TP 003
Inspection DHCP (DHCP Snooping)
Domaine : Sécurité couche 2 (Layer 2 Security)
60–90 min | 
Avancé
Assurez-vous d’avoir configuré votre environnement avant de télécharger l’activité.
1. Contexte
- Confidentiality : interception du trafic utilisateur.
- Integrity : modification ou redirection des flux via une fausse gateway ou un DNS frauduleux.
- Availability : perturbation de l’attribution d’adresses, voire déni de service via des attaques comme le DHCP starvation.
⚙️ Pré-requis
Avant de commencer ce TP, assurez-vous que :
– Packet Tracer est installé et fonctionnel
– Votre environnement de travail est prêt
2. Objectifs du laboratoire
- comment un serveur DHCP malveillant peut exploiter l’absence de contrôle natif du protocole ;
- comment l’inspection DHCP (DHCP Snooping) permet au switch d’accès de filtrer les réponses DHCP non autorisées.
3. Topologie
La topologie met en scène un switch d’accès SW1 connecté à un switch de distribution SW2. Les postes utilisateurs sont placés dans le VLAN 10, tandis que les ports inutilisés sont isolés dans le VLAN 999 de type Blackhole.
- Fa0/1–3 : ports d’accès en VLAN 10, considérés comme untrusted.
- Fa0/24 : lien trunk vers SW2, considéré comme trusted.
- Le serveur DHCP légitime se trouve derrière le chemin de confiance passant par le trunk.
- Un serveur DHCP malveillant est connecté à un port utilisateur non trusted.
Cette séparation permet au switch de distinguer les clients DHCP des sources autorisées de réponses DHCP.
4. Concept étudié
- Trusted interfaces : interfaces autorisées à transporter les messages DHCP serveur, notamment DHCPOFFER, DHCPACK et autres réponses issues du serveur légitime.
- Untrusted interfaces : interfaces utilisateur sur lesquelles seuls les messages émis par les clients DHCP doivent être acceptés.
- adresse IP,
- adresse MAC,
- VLAN,
- port d’accès,
- durée de bail (lease).
5. Scénario d’attaque
Dans ce scénario, un serveur DHCP malveillant est connecté au port Fa0/3, qui est un port d’accès non trusted dans le VLAN 10.
Le déroulement de l’attaque est le suivant :
- Le client diffuse un DHCP DISCOVER.
- Le serveur mavaillant répond rapidement avec un DHCP OFFER falsifié.
- Le serveur légitime répond également, mais le client peut accepter l’offre reçue en premier.
Le serveur malveillant peut alors fournir :
- une fausse passerelle par défaut pour intercepter le trafic ;
- un serveur DNS frauduleux pour rediriger les requêtes vers de fausses destinations ;
- des paramètres IP incohérents provoquant une perturbation du service.
Cette attaque permet notamment :
- une interception du trafic (MITM) ;
- une redirection ou manipulation des flux ;
- un empoisonnement DNS ;
- une dégradation du service réseau.
6. Analyse avant configuration
- le DHCP DISCOVER est envoyé en broadcast ;
- tout équipement capable de répondre peut envoyer un DHCP OFFER ;
- le client n’a aucun moyen natif de vérifier si l’offre provient d’une source légitime.
7. Travaux pratiques (Labs)
Une fois votre environnement prêt, téléchargez l’activité suivante :
Après avoir appliqué le durcissement des ports et des VLANs (TP001) ainsi que la
sécurisation des accès (TP002), nous allons maintenant protéger le processus
d’attribution IP grâce à DHCP Snooping, afin d’empêcher tout serveur DHCP
malveillant de distribuer des paramètres réseau non autorisés.
Phase 1 — Activation du mécanisme
- Activer DHCP Snooping globalement sur le switch d’accès.
→ initialise le moteur d’inspection DHCP.
- Activer DHCP Snooping uniquement sur le VLAN 10.
→ limite la protection au domaine utilisateur ciblé.
Phase 2 — Définition du modèle de confiance
- Déclarer le port Fa0/24 comme trusted.
→ correspond au chemin vers le serveur DHCP légitime.
- Vérifier que les ports Fa0/1–3 restent untrusted.
→ empêche les clients ou serveurs rogue d’émettre des réponses DHCP autorisées.
Phase 3 — Cohérence de la topologie
- Vérifier la cohérence du trunk entre SW1 et SW2.
→ le VLAN 10 doit être autorisé et le VLAN natif doit rester conforme à la stratégie de durcissement.
Phase 4 — Vérification du fonctionnement normal
- Générer une requête DHCP depuis un client du VLAN 10.
- Vérifier la création d’une entrée dans la DHCP Binding Table.
→ confirmer que le switch apprend correctement l’association IP / MAC / VLAN / Port.
Phase 5 — Simulation d’attaque
- Émettre un DHCPOFFER depuis le Rogue DHCP Server connecté sur Fa0/3.
- Observer le comportement du switch face à cette réponse DHCP non autorisée.
→ le paquet doit être filtré car il provient d’un port untrusted.
Phase 6 — Validation finale
- Vérifier que seules les réponses DHCP provenant du port trusted sont acceptées.
- Vérifier que les réponses DHCP provenant des ports untrusted sont bloquées.
Résultat attendu
- Le client obtient une adresse IP valide depuis le serveur DHCP légitime.
- Le serveur DHCP rogue est ignoré ou ses réponses sont supprimées.
- La DHCP Binding Table est correctement alimentée.
- Le switch contrôle effectivement le plan de distribution IP du VLAN utilisateur.
8. Solution type
- DHCP Snooping activé globalement sur SW1.
- DHCP Snooping activé uniquement sur le VLAN 10.
- Les ports utilisateurs Fa0/1–3 laissés en untrusted.
- Le port uplink/trunk Fa0/24 défini comme trusted.
- Les ports inutilisés maintenus en VLAN 999 et shutdown.
- Le trunk limité aux VLANs strictement nécessaires.
- Une DHCP Binding Table générée dynamiquement lors du processus DHCP.
- Une limitation de débit DHCP peut être appliquée sur les ports untrusted si le contexte le justifie.
SW1>enable
SW1#configure terminal
! 1) Activation globale de DHCP Snooping
SW1(config)#ip dhcp snooping
! 2) Activation de DHCP Snooping sur le vlan utilisateur
SW1(config)#ip dhcp snooping vlan 10
! 3) Optionnel: limitation du débit DHCP pour réduire les abus sur les ports utilisateurs
SW1(config)#interface range Fa0/1-3
SW1(config-if-range)#ip dhcp snooping limit rate 10
SW1(config-if-range)#exit
SW1(config)#interface Fa0/24
SW1(config-if)#ip dhcp snooping trust
SW1(config-if)#end
SW1#copy running-config startup-config
SW2>enable
SW2#configure terminal
SW2(config)#interface Fa0/23
SW2(config-if)#switchport mode access
SW2(config-if)#switchport access vlan 10
SW2(config-if)#end
SW2#copy running-config startup-config
Serveur DHCP légitime
Pool Name: VLAN10
Default Gateway: 192.168.1.254
DNS Server: 8.8.8.8
Start IP Address: 192.168.1.11
Subnet Mask: 255.255.255.0
Maximum Number of Users: 100
Serveur DHCP malveillant
Default Gateway: 192.168.1.254 (correct)
DNS Server: 6.6.6.6 (malveillant)
Start IP Address: 192.168.1.201
Subnet Mask: 255.255.255.0
Maximum Number of Users: 50
9. Vérification et tests
1. Vérifier l’état global de DHCP Snooping
Commencez par confirmer que la fonction est activée globalement et qu’elle est bien appliquée au
VLAN 10.
À vérifier dans la sortie :
- DHCP Snooping activé globalement
- VLAN 10 listé comme VLAN protégé
- Fa0/24 identifié comme trusted
- Fa0/1–Fa0/3 considérés comme untrusted.
2. Vérifier la DHCP Binding Table
Après qu’un client a obtenu une adresse IP via le serveur DHCP légitime, le switch doit créer une entrée dans la base de binding DHCP.
Résultat attendu :
- une association IP / MAC / VLAN / Interface visible
- le port du client correctement identifié
- le VLAN 10 correctement renseigné
- une durée de bail active si le contexte Packet Tracer l’affiche.
La DHCP Binding Table n’est pas seulement un journal d’attribution IP. Elle constitue une source de vérité utilisée ensuite par des mécanismes comme
Dynamic ARP Inspection (DAI) et IP Source Guard.
3. Vérifier la configuration du trunk trusted
Vérifiez que le port trunk Fa0/24 est bien configuré en trunk, avec le VLAN natif attendu, et qu’il est déclaré trusted pour DHCP Snooping.
À vérifier :
–> ip dhcp snooping trust présent sur Fa0/24.
4. Vérifier le comportement normal du client
Depuis le client légitime, renouveler ou redemander une adresse IP. Le but est de vérifier que le trafic DHCP normal traverse correctement le switch.
Vérification attendue :
- le client obtient une adresse IP valide
- la passerelle par défaut est correcte
- la binding table est alimentée
- aucun blocage ne survient sur le chemin trusted.
5. Tester l’attaque Rogue DHCP
Simuler ensuite l’émission d’une réponse DHCP depuis le Rogue DHCP Server connecté sur Fa0/3, qui est un port untrusted.
Ce qu’il faut observer :
- le paquet DHCP serveur émis depuis Fa0/3 doit être filtré
- le client ne doit pas recevoir de configuration frauduleuse
- le serveur légitime doit rester la seule source valable de réponses DHCP
- le trafic DHCP serveur provenant d’un port untrusted ne doit jamais être accepté.
6. Vérifier la cohérence globale après attaque
Après la simulation d’attaque, effectuez une dernière vérification globale pour confirmer que
le réseau reste cohérent.
SW1#show ip dhcp snooping binding
SW1#show running-config | section interface FastEthernet0/24
Validation finale :
- DHCP Snooping reste activé ;
- la table de binding contient uniquement les associations légitimes
- Fa0/24 reste trusted
- les ports utilisateurs restent untrusted
- le client conserve une configuration IP légitime.
🧪 Questions de validation
1️⃣ Pourquoi un port est-il trusted ?
Parce qu’il appartient au chemin de confiance menant au serveur DHCP légitime et qu’il est autorisé à transporter les réponses DHCP serveur.2️⃣ Que filtre exactement DHCP Snooping ?
Les messages DHCP serveur, notamment DHCPOFFER et DHCPACK, lorsqu’ils proviennent d’une interface non autorisée.3️⃣ Quel est le rôle de la binding table ?
Elle enregistre les associations IP–MAC–VLAN–Port apprises dynamiquement et sert de base de validation pour d’autres mécanismes de sécurité.💡 Astuce
- Limiter les VLANs autorisés sur les trunks réduit la surface d’attaque.
- Les ports inutilisés doivent être isolés et désactivés.
- Le chemin trusted doit être défini avec précision : une erreur ici casse le DHCP ou crée une faille.
- DHCP Snooping gagne en valeur lorsqu’il est combiné à Port Security, DAI et IP Source Guard.
- Sur Cisco IOS, les ports sont untrusted par défaut après activation de DHCP Snooping. En pratique, il suffit donc de déclarer explicitement les seuls ports trusted.
⚠️ Attention
- Déclarer un mauvais port comme trusted revient à autoriser une source DHCP non légitime.
- Un trunk nécessaire mais non trusted peut empêcher le passage des réponses du serveur DHCP légitime.
- DHCP Snooping mal aligné avec la topologie réelle rend la protection inefficace.
- Sans cohérence entre segmentation VLAN, trusted path et binding table, l’audit devient fragile.
- Si le mauvais port est configuré en trusted, un serveur DHCP malveillant pourra distribuer
des paramètres IP frauduleux.
–> À l’inverse, si le trunk ou le chemin vers le serveur DHCP légitime n’est pas trusted, les réponses DHCP valides seront bloquées.
10. Conclusion
DHCP Snooping apporte un contrôle indispensable sur un protocole historiquement vulnérable. En introduisant une frontière de confiance entre interfaces trusted et untrusted, le switch devient capable de bloquer les offres DHCP malveillantes, de préserver l’intégrité des attributions IP et de réduire la surface d’attaque au niveau de l’accès réseau.
Son intérêt ne se limite pas à la simple protection contre les Rogue DHCP Servers : il crée une base de corrélation fiable entre identité réseau et connectivité, ce qui en fait un pivot du hardening Layer 2 en environnement entreprise.
11. Extension (optionnel)
- Port Security : limitation du nombre de MAC par port pour réduire les attaques de type starvation ou flooding. (Ref. TP 002)
- Dynamic ARP Inspection (DAI) : validation des paquets ARP pour bloquer l’ARP spoofing.
- IP Source Guard : filtrage du trafic IP selon les associations apprises dynamiquement.
Références
- Cisco CCNAv7 – sécurité réseau, attaques réseau, DHCP Snooping, Port Security et techniques de mitigation Layer
- Bonnes pratiques de durcissement Layer 2 en environnement d’accès commuté.