Journaliser les IP des clients IIS derrière un proxy

Lorsqu'un proxy inverse transmet les requêtes à IIS, le champ Client IP Address (c-ip) contient généralement l'IP du proxy. Faites transmettre l'IP d'origine dans X-Forwarded-For, ajoutez l'en-tête aux journaux IIS, puis activez sa lecture dans RdpGuard pour HTTP ou RD Web Access.

Configurez le proxy pour transmettre l'IP d'origine à IIS dans l'en-tête X-Forwarded-For. Le réglage dépend du logiciel ; suivez sa documentation. L'exemple suivant utilise Nginx.

Si Nginx reçoit directement les connexions des clients, ouvrez la configuration du site et ajoutez cette directive au bloc location qui relaie les requêtes vers IIS :

proxy_set_header X-Forwarded-For $remote_addr;

Cela remplace toute valeur X-Forwarded-For du client par l'IP source de la connexion. La variable courante $proxy_add_x_forwarded_for conserve au contraire l'en-tête reçu et y ajoute une adresse. RdpGuard lit la première adresse : un client non fiable ne doit donc pas pouvoir la fournir. Consultez la documentation des en-têtes proxy Nginx.

Sous Linux, testez et rechargez la configuration Nginx :

sudo nginx -t && sudo nginx -s reload

Si un CDN, répartiteur de charge ou autre proxy précède Nginx, configurez d'abord les adresses de confiance et le traitement de l'IP client ; sinon $remote_addr désignera ce proxy amont. Nginx fournit le module real IP pour cela. Restreignez l'accès direct à IIS pour empêcher le contournement du proxy.

Les étapes suivantes utilisent les champs de journalisation personnalisés d'IIS 8.5 et ultérieur. Configurez-les au niveau du site ; ils ne sont pas disponibles au niveau du serveur.

1. Ouvrez le Gestionnaire IIS, sélectionnez le site dans Connexions, puis double-cliquez sur Journalisation dans le groupe IIS.

   

2. La page Journalisation s'ouvre :

   

   Choisissez W3C dans Format. Sous Destination des événements de journal, choisissez Fichier journal uniquement ou Fichier journal et événement ETW pour fournir un fichier à RdpGuard. Cliquez sur Sélectionner les champs....

3. Dans Champs de journalisation W3C, cliquez sur Ajouter un champ... :

   

4. La boîte de dialogue Ajouter un champ personnalisé s'ouvre :

   

   Saisissez ces valeurs :

   • Nom du champ :X-Forwarded-For
   • Type de source :En-tête de requête
   • Source :X-Forwarded-For

   Utilisez exactement ce nom de champ pour que RdpGuard trouve la colonne. Cliquez sur OK dans les deux fenêtres, puis sur Appliquer dans le volet Actions.

Vérifier X-Forwarded-For dans les journaux IIS

Effectuez une requête via le proxy, puis ouvrez le journal le plus récent du site dans le dossier configuré, généralement %SystemDrive%\inetpub\logs\LogFiles, avec un sous-dossier W3SVC... par site. Les fichiers avec champs personnalisés portent le suffixe _x. Attendez l'écriture des entrées mises en mémoire tampon.

Vérifiez que #Fields: inclut X-Forwarded-For et que la valeur correspondante est l'IP du client. Cet exemple W3C abrégé montre le lien entre les deux champs d'adresse :

#Fields: date time c-ip cs-method cs-uri-stem sc-status X-Forwarded-For
2026-09-30 10:15:00 192.0.2.10 GET /login 200 203.0.113.45

Ici, 192.0.2.10 est le proxy enregistré dans c-ip, et 203.0.113.45 le client d'origine enregistré dans X-Forwarded-For. Votre journal peut contenir d'autres colonnes ; leur ordre est défini par sa ligne #Fields:.

Si la colonne manque, vérifiez les paramètres du site et le journal le plus récent. Si sa valeur est -, vérifiez que la requête est passée par le proxy et que celui-ci a envoyé l'en-tête.

Exécutez le tableau de bord RdpGuard en tant qu'administrateur, ouvrez les paramètres HTTP ou RD-WEB sous Protocoles surveillés, puis cliquez sur Paramètres avancés.... La fenêtre Paramètres HTTP avancés s'ouvre :

Activez Lire l'adresse IP du client dans le champ X-Forwarded-For. Pour HTTP, cette option concerne IIS. Si toutes les requêtes passent par le proxy, laissez Utiliser l'IP de connexion si X-Forwarded-For est absent décoché : le recours à c-ip peut bloquer le proxy lui-même. Cliquez sur OK, puis sur Enregistrer dans les paramètres du protocole.

Lire l'IP client ne change pas l'endroit où le blocage s'effectue. Une règle Windows pour cette IP n'arrête pas une connexion dont la source est le proxy. Bloquez les clients sur le proxy ou configurez les restrictions IP et domaine IIS avec le mode proxy et les actions RdpGuard, comme dans les guides HTTP et RD Web Access.