Aller au contenu

TP – Usurpation de messages et protection du DNS

BTS SIO SISR 2e année – Bloc 3 – S09 – en binôme : un tape, l'autre lit ; on échange les rôles à chaque partie

Note

But. Lire des en-têtes de messages pour détecter une usurpation, écrire les enregistrements SPF, DKIM et DMARC d'un domaine de laboratoire dans un serveur DNS, durcir ce serveur (transfert de zone, version), puis signer la zone avec DNSSEC et constater qu'une modification est détectée.

Durée : 3 h 10. Prérequis : cours S09 lu.

Warning

Domaine de laboratoire uniquement. Tout se fait sur un domaine interne (lab.local) servi par ta machine virtuelle. On ne touche jamais au DNS d'un domaine réel (celui de l'établissement ou d'une entreprise), et on n'envoie aucun message d'usurpation.

Note

Comment ce TP fonctionne. Tu anticipes (« J'anticipe »), tu manipules, tu notes ce que tu constates, puis tu expliques (« Je comprends »).

Binôme : ____________ / ____________

Contraintes

  • Une machine virtuelle Debian avec un compte sudo, instantané avant de commencer ; paquets bind9 et bind9-dnsutils (qui fournit dig et delv).
  • Les adresses du TP sont des adresses de documentation (192.0.2.0/24, 203.0.113.0/24) ; les clés DKIM sont fictives.

Partie A – Lire des en-têtes (≈ 40 min)

Quatre messages arrivent chez un salarié de l'entreprise verdier.example. Voici des extraits fictifs de leurs en-têtes (le serveur de réception est mx.verdier.example).

Message 1

Authentication-Results: mx.verdier.example;
  spf=pass smtp.mailfrom=client-a.example;
  dkim=pass header.d=client-a.example;
  dmarc=pass header.from=client-a.example
Received: from mail.client-a.example (mail.client-a.example [192.0.2.60])
  by mx.verdier.example ...
Return-Path: <commande@client-a.example>
From: "Commandes" <commande@client-a.example>
Reply-To: commande@client-a.example
Subject: Bon de commande 4471

Message 2

Authentication-Results: mx.verdier.example;
  spf=pass smtp.mailfrom=promo-rapide.example;
  dkim=none;
  dmarc=fail header.from=verdier.example
Received: from srv77.promo-rapide.example (srv77.promo-rapide.example [203.0.113.77])
  by mx.verdier.example ...
Return-Path: <bounce@promo-rapide.example>
From: "Direction" <direction@verdier.example>
Reply-To: paiement.urgent@mail-secure.example
Subject: Virement urgent et confidentiel

Message 3 (message transféré par une liste de diffusion de l'association)

Authentication-Results: mx.verdier.example;
  spf=fail smtp.mailfrom=partenaire.example;
  dkim=pass header.d=partenaire.example;
  dmarc=pass header.from=partenaire.example
Received: from relais.association.example (relais.association.example [198.51.100.9])
  by mx.verdier.example ...
Return-Path: <contact@partenaire.example>
From: "Partenaire" <contact@partenaire.example>
Subject: Compte rendu de la réunion

Message 4

Authentication-Results: mx.verdier.example;
  spf=pass smtp.mailfrom=verdler.example;
  dkim=pass header.d=verdler.example;
  dmarc=pass header.from=verdler.example
Received: from mail.verdler.example (mail.verdler.example [203.0.113.200])
  by mx.verdier.example ...
Return-Path: <comptabilite@verdler.example>
From: "Comptabilité" <comptabilite@verdler.example>
Subject: Changement de RIB du fournisseur

A1 – Analyse

J'anticipe. Dans quels messages, selon toi, y a-t-il une tentative de tromperie ? ______________________

Message Résultat SPF DKIM DMARC Verdict (légitime ? usurpation ? autre ?) Indices
1
2
3
4
Éléments de réponse

1 : légitime (tout passe, tout est aligné sur le même domaine). 2 : usurpation. SPF « passe » mais pour le domaine de l'expéditeur réel (promo-rapide.example), qui n'est pas celui du From: : pas d'alignement, DMARC échoue, pas de DKIM, Reply-To vers une autre adresse. 3 : légitime malgré un SPF en échec : le relais de la liste n'est pas dans le SPF du partenaire, mais DKIM passe et est aligné : DMARC passe. 4 : tout passe, mais le domaine est un domaine proche (verdler avec un « l » à la place du « i ») : hameçonnage par domaine ressemblant ; la demande de changement de RIB est un classique de la fraude.

A2 – Ce que ça change

Je comprends. Pourquoi le message 4 réussit-il SPF, DKIM et DMARC ? Quelle protection manque à l'entreprise pour s'en prémunir ? ______________________

Partie B – Écrire les enregistrements dans un serveur DNS (≈ 50 min)

B1 – Installer BIND et déclarer une zone

sudo apt install -y bind9 bind9-dnsutils

Crée la zone (le fichier qui décrit le domaine) : sudo nano /etc/bind/db.lab.local

$TTL 300
@   IN SOA ns1.lab.local. admin.lab.local. ( 2026101901 3600 600 86400 300 )
    IN NS  ns1.lab.local.
    IN MX  10 mail.lab.local.
    IN TXT "v=spf1 ip4:192.0.2.25 -all"
ns1  IN A 127.0.0.1
mail IN A 192.0.2.25
www  IN A 192.0.2.80
_dmarc IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@lab.local"
sel1._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlabkeyfictive"

Puis déclare-la dans /etc/bind/named.conf.local (ajoute à la fin) :

zone "lab.local" {
    type primary;
    file "/etc/bind/db.lab.local";
};

Vérifie, puis recharge :

sudo named-checkzone lab.local /etc/bind/db.lab.local
sudo named-checkconf && echo "configuration valide"
sudo systemctl restart bind9

Je comprends. named-checkzone et named-checkconf testent sans appliquer : une zone invalide mal rechargée peut rendre le domaine injoignable. Relis la zone : quel enregistrement donne le serveur de messagerie ? la liste des expéditeurs autorisés ? la politique en cas d'échec ? ______________________

B2 – Interroger

dig @127.0.0.1 lab.local MX +short
dig @127.0.0.1 lab.local TXT +short
dig @127.0.0.1 _dmarc.lab.local TXT +short
dig @127.0.0.1 sel1._domainkey.lab.local TXT +short

Note les résultats : ______________________

J'anticipe. Un message envoyé depuis 192.0.2.99 avec une enveloppe @lab.local : passe-t-il SPF ? ______________________ (réponse en partie C).

Partie C – SPF et DMARC : raisonner (≈ 25 min)

C1 – SPF

Avec l'enregistrement v=spf1 ip4:192.0.2.25 -all, donne le résultat SPF de chaque envoi (le domaine de l'enveloppe est lab.local) :

Envoi depuis Résultat SPF (pass, fail) Pourquoi
192.0.2.25 (le serveur de l'entreprise)
192.0.2.99 (une autre machine)
Un outil d'envoi de newsletters hébergé chez un prestataire, non déclaré

C2 – Faire entrer un prestataire

L'entreprise utilise un prestataire de newsletters qui publie son SPF sous spf.prestataire.example. Réécris l'enregistrement SPF pour l'autoriser (aide : include:), en gardant -all :

C3 – DMARC : une mise en place progressive

Classe dans l'ordre les trois étapes ci-dessous et explique ce qu'on observe et ce qu'on risque à chacune :

Étape Politique On observe… On risque…
1 p=none
2 p=quarantine
3 p=reject

Partie D – Durcir le serveur DNS (≈ 30 min)

D1 – Le transfert de zone

J'anticipe. Un inconnu peut-il demander toute la zone à ton serveur ? ______________________

dig @127.0.0.1 lab.local AXFR

Résultat : ______________________

Je comprends. Quelles informations un attaquant récupère-t-il ainsi ? Pourquoi est-ce utile pour préparer une attaque ? ______________________

Interdis les transferts : dans /etc/bind/named.conf.local, ajoute à l'intérieur du bloc de la zone la ligne allow-transfer { none; };, puis :

sudo named-checkconf && sudo rndc reload
dig @127.0.0.1 lab.local AXFR

Résultat (constat) : ______________________

D2 – La version

dig @127.0.0.1 version.bind CH TXT +short

Note ce que le serveur annonce : ______________________

Dans /etc/bind/named.conf.options, ajoute dans le bloc options { … }; la ligne version "non communiquee";, recharge (sudo rndc reload) et relance la commande : ______________________

Point de contrôle : captures de D1 (avant et après) et D2 (avant et après).

Partie E – DNSSEC : signer, valider, détecter (≈ 40 min)

E1 – Créer les clés et signer la zone

cd /etc/bind
sudo cp db.lab.local db.lab.local.src
sudo dnssec-keygen -a ECDSAP256SHA256 -f KSK -n ZONE lab.local
sudo dnssec-keygen -a ECDSAP256SHA256 -n ZONE lab.local
for k in Klab.local*.key; do echo "\$INCLUDE $k"; done | sudo tee -a db.lab.local.src
sudo dnssec-signzone -N INCREMENT -o lab.local -f db.lab.local.signed db.lab.local.src

Je comprends. Deux clés sont créées : une KSK (signe les clés) et une ZSK (signe la zone). La commande de signature produit le fichier db.lab.local.signed et un fichier dsset-lab.local. qui contient l'enregistrement DS, à publier dans la zone parente : c'est ce qui crée la chaîne de confiance.

E2 – Servir la zone signée

Dans /etc/bind/named.conf.local, remplace db.lab.local par db.lab.local.signed dans la ligne file, puis :

sudo named-checkconf && sudo rndc reload
dig @127.0.0.1 www.lab.local A +dnssec +noall +answer

J'anticipe. Que voit-on en plus de l'enregistrement A ? ______________________

Éléments de réponse

Un enregistrement RRSIG : la signature de l'enregistrement A.

E3 – Valider comme le ferait un résolveur

Crée un fichier de confiance à partir de l'enregistrement DS (ici, le domaine de laboratoire n'a pas de parent : c'est toi qui joues la racine de confiance), puis interroge avec delv, un outil qui valide :

cd /etc/bind
awk '{ d=""; for(i=7;i<=NF;i++) d=d $i; printf "trust-anchors {\n  \"lab.local.\" static-ds %s %s %s \"%s\";\n};\n", $4,$5,$6,d }' dsset-lab.local. | sudo tee /root/ta.conf
sudo delv @127.0.0.1 -a /root/ta.conf +root=lab.local www.lab.local A

Résultat (cherche la mention fully validated) : ______________________

E4 – Une falsification

Simule un attaquant qui modifie un enregistrement : change l'adresse de www dans le fichier signé, sans re-signer :

sudo sed -i 's/192.0.2.80/192.0.2.66/' /etc/bind/db.lab.local.signed
sudo rndc reload
dig @127.0.0.1 www.lab.local A +short
sudo delv @127.0.0.1 -a /root/ta.conf +root=lab.local www.lab.local A

J'anticipe. Que renvoient dig et delv ? ______________________

Éléments de réponse

dig renvoie la fausse adresse (192.0.2.66) : un client qui ne valide pas ne voit rien. delv refuse : « no valid signature found » / « RRSIG failed to verify ». C'est l'intérêt de DNSSEC : un résolveur qui valide détecte la falsification. La signature de www ne correspond plus aux données.

Remets la bonne adresse (sudo sed -i 's/192.0.2.66/192.0.2.80/' /etc/bind/db.lab.local.signed), recharge, et vérifie que delv redonne fully validated.

Je comprends. Cite deux limites de DNSSEC : ______________________

Point de contrôle : captures de E2, E3 et E4.

Retour en entreprise (si ta situation le permet)

  • Observer : quels enregistrements SPF, DKIM et DMARC ton entreprise publie-t-elle ? (consultation par dig ou un outil en ligne sur le domaine de l'entreprise, avec accord du tuteur : c'est de la lecture publique.)
  • Documenter : qui gère le compte du bureau d'enregistrement du nom de domaine ? Quel second facteur ? Quelle date d'expiration ?

Rendu

Compte rendu PDF, nommé RENDU-B3A2-S09-NOM.pdf, contenant l'analyse de la partie A, la zone et les captures des parties B à E, et les réponses aux questions.

Bilan de la séance

Compétence du référentiel Ce que j'ai fait dans cette séance Niveau
B3.2 – Préserver l'identité numérique de l'organisation
B3.4 – Garantir la disponibilité, l'intégrité et la confidentialité des services informatiques et des données de l'organisation face à des cyberattaques

Note

Je sais faire, sans aide :

  • Lire des en-têtes et distinguer usurpation, relais légitime et domaine ressemblant ;
  • Écrire des enregistrements SPF, DKIM et DMARC ;
  • Restreindre le transfert de zone et masquer la version d'un serveur DNS ;
  • Signer une zone et prouver la détection d'une falsification ;
  • Dire ce que DNSSEC garantit et ce qu'il ne garantit pas.

Ce que je dois reprendre : ______________________