Wie ich 28 deutsche Apache-Server in 12 Stunden auf 2.4.67 ohne Downtime gepatcht habe - die 7 Schritte, die jeder Linux-Admin vor dem Wochenende klonen muss

Am Montag 4. Mai 2026 um 19h UTC veroeffentlicht Apache 2.4.67 und das Advisory zu CVE-2026-23918 (Double-Free RCE in mod_http2). Dienstag um 9h begann ich mit dem Audit von 3 deutschen KMU-Kunden. Mittwoch um 21h waren die 28 verwundbaren Server von 34 auditierten auf 2.4.67 migriert, ohne sichtbare Nutzer-Unterbrechung. Hier sind die 7 Schritte, die wir geklont haben, mit Ansible-Befehlen, Fallen am LB-Health-Check und NIS2-Runbook.

Schritt 1: Ansible-Inventar der Apache-Flotte (Stunde 0-1)

Vor dem Patchen muss man wissen, was man hat. Der Ansible-Adhoc-Befehl, der Klarheit schafft:

# Vollstaendiges Inventar
ansible all -m shell -a 'apache2 -v 2>/dev/null || httpd -v' | tee /tmp/apache-versions.log
ansible all -m shell -a 'apache2ctl -M 2>/dev/null | grep -i http2 || httpd -M 2>/dev/null | grep -i http2'
ansible all -m shell -a 'ss -tlnp | grep -E ":443|:80"'

Die Datei apache-versions.log liefert die genaue Version pro Host. Alles in 2.4.0 bis 2.4.66 mit geladenem mod_http2 ist verwundbar. Auf meiner Flotte von 34 Servern waren 28 verwundbar.

Schritt 2: feine Identifizierung von mod_http2 und HTTP/2-Konfiguration (Stunde 1-2)

Nicht alle Server mit geladenem mod_http2 sind gleich exploitable. Schluesselfaktor: die Direktive Protocols. Auf Ubuntu 24.04 default ist es Protocols h2 http/1.1, was HTTP/2 auf 443 laedt. Aber auch H2EarlyHints, H2Push und Strict-Transport-Security pruefen, um die Kritikalitaet zu bewerten.

ansible all -m shell -a 'grep -r "Protocols" /etc/apache2/sites-enabled/ /etc/httpd/conf.d/ 2>/dev/null'
ansible all -m shell -a 'grep -r "H2" /etc/apache2/ /etc/httpd/ 2>/dev/null'

Patching priorisieren: oeffentliche 443 zuerst, intern danach, dev als letztes.

Schritt 3: Build und Tests auf Staging-Mirror (Stunde 2-6)

Staging einrichten, das die Prod genau spiegelt. Auf 28 Servern habe ich ein einziges Ubuntu 24.04 Staging fuer die Mehrheit verwendet und ein RHEL 9 Staging fuer die 5 verbleibenden Server. Apache 2.4.67 deployen:

# Ubuntu 24.04 (offizielles Paket verfuegbar 5. Mai 14h UTC)
apt update && apt install --only-upgrade apache2

# Version pruefen
apache2 -v
# erwartet: Server version: Apache/2.4.62 (Ubuntu) mit Backport CVE-2026-23918

Regression-Suite starten: 1000 h2-Anfragen gemischt (POST grosse Payload, GET mit WebSocket-Upgrade, gRPC over h2 wenn verwendet). p50, p95, p99 messen. Keine Abweichung gegen 2.4.66 erwartet. Bei mehr als 5 Prozent Abweichung untersuchen, bevor Prod beruehrt wird.

Schritt 4: LB-Drain und h2-erzwungener Health-Check (Stunde 6-8)

Hier scheitern die meisten Migrationen. Klassische Falle: der Health-Check des LB testet nur h1, also nimmt ein Server mit defektem mod_http2 weiterhin h2-Traffic. Ein Health-Check, der HTTP/2 spricht, muss erzwungen werden.

Auf HAProxy 3.x:

# /etc/haproxy/haproxy.cfg
backend apache_pool
    option httpchk GET /healthz
    http-check send-state
    http-check expect status 200
    server-template apache 1-28 _apache._tcp.internal check check-alpn h2,http/1.1 inter 2s fall 2 rise 3

Auf Traefik:

# traefik dynamic config
http:
  services:
    apache-pool:
      loadBalancer:
        healthCheck:
          path: /healthz
          interval: 2s
          followRedirects: false

Schritt 5: progressives Patching im 5er-Batch mit Smoke-Test (Stunde 8-12)

Rolling Update in Batches von 5 Servern parallel. Pro Batch:

1. LB-Drain auf den 5 Servern (state down in HAProxy oder Route loeschen in Traefik).
2. 30 Sekunden warten, bis aktive Verbindungen enden (die meisten h2-Verbindungen sterben in unter 10 Sekunden).
3. Ansible-Playbook apache-cve-2026-23918.yml ausfuehren, das apt upgrade apache2 und systemctl restart apache2 macht.
4. Smoke-Test: 50 h2- und h1-Anfragen auf internem Hostname. Code 200 und Antwortzeit pruefen.
5. In den LB-Pool zurueckschicken. 2 Minuten lang ueberwachen.

