Защита от DoH и DoT
Контролируете ли вы свой DNS трафик? Организации вкладывают много времени, денег и усилий в обеспечение безопасности своих сетей. Однако, одной из областей, которой часто не уделяется должного внимания, является DNS.
Хорошим обзором рисков, которые приносит DNS является презентация Verisign на конференции Infosecurity.
Выводы исследования
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
Система доменных имен (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-over-HTTPS (DoH)
DNS-over-TLS (DoT)
Эти протоколы имеют одну общую черту: намеренно прячут 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.
И Google, и Mozilla реализовали возможности DoH в последней версии своих браузеров, и обе компании работают над использованием DoH по умолчанию для всех запросов DNS. Microsoft также разрабатывает планы по интеграции DoH в свои операционные системы. Минусом является то, что не только уважаемые компании-разработчики программного обеспечения, но и злоумышленники начали использовать DoH как средство обхода традиционных мер корпоративного межсетевого экрана. ( Например, просмотрите следующие статьи: PsiXBot теперь использует Google DoH , PsiXBot продолжает развиваться с обновленной инфраструктурой DNS и анализ бэкдора Godlua .) В любом случае, как хороший, так и вредоносный трафик DoH останется незамеченным, оставив организацию слепой к злонамеренному использованию DoH в качестве канала для управления вредоносным ПО (C2) и кражи конфиденциальных данных.
Обеспечение видимости и контроля трафика DoH
В качестве наилучшего решения для контроля DoH мы рекомендуем настроить в NGFW расшифровку трафика HTTPS и блокировку трафика DoH (название приложения: dns-over-https).
Во-первых, убедитесь, что NGFW настроен для расшифровки HTTPS, согласно руководству по лучшим методам расшифровки.
Во-вторых, создайте правило для трафика приложения «dns-over-https», как показано ниже:
В качестве промежуточной альтернативы (если ваша организация не полностью реализовала расшифрование HTTPS) NGFW можно настроить для применения действия «запретить» к идентификатору приложения «dns-over-https», но эффект будет ограничен блокировкой определенных хорошо известных серверов DoH по их доменному имени, так как без расшифрования HTTPS трафик DoH не может быть полностью проверен (см. Applipedia от Palo Alto Networks и выполните поиск по фразе «dns-over-https»).
DNS over TLS (DoT)
В то время как протокол DoH стремится смешиваться с другим трафиком на том же порту, DoT вместо этого по умолчанию использует специальный порт, зарезервированный для этой единственной цели, даже специально запрещая использование того же порта для традиционного незашифрованного трафика DNS ( RFC 7858 , Раздел 3.1 ).
Протокол DoT использует протокол TLS для обеспечения шифрования, инкапсулирующего стандартные запросы протокола DNS, с трафиком, использующим хорошо известный порт 853 ( RFC 7858, раздел 6 ). Протокол DoT был разработан, чтобы упростить организациям блокировать трафик по порту, либо соглашаться на его использование, но включить расшифровку на этом порту.
Риски, связанные с DoT
Google реализовал DoT в своем клиенте Android 9 Pie и более поздних версиях , при этом по умолчанию включена настройка автоматического использования DoT, если он доступен. Если вы оценили риски и готовы к использованию DoT на уровне организации, то нужно, чтобы сетевые администраторы явно разрешали исходящий трафик на порт 853 через свой периметр для этого нового протокола.
Обеспечение видимости и контроля трафика 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).
achekalin
Копирайтеры, нагоняющие волну — они такие копирайтеры!
Вообще, угроза не в DNS, совсем не в нем. В TLS или HTTPS, в которые «обернут» DNS в этом случае — да, но не в DNS.
Я вот, в свою очередь, не понимаю двух вещей: как любое решение для безопасности собирается просматривать шифрованный трафик в принципе, и, что важнее, что оно будет с ним делать, даже если расшифрует.
Второй вопрос совсем не праздный: не так давно еще было вполне привычно гнать весь контрский трафик веб-сайтов через прокси, и на прокси можно было (https было куда менее распространен!) спокойно анализировать всё и вся. И что, разве кто-то умел тогда, имея почти весь трафик открытым, как-то бороться с локерами или воровством кредиток? Да, можно регэкспом ловить все цепочки символов, напоминающие номер кредитки, но это, мы понимаем, тупо, и обходится на раз отправкой номеров, например, в архиве.
На этом фоне вопрос про расшировку трафика как бы не существенен. Из статьи единственное, что более-менее разумно — это что трафик DoT можно зарезать по номеру порта. Остальное, в т.ч. перехват и расшифровка шифрованного трафика (да это же MITM!) требует сурового нагиба всей идеи шифрования («свои» сертификаты, и т.д.) — и не все браузеры, например, на такое поведутся…
ksiva Автор
Прочитайте вот эту презентацию компании Verisign. Там есть слайд, который говорит, что 7 (31%) из 23 исследованных ransomware использовали DNS для обмена ключами.
www.infosecurityeurope.com/__novadocuments/484127
Речь про NGFW. В NGFW после того как трафик TLS расшифрован начинают работать другие движки, и в случае с DNS это DNS Sinkholing, Machine Learning для детекта DGA доменов, Threat Intelligence и др.
Логично, что DNS трафик никак не защищают через HTTP прокси… также как и многих других приложений, который приходится пускать в обход покси.
А как тогда вы будете контролировать DoH и DoT без расшифрования TLS?
achekalin
Я вообще говорю о том, что «расшифровывание шифрования» — это отличная глубокая тема, но шифрование бывает разное, и что факт, что ботнеты будут друг другу слать команды не через DoT, а через обычный нешифрованный ДНС, не убережет большую часть юзеров в первые минуты и часы — а там, если автор ботнета не дурак, он придумает и запасные методы связи. Тем о
Но вот, например, я вам дарю некую волшебную палочку (скорее, волшебное стеклышко из сказки), которая показывает вам расшированным любой обмен по сети. И дальше что, все равно же логика «пустим людей ходить всюду, и динамически отсечен опасное» так и остается сказкой. Все равно вся безопасность строится на запрете всего, чего не нужно для работы, что ок для компаний, но не очень для домашних пользователей (которым страш-ш-шно интересно запустить вот тот откровенно стремный файл!). Получается, палочка особо не помогает — не нужно знать содержимое, надо «не пущать, куда не нужно!»
А если отсекать ненужное, то о какой DoH и DoT Вы говорите — просто зарежте обращения ко внешним ДНС полностью, оставьте доступ только к доверенному подконтрольному серверу, а на том релвите только белый список доменов (добавить в него еще одну зону — по служебке).
Как-то так. Сам очень не люблю попытки организовать конторский (или национальный) catch-all сертификат «просто чтобы все чувствовали себя в безопасности», но вся риторика «вы нам дайте взглянуть, мы тут же безопасность организуем» к тому и идет, к сожалению.
ksiva Автор
Даже в обычном DNS трафике нужно блокировать подключения к центрам управления бот-сетями и также туннели внутри DNS, типа TCP-over-DNS. Для понимания как очищается обычный DNS трафик в сети, видеоролик про DNS Sinkholing
JohnSmith2
Диванные контролеры трафика как всегда в истерике :) А в серьёзных организациях ставят корпоративные сертификаты и слушают трафик через MITM.
ksiva Автор
В статье про это и написано ;-) Что для контроля DoH и DoT нужно включать расшифрование TLS. Функция SSL Decrypt предполагает подмену сертификата (MITM)
Crazyvlad
Без MITM никуда. Фактически сейчас, без подмены сертифткатов, ngfw слабо полезен.
ksiva Автор
К сожалению 50% TLS трафика уже используют ssl pinning и проверку клиентских сертификатов, поэтому расшифровать этот трафик невозможно: обновления, мессенджеры, клиенты на телефонах и др. Поэтому контроль уже переходит на хосты, там активно развивается тема продуктов класса XDR
shifttstas
К сожалению ?! отлично же, в идеале нужно запретить на iOS/Android устанавливать рутовые сертификаты. и MDM сертификаты применять только к доменам входящим в организацию.
ksiva Автор
смотря с какой позиции вы смотрите: хакера или безопасника.
shifttstas
я смотрю с позиции пользователя (или работника) использующего BYOD и не желающего давать доступа работодателю к чему-то кроме рабочего трафика
amarao
Тогда такой пользователь сидит в гостевой сети и использует vpn для доступа к защищённой сети. Или факс.
shifttstas
Я говорю говорю о самом частом случае BYOD (особенно в свете ковид) — МДМ на мобильном устройстве + VDI для доступа к системам.
Revertis
Рутовые сертификаты на устройстве нужны и для локального MitM с целью блокировки рекламы, например.
ksiva Автор
На устройстве у вас трафик и так незашифрован. Вы можете блокировать рекламу и так. Расшифрование нужно только на сетевых устройствах, которые работают как SSL прокси
Revertis
На устройстве между браузером и сетевым стеком трафик ещё зашифрован ;)
amarao
А почему нельзя поднять свой собственный DoH-сервер рядом с рекурсивным ресолвером и юзать его?
ksiva Автор
можно. Только этот сервер должен знать списки вредоносных DNS и блокировать их. Также он должен уметь отличать DGA домены от обычных. Также он должен оповещать CSIRT или SOC об инциденте, чтобы они лечили зараженные компьютеры, которые он увидел.
Revertis
Мне интересно, а почему рэнсомварщики не используют свои методы шифрования на нестандартных портах? Или почему они не могут запустить сервер DoT на порту 8853 например? Только потому, что такой трафик совсем запрещён в корпоративных сетках?
Ну тогда делать C&C-сервер на дешёвых VPS-ках и на 22-ом порту. Он довольно редко блокируется :-D
ksiva Автор
Для этого и существуют исследовательские лаборатории в крупных компаниях — они изучают как работает ransomware и пишут против него защиту. Для неизвестного вредоносного кода нужны более сложные технологии и они тоже есть: специальные ловушки для техник атак, machine learning.
Если взять две точки контроля: сеть и хосты, то есть такая методика написания правил: zero trust, — когда ты разрешаешь каждому сотруднику ровно те приложения, что ему нужны по работе: DNS или DoH, RDP или SSH, если браузер, то только к необходимым категориям URL, если это Word, то ему уж непонятно зачем разрешать скачивать exe файлы. Но хакеры делают туннели внутри разрешенных приложений (или портов если межсетевой экран понимает только порты) и точно также есть методика обнаружения туннелей внутри DNS, SSH, SSL/TLS и тд… Есть методика проверки файлов и блокировки файлов по типам, по сигнатурам вирусов, по regex и тд… вариантов атак много, также как и вариантов защиты. zero trust разрешает ровно то что нужно и запрещает все остальное и все туннели и др ненужная шелуха в сети чистится.