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

Рассмотрим способ, которым DNSSEC обеспечивает защиту транзакций DNS Query / Response с помощью аутентификации источника, проверки целостности данных и аутентифицированного отказа при отсутствии запрошенных данных. Опишем механизмы, используемые DNSSEC операции, с помощью которых эти механизмы реализуются, и способы обеспечения безопасности этих операций. Другими словами, опишем принципы безопасного развертывания DNSSEC.

Для гарантирования end-to-end защиты транзакций запросов и ответов DNS необходимы дополнительные меры защиты (отличные от тех, которые определены в спецификации DNSSEC – такие как обеспечение безопасности коммуникационного пути между локальными поддерживающими DNSSEC кэширующим name-сервером и stub resolver’ами. Эти меры также будут обсуждаться далее.

Механизмы и операции DNSSEC

Механизмы DNSSEC определяют две основных операции: подписывание (и связанные с этим действия) и проверка подписи. Рассмотрим эти операции.

Типы записей, используемых DNSSEC

Первой задачей является создание цифровых подписей для ресурсных записей в зонном файле. DNSSEC предполагает создание подписи для всего RRSet (множества ресурсных записей c одним и тем же именем владельца, классом и типом), а не для каждой ресурсной записи. Цифровая подпись и связанная с ней информация (ID использованного ключа, признаки начала и конца подписываемого блока и т.п.) содержатся в специальной ресурсной записи RRSIG. Строка, содержащая открытый ключ, который используется для проверки подписи (в RRSIG ), содержится в ресурсной записи с типом DNSKEY. Другой тип ресурсной записи, NSEC (Next Secure) используется для перечисления типов ресурсных записей (в каноническом порядке), существующих в данном домене. Подписи (т.е. ресурсные записи RRSIG ) для данного типа ресурсных записей создаются, кроме того, для обеспечения аутентифицированного доказательства невозможности создания ответов на запросы для несуществующего типа ресурсных записей. Дополнительно существует необязательный тип ресурсной записи DS (Delegation Signer) для случая, когда зона хочет разрешать выполнить проверку подлинности открытых ключей своих дочерних зон. Детальный синтаксис каждого из этих дополнительных типов ресурсных записей, введенных спецификацией DNSSEC указан в RFC 4034. Самой важной из них является ресурсная запись RRSIG, потому что именно она содержит строку подписи.

Ресурсная запись RRSIG, подобно другим ресурсным записям, содержит поля имени собственника, TTL, класс, RRType и RDATA. Цифровая подпись и вся связанная с ней информация находится в поле RDATA. Расположение поля RDATA в ресурсной записи RRSIG со всеми подполями показано ниже. Также приведено краткое описание каждого подполя.

Поле Algorithm Code есть целое число, равное коду соответствующего криптографического алгоритма, использованного для создания подписи.

Поля Labels и Original TTL содержат количество ресурсных записей, для которых создана подпись, и значение TTL для множества ресурсных записей, для которых создана данная подпись.

Значения Signature Expiration и Signature Inception являются абсолютными значениями времени, которые определяют период действительности подписи, – период времени, в течение которого данная RRSIG считается действительной для зоны.

Поля Key Tag и Signer’s Name являются хэшем и доменным именем (FQDN) для ресурсной записи DNSKEY, которая будет использоваться клиентом для проверки действительности подписи.

Наконец, последнее поле содержит саму подпись.

Зона, которая содержит эти дополнительные ресурсные записи наряду с обычными ресурсными записями, называется подписанной зоной. Name-сервер, который создает такие подписанные зоны и включает в свой ответ соответствующие подписи (т.е. соответствующие RRSIG ) вместе в запрошенными ресурсными записями, называется поддерживающим DNSSEC name-сервером.

Список операций DNSSEC

Ответ, пришедший из подписанной зоны, называется подписанным ответом. Resolver, который имеет возможность проверять подписи в подписанном ответе, называется поддерживающий DNSSEC validating resolver. Прежде чем resolver сможет проверить подпись, созданную для множества ресурсных записей и полученную им в ответе, используя открытый ключ зоны, посланный в ответе, он должен установить доверие к этому открытому ключу. В DNSSEC данное требование означает, что resolver должен выполнить так называемое построение доверенной цепочки. Для этого resolver рассматривает список известных доверенных ключей (называемых trust anchors ) и создает цепочку открытых ключей, с помощью которой он устанавливает доверие к открытому ключу зоны, полученному им в ответе. Для построения цепочки используется иерархия пространства имен DNS. В идеале trust anchors в resolver’е содержат открытые ключи root’а (если root-сервер поддерживает DNSSEC или открытые ключи зон, расположенных ниже в иерархии. Список trust anchors в resolver’е не строится с помощью транзакций DNS; для этого используется некоторый внешний механизм.

Процессы DNSSEC описанные выше, включают несколько операций name-сервера и несколько операций resolver’а. Операциями name-сервера являются следующие:

• DNSSEC-ОР1: создание пары открытый – закрытый ключ.
• DNSSEC-ОР2: безопасное хранение закрытых ключей.
• DNSSEC-ОР3: распространение открытого ключа.
• DNSSEC-ОР4: подписывание зоны.
• DNSSEC-ОР5: обновление ключа (изменение ключа).
• DNSSEC-ОР6: переподписывание зоны.

Операциями resolver’а являются:

• DNSSEC-ОР7: конфигурирование доверенных anchors.
• DNSSEC-ОР8: создание цепочки доверия и проверка подписи.

Операции name-сервера с DNSSEC-ОР1 по DNSSEC-ОР4 и операции resolver’а DNSSEC-ОР7 и DNSSEC-ОР8 выполняются либо перед развертыванием DNSSEC, либо перед операциями обеспечения безопасности запросов и ответов (таких как обработка подписанных ответов и проверка подписей). Рассмотрим эти операции в первую очередь. Оставшиеся операции name-сервера (обновление ключа и переподписывание зоны – DNSSEC-ОР5 и DNSSEC-ОР6 соответственно) выполняются периодически после полного развертывания DNSSEC и будут приведены в конце лекции.

Создание пары открытый / закрытый ключи (DNSSEC-ОР1)

DNSSEC определяет создание и проверку цифровых подписей с использованием асимметричных ключей. Это требует создания пары открытый / закрытый ключи. Для облегчения операций администрирования, которые должны выполняться периодически, таких как обновление ключа и переподписывание зоны, необходимо иметь два различных типа ключей. Один тип ключа называется Key Signing Key ( KSK Ключ данного типа (а именно, закрытый ключ, называемый KSK-private) будет использоваться только для подписывания ключа, содержащегося в зонном файле в ресурсной записи с типом DNSKEY . Другой тип ключа называется Zone Signing Key ( ZSK ) (соответствующий закрытый ключ называется ZSK-private). Этот ключ используется для подписывания всех множеств ресурсных записей в зоне (включая множество ресурсных записей DNSKEY ). Административное разграничение между KSK- и ZSK-ключами осуществляется с помощью флага Secure Entry Point ( SEP ) в ресурсной записи DNSKEY, который присутствует в открытых ключах, называемых KSK-public и ZSK-public, соответственно.

Причина, лежащая в основе создания двух типов пар ключей, состоит в определении отдельного набора функций для каждого типа ключа для того, чтобы уменьшить сложность задач, связанных с обновлением ключей и переподписыванием зоны. KSK (KSK-private) используется для подписывания множества ключей (т.е. множества ресурсных записей DNSKEY ) и является тем ключом, который передается родительской зоне для использования его при аутентифицированном делегировании. Аутентифицированное делегирование выполняется посредством создания ресурсной записи DS, содержащей хэш дочернего KSK-public ключа, и затем создания соответствующей подписи (ресурсной записи RRSIG ), используя свой собственный ZSK-private. Ключ KSK (KSK-public) также может использоваться в качестве доверенного anchor для установления доверенных цепочек при проверке подписей.

Ключ ZSK (ZSK-private) применяется для подписывания зонного файла (всех множеств ресурсных записей). Открытый ключ (ZSK-public) не посылается родителю, он всегда хранится в зоне.

При создании пар ключей KSK и ZSK необходимо выбрать следующие параметры:

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

Выбор алгоритма цифровой подписи основывается на принятых стандартах. Обычно рассматриваются следующие алгоритмы:

• DSA;
• RSA;
• Elliptic Curve DSA (ECDSA).

Из этих трех алгоритмов наиболее широко распространены RSA и DSA. С точки зрения производительности RSA и DSA имеют сопоставимую скорость создания подписи, но DSA является более медленным при проверке, а RSA — более быстрым. Единственным обязательным для реализации в DNSSEC алгоритмом является RSA с MD5. Считается, что как минимум name-серверы и клиенты должны иметь возможность использовать RSA. Предполагается, что по крайней мере один ZSK для зоны использует алгоритм RSA.

Выбор длины ключа определяется соотношением между риском компрометации ключа и производительностью. Производительность определяется временем создания подписи и временем проверки подписи. Длина пакета DNS-ответа также должна учитываться, потому что ресурсные записи DNSKEY посылаются в дополнительном разделе DNS-ответа. Так как ключ KSK используется только для подписывания множества ключей (множества ресурсных записей DNSKEY ), в этом случае производительность не является решающим фактором. Однако компрометация ключа KSK может иметь большее негативное воздействие, так как этот ключ является фактически мастер-ключом для зоны. Компрометация ключа KSK в зоне, расположенной высоко в DNS-иерархии, может подвергнуть большую часть DNS-поддерева (следовательно, большое число зон) spoofing атакам. Кроме того, обновление ключа KSK в случае компрометации означает изменение доверенных anchor’ов во многих name-серверах и resolver’ах. Тем самым для KSK рекомендуется большая длина ключа: он имеет небольшое воздействие на производительность, но чувствителен к компрометации.

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

Выбор периода использования (периода обновления) определяется риском раскрытия ключа. В случае KSK объем подписываемой информации не очень большой (потому что ключ KSK подписывает только множество ресурсных записей DNSKEY, и частота изменения данного множества ресурсных записей также маленькая). Минимальная вероятность раскрытия ключа (небольшой объем данных, доступный для угадывания KSK-private) в комбинации с большой длиной ключа приводит к тому, что период использования KSK может быть большим (обычно год или два).

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

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

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

С точки зрения количества создаваемых ключей каждого типа ( KSK и ZSK ), хорошей практикой считается создание дополнительного ключа ZSK к тому, который используется в текущий момент. Следовательно, администратор зоны должен использовать программу создания ключа для создания одного KSK и двух ZSKs при начальном развертывании DNSSEC. Один ZSK рассматривается как активный ключ, и его закрытая часть (ZSK-private) используется для создания подписей. Другой ZSK (ZSK-public) помещается в множество ресурсных записей DNSKEY, но соответствующая закрытая часть (ZSK-private) не будет использоваться для подписывания множества ресурсных записей. Данный дополнительный ключ ZSK дает возможность немедленно обновить ZSK в случае аварийных ситуаций, таких как компрометация ключа. Этот подход предоставляет способ предварительного уведомления resolver’ов, которые будут проверять подписи зон, что это тот ключ, который станет новым ключом после истечения периода действительности текущего ключа. Указание периода действительности ключа в множестве ресурсных записей DNSKEY дает возможность resolver’ам кэшировать и устанавливать доверие к новому ключу так, что они могут немедленно после обновления использовать новый ключ для проверки подписи.