Home Lab Security: Härten deiner Home Assistant & N8N Umgebung

Home Lab Security: Härten deiner Home Assistant & N8N Umgebung nach Best Practices

Servus, liebe Home-Lab-Enthusiasten und Admins! Als alter Hase, der seit Jahren seine Finger in Proxmox, Docker, Home Assistant und N8N hat, weiß ich, wie schnell man im Eifer des Gefechts die Sicherheit aus den Augen verlieren kann. Wir bauen uns unsere kleinen Imperien auf, und ehe wir uns versehen, sind da dutzende Dienste, Container und Automatisierungen, die potenziell angreifbar sind.

Der heise-Artikel zum iX-Workshop über Industrial Security nach IEC 62443 hat mich kürzlich nachdenklich gemacht. Klar, industrielle Steuerungssysteme sind eine ganz andere Liga als unser Home Lab. Aber die Prinzipien dahinter – von Anfang an Sicherheit mitzudenken, Risiken zu bewerten und eine Defense-in-Depth-Strategie zu fahren – sind universell. Warum sollten wir das nicht auch auf unsere Heimautomatisierung übertragen? Schließlich steuern Home Assistant und N8N bei vielen von uns nicht nur Lichter, sondern auch Heizungen, Schlösser und Überwachungskameras. Das sind "Automatisierungs- und Steuerungssysteme" im Kleinformat, und ihre Sicherheit ist alles andere als trivial.

In diesem Guide zeige ich dir, wie ich meine Home Assistant und N8N Umgebungen härte, inspiriert von den Gedanken zur strukturierten Sicherheit. Es geht darum, nicht nur schnell etwas zum Laufen zu bringen, sondern es auch robust und sicher zu betreiben. Glaub mir, ein einmaliger Aufwand am Anfang erspart dir unzählige schlaflose Nächte und Datenverluste später.

Voraussetzungen – Dein Werkzeugkasten

Bevor wir loslegen, lass uns sicherstellen, dass wir auf derselben Seite sind. Dieser Guide richtet sich an dich, wenn du bereits ein solides Fundament im Home Lab hast. Du solltest Folgendes mitbringen:

Einen Proxmox-Server als Basis für deine VMs und LXCs.
Grundlegende Kenntnisse im Umgang mit Linux-Shell (SSH, Befehle wie apt, systemctl, nano/vi).
Docker und Docker Compose sind dir vertraut. Du kannst Container starten, stoppen und verwalten.
Home Assistant und N8N sind bei dir bereits in irgendeiner Form installiert oder du planst es. Idealerweise in Docker-Containern oder LXCs.
Ein grundlegendes Verständnis von Netzwerktechnik, insbesondere IP-Adressen, Subnetze und idealerweise VLANs. Wenn du einen Router hast, der VLANs oder zumindest separate Netze für IoT und Management bietet, ist das ein riesiger Vorteil.
SSH-Zugang zu deinem Proxmox-Host und den relevanten VMs/LXC-Containern.
Backups deiner aktuellen Konfigurationen! Das ist mein wichtigster Tipp überhaupt, bevor du größere Änderungen vornimmst.

Schritt-für-Schritt-Anleitung: Dein Home Lab sicher aufbauen

1. Netzwerksegmentierung – Trennung ist Trumpf

In der industriellen Sicherheit ist die Zonierung und Segmentierung des Netzwerks ein Grundpfeiler. Warum sollte das im Home Lab anders sein? Wenn dein smartes Licht gehackt wird, willst du nicht, dass der Angreifer direkten Zugriff auf deinen Proxmox-Host oder deine Finanzdaten hat. Ich segmentiere mein Netzwerk in der Regel wie folgt:

Management-Netz: Für Proxmox, NAS, Router-Management. Hier haben nur vertrauenswürdige Geräte und Admins Zugriff.
Service-Netz: Für "normale" Serverdienste wie Nextcloud, Plex, etc.
IoT-Netz: Für alle Smart-Home-Geräte, Home Assistant, N8N. Dieses Netz ist am stärksten isoliert.
Gäste-Netz: Klar, für Gäste.

Die Umsetzung erfolgt über VLANs auf deinem Router und/oder managed Switches. Jedes VLAN bekommt ein eigenes Subnetz. Dann definierst du Firewall-Regeln, welche Netze miteinander kommunizieren dürfen und welche Ports offen sind.

