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

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

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

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

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

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

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:

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

Закрытые ключи, соответствующие как 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’ов и от того, из какой зоны получен ответ.

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

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

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

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

Пример подписывания зоны

Приведем пример, иллюстрирующий использование программы подписывания зоны (dnssec-signzone в BIND 9.3.x):

dnssec-signzone –o <name of zone> -k <name of file containing KSK> 
   <location of zone file> <name of file containing ZSK>

Для подписывания данных из зоны example.ru с KSK, расположенным в файле Kexample.ru.+005+76425.key, и ZSK, созданным заранее, следует выполнить следующую команду:

dnssec-signzone –o example.ru -k Kexample.ru.+005+76425.key
   /var/named/zonedb.example.ru Kexample.ru.+005+28345.key

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

Ключ KSK подписывает только множество ресурсных записей DNSKEY, а ключ ZSK — все ресурсные записи в зонном файле. Участник, чей закрытый ключ используется для подписывания данных зоны, называется подписывающей стороной (signer или signing authority). В большинстве случаев подписывающая сторона является доменом, связанным с зоной. В ответ на DNS-запрос поддерживающий DNSSEC авторитетный name-сервер выдает соответствующие данные зоны вместе с цифровой подписью этих данных. Получатель проверяет цифровую подпись для полученных данных зоны, используя открытый ключ подписавшего (после установления доверия к открытому ключу).

Создание доверенной цепочки и проверка подписи (DNSSEC-OP8)

До тех пор, пока все зоны не станут подписанными, возможна ситуация, при которой зона является подписанной, но ее родитель не является подписанной зоной. Единственной точкой доверия для поддерживающего DNSSEC resolver’а в этом случае может считаться заранее сконфигурированный открытый ключ подписывающей стороны. При отсутствии другого источника, подтверждающего достоверность открытого ключа подписывающей стороны, требуется, чтобы открытый ключ был получен безопасным способом. В противном случае, если существует домен X, который может подтвердить достоверность открытого ключа домена Y, resolver может установить доверие к подписывающей стороне Y, используя X. Последовательность зон в дереве DNS, с помощью которых resolver устанавливает доверие к открытому ключу подписывающей стороны, называется цепочкой доверия.

Будем считать, что цепочка доверия начинается с домена X и заканчивается доменом Y. Обычно домен X является непосредственным родителем Y и называется родительской зоной. Родительская зона обеспечивает доказательство достоверности открытого ключа дочерней зоны, подписывая ее ключ. Данная подпись хранится в ресурсной записи, называемой Delegation Signer ( DS ). Родительская зона также должна быть подписанной зоной, потому что неподписанная зона не умеет создавать подписи. Таким образом, подписанная зона может быть одного из следующих типов.

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

Для глобально безопасной зоны существуют дополнительные задачи. Чтобы обеспечить возможность создания цепочки доверия, зона должна безопасным образом (внешним по отношению к сервисам DNS) передать родительской зоне свой открытый ключ (KSK-public). Затем родитель создает хэш этого открытого ключа дочерней зоны и хранит его в своей зоне в виде новой ресурсной записи, называемой DS. Он подписывает эту ресурсную запись DS, создавая ресурсную запись RRSIG. Родителю передается ключ KSK, а не ключ ZSK, потому что в противном случае происходило бы следующее. Всякий раз, когда зона изменяет свой ZSK, ее родитель должен был бы быть уведомлен о новом ключе. При этом родителю приходилось бы создавать новую ресурсную запись DS и снова подписывать ее. Для уменьшения подобной административной нагрузки родительской зоне передается ключ KSK. KSK используется для подписывания только ресурсных записей DNSKEY ; все остальные ресурсные записи в зонном файле подписываются ZSK. KSK является тем ключом, который опубликовывается у родителя. Родитель создает ресурсную запись DS, содержащую ключ KSK дочерней зоны, создает подпись для данного KSK и размещает ее в ресурсной записи RRSIG. Ключ KSK создается достаточно большим (например, 2048 бит) по сравнению с ключом ZSK, который может быть, например, длиной 1024 бит и, следовательно, должен изменяться менее часто.

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

