La plupart des déploiements de ModSecurity se limitent à charger le jeu de règles OWASP CRS pour bloquer des attaques connues.
C’est utile, mais cela ne tire parti que d’une infime partie des capacités réelles du moteur.
Peu de gens savent que ModSecurity peut aussi fonctionner comme un système de corrélation d’événements multi‑requêtes, avec mémoire persistante, calculs de seuils, et exécution d’actions personnalisées côté serveur.
Dans cet article, nous allons explorer ces fonctions avancées rarement documentées, en les appliquant à des scénarios concrets.
1. Comprendre les collections persistantes
ModSecurity peut stocker et réutiliser des variables entre plusieurs requêtes, grâce à ce qu’on appelle les collections persistantes.
Ces collections (IP, USER, SESSION, RESOURCE, TX) sont conservées en mémoire ou sur disque selon la configuration, ce qui permet de prendre des décisions en tenant compte du passé de l’IP, de l’utilisateur ou de la ressource demandée.
Par exemple, pour initialiser un compteur par IP :
SecAction \
"id:1000,\
phase:1,\
nolog,\
pass,\
initcol:ip=%{REMOTE_ADDR},\
setvar:ip.counter=+0"
Ici, initcol charge (ou crée) une collection associée à l’adresse IP du client.
Nous initialisons ensuite un compteur ip.counter.
Cette variable restera accessible pour toutes les requêtes suivantes venant de cette IP, jusqu’à expiration.
2. Exemple : détection progressive des comportements suspects
Imaginons un attaquant qui sonde des fichiers sensibles (.env, .git, wp-config.php) sur votre site.
Chaque tentative n’est pas forcément bloquante, mais si l’on en détecte plusieurs en peu de temps, cela devient un signal fort.
SecRule REQUEST_URI "@rx \.env|\.git|wp-config\.php" \
"id:1001,\
phase:2,\
pass,\
log,\
msg:'Tentative de scan de fichiers sensibles',\
setvar:ip.minor_violations=+1,\
expirevar:ip.minor_violations=300"
Cette règle incrémente un compteur ip.minor_violations à chaque détection et fixe une expiration à 300 secondes.
Ainsi, si trois tentatives surviennent en moins de 5 minutes, on peut considérer l’IP comme suspecte :
SecRule IP:minor_violations "@ge 3" \
"id:1002,\
phase:2,\
pass,\
log,\
msg:'IP sous surveillance renforcée',\
setvar:ip.enhanced_watch=1,\
expirevar:ip.enhanced_watch=600"
Nous créons ici un indicateur binaire ip.enhanced_watch valable pendant 10 minutes.
Cet état servira à appliquer des règles plus strictes uniquement à ces IP, sans impacter les visiteurs légitimes.
3. Actions dynamiques : blocage automatisé via script
ModSecurity peut exécuter des commandes systèmes avec l’action exec.
Cela permet de déclencher un blocage dans iptables ou tout autre outil, uniquement lorsque certaines conditions sont réunies.
SecRule REQUEST_HEADERS:User-Agent "@streq sqlmap" \
"id:1003,\
phase:2,\
log,\
msg:'Scan SQLMap détecté',\
chain"
SecRule IP:enhanced_watch "@eq 1" \
"exec:/etc/modsec/ban_ip.sh %{REMOTE_ADDR}"
Ici, on détecte l’outil SQLMap dans l’User-Agent, mais on ne bloque que si l’IP est déjà marquée comme suspecte.
Le script ban_ip.sh va bannir l’IP directement au niveau du pare-feu.
#!/bin/bash
IP=$1
iptables -I INPUT -s $IP -j DROP
logger "ModSecurity : IP $IP bloquée via iptables"
En agissant ainsi, on évite les faux positifs tout en réagissant fermement aux comportements persistants.
4. Intégration avec un SIEM ou un système d’alerte
Les mêmes scripts peuvent envoyer des notifications en temps réel vers un SIEM ou un service comme Slack :
curl -X POST -H 'Content-type: application/json' \
--data "{\"text\":\"ModSecurity : IP $IP bannie pour attaques répétées.\"}" \
https://hooks.slack.com/services/XXXX/YYYY/ZZZZ
Cela permet d’informer immédiatement l’équipe sécurité qu’un blocage a été appliqué, avec l’IP, la règle déclenchée et l’heure.
5. Mitigation comportementale des attaques DoS
On peut aussi utiliser les collections pour limiter la fréquence des requêtes par IP et retourner un code 429 (Too Many Requests) lorsqu’un seuil est dépassé.
SecRule REQUEST_URI ".*" \
"id:1004,\
phase:2,\
pass,\
nolog,\
setvar:ip.req_count=+1,\
expirevar:ip.req_count=60"
SecRule IP:req_count "@ge 100" \
"id:1005,\
phase:2,\
deny,\
status:429,\
msg:'Trop de requêtes : possible DoS'"
Cette logique compte le nombre de requêtes en 60 secondes et bloque temporairement si le seuil est franchi.
6. Pièges à robots : honeypots intégrés
Un honeypot est une URL volontairement inexistante ou cachée que seul un bot malveillant explorera.
En piégeant ainsi, on détecte rapidement les scanners automatisés.
SecRule REQUEST_URI "@rx /secret_admin|/hidden_api" \
"id:1006,\
phase:2,\
log,\
msg:'Honeypot touché',\
exec:/etc/modsec/ban_ip.sh %{REMOTE_ADDR}"
Le simple accès à cette URL déclenche le bannissement de l’IP, car aucun visiteur légitime ne devrait y accéder.
7. Journalisation avancée pour analyse forensic
En phase 5 (logging), on peut enrichir les journaux avec le maximum de contexte utile pour une analyse post‑incident.
SecRule REQUEST_URI ".*" \
"id:1007,\
phase:5,\
log,\
auditlog,\
msg:'Audit complet',\
tag:'context:%{REQUEST_HEADERS.Host} %{REMOTE_ADDR} %{TX.0}'"
Cela permet de regrouper dans les logs les informations critiques : host, IP source, données de transaction, etc., facilitant les investigations.
Conclusion
En combinant collections persistantes, règles chainées, scripts externes et intégration temps réel, ModSecurity peut dépasser largement son rôle de simple WAF statique.
Il devient un moteur de détection comportementale et d’actions adaptatives, capable de prendre des décisions contextuelles sur plusieurs requêtes et de réagir en conséquence.
Peu d’implémentations utilisent ce potentiel, mais il offre un niveau de défense qui se rapproche d’un SOC embarqué directement sur le serveur web.
