Lire les journaux d'accès fournis par l'hébergeur
Dans un access.log, cherchez les POST vers des PHP que vous ne connaissez pas, les 200 sur des scripts isolés, les user-agents de bots d'exploit. Une heure d'entrée se lit souvent mieux ici que dans l'admin WordPress. Demandez ces journaux avant qu'une réinstall ne les efface. Joignez au constat dix lignes anonymisées, pas 800 Mo : heure, méthode, chemin, code suffisent à l'hébergeur.
Cherchez les POST vers des PHP inconnus, les 200 sur des shells, les user-agents de bots d'exploit. Une heure d'entrée se lit souvent mieux ici que dans l'admin WordPress.
Ce que les journaux sont — et ne sont pas
Un access.log raconte qui a demandé quelle URL, avec quel résultat (200, 404, 500). Il ne dit pas « voici la faille » tout seul. Il date. Il oriente. Un admin fantôme sans trace HTTP peut venir d'un FTP. Un PHP jamais demandé en HTTP peut être un cron. Croisez.
Ce n'est pas un cours de forensics. C'est ce qu'un gérant de site peut faire en une heure pour ne plus nettoyer à l'aveugle. Premiers gestes.
On ne publie pas de payloads ni de listes d'exploits. On dit quels types de lignes méritent un coup d'œil. Les 404 wp-login, ignorez-les : du bruit. Un POST 200 vers un PHP isolé, non.
Les demander (et les sauver hors compte)
Ticket : access, error, FTP, mail, cron, référence d'abus, adresse perso. Mail coupé. Certains panels les téléchargent (cPanel, N0C, alwaysdata). alwaysdata. cPanel.
Réinstaller « pour se rassurer » les détruit. Copiez-les avec l'archive.
Rétention courte (7–14 jours souvent). Demandez tôt. Compte suspendu.
HTTP : POST, 200 suspects, 404 utiles
POST vers un `*.php` que vous ne reconnaissez pas (racine, uploads, nom aléatoire) : prioritaire. GET 200 sur le même fichier : il a servi. 404 en masse sur des chemins d'extensions connues : du bruit de bots, pas forcément l'entrée — sauf un 200 au milieu.
User-agents clairement automatisés : contexte. Un user-agent « Mozilla » n'est pas innocent pour autant. L'heure + le chemin comptent plus que le théâtre du UA.
Codes 500 au moment d'une défiguration : fichier cassé, parfois juste après une écriture. Error.log PHP complète.
- POST + PHP inconnu.
- 200 sur un fichier isolé.
- Pic d'heures vs vos horaires métier.
FTP, mail, erreur PHP : trois autres fichiers
FTP : uploads, heures, comptes. Si le panel a été forcé, ces lignes datent mieux que wp-admin. Mail : qui a envoyé, quel script (chemin dans le header parfois). Distingue formulaire et PHP racine.
Error PHP : `include` vers un fichier manquant, timeouts d'un mineur, .htaccess. Erreur 500.
Sans ces fichiers, l'HTTP seul suffit souvent à trouver UN shell. Rarement la porte panel.
Cloudflare, IPv6, www : ce qui brouille
IP Cloudflare partout : headers ou logs CF. Cloudflare proxy. IPv6 / www non nettoyés : autre vhost, autre log. IPv6 www.
Load balancer, HTTP resté ouvert. HTTP ouvert.
Ne concluez pas « pas de trace » si vous n'avez lu que le vhost `www` alors que l'attaque tapait le nu.
Ce qu'on ne fait pas avec un log
On ne « contre-attaque » pas une IP. On ne publie pas les lignes complètes (données clients, tokens). On ne colle pas 800 Mo dans le ticket.
On n'utilise pas le log pour reconstruire un exploit. On l'utilise pour dater et prioriser des fichiers à comparer.
Un prestataire qui vous demande seulement « le log pour s'amuser » sans copie du site n'a pas le bon ordre.
Lier une heure à un fichier et à un compte
Heure du premier POST réussi → date de fichier proche → extension / FTP / admin créé. C'est le fil. Joomla `/images`, Drupal `files`, WP uploads. Joomla, Drupal.
Minage : process + cron, pas seulement HTTP. Cryptominage.
Plusieurs sites : logs de chaque root. Isolation.
Joindre un extrait au constat, pas 800 Mo
10 à 30 lignes anonymisées (heure, méthode, chemin, code) + « fichier retiré, entrée X fermée ». Référence d'abus. Répondre à un abus. OVH.
Tests visiteurs ensuite. Un log propre n'est pas un site propre. Tests.
Créer un compte si le volume ou le format (binaire, rotaté) dépasse. Mieux vaut trente lignes justes que le silence « on n'a pas les logs » alors qu'ils étaient dans le panel.
Anonymisez (IP tronquées, pas de query string avec e-mail). Le ticket d'abus n'a pas besoin du portrait de vos clients. L'heure, la méthode, le chemin, le code suffisent.
Quand le fichier est énorme, rotaté, ou binaire
Access.log de 2 Go : ne l'ouvrez pas dans le Bloc-notes. Cherchez les POST et les `.php` hors CMS (outil, prestataire, ou nous). Les 404 wp-login, ignorez-les. Les rotations (`.1`, `.gz`) partent souvent en premier : demandez-les tôt, rétention courte. Compte suspendu.
Cloudflare : logs origine pauvres. Combinez FTP logs + events CF + une heure de mode développement. Cloudflare. IPv6 / hôte nu : autre fichier parfois. Ne concluez pas « pas de trace » sur un seul vhost.
Pas de logs du tout : dates de fichiers, zips officiels, comptes. Plus long, possible. Notez l'absence. Un hébergeur qui refuse tout extrait « RGPD » alors que vous êtes titulaire : écrivez-le, c'est un levier, parfois un motif de départ après propreté. Changer d'hébergement.