DNSSEC

(DNS Security Extensions)

Стоил ли он всех усилий?

Единственный способ заставить людей внедрить что-то недоделанным — сделать это обязательным.

Есть три технологических решения, которые у меня всегда вызывали сомнения и внутреннее несогласие – IPv6, RPKI и DNSSEC…

Сегодня речь пойдёт о последнем из этого списка «навязанных» (по моему мнению) инноваций.

Какой ответ предполагается на вопрос неофита «Зачем мне использовать DNSSEC?» – «Затем, что он защищает вас от подделок ответов DNS, за исключением подделок, осуществляемых регистратором и государством, а также подделок, осуществляемых вашим интернет-провайдером, и подделок, осуществляемых кем-либо между вами и резолвером интернет-провайдера — если только вы не используете свой собственный резолвер». Представьте это на смартфоне.

Больше он не защищает ни от чего…

Является ли DNS/DNSSEC частью инфраструктуры Интернета? Если да – то сразу вспоминаю основополагающие принципы построения сети, изложенные Дэвидом Кларком в статье End-to-end Arguments in System Design:

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

Эффективная безопасность почти всегда находится на уровне приложений.

Цитаты из Дэвида Кларка – это как маленькая книжечка Мао для IETF. Отсюда же – running code and rough consensus. Но ничто так часто не нарушалось, как эти заявленные священными принципы.

(Для ленивых – дальше можно не читать.)

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

Слабости и дыры в DNS были подмечены и признавались автором – Полом Моцкапетрисом – практически изначально и были изложены в статье Стива Беллоуина о возможности использования DNS для взлома систем, которая была опубликована с задержкой в 5 лет в 1995 году. Она вызвала обсуждение на IETF и легла в основу работ по тому, что стало называться DNSSEC. В 1997 году вышел первый RFC. А в 1998 году была сделана первая реализация DNSSEC в версии BIND9, разработанного для ISC компанией Nominum (одно из детищ Пола Викси и Дэвида Конрада, в дальнейшем долгое время под управлением Моцкапетриса). В целом эта разработка была поддержана ведущими корпорациями – IBM, HP/Compaq, Sun, SGI и т.д. – с прямым и опосредованным финансированием МО США.

Во многом первоначальная работа по DNSSEC проводилась не без участия для нас малоизвестной Trusted Information Systems (TIS).

Шумиха, поднятая Дэном Камински на форуме Black Hat вокруг cache poisoning, уже подзабыта, но тогда она была использована для акцентирования внимания на DNSSEC как ответе на все проблемы DNS. Всё, как всегда, сопровождалось устрашением и промыванием мозгов и компанейщиной – но кто сейчас вспомнит о тогдашних Глобальных альянсах?

В появившемся проекте на основе ICANN (формально – по запросу NTIA) получило целью глобальное внедрение DNSSEC c подписанием корня DNS и было форсированно скоординировано через компанию Shinkuro Стива Крокера (экс-глава ICANN) при поддержке DHS (Министерства внутренней безопасности США).

Следы деятельности компании сейчас можно найти только в Веб-архиве.

Среди сотрудников компании-координатора были работавшие с Крокером еще в TIS Олафур Гудмандссон (бывший вице-президент Cloudflare) и Джеймс Галвин (член правления ICANN, член SSAC – Security and Stability Advisory Committee ICANN – с момента образования), а также Эндрю Салливан (теперь тоже уже бывший президент и гендиректор Internet Society).

В TIS работал и Эд Льюис (сейчас ICANN) – и поныне один из лучших экспертов в DNSSEC.

SSAC ICANN изначально был вотчиной Крокера – по сути, личным комитетом, состав которого изначально определялся лично Стивом.

И первые документы SSAC были посвящены обоснованию необходимости внедрения DNSSEC.

Надо отдать должное Стиву Крокеру за его упорство, методичность и усилия по лоббированию внедрения DNSSEC. Но он никогда не признавал рисков теоретического 100% внедрения DNSSEC не только с точки зрения подписания зон, но и контроля доступа на основе проверки подписей. Наличие многих сбоев в доступе к ресурсам по причине ошибок/сбоев в DNSSEC за последние 15 лет показывает уровень таких рисков.

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

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

DNSSEC в том виде, как он сейчас есть, помог ему зацементировать систему DNS под управлением ICANN, что было изначально политическим решением.

На сегодняшний день мы получили подписанную корневую зону и более 90% доменов верхнего уровня – это стало контрактным обязательством для реестров ICANN.

ПО основных резолверов сегодня упростило поддержание подписанных зон, что снизило изначальную сложность и стоимость поддержания систем.

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

DNSSEC также вошло в требования для федеральных потребителей США.

Среди нормативных документов Национального института стандартов и технологий (NIST) есть руководство по развёртыванию безопасной DNS, которое включает разделы по использованию DNS Security Extensions – Secure Domain Name System (DNS) Deployment Guide.

Что интересно – из 20 угроз, определённых данным документом, только одна решается при помощи DNSSEC.

Почему определение содержит слово «расширения/extensions» во множественном числе?

Первоначально расширения безопасности DNS определялись шире:

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

Следующие четыре компонента считались частью DNSSEC в начале нулевых.

1. Концепция защиты цифровой подписи трафика DNS, которая предназначена для защиты передачи данных в масштабе Интернета – современный DNSSEC.

2. Концепция защиты запросов и ответов через менее масштабируемый, но эффективный механизм TSIG, который применим к передачам зон, регистрациям DHCP и другим резолверам для трафика сервера имён.

3. Безопасные динамические обновления в силу использования TSIG также считались частью DNSSEC.

4. Наконец, определение записи ресурса CERT давало DNS возможность стать механизмом распределения данных безопасности.

Эти четыре элемента DNSSEC были сгруппированы вместе в основном не потому, что они взаимосвязаны, но потому, что были разработаны примерно в одно и то же время.

DNSSEC же как таковой начинался с трёх технических целей по защите данных в DNS:

• аутентификации ответов резолверов;
• обеспечения целостности данных;
• аутентификации отрицательных ответов.

DNSSEC предлагает защиту от различных атак DNS, включая следующие:

• подмена DNS и отравление кеша DNS, когда DNS-резолвер возвращает ложную информацию;
• перехват DNS, когда злоумышленник перенаправляет запрос;
• атаки типа «злоумышленник посередине» (иногда называемые атаками типа «человек посередине»), когда злоумышленник перехватывает связь и потенциально изменяет информацию в процессе передачи.

Аутентификация и проверка, предоставляемые расширениями безопасности DNS, добавляют защиту от определённых типов атак, но это не окончательное решение предотвращения кибератак. Например, инфраструктура открытых ключей (PKI) в Интернете, такая как сертификаты SSL/TLS, помогает защищать веб-сайты и повышать доверие пользователей к посещаемому ими ресурсу, поэтому веб-PKI иногда вытесняет воспринимаемую необходимость в DNSSEC. Однако DNSSEC защищает владельца домена от спуфинговой атаки. Сочетание DNSSEC с веб-PKI обеспечивает дополнительную безопасность как для администратора, так и для пользователя.

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

Есть ли сегодня альтернатива применению DNSSEC? – Ответ звучит как мантра: «Нет».

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

Просто надо помнить, что на применении этой технологии безопасность DNS и сервисов с его использованием не заканчивается.

Image for illustration only. Source: NSLookup. License: CC BY 4.0.