Neu Sprunghafte Zunahme von Visits bei JTL Shops

[nonorush]

Die IP wird nicht gesperrt und ich frage mich warum.

 

[tvd]

Hallo,

Probleme wie dieses werden sehr wahrscheinlich von sogenannten Bad Bots verursacht. Bei Shops geht es darum, Preise auszulesen oder sich mit geleakten Passwortdaten einzuloggen und Betrug zu begehen. In der Regel merkt man von denen nicht allzu viel. Sie machen grundsätzlich 20-30% des gesamten Traffics aus und laufen einfach mit. Ab und zu crawlt ein Bot die Zielwebsite ohne Rücksicht auf Verluste und zieht sie so runter. Das sieht in den Graphen sehr danach aus.

Bei der Lösung des Problems kann ich helfen. Ich biete einen Service an, der Bad Bots erkennt und automatisch über sperrt, z.B. über die Cloudflare-Firewall.

Meldet euch bei Interesse gerne per PN bei mir.

Viele Grüße,
Tobias

 

[lj-shadow]

Probleme wie dieses werden sehr wahrscheinlich von sogenannten Bad Bots verursacht. Bei Shops geht es darum, Preise auszulesen oder sich mit geleakten Passwortdaten....

Boah, DAS hätte ich jetzt nicht gedacht.

 

[chris42]

Fail2Ban sperrt bei uns einige IPs aber wirlliche Verbesserungen bei den Visits gibt es nicht. Jeden Tag werden es bei uns mehr trotz Fail2Ban. In dem Filter ist z.B. der Bot "zh_CN" gelistet trotzdem macht der Bot munter weiter weil die IP nicht gesperrt wurde. Wie kann das sein? Ist eventuell die Schreibweise im Filter falsch?

service fail2ban restart

sollte da ggf. helfen, der liesst dann die neue Konfig ein.....

 

[lj-shadow]

Vorher gff. noch max retry auf 1, die Sperrzeit hoch und die suchzeit ebenso..

Bei retry auf 1 sollte direkt nach dem Zugriff gesperrt werden.
Beachte aber, dass einige der Bots ganze ip ranges nutzen... X.1 wird gesperrt und der kommt mit x.2 usw. Wieder.
Das dauert ne Weile, daher die suchzeit hoch.

Wenn du zusätzlich die Bots anhand Ihres User Agents in der htaccess mit 403 begrüßt, bekommt er auch keine webseiteninhalte.
Und direkt danach wird er eben gesperrt für n weilchen

Bin nach ein paar Tagen aktuell auf 2990 gesperrten IPs

 

[JTL_Fan]

Vorher gff. noch max retry auf 1, die Sperrzeit hoch und die suchzeit ebenso..

Bei retry auf 1 sollte direkt nach dem Zugriff gesperrt werden.
Beachte aber, dass einige der Bots ganze ip ranges nutzen... X.1 wird gesperrt und der kommt mit x.2 usw. Wieder.
Das dauert ne Weile, daher die suchzeit hoch.

Wenn du zusätzlich die Bots anhand Ihres User Agents in der htaccess mit 403 begrüßt, bekommt er auch keine webseiteninhalte.
Und direkt danach wird er eben gesperrt für n weilchen

Bin nach ein paar Tagen aktuell auf 2990 gesperrten IPs

habens so eingestellt wie von @css-umsetzung in dem vorigen Post, aber wie oben bereits beschrieben trotzdem noch etliche Zugriffe.

Daher folgende Fragen

1. Wo setzt man denn die Suchzeit hoch und was regelt diese? Und auf welchen Wert?
2. gibts evtl mittlerweile ne geupdatete Fail2Ban Config?
3. Auf welchen Wert sollte die SPerrzeit dann gesetzt werden. ist ja schon bei 2 Tage

 

[lj-shadow]

Du kannst das im plesk beim Filter einstellen.
Die Angabe ist in Sekunden. Hab jetzt aber nicht im Kopf wo genau.
Sperrzeit ist bei mir 7 Tage.

 

[JTL_Fan]

Du kannst das im plesk beim Filter einstellen.
Die Angabe ist in Sekunden. Hab jetzt aber nicht im Kopf wo genau.
Sperrzeit ist bei mir 7 Tage.

