Skip to content

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

  1. Vor Beginn: Trage alle Stammdaten im Metadaten-Block (oben) ein
  2. Während der Durchführung: Hake jeden Punkt ab ([x]) sobald erledigt
  3. Befehle: Verwende das Runbook für genaue Befehle - diese Checkliste ist zur Nachverfolgung, nicht für Copy/Paste von Commands
  4. Dokumentation: Füge Pre- und Post-Health Snapshots dem Change-Ticket bei
  5. 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 (screen oder tmux gestartet)
  • Zugangsdaten/Credentials vorhanden und verifiziert:
    • Indexer Admin-Credentials aus Secret-Store abgerufen (siehe CUSTOMERS.mdsecrets_ref)
    • Wazuh API-Credentials verfügbar
    • SSH/Root-Zugang zum Zielsystem getestet
    • Dashboard-Login-Credentials bekannt
  • System-Ressourcen geprüft (Disk < 85%, RAM verfügbar, No-Go wenn Disk > 90%)
  • Wazuh APT-Repository aktiv (/etc/apt/sources.list.d/wazuh.list geprüft, nicht auskommentiert)
  • Netzwerk-Konnektivität zu Wazuh-Repositories bestätigt (ping packages.wazuh.com)
  • apt-get update erfolgreich 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

  • filebeat gestoppt
  • wazuh-dashboard gestoppt

C2) Indexer Pre-Actions

  • Security-Konfig Backup ausgeführt
  • Shard Allocation = primaries
  • Flush ausgeführt
  • wazuh-manager gestoppt (insb. single-node indexer cluster)

C3) Indexer Upgrade

  • wazuh-indexer gestoppt
  • jvm.options gesichert (.old)
  • Paket wazuh-indexer aktualisiert
  • wazuh-indexer gestartet und Status OK

C4) Indexer Post-Actions

  • indexer-security-init.sh ausgeführt (Security re-apply)
  • _cat/nodes OK
  • Shard Allocation = all

C5) Manager Upgrade

  • Paket wazuh-manager aktualisiert
  • wazuh-manager gestartet und Status OK
  • ossec.log auf Errors geprüft (quick)

C6) Filebeat Update/Setup

  • Wazuh Filebeat Module aktualisiert
  • wazuh-template.json zur Zielversion aktualisiert
  • Filebeat Paket aktualisiert
  • Pipelines geladen (filebeat setup --pipelines)
  • Index-Management geladen (filebeat setup --index-management ...)
  • filebeat läuft (Status OK)

C7) Dashboard Upgrade

  • Dashboard Config gesichert (opensearch_dashboards.yml.old)
  • Paket wazuh-dashboard aktualisiert
  • wazuh-dashboard lä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