DNSSEC расширение к DNS для повышения безопасности

Практически 25 лет DNS запросы не считались безопасными, но после внедрения DNSSEC на корневых серверах эта проблема будет решена.

Не секрет, что практически все технологии современного Интернета получили свою жизнь еще в 70-80 годах. В то время разработчиков интересовала сама возможность, и ни кто особо не рассчитывал на том, что сеть станет общедоступной и разрастется до мировых масштабов. А подключаться к Интернет можно будет с любой точки планеты. В итоге практически во всех протоколах не была предусмотрена возможность защиты или повышения безопасности. Результат мы получили в виде спама, атак на ресурсы Сети путем подделки DNS адресов и многих других проблем. Сегодня изменить что-то глобально, не так то и просто, даже не возможно, слишком много сил и средств следует потратить. Поэтому и проблемы пытаются решить при помощи разного рода надстроек над протоколами, расширений использующих в качестве защиты стойкую криптографию. Для SMTP таким “спасительным кругом” является DKIM (DomainKeys Identified Mail,), для DNS — протокол DNSSEC.

Зачем нужен DNSSEC?

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

Признаю, что есть и другие атаки на DNS вроде “man-in-the-middle” и так далее, перечисление их всех, не входит в задачу статьи. Но в итоге все сценарии сводятся к двум возможным последствиям – недоступность сервиса или выдача пользователю ложной информации. Универсального решения против DDOS атаки на любой сервис нет и DNS здесь не является исключением. Защита строится на тех же принципах – повышаем, увеличивает, фильтруем и блокируем. Хотя у DNS есть одно существенное преимущество — иерархическая структура, при которой информация не хранится в одном месте, а на многочисленных серверах и запрашивается по мере необходимости. Обращение к серверам верхнего уровня происходит только при отсутствии информации в текущем DNS сервере. Кэширование DNS данных приводит к уменьшению числа запросов. В итоге чтобы DDOS атака действительно была эффективной, необходимо чтобы она затронула максимальное количество серверов, в том числе 13 корневых, и действовала в течение продолжительного времени. А это далеко не так просто реализовать.
А вот с выдачей неправильных данных уже не все так безмятежно. Все реализации атак основываются на том, что протокол DNS (RFC 1034 и 1035) не предоставляет клиенту никакой возможности проверки подлинности полученной информации. И в итоге клиент вынужден “доверять” любому ответу, полученному от DNS сервера. При DNS запросах обычно используется протокол UDP, что упрощает подделку ответа сервера, так как при этом не устанавливается виртуальный канал. Кроме этого злоумышленнику не нужно атаковать все DNS сервера, достаточно взять на прицел только один. В итоге пользователь набравший адрес требуемого ресурса попадает на подставной сайт, где он может раскрыть свои пароли или другую информацию. Особо нужно отметить, что уязвимым в этом случае является именно протокол, а не программы его реализующие. Поэтому и проблему можно решить, только изменив подход к получению адреса клиентом.

Особенности DNSSEC

Расширение к протоколу DNS — DNSSEC (DNS Security Extensions), разработанное одноименной группой, не может защитить от самой атаки направленной на подмену адреса, но дает возможность обнаружить такую попытку и отклонить неправильные данные, обезопасив тем самым клиента. Самое главное – DNSSEC не является заменой DNS. Задача разработчиков была создать такой протокол, внедрение которого не требовало бы менять существующую систему и обеспечивал совместимость клиентов поддерживающих и не поддерживающих расширение. Поэтому DNSSEC можно разворачивать постепенно, добавляя новые возможности к уже существующей службе DNS.
Работа по улучшению DNS велась давно и первые упоминания о датированы еще январем 1997 года в RFC 2065 (через 10 лет после принятия RFC 1034), в котором были предложены два дополнительных поля DNS Security (DNSSEC, так раньше расшифровывалась аббревиатура). Затем в последующих RFC эта идея развивалась и уточнялась. Эксперименты по развертыванию DNSSEC по RFC 2535, показали, что имеется много нюансов, в основном в процедуре распространения ключевых данных, что в итоге привело к появлению доработок названных — RFC 2535bis или DNSSECbis. На текущий момент актуальными/базовыми являются вышедшие в марте 2005 года:

