Am letzten Sonntagabend gegen halb elf schrieb Malte, ein Softwareentwickler aus Bremen, den ich vor ein paar Jahren auf einer Konferenz kennengelernt hatte, eine Nachricht in einen Kanal, den wir beide zu selten benutzen. Sie bestand aus einem Screenshot und drei Wörtern: "Ich glaub ich brauch Hilfe." Der Screenshot zeigte sein Home-Assistant-Dashboard, oder das, was davon übrig war. Alle Automationen, die er über vier Jahre gebaut hatte, standen auf "deaktiviert", die zwei Aqara-Motion-Sensoren im Flur meldeten sich in einer Frequenz von etwa dreimal pro Sekunde als gelöscht und wieder angelegt, sein Heizungsplan war leer, und im Log stand seit zwölf Stunden ein und derselbe Eintrag: "Login attempt from 45.155.205.233 succeeded." Vierzig Sekunden vor der Meldung stand hundertsiebenundzwanzig Mal derselbe Log-Eintrag, nur mit "failed" am Ende. Jemand hatte sein Passwort gebruteforct, war reingekommen, und nutzte den Zugang seither, um Maltes Smart Home fernzusteuern.

Was Malte drei Wochen vorher gemacht hatte, ist die eine Sache, die in jedem Home-Assistant-Subreddit an mindestens einem Tag pro Woche als "einfache Lösung" auftaucht. Er wollte von unterwegs auf sein HA zugreifen. Er wollte kein Abo bei Nabu Casa. Er wollte keinen VPN einrichten, weil ihm das zu kompliziert klang. Also hat er in seiner Fritzbox 7590 unter "Internet, Freigaben, Portfreigaben" den Port 8123 seines Raspberry Pi 4 direkt ins Internet freigegeben, in der Reddit-Antwort mit den zweihundertneunundvierzig Upvotes hatte gestanden "just port forward 8123, it's fine, use a strong password". Malte hatte ein sechzehnstelliges Passwort verwendet, hatte 2FA nicht aktiviert weil "das Setup mit dem Google Authenticator ihn nervte", und war zufrieden gewesen, dass es funktionierte. Er konnte vom Fitnessstudio aus die Waschmaschine anschauen. Er fand das großartig.

Was er nicht wusste, und was auch die Reddit-Antwort ihm nicht gesagt hatte: sein Port 8123 wurde ab dem ersten Tag der Freigabe von automatisierten Scannern erfasst und in eine öffentlich durchsuchbare Datenbank eingetragen. Der Angreifer, der ihn drei Wochen später übernahm, hatte nicht mal einen exotischen Zero-Day benutzt. Er hatte einfach auf Shodan nach "port:8123" gesucht, in der Liste der neuen Einträge gescrollt, und Malte mit einem Passwort-Wörterbuch von rockyou.txt bearbeitet, bis eine der ersten paar hunderttausend Kombinationen passte. Der Angreifer saß wahrscheinlich in einem Rechenzentrum, das ihm dreißig Cent Strom pro Stunde kostete, hatte hundert Instanzen parallel laufen, und Malte war Nummer siebenundvierzig in seiner Warteschlange. Kein Drama. Kein Ziel. Nur Kollateral.

Ich habe Malte durch die nächsten zwölf Stunden begleitet: Router aus, HA komplett neu aufsetzen, aus dem Backup vom Wochenende zurückspielen, alle Passwörter drehen, Portfreigabe löschen, Wireguard einrichten. Danach habe ich ihm gesagt, dass er diesen Text lesen soll, sobald er live geht. Der folgende Text ist die lange Version der Antwort auf die Frage "warum ist eine Portfreigabe für Home Assistant so gefährlich, und was macht man stattdessen", die ich Malte an Sonntagabend um viertel vor zwölf mit einer Sprachnachricht angefangen habe zu erklären und die inzwischen über eine Stunde geworden ist. Wenn du gerade selbst darüber nachdenkst, deinen HA-Port ins Netz freizugeben, oder wenn du das schon getan hast: bleib hier.

Warum Port 8123 ausgerechnet dieser Port ist

Home Assistant hört auf Port 8123. Das war schon 2013 so, als Paulus Schoutsen die ersten Zeilen Python geschrieben hat, und daran hat sich nichts geändert. Der Port ist offiziell keinem IANA-Standard-Dienst zugeordnet, was gut ist, weil es keine Kollision mit einem etablierten Protokoll gibt. Er ist aber trotzdem eindeutig als Home-Assistant-Port erkennbar, weil jeder HA-Server auf einer HTTP-Anfrage an /manifest.json mit einem sehr charakteristischen JSON antwortet, in dem "name": "Home Assistant" steht. Suchmaschinen wie Shodan, Censys oder FOFA fragen genau diesen Endpunkt regelmäßig ab und markieren jeden Server, der die passende Signatur zurückgibt, in ihrer Datenbank als "Home Assistant". (AccessChecker zu Port 8123, Shodan-Suche home_assistant)

Was das praktisch heißt, hat ein Community-Post im Home-Assistant-Forum aus 2021 mit einer nüchternen Zahl zusammengefasst. Zu dem Zeitpunkt fand Shodan knapp achtzigtausend Home-Assistant-Instanzen mit unverschlüsselter HTTP-Verbindung direkt am öffentlichen Port 8123. (Home Assistant Community: Security through obscurity isnt a good strategy) Andere Zählungen aus derselben Zeit sprachen von sechsunddreißigtausend Servern ohne TLS-Zertifikat, jeweils mit dem Login-Screen von HA als erstes Element auf der Startseite. (DEW IT & Web Services: Setting Home Assistant up for Secure access over the Internet) Ein aktueller Beitrag von 2026 nennt inzwischen mehr als hundertdreißigtausend öffentlich erreichbare Home-Assistant-Instanzen weltweit. (GitHub Security Lab: Securing our home labs Home Assistant code review) Jeder einzelne dieser Server ist mit einem Suchbefehl in unter drei Sekunden für jeden auffindbar, der einen Shodan-Account hat, und die Free-Version reicht dafür.

Shodan selbst scannt seit 2013 kontinuierlich den kompletten IPv4-Adressraum. Untersuchungen zeigen, dass neu ans Internet angeschlossene Geräte innerhalb von etwa vierzehn Tagen in der Datenbank landen, in vielen Fällen viel schneller. (arXiv: Scan-Based Analysis of Internet-Exposed IoT Devices Using Shodan Data, Vectra AI: How Attackers Use Shodan and FOFA) Wenn du morgen früh eine Portfreigabe auf Port 8123 einrichtest, ist dein Server in der zweiten Woche mit hoher Wahrscheinlichkeit für jeden Angreifer, der weiß wo er suchen muss, mit einem Klick sichtbar. Und Home Assistant ist ein sehr sichtbares Ziel, weil die Community groß, die Dokumentation offen, und die Angriffsfläche für Menschen mit bösen Absichten damit gut erforscht ist.

Was schiefgeht, wenn jemand reinkommt

Maltes Fall war vergleichsweise harmlos. Der Angreifer hat Automationen umgeschrieben und die Sensoren mit einer Art digitalem Trotzanfall belegt, aber er hat nichts wirklich Kritisches gemacht. In anderen Fällen sieht das anders aus, und die Frage ist immer, was du eigentlich alles an HA angebunden hast.

Ein kompromittierter HA-Server gibt einem Angreifer zunächst einmal die vollständige Sicht auf alles, was in deinem Smart Home passiert. Er sieht die Namen und aktuellen Zustände aller Geräte, kann Historien in der Recorder-Datenbank auslesen und damit rekonstruieren, wann du morgens aufstehst, wann du das Haus verlässt, wann die Kinder von der Schule kommen. Er sieht deine Automationen und weiß dadurch, welche Sensoren für die Anwesenheitserkennung genutzt werden und wie du sie manipulieren kann, um dem Rest der Automatisierung vorzumachen, dass niemand zuhause ist. In Kombination mit deiner in HA hinterlegten Home-Zone (die im Setup abgefragt wird und die Adresse deiner Wohnung als Koordinate enthält) hat er damit ein sehr genaues Bild davon, wo du wohnst und wann du dort nicht bist.

Wenn du Smart Locks angebunden hast, kann er sie öffnen. Nuki, Yale Assure, Danalock, alle diese Modelle bieten HA-Integrationen mit voller Steuerung. Wenn du Reolink- oder Eufy-Kameras integriert hast, sieht er sie live. Wenn du eine Alarmanlage wie Ajax oder DoorBird per HA scharf und unscharf schaltest, kann er sie deaktivieren. Ein Community-Post im Home-Assistant-Forum aus 2024 beschreibt genau diese Kaskade an einem Beispiel, in dem ein Angreifer nach Kompromittierung des HA-Zugangs die Haustür geöffnet und die Kameras deaktiviert hat. (Home Assistant Community: I shut down my HA after many intrusion attempts)

Der zweite und längerfristige Effekt ist die Persistenz. Home Assistant erlaubt es, Shell-Kommandos auf dem Host auszuführen, Add-ons zu installieren, Custom Integrationen über HACS zu laden. Wer als Admin drin ist, kann sich einen SSH-Daemon nachinstallieren, einen Reverse-Shell-Cron eintragen, oder eine Ransomware-Payload nachladen, die deine gesamte HA-Konfiguration verschlüsselt. Ein Bericht im IoT-For-All-Magazin aus 2024 beschreibt, wie eine Ransomware-Attacke auf ein Smart Home aussehen würde: der Angreifer setzt die Heizung im Winter auf zweiunddreissig Grad, deaktiviert alle Steuerungen und schickt eine Nachricht in Bitcoin. (IoT For All: What Would a Ransomware Attack on Your Smart Home Look Like) Was 2020 noch theoretisches Szenario war, ist inzwischen dokumentiert: das Wiener Romantik-Seehotel Jägerwirt war einer der ersten offentlich bekannten Fälle, bei denen ein Angreifer über die Smart-Lock-Steuerung Gäste aussperrte und Lösegeld verlangte. (Fortune: Hackers Hijack Hotels Smart Locks)

Der dritte Effekt, der oft vergessen wird: dein HA-Server ist typischerweise ein Raspberry Pi oder ein Mini-PC, der im gleichen Heimnetz wie deine Laptops, Smartphones, das NAS und die Homebanking-Session steht. Ein Angreifer mit Shell-Zugriff auf den Pi kann von dort aus laterale Bewegungen ins Heimnetz machen, das NAS scannen, Malware auf freigegebene SMB-Shares werfen, den DNS des Netzwerks umleiten. Dein HA-Server ist die Eintrittstür, aber das eigentliche Haus dahinter ist viel größer.

Was HA von Haus aus kann und was nicht

Man könnte jetzt argumentieren: Home Assistant hat doch Login, hat doch mit ip_ban_enabled sogar einen eingebauten Schutz gegen Brute-Force. Warum reicht das nicht? Weil die eingebauten Mittel ausdrücklich nicht dafür designed wurden, ein aus dem Internet direkt erreichbares Web-Interface zu schützen, und weil sie an mehreren Stellen Lücken haben, die im Kontext einer echten Portfreigabe schmerzen.

Home Assistant hat ein IP-Ban-Feature. Aktivieren muss man es explizit in der configuration.yaml unter http.ip_ban_enabled: true, dazu setzt man http.login_attempts_threshold zum Beispiel auf zehn, und nach zehn fehlgeschlagenen Login-Versuchen von derselben IP wird diese in ip_bans.yaml eingetragen und blockiert. (Home Assistant HTTP-Integration Doku) Das ist besser als nichts, hat aber drei Probleme, die die Community regelmäßig beschreibt. Erstens ist der Ban standardmäßig permanent, was zu Selbst-Aussperr-Fällen führt, wenn man aus dem Home-Netz mit dem falschen Password fehlklickt. Zweitens gibt es keine standardmäßige Benachrichtigung, wenn ein Ban ausgelöst wird, man muss sich selbst eine Automation dafür bauen. (Home Assistant Community: Banned ip notification) Drittens, und das ist am schmerzhaftesten, sitzen viele Angreifer hinter Botnets mit tausenden IPs, sodass ein einzelner IP-Ban den Angriff nur um Sekunden verzögert.

Home Assistant hat außerdem eine Multi-Faktor-Authentifizierung über TOTP, kompatibel mit Google Authenticator, Authy oder 2FAS. Sie ist konfigurationsseitig eingebaut, muss aber jeder Benutzer aktiv für sich selbst aktivieren unter "Sicherheit, Zwei-Faktor-Authentifizierung". (Home Assistant Doku: Multi-factor authentication, Home Assistant Developer Docs: MFA modules) Ich schätze, dass unter allen HA-Nutzern der Anteil derer, die 2FA aktiv nutzen, deutlich unter zwanzig Prozent liegt, und unter denen mit Portfreigabe wahrscheinlich noch niedriger, weil die Nutzergruppe, die auf "einfacher Fernzugriff" optimiert, in der Regel eben nicht "und dann auch noch bei jedem Login den TOTP-Code tippen" akzeptiert.

Was HA nicht hat: eine standardmäßig aktivierte Rate-Limitierung für Login-Versuche. Ohne ip_ban kannst du in Home Assistant zehntausend Login-Versuche pro Minute pro IP-Adresse machen, ohne dass etwas passiert außer einträgen im Log. HA hat keinen eingebauten Captcha, kein Adaptive-Auth, kein Behavioural-Analysis. HA hat kein natives HTTPS, wenn du kein Reverse-Proxy oder keine Zertifikat-Datei explizit konfigurierst. HA lässt sein Login-Formular per HTTP ausliefern, mit der Konsequenz, dass ein direkter Portfreigabe-Nutzer sein Passwort im Klartext über das öffentliche Internet schickt, sobald er sich einmal von unterwegs anmeldet. Das war einer der Hauptkritikpunkte in der genannten Community-Analyse: jedesmal wenn du dich remote einloggst, waren deine Zugangsdaten im Klartext auf der Leitung.

Historische CVE-Landschaft: was Angreifer in HA gefunden haben

Home Assistant ist Open Source, was viele Vorteile hat, unter anderem den, dass Sicherheitslücken öffentlich diskutiert und dokumentiert werden. Die CVE-Datenbanken zeigen für Home Assistant selbst und das umgebende Ökosystem eine kontinuierliche Reihe von Findings, die im Laufe der letzten Jahre entdeckt und gefixt wurden. Wer seinen HA-Server ohne zusätzliche Schutzschicht ins Internet stellt, ist von jedem dieser CVEs abhängig davon, ob er rechtzeitig gepatcht hat. Beim nächsten Zero-Day wird er es nicht rechtzeitig sein.

Ein Beispiel, das die Größenordnung zeigt: 2020 fand die Sicherheitsfirma elttam eine Remote-Code-Execution-Schwachstelle in der Supervisor-Integration, die es einem nicht authentifizierten Angreifer erlaubte, beliebige Kommandos auf dem HA-Host auszuführen. Zum Zeitpunkt der Entdeckung gab es rund einhundertdreißigtausend öffentlich erreichbare HA-Instanzen weltweit, die alle betroffen waren. Der elttam-Blogbeitrag beschreibt den Angriffsweg im Detail und lässt wenig Raum für Missverständnisse: wer den HA-Web-Port ins Internet freigab, war zwischen Entdeckung und Patch komplett schutzlos. (elttam: PwnAssistant Controlling homes via a Home Assistant RCE)

2023 fand ein Forscher CVE-2023-41893, einen Account-Takeover-Bug im auth_callback-Flow, bei dem die redirect_uri und client_id manipulierbar waren, sodass ein Angreifer nach einem einzigen Klick des Opfers einen gültigen Access-Token abgreifen konnte. (GitLab Advisories: CVE-2023-41893, OSV: PYSEC-2023-214) Der Angriff funktionierte primär gegen Instanzen, die aus dem Internet erreichbar waren, weil der Angreifer den erbeuteten Token nur dann sinnvoll nutzen konnte, wenn er die HA-Instanz auch von außen ansprechen konnte.

2024 folgte eine CVSS-9.6-Lücke unter CVE-2026-34205, die es unauthentifizierten Nutzern im lokalen Netzwerk erlaubte, auf interne Endpunkte zuzugreifen, insbesondere wenn HA im Docker-Host-Netzwerkmodus lief. (The Hacker Wire: CVE-2026-34205) In Kombination mit einer Portfreigabe wird "lokales Netzwerk" schnell zu "ganz Internet".

2026 kam CVE-2026-40602, ein Code-Injection-Bug in der Command-Line-Integration hass-cli, bei dem eine ungesandbxte Jinja2-Umgebung Angreifer mit lokalem Zugriff Python-Code ausführen liess. (SentinelOne: CVE-2026-40602) Und ebenfalls 2026 wurde CVE-2026-44698 bekannt, eine RCE in den HA-Companion-Apps für iOS und Android, bei der cross-origin iframes JavaScript im Frontend ausführen und Access-Tokens exfiltrieren konnten. (SentinelOne: CVE-2026-44698, heise: Home Assistant Smartphone apps allow takeover by attackers) Die vollständige Liste an Home-Assistant-CVEs bei cvedetails.com zeigt einen dauerhaften Strom ähnlicher Findings; sie ist nicht katastrophal, aber auch nicht leer. (cvedetails: Home Assistant Vulnerabilities)

Wichtig zu verstehen: keine dieser CVEs bedeutet, dass HA schlecht programmiert ist. Sie zeigen nur, dass jede komplexe Software Sicherheitslücken hat, dass diese entdeckt werden, dass sie gefixt werden, und dass der Zeitraum zwischen der ersten Ausnutzung durch einen Angreifer und dem Patch beim Endnutzer immer nicht null ist. Wenn dein HA-Port ins Internet zeigt, bist du bei jedem neuen CVE die Zielscheibe. Wenn er hinter einem VPN sitzt, bist du es nicht.

