Sécuriser son VPS Linux : Les 5 étapes indispensables

Quand j’ai reçu les accès à mon premier VPS, je me suis connecté en root avec un mot de passe de 8 caractères et je me suis dit “ça ira pour l’instant”. Le lendemain matin, les logs SSH affichaient des milliers de tentatives de connexion venues de Chine, de Russie et d’un peu partout. Leçon apprise.

Dès qu’un serveur VPS est mis en ligne avec une adresse IP publique, il ne faut que quelques minutes pour que des réseaux de robots automatisés commencent à le scanner. Leur but est de pirater votre puissance de calcul pour miner de la cryptomonnaie ou lancer des attaques DDoS.

Avant de voir les commandes pour corriger la situation, regardons les erreurs de configuration les plus courantes.

Ce qui compromet un VPS

Laisser l’authentification par mot de passe active

Beaucoup d’utilisateurs configurent un mot de passe qu’ils estiment complexe (ex: MonSuperServeur2026!) et pensent être en sécurité. En réalité, les attaquants utilisent des dictionnaires de mots de passe volés et des outils de force brute capables de tester des milliers de combinaisons par seconde. Il faut désactiver les mots de passe et utiliser des clés SSH asymétriques.

Garder l’accès “root” ouvert

L’utilisateur root est l’administrateur suprême sous Linux. Puisque ce nom d’utilisateur existe sur tous les serveurs, c’est celui que les robots attaquent en priorité. En gardant le compte root accessible par mot de passe, vous facilitez le travail d’intrusion. La solution est de créer un utilisateur standard avec les droits sudo et d’interdire la connexion directe à root dans la configuration SSH.

Exposer tous les ports sur Internet

Lorsqu’un VPS est livré, ses ports réseau sont potentiellement tous accessibles. Si vous installez une base de données MySQL en test sur le port 3306 et que vous oubliez de le fermer, n’importe qui peut s’y connecter et tenter d’exploiter une faille. Il faut bloquer tout le trafic entrant par défaut avec un pare-feu comme UFW et n’ouvrir que les ports vitaux.

Ignorer les attaques par force brute

Même avec des clés SSH, votre serveur subira des requêtes SSH échouées en permanence. Ces tentatives consomment du CPU et saturent vos logs. Le service Fail2ban permet de bannir automatiquement les IP suspectes après quelques échecs.

Oublier les mises à jour

Les failles de sécurité dans les composants Linux sont découvertes régulièrement. Un serveur non mis à jour pendant plusieurs mois devient une cible facile. Il faut activer les mises à jour de sécurité automatiques pour appliquer les correctifs sans y penser.

Étape 1 : Générer une clé SSH Ed25519

Une clé SSH Ed25519 est plus sûre et plus rapide à vérifier qu’un mot de passe. Ouvrez un terminal sur votre machine locale :

ssh-keygen -t ed25519 -C "votre_email@example.com"

L’outil vous demande un emplacement (appuyez sur Entrée pour accepter ~/.ssh/id_ed25519) et une passphrase. Ne la sautez pas. Elle protège votre clé privée si quelqu’un parvient à vous la voler.

Transférez ensuite la clé publique sur le serveur :

ssh-copy-id -i ~/.ssh/id_ed25519.pub votre_user@IP_DU_SERVEUR

Si ssh-copy-id n’est pas disponible, par exemple sous Windows sans WSL, vous pouvez le faire manuellement :

# Sur le serveur, en tant que votre utilisateur
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
# Collez ici le contenu de votre fichier ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/authorized_keys

Astuce sécurité

Avant de passer à l'étape suivante, ouvrez un second terminal et connectez-vous au serveur avec votre clé SSH. Vérifiez que la connexion aboutit. Si vous désactivez les mots de passe sans avoir testé votre clé, vous risquez de bloquer votre propre accès.

Étape 2 : Durcir la configuration SSH

Maintenant que la clé fonctionne, on verrouille le service SSH. Éditez son fichier de configuration :

sudo nano /etc/ssh/sshd_config

Recherchez et modifiez (ou ajoutez) ces directives :

# Interdire la connexion directe en root
PermitRootLogin no

# Désactiver l'authentification par mot de passe
PasswordAuthentication no

# S'assurer que les clés publiques sont bien utilisées
PubkeyAuthentication yes

# Réduire les tentatives par connexion
MaxAuthTries 3
LoginGraceTime 30

# Désactiver les méthodes interactives non nécessaires
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no

Avant de redémarrer le service, validez la syntaxe pour éviter une erreur bloquante :

sudo sshd -t

Si la commande ne renvoie rien, la syntaxe est bonne. Redémarrez SSH :

sudo systemctl reload ssh

Attention

Ne fermez pas votre terminal actuel avant d'avoir vérifié que vous pouvez toujours vous connecter depuis une nouvelle fenêtre. En cas de faute de frappe dans sshd_config, votre session active vous permettra de corriger le problème.

Étape 3 : Installer et configurer UFW

UFW (Uncomplicated Firewall) est l’interface simplifiée d’iptables livrée avec Ubuntu et Debian. On bloque tout par défaut et on n’ouvre que ce dont on a besoin.

sudo apt update && sudo apt install -y ufw

Appliquez les règles de base dans cet ordre précis :

# Bloquer tout le trafic entrant par défaut
sudo ufw default deny incoming

# Autoriser tout le trafic sortant
sudo ufw default allow outgoing

# Autoriser SSH (port 22 standard)
sudo ufw allow OpenSSH

# Autoriser le web
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Activer le pare-feu
sudo ufw enable

# Vérifier l'état
sudo ufw status verbose

Changer le port SSH

Passer le port SSH du 22 à un port non standard (ex: 2222 ou un port au-dessus de 1024) réduit le bruit dans les logs, car les scanners automatisés ciblent presque exclusivement le port 22. Si vous changez le port, pensez à autoriser ce nouveau port dans UFW avec sudo ufw allow 2222/tcp et à modifier l'option Port dans sshd_config.

Étape 4 : Protéger le serveur avec Fail2ban

Des robots vont continuer à tester des connexions sur votre serveur. Fail2ban lit les logs système et banne temporairement les adresses IP qui accumulent trop d’échecs.

sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban

Créez un fichier de configuration local. Il ne faut pas modifier directement jail.conf, sinon vos changements seront écrasés à la prochaine mise à jour :

sudo nano /etc/fail2ban/jail.local

Voici une configuration de base :

[DEFAULT]
# Durée du bannissement : 1 heure
bantime  = 1h
# Fenêtre d'observation : 10 minutes
findtime = 10m
# Nombre de tentatives avant bannissement
maxretry = 5
# Intégration native avec UFW sur Debian/Ubuntu
banaction = ufw

[sshd]
enabled  = true
port     = ssh
logpath  = %(sshd_log)s

Redémarrez Fail2ban pour appliquer les paramètres :

sudo systemctl restart fail2ban

Pour surveiller les bans en temps réel, vous pouvez utiliser ces commandes :

# Voir le statut de la jail SSH
sudo fail2ban-client status sshd

# Voir tous les bans actifs
sudo fail2ban-client status

# Débanner manuellement une IP
sudo fail2ban-client set sshd unbanip VOTRE_IP

Port SSH personnalisé et Fail2ban

Si vous avez changé le port SSH à l'étape 2, pensez à mettre à jour le fichier jail.local en remplaçant port = ssh par port = 2222 (ou votre port). Sinon Fail2ban bannira les adresses IP sur le mauvais port.

Étape 5 : Maintenir le système à jour

La majorité des compromissions exploitent des vulnérabilités connues dans des paquets non mis à jour.

sudo apt update && sudo apt upgrade -y

Pour les serveurs exposés, vous pouvez activer les mises à jour de sécurité automatiques via unattended-upgrades :

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Répondez “Oui” à l’invite. Le système appliquera les correctifs de sécurité critiques tout seul.

Mises à jour et redémarrages

Les mises à jour automatiques peuvent parfois redémarrer des services. Sur un serveur de production critique, vous préférerez peut-être une supervision manuelle avec des alertes pour planifier les mises à jour.

Vérifier sa configuration

Pour confirmer l’état de sécurité de votre VPS :

Vérification	Commande	Résultat attendu
Clé SSH active	`cat ~/.ssh/authorized_keys`	Votre clé publique s’affiche
Root login désactivé	`sudo sshd -T \| grep permitrootlogin`	`permitrootlogin no`
Mots de passe désactivés	`sudo sshd -T \| grep passwordauth`	`passwordauthentication no`
Pare-feu UFW actif	`sudo ufw status`	`Status: active`
Fail2ban actif	`sudo systemctl is-active fail2ban`	`active`
IPs bannies actuelles	`sudo fail2ban-client status sshd`	Nombre de bans > 0 si le serveur est exposé
Mises à jour auto	`systemctl is-active unattended-upgrades`	`active`

Questions fréquentes

Et si je perds ma clé SSH ? La plupart des hébergeurs proposent un accès à la console de secours (rescue mode ou KVM) depuis leur interface d’administration. Vous pouvez vous y connecter avec vos identifiants d’hébergeur pour régénérer un accès.

Faut-il changer le port SSH ? C’est une pratique courante. Elle ne remplace pas les clés SSH mais réduit le bruit dans les logs. Choisissez un port entre 1024 et 65535, et n’oubliez pas de l’ouvrir dans UFW.

Fail2ban peut-il me bannir moi-même ? Oui, si vous tapez votre passphrase incorrectement plusieurs fois de suite. Pour l’éviter, vous pouvez ajouter votre IP en liste blanche dans jail.local avec ignoreip = 127.0.0.1/8 VOTRE_IP.

Dois-je appliquer ceci sur un serveur Coolify ? Coolify tourne sur votre VPS, donc ces étapes sécurisent la machine hôte. Coolify gère ensuite la sécurité de ses conteneurs. Vous pouvez toutefois restreindre l’accès au port 8000 de Coolify à votre seule IP.

Ces cinq étapes éliminent la majorité des attaques automatisées qui ciblent les serveurs exposés. Ce n’est qu’une base, mais elle suffit pour bloquer les scanners de masse.

Pour aller plus loin

Installer Coolify sur un VPS Hostinger : déployer vos applications sur votre serveur sécurisé.
Surveiller ses apps avec Uptime Kuma : mettre en place un monitoring pour être alerté en cas de panne.
Optimiser son blog Astro avec Cloudflare : ajouter le WAF Cloudflare et masquer votre IP publique.
Sauvegarder ses volumes Docker vers S3 : protéger vos données contre les pannes matérielles.