Защищенный DNS

Андрей Робачевский

Андрей Робачевский

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

Почти каждое обращение к информационным ресурсам Интернета начинается со взаимодействия с доменной системой имен DNS. Будь то посещение веб-сайта, обмен почтовыми сообщениями или общение в социальной сети, для определения фактического нахождения ресурса, а именно его IP-адреса, необходима DNS. Эта система обеспечивает трансляцию имени ресурса (например, facebook.com) в его IP-адрес (2a03:2880:f129:83:face:b00c::25 de), необходимый для установления связи.
Система DNS является иерархической и распреде­ленной. Каждый из компонентов доменного имени обслуживается независимым оператором, а трансляция имени происходит посредством последовательного обращения к серверам, обслуживающим базы данных этих имен, или «зон», за ответом. Ответом может быть или указание на сервер, обслуживающий следующий компонент имени (т.н. реферрал), или окончательный ответ.

К сожалению, этот процесс уязвим для различного рода атак. Причиной является слабая система защиты данных базового протокола DNS. Это означает, что в процессе передачи данных от сервера к клиенту данные могут быть модифицированы. Также возможно создание ложных DNS-серверов, поставляющих модифицированные данные. Последствия могут быть долгосрочными и значительными, как для отдельной группы пользователей, так и для отдельного сегмента сети Интернет.
Для того чтобы лучше понять важность обеспечения безопасности DNS, рассмотрим, насколько уязвима система в целом. Различные уязвимые места системы показаны на рисунке 1, а методы защиты – на рисунке 2.
Первый вопрос – насколько защищен собственно процесс подготовки данных, редактирования и создания зоны DNS. Ошибочные данные, умышленно или случайно оказавши­еся в зоне, например, неправильные адреса веб-сайта или почтовых серверов, будут переданы пользователю в ответ на его запрос независимо от использования протоколов защиты DNS, таких как DNSSEC. В данном случае значение имеет уровень внутренней безопасности и защищенности процесса.
Данные также могут быть модифицированы при передаче от мастер-сервера ко вторичным DNS-серверам, обслужи­вающим зону. Сегодня для проверки целостности передачи данных используется протокол TSIG (Transaction SIGnature), описанный в стандарте IETF RFC 2845 «Secret Key Transaction Authentication for DNS (TSIG)».
Ответы от DNS-серверов также могут быть модифици­рованы в процессе передачи в Интернете, но, пожалуй, наибольшую опасность представляет попадание непра­вильных данных в кэш итеративных резолверов – так называемое отравление кэша. Дело в том, что продолжи­тельность жизни данных в кэше, определяемая параметром TTL записи ресурса (например, IP-адрес веб-сайта), может быть достаточно значительной. Это означает, что в течение всего этого времени при модификации данных кэша пользователи будут получать подложные ответы. Более того, внедрение подложных данных в кэш резолвера не представляет особого труда, как было продемонстрировано Дэном Камински в 2008 году. С тех пор в программное обеспечение большинства стандартных резолверов были введены изменения, усложняющие проведение атаки, но только DNSSEC является единственным эффективным методом защиты, поскольку позволяет криптографически проверить аутентичность данных перед загрузкой их в кэш.
Еще одной возможностью публикации ложных данных в DNS является создание лжесерверов DNS. Поскольку адресация и доступ к серверам происходит по их IP-адресу, атака на систему маршрутизации, а именно “захват” соответствующего адресного префикса, может привести к перенаправлению части запросов DNS к DNS-серверу злоумышленника. Соответственно, злоумышленник получает возможность публикации ложных данных с далеко идущими последствиями. Данная угроза особенно значительна при масштабном внедрении технологии аникаст, когда несколько серверов, расположенных в различных частях Интернета, используют один и тот же IP-адрес. В этом случае отличить достоверный DNS-сервер от лжесервера становится сложнее.

