Centraliser les logs : syslog, SIEM et SOC

Centraliser les logs, c'est envoyer en continu les journaux de toutes les machines vers un serveur de collecte unique, où ils sont conservés à l'abri, rapprochés et analysés. Un SIEM (Security Information and Event Management) est l'outil qui exploite ces journaux centralisés : il les normalise, les corrèle et lève des alertes, que surveille un SOC, un centre des opérations de sécurité. Ce chapitre explique pourquoi et comment centraliser, détaille le protocole syslog et la configuration de rsyslog, puis le fonctionnement d'un SIEM et d'un SOC.

Pourquoi centraliser

Aux Ateliers Morvan, chaque serveur garde ses journaux pour lui. Le jour de l'intrusion sur srv-web, quatre problèmes apparaissent.

• L'attaquant contrôle la machine qui contient les preuves. Avec les droits root, il peut effacer ou modifier les journaux locaux. Des journaux copiés en temps réel ailleurs restent intacts.
• Les indices sont dispersés. L'échec de connexion est sur srv-web, le flux sortant sur le pare-feu, la connexion VPN sur une autre machine. Les rapprocher à la main prend des heures.
• Personne ne regarde. Vingt serveurs, c'est vingt endroits à consulter chaque jour : en pratique, personne ne le fait.
• La conservation est hétérogène. Un serveur garde quatre semaines, un autre trois jours, le pare-feu écrase ses journaux quand sa mémoire est pleine.

Centraliser répond aux quatre : une copie hors d'atteinte, un seul endroit pour chercher et corréler, des alertes automatiques, une durée de conservation unique et maîtrisée. La supervision, qui surveille l'état et la disponibilité des équipements, complète ce dispositif (supervision).

L'architecture d'une journalisation centralisée

Le guide de l'ANSSI sur l'architecture d'un système de journalisation (2022) et les sujets d'examen décrivent la même chaîne.

Les recommandations clés de ce type d'architecture :

• le collecteur est isolé dans une zone d'administration, n'accepte que les flux de journalisation et n'est administré que depuis des postes dédiés ;
• les flux sont chiffrés et authentifiés (syslog sur TLS) dès qu'ils traversent un réseau non maîtrisé ;
• les relais et les sources gardent une file d'attente sur disque pour ne rien perdre pendant une coupure ;
• toutes les machines sont synchronisées sur la même source de temps ;
• le collecteur est supervisé : une source qui cesse d'émettre doit déclencher une alerte.

Le protocole syslog

Syslog est le protocole standard d'envoi de journaux sous Linux et sur les équipements réseau. Sa version actuelle est décrite par la RFC 5424 (2009). Un message ressemble à ceci :

<38>1 2026-10-13T03:00:50+02:00 srv-web sshd-session 3139 - - Accepted password for deploy from 203.0.113.45 port 40256 ssh2

Il commence par la priorité entre chevrons, suivie de la version du format (1), de l'horodatage, du nom de la machine, de l'application, du numéro de processus, d'un identifiant de message et de données structurées (ici absents, -), puis du message lui-même.

La priorité combine deux informations : la catégorie (facility), qui dit quelle partie du système parle, et la gravité (severity), de 0 à 7 (les niveaux de gravité).

Quelques calculs pour s'entraîner :

Dans la configuration de rsyslog, un sélecteur désigne les messages à traiter sous la forme catégorie.gravité. kern.err signifie « les messages du noyau de gravité err ou plus grave » ; kern.=err signifie « exactement err » ; auth,authpriv.* signifie « toutes les gravités des catégories auth et authpriv ».

Le transport. Syslog circule historiquement en UDP sur le port 514 : sans accusé de réception, sans chiffrement, sans authentification. Les messages perdus le sont définitivement, n'importe qui peut en lire le contenu sur le réseau, et n'importe qui peut envoyer de faux messages au collecteur. Le TCP (souvent aussi sur le port 514) garantit la livraison. Syslog sur TLS (RFC 5425, port 6514) ajoute le chiffrement et l'authentification par certificats.

Configurer rsyslog

Sur chaque serveur Debian, Léa installe rsyslog (apt install rsyslog), qui reçoit alors les événements du journal de systemd. Elle ajoute un fichier /etc/rsyslog.d/90-central.conf :

# Envoyer l'authentification et toutes les erreurs au collecteur, en TCP,
# avec une file d'attente sur disque si le collecteur ne répond plus
auth,authpriv.*;*.err action(type="omfwd" target="192.168.50.10" port="514" protocol="tcp"
                             queue.type="LinkedList" queue.filename="central"
                             queue.saveOnShutdown="on" action.resumeRetryCount="-1")

omfwd est le module d'envoi ; la file LinkedList avec un nom de fichier passe sur disque quand la mémoire ne suffit plus ; action.resumeRetryCount="-1" fait réessayer sans fin. Tu croiseras aussi l'ancienne syntaxe, plus courte : *.* @@192.168.50.10:514 (deux @ pour TCP, un seul pour UDP).

Sur le collecteur srv-logs, elle active la réception et range les journaux par machine et par programme :

module(load="imtcp")
input(type="imtcp" port="514")

template(name="parHote" type="string" string="/var/log/central/%HOSTNAME%/%PROGRAMNAME%.log")

if $fromhost-ip != "127.0.0.1" then {
    action(type="omfile" dynaFile="parHote")
    stop
}

Elle vérifie la syntaxe avec rsyslogd -N1, redémarre le service (systemctl restart rsyslog), ouvre le port 514 en TCP sur le pare-feu du collecteur uniquement depuis les réseaux internes, puis teste depuis une source avec logger -p auth.warning "test centralisation". En production, elle passera au chiffrement : module gtls, certificats émis par l'autorité interne, port 6514.

Pour les serveurs Windows, le transfert d'événements natif (Windows Event Forwarding) envoie les événements choisis vers un serveur Windows collecteur ; sinon, un agent installé sur chaque machine (celui du SIEM, ou un agent comme NXLog ou Winlogbeat) lit les journaux et les transmet.

Ce que fait un SIEM

Un serveur rsyslog stocke des fichiers. Un SIEM les exploite.

Les solutions que tu croiseras en 2026 :

La corrélation : des événements à l'alerte

Une règle de corrélation décrit une suite d'événements suspecte (le cours Wazuh montre comment écrire des règles et des décodeurs et détecter les incidents courants). Celle que le prestataire a posée pour les Ateliers Morvan :

Force brute réussie : au moins 10 échecs d'authentification depuis une même adresse en moins de 5 minutes, suivis d'une authentification réussie depuis la même adresse dans les 10 minutes. Gravité : critique.

Pris un par un, aucun de ces événements n'est alarmant : des échecs de connexion, il y en a tous les jours ; une connexion réussie aussi. C'est l'enchaînement qui compte. D'autres règles classiques :

• un compte qui se connecte depuis deux pays éloignés à quelques minutes d'intervalle (déplacement impossible) ;
• un compte créé puis ajouté à un groupe d'administration dans l'heure (4720 puis 4728 ou 4732) ;
• l'effacement d'un journal (1102), quel que soit le contexte ;
• un poste qui contacte un domaine figurant dans une liste d'indicateurs de compromission ;
• un volume sortant anormal vers une destination jamais vue.

Faux positifs et faux négatifs. Une règle trop large déclenche à tort : c'est un faux positif. Trop de faux positifs fatiguent l'équipe, qui finit par ignorer les alertes, y compris la vraie. Une règle trop étroite rate des attaques : c'est un faux négatif. Régler un SIEM, c'est ajuster en continu : exceptions documentées (le scanner de vulnérabilités de Mehdi, tous les lundis à 6 h), seuils adaptés, gravités hiérarchisées. On n'efface jamais une règle parce qu'elle « sonne trop » : on la précise.

Le SOC et les outils qui l'entourent

Un SOC (Security Operations Center) est l'équipe, interne ou externalisée, qui surveille les alertes et y répond. On y retrouve des niveaux, comme au support : le niveau 1 trie et qualifie les alertes, le niveau 2 analyse les incidents confirmés, le niveau 3 mène les investigations poussées et la recherche proactive de menaces. Une PME comme les Ateliers Morvan n'a pas de SOC : elle confie la surveillance à un prestataire, qui fournit un SOC mutualisé.

Autour du SIEM gravitent d'autres outils :

• l'EDR (Endpoint Detection and Response), installé sur les postes et les serveurs, détecte les comportements malveillants (un traitement de texte qui lance PowerShell, un programme qui chiffre des centaines de fichiers) et peut isoler une machine du réseau à distance ; il transmet ses détections au SIEM ;
• l'IDS et l'IPS (systèmes de détection et de prévention d'intrusion, comme Suricata) analysent le trafic réseau et signalent ou bloquent les attaques connues (cybersécurité de l'infrastructure) ;
• la matrice MITRE ATT&CK, une base publique qui classe les techniques des attaquants par tactique (accès initial, exécution, persistance, élévation de privilèges, mouvement latéral, exfiltration, impact…), chacune avec un identifiant : T1110 pour la force brute, T1105 pour le transfert d'outils vers la victime, T1486 pour le chiffrement de données à des fins d'impact. Les alertes des SIEM et des EDR citent souvent ces identifiants.

Côté SLAM : rendre son application observable

Une application bien conçue facilite le travail du SOC :

• elle écrit des journaux structurés (JSON), avec des noms d'événements stables ;
• elle attribue un identifiant à chaque requête et le reporte dans toutes les lignes qui la concernent, ce qui permet de suivre une action à travers plusieurs services ;
• en conteneur, elle écrit sur la sortie standard, que la plateforme collecte et transmet (le cours Docker) ;
• elle journalise ses propres mécanismes de défense (limitation du nombre de tentatives de connexion, blocage d'un compte, requête rejetée par la validation) : ce sont d'excellents signaux pour le SIEM.

À l'E7

• SISR, Nouvelle-Calédonie 2025 (U7), cas Everest : tout le dossier B, « Gestion des journaux », le plus long du sujet, porte sur ce chapitre. On y évalue le risque d'une attaque par rejeu sur le serveur syslog, on liste les conséquences de deux attaques sur syslog en clair pour l'intégrité et la disponibilité, on explique l'apport des certificats pour syslog sur TLS, on discute le volume à transmettre (tout, ou seulement les erreurs), on calcule la priorité de messages syslog avec la syntaxe du sélecteur, puis on place relais, collecteurs et périphériques entre deux sites.
• SISR, métropole 2022 (alors E6, U6), cas CalédoBank : le dossier A, « Centralisation et exploitation des informations de supervision », demande une synthèse sur l'apport de la suite Elastic Stack, puis l'analyse d'un extrait du journal d'un serveur d'échange de fichiers pour identifier l'attaque subie.
• SISR, métropole 2026 (U7), cas SPARCLE : la mission B3 fournit deux alertes du SOC d'un prestataire, avec leurs identifiants MITRE ATT&CK (T1071.001 et T1105) ; on explique les activités détectées, leur légitimité et pourquoi la seconde est jugée plus grave.

Pour aller plus loin. Le chapitre Journaux, SIEM et détection des incidents du cours Cybersécurité des infrastructures montre l'intégration des pare-feu et des IDS dans le SIEM, et le chapitre IDS et IPS les sondes qui l'alimentent.

Exercices