Зона, подписывающая ответ, является конечной точкой в цепочке доверия. Предварительно необходимо установить доверие к ZSK для зоны. Доверие к ZSK зоны устанавливается посредством следующих операций:

Для понимания обработки аутентифицированной ссылки, которая находится у родителя, необходимо посмотреть, как обрабатывается обычная ссылка DNS. В обычном DNS-запросе зона, которая не имеет авторитетной информации, относящейся к запросу для доменного имени в дочерней зоне, предоставляет ссылку, указывая множество ресурсных записей NS и соответствующие относящиеся к ним ресурсные записи (ресурсные записи, которые содержат IP-адреса серверов, указанных в ресурсных записях NS). При обычной обработке DNS-запроса следование по этим ссылкам будет следующим шагом обработки. Однако данный процесс является недостаточным с точки зрения установления цепочки доверия; информация о множестве ресурсных записей NS и связанных с ними ресурсными записями не может считаться аутентичной, потому что они не подписаны закрытым ключом аутентичного источника. Аутентификацию данной информации о ссылке родитель предоставляет криптографическим способом с помощью ресурсной записи DS.

Рассмотрим пример того, как поддерживающий DNSSEC resolver проверяет правильность DNS-ответа от подписанной зоны example.ru. Resolver, следуя по своей цепочке доверия, начинающейся от доверенного anchor’а, аутентифицирует открытый ключ для зоны .ru и тем самым доверяет ему. Следовательно, он доверяет ресурсным записям NS и DS в зоне .ru. Из ресурсной записи NS и связанных с ней ресурсных записей resolver определяет, что авторитетный name-сервер для example.ru есть ns.example.ru, и он также знает его IP-адрес. Используя данную информацию, он идет на ns.example.ru и получает ключ KSK для example.ru из его множества ресурсных записей DNSKEY. Он вычисляет хэш данного ключа и сравнивает его с хэшем в ресурсной записи DS его родительской зоны .ru. Равенство этих двух хэшей означает, что ссылка из .ru зоны на example.ru зону аутентифицирована; аутентифицирован также и ключ KSK example.ru зоны. Так как ключ ZSK подписан ключом KSK example.ru, resolver может получить ключ ZSK example.ru аутентифицированным способом. Так как ключ ZSK подписывает все ресурсные записи в example.ru, действительность любого подписанного ответа из данной зоны может быть определена с использованием ключа ZSK, который уже аутентифицирован.

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

Безопасность ответов кэширующего name-сервера

Некоторые name-серверы могут быть авторитетными для одних зон и не являться авторитетными для других. Для зон, для которых они не являются авторитетными, они выполняют кэширование ресурсных записей из предыдущих запросов, полученных для этих зон. Поддерживающий DNSSEC кэширующий name-сервер имеет дополнительные задачи, связанные с его функциями кэширования. Эти задачи относятся к определению состояния безопасности ответа, содержащего ресурсные записи, и последующего его кэширования. Существуют три возможных состояния множества ресурсных записей.

Когда поддерживающий DNSSEC кэширующий name-сервер получает запрос от не поддерживающего безопасность resolver’а, resolver получает как безопасные, так и небезопасные данные из кэша сервера. Так как данный запрос передан небезопасным способом, ресурсная запись DNSSEC не включается в ответ, тем самым применяется только обычная обработка DNS.

Поддерживающие DNSSEC resolver’ы получают либо безопасные, либо и безопасные, и небезопасные данные от поддерживающего DNSSEC кэширующего сервера с установленным в заголовке ответа битом. Этот Authenticated Data ( AD ) бит в заголовке указывает, что множества ресурсных записей в ответе прошли или не прошли все проверки безопасности, выполненные кэширующим name-сервером. Клиент может решить, полагаться ли ему на данную проверку или выполнить свое собственное множество проверок безопасности.

В некоторых случаях клиент может захотеть получить фальшивые данные от кэширующего name-сервера. В этом случае клиент посылает запрос с установленным Checking Disabled ( CD ) битом в заголовке DNS-сообщения. Это дает поддерживающему DNSSEC кэширующему name-серверу команду отвечать фальшивыми данными из BAD кэша. Клиент должен затем выполнить свою собственную проверку множества ресурсных записей в ответе. В таких типах ответов сервер не устанавливает AD бит, указывая, что ответ не прошел все проверки безопасности, выполняемые сервером.

Дополнительные меры защиты для DNS Query / Response

Спецификации DNSSEC для защиты транзакций DNS Query / Response определяет следующие типы ответов:

Так как большинство запросов первоначально исходят от stub resolver’а (от имени ПО клиента, требующего доступ к ресурсу в Интернете), защита сообщения DNS ответа должна также обеспечиваться для stub resolver’а от рекурсивного name-сервера. Способ обеспечения защиты на этом участке, который часто называется DNS "last hop", определяется природой stub resolver’а и топологией сети.

Stub resolver может:

Большинство stub resolver’ов, существующих сегодня, не поддерживают DNSSEC. Другими словами, они не имеют возможности проверить цифровые подписи, связанные с полученными множествами ресурсных записей, и также не могут отличить аутентифицированный ответ (проверяя его подпись) от неаутентифицированного ответа, передаваемого им их локальными рекурсивными name-серверами. Чтобы создать полную end-to-end защиту для DNS Query / Response, эти типы stub resolver’ов как минимум должны иметь возможность выполнять аутентификацию источника и проверку целостности данных в ответах, пришедших от рекурсивного name-сервера, который предоставляет им сервис разрешения имен. Такая возможность может быть обеспечена использованием подхода НМАС, заданного в TSIG (где описано использование НМАС для защиты транзакций зонных пересылок и динамических обновлений). В качестве альтернативы защиту можно обеспечить с помощью других механизмов сетевой безопасности, таких как IPsec. Независимо от механизма, используемого для обеспечения безопасности канала "last hop" (от рекурсивного name-сервера к stub resolver), данная возможность также должна присутствовать в поддерживающих DNSSEC и не проверяющих правильность ответа stub resolver’ах в дополнение к не поддерживающим DNSSEC stub resolver’ам. Поддерживающий DNSSEC, но не проверяющий правильность ответа stub resolver может увеличить доверие к этому ответу, проверяя значение AD бита в заголовке сообщения в полученном ответе. Данные типы stub resolver’ов могут затем использовать этот бит в качестве признака того, что рекурсивный name-сервер имеет возможность проверять действительность подписей для данных в ответе.

В некоторых ситуациях установление доверенного пути между stub resolver’ами и рекурсивными name-серверами не предоставляется возможным. Примером является ситуация, когда рекурсивный name-сервер не расположен в административном домене предприятия, а выполняется у провайдера. В такой ситуации end-to-end защита может быть обеспечена только при наличии поддерживающего DNSSEC stub resolver’а. Поддерживающий DNSSEC stub resolver может уведомить локальный рекурсивный name-сервер, что он хочет сам выполнить проверку действительности подписи, установив Checking Disabled ( CD ) бит в свои сообщения запроса.

Динамические обновления в поддерживающей DNSSEC-зоне

Напомним возможные операции над зонным файлом при выполнении динамических обновлений. Можно считать, что имеются две основные операции: добавление ресурсных записей и их удаление. Обновление можно рассматривать как комбинацию из операций добавления и удаления. В небезопасной зоне добавление и удаление ресурсных записей не вызывают никакой другой операции в оставшихся ресурсных записях в зонном файле. Однако в безопасной зоне существует NSEC -ресурсная запись (и соответствующая RRSIG -ресурсная запись) на каждую область в пространстве имен.

Имеется одна NSEC -ресурсная запись для каждого уникального имени владельца в зоне. Данная NSEC -ресурсная запись указывает на следующее имя владельца в каноническом порядке (упорядоченность, полученная лексикографической сортировкой доменных имен внутри зоны). NSEC -ресурсная запись для последнего имени владельца в каноническом порядке указывает на имя корня зоны (другими словами, имя зоны). Следовательно, концептуально эти записи образуют циклический список, в котором перечислены уникальные доменные имена в зоне

Рассмотрим содержимое ресурсных записей NSEC для зоны example.ru. Предположим следующую каноническую упорядоченность доменных имен в зоне:

example.ru
	IN	SOA	 ns.example.ru admin.example.ru (12985 3600 2700 800 3600)
	IN	RRSIG ( SOA )
	IN	NS	 ns.example.ru.
	IN	RRSIG ( NS )
	IN	MX	 mail.example.ru.
	IN	RRSIG ( MX )
marketing.example.ru
	IN	A	192.253.101.9
	IN	RRSIG ( A )
	IN	MX	 mail.example.ru
	IN	RRSIG ( MX )
sales.example.ru
	IN	NS	 ns.example.ru.
	IN	RRSIG ( NS )
www.exapmle.ru
	IN	A	 192.253.101.10
	IN	RRSIG ( A )

Псевдоформат (содержащий только информационные поля) NSEC -ресурсных записей, который охватывает интервалы пространства имен, относящиеся к доменным именам и типам ресурсных записей, что находятся в каждом имени в зонном файле, является следующим (ниже приведены четыре ресурсных записи NSEC ):

example.ru	IN	NSEC	marketing.example.ru	(SOA NS MX RRSIG NSEC)
marketing.example.ru	IN	NSEC	sales.example.ru	(A MX RRSIG NSEC)
sales.example.ru	IN	NSEC	www.example.ru	(NS RRSIG NSEC)
www.example.ru	IN	NSEC	example.ru	(A RRSIG NSEC)

Заметим, что существует столько NSEC -ресурсных записей, сколько уникальных доменных имен в зоне. NSEC -ресурсная запись, чье имя есть example.ru, ссылается на следующий домен в каноническом порядке (например, marketing.example.ru ). То же самое выполняется для NS-ресурсных записей, относящихся к доменам marketing.example.ru и sales.example.ru. NSEC -ресурсная запись, относящаяся к последнему доменному имени (т.е, www.example.ru ), ссылается на первое доменное имя в зоне (т.е. example.ru ).

Когда получен запрос для " package.example.ru IN A " (т.е. запрос для зоны, которой не существует), авторитетный сервер отвечает NSEC множеством ресурсных записей, доказывая, что имя не существует в зоне. В данном случае ответ от сервера будет состоять из обычного DNS-ответа, указывающего, что имя не существует, и следующей информации:

Модификации NSEC -ресурсных записей, выполняется при следующих операциях:

Добавление нового типа ресурсной записи в существующий домен

Предположим, что новый почтовый хост добавлен в домен www.example.ru. Такое изменение требует добавления MX-ресурсной записи к данному имени домена. Следовательно, NSEC -ресурсная запись для www.example.ru должна быть модифицирована следующим образом:

www.example.ru	IN	NSEC	example.ru	( A MX RRSIG NSEC )

Удаление некоторого типа ресурсной записи из существующего домена

Предположим, что предприятие example.ru решило, что больше не требуется отдельного почтового сервера для сотрудников отдела маркетинга. Такое изменение требует удаления почтового сервера ( RRType = MX ) из домена marketing.example.ru. Модифицированная NSEC -ресурсная запись теперь выглядит следующим образом:

marketing.example.ru	IN	NSEC	sales.example.ru	(A RRSIG NSEC)

Добавление нового имени домена в зону

Чтобы заказчики могли работать в режиме on-line, предприятие решило добавить отдельный домен websales.example.ru. Также был добавлен отдельный name-сервер и множество новых хостов. Этот новый домен требует следующих изменений в зонном файле:

websales.example.ru	IN	NSEC	www.example.ru (A NS RRSIG NSEC)

sales.example.ru	IN	NSEC	websales.example.ru (A RRSIG NSEC)

Удаление домена из зоны

Предположим, предприятие решило, что все продажи теперь будут осуществляться только через Интернет. Так как хосты были созданы для выполнения данной функции в новом домене websales.example.ru, хосты в домене sales.example.ru больше не нужны. Поэтому все ресурсные записи, принадлежащие домену, должны быть удалены из зоны. Данное изменение включает следующие операции:

