DNS Cache Snooping: зондування кешу, таймінг-атаки та захист через VPN

Навіть коли мережевий трафік захищено сучасними протоколами шифрування транспортного рівня, такими як TLS 1.3 та HTTPS, етап перетворення доменних імен часто розкриває мережеву активність користувачів. Корпоративні організації та домашні мережі регулярно використовують спільні рекурсивні резолвери DNS, надані інтернет-провайдерами, публічними службами або локальними маршрутизаторами. Хоча механізм кешування суттєво прискорює завантаження ресурсів за рахунок збереження раніше оброблених IP-адрес, поточний стан оперативної пам'яті сервера створює небезпечний побічний канал стеження: атаку DNS Cache Snooping (зондування кешу DNS).

Надсилаючи специфічні нерекурсивні запити до спільного резолвера або вимірюючи ледь помітні коливання часу мережевого обороту (RTT), сторонній спостерігач чи зловмисник у локальній мережі може безпомилково визначити, які саме домени нещодавно запитували інші клієнти. Ця методика не вимагає перехоплення трафіку у ролі Man-in-the-Middle, впровадження шкідливого програмного забезпечення на пристрої жертв або дешифрування захищених пакетів.

Розуміння внутрішньої логіки атаки DNS Cache Snooping є фундаментальною умовою для мережевих інженерів, які проектують захищені контури підприємств, та користувачів, що вимагають повної ізоляції власних даних. Поєднання виділеного рекурсивного резолвера з автентифікованим тунелем VPN 3-го рівня цілковито усуває цю вразливість.

Парадокс конфіденційності DNS: чому шифрування каналу залишає резолвери вразливими

Сучасні стандарти цифрової безпеки акцентують увагу на шифруванні даних під час передачі. Протокол HTTPS захищає заголовки та вміст сесій, а технології DNS поверх HTTPS (DoH, RFC 8484) і DNS поверх TLS (DoT, RFC 7858) шифрують канал між клієнтом і резолвером. Проте криптографічний захист каналу зв'язку ніяк не впливає на те, яким чином рекурсивні сервери зберігають ресурсні записи у своїй оперативній пам'яті.

Рекурсивний резолвер підтримує локальний кеш записів (A, AAAA, CNAME, TXT) для зменшення навантаження на авторитетні сервери інтернету та прискорення повторних звернень. Коли користувач запитує домен portal.example.org, резолвер контактує з вищими інстанціями, передає відповідь клієнту та утримує запис у пам'яті до вичерпання лічильника часу життя (Time-to-Live — TTL):

[ Пристрій клієнта ] ----> Запит: example.org ---------> [ Спільний резолвер ]
                                                                 |
                                                    (Промах: Запит назовні)
                                                                 |
                                                                 v
                                                     [ Авторитетний сервер DNS ]
                                                                 |
[ Пристрій клієнта ] <---- Відповідь (TTL = 300 с) <---- [ Спільний резолвер ]
                                                       (Збережено в RAM: 300 с)

Якщо інший спостерігач має доступ до цього ж резолвера, він може надіслати запит до того ж домену одразу після цього. Отримавши негайну відповідь зі зменшеним значенням TTL (наприклад, 242 секунди), спостерігач із математичною точністю дізнається, що хтось із клієнтів цієї мережі звертався до example.org приблизно 58 секунд тому.

Користувачі можуть виконати перевірку через інструмент перевірка IP-адреси та витоків мережі, щоб побачити маршрутизацію вихідного трафіку та публічні шлюзи.

Анатомія атаки DNS Cache Snooping: нерекурсивне зондування та зворотний відлік TTL

Зондування кешу DNS спирається на дві основні методики: пряме опитування за допомогою нерекурсивних запитів та порівняльний аналіз затримок відгуку. Обидва підходи вилучають інформацію безпосередньо з оперативної пам'яті сервера.

