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 та Директиві ЄС 95/46 щодо захисту даних, які вимагають явної згоди для обробки комунікаційного трафіку. Однак, він відмовився втручатися, стверджуючи, що не було б розумно проводити закон, тому що це не буде завдавати істотної (або будь-якої) очевидної шкоди фізичним особам.

ICANN, міжнародна організація, що відповідає за управління доменними іменами верхнього рівня, опублікувала меморандум, підкресливши свою стурбованість і підтверджуючи: «ICANN суворо перешкоджає використанню перенаправлення DNS, символів підстановки, синтезованих відповідей і інших форм заміни NXDOMAIN в існуючих gTLD, ccTLD і на будь-якому іншому рівні в дереві DNS реєстрації класу доменних імен».

Див. також[ред.ред. код]

Посилання[ред.ред. код]