 |
|
|
|
Минимум усилий на защиту DNS
Минимум усилий на защиту DNS По статистике (некоторых security teams) из 100 % серверов – 63% работает с неправильно настроенной службой DNS, в контексте сетевой безопасности, конечно. Узнав столь печальную статистику, я решил провести свой собственный анализ. И вот что у меня вышло – из 100 серверов, выбранных мною наугад из различных сегментов Интернета, 57 серверов оказались с неправильно настроенной службой имен. Под словом «неправильно» я подразумеваю, например, получение файла пересылки (transfer) зоны (эта информация является наиболее важной в аспекте безопасности DNS), на основе которого, как известно, можно построить схему внутренней сети исследуемой системы, так как мы получаем полную информацию о инфраструктуре внутренней сети (имена хостов, IP -адреса, почтовые сервера, вышестоящие сервера имен, псевдонимы хостов и т. д.). Вот наглядный пример: выбираем цель, например, www.target.ru; как известно, для работы с DNS подходит nslookup, которая входит в состав большинства ОС. Итак: fenix# nslookup
>server www.target.com >ls -d target.com и если в ответ мы получаем что-то похожее на:
(данная информация является файлом пересылки зоны), то это означает, что администратор системы не предпринял никаких усилий, хотя бы минимальных, (которые я опишу в этой статье) для защиты DNS то ли от незнания, то ли от неумения. Но это все неважно, так как речь в этой статье будет идти не о причинах, побудивших или не побудивших администратора к такому безразличию, которое в свою очередь может привести к плачевным результатам. Я хочу попытаться показать, как хотя бы «немного», (если это слово можно считать корректным в контексте сетевой безопасности) защитить свой DNS-cервер. Я ни в коем случае не претендую на полноту изложенной здесь информации, так как этот вопрос требует намного более пристального внимания со стороны администраторов и выходит за пределы этой статьи; более детальную информацию о защите DNS можно получить в списке дополнительных материалов в конце этой статьи. Итак, начнем. Прежде всего следует сказать, что все описанное ниже будет относиться к настройке bind 8.x.x. Работать мы будем непосредственно с файлами конфигурации bind, а если быть точным, то в основном с named.conf (/etc/namedb/named.conf). Первое, что необходимо сделать в named.conf – это определить список доступа acl, в который будут входить «доверенные» сети и хосты (так же я советую включить в этот список IP -адреса первичных DNS-серверов, которые делегировали на вас управление каким-либо доменом). Создаем секцию acl в самом начале файла (named.conf): acl "trusted" { localhost; 192.168.3.0; }; таким образом, «доверенными» являются localhost и сеть (192.168.3.0), хосты которой пользуются услугами нашего cервера имен. Далее в секцию options данного файла вносим: options { ... # определения прав доступа по умолчанию allow-query { trusted }; # разрешить запросы группе «доверенных» хостов allow-transfer { none }; # запретить пересылку файла зоны кому-либо allow-recursion { trusted }; # pазрешить рекурсивные запросы группе «доверенных» хостов ... }; Данные директивы определяют поведение bind по умолчанию (запросы разрешены только для «доверенных» хостов, трансфер зон запрещен, рекурсивные запросы разрешены только для «доверенных» хостов), эти директивы можно переопределить для каждой зоны в соответствующей секции zone. Тут я советую следовать такому «правилу»: зонам, для которых наш сервер имен является вторичным (slave), необходимо явно разрешить запросы с любым ip-адресом источника, для первичных зон (master), кроме (0.0.127.in-addr.arpa), дополнительно к этому необходимо разрешить трансфер зонных файлов, то есть вот что у нас выходит: zone "example.com" { type master; file "primary/example.com"; # переопределение прав доступа, заданных по умолчанию в options allow-query { any; }; allow-transfer { localhost; 192.168.3.0; }; В }; zone "3.168.192.in-addr.arpa" { type slave; file "secondary/0.126.in-addr.arpa"; masters { 192.168.3.1; } ; # переопределение прав доступа, заданных по умолчанию в options allow-query { any; }; allow-transfer { localhost; }; }; }; В том случае если ваш сервер является, например, сервером имен (единственным) для локальной сети (intranet), т. е. не является шлюзом во внешний мир, то можно настроить bind таким образом, чтобы он разрешал запросы только с «доверенных» хостов. Для этого необходимо в named.conf внести описание зоны bind: zone "bind" chaos { type master; file "primary/bind"; allow-query { trusted }; allow-transfer { none; }; }; и создать, собственно, файл описания зоны: $TTL 3600 $ORIGIN bind. @ 1D CHAOS SOA localhost. root.localhost. { 1 ;serial 3H ;refresh 1H ;retry 1W ;expire 1D ) ;minimum CHAOS NS localhost/ ; Доступ мы ограничили; я думаю, со мной многие согласятся, что «защита» без ведения логов – это не защита, так как лучше знать своего врага в лицо. Разработчики bind’a позаботились и об этом: существует возможность ведения лог-файлов. Вот основные приемы (создаем новую секцию logging): logging { # определяем канал по умолчанию для ведения логов запросов к bind channel default_ch { file "/var/log/named.log"; serverity info; # уровень важности регистрационной информации print-time yes; # регистрировать время print-category yes; # регистрировать категорию }; channel security_ch { # определяем канал для ведения логов по защите file "/var/log/security.log"; serverity info; print-time yes; print-category yes; }; # инициализация каналов category default { default_ch; }; category security { security_ch; }; }; Вот и все. Как было сказано выше, эта информация не является исчерпывающей по данному воросу, так как полная настройка системы защиты DNS строится на создании для службы DNS chrooted environment, создание для нее sandbox и т. д., вплоть до защиты системы в целом. Рекомендуемые материалы:
|
СЕРГЕЙ РОПЧАНКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
