DNSSEC Zone Walking: NSEC, Злам Хешів NSEC3 на GPU та Захист NSEC5

Розширення безпеки системи доменних імен (DNSSEC) інтегрували криптографічну цілісність та автентифікацію джерела в протокол DNS, що первинно проектувався без вбудованих захисних засобів. Шляхом додавання цифрових підписів (RRSIG) до наборів ресурсних записів DNSSEC забезпечує виявлення валідуючими резолверами підробки відповідей та отруєння кешу під час передавання трафіку.

Утім, реалізація криптографічного засвідчення негативних відповідей — доведення того, що запитане ім'я не існує (NXDOMAIN) або вказаний тип запису відсутній (NODATA), — створила фундаментальну архітектурну проблему. Задля захисту закритих ключів підпису зони (ZSK) від компрометації на авторитетних серверах початкові специфікації вимагали автономного підписання. Власник зони підписував файл на ізольованому комп'ютері та розсилав статичні підписи публічним вузлам.

Ця експлуатаційна модель унеможливлювала динамічне генерування підписів для неіснуючих імен у реальному часі без постійної присутності ключів онлайн. Для статичного доведення неіснування IETF розробив запис Next Secure (NSEC) у RFC 4034. Попри математичну коректність, NSEC створив побічний канал витоку даних, відомий як збирання зони DNSSEC (Zone Walking), що дозволяє сканерам за лічені хвилини повністю відтворити топологію корпоративної мережі.

Дилема автентифікованого заперечення: чому негативні відповіді розкривають DNS

У звичайній DNS без перевірки автентичності авторитетний сервер повертає прапорець заголовка з кодом відповіді 3 (NXDOMAIN), якщо запис не знайдено. Проте рекурсивним резолверам із валідацією необхідне суворе математичне підтвердження того, що сторонній суб'єкт не підробив негативну відповідь задля приховування легітимного ресурсу.

Динамічне підписання кожного відхиленого запиту вимагає збереження ключа ZSK на граничних серверах. На етапі впровадження DNSSEC інженери відкинули цей варіант через загрозу викрадення ключів. Відтак RFC 4034 обрав схему статичних інтервальних доказів.

Замість твердження про те, що конкретне ім'я відсутнє, сервер надає підписане засвідчення: у відсортованій за алфавітом зоні між дійсними канонічними іменами A та B немає жодних інших записів. Цей математичний інтервал підтверджує відсутність шуканого імені, але водночас розкриває точні імена обох меж запитувачу.

Анатомія RFC 4034: як записи NSEC утворюють ненавмисний зв'язаний список

Запис NSEC реалізує автентифіковане заперечення через пряме посилання на наступне канонічне ім'я у файлі зони. Корисне навантаження містить два ключові поля: наступне доменне ім'я (Next Domain Name) та бітову карту типів (Type Bit Maps), яка фіксує перелік записів, активних для цього імені.

;; Приклад канонічного порядку в корпоративному файлі зони
alpha.example.com.     3600 IN NSEC  billing.example.com.   A RRSIG NSEC
billing.example.com.   3600 IN NSEC  db-cluster.example.com. A RRSIG NSEC
db-cluster.example.com. 3600 IN NSEC  example.com.           A RRSIG NSEC

Ці записи утворюють замкнений циклічний зв'язаний список. Останній за алфавітом запис NSEC вказує на вершину зони (example.com.). Усі внутрішні імена хостів виявляються поєднаними в єдиний детермінований ланцюг.

Канонічний порядок імен та механіка стандартного збирання зони

Сканери безпеки експлуатують цю зв'язаність шляхом надсилання послідовних рекурсивних запитів:

1. Початковий запит: Сканер запитує запис A для імені, що стоїть за алфавітом безпосередньо перед вершиною, наприклад 0.example.com.
2. Вилучення інтервалу: Сервер повертає NXDOMAIN разом із записом NSEC, що веде від вершини до першого імені: example.com. NSEC admin.example.com.
3. Просування ланцюгом: Сканер фіксує знайдене ім'я admin.example.com і формує наступний запит: admin0.example.com.
4. Ітеративний крок: Сервер надсилає наступний відрізок: admin.example.com NSEC api-gateway.example.com.
5. Завершення циклу: Процес триває, доки черговий запис NSEC не вкаже назад на example.com., що свідчить про вивантаження 100% вмісту зони.

Перелічення піддоменів: картування периметра корпоративної мережі за хвилини

Методика Zone Walking долає стандартні бар'єри зовнішнього моніторингу. Звичні механізми виявлення спираються на словниковий підбір, логи Certificate Transparency або пошукові сервіси, часто пропускаючи внутрішні сервіси.

Застосовуючи відкриті утиліти, такі як ldns-walk, проти зон із підтримкою RFC 4034, аудитори та дослідники дістають повний список серверів внутрішніх баз даних, панелей адміністрування, тестових кластерів та шлюзів захищених тунелів. Отримані дані розкривають принципи найменування вузлів та архітектуру платформ, полегшуючи цільові атаки.

Компроміс RFC 5155: хешоване підтвердження неіснування за допомогою NSEC3

Зважаючи на ризики витоку службових відомостей, у 2008 році IETF схвалив RFC 5155, який запровадив NSEC3 (хешоване автентифіковане заперечення існування).

Призначенням NSEC3 стало збереження функціоналу доведення неіснування без розкриття відкритих текстових імен. Замість прямого сортування рядків NSEC3 хешує кожне ім'я алгоритмом SHA-1, додає опціональну криптографічну сіль (salt) та застосовує повторні ітерації хешування.

;; Синтаксис NSEC3: [Алгоритм] [Прапорці] [Ітерації] [Сіль] [Наступний хеш] [Типи]
2T8A7...example.com. 3600 IN NSEC3 1 0 10 A1B2C3D4 7K9P2... A RRSIG

Хеші у кодуванні base32hex формують упорядковане кільце. Під час запиту неіснуючого імені сервер обчислює його хеш і повертає запис NSEC3, що покриває цей інтервал. Відкриті імена більше не містяться в тілі мережевих пакетів.

Злам NSEC3: словникові атаки за допомогою GPU та підбір хешів у Hashcat

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

Зібравши дані, дослідник переходить в офлайн. Оскільки NSEC3 базується на SHA-1 із фіксованою сіллю, процес зводиться до словникової атаки:

Слово ("vpn") -> Сіль ("A1B2C3D4") -> Ітеративний SHA-1 -> Порівняння із зібраним кільцем

Сучасні графічні процесори (GPU) здатні обчислювати десятки мільярдів операцій SHA-1 за секунду. Програмні комплекси на кшталт Hashcat мають вбудовані модулі (Mode 8300: DNSSEC NSEC3), оптимізовані саме для цих обчислень.

Дослідження показують, що словникові атаки на NSEC3 дають змогу відновити від 65% до 85% доменних імен за кілька годин через передбачуваність корпоративних назв (mail, vpn, api, auth, jira, dev).

Пастка обчислювального DoS: чому високі ітерації паралізують резолвери

У прагненні сповільнити перебір на GPU адміністратори зон у минулому підвищували параметр iterations у RFC 5155 до 500, 1000 або 2500 раундів SHA-1.

Така конфігурація виявилася серйозною помилкою, спричинивши асиметричну загрозу відмови в обслуговуванні (DoS) проти валідуючих резолверів:

• Асиметричність: Авторитетний сервер рахує значення NSEC3 лише один раз під час офлайн-підписання зони.
• Навантаження на резолвер: Кожен клієнтський запит до неіснуючого імені змушує резолвер повністю перераховувати всі 2500 раундів SHA-1 для підтвердження доказу.
• Перевантаження CPU: Штучний потік запитів NXDOMAIN до резолвера у зоні з високими ітераціями завантажує процесор на 100% порожніми підрахунками.

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

Сучасне зміцнення за RFC 9276: відмова від солі та нульові ітерації

З метою ліквідації небезпеки обчислювального DoS та усунення ілюзії безпеки параметрів NSEC3 організація IETF затвердила RFC 9276 (Рекомендації щодо параметрів NSEC3).

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

1. Ітерації мають дорівнювати нулю: Будь-які значення понад 0 не створюють перешкод для сучасних GPU, але виснажують резолвери. Необхідно вказувати iterations = 0.
2. Відмова від солі: Динамічна сіль не рятує словникові слова від цільового перебору та скидає кеш резолверів під час оновлення файлу зони. Рекомендовано застосовувати порожню сіль (знак -).
3. Обмеження на стороні резолверів: Сучасне програмне забезпечення встановлює ліміти перевірок. Якщо зона повертає запис NSEC3 із завищеними ітераціями, резолвер трактує її як незахищену або надсилає SERVFAIL для захисту ресурсів процесора.

;; Рекомендована конфігурація NSEC3 (відповідність RFC 9276)
;; Алгоритм = 1 (SHA-1), Прапорці = 0, Ітерації = 0, Сіль = -
U5G9E...example.com. 3600 IN NSEC3 1 0 0 - 8F3K2... A RRSIG

Наступний крок криптографії: протокол NSEC5 та доказово випадкові функції (VRF)

Оскільки NSEC3 не захищає від словникового зламу, криптографічна спільнота та IETF розробили специфікацію NSEC5 (DNSSEC-заперечення існування за допомогою доказово випадкових функцій — VRF).

NSEC5 усуває проблему збирання зони за допомогою асиметричної схеми VRF:

• Авторитетний сервер володіє секретним ключем VRF (sk_vrf).
• Резолвер має публічний ключ перевірки VRF (pk_vrf).
• Щоб отримати хеш доменного імені, необхідно володіти ключем sk_vrf.
• Щоб перевірити коректність доказу, достатньо мати pk_vrf.

Без секретного ключа зловмисник не здатен генерувати хеші офлайн, тому словникові атаки на базі GPU стають математично неможливими.

Динамічний онлайн-синтез проти офлайн-підпису: концепція "White Lies"

Альтернативною методикою, впровадженою великими постачальниками хмарних DNS, є NSEC із мінімальним покриттям (Minimal Covering NSEC), також відомий як "White Lies" (RFC 4470 та RFC 7129).

Сервер не публікує заздалегідь підписані списки, а генерує відповіді безпосередньо на граничних вузлах:

1. Якщо надходить запит до відсутнього імені charlie.example.com, сервер у режимі реального часу формує запис NSEC, що охоплює тільки діапазон (charlie\000.example.com NSEC charlie\001.example.com).
2. Цей запис засвідчує відсутність імені, не розкриваючи сусідніх дійсних хостів зони.
3. Ця модель вимагає збереження ключів підпису на прикордонних вузлах (PoP), що успішно забезпечується апаратними модулями безпеки (HSM).

Математичні гарантії конфіденційності через асиметричне обчислення VRF

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

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

Рекурсивна архітектура DNS RiceGuard: запобігання розвідці структури зон

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

Мережева архітектура RiceGuard Рівня 3 запобігає загрозам розвідки простору DNS:

• Мінімізація запитів (RFC 7816): Резолвери RiceGuard відкидають зайві мітки імен, надсилаючи вищим авторитетним вузлам лише фрагмент, необхідний для поточної ланки делегування.
• Кешування негативних відповідей: Сервер зберігає записи NXDOMAIN у буфері (RFC 2308), локально задовольняючи повторні запити для збереження ресурсів інфраструктури.
• Контроль алгоритмічної складності: Дотримуючись RFC 9276, RiceGuard блокує або знижує пріоритет записів NSEC3 із завищеними ітераціями, нейтралізуючи загрози обчислювального DoS.
• Запобігання витокам трафіку: Усі запити прямують крізь ізольовані тунелі WireGuard до локальних резолверів, відокремлюючи IP-адреси клієнтів. Перевірити параметри мережевого захисту можна на сторінці /what-is-my-ip.

Користувачі, які потребують стабільного з'єднання, можуть завантажити клієнтські модулі за посиланням /download. Докладний аналіз шифрування DNS наведено у статті /news/dnssec-vs-encrypted-dns-authenticity-privacy-architecture, а засоби захисту від часових атак описано у матеріалі /news/dns-cache-snooping-non-recursive-query-timing-defense.

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

Мережевим адміністраторам варто регулярно перевіряти публічні зони, щоб упевнитися у відсутності витоку структури через застарілі записи NSEC. Аудит передбачає аналіз чинних параметрів та налаштування політик підписування.

Перевірити вразливість до RFC 4034 можна командою dig +dnssec example.com NSEC або сканером ldns-walk @ns1.example.com example.com. Поява послідовного переліку імен свідчить про необхідність термінового переходу на NSEC3 за рекомендаціями RFC 9276.

У конфігурації BIND 9 політику вказують у файлі named.conf:

dnssec-policy "hardened-nsec3" {
    keys {
        ksk lifetime 365d algorithm ecdsap256sha256;
        zsk lifetime 60d algorithm ecdsap256sha256;
    };
    nsec3param {
        iterations 0;
        optout no;
        salt-length 0;
    };
};

Для Knot DNS (knot.conf) установіть параметри nsec3-iterations: 0 та nsec3-salt-length: 0 у розділі policy. Під час валідації командою dig +dnssec +multiline nonexistent.example.com A переконайтеся, що отриманий запис NSEC3 показує 0 ітерацій та порожню сіль -. Відмова від зайвих ітерацій у поєднанні зі стійкими резолверами унеможливлює розкриття внутрішньої топології за повного збереження автентичності DNSSEC.