DNS- und ARP-Datenverkehrs-Triage-Labor

Eine lehrreiche Übung zur Paketanalyse und Resolver-Härtung, durchgeführt auf einer Arch-Linux-Workstation.

Umfang: Dieses Repository ist ein Lernprojekt. Der enthaltene Mitschnitt ist nützlich, um DNS- und ARP-Inspektion zu üben, beweist aber für sich genommen keinen aktiven Cache-Poisoning-Angriff, keine bösartige Hardware, keine Ausnutzung einer bestimmten CVE und keinen kausalen Zusammenhang mit einer NetworkManager-Routingmetrik.

Warum ich dieses Projekt überarbeitet habe

Mein erster Bericht behandelte mehrere Beobachtungen als bestätigte Ursachen. Das war zu stark. Ein DNS-Frame mit 839 Bytes ist nicht automatisch fehlerhaft oder bösartig, und DNS-over-TLS schützt den DNS-Verkehr zum konfigurierten Upstream-Resolver – es stoppt ARP-Spoofing oder jeden Layer-2/3-Angriff nicht.

Die überarbeitete Version behält die nützlichen Teile des Labs und trennt:

1. was die bereitgestellten Daten zeigen;
2. was ich anfangs vermutete;
3. was mehr Beweise erfordern würde;
4. was die Resolver-Konfiguration tatsächlich ändert.

Diese Unterscheidung ist Teil guter Vorfallsarbeit. Es ist besser, eine Schlussfolgerung einzugrenzen, als mehr zu behaupten als die Beweise stützen.

Lab-Ziele

• DNS- und ARP-Verkehr mit Wireshark und tshark untersuchen.
• Lokale Resolver-Ergebnisse mit einem bekannten öffentlichen Resolver vergleichen, ohne Klartext-DNS fälschlicherweise als verschlüsselt zu bezeichnen.
• Unbound konfigurieren, um Upstream-DNS-Anfragen über authentifiziertes TLS weiterzuleiten.
• Einschränkungen und alternative Erklärungen dokumentieren.
• Schritte produzieren, die eine andere Person wiederholen kann.

Umgebung

• Arch Linux-Workstation
• Wireshark / tshark
• BIND dig
• Unbound als lokaler Resolver
• Cloudflare- und Quad9-Upstream-Resolver über TCP/853

Die genauen Paketversionen sollten aufgezeichnet werden, wenn das Lab erneut durchgeführt wird. Das aktuelle Repository enthält nicht genügend Versionsmetadaten, um den Verkehr einer Produktschwachstelle zuzuordnen.

Bereitgestellte Beweise

Die Überprüfung reproduzieren

1. Dateiintegrität aufzeichnen

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

Speichern Sie den Hash und die Mitschnitt-Metadaten mit Ihren Notizen. Nennen Sie den Mitschnitt nicht „vollständige Vorfallsbeweise“; es ist ein Ausschnitt.

2. ARP-Verkehr überprüfen

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

Achten Sie auf wiederholte oder widersprüchliche IP-zu-MAC-Angaben. Ein Konflikt ist ein Hinweis zur Untersuchung, kein automatischer Beweis für einen Angreifer. Überprüfen Sie, ob die Adressen synthetische Laborwerte sind, ob ein Gerät sich legitimerweise geändert hat und ob der Zeitpunkt die Hypothese stützt.

3. DNS-Verkehr überprüfen

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

Nützliche Folgefilter:

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

Die Paketgröße allein ist kein Urteil. DNS-Antwortgrößen können aufgrund der Anzahl der Einträge, EDNS, DNSSEC und des Transportverhaltens variieren. Untersuchen Sie die decodierten Einträge und vergleichen Sie sie mit einer bekannten guten Basislinie.

4. Resolver vergleichen

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

Das Skript kennzeichnet eine direkte dig @1.1.1.1-Abfrage korrekt als Klartext-DNS auf Port 53. Wenn kdig verfügbar ist, führt es auch einen separaten TLS-Test durch.

5. Unbound-Weiterleitung validieren

Überprüfen Sie configs/unbound.conf, passen Sie die Zertifikatspfade für das lokale System an und validieren Sie vor der Verwendung:

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

Eine erfolgreiche Abfrage plus eine hergestellte Verbindung zu TCP/853 unterstützt die engere Schlussfolgerung, dass Unbound an den konfigurierten Upstream über TLS weiterleitet. Es beweist nicht, dass ein nicht damit zusammenhängendes ARP- oder Routing-Problem beseitigt wurde.

Ergebnisse und Einschränkungen

• Der Mitschnitt kann verwendet werden, um DNS- und ARP-Frames zu identifizieren und eine strukturierte Überprüfung zu üben.
• Ein 839-Byte-DNS-Frame ist eine Beobachtung, kein Indikator für eine Kompromittierung an sich.
• Die aktuellen Beweise identifizieren keinen anfälligen BIND 9-Resolver oder eine betroffene Version, daher ist CVE-2025-40778 Hintergrundforschung und keine Vorfallszuordnung.
• Authentifiziertes DNS-over-TLS verbessert Vertraulichkeit und Integrität zwischen diesem Resolver und seinem Upstream. Es sichert nicht das gesamte lokale Netzwerk.
• Eine starke Zuordnung würde vollständige Mitschnitt-Herkunft, Gerätebestände, Resolver-/Versionsnachweise, Paketnummernreferenzen, Zeitstempel und wiederholbare Vorher/Nachher-Tests erfordern.

Referenzen

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

Rechtlicher und datenschutzrechtlicher Hinweis

Verwenden Sie Paketmitschnitt- und Netzwerktest-Tools nur auf Systemen und Netzwerken, die Sie besitzen oder zu deren Test Sie berechtigt sind. Überprüfen Sie Mitschnitte auf private Adressen, Hostnamen, Tokens, Anmeldeinformationen und personenbezogene Daten, bevor Sie sie veröffentlichen.