Que faire dans les 10 premières minutes d’un VPS ?

Les 10 premières minutes déterminent la sécurité de votre serveur

Un VPS tout neuf n’est pas sécurisé. Dès qu’il dispose d’une adresse IP publique, des scanners tentent de s’y connecter. L’image par défaut leur offre souvent une grande surface d’attaque : le compte root est généralement accessible, les mots de passe sont souvent autorisés, aucun pare-feu n’est configuré et les correctifs ne sont pas appliqués selon un calendrier. La bonne nouvelle est qu’il faut environ dix minutes et quelques commandes pour corriger tout cela. C’est la procédure que j’applique à chaque nouveau serveur avant d’y installer quoi que ce soit.

Suivez les étapes dans l’ordre, car elles dépendent les unes des autres. Chaque étape possède son propre guide, indiqué au fil de la procédure. Cette page constitue le parcours rapide qui les relie.

Minute 1 : tout mettre à jour

Connectez-vous en tant que root avec les identifiants fournis par votre hébergeur, puis mettez complètement le système à jour avant toute autre opération :

apt update && apt upgrade -y

Un serveur non corrigé est la cible la plus facile. Cette étape est donc prioritaire. Une fois la mise à jour terminée, configurez les mises à jour de sécurité automatiques pour que le système reste à jour sans intervention manuelle.

Minute 2 : Créer un utilisateur standard avec sudo

Ne continuez pas à travailler en tant que root. Créez un utilisateur pour vous et donnez-lui l’accès à sudo :

adduser matt
usermod -aG sudo matt

À partir de maintenant, connectez-vous avec cet utilisateur et utilisez sudo pour les tâches d’administration. Travailler constamment en tant que root signifie que chaque erreur et chaque compromission se produit avec des privilèges illimités. C’est précisément ce que l’exécution avec un utilisateur non privilégié permet d’éviter.

Minute 4 : Configurez les clés SSH

Les mots de passe peuvent être devinés ; les clés ne le peuvent pas. Sur votre propre ordinateur portable, si vous n’avez pas encore de clé, créez-en une :

ssh-keygen -t ed25519

Copiez ensuite la partie publique sur le serveur :

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id nécessite que l’authentification par mot de passe soit activée pour le nouvel utilisateur ; si elle est déjà désactivée, copiez le ~/.ssh/authorized_keys de root dans /home/matt/.ssh/authorized_keys (propriété de matt), ou collez manuellement votre clé publique dans ce fichier.

Le fonctionnement de cette étape — une clé par appareil, les permissions qui empêchent l’authentification par clé et la révocation d’une clé perdue — est expliqué dans Notions de base sur la gestion des clés SSH.

Déconnectez-vous, puis reconnectez-vous en tant que matt avec la clé. Vérifiez que cela fonctionne avant de passer à l’étape suivante. Restreindre SSH avant de pouvoir vous connecter avec une clé est le meilleur moyen de vous verrouiller vous-même hors du serveur. Si cette connexion renvoie Permission denied (publickey), corrigez le problème maintenant au lieu de revenir au mot de passe, car ce message peut correspondre à cinq problèmes différents et la sortie de ssh -v indique lequel vous rencontrez réellement.

Minute 6 : Désactiver la connexion root et les mots de passe

Maintenant que votre clé fonctionne, fermez les deux accès utilisés par les scanners. Utilisez un fichier drop-in pour éviter qu’une mise à niveau des paquets ne l’écrase. Nommez-le 00- afin qu’il soit chargé avant 50-cloud-init.conf, fourni avec les images cloud Ubuntu par PasswordAuthentication yes. sshd conserve la première valeur qu’il lit. Un fichier chargé plus tard perdrait donc sa valeur sans message d’erreur :

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Rechargez ensuite SSH :

sudo systemctl restart ssh

Vérifiez ensuite les paramètres effectivement utilisés par sshd. Vous éviterez ainsi qu’un fichier drop-in chargé plus tard ne vous induise en erreur :

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Une fois les mots de passe désactivés et la connexion root interdite, le trafic constant de brute force visant votre serveur ne peut plus aboutir. La procédure complète, qui inclut notamment un changement de port facultatif, est présentée dans Renforcer la sécurité de SSH sur un VPS.

Minute 8 : Activez le pare-feu

Refusez par défaut toutes les connexions entrantes, puis n’autorisez que celles dont vous avez besoin. Autorisez SSH avant de l’activer, sinon vous couperez votre propre connexion :

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Ajoutez les règles allow correspondant à chaque service réellement exécuté, par exemple 80/tcp et 443/tcp pour un site web. Si une nouvelle session SSH ne se connecte plus après cette modification, lisez l’erreur avant toute autre action, car un refus signifie que sshd a répondu, tandis qu’un délai d’attente indique généralement que le pare-feu a bloqué le paquet. Vérifiez que les connexions IPv4 et IPv6 sont toutes deux couvertes, car un pare-feu qui ne filtre que l’IPv4 laisse le volet IPv6 complètement exposé. Consultez le guide complet Les pare-feu sur un VPS : les bases. Ces commandes ufw supposent que vous utilisez Ubuntu ou Debian ; sur une machine Rocky ou AlmaLinux, l’objectif de refus par défaut reste le même, mais l’outil est firewalld. Suivez donc la version de cette étape pour firewalld.

Minute 10 : ralentir les scanners avec Fail2ban

Enfin, ajoutez Fail2ban pour bannir les adresses qui martèlent vos ports :

sudo apt install -y fail2ban

Sur Ubuntu 24.04, l’installation standard protège SSH dès le premier démarrage. Comme les clés sont déjà obligatoires, il s’agit d’une protection complémentaire qui réduit le bruit dans les journaux et bloque les récidivistes, plutôt que de constituer votre principale défense.

Votre checklist

C’est le runbook. Utilisez le générateur ci-dessous pour valider chaque contrôle et produire une checklist personnalisée à conserver avec le serveur, avec la commande exacte pour chaque étape :

Parcourez-la une fois pour chaque nouveau serveur : tout deviendra rapidement automatique. Dix minutes maintenant vous éviteront la très mauvaise journée qui suit la compromission d’un serveur.

Une fois les éléments essentiels en place, les mises à jour de sécurité automatiques sur Ubuntu maintiennent le serveur à jour sans vous obliger à vous reconnecter. Chaque service ajouté nécessite ensuite son propre contrôle, et les points faibles se déplacent : avec un gestionnaire de mots de passe auto-hébergé, le serveur ne conserve jamais les données en clair. Les principaux risques de Vaultwarden concernent donc le jeton d’administration et le fichier de sauvegarde.

FAQ

Que faire en premier sur un nouveau VPS ?

Mettez le système à jour avec apt update && apt upgrade -y, puis créez un utilisateur normal avec sudo et cessez de travailler en tant que root. Configurez ensuite les clés SSH, désactivez la connexion de root et l’authentification par mot de passe, activez un firewall dont la politique par défaut refuse tout, puis installez Fail2ban. En procédant dans cet ordre, chaque étape peut être appliquée sans vous bloquer l’accès au serveur.

Comment éviter de me bloquer l’accès pendant le durcissement de SSH ?

Configurez et testez la connexion SSH avec votre clé avant de désactiver les mots de passe ou root. Déconnectez-vous, puis reconnectez-vous avec la clé pour vérifier qu’elle fonctionne. Désactivez seulement ensuite PasswordAuthentication et PermitRootLogin. Lorsque vous activez le firewall, autorisez le port 22 avant d’exécuter ufw enable. Si vous vous bloquez malgré tout l’accès, la console web de votre fournisseur vous permet de vous reconnecter sans SSH.

Ai-je vraiment besoin de tout cela sur un petit serveur ?

Oui, car les scanners ne tiennent pas compte de la taille de votre serveur. Ils testent toutes les adresses IP publiques de la même manière. La procédure complète prend environ dix minutes et supprime les accès les plus faciles : aucune connexion de root, aucune tentative de mot de passe, et aucun service exposé que vous n’avez pas choisi d’exposer. Les vulnérabilités connues sont également corrigées automatiquement.

Quelle est l’étape la plus importante ?

Utiliser SSH uniquement avec une clé et désactiver la connexion de root. La plupart des attaques contre un VPS neuf sont des tentatives automatisées de mot de passe visant root. Désactiver ces deux accès rend toute cette catégorie d’attaques impossible. Le firewall et Fail2ban limitent ensuite les services exposés et ralentissent les attaques restantes.

Comment confirmer que le serveur est réellement sécurisé ?

Vérifiez manuellement trois éléments avant de considérer la configuration comme fiable. Exécutez sudo ss -tlnp et vérifiez que seuls les ports que vous vouliez ouvrir écoutent sur une adresse publique, sans service 0.0.0.0 ou [::] que vous auriez oublié. Exécutez sudo ufw status verbose et vérifiez que la politique entrante par défaut est deny, et que les règles plain et (v6) sont toutes deux présentes. Ouvrez toujours une deuxième session SSH avant de fermer la première. Ainsi, une erreur dans la configuration SSH ne pourra pas vous bloquer l’accès au serveur. Si les trois vérifications sont correctes, les bases sont en place.