Netzwerk & Sicherheit

Jeder ssh-, scp- oder rsync-Aufruf zahlt denselben Preis: TCP-Aufbau, Schluesseltausch, Auth (oft MFA/Agent). Bei vielen kurzen Verbindungen — Deploy-Skripte, Ansible-Loops, git ueber SSH — frisst das spuerbar Zeit. SSH-Multiplexing oeffnet die Verbindung einmal und schiebt alle weiteren Sessions ueber denselben Tunnel. Dazu zeigt dieses Tutorial, wie du Bastion-Hops per ProxyJump end-to-end-verschluesselt durchquerst. Fuer Admins und DevOps mit OpenSSH-Client (Multiplexing seit jeher, ProxyJump ab OpenSSH 7.3).

Multiplexing in der ~/.ssh/config aktivieren

1. Lege ein Verzeichnis fuer die Control-Sockets an, das nur dir gehoert (sonst weigert sich SSH bzw. wird unsicher): mkdir -p ~/.ssh/cm && chmod 700 ~/.ssh/cm
2. Trage in ~/.ssh/config einen Block ein:

Host *
    ControlMaster auto
    ControlPath ~/.ssh/cm/%C
    ControlPersist 10m

• ControlMaster auto — existiert keine Master-Verbindung, wird diese zur Master; existiert schon eine, wird sie wiederverwendet. yes erzwingt immer Master (nie reuse), no ist Default (nie Master).
• ControlPath — Pfad zum Unix-Socket. %C ist ein Hash aus Host, Port, User und lokalem Hostnamen, immer gleich lang — robuster als %r@%h:%p bei langen Hostnamen (Socket-Pfade sind auf ~104 Zeichen begrenzt).
• ControlPersist 10m — der Master bleibt nach Schliessen der letzten Session noch 10 Minuten im Hintergrund offen. yes haelt ihn offen bis er explizit beendet wird; eine Zeit haelt mindestens so lange bzw. bis die letzte Session zu ist.

Verbinde dich einmal (ssh server), lasse das Fenster ruhig wieder zu — der naechste scp/rsync/ssh auf denselben Host nutzt den bestehenden Tunnel und ist sofort da.

Master-Verbindungen kontrollieren

Mit -O steuerst du den laufenden Master, ohne die Config zu aendern:

• ssh -O check server — prueft, ob ein Master laeuft (gibt PID + Socket-Pfad zurueck).
• ssh -O stop server — sanftes Herunterfahren: keine neuen Sessions mehr, bestehende laufen aus, dann faellt der Master.
• ssh -O exit server — beendet den Master sofort und schliesst alle daran haengenden Sessions.

Vorsicht: ssh -O exit reisst laufende Sessions, Forwards und Transfers ueber diesen Master hart ab. Auf Produktiv-Hosts erst mit -O check nachsehen, was dranhaengt. Stuerzt eine Verbindung ab und der Socket bleibt als „stale" liegen, hilft ssh -O exit oder schlicht das Loeschen der Socket-Datei in ~/.ssh/cm/.

ProxyJump: durch die Bastion in einem Rutsch

Statt erst auf den Jump-Host zu hopsen und von dort weiter, tunnelt ProxyJump die Verbindung end-to-end: Der Bastion-Host leitet nur den verschluesselten Stream weiter und sieht weder deinen privaten Schluessel noch die entschluesselte Session.

1. Ad hoc auf der Kommandozeile mit -J:

   ssh -J user@bastion user@ziel-intern

2. Mehrere Hops kettest du komma-separiert:

   ssh -J user@hop1,user@hop2 user@ziel

3. Sauber in der Config, sodass scp/rsync/git es automatisch nutzen:

Host bastion
    HostName bastion.example.net
    User admin

Host ziel-intern
    HostName 10.0.5.42
    User deploy
    ProxyJump bastion

Danach reicht ssh ziel-intern oder rsync -av ./build/ ziel-intern:/srv/app/ — der Hop passiert transparent.

ProxyJump und Multiplexing kombinieren

• Beide Mechanismen greifen unabhaengig: Multiplexing kann sowohl die Verbindung zur Bastion als auch die End-to-End-Verbindung zum Ziel wiederverwenden. Lass den Host *-Block mit ControlMaster einfach stehen — er gilt auch fuer ProxyJump-Ziele.
• So zahlt nur die allererste Verbindung den vollen Handshake (inkl. MFA an der Bastion); jeder weitere Befehl auf das interne Ziel ist quasi instant.
• Fuer Ansible setze in der ansible.cfg unter [ssh_connection] ein ssh_args mit denselben ControlMaster=auto -o ControlPath=… -o ControlPersist=…-Optionen — so teilen sich alle Tasks eines Plays eine Verbindung.

Profi-Tipp: Reuse heisst auch: Aenderst du Optionen wie ForwardAgent, RemoteForward oder den User, wirken sie auf bestehende Sessions nicht — die erben die Parameter des Masters. Nach Config-Aenderungen den Master mit ssh -O exit host beenden und neu aufbauen. Auf instabilen Leitungen ergaenze pro Host ServerAliveInterval 30 und ServerAliveCountMax 3, damit ein toter Master nicht alle Sessions blockiert. Quellen: ssh_config(5), OpenSSH Cookbook: Multiplexing, Red Hat: ProxyJump.

Eigene Cloud statt US-Anbieter: In diesem Tutorial baust du dir auf einem Linux-Host (Debian/Ubuntu, Mini-PC oder VM) zwei der beliebtesten Selfhosting-Dienste zusammen. Nextcloud ersetzt Dropbox/Google Drive, Vaultwarden ist ein schlanker, Bitwarden-kompatibler Passwort-Tresor. Davor sitzt Caddy als Reverse-Proxy, der vollautomatisch TLS-Zertifikate holt. Du brauchst eine eigene Domain (oder Subdomains), einen Server mit Docker und idealerweise DynDNS, wenn du zu Hause hostest. Gedacht fuer alle, die Docker-Grundlagen kennen und jetzt sauber produktiv betreiben wollen.

1. Docker und Verzeichnisse vorbereiten

1. Docker Engine inklusive Compose-Plugin installieren (offizielles Skript):

   curl -fsSL https://get.docker.com | sudo sh
   sudo usermod -aG docker $USER   # danach neu einloggen

2. Pruefe die Version — compose muss als Subcommand existieren, nicht das alte docker-compose: docker compose version
3. Projektordner anlegen:

   mkdir -p ~/stack/caddy ~/stack/vaultwarden-data
   cd ~/stack

4. DNS setzen: A/AAAA-Records fuer cloud.deine-domain.de und vault.deine-domain.de auf deine oeffentliche IP. Ohne korrekte DNS-Aufloesung kann Caddy spaeter kein Zertifikat ausstellen.

2. Caddy als Reverse-Proxy mit Auto-HTTPS

Caddy holt und erneuert TLS-Zertifikate selbst per ACME (Let's Encrypt / ZeroSSL) — kein Certbot, kein Cron-Job. Die Caddyfile (in ~/stack/caddy/Caddyfile):

cloud.deine-domain.de {
    reverse_proxy nextcloud-aio-mastercontainer:11000
}

vault.deine-domain.de {
    reverse_proxy vaultwarden:80
}

• Trage hinter dem ACME-Account-Mail-Eintrag deine echte Adresse ein, indem du oben einen Block { email du@deine-domain.de } ergaenzt — so bekommst du Ablaufwarnungen.
• Wichtig: Das Volume /data von Caddy muss persistent sein. Sonst zieht Caddy bei jedem Neustart neue Zertifikate und du laeufst in die Rate-Limits von Let's Encrypt.

3. compose.yaml fuer den ganzen Stack

Eine Datei ~/stack/compose.yaml startet alle Dienste in einem gemeinsamen Netzwerk:

services:
  caddy:
    image: caddy:2-alpine
    restart: always
    ports: ["80:80", "443:443", "443:443/udp"]
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config

  vaultwarden:
    image: vaultwarden/server:latest
    restart: always
    environment:
      - DOMAIN=https://vault.deine-domain.de
      - SIGNUPS_ALLOWED=false
      - ADMIN_TOKEN=$$argon2id$$v=19$$m=65540,t=3,p=4$$...DEIN_HASH...
    volumes:
      - ./vaultwarden-data:/data

  nextcloud:
    image: ghcr.io/nextcloud-releases/all-in-one:latest
    container_name: nextcloud-aio-mastercontainer
    restart: always
    ports: ["8080:8080"]
    environment:
      - APACHE_PORT=11000
      - APACHE_IP_BINDING=0.0.0.0
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  caddy_data:
  caddy_config:
  nextcloud_aio_mastercontainer:

Nextcloud AIO startet ueber den Mastercontainer weitere Container selbst — deshalb der Mount der docker.sock. Hinter einem Reverse-Proxy ist APACHE_PORT=11000 Pflicht; auf demselben Host setzt du APACHE_IP_BINDING=127.0.0.1. Den AIO-Verwaltungsdienst (Port 8080, self-signed) erreichst du nur lokal — gib ihn niemals oeffentlich frei.

4. Vaultwarden-Admin-Token sicher erzeugen

1. Hash interaktiv erzeugen lassen (Klartext-Token wird seit v1.28 abgelehnt):

   docker run --rm -it vaultwarden/server:latest /vaultwarden hash

2. Du erhaeltst einen Argon2id-String wie $argon2id$v=19$m=65540,t=3,p=4$.... In der compose.yaml musst du jedes $ zu $$ verdoppeln, sonst interpretiert Compose es als Variable.
3. So liegt nur der Hash in der Datei, nie das Passwort. SIGNUPS_ALLOWED=false verhindert, dass Fremde sich registrieren — lege deinen Account ueber /admin per Einladung an.

5. Starten und Backups einrichten

1. Stack hochfahren: docker compose up -d
2. Nextcloud erstmalig konfigurieren: https://:8080 oeffnen, Passwort des Mastercontainers notieren, Domain cloud.deine-domain.de eintragen, Container starten.
3. Vaultwarden-DB sauber sichern (Online-Backup-API, auch im laufenden Betrieb):

   docker exec vaultwarden /vaultwarden backup

   Sichere den Ordner ~/stack/vaultwarden-data (db.sqlite3 + Anhaenge) zusaetzlich versioniert, z. B. mit restic.
4. Updates regelmaessig einspielen: docker compose pull && docker compose up -d

Warnung beim Restore: Loesche vor dem Zurueckspielen einer SQLite-Sicherung eine eventuell vorhandene Datei db.sqlite3-wal — ein veraltetes WAL-File kann beim Recovery die Datenbank beschaedigen. Teste deinen Restore mindestens einmal auf einem zweiten Host: Ein Backup, das du nie zurueckgespielt hast, ist kein Backup. Quelle: Vaultwarden-Wiki und Nextcloud-AIO-Reverse-Proxy-Doku.

Auf eigene Gefahr: Änderungen an Admin-Konto, Remote-Zugang, VLANs und Firewall erfolgen auf eigene Gefahr und können dich aus deinem Netz oder der Verwaltung aussperren. Erstelle zuerst ein Konfig-Backup (Settings → System → Backups), notiere das Admin-Passwort und behalte physischen Zugang zum Gateway — im Notfall hilft nur ein Factory-Reset, der die komplette Konfiguration löscht.

Topologie: So hängt alles zusammen

Ein UniFi-Heimnetz besteht aus drei Bausteinen. Das Cloud Gateway (z. B. Cloud Gateway Ultra/UCG) ist Router, Firewall und Network-Controller in einem — es ersetzt deinen alten Router hinter dem Modem. Daran hängt ein managed Switch (z. B. USW Flex Mini) für mehr LAN-Ports und PoE-fähige Geräte. Die Access Points (U6/U7) liefern das WLAN. Der Controller läuft direkt auf dem Gateway, du brauchst also keinen separaten Cloud Key oder Server.

Internet ── Modem ── Cloud Gateway ── Switch ──┬── U7 Pro AP
                     (Router+Controller)        ├── U6 AP
                                                 └── PC / NAS

Gateway anschließen und einrichten

Verkabele zuerst alles: Modem an den WAN-Port des Gateways, deinen PC oder den Switch an einen LAN-Port. Schalte ein und warte, bis die LED ruhig leuchtet. Die Ersteinrichtung läuft über die UniFi Network App (iOS/Android) oder im Browser:

# Im Browser direkt zur Gateway-IP (Standard-Subnetz 192.168.1.0/24)
https://192.168.1.1

Folge dem Assistenten: UniFi-Konto verknüpfen (oder lokal ohne Cloud), Zeitzone setzen, Gerätenamen vergeben. Lege beim ersten WLAN gleich einen ordentlichen Netznamen und ein starkes Passwort fest — das verfeinerst du gleich.

Switch und Access Points adoptieren

Neue UniFi-Geräte am selben Netz tauchen automatisch unter UniFi Devices auf und stehen auf Pending Adoption. „Adopten" heißt: das Gateway übernimmt das Gerät in deine Verwaltung.

1. Öffne in der App den Reiter Devices.
2. Tippe das neue Gerät (Switch, dann jeder AP) an und wähle Adopt.
3. Warte, bis der Status von Adopting über Provisioning auf Connected wechselt.

PoE-APs wie der U7 Pro brauchen keinen separaten Strom, wenn der Switch PoE liefert (der Flex Mini tut das nicht — dann nutzt du den mitgelieferten PoE-Injektor oder ein PoE-Switch-Modell). Taucht ein Gerät nicht auf, prüfe, ob es im selben Subnetz steckt und das Kabel sitzt.

Firmware aktualisieren — vor allem anderen

Veraltete Firmware ist das häufigste Einfallstor. Aktualisiere direkt nach der Adoption alles, das Gateway zuerst.

# In der App: Settings → System → Updates
# oder pro Gerät: Devices → [Gerät] → Update available → Update
# Auto-Updates für Geräte aktivieren (Settings → System)

WLAN (SSID) einrichten

Unter Settings → WiFi legst du deine SSIDs an. Für ein Heimnetz reicht eine SSID, die UniFi automatisch auf 2,4 + 5 (+ 6) GHz ausspielt — die APs steuern das Band-Steering selbst.

WiFi 6E/7 (6-GHz-Band) verlangt zwingend WPA3. Lass es aktiv — ältere Geräte fallen automatisch auf die 2,4/5-GHz-Bänder zurück.

Gäste-Netz mit Isolation

Trenne Besucher und smarte Geräte vom Hauptnetz. UniFi bietet dafür ein eigenes Guest Network mit aktiver Client-Isolation.

# Settings → WiFi → Create New
#   Network type: Guest
#   eigenes VLAN zuweisen (z. B. VLAN 20)
#   Client Device Isolation: ON  (Gäste sehen einander/das LAN nicht)

Über den Guest-Typ blockt das Gateway automatisch den Zugriff auf dein internes Netz. Lege den Gästen idealerweise ein eigenes VLAN an (Settings → Networks → Create New Network), das gilt dann als saubere Basis, um später auch IoT-Geräte abzuschotten.

Admin-Zugang absichern

Zum Schluss die Härtung — der wichtigste Teil. Standardwerte sind öffentlich bekannt.

• Lokales Admin-Konto: unter Settings → Admins ein eigenes lokales Konto mit starkem Passwort anlegen; das vorbelegte ubnt/ubnt bzw. den Default-Login entfernen.
• 2FA am UniFi-Konto: in deinem account.ui.com Multi-Faktor (TOTP/Passkey) aktivieren — dieses Konto kann aus der Ferne auf dein Netz.
• Remote Access: unter Settings → System → Advanced abschalten, wenn du nicht von unterwegs zugreifst. Brauchst du Fernzugriff, nutze WireGuard-VPN (im Gateway integriert) statt offener Verwaltung.
• Keine Portfreigaben „ins Blaue": öffne niemals den Verwaltungs- oder einen offenen Port nach 0.0.0.0/0. Zugriff von außen immer über VPN.

Auf eigene Gefahr: Das Ändern von WAN-, Fernzugriffs- oder WLAN-Einstellungen kann dich aus dem Router oder dem Netz aussperren — nimm alle Änderungen lokal per LAN-Kabel vor und behalte den physischen Zugang zum Gerät. Sichere vorher die Router-Konfiguration (z. B. FritzBox: System → Sicherung) und teste einen neuen Fernzugriff per VPN von außen, bevor du den alten Zugang schließt. Alles auf eigene Gefahr.

Warum der Router das wichtigste Gerät im Heimnetz ist

Der Router ist das Tor zwischen deinem LAN und dem Internet. Wer ihn übernimmt, kann DNS umbiegen, Traffic mitlesen, Geräte erreichen und Botnetze aufbauen. Die meisten Angriffe sind dabei keine Hacker-Magie, sondern nutzen Standard-Passwörter, alte Firmware und offene Dienste. Diese Anleitung ist herstellerneutral, mit konkreten FritzBox-Beispielen. Bei anderen Routern (Speedport, AVM, UniFi, OpenWrt) heißen die Menüpunkte ähnlich.

1. Admin-Passwort ändern (und Default-Login killen)

Viele Router kommen mit admin/admin oder einem aufgedruckten Standardkennwort. Solche Defaults stehen in öffentlichen Datenbanken — ändere sie sofort. Setze ein einzigartiges, langes Passwort (16+ Zeichen) und speichere es im Passwort-Manager.

FritzBox: System → FRITZ!Box-Benutzer. Lege einen benannten Benutzer mit Passwort an und deaktiviere das geräteweite Kennwort-only-Login. So hat jeder Admin ein eigenes Konto statt eines geteilten Passworts.

2. Firmware aktuell halten

Firmware-Updates schließen genau die Lücken, die in Massen-Scans ausgenutzt werden. Aktiviere automatische Updates und prüfe einmal manuell.

FritzBox: System → Update → Auto-Update → Stufe „Über neue FRITZ!OS-Versionen informieren und neue Versionen automatisch installieren". OpenWrt prüfst du unter System → Software bzw. mit:

opkg update
opkg list-upgradable

3. WPS abschalten

WPS (besonders die PIN-Methode) ist per Brute-Force angreifbar und hebelt deine WLAN-Passphrase aus. Du brauchst es im Alltag nicht — schalte es ab.

FritzBox: WLAN → Sicherheit → WPS → Haken entfernen.

4. WPA3/WPA2 statt WPA/WEP

WEP und WPA(1) gelten als gebrochen. Nutze WPA3, oder den Mischmodus WPA2+WPA3 (WPA2/WPA3-Transitional), wenn ältere Geräte WPA3 noch nicht unterstützen. Reines WPA2 ist akzeptabel, reines WPA/WEP nicht.

FritzBox: WLAN → Sicherheit → Verschlüsselung → „WPA2 + WPA3".

5. Starke WLAN-Passphrase setzen

Die Passphrase schützt vor Offline-Cracking nach einem mitgeschnittenen Handshake. Nimm mindestens 20 Zeichen oder vier zufällige Wörter — länger schlägt Sonderzeichen-Chaos. Erzeuge sie z. B. so:

tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 24; echo

6. UPnP deaktivieren, wenn nicht gebraucht

UPnP erlaubt jedem Gerät im LAN, selbstständig Ports nach außen zu öffnen — Malware liebt das. Schalte es ab und lege bei Bedarf einzelne Portfreigaben manuell an.

FritzBox: Internet → Freigaben → FRITZ!Box-Dienste bzw. bei den Portfreigaben „Selbstständige Portfreigaben für dieses Gerät erlauben" deaktivieren.

7. Fernzugriff und Cloud abschalten

Fernwartung (HTTPS/TR-069), Telnet/SSH von außen und Hersteller-Cloud sind Angriffsfläche aus dem Internet. Lass sie aus, außer du brauchst sie wirklich — und dann nur über VPN.

FritzBox: Internet → Freigaben → FRITZ!Box-Dienste → „Internetzugriff über HTTPS aktivieren" und MyFRITZ! nur einschalten, wenn nötig. Für Fernzugriff besser Internet → Freigaben → VPN (WireGuard) nutzen — verschlüsselt und nicht öffentlich exponiert.

8. Separates Gäste-WLAN für Besuch und IoT

Ein Gäste-WLAN trennt fremde Geräte und unsichere IoT-Hardware (Smart-Plugs, Kameras) von deinem Hauptnetz. Fällt ein billiges Gerät aus, bleibt der Rest geschützt. Aktiviere die Geräte-Isolation, damit Gäste-Clients sich nicht gegenseitig sehen.

FritzBox: WLAN → Gastzugang → eigener Name, eigenes Passwort, „Gäste dürfen untereinander kommunizieren" abwählen. Hänge IoT idealerweise ins Gästenetz oder ein eigenes VLAN.

9. Unnötige Dienste abschalten

Alte Protokolle wie Telnet, FTP ohne TLS und SMBv1 sind unverschlüsselt oder löchrig. Deaktiviere alles, was du nicht aktiv nutzt: Telnet, UPnP-Medienserver, NAS-Freigaben mit SMBv1, alte „LAN-Gastzugang über LAN4"-Brücken. Prüfe von einem Client aus, was offen ist:

nmap -Pn 192.168.178.1

Erwartbar sind höchstens 53 (DNS), 80/443 (lokales Web-UF) — Telnet (23) oder offene SMB-Ports (445) gehören geschlossen.

10. Optional: DNS-over-HTTPS (DoH)

DoH verschlüsselt deine DNS-Anfragen, sodass dein Provider oder Mitleser im Netz nicht sieht, welche Domains du aufrufst. Manche Router (FritzBox ab FRITZ!OS 7.50, OpenWrt, UniFi) unterstützen das direkt.

FritzBox: Internet → Zugangsdaten → DNS-Server → „DNSSEC … verwenden" sowie verschlüsseltes DNS aktivieren und einen DoH-Resolver eintragen, z. B.:

https://dns.quad9.net/dns-query
https://doh.dns.sb/dns-query

Auf OpenWrt erreichst du dasselbe mit https-dns-proxy. Achte darauf, dass einzelne Clients nicht heimlich ein eigenes DoH benutzen, sonst greift deine Router-Richtlinie nicht.

Kurz-Checkliste

Admin-Passwort geändert, Firmware aktuell/Auto-Update an, WPS aus, WPA2/WPA3 aktiv, starke Passphrase, UPnP aus, Fernzugriff/Cloud aus (oder VPN), Gäste-/IoT-WLAN getrennt, Telnet/SMBv1 aus, optional DoH. Damit bist du gegen die überwiegende Mehrheit automatisierter Angriffe abgesichert.

Auf eigene Gefahr: Eine falsch gesetzte Firewall- oder Interface-Regel kann dich aus dem Web-GUI und aus deinem Netz aussperren — Umbau und Konfiguration auf eigene Gefahr. Halte immer Monitor/Tastatur oder serielle Konsole am Mini-PC bereit (über Menüpunkt „Assign interfaces" und Anti-Lockout-Regel kommst du wieder rein), öffne niemals das Management-GUI Richtung WAN, und sichere die funktionierende Konfiguration unter System > Configuration > Backups, bevor du Änderungen vornimmst.

Was du brauchst

OPNsense ist eine quelloffene Firewall- und Router-Distribution auf FreeBSD-Basis. Sie läuft auf eigener Hardware und gibt dir echte Kontrolle über dein Heimnetz: Firewall-Regeln, VLANs, VPN, IDS/IPS. Für ein Heim-Setup reicht ein lüfterloser Mini-PC mit einem N100/N305, 8 GB RAM und einer kleinen SSD. Entscheidend sind mindestens zwei physische Netzwerkkarten (Intel i225/i226 sind ideal) — eine für WAN (zum Modem/ISP), eine für LAN (dein Switch).

Installations-Stick erstellen

Lade das aktuelle Image von opnsense.org herunter (Variante dvd für VGA/HDMI oder serial für serielle Konsole), entpacke die .bz2-Datei und schreibe sie auf einen USB-Stick (mind. 4 GB). Unter Linux:

bzip2 -d OPNsense-25.1-dvd-amd64.iso.bz2
# Stick identifizieren (z. B. /dev/sdb) — NICHT die System-Disk erwischen!
lsblk
sudo dd if=OPNsense-25.1-dvd-amd64.iso of=/dev/sdb bs=1M status=progress conv=fsync

Unter Windows nimmst du Rufus (Modus „DD-Image"), unter macOS ebenfalls dd. Stecke den Stick in den Mini-PC, boote davon und wähle im Boot-Menü die Installation (nicht nur das Live-System).

Installieren und Interfaces zuordnen

Am Login-Prompt meldest du dich mit installer / opnsense an. Der Installer fragt nach Tastaturlayout, Dateisystem (ZFS empfohlen, auch als Single-Disk wegen Snapshots und Prüfsummen) und Ziel-Disk. Nach dem Schreiben setzt du das root-Passwort und entfernst den Stick beim Neustart.

Nach dem Boot landest du im Konsolen-Menü. Wähle 1) Assign interfaces. OPNsense fragt dich nacheinander nach WAN und LAN. Tipp: Ziehe die Kabel einzeln, dann zeigt die Konsole bei auto-detection das richtige Interface an. Ordne so zu:

WAN bezieht standardmäßig per DHCP eine Adresse vom Provider, LAN bekommt 192.168.1.1/24 mit aktivem DHCP-Server. Verbinde jetzt deinen Laptop per Kabel an den LAN-Port — du erhältst eine IP aus dem Bereich.

Erster GUI-Login: Default-Passwort sofort ändern

Öffne https://192.168.1.1 im Browser (Zertifikatswarnung akzeptieren) und melde dich als Benutzer root an — mit dem Passwort, das du bei der Installation gesetzt hast. Das Konsolen-Login installer/opnsense gilt nur im Live-Installer, nicht im Web-GUI. Nur falls du bei der Installation kein eigenes Passwort vergeben hast, greift noch das öffentlich bekannte Default:

Benutzer:  root
Passwort:  opnsense

Der Setup-Wizard (System > Wizard) führt dich durch Hostname, DNS, Zeitzone und WAN-Typ. Lass „Block private networks" und „Block bogon networks" auf dem WAN aktiviert.

Backup machen — vor jeder Änderung

Bevor du an Regeln schraubst: Sichere die funktionierende Konfiguration unter System > Configuration > Backups und lade die XML-Datei herunter. Verschlüssele sie optional mit einer Passphrase. So kannst du nach einem Fehler die Konfig in Sekunden wiederherstellen, statt neu zu installieren.

Firewall-Grundregeln: Default-Deny rein, LAN raus

OPNsense ist ab Werk sicher konfiguriert. Das WAN hat keine erlaubende eingehende Regel — alles von außen wird verworfen (Default-Deny). Das ist genau richtig. Lege keine Regel an, die das Web-GUI aufs WAN öffnet.

Prüfe die WAN-Regeln unter Firewall > Rules > WAN: Hier sollte nichts Eingehendes erlaubt sein (außer optional einer Anti-Lockout-Ausnahme, falls du sie bewusst anlegst). Auf Firewall > Rules > LAN findest du zwei voreingestellte Allow-Regeln (Default allow LAN to any für IPv4 und IPv6) — die erlauben deinem Netz den Weg nach draußen:

Die Anti-Lockout-Regel (System > Settings > Administration, „Disable web GUI redirect rule" NICHT setzen) hält das GUI auf dem LAN immer erreichbar — lass sie aktiv, solange du keinen dedizierten Management-Zugang abgesichert hast.

Firewall-Log aktivieren und nutzen

Pro Regel kannst du Logging einschalten: Firewall > Rules → Regel editieren → Häkchen bei Log packets. Standardmäßig protokolliert OPNsense bereits verworfene Pakete der impliziten Deny-Regel. Die Live-Ansicht findest du unter Firewall > Log Files > Live View — dort siehst du in Echtzeit, was geblockt wird, inklusive Filter nach IP, Port und Interface. Unverzichtbar zum Debuggen, wenn eine Verbindung nicht funktioniert.

DHCP im LAN konfigurieren

Der DHCP-Server läuft auf LAN bereits. Anpassen kannst du ihn unter Services > ISC DHCPv4 > [LAN] (neuere Versionen: Services > Dnsmasq DHCP oder Kea DHCP). Setze einen sinnvollen Adressbereich, z. B.:

Range from:  192.168.1.100
Range to:    192.168.1.200
DNS servers: 192.168.1.1   (OPNsense als DNS-Resolver)
Gateway:     192.168.1.1

Statische Leases vergibst du weiter unten per MAC-Adresse — praktisch für Server, NAS oder Drucker.

Updates einspielen

Halte die Firewall aktuell — Sicherheits-Patches sind hier kritisch. Im GUI: System > Firmware > Status → Check for updates. Über die Konsole oder SSH geht es ebenso:

opnsense-update -c   # auf Updates prüfen
opnsense-update      # System-Update einspielen
# Major-Upgrade auf eine neue Release-Serie:
opnsense-upgrade

Mache vor jedem Major-Upgrade ein frisches Konfig-Backup. Dank ZFS-Boot-Environments kannst du im Notfall auf einen früheren Snapshot zurückbooten.

Auf eigene Gefahr: Falsch gesetzte Firewall-Regeln können dich vom Gateway oder Controller aussperren oder die Geräte-Steuerung lahmlegen — alles auf eigene Gefahr. Exportiere vor Änderungen ein Backup deiner UniFi-Konfiguration, halte einen kabelgebundenen Admin-Zugang im trusted LAN offen und teste mit aktiviertem Regel-Logging, bevor du die Segmentierung scharf schaltest.

Warum überhaupt segmentieren?

Ein flaches Heimnetz behandelt deinen Saugroboter, die billige WLAN-Steckdose und deinen Laptop mit den Steuerunterlagen gleich — alle im selben Broadcast-Segment, alle erreichbar untereinander. IoT-Geräte bekommen selten Updates und „telefonieren" gerne nach Hause. Das Prinzip heißt Least Privilege: Jedes Gerät darf nur das, was es wirklich braucht. Mit VLANs zerlegst du das eine Netz in logisch getrennte Bereiche auf derselben Hardware. Ziel-Layout für ein Heimnetz:

Tagged vs. untagged — die zwei Minuten Theorie

Ein untagged Port (Access-Port) gehört genau zu einem VLAN. Das angeschlossene Gerät weiß nichts von VLANs und bekommt seine IP einfach aus dem zugewiesenen Netz — so steckst du z. B. einen smarten Fernseher ins IoT-VLAN. Ein tagged Port (Trunk) transportiert mehrere VLANs gleichzeitig per 802.1Q-Tag und verbindet die „Infrastruktur": Gateway zu Switch, Switch zu Switch, Switch zu Access Point. Der Access Point braucht die Tags, weil er pro SSID ein anderes VLAN funkt.

Netzwerke in UniFi anlegen

In der UniFi Network App (Self-Hosted Controller oder Cloud Gateway): Settings → Networks → New Virtual Network. Lege zwei neue an, z. B. „IoT" mit VLAN ID 20 und „Gäste" mit VLAN ID 30. Vergib jeweils ein eigenes Subnetz und aktiviere DHCP. Bei „Gäste" setzt du zusätzlich oben den Network-Typ auf Guest (aktiviert die L2-Client-Isolation, sodass Gäste sich nicht gegenseitig sehen).

SSID auf VLAN mappen

Unter Settings → WiFi legst du pro Zone eine SSID an. In den WiFi-Einstellungen wählst du unter „Network" das jeweilige virtuelle Netz:

SSID "Zuhause"   → Network: Default (VLAN 1)
SSID "Zuhause-IoT" → Network: IoT (VLAN 20)
SSID "Gäste"     → Network: Gäste (VLAN 30)

Der AP funkt jede SSID ins zugehörige VLAN und taggt den Traffic auf dem Trunk Richtung Switch. Du musst am AP nichts manuell taggen — das erledigt UniFi automatisch über das SSID-Mapping.

Switch-Ports zuweisen

Pro Port unter Ports → Port Manage ein Port-Profil setzen. Für ein Endgerät, das fest ins IoT-Netz soll (z. B. ein NAS-loser Smart-TV per Kabel), wählst du als Port-Profil das IoT-Netz (untagged = Access). Für den Uplink zum Gateway und zum AP nutzt du das Profil All bzw. einen Trunk, der LAN untagged und IoT/Gäste tagged führt.

Die entscheidende Firewall-Regel: IoT darf nicht ins LAN

Hier liegt der eigentliche Sicherheitsgewinn. Standardmäßig routet das Gateway zwischen allen VLANs frei. Du willst: LAN → IoT erlaubt (damit dein Handy den Drucker/Fernseher steuert), aber IoT → LAN blockiert. Eine Stateful-Firewall lässt Antwortpakete der vom LAN initiierten Verbindung automatisch durch — du musst also nur die von IoT neu aufgebauten Verbindungen ins LAN sperren.

Bei aktuellen UniFi-Versionen unter Settings → Security → Traffic & Firewall Rules eine neue Policy:

Aktion:   Block (Drop)
Richtung: Source = IoT (192.168.20.0/24)
          Destination = "RFC1918" / Local-Networks außer IoT
          oder konkret LAN 192.168.1.0/24 + Gäste 192.168.30.0/24
Connection-States: New
Logging: an (zum Testen)

Wichtig ist die Reihenfolge: Lege die Block-Regel nach einer eventuellen Allow-Regel für DNS/Multicast an. Pakete von etablierten Verbindungen (Established/Related) lässt du in Ruhe — sonst bricht die LAN→IoT-Steuerung. Gäste behandelst du genauso: Block Gäste → alle lokalen Netze, nur Internet bleibt offen.

mDNS/Bonjour-Falle beim Casting

Chromecast, AirPlay, Sonos & Co. finden sich über mDNS (Multicast, 224.0.0.251), das standardmäßig nicht über VLAN-Grenzen läuft. Wenn dein Handy im LAN den Chromecast im IoT-VLAN finden soll, aktiviere den mDNS-Reflector: Settings → Networks → Global Network Settings → Multicast DNS einschalten und die betroffenen Netze auswählen. Das durchbricht die Trennung kontrolliert nur für Discovery — die strikte Firewall-Block-Regel bleibt bestehen, der Reflector ersetzt sie nicht.

Sicher ausrollen, ohne dich auszusperren

Die größte Gefahr: Du blockierst aus Versehen den Zugriff auf das Gateway/den Controller selbst. Halte deshalb immer einen kabelgebundenen Admin-Pfad im trusted LAN offen und arbeite die VLANs schrittweise ab — erst Netze und SSIDs anlegen und testen, dann die Firewall-Regeln aktivieren. Setze die Block-Regeln spezifisch auf IoT/Gäste als Quelle, nie pauschal „alles blocken". So bleibt dein Management-Zugang erreichbar, falls eine Regel danebengeht.

Auf eigene Gefahr: Falsche WAN/LAN-Zuweisung, ein gelöschtes „Allow LAN to any" oder eine deaktivierte Anti-Lockout-Regel können dich aus der Web-GUI aussperren. Schutz: 1) Halte immer physischen Konsolenzugang (Monitor + Tastatur) bereit — über das Konsolenmenü kannst du Interfaces neu zuweisen (Option 1), die GUI/Passwort zurücksetzen oder per Option 4 auf Werk zurücksetzen. 2) Lade vor jeder Regeländerung unter Diagnostics > Backup & Restore die XML-Config herunter. 3) Öffne niemals die Firewall-/SSH-Verwaltung Richtung WAN (keine Allow-Regel am WAN für Port 443/80/22). 4) Prüfe beim dd-Befehl das Zielgerät (lsblk), damit du nicht versehentlich deine Systemplatte überschreibst.

Was du baust

pfSense CE (Community Edition) verwandelt einen kleinen Mini-PC in eine ausgewachsene Firewall und einen Router mit Stateful Packet Filter, NAT, DHCP und DNS. In dieser Anleitung installierst du pfSense vom USB-Stick, weist über die Konsole die Interfaces zu (WAN/LAN), meldest dich erstmalig in der Web-GUI an, durchläufst den Setup-Wizard und richtest saubere Firewall-Regeln ein: WAN per Default-Deny dicht, LAN kontrolliert offen.

Hardware

Du brauchst mindestens zwei physische Netzwerkkarten — eine für WAN (Richtung Internet/Modem), eine für LAN. Bewährt sind lüfterlose Mini-PCs mit Intel N100 und Intel-i226-V-2.5-GbE-Ports. Intel-NICs (igc/igb-Treiber) laufen mit pfSense ohne Gefrickel; Realtek-Chips sind möglich, aber unter BSD historisch zickig.

Installer auf USB schreiben

Lade von pfsense.org das AMD64 Memstick-Installer-Image (Konsole: Serial oder VGA — für Mini-PC mit Monitor nimm VGA). Entpacke das .img.gz und schreibe es 1:1 auf den Stick. Unter Linux (Gerät vorher mit lsblk sicher identifizieren — falsches Ziel löscht deine Platte):

gunzip pfSense-CE-memstick-*-amd64.img.gz
sudo dd if=pfSense-CE-memstick-*-amd64.img of=/dev/sdX bs=4M status=progress conv=fsync

Achtung: dd überschreibt das Zielgerät unwiderruflich. Bestimme mit lsblk zweifelsfrei den USB-Stick (Größe vergleichen!) und setze /dev/sdX exakt darauf — ein falsches Ziel löscht deine Systemplatte ohne Rückfrage.

Installation

Stick einstecken, Mini-PC im BIOS auf USB-Boot stellen, starten. Im Installer akzeptierst du den ZFS-Standard (oder Auto UFS bei sehr kleiner SSD), wählst die Zielplatte und lässt durchlaufen. Am Ende „Reboot" wählen und den USB-Stick ziehen.

Interfaces an der Konsole zuweisen

Nach dem Boot fragt pfSense in der Konsole nach VLANs (mit n ablehnen) und dann nach der Zuordnung. Du musst wissen, welche Buchse welcher Treibername ist (z. B. igc0, igc1). Wenn unklar: Kabel nur in WAN stecken und „Auto-detection" nutzen — pfSense erkennt das aktive Interface beim Einstecken.

Enter the WAN interface name: igc0
Enter the LAN interface name: igc1
Do you want to proceed [y|n]? y

Danach vergibt pfSense LAN standardmäßig 192.168.1.1/24 und startet DHCP nur auf LAN. WAN holt sich per DHCP eine Adresse vom Modem/Provider. Schließe deinen Verwaltungs-PC an den LAN-Port an.

Erste GUI-Anmeldung — Passwort sofort ändern

Öffne vom LAN-PC im Browser https://192.168.1.1. Das Zertifikat ist selbstsigniert (Warnung bestätigen). Die Werks-Zugangsdaten lauten:

Benutzer:  admin
Passwort:  pfsense

Sofort als Erstes: Ändere das Passwort direkt nach dem ersten Login (allererster Wizard-Schritt), bevor du irgendetwas anderes konfigurierst. Ein unverändertes admin/pfsense ist das größte Risiko an einer frischen Firewall — öffentlich bekannt. Vergib ein langes, einzigartiges Passwort.

Setup-Wizard

Der Wizard führt dich durch: Hostname & Domain, DNS-Server (z. B. 9.9.9.9 Quad9 oder dein Provider; „Override DNS" abwählen, wenn du eigene DNS willst), Zeitzone Europe/Berlin, WAN-Typ (meist DHCP), LAN-IP (Standard 192.168.1.1 belassen oder eigenes Subnetz) und schließlich das Admin-Passwort. Im WAN-Schritt sind „Block private networks" und „Block bogon networks" aktiviert — so lassen.

Config sichern, BEVOR du Regeln änderst

Gehe zu Diagnostics > Backup & Restore und lade die XML-Config herunter. Tu das jetzt und nach jeder größeren Änderung. Eine kaputte Regel ist in Sekunden zurückgespielt.

Firewall-Regeln: WAN dicht, LAN kontrolliert

pfSense ist von Haus aus default-deny am WAN: ohne explizite Regel kommt von außen nichts rein, und die Block-private/bogon-Regeln sind aktiv. Lass das so. Lege am WAN keine Allow-Regel für die GUI an.

Am LAN existiert die Default-Regel „Anti-Lockout" (erlaubt Zugriff auf die Firewall selbst) plus „LAN to any". Für mehr Kontrolle ersetzt du „LAN to any" durch gezielte Regeln (Firewall > Rules > LAN), z. B. nur HTTP/HTTPS/DNS erlauben. Die Logik:

Logging aktivieren

Jede Block-Regel kannst du beim Bearbeiten mit „Log packets that are handled by this rule" protokollieren. Standardmäßig loggt pfSense die Default-Deny-Treffer. Ansehen unter Status > System Logs > Firewall. Aktiviere Logging gezielt für interessante Regeln statt pauschal alles — sonst läuft die SSD voll.

Updates

Unter System > Update siehst du die verfügbare Version und spielst Updates ein. Mache vorher immer ein Config-Backup. Pakete (Suricata, pfBlockerNG, WireGuard) installierst du über System > Package Manager.

pfSense vs. OPNsense — kurz

OPNsense ist ein 2015 entstandener Fork von pfSense. Funktional sehr ähnlich (beide FreeBSD-basiert, gleicher pf-Packetfilter). OPNsense bringt eine modernere UI, ein festes Release-Modell (zwei Major-Releases/Jahr) und WireGuard/Plugins out-of-the-box. pfSense CE hat die größere Community, mehr Tutorials und Netgate-Backing. Beide sind solide — wer eine aufgeräumtere Oberfläche und schnellere Feature-Zyklen will, schaut sich OPNsense an; die hier gezeigten Konzepte (Interface-Zuweisung, Default-Deny, Anti-Lockout) gelten sinngemäß für beide.

Auf eigene Gefahr: Eine falsch gesetzte Firewall- oder Port-Forward-Regel kann ungewollt interne Dienste ins Internet stellen. Leite ausschließlich den WireGuard-UDP-Port (z. B. 51820) weiter und keinen anderen. Prüfe nach dem Einrichten zwingend von einem fremden Netz aus (Mobilfunk/externer Port-Scan), dass nur dieser eine UDP-Port reagiert. Behalte außerdem einen alternativen Zugang zu Router und Server (lokale Konsole bzw. LAN-Zugriff), falls eine geänderte Firewall-Regel dich aussperrt — teste neue WAN-Regeln nie ohne diesen Rückweg.

Warum WireGuard statt Port-Forwarding einzelner Dienste

Wenn du von unterwegs auf NAS, Proxmox oder Smart-Home zugreifen willst, ist die schlechteste Lösung, jeden Dienst einzeln per Port-Forwarding ins Internet zu hängen. Jeder offene Port ist eine Angriffsfläche. WireGuard dreht das um: Du öffnest genau einen UDP-Port nach außen, und nur wer den passenden privaten Schlüssel besitzt, kommt überhaupt durch. Alles andere bleibt unsichtbar. WireGuard antwortet auf Pakete ohne gültigen Schlüssel gar nicht erst — der Port wirkt von außen wie geschlossen.

Das Prinzip: Schlüsselpaare und Peers

WireGuard kennt kein Login mit Passwort. Jede Seite (Server und jedes Client-Gerät) hat ein Schlüsselpaar: einen privaten und einen öffentlichen Schlüssel. Der private Schlüssel bleibt immer auf dem Gerät, nur die öffentlichen Schlüssel werden ausgetauscht. Wichtig: Lege pro Gerät einen eigenen Peer an (Handy, Laptop, Tablet jeweils separat). So kannst du einen einzelnen verlorenen Schlüssel widerrufen, ohne alle neu ausrollen zu müssen.

Variante A: Router/Gateway mit eingebautem WireGuard

Am einfachsten ist es, wenn dein Gateway WireGuard schon mitbringt:

Bei FRITZ!Box und UniFi wird die Port-Freigabe automatisch gesetzt — du musst nichts von Hand am NAT öffnen. Bei OPNsense/pfSense legst du selbst eine WAN-Firewall-Regel an: Protokoll UDP, Ziel-Port 51820, Aktion „pass“. Nur diesen einen Port, sonst nichts.

Variante B: Linux/Raspberry Pi als WireGuard-Peer

Hast du kein WG-fähiges Gateway, läuft WireGuard hervorragend auf einem Pi oder einer kleinen VM. Installation und Schlüssel:

sudo apt update && sudo apt install -y wireguard
# Schlüsselpaar für den Server erzeugen (Rechte einschränken!)
umask 077
wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub

Server-Konfiguration unter /etc/wireguard/wg0.conf:

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <INHALT_VON_server.key>

# Ein Peer pro Gerät – hier das Handy
[Peer]
PublicKey = <PUBLIC_KEY_DES_HANDYS>
AllowedIPs = 10.10.0.2/32

Damit Geräte hinter dem Pi erreichbar sind, brauchst du IP-Forwarding und NAT. Aktiviere Forwarding dauerhaft und richte eine Masquerade-Regel auf dem LAN-Interface ein (Beispiel-Interface eth0):

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wg.conf
sudo sysctl --system
# In wg0.conf unter [Interface] ergänzen:
# PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
sudo systemctl enable --now wg-quick@wg0

Auf deinem Router brauchst du dann eine Port-Weiterleitung: UDP 51820 → interne IP des Pi. Kein weiterer Forward.

Client-Config und QR-Code fürs Handy

Die mobile WireGuard-App erzeugt das Schlüsselpaar selbst — du gibst nur deren öffentlichen Schlüssel in den Server-Peer ein. Eine vollständige Client-Config sieht so aus:

[Interface]
PrivateKey = <CLIENT_PRIVATE_KEY>
Address = 10.10.0.2/32
DNS = 10.10.0.1            # interner DNS, damit Heim-Hostnamen aufgelöst werden

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = deinanschluss.ddns.net:51820
AllowedIPs = 10.10.0.0/24, 192.168.1.0/24   # Split-Tunnel: nur Heimnetz
PersistentKeepalive = 25

Für den QR-Code auf dem Server (Variante B):

sudo apt install -y qrencode
qrencode -t ansiutf8 < handy.conf

In der Handy-App: „Hinzufügen → aus QR-Code scannen“. Fertig.

Split-Tunnel vs. Full-Tunnel

Split-Tunnel (oben gezeigt): Nur Verkehr ins Heimnetz geht durch den Tunnel, dein normaler Internet-Traffic läuft direkt — schneller, schont die Upload-Leitung daheim. Setze dafür in AllowedIPs nur deine internen Subnetze. Full-Tunnel: Setze AllowedIPs = 0.0.0.0/0, ::/0, dann läuft aller Traffic über dein Heimnetz — sinnvoll in fremden WLANs, kostet aber Bandbreite. Hinweis: das 0.0.0.0/0 steht hier nur in der Client-Config als Routing-Ziel, nicht in der Firewall — das ist unkritisch.

Auf eigene Gefahr: Binde Uptime Kuma niemals offen ans Internet (kein -p 3001:3001 ohne IP-Bindung und keine Portfreigabe im Router auf 0.0.0.0/0). Erreiche es nur über LAN, VPN oder einen Reverse Proxy mit Authentifizierung und HTTPS. Lege beim ersten Start sofort einen Admin-Account mit starkem Passwort an, solange das Setup nur lokal erreichbar ist – ein offenes, unkonfiguriertes Kuma kann jeder im Netz übernehmen.

Was du baust

Ein kleines, immer laufendes Monitoring, das deine Dienste (Router, NAS, Pi-hole, Webserver, VMs) regelmäßig anpingt und dir eine Push-Nachricht schickt, sobald etwas ausfällt oder wieder online ist. Das Herzstück ist Uptime Kuma – ein selbst gehostetes Tool mit hübschem Dashboard, vielen Check-Typen und über 90 Benachrichtigungskanälen.

Wo läuft das am besten?

Faustregel: Das Monitoring soll nicht auf demselben Gerät laufen, das es überwachen soll – sonst merkst du den Ausfall nie. Ein separater, stromsparender Always-on-Host ist ideal:

Uptime Kuma per Docker starten

Schnellstart mit einem benannten Volume, damit deine Konfiguration einen Neustart übersteht. Wichtig: Wir binden den Port nur an 127.0.0.1 bzw. die LAN-IP – nicht offen ins Internet.

docker run -d \
  --name uptime-kuma \
  --restart unless-stopped \
  -p 127.0.0.1:3001:3001 \
  -v uptime-kuma:/app/data \
  louislam/uptime-kuma:1

Sauberer und wartbarer ist eine compose.yaml:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - uptime-kuma:/app/data

volumes:
  uptime-kuma:

docker compose up -d

Greife danach lokal über http://127.0.0.1:3001 zu (z. B. via SSH-Tunnel ssh -L 3001:127.0.0.1:3001 user@host). Beim ersten Aufruf legst du sofort einen Admin-Account mit starkem Passwort an – es gibt keine Default-Zugangsdaten, aber das Setup darf nicht offen erreichbar herumstehen.

Monitore anlegen

Klick auf Add New Monitor. Die wichtigsten Typen:

Setz das Heartbeat Interval auf 60 s und Retries auf 2–3, damit ein einzelner Aussetzer nicht gleich Alarm auslöst.

Benachrichtigungen einrichten

Unter Settings → Notifications → Setup Notification. Empfehlenswert ist ntfy – kostenlos, selbst hostbar, Push aufs Handy:

Bei ntfy wähle ein nicht erratbares Topic (z. B. kuma-a8f3k2) und abonniere es in der ntfy-App. Da öffentliche Topics jeder lesen kann, der den Namen kennt, gehören keine sensiblen Details in den Topic-Namen – oder du hostest ntfy selbst mit Zugriffsschutz. Teste danach mit dem Button Test.

Status-Page für die Übersicht

Unter Status Pages → New Status Page baust du eine Übersichtsseite deiner Dienste. Praktisch für die Familie („Ist das Internet weg oder nur Netflix?“). Lass sie privat bzw. nur im LAN erreichbar – veröffentliche keine internen Hostnamen oder IPs nach außen.

Sicher von außen erreichbar (optional)

Willst du Kuma von unterwegs sehen, stell nie den Port direkt ins Internet. Nutze stattdessen einen der sicheren Wege:

• VPN (WireGuard/Tailscale) ins Heimnetz – einfachste und sicherste Variante.
• Reverse Proxy mit Auth (Caddy/Traefik/NGINX) plus HTTPS und einer vorgelagerten Authentifizierung.

Minimal-Beispiel für Caddy mit automatischem TLS vor Kuma:

kuma.example.org {
    reverse_proxy 127.0.0.1:3001
}

Alternativen im Blick

Für reines „läuft / läuft nicht“ plus Alarm reicht Uptime Kuma völlig. Metriken-Dashboards lohnen sich erst, wenn du Trends über Zeit sehen willst.

Auf eigene Gefahr: . SMB (Port 445) niemals per Portforwarding ins Internet öffnen und keine Firewall-Regel auf 0.0.0.0/0 setzen — das legt deine Daten offen; nutze für Fernzugriff ein VPN. RAID/Mirror ersetzt kein Backup: halte nach 3-2-1 mindestens eine Off-Device-Kopie. Behalte beim Ändern von Passwörtern, Netzwerk oder Firewall immer einen funktionierenden Admin-Zugang plus Konsolen-/Monitorzugang am NAS, damit du dich nicht aussperrst, und prüfe Festplatten-Layout sorgfältig, bevor du einen Pool erstellst (das Anlegen löscht die Platten).

Was ist ein NAS und wann lohnt es sich?

Ein NAS (Network Attached Storage) ist ein kleiner Server, der Speicher über das Netzwerk bereitstellt — für Backups, Mediendateien, Dokumente oder als Ablage für mehrere Geräte. Statt USB-Platten am Schreibtisch hast du einen zentralen, jederzeit erreichbaren Ort. In diesem Tutorial baust du ein NAS auf, richtest einen gespiegelten Datenpool ein und legst eine SMB-Freigabe mit eigenem Benutzer an.

Hardware: Fertig-NAS oder DIY?

Für ein robustes DIY-NAS empfiehlt sich ein x86-Mini-PC mit mindestens 8 GB RAM (für ZFS gern 16 GB), Gigabit-LAN und Platz für zwei 3,5"-Platten. Nimm NAS-Festplatten (z. B. WD Red Plus, Seagate IronWolf) — die sind für Dauerbetrieb und Vibrationen ausgelegt. Eine optionale SSD kann als Cache (ZFS L2ARC/SLOG) oder als App-/System-Disk dienen.

Betriebssystem: TrueNAS SCALE vs. OpenMediaVault

Wer ZFS und Snapshots will, nimmt TrueNAS SCALE. Wer minimal und auf schwacher Hardware bleiben will, nimmt OMV. Beide installierst du per ISO/Image auf eine separate System-Disk (USB-Stick reicht bei OMV nicht dauerhaft — nimm eine kleine SSD).

RAID/Mirror-Grundlagen

Mit zwei Platten richtest du einen Mirror ein (ZFS-Mirror bzw. RAID1): jede Platte hält dieselben Daten, eine darf ausfallen. Das schützt vor Plattendefekt — aber nicht vor versehentlichem Löschen, Ransomware, Blitzschlag oder Diebstahl.

TrueNAS SCALE: Pool, Dataset und SMB-Freigabe

Nach der Installation öffnest du die Web-UI (http://<nas-ip>) und setzt sofort ein starkes Admin-Passwort. Dann:

1. Pool anlegen: Storage → Create Pool, beide Platten auswählen, Layout Mirror, Name z. B. tank. ⚠ Das Anlegen eines Pools löscht ALLE Daten auf den gewählten Platten unwiderruflich — nimm nur leere Platten oder sichere vorher.
2. Dataset: Datasets → Add Dataset, Name daten, Preset SMB.
3. Benutzer: Credentials → Local Users → Add. Lege einen eigenen Account (z. B. nasuser) mit starkem Passwort an — nicht root für Freigaben verwenden.
4. Freigabe: Shares → Windows (SMB) Shares → Add, Pfad /mnt/tank/daten, Name daten. SMB-Dienst aktivieren, wenn gefragt.

OpenMediaVault: Alternative über die GUI

Bei OMV ist der Ablauf analog über die Web-UI: Storage → Disks prüfen, dann Storage → Software RAID einen RAID1 erstellen, ein Dateisystem (ext4/btrfs) anlegen und mounten. Danach unter Users einen Benutzer anlegen und unter Services → SMB/CIFS die Freigabe mit Zugriffsrechten für genau diesen Benutzer definieren. Aktiviere SMB erst, nachdem der Benutzer steht.

Freigabe sicher binden — nicht ins Internet öffnen

SMB gehört ausschließlich ins LAN. Öffne niemals Port 445 (SMB) per Portforwarding zum Internet. Setze in der Firewall/Router-Konfig keine Regel auf 0.0.0.0/0. Willst du von unterwegs zugreifen, nutze ein VPN (WireGuard/Tailscale) und erreiche das NAS über das VPN-Netz.

Freigabe testen

Vom Linux-Client (Paket smbclient) erreichst du die Freigabe so:

smbclient //<nas-ip>/daten -U nasuser

Unter Windows im Explorer: \\<nas-ip>\daten. Melde dich mit nasuser an — anonymer Gastzugriff sollte deaktiviert bleiben.

3-2-1: Backups trotz Mirror

Die bewährte Regel: 3 Kopien deiner Daten, auf 2 verschiedenen Medien, davon 1 außer Haus (off-site). Ein ZFS-Mirror erfüllt davon fast nichts — er ist eine Kopie auf einem Gerät. Richte daher ein:

• ZFS-Snapshots (TrueNAS: Data Protection → Periodic Snapshot Tasks) gegen versehentliches Löschen.
• Eine externe USB-Platte oder ein Cloud-/Remote-Ziel als Off-Site-Kopie.
• Eine UPS (USV), damit ein Stromausfall den Pool nicht beschädigt; TrueNAS unterstützt NUT für sauberes Herunterfahren.