Audit WordPress : comprendre les logs et les tentatives de connexion

Quand on parle d’attaque sur WordPress, on imagine souvent un “piratage” spectaculaire. Dans la pratique, la plupart des incidents ressemblent davantage à une série de tentatives de connexion, parfois très régulières, parfois opportunistes. L’intérêt de faire un audit propre, c’est de passer du ressenti à des éléments concrets: qui a tenté quoi, quand, depuis où, et surtout, quel comportement était “normal” pour votre site et lequel ne l’était pas.

Les logs sont le point de passage obligé. Mais il ne suffit pas de les lire, il faut savoir les interpréter, éviter les pièges (faux positifs, bruit applicatif, configuration serveur trompeuse) et relier ces traces à une décision de sécurisation. Cet article détaille une méthode réaliste pour comprendre les logs liés aux connexions et aux requêtes suspectes autour de WordPress, avec des exemples issus de situations fréquentes en exploitation.

Pourquoi les tentatives de connexion laissent des traces utiles

Une attaque de type brute force, énumération d’utilisateurs ou tentative d’exploitation d’anciennes surfaces d’entrée laisse rarement une seule trace isolée. Vous verrez plutôt un motif: un même client (ou une plage d’IP), des requêtes répétées vers des URLs connues, des statuts HTTP cohérents, parfois des variations d’agents utilisateurs, puis un silence (attaque stoppée) ou une reprise (attaque relancée).

Même quand l’attaquant ne parvient pas à entrer, les logs décrivent le chemin qu’il a tenté de suivre. Et ce chemin sert à choisir les bons contrôles: limitation de débit, durcissement de l’authentification, filtrage d’accès, correction de configuration, et contrôle de sécurité applicative.

À l’inverse, si vous faites l’audit en regardant seulement “y a-t-il eu des connexions acceptées”, vous risquez de rater des signaux précoces. Un site peut subir beaucoup de tentatives sans qu’un compte soit compromis, et pourtant ces tentatives peuvent révéler une faiblesse de configuration (par exemple, une surface exposée ou un comportement anormal côté serveur).

Identifier les bonnes sources de logs (et celles qui noient le poisson)

Dans un audit WordPress, vous pouvez croiser plusieurs journaux, avec des niveaux d’utilité très différents. L’objectif n’est pas de tout collecter, mais de collecter ce qui répond à vos questions.

En général, on retrouve:

• Les logs d’accès du serveur web (Nginx ou Apache), qui enregistrent les URLs demandées, les statuts HTTP, les adresses IP (quand elles sont disponibles), les durées, et parfois des informations liées au proxy.
• Les logs d’erreurs du serveur, qui racontent les erreurs applicatives et certaines erreurs de configuration, mais pas toujours les tentatives de connexion elles-mêmes.
• Les logs WordPress (selon la configuration), qui peuvent inclure des détails sur des actions PHP, des erreurs, et parfois des événements d’authentification si vous avez configuré correctement la journalisation.
• Les logs d’un pare-feu ou d’un WAF (si vous en utilisez un), qui enrichissent souvent les événements côté réseau avec des scores et des règles.

Un piège fréquent: derrière un CDN ou un reverse proxy, l’IP “visible” dans vos logs peut être l’adresse du proxy, pas celle de l’attaquant. Dans ce cas, les règles de blocage et les analyses géographiques perdent de leur valeur. L’audit doit donc commencer par vérifier si l’IP cliente réelle est correctement transmise, par exemple via des en-têtes standard (les détails dépendent de votre stack).

Lecture des logs d’accès: ce que vous cherchez vraiment

Pour comprendre les tentatives de connexion, vous allez surtout regarder les requêtes vers:

• la page de connexion WordPress (souvent /wp-login.php)
• des endpoints liés à l’authentification et à la communication (par exemple xmlrpc.php, selon l’installation)
• des URLs “ciblées” par des scanners, qui testent des chemins connus

Une lecture efficace consiste à relier quatre éléments: l’URL, le statut HTTP, le rythme, et le contexte (UA, méthode, taille de réponse si disponible).

Statuts HTTP et leur sens pratique

Sur un site WordPress, les statuts HTTP ne prouvent pas à eux seuls qu’il y a eu une attaque, mais ils donnent un indice. Par exemple, des requêtes répétées vers /wp-login.php avec un statut qui correspond à un échec de traitement peuvent indiquer un brute force. Des requêtes vers xmlrpc.php avec des échecs et des redirections peuvent indiquer des tentatives d’abus de l’endpoint.

Le point important en audit: vous devez interpréter les statuts dans la logique de votre serveur. Une configuration de sécurité peut changer le comportement attendu. Par exemple, un reverse proxy ou un WAF peut répondre différemment et masquer les statuts “traditionnels” de WordPress. D’où l’intérêt de corréler avec les logs applicatifs ou avec les événements du WAF.

Rythme et répétition

Un signal assez fiable, c’est la répétition sur une courte fenêtre. Un humain qui se trompe de mot de passe une fois ou deux est plausible. En revanche, voir des dizaines de tentatives par minute depuis une même source, sur plusieurs noms d’utilisateur ou plusieurs formats de payload, ressemble fortement à de l’automatisation.

Il y a toutefois un edge case courant: des systèmes de monitoring ou de services tiers peuvent déclencher des appels de type authentification, surtout si un plugin ou un cron tente de se connecter pour des synchronisations. La méthode d’audit consiste donc à comparer vos volumes “normaux” sur une période sans incident et sur une période suspecte.

Comprendre l’authentification WordPress à travers ses traces

Côté WordPress, les tentatives de connexion sont généralement liées à des requêtes POST vers l’endpoint de login, mais aussi à des variantes selon les modules et plugins.

Ce qui aide, ce sont les variables visibles ou déductibles:

• La méthode HTTP (POST est généralement plus proche de l’authentification que GET)
• La présence d’un référent (souvent vide dans un brute force)
• Le comportement du temps de réponse (des réponses très rapides et répétées peuvent indiquer un automatisme)
• La variation du contenu de requête (difficile à voir sans inspecter plus en profondeur, mais certains journaux incluent des tailles)

Si vous avez accès aux logs applicatifs avec un niveau de détail suffisant, vous pouvez aller plus loin. Mais attention, pousser trop de logs applicatifs peut devenir contre-productif: charge serveur, saturation disque, et exposition de données sensibles dans certains environnements mal configurés.

Une règle pratique: journaliser “assez” pour investiguer, pas “tout” par défaut. Un audit doit aussi définir une politique de conservation et de masquage, surtout pour éviter de stocker des paramètres sensibles en clair.

Une lecture “par cas”: ce que vous pouvez rencontrer

Dans les audits réels, on tombe souvent sur des scénarios récurrents. Je les formule ici en termes de comportements observables, sans supposer la cause unique.

1) Beaucoup de tentatives sur /wp-login.php, échecs fréquents

C’est le pattern typique du brute force. La plupart du temps, l’attaquant teste des couples identifiants/mots de passe ou tente une liste d’utilisateurs courants. Le volume et le rythme sont les plus parlants.

Action d’audit: vérifiez si vos mesures de limitation sont en place. Certains environnements s’appuient sur une règle serveur, d’autres sur un plugin. Si vous avez seulement un plugin sans blocage réseau, vous pouvez vous retrouver avec du trafic qui consomme vos ressources applicatives inutilement.

2) Tentatives très agressives sur xmlrpc.php

xmlrpc.php est connu pour être une cible dans certains scénarios. Selon votre configuration et vos besoins (presse à distance, mobile apps, compatibilité historique), vous n’en avez pas forcément l’usage.

Action d’audit: identifiez si l’endpoint est réellement nécessaire. S’il n’est pas utilisé, le réduire ou le désactiver peut être un levier. S’il est utilisé, vous chercherez plutôt à contrôler l’accès et à renforcer l’authentification, en gardant en tête l’impact possible sur des fonctions légitimes.

3) Trafic “massif” mais sur des pages qui ne sont pas le login

Parfois, vous verrez beaucoup de scans mais peu d’essais de login. Cela peut être du probing de surface plutôt qu’une tentative immédiate de compromission. Même là, les logs d’accès restent utiles, car ils décrivent des chemins et des comportements.

Action d’audit: dans ce cas, la sécurisation doit viser la réduction de surface, la correction des erreurs et la mise en place d’un filtrage réseau. Ce n’est pas la même priorité qu’un brute force pur, et vous n’obtiendrez pas les mêmes résultats avec un simple durcissement du login.

4) Pics corrélés à un changement récent

Une découverte fréquente: des tentatives augmentent après une modification (mise à jour de plugin, changement de CDN, redéploiement, modification DNS). L’audit doit donc inclure une frise de changements. Souvent, un changement de configuration expose un endpoint, modifie des règles de cache, ou modifie la manière dont le WAF applique ses protections.

