Durcir un VPS neuf en une heure : la checklist du NOC

Vue d'ensemble : les dix étapes

L'ordre n'est pas anodin : on crée l'utilisateur et on dépose la clé SSH avant de désactiver les mots de passe, et on ouvre le pare-feu sur le nouveau port SSH avant de l'activer. Chaque étape laisse le serveur dans un état fonctionnel si vous devez vous arrêter en chemin.

• 1. Mises à jour système — fermer les CVE connues avant tout
• 2. Utilisateur sudo dédié — arrêter de travailler en root
• 3. Clé SSH ed25519 — déposée et testée dans une seconde fenêtre
• 4. Durcissement sshd — clés uniquement, root exclu, port déplacé
• 5. Pare-feu UFW — tout refuser sauf SSH
• 6. fail2ban — bannir les IPs qui insistent
• 7. Mises à jour automatiques — les correctifs de sécurité sans y penser
• 8. Swap — 1 à 2 Go si le VPS a 4 Go de RAM ou moins
• 9. Fuseau horaire et NTP — des journaux qu'on peut relire
• 10. Audit lynis — mesurer le reste de la marge

Deux règles d'or avant de commencer. D'abord : ne fermez jamais votre session root courante tant qu'une seconde session n'a pas prouvé que la nouvelle configuration fonctionne. Ensuite : faites un snapshot dans le tableau de bord VPSPLEX avant l'étape 4 — il coûte 1 $/mois et il vous évitera un reinstall si quelque chose se passe mal.

1. Mises à jour système

L'image ISO déployée a quelques semaines ; les dépôts, eux, connaissent déjà des correctifs postérieurs. On met à jour avant d'ouvrir le moindre service :

apt update && apt upgrade -y
apt install -y curl ufw fail2ban unattended-upgrades

# Si le noyau a été mis à jour, appliquez-le maintenant (avant les étapes suivantes)
[ -f /var/run/reboot-required ] && reboot

2. Créer un utilisateur sudo dédié

Travailler en root par habitude, c'est exécuter chaque copier-coller avec les pouvoirs maximaux — une commande ratée (un espace au mauvais endroit dans un rm -rf) et c'est le reinstall. Créez un utilisateur nommé, ajoutez-le au groupe sudo :

adduser ops
# Choisissez un mot de passe long — il ne servira qu'en console de secours
usermod -aG sudo ops
id ops
# Doit afficher : uid=1000(ops) gid=1000(ops) groups=1000(ops),27(sudo)

Optionnel mais recommandé : verrouillez le mot de passe root. Avec PermitRootLogin no (étape 4), plus personne ne s'authentifie en root par SSH de toute façon ; le verrou empêche aussi l'usage du compte root depuis la console sans passer par sudo :

passwd -l root

3. Clés SSH : génération et dépôt

Sur votre machine locale (pas sur le serveur), générez une clé ed25519 avec une passphrase. Une passphrase protège la clé au repos — disque volé, sauvegarde égarée :

ssh-keygen -t ed25519 -a 100 -C "ops@vpsplex-$(date +%Y)"
# Laissez le chemin par défaut (~/.ssh/id_ed25519)

# Déposez la clé publique sur le VPS (remplacez 203.0.113.10 par votre IP VPSPLEX)
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

# Sous Windows / PowerShell, si ssh-copy-id est absent :
# type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh [email protected] "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

Testez immédiatement dans une seconde fenêtre — la session root actuelle reste ouverte en filet de sécurité :

ssh [email protected]
# Doit vous connecter SANS demander de mot de passe (la passphrase de la clé, si)
sudo -v
# Doit valider votre appartenance au groupe sudo

4. Durcir le démon SSH

Plutôt que de modifier /etc/ssh/sshd_config, déposez un fichier dans sshd_config.d/ : il est lu en priorité, survit aux mises à jour du paquet openssh et se supprime proprement si besoin. Créez /etc/ssh/sshd_config.d/99-vpsplex.conf :

# Port non standard : coupe le bruit des scans, pas les attaquants déterminés
Port 2222
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
# Remplacez "ops" par le nom de votre utilisateur, ou supprimez la ligne
AllowUsers ops

# Validation syntaxique OBLIGATOIRE avant rechargement
sshd -t && echo "config OK"

# Rechargement sans couper les sessions actives
systemctl reload ssh

# Test depuis la machine locale, PORT INCLUS, session root toujours ouverte :
# ssh -p 2222 [email protected]

Soyons honnêtes sur le port : changer 22 en 2222 n'ajoute quasiment aucune sécurité — un scanneur teste les 1 000 ports les plus courants en quelques secondes. Ce que ça supprime, c'est le bruit : chez nous, un VPS en port 22 reçoit 30 000 à 80 000 tentatives par jour dans les logs, un VPS en port non standard moins d'une centaine. La vraie protection, c'est PasswordAuthentication no : sans mot de passe accepté, un bot ne peut rien, quel que soit le port.

Verrouillé dehors quand même ? La console web du tableau de bord VPSPLEX vous donne un accès root hors SSH : c'est votre porte de secours permanente, même après avoir cassé sshd. Notez aussi que notre anti-DDoS ne filtre jamais le trafic vers vos ports ouverts, y compris un SSH en 2222.

5. Pare-feu UFW : tout refuser, sauf SSH

