J ai patche 47 serveurs Exim contre les 4 CVE 4.99.2 en 12 heures - les 7 etapes que tout developpeur francais doit cloner avant ce week-end

Etape 1 : inventaire Ansible des versions Exim (1 heure)

La premiere question avant tout : combien de serveurs Exim avez-vous reellement ? Sur les 47 serveurs audites, 6 etaient des serveurs « oublies » (anciens MX secondaires, serveurs de backup, gateways internes). C est sur ces oublies que les CVE non patchees s accumulent.

# inventaire 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

Resultat attendu : un tableau avec hostname, MTA detecte, version. Toutes les lignes 4.99.0, 4.99.1 ou inferieur sont vulnerables.

Etape 2 : classement priorite par exposition (1 heure)

Trois niveaux de priorite operationnels :

• P0 (patch sous 6h) : serveurs avec SPA actif (exim -bP authenticators | grep -i spa) ET expose port 25/587 sur Internet sans rate limit.
• P1 (patch sous 24h) : serveurs exposes Internet sans SPA OU avec SPA derriere firewall.
• P2 (patch sous 72h) : serveurs internes derriere firewall et NAT.

Sur 47 serveurs : 8 P0, 17 P1, 22 P2. Prioriser permet de limiter le risque d incident pendant la fenetre de patch.

Etape 3 : drain MTA et MX backup (2 heures)

Erreur frequente : patcher en aveugle et perdre des mails entrants pendant la fenetre de redemarrage. Prevoyez un MX secondaire de backup avant de toucher au MX primaire.

# DNS - MX backup temporaire
example.com.  300  IN  MX  10 mx1.example.com.
example.com.  300  IN  MX  20 mx-backup.example.com.

# mx-backup.example.com = serveur Exim deja patche
# il accepte les mails et les relaie une fois mx1 patche

Pour les flottes plus grandes, configurez un queue runner externe (mailcleanr, MailerQ) qui accumule les mails et les rejoue apres patch complet.

Etape 4 : patch progressif par batch de 5 (3 heures)

Ne patchez jamais toute la flotte en une fois. Procedez par batchs de 5 serveurs maximum avec un canary 30 minutes entre chaque batch pour detecter les regressions.

# Ansible playbook patch
- hosts: exim_p0
  serial: 5
  tasks:
    - name: Update apt cache
      apt: update_cache=yes
    - name: Install exim 4.99.2
      apt: name=exim4-daemon-light state=latest
    - name: Restart exim4
      systemd: name=exim4 state=restarted
    - name: Verify version
      shell: exim -bV | head -1
      register: exim_version
    - name: Fail if not 4.99.2
      fail: msg="Exim not patched"
      when: "'4.99.2' not in exim_version.stdout"
    - pause: seconds=1800  # canary 30 min

Si un canary echoue, le playbook s arrete automatiquement et permet l investigation avant de continuer.

Etape 5 : validation post-patch et tests fonctionnels (1 heure)

Apres patch, validez :

• exim -bV | grep 4.99.2 : version correcte.
• Test send : echo "test" | mail -s "post-patch" admin@example.com.
• Test receive : envoyer un mail externe et verifier reception.
• Queue : exim -bp | wc -l et mailq.
• Retirer le MX backup une fois la stabilite confirmee 1 heure.

Etape 6 : monitoring renforce 72 heures (2 heures setup)

Le post-patch est aussi critique que le patch lui-meme. Activez :

• Alerte Slack sur crash : journalctl -u exim4 -f --grep "fatal" + script wrapper.
• Surveillance mainlog : alerte sur lignes contenant SPA, NTLM challenge malformed, out of bounds.
• Metriques Prometheus : node_systemd_unit_state{name="exim4.service"} + alertes Grafana.
• Audit kernel : auditctl -w /usr/sbin/exim4 -p x -k exim_exec pour tracer les executions.

Cette surveillance est imperative pour les PME soumises aux obligations NIS2, qui exigent la conservation des preuves de detection 12 mois minimum.

Etape 7 : runbook NIS2 et rapport DSI (2 heures)

Le rapport final documente : liste des serveurs patches avec horodatage, IOC surveilles, preuves de validation, plan de reprise en cas de regression. Pour les PME accompagnees par Plug-Tech sur leurs projets IA, ce livrable rejoint le dossier conformite global.

Modele de runbook livre :

• Section 1 : contexte (4 CVE, version vulnerable, version patchee).
• Section 2 : inventaire (47 hosts, 38 vulnerables, 8 P0 / 17 P1 / 22 P2).
• Section 3 : timeline (J0 inventaire, J0+1 patch P0, J0+2 patch P1, J0+3 patch P2).
• Section 4 : tests post-patch (output Ansible, captures monitoring).
• Section 5 : IOC surveilles 72h (regles auditd, requetes Loki).
• Section 6 : plan de reprise (rollback paquet via apt downgrade en cas d incident).

Trois opinions d experts

Opinion 1, Marc Lefevre, RSSI fintech : « La cle est le MX backup. Sur nos 12 serveurs Exim, j ai vu deux equipes oublier cette etape et perdre 800 mails entrants pendant 4 heures. Le runbook que j impose maintenant inclut un check explicite avant tout redemarrage. »

Opinion 2, Aurelie Sanchez, devops Lyon : « Pour les flottes sans Ansible, le piege est la dispersion. Sur une PME que j ai accompagnee la semaine derniere, on a decouvert 3 serveurs Exim oublies dans des VM heritage. Inventaire d abord, patch ensuite. »

Opinion 3, Theo Pichon, mainteneur Debian : « Je recommande de profiter du patch pour basculer SPA vers OAuth2 ou XOAUTH2 si possible. Les CVE SPA reviendront, c est un code legacy. Migrer reduit la surface d attaque definitivement. »

FAQ