En bref : ModSecurity est un pare-feu applicatif web qui s'exécute dans le serveur web ; l'OWASP Core Rule Set (CRS) fournit pour cela des règles librement disponibles contre les types d'attaques courants. Pour Apache, le projet CRS recommande ModSecurity v2 ; pour Nginx, le connecteur v3 ou Coraza entrent en ligne de compte. Démarrez en mode blocage avec des seuils d'anomalie très élevés, abaissez-les progressivement et traitez les faux positifs par des exceptions ciblées. Une mise à jour de PHP n'est pas remplacée pour autant.
Un WAF maison comme couche supplémentaire
Depuis PHP2Shell, de nombreuses entreprises se demandent si elles ont besoin d'un pare-feu applicatif web. Qui diffuse ses sites via Cloudflare a, selon Cloudflare, des règles de protection automatiquement actives depuis le 21 octobre 2026. Qui ne le fait pas ou ne veut pas faire transiter le trafic par un tiers peut exploiter un WAF directement sur son propre serveur.
La combinaison la plus connue pour cela est ModSecurity avec l'OWASP Core Rule Set. Les deux sont open source et gratuits. Le CRS est un ensemble de règles de détection générales, par exemple contre l'injection SQL, le cross-site scripting ou l'injection de fichiers. Le projet décrit lui-même son objectif comme une détection générale des attaques avec le moins possible de faux positifs, comme un élément parmi d'autres.
La limite est ainsi aussi nommée. Un WAF examine les requêtes et les réponses, il ne répare aucune faille dans l'interpréteur PHP. Pourquoi il faut les deux est décrit dans WAF ou mise à jour : pourquoi il faut les deux.
Quel moteur convient à votre serveur web
L'ensemble de règles a besoin d'un moteur qui l'exécute. Selon la documentation du CRS, il existe trois options compatibles :
| Moteur | Serveur web | Appréciation selon le projet CRS |
|---|---|---|
| ModSecurity v2 | Apache (module) | implémentation de référence, recommandée pour Apache |
| ModSecurity v3 (libModSecurity) | surtout Nginx via connecteur | seul le connecteur Nginx est réellement utilisable en production ; échoue à 2 à 4 pour cent des tests du CRS |
| Coraza | proxys et intégrations basés sur Go | réussit entièrement la suite de tests du CRS v4 |
Pour mémoire : ModSecurity a longtemps été développé par Trustwave. Trustwave a annoncé en 2021 qu'il mettrait fin au développement en 2024. Le 25 janvier 2024, le projet est passé à l'OWASP Foundation. Pour les nouvelles installations, vérifiez quelle version votre distribution fournit et dans quelle mesure elle est à jour.
Comment fonctionne le Core Rule Set
Dans sa configuration par défaut, le CRS ne bloque pas dès la première anomalie suspecte. Il fonctionne avec des points d'anomalie : chaque règle déclenchée ajoute des points selon sa gravité, et ce n'est que lorsque la somme dépasse un seuil que la requête est rejetée.
- Niveaux de gravité : critique 5 points, erreur 4, avertissement 3, remarque 2.
- Seuil pour les requêtes :
tx.inbound_anomaly_score_threshold, par défaut 5. - Seuil pour les réponses :
tx.outbound_anomaly_score_threshold, par défaut 4. - Niveaux de paranoïa 1 à 4 dans
crs-setup.conf: le niveau 1 est la protection de base pour tout serveur sur Internet, le niveau 2 convient, selon le projet, aux applications avec de vraies données d'utilisateurs comme les boutiques en ligne, les niveaux 3 et 4 apportent nettement plus de faux positifs.
Un niveau de paranoïa plus élevé détecte plus, mais génère aussi plus de faux positifs. Pour la plupart des sites d'entreprise, le niveau 1 est le point de départ, le niveau 2 un objectif ultérieur.
Introduire ModSecurity avec OWASP CRS sans paralyser le site
Pour les nouvelles installations, le projet CRS recommande d'activer le mode blocage dès le départ, mais avec des seuils très élevés, jusqu'à 10000, puis de les abaisser progressivement. Vous accumulez ainsi de l'expérience avec de vrais accès, sans bloquer d'utilisateurs. Vous définissez les seuils dans crs-setup.conf :
# crs-setup.conf : phase de démarrage avec des seuils très élevés
SecAction \
"id:900110,\
phase:1,\
pass,\
t:none,\
nolog,\
setvar:tx.inbound_anomaly_score_threshold=10000,\
setvar:tx.outbound_anomaly_score_threshold=10000"
L'intégration sous Apache suit l'ordre que la documentation du CRS prévoit pour les plugins. Les chemins varient selon la distribution :
<IfModule security2_module>
SecRuleEngine On
Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/plugins/*-config.conf
Include /etc/modsecurity/crs/plugins/*-before.conf
Include /etc/modsecurity/crs/rules/*.conf
Include /etc/modsecurity/crs/plugins/*-after.conf
</IfModule>
Analysez ensuite le journal d'audit défini dans SecAuditLog. La manière d'explorer systématiquement les journaux est décrite dans Analyser les journaux du serveur web après une attaque. Abaissez les seuils par paliers, par exemple sur plusieurs semaines, jusqu'à atteindre la valeur par défaut.
Traiter les faux positifs de façon ciblée
Les faux positifs sont normaux, surtout dans les back-offices de CMS avec des éditeurs qui enregistrent du HTML. La pire réaction est de désactiver le WAF. Deux outils sont préférables.
Premièrement, les plugins : le projet CRS maintient des plugins avec des règles d'exception pour des applications courantes, par exemple pour WordPress. Ils sont copiés dans le dossier des plugins et chargés via les lignes Include montrées plus haut. Le projet tient la liste officielle dans son répertoire de plugins.
Deuxièmement, des exceptions personnalisées et étroitement définies. Au lieu de désactiver une règle partout, vous ne la retirez que pour le chemin où elle gêne :
# Exception personnalisée, à charger AVANT les règles CRS (par ex. dans un fichier *-before.conf)
SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \
"id:1000010,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=941100"
Vous trouvez l'identifiant de la règle dans le journal d'audit du faux positif. Documentez chaque exception avec le motif et la date, afin de pouvoir la réexaminer plus tard.
Après chaque modification des seuils ou des exceptions, testez les parcours critiques de votre application : connexion, commande, paiement, formulaire de contact et rédaction. Un WAF qui bloque les commandes est vite désactivé à nouveau.
Pour les serveurs Apache, il vaut la peine d'aborder le WAF en même temps que le reste de la configuration ; les bases figurent dans Configurer Apache pour PHP en toute sécurité. La manière de situer les règles de Cloudflare en comparaison est présentée dans Règles de protection Cloudflare contre PHP2Shell. Les mesures transitoires sur le serveur lui-même figurent dans Mesures immédiates si vous ne pouvez pas encore appliquer le correctif.
Conclusion : un WAF demande de l'entretien
ModSecurity avec l'OWASP Core Rule Set vous donne un pare-feu applicatif web performant, sans frais de licence et sans dépendance à un service externe. Le prix, c'est le travail : choisir le moteur adapté au serveur web, commencer avec des seuils élevés, analyser les faux positifs, entretenir les exceptions et maintenir les règles à jour.
Qui ne peut pas fournir cet effort s'en sort souvent mieux avec un WAF cloud bien configuré. Qui le fournit obtient une couche qui intercepte de nombreuses attaques standard et fournit dans les journaux d'audit de précieuses indications. En aucun cas elle ne remplace la mise à jour : contre PHP2Shell, seuls PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou un backport confirmé protègent, suivis du redémarrage de tous les processus PHP.
Comment PHP SOS aide-t-il concrètement ?
- Choisir le moteur : nous examinons serveur web, distribution et paquets disponibles et recommandons la combinaison adaptée.
- Mettre en place : nous installons le CRS avec des seuils de départ élevés, intégrons les plugins adaptés et configurons la journalisation.
- Ajuster : pendant plusieurs semaines, nous analysons les faux positifs, créons des exceptions ciblées et abaissons les seuils.
- Situer : dans le cadre de WAF et correctif virtuel, nous relions le WAF aux mesures transitoires et à la voie vers le correctif régulier.
Questions fréquentes
L'OWASP CRS protège-t-il contre PHP2Shell ?
Ne le supposez pas. Le Core Rule Set détecte des motifs d'attaque généraux et n'est pas conçu pour une faille précise. Cloudflare souligne en outre que, pour PHP2Shell, des règles fondées sur les seules données de la requête ne suffisent pas. La mise à jour de PHP reste obligatoire.
Quel moteur choisir pour Nginx ?
Selon le projet CRS, avec ModSecurity v3, seul le connecteur Nginx est réellement utilisable en production, et la v3 échoue à une petite partie des tests du CRS. Il existe aussi Coraza, qui, selon le projet, réussit entièrement la suite de tests du CRS v4. Pour Apache, le projet recommande ModSecurity v2.
ModSecurity est-il encore maintenu ?
Selon la documentation du CRS, Trustwave avait annoncé qu'il mettrait fin au développement en 2024. Le 25 janvier 2024, le projet a été transféré à l'OWASP Foundation et y est poursuivi depuis.
Comment éviter que le WAF paralyse ma boutique ?
Commencez avec des seuils d'anomalie très élevés, comme le recommande le projet CRS, et abaissez-les progressivement. Analysez pour cela les journaux et créez des exceptions ciblées pour votre application, au lieu de désactiver des règles en bloc.