Neu Massenweise zugriff auf Merkmalfilter

[_jb_]

Hallo Allerseits,
das Problem ist hier ja schon mehrfach diskutiert worden, auch mit Lösungsvorschlägen.

Seit gestern hatten wir hier wieder spürbare Probleme. Einerseits weisen sich die Bots, die alle möglichen Merkmalskombinationen aufrufen, nicht mehr aus, wodurch sie nicht mehr identifiziert werden können. Andererseits werden die Merkmale von sehr vielen IPs aus aufgerufen, wodurch sich auch kein Ratelimit festlegen lässt.

Von ca. Mitternacht bis jetzt alleine wurde von 393034 unterschiedlichen IPs aus auf unseren Shop zugegriffen. Und wir betreiben einen wirklichen kleinen Shop, mit wenigen hundert Kunden.

Das Nadelöhr dabei sind sehr wahrscheinlich die PHP Worker. Mein Notbehelf war jetzt erst mal im Nginx Proxy das zu setzen:

if ($request_uri ~ "__.*__") {
    return 403;
}

if ($http_referer ~ "__.*__") {
    return 403;
}

Und zusätzlich habe ich das Child Theme dahingehend angepasst, dass man nur noch ein Merkmal gleichzeitig auswählen kann. Angezeigt wird das über Radio Buttons, statt Checkboxen.

Hat hier jemand in letzter Zeit ähnliches beobachtet? Und was waren eure Lösungen?

 

[Ilija]

Ich würde die Sperre an den Session-Cookie hängen: Anfragen mit __ in URL oder Referer nur dann mit 403 beantworten, wenn kein JTLSHOP-Cookie mitkommt. Wer vorher eine normale Seite im Shop aufgerufen hat, hat den Cookie und kann wieder mehrere Merkmale kombinieren, dann könnten auch die Checkboxen zurück. Bots, die ohne echten Browser direkt auf die Filter-URLs springen, haben ihn nicht. In nginx geht das mit zwei if-Abfragen, die eine Hilfsvariable zusammensetzen, weil sich if nicht verschachteln lässt. Hält aber nur, solange die Bots keine Cookies mitschleppen, gegen echte Headless-Browser hilft es nicht. Den Cookienamen vorher im Browser prüfen, falls er bei euch anders heißt.

 

[css-umsetzung]

Ich habe eine kostenpflichtige, updatesichere Lösung, die bereits mehrfach, wir sprechen hier von über 100x im Einsatz ist und das sehr gut abfängt.
schreibe mich einfach per PN an, wenn du Interesse daran hast.

 

[Dyen]

Ich hatte das Problem zuletzt auch, ebenfalls in dieser Größenordnung. Gegenmaßnahmen an den Session-Cookie zu hängen, ist richtig im Hinblick auf richtige Besucher. Den Scraper hat es in meinem Fall aber nicht aufgehalten. Erst eine kleine Javascript-Challenge auf nginx-Ebene hat den Spuk beendet. Nach 36 Stunden Datenmüll einsammeln wurde er abgeschaltet, testet aber nach wie vor. Ich habe mir auch schon Gedanken darüber gemacht, was zu tun ist, wenn der Scraper doch plötzlich Javascript ausführt, aber seit 3 Wochen hält es so.

Die Lösung ist sehr individuell und nicht geeignet hier geteilt zu werden. Praktikabler, und für unterschiedliche setups besser geeignet, ist wahrscheinlich ein Ansatz auf der Ebene der config.JTL-Shop.ini.php. So wie ich @css-umsetzung verstanden habe, tut er genau das. Und die Rückmeldungen seiner Kunden in dieser Sache hier im Forum sind durchweg positiv.

Wenn die Maßnahmen helfen und die Last vom Server genommen wurde, würde ich darüber nachdenken, wie es überhaupt dazu kommen konnte. Ein Scraper, der blind jedem Link folgt, verläuft sich im JTL-Shop-Linklabyrinth der unbegrenzten Möglichkeiten.

 

[Matze_G]

Ich kann euch nur den Tipp geben, die Lösung von Andreas @css-umsetzung zu nehmen.
Diese Angriffe hatten wir letztes Jahr auch. Sie zielen darauf ab, eine hohe PHP-Auslastung zu erzeugen. Andreas hat eine tolle Lösung für faires/kleines Geld. Und seit dem ist Ruhe. Danke nochmal.
Alles andere ist rumgebastel an falscher Stelle.