Sécuriser un VPS Debian 12 pour WordPress : checklist pratique 2026

WordPress attire les bots. Pas parce que WordPress est particulièrement vulnérable — un WordPress à jour avec des plugins maintenus est correct — mais parce que c’est prévisible. /wp-login.php, xmlrpc.php, /wp-admin/ : tout le monde sait où chercher. Si ton VPS est accessible sur internet depuis plus de 24 heures sans protection, le log auth est déjà plein de tentatives.

Voilà ce que j’applique sur chaque nouveau VPS Debian 12 Bookworm avant d’installer quoi que ce soit d’autre.

SSH : port non standard, clé uniquement

Premier réflexe : fermer le mot de passe SSH. C’est la surface d’attaque la plus évidente.

# S'assurer d'avoir une clé SSH uploadée avant de toucher à sshdconfig
# Modifier /etc/ssh/sshdconfig
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
Port 2222   # changer le port par défaut

sudo systemctl restart sshd

[warning]Ne ferme pas ta session SSH avant d’avoir ouvert un second terminal et vérifié que tu peux te connecter avec le nouveau port et la nouvelle config. Un sudo sshd -t avant le restart permet de valider la syntaxe.[/warning]

Changer de port n’est pas de la sécurité par obscurité pure : ça élimine 90% des scans automatiques qui frappent uniquement le port 22. Les logs auth.log deviennent lisibles.

UFW : règles minimales

UFW est installé sur Debian mais inactif par défaut.

sudo apt install -y ufw

# Politique par défaut : refuser tout entrant, autoriser tout sortant
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Autoriser SSH sur le port choisi
sudo ufw allow 2222/tcp

# Autoriser HTTP et HTTPS
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Activer
sudo ufw enable
sudo ufw status verbose

Si tu utilises un port MySQL distant ou une connexion à un NAS via 2.5GbE dédié, ajoute les règles correspondantes au même endroit — pas après, pas « quand j’en aurai besoin ». La liste des règles UFW doit refléter exactement ce qui est ouvert.

Mises à jour automatiques : activer et surveiller

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

Ça active les mises à jour de sécurité automatiques pour Debian. Par défaut, ça touche uniquement le repo debian-security, pas les mises à jour ordinaires — comportement correct.

Vérifier ce qui est configuré :

cat /etc/apt/apt.conf.d/50unattended-upgrades | grep -v '//|^$'

La directive Unattended-Upgrade::Automatic-Reboot est false par défaut. Je la laisse à false — un reboot automatique à 2h du matin sur un VPS de prod peut surprendre si un service ne redémarre pas proprement.

Pour savoir si un reboot est nécessaire après une mise à jour du noyau :

sudo apt install -y needrestart
# Après un apt upgrade, needrestart s'exécute automatiquement et liste les services à redémarrer

fail2ban : bloquer les bruteforce sur WordPress

fail2ban analyse les logs et bannit les IPs qui échouent trop souvent.

sudo apt install -y fail2ban

Configuration de base dans /etc/fail2ban/jail.local (créer le fichier s’il n’existe pas) :

[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 5

[sshd]
enabled = true
port    = 2222
logpath = /var/log/auth.log

[nginx-http-auth]
enabled  = true
logpath  = /var/log/nginx/error.log

[wordpress-auth]
enabled  = true
port     = http,https
logpath  = /var/log/nginx/access.log
filter   = wordpress-auth
maxretry = 5
bantime  = 86400

Pour le filtre WordPress, créer /etc/fail2ban/filter.d/wordpress-auth.conf :

[Definition]
failregex = ^ . "POST /wp-login.phps
            ^ . "POST /xmlrpc.phps
ignoreregex =

sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status wordpress-auth

Après 48h : vérifie sudo fail2ban-client status wordpress-auth. Sur you.arewel.com, j’ai régulièrement 20 à 40 IPs bannies dans la jail WordPress. C’est normal.

Désactiver xmlrpc.php côté nginx

fail2ban banit après les tentatives. nginx peut couper avant :

location = /xmlrpc.php {
    deny all;
    return 444;
}

Si tu n’utilises pas Jetpack ou la publication mobile WordPress, xmlrpc.php est inutile. Le fermer dans nginx coûte zéro et supprime une surface d’attaque.

Ce qui m’a coûté du temps

Le premier VPS que j’ai « durci » avec cette checklist, j’ai oublié d’autoriser le port SSH dans UFW avant d’activer le firewall. Ça m’a valu une session de recovery via la console OVH. Le genre de truc qu’on ne fait qu’une fois.

L’autre erreur classique : modifier sshd_config avec PermitRootLogin no sur un VPS où tu te connectes encore en root. Résultat immédiat : locked out. Toujours créer un utilisateur non-root avec sudo avant de changer cette option.

Ce que cette checklist ne couvre pas

• Certificats TLS : Let’s Encrypt via Certbot ou ACME, c’est un article à part
• Sauvegardes : snapshots VPS OVH + dump MySQL dans un cron, traité séparément
• WordPress lui-même : mises à jour automatiques des plugins, limiter les rôles utilisateurs, désactiver l’éditeur de fichiers — ça dépasse la couche OS

En l’état, cette base couvre l’essentiel. Un VPS qui applique ces six points résiste à 95% des attaques automatiques qui ciblent WordPress.

Article hors série