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

В Windows Server 2008 R2 включены мощные технологии, которые могут дать такую уверенность. Давайте сначала кратко пройдемся по основам DNS, а потом посмотрим, какие возможности открывают перед нами новые функции, такие как DNS Security Extensions (DNSSEC), DNS Devolution и DNS Cache Locking.

Недостатки обычной службы DNS

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

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

Ответ сервера DNS не содержит контрольную сумму, необходимую, скажем, для проверки неизменности содержания ответа. Таким образом, при атаках типа man-in-the-middle злоумышленник может изменить данные, передаваемые клиенту. Также имейте в виду, что большинство ответов DNS приходит с неавторизованных серверов DNS. Точнее, они приходят с промежуточных серверов DNS, которые кэшируют обработанные запросы и в дальнейшем выдают информацию из кэша. Многие хакеры вносят изменения в кэш серверов DNS, наполняя его ложными записями.

DNSSEC для всех

Технология DNS Security Extensions (DNSSEC) представляет собой расширение стандарта DNS, описанное в документах RFC 4033, 4034 и 4035, которое было реализовано компанией Microsoft при создании серверной роли Server 2008 R2 DNS. Предыдущая версия технологии DNSSEC была описана в документе RFC 2535, который в дальнейшем был заменен документами RFC, указанными выше. Системы Windows Server 2003 и даже Server 2008 несовместимы с реализацией данной технологии на платформе Server 2008 R2.

По сути дела, DNSSEC обеспечивает целостность инфраструктуры DNS с помощью технологий, проверяющих подлинность получаемых данных, включая авторизованные ответы типа denial-of-existence. Верификация осуществляется с помощью технологии шифрования с открытым ключом, которая позволяет использовать цифровые подписи в ответах DNS. Успешная проверка подписи означает, что данные подлинные и им можно доверять. Цифровая подпись генерируется на основе закрытого ключа зоны DNS (он держится в секрете) и содержания записи и может быть проверена с помощью открытого ключа. Если пакет был создан подозрительным источником, проверка его подписи закончится неудачно, а если пакет был изменен, то его цифровая подпись не будет соответствовать содержанию.

В реализации шифрования с открытым ключом помогают новые типы записей DNS: DNS Public Key (DNSKEY), представляющий собой контейнер для открытого ключа зоны; Resource Record Signature (RRSIG), содержащий цифровую подпись ответа сервера; Delegation Signer (DS), используемый для обмена между дочерней и родительской зоной, при условии что для них разрешены механизмы DNSSEC; и Next Secure (NSEC), позволяющий обрабатывать проверенные записи denial-of-existence. NSEC использует эффективный механизм, при котором в ответ на запрос с несуществующим именем возвращается предшествующая запись (в алфавитном порядке) и уведомление о следующей безопасной записи. Например, если в зоне DNS описаны записи A и E, а вы запрашиваете запись С, то на выходе получите ответ A NSEC E с цифровой подписью. Таким образом система проинформирует вас, что запрашиваемой записи не существует, так как между A и E других записей не обнаружено.

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

В идеале данная иерархия инфраструктуры открытых ключей PKI должна быть автономной в рамках иерархии DNS, при условии, что корневой зоне (".") данной иерархии доверяют все клиенты и для зоны разрешено использование механизмов DNSSEC. В этом случае корневая зона сможет подписывать имена доменов верхнего уровня (например, com, net, org), которые в свою очередь смогут подписывать подчиненные домены (например, company.com), таким образом создается путь доверия. Это означает, что клиентам достаточно доверять только корневой зоне, а она уже используется для аутентификации остальных дочерних зон. В примере, отраженном на рисунке, для зоны. net включены механизмы DNSSEC, поэтому любая дочерняя зона, подписанная родительской зоной, будет доверенной для всех клиентов DNS, доверяющих зоне. net.

 

Рисунок. Настройка якоря доверия

На сегодня данная схема работает для обычных сертификатов инфраструктуры PKI. На основной массе компьютеров настроено доверие определенным корневым центрам сертификации, размещенным в Интернете, таким как VeriSign, Thawte и Equifax. Данные центры предоставляют сайтам сертификаты, подписанные корневыми центрами сертификации. Клиенты доверяют корневым центрам сертификации, следовательно, они доверяют сертификатам, подписанным центрами сертификации, чьи полномочия подтверждены корневыми центрами. Цепочка DNS работает аналогично: клиенты доверяют корневым доменам и доменам верхнего уровня (предполагается, что корневые домены и домены верхнего уровня являются якорями доверия), которые в свою очередь гарантируют безопасность дочерних сайтов.

На данный момент корневая зона DNS и домен. COM не поддерживают использование механизмов DNSSEC, но с учетом того, что многие правительства по всем миру санкционируют использование технологии DNSSEC, стоит ожидать изменения ситуации в ближайшем будущем. Поддержка технологии DNSSEC в корневой зоне DNS должна быть реализована в конце 2010 года, в зоне COM — в 2011 или 2012 году. Таким образом, нам необходимо промежуточное решение, которое бы позволило клиентам устанавливать отношения доверия с зонами DNS, поддерживающими технологию DNSSEC.

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

С помощью процесса, названного DNSEC Lookaside Validation (DLV), можно настроить отношение доверия между клиентами DNS и открытыми ключами. В Интернете существуют хранилища, в которые зоны с поддержкой технологии DNSSEC могут загружать открытые ключи. После этого ключи могут использоваться клиентами. Считается, что данные хранилища гарантируют легитимность находящихся в них ключей — точно так же мы доверяем центру VeriSign в процессе проверки компаний и выдачи им сертификатов с подписью кода или сертификатов SSL. Организация может скачать содержимое хранилища, и средствами Active Directory (AD) реплицировать информацию DNSSEC между всеми серверами DNS (механизм DLV не поддерживается платформой Server 2008 R2).

Кроме того, вы можете вручную настроить якоря доверия внутри службы DNS, указав имя зоны и открытый ключ, выдаваемый серверами именования (экран 1). После того как будет настроена точка входа (то есть якорь доверия) для цепочки доверия и вы зададите ключ подписывания ключа (подробнее я расскажу о нем ниже), необходимо установить флаги Secure Entry Point (SEP) и Zone Signing Key. Если вы хотите настроить общий доступ к открытому ключу, чтобы другая организация или хранилище могли добавить его в качестве якоря доверия, данная организация должна получить доступ к содержимому файла \%systemroot%\System32\dns\keyset-<имя зоны> (экран 2).

 

Экран 1. Настройка доверия к откликами DNS

 

Экран 2. Настройка общего доступа к открытому ключу

Данная функциональность не распространяется на отношения между клиентом DNS (например, вашей рабочей станцией) и уполномоченным сервером DNS, обслуживающим ваш запрос. Настроить якоря доверия на стороне клиента DNS просто невозможно. На самом деле, хотя я использую термин «клиент DNS», технология DNSSEC проявляет все свои достоинства только при взаимодействии между серверами DNS. В обычном процессе разрешения имен DNS клиент отправляет запрос локальному серверу DNS, а тот в свою очередь осуществляет рекурсивный поиск ответа. Таким образом, ваш сервер DNS является звеном, которому необходим механизм проверки ответов. В большинстве окружений клиент не выполняет проверку ответов: если локальный сервер использует технологию DNS, клиент доверяет проверку ответов ему.

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

Для настройки ожидания клиентами DNS проверки DNSSEC используется таблица Name Resolution Policy Table (NRPT), в которой определяется, каким образом механизмы безопасности будут применяться в работе службы DNS: используются ли отдельные записи для различных пространств DNS (например, microsoft.com), требуется ли проверка механизмами DNSSEC для каждого пространства имен, а также должны ли использоваться механизмы IPsec при обменах между клиентом и ближайшим к нему сервером DNS (то есть локальным сервером DNS). Обычно управление таблицей NRPT осуществляется через групповую политику, чтобы вручную не настраивать ее на каждой клиентской машине. На экране 3 показана простейшая политика. Имейте в виду, что таблица NRPT может иметь в своей основе не только суффикс DNS — вы можете использовать префикс, полное доменное имя (FQDN), а также имя подсети.

 

Экран 3. Настройка требований DNSSEC для зоны

