Nouveau VPS : les 10 premières minutes

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

Un VPS tout neuf n'est pas sûr. Dès qu'il a une IP publique, des scanners tentent de s'y connecter, et l'image par défaut leur offre une large cible : root souvent accessible, mots de passe souvent autorisés, aucun pare-feu, rien de mis à jour régulièrement. La bonne nouvelle : tout fermer prend une dizaine de minutes et une poignée de commandes. Voici le guide que j'applique sur chaque nouveau serveur avant d'y mettre quoi que ce soit.

Suivez les étapes dans l'ordre, car elles s'enchaînent. Chacune a son propre guide, lié au fil du texte ; cette page est le chemin rapide qui les relie.

Minute 1 : tout mettre à jour

Connectez-vous en root avec les identifiants fournis par votre hébergeur, et mettez le système entièrement à jour avant toute chose :

apt update && apt upgrade -y

Une machine non à jour est la cible la plus facile qui soit : cela passe donc en premier. Une fois terminé, configurez les mises à jour de sécurité automatiques pour qu'elle reste à jour sans que vous ayez à y penser.

Minute 2 : créer un utilisateur normal avec sudo

Ne continuez pas à travailler en root. Créez un utilisateur pour vous et donnez-lui sudo :

adduser matt
usermod -aG sudo matt

À partir de là, connectez-vous avec cet utilisateur et utilisez sudo pour les tâches d'administration. Travailler en permanence en root signifie que chaque erreur et chaque compromission se produit avec un pouvoir illimité : c'est précisément ce que travailler avec un utilisateur non privilégié permet d'éviter.

Minute 4 : configurer les clés SSH

Les mots de passe se devinent ; les clés, non. Sur votre propre ordinateur portable, si vous n'avez pas déjà une clé, créez-en une :

ssh-keygen -t ed25519

Puis copiez la moitié publique vers le serveur :

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id a besoin que la connexion par mot de passe soit active 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 (appartenant à matt), ou collez votre clé publique dans ce fichier à la main.

Le modèle derrière cette étape, une clé par appareil, les permissions qui cassent la connexion par clé, et la révocation d'une clé perdue, est traité dans les bases de la gestion des clés SSH.

Déconnectez-vous et reconnectez-vous en tant que matt avec la clé, et vérifiez que cela fonctionne avant de passer à l'étape suivante. Verrouiller SSH avant de pouvoir entrer avec une clé, c'est ainsi qu'on se retrouve enfermé dehors.

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

Maintenant que votre clé fonctionne, fermez les deux portes sur lesquelles comptent les scanners. Utilisez un fichier drop-in pour que les mises à jour de paquets ne l'écrasent pas. Nommez-le 00- pour qu'il soit trié avant 50-cloud-init.conf, que les images cloud d'Ubuntu livrent avec PasswordAuthentication yes ; sshd garde la première valeur qu'il lit, donc un fichier trié plus tard serait silencieusement perdu :

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

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Puis rechargez SSH :

sudo systemctl restart ssh

Vérifiez ensuite les réglages que sshd utilise réellement, pour qu'un drop-in perdant ne puisse pas vous tromper :

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

Mots de passe désactivés et connexion root supprimée, le trafic constant de force brute contre votre serveur ne peut tout simplement plus aboutir. Le traitement complet, y compris un changement de port optionnel, se trouve dans la sécurisation de SSH sur un VPS.

Minute 8 : activer le pare-feu

Refusez par défaut tout le trafic entrant, puis n'autorisez que ce dont vous avez besoin. Autorisez SSH avant d'activer le pare-feu, sinon vous coupez votre propre connexion :

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

Ajoutez des règles allow pour tout service que vous faites réellement tourner, comme 80/tcp et 443/tcp pour un site web. Vérifiez que l'IPv4 et l'IPv6 sont couvertes, car un pare-feu qui ne filtre que l'IPv4 laisse le côté IPv6 grand ouvert. Le guide complet est Pare-feu 101 sur un VPS.

Minute 10 : ralentir les scanners avec Fail2ban

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

sudo apt install -y fail2ban

Sur Ubuntu 24.04, l'installation par défaut protège SSH dès le premier démarrage. Les clés étant déjà requises, c'est un filet de sécurité qui réduit le bruit dans les journaux et bloque les récidivistes, plutôt que votre défense principale.

Votre check-list

Voilà le guide. Utilisez le générateur ci-dessous pour cocher chaque mesure et produire une check-list personnalisée à garder avec le serveur, incluant la commande exacte de chaque étape :

Parcourez-la une fois par nouveau serveur et l'ensemble devient un automatisme. Dix minutes maintenant vous épargnent le très mauvais après-midi qui suit la prise de contrôle d'un serveur.

Une fois l'essentiel en place, les mises à jour de sécurité automatiques sur Ubuntu gardent le serveur à jour sans que vous ayez à vous reconnecter.

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 root. Ensuite, configurez les clés SSH, désactivez la connexion root et l'authentification par mot de passe, activez un pare-feu qui refuse tout par défaut, et installez Fail2ban. Les faire dans cet ordre garantit que chaque étape est sûre sans vous enfermer dehors.

Comment éviter de m'enfermer dehors en sécurisant SSH ?

Configurez et testez votre connexion par clé SSH avant de désactiver les mots de passe ou root. Déconnectez-vous et reconnectez-vous avec la clé pour confirmer que cela fonctionne, et seulement alors désactivez PasswordAuthentication et PermitRootLogin. En activant le pare-feu, autorisez le port 22 avant de lancer ufw enable. Si vous vous retrouvez enfermé dehors, la console web de votre hébergeur vous permet de revenir sans SSH.

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

Oui, car les scanners se moquent de la taille de votre serveur. Ils essaient chaque IP publique de la même manière. Tout le guide prend une dizaine de minutes et supprime les chemins faciles : pas de connexion root, pas de devinette de mot de passe, rien d'exposé que vous n'ayez choisi, et les bugs connus corrigés automatiquement.

Quelle est l'étape la plus importante ?

SSH par clé uniquement, avec la connexion root désactivée. La plupart des attaques sur un VPS neuf sont des devinettes de mots de passe automatisées contre root, et désactiver les deux rend cette catégorie entière d'attaque impossible. Le pare-feu et Fail2ban limitent ensuite ce qui est exposé et ralentissent ce qui reste.

Comment vérifier que le serveur est réellement verrouillé ?

Vérifiez trois choses à la main avant de lui faire confiance. Lancez sudo ss -tlnp et confirmez que seuls les ports voulus écoutent sur une adresse publique, sans service en 0.0.0.0 ou [::] que vous auriez oublié. Lancez sudo ufw status verbose et confirmez que la politique entrante par défaut est deny et que les règles simples et (v6) sont présentes. Et ouvrez toujours une deuxième session SSH avant de fermer la première, pour qu'une erreur dans la configuration SSH ne puisse pas vous enfermer dehors. Si les trois sont corrects, les bases sont en place.