A.1 Le rôle du WAF

Un WAF (Web Application Firewall) est un reverse proxy Apache qui inspecte chaque requête HTTP avant de la transmettre au backend. Il détecte et bloque les attaques web (SQLi, XSS, LFI, RCE) en analysant les URL, les headers, les paramètres et le corps des requêtes.

A.2 Structure d'un VirtualHost WAF

<VirtualHost *:443>
    ServerName www.example.com
    Protocols h2 http/1.1

    # Sécurité de base
    TraceEnable off
    ServerSignature Off

    # Logs séparés par site
    ErrorLog  ${APACHE_LOG_DIR}/example_error.log
    CustomLog ${APACHE_LOG_DIR}/example_access.log combined

    # Headers de sécurité (cf. Partie C)
    # ... (détaillé plus bas)

    # Reverse proxy vers le backend
    ProxyPass        / http://192.168.x.x:8080/
    ProxyPassReverse / http://192.168.x.x:8080/

    # TLS
    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</VirtualHost>

B.1 Installer ModSecurity + CRS

# Installer ModSecurity pour Apache
sudo apt install libapache2-mod-security2

# Activer le module
sudo a2enmod security2

# Installer le CRS (dernière version)
cd /etc/crs
sudo wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v4.10.0.tar.gz
sudo tar xzf v4.10.0.tar.gz
sudo ln -s coreruleset-4.10.0 current

B.2 Configurer le chargement des règles

