Configurer un WAF sans casser les fonctions métier

Un pare-feu applicatif web (WAF, Web Application Firewall) ne se déploie pas en mode bloquant sur une application inconnue. Le compromis central est brutal : augmenter la détection réduit l’exposition aux attaques connues, mais augmente aussi le risque de bloquer des flux métier valides. La bonne réponse n’est pas une règle plus permissive, c’est un cycle d’observation, de qualification et d’exceptions étroites.

→ Lire l’explication complète de la marmotte

Mode observation du WAF avant tout blocage

Le WAF analyse les requêtes Hypertext Transfer Protocol (HTTP) et les réponses avant leur traitement par l’application. Il cherche des signatures d’attaque, des structures suspectes et des anomalies de protocole : injection Structured Query Language (SQL), scripts injectés dans une page, traversée de répertoires, désérialisation dangereuse ou encodages ambigus.

Commencer en mode détection uniquement. Toute autre stratégie revient à faire passer un filtre métier devant une application sans connaître son trafic réel. Les règles du Core Rule Set (CRS), le jeu de règles maintenu par l’Open Web Application Security Project (OWASP), contiennent des protections efficaces mais génériques. Une règle générique ne sait pas qu’un champ commentaire reçoit du code, qu’une interface d’administration accepte des expressions régulières ou qu’un import reçoit du JavaScript Object Notation (JSON) signé.

La période d’observation doit couvrir les parcours authentifiés, les traitements planifiés, les intégrations tierces et les opérations rares mais critiques : import, export, recherche avancée, dépôt de fichier, administration et récupération de compte. Tester uniquement la page d’accueil est une manière élégante de protéger un hall vide.

Activer la journalisation des événements pertinents avec les éléments nécessaires à l’analyse : identifiant de règle, phase, score d’anomalie, méthode HTTP, chemin, paramètre concerné, code de réponse applicatif, identité technique pseudonymisée et identifiant de corrélation. Ne pas journaliser les corps complets par défaut. Les requêtes transportent fréquemment mots de passe, jetons d’accès, données personnelles ou secrets d’intégration. Un WAF bavard peut devenir une fuite de données avec un joli tableau de bord.

Corréler les alertes avec les journaux du proxy inverse, de l’application et du fournisseur d’identité. Un événement isolé n’indique pas forcément un faux positif. Une requête rejetée par l’application avec un code 400 ou 422, suivie d’un événement WAF sur le même identifiant de requête, indique souvent un client malformé. Une réponse 200 accompagnée d’une alerte sur une fonctionnalité attendue mérite au contraire une qualification métier.

Le score d’anomalie est préférable au blocage immédiat par signature lorsque plusieurs catégories de trafic existent. Avec le CRS, chaque règle ajoute un score ; le WAF bloque lorsque le seuil est atteint. Abaisser ce seuil augmente la détection mais fait remonter les faux positifs. La recommandation est de conserver le seuil par défaut pendant l’observation, puis de corriger les exclusions avant d’envisager son abaissement. Descendre le seuil pour compenser des exclusions absentes fabrique une alarme incendie qui sonne quand quelqu’un fait griller une tartine.

Calibrage progressif des règles et des scores

Traiter chaque événement observé dans une matrice de décision : attaque confirmée, trafic légitime, client défectueux ou cas indéterminé. Un événement indéterminé reste en observation, il ne justifie ni exclusion ni blocage définitif. L’incertitude est un état opérationnel, pas une invitation à ajouter allow partout.

Pour un faux positif confirmé, préférer une exclusion ciblée selon cet ordre :

retirer une règle pour un paramètre précis ;
retirer une règle pour une route précise et une méthode précise ;
ajuster la transformation ou la limite de taille si la cause est documentée ;
retirer une règle globalement seulement si son signal est inutilisable sur toute l’application.

Une exception doit contenir quatre dimensions lorsque le protocole le permet : chemin, méthode, paramètre et identité de règle. Exclure la règle d’injection SQL uniquement sur POST /api/import et le champ filtre est défendable si ce champ accepte réellement une syntaxe riche. Exclure cette règle sur /api/ transforme une correction chirurgicale en permission de construire une autoroute.

Ne jamais utiliser l’adresse IP source comme critère principal de whitelist pour un navigateur ou un partenaire Internet. Les adresses changent, passent par des réseaux de traduction d’adresses et peuvent être partagées. Une authentification applicative, un certificat client Transport Layer Security (TLS), une identité de charge de travail ou une route dédiée sont des ancrages plus fiables. L’adresse source reste un signal complémentaire, pas une identité. Les présentations commerciales appellent cela du zero trust après trois icônes de cadenas ; le réseau, lui, continue de mentir poliment.

