Pare-feu applicatif, plugin de sécurité, durcissement : qui fait quoi

Trois couches, pas trois synonymes

Un WAF (Cloudflare, Sucuri Firewall, ModSecurity chez l'hébergeur) lit la requête avant le PHP. Un plugin (WordFence, iThemes, Solid Security) tourne dans WordPress : scan de fichiers, limite de connexions, parfois un mini-pare-feu PHP. Le durcissement, ce sont des réglages : moins d'admins, pas de PHP dans les uploads, permissions, versions tenues, isolation de compte.

Les trois mots se mélangent dans les devis. « On installe un firewall » peut vouloir dire n'importe laquelle. Demandez laquelle, et à quel moment. Pendant l'attaque, poser les trois à la fois ajoute du bruit : journaux illisibles, admin cassé, faux positifs sur le thème enfant.

Cloudflare ou un WAF après piratage détaille le filtre amont. Ici on compare les rôles, pour ne pas en acheter un en croyant avoir les trois.

Pendant l'incident : ce qu'on ne pose pas

L'ordre utile reste : constater, copier, mot de passe panel, ticket hébergeur, tests visiteurs, puis nettoyer. Un plugin de sécurité au milieu de cette liste crée des fichiers, des cron, parfois une « réparation » qui écrase un template légitime. Installer un plugin pendant l'attaque : on ne le fait pas.

Un WAF allumé en urgence masque l'IP réelle dans les access.log et peut bloquer votre propre SFTP web ou l'admin. Si Cloudflare est déjà là, mode développement ; on n'empile pas un second WAF « pour voir ».

Le durcissement trop tôt (permissions 444 partout, .htaccess copié d'un forum) casse l'affichage et détruit des preuves. On durcit après comparaison des fichiers, pas comme premier geste. Le guide premiers gestes tient en six lignes ; aucun outil n'y figure.

• Pas de « cleaner » comme seul traitement.
• Pas de WAF nouveau le soir de l'alerte, sauf déjà en place.
• Pas de durcissement copié-collé avant inventaire.

Le WAF amont, ce qu'il voit

Il voit le trafic qui arrive de l'extérieur. Il ne voit pas un cron local, un PHP voisin qui écrit chez vous, un utilisateur admin déjà connecté. Il ne vide pas une option `site` en base. Il ne purge pas tout seul un Worker malveillant — encore faut-il ouvrir le tableau Cloudflare.

Utile après nettoyage : moins de scans, défi sur des URI d'admin, parfois un masquage d'IP d'origine. Piège : cache qui ressert du HTML sale, journaux d'origine vides. Cloudflare proxy.

ModSecurity chez OVH, o2switch ou IONOS : même famille. Une règle trop agressive casse un webservice ou un checkout. On l'active en mode raisonnable une fois le métier testé, pas comme preuve envoyée au support (« voyez, j'ai un WAF, rouvrez »). Le support veut un constat, pas un logo. Compte suspendu.

Le plugin dans le CMS, ce qu'il voit

Il voit les fichiers de « son » site, parfois la base, parfois les connexions wp-login. Il ne voit pas le parked domain, le zip à côté, le cron système du panel. Un scan « 0 résultat » n'est pas un feu vert. Un scan « 200 résultats » n'est pas une liste d'ordres de suppression : thèmes enfants, cache, encodage légitime.

Wordfence « réparer tout » a cassé plus d'un enfant de thème dans les dossiers que nous reprenons. On s'en sert comme liste de suspects, on compare au zip officiel. Tests avant de déclarer victoire.

Un plugin de sécurité abandonné est une extension comme une autre : surface, cron, parfois privilèges. Extensions abandonnées. N'en empilez pas trois.

Le durcissement, ce qui reste quand on éteint les outils

Moins de comptes admin. Pas de PHP exécutable dans les médias. Versions tenues, abandonnés listés. Isolation de compte. Mots de passe distincts panel / CMS / mail. Sauvegardes hors serveur. C'est moins vendable qu'un tableau de bord vert. C'est ce qui évite la moitié des retours.

Moindre privilège et isolation sont du durcissement. Aucun plugin ne les pose à votre place. Aucun WAF ne retire un stagiaire admin de 2019.

Le durcissement se documente : une page interne, trois captures. Après un ticket d'abus, cette page devient le constat de « ce qui a été corrigé », au-delà du fichier retiré.

« Réparer tout » et autres raccourcis

Réparer, scanner, activer le WAF, réinstaller le cœur par-dessus : quatre raccourcis, quatre façons de garder la porte. Réinstaller WordPress sans comparer laisse mu-plugin, cron, voisin. Réinstaller WordPress après piratage.

Un scan distant (Sitecheck et équivalents) voit ce qu'un visiteur voit. Utile en test final, inutile comme unique preuve pour l'hébergeur si le malware est conditionnel. Croisez avec Search Console et un téléphone.

Payer pour « un firewall à vie » pendant que le shell tourne finance un abonnement, pas un nettoyage. Coût réel d'un piratage : le forfait visible n'est pas le préjudice.

L'ordre une fois le site propre

1) Durcissement minimum (comptes, PHP uploads, secrets). 2) Plugin de sécurité unique, réglages calmes, pas « réparer tout » en boucle. 3) WAF amont si vous en avez déjà un, ou si le trafic de scans est réel ; purge de cache. 4) Surveillance trente jours. Garantie 30 jours.

Joomla, Drupal, PHP sur mesure : le plugin WordPress n'existe pas. Le WAF et le durcissement, si. Joomla, Drupal, site PHP.

Si vous hésitez entre les trois produits marketing, prenez le durcissement et un constat. Les outils s'ajoutent. Créer un espace n'inclut pas l'obligation d'acheter un WAF.

Ce qu'un forfait à 49 € confond souvent

Beaucoup de forfaits bas de gamme vendent un scan + un plugin + « on active Cloudflare ». Ce n'est pas un nettoyage. Demandez : comparaison aux zips officiels ? revue des comptes ? cron ? voisin de compte ? constat écrit ? garantie sur la même faille ? Choisir un prestataire.

Un délai magique (« clean en 1 h ») ignore l'archive hébergeur, les journaux, la blacklist. Le nettoyage tient souvent en un à trois jours ouvrés ; les listes, davantage. Confondre les horloges crée de fausses urgences et de faux devis.

Nous affichons un prix avant l'accès. Nous ne vendons pas le WAF comme un substitut. Si vous voulez seulement comprendre la couche, cette page suffit ; si le site est encore sale, le protocole de premiers gestes prime.