Оглавление
- SocketPool – защищаемся от отравления DNS-кэша
- Фильтрация Name checking
- Нужен ли BIND secondaries
- Ограничиваем размер DNS-ответа
- Secure cache against pollution
- Блокируем раннее обновление кэша – Cache Locking
- Отключаем стандартный трансфер у зон, интегрированных в Active Directory
- Включаем Secure cache against pollution
- Привязка к интерфейсам
- Не публикуем лишние NS
- Настраиваем Global Query Block List
- Механизм Aging/Scavenging в DNS
- Настраиваем EDNS0
SocketPool – защищаемся от отравления DNS-кэша
SocketPool появился как способ противодействия описанной в http://support.microsoft.com/kb/953230/en-us уязвимости. Суть достаточно проста. В версиях Microsoft DNS до NT 6.1 для сервера стартово инициализировался один сокет, от которого шло взаимодействие (в частности – ответы на запросы клиентов). Один сокет = разовая инициализация = одинаковый случайный ID транзакции. Это позволяло проводить достаточно хитрую атаку на перебор вариантов ID и с определённой вероятностью отравить кэш DNS-сервера путём отправки ему “заранее” неправильного ответа на предсказуемый запрос. А после, соответственно, DNS-сервер отдавал бы клиентам неправильную информацию из своего кэша, таким образом перенаправляя трафик туда, куда надо нарушителю. Бороться с этим было решено достаточно просто – выделяя под нужды DNS-сервера пул сокетов, и отправляя ответы со случайного из них. Плюс, для каждой DNS-транзакции стал генериться случайный ID, что дополнительно усложнило задачу отравления кэша, сделав её осуществимой лишь теоретически.Настройка SocketPool
По умолчанию пул равен 2.500 сокетам, но если у Вас есть техническая возможность – увеличьте его дополнительно. Я увеличиваю до 10.000, потому что это максимум (если попробовать больше, выдастDNS_ERROR_DWORD_VALUE_TOO_LARGE с кодом 9567).
Команда для задания количества сокетов, которые под себя “застолбит” сервис DNS:
dnscmd /Config /SocketPoolSize количество
Как посмотреть количество выделенных для DNS сокетов:
dnscmd /Info /SocketPoolSize
Примечание: По сути, это красивая форма записи в параметр реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\SocketPoolSize
Возможные проблемы, связанные с SocketPool
Возможные проблемы связаны с тем, что DNS Server застолбит под себя много UDP-сокетов, и различное ПО может от этого не иметь возможность сделать то же самое. Известный пример – это WDS (Windows Deployment Services). Эта служба резервирует для себя диапазон портов с 64.000 по 65.000, и, в случае, когда DNS Server заберёт 10.000, могут возникнуть проблемы. Они решаемы, благодаря тому, что в WDS, который в Windows Server 2008 R2, встроен механизм динамического выбора портов. Включается он достаточно просто: необходимо зайти в ключ реестраHKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Parameters, открыть параметр UdpPortPolicy и присвоить ему значение 0.
Фильтрация Name checking
Настройка Name Checking на уровне DNS Server’а указывает на то, по каким критериям будут фильтроваться имена в запросах. То есть в случае, если имя в запросе подпадает под выбранную логику проверки – запрос обрабатывается, если нет – то считается ошибочным и отбрасывается. Вариантов настройки будет четыре:Вариант Strict RFC (ANSI)
В запрашиваемых именах могут быть только символы, которые указаны в RFC 952 и 1123. Т.е. подмножество семибитовых ASCII-символов, case insensitive, по сути – только английские буквы, цифры и минус/тире/дефис.Вариант Non RFC (ANSI)
Strict RFC плюс вторая половина ASCII-таблицы.Вариант Multibyte (UTF8)
Имена могут быть в Unicode (RFC 2181).Вариант All Names
Фильтрация не производится, сервер пытается обработать все полученные строки. Что выбрать? Тут всё достаточно сложно. Ситуаций много. Например, если Ваш DNS-сервер держит исключительно внешние зоны, в которых нет хостов с именами, в которых есть символы национальных алфавитов, и предназначен он лишь для этой задачи (т.е. на нём нет рекурсии), то имеет смысл использовать Strict RFC. Вообще, если не планируется пропускать через этот DNS запросы на интернациональные домены, то имеет смысл включать Strict RFC, и лишь в случае чёткой необходимости переходить на другие варианты. Для обычного сервера, который кэширует запросы клиентов, подойдёт Multibyte. Отключать фильтрацию целиком нецелесообразно. Фильтрация по размеру FQDN – каждый компонент не более 63 байт и все в сумме – не более 255 – всегда сохраняется и не редактируема. Заметьте, байт, а не символов. То есть в случае работы с UTF8, где размер символа – не константа, данный критерий работает именно исходя из количества байт.Как настраивается фильтрация Name Checking в Windows Server 2008 R2 DNS
Для настройки этой опции нужно выбрать свойства (Properties) у сервера DNS, и там – вкладку Advanced, а после выбрать необходимый режим.Нужен ли BIND secondaries
По сути, этот параметр делает одну-единственную вещь. Он разрешает при стандартном трансфере зоны с текущего DNS-сервера передавать несколько записей одной операцией, чем ускоряет трансфер. Поддержка этого функционала есть в BIND уже достаточно давно, с версии 4.9.4, поэтому на данный момент включение данной опции не имеет смысла.Как настраивается BIND secondaries в Windows Server 2008 R2 DNS
Для настройки этой опции нужно выбрать свойства (Properties) у сервера DNS, там – вкладку Advanced, а после выбрать соответствующий параметр.Ограничиваем размер DNS-ответа
DNS-ответы выглядят как UDP-пакеты, и обладают интересной особенностью – их максимальный размер по стандарту равен 1,280 байт. Сделано это из соображений совместимости – мол, вдруг ответы должны будут проходить через сетевые среды с малым MTU, вот подстрахуемся на случай отсутствия возможности фрагментации. По сути же данный параметр гибко настраивается в диапазоне от 512 до 16,384 байт.Примечание: 512 байт – это ограничение, заложенное на уровне стандарта RFC 1035. Для работы с пакетами бОльшего размера используется протокол EDNS0, описанный в стандарте RFC 2671.
В случае, если Вы сталкиваетесь с ситуацией, когда MTU малО (например, 640 байт), имеет смысл уменьшить максимальный размер ответа сервера. Тогда сервер в случае необходимости будет просто отправлять несколько ответов, и ошибка, связанная с невозможностью передачи UDP-датаграммы через среду с малым MTU пропадёт. Когда вообще возникнет такая необходимость – возвращать 1,280 байт данных в качестве DNS-ответа, это же очень много для одного запроса? Такой случай будет, когда Ваш сервер будет возвращать в качестве данных, например, много однотипных записей (например разрешать запрос про крупный сайт с многими зеркалами). В этом случае надо будет отдать целую пачку A-записей.Как управлять размером DNS-ответа
У ключаHKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters
есть параметр MaximumUdpPacketSize с типом DWORD32. Установите его в требуемое для Вашей ситуации значение.
Secure cache against pollution
Идея этой настройки, появившейся ещё в Windows NT 4.0, и включенной по умолчанию с Windows Server 2003, проста. Она состоит в том, чтобы читать из ответа DNS-сервера только запрашиваемые ранее сведения, и игнорировать остальные. Рассмотрим пример. Допустим, на DNS-сервер пришёл запрос от клиента – “хочу A-запись с именем msdn.microsoft.com”. DNS-сервер посмотрел у себя в кэше – не нашёл. Потом посмотрел в зонах, расположеных на нём – тоже нет. ОК, на DNS-сервере включена рекурсия. Он запрашивает другой сервер (например, сервер провайдера или какой-нибудь публичный) и ждёт ответ. И сервер присылает ему ответ – вида “msdn.microsoft.com доступен по адресу 1.2.3.4”. Но иногда сервер хочет помочь – вдруг следующим запросом Вы захотите microsoft.com? И он присылает не только msdn.microsoft.com, но и ту информацию, которую он выяснил попутно – например, адрес microsoft.com. По умолчанию предполагается, что сервер хороший, и присылает только полезную и нужную информацию. Но жизнь жестче. Данная настройка позволяет отсечь ситуацию, когда чужой сервер вернёт в составе ответа недостоверную информацию.Как настроить secure cache against pollution
Можно воспользоваться хирургическим способом: взять ключHKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters
и поставить там значение SecureResponses в единицу. Либо сделать это через консоль управления сервером – открыть Properties, вкладку Advanced и установить нужное значение. Всегда включайте этот параметр.
Блокируем раннее обновление кэша – Cache Locking
Cache Locking – новый механизм в Windows Server 2008 R2. Работает он следующим образом. В случае, когда в кэш DNS-сервера попадает информация от другого сервера (в случае выполнения рекурсивного запроса клиента), он сохраняет эту информацию столько времени, сколько указано в поле TTL у записей, содержащихся в ответе. Но в случае, если в одном из других ответов придёт новая информация об уже имеющихся в кэше записях, она их перезапишет. Это является небезопасным, т.к. в случае отключенного механизма Secure Cache Against Pollution позволяет перезаписать “хорошую” информацию, полученную путём кэширования ответа другого сервера “плохой” информацией, полученной как дополнительная в ответе злонамеренного сервера. Данный механизм позволяет запрещать обновлять находящиеся в кэше записи на указанное количество времени. Параметр задаётся в процентах – допустим, если установить его в 50, то в случае, если Ваш сервер закэширует какую-нибудь запись с TTL в 6 часов, все попытки обновить её на протяжении первых 3х часов будут игнорироваться. Установка параметра в 100, как понятно, приведёт к блокировке всех запросов на обновление имеющихся в кэше записей. Это – рекомендованное значение данного параметра.Как настроить DNS Cache Locking
Просто:dnscmd /Config /CacheLockingPercent проценты
Просмотреть:
dnscmd /Info /CacheLockingPercent
Для эстетов:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters, параметр CacheLockingPercent, тип DWORD32.
После смены параметра – что через dnscmd, что через реестр, необходимо перезапустить сервер.
Отключаем стандартный трансфер у зон, интегрированных в Active Directory
В том случае, если все сервера, на которых находится определённая зона, находятся на контроллерах Active Directory, то наличие возможности трансфера зоны стандартным способом – AXFR / IXFR запросом по TCP 53 является уязвимостью, так как может помочь потенциальному злоумышленнику узнать дополнительные сведения об инфраструктуре. Притом достаточно простым способом – например, подключившись при помощиnslookup и выполнив команду ls.
Как отключить zone transfer
Нужно открыть свойства (Properties) у нужной DNS-зоны, выбрать вкладку Zone Transfers и убедиться, что функция Allow Zone Transfers отключена.Привязка к интерфейсам
По умолчанию DNS Server слушает трафик и реагирует на запросы со всех интерфейсов. Это включает в себя все IPv4-адреса и все IPv6 (как unicast’ы, так и link local’ы). Да и при добавлении нового интерфейса он будет сразу же использоваться службой DNS. Имеет смысл из соображений предсказуемости переключить эту настройку на явное указание адресов, на которых DNS Server будет принимать трафик. Например, если в инфраструктуре не используется IPv6, а DNS Server настроен “по умолчанию”, и на его интерфейсах включен сетевой компонент IPv6, он (DNS Server) будет обрабатывать запросы, пришедшие на адрес link local (вида fe80::идентификатор хоста), что является в указанной ситуации не нужным и не должно, согласно принципу Уильяма Оккама, существовать.Как настраивается привязка DNS Server к интерфейсам
Необходимо зайти в настройки DNS Server, выбрать Properties и на вкладке Interfaces в явном виде выбрать только те адреса, на которые нужно принимать dns-запросы.Не публикуем лишние NS
Если у Вас интегрированная в Active Directory зона, и её имя совпадает с именем домена AD, то Вы, наверняка, заметили, что все DC регистрируются туда как NS’ы. А если к этой зоне в силу каких-то причин есть доступ снаружи, то сие есть не очень правильно. Имена плюс внутренние адреса (обычно всех интерфейсов при этом) – слишком много информации, чтобы ей разбрасываться. Вопрос решаем, благодаря технической возможности запрета на регистрацию NS-записей. Примечание: Обратите внимание, речь идёт именно о том, что все DC пропишутся как NS’ы. А не про то, что они регят A-запись за себя, за корень зоны, и кучу SRV. Это другие механизмы. Речь о том, что они на автомате все лезут регить NS, невзирая на то, надо это или нет.Как управлять авторегистрацией NS-записей DC в интегрированных зонах Active Directory
Командаdnscmd /Config имя зоны /AllowNSRecordsAutoCreation первый_ip_адрес_того_кому_можно второй_ip_адрес_того_кому_можно ...
позволяет в явном виде задать список тех DC, которым можно регистрировать себя как NS за указанную зону. Даже не указанных DC, а указанных адресов указанных DC, что позволяет ещё точнее управлять ситуацией. Если хотите вернуть ситуацию на исходную позицию – чтобы любой DC мог зарегить NS – напишите команду без списка адресов:
dnscmd /Config имя зоны /AllowNSRecordsAutoCreation
Узнать список адресов серверов, которые могут регистрировать NS-записи в указанной зоне можно следующей командой:
dnscmd /ZoneInfo имя зоны /AllowNSRecordsAutoCreation
Соответственно, вводите первую команду, указывая только нужные адреса нужных DC, а NS-записи от остальных стираете вручную и ОК – они больше не появятся. Проделать это надо разово на одном контроллере – сделанные настройки реплицируются на другие. Ещё раз – этот механизм только для зон, интегрированных в Active Directory.
Призовой уровень
Несмотря на то, что параметр задаётся на уровне зоны и реплицируется, его можно задать и на конкретном сервере. Для этого надо взять ключ:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
откопать в нём параметр DisableNSRecordsAutoCreation и выставить его в единицу. Если параметра нет – его можно создать, его тип DWORD32. Возвратив параметр в нуль, Вы опять включите для данного сервера возможность динамически регистрировать себя как NS для всех интегрированных зон Active Directory данного домена.
Настраиваем Global Query Block List
Глобальный блок-лист имён – достаточно интересная штука. Необходимость его использования вызвана тем, что в случае использования динамической регистрации возможна ситуация, когда злонамеренный участник зарегистрирует well-known имя, которое используется сетевой службой (например, wpad или isatap). Имя другого компьютера или сервера ему зарегистрировать, в случае существования оных и включённого механизма secure updates, не дадут, а вот wpad допустим – пожалуйста, ведь сервера с таким именем нет, это служебный идентификатор. А после – он будет отвечать на запросы пытающихся автоконфигурироваться клиентов вида “а дайте мне настройки” по адресу http://wpad.имя домена/wpad.dat, отдавая им то, что посчитает нужным. Это неправильно. Соответственно, GQBL нужен для того, чтобы отсечь эту возможность. Как это будет работать? Рассмотрим вариант для наличия в GQBL стандартного имени wpad. При добавлении имени в GQBL будут игнорироваться запросы для всех типов записей (это важно – не только A и AAAA, а всех) для всех зон, для которых данный сервер является authoritative. То есть, допустим, если на сервере есть зоны domain.local и _msdcs.domain.local, то запросы wpad._msdcs.domain.local и wpad.domain.local, несмотря на фактическое наличие/отсутствие данной записи, будут возвращать ответ, что запись не найдена. Примечание: Это можно обойти, если создать зону с именем wpad.domain.local и в ней – пустую запись нужного типа. В именах зон проверка не происходит. Запросы для других зон под это подпадать не будут (т.е. wpad.externaldomain.ru под этот механизм не подпадёт). Примечание: Интересно, что при первой блокировке в журнал пишется событие, где написано, что запрос от такого-то клиента заблокирован по причине нахождения искомого в GQBL. После запись уже не ведётся. Это не баг, а защита от простейшей атаки – переполнения журнала путём отправки огромного количества запросов на предсказуемо блокируемый FQDN. После перезапуска сервера счётчик сбросится на нуль и опять – первая блокировка будет записана в журнал, далее – нет.Настраиваем Global Query Block List на Windows Server 2008 R2 DNS Service
Включить этот фильтр на уровне сервера можно командой:dnscmd /Config /EnableGlobalQueryBlockList 1
Выключить, соответственно, заменив единицу на нуль. Просмотреть включён ли Global Query Block List можно так:
dnscmd /Info /EnableGlobalQueryBlockList
а само содержимое:
dnscmd /Info /GlobalQueryBlockList
Задать лист можно командой:
dnscmd /Config /GlobalQueryBlockList имя1 имя2 …
Добавлять по одному имени или удалять отдельные имена нельзя – только задавать целиком.
Механизм Aging/Scavenging в DNS
Динамически добавленные в DNS-зону записи не умеют пропадать сами. Это не баг, это так положено. В WINS (который NBNS) (не к ночи он будет помянут) этот механизм был штатным, а вот в DNS – увы. Поэтому фирма Microsoft добавила данный механизм в свою реализацию DNS Server. Как он будет работать? У каждой динамически зарегистрированной записи будет указываться time stamp – время последнего успешного изменения этой записи. После, на протяжении no-refresh time (по умолчанию – 7 дней), все обновления этой записи будут игнорироваться. В оригинале, когда этот механизм был в WINS, это было нужно, чтобы информация о записи “расползлась” по инфраструктуре, сейчас делается с другими целями. Когда no-refresh time закончится, у записи начинает бежать обратный отсчёт – refresh-time. Это время, в течении которого запись должна обновиться. Если она не обновится за это время (по умолчанию – тоже 7 дней), то она является кандидатом на удаление. И вот тут-то, если на уровне сервера включен механизм Scavenging of stale records, такие записи будут удаляться. Делается это раз в сутки (если включен автоматический режим), либо вручную. Этот механизм полезен, т.к. при должной настройке будет эффективно удалять ненужные записи рабочих станций, про которых знать совершенно не нужно. Не забывайте, что механизм включается и на уровне сервера, и на уровне зоны. Чтобы механизм функционировал, необходимо включить его и там и там. Т.е. и зона должна одобрять идею автоматической очистки, и конкретный сервер знать, что периодически надо удалять записи, не обновлённые уже X дней. Примечание: Включать данный механизм полезно ещё по одной причине. Мало того, что он будет удалять устаревшие записи. Он ещё будет, вводя no-refresh interval, уменьшать трафик репликации Active Directory. Т.е. если за время no-refresh interval придёт запрос на динамическое обновление записи, и в нём не будет ничего нового, то без механизма aging/scavenging этот запрос будет отработан и в зону будет произведена запись (бессмысленная), что вызовет репликацию раздела Active Directory, в котором находится эта запись. А в случае, если механизм будет включен, сервер посмотрит, и если запрос не будет содержать никакой новой информации (ну, например, машину просто перезагрузили – она ту же A-запись пытается зарегистрировать, по сути – просто сбросить time stamp), он будет проигнорирован. Это никак не повлияет на качество работы DNS, а вот новую репликацию не инициирует. Профит!Как включается Aging/Scavenging в Microsoft Windows Server 2008 R2 DNS
Первое – включаем на уровне сервера. Этот пункт находится в настройках сервера (Properties), вкладке Advanced, снизу. Время, задаваемое там – это критерий очистки. Т.е. раз в сутки сервер, на котором это включено, будет находить все динамически зарегистрированные записи, которые не обновлялись указанное в настройках время, и удалять их. Можно указать этот параметр достаточно большим – я указываю 30 дней, если рабочая станция месяц не обновляла свою запись – наверное, смысла жить в DNS ей больше нет. Вернётся – заново зарегистрирует. Второе – включаем на уровне зоны. Задаём no-refresh и refresh интервалы. Обычно стандартное время менять не нужно. В общем, всё.Настраиваем EDNS0
EDNS0 – это способ преодолеть стартовое ограничение на размер полезной нагрузки DNS, предлагаемый в RFC 1035 равным 512 байт. Понятно, что в случае, когда в ответе будет много информации (например, имя узла разрешится в целую пачку IPv6 адресов, которые сами по себе тоже не маленькие), это ограничение может начать мешать. Но с другой стороны – ограничение вводилось не просто так; предполагалось, что будут сетевые среды с небольшим MTU, а “благодаря” использованию протокола UDP, вычислить это MTU “на ходу” возможности нет (в отличии, скажем, от TCP, где такая возможность есть). И что возможна ситуация “сервер отвечает клиенту большой UDP-датаграммой, она идёт по маршруту, где-то участок с малым MTU, и нельзя фрагментироваться, датаграмма дропится”. Чтобы этого не было, серверу и клиенту надо уметь согласовывать размер ответа. Это умеет EDNS0, описанный в RFC 2671. Суть протокола проста. Запрашивающая сторона (клиент) добавляет в запрос к серверу поле OPT, где указывает максимально возможный для обработки размер ответа. Примечание: Если такого поля в запросе нет, сервер, поддерживающий EDNS0, предполагает, что клиент не поддерживает этот стандарт и работает по RFC 1035 – т.е. с пакетами до 512 байт. Если сервер тоже поддерживает EDNS0, он читает это поле и соответственно его содержимому изменяет верхнюю планку размера ответа. В случае же, если взаимодействуют два сервера, ситуация несколько другая. Запрашивающий сервер (например тот, который форвардит рекурсивный запрос дальше), имеет специальный кэш EDNS, в котором помнит, какой из upstream серверов поддерживает расширения EDNSx, и каких версий. Данный кэш наполняется после получения от “верхнего” сервера ответа, из которого следует, что сервер поддерживает EDNSx. Как это вычисляется? Это вычисляется исходя из отсутствия ошибки в ответе. Ошибкой считается поле RCODE, в котором будет ненулевое значение. То есть, логика такова: Хочется отправить запрос вышестоящему серверу Идём в кэш EDNS, смотрим, есть ли информация – поддерживает ли он EDNS, и какую версию, или не поддерживает вообще Если информация есть – отправляем запрос, исходя из этой информации. Если нет – добавляем поле OPT – мол, мы хотим EDNS, что ответишь? Если информации не было, то в зависимости от ответа сервера пишем в кэш EDNS строчку – мол, такой-то сервер или обработал наш пакет правильно, или сообщил, что ничего не понял Примечание: Как понятно, EDNS0 – это не одно слово, а расширение-dns-версия-нулевая. Предполагалось, что таких расширений будет много, и они будут различаться по версиям. Например, первая версия – EDNS1 – будет включать в себя всё, что включала нулевая, плюс ещё что-то. По факту сейчас есть только EDNS1, и то в драфте – http://tools.ietf.org/html/draft-ietf-dnsext-edns1-03. Судя по тому, что документ за 2002й год…Как управлять EDNS0 в Windows Server 2008 R2
Достаточно просто. Включаем EDNS Probes – т.е. алгоритм выяснения, поддерживают ли upstream DNS servers стандарты EDNS:dnscmd /Config /EnableEDNSProbes 1
Как понятно, выключаем, меняя единицу на нуль – тогда наш сервер не будет пытаться добавить OPT в запрос. Время жизни информации о поддержке EDNS другим сервером задаётся так:
dnscmd /Config /EDNSCacheTimeout время в секундах
Оптимально – включить EDNS Probe и поставить тайм-аут кэша на хорошее число – например, неделю. Просто очень навряд ли будет ситуация, когда сервер, на который Вы форвардите DNS-запросы, поддерживал EDNS, а потом резко перестал, а потом опять начал. Поэтому имеет смысл увеличивать время кэша. Это ведь, например, позитивно повлияет на размеры трафика – Ваш сервер будет реже добавлять опциональное поле в свои запросы.
