Wie man einzelne private Services abriegelt, um die Sicherheit zu erhöhen

Cloudflares größte Stärke liegt in der extrem simplen Verwaltung von DNS-Einträgen und der automatischen Bereitstellung von SSL-Zertifikaten. Jeder, der schon einmal am Wochenende von einem abgelaufenen Let’s Encrypt-Zertifikat überrascht wurde, weiß, wie mühsam die ständige Erneuerung sein kann. Cloudflare nimmt einem diese Fleißarbeit komplett ab und stellt automatisch gültige Zertifikate für alle verwalteten Domains aus. Da liegt der Gedanke nahe, auch die internen, privaten Services über Cloudflare zu routen, um von genau diesem Komfort zu profitieren.

In meiner Infrastruktur hat fast jeder private Service eine eigene Subdomain: NAS, Vault, AdGuard, Grafana, Portainer. Alles läuft über Cloudflare. Wie ich das mit Docker Stacks und Cloudflare Tunnels aufgebaut habe, könnt ihr in Teil 2 meiner Homelab-Serie nachlesen. Das erspart mir das Zertifikats-Management und erlaubt mir einen sicheren Zugriff von überall. Doch wie stellt man sicher, dass diese Services nicht plötzlich für das gesamte Internet offenstehen? Genau hier betritt Cloudflare Access als digitaler Türsteher die Bühne.

Der Weg nach Cloudflare: Keine offenen Ports, keine Panik

Die meisten meiner Services laufen in Docker-Containern auf einem Heimserver. Um diese sicher mit Cloudflare zu verbinden, nutzen wir sogenannte Cloudflare Tunnels. Das Prinzip ist genial: Der Traffic wird von innen nach außen zu Cloudflare geleitet. Ihr müsst also keine Ports an eurem Router öffnen. Weniger offene Ports bedeuten weniger Angriffsfläche und einen deutlich entspannteren Schlaf.

Der gesamte Datenverkehr fließt durch diesen Tunnel, und die Zugriffsrechte regeln wir bequem im Cloudflare Access Dashboard.

Einen solchen Tunnel erstellt ihr im Cloudflare Zero Trust Dashboard unter Networks > Tunnels > Create a tunnel. Dort konfiguriert ihr den cloudflared-Dienst. Nach Abschluss erhaltet ihr ein Token, das ihr dann in eurem Docker-Setup mit dem Image cloudflare/cloudflared:latest verwendet.

Beim Aufsetzen des Containers ist die Netzwerkkonfiguration entscheidend. Ihr habt im Wesentlichen zwei Optionen:

• Host-Netzwerk: Das ist der Weg des geringsten Widerstands. Der Container läuft im Host-Netzwerk und hat direkten Zugriff auf alle lokalen Services. Das ist extrem einfach einzurichten, birgt aber das theoretische Risiko, dass bei einer Kompromittierung des Tunnels das gesamte System erreichbar wäre.
• Eigenes Docker-Netzwerk: Der sicherere, leicht nerdigere Weg. Ihr erstellt ein dediziertes Docker-Netzwerk und packt nur die relevanten privaten Services sowie den cloudflared-Container hinein. So isoliert ihr den Tunnel und stellt sicher, dass er wirklich nur mit den Services kommuniziert, die nach außen sollen.

Tunnel-Routen konfigurieren: Wer darf wohin?

Steht der Tunnel, müssen die Routen definiert werden. Hier legt ihr fest, welche öffentliche Subdomain auf welchen internen Service zeigt. nas.example.com leitet dann auf die IP eures NAS, während grafana.example.com beim entsprechenden Container landet. Die passenden DNS-Einträge legt Cloudflare praktischerweise ganz automatisch an.

Wenn ihr auf einen anderen Docker-Container verweist, der im selben Netzwerk läuft, reicht es völlig, den Hostnamen und den Port des Containers anzugeben. Da Docker eine interne DNS-Auflösung mitbringt, müssen die Ports der Ziel-Container nicht einmal nach außen (auf den Host) gemappt sein.

