Les 30 premières minutes : liste de vérification pour le durcissement d'un VPS

Un VPS fraîchement créé reçoit sa première sonde SSH en quelques minutes après l'obtention d'une adresse IP. Voici la séquence exacte que j'exécute sur chaque nouvelle machine — prête à copier-coller pour Debian 13, avec un tableau de vérification à la fin.

Hypothèses : une image Debian 13 fraîche depuis votre déploiement VPSRento, vous êtes connecté en root via SSH, et l'IP d'exemple est 185.220.101.14 — remplacez-la par la vôtre. Durée totale : environ une demi-heure. Suivez les étapes dans l'ordre ; l'étape 2 peut vous verrouiller dehors si vous la bâclez.

1. Créez votre utilisateur sudo

Travailler en root, c'est ainsi que les fautes de frappe deviennent des incidents. Créez un vrai utilisateur, donnez-lui sudo, et faites tout à partir de là :

Copy# create the user (you'll set a password — still useful for sudo)
adduser ops

# grant sudo
usermod -aG sudo ops

Tout ce qui suit s'exécute en tant que ops sauf indication contraire.

2. Clés SSH uniquement — pas de mots de passe, pas de connexion root

L'authentification par mot de passe est le plus grand trou sur une machine exposée à Internet. Les bots martèlent le port 22 avec des listes d'identifiants toute la journée, tous les jours. Les clés rendent toute cette classe d'attaque sans objet. Sur votre machine locale:

Copy# generate a keypair if you don't have one (ed25519, no passphrase tradeoff is yours)
ssh-keygen -t ed25519 -C "ops@atlas"

# push the public key to the server
ssh-copy-id [email protected]

Vérifiez que vous pouvez vous connecter avec la clé dans un terminal nouveau terminal — ssh [email protected] — avant de toucher à la configuration. Gardez la session root existante ouverte comme issue de secours. Ensuite, modifiez /etc/ssh/sshd_config:

Copy# /etc/ssh/sshd_config — the three lines that matter
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Copy# validate the config, then reload (Debian 13 uses ssh.service)
sshd -t && systemctl reload ssh

prohibit-password plutôt qu'un fichier plat no pour root délibérément : root peut toujours s'authentifier avec une clé depuis votre poste de travail, ce qui est parfois utile pour la récupération via la console du fournisseur — mais aucun mot de passe ne fonctionnera jamais, pour personne, depuis n'importe où. Confirmez avec sshd -T | grep -E 'passwordauthentication|permitrootlogin'.

3. Pare-feu : refus par défaut, n'autorisez que ce que vous exécutez

ufw de Debian est une couche fine et saine au-dessus de nftables. La politique est la sécurité ; les règles ne sont que des exceptions à celle-ci :

Copyapt update && apt install -y ufw

ufw default deny incoming
ufw default allow outgoing

# SSH stays open — add this BEFORE enabling
ufw allow 22/tcp comment 'SSH'

# whatever your box actually serves, e.g.:
ufw allow 80/tcp comment 'HTTP'
ufw allow 443/tcp comment 'HTTPS'

ufw enable
ufw status verbose

Chaque port que vous ouvrez doit avoir un nom et une raison. Si vous ne pouvez pas nommer à quoi sert un port, il n'obtient pas de règle.

4. fail2ban : ralentissez les bots jusqu'à la rampe

Avec l'authentification par mot de passe désactivée, la force brute est déjà morte — mais fail2ban garde vos journaux lisibles et bannit les scanners qui sondent tout le reste :

Copyapt install -y fail2ban

Copy# /etc/fail2ban/jail.local
[sshd]
enabled  = true
port     = ssh
maxretry = 5
findtime = 10m
bantime  = 1h

Copysystemctl enable --now fail2ban

# watch it work
fail2ban-client status sshd

5. Mises à jour de sécurité automatiques

La CVE non corrigée est un risque plus grand que le redémarrage. unattended-upgrades de Debian installe les mises à jour de sécurité tout seul :

Copyapt install -y unattended-upgrades

# answer Yes to auto-install updates
dpkg-reconfigure -plow unattended-upgrades

La configuration par défaut dans /etc/apt/apt.conf.d/50unattended-upgrades tire uniquement de la suite de sécurité — ce qui est ce que vous voulez sur un serveur : correctifs de sécurité automatiquement, tout le reste quand vous choisissez.

6. Désactivez ce que vous n'exécutez pas

Chaque service en cours d'exécution est une surface d'attaque que vous devez corriger. Voyez ce qui écoute réellement :

Copy# who is listening, on what, as which process
ss -tulpn

# everything enabled at boot
systemctl list-unit-files --state=enabled

# example: you don't run a print server — nobody does
systemctl disable --now cups

La règle : si vous ne pouvez pas dire ce que fait un écouteur, découvrez-le avant de le laisser vivre. Sur une image VPSRento minimale, il devrait y avoir très peu au-delà de sshd et de votre propre application.

7. Optionnel mais recommandé : un plan de gestion WireGuard

La version la plus solide de la sécurité SSH est un SSH qui ne fait pas face à Internet. Installez WireGuard sur la machine, autorisez SSH uniquement dans le tunnel, et le port 22 disparaît de tous les scanners de la planète :

Copyapt install -y wireguard

# /etc/wireguard/wg0.conf — minimal management tunnel
# [Interface] Address = 10.8.0.1/24, ListenPort = 51820

# open the tunnel, not the shell
ufw allow 51820/udp comment 'WireGuard'
ufw allow in on wg0 to any port 22 proto tcp comment 'SSH via WG'
ufw delete allow 22/tcp

systemctl enable --now wg-quick@wg0

Ensuite, vous ssh [email protected] via le tunnel, et l'IP publique répond sur un seul port UDP. Le guide complet WireGuard — clés, pairs, configurations client, QR codes pour téléphone — se trouve dans le guide compagnon.

La checklist en 10 points

Passez en revue ce tableau après chaque nouveau déploiement, et à nouveau après chaque service ajouté :

L'élément 10 mérite une phrase : durcissez d'abord, instantané ensuite, dans cet ordre — un instantané d'une machine propre et durcie est votre retour en arrière pour toute erreur future. Les instantanés hors site quotidiens sont une option à $1.99/mois dans l' espace client. Trente minutes de prévention, un clic d'assurance.