Laboratorio di Triage del Traffico DNS e ARP

Un esercizio educativo di analisi dei pacchetti e di rafforzamento del resolver completato su una workstation Arch Linux.

Ambito: Questa repository è un progetto di apprendimento. La cattura inclusa è utile per fare pratica con l'ispezione di DNS e ARP, ma non dimostra di per sé un attacco di avvelenamento della cache in corso, hardware dannoso, lo sfruttamento di una specifica CVE o una connessione causale con una metrica di routing di NetworkManager.

Perché ho rivisto questo progetto

La mia prima relazione trattava diverse osservazioni come cause confermate. Era troppo assertivo. Un frame DNS di 839 byte non è automaticamente malformato o dannoso, e DNS-over-TLS protegge il traffico DNS verso il resolver upstream configurato—non ferma lo spoofing ARP o ogni attacco di livello 2/3.

La versione rivista mantiene le parti utili del laboratorio separando:

1. ciò che mostrano i dati forniti;
2. ciò che inizialmente sospettavo;
3. ciò che richiederebbe più prove;
4. ciò che la configurazione del resolver cambia effettivamente.

Questa distinzione fa parte di un buon lavoro di incident response. È meglio restringere una conclusione piuttosto che affermare più di quanto le prove supportino.

Obiettivi del laboratorio

• Ispezionare il traffico DNS e ARP con Wireshark e tshark.
• Confrontare i risultati del resolver locale con un resolver pubblico noto senza etichettare erroneamente il DNS in chiaro come crittografato.
• Configurare Unbound per inoltrare le query DNS upstream su TLS autenticato.
• Documentare limitazioni e spiegazioni alternative.
• Produrre passaggi che un'altra persona possa ripetere.

Ambiente

• Workstation Arch Linux
• Wireshark / tshark
• BIND dig
• Resolver locale Unbound
• Resolver upstream Cloudflare e Quad9 su TCP/853

Le versioni esatte dei pacchetti dovrebbero essere registrate quando il laboratorio viene ripetuto. La repository attuale non contiene metadati di versione sufficienti per attribuire il traffico a una vulnerabilità di prodotto.

Prove fornite

Riprodurre la revisione

1. Registrare l'integrità dei file

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

Salva l'hash e i metadati della cattura con le tue note. Non chiamare la cattura "prova incidente completa"; è uno snippet.

2. Esaminare il traffico 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

Cerca affermazioni IP-to-MAC ripetute o in conflitto. Un conflitto è uno spunto da indagare, non una prova automatica di un attaccante. Verifica se gli indirizzi sono valori sintetici di laboratorio, se un dispositivo è cambiato legittimamente e se la tempistica supporta l'ipotesi.

3. Esaminare il traffico 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

Filtri di approfondimento utili:

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

La dimensione dei pacchetti da sola non è un verdetto. Le dimensioni delle risposte DNS possono variare a causa del numero di record, EDNS, DNSSEC e del comportamento del trasporto. Ispeziona i record decodificati e confrontali con una baseline nota.

4. Confrontare i resolver

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

Lo script etichetta correttamente una query diretta dig @1.1.1.1 come DNS in chiaro sulla porta 53. Quando kdig è disponibile, esegue anche un test TLS separato.

5. Validare l'inoltro di Unbound

Rivedi configs/unbound.conf, adatta i percorsi dei certificati al sistema locale e valida prima dell'uso:

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

Una query riuscita insieme a una connessione stabilita su TCP/853 supporta la conclusione più ristretta che Unbound stia inoltrando all'upstream configurato su TLS. Non dimostra che un problema ARP o di routing non correlato sia stato eliminato.

Risultati e limitazioni

• La cattura può essere usata per identificare frame DNS e ARP e praticare una revisione strutturata.
• Un frame DNS di 839 byte è un'osservazione, non un indicatore di compromissione di per sé.
• Le prove attuali non identificano un resolver BIND 9 vulnerabile o una versione interessata, quindi CVE-2025-40778 è ricerca di base piuttosto che un'attribuzione di incidente.
• Il DNS-over-TLS autenticato migliora la riservatezza e l'integrità tra questo resolver e il suo upstream. Non mette in sicurezza l'intera rete locale.
• Un'attribuzione solida richiederebbe una provenienza completa della cattura, inventari dei dispositivi, prove su resolver/versione, riferimenti ai numeri di pacchetto, timestamp e test prima/dopo ripetibili.

Riferimenti

• RFC 7858 — DNS over TLS
• RFC 8310 — Profili di utilizzo della privacy DNS
• Avviso ISC per CVE-2025-40778
• Riferimento per i filtri di visualizzazione di Wireshark

Nota legale e sulla privacy

Usa strumenti di cattura pacchetti e test di rete solo su sistemi e reti di tua proprietà o per cui sei autorizzato a effettuare test. Controlla le catture per indirizzi privati, hostname, token, credenziali e informazioni personali prima di pubblicarle.