DNS — протокол неординарный. Это один из старейших, повсеместно используемых и наиболее важных сетевых протоколов и в то же время — источник множества проблем, связанных с безопасностью сетей. Протокол DNS имеет ряд фундаментальных ограничений, но это не дает оснований считать его слабейшим звеном в системе безопасности организации.

Возможно, многие не склонны уделять внимание вопросу безопасности DNS именно из-за его очевидности. Ведь так просто забыть о сервере DNS после того, как он настроен. Но неверно настроенный и предоставленный самому себе сервер DNS может стать угрозой для безопасности. Поскольку эти серверы являются поставщиками информации, касающейся корпоративной сети, они всегда будут мишенями для злоумышленников. Тем не менее тщательное планирование и бдительность помогут свести риск к минимуму. Администратор может многое сделать для создания добротной и безопасной инфраструктуры DNS в своей сети вне зависимости от того, работает он с Microsoft DNS или с BIND. Сведения о различиях между BIND и Microsoft DNS приведены во врезке «Microsoft DNS или BIND?».

Атаки на сервер DNS

Чтобы защитить сервер DNS, нужно понимать, каким образом посторонние могут использовать бреши в его защите. Самые распространенные угрозы — это атаки типа «отказ в обслуживании», Denial of Service attacks, (DoS), манипуляции с записями DNS и сбор данных. DoS-атаки, вероятно, более распространены, потому что организуются они на удивление просто из-за большого числа неверно настроенных DNS-серверов в Internet. DNS-серверы часто выступают в качестве стартовых площадок для запуска DoS-атак, в которых злоумышленник использует сервер DNS, допускающий возможность рекурсии, для того чтобы обрушить на другой сервер лавину пакетов. Подобные атаки истощают ресурсы атакуемого сервера и лишают законных пользователей возможности обращения к нему.

Манипуляции с записями DNS принимают разные формы. Эта угроза не столь распространена, но тем не менее существует. Один из методов манипуляций с DNS называется отравлением кэша (cache poisoning); злоумышленник запускает в кэш сервера DNS фальшивые записи. К другим методам модификации записей DNS относятся поддельные пакеты, атаки через посредника (man-in-the-middle attacks) и использование ложных серверов DNS. В дополнение к модификации записей хакеры используют серверы DNS для сбора информации посредством доступа к файлам, передачи зоны и перехвата пакетов DNS. Правильная настройка серверов DNS в значительной степени снижает опасность всех этих действий.

Изолируйте функции DNS

Первый шаг на пути к предотвращению атак серверов DNS состоит в планировании сетевой инфраструктуры таким образом, чтобы функции DNS были изолированы друг от друга. Термин «сервер DNS» предполагает выполнение двух очень разных функций; это обстоятельство может привести к путанице в процессе создания их конфигурации. Сервер DNS может быть публикующим сервером, а может быть сборщиком (преобразователем) информации, хранящейся в других местах. Максимальной защищенности можно добиться лишь в том случае, если обе эти функции никогда не выполняются одновременно. Публикующий сервер DNS хранит и публикует достоверные записи о контролируемом домене. Публикующий сервер DNS может быть общедоступным сервером DNS, который информирует всех о том, как обратиться к вашему Web-сайту или к почтовым серверам либо к внутреннему серверу DNS в Active Directory. С другой стороны, сервер–преобразователь DNS принимает запросы DNS от пользователей организации и при необходимости связывается с внешними серверами DNS для обнаружения потерянных данных. Серверы – преобразователи DNS могут кэшировать записи для ускорения будущих операций просмотра, а также действовать в качестве переадресующего звена, направляющего запросы клиентов на другие серверы DNS.

Как правило, серверы DNS прекрасно справляются с выполнением обеих функций в одно и то же время, и в организациях обычно имеется несколько серверов DNS, работающих в таком режиме. Однако надо сказать, что именно из-за подобной практики так много серверов DNS остаются уязвимыми. Администратор должен иметь в сети по меньшей мере три различные серверные роли: выходящие в Internet публикующие серверы для общедоступных серверов, частные публикаторы DNS для AD и других внутренних записей DNS и серверы – преобразователи DNS для выполнения задач поиска, кэширования и перенаправления данных внутренним клиентам.

Для повышения производительности, а также с целью ограничения возможности отравления кэша эти роли необходимо разграничить. Чтобы еще более смягчить последствия DoS-атак, администратор должен закрепить за каждой ролью по меньшей мере два сервера. Многие компании наделяют всеми ролями один-единственный сервер DNS, но лучшее решение — это изоляция серверных ролей, поскольку, даже если сейчас та или иная настройка является неуязвимой, она может стать уязвимой в будущем.

