Sécuriser un VPS : la check-list de départ
Clés SSH, pare-feu, mises à jour automatiques, sauvegardes : les réglages à faire dès la création d'un VPS pour éviter les attaques les plus courantes.
- Un VPS est scanné par des robots dans les minutes qui suivent sa création
- Connexion par clé SSH uniquement, mots de passe désactivés
- Pare-feu qui n'ouvre que les ports utiles, en se méfiant de Docker
- Mises à jour de sécurité automatiques et sauvegardes hors du serveur
Un VPS reçoit une adresse IP publique dès sa création, et des robots parcourent en permanence Internet à la recherche de serveurs mal protégés. Dans les minutes qui suivent la mise en ligne, les premières tentatives de connexion SSH arrivent. La bonne nouvelle : une demi-heure de configuration suffit à écarter l'immense majorité de ces attaques. Voici la check-list à suivre, dans l'ordre, avant d'installer quoi que ce soit.
Les commandes ci-dessous concernent Ubuntu et Debian, les systèmes les plus courants sur les VPS.
1. Mettre le système à jour
Première chose à faire, avant tout le reste :
apt update && apt upgrade -y
L'image fournie par l'hébergeur date souvent de plusieurs semaines : des correctifs de sécurité vous attendent.
2. Créer un utilisateur personnel
Travailler en permanence avec le compte root est risqué : une erreur de frappe peut tout casser, et c'est le compte que les robots ciblent. Créez votre propre utilisateur avec les droits d'administration :
adduser alice
usermod -aG sudo alice
3. Se connecter par clé SSH
Une clé SSH remplace le mot de passe par une paire de clés cryptographiques, impossible à deviner. Sur votre ordinateur, générez une clé si vous n'en avez pas :
ssh-keygen -t ed25519
Puis copiez la clé publique sur le serveur :
ssh-copy-id alice@IP_DU_SERVEUR
Beaucoup d'hébergeurs, comme Hetzner, permettent aussi d'ajouter votre clé publique dès la création du serveur : c'est encore mieux.
Vérifiez que vous pouvez vous connecter avec la clé, dans un second terminal, avant de passer à l'étape suivante.
4. Désactiver les mots de passe et la connexion root
Éditez la configuration SSH (/etc/ssh/sshd_config, ou un fichier dans /etc/ssh/sshd_config.d/) :
PasswordAuthentication no
PermitRootLogin no
Redémarrez le service SSH :
sudo systemctl restart ssh
Gardez votre session ouverte et testez une nouvelle connexion avant de fermer : si quelque chose cloche, vous pourrez encore corriger. En dernier recours, la console web de l'hébergeur permet toujours d'accéder au serveur.
5. Activer un pare-feu
UFW est le pare-feu le plus simple sur Ubuntu. N'ouvrez que ce qui est nécessaire :
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
Les ports 80 et 443 servent au web (HTTP et HTTPS) : ne les ouvrez que si vous hébergez un site ou un service web.
Le piège Docker : Docker modifie lui-même les règles réseau, et un port publié par un conteneur (ports: "5678:5678") peut être accessible depuis Internet malgré UFW. Publiez uniquement les ports du reverse proxy, ou liez les autres à la boucle locale ("127.0.0.1:5678:5678"). Beaucoup d'hébergeurs proposent aussi un pare-feu réseau dans leur console, en amont du serveur : utilisez-le en complément.
6. Automatiser les mises à jour de sécurité
Le paquet unattended-upgrades installe automatiquement les correctifs de sécurité :
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
Pensez aussi à mettre à jour vos conteneurs Docker régulièrement : ils ne sont pas couverts par ce mécanisme.
7. Limiter les tentatives de connexion
Fail2ban surveille les journaux et bannit temporairement les adresses qui multiplient les échecs :
sudo apt install fail2ban
Sa configuration par défaut protège déjà SSH. Avec des clés SSH, il sert surtout à réduire le bruit, mais il protège aussi d'autres services exposés.
8. Mettre en place les sauvegardes
La sécurité, c'est aussi pouvoir revenir en arrière. Deux niveaux complémentaires :
- les sauvegardes ou instantanés de l'hébergeur, activables en un clic dans la console, pour restaurer tout le serveur ;
- une sauvegarde de vos données (volumes Docker, bases) vers un stockage extérieur au serveur, avec un outil comme restic ou borg.
Testez une restauration au moins une fois.
La check-list résumée
| Étape | Fait ? |
|---|---|
| Système à jour | ☐ |
| Utilisateur personnel avec sudo | ☐ |
| Connexion par clé SSH testée | ☐ |
| Mots de passe et root désactivés en SSH | ☐ |
| Pare-feu actif, ports minimaux | ☐ |
| Ports Docker vérifiés | ☐ |
| Mises à jour automatiques | ☐ |
| Fail2ban | ☐ |
| Sauvegardes hors serveur, restauration testée | ☐ |
Votre serveur est prêt. Vous pouvez maintenant Installer n8n sur un VPS : le guide pas à pas ou explorer d'autres projets dans Auto-hébergement : par où commencer ?. Et n'oubliez pas de protéger aussi le compte de votre hébergeur avec la Double authentification : quelle méthode choisir ? : c'est par là qu'un attaquant prendrait le contrôle de tout.
Questions fréquentes
Faut-il changer le port SSH ?
Cela réduit le bruit dans les journaux, car les robots testent surtout le port 22, mais ce n'est pas une protection réelle. La vraie sécurité vient des clés SSH et de la désactivation des mots de passe.
Fail2ban est-il encore utile avec des clés SSH ?
Moins indispensable, puisque les tentatives par mot de passe échouent de toute façon. Il reste utile pour limiter le bruit et protéger d'autres services exposés, comme un formulaire de connexion web.
Docker contourne-t-il le pare-feu UFW ?
Oui, c'est un piège classique. Docker modifie directement les règles réseau, si bien qu'un port publié par un conteneur peut rester accessible malgré UFW. Publiez uniquement les ports nécessaires, ou liez-les à 127.0.0.1 quand un reverse proxy fait l'intermédiaire.