Effiziente Logfile-Analyse mit Syslog

Angriffe und Bedrohungen mit Syslog schneller entdecken

22.11.2007 | Autor / Redakteur: Eric Cole / Peter Schmitz

Syslog hilft Admins bei der schnellen Erkennung von Bedrohungen im Netzwerk.

Netzwerkgeräte melden von selbst, wenn sie unter Angriff stehen. Doch nur mit Syslog ist es möglich, diese Warnungen in den enormen Datenmengen rechtzeitig zu finden. Das mächtige Tool chafft nicht nur auf Unix-Systemen mehr Übersichtlichkeit, sondern dank Freeware-Clients auch in der Windows-Welt.

Ein zentrales Security-Prinzip lautet, dass Prävention zwar ideal wäre, zumindest Detektion aber unerlässlich ist. Und je früher sie erfolgt, desto besser. Angriffe sind wie ein Brand – wenn man schnell einschreitet, fällt das Löschen leicht, und der Schaden ist nicht groß.

Logfiles sind die Augen und Ohren eines Netzwerks. Sie melden, wenn ein Feuer ausbricht. Egal, ob es um Firewall-Regeln, eine IDS-Konfiguration oder das Öffnen von Server-Ports geht: Logs bieten die Informationen, die man für diese kritischen Entscheidungen braucht – wenn man sie sich überhaupt anschaut.

Ein Mittel gegen die Datenflut

Es ist praktisch unmöglich, die Unmengen an Protokolldaten durchzusehen, die Server und andere Netzwerkgeräte produzieren. All diese Ereignisse müssen daher in ein Format überführt werden, in dem sie analysiert und korreliert werden können. Syslog existiert nativ für die meisten Nicht-Windows-Systeme wie Unix, Unix-Daemons, -Router, -Firewalls, -Switches und -Webserver. Für Windows gibt es kostenlose und kommerzielle Tools wie etwa Kiwi Syslog Daemon von Kiwi Enterprises, die auch unter dem Microsoft-Betriebssystem die Syslog-Nutzung erlauben.

Die Einrichtung von Syslog kostet nicht viel Zeit und bietet die folgenden Vorteile:

  • Einblick in die Netzwerkaktivität.
  • Zentraler Speicher für Host-Logs; will man sie analysieren oder ein Backup durchführen, muss man also nur an einem Ort nachsehen.
  • Korrelation über viele Systeme hinweg. Sonst betrachtet man üblicherweise z.B. Server-Logs getrennt von Router-Logs. Mit Syslog wertet man sie alle gemeinsam aus und versteht besser, was im Netzwerk passiert.
  • Validierung für andere Geräte. Ein Syslog-Server kann prüfen, ob andere Geräte einwandfrei funktionieren. Soll etwa eine Firewall einen bestimmten Traffic-Typ blockieren, der aber in einem Syslog-Eintrag auftaucht, dann stimmt irgendetwas mit dem Gerät oder seiner Konfiguration nicht.
  • Erkennung von Angriffen, da potenziell gefährliche Ereignisse schnell auffallen.

Unmittelbar nützliche Informationen

Syslog geht das Problem der unübersichtlichen Datenmengen an, indem es Protokolldaten in Kategorien einteilt, die sich einfacher verwalten und analysieren lassen. Die beiden wichtigsten dieser Kategorien sind Log-Quelle und Gefahrenstufe, die bei Syslog „Facility“ (zeigt, welcher Daemon oder welche Quelle die Nachricht erzeugte) und „Severity“ (Einschätzung der Bedeutung) heißen.

Es ist unbedingt notwendig, dass Syslog richtig konfiguriert ist. Jede „Facility“ kann an eine andere Stelle weitergeleitet werden. Großunternehmen können mehrere Syslog-Server für verschiedene Facilities (oder Gruppen davon) einsetzen. Für kleinere Firmen reicht aber auch ein einzelner Syslog-Server, der verschiedene Facilities in unterschiedlichen Verzeichnissen protokolliert.

„Kern“ und andere zentrale Dienste sollten öfter als weniger wichtige Dienste geprüft werden. Doch müssen in jedem Fall die Nachrichten von allen Facilities gespeichert werden. Mit diesen Daten lässt sich vielleicht später ein Problem erklären oder der ursprüngliche Ausgangspunkt eines Angriffs identifizieren. Ein Beispiel: Ein Administrator findet ein Rootkit im System. Da es sich um ein Rootkit auf Kernel-Ebene handelt, prüft er akribisch die Kern- und System-Facilities. Aber erst, als er die Mail-Facility checkt, merkt er, dass Datenpakete ungewöhnlicher Größe eingehen. Syslog liefert die Daten, aber die finale Analyse muss der Mensch bewerkstelligen.

Manche Versionen von Syslog bieten Alarm-Features, andere können durch einfaches Skripting mit Alarm-Funktionen ausgestattet werden.

Mit zunehmender Menge von Protokolldaten wird das Nachvollziehen eines Angriffs, auch mit Syslog, immer schwieriger. Dann muss Syslog mit SIM/SEM-Tools ergänzt werden. Diese Tools erledigen die erste Korrelation und Analyse, um die Ereignisse einzugrenzen und dem Administrator bei der Analyse zu helfen.

Das Severity-Level gibt an, wie wichtig die Meldung ist. Der Severity-Level kann für jedes Gerät einzeln festgelegt werden, je nachdem, wie schlimm sich ein erfolgreicher Angriff auswirken würde und wie schnell jemand eingreifen müsste. Viele Administratoren versäumen es, die Severity-Levels zu definieren, was verhängnisvoll sein kann. Wenn z.B. der Pager alle paar Minuten Warnungen der Alarmstufe Rot anzeigt, dann wird ihn der diensthabende Administrator nach ein paar Stunden einfach ignorieren. Hat er dagegen noch nie eine solche Warnung zuvor gesehen, dann wird er dem wohl sofort mit höchster Priorität nachgehen.

Wenn die Severity-Levels definiert sind, arbeitet Syslog ungefähr wie ein Host-basierendes Intrusion Detection System (HIDS). Für Syslog oder ein HIDS/IPS-Produkt mit Syslog-Server gelten die folgenden Beobachtungen:

  • Einzelner Sensor. Man kann sich jedes Gerät als HIDS-Sensor vorstellen. Der zentrale Syslog-Server fasst dann einfach die Daten von den verschiedenen Hosts zusammen.
  • Nachteile von Netzwerk-IDS. Ein Netzwerk-IDS (NIDS) sieht nicht, was der Host sieht. Fragmentierung oder andere TCP-basierende Angriffe könnten das NIDS glauben machen, dies sei normaler Traffic, während der Host dies anders verarbeitet. Ein zentraler Syslog-Server sieht, was der Host wirklich verarbeitet. Dies wird immer wichtiger, da Traffic zunehmend verschlüsselt zirkuliert und ein Host seine Informationen nach der Entschlüsselung protokolliert.
  • Validierung für HIDS. HIDS wird immer akkurater, und es ist eine ganz natürliche Entwicklung, dass solche Software künftig Angriffe nicht nur entdecken, sondern auch gleich verhindern soll. Doch sind falsch-positive HIPS-Diagnosen nicht akzeptabel, und daher müssen Attacken vor einer potenziellen Blockade validiert werden. Syslog kann dies nicht nur für einen Host, sondern für das ganze Netzwerk übernehmen.
  • Überwachung von Firewall-Regeln. Prinzipiell sollte man bei Firewalls möglichst wenige Privilegien zulassen. Da ein Syslog-Server Informationen über individuelle Dienste protokollieren kann, lässt sich damit auf den Port zurück schließen. Damit können dann die Firewall-Regeln mit den Hosts korreliert werden, und man kann prüfen, ob dieser Port oder Dienst wirklich Zugriff über das Internet braucht.

Mehr...

Lesen Sie in unserem kostenlosen Whitepaper weiter, wenn Sie ein paar Best-Practice-Tricks kennenlernen wollen, wie Administratoren Syslog möglichst effizient einsetzen können und wenn Sie mehr über Syslog „Next Generation“ erfahren wollen. Der komplette Artikel zur Syslog-Analyse kostenlos für Sie zum Download.

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2009244)