Безопасность и современные тренды

Павел Храмцов

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

Начало 2019 года ознаменовалось несколькими событиями, которые заставляют задуматься над вопросом: будет ли Интернет прежним, т.е. будет ли это единая открытая среда информационного обмена или мы скатимся к децентрализации по национальным и корпоративным квартирам?

Обзор этих событий хотелось бы начать не с соображений о «суверенном Рунете», а с события сугубо технического. Речь идет о DNS Flag Day [1]

DNS Flag Day – что это было?

Если подходить к вопросу формально, то можно просто ограничиться цитатой с сайта данного мероприятия: «Нынешний DNS излишне медленен и неэффективен из-за попыток поддержки систем DNS, которые не соответствуют стандартам DNS, установленным два десятилетия назад.

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

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

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

Кратко его можно сформулировать следующим образом: корпорации, разработчики софта и технические гуру лучше всех знают, что нужно конечному пользователю и компаниям, которые этого конечного пользователя обслуживают. Поэтому не нужно ни с кем ничего обсуждать, не нужно втягиваться в дебаты по принципу мультистейкхолдеризма, не нужно обеспечивать совместимость по принципу «снизу-вверх», а следует просто всех поставить перед фактом изменений. Достаточно всех уведомить об этом факте за неполный год до наступления часа «ч», по принципу «кто не спрятался, я не виноват!»

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

Теперь разберемся в сути вопроса. Речь идёт о согласованном прекращении поддержки резолверами «обходных механизмов», позволяющих сейчас работать с DNS-серверами, которые не отвечают на запросы с EDNS [2]. Инициаторы акции (провайдеры DNS-резолвинга и разработчики резолверов) договорились отключить поддержку «обходных механизмов».

Любопытно, что организаторы DNS Flag Day на странице акции обращают внимание на то, что «It is important to note that EDNS is still not mandatory. If you decide not to support EDNS it is okay as long as your software replies according to EDNS standard section 7». Это означает, что речь не идет об обязательной поддержке EDNS, а только о корректной работе DNS в соответствии с текущими спецификациями, например, RFC-1035.

Следует также обратить внимание на тот факт, что ряд популярных общеупотребимых механизмов парирования DDoS с использованием DNS, например, атак типа DNS-amplification (дроп пакетов), прямо противоречат выбранному способу проверки готовности DNS к переходу на EDNS. Никто от этих механизмов отказываться не собирается. Отказ привел бы к частичной деградации DNS-сервиса в случае атаки.

Что же такое EDNS? EDNS – набор расширений для оригинального протокола DNS, позволяющий дополнить его рядом полезных функций. Среди ключевых моментов – DNS-cookie. Поддержка EDNS необходима также для работы DNSSEC.

Как изменилось поведение резолверов-участников акции с 1 февраля 2019? Они перестали использовать «костыли» в случае отсутствия каких либо ответов на запросы с EDNS.

Отсутствие ответов возможно в следующих случаях:

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

б) запросы или ответы фильтруются промежуточными узлами. Обычно это разнообразные межсетевые экраны. Фильтроваться могут либо запросы/ответы, превышающие определённую длину (типовые для UDP 512 байтов), либо запросы/ответы, которые содержат дополнительные флаги. Первый вариант, с ограничением по длине, исторический и напрямую к EDNS не относится, но, тем не менее, работе протокола препятствует. Второй вариант непосредственно связан с EDNS, так как работает «по DNS-заголовкам», однако на практике этот вариант встречается редко. Фильтрация DNS-пакетов может использоваться в составе мер противодействия DDoS-атакам. Основная особенность здесь в том, что корректно работающий резолвер и корректно работающий авторитативный сервер всё равно не могут провести обмен данными в рамках протокола, так как им мешает промежуточный фильтр.

Ранее резолверы просто повторяли запросы без EDNS. Теперь резолверы участников акции считают авторитативный сервер, от которого не был получен ответ на запрос с EDNS, нерабочим, соответственно, перестают к нему обращаться. В этом и состоял «переломный момент» DNS Flag Day.

Такое поведение подразумевает, что каждый авторитативный сервер должен быть доступен для корректных DNS-запросов, отправляемых с EDNS, и сервер должен отвечать на такие запросы. Из этого не следует, что сервер должен полностью поддерживать EDNS: если сервер отвечает корректным пакетом с кодом DNS-ошибки («Ошибка формата»), то в этом случае резолвер всё же попробует повторить запрос без EDNS. В частности, такое поведение заявлено для Unbound и BIND.

