Будем считать, что читателям известны основы безопасной работы с DNS, что их серверы DNS должным образом расположены в различных сетях и географических зонах, а в качестве DNS применяется BIND, самый распространенный в Internet сервер имен. В последней версии BIND все недавно обнаруженные бреши в системе безопасности закрыты (дополнительная информация о слабых местах в системе безопасности приведена во врезке «Следи за ошибками в BIND»). Однако построение распределенной системы DNS и использование самой новой версии BIND не дает гарантии, что система надежно защищена от атак. Для дополнительной защиты службы DNS можно использовать базовые функции безопасности BIND: настройки контроля доступа, которые можно выполнять в файле конфигурации DNS. Эти настройки позволяют ограничить рекурсию запросов, разрешить перенаправление запросов с одного DNS на другой, установить два различных DNS на одном компьютере, разрешить или запретить выполнение запросов, запретить соединение с указанными серверами, ограничить пересылку зонной информации списком доверенных серверов, замаскировать название используемой версии BIND. Разумеется, прежде чем применять эти настройки, следует получить представление о существующих версиях BIND и их возможностях.

Версии BIND

Уже долгое время самым популярным методом разрешения имен компьютеров и IP-адресов в Internet является BIND. Организация Internet Software Consortium (ISC) разрабатывает и сопровождает исходные коды BIND, которые можно бесплатно получить на ftp://ftp.isc.org. Всего имеется три ветви BIND. Это BIND 4, BIND 8 и BIND 9. К моменту написания статьи самыми последними версиями были, соответственно, BIND 4.9.8, BIND 8.2.4 и BIND 9.1.3 (прим. ред.: в октябре-ноябре 2001 г. появились версии BIND 8.2.5, BIND 8.3.0-T2A для Alpha, BIND 9.2.0). Тем, кто использует BIND 4, хочу напомнить о сообщении ISC о прекращении поддержки этой версии. Возможно, стоит перейти на BIND 8 или BIND 9.

Начиная с версии BIND 8.2.3 стали поддерживаться такие важные свойства, как динамический DNS (DDNS), DNS Security (DNSSEC), подпись транзакций - Transaction Signature (TSIG), и передача не всех данных зоны, а только обновлений (IXFR). В BIND 8.2.3 и более поздних версиях были исправлены ошибки, в том числе в системе безопасности, опубликованные организацией CERT Coordination Center (CERT/CC). BIND 9.1.3 обладает всеми возможностями BIND 8.2.3 и, помимо этого, поддерживает версию IPv6, мультипроцессорную работу, серверные базы данных независимых разработчиков; обеспечивает лучшую защиту DNSSEC; имеет новую, не зависящую от платформы архитектуру и возможность поддержки нескольких DNS на одном сервере. Новейшие версии BIND стали лучше работать с Windows 2000. Обычно BIND используется на компьютерах с UNIX и Linux, но начиная с BIND 8.2.3 появился код и для Windows 2000 и Windows NT. Во врезке «BIND для Windows 2000 или NT» рассказывается об использовании BIND 8 на этих операционных системах.

Поведение сервера BIND DNS определяется текстовым файлом конфигурации, который в версиях BIND 8 и BIND 9 называется named.conf. Файл конфигурации для BIND 4 называется named.boot. Так как эта версия более не поддерживается, в статье приводится только имя named.conf. Установка базовых параметров контроля доступа в различных секциях (например, options и zone) используется для повышения надежности службы DNS. В Листинге 1 показан пример файла named.conf.

Ограничение или запрет рекурсии

По умолчанию сервер BIND DNS выполняет запросы рекурсивно. С точки зрения безопасности рекурсивные запросы могут вызывать некоторые проблемы. При получении запроса на разрешение имени от клиента или другого DNS-сервера (например, требуется найти IP-адрес сервера www.exampleco.com) BIND DNS-сервер проверяет свой локальный кэш имен и в случае неудачи пытается получить необходимую информацию от других серверов DNS. Если BIND DNS-сервер получит ложную или недостоверную информацию, она все равно будет передана запрашивающему ее клиенту. А также, если BIND DNS-сервер поддерживает пространство имен домена для доступа в Internet и отвечает на запросы, приходящие из Internet, любой компьютер с выходом в Internet может использовать ресурсы этого сервера DNS для опроса других доменов.

