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. Если уязвимость есть, то вы на экране увидеть всю информацию из этой зоны.
(Продолжение следует)