Les exclusions doivent être versionnées avec la configuration du WAF, relues par un responsable applicatif et testées avec des requêtes positives et négatives. Une requête positive valide le parcours métier. Une requête négative reprend la charge hostile que la règle devait détecter. Sans test négatif, l’exclusion peut neutraliser la protection entière tout en faisant passer la recette avec une grâce très administrative.

Calibrer aussi les limites protocolaires : taille maximale de corps, nombre d’arguments, profondeur JSON, durée d’analyse, encodages autorisés et méthodes HTTP acceptées. Ces limites protègent contre les abus de ressources, mais elles cassent facilement les imports, les téléversements et certaines interfaces de recherche. Les fixer à partir des maxima applicatifs connus, puis ajouter une marge documentée. Une limite de 1 mégaoctet appliquée à un dépôt de fichier de 50 mégaoctets n’est pas du durcissement, c’est une spécification cachée.

Whitelist des usages légitimes avant le mode bloquant

Une whitelist n’est pas une liste de clients sympathiques. C’est une exception explicitement liée à un cas d’usage, avec un propriétaire, une justification, un périmètre et une date de révision. Chaque entrée doit répondre à quatre questions : quelle route est concernée, quelle règle est contournée, quelle donnée légitime déclenche l’alerte, quelle protection compense l’exclusion.

Les cas d’usage légitimes les plus fréquents sont prévisibles :

éditeurs de texte enrichi qui acceptent des balises Hypertext Markup Language (HTML) ;
interfaces d’administration qui transmettent scripts, requêtes ou expressions régulières ;
passerelles d’interface de programmation applicative (API) qui reçoivent des jetons signés contenant des caractères inhabituels ;
imports CSV ou JSON contenant des chaînes qui ressemblent à des signatures d’injection ;
outils de supervision qui envoient des charges volumineuses ou des paramètres techniques non normalisés.

Une route qui accepte du HTML ne doit pas être exemptée de toute inspection. Restreindre le contournement au paramètre de contenu, conserver les contrôles de taille et de type de média, puis imposer une neutralisation côté application avant restitution. Le WAF ne remplace pas l’encodage contextuel de sortie. Il peut bloquer une attaque connue, pas prouver qu’une chaîne sera rendue sans danger dans chaque navigateur.

Les exceptions sont évaluées avant le blocage, donc leur ordre compte. Définir les exclusions locales avant l’activation globale du moteur, puis vérifier que les règles retirées sont bien celles attendues. Une whitelist appliquée après une règle bloquante ne corrige rien, sauf la documentation de l’incident.

Exemple ModSecurity avec exclusion ciblée

Cet exemple utilise ModSecurity avec le jeu OWASP Core Rule Set. Les identifiants de règles doivent correspondre à la version réellement chargée : les recopier d’un billet daté est une tradition du secteur, pas une méthode de configuration.

# Démarrer en observation : les règles journalisent sans bloquer.
SecRuleEngine DetectionOnly

# Conserver les alertes ayant atteint un niveau utile pour le triage.
SecAuditEngine RelevantOnly
SecAuditLogFormat JSON

# Cas métier : le champ "filtre" accepte une syntaxe de requête avancée.
# L'exclusion vise POST, une route et un paramètre, pas toute l'API.
SecRule REQUEST_METHOD "@streq POST" \
  "id:100100,phase:1,pass,nolog,chain"
    SecRule REQUEST_URI "@streq /api/v1/recherche" \
      "chain"
        SecRule ARGS:filtre "@rx ." \
          "ctl:ruleRemoveTargetById=942100;ARGS:filtre"

# Vérifier la syntaxe Nginx avant rechargement.
# nginx -t

Après validation du faux positif, conserver la règle CRS 942100 sur tous les autres paramètres. Ajouter un test automatisé qui envoie une expression légitime dans filtre, puis une charge d’injection dans un paramètre différent. Si la seconde passe, l’exclusion est trop large.

Pour passer en blocage, remplacer DetectionOnly par On, d’abord sur une instance ou un sous-ensemble de trafic réversible. Le déploiement canari doit préserver l’affinité de session si l’application dépend d’état local. Sinon, le diagnostic mélange blocage WAF et perte de session, cocktail connu pour produire des tickets sans cause identifiable.

Surface d’attaque et garanties absentes du WAF

Un WAF placé derrière un réseau de diffusion de contenu ou un proxy inverse doit recevoir l’adresse client dans un en-tête approuvé uniquement depuis ces équipements. Faire confiance à X-Forwarded-For depuis Internet permet à un attaquant de choisir son adresse source. Les mécanismes de réputation, de limitation ou de whitelist deviennent alors décoratifs, avec beaucoup de JSON autour.

Le WAF est exposé au contournement par encodage multiple, fragmentation de paramètres, différences de normalisation entre proxy et application, requêtes HTTP ambiguës et charges chiffrées qu’il ne termine pas. La terminaison TLS est donc une dépendance : sans déchiffrement au point d’inspection, le WAF ne voit pas le contenu applicatif. Consulter les principes de sécurité réseau et les contraintes de TLS et PKI avant de déplacer cette terminaison.

Le WAF ne garantit pas :

l’absence de vulnérabilité dans le code ;
la correction des contrôles d’autorisation ;
la protection contre un compte légitime compromis ;
la détection de toute logique métier abusive ;
la sécurité des dépendances ou des images de conteneur ;
la disponibilité face à une saturation volumétrique supérieure à sa capacité.

Le reste doit venir de l’authentification forte, des contrôles d’accès applicatifs, de la validation de schéma, du durcissement des identités, de tests de sécurité et de protections réseau contre le déni de service. Bloquer ../ ne répare pas une autorisation horizontale absente. C’est moins spectaculaire qu’un tableau de bord rouge, mais c’est le problème réel.

Exploitation, rotation et reprise du WAF

Le WAF dépend de secrets : certificats TLS, clés privées, jetons d’interface d’administration, identifiants d’envoi vers la supervision et, parfois, clés de vérification de signatures. Stocker ces secrets dans un gestionnaire dédié ; ne pas les placer dans les règles, variables d’environnement affichables ou dépôts de configuration. Prévoir rotation, double chargement de certificat et révocation des accès d’administration.

Superviser le taux de blocage par route, règle, code de réponse, version de configuration et identité applicative. Une hausse brutale après une livraison indique souvent une incompatibilité de format. Une baisse brutale peut indiquer que le moteur n’inspecte plus les corps ou que le journal est perdu. Les deux cas méritent une alerte.

Sauvegarder la configuration versionnée, les exceptions validées, les certificats publics et les procédures de retour arrière. Les journaux de sécurité doivent avoir une durée de conservation définie, un contrôle d’accès et une horodatation synchronisée. Une reprise sans configuration d’exclusion remet en service un WAF théoriquement protégé, pratiquement indisponible. Le pare-feu ne doit jamais devenir le composant qui protège l’application de ses utilisateurs.

🐝 Ce qui arrive si on s’en passe

Sans WAF calibré en service, chaque requête hostile atteint directement le code applicatif, et la seule barrière restante est l’absence de défaut dans ce code. Entre la publication d’une vulnérabilité touchant un composant exposé et le déploiement du correctif, aucun correctif virtuel ne peut filtrer la charge connue : la fenêtre d’exploitation dure autant que le cycle de livraison. La phase de reconnaissance devient aussi invisible : les balayages automatisés, les essais successifs d’injection ou de traversée de répertoires ne produisent aucun score d’anomalie ni identifiant de règle, donc aucune corrélation possible avec les journaux applicatifs avant l’exploitation réussie. Un attaquant peut ajuster ses charges à volonté sans jamais déclencher de refus, et l’enquête après incident ne dispose que des traces applicatives, souvent muettes sur le contenu des requêtes rejetées ou acceptées.

🦫 Explication de la marmotte 🍫

Un pare-feu applicatif web examine les demandes envoyées à un site avant qu’elles atteignent le programme qui sert le site. Il compare leur contenu à des règles qui repèrent des formes fréquentes d’attaque, par exemple du texte conçu pour modifier une base de données ou afficher du code dangereux dans une page.

Au début, il ne doit pas refuser les demandes : il les note. Cette période permet de voir quelles actions normales ressemblent par erreur à une attaque. Un formulaire de recherche avancée, un fichier importé ou un outil d’administration peuvent contenir des caractères suspects tout en étant autorisés.

Chaque alerte est alors examinée. Si la demande est réellement dangereuse, la règle reste active. Si elle est normale, on crée une exception limitée à une adresse précise du site, à une action précise et au champ concerné. Il ne faut pas désactiver une protection pour tout le site, car une vraie attaque pourrait alors passer par une autre page.

Après ces corrections, le pare-feu commence à bloquer. Il faut continuer à surveiller les refus et les erreurs, car une nouvelle version de l’application peut changer le format des demandes. Le pare-feu ne corrige pas les défauts du programme, ne vérifie pas à lui seul les droits des utilisateurs et ne protège pas un compte déjà volé. Il ajoute un contrôle, il ne remplace pas le reste de la sécurité.

Pages voisines

La citent

Configurer un WAF sans casser les fonctions métier

Elle cite

Configurer un WAF sans casser les fonctions métier

Configurer un WAF sans casser les fonctions métier

Mode observation du WAF avant tout blocage

Calibrage progressif des règles et des scores

Whitelist des usages légitimes avant le mode bloquant

Exemple ModSecurity avec exclusion ciblée

Surface d’attaque et garanties absentes du WAF

Exploitation, rotation et reprise du WAF

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines