Безопасность DNS Query/Response

Пример создания пары ключей

Любое ПО name-сервера поддерживающего DNSSEC должно предоставлять программную утилиту для создания пары асимметричных ключей. Проиллюстрируем использование одной из таких программ, dnssec-keygen (имеющейся в BIND 9.3.x):

dnssec-keygen –a algorithm –b bits –n type [options] name

где algorithm может быть один из следующих:

• RSAMD5
• DSA

bits (длина ключа) имеет следующие диапазоны:

• 512 4096 для RSA-MD5
• 512 1024 для DSA

type может быть одним из ZONE или HOST. В принципе, могут быть добавлены и любые другие типы ключей.

name есть имя собственника ключа (обычно имя домена).

Данная команда создает два файла: один содержит открытый ключ, а другой файл — соответствующий ему закрытый ключ. Имена этих файлов следующие:

K<domain_name>+algorithm_id+Key_id.key
K<domain_name>+algorithm_id+Key_id.private

domain_name является значением параметра name, указанного в командной строке. Algorithm_id может быть следующим:

3 – DSA

5 – RSAMD5

key_id есть уникальный идентификатор созданного ключа, созданного программой.

Например, для создания ZSK-ключа длиной 1024 бит, который использует набор алгоритмов RSAMD5 для подписывания зоны example.ru, должна быть выполнена следующая команда:

dnssec-keygen –a RSAMD5 –b 1024 –n ZONE example.ru

Будут созданы следующие файлы, содержащие закрытый и открытый ключи:

Kexample.ru.+005+28345.private
Kexample.ru.+005+28345.key

В этих именах файлов 005 определяет algorithm_id и 28345 есть уникальный идентификатор ключа.

В *.key файле информация открытого ключа имеет тот же самый синтаксис, что и ресурсной записи в зонном файле. Содержимое файла Kexample.ru.+005+28345.key следующее:

example.ru IN DNSSEC 256 3 5 BQFG...... (строка ключа в Base64)

Следовательно, содержимое файла с открытым ключом может быть добавлено к содержимому зонного файла с помощью следующей команды:

cat *.key >> /var/named/zonedb.example.ru

После того как ресурсная запись DNSKEY, содержащая открытый ключ, добавлена в зонный файл, Serial Number зоны должен быть увеличен до того, как будет выполнено подписывание зоны.

Безопасное хранение закрытых ключей (DNSSEC-OP2)

Закрытые ключи из KSK и ZSK пар ключей должны быть защищены от неавторизованного доступа. В идеале, закрытые ключи должны храниться off-line на физически безопасной, не доступной из сети машине вместе с мастер-копией зонного файла. Подписи, создаваемые с использованием закрытых ключей, должны пересылаться на первичные авторитетные name-сервера посредством процесса загрузки, используя динамически устанавливаемое сетевое соединение (а не постоянный сетевой канал).

Данная стратегия неосуществима в ситуациях, когда поддерживающий DNSSEC name-сервер должен выполнять динамические обновления. Для поддержки транзакций динамических обновлений name-сервер (который обычно является первичным авторитетным name-сервером) должен иметь как мастер-копию зонного файла, так и соответствующий закрытый ключ для подписывания зоны (ZSK-private) в режиме on-line для немедленного обновления подписей для измененных ресурсных записей. Закрытый ключ из KSK (KSK-private) может, тем не менее, храниться off-line. В этом случае должны быть предприняты следующие меры для защиты ZSK-private:

1. shell, из которого вызывается утилита создания ключа, должен быть недоступен для всех, за исключением администратора зоны.
2. Директория, в которой хранятся файлы закрытых ключей (обычно это поддиректория с тем же именем, что и зона, с именами файлов, имеющими структуру имени K<zonename>.AlgorithmID+<keytag>.private в BIND), должна быть недоступна и невидима для всех, за исключением администратора зоны.
3. Возможность быстрого восстановления должна быть обеспечена тем, что имеется зеркальный диск или выполняется периодический backup на съемный носитель.
4. Другая стратегия состоит в хранении закрытых ключей в зашифрованной файловой системе.

