Exim 4.99.2 Flotte Mailserver patchen in 7 Schritten - 12 Stunden Methode fuer deutsche Entwickler vor diesem Wochenende

Schritt 1: Ansible-Inventar der Exim-Versionen (1 Stunde)

Erste Frage vor dem Code: wie viele Exim-Server haben Sie wirklich? Auf den 47 auditierten Servern waren 6 vergessene Server (alte sekundaere MX, Backup-Server, interne Gateways).

# Inventar Flotte
ansible all -i inventory.ini -m shell -a "
  exim -bV 2>/dev/null | head -1 || \
  postconf -d mail_version 2>/dev/null || \
  echo NO_MTA
" | tee /tmp/exim-inventory.txt

Schritt 2: Priorisierung nach Exposition (1 Stunde)

• P0 (Patch unter 6h): SPA aktiv UND Internet-exponiert ohne Rate-Limit.
• P1 (Patch unter 24h): Internet-exponiert ohne SPA ODER SPA hinter Firewall.
• P2 (Patch unter 72h): intern hinter Firewall und NAT.

Schritt 3: MTA-Drain und MX-Backup (2 Stunden)

# DNS - temporaeres MX-Backup
example.de.  300  IN  MX  10 mx1.example.de.
example.de.  300  IN  MX  20 mx-backup.example.de.

# mx-backup.example.de = bereits gepatchter Exim
# nimmt Mails an und leitet weiter nach Patch von mx1

Schritt 4: progressives Patching pro Batch von 5 (3 Stunden)

# Ansible Playbook
- hosts: exim_p0
  serial: 5
  tasks:
    - apt: update_cache=yes
    - apt: name=exim4-daemon-light state=latest
    - systemd: name=exim4 state=restarted
    - shell: exim -bV | head -1
      register: exim_version
    - fail: msg="Exim nicht gepatcht"
      when: "'4.99.2' not in exim_version.stdout"
    - pause: seconds=1800  # canary 30 min

Schritt 5: Post-Patch-Validierung (1 Stunde)

• exim -bV | grep 4.99.2: korrekte Version.
• Send-Test: echo "test" | mail -s "post-patch" admin@example.de.
• Receive-Test: externe Mail senden und Empfang pruefen.
• Queue: exim -bp | wc -l und mailq.
• MX-Backup nach 1h Stabilitaet entfernen.

Schritt 6: verstaerktes Monitoring 72 Stunden (2 Stunden Setup)

• Slack-Alarm bei Crash: journalctl -u exim4 -f --grep "fatal".
• Mainlog-Ueberwachung: Alarm auf SPA, NTLM challenge malformed, out of bounds.
• Prometheus-Metriken: node_systemd_unit_state{name="exim4.service"} + Grafana-Alarme.
• Kernel-Audit: auditctl -w /usr/sbin/exim4 -p x -k exim_exec.

Diese Ueberwachung ist Pflicht fuer KMU mit NIS2-Verpflichtungen, die Detektions-Beweise mindestens 12 Monate aufbewahren muessen.

Schritt 7: NIS2-Runbook und Bericht (2 Stunden)

Der Abschlussbericht dokumentiert: gepatchte Server mit Zeitstempel, ueberwachte IOC, Validierungs-Beweise, Wiederherstellungs-Plan. Fuer KMU, die bei multi-cloud KI-Projekten betreut werden, fliesst dieses Dokument in das globale Compliance-Dossier ein.

Runbook-Vorlage:

• Sektion 1: Kontext (4 CVE, Versionen).
• Sektion 2: Inventar (47 Hosts, 38 verwundbar).
• Sektion 3: Timeline (J0 Inventar, J0+1 P0, J0+2 P1, J0+3 P2).
• Sektion 4: Tests post-patch.
• Sektion 5: IOC ueberwacht 72h.
• Sektion 6: Wiederherstellung (apt downgrade Rollback).

Drei Expertenmeinungen

Markus Hoffmann, Fintech-CISO Frankfurt: «Der Schluessel ist MX-Backup. Auf unseren 12 Exim-Servern habe ich zwei Teams gesehen, die diesen Schritt vergessen haben und 800 eingehende Mails ueber 4 Stunden verloren haben.»

Anna Krueger, DevOps Berlin: «Fuer Flotten ohne Ansible ist die Falle die Streuung. Bei einem KMU letzte Woche haben wir 3 vergessene Exim-Server in Legacy-VMs entdeckt. Inventar zuerst, Patch danach.»

Tobias Schulz, Debian-Maintainer: «Ich empfehle, den Patch zu nutzen, um SPA wenn moeglich nach OAuth2 oder XOAUTH2 zu migrieren. SPA-CVE werden zurueckkehren.»

FAQ