Известно, как важно защитить серверы имен DNS, но как быть с клиентами DNS? Две недавно появившиеся угрозы — проблема, связанная с протоколом автообнаружения Web Proxy (WPAD), и атака с перенастройкой распознавателя — нацелены против клиентов DNS. Что представляют собой эти атаки и как противостоять им?
WPAD
Первое уязвимое место связано с протоколом WPAD, с помощью которого браузеры определяют параметры proxy-сервера. В сущности, браузер, совместимый с WPAD, использует DNS для поиска имени wpad и подключения к Web-серверу по возвращенному адресу, чтобы получить файл автонастройки proxy-сервера с именем wpad.dat. Затем браузер считывает конфигурацию proxy-сервера из этого файла. Цель — предоставить администраторам процедуру для задания конфигурации proxy-сервера всех браузеров компании из одной точки. Сейчас этот механизм поддерживают браузеры Microsoft Internet Explorer (IE), Mozilla Firefox и Opera.
На первый взгляд WPAD не опасен. Однако взаимодействие протокола со списком поиска — в терминологии Windows список просмотра суффикса DNS или порядок просмотра суффикса DNS — может оказаться непредсказуемым и нежелательным. Список просмотра — последовательность имен доменов, добавляемых к именам, указываемым в поле адреса браузера или командной строке. Например, если список просмотра содержит имена доменов subdomain.company.com и company.com, можно ввести
http://foo
в поле адреса браузера, и браузер сначала найдет foo.subdomain.company.com, а потом (если при просмотре адрес не найден) foo.company.com. Список просмотра также применяется к внутреннему поиску имени wpad в браузере.
Этот список можно задать явно, имя домена за именем домена, но чаще он наследуется (регрессируется, в терминологии Microsoft) из локального имени домена компьютера Windows (в Microsoft его называют основным DNS-суффиксом). По умолчанию список просмотра включает локальное имя домена и все имена предков домена, по крайней мере с двумя метками. Поэтому локальное имя домена sub.net.ac.uk регрессирует в список просмотра sub.net.ac.uk, net.ac.uk и ac.uk.
Проблема возникает, когда комбинация wpad и элементов списка просмотра совпадает с именем домена вне области, контролируемой компанией. Например, если в список просмотра входят sub.org.co.nz, org.co.nz и co.nz, браузер будет искать wpad.sub.org.co.nz, wpad.org.co.nz, а затем wpad.co.nz. Если wpad.sub.org.co.nz и wpad.org.co.nz не существуют, браузер может получить конфигурацию proxy-сервера из wpad.co.nz, имени домена, не контролируемого компанией. Домен wpad.co.nz domain принадлежит Бо Батлеру, новозеландскому специалисту по безопасности, который недавно описал именно эту проблему. Браузер в такой конфигурации может пропустить весь Web-трафик компании через подставной proxy-сервер.
Злоумышленник может эксплуатировать механизм WPAD и другим способом: если он подключится к компьютеру с именем wpad в сети компании, то у этого компьютера будет возможность зарегистрировать свое имя в DNS или DHCP-сервер сделает это за него. Затем злоумышленник может организовать на компьютере Web-сервер для распространения небольшого, специально подготовленного файла wpad.dat, который также направит весь трафик браузера злоумышленнику.
Решение проблемы WPAD
Устранить проблему можно несколькими способами. Во-первых, можно организовать (или использовать существующий) Web-сервер для распространения корректного, официально одобренного файла конфигурации по WPAD-совместимым браузерам. Затем следует добавить в зоны A-записи wpad, указывающие на адрес Web-сервера (A-записи — записи ресурсов DNS, которые сопоставляют имена доменов с IP-адресами). Во-вторых, можно использовать локальный для сайта параметр DHCP 252 (auto-proxy-config), чтобы указать Web-сервер и файл, из которого браузер должен загрузить конфигурацию proxy-сервера. В любом случае после того, как браузер обнаружит файл автоконфигурации proxy-сервера, поиск прекратится. В-третьих, можно отключить WPAD из браузера или с помощью групповой политики. В IE можно отключить WPAD из меню Tools, Internet Options, Connections, LAN Settings (см. экран 1). В диалоговом окне нужно снять флажок Automatically detect settings, чтобы отключить WPAD.
Четвертый вариант — сократить список просмотра до необходимого минимума. Сделать это полезно в любом случае, чтобы устранить непредвиденные совпадения в контекстах, отличных от WPAD. Чтобы отключить механизм регрессии Windows, который вносит в список просмотра предков имени локального домена, нужно снять флажок Append parent suffixes of the primary DNS suffix в окне Advanced TCP/IP Settings в модуле Network панели управления (см. экран 2). После снятия флажка предки основного суффикса DNS (но не сам основной суффикс DNS) не включаются в список просмотра. Такого же результата можно добиться с помощью групповой политики.
Прежде чем исключить все имена предков из списка просмотра, следует убедиться, что они не требуются пользователям и приложениям. Пользователи могут привыкнуть к вводу укороченных имен доменов в браузерах или командной строке и использовать их в файлах конфигурации. Например, может оказаться, что пользователи нуждаются в нескольких элементах списка просмотра. Если только последнее имя домена в списке просмотра подозрительно, можно явно удалить одно имя домена, оставив остальные. На экране 3 показано, как включить в список просмотра sub.org.co.nz и org.co.nz, но не опасную запись co.nz.
И наконец, даже если используется параметр DHCP, чтобы указать Web-сервер, выдающий файл автоконфигурации proxy-сервера, следует добавить A-запись для wpad во все зоны с преобразованием имени в адрес (forward-mapping). После того как браузер обнаружит эту A-запись, поиск прекращается, даже если по указанному IP-адресу нет активного Web-сервера. Во многих случаях добавление A-записи wpad также помешает подставному компьютеру с именем wpad зарегистрировать свое имя в DNS, поскольку это имя уже задействовано. Если предотвратить регистрацию не удается — не составляет труда настроить клиент DHCP с именем компьютера wpad, чтобы увидеть, может ли он перезаписать A-запись wpad, добавленную вручную, — проверьте, что сервер имен настроен на прием только безопасных динамических обновлений (если это DNS-сервер Microsoft), а DHCP-сервер использует промежуточный стиль обновления DDNS (если применяется DHCP-сервер ISC).
И наконец, не используйте адрес замыкания на себя 127.0.0.1 в A-записи. По какой-то причине A-запись, указывающая на этот адрес замыкания на себя, не останавливает обработку списка просмотра.
Перенастройка распознавателя
Недавно организация Measurement Factory провела исследование инфраструктуры DNS сети Internet (dns.measurement-factory.com/surveys/200710.html) и обнаружила примерно 16 млн открытых рекурсоров. Открытый рекурсор — IP-адрес, который принимает рекурсивные запросы из любого источника. Это само по себе плохо: хакеры могут использовать открытые рекурсоры как вспомогательное средство для распределенных атак с отказом в обслуживании против целей в Internet. Открытые рекурсивные серверы имен также более уязвимы для атак с подделкой записей кэша. Однако при глубоком исследовании природы открытых рекурсоров обнаруживается более коварная угроза.
Группа исследователей (с участием Дэвида Дэгона из института Georgia Tech) направляла запросы в открытые рекурсоры и изучала ответы. Большинство ответов были корректными, но некоторые неверными — очевидно, из-за программных ошибок и неверных настроек. Но ответы некоторых открытых рекурсоров (числом примерно 68 000) были одновременно неверными и потенциально опасными. Эти открытые рекурсоры всегда возвращали одни и те же адреса в ответ на любой запрос. Многие из этих адресов принадлежат открытым proxy-серверам в таких опасных с точки зрения Internet странах, как Россия и Китай, или сетям, зарекомендовавшим себя как источник спама.
Конечно, никто сознательно не настроит распознаватель компьютера на один из этих открытых рекурсоров. Тем не менее в выборках DNS-трафика, собранных группой Дэгона в Georgia Tech, было обнаружено много компьютеров, использующих эти открытые рекурсоры в качестве основных источников преобразования имен. Вероятно, их распознаватели были настроены на использование этих открытых рекурсоров разрушительными программами, загруженными из Internet (многие виды вредоносных программ делают именно это). После того как конфигурация компьютеров была изменена, ответы открытых рекурсоров направляют весь Web-трафик через эти удаленные proxy-серверы, в которых данные (например, пароли или информация кредитных карт) могут быть перехвачены и использованы злоумышленниками.
Защита от перенастройки распознавателя
Помимо обычных мер против загрузки вредоносных программ, в частности разъяснения пользователям необходимости проявлять осторожность при загрузке файлов из Internet, существуют способы помешать использованию в этой схеме зараженных компьютеров. Правила брандмауэров должны запрещать произвольным внутренним компьютерам запрашивать серверы имен в Internet. Если вредная программа меняет конфигурацию распознавателя компьютера, тот просто перестает работать. Пользователь компьютера, скорее всего, сообщит об этой неполадке в ИТ-специалистам, которые могут установить причину неисправности, удалить вредную программу и восстановить первоначальную конфигурацию распознавателя.
В таблице показан набор правил брандмауэра, которые позволяют определить набор внутренних серверов имен, имеющих право обращаться к серверам имен в Internet (и получать ответы), но блокируют запросы, исходящие непосредственно из внутренних распознавателей к серверам имен в Internet. Если возможно, брандмауэр должен также применять фильтрацию пакетов UDP в контексте протокола и состояния соединения, чтобы принимать датаграммы UDP только из таких IP-адресов серверов имен в Internet, к которым недавно обращался внутренний сервер имен.
Не забывайте о клиенте
Большинство ИТ-администраторов обращает основное внимание на защиту серверов имен, но атаки могут быть направлены против клиентов. Поэтому будьте бдительны. Успешные атаки против распознавателей могут принести такой же ущерб, как нападения на серверы имен. Полезные рекомендации и инструментарий по DNS можно найти в электронной библиотеке ресурсов по адресу www.infoblox.com/library/dns_resources.cfm.
Крикет Лиу (cricket@infoblox.com) — вице-президент по архитектуре в Infoblox. Соавтор книги об устройстве DNS, издательство O’Reilly
Таблица. Правила брандмауэров