Reliable Event Logging Protocol

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.

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 acquittemment 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.

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 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.

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.

• Rsyslog

• RELP - The Reliable Event Logging Protocol - spécification
• Tutoriel RELP