16 Dezember 2015 User Stories

Der Elastic Stack bei WÜRTHPHOENIX NetEye: Warum Log Management?

Von Georg Kostner

Wuerth-Phoenix_large.png

Begonnen hat alles mit dem neuen Gesetzesdekret, welches die Italienische Datenschutzbehörde „Garante per la protezione dei dati personali“ 2008 erlassen hat. Die Regelung schreibt vor, dass alle Unternehmen, alle Daten in Bezug auf Systemzugriffe seitens der Administratoren aufzeichnen und für mindestens sechs Monate archivieren müssen. Dieses Vorgehen soll die Überwachung der Aktivitäten der Systemadministratoren erleichtern und vereinheitlichen, aber vor allem die sensiblen Daten im Unternehmen schützen. Stichwort: Security Auditing.  (Hier finden Sie die offiziellen Inhalte auf italienischer und englischer Sprache).

Durch die detaillierte Analyse der von der Datenschutzbehörde vorgeschriebenen Anforderungen, können die folgenden vier Kategorien erkannt werden:

  • Aufzeichnung und Sammlung von Events (Logon, Logoff, Failure Authentifizierungen) aus einer heterogenen Systemwelt (Windows, Unix, Linux, Datenbanken wie Oracle, DB2, MySQL, Lotusnote, SAP, Firewall usw.)
  • Zentrale Ablage der Events aller Systeme, Datenbanken und Netzwerkgeräten
  • Indizierung der Events für eine schnelle Suche und zur Erkennung von Anomalien
  • Ermöglichung der gezielten Suche nach bestimmten Merkmalen (wie Hostname, User, Uhrzeit usw.) seitens der Auditoren

Im Jahr 2010 standen wir also der Herausforderung gegenüber, unseren Kunden für all diese Kategorien eine passende Lösung innerhalb unserer IT-System Management Lösung NetEye bereitstellen zu können.

Should we develop our own agent.png

Bestehende Möglichkeiten — Was gab es in der Open Source Welt bereits?

Da unser Monitoring-Tool NetEye auf verschiedenen Open Source Modulen basiert, war es sehr naheliegend, dass wir uns in einem ersten Schritt intensiv mit den bestehenden Möglichkeiten in der Open Source Welt beschäftigten. Was gab es also bereits für Tools um Log-Daten zu sammeln? Unsere Recherche hatte ergeben, dass sich Snare und Epilog eigneten um Logs zu erfassen. Allerdings gab es bei dieser Kombination einige Einschränkungen:

  • Die zuverlässige und sichere Kommunikation war nicht gewährleistet (TLS-TCP, SYSLOG RELP Problem)  
  • Die agent-seitige Filterung, damit nur jene Events gesammelt werden, welche auch tatsächlich benötigt werden, um Netz und Server nicht unnötig zu belasten, war nicht möglich.
  • Keine zentrale und einfache Konfiguration der beiden Agents auf unterschiedlichen Betriebssystemen.
  • Überwachung der Agents selbst.
  • Auto-Discovery der Administrator-Rollen auf Windows nicht möglich.
  • Die Installation von zwei Agents (Snare und Epilog) ist unnötig aufwendig

Nach der Bewertung dieser Schwachpunkte kamen wir zum Schluss, dass wir uns mit diesen Punkten nicht abfinden wollten und entschieden uns für die Entwicklung eines eigenen Agents. Der von uns entwickelte SAFED-Agent (Security Auditing ForwardEr Daemon) basiert auf Snare und Epilog und wurde der Community als neue Möglichkeit für die Sammlung von Logs zur Verfügung gestellt. [Github - Safed] Zum Empfangen der Events auf Linux hatten wir uns für den rsyslog entschieden. Zur Indizierung der Logs hatten wir uns in der ersten Version auf Solr von Apache geeinigt. Zum Durchsuchen der Logs über Solr hatten wir eine eigene Oberfläche entwickelt. Somit waren wir für die Anforderungen 2010 bestens gerüstet.

