09-75-24-68-97 | contact@digital-cookie.io

Sécuriser XML-RPC avec Fail2Ban

Dans ce tutoriel, nous allons voir comment déplacer la gestion des appels au fichier XML–RPC de Apache vers fail2ban. En français, ça veut dire qu’on va sécuriser un peu plus notre site sur WordPress.

Pourquoi sécuriser XML-RPC ?

XML-RPC est une procédure d’appel à distance qui utilise XML pour encoder ses appels et utilise http comme mécanisme de transport. C’est une procédure utilisée par WordPress pour la publication à distance, et également par jet pack pour d’autres fonctions. Le problème, c’est que c’est aussi utilisé par de nombreux hackers pour forcer l’accès à votre site.

C’est donc très problématique, et c’est une source d’ennuis a importante, surtout si on n’a pas un plug-in de sécurité.

Et le plug-in de sécurité justement ?

Dans notre tutoriel précédent, on a installé un plug-in de sécurité sur WordPress. Parmi ces fonctionnalités, on peut justement interdire XML-RPC sur WordPress. Le problème, c’est que cette interdiction figure dans le fichier htaccess qu’on a la racine du site. C’est donc Apache (le serveur de pages) qui gère les erreurs 403 (accès non-autorisé) quand on sollicite XML-RPC.

Si des pirates lancent de nombreuses requêtes sur XML-RPC, Apache répond avec une multitude de 403. Du coup, sa consommation de RAM explose, et ça peut planter les autres services sur votre serveur. Donc, pour faire court, ça peut crasher votre site, en transformant une attaque technique en attaque par déni de service.

Comment fixer la faille représentée par XML-RPC ?

Ce qu’on va voir dans ce tutoriel, c’est comment déplacer la gestion de la connexion à XML-RPC vers une couche logicielle plus profonde, à savoir Fail2ban. Quand quelqu’un sollicitera XML-RPC, Fail2ban le détectera automatiquement et bannira l’IP de l’attaquant pour la durée qu’on a choisie. Cet utilisateur ne pourra plus attaquer votre site, ni même accéder à aucune page.

Pas de souci du côté du référencement, Google ne sollicitera jamais xmlrpc.php 🙂

Mettre en place le fichier jail.local

La première chose qu’on va faire, c’est se rendre sur « /etc/fail2ban » et ouvrir le fichier « jail.conf ». On copie l’intégralité de son contenu avec CTRL + A, on ferme le fichier, et on crée un nouveau fichier juste à côté que l’on va appeler « jail.local ». On l’ouvre, et on colle tout ce qu’on a copié depuis « jail.conf ».

À la fin du nouveau fichier, vous allez rajouter ceci :

[xmlrpc]
enabled = true
filter = xmlrpc
action = iptables-multiport[name=xmlrpc, port="https,http", protocol=tcp]
logpath = /var/log/apache2/access.log
bantime = 43600
maxretry = 1

La prison qu’on a définie ici et qu’on appelle tout simplement « xmlrpc » utilisera le filtre qu’on va configurer, et qui s’appelle lui aussi « xmlrpc ». Le temps de bannissement est réglé sur 43 600 secondes, pour un seul essai de connexion à xmlrpc.php enregistré dans les logs d’Apache.

Créer un filtre dans filter.d

On se rend ensuite dans le dossier « filter.d », toujours dans « /etc/fail2ban »

Ici, on va créer un nouveau filtre, qu’on appelle « xmlrpc.conf »

Dedans, coller simplement les lignes de code suivante :

[Definition]
failregex = ^<HOST> .*(GET|POST) .*xmlrpc.php.*
ignoreregex =

Le filtrer est défini pour analyser les requêtes GET ou POST qui arriveraient sur xmlrpc.php

On redémarre ensuite fail2ban avec la commande service fail2ban restart (rentré dans la console SSH, voir notre tuto sur Fail2ban ici) et c’est terminé !

Le résultat de cette petite opération

Vous le voyez bien dans la vidéo, quand je prends une IP en Indonésie et que je Ping XML-RPC, je ne peux plus du tout accéder au site que j’ai tenté de « pirater ». Toute tentative de connexion sur XML-RPC se soldera par un ban de 43 600 secondes. Vous avez la possibilité de bannir les attaques plus longtemps, mais ça ferait monter en charge la base de données utilisées par « IP tables », la couche logicielle qui enregistre les adresses IP des assaillants.

Ici, 12 heures, ça suffit largement. Le bénéfice, c’est qu’Apache n’aura plus à gérer plein de 403 si un abruti à l’autre bout du monde décide de pinger xmlrpc.php à tout-va, sans motif légitime.

Prochaine étape : installer un plug-in de cache, pour gagner encore plus de performances et réduire les temps de chargement !

A propos de l'auteur

Charles Annoni est chef de projet web depuis 2008. Formateur en référencement naturel, E-commerce et Webmarketing (6 centres de formation en Normandie), il est également Webmaster Freelance et accompagne les entreprises dans leur développement sur le web.