Mises à jour de sécurité Ubuntu et Debian : automatiser sans casser la production

La plupart des attaques réussies n'utilisent pas de technique nouvelle. Elles exploitent une faille publiée, corrigée, et jamais installée. Garder un serveur à jour est la mesure de sécurité la moins chère qui soit, et pourtant c'est celle que les petites équipes repoussent le plus, par peur de casser la production.

Voici comment automatiser ce qui peut l'être, et garder un œil sur le reste.

Trois couches à maintenir à jour

Un serveur type comporte trois couches, et chacune se met à jour différemment :

Les mises à jour automatiques du système ne couvrent que la première couche, et une partie de la deuxième.

Couche 1 : mises à jour de sécurité automatiques

Sur Ubuntu et Debian, unattended-upgrades installe les correctifs de sécurité chaque jour :

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Gardez le réglage par défaut : uniquement les mises à jour de sécurité. Les mises à niveau fonctionnelles sont celles qui réservent des surprises.

Deux réglages à vérifier dans /etc/apt/apt.conf.d/50unattended-upgrades :

• Unattended-Upgrade::Mail pour recevoir un résumé ;
• Unattended-Upgrade::Automatic-Reboot, en général false en production, avec une fenêtre de redémarrage planifiée.

Le problème du redémarrage

Un noyau ou une libc corrigés ne sont actifs qu'après redémarrage du serveur (ou du service). Vérifiez si un redémarrage est en attente :

cat /var/run/reboot-required 2>/dev/null
sudo needrestart -r l

Prévoyez une fenêtre de maintenance hebdomadaire plutôt que de laisser les redémarrages s'accumuler pendant des mois.

Couche 2 : environnements et services

Les langages installés depuis des dépôts éditeurs ou à la main sont souvent oubliés. Une version de Node.js ou de PHP en fin de vie ne reçoit plus aucun correctif de sécurité.

Listez ce qui tourne et la version :

node -v; python3 --version; php -v; nginx -v; psql --version

Puis comparez avec les versions supportées publiées par chaque projet.

Couche 3 : dépendances applicatives

C'est là que commencent la plupart des piratages web : un framework ou une bibliothèque avec une CVE critique connue, déployé il y a des mois et jamais retouché. apt ne le mettra jamais à jour.

Chaque écosystème a sa commande d'audit (npm audit, pip-audit, composer audit), mais elles ne servent que si quelqu'un les lance, sur chaque serveur, régulièrement.

Une routine qui marche pour les petites équipes

1. Chaque jour : mises à jour de sécurité automatiques du système.
2. Chaque jour : contrôle des versions installées face aux bases publiques de failles, avec la version corrigée à installer.
3. Chaque semaine : une fenêtre de maintenance pour redémarrer ce qui doit l'être et mettre à jour les dépendances critiques.
4. Chaque mois : revue des environnements qui arrivent en fin de vie.

Automatiser l'étape 2

L'étape 2 est la plus difficile à faire à la main sur plusieurs serveurs. FounderMode compare chaque jour les paquets système et les dépendances npm, Python et PHP aux bases publiques de CVE, et indique dans son rapport du matin quoi mettre à jour et vers quelle version, avec les tentatives d'intrusion et la santé du serveur. Essai gratuit 14 jours.