Wo OWASP ins Spiel kommt

Das Open Web Application Security Project pflegt seit 2003 die "OWASP Top 10", eine Liste der zehn häufigsten Ursachen für Kompromittierungen von Webapplikationen. In der 2021er Version (die aktuelle Version, an der aktuell die 2027er-Aktualisierung erarbeitet wird) steht auf Platz eins "Broken Access Control", auf Platz sieben "Identification and Authentication Failures". (OWASP Top 10 2021, OWASP A07 Identification and Authentication Failures) Beide Kategorien greifen bei einer nackten HA-Portfreigabe: die Zugriffskontrolle besteht aus einem Passwort ohne Rate-Limit, und die Authentifizierung ist ohne aktiviertes 2FA anfällig für Brute-Force und Credential-Stuffing.

Das ist keine akademische Beobachtung. Wenn du Maltes Bruteforce-Angriff durch die OWASP-Brille liest, siehst du buchstäblich Punkt sieben: Identification and Authentication Failures, konkret "Permits brute force or other automated attacks", "Permits default, weak, or well-known passwords", "Has ineffective credential recovery and forgot-password processes". HA hat gegen die ersten beiden nur den optionalen ip_ban, der wie oben beschrieben Botnets nicht stoppt. HA-Endnutzer machen die dritte Kategorie oft selbst kaputt, weil sie für den "einmalige Zugriff von unterwegs, ist doch bloß die Waschmaschine"-Fall keine sinnvollen Passwort-Manager verwenden.

Wenn du unbedingt Portfreigabe machen willst: der ehrliche Weg

Es gibt sehr wenige Fälle, in denen eine Portfreigabe wirklich Sinn ergibt. Der häufigste: du hast einen sehr großen Haushalt oder eine WG mit sechs Mitbewohnern, du willst nicht sechs VPN-Konfigurationen verwalten, und du willst gleichzeitig externe Voice-Assistants wie Google Home oder Alexa an HA anbinden, was ohne öffentliche Erreichbarkeit deiner HA-Instanz nicht funktioniert. In diesen Fällen musst du eine Portfreigabe machen, weil weder VPN noch Nabu Casa alle Anforderungen erfüllen (letzteres kann Google und Alexa, aber die WG mag den Umweg über die Nabu-Casa-URL vielleicht nicht). Wenn du in dieser Situation bist: dann bitte richtig.

Der ehrliche Weg besteht aus mindestens fünf Schichten, keine davon ist optional.

Erste Schicht, TLS-Zertifikat von Let's Encrypt. Kein selbst-signiertes Zertifikat, weil Browser dann Warnungen anzeigen, die deine Nutzer wegklicken und damit für Man-in-the-Middle-Angriffe empfänglich werden. Let's Encrypt liefert kostenlose Zertifikate mit ninety-tage-Lifetime, automatische Erneuerung ist Pflicht. Idealer Weg über ein DNS-Challenge, weil das ohne Port 80-Freigabe funktioniert. Zweite Schicht, Reverse Proxy. Nginx oder Caddy setzt sich als eigenständiger Prozess vor HA, terminiert TLS, leitet nur validierte Anfragen weiter. Caddy ist für Home-Setups der pragmatischere Weg, weil es Let's-Encrypt komplett automatisiert; nach einem kurzen Caddyfile mit reverse_proxy 192.168.178.42:8123 läuft alles inklusive Zertifikat-Renewal von allein. (Caddy Reverse Proxy Doku Home Assistant, Nginx Reverse Proxy Guide für Home Assistant) Wichtig: HA muss unter http.use_x_forwarded_for: true und http.trusted_proxies wissen, dass es hinter einem Proxy sitzt, sonst siehst du in allen Logs nur die Proxy-IP und der ip_ban wirkt gegen falsche Adressen. Dritte Schicht, Basic-Auth vor dem HA-Login. Auf dem Reverse-Proxy schaltest du eine HTTP-Basic-Authentication davor, mit einem eigenen Benutzernamen und Passwort. Wer die HA-Login-Seite überhaupt sehen will, muss vorher diese zweite Hürde nehmen. Das kostet dich zwei Zeilen im Caddyfile und stoppt alle automatisierten Scanner, weil sie an der ersten Hürde hängen bleiben und nicht wissen, dass da HA dahinter steckt. Basic-Auth ist keine hohe Sicherheit für sich, aber als vorgeschaltete Barriere gegen Massen-Scans sehr effektiv. Vierte Schicht, Fail2Ban. Home Assistant hat eine offizielle Fail2Ban-Integration, die Log-Zeilen so formatiert, dass sie vom Fail2Ban-Dienst auf dem Host geparst werden können. (Home Assistant Fail2Ban-Integration) Auf dem Reverse-Proxy lässt du Fail2Ban parallel gegen die Nginx- oder Caddy-Access-Logs laufen und blockierst IPs, die zu viele 401-Antworten produzieren, per iptables auf Netzwerkebene. Ergebnis: ein Angreifer bekommt nach zehn fehlgeschlagenen Versuchen für eine Stunde keinen einzigen weiteren TCP-Handshake zu deinem Server. (Home Assistant Community: NGINX reverse proxy and fail2ban) Wichtig, wie oben erwähnt: der Proxy muss X-Real-IP und X-Forwarded-For korrekt setzen, sonst blockt Fail2Ban die IP des Nginx-Containers und lockt den echten Angreifer weiter durch. Fünfte Schicht, 2FA für jeden HA-Benutzer. Nicht optional. Jeder Account braucht TOTP aktiviert, idealer Weise mit einem Authenticator, dessen Secrets nicht in der Cloud liegen (also 2FAS oder Aegis, nicht Authy). (2Stable Authenticator Home Assistant) Wenn ein Angreifer trotz Basic-Auth und Fail2Ban an den HA-Login kommt, muss er trotzdem noch einen zweiten Faktor knacken, den er nicht über Wireshark abfangen kann.