Entwicklung des neuen Safed Agent.png

Fig. 2 Safed Agent

Mehrwerte — Wir wollen mehr!

Unsere Lösung diente zwar der Einhaltung der vorgeschriebenen Richtlinien, allerdings stellte sie für das IT-Management keinen besonders großen Vorteil dar. Wir wollten unsere Lösung unbedingt so weiterentwickeln, dass sie für das IT-Service Management unserer Kunden einen Mehrwert darstellt.

Durch Kundenfeedbacks lernten wir die anspruchsvolleren Anforderungen der Welt des Log Managements und des Security Information und Event Management (SIEM) kennen. Plötzlich ging es nicht mehr „nur“ um das Sammeln und Archivieren von Logs. Wir standen einer Liste neuer Anforderungen gegenüber:

  • Daten Aggregation: Aggregation von Daten verschiedenen Ursprungs (Netzwerk, Security, Server, Datenbanken, Applikationen)
  • Korrelation: Erkennung gemeinsame Attribute zur Bündelung der Events
  • Alarme: Automatisierte Analyse der korrelierten Events zum Versenden von Benachrichtigungen
  • Dashboards: Abbildung der Event-Daten auf Dashboards
  • Konformität: Reports zu den Bereichen Security, Governance und Auditing
  • Retention: Langzeit-Speicher historischer Date
  • Forensische Analysen: Suche in Logs verschiedener Nodes und Zeitspannen basierend auf diversen Kriterien

Dafür war die Kombination aus SAFED-Agent, rsyslog und Solr nicht mehr ausreichend. Wir machten uns also erneut auf die Suche nach geeigneten Tools um NetEye an die neuen Marktanforderungen anzupassen. Im Januar 2014 stießen wir auf den Elastic Stack. Unsere Entwickler setzten sich intensiv mit dem Thema auseinander und erkannten die Chance, mithilfe des Elastic Stacks, NetEye zu einer vollwertigen Log Management Lösung auszubauen.

Wir entschieden uns, den Elastic Stack in NetEye zu integrieren. Die Hauptentscheidungsgründe waren dabei:

  • die einfache Implementierung
  • das Logstash Parsing-Tool
  • die Clusterfähigkeit von Elasticsearch
  • die Skalierbarkeit
  • und Kibana als interaktives Dashboard

[Um ganz genau zu sein, nutzen wir zwischenzeitlich Grok als Parser. Das war technisch jedoch relativ aufwendig. Als Grok dann in Logstash integriert wurde, war die Nutzung einfacher. Dies war ein weiterer Grund, der für die Integration des Elastic Stacks sprach.]

Unsere Weboberfläche für die Suche ersetzten wir mit Kibana, Solr musste Elasticsearch weichen. Logstash nutzten wir von da an als Log-Parser, außerdem bot uns Elasticsearch die Möglichkeit der Aggregation und der indizierten Suche.

Integrated Open Source Projects.pngFig. 3 Integrierter Elastic stack

Das einzige was uns damals noch für die grundlegenden SIEM-Funktionen fehlte war ein Event Handler, also ein Element, das auf den Eingang eines Events proaktiv reagiert und je nach Ereignis eine bestimmte Aktion auslöst. Wir entwickelten den NetEye Event Handler, welcher Syslog-Ereignisse, Emails, SNMP Traps und SMS erfassen und mittels einer „Rule Matching Engine“ entsprechenden Aktionen zuweisen kann. (Details zum NetEye Event Handler gibt es auf unserem Blog)

Ergebnis — Wir sind stolz!

Das Ergebnis unserer Eigenentwicklungen und der Integration vom Elastic Stack im Jahr 2014 war der Release von NetEye 3.5 mit einem umfassenden Log Management Modul. Events werden gesammelt, indiziert und aggregiert. Individuelle Suchen werden ermöglicht und auf alle Events kann automatisch reagiert werden. Wir sind mit dem Ergebnis zufrieden und freuen uns, dass unsere Kunden nicht mehr nur die Einhaltung der Datenschutzrichtlinien verfolgen, sondern vielmehr die gesamten Vorteile eines umfassenden Log Managements nutzen können.

