• 1
mercredi, 24 septembre 2014 19:06

RetEx : Server under attacks !

Écrit par

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

Exe

Qualifié de Geek depuis mon plus jeune âge, Twit-Addict et un peu râleur sur les bords, je m'intéresse à tout ce qui touche les nouvelles techno. Passionné d'informatique, de jeux vidéo, de cinéma et de création numérique, il m'arrive également d'explorer les domaines de la photographie et du DIY.

www.exe-prod.com/

Ajouter votre commentaire

Écrire un commentaire en tant qu'invité

0
Vos commentaires sont soumis à la modération d'un administrateur.
  • Aucun commentaire sur cet article.
Entrez dans le monde de la haute voltige avec le T.16000M FCS Hotas !
Trouvez les meilleurs accessoires disponibles pour Samsung Galaxy S8