WAF pare-feu applicatif : définition, rôle et solutions

WAF : la définition du pare-feu applicatif web

Derrière le sigle se cache un filtre de sécurité. Un WAF, ou pare-feu applicatif web (WAF), se place entre les internautes et votre application web : il examine chaque requête, puis la laisse passer ou la bloque. Le sigle vient de l’anglais web application firewall. Dans la documentation des éditeurs, vous lirez aussi « application firewall », tout court.

Les câbles et les ports ouverts ? Ce type de pare-feu ne s’en occupe pas. Il travaille sur la couche applicative (la couche 7 du modèle OSI), celle où circulent les formulaires, les URL, les cookies et les échanges avec une API. Il comprend donc le contenu de ce que l’utilisateur envoie, et pas seulement son adresse.

Ce qui le distingue d’un pare-feu réseau

Adresse IP, port, protocole : un pare-feu réseau classique ne filtre que sur ces critères. Il autorise le port 443, celui du HTTPS, sans jamais regarder ce que contient la requête. Et une injection SQL glissée dans un champ de recherche ? Elle passe sans problème par ce port ouvert.

C’est précisément là que le WAF prend le relais. Il ouvre le paquet. Il lit les paramètres et repère les motifs dangereux. Les deux outils se complètent : l’un ferme les portes inutiles, l’autre contrôle ce qui entre par la porte principale.

Ce qu’il n’est pas

Ce n’est ni un antivirus, ni un système de prévention des intrusions généraliste. Un IPS surveille tout le trafic réseau d’une entreprise. Le WAF, lui, se concentre sur les échanges HTTP et HTTPS d’un site ou d’une application. Il ne corrige pas non plus les failles du code (autant le dire tout de suite) : il les rend seulement plus difficiles à exploiter.

À quoi sert un WAF pour votre application

Son rôle est de protéger l’application contre les attaques qui visent sa logique ou ses données. Concrètement, il bloque le trafic malveillant avant que les requêtes n’atteignent l’application. Pour un dirigeant, cela veut dire moins de risques de fuite du fichier clients, de site défiguré ou de boutique en ligne à l’arrêt.

Les menaces qu’un WAF peut protéger

Pour écrire leurs règles, les éditeurs partent des risques les plus fréquents, souvent ceux de l’OWASP Top 10. Bien réglé, le WAF peut protéger efficacement contre ces familles d’attaques :

• les attaques par injection, notamment l’injection SQL, qui cherche à lire ou à modifier votre base de données ;
• le cross-site scripting, qui insère un script dans une page pour voler la session d’un visiteur (voir notre article sur la faille XSS) ;
• l’inclusion de fichiers et la traversée de répertoires, deux moyens de lire des fichiers du serveur ;
• les tentatives de connexion répétées, cousines de l’attaque par force brute ;
• les robots de scraping ou de spam qui saturent vos formulaires ;
• une partie des attaques de saturation applicative, en complément d’une protection contre l’attaque DDoS.

Gagner du temps face aux nouvelles vulnérabilités

Prenons une faille découverte dans une extension WordPress ou dans une bibliothèque populaire. Combien de temps faut-il pour que le correctif soit publié, puis installé chez vous ? Parfois plusieurs jours, et pendant ce temps votre site reste exposé. Beaucoup de WAF reçoivent entre-temps une règle spécifique qui bloque l’exploitation de cette faille : c’est ce qu’on appelle un correctif virtuel.

Ce n’est pas pour autant une excuse pour repousser les mises à jour ! Voyez-le comme une marge de sécurité, qui assure la continuité du service le temps de corriger proprement.

Comment fonctionne un pare-feu applicatif web

Le principe tient en une phrase. Le WAF protège l’application web en analysant chaque requête HTTP, puis il décide : autoriser, bloquer, demander une vérification (un défi anti-robot, par exemple) ou simplement journaliser. Tout se joue ensuite dans la qualité des règles et dans leur réglage.

Les règles : liste noire, liste blanche ou mixte

Il existe deux grandes logiques, que les solutions actuelles combinent souvent :

• le modèle négatif, ou liste noire : le WAF connaît les signatures d’attaques et rejette tout ce qui leur ressemble (c’est le réglage le plus courant) ;
• le modèle positif, ou liste blanche : vous décrivez ce qui est permis, par exemple tel champ attend un code postal ou telle page n’accepte que des requêtes GET, et tout le reste est refusé ;
• l’approche mixte, qui ajoute des scores de risque : chaque élément suspect rapporte des points, et la requête est bloquée au-delà d’un seuil.

Les règles à base de signatures se déploient vite, mais elles peuvent laisser passer une attaque inédite. Les règles positives sont plus strictes. En revanche, elles demandent de bien connaître l’application. Une nouvelle génération de WAF ajoute de l’analyse comportementale pour repérer les usages anormaux : un visiteur qui teste des centaines d’URL en une minute ne se comporte pas comme un client ordinaire.

Où se place le WAF dans l’architecture

Dans la plupart des cas, le WAF fonctionne comme un proxy inverse. Une modification des DNS fait pointer votre nom de domaine vers lui plutôt que vers votre serveur web. Il reçoit la requête, la contrôle, puis la transmet au serveur si elle est saine.

Ce montage a un effet secondaire utile : l’adresse réelle du serveur est masquée. Encore faut-il configurer ce serveur pour qu’il n’accepte que le trafic venant du WAF. Sinon, un attaquant peut le contourner en visant directement l’adresse du serveur.

Ce que le WAF fait des requêtes bloquées

En général, une requête rejetée reçoit une réponse 403, l’un des codes de réponse HTTP standards. Elle est aussi enregistrée dans un journal avec l’adresse, la règle déclenchée et le contenu suspect. Ces journaux vous permettent de repérer les faux positifs et de suivre les intrusions tentées sur votre site.

Les solutions WAF : cloud, serveur ou intégrée

Il y a plusieurs façons de déployer un WAF. Le bon choix dépend de votre hébergement, de votre budget technique et de la personne qui gérera l’outil au quotidien. On distingue trois grandes familles de solutions.

Le WAF cloud

Le WAF cloud est un service hébergé par un prestataire, souvent couplé à un CDN. Vous changez vos DNS, vous activez un jeu de règles, et la protection est en place sans rien installer. Pour une TPE ou une PME qui n’a pas d’administrateur système en interne, c’est selon nous la formule la plus accessible.

Ses limites ? Vous dépendez du prestataire. Et certaines fonctionnalités avancées (règles personnalisées, analyse fine des robots) sont réservées aux offres supérieures.

Le WAF installé sur le serveur

Vous pouvez aussi installer un module directement sur le serveur web, comme ModSecurity avec le jeu de règles libre OWASP Core Rule Set. Le contrôle est total. En contrepartie, il faut des compétences pour l’installer, l’ajuster et le maintenir. Cette option convient donc surtout aux équipes qui gèrent déjà leur propre infrastructure.

Le WAF intégré à l’hébergement ou au CMS

Certains hébergeurs incluent un pare-feu applicatif dans leurs offres, et des extensions WordPress jouent ce rôle au niveau du site. Ces extensions sont pratiques. Mais elles s’exécutent une fois que la requête a déjà atteint le serveur et chargé WordPress, si bien qu’elles protègent moins bien qu’un filtre placé en amont. Voyez-les comme un complément aux bonnes pratiques pour sécuriser WordPress.

• votre site tourne sur un hébergement mutualisé : commencez par un WAF cloud ;
• vous avez une application métier sur un serveur dédié : choisissez un WAF serveur ou cloud avec des règles personnalisées ;
• vous avez une boutique en ligne : privilégiez une solution qui gère aussi les robots et les pics de trafic ;
• personne ne regarde les journaux : prenez l’offre la plus simple, car une protection mal suivie vaut moins qu’une protection basique bien suivie.

Exemple concret : une boutique en ligne attaquée par injection

Imaginons une PME qui vend du matériel professionnel sur son site e-commerce. Son moteur de recherche interne transmet le texte saisi à la base de données. Un jour, un robot se met à envoyer des recherches qui contiennent des fragments de code SQL, dans l’espoir de récupérer la table des clients.

Ce scénario montre bien la place du WAF : il arrête l’attaque à l’entrée, mais la vraie correction se fait dans le code. C’est pourquoi, quand nous menons une création de site internet, nous traitons les deux niveaux : un code qui filtre ses entrées et une couche de protection devant le serveur.

Les erreurs courantes avec un WAF

Mal configuré, un pare-feu applicatif donne une fausse impression de sécurité. Voici les pièges que nous rencontrons le plus souvent chez les PME.

Activer le blocage sans phase d’observation

Si vous passez directement en mode blocage, vous risquez de casser des fonctions légitimes : un formulaire de devis refusé, un paiement qui échoue, un back-office inaccessible. Notre méthode ? Lancer le WAF en mode détection pendant quelques jours, lire les journaux et ajuster les règles. Ensuite seulement, activer le blocage.

Laisser le serveur joignable en direct

Si l’adresse IP du serveur reste accessible, un attaquant peut ignorer le WAF et viser directement la machine. Limitez l’accès au serveur aux seules adresses du WAF. Le réglage est simple, et pourtant souvent oublié.

Croire que le WAF remplace le reste

Le WAF ne remplace ni les mises à jour, ni un code propre, ni l’authentification forte, ni les sauvegardes. Contre un mot de passe administrateur volé, il ne peut rien non plus. C’est une couche parmi d’autres : elle est utile parce qu’elle s’ajoute aux autres, pas parce qu’elle les remplace.

Ne jamais relire les journaux

Un WAF installé puis oublié perd vite de sa valeur. Les règles évoluent, et le site aussi : une nouvelle page ou un nouveau module peut provoquer des faux positifs, voire ouvrir une brèche non couverte. Souvent, un coup d’œil régulier aux alertes suffit pour repérer un problème avant qu’il ne vous coûte des ventes.

Questions fréquentes