Comme je l’avais déjà dit il y a deux ans Mandrill, qui est notre serveur d’expédition d’email, nous a déjà bien sauvé le cul avec une attaque de spammeurs qui se servent de la création de compte sur notre Magento pour envoyer du SPAM à la terre entière.
Un truc sur lequel on serait sans défenses sans Mandrill et sa possibilité de filtrer les emails sortant au niveau du serveur d’envoi.
La semaine passée, je me suis penché sur un problème qui nous pendait au nez depuis le début de l’année.
Depuis le début de l’année, Mandrill nous alertait sur la réputation email de notre domaine qui était en chute lente, mais continue. D’autres chats à fouetter, je ne m’étais jamais penché sur le problème.
Mais la semaine dernière avec le confinement, on s’est retrouvé sous une avalanche de commande (générant des emails par notre site) et nous derrière qui expédiions également des emails à chaque commande pour demander aux clients s’ils avaient bien lu le message indiquant que nous n’expédions plus rien (SPOILER ALERT : Pour les 2/3, non ils ne l’avaient pas lu), et la limite horaire imposée par Mandrill suite à la baisse de la réputation de notre domaine de plus en plus pourrave, ne suffisait plus.
J’ai donc pris le temps de demander des explications à Mandrill, car à mes yeux, on avait le cul propre.
Nous bloquions déjà toutes les tentatives de SPAM.
Après quelques minutes seulement (service client au top top top), ils m’ont répondu, que notre domaine envoyait quand même des SPAM, avec des exemples à la clé.
En effet, notre formulaire de contact nous envoyait des SPAM. À nous.
Notre domaine nous envoyait bien des emails de SPAM pourris incontestablement.
Nous ne les signalions jamais en SPAM (on n’est pas si con, même si j’ai des doutes sur certains), mais les analyseurs de mails notaient bien que notre nom de domaine envoyait des emails avec des liens vers du pr0n ou du v14gr4.
Je ne voulais pas me résigner à installer un Captcha.
Nos clients ont déjà du mal à remplir comme il le faut leur code postal ou leur numéro de téléphone (true story) alors leur demander de recopier des caractères dégradés, ou de cliquer sur des images de voitures ou de bus, c’est impensable !
Autres soucis, notre Magento étant devenu avec le temps tellement instable, qu’il est hors de question d’installer des plugins tiers.
Bon en vrai, il n’est pas instable, il est vitrifié pour garder sa stabilité.
Bon, le problème était clos il n’y avait rien à faire. J’ai passé une nuit à pleurer.
Puis, REVELATION !
Je serais incapable de dire d’où elle est venue, mais je me suis souvenu qu’il était possible d’activer ou de désactiver le formulaire de contact.
Car oui, c’est bien lui qu’il faut désactiver, car les spammeurs pointent leurs robots directement sur le moteur d’envoi, et ne visitent aucunes pages. (J’avais déjà tenté un truc sur cette caractéristique avec Cloudflare, mais sans succès)
Une fois désactivé, j’ai fait moi-même mon petit formulaire et son script d’expé d’email à la main.
J’y ai ajouté deux antispam :
- Un bête et méchant de ma fabrication
Dans le formulaire j’ajoute un champ URL, que je cache en CSS.
Les robots spammeurs aiment être exhaustifs. Ils remplissent tous les champs des formulaires. Alors pensez-y, un champ nommé URL !
Donc dans mon script si le champ URL est renseigné, c’est à coup sûr du spam.
Essayez, c’est redoutable, et ça fait plus de 10 ans que j’applique cette technique un peu partout.
Pour les plus malins qui visent spécifiquement des Magento, qui savent que ce champ n’existe pas et qui font naviguer leur robot, j’ai rajouté une couche avec l’antispam de WordPress.
Je suis passé par la libraire/function Fuspam en php pour accéder à l’API Akismet.
Pour les messages qui restent coincé dans ce filet, j’enregistre sur le serveur le message et envoie un email neutre à notre adresse indiquant qu’il faut aller vérifier.
J’ai aussi fait une page pour visualiser et supprimer tout d’un coup.
Et pour les messages qui ne passent pas le premier test de l’URL vide, je les déclare tout de suite comme SPAM à Akismet.
Si vous voulez, vous aussi, ce script de formulaire, n’hésitez pas à me le demander.
Ces dernières heures chez Jardiforet.com, nous avons été sous le coup d’une attaque de spammeurs utilisant notre nom de domaine.
Pourtant;
Notre domaine d’expédition est relativement protégé, avec des DKIM et des SPF configurés correctement.
Notre serveur d’hébergement ne peut pas envoyer d’email.
Tous nos emails sont envoyés via Mandrill (je vous en parlerais un jour dans la catégrie #Mes outils), et nos clés API sont safe.
Notre site ne peut envoyer qu’un nombre très restreint d’emails différents.
Les attaquants ont utilisé une technique que je ne connaissait pas !
Une technique se jouant de toutes les sécurités mise en place sur les noms de domaines.
Une technique relativement compliquée à contrecarrer si elle etait utilisé à grande échelle.
Les attaquants créent à tour de bras des comptes sur notre site, avec l’adresse de leur cible en remplacent le nom et prénom par leur message à transmettre.
Le « Bonjour Alban JAMESSE », se transforme en
« Bonjour MESSAGE DE SPAM POUR T’ENVOYER SUR UN SITE RUSSE ».
Comment contrer cette attaque ?
Bloquer les création de compte de ces bots ?
Les logs de notre site indique que les comptes sont créés par des IP françaises à chaque fois différentes, sur tous les FAI (botnet ?).
Diminuer la taille autorisée des champs nom et prénom ou modifier l’email?
Solution préventive oui, mais ça ne règle pas le souci du botnet qui continu à envoyer des emails.
Empêcher l’envoi d’emails ?
Solution temporaire de secours, mais pas cool pour les vrais clients.
Donnez vos idées !
La solution que j’ai réussi à mettre en place
Par chance nos spammeurs ne spamment que des adresses emails russes (pour le moment ?).
Surement pour jouer sur le fait que les lecteurs lisent le cyrillique et fassent abstraction du romain.
Nous avons donc créé une règle dans mandrill qui bloque tous les emails à expédier vers des adresses en .ru .
Cette solution tient le coup depuis une heure maintenant.
Mais quid de quand ils vont attaquer d’autres extensions ?
· Mise à jour ·
· 28/02/2018 ·
Nos règles de blocages sur Mandrill nous permettent :
- de bloquer tous les emails vers des adresses emails en .ru, qui sont les cibles de cette campagne de SPAM
- de bloquer tous les emails qui contiennent « http », ou « www » dans les objets
Mandrill nous a bloqué plus de 4000 emails (en date) répondant à l’une de ces deux règles, sans impacter nos véritables clients.
En raison de la vétusté de notre Magento, nous n’aurions pas réussi à contrecarrer cette campagne de SPAM sans Mandrill.
· Mise à jour ·
· 02/03/2018 ·
L’attaque a cessé.
En résumé :
- 10 jours d’attaque;
- 6000 messages envoyés;
- 5500 messages bloqués;
- Mandrill nous a bien sauvé le cul.
· Mise à jour ·
· 23/03/2020 ·
Depuis début 2019 l’attaque à reprise de manière continue et cible, comme le je craignais des adresses Gmail, Ouloook et tout plein d’autres domaines hors de Russie.
Le volume quotidien est d’environ 50 à 100 création de faux comptes par jours.
Nos règles Mandrill nous ont permis de ne pas envoyer 42.000 emails depuis début 2019.
Nous avons adaptés nos emails également.
Aujourd’hui tous les emails pré-commande, contiennent obligatoirement un {Prénom} {NOM} dans l’objet
Nous n’avons plus que deux règles de blocage qui se déclenchent avec la présence de « *http* » ou de « */* » dans les objets.
Et Mandrill nous sauve une nouvelle fois le cul avec une autre faille insoupçonnée qui concerne notre formulaire de contact.
Je tombe souvent sur des personnes qui peinent (= qui perde du temps bordel !) à faire une redirection d’url avec le module « Gestion de réécriture d’URL » de Magento.
C’est pourtant simple :
- Dans votre backoffice, allez dans Catalogue > Gestion de réécriture d’URL;
- Une fois ue vous avez cliqué sur « Ajouter une réécriture d’url »;
- Choisissez « Créer une réécriture d’URL » : « Personnaliser »;
- Vous vous retrouvez donc avec un champ « Personnaliser » non modifiable;
- Dans « ID chemin » : C’est un nom à donner à votre redirection.
Nommez la de manière intelligente pour la retrouver facilement si besoin;
- Dans « Chemin de requête » : Ici vous mettez l’ancien adresse de la page (sans votre nom de domaine, ni le / de début, qui fait encore parti de votre domaine hein !);
- Dans « Chemin cible » : C’est la que vous mettez la nouvelle adresse suivant les mêmes règles que ci dessus;
- Et dans « Rediriger » : Vous avez le choix entre « Non », qu’on ne choisira pas car on veut le faire, « Temporaire (302) », et « Permanente (301) », où vous ferez suivant le besoin.
Si vous ne savez pas, misez sur la 301.
Et c’est tout, pas besoin de couper les cheveux en 4.
La casse (majuscule/minuscule) n’est pas importante normalement, mais il se peut que suivant votre configuration de serveur elle le soit quand même, vous verrez par vous même.
