Überall nur Daten - Teil 2
Nachdem die Grundlagen in Teil 1 erklärt wurden, zeigen wir Ihnen im zweiten Teil eine partielle und vereinfachte Angriffserkennung mit Splunk.
Vorbetrachtung
In der Praxis sind meist heterogene Umgebungen zu finden. Für diese sind vorgefertigte Plug-Ins nur bedingt nutzbar, doch wie erkennt man dann Angriffe auf das Unternehmen? Es besteht die Möglichkeit, Systeme auf Anomalien zu überprüfen. Ist ein Unternehmen z.B. nur im deutschsprachigen Raum tätig, können Zugriffe auf Systeme von anderen Geolokationen Aufschluss über ein erfolgtes Abtasten oder einen Angriffsversuch deuten (Zugriffs-Dashboard).
Ferner können fehlgeschlagene Login-Versuche weiteren Aufschluss bieten. Auch Zugriffsmuster, z.B. auf Fileserver können einen Angriff signalisieren. So ist es eher unüblich, dass ein Nutzer mehrere Tausend Files innerhalb einer Stunde abruft bzw. modifiziert. Indikatoren sind hier:
- Anzahl der Zugriffe pro Nutzer
- Geschwindigkeit
- Zugriffzeiten
- eine erhöhte Anzahl von Abrufen sensibler Daten
Ein weiterer Indikator kann z.B. DNS Datenverkehr sein. Dieser wurde eigentlich nicht für den Datentransfer konzipiert und wird somit vielfach vernachlässigt. Jedoch erfreut sich dieser Kanal zunehmender Beliebtheit bei Bots und Trojanern. Das Aufspüren solcher „hidden channels“ ist mittels Logfileanalyse jedoch recht einfach zu bewerkstelligen. Indikatoren hierfür sind z.B.:
- Volumen des DNS Traffics nach IP
- Länge und Anzahl von Subdomains
Hier gilt, lange und kryptische Subdomains sind eher untypisch für gewollten Datenverkehr, da deren Einsatz-Zweck das einfache Erreichen eines Dienstes ist. Aber auch die Analyse von Firewall-Daten kann Aufschluss geben. So kann eine vermehrte Nutzung von sogenannten High Ports ebenfalls ein Indiz für aktive Angriffe sein.
Umgebung für Betrachtung:
Für die weitere Betrachtung und das How To wurde ein Webserver aufgebaut. Dieser ist von extern erreichbar. Logfiles werden via Splunk Universal Forwarder an einen zentralen Splunk Server (Indexer & Search Head) weitergeleitet. Eingehende Daten vom Webserver werden im Index „dmz“ erfasst. Das System hat eine Loghistorie von ca. 1,5 Monaten.
Angriffserkennung auf Basis der Source IP
Die notwendigen Apache Log Files werden von der Struktur her als „combined_access“ erkannt. Reguläre Zugriffe erfolgen nur aus Deutschland. Sollen nun alle Logfiles angezeigt werden, nutzt man folgenden Suchbefehl: index=“dmz“ sourcetype=access_combined
Über die Feld-Auswahl (vgl. Abb. 1) erhält man nun die Möglichkeit zu filtern. Werden Felder nicht automatisch erkannt, können diese mittels „Field Ex-traction“ durch Markierung der Passage in einem Logeintrag oder durch Angabe eines Trennzeichens separiert werden. Die Felder User und Plattform wurden so ermittelt. Mittels Klick auf User und „Events with this Field“ werden alle User aufgelistet. Diese Abfrage kann mittels „Save as“ „Dashboard“ als neues Dashboard oder innerhalb eines Dashboards abgespeichert werden. Die Suche wird hierbei automatisch auf „index=“dmz“ sourcetype=“access_combined“ User=“*““angepasst.
Eine Filterung nach Plattform erfolgt analog zu der Userübersicht. Um die Auswahl zu limitieren, bietet sich das Top Kommando an. Im Beispiel wird die Auswahl auf die Top 10 Werte limitiert. Somit bleibt die Ausgabe übersichtlicher, wenn mehrere Ergebnisse zurückgeliefert werden.
index=“dmz“ sourcetype=access_combined| top limit=10 Plattform
Eine Umsetzung von IP zu Zugriffsort wird bei Splunk mittels „iplocation“ realisiert. Als Quelle dient die Source IP des Logfiles. Die Ausgabe in Tabellenform erfolgt mittels „table“. Im Beispiel geschieht dies nach Land. Eine Sortierung nach Bundesland oder Stadt ist aber auch möglich.
index=“dmz“ sourcetype=access_combined Source_IP=“*“ | iplocation Source_IP |table Source_IP Country
Zur Nutzung der Clustermap wird der geostats Befehl genutzt. Somit ergibt sich folgende Suchabfrage:
index=“dmz“ sourcetype=access_combined Source_IP=“*“ | iplocation Source_IP | geostats count by City
Das Ergebnis aller Abfragen zeigt die Abbildung „Zugriffs-Dashboard“:
Um nun Zugriffe aus Deutschland auszuschließen, fügt man folgendes Kommando vor den „geostats“ Befehl ein: „| search Country!=Germany“
Um die Original-Logfiles zu sehen, reicht ein einfacher Klick auf eine entsprechende Abfrage. Wählt man ein Event auf der Karte aus, ergibt dieses z.B. folgende Ausgabe:
Der Eintrag lässt auf einen automatisierten Scan eines US IT-Sicherheitsdienstleisters schließen. Auf Basis dieser Grundwerte können dann weitere Abfragen gestartet werden, wie z.B. Anzeigen der geografischen Verteilung von Fehlerfällen und die Verteilung der Fehler in Korrelation mit dem Zeitpunkt (siehe erweitertes Zugriffs-Dashboard). All dies kann helfen, untypische Verhaltensmuster aufzudecken und ggf. hieraus Alarme zu generieren.
Dies zeigt nur eine kleine Auswahl an Möglichkeiten. Allein die Vorbetrachtung lässt hier noch einigen Spielraum offen. Kontaktieren Sie uns, wenn Sie mehr erfahren wollen.
Weiterführende Informationen:
Bildquelle/Copyright: © Sergey Nivens — fotolia.com
