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.

 

[Dyen]

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.

Ich glaube nicht, dass irgendjemand Server überlasten will. Das wird von den Scrapern nur in Kauf genommen. Die folgen einfach nur jedem auffindbaren Link, wenn die Domain einmal im Suchcluster aufgenommen wurde. Und nein, ich bastel nicht rum, schon gar nicht an der falschen Stelle.

 

[Matze_G]

Ich glaube nicht, dass irgendjemand Server überlasten will. Das wird von den Scrapern nur in Kauf genommen. Die folgen einfach nur jedem auffindbaren Link, wenn die Domain einmal im Suchcluster aufgenommen wurde. Und nein, ich bastel nicht rum, schon gar nicht an der falschen Stelle.

Kannst ja spaßeshalber mal einige der IP's, die so zugreifen z.B. auf abuseipdb.com prüfen. Bei mir waren die damals dort bekannt. Und Scraper, die über 300k verschiedene Adressen zugreifen, wie beim TO? Ich weiß nicht.

Ich will dir ja auch nichts unterstellen oder deine Kompetenz in Abrede stellen. Aber wenn du schon zweifel hast, dass dein individuelles Javascript irgendwann ausgehebelt werden könnte, dann wäre eine grundsätzliche Lösung sicher besser. Und hier greift der Ansatz von css-umsetzung.
Also nichts für ungut, wollte niemanden auf die Füße treten.

 

[Dyen]

Scraper, die über 300k verschiedene Adressen zugreifen, wie beim TO? Ich weiß nicht.

Mein Spitzenwert waren 607170 Filter-URL von 303817 IP-Adressen. Das sind die Werte eines Tages aus nur einem Cluster. Habe gerade noch mal in die Logdatei meines Analyse-Scriptes gesehen. Stichworte für die Google-Suche: Verteilte Scraper und residential proxys. Die Besitzer der Smartphones, die als Proxy agieren, wissen wahrscheinlich gar nichts von ihrem Glück, wundern sich höchsten mal, wenn das Gerät etwas wärmer wird. Wer liest schon die Nutzungsbedingungen beim Herunterladen einer kostenlosen App. Angebote für Proxys kannst du z.B. bei Brightdata einholen. Da erfährst du am Ende auch, wie du die Kosten des Scrapers in die Höhe treiben kannst. Ist der Preis zu hoch, zieht der Scraper weiter. Ich habe den Preis in die Höhe getrieben, und Andreas @css-umsetzung wird nichts anderes tun.

Mir war wichtig, dass die Filterfunktionen nicht eingeschränkt werden (siehe TO) und Besucher nicht ausgesperrt werden. Lieschen Müller mit ihrem Proxy-Smartphone kann im nächsten Augenblick auch deine Kundin sein. Darüber hinaus würde ich so tief wie irgend möglich ansetzen. Also wenn's geht, ohne PHP, schon gar nicht als Shop-Plugin.