Нынешний DNS излишне медленен и неэффективен из-за попыток поддержки систем DNS, которые не соответствуют стандартам DNS, установленным два десятилетия назад. Чтобы обеспечить дальнейшую устойчивость системы, пришло время положить конец этой ситуации и исправить несоответствующие системы. Это изменение сделает большинство операций DNS немного более эффективными, а также позволит операторам развертывать новые функции, в том числе новые механизмы защиты от DDoS-атак.

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

Есть, правда, один момент, о котором уже упоминалось, связанный с парированием DDoS. В этом случае применяется RRL (Response Rate Limit). При установленных RRL часть запросов просто не обрабатывается.

Не стоит думать, что с 1 февраля наступил «конец света» в DNS. Нововведение не является критическим в масштабах Интернета. Во-первых, проблемы с потерями и блокированием EDNS довольно редки. Во-вторых, на проблемных направлениях ещё должны обновиться резолверы. Что касается авторитативных серверов, то большинство (по числу зон) уже так или иначе поддерживает работу с EDNS-пакетами, поэтому здесь массовой недоступности узлов для конечных пользователей ожидать не следует. Если где-то и остались несовместимые “самодельные” решения либо старые версии типового ПО, то им следует доработать программный код или обновить пакеты.

Особенность данной ситуации в том, что существенную роль играет сетевой транспорт и его настройка. То есть факторы, которые к DNS относятся косвенно, и исправить их обновлением ПО DNS нельзя. Здесь, в теории, возможна ситуация, когда крупный провайдер доступа обновил резолверы, но не поменял настройки прохождения пакетов, соответственно, его конечные клиенты останутся без службы DNS (ситуация теоретическая, потому что такой провайдер уже должен был бы отмечать дефекты в работе DNS на своих сетях). Поэтому для исключения возможных аварий требуется участие провайдеров доступа, служб NOC, обеспечивающих прохождение пакетов DNS «в обе стороны» – и на стороне клиентов (рекурсивных резолверов), и на стороне автортитативных серверов. Такое участие состоит в проверке правил межсетевых экранов и подобного программно-аппаратного обеспечения: пакеты EDNS, при штатной работе сети, не должны блокироваться (если тотальное блокирование всё же необходимо, то следует отправлять на адрес источника пакета сообщение DNS о неверном запросе).

Таким образом, принудительное внедрение EDNS в том виде, в каком оно было проведено, больше похоже на PR-акцию, чем на полезное во всех смыслах мероприятие.

В общем-то, тот факт, что разработчики лучше всех знают, как осчастливить конечного пользователя, общеизвестен, а DNS Flag Day – это лишнее тому подтверждение.

Зашифруем всё, или DoT & DoH & ESNI

Не EDNS единым живут гуру DNS. Наиболее популярная тема дискуссий этой зимы – внедрение протоколов DNS over TLS и DNS over HTTP(S). Этим вопросам были посвящены целиком секция на ME DNS Forum [3] и половина секции Emerging Identifiers Technology на ICANN64 [4].

Назначение и особенности реализации DoT и DoH прекрасно разобраны в статье Джеффа Хьюстона [5] (на русском ее можно прочитать на сайте «Интернет изнутри»[6]), поэтому здесь мы не будем углубляться в технические детали этих протоколов.

Собственно, обсуждение последствий внедрения DoH и DoT идут не по поводу инструментария реализации, а по поводу последствий таковой.

Основной вопрос дискуссии – приведет ли внедрение DoH и DoT к фрагментации/децентрализации Интернета или эти опасения надуманы? Останется ли мантра ICANN «One World, One Internet, One Namespace» верной?

Основная идея протоколов DoH и DoT заключается в защите от прослушивания DNS-трафика, который ходит между конечным пользователем (точнее, stub resolver-ом конечного пользователя) и кэширующим резолвером.

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

Вся информация о запросах пользователя и ответах на них попадала на резолвер провайдера.

Ситуация меняется, когда в качестве кэширующего резолвера используют публичные резолверы, например, Google (8.8.8.8) или CloudFlare (1.1.1.1). Учитывая топологию размещения сервисов Google – Google Cache, – часто указанные публичные резолверы отвечают быстрее резолверов провайдера. Многие провайдеры включают публичные резолверы в настройки DHCP для своих конечных пользователей, чтобы не заморачиваться с поддержкой своих собственных резолверов.

Согласно статистике лаборатории APNIC⁷ значительная часть DNS-трафика обрабатывается публичными резолверами Google (рис. 1).

6-1024x431 — Рис. 1. Популярность публичного резолвера Google в различных частях света.

В ряде стран, например, в Монголии, доля использования резолвера Google превышает 50%, т.е. информационные предпочтения граждан этой страны – открытая книга для Google.

Здесь следует заметить еще один момент. Достоверность информации в современной системе DNS обеспечивается технологией DNSSEC[8]. Но все проверки кончаются на уровне кэширующего резолвера, т.е. в дискутируемом случае они заканчиваются на уровне публичного кэширующего резолвера Google или CloudFlare.

В этой связи интересны замечания Пола Хофмана, которые он сделал в своем выступлении на секции Emerging Identifiers Technology на ICANN64. Суть этих замечаний сводится к тому, что, во-первых, в рамках построения замкнутых корпоративных систем одно и то же пространство имен можно резолвить в разные пространства адресов и использовать для этого открытую публичную сеть, а во-вторых, DNS-резолвингом можно управлять через JavaScript.

В настоящий момент можно свободно получить корневую зону и в соответствии с RFC-7706 [9] разместить ее на резолвере и включить prefetching [10] (предварительное кэширование соответствий между доменными адресами и IP-адресами) непосредственно на резолвере. Следует также принять во внимание тот факт, что в DNSSEC не подписывается дополнительная секция ответов авторитетных серверов.

Все это позволяет предположить, что при использовании DoH и DoT возможно построение полностью или частично совершенно разных «интернетов» на одном и том же пространстве имен. Все зависит исключительно от позиции провайдера резолвинга и реакции конечных пользователей на факт выявления «аномалий».

А пока высказываются такие опасения, в браузере FireFox уже реализована поддержка DoH [11] – и в качестве сервера умолчания используется сервер CloudFlare [12].

Справедливости ради, следует заметить, что стандартный протокол HTTPS даже версии 1.3 не обеспечивает полной защиты DNS-информации. В рамках обмена между браузером и сервером в незашифрованном виде передается SNI (Server Name Indication).

Однако здесь тоже есть прогресс. В октябре 2018 FireFox стал первым браузером, в котором была реализована поддержка Encrypted SNI [13].

Подведем итог: вследствие последних изысканий в области безопасного DNS мы можем получить в качестве транспорта DNS-запросов протокол HTTP, встроенные в приложения, например, в браузеры, резолверы и «плоскую» систему резолвинга на основе технологических решений «корпораций добра».

CISA предупреждает

В ноябре 2018 года в США было создано Агентство кибербезопасности (CISA – Cybersecurity and Infrastructure Security Agency). В ноябре 2019 оно подготовило первый отчет, который оказался посвящен вопросам безопасности DNS [14].

В связи с этим корпорация ICANN выпустила свой обзор предметной области [15]. На что обратили внимание американские специалисты?

Во-первых, это атаки на систему регистрации доменных имен, а если говорить более конкретно, на информационные системы регистраторов с целью завладеть «паролями и явками» администраторов доменных имен.

Во-вторых, это атака с целью перехвата DNS-трафика и перенаправления его на DNS-серверы атакующего.

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

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

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

На эту брешь в системе регистрации доменов верхнего уровня указывали давно. Подмены адресов случались довольно часто. Но ICANN отреагировала только сейчас, когда появился подробный разбор такого рода атак [16].

По сути, рассматриваются несколько вариантов «редактирования»: замена адресных записей, замена NS-записей, а также возможность подмены легитимных ответов.

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

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

О хорошем

Здесь можно просто процитировать Координационный центр национального домена сети Интернет: «7 апреля 1994 года Российская Федерация получила национальный домен .ru, зарегистрированный международным сетевым центром InterNIC».

Это значит, что 7 апреля 2019 года домену .ru исполнится 25 лет.

Сейчас в «точке ru» зарегистрировано более пяти миллионов доменных имен – это шестое место среди доменов, выделенных странам.

В среднем серверы DNS национального домена в день обслуживают около семи миллиардов запросов. И это количество постоянно увеличивается год от года.

Доменное пространство имен в .ru принято называть Рунетом. С 25-летием, Рунет!

Ссылки

1. https://dnsflagday.net/index-ru.html

2. https://tools.ietf.org/html/rfc6891

3. https://www.mednsf.org/program/

4. https://static.ptbl.co/static/attachments/200822/1552364329.pdf?1552364329

5. http://www.potaroo.net/ispcol/2016-06/dprive.html

6. http://internetinside.ru/privatnost-dns/

7. https://stats.labs.apnic.net/dnssec?s=Uses+Google+Public+DNS&d=Auto&w=30&t=green