Home Tutos Tutos Wordpress Sécuriser XML-RPC avec Fail2Ban

Sécuriser XML-RPC avec Fail2Ban

4

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 !

 

 

GDM-Pixel / Charles Annoni Charles est chef de projet en marketing web et conception de sites. Formateur en référencement naturel, il est également consultant en webmarketing et propose des tutoriels exclusifs en France.

Les commentaires peuvent donner lieu à un lien dofollow si thématique similaire et ancre clean :)

Comment(4)

  1. Hello,

    fail2ban est un excellent outil. Malheureusement c’est bien souvent réservé aux serveurs dédiés sur lesquels on a la main pour déployer de telles protections. Chez les hébergeurs mutualisés on ne peut obtenir ce type de filtres spécifiques à WordPress.

    En complément, je me permets de citer mon tutoriel (l’approche est similaire avec une Debian) pour le complément relatif à MainWP. En effet, certains outils nécessiteront l’accès XML-RPC, il faut donc débloquer certaines IP.

  2. Bonjour Aurélien,
    dans un tuto précédent, nous avons déjà ajouté l’IP locale (enfin, celle du webmaster) à la whiteliste. Je prend ton lien néanmoins, car ton site est plein de ressources et vaut largement le détour 🙂

  3. Merci à tous deux, je viens de découvrir une séquence de 50k accès à wmlrpc et j’étais un peu dans le brouillard. Sur ma Dedibox, la solution d’Aurélien a fonctionné parfaitement sans retour ni rebroussement.

LEAVE YOUR COMMENT

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *