Транзакции DNS

Угрозы для транзакций DNS

Угрозы транзакциям DNS зависят от типа транзакции. Запросы и ответы разрешения имен ( DNS Query/Response ) между DNS-клиентами (stub resolver или рекурсивным name-серверы) и DNS-серверами (кэширующий и авторитетный name-сервер) могут проходить через любые узлы в Интернете; следовательно, угроз для этих транзакций намного больше, чем для транзакций зонной пересылки, динамического обновления или DNS NOTIFY. Как правило, хосты, участвующие в транзакциях зонной пересылки, динамических обновлениях и DNS NOTIFY, находятся внутри одного административного домена. Единственным исключением являются первичный или вторичный name-серверы организации, которые часто расположены у Интернет-провайдера или в других организациях. При этом обычно предполагается наличие заранее существующего отношения доверия между первичным и вторичным name-серверами. Тем не менее возможны случаи, когда потребуется установить тот или иной способ взаимной аутентификации при зонных пересылках DNS.

Угрозы DNS-запросам и ответам и способы обеспечения защиты

Обычные запросы и ответы сервиса разрешения имен содержат неподписанные и незашифрованные UDP-пакеты. Возможные угрозы транзакциям DNS Query/Response описаны в RFC 3833 и могут быть классифицированы следующим образом:

• Угроза Т9: поддельный (выдуманный) ответ.
• Угроза Т10: удаление некоторых ресурсных записей из ответа.
• Угроза Т11: некорректные правила расширения, примененные к wildcard в ресурсных записях в зонном файле.

Поддельный или выдуманный ответ

Поддельный или выдуманный ответ – это ответ, который отличается от того, который посылает законный авторитетный name-сервер. Поддельный ответ может быть получен от:

• скомпрометированного авторитетного name-сервера (на запросы, исходящие от рекурсивного name-сервера);
• испорченного кэша кэширующего name-сервера (на запросы, исходящие от stub resolver’а).

Поддельный ответ может быть создан в результате:

• атаки на уровне ОС с использованием уязвимостей на уровне стека протоколов TCP/IP. Скомпрометированный name-сервер, контролируемый противником, посылает ложные ответы на запросы от рекурсивных name-серверов;
• перехвата пакета. В этом случае атакующий подсматривает запрос, создает и посылает ответ, подделываясь под name-сервер, до того, как реальный ответ от законного авторитетного name-сервера достигнет рекурсивного name-сервера.

Последствия для систем, которым требуются сервисы name-сервера, имеющего испорченный кэш или скомпрометированный зонный файл:

• DoS-атака. Если некоторые важные ресурсные записи, такие как А, NS, MX ресурсные записи, подделаны, система, которая запрашивает данную информацию, никогда не сможет установить соединение с требуемым хостом.
• Перенаправление клиента на неверный адрес. Перенаправление клиента на неверный адрес осуществляется с использованием выборочно испорченных ресурсных записей, у которых элемент RDATA содержит некоторое имя. Примерами таких записей являются CNAME, NS и MX. Информация разрешения имени (т.е. IP-адрес) для имен, содержащихся в этих записях, отыскивается в множестве ресурсных записей, называемых glue (склеенные) записями. Обычно запрашивающий эту информацию клиент получает склеенные записи с помощью последовательных запросов (также называемых triggered-запросами ). Ответы на такие запросы также могут быть скомпрометированы атакующим с помощью вставки поддельных записей. Атакующий может ввести имена, выбранные им, в часть RDATA ресурсных записей; затем атакующий может вставить IP-адреса серверов (выбранные атакующим) в соответствующие склеенные записи, которые передаются в качестве ответа на последовательные запросы. Данный тип атаки на два множества соответствующих ответов называется атакой на цепочку имен. Общий эффект от этого состоит в неправильном перенаправлении клиентов, которые используют сервисы данного name-сервера. Результатом будет перенаправление пользователей к узлам атакующего, что может дать возможность атакующему перехватить разного рода чувствительную информацию.

Удаление некоторых ресурсных записей

Кроме вставки поддельных данных в ответ, атакующий может удалить некоторые ресурсные записи из ответа. Результатом будет невозможность выполнить разрешение имени, что приведет в дальнейшем к DoS-атаке.

Защищенный подход для 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-атак, хотя он делает это косвенно, обеспечивая целостность сообщения и аутентификацию источника.