Laboratoire de tri du trafic DNS et ARP

Un exercice pédagogique d'analyse de paquets et de durcissement de résolveur réalisé sur une station de travail Arch Linux.

Portée : Ce dépôt est un projet d'apprentissage. La capture incluse est utile pour s'entraîner à l'inspection DNS et ARP, mais elle ne prouve pas en soi une attaque active d'empoisonnement de cache, un matériel malveillant, l'exploitation d'une CVE spécifique, ou un lien de causalité avec une métrique de routage NetworkManager.

Pourquoi j'ai révisé ce projet

Mon premier compte rendu traitait plusieurs observations comme des causes confirmées. C'était trop affirmatif. Une trame DNS de 839 octets n'est pas automatiquement malformée ou malveillante, et DNS-over-TLS protège le trafic DNS vers le résolveur amont configuré — il n'arrête pas l'usurpation ARP ni toutes les attaques des couches 2/3.

La version révisée conserve les parties utiles du laboratoire tout en distinguant :

1. ce que montrent les données fournies ;
2. ce que j'ai initialement suspecté ;
3. ce qui exigerait davantage de preuves ;
4. ce que la configuration du résolveur change réellement.

Cette distinction fait partie d'un bon travail d'investigation d'incident. Mieux vaut resserrer une conclusion que d'affirmer plus que ce que les preuves soutiennent.

Objectifs du laboratoire

• Inspecter le trafic DNS et ARP avec Wireshark et tshark.
• Comparer les résultats du résolveur local avec un résolveur public connu sans étiqueter à tort le DNS en clair comme chiffré.
• Configurer Unbound pour transmettre les requêtes DNS amont via TLS authentifié.
• Documenter les limites et les explications alternatives.
• Fournir des étapes reproductibles par une autre personne.

Environnement

• Station de travail Arch Linux
• Wireshark / tshark
• BIND dig
• Résolveur local Unbound
• Résolveurs amont Cloudflare et Quad9 sur TCP/853

Les versions exactes des paquets devraient être consignées lorsque le laboratoire est relancé. Le dépôt actuel ne contient pas assez de métadonnées de version pour attribuer le trafic à une vulnérabilité produit.

Preuves fournies

Reproduire l'examen

1. Consigner l'intégrité des fichiers

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

Enregistrez le hash et les métadonnées de capture avec vos notes. N'appelez pas la capture « preuve complète d'incident » ; c'est un extrait.

2. Examiner le trafic 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

Recherchez des affirmations IP-vers-MAC répétées ou contradictoires. Un conflit est une piste à investiguer, pas une preuve automatique d'un attaquant. Vérifiez si les adresses sont des valeurs de laboratoire synthétiques, si un appareil a légitimement changé, et si le minutage soutient l'hypothèse.

3. Examiner le trafic 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

Filtres de suivi utiles :

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

La taille des paquets seule n'est pas un verdict. Les tailles de réponses DNS peuvent varier en raison du nombre d'enregistrements, d'EDNS, de DNSSEC et du comportement de transport. Inspectez les enregistrements décodés et comparez-les à un référentiel connu fiable.

4. Comparer les résolveurs

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

Le script étiquette correctement une requête directe dig @1.1.1.1 comme du DNS en clair sur le port 53. Lorsque kdig est disponible, il effectue également un test TLS séparé.

5. Valider la transmission Unbound

Examinez configs/unbound.conf, adaptez les chemins des certificats pour le système local, et validez avant utilisation :

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

Une requête réussie plus une connexion établie vers TCP/853 soutiennent la conclusion plus restreinte selon laquelle Unbound transmet au résolveur amont configuré via TLS. Cela ne prouve pas qu'un problème ARP ou de routage sans rapport a été éliminé.

Constatations et limites

• La capture peut être utilisée pour identifier les trames DNS et ARP et s'entraîner à un examen structuré.
• Une trame DNS de 839 octets est une observation, pas un indicateur de compromission en soi.
• Les preuves actuelles n'identifient pas un résolveur BIND 9 vulnérable ni une version affectée, donc CVE-2025-40778 est une recherche de contexte plutôt qu'une attribution d'incident.
• Le DNS-over-TLS authentifié améliore la confidentialité et l'intégrité entre ce résolveur et son amont. Il ne sécurise pas l'ensemble du réseau local.
• Une attribution solide exigerait une provenance complète de la capture, des inventaires d'appareils, des preuves résolveur/version, des références de numéros de paquets, des horodatages, et des tests avant/après reproductibles.

Références

• RFC 7858 — DNS sur TLS
• RFC 8310 — Profils d'utilisation de la confidentialité DNS
• Avis ISC pour CVE-2025-40778
• Référence des filtres d'affichage Wireshark

Note légale et confidentialité

Utilisez les outils de capture de paquets et de test réseau uniquement sur des systèmes et réseaux que vous possédez ou que vous êtes autorisé à tester. Examinez les captures pour détecter les adresses privées, les noms d'hôtes, les jetons, les identifiants et les informations personnelles avant de les publier.