Comme je vous en ai parlé dans un précédent article, mon serveur a été victime d’une tentative d’exploit d’une faille WordPress.

Pour m’en prémunir, j’ai créé une nouvelle règle dans Fail2Ban qui va analyser les logs et repérer l’action suspecte à bloquer.

Si vous n’avez pas encore installé Fail2Ban :

sudo apt-get install fail2ban

Ensuite, il faut commencer par créer un filtre pour parser les logs à la recherche des nombreuses tentatives d’accès :

cd /etc/fail2ban/filter.d
sudo vi apache-xmlrpc.conf

Et y ajouter le code suivant :

[Definition]
failregex = ^<HOST> .*POST .*xmlrpc\.php.* ignoreregex =

Quittez et enregistrez le fichier. A ce stade, vous venez de créer le filtre qui va chercher l’adresse IP correspondant à la machine qui tente de lancer l’exploit sur votre fichier xmlrpc.php situé à la racine de votre installation WordPress. Passons maintenant à sa mise en place dans la configuration de Fail2Ban :

cd /etc/fail2ban/
sudo vi jail.conf

Ajoutez à la liste des filtres déjà présents celui que vous venez de créer :

[apache-xmlrpc] enabled = true
port = http,https
filter = apache-xmlrpc
logpath = /CHEMIN-VERS-VOS-FICHIERS-DE-LOG/access.log
maxretry = 6

Quittez et enregistrez le fichier. Il ne reste plus qu’à redémarrer le service Fail2Ban :

sudo service fail2ban restart

Et le tour est joué ! Vous n’avez plus qu’à surveiller les logs de Fail2Ban pour détecter les IPs qui tentent d’accéder à votre site et qui sont bloquées par le logiciel pour ensuite faire un whois suivi d’un déclenchement d’abuse.

Attention toutefois, cette astuce n’est efficace que sur de modestes sites. Si vous héberger un gros site avec un fort traffic, le parcours des logs Apache par Fail2Ban risque probablement d’impacter les performances de votre serveur en mobilisant une charge importante du CPU !

Sponsornot : Zéro collaboration

Comme vous le savez surement, j’héberge moi même mes sites internet sur un serveur dédié loué chez Online.net. En début de semaine, j’ai constaté des ralentissements importants sur l’ensemble de mes sites, ainsi que des problèmes de synchronisation MySQL entre les dis sites et leurs bases de données respectives. Je me connecte donc en SSH sur mon dédié et balance donc une petite commande « top » pour afficher les processus qui tournent.

A ma grande surprise, la liste n’est composée que d’une succession de services Apache2 qui vont et viennent et surchargent ainsi la totalité ou presque des ressources de mon serveur. La charge processeur culmine autour de 99% d’utilisation en constant, alors que d’ordinaire je suis plutôt entre 5 et 10%…

Mon premier réflexe : redémarrer le service Apache2 :

sudo service apache2 restart

Je patiente quelques secondes le temps que le service remonte et refait un « top ». Même constat, mon serveur est toujours à fond… Du coup, je file jeter un petit coup d’oeil aux logs et là, surprise :

mon-user@mon-serveur:~$ cd /var/log/apache2/
mon-user@mon-serveur:/var/log/apache2$ ll
total 786200
drwxr-x--- 2 root adm 4096 sept. 21 06:25 ./
drwxr-xr-x 14 root root 4096 sept. 24 06:25 ../

-rw-r----- 1 root adm 163781250 sept. 24 20:00 access.log
-rw-r----- 1 root adm 245624497 sept. 21 06:25 access.log.1
-rw-r----- 1 root adm 6488434 juil. 20 06:24 access.log.10.gz
-rw-r----- 1 root adm 6781312 juil. 13 06:25 access.log.11.gz
-rw-r----- 1 root adm 5014221 juil. 6 06:25 access.log.12.gz
-rw-r----- 1 root adm 6811034 juin 29 06:25 access.log.13.gz
-rw-r----- 1 root adm 6491920 juin 22 06:25 access.log.14.gz
-rw-r----- 1 root adm 8740091 juin 15 06:25 access.log.15.gz
-rw-r----- 1 root adm 13286015 juin 8 06:25 access.log.16.gz

-rw-r----- 1 root adm 7343230 sept. 24 20:00 error.log
-rw-r----- 1 root adm 13729544 sept. 21 06:25 error.log.1
-rw-r----- 1 root adm 602268 juil. 20 06:25 error.log.10.gz
-rw-r----- 1 root adm 569964 juil. 13 06:25 error.log.11.gz
-rw-r----- 1 root adm 483897 juil. 6 06:25 error.log.12.gz
-rw-r----- 1 root adm 334804 juin 29 06:25 error.log.13.gz
-rw-r----- 1 root adm 457884 juin 22 06:25 error.log.14.gz
-rw-r----- 1 root adm 853488 juin 15 06:25 error.log.15.gz
-rw-r----- 1 root adm 780921 juin 8 06:25 error.log.16.gz

