Sécuriser un VPS de zéro : clés SSH, pare-feu et Fail2ban

Un VPS n'est pas automatiquement protégé dès l'installation d'Ubuntu. Avant même de configurer l'accès, le serveur est déjà visible par des scanners qui testent les mots de passe SSH, recherchent les panneaux d'administration exposés et vérifient les vulnérabilités courantes. Ce guide explique comment sécuriser un VPS depuis le début : créer un utilisateur distinct, activer la connexion par clé SSH, limiter les ports réseau avec UFW et ajouter Fail2ban. Les étapes conviennent à Ubuntu 22.04 et 24.04 si les commandes sont exécutées par un utilisateur disposant des droits sudo.

Avant la configuration : dressez la liste des ports

N'ouvrez pas de ports « au cas où ». Pour un serveur web classique, les ports nécessaires sont les suivants :

• 22/tcp — SSH, idéalement limité à certaines adresses IP ou déplacé vers un autre port uniquement comme mesure complémentaire ;
• 80/tcp — HTTP, généralement nécessaire pour la redirection vers HTTPS et la validation d'un certificat ;
• 443/tcp — HTTPS.

Un port d'application comme 3000, 8080 ou 9000 ne devrait pas être accessible depuis Internet lorsqu'un proxy Nginx ou Caddy se trouve devant l'application. Faites écouter l'application sur 127.0.0.1 ou autorisez son port uniquement sur le réseau interne. Commencez par vérifier ce qui écoute sur le serveur :

sudo ss -tulpn

Après l'installation de Docker, vérifiez également ses règles iptables : la publication -p 3000:3000 peut ouvrir un port en contournant le schéma prévu. Pour un service public, il est plus sûr d'utiliser un proxy HTTPS et de masquer le port interne.

Étape 1. Mettez le système à jour et créez un administrateur

Connectez-vous au VPS avec le compte fourni et installez les mises à jour :

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y ufw fail2ban unattended-upgrades

Créez votre utilisateur personnel. Remplacez alex par votre propre nom :

sudo adduser alex
sudo usermod -aG sudo alex

Ne supprimez pas l'accès initial avant d'avoir testé le nouveau compte dans une fenêtre distincte du terminal. C'est une règle importante : une erreur de configuration SSH est plus facile à corriger lorsque la session actuelle est encore ouverte.

Étape 2. Créez une clé SSH et installez-la sur le serveur

Sur votre ordinateur Linux, macOS ou Windows PowerShell, exécutez :

ssh-keygen -t ed25519 -C "alex@my-computer"

Appuyez sur Entrée pour enregistrer la clé dans le fichier proposé par défaut, puis définissez une passphrase. La clé privée ne doit jamais être envoyée dans un chat, placée dans un dépôt ou copiée sur le VPS. Seul le fichier portant l'extension .pub doit être transféré au serveur :

ssh-copy-id alex@SERVER_IP

Si ssh-copy-id n'est pas disponible, affichez la clé publique avec Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub dans PowerShell, puis ajoutez-la au serveur :

sudo install -d -m 700 -o alex -g alex /home/alex/.ssh
sudo nano /home/alex/.ssh/authorized_keys
sudo chown alex:alex /home/alex/.ssh/authorized_keys
sudo chmod 600 /home/alex/.ssh/authorized_keys

Collez la clé sur une seule ligne et vérifiez la connexion avant de désactiver les mots de passe :

ssh alex@SERVER_IP
sudo whoami

La dernière commande doit renvoyer root. Si le client SSH ne trouve pas la clé, indiquez-la explicitement : ssh -i ~/.ssh/id_ed25519 alex@SERVER_IP.

Étape 3. Interdisez root et la connexion par mot de passe

Faites une copie de sauvegarde de la configuration SSH :

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

Vérifiez que le fichier contient les paramètres suivants :

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
MaxAuthTries 3

Sous Ubuntu, les réglages peuvent se trouver dans /etc/ssh/sshd_config.d/*.conf. Vérifiez donc la configuration effectivement utilisée :

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries'

Si sshd -t affiche une erreur, ne redémarrez pas le service avant d'avoir corrigé la syntaxe. Une fois la vérification réussie, appliquez les réglages :

sudo systemctl reload ssh

Laissez l'ancienne connexion SSH ouverte et testez la connexion par clé dans une nouvelle fenêtre. Désactiver les mots de passe sans avoir vérifié la clé est le moyen le plus courant de perdre l'accès au serveur.

Étape 4. Configurez UFW sans bloquer SSH

UFW est une interface pratique au-dessus des règles réseau de Linux. Commencez par définir des valeurs par défaut sûres, puis autorisez SSH et les ports web :

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

Ne confirmez l'activation qu'après avoir ajouté la règle SSH. Affichez ensuite le résultat :

sudo ufw status verbose
sudo ufw status numbered

Pour une adresse IP de bureau fixe, vous pouvez limiter SSH à cette adresse :

sudo ufw delete allow 22/tcp
sudo ufw allow from YOUR.PUBLIC.IP to any port 22 proto tcp comment 'SSH office'

N'utilisez cette méthode qu'avec une IP fixe et une console du fournisseur disponible : si l'adresse change, vous risquez de vous bloquer vous-même.

Ouvrir temporairement le port d'une application

Si vous devez vérifier directement un service, créez une règle dont la source est limitée :

sudo ufw allow from YOUR.PUBLIC.IP to any port 8080 proto tcp

Après le test, supprimez-la en utilisant son numéro affiché par ufw status numbered :

sudo ufw delete RULE_NUMBER

N'utilisez jamais sudo ufw allow 1:65535/tcp : une telle règle réduirait le pare-feu à une simple formalité.

Étape 5. Activez Fail2ban pour SSH

Fail2ban analyse les journaux et ajoute une règle de blocage temporaire après plusieurs tentatives de connexion infructueuses. Il ne remplace ni les clés SSH ni le pare-feu, mais réduit le bruit généré par les attaques automatisées par dictionnaire.

Créez une configuration locale afin qu'une mise à jour du paquet ne remplace pas vos réglages :

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Dans la section [DEFAULT], définissez des valeurs raisonnables :

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
backend = systemd
banaction = ufw

[sshd]
enabled = true
port = 22

Démarrez le service et vérifiez la jail :

sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Dans la sortie de sshd, examinez le nombre de tentatives échouées et les adresses bloquées. N'ajoutez pas votre propre IP à la liste de bannissement. Pour créer une exception permanente, utilisez le paramètre ignoreip = 127.0.0.1/8 YOUR.PUBLIC.IP dans [DEFAULT].

Étape 6. Activez les mises à jour automatiques

Les mises à jour automatiques sont utiles pour les paquets de sécurité, mais le redémarrage du noyau doit tout de même être contrôlé :

sudo dpkg-reconfigure -plow unattended-upgrades
sudo systemctl status unattended-upgrades

Une fois par semaine, vérifiez si un redémarrage est nécessaire :

test -f /var/run/reboot-required && echo 'Требуется перезапуск'

Avant un redémarrage manuel, assurez-vous de disposer d'une clé fonctionnelle et d'un accès à la console du VPS. Après le redémarrage, vérifiez les services de l'application, Nginx, UFW et Fail2ban.

Étape 7. Vérifiez le résultat depuis l'extérieur

Testez la protection depuis un autre ordinateur, et pas seulement en lisant la configuration :

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no alex@SERVER_IP

La commande doit se terminer par un refus. Testez séparément la connexion par clé :

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 alex@SERVER_IP

Sur le VPS, vérifiez les adresses en écoute et les règles :

sudo ss -lntup
sudo ufw status numbered
sudo fail2ban-client status sshd

Le port de l'application doit écouter sur 127.0.0.1 s'il n'est pas destiné à un accès direct. Depuis un nœud externe, vous pouvez utiliser nmap SERVER_IP, mais scannez uniquement votre propre serveur : tester une infrastructure qui ne vous appartient pas sans autorisation peut enfreindre la loi et les règles du fournisseur.

Sauvegardes et restauration

La protection SSH ne vous protège ni contre la suppression de données, ni contre une erreur d'administration, ni contre la compromission d'une application. Conservez les sauvegardes de la base de données, des configurations et des fichiers utilisateur séparément du VPS. Le minimum consiste à effectuer une copie quotidienne, à conserver plusieurs versions des jours précédents et à vérifier périodiquement la restauration.

N'inscrivez pas de mots de passe ni de jetons dans des scripts en clair. En cas de fuite, révoquez immédiatement le secret et créez-en un nouveau.

Comment choisir un VPS pour un projet sécurisé

La sécurité commence par le contrôle de l'infrastructure. Avec un VPS, vous pouvez choisir vous-même le système d'exploitation, les règles du pare-feu, le mode d'accès, la stratégie de sauvegarde et l'emplacement des services. Pour un petit site ou une API, un réseau stable, un SSD et une console de récupération sont souvent plus importants qu'un grand nombre de cœurs virtuels.

Lors du lancement d'un projet sur un VPS chez tropic.host, déterminez à l'avance ses points d'entrée publics : dans la plupart des cas, SSH, HTTP et HTTPS suffisent. Laissez la base de données et les panneaux d'administration dans le réseau interne. Pour un projet en croissance, des VPS distincts pour l'application, la base de données et la supervision permettent de séparer les zones de panne.

Erreurs fréquentes

• Désactiver le mot de passe avant d'avoir vérifié la connexion par clé. Gardez la session actuelle ouverte et testez la nouvelle connexion séparément.
• Laisser 22/tcp ouvert au monde entier alors qu'il est possible de l'autoriser uniquement depuis des adresses de confiance.
• Publier directement les ports Docker. Vérifiez d'abord les règles de Docker et d'UFW.
• Installer Fail2ban puis ne plus consulter les journaux. Après chaque modification, vérifiez journalctl -u ssh et l'état de la jail.

Conclusion

La protection de base d'un VPS prend peu de temps si vous respectez le bon ordre : créer un utilisateur distinct, installer une clé SSH, vérifier l'accès, interdire root et les mots de passe, activer UFW, configurer Fail2ban et les mises à jour automatiques. Ajoutez ensuite les sauvegardes, la journalisation et une supervision externe.

Ces étapes ne rendent pas le serveur invulnérable, mais elles corrigent les erreurs les plus fréquentes lors de la configuration initiale. Adaptez ensuite le niveau de protection à l'application concernée : mettez les dépendances à jour, limitez les droits des services, protégez les panneaux d'administration et contrôlez régulièrement les ports ouverts.

FAQ

Est-il nécessaire de modifier le port SSH par défaut ?

Non, ce n'est pas obligatoire. Changer de port réduit le bruit généré par les automatismes, mais ne remplace ni les clés, ni la désactivation des mots de passe, ni UFW, ni Fail2ban. Si vous changez de port, mettez à jour la règle du pare-feu et le paramètre port de la jail Fail2ban.

Que faire si j'ai perdu l'accès après avoir configuré UFW ?

Utilisez la console web ou la console de secours du fournisseur, puis vérifiez la règle SSH et la configuration de sshd. Ne fermez pas l'ancienne session fonctionnelle tant que la nouvelle connexion n'est pas confirmée.

Fail2ban suffit-il à protéger SSH ?

Non. Fail2ban réagit après les tentatives de connexion déjà échouées. La base doit être constituée de clés SSH, de l'authentification par mot de passe désactivée, de droits utilisateur minimaux et d'un pare-feu restrictif.

Peut-on autoriser SSH depuis une seule adresse IP ?

Oui, si l'adresse est fixe : ajoutez dans UFW une règle allow from pour cette IP. Prévoyez à l'avance une console du fournisseur ou un accès de secours, car une modification de l'adresse IP bloquera la connexion.

À quelle fréquence faut-il vérifier la sécurité d'un VPS ?

Après chaque modification de SSH, du pare-feu ou de la publication d'un port Docker, vérifiez les ports et testez la connexion. Consultez les mises à jour et les journaux au moins une fois par semaine, et testez régulièrement la restauration des sauvegardes.