Cloudflare Tunnel + Cloudflare Access für Home Assistant – sichere App-Nutzung ohne 30-Tage-Reauth?

Add-ons
1

Hallo zusammen,

ich nutze aktuell Cloudflare Tunnel, um von extern auf meinen Home Assistant zuzugreifen. Grundsätzlich funktioniert das Setup gut.

Nun möchte ich den Zugriff zusätzlich mit Cloudflare Access absichern, mit folgenden Zielen:

  • Browserzugriff:
    Eine vorgeschaltete zusätzliche Anmeldemaske (Cloudflare Access), bevor überhaupt das Home-Assistant-Login erscheint.

  • App-Zugriff (iOS) (Home Assistant App):
    Ebenfalls eine zusätzliche Sicherheitsebene, ohne dass das Login-Portal öffentlich erreichbar bzw. direkt sichtbar ist.

  • Generell soll das Home-Assistant-Login nicht einfach von außen erreichbar sein, sondern nur nach erfolgreicher Access-Authentifizierung.

Aktuell habe ich den App-Zugriff über Cloudflare Access mit E-Mail-Authentifizierung umgesetzt. Das funktioniert, allerdings ist die Freigabe auf maximal 30 Tage begrenzt. Danach muss ich den Zugriff erneut bestätigen, was für die tägliche Nutzung der App eher unpraktisch ist und für mich keine saubere Dauerlösung darstellt.

Meine Fragen an euch:

  • Wie setzt ihr Cloudflare Access für Home Assistant sinnvoll um (Browser + App)?

  • Gibt es eine Möglichkeit, den App-Zugriff dauerhaft oder deutlich länger gültig zu machen, ohne ständig neu zu authentifizieren?

  • Nutzt ihr z. B. Service Tokens, mTLS, Device Posture, Bypass-Regeln oder separate Subdomains für App und Browser?

  • Welche Best Practices haben sich aus eurer Sicht bewährt?

Ich freue mich über konkrete Erfahrungswerte, Architektur-Vorschläge oder Beispiel-Setups.

Vielen Dank im Voraus!

BG

Paddey

2

Hi,

als ich deine Anfrage gelesen habe, war ich auch interessiert daran, das umzusetzen. Habe daraufhin deine Fragen mal der KI gestellt: Antwort war, Email Auth alle 30 Tage für unwichtiges und für tägliches via mTLS ein Zertifikat erstellen und installieren um den Login Prozess für HA zu umgehen.

Bist du denn schon weiter gekommen ?

MfG

1 „Gefällt mir“
3

Ich habe die in Cloudflare verfügbaren Schutzmechanismen (DDoS-Schutz, Bot-Schutz, etc.) aktiviert und ggf. konfiguriert, zusätzlich habe ich Firewallregeln zum Geoblocking eingerichtet.
Die zur Verfügung stehenden Möglichkeiten hängen vom gewählten Plan ab, ich habe aktuell nur den kostenlosen Plan in Benutzung.

Der Login in HA ist zusätzlich via 2-Faktorauthorisierung abgesichert.
100%-igen Schutz gibt es natürlich nicht…

1 „Gefällt mir“
4

Das klingt interessant. Hast du dir mal angeschaut, wie das funktioniert und wo man das Zertifikat in der App einbinden kann?

Habe bei paperless ngx eine Header bedingte Authentifizierung eingerichtet. Das kann man in der App hinterlegen. Das funktioniert allerdings nicht in der HA App

5

Ich habe das grundsätzlich ähnlich gelöst und SSL sowie die relevanten Sicherheitsprotokolle sauber konfiguriert, um insgesamt ein hohes Sicherheitsniveau zu erreichen.

Was mich aktuell noch stört: Die Home-Assistant-Anmeldemaske ist direkt öffentlich erreichbar. Für den Browserzugriff habe ich bereits einen zweiten Layer über Cloudflare Access eingebaut – erst Cloudflare-Login (E-Mail + PIN), danach erst die Home-Assistant-Anmeldung.

Für die App ist das allerdings unpraktisch, da dieser zusätzliche Login dort nicht sauber funktioniert. Dafür suche ich aktuell noch eine passende Lösung. Wenn das gelöst ist, wäre ich aus Security-Sicht zufrieden.

6

