[3.3](ERLEDIGT) Moderations Probleme nach update (Forbidden You don't have permission to access this resource) Strato

[Eisrose]

Jut, das Thema ModSecurity (meine Vermutung) ist somit eher vom Tisch, hab die Infobox im Startbeitrag und den Titel angepasst.

Jetzt, wo der Fehler von Strato korrigiert wurde und ich diesen Thread gelesen habe, bin ich am überlegen, ob es nicht doch das ModSecurity gewesen sein könnte.

Ich bin ja auch eigentlich als erstes auf das ModSecurity gestossen, hatte das aber verworfen, da man dessen Installation mittels phpinfo() hätte sehen müssen, aber da fand ich nichts. Jetzt kann es sein, dass ich da falsch lag und man das mit phpinfo() gar nicht sehen kann oder zumindest Strato die Installation des Moduls unsichtbar vorgenommen hat. Das wäre dann auch eine Frage, ob da jemand was zu sagen kann.

Zumal ich vermuten würde, dass Strato die Standardeinstellungen des Apachen nicht so einfach wieder ändert, wenn dadurch eine Sicherheitslücke geschlossen wird. Das spricht auch eher gegen das Setzen des UnsafeAllow3F-Flags. Änderungen in einem problematischen Modul vorzunehmen oder das wieder ganz zu deinstallieren, geht da vielleicht etwas einfacher von der Hand. Dass das Problem auf dem ModSecurity beruhte, würde ich jedenfalls im Nachhinein doch nicht mehr ausschliessen. Aber es kann natürlich auch sein, dass das einfach ein Installationsfehler beim Apachen war.

Mir ist es leider nicht gelungen, das Problem reproduzieren zu können. Also entweder da muss noch eine andere Bedingung erfüllt sein, oder aber man hat bei 2.4.61 das Ganze schon wieder geändert, weshalb ich das gar nicht nachvollziehen kann. Und die 2.4.60 ist bei Wampserver auch gar nicht (mehr) erhältlich, so kann man das auch nicht mehr gezielt testen.

Wenn das nicht reproduzierbar ist, legt das auch einen Apache-Installationsfehler bei Strato nahe oder eben doch das ModSecurity. Dann machen die default settings des Apachen keine Probleme und das Setzen des UnsafeAllow3F-Flags ist gar nicht notwendig und würde nicht das Verschwinden des Fehlers bewirken.

Was Strato da gemacht hat, weiß ich nicht.

Ja, wäre schön wenn man erfahren würde, was genau das Problem ist/war.

Das wäre natürlich wirklich gut. Aber ich befürchte, da erfahren wir nix.

[Eisrose]

Der Vollständigkeit halber: es scheint ein Fehler im Apache selber gewesen zu sein.

https://bz.apache.org/bugzilla/show_bug.cgi?id=69197

[LukeWCS]

Fast zeitgleich mit dem Absenden meines obigen Beitrags funktioniert es jetzt auch bei uns wieder.

Dann warst du einfach noch auf einem Server, der noch nicht angepasst wurde. Die Hoster rollen Updates und Änderungen ja normalerweise Block- bzw. Wellenweise auf die einzelnen Server aus.

Ich bin ja auch eigentlich als erstes auf das ModSecurity gestossen

Ja, weil auch in dem Zusammenhang mit ModSecurity dieselbe Fehlermeldung auftauchte. Allerdings ist das eine "Allerwelts-Fehlermeldung" und nichts spezifisches. Aber irgendwo muss man ja mal mit Recherche und Infos sammeln anfangen. Für mich war im Prinzip die Meldung von Bruno bezüglich dem Apache Problem die Wende hier im Thema, denn das hat perfekt auf die beschriebenen Probleme gepasst.

Zumal ich vermuten würde, dass Strato die Standardeinstellungen des Apachen nicht so einfach wieder ändert, wenn dadurch eine Sicherheitslücke geschlossen wird. Das spricht auch eher gegen das Setzen des UnsafeAllow3F-Flags.

Sehe ich genauso.

Der Vollständigkeit halber: es scheint ein Fehler im Apache selber gewesen zu sein.

Interessant. Da dieser Bugtracker Eintrag noch den Status NEW hat, gibt es also noch keinen offiziellen Fix und somit auch keine offizielle Lösung bei den Hostern. Ergo hat Strato am 17.7 entweder auf die Schnelle eine eigene vorläufige Version vom Apachen compiliert mit einem eigenen Workaround, oder aber einen anderen Workaround ausserhalb von Apache gefunden, mit dem das Problem bis zum offiziellen Fix temporär behoben werden kann.

Aber damit verdichten sich die Infos jetzt immer mehr, dass das ein effektives Apache Problem ist. Also hat der Security Fix von 2.4.60 unerwartete Nebenwirkungen, die jetzt so nach und nach auftauchen und behoben werden müssen. Der Bug Tracker Eintrag macht auch klar, dass das Sicherheitsproblem bezüglich %3f eher nicht bei den GET Parametern liegt und somit dürfte phpBB eigentlich aus dem Schneider sein.

[Steve Wuppertal]

Als der Fahler noch vorhanden war, stand im PHPInfo im ACP von phpBB folgendes:

Code: Alles auswählen

$_ENV['SERVER_SOFTWARE']	Apache/2.4.59 (Unix)

Jetzt nachdem das Problem bei Strato gefixt wurde steht da:

Code: Alles auswählen

$_ENV['SERVER_SOFTWARE']	Apache/2.4.61 (Unix)

[LukeWCS]

Steve, das irritiert mich jetzt. Das Problem sollte doch eigentlich erst ab 2.4.60 auftreten?

[Steve Wuppertal]

Ich wollts nur mal reinschreiben, weil sich alle so auf die 2.4.60 eingeschossen hatten
Definitiv war zum Zeitpunkt des Problems die 2.4.59 des Apachen bei Strato aktiv.
Seit dem Wechsel auf die Version 2.4.61 funktioniert alles wieder wie es soll.

Evtl. lag ja da der Fehler...
Eine nicht sauber (vollständig) installierte Version ?

[69bruno]

https://github.com/owasp-modsecurity/Mo ... ssues/2705

Hier wird beschrieben, dass modsecurity auch Fehler produziert bei Codierungen mit einem "?". Kann es vielleicht sein, dass entweder der Mod oder die Apacheversion Auslöser sind ???
(Mir schwant da, dass erst der Mod neugestrickt wurde und das dann in den Apachen übernommen wurde)

[LukeWCS]

Mahlzeit

Ich wollts nur mal reinschreiben, weil sich alle so auf die 2.4.60 eingeschossen hatten

Nun, eben auf Grundlage von Brunos Beitrag und eigener Recherchen. Das Changelog sagt klar aus, dass das Problem frühestens mit 2.4.60 auftreten dürfte/sollte, denn da wurde die offensichtlich problematische Änderung samt dem Flag UnsafeAllow3F hinzugefügt.

Definitiv war zum Zeitpunkt des Problems die 2.4.59 des Apachen bei Strato aktiv.

Ich wollte gestern auch mal schauen, welche Apache Version bei mir im LB läuft, habe aber dann festgestellt, dass mein Hoster sämtliche Methoden zur Ermittlung der Version unterbindet. Vermutlich aus Sicherheitsgründen.

Seit dem Wechsel auf die Version 2.4.61 funktioniert alles wieder wie es soll.

Evtl. lag ja da der Fehler...
Eine nicht sauber (vollständig) installierte Version ?

Wäre auch denkbar. Wenn wir jetzt neu festhalten, dass das Problem bei dir schon bei 2.4.59 auftrat UND im Apache Changelog zu 2.4.61 und 2.4.62 keine einzige Silbe davon zu lesen ist, dass man einen "Fehler" des Security Fixes von 2.4.60 nacharbeiten musste, ist es aktuell eher zweifelhaft, ob die Ursache wirklich beim Apache zu suchen ist. Jedenfalls nicht als alleinige Ursache.

Meine letzte Theorie war, dass man bei Apache 2.4.60 durch den Security Fix eine für ModSecurity problematische Situation geschaffen hat, die auch erst vom ModSecurity Team verstanden und behoben werden musste. Aber dagegen spricht wieder deine Beobachtung mit Apache 2.4.59.

Weder hier noch auf .com gab es in dem Zeitraum seit chri1278 das Thema hier gestartet hatte, ein vermehrtes Aufkommen von Supportanfragen zum "forbidden" Problem. Am "meisten" findet man dazu nur hier etwas, also auf die Deutsch-sprachige Community begrenzt und so wie es aktuell aussieht, sogar auf einen einzigen deutschen Hoster begrenzt. Auf .com findet man im besagten Zeitraum schlicht gar nichts zu dem Thema, nur das Thema dort von Eisrose ist die einzige Ausnahme. Ergo wird das Problem dort allerhöchstens als Fussnote am Rande wahrgenommen und hat sonst keinerlei Relevanz.

Kann es vielleicht sein, dass entweder der Mod oder die Apacheversion Auslöser sind ???
(Mir schwant da, dass erst der Mod neugestrickt wurde und das dann in den Apachen übernommen wurde)

Auch möglich, also dass das eventuell gar keine ODER Frage, sondern eine UND Frage ist. Vielleicht ist erst die Kombination von 2 "ungünstigen" Versionen von Apache und ModSecurity ein Problem (gewesen).

Das ist halt das Problem wenn Hoster nicht klar kommunizieren, was das Problem war. Dann ist man auf eigene Recherchen und "wilde Vermutungen" angewiesen.

[Steve Wuppertal]

Denke auch das es ein auf Strato zu begrenzendes Problem gewesen ist.
Andernfalls hätte es bedeutend mehr Meldungen (weltweit) gegeben.

Was mir zum Zeitpunkt des Problems noch aufgefallen war, unter Wordpress hatten die URLs mit angehängten Variablen (allerdings nur jene, welche den Forbidden Fehler ausgelöst haben) jene Variablenketten in fünffacher Wiederholung angehängt (ob das unter phpBB auch so war, kann ich nicht sagen da ich dort das Problem zu diesem Zeitpunkt noch nicht erkannt hatte).

Bsp.:
Normal wäre es so:

Code: Alles auswählen

https://www.phpbb.de/community/posting.php?mode=reply&t=247300

Zum Zeitpunkt des Problems:

Code: Alles auswählen

https://www.phpbb.de/community/posting.php?mode=reply&t=247300?mode=reply&t=247300?mode=reply&t=247300?mode=reply&t=247300?mode=reply&t=247300?mode=reply&t=247300

[LukeWCS]

Titel und Startbeitrag mal aktualisiert, da das Problem inzwischen behoben wurde.

Was mir zum Zeitpunkt des Problems noch aufgefallen war, unter Wordpress hatten die URLs mit angehängten Variablen (allerdings nur jene, welche den Forbidden Fehler ausgelöst haben) jene Variablenketten in fünffacher Wiederholung angehängt

Das heisst, es wurde ein bestimmter GET Parameter redundant generiert, oder waren es tatsächlich verschiedene Parameter?

(ob das unter phpBB auch so war, kann ich nicht sagen da ich dort das Problem zu diesem Zeitpunkt noch nicht erkannt hatte).

Ich habe speziell das Problem untersucht, das chris1278 gemeldet hatte. Und in dem Fall wurden die URLs von phpBB laut meinem TB mit mehrfachen GET Parametern generiert, bei dem in der gesamten URL nur ein einziges als %3f codiertes Fragezeichen vorkam. Das Problem muss also beim ersten codierten Fragezeichen auftreten und alle weitere Vorkommen davon dürften dann irrelevant sein.