Pare-feu applicatif web (WAF) : rôle et fonctionnement

Vous avez probablement vu des alertes concernant des injections SQL, des scripts intersites ou des attaques de bots ciblant votre application web. Bien que le codage sécurisé et les correctifs réguliers soient essentiels, ils ne suffisent pas toujours. Un pare-feu applicatif web (WAF) ajoute une couche de défense critique en inspectant le trafic HTTP et en bloquant les requêtes malveillantes avant qu'elles n'atteignent votre application. Dans cet article, nous expliquons ce que fait un WAF, comment il fonctionne en interne, et comment le déployer et l'ajuster efficacement.

Qu'est-ce qu'un pare-feu applicatif web ?

Un WAF est une solution de sécurité qui surveille, filtre et bloque le trafic HTTP/HTTPS entrant et sortant d'une application web. Contrairement aux pare-feu réseau traditionnels qui opèrent aux couches 3 et 4 (IP et TCP), un WAF travaille à la couche 7, la couche applicative. Il comprend les méthodes HTTP, les en-têtes, les cookies, les chaînes de requête et les corps de requête. Cela lui permet de détecter et de bloquer des attaques qui semblent être du trafic normal pour un pare-feu réseau.

Les WAF sont couramment utilisés pour se protéger contre :

• L'injection SQL (SQLi)
• Les scripts intersites (XSS)
• La falsification de requête intersites (CSRF)
• L'inclusion de fichiers et la traversée de répertoires
• Les vulnérabilités connues des CMS (par exemple, les extensions WordPress)
• Les mauvais bots, les scrapers et les attaques DDoS au niveau applicatif

Comment fonctionne un WAF

Globalement, un WAF se place entre le client et votre serveur web. Lorsqu'une requête arrive, le WAF l'inspecte par rapport à un ensemble de règles ou de politiques. Si la requête correspond à une règle indiquant une attaque, le WAF peut la bloquer, la journaliser ou lancer un défi au client. Sinon, la requête est transmise à l'application.

Il existe trois principales techniques de détection :

• Basée sur les signatures : Compare les requêtes à une base de données de motifs d'attaque connus (par exemple, UNION SELECT dans une chaîne de requête). Rapide mais peut manquer de nouvelles attaques.
• Basée sur les anomalies : Apprend le comportement normal du trafic et signale les écarts. Meilleure pour les zero-days mais peut produire des faux positifs.
• Basée sur la réputation : Utilise la réputation IP, la géolocalisation et les renseignements sur les menaces pour bloquer les acteurs malveillants connus.

La plupart des WAF combinent ces méthodes. Par exemple, ModSecurity avec l'OWASP Core Rule Set (CRS) utilise des signatures et un score d'anomalie pour attribuer un score de menace à chaque requête. Si le score dépasse un seuil, la requête est bloquée.

Modes de fonctionnement

Un WAF peut fonctionner selon deux modes principaux :

• Mode surveillance (ou détection seule) : Journalise les requêtes suspectes mais ne les bloque pas. Utile lors du déploiement initial pour ajuster les règles et éviter de bloquer le trafic légitime.
• Mode blocage (ou prévention) : Bloque activement les requêtes qui violent les règles. C'est l'objectif après l'ajustement.

Certains WAF proposent également un mode défi, où les clients suspects doivent résoudre un CAPTCHA ou un défi JavaScript avant de continuer.

Options de déploiement

Vous pouvez déployer un WAF de plusieurs façons, chacune avec ses compromis :

Pour de nombreuses équipes, un WAF cloud est le moyen le plus rapide de démarrer, tandis que les WAF basés sur l'hôte offrent plus de personnalisation pour des applications spécifiques.

Fonctionnalités clés à rechercher

• Ensembles de règles : Règles prédéfinies pour l'OWASP Top 10 et les plateformes CMS courantes.
• Règles personnalisées : Capacité à écrire vos propres règles en fonction de la logique de votre application.
• Limitation de débit : Limiter les requêtes provenant d'une seule IP ou session pour prévenir la force brute et le scraping.
• Gestion des bots : Distinguer les bons bots (moteurs de recherche) des mauvais.
• Journalisation et alertes : Journaux détaillés pour la réponse aux incidents et la conformité.
• Protection des API : Validation de schéma et détection d'anomalies pour les API REST/GraphQL.

Comment déployer un WAF : étape par étape

1. Choisissez votre modèle de déploiement. Décidez entre cloud, hôte ou réseau en fonction de votre infrastructure et des compétences de votre équipe.
2. Commencez en mode surveillance. Activez le WAF en mode détection seule pour journaliser le trafic sans le bloquer. Cela vous aide à comprendre les schémas normaux.
3. Analysez les journaux et ajustez les règles. Recherchez les faux positifs (requêtes légitimes signalées comme attaques) et ajustez les règles ou ajoutez des exceptions. Utilisez un analyseur de journaux pour traiter efficacement les logs WAF.
4. Activez le blocage progressivement. Commencez par des règles à haute confiance (par exemple, les motifs SQLi connus) et activez-en progressivement d'autres au fur et à mesure que vous gagnez en confiance.
5. Intégrez à votre CI/CD. Si vous utilisez l'infrastructure as code, gérez les règles WAF sous forme de code pour versionner et examiner les modifications.
6. Surveillez et mettez à jour. Examinez régulièrement les journaux, mettez à jour les ensembles de règles et ajustez au fur et à mesure de l'évolution de votre application.

Exemple : règle ModSecurity

Voici une règle ModSecurity simple qui bloque les requêtes contenant ../ dans la chaîne de requête, une tentative courante de traversée de répertoires :

SecRule ARGS "\.\./" \
    "id:1001,phase:2,deny,status:403,log,msg:'Path Traversal Attempt'"

Cette règle inspecte tous les arguments de requête (chaîne de requête, corps) et refuse la requête si elle trouve ../. En production, vous utiliseriez des ensembles de règles plus complets comme l'OWASP CRS.

Bonnes pratiques et pièges

• Ne vous fiez pas uniquement à un WAF. C'est une couche complémentaire ; le codage sécurisé et les correctifs restent essentiels.
• Évitez de bloquer le trafic légitime. Ajustez soigneusement les règles et surveillez les faux positifs.
• Maintenez les règles à jour. De nouvelles vulnérabilités apparaissent régulièrement ; abonnez-vous aux mises à jour des ensembles de règles.
• Protégez aussi les API. Les applications modernes utilisent massivement les API ; assurez-vous que votre WAF les couvre.
• Journalisez et surveillez. Un WAF ne vaut que par les informations que vous tirez de ses journaux.

FAQ

Un WAF remplace-t-il le codage sécurisé ?

Non. Un WAF est une couche de défense en profondeur. Il peut bloquer de nombreuses attaques, mais les vulnérabilités dans votre code doivent toujours être corrigées. Un WAF vous fait gagner du temps et ajoute une protection, mais il ne remplace pas les pratiques de développement sécurisé.

Un WAF peut-il ralentir mon site web ?

Oui, toute inspection ajoute une certaine latence. Les WAF cloud ajoutent généralement quelques millisecondes, tandis que les WAF basés sur l'hôte peuvent en ajouter davantage selon la complexité des règles. Un bon ajustement et la mise en cache peuvent minimiser l'impact.

Comment choisir entre un WAF cloud et un WAF auto-hébergé ?

Les WAF cloud sont plus faciles à mettre en place et à mettre à l'échelle, ce qui les rend idéaux pour les équipes sans personnel de sécurité dédié. Les WAF auto-hébergés offrent plus de contrôle et peuvent être moins chers à grande échelle, mais nécessitent de la maintenance. Tenez compte de l'expertise de votre équipe et de votre budget.

Prêt à analyser vos journaux WAF ? Utilisez notre Analyseur de journaux Nginx pour analyser et visualiser les schémas de trafic, vous aidant à ajuster vos règles WAF et à repérer rapidement les anomalies.