Wer diese fünf Schichten sauber baut und betreut, ist reasonably safe. Der Aufwand liegt bei drei bis vier Stunden Erstinstallation, wenn man sich damit auskennt, und bei etwa einer Stunde pro Monat Wartung für Zertifikate, Log-Reviews und Update-Zyklen. Für die allermeisten HA-Nutzer ist das ein absurd hoher Preis für "ich will von unterwegs meine Waschmaschine sehen". Die Alternative ist praktisch immer besser.

Warum Wireguard einfacher und sicherer ist

An diesem Punkt kommt der Artikel zurück zu meinem Text über Wireguard auf der Fritzbox, den es seit Juni 2026 hier auf Technikheim gibt. (Artikel 084: Wireguard Fritzbox Home Assistant) Die Kurzfassung für alle, die dort noch nicht waren: Wireguard ist ein VPN-Protokoll, seit FRITZ!OS 7.50 direkt in der Fritzbox eingebaut, kein Cloud-Konto notwendig, kein Add-on. Du legst in der Fritzbox einen Wireguard-Peer an, scannst mit deinem Smartphone einen QR-Code, und ab da bist du von unterwegs im Heimnetz wie am Küchentisch. HA läuft weiterhin lokal-only auf http://homeassistant.local:8123, keine Portfreigabe, kein Zertifikat, kein Fail2Ban, kein Reverse-Proxy. Setup-Zeit: fünfzehn Minuten.

Der Sicherheitsvergleich ist eindeutig. Ein offener Port 443 mit Reverse-Proxy antwortet auf jeden TCP-Handshake und lässt Angreifer wissen, dass da ein Web-Server ist. Selbst wenn dahinter Basic-Auth und Fail2Ban stehen, hat der Angreifer immer einen ersten Kontaktpunkt. Ein Wireguard-Endpoint auf einem UDP-Port reagiert auf Pakete, die nicht den richtigen Cryptokey mitbringen, schlicht gar nicht. Für Port-Scanner ist der Port geschlossen. Der Angreifer bekommt weder ein Banner noch ein Timeout, sondern nur Stille. (SmartHomeScene: Home Assistant Remote Access Best Methods, heise: Home Assistant Fernzugriff kostenlos mit Tailscale einrichten)

Der Wartungsaufwand ist ebenfalls dramatisch niedriger. Ein Reverse-Proxy braucht Zertifikat-Renewals, Nginx-Updates, Fail2Ban-Log-Reviews, IP-Ban-Verwaltung. Wireguard auf der Fritzbox braucht: nichts. FRITZ!OS-Update kommt automatisch, die Wireguard-Konfiguration ändert sich nicht, die einzige Aktion ist alle paar Monate mal auf "Verbindung testen" klicken und darauf achten, ob deine Frau ein neues Smartphone braucht (dann neuen Peer anlegen).