Наконец, ответы резолвера на запросы клиентов могут быть также модифицированы. DNSSEC здесь не поможет, если пользователь не производит проверку подлинности ответов самостоятельно, а полагается на резолвер. Правда, канал между резолвером и пользователем как правило находится под административным контролем сервис-провайдера или администратора корпоративной сети, и зачастую имеет высокую степень защиты, напри­мер, с помощью VPN.
Эффективным средством противостояния послед­ствиям модификации данных DNS является применение расширений безопасности DNS, разработанных в рамках IETF (Internet Engineering Task Force, www.ietf.org) и получивших название DNSSEC.
Как защитить DNS?
Давайте теперь поговорим более подробно о технологии, позволяющей защитить многие уязвимые места DNS, связанные с целостностью и аутентичностью данных.
В рамках IETF были расширены возможности стандартно­го протокола DNS для решения проблемы аутентичности и целостности данных. Эти расширения получили название DNSSEC. Основная спецификация DNSSEC содержится в стандартах IETF RFC4033, RFC4034, RFC4035 и RFC5155.
С помощью DNSSEC пользователь имеет возможность убедиться, что полученные данные не были модифи­цированы в процессе публикации и передачи. Другими словами, убедиться в том, что данные, содержащиеся в ответе на запрос DNS, в точности соответствуют данным в зоне для запрашиваемого доменного имени.
В рамках стандартного подхода к информационной без­опасности рассматриваются три основных аспекта данных – их конфиденциальность, целостность и доступность. Целью технологии DNSSEC является защита целостности данных, а точнее, обеспечение возможности проверки целостности данных. Конфиденциальность не является требованием в DNS, а доступность обеспечивается путем усиления инфраструктуры – например, использования технологии аникаст. Кстати, при использовании аникаст вопросы аутентичности и целостности данных встают еще острее, увеличивая ценность DNSSEC.
DNSSEC основан на криптографии с использованием открытых ключей. Администратор зоны подписывает все записи зоны своей цифровой подписью. Там же админи­стратор публикует и открытый ключ, соответствующий этой цифровой подписи. Таким образом, путем проверки подлинности цифровой подписи и ее принадлежности администратору зоны пользователь может убедиться в целостности и аутентичности полученных данных.
Подлинность открытого ключа удостоверяет администра­тор родительской зоны путем включения в зону т.н. записи DS, представляющей собой хэш открытого ключа дочерней зоны. Разумеется, эта запись заверена цифровой подписью администратора этой родительской зоны. Его же ключ удостоверяется администратором зоны верхнего уровня – и так далее, пока не будет достигнута так называемая точка доверия (trust anchor) – ключ, которому пользователь абсолютно доверяет. В DNSSEC таким ключом является ключ корневой зоны «.».
Таким образом, для проверки подлинности ответа на запрос DNS пользователю необходимо совершить целую цепочку проверок – от корневого ключа до ключа зоны, содержащей доменное имя. Этот процесс называется построением цепочки доверия. Только при успешном построении цепочки доверия и положительной проверке самой записи ответ может быть положительно удостоверен. Если хотя бы одна из проверок заканчивается неудачей, то и общий результат будет отрицательным.
К счастью, цепочка доверия DNSSEC полностью соответ­ствует структуре делегирования имен, поэтому процесс построения цепочки доверия и разрешения имен происхо­дит одновременно. На рисунке 3 показана цепочка доверия в DNSSEC.

Из рисунка, кстати, видно, что в DNSSEC используются два типа ключей – так называемый ключ KSK (Key Signing Key, ключ подписи ключей) и ключ ZSK (ключ подписи зоны). Первый является ключом долговременного пользования и, соответственно, более сильным в криптографическом плане. Именно хэш ключа KSK «экспортируется» в родительскую зону в виде записи DS, устанавливая тем самым цепочку доверия. Ключ ZSK служит для подписания записей самой зоны. Ключ ZSK удостоверяется администратором домена путем подписи его ключом KSK. Поскольку в изменении ZSK задействован только администратор домена, этот процесс может (и должен) происходить достаточно часто.
Еще одной важной особенностью DNSSEC является то, что он позволяет удостовериться, что запрошенное имя не существует. Другими словами, при запросе разрешения несуществующего имени пользователю будет возвращен криптографически заверенный ответ, указывающий на отсутствие запрашиваемой записи в зоне. Для этого в DNSSEC используются технологии NSEC и NSEC3 (ru.wikipedia.org/wiki/DNSSEC).
В то же время DNSSEC не является панацеей. Даже если полученные адреса серверов являются правильными, обмен данными может быть перехвачен или перена­правлен с использованием уязвимых мест системы маршрутизации. Также DNSSEC не обеспечивает шифрова­ние данных, здесь необходима другая, довольно широко распространенная технология TLS (Transport Layer Security), использующая цифровые сертификаты X.509, на которой базируется протокол HTTPS. Наконец, DNSSEC не спасет от гомографии, когда имя сервера внешне очень похоже на другое имя, но на самом деле использует другие симво­лы, например, «1» и «l».
И все же, использование DNSSEC совместно с другими средствами защиты существенно усиливает их эффек­тивность. Например, в противоположность сертификатам доменных имен, используемых в TLS/HTTPS, цепь дове­рия в DNSSEC следует цепочке делегирования доменов и, таким образом, основана на деловых отношениях, существующих при регистрации доменов.
DANE
Внедрение DNSSEC также открывает новые возмож­ности. Например, решить проблемы, связанные с сертификатами для проверки достоверности веб- или почтовых серверов и обмена информацией с использо­ванием защищенного протокола TLS. Так называемая система Web-PKI.
Дело в том, что выдачей этих X.509-сертификатов занимаются несколько сотен независимых удостоверяю­щих центров (УЦ), которые используют данные третьих сторон (например, данные от компаний-регистраторов) для верификации прав пользования доменным именем. Конкретный список доверенных УЦ определяется производителями веб-браузеров – такими компаниями, как Google, Apple, Mozilla Foundation и т.д. Хотя в выборе УЦ они руководствуются требованиями CA/Browser Forum, а также результатами аудита WebTrust Task Force  и ETSI , в основном этот процесс закрыт и непрозрачен.
В Web-PKI все УЦ, корневые сертификаты которых установлены в браузере пользователя, имеют право выдавать сертификаты для любого доменного имени и при этом имеют одинаковый уровень доверия. Любой из этих корневых сертификатов является так называемой точкой доверия (trust anchor, TA). Это значит, что УЦ с недостаточ­ным качеством проверок прав владения именем является «слабым звеном» всей системы. Злоумышленник может использовать такой УЦ для получения конкурирующего сертификата для уже существующего чужого имени или сертификата для несуществующего имени. Даже флаг­маны индустрии оказываются уязвимы – так, компания Symantec на протяжении нескольких лет генерировала сертификаты для несуществующих имен, с просроченным сроком действия и другими нарушениями требований CA/ Browser Forum.
Дело усугубляется еще и тем, что корневые УЦ часто делегируют полномочия выдачи сертификатов подчинен­ным УЦ. В результате в Интернете существует большое количество доверенных УЦ, качество регистрационных процессов которых проверить практически невозможно.
Исправить ситуацию можно, если владелец доменного имени сможет сам контролировать выдачу сертификатов, а по возможности – и вообще избежать услуг третьих лиц.
Здесь на помощь приходит DNS. Действительно, если владелец имени или зоны контролирует публикацию такой важной информации, как IP-адреса сайтов, почтовых серверов, обслуживающих домен, и т.п., почему бы не создать новую запись, с помощью которой владелец смог бы указать на сертификат, который следует использовать при обращении к сайту, почтовому серверу и т.д.? Разумеет­ся, эта запись должна быть защищена, и DNSSEC выполняет эту функцию.

Разработка и стандартизация соответствующих прото­колов велась в рамках рабочей группы IETF DANE. DANE позволяет владельцу домена указать, какой сертификат TLS/SSL должно использовать приложение или служба для подключения к вашему сайту. Для этого используется запись TLSA, стан­дартизованная в RFC6698 “The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA” и RFC7671 «The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance”.
Основой DANE является новая запись ресурса TLSA. Эта запись с доменным именем хоста и содержит инструкции по использованию TLS/SSL-сертификата при доступе к сервису по указанному порту и протоколу.

