Analyser les journaux du serveur web après une attaque : bien lire le journal d'accès

En bref : qui veut analyser le journal d'accès après une attaque sauvegarde d'abord les journaux sans les modifier, puis ne travaille que sur des copies. On recherche des requêtes avec statut 200 vers des fichiers PHP inconnus, des requêtes POST suspectes, des accès aux répertoires d'upload et des schémas temporels. Pour PHP2Shell, il n'existe aucun indicateur de compromission confirmé publié ; c'est donc l'image d'ensemble issue de plusieurs sources de journaux qui compte.

D'abord sauvegarder, puis analyser

Sur la plupart des serveurs, les fichiers journaux subissent une rotation automatique et sont supprimés après une durée fixe. Après une attaque, la première étape consiste donc à sauvegarder les journaux existants avant qu'ils ne disparaissent. Cela vaut aussi lorsque vous n'êtes pas encore sûr qu'il se soit passé quelque chose. Pour PHP2Shell, la presse spécialisée conseille de conserver les journaux à partir du 20 octobre 2026.

# Copier les journaux avec leurs horodatages et consigner les sommes de contrôle
ZIEL=/root/sicherung-logs-$(date +%F)
mkdir -p "$ZIEL"
cp -a /var/log/nginx /var/log/apache2 /var/log/php* "$ZIEL"/ 2>/dev/null
cp -a /var/log/auth.log* /var/log/syslog* "$ZIEL"/ 2>/dev/null
find "$ZIEL" -type f -exec sha256sum {} + > "$ZIEL.sha256"

Placez en outre la sauvegarde sur un autre système. Un attaquant ayant accès au serveur pourrait sinon modifier les journaux après coup. Les sommes de contrôle montrent plus tard que la copie est inchangée. Si une sauvegarde recevable en justice est nécessaire, par exemple pour une plainte ou l'assurance, une analyse forensique informatique devrait s'en charger.

Où se trouvent les journaux et comment une ligne est construite

Les emplacements dépendent de la distribution et de l'interface d'administration. Chemins typiques :

Dans le format Combined répandu, chaque ligne contient l'adresse du client, la date et l'heure, la méthode et le chemin de la requête, le code de statut, la taille de la réponse en octets, le référent et l'agent utilisateur. Faites attention au fuseau horaire de l'horodatage, surtout si vous comparez les journaux avec des messages en UTC. Les correctifs PHP2Shell ont par exemple été publiés le 21 octobre 2026 à 14 h 00 UTC, soit 16 h, heure allemande.

Si votre site se trouve derrière un proxy, un CDN ou un répartiteur de charge, le journal ne contient peut-être que son adresse. La véritable adresse du visiteur se trouve alors dans un champ dédié ou dans les journaux du service placé en amont.

Sans ligne de commande : journaux dans le panneau ou chez l'hébergeur

Tous les exploitants n'ont pas d'accès shell. Sur un hébergement mutualisé ou des serveurs gérés, les interfaces d'administration proposent généralement une vue des journaux et un téléchargement des journaux d'accès et d'erreurs. Téléchargez les fichiers pour toute la période disponible et conservez-les en lieu sûr. Demandez par écrit à votre hébergeur combien de temps les journaux sont conservés et si d'anciens états peuvent être sauvegardés avant leur expiration.

Respectez ici la protection des données : les journaux contiennent des adresses IP et souvent d'autres données personnelles. Stockez les copies avec un accès protégé, ne les transmettez qu'aux personnes qui en ont besoin pour l'élucidation et fixez quand elles seront supprimées après la clôture de l'incident.

Analyser le journal d'accès : les requêtes les plus importantes

Les commandes suivantes ne font que lire et conviennent à Nginx et Apache au format Combined. Les fichiers ayant subi une rotation et compressés se parcourent avec zgrep ou zcat.

LOG=/root/sicherung-logs-2026-10-25/nginx/access.log

# Requêtes réussies vers des fichiers PHP, par fréquence
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Appels PHP dans les répertoires d'upload, de cache ou d'images
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"

# Requêtes POST par cible et adresse
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Erreurs 5xx par heure : des accumulations peuvent indiquer des processus PHP qui plantent
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c

# Inclure les journaux ayant subi une rotation
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'

Pour la première requête, les noms de fichiers que vous ne connaissez pas ou qui ne font pas partie de l'application sont particulièrement intéressants. Recoupez les fichiers suspects avec le système de fichiers : quand ont-ils été créés, à qui appartiennent-ils, que contiennent-ils ? Le guide Détecter et supprimer les webshells donne des indications à ce sujet.

Particularités de PHP2Shell

Avec PHP2Shell, les failles se trouvent dans le traitement des requêtes de PHP lui-même. Avec mod_php, un exploit a été démontré avant même l'exécution du code applicatif. Cela signifie qu'une requête vers une page tout à fait normale peut suffire. Dans le journal d'accès, une telle requête peut sembler discrète, car le contenu du corps de la requête n'y figure pas.

Il n'existe aucun indicateur de compromission confirmé publié. Soyez donc attentif au comportement et aux liens, par exemple à partir du 17 octobre 2026, la première tentative d'attaque observée selon des articles de presse :

• Accumulations d'erreurs 500 ou de réponses interrompues sur des pages ordinaires.
• Messages sur une mémoire épuisée ou des workers terminés dans le journal d'erreurs et le journal PHP-FPM.
• Fichiers PHP nouveaux ou modifiés peu après de telles accumulations.
• Nouvelles tâches cron, nouveaux processus ou connexions sortantes sous l'utilisateur du serveur web.

Aucun de ces signaux n'est à lui seul une preuve. Ensemble avec d'autres traces, ils forment toutefois une image qui répond à la question d'une compromission ou justifie une enquête plus approfondie. Vous trouverez un aperçu des signes sous Suis-je déjà compromis ?.

Autres sources : journal d'erreurs, PHP-FPM et journaux système

Le journal d'accès n'en montre qu'une partie. Pour une image complète, ajoutez d'autres sources :

# PHP-FPM et serveur web dans le journal systemd à partir d'une date
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200

# Connexions au serveur
last -Fa | head -40
grep -E 'Accepted|Failed' /var/log/auth.log | tail -100

# Vérifier les tâches planifiées de tous les utilisateurs
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

Les erreurs typiques d'analyse sont de ne parcourir que les journaux actuels au lieu de ceux ayant aussi subi une rotation, de négliger le fuseau horaire et de prendre des résultats isolés de scanners automatisés pour une attaque réussie. L'inverse est tout aussi risqué : considérer un journal d'accès sans particularité comme une levée d'alerte alors que le journal d'erreurs et le système de fichiers n'ont pas encore été vérifiés.

Consignez chaque constat avec l'heure, la source et l'observation dans une chronologie. Cette chronologie est ensuite la base des décisions, des notifications aux autorités ou aux assureurs et du rapport final.

Comment PHP SOS aide-t-il concrètement ?

• Nous sauvegardons les journaux et les fichiers pertinents de façon à ce qu'ils restent traçables pour des vérifications ultérieures.
• Nous analysons ensemble les journaux d'accès, d'erreurs, PHP et système et établissons une chronologie de l'incident.
• En cas d'indices de compromission, nous prenons en charge la réponse à incident avec confinement et nettoyage.
• Nous configurons la rotation et la conservation des journaux de sorte que, lors du prochain incident, les données nécessaires soient disponibles.

Questions fréquentes

Sources

• TechTarget : PHP2Shell, 22 millions de serveurs exposés
• php.net : avis de sécurité
• BSI IT-Grundschutz (socle de sécurité informatique du BSI)