Wordfence voit la même IP pour tous : corriger la détection derrière un proxy

Comprendre le risque d’une adresse de relais prise pour un visiteur

Wordfence affiche la même adresse IP pour des visiteurs censés venir de réseaux différents. Il peut s’agir de l’adresse d’un proxy ou du serveur, à la place de celle transmise pour le client. Un blocage déclenché pour une requête peut alors toucher plusieurs personnes, et les journaux deviennent difficiles à interpréter.

Un proxy est un intermédiaire qui reçoit une connexion puis la transmet au serveur WordPress. Du point de vue du serveur, cet intermédiaire est parfois le correspondant direct. L’adresse d’origine peut être transmise dans un en-tête, mais cet en-tête ne devient fiable que si la chaîne qui le produit est maîtrisée.

Le résultat recherché est une attribution cohérente aux réseaux réellement observés, sans permettre à un visiteur de choisir librement l’adresse utilisée par la sécurité. Ajouter l’adresse du proxy à une liste qui contourne toutes les règles ne résout pas ce problème. Cela peut au contraire donner à de nombreuses requêtes le même accès privilégié. Nous allons vérifier la détection avant de modifier les règles de blocage.

Comparer deux réseaux réellement distincts

Deux fenêtres de navigateur sur le même réseau peuvent partager une adresse publique. C’est normal derrière une box ou une passerelle d’entreprise. Le seul fait de voir deux utilisateurs sous la même IP ne démontre donc pas une mauvaise configuration.

Préparez deux accès dont les adresses publiques de sortie sont connues et différentes, par exemple un réseau fixe et une connexion mobile autorisée. Comparez la même famille d’adresses lorsque cela est pertinent : un appareil peut utiliser IPv6 alors qu’un relevé de sortie ne montre que son IPv4. Gardez ces adresses dans un dossier privé.

1. Notez l’adresse de sortie de chaque connexion avec le moyen de confiance habituel du réseau.
2. Ouvrez une page publique simple du site depuis chaque accès, sans soumission de formulaire ni paiement.
3. Relevez l’heure et un chemin reconnaissable pour retrouver les visites.
4. Comparez ensuite les adresses enregistrées par Wordfence pour ces deux demandes.
5. Si elles sont correctes ou si les réseaux partagent effectivement leur sortie, ne modifiez pas la détection. Cherchez plutôt la cause du regroupement que vous aviez interprété comme une panne.

Sauvegarder les réglages et identifier la chaîne

Cette intervention suppose les droits de réglage Wordfence et la connaissance des intermédiaires de l’hébergement. Notez la méthode actuelle, les proxys de confiance et les éventuelles exceptions. Préparez un accès de maintenance permettant de revenir en arrière si une mauvaise détection bloque le compte qui effectue le changement.

Faites confirmer le trajet : service de diffusion éventuel, proxy d’hébergement, serveur Web et PHP. Le produit peut recevoir une adresse déjà restaurée par le serveur, ou devoir exploiter un en-tête lui-même. Configurer les deux couches différemment sans comprendre leurs rôles peut produire une nouvelle erreur.

Préférez une copie qui reproduit cette chaîne, mais ne concluez pas à partir d’une copie sans proxy que la production utilise la même méthode. Une sauvegarde des réglages et, pour une modification serveur, du fragment de configuration est nécessaire. Ne copiez pas un rapport complet de diagnostics dans un forum : il peut révéler des chemins, des adresses internes et d’autres informations sans rapport avec la détection. Le relevé de quelques champs pertinents suffit à préparer le choix.

Lire les adresses détectées dans Wordfence

Dans Wordfence > All Options > General Wordfence Options, ouvrez How does Wordfence get IPs. Comparez Detected IP(s) et Your IP with this setting avec l’adresse attendue pour la connexion courante. Dans Wordfence > Tools > Diagnostics, la section IP Detection complète ce relevé.