du meinst suchzeit kann ich hier einstellen??? Was gebe ich da ein?

Zeitraum für IP-Adress Sperre ist klar aber was regelt die Suchzeit?

 

[lj-shadow]

Plesk -> Tools & Einstellungen -> sperren von ip Adressen -> Einstellungen

Dort sind die "grundeinstellungen".
Im Jail kannst du die Sperrzeit und "Maximale Anzahl an fehlgeschlagenen Anmeldeversuchen"
Noch mal jeweils anpassen

 

[JTL_Fan]

Plesk -> Tools & Einstellungen -> sperren von ip Adressen -> Einstellungen

Dort sind die "grundeinstellungen".
Im Jail kannst du die Sperrzeit und "Maximale Anzahl an fehlgeschlagenen Anmeldeversuchen"
Noch mal jeweils anpassen

Ok Danke

also in den Grundeinstelluingen ist bei uns folgendes drin - siehe Bild
Was würdest du hier empfehlen?

Im Jail ist folgendes Eingestellt, siehen Ebenso Bild

Es scheint also würde Fail2Ban nicht greifen. Seit 00:00 uhr schonn wieder 3000 Zugriffe was nicht normal ist

 

[lj-shadow]

Erkennung und Sperre hab ich auf 7 Tage.
(Erkennung ist vll etwas hoch)

Retry auf 1 (aber nur bei den Bad bots)
Bei SSH=1 zb würdest dich sonst selber aussperren, wenn du dich mal vertippst. (Wobei man den ssh Port ohnehin verschiebt, wenn ssh aktiv ist. Da ist bei mir vollkommen Ruhe)

 

[JTL_Fan]

Erkennung und Sperre hab ich auf 7 Tage.
(Erkennung ist vll etwas hoch)

Retry auf 1 (aber nur bei den Bad bots)
Bei SSH=1 zb würdest dich sonst selber aussperren, wenn du dich mal vertippst. (Wobei man den ssh Port ohnehin verschiebt, wenn ssh aktiv ist. Da ist bei mir vollkommen Ruhe)

OK sorry, dass ich nachhake, also so meinst du???

 

[lj-shadow]

Fast... auf dem Bild stellst du die 1 wieder auf 3.
Wegen dem, was ich grade geschrieben hab.

Dann gehst du zum Jail, stellst die Sperrzeit gleich ein, Anzahl der Fehlversuche dort dann auf 1

 

[JTL_Fan]

Fast... auf dem Bild stellst du die 1 wieder auf 3.
Wegen dem, was ich grade geschrieben hab.

Dann gehst du zum Jail, stellst die Sperrzeit gleich ein, Anzahl der Fehlversuche dort dann auf 1

ok danke dir erledigt.
Besucherzähler im Shop juckt das jedoch nicht. Der dreht schön kräftig weiter nach oben...

 

[lj-shadow]

Das ist kein Allheilmittel...
Und jede ip muss 1x zugreifen, bevor die dann für 7 Tage gesperrt wird. Kombiniere das mit der htaccess, dann zählt der Shop nicht mehr, weil der Zugriff dort schon gar nicht mehr ankommt.

 

[css-umsetzung]

Ich würde zuerst immer schauen wer da überhaupt zugreift, es kann ja sein das bei dir andere Bots sind oder etwas anderes diese Zugriffe verursacht.
Da es in einem access log zu unübersichtlich ist bietet es sich an meine Log Funktion zu verwenden, da die den Zugriff je Aufruf nur einmal protokolliert.

Und dann siehst du ja wer zickt und wenn dein Fail2Ban nicht greift, warum auch immer hast du noch die htaccess oder meine php Lösung.

 

[zttom]

Hallo zusammen,

es ist schön, wie sich diese Kommunikation zwischenzeitlich entwickelt hat. Wir von zitro Hosting möchten Euch an auch an unseren Erkenntnissen teilhaben lassen, da wir bei uns zwischenzeitlich schon das Botnetz auf ca. 200.000 IP-Adressen identifizieren konnten. Bilder und Skripte werden übrigens von dem Botnetz nicht geladen - wir vermuten aktuell, dass es das Botnetz auf die Artikelbeschreibungen und die Preise abgesehen hat

Zusammenfassend die Best-Practices für Eure Shops, die hier in den Posts einzeln schon erwähnt wurden, aber man sollte den Schutz gesamtheitlich aufbauen:

1.) Wie am Anfang von @css-umsetzung schon erwähnt, benötigt Ihr die IP-Tables-Filters. Die Regeln von @css-umsetzung oder @Stephs182 sind für den Anfang gut und werden auch funktionieren, allerdings muss der failregex angepasst werden, da er den Suchstring auch im Request sucht und sich nicht auf den User Agent beschränkt. Wenn ein Shop eine Artikel-URL benutzt, wo ein Teil von den Suchstrings vorkommt, dann werden auch legitime Requests geblockt. Daher besser:

failregex = ^<HOST> -.*"(GET|POST|HEAD).*HTTP\/\d+\.\d+" .* ".*" ".*(?:%(badbots)s|%(badbotscustom)s).*"$

Für die, die nicht so tief in der Materie stecken: zum Testen der Suchstrings lassen sich gut Online-Regex-Tester verwenden oder per Terminal über fail2ban-client.

Wir werden nächste Woche hier mal eine vollständige Liste der Suchstrings für die Bad-Bots publizieren. Wir nutzen aktuell eine Liste von ca. 250 Strings.

Zu der Frage nach den Suchzeiträumen von @JTL_Fan : Wenn ihr keine chinesischen Kunden habt, nehmt für beides: 604800

Leider wechselt das Botnetz für jeden Request die IP-Adresse, sobald ein Request durch fail2ban ins Leere läuft. Durch fail2ban und den wechselnden IP-Adressen geht die Last nicht zwangsweise zurück, sondern kann sogar noch stark zunehmen (das haben wir bei einigen Kunden beobachten können), was dann zu Punkt 2 führt:

2.) Zusätzlich zu fail2ban benötigt man auch den Schutz über die htaccess (es reicht der Schutz von @akBenutzer - wer es ganz schick haben möchte, leitet auf eine Webseite um, wo der "Kunde" über die Sperrung seiner IP-Adresse informiert wird).
Wie hier schon einmal kurz in dem Post von @lj-shadow erwähnt, blockiert fail2ban erst ab dem zweiten Request, da es die IP-Adresse erst aus den Apache-Logs extrahieren muss. D.h. der erste Request wird bei einem reinen fail2ban-Schutz immer abgearbeitet, was den htaccess-Schutz für den ersten Request notwendig macht.
Theoretisch reicht ein purer htaccess-Schutz (oder PHP basierten Schutz) für alle, die bspw. keinen fail2ban zur Verfügung haben, aber dann wird jeder Request an den Webserver weitergegeben und im Falle eines PHP-Skriptes wird der PHP-Interpreter noch belastet. Dies ist unperformanter als im Vergleich zu iptables: iptables vergleicht die Adressen über einen binären Suchbaum und benötigt egal wie viele IP-Adressen man in der Liste hat nur max. 32 bitweise Vergleiche, um zu entscheiden, ob eine Adresse blockiert werden soll.

3.) Bitte never ever:

Bei der Lösung des Problems kann ich helfen. Ich biete einen Service an, der Bad Bots erkennt und automatisch über sperrt, z.B. über die Cloudflare-Firewall.

Routet bitte nicht Euren Traffic über andere Dienstleister aus dem Ausland oder andere Anbieter im Inland. Denkt bitte an die DSGVO und wie Ihr Eure Kunden darüber informieren möchtet, dass der Verkehr gerade einmal ins Ausland und zurück geschickt wird. Fragt lieber Euren Hoster nach solchen Lösungen. Hoster haben i.d.R. auch ein großes Interesse daran Euch maßgeschneiderte Lösungen anzubieten. Dort bekommt Ihr dann alles aus einer Hand und die Sicherheit der Kundendaten ist über deren Auftragsdatenverarbeitungsvertrag geregelt. Wenn es bei einem Hoster nicht klappt, gibt es genügend andere...

4.) Zusätzlich blockieren wir eine Liste von bekannten bösartigen IP-Adressen aus verschiedenen Quellen, was mich zum nächsten Punkt bringt:

Wir beabsichtigen nächste Woche einen Dienst bereitzustellen, wo Ihr die aktuell ca. 200.000 und stetig steigenden IP-Adressen aus dem Botnetz über eine RESTful-API kostenfrei laden könnt, um Euren fail2ban-filter zu trainieren. Eine Anbindung an fail2ban werden wir hier auch posten. Wenn Ihr Eure gefundenen IP-Adressen automatisch über fail2ban über unseren Dienst mit den anderen betroffenen teilen wollt, dann könnt Ihr über eine PM an mich einen Accesstoken erhalten. Accesstoken und Schnittstelle kommen dann vrstl. Ende der kommenden Woche. Um die Datenschutzfrage vorweg zu nehmen: Wir haben mit dem Datenschutzbeauftragten des Land NRW abgeklärt, dass in Anwendungen zum Schutz von IT-Systemen, die IP-Adressen so lange aufbewahrt werden dürfen, wie diese zum Schutz der Systeme benötigt werden.

So far, seid wachsam

Tom

 

[lj-shadow]

Naja, um die Sache mit den Preisbots nochmal aufzugreifen, was ich ja von Anfang an vermutet habe...

Eigentlich(!) Wäre es noch viel besser, die Bots anders zu behandeln, als sie auszusperren.

Wenn ich die einfach nur aussperre, gebe ich dem ja trotzdem eine Info. Und zwar die, das er erwischt wurde.

Besser wäre es, ihm einfach falsche Infos zu geben.

Dann soll doch der Herr Mitbewerber seine Preise gern automatisch auf 1 Euro matchen.
Diese Tools gehören in meinen Augen verboten.
Wenn einer seine Mitbewerber-preise checken will, wozu er ja auch das Recht hat, dann bitte auch mit 2 Augen und nicht mit automatischen Tools auf Kosten *traffic/cpu* seiner Mitbewerber auf die Gefahr hin, dortige Systeme lahm zu legen.

 

[JTL_Fan]

Kann hier jemand nochmals ne aktuelle htaccess anbieten.


Wir haben aktuelle folgendes in der Htaccess, was scheinbar nicht reicht.

  # Blockieren von Chinesischen Suchmaschinen, siehe auch https://www.johnlarge.co.uk/blocking-aggressive-chinese-crawlers-scrapers-bots/
  RewriteCond %{HTTP_USER_AGENT} SeznamBot|MQQBrowser|Screaming|Snappy|DtoBot|Gigabot|DuckDuckGo-Favicons-Bot|Yandex|yandexbot|Yeti|slurp|TheWorld|YoudaoBot|Mb2345Browser|LieBaoFast|zh-CN|MicroMessenger|zh_CN|Kinza [NC]
  RewriteRule ^ - [F,L]

Hat daher jemand nochmals eine aktuelle htaccess für uns alle evtl.? UND ist es wichtig wo der Code in der htaccess etwa steht? (klar zwischen "<IfModule mod_rewrite.c> RewriteEngine on" aber darin dann, gibts da ne Reihenfolge? Ganz oben/unten?

Denn sehr seltsam ist folgendes:
Wir haben obigen Code in der Htaccess. Der Code für die Log von @css-umsetzung liefert aber immer noch Daten mit obigen Bots. Wie kann das sein dass die dann noch durchkommen?
siehe Bild

 

[zttom]

Denn sehr seltsam ist folgendes:
Wir haben obigen Code in der Htaccess. Der Code für die Log von @css-umsetzung liefert aber immer noch Daten mit obigen Bots. Wie kann das sein dass die dann noch durchkommen?
siehe Bild

Dein Bild ist nicht sehr aussagekräftig. Der htaccess-Schutz leitet jeden Request des Botnetzes weiterhin zum Webserver, der den dann mit einem 403 Response-Code beantwortet. Jeder Request des Bot-Netzes taucht also weiterhin in dem Apache-Log auf. Zur Kontrolle der Funktion musst Du in Deinem Apache-Log nachsehen, ob der Request mit einem 403-Response-Code beantwortet wurde. Das ist der Unterschied zu fail2ban. fail2ban blockiert schon oberhalb der Netztwerkkarte und lässt den Request gar nicht mehr zum Webserver durchkommen.