Protection contre les scans de vulnérabilités HTTP

• Présentation de la protection HTTP
• Activer la protection HTTP
• Règles de détection
• Paramètres avancés

RdpGuard surveille les journaux d'accès Microsoft IIS, Apache HTTP Server et nginx pour détecter des indices de scan de vulnérabilités : requêtes répétées vers des pages absentes, recherche d'identifiants exposés ou de fichiers de dépôt. Lorsque les détections d'une IP atteignent le seuil configuré, RdpGuard la bloque temporairement.

La protection HTTP utilise des règles de détection pour identifier les requêtes suspectes. Commencez avec les règles standard, puis adaptez-les aux chemins et applications hébergés. Si vos sites sont derrière un proxy inverse, vérifiez aussi les paramètres du proxy pour identifier et bloquer le client d'origine.

1. Ouvrez le tableau de bord RdpGuard et cliquez sur HTTP sous Protocoles surveillés.

   

   La boîte de dialogue Paramètres de protection HTTP s'ouvre :

   

2. Cochez Activer la protection HTTP et choisissez votre Serveur web : Microsoft IIS, Apache HTTP Server ou nginx.

3. Cliquez sur Ajouter... et sélectionnez les dossiers des journaux d'accès. Vous pouvez en ajouter plusieurs. Sélectionnez une entrée pour la Modifier... ou la Supprimer.

4. Laissez Remplacer les règles de détection standard décoché pour utiliser les règles par défaut, puis cliquez sur Enregistrer. Vérifiez les erreurs de surveillance dans Affichage, Afficher le journal d'événements.

Dossiers des journaux IIS

Sélectionnez le dossier de chaque site, par exemple C:\inetpub\logs\LogFiles\W3SVC1. Le nombre après W3SVC est l'identifiant du site IIS. Choisissez le dossier contenant les fichiers journaux, pas le parent LogFiles : RdpGuard ne parcourt pas les sous-dossiers.

Activez les journaux W3C dans IIS. Incluez Client IP Address (c-ip), URI Stem (cs-uri-stem) et HTTP Status (sc-status) pour les règles standard. Les règles personnalisées peuvent nécessiter d'autres champs, détaillés ci-dessous.

Dossiers des journaux d'accès Apache

Sélectionnez le dossier configuré dans Apache, par exemple C:\Apache24\logs. Ajoutez chaque dossier séparément ; les sous-dossiers ne sont pas parcourus. RdpGuard accepte les formats Common et Combined, avec une IP client numérique dans le premier champ. Combined inclut aussi Referer et User-Agent, nécessaires aux règles qui les utilisent. Consultez la documentation des journaux Apache.

Dossiers des journaux d'accès nginx

Sélectionnez nginx comme serveur web et ajoutez le dossier des journaux, par exemple C:\nginx\logs. Les sous-dossiers ne sont pas parcourus. Utilisez le format combined par défaut de nginx, avec une IP client numérique en premier champ. Il inclut tous les champs pris en charge par les règles HTTP.

access_log logs/access.log combined;

RdpGuard traite l'échappement \xXX par défaut de nginx, y compris le texte UTF-8. Les formats personnalisés avec des champs supplémentaires ou réordonnés, les journaux JSON et les fichiers compressés ne sont pas pris en charge. Consultez la documentation des journaux nginx.

Cochez Remplacer les règles de détection standard pour les modifier. Votre jeu personnalisé remplace les règles standard, il ne les complète pas. Conservez les règles standard nécessaires dans votre jeu, ou décochez l'option pour rétablir les valeurs par défaut.

Saisissez une règle par ligne. Une ligne commençant par # est un commentaire. Chaque règle contient des conditions séparées par des virgules, avec = pour une correspondance et != pour une exclusion. Les valeurs respectent la casse ; * représente une suite quelconque de caractères et ? un seul caractère.

Uri=/*.zip,Uri!=/download/*

Cet exemple cible les fichiers ZIP, sauf sous /download/. Toutes les conditions d'une ligne doivent correspondre (ET) ; n'importe quelle règle correspondante peut produire une détection (OU). Une requête peut correspondre à plusieurs règles et compter pour chacune : des règles qui se recoupent peuvent donc produire plusieurs détections pour une seule requête.

Champs pris en charge et noms IIS W3C correspondants :

• Method - Méthode HTTP, par exemple GET ou POST (cs-method).
• Uri - Chemin demandé, sans chaîne de requête (cs-uri-stem).
• Query - Chaîne de requête, sans le ? initial (cs-uri-query).
• UserName - Nom d'utilisateur authentifié (cs-username).
• UserAgent - Valeur User-Agent du client (cs(User-Agent)).
• Referer - URL référente (cs(Referer)).
• Status - Code de statut HTTP, par exemple 404 (sc-status).

Vérifiez que le format du journal inclut les champs utilisés par vos règles. Le format Apache Common ne contient ni Referer ni User-Agent ; utilisez Combined pour les règles qui en dépendent.

Seuil

Sans Threshold, chaque requête correspondante produit une détection pour la règle. Ajoutez un entier positif pour regrouper plusieurs correspondances d'une même IP en une détection. Exemple :

Status=404,Threshold=15

Cette règle produit une détection toutes les 15 réponses HTTP 404 pour une même IP. Elle ne bloque pas seule après 15 requêtes : le blocage dépend toujours du seuil configuré dans RdpGuard. Avec un seuil de 3 et aucune autre règle contributrice, il faut 45 requêtes correspondantes, si les compteurs n'ont pas été réinitialisés.

Un seuil évite de traiter un lien cassé occasionnel comme un scan. Pour un chemin sans usage légitime sur votre site, vous pouvez choisir une règle sans seuil. Configurez la limite de blocage et le délai de remise à zéro dans Outils, Options, onglet Général.

Exemples de règles

Les règles suivantes correspondent au jeu standard actuel. Les vérifications d'archives et de WordPress sont commentées. Activez-les seulement si ces chemins doivent être considérés comme des scans sur vos sites, pour éviter de bloquer des visiteurs légitimes.

# Count every 15 HTTP 404 responses as one detection
Status=404,Threshold=15

# Scan for secrets, environment files and repository metadata
Uri=*/.aws*
Uri=*/.env*
Uri=*/.git*
Uri=*/.hg/*
Uri=*/.svn*
Uri=*/.vscode*

