Syslog est l’acronyme de System Logging Protocol et désigne un protocole standard qui sert à envoyer des fichiers du journal système ou des messages ayant trait à des événements à un serveur dédié appelé serveur syslog. On l’utilise avant toute chose pour collecter différents journaux d’événements auprès de plusieurs machines et pour les transférer vers un emplacement central depuis lequel on pourra les consulter et les examiner.
Le protocole est activé sur la plupart des périphériques réseau tels que les routeurs, les switches, les pare-feu, et même certains modèles d’imprimantes et de scanners. Il est aussi disponible sur les systèmes de type Unix et Linux et sur quantité de serveurs web dont Apache. Syslog n’est pas installé par défaut sur les systèmes Windows, qui utilisent leur propre journal d’événements Windows, baptisé Windows Event Log. Ces événements peuvent être transférés par le biais d’utilitaires externes ou d’autres configurations mettant à contribution le protocole syslog.
Syslog est défini dans le RFC 5424, The Syslog Protocol, qui rendait obsolète le précédent RFC 3164.
Les composants de syslog
Sur tous les types de périphériques, différents événements sont générés par le système à la suite de changements de situation. Ces événements sont en général enregistrés localement à un emplacement où l’administrateur pourra les consulter et les analyser. Cependant, examiner une importante quantité de journaux d’événements sur un nombre tout aussi élevé de routeurs, de switches et de systèmes prendrait un temps fou et s’avèrerait peu commode. Syslog remédie à ce problème en transférant ces événements vers un serveur centralisé.
Le procédé de transmission de syslog
D’ordinaire, Syslog se sert du protocole UDP via le port 514, mais on peut le configurer pour utiliser n’importe quel port. En outre, certains appareils s’appuient sur TCP 1468 pour envoyer des données syslog de manière à accuser réception des messages.
La transmission des paquets syslog se fait de manière asynchrone. Les éléments pouvant donner lieu à la création d’un message sont définis au sein même du routeur, commutateur ou serveur. Contrairement à d’autres protocoles de supervision comme SNMP, il n’y a pas de mécanisme de collecte des données syslog. Sur certains déploiements, on peut utiliser le protocole SNMP pour configurer ou modifier les paramètres syslog à distance.
Un message syslog se compose de 3 parties : le PRI (le niveau de priorité calculé), le HEADER (en-tête comportant les informations d’identification), et le MSG (le message lui-même).
Les données PRI envoyées via le protocole syslog sont le fruit de deux valeurs numérales qui permettent de classifier le message. La première est la Facility value, c’est-à-dire la catégorie. Elle correspond à une des 15 valeurs prédéfinies, ou aux diverses valeurs définies localement en ce qui concerne les codes 16 à 23. Elles assignent une catégorie au type de message ou au système à l’origine de l’événement.
| Number | Description de la fonctionnalité |
| 0 | Messages du noyau |
| 1 | Messages de l’espace utilisateur |
| 2 | Messages du système de messagerie |
| 3 | Messages des processus d’arrière-plan |
| 4 | Messages d’authentification |
| 5 | Messages générés par syslogd lui-même |
| 6 | Messages d’impressions |
| 7 | Messages d’actualités |
| 8 | Messages UUCP |
| 9 | Taches planifiées (at/cron) |
| 10 | Sécurité / élévation de privilèges |
| 11 | Logiciel FTP |
| 12 | Synchronisation du temps NTP |
| 13 | Log audit |
| 14 | Log alert |
| 15 | Taches planifiées (at/cron) |
| 16 - 23 | Utilisation locale 0 - 7 |
La seconde partie d‘un message syslog catégorise l’importance ou la gravité du message par un chiffre allant de 0 à 7.
| Code | Severity | Description |
| 0 | Emergency | Système inutilisable. |
| 1 | Alert | Une intervention immédiate est nécessaire. |
| 2 | Critical | Erreur critique pour le système. |
| 3 | Error | Erreur de fonctionnement. |
| 4 | Warning | Avertissement (une erreur peut intervenir si aucune action n’est prise). |
| 5 | Notice | Événement normal méritant d’être signalé. |
| 6 | Informational | Pour information. |
| 7 | Debug | Message de mise au point. |
Les valeurs de ces deux parties ne répondent pas à une définition stricte. Ainsi, c’est au système ou à l’application qu’il appartient de déterminer sous quelle forme il convient d’enregistrer un événement (par exemple, en tant qu’avertissement, note, etc.) et sous quelle catégorie. Au sein d’un même service ou application, moins le chiffre correspondant au code est élevé, plus le problème affectant le processus en question est grave.
Les deux valeurs sont agrégées pour produire un indice de Priorité qui est envoyé conjointement au message. Cet indice se calcule en multipliant la catégorie par 8 et en y ajoutant le niveau de gravité. Plus le PRI est bas, plus la priorité est élevée.
Priorité = (catégorie x 8) + gravité
Ainsi, un message du noyau se verra attribuer une valeur plus faible (priorité plus élevée) qu’une log alert, quelle que soit la gravité de cette dernière. Parmi les autres identifiants du paquet, on trouve notamment le nom d’hôte, l’adresse IP, l’identifiant du processus, le nom de l’application, et l’horodatage du message.
En pratique, la formulation ou le contenu du message syslog n’est pas défini par le protocole. Certains messages se composent de texte simple et lisible par l’homme, tandis que d’autres sont uniquement lisibles par des machines.
Par convention, les messages ne dépassent pas les 1024 octets.
<165>1 2017-05-11T21:14:15.003Z mymachine.example.com - ID47 [exampleSDID@32473 iut="3" eventSource=" eventID="1011"] BOMAn application log entry...
Extraits du message syslog :
| Partie | Valeur | Information |
| PRI | 165 | Facility = 20, Severity = 5 |
| VERSION | 1 | Version 1 |
| TIMESTAMP | 2017-05-11T21:14:15.003Z | Message created on 11 May 2017 at 09:14:15 pm, 3 milliseconds into the next second |
| HOSTNAME | mymachine.example.com | Message originated from host "mymachine.example.com" |
| APP-NAME | su | App-Name: "su" |
| PROCID | - | PROCID unknown |
| MSGID | ID47 | Message-ID: 47 |
| STRUCTURED-DATA | [exampleSDID@32473 iut="3" eventSource=" eventID="1011"] | Structured Data Element with a non-IANA controlled SD-ID of type "exampleSDID@32473", which has three parameters |
| MSG | BOMAn application log entry... | BOM indicates UTF-8 encoding, the message itself is "An application log entry..." |
Le serveur syslog est parfois appelé « collecteur syslog » ou « récepteur ».
Les messages syslog sont acheminés de l’appareil qui les génère vers le collecteur. L’adresse IP du serveur syslog de destination doit être configurée sur l’appareil lui-même, ce qui se fait par l’intermédiaire de la ligne de commande ou d’un fichier « .conf ». Une fois qu’elle a été paramétrée, toutes les données syslog seront envoyées à ce serveur. Précisons que le protocole syslog est dénué de mécanisme permettant à un autre serveur d’interroger des données syslog.
La plupart des déploiements Unix et des fournisseurs de réseau comme Cisco ont mis au point leurs propres collecteurs syslog de type barebone, mais on en trouve également bien d’autres sur le marché.
PRTG, le logiciel de supervision de Paessler, intègre un capteur Syslog Receiver. Le récepteur collecte tous les messages syslog arrivés à bon port. Pour utiliser cette fonction, l’administrateur doit ajouter le récepteur syslog, puis configurer l’adresse IP de ce serveur comme serveur de destination des données syslog sur tous les appareils à superviser.
Après avoir recueilli les données, le tableau de bord de PRTG indique :
- Le nombre de messages syslog reçus par seconde.
- Le nombre de messages classifiés comme des « avertissements » par seconde.
- Le nombre de messages classifiés comme des « erreurs » par seconde.
- Le nombre de paquets perdus par seconde.
Le protocole syslog peut générer une grande quantité de messages. Syslog se contente de les transférer aussitôt qu’il les génère. Ainsi, un serveur syslog de qualité se doit de pouvoir filtrer correctement les messages et de réagir comme il se doit aux données entrantes.
Le capteur Syslog Receiver de PRTG vous donne la possibilité de définir des règles de filtrage. Celles-ci permettent d’inclure ou d’exclure certains messages syslog comme les avertissements ou les erreurs, indépendamment de la façon dont l’appareil les a générés à l’origine. Ce filtrage donne aux administrateurs l’assurance d’être alertés de toutes les erreurs auxquelles ils prêtent de l’importance, sans pour autant être importunés par celles qu’ils jugent moins préoccupantes.
Le protocole syslog ne comporte aucun mécanisme de sécurité : il ne propose pas de système d’authentification intégré qui permettrait de vérifier que les messages proviennent bel et bien de l’appareil qui affirme en être l’émetteur. Il est dépourvu de technologies de cryptage vouées à dissimuler la nature des informations transmises au serveur. Il est particulièrement sensible aux fameuses playback attacks, ou « attaques par rejeu », un type de cyberattaque où les hackers interceptent, puis réitèrent une transmission valide en passant par un réseau afin de provoquer une réaction.
Configuration des appareils
La plupart des implémentations syslog permettent de paramétrer les fonctionnalités et les seuils de gravité qui génèreront des événements syslog destinés à être transférés au serveur syslog. Il est important de configurer cela correctement pour éviter que le serveur et le réseau ne subissent un déluge de trafic inutile. Par exemple, il faut configurer Debug pour qu’il n’envoie jamais de messages, sauf dans le cadre d’un test.
Il est recommandé de définir les paramètres du syslog de manière à ce qu’ils exigent la catégorie la plus élevée (code le plus bas) et la plus grande gravité possible pour minimiser le trafic. Là où une erreur de routage peut laisser à penser qu’une interface est en panne, et doit à ce titre impérativement être signalée, une imprimante réseau de moindre importance peut être configurée pour ne générer du trafic syslog que pour les événements critiques.
Windows
Sur les systèmes Windows, syslog n’est pas intégré au système standard d’enregistrement des événements. On peut cependant se servir d’un utilitaire tiers pour regrouper et transférer vers un serveur syslog les événements générés par le système de journalisation de Windows. Ces utilitaires supervisent les journaux d’événements, créent un événement au format syslog à partir des informations qu’ils y trouvent, et transfèrent les événements au moyen du protocole syslog standard.
Limites
Une des grandes limites du protocole syslog est que l’appareil sous surveillance ne peut générer ou envoyer un événement syslog qu’à la condition d’être opérationnel et connecté au réseau. Une erreur critique provenant du noyau peut ne jamais donner lieu à l’envoi d’une erreur pour la simple et bonne raison que le système est déconnecté. En d’autres termes, syslog n’est pas un bon moyen de surveiller l’état de fonctionnement des appareils.
Syslog n’est pas adapté à la supervision du statut des périphériques réseau, mais peut permettre de contrôler l’état de santé général de l’équipement réseau. Si les logiciels de supervision réseau à l’image de PRTG intègrent une suite d’utilitaires permettant d’observer son réseau, un journal d’événements qui se remplit d’avertissements n’a pas son pareil pour attirer immédiatement l’attention d’un administrateur sur un problème. Un mécanisme de supervision syslog dûment configuré détectera toute augmentation soudaine du nombre et de la gravité des événements, et avertira probablement l’administrateur avant qu’un problème perceptible des utilisateurs ne se produise.
Sécurité/autorisations/audit
Un réseau d’entreprise lambda contient de nombreux appareils auxquels personne n’est censé avoir accès en temps normal. Si un commutateur distant auquel on ne se connecte qu’à chaque cycle d’audit fait soudain l’objet de tentatives de connexion quotidiennes (qu’elles aboutissent ou non), il revient à l’administrateur de tirer les choses au clair. Sur ces types d’appareils, syslog peut être configuré pour transférer tous les événements d’authentification à un serveur syslog, sans qu’il soit nécessaire d’installer et de paramétrer un agent de supervision en tant que tel.
Syslog permet par ailleurs de s’assurer que les événements critiques sont enregistrés et stockés hors du serveur d’origine. Le premier réflexe d’un attaquant qui vient d’infiltrer un système est de couvrir les traces qu’il a laissées dans le journal. Heureusement, les événements transmis via syslog lui seront inaccessibles.
Application monitoring
There are plenty of ways to monitor how an application is running on a server. However, those monitors can overlook how the application is affecting other processes on the server. While high CPU or memory utilization is easy enough to detect with other monitors, logged events can help show more possible issues. Is an application continuously trying to access a file that is locked? Is there an attempted database write generating an error? Events like these may go undetected when caused by applications that do a good job of working around errors, but they shouldn’t be ignored. Syslog will make sure those logged events get the attention they deserve.
Supervision des applications
Nombreuses sont les méthodes permettant de superviser la façon dont une application s’exécute sur un serveur. Cependant, elles peuvent parfois négliger l’impact de ladite application sur les autres processus qui s’exécutent sur le serveur. Si une utilisation excessive de CPU ou de mémoire échappe rarement aux autres moniteurs, l’examen des événements enregistrés permet de découvrir d’autres erreurs potentielles. Une application tente en permanence d’accéder à un fichier verrouillé ? Une tentative d’écriture de la base de données génère une erreur ? Des événements de ce genre peuvent passer inaperçus quand ils sont provoqués par des applications capables de contourner les erreurs, mais ils ne doivent pas rester sans suite. Syslog veillera à ce que ces événements enregistrés reçoivent toute l’attention qu’ils réclament.