Теперь, когда мы выяснили, каким образом технология DNSSEC гарантирует подлинность DNS ответов, возникает вопрос, как получить доступ к этим механизмам. Для окружений, построенных на основе платформы Microsoft, необходимы серверы DNS на базе Server 2008 R2, а на клиентских системах должна быть установлена Windows 7. Также, в связи с особенностью функций DNSSEC, существуют некоторые ограничения на использование данной технологии. Нет необходимости активировать механизмы DNSSEC для каждой записи в организации — стоит применять DNSSEC для защиты записей, используемых широкой аудиторией, ориентированной на работу с Интернетом, например для защиты адреса вашего сайта. Зона с цифровой подписью DNSSEC в дальнейшем не будет воспринимать динамические обновления, используемые в большинстве окружений для автоматической регистрации соответствий имя-Ip-адрес. Таким образом, для защищенных записей необходимо создать отдельную зону, в дополнение к зоне, получающей динамические обновления из Интернета (если такая зона необходима). Каждый сервер DNS, хранящий копию подписанной зоны, должен использовать операционную систему Server 2008 R2. Кроме того, необходимо убедиться в том, что ваша сеть может работать с пакетами DNS большего размера, используемыми механизмами DNSSEC. Например, убедитесь, что сеть поддерживает стандарт Extended DNS 0 (EDNS0), разрешающий использование пакетов DNS размером до 4 Кбайт, вместо стандартных 512 байт.

Чтобы активировать технологию DNSSEC для зоны в системе Server 2008 R2, используйте утилиту DnsCmd. Создайте ключи подписывания ключей и ключи подписывания зон и сохраните их в локальном хранилище сертификатов (MS-DNSSEC). Ключ подписывания зон (ZSK в приведенном ниже коде) подписывает все записи в зоне, а ключ подписывания ключей (KSK в коде) подписывает только другие ключи. Необходимо также создать запись ресурса DNSSEC в корне цепочки доверия (это происходит автоматически). Например, для создания моих сертификатов я использовал команды

dnscmd/offlinesign/genkey/alg rsasha1
   /flags KSK/length 2048/zone secure
   . savilltech.com/SSCert/FriendlyName
   KSK-secure.savilltech.com
dnscmd/offlinesign/genkey/alg rsasha1
   /length 2048/zone secure.savilltech
   . com/SSCert/FriendlyName ZSK-secure
   . savilltech.com

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

dnscmd/zoneexport secure.savilltech
   . net securesavilltechnet.dns
dnscmd/offlinesign/signzone/input
   securesavilltechnet.dns/output
   securesavilltechnetsigned.dns/zone
   secure.savilltech.net/signkey/cert
   /friendlyname KSK-secure.savilltech
   . net/signkey/cert/friendlyname
   ZSK-secure.savilltech.net
dnscmd/zonedelete secure.savilltech
   . net/dsdel/f
dnscmd/zoneadd secure.savilltech
   . net/primary/file
   securesavilltechnetsigned.dns/load
dnscmd/zoneresettype secure
   . savilltech.net/dsprimary

На экране 4 приведены различные записи DNSSEC.

 

Экран 4. Записи DNSSEC

Реализация механизмов DNSSEC включает множество шагов, при этом сопровождение данных механизмов и обслуживание набора ключей также занимают массу времени. Созданные ключи имеют ограниченное время жизни, и их необходимо периодически обновлять. Если в системе настроены якоря доверия, то их открытые ключи будут меняться, а, следовательно, якоря также нуждаются в обновлении. Я настоятельно рекомендую ознакомиться со статьей Microsoft «Deploying DNS Security Extensions (DNSSEC)» по адресу technet.microsoft.com/en-us/library/ee649268(WS.10).aspx — это отличное пошаговое руководство.

DNS Devolution

Вероятно, технология DNSSEC является наиболее известным нововведением для службы DNS в системе Server 2008 R2, однако не стоит забывать и про другие полезные новинки. В окружениях с многоуровневой архитектурой пространства имен DNS бывает сложно определить корректный суффикс для адреса. Например, в моем окружении есть узел с именем savdalfile01. Однако я являюсь членом домена dallas.na.savilltech.net и не могу точно сказать, какое полное имя avdalfile01.dallas.na.savilltech.net, savdalfile01.na.savilltech.net или savdalfile01.savilltech.net будет соответствовать данной системе. В прошлом приходилось создавать глобальный список суффиксов, содержащий все суффиксы DNS, которые необходимо было проверить при разрешении имени.

