UDM Pro 1.x: Netzwerktrennung - Teil 1
Alle Aussagen in diesem Artikel beziehen sich auf die UnifiOS Version 1.10.0 für die UDM Pro und die Unifi Network in Version 6.2.26. Mit jedem Update sowohl von UnifiOS als auch der Network App kann sich das Netzwerk-Setup und die IPv6 Unterstützung grundlegend ändern.
Es gibt eine aktualisierte Version des Artikels in dem eine angepasste Version des Scripts, die mit UnifiOS 3.2.7 kompatibel ist beschrieben wird: UDM Pro 3: Netzwerktrennung - Teil 1.
01| Default Segmentierung in UnifiOS
Ich habe mir die Unifi Dream Machine Pro vor allem gekauft, damit ich mein internes Netzwerk in unterschiedliche VLANs aufteilen kann. Vor allem sollen die internen Teilnetzwerke untereinander nicht mehr ungefiltert kommunizieren können, damit die weniger vertrauenswürdigen IoT-Geräte nicht mehr mit den anderen internen Systemen kommunizieren können. Je nachdem, ob im internen Netzwerk auch IPv6 eingesetzt wird (siehe auch UDM Pro: IPv6 hinter einer FRITZ!Box einrichten) wurden, muss die Filterung dabei für beide Protokolle sichergestellt werden.
Bei der Dream Machine Pro wird hierzu zwischen den drei Sicherheitszonen WAN, LAN und Guest unterschieden. Während das WAN statisch für die beiden WAN-Interfaces angewendet werden, können die Sicherheitszone Corporate oder Guest bei der Einrichtung des Netzwerks über den entsprechenden Eintrag unter Purpose
festgelegt werden:

Um zu verstehen, ob und wie zwischen den unterschiedlichen Netzwerken gefiltert wird, muss zunächst der grundlegende Filtermechanismus der UDM Pro erläutert werden.
01.1| Corporate-Netzwerke
Alle VLANs, die einem LAN-Netzwerk zugeordnet sind (im Unifi-Jargon auch Corporate Network genannt), können dabei in der Standardeinstellung ungefiltert miteinander kommunizieren. Sowohl über IPv4 als auch über IPv6:


01.1.1| Trennung der Corporate-Netzwerke - IPv4
Um eine manuelle Trennung der LAN-Netzwerke kommt man hier also nicht herum. Das ist für die IPv4-Trennung auch grundsätzlich kein Problem und ist mit etwas Aufwand über Firewall-Regeln leicht zu implementieren. Wie das erreicht werden kann findet sich in zahlreichen Anleitungen im Internet. Im Prinzip wird dabei für jedes LAN-Segment eine DROP- oder REJECT-Regel erstellt, die direkt vor den Built-In-IPv4-Regeln eingefügt werden. Über dedizierte ACCEPT-Regeln vor diesen DROP-/REJECT-Regeln können dann gezielt Dienste freigegeben werden.
01.1.1| Trennung der Corporate-Netzwerke - IPv6
Schwieriger wird es jedoch bei der Trennung auf IPv6-Ebene. Wird vom Provider ein statisches IPv6-Prefix bereitgestellt, so kann dass oben beschriebene Prinzip mit den DROP-/REJECT-Regeln auch für IPv6 umgesetzt werden. Das Prinzip funktioniert allerdings nicht mehr, wenn sich das IPv6-Prefix von Zeit zu Zeit ändert bzw. ändern kann (dynamisches IPv6-Prefix). Damit das Regelwerk dann noch korrekt funktioniert, müssen bei einem Prefix-Wechsel auch die IPv6-Firewall-Regeln angepasst werden. Zwar sind intern für die unterschiedlichen VLAN-Segmente bereits intern entsprechende IP-Sets vorgesehen, diese können in der Web-Oberfläche allerdings nicht verwendet werden. Eine Verwaltung der IPv6-Firewall-Regeln für die Trennung der Corporate-Netzwerke mit dynamischen IPv6-PRefixen ist damit nicht möglich. Zumindest sind alle Versuche und Lösungsvorschläge die ich gefunden habe gescheitert (siehe z.B. Quellen [02] - [05]).
01.2| Guest-Netzwerken
Netzwerke vom Typ "Guest" sind deutlich eingeschränkter. Diese Netze können laut Default-Regeln nicht auf die LAN/Corporate Netzwerke zugreifen (siehe Regeln 3004-3006 bzw. 3007 - 3010):


