Syslog

01 — DéfinitionQu'est-ce que Syslog ?

Syslog (System Log) est un protocole de journalisation standardisé qui permet à des systèmes, applications et équipements réseau d'émettre des messages de log vers un serveur centralisé.

Histoire

Créé dans les années 1980 par Eric Allman dans le cadre du serveur mail Sendmail à l'université de Berkeley. Rapidement adopté par tout l'écosystème Unix, puis étendu aux équipements réseau (Cisco, Juniper, Palo Alto, tous supportent Syslog nativement). Standardisé tardivement par l'IETF :

• RFC 3164 (2001) : « BSD Syslog Protocol » — documentation informative du format historique déjà largement utilisé.
• RFC 5424 (2009) : format moderne remplaçant RFC 3164, plus structuré, avec support des données structurées et UTF-8.
• RFC 5425 (2009) : transport TLS pour Syslog (sécurisation).
• RFC 5426 (2009) : transport UDP précisé.

Architecture classique

• Émetteurs (syslog clients) : serveurs Linux, firewalls, switches, applications, IoT — tout ce qui génère des logs.
• Relais : serveurs intermédiaires qui reçoivent, filtrent et transfèrent vers d'autres destinations.
• Collecteurs (syslog servers) : stockent durablement les logs, souvent avec indexation pour recherche.
• Consommateurs : SIEM, outils d'analyse, alerting.

Pourquoi Syslog est important en cybersécurité

• Centralisation : les logs survivent même si le système émetteur est compromis ou détruit.
• Détection : base des SIEM et corrélations d'événements.
• Forensic : reconstitution chronologique post-incident.
• Conformité : PCI DSS, NIS2, ISO 27001 exigent la journalisation centralisée.
• Universalité : supporté par virtuellement tous les systèmes et équipements.

Implémentations majeures

• rsyslog : successeur moderne de syslogd, défaut sur la plupart des Linux (RHEL, Debian, Ubuntu). Rapide, flexible, modulaire.
• syslog-ng : alternative performante, édition open source et enterprise.
• syslogd BSD : historique, encore présent sur BSD.
• Cisco IOS, Juniper Junos, Palo Alto PAN-OS, Fortinet FortiOS : tous intègrent nativement un client Syslog.
• NXLog, Fluentd, Vector, Fluent Bit : collecteurs modernes multi-source incluant Syslog.

Syslog est l'un de ces standards techniques anciens qui ont traversé quatre décennies sans être remplacés — pas parce qu'il est parfait, mais parce qu'il est universellement implémenté. Dans un data center moderne, Syslog et SSH sont les deux vétérans qu'on retrouve toujours en première ligne de journalisation et administration.

02 — FormatStructure d'un message

Format BSD (RFC 3164)

Format historique encore largement utilisé. Structure simple :

<PRI>TIMESTAMP HOSTNAME TAG: MESSAGE

Exemple :

<34>Oct 11 22:14:15 mymachine sshd[12345]: Failed password for root from 192.0.2.1 port 22