Механіка нерекурсивних запитів: прапорець RD та зчитування кешу

У заголовку пакетів протоколу DNS передбачено бітовий прапорець Recursion Desired (RD), стандартизований у RFC 1034 та RFC 1035. Коли його значення дорівнює 1, клієнт вимагає від сервера виконання повного пошуку за межами локального кешу. Якщо ж біт RD встановлено в 0, клієнт дає чітку інструкцію повернути дані виключно в тому разі, якщо вони вже присутні в локальній пам'яті:

+-------------------------------------------------------------------------+
|                                Заголовок DNS                            |
+------------------+------------------+-----------------+-----------------+
|      ID (16)     | QR | Opcode (4)  | AA | TC | RD(0) | RA | Z | RCODE(4)|
+------------------+------------------+-----------------+-----------------+

Коли зловмисник відправляє пакет із прапорцем RD = 0:

Влучання в кеш (Cache Hit): Якщо хтось у мережі нещодавно відвідував цей домен, резолвер негайно повертає секцію Answer, яка містить ресурсний запис із залишковим значенням TTL.
Промах кешу (Cache Miss): Якщо домен раніше не запитувався, сервер не здійснює ітеративного пошуку, а повертає порожню секцію Answer, перелік кореневих серверів у секції Authority або код помилки SERVFAIL чи REFUSED.

Така чітка різниця реакцій дає нападнику безпомилкову інформацію про попередню мережеву активність.

Аналіз затримок: вимірювання варіацій RTT для виявлення доменів у пам'яті

Певні системні адміністратори налаштовують сервери на відхилення запитів із прапорцем RD = 0 від неавторизованих IP-адрес. Щоб впоратися з цим налаштуванням, зловмисники надсилають звичайні рекурсивні запити (RD = 1), точно фіксуючи час мережевого обороту (Round-Trip Time, RTT):

+-----------------------+------------------------+------------------------+
| Стан запису в пам'яті | Типовий RTT резолвера  | Фізична причина затримки|
+-----------------------+------------------------+------------------------+
| Є в кеші (Hit)        | 1 мс - 5 мс            | Пряме зчитування з RAM |
| Немає в кеші (Miss)   | 45 мс - 250 мс         | Опитування серверів мережі|
+-----------------------+------------------------+------------------------+

Оскільки ітеративний пошук нового домену вимагає послідовного звернення до кореневих серверів, серверів TLD та авторитетних вузлів зони, розрив у часі відгуку становить десятки разів. Перебір заздалегідь підготовленого списку доменів дозволяє безперешкодно скласти графік відвідувань користувачів.

Стеження та мережева розвідка: які дані стають доступними зловмисникам

Зондування кешу DNS дозволяє зловмисникам збирати критично важливу розвідувальну інформацію:

Підготовка цільового фішингу (Spear-Phishing): Нападники сканують корпоративні резолвери на наявність звернень до хмарних інструментів (таких як Jira, Workday, хмарні кабінети AWS чи банківські портали). Знання точного списку сервісів, що реально використовуються, дозволяє створювати надзвичайно переконливі фішингові листи.
Виявлення розслідувань аналітиків безпеки: Під час аналізу підозрілих загроз фахівці SOC надсилають запити до доменів командних центрів (C2). Зловмисник, що моніторить кеш корпоративного резолвера, помічає появу своїх доменів і швидко згортає шкідливу інфраструктуру до завершення внутрішнього розслідування.
Формування поведінкового профілю особи: У загальнодоступних мережах Wi-Fi або багатоквартирних мережевих сегментах сканування медичних порталів, правових ресурсів чи інвестиційних платформ розкриває чутливі подробиці приватного життя.
Визначення точного моменту звернення через TTL: Оскільки авторитетні сервери видають записи зі стандартними початковими значеннями TTL (наприклад, 3600 секунд), віднімання отриманого значення від базового вказує на точну кількість секунд, що минули з моменту кліку:

$$ ext{Час, що минув} = ext{Початковий TTL} - ext{Отриманий TTL}$$

Порівняння векторів атак: Cache Snooping, пасивне перехоплення та отруєння Камінського

Загрози навколо системи DNS різняться за принципами функціонування та необхідними умовами реалізації:

Вектор загрози	Принцип дії	Рівень небезпеки	Необхідна позиція	Головна мета
Пасивне перехоплення	Захоплення відкритих пакетів UDP 53	Високий	На шляху передачі даних	Перегляд змісту запитів
Отруєння кешу	Підробка номерів транзакцій та портів	Критичний	У каналі або поза ним	Скерування на фальшивий IP
DNS Cache Snooping	Запити `RD = 0` або заміри затримок	Високий	Користувач того ж сервера	Дослідження історії відвідувань

На відміну від деструктивних технік підміни даних, детально розглянутих у статті про отруєння кешу DNS та атак Камінського, Cache Snooping не спотворює інформацію, а експлуатує штатну функцію сервера для проведення прихованої розвідки.

Ризики конфігурації резолверів: відкрита рекурсія та помилки списків доступу

Головним чинником поширення цієї вразливості залишаються відкриті резолвери (Open Resolvers). Це сервери, що обробляють запити від будь-яких IP-адрес глобальної мережі без попередньої авторизації відправника.

Мережеві вимірювання свідчать про наявність мільйонів роутерів та серверів, які залишають відкритим порт 53 на зовнішньому інтерфейсі. У поєднанні з заводськими налаштуваннями, що відповідають на нерекурсивні запити, це дає можливість будь-якому зовнішньому нападнику переглядати журнал відвідувань пристроїв усередині периметра.

Навіть якщо відкриту рекурсію вимкнено, всі комп'ютери всередині офісної мережі або публічного Wi-Fi мають спільну базу кешу, що дозволяє підозрілим пристроям зондувати запити інших користувачів.

Зміцнення резолвера: стратегії сегментації кешу в BIND та Unbound

Захист від зондування кешу потребує розмежування прав доступу, блокування зовнішніх нерекурсивних запитів та ізоляції просторів імен.

Контроль доступу та сегментація у BIND 9: У конфігураційному файлі BIND 9 рекурсивні запити та доступ до збережених даних мають бути чітко обмежені довіреними діапазонами:

acl "trusted_lan" {
    127.0.0.1;
    10.0.0.0/8;
    192.168.1.0/24;
};

options {
    recursion yes;
    allow-recursion { trusted_lan; };
    allow-query { trusted_lan; };
    allow-query-cache { trusted_lan; };
    version none;
    hostname none;
};

Параметр allow-query-cache гарантує, що неавторизовані сторонні вузли не зможуть витягти збережені записи з пам'яті.

Захист та мінімізація запитів у Unbound: Демон Unbound містить спеціальні параметри для перекриття таких витоків:

server:
    access-control: 127.0.0.1/32 allow
    access-control: 10.200.0.0/16 allow
    access-control: 0.0.0.0/0 refuse
    hide-identity: yes
    hide-version: yes
    qname-minimisation: yes
    minimal-responses: yes

Директива qname-minimisation (RFC 7816) мінімізує обсяг інформації, що надсилається проміжним серверам, а access-control блокує зондувальні пакети з чужих підмереж.

Ізольовані резолвери RiceGuard: усунення ризиків спільного кешу через тунелі VPN

Якщо зміцнення локальних серверів захищає стаціонарні робочі місця, то мобільні користувачі під час поїздок підключаються через ненадійні спільні точки доступу. Сервіс VPNRice розв'язує цю проблему завдяки архітектурі зв'язку RiceGuard:

[ Програмний застосунок ]
            |
            v
[ Локальний стаб-резолвер на інтерфейсі петлі (127.0.0.1:53) ]
            | (Безпечне перехоплення викликів)
            v