Mein Tipp: Starte mit der restriktivsten Regel (alles blockieren) und öffne dann nur die Ports und Verbindungen, die absolut notwendig sind. Für Home Assistant bedeutet das zum Beispiel, dass das IoT-Netzwerk Zugriff auf den Home Assistant-Port (meist 8123) haben muss, aber Home Assistant selbst vielleicht nur auf bestimmte Cloud-Dienste oder lokale IoT-Geräte zugreifen darf.

# Beispiel (vereinfacht) für eine UFW-Regel auf einem Linux-Host,
# der Home Assistant hostet und im IoT-Netzwerk ist (z.B. 192.168.30.0/24)
# Erlaube eingehenden Traffic auf Port 8123 (Home Assistant UI) nur aus dem IoT-Netz
sudo ufw allow proto tcp from 192.168.30.0/24 to any port 8123 comment 'Allow Home Assistant UI from IoT network'

# Erlaube ausgehenden Traffic für DNS (wichtig für Updates und externe Dienste)
sudo ufw allow out proto udp to any port 53 comment 'Allow DNS resolution'

# Erlaube ausgehenden Traffic für NTP (Zeitsynchronisation)
sudo ufw allow out proto udp to any port 123 comment 'Allow NTP'

# Denk daran, deine spezifischen Integrations-Ports zu öffnen!
# Zum Beispiel für MQTT-Broker im gleichen Netz
# sudo ufw allow out proto tcp to 192.168.30.X port 1883 comment 'Allow MQTT to Broker'

sudo ufw enable
sudo ufw status verbose

Für Proxmox selbst solltest du die Firewall im Webinterface nutzen, um den Zugriff auf die Management-Ports (8006, 22) ebenfalls nur von deinem Management-Netz zu erlauben.

2. Container-Sicherheit – Docker mit Bedacht

Die meisten von uns betreiben Home Assistant und N8N in Docker-Containern. Das ist super, aber auch hier gibt es Fallstricke.

a) Non-Root-Benutzer in Containern

Einer der häufigsten Fehler ist, Container als Root laufen zu lassen. Wenn ein Angreifer Code im Container ausführen kann, hat er sofort Root-Rechte *im Container*. Mit einigen Exploits kann er dann eventuell auch aus dem Container ausbrechen und Root auf dem Host erlangen. Daher: Wenn möglich, führe deine Container mit einem dedizierten, nicht-privilegierten Benutzer aus.

Viele offizielle Docker-Images erlauben es, die User-ID (UID) und Group-ID (GID) zu setzen. Prüfe die Dokumentation des Images. Ich nutze dafür gerne PUID und PGID Umgebungsvariablen.

b) Ressourcengrenzen

Setze Limits für CPU und RAM. Das schützt deinen Host davor, dass ein fehlerhafter oder kompromittierter Container den gesamten Server lahmlegt.

c) Volume Mounts mit Bedacht

Mounte nur die Verzeichnisse, die der Container *wirklich* benötigt, und das mit den minimal notwendigen Berechtigungen (read-only, wenn möglich). Prüfe die Dateiberechtigungen auf dem Host für die gemounteten Verzeichnisse – der User im Container braucht entsprechende Rechte.

d) Netzwerkmodi

Nutze den Standard-Bridge-Modus, es sei denn, du brauchst unbedingt host-Netzwerk (was ich für HA/N8N meist vermeide). Wenn du eine dedizierte IP im IoT-VLAN für deine Container haben möchtest, nutze macvlan – das ist sicherer als host und bietet bessere Isolation.

# Beispiel docker-compose.yml für Home Assistant und N8N mit Sicherheitsaspekten
version: '3.8'

services:
  homeassistant:
    image: ghcr.io/home-assistant/home-assistant:stable
    container_name: homeassistant
    restart: unless-stopped
    # PUID/PGID für einen dedizierten User auf dem Host (z.B. user id 1001, group id 1001)
    # Erstelle diesen User auf deinem Host: sudo useradd -u 1001 -s /sbin/nologin hassuser
    # sudo groupadd -g 1001 hassgroup
    # sudo usermod -aG hassgroup hassuser
    # Dann die Berechtigungen für das Config-Verzeichnis anpassen!
    user: "1001:1001" # Beispiel: UID:GID des non-root Users
    privileged: false # Niemals auf true setzen, es sei denn absolut notwendig!
    ports:
      - "192.168.30.10:8123:8123" # Nur auf spezifischer IP im IoT-Netzwerk lauschen
    volumes:
      - /opt/homeassistant/config:/config # Nur das Config-Verzeichnis mounten
      - /etc/localtime:/etc/localtime:ro
    environment:
      - TZ=Europe/Berlin
    networks:
      - iot_network
    # CPU/RAM Limits setzen, um Ressourcenmissbrauch zu verhindern
    deploy:
      resources:
        limits:
          cpus: '0.75' # Max 75% einer CPU
          memory: 1024M # Max 1GB RAM

  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    # Auch hier PUID/PGID verwenden, falls das Image es unterstützt
    # user: "1002:1002"
    ports:
      - "192.168.30.11:5678:5678" # Dedizierte IP für N8N
    volumes:
      - /opt/n8n/data:/home/node/.n8n # Nur das N8N-Datenverzeichnis
      - /etc/localtime:/etc/localtime:ro
    environment:
      - TZ=Europe/Berlin
      - N8N_HOST=n8n.dein-domain.de # Wichtig für Webhooks
      - N8N_PORT=5678
      - N8N_PROTOCOL=https # Immer HTTPS nutzen (mit Reverse Proxy)
      - WEBHOOK_URL=https://n8n.dein-domain.de/
      - GENERIC_TIMEZONE=Europe/Berlin
      # Weitere Sicherheitsrelevante N8N-ENVs:
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=dein_n8n_admin
      - N8N_BASIC_AUTH_PASSWORD=dein_sehr_sicheres_passwort
      - N8N_EDITOR_BASE_URL=https://n8n.dein-domain.de/
    networks:
      - iot_network
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M

networks:
  iot_network:
    external: true # Gehe davon aus, dass du das Netzwerk manuell erstellt hast
    # Für macvlan:
    # driver: macvlan
    # driver_opts:
    #   parent: eth0.30 # Dein Host-Interface mit dem IoT-VLAN-Tag
    # ipam:
    #   config:
    #     - subnet: 192.168.30.0/24
    #       gateway: 192.168.30.1
    #       ip_range: 192.168.30.10/28 # Ein kleiner Bereich für deine Container

Wichtig zu wissen: Für external: true musst du das Netzwerk vorher erstellen, z.B. docker network create --driver macvlan --subnet=192.168.30.0/24 --gateway=192.168.30.1 -o parent=eth0.30 iot_network.

3. System-Härtung des Host-OS (Proxmox-LXC/VM oder Docker-Host)

Ein sicherer Container nützt wenig, wenn der Host unsicher ist.

Regelmäßige Updates: Das A und O. Halte dein System (Proxmox, LXCs, VMs) immer auf dem neuesten Stand. apt update && apt upgrade -y ist dein Freund.
SSH-Zugang absichern: Deaktiviere den Passwort-Login für SSH. Nutze ausschließlich SSH-Keys. Das ist sicherer und bequemer. Ändere den Standard-SSH-Port von 22 auf etwas Ungewöhnliches (z.B. 22222).
Firewall auf dem Host: Auch wenn du Netzwerksegmentierung hast, eine lokale Firewall wie ufw oder firewalld auf deinen VMs/LXCs bietet eine zusätzliche Schutzschicht. Erlaube nur die Ports, die der Dienst wirklich benötigt.
Fail2ban: Installiere Fail2ban, um Brute-Force-Angriffe auf SSH und andere Dienste zu blockieren.

# SSH-Härtung: /etc/ssh/sshd_config bearbeiten
# Mein Tipp: Immer eine Kopie der Originaldatei machen, bevor du sie änderst!
# sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

sudo nano /etc/ssh/sshd_config

# Folgende Zeilen prüfen/ändern:
# Port 22 -> Port 22222 (oder ein anderer hoher Port)
Port 22222
# Deaktiviere Root-Login
PermitRootLogin no
# Erlaube nur Key-Authentifizierung
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
# Erlaube nur spezifische Benutzer (optional, aber gut)
AllowUsers dein_username

# Nach Änderungen den SSH-Dienst neu starten
sudo systemctl restart sshd

# WICHTIG: Teste den Login mit deinem Key und dem neuen Port in einem ZWEITEN Terminal,
# BEVOR du das erste Terminal schließt. Wenn du dich aussperrst, hast du ein Problem!
ssh -p 22222 dein_username@deine_server_ip

4. Applikations-Sicherheit – Home Assistant & N8N im Fokus

Auch die Anwendungen selbst müssen sicher konfiguriert sein.

Starke Passwörter und 2FA: Das sollte selbstverständlich sein. Überall, wo es geht, Multi-Faktor-Authentifizierung (MFA/2FA) aktivieren. Für Home Assistant ist das ein Muss.
Regelmäßige Updates der Anwendungen: Halte Home Assistant und N8N immer aktuell. Neue Versionen bringen oft Sicherheitsfixes mit sich.
API-Tokens und Zugänge: Wenn du API-Tokens oder Zugänge für externe Dienste in Home Assistant oder N8N hinterlegst, nutze immer das Prinzip der geringsten Rechte (Least Privilege). Gib einem Token nur die Berechtigungen, die es *unbedingt* benötigt.
N8N Credentials: N8N hat ein hervorragendes System für Credentials. Nutze es! Speichere keine Anmeldedaten direkt in deinen Workflows. Schütze N8N selbst mit Basic Auth oder einem Reverse Proxy, der Authentifizierung vorschaltet.
Home Assistant: User-Management: Erstelle für verschiedene Zwecke (z.B. Automatisierungen, Gäste) separate Benutzer mit eingeschränkten Rechten. Nutze allowlist_external_dirs, um zu kontrollieren, auf welche Verzeichnisse Home Assistant zugreifen darf.
Reverse Proxy mit HTTPS: Wenn du Home Assistant oder N8N über das Internet erreichbar machst, nutze unbedingt einen Reverse Proxy (z.B. Nginx Proxy Manager, Traefik) mit Let's Encrypt für HTTPS. Das ist nicht nur gut für die Sicherheit, sondern auch für die Integrität deiner Daten. Ein Web Application Firewall (WAF) als Teil des Reverse Proxy ist das Sahnehäubchen.

5. Monitoring & Logging – Augen und Ohren offen halten

Ein sicheres System ist gut, aber du musst auch wissen, wenn etwas schiefläuft. Überwache deine Systeme und schau in die Logs.

System-Logs: Regelmäßig journalctl -xe oder die Logs deiner Container prüfen. Auffälligkeiten wie fehlgeschlagene Login-Versuche, ungewöhnliche Netzwerkaktivität oder Abstürze sind Warnsignale.
Home Assistant Logs: In den Home Assistant Einstellungen gibt es einen Bereich für die Logs. Prüfe diese auf Fehler oder ungewöhnliche Aktivitäten.
N8N Execution Logs: N8N speichert die Ausführungshistorie deiner Workflows. Das ist nicht nur zum Debuggen nützlich, sondern zeigt auch an, wann und wie oft Workflows ausgeführt wurden.
Benachrichtigungen: Richte dir Benachrichtigungen ein, z.B. über Home Assistant oder N8N, wenn kritische Dienste nicht erreichbar sind, oder wenn Fail2ban jemanden blockiert hat.

Häufige Fehler und Lösungen

Problem 1: "Meine Home Assistant Integrationen funktionieren nicht mehr nach der Netzwerksegmentierung!"

Beschreibung: Du hast VLANs oder Firewall-Regeln eingerichtet, und plötzlich können deine Smart-Home-Geräte nicht mehr mit Home Assistant kommunizieren, oder Home Assistant kann keine externen Dienste erreichen.

Ursache: Meistens sind es fehlende oder falsch konfigurierte Firewall-Regeln. Das IoT-Netzwerk ist zu stark isoliert, oder Home Assistant fehlt der Zugang zu bestimmten IP-Adressen/Ports.

Lösung:

Prüfe die Firewall-Regeln: Vergewissere dich, dass dein IoT-Netzwerk eingehenden Zugriff auf den Home Assistant-Port (Standard 8123) hat.
Ausgehende Regeln: Stelle sicher, dass Home Assistant ausgehenden Zugriff auf DNS-Server (Port 53 UDP), NTP-Server (Port 123 UDP) und die spezifischen Ports deiner IoT-Geräte (z.B. MQTT Port 1883, Zigbee-Bridge Ports) oder Cloud-Dienste hat.
Netzwerk-Diagnose: Nutze Tools wie ping, traceroute oder netcat (nc) vom Home Assistant-Container (docker exec -it homeassistant bash und dann die Tools installieren, falls nicht vorhanden) aus, um die Konnektivität zu testen. Z.B. nc -vz ziel_ip ziel_port.
Unterschiedliche Subnetze: Wenn deine IoT-Geräte in einem anderen Subnetz als Home Assistant sind, müssen die Router-Firewall-Regeln die Kommunikation zwischen diesen Subnetzen auf den benötigten Ports erlauben.

Problem 2: "N8N kann nicht auf externe Dienste zugreifen, obwohl es vorher ging!"

Beschreibung: Deine N8N-Workflows, die externe APIs aufrufen sollen, schlagen fehl. Fehlermeldungen wie "Network Error" oder "Connection refused".

Ursache: Ähnlich wie bei Home Assistant, oft Firewall-Probleme oder DNS-Auflösung.

Lösung:

DNS-Prüfung: Kann der N8N-Container Hostnamen auflösen? Teste mit ping google.com oder nslookup google.com innerhalb des Containers. Wenn nicht, prüfe deine DNS-Einstellungen im Docker-Netzwerk oder auf dem Host.
Firewall Outbound: Stelle sicher, dass der N8N-Container ausgehenden Traffic auf Port 443 (HTTPS) oder 80 (HTTP) zu den jeweiligen Ziel-IPs/Domains erlauben darf.
Proxy-Einstellungen: Wenn du einen Proxy für ausgehenden Traffic nutzt, stelle sicher, dass die Umgebungsvariablen (HTTP_PROXY, HTTPS_PROXY, NO_PROXY) korrekt im N8N-Container gesetzt sind.
API-Rate Limits: Manchmal ist es auch kein Sicherheitsproblem, sondern ein Rate Limit der externen API, das du überschreitest. Prüfe die API-Dokumentation.

Problem 3: "Docker Container startet nicht mit neuem User oder hat Berechtigungsprobleme!"

Beschreibung: Nachdem du versucht hast, den Container mit einem Non-Root-User zu starten (z.B. über user: "1001:1001"), startet er nicht mehr oder kann nicht auf seine Daten zugreifen.

Ursache: Der User im Container hat keine ausreichenden Rechte auf die gemounteten Host-Verzeichnisse.

Lösung:

Host-Berechtigungen anpassen: Erstelle auf deinem Host den entsprechenden User und/oder die Gruppe mit der UID/GID, die du im Docker Compose File angegeben hast (z.B. sudo useradd -u 1001 -s /sbin/nologin hassuser).

Verzeichnis-Besitzer ändern: Ändere den Besitzer des gemounteten Verzeichnisses auf dem Host zum neuen User/Gruppe.

# Beispiel für Home Assistant Config-Verzeichnis
sudo chown -R 1001:1001 /opt/homeassistant/config
# Oder mit dem Benutzernamen, falls du einen erstellt hast
# sudo chown -R hassuser:hassgroup /opt/homeassistant/config

Dateiberechtigungen prüfen: Stelle sicher, dass die Dateiberechtigungen (z.B. chmod 755 für Verzeichnisse, 644 für Dateien) dem neuen User auch den Zugriff erlauben.
Container-Logs prüfen: Schau dir die Logs des Containers an (docker logs container_name), sie geben oft Aufschluss über die genaue Ursache der Berechtigungsfehler.

Fazit: Sicherheit ist ein Marathon, kein Sprint

Ich hoffe, dieser Praxis-Guide hat dir gezeigt, dass auch im Home Lab eine strukturierte Herangehensweise an Sicherheit unerlässlich ist. Es geht nicht darum, ein unüberwindbares Bollwerk zu errichten – das ist in der Praxis kaum möglich –, sondern darum, die Risiken zu minimieren und die Angriffsfläche zu reduzieren. Indem du Prinzipien aus der industriellen Sicherheit auf deine Heimautomatisierung anwendest, erhöhst du die Robustheit und Zuverlässigkeit deines Systems erheblich.

Denk dran: Sicherheit ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess. Bleib neugierig, informiere dich über neue Bedrohungen und halte deine Systeme stets aktuell. Die Mühe lohnt sich, denn ein sicheres Home Lab ist ein entspanntes Home Lab.

Was sind die nächsten Schritte?

Vertiefe dich in das Thema Reverse Proxies mit WAF-Funktionalität (z.B. Nginx mit ModSecurity oder Traefik mit CrowdSec).
Richte ein dediziertes VPN für den sicheren Fernzugriff auf dein Home Lab ein (z.B. WireGuard oder OpenVPN auf deinem Router oder einem separaten LXC/VM).

Home Lab Security: Härten deiner Home Assistant & N8N Umgebung