Pare-feu applicatif (WAF)
Filtrer les requêtes avant qu'elles n'atteignent ton application.
Le WAF s'applique aux domaines servis par le reverse proxy. Les règles sont traduites en configuration nginx et appliquées sur le node : une requête refusée n'atteint jamais ton conteneur.
Jeux de règles fournis#
Le plus rapide est d'activer un jeu prêt à l'emploi depuis Sécurité → WAF.
| Jeu | Ce qu'il bloque | Risque |
|---|---|---|
| Injection SQL | Mots-clés SQL enchaînés dans l'URL ou les paramètres. | sans risque |
| Cross-site scripting | Balises et gestionnaires d'événements injectés. | à surveiller |
| Exécution de commandes | Enchaînements de commandes shell dans les paramètres. | sans risque |
| Log4Shell et injections JNDI | Chaînes ${jndi:…} qui font charger du code à distance par une application Java, variantes obfusquées comprises. | sans risque |
| Portes dérobées et webshells | Noms de webshells connus (c99, r57, wso…) et exécution de code PHP en paramètre. | sans risque |
| Traversée de répertoire | Tentatives de remonter l'arborescence (../, encodages inclus). | sans risque |
| Fichiers sensibles | Accès direct à .env, .git, dumps SQL… | sans risque |
| SSRF et métadonnées cloud | Paramètres pointant vers l'intérieur : 169.254.169.254, localhost, adresses privées, file://. | à surveiller |
| Scanners | Signatures d'outils connus (sqlmap, nikto, nmap…). | sans risque |
| Sondages d'administration | Balayage de wp-admin, phpMyAdmin, .git/config, /actuator… | à tester d'abord |
| Collecteurs de contenu | Aspirateurs et bibliothèques laissées à leur agent par défaut (wget, curl, scrapy…). | à tester d'abord |
| Anomalies de protocole | Octets nuls, doubles encodages, retours à la ligne injectés dans l'URL. | sans risque |
Des motifs volontairement resserrés
Lis la colonne « Risque »
curl et python-requests, donc tes propres intégrations et tes sondes de supervision — sur une API, préfère l'action « Vérifier ».Un jeu s'active sur le domaine affiché, ou sur tous tes domaines d'un coup avec le lien sous sa description : une injection SQL ne vise pas un site en particulier, et personne ne réactive la même protection sur douze domaines à la main.
Bloquer, ou seulement observer#
Chaque domaine a un mode, en haut de la page. En observation, les règles ne refusent RIEN : elles écrivent au journal ce qu'elles auraient bloqué, limites de débit comprises.
C'est la façon d'allumer un pare-feu sur un site vivant : on regarde deux jours ce qui aurait été cassé dans les évènements, on ajoute les exceptions nécessaires, puis on bascule en blocage en sachant ce qu'on fait — au lieu de l'apprendre par un client au téléphone.
Le mode ne touche pas aux règles
Tester une requête avant qu'un visiteur ne le fasse#
Le simulateur, sur la même page, répond à « que ferait le pare-feu de cette requête ? ». Tu donnes un chemin et un agent utilisateur — ou tu cliques un exemple — et il rend le verdict, la règle qui a décidé, et la valeur exacte qui a été comparée.
Rien n'est envoyé à ton application
C'est une simulation, pas nginx
Règles sur mesure#
Une règle inspecte un élément de la requête et agit dessus.
- Élément inspecté : chemin, URL et paramètres, agent utilisateur, en-tête HTTP, méthode, ou adresse IP.
- Comparaison : contient, égal, commence par, finit par, ou expression régulière.
- Action : bloquer (403) ou autoriser.
Une règle « Autoriser » l'emporte toujours
Quelle que soit sa priorité. C'est ainsi qu'on écrit une exception : laisser passer une API interne qu'un jeu fourni gênerait, par exemple.
Règle 1 — en-tête X-Api-Key égal à « secret-interne » → Autoriser
Règle 2 — jeu « Injection SQL » → Bloquer
Une requête portant la bonne clé passe, même si elle déclenche le jeu SQL.Profils de filtrage (par domaine)#
À côté des règles sur mesure, chaque domaine choisit un profil depuis Sécurité → Filtres. C'est un réglage à part : les règles ci-dessus sont des conditions que tu écris, un profil est un jeu de contrôles tout prêt, appliqué avant elles.
| Profil | Ce qu'il examine | Latence |
|---|---|---|
| Auto | Suit la posture du domaine : le Bouclier rapide si Renforcé, rien sinon. | — |
| Aucun | Rien. Seules les limites de débit de base s'appliquent. | aucune |
| Bouclier rapide | Méthode, agent utilisateur, chemin, taille des en-têtes — des valeurs déjà en mémoire. | aucune |
| Inspection profonde | Tout ce qui précède, plus l'URL, les paramètres, les cookies, le référent ET le corps de la requête : SQL, XSS, traversée de répertoire, commandes shell. | notable |
« Auto » et « Aucun » ne sont pas la même chose
Auto veut dire « je n'ai rien décidé, suis la posture » ; Aucun est un choix explicite qui l'emporte sur la posture. Un domaine en Renforcé qui choisit Aucun conserve les limites de débit resserrées de sa posture, mais plus le filtre applicatif. Tant que les deux se confondaient, le clic sur Aucun n'avait aucun effet visible.La limite réelle de l'inspection profonde
Ce que ce WAF ne fait pas#
Dit ici plutôt que découvert à l'usage :
- Les règles sur mesure n'inspectent pas le corps des requêtes. Seule l'Inspection profonde le fait, avec la limite de tampon ci-dessus.
- Pas d'action « journaliser sans bloquer ». Elle exigerait de modifier le format de journal que l'agent analyse pour les statistiques du proxy.
Suivre les blocages#
Les requêtes refusées remontent dans Sécurité : compteur sur 14 jours, et détail des derniers blocages (adresse, méthode, chemin, agent utilisateur).
La remontée exige un agent 2.16.0 ou plus récent
Si une règle ne semble pas s'appliquer#
La configuration est validée par nginx avant d'être adoptée. Si elle est refusée, l'agent conserve la précédente — le site continue donc de fonctionner, mais la nouvelle règle n'a aucun effet. Une erreur apparaît alors dans Admin → Agents. C'est le premier endroit à regarder après avoir créé une règle qui ne fait rien.
Voir aussi Sécurité pour le durcissement des nodes et le filtrage d'adresses, et Domaines & reverse proxy pour l'anti-DDoS et les en-têtes de sécurité.