Gérer une protection WordPress sérieuse, ce n’est pas seulement installer un plugin ou durcir quelques réglages. La vraie différence se joue souvent après coup, quand quelque chose a l’air “bizarre” et que vous devez remonter la piste avant que l’incident ne se propage. Et pour ça, les logs serveur sont votre meilleur témoin.
Sur le papier, “surveiller les logs” ressemble à une tâche technique, presque abstraite. Dans la pratique, j’ai vu des attaques se révéler en quelques lignes, parce qu’un pic d’erreurs, une URL répétée, ou une vague de requêtes vers des endpoints inexistants finissait par raconter l’histoire complète. L’enjeu, c’est d’apprendre à lire ces signaux avec méthode, sans noyer votre équipe dans du bruit.
Les logs ne servent pas à “faire joli”, ils servent à trancher
Un incident WordPress a rarement un début spectaculaire. Souvent, il commence par des indices discrets :
- des tentatives de connexion répétées, des requêtes à des fichiers qui ne devraient pas être accessibles, des réponses 404 ou 403 en hausse, des erreurs PHP récurrentes après un déploiement, des pics sur certains répertoires, certains noms de scripts, ou certains schémas d’URL.
Les logs vous donnent une chronologie. Sans chronologie, vous pouvez deviner, mais rarement agir avec précision. Avec une chronologie claire, vous pouvez répondre à trois questions qui comptent vraiment :
1) Est-ce que quelqu’un cherche, ou est-ce que quelqu’un a déjà trouvé ?
2) Est-ce une tentative isolée, ou un mouvement coordonné ? 3) Quel périmètre est potentiellement impacté : compte, thèmes, fichiers, base de données, ou configuration web ?Ce que les attaquants laissent derrière eux dans un environnement WordPress
WordPress est une cible très documentée. Du coup, une partie des attaques suit des schémas “classiques”. Cela ne veut pas dire qu’elles sont simples, mais qu’elles laissent des traces. Par exemple, beaucoup de bots explorent des chemins connus, testent des points d’entrée avant de tenter l’authentification, ou déclenchent des erreurs pour voir comment le serveur répond.
Il existe aussi des attaques “moins bruyantes”. Un bot peut réduire le rythme pour éviter les seuils, ou répartir les requêtes. Même là, les logs finissent par montrer des patterns, surtout quand vous comparez avec une base “normale” de votre trafic.
Et puis il y a le cas fréquent que j’ai rencontré plus d’une fois : l’incident n’est pas “une attaque” au sens strict, mais un comportement anormal provoqué par un plugin défaillant, un cron mal configuré, ou une migration incomplète. Les logs vous aident à distinguer ce qui ressemble à une attaque de ce qui ne l’est pas.
Les bons logs à surveiller (et ceux qui vous feront perdre du temps)
Selon votre hébergement, votre stack peut varier: Nginx ou Apache, PHP-FPM, CDN en amont, WAF, conteneurs Docker, etc. L’idée n’est pas d’ouvrir tous les fichiers et de prier. L’idée est de choisir les sources qui répondent le mieux à vos hypothèses de menace.
Voici les sources de logs les plus utiles dans un contexte WordPress, avec un intérêt concret pour la détection :
- logs web (Nginx ou Apache) : URL demandées, codes HTTP (200, 401, 403, 404, 500), latence, taille des réponses logs PHP-FPM / PHP (erreurs et warning) : traces d’exceptions, erreurs de scripts, index non trouvés, limites mémoire logs d’authentification : tentatives de connexion, échecs, patterns de mots de passe, parfois IP de provenance logs système (auth, syslog) si disponibles : connexions SSH, exécutions de commandes, escalades suspectes logs applicatifs WordPress (si configurés) : erreurs WP_DEBUG, activités liées à des plugins, journaux d’audit quand ils existent
Le point clé : vous voulez des logs qui permettent de relier une requête à une action. Si vous n’avez que des métriques globales, https://gardewp.fr/securite-wordpress/ vous serez aveugle sur l’objet précis de la demande.
Mettre en place une lecture “orientée hypothèses”
Surveiller des logs, c’est aussi un exercice de discipline. Sans méthode, on finit par regarder un flux et chercher “quelque chose qui choque”, ce qui fatigue et conduit à rater l’essentiel.
Une approche pragmatique consiste à partir d’hypothèses réalistes. Par exemple :
- Un attaquant essaie de forcer la connexion, donc vous devez surveiller les échecs d’auth et les tentatives répétées. Un attaquant explore des chemins, donc vous devez repérer les suites d’URL avec des codes 404 ou 403 en rafale. Un attaquant tente une exploitation PHP, donc vous devez croiser les requêtes avec des erreurs PHP et des réponses 500. Un incident vise à déposer ou exécuter du code, donc vous cherchez des signes d’accès à des fichiers sensibles (directement ou indirectement via l’application).
Ensuite, vous vous limitez à quelques indicateurs. Dans mon expérience, mieux vaut cinq signaux fiables qu’une centaine d’alertes inutiles.
Construire une base de référence, sinon les alertes vous mentent
La partie la plus sous-estimée, c’est la normalité. Un serveur qui reçoit des visites légitimes, des crawlers SEO, du trafic d’admin et des appels de plugins aura des “bruits” qui ressemblent parfois à des attaques.
La normalité dépend fortement de votre site, de votre audience, et de votre topologie. Un site e-commerce en campagne n’a pas le même profil qu’un blog statique. Un site derrière un CDN peut montrer des IP “banales” au lieu de vraies origines. Les codes HTTP peuvent aussi varier selon la config.
Concrètement, si vous créez des alertes sur un pic sans contexte, vous risquez d’avoir trop de faux positifs. La solution n’est pas forcément de baisser la sensibilité, mais de comprendre :
- à quelle heure le trafic explose chez vous, quels chemins sont naturellement demandés, quels user agents sont habituels, quelle proportion de 404 et 403 est “normale”.
Même une comparaison manuelle, sur quelques semaines, peut suffire à poser des limites raisonnables.
Les signaux d’attaque les plus fréquents dans les logs web
Quand je dois analyser un incident, je ne commence pas par “tout relire”. Je commence par regarder les tendances et la cohérence entre éléments.
Dans les logs web, voici ce qui attire l’attention, surtout si les volumes montent rapidement:
1) répétitions d’URL inhabituelles, en particulier avec paramètres
2) codes HTTP 401 et 403 à répétition sur des endpoints d’authentification 3) 404 très nombreux vers des chemins qui semblent “testés” en boucle 4) 500 en corrélation avec une série de requêtes structurées 5) temps de réponse instable ou hausse de latence, qui peut accompagner une charge anormaleLe piège est de confondre un pic de 404 causé par un lien cassé ou un changement de routing avec un balayage automatisé. Le contexte est décisif: l’attaquant suit souvent un pattern de requêtes, pas juste un chemin isolé.
Croiser les logs: la méthode qui évite de se tromper
Le grand avantage de WordPress, c’est qu’il existe une séparation naturelle entre le “web” (vos requêtes HTTP) et le “runtime” (PHP qui exécute). Quand les deux racontent la même histoire, vous avez une preuve plus robuste.
Par exemple, si vous voyez :
- un ensemble d’URL vers un script PHP particulier, en même temps des erreurs PHP similaires, et des réponses HTTP 500 ou des délais inhabituels,
Vous avez un point de départ solide. À l’inverse, des 404 seuls, sans erreurs PHP, peuvent correspondre à un scanning de surface ou à du trafic de bots, parfois sans impact direct.
Autre scénario fréquent : vous voyez des tentatives de login, mais pas d’erreurs PHP. Dans ce cas, l’attaque cible l’authentification plutôt que l’exécution de code. Votre réponse sera différente.
Un petit cas vécu, typique et instructif
Sur un WordPress à taille moyenne, on a d’abord remarqué une hausse progressive des 403 sur des URL qui n’existaient pas. Rien de dramatique, les erreurs n’explosaient pas. Puis, en croisant Nginx et PHP, on a découvert que certaines requêtes provoquaient aussi des warnings PHP récurrents. Le point déclencheur a été la corrélation temporelle: quand les 403 montaient, les logs PHP montraient des erreurs sur des chemins internes.
Au lieu de conclure “c’est un bot, on ignore”, on a identifié un endpoint ciblé, lié à une exposition d’un fichier mal configuré. Après correction de la configuration et durcissement, le volume d’erreurs a chuté et la partie “autre” de scanning a continué plus tranquillement, comme d’habitude. Moralité: les logs servent à décider où concentrer l’effort. Une enquête courte peut éviter une “chasse au fantôme” longue.
Mettre des alertes sans noyer l’équipe
L’objectif n’est pas de créer une usine à alertes. L’objectif est de déclencher une analyse quand quelque chose dépasse vos seuils, ou quand un événement “rare” apparaît.
Dans une approche réaliste, vous pouvez vous appuyer sur :
- des règles de seuil sur les codes HTTP (par chemin ou par catégorie), des alertes sur des schémas d’URL, des alertes sur l’augmentation des erreurs PHP, des alertes sur les échecs d’authentification, des corrélations entre sources, quand votre outils le permet.
Voici une manière simple de structurer un premier niveau de triage, sans tomber dans la panique :
- si vous voyez des pics de 401 ou 403 sur les routes d’auth, priorisez l’analyse des tentatives de connexion et l’état du durcissement côté WordPress si 500 augmente et se corrèle à certaines URL, priorisez la piste d’erreur applicative ou d’exploitation PHP si vous identifiez des accès répétés à des fichiers sensibles ou des chemins non standards, vérifiez la configuration web et les permissions si le volume de requêtes devient très élevé sur une courte fenêtre, regardez l’impact CPU et la latence, car l’objectif peut être le déni de service si vous constatez que le trafic vient majoritairement d’un ou deux réseaux, évaluez la possibilité d’un blocage temporaire et d’un réglage de rate limiting
Ce triage vous donne une direction. Ensuite seulement, vous approfondissez.
Le risque des faux positifs, et comment le gérer sans perdre la détection
Les faux positifs sont inévitables. Le problème, c’est quand ils deviennent systématiques, vous finissez par ignorer les alertes.
Quelques situations classiques :
- Un plugin de monitoring ou un outil de cache rejoue des requêtes internes: cela peut ressembler à un bot. Un système de santé ou d’orchestration (Kubernetes, uptime checks) demande des endpoints “de test”: cela ressemble à une exploration. Des crawlers SEO mal configurés déclenchent beaucoup de 404: cela fait monter le bruit côté web.
La gestion passe par la connaissance de votre propre trafic et la mise en place de règles plus “intelligentes” que “trop de 404 = attaque”. Vous gagnez aussi à séparer les alertes “exploit possible” (corrélation HTTP et PHP, accès à des chemins sensibles) des alertes “scan probable” (balayage sans erreurs applicatives).
WordPress ajoute des patterns, surtout autour de l’auth
Dans WordPress, beaucoup d’attaques gravitent autour de l’authentification: brute force, credential stuffing, ou tests ciblés sur des noms d’utilisateurs.
Les logs utiles dans ce contexte ne sont pas seulement “les échecs”. Vous cherchez aussi :
- des répétitions à cadence régulière, des successions d’échecs suivies parfois de connexions, des tentatives sur des variantes de chemins d’auth, des user agents typiques de scripts.
Même si WordPress peut être durci avec des mécanismes internes, la surveillance des logs serveur reste un filet de sécurité. Elle vous permet de vérifier que les protections fonctionnent réellement. Par exemple, si vous mettez en place une politique de blocage au niveau serveur, les logs doivent montrer une diminution après déploiement.
Une alerte n’est qu’un début, la réponse doit être graduée
Quand un signal apparaît, votre réponse dépend de ce que vous observez. “Tout bloquer tout de suite” peut parfois casser votre site si vous ciblez une mauvaise origine. Inversement, “ne rien faire” laisse le temps à l’attaquant.
Le bon réflexe est d’adopter une réponse graduée:
- d’abord comprendre si c’est du scanning inoffensif, ensuite vérifier si un exploit ou une tentative d’exécution est en jeu, enfin décider du blocage, du durcissement, et de l’inspection des fichiers ou de la base.
Dans l’idéal, vous isolez l’origine suspecte. Si vous n’avez qu’un flux d’IP anonymes, vous utilisez alors le rate limiting, ou des règles qui ciblent les patterns d’URL plutôt qu’une IP unique.
Où conserver les logs et comment éviter la perte d’informations
Une surveillance sérieuse échoue souvent sur un détail banal : les logs disparaissent trop vite, ou sont incomplets.
Assurez-vous que :
- la rotation conserve au moins quelques jours, selon la taille de votre trafic, les logs sont centralisés si vous avez plusieurs serveurs, les horodatages sont cohérents (NTP), sinon la corrélation devient difficile, l’accès aux logs est sécurisé, car un attaquant qui lit vos logs peut mieux cibler vos défenses.
Si vous utilisez un outil de centralisation (ELK, Grafana Loki, cloud logs), gardez en tête que le coût et la rétention comptent. Vous n’avez pas besoin de tout archiver à l’infini, mais il faut garder assez pour enquêter sur des tendances.
Pièges fréquents: quand les logs vous donnent une impression fausse
Il y a des cas où les logs racontent une histoire trompeuse :
- Vous êtes derrière un reverse proxy ou un CDN, donc l’IP d’origine n’est pas celle que vous croyez si les en-têtes de proxy ne sont pas bien configurés. Une mauvaise configuration de WordPress masque des codes d’erreur, donc vous ne voyez pas l’échec réel. Un cache peut servir des réponses et réduire la visibilité, donc vous verrez moins d’erreurs mais pas forcément moins d’activité malveillante. L’augmentation de 404 peut venir d’un changement de routage ou d’un domaine expiré, pas d’un scanning.
D’où l’importance de corréler, et pas juste “compter”.
Durcir en parallèle, mais sans croire que la surveillance devient inutile
La surveillance des logs ne remplace pas le durcissement, elle le complète. Les deux se renforcent.
Si vous mettez en place des protections WordPress (limitation de tentatives, durcissement des permissions, mise à jour des composants, règles au niveau web), vous voulez ensuite vérifier que votre trafic “réagit” comme prévu dans les logs.
C’est un point que je trouve souvent oublié: la défense doit être validée. Un changement de configuration sans contrôle laisse un risque. À l’inverse, une surveillance bien faite vous permet de repérer quand une protection ne se déclenche pas.
Mettre en place un cycle d’amélioration continue
Une fois que la surveillance tourne, l’étape suivante est d’apprendre de chaque alerte. Les incidents récurrents vous donnent des modèles:
- tel chemin revient toujours, alors vous pouvez vérifier pourquoi, tel type d’erreur PHP revient après une mise à jour, alors vous corrigez ou ajustez, telle vague de tentatives ressemble à un pattern connu de bots, alors vous améliorez vos règles.
Au fil du temps, vos seuils deviennent plus pertinents, et votre temps d’investigation diminue. La surveillance devient un outil d’amélioration, pas un exercice de stress.
Quoi faire si vous trouvez des traces d’attaque
Si vos logs montrent un événement clairement malveillant, commencez par limiter le risque sans détruire votre capacité d’enquête.
Vous voudrez idéalement :
- conserver les extraits de logs pertinents, identifier la période exacte, déterminer les endpoints ciblés, vérifier l’état WordPress (comptes, plugins, modifications de fichiers si votre procédure le permet), et appliquer la correction associée (configuration, règles, mise à jour).
Même si je ne détaille pas ici une procédure “incident response” complète, l’idée est la même: isoler, vérifier, puis agir. Les logs servent de guide, mais votre réponse doit préserver les preuves et limiter l’impact.
Finalement, la meilleure protection WordPress, c’est la visibilité
Les attaques contre WordPress évoluent, les bots aussi. Ce qui reste solide, c’est votre capacité à voir ce qui se passe, tôt, et à comprendre rapidement la nature du problème. Surveiller les logs serveur, ce n’est pas seulement détecter, c’est aussi confirmer vos hypothèses, mesurer l’effet de vos changements, et réduire le temps entre un signal et une décision.
Si vous ne deviez retenir qu’une idée: ne cherchez pas “une alerte parfaite”. Cherchez un système où chaque signal est assez informatif pour vous permettre d’agir avec justesse, et où le bruit est assez contrôlé pour que vous gardiez votre attention quand quelque chose compte vraiment.