Tobias Frenzel aus Regensburg hat im Juni 2026 sein Home Assistant erstmals über eine externe Domain erreichbar gemacht. Zuvor lief alles nur im Heimnetz, der Zugriff von unterwegs über die Nabu Casa Cloud reichte ihm. Dann hat er eine Fritzbox-VPN-Alternative gebaut, Nginx als Reverse Proxy eingerichtet, HTTPS mit einem Let's-Encrypt-Zertifikat konfiguriert. Alles lief. Zwei Tage später kam er nach Hause, öffnete die Home-Assistant-App auf dem Handy, und der Server war weg. Kein Zugriff, nicht über die externe Domain, nicht über die interne IP im Heimnetz. Im Log stand: "Banning IP address: 192.168.1.1".

Das war die IP seines eigenen Routers.

Was Tobias nicht wusste: Nginx leitet Anfragen standardmäßig mit seiner eigenen IP weiter, wenn man Home Assistant nicht sagt, dass ein Proxy dazwischen sitzt. Alle Anfragen kamen also aus Sicht von Home Assistant von 192.168.1.1. Als jemand von außen drei Mal falsche Zugangsdaten eingab, wurde 192.168.1.1 gebannt. Und damit auch Tobias.

Dieser Artikel beschreibt, wie ip_ban_enabled und trusted_proxies zusammenspielen, welche Fehlkonfigurationen das Ausgesperrtsein fast garantieren, wie man sie behebt, und was die YAML-Deprecation in Home Assistant 2026.8 für bestehende Konfigurationen bedeutet.

Wozu ip_ban_enabled überhaupt da ist

Wer sein Home Assistant über das Internet erreichbar macht, hat ein Problem: Das Login-Formular ist öffentlich. Automatisierte Scanner probieren Benutzername-Passwort-Kombinationen durch. Ohne Gegenmassnahme können das tausende Versuche pro Stunde sein, ohne dass Home Assistant reagiert.

ip_ban_enabled schaltet einen einfachen Zähler ein. Nach einer konfigurierbaren Anzahl fehlgeschlagener Anmeldeversuche von einer IP-Adresse schreibt Home Assistant diese IP in die Datei ip_bans.yaml im Konfigurationsverzeichnis. Ab dann kommt diese IP nicht mehr an das Login-Formular, sie erhält einen 403-Fehler.

Der Schwellwert heißt login_attempts_threshold. Setzt man ihn auf 5, wird eine IP nach fünf Fehlversuchen gebannt. Setzt man ihn auf -1, schaltet man automatische Bans komplett ab, der Ban-Mechanismus bleibt aber manuell über ip_bans.yaml nutzbar.

Bis Home Assistant 2026.8 wurde das in configuration.yaml konfiguriert:

http:
  ip_ban_enabled: true
  login_attempts_threshold: 5

Ab 2026.8 ist dieser YAML-Block deprecated. Was das bedeutet, erkläre ich am Ende des Artikels.

Das ip_bans.yaml-Format

Wenn Home Assistant eine IP sperrt, legt es die Datei ip_bans.yaml im Hauptkonfigurationsverzeichnis an. Die Datei ist ein YAML-Dictionary, kein YAML-Array. Das ist relevant, wenn man Einträge manuell hinzufügen oder entfernen will.

203.0.113.42:
  banned_at: "2026-06-14T22:17:33.814201+00:00"
45.129.56.200:
  banned_at: "2026-06-15T08:44:11.002847+00:00"

Wichtig: kein Bindestrich vor der IP-Adresse. Bindestriche würden eine Liste erzeugen, hier braucht man ein Dictionary.

Um einen Eintrag zu entfernen: Die Zeilen des IP-Eintrags und des banned_at-Feldes löschen, Datei speichern. Ein Neustart von Home Assistant ist nötig, damit die Änderung greift. Ein einfaches Nachladen der Konfiguration reicht nicht.

Um eine IP manuell zu sperren: Eintrag im oben gezeigten Format hinzufügen, Neustart. Wildcards für IP-Bereiche werden nicht unterstützt, jede IP muss einzeln eingetragen werden.

Das Reverse-Proxy-Problem und trusted_proxies

Hier fängt Tobias' Geschichte an, kompliziert zu werden.

Wenn Nginx, Caddy, Traefik oder ein anderer Reverse Proxy vor Home Assistant sitzt, passiert folgendes: Der Browser des Nutzers schickt eine Anfrage an den Proxy. Der Proxy schickt sie weiter an Home Assistant. Aus Sicht von Home Assistant kommt die Anfrage vom Proxy, nicht vom ursprünglichen Nutzer. Home Assistant sieht also immer dieselbe IP: die des Proxys.

