8. Considérations de sécurité

Cette section traite des considérations de sécurité du protocole syslog. Implémenteurs et opérateurs doivent les avoir à l'esprit pour déployer syslog en toute sécurité.

8.1. Unicode

Cette spécification impose l'utilisation de l'encodage UTF-8 pour la STRUCTURED-DATA. UTF-8 peut encoder l'intégralité du jeu de caractères Unicode.

Préoccupations de sécurité :

• Problèmes d'affichage : certains caractères Unicode peuvent être visuellement proches d'autres, ce qui peut faciliter des attaques par usurpation. Par exemple, des caractères cyrilliques ressemblant à des caractères latins.

• Caractères de contrôle : Unicode comporte de nombreux caractères de contrôle et de mise en forme susceptibles d'affecter l'affichage ou l'analyse.

• Équivalence canonique : différentes séquences Unicode peuvent représenter le même caractère visuel, ce qui peut contourner certains filtres de sécurité.

Recommandations :

• Les applications affichant des messages syslog devraient implémenter une gestion et une désinfection appropriées de l'Unicode.
• Envisager une normalisation des chaînes Unicode vers une forme canonique.
• Tenir compte des problèmes de texte bidirectionnel.
• Valider et désinfecter les données utilisateur avant inclusion dans des messages syslog.

8.2. Caractères de contrôle

Les caractères de contrôle dans les messages syslog peuvent provoquer des problèmes d'affichage ou de sécurité.

Préoccupations :

• Les séquences de contrôle de terminal peuvent altérer l'affichage.
• Les octets nuls peuvent tronquer des chaînes dans certaines implémentations.
• Les retours chariot et sauts de ligne peuvent casser l'analyse des journaux.

Recommandations :

• Filtrer ou échapper les caractères de contrôle à l'affichage.
• Valider le contenu des messages avant traitement.
• Préférer les éléments de structured data plutôt que d'embarquer de l'information structurée dans le texte libre.

8.3. Troncature des messages

Si un message est tronqué pendant la transmission, des informations importantes peuvent être perdues.

Implications de sécurité :

• Des détails pertinents pour la sécurité peuvent être supprimés.
• Une troncature peut survenir aux relais ou aux limites de transport.
• Des attaquants pourraient exploiter la troncature pour masquer une activité malveillante.

Recommandations :

• Conserver l'information critique en début de message (dans les 480 premiers octets).
• Utiliser STRUCTURED-DATA pour les métadonnées importantes.
• Mettre en œuvre des protocoles de transport supportant des messages plus longs si nécessaire.
• Surveiller la présence de messages tronqués au niveau des collectors.

8.4. Rejeu

Les messages syslog peuvent être capturés et rejoués par des attaquants.

Scénarios d'attaque :

• Rejouer d'anciens messages pour masquer l'activité courante.
• Inonder les collectors de messages rejoués (DoS).
• Brouiller l'analyse forensique en injectant d'anciens événements.

Recommandations :

• Utiliser un transport authentifié et chiffré (TLS).
• Inclure des numéros de séquence (meta sequenceId).
• Inclure des horodatages précis.
• Mettre en place une vérification de l'origine des messages.
• Surveiller les messages dupliqués ou hors-séquence.

8.5. Livraison fiable

Cette spécification n'exige pas de livraison fiable. Des messages peuvent être perdus.

Implications de sécurité :

• Des événements de sécurité peuvent ne pas être enregistrés.
• La perte de messages peut masquer des attaques.
• Les exigences de conformité peuvent ne pas être satisfaites.

Recommandations :

• Utiliser des protocoles de transport fiables (TCP/TLS) pour les messages liés à la sécurité.
• Mettre en place des accusés de réception au niveau applicatif.
• Utiliser des numéros de séquence pour détecter les pertes.
• Concevoir la supervision de sécurité en tenant compte des pertes potentielles.
• Envisager des chemins de journalisation redondants pour les systèmes critiques.

