Мемуары о будущем

Дмитрий Беляев

Что такое DNSSEC?

Опубликовано: 12 июня 2015 года






В настоящее время в сети интернет довольно часто можно встретить аббревиатуру DNSSEC, когда речь идёт об использовании современных технологий обеспечения сетевой безопасности.

DNSSEC (Domain Name System Security Extensions) — это расширение протокола DNS (Domain Name System), обеспечивающее безопасность информации, предоставляемой средствами DNS в IP-сетях (в сети Интернет).

Фактически применение протокола DNSSEC позволяет подписывать адресную информацию цифровой подписью: администратор доменной зоны подписывает записи о соответствии доменных имён и IP-адресов в своей зоне, а потребитель адресной информации получает возможность проверить достоверность подписи.

Использование DNSSEC позволяет избавиться от ключевых уязвимостей в адресной системе DNS и снизить риск так называемых «подмен адреса», от которых могут пострадать пользователи интернета.

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

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

Изначально система Domain Name System (DNS) разрабатывалась не в целях безопасности, а для создания масштабируемых распределённых систем.

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

Таким образом, DNSSEC была разработана для обеспечения безопасности клиентов от фальшивых DNS данных, например, создаваемых DNS cache poisoning. Все ответы от DNSSEC имеют цифровую подпись. При проверке цифровой подписи DNS-клиент проверяет верность и целостность информации.

В то же время DNSSEC не шифрует данные и не изменяет управление ими, являясь совместимой с ранними версиями текущей системы DNS и приложений.

DNSSEC может удостоверить и такую информацию, как криптографические сертификаты общего назначения, хранящиеся в CERT record DNS.

RFC 4398 описывает, как распределить эти сертификаты, в том числе по электронной почте, что позволяет использовать DNSSEC в качестве глобального распределённого хранилища сертификатов ключей подписи.

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

Дополнительные сведения

Изначально система доменных имён не имела механизмов защиты от подмены информации в ответе сервера, так как во времена разработки (в начале 1980-х годов) угрозы безопасности современного Интернета не являлись актуальными.

При этом клиенты судили о верности полученной информации исключительно по двухбайтовому идентификатору запроса. Таким образом, злоумышленнику требовалось перебрать 65536 значений, чтобы «отравить кэш». Это означало, что данные в системе DNS повреждены (преднамеренно или из-за ошибки), а DNS-сервер кэширует их для оптимизации быстродействия (кэш становится «отравленным») и начинает предоставлять эти неаутентичные данные своим клиентам.

Ещё в 1990 году Стив Белловин (англ. Steve Bellovin) выявил серьёзные недостатки в безопасности. Исследования в этой области начались и проводились полным ходом со времён публикации доклада в 1995 году.

Первая редакция DNSSEC RFC 2065 была опубликована IETF в 1997 году. Попытки реализации этой спецификации привели к новой спецификации RFC 2535 в 1999 году. Было запланировано реализовывать DNSSEC, основываясь на IETF RFC 2535.

К сожалению, у спецификации IETF RFC 2535 были серьёзные проблемы с масштабированием на весь интернет. К 2001 году стало ясно, что эта спецификация была непригодна для крупных сетей. При нормальной работе DNS серверы часто десинхронизировались со своими родителями (вышестоящими в иерархии доменами). Обычно это не являлось проблемой, но при включенном DNSSEC десинхронизованные данные могли нести непроизвольный DoS эффект. Защищённый DNS гораздо более ресурсоёмок в вычислительном плане, и с большей, относительно «классической» DNS, лёгкостью может занять все вычислительные ресурсы.

Первая версия DNSSEC требовала коммуникации из шести сообщений и большое количество данных для осуществления изменений наследника (все DNS зоны наследника должны быть полностью переданы родителю, родитель вносит изменения и отправляет их обратно наследнику). Кроме того, изменения в публичном ключе могли иметь катастрофический эффект. Например, если бы зона «.com» изменила свой ключ, то пришлось бы отправить 22 миллиона записей (так как необходимо было обновить все записи во всех наследниках). Таким образом, DNSSEC в виде RFC 2535 не мог быть масштабирован до размера интернета.

