🛡️ WAF ModSecurity : Protéger ses Applications Web des Attaques OWASP Top 10

🟡 Niveau : Intermédiaire | ⏱️ Lecture : 14 min | 🛠️ Mise en œuvre : 3-4 heures

📚 Prérequis

Connaissances de base de Nginx ou Apache
Docker installé (pour le déploiement conteneurisé)
Une application web à protéger
Compréhension basique des requêtes HTTP

Chaque jour, des milliers d’applications web sont attaquées par des bots et des hackers cherchant des vulnérabilités. Les injections SQL, les XSS et autres attaques du OWASP Top 10 font des ravages. Un WAF (Web Application Firewall) est votre première ligne de défense. Découvrez comment ModSecurity avec les règles OWASP CRS peut protéger vos applications.

📋 Le OWASP Top 10 : Comprendre les Menaces

L’OWASP (Open Web Application Security Project) publie régulièrement une liste des 10 vulnérabilités web les plus critiques. Voici l’édition 2021 (toujours d’actualité) :

#	Vulnérabilité	Description
A01	Broken Access Control	Accès à des ressources non autorisées
A02	Cryptographic Failures	Données sensibles mal protégées
A03	Injection	SQL, NoSQL, OS, LDAP injection
A04	Insecure Design	Failles architecturales
A05	Security Misconfiguration	Configurations par défaut dangereuses
A06	Vulnerable Components	Bibliothèques avec CVE connues
A07	Auth Failures	Authentification cassée
A08	Software Integrity	Code ou données non vérifiés
A09	Logging Failures	Logs insuffisants pour détecter les attaques
A10	SSRF	Requêtes forgées côté serveur

Un WAF bien configuré peut bloquer A03, A05, A07 et atténuer plusieurs autres.

🔒 ModSecurity : Le Moteur WAF de Référence

Flux de requêtes à travers le WAF ModSecurity

ModSecurity est un moteur de WAF open-source créé en 2002. Il s’intègre comme module à Apache, Nginx ou IIS. La version 3 (libmodsecurity) offre des performances exceptionnelles.

Comment ça fonctionne ?

Une requête HTTP arrive sur le serveur
ModSecurity analyse les headers, paramètres, body, cookies
Il compare avec des règles de détection
Si une règle matche, il peut : journaliser, bloquer, ou laisser passer

Les Phases d’Analyse

Phase 1 : Headers de requête
Phase 2 : Body de requête
Phase 3 : Headers de réponse
Phase 4 : Body de réponse
Phase 5 : Logging

📋 OWASP Core Rule Set (CRS) : Des Règles Maintenues par la Communauté

ModSecurity seul n’est qu’un moteur. Il a besoin de règles pour détecter les attaques. L’OWASP CRS est un ensemble de règles open-source maintenu activement :

+200 règles de détection
Mises à jour régulières contre les nouvelles menaces
Utilisé par des millions de sites
Version actuelle : 4.x

Exemples de Règles CRS

# Règle 942100 : Détection SQL Injection
SecRule ARGS "@detectSQLi" \
    "id:942100,\
    phase:2,\
    block,\
    msg:'SQL Injection Attack Detected',\
    logdata:'Matched Data: %{TX.0}',\
    tag:'attack-sqli',\
    tag:'OWASP_CRS'"

# Règle 941100 : Détection XSS
SecRule ARGS "@detectXSS" \
    "id:941100,\
    phase:2,\
    block,\
    msg:'XSS Attack Detected',\
    tag:'attack-xss'"

🎯 Mode DetectionOnly vs Mode Blocage

C’est LA décision critique lors du déploiement d’un WAF :

Mode DetectionOnly (Observation)

SecRuleEngine DetectionOnly

✅ Les attaques sont journalisées mais pas bloquées
✅ Parfait pour identifier les faux positifs
✅ Aucun risque de casser l’application
❌ Pas de protection réelle

Recommandation : Toujours commencer en DetectionOnly pendant 2-4 semaines.

Mode On (Blocage)

SecRuleEngine On

✅ Les attaques sont bloquées
✅ Protection active
❌ Risque de bloquer du trafic légitime (faux positifs)

