© inhabitant, 123RF.com

Logserver, Logfile-Überwachung, IDS und Monitoring – Splunk ist von allem ein bisschen. Und mehr: Dank schneller Indizierung und intelligenter Suchfunktionen durchforstet es selbst umfangreiche Logfile-Sammlungen schnell, wenn nötig auch automatisch.

Wenn Systemprotokolle die Giga- oder gar Terabyte-Grenzen sprengen, läuft sich jeder Grep-Befehl die Hacken ab. Professionelle, unter Umständen auch kommerzielle Loganalyzer wie Splunk [1] müssen her. Die Idee ist einfach: Hinten will der Admin viele und vor allem umfangreiche Textdaten reinwerfen und vorne soll ein Webinterface schnelle und komfortable Suchfunktionen ermöglichen.

Big Data und Map-Reduce

Angesichts derart großer Datenmengen kommen schnell Suchmaschinen wie Google oder Schlagworte wie Big Data in den Sinn. Tatsächlich verwendet Splunk als Basis seiner Indizierung einen Map-Reduce-Algorithmus, den auch Google als Basis zur Bewältigung seiner riesigen Datenmengen verwendet (siehe Kasten “Map-Reduce”). Der Performancegewinn entsteht dabei vor allem durch die Indizes, die eine Volltextsuche deutlich effizienter gestalten.

Neben der Full Search erlaubt Splunk es aber auch, Felder separat aus den Protokollen zu extrahieren. Dies kann etwa die Quell-IP-Adresse eines Firewall-Logeintrags sein, ein Hostname oder auch die Temperatur der CPU. Die so extrahierten Felder lassen sich dann in Formeln, Vergleichen und Zusammenfassungen verwenden.

Splunks Datenmodell mit Indizes und Extraktionen erlaubt es, beliebige Textdaten zu importieren, ohne dass sich der Anwender vorher über das Format im Klaren sein muss. Ein Datenbankmodell mit einer festen Struktur ist auch nicht notwendig. Bedienen wird der Admin Splunk über ein eigenes Web-GUI, wobei er aber auch jederzeit an der Shell individuelle Suchanfragen absetzen kann.

Mehrköpfige Splunk-Architektur

Eine Splunk-Installation besteht aus mehreren Komponenten: dem Splunk-Server und der wiederum aus dem Indexer und dem Search Head. Der Indexer sammelt die eingehenden Daten und legt sie in der Splunk-Filestruktur ab. Zum Teil erledigt er auch das Extrahieren der Felder. Der Search Head führt die Suche auf den indizierten Daten aus. Alle Auswertungen, Alarme und Reports in Splunk sind Suchvorgänge.

Weil ein Search Head auch in mehreren Indexern suchen kann, ist das Verteilen auf mehrere Hosts und damit auch Redundanz möglich. Je nach Installation kann der Admin Daten auch erst bei der Suche extrahieren lassen.

Ein Forwarder kümmert sich darum, die Daten ins System laufen zu lassen. Er nimmt die Daten in verschiedenen Formen auf und

• stellt Dateien und Verzeichnisse zur Verfügung,
• streamt Logdaten per UDP oder TCP auf einen Socket und
• führt Skripte aus, um Daten zu erheben (zum Beispiel ein regelmäßiges »ps auxwww« für eine Prozessliste).

Vom Forwarder gibt es zwei Versionen: Der Universal Forwarder ist eine abgespeckte Version mit relativ geringem Ressourcenbedarf, der auf den Servern mitläuft, ohne den Betrieb zu stören. Diese Version leitet alle Logfeeds an den Indexer weiter. Filtermöglichkeiten gibt es in dieser Kombination erst auf dem Indexer. Der Universal Forwarder lässt sich als eigenes Paket herunterladen [2].

Heavy Forwarder und Deployment

Alternativ dazu gibt es den Heavy Forwarder, das ist eine Splunk-Vollversion, die sich per Lizenzkey auf die Aufgabe als Forwarder herunterstufen lässt und beispielsweise Filter zu setzen erlaubt, um etwa gleich nur bestimmte Events weiterzuleiten. Der Deployment-Server, ebenfalls eine eigene Splunk-Komponente, hilft dabei, Konfigurationen und Erweiterungen der angeschlossenen Forwarder zentral zu verwalten.

Damit nicht genug: Splunk ist auch noch erweiterbar. Dem allgemeinen Trend folgend heißen die Erweiterungen Apps beziehungsweise Technology Add-ons, wenn sie keine Komponenten im GUI enthalten. Ein solches Add-on besteht aus Vorgaben für bestimmte Datentypen, zum Beispiel die Logfiles der Firewalls IPtables oder IPfw.

Zusätzlich dürfen Admins vordefinierte Suchen hinterlegen, die im Kontext der eingebundenen Logs Sinn ergeben, zum Beispiel die Top-Firewall-Ziele der letzten 24 Stunden als Balkengrafik im Web-GUI. Eine Sammlung dieser Links ergibt ein so genanntes Dashboard, das dem Anwender auf einer Webseite innerhalb der Splunk-Oberfläche einen Überblick zu einem definierten Thema bieten soll.

Installation

Das Installieren erweist sich als denkbar einfach. Splunk steht auf der Webseite des Herstellers [1] zum Download bereit, außer für Linux in 32 und 64 Bit gibt es auch Pakete für Windows, Solaris, AIX, HPUX, Free BSD und OS X. Für Linux steht das Paket als RPM, Deb und Tarball bereit. Für eine Testinstallation reicht es, nach dem Auspacken in das Splunk-Verzeichnis zu wechseln und »bin/splunk start« aufzurufen – schon steht das Web-GUI zum Einloggen bereit. Paketmanager installieren die Software meist unter »/opt/splunk« . Im Test des Linux-Magazins funktionierte sogar ein Major-Release-Upgrade von Version 4 auf 5 ohne Probleme – selbst mit dem Tarball.

Für produktive Installationen sollte der Admin allerdings die Speicherorte der Logdaten auf dem Indexer (»$SPLUNKDIR/var/lib/splunk« ) so definieren, dass genug und angemessen schneller Festplattenplatz bereitsteht. Splunk erlaubt es einzustellen, wo es welche Daten speichert, und kann sogar eine Differenzierung nach Daten vornehmen (Firewalldaten in Verzeichnis 1, Logindaten in Verzeichnis 2, …). Dazu bedarf es jedoch eigener Indizes und pro Index eines definierten Speicherorts.

Auf der gedachten Zeitlinie unterscheidet Splunk die Vorfälle oder Einträge dann noch nach »hot« , »warm« und »cold« . Heiße und warme Ereignisse befinden sich in einem gemeinsamen Verzeichnis (pro Index), sie sind die jüngsten Daten und sollten auf den schnellsten Platten gelagert sein.

Für den Universal Forwarder gelten die gleichen Bedingungen. Er lässt sich unter [2] herunterladen und genau so installieren wie die Vollversion. Nach der Installation existiert ein Benutzer »admin« mit dem Password »changeme« . Nach der obligatorischen Passwortänderung sieht der Administrator die Ansicht aus Abbildung 1. Ein normaler Anwender sieht dagegen einen etwas anderen Startbildschirm, der Admin kann konfigurieren, wer was angezeigt bekommt.

Abbildung 1: Der Splunk-Startbildschirm des Web-GUI nach dem ersten Einloggen.

Doch bevor er mit dem Auswerten beginnt, muss der Administrator erst einmal die gewünschten Datenquellen anbinden. Als Erstes bieten sich die Syslogdateien des lokalen Systems an. Also folgt der Administrator dem Link »Add data« aus Abbildung 1, wählt »consume any file or directory on this server« und die entsprechende Logdatei aus, die Splunk importieren soll. Es ist auch möglich, ein ganzes Verzeichnis (etwa »/var/log« ) einzubinden, dann importiert Splunk alle darin befindlichen Dateien – es kommt dabei mit komprimierten Daten zurecht und versteht auch Logfile-Rotation.

Wer einzelne Protokolldateien oder -daten ausklammern will, definiert einen Filter in der Datei »inputs.conf« in einem der Splunk-Konfigurationsverzeichnisse (siehe Kasten “Splunks Konfigurationshierarchie”) entweder per Web-GUI oder direkt mit einem Editor.

[sektion]Schlüssel=WertNoch_ein_Schlüssel=Noch_ein_Wert

Suchen

Laufen die ersten Daten in die Splunk-Installation, ist es an der Zeit, die Search-App zu öffnen. Abbildung 2 zeigt deren Übersichtsseite. Auf ihr sieht der Admin schnell, wie viele Logdaten welcher Quelle und welches Typs gerade in Splunk Einzug halten.

Abbildung 2: Die Übersichtsseite der Splunk-Suche, neudeutsch Search-App genannt.

Splunk bietet eine recht mächtige Sprache, um in den gesammelten Daten zu suchen, die Kommandoreferenz findet sich unter [3]. Alternativ zum Web-GUI kann der Admin aber auch auf der Kommandozeile mit »/opt/splunk/bin/splunk search Suchstring« suchen. Dazu meldet er sich auf der Kommandozeile beim Splunk-Server an. Im Erfolgsfall speichert dieser im Homedirectory ein Cookie, das die Anmeldung eine Zeit lang gültig hält.

