Aller au contenu principal

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.