01.2.1| Trennung der Guest-Netzwerke - IPv4
Schaut man sich die Regeln per SSH genauer an, so sind im Wesentlichen folgende iptables-Regeln für die Trennung der Guest-Netzwerke auf IPv4 ebene verantwortlich:
num pkts bytes target prot opt in out source destination
4 0 0 RETURN all -- any any anywhere anywhere match-set UBIOS_guest_pre_allow dst /* 00000001095216663483 */
5 0 0 DROP all -- any any anywhere anywhere match-set UBIOS_guest_restricted dst /* 00000001095216663484 */
6 0 0 DROP all -- any any anywhere anywhere match-set UBIOS_corporate_network dst /* 00000001095216663485 */
7 0 0 DROP all -- any any anywhere anywhere match-set UBIOS_remote_user_vpn_network dst /* 00000001095216663486 */
Die in den Regeln genutzten IP-Sets sind bei mir folgendermaßen konfiguriert:
IP-Set | Beschreibung |
UBIOS_guest_pre_allow | Dieses IP-Set war bei mir leer, so dass die iptables-Regel 4 (s.o.) keine Wirkung hat. |
UBIOS_guest_restricted | In diesem IP-Set sind die RFC1918 Adressen (192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12) hinterlegt. Dadurch wird dien Kommunikation aus einem Gast-Netzwerk in alle privaten Netzwerke über iptables-Regel 5 (s.o.) unterbunden. |
UBIOS_corporate_network | Dieses Set beinhaltet die IPv4-Adressbereiche der definierten Corporate-/LAN-Netzwerke. Mit der iptables-Regel 6 wird damit der Datenverkehr zu den Corporate-Netzwerken unterbunden. |
UBIOS_remote_user_vpn_network | Dieses IP-Set war bei mir ebenfalls leer und wird wohl nur gefüllt, wenn auch ein VPN eingerichtet wird. Ich gehe davon aus, dass über diese Regel also der Verkehr zu etwaigen VPN-Clients eingeschränkt wird. |
Damit werden die Guest-Netzwerke von LAN-/Corporate-Netzwerken auf IPv4-Ebene ordentlich voneinander getrennt.
Der IPv4-basierte Datenverkehr zwischen zwei Guest-Segmenten wird allerdings über die folgenden Regeln zugelassen:
num pkts bytes target prot opt in out source destination
8 53 6241 RETURN all -- any any 192.168.xx.0/24 anywhere /* 00000001095216666481 */
9 0 0 RETURN all -- any any 192.168.yy.0/24 anywhere /* 00000001095216666482 */
01.2.1| Trennung der Guest-Netzwerke - IPv6
Eine ähnliche Trennung ist auch für IPv6 mittels ip6tables umgesetzt:
num pkts bytes target prot opt in out source destination
1 0 0 DROP all any any anywhere anywhere match-set UBIOS_corporate_networkv6 dst /* 00000001095216663487 */
2 0 0 DROP all any any anywhere anywhere match-set UBIOS_NETv6_br1 dst /* 00000001095216663488 */
3 0 0 DROP all any any anywhere anywhere match-set UBIOS_NETv6_br2 dst /* 00000001095216663489 */
4 0 0 DROP all any any anywhere anywhere match-set UBIOS_NETv6_br3 dst /* 00000001095216663490 */
In dem IP-Set UBIOS_corporate_networkv6
waren bei mir zwar keine Adressen hinterlegt, aber dafür sind in den Sets UBIOS_NETv6_br1-3
die IPv6-Adressen der LAN-Segmente hinterlegt.
Mit den folgenden RETURN-Regeln wird vergleichbar zur IPv4 Kommunikation auch die Kommunikation zwischen den Guest-Netzwerken zugelassen:
num pkts bytes target prot opt in out source destination
5 0 0 RETURN all any any anywhere anywhere match-set UBIOS_NETv6_br100 src /* 00000001095216663491 */
6 0 0 RETURN all any any anywhere anywhere match-set UBIOS_NETv6_br101 src /* 00000001095216663492 */
7 0 0 RETURN all any any anywhere anywhere match-set UBIOS_NETv6_br100 src /* 00000001095216663493 */
8 0 0 RETURN all any any anywhere anywhere match-set UBIOS_NETv6_br101 src /* 00000001095216663494 */
Da es in den entsprechenden Chains UBIOS_GUEST_IN_USER
keine ESTABLISHED
oder RELATED
-Verbindungen zugelassen werden, können auch aus dem Corporate-Netzwerk keine Verbindungen in Richtung Guest-Netzwerke initiiert werden. Damit sind die Guest-Netzwerke zwar von den Corporate-Netzwerken weitgehend getrennt, aber eben nicht untereinander. Soll eines der Guest-Netzwerke also tatsächlich für den Internetzugang für Gäste bereitstellen, so können die Gäste theoretisch auch auf die anderen Gast-Netzwerke zugreifen in denen beispielsweise die IoT-Geräte untergebracht sind.
Hinweis zur Trennung zwischen Corporate und Guest-Netzwerken: Mit den vordefinierten Firewall-Regeln kann zwar keine Verbindung vom Coporate-Netzwerk in Guest-Netzwerke hergestellt werden, aber einzelne Pakete können in das Guest-Netzwerk gelangen. Wird beispielsweise ein Ping vom Corporate-Netzwerk an einen Client im Guest-Netzwerk gesendet, so wird dieser von der UDM Pro nicht gefiltert, sondern erreicht sein Ziel. Lediglich die Antwort aus dem Guest-Netzwerk, die an das Corporate-Netzwerk gesendet wird, wird geblockt. Somit können theoretisch Informationen über interne Systeme in das Guest-Netzwerk fließen. Soll dass verhindert werden, so müssen die Guest-Netzwerke in der LAN-In entsprechend ebenfalls gefiltert werden.
Es bleibt noch anzumerken, dass in UnifiOS 1.10.0 die IPv6-Implementierung scheinbar nicht korrekt funktioniert. Wird das IPv6-PD aktiviert, so erhält zwar das UDM-Pro Interface in dem jeweiligen Guest-Netzwerk zwar eine IPv6 Adresse, allerdings wird den Clients in den Guest-Netzwerken keine IPv6-Adresse zugewiesen. Aus meiner Sicht ein Bug in dem IPv6 Firewall Regelwerk, da scheinbar nicht die nötigen IPv6-ICMP oder DHCPv6-Ports freigegeben werden.
02| Zwischenstand
Um eine angemessene Netzwerktrennung auf IPV4 und IPv6 mit dynamischen Prefixen umsetzen zu können, biete die Unifi Verwaltungsoberfläche aktuell keine ausreichenden Möglichkeiten. Eine DIY-Lösung auf Basis des On-Boot-Scriptes von boostchicken, die ich auch schon zur Deaktivierung des "Unifi Zwangs-NAT" verwendet habe, ist daher wohl die einzige Lösung.
Es ergeben sich also folgende Punkte, die beim Aufbau des Netzwerks aktuell zu berücksichtigen sind:
- Eine Trennung der Corporate-Netzwerke muss manuell erfolgen. Während das für IPv4 mit etwas Aufwand über die GUI zu erledigen ist, ist das bei dynamischen IPV6-Prefixen in der GUI nicht möglich. Hier ist in der aktuellen Version eine Lösung mittels Scripten zu realisieren. Dabei sollten nach Möglichkeit jedoch immer die Board-Mittel verwendet werden, da bei individuellen Scripten immer die Gefahr besteht, dass diese mit dem nächsten Firmware-Update nicht mehr funktionieren und die Netzwerktrennung dann ausgehoben wird, aufgrund des Default-Allow-Ansatzes für die Corporate Netzwerke.
- Sollen einzelne Netzwerksegmente möglichst sicher vom internen LAN bzw. den Corporate-Netzwerken getrennt werden, so sollte der Netzwerktyp
Guest
verwendet werden. Geräte in diesen Netzwerken sollten auch dann nicht auf Geräte im internen LAN Zugreifen können, wenn einon_boot
-Script z.B. nach einem Firmware-Update nicht mehr korrekt funktioniert. - Ist IPv6 zwingend erforderlich, so sollten Guest-Netzwerke aktuell eher vermieden werden, da aktuell die Zuweisung von IPv6 Adressen nicht funktioniert. Vermutlich sollte man die IPv6-PD für Guest-Netzwerke eher komplett deaktivieren, solange die IPv6-Implementierung nicht korrekt implementiert ist.
Im nächsten Artikel werde ich zusammenfassen, wie ich das Firewall-Regelwerk angepasst habe, damit eine angemessene Filterung umgesetzt wird
03| Quellen
[01] weberblog.net: Tag Archives: IPv6 Dynamic Prefix
[02] IPv6 Network Segmentation Strategy
[03] IPv6 firewall rules in Unifi controller
[04] Firewall rules for IPv6 hosts with dynamic prefix from ISP
[05] Inbound Firewall rules with DHCPv6-PD
Kommentare