Öffentliche Server sicher in einem UniFi-Netzwerk hosten

Das Hosten eines öffentlich zugänglichen Servers – etwa eines Raspberry Pi mit Webserver, Nextcloud oder einer benutzerdefinierten Anwendung – ist eine hervorragende Möglichkeit, die Kontrolle über die eigenen Daten zu übernehmen. Die Exposition eines Geräts im lokalen Netzwerk gegenüber dem Internet birgt jedoch erhebliche Sicherheitsrisiken. Wenn der Raspberry Pi kompromittiert wird, bietet eine flache Netzwerkarchitektur einem Angreifer freien Zugang zu den persönlichen Computern, NAS-Systemen und Smart-Home-Geräten.

Die Lösung ist die Netzwerktrennung mithilfe von VLANs (Virtual Local Area Networks). In einer ordnungsgemäßen DMZ-Architektur (Demilitarized Zone) sollte der Raspberry Pi aus dem Internet und aus dem vertrauenswürdigen internen Netzwerk erreichbar sein, aber das Pi selbst muss strikt daran gehindert werden, Verbindungen zu diesen vertrauenswürdigen Geräten zu initiieren. Hier ist eine technische Analyse zur Einrichtung dieser Architektur im Ubiquiti UniFi-Ökosystem, wobei die Unterschiede zwischen dem alten Firewall-Ansatz und der modernen zonenbasierten Einrichtung hervorgehoben werden.

Das Ziel

Bevor wir zur Konfiguration kommen, definieren wir die Anforderungen an den Datenverkehr für den Raspberry Pi (RPI), der sich in einem dedizierten VLAN befindet (z. B. VLAN 50 – DMZ):

• Internet zu RPI: Erlaubt (beschränkt auf bestimmte weitergeleitete Ports wie 80/443).
• Internes LAN zu RPI: Erlaubt (für SSH-Verwaltung oder Zugriff auf interne Dashboards).
• RPI zu Internet: Erlaubt (für Software-Updates und ausgehende API-Aufrufe).
• RPI zu internem LAN: Strikte Blockierung (zur Eindämmung potenzieller Sicherheitsverletzungen).

Das “alte” Setup: Klassische Firewall-Regeln (LAN IN)

Bevor Ubiquiti die Firewall-Oberfläche überarbeitete, erforderte die Netzwerktrennung ein tiefes Verständnis des Paketflusses im iptables-Stil – insbesondere der LAN IN-, LAN OUT- und LAN LOCAL-Ketten. Um das Raspberry-Pi-VLAN zu isolieren, mussten manuell Regeln im LAN IN-Tab gestapelt werden (welcher den Verkehr steuert, der aus einem lokalen Netzwerk in den Router eintritt, bevor er weitergeleitet wird).

Die Abfolge der klassischen Regeln sah so aus:

1. Erlaubnis für “Established and Related”-Traffic: Dies stellt sicher, dass der Rückverkehr erlaubt ist, wenn ein vertrauenswürdiger PC eine SSH-Verbindung zum RPI initiiert.
2. Verwerfen von DMZ zum vertrauenswürdigen LAN: Diese Regel blockiert neue Verbindungen vom RPI zum privaten Netzwerk. Da sie unter der ersten Regel steht, kann der RPI weiterhin auf Anfragen antworten; neue Verbindungsversuche ins private Netzwerk werden dagegen verworfen.

Diese Methode war effektiv, aber fehleranfällig. Ein einfacher Fehler in der Reihenfolge oder ein Missverständnis zwischen LAN IN und LAN LOCAL führte oft zu defekten Setups oder einem falschen Sicherheitsgefühl.

Das “neue” Setup: Zonenbasierte Verkehrsregeln

Mit UniFi Network 9.0 hat Ubiquiti eine moderne, zonenbasierte Firewall eingeführt. Diese hat die getrennten Ansichten für Firewall-Regeln und Verkehrsregeln (Traffic Rules) als Ort dieser Konfiguration abgelöst; vorhandene Regeln werden bei der Umstellung in Zonen-Policies überführt. Statt die komplexen Routing-Ketten (LAN IN/OUT) einzeln zu konfigurieren, legst du fest, welcher Verkehr zwischen den Zonen erlaubt sein soll.

Statt Pakete auf ihrem Weg durch die internen Schnittstellen des Routers zu verfolgen, werden Richtlinien zwischen Zonen definiert. Eine Zone ist dabei kein einzelnes Netzwerk, sondern eine Gruppe von Netzwerken und Schnittstellen: Das DMZ-VLAN kommt in eine DMZ-Zone, die vertrauenswürdigen Netze in eine interne Zone. Eine Policy wählt anschließend eine Quell- und eine Zielzone. Die folgenden Angaben beziehen sich auf UniFi Network 10.4 (Stand August 2026).

So gelingt die Isolierung in der modernen UniFi-Oberfläche:

1. Unter Settings > Policy Engine die Zonen-Matrix öffnen (in UniFi Network 9.x lag der Bereich unter Settings > Security).
2. Die Netzwerke den Zonen zuordnen: das DMZ-VLAN der DMZ-Zone, die vertrauenswürdigen Netze der internen Zone.
3. In der Matrix die Zelle öffnen, in der die Quellzone DMZ auf die Zielzone Intern trifft, und dort eine Policy anlegen.
4. Aktion: Block (oder Reject, wenn der Absender statt eines stillen Verwerfens eine Fehlermeldung erhalten soll).
5. Quelle: Zone DMZ, bei Bedarf eingegrenzt auf den Raspberry Pi. Ziel: Zone Intern, bei Bedarf eingegrenzt auf die zu schützenden Netze.
6. Policy speichern. Die Gegenrichtung Intern zu DMZ hat eine eigene Zelle in der Matrix und bleibt erlaubt.

Die Magie der Zonen: Unter der Haube übernimmt der UniFi-Controller automatisch die zustandsorientierte Überprüfung (Stateful Inspection). Er weiß von Natur aus, dass “Established and Related”-Traffic erlaubt werden muss, ohne dass es dafür eine dedizierte Regel braucht. Die vertrauenswürdigen Geräte können mit dem Raspberry Pi sprechen, aber wenn das Pi kompromittiert wird und versucht, das NAS anzupingen, wirkt die Zonenregel wie eine Ziegelmauer. Die Konfiguration ist dadurch wesentlich sauberer, besser lesbar und weniger fehleranfällig.

Ein Hinweis zur Portweiterleitung (Port Forwarding)

Sobald der Raspberry Pi sicher in einem eigenen VLAN isoliert ist, muss er für die Außenwelt zugänglich werden. Klassischerweise brauchte es dafür eine manuell erstellte Destination NAT (DNAT)-Regel und eine entsprechende WAN IN-Firewall-Regel.

Ubiquiti macht dies extrem einfach:

1. Der Bereich liegt unter Settings > Policy Engine > Port Forwarding (Pfad in UniFi Network 10.4).
2. Auf “Create New Port Forwarding Rule” klicken.
3. Den Port (z. B. 443 für HTTPS) und die Ziel-IP des Raspberry Pi definieren.
4. Das war’s. Der UniFi-Controller provisioniert automatisch die notwendigen NAT-Übersetzungen und injiziert dynamisch die WAN IN-Firewall-Regeln, damit der externe Datenverkehr diesen spezifischen Port im isolierten VLAN erreichen kann. Der öffentliche Server ist nun online und sicher vom privaten Netz abgeschottet.