Эти RFC заменили более ранние, в том числе и RFC 2535, которые считаются уже устаревшими. Сами разработчики называют для технологии DNSSEC переломным 2004 год, когда на новые расширения обратили внимание в группе по IESG (Internet Engineering Steering Group, выработка инженерного регламента Интернета), которая следит за процессом стандартизации в Интернете.
Основная идея DNSSEC проверка подлинности полученных данных при помощи цифровой подписи, для чего задействуется механизм шифрования с открытыми ключами.
Для этого администратор доменной зоны подписывает информацию о соответствии имен и IP-адресов, используя свой закрытый ключ. Клиент (Security-Aware Resolver) вместе с адресом получает подписанную адресную информацию, которую он может проверить, используя открытый ключ администратора. Соответственно, если данные в полученном сообщении не соответствуют подписи, они отбрасываются. Механизм подтверждения применяются только к данным по зоне и при подтверждении отсутствия DNS записей, но не предназначен для защиты таких операций, как перенос зон и динамические обновления.
В механизме с открытыми ключами есть слабое место – необходимо точно знать, что открытый ключ принадлежит именно тому субъекту, который нас интересует, то есть в нашем случае клиент получивший подписанный ответ должен доверять открытому ключу. И только тогда он может быть уверен, что полученная DNS запись принадлежит именно ответственному серверу. В DNSSEC эту проблему решают за счет построения цепочек доверия. При этом случае полностью задействует имеющуюся иерархическую структуру, когда администратор верхнего уровня выступает гарантом, удостоверяющим подпись доменов находящихся уровнем ниже. В результате клиент, получающий адрес, последовательно может проследить цепочку доверия к открытому ключу начиная от самого верхнего сервера root/TLD к серверу отвечающему за конкретную зону. Очевидно, что данный подход требует поддержки DNSSEC в корневых серверах или хотя бы в TLD (top-level domain). Ведь при использовании DNSSEC в root серверах клиенту потребуется знание единственного ключа, для подтверждения любых (в идеале) данных. Иначе потребуется импортировать ключ для каждой зоны или отдельного домена.
В отсутствии поддержки DNSSEC корневой зоны и TLD допускается участие в подтверждении ключа третьих сторон (look-aside). Это может быть необходимо при построении “островка безопасности” (в RFC — Island of Security), то есть автономно работающего DNS сервера поддерживающего DNSSEC и не завязанного на TLD (в котором не реализован DNSSEC) или другие сервера верхнего уровня. Чтобы упростить процедуру было принято решение развернуть отдельную инфраструктуру, обеспечивающую централизованное хранение публичных ключей зон и подтверждать любые зоны не являющиеся дочерними. Такая структура описана в RFC 4431 и 5074 и получила название DLV (DNSSEC Lookaside Validation). В настоящее время централизованная база поддерживается организацией ISC, хотя DLV может быть развернута на любом DNS сервере.
Кстати наличие открытых ключей в DNS записях позволяет использовать их и для других операций – SSH, электронная почта и т.п.
Особо хочу отметить, что DNSSEC не защищает данные, так как в этом нет смысла, они должны быть открыты, а затрудняет их подделку. Также не следует считать эту схему панацеей, ведь всегда есть вероятность того, что злоумышленнику удастся не только подделать адресную информацию, но и подменить подписи, выдав свой ключ за ключ администратора зоны. Хотя в случае DNSSEC подменить адрес на порядок сложнее.
DNSSEC предполагает подписывать не каждую отдельную запись, а все множество ресурсных записей (RRSet). Его внедрение потребовало некоторых изменений в DNS протокол в частности в ресурсные DNS записи:

Детально они рассмотрены в RFC 4034. Так поле DNSKEY содержит кроме самого ключа еще три записи – флаг (16 позиций, установленный в “1” 7ой бит означает, что запись содержит ключ DNS зоны), протокол (только значение 3) и алгоритм. Список поддерживаемых алгоритмов дан в Appendix A.1 RFC 4034 – RSA/MD5, Diffie-Hellman, DSA/SHA-1, Elliptic Curve DSA (ECDSA) и RSA/SHA-1. Два поля помечены как Private и позволяют при необходимости задействовать другие алгоритмы в отдельных решениях.
Кроме этого в настоящее время действителен RFC 5702 в котором добавлены алгоритмы RSA/SHA-256 и RSA/SHA-512. В результате DNSKEY может выглядеть так (цифра “5” на третьей позиции — RSA/SHA-1):

example.com. 7200 IN DNSKEY 256 3 5 (открытый ключ)

Запись RRSIG содержит большее количество полей:

host.example.com. 7200 IN RRSIG A 5 3 7200 20091110090150 (
	20091103182315 13173 example.com.
raR/8vMh37yX…..6LOsE1TqzqPJ  # сигнатура в Base64)

По порядку – владелец, TTL, цифра “5” указывает на алгоритм шифрования. Цифра 3 указывает на метку label (количество ресурсных записей, она используется для уточнения имени владельца). Так root имеет label = 0, домен верхнего уровня – 1 и так далее. Следующее число (7200) описывает Original TTL, который определяет значение время жизни для подписанных ресурсных записей. За ним две даты — Signature Expiration и Signature Inception (время истечения и начала действия ключа то есть период действия ключа 20091110090150, 20091103182315 13173). Далее следует тэг (определяет хэш DNSKEY), FQDN ресурсной записи DNSKEY, которая должна использоваться для проверки подписи и собственно сигнатура в Base64 кодировке.
Имеющиеся утилиты практически полностью автоматизируют создание DNSKEY и RRSIG записей, поэтому проблем здесь ни каких быть не должно.
Протокол DNSSEC потребовал новых полей в заголовке DNS сообщения: Checking Disabled (CD) и Authenticated Data (AD). Кроме этого задействуется механизмы расширений для DNS (EDNS0, RFC 2671), которые позволяют использовать UDP пакеты свыше 512 байт, как это изначально установлено в RFC 1035. Не следует увлекаться с большей длиной ключей. Кроме дополнительной нагрузки на сервер, это может привести к увеличению результирующего UDP пакета. Некоторые сетевые устройства могут не пропускать пакеты с большей длиной, чем 512 байт, учитывая возможные потери фрагментов разработчики не рекомендуют превышать этот “лимит”.
Как видно ключи должны периодически обновляться и зоны переподписываться. Чтобы упростить эти операции, рекомендовано (именно рекомендовано, но не обязательно) использовать два ключа – KSK (Key Signing Key) и ZSK (Zone Signing Key). Ключ KSK используется для подписывания ресурсных записей зоны (DNSKEY), в родительской зоне (запись DS) при аутентифицированном делегировании, открытая часть KSK передается клиенту. Ключ ZSK используется для подписывания всего множества ресурсных записей в зоне и подписывания DS. Такая схема рекомендована с целью ускорения процесса проверки подписей DNS, так как размер ZSK ключей выбирают меньшего размера, чем KSK. При создании KSK следует исходить из требований безопасности, производительность играет меньшую роль, поэтому здесь рекомендована большая длина ключа. Менять KSK следует раз в год, ZSK чаще вплоть то раз в месяц.
Здесь виден еще один минус DNSSEC – периодически ключи меняются, а администраторы подчиненных серверов должны отслеживать их смену, иначе в один прекрасный день DNS сервер не сможет разрешать адреса.

Теги:

Понравилась статья? Оставьте комментарий или подпишитесь на RSS рассылку.

Комментарии

Комментариев пока что нет

Оставить комментарий

(required)

(required)