Magento – SPAM Registrierungen als Kunden oder für den Newsletter

Es kommt nun immer häufiger vor, dass Magento-Shops für die Versendung von SPAM-Mails versendet werden. Hierzu werden entweder “Fake”-Kundenkonten angelegt und/oder Newsletter-Abonnenten erstellt.

Viele fragen sich-während sie sich ärgern- “Warum machen die das?” oder “Was ist der Sinn?”. Eine klare Antwort kann ich darauf nicht geben aber einen Ansatz:

Es werden zwar automatisch von Bots Kundenkonten erstellt, die verwendeten Mail-Adressen sind aber nicht falsch. In den letzten Fällen waren es meist E-Mail-Konten von @mail.ru, @gmail.ru, @inbox.ru, @bk.ru, @list.ru und weiteren russischen Mail-Hostern. Generell existieren wohl die meisten der Mail-Adressen und erhalten somit nach Anmeldung im jeweiligen Shop eine Bestätigungs-Mail von diesem = es werden also echte Mails von einem echten Shop (-Absender) an echte Menschen verschickt. Das wäre also Absicht 1. Nun die Frage “Warum? Es ist doch nur eine normale Anmelde-Bestätigungs-Mail…”. Ja, ist es ABER die Bots verwenden für ihre “Werbenachricht” den Kundennamen. Daher steht hier auch so ein langer Text drin. Als Beispiel:

Bild

Laut Google-Translate heißt dies wohl so ganz grob

Bild

Wir sehen also einen gewissen “Sinn” in der Nachricht. Nun stellen wir uns aber vor, dass dies als Name in der “Hallo [Name] und herzlich willkommen im X-Shop!”-E-Mail zur Bestätigung der Anmeldung im Onlineshop verwendet wird. Macht eigentlich keinen Sinn… Im Vergleich zu den SPAM-Mails, die wir jeden Tag bekommen wohl eine glatte 6.

Welchen tieferen Sinn dies macht bzw wie effizient dies ist, kann ich nicht sagen, Fakt ist aber, dass die Registrierungsfunktion des Magento-Shops für diesen Nutzen vielfach verwendet wird. In unserem aktuellen Fall auch gerne knapp 300 Mal innerhalb von 12 Stunden.

Was kann man dagegen tun? Leider gibt es auf diese Frage keine klare Antwort, da das Problem tief geht. Ich möchte die folgenden Ansätze vorstellen:

Bild1. Magento Captcha: Magento verfügt ab Version 1.7 über eine fertig eingebaute Captcha-Funktion. Diese muss nur aktiviert werden, um für die Kundenregistrierung, den Login, die “Passwort-vergessen”-Funktion und den Checkout verwendet zu werden (mögliche Anpassungen für das eigene Template notwendig). Hierzu unter System > Konfiguration > Kunden / Kundenkonfiguration / CAPTCHA gehen.

BildDort kann man das Captcha dann für die verschiedenen Bereiche im Frontend aktivieren.

Für die Newsletter-Anmeldung oder das Kontakt-Formular geht dies im Standard nicht.

2. Google reCaptcha: Das wohl aktuell am häufigsten im Internet anzutreffende (re)Captcha. Für die Nutzung bei Magento muss auf der einen Seite mit einem Google-Konto ein reCaptcha-Konto für den eigenen Shop / die Domain erstellt werden, um dann die so gewonnenen Keys im Shop einzusetzen. Zur Anzeige des Captchas gibt es dann verschiedene Möglichkeiten. Von der eigenen Implementierung über diverse Extensions (kostenfrei und kostenpflichtig). Ich persönlich würde bei der Extension darauf achten, dass man sich keine unnötige “Bloatware” mitinstalliert, da es ausschließlich um die Einbindung eines “Widgets” handelt, sollten große Datenbankänderungen durch die Extension nicht notwendig sein sowie Zusatzfunktionen überflüssig. Amasty bringt bei seinem kostenlosen Tool z.B. sowohl das eine als auch das andere mit – daher habe ich davon Abstand genommen. Hingegen wird bei der ebenfalls kostenlosen Extension von Turiknox nicht viel mehr gemacht als sein muss.

3. IP-Sperre: Wertet man die Server-Logs aus, erkennt man sehr deutlich relativ regelmäßige Ursprungs-IPs. In unserem Fall meist aus Russland. Hier kann es helfen diese IPs oder auch IP-Bereiche zu sperren. Dies haben wir über die .htaccess gemacht in der wir

<Files index.php>
Order Deny,Allow
Deny from XXX.XXX.XXX.XXX
Deny from XXX.XXX.
</Files>

eingetragen haben. Man kann die komplette IP ausschreiben oder aber nur Bereiche, indem man nur einen Teil schreibt (meist den vorderen). Umso weniger man schreibt, desto mehr wird geblockt. Das Risiko der ungewollten Blockierung steigt aber natürlich auch.

4. Da viele Einträge bei den neuen Kunden NICHT “reulär” über das Frontendskript erstellt wurden, sondern an diesem vorbei, bringt das Captcha (1 und auch 2) bei einigen Bots nichts. Sie erstellen weiterhin problemlos Kundenkonten. Wertet man die Logs aus, findet man hier immer wieder Aufrufe von /customer/account/createpost. Was ja generell korrekt ist. Der Unterschied liegt jedoch in der Historie bzw. dem Zusammenhang.

Erstelle ich mit einem normalen User ein Kundenkonto, sieht dies im Log so aus:

Meine.IP.Adresse.hier - - [05/Jun/2018:12:02:28 +0200] "GET /index.php/customer/account/create/ HTTP/2.0" 200 10055 "https://www.hiermeineshopurl.de/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0"
Meine.IP.Adresse.hier - - [05/Jun/2018:12:02:53 +0200] "GET /index.php/customer/account/createpost/ HTTP/2.0" 302 - "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0"

Erstellt ein Bot einen Useraccount, sieht es hingegen so aus:

Die.Bot.IP.Hier - - [05/Jun/2018:12:11:20 +0200] "GET /index.php/customer/account/create HTTP/1.1" 200 10054 "https://www.hiermeineshopurl.de/index.php/customer/account/login/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Firefox/60.0"
Die.Bot.IP.Hier - - [05/Jun/2018:12:11:21 +0200] "POST /index.php/customer/account/createpost/ HTTP/1.1" 302 - "https://www.hiermeineshopurl.de/index.php/customer/account/create/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Firefox/60.0"
Die.Bot.IP.Hier - - [05/Jun/2018:12:11:22 +0200] "GET /index.php/customer/account/index/ HTTP/1.1" 200 9542 "https://www.hiermeineshopurl.de/index.php/customer/account/create/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Firefox/60.0"

Auffälligkeiten en masse. Wir hatten in diesem Shop testweise die Double-Opt-In-Funktion bei der Anmeldung deaktiviert und es fiel auf, dass sich umgehend eingeloggt wurde, um eine Kundenadresse zu hinterlegen.

5. HoneyPot: Bei einem solchen werden z.B. Dinge auf der Seite integriert, die ein Mensch nicht sieht und daher auch nicht beachten würde. Ein Bot “sieht” sie jedoch und reagiert entsprechend. Dies kann ein weiteres Feld oder eine Checkbox sein. Verwendet habe ich die gratis Extension Magento-Hackathon HoneySpam. Diese fügt ein URL-Feld zur Registrierung hinzu. Dieses ist für den normalen Nutzer nicht sicht- und somit auch nicht ausfüllbar. Wird es also ausgefüllt, war es ein Bot und die Registrierung wird abgelehnt.

6. Country-Block: Es gibt die Möglichkeit ganze Länder(kennungen) zu sperren und nicht auf die Seite zu lassen. Hierzu gibt es diverse Anleitungen, die man über Google finden kann sowie einige Extensions. Dies sollte aber immer die Ultima Ratio sein und daher noch mein letztes Ass im Ärmel, die

7. Email Blacklist: Es gibt einige Extensions, die so konfiguriert werden können, dass bei der Anmeldung definierte Mail-Adressen oder auch Teile von Mail-Adressen abgewiesen werden. Hier als Beispiel die Extension von Amasty zum Nulltarif (man holt sich aber wieder die “Bloatware” Amasty-Base mit in den Shop wie schon unter 2 beschrieben). Bei dieser Extension kann man viel mit dem Platzhalter * arbeiten. Somit wäre ein blockieren von *@mail.ru uvm. möglich.
Auch diese Möglichkeit birgt das Risiko gewollte Nutzer abzublocken, ist jedoch nicht ganz so rigoros wie Nr. 6.

Alles in allem konnten wir bislang die Flut der Spam-Registrierungen nur stark einschränken aber noch nicht verhindern. Wenn es hier etwas Neues gibt, schreiben wir. Wir freuen uns aber auch über Zuschriften bzw. Kommentare.

Update vom 07.06.2018

Nach Auswertung der neuen Server-Logs und weiteren Tests, möchte ich noch weitere Infos hinzufügen.

  1. Habe ich mal testweise einen neuen User erstellt und bei Vorname und Nachname mal einen kleinen Text eingebaut unter Nennung einer Super-Domain. Der Teil “Commercers mit IP XYZ [Anm.: IP habe ich genannt, damit ich morgen die Server-Logs nach meiner IP durchsuchen kann) – tolle Website unter www.commercers.com” wäre somit vergleichbar mit den Infos, die die Bots einbauen. Und man sieht deutlich, dass sowohl der Mail-Betreff als auch der Mail-Inhalt keinen wirklichen Sinn macht. ICH würde nicht auf die Idee kommen eine angeblich ausstehende Rechnung zu zahlen, weil dies in einem solchen Zusammenhang steht.
  2. Habe ich das Phänomen der systemischen Kundenregistrierung weiter beobachtet. Das Double-Opt-In für die Kundenregistrierung ist aktiviert. Somit muss jeder Kunde zuerst den Link in der Mail anklicken bevor er sich einloggen kann, um z.B. Adressdaten zu hinterlegen (in der Registrierungsmaske wird KEINE Adresse abgefragt!). Überraschenderweise sind aber alle von Bots angelegten Konten mit einer kompletten Adresse (alle aus Australien) hinterlegt. Die Bots haben also die Möglichkeit die Adressen schon bei der Registrierung zu hinterlegen, da man wohl davon ausgehen kann, dass der angespamte Russe sich kaum einloggen wird, um eine australische Adresse zu hinterlegen 😉
  3. Dies ein aktueller Auszug aus dem Server-Log:
    Hier.die.BOT.IP - - [06/Jun/2018:20:04:45 +0200] "POST /customer/account/createpost HTTP/1.1" 302 - "https://www.hiermeineshopurl.de/customer/account/create" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36"
    Hier.die.BOT.IP - - [06/Jun/2018:20:04:49 +0200] "GET /index.php/customer/account/index/ HTTP/1.1" 302 - "https://www.hiermeineshopurl.de/customer/account/create" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36"
    Hier.die.BOT.IP - - [06/Jun/2018:20:04:51 +0200] "GET /index.php/customer/account/login/ HTTP/1.1" 200 9870 "https://www.hiermeineshopurl.de/customer/account/create" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36"
  4. Ein häufiger Besucher der Seite ist auch der Mail.RU_Bot/2.0 mit folgendem Eintrag
    Hier.die.Bot.IP - - [06/Jun/2018:00:19:53 +0200] "GET /robots.txt HTTP/1.0" 200 67 "-" "Mozilla/5.0 (compatible; Linux x86_64; Mail.RU_Bot/2.0; +http://go.mail.ru/help/robots)"

    Interessant ist hier, dass er offensichtlich die robots.txt liest in der steht, dass er sich gefälligst vom Acker machen soll. Juckt ihn aber nicht sonderlich, da er nach dieser Lektüre die Arbeit fleißig aufnimmt und die Seite indiziert mit z.B.:

    Hier.die.Bot.IP - - [06/Jun/2018:01:51:34 +0200] "GET /index.php/contacts/ HTTP/1.1" 200 9208 "-" "Mozilla/5.0 (compatible; Linux x86_64; Mail.RU_Bot/2.0; +http://go.mail.ru/help/robots)"

    (die URL http://go.mail.ru/help/robots hilft einem übrigens nicht weiter. Ich denke aber nicht, dass der Bot selber ein Problem darstellt, da Mail.ru ein legaler Mail-Anbieter ist. Auf der Seite haben muss man ihn aber dennoch nicht.)

  5. Zusammenfassend für heute:
    • Die Bots nutzen eine Möglichkeit an der normalen Kontoerstellung vorbeizukommen. Somit hält sie das reCaptcha nicht auf.
    • Die Bots können bei der Registrierung auch gleich die Adresse mitgeben. Schaut man sich die register.phtml an, sind die Adressfelder dort hinterlegt, jedoch “hidden”. Somit sind sie für normale Nutzer nicht sicht- und ausfüllbar. Dies wäre somit ein geeigneter HoneyPot.

Update vom 12.06.2018

Nachdem alles nicht übermäßig viel brachte, versuchte ich nochmal das Magento eigene Captcha. Ich deaktivierte das Google reCaptcha und aktivierte das Standard Captcha. Auch wenn ich es vorher schon genauso eingestellt (s. Screenshot oben) hatte, versuchte ich es nochmals. Und siehe da: Es klappte. Seit diesem Zeitpunkt keinerlei SPAM-Registrierungen mehr. Laut Server-Logs wird weiterhin versucht auf den Shop zuzugreifen, durch die .htaccess und (wahrscheinlich) das Captcha geht aber keine Registrierung der Bots mehr durch.

Mal schauen. Wenn es etwas Neues gibt, melde ich mich.

Genutzt übrigens in Magento 1.9

Published by Covos

Seit 2009 arbeite ich nun intensiv mit Magento. Begonnen habe ich mit der Erstellung und dem Betrieb von B2C-Shops. Ausgeweitet wurde dies durch meine Tätigkeit im Logistik-Sektor. Hieraus entstanden erste spezialisierte B2E-Systeme. Heute arbeite ich tag-täglich mit spannenden B2C-, B2B- und B2E-Projekten und berichte in diesem Blog über Herausforderungen und gebe Insider-Tipps.

5 comments on “Magento – SPAM Registrierungen als Kunden oder für den Newsletter”

  1. A mí me está pasando lo mismo desde hace unos meses…era muy poco a poco…pero lo de hoy es bestial. Llevo como 1700 nuevas altas en lo que llevamos de día. Todas supuestamente de china… Y no puedo con ellos!

    1. Ayer tuvimos este problema en otra tienda (mail.ru registros de Australia). No más problemas después de activar Magento Captcha.

  2. Hallo, vielleicht würde es auch was bringen, die Formularfelder Name und Vorname auf z.B. jeweils 20 Zeichen zu beschränken. Länger sind Namen normalerweise nicht und der Platz für die vermeintliche Werbebotschaft wäre dann vielleicht zu wenig. Somit wäre es für den Spammer nicht mehr interessant genug.

    1. Moin! Das ist ein guter Ansatz. Die Frage ist wie der Bot mit der Fehlermeldung “Mehr als 20 Zeichen” umgeht. Ob er damit NICHT umgeht und somit kein Eintrag erstellt wird oder ob dann eben nur 20 Zeichen eingetragen werden. Ich könnte mir vorstellen, dass Ersteres zutrifft.

  3. Thanks for shining light on the reason for this. This has happened to us and I was completely baffled as to what the purpose of this was. That totally makes sense that it’s a way to send out spam emails.

Leave a Reply to Aaron Guzman

Your email address will not be published. Required fields are marked *