Sécuriser votre VPS : une checklist à terminer en 20 minutes

Vous ne rendrez jamais un serveur parfaitement sûr. Vous pouvez en faire une cible peu attrayante en une vingtaine de minutes, ce qui détourne pratiquement toutes les attaques automatisées.

1. SSH par clé uniquement

Expliqué en détail dans Clés SSH et accès. C'est l'étape isolée qui a le plus de valeur. Le bruteforce de mots de passe est la méthode d'intrusion la plus courante sur l'internet public, et ceci l'élimine.

PasswordAuthentication no
PermitRootLogin prohibit-password

2. Un pare-feu qui refuse par défaut

N'autorisez que ce que vous servez réellement. Sur Debian/Ubuntu :

apt install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp          # SSH — see the warning below
ufw allow 80,443/tcp      # web
ufw enable
ufw status verbose

Sur la famille RHEL, utilisez firewalld :

firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

Attention : activez le pare-feu pendant que votre session SSH est ouverte et vérifiez que SSH est autorisé avant de vous déconnecter. Si vous changez le port SSH, autorisez d'abord le nouveau port. Voir Notions de base du pare-feu pour les détails, y compris notre interface de maillage privé qui doit toujours être autorisée.

3. Mises à jour de sécurité automatiques

apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades    # choose yes
# verify:
systemctl status unattended-upgrades --no-pager

Sur la famille RHEL, dnf-automatic fait le même travail. Les correctifs de sécurité automatiques referment la fenêtre entre la publication d'une vulnérabilité et son exploitation — qui, en pratique, se compte souvent en heures.

4. Fail2ban

Bloque une IP après plusieurs échecs de connexion, transformant une tentative de bruteforce sans fin en impasse. Voir Notions de base de Fail2ban.

apt install -y fail2ban
systemctl enable --now fail2ban

5. Désactivez ce que vous n'utilisez pas

Chaque service à l'écoute est une porte d'entrée potentielle.

ss -tulpn        # what is listening, and who owns it
systemctl --type=service --state=running   # what is running

Arrêtez et désactivez tout ce que vous n'avez pas demandé. Un serveur minimal est un serveur sûr.

6. Exécutez les services avec des utilisateurs sans privilèges

Les bases de données, applications web et workers ne doivent jamais tourner en root. La plupart des paquets créent automatiquement leur propre utilisateur de service ; utilisez-le. Si vous écrivez votre propre fichier d'unité, définissez explicitement User= et Group=.

7. Protégez les secrets

• Ne commitez jamais de secrets dans git. Utilisez des fichiers d'environnement avec chmod 600.

• Ne rendez jamais un fichier de configuration lisible par tous s'il contient un mot de passe ou une clé.

• Préférez des identifiants par service plutôt qu'un seul identifiant administrateur partagé.

8. Gardez un moyen de revenir

• Vérifiez que la console de secours dans /panel/vps fonctionne avant d'en avoir besoin.

• Faites un instantané avant les changements risqués — voir Redimensionner, instantané et réinstaller.

• Conservez au moins une clé SSH stockée ailleurs que sur votre portable de tous les jours.

9. Surveillez

Un serveur que vous ne regardez jamais est un serveur que vous ne pouvez pas défendre. Ajoutez une vérification de supervision et lisez vos journaux de temps en temps — Lire vos journaux vous montre comment.

Facultatif : détection d'intrusion

Pour les hôtes de plus grande valeur, CrowdSec (blocage collaboratif, licence MIT) et Wazuh (détection d'intrusion sur l'hôte) apportent une vraie profondeur. Les deux sont documentés dans nos guides d'hébergement d'applications.

Pour aller plus loin

• Clés SSH et accès

• Notions de base du pare-feu

• Notions de base de Fail2ban