NRPT: Управляем безопасным DNS на Windows-клиенте

Привет.

Введение

Эта статья – про отдельную, но достаточно важную функцию по управлению DNS-подсистемой на стороне клиента. В частности, NRPT будет помогать и при использовании DNSSEC, и про работе с DirectAccess, в общем знание работы NRPT необходимо, чтобы обладать пониманием всей системы DNS на предприятии. Без NRPT Вы можете хорошо представлять, как взаимодействуют сервера друг меж другом и с внешними источниками, но безопасная ‘последняя миля’ без NRPT не настраивается. Я вообще хотел это сделать частью статьи про DNSSEC, но и эта тема заслуживает отдельного описания, и та статья уже достаточно масштабна и имеет тенденцию к росту. Поэтому заранее делаем отдельно. Технология NRPT реализована в Windows 7, поэтому разговор будет именно про эту ОС. Я предполагаю, что Вы ознакомились со статьями про безопасность DNS в Windows Server 2008 R2 и про DNSSEC в Windows Server 2008 R2. Многие предполагают, что NRPT – исключительно “внутридоменная” технология. Это не так, и NRPT настраиваема и для отдельных хостов. Далее – подробнее.

Оглавление

• Что такое NRPT – Name Resolution Policy Table
• Про Windows 7 DNS Client
• Глобальные настройки NRPT
  • Network Location Dependency
  • Query Failure
  • Query Resolution
  • Просмотр текущего значения глобальных настроек NRPT
• Правила NRPT и DNSSEC / DirectAccess
• Настройка NRPT в домене
• Настройка NRPT на отдельном хосте
• Как изменится алгоритм работы DNS Resolver с NRPT
• Проверяем работу NRPT

Что такое NRPT – Name Resolution Policy Table

NRPT – массив служебной информации, которая детализирует поведение сервиса DNS Client в плане безопасности. Говоря проще, это возможность установить специфику поведения DNS-клиента в зависимости от FQDN запроса или ответа со стороны сервера. Состоит NRPT из отдельных правил, которые указывают, для каких запросов как надо себя вести (например, добавлять ли флаги о поддержке DNSSEC в отправляемые на сервер запросы, как проверять и проверять ли ответы от DNS-сервера, что делать в случае работы DirectAccess). Хранится это всё в реестре, управляется через групповую политику либо напрямую, правкой реестра. Данная функциональность появляется только в Windows 7.

Про Windows 7 DNS Client

Никогда не задумывались, что будет, если выключить сервис DNS Client? А почти ничего не будет. Этот сервис, по сути – мини-DNS-сервер, который при старте забирает в кэш содержимое файла hosts и форвардит запросы от ОС и ПО на указанные в настройках сервера, запрашивая рекурсию. Про DNS client в Windows 7 пишут страшную фразу: “Non-validating security-aware stub resolver”. Разберемся, что это обозначает:

• Non-validating – это обозначает, что клиентский сервис в Windows 7 не проверяет целостность записей, которые ему возвращает сервер. То есть, если в ответе сервера есть, допустим, RRSIG, клиент Windows 7 его не проверит, даже если будет иметь технологическую возможность. Почему? Потому что сценарий DNSSEC в связке Win2008R2+Win7 – это “дотащить через инфраструктуру DNS-серверов безопасный ответ от других серверов, обеспечивая его целостность и аутентичность”. В этом сценарии клиент верит, что раз он что-то берёт от своего DNS-сервера, то раз оно “доползло” до сервера, то оно правильное-целостное-хорошее. Поэтому Microsoft, к примеру, предлагает защищать трафик от DNS-сервера до клиента IPSec’ом. “Как же так, ну вот зашифруете вы этот кусочек трассы, и что?” – удивляются люди. А ничего удивительного – если взять предположение, что DNSSEC-инфраструктура настроена правильно, то она просто “плохие” ответы не допустит до последнего в цепочке DNS-сервера, к которому, в свою очередь, будут подключаться клиенты.
• Security-aware – это обозначает, что клиентский сервис умеет ставить в запросах бит, показывающий, что ему нужно возвращать DNSSEC-ответы. Т.е. наличие этого бита важно – тогда сервер начинает понимать, что это вообще нужно делать. Заметьте, что для этого обязательно должен быть включен и настроен EDNS0 (как это сделать, есть в статье про безопасность DNS в Windows Server 2008 R2). И ещё, если клиент поставит такой бит, а сервер не-DNSSEC совместимый (как большинство публичных DNS-серверов, допустим, использующихся в домашних сетях и у провайдеров доступа в Интернет), то сервер, скорее всего, пришлёт “отбой” – что он не может отработать запрос клиента.
• Stub resolver – это обозначает, что клиентский сервис всегда запрашивает рекурсивный запрос, просто перебирая указанные ему DNS-сервера.

Соответственно, эффективная настройка клиента возможна только с учётом всего вышеуказанного (и EDNS0, и NRPT, и всё остальное). Теперь начнём настраивать NRPT. Начнём, что и логично, с глобальных настроек.

Глобальные настройки NRPT

Глобальные настройки NRPT проще всего редактировать через групповую политику (соответственно, на локальной системе – через вызов gpedit.msc). Откройте объект групповой политики, там выберите Computer -> Windows Settings -> Name Resolution Policy. В этом разделе, в общем-то, и собраны все настройки NRPT. Делятся они на две части:

• Линейный массив правил
• Глобальные настройки хоста

Посмотрим, какие нам доступны глобальные настройки. Это можно сделать, нажав кнопку Advanced Global Policy Settings.

Настройка Query Resolution в NRPT

Данная настройка поможет Вам выбрать поведение клиента, в случае, если ему в ответ на запрос будет возвращены и записи типа A, и AAAA. Зачем может понадобиться такая странная настройка, тем более, не учитывающая наличие IPv6 на узле вообще и на интерфейсах в частности? Это нужно в случае, когда Вы подключаетесь по DirectAccess. В этом случае, подключаясь к корпоративной сети, все узлы (в силу природы Direct Access) должны быть доступны по IPv6, и их имена должны разрешаться в AAAA. Обсуждаемая настройка будет закреплять эту ситуацию тем, что даже если для узла будет доступна/разрешаема/в локальном кэше позитивная запись и A и AAAA вида, будет обрабатываться только AAAA. Соответственно, включайте режим Resolve only IPv6 adresses for names только для описанного случая. Просто так не надо.

Настройка Query Failure в NRPT

Данная настройка – единственная, адресно относящаяся к DNSSEC. Она помогает настроить поведение клиента в случае, когда самый оптимальный и безопасный вариант разрешения имени (через DNSSEC) не сработал. Если эта опция не включена, то по умолчанию DNS-клиент будет пробовать другие способы разрешения имени (LLMNR и NBNS) только если получит чёткий ответ от сервера, что такой записи нет. Вы можете, управляя этой настройкой, управлять тем, как и после каких ошибок разрешения имени DNS-клиент будет действовать дальше. Варианты будут состоять из:

• Always fall back to Link-Local Multicast Name Resolution (LLMNR) and NetBIOS if the name does not exist in DNS or if the DNS servers are unreachable when on a private network (moderately secure) – этот вариант используется по-умолчанию и подразумевает, что если сервер, у которого мы запрашивали DNSSEC-ответ, вернул нам сообщение, что имя не найдено, то мы попробуем другие способы разрешения имени.
• Only use LLMNR and NetBIOS ... (в конце помечен как most secure) – если не нашли по DNSSEC, то считаем, что имени нет и не пробуем LLMNR и NetBIOS.
• Always fall back ... (в конце - least secure) – самый небезопасный вариант. Логика проста – если по любой причине не удалось разрешить имя узла через DNSSEC-сервер, пробовать разрешить его через LLMNR и NetBIOS. Данный вариант является самым небезопасным, потому что даже в случае, допустим, если Ваш хост начнёт искать www.atraining.ru, а DNSSEC-сервер скажет, что “ну нет записи www в зоне atraining.ru.“, Ваш хост попробует найти среди соседей того, кто откликнется на броадкаст “Кто тут www?”.

Настройка Network Location Dependency в NRPT

Настройка пригодится в случае работы через UAG с Direct Access. В этом варианте Вам должен быть доступен NLS-сервер (точнее даже, NLS-сайт на нём). Соответственно, можно тюнинговать поведение клиента в виде трёх различных вариантов, выбираемых в этой настройке:

• Клиент, у которого есть подключение по DirectAccess, сам “осознаёт”, подключён он к intranet или нет – вариант Let Network ID (NID) determine when Direct Access setting are to be user (это нормальная логика поведения клиента).
• Клиент всегда предполагает, что раз в системе есть подключение по DirectAccess, то он “в intranet’е” – вариант Always use Direct Access settings in th NRPT. Соответственно, все правила NRPT, где есть настройки DirectAccess, обрабатываются и принимаются во внимание.
• Клиент всегда предполагает, что он отключен от intranet’а и должен вести себя (с точки зрения обработки правил NRPT, заметьте!) так, будто канал DirectAccess сконфигурирован, но не подключен – вариант Never use Direct Access settings in th NRPT.

Лучше, пока сильно не надо, эту настройку не трогать. Выиграть в обычной ситуации, когда Direct Access нет, Вы этим ничего не выиграете. Если что, настроить URL, по которому будет проверяться наличие NLS-сайта, можно здесь: HKLM\software\policies\microsoft\windows\NetworkConnectivityStatusIndicator\ CorporateConnectivity\DomainLocationDeterminationUrl

Как посмотреть текущие глобальные настройки NRPT?

Достаточно несложно – есть команда netsh dns show state которая их покажет.

Примечание: Суммируя, в расширенных настройках NRPT есть 3 полезные в ряде моментов опции – две про DirectAccess, одна про DNSSEC.

Теперь поговорим про создание и управление правилами NRPT.

NRPT в домене и правила DNSSEC / DirectAccess

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

Компонент Namespace

Варианты:

• FQDN – явно указанный FQDN отдельного узла. Не подойдут варианты вида *.atraining.ru, т.е. именно явно указанный узел.
• Suffix – все запросы, которые будут заканчиваться на указанный суффикс, будут считаться подпадающими под это правило.
• Prefix – все запросы, FQDN которых будут начинаться с этого компонента. Внимание – в случае с суффиксом длина суффикса не ограничена – он может быть как из 2, так и из 3 или 4 компонентов. В префиксе же допустимо только одно имя: точку использовать нельзя.
• Subnet (IPv4) – все запросы для PTR-записей из указанной IPv4-подсети (указывается в формате ip-адрес/длина маски).
• Subnet (IPv6) – все запросы для PTR-записей из указанной IPv6-подсети.

Компонент Certification Authority

Это поле задавать не нужно. Причина в следующем. Правило лишь покажет клиенту, когда надо ставить бит “требую DNSSEC-ответ”. Сама связь с DNS-сервером будет защищаться уже IPSec-политикой, в которой будут настройки аутентификации. Т.е. тут проверять CA не имеет смысла – это правило перенаправления, а не проверки серверов. Если Вы всё же зададите это правило, то надо будет выбрать один из сертификатов корневых CA, и сервер будет проверяться на выданность именно этим CA. Со стороны организации это приведёт к тому, что надо будет сделать специальный CA, который будет выдавать только специальный вид сертификатов DNSSEC, которые делаются из специального шаблона (т.е. этот пункт мало того, что проверяет сертификат на действительность и выданность указанным CA, так ещё и проверяет EKU, поэтому, допустим, обычный компьютерный сертификат не подойдёт). Про это я подробнее писал в DNSSEC в Windows Server 2008 R2, а так как эта статья про настройки клиентов, то здесь про это подробнее не особо надо.

Компонент DNSSEC : Validation

Если запросы, подпадающие под данное правило, нуждаются в защите посредством DNSSEC, выберите вкладку DNSSEC и включите её – Enable DNSSEC in this rule. Как понятно, на вкладке про Direct Access будет аналогичный “выключатель” – ведь технологии DNSSEC и Direct Access не противоречат друг другу. Теперь включим обязательный запрос DNSSEC-ответа. По сути, мы скажем – если наш запрос подпадает под правило, надо ставить бит DO (DO – это хардкорное обозначание ои DNSSEC OK) в EDNS0-запросе. Включим установкой отметки около Require DNS clients to check that name and address data has been validated by the DNS server.

Компонент DNSSEC : Encryption

Это – про шифрование запросов. Да, это, по сути, не DNSSEC. Но это то, что ожидают от термина “защита DNS-трафика”, поэтому, несмотря на то, что эта настройка, по сути, “инициирует” требование защиты IPSec’ом, она здесь есть. Включите параметр Use IPsec in communication between the DNS client and DNS server и выберите нужную степень защиты. Обратите внимание, что это уже FIPS140-1 – Вам даже не предложат RC4, DES, и самым минимальным будет 3DES/AES. Доступные варианты будут:

• Не требовать шифрование; достаточно подтверждения подлинности.
• 3DES и любой AES.
• Только AES.
• Только AES с ключом более 128 бит (т.е. 192 или 256).

Я бы рекомендовал в этой настройке всегда выбирать максимум. Причина – DNS-трафик крайне мал, поэтому рост вычислительной сложности алгоритма шифрования никак не повлияет на скорость работы клиента. Будьте внимательны, есть различие между вообще не включённой этой настройкой и включением и выбором пункта “Не требовать шифрование”. Если настройку не включать, то для общения с сервером не обязателен будет IPSec (т.е. живая IKE’шная SA). Если включать и выбрать “не требовать шифрования”, то IPSec будет согласован, но не обязательно ESP, а AH. Авторами настроек предполагается, что у Вас в политике IPSec, действующей на связку клиент-сервер, будет список согласовываемых алгоритмов и методов, который будет начинаться с ESP и заканчиваться AH. Если Вы сделали всё это, то с настройками, касающимися DNSSEC, уже всё ОК. Остался только Direct Access, про него будет отдельно.

Настройка NRPT на отдельном хосте

Ну тут как обычно. Те, кто читает уже не первую статью на этом ресурсе, знает, что сейчас начнётся. Надо создать ключ реестра с названием HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig В нём – для каждого правила свой подключ вида Rule1, Rule2, и далее, до RuleX. Каждый из этих подключей, что логично, будет задавать отдельное правило NRPT и иметь свой одинаковый комплект значений. Их будет чуть больше, чем в графическом интерфейсе. Разберемся.

Значение Version в NRPT

Тип – DWORD32. Обозначает версию NRPT. На данный момент только единица.

Значение ConfigOptions в NRPT

Тип – DWORD32. Обозначает, на каких из двух вкладок Вы поставили “включить”. Если равно 2 – то на DNSSEC. Если 4 – то на DirectAccess. Если 6 – то на обоих.

Значение Name в NRPT

Тип – MULTI_SZ. Тут уже интереснее. Будьте аккуратнее. Система не делает два отдельных поля “Тип имени” и “Имя”, поэтому отличает типы по признакам. Смотрите:

• Если Вы задаёте FQDN – например, www.atraining.ru – система узнает его по тому, что это строка, разделенная точками, и не имеющая точек в начале и конце
• Если Вы задаёте суффикс – например, .atraining.net – система узнает его по стартовой точке.
• Если Вы задаёте подсеть IPv4/IPv6 – например, .0.168.192.in-addr.arpa или .1.0.0.0.0.0.0.4.3.2.1.0.2.0.0.2.ip6.arpa – система узнает это по предсказуемому суффиксу и стартовой точке.
• Если Вы задаёте префикс – hostname1 – система узнает это по отсутствию точек.
• Если под правило должно подпадать всё – просто укажите точку.

Значение IPSECCARestriction в NRPT

Тип – SZ. Это – DN CA, который должен подтверждать подлинность DNS-сервера. То есть, это строка, имеющая вид типа “CN=ca1,DC=domain,DC=local”.

Значение DNSSECValidationRequired в NRPT

Тип – DWORD32. Аналог того, что выше обсуждалось как Validation. Значения – единица или нуль.

Значение DNSSECQueryIPSECRequired в NRPT

Тип – DWORD32. Флаг, надо ли требовать IPSec. Значения – единица или нуль.

Значение DNSSECQueryIPSECEncryption в NRPT

Тип – DWORD32. Выбор варианта защиты IPSec’ом; 0 – если шифрование необязательно, 1 – подойдёт любое, 2 – только AES, 3 – только AES выше 128 бит. Тоже выше обсуждали. В общем-то, всё. Как понимаете, благодаря этим настройкам Вы сможете даже с домашней машины сделать вполне разумную политику – от запросов к каким доменам (допустим, корпоративным) требовать подтверждения, а с какими – и шифрования, и как вести себя системе, если DNSSEC-запрос не срабатывает. Если подозреваете, что эти параметры не работают, поставьте требовать от Any (которое точка) и DNSSEC и шифрование, удивитесь, с какой скоростью перестанут разрешаться имена. На локальном хосте это применяется крайне шустро. Теперь давайте, вооруженные знаниями по возможностям и настройкам, разберемся, как наличие NRPT дополняет стандартную логику DNS Client’а.

Как выглядит алгоритм работы DNS Resolver, который с NRPT

• Приложение запрашивает какое-либо имя. Если это имя не кончается на точку, система дополняет его суффиксом.
• Получившееся имя смотрят в локальном кэше. Если результат есть (что негативный, что позитивный) – он возвращается клиенту. Если нет – далее.
• Проверяется, подпадает ли этот FQDN под одно из правил NRPT. Если не подпадает, или подпадает под правило-исключение, в котором стоит “не запрашивать DNSSEC и/или DirectAccess”, то запрос обрабатывается нормально – DNS Client вспоминает, что он тупой стаб и делает рекурсию по списку известных ему DNS-серверов.
• Если запрос подпал только под одно NRPT-правило, то он обрабатывается согласно ему. Если под несколько – то правила выстраиваются в порядке приоритета. По порядку:
  • Первым идёт FQDN-правило, потому что 100% подпадение.
  • Потом правила на совпадение префиксов – выбирается то, у которого совпал максимум символов (т.е. если мы запрашивали, например, host1.atraining.ru, то если такого FQDN нет, нам подойдёт префиксовое правило про host1, после – и про hos)
  • Потом правила на суффиксы – тоже выиграет самое длинное совпадение, т.к. полного-то уже не будет точно.
  • Ну а потом, что логично – точка.
• И запрос обрабатывается самым лучшим по приоритету правилом. Одним.

Как понятно, в случае приёма ситуация проще – всё принятое “прогоняется” через таблицу, если подпало – проверяется на совпадение деталей (шифрование, целостность, имя CA – что настроите). В общем-то, всё.

Проверяем работу NRPT

Как проверить на локальном хосте, как у него сейчас работает NRPT?

Есть команда: netsh namespace show policy которая выведет все текущие настройки NRPR.

Заключение

Я искренне надеюсь, что “тёмных углов” в хороших и нужных современных сетевых технологиях у Вас стало на один меньше. Если нет – пишите в комментарии; как обычно, я допишу те моменты, которых не хватает, либо те, которые расписаны недостаточно подробно.