Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

SplunkLive! München - Flughafen München

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 27 Anzeige

Weitere Verwandte Inhalte

Ähnlich wie SplunkLive! München - Flughafen München (20)

Weitere von Splunk (20)

Anzeige

Aktuellste (20)

SplunkLive! München - Flughafen München

  1. 1. splunk > live 2017 Flughafen München Einführung einer zentralen Logfile Management Lösung
  2. 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
  3. 3. Flughafen München GmbH Flughafen München GmbH, Splunk Live Munich 20173
  4. 4. Flughafen München GmbH Flughafen München GmbH, Splunk Live Munich 20174
  5. 5. 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. Flughafen München GmbH, Splunk Live Munich 2017
  6. 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. 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. 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
  9. 9. Architektur: Überblick Zentralsystem Flughafen München GmbH, Splunk Live Munich 20179
  10. 10. Zahlen, Daten, Fakten Flughafen München GmbH, Splunk Live Munich 201710
  11. 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. 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. 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. 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. 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. 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. 17. UseCase: ULO – unbekannte LAN Objekte Flughafen München GmbH, Splunk Live Munich 201717 • ULO Daten können angemessen gefiltert und dargestellt werden:
  18. 18. UseCase: ULO – unbekannte LAN Objekte Flughafen München GmbH, Splunk Live Munich 201718 • Auch die Historie ist erkennbar:
  19. 19. UseCase: ULO – unbekannte LAN Objekte Flughafen München GmbH, Splunk Live Munich 201719
  20. 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. 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. 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. 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. 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. 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. 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
  27. 27. Vielen Dank

×