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., подтверждая сбор полного каталога зоны.

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

Методика Zone Walking преодолевает привычные барьеры внешней разведки. Традиционные средства поиска поддоменов полагаются на словари, логи прозрачности сертификатов (Certificate Transparency) или поисковые системы, упуская закрытые технологические узлы.

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

Компромисс RFC 5155: хешированное доказательство несуществования с NSEC3

В ответ на запросы реестров и корпоративного сектора в 2008 году IETF утвердил стандарт RFC 5155, представивший механизм NSEC3 (DNSSEC Hashed Authenticated Denial of Existence).

Целью NSEC3 стало сохранение проверяемого доказательства отсутствия при сокрытии открытых текстовых имен. Вместо сортировки строк в алфавитном порядке NSEC3 хеширует каждое доменное имя алгоритмом SHA-1 с добавлением опциональной криптографической соли и многократным повторением итераций.

;; Синтаксис 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 и ликвидации ложного чувства защищенности IETF выпустил документ RFC 9276 (Рекомендации по настройке параметров NSEC3).

RFC 9276 вводит строгие базовые требования для операторов зон:

1. Итерации должны быть равны нулю: Значения итераций выше нуля не создают барьера для современных кластеров GPU, но перегружают валидирующие резолверы. Рекомендовано жестко фиксировать iterations = 0.
2. Отказ от соли: Динамическая соль не защищает словарные термины от направленного перебора и сбрасывает кэш резолверов при обновлении зоны. Стандарт предписывает использовать пустую соль (знак -).
3. Ограничения валидации: Современное серверное ПО устанавливает жесткие пороги. Если авторитетный сервер возвращает запись NSEC3 с завышенным числом итераций, резолвер считает зону небезопасной или выдает SERVFAIL, предотвращая перегрузку CPU.

;; Рекомендованная конфигурация 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.

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

Динамический синтез против офлайн-подписи: концепция "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 Layer 3 нейтрализует векторы зонной разведки и защищает конечные устройства:

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

Клиентские модули для защищенного доступа доступны в разделе /download. Технические аспекты защиты доменных запросов рассмотрены в материале /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 подтвердит наличие нулевых итераций и пустой соли -. Отказ от лишних итераций и использование надежных резолверов устраняют риск утечки сетевой структуры при сохранении строгой подлинности DNSSEC.