Neu Sprunghafte Zunahme von Visits bei JTL Shops

[akBenutzer]

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

Da sich die IP´s mit den Wochen ändern, schlage ich vor du folgst dem Blog-Beitrag #36

 

[blitz]

Da sich die IP´s mit den Wochen ändern, schlage ich vor du folgst dem Blog-Beitrag #36

Damit ist auch dann die .htaccess im jtl Shop Root Verzeichnis gemeint vermute ich ?

 

[css-umsetzung]

Ob das so klug ist so komplexe IP Bereiche zu blocken?
52.59 ist z.B. ein Bereich in Deutschland wenn ich das auf die schnelle richtig gesehen habe, mit Diensten von Amazon

Meine Lösung da oben, tut keinem weh und ist was die Performance angeht nicht wirklich relevant.

 

[blitz]

Ob das so klug ist so komplexe IP Bereiche zu blocken?
52.59 ist z.B. ein Bereich in Deutschland wenn ich das auf die schnelle richtig gesehen habe, mit Diensten von Amazon

Meine Lösung da oben, tut keinem weh und ist was die Performance angeht nicht wirklich relevant.

Du meinst die mit der Config Datei ?

 

[akBenutzer]

@blitz Ja die .htaccess im Shop Root ist gemeint.
Der Eintrag in der .htaccess könnte so aussehen:
<IfModule mod_rewrite.c>
RewriteEngine on

...

# 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]

...
</IfModule>
Je nachdem wie deine .htaccess derzeit aussieht und welche Agents du doch nicht ausschließen willst.

 

[css-umsetzung]

Ja, denn dadurch das die schon geblockt werden bevor überhaupt eine Session geschrieben oder ein Zugriff auf die Datenbank durchgeführt wird, ist es nur ein Apachenkind was sich um den kümmern muss.

Die Beste Lösung ist natürlich Fail2Ban und diese dann sofern noch nicht enthalten mit einzutragen, aber das hat eben nicht jeder.

 

[lj-shadow]

Damit ist auch dann die .htaccess im jtl Shop Root Verzeichnis gemeint vermute ich ?

Korrekt...
in dem root-verzeichnis des Shops.

Das sollte dann etwa so aussehen:

<FilesMatch "(.*)"> 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 </FilesMatch>

Ob das so klug ist so komplexe IP Bereiche zu blocken?
52.59 ist z.B. ein Bereich in Deutschland wenn ich das auf die schnelle richtig gesehen habe, mit Diensten von Amazon

Amazon hat eigentlich nichts in Fremdshops zu suchen, es sei denn, man ist so blöd und nimmt Dienste von dem Verein in Anspruch.
Aber abgesehen von "Amazon Payment" fällt mir nichts ein, was Amazon da zu suchen hätte.
Amazon Pay geht aber eigentlich - soweit ich weiß - nur auf nen IPN-Link im Admin-Plugin..

 

[blitz]

Ja, denn dadurch das die schon geblockt werden bevor überhaupt eine Session geschrieben oder ein Zugriff auf die Datenbank durchgeführt wird, ist es nur ein Apachenkind was sich um den kümmern muss.

Die Beste Lösung ist natürlich Fail2Ban und diese dann sofern noch nicht enthalten mit einzutragen, aber das hat eben nicht jeder.

Fail2Ban is leider nicht. Positionierung is egal ?

 

[css-umsetzung]

Zwei andere der Blöcke kommen aus Amerika (hab nur drei IP Bereiche in Tante Google eingegeben es also nicht näher geprüft) .
Mir ist das ja Wurscht, ich finde es für mich nur krass bereits die ersten beiden Blöcke zu sperren wenn es andere Möglichkeiten gibt.

 

[lj-shadow]

Positionierung is egal ?

Ich glaube ja, aber ich mach's fast ganz oben (in dem Glauben, dass hier die weitere Verarbeitung bereits abgebrochen wird und der Rest dem Apachen dann schon schnuppe ist.)

 

[blitz]

Ich glaube ja, aber ich mach's fast ganz oben (in dem Glauben, dass hier die weitere Verarbeitung bereits abgebrochen wird und der Rest dem Apachen dann schon schnuppe ist.)

Also : Shoproot/includes/config.JTL-Shop.ini.php Dann unter <?php und vor den Datenbankzugangsdaten sozusagen

 

