Википедия

DNS hijacking

Перехват DNS — подрыв разрешения DNS-запросов. Это может быть достигнуто с помощью вредоносных программ, которые перекрывают TCP/IP-конфигурации компьютера, чтобы запросы отправлялись на DNS-сервер злоумышленника, либо через изменение поведения доверенного DNS-сервера так, чтобы оно не соответствовало стандартам Интернета. Эти изменения могут быть сделаны в злонамеренных целях, таких как фишинг, или в корыстных целях Интернет-провайдерами (ISP), направляющими веб-трафик пользователя на собственные веб-серверы для показа рекламы, сбора статистики или других целей провайдера; и поставщиками услуг DNS для блокирования доступа к выбранным доменам как форма цензуры.

Техническое отступление править

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

Серверы-мошенники DNS править

Сервер-мошенник DNS переводит доменные имена запрашиваемых веб-сайтов (поисковых систем, банков и т. д.) в IP-адреса сайтов с непредсказуемым содержимым, даже вредоносных веб-сайтов. Большинству пользователей DNS-серверы назначаются автоматически их провайдерами. Компьютеры-зомби запускают трояны, незаметно изменяющие адрес автоматически присвоенного провайдером DNS-сервера на DNS-сервер мошенника. Когда пользователи пытаются посетить веб-сайты, они попадают на поддельный сайт. Такая атака называется фарминг. Если вредоносный сайт, на который перенаправляются запросы, маскируясь под легальный веб-сайт, пытается обманным путём получить доступ к конфиденциальной информации, то это называется фишингом.

Манипуляции провайдеров править

Некоторые провайдеры, такие как OpenDNS, Cablevision’s Optimum Online, Comcast, Time Warner, Cox Communications, RCN, Rogers, Charter Communications, Verizon, Virgin Media, Frontier Communications, Bell Sympatico, UPC, T-Online, Optus, Mediacom, ONO, TalkTalk и Bigpond (Telstra) используют перенаправление DNS в своих целях, например для отображения рекламы или сбора статистики. Это нарушает RFC-стандарты для DNS (NXDOMAIN)-ответов и может открыть пользователям возможность межсайтового скриптинга. Перенаправление DNS включает изменение ответа NXDOMAIN. Интернет- и интранет-приложения полагаются на ответ NXDOMAIN для описания состояния, когда DNS не имеет записи для указанного узла. Если мы запросили несуществующее доменное имя (fakeexample.com), в ответ мы должны получить NXDOMAIN-ответ, информирующий приложение о том, что имя недопустимо и вызывающий соответствующие меры (например, отображение ошибки или отказ от подключения к серверу). Так, если доменное имя запрашивается на одном из этих несуществующих провайдерах, можно получать поддельный IP-адрес, принадлежащий провайдеру. В веб-браузере такое поведение может быть раздражающим или оскорбительным, когда соединения с этим IP-адресом отображают провайдерскую страницу перенаправления, иногда с рекламой, вместо надлежащего сообщения об ошибке. Однако, другие приложения, полагающиеся на ошибку NXDOMAIN, будут вместо этого пытаться инициировать соединение с этим поддельным IP-адресом, потенциально подвергая риску конфиденциальную информацию.

Примеры функциональности, которая пропадает, если провайдеры перенаправляют DNS:

  • Маршрутизируемые ноутбуки, являющиеся членами домена Windows Server, ложно предполагают, что они вернулись в корпоративную сеть, потому что ресурсы, такие как контроллеры домена, серверы электронной почты и другие объекты инфраструктуры, становятся доступны. Приложения пытаются инициировать соединения с этими корпоративными серверами, но терпят неудачу, что приводит к ухудшению производительности, ненужному трафику в Интернете и тайм-аутам.
  • Много малых офисов и большинство домашних сетей не имеют собственного сервера DNS, полагаясь вместо этого на широковещательное разрешение имен. Поскольку DNS-запросы являются более приоритетными, чем локальное широковещание, все имена будут ложно разрешаться на серверы, принадлежащие провайдеру, и локальная сеть работать не будет.
  • Браузеры, такие как Firefox, не смогут выполнять «поиск по имени» (когда ключевые слова, набранные в адресной строке, перенаправляют вас на ближайший найденный сайт).
  • Локальный DNS-клиент, встроенный в современные операционные системы, будет кешировать результаты DNS-поиска для повышения производительности. Если клиент переключается между домашней сетью и VPN, ложные записи могут остаться закешированными, тем самым создавая перерывы в обслуживании соединения VPN.
  • Антиспам решения DNSBL основаны на DNS; поэтому ложные результаты DNS мешают правильной работе DNSBL.
  • Конфиденциальные данные пользователя могут быть раскрыты приложением, которое поставил в заблуждение провайдер, изображая, что сервис, к которому оно пытается подключится, доступен.
  • Поисковая система не сможет исправлять неправильно напечатанные URL, опираясь на предыдущие выборы пользователя, так как провайдер определяет, какие результаты поиска отобразить пользователю; приложения, такие как панель инструментов Google, не смогут работать корректно.
  • Компьютеры, настроенные на использование раздельного тунеллирования с VPN-подключением перестанут работать, потому что имена интрасети, которые не должны разрешаться вне туннеля в публичной сети Интернет, станут разрешаться в фиктивные адреса, вместо того, чтобы корректно разрешаться через VPN-туннель на частном DNS-сервере при получении записи NXDOMAIN из Интернета. Например, почтовый клиент, пытающийся разрешить DNS-запись типа А для внутреннего почтового сервера, может получить ложный DNS-ответ, который направляет на платный веб-сервер с очередью сообщений на доставку в случае, если повторная передача была неудачной.
  • Это нарушает работу WPAP (протокола автоматической настройки прокси), заставляя веб-браузеры ошибочно полагать, что провайдер имеет конфигурацию прокси-сервера.
  • Это нарушает работу программного обеспечения для контроля. Например, если мы периодически обращаемся к серверу для проверки работоспособности, монитор не заметит подделки, пока не попытается проверить криптографический ключ сервера.

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

Манипуляции регистраторов править

Некоторые регистраторы доменных имен, в частности Name.com, производят перенаправление DNS при неудачном поиске доменных имен, несмотря на возражения против этого ICANN и их потребителей.

Решение править

В Великобритании Информационный Офис Комиссаров установил, что практика недобровольного DNS-перенаправления противоречит PECR и Директиве EC 95/46 о защите данных, которые требуют явного согласия для обработки коммуникационного трафика. Однако, он отказался вмешиваться, утверждая, что не было бы разумно проводить закон, потому что это не будет наносить существенного (или какого-либо) очевидного ущерба физическим лицам. ICANN, международная организация, отвечающая за управление доменными именами верхнего уровня, опубликовала меморандум, подчеркнув свою озабоченность и подтверждая: «ICANN строго препятствует использованию перенаправления DNS, подстановочных знаков, синтезированию ответов и другую форму замены NXDOMAIN в существующих gTLD, ccTLD и на любом другом уровне в дереве DNS регистрации класса доменных имен».

См. также править

Ссылки править

Источник — https://ru.wikipedia.org/w/index.php?title=DNS_hijacking&oldid=121379001