Dns поверх tls android

Минимизация рисков использования 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.

И 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», как показано ниже:

Правило 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)

В то время как протокол 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).

Источник

DNS Over TLS & Over HTTPS теперь и на iOS/Android и для всех сетей сразу [Спасибо Cloudflare]

DNS Over TLS & Over HTTPS (Далее DOT & DOH) — пожалуй именно те технологии которые кардинально повышают приватность и безопасность в Интернете. Есть еще Encrypted SNI, но для её использования нужны DOH и DOT

Обращаю внимание, само приложение — очень UserFriendly даже без глубоких знаний технологий настоятельно рекомендуется ознакомится с ним.

Краткая справка: DNS — система получения IP адреса, фундаментальная часть интернета, которая используется каждый раз при веб браузинге. Открывая тот или иной ресурс, вы сообщаете своему оператору связи куда вы зашли, причем даже если вы поменяете DNS на другой (8.8.8.8 от Google например) — это вам не поможет, из-за отсутствия шифрования в протоколе, что позволяет производить подмену и перенаправление трафика не целевой сервер (фактически атака MITM).

Совсем недавно основной проблемой безопасности в сети был HTTP, но, спасибо Google & LetsEncrypt — она практически решена — теперь что конкретно вы смотрите на сайте — теперь неизвестно провайдеру, осталось только две проблемы:

1. DNS Leak: Это та самая проблема которая может быть решена используя DOH & DOT
2. Domain SNI Leak — проблема раскрытия SNI возникает при установке HTTPS соединения с сайтом, однако, перед началом зашифрованной передачи — браузер в открытом виде передаёт доменное имя сайта для соединение серверу, стандарт eSNI решит эту проблему, но это следующий шаг

Некоторое время назад, на Habr были опубликованы статьи: (рекомендую ознакомиться):

1. Google Public DNS тихо включили поддержку DNS over TLS
2. Встречаем сервис от Cloudflare на адресах 1.1.1.1 и 1.0.0.1, или «полку публичных DNS прибыло!»

И казалось бы, счастье уже близко, две крупные компании решили реализовать новые протоколы и вот-вот поддержка доберётся до конечных пользователей. (Особенно в случае с Chrome)

Но по непонятной причине, поддержка DOT & DOH сейчас есть только в «ночных» сборках Firefox, не говоря уже о системном уровне Android & iOS.

Однако, спасибо CloudFlare, который решил воспользоватся медлительностью Google, и выпустил приложение для iOS & Android

Приложение очень простое, в случае с iOS работа осуществляется через установку профиля VPN
Не путать с настоящим VPN! После установки профиля — фактически будет установлен VPN к самому себе (на 127.0.0.1) и DNS запросы будут отправлены в CloudFlare через DOT & DOH, трафик же пойдет по обычному маршруту.

Что приятно, в приложение есть возможность настроить режим DNS Over TLS или DNS Over HTTPS. по умолчнию используется последний вариант.

Отмечу еще раз, появление иконки VPN не говорит об использовании «VPN» в привычном смысле этого слова, убедится вы сможете зайдя на любой определитель IP, например 2ip.ru

И еще, в случае смены DNS в настройках сети — при переходе от WiFi к WiFi вам нужно каждый раз менять настройки, не говоря уже о DNS для сети оператора связи, редактировать этот параметр иногда вообще невозможно.

В случае с приложением — для любых сосединений будет автоматическим использован DOH / DOT от CloudFlare.

Источник

Google Public DNS тихо включили поддержку DNS over TLS

Внезапно, без предварительного анонса, на 8.8.8.8 заработал DNS over TLS. Ранее Google анонсировал только поддержку DNS over HTTPS.

Публичный резолвер от компании CloudFlare с IP-адресом 1.1.1.1 поддерживает DNS over TLS с момента запуска проекта.

Зачем это нужно

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

C DNS over TLS/HTTPS запросы посылаются внутри зашифрованного тоннеля так, что провайдер не может подменить или просмотреть запрос.

А с приходом шифрования имени домена в сертификатах X.509 (ESNI) станут невозможны блокировки через DPI по SNI (Server Name Indication, специальное поле, в котором передается имя домена в первом TLS-пакете), которые сейчас применяются у некоторых крупных провайдеров.

