Neu Sessiondateien zu 1000en

MatthiasW

Gut bekanntes Mitglied
5. Oktober 2008
239
8
Badenweiler
Guten Abend,

heute Morgen musste ich meinen Hoster informieren, dass mein Shop nicht erreichbar war. Er stellte daraufhin fest, dass der gesamte für den Shop reservierte Speicherbereich auf unterster Ebene in root/.system/sessions mit sessiondateien zugepflastert war. Es handelte sich dabei um 1000de Dateien im Größenbereich von meistens ca 400 KB.
Diese müssen über Nacht vom 15. auf den 16.2. dort geschaffen worden sein. Eine Datei ist beigefügt.

Im Backend konnte ich feststellen, dass in den Logfiles 39 Fehleranzeigen allesamt vom 15.2.17, 23:47:48 angezeigt werden. In allen diesen `Fehleranzeigen kommen Begriffe zu Maßeinheiten zu Länge, Gewicht un Flüssigkeiten vor, die in meinem Shop nicht verwendet werden.
Diese Begriffe konnte ich in den Suchanfragen nicht finden.

Ein Blick in das Dashboard zeigte mir für den Februar 0 ( Null) Besucher an, was die mir täglich zugesandte Infomail bestätigte:
Tägliche Status-Email
Neukunde: 2
Besucher: 0
Besucher von Suchmaschinen: 0
Versendete Wunschlisten: 0

Mir stellen sich die Fragen:
A) konnte dieser Angriff einen Schaden verursachen
B) konnte er die Besucherstatistik löschen, was dann ja ein erfolgter Zugriff gewesen wäre
C) Besteht die Gefahr dass die shopdatenbank beschägt ist.

Auf Grund von C) habe ich keinen Shopabgleich mehr vorgenommen. Die letzte Bestellung gab es um 1:30 und laut Logfiles war der Shop vermutlich nicht mehr erreichbar ab 4:12:25 auf Grund der Meldung "CSRF-Warnung fuer Login: 1" ( siehe PDF )
Auf Grund dieser Merkwürdigkeiten habe ich den Shop auf Wartung gesetzt.

Mir scheint das nach einem Hack auszusehen, zumindest einem massiven Versuch.

Gruss Matthias

Auszug aus der Session Datei:
"
kSprachISO|i:2;FremdParameter|a:0:{}Warenkorb|O:9:"Warenkorb":6:{s:10:"kWarenkorb";N;s:6:"kKunde";N;s:14:"kLieferadresse";N;s:13:"kZahlungsInfo";i:0;s:13:"PositionenArr";a:0:{}s:18:"cEstimatedDelivery";s:0:"";}Globals_TS|s:19:"2017-02-15 09:50:31";oKategorie_arr|a:0:{}kKategorieVonUnterkategorien_arr|a:0:{}ks|a:0:{}Waehrungen|a:1:{i:0;O:8:"stdClass":9:{s:9:"kWaehrung";s:1:"1";s:4:"cISO";s:3:"EUR";s:5:"cName";s:3:"EUR";s:9:"cNameHTML";s:6:"€";s:7:"fFaktor";s:1:"1";s:9:"cStandard";s:1:"Y";s:10:"cVorBetrag";s:1:"N";s:17:"cTrennzeichenCent";s:1:",";s:20:"cTrennzeichenTausend";s:1:".";}}Sprachen|a:2:{i:0;O:8:"stdClass":8:{s:8:"kSprache";s:1:"1";s:13:"cNameEnglisch";s:6:"German";s:12:"cNameDeutsch";s:7:"Deutsch";s:9:"cStandard";s:1:"Y";s:4:"cISO";s:3:"ger";s:13:"cShopStandard";s:1:"Y";s:7:"cISO639";s:2:"de";s:4:"cURL";s:32:"https://music-strings.de/Nylon_2";}i:1;O:8:"stdClass":8 ..."
so gehts dann 99 Seiten weiter
 

Anhänge

  • 2016-02-06 - JTL Shop Administration 1.pdf
    47,4 KB · Aufrufe: 16

elevennerds.de

Sehr aktives Mitglied
23. September 2015
1.219
203
Hallo,

" "CSRF-Warnung fuer Login: 1" "

hier hat vermutlich jemand ein Skript auf den Shop-Login losgelassen, JTL-Shop ist relativ sicher, solange es keine Anhaltspunkte dafür gibt, dass am Shop was verändert ist, würde ich nicht davon ausgehen, dass der Angriff Erfolg hatte.

Mit den Session-Daten ist ärgerlich. Du kannst alle Session-Dateien, die älter als 1 Stunde sind, einfach löschen lassen.

Schon blöd, wenn jemand aus der Ferne Deinen Shop chanceln kann. Du brauchst entweder mehr Speicherplatz, oder eine Redis-DB im Backend, die auch als Session-Speicher konfiguriert werden kann.

MfG

Rene
 

MatthiasW

Gut bekanntes Mitglied
5. Oktober 2008
239
8
Badenweiler
Hallo Rene,

vielen Dank für Dein schnelles und ausführliches Feedback.

Nein, mein Shop ist ganz ursprünglich, nur an Templates habe ich etwas verändert.

Es ist sogar so dass der Login nicht auf dem Standardpfad liegt.

Bringt da die 2-Faktor-Authentifizierung im Backend vom Shop 4.05 mehr Sicherheit? Wollte mit der Installation warten bis die ersten Patches raus sind.

Was mich einfach bedenklich stimmt, ist dass die login-Statistik komplett auf Null gesetzt ist. Siehe Bild. Ich hatte Besucher und Verkäufe im Feb. Wie kann das auf Null kommen? Die Gesamtbesucherzahl ist davon nicht betroffen.

Gruß Matthias
 

Anhänge

  • 2017-02 - statistics.jpg
    2017-02 - statistics.jpg
    41 KB · Aufrufe: 63

MatthiasW

Gut bekanntes Mitglied
5. Oktober 2008
239
8
Badenweiler

david

Administrator
Mitarbeiter
16. Juli 2010
2.310
170
Prüf mal in der Shopdatenbank, ob Tabellen als crashed markiert sind (tbesucherarchiv). Die müssten dann repariert werden. PHPMyAdmin bietet dafür entsprechende Optionen an.
 

MatthiasW

Gut bekanntes Mitglied
5. Oktober 2008
239
8
Badenweiler
Zitat von david:
Prüf mal in der Shopdatenbank, ob Tabellen als crashed markiert sind (tbesucherarchiv). Die müssten dann repariert werden. PHPMyAdmin bietet dafür entsprechende Optionen an.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Vielen Dank. Ja in der Tat, genau diese Tabelle ist beschädigt.

Kann sowas durch einen Angriff geschehen?
Mein Shop ist jetzt auf Wartung gesetzt. dann leert er sich auch wieder. Wenn er an ist dann läuft umgehend der reservierte Platenplatz von 10 GB! voll
Da ist doch ziemlich was schräges dran, oder? Und ziemlich gigantischer Platzverbrauch. Wie können nur solch riesige sessiondateien entstehen von über 400 Kb.
Eigentlich braucht er ca. 500MB Plattenplatz mit allem drum unddran ( Bilder ... ) Das hatte sich im Oktober beim Serverumzug gezeigt.

GM
 

MatthiasW

Gut bekanntes Mitglied
5. Oktober 2008
239
8
Badenweiler
Hallo,

noch ein kleiner Nahtrag zu meinem vorigen Beitrag:
kurz nach diesem konnte mein Hoster die DB reparieren, diezuvor fehlenden Informationen zur Besucherstatistik sind nun wieder sichtbar.

Bleibt die Frage, wie konnte es zu diesem DB Fehler kommen? Einbruch gelungen?

Gruß Matthias
 

MatthiasW

Gut bekanntes Mitglied
5. Oktober 2008
239
8
Badenweiler
Gut, das ist beruhigend. Was jedoch bleibt ist die große Anzahl der mit um die 400 Kb riesigen Sessiondateien. Das muss gelöst werden, denn sonst läuft der für den Shop reservierte Platz gleich wieder voll.
es tauchen da auch noch gezippte Dateien auf, das wird bei den Log-Dateien auch protokolliert.
z.B. incoming: data.zip size:169 & Entpacke: tmp/php6HZvf1
Was sind das für Dateien und um welche Vorgängehandelt es sich da?

Zusammen mit dem Hoster haben wir die Historie und den Hintergrund nochmals gecheckt und es besteht folgende Situation:
  • ca. 10.000 Artikel, nicht alle haben Bilder
  • 10GB Speicherplatz, ein Umfang mit dem JTL ja auch arbeitet
  • Version 4 seit April 2016
  • April 2016 Installation Telecash Plugin von Modulexpert
  • Update auf 4.04 Mitte Oktober 2016
  • im Rückblick lässt sich sagen dass es vor diesem Update diese Probleme nicht gab
  • aktivierte Plugins
    • Telecash v. Mudulexpert
    • Paypal von JTL
    • 1 x Widget PI von JTL
  • Der Shop ist ganz ursprünglich, keine Veränderungen - lediglich kleine Ergänzungen an .tpl Dateien des Evo wurden gemacht.
Ich sehe da die Situation dass im Shop selbst wohl das Problem liegen muss.

Gruß Matthias
 

fav-hosting.online

Sehr aktives Mitglied
16. Oktober 2012
780
60
Weiterstadt
Firma
FaV-Hosting
Hallo,

die data.zip und das entpacken sind normal. Beim Webshopabgleich werden die Daten als ZIP gesendet und dann auf dem Server entpackt, verarbeitet und danach gelöscht.
Was die Sessiondateien angeht würde ich dir unten stehende Einstellungen empfehlen. Wir hatten bei PHP7 das Problem das bei der Standardeinstellung alte Sessiondateien nicht automatisch gelöscht wurden.
Der Googlebot z.B. wird auch bei jedem Crawling der einzelnen Seiten eine neue Session erzeugen und damit auch eine neue Sessiondatei.
Wir hatten vor der Optimierung der Config 45 GB an Sessiondateien, jetzt sind es noch 100 MB im Durchschnitt.

Code: 
session.gc_maxlifetime = 3600
session.gc_probability = 1
session.gc_divisor = 100

Eine gute Erklärung was diese Werte bewirken kann hier nachgelesen werden.
 

MatthiasW

Gut bekanntes Mitglied
5. Oktober 2008
239
8
Badenweiler
sorry da hatte ich was falsches bestätigt. Meine Einstellungen sind:

session.gc_maxlifetime = 1440
session.gc_probability = 1
session.gc_divisor = 1000

auch o.k.?
 

marryanne

Aktives Mitglied
10. Dezember 2014
73
4
Hallo, entschuldigt bitte meine Unwissenheit, aber kann mir jemand sagen wo genau ich diese Werte

session.gc_maxlifetime = 1440
session.gc_probability = 1
session.gc_divisor = 1000

eintragen muß?
Vielen Dank ;)
 

css-umsetzung

Offizieller Servicepartner
SPBanner
6. Juli 2011
7.340
2.001
Berlin
Die php.ini wird in der Regel vom Serverbetreiber konfiguriert.

in den seltensten Fällen dürfen normale Domainbetreiber hier eingreifen und wenn dann nur bedingt.
 

Jens Falk

Offizieller Servicepartner
SPBanner
14. Mai 2020
285
109
Zitat von css-umsetzung:
Die php.ini wird in der Regel vom Serverbetreiber konfiguriert.

in den seltensten Fällen dürfen normale Domainbetreiber hier eingreifen und wenn dann nur bedingt.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.


Das kommt auf den Hoster an.

Sehr viele (eigentlich alle, oder?) ermöglichen eigene php.ini nach folgendem Schema:

Liegt im Verz. /domain.com eine php.ini und ruft die domain dieses Verzeichnis auf, so gilt nicht die php.ini des Servers, sondern die die im Verzeichnis liegt.

liegt eine weitere im Verzeichnis /domian.com/ shop, so gilt die php.ini im /domian.com/shop für den shop, liegt dort keine, gilt die php.php im Verz /domain.com. usw.
 
Du musst Dich einloggen oder registrieren um hier antworten zu können.
Top Bottom