Эти сложности, в свою очередь, вызвали появление новых спецификаций (RFC 4033, RFC 4034, RFC 4035) с принципиальными изменениями DNSSEC (DNSSEC-bis), новая версия которого устранила основную проблему предыдущей реализации и, хотя в новой спецификации клиентам и необходимо совершать дополнительные действия для проверки ключей, она оказалась вполне пригодной для практического применения.

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

Изменение DNSSEC, которое называется DNSSEC-bis (название было дано чтобы отличать DNSSEC-bis от первоначального подхода DNSSEC в RFC 2535) использует принцип DS (англ. delegation signer) для обеспечения дополнительного уровня косвенной делегации при передаче зон от родителя к наследнику.

В новом подходе при смене открытого ключа администратору вышестоящего домена отсылается только одно-два сообщения вместо шести: наследник посылает дайджест (fingerprint, хэш) нового открытого ключа родителю. Родитель просто хранит идентификатор открытого ключа для каждого из наследников. Это значит, что родителю будет отправлено совсем небольшое количество данных вместо обмена огромным количеством данных между наследником и родителем.

Подписание и проверка данных DNS создают дополнительные расходы, что отрицательно сказывается на производительности сети и серверов. К примеру, в среднем зона DNSSEC (совокупность доменных имён определённого уровня входящих в конкретный домен) в 7-10 раз превышает по размеру саму систему DNS. Генерация и проверка подписей отнимает значительное время ЦПУ. Подписи и ключи занимают на порядок больше места на диске и в оперативной памяти, чем сами данные.

Принцип работы

Принцип работы DNSSEC основан на использовании цифровых подписей. У администратора имеются записи о соответствии имени домена и IP-адреса. DNSSEC ставит каждой из них в строгое соответствие специальную, строго определённую последовательность символов, которая представляет собой цифровую подпись.

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

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

При наличии секретного ключа вычисление цифровой подписи не представляет сложности. Такова работа асимметричных систем шифрования с открытым ключом, лежащих в основе алгоритмов цифровой подписи.

Проблемы внедрения и недостатки

Внедрение DNSSEC сильно задержалось по таким причинам, как:

  • Разработка обратно совместимого стандарта, который можно масштабировать до размера интернета;
  • Разногласия между ключевыми игроками по поводу того, кто должен владеть доменами верхнего уровня (.com, .net);
  • DNS серверы и клиенты должны поддерживать DNSSEC;
  • Обновленные DNS-резолверы, умеющие работать с DNSSEC, должны использовать TCP;
  • Каждый клиент должен получить хотя бы один доверенный открытый ключ до того момента, как он начнет использовать DNSSEC;
  • Возрастание нагрузки на сеть из-за серьёзно (в 6-7 раз) возросшего трафика от запросов;
  • Возрастание нагрузки на процессор сервера из-за потребности генерации и проверки подписей, так что может потребоваться замена некоторых недостаточно мощных DNS-серверов;
  • Увеличение требований для хранилищ информации об адресации, так как подписанные данные занимают гораздо больше места;
  • Нужно создавать, тестировать и дорабатывать програмное обеспечение как серверной, так и клиентской части, что требует времени и испытаний в масштабах всего интернета;
  • Stub-резолверы не защищены от отравления кеша — валидация происходит на стороне рекурсивного сервера, клиент получает только ответ с выставленным битом AD;
  • Резко возросла опасность атаки DNS Amplification.

В настоящее время большая часть этих проблем решена техническим интернет-сообществом.

Если говорить о российских доменах, то в зонах .RU, .SU и .РФ система DNSSEC была внедрена в 2011-2012 годах, и сейчас активно используется.

Алгоритм работы DNSSEC в зоне .РФ

1. Пользователь вводит в строке браузера адрес подпись.рф. В соответствии с сетевыми настройками компьютер пользователя посылает запрос на разрешение доменного имени на DNS-сервер (обычно это сервер провайдера доступа к Интернет, который является валидирующим резолвером).

2. DNS-сервер провайдера при отсутствии в кэше информации о запрашиваемом домене посылает запрос к корневому DNS-серверу. В запросе дополнительно устанавливается признак того, что резолвер желает получить ответ с использованием DNSSEC (выставленный бит DO).

