Neu Sprunghafte Zunahme von Visits bei JTL Shops

[Shoppi01]

Ich weiß welche IT-Kenntnisse usw. die anderen Shopbetreiber haben, aber ich traue mich nicht an solche Sachen ran. Ich habe JTL- Hosting und erwarte eigentlich das ich nicht ein IT-Studium absolvieren muß.
Ich habe auch eine extreme Steigerung z.B. gestern beobachtet. Am kurz nach 11 Uhr ging es los (habe dann gleich ein Support- Ticket bei JTL aufgemacht, aber bisher keine Reaktion. Wahrscheinlich weil dort nur Mo-Fr 8-12, 13-17 Uhr gearbeitet wird und ich ja nur normaler Kunde ging und keinen super Premium Business Professional Advanced ... Support gebucht habe).
Kleine Steigerung von 0,5k auf 32k Zugriffe. Also nur das 64-fache zu normal. Heute inzwischen (Stand 11:30 Uhr) 30k. Wenn das so weiter geht werde ich heute locker die 60k erreichen. Endlich neuer Rekord.
Ich zumindest vermisse eine Lösung die für mich als DAU praktikabel anwendbar ist.

 

[zttom]

Ich zumindest vermisse eine Lösung die für mich als DAU praktikabel anwendbar ist.

Einfach an den Anfang der .htaccess-Datei im Webverzeichnis ergänzen:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond "%{HTTP_USER_AGENT}" "(MJ12bot|AhrefsBot|Semrush|Mb2345Browser|LieBaoFast|zh\-CN|MicroMessenger|zh_CN|DotBot|SEOkicks|MegaIndex\.ru)"
RewriteRule .* - [F,L]
</IfModule>

 

[Inge]

DAU-Kompatibel sind die hier vorgeschlagenen Lösungen mit .htaccess bzw einer robots.txt

Der Nachteil dieser DAU-Lösungen ist, dass sich dieser kinderleicht umgehen lassen und dir faktisch minimalen bis keinen Schutz bieten, dir so gar ein falsches Gefühl der Sicherheit geben.

Ein User-Agent wird im Botnetz in der Regel alle paar Tage automatisiert geändert, so würdest du dich zwar im Moment-Fall sicher fühlen, jedoch kann der Bot-Netzbetreiber jeder Zeit die User-Agents ändern.
Deine Fallen würden dann ins Leere laufen. Und man muss immer wieder nachpflegen. User-Agents sind schwache IOCs. Langfristig hilfst dir nur ein System aus Signalen und Automatischer-Mitteilung, ähnlich heutiger Antiviren-Signaturen. Du brauchst ein Netz aus Signalen, die vorzeitig solche Angriffe erkennen und diese rechtzeitig an andere Kunden weitergeben (sog. "Blacklists"). Für ein paar Projekte wird dies vorbildlich gemacht. Also wenn du es richtig machen möchtest, brauchst du diese Informationen irgendwo automatisiert (per API, per Script, per Cronjob) irgendeinen Automatismus, der dafür sorgt, dass du automatisch mit neuen Infos versorgt wird und deine Abwehr entsprechend angepasst wird.
Ich glaube, das obige Konstrukt ging auch in die Richtung. Ich würde hier jedoch auf etablierte Feeds setzen.

Zweites Problem, IP-Adressen können durchrotieren. Problem ist mit dem obigen Konstrukt, werden Clients erst gesperrt, nachdem IO verbraucht wurde. Klar kannst du einen Rate_Limiter an deine Site hängen und diesen bei Hit an Fail2ban übergeben, oder bei dem Fund eines bösen User-Agents, dessen IP an Fail2Ban übergeben, jedoch hat der Handshake hier schon statt gefunden. D.h. die Ressourcen sind bereits verbraucht.
Die obigen System, wenn richtig umgesetzt, erlauben Bots gar keine TCP Verbindung mehr aufzubauen (proaktiv, statt retrograd zu blocken). Das ist weitaus effizenzter.
Das ist generell kein Problem oder eine Thematik von JTL, sondern betrifft generell Bad Bots und Webscrapers und oder DDOS-Angriffe.
Man kann hier noch viel mehr machen, ein interessanter Bereich.

 

[Verkäuferlein]

Hat denn schon jemand herausgefunden, welchen Zweck das Botnetz bzw. deren Betreiber verfolgen?

Geht es darum Shop-Betreiber zu erpressen oder was ist die Zielsetzung?

 

[Stephs182]

