Log Messages werden von vielen System und von vielen Applikationen auf besagten Systemen geschrieben. Damit diese alle zentral zu Management- und Analysezwecken gesammelt werden können, ist es notwendig, die Logs über das Netz zu versenden.

Dabei ist es von grosser Wichtigkeit, dass die Messages wie auch alle involvierten Komponenten so wenig wie möglich exponiert werden damit die Vertraulichkeit, die Integrität und die Abrufbarkeit der Daten gewahrt werden kann.

Probleme

Log Messages werden im Normalfall über ein syslog-Protokoll ausgetauscht. Standardmässig nutzt syslog dabei UDP-Pakete im Fire and Forget Modus um die Daten von Client zu einem oder mehreren Servern zu schicken. UDP-Pakete können aber einfach gespooft werden, die Lieferung ist nicht garantiert und die Information wird im Klartext übermittelt.

Lösungen

Seit Jahren bieten syslog Daemons die Möglichkeit, TCP als Transport-Protokoll zu nutzen. TCP hat viele Vorzüge gegenüber UDP: Es ist weniger anfällig für Spoofing, die Lieferung ist garantiert. Aber die Information wird immer noch im Klartext übertragen.

Um das Klartext-Problem zu lösen, bieten manche syslog-Daemons die Möglichkeit, die Daten zu mittels TLS zu verschlüsseln: Dazu werden einfach Zertifikate eingesetzt und verschlüsselte Übertragungen zwischen den Daemons, die beide TCP/TLS unterstützen, beginnen.

Einfach.

Zu einfach!

Erfahrungswerte

Die obige Lösung benötigt von allen syslog-Daemons Folgendes:

• TCP-Support
• TCP/TLS-Support
• Generischer CA-Zertifikatssuport (nicht proprietär oder selbst signiert)

Diese Anforderungen erfüllen syslog-Daemons wie rsyslog, syslog-ng, Snare und andere. The requirements can be satisfied by syslog daemons like rsyslog, syslog-ng, Snare and others. Aber wie steht es um einen syslog-Daemon in einem Switch? Unterstützt der TLS?

Wenn wir TLS nicht nutzen können, dann ist es vernünftig, mindestens TCP zu nutzen. Eine grosse Anzahl Geräte bieten die Möglichkeit, syslog-Daten mittels TCP-Paketen zu versenden.

Die Erfahrung zeigt, dass auch wenn ein syslog-Daemon TCP-Support bietet, dass das Polling Feature im Server nicht immer da ist. Das heisst: Wenn der Server offline geht oder – aus welchen Gründen auch immer – nicht erreichbar ist, hört der Client auf, Messages zu senden. Dies kann unter Umständen nur mit einem Neustart gefixt werden.

Dieses Verhalten ist schwierig zu überwachen und eine Korrektur des Ausfalls benötigt Zeit. Wenn du 100 solcher Clients hast, dann muss jeder einzelne Client neu gestartet werden.

Praktische Lösung

Nach einer Vielzahl Implementationen haben wir ein Design entwickelt, das Sicherheit und Management des Systems optimal ausbalanciert:

• Wir bevorzugen syslog gegenüber UDP in allen Netzwerkgeräten.
• Wir versuchen den physischen Pfad zwischen UDP Client und syslog-Proxy so kurz wie möglich zu halten.
• Wir implementieren zusätzliche Mitigationen, die den Pfad so sicher wie möglich halten (dedizierte Netzwerke/Switches/etc.)
• Aus Redundanz-Gründen bevorzugen wir zwei syslog-Servers anstelle eines Clusters.
• Um über unsichere Pfade zu kommunizieren nutzen wir zwei rsyslogd mit TCP/TLS.
• rsyslog kann konfiguriert werden um lokales Spooling abzuwickeln um Forwarding-Probleme zu beheben.
• Jegliche Kommunikation wird an einer zentralen Log-Sammelstelle beendet. Dort wird jede Message gefiltert und an ihre Endstation weitergeleitet (lokaler Speicher, indexing engine, Reporting, SIEM, etc.)

Die folgende Grafik zeigt dieses Setup auf:

Aber: Viele syslog-Daemons nutzen ebenfalls das Best-Effort-Prinzip, daher ist die Generation von Messages nicht garantiert.

Zusammenfassung

syslog ist ein gutes Protokoll, aber jegliche Implementation unterscheidet sich von den andern: Andere Features werden unterstützt und das kann zu unerwartetem Verhalten führen.

Um solche Überraschungen zu vermeiden, nutze das KISS Prinzip – mindestens für Netzwerk-Geräte. Die fortgeschrittenen Features sollten nur mit gut bekannten und weit verbreiteten Daemons genutzt werden.

Über den Autor

Rocco Gagliardi ist seit den 1980er Jahren im Bereich der Informationstechnologie tätig. In den 1990er Jahren hat er sich ganz der Informationssicherheit verschrieben. Die Schwerpunkte seiner Arbeit liegen im Bereich Security Frameworks, Routing, Firewalling und Log Management.