Kurzer Hinweis für Leute, die Webseiten unter Plesk hosten. Die in Plesk gehostete Websites sind nach einem kürzlichen Apache-Update nicht mehr zugänglich. Es wird ein Fehler "421 Misdirected Request" angezeigt. Ursache ist ein Patch verschiedener Sicherheitslücken in der letzten Apache-Version. Danach können Anfragen von nginx ohne den Servernamen nicht mehr verarbeitet werden (das ist Standard bei nginx, wenn eine Verbindung mit einem Proxy-HTTPS-Server hergestellt wird).
Admin-Passwörter schützen mit Windows LAPS. eBook jetzt herunterladen » (Anzeige)
Der gesamte Sachverhalt ist auf der plesk-Supportseite im Artikel Websites hosted in Plesk are not accessible after a recent Apache update: 421 Misdirected Request kurz beschrieben, nachdem es erste Problemberichte von Anwendern gab (danke an den Leser für den Hinweis).
Die Lösung besteht darin, die Direktiven proxy_ssl_server_name und proxy_ssl_name in die nginx-Konfiguration einzufügen, damit nginx den Servernamen über die TLS Server Name Indication (SNI) Erweiterung an den Apache weitergibt. Die Details sind dem Supportbeitrag zu entnehmen.
MVP: 2013 – 2016
Da sind wir gestern auch drüber gestolpert, das Update wurde in unserem Hosting Paket vom Anbieter automatisch installiert, daher wurde das nicht sofort bemerkt.
Die Lösung in dem Supportbeitrag funktionierte dann zum Glück sofort, es muss auch nichts neu gestartet werden.
Das Problem tauchte hier am 17.07. gegen 06:30 Uhr auf.
Wie auch im Support Beitrag zu finden ist es schon sehr interessant, dass der Fehler auch ohne aktives Updaten auftrat…
Über Google war zu der zeit gestern übrigens noch nix bei Plesk zu finden. Ein Fix lies sich jedoch zum Glück bei hestiacp finden (forum.hestiacp.com/t/nginx-apache-ssl-421-misdirected-request/19502/2)
In den Kommentaren dort steht u.a. dazu:
Schon klar, aber wenn du weiter lesen würdest siehst auch du, dass die Auto Updates in der Regel ausgeschaltet sind.
Bei Dir ist der Fehler ohne aktives Updaten und mit den genannten Settings abgeschaltet aufgetreten?
Bei mir nicht, aber es gibt Fälle wo das offenbar so war. Darum die berechtigte Aufregung an diversen Stellen.
Ändert aber auch nichts daran, dass das nicht passieren darf bei vorhandenem QC. Schließlich waren/sind alle plesk Nutzer die nginx als Proxy Nutzen (Default) betroffen und das Update hätte nur in Verbindung MIT dem/einem Fix ausgerollt werden dürfen.
Kann mich jemand erleuchten?
es geht um den Apache Webserver und davor wird bei plesk ein nginx geschaltet und diese Konfiguration macht jetzt Probleme. Warum benutzt man das in der Kombination?
relativ einfach – fyi:
plesk.com/wiki/nginx/
kreativmedia.ch/de/nginx-reverseproxy
Plex betreibt einen internet facing apache (frontend). Dieser wiederum fungiert als reverse proxy für dynamische Inhalte aus einem Container (docker) von einem Kunden. Die Container sind nicht direkt über das Internet errichbar.
Im Container erzeugt eine App die dynamischen Inhalte und spielt diese über nginx aus (backend server). Wäre der Container direkt aus dem Internet ereichbar wäre dieser der frontend server. Daher muss der Kunde innerhalb des Docker Containers auch seine Config anpassen, damit der frontend server (apache) den traffic korrekt an das Backend (nginx) durreicht. Das hängt mit https Zertifikaten zusammen. Die Apps im Container prüfen wie bei einer traceroute die einzelnen Ettappen der https requestes. So werden zb MDM Attacken gefiltert.
insgesamt macht man das ganze weil es maximal flexibel ist, ein zentrales logging und security (waf) bietet und dabei auch noch unendlich skalierbar ist.
das ganze ist heutzutage standard. zb setzt so cloudflare seine http security filter durch. oder microsoft mit azure frontdoor
Ist wirklich sehr bedenklich, dass offenbar, trotz deaktivierter automatischer Installation von Updates, ein oder mehrere Updates kommentarlos auf unseren Plesk-Systemen installiert wurden.
Hersteller sichern XY zu und scheinbar stimmt es wie in diesem Fall nicht.
Könnte das der Grund sein, siehe Kommentar auf der Support Seite?
Wie geschrieben, sind sämtliche Updateinstallationen in Plesk deaktiviert.
Aber offenbar bedeutet "deaktiviert" nicht auch tatsächlich deaktiviert.
Ich hatte vor mir das mal anzusehen, aber leider sind die PHP Files für die Cronjobs von Plesk verschlüsselt. Ich frage mich auch wie sowas passieren kann, wir haben hunderte Euro Werbebudget pro Tag und rund 1/3 davon ist durch dieses Fiasko am besagten Tag für nichts und Imageschaden verbrannt.
Hm, interessant. Man gut, dass ich bei unserem Plesk VPS den nginx reverse-proxy deaktiviert hab. Macht auch bei simplen Low-Traffic Seiten eh keinen Unterschied.