-rw-r----- 1 root adm 4917534 sept. 24 20:00 other_vhosts_access.log
-rw-r----- 1 root adm 9301167 sept. 21 06:25 other_vhosts_access.log.1
-rw-r----- 1 root adm 66098 juil. 20 06:25 other_vhosts_access.log.10.gz
-rw-r----- 1 root adm 89567 juil. 13 06:25 other_vhosts_access.log.11.gz
-rw-r----- 1 root adm 52761 juil. 6 06:25 other_vhosts_access.log.12.gz
-rw-r----- 1 root adm 63852 juin 29 06:25 other_vhosts_access.log.13.gz
-rw-r----- 1 root adm 60675 juin 22 06:25 other_vhosts_access.log.14.gz
-rw-r----- 1 root adm 87682 juin 15 06:25 other_vhosts_access.log.15.gz
-rw-r----- 1 root adm 204479 juin 8 06:25 other_vhosts_access.log.16.gz

Je vous laisse comparer la taille des archives de log de septembre, avec celle des autres mois que j’ai volontairement laissé. Vous pouvez constater que pour septembre la quantité de logs s’est envolée et cela m’a mis la puce à l’oreille.

J’affiche le contenu du fichier access.log afin de voir qu’est ce qui accède à mon serveur, et parmi les quelques requêtes légitimes (je ne peux malheureusement pas me vanter de comptabiliser des millions de visites / mois ;)) je détecte 4 IPs qui ne requêtent pas de façon « normale » :

mon-user@monserveur:/var/log/apache2$ cat access.log | grep ip-suspecte
ip-suspecte - - [22/Sep/2014:19:39:21 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:21 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:23 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:23 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:23 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"

Au total : 200000 requêtes en 24h de cette simple IP, et il y en avait 3 autres, certes beaucoup moins virulentes mais pour le serveur s’en était trop.

On m’a demandé pourquoi je n’avais pas installé Fail2Ban. Et bien si, Fail2Ban était pourtant bel est bien installé ! Le problème, c’est que lorsqu’on épluche les logs on voit que l’attaquant fait un POST sur un fichier bien précis d’une installation WordPress : xmlrpc.php. La réponse du serveur à cette requête est 200 « Requête traitée avec succès », il n’y a donc aucune erreur de renvoyer… L’attaque passe ainsi entre les mailles de Fail2Ban dans sa configuration de base…

Une recherche sur Internet m’a permis d’identifier cette attaque comme étant une tentative d’exploit d’une vulnérabilité connue de WordPress. Comme il s’agit aussi d’une tentative d’injection SQL, j’ai jeté un oeil aux logs concernés :  

mon-user@mon-serveur:/var/log/mysql$ ll
total 36
drwxr-s--- 2 mysql adm 4096 sept. 25 06:25 ./
drwxr-xr-x 14 root root 4096 sept. 25 06:25 ../
-rw-r----- 1 mysql adm 0 sept. 25 06:25 error.log
-rw-r----- 1 mysql adm 20 sept. 24 06:25 error.log.1.gz
-rw-r----- 1 mysql adm 20 sept. 23 06:26 error.log.2.gz
-rw-r----- 1 mysql adm 1059 sept. 22 14:15 error.log.3.gz
-rw-r----- 1 mysql adm 20 sept. 21 06:25 error.log.4.gz
-rw-r----- 1 mysql adm 20 sept. 20 06:25 error.log.5.gz
-rw-r----- 1 mysql adm 20 sept. 19 06:25 error.log.6.gz
-rw-r----- 1 mysql adm 20 sept. 18 06:25 error.log.7.gz

Pour la journée du 22 septembre, la taille des logs a été multipliée par 50 environ, preuve qu’il s’agit bien d’une tentative d’exploit de la faille sur la fonctionnalité Pingback de WordPress. Je vous indiquerai dans un prochain tutoriel comment configurer Fail2Ban pour qu’il prenne en compte cette attaque sur vos installations WordPress.

Après un WhoIs sur les différentes IPs, 2 provenaient de serveurs hébergés chez Online et 2 de chez Elcatel. Ayant toujours été très bien renseigné par l’assistance du premier, je les ai contacté pour leur faire part du problème et ils m’ont guidé pour déclencher un abuse. La hotline Online ? Toujours au top (je vous invite à lire mon article sur mon expérience avec eux) !

Dans la foulée, pour stopper cette surcharge assez handicapante avant le traitement du signalement, j’ai créé 4 règles dans le firewall du serveur :

mon-user@mon-serveur:/~$ sudo ufw deny from ip-suspecte-1
mon-user@mon-serveur:/~$ sudo ufw deny from ip-suspecte-2
mon-user@mon-serveur:/~$ sudo ufw deny from ip-suspecte-3
mon-user@mon-serveur:/~$ sudo ufw deny from ip-suspecte-4
mon-user@mon-serveur:/~$ sudo ufw disable
mon-user@mon-serveur:/~$ sudo ufw enable

La charge serveur est instantanément retombée à son niveau d’origine et les sites internet et autres services hébergés sont redevenus fluides.

Moralité : superviser son serveur est indispensable pour traiter au plus vite ce genre d’attaque…

Sponsornot : Zéro collaboration

Read More