• PRI : <34> = facility × 8 + severity = auth (4) × 8 + crit (2) = 34.
• TIMESTAMP : Oct 11 22:14:15 (pas d'année ni timezone — limitation historique).
• HOSTNAME : mymachine.
• TAG : sshd[12345] (nom du programme + PID).
• MESSAGE : le contenu libre.

Format RFC 5424 — moderne

Format structuré avec plus d'information :

<PRI>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID STRUCTURED-DATA MSG

Exemple :

<34>1 2026-04-23T14:30:00.123Z mymachine.example.com sshd 12345 ID47 [exampleSDID@32473 iut="3" eventSource="Application"] Failed password for root from 192.0.2.1

• VERSION : 1 (version du format).
• TIMESTAMP : ISO 8601 complet avec timezone (RFC 3339).
• HOSTNAME : FQDN complet.
• APP-NAME : sshd.
• PROCID : identifiant du processus.
• MSGID : identifiant du type de message.
• STRUCTURED-DATA : données structurées entre crochets avec SDID (enterprise).
• MSG : le message libre, UTF-8 si préfixé par BOM.

Différences pratiques BSD vs RFC 5424

• Timestamp : BSD simple sans année/timezone, RFC 5424 complet ISO 8601.
• Structured data : seulement RFC 5424 — permet des métadonnées machine-readable.
• UTF-8 : officiellement supporté dans RFC 5424, ambigu en BSD.
• Compatibilité : RFC 5424 est rétro-compatible, mais certains vieux parseurs acceptent seulement BSD.
• Adoption : BSD reste dominant en pratique, beaucoup d'équipements ne parlent que BSD.

Syslog avec données structurées — exemple

<165>1 2026-04-23T14:30:00.123Z server.example.com app 1234 ID47 [authEvent@32473 user="admin" srcIP="192.0.2.1" result="failure"] Authentication failed

Les données structurées (bracket block) permettent aux SIEM de parser automatiquement : user, srcIP, result deviennent des champs indexés directement, sans extraction regex fragile.

03 — SévéritésFacilities et niveaux

Les 8 niveaux de sévérité

• 0 — Emergency (emerg) : système inutilisable, panne majeure.
• 1 — Alert : action immédiate requise.
• 2 — Critical (crit) : conditions critiques (erreur matérielle grave).
• 3 — Error (err) : erreurs nécessitant attention.
• 4 — Warning (warn) : avertissement, situation anormale non bloquante.
• 5 — Notice : événement normal significatif.
• 6 — Informational (info) : messages informationnels standards.
• 7 — Debug : messages de débogage, très verbeux.

Numérotation croissante = importance décroissante. Rétablir cette intuition : emerg = 0 (le plus grave), debug = 7 (le moins grave).

Les 24 facilities standards

• 0 — kern : messages du noyau.
• 1 — user : messages applicatifs utilisateur.
• 2 — mail : système mail.
• 3 — daemon : démons système.
• 4 — auth : authentification/autorisation.
• 5 — syslog : messages internes de Syslog.
• 6 — lpr : système d'impression.
• 7 — news : Usenet (historique).
• 8 — uucp : UUCP (historique).
• 9 — cron : tâches planifiées.
• 10 — authpriv : authentification sensible (isolée).
• 11 — ftp : démon FTP.
• 12 — ntp : sync temps.
• 13 — security : audit sécurité.
• 14 — console : messages console.
• 15 — solaris-cron : cron Solaris.
• 16-23 — local0 à local7 : usages applicatifs personnalisables — les plus utilisés pour applications custom.

Calcul de la PRIORITY value

PRI = facility × 8 + severity

Exemples :

• kern.emerg = 0 × 8 + 0 = 0
• auth.crit = 4 × 8 + 2 = 34
• local0.info = 16 × 8 + 6 = 134
• cron.notice = 9 × 8 + 5 = 77
• daemon.debug = 3 × 8 + 7 = 31

Filtrage dans la configuration

Exemple rsyslog.conf ou /etc/syslog.conf :

# Tous les auth de niveau warning et plus → fichier dédié
auth.warn                       /var/log/auth-high.log

# Mails critiques → alerte admin
mail.crit                       root

# Tout sauf debug → log général
*.*;*.!debug                    /var/log/syslog

# Local0 (application custom) → SIEM distant via TCP
local0.*                        @@siem.example.com:514

# Kernel emerg → console immédiatement
kern.emerg                      /dev/console

Les notations @ = UDP, @@ = TCP.

Niveaux usuels en production

• Minimum recommandé : collecter 0-5 (emerg à notice).
• Standard : 0-6 (inclut info).
• Debug en production : rarement, sauf debug ciblé temporaire — volume énorme.
• Audit sécurité : toujours auth.* et authpriv.* collectés intégralement.

04 — TransportUDP, TCP, TLS

UDP 514 — défaut historique

• Port 514, protocole simple.
• Avantage : rapide, peu d'overhead, ne bloque pas l'émetteur si le serveur est lent.
• Limite : non fiable — messages perdus en cas de congestion réseau, sans retransmission.
• Limite : messages non chiffrés, interceptables par un attaquant réseau.
• Limite : taille message limitée à 1024 octets historiquement (souvent relâché à ~8 Ko).
• Usage : encore très courant sur équipements réseau simples et LAN de confiance.

TCP 514 — fiabilité

• Même port 514 mais TCP.
• Avantage : retransmission automatique en cas de perte, ordre garanti.
• Avantage : messages plus longs possibles.
• Limite : non chiffré par défaut, interceptable.
• Limite : consommation ressources plus élevée (connexions persistantes).
• Usage : environnements exigeant la non-perte de messages.

TLS 6514 — sécurité

• Port 6514 standard (RFC 5425).
• Chiffrement TLS des messages en transit — pas d'interception possible.
• Authentification mutuelle possible via certificats.
• Recommandé pour traverser des réseaux non fiables ou collecter depuis cloud vers sur site.
• Usage : production moderne, environnements conformes (PCI DSS, HDS, NIS2).

RELP — Reliable Event Logging Protocol

Protocole propriétaire de rsyslog : extension de TCP avec acknowledgement au niveau application. Garantit la non-perte même en cas de déconnexion brutale — très utilisé pour des logs critiques où chaque événement compte.

Ports récapitulatifs

• UDP 514 : défaut.
• TCP 514 : fiabilité.
• TCP 6514 : Syslog sur TLS (RFC 5425).
• TCP 20514 : RELP standard.

Architecture multi-niveaux typique

1. Équipements → relais Syslog local ou régional via UDP/TCP.
2. Relais → serveur de collecte central via TLS.
3. Serveur central → stockage (indexation Elastic, fichiers bruts) + SIEM.
4. SIEM → règles de détection, corrélation, alerting.

Bonnes pratiques de sécurité

• TLS obligatoire sur les liaisons non-trust (WAN, Internet, cloud→onprem).
• Segmentation réseau : serveur Syslog isolé, accès restreint.
• Stockage immuable : WORM (Write Once Read Many), intégrité par hash.
• Synchronisation temps : NTP/PTP sur tous les émetteurs pour timestamps cohérents.
• Rate limiting : protéger le collecteur contre les floods (accidentels ou malveillants).
• Sauvegardes : conservation multi-sites des logs critiques.
• Rétention : minimum 6 mois (souvent 1-3 ans) selon contexte réglementaire.
• Accès lecture : restreint, audité, journalisé lui-même.

05 — UsageEn cybersécurité

Rôle dans l'infrastructure SOC

Syslog est la fondation de la journalisation centralisée qui alimente les SOC. Flux typique :

• Équipements émettent des logs via Syslog.
• Relais les filtrent, enrichissent, routent.
• Collecteur central stocke pour rétention.
• SIEM consomme les flux, applique des règles de détection, corrèle entre sources.
• Analystes SOC investiguent via interface SIEM + requêtes historiques.

Sources Syslog typiques en cybersécurité

• Serveurs Linux/Unix : auth (sshd, sudo), kernel (audit, kernel panics), applications.
• Firewalls : connexions acceptées/bloquées, alertes IPS/IDS. Cisco ASA, Palo Alto, Fortinet, Stormshield — tous émettent Syslog.
• Équipements réseau : routeurs, switches (ACL, port security, Spanning Tree events).
• Proxies web : Squid, Bluecoat/Symantec, Zscaler — logs d'accès URL.
• WAF : ModSecurity, F5, AWS WAF — attaques bloquées.
• VPN : connexions/déconnexions, erreurs auth.
• Applications : via local0-7, web apps, APIs.
• Hyperviseurs : VMware ESXi, Proxmox.
• Appliances sécurité : EDR managers, scanners de vulnérabilités.

Détection via Syslog

Exemples de patterns détectables :

• Brute force SSH : multiples "Failed password" en auth depuis même IP.
• Élévation privilèges : sudo hors horaire normal, users inhabituels.
• Mouvement latéral : connexions SSH/RDP entre machines internes inhabituelles.
• Exfiltration : gros volumes sortants via firewall à destination inattendue.
• Compromission perimétrique : patterns d'attaque sur WAF, firewall.
• Désactivation de logs : absence soudaine de logs d'un système (signe d'attaque).
• Ransomware : patterns de chiffrement massif visible dans les audits fichiers.

Forensic et réponse à incident

Après incident, les logs Syslog centralisés sont souvent l'unique source pour :

• Reconstituer la chronologie de l'attaque.
• Identifier les systèmes compromis.
• Déterminer les données exfiltrées (volumes, destinations).
• Attribuer l'attaque (TTP observées).
• Justifier les mesures prises devant autorités ou assurance.

Un attaquant sophistiqué efface les logs locaux (technique T1070 MITRE ATT&CK Indicator Removal). Les logs centralisés Syslog sauvent la mise — c'est pour ça qu'on les isole et les rend immuables.

Conformité

• PCI DSS : req 10 exige la journalisation et protection des logs, rétention minimum 1 an, 3 mois en ligne.
• NIS2 : obligation de détection et journalisation pour entités essentielles/importantes.
• ISO 27001 : contrôles A.8.15 (logging) et A.8.16 (monitoring).
• HDS : traçabilité des accès aux données de santé.
• RGPD : articles 32 et 33 — journalisation nécessaire pour démontrer les mesures de sécurité et notifier les violations.
• SOC 2 : contrôles sur la journalisation et le monitoring.

Volumes typiques

• Serveur Linux standard : 10-100 MB/jour.
• Firewall entreprise : 1-100 GB/jour selon trafic.
• Proxy web large déploiement : 100 GB - plusieurs TB/jour.
• SI d'une grande entreprise : 1-10+ TB/jour en Syslog agrégé.

Stockage et licensing SIEM deviennent des enjeux financiers majeurs — stratégies de filtrage amont et tiered storage (chaud/froid) essentielles.

06 — AlternativesJournalisation moderne

Windows Event Log

• Système natif Windows, complètement différent de Syslog.
• Structure en événements avec codes numériques, XML.
• Collecte via Windows Event Forwarding (WEF), agents (Splunk UF, Elastic Winlogbeat, NXLog).
• Conversion Syslog via outils (rsyslog imfile module, NXLog).
• Toujours essentiel pour environnements Windows dominants.

systemd journald

• Système moderne Linux, intégré à systemd.
• Format binaire indexé, métadonnées enrichies automatiquement.
• Commandes : journalctl, journalctl --since yesterday, journalctl -u sshd.
• Peut exporter vers Syslog pour compatibilité (syslogd/rsyslog coexistent souvent).
• Avantages : structuration native, filtrage puissant, index rapide.
• Inconvénient : format binaire propriétaire, pas portable comme texte brut.

Fluentd / Fluent Bit

• Collecteurs open source universels, projet CNCF.
• Entrée : Syslog, fichiers, HTTP, Docker, Kubernetes, cloud APIs.
• Traitement : filtres, parsers, enrichissement.
• Sortie : Elasticsearch, Kafka, S3, SIEM, stockage cloud.
• Fluent Bit = version légère pour edge et Kubernetes.
• Standard dans les environnements cloud natifs et Kubernetes.

Vector (Datadog)

• Collecteur moderne écrit en Rust, lancé open source par Datadog.
• Performance supérieure à Fluentd/Fluent Bit sur benchmarks.
• Configuration déclarative (TOML/YAML).
• Adoption rapide depuis 2023-2024, particulièrement pour pipelines de logs à fort volume.

OpenTelemetry Logs

• Standard émergent pour l'observabilité (logs + métriques + traces).
• Protocole OTLP (OpenTelemetry Protocol) en gRPC/HTTP.
• Convergence vers un standard unique pour tous les signaux d'observabilité.
• Adoption progressive dans les nouvelles architectures cloud natives.
• Compatible avec Syslog via collecteurs intermédiaires.

Services cloud natifs

• AWS CloudWatch Logs : logs natifs AWS, intégration avec EC2, Lambda, API Gateway, RDS.
• Azure Monitor Logs / Log Analytics : équivalent Microsoft, adossé à Kusto Query Language (KQL).
• GCP Cloud Logging : service Google Cloud.
• Collecte via agents propriétaires (CloudWatch Agent, Azure Monitor Agent, Ops Agent).
• Tous supportent l'ingestion Syslog via agents ou API.

Agents SIEM propriétaires

• Splunk Universal Forwarder : agent léger qui collecte fichiers, Windows Event Logs, Syslog.
• Elastic Beats : famille d'agents légers (Filebeat, Winlogbeat, Auditbeat, Metricbeat).
• CrowdStrike, SentinelOne, Microsoft Defender : EDR avec collecte de télémétrie, alimentent leurs consoles mais exportent aussi Syslog/API.
• Avantages : intégration riche avec le produit, parsing automatique.
• Inconvénients : couplage vendeur.

Pourquoi Syslog persiste

• Universalité : supporté par virtuellement tout équipement.
• Simplicité : RFC ouvert, pas de licence.
• Équipements legacy : nombreux équipements réseau ne parlent que Syslog.
• Lingua franca : rôle de format d'interchange entre systèmes hétérogènes.
• Compatibilité ascendante : les collecteurs modernes acceptent tous Syslog.

Dans une architecture moderne : Syslog en sortie des équipements → collecteur moderne (Fluentd, Vector) en relais → stockage moderne (Elasticsearch, Loki, S3) et SIEM.

07 — FAQQuestions fréquentes

Syslog est-il toujours pertinent en 2026 ?

Oui, bien qu'il ne soit plus la technologie la plus moderne. Syslog reste universel — supporté par tous les systèmes Unix/Linux, tous les équipements réseau (Cisco, Juniper, Palo Alto, Fortinet, Stormshield), la majorité des appliances de sécurité. Les architectures cloud-natives privilégient parfois des approches plus riches (OpenTelemetry, agents propriétaires), mais Syslog reste la lingua franca pour intégrer des environnements hétérogènes. En 2026, tout SIEM consomme nativement Syslog, et les nouveaux collecteurs (Fluent Bit, Vector) acceptent Syslog en entrée pour assurer la compatibilité. Il ne disparaîtra pas dans les 10 prochaines années.

Quelle différence entre Syslog UDP et TCP ?

UDP (port 514, défaut historique) : rapide, peu d'overhead, mais non fiable — les messages peuvent être perdus en cas de congestion ou panne réseau, sans retransmission. Convient pour réseaux de confiance à faible criticité. TCP (port 514 aussi, moderne) : fiable avec retransmission automatique, ordre garanti, messages plus longs supportés. Recommandé pour logs critiques ou traversée de liens non fiables. TLS (port 6514) : TCP + chiffrement, recommandé pour traverser Internet ou WAN non maîtrisé. La configuration rsyslog : @@server (deux @) = TCP, @server (un @) = UDP.

Combien de temps conserver les logs Syslog ?

Dépend du contexte et des obligations légales/réglementaires. Durées typiques : PCI DSS : minimum 1 an, 3 mois immédiatement disponibles. RGPD : durée proportionnée au but, souvent 6-12 mois pour journalisation sécurité. NIS2 : sans durée fixée explicitement, mais « permettant la détection d'incidents » — pratique typique 12-24 mois. Secteur bancaire / financier : 5-10 ans selon le type de log. Investigations judiciaires : certaines fraudes se révèlent après 2-3 ans — prévoir rétention longue pour incidents critiques. Stockage : tiered typiquement — 30 jours en hot (SSD rapide, SIEM), 6-12 mois en warm (HDD), plus longtemps en cold (S3 Glacier). Compromis coût / disponibilité.

Comment sécuriser un serveur Syslog ?

Plusieurs couches. Réseau : segmentation stricte, le serveur Syslog dans un VLAN dédié, règles firewall limitant les sources. Accès administrateur via bastion uniquement. Transport : TLS obligatoire au-delà du LAN de confiance, authentification mutuelle via certificats pour les équipements sensibles. Stockage : WORM (write-once) via filesystem, NAS ou S3 Object Lock. Hachage des fichiers de logs pour détecter altération. Sauvegardes multi-sites. Accès : lecture restreinte aux analystes SOC + équipes compliance. Tout accès lui-même journalisé. MFA obligatoire. Anti-flood : rate limiting pour éviter qu'un attaquant ne noie les logs avec du bruit (technique courante). Intégrité système : monitoring des binaires rsyslog/syslog-ng (un attaquant qui modifierait la conf pourrait rediriger les logs). Synchronisation temps : NTP sur tous les émetteurs et collecteurs, pour timestamps cohérents et forensic fiable.

Peut-on perdre des logs avec Syslog UDP ?

Oui, c'est le principal reproche fait à UDP. Situations où des logs UDP peuvent être perdus : congestion réseau, saturation du buffer UDP du serveur (par défaut ~200 Ko, à augmenter), panne temporaire du serveur, packet loss sur liaison instable, flood généré par attaque ou incident massif. En pratique : pour équipements avec peu de logs et LAN fiable, UDP est acceptable. Pour logs critiques (auth, firewall, audit sécurité), TCP ou TLS est fortement recommandé. RELP (rsyslog) offre la garantie la plus forte avec acquittement applicatif. Mesurer les pertes : compter les messages émis vs reçus (via numéros de séquence si supportés), alerter si écart. Pour les organisations matures : migration progressive UDP → TCP → TLS → RELP selon criticité.

Comment Syslog s'intègre avec un SIEM ?

Le SIEM est un consommateur typique de flux Syslog. Architectures courantes : Ingestion directe : les équipements envoient leur Syslog directement au SIEM qui écoute sur port 514/6514. Simple mais peut saturer le SIEM. Via relais : Syslog → collecteur (rsyslog, syslog-ng, Fluentd, Vector) → SIEM. Le relais filtre, enrichit, met en forme. Permet de changer de SIEM sans reconfigurer les émetteurs. Parsers : le SIEM applique des parsers (regex, patterns, CIM) pour extraire les champs structurés des messages Syslog texte. Les SIEM modernes (Splunk, Elastic, Chronicle, Sentinel) fournissent des parsers prêts pour les sources courantes (Cisco ASA, Palo Alto, sshd, Apache, etc.). Normalisation : formats standards type ECS (Elastic Common Schema), CEF (Common Event Format), LEEF facilitent l'interopérabilité. Règles de détection : appliquées sur les événements parsés, alertes générées sur patterns suspects. Référentiel commun pour les règles : Sigma rules, mappé sur MITRE ATT&CK.