Четыре причины обновления DNS сервера до версии Windows Server 2008 R2

DNS является хребтом сетевых взаимодействий. Без DNS мы были бы вынуждены запоминать IP адреса всех клиентов и серверов в сети. Это еще было выполнимо в 1985 году, но на пороге второго десятилетия 21 века это не реально. И DNS станет еще важнее по мере плавного перехода с IPv4 на IPv6. Хотя некоторые талантливые администраторы могут запоминать IPv4 адреса десятков, а, возможно, даже сотен серверов, это станет абсолютно невозможным для IPv6; поскольку IP адреса будут иметь 128-разрядные номера шестнадцатеричной системы счисления. IPv6 снова вернет DNS на первый план.

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

Это заставило меня задуматься о Windows Server 2008 R2 DNS сервере. В нем есть ряд новых компонентов, которые можно использовать для повышения уровня общей безопасности вашей инфраструктуры DNS. Сюда входит следующее:

• Расширения безопасности DNS Security Extensions (DNSSEC)
• Контроль поведения передачи прав DNS
• Блокировка кэша DNS
• Пул сокетов DNS

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

DNS Security Extensions (DNSSEC)

DNSSEC представляет собой группу спецификаций из Internet Engineering Task Force (IETF), которые обеспечивают проверку подлинности происхождения DNS данных, отрицание существования при проверке подлинности и целостности данных (не конфиденциальности данных). Целью DNSSEC является защита от фальшивой DNS информации (например, отравления DNS кэша) посредством использования цифровых подписей. DNSSEC по сути представляет собой собрание новых компонентов, добавленных во взаимодействие между клиентом и сервером DNS, которое поможет повысить безопасность основных протоколов DNS. Основные компоненты DNSSEC определены в стандартах:

• RFC 4033
• RFC 4034
• RFC 4035

DNSSEC представляет несколько новых терминов и технологий на стороне сервера и клиента. Например, DNSSEC добавляет новые записи DNS ресурсов:

• DNSKEY
• RRSIG
• NSEC
• DS

Применение Windows Server 2008 R2

Windows Server 2008 R2 и Windows 7 являются первыми операционными системами от Microsoft с поддержкой DNSSEC. Теперь вы можете подписывать и размещать DNSSEC подписанные зоны для повышения уровня безопасности вашей инфраструктуры DNS. Следующие компоненты, связанные с DNSSEC, представлены в Windows Server 2008 R2:

• Возможность подписывания зон (то есть назначение зонам цифровых подписей)
• Возможность размещения подписанных зон
• Новая поддержка DNSSEC протокола
• Новая поддержка DNSKEY, RRSIG, NSEC и DS записей ресурсов.

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

Улучшения Windows 7/Server 2008 R2 DNS клиентов

Вдобавок к обновлениям DNS сервера в Windows Server 2008 R2, были внесены усовершенствования в Windows 7 DNS клиент (которые также включают службу DNS клиента в Windows Server 2008 R2):

• Способность передачи информации о поддержке DNSSEC в DNS запросах (которая требуется, если вы решите использовать подписанные зоны)
• Способность обработки DNSKEY, RRSIG, NSEC и DS записей ресурсов.
• Способность определения того, выполняет ли DNS сервер, на который клиент направил запрос, подтверждение.

DNSSEC и NRPT

Если вы знакомы с DirectAccess, вам, возможно, интересен тот факт, что DNSSEC использует таблицу политик разрешения имен (Name Resolution Policy Table - NRPT). Поведение DNS клиента, связанное с DNSSEC, определяется таблицей NRPT. Таблица NRPT позволяет вам создавать тип маршрутизации на основе политики для DNS запросов. Например, вы можете настроить NRPT на отправку запросов для contoso.com на DNS сервер 1, а запросы для всех остальных доменов будут отправляться на адрес DNS сервера, настроенный на сетевой карте DNS клиента. Настройка NRPT выполняется в групповой политике. Таблица NRPT также используется для включения DNSSEC для определенных пространств имен, как показано на рисунке 1 ниже.

Понимание принципа работы DNSSEC

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

Новая поддержка Windows Server 2008 R2 DNSSEC позволяет вам подписывать зоны на основе файлов (file-based) и Active Directory интегрированные зоны посредством автономного инструмента подписания зон. Знаю, что было бы удобнее использовать графический интерфейс для этой цели, но думаю, что у Microsoft не было времени, или они решили, что немногие будут использовать эту функцию, и поэтому не стали разрабатывать удобный графический интерфейс для подписания зон. Процесс подписания также выполняется в автономном режиме. После подписания зоны, она может содержаться на других DNS серверах с помощью типичных технологий перемещения зон.

При настройке с якорем доверия (trust anchor) DNS сервер способен проверять DNSSEC ответы, получаемые от имени клиента. Однако чтобы убедиться, что DNS ответ верен, необходимо знать как минимум один ключ или DS запись, которая будет верна для любого источника помимо DNS. Такие отправные точки называются якорями доверия.

Еще одним изменением в Windows 7 и Windows Server 2008 R2 DNS клиенте является то, что он действует в качестве преобразователя заглушки с поддержкой безопасности. Это означает, что DNS клиент будет позволять DNS серверу выполнять задачи проверки безопасности, но будет использовать результаты проверки безопасности, выполненные сервером DNS. Клиенты DNS используют таблицу NRPT для определения того, когда им следует проверять результаты утверждения безопасности. После того, как клиент удостоверится в том, что ответ действителен, он вернет результаты DNS запроса приложению, выполнившему изначальный DNS запрос.

Использование IPsec с DNSSEC

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

• DNSSEC использует SSL для защиты соединений между клиентом и сервером DNS. Есть два преимущества в использовании SSL: во-первых, оно шифрует трафик DNS запросов между клиентом и сервером DNS, а, во-вторых, оно позволяет DNS клиенту выполнять проверку подлинности идентификации DNS сервера, что позволяет быть уверенным в том, что DNS сервер является доверенной машиной.
• Нужно исключить TCP порт 53 и UDP порт 53 из своей IPsec политики домена. Причина заключается в том, что IPsec политика домена будет использоваться, и проверка подлинности на базе сертификата DNSSEC не будет выполняться. В результате клиент не сможет выполнять EKU проверку и не будет доверять серверу DNS.

Контроль делегирования DNS

DNS делегирование доступно уже долгое время в клиентах Windows DNS. Нет, это не означает, что операционные системы не развиваются. Делегирование позволяет вашим клиентским компьютерам, которые являются членами субдоменов, получать доступ к ресурсам в родительском домене без необходимости предоставления точного имени FQDN этих ресурсов.

Например, если клиент использует основной DNS суффикс corp.contoso.com и делегирование настроено на второй уровень, приложение, пытающееся запросить имя узла server1, будет также пытаться преобразовать:

• server1.corp.contoso.com и
• server1.corp.com

Обратите внимание, что когда делегирование установлено на второй уровень, процесс делегирования прекращается, когда есть два ярлыка для имени домена (в данном случае, corp.com).

Итак, если установлен третий уровень делегирования, процесс делегирования остановился бы на server1.corp.contoso.com, поскольку server1.contoso.com имеет всего два ярлыка в имени домена (contoso.com).

Однако, делегирование не включено в доменах Active Directory когда:

1. список поиска глобальных суффиксов назначен групповой политикой.
2. на DNS-клиенте не отмечена опция «Дописывать родительские суффиксы основного DNS-суффикса» (Append parent suffixes of the primary DNS suffix) в закладке DNS в дополнительных параметрах TCP/IP свойств IPv4 или IPv6 Internet Protocol (TCP/IP) для сетевого подключения клиентского компьютера, как показано на рисунке 2. Родительские суффиксы приобретаются в результате делегирования.

Предыдущие версии Windows использовали эффективное делегирование второго уровня. Однако в Windows Server 2008 R2 новым является то, что теперь можно указывать собственный уровень делегирования, что обеспечивает дополнительный контроль над границами организации в домене Active Directory, когда клиент пытается разрешить имена в этом домене. Вы можете устанавливать уровень делегирования с помощью групповой политики, как показано на рисунке 3 ниже (Конфигурация компьютера\Политики\Административные шаблоны\Сети\DNS клиент).

Блокирование DNS кэша

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

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

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

Пример того, как настраивать значение блокировки кэша, показан на рисунке 4 ниже. Процентное значение может варьироваться в диапазоне от 0 до 100.

Пул сокетов Windows Server 2008 R2 DNS Socket Pool

Для пула сокетов Windows Server 2008 R2 DNS вы можете позволить серверу DNS использовать перемешивание портов источников при выполнении DNS запросов. Зачем это делать? Затем, что перемешивание портов источника обеспечивает защиту от различных атак отравления кэша, как атаки, описанные здесь.

Изначальное исправление включало некоторые стандартные параметры, но в Windows Server 2008 R2 вы можете изменять параметры пула сокетов.

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

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

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

Как и компонент кэша DNS, пул сокетов настраивается с помощью инструмента dnscmd. Ниже приведен пример настройки значения.

Заключение

В этой статье мы рассмотрели несколько новых компонентов, включенных в Windows Server 2008 R2 сервер и Windows 7 DNS клиент, которые помогут повысить уровень безопасности и производительности вашей DNS инфраструктуры. Сочетание DNSSEC, усовершенствований контроля над делегированием DNS, улучшений безопасности в DNS кэше и пуле сокетов DNS, является веской причиной для обновления DNS серверов до версии Windows Server 2008 R2.