SplunkLive! München - Flughafen München

splunk > live 2017
Flughafen München
Einführung einer zentralen Logfile
Management Lösung

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

Flughafen München GmbH

Faszination Flughafen
5
42 Mio.
Passagiere
1.600
Hektar
Gesamtfläche
35.000
Mitarbeiter
am Campus
Illustration nicht maßstabs- und lagegetreu
550
Betriebe am Campus
400.000
Starts & Landungen
335.000
Tonnen Luftfracht
Der Flughafen München – eine Stadt zum Abheben.

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.

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

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

Architektur: Überblick Zentralsystem

Zahlen, Daten, Fakten

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

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.

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.

UseCase: Proxy Systeme
• Proxy Logs können schnell auf Probleme hinweisen
• Lastverteilung OK?
• Ausreißer in der Nutzung der Proxies?
• „misbehaving“ Clients

UseCase: ULO – unbekannte LAN Objekte
• 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

• 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

• ULO Daten können angemessen gefiltert und dargestellt werden:

• Auch die Historie ist erkennbar:

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.

• 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.

• 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 ...“

• Umsetzung:
• Drilldown ergibt detaillierte Aussage über den Weg einer Email durch
die FMG Systeme:

• 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.

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).

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.

SplunkLive! München - Flughafen München

Weitere ähnliche Inhalte

Was ist angesagt?

Mehr von Splunk

SplunkLive! München - Flughafen München