Durcir un nouveau VPS : la première heure après déploiement

La première heure n'est pas optionnelle

L'espace IPv4 d'Internet est assez restreint pour qu'un inconnu bien équipé le scanne intégralement en quelques minutes, et un simple ordinateur portable en quelques heures. Les plages d'hébergement sont publiées, cataloguées et rescannées en permanence, donc une nouvelle adresse n'a rien de discret : c'est une entrée de plus dans une liste qui existe déjà. Dans les faits, la première tentative de connexion SSH automatisée sur une machine tout juste démarrée arrive bien avant que vous n'ayez fini de lire votre e-mail de bienvenue, et elle sera suivie de milliers d'autres venant de sources sans rapport entre elles, toutes essayant les mêmes quelques centaines de mots de passe sur les mêmes quelques noms d'utilisateur. Rien de tout cela ne vous vise personnellement. C'est une machine qui trie Internet entre répond et ne répond pas, et la seule chose qui décide dans quel tas vous atterrissez, c'est ce que vous avez fait pendant la première heure.

La bonne nouvelle, c'est que le travail est ennuyeux et fini. Quatre contrôles font presque tout : s'authentifier par clé plutôt que par mot de passe, refuser tout port entrant que vous ne servez pas délibérément, appliquer les mises à jour de sécurité sans qu'on ait à vous le demander et cesser d'opérer en root. Chacun prend quelques minutes et rien de tout cela n'a d'exotique. Ce qui justifie de le détailler spécifiquement pour un serveur offshore no-KYC, c'est l'asymétrie de l'autre côté : le chemin de récupération. Chez un hébergeur grand public, un sshd_config cassé se termine par un ticket de support, une vérification d'identité et une session console. Ici, il n'y a aucune identité enregistrée à vérifier, ce qui est tout l'intérêt du produit — et aussi la raison pour laquelle une frappe malheureuse vous coûte la machine plutôt que vingt minutes. Chaque étape ci-dessous est écrite en gardant cela à l'esprit.

Ce qui attaque réellement un petit serveur

Deux populations très différentes apparaissent dans les journaux, et il est utile de les distinguer, car elles ne se combattent pas de la même façon. L'écrasante majorité relève du scan de masse indiscriminé : des bots qui parcourent l'espace d'adressage à la recherche de SSH acceptant les mots de passe, de bases de données liées à 0.0.0.0, de panneaux d'administration aux identifiants par défaut, de copies de staging oubliées, d'applications web non patchées avec un exploit public. Cette population se moque de l'usage que vous faites de votre serveur. Elle ne raisonne pas, elle ne s'arrête jamais, et elle est intégralement mise en échec par la checklist de ce guide — non pas parce que la checklist est ingénieuse, mais parce que les bots cherchent les machines qui l'ont sautée, et il y en a beaucoup.

La seconde population est ciblée — quelqu'un qui veut précisément votre machine — et elle est rare, coûteuse, et ne passe presque jamais par SSH. Elle arrive par l'application que vous avez déployée, une dépendance que vous n'avez pas auditée, un identifiant réutilisé, ou un ordinateur portable compromis avant même d'avoir touché le serveur. C'est pourquoi le durcissement ne s'arrête pas au pare-feu : les vraies questions deviennent sous quel utilisateur tourne votre service, ce qu'il peut atteindre en sortie, et à quelle vitesse vous le patchez. Bon à savoir pendant que vous planifiez : nos plans VPS reposent sur une virtualisation complète KVM, donc vous faites tourner votre propre noyau et toute la boîte à outils — nftables, ufw, namespaces, seccomp, sysctl personnalisé — fonctionne réellement, ce qui n'est pas le cas des produits "VPS" à base de conteneurs, dont le noyau appartient à quelqu'un d'autre.

SSH : des clés, et une seule porte

L'authentification par mot de passe sur un port SSH public est de loin le plus grand risque auto-infligé sur un serveur loué, et la supprimer représente les cinq minutes les plus rentables de ce guide. Générez une paire de clés Ed25519 sur votre propre machine — jamais sur le serveur, où la moitié privée naîtrait sur l'hôte même que vous essayez de protéger — protégez-la par une phrase de passe, et chargez-la dans un agent pour que cette phrase de passe ne vous coûte qu'une invite par session plutôt qu'une par connexion. Copiez la moitié publique sur le serveur, vérifiez que ça fonctionne, et alors seulement désactivez les mots de passe. Une fois PasswordAuthentication no et KbdInteractiveAuthentication no en place, les milliers de tentatives quotidiennes cessent d'être un risque pour devenir du simple bruit : il n'y a pas de mot de passe à deviner, donc la tentative échoue avant même d'être intéressante.

