WAF : ModSecurity (Plesk) ou Cloudflare, que choisir ?

Un WAF (Web Application Firewall) filtre le trafic HTTP avant qu'il n'atteigne votre application. Il inspecte chaque requête, compare à des signatures d'attaque connues (injections SQL, XSS, RCE, path traversal, scans de vulnérabilités, bots agressifs) et bloque ce qui correspond. Deux options sont à la portée d'un client Datacampus : ModSecurity côté serveur via Plesk, ou le WAF Cloudflare en edge. Les deux se défendent, et ils peuvent se combiner. Voyons ce que chacun apporte concrètement.

Ce qu'un WAF bloque vraiment

Sur un site WordPress ou PrestaShop exposé, voici la nature des requêtes qu'un WAF intercepte au quotidien :

• SQLi — ?id=1' OR 1=1-- et ses variantes, union-based, time-based.
• XSS — <script>, handlers onerror=, payloads encodés.
• RCE / LFI — tentatives sur wp-config.php, .env, /etc/passwd, php://filter.
• Scans de vulnérabilités — Nuclei, Nikto, Nessus, ZGrab, scans de plugins WP obsolètes.
• Brute force sur /wp-login.php, /administrator/, /admin.
• Bots — scrapers agressifs, faux Googlebot, exploit kits automatisés.

ModSecurity dans Plesk

ModSecurity est un module Apache (et Nginx) open source, intégré directement à Plesk. Il applique un jeu de règles, le plus connu étant l'OWASP Core Rule Set (CRS), sur chaque requête qui atteint votre serveur.

Activation

Dans Plesk : Sites Web & Domaines > votre domaine > Firewall d'applications Web (ModSecurity). Trois modes :

• Désactivé — rien n'est filtré.
• Mode détection — les règles tournent, les hits sont loggés, rien n'est bloqué. Mode à privilégier au démarrage pour repérer les faux positifs avant de serrer la vis.
• Activé — les règles bloquent (HTTP 403).

Côté jeu de règles, Plesk propose généralement OWASP CRS, Atomic Basic (gratuit, léger) et Comodo / Atomic Advanced selon la licence. Pour 95 % des cas, OWASP CRS en niveau de paranoïa 1 suffit.

Avantages

• Gratuit, inclus dans tout hébergement Plesk chez Datacampus.
• Granulaire par domaine : vous pouvez avoir du strict sur une boutique et du permissif sur un blog.
• Voit 100 % du trafic, y compris ce qui passe derrière un CDN. Si Cloudflare laisse passer une requête, ModSecurity a encore son mot à dire.
• Logs détaillés dans /var/log/modsec_audit.log, exploitables par votre équipe ou la nôtre.

Inconvénients

• Faux positifs fréquents — l'OWASP CRS est conservateur. Un éditeur WYSIWYG, un champ de commentaire riche, un plugin qui passe du JSON en POST, et la règle bloque.
• Coût CPU. Chaque requête est inspectée par votre serveur. Sur un site à gros trafic ou sous attaque, l'overhead se voit.
• Votre serveur absorbe quand même l'attaque. Le WAF filtre, mais la requête a déjà consommé bande passante, connexion TCP, fork Apache ou worker PHP-FPM. Face à un DDoS applicatif, ModSecurity ne vous sauve pas.

Cloudflare WAF

Le WAF Cloudflare filtre en edge, sur les POPs Cloudflare, avant que la requête n'atteigne votre origine Datacampus. Ce qui est bloqué ne consomme pas une milliseconde de votre CPU.

Ce que vous avez selon le plan

Avantages

• Bloque avant votre serveur : économie CPU et bande passante, résistance aux DDoS L7.
• Règles à jour en permanence : Cloudflare pousse de nouvelles signatures dès qu'une CVE majeure sort (Log4Shell a été bloqué au edge avant que beaucoup d'admins n'aient patché).
• Logs clairs, UI exploitable, WAF analytics en temps réel.
• Rate limiting natif sur Business : limiter /wp-login.php à 5 tentatives par 10 minutes, par exemple.

Inconvénients

• Un vrai WAF coûte. Le Pro à 20 $/mois est un bon compromis ; le Business à 200 $/mois devient pertinent à partir d'un certain enjeu business.
• Ne voit que ce qui passe par Cloudflare. Si un attaquant trouve votre IP d'origine (DNS historique, email SMTP, ancien record en gris oublié), il contourne le WAF. À combiner avec une whitelist d'IPs Cloudflare côté origine (voir Cloudflare devant Plesk).

