This presentation covers the state of the syslog protocol and its standardization as of 2005. It was created for and held at Linuxtag in Germany (and as such is in German).

1. syslog
LinuxTag 2005
Rainer Gerhards
rgerhards@hq.adiscon.com
2005-06-06

2. Was ist syslog?
● Gebräuchliches Protokoll für
– Trouble-shooting
– Security-Überwachung
– Auditing
● Einfaches, textbasierendes Protokoll
● Benutzt UDP (nicht verlustsicher)
● Nicht standardisiert
● Vergleichsweise unsicher

3. Wie sieht eine Nachricht aus?
● <34>Oct 11 22:14:15 mymachine su: 'su root'
failed for lonvick on /dev/pts/8
● In spitzen Klammern steht Facility und Severity,
die üblicherweise zur Nachrichtenfilterung
verwendet werden
– PRI = Facility * 8 + Severity
– Oben: Facility 4 (security system), Severity 2
(cirtical)
● Prinzipiell ist jedes an UDP Port 514 gerichtete
Paket eine gültige syslog-Meldung...

4. Historie - Der Anfang
● Ursprünglich von Eric Allmann im Rahmen des
sendmail-Projektes entwickelt (frühe 80er Jahre)
● Als Protokollier- und Debug-Möglichkeit für
sendmail gedacht
● Nachrichten-Filterung nur anhand von
– Facility
– Severity
● Weitergehende Verwendung weder geplant noch
designed

5. Weitere Nutzung...
● Syslog erweist sich schnell als hilfreiche Methode
● Auch andere Applikationen verwenden syslog
● Nachrichten vom Admin leicht interpretierbar
● Extrem einfach implementierbar, daher auch in
fast allen Routern, Firewalls, Switches, ...
implementiert
● Implementierungen auch unter anderen
Betriebssystemen

6. Weiterentwicklungen
● TCP als Transportmechanismus
– Löst Problem der Verlässlichkeit
– Weite Akzeptanz, z.B. in syslog-ng
● Verschlüsselung
– Hersteller/Projektspezifische Ansätze
● meist auf Basis SSL
● Im Regelfall nicht interoperabel
– stunnel
● stunnel Treiber werden in Verbindung mit TCP-
Implementierung genutzt
● Interoperabel (auch cross-Plattform)

7. Problem: Nachrichtenverlust
● UDP Pakete dürfen vom Netz verworfen werden
● Gerade bei Attacken und Fehlfunktionen gibt es
oft “Traffic Bursts”
● Bei hoher Last steigt Verlustrate drastisch an
● Test belegen, dass teilweise schon der Sender-IP-
Stack die Pakete verwirft
● Wichtige Einzelmeldungen oder Gesamtbild
können verloren gehen

8. Problem: Sicherheit (Security)
● “Good Guys” Internet Protokoll der 80er Jahre...
● Volles Programm...
– spoofing
– replay-Attacken
– Klartext-Übertragung
– (D)DoS via Packet Loss (wie zuvor gesagt)
– Log Modifikationen
● Im Rahmen von UDP-Syslog schwer zu
beherrschen

9. Problem: Formatvielfalt
● Syslog ist ein “Haufen von Bytes”
● meist zeilenweise organisiert
● Jeder verwendet ein eigenes Format, je nach
– Projekt/Hersteller
– Software
– Version
● Keine “semantischen Objekte” (lassen sich aber
parsen)

10. Standardisierung
● Überhaupt keine Standardisierung bis ca. 2000
● In 2000 Gründung einer IETF-Arbeitsgruppe.
– Grundsätzliches Ziel: Sicherheits von syslog erhöhen
– Erstes Teilziel: Dokumentation von syslog “in the
wild”
– Wichtig: Sicherheitsprobleme aufzeigen
● RFC 3164 (August 2001)
– “informational”, kein Standard
– RFC 3164 gibt leider nicht die “volle Warheit”
wieder, z.B. Konflikte mit BSD-Implementierung

11. Standardisierung II
● RFC 3195 (November 2001)
– “echter Standard”
– basiert auf BEEP (RFC 3080 & 3081)
● Authentifizierung
● Verschlüsselung
● Verbindungsorientiert (TCP)
– BEEP ist momentan Hinderungsgrund für
Implementierungen
● Komplexes Channel-Multiplexing Protocol
● wenige/keine geeignete Libraries verfügbar

12. Standardisierung III
● syslog-sign
– Krypto-Signaturen in den Log-Meldungen
– Begonnen parallel zu RFC 3195
– “wartet” momentan auf syslog-protocol
● syslog-protocol
– Künftiger Basis-RFC für syslog Nachrichtenformat
– Begonnen in 2003, (hoffentlich) kurz vor
Fertigstellung
– Unabhängig vom verwendeten Transport

13. Denkansatz der neueren IETF-
Bestrebungen
● Keine CONTENT-Standardisierung
● “keep it simple”
● Aufteilung in Schichten
● Strukturierung des Nachrichteninhalts

14. “keep it simple”
● Der Erfolg von syslog liegt in seiner Einfachheit
begründet
● IETF versucht, diese soweit wie möglich
beizubehalten
– Gerade Security-Anforderungen machen dies nicht
immer möglich
– RFC 3195 zeigt, dass sich unmittelbar
Akzeptanzprobleme ergeben können...
– (Neue) Libraries werden dem hoffenlich abhelfen

15. Aufteilung in Schichten
● Alle erfolgreichen Protokolle basieren auf einem
Schichtenmodell
● Syslog kannte keine Schichten
– in der Urform
– in den ersten IETF-Anstrengungen
● Schichtenmodell ist wesentlicher Kernpunkt der
aktuellen Bestrebungen

16. syslog Protokollschichten
“Applications”, e. g. Signatures, International Characters
Transport Mappings
Message Format & Syslog Semantics

17. RFCs/IDs as of 11/2003
App
Transport
Protocol
3164
3195
-inter-
national
-sign

18. Bestehende Dokumente im neuen
Konzept...
App
Transport
syslog-
transport-
udp
3195bis
(transport)
-inter-
national
-sign
3195bis
(metadata)
-protocol
Die Schichtenarchitektur erfordert 6 RFCs gegenüber sonst 4, aber
jeder davon kürzer und kompatibel zu den anderen. Dank dieser
Konsistens werden sie hoffenlich einfacher zu implementieren und
warten sein.

19. Was passiert, wenn etwas neu
hinzukommt?
3164bis
(STAN-
DARD!)
3195bis
(transport)
-inter-
national
-sign
3195bis
(metadata)
-protocol
NEW
(SNMP?)
● Alles bestehende
wird weiter
funktionieren
● Die neue
Funktionalität wird
sofort auch für
bestehende syslog
“Teile” verfügbar

20. Strukturierung des Nachrichteninhalts
● Keine CONTENT-Standardisierung
● Aber Bereitstellung von “Containern”
– “STRUCTURED-DATA”
– z.B.: [timeQuality tzKnown="0" isSynced="0"]
– Leicht zu parsen
– Definition einiger Basis-Datenelemente (z.B. IP-
Adresse, Zeitgenauigkeit, ...)
– Leicht erweiterbar
● Voraussetzung für künftige Content-
Standardisierung geschaffen

21. Nachrichtenlänge
● Sehr kontroverses Thema
● syslog-Meldungen sind traditionell kurz (weniger
als 1024 Zeichen)
● Einige Anwendungen mit deutlich größeren
Längenanforderungen (z.B. IHE mit momentan
bis zu 32KB)
● Fragmentierte Pakete für Troubleshooting
problematisch, dafür ist eine Länge kleiner als
480 Zeichen optimal...

22. Nachrichtenlänge - Kompromiss
● Jeder Sender/Empfänger muss Nachrichten bis zu
einer Länge von 480 Zeichen unterstützen. Wenn
möglich, sollten keine längeren Nachrichten
gesendet werden.
● Es wird empfohlen, Nachrichten bis zu einer
Länge von 2048 Zeichen zu unterstützen.
● Längere Nachrichten sind erlaubt.
● Künftig wird der Administrator wohl auf die
Anwendungs-Anforderungen achten müssen.

23. Neue Projekte/Implementierungen
● RFC 3195
● syslog-sign
● syslog-protocol

24. RFC 3195
● SDSC syslogd (2003)
– Einzige (weitgehend) vollständige Implementierung
– Basiert auf RoadRunner Library
● RoadRunner – generelle BEEP-Library, aber mit
RFC 3195/RAW Beispiel-Implementierung
● liblogging – gezielt für RFC 3195 geschaffene
Library, unterstützt weitgehend alle features
● rsyslog soll künftig RFC 3195 unterstützen
● einige Windows-Produkte auf Basis liblogging

25. Syslog-sign
● Prototyp von Albert Mietus auf EuroBSDCon
2002 vorgestellt
● Arbeit kann leider durch momentane
Warteposition von syslog-sign nicht beendet
werden
● Autor hat zu erkennen gegeben, dass er den
Daemon später fertig stellen möchte

26. Syslog-protocol
● Modifikation von Metalog an der Universität von
Nizza, Frankreich als Lehrprojekt – Projekt im
April 2005 begonnen
● Integration geplant in
– liblogging
– rsyslog
– Aber: weitere Stabilität des ID wird abgewartet

27. Werden sich die neuen Standards
durchsetzen?
● Wie immer bei Standardisierung ist Ausdauer
gefragt ;-)
● Optical Internet Forum (OIF) hat Interesse an
syslog-protocol bekundet
● Seit März/April 2005 ist erkennbar steigendes
Interesse an RFC 3195 festzustellen
– Gesundheitswesen (IHE) wohl eine treibende Kraft
– Es würde mich nicht wundern, wenn auch wenigstens
ein “major” Hersteller von Netz-Equipment bald RFC
3195 unterstützen würde

28. Zusammenfassung
● Syslog wird universell genutzt
● Hat dennoch erhebliche Sicherheitsmängel
● Neue IETF-Standards wollen das Problem lösen.
● Mittel- bis Langfristig ist mit neuen, sichereren
Lösungen mit höherer Funktionalität zu rechnen.

29. Fragen?
● rgerhards@hq.adiscon.com