Security

Platformübergreifende Log-Analyse ohne SIEM

Parallele Datenabfrage über mehrere Managementsysteme

Michael Meister

23. Apr. 2024 • 4 min read

Es gibt Firmen, die ihren Administratoren nicht gestatten auf Informationen des SIEM zuzugreifen. Sei es, weil zum Beispiel Security- und Firewall-Betrieb in unterschiedlichen Abteilungen abgebildet ist. Möglicherweise verbieten auch interne Prozesse, dass die Proxy-Administratoren ihre Auswirkungen in korrelierten Logfiles analysieren können.

Normalerweise kann man in einem SIEM gut filtern, welche Informationen ein User sehen darf. Dennoch mag es Gründe geben, die einen Zugriff auf zentrale Logs verbieten.

Auswege

Folgende Möglichkeiten habe ich bereits implementiert:

Es wäre möglich, dass eine Abteilung ihre Logs nicht nur an das SIEM schickt, sondern zusätzlich an einen eigenen zentralen Syslog-Server. Dies hat den Vorteil, dass die Daten schnell zu ermitteln sind. Auch Dashboards lassen sich so vorhalten. Nachteil ist, dass die doppelte Menge an Daten über das Netz übertragen werden müssen.
Man könnte die Daten von den beteiligten Systemen abholen, wenn sie gebraucht werden. Vorteil ist, dass man keine weitere Infrastruktur benötigt. Der Nachteil ist jedoch, dass das Erzeugen der Logs eine gewisse Zeit in Anspruch nimmt - also langsam ist.

Den ersten Weg kann man leicht umsetzen, indem man einen Greylog-Server oder gar einen wazuh-Server aufstellt. Hier sind die Anfragen schnell gestellt. Auch Übersichten lassen sich vorhalten. Selbst regelmäßige Reports sind möglich. Man nutzt daher eigentlich ein SIEM als weiteren Syslog-Server. Wenn man keine Usecases konfigurieren muss, ist das Aufsetzen von wazuh ein Kinderspiel. Es reicht, eine Zeile in die Konsole zu kopieren:

curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

Fertig!

Den zweiten Weg musste ich leider in einem Unternehmen aufbauen, dem interne Prozesse und mangelndes technisches Verständnis der Prozessverantwortlichen im Weg standen.

Ein Lösungsansatz ohne zusätzliche Hardware

An ein Firewallteam, das mehrere unterschiedliche Produkte diverser Hersteller verwaltet, wird oft die Frage nach der Aktivität einer IP-Adresse gestellt. Das Team muss diese Informationen dann schnell aus all den unterschiedlichen Plattformen beschaffen. Dies kann ohne eine zentrale Log-Instanz eine mühselige und zeitaufwändige Aufgabe sein.

Ich hatte früher verschiedene kleinere Scripts geschrieben, um aus verschiedenen Firewalltypen die Logs zu beschaffen. Damit ich diese parallel ausführen kann, habe ich diese später in einem kleinen Werkzeug zusammengefasst. Dies sah ungefähr so aus (da ist die Filterung nach einer einzigen IP nicht drin 😉):

#!/bin/bash

# Array mit den Hostnamen der Firewall-Systeme
hosts=("checkpoint-fra" "checkpoint-kar" "opnsense_ham" "opnsense_muc" "barracuda_dus" "barracuda_ber" "fortianalyzer_fra")

# Array für die gesammelten Ereignisse
all_events=()