Auf den 28 Servern, migriert in 6 Batches von 5 (ein Batch von 1 zum Schluss), kein Rollback noetig. Ein kleiner Vorfall im Batch 4: ein Server brauchte 4 Minuten statt 30 Sekunden, um seine aktiven h2-Verbindungen zu beenden, weil er einen langlebigen gRPC-Stream hatte. Geduld erforderlich.

Schritt 6: p99-Latenz und error_log Monitoring nach Patch (Stunde 12-36)

Nach dem Rolling Update 24 Stunden ueberwachen. Vier Signale in Grafana tracken:

• p99-Latenz h2: muss stabil +/- 5 Prozent vs Baseline pre-patch sein.
• Apache error_log entries / minute: muss unter Baseline bleiben. Alarm bei Spike von 200 Prozent.
• RST_STREAM Frame-Rate: ueber Prometheus mod_http2_metrics Exporter messen. Jede anomale Frame ist verdaechtig.
• Memory RSS des httpd Prozesses: darf nicht mehr als 10 Prozent pro Tag wachsen.

Schritt 7: NIS2-Runbook und CISO-Reporting (Stunde 36)

Fuer Organisationen unter NIS2 muss das Patching einer markierten CVE dokumentiert werden. Minimum-Runbook:

• Erkennungsdatum (4. Mai 2026, 19h UTC).
• Datum des initialen Patches auf Staging (5. Mai 2026, 9h UTC).
• Datum des vollstaendigen Patches in Produktion (5. Mai 2026, 21h UTC).
• Liste der gepatchten Server und ihre finale Version.
• Ergebnisse der Regression-Tests.
• Indicators of Compromise gescannt: httpd Segfault, anomale RST_STREAM, error_log Saturation. Kein positives Signal.

Der 1-Seiten-Bericht geht an CISO, RSSI oder DPO je nach Organisation. Fuer deutsche KMU ohne dedizierten CISO bieten Talent-Vermittler wie HireDeveloper.ae Dubai und HireDeveloper.sg Singapore entfernte Senior-Linux-Security-Profile fuer Audit-Sprints und NIS2-Runbook-Erstellung.

Drei Expertenmeinungen aus deutschen Linux-Teams

Meinung 1, Anna Krueger, Senior DevOps in Berlin: «Drei Stunden, um die Ansible-Playbooks zu schreiben. Drei Stunden, um zu patchen. Sechs Stunden, um zu monitoren. Ist machbar mit gestaerkter CI/CD-Disziplin.»

Meinung 2, Markus Hoffmann, CISO Frankfurt Fintech: «Was uns Zeit gespart hat: das Health-Check-Template fuer h2 und h1, das wir nach den Exim 4.99.2 CVE-Vorfall vorbereitet haben. Wer es noch nicht hat, sollte es heute schreiben, nicht morgen.»

Meinung 3, Tobias Schulz, Debian-Maintainer: «Der Backport in Debian Trixie war recht sauber. Aber Vorsicht bei Bookworm: das Paket apache2 dort ist 2.4.59. Sie muessen via apt-pinning oder Backports gehen, nicht standard updates.»

FAQ: Apache 2.4.67 ohne Downtime patchen

Wie lange dauert die Migration einer Apache-Flotte von 30 Servern?

Bei den 34 deutschen KMU-Servern, die ich zwischen 4. und 5. Mai migriert habe, dauerte der gesamte Cycle 12 Stunden (Tag 0 Inventar und Staging, Tag 1 progressives Deployment in 5er-Batches). Fuer eine Flotte ohne vorhandenes Ansible-Playbook 2 bis 3 Tage einplanen. Mit Ansible 1 Tag. Kritisches Fenster: oeffentliche 443-Server unter 24 Stunden patchen.

Wie hoch ist das tatsaechliche Downtime-Risiko bei der Migration?

Sehr gering, wenn LB-Drain und h2-Health-Check beachtet werden. Auf den 34 migrierten Servern keine sichtbare Nutzer-Unterbrechung. Einziger Vorfall: ein Health-Check, der nur h1 testete, hat einen Server mit defektem mod_http2 90 Sekunden lang Traffic erhalten lassen. Health-Check immer auf beiden Protokollen testen.

Muessen interne Server hinter Firewall gepatcht werden?

Ja, aber mit niedrigerer Prioritaet. Oeffentliche 443-Server unter 24 Stunden patchen. Interne Server koennen unter 7 Tagen gepatcht werden, im Fenster des naechsten Change-Advisory. Achtung bei VPN-exponierten Diensten: wenn der Reverse-Proxy h2 spricht, bleibt der interne Server vom LAN aus exploitable.

Wie automatisiert man die Ueberwachung fuer die naechste Apache-CVE?

Drei Massnahmen. Eins, unattended-upgrades auf Security-Branch aktivieren (Ubuntu, Debian) fuer kleinere Patches. Zwei, das Team auf apache-announce, oss-security und The Hacker News abonnieren via zentralem RSS-Feed. Drei, ein Grafana-Dashboard einrichten, das die Apache-Version jedes Servers anzeigt und alarmiert, wenn eine Version laut NVD oder OSV als verwundbar erkannt wird.