Межсетевое экранирование

         

Защищенный подход для DNS Query/Response – DNSSEC


Ликвидация угрозы, связанной с DNS Query/Response (т.е. подделанного ответа), состоит в обеспечении целостности данных DNS, возвращаемых в ответе. Следовательно, целью безопасности является проверка целостности каждого полученного ответа. Составной частью проверки целостности является гарантирование того, что данные получены из нужного источника. Установление доверия к источнику называется аутентификацией источника. Итак, целями безопасности для транзакций DNS Query/Response являются аутентификация источника и проверка целостности данных.

Эти сервисы могут быть предоставлены для установления доверия к источнику с помощью проверки подписи данных, посланных источником. Описание использования механизма цифровой подписи в контексте инфраструктуры DNS называется стандартом DNSSEC. Преследуемые цели, дополнительные ресурсные записи и содержание сообщений DNS специфицированы в RFC 4033, 4034 и 4035. В DNSSEC доверие к открытому ключу источника, который используется для проверки подписи, устанавливается не с помощью третьей стороны или цепочки третьих сторон (как в инфраструктуре открытого ключа PKI), а наличием доверенного name-сервера (такого как root name-сервер) и установлением цепочки доверия вниз к текущему источнику ответа с помощью проверок подписи, созданной в родительском домене для открытого ключа потомка. Открытый ключ доверенных name-серверов называется trust anchor.

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

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

Для защиты от атак некорректного применения правил расширения для wildcard в ресурсных записях механизм DNSSEC предоставляет значения для сравнения действительной ресурсной записи в wildcard с NSEC-ресурсной записью, и тем самым проверяет, что name-сервер корректно применил в созданном ответе правила расширения wildcard.

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

Данные DNS считаются публичными, следовательно, конфиденциальность не является целью безопасности DNSSEC. DNSSEC не разрабатывался непосредственно для защиты от DoS-атак, хотя он делает это косвенно, обеспечивая целостность сообщения и аутентификацию источника.


Содержание раздела