В данном случае я рекомендую добавить в секцию options файла na-med.conf специальное условие, в котором указаны пользователи, имеющие право на выполнение рекурсивных запросов. В Листинге 2 приведен пример, в котором компьютеры внутренней сети из диапазона адресов 192.168.10.0/24 и 192.168.11.0/24 могут использовать BIND DNS-сервер для разрешения имен Internet.

Также следует отключить ряд рекурсивных функций сервера BIND DNS, как показано в секции options файла named.conf в Листинге 3. Метка A предваряет условие, запрещающее локальному серверу DNS использовать для разрешения имен другие серверы DNS. Метка B предваряет условие, по которому локальному серверу DNS запрещается выступать в роли транслятора чужих запросов на разрешение имен в записях Name Server (NS). Вместе с тем, отключение рекурсивных функций у Internet-сервера BIND DNS приводит к тому, что внутренние DNS-серверы и пользователи не смогут выполнять разрешение имен Internet при помощи этого сервера.

Разделение DNS

В целях обеспечения безопасности многие организации стремятся скрыть свою внутреннюю инфраструктуру сети. Особенно это касается имен компьютеров и их IP-адресов из локальной сети, которые находятся в базе серверов DNS. С другой стороны, служба DNS должна выполнять разрешение имен внешних Internet-серверов (например, почтовых и Web-серверов). Метод, который позволяет это сделать и поделить службу DNS на внешнюю и внутреннюю, называется разделение (split) DNS.

При установке сервера в качестве носителя раздельной DNS внутренняя служба DNS выполняет для внутренних пользователей разрешение имен и IP-адресов серверов intranet и Internet. Внешняя служба DNS отвечает на приходящие из Internet запросы о внешних именах и адресах компьютеров организации. Разделение DNS можно выполнить двумя способами, в зависимости от используемой версии BIND.

Рисунок 1. Пример разделенного DNS.

Разделение DNS в версии BIND 8. На Рисунке 1 показан первый способ разделения DNS, при котором внутренние серверы DNS размещаются в intranet за сетевым экраном (firewall), а внешние серверы DNS устанавливаются в демилитаризованной зоне (DMZ) или в Internet. При этом только внутренние клиенты имеют доступ к внутреннему серверу DNS, хранящему адресную информацию о компьютерах внутренней сети. Запросы внешних клиентов о доменных Internet-именах и адресах организации выполняются внешним DNS-сервером. Любые запросы, идущие из Internet в intranet, запрещены. Если на внутренний DNS-сервер приходит запрос о разрешении имени Internet (например, www.win2000mag.ru), которого нет в локальном кэше, то рекурсивный запрос отправляется на внешний DNS-сервер. Вместо полного запрещения рекурсии на внешнем сервере DNS, следует разрешить только запросы, исходящие из внутренней сети, как показано в Листинге 2. Внешний сервер получает от первичного сервера DNS адрес сервера DNS домена win2000mag.ru и выполняет с его помощью разрешение имени www.win2000mag.ru.

Чтобы на внутреннем DNS-сервере разрешить перенаправление запросов, следует модифицировать секцию options файла named.conf, как показано в Листинге 4. Метка A в Листинге 4 предваряет правило, по которому внутренние серверы DNS всегда пересылают запросы о внешних доменах на один из внешних DNS, указанных после метки B.

Сервер BIND DNS желательно расположить внутри DMZ, за сетевым экраном, как показано на Рисунке 1. Хороший сетевой экран способен обнаруживать и отражать такие атаки, как отказ в обслуживании Denial of Service (DoS). Внешний сетевой экран не должен закрывать 53-й порт UDP, чтобы запросы из Internet доходили до внешнего сервера DNS.

Разделение DNS в версии BIND 9. Второй способ разделения DNS основан на новой возможности девятой версии BIND, позволяющей разместить внутренний и внешний DNS на одном компьютере. Предположим, некая компания Exampleco поддерживает внутренний домен exampleco.com и внешний домен exampleco.com. Файл зоны внутреннего домена содержит имена внутренних компьютеров и их IP-адреса, а внешний домен имеет отдельный файл зоны, содержащий имена внешних компьютеров и их IP-адреса. Обычный DNS-сервер смог бы использовать лишь один файл зоны для домена exampleco.com. BIND 9 позволяет единственному DNS работать с несколькими файлами зон для одного и того же доменного имени. Такой DNS умеет отличать внутренних клиентов от внешних по их IP-адресам и использовать для ответов соответствующие файлы зон.

Приведенный в Листинге 5 пример конфигурации секции View файла named.conf определяет файлы внутренней и внешней зоны домена exampleco.com для сервера BIND 9. Сервер BIND DNS выполняет запросы клиентов в том порядке, в котором строки конфигурации размещены в секции View. Таким образом, добавляя новую строку в секцию View, следует обращать внимание на то, какое место она занимает по отношению к другим строкам-утверждениям этой секции. Первое утверждение относится к внутреннему домену, второе - к внешнему. Файл зоны внутреннего домена называется internal.exampleco, а файл зоны внешнего домена - exter-nal.exampleco. Как только сервер DNS получает запрос, он сначала пытается определить, попадает ли IP-адрес клиента в диапазон, отмеченный в Листинге 5 идентификатором A. Если это так, то DNS-сервер считает, что запрос пришел из внутренней сети, и возвращает ответ на основании данных внутреннего домена. Если это не так, то DNS-сервер определяет, попадает ли IP-адрес клиента в диапазон, отмеченный идентификатором B. В нашем примере идентификатор B содержит условие с ключевым словом any (любой), поэтому сервер возвращает ответ с информацией о внешнем домене любому клиенту, чей IP не попадает в список внутренних адресов.

Чтобы использовать данную возможность, требуется расположить сервер BIND 9 на компьютере, доступном для клиентов как внутренней, так и внешней сети. Такой компьютер может служить сетевым экраном между Internet и intranet или сервером в демилитаризованной зоне DMZ. Хорошая DMZ имеет как внутренний сетевой экран, так и внешний. Внутренний экран открывает выходящий порт UDP 53 для DNS-запросов из внутренней сети, а внешний экран открывает для запросов входящий порт UDP 53.

Ограничение доступа

Для обеспечения безопасности серверов DNS можно внести еще несколько дополнений в настройки BIND и разрешить внутреннему серверу BIND отвечать только на те запросы, которые приходят с указанных IP-адресов. В примере из Листинга 6 сервер обрабатывает запросы только от клиентов из сетей 192.168.10.0/24 и 192.168.11.0/24.

Что касается внешнего сервера BIND DNS, то ограничение на IP-адреса использовать очень трудно, так как нельзя заранее сказать, какие клиенты обратятся к серверу. Зато очень просто в настройках named.conf запретить доступ для тех клиентов и серверов, которые явно представляют опасность (имеется в виду, что их IP-адреса известны). Например, если известно, что кто-то пытается атаковать сервер DNS из сети 172.36.0.0/16, можно ввести в конфигурационном файле blackhole условие и запретить запросы из этой сети, как показано в Листинге 7. Если известен адрес нежелательного сервера DNS (например, 172.36.2.2), то для предотвращения соединения с ним можно ввести условие server (см. Листинг 8).

В Листинге 9 приведено описание секции options файла named.conf, в соответствии с которым только конкретным серверам DNS (например, вторичным серверам DNS с адресами 192.168 .10.10 и 198.168.11.10) разрешается копировать информацию о зоне указанного сервера DNS (например, первичного DNS-сервера). Если зона, поддерживаемая сервером BIND DNS, является динамической, то в настройках файла named.conf в секции определения зоны можно указать, каким клиентам (например, серверам DHCP и компьютерам Windows 2000) разрешается динамически обновлять зону. В Листинге 10 приведен пример конфигурации, разрешающей системам из сети 192.168.10.0/24 обновлять динамическую зону для exampleco.com.

Маскировка версии BIND

Сервер, на котором эксплуатируется версия BIND с известными, но не устраненными брешами в системе безопасности, является лакомой добычей для злоумышленников. Если администратору некогда обновлять версию сервера до BIND 8.2.3, или более поздней, или до версии BIND 9.x, следует хотя бы скрыть номер текущей версии. В настройках секции options можно указать номер самой последней версии BIND. В Листинге 11 приведен пример маскировки старой версии BIND. Злоумышленник будет считать, что установлена BIND 8.2.4, если попытается узнать номер версии с помощью команды Dig.

dig @ chaos version.bind txt

(О программе Dig для Windows 2000 и NT можно прочитать во врезке «Охота за информацией о DNS».)

От простого к сложному

Чтобы еще выше поднять планку защиты службы DNS в Internet, специалисты компании ISC включили в код BIND протокол Internet Engineering Task Force (IETF) Internet DNS security. В следующей статье будут рассмотрены такие функции безопасности BIND, как DNSSEC и TSIG, и даны рекомендации по их применению для усиления защиты службы DNS.

Тао Чжоу - редактор журнала Windows NT Magazine и инженер, работающий в сфере Internet. Имеет сертификаты MCSE и Master CNE. С ним можно связаться по адресу: taoz@ix.netcom.com.

Следи за ошибками в BIND

В начале этого года Координационный центр по проблемам безопасности в Internet - CERT/CC, основанный правительством США, опубликовал отчет о слабых местах в системе безопасности BIND. Это касается всех версий до BIND 8.2.3. «Дыры» в системе безопасности позволяли злоумышленникам получить доступ к серверам BIND, проводить атаки типа «отказ в обслуживании» (Denial of Service, DoS), изменять информацию о расположении Web-сайтов, перенаправлять потоки электронной почты. Отчет комиссии CERT/CC можно прочитать в статье «CERT Advisory CA-2001-02 Multiple Vulnerabilities in BIND» по адресу: http://www.cert.org/ advisories/ CA-2001-02.html. Компания ISC - разработчик программного обеспечения BIND - опубликовала список известных брешей в системе безопасности, который можно найти по адресу: http://www.isc.org/ products/ BIND/ bind-security.html.

Комиссия CERT/CC настоятельно рекомендует всем организациям, использующим BIND, срочно обновить версии BIND до 8.2.3 или более поздних или версии 9.1.0, в которых все известные лазейки закрыты. В службе DNS компании Microsoft таких «дыр» в системе безопасности нет.

Версия BIND для Windows 2000 или NT

ISC поставляет исходные коды BIND на языке C для всех основных платформ (например, Windows NT и Linux). Можно самостоятельно откомпилировать BIND для выбранной платформы или использовать готовые дистрибутивы. Например, есть готовые установочные файлы BIND 8.2.4 для Windows 2000 и NT. Дистрибутив BIND 8.2.4 можно получить по адресу: http://www.isc.org/ products/ BIND/ bind8.html. Далее следует разместить его в пустом каталоге компьютера Windows 2000 или NT, который планируется использовать в качестве сервера BIND DNS, и выполнить программу BINDInstall, чтобы установить BIND в качестве службы. BINDInstall размещает необходимые для работы BIND файлы в каталоге C:winntsystem32dnsin. Исключение составляет библиотека libbind.dll, которая размещается в C:winntsystem32.

Перед запуском службы BIND следует создать в каталоге C:winntsystem32dnsetc конфигурационный файл named.conf. Это можно сделать в любом текстовом редакторе, например Notepad. Файлы описаний зон forward- и reverse-lookup для поддерживаемых сервером BIND доменов могут располагаться в любых каталогах компьютера. Единственное требование - указать путь к этим каталогам в файле named.conf. После любых изменений в named.conf или файлах зон, службу BIND требуется перегрузить, чтобы изменения были внесены в кэш. Разумеется, нет нужды перезапускать динамический DNS после того, как его клиент - компьютер Windows 2000 или Windows 2000 DHCP, сервер или программа Nsupdate - обновляет запись. После создания и настройки named.conf следует запустить службу BIND. Для этого можно воспользоваться BINDCtrl (программой с графическим интерфейсом для управления службой BIND, которая может быть запущена из командной строки) для управления службой (например, запуска, остановки, перезагрузки, вывода информации из базы данных, формирования запросов для журнального файла).

