Sécuriser un VPS Linux : ce que « durcir » veut vraiment dire.
Vous venez de provisionner un VPS chez Infomaniak, Exoscale, OVH ou Hetzner. Mauvaise nouvelle : il est déjà scanné. Bonne nouvelle : le durcir n'a rien de magique — mais ce n'est pas non plus une checklist qu'on coche une fois et qu'on oublie. Voici ce que recouvre un vrai hardening, sans la fausse sécurité des recettes copiées-collées.
01 · Un VPS par défaut est déjà une cible
Branchez une IP publique et, en quelques minutes, des bots automatisés la trouvent. Ils ne vous visent pas vous : ils balayent en continu l'ensemble d'Internet à la recherche de la même chose — un port SSH ouvert, un identifiant faible, un service connu non corrigé.
Un serveur fraîchement provisionné encaisse couramment des milliers de tentatives de connexion par jour sans que vous ayez communiqué son adresse à qui que ce soit. La plupart échouent. Il suffit qu'une réussisse : identifiant réutilisé, service oublié, faille non patchée. Le serveur rejoint alors un botnet, mine de la cryptomonnaie, relaie du spam ou sert de tremplin — souvent sans le moindre symptôme visible pendant des semaines.
02 · Ce que recouvre vraiment un durcissement
Le hardening n'est pas « changer le port SSH et installer fail2ban ». C'est une démarche cohérente sur plusieurs plans. Voici ce que chacun couvre — le quoi et le pourquoi, pas la recette.
Les accès
Authentification par clé plutôt que par mot de passe, désactivation de la connexion root directe, second facteur sur les accès sensibles, et un inventaire honnête de qui peut se connecter et avec quels droits. L'objectif : qu'un identifiant volé ne suffise jamais, à lui seul, à entrer.
La surface réseau
Un pare-feu en politique « tout fermé sauf ce qui est nécessaire », et la conscience exacte des services qui écoutent. Beaucoup de compromissions passent par un service que le propriétaire avait oublié d'exposer (une base de données, un panneau d'admin, un cache).
Le moindre privilège
Chaque service tourne avec le strict nécessaire, chaque humain avec le rôle juste suffisant. Quand quelque chose est compromis, le moindre privilège limite ce que l'attaquant peut atteindre depuis ce point d'appui.
Les mises à jour
Correctifs de sécurité appliqués vite et de façon fiable — y compris le noyau. Une CVE critique sur un service exposé se fait exploiter en masse dans les jours qui suivent sa publication. Le délai entre « correctif disponible » et « correctif appliqué » est une fenêtre d'attaque.
La détection comportementale
Au-delà du simple bannissement d'IP, des outils comme CrowdSec détectent des comportements d'attaque et partagent le signal. C'est la différence entre réagir à une signature connue et repérer une intrusion en cours.
Les logs et la supervision
Des logs centralisés, conservés, et surtout regardés. Un serveur qui journalise tout mais que personne ne surveille, c'est une caméra débranchée. La supervision (charge, trafic, intégrité des fichiers) est ce qui transforme « on s'en est rendu compte 6 mois plus tard » en « on a vu l'anomalie le jour même ».
Aucun de ces piliers n'est difficile pris isolément. La difficulté est de les tenir tous, ensemble, et dans la durée — sans casser ce qui tourne en production.
03 · Les erreurs qu'on voit le plus souvent
Sur les serveurs qu'on reprend après incident, ce sont presque toujours les mêmes :
- Le faux sentiment de sécurité du « port SSH changé ». Déplacer SSH sur un autre port arrête le bruit des bots, pas un attaquant qui scanne. Ça masque le problème sans le régler.
- Un pare-feu « configuré » mais permissif. Des règles ajoutées au fil du temps, jamais auditées, qui laissent finalement passer plus que prévu.
- Des mises à jour « quand j'y pense ». L'automatisation existe, mais sans reboot planifié ni suivi, le noyau reste vulnérable des mois.
- fail2ban mal réglé qui donne l'illusion de protéger alors qu'il ne couvre qu'un seul service.
- Des logs que personne ne lit. L'information de l'intrusion était là — non consultée.
- Le hardening one-shot. Durci une fois à l'installation, jamais retouché ensuite, pendant que la stack dérive et que de nouveaux services s'ajoutent.
04 · Le hardening n'est pas un one-shot
C'est le point que les guides oublient. Un serveur durci en janvier ne l'est plus en juin : de nouvelles CVE sortent, des services s'ajoutent, des règles temporaires deviennent permanentes, des accès accordés « pour dépanner » ne sont jamais révoqués. C'est ce qu'on appelle la dérive de configuration.
Un durcissement qui tient dans le temps suppose une configuration versionnée (on sait ce qui a changé, quand, et pourquoi), des mises à jour suivies, et une surveillance qui alerte quand l'état réel s'écarte de l'état voulu. C'est exactement la frontière entre un audit ponctuel et une protection continue.
05 · Où s'arrête un tutoriel
Un bon tutoriel vous emmène loin — l'essentiel des bases est documenté publiquement, et c'est tant mieux. Mais il vous laisse aussi avec les questions qui comptent le plus : votre configuration est-elle réellement cohérente, ou avez-vous empilé des recettes contradictoires ? Qu'est-ce qui écoute exactement sur vos interfaces, et pourquoi ? Sauriez-vous repérer une intrusion en cours, ou seulement après coup ?
C'est là qu'un regard extérieur a de la valeur : pas pour vous réciter ce qu'un blog dit déjà, mais pour valider l'état réel de votre serveur, identifier les écarts, et mettre en place ce qui le maintiendra durci au fil des mois.