Transition : Passez en mode On uniquement après avoir géré tous les faux positifs identifiés.

📊 Niveaux de Paranoïa : Ajuster la Sensibilité

Le CRS offre 4 niveaux de paranoïa qui déterminent l’agressivité des règles :

Niveau	Description	Cas d’usage
PL1	Règles de base, peu de faux positifs	Sites grand public, e-commerce
PL2	+ règles supplémentaires	Applications métier
PL3	+ détection Unicode, encodages	Applications sensibles
PL4	Maximum de détection	Environnements très sécurisés

Conseil : Commencez par PL1 et augmentez progressivement si nécessaire.

🔧 Gérer les Faux Positifs

Les faux positifs sont inévitables. Voici comment les gérer proprement :

1. Identifier le Faux Positif

Analysez les logs ModSecurity :

ModSecurity: Warning. Matched "Operator `Contains' with parameter `select' 
against variable `ARGS:search'" 
[file "/etc/modsecurity/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] 
[line "45"] [id "942100"] [msg "SQL Injection Attack Detected"]

Ici, le mot « select » dans un champ de recherche déclenche une fausse alerte SQL injection.

2. Créer une Exclusion

# Exclure la règle 942100 pour le paramètre 'search'
SecRuleUpdateTargetById 942100 "!ARGS:search"

3. Méthode Alternative : Whitelisting par URL

# Désactiver certaines règles pour une URL spécifique
SecRule REQUEST_URI "@beginsWith /api/upload" \
    "id:1001,phase:1,pass,nolog,\
    ctl:ruleRemoveById=920420,\
    ctl:ruleRemoveById=921110"

🔐 HTTPS et Certificats Let’s Encrypt

Un WAF sans HTTPS n’a pas de sens. ModSecurity doit voir le trafic déchiffré pour l’analyser. Voici l’architecture recommandée :

Internet → WAF (Nginx + ModSecurity + HTTPS) → Backend (HTTP interne)

Let’s Encrypt fournit des certificats SSL gratuits et automatiquement renouvelés via Certbot.

📈 Métriques et Monitoring du WAF

Un WAF doit être surveillé. Métriques importantes :

Requêtes bloquées par minute : pic = attaque potentielle
Top 10 règles déclenchées : identifier les patterns
IPs les plus bloquées : potentiels attaquants
Latence ajoutée : impact sur la performance

🚀 Déployer un WAF ModSecurity en Production

Configurer un WAF from scratch implique :

Installation Nginx avec module ModSecurity
Configuration des règles CRS
Génération des paramètres DH pour TLS
Configuration Certbot pour Let’s Encrypt
Création des virtual hosts
Monitoring et logging

Notre rôle Ansible simplifie tout :

✅ Image Docker OWASP officielle avec Nginx + ModSecurity
✅ CRS préconfiguré avec niveaux de paranoïa ajustables
✅ Mode DetectionOnly par défaut (sécuritaire)
✅ Certbot intégré avec renouvellement automatique
✅ Exclusions de règles faciles via variables Ansible
✅ Mode Server (WAF complet) et Client (ajout de sites)

Prêt à protéger vos applications web ? Découvrez notre rôle Ansible nginx_modsecurity.

Voir le rôle nginx_modsecurity

📖 Glossaire

WAF (Web Application Firewall) : Pare-feu applicatif qui analyse et filtre le trafic HTTP
OWASP : Open Web Application Security Project, communauté qui publie des standards de sécurité web
CRS (Core Rule Set) : Ensemble de règles de détection d’attaques maintenu par l’OWASP
SQL Injection : Attaque consistant à injecter du code SQL malveillant via les entrées utilisateur
XSS (Cross-Site Scripting) : Attaque permettant d’exécuter du code JavaScript malveillant dans le navigateur
Faux Positif : Requête légitime incorrectement identifiée comme malveillante
Niveau de Paranoïa : Paramètre CRS définissant l’agressivité des règles de détection (1 à 4)

Le prochain article explorera PostgreSQL en haute disponibilité avec Patroni, etcd et HAProxy. Une architecture complexe démystifiée !