Издательский дом ООО "Гейм Лэнд"СПЕЦВЫПУСК ЖУРНАЛА ХАКЕР #51, ФЕВРАЛЬ 2005 г.

Бронебойный DNS

Антон Карпов, toxa@cterra.ru

Спецвыпуск: Хакер, номер #051, стр. 051-044-1


Поднимаем безопасный и функциональный dns-сервер

Ты уже прочитал (или еще прочтешь) статью о настройке почтового сервера в этом номере. Как ты уже, наверное, догадался, почте, как и другим сетевым сервисам, жить без DNS проблематично. Доменная система имен - основа всей сети, поэтому обустроить свой "именной" уголок безопасно и корректно - одна из основных задач администратора.

djbdns - три в одном

Знакомься: djbdns - полноценная реализация для работы с DNS от Дэна Бернштейна. Как нельзя лучше подходит для решения именно этой проблемы. Итак, настройки требует DNS-сервер, который предоставлял бы внешним машинам информацию о нашей зоне, а клиентам Сети - информацию об адресах машин в интернете. Если ты имел дело с BIND, то знаешь, что он "и швец, и жнец, и на дуде игрец", то есть в зависимости от настроек может и держать зону, и играть роль кеширующего сервера/форвардера, и отдавать зону slave-серверам. Это не самое элегантное решение, что доказывает богатая история уязвимостей BIND и постоянные проблемы с его корректной настройкой у начинающих администраторов. Как же должно быть? Так, как в пакете djbdns, который представляет собой набор из трех основных программ: tinydns (не умеет ничего кроме как обслуживать зоны); dnscache (отвечает лишь за кеширование и разрешение внешних имен); axfrdns (занимается отдачей зон tinydns'a slave-серверам, точнее named'ам, так как для распространения зоны между двумя tinydns djb предлагает другие механизмы). Почему все так сложно? Эти три программы функционируют независимо друг от друга, и не существует даже теоретической возможности, например, некорректно настроить DNS-сервер так, чтобы он отвечал на рекурсивные запросы (такие сервера часто используются для DDoS-атак), или удаленно получить контроль над кешем (доступный для соединений извне tinydns не работает с кешем).

Будем считать, что у нас в распоряжении вторичный DNS-сервер BIND. Разгуляемся по полной настроив dnscache, tinynds и axfrdns. Если ты когда-нибудь имел дело с BIND, то постарайся забыть все, что ты знал о нем :). Если нет - тем лучше для твоей психики: named, как правило, слушает на всех доступных интерфейсах, принимая запросы на внутреннем интерфейсе от клиентов для разрешения имен внешних машин, а на внешнем интерфейсе - от серверов для предоставления информации о машинах в своей зоне и трансфера зоны вторичным серверам. Разбивая систему на функциональности, получаем следующую картину: на внутренний интерфейс приходят исключительно пользовательские запросы. Значит, на него нужно повесить dnscache, который будет резолвить адреса внешних машин и кешировать результат.

На внешний интерфейс приходят запросы к нашей зоне как на разрешение имен, так и на трансфер. Значит, на него повесим tinydns, который понятия не имеет, что такое рекурсивные запросы, и отвечает только на запросы своей зоны, и axfrdns, который будет отдавать зону определенным slave-серверам. В качестве ОС для построения DNS-сервера избираем FreeBSD. Но о вкусах не спорят. Все нижеизложенные инструкции легко можно применить и к Linux/OpenBSD/NetBSD и т.д.

Содержание  Вперед на стр. 051-044-2