Homeserver Fernzugriff: OpenVPN od. Cloudflare/Reverse Proxy?

[roberto_blanco]

Hallo zusammen,

Ich betreibe zuhause einen kleinen Homeserver mit OMV und diversen Diensten die in Docker Containern laufen. Bisher habe ich diese Dienste hauptsächlich alleine genutzt und mich - wenn ich unterwegs war - einfach mittels OpenVPN mit meinem Heimnetzwerk verbunden um darauf zuzugreifen. Inzwischen sind aber ein paar Dienste dazugekommen, die ich gerne auch meiner Frau und den Kindern zugänglich machen würde wenn sie unterwegs sind (z.B. Vaultwarden, Timelimit, ioBroker). Daher habe ich mich nun 2 Tage lang durch unzählige Threads und Blogs gewühlt und nach Möglichkeiten gesucht, einen solchen Fernzugriff ohne VPN zu ermöglichen ohne Heimnetzwerk zu kompromittieren.

Mehrheitlich wird nach wie vor die Verwendung einer VPN-Verbindung empfohlen, allerdings bin ich in diesem (englischsprachigen) Blog auf eine alternative Möglichkeit gestossen. Kurz zusammengefasst geht es darum, dass man für eine (eigene) Domain die DNS-Server von Cloudflare nutzt und durch einen Cloudflare-Tunnel auf einen Reverse Proxy (Traefik) auf dem Homeserver gelangt, über welchen man den gewünschten Dienst nutzen kann. Für Dienste die keine eigene Authentifizierung bieten lässt sich mittels Authelia noch ein Dienst zur Authentifizierung dazwischenschalten.

Ein Vorteil den ich bei dieser Variante gegenüber OpenVPN sehe ist, dass ich dadurch nicht mein ganzes Netzwerk exponiere, sondern nur die freigegebenen Dienste. Was zugegebenermassen insbesondere bei Vaultwarden trotzdem nicht unkritisch ist... Wie ist dieser Weg über Cloudflare/Traefik in Punkto Sicherheit einzuschätzen, insbesondere im Vergleich zu VPN?

Bin dankbar für jegliche Inputs.

Viele Grüsse,
Rob

 

[foo_1337]

Ein Vorteil den ich bei dieser Variante gegenüber OpenVPN sehe ist, dass ich dadurch nicht mein ganzes Netzwerk exponiere, sondern nur die freigegebenen Dienste.

Niemand zwingt dich dazu, bei ovpn (oder wireguard oder ipsec) das ganze Netzwerk zu exposen.

Die 2 Vorgehensweisen sind grundverschieden und du solltest dir erstmal die Frage stellen, was du eigentlich willst und dann entscheiden. Insbesondere wenn die exposed Services keine gute 2FA bieten (hättest du ja hier via Authelia), würde meine Empfehlung stark in Richtung VPN gehen. Sobald es keine Encryption gibt, erstrecht.

 

[s1ave77]

Traefik v2 kann auch Google OAuth2 (Googlekonto mit 2FA sichern) einbinden und per Middlewares an die Subdomains vererben: https://www.smarthomebeginner.com/traefik-2-docker-tutorial.

Das ist auch sicher ohne VPN .

 

[roberto_blanco]

Niemand zwingt dich dazu, bei ovpn (oder wireguard oder ipsec) das ganze Netzwerk zu exposen.

Da hast du natürlich Recht, da waren meine Finger mal wieder schneller als mein Kopf.

du solltest dir erstmal die Frage stellen, was du eigentlich willst

Wie bereits im Eingangsbeitrag geschrieben möchte ich eigentlich eine Lösung um ohne VPN auf diese Dienste zugreifen zu können. Was ich sebst zu wenig einschätzen kann ist ob das Vorgehen wie in dem verlinkten Blog beschrieben in Punkto Sicherheit Nachteile hat gegenüber OpenVPN. Sprich, setze ich mein Heimnetzwerk einem grossen/grösseren Risiko aus, wenn ich einzelne Dienste mittels Cloudflare-Tunnel und Traefik der ganzen Welt aussetze?

Traefik v2 kann auch Google OAuth2 (Googlekonto mit 2FA sichern) einbinden und per Middlewares an die Subdomains vererben: https://www.smarthomebeginner.com/traefik-2-docker-tutorial.

Das mit Google OAuth2 wusste ich nicht. Im Blog wird allerdings auch https://github.com/authelia/authelia als Middleware ins Spiel gebracht, das bietet auch die Möglichkeit einer 2FA.

 

[TechX]

Warum noch Fremde mit einbinden?
VPN erweitern u. fertig ist die Laube.

 

[foo_1337]

Sprich, setze ich mein Heimnetzwerk einem grossen/grösseren Risiko aus, wenn ich einzelne Dienste mittels Cloudflare-Tunnel und Traefik der ganzen Welt aussetze?

Die Frage ist recht einfach zu beantworten: Solange du dafür Sorge trägst, dass alle exposed Dienste sicher konfiguriert sind und eventuelle Lücken schnell geschlossen werden (Update oder Workaround) spricht absolut gar nichts dagegen.
Bist du hier nachlässig oder nicht versiert, solltest du auf eine der VPN Varianten ausweichen. Das klingt jetzt wie ein Freibrief, ist es aber selbstverständlich nicht. Nur muss ein Angreifer halt hier erstmal das eine Tor öffnen um zum nächsten zu kommen.

 

[roberto_blanco]

Warum noch Fremde mit einbinden?
VPN erweitern u. fertig ist die Laube.

Weil meine Familie eine möglichst simple Bedienungsmöglichkeit braucht und daher der Weg ohne VPN, sondern mit jederzeitigem direktem Zugriff über z.B. die Bitwarden-App, der Einfachste wäre. Und wenn nichts gegen die Cloudflare-Variante spricht, warum MUSS es dann VPN sein?

Solange du dafür Sorge trägst, dass alle exposed Dienste sicher konfiguriert sind und eventuelle Lücken schnell geschlossen werden (Update oder Workaround) spricht absolut gar nichts dagegen.

Alles klar, damit kann ich was anfangen, vielen Dank! ;-) In Docker habe ich Watchtower laufen, wodurch meine Dienste laufend aktuell gehalten werden. Und es werden wie gesagt auch nur 2-3 Dienste exposed, somit sollte das Ganze auch überschaubar bleiben was die Config anbelangt...

 

[snaxilian]

Watchtower o.ä. ist schon einmal ein Anfang aber oft nicht ausreichend.
1. Abfragen per Watchtower ob es Updates gibt, reicht manchmal schon aus um ins rate-limit vom Docker Hub zu laufen, der Updateprozess schlägt dann fehl.
2. Nicht alle Updates laufen problemlos unbeaufsichtigt. Mal muss auch eine Konfiguration angepasst werden damit das (Sicherheits-)Update vollumfänglich funktioniert oder es sind anschließende manuelle Entscheidungen notwendig bei Upgrades

 

[roberto_blanco]

1. Abfragen per Watchtower ob es Updates gibt, reicht manchmal schon aus um ins rate-limit vom Docker Hub zu laufen, der Updateprozess schlägt dann fehl.

Als registrierter Dockerhub User liegt das Limit bei 200 Pulls innerhalb von 6 Stunden. Ist es da nicht sehr unwahrscheinlich, dass dies passiert?

2. Nicht alle Updates laufen problemlos unbeaufsichtigt. Mal muss auch eine Konfiguration angepasst werden damit das (Sicherheits-)Update vollumfänglich funktioniert oder es sind anschließende manuelle Entscheidungen notwendig bei Upgrades

Ist mir zwar bisher noch nie passiert, aber klar. das kann man natürlich nicht ausschliessen. Hast du einen Tipp, wie man damit am besten umgeht? Lässt es sich z.B. konfigurieren, dass in solchen Fällen der Container autom. gestoppt wird?

 

[snaxilian]

Ist es da nicht sehr unwahrscheinlich, dass dies passiert?

Ja, nein, vielleicht. Woher soll ich das in deinem konkreten Fall wissen? Du hingegen könntest dies selbst verifizieren. Einfach für alle Images, die man im Einsatz hat, die diversen Layer zählen, dann weißt du, wie viele Pulls du benötigst für die Aktualisierung aller deiner Container.

docker history <Name-des-Images>

zeigt dir alle Layer eines Images an.

docker history <Name-des-Images> | wc -l

zeigt dir alle Layer an und zählt die Zeilen. Davon musst je eine Zeile abziehen für die Überschrift der Spalten^^

Als Beispiel: Eine simple Jitsi Instanz besteht zwar nur aus vier Containern, diese bestehen zusammen aus 76 Layern. Das Image von nginx:latest besteht aus 15 Layern, nextcloud:latest aus 43 und mariadb:10.5 aus 23.
Ein kleiner vServer mit nginx als Reverse Proxy und dahinter Jitsi und eine Nextcloud ergeben schon 157 Layer und damit 157 Pulls.

<edit>Layer != Images</edit>

In dem Setup fehlt dann noch ein Container, der sich um die Erneuerung der Zertifikate kümmert und Watchtower o.ä. oder was auch immer du noch so hosten willst.

Wer dann noch ggf. Container zuhause hostet und an einem DSlite Anschluss hockt, kommt schnell ins Limit wenn andere Nutzer auch Docker nutzen.

Hast du einen Tipp, wie man damit am besten umgeht?

Da ist mir kein (technischer) Automatismus bekannt. Da hilft nur Release Notes lesen und/oder entsprechende Anwendungstests bzw. Monitoring verwenden um mitzubekommen, wenn $Anwendung nicht mehr wie erwartet funktioniert.
Nextcloud ist so ein gutes Beispiel wo bei neuen Majorversionen oft noch Nacharbeiten an der DB notwendig sind oder Plugins/"Apps" innerhalb von Nextcloud manuell aktualisiert werden müssen.
Aus genau diesem Grund ist die Verwendung von :latest Images nur bedingt sinnvoll. Im privaten Umfeld kann man ggf. damit leben wenn irgendetwas nach automatischen Updates kaputt geht aber auch da kommt es darauf an, wer bzw. wie viele Dritte die bereit gestellten Dienste noch verwenden.

 

[roberto_blanco]

Einfach für alle Images, die man im Einsatz hat, die diversen Layer zählen, dann weißt du, wie viele Pulls du benötigst

Auf Docker-Hub ist das Rate Limit folgendermassen definiert:

Definition of limits​

A user’s limit is equal to the highest entitlement of their personal account or any organization they belong to. To take advantage of this, you must log in to Docker Hub as an authenticated user. For more information, see How do I authenticate pull requests. Unauthenticated (anonymous) users will have the limits enforced via IP.

• A pull request is defined as up to two GET requests on registry manifest URLs (/v2//manifests/).
• A normal image pull makes a single manifest request.
• A pull request for a multi-arch image makes two manifest requests.
• HEAD requests are not counted.

https://docs.docker.com/docker-hub/download-rate-limit/

Wie ich das verstehe heisst das doch, dass ein Image = 1 Pull ist und nicht nach Layern abgerechnet wird?

Nextcloud ist so ein gutes Beispiel wo bei neuen Majorversionen oft noch Nacharbeiten an der DB notwendig sind oder Plugins/"Apps" innerhalb von Nextcloud manuell aktualisiert werden müssen.

Für die "wichtigen" Container habe ich Watchdower bereits so konfiguriert, dass ich lediglich benachrichtigt werde, wenn Updates zur Verfügung stehen. Die Aktualisierung mache ich dann selbst.

 

[snaxilian]

Ja, du hast recht, nicht jeder Layer ist ein eigenes Image aber guck einfach mal in deine Dockerfiles, direkt am Anfang steht ein 'from' aus dem ersichtlich ist, auf welchem Image das aufbaut. Dann such mal diesem Dockerfile und guck was da unter 'from' steht usw.

 

[roberto_blanco]

Alles klar, schaue ich mir mal an, danke für den Hinweis!!

Da du von Nextcloud schreibst: Hast du einen solchen Container am laufen und ist dieser exposed? Falls ja, wie sicherst du den Zugriff von aussen ab?

 

[snaxilian]

Nginx als Reverse Proxy und dort ModSecurity als WAF sowie fail2ban, nein das sind beides keine installieren und fertig Lösungen sondern erfordern ggf. Feintuning und das man sich damit beschäftigt.
Login der Nextcloud zusätzlich mit MFA abgesichert.

 

[roberto_blanco]

@snaxilian Cool, vielen Dank für den Link zu ModSecurity (fail2ban ist mir natürlich bekannt)!!Wwerde mich da mal einlesen... Unterstützt die (Android?) Nextcloud App MFA-Login oder nutzt du Nextcloud nur browserbasiert?

 

[snaxilian]

Der Login der App öffnet afaik auch nur einen Browser, also klappt^^
Ansonsten ist, sofern nicht anders konfiguriert, MFA eine User-Entscheidung, du könntest dir also problemlos einen Testaccount einrichten.

 

[roberto_blanco]

@snaxilian Top, vielen Dank!