# Funktion, um die SSH-Verbindung herzustellen und Firewall-Events abzurufen
fetch_events() {
 	 	fwhost=$1
 	 	if [[ $fwhost == *"checkpoint"* ]]; then
 	 	 	 	events=$(ssh username@$fwhost "fw log -n -p")
 	 	 	 	all_events+=("$events")
 	 	fi
 	 	if [[ $fwhost == *"opnsense"* ]]; then
 	 	 	 	events=$(ssh username@$fwhost "cat /var/log/filter/latest.log")
 	 	 	 	all_events+=("$events")
 	 	fi
 	 	if [[ $fwhost == *"barracuda"* ]]; then
 	 	 	 	events=$(ssh username@$fwhost "cat /phion0/log/fw.log")
 	 	 	 	all_events+=("$events")
 	 	fi
 	 	if [[ $fwhost == *"fortianalyzer"* ]]; then
 	 	 	 	# Konfiguration
 	 	 	 	FA_HOST="$fwhost"
 	 	 	 	FA_USER="your_api-username"
 	 	 	 	FA_PASS="your_api-password"

 	 	 	 	# Authentifizierung und Token erhalten
 	 	 	 	login_response=$(curl -s -k -X POST \
 	 	 	 	 	"https://$FA_HOST/logincheck" \
 	 	 	 	 	-d "username=$FA_USER" \
 	 	 	 	 	-d "secretkey=$FA_PASS")

 	 	 	 	# Extrahiere die Session-Token-ID aus der Antwort
 	 	 	 	session_token=$(echo "$login_response" | grep -oP '^[^|]+')

 	 	 	 	# Überprüfe, ob die Anmeldung erfolgreich war
 	 	 	 	if [ -z "$session_token" ]; then
 	 	 	 	 	echo "Anmeldung fehlgeschlagen. Überprüfe Benutzernamen und Passwort."
 	 	 	 	fi

 	 	 	 	# API-Anfrage zum Abrufen aller FortiGate-Events
 	 	 	 	events_response=$(curl -s -k -X POST \
 	 	 	 	 	"https://$FA_HOST/api/v2/monitor/user/event" \
 	 	 	 	 	-d "sessionid=$session_token" \
 	 	 	 	 	-d "limit=0" \
 	 	 	 	 	-d "filter=devid=@'FG%'" \
 	 	 	 	 	-d "format=detail" \
 	 	 	 	 	-d "orderby=time" \
 	 	 	 	 	-d "reverse=false")

 	 	 	 	# Überprüfe, ob die API-Anfrage erfolgreich war
 	 	 	 	if [ -z "$events_response" ]; then
 	 	 	 	 	echo "Fehler beim Abrufen der Events."
 	 	 	 	fi

 	 	 	 	# Füge die Events zum Array hinzu
 	 	 	 	all_events+=("$events_response")

 	 	 	 	# Abmelden und Session beenden
 	 	 	 	curl -s -k -X POST \
 	 	 	 	 	"https://$FA_HOST/logout" \
 	 	 	 	 	-d "sessionid=$session_token"
 	 	fi
}

# Exportiere die Funktion, um sie von parallel verwenden zu können
export -f fetch_events

# Parallelisierte Ausführung für jede IP-Adresse
parallel fetch_events ::: "${hosts[@]}"

# Falls man 'parallel' zu kompliziert findet, kann man den Einzeiler auch so schreiben:
# for fw in ${hosts[@]}; do 
# 	fetch_events $fw &
# done
# wait

# Zusammenführen und Sortieren der Events
sorted_events=$(printf "%s\n" "${all_events[@]}" | sort -k 1M -k 2n -k 3n -k 4n -k 5n -k 6n)

# Ausgabe der sortierten Events
echo "$sorted_events" | column -tx

Hier ist eine Zusammenfassung der Schritte:

Es definiert ein Array hosts, das die Hostnamen der Firewall-Systeme enthält, von denen die Ereignisprotokolle abgerufen werden sollen.

Es definiert ein leeres Array all_events, um die Ereignisse von allen Firewall-Systemen zu sammeln.

Es definiert eine Funktion fetch_events, die für jeden Host im Array die entsprechenden Ereignisprotokolle abruft und sie dem Array all_events hinzufügt. Die Methode variiert je nach Art des Firewall-Systems, von dem die Ereignisse abgerufen werden.

Um die Ausgabe extrem zu beschleunigen wird die Funktion fetch_events parallel für jeden Host im Array hosts ausgeführt, um die Ereignisprotokolle von allen Firewall-Systemen gleichzeitig abzurufen.

Nachdem alle Ereignisse abgerufen wurden, werden sie mithilfe des Befehls sort nach Zeit sortiert.

Die sortierten Ereignisse werden in tabellarischer Form mithilfe des Befehls column -tx auf der Konsole ausgegeben.

Natürlich lässt sich mit geringem Aufwand die Ausgabe kosmetisch verbessern. Aber hier soll lediglich ein Weg aufgezeigt werden, wie man auch ohne SIEM eine Anfrage an viele unterschiedliche Systeme gleichzeitig stellen kann.

Fazit

Es ist bedauerlich, dass die Arbeitslast der Experten zunimmt, während sie sich um immer mehr Systeme kümmern müssen und die Anzahl der Kunden kontinuierlich wächst. Um mit dem steigenden Anruf- und E-Mail-Aufkommen Schritt zu halten und die Kundenaufträge rechtzeitig zu erledigen, greifen die Experten manchmal zu Abkürzungen.

Es wäre zweifellos effizienter, den verschiedenen Teams Zugriff auf die Daten zu gewähren, auf die sie als Administratoren der Systeme sowieso bereits Zugriff haben. Dadurch könnte nicht nur die Arbeitsbelastung der einzelnen Experten verringert werden, sondern auch die Effizienz und Transparenz erhöht werden.

Eine Neuorganisation der Unternehmensstruktur erscheint vernünftig. Leider neigen Führungskräfte oft dazu, Veränderungen zu scheuen. So werden beispielsweise in deutschen Ämtern weiterhin Papiere gestempelt, anstatt Zertifikate digital zu signieren.