Comment sécuriser un nouveau VPS : les dix premières minutes

Un nouveau serveur n'est jamais aussi exposé qu'à l'instant où il reçoit une adresse IP. Des scanners automatisés balaient en continu la totalité de l'espace IPv4, si bien que les premières tentatives de connexion contre une machine déployée depuis une minute arrivent en général avant même que vous ayez fini de lire son message de bienvenue. Rien de tout cela ne vous vise personnellement — c'est du bruit de fond — et c'est justement ce qui fait qu'un serveur non durci avec un mot de passe sur root est compromis en quelques heures plutôt qu'en plusieurs mois. La bonne nouvelle, c'est que le refermer est un travail rapide : dix minutes d'étapes dans le bon ordre suppriment l'essentiel du risque opportuniste. Ce guide couvre cette checklist, l'ordre qui évite de vous retrouver enfermé dehors, et une chose que la plupart des tutoriels de durcissement ne mentionnent jamais — les détails personnels qu'une configuration par défaut inscrit discrètement sur une machine que vous avez louée précisément pour qu'elle ne soit pas reliée à vous.

Ce que le durcissement protège réellement

Le durcissement vaut la peine d'être fait précisément parce que ses bénéfices sont étroits mais réels. Être au clair sur cette limite évite un faux sentiment de sécurité dans les zones qu'il ne couvre pas.

• Il élimine entièrement l'attaquant opportuniste. Les bots de credential stuffing, la force brute SSH et les scans de panneaux d'administration exposés échouent tous face à une authentification par clé uniquement et à un pare-feu qui refuse tout par défaut.
• Il limite le rayon d'impact quand quelque chose que vous faites tourner présente une faille. Un service lié à localhost derrière un port fermé ne peut être atteint par un inconnu, même le jour où sa CVE est publiée.
• Il réduit le coût d'une erreur. Utilisateurs non privilégiés, clés séparées et correctifs automatiques font qu'une seule mauvaise décision ne livre pas toute la machine.
• Il ne cache pas le serveur à votre hébergeur. Quiconque a accès à l'hyperviseur peut en principe lire la mémoire d'une machine en fonctionnement — une question qui concerne l'hébergeur chez qui vous louez, pas vos règles de pare-feu.
• Il ne vous rend pas anonyme. Le durcissement protège la machine ; le fait qu'elle soit rattachée à votre nom se décide à l'inscription et au paiement, bien avant votre première connexion.

Cette dernière distinction est celle que l'on inverse le plus souvent. Un serveur parfaitement durci acheté avec une carte bancaire à votre nom légal reste un serveur à votre nom légal. Les deux couches sont complémentaires : l'hébergement sans KYC et un solde alimenté en cryptomonnaie décident à qui la machine appartient sur le papier, et les dix minutes ci-dessous décident qui peut y entrer.

L'ordre qui évite de vous enfermer dehors

Presque toutes les histoires d'horreur du durcissement racontent la même chose : quelqu'un a désactivé l'authentification par mot de passe avant de confirmer que sa clé fonctionnait, ou a activé un pare-feu dont les règles n'incluaient pas SSH, et s'est retrouvé enfermé dehors d'une machine qu'il ne pouvait plus joindre. L'ordre des étapes existe pour rendre cela impossible. Installez d'abord la clé et prouvez qu'elle fonctionne depuis une seconde fenêtre. Ce n'est qu'ensuite que vous désactivez les mots de passe. Ajoutez la règle de pare-feu pour SSH avant d'activer le pare-feu, jamais après.

Il vaut aussi la peine de connaître votre chemin de secours avant d'en avoir besoin. Un VPS que vous ne pouvez joindre que par SSH n'a qu'une seule porte, donc la console de votre espace client est la solution de repli qui transforme un enfermement dehors en simple désagrément plutôt qu'en reconstruction complète. Vérifiez que vous pouvez l'ouvrir pendant que tout fonctionne encore.

Étape par étape : les dix premières minutes sur une nouvelle machine

