Unisphere for PowerMax 9.2 Remote Secure Syslog
Résumé: Unisphere for PowerMax Secure Syslog comment et quand l’utiliser. Conception et normes de l’industrie
Symptômes
Historique syslog
Syslog a été développé dans les années 1980 par Eric Paul Allman (né le 2 septembre 1955).
Eric est un programmeur informatique américain qui a développé Sendmail et son précurseur Delivermail à la fin des années 1970 et au début des années 1980 à l’UC Berkeley. En 1998, Allman et Greg Olson ont cofondé la société Sendmail, Inc. Format de journalisation utilisé par l’agent de transfert de messages MTA, appelé syslog. Syslog a d’abord été utilisé uniquement par Sendmail, mais est finalement devenu un format standard non officiel utilisé par d’autres programmes indépendants pour la journalisation. Plus tard, ce format a été officialisé par la Rfc 3164 en 2001 ; Cependant, le format original a été rendu obsolète par la révision la plus récente, RFC 5424.
Groupe de travail sur l’ingénierie de l’Internet
L’IETF (Internet Engineering Task Force) est une organisation de normes ouvertes, qui développe et promeut des normes Internet volontaires, en particulier les normes qui composent la suite de protocoles Internet (TCP/IP).
Il n’a pas de liste officielle de membres ni de conditions d’adhésion. Tous les participants et les gestionnaires sont des bénévoles, bien que leur travail soit financé par leurs employeurs ou commanditaires.
L’Internet Architecture Board (IAB) supervise les relations externes de l’IETF et les relations avec l’éditeur de la RFC. L’IAB fournit une orientation technique à long terme pour le développement de l’Internet. L’IAB est également conjointement responsable du Comité de surveillance administrative de l’IETF (IAOC), qui supervise l’activité de soutien administratif de l’IETF (IASA), qui fournit un soutien logistique, etc., à l’IETF.
L’IAB gère également l’Internet Research Task Force (IRTF), avec lequel l’IETF entretient plusieurs relations intergroupes.
Groupe de pilotage
L’Internet Engineering Steering Group (IESG) est un organe composé du président de l’Internet Engineering Task Force (IETF) et des directeurs régionaux. Il fournit l’examen technique final des normes Internet et est responsable de la gestion quotidienne de l’IETF. Il reçoit les recours contre les décisions des groupes de travail, et l’IESG prend la décision de faire progresser les documents dans le domaine des normes.
Le protocole Syslog
Syslog utilizes three layers o "syslog content" is the management information contained in a syslog message. o The "syslog application" layer handles generation, interpretation, routing, and storage of syslog messages. o The "syslog transport" layer puts messages on the wire and takes them off the wire. o An "originator" generates syslog content to be carried in a message. o A "collector" gathers syslog content for further analysis. o A "relay" forwards messages, accepting messages from originators or other relays and sending them to collectors or other relays. o A "transport sender" passes syslog messages to a specific transport protocol. o A "transport receiver" takes syslog messages from a specific transport protocol. Diagram 1 shows the different entities separated by layer. +-------------------------+ +----------------------+ | content | | content | |------------------------| |----------------------| | syslog application | | syslog application | | | | | (originator, | | | | (collector, relay) |------------------------| |----------------------| | syslog transport | | syslog transport | (transport sender, | | | | (transport receiver) +------------------------+ +----------------------+ ^ ^ | | -----------------------------
Comment le journal syslog est-il transporté ?
Il existe deux façons courantes d’envoyer des messages syslog. Bien que la norme RFC 5424 exige que toutes les implémentations syslog prennent en charge un transport réseau TLS chiffré sur TCP, la plupart des messages syslog sont toujours remis à l’aide de l’ancienne méthode UDP. Dans la version UDP, les messages sont simplement placés dans la partie données d’un paquet UDP et envoyés au serveur via le port UDP 514. Chaque message tient généralement dans un seul paquet. UDP est sans état et sans session, il n’y a donc aucun accusé de réception. Les paquets sont envoyés dans le réseau. Cela pose le problème évident que tout type de problème réseau pourrait empêcher la livraison du paquet, auquel cas vous ne saurez peut-être pas que le réseau est en panne parce qu’il ne peut pas vous le dire. Cela signifie également que des paquets importants peuvent parfois être perdus ou endommagés pendant le transport.
Principes de base
Les principes suivants s’appliquent à la communication syslog :
o Le protocole syslog ne permet pas d’accuser réception de la remise des messages. Bien que certains transports puissent fournir des informations d’état, d’un point de vue conceptuel, syslog est un protocole de communication simplexe pur.
o Les initiateurs et les relais peuvent être configurés pour envoyer le même message à plusieurs collecteurs et relais.
o Les fonctionnalités d’origine, de relais et de collecteur peuvent résider sur le même système.
Mappage du transport minimal requis
Toutes les mises en œuvre de cette spécification DOIVENT prendre en charge un transport basé sur TLS comme décrit dans [RFC5425].
Toutes les mises en œuvre de cette spécification DEVRAIENT également prendre en charge un transport basé sur UDP comme décrit dans [RFC5426]. Il est RECOMMANDÉ que les déploiements de cette spécification utilisent le transport basé sur TLS.
La nature libre des messages syslog est la plus grande force de syslog, mais c’est aussi le plus grand problème de syslog. Il est très difficile d’analyser un journal comprenant des événements provenant de dizaines de systèmes différents de différents fournisseurs et de leur donner un sens simultanément. Quels messages représentent quelles fonctions ? Et lesquels représentent des événements critiques par rapport à de simples messages d’information ?
Pour répondre à ces questions, le protocole syslog (qui est défini dans la RFC 5424) fournit ces messages de forme libre avec des champs spéciaux appelés « facility » et « severity ».
(Notez que la RFC 5424 est la norme pour syslog, mais que toutes les implémentations syslog ne sont pas conformes à la RFC 5424. Le protocole syslog existe depuis très longtemps et certaines implémentations pré-standard sont toujours utilisées.)
Exigences de sécurité pour Syslog
Les messages Syslog peuvent transiter par plusieurs tronçons pour parvenir au collecteur prévu. Certains réseaux intermédiaires peuvent ne pas être considérés comme fiables par l’initiateur, le relais ou le récepteur, car le réseau se trouve dans un domaine de sécurité ou à un niveau de sécurité différent de celui de l’initiateur, du relais ou du collecteur. Un autre problème de sécurité est que l’initiateur, le relais ou le récepteur lui-même se trouve dans un réseau non sécurisé.
Plusieurs menaces doivent être prises en compte pour la sécurité du journal syslog.
Les principales menaces sont les suivantes :
o Mascarade. Un expéditeur de transport non autorisé peut envoyer des messages à un destinataire de transport légitime, ou un destinataire de transport non autorisé peut essayer de tromper un expéditeur de transport légitime en lui envoyant des messages syslog.
o Modification. Un attaquant entre l’expéditeur de transport et le récepteur de transport peut modifier un message syslog en transit, puis transférer le message au destinataire de transport. Une telle modification peut amener le destinataire du transport à mal comprendre le message ou à le faire se comporter de manière indésirable.
o Divulgation. Une entité non autorisée peut examiner le contenu des messages syslog et obtenir un accès non autorisé aux informations. Certaines données contenues dans les messages syslog sont sensibles et peuvent être utiles à un attaquant, telles que le mot de passe d’un administrateur ou d’un utilisateur autorisé.
La menace secondaire est
o Modification du flux de messages. Un attaquant peut supprimer un ou plusieurs messages syslog d’une série de messages, relire un message ou modifier la séquence de remise. Le protocole syslog lui-même n’est pas basé sur l’ordre des messages. Toutefois, un événement d’un message syslog peut être lié sémantiquement aux événements d’autres messages, de sorte que l’ordre des messages peut être important pour comprendre une séquence d’événements.
Les menaces suivantes sont considérées comme étant de moindre importance pour syslog et ne sont pas traitées dans ce document :
o Déni de service
o Analyse du trafic
Utilisation de TLS pour sécuriser le journal syslog
TLS peut être utilisé comme un moyen de transport sécurisé pour contrer toutes les principales menaces qui pèsent sur le journal syslog décrites ci-dessus
o Confidentialité pour contrer la divulgation du contenu du message.
o Vérification de l’intégrité pour contrer les modifications apportées à un message saut par saut.
o Authentification serveur ou mutuelle pour contrer la mascarade.
Remarque : Ce transport sécurisé (c’est-à-dire TLS) sécurise uniquement le transport syslog de manière saut-à-hop et ne s’intéresse pas au contenu des messages syslog. En particulier, l’identité authentifiée de l’expéditeur du transport (par exemple, le nom de l’objet dans le certificat) n’est pas nécessairement liée au champ HOSTNAME du message syslog. Lorsque l’authentification de l’origine du message syslog est requise, [SYS-SIGN] peut être utilisé.
Cause
L’image ci-dessus montre l’écran dans Unisphere for PowerMax pour configurer Secure syslog.