Тервер.asmАлгоритмыКомбалгJSMarkupHackWeb

DNSSEC

Содержание:

История

Изначально система доменных имен не имела никаких механизмов для защиты от подмены информации в ответе — и запрос, и ответ передаются чистым текстом. При этом резолвер судил о верности полученной информации только по идентификатору запроса, длина которого всего 2 байта. То есть чтобы отравить кэш нужно было просто перебрать $2^{16}$ значений.

Говорить об этом начали еще в 90-х. При этом принялись неспешно описывать первую редакцию DNSSEC. Она увидела свет в 1997, через два года появилась следующая. В 2005 появилась нынешняя редакция DNSSEC, с которой все и работают. Знаковое событие случилось в 2008 году, когда Дэн Камински показал миру, что отравить кэш можно за 10 секунд. Производители DNS софта ответили тем, что кроме идентификатора запроса стали рандомно выбирать исходящий порт. Попутно началась истерия по поводу внедрения DNSSEC.

Что такое DNSSEC

Domain Name System Security Extensions – набор расширений протокола DNS, позволяющих минимизировать атаки, связанные с подменой DNS-адреса при разрешении доменных имен.

DNSSEC является технологией, разработанной, помимо всего прочего, для защиты от атак с помощью цифрового “подписывания” данных, которое позволяет быть уверенным в их достоверности. Однако для устранения данной уязвимости Интернета необходимо использовать данную технологию на каждом этапе поиска, начиная с корневой зоны и заканчивая последним доменным именем. Подпись корня (использование технологии DNSSEC в корневой зоне) является необходимым действием во всем процессе. Важно отметить, что при этом данные не шифруются. Технология просто позволяет убедиться в достоверности адреса посещаемого сайта.

Как это работает

Принцип работы DNSSEC тот же, что и у цифровой подписи. То есть закрытым ключом подписываем, открытым сверяем.

Особенность состоит в том, что DNSSEC использует два типа ключей:

Сделано это из таких соображений: зона может быть достаточно большой, чтобы удалось подобрать закрытый ключ, поэтому его надо менять почаще, и сделать его можно покороче, чтобы зоны подписывались быстрее; KSK же используется для небольших объемов данных, поэтому его можно и подлиннее сделать и менять пореже. Тем более, что хэш от открытой части KSK требуется отправить в родительскую зону, что хотелось бы делать не слишком часто.

Механизм работы

Допустим, мы хотим узнать адрес test.bar.example.com:

  1. Запрашиваем доменное имя у резолвера

  2. Резолвер выставляет бит DO и запрашивает test.bar.example.com у корневого сервера

  3. Резолвер знает, что корневая доменная зона подписана — у него указан ключ или хэш ключа для неё (trust-anchor), поэтому он запрашивает у корневого сервера DNSKEY записи для корневой зоны и сверяет полученное с имеющимся

  4. Корневой сервер не знает такого доменного имени, он сообщает адреса серверов, ответственных за зону com. резолверу вместе с подписанной DS записью для зоны

  5. Резолвер валидирует DS запись полученным и проверенным ZSK ключом корневой зоны

  6. Теперь резолвер знает, что зона com. подписана, далее он спрашивает у её DNS сервера DNSKEY и валидирует их, после чего спрашивает про bar.example.com.

    Сервер зоны com. сообщает адреса ответственных серверов ns.example.com и ns1.example.com вместе с DS записью

  7. Так резолвер выстроил цепочку доверия до example.com, где он узнает серверы имен зоны bar.example.com и ее DS

  8. Далее, резолвер итеративно узнает адреса DNS серверов, отвечающих за bar.example.com, у которых получает нужную информацию, валидирует её и отдает нам адресную запись, выставив в ответе бит AD.

При невозможности что-то провалидировать резолвер вернет servfail.

Цепочка доверия

DNSSEC привязана к административной иерархии глобальной (общепринятой) системы доменных имён (DNS). То есть, для каждого домена должна быть построена “цепочка доверия”, ведущая от записей данного домена через различные криптографические ключи к корневому домену. Более детальное описание конкретного решения в случае nox.su приведено ниже.

nox.su - домен второго уровня, находится в зоне .su, которая, в свою очередь, принадлежит к корневой зоне.

Пример цепочка доверия_1

  1. Корневой доменной зоне соответствует KSK с id=19036.

    Запись DNSKEY содержит публичную часть данного KSK, которая позволяет проверить подписи, сделанные с его помощью. В нашем случае этим ключом подписаны две записи: публичная часть KSK (на схеме отражено при помощи “возвратной” стрелки) и публичная часть ZSK - ключа, используемого для подписывания всех остальных записей корневой зоны.

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

    В корневой зоне соответствующий ZSK (DNSKEY c id=51201) удостоверяет две DS-записи, относящиеся к ключам из расположенной ниже зоны .su. Это первое звено цепочки доверия в нашей схеме. DS-записи содержат хеши (SHA-1 и SHA-256) публичных частей ключей KSK, используемых в .su (id=1509,id=19071, см. на след. слайде). Таких ключей два, что позволяет проводить ротацию ключей без нарушения работоспособности процедур валидации для данной зоны (один ключ заменяет другой, при этом оба заранее размещены в зоне).

Пример цепочка доверия_2

  1. Зона .su использует собственный ZSK (id=41948), при помощи которого подписана DS-запись, соответствующая KSK зоны nox.su. То есть, использована та же процедура, что и для звена корневая зона - .su. Единственное отличие: указана только одна DS-запись. Это связано с тем, что в nox.su - только один ключ KSK. Таким образом, для того, чтобы изменить этот ключ, потребуется внести в зону .su новую DS-запись.

    Строго говоря, использование только одной DS-записи не является лучшей практикой, однако такое решение вполне допустимо. Например, если потребуется провести плановую ротацию ключей для nox.su, то вторую DS-запись можно разместить заранее. Проблема возникнет только при необходимости внезапной, незамедлительной смены ключа.

Пример цепочка доверия_3

  1. Как нетрудно узнать из DNS, зону nox.su поддерживают минимум два NS-а. В зоне они обзначены так: ns1.8191.ru и ns2.8191.ru. Сейчас, 26.05.13, в DNS имена серверов изменены, но это не важно. Именно эти два сервера и содержат информацию об адресации внутри упомянутой зоны. Техническое решение практически стандартное: Linux + BIND 9.7. (утилиты dnssec-signzone и др.).

    При помощи KSK (id=47341 на схеме) подписаны два ZSK (id=23208, id=17166). ZSK 23208 - удостоверяет остальные записи в зоне (в том числе и сам этот ZSK, что, в общем, избыточно). Второй ZSK не используется, но размещён в зоне для обеспечения возможности быстрой ротации ключей.

Пример DNSSEC

Оказываемые эффекты

  1. Исходящий трафик авторитетного DNS сервера увеличивается примерно в 4 раза
  2. Размер файла зоны после подписи вырастает в 6-7 раз
  3. Увеличение длины ключа приводит к заметному снижению производительности резолвера, на авторитетный сервер влияет в меньшей степени
  4. Наоборот действует увеличение кол-ва итераций при использовании NSEC3
  5. DNSSEC приводит к значительному увеличению DNS ответа и, следовательно, необходимо чтобы все сетевое оборудование корректно работало с DNS пакетами более 512 байт.

Ресурсные записи DNSSEC

DS (Delegation Signer) – для идентификации ключа делегированной зоны. Содержит значение хеш-функции, открытого ключа, который должен находиться в одной из DNSKEY-записей делегируемой зоны. Размещается в делегирующей зоне, при условии наличия NS-записей для зоны делегируемой.

DNSKEY (DNS Key) – для публикации криптографических ключей в зоне. Содержит тип ключа, используемый алгоритм, сам ключ.

RRSIG (Signature RR) – для подписания других ресурсных записей. Содержит значения подписей, сгенерированных для наборов ресурсных записей зоны. Валидность той или иной подписи может быть проверена при помощи ключей, размещённых в соответствующих DNSKEY-записях.

Пример DNSKEY

su	345600	DNSKEY	256	3	7
AwEAAfWZHDRorjygm9vbdoAyMWttyXigyCwif0STSxjeaU
...wKbl1SwI8E06pqyPXiJRapdqNP; key tag = 30062

su	345600	DNSKEY	257	3	7
AwEAAakz9eb33Pqr8hVaCowuxLWNaZlEDKvF6t8nKyN77c
...VVKGOm+NZ5fD/dXi4LQtTXwS1y; key tag = 16101

Тип протокола - всегда 3 для DNSSEC

Код алгоритма - 5, соответствует RSA с использованием SHA1

Интернациональные доменные имена

IDN (Internationalized Domain Names) – доменные имена, которые содержат символы национальных алфавитов.

президент.рф , مصر.

Для поддержки IDN достаточно, чтобы их понимал браузер.

Punycode – стандартизированный метод преобразования последовательностей Unicode-символов в ACE- последовательности (ASCII Compatible Encoding).

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

http://xn--80acd.com – IDN в Punycode-представлении, http://80acd.com – обычное доменное имя.

Примеры Punycode преобразования

Последовательность символов Кодировка
abcdef abcdef
abæcdöef abcdef-qua4k
schön schn-7qa
ยจฆฟคฏข 22cdfh1b8fsa
☺ 74h
правда 80aafi6cg