Ja ich habe mich gestern sogar damit beschäftigt. Ich hatte die Google Auth Verifikation integriert aber nur für nicht App genutzte Sachen wie SynoStation und FB. Bisher habe ich noch keine Möglichkeit gesehen das mTLS in Verbindung mit HA zu nutzen. Weder HA bietet eine Zertifikatsauswahl / upload an, noch Cloudflared. Also bin ich erstmal von ausgegangen, dass das so nicht kompatibel ist. Das einzige was mir dabei noch in den Kopf kam, wäre ha via Browser / eigene Subdomain mit der Google Auth abzusichern und dann für die HA Companion App vieles mit policys einzuschränken, wobei das auch kein Allheilmittel ist.

7

Wie wäre einfach ein sicheres Passwort? :wink:

Wenn dies schlecht ist, hilft auch keine weitere Eingabe davor zu schalten. Und wenn es passt, ist es auch so sicher.

Wer anderer Meinung ist kann gerne einen Proof of Concept präsentieren.

8

Ich nutze 1Password und alle meine Passwörter bestehen aus mindestens 12 Zeichen + Sondernzeichen. Ich würde das umsetzen wollen, damit ich erst gar keine IP-Bans sehen muss und diese schon bei Cloudflare abprallen. Deren Dienste und Funktionen sind wohl deutlich weiter entwickelter als mein System und dessen Funktionen. Wäre auch noch ein Argument.

1 „Gefällt mir“
9

IP Ban würde ich keinesfalls aktivieren. Bei Cloudflare reicht es für gewöhnlich, dass man die üblichen Länder ausnimmt bzw. nur die Länder erlaubt, in denen man sich bewegt.

Über Nabu Casa kann ich mich interessanterweise an nicht einen fehlgeschlagenen, unerklärlichen Login erinnern.

10

IP Ban würde ich keinesfalls aktivieren.

Aber das wird doch in jeder Dokumentation / Video so beschrieben !? Wo soll denn da bitte die Gefahr sein ? Adapter Reset und weiter gehts …

11

Dann schau mal wie viele Themen es gibt, wo sich Menschen local aussperren oder Probleme haben und keine Ahnung wieso.

Und was genau soll diese Funktion bringen? Wie viele Zugriffsversuche der selben IP hast Du im Durchschnitt innerhalb von wenigen Minuten?

12

Sehe ich ganz genau so, hab auch 1Password, lange, kryptische Kennwörter und zwei Faktor Authetifizierung. Trotzdem möchte ich nicht, dass mein Home AssistAmt Login Page direkt im Internet sichtbar ist. Mit IP Ban möchte ich lokal auch nicht unbedingt arbeiten. :see_no_evil_monkey:

13

Also ich glaube wir sind uns einig, das ein IP-Ban so gut wie keinerlei Sicherheit bietet, jedoch finde ich die Hürde für einen potenziellen Angreifer etwas höher. Und wer einen Passwortmanager nutzt UND sich dann noch aussperrt, der darf dann auch als Lehre ein Backup einspielen oder neu aufsetzen.

Ich lese gerade, dass auch nginx ein mTLS Gegenstück sein kann. Den habe ich am laufen. Ich belese mich mal in die Richtung weiter

1 „Gefällt mir“
14

Dagegen gäbe es die Möglichkeit des Whitelistens… :wink:
Ich würde IPBan aber auch schon seit vielen Jahren nicht mehr “zur Verteidigung” einsetzen.

15

Stimme ich dir mit allen zu. Nginx habe ich auch laufen. Wenn du eine Lösung gefunden hast, freue ich mich diese zu erfahren :slight_smile:

Habe selber auch geschaut, die Zertifikatsbedingte Authentifizierung funktioniert nur unter Android direkt mit der App. Soweitnich das richtig verstehe :slight_smile:

16

Gegen einen IP Ban wechselt man einfach die IP. Insbesondere local ist dies doch extrem einfach. Online ebenfalls.

Und was spricht gegen den Login Public erreichbar, außer dem Gefühl?

Wenn jemand technisch nachvollziehbare Gründe liefern kann, wieso dies unsicher sein sollte… Proof of Concept

Andernfalls vielleicht weniger Gefühl mehr Fakten. :wink:

1 „Gefällt mir“
17

Hi tarag,

der Punkt ist nicht „IP-Ban ja oder nein“, sondern Angriffsoberfläche und Angriffsökonomie.

Dass ein IP-Ban trivial zu umgehen ist, ist korrekt. Genau deshalb ist er keine Sicherheitsmaßnahme, sondern höchstens ein Störfaktor. Daraus folgt aber nicht, dass eine öffentlich erreichbare Login-Seite unkritisch ist.

Ein paar konkrete, technische Gründe, warum man Login-Pages wie Paperless oder Home Assistant nicht direkt exponieren sollte, selbst hinter Cloudflare Tunnel:

