UFW und Docker mit Reverse Proxy - Sicherheit

Chibi88

Lt. Commander
Registriert
Dez. 2007
Beiträge
1.266
Hallo,

derzeit habe ich eine Nextcloudinstanz und eine Vaultwardeninstanz auf meinem Server laufen. Die beiden Dienste habe ich mit einer Nginx Proxy Manager Weiterleitung so konfiguriert, dass sie auf die Ports zeigen.

Deployt habe ich die Docker Container wie folgt:
Nextcloud auf Host 11000 und Docker 80
Vaultwarden auf Host 15000 und Docker 80

Wenn ich im Proxy Manager jetzt wie folgt konfiguriere
Domain Name: <meineDomain>
Scheme: <http>
Hostname / IP: <meineVPSipv4>
Forward Port <11000 und bei dem anderen Dienst 15000)

kann ich unter SSL für diese Dienste ein Zertifikat von let's Encrypt ausrollen. Bei Domainaufruf ohne Portangabe im Header werde ich auch richtig weitergeleitet. Ich kann diese aber auch im Browser über nur http mit der Domain und dem Port, z. B. 15000 aufrufen.

Ist das ein Sicherheitsrisiko? Wenn ja, wie kann ich das beheben? MITM ist bei normalen Domainaufruf nicht möglich, da SSL verschlüsselt. Außerdem muss ich in UFW Ports 11000 und 15000 freigeben, da ich sonst keinen Zugriff bekomme. Kann ich hier evtl. auch ein bisschen mehr Sicherheit erlangen?

Grüße

Edit: Das Management vom Portainer und Nginx Proxy Manager sind auch öffentlich erreichbar. Ich habe hier ein langes PW genommen und arbeite mit Fail2ban. Gibt es bessere Lösungen?
 
Zuletzt bearbeitet:
Chibi88 schrieb:
Edit: Das Management vom Portainer und Nginx Proxy Manager sind auch öffentlich erreichbar. Ich habe hier ein langes PW genommen und arbeite mit Fail2ban. Gibt es bessere Lösungen?
Nur öffentlich erreichbar machen, was erreichbar sein muss. Beispielsweise kannst du fix wireguard aufsetzen und die management Interfaces nur auf der fürs vpn vorgesehenen ip Range lauschen lassen.


Chibi88 schrieb:
das ein Sicherheitsrisiko? Wenn ja, wie kann ich das beheben? MITM ist bei normalen Domainaufruf nicht möglich, da SSL verschlüsselt. Außerdem muss ich in UFW Ports 11000 und 15000 freigeben, da ich sonst keinen Zugriff bekomme. Kann ich hier evtl. auch ein bisschen mehr Sicherheit erlangen?
Ob du Transportverschlüsselung a. Hast oder nicht ist aus betreibersicht fast egal. Kannst für alles http einen redirect nach https machen.
Warum 11000 unf 15000? Ich betreibe mir ein paar mehr Dienste und habe nur 80 und 443 auf (von Video Konferenzen mal abgesehen)
 
madmax2010 schrieb:
Ob du Transportverschlüsselung a. Hast oder nicht ist aus betreibersicht fast egal. Kannst für alles http einen redirect nach https machen.
Warum 11000 unf 15000? Ich betreibe mir ein paar mehr Dienste und habe nur 80 und 443 auf (von Video Konferenzen mal abgesehen)
Hat er ja auch. Die 11000 und 15000 gehen nur zwischen NPM und Docker-Host. Nach außen ist nur 80 & 443 offen.
Hier würde ich auch ansetzen: ich gehe mal davon da steht noch ein Router und/oder Firewall zwischen Außenwelt und NPM. Hier einfach Port 80 dichtmachen.

Ein Sicherheitsrisiko besteht halt für den der deine Dienste per http (unverschlüsselt) nutzt. Man kann NPM aber auch so konfigurieren das er http-Anfragen in https umsetzt. (Force SSL aktivieren).

https://github.com/NginxProxyManager/nginx-proxy-manager/issues/886
Ergänzung ()

PS: gerade eingefallen: bin unsicher wegen Port 80 dicht machen: braucht man für die Zertifikatsanfrage bei Let's Encrypt nicht Port 80 & 443?
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: madmax2010
Korben2206 schrieb:
PS: gerade eingefallen: bin unsicher wegen Port 80 dicht machen: braucht man für die Zertifikatsanfrage bei Let's Encrypt nicht Port 80 & 443?
jein, gibt auch noch DNS-01

aber den selben dienst auf 80 und 443 lauschen zu lassen, exposed i.d.r auch die gleichen sicherheitsluecken. Security by Obscurity wirkt nicht. 80 kann man lasen und einfach einen redirect machen.

grob so:

Code:
server {
    listen 80 default_server;

    server_name _;

    return 301 https://$host$request_uri;
}
 
  • Gefällt mir
Reaktionen: Korben2206
madmax2010 schrieb:
Nur öffentlich erreichbar machen, was erreichbar sein muss. Beispielsweise kannst du fix wireguard aufsetzen und die management Interfaces nur auf der fürs vpn vorgesehenen ip Range lauschen lassen.



Ob du Transportverschlüsselung a. Hast oder nicht ist aus betreibersicht fast egal. Kannst für alles http einen redirect nach https machen.
Warum 11000 unf 15000? Ich betreibe mir ein paar mehr Dienste und habe nur 80 und 443 auf (von Video Konferenzen mal abgesehen)

Wie machst du das in Docker? Ich habe im Container den Port 15000 und 11000 genommen und via Proxy Manger dann ein SSL ausgerollt, welches auf 443 weiterleitet. Wenn ich 80:80 in Docker nehme, beißen sich andere Container, die auch auf 80:80 senden.
 
Zurück
Oben