Как провайдеры блокируют доступ к сайтам

Как известно, в России, Китае и некоторых других странах повально закрывают доступ к множеству сайтов, легальных и не очень, безопасных и не очень. РКН не держит базу в открытом доступе, а вместо этого он предлагает провайдерам использовать цифровую подпись для доступа к базе. РКН рекомендует провайдерам обновлять базу раз в час. Эта база содержит список доменных имен, IP адресов и сетей, которые должны быть заблокированы.

Провайдер, в свою очередь, скачав базу, должен перенаправлять запросы к указанных ресурсам на страницу о блокировке. Кроме того, провайдеров обязали установить программно-аппаратный комплекс «Ревизор» разработки «МФИ Софт», который автоматически проверяет доступ к запрещенным сайтам из сети провайдера. Кстати, решение было создано на базе беспроводного маршрутизатора компании TP-Link :)

В итоге при обращении по определенному доменному имени или IP правила на сетевом оборудовании провайдера резолвили (разрешали) адрес заблокированного сайта в IP сервера, где находится страница с информацией о блокировке, которая пользователем и показывалась вместо ожидаемого сайта.

Но этим все не заканчивается. Конечно же, продвинутые пользователи сразу начали обходить такую блокировку просто прописав сторонние DNS, например от Google (8.8.8.8). Но счастье продлилось недолго.

Современные методы блокировки

Как известно, протокол DNS не шифрует запросы и данные передаются в открытом виде. Для обращения к DNS в большинстве случаев не применяются технологии аутентификации (DNSSEC) и шифрования (DNS over TLS/HTTPS), что позволяет провайдерам легко перехватывать и перенаправлять на свои сервера DNS-запросы к публичным DNS-серверам, таким как 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), OpenDNS, Dyn DNS и Edu DNS.

Основными мотивами перенаправления обычно является желание сэкономить трафик, снизить время отклика, обеспечить дополнительную защиту или реализовать блокировку запрещённых ресурсов. Если пользователь пытается перейти на несуществующий сайт, то провайдер перенаправляет его на свою страницу с рекламой. А может и не на свою. В наибольшей степени перехват обращений к DNS пользуются в Китае, на втором месте Россия, на третьем — США.

Кстати, перехват DNS запросов (DNS hijacking) может использоваться и троянами для вредоносных целей. В 2007 году группа предприимчивых людей из Эстонии создала троян DNSChanger, который за несколько лет заразил 4 млн компьютеров по всему миру. Троян изменял системные настройки DNS, что приводило к появлению рекламы на веб-страницах. Также подвержены этой уязвимости и домашние модемы и роутеры (при условии, что проникнув в них, будут прописаны подставные DNS сервера).

Из методов перехвата трафика наиболее популярными являются перенаправление запросов и реплицирование ответа (оригинальный запрос и ответ не блокируются, но провайдер также направляет свой подставной ответ, который обычно приходит раньше и воспринимается клиентом). Наиболее часто перехватываемым публичным DNS-сервером стал сервис Google (8.8.8.8).

Как бороться с перехватом DNS

Собственно, методов защиты от перехвата два: или шифровать весь трафик, пустив его через VPN туннель или же только DNS трафик. Для шифрования DNS-трафика были реализованы специальные протоколы DNS over TLS (DNS поверх TLS, DoT, RFC7858) и DNS over HTTPS (DNS поверх HTTPS, DoH, RFC8484). Шифрование гарантирует, что трафик не просканируют и не изменят, и что запросы не получит и не обработает поддельный DNS-сервер. Это защищает от атак MiTM и шпионажа.

Также для компаний разумно рассмотреть вариант проксирования DNS трафика. DNS-прокси с одной из этих служб (непосредственно на сетевом устройстве или на сервере в локальной сети) поможет предотвратить DNS-утечки через VPN, поскольку прокси-сервер всегда будет самым быстрым DNS-сервером среди всех доступных.

DNS сервис от CloudFlare (1.1.1.1) использует DNS over TLS с самого начала открытия. А Google DNS начал использовать его только недавно, приблизительно в октябре 2018 года. До этого они поддерживали только DNS-over-HTTPS (DoH). Также сосуществует протокол шифрования и проксирования запросов DNSCrypt, который больше поддерживается частными DNS серверами и сообществами, чем крупнейшими DNS провайдерами.

[stextbox id=’info’]

Список публичных DNS-сервисов с поддержкой DoT/DoH вы можете найти на:

[/stextbox]

Для пользователей подключить DNS-шифрование не так просто, как изменить адрес в настройках сети. В настоящее время ни одна ОС напрямую не поддерживает шифрование DNS без дополнительного программного обеспечения. И не все сервисы одинаковы с точки зрения софта и производительности.

Диспозиции сейчас такие:

DNSCrypt поддерживает сообщество и некоторые вендоры, среди прочих, его поддерживает OpenDNS от Cisco
DNS по TLS поддерживается Сloudflare, Google, Quad9, OpenDNS
DNS по HTTPS поддерживается Сloudflare, Google и сервисом блокировки «взрослого» контента CleanBrowsing.

DNS через TLS поддерживается основными поставщиками DNS, что не относится к DNSCrypt. Однако, последняя предоставляет удобную утилиту для Windows, плюс этот протокол поддерживается Яндекс. Поэтому с него и начнем.

DNSCrypt

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

Сообщество DNSCrypt создало простые в использовании клиенты, такие как Simple DNSCrypt для Windows и клиент для Apple iOS под названием DNS Cloak, что делает шифрование DNS доступнее для нетехнических людей. Другие активисты подняли независимую сеть приватных DNS-серверов на основе протокола, помогающего пользователям уклониться от использования корпоративных DNS-систем.

Для тех, кто хочет запустить DNS-сервер с поддержкой DNSCrypt для всей своей сети, лучшим клиентом будет DNSCrypt Proxy 2. По умолчанию прокси-сервер использует открытый DNS-резолвер Quad9 для поиска и получения с GitHub курируемого списка открытых DNS-сервисов. Затем подключается к серверу с самым быстрым откликом. При необходимости можно изменить конфигурацию и выбрать конкретный сервис.

Основное преимущество DNSCrypt в том, что он передаёт UDP-трафик по порту 443 — тот же порт используется для безопасных веб-соединений. Это даёт относительно быстрый резолвинг адресов и снижает вероятность блокировки на файрволе провайдера.

Кроме того нативная поддержка DNSCrypt реализована в Яндекс.Браузере. При этом все запросы в зашифрованном виде будут отправляться на быстрый DNS-сервер Яндекса, который также получил поддержку протокола DNSCrypt. Правда, по умолчанию эта настройка в браузере отключена.

DNS over TLS против DNS over HTTPS

Сравним два эти протокола:

	DNS over TLS	DNS over HTTPS
Плюсы	Полное шифрование протокола DNS Имеет низкое, но все большее число серверов в развертывании Много реализаций, выполненные на разных этапах Предоставляет больше информации, чем обычный DNS для операторов-резольверов	Полное шифрование протокола DNS Использует стандартный HTTP/2, стандартный порт (443) Меньше вероятность блокировки Может быть тривиально развернут на любом веб-сервере и работать по существующим веб-сайтам; Ответ DNS обрабатывается как простые веб-страницы Может совместно использовать ту же инфраструктуру, что и существующие веб-сайты, и использовать одни и те же сертификаты Простая реализация поверх любого существующего веб-стека Совместим с кеширующим прокси и CDN Позволяет веб-браузерам выполнять DNS-запросы с помощью Javascript Уже реализован Google DNS (хотя и не последний проект) Доступно в Firefox Ведется работа по использованию DoH и CDN для повышения производительности веб-приложений.
Минусы	Использует выделенный порт (853), который может быть заблокирован или контролироваться в ситуациях, когда шифрование DNS полезно Первоначальное соединение происходит медленно из-за длинного рукопожатия (до тех пор, пока не будет развернуто TLS 1.3) Требуется полный стек TLS, представляющий большую поверхность атаки Трудно реализовать безопасно. Проверка сертификатов TLS в не-браузерном программном обеспечении Легко совместим с отраслевыми стандартными устройства перехвата / контроля TLS. Требуется TCP Требуется отслеживание сеансов на сервере Сомнительные практические преимущества перед DoH	Предоставляет больше информации, чем обычный DNS Требуется полный стек TLS и веб-сервер Инструменты перехвата / мониторинга доступны Позволяет использовать небезопасные алгоритмы и параметры Требуется TCP

Как работает DNS over TLS

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

Для реализации DNS-over-TLS предлагается клиент Stubby для Windows, MacOS и Ubuntu.

Также из хороших новостей в Android 9 поддержка DNS-over-TLS встроена в системный DNS резолвер. В частности, в моем Huawei P20 эта настройка находится в Настройки — Беспроводные сети — Частный DNS. По умолчанию, там стоит Авто.

Например, для того, чтобы настроить телефон на использование DNS сервиса CloudFlare, вам нужно туда прописать в качестве адреса DNS сервера:

1dot1dot1dot1.cloudflare-dns.com

Инструкция с картинкой доступна на официальном сайте.

Также есть хорошая новость для владельцев роутеров Zyxel Keenetic. Начиная с версии KeeneticOS 3.00 была добавлена поддержка протоколов DNS over TLS и DNS over HTTPS. Включив один из них, DNS-трафик от роутера будет передаваться в зашифрованном виде через Интернет.

Если вы хотите пользоваться только DNS over TLS, то достаточно будет удалить компонент «DNS-over-HTTPS proxy». Аналогично и с DNS over HTTPS, нужно удалить компонент «DNS-over-TLS». Пример настройки для CloudFlare приведен в базе знаний Zyxel.

[Посещений: 1 475, из них сегодня: 1]