SIEM

Mit wazuh Dateien beobachten

Angriffe in Logfiles erkennen und verhindern.

Michael Meister

23. Mai 2024 • 4 min read

Ich habe schon einiges über wazuh geschrieben. Manchmal will man jedoch mehr als nur den Standard. Und da ist die Flexibilität von wazuh extrem nützlich.

Auf meinen Webservern läuft traefik, aber auch sehr oft der nginx-proxy-manager als Reverse-Proxy. Wie schon in meinem Webserver-Blogbeitrag gegen Ende beschrieben, prüfe ich, mit welchem Hostname auf meinen Server zugegriffen wurde.

Wurde er einfach nur durch einen Scan gefunden und es wurde versucht eine Webseite von der IP meines Webservers abzurufen, antwortet der Reverse-Proxy nicht. Dies soll Angreifern vortäuschen, dass dort kein Webserver läuft. Meist ziehen sie dann weiter. Oder der Scan ist so schlecht programmiert, dass er blind weiter ins Leere fragt.

Mit solchen Clients möchte ich nichts zu tun haben. Doch wie kann ich ihre Zugriffe beenden?

Indizien

In welchen Dateien speichert zum Beispiel der nginx-proxy-manager die Zugriffe auf den Webserver?

Zu jeder angelegten Domäne entstehen hier Logfiles:

Die Default-Antwort wurde zwar mit No Response konfiguriert. Dennoch werden Zugriffsversuche im default-host_access.log vermerkt. Ein Eintrag in dieser Datei sieht zum Beispiel so aus:

164.92.181.220 - - [20/Apr/2024:13:54:04 +0000] "GET /password.php HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"

Man sieht deutlich, dass versucht wird password.php aufzurufen. Den Client mit der IP-Adresse, die man gleich zu Beginn des Logeintrags sieht, möchte ich möglichst schnell blockieren.

File-Monitoring mit dem wazuh-agent

Da ich nun weiß, in welcher Datei man erkennt, dass ein Angreifer böse Absichten verfolgt, kann ich diese beobachten lassen.

Auf dem Server kann ich in der Konfiguration des wazuh-Agents entsprechende Änderungen vornehmen. Bei dieser Gelegenheit kann ich auch gleich alle Web-Zugriffe auf den Server mit aufnehmen. Dazu füge ich /var/ossec/etc/ossec.conf folgende Zeilen hinzu:

<localfile>
  <location>/var/docker/web/nginx-proxy-manager/data/logs/*.log</location>
  <log_format>syslog</log_format>
</localfile>

Schließlich restarte ich noch den wazuh-agent, um die Änderung zu aktivieren:

systemctl restart wazuh-agent

Und schon sollten Events im Wazu-Server erscheinen:

Man kann auch hier wieder leicht die bösen Absichten erkennen. Ein Angreifer hat versucht .env auf dem Webserver zu lesen. Oft finden sich in dieser Datei Zugangsdaten.

Schauen wir uns an, welche wazuh-rule ausgelöst wurde:

Die Rule-ID 31101 gehört in die Gruppe der Web-Attacks:

Wenn wir diese Angreifer durch eine Firewall-Drop-Regel aussperren wollen, können wir das durch Anpassung der wazuh-Server Konfiguration in der Datei /var/ossec/etc/ossec.conf. Wir fügen folgenden Abschnitt hinzu:

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>31101</rules_id>
  <timeout>180</timeout>
</active-response>

Er sperrt Angreifer aus. Nach drei Minuten wird die Firewall-Regel auf dem Webserver wieder entfernt.

Auch hier starten wir den wazuh-manager neu, um die Änderung zu aktivieren:

systemctl restart wazuh-manager

Und schon sollten wir die Active-Responses sehen:

Dies ist ein gutes Beispiel für einen stupiden Scan, der selbst dann noch weiterläuft, obwohl der Server nicht antwortet.

Durch einen Klick auf data.scrip kann man sehen, welche Clients versuchen meinen Webserver anzugreifen.

Ein Klick auf Visualize erstellt ein Diagramm, dass man später auch einem Dashboard hinzufügen kann:

Fazit

Hat man die richtigen Mittel zur Hand, kann man die Sicherheit seines Unternehmens mit Leichtigkeit um ein weiteres Stück verbessern. Das Einzige, was ich verändern musste, war die Konfiguration des wazuh-Agents.

Die Zusammenarbeit der Server-Administratoren mit den Security-Experten ist ein wichtiger Baustein, wenn es um die Verbesserung der Unternehmenssicherheit geht. Sie wissen am besten, welche Dateien und Prozesse Auskunft über die Bedrohungslage geben.

Neue Indizien findet man als Security-Analyst beispielsweise durch Visualisierung verschiedener Parameter oder das immer weitere Herausfiltern all dessen, was man erwartet. So bleibt am Ende das übrig, was man nicht kennt. Diesen Vorgang nennt man auch Threat-Hunting. Hat man als Analyst vollen Zugriff auf das SIEM, kann man sich einfach temporäre Langzeitbeobachtungen einrichten und prüfen, ob sich diese Vermutungen bewahrheiten. Aus diesen Erkenntnissen lassen sich dann weitere Usecases bauen, die bei Eintreten eine sofortige Reaktion ermöglichen.