К моменту написания этой статьи ISC еще не имел готовых дистрибутивов BIND 9 для всех ведущих операционных систем (информацию можно получить по адресу: http://www.isc.org/ products/ BIND/ bind9.html). Поэтому требуется UNIX-система с компилятором ANSI C, например, таким, как свободно распространяемый компилятор GNU Compiler Collection (на сайте http://www.gnu.org/ directory/ gcc.html), чтобы можно было самостоятельно создавать исполняемые файлы BIND 9, конфигурационные и make-файлы (по данным ISC, сервер BIND 9.2.0 RC2 был успешно протестирован для Windows 2000 и NT).

Охота за информацией о DNS

Для поиска имен в базе DNS администраторы UNIX обычно используют программы Nslookup и Dig (Dig похожа на Nslookup, но не работает в интерактивном режиме). В этом году ISC включила Dig в состав версий BIND 8.2.3 и более поздних для Windows 2000/NT. Программа dig.exe использует библиотеку libbind.dll из комплекта BIND, поэтому копия файла libbind.dll должна находиться в одном каталоге с dig.exe или в каталоге, входящем в маршрут поиска на Windows 2000 или NT.

В командной строке Dig можно указать имя опрашиваемого сервера DNS. Если этого не сделать, то используется сервер DNS, указанный в настройках свойств TCP/IP систем Windows 2000/NT или в файле resolv.conf, расположенном в C:winntsystem32driversetc. Это стандартный файл из конфигурации UNIX, служащий для описания серверов DNS, используемых локальным клиентом. В Листинге А показан пример файла resolv.conf.

В файле resolv.conf может быть указано не более трех серверов имен. Обычно в resolv.conf указывается строка с доменным суффиксом и строка, задающая порядок поиска в доменах. Поиск в доменах осуществляется в том случае, если выполняется разрешение по имени хоста, а не по полному доменному имени (FQDN). К сожалению, выяснилось, что Dig в BIND 8.2.4 для Windows 2000 или NT не поддерживает эту возможность. Базовый синтаксис команды Dig следующий:

dig [@] [] []

Например, команда

dig @24.30.163.11 www.microsoft.com any

предписывает Dig использовать DNS-сервер 24.30.163.11 для разрешения имени www.microsoft.com. Тип заданного запроса any (любой) означает поиск информации о www.microsoft.com вне зависимости от типа ресурсной записи DNS Resource Record (RR). (dig -h выводит полный синтаксис команды.) На Рисунке A приведен результат выполнения команды Dig, содержащий массу полезной информации.

Метка A указывает на версию Dig и введенные переключатели командной строки. Метка B указывает, был ли запрос рекурсивным, как в нашем случае. Метка C показывает статус запроса. В нашем запросе - статус NOERROR; это говорит об успешном выполнении запроса (статус SERVFAIL означал бы, что сервер не смог найти нужное имя). Метка D предваряет секцию Query, содержащую количество отправленных запросов, и еще несколько секций (т. е. Answer, Authority и Additional), содержащих записи о принятых ответах.

В секции Answer размещена искомая DNS информация, полученная из записей RR в результате запроса. Метка E подчеркивает, что имя www.microsoft.com является записью CNAME, указывающей на www.microsoft.akadns.net. Из этого следует, что Web-сайт Microsoft размещается на сервере akadns.net. Метка E указывает на то, что информация, полученная о www.microsoft.com из кэша сервера DNS, будет находиться там еще как минимум 13 мин и 46 с. В секции Authority перечислены серверы DNS, поддерживающие информацию о домене microsoft.com. В секции Additional могут быть приведены IP-адреса серверов из секции Authority. Метка F показывает, сколько времени выполнялся запрос, какой компьютер к какому серверу DNS обращался, когда выполнялся запрос (день недели, дата, время), каков размер отправленного и принятого сообщений.