Auf Grund der ursprünglich recht simplen Architektur von Syslog treten dessen Schwachstellen recht schnell zu Tage. Eine ist zum Beispiel die Übertragungsweise der Nachrichten. Da ein Syslog-Gerät seine Meldungen verbindungslos über UDP schickt, gibt es keine Möglichkeit für einen Syslog-Server, den fehlerfreien Empfang aller gesendeten Nachrichten sicherzustellen. Denn da ein Kollektor nicht weiß, ob und wann von wem ein UDP-Paket an ihn geschickt wird und er keine Möglichkeit hat, mit dem Sender zu kommunizieren, ist die Übertragung von Syslog-Meldungen über UDP in der Praxis schlicht Glückssache. Überlastete Netzwerksegmente oder WAN-Verbindungen können hier schnell zum Verlust von Syslog-Informationen führen. Das selbe gilt, wenn ein Syslog-Server ausfällt oder vorübergehend nicht erreichbar ist. An diesen Server über UDP gesendete Nachrichten sind ebenfalls für immer verloren.

Ein weiteres Problem aus heutiger Sicht ist die Übertragung der Nutzdaten im Klartext. Sendet beispielsweise ein E-Mail-Server Informationen über fehlgeschlagene Anmeldeversuche eines Benutzers inklusive dessen Login und verwendetem Passwort per Syslog durch das Netz, kann ein Angreifer diese Daten mit einfachsten Mitteln mitlesen. Hatte der Benutzer bei der Eingabe des Passworts nur einen Buchstabendreher, kann der Angreifer daraus sofort dessen richtiges Passwort ableiten. Damit einher geht die fehlende Authentifizierung eines sendenden Geräts bei einem Syslog-Server. So können Angreifer leicht selber Syslog-Pakete generieren und im Netzwerk absetzen – beispielsweise in Form einer Replay- oder Flooding-Attacke.

Weitere Probleme treten in der Praxis durch verschiedene Verwendungen des Priority-Felds auf. Auch unterdrücken einige Syslog-Implementierungen bei der Weiterleitung von Nachrichten deren ursprüngliche Quelle, so dass der Syslog-Server am Ende nicht mehr weiß, von welchem System die Nachricht ursprünglich stammt. Andere Syslog-Server setzen als Zeitstempel lediglich den aktuellen Monat, Tag und die Uhrzeit, so dass spätestens nach einem Jahr Meldungen nicht mehr eindeutig zuzuordnen sind. Und schließlich nimmt gerade in größeren Umgebungen die Zahl an Syslog-Nachrichten schnell überhand. Hier wäre es also auf Relay- oder Server-Seite wünschenswert, nur bestimmte Nachrichten herauszufiltern, weiterzuleiten oder zu speichern.

Syslog – Next Generation

Einigen dieser Defizite nehmen sich verschiedene Weiterentwicklungen von Syslog an. Zu den Open-Source-Vertretern zählen beispielsweise Syslog-ng, modular Syslog oder rSyslog. Heute am verbreitetsten ist wohl Syslog-ng, dessen Entwicklung 1998 begann. Syslog-ng ist heute in vielen Linux-Distributionen wie Debian, Fedora, Gentoo oder Suse enthalten. In Suse-Linux ist Syslog-ng seit der Version 9.3 der standardmäßige Syslog-Server.

Um sicherzustellen, dass Syslog-Nachrichten nicht mehr auf Grund von Engpässen im Netzwerk verloren gehen, nutzt Syslog-ng statt UDP das verbindungsorientierte TCP als Transportprotokoll. Weiterhin verwendet Syslog-ng einen Zeitstempel, der das komplette Datum einschließlich der Uhrzeit inklusive Millisekunden und Zeitzone unterstützt. Weiterhin protokolliert die nächste Generation von Syslog alle bei einer Übertragung verwendeten Syslog-Relays in den Nachrichten, so dass am Ende der genaue Weg einer Meldung nachvollziehbar ist.

Dass Syslog-ng auf vielen verschiedenen Plattformen verfügbar ist, hat dabei ebenso zu dessen Verbreitung beigetragen wie die umfangreichen Filtermechanismen, die in den Syslog-Client und -Server Einzug gehalten haben. Über einfache bis hin zu hoch komplexen Regeln kann ein Syslog-ng-Server eingehende Nachrichten beispielsweise nach Herkunft, Schweregrad, Muster im Hostfeld sowie auf Basis von regulären Ausdrücken selektieren und so entscheiden, ob eine Nachricht wichtig genug ist, um weitergeleitet oder gespeichert zu werden.