Dns запросы не защищены
Эта статья по сути является текстовой калькой с выступления Андрея Мешкова, сооснователя и CTO AdGuard, на коференции Ad Blocker Dev Summit 2021. Если вы не хотите читать “много букв”, уделите 30 минут просмотру этого видео (на английском языке).
Сегодня к интернету подключено абсолютно всё — от телевизора до умных лампочек, от мобильных устройств до умных автомобилей. А где есть интернет, есть трекеры и реклама. Верно? Получается, что один только браузерный блокировщик не сможет защитить вас. В его силах лишь предоставить вам крошечное окно в «лучший интернет» без агрессивных и навязчивых баннеров, пытающихся завладеть вашим вниманием. Но что, если вы хотите расширить это «окно»?
В этом случае пристегните ремни и приготовьтесь к увлекательному путешествию по прошлому, настоящему и будущему DNS-фильтрации. Почему? Потому что DNS — это ответ!
Прародитель DNS — HOSTS-файл
Удивительно, но блокировка на уровне DNS — самый старый известный подход к блокировке рекламы. Как такое возможно?
Ещё в те дни, когда интернет был молод и назывался ARPANET, была разработана система именования, которая сопоставляла IP-адрес компьютера с уникальным идентификатором на основе ASCII. Имея всего несколько компьютеров, подключенных к ARPANET, Центр сетевой информации Министерства обороны США поддерживал файл с именем HOSTS.TXT — главный список адресов всех компьютеров и их хост-имён. Системные администраторы периодически загружали обновленный HOSTS.TXT. Зная имя компьютера ARPANET, можно было просто посмотреть его IP-адрес в файле HOSTS.
Так выглядел файл HOSTS.TXT, который использовался во времена ARPANET
Но вскоре стало ясно, что растущее число хостов создает слишком большую нагрузку на компьютер NIC (Network Information Center). Все хотели иметь свои компьютеры в ARPANET, но им приходилось ждать, пока организация NIC обновит HOSTS.TXT. Возникла необходимость в альтернативном решении, поэтому в конце 1987 года Пол Мокапетрис разработал систему доменных имён.
Но файл HOSTS не был забыт. Вскоре после появления первой рекламы в интернете люди обнаружили, что HOSTS.TXT можно использовать в качестве блоклиста для предотвращения загрузки рекламы (такой подход очень напоминает технику «DNS Sinkholing», не так ли?) После этого некоторые энтузиасты стали составлять первые блоклисты и делиться ими со всеми желающими. Есть несколько ярких примеров блоклистов с более чем 20-летней историей, которые активно развиваются и по сей день, например, блоклисты Питера Лоу, блоклисты Стивена Блэка или хосты Дэна Поллока.
Фрагмент блоклиста Питера Лоу
Когда появилась первая версия Adblock для Firefox, некоторые пользователи просто не могли понять его предназначение. Их всё устраивало в том, как работал файл HOSTS.
Скриншот записи на форуме, 2003 г.
Однако файлы HOSTS имеют некоторые недостатки, которые не так просто устранить.
Распространение обновлений. Не существует удобного способа предоставления обновлений файла HOSTS пользователям. Для этого нужно либо иметь специальное программное обеспечение, либо быть очень терпеливым и периодически делать это вручную.
Большие размеры. Файлы HOSTS становятся просто огромными из-за того, в них нельзя использовать подстановочные знаки и необходимо прописывать каждый домен. Синтаксис файла HOSTS просто не предназначен для использования таким образом. Взгляните на рисунок ниже, где показан один из самых больших блоклистов — Energized Unified. Как вы можете видеть, он содержит более 700 тысяч доменов и весит почти 21 мегабайт. Распространять файл размером 21 Мб среди миллионов пользователей ежедневно — это уже серьезная проблема.
Блоклист Energized Unified
Публичные DNS-серверы, блокирующие рекламу, появились как перспективная альтернатива файлу HOSTS. Достаточно было настроить устройство на использование такого сервера, и больше не нужно было возиться с обновлением файлов HOSTS. Один из первых публичных DNS-серверов назывался Alternate DNS и появился в 2015 году. Его обслуживанием занимался один человек. Позже, в 2016 году, мы запустили AdGuard DNS.
Как работает DNS-фильтрация?
DNS-фильтрация — это мощный инструмент, который поддерживается всеми основными приложениями AdGuard: AdGuard для Windows, AdGuard для Mac, AdGuard для Android и AdGuard для iOS.
DNS-фильтрация может быть условно разделена на две основные функции: шифрование DNS-трафика и его перенаправление на DNS-сервер, а также блокировка определённых доменов с помощью локальных DNS-фильтров.
DNS-серверы
Другие DNS-провайдеры могут работать иначе, так что узнайте все подробности перед тем, как делать выбор в пользу того или иного сервера. Вы можете найти список некоторых популярных DNS-провайдеров в этой статье. Все приложения AdGuard, которые поддерживают DNS-функционал, также предоставляют на выбор список проверенных DNS-серверов и даже дают возможность вручную указать любой предпочитаемый вами DNS-сервер.
Локальные DNS-фильтры
Но если полагаться только на DNS-серверы в вопросе фильтрации DNS-трафика, то неизбежны потери в гибкости. Если выбранный сервер блокирует какой-либо домен, вы не сможете на него перейти, пока не переключитесь на другой сервер. С AdGuard же вам даже не обязательно настраивать какой-то конкретный DNS-сервер, чтобы фильтровать DNS-трафик. Все продукты AdGuard позволяют добавлять локальные DNS-фильтры, будь то простые файлы hosts или фильтры, использующие более сложный DNS-синтаксис. Они работают сходным образом с обычными рекламными фильтрами: когда DNS-запрос подходит под одно из правил в активном фильтре, он блокируется. Чтобы быть более точным, перенаправляется "в никуда".
Чтобы получить доступ к DNS-фильтрации в AdGuard для iOS, вам сначала потребуется включить "Расширенный режим" в настройках.
Вы можете добавлять столько собственных DNS-фильтров, сколько захотите. Например, вы можете задействовать DNS-фильтр AdGuard. Он буквально блокирует всё то же самое, что и сервер AdGuard DNS, но в данном случае вы вольны использовать любой другой DNS-сервер. Плюс, при использовании данного метода вы можете добавить больше фильтров или же создать собственные правила-исключения. Всё это было бы невозможно в случае с использованием только DNS-сервера.
Существуют сотни различных DNS-фильтров, вы можете выбрать нужные вам здесь.
Оповещения мониторинга DNS
Возможность эффективно отслеживать трафик DNS в вашей сети на предмет подозрительных аномалий имеет решающее значение для раннего обнаружения взлома. Использование такого инструмента, как Varonis Edge даст вам возможность быть в курсе всех важных показателей и создавать профили для каждой учетной записи в вашей сети. Вы можете настроить генерацию оповещений в результате комбинации действий, происходящих за определенный период времени.
Мониторинг изменений DNS, местоположений учетной записи, а также фактов первого использования и получения доступа к конфиденциальным данным, а также активности в нерабочее время — это лишь несколько показателей, которые можно сопоставить для составления более обширной картины обнаружения.
Шифрование трафика между вашим устройством и DNS-сервисом помешает посторонним лицам отслеживать трафик или подменить адрес
Смерть сетевого нейтралитета и ослабление правил для интернет-провайдеров по обработке сетевого трафика вызвали немало опасений по поводу конфиденциальности. У провайдеров (и других посторонних лиц, которые наблюдают за проходящим трафиком) уже давно есть инструмент, позволяющий легко отслеживать поведение людей в интернете: это их серверы доменных имен (DNS). Даже если они до сих пор не монетизировали эти данные (или не подменяли трафик), то наверняка скоро начнут.
«Открытые» DNS-сервисы позволяют обходить сервисы провайдеров ради конфиденциальности и безопасности, а кое в каких странах — уклоняться от фильтрации контента, слежки и цензуры. 1 апреля (не шутка) компания Cloudflare запустила свой новый, бесплатный и высокопроизводительный DNS-сервис, предназначенный для повышения конфиденциальности пользователей в интернете. Он также обещает полностью скрыть DNS-трафик от посторонних глаз, используя шифрование.
Названный по своему IP-адресу, сервис 1.1.1.1 — это результат партнёрства с исследовательской группой APNIC, Азиатско-Тихоокеанским сетевым информационным центром, одним из пяти региональных интернет-регистраторов. Хотя он также доступен как «открытый» обычный DNS-резолвер (и очень быстрый), но Cloudflare ещё поддерживает два протокола шифрования DNS.
Хотя и разработанный с некоторыми уникальными «плюшками» от Cloudflare, но 1.1.1.1 — никак не первый DNS-сервис с шифрованием. Успешно работают Quad9, OpenDNS от Cisco, сервис 8.8.8.8 от Google и множество более мелких сервисов с поддержкой различных схем полного шифрования DNS-запросов. Но шифрование не обязательно означает, что ваш трафик невидим: некоторые службы DNS с шифрованием всё равно записывают ваши запросы в лог для различных целей.
Cloudflare пообещал не журналировать DNS-трафик и нанял стороннюю фирму для аудита. Джефф Хастон из APNIC сообщил, что APNIC собирается использовать данные в исследовательских целях: диапазоны 1.0.0.0/24 и 1.1.1.0/24 изначально были сконфигурированы как адреса для «чёрного» трафика. Но APNIC не получит доступ к зашифрованному трафику DNS.
Для пользователей подключить DNS-шифрование не так просто, как изменить адрес в настройках сети. В настоящее время ни одна ОС напрямую не поддерживает шифрование DNS без дополнительного программного обеспечения. И не все сервисы одинаковы с точки зрения софта и производительности.
Как работает DNS
Есть много причин для лучшей защиты DNS-трафика. Хотя веб-трафик и другие коммуникации могут быть защищены криптографическими протоколами, такими как Transport Layer Security (TLS), но почти весь трафик DNS передаётся незашифрованным. Это означает, что ваш провайдер (или кто-то другой между вами и интернетом) может регистрировать посещаемые сайты даже при работе через сторонний DNS — и использовать эти данных в своих интересах, включая фильтрацию контента и сбор данных в рекламных целях.
Как выглядит типичный обмен данными между устройством и DNS-резолвером
«У нас есть проблема “последней мили” в DNS, — говорил Крикет Лю, главный архитектор DNS в компании Infoblox, которая занимается информационной безопасностью. — Большинство наших механизмов безопасности решают вопросы коммуникаций между серверами. Но есть проблема с суррогатами резолверов на различных операционных системах. В реальности мы не можем их защитить». Проблема особенно заметна в странах, где власти более враждебно относятся к интернету.
Наиболее очевидный способ уклонения от слежки — использование VPN. Но хотя VPN скрывают содержимое вашего трафика, для подключения к VPN может потребоваться запрос DNS. И в ходе VPN-сеанса запросы DNS тоже могут иногда направляться веб-браузерами или другим софтом за пределы VPN-тоннеля, создавая «утечки DNS», которые раскрывают посещённые сайты.
Однако эта опция защиты недоступна массовому пользователю. Ни один из этих протоколов нативно не поддерживается ни одним DNS-резолвером, который идёт в комплекте с ОС. Все они требуют установки (и, вероятно, компиляции) клиентского приложения, которое действует как локальный «сервер» DNS, ретранслируя запросы, сделанные браузерами и другими приложениями вверх по течению к безопасному провайдеру DNS по вашему выбору. И хотя две из трёх данных технологий предлагаются на роль стандартов, ни один из проверенных нами вариантов пока не представлен в окончательном виде.
Поэтому если хотите погрузиться в шифрование DNS, то лучше взять для DNS-сервера в домашней сети Raspberry Pi или другое отдельное устройство. Потому что вы наверняка обнаружите, что настройка одного из перечисленных клиентов — это уже достаточно хакерства, чтобы не захотеть повторять процесс заново. Проще запросить настройки DHCP по локальной сети — и указать всем компьютерам на одну успешную установку DNS-сервера. Я много раз повторял себе это во время тестирования, наблюдая падение одного за другим клиентов под Windows и погружение в спячку клиентов под MacOS.
Сообщество DNSCrypt пыталось сделать доступный инструмент для тех, кто не обладает навыками работы в командной строке, выпустив программы DNSCloak (слева) под iOS и Simple DNSCrypt (справа) под Windows
Для полноты картины в исторической перспективе начнём обзор с самой первой технологии шифрования DNS — DNSCrypt. Впервые представленный в 2008 году на BSD Unix, инструмент DNSCrypt изначально предназначался для защиты не от прослушки, а от DNS-спуфинга. Тем не менее, его можно использовать как часть системы обеспечения конфиденциальности — особенно в сочетании с DNS-сервером без логов. Как отметил разработчик DNSCrypt Фрэнк Денис, гораздо больше серверов поддерживают DNSCrypt, чем любой другой вид шифрования DNS.
«DNSCrypt — это немного больше, чем просто протокол, — говорит Фрэнк Денис. — Сейчас сообщество и активные проекты характеризуют его гораздо лучше, чем мой изначальный протокол, разработанный в выходные». Сообщество DNSCrypt создало простые в использовании клиенты, такие как Simple DNSCrypt для Windows и клиент для Apple iOS под названием DNS Cloak, что делает шифрование DNS доступнее для нетехнических людей. Другие активисты подняли независимую сеть приватных DNS-серверов на основе протокола, помогающего пользователям уклониться от использования корпоративных DNS-систем.
«DNSCrypt — это не подключение к серверам конкретной компании, — сказал Денис. — Мы призываем всех поднимать собственные сервера. Сделать это очень дёшево и легко. Теперь, когда у нас есть безопасные резолверы, я пытаюсь решить задачу фильтрации контента с учётом конфиденциальности».
Для тех, кто хочет запустить DNS-сервер с поддержкой DNSCrypt для всей своей сети, лучшим клиентом будет DNSCrypt Proxy 2. Старая версия DNSCrypt Proxy по-прежнему доступна как пакет для большинства основных дистрибутивов Linux, но лучше загрузить бинарник новой версии непосредственно с официального репозитория на GitHub. Есть версии для Windows, MacOS, BSD и Android.
Опыт сообщества DNSCrypt по защите конфиденциальности воплощён в DNSCrypt Proxy. Программа легко настраивается, поддерживает ограничения по времени доступа, шаблоны для доменов и чёрный список IP-адресов, журнал запросов и другие функции довольно мощного локального DNS-сервера. Но для начала работы достаточно самой базовой конфигурации. Есть пример файла конфигурации в формате TOML (Tom's Obvious Minimal Language, созданный соучредителем GitHub Томом Престоном-Вернером). Можете просто переименовать его перед запуском DNSCrypt Proxy — и он станет рабочим файлом конфигурации.
По умолчанию прокси-сервер использует открытый DNS-резолвер Quad9 для поиска и получения с GitHub курируемого списка открытых DNS-сервисов. Затем подключается к серверу с самым быстрым откликом. При необходимости можно изменить конфигурацию и выбрать конкретный сервис. Информация о серверах в списке кодируется как «штамп сервера». Он содержит IP-адрес поставщика, открытый ключ, информацию, поддерживает ли сервер DNSSEC, хранит ли провайдер логи и блокирует ли какие-нибудь домены. (Если не хотите зависеть от удалённого файла при установке, то можно запустить «калькулятор штампов» на JavaScript — и сгенерировать собственный локальный статичный список серверов в этом формате).
Для своего тестирования DNSCrypt я использовал OpenDNS от Cisco в качестве удалённого DNS-сервиса. При первых запросах производительность DNSCrypt оказалась немного хуже, чем у обычного DNS, но затем DNSCrypt Proxy кэширует результаты. Самые медленные запросы обрабатывались в районе 200 мс, в то время как средние — примерно за 30 мс. (У вас результаты могут отличаться в зависимости от провайдера, рекурсии при поиске домена и других факторов). В целом, я не заметил замедления скорости при просмотре веб-страниц.
С другой стороны, DNSCrypt для шифрования не полагается на доверенные центры сертификации — клиент должен доверять открытому ключу подписи, выданному провайдером. Этот ключ подписи используется для проверки сертификатов, которые извлекаются с помощью обычных (нешифрованных) DNS-запросов и используются для обмена ключами с использованием алгоритма обмена ключами X25519. В некоторых (более старых) реализациях DNSCrypt есть условие для сертификата на стороне клиента, который может использоваться в качестве схемы управления доступом. Это позволяет им журналировать ваш трафик независимо от того, с какой IP-адреса вы пришли, и связывать его с вашим аккаунтом. Такая схема не используется в DNSCrypt 2.
С точки зрения разработчика немного сложно работать с DNSCrypt. «DNSCrypt не особенно хорошо документирован, и не так много его реализаций», — говорит Крикет Лю из Infoblox. На самом деле мы смогли найти только единственный клиент в активной разработке — это DNSCrypt Proxy, а OpenDNS прекратил поддерживать его разработку.
Интересный выбор криптографии в DNSCrypt может напугать некоторых разработчиков. Протокол использует Curve25519 (RFC 8032), X25519 (RFC 8031) и Chacha20Poly1305 (RFC 7539). Одна реализация алгоритма X24419 в криптографических библиотеках Pyca Python помечена как «криптографически опасная», потому что с ней очень легко ошибиться в настройках. Но основной используемый криптографический алгоритм Curve25519, является «одной из самых простых эллиптических кривых для безопасного использования», — сказал Денис.
Разработчик говорит, что DNSCrypt никогда не считался стандартом IETF, потому что был создан добровольцами без корпоративной «крыши». Представление его в качестве стандарта «потребовало бы времени, а также защиты на заседаниях IETF», — сказал он. «Я не могу себе этого позволить, как и другие разработчики, которые работают над ним в свободное время. Практически все ратифицированные спецификации, связанные с DNS, фактически написаны людьми из одних и тех же нескольких компаний, из года в год. Если ваш бизнес не связан с DNS, то действительно тяжело получить право голоса».
TLS стал приоритетом для CloudFlare, когда понадобилось усилить шифрование веб-трафика для защиты от слежки
У DNS по TLS (Transport Layer Security) несколько преимуществ перед DNSCrypt. Во-первых, это предлагаемый стандарт IETF. Также он довольно просто работает по своей сути — принимает запросы стандартного формата DNS и инкапсулирует их в зашифрованный TCP-трафик. Кроме шифрования на основе TLS, это по существу то же самое, что и отправка DNS по TCP/IP вместо UDP.
Существует несколько рабочих клиентов для DNS по TLS. Самый лучший вариант, который я нашел, называется Stubby, он разработан в рамках проекта DNS Privacy Project. Stubby распространяется в составе пакета Linux, но есть также версия для MacOS (устанавливается с помощью Homebrew) и версия для Windows, хотя работа над последней ещё не завершена.
Хотя мне удалось стабильно запускать Stubby на Debian после сражения с некоторыми зависимостями, этот клиент регулярно падал в Windows 10 и имеет тенденцию зависать на MacOS. Если вы ищете хорошее руководство по установке Stubby на Linux, то лучшая найденная мной документация — это пост Фрэнка Сантосо на Reddit. Он также написал shell скрипт для установки на Raspberry Pi.
Положительный момент в том, что Stubby допускает конфигурации с использованием нескольких служб на основе DNS по TLS. Файл конфигурации на YAML позволяет настроить несколько служб IPv4 и IPv6 и включает в себя настройки для SURFNet, Quad9 и других сервисов. Однако реализация YAML, используемая Stubby, чувствительна к пробелам, поэтому будьте осторожны при добавлении новой службы (например, Cloudflare). Сначала я использовал табы — и всё поломал.
Клиенты DNS по TLS при подключении к серверу DNS осуществляют аутентификацию с помощью простой инфраструктуры открытых ключей (Simple Public Key Infrastructure, SPKI). SPKI использует локальный криптографический хэш сертификата провайдера, обычно на алгоритме SHA256. В Stubby этот хэш хранится как часть описания сервера в файле конфигурации YAML, как показано ниже:
После установления TCP-соединения клиента с сервером через порт 853 сервер представляет свой сертификат, а клиент сверяет его с хэшем. Если всё в порядке, то клиент и сервер производят рукопожатие TLS, обмениваются ключами и запускают зашифрованный сеанс связи. С этого момента данные в зашифрованной сессии следуют тем же правилам, что и в DNS по TCP.
После успешного запуска Stubby я изменил сетевые настройки сети DNS, чтобы направлять запросы на 127.0.0.1 (localhost). Сниффер Wireshark хорошо показывает этот момент переключения, когда трафик DNS становится невидимым.
Переключаемся с обычного трафика DNS на шифрование TLS
Хотя DNS по TLS может работать как DNS по TCP, но шифрование TLS немного сказывается на производительности. Запросы dig к Cloudflare через Stubby у меня выполнялись в среднем около 50 миллисекунд (у вас результат может отличаться), в то время как простые DNS-запросы к Cloudflare получают ответ менее чем за 20 мс.
Здесь тоже имеется проблема с управлением сертификатами. Если провайдер удалит сертификат и начнёт использовать новый, то в настоящее время нет чистого способа обновления данных SPKI на клиентах, кроме вырезания старого и вставки нового сертификата в файл конфигурации. Прежде чем с этим разберутся, было бы полезно использовать какую-то схему управления ключами. И поскольку сервис работает на редком порту 853, то с высокой вероятностью DNS по TLS могут заблокировать на файрволе.
Google и Cloudflare, похоже, одинаково видят будущее зашифрованного DNS
Как Cloudflare, мы считаем, что туннели иллюстрируют операцию «Арго» лучше, чем Бен Аффлек
Дабы убедиться, что проблема именно в протоколе DoH, а не в программистах Cloudflare, я испытал два других инструмента. Во-первых, прокси-сервер от Google под названием Dingo. Его написал Павел Форемски, интернет-исследователь из Института теоретической и прикладной информатики Академии наук Польши. Dingo работает только с реализацией DoH от Google, но его можно настроить на ближайшую службу Google DNS. Это хорошо, потому что без такой оптимизации Dingo сожрал всю производительность DNS. Запросы dig в среднем выполнялись более 100 миллисекунд.
Это сократило время отклика примерно на 20%, то есть примерно до того показателя, как у Argo.
А оптимальную производительность DoH неожиданно показал DNSCrypt Proxy 2. После недавнего добавления DoH Cloudflare в курируемый список публичных DNS-сервисов DNSCrypt Proxy почти всегда по умолчанию подключается к Cloudflare из-за низкой задержки этого сервера. Чтобы убедиться, я даже вручную сконфигурировал его под резолвер Cloudflare для DoH, прежде чем запустить батарею dig-запросов.
Все запросы обрабатывались менее чем за 45 миллисекунд — это быстрее, чем собственный клиент Cloudflare, причём с большим отрывом. С сервисом DoH от Google производительность оказалась похуже: запросы обрабатывались в среднем около 80 миллисекунд. Это показатель без оптимизации на ближайший DNS-сервер от Google.
Я не Бэтмен, но моя модель угроз всё равно немного сложнее, чем у большинства людей
Я профессиональный параноик. Моя модель угроз отличается от вашей, и я предпочел бы сохранить в безопасности как можно больше своих действий в онлайне. Но учитывая количество нынешних угроз приватности и безопасности из-за манипуляций с трафиком DNS, у многих людей есть веские основания использовать какую-либо форму шифрования DNS. Я с удовольствием обнаружил, что некоторые реализации всех трёх протоколов не оказывают сильно негативного влияния на скорость передачи трафика.
Другая проблема в том, что, хотя прекрасные ребята из сообщества DNSCrypt проделали большую работу, но такая приватность по-прежнему слишком сложна для обычных людей. Хотя некоторые из этих DNS-клиентов для шифрования оказалось относительно легко настроить, но ни один из них нельзя назвать гарантированно простым для нормальных пользователей. Чтобы эти услуги стали действительно полезными, их следует плотнее интегрировать в железо и софт, который покупают люди — домашние маршрутизаторы, операционные системы для персональных компьютеров и мобильных устройств.
Интернет-провайдеры наверняка постараются активнее монетизировать обычный DNS-трафик, и никуда не исчезнут государственные агентства и преступники, которые стремятся использовать его во вред пользователю. Но маловероятно, что крупные разработчики ОС стремятся надёжно защитить DNS доступным для большинства людей способом, потому что они часто заинтересованы в монетизации, как и интернет-провайдеры. Кроме того, эти разработчики могут столкнуться с сопротивлением изменениям со стороны некоторых правительств, которые хотят сохранить возможности мониторинга DNS.
Так что в ближайшее время эти протоколы останутся инструментом для тех немногих людей, кто реально заботится о конфиденциальности своих данных и готов для этого немного потрудиться. Надеюсь, сообщество вокруг DNSCrypt продолжит свою активность и продвинет ситуацию вперёд.
По сравнению с DoT, DoH централизует информацию о посещённых вами сайтах в нескольких компаниях: на сегодня это Cloudflare, обещающая избавляться от ваших данных через 24 часа, и Google, которая намерена сохранить и монетизировать все подробности всего, что вы когда-либо планировали сделать.
DNS и конфиденциальность – важные темы, поэтому давайте углубимся в детали.
Проблема с DoH
У DoT есть ещё одно преимущество – этот протокол уже реализован, и гораздо дольше, чем существует DoH, используется такими компаниями, как Cloudflare, Google, а также местными интернет-провайдерами; такое стандартное серверное ПО, как BIND, использует DoT прямо «из коробки». На ОС Android Pie (9-я версия) DNS через TLS будет использоваться по умолчанию, если выбранный сервер DNS поддерживает DoT.
Зачем переключаться на DoH, если DoT уже раскручивается? Если такие нестандартные приложения, как Firefox, будут обходить системную DNS на базе DoT, и использовать собственную систему получения доменных имён через DoH, то с точки зрения безопасности эта ситуация станет весьма сложной. Передача DNS на откуп отдельным приложениям, происходящая сейчас, кажется шагом назад. Известно ли вам, какой метод DNS использует каждое из приложений? Узнаете ли вы о том, что оно смешивает этот процесс с TCP-трафиком на 443-м порту?
Обнаружение приложений
И ещё одна вещь может быть улучшена. Было бы здорово иметь возможность определять, какое приложение выполняет тот или иной DNS-запрос. Однако не существует RFC, который мог бы в этом помочь. Но мы можем попытаться сделать это сами, попытаться создать своего рода "отпечатки пальцев DNS", по крайней мере, для популярных приложений. Если бы мы знали, какое приложение делает DNS-запрос, мы могли бы более гибко настраивать параметры блокировки.
Например, мы хотим заблокировать трекинг Facebook. Но глобальная блокировка приведёт к поломке всех приложений Facebook. Поэтому мы хотим иметь возможность блокировать его только в приложениях, не относящихся к Facebook.
Другая реальная проблема заключается в том, что блокировка AppsFlyer (системы мобильной аналитики) ломает некоторые довольно популярные приложения. Мы бы предпочли выборочно разрешить его работу — только для затронутых приложений, а в противном случае оставить его заблокированным.
Создание таких "отпечатков DNS" требует анализа сетевого поведения каждого популярного приложения, и мы работаем над решением, которое позволит это сделать.
Что такое безопасность DNS?
Узел AdGuard DNS-сервера
Безопасность DNS: вопросы и компоненты
- Усиление безопасности серверов и процедур управления: повышайте уровень защищенности серверов и создайте стандартный шаблон ввода в эксплуатацию
- Совершенствование протокола: внедрите DNSSEC, DoT или DoH
- Аналитика и отчетность: добавьте журнал событий DNS в SIEM-систему для дополнительного контекста при расследовании инцидентов
- Киберразведка и обнаружение угроз: подпишитесь на активный канал получения аналитических данных об угрозах
- Автоматизация: создайте максимально возможное количество сценариев, чтобы автоматизировать процессы
Реализации движков фильтрации DNS
Реализации движков фильтрации DNS имеют открытый исходный код и доступны на Github. Их две. Первая называется urlfilter и представляет собой библиотеку Golang, которую мы используем в AdGuard DNS и AdGuard Home. Обеспечивает относительно высокую производительность и занимает мало памяти. Вторая — AdGuard DnsLibs, это библиотека C++, которую мы используем в наших клиентских приложениях. Помимо фильтрации DNS, она также обеспечивает реализацию DNS-шифрования.
Если вы хотите защитить себя от рекламы и трекеров с помощью AdGuard DNS, просто следуйте этому руководству по настройке.
Механизмы обнаружения DNS с шифрованием
Сейчас вам нужно настраивать DNS на каждом устройстве. Не проще ли сделать это один раз непосредственно на роутере? Некоторые новые маршрутизаторы уже поддерживают DNS-шифрование. Однако многие старые устройства по-прежнему могут работать только со стандартными DNS-серверами. Существует рабочая группа "Adaptive DNS Discovery", которая стремится изменить эту ситуацию к лучшему.
Примечательные RFC-проекты:.
Сравнение DNS-фильтрации с сетевой фильтрацией
Мы называем сетевой фильтрацией "обычный" способ, которым самостоятельные приложения AdGuard (кроме браузерных расширений) фильтруют весь сетевой трафик, отсюда и название. Освежить знания о сетевой фильтрации можно, прочитав эту статью.
Во-первых, мы сразу хотим оговориться, что с AdGuard вам не нужно выбирать между ними. Вы всегда можете использовать обычную сетевую фильтрацию и DNS-фильтрацию одновременно. Однако важно понимать разницу между этими двумя подходами. DNS-фильтрация обладает как своими уникальными преимуществами, так и недостатками.
Плюсы DNS-фильтрации:
Недостатки DNS-фильтрации:
- DNS-фильтрация — "грубый" метод. Это означает, что с её помощью не получится убрать, например, белые пустые блоки, остающиеся после заблокированной рекламы. Также не получится применить никакие косметические правила. Многие виды более сложной рекламы не могут быть заблокированы на уровне DNS (точнее, могут, но только ценой полной блокировки домена, который также используется для других, полезных целей).
Пример разницы между DNS-фильтрацией и сетевой фильтрацией
- Невозможно определить источник DNS-запроса, то есть вы не сможете различать трафик разных приложений на DNS-уровне. Это помешает ведению подробной статистики и сделает невозможным создание правил, работающих только для конкретных приложений.
Мы рекомендуем использовать DNS-фильтрацию вместе с сетевой фильтрацией, а не вместо неё, если это возможно.
Что такое DNS?
DNS расшифровывается как "Domain name system", или "Система доменных имён". Её цель — переводить имена доменов, понятные человеку, в нечто, что понятно браузерам, т.е. в IP-адреса. Таким образом, каждый раз, когда вы переходите на сайт, ваш браузер посылает запрос на специальный сервер (DNS-сервер). Этот сервер смотрит на имя запрашиваемого домена и отвечает соответствующим IP-адресом. Очень схематично это выглядит так:
Всё то же самое применимо, разумеется, и к приложениям и программам, которые посылают какие-либо веб-запросы, а не только к браузерам.
Шифрование не препятствует слежке
Кроме DoH, они упоминают стандарт QNAME minimization (RFC 7816), который должен уменьшить количество некритичной информации, отправляемой DNS-сервером. При этом этот стандарт никак не зависит от DoH и будет работать без всякого шифрования DNS. Как в случае с DNSSEC, безопасность и конфиденциальность улучшаются через эволюцию стандарта DNS.
Использование DNS для блокировки контента: за и против
DNS-блокировка контента имеет как преимущества, так и очевидные недостатки. Давайте начнем с положительных сторон использования DNS для блокировки контента.
Минусы
- Невозможно работать с рекламой от первого лица. Например, вы не сможете заблокировать видеорекламу на YouTube, потому что она размещается на том же домене, что и обычные видео.
- Нет косметической фильтрации. При использовании только блокировки по DNS вы не будете видеть большинство рекламных объявлений, но у вас будут довольно уродливые веб-страницы со сломанными фреймами и пустыми рекламными блоками.
- Более высокая вероятность поломки. Например, некоторые приложения или веб-сайты могут быть сломаны из-за блокировки Google Analytics, и вы ничего не сможете с этим сделать.
- Легче обойти. Приложение может просто использовать другой 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 настоящие.
Что такое AdGuard DNS
Если вы хотите получить доступ к "лучшему интернету", вам обязательно нужно в сочетании с VPN и блокировщиком рекламы использовать DNS. И мы предлагаем вам присмотреться к AdGuard DNS.
Что же представляет собой AdGuard DNS? Это DNS-сервис, который заботится о сохранении вашей конфиденциальности и обеспечении безопасности в интернете. Он поддерживает такие надежные протоколы шифрования, как DNS-over-HTTPS, DNS-over-TLS и DNS-over-QUIC. Он может определять запросы к рекламным, отслеживающим и/или доменам со "взрослым" контентом (опционально) и возвращать им пустой ответ. AdGuard имеет собственную базу доменных имен, обслуживающих рекламу, трекеры и мошеннические активности, и она регулярно обновляется. Кроме того, мы обеспечиваем полезную возможность добавлять в блоклисты свои пользовательские правила.
Чтобы дать вам более широкое представление о том, что такое AdGuard DNS, я упомяну ещё несколько моментов:
- Он состоит из нескольких серверов, расположенных в 14 локациях.
- Все эти серверы "анонсируют" одни и те же IP-адреса через BGP (Border Gateway Protocol).
- Его текущая нагрузка составляет около трёхсот тысяч DNS-запросов в секунду.
- AdGuard DNS написан на языке Golang.
- Около 75% DNS-трафика шифруется. Именно это отличает DNS-серверы, блокирующие контент, от других. Если вы посмотрите на статистику CloudFlare или Quad9, то увидите, что зашифрованный DNS-трафик составляет лишь небольшую долю всех запросов. Для AdGuard DNS всё совсем иначе, большая часть трафика шифруется.
В понятие безопасности DNS входят две важные составляющие:
- Обеспечение общей целостности и доступности служб DNS, преобразовывающих имена сетевых узлов в IP-адреса
- Мониторинг активности DNS для определения возможных проблем безопасности где-либо в вашей сети
Станет ли будущий интернет единой точкой отказа?
Mozilla предлагает справляться с проблемой отслеживания IP просто заявляя, что это не проблема благодаря использованию Облака. Чем больше веб-сайтов и сетей распространения контента (CDN) навесят на небольшое количество сервисов (Cloudflare, Azure, AWS, и т.п.), тем меньше будет значить этот единственный IP-адрес – нужно будет просто верить в то, что выбранный вами облачный сервис не будет воровать ваши данные и не упадёт на сутки.
В этом году 24 июня было массивное падение сервисов, когда ошибка в настройках, сделанная провайдером Verizon, привела к тому, что Cloudflare, Amazon, Linode и многие другие большую часть дня были недоступны. 2 июля этого года примерно на полчаса упал Cloudflare, а вместе с ним и многие веб-сайты, полагающиеся на его услуги.
По совпадению, облачный сервис Office365 от Microsoft тоже лежал в тот день несколько часов, из-за чего многие пользователи не смогли воспользоваться его услугами. В выходные перед днём труда [национальный праздник в США, отмечаемый в первый понедельник сентября / прим. перев.] отключение напряжения в дата-центре AWS US-East-1 привело к тому, что терабайт хранившихся там данных клиентов накрылся медным тазом. Очевидно, в идее о благе централизации интернета есть ещё какие-то недостатки.
Атаки на DNS
- подмена DNS или «отравление» кэша: использование уязвимости системы для управления кэшем DNS с целью перенаправления пользователей в другое место
- DNS-туннелирование: в основном используется для обхода средств защиты от удаленных подключений
- перехват DNS: перенаправление обычного трафика DNS на другой целевой DNS-сервер путем изменения регистратора домена
- атака NXDOMAIN: проведение DDoS-атаки на авторитетный сервер DNS путем отправки неправомерных доменных запросов для получения принудительного ответа
- фантомный домен: заставляет DNS-преобразователь (DNS resolver) ждать ответа от несуществующих доменов, что приводит к снижению производительности
- атака на случайный субдомен: взломанные хосты и ботнеты проводят DDoS-атаку на действующий домен, но сосредотачивают огонь на ложных субдоменах, чтобы принудить DNS-сервер выполнять поиск записей и захватить управление над службой
- блокировка домена: представляет собой отправку множества спам-откликов для блокировки ресурсов DNS-сервера
- ботнет-атака с абонентского оборудования: совокупность компьютеров, модемов, роутеров и других устройств, концентрирующих вычислительную мощность на определенном веб-сайте для его перегрузки запросами трафика
Почему DNS уязвима для атак?
Технология DNS была создана на заре развития интернета, задолго до того, как кто-либо вообще начал думать о сетевой безопасности. DNS работает без аутентификации и шифрования, вслепую обрабатывая запросы любого пользователя.
В связи с этим существует множество способов обмануть пользователя и подделать информацию о том, где на самом деле осуществляется преобразование имен в IP-адреса.
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?
DNSSEC — модули безопасности службы доменных имен — используются для проверки записей DNS без необходимости знать общую информацию по каждому конкретному DNS-запросу.
DNSSEC использует ключи цифровой подписи (PKI) для подтверждения того, получены ли результаты запроса доменного имени из допустимого источника.
Внедрение DNSSEC является не только лучшей отраслевой практикой, но также эффективно помогает избежать большинство атак на DNS.
Принцип работы DNSSEC
- Записи DNS подписываются парой закрытого и закрытого ключей
- Ответы на запросы DNSSEC содержат запрошенную запись, а также подпись и открытый ключ
- Затем открытый ключ используется для сравнения подлинности записи и подписи
Что такое блокировка на уровне DNS
Чтобы освежить ваши знания: аббревиатура DNS расшифровывается как Domain Name System, т.е. «система доменных имен». DNS — своего рода «адресная книга» интернета, цель которой состоит в переводе имён веб-сайтов в нечто понятное браузерам, то есть в IP-адреса. Таким образом, каждый раз, когда вы заходите на веб-сайт, ваш браузер отправляет запрос на DNS-сервер (который обычно предоставляется вашим интернет-провайдером), чтобы определить IP-адрес веб-сайта. В ответ обычный DNS-резолвер просто возвращает IP-адрес запрошенного домена.
Ваше устройство всегда использует какой-либо DNS-сервер для получения IP-адреса доменного имени, к которому обращается приложение.
К счастью для нас с вами, существуют DNS-серверы, обеспечивающие фильтрацию трафика и блокировку контента. Обычно это делается с помощью техники «DNS Sinkholing», суть которой заключается в выдаче немаршрутизируемых адресов для заблокированных доменов. Когда ваше устройство отправляет «плохой» запрос, будь то реклама или трекер, DNS-сервер отвечает IP-адресом 0.0.0.0 для заблокированного домена. Получается, что приложение просто не может подключиться к этому адресу, и мы получаем желаемый результат — заблокированое подключение.
Пример использования DNS-сервера для блокировки доступа к домену
DNS-сервер также может вернуть такие ответы: NXDOMAIN (означает, что домен не существует) или REFUSED (означает, что сервер отказался обрабатывать запрос). Вы скорее всего не заметите разницы между ними, но некоторые старые устройства могут неверно интерпретировать REFUSED и попытаться использовать резервный DNS-сервер.
Что можно улучшить
В настоящее время, если домен заблокирован на уровне DNS, вы просто видите уродливую страницу ошибки. Это негативно сказывается на пользовательском опыте. Например, при желании человек не сможет временно разблокировать домен, ведь способа сделать это просто нет.
Взгляд в будущее
Браузерные блокировщики контента можно назвать самыми популярными среди обычных пользователей, но не среди составителей блоклистов. Существует гораздо больше HOSTS-файлов и списков доменов, которые поддерживаются добровольцами, чем списков фильтров для браузерных блокировщиков. Это говорит о том, что у блокировки на уровне DNS большие перспективы.
Что ещё можно сказать о будущем этой технологии? Во-первых, рост DNS-блокировки контента ускорится. В Windows 11 появилась поддержка шифрования DNS, новые роутеры также поддерживают шифрование DNS, всё это облегчит пользователям его настройку и использование.
Уровень обхода блокировки DNS-контента будет расти, но он всё ещё будет незначительным. Чтобы обойти её, требуется много усилий с разных сторон, и чтобы это начало происходить, DNS-блокировка контента должна стать такой же популярной, как и браузерная блокировка. А этого, вероятно, не произойдет, несмотря на темпы роста.
DNS не заменит браузерные блокировщики по очевидным причинам. Но, тем не менее, DNS-блокировка останется и займёт достойное место в системе обеспечения конфиденциальности и безопасности пользователей в интернете.
Чем бы ни занималась компания, безопасность DNS должна являться неотъемлемой частью ее плана по обеспечению безопасности. Службы обработки имен, преобразовывающие имена сетевых узлов в IP-адреса, используются буквально всеми приложениями и службами в сети.
Новая жизнь для DNS-блокировщиков
До роста популярности DNS-шифрования доступные варианты были слишком сложными для обычного пользователя. Можно было:
- Использовать файл HOSTS и каким-то образом получать его обновления.
- Использовать обычный DNS-сервер и смириться с ограничениями, такими как невозможность настроить его на телефоне для мобильной сети или необходимость настраивать каждый сетевой адаптер на десктопе и погружаться для этого в довольно низкоуровневые настройки.
- Использовать VPN или локальный VPN.
После того как DNS-шифрование стало общепринятым, некоторые технические препятствия просто исчезли. Теперь настроить DNS-сервер стало намного проще, и его можно использовать в любой сети. Конечно, вам всё ещё нужно погружаться в настройки устройства, но не так глубоко, как раньше. Кроме того, DNS-шифрование нативно поддерживается на Android 9+ (DoT, DoH на подходе), iOS 14+ и macOS 15+ (DoT, DoH), Windows 11 (правда, поддержка довольно ограничена). Всё это дало огромный толчок росту популярности DNS-блокировки.
Кроме того, развитие DNS-шифрования позволило публичным DNS-серверам предоставлять пользователям возможности настройки. Другими словами, каждый получил возможность выбирать, что блокировать, а что нет. Ранее применение пользовательских правил на основе доменного имени DNS-сервера было возможно только путём "привязки" IP-адреса пользователя, что точно не было хорошим решением.
Атаки на DNS
- Подмена DNS или «отравление» кэша
- Перехват DNS
DoT — DNS поверх TLS
Transport Layer Security (безопасность на транспортном уровне, TLS) — это криптографический протокол для защиты передаваемой информации по сетевому соединению. Как только между клиентом и сервером установлено безопасное соединение TLS, передаваемые данные шифруются и никакие посредники не смогут их увидеть.
Источник: University of California Irvine
Стандартные DNS-запросы передаются через UDP. Запросы и ответы можно отслеживать с помощью таких инструментов, как Wireshark. DoT шифрует эти запросы, но они по-прежнему идентифицируются как довольно отчетливый трафик UDP в сети.
- DNS-фильтрация — это распространенный способ фильтрации веб-трафика для защиты пользователей от фишинговых атак, сайтов, распространяющих вредоносные программы, или другой потенциально опасной интернет-активности в корпоративной сети. Протокол DoH обходит эти фильтры, потенциально подвергая пользователей и сеть более высокому риску.
- В текущей модели преобразования имен каждое устройство в сети в той или иной степени получает DNS-запросы из одного и того же места (из указанного DNS-сервера). DoH и, в частности, его реализация от Firefox показывают, что в будущем это может измениться. Каждое приложение на компьютере может получать данные из разных источников DNS, что значительно усложняет поиск и устранение проблем, обеспечение безопасности и моделирование рисков.
Безопасность DNS и DNSSEC
DNSSEC — это средство для проверки целостности DNS-запросов. Оно не влияет на конфиденциальность DNS. Иными словами, DNSSEC может дать вам уверенность в том, что ответ на ваш DNS-запрос не подделан, но любой злоумышленник может увидеть эти результаты в том виде, в каком они были переданы вам.
Синтаксис правил фильтрации DNS
Блоклисты AdGuard DNS составляются с использованием специального "синтаксиса фильтрации DNS". Нас не устраивали ограничения блоклистов типа HOSTS-файлов, поэтому для AdGuard DNS мы использовали знакомый синтаксис в стиле блокировщика рекламы. Затем он был постепенно расширен модификаторами, специфичными для DNS.
Примеры правил фильтрации DNS. Полная спецификация доступна на Github
Просто чтобы продемонстрировать разницу. Слева приведена статистика для DNS-фильтра AdGuard (тот, который мы используем по умолчанию). Он относительно короткий, но на самом деле блокирует около 900 000 доменов. А слева мы видим другой блоклист — Energized Ultimate, который представляет собой HOSTS-файл с 500 000 доменов. И вот что он блокирует — 500 000 доменов.
Статистика по данным AdGuard DNS
Старые песни по-новому
Потрясающе, что во всей этой дискуссии по поводу конфиденциальности и отслеживания нет никаких упоминаний виртуальных частных сетей (VPN). Они решают проблемы с шифрованием данных и DNS-запросами, с сокрытием IP-адреса и прочим, просто перемещая точку, в которой ваш ПК или другое выходящее в интернет устройство соединяется с интернетом. Диссиденты внутри авторитарных режимов десятилетиями использовали VPN для обхода интернет-цензуры; VPN, включая такие его специальные виды, как Tor, являются критически важным элементом свободы в интернете.
Как работает Tor
Если вы доверяете большой коммерческой компании вроде Cloudflare в такой схеме, как DoH, то найти доверенного VPN-провайдера, не хранящего и не продающего ваши данные, будет легко. А в браузере Opera вообще есть бесплатная встроенная поддержка proxy, предлагающая множество преимуществ VPN.
В итоге можно сказать, что DoH подтверждает свой акроним, плохо делая то, что уже хорошо удаётся DoT [«Doh!» – восклицание, указывающее на глупость совершённого действия, особенно собственного / прим. перев.]. Нужно больше концентрироваться на повсеместном внедрении DNSSEC, совместно с DoT и минимизацией QNAME. А если вас заботит реальная конфиденциальность, то вам нужно обратиться к VPN.
Чтобы лучше понимать DNS-фильтрацию, надо сначала ответить на вопрос "Что такое DNS"?
Атаки с использованием DNS
- Fast-Flux
- Одиночные сети Flux
- Двойные сети Flux
Плюсы
- Не требует установки дополнительного программного обеспечения.
- Не зависит от производителя браузера или ОС.
- Не влияет на производительность.
- Запуск публичного DNS-сервера позволяет наблюдать за всем интернетом. Это очень полезно, если вы ведёте список сайтов для блокировки. Вы можете избавиться от неиспользуемых правил и оперативно узнавать о новых угрозах. У DNS нет "слепых зон", поскольку он наблюдает за всеми устройствами, а не только за браузерами.
- Централизованное решение лучше справляется с некоторыми проблемами.
Например, давайте рассмотрим маскировку CNAME — тактику, которую использовали некоторые трекеры, чтобы скрыться от блокировщиков. С помощью DNS-записи CNAME они скрывали настоящее доменное имя третьей стороны, маскируя его под домен первой стороны. С помощью AdGuard DNS мы смогли обнаружить все эти замаскированные домены и опубликовать их список, чтобы даже блокировщики контента, не имеющие доступа к DNS, могли остановить это.
Другой пример — использование прокси для маскировки трекеров. В принципе, возможно использовать CloudFlare или CloudFront для настройки безсерверного прокси, который будет скрывать оригинальный домен третьей стороны. DNS в целом не поможет в этом случае, но он может стать хорошей отправной точкой для обнаружения таких прокси.
Читайте также: