# Automatiser les correctifs de sécurité système sous Debian sans casser WordPress

> Surveiller manuellement chaque serveur d'un parc pour appliquer les correctifs noyau et système ne tient pas à l'échelle. Voici comment unattended-upgrades a été configuré, avec ses garde-fous.

- Auteur : Clément Hadrot
- Publié le : 2024-11-22
- Mis à jour le : 2024-11-22
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/automatiser-correctifs-securite-debian-sans-casser-wordpress/

## L’essentiel

- unattended-upgrades applique les correctifs de sécurité sans intervention manuelle
- Un redémarrage automatique mal encadré peut couper un serveur en pleine activité
- Exclure les paquets sensibles (PHP, MariaDB) de l'automatisation reste indispensable

Le parc compte 47 serveurs Debian répartis sur des projets clients variés. Historiquement, les correctifs de sécurité système (noyau, bibliothèques systèmes, OpenSSL) étaient appliqués manuellement lors de sessions de maintenance mensuelles, un rythme qui laissait une fenêtre de plusieurs semaines entre la publication d'une vulnérabilité critique et son correctif effectif sur certains serveurs, un délai jugé trop long au regard du volume croissant du parc.

Ce sujet ne traite volontairement pas de la sécurité applicative de WordPress lui-même (mises à jour de plugins, thèmes, cœur), déjà couverte par ailleurs, mais uniquement de la couche système sous-jacente : le noyau Linux, les bibliothèques partagées, les paquets Debian eux-mêmes. L'outil retenu pour automatiser cette couche a été `unattended-upgrades`, avec des garde-fous précis pour éviter qu'une mise à jour automatique ne casse un service en production.

## Ce qu'unattended-upgrades fait réellement

Ce paquet Debian officiel automatise l'application des mises à jour issues des dépôts de sécurité, en s'exécutant périodiquement (généralement via un timer systemd ou une tâche cron dédiée) pour vérifier, télécharger et installer les correctifs disponibles, sans intervention manuelle, tout en respectant une configuration précise des dépôts autorisés.

```
// /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
};

Unattended-Upgrade::Package-Blacklist {
    "php8.2*";
    "mariadb-server*";
    "nginx*";
};

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:30";
```

La liste `Allowed-Origins` restreint volontairement l'automatisation aux seuls dépôts de sécurité officiels, excluant les mises à jour de fonctionnalités qui pourraient introduire des changements de comportement non désirés en production. La liste `Package-Blacklist` exclut explicitement les paquets sensibles dont une montée de version automatique pourrait casser une configuration existante ou introduire une incompatibilité avec le code applicatif.

## Pourquoi exclure PHP, MariaDB et nginx de l'automatisation

Ces trois paquets forment le socle direct sur lequel WordPress s'exécute, et une montée de version mineure automatique, même issue d'un dépôt de sécurité légitime, peut introduire des changements de comportement suffisants pour casser un plugin mal maintenu ou une configuration personnalisée. Leur mise à jour reste volontairement manuelle, planifiée et testée, jamais déléguée à l'automatisation nocturne.

| Composant | Automatisé | Raison |
| --- | --- | --- |
| Noyau Linux | Oui | Correctifs de sécurité critiques, faible risque de régression applicative |
| OpenSSL, bibliothèques système | Oui | Vulnérabilités souvent critiques (ex. type Heartbleed) |
| PHP, MariaDB, nginx | Non, exclus explicitement | Risque de régression applicative directe |

> L'essentiel à retenir : unattended-upgrades applique les correctifs de sécurité sans intervention manuelle ; Un redémarrage automatique mal encadré peut couper un serveur en pleine activité ; Exclure les paquets sensibles (PHP, MariaDB) de l'automatisation reste indispensable

## Le redémarrage automatique, à encadrer strictement

Certains correctifs de sécurité, notamment ceux touchant le noyau Linux, n'entrent en application qu'après un redémarrage complet du serveur. La directive `Automatic-Reboot` autorise ce redémarrage automatique, mais uniquement dans une fenêtre horaire précise (ici 4 h 30 du matin), choisie pour correspondre au trafic le plus faible observé sur l'ensemble du parc, jamais en pleine journée où un redémarrage couperait un site en pleine activité.

- La fenêtre de redémarrage doit être choisie en fonction du trafic réel de chaque serveur, pas d'une valeur générique copiée d'un tutoriel.
- Une notification par email est envoyée à chaque redémarrage automatique effectué, pour garder une trace consultable sans avoir à se connecter à chaque serveur individuellement.
- Sur les serveurs les plus critiques du parc, le redémarrage automatique reste désactivé : une alerte est envoyée à la place, laissant l'équipe planifier elle-même le moment du redémarrage.

## Le journal de vérification, indispensable pour la confiance

```
# Consulter le journal détaillé des dernières exécutions
cat /var/log/unattended-upgrades/unattended-upgrades.log

# Vérifier si un redémarrage est en attente
[ -f /var/run/reboot-required ] && echo "Redémarrage requis"
```

Sur ce parc, un script de supervision interroge quotidiennement l'existence du fichier `/var/run/reboot-required` sur chaque serveur, pour détecter les cas où un correctif nécessitant un redémarrage a été appliqué mais où le redémarrage automatique a été désactivé volontairement, évitant qu'un serveur reste des semaines avec un noyau à jour mais non actif faute de redémarrage effectif.

> Automatiser sans surveiller revient à déplacer le risque, pas à le supprimer : un correctif appliqué en silence qui casse un service un dimanche matin n'est pas moins grave qu'une négligence manuelle, juste plus difficile à tracer après coup.

## En résumé

Automatiser les correctifs de sécurité système sous Debian avec `unattended-upgrades` réduit sensiblement la fenêtre d'exposition aux vulnérabilités noyau et système sur un parc de serveurs, à condition d'exclure explicitement les paquets sensibles à WordPress (PHP, MariaDB, nginx) et d'encadrer strictement les redémarrages automatiques par une fenêtre horaire adaptée au trafic réel de chaque serveur. La sécurité applicative de WordPress lui-même reste un chantier distinct, jamais couvert par cette automatisation système.