La sécurité d’un site web est un sujet important dont on parle souvent seulement après la première vraie problématique.
Tout dépend de l’endroit et de la manière dont votre WordPress est hébergé.
Si votre site se trouve sur un hébergement mutualisé (shared hosting), la sécurité de base relève du fournisseur d’hébergement, avec tous les avantages et les inconvénients que cela implique. Vous avez peu de contrôle, mais aussi peu de responsabilités — il ne reste souvent que la confiance et l’espoir 🙂.
Un autre niveau commence lorsque vous utilisez votre propre serveur — virtuel (VPS) ou physique (bare metal). Cela offre beaucoup plus de liberté, de possibilités et de contrôle, mais impose aussi une responsabilité différente : la sécurité du serveur et du site devient votre responsabilité.
Comme WordPress est le CMS le plus populaire au monde, il est en permanence la cible d’attaques automatisées : brute-force, scans de /wp-login.php, tentatives de deviner les mots de passe, etc. C’est pourquoi, dans cet article, je présente une méthode simple et fiable pour protéger l’interface d’administration de WordPress sans utiliser de plugins — en limitant l’accès à /wp-admin et wp-login.php de façon à ce que :
– le site reste public (HTTP/HTTPS) via une adresse IP ou un nom de domaine
– /wp-admin et wp-login.php ne soient accessibles que via Tailscale
Tailscale est un service qui permet de créer un réseau VPN privé entre vos appareils.
Pour un nombre limité de dispositifs, il est gratuit et beaucoup plus simple à utiliser que la configuration manuelle de WireGuard ou d’un VPN classique.
Alors, on se sert un café ou un thé — et on commence 🙂
Conditions initiales
Pour cette démonstration, j’utilise une machine virtuelle dans Proxmox avec une pile LEMP et WordPress installé.
OS : Ubuntu 22.04 LTS
Web : nginx
PHP : php-fpm 8.4
WordPress est installé dans : /var/www/html/
L’accès au site se fait via l’adresse IP : 192.168.0.210
Je n’ai pas configuré de DNS ; l’accès au site se fait donc uniquement par adresse IP, mais en pratique cela ne change rien au principe.
Tailscale n’est pas encore installé.
Vérification de l’accès à WordPress (à titre informatif)
Avant de commencer, on vérifie simplement l’accès à WordPress en utilisant l’adresse IP depuis mon réseau domestique.
Installation de Tailscale sur le serveur
Sur la page d’installation de Tailscale, il faut choisir Linux server et non Client device.
Ensuite, on copie le script généré et on l’exécute sur la VM où WordPress est installé.
Après cela, on démarre Tailscale :
tailscale up
Dans le navigateur, on autorise le serveur dans son compte Tailscale.
Une fois l’authentification terminée, le serveur reçoit une adresse IP du type 100.x.y.z.
Pour vérifier :
tailscale ip
Cette adresse IP est accessible uniquement depuis ton réseau Tailscale.
Installation sur le client (ton ordinateur)
Pour accéder à /wp-admin depuis ton poste, il faut aussi installer Tailscale sur ta machine. Télécharge simplement l’application depuis tailscale.com/download — disponible pour Windows, macOS, Linux, iOS et Android. Une fois connecté avec le même compte, ta machine rejoindra automatiquement le même réseau privé que le serveur, et l’adresse 100.x.y.z deviendra accessible depuis ton navigateur.
Vérifier que nginx écoute toujours publiquement
À cette étape, le site fonctionne exactement comme avant :
http://192.168.0.210 — OK
http://192.168.0.210/wp-admin — encore OK
C’est normal. Les restrictions ne sont pas encore activées.
Sauvegarde de la configuration nginx
sudo cp /etc/nginx/sites-available/default \ /etc/nginx/sites-available/default.bak
Si quelque chose se passe mal, tu pourras revenir en arrière instantanément.
Restriction de l’accès à wp-admin et wp-login.php
On ouvre la configuration nginx du site :
sudo nano /etc/nginx/sites-available/default
Il faut ajouter les blocs suivants À L’INTÉRIEUR du bloc server { }.
J’utilise mon adresse IP comme exemple ; pense à remplacer par la tienne.
# Limiter l'accès à wp-login.php uniquement via Tailscale
location = /wp-login.php {
allow 100.64.0.0/10; # Plage d'adresses Tailscale
allow 100.67.158.3; # Ton IP Tailscale spécifique (optionnel si range est là)
deny all;
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.4-fpm.sock;
}
# Limiter l'accès au répertoire /wp-admin/ uniquement via Tailscale
location /wp-admin/ {
allow 100.64.0.0/10;
allow 100.67.158.3;
deny all;
# Indispensable pour exécuter les scripts PHP dans l'administration
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.4-fpm.sock;
}
try_files $uri $uri/ /wp-admin/index.php?$args;
}
100.64.0.0/10 — plage CGNAT officielle utilisée par Tailscale.
Note : si ton IP Tailscale est dans la plage 100.64.0.0/10 (ce qui est toujours le cas), la ligne allow 100.67.158.3 est redondante — la règle du range suffit. Elle est incluse ici uniquement à titre d’illustration.
Vérification de la configuration nginx
sudo nginx -t
Résultat attendu :
syntax is ok test is successful
S’il y a une erreur, ne redémarre pas nginx : corrige d’abord la configuration.
Rechargement de nginx
sudo systemctl reload nginx
La configuration est appliquée sans interrompre le service.
Configuration des paramètres WordPress
Cette étape est nécessaire pour éviter que WordPress ne redirige automatiquement depuis l’adresse Tailscale vers le domaine public.
Dans le fichier wp-config.php :
sudo nano /var/www/html/wp-config.php
Il faut ajouter le code au-dessus de la ligne :
/* That’s all, stop editing! */
Ajoute ensuite ce qui suit (n’oublie pas d’adapter les adresses IP à ton environnement) :
/* Admin access via Tailscale only, frontend stays on LAN IP */
if (isset($_SERVER['HTTP_HOST']) && $_SERVER['HTTP_HOST'] === '100.67.158.3') {
define('WP_HOME', 'http://100.67.158.3');
define('WP_SITEURL', 'http://100.67.158.3');
}
Tests
Sans Tailscale
http://192.168.0.210/wp-admin → 403 Forbidden
http://192.168.0.210/wp-login.php → 403 Forbidden
Le site lui-même reste accessible et fonctionne normalement.
Via Tailscale
Depuis un ordinateur connecté à Tailscale, ouvre dans le navigateur :
http://100.x.y.z/wp-admin
Dans mon cas:
http://100.67.158.3/wp-admin
L’interface d’administration est accessible et fonctionne correctement.
Accès d’urgence (recommandé)
Si, pour une raison quelconque, Tailscale n’est pas disponible :
sudo mv /etc/nginx/sites-available/default.bak \ /etc/nginx/sites-available/default sudo systemctl reload nginx
L’accès à l’interface d’administration redevient alors public.
Au final, on obtient un schéma de protection simple, mais très efficace. Le site WordPress lui-même reste entièrement public et accessible via une adresse IP ou un nom de domaine, sans aucune restriction pour les visiteurs. En revanche, l’interface d’administration n’est plus exposée sur Internet et devient invisible pour les scanners automatiques, les bots et les attaques par force brute : l’accès à /wp-admin et wp-login.php n’est possible que depuis le réseau privé Tailscale.
Tout cela est mis en place sans aucun plugin WordPress et sans modifier le fonctionnement interne du CMS. Le contrôle se fait au niveau de nginx, exactement là où il doit se trouver du point de vue de la sécurité. Cette approche est parfaitement adaptée aux environnements de test, aux serveurs maison et aux VPS, et peut ensuite être déployée en production sans changer la logique de fonctionnement du site.
IMPORTANT
Ne ferme jamais l’accès SSH au serveur. Dans toute configuration où l’accès à l’admin est restreint, c’est ton seul moyen garanti de reprendre rapidement le contrôle si quelque chose tourne mal.
Garde toujours une copie de sauvegarde du fichier de configuration nginx avec l’extension .bak. C’est un détail, mais ça peut te sauver des heures de stress : un simple mv suivi d’un reload, et tout refonctionne.
Teste impérativement la configuration sur un serveur de test, comme tu l’as prévu. Même si le fichier de configuration semble parfait, le comportement réel de WordPress et de nginx peut parfois réserver des surprises, notamment avec les redirections.
Sois particulièrement attentif si tu utilises un CDN, comme Cloudflare. Dans ce cas, WordPress et nginx verront l’adresse IP du CDN et non celle fournie par Tailscale, ce qui peut fausser la logique de restriction d’accès. C’est un point à prendre en compte avant tout déploiement en production.
Bonne chance!