Wazuh Upgrade Checkliste – Ubuntu AIO (Central Components)¶
Zweck: 1:1 Checkliste für Change-Tickets bei Wazuh Upgrades.
Verwendung: Diese Checkliste ist direkt in Change-Tickets zu kopieren und Schritt für Schritt abzuarbeiten.
Detaillierte Befehle: Siehe referenziertes Runbook: {{runbook_ref}}
WICHTIG: Fülle zuerst die Metadaten oben aus, bevor du mit der Checkliste beginnst!
Anleitung¶
- Vor Beginn: Trage alle Stammdaten im Metadaten-Block (oben) ein
- Während der Durchführung: Hake jeden Punkt ab (
[x]) sobald erledigt - Befehle: Verwende das Runbook für genaue Befehle - diese Checkliste ist zur Nachverfolgung, nicht für Copy/Paste von Commands
- Dokumentation: Füge Pre- und Post-Health Snapshots dem Change-Ticket bei
- Bei Problemen: Siehe Abschnitt E für Rollback-Entscheidungen
Diese Checkliste ist 1:1 für Change/Ticket gedacht.
Commands stehen im Runbook:{{runbook_ref}}
A) Stammdaten (vorab ausfüllen)¶
Operator (genau 1 auswählen): - [ ] David Dutler - [ ] Ivan Stricker
Kunde: {{customer}}
Infrastruktur: {{infrastructure}}
Change/Ticket: {{change_ticket}}
Wartungsfenster: {{maintenance_window_start}} – {{maintenance_window_end}} (Europe/Zurich)
Ist-/Zielversion: {{current_version}} → {{target_version}}
Snapshot/Backup-ID: {{snapshot_id}}
Guide: {{guide_ref}}
B) Pre-Go (No-Go Gates)¶
- Change freigegeben (approved)
- Kunde informiert (Downtime/Impact kommuniziert)
- Offiziellen Wazuh Upgrade Guide gelesen (Link)
- Interner versionsspezifischer Guide geprüft (siehe
upgrade-guides/<version>/) - Breaking Changes / besondere Schritte für Zielversion bekannt
- Voraussetzungen validiert (siehe Runbook Abschnitt "Voraussetzungen")
- Persistente Terminal-Session aktiv (
screenodertmuxgestartet) - Zugangsdaten/Credentials vorhanden und verifiziert:
- Indexer Admin-Credentials aus Secret-Store abgerufen (siehe
CUSTOMERS.md→secrets_ref) - Wazuh API-Credentials verfügbar
- SSH/Root-Zugang zum Zielsystem getestet
- Dashboard-Login-Credentials bekannt
- Indexer Admin-Credentials aus Secret-Store abgerufen (siehe
- System-Ressourcen geprüft (Disk < 85%, RAM verfügbar, No-Go wenn Disk > 90%)
- Wazuh APT-Repository aktiv (
/etc/apt/sources.list.d/wazuh.listgeprüft, nicht auskommentiert) - Netzwerk-Konnektivität zu Wazuh-Repositories bestätigt (
ping packages.wazuh.com) -
apt-get updateerfolgreich ausgeführt - Candidate-Versionen sind identisch (Indexer/Manager/Dashboard inkl. Patchlevel)
- VM/Volume-Snapshot erstellt (empfohlen) ODER Konfigurations-Backup erstellt
- Snapshot/Backup-ID dokumentiert (
snapshot_id) - Individuelle Konfigurationsanpassungen geprüft (siehe Runbook 2.2a)
- Falls Anpassungen vorhanden: Dokumentiert, welche nach Upgrade erneut anzuwenden sind
- Health Snapshot (Runbook Abschnitt 1) durchgeführt und im Ticket abgelegt
C) Ausführung (Guide-aligned)¶
C1) Controlled Stop¶
-
filebeatgestoppt -
wazuh-dashboardgestoppt
C2) Indexer Pre-Actions¶
- Security-Konfig Backup ausgeführt
- Shard Allocation =
primaries - Flush ausgeführt
-
wazuh-managergestoppt (insb. single-node indexer cluster)
C3) Indexer Upgrade¶
-
wazuh-indexergestoppt -
jvm.optionsgesichert (.old) - Paket
wazuh-indexeraktualisiert -
wazuh-indexergestartet und Status OK
C4) Indexer Post-Actions¶
-
indexer-security-init.shausgeführt (Security re-apply) -
_cat/nodesOK - Shard Allocation =
all
C5) Manager Upgrade¶
- Paket
wazuh-manageraktualisiert -
wazuh-managergestartet und Status OK -
ossec.logauf Errors geprüft (quick)
C6) Filebeat Update/Setup¶
- Wazuh Filebeat Module aktualisiert
-
wazuh-template.jsonzur Zielversion aktualisiert - Filebeat Paket aktualisiert
- Pipelines geladen (
filebeat setup --pipelines) - Index-Management geladen (
filebeat setup --index-management ...) -
filebeatläuft (Status OK)
C7) Dashboard Upgrade¶
- Dashboard Config gesichert (
opensearch_dashboards.yml.old) - Paket
wazuh-dashboardaktualisiert -
wazuh-dashboardläuft (Status OK)
D) Post-Go (Abnahme)¶
- Versionen verifiziert (alle Komponenten auf identischer Version)
- Services Health Check (alle Services aktiv und ohne Fehler)
- Funktionale Validierung (Cluster Health, Indices, Events)
- Health Snapshot (Runbook Abschnitt 1) erneut ausgeführt und im Ticket abgelegt
- Dashboard erreichbar (HTTPS)
- Login erfolgreich (mit korrekten Credentials)
- Datenfluss plausibel (neue Events kommen an / Testevent verifiziert)
- Keine kritischen Fehler in journalctl-Logs (Indexer/Manager/Dashboard/Filebeat)
- Alle Ports hören wie erwartet (1514, 1515, 55000, 9200, 5601)
- Wazuh APT-Repository nach Upgrade deaktiviert ODER Pakete auf "hold" gesetzt (Entscheidung dokumentiert)
- Abschlussmeldung an Kunde gesendet (Versionen + kurzer Health-Status)
- Change/Ticket sauber dokumentiert (Start/Ende, Findings, Abweichungen)
Dokumentation Check: - [ ] Pre-Upgrade Health Snapshot im Ticket - [ ] Post-Upgrade Health Snapshot im Ticket - [ ] Backup/Snapshot-ID dokumentiert - [ ] Upgrade-Zeitstempel (Start und Ende) dokumentiert - [ ] Zielversion erreicht und dokumentiert
E) Störung / Rollback Entscheidung¶
Dieser Abschnitt ist NUR auszufüllen, wenn ein Rollback durchgeführt wurde. Wenn das Upgrade erfolgreich war, überspringen Sie diesen Abschnitt und setzen Sie direkt bei Section F fort.
- Rollback wurde durchgeführt: JA / NEIN
Falls NEIN → Weiter mit Abschnitt F (kein Ausfüllen der folgenden Punkte erforderlich)
Falls JA, bitte ausfüllen:
Trigger für Rollback (zutreffende(s) ankreuzen): - [ ] Indexer nicht stabil (Crash/Red-Cluster) - [ ] Auth/TLS/Index Security nicht funktionsfähig - [ ] Datenfluss bricht nachhaltig (keine Events, Filebeat Errors) - [ ] Dashboard nicht erreichbar / keine Anmeldung möglich - [ ] Kritische Services starten nicht nach mehreren Versuchen - [ ] Upgrade-Zeitfenster wird überschritten - [ ] Performance-Degradation ist inakzeptabel
Rollback-Methode (eine auswählen): - [ ] VM/Volume-Snapshot Restore (empfohlen, siehe Runbook Abschnitt 10.1) - [ ] Paket-Downgrade (nur wenn Snapshot nicht verfügbar, siehe Runbook Abschnitt 10.2)
Nach Rollback: - [ ] Post-Rollback Health Snapshot erstellt und dokumentiert - [ ] Funktionalität bestätigt (Dashboard Login, Datenfluss) - [ ] Stakeholder über Rollback informiert - [ ] Grund für Rollback im Ticket dokumentiert
Post-Mortem und Follow-up: - [ ] Incident-Report erstellt (Root Cause / Prevention / Lessons Learned) - [ ] Follow-up Tasks erfasst (Hardening, Monitoring, Automatisierung) - [ ] Neuer Upgrade-Versuch geplant (mit Lessons Learned) - [ ] Bei Bedarf: Test-Upgrade in Staging-Umgebung vor erneutem Produktions-Upgrade
F) Troubleshooting-Referenz¶
Falls Probleme während des Upgrades auftreten, konsultieren Sie:
Runbook Abschnitt 11: Troubleshooting Guide
Häufige Probleme mit Lösungen: - Indexer startet nicht nach Upgrade - Manager startet nicht nach Upgrade - Dashboard nicht erreichbar - Filebeat läuft, aber keine Events im Indexer - Cluster Health = RED - Login am Dashboard funktioniert nicht - Version Conflicts oder Compatibility Issues
Notfall-Kommandos: Siehe Runbook Abschnitt 11 für kompletten Service-Neustart und Support-Log-Sammlung.
Checklisten-Version: 1.1 (aktualisiert Januar 2026) Änderungen: Erweiterte Validierungsschritte, detaillierte Rollback-Checks, Troubleshooting-Referenz