marketing.example.ru	IN	NSEC	websales.example.ru (A MX RRSIG NSEC)

Краткое резюме

Перечислим основные принципы, которым необходимо следовать при развертывании DNSSEC.

Минимизация раскрываемой DNS-информации

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

Существует вероятность, что атакующий попытается получить информацию о локальной сети с использованием сервисов DNS и использует данную информацию для выполнения атаки. Некоторые типы информации, например, IP-адреса публичных серверов, предназначены для того, чтобы быть доступными всем. Что касается другой информации, администратору DNS рекомендуется выполнить определенные действия при создании зонного файла, которые бы сводили раскрытие локальной сети к минимуму. Данный процесс должен быть выполнен до подписывания зоны. Информация о сети, которая должна быть абсолютно закрытой, не должна публиковаться в DNS совсем.

Выбор значений параметров в SOA RR

Первое действие, которое должен предпринять администратор DNS, – это гарантировать, что значения данных ресурсной записи SOA являются корректными. Значения в данной ресурсной записи определяют взаимодействие между первичным и вторичными серверами в зоне, а именно, с какой периодичностью вторичные серверы должны выполнять зонные пересылки с первичного сервера. Эти данные также содержат минимальное значение TTL, которое говорит клиентским resolver’ам, как долго находятся данные в кэше. Смысл этих полей следующий:

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

Утечка информации и Informational RRTypes

Существует несколько типов ресурсных записей, которые сообщают информацию о сети, хостах или сервисах. К этим ресурсным записям относятся Responsible Person ( RP ) запись, Host Information ( HINFO ) запись, Location ( LOC ) запись и различные Text рекурсивные записи ( TXT ). Хотя данные типы записей предназначены для информирования пользователей, не имеющих плохих намерений, они также позволяют атакующему получить информацию о хостах в локальной сети для того, чтобы попытаться использовать их уязвимости. Например, атакующий может запросить HINFO -записи, просмотреть перечисленные хосты и определить ОС и платформы, которые имеют известные уязвимости. Следовательно, следует быть очень осторожным, включая данные типы записей в зонный файл.

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

Использование периода действительности RRSIG для минимизации последствий компрометации ключа

Самым лучшим способом минимизировать последствия компрометации ключа является ограничение периода действительности RRSIG как в самой зоне, так и в родительской зоне. Это позволяет ограничить время, в течение которого атакующий может использовать скомпрометированный ключ для подделки ответов. Атакующий, который имеет скомпрометированный ключ ZSK, может использовать данный ключ только в течение интервала действительности подписи, созданной ключом KSK. Атакующий, который скомпрометировал ключ KSK, может использовать его только в интервале, указаном в DS -ресурсной записи, которая является точкой делегирования у родителя. Но если определить данный период действительности коротким, то потребуется частое переподписывание в зонном файле родителя.

Для минимизации влияния скомпрометированного ключа ZSK следует установить период действительности подписи RRSIG, охватывающей DS -ресурсные записи, в диапазоне от нескольких дней до одной недели. Данное переподписывание не требует частого обновления родительского ключа ZSK, а плановое обновление ключа ZSK должно выполняться через фиксированные интервалы.

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

Администрирование операций для обеспечения безопасности сервисов DNS

Мы рассмотрели операции развертывания и использования возможностей DNSSEC для защиты транзакций запросов и ответов DNS. Рассмотрим операции администрирования, которые должны выполняться периодически, в поддерживающей DNSSEC зоне.

Плановое обновление ключа (время жизни ключа)

Ключи, используемые для подписывания зоны ( ZSK ), и ключи подписывания ключа ( KSK ) должны периодически меняться, потому что они становятся уязвимыми после определенного периода использования. Компрометация закрытого ключа означает, что любой хост может подделать данные зоны, подписывая ложное множество ресурсных записей закрытым ключом, тем самым полностью аннулируя цели, которые преследовались при подписывании зонного файла. Обновление ключа может быть плановым (плановое обновление) или может иметь место в результате каких-либо чрезвычайных обстоятельств (чрезвычайное обновление). Чрезвычайное обновление происходит по одной из следующих причин:

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

