1. splunk > live 2017
Flughafen München
Einführung einer zentralen Logfile
Management Lösung
2. Gut. Besser. Ausgezeichnet
Flughafen München GmbH, Splunk Live Munich 20172
Der Flughafen München ist der erste Fünf-Sterne-Flughafen Europas. Bereits zum zehnten Mal
wählten
ihn die Passagiere zum besten Flughafen Europas (World Airport Awards).
Erster Fünf-Sterne-
Flughafen Europas
Bester Flughafen Europas
und drittbester der Welt
Bester Arbeitgeber
der Branche Verkehr und Logistik
2
6. Ausgangssituation:
Erkenntnisse vor dem Projekt „zentrale Log-Management-Lösung“
• Es existieren Fragestellungen, die eine spezialisierte Person/ Programm zur Beantwortung
benötigen.
• Nur in jedem Gewerk einzeln und nicht übergreifend möglich.
• Innerhalb von Gewerken wird u.U. nicht zentral geloggt.
• Übergreifende Beantwortung schwierig – im Wesentlichen aber langwierig und schwer
wiederholbar
• Die notwendige Transparenz unser eigenen digitalen Welt ist nicht gegeben.
• Wir haben Defizite, die Schätze der digitalen Welt für die Zukunft zu heben.
Flughafen München GmbH, Splunk Live Munich 20176
7. Projekt-Historie
• 2012 - Erste Splunk-Tests im Umfeld Remote Access und Firewall
• Tests vielversprechend, keine Beschaffung
• 2013/14 – erste Ideen zur Einführung einer SIEM-Lösung
• Definition erster konzeptioneller Punkte
• 2015 – Projektauftrag „zentrale Log-Management-Lösung für LAN/WLAN/Security“
• Technische Voraussetzung für SIEM geschaffen
• 2016 - Umsetzung zentrales Log-Management mit Splunk Enterprise
• Toolauswahl / Proof of Concept. Erste Schätzung des Datenvolumens: ~ 45 GByte / Tag
• Einbindung Datenschutz und Betriebsrat
• Beschaffung: HW & SW ( Lizenz: 150 GByte / Tag)
• 2017 – Nutzung durch Betrieb und Engineering
• Momentanes Datenvolumen: ~110 Gbyte / Tag
Flughafen München GmbH, Splunk Live Munich 20177
8. Architektur: Produktauswahl - Warum Splunk ?
Arbeits-
erleichterun
g
Ablösung von Scripten
durch übersichtliche
Tabellen
Zeitersparnis
Automatisierung von
textuellen Analysen
Korrelation
von
mehreren
Datenquelle
n
Security
Vorfälle
können
entdeckt
werden
Alarmierung bei Störungen
Einfache
Bedienung
Suchsprache ist auch für
komplexe Fragestellungen
geeignet
Flughafen München GmbH, Splunk Live Munich 20178
11. 3 Use Cases – Anforderungen aus dem IT Betrieb (Beispiele)
Proxy Systeme
• Mehrere geclusterte
Systeme
• Jedes System loggt für sich
• Web Interface lädt das
komplette Log
Welches System bedient
den Request des Kunden
(und mit welchem Ergebnis)?
Unbekanntes LAN Objekt
(ULO)
• NAC-Lösung im
MPLS/VPN-Umfeld
• Zuordnung Ereignis/System
zu örtlicher Lokation
Wo und wie oft tritt ein
solcher Vorfall auf?
Email
• Mehrere geclusterte
Systeme
• Unterschiedliche
Softwarekomponenten
• Keine einheitlichen Logs für
Mail, AV, SPAM-Erkennung
Warum wurden Emails nicht
zugestellt?
11 Flughafen München GmbH, Splunk Live Munich 2017
12. UseCase: zentrales Logging von Proxy Systemen
• Setup der FMG:
• zweistufiges Proxy System (interner + externer Cluster)
• Pro Cluster jeweils zwei leistungsstarke Server für Produktion
• Pro Cluster jeweils ein adäquates Testsystem
• System schreibt die Logs erstmal nur lokal.
• Aufgrund der Größe wird das Log stündlich rotiert und komprimiert.
• Betriebseinheit besitzt Zugriff auf die Proxy Logs nur über Webschnittstelle (Logansicht =
Download), sollen aber im Rahmen von Störbehebung ggf. telefonisch schnell Auskunft geben
können.
Flughafen München GmbH, Splunk Live Munich 201712
13. UseCase: Proxy Systeme
• Installation des Splunk Universal Forwarder auf das System
• Einfaches Splunk Dashboard für den Betrieb:
• Suche in nahezu Echtzeit möglich – über mehrere Server / Logfiles hinweg – auch ältere Events
können gefunden werden – incl. Drilldown zu weiteren Informationen.
Flughafen München GmbH, Splunk Live Munich 201713
14. UseCase: Proxy Systeme
• Proxy Logs können schnell auf Probleme hinweisen
• Lastverteilung OK?
• Ausreißer in der Nutzung der Proxies?
• „misbehaving“ Clients
Flughafen München GmbH, Splunk Live Munich 201714
15. UseCase: ULO – unbekannte LAN Objekte
Flughafen München GmbH, Splunk Live Munich 201715
• ULO: eigenentwickelte NAC-Lösung im MPLS/VPN-Umfeld
• Vergleicht sichtbare MAC Adressen an Switchports mit bekannten MAC Adressen aus der CMDB
• deaktiviert den Switchport bei Diskrepanzen
• Der Ort des betroffenen Switches / Port ist nicht identisch mit der physikalischen Lokation der LAN
Dose an dem das ULO aufgetreten ist.
• Logdatei für ULO: Text (csv Datei)
• Information über physikalische Lokationen ist im Kabelmanagement Tool vorhanden. Backend ist
eine Oracle Datenbank.
Korrelation des Ulo Events Kabelweg Gebäude/Raum/Dose
16. UseCase: ULO – unbekannte LAN Objekte
Flughafen München GmbH, Splunk Live Munich 201716
• Backend ist eine Oracle DB:
• Eine singuläre Abfrage benötigt ~ 20 min um aus Switch + Port die entsprechende Lokation der
Dose zu bekommen.
• Die Abfrage aller Switch / Port Kombis zu den angeschlossenen Dosen benötigt ebenfalls ~20 min
• Applikations Admin merkt an, daß dieser Anwendungsfall nicht wirklich unterstützt ist, ggf.
könnten DB Admins eine “materialized view“ einrichten.
• DB Administration schlägt vor, die genutzten Views / Queries vom Hersteller optimieren zu
lassen ( Zeit / Kosten ).
Splunk Admin zieht sich die Daten täglich mittels Splunk DB Connect ab und speichert sie in
einer CSV Datei als lookup ab:
| dbxquery connection=… query="SELECT …"
shortnames=t output=csv wrap=f maxrows=1000000
| outputcsv switch-port2bauteil-ebene-raum
17. UseCase: ULO – unbekannte LAN Objekte
Flughafen München GmbH, Splunk Live Munich 201717
• ULO Daten können angemessen gefiltert und dargestellt werden:
18. UseCase: ULO – unbekannte LAN Objekte
Flughafen München GmbH, Splunk Live Munich 201718
• Auch die Historie ist erkennbar:
19. UseCase: ULO – unbekannte LAN Objekte
Flughafen München GmbH, Splunk Live Munich 201719
20. UseCase: Ablauf einer Email durch
verschiedene Sicherheitssysteme
• Setup der FMG:
• mehrstufiges System
• Unterschiedliche Produkte für MTA, Spam, AV, Crypto im Einsatz
• Aus Redundanzgründen sind die einzelnen Komponenten mindestens doppelt vorhanden.
• Logdaten zu einer Email der einzelnen Komponenten nur schwierig untereinander korrelierbar.
• Eine Email kann durch unterschiedliche Software Instanzen auf
dem gleichen oder unterschiedlichen Servern geschleust werden.
Flughafen München GmbH, Splunk Live Munich 201720
21. UseCase: Ablauf einer Email durch
verschiedene Sicherheitssysteme
• Anforderung aus dem Betrieb:
• Es soll eine einfache Lösung zur Nachverfolgung durch die verschiedenen
Email Instanzen soll etabliert werden.
• Herausforderungen bei der Umsetzung:
Eine Email kann bei der FMG durch 7 unterschiedliche Software Instanzen laufen, bevor sie
ausgeliefert wird. Die Korrelation der entsprechenden Events über die ‚queue_id‘ ist nicht eindeutig.
Fallback: ‚message_id‘. Auch die message_id ist nicht eindeutig. AV Systeme können diese ggf.
verändern. Die Kombination ist für uns jedoch ausreichend.
Der aktuelle Status einer Email ist nicht in einer singulären Logzeile hinterlegt. Es müssen immer
mehrere Logzeilen miteinander verknüpft werden („queue_id“). Probleme siehe oben.
Flughafen München GmbH, Splunk Live Munich 201721
22. UseCase: Ablauf einer Email durch
verschiedene Sicherheitssysteme
• Umsetzung:
• Annahme durch FMG Mailserver durch rote oder grüne Markierung
dargestellt. eine erste Aussage sofort möglich.
• Komplexere Fälle (z.B. multiple Adressaten) müssen über eine andere Suche erkannt werden.
„transaction queue_id endswith=removed startswith=client ...“
Flughafen München GmbH, Splunk Live Munich 201722
23. UseCase: Ablauf einer Email durch
verschiedene Sicherheitssysteme
• Umsetzung:
• Drilldown ergibt detaillierte Aussage über den Weg einer Email durch
die FMG Systeme:
Flughafen München GmbH, Splunk Live Munich 201723
24. UseCase: Ablauf einer Email durch
verschiedene Sicherheitssysteme
• Umsetzung:
• Ebenso ist der AV Status sofort an der grünen bzw. roten Markierung
erkennbar.
• Das komplette Ergebnis ist als ein singuläres Dashboard realisiert.
Flughafen München GmbH, Splunk Live Munich 201724
25. Weitere Nutzungsbeispiele
• Internetauftritt www.munich-airport.de & Passengr-App:
• Logfiles der Web & Application Server geben sofort Auskunft über evtl. auftretende Probleme im
Betrieb oder auch beim deployment einer neuen Version in der Testumgebung.
• Auswirkungsanalyse
• Switch „xyz“ wird im Rahmen normaler Tätigkeiten gebootet Welche Systeme sind davon
betroffen?
• Analysen weiterer Logquellen / Daten:
• Security Systeme: Firewall, Remote Access Systeme, Vuln. & APT-Scans.
• WLAN und Radius.
• Remote Desktop Strategie
• Messung und Vergleich der Benutzbarkeit von virtuellen zu physikalischen Endnutzer Systemen
(Terminalserver vs. Thin Client).
Flughafen München GmbH, Splunk Live Munich 201725
26. Ideen / Ausblick
• Vorher-/Nachher Analyse im Netzwerk im Rahmen von Changes:
• Im Rahmen des PoC von Splunk mit einfachen Mitteln (zählen von Routing Tabellen, getrunkten VLANs,
etc. ) erfolgreich angegangen. Vielversprechender erscheint uns die Möglichkeit entsprechende
Parameter durch Machine Learning auswerten zu lassen.
• Security Incident und Event Management System.
• Erweiterung der Nutzung von Splunk auf die gesamte IT-Landschaft, sowie die Validierung weiterer Use
Cases im Umfeld Technik, Marketing usw.
Die initial erkannten Anwendungsfälle sind nur der Startpunkt für alle weiteren Aktivitäten. Nahezu jedes
Logfile enthält, auch für den erfahrenen Administrator, Überraschungen.
Fragestellungen verändern sich, da sich die Kenntnisse zu einzelnen Gewerken vertiefen. Weg von: „zähle
X“, hin zu „vergleiche X mit Y, visualisiere, erkenne den Grund für X“.
Entscheidungen werden nicht mehr aufgrund einzelner Parameter, sondern aufgrund größerer
Zusammenhänge getroffen.
Flughafen München GmbH, Splunk Live Munich 201726