<IfModule security2_module>
    SecDataDir /var/cache/modsecurity
    Include /etc/modsecurity/modsecurity.conf
    Include /etc/modsecurity/crs-setup.conf
    Include /etc/crs/current/rules/*.conf
</IfModule>

B.3 Le scoring par anomalie

Le CRS ne bloque jamais une requête sur une seule règle. Chaque règle déclenchée ajoute un score. Si le total dépasse le seuil, la requête est bloquée. C'est le mode Anomaly Scoring.

Un score typique pour une attaque SQLi : 5 points (une seule règle 942xxx suffit). Pour une requête légitime : 0 points. Les faux positifs ajoutent souvent 3 points — en dessous du seuil.

B.4 Le fichier crs-setup.conf

# Mode de détection : On = bloque, DetectionOnly = log uniquement
SecRuleEngine On

# Scoring
SecAction "id:900110,phase:1,pass,nolog,\
  setvar:tx.inbound_anomaly_score_threshold=5,\
  setvar:tx.outbound_anomaly_score_threshold=4"

# Paranoia level (1 = standard, raisonnable pour la plupart des sites)
SecAction "id:900000,phase:1,pass,nolog,\
  setvar:tx.paranoia_level=1"

# Contenu autorisé
SecAction "id:900220,phase:1,pass,nolog,\
  setvar:'tx.allowed_request_content_type=|application/x-www-form-urlencoded|\
|multipart/form-data||text/xml||application/xml||application/soap+xml|\
|application/json||application/cloudevents+json||application/csp-report|'"

B.5 DetectionOnly vs On

Le mode DetectionOnly est indispensable pour les premiers jours de déploiement :

B.6 Les familles de règles CRS

C.1 Pourquoi centraliser au WAF ?

Les applications backend (WordPress, Node.js, Python/Django…) ont chacune leur propre gestion des headers. Certaines les oublient, d'autres les doublent. En les posant au niveau du WAF, vous garantissez une politique uniforme sur tous les sites.

C.2 Configuration globale — security.conf

Ce fichier est chargé par tous les VirtualHosts :

ServerTokens Prod
ServerSignature Off
TraceEnable Off

# Bloquer l'accès aux fichiers sensibles
RedirectMatch 404 /\.git
RedirectMatch 404 /\.svn
RedirectMatch 404 /\.env

<IfModule mod_headers.c>
    # Supprimer les headers remontés par le backend
    Header onsuccess unset X-Content-Type-Options
    Header onsuccess unset X-Frame-Options
    Header onsuccess unset Strict-Transport-Security
    Header onsuccess unset Server
    Header always unset X-Content-Type-Options
    Header always unset X-Frame-Options
    Header always unset Strict-Transport-Security
    Header always unset Server

    # Poser NOS headers de sécurité
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "DENY"
    Header always set X-XSS-Protection "1; mode=block"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
    Header always set Cache-Control "no-store, no-cache, must-revalidate, max-age=0"
    Header always set Pragma "no-cache"
    Header always set Server "Apache"
</IfModule>

C.3 Les headers expliqués

C.4 Cas particulier : sites WordPress avec ressources externes

Pour les sites avec Google Fonts, analytics, plugins tiers : ne posez pas de CSP dans un premier temps. Les autres headers suffisent pour satisfaire les audits RiskRecon/Bitsight. La CSP est un chantier à part (cf. Partie E).

D.1 Identifier un faux positif

Dans les logs ModSecurity, un faux positif ressemble à ça :

[client 10.0.0.5] ModSecurity: Warning. 
  Pattern match "(?:select|union|insert|update|delete)" at ARGS:query.
  [id "942100"] [msg "SQL Injection Attack Detected"]
  [severity "CRITICAL"] [tag "attack-sqli"]
  [hostname "app.example.com"] [uri "/api/search"]

La clé : l'URI /api/search avec un paramètre query est une fonctionnalité légitime de votre application. La règle 942100 voit le mot select dans le paramètre et crie à l'injection SQL.

D.2 Exclure une règle sur une URI spécifique

# Exclure la règle 942100 uniquement sur /api/search
SecRule REQUEST_URI "@beginsWith /api/search" \
    "id:9000001,phase:1,pass,nolog,\
    ctl:ruleRemoveById=942100"

D.3 Exclure une règle sur un paramètre spécifique

# Ne pas inspecter le paramètre 'content' (éditeur WYSIWYG)
SecRuleUpdateTargetById 942100 "!ARGS:content"
SecRuleUpdateTargetById 941100 "!ARGS:content"

D.4 Exclusions pour les applications IA / LLM

Les applications d'IA (OpenWebUI, ChatGPT, Ollama) génèrent un volume massif de faux positifs car les conversations contiennent du code, du SQL, du HTML — tout ce que le CRS cherche à bloquer.

# Routes API streaming LLM — désactiver ModSecurity
<LocationMatch "^/(api/v1/chats|ollama|litellm)">
    SecRuleEngine Off
</LocationMatch>

E.1 Le principe

La CSP dit au navigateur : « voici les seules sources autorisées pour charger des scripts, styles, images, polices, etc. ». Tout ce qui n'est pas dans la liste est bloqué par le navigateur — même si le HTML de la page le demande. C'est la protection ultime contre le XSS.

E.2 Phase 1 — Report-Only (découverte)

Ne déployez jamais une CSP en enforcement sans phase de découverte. Utilisez Content-Security-Policy-Report-Only pour observer les violations sans rien bloquer :

# Phase découverte — log uniquement, ne bloque rien
Header always set Content-Security-Policy-Report-Only "\
  default-src 'self'; \
  script-src 'self'; \
  style-src 'self' 'unsafe-inline'; \
  img-src 'self' data:; \
  font-src 'self'; \
  connect-src 'self'; \
  frame-ancestors 'none'; \
  form-action 'self'; \
  base-uri 'self'; \
  object-src 'none'; \
  report-uri /csp-report"

E.3 Collecter les violations avec ModSecurity

Plutôt que de déployer un endpoint PHP/Python, exploitez ModSecurity comme collecteur CSP :

# Collecteur CSP — exclure le Content-Type inhabituel du CRS
SecRule REQUEST_URI "@streq /csp-report" \
    "id:9000099,phase:1,pass,nolog,\
    ctl:ruleRemoveById=920420"

E.4 Phase 2 — Enforcement

Après 2-3 semaines de collecte et d'ajustement (ajout des domaines tiers détectés dans les violations), remplacez Report-Only par Content-Security-Policy :

Header always set Content-Security-Policy "\
  default-src 'self'; \
  script-src 'self'; \
  style-src 'self' 'unsafe-inline'; \
  img-src 'self' data:; \
  font-src 'self'; \
  connect-src 'self'; \
  frame-ancestors 'none'; \
  object-src 'none'"

F.1 Architecture du rapport

F.2 Prérequis

sudo apt install -y msmtp geoip-bin geoip-database gawk

F.3 Contenu du rapport

Le rapport quotidien contient :

F.4 Crontab

# Rapport WAF quotidien à 7h00
0 7 * * * root /opt/waf-report/waf_daily_report.sh >> /var/log/waf_report.log 2>&1