Денис Колисниченко - Linux: Полное руководство
13.6. Просмотр DNS-зоны. Утилита nslookup
Утилита nslookup, служащая для просмотра информации о зоне (домене), входит в пакет bind-utils и в популярных дистрибутивах устанавливается по умолчанию. Она есть также в Windows NT/2000/XP.
Зоны бывают разные: одни содержат информацию о компьютерах в домене и служат для преобразования имени компьютера в IP-адрес и наоборот, другие содержат информацию о корневых серверах — зона «.». Последняя зона относится к типу hint — подсказка. Зоны для разрешения имен обычно имеют тип master (главный), а зоны вторичных серверов относятся к типу slave (подчиненный). Обычно просмотр зоны разрешается только определенным, доверенным узлам. Итак, запустите nslookup:
# nslookup
Default Server: ns4.obit.ru
Address: 81.3.165.35
>
Для того, чтобы получить информацию от сервера, нужно ввести в строку приглашения тип запроса: set q=<тип> (или set type=<тип>). Типы запросов перечислены в таблице 13.2.
Типы запросов Таблица 13.2
Тип Описание soa Начало полномочий a Преобразование имени в IP-адрес узла aaaa Отображение IPv6-адреса узла ns Отображение информации о сервере DNS ptr Преобразование IP-адреса в имя узла whs Распространенные службы hinfo Информация об аппаратном обеспечении узла mx Информация о почтовых серверах домена txt Отображение записи общего назначения cname Отображение канонического имени any Отображение всех ресурсных записейТеперь рассмотрим несколько практических примеров. Допустим, вы знаете имя узла — www.server.com. Давайте посмотрим, какая информация будет выведена при указании типа any:
>set q=any
>server.com
Server: myserver.domain.com
Address: 127.0.0.1
Non-authoritative answer:
server.com nameserver = comp1.server.com
server.com nameserver = comp2.server.com
server.com nameserver = comp3.server.com
Authoritative answers can be found from:
server.com nameserver = comp1.server.com
server.com nameserver = comp2.server.com
server.com nameserver = comp3.server.com
comp1.server.com internet address = 323.111.200.1
comp2.server.com internet address = 323.111.200.2
comp3.server.com internet address = 323.555.200.3
А сейчас посмотрим информацию о других узлах в этой сети:
>ls server.com.
[comp2.server.com]
server.com. 323.111.200.2
server.com. server = comp1.server.com
server.com. server = comp2.server.com
server.com. server = comp3.server.com
mail 323.111.200.17
gold 323.111.200.22
www.ie 323.111.200.11
jersild 323.111.200.25
comp1 323.111.200.1
comp3 323.111.200.3
parasit3 323.111.200.20
www.press 323.111.200.30
comp1 323.111.200.1
www 323.111.200.2
Но ответ мог быть и таким:
[server.com]
Can't list domain server.com: Query refused
Чтобы разрешить передачу зоны определенным узлам (а, значит, запретить всем остальным), в файле конфигурации DNS-сервера применяется директива allow-transfer. В следующем примере трансфер зоны разрешен узлам 10.1.1.1 и 10.1.2.1, то есть все остальные узлы в ответ на запрос nslookup ls получат ответ «Query refused»:
options {
allow-transfer {
10.1.1.1;
10.1.2.1;
};
};
Вторичный сервер DNS не передает никакой информации о зоне, поэтому обязательно укажите следующую строку в его файле конфигурации (в секции options):
allow-transfer { none; }
13.7. Оптимизация настроек сервера DNS
Как любой хороший администратор, вы хотите, чтобы ваш сервер DNS быстро обслуживал запросы клиентов. Но к вашему серверу могут подключаться пользователи не из вашей сети, а, например, из сети конкурирующего провайдера. Тогда ваш сервер будет обслуживать «чужих» клиентов. Непорядок! Директива allow-query позволяет указать адреса узлов и сетей, которым можно использовать наш сервер DNS:
allow-query { 192.168.1.0/24; localhost; };
В данном примере мы позволяем использовать наш сервер узлам из сети 192.168.1.0 и узлу localhost. Целесообразно разрешить рекурсивные запросы только из сети 192.168.1.0 и узлу localhost:
allow-recursion { 192.168.1.0/24; localhost; };
Обычно взлом любой сети начинается со сбора информации — о структуре сети, об установленном программном обеспечении и его версиях и т.п. Мы можем заставить сервер DNS не сообщать номер своей версии, а выдавать произвольное сообщение:
version "Made in USSR";
Все перечисленные директивы должны быть указаны в секции options файла конфигурации /etc/named.conf:
options {
allow-query { 192.168.1.0/24; localhost; };
allow-recursion { 192.168.1.0/24; localhost; };
allow-transfer { 10.1.1.1; 10.1.2.1; };
version "Made in USSR";
}
13.8. Защита сервера DNS
13.8.1. Настройка и запуск DNS-сервера в chroot-окружении
Из соображений безопасности рекомендуется запускать все сетевые сервисы в так называемом chroot-окружении (change root). Это файловая система, повторяющая структуру корневой файловой системы, но содержащая только те файлы, которые необходимы для запуска нашего сетевого сервиса. Взломав сетевой сервис и получив доступ к корневой файловой системе, злоумышленник не сможет повредить всей системе в целом, поскольку он получит доступ только к файлам данного сервиса. Некоторые сетевые службы не могут работать в chroot-окружении. BIND — может, и сейчас я покажу, как это организовать.
Не нужно создавать отдельный раздел на диске для каждого сетевого сервиса: нужно только создать каталог, например, root-dns, в который вы скопируете все файлы, необходимые для запуска сервера DNS. Потом, при запуске сервиса, будет выполнена команда chroot для этого сервиса, которая подменит файловую систему. А так как в каталоге root-dns, который станет каталогом /, имеются все необходимые файлы для работы BIND, то для сервиса запуск и работа в chroot-окружении будут совершенно прозрачными.
Сразу нужно оговорить, что настраивать chroot-окружение мы будем для девятой версии BIND, поскольку это значительно проще, чем для восьмой версии. В отличие от восьмой версии, где для настройки chroot-окружения нужно было копировать все бинарные файлы или библиотеки, необходимые для запуска BIND, для работы девятой версии достаточно скопировать только файлы конфигурации и зон, обслуживаемых сервером.
Создайте каталоги корневой файловой системы сервера DNS:
# mkdir -p /root-dns
# mkdir -p /root-dns/etc
# mkdir -p /root-dns/var/run/named
# mkdir -p /root-dns/var/named
Остановите сервер DNS, если он запущен:
# service named stop
Переместите файл конфигурации, файлы зон и файл /etc/localtime (он нужен для корректной работы сервера DNS со временем) в каталог /root-dns:
# mv /etc/named.conf /root-dns/etc/
# mv /var/named/* /root-dns/var/named/
# chown named.named /chroot/etc/named.conf
# chown -R named.named /root-dns/var/named/*
Защитите от редактирования и удаления файл конфигурации:
# chattr +i /root-dns/etc/named.conf
Добавьте в файл /etc/sysconfig/named строку:
ROOTDIR="/root-dns/"
Все, теперь можно запустить сервер named:
# service named start
Проверьте, все ли сделано правильно:
$ ps -ax | grep named.
5380 ? S 0:00 named -u named -t /root-dns/
5381 ? S 0:00 named -u named -t /root-dns/
5382 ? S 0:00 named -u named -t /root-dns/
13.9. Использование подписей транзакций. Механизм TSIG
В девятой версии BIND появилась возможность создавать подписи транзакций (TSIG — Transaction SIGnatures). Механизм TSIG работает так: сервер получает сообщение, подписанное ключом, проверяет подпись и, если она «правильная», сервер отправляет ответ, подписанный тем же ключом.
Механизм TSIG очень эффективен при передаче информации о зоне, уведомлений об изменении зоны и рекурсивных сообщений. Согласитесь, проверка подписи надежнее, чем проверка IP-адреса. Злоумышленник может вывести из строя вторичный сервер DNS банальной атакой на отказ, и, пока администратор будет «поднимать» вторичный сервер, он заменит свой IP-адрес адресом вторичного сервера. При использовании TSIG задача злоумышленника значительно усложняется: ведь ему придется «подобрать» 128-битный MD5-ключ, а вероятность такого подбора близка к нулю.
