Колесниченко Д.Н. Cделай сам компьютерную сеть. Монтаж, настройка, обслуживание
Подождите немного. Документ загружается.
Глава 9. Система DNS
Возможные проблемы и их решения
Как правило, кэширующий сервер используется на отдельной машине,
которая подключается к Интернет по коммутируемому соединению. Нуж-
но учитывать, что сервер
DNS
сразу требует обращения к какому-нибудь
сетевому ресурсу. В нашем же случае, если соединение не установлено,
то устройство рррО существовать не будет, a named будет страшно ру-
гаться на то, что сеть недоступна. При этом недоступным окажется даже
интерфейс 1о, а программа nslookup, если она нам понадобится без суще-
ствования сети, просто
«подвиснет»,
ожидая ответа от сервера DNS.
Есть два способа решить данную проблему. Какой использовать — это
решать вам. Первый заключается в том, что при установлении соедине-
ния сценарий ррр-оп, будет запускать программу ndc с параметром start
(см. ниже), а сценарий ppp-off будет останавливать сервер
DNS
коман-
дой ndc stop.
Второй способ основывается тоже на использовании сценариев ррр-оп и
ppp-off, но в этом случае сервер DNS всегда будет запущен. Принцип
работы заключается в подмене файла корневого кэша
named.са.
Сервер
DNS содержит пустой файл корневого кэша, и при установке соедине-
ния сценарий ррр-оп скопирует вместо пустого файла нормальный файл
кэша. Сценарий ppp-off при разрыве соединения перезапишет нормаль-
ный файл
named.
са пустым файлом с таким же именем. При использо-
вании этого способа в ваших протоколах (журналах) будут регулярно
появляться сообщения примерно такого содержания:
Jan 5 16:10:11 den
named[10147]:
No root
nameserver
for
class IN
Для полноты картины хочу отметить, что если вы используете NFS, и у
вас возникают проблемы с монтированием удаленных файловых систем,
запускайте сервер named после запуска nfsd и mountd.
9.2.3.
Настройка дополнительного (вторичного)
сервера
DNS
Вы когда-нибудь обращали внимание, что у любого уважающего себя
провайдера есть два сервера DNS — первичный (primary или master) и
вторичный (secondary или slave)? Так вот, сейчас и мы займемся настрой-
кой вторичного сервера DNS.
'
Примечание.
Практически у каждого провайдера работают два сервера DNS. Наличие двух
серверов обеспечивает, если можно так выразиться, избыточность разреше-
ния имени. Например, с первичным сервером что-нибудь случилось, произо-
шел сбой, что бывает очень редко, или же просто первичный
сервер
не в
199
Часть IV. Настройка сервера сети. Иерархическая сеть
состоянии обработать большое количество запросов клиентов. Тогда систе-
ма разрешения имен операционной системы, получив отказ от первичного
сервера DNS, обращается к вторичному.
Например, вам нужно создать вторичный сервер, который будет обслу-
живать
домен
domain.com.
С этой целью внесите следующие изменения
в файл
named.
conf
дополнительного сервера:
zone
«domain.com»
{
type
slave;
file
«domain.com»;
masters { 192.168.1.1; 192.168.1.2;
};
IP-адреса основных серверов DNS вашей сети указываются внутри под-
секции master через точку с запятой. Вторичный сервер, в отличие от
кэширующего, всегда должен иметь тип slave.
9.2.4. Команды управления сервером DNS
Для управления сервером DNS используется программа ndc. Ее можно
использовать с параметрами start, stop, reload, restart:
* Параметр start — запускает сервер.
»
Параметр stop — останавливает сервер.
» Параметр reload — перезагружает файлы зоны, если в них произош-
ли изменения.
» Параметр restart — перезапускает сервер DNS.
9.2.5. Просмотр
DNS-зоны.
Использование nslookup
Программа nslookup используется для просмотра зоны DNS и входит в
состав Linux (и всех вариантов UNIX), а также Windows NT.
В данном случае зону следует понимать как домен и читать «для про-
смотра домена». В зоне содержится различная информация о компью-
терах в домене. Зоны бывают разные: одни содержат информацию о
компьютерах в домене и служат для преобразования имени компью-
тера в IP-адрес и наоборот (см. листинг 10.1), другие содержат инфор-
мацию о корневых серверах — зона
«.».
Последняя зона относится к
типу hint — подсказка. Зоны для разрешения имен обычно имеют тип
master (главный), а зоны вторичных серверов относятся к типу slave
(подчиненный).
200
Глава 9. Система DNS
Просмотр зоны — это просмотр информации, которую содержит зона.
Обычно просмотр зоны разрешается только определенным, доверенным
хостам. Итак, запустите nslookup:
# nslookup
Default Server:
myserver.domain.com
Address: 127.0.0.1
Для того, чтобы получить информацию от сервера, нужно установить тип
запроса set
q=<type>
(или set
type=<type>).
Перечень типов представлен
в табл. 9.2.
Типы запросов Таблица 9.2
Тип
soa
а
аааа
ns
ptr
wks
hinfo
mx
txt
cname
any
Описание
Начало полномочий
Преобразование имени в IP-адрес узла
Отображение
IPv6-aflpeca
узла
Отображение информации о сервере DNS
Преобразование IP-адреса в имя узла
Распространенные службы
Информация о «железе» узла
Информация о почтовых серверах домена
Отображение записи общего назначения
Отображение канонического имени
Отображение всех ресурсных записей
Теперь рассмотрим несколько практических примеров. Например, вы
знаете имя узла —
www.server.com.
Давайте посмотрим, какая информа-
ция будет выведена при указании типа any:
>set q=any
>server.com
Server:
myserver.domain.com
Address: 127.0.0.1
Non-authoritative answer:
server.com
nameserver
=
compl.server.com
server.com nameserver =
comp2.server.com
server.com nameserver =
comp3.server.com
Authoritative answers can be found from:
server.com nameserver =
compl.server.com
server.com nameserver =
comp2.server.com
201
Часть IV. Настройка сервера сети. Иерархическая сеть
server.com nameserver =
comp3.s,erver.
com
compl.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
Теперь получим сведения о зоне и почтовиках.
>server
compl.server.com
Default Server:
compl.server.com
Address:
323.111.200.1
>server.com.
Server:
compl.server.com
Address:
323.111.200.1
server.com internet address =
123.111.200.2
server.com nameserver =
compl.server.com
server.com nameserver =
comp2.server.com
server.com nameserver
=
comp3.server.com
server.com
origin =
comp2.server.com
mail addr =
root.server.com
serial = 19
refresh = 10800 (3 hours)
retry = 7200 (2 hours)
expire = 86400 (1 day)
minimum
ttl
=
3600
(1 hour)
server.com preference =
10,
mail
exchanger
=mail.server.corn
compl.server.com
internet address =
323.111.200.1
comp2.server.com
internet address =
323.111.200.1
comp3.server.com
internet address =
323.111.200.3
mail.server.com
internet address =
323.111.200.17
А сейчас посмотрим информацию о других узлах в этой сети:
Is
server.com.
[comp2.server.com]
server.com.
323.111.200.2
server.com. server =
compl.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
202
Глава 9. Система DNS
jersild 323.111.200.25
compl
323.111.200.1
сотрЗ
323.111.200.3
parasitS
323.111.200.20
www.
press
323.111.200.30
compl 323.111.200.1
www 323.111.200.2
Теперь вам понятно, почему не нужно вообще использовать запись
HINFO? Если при реальной атаке злоумышленник выяснит, какая опе-
рационная система используется на компьютерах в вашей сети, ему бу-
дет проще нанести удар. Я не отрицаю, существует много способов вы-
яснить тип ОС, но зачем же сообщать это самому?
Примечание.
В записи
HINFO
обычно указывается информация
об
аппаратном обеспече-
нии, платформе компьютера и его операционной системе.
Несколько
замечаний:
1. IP-адреса использовались учебные.
2. Не всегда все так просто: иногда настройки сервера DNS и firewall
не разрешат вам просмотреть некоторую информацию о зоне, на-
пример ту, которую мы получали с помощью команды Is server.com.
Разрешить передачу зоны (трансфер зоны) определенным узлам, а зна-
чит, запретить всем остальным, вы можете с помощью директивы
allow-
transfer.
В следующем примере трансфер зоны разрешен узлам 10.1.1.1 и
10.1.2.1. Другими словами, на узлах 10.1.1.1 и 10.1.2.1 можно будет ис-
пользовать команду nslookup
Is
для просмотра зоны.
options
{
allow-
transfer
10.1.1.1;
10.1.2.1;
Вторичный сервер DNS не передает никакой информации о зоне, по-
этому обязательно укажите следующую строку в его файле конфигура-
ции (в секции options):
allow-transfer
{ none; }
203
Часть IV. Настройка сервера сети. Иерархическая сеть
9.2.6.
Оптимизация настроек сервера DNS
Как любой хороший администратор, вы хотите, чтобы ваш сервер DNS
быстро обслуживал запросы клиентов. Но к вашему серверу могут подклю-
чаться пользователи не из вашей сети, например, из сети конкурирующе-
го провайдера. Тогда ваш сервер будет обслуживать «чужих» клиентов. Не-
порядок! Опция
allow-query
в файле
/е
t
с
/named,
con
f позволяет указать
адреса узлов и сетей, которым можно использовать наш сервер DNS:
allow-query {
192.168.1.0/24;
Iqcalhost;
};
В данном примере мы позволяем использовать наш сервер узлам из сети
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»;
9.2.7.
Защита сервера DNS
Настройка и запуск
DNS-
сервера в
chroot-окружении
Из
соображений безопасности рекомендуется запускать все сетевые сер-
висы в так называемом chroot-окружении. Сейчас
поясню,,
что это та-
кое. Создается файловая система, повторяющая структуру корневой фай-
ловой системы, но на этой файловой системе будут только те файлы,
которые необходимы для запуска нашего сетевого сервиса. Взломав
се-
204
Глава 9. Система DNS
тевой сервис и получив доступ к корневой файловой системе, злоумыш-
ленник не сможет повредить всей системе в целом, поскольку он полу-
чит доступ только к файлам, которые принадлежат данному сетевому
сервису. Одни сетевые сервисы могут работать в chroot-окружении, а
другие — нет. Сервис BIND как раз относится к первой группе.
Теперь разберемся, как все это организовывается. Вам не нужно созда-
вать отдельный раздел на диске для каждого сетевого сервиса: нужно только
создать каталог, например, root-dns, в который вы скопируете все файлы,
необходимые для запуска сервера DNS. Потом, при запуске сервиса, бу-
дет выполнена команда chroot для этого сервиса, которая подменит файло-
вую систему. А так как в каталоге root-dns, который станет каталогом /,
имеются все необходимые файлы для работы BIND, то для сервиса запуск
и работа в chroot-окружении будут совершенно прозрачными.
Сразу нужно сказать, что настраивать chroot-окружении мы будем для
девятой версии BIND, поскольку это значительно проще, чем для восьмой
версии. В отличие от восьмой версии, где для настройки chroot-окруже-
ния нужно было копировать все бинарные файлы или библиотеки, необ-
ходимые для запуска BIND, для работы девятой версии достаточно ско-
пировать только файлы конфигурации и зон, обслуживаемых сервером.
Начнем настраивать
chroot-окружение
для нашего сервера DNS. Создадим
каталоги корневой файловой системы сервера DNS — каталоги root-dns:
mkdir -p
/root-dnsI
mkdir -p /root-dns/etc
mkdir -p
/root-dns/var/run/named
mkdir -p /root-dns/var/named
Остановим сервер DNS, если он запущен:
service
named
stop
Переместим файл конфигурации
/etc/named.conf
и файлы зон в ката-
лог /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/*
Нам еще понадобится файл
/etc/localtime
для правильной работы сер-
вера DNS со временем:
ср /etc/localtime /root-dns/etc/
Защитим от редактирования и удаления файл конфигурации
named,
conf:
chattr +i
/root-dns/etc/named.conf
*
205
Часть IV. Настройка сервера сети. Иерархическая сеть
Примечание.
Не забудьте снять атрибут
«i»
перед редактированием файла конфигурации
(chattr -i
/root-dns/etc/named.conf).
Удалим каталоги
/var/named
и
/var/run/named
— они нам больше не
нужны:
rm -rf /var/named/
rm
-rf
/var/run/named/
Добавим в файл
/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 -и named
-t
/root-dns/
5382 ? S 0:00 named -u named -t /root-dns/
5383 ? S 0:00 named -u named -t. /root-dns/
значит, все сделали правильно.
Мы запустили сервер DNS в
chroot-окружение,
но на этом данная глава
не заканчивается.
Использование подписей транзакций. Механизм TSIG
В девятой версии BIND появилась возможность создавать подписи тран-
закций (TSIG — Transaction SIGnatures). Механизм TSIG работает так:
сервер получает сообщение, подписанное ключом, затем подпись прове-
ряется, если она «правильная», сервер отправляет ответ, подписанный тем
же ключом.
Механизм TSIG очень эффективен при передаче информации о зоне,
уведомлений об изменении зоны и рекурсивных сообщений. Согласитесь,
проверка подписи надежнее, чем проверка IP-адреса. Злоумышленник
может вывести вторичный сервер DNS банальной атакой на отказ, и, пока
администратор будет «подымать» вторичный сервер, он заменит свой IP-
адрес адресом вторичного сервера. При использовании TSIG задача зло-
умышленника значительно усложняется: ведь ему придется «подобрать»
128-битный
MDS-ключ,
а вероятность такого подбора стремится к нулю.
206
Глава 9. Система DNS
Итак, приступим к настройке. Остановим сервис named, если он запущен:
service named stop
t
Сгенерируем общие ключи для каждой пары узлов. Общие ключи исполь-
зуются при «общении» первичного и вторичного серверов DNS.
[rootSdns]#
dnssec-keygen
-a
hmac-md5
-b 128 -n
HOST
nsl-ns2
Knsl-ns2.+157+49406
Мы используем алгоритм HMAC-MD5, 128-битное шифрование,
nsl-
ns2
— это имя ключа. После выполнения этой команды будет создан файл
Knsl-ns2.
+176+40946.private.
Откройте его в любом текстовом редак-
торе. Вы увидите примерно следующее:
Private-key-format:
vl.2
Algorithm:
157
(HMAC_MD5)
Key: ms7dfts87Cjhj7FD91k7a3==
Ключ
«ms7dfts87Cjhj7FD91k7a3==»
и будет тем секретом, который бу-
дет передаваться между серверами. Запишите данный ключ на бумаге (ко-
торую потом нужно будет уничтожить) и удалите файлы:
rm
-f
Knsl-ns2.+157+49406.key
rm
-f Knsl-ns2.+157+49406.private
Добавим в файл
/etc/named.conf
(или
/root-dns/etc/named.conf)
пер-
вичного и вторичного серверов DNS следующие строки:
key nsl-ns2 {
algorithm
hmac-md5;
secret
«ms7dfts87Cjhj7FD91k7a3==»;
Укажем
серверу
BIND использовать ключ nsl-ns2. Для этого в файле
named.conf
первичного сервера DNS добавим опцию server. Как это сде-
лать для первичного и вторичного серверов DNS, показано в листингах
9.7 и
9.8.
Листинг 9.7. Фрагмент файла
named.conf
первичного сервера DNS
key nsl-ns2 {
algorithm
hmac-md5;
secret
«ms7dfts87Cjhj7FD91k7a3==»;
207
Часть IV. Настройка сервера сети. Иерархическая сеть
# прописываем вторичный сервер DNS —
192.168.1.2:
server 192.168.1.2 {
keys {
nsl-ns2;
}
;
options {
# разрешаем передачу зоны вторичному серверу DNS
allow-transfer
{ 192.168.1.2;
};
Листинг
9.8.
Фрагмент файла
named.corif
ВТОРИЧНОГО сервера DNS
key nsl-ns2 {
algorithm
hmac-md5;
secret
«ms7dfts87Cjhj7FD91k7a3==»;'
# прописываем первичный сервер DNS —
192.168.1.1:
server 192.168.1.1 {
- '
keys {
nsl-ns2;
}
;
options {
# никому не передаем зону
allow-transfer { none
}
;
Можно также настроить передачу зоны «по ключу». Для этого в файле
конфигурации первичного сервера DNS замените строку
allow-transfer {
192.168.1.2;
};
строкой
allow-transfer { key
nsl-ns2;
}
;
208