Vérifier un état, pas le reconstruire
Le durcissement initial d'un VPS se fait une fois, à la livraison : clés SSH, pare-feu, fail2ban, mises à jour automatiques. Notre checklist de durcissement le détaille déjà. Ici, on part du principe que tout cela existe et on se demande s'il tient encore. Un paquet resté en attente, un compte créé pour un prestataire et jamais supprimé, un port ouvert pour un test, un certificat dont le renouvellement échoue en silence : rien de cela ne se voit tant qu'on ne regarde pas. L'audit mensuel est donc une routine de contrôle, pas de configuration. Chaque contrôle produit une sortie, que vous archivez, et un statut vert, orange ou rouge dans le rapport du client. Un écart est noté, jamais corrigé sans accord.
Poser le périmètre avant le premier audit
Avant la première commande, fixez par écrit qui est responsable de quoi. Le VPS appartient-il au client ou à l'agence ? Qui détient le compte root, qui reçoit les alertes, qui décide d'un redémarrage ? Sans réponse, le premier écart trouvé devient un différend : l'agence a-t-elle le droit de corriger, le client a-t-il été prévenu ? Reprenez cinq points dans votre contrat ou votre bon de commande : les VPS couverts, la fréquence de l'audit, les accès accordés en lecture seule, le délai de réponse en cas d'écart rouge, et la liste des actions que l'agence peut faire seule, comme appliquer une mise à jour de sécurité, par opposition à celles qui exigent une validation du client, comme un redémarrage ou une suppression de compte.
À préparer une seule fois, avant d'auditer
- Un compte d'audit dédié — un utilisateur nominatif avec
sudolimité à la lecture des journaux et à l'inspection réseau, plutôt que root partagé. - Une liste attendue par VPS — ports qui doivent écouter, comptes autorisés, domaines servis, outil de sauvegarde et dépôt. Sans référence, un écart ne se distingue pas d'un fonctionnement normal.
- Un script de collecte en lecture seule — il enchaîne les commandes de la checklist et écrit tout dans un fichier daté, pour ne taper chaque commande qu'une fois.
- Un dossier d'archives par client — un sous-dossier par mois, conservé hors du VPS audité, pour pouvoir comparer les mois entre eux.
- Un modèle de rapport — le même gabarit pour tous les clients, rempli depuis les sorties collectées.
- Un calendrier — un jour fixe du mois par client, noté dans l'agenda de l'équipe, sinon l'audit saute dès le premier mois chargé.
Les sept contrôles, avec leur budget de temps
Mises à jour en attente (6 min)
sudo apt updateapt list --upgradable 2>/dev/nullapt list --upgradable 2>/dev/null | grep -i security
Isolez les paquets dont l'origine finit par-security: ils partent en priorité. Les autres passent par une validation humaine, car une montée de version majeure peut casser une application. Sur AlmaLinux ou RHEL,sudo dnf check-update --securityjoue le même rôle. Même avec les mises à jour automatiques activées, ce contrôle montre ce qui reste bloqué.Noyau et redémarrage en attente (4 min)
uname -rls /boot/vmlinuz-*ls /var/run/reboot-requiredsudo needrestart -b -r l
Si le noyau installé le plus récent diffère deuname -r, ou si/var/run/reboot-requiredexiste, un redémarrage est dû. Dans la sortie de needrestart, la ligneNEEDRESTART-KSTAdit si le noyau chargé est à jour, et la liste indique les services qui utilisent encore d'anciennes bibliothèques. Le redémarrage n'est jamais fait seul : il se planifie avec le client.Comptes et clés SSH (8 min)
awk -F: '$3>=1000' /etc/passwdgetent group sudosudo ssh-keygen -lf /home/<compte>/.ssh/authorized_keyslastlog | grep -v 'Never logged in'last -n 20
Chaque compte humain doit correspondre à une personne connue du client ou de l'agence. Chaque empreinte de clé doit appartenir à quelqu'un qui travaille encore sur le projet. Un compte jamais connecté depuis des mois, ou une clé inconnue, passe en orange et part au client pour validation.Ports ouverts (5 min)
sudo ss -tlnpsudo ss -ulnpsudo ufw status verbose
Rapprochez la liste de celle attendue pour ce VPS. Une base de données qui écoute sur toutes les interfaces au lieu de la boucle locale, un port de test oublié, un service inconnu : chaque écart est noté avec le processus qui l'ouvre, sans fermeture immédiate, car un service peut dépendre de ce port.Certificats (4 min)
openssl s_client -connect mondomaine.com:443 -servername mondomaine.com </dev/null 2>/dev/null | openssl x509 -noout -enddate
Lisez la date d'expiration sur le service réellement exposé, pas seulement la présence d'un timer de renouvellement : un timer actif peut échouer chaque nuit. Si le domaine passe par un CDN, cette commande lit le certificat du CDN. Pour l'origine, remplacez l'hôte de-connectpar l'adresse IP du VPS en gardant-servername.Sauvegardes restaurées (10 min)
restic snapshotsrestic restore latest --target /tmp/restauration-test --include /etc/nginx
Notez la date du dernier point de restauration, puis restaurez réellement un fichier ou une base dans un répertoire temporaire, et ouvrez-le. Une sauvegarde jamais restaurée n'est pas une preuve, c'est une hypothèse. Supprimez le répertoire temporaire ensuite. Si le client utilise un autre outil, la logique est identique : liste des points, restauration partielle, vérification du contenu.Journaux d'authentification (8 min)
sudo journalctl -u ssh --since '30 days ago' --no-pager | grep -c 'Failed password'sudo journalctl -u ssh --since '30 days ago' --no-pager | grep 'Accepted'sudo journalctl _COMM=sudo --since '30 days ago' --no-pager
Comptez les échecs, listez les connexions réussies et cherchez celles qui viennent d'une adresse inconnue. Relisez les usages desudo. Sur RHEL et dérivés, l'unité s'appellesshd, passsh.
Le budget de 45 minutes par VPS
Faites défiler le tableau
| Contrôle | Commande clé | Temps |
|---|---|---|
| Mises à jour en attente | `apt list --upgradable` | 6 min |
| Noyau et redémarrage | `needrestart -b -r l` | 4 min |
| Comptes et clés SSH | `ssh-keygen -lf authorized_keys` | 8 min |
| Ports ouverts | `ss -tlnp` | 5 min |
| Certificats | `openssl s_client` | 4 min |
| Sauvegardes restaurées | `restic restore` | 10 min |
| Journaux d'authentification | `journalctl -u ssh` | 8 min |
Un script de collecte plutôt que sept sessions à la main
La plus grande part des 45 minutes est de la lecture, pas de la frappe, à condition de ne pas retaper les commandes. Écrivez un script audit-vps qui lance les commandes des contrôles un à sept et redirige chaque sortie vers un fichier nommé d'après le client et la date, par exemple ~/audits/client-a/AAAA-MM/sortie-brute.txt. Il ne contient que des commandes de lecture : aucun apt upgrade, aucun systemctl restart, aucun rm. Lancez-le par SSH depuis votre poste, récupérez le fichier, puis lisez-le tranquillement. La restauration de sauvegarde reste la seule étape manuelle, parce qu'elle demande de juger si le contenu restauré est cohérent.
Archiver et comparer : c'est là que les dérives se voient
Un audit isolé donne une photographie, deux audits consécutifs donnent une tendance. Conservez la sortie brute de chaque mois, puis comparez-la à la précédente avec diff -u audit-precedent.txt audit-courant.txt. Un port qui apparaît, un compte en plus, un nombre d'échecs de connexion multiplié par dix, un point de restauration qui ne bouge plus : tous ces signaux ressortent en quelques lignes de différence, alors qu'ils sont invisibles dans une sortie lue seule. Archivez aussi le rapport remis au client. Le jour où celui-ci demande depuis quand un compte existait ou quand un correctif a été appliqué, la réponse est un fichier daté, pas un souvenir.
Le rapport d'une page remis au client
L'en-tête
Nom du client, identifiant du VPS, adresse IP, date de l'audit, nom de la personne qui l'a mené.
Le tableau des sept contrôles
Une ligne par contrôle avec un statut : vert si rien à signaler, orange si un écart demande une décision du client, rouge si une action urgente est nécessaire.
Les écarts constatés
Chaque écart en une phrase factuelle, avec la preuve : la ligne de sortie, le port, le compte concerné.
Les actions faites
Ce que l'agence a appliqué seule, dans le périmètre convenu, par exemple une mise à jour de sécurité.
Les actions à valider par le client
Redémarrage, suppression d'un compte, fermeture d'un port, avec le risque de ne rien faire.
La prochaine échéance
La date du prochain audit et, pour chaque écart orange ou rouge, une date limite de traitement.
Notez l'écart, ne le corrigez pas dans la foulée
Le réflexe de fermer le port ou de supprimer le compte suspect pendant l'audit est le plus coûteux : un service client tombe, et l'agence l'a décidé seule. Le rôle de l'audit est de rendre l'écart visible et daté. La correction suit le circuit de validation convenu au départ, y compris pour ce qui paraît évident.
Quand une sortie ne dit pas ce qu'elle semble dire
needrestartintrouvable — le paquet n'est pas installé par défaut partout. Installez-le une fois avec accord du client, ou comparez à la mainuname -ret les noyaux présents dans/boot.- Aucun échec SSH dans les journaux — vérifiez le nom de l'unité avant de conclure. Selon la distribution, l'authentification est journalisée sous
ssh,sshdou, sur les versions récentes d'OpenSSH,sshd-session. Testezsudo journalctl _COMM=sshd-session --since '30 days ago'. ss -tlnpn'affiche pas les processus — sanssudo, la colonne des processus reste vide pour les services des autres utilisateurs.- Un certificat valide alors que le site affiche une erreur — vous avez lu celui d'un CDN ou d'un autre vhost. Pointez l'adresse du VPS et passez le bon
-servername. resticdemande un mot de passe — le dépôt est chiffré. Récupérez le secret auprès du client avant l'audit, et non pendant, faute de quoi le contrôle saute.
L'objection du temps : 45 minutes par client, chaque mois
Vingt clients font quinze heures par mois, et l'objection est légitime. Trois leviers la réduisent. D'abord, le temps se mesure par VPS, pas par client : un client à un seul serveur coûte 45 minutes, et moins dès le deuxième mois, car les références attendues sont posées. Ensuite, le script collecte tout, vous ne faites que lire, et le rapport se remplit depuis un modèle. Enfin, comparez au coût d'un incident non détecté : un accès oublié ou une sauvegarde inutilisable se découvrent le jour de la panne, avec un client mécontent et une facture de remise en état. La routine coûte moins qu'un seul incident évitable.
Quand le portefeuille grandit
À dix VPS, la checklist tient dans une journée. À cinquante, la difficulté devient d'organisation : savoir quel client a quoi, quelles échéances tombent ce mois-ci, qui a été audité. L'espace agence de ServOrbit.com regroupe services et échéances de chaque client dans une seule interface, ce qui évite de maintenir un tableur parallèle. Si l'agence ne souhaite pas porter elle-même le socle système, l'option administration VPS existe et s'étudie à part. Ce guide est fourni tel quel, sans prise en charge : l'exécution de l'audit et la responsabilité envers le client restent les vôtres.
Pour aller plus loin
- Mettre en place le socle — /blog/linux-hardening-vps-checklist décrit le durcissement initial que cet audit vient vérifier.
- Automatiser les correctifs — /blog/securite-vps-mises-a-jour-automatiques-debian-ubuntu explique unattended-upgrades, dont le premier contrôle mesure les restes.
- Sauvegarder correctement — /blog/backup-vps-restic-s3-3-2-1 couvre la mise en place de Restic, dont le sixième contrôle vérifie la restauration.
- Surveiller en continu — /blog/alertes-disque-ram-vps-monitoring-proactif complète l'audit mensuel par des alertes entre deux passages.
- Inventorier les versions de PHP — /blog/inventaire-versions-php-parc-sites-clients-agence applique la même discipline au parc de sites.
- Réagir à une faille — les guides de correctif de la catégorie Sécurité et monitoring du blog montrent ce qu'un inventaire à jour permet de faire le jour J.
La documentation officielle
Options de apt : https://manpages.debian.org/stable/apt/apt.8.en.html
Projet needrestart : https://github.com/liske/needrestart
Mise à jour automatique sous Debian : https://wiki.debian.org/UnattendedUpgrades
Commande ss : https://man7.org/linux/man-pages/man8/ss.8.html
Commande openssl s_client : https://docs.openssl.org/master/man1/openssl-s_client/
Commande journalctl : https://www.freedesktop.org/software/systemd/man/latest/journalctl.html
Démon sshd : https://man.openbsd.org/sshd.8
Commande last : https://man7.org/linux/man-pages/man1/last.1.html