Давайте чуть подробнее остановимся на поле «Исполь­зование сертификата». Это поле определяет проверки, которые браузер с поддержкой DANE должен выполнить перед принятием решения об использовании сертификата, полученного от веб-сайта. Эти проверки схематично отображены на рис. 4.
Значение 0 (PKIX-TA) указывает, что путь валидации полу­ченного сертификата, или открытого ключа, в зависимости от значения поля «Селектор», должен проходить через сертификат, указанный в поле «Данные, ассоциированные с сертификатом». Это может быть как корневой, так и под­чиненный сертификат, но в любом случае путь валидации должен заканчиваться точкой доверия, зарегистрированной в пользовательском браузере.
Значение 1 (PKIX-EE) накладывает ограничение на серти­фикат, полученный от веб-сервера. Он (или его открытый ключ) должен соответствовать «данным, ассоциированным с сертификатом». При этом сертификат должен пройти проверку, используя путь валидации к одной из точек доверия браузера.
Значение 2 (DANE-TA) применяется для определения сертификата, который должен использоваться в качестве новой точки доверия при валидации сертификата, полученного от веб-сервера. Этот метод также называют «утверждением точки доверия», поскольку он позволяет владельцу доменного имени указать точку доверия, которая не входит в стандартную коллекцию TA пользова­тельского браузера.
Наконец, значение 3 (DANE-EE) определяет метод, когда сертификат (или его открытый ключ), полученный от сервера, должен совпадать с сертификатом, указанным в записи TLSA. Этот метод позволяет владель­цу доменного имени использовать собственные сертификаты без при­влечения сторонних УЦ. Этот метод отличается от PKIX-EE тем, что не требует дополнительной валидации сертификата через путь доверия.
DANE может использоваться не только при взаимодействии с веб-серверами. Например, защита передачи данных между почтовыми серверами является чрезвычайно важной. При этом часто используется протокол TLS, но аутентичность сертификата сервера представляет еще большую проблему, чем в случае с Web-PKI. DANE и здесь окажет администраторам почтовых серверов неоценимую услугу, делая почтовую систему в целом более защищенной. Более подробно о проблематике защиты передачи почтовых сообщений между транспортными почтовыми агентами (Mail Transport Agent, MTA) и о применении DANE в этом случае для защиты протокола SMTP описано в RFC7672 “SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)”.
Другие протоколы приложений, например, IMAP или XMPP, могут также использовать DANE. Обсуждение использования DANE в этих случаях можно найти в RFC 7673 “Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records”.

Другими словами, DNSSEC+DANE обладают существенным потенциалом обеспечения защищенности коммуникаци­онной инфраструктуры Интернета на уровне приложений. Основной проблемой является внедрение этих технологий. Дело в том, что их полноценное использование зависит от усилий многих сторон, интересы которых не обязательно совпадают. Так, например, даже если владелец доменного имени заинтересован в его защите с помощью DNSSEC и DANE, его успех зависит от многих факторов, находящихся вне его контроля:

• внедрен ли DNSSEC в родительской зоне?
• поддерживает ли регистратор доменов DNSSEC и DANE (включение в зону соответствующих записей, а также записи защищенного делегирования DS в родительской зоне)?
• выполняет ли резолвер пользователя валидацию DNSSEC?
• поддерживает ли пользовательское приложение (веб-браузер, почтовый сервер) протокол DANE?

Отрицательный ответ на хотя бы один из приведенных выше вопросов сведет на нет защиту, предоставляемую этими технологиями. Этим объясняются весьма невысокие цифры внедрения этих технологий: процент внедрения DNSSEC не превышает пары процентов (есть исключения – например, в Германии уровень внедрения достиг 12% (https://eggert.org/meter/dnssec)), а проникновение DANE (записей TLSA) в этих подписанных зонах и того меньше – он составляет всего 1,8%. Использование DNSSEC (валидация ответов) находится на уровне 15%, во многом благодаря широкому использованию открытого резолвера Google (Google Public DNS), который осуществляет валида­цию ответов по умолчанию.
Однако не стоит отчаиваться. Знание этих возможностей – уже шаг в правильном направлении. Пользовательский интерес к защищенному DNS является существенным стимулом для внедрения сервис-провайдером DNSSEC и осуществления валидации запросов. Требования под­держки DNSSEC и DANE владельцев доменных имен будут рано или поздно услышаны регистраторами и операторами доменов.