Lire ses logs serveur pour repérer une attaque WordPress

Les logs de votre serveur racontent tout ce qui arrive à votre site, y compris ce que le pirate aimerait cacher. Chaque visite, chaque tentative de connexion, chaque appel à un fichier suspect y laisse une ligne horodatée. Ce guide vous montre où trouver ces journaux selon votre hébergement, comment lire une ligne, et quels motifs signalent une attaque en cours ou une intrusion déjà réussie sur un site WordPress.

Comprendre les logs serveur

Un log serveur est un simple fichier texte dans lequel le logiciel serveur web écrit une ligne à chaque requête. Sur la plupart des hébergements WordPress, ce logiciel est Apache, Nginx, LiteSpeed ou, sous Windows, IIS. Il existe deux journaux principaux : le log d'accès, qui liste les requêtes, et le log d'erreurs, qui liste les problèmes techniques.

Qui est concerné ? Tout propriétaire de site, mais surtout ceux qui doivent comprendre un incident : une alerte de l'hébergeur, un site lent, un compte administrateur apparu sans explication. Les logs permettent de répondre à trois questions essentielles : par où le pirate est-il entré, quand, et qu'a-t-il fait ensuite.

L'erreur fréquente est de les consulter trop tard. Les journaux tournent : ils sont compressés puis supprimés au bout d'une durée fixée par l'hébergeur. Quand on se décide à enquêter, la trace de l'entrée initiale a parfois déjà disparu.

Autre piège : le volume. Un site modeste reçoit chaque jour des milliers de requêtes, dont une bonne partie provient de robots d'indexation et de scanners automatiques qui testent tous les sites du web. Lire un log ligne par ligne n'a donc aucun sens. La bonne approche consiste à filtrer : partir d'un indice précis, comme une date, une page ou une adresse IP, puis remonter le fil. Quelques commandes simples suffisent à transformer un fichier illisible en une chronologie claire.

Où trouver les logs et comment les lire

L'emplacement dépend du serveur et de l'hébergeur. Les chemins ci-dessous sont les emplacements par défaut ; votre hébergeur peut les avoir changés.

Apache (Debian, Ubuntu)   /var/log/apache2/access.log   /var/log/apache2/error.log
Apache (RHEL, AlmaLinux)  /var/log/httpd/access_log     /var/log/httpd/error_log
Nginx                     /var/log/nginx/access.log     /var/log/nginx/error.log
IIS (Windows)             C:\inetpub\logs\LogFiles\W3SVC1\u_exAAMMJJ.log
cPanel                    ~/access-logs/ ou rubrique « Raw Access »
Plesk                     /var/www/vhosts/system/votredomaine.fr/logs/

Une ligne de log d'accès au format standard Apache ou Nginx ressemble à ceci. On y lit, dans l'ordre : l'adresse IP du visiteur, la date, la méthode et l'URL demandée, le code de réponse, la taille, la page d'origine et le navigateur déclaré.

203.0.113.45 - - [03/Nov/2026:04:12:09 +0100] "POST /wp-login.php HTTP/1.1" 200 4523 "-" "Mozilla/5.0"

Les signes à surveiller dans ces lignes sont les suivants :

• Rafales de POST vers wp-login.php ou xmlrpc.php : attaque par force brute sur les mots de passe.
• Un POST vers wp-login.php suivi d'un code 302 vers wp-admin : connexion réussie, à vérifier.
• Appels à des fichiers PHP inconnus, surtout dans wp-content/uploads : souvent une porte dérobée en service.
• Centaines de codes 404 sur des chemins de plugins : un robot qui teste des vulnérabilités connues.
• Paramètres étranges dans l'URL : apostrophes, mots comme UNION SELECT, balises script, séquences ../ qui remontent l'arborescence.
• Navigateurs déclarés vides ou outils automatiques comme python-requests, curl ou des scanners connus.

Cas concrets

Le restaurant et le compte administrateur fantôme

Un restaurateur découvre un administrateur nommé « wpsupport ». Dans le log d'accès, une seule adresse IP a enchaîné plusieurs milliers de POST sur wp-login.php pendant la nuit, puis obtenu un code 302. Le compte d'un ancien stagiaire, au mot de passe faible, avait cédé. L'heure exacte a permis de savoir quels fichiers vérifier en priorité.

La boutique WooCommerce et le fichier dans les médias

Une boutique de vêtements reçoit un avertissement de son hébergeur pour envoi de spam. Les logs montrent des requêtes POST répétées vers un fichier PHP situé dans un sous-dossier daté de wp-content/uploads. Ce fichier n'avait rien à faire là : c'était le script d'envoi des emails.

L'association et le robot de scan

