Under attack

Rien à voir avec les attentats de Paris mais le site est la cible d’attaques répétées.
Ça fait une dizaine de jour que je voyais des perturbations sur le site qui devenait saturé et injoignable par moment.

J’ai pensé à un hack de mon serveur mais pas de trace flagrante.
J’ai monitoré le serveur et observé que la charge CPU et la mémoire étaient saturées très rapidement dès que je démarrais apache2.

J’ai d’abord cru à un problème mysql car les logs d’erreurs me montraient des corruptions de tables mais ce n’était que la conséquence de mes redémarrages du serveur.
Une fois cette piste écartée, j’ai pensé à mon install wordpress puis aux plugins, mais en vain.
Ne voyant pas pourquoi je serai attaqué, j’ai décidé de remettre mon serveur à jour (oui je devrais le faire plus souvent mais bon on sait comment c’est …). Donc hop, passage en Debian 8.0 et Kernel 4.2.6 ainsi qu’un upgrade de tous les packages installés. Ça fait du bien d’être à peu près à jour.

Malheureusement, le problème est ré-apparu très rapidement.

Pour avancer dans le diagnostique, j’ai éteint un à un les serveurs pour valider mon setup de base, puis je les ai redemarre aussi un par un pour me rendre compte que c’est le blog qui est la cible.

En épluchant les logs d’accès du serveur, j’ai de suite repéré la multitude de requêtes qui assaillaient le blog. La même IP pendant quelques heures puis une autre, et encore une autre… qui font des centaines de requêtes à la minute (j’ai pas mesuré mais y en a un paquet) et qui sature le serveur en quelques secondes.

A noter que l’attaque cesse quelques temps (quelques minutes) lorsque je switch-off le serveur http. Ils doivent être capable de détecter qu’il ne répond plus.
D’après le service de monitoring de mon hébergeur, les attaques sont continuelles mais ont l’air d’avoir des pics d’activité toutes les 2h environ.

Les requêtes sont toujours les mêmes et visent le service xmlrpc de wordpress.
Une petite recherche montre que ce type d’attaque est très utilisé pour du DoS ou pour de la force brute.
Je ne sais pas quel était le but de mon attaque mais le résultat est le même, mon serveur ne peut pas traité autant de requêtes aussi vite.

Comme xmlrpc ne me sert pas vraiment, j’ai décidé de les filtrer au niveau apache.
J’ai ajouté ces lignes dans le fichier .htaccess dans le répertoire racine de wordpress:

<filesmatch "xmlrpc.php">
Require all denied
</filesmatch>

J’ai aussi diminué le paramètres MaxRequestWorkers de 150 à 50 de ma configuration apache2 (mpm_prefork.conf dans /etc/apache2/mods-enabled) pour éviter une nouvelle fois que le serveur soit inutilisable pendant les attaques. Je l’ai testé et dans mon cas, je pouvais toujours utilisé la console pendant l’attaque (ce qui n’était pas le cas précédemment).

Note: Avec la mise à jour de mon serveur, j’ai eu des soucis pour le module php5 de apache2. Il semblerait que sous debian jessie (8.0), le module par défaut est apache2-mod-php5filter qui est sensé ne faire appel au module php5 uniquement quand on accède à des fichiers php. Ça semble une bonne idée mais j’ai pas mal galéré avant de me rendre compte que ce module était la cause de mes soucis.
Le site semblait marcher mais quand je créais des nouveaux articles sur le blog et que je les sauvais, ils étaient tronqués à environ 150 caractères. J’ai eu beau tenté de changer les paramètres de configuration, rien n’y faisait.
En désespoir de cause, j’ai viré php5, libapache2-mod-php5filter pour ré-installer php5 et libapache2-mod-php5 et là, comme par magie, le site s’est mis à fonctionner comme avant.

Globalement, j’ai fait ça :
apt-get remove --purge php5 libapache2-mod-php5filter php5-cli php5-mysql
rm -rf /etc/php5
mkdir /etc/php5
mkdir /etc/php5/mods-available
apt-get update
apt-get install php5 libapache2-mod-php5 php5-cli php5-mysql