Firewall WAF WordPress : comment il bloque les attaques web

La plupart des attaques contre WordPress commencent par une simple requête web. Un robot envoie une adresse piégée, un formulaire rempli de code ou des milliers de tentatives de connexion par minute. Un pare-feu applicatif, appelé WAF, filtre ces requêtes avant qu'elles n'atteignent votre site. Voici comment il fonctionne, ce qu'il bloque réellement, ses limites et comment le régler sans gêner vos visiteurs.

Comprendre le rôle d'un pare-feu applicatif

Un pare-feu classique, celui d'un hébergeur ou d'une box internet, contrôle qui a le droit de se connecter à quel port. Il ne regarde pas le contenu des échanges. Un pare-feu applicatif, ou WAF pour Web Application Firewall, fait l'inverse : il lit chaque requête envoyée à votre site, examine l'adresse, les paramètres, les formulaires et les en-têtes, puis décide si elle peut passer.

Concrètement, quand quelqu'un tente d'insérer une commande de base de données dans un champ de recherche, ou un script dans un commentaire, le WAF reconnaît le motif et bloque la requête. WordPress ne la voit jamais.

Tous les sites exposés sur internet sont concernés, car le trafic malveillant est permanent et automatisé. Il suffit d'ouvrir les journaux d'un site récent pour voir défiler des tentatives sur des fichiers qui n'existent même pas sur votre installation.

L'erreur fréquente est de croire qu'un WAF rend les mises à jour facultatives. Un pare-feu bloque les attaques qu'il sait reconnaître. Une faille inédite, ou exploitée d'une manière que ses règles ne couvrent pas, peut passer. Le WAF réduit le risque et vous fait gagner du temps entre l'annonce d'une faille et sa correction ; il ne remplace pas la correction.

Les enjeux : ce qu'un WAF bloque et ce qu'il ne bloque pas

Un pare-feu applicatif bien réglé traite plusieurs familles d'attaques :

• Les injections SQL : du code ajouté dans un paramètre pour lire ou modifier votre base de données, par exemple pour créer un compte administrateur.
• Le cross-site scripting, ou XSS : un script injecté dans une page, qui s'exécute ensuite dans le navigateur de vos visiteurs ou de vos administrateurs.
• Les rafales de requêtes : un robot qui envoie des centaines de requêtes en peu de temps, pour deviner un mot de passe ou saturer le serveur.
• L'accès aux fichiers sensibles : tentatives de lecture de wp-config.php, de fichiers de sauvegarde ou de journaux.
• Les scanners automatiques : outils qui testent des listes de failles connues sur des milliers de sites.

En revanche, un WAF ne protège pas contre un mot de passe administrateur volé et utilisé normalement, contre une extension piratée que vous avez installée vous-même, ni contre un accès FTP compromis. Il ne nettoie pas non plus un site déjà infecté : c'est le rôle du scan et du nettoyage.

Il existe deux grandes architectures. Le WAF cloud se place devant le site via une modification des DNS : tout le trafic passe par un service tiers. Le WAF applicatif s'exécute sur votre serveur, au niveau de PHP ou de WordPress. Le premier encaisse mieux les gros volumes ; le second voit le contexte réel de l'application et ne demande aucune modification DNS. Les deux approches sont sérieuses, le choix dépend de votre site et de votre hébergement.

Limitation des rafales et géo-blocage

Deux réglages complètent utilement le filtrage des requêtes. La limitation des rafales, parfois appelée rate limiting, fixe un nombre maximal de requêtes qu'une même adresse peut envoyer dans un intervalle donné. Un visiteur humain n'envoie jamais cinquante tentatives de connexion par minute ; un robot, si. Au-delà du seuil, l'adresse est ralentie ou bloquée temporairement. C'est la réponse la plus directe aux attaques par force brute, qui consistent à essayer des milliers de mots de passe.

Le géo-blocage restreint l'accès à certaines pages selon le pays d'origine de la connexion. Appliqué à l'ensemble du site, il priverait votre boutique de clients à l'étranger. Appliqué uniquement à l'administration, wp-admin et la page de connexion, il est très efficace : si vous et vos prestataires travaillez depuis la France, personne n'a besoin de se connecter depuis l'autre bout du monde. Il faut simplement penser aux déplacements et aux prestataires installés ailleurs.

Les journaux du pare-feu

Un pare-feu produit des journaux qui racontent ce qu'il a bloqué, quand et pourquoi. Les consulter de temps en temps permet de repérer une attaque ciblée, une extension qui attire les robots ou un faux positif qui gêne vos clients. Ils servent aussi après un incident : ils permettent de reconstituer la chronologie d'une attaque, de savoir quelle page était visée et depuis quand. Conservez-les assez longtemps, quelques semaines au minimum, et vérifiez qu'ils ne contiennent pas de données personnelles inutiles, comme des mots de passe saisis dans un formulaire.

Cas concrets

L'artisan et les connexions en rafale

Le site d'un plombier ralentit chaque nuit. Les journaux montrent des milliers de tentatives de connexion sur la page wp-login.php. La limitation des rafales de requêtes et le géo-blocage de l'administration, réservée à la France, font disparaître le problème, et le serveur retrouve sa charge normale.

La boutique WooCommerce et la faille d'extension

Une boutique de jouets utilise une extension de filtres de produits. Une faille d'injection SQL est publiée un samedi. Le pare-feu bloque les tentatives d'exploitation reçues dès le soir même, et le gérant applique la mise à jour le lundi sans incident.

Le cabinet médical et le formulaire de contact

Le formulaire de contact d'un cabinet de kinésithérapie reçoit des messages contenant du code. Le WAF bloque les tentatives de XSS visant l'interface d'administration, là où les messages sont lus.

L'agence et le faux positif

Une agence voit un client bloqué lors de l'import d'un fichier de produits. Le journal du pare-feu indique la règle déclenchée. Une exception limitée à cette page d'import règle le problème, sans désactiver la protection ailleurs.

Méthode pas à pas

1. Faire l'état des lieux : consultez les journaux d'accès de votre hébergement pour voir quelles attaques visent déjà votre site et à quelle fréquence.
2. Choisir l'architecture : WAF cloud, WAF applicatif ou combinaison des deux, selon votre trafic, votre hébergement et votre capacité à modifier les DNS.
3. Activer en mode observation si possible : laissez le pare-feu journaliser sans bloquer pendant quelques jours pour repérer les faux positifs.
4. Passer en mode blocage : activez le filtrage des injections SQL et XSS, ainsi que la limitation des rafales de requêtes sur la connexion et les formulaires.
5. Protéger l'administration : limitez l'accès à wp-admin aux pays où vous et vos prestataires travaillez, et activez la double authentification.
6. Durcir la configuration : désactivez l'édition des fichiers depuis l'administration et bloquez l'exécution de PHP dans le dossier des médias. Dans wp-config.php :

define( 'DISALLOW_FILE_EDIT', true );

7. Surveiller et ajuster : relisez les journaux chaque mois, ajoutez des exceptions ciblées en cas de faux positif, et vérifiez que les règles se mettent à jour.

Bonnes pratiques

• Combinez le WAF avec des mises à jour régulières : l'un couvre la fenêtre d'exposition, l'autre ferme la faille.
• Créez des exceptions précises, limitées à une page ou un paramètre, jamais une désactivation globale.
• Protégez spécialement les pages sensibles : connexion, formulaires, paiement, recherche.
• Gardez les journaux du pare-feu assez longtemps pour reconstituer une attaque.
• Testez votre site après chaque changement de règles : commande, formulaire, connexion.

Erreurs fréquentes à éviter

• Considérer le WAF comme une raison de repousser les mises à jour.
• Désactiver tout le pare-feu au premier faux positif.
• Bloquer l'administration par pays sans prévoir l'accès de votre prestataire basé à l'étranger.
• Ne jamais consulter les journaux et ignorer qu'une attaque ciblée est en cours.

Comment V-Shield vous aide

V-Shield intègre un pare-feu applicatif qui filtre les injections SQL et XSS, limite les rafales de requêtes et permet le géo-blocage de wp-admin. Il applique aussi un durcissement de la configuration WordPress, comme la désactivation de l'éditeur de fichiers. Le WAF fonctionne avec le reste de la plateforme : mises à jour avec retour arrière, scan automatique et alertes en cas de dérive, par exemple l'apparition d'un nouvel administrateur. Voyez comment ces briques s'articulent sur la page des fonctionnalités, ou comparez notre approche avec celle de Sucuri et son WAF cloud. Pour aller plus loin, lisez notre article sur les vulnérabilités WordPress, notre comparatif des plugins de sécurité et notre guide pour sécuriser WordPress.

Bloquez les attaques avant qu'elles n'atteignent WordPress : activez la formule Pro, sans engagement.