Важно надежно защитить все роли DNS-серверов, но я хотел бы особо остановиться на самой важной роли — роли публикующих серверов, имеющих выход в Internet.

Общедоступные публикующие серверы DNS

Публикующие DNS-серверы, имеющие выход в Internet, являются единственными серверами DNS, видимыми за пределами сети компании. Поэтому объем хранимой в них информации необходимо ограничивать, иначе злоумышленники смогут использовать ее. Общедоступные публикующие серверы должны содержать только записи общедоступных главных машин и публиковать записи только для серверов, доступных из Internet, — например, для Web-серверов, почтовых серверов и серверов FTP. Общедоступные публикующие серверы должны содержать только общедоступные IP-адреса и другие общедоступные записи, такие как записи Sender Policy Framework и базовые сведения о контактах. Если какие-либо сетевые адаптеры указывают на общедоступные серверы DNS, значит, у вас, скорее всего, возникла проблема, и ее необходимо устранить.

Но при всей важности управления информацией главная стратегическая линия в деле защиты общедоступных публикующих серверов должна состоять в следующем. Эти серверы необходимо настраивать таким образом, чтобы они отвечали только на запросы, касающиеся хранящихся на них записей. Они никогда не должны выполнять операции поиска DNS или другой информации от имени инициаторов запроса. Ограничив диапазон ответов, вы исключите опасность отравления кэша и заблокируете попытки злоумышленников использовать ваш сервер DNS в качестве ретранслятора, участвующего в DoS-атаке. При работе как с BIND, так и с Microsoft DNS для обеспечения безопасности общедоступных публикующих серверов необходимо принять несколько мер.

Отключение средств рекурсии

Средства рекурсии позволяют серверу DNS находить запись хостов от имени другого сервера. При этом проблема состоит в том, что в процессе выполнения поиска за других сервер DNS может стать участником операции отравления кэша. Более того, злоумышленники часто привлекают рекурсивные серверы DNS к участию в DoS-атаках.

При организации таких атак хакеры создают на контролируемых ими серверах множество записей DNS и затем направляют тысячи запросов к рекурсивным DNS-серверам по всему Internet.

Отключение средств рекурсии DNSПосле проведенной модификации эти запросы выглядят так, будто они поступили с одного IP-адреса, поэтому каждый сервер DNS обычно захватывает эту запись, кэширует ее и возвращает по модифицированному IP-адресу. Повторяя этот процесс, организатор атаки может «затопить» целевой сервер потоком запросов. Единственный способ этого избежать состоит в настройке каждого общедоступного DNS-сервера в Internet так, чтобы он блокировал рекурсивные запросы. В Internet имеется порядка полумиллиона серверов DNS, допускающих возможность рекурсии. Перенастроить их все невозможно, но вы можете выполнить свою часть работы, правильно настроив серверы.

Для отключения средств рекурсии на сервере Microsoft DNS нужно открыть окно оснастки DNS Management Console, правой кнопкой мыши щелкнуть имя компьютера на левой панели и выбрать пункт Properties. Перейдите на вкладку Advanced и установите флажок Disable recursion, как показано на экране 1. Кроме того, проследите, чтобы был выбран параметр Secure cache against pollution.

Те, кто использует BIND, могут отключить средства рекурсии, добавив следующую запись в раздел параметров файла named.conf:

Options {
recursion no;
};

Отметим, что в BIND администратор может с помощью допускающего рекурсию списка управления доступом разрешить рекурсию только с доверенных IP-адресов. Но хотя в некоторых настройках это может быть единственно возможным решением, наиболее надежная защита тем не менее предполагает блокировку любой рекурсии на общедоступных серверах DNS.

Ограничивайте передачи зон

На удивление часто встречается следующая ошибка в настройке серверов DNS: администратор разрешает всем хостам выполнять передачи зон и дает санкцию на возвращение всех записей для зоны. Передачи зон обеспечивают серверам DNS возможность совместно использовать информацию, но следует с осторожностью ограничивать число хостов, которые могут запрашивать их. Если в обычных ситуациях серверы не имеют возможности обновлять друг друга, передачи зон могут быть полностью заблокированы.

Чтобы ограничить передачи зон в Microsoft DNS, откройте окно программы DNS Management Console, правой кнопкой мыши щелкните домен, который будете настраивать, выберите пункт Properties и затем перейдите на вкладку Zone Transfers. Если вы хотите активировать передачи зон, проследите за тем, чтобы разрешения были предоставлены только серверам, указанным на вкладке Name Servers, или используйте конкретные IP-адреса. Никогда не предоставляйте возможность выполнять данную операцию всем серверам.

