Mettre un site WordPress en production, ce n’est pas seulement choisir un thème et publier du contenu. À partir du moment où vous ouvrez la porte aux visites, vous ouvrez aussi des portes aux scanners, aux tentatives de connexion automatiques et aux acteurs qui testent des failles connues. J’ai déjà vu des incidents “sans histoire” au départ, avec quelques centaines de requêtes suspectes par heure, puis un rebond: un utilisateur administrateur créé à l’improviste, une page d’accueil modifiée, ou un script injecté qui télécharge un chargement malveillant quelques secondes après le chargement du navigateur.
Un système de détection d’intrusion n’empêche pas tout, mais il change radicalement la dynamique. Au lieu de découvrir l’incident après coup, souvent via un navigateur qui affiche “site dangereux” ou via des alertes de blocage, vous cherchez des signaux tôt, vous logguez proprement, et vous pouvez réagir avec méthode.
Ce que “détection d’intrusion” veut dire pour WordPress
Le terme “détection” peut recouvrir plusieurs couches. Pour un WordPress, on observe généralement trois types d’événements.
D’abord, les attaques “front door”: tentatives d’authentification sur wp-login.php, brute force, et surtout des patterns d’énumération d’utilisateurs (mêmes erreurs, mais avec des réponses différentes selon l’existence du compte).
Ensuite, la compromission applicative ou la tentative de compromission: appels à des endpoints sensibles, tentatives d’exécution de fichiers, injections dans des fichiers PHP, et modifications de base de données. WordPress n’est pas “un serveur d’applications” comme un autre, il a son rythme, ses tables, ses hooks, et ses comportements attendus. Toute dérive se repère dans les logs web, les logs d’application, et la surveillance du système de fichiers.
Enfin, les indices “réseau et infra”: requêtes depuis des pays ou des ASN inhabituels, pics de trafic non corrélés au contenu publié, et connexions sortantes anormales depuis le serveur (par exemple, vers des domaines nouvellement créés).
Un bon système combine ces signaux. L’erreur fréquente consiste à installer un module et à le laisser faire sans définir de politique de réponse. Détecter, c’est utile seulement si vous savez quoi vérifier et quoi faire quand l’alerte remonte.
Avant d’installer quoi que ce soit: clarifier votre terrain de jeu
Avant même de choisir un plugin ou une brique de type WAF, prenez cinq minutes pour répondre à une question simple: où est hébergé votre WordPress et qui fait quoi?
- Si vous êtes derrière un CDN ou un pare-feu géré (souvent chez un hébergeur ou une plateforme de protection), certains événements ne seront jamais visibles côté serveur. Si vous avez un accès shell (SSH), vous pouvez renforcer la détection avec des logs système et des vérifications d’intégrité. Si vous êtes en hébergement mutualisé sans accès avancé, vous dépendrez davantage des plugins de sécurité et des logs d’accès WordPress.
Cette clarification change aussi la manière de configurer. Par exemple, activer trop de règles “bloquantes” sur un site qui utilise un formulaire de connexion custom, ou un plugin de logins sociaux, peut générer des faux positifs. Et même un faux positif à répétition devient un problème de disponibilité.
Choisir une approche: plugin, WAF, ou système hybride
Pour WordPress, la route la plus rapide consiste à combiner plusieurs niveaux:
1) un pare-feu applicatif ou des règles au niveau web (idéalement avant WordPress),
On retrouve souvent ces options sous forme de plugins ou via un service externe. Sur le plan pratique, voici ce que j’ai constaté en mission: les plugins font bien le travail sur la surface applicative, mais la qualité des alertes dépend beaucoup de la configuration des logs et de la façon dont le site gère ses requêtes. Un WAF ou un service de protection en amont est plus fort contre les volumes et les patterns simples, mais il faut garder une visibilité côté serveur pour investiguer un incident.
Le plus sain est un modèle hybride, même léger: un filtre en amont pour réduire le bruit, et une détection plus “fine” côté serveur pour conserver une trace exploitable.
Installer un système de détection: la méthode sans douleur
Vous pouvez bâtir votre système en suivant un ordre qui limite les interruptions.
1) Préparer la base: sauvegardes, logs, et accès
Avant toute modification de sécurité, confirmez que vous pouvez revenir en arrière. Une sauvegarde “clean” permet de tester que rien n’est déjà compromis et que les règles que vous activez n’endommagent pas des fonctionnalités.
Ensuite, assurez-vous que vous avez des logs utiles. Un système de détection sans données exploitables revient à écouter un bruit sans pouvoir identifier la source.
Dans WordPress, vous voulez au minimum des journaux d’accès (requêtes web, codes de réponse), des journaux applicatifs (échecs de connexion, erreurs de plugin), et l’historique des modifications si possible (par exemple, changements de thèmes et de plugins, ou actions admin).
2) Ajouter une couche de protection web en amont
Si votre hébergeur ou votre CDN propose un pare-feu avec règles, c’est souvent le meilleur point de départ pour réduire le volume des attaques qui visent wp-login.php ou des chemins sensibles. L’objectif n’est pas de “tout bloquer”, mais de diminuer les tentatives évidentes.
Au niveau WordPress, les plugins de sécurité offrent des capacités proches, comme des règles de filtrage, des limitations de tentatives, et parfois des signatures d’attaques. Selon votre configuration, vous choisirez l’un ou l’autre, ou vous combinerez.
Je préfère une approche pragmatique: commencer avec des règles en mode surveillance (si l’outil le permet), observer la génération d’alertes, puis passer à des mesures de blocage quand vous comprenez les faux positifs.
3) Déployer la détection côté WordPress et consolider l’observabilité
C’est ici que vous construisez votre “système de détection” au sens utile. Concrètement, vous voulez des alertes sur des événements qui indiquent une tentative de compromission ou une activité non cohérente.
Les meilleurs signaux, dans un environnement WordPress, tournent autour de:
- échecs répétés sur la connexion, accès à des fichiers et répertoires inattendus, répétition de requêtes sur des chemins connus pour être explorés lors d’attaques, modifications de fichiers PHP ou changements de thèmes/plugins, création d’utilisateurs ou élévation de privilèges.
Certains plugins proposent aussi des “audit logs” pour des actions admin. Si vous pouvez collecter ces événements de façon fiable, vous réduisez énormément le temps d’investigation.
4) Configurer des réponses progressives, pas des murs de blocage
Une fois que les alertes existent, vous devez décider du niveau d’action. La réponse peut aller de la simple notification à un blocage temporaire. La meilleure pratique que j’applique presque toujours consiste à commencer par l’observation et la mise en quarantaine douce (limitation, challenge, ou blocage temporaire sur les patterns répétitifs).
Le piège classique consiste à activer trop tôt des protections “strictes” et à bloquer des scénarios légitimes: bot de moteur qui visite trop vite, plugin d’import qui appelle des URLs, ou test de monitoring qui se connecte via un compte de service.
Voici un exemple de progression que j’utilise quand je mets en place une protection site WordPress avec une logique de détection, sans casser l’activité:
- commencer en mode journalisation et alerter sur les événements à risque, ajuster les exceptions pour les endpoints indispensables, activer des actions automatiques sur des patterns clairs (brute force, répétitions d’erreurs), puis durcir progressivement après une période d’observation.
5) Vérifier et tester comme si vous étiez l’attaquant (sans nuire)
Testez la détection sans tenter d’exploits dangereux. Vous pouvez provoquer des signaux https://gardewp.fr/securite-wordpress/ contrôlés: par exemple, tenter des connexions avec des identifiants incorrects pour vérifier que le système alerte, ou vérifier que la modification de certains éléments déclenche une alerte d’intégrité si l’outil le propose.
Dans un environnement réel, je fais aussi un test de cohérence: je vérifie qu’une alerte renvoie assez d’informations pour investiguer, comme l’IP source, le user-agent si disponible, l’horodatage précis, et la règle ou la signature déclenchée.
Liste de configuration initiale (courte)
- Activer les logs d’accès et applicatifs nécessaires avant d’activer les règles sensibles Mettre les protections en mode “surveillance” pendant quelques jours si c’est proposé Définir un canal d’alerte (email, webhook, ou journal central) Prévoir une fenêtre de test sur les heures de faible trafic Documenter les exceptions (IPs internes, outils de monitoring, endpoints légitimes)
Les types d’alertes à privilégier, et ceux qui deviennent du bruit
Le problème des systèmes de détection, ce n’est pas qu’ils détectent trop peu. Souvent, c’est l’inverse: ils détectent trop, et vous perdez confiance dans les alertes.
Une alerte utile a trois propriétés: elle est contextualisée, elle est répétable, et elle indique une direction d’action.
Alertes généralement utiles pour WordPress
Dans les incidents que j’ai gérés, les alertes les plus actionnables sont celles liées à l’authentification et aux changements.
Quand un attaquant tente de créer un compte, ou lorsqu’il observe le comportement de WordPress via plusieurs requêtes sur les mêmes endpoints, vous voyez des patterns. Les systèmes de détection qui regroupent ces patterns par source et par temps sont plus utiles que ceux qui alertent sur chaque requête isolée.
Pareil pour les modifications de fichiers: une alerte d’intégrité sur un fichier PHP inattendu ou sur un changement de thème ou de plugin est plus “décisionnelle” qu’un simple blocage d’une requête.
Les alertes qui deviennent du bruit
Le bruit vient souvent des bots légitimes ou des outils de service.
Par exemple, si votre site utilise un service d’optimisation ou un crawler SEO, vous pouvez recevoir des alertes sur des requêtes répétées. Si votre WordPress a une dépendance à un plugin qui effectue des appels vers des URLs internes, certaines règles “scan” peuvent se déclencher.
La règle d’or: vous ne voulez pas supprimer toutes les alertes, vous voulez réduire les faux positifs en affinant les exceptions et la granularité.
Voici un second repère, utile en pratique, pour distinguer ce qui mérite une vérification rapide et ce qui peut attendre:
- Alerte sur échecs de connexion concentrés sur un petit nombre d’IP sur une courte période Alerte sur création d’utilisateur, changement de rôle, ou modifications de configuration admin Alerte sur modifications d’intégrité sur des fichiers PHP ou des emplacements inattendus Alerte sur accès répétés à des endpoints sensibles en dehors de vos habitudes
Je limite volontairement à ce cadre, car au-delà vous risquez de tout traiter comme critique. Le but est d’avoir une hiérarchie d’investigation, sinon vous finissez par “submerger” votre propre procédure.
Politiques de blocage et gestion des faux positifs
Le passage de la détection au blocage est le moment où les systèmes se révèlent ou se dégradent.
Le dilemme: sécurité stricte versus accessibilité
Si vous bloquez trop agressivement, vous cassez des scénarios réels. Si vous bloquez pas assez, vous subissez du bruit et vous perdez du temps d’investigation.
Mon approche consiste à établir une politique graduelle selon le risque:
- Pour les tentatives de login manifestement abusives: limitation, challenge, ou blocage temporaire. Pour les comportements exploratoires sans preuve de compromission: observation d’abord, puis durcissement si ça se répète. Pour les changements de fichiers ou les signaux d’intégrité: intervention immédiate, vérification de la source, et restauration si nécessaire.
Exemples concrets de faux positifs que j’ai vus
Sur des sites WordPress, les faux positifs viennent souvent de l’intégration.
Un cas fréquent: un plugin d’import ou un automatisme de maintenance qui appelle wp-admin et déclenche des règles de brute force ou de scan. Un autre cas: un outil de supervision qui tente de “se connecter” pour vérifier la disponibilité, sans passer par la bonne route (ou avec un user-agent inattendu).
La correction n’est pas uniquement “désactiver la règle”. Je préfère identifier le chemin exact, comprendre le trafic légitime, puis ajouter une exception ciblée. Cela garde la valeur de la détection.
Durcir après coup: intégrité des fichiers et suivi des changements
La détection d’intrusion ne sert pas seulement à dire “il y a eu une attaque”. Elle doit vous aider à répondre à une question plus importante: “est-ce que quelqu’un a réussi?”.
Pour WordPress, la piste la plus robuste est la surveillance de l’intégrité des fichiers, et le suivi des changements dans le répertoire des uploads, des thèmes et des plugins.
Le répertoire wp-content/uploads est le premier endroit où des scripts malveillants peuvent apparaître sous forme de fichiers inattendus, parfois en masquant avec de petites variations de noms. Les thèmes et plugins sont une autre zone, surtout si un plugin a été ajouté, modifié, ou si un fichier PHP a été altéré.
La base de données est la troisième dimension. Je ne recommande pas d’automatiser à l’aveugle des restaurations sans avoir un diagnostic, car une restauration trop large peut effacer des changements légitimes (contenu, configuration, commandes). Ce qui fonctionne bien est la combinaison: alerte sur changement, puis vérification ciblée.
Centraliser les alertes et améliorer votre capacité d’investigation
Un système de détection local qui envoie un email, c’est bien. Un système qui vous aide à investiguer vite, c’est mieux.
Dans la pratique, vous gagnerez énormément si:
- les alertes incluent l’horodatage précis, vous avez la source (IP) et si possible des éléments comme user-agent, les événements sont reliés à des actions admin quand c’est disponible, et vos logs web restent accessibles suffisamment longtemps pour recouper.
Je recommande aussi de stocker vos règles et vos configurations de manière traçable. Quand un incident survient, vous voulez savoir exactement quelle version du plugin de sécurité était installée, et quelles règles étaient actives à l’époque.
Mettre en place un cycle simple: observer, ajuster, documenter
Un système de détection qui ne bouge jamais devient vite inefficace. Les attaques changent, les outils aussi.
Le cycle que j’ai vu marcher le mieux ressemble à ça, sans lourdeur:
- Sur une période courte, vous analysez les alertes récurrentes. Vous ajustez les exceptions et la sensibilité. Vous durcissez progressivement. Vous documentez les décisions, au moins pour vous rappeler pourquoi une exception existe.
La documentation n’a pas besoin d’être longue. Juste quelques lignes sur ce que vous avez ajouté et pourquoi suffisent. Elle vous épargne des heures quand vous revenez sur le sujet après un incident ou une mise à jour.
Un mot sur WordPress updates et dépendances
Un point souvent négligé: la meilleure détection du monde ne compense pas une application vulnérable.
WordPress, thèmes et plugins doivent rester à jour quand c’est possible, surtout sur les composants qui exposent des fonctionnalités d’authentification ou des endpoints. Une configuration de détection peut vous prévenir d’une tentative, mais si la surface est fragile, un attaquant peut réussir avant même que vous compreniez.
D’où une règle que je garde en tête: traiter la détection comme un filet de sécurité, pas comme une seule barrière. Mettre à jour, réduire la surface (plugins inutiles), et surveiller les changements doivent aller ensemble.
Quand il faut réagir “comme en incident”, pas comme en alerte
Il existe un moment où vous ne voulez plus “observer”, vous voulez agir. En général, ça arrive quand vous avez un signal sur la compromission potentielle.
Quelques indices qui méritent une vérification immédiate:
- modifications d’intégrité sur des fichiers PHP hors des mises à jour prévues, création d’un utilisateur avec des rôles élevés, apparition d’un thème ou plugin que vous n’avez pas installé, modifications de fichiers dans des emplacements inattendus, récurrence d’erreurs qui se transforment soudainement en activité normale (signe parfois d’un script déjà en place).
La réaction n’a pas besoin d’être spectaculaire, mais elle doit être structurée: vérifier la chronologie, comparer avec ce que vous avez déployé, isoler si nécessaire (par exemple mettre le site en maintenance le temps de diagnostiquer), puis restaurer ou assainir en dernier ressort.
Checklist rapide d’exploitation après installation
Vous n’avez pas besoin d’un gros plan, juste une discipline.
Assurez-vous d’avoir des réponses prêtes pour les alertes majeures, que ce soit une vérification des utilisateurs admin, un contrôle des fichiers modifiés, ou une vérification des logs d’accès.
Et surtout, testez votre procédure. Un système de détection “qui marche” n’est pas seulement un plugin avec des graphiques, c’est une chaîne complète, de l’alerte à la décision.
Si vous voulez, dites-moi votre contexte (hébergement avec accès SSH ou non, présence d’un CDN/WAF, volume de trafic, plugins utilisés). Je pourrai vous proposer une stratégie de déploiement plus précise, adaptée à votre niveau de visibilité et à votre tolérance aux faux positifs.