Войти
Перехват DNS, Отравление DNS или Перенаправление DNS это практика подрыва разрешения запросов системы доменных имен (DNS). Этого можно достичь с помощью вредоносного ПО, которое переопределяет конфигурацию TCP / IP компьютера, чтобы указать на мошеннический DNS-сервер, находящийся под контролем злоумышленника, или путем изменения поведения доверенного DNS-сервера, чтобы он не соответствовал требованиям. со стандартами Интернета.
Эти изменения могут быть внесены в злонамеренных целях, таких как фишинг, в личных целях интернет-провайдерами (ISP), Great Firewall Китая и общедоступных / базирующихся на маршрутизаторах онлайн-провайдеров DNS-серверов для направления веб-трафика пользователей на собственные веб-серверы провайдера, где может быть размещена реклама, собрана статистика или другие цели провайдера; и поставщиками услуг DNS для блокировки доступа к выбранным доменам в виде цензуры.
Одна из функций DNS-сервера - преобразовать доменное имя в IP-адрес, который приложениям необходимо подключать к Интернет-ресурсам, таким как веб-сайт. Эта функциональность определена в различных формальных Интернет-стандартах, которые подробно определяют протокол. Компьютеры и пользователи, подключенные к Интернету, неявно доверяют DNS-серверам правильное преобразование имен в фактические адреса, зарегистрированные владельцами Интернет-домена.
Неверный DNS-сервер переводит доменные имена желаемых веб-сайтов (поисковые системы, банки, брокеры и т. Д.) В IP-адреса сайтов с нежелательным содержанием, даже вредоносных сайтов. Большинство пользователей зависят от DNS-серверов, автоматически назначаемых их интернет-провайдерами. Компьютеры-зомби используют DNS-изменяющие трояны, чтобы незаметно переключать автоматическое назначение DNS-сервера провайдером на ручное назначение DNS-сервера с поддельных DNS-серверов. Назначенные маршрутизатору DNS-серверы также могут быть изменены путем удаленного использования уязвимости во встроенном ПО маршрутизатора. Когда пользователи пытаются посетить веб-сайты, они вместо этого попадают на поддельный веб-сайт. Эта атака называется фарминг. Если сайт, на который они перенаправляются, является вредоносным веб-сайтом, маскирующимся под законный веб-сайт, с целью получения конфиденциальной информации обманным путем, это называется фишинг.
Ряд интернет-провайдеров-потребителей например, ATT, Cablevision Optimum Online, CenturyLink, Cox Communications, RCN, Rogers, Charter Communications (Spectrum), Plusnet, Verizon, Sprint, T-Mobile US, Virgin Media, Frontier Communications, Bell Sympatico, Deutsche Telekom AG, Optus, Mediacom, ONO, TalkTalk, Bigpond (Telstra ), TTNET, Türksat и Telkom Indonesia использовали или использовали перехват DNS в своих целях, например, для показа рекламы или сбора статистики. Голландские интернет-провайдеры XS4ALL и Ziggo используют перехват DNS по решению суда: им было приказано заблокировать доступ к The Pirate Bay и вместо этого отобразить страницу с предупреждением. Эти методы нарушают стандарт RFC для ответов DNS (NXDOMAIN) и потенциально могут открыть пользователям межсайтовый скриптинг атак.
Проблема с захватом DNS связана с этим захват ответа NXDOMAIN. Приложения Интернета и интрасети полагаются на ответ NXDOMAIN для описания условия, при котором DNS не имеет записи для указанного хоста. Если нужно было запросить недопустимое доменное имя (например, www.example.invalid), он должен получить ответ NXDOMAIN, информирующий приложение о том, что имя недействительно, и выполнение соответствующих действий (например, отображение ошибки или отсутствие попытки подключиться к серверу). Однако, если доменное имя запрашивается у одного из этих несовместимых интернет-провайдеров, всегда будет получен поддельный IP-адрес, принадлежащий интернет-провайдеру. В веб-браузере такое поведение может раздражать или оскорблять, поскольку при подключении к этому IP-адресу вместо правильного сообщения об ошибке отображается страница перенаправления ISP поставщика, иногда с рекламой. Однако другие приложения, которые полагаются на ошибку NXDOMAIN, вместо этого будут пытаться инициировать подключения к этому поддельному IP-адресу, потенциально раскрывая конфиденциальную информацию.
Примеры функциональности, которая нарушается, когда интернет-провайдер перехватывает DNS:
В некоторых, но не в большинстве случаев, интернет-провайдеры предоставляют настраиваемые абонентом настройки для отключения перехвата ответов NXDOMAIN. При правильной реализации такая настройка возвращает DNS к стандартному поведению. Однако другие интернет-провайдеры вместо этого используют веб-браузер cookie для сохранения предпочтений. В этом случае основное поведение не решается: запросы DNS продолжают перенаправляться, а страница перенаправления поставщика услуг Интернета заменяется поддельной страницей ошибок DNS. Приложения, отличные от веб-браузеров, не могут быть исключены из схемы с использованием файлов cookie, поскольку отказ нацелен только на протокол HTTP, когда схема фактически реализована в системе DNS, не зависящей от протокола.
Управление комиссара по информации Великобритании признало, что практика принудительного перехвата DNS противоречит PECR и Директиве ЕС 95/46 о защите данных, которые требуют явное согласие на обработку коммуникационного трафика. Однако они отказались вмешиваться, утверждая, что было бы неразумно применять закон, потому что это не нанесло бы значительного (или даже какого-либо) очевидного ущерба для людей. В Германии в 2019 году было обнаружено, что Deutsche Telekom AG не только манипулировала своими DNS-серверами, но также передавала сетевой трафик (например, незащищенные файлы cookie, когда пользователи не использовали HTTPS ) сторонней компании. потому что веб-портал T-Online, на который пользователи были перенаправлены из-за манипуляций с DNS, не принадлежал (больше) Deutsche Telekom. После того, как пользователь подал уголовное дело, Deutsche Telekom прекратил дальнейшие манипуляции с DNS.
ICANN, международный орган, отвечающий за администрирование доменных имен верхнего уровня, опубликовал меморандум, в котором подчеркивается его озабоченность и подтверждается: ICANN настоятельно не рекомендует использовать перенаправление DNS, подстановочные знаки, синтезированные ответы и любые другие формы подстановки NXDOMAIN в существующих gTLD, ccTLD и на любом другом уровне в дереве DNS для доменных имен класса реестра.
Конечные пользователи, недовольные плохими вариантами отказа, такими как файлы cookie, ответили на спор, найдя способы избежать поддельных ответов NXDOMAIN. Программное обеспечение DNS, такое как BIND и Dnsmasq, предлагает опции для фильтрации результатов и может запускаться со шлюза или маршрутизатора для защиты всей сети. Google, среди прочего, запускает открытые DNS-серверы, которые в настоящее время не возвращают поддельные результаты. Таким образом, пользователь может использовать Google Public DNS вместо DNS-серверов своего интернет-провайдера, если они готовы согласиться с тем, что они используют службу в соответствии с политикой конфиденциальности Google и, возможно, будут подвергнуты другому методу, с помощью которого Google может отслеживать пользователя. Одним из ограничений этого подхода является то, что некоторые провайдеры блокируют или перезаписывают внешние DNS-запросы. OpenDNS, принадлежащий Cisco, представляет собой аналогичный популярный сервис, который не изменяет ответы NXDOMAIN.
Google в апреле 2016 года запустил службу DNS-over-HTTPS. Эта схема может преодолеть ограничения устаревшего протокола DNS. Он выполняет удаленную проверку DNSSEC и передает результаты в безопасный туннель HTTPS.
Существуют также обходные пути на уровне приложений, такие как NoRedirect расширение Firefox, которые смягчают некоторые проявления поведения. Такой подход исправляет только одно приложение (в данном примере Firefox) и не решает никаких других проблем. Владельцы веб-сайтов могут обмануть некоторых злоумышленников, используя определенные настройки DNS. Например, установка TXT-записи "неиспользованный" на их адрес с подстановочными знаками (например, *.example.com). В качестве альтернативы они могут попытаться установить CNAME подстановочного знака на «example.invalid», используя тот факт, что «.invalid» гарантированно не существует согласно RFC. Ограничение этого подхода состоит в том, что он предотвращает захват только этих конкретных доменов, но может решить некоторые проблемы безопасности VPN, вызванные перехватом DNS.
