Journal système

En informatique , syslog / ˈ s ɪ s l ɒ ɡ / est une norme de journalisation des messages . Elle permet de séparer le logiciel qui génère les messages, le système qui les stocke et le logiciel qui les rapporte et les analyse. Chaque message est étiqueté avec un code d'installation, indiquant le type de système qui génère le message, et se voit attribuer un niveau de gravité.

Les concepteurs de systèmes informatiques peuvent utiliser Syslog pour la gestion du système et l'audit de sécurité, ainsi que pour les messages d'information générale, d'analyse et de débogage. Une grande variété de périphériques, tels que les imprimantes, les routeurs et les récepteurs de messages sur de nombreuses plates-formes, utilisent la norme Syslog. Cela permet la consolidation des données de journalisation de différents types de systèmes dans un référentiel central. Des implémentations de Syslog existent pour de nombreux systèmes d'exploitation.

Lorsqu'il fonctionne sur un réseau, Syslog utilise une architecture client-serveur dans laquelle un serveur Syslog écoute et enregistre les messages provenant des clients.

Syslog a été développé dans les années 1980 par Eric Allman dans le cadre du projet Sendmail . Il a été rapidement adopté par d'autres applications et est depuis devenu la solution de journalisation standard sur les systèmes de type Unix . Il existe également une variété d'implémentations sur d'autres systèmes d'exploitation et on le trouve couramment dans les périphériques réseau, tels que les routeurs .

À l'origine, Syslog fonctionnait comme une norme de facto , sans aucune spécification officielle publiée, et de nombreuses implémentations existaient, dont certaines étaient incompatibles. L' Internet Engineering Task Force a documenté le statu quo dans la RFC 3164 en août 2001. Il a été normalisé par la RFC 5424 en mars 2009.

Plusieurs entreprises ont tenté de revendiquer des brevets pour des aspects spécifiques des implémentations de Syslog. Cela a eu peu d'effet sur l'utilisation et la normalisation du protocole.

Les informations fournies par l'expéditeur d'un message Syslog incluent le code d'installation et le niveau de gravité. Le logiciel Syslog ajoute des informations à l'en-tête d'informations avant de transmettre l'entrée au récepteur Syslog. Ces composants incluent un ID de processus d'origine, un horodatage et le nom d'hôte ou l'adresse IP du périphérique.

Un code d'installation est utilisé pour spécifier le type de système qui enregistre le message. Les messages avec des installations différentes peuvent être traités différemment. La ​​liste des installations disponibles est décrite par la norme :

La correspondance entre le code de l'installation et le mot-clé n'est pas uniforme dans les différents systèmes d'exploitation et implémentations Syslog.

La liste des niveaux de gravité est également décrite par la norme :

La signification des niveaux de gravité autres que Urgence et Débogage est relative à l'application. Par exemple, si le but du système est de traiter des transactions pour mettre à jour les informations sur le solde du compte client, une erreur lors de l'étape finale doit être affectée au niveau Alerte . Cependant, une erreur survenant lors d'une tentative d'affichage du code postal du client peut être affectée au niveau Erreur ou même Avertissement .

Le processus serveur qui gère l'affichage des messages inclut généralement tous les niveaux inférieurs (plus graves) lorsque l'affichage des niveaux moins graves est demandé. Autrement dit, si les messages sont séparés par gravité individuelle, une entrée de niveau d' avertissement sera également incluse lors du filtrage des messages d'avis , d'informations et de débogage .

Dans la RFC 3164, le composant de message (appelé MSG) a été spécifié comme ayant ces champs : TAG , qui doit être le nom du programme ou du processus qui a généré le message, et CONTENT qui contient les détails du message.

Décrit dans la RFC 5424, « MSG est ce qu'on appelait CONTENU dans la RFC 3164. Le TAG fait désormais partie de l'en-tête, mais pas en tant que champ unique. Le TAG a été divisé en APP-NAME, PROCID et MSGID. Cela ne ressemble pas totalement à l'utilisation de TAG, mais fournit la même fonctionnalité dans la plupart des cas. » Les outils Syslog populaires tels que NXLog et Rsyslog sont conformes à cette nouvelle norme.

