Jump to content

Edit History

Ritter

Ritter

Seit 2 Tagen gibt es ca. alle 30 Minuten jeweils eine Fake-Anmeldung im Shop. Diese folgen alle dem gleichen Muster:
Name: ClaudemeawnEV, RobertNeelONT, RichardBerryRO, TyreesicUQ, usw.
Firma: immer Google
E-Mail: 80% Gmail.com, der Rest aol.com, hotmail.com, comcast,net, yahoo.com

Eine Überprüfung der dazugehörigen IP-Adressen ergibt eine Häufung der Provider:
PJSC MegaFon (Russland)
Facebook (USA)
OVH SAS (Großbritannien/Frankreich)
und einige wenige andere.

Zur Zeit sperre ich diese IP-Adressen jeweils über .htaccess, aber angesichts der bevorstehenden Feiertage keine so tolle Lösung, bzw. ich müsste prophylaktisch dann ganze Adressräume sperren.
Eine vorübergehende Deaktivierung des Module: Customer „sign in“ link war ohne Erfolg, Anmeldungen finden weiterhin statt

Die Daten zu den IPv6 Adressen im Log-file sind mehrfach verschlüsselt, nach der rekursiven Dekodierung sieht es so aus, als ob zumindest diese Adressen Crawlern zuzuordnen sind. z.B.:

meta-externalagent/1.1(+https://developers.facebook.com/docs/sharing/webmasters/crawler)""xxxxx.xx
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.3; +https://openai.com/gptbot)

Der Eintrag:

"POST /shop/de/index.php?controller=registration HTTP/1.0" 302 0 "https://xxxxx.xx/shop/de/index.php?controller=registration" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36" "xxxxx.xx"

deutet für mich darauf hin, dass die robot.txt:

Disallow: /*de/controllers/
Disallow: /shop/de/controllers/

ignoriert wird, so auch bei den IPv4-Adressen:

"GET /shop/de/index.php?controller=registration HTTP/1.0" 200 59244 "https://xxxxx.xx 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36" "xxxxx.xx"

Damit muss ich wohl leben.

Meine Frage aber: gibt es eine Möglichkeit diese Fake-Anmeldungen dauerhaft unterbinden, ohne echte Neukunden und Bestandskunden auszuschließen?

Ritter

Ritter

Seit 2 Tagen gibt es ca. alle 30 Minuten jeweils eine Fake-Anmeldung im Shop. Diese folgen alle dem gleichen Muster:
Name: ClaudemeawnEV, RobertNeelONT, RichardBerryRO, TyreesicUQ, usw.
Firma: immer Google
E-Mail: 80% Gmail.com, der Rest aol.com, hotmail.com, comcast,net, yahoo.com

Eine Überprüfung der dazugehörigen IP-Adressen ergibt eine Häufung der Provider:
PJSC MegaFon (Russland)
Facebook (USA)
OVH SAS (Frankreich)
und einige wenige andere.

Zur Zeit sperre ich diese IP-Adressen jeweils über .htaccess, aber angesichts der bevorstehenden Feiertage keine so tolle Lösung, bzw. ich müsste prophylaktisch dann ganze Adressräume sperren.
Eine vorübergehende Deaktivierung des Module: Customer „sign in“ link war ohne Erfolg, Anmeldungen finden weiterhin statt

Die Daten zu den IPv6 Adressen im Log-file sind mehrfach verschlüsselt, nach der rekursiven Dekodierung sieht es so aus, als ob zumindest diese Adressen Crawlern zuzuordnen sind. z.B.:

meta-externalagent/1.1(+https://developers.facebook.com/docs/sharing/webmasters/crawler)""xxxxx.xx
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.3; +https://openai.com/gptbot)

Der Eintrag:

"POST /shop/de/index.php?controller=registration HTTP/1.0" 302 0 "https://xxxxx.xx/shop/de/index.php?controller=registration" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36" "xxxxx.xx"

deutet für mich darauf hin, dass die robot.txt:

Disallow: /*de/controllers/
Disallow: /shop/de/controllers/

ignoriert wird, so auch bei den IPv4-Adressen:

"GET /shop/de/index.php?controller=registration HTTP/1.0" 200 59244 "https://xxxxx.xx 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36" "xxxxx.xx"

Damit muss ich wohl leben.

Meine Frage aber: gibt es eine Möglichkeit diese Fake-Anmeldungen dauerhaft unterbinden, ohne echte Neukunden und Bestandskunden auszuschließen?

×
×
  • Create New...