X-Forwarded-For : retrouver une IP client fiable

Une vérification de réputation est inutile si elle porte sur l’adresse de votre propre reverse proxy ou sur une IP choisie par le client. Avant d’exploiter X-Forwarded-For dans un WAF, un limiteur de requêtes ou un SIEM, il faut établir qui a fourni chaque partie de cette chaîne.

L’objectif est d’obtenir une adresse attribuable au trajet réseau observé. Cela ne transforme pas cette adresse en identité personnelle : un VPN, une passerelle ou un réseau partagé peuvent toujours regrouper plusieurs utilisateurs derrière elle.

Partir du pair réseau réellement connecté

Le serveur reçoit une connexion depuis un pair immédiat. Lorsque ce pair est votre reverse proxy, il connaît directement son adresse ; il ne connaît pas directement celle du navigateur. L’en-tête transmis par le proxy apporte une déclaration supplémentaire, dont la valeur dépend de votre architecture.

Inventoriez chaque chemin vers l’application : CDN, répartiteur, ingress, proxy interne, accès de supervision et éventuel accès direct à l’origine. Pour chacun, documentez le pair attendu, le traitement des en-têtes entrants et la manière dont le relais ajoute l’adresse qu’il observe.

Un en-tête normalisé ne résout pas seul cette question. La RFC 7239, section 8.1, rappelle que les informations Forwarded peuvent être modifiées par les intermédiaires ou le client. Le choix entre Forwarded et X-Forwarded-For ne dispense donc pas de définir la confiance.

Dessiner la frontière où la déclaration devient fiable

Choisissez le composant d’entrée qui est chargé de nettoyer ou reconstruire les informations de provenance. Ce choix doit correspondre à sa configuration réelle. Un proxy qui conserve aveuglément un en-tête client ne lui donne pas une origine fiable simplement parce qu’il l’a transmis.

Les relais suivants doivent n’accepter ces informations que depuis leurs prédécesseurs autorisés. Définissez cette confiance avec des adresses ou des plages contrôlées et un chemin réseau protégé. Une liste couvrant tous les réseaux privés peut être trop large si d’autres charges y sont capables d’atteindre l’application.

Vérifiez surtout que l’origine ne peut pas être jointe par un chemin qui évite l’entrée prévue. Sinon, un client peut fournir directement les en-têtes que l’application attribue normalement au proxy. Le problème est architectural, même si le parseur d’adresses fonctionne correctement.

Lire la chaîne depuis le côté connu

Dans un schéma où les proxys fiables ajoutent correctement le pair qu’ils voient, la lecture part du pair immédiat, puis remonte les valeurs depuis la droite. Elle s’arrête à la première adresse qui n’appartient pas à un relais de confiance. Les valeurs situées plus loin ne gagnent pas de fiabilité par leur seule position.

La documentation du module realip de Nginx décrit cette sélection lorsque real_ip_recursive est activé : le module utilise la dernière adresse non fiable de la chaîne, après vérification de l’adresse d’origine contre les relais configurés. La configuration précise reste liée au trajet que vous avez vérifié.

Considérez cet exemple fictif, composé uniquement d’adresses de documentation :

pair immédiat : 192.0.2.10          (proxy interne fiable)
X-Forwarded-For : 203.0.113.66, 198.51.100.24, 192.0.2.20
                                               ↑ proxy d’entrée fiable

Si 192.0.2.20 a ajouté 198.51.100.24 comme pair réellement observé, cette dernière adresse est la candidate utile. 203.0.113.66, située plus à gauche, peut avoir été fournie par le client. Prendre systématiquement la première valeur attribuerait la requête à une déclaration non vérifiée.

Utiliser un parseur adapté aux formats reçus

Ne découpez pas chaque adresse sur le caractère : : IPv6 en contient. Vérifiez également les en-têtes répétés, les espaces, les ports éventuels et les valeurs invalides selon les conventions effectivement émises par vos proxys. Forwarded possède une syntaxe distincte ; il ne se traite pas comme une simple liste XFF.

Définissez une seule méthode de sélection utilisée par la journalisation, la limitation de débit et l’enrichissement. Si trois composants appliquent trois règles, un même événement peut être associé à des IP différentes. Une alerte devient alors difficile à reproduire, même avec tous les journaux disponibles.

Conservez une issue explicite pour les valeurs inexploitables. Un parseur qui échoue ne doit pas inventer une adresse, réutiliser silencieusement celle d’une requête précédente ou choisir un autre en-tête non fiable. Le journal doit permettre de comprendre pourquoi l’attribution a échoué.

Tester la confiance, pas seulement le cas nominal

En environnement autorisé, envoyez des requêtes de test sur chaque chemin prévu. Utilisez des IP fictives dans les en-têtes contrôlés pour distinguer clairement ce qui provient du client de ce qui a été ajouté par votre infrastructure.

Le dernier cas expose les configurations qui font confiance à un nombre fixe de sauts alors que plusieurs trajets existent. Répétez ces tests après un changement de CDN, d’ingress ou de routage. La politique de confiance évolue avec le réseau.

Enrichir l’adresse retenue avec son contexte

Journalisez le pair réseau, l’adresse retenue, la méthode utilisée et un identifiant de requête. La conservation de l’en-tête brut doit suivre votre politique d’accès et de rétention, car il peut contenir des données non fiables ou superflues. Rendez ces champs distincts dans le SIEM.

Vous pouvez ensuite appliquer les critères de réputation et de type d’IP, puis consulter un rapport IP lorsque l’enquête le justifie. Ne qualifiez pas l’adresse de votre CDN comme celle de l’attaquant simplement parce qu’elle apparaît dans le journal de connexion.

Enfin, rapprochez l’IP des événements applicatifs : compte, session, ressource demandée et résultat. Le guide d’enrichissement IOC pour le SOC apporte le contexte externe. La provenance de l’adresse reste une preuve que votre propre chaîne de proxys doit fournir.