Cacher l’accès administrateur sur un site WordPress, à savoir wp-admin et wp-login.php, me semble aujourd’hui une pratique assez répandue pour « sécuriser » un site WordPress. Malheureusement, je ne pense pas que ce soit une bonne pratique de sécurité. Voici pourquoi
La sécurité par l’obscurité
Cette pratique de sécurité consiste à déplacer l’URL effective pour se connecter à WordPress. Dans les dessous des plugins comme WPS Hide Login se trouve des directives pour déporter l’URL wp-login.php vers un autre URL, en passant par la réécriture d’URL. Quant à l’accès à l’URL wp-admin, ce type de plugin remplace la redirection vers la page de connexion en une erreur 404 ou en une redirection vers la page d’accueil.
Certes, cette pratique peut rebuter pas mal de robots qui sont programmés à n’utiliser que les URLs par défaut, mais ce n’est pas pour autant que votre site web soit sécurisé. Déjà, il est assez rare que les hébergeurs limitent les erreurs 404 ni par adresse IP, ni par nom de domaine. Donc, votre site web n’est probablement pas immunisé de robots qui tenteraient d’accéder à l’URL en testant différentes combinaisons possibles (une attaque par bruteforce).
Les accès machines (API)
Mais le pire, c’est que wp-login.php n’est pas le seul moyen de se connecter à WordPress. Aujourd’hui, nous avons le REST API et le vieux XML-RPC qui permet également de se connecter au site. Vous ne pouvez donc tout simplement pas vous reposer sur vos lauriers après avoir déplacé wp-login.php. Et, vous ne pouvez malheureusement pas déplacer le REST API. Déjà, déplacer wp-login.php présente des risques d’incompatibilités avec certains plugins (notamment ceux qui pourraient proposer des mécanismes de connexions comme les plugins d’espace membre, de forum ou d’espace client) ; désactiver le XML-RPC se fait, mais quelques vieux plugins risquent d’en avoir toujours besoin ; et REST API, malheureusement, vous ne pouvez pas le déplacer sans casser WordPress.
Vous pouvez remarquer rapidement en ayant un plugin qui comptabilise le nombre de connexions échoué que même si vous déplacez wp-login.php, vous continuez à avoir des robots qui tentent de se connecter.
Alors, qu’est-ce qu’il faut faire pour sécuriser WordPress ?
Au lieu de dépenser vos efforts pour cacher les pages de connexion, vous devriez miser plus sur la sécurisation de la page de connexion lui-même.
Limiter les adresses IP
Autant que possible, limitez l’accès aux pages de connexion et au REST API / XMLRPC par une liste d’adresse IP / géolocalisation. Si vous vivez en France, par exemple, vous pouvez restreindre l’accès uniquement à ce pays.
Il y a plusieurs techniques possibles, que ce soit avec un plugin, avec un .htaccess, dans les configurations serveurs voire même au niveau du proxy CDN (comme Cloudflare). A titre personnel, je recommande toujours de régler ce problème le plus tôt possible : donc au niveau du CDN, ou au niveau de la configuration serveur.
Limiter les accès robots
Si vous êtes dans l’obligation d’exposer votre page de connexion (site ayant un accès membre, par exemple), assurez-vous de bloquer les robots sur ces pages.
La méthode la plus classique est d’y activer un système captcha. Malheureusement, le captcha peut être relou pour l’expérience utilisateur et en plus, il est aujourd’hui facilement outrepassé par les robots grâce à de l’IA et aux fermes de clics.
La solution que je recommande est de se baser sur une solution de réputation. Beaucoup de services proposent aujourd’hui (gratuit ou payant) une certaine liste d’adresse IP qui ont déjà attaqué d’autres sites WordPress. Il suffira d’ajouter cette liste dans vos listes de blocages.
C’est d’ailleurs pour cette raison que les solutions de pare-feu en proxy comme Cloudflare et Sucuri sont puissants. En effet, ils peuvent détecter, sur une très large échelle, le comportement d’une adresse IP sur des millions de sites et repérer ainsi les robots d’attaques pour pouvoir ensuite les bloquer à échelle globale.
Vous pouvez aussi bloquer les adresses IP non résidentielles (adresses IP qui sont dans des datacenters), qui représente une masse non négligeable des attaquants. Malheureusement, je n’ai trouvé à ce jour aucune liste assez fiable.
Limitez les tentatives infructueuses
On ne dirait pas comme ça, mais WordPress n’en est pas immunisé, de nature. Il faut implémenter vous-même une solution pour limiter les tentatives infructueuses. Personnellement, j’ai implémenté cela par le biais de scripts LUA sur mon serveur NGINX, mais c’est une solution qui peut aussi être implémenté avec un simple plugin.
Certains hébergeurs proposent également cette solution sous forme de règles ModSecurity ou de limitation de trafic L7 sur son serveur web, ou encore les CDN proxy orienté sécurité comme Sucuri.
Utiliser un mot de passe fort et l’authentification à deux facteurs
Évidemment, si votre ensemble nom d’utilisateur / mot de passe est facilement identifiable, alors c’est nécessaire d’améliorer cela en mettant un mot de passe fort (long et complexe) et surtout de mettre l’authentification à deux facteurs afin que, même si les robots passent la page de connexion, l’authentification à deux facteurs vont les garder derrière une autre porte.