8.6. Contrôle de congestion

Une congestion réseau ou une surcharge de traitement peut entraîner des pertes ou des retards de messages.

Préoccupations :

• Les rafales de messages durant des attaques peuvent être perdues.
• Des messages retardés peuvent arriver dans le désordre.
• L'épuisement des ressources peut affecter des systèmes critiques.

Recommandations :

• Mettre en place une limitation de débit côté émetteur.
• Utiliser des protocoles de transport offrant un contrôle de congestion.
• Surveiller la profondeur des files et les délais de messages.
• Prioriser les messages liés à la sécurité.
• Concevoir des systèmes capables d'absorber les rafales.

8.7. Intégrité des messages

Syslog ne fournit pas intrinsèquement de protection d'intégrité des messages.

Menaces :

• Les messages peuvent être modifiés en transit.
• Des attaquants peuvent altérer les messages au niveau des relais.
• Des erreurs réseau peuvent corrompre les messages.

Recommandations :

• Utiliser un transport TLS pour la protection d'intégrité.
• Mettre en place une signature de bout en bout si nécessaire.
• Vérifier le format et le contenu des messages aux collectors.
• Surveiller la présence de messages malformés ou suspects.

8.8. Observation des messages

Les messages syslog peuvent contenir des informations sensibles.

Préoccupations de confidentialité :

• Des informations personnelles peuvent être journalisées.
• Des détails système peuvent profiter à des attaquants.
• Des données sensibles métier peuvent être exposées.

Recommandations :

• Utiliser un transport chiffré (TLS).
• Désinfecter les messages pour retirer les informations sensibles.
• Mettre en place des contrôles d'accès aux collectors.
• Tenir compte des exigences réglementaires (RGPD, HIPAA, etc.).
• Éviter de journaliser mots de passe, clés ou autres secrets.

8.9. Configuration inadaptée

Des erreurs de configuration peuvent créer des vulnérabilités.

Problèmes courants :

• Envoi de messages aux mauvais collectors.
• Exposition des services syslog à des réseaux non fiables.
• Contrôles d'accès insuffisants.
• Filtrage de messages inadapté.

Recommandations :

• Valider les configurations.
• Utiliser des règles de pare-feu pour restreindre le trafic syslog.
• Auditer régulièrement l'infrastructure syslog.
• Tester les changements de configuration en environnement non productif.
• Documenter les standards de configuration.

8.10. Boucles de retransmission

Les boucles de relais peuvent provoquer un épuisement des ressources.

Préoccupations :

• Les messages circulent indéfiniment entre relais.
• Des ressources réseau et système sont consommées.
• Des messages légitimes peuvent être perdus.

Prévention :

• Mettre en place des limites de hop count.
• Détecter et rompre les boucles.
• Concevoir soigneusement la topologie de relais.
• Surveiller le comportement des relais.
• Implémenter une détection de boucle au niveau des relais.

8.11. Considérations de charge

Des volumes de messages élevés peuvent submerger les systèmes.

Problèmes :

• Saturation du receveur ou du relais.
• Pertes de messages sous charge.
• Dégradation des performances.

Recommandations :

• Planification de capacité pour les charges nominales et de pointe.
• Limitation de débit.
• Traitement de messages efficace.
• Supervision des performances.
• Mise à l'échelle de l'infrastructure si nécessaire.

8.12. Déni de service

L'infrastructure syslog est sensible aux attaques DoS.

Vecteurs d'attaque :

• Inondation par de gros volumes de messages.
• Envoi de messages malformés pour faire planter les receveurs.
• Saturation du stockage par une journalisation excessive.
• Ciblage des relais.

Atténuations :

• Limitation de débit à toutes les couches.
• Validation des entrées.
• Quotas de ressources.
• Infrastructure redondante.
• Protections au niveau réseau (pare-feux, IDS).
• Authentification et autorisation.