Drill Down.png

Fig. 4 Kibana Dashboard

Zukunft — Es gibt viel zu tun!

Software Metering

Wir haben erkannt, dass wir mit der von uns geschaffenen Basis noch viele weitere Einsatzgebiete abdecken können. Aktuell haben wir Kundenanfragen zur Abbildung eines Application Metering. Ganz konkret geht es dabei um ein Software Metering auf einer Citrix Farm. Hierfür nutzen wir unseren SAFED-Agent um die Events (Application start — end pro User) zu sammeln, die Ereignisse werden dann in Elasticsearch abgelegt und über das Kibana-Dashboard dargestellt. Dieses Beispiel unterstreicht einmal mehr, die Flexibilität des NetEye Log Managements auf Basis des Elastic Stacks.

Netzwerk Performance Monitoring

Im Bereich Netzwerk Performance Monitoring sammeln wir mithilfe unserer nBox Appliance, Netflow-Daten, um die Nutzung des Netzwerks zu messen. Auch hier gibt es Ansätze, die gesammelten NetFlow-Daten direkt im Elastic Stack abzulegen. Logstash ist in der Lage NetFlow v5 und v9 zu empfangen (bei NetFlow v9 mussten wir ein bisschen nachbessern, aber das war mit relativ geringem Aufwand erledigt). In Kibana 4 können die NetFlow Dashboards dargestellt werden. Da die Kibana-Dashboards in der Navigation und Aggregation so mächtig sind, bieten sie der IT-Welt eine Vielfalt von Möglichkeiten.

Doch auch hier steht die nächste Herausforderung bereits vor der Tür. Wie gut kann Elasticsearch mit Millionen NetFlow-Flüssen umgehen? Wir setzten unsere Netzwerksonden auch im Bereich von 10G Netzwerken ein, da entstehen Millionen solcher Flows im Sekundentakt.

Performance Daten auf I/O Ebene

Ein weiteres Projekt, welches wir angehen werden, ist die Sammlung von Performance Daten einer VMWare ESX Umgebung und auf SAN Systemen auf I/O Ebene. In diesem Projekt werden wir die Daten der VM per VMWare SDK, Datastore, Lun auslesen um somit die Top-Talkers der VM(s) darzustellen. So sieht ein Admin auf Anhieb, welche VM extrem viel I/O Last auf seiner SAN erzeugt. Im Falle von mehreren SANs (auch verschiedener Hersteller) wird er somit nicht den Überblick verlieren bzw. in einer vertretbaren Zeit eine Antwort auf seine Fragestellung finden.

Zusammenfassung

Abschließend möchte ich sagen, dass wir erst am Anfang der Einsatzmöglichkeiten des Elastic Stacks innerhalb NetEye stehen. Es wird spannend zu sehen, welche Marktanforderungen mit dem Elastic Stack noch abgebildet werden können. Auch in der Community entstehen ständig neue Möglichkeiten und Einsatzgebiete für eine derart flexible Technologie.


Georg KostnerGeorg Kostner weißt über 17 Jahre Erfahrung in den Bereichen IT-System Management und Software-Entwicklung innerhalb der Würth-Gruppe auf. Zu Beginn seiner beruflichen Laufbahn beschäftigte er sich mit der Implementierung von ERP Anwendungen und Framework-Entwicklungen. Sein Einsatz für innovative, technologische Forschungsprojekte und vor Allem sein Interesse für Open Source Software begleiten ihn bis heute. Aktuell ist er als Leiter der Abteilung System Integration für die hausintern entwickelten Lösungen WÜRTHPHOENIX NetEye und WÜRTHPHOENIX EriZone verantwortlich.