Die Auswirkung auf die Angriffsfläche ist noch dramatischer. Bei Wireguard kann ein Angreifer selbst mit einem hypothetischen Zero-Day in Home Assistant deinen HA gar nicht angreifen, weil der HA-Web-Port nie das Heimnetz verlässt. Der Zero-Day braucht Netzwerk-Zugriff auf Port 8123. Ohne Portfreigabe hat er den nicht. Ohne den hat er nichts. Das ist die eigentliche Aussage von Defense-in-Depth: die beste Verteidigung gegen Sicherheitslücken ist, das verwundbare System gar nicht erst erreichbar zu machen.

Wann Wireguard nicht reicht: Voice-Assistants und Multi-User

Zwei Fälle, in denen Wireguard alleine nicht ausreicht.

Erster Fall, du willst Alexa oder Google Assistant an HA anbinden. Die HA-Skills für diese Voice-Assistants brauchen eine öffentlich erreichbare HTTPS-URL, damit Amazon und Google beim Auftrag "Wohnzimmerlicht an" eine Anfrage zu deinem HA schicken können. Wireguard hilft hier nicht, weil der Amazon-Server keinen Wireguard-Peer auf deiner Fritzbox konfiguriert hat. In diesem Fall ist Nabu Casa die naheliegende Lösung, weil sie die Skills bereits integriert hat und alle Backend-Details für dich übernimmt. Zweiter Fall, du willst mehreren Familienmitgliedern oder Mitbewohnern Zugang geben. Hier ist Wireguard technisch möglich (bis zu sechzig Peers pro Fritzbox), aber die Nutzer-Erfahrung ist mäßig: jeder muss die Wireguard-App installieren, jeder muss den Tunnel manuell aktivieren, jedes neue Gerät braucht einen neuen Peer. Für Ehepaare geht das noch, für WGs mit Fluktuation wird es mühsam. Nabu Casa ist hier die einfachere Lösung.

Nabu Casa kostet Stand August 2026 6,50 Euro pro Monat oder 65 Euro pro Jahr (die Preise wurden im Frühjahr 2026 leicht erhöht) und finanziert direkt die Entwicklung von Home Assistant selbst. (Home Assistant Cloud offizielle Seite, Frigi Guide: 2026 Guide Remote Access Home Assistant) Der Datenverkehr läuft über Nabu-Casa-Server in den USA, was für manche ein Ausschlusskriterium ist, aber im Vergleich zu einer offenen Portfreigabe drastisch sicherer. Die Alexa- und Google-Home-Skills funktionieren aus der Box, ohne dass du dich mit Skill-Registrierung, HTTPS-Endpunkten oder Amazon-Developer-Konten beschäftigen musst.

Wer Nabu Casa nicht will, aber Voice-Assistants trotzdem braucht, hat als dritte Option Cloudflare Tunnel. Cloudflare bietet mit dem cloudflared-Daemon eine Lösung, bei der ein ausgehender Tunnel von deinem HA-Server zu Cloudflare aufgebaut wird und Cloudflare als Reverse-Proxy für eine deiner eigenen Domains fungiert. Zusammen mit Cloudflare-Access (früher "Cloudflare Zero Trust", inzwischen umbenannt) kannst du eine Authentifizierung auf Cloudflare-Ebene vorschalten, die zum Beispiel Google-Login voraussetzt, bevor der Nutzer überhaupt die HA-Login-Seite sieht. (Pi My Life Up: Cloudflare Tunnel on Home Assistant, empty.coffee: Securing Home Assistant with Cloudflare Zero Trust, Chris Arcand: Zero Trust Securely Accessing Home Assistant with Cloudflare Tunnels) Cloudflare Tunnel ist kostenlos, funktioniert ohne CGNAT-Probleme (der Tunnel wird von deiner Seite aus initiiert) und ist im Sicherheitsniveau vergleichbar mit Nabu Casa, aber ohne monatliche Kosten. Der Preis: Setup-Aufwand von etwa einer Stunde, eigene Domain bei Cloudflare notwendig, laufende Wartung des cloudflared-Add-ons.

Wie du eine bestehende Portfreigabe wieder loswirst

Wenn du diesen Artikel gelesen hast und feststellst, dass du selbst gerade eine offene Portfreigabe auf HA hast: hier die Reihenfolge, in der du das zurückbaust.

