Безопасность DNS (часть 2): меры безопасности DNS перед развертыванием DNSSEC
Введение
В части 1 этой серии статей, состоящей из нескольких частей, посвященной безопасности DNS, я рассмотрел некоторые основные вопросы, относящиеся к безопасности DNS, чтобы повысить вашу осведомленность о некоторых общих соображениях, с которыми вы столкнетесь, когда начнете планировать безопасность для вашей DNS-инфраструктуры. Теперь мы перейдем к следующему шагу: что вы можете сделать, чтобы обезопасить свою инфраструктуру Windows DNS до развертывания «ядерного варианта», который заключается в развертывании DNSSEC в вашей среде. Я рекомендую вам выполнить эти шаги перед развертыванием DNSSEC, потому что вы хотите убедиться, что ваша инфраструктура DNS стабильна и что у вас есть разумный период адаптации после выполнения этих основных задач безопасности, прежде чем вы достанете большие пушки DNSSEC.
В этой статье мы подробно рассмотрим следующие предварительные шаги, которые вы можете предпринять, чтобы защитить свою инфраструктуру Windows DNS:
- Решите, кто может разрешать имена хостов в Интернете
- Не совмещайте внутреннюю и внешнюю зоны
- Заблокируйте кеш DNS
- Включить рекурсию только там, где это необходимо
- Ограничить DNS-серверы для прослушивания определенных адресов
- Рассмотрите возможность использования частного файла корневых подсказок
- Рандомизируйте исходные порты DNS
- Помните о глобальном черном списке запросов
- Ограничение трансферов по зонам
- Воспользуйтесь преимуществами безопасности интегрированной зоны Active Directory
Решите, кто может разрешать имена хостов в Интернете
Это может показаться элементарным, но легко упустить из виду тот факт, что не всем в сети нужно иметь возможность разрешать имена хостов в Интернете. В большинстве случаев ваши внутренние хосты должны иметь возможность разрешать только внутренние имена, и единственными машинами, которые должны иметь возможность разрешать имена хостов в Интернете, являются шлюзовые устройства, такие как веб-прокси-серверы или прокси-серверы Winsock (например, брандмауэр TMG).. При разработке инфраструктуры разрешения имен DNS можно настроить большинство компьютеров для использования DNS-серверов, которые размещают только внутренние имена и не выполняют рекурсию для общедоступных имен. Затем вы можете настроить отдельную инфраструктуру DNS, которая выполняет разрешение имен в Интернете для машин, которые должны иметь возможность разрешать общедоступные имена хостов. На этих DNS-серверах вы можете настроить зоны переадресации, чтобы веб-прокси и прокси-серверы Winsock (и другие машины, которым необходимо разрешать внутренние имена хостов) также могли разрешать внутренние имена.
Не совмещайте внутреннюю и внешнюю зоны
Организации, развертывающие разделенную инфраструктуру DNS, будут использовать одни и те же доменные имена как для внутреннего, так и для внешнего разрешения имен. Например, если имя вашего внутреннего домена — corp.contoso.com, вы также можете использовать то же имя, corp.contoso.com, для разрешения внешнего имени. Преимущество этого заключается в том, что хосты могут преобразовывать имена в соответствующие адреса независимо от их местоположения, а пользователям не нужно перенастраивать приложения в зависимости от их текущего местоположения (внутри сети или вне сети).
В то время как разделенная инфраструктура DNS работает нормально и выполняет то, что она должна делать, проблема, которую я иногда вижу (более типичная для малого бизнеса, но я видел, что более крупные компании делают то же самое), заключается в том, что компания будет размещать внутренние и внешние имена. в той же зоне. Это может вызвать потенциальную проблему безопасности, поскольку внешний злоумышленник может потенциально скомпрометировать общедоступный сервер и получить информацию не только обо всех ваших внешних именах (что не так уж важно, поскольку вы хотите, чтобы люди знали ваши общедоступные имена)., но также и частные имена машин в интрасети, о которых злоумышленник не должен знать.
Эту проблему безопасности легко решить, используя отдельные DNS-серверы и отдельные зоны для внутренних и внешних имен. Ваша внешняя зона может размещаться у интернет-провайдера или вы можете разместить ее самостоятельно на DNS-сервере, расположенном в демилитаризованной зоне. Частная зона остается во внутренней сети и никогда не доступна внешним пользователям.
Заблокируйте кеш DNS
Кэш DNS на DNS-сервере позволяет DNS-серверу возвращать результаты успешных запросов из кеша вместо того, чтобы снова обращаться к другим DNS-серверам для получения информации. Ответы на запросы обычно поступают из кеша для времени жизни (TTL) кэшированной записи. Это может значительно улучшить общую производительность DNS, поскольку серверу не нужно выходить и повторно выдавать запросы для имен, которые DNS-сервер недавно успешно разрешил.
Однако есть некоторые атаки, основанные на возможности перезаписать кэшированную запись до истечения срока жизни. Вы можете предотвратить подобные атаки, включив блокировку кеша на DNS-сервере. Кроме того, блокировка кеша поможет защитить ваш сервер от атак с отравлением кеша.
По умолчанию DNS-серверы Windows Server 2008 R2 устанавливают значение блокировки кэша, равное 100, что означает, что DNS-сервер не перезапишет кэшированное значение, пока не истечет срок жизни записи DNS. Вы можете изменить это значение, если хотите, с помощью команды dnscmd:
dnscmd /Config /CacheLockingPercent<процент>
Процентное значение может варьироваться от 0 до 100.
Включайте рекурсию только там, где это необходимо
Рекурсия — это процесс, который DNS-сервер использует для разрешения имен, для которых он не является полномочным. Если DNS-сервер не содержит файл зоны, который является авторитетным для домена в запросе, DNS-сервер перенаправит соединение на другие DNS-серверы, используя процесс рекурсии. Проблема в том, что DNS-серверы, выполняющие рекурсию, более уязвимы для атак типа «отказ в обслуживании» (DoS). По этой причине вам следует отключить рекурсию на DNS-сервере в вашей организации, который будет отвечать только на те запросы, для которых он является авторитетным — обычно это означает запросы к вашим внутренним ресурсам.
Вы можете отключить рекурсию в диалоговом окне «Свойства» вашего DNS-сервера, как показано на рисунке ниже. Имейте в виду, что если вы отключите рекурсию, это также отключит все настроенные вами серверы пересылки.
фигура 1
Ограничить DNS-серверы для прослушивания определенных адресов
Часто у DNS-сервера есть несколько IP-адресов, назначенных одному сетевому адаптеру, или к DNS-серверу подключено несколько сетевых адаптеров. По умолчанию DNS-сервер прослушивает DNS-запросы на всех интерфейсах и IP-адресах, привязанных к этим интерфейсам. Вы можете немного улучшить безопасность и аудит, заблокировав интерфейсы и IP-адреса на DNS-сервере, которые будут принимать DNS-запросы. На рисунке ниже показано диалоговое окно «Свойства» DNS-сервера, в котором вы можете применить этот параметр. Выберите параметр Только следующие IP-адреса, а затем снимите флажки с флажков, для которых вы не хотите, чтобы DNS-сервер принимал запросы.
фигура 2
Рассмотрите возможность использования частного файла корневых подсказок
Когда DNS-сервер Windows Server 2008 R2 работает на контроллере домена, корневые ссылки сначала получаются из Active Directory. Если DNS-сервер не работает на контроллере домена, корневые ссылки берутся из файла cache.dns, расположенного по адресу %systemroot%System32Dns. Корневые подсказки используются, чтобы сообщить DNS-серверу, где начать процесс рекурсии. Корневые ссылки обычно указывают на корневые DNS-серверы Интернета, поэтому вы можете разрешать общедоступные имена хостов с помощью рекурсии.
Однако, если вам не нужно разрешать общедоступные имена хостов, вы можете отредактировать файл корневых подсказок, чтобы он содержал только DNS-серверы в вашей интрасети. Делая это, вы можете избежать отправки частной информации о возможных внутренних именах хостов на общедоступные DNS-серверы.
На рисунке ниже показана вкладка Root Hints в диалоговом окне свойств DNS-сервера. Вы можете добавлять, редактировать, удалять или копировать записи корневых подсказок сервера с помощью кнопок на этой вкладке.
Рисунок 3
Рандомизируйте исходные порты DNS
Существуют некоторые DNS-атаки, которые могут использовать предсказуемость исходного порта для ответов DNS, отправляемых компьютером. Предсказуемость может позволить злоумышленнику перехватить ответ DNS-клиенту и отправить его на сайт, находящийся под контролем злоумышленника. Вы можете снизить риск успешной атаки, увеличив количество исходных портов, доступных для рандомизации.
Вы делаете это, увеличивая размер пула сокетов. Для DNS-серверов Windows Server 2008 R2 размер пула сокетов по умолчанию составляет 2500. Вы можете увеличить количество доступных сокетов для рандомизации до максимального значения 10 000.
Используйте следующую команду dnscmd, чтобы изменить значение пула сокетов:
dnscmd /Config /SocketPoolSize<значение>
Если вы хотите увидеть текущий размер пула сокетов, используйте эту команду dnscmd:
Dnscmd/Info/SocketPoolSize
Вы также можете исключить диапазоны портов, используемых пулом сокетов, с помощью следующей команды dnscmd:
dnscmd /Config /SocketPoolExcludedPortRanges<исключенные диапазоны портов>
Имейте в виду, что для поддержки большего количества сокетов потребуется больше памяти. В Windows Server 2008 R2 для каждого сокета выделяется около 2,5 КБ памяти плюс 7,2 КБ памяти на буфер приема. Количество приемных буферов равно двум на однопроцессорном или двухпроцессорном сервере и равно количеству ЦП, если их больше двух.
Помните о глобальном черном списке запросов
Начиная с Windows Server 2003 R2, имена можно было исключить из списка ответов DNS-сервера, добавив их в глобальный черный список запросов. По умолчанию имена WPAD и ISATAP автоматически включаются в глобальный черный список запросов DNS-сервера. Это означает, что даже если вы добавите запись ресурса для WPAD или ISATAP, DNS-сервер не будет отвечать на запросы для этих имен.
Вы можете включить или отключить список глобальных блокировок запросов с помощью следующей команды dnscmd:
dnscmd [<ServerName>] /config /enableglobalqueryblocklist 0|1
Если вы хотите увидеть, какие имена в настоящее время введены в глобальный черный список запросов, используйте следующую команду dnscmd:
dnscmd [<ServerName>] /config /enableglobalqueryblocklist 0|1
Если вы хотите добавить имя в список, используйте эту команду:
dnscmd [<ServerName>] /config /globalqueryblocklist [<name> [<name>]…]
Ограничение трансферов по зонам
Злоумышленники могут узнать все имена в вашей зоне, если вы включите передачу зон. Хотя это не является серьезной проблемой для общедоступных зон DNS, вам следует ограничить круг лиц, которые могут выполнять передачу зон для ваших частных зон. Клиенты не должны знать о вашем пространстве имен больше, чем им необходимо для подключения к необходимым им ресурсам.
По умолчанию передача зон не включена. Но если вы хотите включить их (не требуется для зон, интегрированных с Active Directory), вы можете зайти в диалоговое окно «Свойства» зоны и установить флажок «Разрешить передачу зоны» на вкладке «Передача зоны ». Затем используйте параметр «Только для следующих серверов», чтобы указать IP-адреса, на которые вы хотите разрешить передачу зон.
Рисунок 4
Воспользуйтесь преимуществами безопасности интегрированной зоны Active Directory
Интегрированные зоны Active Directory позволяют защитить регистрацию записей ресурсов, если включена динамическая регистрация имен. Члены домена Active Directory могут динамически регистрировать свои записи ресурсов, в то время как нечлены домена не смогут регистрировать свои имена. Вы также можете использовать списки управления доступом на уровне пользователей (DACL), чтобы контролировать, какие компьютеры могут регистрироваться или изменять свою адресную информацию.
На рисунке ниже показано, как настроить безопасные динамические обновления.
Рисунок 5
Резюме
Во второй части статьи, состоящей из нескольких частей, мы рассмотрели некоторые вещи, которые вы можете сделать, чтобы помочь защитить свою инфраструктуру Windows DNS, прежде чем вытаскивать «большую артиллерию» и развертывать DNSSEC. В следующей части этой серии мы поговорим о DNSSEC для Windows Server 2008 R2, а также о процессе и процедурах интеграции DNSSEC в вашу среду. Тогда увидимся! -Деб.