Sicheres Homelab – Proxmox, VLANs und Updates sauber trennen

Im Homelab laufen oft Dienste, die im Produktivbetrieb getrennt wären: Testsysteme, Medienserver, Smart-Home-Gateways, Admin-Tools und manchmal sogar Backups. Genau diese Mischung ist der typische Risikotreiber: Ein verwundbarer Container oder eine unsaubere Portfreigabe kann lateral (seitlich) in Richtung Router, NAS oder Admin-Interface eskalieren. Mit wenigen, klaren Regeln lässt sich die Angriffsfläche deutlich reduzieren, ohne den Bastelspaß zu verlieren.

Warum Homelabs so häufig „aus Versehen“ offen sind

Typische Schwachstellen: Portfreigaben, Standardkonten, gemischte Netze

Viele Homelabs entstehen inkrementell: Erst eine VM, dann ein Reverse Proxy, später ein Git-Runner oder ein neues IoT-Gerät. Dabei schleichen sich Muster ein, die aus Sicherheitssicht ungünstig sind: Dienste werden „kurz“ ins Internet veröffentlicht, Passwörter bleiben länger unverändert, und alle Systeme teilen sich dasselbe Subnetz. Besonders kritisch ist das, wenn das Management-Interface des Hypervisors aus dem gleichen Netz erreichbar ist wie experimentelle Workloads.

Ein weiteres Problem: Logging und Übersicht fehlen. Wer nicht erkennt, welche Systeme überhaupt nach außen sprechen, merkt kompromittierte Services oft erst spät. Einfache Kontrollen (z. B. welche Ports am Router offen sind und welche VMs welche Netze nutzen) bringen hier bereits viel.

Realistische Angriffswege im Heimnetz

In Homelabs dominieren drei Angriffswege: Erstens Angriffe über veröffentlichte Webdienste (schwache Authentifizierung, ungepatchte Webapps). Zweitens Missbrauch durch kompromittierte Clients im Heimnetz (Phishing am PC, Malware am Laptop), die dann Dienste im Lab scannen. Drittens Risiko durch Lieferketten in Images/Plugins (unsaubere Downloads, alte Container). Ziel ist nicht „absolute Sicherheit“, sondern kontrollierte Bereiche: Wenn etwas fällt, darf es nicht alles mitreißen.

Netztrennung im Homelab planen: Welche Zonen wirklich helfen

Minimaler Zonenplan, der sich bewährt

Ein praktikabler Aufbau setzt auf klare Zonen, die sich auch im kleinen Maßstab betreiben lassen:

• Management-Netz (nur Administration): Proxmox-UI/SSH, Switch/Firewall-Management; Zugriff nur von einem Admin-Client oder über einen gesicherten Jump-Host.
• Server-/Service-Netz: stabile Dienste wie DNS-Resolver, Reverse Proxy, interne Apps.
• Lab-/Test-Netz: experimentelle VMs/Container, CI-Runs, neue Images.
• IoT-/Gäste-Netz: Smart-Home, Kameras, Gäste; strikt begrenzt.

Wichtig ist nicht die perfekte Anzahl, sondern ein klarer Grundsatz: Management darf nicht „nebenbei“ aus jedem Netz erreichbar sein, und Testsysteme dürfen nicht „ungefiltert“ in die sensibleren Bereiche.

VLAN (virtuelle Netztrennung) sinnvoll umsetzen

VLANs trennen Netze logisch auf demselben Switch. Das reduziert Kabelsalat und sorgt für klare Segmente. Entscheidend ist die saubere Konfiguration an drei Stellen: Switch-Ports (Tagged/Untagged korrekt), Trunk zum Proxmox-Host und die Firewall/Router-Regeln zwischen den Netzen. Häufige Fehler sind „Native VLAN“ versehentlich offen lassen oder Management-Traffic über denselben unkontrollierten Pfad wie Test-Workloads zu führen.

Für kleine Setups genügt oft: ein Trunk-Port zum Hypervisor (tagged für mehrere VLANs) und ein oder zwei Access-Ports für Admin-Client bzw. WLAN-AP. Zwischen den VLANs sollte standardmäßig „deny“ gelten, danach werden nur benötigte Verbindungen erlaubt (z. B. Clients dürfen auf Reverse Proxy, aber Lab darf nicht auf Management).

Proxmox härten: Admin-Zugänge, API und Storage absichern

Admin-Oberfläche und SSH minimal exponieren

Die Proxmox-Weboberfläche und SSH sollten nur im Management-Netz verfügbar sein. Wenn Administration aus dem Alltag-Netz nötig ist, ist ein gesicherter Zugangskanal sinnvoll (z. B. VPN auf dem Router oder ein dedizierter Admin-Jump-Host). Exponierte Management-Ports ins Internet sind im Homelab fast nie notwendig und erhöhen das Risiko massiv.

Bei SSH gilt: Root-Login vermeiden, stattdessen ein eigener Admin-User mit gezielten Rechten. Schlüsselbasierte Anmeldung ist dem Passwortlogin vorzuziehen. Zusätzlich hilft Rate-Limiting auf Firewall-Ebene gegen triviale Passwortsprays.

MFA (Mehrfaktor-Authentifizierung) für Proxmox-Accounts

Für die Weboberfläche sollten administrative Accounts mit MFA abgesichert werden. Das reduziert das Risiko durch gestohlene Passwörter und wiederverwendete Credentials erheblich. Wichtig ist dabei die Betriebsrealität: Recovery-Codes offline sichern, Token/Authenticator nicht auf dem gleichen Gerät wie die Passwortablage betreiben und Notfallzugang definieren (z. B. zweiter Admin-Account, der sicher verwahrt wird).

Auch bei API-Tokens gilt: nur so viel Berechtigung wie nötig, Tokens trennen (pro Tool/Automation eigener Token) und regelmäßige Rotation einplanen. Das verhindert, dass ein kompromittiertes CI-System automatisch Vollzugriff auf die Virtualisierungsebene erhält.

Storage und Backups: Trennen, damit ein Ausbruch nicht alles löscht

Im Homelab ist das größte Risiko oft nicht der Initialzugriff, sondern der Folgeschaden: Ransomware oder ein Angreifer löscht Snapshots und Backups. Hilfreich ist eine klare Trennung: Produktive Daten (z. B. Fotos, Dokumente) nicht im gleichen Rechtekontext wie Test-VMs. Backups sollten nicht mit denselben Credentials erreichbar sein wie die Workloads, die gesichert werden.

Falls Proxmox-Backups genutzt werden: Zielsystem und Credentials so gestalten, dass ein kompromittierter Gast nicht einfach das Backup-Repository löschen kann. Mindestens ein Backup-Pfad sollte „kalt“ oder logisch getrennt sein (z. B. nur zeitweise gemountet oder über getrennte Accounts).

Regeln zwischen den Netzen: Was darf wirklich wohin?

Default-Deny als Ausgangspunkt, dann gezielt freischalten

Eine robuste Netztrennung steht und fällt mit den Firewall-Regeln am Router oder der zentralen Firewall. Bewährt hat sich: Inter-VLAN-Verkehr zunächst komplett blocken, danach einzelne, dokumentierte Ausnahmen erlauben. Typische Freigaben sind:

• Clients → Reverse Proxy (HTTP/HTTPS) im Service-Netz
• Clients → DNS/NTP im Service-Netz
• Admin-Client → Proxmox-Management (Web/SSH) im Management-Netz
• IoT → nur benötigte Ziele (z. B. Update-Server), keine Zugriffe auf Management

Zusätzlich sinnvoll: Ausgehenden Traffic aus dem Lab-/Test-Netz begrenzen. Viele kompromittierte Systeme fallen zuerst durch verdächtige ausgehende Verbindungen auf (Command-and-Control, massives Scanning). Wer Egress-Regeln setzt, verhindert oft die zweite Angriffsphase.

Firewall (Paketfilter) und Proxmox-eigene Filter: Zuständigkeiten trennen

Viele bauen Regeln sowohl am Router als auch auf dem Proxmox-Host. Das kann funktionieren, wenn klar ist, wer was macht. Als praxistaugliche Aufteilung gilt: Der Router/Firewall macht Inter-VLAN und Internet-Egress; Proxmox-Firewall schützt Management und einzelne VMs/Bridges vor „Nachbarn“ im gleichen Segment. Doppeltes Regelwerk ohne Dokumentation führt dagegen schnell zu Fehlern und „temporären“ Ausnahmen, die bleiben.

Für das Troubleshooting ist es hilfreich, Regeln in Schichten zu betrachten: (1) physischer/virtueller Switch, (2) Router/Firewall, (3) Host-Firewall, (4) VM-Firewall. Fehler entstehen häufig durch falsch getaggte VLANs oder durch Regeln, die in einer Schicht etwas erlauben, das in einer anderen stillschweigend blockiert wird.

Updates, Images und Automatisierung: Sicherheit wartbar halten

Patch-Rhythmus definieren, ohne den Betrieb zu riskieren

Ein Homelab scheitert oft an Wartung: Updates werden verschoben, weil „gerade alles läuft“. Besser ist ein fester Rhythmus: z. B. monatliches Wartungsfenster für Hosts und stabile Dienste, häufiger für öffentlich erreichbare Komponenten (Reverse Proxy, Webapps). Vorher snapshots/Backups erstellen, danach kurz testen: Login, DNS, Storage, wichtige Container.

Für Proxmox selbst gilt: Updates nur aus vertrauenswürdigen Repositories, und Änderungen an Kernel/ZFS/LXC bewusst planen. Wer Verfügbarkeit braucht, profitiert von einer kleinen Staging-VM oder einem Test-Node, um Updates einmal durchlaufen zu lassen, bevor der Hauptknoten an der Reihe ist. Passend dazu: sicheres Patchen als Prozessprinzip, nicht als einmalige Aktion.

Container- und VM-Templates nur kontrolliert übernehmen

Viele Homelab-Dienste kommen als fertige Container-Images oder VM-Appliances. Das spart Zeit, kann aber Altlasten mitbringen: unnötige Ports, unsichere Defaults, veraltete Pakete. Praktisch ist ein Standard-Check pro neuem Template: Welche Ports lauschen? Welche User existieren? Welche Secrets sind hinterlegt? Läuft der Dienst mit Root-Rechten? Ein kurzer Scan mit Bordmitteln (netstat/ss, Prozessliste, Paketstand) reicht oft, um grobe Fehler zu finden.

Für Docker/LXC gilt zusätzlich: Keine sensiblen Host-Pfade einbinden, wenn es nicht nötig ist, und Privileged-Container vermeiden. Wer Container intensiver nutzt, findet ergänzende Maßnahmen im Beitrag Container absichern.

Konkrete Schritte für ein sicheres Setup ohne Overkill

In 60–90 Minuten realistisch umsetzbar

• Management-Zugänge (Proxmox-UI/SSH) in ein eigenes Netz legen und aus dem Alltagsnetz sperren.
• Mindestens drei Netze definieren: Management, Services, Lab/IoT (kombinierbar, falls klein).
• Inter-VLAN-Regeln am Router auf „blocken“ stellen und nur notwendige Ports freigeben.
• MFA für administrative Web-Logins aktivieren und Recovery-Codes offline sichern.
• Für jede Automatisierung eigene Tokens/Accounts nutzen und Rechte minimieren.
• Öffentlich erreichbare Dienste nur über einen Reverse Proxy veröffentlichen; direkte Portfreigaben vermeiden.
• Update-Rhythmus festlegen und für kritische Komponenten ein kurzes Wartungsfenster einplanen.

Häufige Praxisfragen: Was ist im Homelab „gut genug“?

Muss jedes Gerät ein eigenes VLAN bekommen?

Nein. Für die meisten Setups reicht es, „unsaubere“ Bereiche zusammenzufassen (IoT/Gäste) und Admin/Management strikt zu trennen. Ein VLAN pro Gerätekategorie ist dann sinnvoll, wenn das Risiko oder der Funktionsbedarf stark abweicht (z. B. Kameras vs. Medienserver). Entscheidend ist die Regelbasis: Ein zusätzliches VLAN ohne passende Filter bringt kaum Gewinn.

Ist ein VPN Pflicht, wenn von unterwegs administriert wird?

Für administrative Zugriffe ist ein VPN in der Praxis die stabilste und übersichtlichste Lösung, weil Management-Ports nicht ins Internet müssen. Alternativen (z. B. einzelne Dienste über Reverse Proxy) erhöhen Komplexität und Fehlerrisiko. Falls Fernzugriff ein Thema ist, hilft die Einordnung aus sicherer Fernzugriff ohne RDP als Entscheidungsgrundlage.

Wie wird sichtbar, ob die Trennung wirklich wirkt?

Ein einfacher Test ist ein kontrolliertes „Kann ich von Netz A nach Netz B?“: Ping/Traceroute (falls erlaubt), Porttests (z. B. ob 8006/22 ins Management erreichbar sind), DNS-Auflösung und Zugriff auf definierte Services. Zusätzlich lohnt ein Blick in Router-Logs: Blockierte Verbindungen aus dem Lab-Netz zeigen schnell, ob unerwartete Kommunikation stattfindet. Wer Windows-Clients nutzt, kann ergänzend Windows-Logs auswerten, um verdächtige Anmelde- oder Netzwerkereignisse besser einzuordnen.