Основываясь на этих факторах, в каждой зоне определяется частота обновления ключей для ZSK и KSK. Напомним, что ключ KSK (KSK-private) используется для подписывания только множества ресурсных записей DNSKEY, в то время как ключ ZSK (ZSK-private) используется для подписывания всего зонного файла. Независимо от объема данных, ключ ZSK используется намного чаще, а именно, в следующих случаях:

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

Ключ KSK должен обновляться менее часто, чем ключ ZSK. Рекомендуемая частота обновления для ключа KSK равна одному году (при использовании RSA/MD5 с длиной ключа 2048 бит), а ключ ZSK должен обновляться каждый месяц (при использовании RSA/MD5 с длиной ключа 1024 бит).

Воздействие обновления ключа на оставшуюся часть DNS зависит от того, является ли безопасная зона локально безопасной или глобально безопасной (как часть цепочки доверия).

Обновление ключа в локально безопасной зоне

Зона, которая является локально безопасной имеет ключ ZSK и, возможно, ключ KSK, который сконфигурирован в resolver’ах клиента как доверенный ключ. Определенные сложности возникают, когда любой из ключей обновляется, хотя наличие ключа KSK для локально подписанной зоны делает обновление ключа ZSK более легким. Когда зона изменяет свой ключ ZSK и имеется ключ KSK, который не изменяется, проблема состоит в том, что следует ввести новый ключ, в то время как старый ключ может находиться в некоторых удаленных resolver’ах или кэшах name-серверов.

Решение состоит в предварительном опубликовании нового открытого ключа перед тем, как выполнить обновление. Администратор DNS должен опубликовать новый ключ как ресурсную запись DNSKEY в зонном файле перед тем, как он будет использоваться для создания подписей. Процесс состоит в следующем:

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

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

При обновлении KSK безопасная зона может не знать, какие resolver’ы хранят открытый ключ в качестве доверенного anchor’а. Если сетевой администратор имеет внешний способ (хотя бы по e-mail) контактирования с администраторами resolver’ов, которые хранят открытые ключи в качестве доверенных anchor’ов, сетевой администратор должен послать соответствующее уведомление и установить безопасные способы распространения нового доверенного anchor’а. Если такого внешнего способа не существует, администратор ничего не сможет сделать, за исключением предварительного опубликования нового ключа KSK, давая администраторам resolver’ов достаточно времени для получения нового ключа KSK.

Обновление ключа в глобально безопасной зоне

Глобально безопасная зона использует два множества ключей: ZSK и KSK.

Обновление ключа ZSK в глобально безопасной зоне

Операции, выполняемые при обновлении ключа ZSK в глобально безопасной зоне не отличаются от тех, которые выполняются при обновлении ключа ZSK в локально безопасной зоне.

Обновление ключа KSK в глобально безопасной зоне

Ключ KSK (KSK-public) является ключом, для которого родитель данной безопасной зоны обеспечивает доверие. Для этого он использует ресурсную запись DS, которая содержит хэш дочернего ключа KSK. Делегирующий родитель подписывает данную ресурсную запись DS своим собственным ключом ZSK для того, чтобы отношения доверия осталось в силе. Для обновления ключа KSK дочерней зоны следует выполнить следующее:

Для того чтобы родитель мог аутентифицировать новый ключ KSK (будем называть его KSK2), основываясь на существующей цепочке доверия, дочерняя зона при выполнении обновления ключа создает DNSKEY -множество ресурсных записей, используя DNSKEY -ресурсные записи существующего ключа вместе с новой DNSKEY -ресурсной записью для KSK2. Затем создаются две подписи (две RRSIG -ресурсные записи) – одна с использованием существующего ключа KSK, другая с использованием нового ключа KSK2. Затем родителю посылается заново созданное DNSKEY множество ресурсных записей вместе с RRSIG -ресурсными записями (во множественном числе, потому что существуют две подписи, соответствующие ключам KSK и KSK2). Множество ресурсных записей, посылаемое родителю, приведено ниже в некотором псевдоформате:

example.ru	DNSKEY	<key-id: 43543>	/* новый KSK*/
example.ru	DNSKEY	<key-id: 78546>	/* существующий KSK*/
example.ru	DNSKEY	<key-id: 98342>	/* ZSK*/
example.ru	RRSIG (DNSKEY)	<signer:example.ru signing-key:78546> 
                                    /* весь DNSKEY RRset подписан существующим KSK */
example.ru	RRSIG (DNSKEY)	<signer:example.ru signing-key:43543> 
                                   /* весь DNSKEY RRset подписан новым KSK */

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

Когда данные задачи выполнены родителем, процесс обновления ключа KSK с точки зрения дочерней зоны полностью выполнен. Родительская зона должна затем обновить свой зонный файл с новой DS -ресурсной записью. Это аналогично обновлению любого другого множества ресурсных записей, которое включает создание, если требуется, любых новых RRSIG. Данное обновление может выполняться автоматически. Это означает, что старая DS -ресурсная запись может быть сброшена и одновременно новая DS -ресурсная запись добавлена. При этом будет выполнено только одно переподписывание в зоне.

Делегированная дочерняя зона должна сохранять истекший ключ KSK в своем множестве ключей до тех пор, пока она не получит подтверждение, что родительская зона выполнила соответствующее обновление DS для гарантии целостности цепочки аутентификации при обновлении ключа KSK. После того как дочерняя зона получает подтверждение, что делегирующий родитель обновил информацию делегирования для дочерней зоны, администратор дочерней зоны должен удалить старый ключ KSK из набора ключей и переподписать с использованием ключа ZSK новый ключ KSK.

Аварийное обновление ключа

Аварийное обновление ключа происходит тогда, когда один или более ключей в зоне ( ZSK или KSK компрометируются или закрытая компонента потеряна и необходимо выполнить переподписывание. Данный тип обновления не является плановым, поэтому велика вероятность разорвать цепочку аутентификации, если администратору зоны необходимо выполнить процесс обновления.

Аварийное обновление ZSK

Администратор DNS может обновить компрометированный ключ ZSK более быстро, чем компрометированный ключ KSK, потому что компрометация влияет только на зону. Возможность более быстрого обновления является другой причиной, по которой администратор зоны выполняет обновление ключа ZSK более часто. Если администратор зоны имеет новую DNSKEY -ресурсную запись, уже опубликованную в зоне в качестве части набора ключей зоны (первые три шага в процессе, который рассматривался ранее), следующий шаг зависит от того, является ли ключ компрометированным.

Если используемый в текущий момент ключ ZSK компрометирован, администратор зоны может немедленно заменить его на новый ключ. Нет необходимости ждать, чтобы истек период TTL, потому что новый ключ уже опубликован к данному моменту. Администратор может просто удалить старые RRSIG из зоны и переподписать новым ключом ZSK раньше, чем предполагалось сделать плановое обновление. Функционирование DNS должно продолжиться нормально после такого переподписывания, без разрыва цепочки аутентификации.

Если новый ключ ZSK (следующий ключ ZSK, который будет использоваться) компрометирован, его следует заменить немедленно в множестве ключей зоны. Такая замена также может выполниться автоматически, потому что новый ключ не использовался для создания каких-либо RRSIG ; должно быть переподписано только множество ключей зоны. Также возможно просто удалить компрометированный ключ и заменить его новым ключом ZSK за одно обновление.

Однако существует опасность, что атакующий использовал скомпрометированный ключ ZSK для подделки ответов, исходящих из зоны. Такая опасность реальна в течение того времени, какое текущий ключ KSK остается активным, в соответствии с периодом обновления ключа KSK. После того как ключ ZSK был компрометирован, администратор зоны должен инициировать обновление ключа KSK как можно скорее.

Аварийное обновление KSK

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

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

Администратор DNS должен иметь способ аварийного контактирования с администратором родительской зоны, чтобы иметь возможность выполнять аварийное обновление ключа KSK.

Переподписывание зоны

Зонный файл переподписывается (т.е. заново создаются RRSIG -ресурсные записи), в следующих ситуациях:

Существуют две стратегии для переподписывания данных зоны.

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