Prestashop : se protéger contre le spam du le module Sendtoafriend

En auditant les sites hébergés sur mon serveur ce matin, j’ai remarqué qu’ils étaient tous très lents. J’ai vérifié quelques métriques du serveur et j’ai remarqué que le CPU explosait :

La requête top m’a vite permis de voir que les processus PHP bouffait toutes les ressources à partir d’un utilisateur apache bien spécifique. J’ai donc jeté un oeil sur les logs du site en question (access.log). Et j’ai pu voir le problème :

Sous Prestashop, vous avez le module « sendtoafriend » qui permet d’envoyer un mail à l’un de vos amis avec le lien du produit visité. Sauf que le module présente une faille. En envoyant une requête POST sur le fichier ajax de ce module, vous pouvez déclencher l’envoi d’un mail sur l’adresse de votre choix.

L’un de mes clients a été victime de cette faille. Il a eu pas moins de 390 000 requêtes entre minuit et 8h du matin. Merci à lui d’avoir d’ailleurs remonté les lenteurs sur son site.

Attention : même si le module est désactivé, les fichiers sont toujours accessibles et la fail toujours présente. Même après suppression des fichiers, le spam peut continuer et générer des 404, comme ici. Cela suffira à faire ramer le serveur si vous n’avez aucune mesure de sécurité en place.

Fail2ban peut vous sauver dans ces situations là.

Se protéger contre cette faille

L’objectif va être de bannir toutes les IP du serveur qui envoient des requêtes en POST sur le fichier ajax du module avec Fail2Ban.

Créer le fichier /etc/fail2ban/filter.d/apache-customurl.conf puis coller le contenu ci-dessous dans le fichier :

[Definition]
failregex = ^.*"POST \/modules\/sendtoafriend\/sendtoafriend_ajax.php.*
ignoreregex =

Éditez le fichier /etc/fail2ban/jail.conf et collez le code ci-dessous à la fin :

[apache-customurl]

enabled  = true
port     = http,https
filter   = apache-customurl
logpath = /var/www/*/log/access.log
maxretry = 1
bantime  = 36000

C’est un serveur qui tourne avec ISP Config, ce qui explique la structure des fichiers de log (logpath) utilisée. Adaptez là suivant l’emplacement de vos fichiers. Ceci peut aussi fonctionner :

logpath  = /var/log/apache*/*access.log

Suivi d’un service fail2ban restart

Si vous avez tout bien paramétré, les IP devraient commencer à se faire bannier. Vous pouvez le vérifier en tapant tail -f /var/log/fail2ban.log

Notez que vous pouvez aussi tester votre configuration avant de redémarrer fail2ban, avec la ligne ci-dessous :

fail2ban-regex /var/www/[URL_SITE]/log/access.log /etc/fail2ban/filter.d/apache-customurl.conf

Et voila ! Vous pouvez souffler, votre serveur est sauf.