В BIND эту настройку можно изменить в файле named.conf. Изменение вносится либо в разделе глобальных параметров, либо в разделах индивидуальных зон. Не забывайте, что настройки, указанные в разделе зоны, переопределяют глобальные параметры этой зоны, поэтому лучший способ управления передачами зон состоит в блокировке их на глобальном уровне и в последующей настройке индивидуальных зон таким образом, чтобы выполнялись только те запросы на передачу зон, которые поступают с определенных IP-адресов. Для этого добавьте в файл named.conf следующий код:

Option {
recursion no;
fetch-glue no;
allow-transfer {none;};
};

zone «example.com» in{

allow-transfer
(192.168.0.15;);
};

Сокращайте внешнее воздействие

Для предотвращения злоупотреблений важно ограничивать работу всех сетевых служб; они должны использовать лишь заданные порты и IP-адреса. Администраторам всегда следует ограничивать доступ к серверам DNS с помощью фильтров пакетов, таких как брандмауэры или маршрутизаторы, и задавать ограничения при настройке самих серверов. Чтобы сервер Microsoft DNS осуществлял прослушивание лишь по заданным IP-адресам, откройте окно DNS Management Console, правой кнопкой мыши щелкните имя компьютера, выберите пункт Properties и перейдите на вкладку Interfaces. Затем вы сможете ввести конкретные IP-адреса, которые хотите прослушивать, как показано на экране 2.

Ограничение IP-адресов, прослушиваемых DNS

В BIND IP-адреса для прослушивания можно установить как глобальный параметр или как параметр зоны в файле named.conf. Делается это так:

Options {
recursion no;
fetch-glue no;
allow-transfer {none;};
listen-on {192.168.0.8;};
};

В Microsoft DNS управлять удаленным сервером DNS можно с помощью протокола удаленного вызова процедур, remote procedure call (RPC). Если вы не пользуетесь этой возможностью, отключите RPC, чтобы уменьшить площадь атаки. Для отключения необходимо внести изменения в реестр сервера. С помощью редактора Regedit нужно найти раздел HKEY_LOCAL_MACHINESYSTEM CurrentControl
SetServicesDNSParameters и создать параметр типа DWORD с именем RpcProtocol. Задайте параметру значение 0 и перезапустите сервер DNS, чтобы новая настройка вступила в действие.

Дополнительные возможности

Итак, после проведенной работы ваш сервер DNS будет блокировать рекурсивные запросы DNS с других серверов, не будет пытаться отвечать на запросы вне своих зон, начнет санкционировать передачи зон только пользующимся доверием хостам и будет прослушивать только указанные IP-адреса. Если этот сервер содержит только общедоступные записи DNS, его можно считать достаточно защищенным для того, чтобы использовать в качестве публикующего сервера DNS. И если теперь вы выберете разумные настройки для брандмауэра, будете тщательно управлять внесением изменений и выполнять другие рекомендации в области безопасности, можете быть уверены, что ваш сервер DNS не представляет угрозы ни для вашей сети, ни для других.

Но остаются и дополнительные возможности. Используя протокол IPsec для взаимодействия между доверенными хостами, а также расширения DNS Security Extensions (DNSSEC) и Transaction Signature extensions, можно еще более повысить уровень целостности и конфиденциальности трафика DNS. Продуманные меры по усилению защиты помогут предотвратить другие типы атак на сервер DNS. Наконец, добротная система сетевого мониторинга может предупреждать о грозящих атаках.

Марк Барнетт (mburnett@xato.net) —независимый консультант по безопасности и автор, специализирующийся на вопросах безопасности Windows. Обладатель сертификата IIS MVP


Microsoft DNS или BIND?

Меня могут спросить: а какое решение обеспечивает более высокий уровень защиты — Microsoft DNS (поставляемое в комплекте Windows) или известная система BIND? Большинство организаций, эксплуатирующих сети на базе Windows, используют Microsoft DNS, так как этот элемент является одним из центральных компонентов Active Directory, но многие утверждают, что BIND обеспечивает более надежную защиту.

Сравнивать уровень безопасности, обеспечиваемый этими продуктами, непросто. BIND позволяет осуществлять более тонкую настройку и полностью совместим с расширениями DNS Security Extensions, но в нем было отмечено больше дефектов системы безопасности, чем в реализации DNS, осуществленной корпорацией Microsoft. Microsoft DNS проще разворачивается, что, как утверждают некоторые, снижает вероятность ошибок при настройке. Однако именно из-за простоты настройки повышается вероятность того, что за эту работу будут браться неопытные администраторы — и допускать при этом ошибки. В конечном счете, надежно защитить сервер DNS можно с помощью любого из этих двух продуктов. В отличие от большинства уязвимых мест в системе безопасности, проблемы с DNS чаще всего являются результатом ошибок настройки, а не дефектов кода.