Mises à jour de sécurité automatiques sur VPS Debian/Ubuntu

Le cycle de vie d'une vulnérabilité est court. Entre la publication d'un CVE critique et les premières tentatives d'exploitation massives, la fenêtre se compte désormais en heures. Pour une agence qui administre dix, vingt ou cinquante VPS, attendre une intervention humaine planifiée chaque semaine revient à offrir plusieurs jours d'exposition sur chaque machine.

La réglementation renforce cette exigence. Le Cyber Resilience Act européen impose aux opérateurs de produits connectés de démontrer une politique de correctifs documentée et appliquée. Pour les agences qui hébergent des applications clients, l'absence de traçabilité des mises à jour peut engager leur responsabilité contractuelle en cas d'incident.

L'argument technique est simple : la majorité des compromissions de serveurs Linux exploitent des vulnérabilités pour lesquelles un patch est disponible depuis plus de 30 jours. L'outil unattended-upgrades, inclus dans les dépôts Debian et Ubuntu, installe automatiquement les correctifs de sécurité issus des dépôts officiels — sans toucher aux mises à jour de version majeure ni aux paquets que vous avez explicitement exclus.

unattended-upgrades est un démon Debian/Ubuntu qui s'exécute via un timer systemd (ou cron sur les systèmes plus anciens). Il interroge les dépôts APT configurés, filtre les paquets selon les origines autorisées définies dans sa configuration, puis installe les mises à jour sans interaction utilisateur.

La logique de filtrage repose sur les Release files APT. Chaque dépôt expose des métadonnées (Origin, Suite, Codename) que unattended-upgrades compare à sa liste blanche. Par défaut sur Ubuntu, seules les origines ${distro_id}:${distro_codename}-security sont activées — ce qui correspond exactement aux archives de sécurité officielles Canonical, sans inclure les mises à jour de backports ni les paquets tiers.

Le processus se déroule en trois phases : mise à jour du cache APT (apt-get update), résolution des dépendances pour les paquets éligibles, installation avec journalisation détaillée. En cas d'erreur (conflit de dépendance, paquet verrouillé, espace disque insuffisant), l'installation s'arrête et une notification peut être émise selon la configuration. L'intégrité du système n'est jamais compromise : unattended-upgrades ne force pas la résolution de conflits.

La configuration décrite dans cet article s'applique à Debian 11/12 et Ubuntu 22.04/24.04 LTS. Les systèmes plus anciens (Debian 10, Ubuntu 20.04) sont compatibles mais leur support amont approche de sa fin — une migration est recommandée avant d'investir dans leur configuration.

Accès requis : connexion SSH avec droits root ou compte sudo. Aucune dépendance externe n'est nécessaire pour le fonctionnement de base ; la configuration SMTP est optionnelle et n'intervient que pour les notifications par courriel.

Si vous gérez votre parc depuis Ansible, les étapes décrites ci-dessous peuvent être reproduites directement dans un rôle dédié — la structure des fichiers de configuration est stable entre les versions majeures de Debian et Ubuntu.

Les notifications courriel permettent à l'équipe de recevoir une alerte lorsqu'une mise à jour échoue ou lorsqu'un redémarrage est requis. Elles n'envoient rien en cas de succès silencieux — ce qui évite de saturer la boîte de réception avec des rapports quotidiens.

Dans /etc/apt/apt.conf.d/50unattended-upgrades, activez l'option :

Unattended-Upgrade::Mail "[email protected]";
Unattended-Upgrade::MailReport "only-on-error";

La valeur only-on-error (recommandée) n'envoie un courriel qu'en cas d'erreur. La valeur on-change envoie un courriel à chaque installation. La valeur always envoie un courriel même quand rien n'est installé — à éviter sur un parc de plusieurs dizaines de machines.

Pour que l'envoi fonctionne, le serveur doit disposer d'un MTA local capable de relayer les courriels. Sur un VPS minimal, postfix en mode satellite est l'option la plus légère :