[css-umsetzung]

@lj-shadow spricht von der .htaccess Lösung
https://forum.jtl-software.de/threa...isits-bei-jtl-shops.125549/page-3#post-686427

 

[blitz]

@lj-shadow spricht von der .htaccess Lösung
https://forum.jtl-software.de/threa...isits-bei-jtl-shops.125549/page-3#post-686427

Die hab ich schon drin die funzt zwar aber es kommen immer noch welche durch ich würd das aber gern bevor irgend eine Leistung verbraucht wird oder was passiert einbauen.

 

[akBenutzer]

Also : Shoproot/includes/config.JTL-Shop.ini.php Dann unter <?php und vor den Datenbankzugangsdaten sozusagen

Shoproot/.htaccess
Das ist die richtige Datei, nicht in der config.JTL- Shop.ini.php

Update: Wir haben durch diese Lösung auch keine Leistungseinbußen.

 

[blitz]

Shoproot/.htaccess
Das ist die richtige Datei, nicht in der config.JTL- Shop.ini.php

Update: Wir haben durch diese Lösung auch keine Leistungseinbußen.

Die Variante hab ich schon eingebaut ich würde halt gerne sehen können welche bots das noch sind daher das mit der config Das Problem ist nämlich das mit dieser lösung
immer noch massig an Sessionfiles bei uns kommen.

 

[lj-shadow]

... ich würd das aber gern bevor irgend eine Leistung verbraucht wird oder was passiert einbauen.

Da wärst Du bei Fail2Ban.
Da wird nur EIN MAL Leistung verbraucht - zumindest nur 1x für die Dauer der Sperre.
Anders bekommst Du das nicht hin, außer in der htaccess die (leider wechselnden) IPs dauerhaft zu sperren und ggf. immer wieder mal zu checken

 

[blitz]

Ok ich habe nun mal die Codeschnipsel für die Config Datei von css Umsetzung mit der für die .htaccess Datei abgeglichen und die bots die fehlten zugefügt mal sehen ob es nun besser ist ich würde aber trotzdem gerne sehen können ob noch andere Bots wüten.

Nachtrag: Ok es sind immernoch Sessionfiles mit 3,8 mb etc. zu finden die in Sekunden kein User erzeugen würde

 

[lj-shadow]

Wenn du die bereits "erwischten" Bots in der htaccess schon drin hast UND den Codeschnipsel für die Log-Erstellung von CSS-Umsetzung in der Config, dann kannst du doch super das erstellte Log nutzen, um zu sehen was da noch auftaucht.

Ich würde den Schnipsel aber minimal ändern in diesen:

    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);
}

(Man beachte die Pipe...)
Dann kannst Du die Datei wie 'ne CSV mit Spaltentrenner Pipe in Office öffnen und nach User-Agent sortieren. Dann findest Du die ggf. einfacher.
Und alles, was dann noch an "Bösen Bots" drin zu finden ist, nimmst Du in die htaccess mit auf.

EDIT:
Alle Bots, die in der htaccess bereits geblockt werden, tauchen in diesem Log anschließend nicht mehr auf, da das der Shop schon gar nicht mehr mitbekommt

 

[blitz]

Wenn du die bereits "erwischten" Bots in der htaccess schon drin hast UND den Codeschnipsel für die Log-Erstellung von CSS-Umsetzung in der Config, dann kannst du doch super das erstellte Log nutzen, um zu sehen was da noch auftaucht.

Ich würde den Schnipsel aber minimal ändern in diesen:

    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);
}

(Man beachte die Pipe...)
Dann kannst Du die Datei wie 'ne CSV mit Spaltentrenner Pipe in Office öffnen und nach User-Agent sortieren. Dann findest Du die ggf. einfacher.
Und alles, was dann noch an "Bösen Bots" drin zu finden ist, nimmst Du in die htaccess mit auf.

EDIT:
Alle Bots, die in der htaccess bereits geblockt werden, tauchen in diesem Log anschließend nicht mehr auf, da das der Shop schon gar nicht mehr mitbekommt

So in etwa hatte ich das auch vor nur wusste ich nicht ob es die config.JTL-Shop.ini.php im Ordner includes ist und wo genau es hin sollte ich hätte es nun zwisschen <?php und die Datenbankdaten darin gepackt

 

[blitz]

Hab es funktioniert einwandfrei danke