Chaque paquet IPv4 transitant sur Internet transporte un champ d'identification sur 16 bits (IP ID) dans son en-tête binaire. Défini dès 1981 dans la spécification RFC 791, ce champ avait pour vocation de permettre aux systèmes d'exploitation destinataires de réassembler les fragments de datagrammes dépassant le MTU des liaisons intermédiaires. Pendant des décennies, les développeurs de noyaux ont implémenté ce mécanisme à l'aide d'un simple entier global incrémenté : chaque émission de paquet par la machine augmentait la valeur de ce compteur d'une unité.

Cette fonction utilitaire a donné naissance à l'une des failles par canal auxiliaire (side-channel) les plus élégantes de l'histoire des réseaux. En observant les variations séquentielles du compteur IP ID d'une machine distante, un observateur externe peut cartographier les ports protégés par pare-feu d'un serveur cible sans transmettre le moindre paquet portant sa propre adresse IP, déduire des relations de communication internes et mesurer des flux de transmission de données.

Les standards actuels, en particulier la RFC 6864 et les protocoles de tunnelisation chiffrée comme WireGuard, ont profondément restructuré la gestion des identifiants IP par les systèmes d'exploitation. L'analyse de cette vulnérabilité met en lumière des principes fondamentaux de sécurité du transport, d'isolation de l'état du noyau et de protection par tunnels chiffrés.

+-------------------------------------------------------------------------+
|                  TRIANGLE D'ATTAQUE CLASSIQUE DE L'IDLE SCAN            |
+-------------------------------------------------------------------------+
|                                                                         |
|      1. Sonde IP ID (SYN/ACK)          2. SYN usurpé (Source=Zombie)    |
|         IP ID zombie = 31337              Port 443 cible                |
|      ┌─────────────────────────┐       ┌─────────────────────────┐      |
|      │                         ▼       │                         ▼      |
|  [Attaquant]                 [Hôte Zombie]                [Serveur Cible]|
|      ▲                         │       ▲                         │      |
|      │                         └───────┼─────────────────────────┘      |
|      3. Seconde sonde (SYN/ACK)        │ La cible répond SYN/ACK        |
|         IP ID zombie = 31339           │ Le zombie émet RST (ID + 1!)   |
|         Différence Delta = 2 -> PORT OUVERT ! └───────────────────┘     |
+-------------------------------------------------------------------------+

Les origines du champ d'identification IPv4 (RFC 791)

D'après le standard RFC 791, lorsqu'un routeur intermédiaire rencontre un datagramme d'une taille supérieure au MTU du saut suivant, il doit fractionner ce datagramme en fragments. Pour garantir que la station destinataire réassemble correctement les fragments appartenant à chaque paquet original, l'émetteur attribue un identifiant numérique à chaque datagramme.

Le récepteur reconstitue les données grâce à un quadruplet :

  • Adresse IP source (Source IP)
  • Adresse IP destination (Destination IP)
  • Identifiant de protocole (Protocol ID) (ex. TCP, UDP, ICMP)
  • Valeur d'identification (IP ID)

Puisque 16 bits n'offrent que 65 536 valeurs distinctes, les premiers systèmes d'exploitation (versions historiques de Windows, BSD et noyaux Linux anciens) ont utilisé une simple variable globale partagée :

// Implémentation historique : incrémentation monotone globale
static unsigned short global_ip_id = 0;

void build_ip_header(struct iphdr *iph) {
    iph->id = htons(++global_ip_id);
}

Cette architecture créait sans le vouloir un canal de télémétrie public : n'importe quel observateur extérieur pouvait évaluer avec précision le volume de paquets émis par une machine sur une période donnée.

Anatomie de l'Idle Scan : balayage aveugle de ports via machine zombie

En 1998, le chercheur en sécurité Salvatore Sanfilippo (antirez) a découvert que les compteurs séquentiels prévisibles d'IP ID permettaient d'effectuer des reconnaissances de ports entièrement indirectes. Baptisée Idle Scan (intégrée dans Nmap via l'option -sI), cette approche permet de sonder un réseau cible sans émettre de paquet portant la véritable adresse IP de l'opérateur.

Cette opération repose sur trois entités :

  1. L'attaquant : La station qui pilote l'envoi des requêtes et analyse les écarts.
  2. L'hôte zombie : Une machine peu sollicitée connectée à Internet, dont le compteur IP ID augmente de façon globale et dont le trafic de fond est minime.
  3. Le serveur cible : Le système dont on cherche à cartographier les règles de pare-feu et les ports en écoute.

La manœuvre consiste à pousser la cible à interagir avec le zombie, puis à mesurer l'impact de cet échange sur l'incrémentation du compteur du zombie.

Exécution technique étape par étape de l'Idle Scan

Pour chaque port ciblé, l'Idle Scan se décompose en trois phases minutieusement synchronisées :

  1. Étape 1 - Mesure initiale sur le zombie : L'attaquant envoie un paquet SYN/ACK inattendu au zombie. En l'absence de session TCP préexistante, le zombie répond par un paquet RST portant sa valeur d'identification actuelle ($IPID_1 = 1000$).
  2. Étape 2 - Sonde forgée vers la cible : L'attaquant émet un paquet SYN brut vers le port de la cible (par exemple le port 443), en falsifiant l'adresse IP source pour faire apparaître celle de l'hôte zombie.
  3. Étape 3 - Mesure de vérification sur le zombie : L'attaquant transmet un nouveau paquet SYN/ACK au zombie pour provoquer un second RST et relever la valeur actualisée ($IPID_2$).

Analyse des transitions d'état : ports ouverts, fermés et filtrés

L'écart mesuré entre les deux sondages ($\Delta = IPID_2 - IPID_1$) traduit directement l'état physique du port :

+-------------------------------------------------------------------------+
|                  TABLEAU DE DÉCISION DE L'ÉTAT DU PORT CIBLE            |
+-------------------------------------------------------------------------+
| État du port      | Réaction de la cible au SYN falsifié | Delta zombie (Δ) |
| :---              | :---                                 | :---             |
| OUVERT (OPEN)     | Transmet un SYN/ACK au zombie        | Δ = 2 (Ouvert)   |
|                   | Le zombie réplique par RST (consomme ID)                |
| FERMÉ (CLOSED)    | Transmet un RST au zombie            | Δ = 1 (Fermé)    |
|                   | Le zombie ignore le RST (aucun envoi)|                  |
| FILTRÉ (FILTERED) | Le pare-feu rejette sans réponse     | Δ = 1 (Pas de    |
|                   | Le zombie ne reçoit aucun flux       |       réponse)   |
+-------------------------------------------------------------------------+
  • Port ouvert ($\Delta = 2$) : La cible accueille la demande et renvoie un SYN/ACK vers le zombie. Ce dernier, recevant un accusé de réception imprévu, émet immédiatement un paquet RST en retour, ce qui consomme une valeur d'IP ID. Lorsque l'attaquant réinterroge le zombie à l'Étape 3, le compteur présente une avance de deux unités.
  • Port fermé ou filtré ($\Delta = 1$) : Si le port est fermé, la cible transmet un RST que le zombie écarte silencieusement. Si le port est filtré par pare-feu, le paquet est simplement ignoré. Dans les deux cas, le zombie n'émet aucun paquet additionnel, et son compteur n'augmente que d'une unité sous l'effet direct de la troisième étape.

Les journaux de sécurité du pare-feu et des systèmes de détection d'intrusion (IDS) n'enregistrent que les coordonnées du zombie, masquant totalement l'emplacement réel de l'attaquant.

Inférence du volume de trafic et suivi d'hôtes à travers les réseaux

La portée de cette vulnérabilité va bien au-delà de la découverte de ports :

  1. Surveillance du débit d'un serveur : En sondant régulièrement l'IP ID d'un serveur distant, un observateur peut tracer avec fidélité la courbe d'activité réseau et repérer des sauvegardes nocturnes ou des sessions d'administration.
  2. Identification de liaisons privées : Si deux serveurs échangent des flux non chiffrés sur un réseau interne, l'incrémentation conjointe de leurs compteurs respectifs permet de confirmer leur communication mutuelle.
  3. Corrélation d'équipements mobiles : Certains appareils intégraient autrefois des graines déterministes d'initialisation, facilitant le suivi d'un même ordinateur lors de ses déplacements entre plusieurs réseaux Wi-Fi.

Standardisation RFC 6864 : suppression de l'IP ID sur les datagrammes atomiques

L'IETF a formalisé la parade technique à ces failles dans le document RFC 6864: Updated Specification of the IPv4 ID Field, publié en 2013.

Le standard s'appuie sur la généralisation du protocole Path MTU Discovery (PMTUD, RFC 1191), qui active le bit Don't Fragment (DF = 1) sur l'immense majorité des paquets TCP et UDP. Tout paquet IPv4 portant le bit DF = 1 et non fragmenté est qualifié de datagramme atomique.

La RFC 6864 impose des principes opérationnels stricts :

  • Mise à zéro de l'identifiant : Les hôtes émetteurs sont autorisés et incités à fixer le champ IP ID à 0x0000 pour l'ensemble des datagrammes atomiques.
  • Dispense pour le récepteur : Les systèmes destinataires ne doivent pas exiger de valeur unique d'IP ID pour les paquets dont le bit DF = 1 est activé.
  • Suppression des compteurs globaux : Les noyaux ne doivent plus entretenir de registre séquentiel commun pour des destinations indépendantes.
+-------------------------------------------------------------------------+
|                  STRUCTURE DU DATAGRAMME ATOMIQUE SELON RFC 6864        |
+-------------------------------------------------------------------------+
|  En-tête IPv4 :                                                         |
|  [ Version: 4 ] [ IHL: 5 ] [ DSCP/ECN ] [ Total Length: 1500 ]          |
|  [ Identification: 0x0000 ] <--- RFC 6864 : Valeur 0 sur paquet atomique|
|  [ Flags: DF=1, MF=0 ] [ Fragment Offset: 0 ]                           |
|  [ TTL: 64 ] [ Protocol: 6 (TCP) ] [ Header Checksum ]                  |
|  [ Source IP ] [ Destination IP ]                                       |
+-------------------------------------------------------------------------+

Mécanismes de défense des systèmes modernes : Linux et BSD

Les systèmes d'exploitation modernes ont entièrement dissocié le champ IP ID de tout mécanisme global partagé.

Tables de hachage par socket et génération cryptographique PRNG

Les piles réseau contemporaines assurent une isolation rigoureuse :

  • Architecture du noyau Linux : Par défaut, Linux applique iph->id = 0 à tous les datagrammes atomiques. Lorsqu'une fragmentation s'avère indispensable, le noyau calcule une empreinte (siphash) combinant les adresses source et destination, le protocole et un sel secret, isolant ainsi l'incrémentation par pair distant.
  • Familles BSD et macOS : Recours à des générateurs de nombres pseudo-aléatoires cryptographiques (PRNG) qui produisent des suites non déductibles pour chaque association de transport.
  • Implémentation Windows : Depuis Windows 10 et Windows Server 2016, les compteurs globaux ont été remplacés par des attributions indépendantes et aléatoires.

Comment les tunnels VPN de couche 3 et RiceGuard neutralisent les fuites d'IP ID

Les réseaux privés virtuels de niveau 3 opérant en mode TUN (comme WireGuard) confèrent une protection structurelle complète face aux attaques par canal auxiliaire IP ID.

L'architecture de VPNRice repose sur une encapsulation cryptographique exigeante. Grâce au protocole RiceGuard, les données de l'utilisateur sont encapsulées au sein de datagrammes UDP authentifiés avant leur acheminement sur les réseaux publics.

+-------------------------------------------------------------------------+
|              ENCAPSULATION RICEGUARD ET ISOLATION DE L'IP ID            |
+-------------------------------------------------------------------------+
|  Pile système locale du client :                                        |
|  [ Paquet IP interne : SYN TCP vers la cible | IP ID interne du système]|
|                              │                                          |
|                              ▼                                          |
|  Moteur de tunnelisation RiceGuard :                                    |
|  [ Charge utile chiffrée ChaCha20-Poly1305 (En-tête interne masqué) ]   |
|                              │                                          |
|                              ▼                                          |
|  Liaison de transit externe :                                           |
|  [ En-tête IPv4 externe : UDP 51820 | IP ID externe = 0x0000 (RFC 6864)]|
+-------------------------------------------------------------------------+

RiceGuard élimine l'exposition aux canaux auxiliaires via trois garanties :

  1. Encapsulation totale des en-têtes : L'en-tête IPv4 initial et son identifiant IP ID sont chiffrés au sein de la charge Noise. Les observateurs extérieurs ne peuvent ni examiner ni corréler ces identifiants.
  2. Conformité externe avec la RFC 6864 : Les paquets UDP émis par le tunnel appliquent DF = 1 et un champ externe IP ID = 0x0000, empêchant toute observation de variations séquentielles.
  3. Rejet cryptographique des paquets usurpés : Les passerelles contrôlent la signature cryptographique avant tout traitement ; les sondes falsifiées sont écartées silencieusement sans modifier l'état réseau.

Les utilisateurs souhaitant préserver leurs communications contre les écoutes et l'analyse de flux peuvent installer l'application officielle depuis la page de téléchargement VPN.

Tests pratiques : détection d'hôtes zombies vulnérables avec Nmap

Les professionnels de la sécurité informatique évaluent la prévisibilité des compteurs de paquets à l'aide des scripts intégrés de Nmap :

# Vérifier si un hôte cible génère des IP ID de manière séquentielle
nmap -p 80,443 --script ipidseq 198.51.100.25

# Exemple de résultat vulnérable :
# Host script results:
# |_ipidseq: Incremental! (Vulnérable à une exploitation en tant que zombie)

# Exemple de résultat conforme à la RFC 6864 :
# Host script results:
# |_ipidseq: All zeros! (Sécurisé : conforme à la RFC 6864)

En présence de la mention Incremental, un audit en environnement contrôlé permet de vérifier le comportement du système :

# Test d'un balayage Idle Scan utilisant l'hôte zombie identifié
nmap -Pn -sI 198.51.100.25:80 203.0.113.50

Si le relais potentiel applique les règles modernes de randomisation ou de mise à zéro, Nmap signale : Cannot use zombie host: IP ID sequence is not incremental.

Comparaison architecturale : compteurs globaux versus génération aléatoire

Propriété technique Compteur global séquentiel Hachage par pair (Linux/BSD) Mise à zéro RFC 6864 (RiceGuard)
Exploitation par Idle Scan Vulnérable Protégé (Isolation des pairs) Protégé (Identifiant nul)
Estimation du trafic émis Accessible aux tiers Impossible pour un observateur Impossible pour un observateur
Empreinte de l'appareil Élevée (Suite séquentielle) Négligeable Nulle (Champ statique invariable)
Support de la fragmentation Intégral Intégral (Table par hôte) Intégral via PMTUD
Empreinte mémoire noyau 2 octets (Variable globale) Modérée (Table de hachage) Nulle (Valeur constante)
Charge de calcul processeur Minimale (++counter) Faible (Calcul SipHash) Minimale (Constante 0x0000)

La transition vers IPv6 : suppression complète de l'identifiant de base

La réponse architecturale définitive au problème de l'IP ID est venue avec la conception du protocole IPv6 (RFC 8200).

La fragmentation représentant moins de 0,1 % du trafic contemporain, les concepteurs d'IPv6 ont tout bonnement retiré le champ d'identification de l'en-tête standard fixe de 40 octets. Sous IPv6, les routeurs intermédiaires n'ont plus la possibilité de fragmenter les paquets : le fractionnement relève uniquement de l'hôte source au moyen d'un en-tête d'extension optionnel (Fragment Extension Header) :

+-------------------------------------------------------------------------+
|                  EN-TÊTE IPV6 STANDARD : AUCUN IDENTIFIANT FIXE         |
+-------------------------------------------------------------------------+
|  En-tête de base IPv6 (40 octets fixes) :                               |
|  [ Version: 6 ] [ Traffic Class ] [ Flow Label: 20 bits ]               |
|  [ Payload Length: 16 bits ] [ Next Header: 6 (TCP) ] [ Hop Limit: 64 ] |
|  [ Source IPv6 Address: 128 bits ]                                      |
|  [ Destination IPv6 Address: 128 bits ]                                 |
|                                                                         |
|  * AUCUN CHAMP D'IDENTIFICATION N'EXISTE DANS L'EN-TÊTE FIXE ! *        |
+-------------------------------------------------------------------------+

Les datagrammes atomiques sous IPv6 ne possédant aucun en-tête de fragmentation, il n'existe physiquement aucun champ à observer. La méthode d'Idle Scan devient ainsi structurellement impossible au sein des réseaux IPv6 natifs.

Liste de contrôle pour administrateurs système face aux canaux auxiliaires IP ID

Pour prémunir les infrastructures contre ce type de vecteur de reconnaissance, voici les mesures recommandées :

  1. Adopter les directives RFC 6864 : Veiller à employer des noyaux Linux récents (4.0 ou supérieur) pour que les paquets atomiques portent un identifiant nul.
  2. Maintenir le fonctionnement du PMTUD : Configurer les pare-feux pour relayer les messages ICMP Type 3 Code 4 (Fragmentation Needed), évitant les blocages de fragmentation.
  3. Mettre en œuvre le filtrage anti-usurpation (BCP 38) : Activer la validation de chemin inverse (uRPF) sur les routeurs frontières pour rejeter les paquets aux adresses d'origine usurpées.
  4. Isoler les flux sensibles par des tunnels de niveau 3 : Faire transiter les communications inter-serveurs au sein de tunnels RiceGuard pour sécuriser les métadonnées de transport.
  5. Moderniser les parcs logiciels : Remplacer les systèmes d'exploitation et microprogrammes anciens qui continuent d'utiliser des compteurs d'identification globaux.

Grâce à la modernisation des spécifications réseau et au déploiement de liaisons chiffrées de niveau 3, le canal auxiliaire lié à l'IP ID a été résolu, privant les observateurs malveillants d'un outil d'analyse furtive.