Achtung, Stolperfalle: Beim Routen auf ein NAS oder bestimmte Web-Frontends, die strikt HTTPS erzwingen, lauft ihr oft in einen 502 Bad Gateway Fehler. Das liegt an gescheiterten TLS-Handshakes zwischen Cloudflare und eurem internen Service. Die Lösung ist simpel: Aktiviert in den Tunnel-Einstellungen unter Additional application settings > TLS die Option No TLS Verify. Cloudflare ignoriert dann den fehlgeschlagenen Handshake des selbstsignierten internen Zertifikats und die Verbindung steht.

Pro-Tipp: Reverse Proxy Inception In meinem Setup habe ich für meine Webseiten nur einen einzigen Service im Tunnel konfiguriert: http://traefik:80. Traefik fungiert bei mir als Reverse Proxy. Cloudflare reicht alle Anfragen einfach an Traefik durch, und Traefik kümmert sich dann anhand der Subdomains um das interne Routing. So muss ich nicht für jeden neuen Container den Cloudflare-Tunnel anfassen. Meine Traefik-Konfiguration findet ihr zur Inspiration hier in meinem GitHub Repo.

Cloudflare Access Policies: Der VIP-Bereich

Früher habe das abriegeln mittels Security Rules im Domain Dashboard gemacht aber es geht auch deutlich komfortabler mit Zero trust.

Der Tunnel steht, die Services sind erreichbar. Jetzt müssen wir sie wieder absperren.

Dazu legen wir unter Access > Applications eine neue Application an. Nennen wir sie schlicht “Home”. Als Application URL habe ich *.dieck-labs.de konfiguriert, da ich für meine Home-Infrastruktur eine separate Domain betreibe. Der Wildcard-Eintrag schützt direkt alle Subdomains auf einmal.

Jetzt definieren wir die Policies (die Regeln für unseren Türsteher):

1. Der Zugriff von außen (Allow): Damit ich von unterwegs auf meine Services komme, richte ich eine Allow-Regel ein. Als Selektor wähle ich “Emails” und trage meine private E-Mail-Adresse ein. Auch die Adressen von Familienmitgliedern, die auf den Jellyfin-Server zugreifen sollen, landen hier. Wer die Seite aufruft, bekommt einen Login-Screen, gibt seine E-Mail ein, erhält einen Einmalcode und ist drin.
2. Der bequeme Zugriff von Zuhause (Bypass): Innerhalb der eigenen vier Wände möchte man sich nicht ständig mit PIN-Codes herumschlagen. Hierfür brauchen wir eine Bypass-Regel. Man könnte theoretisch IP-Ranges oder die eigene öffentliche IP eintragen, was aber bei dynamischen IPs (ohne ständige DynDNS-Updates) schnell nervig wird. Die weitaus elegantere Lösung: Wählt als Selector Gateway. In Kombination mit dem Cloudflare WARP-Client (der 1.1.1.1 App) auf euren Geräten erkennt Cloudflare euch automatisch als berechtigt. Der Zugriff im Heimnetz (oder mit aktivem WARP-Client) funktioniert so komplett nahtlos, ohne jegliche PIN-Eingabe.

Device Enrollment absichern

Zuletzt solltet ihr noch sicherstellen, dass nicht jedes beliebige Gerät eurer Organisation beitreten kann. Unter Settings > WARP Client > Device enrollment permissions (oder je nach Dashboard-Version unter Team & Resources > Devices) müsst ihr eine Regel definieren:

1. Klickt auf Manage oder Add a rule.
2. Rule Name: “My Devices” (oder ähnlich).
3. Selector: Emails.
4. Value: Eure E-Mail-Adresse(n).

Zusätzlich empfehle ich, die “Device authentication identity” in den Teams und Apps zu aktivieren.

So ist das Setup rund: Eure Services sind durch Cloudflare abgeschirmt, von außen nur für autorisierte Nutzer erreichbar, und zu Hause könnt ihr dank eleganter Bypass-Regeln weiterhin bequem und ohne ständige Logins auf euer Homelab zugreifen.