Sur un réseau local Ethernet ou Wi-Fi partagé, les postes de travail s'appuient sur une passerelle par défaut (default gateway) pour acheminer leurs données vers l'extérieur. Dans une architecture nominale, les paquets transitent vers le routeur local qui les achemine jusqu'au destinataire final. Cependant, la spécification d'origine de la pile IPv4 intègre depuis 1981 un protocole de diagnostic et de contrôle : l'Internet Control Message Protocol (ICMP), standardisé dans la RFC 792.

Au sein de la RFC 792 figure le message de redirection ICMP (Type 5). Conçu à une époque où les équipements d'un réseau local étaient implicitement dignes de confiance, ce message permet à un routeur d'indiquer à un hôte qu'un chemin plus court existe vers sa destination. Lorsqu'il est détourné par un assaillant situé sur le même segment réseau, ce mécanisme devient une attaque redoutable d'empoisonnement de routage (ICMP Route Poisoning).

Structure binaire du message ICMP Type 5 selon la RFC 792

Lorsqu'un routeur reçoit un datagramme IP et constate qu'il doit le réexpédier sur la même interface physique que celle d'où il provient, il conclut à une inefficacité d'acheminement. L'émetteur aurait pu contacter directement le routeur suivant. Le routeur génère alors un paquet ICMP Redirect à destination de l'hôte source.

Le paquet ICMP Type 5 adopte une structure normalisée :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type (5)  |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Gateway Internet Address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Internet Header + 64 bits of Original Data Datagram      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Détail des champs techniques :

  • Champ Type : Fixé à la valeur 5, signalant une redirection ICMP.
  • Champ Code : Précise la portée de la redirection :
    • Code 0 : Redirection pour l'ensemble du réseau de destination.
    • Code 1 : Redirection pour un hôte spécifique.
    • Code 2 : Redirection selon le type de service (ToS) et le réseau.
    • Code 3 : Redirection selon le ToS et l'hôte.
  • Gateway Internet Address : Adresse IPv4 (32 bits) de la nouvelle passerelle préconisée.
  • Charge utile : Contient l'en-tête IPv4 initial complété des 64 premiers bits (8 octets) du paquet ayant déclenché la redirection.

À la réception, le noyau du système d'exploitation de la victime examine ces 64 bits. S'ils correspondent à une connexion active (adresse IP source, destination et ports de transport), le système valide l'instruction et met à jour sa table de transmission (FIB).

Le vecteur d'attaque de l'homme du milieu sur réseau local

L'absence d'authentification cryptographique dans la RFC 792 permet à n'importe quel ordinateur présent sur le réseau local (comme un point d'accès Wi-Fi ouvert ou un commutateur non administré) d'émettre des trames ICMP Type 5 contrefaites.

L'attaque se déroule en trois étapes synchronisées :

  1. Surveillance du trafic : L'assaillant écoute le réseau local pour repérer les sessions sortantes de la machine ciblée.
  2. Fabrication de la fausse trame : Il forge un paquet ICMP Type 5 Code 1, mentionne sa propre adresse IP comme nouvelle passerelle, usurpe l'adresse du routeur légitime et joint les en-têtes interceptés de la victime.
  3. Injection dans la table système : Le système d'exploitation de la victime traite la notification comme venant du routeur officiel et inscrit dynamiquement une route hôte /32 dirigeant le trafic vers la machine de l'attaquant.
Phase d'attaque Action de l'attaquant Réaction du noyau système victime Résultat sur le réseau
Écoute Capture une session TCP/UDP active Émission normale des données Paramètres de connexion identifiés
Trame forgée Émission du paquet ICMP Type 5 Analyse des 64 bits d'en-tête joints Correspondance avec la socket active
Modification FIB Injection de son IP en passerelle Création d'une route hôte /32 Table de routage empoisonnée
Interception Réception du trafic de la victime Retransmission vers la vraie passerelle Attaque Man-in-the-Middle active

Risques et vecteurs de fuite pour les réseaux privés virtuels (VPN)

Un client VPN établit une interface virtuelle (tun0 ou wg0) pour encapsuler le trafic dans un canal chiffré. Toutefois, les attaques ICMP Redirect présentent des risques réels si les interfaces physiques ne sont pas convenablement protégées :

1. Détournement du point de terminaison du tunnel

Pour maintenir la liaison avec le serveur distant, l'application VPN transmet des paquets UDP encapsulés via l'interface réseau physique (eth0 ou wlan0). Si l'assaillant injecte une redirection ciblant l'adresse IP publique du serveur VPN, le système de la victime transmettra ses paquets chiffrés directement à l'attaquant. Bien que les données soient protégées par des algorithmes comme ChaCha20-Poly1305, l'intercepteur peut analyser les métadonnées, le volume de trafic ou couper la communication.

2. Évasion du tunnel et fuites en clair

Dans les environnements avec tunnel fractionné (split tunneling) ou lorsque le routage par politique n'est pas appliqué, une route hôte en /32 injectée prévaut sur des routes plus larges (comme 0.0.0.0/1). Des flux destinés à des services sensibles peuvent ainsi s'échapper en clair sur le réseau local physique en dehors du tunnel VPN.

Neutraliser les redirections ICMP au niveau du système

Les architectures réseau contemporaines n'ont aucun besoin de redirections dynamiques ordonnées aux stations clientes. La désactivation du traitement des paquets de redirection est formellement conseillée par la RFC 1122.

Configuration du noyau Linux via Sysctl

Vérifiez l'état actuel des directives de redirection :

sysctl -a | grep -E "accept_redirects|send_redirects"

Pour désactiver la réception et l'émission des redirections, insérez ces directives dans /etc/sysctl.d/99-disable-icmp-redirects.conf :

# Désactiver l'acceptation des redirections ICMP IPv4
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0

# Désactiver l'émission de redirections ICMP
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Désactiver les redirections ICMPv6 (RFC 4861)
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

Appliquez immédiatement sans redémarrage :

sudo sysctl --system

Paramétrage sous macOS et systèmes BSD

Sous macOS et les distributions BSD, modifiez la variable du noyau correspondante :

sudo sysctl -w net.inet.icmp.drop_redirect=1

Configuration des postes Windows

Sur les machines Windows, l'option se règle dans le registre du système d'exploitation via PowerShell :

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" -Name "EnableICMPRedirect" -Value 0 -Type DWord

Protection multicouche avec le routage par politique RiceGuard

Au-delà de la sécurisation locale des paramètres système, VPNRice met en œuvre l'architecture RiceGuard pour immuniser les échanges :

  1. Tables de routage isolées et marquage de paquets (fwmark) : RiceGuard attribue un marqueur pare-feu distinct aux flux applicatifs. La table des politiques du noyau (ip rule) dirige ces paquets vers la table isolée 51820, neutralisant toute tentative de manipulation de la table principale.
  2. Filtrage des paquets au niveau matériel : Des règles nftables éliminent directement les paquets ICMP Type 5 sur les cartes physiques avant leur transmission au système.
  3. Protection contre le rejeu WireGuard : Le protocole Noise IK et le compteur anti-rejeu sur fenêtre glissante de 64 bits rejettent automatiquement toute trame interceptée ou dupliquée.

Cette combinaison entre durcissement système et routage par politique de niveau 3 garantit une confidentialité totale, y compris sur les réseaux Wi-Fi publics non sécurisés.