Die Nutzeraktivitäten in der eigenen Firma in Form von Logs sind unglaublich wertvolle Daten. Systemausfälle und Leistungszustände liefern zusätzlich reichhaltige Informationen über die Qualität eines Netzwerks oder eines Produktes. Das Sammeln all solcher Aktionen, sowohl von Menschen als auch von Maschinen, ist jedoch in den meisten Fällen eine sehr komplexe Aufgabe.
ELK ist ein Technologiestack, der Elasticsearch, Logstash und Kibana kombiniert, um einen umfassenden Ansatz zur Konsolidierung, Verwaltung und Analyse von Protokollen aus Ihrer gesamten Firma zu bieten, indem er Echtzeiteinblicke in Log-Daten und Flows liefert, damit automatisierte und kontinuierliche Analysen durchführt werden können.
Events und Log-Daten zentral sammeln, durchsuchen, automatisiert analysieren, auswerten und Alarme auslösen, sobald Security-Probleme erkannt werden.
Das Herzstück – Elasticsearch
Als Hauptkomponente des ELK-Stacks dient Elasticsearch. Es ist die Datenbank, der Speicherort sämtlicher Daten, welche in separaten Log-Indexen (Indices) liegen kann. Hier werden das Cluster zum Leben erweckt und auch alle Suchen, automatisiert oder manuell, durchgeführt.
Da Elasticsearch sehr umfangreich ist, wird hierzu ein eigener Post veröffentlicht: Elasticsearch – Die High Performance Search Engine.
Die Log-Aufbereitung durch Logstash
Sollen Systeme in das neue Log-Management-System integriert werden, welche nicht durch die offiziellen Data-Shippers wie Filebeat, Networkbeat, Auditbeat, Winlogbeat abgedeckt werden, so kommt Logstash zum Zuge.
- Ein Fleet-Server wäre natürlich auch eine gute Möglichkeit, Perimeter-Firewalls oder andere Log-Quellen in ELK zu integrieren. Bereits vorhandene Integrationen finden Sie unter diesem Link: Fleet-Agents.
Mit Logstash ist es möglich, anhand von selbst erstellten Pipelines und sogenannten GROK-Patterns die eigenen Log-Files (z. B. ein selbst erstelltes Python-Skript) in Searchable Fields zu mappen und zu indexieren (speichern in Elastic). Als Beispiel können so mit GROK wie bei Regex alle Usernamen oder IP-Adressen aus einem speziellen Logfile selektiert werden und anhand von Key-Value-Matching für Elasticsearch in einem JSON vorselektiert werden. Die fertig gemappte Log-Message wird am Ende der Pipeline in das Elasticsearch-Cluster importiert.
Um das Thema Logstash vertieft zu behandeln, wird zeitnah ein eigener Post dazu veröffentlicht: Logstash – Die Log-Pipeline.
Die Benutzeroberfläche Kibana
Unten sehen Sie einige Screenshots von Kibana im Einsatz. Kibana wurde früher als eigenständiges Produkt entwickelt, heute ist es die grafische Hauptoberfläche, also das Web-UI von Elasticsearch und würde ohne Elasticsearch auch nicht mehr eigenständig funktionieren. Am Ende dieses Blog-Eintrags finden Sie Hersteller-Demos, wie die Datenvisualisierung mit Kibana und Ihren Daten aussehen könnte.
Um Daten in Elasticsearch zu indexieren, gibt es unzählige Wege:
- Beats Data Shippers
- Filebeat – Alles, was in Form von Log-Files daherkommt (Apache, Nginx, Linux-Messages, Audit.log, usw.)
- Auditbeat – Security-relevante Messages, Login-Versuche, z. B. auf Unix-Systemen
- Winlogbeat – Sämtliche Windows Eventlog Messages und diverse Erweiterungen, z. B. PowerShell-Eingaben uvm.
- Networkbeat – Netzwerkaktivitäten, Latenzen oder Netzwerkprobleme
- Logstash
- Syslog – Input, der Netzwerkport ist frei konfigurierbar
- Kafka – Input und Output, der Netzwerkport ist frei konfigurierbar
- RabbitMQ – Input und Output, der Netzwerkport ist frei konfigurierbar
- ⇒ Komplette Liste der Logstash-Inputs
- Fleet-Server
- Sämtliche Integrationen unter folgendem Link: Fleet-Integrationen
Elasticsearch ist eine as-is-Datenbank. Das heisst, dass alle Mappings von Daten und Fields vor dem finalen Indexieren erfolgen müssen. Bei Standardprodukten, welche weltweit bekannt sind, z. B. PaloAlto-Firewalls, Cisco-Produkte, Webserver, Windows-Systeme, Linux-System-Logs, braucht es in den meisten Fällen keine zusätzliche Aufbereitung mit GROK, da bei solchen Technologien bereits automatisch alle Felder korrekt zugewiesen werden.
Sollte dies einmal nicht der Fall sein, kann dies aber straightforward mit Logstash nachgeholt werden, z. B. wenn es sich um eine Eigenentwicklung handelt.
- Mehr über: Wie eine Logstash-Pipeline funktioniert
Daten oder Logs werden im Menu «Discover» analysiert.
Hier kann entweder händisch gesucht werden, per Ausschliessen von Eventkategorien oder durch explizites Einschliessen wie die Suche nach dem Tag «Access Denied» oder «403» und noch vielem mehr. Es kann auch die KQL (Kibana Query Language) gebraucht werden oder für Mutige Apache-Lucene.
Weiter kann der Zeitraum eingeschränkt werden oder auch bei einem spezifischen Datum innerhalb eines Zeitraums auf die Millisekunde genau gesucht werden. Auch hier können zusätzliche Filter wie z. B. nur Logs von der Firewall hinzugefügt werden.
Unter Dashboards finden sich bereits über 40 Default-Dashboards, welche mit Elasticsearch und dessen Beats mitkommen. Diese können angepasst, kopiert und unter einem neuen Namen gespeichert werden.
Natürlich können auch komplett eigene Dashboards from-scratch erstellt werden, wie das Beispiel dieses Reverse-Proxies zeigt:
Logs brauchen Speicherplatz. Je nach Firma und Firewalls kann dies pro Tag auch bis zu 15 GB ausmachen. Hier macht es Sinn, dass man sich überlegt, wie lange die Daten durchsuchbar sein sollen und wann diese gelöscht werden. Dazu gibt es vier Lifecycle-Phasen, die ganz einfach in einer Lifecycle-Policy je Index oder global definiert werden können:
- Hot-Phase
- Hier befinden sich die Live-Daten.
- Hier wird indexiert und aktiv gesucht.
- Am performantesten auf lokalem oder sogar SSD-Storage
- Warm-Phase
- Die Warm-Phase ist da, falls man Logs länger durchsuchen möchte, aber diese nach einem gewissen Zeitpunkt auf einen günstigeren Storage auslagern möchte.
- Beispiel: Nach 20 Tagen sollen alle Logs automatisch vom SSD-Storage auf einen NFS-Share gemoved, also auf die Warm-Nodes verschoben werden.
- Diese Logs sind noch aktiv durchsuchbar, wenn eine längere Zeit zurück gesucht wird, z. B. über die letzten 90 Tage (Suche in hot und warm).
- Cold-Phase
- Diese Phase gilt nur zu Archivierungszwecken.
- Es kann nicht mehr aktiv darin gesucht werden. Um die Daten erneut zu durchsuchen, müssten diese zuerst in einen temporären Index reindexiert werden, Use-Case sind Banken, die Logs 10 Jahre aufbewahren möchten.
- Delete-Phase
- Logs, die diese Phase erreichen, werden vom Cluster gelöscht.
Wichtig zu erwähnen ist, dass nie alle Phasen definiert werden müssen. Es kann auch nur eine Hot-Phase von 30 Tagen geben und danach gleich die Delete-Phase.
