Dieser Blogbeitrag ist Teil einer Challenge (eines „Blog-a-thons“) in meiner Gruppe von Vertriebsingenieuren. Die Herausforderung besteht darin, herauszufinden, wer über einige der am wenigsten verwendeten Splunk-Suchbefehle bloggen kann. Ich habe mich für coalesce entschieden, weil über diesen Suchbefehl selten gesprochen wird.
Wann kann der coalesce-Befehl verwendet werden?
„Defense in depth“ ist eine ältere Methodik, die für Perimetersicherheit verwendet wird. Zum Konzept gehört die Erstellung mehrerer Barrieren, die vom „Hacker“ überwunden werden müssen, bevor er in eine Umgebung eindringen kann. Um es jemandem mit böswilligen Absichten schwer zu machen, werden auf bestimmten Ebenen mehrere Anbieter eingesetzt. So kann beispielsweise die Firewall eines Anbieters zu einem bestimmten Zeitpunkt ausnutzbare Schwachstellen aufweisen, was für die Firewall eines anderen Anbieters zu diesem Zeitpunkt aber nicht gelten muss. Theoretisch seid ihr dadurch weniger gefährdet. Ob sie nun von einer alten "defense in depth"-Strategie oder aus mehreren Unternehmenszusammenschlüssen herrühren – Umgebungen mit mehreren Anbietern stellen ein ständiges Risiko dar. Als Security-Experten haben wir schon vor langer Zeit gelernt, dass die Geschwindigkeit und der Komfort einer zentralen Verwaltung die Vorteile des verringerten Risikos durch die oben erwähnte Technik bei weitem überwiegen. Selbst wenn ihr das nicht selbst durchlebt habt, lasst euch gesagt sein, dass selbst heute noch über 50 % der größten Unternehmen ihre Netzwerksicherheit manuell und individuell über die Konsolen der einzelnen Anbieter verwalten.
In diesen gemischten Umgebungen lassen sich Logging-Standards unmöglich aufrecht erhalten, da riesige Mengen an „maschinengenerierten Daten“ erstellt werden und die Felder in den Daten unterschiedlich bezeichnet sind. Beispielsweise verwendet ein Anbieter „sip“ zur Beschreibung der Quell-IP, während ein anderer „src_ip“ verwendet. Ein weiteres Beispiel sind die verschiedenen EventIDs, die in Logs für verschiedene Versionen von Windows-Betriebssystemen verzeichnet werden. Die EventIDs der Desktop-Firewall ändern sich (wir haben beispielsweise 852, 4946, 4947 oder 4948), sie stehen aber alle für das gleiche Ereignis.
Hier kommt coalesce ins Spiel, um dieses Problem zu lösen.
Wie ihr im zweiten Anwendungsfall sehen könnt, normalisiert der coalesce-Befehl Feldnamen mit dem gleichen Wert. Coalesce nimmt den ersten Wert ungleich NULL zum Kombinieren.
Ihr könnt euch vorstellen, wie schwierig es in diesen Anwendungsfällen wäre, dafür in einer herkömmlichen relationalen Datenbank ein Schema zu erstellen. Aber mit Splunk ist es ganz einfach.
Coalesce:
Beispieldaten:
Thu Mar 6 11:33:49 EST 2014 src_ip=1.1.1.1
Thu Mar 6 11:33:45 EST 2014 sourceip=8.1.2.3
Thu Mar 6 11:33:48 EST 2014 source_ip=1.1.1.0
Thu Mar 6 11:33:47 EST 2014 sip=1.1.1.199
Thu Mar 6 11:33:46 EST 2014 ip=
Thu Mar 6 11:33:46 EST 2014 ip=22.22.22.22
Hier werden wir mit „coalesce“ alle diese verschiedenen Schlüssel für die Quell-ID vereinigen und sie für weitere Statistiken unter dem gemeinsamen Namen src_ip zusammenfassen.
Kopiert für dieses Beispiel die Daten oben und fügt sie in die Datei „firewall.log“ ein. Verwendet anschließend den oneshot-Befehl, um die Datei zu indizieren:
./splunk add oneshot “/your/log/file/firewall.log” –sourcetype firewall
sourcetype=firewall
|eval src_ip = coalesce(src_ip,sourceip,source_ip,sip,ip)
Hier ist ein weiteres Beispiel für die Verwendung und die Leistungsfähigkeit des coalesce-Befehls:
Wed Mar 12 10:53:55 EDT 2014 bytesIN=10000000000
Wed Mar 12 10:53:55 EDT 2014 bIN=10000000000
sourcetype=firewall
| eval TotalGBIn = coalesce(bytsIN, bIN)/1024/1024/1024
Im oben besprochenen Anwendungsfall könnt ihr es mit einem Feld wie „bytesIN“ und „bIN“ zu tun haben, das zu einem bestimmten Zeitpunkt den gleichen Wert darstellt. Der Befehl „coalesce“ nimmt nur den ersten Wert ungleich NULL im Array an und kombiniert alle verschiedenen Felder zu einem Feld, das dann für weitere Befehle verwendet werden kann.
Viel Spaß beim Splunken!
----------------------------------------------------
Vielen Dank!
David Croteau
*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier.