UFW est un frontal simple sur iptables/nftables. La politique qui tient la route sur un serveur frais : tout bloquer en entrée, tout autoriser en sortie, ouvrir uniquement ce dont vous avez besoin. À ce stade, c'est un seul port :

ufw default deny incoming
ufw default allow outgoing

# SSH — le port que vous avez défini à l'étape 4
ufw allow 2222/tcp comment 'SSH'

# Quand vous ajouterez un service (WireGuard, HTTP...), ouvrez-le ICI en premier

ufw enable
ufw status verbose

Le piège classique : activer UFW avant d'autoriser son propre port SSH, et se déconnecter définitivement. Les sessions déjà établies restent généralement actives (le trafic de retour est autorisé), mais toute nouvelle connexion sera refusée. Respectez l'ordre des commandes ci-dessus et tout ira bien.

6. fail2ban : bannir les persévérants

Même avec l'authentification par clé uniquement, vos logs se rempliront de tentatives — elles échoueront, mais elles consomment du CPU et masquent les vrais événements. fail2ban lit les journaux SSH et bannit les adresses IP qui dépassent un seuil d'échecs, via UFW :

[DEFAULT]
# Le bannissement passe par UFW, cohérent avec notre pare-feu
banaction = ufw
backend = auto

[sshd]
enabled = true
# Le port SSH durci à l'étape 4
port = 2222
filter = sshd
maxretry = 3
findtime = 10m
bantime = 1h
# Une IP récidiviste finit bannie une semaine
bantime.increment = true
bantime.factor = 24

systemctl enable --now fail2ban
fail2ban-client status sshd
# Après quelques heures : "Currently banned" > 0 = les scans sont arrêtés à la porte

Note de lucidité : avec PasswordAuthentication no, fail2ban n'est plus indispensable — il n'y a plus rien à deviner. Il reste utile comme défense en profondeur (il coupe le bruit réseau) et comme garde-fou si vous réactivez un jour un accès par mot de passe sur un service donné. Ne le déployez pas pour l'oublier aussitôt : vérifiez de temps en temps fail2ban-client status.

7. Mises à jour automatiques de sécurité

La plupart des compromissions de VPS « lambda » exploitent des CVE corrigées depuis des semaines. unattended-upgrades applique seul les correctifs de sécurité du dépôt — sans redémarrage forcé, que vous gardez sous votre contrôle. Activez-le :

# Activation automatique (répondez Oui)
dpkg-reconfigure --priority=low unattended-upgrades

# Ou en écrivant directement la configuration :
cat > /etc/apt/apt.conf.d/20auto-upgrades <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";
EOF

# Simulation : liste ce qui serait mis à jour
unattended-upgrade --dry-run -d 2>&1 | grep -i security | head

Les mises à jour de noyau sont installées mais pas appliquées : c'est le fichier /var/run/reboot-required qui vous le signalera. Sur un VPS de production, planifiez un redémarrage mensuel à heure creuse — ou automatisez-le avec unattended-upgrades configuré pour redémarrer à 4 h du matin quand le fichier apparaît, si l'uptime n'est pas critique pour vous.

8. Swap (si 4 Go de RAM ou moins)

Un processus qui dépasse la RAM sur un serveur sans swap reçoit le SIGKILL immédiatement — MySQL qui disparaît à 3 h du matin, c'est presque toujours ça. Sur nos VPS-1 Coast (2 Go) et VPS-2 Reef (4 Go), ajoutez un fichier swap de 2 Go sur le NVMe :

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

# Le swap est un amortisseur de secours, pas de la RAM : l'utiliser à 10 % max
echo 'vm.swappiness=10' > /etc/sysctl.d/90-swappiness.conf
sysctl --system

free -h

Sur un VPS-3 Horizon (8 Go) ou plus, le swap est optionnel : s'il ne sert jamais, il ne coûte rien non plus. Une précision d'honnêteté : le swap sur disque NVMe est 100 fois plus lent que la RAM — il sauve d'un crash, il ne rend pas un serveur sous-dimensionné rapide.

9. Fuseau horaire et NTP

Des journaux avec un fuseau horaire incohérent sont des journaux inutilisables quand il faut corréler un incident. systemd-timesyncd synchronise déjà l'heure sur les images récentes ; il ne reste qu'à régler le fuseau et vérifier :

timedatectl set-timezone Europe/Paris
timedatectl set-ntp true
timedatectl status
# "System clock synchronized: yes" + fuseau correct = terminé

10. Audit final avec lynis

Lynis balaie le système et produit un « hardening index » chiffré avec les points restants, triés par criticité. Une Debian 12 fraîche durcie avec cette checklist se situe typiquement entre 68 et 74 :

apt install -y lynis
lynis audit system --quick 2>/dev/null | tail -30
# Retenez l'"Hardening index" et les avertissements ; relisez /var/log/lynis.log pour le détail

Ce qui reste après cette checklist relève du cas par cas : les recommandations kernel (sysctl réseau), auditd pour la traçabilité, ou la désactivation des services que vous n'utilisez pas (systemctl list-unit-files --state=enabled pour l'inventaire). N'appliquez jamais un durcissement aveuglément — chaque durcissement se paie en confort ou en compatibilité. Et si ce VPS héberge quelque chose de réellement important, la suite logique se trouve dans nos guides chiffrement LUKS et sauvegardes 3-2-1.

Questions fréquentes