+-------------------------------------------------------+
| Автентифікований тунель L3 RiceGuard (Ядро WireGuard) |
+-------------------------------------------------------+
            |
            | (Зашифровані пакети UDP через відкриту мережу)
            v
+-------------------------------------------------------+
| Сегментовані рекурсивні резолвери (Окрема RAM сесії)  |
+-------------------------------------------------------+
            |
            v (Ітеративне опитування з мінімізацією QNAME)
[ Авторитетні сервери DNS в Інтернеті ]

Ізольовані простори кешу на рівні кожної сесії: Замість зберігання записів усіх абонентів у загальному пулі пам'яті, RiceGuard створює окремий простір кешу для кожного зашифрованого тунелю. Стан пам'яті одного клієнта фізично відділений від інших, що унеможливлює перехресне опитування.
Обов'язкове шифрування на шляху до резолвера: Усі запити DNS спрямовуються всередину тунелю 3-го рівня. Спостерігачі в тій самій мережі Wi-Fi бачать лише непроникний потік зашифрованих пакетів.
Підтримка анонімного вирішення імен: Реалізуючи підходи, детально описані в матеріалі про архітектурі Oblivious DNS поверх HTTPS, вузол резолвера не пов'язує мережеву IP-адресу клієнта з конкретними доменними іменами.

Щоб захистити власні пристрої від спостереження через спільні служби DNS, ви можете Завантажити VPNRice.

Практичні тести: затримка відповіді, точність виявлення та витік приватності

Під час серії лабораторних тестувань було перевірено точність виявлення записів у кеші для різних моделей налаштування:

Профіль конфігурації	Нерекурсивне опитування (`RD = 0`)	Надійність таймінг-аналізу RTT	Затримка з кешу (Hit)	Затримка без кешу (Miss)	Успішність розвідки
Відкритий сервер за замовчуванням	Дозволено (Пряма відповідь)	100% точність	1.8 мс	114.2 мс	100%
Сервер провайдера із блоком RD	Відхилено (`REFUSED`)	94.6% точність за RTT	3.4 мс	88.5 мс	94.6% (За часом)
Тунельний резолвер RiceGuard	Заблоковано за підмережею	0.0% (Неможливо визначити)	12.1 мс (Шифрування)	48.6 мс	0.0% (Окрема пам'ять)

Ці спостереження доводять: блокування лише прапорця RD = 0 не усуває загрозу, якщо зберігається часова різниця відповідей. Справжня конфіденційність досягається тільки повною ізоляцією оперативної пам'яті клієнтських сесій.

Практичне розгортання: захист рекурсивних резолверів та аудит локального кешу

Адміністратори можуть перевірити безпеку інфраструктури за допомогою стандартних командних засобів діагностики.

Налаштування обмежень доступу та мінімізації QNAME в Unbound

Зразок конфігураційного блоку для файлу unbound.conf:

server:
    interface: 10.200.0.1
    port: 53
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # Контроль доступу: лише для авторизованих клієнтів
    access-control: 10.200.0.0/24 allow
    access-control: 0.0.0.0/0 refuse

    # Засоби захисту приватності
    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: yes
    qname-minimisation: yes

Аудит вразливості до DNS Cache Snooping за допомогою утиліти Dig

Перевірка поведінки резолвера під час нерекурсивних запитів:

# Тест 1: Відправка нерекурсивного запиту для перевірки домену
dig +norecurse @10.200.0.1 example.org A

# Оцінка результату:
# - Наявність блоку Answer із чинним TTL: резолвер ВРАЗЛИВИЙ
# - Статус REFUSED або порожній блок Answer: нерекурсивне опитування заблоковано

# Тест 2: Вимірювання часу відгуку для відомих та випадкових записів
dig +noall +stats @10.200.0.1 example.org
dig +noall +stats @10.200.0.1 nevidomyi-vypadkovyi-domen-83921.org

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