| Fonction | Transfert de journaux d'événements |
|---|---|
| Sigle | RELP |
| Auteur(s) / Autrice(s) | Rainer Gerhards |
| Port | Non standard [1] |
Reliable Event Logging Protocol ou RELP est un protocole définissant un service de journaux d'événements d'un système informatique.
Historique
RELP est développé à partir de 2008 par Rainer Gerhards (en)[2], le créateur de Rsyslog. Il prolonge l'ébauche Internet de protocole Simple Event Logging Protocol [3], proposée en février 2003 sur la liste de diffusion lOganalysis par la même personne. Il faut probablement y voir un lien avec le protocole Simple Event Transfer Protocol[4], propriété de Adiscon GmbH dont l'actionnaire principal est Rainer Gerhards[5].
L'auteur de RELP justifie sa création par les constats suivants [2] :
- le RFC 3195 ajoute trop de complexité non nécessaire pour un transport fiable et léger (voir protocole BEEP - RFC 3080)
- limitation technique inhérente au protocole de transport TCP [6]
- lenteur des processus de décisions de l'IETF.
Détails techniques
Le protocole syslog est défini par le RFC 5424. Construit sur une architecture sur 3 couches (contenu, application et transport), il s'agit d'un protocole de communication de type simplex c'est-à-dire monodirectionnel. Dès lors, aucun acquittement n'est possible. Historiquement, il s'appuie sur le mode de transport UDP. Pour des raisons d'interopérabilité, le maintien de ce mode de transport est requis (RFC 5426). Ce choix devait permettre de limiter la charge de travail pour des équipements embarqués pouvant générer beaucoup de message.
L'utilisation complémentaire du mode de transport TCP devait permettre d'assurer une meilleure assurance concernant la bonne livraison ce que contredit Rainer Gerhards.
Sécurité
Le protocole syslog basé sur UDP souffre de nombreux problèmes de sécurité dont voici une liste non exhaustive :
- perte d'intégrité (spécification autorisant la troncature les messages selon leur taille, modification intentionnelle (en) par un attaquant ou accidentelle lors du transit) ;
- perte de disponibilité : perte de message sans avertissement, possibilité d'entraîner une congestion du réseau (inondation intentionnelle par un attaquant ou bien accidentelle par une mauvaise configuration), manque d'information pour détecter une configuration incorrecte (p. ex. mauvaise cible, boucle de transfert), interblocage entre le démon syslogd avec un autre processus disposant d'une priorité maximale (cas des machines *nix)) ;
- perte de confidentialité : message non chiffré, possibilité d'attaque par rejeu.
Le RFC 5425 recommande de chiffrer les messages et d'authentifier la cible en utilisant TLS comme protocole de transport pour aboutir au protocole hybride syslog over TLS. Cette option est disponible dans l'implémentation de RELP par Rsyslog[7].
Enfin une obfuscation est possible si l'émetteur ne prend pas en compte la capacité finale de stockage et de traitement humaine, assistée éventuellement par un SIEM. Ceci peut être intentionnel pour masquer l'activité d'un attaquant.
Implémentations
RELP est supporté par Rsyslog depuis la version 3.15.0[6]. Initialement il ne vise que à permettre l'échange de messages entre 2 instances de Rsyslog. Cependant, Rsyslog étant un standard de facto, d'autres outils supportent ce protocole. Pour faciliter sa dissémination, le projet Rsyslog a mis a disposition et maintient la bibliothèque écrite en C librelp.
Voir aussi
Notes et références
- ↑ (en) « 1410505 - RELP port for rsyslog », sur redhat.com (consulté le ).
- (en) « RELP - the reliable event logging protocol », sur Rainer Gerhards, (consulté le ).
- ↑ http://www.monitorware.com/en/workinprogress/selp.txt
- ↑ (en) « SETP », sur Adiscon, (consulté le ).
- ↑ (en) « Adiscon », sur Adiscon (consulté le ).
- (en) « On the (un)reliability of plain tcp syslog... », sur Rainer Gerhards, (consulté le ).
- ↑ (en) « Librelp 1.1.0 », sur rsyslog, (consulté le ).
