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 регистрации класса доменных имен».

См. также[править | править исходный текст]

Ссылки[править | править исходный текст]