8. Security Considerations (Sicherheitsüberlegungen)
Syslog kann Informationen über das Sicherheitsniveau verschiedener Anwendungen auf einem System transportieren. Daher können die Syslog-Transportunternehmen in einigen Bereitstellungen selbst zum Ziel von Angriffen werden, möglicherweise bevor irgendwelche Sicherheitswarnungen auf Anwendungsebene an die Verantwortlichen übermittelt werden können. Aus diesem Grund empfiehlt dieses Dokument dringend, dass Syslog-Transporte TLS verwenden, wie in [RFC5425] spezifiziert. Dieser Transport erzwingt ein Minimum an Sicherheit und kann konfiguriert werden, um wesentlich mehr zu bieten.
Bösartiger Netzwerkverkehr (oder feindliche Anwendungen mit Zugriff auf den syslog-Transport auf lokalen Maschinen) kann den Syslog-Transportunternehmer täuschen, damit er glaubt, dass ein Angriff stattfindet. Ein Verteidigungssystem kann dann Maßnahmen ergreifen, um Maschinen oder Netzwerksegmente herunterzufahren, die tatsächlich nicht angegriffen werden.
Eine Lösung für dieses Problem besteht darin, dass Originators ihre Nachrichten digital signieren. Die Empfänger können dann verifizieren, dass die Nachricht von einer bekannten Quelle gesendet wurde und nicht verändert wurde. Allerdings behebt dies nicht das Problem einer kompromittierten Maschine, die durch ihren rechtmäßigen Eigentümer zertifiziert ist, das einen Angriff fälschlich meldet.
Die Reihenfolge der STRUCTURED-DATA-Elemente oder ihre SD-PARAMs ist nicht festgelegt. Obwohl STRUCTURED-DATA-Elemente leicht zu parsen sind, bedeutet diese Tatsache, dass es teurer ist, ein bestimmtes Element zu finden, wenn viele solcher Elemente vorhanden sind.
Aus diesem Grund sollten syslog-Anwendungen übermäßig große Mengen an STRUCTURED-DATA in einer einzelnen Nachricht vermeiden. Um das Problem weiter zu begrenzen, stellt die Spezifikation eine Obergrenze von 32 Zeichen für die Namen von strukturierten Datenelementen dar (die Länge von SD-ID und PARAM-NAME). Selbst mit diesem Limit kann jedoch ein böswilliger Sender Collector (oder andere syslog-Anwendungen) mit vielen STRUCTURED-DATA-Elementen oder ungültigen STRUCTURED-DATA überfluten. Empfänger SOLLTEN Mechanismen haben, um solche Angriffe zu erkennen und zu tolerieren. Dies kann beinhalten, fehlerhafte strukturierte Daten zu ignorieren, zu begrenzen, wie viele Elemente verarbeitet werden oder Nachrichten mit zu vielen Elementen zu verwerfen.
Zusätzlich können längere syslog-Nachrichten verwendet werden, um syslog-Infrastruktur zu überfluten. Ein Relay oder Collector SOLLTE geeignete Maßnahmen ergreifen, um zu verhindern, dass es überflutet wird.
Ein Originator sollte keine gefälschten Zeitstempel senden. Empfänger sollten jedoch nicht davon ausgehen, dass sie einen korrekten Zeitstempel erhalten haben. Der Empfänger sollte den TIMESTAMP als Repräsentation betrachten, wann der Originator glaubte, dass das Ereignis aufgetreten ist. Er sollte ihn nicht als genaue Zeit des Ereignisses selbst betrachten.
Syslog-Nachrichten sollten verwendet werden, um Ereignisse zu melden, aber sie sollten nicht als die einzige Kanal dienen, über den kritische Ereignisse gemeldet werden. Zum Beispiel sollte ein kritisches Ereignis wie ein unmittelbares System-Herunterfahren nicht ausschließlich über syslog gemeldet werden. Ein verantwortlicher Operator sollte nicht davon ausgehen, dass Nachrichten über syslog erfolgreich übertragen werden. Systeme, die kritische Ereignisse übermitteln, sollten mehrere Kanäle zur Übertragung solcher Informationen haben.
Eine Maschine kann Nachrichten im Namen anderer Maschinen senden. Zum Beispiel muss ein Router-Log SOLLTE den Router als HOSTNAME haben, aber es kann auch über einen Collector laufen. Empfänger sollten sich dessen bewusst sein, wenn sie Nachrichten verarbeiten, insbesondere wenn Nachrichten über unsichere Transportmechanismen kommen.
Nachrichten von einer bestimmten HOSTNAME können auch aus verschiedenen Netzwerkadressen kommen. Empfänger sollten sich dessen ebenfalls bewusst sein, wenn sie Nachrichten empfangen. Das ist nicht unbedingt ein Sicherheitsrisiko, sondern eine Realität der verschiedenen Netzwerkkonfigurationen.