Лаборатория триажа трафика 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

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

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

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

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

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

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