Кожного разу, коли застосунок ініціює захищене з’єднання HTTPS або надсилає запит до віддаленого сервісу, операційна система звертається до протоколу перетворення доменних імен, розробленого ще у 1987 році. Система доменних імен (DNS), стандартизована Полом Мокапетрісом у документі RFC 1035, транслює текстові назви сайтів у 32-бітні адреси IPv4 або 128-бітні координати IPv6. Задля високої швидкодії в часи мережі ARPANET протокол DNS було спроєктовано поверх протоколу UDP без збереження стану через стандартний порт 53.

У цій архітектурі відсутня вбудована криптографічна перевірка автентичності відповідей. Зловмисник, спроможний передбачити або підробити параметри запиту до рекурсивного резолвера (Recursive Resolver), може внедрить фальшиві записи безпосередньо в його оперативну пам’ять. Цей тип атаки відомий як отруєння кешу DNS (DNS Cache Poisoning). У разі успіху користувачі непомітно спрямовуються на підставні вузли, що відкриває шлях до викрадення облікових даних та перехоплення трафіку.

[Вузол клієнта] ─── (1) Запит: bank.example.com ───> [Рекурсивний резолвер]
                                                            │
                                            (2) Запит назовні: bank.example.com
                                                (TXID: 0x4A2F, Порт: 53)
                                                            ▼
                                            [Авторитетний сервер DNS]
                                                            ▲
                                                            │
                                            (3) Масив підроблених UDP-відповідей
                                                (Перебір TXID: 0x0000 - 0xFFFF)
                                                (Фальшива IP: 198.51.100.25)
                                                            │
                                            [Атакуючий вузол / Позиція MitM]

Структура класичного отруєння пам’яті резолвера

Під час звичайної рекурсивної обробки клієнтський пристрій опитує локальний резолвер (наприклад, сервер провайдера чи офісний шлюз). Якщо адреса відсутня в локальному кеші, резолвер послідовно звертається до кореневих серверів (.), серверів доменної зони першого рівня (.com), і врешті-решт — до авторитетних серверів запитуваного домену (example.com).

Для узгодження вхідного UDP-пакета з активним запитом специфікація RFC 1035 виділяє 16-бітний ідентифікатор транзакції (Transaction ID, TXID) у заголовку DNS. Отримуючи відповідь на порт 53, резолвер звіряє чотири параметри:

  1. IP-адреса джерела: повинна чітко збігатися з адресою авторитетного сервера.
  2. Порт призначення UDP: має відповідати локальному порту, з якого надсилався запит (історично фіксований порт 53).
  3. Блок запитання (Question): має містити точну назву домену та відповідний тип запису (A, AAAA, MX).
  4. Ідентифікатор TXID: повинен повністю збігатися з випадковим 16-бітним числом, згенерованим резолвером.

Поле розміром 16 біт забезпечує рівно 65 536 теоретичних значень ($2^{16}$). До 2008 року зловмисники застосовували таку схему: надсилали запит до резолвера щодо bank.example.com і відразу ж спрямовували лавину підроблених відповідей UDP від імені авторитетного сервера, перебираючи значення TXID.

Проте успіху заважав параметр часу життя запису (TTL, Time-to-Live). Якщо справжня відповідь від авторитетного сервера надходила раніше, коректний запис фіксувався в кеші на весь період TTL (зазвичай 86 400 секунд, або 24 години). Атакуючому доводилося чекати цілу добу до завершення терміну дії запису, щоб розпочати нову серію підбору.

Прорив Дена Камінскі: генерація піддоменів та підміна делегування

У липні 2008 року дослідник безпеки Ден Камінскі (Dan Kaminsky) оприлюднив уразливість, яка знівелювала обмеження TTL. Замість прямого опитування цільового домену зловмисник генерує тисячі запитів до випадкових неіснуючих піддоменів:

  • x01a9.bank.example.com
  • m47k2.bank.example.com
  • z99p8.bank.example.com

Оскільки такі піддомени гарантовано відсутні в пам’яті, резолвер щоразу змушений надсилати новий зовнішній запит до авторитетного сервера. Одночасно з цим атакуючий надсилає пачки фальшивих відповідей UDP для кожного згенерованого піддомену. У тіло підробленого пакета він додає підступні записи в секціях делегування (Authority) та додаткових даних (Additional):

;; QUESTION SECTION:
x01a9.bank.example.com.    IN    A

;; ANSWER SECTION:
x01a9.bank.example.com.    IN    A    198.51.100.99

;; AUTHORITY SECTION:
bank.example.com.          IN    NS   ns.attacker-domain.org.

;; ADDITIONAL SECTION:
ns.attacker-domain.org.    IN    A    198.51.100.66

Згідно з правилами обробки зон повноважень (Bailiwick Rules), авторитетна відповідь має право передавати дані про зміну серверів імен для своєї зони. Якщо хоча б один підроблений пакет випадково збіжиться з 16-бітним TXID раніше за легітимну відповідь, резолвер приймає пакет. Він зберігає не лише фіктивний піддомен, але й перезаписує авторитетний сервер NS для всього домену bank.example.com на вузол ns.attacker-domain.org!

Відтоді вся подальша обробка трафіку домену bank.example.com та будь-яких його підрозділів контролюється сервером атакуючого. На високошвидкісних каналах зв’язку підміна здійснюється за лічені секунди.

Математична ентропія та рандомізація портів джерела (RFC 5452)

Причиною результативності атаки Камінскі став малий обсяг простору пошуку. Простір у 16 біт ($N = 65 536$) легко компрометується за допомогою парадоксу днів народження (Birthday Attack) та швидкого надсилання пакетів UDP.

Для виправлення фундаментальної вразливості комітет IETF затвердив специфікацію RFC 5452 («Measures for Making DNS More Resilient against Forged Answers»). Стандарт закріпив обов’язкову рандомізацію портів джерела (Source Port Randomization, SPR). Резолвер припинив використовувати статичний вихідний порт 53 і перейшов до випадкового вибору тимчасового порту UDP з пулу приблизно у 50 000 доступних портів (у діапазонах 1024–65535 або 49152–65535).

Критерій стійкості Базовий стандарт RFC 1035 Рандомізація портів RFC 5452 Криптографічний контроль DNSSEC
Ентропія TXID 16 біт ($2^{16} = 65 536$) 16 біт ($2^{16} = 65 536$) 16 біт ($2^{16} = 65 536$)
Ентропія порту 0 біт (Статичний порт 53) ~15,6 біт (~50 000 портів) ~15,6 біт (~50 000 портів)
Загальний простір пошуку 65 536 комбінацій $pprox 3,27 imes 10^9$ комбінацій $pprox 3,27 imes 10^9$ комбінацій
Пакетів для 50% ймовірності ~300 пакетів ~2 000 000 пакетів Фальсифікація відхиляється через відсутність підпису
Тип захисту Імовірнісний Імовірнісний Криптографічні цифрові підписи (RSA/ECDSA)

Поєднання 16 біт TXID із 15–16 бітами випадкового порту змушує зловмисника водночас вгадувати дві змінні:

$$ ext{Загальна кількість комбінацій} = 2^{16} imes pprox 50 000 pprox 3 276 800 000$$

Спроба перебору понад 3,2 мільярда комбінацій перевантажує канал атакуючого та спричиняє спрацювання систем виявлення мережевих аномалій задовго до настання успіху.

Криптографічний ланцюжок довіри: DNSSEC

Хоча рандомізація портів згідно з RFC 5452 суттєво ускладнює підбір, вона залишається статистичним бар’єром. Шлюзи перетворення мережевих адрес (NAT), міжмережеві екрани та операторські пристрої CGNAT нерідко зводять динамічні порти UDP до вузького детермінованого пулу, знижуючи ентропію до критичного рівня.

Радикальним архітектурним захистом стало впровадження розширень безпеки DNS (DNSSEC), стандартизованих у RFC 4033, RFC 4034 та RFC 4035. Архітектура DNSSEC впроваджує криптографію з відкритим ключем:

[Коренева зона Root (.)]
  └─ Ключ KSK підписує ZSK ──> підписує запис DS для зони .com
                                     │
                                     ▼
[Зона верхнього рівня .com]
  └─ Ключ KSK підписує ZSK ──> підписує запис DS для зони example.com
                                     │
                                     ▼
[Авторитетна зона example.com]
  └─ Ключ KSK підписує ZSK ──> створює підпис RRSIG для bank.example.com
  1. RRSIG (Resource Record Signature): Цифровий підпис, доданий до кожного набору записів DNS (алгоритми RSA або ECDSA).
  2. DNSKEY: Відкритий ключ, призначений для перевірки цифрового підпису RRSIG.
  3. DS (Delegation Signer): Хеш SHA-256 ключа KSK дочірньої зони, збережений у батьківській зоні, що утворює цілісний ланцюжок довіри до кореневого якоря (Root Trust Anchor).

Валідуючий резолвер автоматично відкидає підроблені відповіді, навіть якщо атакуючому вдалося вгадати TXID і порт UDP, оскільки зловмисник не має закритого ключа для генерації коректного підпису RRSIG.

Локальні загрози та захист криптографічним тунелем 3-го рівня

У публічних бездротових мережах Wi-Fi чи загальних офісних мережах атакуючий на тому самому каналі не потребує сліпого підбору:

  • Пасивне перехоплення: Традиційний трафік DNS передається відкрито. Зловмисник перехоплює вихідні пакети у локальній мережі, дізнаючись точні TXID та порт джерела.
  • Випередження пакетів: Перебуваючи поруч із жертвою, пристрій атакуючого надсилає підроблену відповідь, яка досягає клієнта на кілька мілісекунд раніше за легітимну відповідь із глобальної мережі.
[Програми на пристрої користувача]
               │ (Внутрішній сокет 127.0.0.1)
               ▼
[Віртуальний інтерфейс wg0 / tun0]
   Шифрування ChaCha20-Poly1305 (Мережевий рівень L3)
               │
               ▼
[Фізичний сегмент Wi-Fi / Кабель Ethernet]
   Передаються виключно непрозорі зашифровані пакети WireGuard / RiceGuard
   Зловмисник не бачить назв сайтів, значень TXID та портів UDP 53
               │
               ▼
[Захищений рекурсивний резолвер VPNRice]
   Застосування рандомізації портів RFC 5452 та повна валідація DNSSEC
   Повна відсутність журналів запитів, пряма рекурсивна обробка Anycast

Щоб запобігти маніпуляціям у локальному сегменті, VPNRice спрямовує весь потік запитів DNS крізь зашифрований тунель 3-го рівня. Завдяки протоколу RiceGuard:

  • Кожен запит інкапсулюється в зашифрований блок ChaCha20 з автентифікаційним тегом Poly1305 ще до виходу в локальне середовище.
  • Сторонні пристрої в мережі Wi-Fi бачать лише криптографічний потік, що виключає зчитування TXID чи назв сайтів.
  • Обробка виконується на захищених резолверах VPNRice із суворою перевіркою DNSSEC та високою ентропією портів RFC 5452.

Практична перевірка конфігурації резолвера

Фахівці з мережевої безпеки можуть перевірити коректність роботи DNSSEC за допомогою стандартних термінальних команд:

# 1. Запит домену з вимогою перевірки підписів DNSSEC
dig +dnssec bank.example.com @127.0.0.1

# 2. Перевірка наявності прапорця ad (Authenticated Data) у відповіді
# Зверніть увагу на: flags: qr rd ra ad; QUERY: 1, ANSWER: 2

# 3. Тестування зони з навмисно пошкодженим підписом (повинен повернутися код помилки SERVFAIL)
dig sigfail.verteiltesysteme.net @127.0.0.1

# 4. Аналіз ланцюжка довіри за допомогою утиліти delv
delv @127.0.0.1 bank.example.com
  • Активація валідації DNSSEC: Переконайтеся, що системний резолвер (systemd-resolved або Unbound) працює з увімкненим параметром DNSSEC=yes.
  • Маршрутизація через захищений тунель: Запобігайте аналізу у відкритих мережах, спрямовуючи всі запити через з’єднання WireGuard або RiceGuard.
  • Блокування з’єднань у разі збою підпису: Налаштуйте систему сприймати код SERVFAIL як ознаку компрометації та відхиляти запит замість автоматичного відкочування до незахищеного режиму.