Da jetzt öfters noch mal die Frage aufkam, welcher Ansatz nun der richtige sei und ob es eine Anleitung gibt: Die Erkennung des chinesischen Botnetzes (Mb2345Browser|LieBaoFast|zh\-CN|MicroMessenger|zh_CN) über die Fail2ban-Filter kann zu einer hohen Last durch die fail2ban-Prozesse auf dem Server führen, da das Botnetz mit einer hohen Anzahl von unterschiedlichen IP-Adressen zugreift. Fail2ban kann dann bei ungünstiger Konstellation zu sehr mit der Extraktion der IP-Adressen aus den Log-Files und der Verwaltung der IP-Adressen beschäftigt sein. Dies konnten wir sowohl auf unseren Servern als auch @css-umsetzung bei seinen Servern beobachten.

Hier mal ein Bild mit der durch fail2ban verursachten Prozessor-Last auf einem Kunden-Server bis zum 23. und der anschliessenden Prozessor-Last nach der Anbindung an unsere API:

Den Anhang 37370 betrachten

Wenn Ihr aktuell betroffen seid und eine schnelle Lösung sucht, reicht es vorerst aus, folgenden Code an den Anfang(!) der .htaccess einzufügen:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond "%{HTTP_USER_AGENT}" "(MJ12bot|AhrefsBot|Semrush|Mb2345Browser|LieBaoFast|zh\-CN|MicroMessenger|zh_CN|DotBot|SEOkicks|MegaIndex\.ru)"
RewriteRule .* - [F,L]
</IfModule>

@zttom vielen Dank für euer super Arbeit. Einer unserer Server ist auch extrem am schwitzen wegen dem Fail2Ban. Bei knapp 200.000 Ip die gerade gesperrt sind, musst ich die BadBot Jail nun rausnehmen und versuche über die Htaccess von dir erstmal den Betrieb aufrecht zu erhalten. Aber eine dauerhafte Lösung ist es in meinen Augen ja nicht.

Wir werden mal beratschlagen wie wir unseren Kurs nun ändern werden. So wie es gerade ist, kann es jedenfalls nicht weitergehen auf unseren Servern.

Fail2Ban:




Am Ende kann man deutlich die Abschaltung von Fail2Ban bzw. der Jail sehen.

Hat denn schon jemand herausgefunden, welchen Zweck das Botnetz bzw. deren Betreiber verfolgen?

Geht es darum Shop-Betreiber zu erpressen oder was ist die Zielsetzung?

Zu 100% kann es keiner sagen. (wird man auch meiner Meinung kaum rausbekommen können) Aktuell kann man nur sagen, dass sie Preise und Artikeldaten sammeln um ein großes Netzwerk an Daten aufzubauen.

Im Übrigen erfahre ich gerade, dass nicht nur JTL- Shop Ziel der Attake ist, sondern mittlerweile auch andere Shop-Systeme!

 

[Point13]

@zttom

Danke für den Hinweis mit der Auslastung von F2B. Mit der htaccess entspannt sich tatsächlich die ganze Lage.

 

[martinwolf]

An die Profis hier: Könnte man für die Bots nicht auf ein 410 (Gone) umleiten, oder würde das ggf. weitere Probleme mit sich bringen?

 

[Stephs182]

Naja im Grunde wird ja aktuell nix anderes getan. Ob nun 403 oder 410 ist ja im Grunde egal. bzw. sagen wir mal, es erziel das gleiche Ergebnis.

Wir vermuten, das im asiatischen Raum irgendeine App(s) dazu genutzt wird um die Daten zu sammeln und die User der Handys das gar nicht wirklich mitbekommen was ihr Handy oder Tab da eigentlich macht.
Zu erkennen ist ja klar, das es mobile Geräte sind. Da ja die Bots erkennen, wenn sie gesperrt werden und dann mit einer anderen IP kommen, macht es wenig Sinn die IPs da zu sperren. Die Ips kommen eh so schnell nicht mehr wieder.

Deshalb wollen wir jetzt eher mit dem GEOip Modul des Apache in Kombination zwischen Mobil (android) und Land zu sperren.

Fail2Ban ist super, aber verbraucht einfach zu viele Ressourcen.

 

[Stephs182]

So, ich habe es mal ein wenig getestet. GEOip funktioniert schon, wie aber schon geschrieben würde ich lieder das Land mit UserAgent "Android" in Kombination sperren.

Leider bringe ich die Kombination in der Htaccess noch nicht final zusammen. Kann da jemand unterstützen?! (Ich habe die Codes hier aus dem Thread mal zusammen getan und versuche zu kombinieren)

    SetEnvIf GEOIP_COUNTRY_CODE JP BlockCountry
    SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry
    SetEnvIf GEOIP_COUNTRY_CODE KP BlockCountry
    SetEnvIf GEOIP_COUNTRY_CODE KH BlockCountry
    SetEnvIf GEOIP_COUNTRY_CODE KR BlockCountry
    SetEnvIf GEOIP_COUNTRY_CODE HK BlockCountry
    
SetEnvIfNoCase User-Agent "Android" BlockMobil

    Deny from env=BlockCountry&BlockMobil

