Syslog Monitoring

Was dem Windows Administrator sein "Eventlog" ist dem Unix oder Router-Admin eben Syslog. Syslog ist ein Protokoll, welches einem Syslog-Client erlaubt, per UDP und neuerdings auch per TCP und optional SSL und Anmeldung entsprechende Meldungen an einen Dienst zu senden, welcher diese Meldungen im einfachsten Fall in eine Textdatei aufzeichnet.

Achtung
Syslog ist in den meisten Fällen der ungesicherte Versand von kurzen Text-Meldungen per UDP. Die meisten Meldungen sind einfach abzuhören und es gibt auch keine Sicherung, dass die Meldung angekommen ist. Wenn der Syslog-Server nicht online oder die Verbindung unterbrochen ist, dann gehen die Meldungen unwiederbringlich verloren. Es gibt kein Queuing oder eine Sicherung.

Windows konnte lange Zeit gar nichts mit SYSLOG anfangen, da Windows mit dem Eventlog durchaus gut bedient ist. Um aber "Systemübergreifend" zu administrieren, ist es natürlich sinnvoll, die unterschiedlichen Systeme zu verbinden. So gibt es Zusatzprogramme, damit die Windows Eventlogs in SYSLOG-Meldungen überführt werden.

Syslog Basics

Ich beschränke mich auf der MSXFAQ auf die "einfache" Form des Syslog über UDP ohne SSL, Absicherungen o.ä. Die meisten "einfachen Router" und Gateways nutzen einfach diesen Weg und auch als Windows Administrator sollten Sie das Protokoll zumindest können.

Syslog-Meldungen sind faktisch einfach Text-Strings, die in UDP-Paketen an vordefinierte Ziele auf Port 514 gesendet werden. Über UDP sollten die Pakete klein sein, und Verluste dürfen nicht kritisch sein, da keine Flusskontrolle vorhanden ist. Es gibt auf dem Sender daher auch keine Queue und wenn der Empfänger "offline" ist, dann gehen die Meldungen verloren. Es gibt auch keine Authentifizierung, Verschlüsselung, Sicherstellung der Reihenfolge oder Schutz gegen Veränderungen . Auch "Fälschungen" sind einfach möglich, wenn der Angreifer den Syslog-Server erreichen kann. All diese Kritikpunkte sind in der RFC5426 ebenfalls aufgeführt.

Entsprechend einfach ist auch der Paketaufbau. Er besteht aus einem UDP-Paket und der Nutzlast als einfacher String. Hier habe ich mit WireShark mal solche Meldungen von zwei Systemen mitgeschnitten:

Beide Systeme senden UDP-Pakete aber nur eines davon nutzt die ersten 5 Byte zur Übermittlung standardisierter Daten.

  • 192.168.100.107 - Audiocodes Mediant
    Hier beginnt das UDP-Paket mit einem besonderen String "<xxx>", in dem weitergehende Informationen codiert sind, die ein SYSLOG-Server auswerten kann. WireShark wertet die "<133>" z.B. als "Local0:Notice" aus.
  • 192.168.99.14 Grandstream GXV3140-Telefon
    Diese Telefon sendet einfach nur einen String. Das ist durchaus legitim, wenn der Syslog-Service einfach nur zum Protokollieren gedacht ist. für Debug-Funktionen ist das sicher i.O. aber schöner wäre es schon, wenn das Gerät eine Einordnung und Gewichtung der Meldungen vornehmen würde.

Facility, Severity und Zeit

Beim Design von Syslog hat man etwas mehr im Hinterkopf gehabt als einfach nur einen Textstring per UDP an einem Server zuzuwerfen, der diesen denn irgendwie protokolliert. Der Server "sieht" vom Absender neben der IP-Adresse und der Message auch noch zwei weitere Klassifizierungen, die am Anfang des Texts mit "<" und ">" eingerahmt stehen müssen. Diese Prefix gibt eine Facility und eine Severity vor.

  • Facility
    Die Facility ist ein Wert zwischen 0 und 23
    • 0 kernel messages
    • 1 user-level messages
    • 2 mail system
    • 3 system daemons
    • 4 security/authorization messages
    • 5 messages generated internally by syslogd
    • 6 line printer subsystem
    • 7 network news subsystem
    • 8 UUCP subsystem
    • 9 clock daemon
    • 10 security/authorization messages
    • 11 FTP daemon
    • 12 NTP subsystem
    • 13 log audit
    • 14 log alert
    • 15 clock daemon
    • 16-23  local10 - local17
      Allgemeine Meldungen sollten diesen Bereich nutzen.
  • Severity = Schweregrad
    Dieser kann einen Wert von (0..7 annehmen)
    • 0 Emergency
    • 1 Alert
    • 2 Critical
    • 3 Error
    • 4 Warning
    • 5 Notice
    • 6 Informational
    • 7 Debug

Eine Nummer wird daraus, indem man die Facility mit 8 multipliziert (und damit die 5 Bits um 3 Stellen nach rechts schiebt und dann die Severity addiert. Der alte BSD Syslog Standard (RFC3164) schreibt dann vor, dass ein Zeitstempel und dann die Message gesendet wird.

Windows Eventlog zu SYSLOG

Auf der Seite NTSyslog habe ich am Beispiel einer Freeware gezeigt, wie Sie Meldungen aus dem lokalen Eventlog per SYSLOG an einen beliebigen SYSLOG-Server versenden können. Natürlich gibt es noch weitere Programme und Tools.

Der Versand von Meldungen per Syslog ist aber in anderen Umgebungen sehr viel häufiger. Ein paar Beispiele

  • Router und Switches
    Fast jeder Router oder Switch kann Vorgänge per SYSLOG versenden, z.B.: wenn sich ein Benutzer auf der Console anmeldet, wenn sich der Status eines Link verändert etc.
  • VPN-Knoten, Firewalls
    VPN-Knoten können über SYSLOG jeden Anmeldevorgang protokollieren während Firewalls z.B. Einbruchsversuche weitergeben können.
  • VoIP Gateways
    Am Beispiel eines Audiocodes Mediant 1000 können Sie auch gut erkennen, dass das zentrale Einsammeln von Systemmeldungen z.B. für die Erfassung von Verbindungsdaten sehr effektiv sein kann.
  • Drucker
    Auch scheinbar "dumme" Geräte haben heute einen direkte Netzwerkanschluss und können Statusmeldungen (z.B. Toner fast leer, Fach offen) etc. melden
  • UNIX-Systeme
    Fast jeder Prozess auf einem Unix-System kann Meldungen per SYSLOG versenden. Viele kleinere Systeme senden die Meldungen auf den SyslogD auf "localhost", um die Logs dann einfach lokal zu behalten.
  • Telefonanlagen
    Hier könnte der klassische "Verbindungsnachweis" gemeldet werden.

Zum Testen eines Syslog Servers und dessen Reaktionen können folgende beiden Testprogramme gute Dienste tun.

In die Gegenrichtung geht es natürlich auch

Syslog-Meldung per .NET versenden

Wenn Sie nun selbst mit dem .NET Framework Software entwickeln, dann schreiben Sie natürlich primär Fehler in das Eventlog und überlassen es anderen Programmen, um diese entsprechend weiter zu melden. Um zu zeigen, die einfach es aber ist, aus .NET einfach eine Meldung an einen SYSLOG-Server zu senden, habe ich hier einen Codeschnipsel aus Der Webseite von Glen Scales extrahiert (http://gsexdev.blogspot.com/2005/06/syslogging-message-tracking-logs-on.html).

void sendsyslog(string mtMessagetxt,string iaIpaddress, int spPriority){

   udpClient ucUdpclient = new udpClient(iaIpaddress, 514);
   byte[] rawMsg;
   string strParams = System.String.Format("<{0}>{1}",spPriority, mtMessagetxt);
   rawMsg = System.Text.Encoding.ASCII.GetBytes(string.Concat(strParams));
   ucUdpclient.Send(rawMsg, rawMsg.Length);
   ucUdpclient.Close();
   ucUdpclient=null;
}

So langsam kann man sich wirklich an .NET gewöhnen, da das Framework viele Aktionen doch sehr einfach macht.

Syslog per PowerShell senden

Wenn sie sich den .NET-Code anschauen, dann ist es nur ein kurzer Schritt um das ganze in PowerShell umzusetzen

[string]$sysloghost = "1.2.3.4"
[string]$syslogmesage = "Meldung an Syslog"
 
$udpclient = New-Object system.net.sockets.udpclient($sysloghost,514)
$rawmessage = [System.Text.Encoding.ASCII]::GetBytes($syslogmesage)
$udpclient.send($rawmessage, $rawmessage.length)
$udpclient.close()
$udpclient = $null

Es ist schon erstaunlich, wie leistungsfähig in PowerShell mal eben schnell ein Syslog-Sender geschrieben werden. Noch faszinierender ist, dass man sogar einen einfachen Syslog-Server in PowerShell schreiben kann

Syslog Server

Auf der Empfängerseite muss natürlich ein SYSLOG-Server die Daten annehmen. Auch hier gibt es eine ganze Auswahl von Produkten, die teils "Freeware" teils kommerziell sind und auf Windows oder Unix laufen. Die Frage dabei ist natürlich, wie sie mit den eingehenden Meldungen umgehen. Der reine Empfang und die Ablage in einer einfachen Textdatei ist nicht mehr als ein Pflichtprogramm. Interessant wird das ganze natürlich, wenn ein zentraler Server die Daten annimmt und speichert. Neben der besseren Speicherung erlaubt eine zentrale Anlage auch eine Korrelation der Vorgänge und das Erkennen von Zusammenhängen. Aber auch bezüglich der Sicherheit hat so eine zentrale Ablage Vorteile, da ein Angreifer vielleicht das einzelne System kompromittieren kann aber entsprechend weitergegebene Meldungen nicht wieder "zurückgezogen" werden können.

Vielleicht haben Sie schon eine entsprechende Management Software, die SYSLOG Meldungen annimmt und entsprechend aufbereitet. Ansonsten müssen Sie sich einen Syslog Server besorgen. Auch auch diese gibt es im Internet häufig kostenfrei oder als beschränkte Version. Das sollte Sie natürlich nicht davon abhalten, bei Bedarf eine Profiversion zu kaufen. Insbesondere wenn Sie ein echtes "Management" damit verbinden wollen. Dazu zählen z.B. Regeln um auf Events zu reagieren oder Events z.B. "als Erledigt" zu kennzeichnen.

Natürlich gibt es eine ganze Menge anderer Produkte. Letztlich bleibt es eine Frage der Anforderungen, welches Produkt dann zum Einsatz kommen soll.

Syslog mit Operation Manager

Auch wenn man auf den ersten Blick nicht erkennt, dass Operation Manager auch Syslog verkraftet (Ein Netstat zeigt nicht an, dass etwas auf Port 514/UDP lauscht) so kann man auch OM beibringen, Syslog-Meldungen anzunehmen und darauf zu reagieren. Das geht über den Bereich "Authoring", in dem einfach eine entsprechende Regel angelegt wird. Sie sollten nur wissen, dass der OM Server nicht selbst die Meldungen annimmt, sondern ein Agent auf einem Server

Es kommt noch einige weitere Fenster, mit denen Sie Filterregeln und Zielsätze (z.B.: die Agenten, die SYSLOG dann annehmen und weiter geben) einstellen können, auf die ich hier nicht weiter eingehe. Die folgenden Links und andere Seiten helfen hier weiter.

Syslog Server Kiwi Syslog

Achtung
Für Windows 2012 muss es Version 9.3.3 sein.
http://www.kiwisyslog.com/free-vs-paid-edition.aspx
Achtung. der Download der "Free-Edition" ist ziemlich versteckt. Die "Vollversion", die ohne Lizenz einige Zeit als "Eval" läuft stellt danach den Betrieb ein.
http://www.kiwisyslog.com/free-edition.aspx.
Der in der Mail gesendete Bestätigungslink verweist aber wieder auf die EvalVersion

Ein relativ einfach einzusetzender SYSLOG-Daemon ist der Syslog Server von Kiwi an. Sie erhalten ihn unter http://www.kiwisyslog.com. Laden Sie besser die Version herunter, die als "Dienst" laufen. Sie funktioniert zwar erst ab Windows NT und nicht auf Windows 95 und älter, aber dafür läuft sie auch, wenn niemand angemeldet ist. Die Konsole selbst stellt sich einfach und übersichtlich dar. Danke umfangreicher Optionen können Sie auch "Skins" nutzen und die Farben anpassen.

Viel wichtiger sind aber die Funktionen dahinter. Auf jeden eingehenden Event können Filter und Aktionen ausgelöst werden. Die Basisevents bewirken, dass alle Meldungen auf dem Bildschirm angezeigt und in eine Datei protokolliert werden. Zusätzlich sind aber auch SMTP-Mail, SNMP Traps, Datenbankablagen, Ausführen von Skripten, ICQ und vieles mehr möglich. Spielen Sie einfach etwas mit den Optionen.

Per Default werden die eingehenden Logs all in C:\Program Files (x86)\Syslogd\Logs\SyslogCatchall.txt geloggt. Ich würde über die Einstellungen hier einen anderen Pfad vorschlagen und auch eine "LogRotation" einschalten, die z.B. alle Stunde eine neue Logdatei startet und alte Dateien löscht. (Logrotation ist aber ein Features der Kaufversion).

Das Verzeichnis für die LOG-Dateien können Sie per NTFS-Kompression recht "klein" halten.

Weitere Links