Die einfachste Form der Suche ist eine Volltextsuche, in der der Administrator einfach den Suchstring in das Feld eingibt. Dies entspricht in Unix einem »grep -i« über alle gespeicherten Daten. Rechts neben dem Suchfeld darf er den Zeitraum einschränken, über den die Suche laufen soll. Neben vordefinierten Werten stehen ihm hier auch die Möglichkeit einer genauen Zeitangabe sowie Echtzeitanzeigen (analog zum »tail -f Alle_Logdaten | grep -i Suchstring« ) zur Verfügung.

Schönheit im Detail

Bis hierhin leistet Splunk – abgesehen von einer netten Weboberfläche und der Benutzerverwaltung – nichts, was nicht auch ein Syslog-Server und ein paar Skripte könnten, abgesehen vom deutlich höheren Tempo, mit dem die Ergebnisse kommen. Spannend wird es jedoch, wenn der Admin etwas tiefer in die Suchsprache einsteigt. Will er zum Beispiel nur die Webserver-Logs durchsuchen, dann erreicht er das mit einer Suche wie »sourcetype=”access_combined” Suchstring« . Zum Einschränken auf die Webserver-Logs gibt es noch weitere Möglichkeiten.

Um Auswertungen zu fahren, die logisch komplexer sind, zum Beispiel: “Welcher Pfad auf dem Webserver wurde wie oft abgerufen?”, benötigt Splunk so genannte Field Extractions. Diese sind bei den Apps oder Technology Add-ons enthalten, der Administrator kann sie aber auch selbst entweder sehr bequem über das Web-GUI oder direkt in einer Regular Expression in der Konfigurationsdatei »transforms.conf« angeben. Hier gibt er Teilen bestimmter Logdaten Namen, die er anschließend in seinen Suchanfragen verwenden kann.

Bei der in jeder Splunk-Installation integrierten Auswertung von Webserver-Logs gibt es etwa die Felder »clientip« , »method« oder »uri« . Kennt der Admin die Felder nicht, hilft eine Suche wie »sourcetype=”access_combined”|table *« , die alle Felder in einer Tabelle darstellt. Die Suche nach den Top-URLs sieht folgendermaßen aus: »sourcetype=”access_combined”|top uri« , ein exemplarisches Ergebnis zeigt Abbildung 3.

Abbildung 3: Einfache Frage, übersichtliche Antwort: “Zeige mir die Top-URLs an, die von den meisten Leuten hier im LAN angesurft wurden.” Aufbereitet von Splunk, extrahiert aus den Firewall- oder Proxylogs.

Per Klick im Ergebnis lässt sich aus dem Suchergebnis auch eine Grafik erzeugen. Mit dem Button »Create« rechts über dem Ergebnis kann der Administrator aus der Suche gleich ein Dashboard, einen Alarm, einen Report oder eine regelmäßig ablaufende Suche erzeugen. Bei Alarmen wendet Splunk die Suche in Echtzeit oder in regelmäßigen Intervallen auf die einlaufenden Daten an. Überschreiten die Ergebnisse definierte Grenzwerte (wie etwa beim Klassiker von fünf fehlgeschlagenen Login-Versuchen am gleichen Rechner in wenigen Minuten), dann löst Splunk einen Alarm aus, den es als E-Mail versendet, der ein Skript auslöst oder der einfach nur lokal im GUI des Administrators erscheint.

Ein »Save« -Button in der Weboberfläche speichert die aktuell konfigurierte Suche. Gerade nach längerem Tüfteln, das erfolgreich etwas Bestimmtes aus dem Datenberg herausfiltern half, kann die Option, eine identische Suche später noch einmal durchzuführen, sehr wertvoll sein

Einen Angreifer erkennen

Eine kompliziertere Suche könnte etwa so aussehen:

sourcetype=*|rename SRC as clientip|transaction fields=clientip
maxspan=50s|search sourcetype="syslog"sourcetype="access_combined"

Übersetzt in für Menschen leichter verständliche Sätze also etwa:

• Nimm alle Logeinträge.
• Wenn es Einträge gibt, die ein Feld »SRC« haben, dann benenne das Feld für diese Suche in »clientip« um. Das Feld kommt aus der Unix-App für Splunk, die Linux-IPtables-Syslog-Einträge parst, und beinhaltet die Quell-IP eines Firewall-Logeintrags.
• Sortiere die Logeinträge entsprechend »clientip« . In Clientip stehen jetzt sowohl IPtables- als auch die Webserver-Einträge, und zwar für Ereignisse innerhalb von 50 Sekunden.
• Suche alle Einträge, die sowohl Syslog- (IPtables) als auch Webserver-Zugriffe haben.

Im zusammenhängenden Satz: Suche alle Logs und fasse jene zusammen, bei denen innerhalb von 50 Sekunden von der gleichen Quell-IP sowohl Firewall-Logeinträge vorliegen als auch Webserver-Zugriffe erfolgt sind. Dies würde zum Beispiel einen Portscan finden, der an die Firewall hämmert und bei offenen Webservern ausprobiert, was er mit dem HTTP-Server so anfangen kann, etwa durch »nmap –script=http*« .

Die Suchsprache enthält jede Menge Routinen zur Textmanipulation, statistischen Auswertung und Formatierung der Ergebnisse. Auch die abzusuchenden Zeiträume können Admins direkt im Suchkommando mitgeben. Splunk hat auf der Webseite sogar eine eigene Dokumentationsseite “Splunk für SQL-Anwender” [4], die zeigt, wie in der Splunk-Sprache oder -Logik Joins zwischen verschiedenen Logquellen funktionieren.

Besser einsortieren

Die Stecknadel im Heuhaufen, bei deren Suche Splunk den Administrator unterstützen will, findet häufig erst, wer technisch ganz unterschiedliche, aber semantisch ähnliche Logdaten miteinander vergleicht. Zum Beispiel sind “alle fehlgeschlagenen Logins” in einem heterogenen Netz nicht nur Unix-PAM- und SSH-Einträge, sondern auch Windows-Eventlogs und vielleicht sogar Samba-Logdaten. Diese kann man zwar mit verschiedenen Splunk-Erweiterungen auch parsen und die Software erkennt auch die Felder für den Benutzernamen und die Quelle, von der aus der Versuch unternommen wurde. Aber weil die Entwickler der Erweiterungen sich meist nicht an Standards halten, heißt es dort mal »username« , mal »user_name« und ein anderes Mal einfach »user« .

Damit der Admin trotzdem mit einfachen Suchen alle fehlgeschlagenen Logins sieht, gibt es das Tagging. Hier kann er einmal für jeden Typ (Windows, Samba, Unix) definieren, was ein »failed_login« ausmacht. Danach kann er nach »tag=”failed_login”« suchen und alle Events in einem einheitlichen Ergebnis begutachten.

Lizenzen und Preise

Splunk ist proprietär, eine Open-Source-Variante fehlt. Neben der kostenpflichtigen Enterprise-Lizenz gibt es aber auch eine kostenlose und zeitlich unbeschränkte Lizenz. Sie gilt aber nur für 500 MByte pro Tag und gestattet keine automatische Alarmierung, die zentrale Verwaltung anderer Splunk-Systeme und eine verteilte Installation sind auch nicht möglich. Die gute Online-Community hilft jedoch meist auch bei komplizierteren Fragen schnell weiter.

Wer mehr braucht, muss zur Enterprise-Version greifen. Die lizenziert sich ausschließlich nach einlaufendem Datenvolumen: Mehr GByte an Logs bedeuten hier automatisch mehr Euro auf der Rechnung. Nach einer Registrierung kann der Admin eine Vollversion der Software herunterladen, die aber auf 500 MByte pro Tag und 60 Tage Laufzeit limitiert ist. Forwarder kosten keine Lizenzen.

Zusammenfassung

Splunk bietet eine durchaus mächtige Plattform, um aus riesigen Logfiles mit einem Werkzeug die wirklich relevanten Informationen herauszuziehen. Der Einsatz beschränkt sich nicht nur auf sicherheitsrelevante Logs, Admins können vielmehr beliebige Textdaten einfüttern und auswerten.

Das hat zwar seinen Preis, denn Splunk ist keinesfalls Software der Sorte “Installieren und fertig”, es verlangt von seinen Anwendern einen klaren Plan, Anpassungen und Erweiterungen sind fast immer notwendig. Aber genau das erledigt Splunk im Verhältnis zu anderen Produkten sehr einfach, ohne dabei an Mächtigkeit einzubüßen. Viele Admins lassen selbst gestrickte Skripte laufen, um auf bestimmte Logeinträge automatisch zu reagieren. Jetzt verleitet Splunk dazu, diese aufzugeben – zu einem stolzen Preis, der sich nach den verarbeiteten Datenmengen richtet.

Die kleinste Lizenz fängt laut Webseite bei 5000 US-Dollar an, Euro-Preise gibt es individuell auf Anfrage bei den Splunk-Partnern. Die Preise pro GByte werden allerdings deutlich günstiger, je größer das gekaufte Volumen ist.