Also wenn BlockCountry und BlockMobil zutrifft, dann soll gesperrt werden.
Mein Code ist komplett ungetestet und nur theorietisch... aber ich glaube das haut so noch nicht so hin.

 

[Rektor]

Hat denn schon jemand herausgefunden, welchen Zweck das Botnetz bzw. deren Betreiber verfolgen?

Geht es darum Shop-Betreiber zu erpressen oder was ist die Zielsetzung?

Offensichtlich ist in erster Linie das Ziel, Produkte von einzelnen Händlern auf Fakeseiten zu listen. Wir haben in den letzten Monaten festgestellt, das unsere Produkte (unser Artikelbild und Beschreibung) auf vielen Fakeshops zu Schnäppchenpreisen angeboten werden. Diese Fakeseiten oder auch Fakeshops listen teilweise Millionen von Artikel unterschiedlichster Produktsparten. Offensichtlich sollte JTL schnellstmöglich eine entsprechende Funktion zum Unterbinden dieser kriminellen Natur im Shop zur Verfügung stellen, und zwar auch für nicht IT-Spezialisten.

 

[hula1499]

Offensichtlich sollte JTL schnellstmöglich eine entsprechende Funktion zum Unterbinden dieser kriminellen Natur im Shop zur Verfügung stellen, und zwar auch für nicht IT-Spezialisten.

Offensichtlich .... hast du 0 Ahnung, aber es sei dir verziehen.

Der Häuslbauer ist auch nicht dafür verantwortlich, wenn irgendwann mal ein Auto den Zaun umfährt und dir deine geliebten Gartenzwerg kaputt macht...

JTL könnte zwar an möglichen Lösungen/Vorschläge mitarbeiten, aber wenn sich eh User darüber unterhalten, halten sie sich raus und sparen sich die Zeit

 

[zttom]

So, ich habe es mal ein wenig getestet. GEOip funktioniert schon, wie aber schon geschrieben würde ich lieder das Land mit UserAgent "Android" in Kombination sperren.

[....]

Also wenn BlockCountry und BlockMobil zutrifft, dann soll gesperrt werden.
Mein Code ist komplett ungetestet und nur theorietisch... aber ich glaube das haut so noch nicht so hin.

Ich habe gerade mal etwas nachgedacht und in unseren Daten gegraben: GeoIP in Kombination mit UserAgent Android in der htaccess ist m.E. ein Lookup in der GeoIP-Datenbank zu viel, da sich das chinesische Botnetz über die 4 Pattern "zh-CN", "MicroMessenger", "Mb2345Browser" und "LieBaoFast" gleich verteilt. Fast alle User-Agents aus der Klasse des zh-CN-Patterns kommen mit dem UCBrowser (UC Browser is a web browser developed by the Singapore/China-based mobile Internet company UCWeb, which is in turn owned by the Alibaba Group. It is more popular than Google Chrome in some of Asia's fastest-growing markets like India and Indonesia.) und dem MQQBrowser (Pattern zh_CN). Wenn man also befürchtet mit zh-CN|zh_CN sämtliche Chinesen auszusperren, könnte man stattdessen auch UCBrowser und MQQBrowser als Pattern verwenden. Die anderen Pattern werden auch nur in Asien verwendet: 'MicroMessenger' => WeChat App, mb2345browser => Chinese web directory 2345.com, LieBaoFast => ?. Performanter als ein GeoIP-Lookup bei jedem Request wäre also immer noch das htaccess-Pattern von oben (ggf. mit Ersetzung von "zh\-CN|MicroMessenger|zh_CN" durch "MicroMessenger|UCBrowser|MQQBrowser"). Oder übersehe ich da was?

 

[Rektor]

schnellstmöglich eine entsprechende Funktion zum Unterbinden dieser kriminellen Natur im Shop zur Verfügung stellen

Offensichtlich .... hast du 0 Ahnung, aber es sei dir verziehen.

Der Häuslbauer ist auch nicht dafür verantwortlich, wenn irgendwann mal ein Auto den Zaun umfährt und dir deine geliebten Gartenzwerg kaputt macht...

JTL könnte zwar an möglichen Lösungen/Vorschläge mitarbeiten, aber wenn sich eh User darüber unterhalten, halten sie sich raus und sparen sich die Zeit

Offensichtlich verstehst DU den Sachverhalt nicht richtig....

Geschrieben wurde, "Offensichtlich sollte JTL schnellstmöglich eine entsprechende Funktion zum Unterbinden dieser kriminellen Natur im Shop zur Verfügung stellen, und zwar auch für NICHT IT-Spezialisten." Dementsprechend haben wir wenig bis 0-Ahnung davon, was uns von dir großzügig verziehen wurde.

Das bedeutet ganz einfach, das nicht alle Nutzer vom JTL-Shop in der Lage sind, eventuell schädliche Bots selbst abzuwehren. Der Fokus liegt darauf, mit welcher Materie sich der Nutzer im Detail beschäftigt. Wird bekannt, das viele JTL-Shops davon betroffen sind, wird JTL sicherlich was unternehmen müssen. Offensichtlich ist das der Fall, weshalb auch immer. Komischerweise sind einige andere Shopsysteme davon nicht betroffen, gemäß keinen Einträgen im Web.

 

[zttom]

@Rektor:

Auch wenn dies Art der Kommunikation nicht zielführend für die Lösung des Problems ist, muss ich dennoch mal dazwischen grätschen:

Als Hoster kann ich bestätigen, dass dieses Botnetz es auch auf andere Webseiten ausser JTL abgesehen hat. Zudem gibt es das Botnetz schon länger und es findet sich auch Kommunikation bzgl. anderer CMS-Systeme im Netz:

https://wordpress.org/support/topic/resource-limit-reached-error-due-to-targetted-attacks/
https://www.johnlarge.co.uk/blocking-aggressive-chinese-crawlers-scrapers-bots/
https://community.cloudflare.com/t/ddos-from-china-botnet/129380

Angriffe jeglicher Art abzuwehren erfordert Verständnis über die Angreifer, deren Methoden und die Möglichkeiten einer geeigneter Abwehr. Das gilt für den Cyber-Raum genauso wie für das reale Leben.

Für die Abwehr von Bot-Netzen benötigt man technisches Verständnis. Dafür gibt es dann Experten wie bspw. Cloudflare, Deinen Hoster oder ggf. Deinen Servicepartner. Dass ein ein vernünftiger Schutz ständige Anpassungen erfordert und vollumfänglich nicht als Gratisbeilage bei einem Produkt beiliegt, ist selbstverständlich. Eine einfache und kostenfreie Abwehr zum aktuellen Angriff findest Du oben im Beitrag #182. Cloudflare ist dann das andere Extrem.

Ich würde mich freuen, wenn wir alle hier wieder zur Diskussion einer technischen Lösung zurückkehren.

 

[maydo]

wir sind zum Glück nicht von dem problem betroffen.
habe aber bei einem kollegen (ebenfalls jtl shop) einen anstieg gesehen, von ca. 5k regulär auf 150k visits, das ist schon extrem

ich sehe das ähnlich, hat wenig bis gar nichts mit dem JTL Shop als System zu tun, solche Angriffe können immer erfolgen, unabhängig davon welche webpräsenz man betreibt

 

[hula1499]

schnellstmöglich eine entsprechende Funktion zum Unterbinden dieser kriminellen Natur im Shop zur Verfügung stellen

Das bedeutet ganz einfach, das nicht alle Nutzer vom JTL-Shop in der Lage sind, eventuell schädliche Bots selbst abzuwehren. Der Fokus liegt darauf, mit welcher Materie sich der Nutzer im Detail beschäftigt. Wird bekannt, das viele JTL-Shops davon betroffen sind, wird JTL sicherlich was unternehmen müssen. Offensichtlich ist das der Fall, weshalb auch immer. Komischerweise sind einige andere Shopsysteme davon nicht betroffen, gemäß keinen Einträgen im Web.

Wie auch schon zttom richtig schreibt, ist das kein JTL Phänomen. Wir haben das viel stärker bei einem Shopware und einem Joomla Shop.
Weder der Shopersteller noch der Hoster sind in der Pflicht, etwas zu machen.

Wende dich an einen Servicepartner von JTL oder an einen IT Fachmann, der Gegenmaßnahmen ergreifen kann. JTL selbst wirds - zurecht - nicht sein.
Es gibt hier bereits diverse Ansätze die gepostet wurden, setze (nach reiflicher Überlegung) diese um oder lasse sie, von einem Fachmann, umsetzen.

Wer hier jetzt welchen Sachverhalt nicht versteht, lass ich mal, der ruhe wegen, unkommentiert

 

[microline]

Ich habe css-umsetzung damit beauftragt, mir eine effektive Sperre einzurichten.
Innerhalb 24 Stunden war Ruhe mit den bots und es bleibt auch ruhig.

Wer sich also nicht an die Shop Dateien rantraut, so wie ich, einfach einen fähigen Servicepartner kontaktieren.

 

[_simone_]

Howdi, da hat Andreas wohl ein "deny all" eingebaut.
*duckundwech*

 

[microline]

Ne, ich habe momentan keine Saison, passt schon

 

[css-umsetzung]

Howdi, da hat Andreas wohl ein "deny all" eingebaut.

Na toll... jetzt hab ich wieder Panik die sich in Schnappatmung und Herzrasen bemerkbar macht