Position Datacampus sur Cloudflare

Nous ne recommandons pas le plan Free dès que le site est critique. La raison est double : le WAF Free est cosmétique, et surtout le plan Free impose le transfert complet de votre zone DNS chez Cloudflare. Vous perdez la main sur vos MX, vos TXT, votre délivrabilité mail.

Notre recommandation pour les sites exposés : Cloudflare Business en CNAME Setup. Vous gardez votre zone DNS, seul le flux web transite par Cloudflare, et vous récupérez le WAF complet, les custom rules et le rate limiting.

Matrice de décision

Le principe de défense en profondeur est intéressant : Cloudflare absorbe l'attaque volumétrique et les signatures connues en edge, ModSecurity rattrape ce qui serait passé et voit les requêtes internes (webhooks, scripts cron exposés, APIs) qui ne transitent pas forcément par Cloudflare.

Gérer les faux positifs ModSecurity

C'est le point qui fait râler tout le monde au début. Un plugin WordPress passe du JSON en POST, ou un éditeur TinyMCE envoie du HTML avec des balises <iframe> dans un champ d'article, et ModSecurity bloque.

Identifier la règle

Les hits sont loggés dans /var/log/modsec_audit.log. Cherchez la règle qui a matché :

grep -A 5 "id \"942100\"" /var/log/modsec_audit.log
# 942100 = Detects MySQL comment-/space-obfuscated injections

Chaque règle a un ID numérique unique. Les règles OWASP CRS sont rangées par famille : 9xx pour SQLi (942xxx), XSS (941xxx), RCE (932xxx), etc.

Créer une exclusion

Dans Plesk : Sites Web & Domaines > votre domaine > Firewall d'applications Web > Paramètres. Vous pouvez désactiver une règle globalement (à éviter), ou mieux, l'exclure sur une URL précise :

# Dans les directives additionnelles du domaine
<LocationMatch "^/wp-admin/admin-ajax\.php">
    SecRuleRemoveById 942100 942190 942200
</LocationMatch>

Cela désactive trois règles SQLi sur l'endpoint AJAX de WordPress, qui est notoirement sujet aux faux positifs, sans affaiblir la protection sur le reste du site.

Cas concret : tentatives SQLi sur une boutique PrestaShop

Contexte : boutique PrestaShop 8 hébergée chez Datacampus, Plesk, Cloudflare Free devant. Sur une semaine, les logs révèlent des requêtes type :

/recherche?controller=search&s=test' UNION SELECT null,null,concat(user,0x3a,password) FROM ps_employee--
/index.php?id_category=2' AND SLEEP(5)--
/module/ps_linklist/link?id=1 OR 1=1

Cloudflare Free laisse passer (le Free Managed Ruleset est trop permissif), ModSecurity bloque, mais le serveur encaisse quand même 400 requêtes/minute venant de 12 IPs résidentielles distribuées.

Réponse opérationnelle

1. Bascule vers Cloudflare Business (CNAME Setup, pas de transfert de zone).
2. Activation du Cloudflare Managed Ruleset : les patterns SQLi sont bloqués au edge.
3. Custom rule rate limiting sur /recherche : max 10 requêtes / 10 secondes par IP.
4. Custom rule : bloquer toute requête contenant UNION SELECT, SLEEP(, information_schema dans la query string, tous endpoints.
5. Conservation de ModSecurity côté origine en mode bloquant, pour les requêtes internes et la défense en profondeur.

Résultat en 24 h : 99 % des attaques stoppées en edge, CPU serveur divisé par 3 sur les heures de scan, zéro faux positif côté clients légitimes.

Check-list

• ModSecurity activé en mode détection sur chaque domaine Plesk, puis passé en bloquant après la phase d'observation.
• Faux positifs connus listés et exclus par SecRuleRemoveById ciblé, pas de règle désactivée globalement sans raison documentée.
• Si Cloudflare : plan Business au minimum pour un vrai WAF, CNAME Setup pour garder la main sur la zone DNS.
• Défense en profondeur : les deux WAF cohabitent, Cloudflare en edge, ModSecurity côté origine.
• Whitelist des plages IP Cloudflare côté Plesk (voir Cloudflare devant Plesk), et Authenticated Origin Pulls pour les sites critiques.
• Revue mensuelle des logs : /var/log/modsec_audit.log côté serveur, WAF Analytics côté Cloudflare.

Pour aller plus loin, voir Hardening général, Audit de sécurité rapide et, en cas d'incident, Site hacké, que faire.