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

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

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

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

1. Администратор DNS не должен включать в зонный файл или во внешний view зоны (если используется split DNS) HINFO, RP, LOC или другие типы ресурсных записей, которые могут разглашать информацию, полезную атакующему.
2. Администратор DNS должен просмотреть все данные, которые содержатся в ресурсной записи TXT, для проверки возможной утечки информации, перед тем как добавлять их в зонный файл.

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

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

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

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

1. Период действительности для RRSIG, охватывающих множество ресурсных записей DNSKEY зоны, должен быть в диапазоне от двух дней до одной недели. Такое значение помогает уменьшить период существования уязвимости, который может возникнуть в результате компрометации ключа.
2. Зона, имеющая делегированную дочернюю зону, должна иметь период действительности от нескольких дней до одной недели для RRSIG, охватывающей DS-ресурсную запись для делегированной дочерней зоны. Такое значение помогает снизить период уязвимости в дочерней зоне, возникший в результате компрометации ее ключа KSK.

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

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

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

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

• закрытый ключ зоны скомпрометирован;
• закрытый ключ зоны потерян, и зона обновлена до истечения периода действительности RRSIG, но нет возможности подписать новые данные зоны.

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

• большой размер зонного файла, большое количество данных, для которых создаются подписи, делает процесс взлома закрытого ключа более легким;
• чем меньше размер закрытого ключа, тем легче его взломать.

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

• добавляется новая ресурсная запись (например, добавлен новый почтовый сервер, и, следовательно, добавлена новая ресурсная запись MX в зонный файл);
• существующие RDATA в ресурсной записи изменяются (например, IP-адрес сервера изменился, и, следовательно, существующая ресурсная запись A должна быть заменена);
• истекает период действительности подписи для ресурсной записи RRSIG.

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

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

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

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

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

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

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

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

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

• безопасная зона, которая предварительно опубликовывает свой открытый ключ, должна сделать так, чтобы по крайней мере один период TTL завершался до времени обновления ключа;
• после удаления старого открытого ключа зона должна создать новую подпись ( RRSIG -ресурсную запись) для оставшихся ключей ( DNSKEY -ресурсные записи) в зонном файле.

При обновлении 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 и добавить его в множество зонных ключей;
• подписать множество ключей зоны новым ключом KSK, а также старым ключом KSK (ключом, который истекает);
• передать новый ключ KSK своему родителю таким способом, при котором родитель мог бы аутентифицировать этот ключ;
• в родительской зоне создать новую DS -ресурсную запись (которая заменит старую DS -ресурсную запись), содержащую хэш нового ключа KSK, затем подписать заново созданную DS -ресурсную запись.

Для того чтобы родитель мог аутентифицировать новый ключ 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 78456 для заново созданного множества ресурсных записей DNSKEY, которое включает новый ключ KSK2. Это выполняется с использованием первой из RRSIG -ресурсных записей заново созданного DNSKEY -множества ресурсных записей, (записи, в которой указан 78456 в качестве ключа подписывания) и своей собственной DS -ресурсной записи;
• проверяет аутентичность ключа KSK2 по открытому ключу KSK2 дочерней зоны. Для этого он проверяет вторую RRSIG -ресурсную запись (запись, в которой указан 43543 в качестве ключа подписывания) из DNSKEY -множества ресурсных записей;
• создает новую DS -ресурсную запись, содержащую хэш нового ключа KSK2;
• создает RRSIG для новой DS -ресурсной записи ключа KSK2.

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

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