1. 01Mettez à jour l'index des paquets et les paquets installésUne image fraîche est un instantané datant du moment où elle a été construite. La remettre à jour est l'action à plus forte valeur de toute la liste, et cela prend moins d'une minute.
2. 02Créez un utilisateur non privilégié avec sudoTravailler en permanence en root signifie que chaque faute de frappe et chaque processus s'exécute avec l'autorité complète. Mettez en place un utilisateur normal, ajoutez-le au groupe sudo ou wheel, et utilisez celui-ci.
3. 03Copiez votre clé publique vers cet utilisateurGénérez une clé ed25519 sur votre propre machine si vous n'en avez pas, puis envoyez la moitié publique avec ssh-copy-id. La clé privée ne quitte jamais votre ordinateur portable.
4. 04Ouvrez un second terminal et confirmez que la connexion par clé fonctionneNe sautez pas cette étape. Connectez-vous en tant que nouvel utilisateur avec la clé, dans une nouvelle fenêtre, avant de changer quoi que ce soit à l'authentification.
5. 05Désactivez l'authentification par mot de passe et la connexion rootDéfinissez PasswordAuthentication no et PermitRootLogin prohibit-password, puis rechargez sshd. La force brute contre la machine n'a désormais plus rien à deviner.
6. 06Activez un pare-feu qui refuse tout par défaut, avec SSH autoriséRefusez tout le trafic entrant, autorisez votre port SSH, puis activez le pare-feu. Ajoutez ensuite les ports dont vos propres services ont besoin, un par un.
7. 07Activez les mises à jour de sécurité automatiquesunattended-upgrades sur Debian et Ubuntu, dnf-automatic sur la famille RHEL. C'est ce qui garde la machine sûre au sixième mois, quand vous avez cessé d'y prêter attention.
8. 08Listez ce qui écoute et fermez ce qui ne devrait pas l'êtreUn simple ss -tulpn indique chaque socket ouvert. Tout ce que vous n'avez pas placé là délibérément doit être supprimé ou lié à localhost.

SSH : uniquement des clés, et les réglages qui comptent

L'authentification par clé publique constitue à elle seule tout le durcissement de SSH. Une fois les mots de passe désactivés, un attaquant a besoin d'une clé privée qu'il ne possède pas, et deviner ne lui en fournira jamais une. Générez des clés ed25519 — elles sont courtes, rapides, et c'est le standard moderne — et protégez la clé par une phrase de passe pour qu'un ordinateur portable volé ne devienne pas un serveur volé. Tout le reste dans sshd_config n'est que du raffinement au-dessus de cette seule décision.

• PasswordAuthentication no — le réglage qui met fin à la force brute. Vérifiez d'abord que votre clé fonctionne, dans une seconde session.
• PermitRootLogin prohibit-password — root reste joignable par clé pour la récupération, mais jamais par mot de passe. Passez-le à no une fois votre utilisateur sudo validé.
• AllowUsers ou AllowGroups — une liste blanche explicite de qui a le droit de se connecter, afin qu'un compte de service créé par un paquet quelconque ne puisse jamais devenir un point d'entrée SSH.
• KbdInteractiveAuthentication no — ferme l'autre chemin interactif qui peut discrètement réactiver les invites de mot de passe sur certaines distributions.
• Une seconde clé pour un second appareil, plutôt que de copier une seule clé privée un peu partout. Perdre un téléphone devrait signifier retirer une ligne d'authorized_keys, pas tout régénérer.
• Déplacer SSH hors du port 22 réduit drastiquement le volume de vos journaux, mais traitez cela comme une réduction du bruit plutôt que comme de la sécurité — cela ne change rien pour quiconque examine réellement votre IP.

Si vous voulez aller plus loin que les clés, l'arrangement le plus solide consiste à ne pas exposer SSH publiquement du tout : placez la machine derrière un tunnel WireGuard et filtrez le port 22 au pare-feu pour qu'il n'accepte que les connexions venant de l'adresse du tunnel. Cela transforme votre démon SSH en quelque chose que l'internet ne peut pas voir, ce qui vaut mieux que n'importe quelle quantité de durcissement de configuration sur un démon exposé.

Le pare-feu : tout refuser par défaut, puis n'ouvrir que ce que vous utilisez

Un pare-feu n'a de sens que si son comportement par défaut est de refuser. Tout autoriser puis bloquer les ports connus comme mauvais revient à faire les choses à l'envers : vous finissez par protéger les services dont vous vous êtes souvenu et par exposer ceux que vous avez oubliés. Refusez tout le trafic entrant, autorisez le trafic sortant, puis ouvrez les ports un par un à mesure que vous déployez ce qui en a besoin. Le Linux moderne utilise nftables en dessous, et ufw ou firewalld en sont des interfaces tout à fait valables — l'outil compte beaucoup moins que le comportement par défaut.

• Autorisez SSH avant d'activer le pare-feu, pas après. C'est la deuxième façon la plus courante de vous enfermer dehors.
• N'ouvrez que les ports dont un service a réellement besoin depuis l'extérieur. Un serveur web veut les ports 80 et 443 ; une base de données ne veut presque jamais rien.
• Liez les services purement locaux à 127.0.0.1 plutôt qu'à 0.0.0.0. Un port fermé et un service qui n'écoute jamais publiquement sont deux protections indépendantes, et vous voulez les deux.
• Écrivez des règles IPv6 en plus des règles IPv4. Un jeu de règles qui ne couvre que l'IPv4 sur une machine en double pile laisse le même service grand ouvert sur son adresse IPv6.
• Restreignez les ports d'administration par adresse source lorsque c'est possible. Si l'administration provient toujours d'un seul point de terminaison VPN, précisez-le dans la règle.
• Relisez les règles après avoir ajouté un service. Les ports ouverts pour quelque chose que vous avez depuis supprimé forment l'accumulation silencieuse qui défait un départ propre.

Certaines charges de travail inversent la logique et ont besoin, volontairement, d'un port grand ouvert — un relais Tor doit accepter des connexions venant de n'importe où, et un nœud Bitcoin complet ne sert des pairs que si le port 8333 est joignable. C'est très bien ainsi. La règle n'est pas « ne rien ouvrir », c'est « ouvrir délibérément », et un service conçu pour être public est un choix délibéré.

fail2ban, et pourquoi il compte moins que vous ne le pensez

fail2ban surveille vos journaux et bannit les adresses qui échouent à s'authentifier de façon répétée. C'est réellement utile, mais il vaut la peine d'être honnête sur ce qu'il fait une fois que vous avez déjà désactivé l'authentification par mot de passe : à ce stade, personne ne peut réussir en devinant, donc fail2ban n'empêche plus une intrusion. Ce qu'il évite, ce sont des milliers de lignes de journal inutiles par jour, le CPU que consomment ces tentatives de connexion, et le risque qu'un événement réel se noie dans un bruit que vous avez cessé de lire depuis des mois.

Cela reste dix secondes de configuration qui en valent la peine, et cela devient réellement protecteur dès que vous faites tourner quelque chose qui accepte un mot de passe — la connexion d'une application web, un serveur de messagerie, un panneau de contrôle. Pointez-le vers ces journaux plutôt que vers sshd uniquement. Réglez la fenêtre de bannissement en heures plutôt qu'en minutes, et ajoutez votre propre adresse à la liste d'exclusion pour qu'un mot de passe mal tapé ne vous enferme pas dehors de votre propre machine.

Des mises à jour dont vous n'avez pas à vous souvenir

La menace réaliste pour un serveur bien configuré n'est pas quelqu'un qui vient à bout de vos clés SSH. C'est une vulnérabilité publiée pour quelque chose que vous avez installé puis oublié, exploitée par un scanner trois jours plus tard pendant que vous vous occupiez d'autre chose. Les mises à jour de sécurité automatiques sont la réponse : sur Debian ou Ubuntu, il s'agit d'unattended-upgrades configuré pour installer uniquement les correctifs de sécurité ; sur Fedora, Rocky ou Alma, c'est dnf-automatic. Activez-les pendant les dix premières minutes, et la machine continue d'appliquer ses propres correctifs longtemps après que votre attention s'est portée ailleurs.

Les mises à jour du noyau et de la libc sont l'exception qui a encore besoin de vous : elles ne prennent effet qu'après un redémarrage, donc un serveur actif depuis quatre cents jours fait presque certainement tourner du code corrigé sur le disque depuis un an. needrestart, sur Debian, vous indique quels services tournent encore contre des bibliothèques supprimées, et une fenêtre de redémarrage planifiée — même mensuelle — fait toute la différence entre des correctifs installés et des correctifs réellement appliqués. Tout ce que vous faites tourner devrait de toute façon survivre à un redémarrage inattendu ; si ce n'est pas le cas, c'est un problème distinct qui mérite d'être corrigé.

Les fuites d'identité qu'une checklist de durcissement ne voit pas

C'est la section qui compte si vous avez délibérément choisi un hébergeur offshore et sans KYC. Un guide de durcissement standard est écrit pour un serveur d'entreprise dont le propriétaire est de notoriété publique, donc il ne se demande jamais ce que la configuration par défaut inscrit à votre sujet. Sur une machine louée anonymement, plusieurs de ces réglages par défaut y rattachent discrètement votre nom.

• Votre clé publique SSH porte un commentaire — par défaut votre nom d'utilisateur local et le nom d'hôte de votre ordinateur portable, quelque chose comme alex@alex-macbook — et ce commentaire est stocké tel quel dans authorized_keys sur le serveur. Définissez-le avec l'option -C au moment de générer la clé, ou modifiez la ligne après l'avoir copiée.
• Le nom d'hôte que vous choisissez pour le serveur se retrouve dans les journaux, dans les en-têtes de mail, dans les sorties de supervision et parfois dans les bannières de service. Un nom d'hôte générique ne révèle rien ; votre nom ou celui de votre entreprise, si.
• Le fuseau horaire du système. Les images cloud utilisent UTC par défaut, ce qui ne dit rien à personne. Le régler sur votre fuseau local restreint la zone où vous vous trouvez, et les horodatages de chaque journal confirment ensuite vos heures de travail.
• La configuration Git copiée sur la machine, qui porte le nom et l'adresse e-mail sous lesquels vous commitez. C'est aussi le cas des fichiers d'historique de shell, des dotfiles synchronisés depuis votre poste de travail, et de tout identifiant mis en cache lors d'un test fait à la hâte.
• L'adresse e-mail que vous fournissez à Let's Encrypt lors de l'émission d'un certificat, qui devient partie du registre public de ce certificat. Utilisez une adresse qui n'est pas liée à votre identité.
• Les bannières de version du serveur web et les en-têtes X-Powered-By, plus tout outil d'analytics, de crash reporting ou de supervision fournisseur qui communique vers l'extérieur depuis la machine, avec un identifiant de compte associé.

Il vaut la peine de garder ces couches bien distinctes. Le durcissement tient les inconnus à l'écart de la machine. Ces détails empêchent la machine de vous décrire à qui l'examine déjà. Et la couche de paiement décide s'il y a jamais eu un nom à trouver — un sujet traité honnêtement dans si acheter un VPS en Bitcoin est vraiment anonyme, et poussé plus loin par une recharge en Monero. Chaque couche échoue prise isolément ; ensemble, elles tiennent.

Les sauvegardes : ce que le durcissement ne peut pas faire pour vous

Aucune règle de pare-feu ne protège contre une base de données supprimée, un disque défaillant ou un changement de configuration qui semblait raisonnable sur le moment. Les sauvegardes sont le seul mécanisme qui vous permette de récupérer de vos propres erreurs, ce qui est statistiquement la façon la plus probable de perdre des données sur une machine par ailleurs bien sécurisée. Chiffrez-les avant qu'elles ne quittent le serveur, gardez-en au moins une copie quelque part que le serveur lui-même ne peut pas atteindre, et faites-les tourner sur une planification plutôt que quand vous y pensez.

Ce dernier point compte plus qu'il n'y paraît : un processus de sauvegarde que le serveur peut écraser est une sauvegarde que tout ce qui a root sur le serveur peut détruire. Pousser des archives chiffrées vers un serveur de stockage séparé — ou les y récupérer depuis celui-ci, afin que les identifiants vivent en dehors de la machine sauvegardée — vous donne une copie qui survit à la machine. Et faites la restauration une fois, délibérément, pendant que tout va bien. Une sauvegarde non testée est une hypothèse, pas un filet de sécurité.

Les erreurs qui défont discrètement le travail

• Désactiver l'authentification par mot de passe avant de tester la clé, puis découvrir l'erreur depuis un ordinateur portable qui ne peut plus se connecter.
• Activer le pare-feu avant d'autoriser SSH — le même enfermement dehors, atteint depuis l'autre direction.
• N'écrire que des règles IPv4, et laisser chaque service joignable sur l'adresse IPv6 de la machine.
• Durcir soigneusement le premier jour, puis installer un panneau de contrôle, une base de données et une stack de supervision qui ouvrent chacun leur propre port sans qu'on le leur ait demandé.
• Tout faire tourner en root parce que c'est un sudo de moins à taper, si bien que la première faille dans n'importe lequel de ces éléments devient une compromission complète.
• Traiter fail2ban comme un substitut aux clés, ce qui laisse tourner un jeu de devinette de mot de passe simplement plus lent.
• Supposer qu'un serveur loué peut être rendu privé vis-à-vis de son hébergeur en chiffrant le disque — le chiffrement intégral du disque protège un disque volé, pas une machine en fonctionnement.
• Ne jamais redémarrer, si bien que des mois de correctifs noyau installés dorment sur le disque pendant que l'ancien noyau continue de tourner.

Rien de tout cela n'est difficile, et rien de tout cela ne prend longtemps. Faites-le dans l'ordre, prouvez chaque étape depuis un second terminal avant de passer à la suivante, et la machine que vous avez déployée il y a quelques minutes cesse d'être une opportunité pour quiconque balaie l'espace d'adresses. Déployez ensuite ce que vous êtes réellement venu faire tourner — un site web, un nœud, un tunnel, un endpoint de modèle privé — sur une base que vous comprenez entièrement.