Certains d’entre vous l’ont peut-\u00eatre constat\u00e9, il \u00e9tait plut\u00f4t compliqu\u00e9 d’acc\u00e9der \u00e0 unicoda.com durant les derni\u00e8res 48h. En effet, il se trouve que le site a \u00e9t\u00e9 la cible d’une attaque de type brute force qui l’a mis \u00e0 mal. R\u00e9sultat, un processus apache qui d\u00e9colle et accapare toutes les ressources de la machine jusqu’au d\u00e9ni de service. Retour sur la folle vie d’un serveur attaqu\u00e9.<\/p>\n
Tout commence le 25 ao\u00fbt 2016 aux alentours de 19h, la premi\u00e8re requ\u00eate de la s\u00e9rie appara\u00eet \u00e0 18 heures 46 minutes et 25 secondes pour \u00eatre pr\u00e9cis.<\/p>\n
191.96.249.54 - - [25\/Aug\/2016:18:46:25 +0200] \"POST \/xmlrpc.php HTTP\/1.0\" 200 579 \"-\" \"Mozilla\/4.0 (compatible: MSIE 7.0; Windows NT 6.0)\"\r\n191.96.249.54 - - [25\/Aug\/2016:18:46:25 +0200] \"POST \/xmlrpc.php HTTP\/1.0\" 200 579 \"-\" \"Mozilla\/4.0 (compatible: MSIE 7.0; Windows NT 6.0)\"\r\n191.96.249.54 - - [25\/Aug\/2016:18:46:25 +0200] \"POST \/xmlrpc.php HTTP\/1.0\" 200 579 \"-\" \"Mozilla\/4.0 (compatible: MSIE 7.0; Windows NT 6.0)\"<\/pre>\n\u00c0 cette heure-l\u00e0, pas de probl\u00e8me, le serveur fonctionne correctement. La premi\u00e8re alerte sera lev\u00e9e par le syst\u00e8me de monitoring d’OVH \u00e0 22h54 ce m\u00eame jour. Le serveur a d\u00e9clar\u00e9 forfait et ne r\u00e9pond plus au ping. Quelques minutes plus tard, le support intervient et red\u00e9marre le serveur. Une nouvelle alerte sera lev\u00e9e vers 4h du matin, avec intervention du support. En d\u00e9couvrant les mails le matin, je ne flaire pas imm\u00e9diatement l’attaque. Le support est intervenu, il n’y a pas de pr\u00e9cision indiquant si le probl\u00e8me vient du logiciel ou du mat\u00e9riel c\u00f4t\u00e9 h\u00e9bergeur, le site ne s’affichant pas, j’effectue \u00e0 mon tour un red\u00e9marrage du serveur et m’assure que les diff\u00e9rents services sont bien repartis. Tout semble fonctionner\u2026 Pourtant, m\u00eame sc\u00e9nario dans la nuit de vendredi \u00e0 samedi avec deux interventions du support. Quelque chose cloche, je continue de vaquer \u00e0 mes occupations lorsque le serveur devient une nouvelle fois inaccessible samedi vers midi. Pas doute il y a un probl\u00e8me, je vais devoir effectuer des v\u00e9rifications d\u00e8s que possible.<\/p>\n
<\/p>\n
En fin d’apr\u00e8s-midi le samedi 27, je me connecte donc au serveur apr\u00e8s l’avoir red\u00e9marr\u00e9. Pas d’\u00e9tranget\u00e9 du c\u00f4t\u00e9 des processus, si ce n’est plusieurs process apache qui tournent en \u00e9puisant la majeure partie des ressources. \u00ab\u00a0Houston, nous avons un probl\u00e8me.<\/em>\u00a0\u00bb Une telle utilisation des processus apache sugg\u00e8re un trafic important du c\u00f4t\u00e9 site web. Direction les logs et l\u00e0 bingo, une m\u00eame IP effectue des requ\u00eates POST sur \/xmlrpc.php en boucle et mets le serveur \u00e0 genou. Ni une ni deux, je d\u00e9cide de prendre les mesures qui s’imposent :<\/p>\n
iptables -A INPUT -s 191.96.249.54 -j DROP<\/pre>\nLe changement est flagrant, les indicateurs repassent au vert, le serveur respire. Le probl\u00e8me imm\u00e9diat est r\u00e9gl\u00e9. Il faut maintenant s’assurer que cela ne se reproduise plus et qu’une machine tentant une telle attaque soit automatique bloqu\u00e9e. \u00c7a tombe bien, Fail2ban<\/a> va pouvoir s’en charger !<\/p>\n
Nous allons donc ajouter la configuration suivante \u00e0 Fail2ban (fichier jail.conf :<\/p>\n
[wordpress-xmlrpc]\r\n\r\nenabled = true\r\nport = https,http\r\nfilter = wordpress-xmlrpc\r\nlogpath = \/var\/log\/apache2\/wordpress_access.log\r\nbantime = 86400\r\nmaxretry = 1<\/pre>\nAu niveau du param\u00e8tre, 86400 secondes de bannissement (24h) et une tol\u00e9rance limite de une tentative de connexion au fichier sur 600 secondes (par d\u00e9faut). On ajoute ensuite le filtre par cr\u00e9ation du fichier wordpress-xmlrpc.conf dans le dossier filter.d :<\/p>\n
[INCLUDES]\r\nbefore = common.conf\r\n\r\n[Definition]\r\nfailregex = <HOST> - .*(GET|POST) .*\/xmlrpc.php \r\nignoreregex =<\/pre>\nIl ne faut pas oublier de s’assurer que Fail2ban a acc\u00e8s au fichier de log en lecture, en th\u00e9orie pas de probl\u00e8me. La regex doit \u00e9galement \u00eatre modifi\u00e9e pour coller \u00e0 la structure des logs. Afin de tester la configuration, on peut utiliser la commande suivante, en \u00e9tant particuli\u00e8rement attentif aux lignes commen\u00e7ant par ERROR :<\/p>\n
sudo fail2ban-client -d<\/pre>\nIl est \u00e9galement possible de tester votre regex en cr\u00e9ant un fichier contenant la ligne que nous souhaitons v\u00e9rifier et en demandant \u00e0 fail2ban de v\u00e9rifier la regex sur le contenu du fichier :<\/p>\n
fail2ban-regex \/chemin\/vers\/test.log \"<HOST> - .*(GET|POST) .*\/xmlrpc.php\"<\/pre>\nLa regex correspond \u00e0 la cha\u00eene de caract\u00e8re entre double quote. Par ailleurs, si ce n’est pas fait et si on a la chance de disposer d’une IP fixe pour votre modem personnel, on peut en profiter pour mettre celle-ci en liste blanche dans le fichier de configuration jail.conf :<\/p>\n
[DEFAULT]\r\n\r\n# \"ignoreip\" can be an IP address, a CIDR mask or a DNS host\r\nignoreip = 127.0.0.1\/8 xxx.xxx.xxx.xxx<\/pre>\nPour v\u00e9rifier que la r\u00e8gle est active, on pourra utiliser la commande :<\/p>\n
sudo fail2ban-client status<\/pre>\nVoil\u00e0 une configuration qui devrait limiter les d\u00e9g\u00e2ts lors des prochaines tentatives d’attaque. Le comble de cette histoire, c’est que j’avais pris connaissance plus t\u00f4t cette ann\u00e9e des risques li\u00e9s \u00e0 xmlrpc.php dans WordPress, mais je n’avais pas pris le temps de mettre en place les protections n\u00e9cessaires. C’est d\u00e9sormais chose faite.<\/p>\n
Cette premi\u00e8re attaque avec un impact visible sur les services h\u00e9berg\u00e9s m’a donc permis d’approfondir mes connaissances de fail2ban. Je retiendrai bien \u00e9videmment le diagnostic un peu tardif mais n\u00e9anmoins rapide du probl\u00e8me. Je pense qu’il y a des choses \u00e0 creuser de ce c\u00f4t\u00e9-l\u00e0 pour tenter d’avoir une remont\u00e9e automatique d’informations d\u00e8s que le serveur d\u00e9tecte un \u00e9ventuel probl\u00e8me.<\/p>\n
<\/p>\n
Chronologie<\/h6>\n
25-08-2016 22:50:07 Destination Host Unreachable\r\n25-08-2016 23:40:57 Reboot HARD\r\n\r\n26-08-2016 04:19:05 Destination Host Unreachable\r\n26-08-2016 04:31:13 Reboot HARD\r\n26-08-2016 22:37:06 Destination Host Unreachable\r\n26-08-2016 23:29:00 Reboot HARD\r\n\r\n27-08-2016 02:43:06 Destination Host Unreachable\r\n27-08-2016 03:06:59 Reboot HARD\r\n27-08-2016 12:39:06 Destination Host Unreachable\r\n27-08-2016 12:46:08 Reboot HARD<\/pre>\nAu passage, je tiens \u00e0 remercier le support technique pour leur intervention \u00e0 chaque fois que le serveur devenait indisponible (Jonathan L. et Nicolas D.).<\/p>\n
Quelques chiffres<\/h6>\n
IP source : 191.96.249.54
\n84 524 requ\u00eates<\/p>\n","protected":false},"excerpt":{"rendered":"Certains d’entre vous l’ont peut-\u00eatre constat\u00e9, il \u00e9tait plut\u00f4t compliqu\u00e9 d’acc\u00e9der \u00e0 unicoda.com durant les derni\u00e8res 48h. En effet, il se trouve que le site a \u00e9t\u00e9 la cible d’une attaque de type brute force qui l’a mis \u00e0 mal. R\u00e9sultat, un processus apache qui d\u00e9colle et accapare toutes les ressources de la machine jusqu’au … Continuer la lecture de « WordPress, xmlrpc et d\u00e9ni de service »<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40],"tags":[288,287,12,285],"class_list":["post-2232","post","type-post","status-publish","format-standard","hentry","category-info","tag-deni-de-service","tag-fail2ban","tag-wordpress","tag-xmlrpc"],"_links":{"self":[{"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/posts\/2232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2232"}],"version-history":[{"count":8,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/posts\/2232\/revisions"}],"predecessor-version":[{"id":2240,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/posts\/2232\/revisions\/2240"}],"wp:attachment":[{"href":"https:\/\/www.unicoda.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2232"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}