Durcir DHCP

DHCP remet à une machine qui démarre son adresse, sa passerelle et son DNS, c’est-à-dire qu’il dit à chaque client où envoyer son trafic et à qui faire confiance pour résoudre les noms. Le protocole n’a aucune authentification: un client prend la première offre qu’il entend. Ce seul fait est tout le modèle de menace. Un serveur DHCP pirate, un portable avec dnsmasq, répond plus vite que le vôtre et possède désormais la passerelle et le résolveur de tous ceux qui l’ont cru et de là lit, redirige et réécrit le trafic à volonté. La défense n’est pas dans le serveur DHCP, elle est dans le switch, seule chose placée pour décider quelles offres sont autorisées sur le fil.

Les deux attaques et pourquoi elles vont de pair

Le serveur pirate est le coup direct: on le branche, on répond aux DISCOVER, on pointe la passerelle et le DNS sur soi. La starvation est la préparation qui le rend fiable: inonder le serveur légitime de DISCOVER sous des milliers de fausses adresses MAC jusqu’à vider son pool, de sorte que chaque nouveau client n’ait nulle part où obtenir un bail sinon le pirate. Ensemble, elles sont un homme du milieu pour tout le segment et ni l’une ni l’autre ne demande plus qu’un outil bon marché et un port.

Ce qui l’aggrave au-delà de la simple interception, ce sont les options qu’un serveur pirate peut pousser en plus de la passerelle et du DNS: une URL WPAD/PAC (option 252) qui route chaque navigateur par un proxy attaquant, un serveur NTP (option 42) qui décale les horloges assez pour casser la validation de certificat et Kerberos, un serveur TFTP/boot qui sert une image PXE trafiquée à une machine avant que son OS et donc son antivirus, n’existe. Le bail est un canal de configuration et non authentifié.

Le snooping DHCP : le contrôle de premier plan

Le snooping DHCP fait du switch l’arbitre que le protocole n’a pas. Chaque port est non fiable par défaut et ne peut émettre que des messages de client; la poignée de ports qui atteignent un vrai serveur DHCP (les liens montants, le port serveur) sont marqués fiables et une OFFER de serveur arrivant sur tout autre port est jetée. Cette seule distinction tue le serveur pirate quelle que soit sa vitesse de réponse:

ip dhcp snooping
ip dhcp snooping vlan 10,20,30
no ip dhcp snooping information option   # sauf si votre relais utilise l'option 82
interface Gi0/1
 description lien-vers-dhcp
 ip dhcp snooping trust
interface range Gi0/2-48
 ip dhcp snooping limit rate 15          # émousse la starvation

En fonctionnant, le snooping bâtit une table de bindings: la MAC, l’IP, le VLAN et le port de chaque bail observé. Cette table est le sous-produit précieux, parce que deux autres contrôles la lisent. La Dynamic ARP Inspection vérifie chaque ARP contre les bindings et jette ceux qui revendiquent une IP que la table dit appartenir à un autre, ce qui coupe le spoofing ARP qui atteindrait sinon le même homme du milieu par une autre porte. L’IP Source Guard filtre par adresse source par port, de sorte qu’un hôte ne peut usurper une IP qu’on ne lui a jamais louée:

ip arp inspection vlan 10,20,30
interface range Gi0/2-48
 ip verify source

La limite de débit sur les ports d’accès est la défense anti-starvation: un port émettant bien plus de DISCOVER qu’un vrai client ne le ferait déclenche la limite et est coupé, ce qui est exactement le comportement voulu face à un portable qui inonde en MAC.

Le 802.1X est le contrôle qui rend la question caduque

Le snooping, la DAI et le source guard défendent le réseau contre un appareil déjà branché. Le 802.1X pose la question antérieure, celle de savoir si l’appareil devrait être sur le réseau tout court, en exigeant une authentification auprès d’un serveur RADIUS avant que le port ne porte le moindre trafic au-delà de l’échange d’authentification. Un serveur DHCP pirate sur un portable non authentifié n’arrive jamais assez loin pour répondre à un DISCOVER, parce que son port ne s’ouvre jamais. Là où on peut le déployer, le 802.1X avec affectation dynamique de VLAN est le contrôle le plus fort et celui qui transforme “détecter l’appareil pirate” en “l’appareil pirate n’a pas pu se connecter”. Les contrôles L2 ci-dessus restent la défense pour tout ce qui ne sait pas parler 802.1X, ce qui dans un vrai parc est toujours une longue liste: imprimantes, téléphones, caméras, matériel de labo.

Le boot PXE, en bref

Le boot réseau fait confiance au même DHCP non authentifié pour lui dire où vit son image de boot, de sorte qu’un serveur pirate qui fait aussi tourner du TFTP peut servir une image trafiquée à une machine avant le chargement de l’OS, ce qui est de la persistance sous tout ce qui la détecterait. Le snooping ferme la moitié serveur-pirate; l’autre moitié consiste à préférer le boot HTTPS là où le firmware le supporte, vérifier les signatures d’image et garder le Secure Boot sur le chemin plutôt que de laisser PXE le contourner par repli.

Segmenter les baux

DHCP est aussi l’endroit où la segmentation réseau devient concrète, parce que le scope de chaque VLAN est là où ses clients apprennent ce qu’ils peuvent atteindre. Les réseaux utilisateur, invité, IoT et admin reçoivent des scopes séparés avec des passerelles et des DNS séparés, le VLAN serveur tourne en adresses statiques sans aucun DHCP à empoisonner et le scope invité remet une passerelle qui atteint internet et rien d’interne. Le bail est la première chose qu’un appareil apprend; le segmenter coûte moins cher que de dé-segmenter un réseau plat après un incident.

Ce qu’il faut vraiment surveiller

Le signal utile est simple et côté switch: le snooping journalise déjà les messages de serveur jetés sur les ports non fiables, ce qui est un serveur pirate qui s’annonce et la DAI journalise les ARP qu’elle a rejetés. Une vérification active rapide depuis un client règle aussi la question “y a-t-il un second serveur” en une commande:

nmap --script broadcast-dhcp-discover   # plus d'une OFFER est le constat

Ce que je ne m’embêterais pas à construire, c’est l’appareillage SIEM-plus-ML que ces guides ajoutent toujours. Le serveur pirate est jeté par le snooping au port qu’un log soit lu ou non; le log sert à savoir que c’est arrivé, pas à l’arrêter.

Où atterrir

Activez le snooping DHCP sur chaque switch d’accès avec seulement les liens montants et les ports serveur fiables, superposez la DAI et l’IP Source Guard sur sa table de bindings et limitez le débit des ports d’accès pour que la starvation déclenche une coupure plutôt qu’un vidage du pool. Poussez vers le 802.1X là où les appareils le permettent, parce qu’authentifier le port est strictement plus fort que policer ce qu’un appareil non authentifié a le droit de dire. Segmentez les scopes, gardez les serveurs en statique et sécurisez PXE pour que le bail ne puisse remettre une image empoisonnée à une machine. Le protocole ne s’authentifiera jamais lui-même; c’est au switch de le faire à sa place.