Le champ de contenu doit être codé dans un jeu de caractères UTF-8 et les valeurs d'octets dans la plage de caractères de contrôle ASCII traditionnelle doivent être évitées.

Les messages de journal générés peuvent être dirigés vers diverses destinations, notamment la console , les fichiers, les serveurs syslog distants ou les relais. La plupart des implémentations fournissent un utilitaire de ligne de commande, souvent appelé logger , ainsi qu'une bibliothèque logicielle , pour envoyer des messages au journal.

Pour afficher et surveiller les journaux collectés, il faut utiliser une application cliente ou accéder directement au fichier journal sur le système. Les outils de ligne de commande de base sont tail et grep . Les serveurs de journaux peuvent être configurés pour envoyer les journaux sur le réseau (en plus des fichiers locaux). Certaines implémentations incluent des programmes de reporting pour le filtrage et l'affichage des messages syslog.

Lorsqu'il fonctionne sur un réseau, Syslog utilise une architecture client-serveur dans laquelle le serveur écoute sur un port connu ou enregistré les demandes de protocole des clients. Historiquement, le protocole de couche de transport le plus courant pour la journalisation réseau était le protocole UDP (User Datagram Protocol ), le serveur écoutant sur le port 514. Étant donné que le protocole UDP ne dispose pas de mécanismes de contrôle de congestion, le port 6514 du protocole TCP (Transmission Control Protocol ) est utilisé ; la sécurité de la couche de transport est également requise dans les implémentations et recommandée pour une utilisation générale.

Étant donné que chaque processus, application et système d'exploitation a été écrit indépendamment, la charge utile du message de journal est peu uniforme. Pour cette raison, aucune hypothèse n'est faite sur son formatage ou son contenu. Un message syslog est formaté (la RFC 5424 donne la définition du format ABNF ( Augmented Backus–Naur form )), mais son champ MSG ne l'est pas.

Le protocole réseau est une communication simplex , sans aucun moyen d'accuser réception de la livraison à l'expéditeur.

Différents groupes travaillent sur des projets de normes détaillant l’utilisation de Syslog pour plus que la simple journalisation des événements réseau et de sécurité, comme son application proposée dans l’environnement des soins de santé.

Les réglementations, telles que la loi Sarbanes-Oxley , la norme PCI DSS , la norme HIPAA et bien d'autres, exigent que les organisations mettent en œuvre des mesures de sécurité complètes, qui incluent souvent la collecte et l'analyse de journaux provenant de nombreuses sources différentes. Le format Syslog s'est avéré efficace pour consolider les journaux, car il existe de nombreux outils open source et propriétaires pour la création de rapports et l'analyse de ces journaux. Il existe des utilitaires pour la conversion du journal des événements Windows et d'autres formats de journaux en Syslog.

Les fournisseurs de services de sécurité gérés tentent d’appliquer des techniques analytiques et des algorithmes d’intelligence artificielle pour détecter des modèles et alerter les clients des problèmes.

Le protocole Syslog est défini par des documents RFC ( Request for Comments ) publiés par l' Internet Engineering Task Force ( normes Internet ). Voici une liste des RFC qui définissent le protocole Syslog :

• Le protocole syslog BSD . RFC 3164 .(obsolète par le protocole Syslog . RFC 5424 . )
• Livraison fiable pour syslog . RFC 3195 .
• Le protocole Syslog . RFC 5424 .
• Mappage de transport TLS pour Syslog . RFC 5425 .
• Transmission de messages Syslog via UDP . RFC 5426 .
• Conventions textuelles pour la gestion Syslog . RFC 5427 .
• Messages Syslog signés . RFC 5848 .
• Mappage de transport DTLS (Datagram Transport Layer Security) pour Syslog . RFC 6012 .
• Transmission de messages Syslog via TCP . RFC 6587 .