🎓 Niveau : 🟢 Débutant
📋 Prérequis : notions de réseau (IP, ports UDP/TCP), notion de serveur
Quand un serveur plante, qu'un pare-feu bloque une attaque ou qu'un disque sature, l'appareil l'écrit dans un journal (log). Problème : dans une entreprise, il y a des dizaines d'équipements, chacun avec ses propres logs, dispersés partout. Impossible d'enquêter efficacement quand un incident touche plusieurs machines.
Syslog (System Logging Protocol, « protocole de journalisation système ») résout ce problème en centralisant tous les logs au même endroit. Chaque équipement envoie ses messages à un serveur de logs unique. On peut alors tout chercher, corréler et conserver au même endroit — essentiel pour le dépannage, la sécurité et la conformité.
- Log (journal) : ligne horodatée décrivant un événement (« connexion réussie », « erreur disque », « paquet bloqué »).
- Syslog : standard décrivant le format des messages de log et le protocole pour les transporter sur le réseau.
- Serveur Syslog (collecteur) : machine qui reçoit et stocke les logs de tout le parc (ex. rsyslog, syslog-ng, Graylog).
- Facility : catégorie de la source du message (noyau, mail, authentification, etc.).
- Severity : niveau de gravité, de 0 (urgence absolue) à 7 (débogage). Exemples :
emergency, error, warning, info, debug.
- Ports : Syslog utilise traditionnellement le port UDP 514, ou TCP 514, voire TCP 6514 chiffré (TLS).
- Un équipement (serveur, routeur, pare-feu) génère un événement.
- Il formate un message Syslog : date/heure, facility, severity, nom de la machine, texte.
- Il envoie ce message au serveur Syslog via le réseau (UDP/TCP 514).
- Le serveur Syslog reçoit, classe et stocke le message (souvent par machine, par date, par gravité).
- L'administrateur consulte, recherche et filtre les logs, et configure des alertes sur les événements graves.
💡 La severity permet de filtrer : on peut ignorer le debug au quotidien et déclencher une alerte dès qu'un message error ou critical arrive.
graph LR
R[Routeur] -->|UDP 514| S[Serveur Syslog]
F[Pare-feu] -->|UDP 514| S
W[Serveur Web] -->|TCP 514| S
L[Serveur Linux] -->|TCP 6514 TLS| S
S --> DB[(Stockage des logs)]
A[Admin] -->|recherche / alertes| S
L'entreprise « TechCorp » installe un serveur Syslog avec rsyslog. Elle configure le pare-feu, deux serveurs Linux et les switchs pour qu'ils envoient leurs logs vers 10.0.0.50:514.
Un matin, plusieurs utilisateurs ne peuvent plus se connecter. L'administrateur ouvre le serveur Syslog, filtre sur la severity error des 30 dernières minutes, et voit que le serveur d'authentification a logué disk full. En 2 minutes, il a trouvé la cause sans se connecter à dix machines : tout était centralisé.
- Centraliser tous les équipements vers un seul collecteur (et garder une copie locale).
- Synchroniser l'heure (NTP) sur tout le parc : sans horloges alignées, corréler les logs devient impossible.
- Chiffrer le transport (TCP + TLS, port 6514) pour les réseaux sensibles.
- Définir une rétention (combien de temps garder les logs) selon les obligations légales.
- Mettre des alertes sur les severities critiques.
UDP 514 ne garantit pas la livraison : un message perdu l'est sans avertissement. Pour les logs critiques (sécurité), préfère TCP qui confirme la réception.
- Horloges non synchronisées → impossible de remettre les événements dans l'ordre.
- Stockage saturé par les logs
debug laissés actifs en production.
- Logs en clair sur le réseau (UDP non chiffré) : un attaquant peut les lire.
- Aucune sauvegarde du collecteur : si le serveur de logs tombe, l'historique disparaît.
- Syslog centralise les journaux de tout le parc sur un serveur unique pour faciliter le dépannage et la sécurité.
- Chaque message porte une facility (source) et une severity (gravité) pour filtrer et alerter.
- Synchroniser l'heure (NTP) et chiffrer (TCP/TLS) sont indispensables pour des logs exploitables et sûrs.
« Un log que personne ne lit ne sert à rien ; centralise-le pour qu'il parle. » 🔑