Liste de sécurité VPS : étapes de configuration

Le compte à rebours démarre dès que vous obtenez un nouveau VPS : tout serveur exposé à Internet rencontre des scans de bots automatisés quelques minutes après sa mise en ligne. Une base solide de sécurité VPS se construit dans ces premières heures, avant d'installer la moindre application. Dans cet article, je partage la liste de contrôle que je suis, dans l'ordre, pour préparer un serveur Ubuntu/Debian neuf à la production : un utilisateur privilégié, le durcissement de SSH, un pare-feu, fail2ban, les mises à jour de sécurité automatiques et quelques bonnes habitudes essentielles.

1. Première connexion et mise à jour du système

Votre hébergeur vous remet généralement un mot de passe root ou une clé SSH. La toute première tâche consiste à actualiser la liste des paquets et à mettre à jour ceux installés. Les anciens paquets embarquent des failles connues ; mettre à jour est le gain de sécurité le moins cher qui soit.

apt update && apt upgrade -y

Si une mise à jour du noyau ou d'une bibliothèque est arrivée, redémarrez le serveur une fois : reboot. C'est aussi le bon moment pour régler le fuseau horaire et le nom d'hôte.

2. Créer un utilisateur privilégié (sudo) au lieu de root

Tout faire en root signifie qu'une seule mauvaise commande ou une session compromise peut faire tomber tout le système. Créez votre propre utilisateur et ajoutez-le au groupe sudo :

adduser aslain
usermod -aG sudo aslain

Passez sur le nouvel utilisateur et lancez sudo whoami pour confirmer les privilèges. Désormais vous travaillerez au quotidien avec cet utilisateur, et nous désactiverons bientôt complètement la connexion directe en root.

3. Utiliser une clé SSH, abandonner le mot de passe

La connexion par mot de passe est une porte ouverte aux attaques par force brute. Utilisez plutôt une paire de clés SSH. Si vous n'avez pas de clé sur votre machine, générez-en une :

ssh-keygen -t ed25519 -C "aslain@laptop"

Copiez la clé publique sur le serveur :

ssh-copy-id aslain@IP_SERVEUR

Si vous pouvez désormais vous connecter avec ssh aslain@IP_SERVEUR sans qu'aucun mot de passe ne soit demandé, la clé fonctionne. Ne désactivez pas la connexion par mot de passe avant d'avoir vérifié l'accès par clé, sinon vous risquez de vous verrouiller dehors.

4. Durcir la configuration SSH

Le durcissement de SSH est l'une des étapes les plus rentables côté sécurité VPS. Modifiez /etc/ssh/sshd_config (ou un fichier distinct sous /etc/ssh/sshd_config.d/) :

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Dans l'ordre, ces réglages : bloquent la connexion directe en root, désactivent entièrement l'authentification par mot de passe et n'autorisent que l'accès par clé. Après la modification, redémarrez le service :

systemctl restart ssh

Conseil important : ouvrez un nouveau terminal et tentez de vous reconnecter, mais gardez la session existante ouverte. En cas d'erreur, la session ouverte vous permet de revenir corriger. Changer le port 22 par défaut relève de la sécurité par l'obscurité ; cela n'offre aucune protection réelle mais réduit le bruit dans les logs — vous pouvez le faire, mais cela ne remplace ni un pare-feu ni la connexion par clé.

5. Mettre en place un pare-feu et n'ouvrir que les ports nécessaires

Sous Ubuntu/Debian, l'outil le plus pratique est ufw (Uncomplicated Firewall). La logique est simple : tout refuser, n'autoriser que le nécessaire.

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw enable

Si vous comptez faire tourner un serveur web, ouvrez aussi HTTP et HTTPS :

ufw allow 80/tcp
ufw allow 443/tcp

Vérifiez l'état avec ufw status verbose. Attention : assurez-vous que la règle SSH est en place avant d'activer le pare-feu, sinon vous vous verrouillerez dehors.

6. Bloquer les attaques automatisées avec fail2ban

Même après le passage à la clé, vos logs se remplissent de tentatives de connexion échouées. fail2ban bannit temporairement une IP après un nombre défini d'échecs :

apt install fail2ban -y
systemctl enable --now fail2ban

Les valeurs par défaut offrent une protection SSH raisonnable. Pour personnaliser, créez un fichier /etc/fail2ban/jail.local (ne modifiez pas jail.conf lui-même — il est écrasé à la mise à jour) :

[sshd]
enabled = true
maxretry = 4
bantime = 1h

Vous pouvez voir les IP bannies avec fail2ban-client status sshd.

7. Activer les mises à jour de sécurité automatiques

Les humains oublient de mettre à jour ; l'automatisation, non. Utilisez unattended-upgrades pour appliquer seules les correctifs de sécurité :

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

Par défaut, ce paquet n'installe que les mises à jour des dépôts de sécurité, ce qui évite les sauts de version majeure inattendus. Malgré tout, sur les systèmes critiques, passez vous-même en revue les mises à jour périodiquement.

8. Quelques bonnes habitudes essentielles

Synchronisation de l'heure : lancez timedatectl set-ntp true pour garder l'horloge juste ; c'est important pour les certificats et les logs.
Moindre privilège : faites tourner les services sous leurs propres utilisateurs limités, pas en root.
Sauvegardes : la sécurité, ce n'est pas seulement bloquer les attaques, c'est aussi pouvoir récupérer un mauvais jour. Ne négligez ni la fonction snapshot de votre hébergeur ni des sauvegardes de données régulières.
Surveillance : jetez de temps en temps un œil aux journaux de connexion avec journalctl et last.

Une fois ces étapes devenues une habitude, poser un nouveau serveur sur des bases sûres prend moins d'une demi-heure.

Questions fréquentes

Faut-il changer le port SSH 22 ?

Ce n'est pas obligatoire. Changer le port réduit le bruit automatisé dans les logs mais n'est pas une vraie couche de sécurité. La protection réelle, c'est la connexion par clé, l'authentification par mot de passe désactivée et un pare-feu ; un changement de port ne les remplace pas.

Que se passe-t-il si je désactive le mot de passe et perds ma clé ?

Vous êtes complètement verrouillé hors du serveur. Sauvegardez donc votre clé en lieu sûr et apprenez l'accès à la console web (VNC/recovery) que proposent la plupart des hébergeurs ; vous pourrez vous y connecter pour ajouter une nouvelle clé.

fail2ban et le pare-feu font-ils le même travail ?

Non. Le pare-feu décide quels ports sont ouverts ; fail2ban détecte les comportements malveillants répétés (comme les connexions échouées) qui frappent ces ports ouverts et bannit temporairement l'IP fautive. Les deux se complètent.

Besoin d'aide pour configurer un serveur ? J'accompagne sur le durcissement de serveurs Linux, l'installation de serveurs de jeu/web et le DevOps. Pour parler de votre projet, contactez-moi.