Syslog - Syslog

Syslog

Auteur(s) original(aux)	Eric Allman
Première version	années 1980
Système opérateur	Unix-like
Taper	Journalisation du système
Site Internet	datatracker .ietf .org /wg /syslog /charter /

Dans le calcul , syslog / s ɪ s l ɒ ɡ / est une norme pour l' enregistrement du message . Il 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 générant 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 généraux d'information, d'analyse et de débogage. Une grande variété de périphériques, tels que des imprimantes, des routeurs et des 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 où un serveur syslog écoute et enregistre les messages provenant des clients.

Histoire

Syslog a été développé dans les années 1980 par Eric Allman dans le cadre du projet Sendmail . Il a été facilement 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 la trouve couramment dans les périphériques réseau, tels que les routeurs .

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

Diverses sociétés ont tenté de revendiquer des brevets pour des aspects spécifiques des implémentations syslog. Cela a eu peu d'effet sur l'utilisation et la normalisation du protocole.

Composants du message

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 de l'appareil.

Établissement

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 équipements disponibles est définie par la norme :

Le mappage entre le code d'installation et le mot-clé n'est pas uniforme dans les différents systèmes d'exploitation et implémentations syslog.

Degré de gravité

La liste des sévérités est également définie 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 dans l'étape finale doit être affectée au niveau d'alerte. Cependant, une erreur survenant lors d'une tentative d'affichage du code postal du client peut se voir attribuer le niveau Erreur voire Avertissement .

Le processus serveur qui gère l'affichage des messages inclut généralement tous les niveaux inférieurs (plus sévères) lorsque l'affichage de niveaux moins sévères est demandé. C'est-à-dire que 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 de notification , d' information et de débogage .

Un message

Dans la RFC 3164, le composant de message (appelé MSG) était spécifié comme ayant ces champs : TAG , qui devrait ê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 qui était appelé CONTENT dans la RFC 3164. Le TAG fait maintenant partie de l'en-tête, mais pas comme un seul champ. Le TAG a été divisé en APP-NAME, PROCID et MSGID. ressemble totalement à l'utilisation de TAG, mais fournit la même fonctionnalité dans la plupart des cas. » Les outils syslog populaires tels que Rsyslog se conforment à cette nouvelle norme.

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

Enregistreur

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 au fichier journal directement 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.

Protocole réseau

Lorsqu'il fonctionne sur un réseau, syslog utilise une architecture client-serveur où le serveur écoute sur un port bien 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 ), avec le serveur écoutant sur le port 514. Comme UDP manque de mécanismes de contrôle de congestion, la prise en charge de la sécurité de la couche de transport est requise dans les implémentations et recommandée pour une utilisation générale sur la transmission. Protocole de contrôle (TCP) port 6514.

Limites

Étant donné que chaque processus, application et système d'exploitation a été écrit indépendamment, il y a peu d'uniformité dans la charge utile du message de journal. Pour cette raison, aucune hypothèse n'est faite quant à sa mise en forme ou son contenu. Un message syslog est formaté (la RFC 5424 donne la définition de la forme augmentée de Backus-Naur (ABNF)), 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.

Perspectives

Divers groupes travaillent sur des projets de normes détaillant l'utilisation de syslog pour plus que la simple journalisation des événements de 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 , PCI DSS , HIPAA et bien d'autres, obligent les organisations à mettre 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 la consolidation des journaux, car il existe de nombreux outils open source et propriétaires pour la création de rapports et l'analyse de ces journaux. Des utilitaires existent 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.

Documents standards Internet

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

• Le protocole syslog de 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 Datagram Transport Layer Security (DTLS) pour Syslog . RFC  6012 .
• Transmission de messages Syslog sur TCP . RFC  6587 .

Voir également

Les références

Liens externes

• Groupe de travail sur l'ingénierie Internet : Datatracker : groupe de travail syslog (fin)
• Institut SANS : "Les tenants et aboutissants de la journalisation système à l'aide de Syslog" ( livre blanc )
• National Institute of Standards and Technology : "Guide de gestion des journaux de sécurité informatique" (Publication spéciale 800-92) (livre blanc)
• Logiciel de gestion de réseau : « Comprendre Syslog : serveurs, messages et sécurité »
• L'informatique de Paessler expliquée - Syslog
• MonitorWare : tout sur Syslog