OPNsense Forum
International Forums => German - Deutsch => Topic started by: Wuschy on November 20, 2021, 10:03:00 pm
-
Hallo Zusammen,
Vielleicht kann mir hier jemand helfen, da ich einfach nicht mehr weiterkomme:
Ich habe die OPNsense FW schon eine Weile mit einem Wildcard Zertifikat von LetsEncrypt und einem HAproxy in Betrieb.
Mein aktuellstes Projekt ist OnlyOffice hinter dem HAproxy zugunsten der SSL Verschlüsselung zu betreiben.
Der Server läuft lokal auf Port 80 und funktioniert dort inkl. den Doc-Editoren auch problemlos.
Wenn ich aber die Adresse über den HAproxy öffne, funktioniert zwar die grundsätzliche OnlyOffice Seite noch, jedoch die Doc-Editoren nicht mehr.
Die Einträge von Threads 16595, 19122 & 10343 haben mir leider auch nicht weitergeholfen... von OnlyOffice gibt es unter https://helpcenter.onlyoffice.com/installation/docs-community-proxy.aspx (https://helpcenter.onlyoffice.com/installation/docs-community-proxy.aspx) eine Verlinkung zur "zu tätigenden HAproxy Konfiguration" https://github.com/ONLYOFFICE/document-server-proxy/blob/master/haproxy/proxy-https-to-http.cfg (https://github.com/ONLYOFFICE/document-server-proxy/blob/master/haproxy/proxy-https-to-http.cfg) jedoch weiss ich nicht, wie ich die Einstellungen in der OPNsense GUI vornehmen kann (wenn überhaupt?)!
Ich gehe davon aus, dass hier das Problem begraben liegt:
acl existing-x-forwarded-host req.hdr(X-Forwarded-Host) -m found
acl existing-x-forwarded-proto req.hdr(X-Forwarded-Proto) -m found
http-request add-header X-Forwarded-Host %[req.hdr(Host)] unless existing-x-forwarded-host
http-request add-header X-Forwarded-Proto https unless existing-x-forwarded-proto
Für eure Hilfe bin ich sehr dankbar!
-
Nevermind, sorry für die Umstände, die Lösung ist ja eig. bedenklich einfach:
im entsprechenden Backend die Advanced Options aktivieren und unter "Option pass-through" die vier Zeilen einfügen:
acl existing-x-forwarded-host req.hdr(X-Forwarded-Host) -m found
acl existing-x-forwarded-proto req.hdr(X-Forwarded-Proto) -m found
http-request add-header X-Forwarded-Host %[req.hdr(Host)] unless existing-x-forwarded-host
http-request add-header X-Forwarded-Proto https unless existing-x-forwarded-proto
Sorry für jede verschwendete Minute!
-
acl existing-x-forwarded-host req.hdr(X-Forwarded-Host) -m found
acl existing-x-forwarded-proto req.hdr(X-Forwarded-Proto) -m found
http-request add-header X-Forwarded-Host %[req.hdr(Host)] unless existing-x-forwarded-host
http-request add-header X-Forwarded-Proto https unless existing-x-forwarded-proto
Ich bin jetzt nicht der HAProxy experte, aber das hier sieht gefährlich aus.
Theoretisch könnte man die Header dann auch von außen setzen.
-
acl existing-x-forwarded-host req.hdr(X-Forwarded-Host) -m found
acl existing-x-forwarded-proto req.hdr(X-Forwarded-Proto) -m found
http-request add-header X-Forwarded-Host %[req.hdr(Host)] unless existing-x-forwarded-host
http-request add-header X-Forwarded-Proto https unless existing-x-forwarded-proto
Ich bin jetzt nicht der HAProxy experte, aber das hier sieht gefährlich aus.
Theoretisch könnte man die Header dann auch von außen setzen.
Denke ich auch.
Klingt definitiv nach einer schlechten Idee es so zu "lösen".
-
Experte bin ich jetzt auch nicht, aber soweit ich das lese setzt das lediglich den HostHeader für X-Forwarded-Host wenn er nicht gesetzt wurde durch ein System davor auf den Wert von hdr(Host). Da das System dahinter den Forwarded Header wohl ausliest/braucht.
Proto wird meist gebraucht wenn HTTPS im Frontend aber nicht im Backend gesprochen wird, sonst landet das in ner Endlos-Redirect-Loop da das Backend immer denkt es ist HTTP, macht einen Redirect aber das Frontend ist schon auf HTTPS. Der Host sollte eigentlich durch den Eintrag im HAproxy Frontend sauber gesetzt werden (wenn angehakt), dass man den nicht setzen müsste (IMHO). Vielleicht wurde das aber auch vergessen und daher war dann der Header leer was das Problem verursacht hat. "Setzen wenn leer" sollte also eigentlich nichts böses sein.
Cheers :)
-
https://portswigger.net/web-security/host-header
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection
-
Korrekt, da gehts um Host-Header Attacken. Und X-Forwarded-For ggf. als Vektor. Die Anwendungen brauchen den X-Forwarded aber um ggf. zu prüfen, ob über die korrekte Domain zugegriffen wurde, nicht für Auth. Sehe ich jetzt im ersten Moment nicht, was das eine hier mit dem anderen zu tun hat.
Ich hätte tatsächlich auch eher wie schon geschrieben den Forwarded-For fix im Frontend gesetzt bzw. statt mit Variablen
-> http-request add-header X-Forwarded-Host %[req.hdr(Host)] unless existing-x-forwarded-host
direkt fix auf den Wert gesetzt, den der Host dahinter braucht bzw. auf dem er läuft.
Was dann ein Angreifer in seinen Host-Header reinhaut ist eigentlich egal (wenn der falsch ist, kommt er ja nicht im korrekten Backend raus - oder in gar keinem) und selbst wenn er seine Attack URL selbst in X-Forward einfügt, wird die "überschrieben" bevor sie ans Backend geht.
Darum meinte ich: sehe ich beim ersten Drüberlesen jetzt nicht als böse, aber ich lerne auch gern dazu! Wenn das also wider erwarten nicht so funktioniert wie ich denke/dachte - bitte raus damit :)