Schritt eins, sofort die Portfreigabe deaktivieren. Ins Fritzbox-Menü unter Internet, Freigaben, Portfreigaben, den Eintrag für den HA-Server suchen (der auf Port 8123 oder Port 443 verweist), Haken raus, Übernehmen. Damit ist der Server ab der nächsten Minute nicht mehr aus dem Internet erreichbar. Das ist die wichtigste Aktion. Schritt zwei, Passwörter drehen. Alle HA-Benutzer, Passwörter ändern. Auch wenn du keine Anzeichen für eine Kompromittierung siehst: wenn die Portfreigabe länger als zwei Wochen offen war, ist die Wahrscheinlichkeit für einen erfolgreichen Bruteforce-Versuch nicht null. Schritt drei, ip_bans.yaml prüfen. Datei liegt im HA-config-Verzeichnis. Wenn dort Einträge drin sind, hat schon jemand versucht, sich bei dir einzuloggen. Bei drei bis fünf Einträgen ist das das normale Grundrauschen des Internets. Bei einer längeren Liste hattest du echten Angriffsdruck. Schritt vier, Audit-Log der HA-Benutzer prüfen. Unter Einstellungen, Personen, siehst du für jeden Nutzer den letzten Login-Zeitpunkt. Wenn dort etwas steht, das du nicht warst, hattest du einen erfolgreichen Einbruch. Dann: HA komplett aus dem Backup vor der Portfreigabe wiederherstellen, alle Automationen manuell durchgehen, alle Add-ons deinstallieren und neu installieren, alle Integrationen löschen und neu einrichten, alle Passwörter, API-Keys und Access-Tokens rotieren. Das ist mühsam, aber es ist der einzige Weg, sicherzugehen, dass keine Persistenz zurückbleibt. Schritt fünf, Wireguard einrichten. Nachdem der Notfall abgearbeitet ist, hast du Zeit, den geordneten Weg zu bauen. Wireguard auf der Fritzbox, wie in dem gleichnamigen Technikheim-Artikel beschrieben, ist für die allermeisten Setups der richtige Ansatz.

Was Malte drei Wochen später dachte

Malte hat am Sonntagabend nach unserem Gespräch alles gemacht, was auf der Liste stand. Portfreigabe gelöscht, HA aus dem Backup vom Freitag zurückgespielt, Wireguard eingerichtet. Er hat sich zwei Tage lang geärgert, dass er nicht schon vorher darauf gekommen ist, hat dann seiner Frau erklärt, wieso sie jetzt eine Wireguard-App auf ihrem Handy braucht, und die nächsten zwei Wochen verlaufen ohne Zwischenfälle.

Was er mir vor drei Tagen geschrieben hat: "das Wireguard-Setup war zehn Minuten. Wieso habe ich das nicht sofort so gemacht?" Die Antwort ist, dass er die einfache Lösung gesucht und die falsche Antwort auf Reddit gefunden hatte. Dass das Reddit-Posting mit den zweihundertneunundvierzig Upvotes seit inzwischen sechs Jahren online steht, ohne dass ein Moderator ein Warnhinweis dransetzt, ist ein systemisches Problem der Community. Die HA-Doku ist an dieser Stelle sehr klar: "Do not enable the Home Assistant frontend or API to the internet without additional security". (Home Assistant Doku: Securing your Home Assistant, Home Assistant Doku: Remote access) Aber die Doku liest niemand, der auf Reddit die eine Antwort mit den Upvotes findet.

Für alle, die jetzt vor derselben Entscheidung stehen wie Malte damals, hier die Empfehlung in einem Absatz. Für neunundneunzig Prozent der HA-Nutzer ist Wireguard auf der Fritzbox die richtige Lösung, kostenlos, sicher, ohne Wartungsaufwand, für die Details siehe der entsprechende Artikel hier auf Technikheim. Wer Voice-Assistants wie Alexa oder Google will, kann entweder 6,50 Euro pro Monat für Nabu Casa zahlen und die Lösung mit den geringsten Reibungsverlusten kaufen, oder mit etwa einer Stunde Setup Cloudflare Tunnel plus Cloudflare Access kostenlos aufsetzen. Wer aus sehr spezifischen Gründen eine echte Portfreigabe braucht (große WG, mehrere externe Nutzer, keine VPN-App auf den Geräten möglich), muss bereit sein, den vollen Fünf-Schichten-Stack aus TLS, Reverse-Proxy, Basic-Auth, Fail2Ban und 2FA zu bauen und zu pflegen. Wer diese Bereitschaft nicht mitbringt, aber trotzdem "einfach mal den Port 8123 aufmacht", macht Maltes Fehler von vor drei Wochen und wartet, bis er den Anruf bekommt.

Es gibt selten technische Entscheidungen im Smart Home, bei denen die Sicherheitslücke so groß und die Alternative so gut ist. Portfreigabe für HA gehört dazu. Mach es nicht.