Рекомендация:

Закрытые ключи, соответствующие как ZSK, так и KSK, не должны храниться в поддерживающем DNSSEC первичном авторитетном name-сервере, если name-сервер не должен выполнять динамических обновлений. Если динамические обновления поддерживаются, то только закрытый ключ, соответствующий ZSK, должен храниться на name-сервере в директории и файле с соответствующем управлением доступа или криптографически защищенным.

Опубликование открытого ключа (DNSSEC-OP3) и конфигурирование доверенных anchor’ов (DNSSEC-OP7)

Проверка данных зоны resolver’ом начинается с того, что resolver знает открытый ключ данной зоны (той, чьи данные он проверяет) или любой из открытых ключей зон, расположенных выше в дереве DNS. Если проверяемая зона (например, example.ru ) поддерживает безопасность (т.е. поддерживает DNSSEC ), а ее родитель ( .ru ) — нет, то точка доверия начинается с самой зоны. Если зона родителя (зона .ru ) поддерживает безопасность, а зона выше по дереву (зона root) — нет, начальной точкой доверия является родитель (т.е. зона .ru ). Если зона root поддерживает безопасность, то она становится исходной точкой доверия.

В любом случае открытый ключ данной начальной точки должен быть известен resolver’ам. Такие открытые ключи, известные resolver’ам, называются доверенными anchor’ами. Поскольку не существует возможности средствами DNS выполнить проверку этих открытых ключей, открытый ключ доверенного anchor’а должен распространяться внешним по отношению к DNS способом. Данное распространение может быть осуществлено с использованием таких каналов, как web-сайты или e-mail.

Список доверенных anchor’ов в поддерживающем DNSSEC resolver’е определяет, какой подписанный ответ от зоны будет рассматриваться как безопасный, а какой — нет. Как уже отмечалось, resolver должен установить доверие к открытому ключу зоны, из которой он получил ответ, перед тем как выполнить проверку подписи. Если такое доверие не может быть установлено с помощью построения доверенной цепочки, используя записи в списке доверенных anchor’ов, ответ должен помечаться как небезопасный. Причина, по которой отсутствует возможность построения доверенной цепочки, может состоять в том, что пространство имен DNS содержит только отдельные участки подписанных зон вместо непрерываемой иерархической последовательности подписанных зон. Предположим, что дерево DNS имеет следующую структуру.

Тогда статус ответа (безопасный или небезопасный) зависит от списка хранящихся в resolver’е доверенных anchor’ов и от того, из какой зоны получен ответ.

Рис. 8.2. "Острова" подписанных зон

Результат приведен в таблице.

Подписывание зоны (DNSSEC-OP4)

При подписывании зонного файла выполняется следующая последовательность действий:

1. Зонный файл сортируется в каноническом порядке доменных имен.
2. Создается ресурсная запись NSEC для каждого имени собственника в зоне.
3. Используется ключ KSK (KSK-private) для подписывания множества ресурсных записей DNSSEC. Ключ KSK определяется по наличию установленного флага SEP в RDATA в ресурсной записи DNSSEC.
4. Ключ ZSK (ZSK-private) используется для подписывания всех ресурсных записей в зоне (включая ресурсные записи DNSKEY и NSEC ).

Рекомендации:

1. Создание подписи с использованием ключа KSK должно выполняться off-line, используя KSK-private, также хранимый off-line; затем ресурсные записи DNSKEY вместе в ресурсной записью RRSIG должны быть размещены в первичном авторитетном name-сервере.
2. Хранение ключа ZSK-private и создание подписи с использованием этого ключа должно выполняться off-line; ресурсные записи вместе с RRSIG ресурсными записями затем могут быть записаны в первичный авторитетный name-сервер. Исключением является случай, когда name-сервер поддерживает динамические обновления. В этом случае ZSK-private должен располагаться в name-сервере.