Log Management vs. SIEM: Daten sammeln und analysieren

Die Leitung ist verstopft! Das Internet ist langsam! – Viele Administratoren kennen solche Aussagen, und vermuten auch richtig das Problem: ein Nutzer oder ein Programm nutzen die Verbindung ins Internet derart extensiv, dass die Dienstqualität der meisten Verbindungen mit dem Internet leidet. Es könnte aber auch ein fehlerhaftes Programm sein, welches pausenlos Daten hochladen möchte. Doch wie findet man den Computer, von dem das Problem ausgeht? Wie bekommt man die harten Zahlen, um notwendige Optimierungen des Durchsatzes bzw. die Erhöhung des Budgets zu begründen?

Darf es ein „exotisches“ Problem für einen Netzwerkadministrator sein? Es ist nachmittags, blauer Himmel und in den Bergen bilden sich ein paar Gewitter. Plötzlich lassen sich über den neuen WLAN-Access Point, welcher letzte Woche installiert wurde, keine Clients mehr erreichen. Etwa zur gleichen Zeit höre ich ein Flugzeug, welches auf dem nahen Airport landen wird. Ca. 40 Minuten später wiederholt sich das Ganze. Hoppla, was ist denn da los? Hat das Flugzeug den Ausfall vom WLAN verursacht? Die Log Einträge des Access Points weisen auf einen Kanalwechsel durch Dynamic Frequency Selection (DFS) hin. DFS ist eine vorgeschriebene Funktion im Frequenzbereich zwischen 5.6 GHz – 5.8 GHz und der vorübergehende Verbindungsabbruch wurde tatsächlich vom Wetterradar des Flugzeugs ausgelöst. Ohne Log File wäre es nicht so einfach gewesen, den Zusammenhang zu beweisen.

Viele IT-Systeme protokollieren die internen Abläufe oder auftretenden Fehler. Meistens werden diese Log Daten intern gespeichert. Möchte man diese Informationen nutzen, muss man wissen, wo man suchen muss: bei Windows-Betriebssystemen im Event-Viewer, bei Linux-Betriebssystemen in verschiedenen Textdateien und bei verschiedenen Netzwerkgeräten zum Beispiel in der Weboberfläche. Um an die Daten zu kommen, muss man sich erst mit dem richtigen Passwort am Gerät anmelden. Und was ist, wenn das Gerät gerade ausgeschaltet ist? Unter Umständen gehen diese Daten in diesem Fall vielleicht sogar verloren?

Heute sind IT-Landschaften mit weit über 1000 Clients, Servern und Netzwerkgeräten kein Einzelfall mehr. Und manche dieser Geräte, wie zum Beispiel Firewalls, Proxies oder das Active Directory generieren zum Teil über 1000 Nachrichten in der Sekunde. Mit den herkömmlichen Methoden ist es fast unmöglich, Log Daten im täglichen Business zu nutzen – Zugriff und Suche sind einfach zu aufwendig. Und so schlummern wertvolle Informationen auf den verschiedenen Geräten im Netzwerk. Die Lösung? Mit Log Management lassen sich diese Daten zentral speichern und auswerten.

Die Technik

Für das Auswerten von Log Daten gibt es heute verschiedene Möglichkeiten[1]: kommerzielle Lösungen, Open-Source-Programme, aber es ist auch denkbar, für einen Anwendungsfall ein Skript oder Programm selbst zu schreiben. Allgemein folgt jede technische Lösung aber folgendem Schema: Log Daten werden gesammelt und übertragen, geparst und mit Metadaten angereichert, in einem Data-Store abgelegt, und dann gibt es verschiedene Möglichkeiten zur Auswertung wie zum Beispiel Dashboards:

Diese Schritte sollen jetzt im Einzelnen vorgestellt werden:

1. Daten sammeln und übertragen

Log Daten werden auf ganz unterschiedliche Weise von der Software bereitgestellt: es gibt verschiedene Logging- Frameworks wie zum Beispiel Log4x für Java, PHP etc. Es gibt verschiedene Protokolle zum Übertragen von Log Daten, wie zum Beispiel Syslog oder OPSEC-LEA. Manchmal werden die Daten auch einfach in Textdateien geschrieben. Für all diese Frameworks bzw. Protokolle gibt es Möglichkeiten, Log Daten an einen zentralen Log Server zu übertragen.

Es gibt ein paar Herausforderungen: Was passiert, wenn der Log Server ausfällt oder anderweitig nicht verfügbar ist? Sollen Log Daten eventuell über das WAN an einen zentralen Standort übertragen werden? Was passiert, wenn Log Daten schneller generiert werden, als die Übertragung und Weiterverarbeitung zu lassen? Bleibt die Anwendung, welche die Logs generiert, einfach stehen oder gehen Daten verloren? Können die Daten komprimiert und für die Übertragung verschlüsselt werden? – Aus diesen Gründen nutze ich in der Regel ein zweistufiges System, mit dem die Daten in einem Puffer zwischengespeichert werden und dadurch das Generieren der Logs von Übertragung und Weiterverarbeitung asynchron entkoppelt wird.

Beim Einsammeln der Logs sind in der Regel Metadaten bekannt, welche sich später wesentlich schwerer rekonstruieren lassen: das sind zum einen der Typ der Log Daten und zum anderen der Hostname oder die IP-Adresse des sendenden Systems. Weiterhin ist eine Zeitsynchronisation per NTP für alle beteiligten Systeme erforderlich, um später die Reihenfolge von Log Daten verschiedener Systeme bestimmen zu können. Für Compliance-Frameworks wie zum Beispiel ISO 27001 (oder NIST 800-171, …) ist diese Zeitsynchronisation zwingend vorgeschrieben.

Manche Systeme arbeiten mit strukturierten Informationen, wie zum Beispiel Windows Event Logs und der Linux-Kernel[2]Java-Programme kennen in der Regel die Klasse, von welcher das Log generiert wurde, Firewalls kennen Quell- und Ziel-IP-Adressen oder ein Proxy kennt Quell-IP-Adresse, die URL, den Status-Code und eventuell das Ergebnis einer Antivirus-Überprüfung. Oft werden diese strukturierten Informationen einfach hintereinander in eine Textzeile geschrieben. Wenn möglich, ist zu prüfen, ob diese Informationen auch gleich strukturiert geloggt werden können, zum Beispiel im JSON-Format.

Werden die Daten später mehrfach an unterschiedlichen Stellen gespeichert (zum Beispiel in einer Datenbank und zusätzlich in einem Backup-Archiv) empfiehlt es sich darauf zu achten, dass alle Logs mit einer UUID versehen sind, damit Logs später wieder zugeordnet werden können.

2. Parsen, Normalisieren und Anreichern mit Meta-Daten

Im zweiten Schritt, dem Parsing, geht es darum, Log Informationen, welche in eine Textzeile geschrieben wurden, wieder in Felder zu zerlegen. Meist geschieht dies mit regulären Ausdrücken. Ziel ist es, dass Informationen wie Zeitstempel, Quellsystem, Anwendung (zum Beispiel SSH,..), Nutzernamen und IP-Adressen, URLs oder Statuscodes entsprechenden Variablen zugeordnet werden. Genau diese Variablen sind später die verschiedenen „Dimensionen“, nach denen sich Logs filtern lassen, um die Nadel im Heuhaufen zu finden.

In Logs finden sich unter anderem Zahlen (z.B. 200, 407, 503)[3], IP-Protokoll Informationen (z.B. 6=TCP, 17=UDP), Portnummern oder EventIDs. Was bedeuten diese Zahlen? All diese Informationen lassen sich mit Übersetzungstabellen in eine Form umwandeln, sodass sie dem Anwender vor dem Dashboard nützliche Informationen liefern. Je nach Anwendungsfall ist es auch wichtig, die Logs so zu normalisieren, dass zum Beispiel Quell- und Ziel-IP-Adresse oder Benutzernamen typübergreifend immer in der gleichen Variable zu finden sind.

Weiterhin ist es möglich, Logs mit weiteren Metadaten anzureichern, wie zum Beispiel GeoIP-Informationen, reverse DNS, Kostenstellen für eine spätere Rechnungslegung…, Ebenso sollte der Abgleich mit Thread-Listen von  C&C-Server-Adressen eines Bot-Netzwerks, oder allgemeinen Black- und White-Listen, erfolgen und das Ergebnis dem Log zugeordnet werden.

Nicht zuletzt sollte im Schritt Datenanalyse geprüft werden, ob und wie Logs zu anonymisieren sind. Müssen IP-Adressen und Nutzer-Namen ersetzt werden oder können sie eventuell ganz entfernt werden?

Das Parsing und Anreichern von Logs mit Metadaten ist zeitkritisch. Sendet ein System zum Beispiel 200 Logs pro Sekunde, heißt das, dass mindestens 200 Logs pro Sekunde im Log Management System verarbeitet werden müssen. Aber zum Beispiel reverse DNS Anfragen für IP-Adressen in Australien benötigen Zeit, teilweise mehr als eine Sekunde! Insofern wird gutes Caching für Metadaten benötigt, ebenso muss meistens mit mehreren Threads gearbeitet werden.

3. Speichern und Archivieren

Werden 200 Logs pro Sekunde ausgewertet und gespeichert, kommen schnell 10 GB bis 20 GB Daten pro Tag zusammen. Wo und wie kann man das speichern? Wer darf auf die Daten zugreifen und für welchen Zeitraum sollen die Daten ausgewertet werden?

Eigentlich gibt es drei praktische Anwendungsfälle für die Auswertung:

• Echtzeitauswertungen
  Oft ist es nur wichtig, aktuelle Fehler oder die Auslastung eines Systems zu kennen. Nach wenigen Stunden oder Tagen haben die Daten ihren Nutzwert verloren. Allerdings ist es wichtig, in den Daten schnell und detailreich suchen zu können.
• Langzeitstatistik
  Wie hat sich die Auslastung der Datenverbindung ins Internet in den Letzten 2-5 Jahren entwickelt? Für diese Frage benötigt man vielleicht nur ein Datum pro Tag. Durch das Bilden von Summen für die jeweils wichtigen Details lässt sich das Datenvolumen reduzieren und diese Statistik lässt sich mit wenig Speicherplatz realisieren.
• Archivierung für spätere forensische Analyse
  Angriffe auf ein Unternehmen werden oft erst nach 200 Tagen entdeckt. Für die forensische Analyse reicht es oft aus, einen Teil der Daten später noch einmal zu importieren.

Aufgrund der dynamischen Struktur der geparsten Logs, nutze ich in der Log Analyse mit OpenSource-Werkzeugen JSON-Dokumente zum Speichern der Daten. Diese Dokumente werden in einer NoSQL-Datenbank für z.B. 30 Tage indiziert (online). Praktisch ist das z.B mit Elasticsearch möglich. Zusätzlich werden die Logs in komprimierten Textdateien im JSON-Format archiviert (offline).

Aus praktischen Überlegungen nutze ich eine Datei[4] pro Tag sowie für jede Log Quelle bzw. jeden Log Typ. Durch die verschiedenen Dateien ist es möglich, Dateien täglich zu löschen, vereinfacht Zugriffsberechtigungen  zu definieren, Daten unterschiedlichen Typs verschieden lange zu archivieren, etc.

4. Daten Auswerten: Dashboards, Reports und Benachrichtigungen

Sind die Daten gespeichert, können sie in Dashboards ausgewertet werden. Praktische Grafiken sind z.B.:

• Top 10 Quell- und Ziel-IP-Adressen
• Top 10 Downloads
• Der Verlauf der Log Menge bzw. der Datenmenge ober die Zeit
• Der Verlauf der Datenmenge über die Tageszeit
• Eine Karte, welche die geographische Verteilung der IP-Adressen zeigt.

Meist ist es in Dashboards möglich, auf Teilaspekte zu klicken und so in den Daten zu filtern. Oft ist auch eine Volltextsuche in Daten möglich, z.B. zum Finden aller Logs mit einem bestimmten Nutzernamen. Somit sind Dashboards ein mächtiges Werkzeug, um Log Daten relativ echtzeitnah zu analysieren.

Eine andere Möglichkeit der Auswertung ist das Generieren von PDF-Reports. Dies geschieht z.B. periodisch nachts oder wöchentlich. So ist es möglich, Rechnungen zu erstellen, monatliche Statistiken zu generieren oder aber das Erstellen und Löschen von Benutzeraccounts zu protokollieren.

Ebenso ist es möglich, beim Auftreten bestimmter Ereignisse oder beim Überschreiten bestimmter Schwellwerte einen Alarm zu generieren bzw. jemanden zu benachrichtigen:

• Ein Backup Fehler tritt auf
• Morgens 7:00 Uhr wurde noch nicht der erfolgreiche Abschluss aller Backup Jobs festgestellt
• Innerhalb von 10 Minuten meldet sich ein Nutzer öfter als 20 mal fehlerhaft an
• Innerhalb von 10 Minuten treten plötzlich Anmeldefehler auf mehr als 40 Clients auf

Auf spezielle SIEM-Auswertungen werde ich im 2. Teil von Log Management vs. SIEM eingehen.

Fazit

Mit der vorgestellten Technik ist es möglich, einen guten Überblick über das Verhalten der IT-Landschaft zu bekommen. Für mich persönlich ist Log Management eine Best-Effort-Technik: bei vielen tausend Logs pro Sekunde lässt es sich manchmal leider nicht vermeiden, dass wenige Log Daten verloren gehen bzw. vergessen wurde, ein System anzubinden. Trotzdem glaube ich, dass Log Management belastbare Indizien und Zahlen liefert, die den System- und Netzwerkadministrator bei der Entscheidungsfindung unterstützen.

Kurz habe ich das Thema Datenschutz und Anonymisierung angesprochen. Dies hängt allerdings vom Anwendungsfall und den verschiedenen Log Quellen ab und nicht so sehr von der Technik der Log-Auswertung. Deswegen denke ich, der Datenschutz sollte immer für den Anwendungsfall betrachtet werden.

[1] Es gibt mehrere technische Lösungen um Log Daten zu speichern und auszuwerten:  ein selbst programmiertes Programm/Script, SQL-Datenbanken, Logstash, Elasticsearch und Kibana, Hadoop oder Apache Spark, …

[2] neuere Linux-Versionen nutzen Journald

[3] HTTP Status Code: 200 = OK, 407 = Proxy Authentication Required, 503 = Service Unavailable

[4] Z.B. bei Textdateien. Gleiches ist in Elasticsearch oder Anderen Repositories mit einem Index pro Tag möglich.