Sans cette contextualisation, on attribue à l’attaque ce qui relève d’un effet de configuration, ou inversement.

Construire une chronologie: le cœur d’un bon audit

La clé, c’est d’éviter de regarder “au hasard” dans les logs. Une chronologie simple, même basée GardeWP durcissement WordPress sur des plages horaires, vous donne un avantage énorme. Vous cherchez des réponses comme:

• Quand l’activité a-t-elle commencé?
• Est-ce que c’est continu ou par vagues?
• Est-ce que ça correspond à des actions du site (publication, sauvegarde, mise à jour)?
• Quelle proportion d’IP a une signature identique (même UA, même source, même pattern d’URLs)?

En audit, j’ai vu des situations où un pic de tentatives était déclenché par un outil interne mal configuré, mais qui apparaissait comme “attaque” dans un dashboard. La seule chose qui a permis de trancher, c’est la corrélation avec une tâche planifiée qui tournait au même intervalle.

Exemple de démarche de triage (sans s’affoler)

Voici une façon concrète de procéder quand vous ouvrez vos logs pour la première fois. L’idée est de faire un tri rapide, puis une investigation ciblée.

Petit tri initial (check rapide)

• Repérez les URL les plus touchées sur la période récente (souvent /wp-login.php, xmlrpc.php, et quelques variantes).
• Filtrez par IP et observez si le même client répète des tentatives, ou si le trafic est distribué.
• Observez la proportion des statuts HTTP, surtout les réponses qui indiquent un échec ou un blocage côté sécurité.
• Vérifiez l’heure et comparez avec les changements récents (déploiement, modification WAF, nouvelle mise en cache, changement de reverse proxy).
• Contrôlez si vous pouvez retrouver l’IP réelle, ou si vous l’avez remplacée par celle du proxy/CDN.

Cette étape ne “résout” pas tout, elle vous donne seulement une direction. Ensuite, vous passez à l’investigation plus précise.

Ce que les plugins de sécurité affichent, et ce qu’ils peuvent masquer

Les plugins de sécurité peuvent être utiles, mais ils ajoutent parfois un niveau d’abstraction. Certains agrègent des tentatives, d’autres classent des comportements selon des règles internes. Le risque en audit, c’est de vous reposer sur l’interprétation du plugin sans aller voir la source.

Je recommande d’utiliser le plugin comme un guide, pas comme une preuve unique. Si le plugin dit “blocage”, vérifiez au moins côté logs serveur ou WAF que le blocage a bien eu lieu au bon niveau. Sinon, vous pouvez croire être protégé, alors que WordPress reçoit encore une partie du trafic avant blocage.

Autre point de vigilance: la présence de faux positifs. Certains outils considèrent comme suspect des robots de monitoring, des clients API légitimes, ou des outils de gestion de site. D’où l’intérêt d’avoir une cartographie simple de vos intégrations: que fait votre site, et depuis où.

Comment passer des logs à des décisions de sécurisation

Une fois que vous comprenez le pattern, la sécurisation doit être proportionnée au risque et au coût d’exploitation.

Si vous voyez un brute force massif, la priorité n’est pas de “changer tous les mots de passe”. La priorité est de réduire la charge inutile et d’empêcher l’attaque de progresser. Si vous voyez des tentatives ciblant un endpoint non utilisé, la meilleure décision peut être de réduire la surface plutôt que d’ajouter des couches.

Si vous suspectez une fuite de compte ou un usage compromis, vous vous tournez vers la rotation des identifiants, la vérification des utilisateurs, et la revue des sessions. Mais même là, les logs d’accès et d’authentification servent de déclencheur, pas de preuve isolée.

Actions typiques après analyse (séquence courte)

• Mettre en place ou vérifier une limitation du débit sur les tentatives de login, côté serveur ou via WAF, en évitant de casser les accès légitimes.
• Durcir la configuration d’authentification WordPress et confirmer que les réglages de base sont cohérents avec votre modèle d’usage.
• Réduire la surface des endpoints inutiles (par exemple limiter l’accès à des endpoints que votre site n’utilise pas).
• Revoir les plugins exposés et leurs réglages, car certaines extensions contribuent au bruit ou ouvrent des chemins non désirés.
• Vérifier l’intégrité du site et la sécurité des comptes administrateurs si des connexions réussies ou des événements anormaux sont apparus.

Cette séquence n’est pas une recette universelle, elle correspond à une logique d’audit: d’abord stopper le bruit utile, puis corriger ce qui est exposé, et enfin confirmer que l’application n’a pas changé.

La partie la plus difficile: distinguer attaque et activité légitime

Les logs racontent rarement toute l’histoire. Ils montrent des requêtes, des statuts et des identifiants techniques. Mais ils ne disent pas “intention”. En audit, vous devez donc interpréter.

Un exemple concret: un outil d’automatisation peut effectuer des appels vers le login si des identifiants sont stockés dans une variable d’environnement et que cette variable a expiré ou a été remplacée par une valeur incorrecte. Vous verrez alors des tentatives répétées, avec une origine IP qui ressemble à une attaque, mais qui vient en réalité de votre propre infrastructure.

Autre exemple: un système de sauvegarde ou de déploiement peut tester la connexion à distance en utilisant des méthodes différentes. Si votre journalisation serveur ne vous donne pas les bons référents ou la bonne IP, vous pouvez mal classifier les événements.

La bonne approche, c’est de recouper: IP connue de votre fournisseur, plage horaire cohérente avec un job interne, signature d’agent utilisateur associée à vos outils, et volume attendu.

Paramétrage et conservation: ne pas saboter l’audit en stockant trop

Une journalisation trop généreuse peut vous faire perdre le contrôle: disque saturé, perte de logs, surcharge CPU, ou exposition de paramètres sensibles. Un audit sérieux tient aussi compte de la gouvernance.

Sans entrer dans un modèle précis, retenez ces principes de bon sens:

• conserver moins longtemps ce qui est “bruit” et garder plus longtemps ce qui est “preuve” (par exemple les événements autour de l’authentification)
• masquer les données sensibles si vos logs les contiennent (selon votre stack, cela peut être partiellement possible)
• définir des alertes qui signalent l’anormal sans déclencher toutes les heures

Le but n’est pas d’obtenir un journal parfait, c’est d’avoir un journal exploitable quand un incident arrive.

Vérifier la sécurité sans faire d’autopsie permanente

Après l’audit, l’objectif est que votre site reste stable, pas que vous passiez votre temps à scruter des lignes.

En pratique, vous cherchez un équilibre:

• assez de protection pour réduire les tentatives sans bloquer des usages légitimes
• assez de visibilité pour investiguer quand un événement dépasse votre base
• assez d’hygiène pour que WordPress ne soit pas une cible facile (mises à jour, thèmes/plugins à jour, politique de mots de passe)

Les logs servent de thermomètre. La sécurisation est la médecine. Les deux doivent être coordonnés.

Cas d’école utile: quand les tentatives ne mènent à rien, mais révèlent un défaut

Je garde un souvenir d’un audit où le site semblait “indemne” sur la base des connexions réussies. Pourtant, les logs montraient une activité très élevée vers le login, surtout depuis des sources distribuées. Après corrélation avec la configuration, on a identifié l’absence de limitation efficace côté périmètre. Résultat: l’attaque ne passait pas, mais elle consommait des ressources et augmentait le risque, notamment sur des pics ou en période de trafic normal.

C’est typiquement le genre de situation où un audit vaut le coup même si vous n’avez pas de preuve de compromission. La sécurisation “préventive” devient rationnelle, car les logs montrent un risque opérationnel, pas seulement un risque théorique.

Conclusion implicite pour l’audit: apprenez le langage des logs

Comprendre les logs d’un site WordPress, ce n’est pas seulement apprendre à lire “wp-login.php” ou “401”. C’est apprendre à relier des traces à une réalité de service: configuration réseau, comportements d’automatisation, cohérence des statuts, rythmes d’attaque, et corrélation avec vos changements.

Si vous prenez une seule chose de cette lecture, ce serait celle-ci: l’audit n’est pas une chasse au mot “attaque” dans un dashboard. C’est une démarche où chaque ligne doit finir par servir une décision. Quand les tentatives de connexion sont comprises, la sécurisation devient plus précise, plus rentable, et moins anxiogène pour l’équipe qui gère le site.

Si vous le souhaitez, je peux aussi vous proposer une grille de questions à remplir pendant l’analyse (sans entrer dans des étapes techniques trop spécifiques) pour guider votre lecture de logs et décider des priorités d’audit et de sécurisation WordPress.