Защита DNS

DNS служба является достаточно критичным и важным компонентом Интернета. Дело в

том, что это служба нужна для того, чтобы пользователи могли общаться с узлами не по
их ip адресам, которые собой представляют набор цифр, а по именам. С момента развития
Интернета, увеличилось и количество узлов в сети, поэтому появление DNS в принципе и
следовало ожидать. Думаю, сейчас уже не стоит объяснять всю важность этой службы.
Как я и сказал чуть выше, DNS сервера в сети отвечают за то, чтобы получить запросы от
клиентских машин и соответствующим образом их обрабатывать, так же DNS сервер
хранит так называемые зоны, в которых содержится вся необходимая информация.
Клиенты могут запрашивать получение IР адреса удаленного узла по имени и наоборот,
все эти запросы посылаются к DNS серверу на 53 порт, по протоколу udp. Что все же
происходит, когда этот запрос приходит на DNS сервер? Все очень просто, если DNS
серверу не удалось найти соответствующих данных в своих зонах, то он может
перенаправить этот запрос вышестоящему серверу, который может содержать
необходимые данные. В данном случае это у нас рекурсивный запрос. Рекурсивный
запрос – это запрос, на который DNS сервер обязан вернуть либо ответ запросившему
компьютеру, либо сообщение об ошибке, так же DNS сервер берет на себя задачу опроса
вышестоящих DNS серверов на предмет нужных данных. Существует и другой тип
запросов, который чаще всего называется итеративным запросом. Итеративный запрос –
это когда DNS сервер получает запрос и, если он не находит нужные данные у себя в
зонах, он может вернуть в качестве ответа адреса другого DNS сервера, при этом
предполагая, что клиент сделает соответствующий запрос к указанному DNS серверу в
ответе. 

Сейчас, когда мы с вами все же не много вспомнили принципы работы DNS сервера, мы
можем обсудить вопросы его безопасности. Что нас интересует в первую очередь?
Правильно - отказоустойчивость. Что же можно сделать для повышения
отказоустойчивости? Чаще всего в сети устанавливают вторичный DNS сервер, который
полностью дублирует содержащуюся информацию на первичном DNS сервере. Такая
практика встречается практически повсеместно, но многие не учитывают определенных
факторов. Таких, например, как нагрузка на каналы передачи данных. Допустим у нас в
сети несколько тысяч клиентов и два DNS сервера, которые установлены в одном сетевом
сегменте. Все решили послать запрос на первичный DNS сервер, естественно уровень
загруженности канала у нас резко возрастает или вообще он отказывает. Что произойдет?
Правильно, клиенты не получив ответ от первичного DNS сервера, будут посылать
соответствующие запросы на вторичный, но вторичный у нас не сможет на них ответить,
так как он их просто не получит, произойдет отказ в обслуживании. По этому очень важно
располагать DNS сервера как можно «удачнее» в сети, то есть в разных сетевых
сегментах, а еще лучше, если в разных подсетях. Казалась бы мелочь, но это мелочь очень
существенна, особенно если вы крупный Интернет-провайдер. Теперь хотелось бы
поговорить по поводу самих запросов к DNS серверу. Первое: нам нужно, чтобы наш DNS
сервер обслуживал компьютеры нашей сети, а не чужой. Тем самым мы снимаем еще и
другие проблемы, такие как нагрузка нежелательных пользователей. Сделать это можно
несколькими способами. Первый и самый желательный способ для подстраховки и
снижения нагрузки на сервер это закрыть только входящие обращения по 53 порту по
периметру сети. Но данный способ может не устраивать Интернет-провайдера. А дело все
в том, что Интернет провайдер, как правило, имеет несколько каналов связи,
проконтролировать соответствующие настройки будет достаточно проблематично, но
суть не в этом, суть в другом. Что если наш DNS сервер обслуживает какой-нибудь
домен? Правильно, к нему тогда не смогут обратиться другие DNS серверы и получить
соответствующую информацию, поэтому в данном случае ограничение по запросам из
других сетей не стоит делать вообще или делать это очень и очень аккуратно. Второй
способ это произвести соответствующие изменения в конфигурации DNS сервера. В
качестве примера возьмем с вами BIND. Для того, чтобы разрешить производить работу
только клиентам нашей сети, необходимо изменить добавить всего одну строчку в
файле /etc/named.conf. Открыв этот самый файл, мы с вами находим в начале файла раздел
options и пишем туда следующие:
Allow-query { 213.48.57.70/24; localhost; };

Где 213.48.57.70 идентификатор нашей сети, 24 код по CIDR который в свою очередь
соответствует маске подсети 255.255.255.0, а localhost сам сервер. 

Вы, наверное, часто встречали в Интернете информацию, о том, что все же лучше
отключать рекурсивные запросы на DNS серверах. Это действительно так, так как чаще
всего при организации DDOS атак используют рекурсию, да и зачем нагружать DNS
сервер ненужной работой, если часть функций может выполнить и сам клиент? Правильно
- не зачем. Как исправить? В случае с BIND’ом опять открываем файл named.conf и в
разделе options добавляем следующую строчку:
Allow-recursion { localhost; };

Если вы все же страдает полной паранойей, то вы можете значение localhost заменить на

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

Первичный DNS сервер в сети всегда располагает более актуальной информацией, чем
вторичный, так как информацию они синхронизируют не в реальном времени, а через
определенный промежуток времени. Вторичный DNS сервер посылает соответствующий
запрос к первичному DNS серверу и если все в порядке, то первичный DNS сервер
возвращает первичному свою копию зоны. Часто тут системные администраторы не
учитывают такого момента, что конфигурация большинства DNS серверов позволяет
получить эту копию с любого IP адреса, что в принципе несет в себе не очень хорошие
последствия. Тогда имеет смысл ограничить на первичном DNS сервер пересылку зоны
только на вторичный DNS сервер, а на вторичном DNS сервере вообще ее запретить, так
как все изменения в зонах производятся только на первичном DNS сервере. В BIND это
делается следующим образом (файл named.conf):
Allow-transfer { 213.48.57.81; ); 

Где 213.48.57.81 это адрес вторичного DNS сервера. Как можно проверить свой DNS
сервер на предмет наличия этой ошибки в конфигурации? Делается это следующим
образом, запускается утилита nslookup, после чего дается команда server ns1.company.com,
а потом команда ls –d company.com. Если уязвимость есть, то вы на экране увидеть всю
информацию из этой зоны. 

Пример:
company.ru. SOA ns1.company.ru root.ns1.company.ru. (2003103001 3600 600 604800 3600)
company.ru. NS ns1.company.ru
ns1 A 213.48.57.81
Так же первичный DNS сервер может уведомлять вторичный DNS сервер об изменениях в
зонах, что приведет к изменению зоны на вторичном DNS сервере. А теперь давайте
представим себе такую ситуацию: злоумышленник постоянно посылает ложные запросы
на вторичный DNS сервер, в результате чего DNS сервер дезинформирован. На самом
деле, такая ситуация несет критический характер, особенно если в сети используются
различные средства безопасности, которые могут зависеть от работы DNS службы. Как
можно защититься от такого рода атак? В принципе это, опять же,  возможно средствами
BIND, в его новой версии. В новой версии BIND появилась такая новая функция как TSIG.
Что это такое? Это новый более защищенный механизм, который позволяет осуществлять
проверку при передачи зон и уведомлений об изменениях не только по ip адресу, но и по
MD5 ключу. Для того, чтобы включить этот механизм, необходимо сгенерировать
соответствующие ключи. Делается это следующим образом:
devil# dnssec-keygen –a hmac-md5 –b 128 –n HOST dnskey

в результате чего у нас будут сгенерированы два файла, нас интересует второй файл,
который имеет расширение .private. Теперь:
devil# cat key.private
Private-key-format v1.2
Algorithm,: 157 (HMAC_MD5)
Key: BdySGxJmrd6N1YG2agKPh0==

После чего мы открываем named.conf и прописываем туда следующие на обоих DNS

серверах:
Key dns { algorithm hmac-md5; secret “BdySGxJmrd6N1YG2agKPh0==”; };

Server ipadress { keys { dns; }; };

Где ipadress у нас ip адрес другого DNS сервера. На первичном DNS сервере естественно
необходимо указать ip адрес вторичного DNS сервера. То же самое необходимо проделать
на вторичном DNS сервере, но уже указав там ip адрес первичного DNS. Механизм на
самом деле очень хорош, но что делать другим администраторам, у которых либо старая
версия BIND, либо в качестве него работает другое программное обеспечение? В качестве
решения данной проблемы я бы воспользовался средствами IPSecurity, что в принципе
гораздо надежней, чем сам этот механизм. Дело в том, что IPSecurity абсолютно прозрачен
для пользователей и другого программного обеспечения за счет того, что работает на
более низком уровне по модели OSI. Для тех, кто не знаком с IPSecurity, могу лишь
добавить, что это протокол позволяет проверять целостность данных, источник,
шифровать передаваемый данные по разным криптографическим алгоритмам (к примеру,
3DES), а так же производить аутентификацию с поддержкой PKI. Рассказывать о том, как
это все можно сделать средствами IPSecurity я не буду, так как это выходит за рамки
данной статьи. Я лишь напомнил об IPSecurity, как о возможном средстве для решения
некоторых проблем в сети.

В принципе вы, наверное, многие слышали про fingprint? Самая начальная стадия
проникновения в сеть, когда злоумышленник только собирает информацию о сети. В
качестве мер предосторожности всегда следует использовать все доступные методы, в
частотности дезинформацию. Например, для того, чтобы изменить версию BIND сервера
достаточно добавить в файл named.conf раздел options следующую строчку:
Version “Not version”;

Это далеко не все рекомендации, но это основные. В качестве более серьезных мер
можно, а иногда и нужно, вынести DNS сервера в DMZ зону, с защитой средствами не
только брандмауэра, но и средставми обнаружения вторжений, таких как SNORT и
RealSecure. Дело в том, что сейчас довольно часто находят различные дыры, которые
приводят к атакам типа DOS. В частности они могут выглядеть в качестве некорректного
запроса. Сигнатуры для этих IDS всегда можно найти на веб узле www.whitehats.com. Так
же старайтесь всегда отключать не нужные службы, а если бюджет позволяет то еще
лучше вынести DNS сервер на отдельный сервер, на котором будет работать только эта
служба. Если же вы стремитесь к очень высокой защищенности сети, тогда по
возможности старайтесь не использовать зоны обратного просмотра. Зоны обратного
просмотра отвечают за сопоставление ip адресу имен узлов. Но и тут есть подводные
камни, так как достаточно многие службы в сети нуждаются в работе этих зон, в качестве
примера могу привести ActiveDirectory. В данном случае мы рассмотрели вопросы
безопасности самой службы DNS, но не забывайте, о том, что в мире информационных
технологий все взаимосвязано.