Keine neuen Alerts nach Upgrade von Ubuntu 20.04 auf 24.04
Bei einem geplanten Upgrade von Ubuntu 20.04 auf 24.04 haben wir erst die VM mit Snapshot bestückt und dann den ganz normalen Weg wie er überall beschrieben ist gewählt:
apt update && apt upgrade
do-release-upgrade
reboot
Geänderte Defaults nicht überschreiben lassen und Dienste neu starten lassen, kein großes Ding. Bei 22.04 kurz geprüft ob alle Dienste laufen und neue Logs in der UI erscheinen, alles wundert.
Kurze Absprache mit dem Kunden, ob wir gleich auf 24.04 gehen sollen, oder doch erst mal einen Woche warten. Kunde wünscht Upgrade, Mut kann man sich nicht kaufen, also los …
do-release-upgrade
reboot
Nach dem Neustart lief Wazuh, der Indexer, man konnte sich einloggen, aber es kamen keine neuen Logs an!
Wie geht man da vor?
- Wazuh-Indexer
tail -f /var/log/wazuh-indexer/wazuh-cluster.log
- Im Browser
Index Management -> Dev Tools -> GET _cluster/health
Wazuh
- tail -f /var/ossec/logs/alerts/alerts.json (wenn hier logs kommen funktioniert der Manager)
- tail -f /var/ossec/logs/ossec.log (Grobe Fehler sind hier zu suchen)
- /var/ossec/bin/wazuh-control restart (bevorzuge ich gegenüber systemctl, da hier mehr auf der Console kommt)
Filebeat
- tail -f /var/log/syslog | grep -v opensearch (Dashboard loggt hier auch)
- filebeat test output (hier sollte alles grün sein)
In unserem Fall keine groben Fehler, ein paar alte Monitoring und Statistics Indexe gelöscht und etwas mehr Speicher spendiert, da low und high watermark im Opensearch gerissen wurden, war aber auch nicht die Lösung.
Alles lief, keine Fehler, stiller Betrieb, zu still. Das System generiert 30 Millionen Events am Tag, da wir das Update erst am Nachmittag machten, war alerts.log und alerts.json bereits 40GB groß! Also haben wir die Logs verschoben und Manager neu gestartet. Wieder keine neuen Logs, aber die Dateien waren mit ihrer alten Größe wieder da! Im Unterordner /2025/Jul lagen sie ebenfalls mit ossec-alerts-16.json und werden beim Neustart reinkopiert. Auch diese Dateien gelöscht, neu gestartet und schon lief alles wieder.
Wazuh hat einfach zu lang gebraucht und das File zu lesen, oder wir waren einfach zu ungeduldig! 🙂
Quelle
Dieser Artikel stammt aus dem Wazuh-Blog von m.a.x. it (veröffentlicht am 16. Juli 2025).
Unterstützung von m.a.x. it
Bei Einführung, Betrieb und Feintuning von Wazuh (SIEM) unterstützt Sie m.a.x. it mit SIEM-Services auf Open-Source-Basis.
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
