Doh server что это
Минимизация рисков использования 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).
Глубокий в-DoH. Разбираемся, как работает DNS over HTTPS и кому (не) выгодно его внедрение
Содержание статьи
Шаткая скрепа DNS
Для порядка и связности изложения кратко вспомним основные понятия. Система доменных имен DNS — одна из технологий, лежащих в самой основе современного интернета. С ее помощью соотносятся числовые IP-адреса и более удобные для человека доменные имена. Она построена по принципу иерархического взаимодействия DNS-серверов.
Важный момент: разрабатывалась эта система еще в 1983 году, и поэтому у нее есть некоторые проблемы с безопасностью. Ведь интернет тогда, как известно, был сетью, которая связывала американские научные и военные учреждения, и подключать к ней кого попало не планировалось.
Если вкратце, то корень проблемы в том, что базовая система DNS принимает и передает любые запросы, поступающие в нее. Как во многих других решениях, которые появились на заре интернета, защиты от злонамеренного использования здесь нет. В те времена считалось, что главное — это простота и масштабируемость.
В результате появились разные методы атак на DNS-серверы (например, отравление кеша DNS или перехват DNS). Результат таких атак — перенаправление клиентских браузеров куда-то, куда пользователи попадать не собирались.
Для борьбы с этими бедами Инженерный совет интернета разработал набор расширений DNSSEC, который добавил к DNS-запросам подпись-аутентификацию на основе криптографии с открытым ключом. Но разрабатывался этот набор расширений очень долго. Проблема стала очевидной еще в начале девяностых, направление работы над проблемой определили к 1993 году, первую версию DNSSEC подготовили к 1997 году, попытались внедрить, стали вносить изменения.
Если хочешь подробнее разобраться, от каких угроз DNSSEC должен был защитить DNS, то можешь почитать доклад об анализе угроз того самого Инженерного совета интернета от 2004 года. Как пишут его авторы, спустя десять лет после начала работ настало время отчитаться о том, с какими проблемами и как именно мы собираемся бороться.
Но DNSSEC решает только часть проблемы — он гарантирует аутентичность и целостность данных, но не их приватность. В борьбе за эту цель логичным средством выступает шифрование. Вопрос в том, как именно его реализовать.
Варианты шифрования
Несколько групп разработчиков предложили свои варианты технологических решений. Среди них есть те, которые используют оригинальные способы шифрования, например DNSCrypt или DNSCurve, в котором применяется шифрование с использованием эллиптических кривых. Но решения, оказавшиеся в итоге более популярными, опираются на широко распространенный протокол безопасности TLS. Такими решениями являются DoT (DNS over TLS) и DoH, основной предмет этой статьи.
DoT, как и следует из его названия, использует для зашифрованной передачи DNS-запросов сам протокол TLS. Это влечет за собой смену основных портов и протоколов — вместо UDP по порту 53 используется TCP по порту 853.
DoH устроен иначе и по-другому использует TLS. В DoH TLS-шифрование применяется на уровне протокола HTTPS, с использованием HTTPS-запросов и обращением к HTTP-портам DNS-сервера.
Звучит сложновато? Ян Шауман рассказывает об этом очень точно и доходчиво:
Поскольку HTTPS использует TLS, можно было бы позанудствовать и подоказывать, что технически DoH — это тоже DNS через TLS. Но это было бы неверно. DoT отправляет запросы базового протокола DNS через TLS-соединение на отдельном выделенном порте. DoH использует протокол HTTP на уровне протокола прикладного уровня (HTTP application layer protocol), чтобы отправлять запросы на HTTPS-порт сервера, используя и включая все элементы обычных сообщений HTTP.
DoHодим до сути
Здесь резонно задаться вопросом: а в чем вообще тут может быть проблема? Чем больше безопасности, тем лучше, разве не так?
Ответ на этот вопрос лежит в нюансах выбранных решений, их сильных и слабых сторонах. А именно в том, как новая технология взаимодействует с разными участниками системы DNS, кого из них ее разработчики считают условно заслуживающими доверия, а кого — источниками угрозы. И речь сейчас даже не о хакерах-злоумышленниках, имеющих откровенно преступные цели.
Речь о том, что между пользовательским устройством и конечным сайтом находятся посредники. Администратор сети, файрвол, провайдер интернета — все они могут в своих интересах взаимодействовать с системой DNS, задавая своим резолверам имен DNS настройки того, какие запросы отслеживать, блокировать, модифицировать. Так можно встраивать рекламу, отсекать вредоносный контент, не пускать на определенные ресурсы.
Путь запроса от клиента до сервера может проходить через множество резолверов
DoT, работая через TLS с его системой сертификатов доверия, точно так же нуждается в DNS-резолвере, которому он сможет доверять. Присутствует гибкая возможность настройки списка доверенных резолверов, возможность централизованного изменения настроек в предварительно доверенной (например, корпоративной) среде, а также возможность переключаться обратно на базовый DNS, если с новой версией возникнут проблемы.
Поскольку для DoT используется новый, выделенный порт, возможно заметить передаваемый трафик и наблюдать за его объемами, шифрование этому никак не помешает. При желании можно даже заблокировать его вовсе.
В общем, DoT нужно грамотно настроить, но зато он содержит некоторые крайне полезные для системных администраторов и сетевых инженеров функции. Поэтому многие из профессионалов и хвалят за это DoT.
С DoH история другая. Эта технология разрабатывалась с расчетом на пользовательские приложения, а именно — браузеры. Это ключевая деталь во всей этой истории. Означает она вот что. При использовании DoH весь трафик, который не относится к браузерам, идет через базовый DNS, но браузерный трафик при этом обходит любые настройки DNS — на уровне операционной системы, локальной сети, провайдера — и, минуя промежуточные этапы, по HTTPS попадает сразу к поддерживающему DoH резолверу DNS.
И к этой схеме есть ряд серьезных вопросов.
Коварные злодеи и теории заговора
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
MikroTik настройка DoH (DNS поверх HTTPS)
В этой статье мы рассмотрим настройку DNS over HTTPS (DoH) на роутере Mikrotik. DoH был добавлен в релиз RouterOS начиная с версии 6.47. И предназначен для выполнения разрешения ДНС-запросов по https.
Освоить MikroTik вы можете с помощью онлайн-курса «Настройка оборудования MikroTik». В курсе изучаются все темы из официальной программы MTCNA. Автор – официальный тренер MikroTik. Материал подходит и тем, кто уже давно работает с оборудованием MikroTik, и тем, кто еще не держал его в руках. В состав входят 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.
DNS over HTTPS. Краткое описание
Основная проблема заключается в том, что запросы от клиента до сервера передаются в открытом виде, без шифрования и могут проходить через множество посредников (провайдер, firewall).
Путь запроса от клиента до сервера
Получается, что у провайдера есть возможность хранить и анализировать историю запрошенных вами сайтов. Блокировать или модифицировать запросы, встраивая рекламу партнеров, запрещать доступ на определенные ресурсы. А также этим могут воспользоваться злоумышленники, пропуская веб-трафик через себя, таким образом, получая отправленные пользователем конфиденциальные данные (логин, пароль и т.д.). Такой тип атаки называется «человек посередине (MITM)».
DNS over HTTPS(DoH) — технология, которая повышает безопасность и надежность подключения ДНС используя для шифрования передаваемых данных протокол HTTPS.
Протокол DoH разрабатывался для браузеров. Поэтому трафик от пользовательского приложения по HTTPS попадает к поддерживающему DoH resolver, минуя DNS настройки операционной системы, внутренней сети, интернет-провайдера и посредников. Остальной трафик идет через базовый DNS.
Настройка Mikrotik DoH
Сегодня можно выделить две компании, предлагающие публичные DNS-резолверы с поддержкой DoH:
Проверка версии RouterOS
Как упоминалось выше, настраиваемый функционал появился в RouterOS v6.47, проверим версию прошивки. Перейдем:
Если версия ниже 6.47, то необходимо выполнить обновление прошивки Mikrotik.
Отключить динамический DNS
При подключении к интернет-провайдеру DHCP или PPPoE клиентом, “по умолчанию” настройки DNS назначаются автоматически. Для правильной работы DoH эту функцию нужно отключить:
Загрузка Корневых сертификатов
Для того чтобы проверять подлинность ДНС-запросов, нужно установить сертификат корневого центра сертификации.
Cloudflare
Серверы компании подписаны сертификатом DigiCert Global Root CA. Переходим по ссылке и скачиваем:
Для серверов Гугл качаем отсюда:
Mikrotik DoH. Настройка конфигурации Cloudflare
Приступим непосредственно к настройке. Для начала перенесем ранее скаченный файл сертификата в любую часть рабочего поля программы Winbox:
Следующим шагом импортируем файл:
Из консоли
Чтобы скачать и импортировать сертификат из командной строки, откроем терминал:
На этом настройка закончена.
Mikrotik DoH. Настройка конфигурации Google
Конфигурирование производится аналогичным образом, но есть одно небольшое отличие, о котором поговорим ниже. Начнем с импорта сертификата:
Так как сервера Google не воспринимают IP-адрес в запросе, нужно задать его соответствие к доменному имени вручную.
Проверка
Чтобы проверить правильно ли вы настроили DoH на маршрутизаторе Mikrotik, перейдем на специальную страницу Clouflare:
И также можно запустить torch на интерфейсе WAN. Соединений по 53 порту tcp или udp не должно быть.
А также рекомендуем изучить статьи:
Заключение
Мы узнали, как на маршрутизаторе Mikrotik настроить DNS поверх HTTPS используя публичные серверы Clouflare или Google. Надеемся статья была познавательной и полезной! Для более полного понимания работы ДНС, рекомендуем статью Mikrotik настройка DNS.
Освоить MikroTik вы можете с помощью онлайн-курса «Настройка оборудования MikroTik». В курсе изучаются все темы из официальной программы MTCNA. Автор – официальный тренер MikroTik. Материал подходит и тем, кто уже давно работает с оборудованием MikroTik, и тем, кто еще не держал его в руках. В состав входят 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.
DoH в картинках
Угрозы конфиденциальности и безопасности в интернете становятся серьёзнее. Мы в Mozilla внимательно их отслеживаем. Считаем своей обязанностью сделать всё возможное для защиты пользователей Firefox и их данных.
Нас беспокоят компании и организации, которые тайно собирают и продают пользовательские данные. Поэтому мы добавили защиту от слежения и создали расширение контейнера Facebook. В ближайшие месяцы появится ещё больше защитных мер.
Сейчас мы добавляем в список ещё две технологии:
Но сначала посмотрим, как веб-страницы передаются по интернету.
Если вы уже знаете, как работают протоколы DNS и HTTPS, можете перейти к разделу о том, как помогает DNS по HTTPS.
Краткий курс по HTTP
Когда люди объясняют, как браузер загружает веб-страницу, то обычно объясняют это так:
Эта система называется HTTP.
Но эта схема слишком упрощена. Ваш браузер не разговаривает напрямую с сервером. Наверное потому что они не близки друг другу.
Сервер может быть за тысячи километров. И вероятно, между вашим компьютером и сервером нет прямой связи.
Таким образом, прежде чем запрос попадёт из браузера на сервер, он пройдёт через несколько рук. То же самое верно для ответа.
Я думаю об этом как о школьниках, передающих друг другу записки в классе. Снаружи в записке написано, кому она предназначена. Ребёнок, написавший записку, передаст её соседу. Затем тот следующий ребёнок передаёт её одному из соседей — вероятно, не конечному получателю, а тому, кто находится в нужном направлении.
— Псст… передай это Сэнди
Проблема в том, что любой по пути может открыть записку и прочитать её. И нет никакого способа узнать заранее, по какому пути будет проходить записка, поэтому неизвестно, какие люди получат доступ к ней.
Она может оказаться в руках людей, которые сделают вредные вещи…
Например, поделятся содержанием записки со всеми.
— О, это пикантно…. Эй народ! Дэнни влюбился в Сэнди!
— Я тебе тоже нравлюсь?
— Хе-хе, подшучу над ним и напишу «Нет».
Чтобы устранить эти проблемы, создана новая безопасная версия HTTP. Она называется HTTPS: это словно замок на каждом сообщении.
Только браузер и сервер знают комбинацию для снятия блокировки. Даже если сообщения проходят через несколько маршрутизаторов, только вы и веб-сайт фактически можете прочитать содержимое.
Это решает многие вопросы безопасности. Но между вашим браузером и сервером всё еще есть незашифрованные сообщения. Значит, люди на пути всё ещё могут вмешиваться в ваши дела.
Например, данные по-прежнему открыты во время установки подключения. При отправке исходного сообщения на сервер вы также отправляете имя сервера в поле “Server Name Indication”. Это позволяет операторам сервера запускать несколько сайтов на одном компьютере и в то же время понимать, с кем вы хотите связаться. Этот первоначальный запрос — часть установки шифросвязи, но сам первоначальный запрос не шифруется.
Другое место, где данные открыты — это DNS. Но что такое DNS?
DNS: система доменных имён
В метафоре с передачей записок в классе я сказала, что имя получателя должно быть написано снаружи записки. Это верно и для HTTP-запросов… они должны объявить, куда собираются идти.
Но вы не можете использовать обычное имя сайта. Ни один из маршрутизаторов не понимает, о ком вы говорите. Вместо этого необходимо использовать IP-адрес. Вот как маршрутизаторы по пути понимают, на какой сервер вы хотите отправить запрос.
— Пожалуйста, отправь это на 208.80.154.224
Это вызывает проблемы. Пользователям неудобно запоминать цифры IP-адреса. Хочется дать сайту запоминающееся имя… которое отложится в памяти у людей.
Вот почему у нас есть система доменных имен (DNS). Ваш браузер использует DNS для преобразования имени сайта в IP-адрес. Этот процесс — преобразование доменного имени в IP-адрес — называется разрешением имени домена или резолвингом.
Как браузер решает задачу?
Один из вариантов — завести большой список вроде телефонного справочника в браузере. Но по мере того, как появляются новые веб-сайты или перемещаются на новые серверы, будет трудно поддерживать этот список в актуальном состоянии.
Таким образом, вместо одного списка для всех доменных имён существует много небольших списков, связанных друг с другом. Это позволяет им управляться независимо.
Для получения IP-адреса, соответствующего доменному имени, необходимо найти конкретный список, который содержит нужное доменное имя. Это похоже на поиск клада.
Домен можно разделить на части.
С такими частями можно начать охоту на список, содержащий IP-адрес сайта. Но нам нужна помощь в поисках. Инструмент, который осуществляет эту охоту вместо нас и находит IP-адрес, называется резолвером.
Сервер имён TLD посоветует резолверу задать этот вопрос серверу имён Википедии.
— Вы не знаете, как пройти на en.wikipedia.org?
— Иди и спроси у 11.21.31.41, он знает о сайтах в домене wikipedia.org
— Вы не знаете, как пройти на en.wikipedia.org?
— О да, просто иди на 208.80.154.224
Этот процесс называется рекурсивным разрешением, потому что приходится ходить туда и обратно, задавая разным серверам по сути один и тот же вопрос.
Я говорила, что нам нужен резолвер для помощи в поисках. Но как браузер находит этот резолвер? В общем, он спрашивает у операционной системы.
— Мне нужен резолвер. Можешь помочь?
— Конечно, позволь познакомить тебя с резолвером, который я использую
Как операционная система знает, какой резолвер использовать? Существует два возможных способа.
Вы можете настроить компьютер на использование определённого резолвера, которому доверяете. Но очень немногие люди делают это.
Вместо этого большинство просто использует настройки по умолчанию. И по умолчанию ОС будет использовать любой резолвер, какой скажет сеть. Когда компьютер подключается к сети и получает свой IP-адрес, то сеть рекомендует определённый резолвер.
— Можно мне получить IP-адрес?
— Без проблем! А если тебе понадобится резолвер, рекомендую вот этот
Это значит, что используемый резолвер может изменяться несколько раз в день. Если вы направляетесь в кафе поработать днём, то вероятно используете другой резолвер, чем утром. И так происходит даже если вы настроили свой собственный резолвер, потому что в протоколе DNS нет никакой безопасности.
Как можно эксплойтить DNS?
Так как эта система подвергает опасности пользователей?
Обычно резолвер сообщает каждому DNS-серверу, какой домен вы ищете. Этот запрос иногда включает ваш полный IP-адрес. А если не полный адрес, то всё чаще запрос включает в себя большую часть вашего IP-адреса, что можно легко объединить с другой информацией, чтобы установить вашу личность.
Содержит большую часть вашего IP-адреса…
… и полный домен, который вы ищете
Значит, каждый сервер, который вы попросите помочь с разрешением доменных имен, видит, какой сайт вы ищете. Более того, любой по пути к этим серверам тоже видит ваши запросы.
Существует несколько способов, как подобная система подвергает риску данные пользователей. Два основных — трекинг (отслеживание) и спуфинг (подмена).
Трекинг
Как я говорила выше, по полной или частичной информацию об IP-адресе несложно определить личность того, кто просит доступ к конкретному сайту. Это означает, что DNS-сервер и любой пользователь на пути к этому DNS-серверу (маршрутизатор по пути) может создать профиль пользователя. Они могут составить список всех сайтов, которые вы просмотрели.
И это ценные данные. Многие люди и компании готовы немало заплатить, чтобы увидеть вашу историю посещённых страниц.
Сколько вы готовы заплатить за информацию о том, на что смотрел Джон Доу?
Даже если бы нам не пришлось беспокоиться о потенциально гнусных DNS-серверах или маршрутизаторах по пути, всё равно есть риск, что ваши данные соберут и продадут. Потому что сам резолвер — который вам дала сеть — может оказаться ненадёжным.
Даже если вы доверяете рекомендованному резолверу от сети, то вероятно используете его только дома. Как я уже упоминала, каждый раз в кафе, отеле или в любой другой сети вам, вероятно, дадут другой резолвер. И кто знает, какова его политика сбора данных?
Кроме того, что ваши данные собираются и затем продаются без вашего ведома или согласия, систему используют ещё более опасным способом.
Спуфинг
При помощи спуфинга некто на пути между вами и DNS-сервером меняет ответ. Вместо реального IP-адреса мошенник сообщает вам неправильный IP-адрес для сайта. Таким образом, вам могут заблокировать доступ к реальному сайту или отправить не поддельную версию от мошенников.
Отправь это на 1.6.6.6… это абсолютно правильный адрес, а вовсе не поддельный сайт, который я контролирую
Опять же, здесь и сам резолвер может действовать гнусно.
Предположим, вы делаете покупку в магазине Megastore. Вы хотите сравнить цены и посмотреть, не продаётся ли такой товар дешевле в конкурирующем интернет-магазине big-box.com.
Но если вы пользуетесь Megastore WiFi у них в торговом зале, то вероятно используете их резолвер. Он может перехватить запрос к big-box.com и соврать вам, что сайт недоступен.
Как исправить ситуацию с помощью Trusted Recursive Resolver (TRR) и DNS over HTTPS (DoH)?
Мы в Mozilla твёрдо убеждены, что несём ответственность за защиту пользователей и их данных, и поэтому работаем над устранением данных уязвимостей.
Представляем две новые функции для исправления ситуации: это доверенный рекурсивный резолвер (Trusted Recursive Resolver, TRR) и DNS по HTTPS (DoH). Потому что на самом деле имеется три угрозы:
Как этого избежать?
Избегать ненадёжных резолверов с помощью TRR
Сети могут перестать рекомендовать ненадёжные резолверы, которые собирают данные пользователей или подделывают DNS-запросы, потому что очень немногие пользователи знают о рисках или о том, как защитить себя.
Даже для пользователей, которые знают о рисках, отдельному пользователю трудно договориться со своим провайдером или другой организацией о гарантиях, что с его DNS-запросами будут ответственно обращаться.
Тем не менее, мы изучили этих риски… и у нас есть определённое влияние. Мы долго искали компанию, которая поможет нам защитить DNS-данные пользователей. И нашли одну такую: Cloudflare.
Cloudflare предоставляет сервис рекурсивного резолвинга с политикой конфиденциальности для пользователей. Они обязались удалять все привязанные к конкретным людям данные (personally identifiable data) после 24 часов и никогда не передавать эти данные третьим лицам. Будут проводиться регулярные проверки, что данные действительно удаляются, как было обещано.
Благодаря этому у нас есть доверенный резолвер для защиты приватности пользователей. Это означает, что Firefox может игнорировать резолвер сети, а перейти сразу к Cloudflare. Теперь можно не беспокоиться, что злоумышленники используют резолвер для продажи данных пользователей или спуфинга DNS.
Почему мы выбрали один резолвер? Как и мы, Cloudflare озабочен созданием приватной службы DNS. Они вместе с нами разработали хороший прозрачный резолвер DoH. Компания с готовностью пошла на дополнительную защиту сервиса, поэтому мы рады сотрудничать с ними.
Но это не значит, что вы должны использовать Cloudflare. Пользователи могут настроить Firefox на использование любого рекурсивного резолвера с поддержкой DoH. По мере появления новых сервисов мы планируем реализовать простое обнаружение и переключение между ними.
Защищаться от прослушивания и спуфинга с помощью DNS по HTTPS
Но резолвер — не единственная угроза. Маршрутизаторы на пути могут отслеживать и подделывать DNS-запросы, поскольку тоже видят содержимое запросов и ответов DNS. К счастью, в интернете уже есть технология для защиты от прослушивания со стороны маршрутизаторов на пути. Это шифрование, о котором я говорила.
Использование HTTPS для обмена DNS-пакетами защищает DNS-запросы наших пользователей от шпионажа.
Передавать как можно меньше данных, чтобы защитить пользователей от деанонимизации
Вдобавок к доверенному резолверу, который работает по протоколу DoH, мы с компанией Cloudflare работаем над дополнительными мерами безопасности.
Обычно резолвер отправляет полное имя домена каждому серверу: корневому DNS, серверу имён доменов верхнего уровня, второго уровня и т. д. Но сервер Cloudflare будет поступать иначе. Он будет отправлять только ту часть, которая имеет отношение к конкретному DNS-серверу. Это называется минимизация QNAME.
Часто резолвер также включает в запрос первые 24 бита вашего IP-адреса. Это помогает DNS-серверу узнать, где вы находитесь, и выбрать ближайший CDN. Но DNS-серверы могут использовать данную информацию для связывания друг с другом разрозненных запросов.
Вместо этого Cloudflare будет делать запрос с одного из собственных IP-адресов, который находится рядом с пользователем. Это обеспечивает геолокацию без привязки к конкретному человеку. Мы также изучаем, как реализовать ещё лучшую, тонкую балансировку нагрузки с учётом конфиденциальности.
Всё это — удаление ненужных частей домена и IP-адреса — означает, что DNS-сервер может собрать о вас гораздо меньше данных.
Что остаётся за рамками TRR с DoH?
Эти защитные меры сокращают количество людей, которые могут видеть историю посещённых вами страниц. Но они полностью не исключают утечки данных.
После выполнения поиска в DNS для получения IP-адреса по-прежнему необходимо подключиться к веб-серверу по этому адресу. Для этого необходимо отправить запрос. Запрос включает в себя SNI (server name indication) с указанием конкретного сайта на сервере. И этот запрос не шифруется.
То есть ваш интернет-провайдер по-прежнему способен выяснить, какие сайты вы посещаете, потому что они указаны прямо там, в SNI. Информация открыта и для маршрутизаторов, которые передают первоначальный запрос из вашего браузера на веб-сервер.
Но как только вы установили соединение с веб-сервером, всё зашифровано. И самое главное, что данное зашифрованное соединение можно использовать для любого сайта на этом сервере, а не только для того, который вы изначально запрашивали.
Это иногда называют слиянием соединения HTTP/2 (connection coalescing) или просто повторным использованием соединения. Когда вы открываете соединение с совместимым сервером, он сообщит, какие ещё сайты размещаются на нём. Затем вы можете посетить эти сайты, используя существующее зашифрованное соединение.
Почему это полезно? Потому что не нужно открывать новое соединение для подключения к этим другим сайтам. То есть вам не нужно отправлять ещё один незашифрованный первоначальный запрос с указанием SNI и раскрытием информации, на какой сайт вы идёте. Так вы можете посетить любой из других сайтов на том же сервере, не раскрывая их своему провайдеру и маршрутизаторам на пути.
С ростом популярности CDN всё больше отдельных сайтов обслуживаются одним сервером. И поскольку у вас может быть открыто несколько объединённых соединений, вы одновременно подключаетесь к нескольким общим серверам или CDN, посещая все сайты на разных серверах без утечки данных. Так что данная функция всё более эффективно работает как защитный экран.
Каков статус?
Уже сейчас в Firefox вы можете включить DNS по HTTPS, и мы рекомендуем сделать это.
Мы хотим включить DoH по умолчанию для всех пользователей, поскольку каждый человек заслуживает конфиденциальности и безопасности, независимо от того, знает он об утечках DNS или нет.
Но это значительное изменение, и его нужно сначала протестировать. Поэтому мы проводим исследование. Половину наших пользователей Firefox Nightly мы просим помочь собрать данные о производительности.
В тестировании используется резолвер по умолчанию, как и сейчас, но также запросы отправляются на DoH-резолвер Cloudflare. Затем мы сравниваем результат для проверки, что всё работает как положено.
Для участников исследования ответ Cloudflare DNS пока не используется. Мы просто проверяем, что всё работает, а затем выбрасываем ответ Cloudflare.
Выражаем благодарность за поддержку пользователям Nightly, которые каждый день помогают тестировать Firefox. Надеемся, что вы тоже поможете нам.