apt-get install -y postfix
# Choisir "Satellite system" dans le wizard
# Renseigner le relais SMTP de votre fournisseur ou de votre infrastructure

Alternativement, msmtp peut servir de relais vers un service transactionnel (Mailgun, Postmark, SendGrid) sans installer un MTA complet.

Le redémarrage automatique après un patch noyau est la décision la plus délicate dans une politique de mises à jour. Il garantit que le correctif est actif immédiatement, mais il interrompt les services en cours — ce qui peut être inacceptable pour certaines charges de travail.

Dans /etc/apt/apt.conf.d/50unattended-upgrades, les options concernées :

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

Automatic-Reboot-Time planifie le redémarrage à une heure creuse. Automatic-Reboot-WithUsers "false" empêche le redémarrage si une session utilisateur est ouverte — utile pour les machines de développement, moins pertinent sur un serveur de production sans connexion interactive permanente.

Précautions indispensables avant d'activer cette option :
- Vérifiez que vos services se relancent automatiquement au démarrage (systemctl is-enabled <service>).
- Testez le temps de redémarrage complet sur un serveur de staging avant de déployer en production.
- Si votre application nécessite un ordre de démarrage précis (base de données avant applicatif), documentez et testez ce scénario.
- Pour un parc multi-VPS, échelonnez les horaires de redémarrage — voir la section suivante.

La configuration décrite jusqu'ici s'applique à un seul serveur. Pour un parc de dizaines de VPS clients, la reproductibilité et la coordination deviennent des enjeux à part entière.

Automatiser avec Ansible

Un rôle Ansible simple suffit à déployer la configuration sur l'ensemble du parc en quelques minutes. Stockez les fichiers 50unattended-upgrades et 20auto-upgrades dans templates/ et rendez les options de reboot configurables par variable d'inventaire :

- name: Déployer unattended-upgrades
  hosts: vps_clients
  become: true
  tasks:
    - name: Installer unattended-upgrades
      apt:
        name: [unattended-upgrades, apt-listchanges]
        state: present
        update_cache: true
    - name: Déployer la configuration
      template:
        src: 50unattended-upgrades.j2
        dest: /etc/apt/apt.conf.d/50unattended-upgrades
        owner: root
        mode: '0644'
    - name: Déployer apt-periodic
      copy:
        src: 20auto-upgrades
        dest: /etc/apt/apt.conf.d/20auto-upgrades
        owner: root
        mode: '0644'

Échelonner les redémarrages

Si le reboot automatique est activé, ne configurez pas la même heure sur tous vos serveurs. Un redémarrage simultané de 30 VPS peut générer une charge de reconnexion inhabituelle sur votre infrastructure et compliquer le diagnostic en cas de problème. Distribuez les horaires sur une plage de deux heures (02:00 à 04:00) en utilisant une variable Ansible par groupe ou par serveur.

Tester sur staging avant le parc de production

Pour les configurations qui activent le reboot automatique ou qui modifient la liste noire des paquets, validez d'abord sur un serveur de staging représentatif. Un VPS 99 DH/mois dédié aux tests de configuration évite de propager une erreur de configuration à l'ensemble du parc.

Centraliser les alertes

Plutôt que de recevoir des courriels individuels de chaque serveur, configurez un alias courriel qui agrège les alertes dans un canal de supervision unique. Si votre infrastructure utilise déjà un agrégateur de logs (Loki, OpenSearch), les fichiers de log unattended-upgrades peuvent y être acheminés via un agent léger pour une vue centralisée du parc.

Pour aller plus loin sur la sécurisation de vos VPS, consultez notre checklist de durcissement Linux et notre comparatif CrowdSec vs Fail2ban. Si vous gérez également des applications self-hosted, la routine de correctifs pour applications self-hosted complète cette approche avec les couches applicatives.