8. Security Considerations (Considérations de sécurité)
8.1. UNICODE
L'Unicode valide qui peut être malicieusement malformé est un problème pour les messages syslog (voir [UNICODE-TR36]). Par exemple, un message peut être conçu de manière à apparaître comme un message bénin mais après décodage, il contient du contenu malveillant. Pour se protéger contre cela, les applications DOIVENT encoder les messages sous la "forme la plus courte" comme exigé dans la section 6.3.3. De plus, toutes les applications décodant ces messages DOIVENT vérifier que l'encodage est sous la "forme la plus courte" avant d'opérer sur l'un des caractères.
8.2. Control Characters (Caractères de contrôle)
Le PARAM-VALUE peut contenir des caractères de contrôle. Ceci est une fonctionnalité nécessaire pour prendre en charge le passage de toute information pouvant être représentée en Unicode. Cependant, cela signifie également que les messages syslog peuvent contenir des caractères qui ont des significations spéciales pour certains périphériques d'affichage. Par exemple, les caractères de retour chariot pourraient être utilisés pour écraser des parties précédemment affichées d'un message sur un affichage de terminal, cachant potentiellement un message pertinent pour la sécurité ou une modification. De plus, il existe des caractères de contrôle qui peuvent affecter la façon dont le contenu est affiché, ce qui permet également une possibilité de fausse représentation.
La spécification RECOMMANDE que les applications syslog NE DEVRAIENT PAS émettre de caractères de contrôle dans PARAM-VALUE. Si une application syslog utilise des caractères de contrôle, il pourrait ne pas être possible d'interpréter le message sur le collector ou le relay. De plus, les caractères de contrôle PEUVENT confondre ou induire en erreur les spectateurs des messages de journal. Il est RECOMMANDÉ que les applications syslog qui reçoivent des messages syslog filtrent les caractères de contrôle ou les remplacent par un caractère inoffensif avant de les afficher.
Un risque similaire existe avec le champ MSG. Bien que le jeu de caractères pour MSG soit moins strict, il est RECOMMANDÉ que des précautions similaires soient prises avec la partie MSG d'un message syslog.
8.3. Message Truncation (Troncature de message)
Cette spécification exige que les transport receivers conformes puissent accepter des messages d'une longueur allant jusqu'à 480 octets. Les transport receivers DEVRAIENT pouvoir accepter des messages d'une longueur allant jusqu'à 2048 octets. Tout ce qui dépasse ces longueurs minimales requises est acceptable mais optionnel. Les expéditeurs sont toujours libres d'envoyer des messages de n'importe quelle longueur qu'ils souhaitent. Cependant, les messages peuvent être tronqués par les transport receivers ou peuvent devoir traverser des chaînes de relays qui incluent des périphériques ayant des capacités de longueur de message maximale inférieures. Cette troncature peut altérer la signification d'un message ou supprimer des informations critiques. Cela peut également rendre difficile l'exécution d'une analyse de journal significative.
La probabilité de troncature peut être considérablement réduite en maintenant la longueur du message en dessous de 480 octets. Dans le même temps, les implémentations DOIVENT pouvoir accepter des messages d'au moins 480 octets et DEVRAIENT pouvoir accepter des messages de 2048 octets. Tout ce qui dépasse cela est discrétionnaire.
8.4. Replay (Rejeu)
La transmission de messages syslog, par elle-même, ne fournit pas d'assurance que le message reçu est effectivement le message qui a été envoyé ou même que le message provient de l'expéditeur prétendu. Même si une vérification cryptographique est effectuée, un observateur malveillant pourrait enregistrer des messages valides et les rejouer à un moment ultérieur. Cela pourrait amener un destinataire à croire qu'un événement particulier s'est produit à un moment différent du moment où le message a été transmis initialement. Au mieux, cela pourrait provoquer une analyse incorrecte de l'état d'une machine. Au pire, cela pourrait provoquer une fausse alarme qui pourrait déclencher une action corrective inutile ou masquer une vraie alarme qui aurait dû déclencher une action corrective.
8.5. Reliable Delivery (Livraison fiable)
Comme syslog est un protocole simplex, par défaut il ne fournit pas d'assurance de livraison. Un observateur malveillant peut simplement supprimer des messages en transit ou générer tellement de trafic que le destinataire est incapable d'accepter tous les messages. Bien qu'il soit possible de construire des transports syslog qui fournissent une assurance de livraison, de telles constructions sont en dehors du cadre de ce document. Plus d'informations sur les transports fiables pour syslog peuvent être trouvées dans [RFC3195].
Il est également possible que des messages soient supprimés ou détournés pendant qu'ils sont relayés à travers un relay. Par exemple, un relay pourrait être configuré ou compromis pour supprimer tous les messages de sévérités particulières ou d'originators particuliers.
8.6. Congestion Control (Contrôle de congestion)
Les messages syslog peuvent être envoyés en utilisant des protocoles qui ne fournissent pas de contrôle de congestion. Cela peut conduire à la perte de messages et à la congestion du réseau. Pour se protéger contre cela, les protocoles de transport utilisés DEVRAIENT fournir un contrôle de congestion. La fonctionnalité de contrôle de congestion dépend du protocole de transport.
8.7. Message Integrity (Intégrité des messages)
Cette spécification ne fournit pas de moyens natifs pour garantir que les messages ne sont pas modifiés, supprimés ou injectés par des parties intermédiaires. Il est RECOMMANDÉ que les communications syslog sensibles à la sécurité utilisent un transport qui fournit l'intégrité des messages. L'intégrité des messages peut être obtenue par divers moyens, y compris l'utilisation de signatures cryptographiques. Cependant, ces mécanismes ne sont pas décrits dans cette spécification et dépendent du protocole de transport.
8.8. Message Observation (Observation des messages)
Par elle-même, cette spécification ne fournit pas de confidentialité native pour les messages. En raison de la nature simplex de syslog, il est facile pour quelqu'un ayant un accès physique ou électronique à la transmission d'écouter les informations contenues dans les messages. Par conséquent, les messages syslog peuvent être observés par des acteurs malveillants. Il est RECOMMANDÉ que les communications syslog sensibles à la sécurité utilisent un transport qui fournit la confidentialité des messages.
8.9. Inappropriate Configuration (Configuration inappropriée)
Les messages syslog peuvent contenir des informations sensibles. Par exemple, les messages syslog pourraient contenir des informations sur la topologie du réseau, la configuration du système ou les identités d'utilisateurs. Ces informations peuvent être utiles à un attaquant. Les messages syslog NE DEVRAIENT PAS contenir d'informations sensibles (par exemple, des mots de passe). Cependant, il est impossible de définir une liste exhaustive de ce qui constitue des informations sensibles. Le caractère approprié de la sensibilité des informations transmises via syslog est une question de politique locale. Il est important que les administrateurs locaux comprennent que toute information dans le champ MSG n'est pas protégée par cette spécification.
Les opérateurs NE DEVRAIENT PAS utiliser syslog pour transmettre des informations sensibles à moins que le contenu n'ait été correctement anonymisé ou protégé par d'autres moyens. Cela pourrait être fait par un certain nombre de méthodes, y compris:
- Envoyer des messages syslog sur un canal confidentiel, tel que TLS
- Pré-filtrer les messages pour supprimer les informations sensibles
- Utiliser syslog uniquement dans un environnement réseau protégé
8.10. Forwarding Loop (Boucle de transfert)
Dans une chaîne de relays syslog, une erreur de configuration pourrait entraîner une boucle de transfert. Par exemple, le relay A pourrait être configuré pour transférer des messages au relay B, et le relay B pourrait être configuré pour transférer des messages au relay A. Une telle boucle peut provoquer l'épuisement des ressources ou d'autres problèmes. Les implémentations DEVRAIENT essayer de détecter de telles boucles et émettre une notification si une est détectée. Une façon de détecter les boucles est d'inclure un identifiant spécifique à l'originator dans le message qui peut être vérifié à chaque relay. Par exemple, le SD-ID origin peut être utilisé à cette fin.
8.11. Load Considerations (Considérations de charge)
Les implémenteurs et les opérateurs doivent tenir compte des caractéristiques de performance et des facteurs de charge liés à la génération, la transmission, le relais et la collecte de messages syslog. Parce que syslog est généralement utilisé comme moyen de transmettre des informations utilisées pour la surveillance opérationnelle, le débogage et l'analyse de sécurité, il est important que l'acte de transmettre les messages syslog ne crée pas lui-même de problèmes opérationnels ou de vulnérabilités de sécurité.
Par exemple, des volumes excessifs de messages syslog peuvent surcharger la capacité du réseau de transport. De même, un relay ou un collector pourrait être submergé s'il reçoit des messages à un débit plus rapide qu'il ne peut les traiter. Un tel épuisement des ressources peut entraîner des messages perdus, des messages retardés ou un déni de service. Les implémentations syslog DEVRAIENT avoir des contrôles appropriés pour limiter la charge qu'elles imposent au système et au réseau.
8.12. Denial of Service (Déni de service)
Les protocoles de transport syslog DEVRAIENT pouvoir détecter et gérer les attaques par déni de service. Un destinataire peut être inondé de messages, soit par une mauvaise configuration, soit comme une attaque. Il est RECOMMANDÉ que les destinataires syslog aient la capacité de limiter le débit auquel ils acceptent les messages. Il est également RECOMMANDÉ que les destinataires aient la capacité de filtrer les messages pour rejeter ceux provenant d'expéditeurs non autorisés ou avec un contenu suspect.