Neu Sprunghafte Zunahme von Visits bei JTL Shops

[lj-shadow]

Ja, ich habe einen optimierten.
Schreib mich einfach an dann schicke ich dir den morgen per Mail.

Erledigt...

 

[301Moved]

Kann ich in mehreren älteren Shops auch so feststellen, sprunghafte Anstiege für ein paar Tage. In neueren Shops ist das nicht gegeben... spannend

 

[css-umsetzung]

Da ich bereits einige Anfragen hatte hier mal die Filter die ich verwende:
Wenn ich diesen Filter bei mir aktiviere dann sehe ich sofort das sich etwas tut, da man ja eigentlich ständig von nicht gewollten Bots besucht wird.

Plesk Bad Bot Filter:

[Definition]
badbotscustom = EmailCollector|WebEMailExtrac|TrackBack/1\.02|sogou music spider|(?:Mozilla/\d+\.\d+ )?Jorgee|MJ12bot
badbots = Atomic_Email_Hunter/4\.0|atSpider/1\.0|autoemailspider|bwh3_user_agent|China Local Browse 2\.6|ContactBot/0\.2|ContentSmartz|DataCha0s/2\.0|DBrowse 1\.4b|DBrowse 1\.4d|Demo Bot DOT 16b|Demo Bot Z 16b|DSurf15a 01|DSurf15a 71|DSurf15a 81|DSurf15a VA|EBrowse 1\.4b|Educate Search VxB|EmailSiphon|EmailSpider|EmailWolf 1\.00|ESurf15a 15|ExtractorPro|Franklin Locator 1\.8|FSurf15a 01|Full Web Bot 0416B|Full Web Bot 0516B|Full Web Bot 2816B|Guestbook Auto Submitter|Industry Program 1\.0\.x|ISC Systems iRc Search 2\.1|IUPUI Research Bot v 1\.9a|LARBIN-EXPERIMENTAL \(efp@gmx\.net\)|LetsCrawl\.com/1\.0 \+http\://letscrawl\.com/|Lincoln State Web Browser|LMQueueBot/0\.2|LWP\:\:Simple/5\.803|Mac Finder 1\.0\.xx|MFC Foundation Class Library 4\.0|Microsoft URL Control - 6\.00\.8xxx|Missauga Locate 1\.0\.0|Missigua Locator 1\.9|Missouri College Browse|Mizzu Labs 2\.2|Mo College 1\.9|MVAClient|Mozilla/2\.0 \(compatible; NEWT ActiveX; Win32\)|Mozilla/3\.0 \(compatible; Indy Library\)|Mozilla/3\.0 \(compatible; scan4mail \(advanced version\) http\://www\.peterspages\.net/?scan4mail\)|Mozilla/4\.0 \(compatible; Advanced Email Extractor v2\.xx\)|Mozilla/4\.0 \(compatible; Iplexx Spider/1\.0 http\://www\.iplexx\.at\)|Mozilla/4\.0 \(compatible; MSIE 5\.0; Windows NT; DigExt; DTS Agent|Mozilla/4\.0 efp@gmx\.net|Mozilla/5\.0 \(Version\: xxxx Type\:xx\)|NameOfAgent \(CMS Spider\)|NASA Search 1\.0|Nsauditor/1\.x|PBrowse 1\.4b|PEval 1\.4b|Poirot|Port Huron Labs|Production Bot 0116B|Production Bot 2016B|Production Bot DOT 3016B|Program Shareware 1\.0\.2|PSurf15a 11|PSurf15a 51|PSurf15a VA|psycheclone|RSurf15a 41|RSurf15a 51|RSurf15a 81|searchbot admin@google\.com|ShablastBot 1\.0|snap\.com beta crawler v0|Snapbot/1\.0|Snapbot/1\.0 \(Snap Shots, \+http\://www\.snap\.com\)|sogou develop spider|Sogou Orion spider/3\.0\(\+http\://www\.sogou\.com/docs/help/webmasters\.htm#07\)|sogou spider|Sogou web spider/3\.0\(\+http\://www\.sogou\.com/docs/help/webmasters\.htm#07\)|sohu agent|SSurf15a 11 |TSurf15a 11|Under the Rainbow 2\.2|User-Agent\: Mozilla/4\.0 \(compatible; MSIE 6\.0; Windows NT 5\.1\)|VadixBot|WebVulnCrawl\.unknown/1\.0 libwww-perl/5\.803|Wells Search II|WEP Search 00|.*AhrefsBot.*|.*seoscanners.*|.*MJ12bot.*
failregex = ^<HOST> -.*"(GET|POST|HEAD).*HTTP.*"(?:%(badbots)s|%(badbotscustom)s)"$
ignoreregex =
datepattern = ^[^\[]*\[({DATE})
    {^LN-BEG}

Dazu diese Einstellungen:

[plesk-apache-badbot]
enabled = true
filter = apache-badbots
action = iptables-multiport[name=BadBots, port="http,https,7080,7081"]
logpath = /var/www/vhosts/system/*/logs/*access*log
/var/log/apache2/*access.log
maxretry = 1

Dann habe ich noch einen für SQL Injects falls jemand denkt den auch haben zu müssen
Filter:

[Definition]
sqlfragments_generic = select.*from|delete.*from|update.*set|insert.*into|replace.*(value|set)
sqlfragments_havij = and(\+|%%20)ascii%%28substring|and(\+|%%20)Length|union(\+|%%20)all(\+|%%20)select|and(\+|%%20)1%%3C1|and(\+|%%20)1%%3D1|and(\+|%%20)1%%3E1|and(\+|%%20)%%27.%%27%%3D%%27|%%2F\*%%21[0-9]+((\+|%%20)[0-9]*)?\*%%2F
failregex = ^<HOST> -[^"]*"[A-Z]+\s+/[^"]*\?[^"]*(?:%(sqlfragments_generic)s|%(sqlfragments_havij)s)[^"]*HTTP[^"]*"
ignoreregex =

Einstellung:

[apache-sqlinject]
enabled = true
filter = apache-sqlinject
action = iptables-multiport[name=apache-sqlinject, port="http,https,7080,7081"]
logpath = /var/www/vhosts/system/*/logs/*access*log
/var/log/apache2/*access.log
maxretry = 1

 

[lj-shadow]

Ich hab den badbot Filter seit 12 std. Laufen.
Bisher lediglich 2x angeschlagen. Allerdings ist meine htaccess schon recht restriktiv. Ich weiß nicht, ob fail2ban daher die Zugriffe gar nicht erst bemerkt.
Filter 2 (sql) ist auch mal angesetzt...

Da meine htaccess seit eh und je so restriktiv ist und ich das ganze Jahr über immer wieder solche Spitzen habe, meist 1-3 Tage, bin ich eher weiterhin der Meinung, dass es preiscrawler sind, die sich hinter regulären kennungen verstecken.

 

[css-umsetzung]

Aus gegebenen Anlass und weil bei einer Seite nun fast gar nichts mehr ging und weil dort auch kein Fail2Ban aktiv sowie der Hoster "kreativkarussell" wohl seit Tagen nicht erreichbar ist, habe ich jetzt direkt gehandelt und mir das genauer angeschaut.

Also wer unnatürlich viele Zugriffe hat sollte in seiner config Datei vom Shop mal diesen Schnipsel einbauen, das legt in jtllogs ein Log an in dem steht wer alles auf den Shop zugreift:

    if($fp = fopen(PFAD_ROOT."jtllogs/zugriffslog_".date("d-m-Y").".log","a+")) {
        fwrite($fp,$_SERVER['REMOTE_ADDR']."                ".$_SERVER['HTTP_USER_AGENT']."\n");
        fclose($fp);
    }

Wer dann sieht das da Zugriffe von Crawlern wie KInza,Mb2345Browser,LieBaoFast,MicroMessenger oder etwas findet wie zh-CN sollte dann einfach diesen Schnipsel mit einfügen, am besten vor dem ersten Schnipsel damit man danach sieht was noch durch kommt, das kann auch nach belieben erweitert werden.

if(preg_match("/Mb2345Browser|LieBaoFast|zh-CN|MicroMessenger|zh_CN|Kinza|MJ12bot|AhrefsBot/",$_SERVER['HTTP_USER_AGENT'])) {
    header('HTTP/1.0 403 Forbidden');
    die("zugriff nicht erlaubt");
}

 

[bigboss]

Da wo ich es geprüft habe waren es viele IP Adressen aus Korea und dieser Region, das ging teilweise so weit das Host Europe schon den Webspace dicht machen wollte.

Das Problem kannten wir beide ja schon mal dieses Jahr.
Mit der IP Sperre in der .htaccess dieser ganzen Regionen funktiniert es die ganze Zeit nun schon gut.
Diesmal waren es bei uns polnische IP Adressen.

 

[JulianG]

Hallo zusammen,

wir haben dafür mal ein Ticket eröffnet, sodass sich unsere Entwicklung das zur Sicherheit mal ansehen kann: https://issues.jtl-software.de/issues/SHOP-3774

Ich persönlich kann nicht einschätzen, ob das wirklich Relevanz hat und würde pauschal erst einmal sagen, dass das normales Verhalten von Bots ist. Nacheinander werden URL's abgegrast und das ggf. auch ohne Rücksicht auf Belastung. Nacheinander bedeutet für mich ggf. auch, dass Bots nach IP-Range vorgehen könnten und somit vermehrt allgemein Shops in Deutschland betroffen sein könnten... und da die meisten JTL- Shop's in Deutschland betrieben werden, dürften dann auch einige JTL-Shop's in ungefähr gleichem Zeitraum abgegrast werden.

Aber wie gesagt, ich bin auf dem Gebiet kein Experte. Wir haben das Ticket für unsere Entwicklung und ich habe auch unsere Hosting-Abteilung mal darauf aufmerksam gemacht, vielleicht bekommen wir da auch noch Input. Sollte sich etwas ergeben, wird das im Ticket und hier gemeldet.

 

[css-umsetzung]

Ich persönlich kann nicht einschätzen, ob das wirklich Relevanz hat und würde pauschal erst einmal sagen, dass das normales Verhalten von Bots ist. Nacheinander werden URL's abgegrast und das ggf. auch ohne Rücksicht auf Belastung. Nacheinander bedeutet für mich ggf. auch, dass Bots nach IP-Range vorgehen könnten und somit vermehrt allgemein Shops in Deutschland betroffen sein könnten... und da die meisten JTL- Shop's in Deutschland betrieben werden, dürften dann auch einige JTL-Shop's in ungefähr gleichem Zeitraum abgegrast werden.

Hallo Julian,
Das Größte Problem hierbei ist die Menge der Sessions die erzeugt wird. Ihr habt zwar die Möglichkeit über ein define die sessions für Bots zu deaktivieren, aber eben nur für einen verschwindend geringen Teil an Bots, hier wäre es von Vorteil wenn man eigene Bots hinzufügen könnte, denn niemand erwartet von euch das Ihr jetzt auf Bot-detect Listen zugreift und Millionen von Bot Möglichkeiten abfragt.

 

[bbfdesign]

Moin,
Andreas ... Bei der Seite, bei der fast nichts mehr ging, wie viele Abrufe haben denn da in welcher Zeit statt gefunden? Das kann ja schon recht schnell zu Problemen im "Betriebsablauf" bei den Shops führen...

Ahjou - und frohes neues

 

[css-umsetzung]

HI Björn,
also da war es so das durch die Sessions wieder zu viele Dateien geschrieben wurden, es war also für andere Kunden
nachher nicht mehr möglich selbst etwas in den WK zu legen noch konnte ich mich als Admin im Backend einloggen.

Da der Hoster ja nicht erreichbar ist/wahr (was für mich völlig unverständlich ist wenn ich ein Hosting anbiete) hatte ich auch keine Möglichkeit in irgendwelchen Logs zu schauen was wirklich los ist und musste mir das alles ein wenig zusammenwürfeln. Zuerst dachte ich die Festplatte ist einfach nur voll aber letztendlich war es wohl eher die Menge der Dateien das keine neuen Sessions mehr angelegt werden konnten.
Zusätzlich war der Shop dadurch auffällig langsam.

Wenn ein Shop normalerweise 200-400 User am Tag hat und dann auf einmal fast 12k, dann ist das schon krass.

 

[bbfdesign]

Was mich irritiert ist, dass wir dieses Problem im Moment aber "nur" bei JTL Shops sehen. Andere Shops bzw. auch CMS Systeme haben dieses Problem im Moment nicht. Es scheint zumindest im Moment nur eine Problematik mit dem JTL Shop zu geben... Oder gibt es hier auch andere Beobachtungen ?

 

[chris42]

Wir haben auch eine Zunahme, etwa 10.000 - 15.000 am Tag.

mfg chris

 

[Sascha Reuters]

Hallo zusammen,

um hier eine gemeinsame Referenz zu schaffen, werden wir unsere eigenen Hostingsysteme ebenfalls auf die genannten Zugriffe prüfen und das Ergebnis an die Shopentwicklung weiterleiten.
In der Vergangenheit konnten wir wiederholt Zugriffe auf Hostings von asiatischen Bots feststellen, da wir aber verschiedene Mechanismen zum sperren von potentiell schadhaften IPs nutzen,
werden diese größtenteils geblockt bevor sie einen negativen Einfluss haben.

Ob es zu einem Anstieg der Zugriffe auf unsere Systeme innerhalb des letzten Monats kam, können wir zum jetzigen Zeitpunkt noch nicht sagen.
Relevante Informationen die durch unsere Analyse hervorgehen werden hier kommuniziert.

Viele Grüße

Sascha Reuters

 

[css-umsetzung]

Hier mal etwas zum staunen, wie schlimm es teilweise sein kann, die Bots die hier am Werkeln sind, sind die die ich oben mit meinem snippet gesperrt habe:

 

[elevennerds.de]

Interessant wären ja mal Ausschnitte aus der access. log was dort im User Agent-Feld steht. Ich bezweifle nämlich, dass die Verursacher so dumm und dort ihre Bot-Software eintragen.

Dann kann man solche Zugriffe fast nur noch mittels IP oder Javascript detektieren.

 

[akBenutzer]

Wir hatten vor einigen Wochen/Monaten das gleiche Problem.
Hier gibt es einen Lösungsansatz, der uns geholfen hatte:
https://www.johnlarge.co.uk/blocking-aggressive-chinese-crawlers-scrapers-bots/
In den Kommentaren in diesem Blogpost sind auch weitere User-Agents zu finden.

In der apache-accesslog-Datei seht ihr die User-Agents.

Update: Also der Blog behandelt die bereits genannten Zugriffe: MQQBrowser, LieBaoFast, Mb2345Browser, etc.
Sollte also die Lösung sein.

 

[css-umsetzung]

Interessant wären ja mal Ausschnitte aus der access.log was dort im User Agent-Feld steht. Ich bezweifle nämlich, dass die Verursacher so dumm und dort ihre Bot-Software eintragen.

Doch das sind sie, denn sonst könnte ich sie ja nicht Filtern

hier mal ein Auszug davon was ich gerade logge

 

[chris42]

Ich hatte heute genug und habe die Bot Chinesen im Firewall geblockt, die haben sich in Filter URLS im Kreis gedreht

ufw insert 2 deny from 159.138.0.0/16

ufw status numbered zeigt die aktuelle regeln an, der Deny muss vor die apache/nginx Regel.
Bei mir Nummer z.B. "2"

Etwa so:

ufw status numbered To Action From
-- ------ ----
[ 1] XXXX/tcp ALLOW IN XXXX
[ 2] Anywhere DENY IN 159.138.0.0/16
[ 3] Apache Full ALLOW IN Anywhere

mfg chris

 

[301Moved]

Aus gegebenen Anlass und weil bei einer Seite nun fast gar nichts mehr ging und weil dort auch kein Fail2Ban aktiv sowie der Hoster "kreativkarussell" wohl seit Tagen nicht erreichbar ist, habe ich jetzt direkt gehandelt und mir das genauer angeschaut.

Also wer unnatürlich viele Zugriffe hat sollte in seiner config Datei vom Shop mal diesen Schnipsel einbauen, das legt in jtllogs ein Log an in dem steht wer alles auf den Shop zugreift:

    if($fp = fopen(PFAD_ROOT."jtllogs/zugriffslog_".date("d-m-Y").".log","a+")) {
        fwrite($fp,$_SERVER['REMOTE_ADDR']."                ".$_SERVER['HTTP_USER_AGENT']."\n");
        fclose($fp);
    }

Wer dann sieht das da Zugriffe von Crawlern wie KInza,Mb2345Browser,LieBaoFast,MicroMessenger oder etwas findet wie zh-CN sollte dann einfach diesen Schnipsel mit einfügen, am besten vor dem ersten Schnipsel damit man danach sieht was noch durch kommt, das kann auch nach belieben erweitert werden.

if(preg_match("/Mb2345Browser|LieBaoFast|zh-CN|MicroMessenger|zh_CN|Kinza|MJ12bot|AhrefsBot/",$_SERVER['HTTP_USER_AGENT'])) {
    header('HTTP/1.0 403 Forbidden');
    die("zugriff nicht erlaubt");
}

Hier mal etwas zum staunen, wie schlimm es teilweise sein kann, die Bots die hier am Werkeln sind, sind die die ich oben mit meinem snippet gesperrt habe:

Den Anhang 36898 betrachten

Danke! Hab ich auch mal eingebaut in ein paar Shops, da sahen die Kurven genauso aus und ich konnte in der access.log auch nachvollziehen, dass es MicroMessenger, LieBaoFast, etc waren.




Spannend!

 

[blitz]

Hi, bei uns war es aktuell ein Pole und viele Südkorea

einfah in de .htaccess

order allow,deny
deny from 159.138
deny from 203.133
#deny from 46.229.168
deny from 3.1
deny from 18.18
deny from 35.15
deny from 54.93
deny from 52.59
deny from 185.172
allow from all

dann war erst einmal ruhe

Die JTL Shop .htaccess Datei ? Und wenn ja Position egal ? Am Anfang oder Ende ?!?
Würd das auch gerne versuchen bei uns sind es fast 70k zugriffe