В системах Server 2008 R2 и Windows 7 обновлен один из ключевых механизмов — функция DNS Devolution, которая позволяет запросам DNS просматривать пространство имен до тех пор, пока не будет найдено совпадение или пока не будет выполнено определенное количество регрессий. Каждый возврат к родительскому домену в пространстве имен является регрессией на уровень выше. Вернемся к примеру с именем savdalfile01. При использовании механизма DNS Devolution сначала будет выполнен запрос на разрешение имени savdalfile01.dallas.na.savilltech.net, далее произойдет переход к домену-родителю и будет выполнен запрос для имени savdalfile01.na.savilltech.net. Происходит регрессия третьего уровня, так как суффикс DNS состоит из трех частей — na, savilltech и net. Если совпадение не найдено, происходит возврат к родительскому домену зоны и осуществляется поиск совпадений для имени savdalfile01.savilltech.net (в данном случае имеет место регрессия второго уровня, так как суффикс имеет две части). По существу, данный механизм позволяет доменам-потомкам получать доступ к ресурсам доменов-родителей, и при этом нет необходимости указывать имя родительского домена в теле запроса DNS.

В системах Server 2008 R2 и Windows 7 впервые появилась возможность настраивать уровень регрессии на стороне клиента DNS. Как администратор, вы можете указать, активирован ли механизм Devolution и на какой уровень регрессии ему разрешен доступ. Например, указав уровень регрессии 2, в процессе разрешения имени вы сможете «опуститься» до корневого домена леса (FRD) второго уровня (например, savilltech.net). Указав уровень 3, вы сможете работать только с доменом DNS третьего уровня (например, na.savilltech.net).

Вы можете настраивать механизм DNS Devolution с помощью групповой политики, используя параметры Primary DNS Suffix Devolution и Primary DNS Suffix Devolution Level, расположенные в узле \Computer Configuration\Policies\Administrative\Templates\Network\DNS Client (экран 5). Также можно напрямую задать значения параметров реестра HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\UseDomainNameDevolution и HKEY_ LOCAL_MACHINE\SYSTEM\Current ControlSet\services\Dnscache\Parameters\DomainNameDevolutionLevel, управляющих работой функции DNS Devolution. Данный механизм полезен в окружениях с многоуровневым пространством имен DNS.

 

Экран 5. Настройка уровня регрессии

DNS Cache Locking

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

Функция DNS Cache Locking — новый механизм, появившийся в системе Server 2008 R2, позволяющий уменьшить негативный эффект от фальсификации кэша: он не дает перезаписывать записи кэша DNS в течение всего времени их жизни. То есть если кто-то пытается сфальсифицировать кэш, заменив в нем запись, сервер DNS проигнорирует такую замену. Таким образом поддерживается «чистота» кэша.

Для использования механизма Cache Locking необходимо задать процентную долю времени жизни записей кэша, в течение которых они будут защищены от перезаписи: например, значение 75 означает, что кэшированные записи не могут быть перезаписаны, пока не пройдет 75% времени их жизни. По умолчанию используется значение 100, означающее, что записи не могут быть перезаписаны в течение всего времени жизни. Однако можно изменить это значение, обратившись к параметру реестра HKEY_LOCAL_ MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters\CacheLockingPercent. Если значение не задано, используется настройка по умолчанию, то есть 100%.

Еще об NRPT

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

Помимо службы DNSSEC, таблица NRPT используется в работе еще одного ключевого механизма систем Windows 7 и Server 2008 R2, а именно новой функции DirectAccess, позволяющей клиентам с системой Windows 7 подключаться к корпоративным ресурсам, расположенным в любой точке Интернета, не используя каналы VPN. Клиент устанавливает соединение, и механизм DirectAccess обеспечивает безопасное обратное подключение.

Автоматическое использование DirectAccess при доступе к ресурсам вызывает один важный вопрос: как клиентская система Windows 7 определяет, к каким ресурсам корпоративной сети необходимо обращаться через механизм DirectAccess, а к каким — через обычное подключение к Интернету.

Выбор основывается на таблице NRPT: точно так же, как мы настраивали определенные действия механизма DNSSEC для различных имен DNS и IP-адресов, мы можем задать параметры обработки механизма DirectAccess с помощью вкладки DirectAccess, приведенной на экране 6. Если вы хотите проверить правила для данной машины, настроенные через групповую политику, обратитесь к разделу реестра HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig. Также вы можете создать исключения, позволяющие настроить глобальные правила для пространств имен, но в дальнейшем использовать альтернативные варианты обработки для определенного узла или части пространства имен.

 

Экран 6. Активация механизма DirectAccess

, и я рекомендую вам заменить им устаревшие службы Microsoft DNS, чтобы обеспечить максимальную безопасность работы.

Джон Сэвилл (jsavill@windowsitpro.com) — директор по технической инфраструктуре компании Geniant, имеет сертификаты CISSP, Security and Messaging MCSE для Windows Server 2003 и звание MVP