Augmenter (un peu) la sécurité de WordPress avec Fail2ban

Cet article a été publié il y a 9 ans 2 mois 14 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Le trafic du blog augmente. Rançon de ce succès, j’ai eu droit à quelques tentatives de brute-force sur la page d’administration de WordPress. Et si j’utilise Fail2ban sur le serveur, je me suis donc rendu compte que je ne lui avais pas donné toute l’attention qu’il mérite, et qu’on peut s’en servir pour protéger WordPress. Plusieurs méthodes, dont une que j’aime un peu plus.

En effet, même si la tentative pour accéder à l’administration échoue, comme le site répond normalement d’un point de vue HTTP, les requêtes sont enregistrées dans le log access comme n’importe quelle requête. Il faut donc dire à fail2ban d’agir différemment.

Pour ceux qui ne le sauraient pas, c’est un logiciel qui surveille les fichiers journaux de vos applications et prend des décisions en fonction de la situation. Typiquement, par exemple du côté du serveur SSH, si une même adresse est repérée trop de fois dans un laps de temps très court, et tout particulièrement sur le compte root, fail2ban va ajouter l’adresse IP aux règles du pare-feu du noyau Linux pour bannir le malandrin.

Pour installer fail2ban, sous Debian ça tient à une seule ligne :

Il est déjà actif sur certains critères par défaut : SSH, Apache, serveurs FTP, mais il va nous falloir une nouvelle règle spécifique au login WordPress. Histoire de ne pas mélanger les règles, ouvrez le fichier /etc/fail2ban/jail.conf, cherchez la section HTTP servers, et à la fin de celle-ci, ajoutez les lignes suivantes :

Adaptez le chemin du fichier de log à votre situation. Maintenant qu’on a le cas et le fichier à sniffer, il nous reste le filtre. On l’a appelé apache-wp-login, on crée donc un fichier /etc/fail2ban/filter.d/apache-wp-login.conf, et on y met les lignes suivantes :

Il suffit ensuite de redémarrer fail2ban, et de laisser la magie opérer :

Bizarrement, pendant plusieurs jours après avoir mis la règle en place, j’ai eu la paix. Rageant. Mais un bon appât permet toujours d’attraper quelque chose, et finalement, j’ai vu apparaître des lignes intéressantes dans le fichier /var/log/fail2ban.log :

Par contre, l’adresse IP n’est bannie que pendant dix minutes. C’est une mesure de sécurité : déjà, normalement dix minutes suffisent aux robots de login pour laisser tomber s’ils n’ont plus de réponse. Mais surtout si jamais vous vous faites attraper, parce que vous ratez votre coup, vous n’avez qu’à attendre dix minutes pour recommencer.

Si vous souhaitez malgré tout augmenter la durée, il faut retourner dans le fichier /etc/fail2ban/jail.conf, dans la section qu’on a ajouté plus haut, et ajouter la ligne suivante :

Redémarrez une fois de plus fail2ban pour que la nouvelle durée soit prise en compte. Et c’est à peu près tout.

Une autre méthode est possible, toujours avec fail2ban. Je ne la chéris pas trop puisqu’elle fait appel à une extension, et que ça peut impacter les performances. Je n’ai pas besoin de détailler plus, tout est décrit dans cet article très bien fait.

Il y a beaucoup de choses à faire pour sécuriser une instance WordPress, que ce soit les logiciels utilisés pour la servir, que l’application elle-même. Je n’ai pas encore poussé le concept des fonctions « custom », qui permettent de redéfinir le comportement de certains éléments de l’application, dont font partie la page de connexion.