Reverse Proxies können die ursprüngliche Client-IP im HTTP-Header X-Forwarded-For mitschicken. Nginx macht das mit proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;. Home Assistant ignoriert diesen Header aber standardmäßig, weil es ihn von jedem beliebigen Client fälschen könnte.

Man muss Home Assistant sagen, welche IPs vertrauenswürdige Proxys sind. Anfragen von diesen IPs dürfen den X-Forwarded-For-Header setzen, und Home Assistant nutzt den enthaltenen Wert als echte Client-IP.

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 192.168.1.1

Wenn der Proxy auf derselben Maschine wie Home Assistant läuft, oft der Fall bei Nginx als Add-on oder Docker-Container, ist die Proxy-IP 127.0.0.1:

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1

Man kann auch CIDR-Blöcke angeben: 192.168.1.0/24 für das gesamte lokale Netz. Wichtig dabei: Es muss die Netzwerkadresse sein, nicht eine Hostadresse. 192.168.1.50/24 ist falsch, 192.168.1.0/24 ist richtig.

Mit dieser Konfiguration sieht Home Assistant die echte Client-IP des Angreifers, nicht die Router-IP. Brute-Force-Bans treffen dann die richtigen Adressen.

Der 127.0.0.1-Ban bei Nabu Casa

Wer keinen eigenen Reverse Proxy betreibt, sondern Nabu Casa für den externen Zugriff nutzt, hat ein anderes Problem.

Der Nabu-Casa-Tunnel funktioniert so: Verbindungen von extern gehen zuerst zu den Nabu-Casa-Servern und werden von dort über einen lokal laufenden Prozess an die Home-Assistant-Instanz weitergeleitet. Aus Sicht von Home Assistant kommen alle Nabu-Casa-Anfragen von 127.0.0.1, also vom lokalen System selbst.

Das hat eine unangenehme Konsequenz: Wenn jemand über Nabu Casa falsche Zugangsdaten eingibt, zählt das als Fehlversuch von 127.0.0.1. Bei aktiviertem ip_ban_enabled mit niedrigem Schwellwert kann das dazu führen, dass 127.0.0.1 gebannt wird. Das sperrt dann nicht nur den Angreifer aus, sondern alle Nabu-Casa-Verbindungen, also auch den eigenen Zugriff von unterwegs.

Nabu Casa gibt zu, dass sie bisher keine verlässliche IP-Weitergabe implementiert haben. In GitHub-Issue #96597 heißt es dazu, dass die Architektur des Tunnels dafür verantwortlich ist. Eine Lösung ist bisher nicht angekündigt.

Was bedeutet das in der Praxis? Wer Nabu Casa nutzt und ip_ban_enabled aktiviert, muss damit rechnen, dass ein Angreifer mit genug Ausdauer den externen Zugang für alle sperren kann, indem er einfach wiederholt falsche Passwörter eingibt. Der Schwellwert 5 ist in diesem Szenario gefährlich niedrig.

Wer trotzdem Brute-Force-Schutz will und Nabu Casa nutzt: Threshold deutlich höher setzen, zum Beispiel 20 oder 30, oder ip_ban_enabled deaktivieren und stattdessen auf starke Passwörter und Multi-Faktor-Authentifizierung setzen. Die Zwei-Faktor-Authentifizierung in Home Assistant lässt sich über Einstellungen, Profil, Sicherheit aktivieren.

Gesperrte eigene IP wieder freischalten

Es gibt mehrere Wege, wie man sich selbst aussperrt. App-Absturz mit Fehlversuchen, fehlgeschlagenes Passwort nach einem Update, ein altes Login-Tool das auf eine geänderte API trifft und im Sekundentakt Fehler produziert.

Wenn die eigene IP in ip_bans.yaml steht, läuft die Entsperrung so:

  1. Zugang zum Dateisystem des Home-Assistant-Servers über SSH, über den Terminal-Add-on oder direkt.
  2. Datei ip_bans.yaml im Konfigurationsverzeichnis öffnen, standardmäßig /config/ip_bans.yaml bei HAOS.
  3. Den Eintrag mit der eigenen IP entfernen. Keine Teilzeilen stehen lassen, die banned_at-Zeile gehört dazu.
  4. Home Assistant neu starten.
Wenn man überhaupt keinen Zugriff mehr hat, auch nicht lokal, weil zum Beispiel die Loopback-IP 127.0.0.1 gebannt wurde: Der HAOS-Terminal gibt weiter Zugang. Entweder über einen direkt angeschlossenen Monitor und Tastatur, oder über die Hardware-Konsole. Von dort kann man die Datei bearbeiten und den Dienst neu starten mit ha core restart.

Die YAML-Deprecation in 2026.8

Mit Home Assistant 2026.8 hat Nabu Casa die HTTP-Konfiguration aus configuration.yaml in die grafische Oberfläche verschoben. Der http:-Block in YAML zeigt ab 2026.8 eine Reparatur-Meldung. In der Reparatur-Liste in Home Assistant steht: "The HTTP YAML configuration is deprecated. This stops working in version 2027.2.0."

Beim ersten Start nach dem Update auf 2026.8 wandern die bestehenden Einstellungen automatisch in die UI. Man muss nichts von Hand übertragen. Die Einstellungen finden sich danach unter Einstellungen, dann System, dann Netzwerk, dann HTTP-Server.

Für Proxy-Nutzer gibt es drei Punkte, die Aufmerksamkeit brauchen.

Nach dem Update den bestehenden http:-Block aus configuration.yaml entfernen. Sonst zeigt Home Assistant weiterhin die Reparatur-Meldung. Vorher prüfen, ob die Werte in der UI angekommen sind.

Wenn die neuen Einstellungen in der UI nach dem Update nicht sichtbar sind, ist die Ursache fast immer Browser-Cache. Strg+Shift+R löst das.

Und dann gab es kurzzeitig einen Bug, bei dem nach der YAML-Entfernung der Reverse-Proxy-Zugang nicht mehr funktionierte, weil trusted_proxies in der UI noch fehlte. GitHub-Issue #178330 dokumentiert das. Nach einem Home-Assistant-Neustart tauchten die Felder auf. Wer da rein gerät: nicht panisch YAML zurückschreiben, sondern erst neustarten und dann prüfen.

Ab 2027.2.0 wird der http:-Block in YAML ohne Wirkung sein. Wer bis dahin nicht migriert, verliert seine Konfiguration kommentarlos.

Sicherheit ohne Reverse Proxy

Für alle, die keinen Reverse Proxy betreiben und Home Assistant direkt über Port 8123 zugänglich machen, aber die öffentliche IP mit ip_ban_enabled schützen wollen: Das Setup ist einfacher, birgt aber eine andere Falle.

Wenn use_x_forwarded_for nicht aktiviert ist, sieht Home Assistant immer direkt die Client-IP. Das ist eigentlich gut: Bans treffen die richtigen Adressen. Die Falle liegt woanders. Wenn die eigene Heimnetz-IP (typischerweise 192.168.x.x) zu viele Fehlversuche produziert, wird sie gebannt. Das kann passieren, wenn mehrere Geräte im Netz gleichzeitig mit veraltetem Token oder falschem Passwort auf Home Assistant zugreifen.

In diesem Fall hilft trusted_networks im Authentication-Providers-Block. Damit können lokale IPs oder Subnetze vom Login-Prozess ausgenommen werden:

homeassistant:
  auth_providers:
    - type: homeassistant
    - type: trusted_networks
      trusted_networks:
        - 192.168.1.0/24

Das trusted_networks-Provider erlaubt Geräten aus dem angegebenen Netz, sich ohne Passwort anzumelden. Es ist kein Workaround für ip_ban_enabled, sondern ein separater Authentication-Provider. Er verhindert, dass lokale Geräte überhaupt Fehlversuche erzeugen können, solange sie im Heimnetz sind.

Tobias' Setup heute

Tobias hat sein Problem gelöst. In Nginx hat er proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; hinzugefügt. Dann in der Home-Assistant-UI unter Einstellungen, System, Netzwerk die Option "X-Forwarded-For vertrauen" aktiviert, die Nginx-IP als trusted Proxy eingetragen, 192.168.1.1 aus ip_bans.yaml gelöscht und neu gestartet.

Seitdem sieht er im Log die echten Angreifer-IPs. Der eigene Router ist nicht mehr gesperrt worden.

Was sich dabei als die eigentlichen Fallstricke herausgestellt hat, die man kennen sollte:

ip_ban_enabled ohne trusted_proxies hinter einem Reverse Proxy sperrt früher oder später den Proxy selbst. Das ist kein Sonderfall, das ist das normale Ergebnis wenn man den Proxy vergisst.

Nabu Casa und ein Threshold von 5 passen nicht gut zusammen. Wer beides nutzt, sollte auf 20+ gehen oder lieber auf MFA als primären Schutz setzen.

Die YAML-Migration in 2026.8 läuft automatisch durch. Den alten Block danach aus configuration.yaml entfernen. Wenn trusted_proxies in der UI danach fehlt, hilft ein Neustart.

Quellen: