Принципы безопасного развертывания сервисов DNS

Транзакции DNS

Существуют следующие типы DNS-транзакций:

• запрос / ответ DNS;
• зонная пересылка;
• динамические обновления;
• DNS NOTIFY.

Опишем каждый из этих типов.

Запрос / ответ DNS

Это наиболее распространенная транзакция в DNS. Запрос DNS исходит от resolver’а; получателем является авторитетный или кэширующий name-сервер. Наиболее распространенным запросом является поиск ресурсной записи по имени владельца или типу. Ответ может состоять из единственной ресурсной записи, множества ресурсных записей или сообщения о соответствующей ошибке.

Существует два типа запросов: нерекурсивный и рекурсивный. DNS-resolver’ы, которые обычно посылают нерекурсивные запросы, как правило, предоставляют более стабильные ответы, потому что они могут переходить по referral’ам для получения окончательного ответа на запрос. Если они также имеют кэш DNS, они могут обладать достаточно полной информацией о пространстве name-серверов в DNS, полученной из ответов на предыдущие запросы. Это может быть использовано для уменьшения времени ответа на последующие запросы. Рекурсивные запросы обычно посылаются от stub resolver’ов, которые не имеют возможности выполнять сложные операции DNS. Вместо этого они полагаются на вышележащий сервер DNS (обычно name-сервер с кэшем, который посылает нерекурсивные запросы от имени нескольких stub resolver’ов) для выполнения запроса и возврата окончательного ответа.

Запросы DNS посылаются в виде одного UDP-пакета. Ответ обычно также является одним UDP-пакетом, но данные могут быть усечены – в этом случае выполняется повторный запрос с использованием ТСР. UDP используется потому, что он требует меньше вычислительных ресурсов и является более быстрым, чем ТСР, который требует процедуры установления соединения.

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

Зонная пересылка

Зонная пересылка является способом, которым вторичный (slave) сервер обновляет все содержимое своего зонного файла от первичного (master) сервера. Этот процесс дает возможность вторичному name-серверу поддерживать свой зонный файл в синхронном состоянии с первичным name-сервером. Транзакция зонной пересылки начинается в виде запроса от вторичного name-сервера к первичному name-серверу. Запрос зонной пересылки – в противоположность запросу DNS – запрашивает все ресурсные записи из зоны вместо конкретных ресурсных записей для данного владельца или типа. Этот запрос начинается с вторичного name-сервера либо в ответ на сообщение DNS NOTIFY, либо основываясь на значении элемента данных Refresh в поле RData в Start of Authority (SOA) ресурсной записи.

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

Динамические обновления

Если происходит добавление, удаление или перемещение сетевых ресурсов (например, серверов баз данных, web-серверов, почтовых серверов или name-серверов), соответствующие изменения необходимо делать в зонном файле, содержащим информацию о доменах, в которых размещены эти ресурсы. На ранних стадиях развития DNS администратор зоны делал такие изменения вручную. Когда такие изменения становятся большими и частыми, ручное изменение затрудняется, поэтому было введено понятие динамического обновления. Независимо от объема и частоты обновлений, существуют некоторые приложения, которые требуют немедленных автоматических изменений зонного файла с помощью прикладных программ. Примерами этого являются серверы DHCP.

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

В некоторых случаях DNS-сервер может использоваться в качестве репозитория сертификатов открытого ключа. При этом СА получает открытый ключ от пользователя, подписывает его своим закрытым ключом для создания сертификата и хранит данный сертификат в ресурсной записи с типом CERT (CERT RR) в зонном файле.

В RFC 2136 описан механизм динамического изменения, который затем был реализован в BIND 8-й версии и поддерживается во всех последующих версиях.

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

Набор операций для динамического изменения определен следующим образом:

• Добавить или удалить отдельные ресурсные записи для существующего домена.
• Удалить конкретные RRSets (множество ресурсных записей с одним и тем же именем владельца, классом или RRType – например, множество ресурсных записей с RRType NS для имени домена example.ru ) для существующего домена.
• Удалить существующий домен (все ресурсные записи для данного доменного имени – например, все ресурсные записи для домена example.ru ).
• Добавить новый домен (одну или более ресурсных записей для нового домена – например, добавление ресурсной записи типа А для нового домена new.example.ru ).

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

DNS NOTIFY

Всякий раз, когда выполняются изменения в зонном файле первичного (master) DNS-сервера, вторичные (slave) DNS-серверы, которые содержат идентичные данные, должны быть уведомлены об изменениях. Такое уведомление выполняется посредством сообщения DNS NOTIFY, которое указывает, что вторичному DNS-серверу следует начать зонную пересылку. Сообщение DNS NOTIFY является более быстрым и эффективным способом поддержки синхронизации вторичных серверов с первичным сервером, чем альтернативный подход, при котором вторичные серверы запрашивают первичный сервер об изменениях с помощью значения времени в SOA Refresh.

Посылка сообщения DNS NOTIFY, называемая операцией notify, является способом синхронизации по умолчанию в BIND 9.x. Возникает вопрос: как name-сервер узнает, каким серверам сообщение DNS NOTIFY должно быть послано? В BIND 9.x уведомление посылается серверам, которые определены в NS ресурсных записях для зоны. Если существуют дополнительные серверы, которым администратор зоны хочет посылать сообщение DNS NOTIFY (так называемые невидимые slave-серверы), администратор DNS может добавить IP-адреса этих серверов в конфигурационный файл BIND. Администратор может также с помощью конфигурационных опций не разрешать серверу посылать сообщения NOTIFY о некоторых зонах, обслуживаемых данным name-сервером.

После того как вторичный сервер получил сообщение DNS NOTIFY, он посылает запрос зонной пересылки к первичному серверу, независимо от того, как давно в последний раз зонная пересылка осуществлялась. Данная процедура позволяет распространять изменение зоны всем вторичным name-серверам более быстро.

Так как сообщение DNS NOTIFY запускает зонную пересылку, ложные сообщения DNS NOTIFY могут привести к ненужным зонным пересылкам и, следовательно, потенциальным DoS-атакам.