Une association sportive constate un site très lent chaque soir. Le log d'accès révèle une même adresse IP qui teste des centaines de chemins de plugins en quelques minutes, avec des codes 404. Ce n'était pas une intrusion, mais un repérage automatisé. Un blocage par limitation des rafales a réglé la lenteur.

L'agence sous Windows Server

Une agence héberge ses sites sous IIS. Ses journaux, au format W3C, placent les champs dans un ordre décrit par la ligne d'en-tête qui commence par « #Fields ». En lisant cette ligne d'abord, l'équipe a pu filtrer les requêtes vers xmlrpc.php avec les mêmes réflexes que sous Linux.

Méthode pas à pas

Les commandes ci-dessous s'exécutent en SSH sur un serveur Linux. Sans accès SSH, téléchargez les logs depuis votre panneau d'hébergement et ouvrez-les dans un éditeur de texte. Si l'analyse devient longue, confiez-la à un professionnel : l'interprétation demande de l'habitude.

1. Copier les logs immédiatement : avant toute analyse, mettez une copie à l'abri pour qu'elle ne soit pas effacée par la rotation. Les fichiers anciens sont souvent compressés en .gz.

   mkdir -p ~/enquete && cp /var/log/apache2/access.log* ~/enquete/
   

2. Identifier les adresses les plus actives sur la page de connexion : cette commande compte les POST vers wp-login.php et xmlrpc.php par adresse IP, et affiche les dix premières.

   grep -E '"POST /(wp-login|xmlrpc)\.php' access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
   

3. Repérer les connexions réussies : un POST sur wp-login.php qui reçoit un code 302 correspond généralement à une connexion acceptée. Comparez les adresses obtenues avec celles de votre équipe.

   grep '"POST /wp-login.php' access.log | awk '$9 == 302'
   

4. Chercher les appels à du PHP dans les médias : toute requête vers un fichier PHP du dossier uploads est suspecte et mérite d'être examinée.

   grep -E '/wp-content/uploads/.*\.php' access.log
   

5. Détecter les tentatives d'injection : cette recherche, insensible à la casse, signale les URL contenant des motifs typiques d'injection SQL, de XSS ou de remontée de dossiers.

   grep -iE "union(\+|%20)select|%3Cscript|<script|\.\./|/etc/passwd" access.log
   

6. Établir une chronologie : une fois l'adresse ou le fichier suspect identifié, extrayez toutes ses lignes pour voir ce qui s'est passé avant et après. Sous Windows, la commande PowerShell équivalente lit les journaux IIS.

   grep "203.0.113.45" access.log* | sort -k4
   

   Select-String -Path "C:\inetpub\logs\LogFiles\W3SVC1\*.log" -Pattern "xmlrpc.php"
   

7. Croiser avec le log d'erreurs et les fichiers : une erreur PHP sur un fichier inconnu, ou un fichier modifié à la minute exacte d'une requête suspecte, confirme la piste. Notez les dates, elles orienteront le nettoyage.

Bonnes pratiques

• Activer et conserver les logs : vérifiez que votre hébergeur les active et demandez la durée de conservation.
• Synchroniser les horloges : notez le fuseau horaire des logs pour croiser les heures avec celles des fichiers modifiés.
• Garder une copie hors du serveur après tout incident : un pirate habile peut effacer ses traces.
• Lire les logs avec une hypothèse : partez d'un symptôme et d'une date, plutôt que de tout parcourir.
• Ne pas se fier à l'adresse IP seule : beaucoup d'attaques passent par des machines piratées ou des proxys.

Erreurs fréquentes à éviter

• Attendre plusieurs jours avant de récupérer les logs, alors que la rotation les efface.
• Bloquer une adresse IP et considérer l'affaire close, sans vérifier si une connexion a réussi.
• Oublier xmlrpc.php, qui permet de tester de nombreux mots de passe en une seule requête.
• Analyser les logs sans scanner les fichiers : une porte dérobée peut rester active même si l'attaquant change d'adresse.

Comment V-Shield vous aide

V-Shield ne remplace pas la lecture des logs dans une enquête, mais il réduit le nombre de situations où vous en avez besoin. Son firewall applicatif bloque les injections SQL et XSS, limite les rafales de requêtes sur la page de connexion et peut géo-bloquer l'accès à wp-admin. Le scan automatique repère les portes dérobées et les comptes administrateurs frauduleux, et une alerte email vous prévient en cas de dérive, comme un nouvel administrateur. Découvrez le firewall et la détection ou comparez les formules. Pour compléter, lisez notre article sur le pare-feu WAF pour WordPress et notre méthode pour scanner un site WordPress contre les malwares.

Vos logs montrent une connexion que personne n'a faite ? Consultez notre page urgence site piraté pour agir dans le bon ordre.