Le plugin vérifié est Wordfence Security 9.0.2 de Mark Maunder, avec WordPress 4.7 et PHP 7.0 minimum et des essais déclarés jusqu’à WordPress 7.1.4. Les libellés peuvent être traduits, et l’environnement peut imposer un réglage. Utilisez le module déjà présent ; installer un autre pare-feu ne réparera pas automatiquement la transmission des adresses.

1. Conservez les valeurs actuelles avant de sélectionner une autre méthode.
2. Notez l’adresse directe PHP et les en-têtes disponibles, sans inventer ceux qui sont absents.
3. Comparez l’adresse annoncée pour votre connexion avec celle attendue.
4. Demandez au responsable quels relais et quel en-tête sont réellement fiables.
5. Si aucune source ne contient l’adresse correcte, passez à la transmission serveur : choisir au hasard une autre ligne ne peut pas recréer une donnée qui n’arrive pas.

Choisir une source conforme à l’architecture

Lorsque le serveur reçoit directement les visiteurs, ou restaure déjà leur adresse de façon fiable, la valeur PHP REMOTE_ADDR peut être la bonne source. Derrière un proxy qui laisse son adresse dans ce champ, cette valeur seule peut représenter le relais au lieu du visiteur.

Wordfence propose aussi des méthodes fondées sur X-Forwarded-For ou X-Real-IP. Utilisez-les uniquement lorsque l’intermédiaire prévu transmet cette information correctement. Un en-tête fourni librement par le client ne doit pas devenir une preuve d’identité. Le mode automatique reste le point de départ habituel ; ne le remplacez que lorsque la comparaison et l’architecture justifient un autre choix.

Sélectionnez la méthode confirmée dans How does Wordfence get IPs puis utilisez le bouton d’enregistrement de l’écran, généralement Save Changes. Reprenez la même petite lecture et le relevé. Le résultat attendu est une adresse cohérente pour ce visiteur, puis pour le second réseau. Une bonne valeur sur votre propre session ne valide pas encore toutes les chaînes possibles. Si le changement donne une adresse vide, interne ou commune aux deux accès, restaurez la méthode initiale et poursuivez avec les relais de confiance.

Si le trajet passe effectivement par Cloudflare, Wordfence propose aussi CF-Connecting-IP. Ne choisissez cette source qu’après confirmation de ce relais et du traitement fiable de l’en-tête jusqu’à PHP. Si le serveur a déjà restauré l’adresse réelle dans REMOTE_ADDR, cette méthode peut rester la bonne : empiler deux corrections sans observer leurs valeurs ne rend pas la détection plus fiable.

Définir les proxys de confiance sans autoriser tout le réseau

Une chaîne X-Forwarded-For peut contenir plusieurs adresses. Le traitement doit distinguer les relais autorisés de l’adresse retenue pour le visiteur. Il ne faut pas choisir systématiquement la première ou la dernière valeur parce qu’elle ressemble à une adresse publique.

Dans le même écran, le lien + Edit trusted proxies permet de saisir les adresses ou plages CIDR confirmées. Une plage CIDR décrit un ensemble d’adresses réseau. Utilisez les valeurs actuelles fournies par le responsable du service, pas les exemples d’une documentation ni une plage privée très large choisie par commodité.

1. Obtenez la liste des seuls relais autorisés à fournir les adresses de remplacement.
2. Conservez la liste précédente puis ouvrez + Edit trusted proxies.
3. Saisissez les valeurs confirmées dans Trusted Proxies, ou le préréglage du service réellement utilisé lorsqu’il est disponible et adapté.
4. Enregistrez et contrôlez Your IP with this setting.
5. Comparez à nouveau les deux réseaux. Si un relais manque ou si la liste semble trop large, faites corriger la chaîne avant de continuer ; ne classez pas tous les visiteurs parmi les proxys fiables.

Faire corriger l’en-tête lorsqu’il manque ou est réécrit

Si l’adresse attendue n’apparaît dans aucune source reçue par PHP, la correction doit se faire avant Wordfence. Le proxy peut ne pas transmettre l’en-tête, l’écraser avec son propre correspondant ou laisser passer une valeur fournie par le visiteur. Le nom d’un en-tête ne démontre pas son origine fiable.

Transmettez au responsable le trajet connu, le créneau des deux demandes et les valeurs observées. Il doit comparer l’adresse reçue au premier intermédiaire avec celle transmise au serveur applicatif. Une chaîne maîtrisée doit définir qui remplace l’information et quels correspondants sont autorisés à la fournir.

N’ajoutez pas un fichier PHP public qui affiche tous les en-têtes. Les outils privés et les journaux ciblés du service conviennent mieux à cette comparaison. Ne modifiez pas non plus les DNS pour éviter le proxy pendant ce diagnostic : cela changerait le trajet et pourrait exposer une origine normalement protégée. Après la correction de transmission, reprenez le contrôle dans Wordfence avant de changer une seconde fois ses réglages. Le résultat attendu est une information exploitable, pas la multiplication des en-têtes portant des valeurs contradictoires.

Restaurer une adresse fiable dans un serveur Nginx identifié

Ce parcours avancé concerne le responsable du serveur Nginx effectif, avec le module realip disponible. Il ne s’applique pas à un simple compte WordPress. Dans la configuration du seul domaine concerné, le fragment illustre une restauration depuis X-Forwarded-For ; remplacez impérativement CIDR_PROXY_VERIFIE par la source autorisée confirmée. Répétez la directive seulement pour les relais nécessaires.

Avec la recherche récursive, si le correspondant initial est un proxy déclaré fiable, Nginx retient la dernière adresse non fiable dans la chaîne de l’en-tête. Cela ne rend pas fiable une liste d’adresses arbitraires. La configuration qui produit l’en-tête et le périmètre d’accès à l’origine doivent aussi être maîtrisés.

1. Sauvegardez le fragment actif et vérifiez le module ainsi que le contexte de configuration.
2. Adaptez uniquement le bloc du domaine avec les adresses confirmées et le bon en-tête.
3. Contrôlez avec nginx -t, en conservant les paramètres habituels du service.
4. Après succès seulement, appliquez le rechargement prévu, par exemple nginx -s reload pour ce mode de gestion.
5. Vérifiez la valeur PHP obtenue puis la détection Wordfence. Si le test échoue, restaurez le fragment et son état actif selon le même contrôle.

set_real_ip_from CIDR_PROXY_VERIFIE;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Corriger les conséquences sans contourner toutes les règles

Une fois la détection réparée, un blocage antérieur peut encore viser l’adresse commune qui était utilisée par erreur. Examinez les événements et les règles concernés avant de retirer cette conséquence. La correction de la source n’efface pas automatiquement tous les blocages enregistrés.

Ne placez pas l’adresse du proxy dans Allowlisted IP addresses that bypass all rules pour faire revenir l’accès général. Si Wordfence considère les visiteurs comme venant de cette adresse, cette exception peut s’appliquer à un très grand ensemble de requêtes. Un proxy de confiance pour lire un en-tête et une adresse autorisée à contourner la sécurité sont deux notions différentes.

Le responsable peut retirer uniquement une exception de contournement ajoutée pour ce dépannage ou lever un blocage confirmé comme conséquence de la mauvaise attribution. Gardez son état initial et le motif de correction. Si une règle légitime continue à bloquer un visiteur avec sa bonne adresse, traitez cette règle selon son événement précis. Ne desserrez pas tous les seuils ni toutes les protections pour compenser un problème d’attribution qui doit désormais être vérifié séparément.

Vérifier la détection sur les parcours réels

Reprenez les deux réseaux et les mêmes lectures publiques. Comparez les nouveaux événements à leurs adresses attendues, puis vérifiez une connexion autorisée. Un cache de page peut empêcher certaines demandes d’atteindre WordPress ; l’absence d’une visite dans le journal n’est pas automatiquement une nouvelle erreur d’adresse.

Dans Wordfence > Tools > Live Traffic, utilisez les filtres et le créneau concernés. Si le mode de collecte ne montre pas les lectures publiques nécessaires, adaptez temporairement sa collecte sur le périmètre préparé, puis remettez le réglage initial. Évitez de laisser une vue très fréquente ouverte inutilement sur un hébergement limité.

1. Confirmez que les deux adresses différentes sont distinguées sur les requêtes observées.
2. Vérifiez qu’aucune adresse de relais n’est devenue une autorisation générale de contournement.
3. Contrôlez le parcours connecté et le site public sans provoquer volontairement de blocage.
4. Faites vérifier par le responsable que la source retenue ne peut pas être imposée librement par un client non fiable.
5. Archivez les résultats expurgés et les réglages finaux. La localisation géographique affichée n’est pas une preuve suffisante de la bonne attribution.

Distinguer une adresse partagée d’une identité individuelle

Même avec une configuration correcte, une adresse IP ne désigne pas une personne de façon unique. Plusieurs utilisateurs peuvent partager la sortie d’une entreprise, d’un opérateur mobile ou d’un réseau privé. À l’inverse, un même appareil peut changer d’adresse ou de famille d’adresses entre deux connexions.

Si le regroupement ne concerne que ces cas, ne changez pas les proxys de confiance pour forcer artificiellement une adresse différente par utilisateur. Examinez le comportement réel et les limites des règles qui reposent sur l’IP. Un compte connecté, un événement et une adresse réseau apportent des informations complémentaires, sans être interchangeables.

Après une modification d’infrastructure, vérifiez les différentes entrées prévues : domaine principal, sous-domaines ou accès d’administration selon l’architecture. Les sous-sites d’un réseau peuvent partager une configuration serveur tout en ayant des chemins différents. Une réussite sur l’accueil ne valide pas un second trajet qui passe par d’autres relais. Conservez ces différences dans le dossier de maintenance pour éviter de réutiliser une liste de confiance conçue pour un autre domaine ou un ancien prestataire.

Revenir au réglage précédent si la correction n’est pas établie

Si un changement produit des adresses incohérentes, rétablissez la méthode et la liste initiales sauvegardées. Si la configuration serveur a aussi été modifiée, faites annuler le fragment ciblé et appliquer le contrôle avant rechargement. Ne restaurez pas une ancienne base complète pour annuler un réglage d’adresse.

Vérifiez ensuite que l’accès de maintenance et le site public restent disponibles. Une configuration initiale incorrecte peut conserver le symptôme, mais il vaut mieux le documenter que cumuler plusieurs tentatives dont personne ne sait laquelle est active. Préparez la prochaine correction avec le responsable à partir des valeurs réellement reçues.

Le dossier utile contient la cible, les intermédiaires connus, les adresses attendues des tests et les valeurs observées avant et après. Masquez les éléments sans rapport et conservez les originaux en privé. Distinguez les réglages du plugin de ceux du serveur : remettre l’un en place n’annule pas nécessairement l’autre. La fin du diagnostic doit identifier une configuration cohérente et reproductible, pas seulement un retour provisoire à l’administration.

Documenter la confiance pour les prochains changements

Conservez la liste des intermédiaires, leur source officielle d’adresses et la personne qui maintient ces valeurs. Un prestataire peut modifier son réseau ; une liste recopiée une fois puis oubliée peut devenir incomplète. Préparez un contrôle après chaque migration, ajout de proxy ou changement du traitement des en-têtes.

Gardez un scénario simple avec deux réseaux autorisés et quelques lectures reconnaissables. Il permet de vérifier la chaîne sans lancer de charge, scanner le site ni déclencher une règle de blocage. Le contrôle doit confirmer l’adresse et sa provenance fiable, pas seulement une différence visuelle dans un tableau.

Aucune extension supplémentaire n’est nécessaire pour ce dépannage : les diagnostics du produit et les outils privés du serveur permettent de localiser l’écart. Si l’hébergement gère les relais, transmettez-lui la comparaison précise et le réglage attendu, sans essayer de contourner sa configuration. Une politique de confiance bien identifiée permet de conserver les protections utiles et de comprendre les événements futurs sans traiter tous les visiteurs comme un unique serveur.