1.
syslogLinuxTag 2005Rainer Gerhardsrgerhards@hq.adiscon.com2005-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 rootfailed for lonvick on /dev/pts/8● In spitzen Klammern steht Facility und Severity,die üblicherweise zur Nachrichtenfilterungverwendet werden– PRI = Facility * 8 + Severity– Oben: Facility 4 (security system), Severity 2(cirtical)● Prinzipiell ist jedes an UDP Port 514 gerichtetePaket eine gültige syslog-Meldung...

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

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 infast allen Routern, Firewalls, Switches, ...implementiert● Implementierungen auch unter anderenBetriebssystemen

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 esoft “Traffic Bursts”● Bei hoher Last steigt Verlustrate drastisch an● Test belegen, dass teilweise schon der Sender-IP-Stack die Pakete verwirft● Wichtige Einzelmeldungen oder Gesamtbildkö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 zubeherrschen

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 aberparsen)

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 thewild”– 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ürImplementierungen● 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 vorFertigstellung– 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 Einfachheitbegründet● IETF versucht, diese soweit wie möglichbeizubehalten– Gerade Security-Anforderungen machen dies nichtimmer möglich– RFC 3195 zeigt, dass sich unmittelbarAkzeptanzprobleme ergeben können...– (Neue) Libraries werden dem hoffenlich abhelfen

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

16.
syslog Protokollschichten“Applications”, e. g. Signatures, International CharactersTransport MappingsMessage Format & Syslog Semantics

17.
RFCs/IDs as of 11/2003AppTransportProtocol31643195-inter-national-sign

18.
Bestehende Dokumente im neuenKonzept...AppTransportsyslog-transport-udp3195bis(transport)-inter-national-sign3195bis(metadata)-protocolDie Schichtenarchitektur erfordert 6 RFCs gegenüber sonst 4, aberjeder davon kürzer und kompatibel zu den anderen. Dank dieserKonsistens werden sie hoffenlich einfacher zu implementieren undwarten sein.

19.
Was passiert, wenn etwas neuhinzukommt?3164bis(STAN-DARD!)3195bis(transport)-inter-national-sign3195bis(metadata)-protocolNEW(SNMP?)● Alles bestehendewird weiterfunktionieren● Die neueFunktionalität wirdsofort auch fürbestehende 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 (wenigerals 1024 Zeichen)● Einige Anwendungen mit deutlich größerenLängenanforderungen (z.B. IHE mit momentanbis zu 32KB)● Fragmentierte Pakete für Troubleshootingproblematisch, dafür ist eine Länge kleiner als480 Zeichen optimal...

22.
Nachrichtenlänge - Kompromiss● Jeder Sender/Empfänger muss Nachrichten bis zueiner Länge von 480 Zeichen unterstützen. Wennmöglich, sollten keine längeren Nachrichtengesendet werden.● Es wird empfohlen, Nachrichten bis zu einerLänge von 2048 Zeichen zu unterstützen.● Längere Nachrichten sind erlaubt.● Künftig wird der Administrator wohl auf dieAnwendungs-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 mitRFC 3195/RAW Beispiel-Implementierung● liblogging – gezielt für RFC 3195 geschaffeneLibrary, 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 EuroBSDCon2002 vorgestellt● Arbeit kann leider durch momentaneWarteposition von syslog-sign nicht beendetwerden● Autor hat zu erkennen gegeben, dass er denDaemon später fertig stellen möchte

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

27.
Werden sich die neuen Standardsdurchsetzen?● Wie immer bei Standardisierung ist Ausdauergefragt ;-)● Optical Internet Forum (OIF) hat Interesse ansyslog-protocol bekundet● Seit März/April 2005 ist erkennbar steigendesInteresse an RFC 3195 festzustellen– Gesundheitswesen (IHE) wohl eine treibende Kraft– Es würde mich nicht wundern, wenn auch wenigstensein “major” Hersteller von Netz-Equipment bald RFC3195 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, sichererenLösungen mit höherer Funktionalität zu rechnen.

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