Root mérite sa propre décision. PermitRootLogin prohibit-password conserve un accès root par clé pour les urgences ; PermitRootLogin no est plus strict et force chaque session à passer par un compte nommé avec sudo, ce qu'il vous faut dès que plus d'une personne touche à la machine. Ajoutez AllowUsers pour qu'un compte égaré créé par un paquet quelconque ne puisse jamais devenir un chemin de connexion. Déplacer le démon hors du port 22 vaut la peine d'être fait, mais soyons honnêtes sur la raison : ce n'est pas un contrôle de sécurité — quiconque scanne votre adresse trouvera le nouveau port en quelques secondes — c'est de l'hygiène de journaux, et cela élimine l'écrasante majorité du bruit automatisé, si bien que les entrées restantes dans auth.log sont celles que vous devriez réellement lire. Quoi que vous changiez, validez avec sshd -t avant de recharger, et gardez votre session actuelle ouverte jusqu'à ce qu'un second terminal se soit connecté avec succès. Cette habitude fait toute la différence entre une faute de frappe et un serveur perdu.

Default-deny, et la moitié du pare-feu que personne ne configure

Un pare-feu sur un serveur a un seul travail : faire en sorte que la réponse à "qu'est-ce qui écoute ici ?" soit exactement égale à la liste des choses que vous avez délibérément publiées. Default-deny en entrée, autoriser en sortie, puis ouvrir les ports un par un, chacun avec une raison précise. Avant d'écrire la moindre règle, lancez ss -tulpen et regardez ce qui est déjà lié — une installation par défaut écoute sur plus de choses que la plupart des gens ne l'imaginent, et une base de données ou un cache lié à 0.0.0.0 plutôt qu'à 127.0.0.1 est la façon classique dont un petit serveur finit dans le jeu de données de quelqu'un. Liez d'abord les services locaux à loopback ; le pare-feu est votre seconde ligne de défense, pas la seule.

Vient ensuite la moitié qu'on oublie de configurer. Chaque plan ici est livré avec un /64 d'IPv6 en plus de son IPv4, et la plupart des démons modernes lient volontiers les deux familles. Si vos règles ne couvrent que v4, un service que vous croyez protégé par le pare-feu reste joignable en v6 par quiconque résout l'adresse — et le scan IPv6 d'un préfixe d'hébergement connu est parfaitement routinier. ufw gère bien les deux, mais seulement quand IPV6=yes est réglé dans /etc/default/ufw ; vérifiez avec ufw status verbose plutôt que de le supposer. Docker mérite la même méfiance : publier un port de conteneur avec -p insère des règles dans sa propre chaîne iptables, évaluées avant celles d'ufw, si bien qu'un conteneur que vous pensiez protégé est souvent grand ouvert. Liez-le explicitement à 127.0.0.1:port et placez un reverse proxy devant. Quoi que vous configuriez, testez-le depuis un autre point d'Internet — une règle qui n'a jamais été que lue est une règle qui n'a jamais été testée.

Des mises à jour que vous n'avez pas à retenir

Les logiciels non patchés sont la façon dont la plupart des petits serveurs sont réellement perdus, et la raison est humaine plutôt que technique : patcher est une corvée qui rivalise avec tout ce que vous avez déjà à faire. Automatisez le canal de sécurité et le problème disparaît. unattended-upgrades, sur Debian et Ubuntu, applique les mises à jour de sécurité sur une minuterie et reste discret ; limitez-le au périmètre sécurité plutôt qu'à toute mise à niveau disponible, pour qu'une sortie de fonctionnalité de routine ne redémarre jamais votre application à trois heures du matin. Cela compte davantage sur une machine offshore auto-gérée que sur une plateforme managée, parce que personne ne la patche à votre place et qu'aucun chargé de compte ne vous enverra un e-mail à propos d'un CVE critique — il n'y a aucune adresse e-mail enregistrée à contacter.

Les mises à jour du noyau ont besoin d'un redémarrage pour prendre effet, donc décidez délibérément de votre politique de redémarrage plutôt que de la découvrir sur le tas. needrestart vous dira quels services tournent encore contre des bibliothèques supprimées, et une fenêtre Unattended-Upgrade::Automatic-Reboot au milieu de la nuit convient bien à un service sans état. Une interaction importante : si vous avez suivi notre guide de chiffrement intégral du disque et que votre système de fichiers root est chiffré, un redémarrage automatique s'arrête sur une invite de phrase de passe et y reste tant que vous ne l'avez pas déverrouillé par le réseau. Soit vous désactivez les redémarrages automatiques sur ces machines, soit vous vous assurez que le déverrouillage à distance est testé et que vous êtes éveillé pendant la fenêtre. Quel que soit votre choix, notez-le par écrit — une politique qui ne vit que dans votre tête cesse d'exister dès que vous partez en vacances.

Rate limiting, fail2ban, et le bruit de fond

Une fois l'authentification par mot de passe désactivée, la force brute contre SSH ne peut plus aboutir. Autant être clair sur ce que des outils comme fail2ban vous apportent à partir de là : non pas une défense contre le devinage — déjà impossible — mais un journal plus calme, moins de CPU dépensé sur des poignées de main condamnées d'avance, et un contrôle réel sur les couches où des secrets restent devinables. Pointez-le vers les endroits qui comptent : le formulaire de connexion d'une application web, le SMTP AUTH d'un serveur mail, un chemin d'administration que quelqu'un est en train d'énumérer. ufw limit vous donne un plafonnement de débit de connexion bon marché, sans aucun logiciel supplémentaire. Une poignée de réglages noyau méritent les mêmes cinq minutes — SYN cookies activés, reverse-path filtering activé, réponses aux broadcasts ICMP désactivées et annonces de routeur IPv6 ignorées sur un serveur à adresse statique.

Sachez cependant où s'arrête l'hôte. Rien de tout cela ne survit à une attaque volumétrique, parce qu'une inondation remplit le tuyau réseau bien avant d'inquiéter le CPU : le temps que les paquets atteignent vos règles nftables, ils ont déjà consommé la bande passante que vous essayiez de protéger. C'est pourquoi un nettoyage L3/L4 allant jusqu'à 1.5 Tbps se trouve en amont de la flotte et est inclus dans chaque plan plutôt que vendu en option, avec un bouclier L7 optionnel pour les inondations de couche applicative qui ressemblent à des requêtes légitimes. Votre pare-feu hôte gère la précision ; le réseau gère le volume. Traiter l'un comme le substitut de l'autre, c'est exactement ce qui prend les gens au dépourvu.

Le vrai risque ici, c'est de s'enfermer soi-même dehors

De tout ce qui peut mal tourner pendant cette première heure, le résultat de loin le plus probable n'est pas une intrusion. C'est vous, en fin de longue session, qui rechargez un sshd_config cassé ou activez un pare-feu dont la règle d'autorisation contient une faute de frappe, et qui découvrez que la porte s'est refermée derrière vous. Chez un hébergeur grand public, c'est un désagrément. Ici, cela mérite un vrai respect, parce que l'inscription se résume à un pseudonyme et un mot de passe, avec huit codes de récupération et aucun e-mail nulle part dans la boucle, précisément pour qu'il n'y ait aucune identité à divulguer — et un hébergeur qui ne peut pas vous identifier ne peut pas non plus vous faire rentrer dans votre serveur. Personne ne peut se porter garant de vous. Cette propriété est le produit qui fonctionne comme prévu, et c'est pourquoi les garde-fous ci-dessous sont des habitudes plutôt que des suggestions.

Quatre d'entre eux ne coûtent rien. Prenez un snapshot avant de toucher à SSH ou au pare-feu, pour qu'un mauvais rechargement se règle par un retour en arrière plutôt que par une reconstruction. Inscrivez une seconde clé publique depuis un appareil différent — un téléphone, un ordinateur portable professionnel, une sauvegarde hors ligne — parce qu'une seule clé sur un seul disque n'est jamais qu'à un café renversé de ne plus être aucune clé du tout. Gardez un second terminal connecté pendant que vous modifiez tout ce qui pourrait couper le premier, et testez toujours la nouvelle configuration depuis une connexion neuve avant de lâcher l'ancienne. Et acceptez où s'arrête l'échelle de récupération : les snapshots vivent sur le même hôte et sont une commodité de retour en arrière, pas une sauvegarde, donc tout ce que vous regretteriez vraiment de perdre appartient à un stockage hors machine — l'option de sauvegardes chiffrées quotidiennes, ou vos propres copies chiffrées côté client envoyées ailleurs. Votre pire scénario devrait être un redéploiement et une restauration, question de minutes, plutôt qu'une perte totale.

Quoi ajouter ensuite, selon ce que fait la machine

La checklist ci-dessus est le plancher, et elle est la même pour toutes les machines. Ce qui vient par-dessus dépend entièrement du rôle. Un serveur web public veut du TLS, un reverse proxy qui le termine, l'application tournant sous un utilisateur non privilégié, et la base de données sur loopback ou sur une tout autre machine. Un point de terminaison VPN a une forme différente — un seul port UDP, aucune pile web, aucun service public du tout — et c'est traité de bout en bout dans monter son propre VPN WireGuard. Un serveur mail est le plus exigeant des trois et a besoin d'un contrôle du rDNS sur l'adresse, ce qu'inclut chaque plan ; l'auto-hébergement d'un serveur mail sur VPS offshore couvre le volet délivrabilité. Un relais Tor est délibérément l'inverse de l'anonymat — c'est un service publié, joignable — et les compromis sont exposés dans faire tourner un relais sur un VPS no-KYC. Tout ce qui détient un état privé au repos devrait aussi être chiffré, ce qui est un contrôle séparé avec ses propres modes de défaillance, couvert dans LUKS et déverrouillage à distance.

Il vaut la peine de terminer en resituant le durcissement dans le tableau d'ensemble, car ce n'est que l'une des trois couches, et elles échouent indépendamment les unes des autres. Ce que l'hébergeur sait de vous est la première, et ici c'est proche de rien : un pseudonyme alimenté par un solde crypto prépayé à partir de $30.00, sans carte ni document dans la chaîne — le sujet de payer son hébergement anonymement. Quelle loi s'applique est la seconde, décidée par l'endroit où se trouve le matériel à travers nos 6 régions plutôt que par l'endroit où vous vous trouvez, et traitée région par région dans quelle localisation offshore choisir ?. Ce que la machine elle-même permet est la troisième, et celle-là n'appartient qu'à vous — aucun hébergeur ne peut la configurer à votre place. Un VPS à partir de $8.00/mois est en ligne en environ 15 min, ce qui signifie que l'heure qui suit est celle où se décide la sécurité réelle de la chose. Passez-la avec intention.

Étape par étape

1. 01

   Déployez, puis connectez-vous avant tout le reste

   Déployez depuis le panneau et choisissez une distribution que vous allez réellement patcher — une Debian actuelle ou une Ubuntu LTS est la réponse ennuyeuse et correcte. Un VPS est en ligne en environ 15 min et ses identifiants root atterrissent dans votre panneau. Connectez-vous immédiatement, mettez le système entièrement à jour et définissez un hostname pour que les journaux restent lisibles par la suite. Rien d'autre ne se passe sur cette machine tant que le reste de ces étapes n'est pas terminé.

   ssh root@203.0.113.10
   apt update && apt full-upgrade -y
   hostnamectl set-hostname edge-01
   apt install -y ufw unattended-upgrades needrestart

2. 02

   Quittez root : un utilisateur nommé, une clé et sudo

   Générez la paire de clés sur votre ordinateur portable, jamais sur le serveur. Créez ensuite un compte nommé sur la machine, placez la moitié publique dans son authorized_keys, et donnez-lui sudo. Ouvrez un second terminal et connectez-vous immédiatement sous cet utilisateur — avant de changer quoi que ce soit d'autre, pendant que root par SSH fonctionne encore comme filet de sécurité.

   # on your own machine
   ssh-keygen -t ed25519 -C "laptop"
   ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10
   
   # on the server
   adduser --disabled-password --gecos "" ops
   usermod -aG sudo ops
   install -d -m 700 -o ops -g ops /home/ops/.ssh
   cp /root/.ssh/authorized_keys /home/ops/.ssh/
   chown ops:ops /home/ops/.ssh/authorized_keys
   chmod 600 /home/ops/.ssh/authorized_keys

3. 03

   Verrouillez le démon SSH — avec un second terminal ouvert

   Écrivez les changements dans un fichier drop-in plutôt que d'éditer la config fournie, pour qu'une mise à niveau de la distribution ne les annule jamais silencieusement. Validez la syntaxe avec sshd -t avant de recharger, rechargez, puis prouvez-le depuis une toute nouvelle connexion pendant que l'actuelle est encore vivante. Si la nouvelle connexion échoue, vous avez toujours une session fonctionnelle pour annuler le changement. Un piège de distribution : sur Ubuntu 24.04, le démon est activé par socket, donc Port dans sshd_config est ignoré — réglez le port avec systemctl edit ssh.socket à la place, ou désactivez l'unité socket.

   cat > /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
   Port 2222
   PermitRootLogin prohibit-password
   PasswordAuthentication no
   KbdInteractiveAuthentication no
   AllowUsers ops
   X11Forwarding no
   MaxAuthTries 3
   LoginGraceTime 20
   EOF
   sshd -t && systemctl reload ssh
   # new terminal, do not close the old one:
   ssh -p 2222 ops@203.0.113.10

4. 04

   Mettez le pare-feu en default-deny, sur les deux familles IP

   Confirmez qu'IPv6 est activé dans ufw, puis refusez tout en entrée et n'ouvrez que les ports que vous servez délibérément — y compris le nouveau port SSH, qui doit être autorisé avant d'activer le pare-feu. Vérifiez ce qui écoute réellement pendant que vous y êtes, et déplacez sur loopback tout ce qui devrait être local.

   grep IPV6 /etc/default/ufw          # must read IPV6=yes
   ufw default deny incoming
   ufw default allow outgoing
   ufw limit 2222/tcp
   ufw allow 80,443/tcp
   ufw enable
   ufw status verbose
   ss -tulpen                           # anything on 0.0.0.0 or :: ?

5. 05

   Activez les mises à jour de sécurité automatiques

   N'activez que le canal de sécurité, pour que les correctifs arrivent sans qu'une mise à niveau de fonctionnalité ne redémarre votre application sans prévenir. Décidez explicitement la politique de redémarrage — et laissez les redémarrages automatiques désactivés si le système de fichiers root est chiffré et nécessite un déverrouillage manuel.

   dpkg-reconfigure -plow unattended-upgrades
   cat > /etc/apt/apt.conf.d/51-local <<'EOF'
   Unattended-Upgrade::Automatic-Reboot "false";
   Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
   EOF
   unattended-upgrade --dry-run --debug | tail -20

6. 06

   Réduisez le bruit et resserrez les réglages noyau

   Ajoutez fail2ban pour les couches où un secret reste devinable, et réglez la poignée de valeurs sysctl qui sont simplement correctes sur un serveur public à adresse statique. C'est peu coûteux, et cela rend les journaux dignes d'être lus.

   apt install -y fail2ban
   cat > /etc/sysctl.d/99-harden.conf <<'EOF'
   net.ipv4.tcp_syncookies = 1
   net.ipv4.conf.all.rp_filter = 1
   net.ipv4.icmp_echo_ignore_broadcasts = 1
   net.ipv4.conf.all.accept_redirects = 0
   net.ipv6.conf.all.accept_ra = 0
   kernel.kptr_restrict = 2
   EOF
   sysctl --system

7. 07

   Vérifiez depuis l'extérieur, puis rédigez le runbook

   Faites confiance à la vue depuis Internet, pas à la vue depuis l'intérieur de la machine. Confirmez que l'ancien port SSH a disparu, que rien d'inattendu ne répond, et que la connexion par clé seule est réellement imposée. Notez ensuite les trois faits dont vous aurez besoin dans votre pire jour : où vit votre seconde clé, quel snapshot vous avez pris et où se trouve la sauvegarde hors machine.

   # from another machine
   ssh -p 22 ops@203.0.113.10          # must time out or be refused
   ssh -p 2222 -o PreferredAuthentications=password ops@203.0.113.10
   # expected: Permission denied (publickey)
   ssh -p 2222 ops@203.0.113.10 'sudo ufw status verbose; uptime'