1. Login-Endpoints sind per Definition Hochrisiko-Ziele

Alles, was:

  • /login

  • /auth

  • /api/auth

  • /api/token

enthält, ist automatisiert scannbar und wird permanent von Bots angegriffen.
Nicht „vielleicht“, sondern nachweislich, 24/7.

Cloudflare filtert viel – aber:

  • Credential-Stuffing mit niedriger Rate

  • Passwort-Spraying

  • gezielte Exploits gegen bekannte Versionen

sehen für WAFs oft wie legitimer Traffic aus.

2. Zero-Day-Risiko schlägt jedes Gefühl

Der entscheidende Punkt ist nicht bekannte Schwachstellen, sondern unbekannte.

Proof of Concept (theoretisch, aber realistisch):

  • CVE in Home Assistant Auth Middleware

  • Fehler in Paperless Token Handling

  • Logic Bug vor MFA-Check

Wenn die Login-Page öffentlich ist:
→ Exploit = direkter Einstieg

Wenn davor ein zusätzlicher Auth-Layer liegt:
→ Exploit ist nicht erreichbar, selbst bei Zero-Day.

Das ist kein Gefühl, sondern klassisches Defense-in-Depth.

3. Cloudflare schützt den Transport, nicht die App-Logik

Cloudflare Tunnel bietet:

  • TLS

  • DDoS-Mitigation

  • Basic WAF

Aber keine Kenntnis der Applikationslogik von Home Assistant oder Paperless.

Cloudflare kann nicht wissen:

  • ob ein Token korrekt invalidiert wurde

  • ob ein Session-Fixation-Bug existiert

  • ob ein bestimmter Request legitimer Auth-Flow ist

Ein vorgeschalteter Identity-Layer (z. B. Cloudflare Access):

  • eliminiert komplette Code-Paths der App

  • reduziert Angriffsfläche auf Null vor Login

4. Öffentliche Login-Pages sind Metadaten-Leaks

Selbst ohne erfolgreichen Login:

  • App-Fingerprinting

  • Versionserkennung

  • verwendete Auth-Mechanismen

  • aktive Endpunkte

Das reicht Angreifern, um gezielt Exploits zu entwickeln oder zu warten, bis einer erscheint.

5. Wirtschaftlicher Aspekt (Angriffsökonomie)

Angreifer arbeiten opportunistisch:

  • öffentlich sichtbar → wird angegriffen

  • nicht sichtbar → wird übersprungen

Ein zusätzlicher Auth-Layer erhöht den Aufwand massiv und senkt die Wahrscheinlichkeit, überhaupt Ziel zu sein.

6. Vergleichbare Best Practices

In professionellen Setups sind:

  • Admin-Interfaces

  • Management-UIs

  • Self-Hosted Services

niemals direkt öffentlich, sondern immer:

  • VPN

  • Identity-Aware Proxy

  • Zero-Trust-Gateway

Nicht weil es „schöner“ ist, sondern weil es messbar sicherer ist.

Kurzfassung:
Es geht nicht darum, dass Cloudflare „unsicher“ wäre.
Es geht darum, dass jede öffentlich erreichbare Login-Seite ein unnötiges Risiko darstellt, das man mit minimalem Aufwand vollständig eliminieren kann.

Wenn man einen zusätzlichen Layer davorschaltet, gewinnt man:

  • Schutz vor Zero-Days

  • Reduktion der Angriffsfläche auf nahezu null

  • saubere Trennung zwischen Internet und interner App-Logik

Das ist keine Paranoia, sondern Standard-Security-Architektur. :slight_smile:

2 „Gefällt mir“
18

Wir sprechen über eine der aktivsten Open Source Projekte der Welt. Und welche Vorteile hätte ein Eindringling, wenn er Zugang erhalten würde?

Im Grundsatz bin ich bei Dir, dass ein nicht öffentlich erreichbarer Login sicherer ist als ein erreichbarer. Aber das spricht eben grundsätzlich gegen Cloudflare. :wink:

19

Ich habe das mit Wirequard onDemand VPN gemacht. Ich habe das VPN so eingerichtet, dass es nur bei internen URLs greift und auch den DNS intern nutzt. (Dann ist auch gleich die Werbung auf Handy und so weg). Damit muss ich HA nicht öffentlich erreichbar machen und habe keinerlei Einschränkungen. Geht Zuhause im WLAN (SSID als Ausnahme gesetzt in Wirequard) und in jeglichem anderen Netz, wenn VPN erlaubt ist.