Cloudflare ou un WAF après un piratage : ce que ça ferme, ce que ça ne ferme pas

Ce qu'un WAF arrête vraiment

Un pare-feu applicatif (WAF) lit les requêtes avant qu'elles n'arrivent au PHP. Il bloque des motifs connus : scans d'extensions oubliées, tentatives d'injection dans un formulaire, user-agents de bots d'exploit. Cloudflare, Sucuri, un module ModSecurity chez l'hébergeur : le principe est le même. Ça filtre le bruit de fond qui tape tous les WordPress de la place.

Ce filtre est utile. Il n'est pas un nettoyage. Si quelqu'un a déjà un fichier PHP à la racine, un mu-plugin, ou un compte administrateur fantôme, le WAF le laisse travailler : la requête part d'une session légitime, ou d'un cron interne. Distinguer « moins de scans » et « plus de backdoor » évite le malentendu le plus fréquent après un incident.

Les dossiers que nous reprenons ont souvent un Cloudflare allumé le soir de l'attaque, et le même shell encore là le lundi. Le propriétaire pensait s'être protégé. Il avait seulement baissé le volume des tentatives nouvelles. Voir pare-feu applicatif contre plugin de sécurité pour le découpage des trois couches.

• Coupe une partie du trafic automatisé vers des URLs connues.
• Ne voit pas un fichier déjà déposé ni une option en base.
• Ne remplace ni la copie du compte, ni le changement du mot de passe panel.

Ce qu'il laisse passer une fois la porte ouverte

Une backdoor se présente souvent comme un visiteur normal : cookie de session, requête POST vers un fichier anodin, appel depuis le cron du serveur. Le WAF n'a pas de raison de la refuser. Idem pour un JavaScript injecté dans le pied de page : le HTML part déjà du serveur, le filtre amont ne le réécrit pas.

Le voisin de compte est l'angle mort classique. Si un autre site du même hébergement écrit dans votre dossier, la requête ne traverse pas Cloudflare. Elle reste locale. Isoler les sites du compte, pas seulement « mettre un WAF », est le sujet de l'isolation des sites sur un même compte.

Un attaquant qui a le mot de passe FTP ou le panel o2switch n'a pas besoin de passer le WAF. Il upload. C'est pourquoi l'ordre des mots de passe (panel d'abord) reste prioritaire, WAF ou pas. Le guide des premiers gestes rappelle cette séquence.

L'activer après le nettoyage, pas pendant

Pendant l'incident, un WAF ajouté en urgence mélange les pistes. Les journaux d'accès de l'origine se remplissent d'IP Cloudflare. Les règles cassent parfois l'admin, le tunnel de paiement, ou un webservice. On passe du temps à déboguer le filtre au lieu de comparer les fichiers.

Activez-le une fois le site propre, comme filet. Pas comme premier geste. La même logique vaut pour Wordfence ou Sucuri côté plugin : on les pose à la fin. Les installer « pour voir » pendant que le shell tourne ajoute des alertes et parfois un fichier de plus à inspecter.

Si Cloudflare est déjà devant le site depuis des mois, ne le retirez pas d'un coup : vous exposeriez l'IP d'origine et vous perdriez le cache utile. Passez plutôt en mode développement le temps de voir ce que l'origine sert vraiment. Le détail est dans Cloudflare devant un site piraté.

Le piège du cache qui ressert l'infection