# Optional: archive scans (check your legitimate downloads first)
#Uri=/*.bz2
#Uri=/*.tar.gz
#Uri=/*.tgz
#Uri=/*.7z
#Uri=/*.zip,Uri!=/download/*
#Uri=/*.rar

# Optional: WordPress scans (leave disabled if you use WordPress)
#Uri=*/wp-content/*
#Uri=*/wp-admin/*
#Uri=*/wp-includes/*
#Uri=*/wp-json/*
#Uri=*/wp-config*
#Uri=*/wp-login.php*

Cliquez sur Paramètres avancés... dans la protection HTTP pour ouvrir Paramètres HTTP avancés. Les options X-Forwarded-For ci-dessous concernent les journaux IIS.

Lire l'adresse IP du client dans le champ X-Forwarded-For

Par défaut, RdpGuard lit Client IP Address (c-ip) dans le journal IIS. Derrière un proxy inverse, il s'agit généralement du proxy. Activez cette option pour utiliser X-Forwarded-For. S'il contient plusieurs adresses, RdpGuard utilise la première.

Configurez le proxy de confiance pour transmettre l'IP réelle et empêcher les clients d'injecter leur propre première adresse dans l'en-tête. Restreignez l'accès direct à IIS pour empêcher le contournement du proxy. Consultez la configuration IIS derrière un proxy pour la journalisation.

Utiliser l'IP de connexion si X-Forwarded-For est absent

Activez cette option pour utiliser c-ip si X-Forwarded-For manque. Laissez-la désactivée si toutes les requêtes passent par un proxy : ce recours peut entraîner le blocage du proxy lui-même.

Cliquez sur OK, puis sur Enregistrer dans la protection HTTP pour appliquer les changements.

Pour Apache, RdpGuard lit l'IP dans le premier champ de chaque entrée ; ces cases X-Forwarded-For ne concernent pas Apache. Configurez Apache pour y écrire l'IP d'origine avec un proxy de confiance, par exemple via mod_remoteip.

Pour nginx, RdpGuard utilise aussi le premier champ ($remote_addr au format combined standard). Les cases X-Forwarded-For ne concernent pas nginx. Derrière un proxy, configurez une relation de confiance pour que ce champ contienne l'IP du client d'origine.

Bloquer les requêtes avec X-Forwarded-For

Lire X-Forwarded-For identifie le client sans changer l'endroit où le blocage s'effectue. Si la connexion vient d'un proxy inverse, une règle de pare-feu Windows ciblant l'IP du client ne bloquera pas cette connexion relayée.

Bloquez le client au niveau du proxy. Avec IIS, vous pouvez aussi utiliser Restrictions par adresse IP et domaine, le Mode proxy et les actions personnalisées de RdpGuard, comme ci-dessous.

Configurer les actions personnalisées dans RdpGuard

Cet exemple ajoute et supprime des entrées de refus IPv4 pour un site IIS. Dans les deux commandes, remplacez Your Web Site par le nom du site dans le gestionnaire IIS.

1. Installez le service de rôle IIS Restrictions par adresse IP et domaine si nécessaire.
2. Dans le Gestionnaire IIS, sélectionnez le site, ouvrez Restrictions par adresse IP et domaine, cliquez sur Modifier les paramètres de fonctionnalité... et cochez Activer le mode proxy. IIS 8.0 ou ultérieur est requis. Consultez la documentation IP Security de Microsoft.
3. Exécutez le tableau de bord RdpGuard en tant qu'administrateur, ouvrez Outils, Actions personnalisées / Notifications et ajoutez les deux actions suivantes.

Action IP bloquée

• Événement : IP bloquée
• Tâche : Exécuter un programme
• Chemin :C:\Windows\System32\inetsrv\appcmd.exe

Arguments :

set config "Your Web Site" /section:system.webServer/security/ipSecurity /+"[ipAddress='%IP%',allowed='false']" /commit:apphost

Action IP débloquée

• Événement : IP débloquée
• Tâche : Exécuter un programme
• Chemin :C:\Windows\System32\inetsrv\appcmd.exe

Arguments :

set config "Your Web Site" /section:system.webServer/security/ipSecurity /-"[ipAddress='%IP%']" /commit:apphost

Enregistrez les actions. Après un blocage déclenché par une détection locale, vérifiez que l'entrée de refus apparaît pour le site et que les requêtes du client sont refusées via le proxy. Lors du déblocage, la seconde action supprime l'entrée.

Ces actions traitent les futurs événements IP bloquée et IP débloquée issus de détections locales ; elles ne synchronisent ni la liste déjà bloquée, ni les adresses bloquées uniquement par IP Cloud.