3. Корневой DNS-сервер отвечает, что за зону РФ. ответственным является DNS-сервер a.dns.ripn.net. Одновременно он возвращает подписанный с помощью закрытого KSK корневой зоны набор открытых ключей подписи корневой зоны (набор ключей состоит из открытого KSK и открытого ZSK) и подписанный с помощью закрытого ZSK корневой зоны хэш открытого KSK для зоны РФ.

4. Резолвер сравнивает полученный от корневого DNS-сервера открытый KSK корневой зоны с содержащимся в своей памяти открытым KSK корневой зоны. Затем резолвер проверяет содержащуюся в RRSIG электронную подпись набора ключей корневой зоны. Если подпись верная, резолвер начинает доверять ZSK корневой зоны и проверяет с его помощью подпись DS-записи для нижестоящей зоны – РФ. (DS-запись представляет собой хэш KSK зоны РФ.).

5. Получив от корневого сервера адрес ответственного за зону РФ. DNS-сервера a.dns.ripn.net, резолвер выполняет к последнему аналогичный запрос – каков IP-адрес сайта подпись.рф – и указывает, что использует DNSSEC.

6. Ответственный за зону РФ. DNS-сервер отвечает, что информация о зоне ПОДПИСЬ.РФ. содержится на DNS-сервере cainet.ru; возвращает подписанный с помощью закрытого KSK зоны РФ. набор открытых ключей подписи зоны РФ. и подписанный с помощью закрытого ZSK зоны РФ. хэш открытого KSK зоны ПОДПИСЬ.РФ.

7. Резолвер сравнивает полученную от корневого DNS-сервера DS-запись (хэш) KSK зоны РФ. с рассчитанным самостоятельно хэшем полученного от a.dns.ripn.net открытого KSK зоны РФ. При совпадении хэшей резолвер начинает доверять открытому KSK зоны РФ. и может проверить подпись ключевого набора зоны РФ., а следовательно – доверять открытому ZSK зоны РФ. из ключевого набора и проверить подпись открытого KSK зоны ПОДПИСЬ.РФ. После всех проверок резолвер имеет DS-запись KSK зоны ПОДПИСЬ.РФ и адрес ответственного за зону ПОДПИСЬ.РФ. DNS-сервера cainet.ru.

8. Резолвер обращается к DNS-серверу cainet.ru с запросом адреса сайта подпись.рф и указывает, что использует DNSSEC.

Сервер cainet.ru знает, что зона ПОДПИСЬ.РФ содержится на нём самом и возвращает резолверу ответ: подписанный с помощью закрытого KSK зоны ПОДПИСЬ.РФ набор открытых ключей подписи зоны ПОДПИСЬ.РФ и подписанный с помощью закрытого ZSK зоны ПОДПИСЬ.РФ адрес сайта подпись.рф.

9. Аналогично пункту 7 резолвер проверяет открытый KSK зоны ПОДПИСЬ.РФ, открытый ZSK зоны ПОДПИСЬ.РФ и адрес сайта подпись.рф.

10 При удачной проверке в пункте 10 резолвер возвращает пользователю ответ, содержащий в себе адрес сайта подпись.рф и подтверждение, что ответ верифицирован (выставленный бит AD).

По материалам cctld.ru, wikipedia.org и других открытых источников

0


1 звезда2 звезды3 звезды4 звезды5 звезд (Еще никто не голосовал)
Loading ... Loading ...
Google Bookmarks Digg Reddit del.icio.us Ma.gnolia Technorati Slashdot Yahoo My Web News2.ru БобрДобр.ru RUmarkz Ваау! Memori.ru rucity.com МоёМесто.ru Mister Wong





Записи с теми же метками:

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

:wink: :-| :-x :twisted: :) 8-O :( :roll: :-P :oops: :-o :mrgreen: :lol: :idea: :-D :evil: :cry: 8) :arrow: :-? :?: :!:

ВНИМАНИЕ! Все комментарии, содержащие явные оскорбления (в адрес автора статьи или собеседника-комментатора), спам и очевидную рекламу сторонних ресурсов, будут удалены. Также не рекомендуется злоупотреблять матом (такие сообщения будут отмодерированы или удалены).


Другие материалы: