«DNS over HTTPS» оформлен в RFC 8484 — но не все им довольны
В конце октября Инженерный совет интернета (IETF) представил стандарт DNS over HTTPS (DoH) для шифрования DNS-трафика, оформив его в виде RFC 8484. Его одобрили многие крупные компании, но были и те, кто остался недоволен решением IETF. Среди последних был один из создателей системы DNS Пол Викси (Paul Vixie). Сегодня мы расскажем, в чем здесь суть.
Проблема DNS
Протокол DNS не шифрует запросы от пользователя к серверу и ответы на них. Данные транслируются в виде текста. Таким образом, запросы содержат имена хостов, которые посещает пользователь. Отсюда появляется возможность «подслушать» канал связи и перехватить незащищенные персональные данные.
В чем суть DNS over HTTPS
Чтобы исправить ситуацию, был предложен стандарт DNS over HTTPS, или «DNS поверх HTTPS». В IETF начали работать над ним в мае 2017 года. Его авторами выступили инженеры Пол Хоффман (Paul Hoffman) из ICANN — корпорации по управлению доменными именами и IP-адресами — и Патрик Макманус (Patrick McManus) из Mozilla.
Особенность DoH заключается в том, что запросы на определение IP-адреса отправляются не DNS-серверу, а инкапсулируются в трафик HTTPS и передаются HTTP-серверу, на котором специальный резолвер обрабатывает их с помощью API. DNS-трафик маскируется под обычный HTTPS-трафик, а связь клиента и сервера происходит через стандартный для HTTPS порт 443. Содержание запросов и факт использования DoH остаются скрытыми.
В RFC 8484 Инженерный совет приводит примеры DNS-запросов к example.com с DoH. Вот запрос с методом GET:
Аналогичный запрос с использованием POST:
Многие из представителей ИТ-индустрии выступили в поддержку стандарта IETF. Например, ведущий исследователь интернет-регистратора APNIC Джефф Хьюстон (Geoff Houston).
Разработку протокола поддержали крупные интернет-компании. С начала года (когда протокол еще находился на этапе драфта) DoH тестируют Google/Alphabet и Mozilla. Одно из подразделений Alphabet, выпустило приложение Intra для шифрования DNS-трафика пользователей. Браузер Mozilla Firefox поддерживает DNS over HTTPS с июня этого года.
DoH внедрили и DNS-сервисы — Cloudflare и Quad9. В Cloudflare недавно выпустили приложение (об этом была статья на Хабре) для работы с новым протоколом на Android и iOS. Оно выступает в роли VPN к собственному устройству (на адрес 127.0.0.1). DNS-запросы начинают отправляться в Cloudflare с использованием DoH, а трафик идет «обычным» маршрутом.
Список браузеров и клиентов с поддержкой DoH можно найти на GitHub.
Критика стандарта DoH
Не все участники индустрии положительно отозвались о решении IETF. Противники стандарта считают, что DoH — шаг в неправильном направлении и он только снизит уровень безопасности соединения. Наиболее резко о новом протоколе высказался Пол Викси, один из разработчиков системы DNS. У себя в Twitter он назвал DoH «полнейшей чушью с точки зрения информационной безопасности».
По его мнению, новая технология не даст эффективно контролировать работу сетей. Например, системные администраторы не смогут блокировать потенциально вредоносные сайты, а рядовые пользователи будут лишены возможности организации родительского контроля в браузерах.
/ фото TheAndrasBarta PD
Противники DoH предлагают использовать другой подход — протокол DNS over TLS, или DoT. Эта технология принята как стандарт IETF и описана в документах RFC 7858 и RFC 8310. Как и DoH, протокол DoT скрывает содержимое запросов, но отправляет их не по HTTPS, а использует TLS. Для подключения к DNS-серверу при этом используется отдельный порт — 853. Из-за этого отправка DNS-запроса не скрывается, как в случае с DoH.
Технология DoT тоже подвергается критике. В частности, эксперты отмечают: из-за того, что протокол работает с выделенным портом, третья сторона сможет отслеживать использование защищенного канала и при необходимости блокировать его.
Что ждет протоколы дальше
По словам экспертов, пока неясно, какой из способов защиты DNS-запросов станет более распространен.
Сейчас и Cloudflare, и Quad9, и Alphabet поддерживают оба стандарта. Если DoH Alphabet использует в упомянутом выше приложении Intra, то протокол DoT применили для защиты трафика в Android Pie. Также Google включил поддержку DoH и DoT в Google Public DNS — причем внедрение второго стандарта никак не анонсировали.
Издание The Register пишет, что конечный выбор между DoT и DoH будет зависеть от пользователей и провайдеров, и сейчас ни у одного из стандартов нет явного преимущества. В частности, по прогнозам ИТ-специалистов, для широкого распространения протокола DoH на практике потребуется пара десятилетий.
AdGuard DNS: Как работает защита данных через DNS
Команда AdGuard инвестирует много времени и усилий в разработку решений защиты конфиденциальности пользователей, и многие пользователи ценят продукты AdGuard именно по этой причине. Самым большим вызовом для разработчиков AdGuard является не только обеспечение эффективной защиты, но и предоставление ее любому пользователю, независимо от используемого устройства.
Как раз для этого был создан AdGuard DNS – DNS-служба с акцентом на защиту конфиденциальности, которая блокирует трекеры, рекламные блоки где угодно, будь то стационарные компьютеры, мобильные устройства или смарт-ТВ и устройства «Интернета вещей». Официальный запуск AdGuard DNS состоялся в прошлом году, 18 декабря 2018 года, спустя два года после начала разработки службы.
Что такое DNS?
DNS – в образном смысле, это «адресная книга» Интернета. Каждый раз, когда вы открываете веб-сайт, отправляете электронное письмо или высылаете фотографию кота вашему другу, используемое вами приложение или браузер должно сопоставить имя домена (например, yahoo.com, легко запомнить, что не имеет смысла для компьютера) с IP-адресом, который фактически используют компьютеры. Для этого браузер или приложение отправляет специальный DNS-запрос DNS-преобразователю или резольверу. DNS-резольвер выполняет операцию преобразования доменного имени в IP-адрес и отправляет его обратно.
Схематическое изображение работы DNS
На самом деле система DNS является более сложной, но этой информации достаточно, чтобы получить базовое понимание. Обычно ваш интернет-провайдер (или оператор используемой сети) сам решает, какой DNS-преобразователь следует использовать.
Проблема конфиденциальности DNS
Заметили ли вы проблему на схеме выше? Действительно, случайное лицо, которое предоставляет вам доступ в Интернет, знает каждый домен, который вы посетили и когда происходил сеанс посещения. Одно из исследований на практике продемонстрировало, что модель поведения, полученная путем анализа исключительно данных DNS, позволила правильно идентифицировать 86% пользователей.
Это звучит не очень хорошо, особенно если учесть, сколько усилий многие люди прилагают для защиты своей конфиденциальности: использование HTTPS, VPN-сервисов, блокировщиков рекламы и др. Все эти активности можно отследить с помощью DNS с последующей монетизацией Интернет-провайдерами. Думаете, они не будут получать дополнительную прибыль при наличии соответствующей возможности?
DNS-трафик уязвим для злоумышленников
К счастью, существуют эффективное решение данной проблемы. Почти все устройства, которые позволяют вам выходить в Интернет, также дают возможность выбрать собственный преобразователь DNS. Какой выбрать? На рынке доступно много различных вариантов, но не все из них ставят в приоритет конфиденциальность. AdGuard предлагает сервис, который не только сохранит ваши действия в Интернете в тайне, но и предоставит дополнительные возможности защиты от сетевых угроз.
Давайте подробнее рассмотрим AdGuard DNS и выясним, почему это один из самых безопасных для вас вариантов на сегодняшний день.
Тернистая дорога к безопасности
Выбор альтернативного DNS-резольвера является первым шагом для повышения конфиденциальности, но этого может быть недостаточно. Если никто не может иметь доступ к вашему DNS-трафику сейчас, это не значит, что никто не мог ранее. Протокол DNS совсем не новый, и тогда, когда он был разработан, стандарты конфиденциальности практически отсутствовали. В результате сегодня существует высокий риск того, что ваши DNS-запросы могут быть подслушаны или даже изменены злоумышленниками. Чтобы противостоять им, команда AdGuard приняла несколько действенных мер.
DNSCrypt
DNSCrypt стал первой попыткой обезопасить DNS-трафик от злоумышленников. Это специальный протокол, который зашифровывает связь между вашим устройством и DNS-сервером, защищая его от несанкционированного доступа и атак типа «человек посередине» (MITM-атаки). AdGuard DNS уже давно поддерживает эту технологию.
С AdGuard DNS ваш трафик защищен
Проблема DNSCrypt заключается в том, что протокол никогда не становился официальным стандартом и не получал документ RFC (документ с техническими спецификациями) в отличие от его альтернатив: DNS-over-HTTPS и DNS-over-TLS. Ожидается, что со временем DNSCrypt станет менее популярным и не получит особой поддержки на уровне операционной системе. К счастью, существуют и другие современные инструменты, которые не так широко распространены, но обеспечивают гораздо более высокий уровень безопасности и могут стать новыми стандартами конфиденциальности DNS в обозримом будущем.
DNS-over-TLS
DNS-over-TLS или DoT – протокол шифрования DNS-запросов и передачи по TLS-протоколу. DoT более надежен, чем DNSCrypt. Все больше и больше DNS сервисов поддерживают его, и AdGuard с гордостью вступает в их ряды.
Стоит упомянуть, что начиная с Android 9, устройства Android имеют встроенную поддержку DNS-over-TLS. Вы можете настроить свой смартфон или планшет на использование этого протокола в несколько нажатий без необходимости установки какого-либо дополнительного программного обеспечения.
DNS-over-HTTPS
DNS-over-HTTPS или DoH выполняет удаленное преобразование DNS по протоколу HTTPS. Это еще один безопасный способ защитить ваш трафик DNS от перехвата и подмены. Есть ли разница между DoT и DoH? Для обычного пользователя – практически никакой.
AdGuard DNS недавно получил поддержку DoH, которая выводит сервис на передний план защиты конфиденциальности. К сожалению, этот протокол все еще относительно новый, и способов применения его на вашем устройстве немного. Тем не менее, новая версия AdGuard для Android уже поддерживает эту опцию.
Другие меры защиты
Когда решена проблема с конфиденциальностью DNS, самое время подумать о других потенциальных угрозах. Ни для кого не секрет, что Интернет буквально кишит тысячами трекеров, которые следят за каждым вашим кликом, а затем используют эту информацию, чтобы нацелить вас на рекламу и создать цифровой отпечаток. Как с этим бороться? AdGuard DNS — это не только DNS-преобразователь, но и фильтр трафика. Всякий раз, когда ваше устройство отправляет «плохой» запрос для нужд рекламных блоков и трекеров, то вместо правильного IP-адреса DNS-сервер AdGuard ничего не вернет. Просто, но эффективно.
AdGuard DNS блокирует запросы к рекламным и отслеживающим доменам
Наконец, AdGuard фактически предоставляет два варианта службы DNS – «По умолчанию» и «Семейный». Единственная разница между ними заключается в том, что в режиме «Семейный» дополнительно блокируется доступ к любому контенту, не предназначенному для детей, и принудительно используется параметр Safe Search в браузерах, которые поддерживают данную функцию.
Подводим итоги
Как же настроить AdGuard DNS? Укажите DNS-сервера для вашего подключения или прямо на маршрутизаторе, используя нашу инструкцию.
DNS сервера
94.140.14.14 и 94.140.15.15 для серверов «По умолчанию»
94.140.14.140 и 94.140.14.141 для серверов «Нефильтрующие»
94.140.14.15 и 94.140.15.16 для серверов «Семейный»
DNS-over-TLS
Используйте dns.adguard.com для серверов «По умолчанию» или dns-family.adguard.com для серверов «Семейный»
DNS-over-HTTPS
Используйте https://dns.adguard.com/dns-query для серверов «По умолчанию» или https://dns-family.adguard.com/dns-query для серверов «Семейный»
Помните, что AdGuard DNS – проект с открытым исходным кодом, как и все бесплатные продукты AdGuard. Компания считает чрезвычайно важным, чтобы услуги и продукты, которым вы доверяете защиту конфиденциальности данных, были максимально прозрачными и заслуживающими доверия. Чтобы просмотреть исходный код, узнать все о AdGuard DNS или даже оставить предложение, посетите репозиторий в GitHub.
Команда разработчиков надеется, что пользователям понравится AdGuard DNS. Они убеждены, что проект будет только расти. В будущем будет добавлено больше расположений серверов и новые дополнительные функции.
DNS по HTTPS – половинчатое и неверное решение
Всё время существования интернета открытость была одной из его определяющих характеристик, и большая часть сегодняшнего трафика всё ещё передаётся без какого бы то ни было шифрования. Большая часть запросов HTML-страниц и связанного с этим контента делается в простом текстовом виде [plain text], и ответы возвращаются тем же способом, несмотря на то, что протокол HTTPS существует с 1994 года.
Однако иногда возникает необходимость в безопасности и/или конфиденциальности. Хотя шифрование интернет-трафика получило широкое распространение в таких областях, как онлайн-банки и покупки, вопрос сохранения конфиденциальности во многих интернет-протоколах решался не так быстро. В частности, при запросе IP-адреса сайта по хосту DNS-запрос почти всегда передаётся открытым текстом, что позволяет всем компьютерам и провайдерам по пути запроса определить, на какой сайт вы заходите, даже если вы используете HTTPS после установления связи.
Идея о необходимости шифрования также и DNS-запросов не нова, и первые попытки этого делались ещё в 2000-х — DNSCrypt, DNS over TLS (DoT), и т.п. Mozilla, Google и другие крупные интернет-компании продвигают новый метод шифрования DNS-запросов: DNS over HTTPS (DoH).
DoH не только шифрует DNS-запрос, но и передаёт его «обычному» веб-серверу, а не DNS-серверу, благодаря чему DNS-трафик невозможно отличить от обычного HTTPS. У этой монеты есть две стороны. Эта процедура защищает сам DNS-запрос, как DNSCrypt или DoT, а также делает невозможным ребятам из служб безопасности крупных фирм отслеживать DNS-спуфинг, и переносит ответственность за критически важные функции сети с ОС в приложение. И также это никак не помогает скрыть IP-адрес веб-сайта, который вы только что запросили – ведь вы всё равно на него переходите.
По сравнению с DoT, DoH централизует информацию о посещённых вами сайтах в нескольких компаниях: на сегодня это Cloudflare, обещающая избавляться от ваших данных через 24 часа, и Google, которая намерена сохранить и монетизировать все подробности всего, что вы когда-либо планировали сделать.
DNS и конфиденциальность – важные темы, поэтому давайте углубимся в детали.
DNS-сервера и доверие
Концепция системы доменных имён восходит ещё к ARPANET, когда в единственном текстовом файле на каждом узле ARPANET – под названием HOSTS.TXT – содержалось всё соответствие названий систем, подключённых к ARPANET и их цифровых адресов. Когда вы самостоятельно пополняли этот файл, легко было убедиться в его правильности. С ростом сети стало нереально поддерживать центральную и локальные копии этих файлов. К началу 1980-х уже начались попытки создания системы автоматизации этого процесса.
Первый сервер имён (Berkeley Internet Name Domain Server или BIND) был написан в 1984 году группой студентов Калифорнийского университета в Беркли на основе RFC 882 и RFC 883. К 1987 году стандарт DNS был несколько раз пересмотрен, что привело к появлению RFC 1034 и RFC 1035, которые с тех пор по большому счёту не менялись.
Основа структуры DNS состоит в её древовидной схеме, где узлы и листья делятся на зоны. Корневая зона DNS – это верхний уровень, состоящий из тринадцати кластеров корневых серверов, формирующих официальные корневые DNS-сервера. Любой новый DNS-сервер (поднятый провайдером или компанией) получает DNS-записи по меньшей мере от одного из этих главных серверов.
DNSSEC: добавляем доверие в систему DNS
Перед тем, как перейти к шифровке DNS-запросов, нужно убедиться, что мы можем доверять DNS-серверу. Эта необходимость стала очевидной в 1990-х, и привела к появлению первых рабочих расширений стандарта безопасности DNS (DNSSEC), RFC 2353 и пересмотренного RFC 4033 (DNSSEC-bis).
Карта интернета 2006 года
DNSSEC работает, подписывая записи запросов DNS публичным ключом. Подлинность DNS-записи можно подтвердить публичными ключами корневой зоны DNS, являющейся доверенным третьим лицом в этом сценарии. Владельцы доменов генерируют свои ключи, подписываемые операторами зоны и добавляемые в DNS.
Хотя DNSSEC позволяют быть относительно уверенным в том, что ответы от DNS-сервера настоящие, этот протокол нужно включить в ОС. К сожалению, мало какие ОС реализуют сервис DNS, способный на нечто большее, чем просто «знать о наличии DNSSEC» – то есть, они на самом деле не подтверждают ответы DNS. А значит, сегодня нельзя быть уверенным в том, что получаемые вами ответы от DNS настоящие.
Проблема с DoH
Представим, что вы используете DNSSEC. Вы готовы зашифровать сообщения, чтобы добавить вашей передаче данных конфиденциальности. Причин для того, чтобы сохранить DNS-запросы в секрете от любопытных глаз, может быть много. Среди самых невинных — обход фильтров корпорации и провайдеров, запрет отслеживания интернет-привычек, и прочее. Среди более серьёзных — попытки избежать преследования со стороны правительства за выражение политических взглядов в интернете. Естественно, что шифрование DNS-запросов не даёт людям подсматривать эти запросы, однако в результате игнорируются более крупные проблемы с безопасностью DNS, и, естественно, всех остальных протоколов связи.
Основными конкурентами здесь являются DoT с использованием TLS и DoH с использованием HTTPS. Самая очевидная разница между ними – это порт: DoT работает на выделенном порту TCP 853, а DoH смешивается с другим HTTPS-трафиком на порту 443. Это даёт спорное преимущество неотличимости DNS-запросов от остального трафика, что лишает возможности операторам сети (частным и корпоративным) обезопасить собственную сеть, как в прошлом году заявил в своём твиттере один из архитекторов DNS Пол Викси.
Второе из главных отличий состоит в том, что если DoT просто отправляет DNS-запросы по TLS, то DoH по сути представляет собой DNS-over-HTTP-over-TLS, требует своего Media Type application/dns-message, и значительно всё усложняет. Смешение DoH с существующими протоколами приводит к тому, что каждый DNS-запрос и ответ проходят через стек HTTPS. Это кошмар для встроенных приложений, а также несовместимо практически со всеми существующими типами оборудования.
У DoT есть ещё одно преимущество – этот протокол уже реализован, и гораздо дольше, чем существует DoH, используется такими компаниями, как Cloudflare, Google, а также местными интернет-провайдерами; такое стандартное серверное ПО, как BIND, использует DoT прямо «из коробки». На ОС Android Pie (9-я версия) DNS через TLS будет использоваться по умолчанию, если выбранный сервер DNS поддерживает DoT.
Зачем переключаться на DoH, если DoT уже раскручивается? Если такие нестандартные приложения, как Firefox, будут обходить системную DNS на базе DoT, и использовать собственную систему получения доменных имён через DoH, то с точки зрения безопасности эта ситуация станет весьма сложной. Передача DNS на откуп отдельным приложениям, происходящая сейчас, кажется шагом назад. Известно ли вам, какой метод DNS использует каждое из приложений? Узнаете ли вы о том, что оно смешивает этот процесс с TCP-трафиком на 443-м порту?
Шифрование не препятствует слежке
За DNS over HTTPS ратуют две крупные компании, Cloudflare и Mozilla, причём последняя даже выпустила миленький комикс, где пытается объяснить схему DoH. Неудивительно, что они совершенно не упоминают DNSSEC (несмотря на то, что её называют «критически важной» в RFC 8484), и вместо этого предлагают нечто под названием Trusted Recursive Resolver (TRR), что, по сути, представляет собой совет «использовать доверенный DNS-сервер», под которым Mozilla подразумевает Cloudflare.
Кроме DoH, они упоминают стандарт QNAME minimization (RFC 7816), который должен уменьшить количество некритичной информации, отправляемой DNS-сервером. При этом этот стандарт никак не зависит от DoH и будет работать без всякого шифрования DNS. Как в случае с DNSSEC, безопасность и конфиденциальность улучшаются через эволюцию стандарта DNS.
Самое же интересное содержится в разделе «Чего не исправляет TRR + DoH»? Как уже говорили многие эксперты, шифрование DNS не препятствует отслеживанию. Любой последующий запрос к IP-адресу, который был получен ужасно секретным способом, всё равно будет ясно виден. Все всё равно будут знать, что вы зашли на Facebook.com, или на сайт для диссидентов. Никакое шифрование DNS или интернет-трафика не скроет информацию, жизненно необходимую для работы такой сети, как интернет.
Станет ли будущий интернет единой точкой отказа?
Mozilla предлагает справляться с проблемой отслеживания IP просто заявляя, что это не проблема благодаря использованию Облака. Чем больше веб-сайтов и сетей распространения контента (CDN) навесят на небольшое количество сервисов (Cloudflare, Azure, AWS, и т.п.), тем меньше будет значить этот единственный IP-адрес – нужно будет просто верить в то, что выбранный вами облачный сервис не будет воровать ваши данные и не упадёт на сутки.
В этом году 24 июня было массивное падение сервисов, когда ошибка в настройках, сделанная провайдером Verizon, привела к тому, что Cloudflare, Amazon, Linode и многие другие большую часть дня были недоступны. 2 июля этого года примерно на полчаса упал Cloudflare, а вместе с ним и многие веб-сайты, полагающиеся на его услуги.
По совпадению, облачный сервис Office365 от Microsoft тоже лежал в тот день несколько часов, из-за чего многие пользователи не смогли воспользоваться его услугами. В выходные перед днём труда [национальный праздник в США, отмечаемый в первый понедельник сентября / прим. перев.] отключение напряжения в дата-центре AWS US-East-1 привело к тому, что терабайт хранившихся там данных клиентов накрылся медным тазом. Очевидно, в идее о благе централизации интернета есть ещё какие-то недостатки.
Старые песни по-новому
Потрясающе, что во всей этой дискуссии по поводу конфиденциальности и отслеживания нет никаких упоминаний виртуальных частных сетей (VPN). Они решают проблемы с шифрованием данных и DNS-запросами, с сокрытием IP-адреса и прочим, просто перемещая точку, в которой ваш ПК или другое выходящее в интернет устройство соединяется с интернетом. Диссиденты внутри авторитарных режимов десятилетиями использовали VPN для обхода интернет-цензуры; VPN, включая такие его специальные виды, как Tor, являются критически важным элементом свободы в интернете.
Как работает Tor
Если вы доверяете большой коммерческой компании вроде Cloudflare в такой схеме, как DoH, то найти доверенного VPN-провайдера, не хранящего и не продающего ваши данные, будет легко. А в браузере Opera вообще есть бесплатная встроенная поддержка proxy, предлагающая множество преимуществ VPN.
В итоге можно сказать, что DoH подтверждает свой акроним, плохо делая то, что уже хорошо удаётся DoT [«Doh!» – восклицание, указывающее на глупость совершённого действия, особенно собственного / прим. перев.]. Нужно больше концентрироваться на повсеместном внедрении DNSSEC, совместно с DoT и минимизацией QNAME. А если вас заботит реальная конфиденциальность, то вам нужно обратиться к VPN.
Минимизация рисков использования DNS-over-TLS (DoT) и DNS-over-HTTPS (DoH)
Защита от DoH и DoT
Контролируете ли вы свой DNS трафик? Организации вкладывают много времени, денег и усилий в обеспечение безопасности своих сетей. Однако, одной из областей, которой часто не уделяется должного внимания, является DNS.
Хорошим обзором рисков, которые приносит DNS является презентация Verisign на конференции Infosecurity.
31% обследованных классов программ-вымогателей использовали DNS для обмена ключами. Выводы исследования
31% обследованных классов программ-вымогателей использовали DNS для обмена ключами.
Проблема серьезная. По данным исследовательской лаборатории Palo Alto Networks Unit 42, примерно 85% вредоносных программ используют DNS для установления канала управления и контроля, позволяя злоумышленникам легко внедрять вредоносные программы в вашу сеть, а также похищать данные. С момента своего создания трафик DNS в основном был незашифрованным и его легко можно было анализировать защитными механизмами NGFW.
Появились новые протоколы для DNS, направленные на повышение конфиденциальности DNS соединений. Они активно поддерживаются ведущими поставщиками браузеров и другими поставщиками программного обеспечения. Скоро в корпоративных сетях начнется рост зашифрованного DNS-трафика. Зашифрованный трафик DNS, который не анализируется средствами должным образом и разрешен, представляет угрозу безопасности для компании. Например, такой угрозой являются криптолокеры, которые используют DNS для обмена ключами шифрования. Атакующие сейчас требуют выкуп в несколько миллионов долларов за восстановление доступа к вашим данным. В компании Garmin, например, заплатили 10 миллионов долларов.
При правильной настройке NGFW могут запрещать или защищать использование DNS-over-TLS (DoT) и могут использоваться для запрета использования DNS-over-HTTPS (DoH), что позволяет анализировать весь трафик DNS в вашей сети.
Что такое зашифрованный DNS?
Система доменных имен (DNS) преобразует удобочитаемые человеку доменные имена (например, адрес www.paloaltonetworks.com ) в IP-адреса (например, в 34.107.151.202). Когда пользователь вводит доменное имя в веб-браузере, браузер отправляет DNS-запрос на DNS-сервер, запрашивая IP-адрес, связанный с этим доменным именем. В ответ DNS-сервер возвращает IP-адрес, который будет использовать этот браузер.
Запросы и ответы DNS пересылаются по сети в виде обычного текста в незашифрованном виде, что делает его уязвимым для шпионажа или изменения ответа и перенаправления браузера на вредоносные сервера. Шифрование DNS затрудняет отслеживание DNS-запросов или их изменение во время передачи. Шифрование DNS запросов и ответов защищает вас от атаки Man-in-the-Middle, выполняя при этом те же функции, что и традиционный протокол DNS (система доменных имен) с открытым текстом.
За последние несколько лет были внедрены два протокола шифрования DNS:
Эти протоколы имеют одну общую черту: намеренно прячут DNS-запросы от любого перехвата. и от безопасников организации в том числе. Протоколы в основном используют протокол TLS (Transport Layer Security) для установления зашифрованного соединения между клиентом, выполняющим запросы, и сервером, разрешающим запросы DNS, через порт, который обычно не используется для трафика DNS.
Конфиденциальность запросов DNS является большим плюсом этих протоколов. Однако, они создают проблемы безопасникам, которые должны следить за сетевым трафиком и обнаруживать и блокировать вредоносные соединения. Поскольку протоколы различаются по своей реализации, методы анализа будут отличаться у DoH и DoT.
DNS over HTTPS (DoH)
DoH использует хорошо известный порт 443 для HTTPS, для которого в RFC специально указано, что задача состоит в том, чтобы «смешать трафик DoH с другим трафиком HTTPS в одном и том же соединении», «затруднить анализ трафика DNS» и, таким образом, обойти меры корпоративного контроля ( RFC 8484 DoH, раздел 8.1 ). Протокол DoH использует шифрование TLS и синтаксис запросов, предоставляемый общими стандартами HTTPS и HTTP/2, добавляя запросы и ответы DNS поверх стандартных запросов HTTP.
Риски, связанные с DoH
Если вы не можете отличить обычный HTTPS-трафик от запросов DoH, то приложения внутри вашей организации могут (и будут) обходить локальные настройки DNS, перенаправляя запросы на сторонние сервера отвечающие на запросы DoH, что обходит любой мониторинг, то есть уничтожает возможность контроля за DNS трафиком. В идеале вы должны контролировать DoH используя функции расшифрования HTTPS.
Обеспечение видимости и контроля трафика DoH
В качестве наилучшего решения для контроля DoH мы рекомендуем настроить в NGFW расшифровку трафика HTTPS и блокировку трафика DoH (название приложения: dns-over-https).
Во-первых, убедитесь, что NGFW настроен для расшифровки HTTPS, согласно руководству по лучшим методам расшифровки.
Во-вторых, создайте правило для трафика приложения «dns-over-https», как показано ниже:
Правило Palo Alto Networks NGFW для блокировки DNS-over-HTTPS
В качестве промежуточной альтернативы (если ваша организация не полностью реализовала расшифрование HTTPS) NGFW можно настроить для применения действия «запретить» к идентификатору приложения «dns-over-https», но эффект будет ограничен блокировкой определенных хорошо известных серверов DoH по их доменному имени, так как без расшифрования HTTPS трафик DoH не может быть полностью проверен (см. Applipedia от Palo Alto Networks и выполните поиск по фразе «dns-over-https»).
DNS over TLS (DoT)
Протокол DoT использует протокол TLS для обеспечения шифрования, инкапсулирующего стандартные запросы протокола DNS, с трафиком, использующим хорошо известный порт 853 ( RFC 7858, раздел 6 ). Протокол DoT был разработан, чтобы упростить организациям блокировать трафик по порту, либо соглашаться на его использование, но включить расшифровку на этом порту.
Риски, связанные с DoT
Обеспечение видимости и контроля трафика DoT
В качестве наилучшей методики контроля за DoT мы рекомендуем любое из вышеперечисленного, исходя из требований вашей организации:
Настройте NGFW для расшифрования всего трафика для порта назначения 853. Благодаря расшифрованию трафика, DoT будет отображаться как приложение DNS, к которому вы можете применить любое действие, например, включить подписку Palo Alto Networks DNS Security для контроля DGA доменов или уже имеющийся DNS Sinkholing и anti-spyware.
В качестве альтернативы можно полностью заблокировать движком App-ID трафик ‘dns-over-tls’ через порт 853. Обычно он заблокирован по умолчанию, никаких действий не требуется (если вы специально не разрешили приложение ‘dns-over-tls’ или трафик через порт 853).
