Служба DNS является одной из старейших и наиболее часто используемых в Internet и вместе с тем одним из самых непонятных и плохо настраиваемых компонентов. Служба DNS имеет мощный механизм работы с иерархической распределенной базой данных, однако на эффективность этого механизма сильно влияет правильность его настроек. От того, как разработана инфраструктура DNS в организации, будет в огромной степени зависеть как производительность сети в целом, так и ее защищенность.

Как оптимально настроить службу DNS в масштабах предприятия? Ключ к построению эффективной и защищенной инфраструктуры DNS, особенно в крупных сетях, состоит в ролевом разделении серверов DNS, при котором каждый сервер решает свой набор задач. Это идеальный случай, при котором каждый сервер имеет специфическую конфигурацию, функции и зону. Далее в статье будет описано, как можно реализовать данный подход.

Функциональное назначение серверов DNS

Прежде чем мы обсудим разделение ролей, следует рассмотреть функции, выполняемые сервером DNS. К ним относятся авторизованные ответы (authoritative responses), рекурсия (recursion), перенаправление (forwarding) и кэширование (caching).

Авторизованные ответы. Наиболее типичной функцией сервера DNS является выдача авторизованного ответа на клиентский запрос в процессе разрешения имени хоста. При этом сервер, по существу, гарантирует, что данный ответ является окончательным и дальнейший поиск не требуется. Регистрируя свой домен в Internet, требуется также зарегистрировать серверы службы имен, авторизованные в домене. Эти серверы всегда будут давать авторизованные ответы по домену. Поэтому необходимо, чтобы в каждом домене имелся соответствующий сервер такого типа.

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

Процесс рекурсии начинается с обращения к одному из корневых серверов (root server), размещенных в Internet. Предположим, например, что браузер вашего компьютера пытается найти IP-адрес, соответствующий имени http://www.osp.ru/adm/edit/www.example.com. Если сервер DNS сам не имеет этих данных, он запросит их у одного из корневых серверов. Корневой сервер тоже вряд ли что-либо «знает» о запрашиваемом имени хоста, однако ему известен IP-адрес сервера, обслуживающего имена верхнего уровня .com, соответственно он возвращает ссылку на этот сервер. Далее ваш сервер DNS обращается к серверу DNS домена .com, который, вероятно, также не имеет сведений об интересующем вас хосте, но у него есть данные о DNS-сервере, обслуживающем домен example.com, поэтому он возвращает IP-адрес этого сервера. Что касается DNS-сервера example.com, то он является авторизованным для данного домена, поэтому может дать авторизованный ответ на запрос адреса http://www.osp.ru/adm/edit/www.example.com.

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

Перенаправление. Как правило, запросы, посылаемые сервером DNS, не являются рекурсивными, однако здесь есть исключение. Речь идет о том случае, когда сервер DNS сконфигурирован для перенаправления запросов. Сервер перенаправления принимает запросы от клиентов и переадресует их другому серверу DNS как рекурсивные запросы, в результате чего все действия по поиску авторизованного ответа будут выполняться этим сервером DNS. Механизм перенаправления запросов является важным компонентом инфраструктуры DNS, поскольку это позволяет упростить конфигурацию службы DNS на клиентах, обеспечить централизованную обработку запросов DNS, а также предоставить возможность работы с теми сетями, к которым клиент может не иметь прямого доступа.

Кэширование. Сервер DNS также может использоваться в целях кэширования. В ходе поиска авторизованного ответа сервер DNS обменивается данными со всей иерархией DNS и таким образом получает сведения о глобальной инфраструктуре службы имен. Для ускорения обработки будущих запросов сервер сохраняет эту информацию вместе с данными о разрешенных им именах хостов. Другие серверы в иерархии DNS также хранят аналогичные данные, что делает всю инфраструктуру в целом намного более эффективной. Кэширование может существенно сократить время отклика на запрос и значительно снизить общий сетевой трафик.

Например, если серверу DNS организации уже известны IP-адреса серверов DNS вышеупомянутого домена example.com, то ему нет необходимости запрашивать какие-либо внешние серверы, что позволяет снизить нагрузку как на корневые серверы, так и на другие серверы высших уровней иерархии.

Основные роли DNS

Исходя из понимания основных аспектов работы DNS становится ясно, что в организации эта служба может играть несколько ролей. При этом наиболее распространенная ошибка, допускаемая сетевыми администраторами, состоит в том, что каждый существующий в сети сервер DNS конфигурируется сразу под все эти роли. О типичных уязвимых местах стандартных конфигураций DNS рассказано во врезке «Уязвимые места DNS». Предлагаемый подход с разделением ролей поможет предотвратить или по крайней мере минимизировать возможности проведения различных атак.

На этапе проектирования инфраструктуры DNS следует сразу же стратегически разделить серверы DNS на три основные группы в соответствии с возлагаемыми на них ролями. При этом в целях выравнивания нагрузки и обеспечения отказоустойчивости для каждой роли следует предусмотреть как минимум два сервера. Три основные роли, которые могут выполнять серверы DNS, перечислены ниже.

  • Публикующий сервер (Advertiser). Сервер DNS, имеющий связь с Internet и предоставляющий информацию об общедоступных серверах сети компании.
  • Мастер внутреннего домена (Internal domain master). Данный сервер, обычно интегрированный с Active Directory (AD), предоставляет авторизованные ответы по разрешению имен хостов локального домена.
  • Сервер разрешения имен (Resolver). Эти серверы DNS размещены централизованно и реализуют функции перенаправления и кэширования.

При реализации подхода, основанного на разграничении серверов в соответствии с этими тремя ролями, потребуется выполнить специальные настройки, повышающие степень защищенности каждой из ролей.

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

Настройка публикующих серверов

Публикующие серверы позволяют всем внешним клиентам разрешать имена общедоступных хостов, таких как серверы Web и FTP, а также почтовые серверы. Публикующие серверы чаще всего являются объектами атак, поэтому необходимо тщательно отбирать информацию, которую они могут предоставлять. Здесь должны храниться сведения только об общедоступных хостах, но не должно быть никакой информации об IP-адресах внутренней сети. Кроме того, публикующие серверы следует настраивать так, чтобы они разделяли информацию о зонах только с другими публикующими DNS-серверами сети предприятия.

Многие организации пользуются услугами своих Internet-провайдеров для размещения публичных записей DNS, и в этом случае возможность управления конфигурацией DNS практически отсутствует. Однако администраторы, самостоятельно обслуживающие свои публичные серверы DNS, могут воспользоваться утилитой DNScmd из пакета Support Tools (файл Support.cab). Данный файл находится на установочном компакт-диске Windows Server 2003 в каталоге support ools. Первым делом следует настроить публикующий сервер на прослушивание единственного IP-адреса. Предположим, ваш публичный сервер DNS имеет адрес 192.0.34.166. Тогда надо использовать следующую команду:

dnscmd resetlistenaddresses 192.0.34.166

Далее нужно отключить рекурсию, для того чтобы сервер DNS отвечал на запросы только внутри собственной зоны. Для этого применяется команда:

dnscmd /Config /NoRecursion 1

На следующем шаге требуется сделать сервер DNS корневым. Это реализуется путем добавления корневой зоны. Если сервер является корневым, то он предполагает, что имеет всю необходимую информацию и не будет пытаться обращаться к другим серверам DNS. Соответствующая команда выглядит следующим образом:

dnscmd /ZoneAdd . /Primary

Поскольку в данном случае сервер DNS имеет подключение к общедоступной сети, я рекомендовал бы выполнить еще несколько настроек, чтобы предотвратить возможность атак. Во-первых, с помощью приведенной ниже команды следует запретить серверу DNS использовать протокол RPC:

dnscmd /Config /RPCProtocol 0

Во-вторых, если имена всех зон состоят только из символов ANSI (т. е. не содержат специальных символов и букв нелатинского алфавита), тогда можно настроить сервер имен так, чтобы он обрабатывал лишь имена, совместимые с RFC. Для этого используется команда:

dnscmd /Config /NameCheckFlag 0

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

dnscmd /Config /AddressAnswerLimit 5

Настройка мастеров внутреннего домена

Мастерами внутреннего домена являются серверы DNS, обрабатывающие запросы на разрешение имен в локальных доменах AD. Для того чтобы иметь возможность более детального управления параметрами безопасности и улучшения работы механизмов репликации по сравнению с теми, которые мы имеем после установки системы, следует настроить эти серверы (если это не было сделано сразу) как зоны, интегрированные в AD. Данные серверы являются авторизованными только для своих зон, никаких попыток разрешения имен в «чужих» зонах они предпринимать не будут.

Первое, что следует сделать в процессе настройки мастера домена, это отключить рекурсию, как для публикующего сервера. Затем нужно сделать данный сервер корневым, исключив таким образом попытки его обращения к другим серверам DNS:

dns /zoneadd . /Primary

Настройка сервера разрешения имен

Теперь рассмотрим, как настраиваются серверы разрешения имен. Такие серверы должны иметь центральное размещение, причем, с одной стороны, к ним должны иметь доступ клиенты внутренней сети, а с другой стороны, они должны иметь возможность подключения к другим серверам DNS. В этом случае первое, что следует сделать, — это убедиться в том, что сервер разрешения имен прослушивает только IP-адреса внутренней сети. Например, если сервер разрешения имен должен прослушивать адрес 192.168.0.54, можно воспользоваться следующей командой:

dnscmd resetlistenaddresses
192.168.0.54

Обратите внимание, что этот IP-адрес, а также те адреса, которые аналогичным образом задаются для дополнительных серверов разрешения имен, будут теми самыми адресами, которые необходимо указывать на каждом клиенте в настройках протокола TCP/IP в качестве серверов DNS (в разделе «Свойства TCP/IP»).

Вторая задача состоит в том, чтобы настроить каждый сервер разрешения на выполнение переадресации запросов разрешения имен внутри домена на те серверы, которые являются мастерами домена. Например, если имя домена example.corp, а серверы-мастера домена имеют адреса 192.168.0.11 и 192.168.0.12, то соответствующая команда настройки будет выглядеть так:

dnscmd /zoneadd example.corp /forwarder
192.168.0.11 192.168.0.12 /slave

Здесь параметр /slave предписывает серверу разрешения имен не предпринимать самостоятельных попыток поиска адреса, если сервер DNS не отвечает. Поскольку в данном случае мы имеем в виду серверы DNS внутреннего домена предприятия, то, соответственно, они не должны выполнять поиск где-либо еще.

Далее нужно настроить сервер перенаправления так, чтобы он обрабатывал все остальные запросы к DNS. Этот сервер должен быть внешним сервером DNS, например тем, который предоставляет Internet-провайдер. Так, если серверы DNS Internet-провайдера имеют IP-адреса 192.14.9.22 и 192.15.9.23, можно воспользоваться следующей командой:

dnscmd /resetforwarders 192.14.9.22 192.15.9.23

Если в организации используется жесткая политика брандмауэров, то администратор, вероятно, не захочет предоставлять серверу разрешения имен возможность выполнять рекурсивный поиск по собственной инициативе. Поэтому, если нужно сделать так, чтобы серверы разрешения имен могли обращаться лишь ко внешним серверам DNS, следует добавить в только что описанную команду параметр /slave.

Для того чтобы проверить правильность выполненных настроек, следует указать в параметрах сетевого адаптера компьютера адреса этих серверов DNS. Затем с помощью команды Nslookup нужно попытаться выполнить поиск, задавая различные имена локальных и публичных хостов.

Правильный подход к планированию

Если вы воспользуетесь рекомендациями, приведенными в данной статье при планировании функций серверов DNS, то убедитесь, что инфраструктура DNS вашей организации стала более эффективной и защищенной, а время ее безотказной работы увеличилось. При этом у вас появятся возможности масштабирования данной структуры практически до любых размеров в соответствии с требованиями предприятия.

Марк Барнетт (mburnett@xato.net) — независимый программный консультант по безопасности и автор, специализирующийся на безопасности Windows. Обладатель сертификата IIS MVP и автор нескольких книг, в том числе Perfect Passwords и Hacking the Code (издательство Syngress)

Уязвимые места DNS

Если служба DNS настроена неправильно, то она, как и любая другая сетевая служба, может создать благоприятную ситуацию для различных атак. Одним из самых типичных примеров уязвимости, обусловленной этой службой, является сервер DNS, предоставляющий излишнюю информацию. Следует понимать, что для злоумышленника может быть полезен буквально каждый бит информации о сети, поэтому крайне важно минимизировать данные, предоставляемые во внешние сети. Обычно первое, что пытается сделать злоумышленник, — это построить карту сети предприятия, и эти данные он может получить от сервера DNS. Например, он может осуществить передачу зоны на какой-то свой сервер и таким образом получить информацию обо всех IP-адресах и именах хостов данной зоны.

Хотя по умолчанию серверы DNS блокируют возможность передачи зон, это не может стать серьезным препятствием для сбора данных о сети злоумышленниками. Они могут использовать и другую методику, а именно генерировать в огромном количестве запросы имен хостов, что приводит к нарушениям работы сетевой инфраструктуры. Здесь единственная мера защиты состоит в том, чтобы свести к минимуму информацию, хранящуюся на публичных серверах DNS.

Еще одним типичным приемом, применяемым для атак серверов DNS, является атака типа «отказ в обслуживании» (Denial of Service, DoS). В этом случае сервер DNS перегружается лавинообразно нарастающим трафиком, при этом злоумышленник задействует все его доступные ресурсы, в результате чего сервер просто перестает отвечать на запросы. Но если у вас имеется несколько серверов в отдельной сети, причем роли их четко разграничены, это поможет существенно уменьшить ущерб от подобных атак. В этом случае атаки на внешние серверы никак не повлияют на механизмы разрешения имен во внутренней сети предприятия. Существует и такая опасность, как «засорение кэша DNS» (DNS cache poisoning). В этом случае злоумышленник «обманывает» сервер DNS, записывая в кэш некорректные данные DNS. Это позволяет ему перенаправлять запросы пользователей не на тот хост, который им нужен, а на какой-то другой. Данная ситуация весьма благоприятна для различных атак. Служба DNS, реализованная в Windows, имеет специальные механизмы для блокирования подобных атак, однако эти механизмы несовершенны, поэтому будем надеяться, что проведенные исследования позволят в дальнейшем улучшить их. Таким образом, самый эффективный способ защиты от подобных атак состоит в том, чтобы предотвратить доступ злоумышленников к кэширующим серверам DNS.

И наконец, не следует сбрасывать со счетов ситуацию, когда злоумышленник может физически подобраться к серверу DNS и получить доступ или даже модифицировать имеющиеся на нем данные. Поэтому, физически изолируя серверы DNS, мы также снижаем вероятность того, что какой-либо сервер или его роль будут скомпрометированы.