Un serveur se configure une fois, puis vit tout seul. Un mois plus tard, quelques paquets attendent d’être mis à jour, le certificat est arrivé à trois semaines de son échéance, une ligne de trop est apparue dans la configuration SSH après l’installation de quelque chose d’étranger, et la prison censée surveiller les connexions s’est arrêtée sans que personne le remarque. Rien de tout cela ne crie. Tout cesse simplement, en silence, d’être vrai.

Voici douze choses qu’il vaut la peine de vérifier régulièrement, avec les commandes. La tournée prend une quinzaine de minutes. L’ordre va de ce par quoi on entre vers ce qui casse tout seul.

SSH : cinq lignes

Ce qu’il faut regarder, ce n’est pas le fichier mais la configuration effective : elle s’assemble à partir de /etc/ssh/sshd_config, de tout le répertoire sshd_config.d et des valeurs par défaut de la compilation.

sudo sshd -T | grep -iE 'permitrootlogin|passwordauthentication|permitemptypasswords|maxauthtries|x11forwarding'

Ce que nous voulons voir : permitrootlogin no, passwordauthentication no, permitemptypasswords no, maxauthtries à 3–4 et x11forwarding no. Les trois premières sont la porte ; les deux dernières en sont les gonds — une limite de tentatives par connexion, et un renvoi graphique dont un serveur n’a aucun usage.

Deux réserves, deux façons faciles de s’enfermer dehors. D’abord : ne coupez pas la connexion par mot de passe ni la connexion root avant d’avoir vérifié que votre clé fonctionne — dans une session séparée, sans fermer la session courante. Si vous lisez ceci connecté en root par mot de passe, ces deux lignes vous mettront dehors, vous précisément.

Ensuite, l’ordre des fichiers. OpenSSH retient la première valeur rencontrée pour un paramètre, et les fichiers de sshd_config.d sont lus par ordre alphabétique. Les images cloud y déposent d’ordinaire un 50-cloud-init.conf, qui l’emportera sur votre propre fichier si vous l’avez nommé par exemple 90-hardening.conf. Vos réglages vont sous un numéro plus petit — 00- ou 10-. Et le résultat se vérifie avec sshd -T, pas en relisant le fichier.

Pare-feu : une vérification

sudo ufw status verbose

Il faut garder en tête que cette sortie montre des intentions, pas des résultats. Une règle peut figurer dans la liste sans rien fermer : UFW lui-même est désactivé, le port est servi par quelque chose que Docker a publié (il écrit ses propres règles dans iptables en dessous d’UFW), ou le trafic atteint le serveur par un autre chemin. Il vaut donc la peine de confronter la liste des règles à ce qui écoute réellement vers l’extérieur :

sudo ss -tulpn | grep -v '127.0.0.1\|::1'

fail2ban : deux vérifications

Il ne suffit pas que le service tourne — il faut aussi une prison qui fonctionne pour SSH :

sudo fail2ban-client status
sudo fail2ban-client status sshd

L’ennui le plus fréquent ici est une prison muette. Sur Debian 12 et les Ubuntu récentes, /var/log/auth.log peut ne pas exister du tout : rsyslog n’est pas installé et les enregistrements vivent uniquement dans journald. Une prison avec le logpath d’origine démarre alors, s’annonce active et ne bannit jamais personne. Le remède est de la brancher sur le journal systemd :

printf '[sshd]\nenabled = true\nbackend = systemd\n' | sudo tee /etc/fail2ban/jail.d/sshd-systemd.local
sudo systemctl restart fail2ban

Le signe qui permet de l’attraper sans fouiller les configurations : dans fail2ban-client status sshd, « Currently failed » et « Total failed » restent à zéro alors que le journal contient clairement des connexions ratées.

Mises à jour : trois vérifications

Séparément : combien de paquets attendent en tout, combien d’entre eux relèvent de la sécurité, et si le système réclame un redémarrage après une mise à jour du noyau.

sudo apt update
apt list --upgradable 2>/dev/null | grep -c -- '-security'
ls /var/run/reboot-required 2>/dev/null && echo 'redémarrage nécessaire'

La troisième vérification porte sur l’activation des mises à jour de sécurité automatiques, pour que les deux premières ne tournent pas au rituel mensuel :

systemctl status unattended-upgrades --no-pager
cat /etc/apt/apt.conf.d/20auto-upgrades

Ce fichier doit porter un 1 sur les deux lignes. Si le paquet manque : sudo apt install unattended-upgrades && sudo dpkg-reconfigure -plow unattended-upgrades.

Certificats : une vérification

Un certificat Let's Encrypt vit quatre-vingt-dix jours, et le renouvellement fonctionne tout seul jusqu’au jour précis où il ne fonctionne plus. Ce qu’il faut regarder n’est pas le panneau du registrar mais ce que le serveur sert réellement :

echo | openssl s_client -connect localhost:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate
sudo certbot renew --dry-run

La première commande donne la date de fin du certificat servi pour ce nom ; la seconde vérifie que le renouvellement passera, sans attendre la vraie échéance. Il vaut la peine de parcourir tous les noms que le serveur dessert, pas seulement le domaine principal : celui qu’on oublie, c’est le sous-domaine ajouté plus tard.

Disque : une vérification

df -h
df -i

Deux commandes, parce que l’espace et les enregistrements de fichiers s’épuisent indépendamment. Sur la plupart des serveurs, le second atteint son plafond en premier — des millions de petits fichiers dans les sessions PHP ou le cache applicatif donnent un IUse% à 100 avec des gigaoctets encore libres. Nous avons un article à part qui détaille les deux cas.

Ce qui cloche dans cette liste

La liste est juste, mais elle a une propriété : elle exige que quelqu’un y pense. Quinze minutes par semaine, ce n’est pas grand-chose, tant qu’il n’y a qu’un serveur et tant qu’il y a une raison. Au bout de deux mois tranquilles, la tournée saute, et l’on apprend que la prison s’est arrêtée par les logs de quelqu’un d’autre.

C’est pourquoi nous avons rassemblé exactement ces douze vérifications dans un panneau gratuit à part — Arcivéo FREE. Il s’installe en une commande, tourne sur votre propre serveur, ne nous envoie rien et ne demande aucune inscription. Un collecteur s’exécute via cron toutes les cinq minutes et écrit les mêmes choses dans une base locale : connexions SSH et connexions refusées, état d’UFW et de fail2ban, mises à jour de sécurité en attente, échéances des certificats, espace disque. L’historique couvre sept jours, l’interface existe en 34 langues. Le prix est nul, y compris sur un serveur professionnel : la licence autorise l’installation sur vos propres machines, celles de l’entreprise comprises, et n’autorise ni la revente ni l’exploitation comme service pour les serveurs d’autrui.

La pile de l’édition gratuite est modeste : elle installe et active UFW et fail2ban, puis se contente d’en montrer l’état. ModSecurity, Suricata, AIDE et les autres modules n’y sont pas, ils relèvent de la version payante. Mais pour cesser de porter la tournée hebdomadaire dans sa tête, elle suffit. À quoi ressemblent les mêmes données sur le panneau complet : voir les pages de démonstration ci-dessous.