Лаборатория триажа трафика DNS и ARP

Образовательное упражнение по анализу пакетов и усилению резолвера, выполненное на рабочей станции Arch Linux.

Область применения: Этот репозиторий — учебный проект. Включенный захват полезен для практики анализа DNS и ARP, но сам по себе он не доказывает реальную атаку отравления кэша, вредоносное оборудование, эксплуатацию конкретной CVE или причинную связь с метрикой маршрутизации NetworkManager.

Почему я пересмотрел этот проект

Мой первый отчет трактовал несколько наблюдений как подтвержденные причины. Это было слишком сильным утверждением. DNS-кадр размером 839 байт не является автоматически некорректным или вредоносным, а DNS-over-TLS защищает DNS-трафик до настроенного вышестоящего резолвера — он не останавливает ARP-спуфинг или любую атаку уровня 2/3.

Пересмотренная версия сохраняет полезные части лабораторной работы, разделяя:

1. что показывают предоставленные данные;
2. что я первоначально подозревал;
3. что потребовало бы дополнительных доказательств;
4. что на самом деле меняет конфигурация резолвера.

Это различие является частью хорошей работы по инцидентам. Лучше сузить вывод, чем утверждать больше, чем подтверждают доказательства.

Цели лабораторной работы

• Проверить трафик DNS и ARP с помощью Wireshark и tshark.
• Сравнить результаты локального резолвера с известным публичным резолвером, не ошибочно помечая обычный DNS как зашифрованный.
• Настроить Unbound для пересылки вышестоящих DNS-запросов через аутентифицированный TLS.
• Задокументировать ограничения и альтернативные объяснения.
• Предоставить шаги, которые другой человек может повторить.

Окружение

• Рабочая станция Arch Linux
• Wireshark / tshark
• BIND dig
• Локальный резолвер Unbound
• Вышестоящие резолверы Cloudflare и Quad9 через TCP/853

Точные версии пакетов следует записывать при повторном запуске лабораторной работы. Текущий репозиторий не содержит достаточных метаданных версий, чтобы приписать трафик уязвимости продукта.

Предоставленные доказательства

Путь	Назначение
evidence/incident_triage_snippet.pcap	Небольшой образец захвата пакетов, используемый для проверки DNS/ARP
evidence/wireshark_anomoly.png	Имя файла скриншота сохранено для истории репозитория; правильное написание — anomaly
reports/ANALYSIS.md	Обзор на основе доказательств и ограничения
scripts/checkdns.sh	Сравнивает вывод резолвера и четко указывает транспорт
configs/unbound.conf	Пример конфигурации пересылки Unbound с использованием DNS-over-TLS
logs/remediation_validation.txt	Пример вывода проверки с исправленными выводами
CVE_RESEARCH.md	Объясняет, почему имеющиеся доказательства не поддерживают атрибуцию CVE

Воспроизведите анализ

1. Запишите целостность файла

sha256sum evidence/incident_triage_snippet.pcap
capinfos evidence/incident_triage_snippet.pcap

Сохраните хэш и метаданные захвата вместе с вашими заметками. Не называйте захват «полным доказательством инцидента»; это фрагмент.

2. Проверьте ARP-трафик

tshark -r evidence/incident_triage_snippet.pcap -Y arp \
  -T fields -e frame.number -e frame.time_relative \
  -e arp.opcode -e arp.src.proto_ipv4 -e arp.src.hw_mac \
  -e arp.dst.proto_ipv4 -e arp.dst.hw_mac

Ищите повторяющиеся или конфликтующие утверждения IP/MAC. Конфликт — это зацепка для расследования, а не автоматическое доказательство злоумышленника. Проверьте, являются ли адреса синтетическими лабораторными значениями, изменилось ли устройство легитимно и поддерживает ли временная привязка гипотезу.

3. Проверьте DNS-трафик

tshark -r evidence/incident_triage_snippet.pcap -Y dns \
  -T fields -e frame.number -e frame.time_relative \
  -e ip.src -e ip.dst -e udp.srcport -e udp.dstport \
  -e dns.id -e dns.flags.response -e dns.qry.name \
  -e dns.count.answers -e frame.len

Полезные последующие фильтры:

dns && frame.len == 839
dns.flags.response == 1
dns.qry.name == "."
arp.duplicate-address-detected || arp.duplicate-address-frame

Размер пакета сам по себе не является вердиктом. Размеры DNS-ответов могут варьироваться из-за количества записей, EDNS, DNSSEC и поведения транспорта. Проверьте декодированные записи и сравните их с эталонным образцом.

4. Сравните резолверы

chmod +x scripts/checkdns.sh
./scripts/checkdns.sh example.com

Скрипт правильно помечает прямой запрос dig @1.1.1.1 как обычный DNS на порту 53. Когда доступен kdig, он также выполняет отдельный TLS-тест.

5. Проверьте пересылку Unbound

Проверьте configs/unbound.conf, адаптируйте пути к сертификатам для локальной системы и проверьте перед использованием:

sudo unbound-checkconf configs/unbound.conf
sudo ss -tnp | grep ':853'
dig @127.0.0.1 example.com

Успешный запрос и установленное соединение через TCP/853 поддерживают более узкий вывод о том, что Unbound пересылает запросы настроенному вышестоящему резолверу через TLS. Это не доказывает, что несвязанная проблема ARP или маршрутизации была устранена.

Выводы и ограничения

• Захват можно использовать для идентификации DNS- и ARP-кадров и практики структурированного анализа.
• DNS-кадр размером 839 байт — это наблюдение, а не само по себе индикатор компрометации.
• Текущие доказательства не идентифицируют уязвимый резолвер BIND 9 или затронутую версию, поэтому CVE-2025-40778 является фоновым исследованием, а не атрибуцией инцидента.
• Аутентифицированный DNS-over-TLS повышает конфиденциальность и целостность между этим резолвером и его вышестоящим. Он не защищает всю локальную сеть.
• Надежная атрибуция потребовала бы полного происхождения захвата, инвентаризации устройств, доказательств резолвера/версии, ссылок на номера пакетов, временных меток и повторяемого тестирования до/после.

Ссылки

• RFC 7858 — DNS over TLS
• RFC 8310 — DNS Privacy Usage Profiles
• ISC advisory for CVE-2025-40778
• Wireshark display-filter reference

Юридическое и конфиденциальное примечание

Используйте инструменты захвата пакетов и тестирования сети только на системах и сетях, которыми вы владеете или которые уполномочены тестировать. Перед публикацией проверяйте захваты на наличие частных адресов, имен хостов, токенов, учетных данных и личной информации.