JTL-Shop Abgleiche geht nicht mehr

[vishes]

Im Hauptordner.
So ungefähr. Und ohne Gewähr. Und die richtige IP-Adresse verwenden. Und für Apache.

<IfModule mod_setenvif.c>
    SetEnvIfNoCase Remote_Addr "^192\.168\.100\.100$" MODSEC_ENABLE=Off
</IfModule>

# Ensure ModSecurity respects the MODSEC_ENABLE variable
<IfModule mod_security.c>
    SecRuleEngine On
    SecRule REMOTE_ADDR "@rx ^192\.168\.100\.100$" "phase:1,nolog,allow,ctl:ruleEngine=Off"
</IfModule>

Danke. Aber bei uns bringt das leider nichts.

 

[mvh]

Danke. Aber bei uns bringt das leider nichts.

S. Beitrag im Thema "JTL-Wawi 2.0.6.0 sendet fehlerhafte multipart/form-data-Requests – ModSecurity blockt Datenabgleich mit 403 (scheinbar hosterabhängig)" https://forum.jtl-software.de/threa...scheinbar-hosterabhaengig.248836/post-1363369

 

[Ironyeti]

Im Hauptordner.
So ungefähr. Und ohne Gewähr. Und die richtige IP-Adresse verwenden. Und für Apache.

<IfModule mod_setenvif.c>
    SetEnvIfNoCase Remote_Addr "^192\.168\.100\.100$" MODSEC_ENABLE=Off
</IfModule>

# Ensure ModSecurity respects the MODSEC_ENABLE variable
<IfModule mod_security.c>
    SecRuleEngine On
    SecRule REMOTE_ADDR "@rx ^192\.168\.100\.100$" "phase:1,nolog,allow,ctl:ruleEngine=Off"
</IfModule>

Vielen Dank für die Mühe. Hat aber leider nicht funktioniert. Da muss ich wohl warten, bis Hosteurope aus dem Knick kommt.

 

[mvh]

Vielen Dank für die Mühe. Hat aber leider nicht funktioniert. Da muss ich wohl warten, bis Hosteurope aus dem Knick kommt.

Beitrag im Thema "JTL-Wawi 2.0.6.0 sendet fehlerhafte multipart/form-data-Requests – ModSecurity blockt Datenabgleich mit 403 (scheinbar hosterabhängig)" https://forum.jtl-software.de/threa...scheinbar-hosterabhaengig.248836/post-1363387

 

[vishes]

Wir haben jetzt folgende Nachricht von unserem Hoster bekommen:

Guten Tag,

gerne möchten wir Ihnen eine Update zum Sachverhalt bezüglich der JTL-Wawi Synchronisation geben.

Die zuständige Fachabteilung hat den Sachverhalt gemeinsam mit unserem Security-Team geprüft, und die betreffende Regel wird exakter auf den Grund warum sie Anfang der Woche aktiviert wurde angepasst. Dadurch wird die Regel nicht mehr auf die Wawi Requests angewendet. Diese Änderung befindet sich derzeit in der Prüfung.

Die korrigierte Regel wird anschließend auf alle Server ausgerollt. Wir rechnen frühestens ab späten Vormittag/Mittag mit der Verteilung, je nach Prüfungsverlauf kann sich dies auch etwas nach hinten verschieben. Da es sich um eine plattformweite Korrektur handelt, ist von Ihrer Seite keine weitere Aktion und keine Änderung an Ihrer Wawi oder am Shop erforderlich.

Wir informieren Sie erneut, sobald die Änderung vollständig verteilt ist.

 

[css-umsetzung]

Dann sparst du dir den Serverwechsel ja vorerst .

 

[mvh]

Dann sparst du dir den Serverwechsel ja vorerst .

..,bis der Hoster noch etwas einbaut.

 

[css-umsetzung]

..,bis der Hoster noch etwas einbaut.

Ja

Ich hatte mit ihm ja direkten Kontakt, ein Serverwechsel ist theoretisch geplant aber dann eben nicht innerhalb von einem Tag, so kann man das in Ruhe angehen.

Mich würde interessieren, was bei euren Tests (anderer Beitrag, gleiches Thema), die Ihr bezüglich der 2er Version vorhabt (abgesetzter WAWI Request) rauskommt.

 

[mvh]

Ja

Ich hatte mit ihm ja direkten Kontakt, ein Serverwechsel ist theoretisch geplant aber dann eben nicht innerhalb von einem Tag, so kann man das in Ruhe angehen.

Mich würde interessieren, was bei euren Tests (anderer Beitrag, gleiches Thema), die Ihr bezüglich der 2er Version vorhabt (abgesetzter WAWI Request) rauskommt.

NoOne hat festgestellt, ModSecurity steigt mit MULTIPART_BOUNDARY_QUOTED Fehler aus (BQ 1),
d.h. boundary="<BoundaryCode>" ist nicht erlaubt.
Der Trigger ist vermutlich: BQ %{MULTIPART_BOUNDARY_QUOTED}
Ich habe festgestellt - es wird der .NET Core 8 HttpClient verwendet, der hat immer boundary="<BoundaryCode>", und das ist auch kein Fehler von MS laut RFC

 

[vishes]

Dann sparst du dir den Serverwechsel ja vorerst .

Ja dank dir trotzdem schon mal. Aber Serverwechsel ist auch aus anderen Gründen demnächst angebracht.

Aktuell geht es aber immer noch nicht ...

 

[Ironyeti]

Ja dank dir trotzdem schon mal. Aber Serverwechsel ist auch aus anderen Gründen demnächst angebracht.

Aktuell geht es aber immer noch nicht ...

Hat sich bei dir schon etwas getan? Bei mir hat Hosteurope noch keine Lösung gefunden.
Was machst du in der Zwischenzeit mit deinen Bestellungen?

 

[vishes]

Hat sich bei dir schon etwas getan? Bei mir hat Hosteurope noch keine Lösung gefunden.
Was machst du in der Zwischenzeit mit deinen Bestellungen?

Es geht leider immer noch nicht. Wir wurden gestern Abend wieder vertröstet.

In der Zwischenzeit importieren wir die Bestellungen manuell über die Ameise: aus den Bestellbestätigungs-Mails ziehen wir per kleinem Skript die Adress-/Bestelldaten in eine CSV und legen damit in der Wawi Aufträge an, um zumindest Versandlabels erzeugen zu können.

 

[css-umsetzung]

Meine Meinung:
Dann doch lieber umziehen, das ist ja kein Zustand, das man da jetzt bald eine Woche keine Bestellungen abholen kann.
Wenn dann müsste die Entscheidung schnell fallen, heute ist Freitag, am WE wird nichts passieren.

DF ist für mich eh ungeeignet für ein JTL Hosting.

 

[Ironyeti]

Meine Meinung:
Dann doch lieber umziehen, das ist ja kein Zustand, das man da jetzt bald eine Woche keine Bestellungen abholen kann.
Wenn dann müsste die Entscheidung schnell fallen, heute ist Freitag, am WE wird nichts passieren.

DF ist für mich eh ungeeignet für ein JTL Hosting.

Ist Hosting bei JTL eine gute Lösung? Und wie schnell funktioniert so ein Umzug(vor allem wegen dem Umzug der Domain)?

 

[css-umsetzung]

Auch wenn ich JTL Servicepartner bin,
ein JTL Hosting war noch nie meine erste Wahl.

Man sollte das auch ein wenig davon abhängig machen, wie der Shop läuft (Besucheranzahl, Bestellungen usw.) und welche Ansprüche man hat.
Ich würde einen Shop, der nicht nur eine Bestellung am Tag hat immer auf einen eigenen Server legen, ob VServer oder dedicated ist dabei auch wieder von den Zugriffen abhängig.

REDIS ist die Grundvoraussetzung bei der Anbieterwahl.

 

[Ironyeti]

Der Shop liegt ja auch jetzt auf einem VServer. Bisher war ich auch zufrieden mit Hosteurope.
Mein Gedanke war nun, dass JTL (hoffentlich) weiß, was auf Ihrem Server im Zusammenspiel mit der Shopsoftware zu tun ist.
Was spricht gegen JTL-Hosting?

 

[css-umsetzung]

hast du bei Hosteurope Redis?
Vermutlich nicht, das bedeutet das du mit dem Dateicache arbeitest, was über kurz oder lang Probleme verursacht, weil es zu viele Dateien werden, die am Ende nicht mehr sauber gelöscht werden können.

 

[vishes]

Meine Meinung:
Dann doch lieber umziehen, das ist ja kein Zustand, das man da jetzt bald eine Woche keine Bestellungen abholen kann.
Wenn dann müsste die Entscheidung schnell fallen, heute ist Freitag, am WE wird nichts passieren.

DF ist für mich eh ungeeignet für ein JTL Hosting.

Hallo, jetzt geht es wieder. Ein Umzug steht trotzdem auf der Agenda.

 

[Ironyeti]

Hallo, jetzt geht es wieder. Ein Umzug steht trotzdem auf der Agenda.

Weißt du, woran es gelegen hat? Vielleicht kann ich Hosteurope einen Tipp geben.

 

[vishes]

Weißt du, woran es gelegen hat? Vielleicht kann ich Hosteurope einen Tipp geben.

Bei uns lag's an einer zentralen WAF-/ModSecurity-Regel, die der Hoster Anfang der Woche aktiviert hatte. Die hat die POST-Requests der Wawi auf /dbeS/ fälschlich als Angriff gewertet und mit HTTP 403 geblockt (False Positive). An unserer Wawi/am Shop selbst war nichts falsch.

Gelöst wurde es serverseitig vom Hoster: Er hat die Regel angepasst, sodass sie nicht mehr auf die Wawi-Requests greift - plattformweit ausgerollt, ohne Änderung auf unserer Seite.

Tipp für HostEurope: Lass den Support gezielt im ModSecurity-Audit-Log nach der Regel suchen, die bei POST /dbeS/mytest.php den 403 auslöst, und die Rule-ID nennen. Dann kann das Security-Team die Regel korrigieren bzw. /dbeS/ davon ausnehmen. Wichtig zu betonen: Es ist eine zentrale Regel (kein kundenspezifisches Problem) - HostEurope und Domainfactory gehören ja zur selben Gruppe.