Как это работает

На порт TCP:853 выполняется TLS-подключение, при этом проверка сертификата резолвера происходит с использованием системных корневых сертификатов, точно так же, как HTTPS в браузере. Это избавляет от необходимости добавлять какие-либо ключи вручную. Внутри тоннеля выполняется обычный DNS-запрос. Это создает меньше накладных расходов по сравнению с DNS over HTTPS, который добавляет HTTP-заголовки к запросу и ответу.

К сожалению, на текущий момент только в Android 9 (Pie) поддержка DNS over TLS встроена в системный резолвер. Инструкция по настройке для Android 9.

Для остальных систем предлагается использовать сторонний демон, а системный резолвер направлять на localhost (127.0.0.1).

Настройка на macOS

Установка

По умолчанию knot будет работать как обычный рекурсивный резолвер, подобно dnsmasq.

Редактируем конфиг

И добавляем в конец файла:

В итоге мой конфиг выглядит так:

Параметр hostname в данном случае — Common Name (CN) или Subject Alt Name (SAN) сертификата. То есть, доменное имя, для которого выпущен сертификат. По нему проверяется подлинность сертификата сервера.

Вот какие значения SAN у сертификата, который используется при подключении на 8.8.8.8:853

Любое из этих значений можно использовать в качестве параметра hostname. Если же вы будете разворачивать собственный публичный рекурсивный резолвер, у вас вряд ли получится выпустить X.509-сертификат на IP-адрес, поэтому в параметре hostname придется указывать доменное имя.

Запуск демона

Проверить, успешно ли запустился демон, можно командой:

процесс kresd должен слушать порт 53 на localhost.

Если что-то пошло не так, смотрим лог ошибок:

Проверка работы резолвера

Проверяем, что локальный резолвер отвечает корректно.

Установка в качестве системного резолвера

Если все работает правильно, можно назначить системный резолвер в свойствах сетевого адаптера:

В чем разница между DNSCrypt, DNSSEC, DNS over TLS/HTTPS.

DNSCrypt может работать по UDP и TCP. Подключение на порт 443. Для шифрования используется собственный протокол, который отличается от HTTPS. Может быть легко выделен с помощью DPI. Это скорее черновик, который тестировали до внедрения DNS over TLS/HTTPS, так как он не имеет RFC, то есть не является официальным стандартом интернета. Вероятнее всего, в скором, времени он будет полностью вытеснен последними.

DNS over TLS (DoT) — TCP-подключение происходит на порт 853, внутри тоннеля передается обычный DNS-запрос. Провайдер видит, что это DNS запрос но не может в него вмешаться. При прочих равных, в DNS over TLS должно быть чуть меньше накладных расходов на каждый запрос, чем в over HTTPS.

DNS over HTTP (DoH) — TCP-подключение на порт 443, подобно обычному HTTPS. Внутри другой формат запроса, с HTTP-заголовками. Однако для провайдера такой запрос будет виден как обычное HTTPS-подключение. Полагаю, этот протокол был придуман на случай, когда DNS-запросы к чужим серверам будут заблокированы, чтобы маскировать под обычный веб трафик. А также, чтобы браузеры могли сами резолвить домены и не создавать при этом аномальный трафик.

По сути, DNS over HTTPS и over TLS — одно и то же, с немного отличающемся форматом запросов. Оба эти протокола приняты в качестве стандартов и имеют RFC. Вероятнее всего, в ближайшее время мы увидим массовое распространение их обоих.

DNSSEC — протокол цифровой подписи DNS-записей. Не имеет отношения к шифрованию, так как все запросы передаются в открытом виде. Может работать как по старому классическому протоколу DNS, то есть UDP/TCP на порту 53, так и внутри DNS over TLS/HTTPS. Целью DNSSEC является подтверждение подлинности DNS-записи. Владелец домена может добавить публичный ключ на корневые сервера своей доменной зоны и подписывать все записи на мастер NS-серверах. По сути, к каждой DNS записи, например, A-записи или MX-записи, добавляется еще одна запись типа RRSIG, содержащая подпись. Процедура валидации DNSSEC на рекурсивном резолвере позволяет установить, действительно эта запись была создана владельцем домена.

Источник