Le CDN retient des copies. Vous avez retiré le JavaScript du thème, vidé le cache WordPress, et Google voit encore la redirection. Cause fréquente : le cache Cloudflare (ou celui de l'hébergeur) sert encore l'ancienne page. Les visiteurs, surtout sur mobile, restent dans la version sale.

Après nettoyage : purge complète, pas seulement « une URL ». Vérifiez aussi les Page Rules qui forcent le cache sur le HTML, les Workers qui réécrivent des réponses, et le cache objet (Redis, Memcached) s'il existe. Un objet cache qui contient un pied de page injecté survit au fichier corrigé. Voir cache objet qui ressert le malware.

Testez ensuite comme un visiteur : navigation privée, téléphone, clic depuis un résultat Google. Si l'un des trois diverge encore, le cache n'est pas le seul suspect — mais c'est le premier à écarter. Ne demandez pas un réexamen Safe Browsing tant qu'une URL sale répond 200 depuis le CDN.

• Purge globale Cloudflare + cache plugin + cache hébergeur.
• Workers et Page Rules relus, pas seulement « orange cloud ».
• Test mobile et `site:votre-domaine` avant tout réexamen Google.

Cloudflare, plugin WordPress, durcissement : trois rôles

Cloudflare (ou un WAF amont) filtre avant le serveur. Un plugin de sécurité scanne et parfois limite les connexions. Le durcissement (permissions, plus de PHP dans uploads, moins d'admins) réduit la surface. Les trois se complètent après un incident. Aucun ne remplace la comparaison des fichiers au paquet officiel.

Les vendre comme « nettoyage » est un malentendu fréquent. Un forfait « on active Cloudflare et c'est bon » laisse la porte. Un scan Wordfence « réparer tout » casse parfois un thème enfant sans retirer le cron. On nettoie, on referme, on pose les filets.

Si vous devez choisir un seul geste le soir de l'attaque : changez le mot de passe du panel, copiez le compte. Le WAF attend. Déclarer le dossier n'exige pas d'accès à l'inscription ; le prix s'affiche avant.

Réglages utiles sans se croire protégé

Une fois le site propre, quelques réglages valent le temps. Sous Cloudflare : défi pour les pays qui n'ont aucun client, restriction des URI d'administration si vous n'y touchez que depuis le bureau, WAF géré en mode « essentiel » plutôt qu'un mur de règles maison le premier soir. Chez l'hébergeur : ModSecurity s'il est proposé, sans le pousser au point de casser le checkout.

Côté WordPress : limiter les tentatives de connexion, retirer les comptes admin inutiles, interdire l'exécution PHP dans `wp-content/uploads`. Ce n'est pas un WAF. C'est du durcissement, et c'est ce qui évite la moitié des retours. Le détail des rôles est dans moins de comptes admin.

N'empilez pas trois plugins « firewall » plus Cloudflare plus un .htaccess trouvé sur un forum. Chaque couche ajoute des faux positifs. Une stack lisible se débogue ; une stack opaque se contourne et se casse.

Ce qu'il faut avoir retiré avant

Avant d'allumer le WAF, le site doit être comparable à un état sain : pas de PHP inconnu à la racine, pas de Super User / admin fantôme, pas de cron qui réécrit un fichier, pas d'option de site qui injecte du JS. Sinon vous filtrez le bruit et vous conservez la porte.

Si l'hébergeur a suspendu le compte, le WAF ne débloque rien. Il attend un constat : trouvé, retiré, corrigé. La page compte suspendu par l'hébergeur et le guide de remise en ligne détaillent ce que le support attend. Relancer toutes les heures n'accélère pas la file.

Gardez une archive hors serveur avant toute purge agressive. Un WAF mal réglé peut rendre l'admin inutilisable ; la copie permet de revenir. L'archive fournie par l'hébergeur est un état des lieux, souvent déjà infecté : on la traite comme preuve, pas comme source de restauration. Voir archive hébergeur déjà infectée.

Trente jours derrière le filtre

Le WAF réduit les tentatives. Il ne dit pas si une porte oubliée se manifeste. Surveillez trente jours : nouvelles URL dans `site:`, fichiers à la racine, admins créés, charge CPU (minage). C'est la fenêtre où un cron hebdomadaire ou un compte resté ouvert se montre. Notre garantie de suivi couvre cette période, pour la même faille.

Si une redirection conditionnelle réapparaît alors que Cloudflare est vert, ne « durcissez » pas les règles en premier. Relisez les fichiers et la base. Le filtre a peut-être tenu. La backdoor, elle, a attendu.

Un site propre derrière un WAF reste un site à tenir : mises à jour, extensions abandonnées listées, moins d'admins. Le WAF n'entretient pas le CMS. Il achète du temps si une faille publique sort demain — à condition que le reste soit déjà refermé.

• Purge CDN confirmée, tests visiteurs OK.
• Journaux WAF lus une fois, pas toutes les heures.
• Liste des extensions abandonnées pour remplacement, à froid.