Your SlideShare is downloading. ×
0
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Status of syslog as of 2005
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Status of syslog as of 2005

137

Published on

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

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
137
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×