Comment durcir un VPS Debian 12 en 2026

Vous venez de recevoir les accès root de votre VPS tout neuf. Avant d'installer quoi que ce soit, il y a un travail invisible mais critique à faire : le durcissement. Un serveur Debian 12 par défaut est fonctionnel, mais certainement pas sécurisé. Bots, scans de ports, tentatives de brute-force — votre IP sera sondée dans les minutes qui suivent sa mise en ligne.

Ce guide couvre les 10 étapes que j'applique systématiquement sur chaque VPS que je configure pour mes clients. Rien de théorique : que des commandes concrètes, testées en production.

1. Créer un utilisateur non-root avec sudo

Travailler en root est une mauvaise habitude qui finit toujours par coûter cher. La première chose à faire est de créer un utilisateur dédié à l'administration.

adduser deploy
usermod -aG sudo deploy

Déconnectez-vous et reconnectez-vous en tant que deploy pour la suite. Toutes les commandes ci-dessous supposent que vous utilisez sudo.

2. Verrouiller SSH : clé uniquement, port non standard

Sur votre machine locale, générez une paire de clés Ed25519 si ce n'est pas déjà fait, puis envoyez la clé publique sur le serveur :

# Sur votre machine locale
ssh-keygen -t ed25519 -C "deploy@monvps"
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@IP_DU_VPS

Ensuite, éditez la configuration du démon SSH sur le serveur. Voici les directives essentielles à modifier dans /etc/ssh/sshd_config :

Port 2244
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2

Redémarrez le service et testez dans un second terminal avant de fermer votre session active. C'est le genre d'erreur qui vous enferme dehors :

sudo systemctl restart sshd

3. Configurer le pare-feu avec UFW

UFW est le front-end le plus lisible pour iptables/nftables. On autorise uniquement ce qui est strictement nécessaire :

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2244/tcp comment 'SSH custom'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable
sudo ufw status verbose

Pensez à adapter le port SSH si vous avez choisi autre chose que 2244. Et n'activez jamais UFW avant d'avoir autorisé votre port SSH — sinon, vous perdez l'accès.

4. Installer et configurer Fail2ban

Fail2ban surveille les logs et bannit automatiquement les IP qui échouent trop de tentatives de connexion. Indispensable même avec l'authentification par clé, parce que les scans génèrent du bruit dans vos logs et consomment des ressources.

sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Éditez /etc/fail2ban/jail.local et ajoutez un bloc dédié à SSH :

[sshd]
enabled  = true
port     = 2244
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
findtime = 600
bantime  = 3600
action   = %(action_mwl)s

sudo systemctl enable fail2ban
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

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

Les failles critiques n'attendent pas que vous soyez disponible un mardi matin. unattended-upgrades applique les patchs de sécurité sans intervention manuelle :

sudo apt install unattended-upgrades apt-listchanges -y
sudo dpkg-reconfigure -plow unattended-upgrades

Vérifiez que le fichier /etc/apt/apt.conf.d/50unattended-upgrades contient bien la ligne pour les mises à jour de sécurité Debian. Vous pouvez aussi activer les notifications par mail pour savoir ce qui a été installé.

// Dans 50unattended-upgrades
Unattended-Upgrade::Mail "admin@votredomaine.fr";
Unattended-Upgrade::MailReport "on-change";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

6. Durcir le noyau avec sysctl

Le noyau Linux expose des paramètres réseau qui, par défaut, sont permissifs. On va réduire la surface d'attaque en désactivant ce qui n'a aucune raison d'être actif sur un serveur :

# /etc/sysctl.d/99-hardening.conf

# Désactiver le routage de paquets
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

# Ignorer les ICMP redirects (attaque MITM)
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# Protection contre le SYN flood
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048

# Ignorer les pings broadcast (Smurf attack)
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Enregistrer les paquets suspects
net.ipv4.conf.all.log_martians = 1

# ASLR maximum
kernel.randomize_va_space = 2

sudo sysctl --system

Si votre VPS fait tourner des conteneurs Docker ou sert de routeur VPN, vous devrez réactiver ip_forward. Adaptez selon votre cas d'usage, mais partez toujours du principe du moindre privilège.

7. Désactiver les services inutiles

Un service qui tourne est une surface d'attaque. Listez ce qui est actif et désactivez tout ce que vous n'utilisez pas :

sudo systemctl list-units --type=service --state=running

# Exemples fréquents à désactiver sur un VPS
sudo systemctl disable --now rpcbind
sudo systemctl disable --now avahi-daemon
sudo systemctl disable --now cups

Vérifiez aussi les ports ouverts avec ss -tlnp. Tout port en écoute que vous ne reconnaissez pas mérite une investigation. Sur un VPS web classique, vous ne devriez voir que vos ports SSH, HTTP et HTTPS.

8. Centraliser et surveiller les logs

Les logs sont votre seule source de vérité en cas d'incident. Assurez-vous que rsyslog est actif et configurez une rotation raisonnable pour ne pas saturer le disque :

sudo apt install rsyslog logrotate -y
sudo systemctl enable rsyslog

Pour une surveillance active, installez logwatch qui vous envoie un résumé quotidien par mail :

sudo apt install logwatch -y
# Rapport quotidien envoyé par mail
sudo logwatch --detail High --mailto admin@votredomaine.fr --range today

Si vous gérez plusieurs serveurs, envisagez un stack de centralisation type Loki + Grafana ou un simple envoi syslog vers un collecteur distant. Mais pour un VPS unique, logwatch suffit largement.

9. Mettre en place une détection d'intrusion basique

AIDE (Advanced Intrusion Detection Environment) prend un instantané de votre système de fichiers et vous alerte si quelque chose change de manière inattendue — binaire modifié, fichier de config altéré, permission suspecte :

sudo apt install aide -y
sudo aideinit
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Planifiez une vérification quotidienne via cron :

# /etc/cron.daily/aide-check
#!/bin/bash
/usr/bin/aide --check | mail -s "AIDE report $(hostname)" admin@votredomaine.fr

Après chaque mise à jour légitime du système, pensez à regénérer la base AIDE avec sudo aide --update, sinon vous serez noyé de faux positifs.

10. Derniers ajustements : bannière, umask et comptes inutilisés

Quelques réglages souvent négligés qui complètent le durcissement :

# Bannière d'avertissement légal
echo "Accès non autorisé interdit. Toute activité est journalisée." | sudo tee /etc/issue.net
# Activer la bannière dans sshd_config
# Banner /etc/issue.net

# Umask restrictif par défaut
sudo sed -i 's/^UMASK.*/UMASK 027/' /etc/login.defs

# Verrouiller les comptes système inutilisés
sudo passwd -l www-data
sudo passwd -l nobody

Enfin, faites un dernier passage avec lynis, un outil d'audit qui vous donnera un score de durcissement et des recommandations supplémentaires :

sudo apt install lynis -y
sudo lynis audit system

Visez un score au-dessus de 80. En dessous, il y a probablement des quick wins que vous avez ratés.

Conclusion

Ces 10 étapes ne rendent pas votre serveur invulnérable — rien ne le peut. Mais elles éliminent la grande majorité des vecteurs d'attaque opportunistes. La plupart des compromissions de VPS exploitent des défauts de configuration basiques : mot de passe root actif, pas de pare-feu, services exposés inutilement. En appliquant ce guide, vous passez de la catégorie « cible facile » à « pas rentable à attaquer ».

Le durcissement n'est pas un one-shot. Revenez-y régulièrement, suivez les CVE qui concernent vos paquets, et testez vos défenses avec des scans Nmap depuis l'extérieur.