UDM Pro: Netzwerktrennung - Teil 1

Hinweis vorab: 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.

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: 

Unifi Network > Settings > Network > Create Network

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:

IPv4 Default Rules für LAN In und Out
IPv4 Default Rules für LAN In und Out
IPv6 Default Rules für LAN In und Out
IPv6 Default Rules für LAN In und Out

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):

IPv4 Default Rules für Guest In (bei zwei definierten Guest-Netzen und 3 LAN-Netzen)
IPv4 Default Rules für Guest In (bei 2 definierten Guest-Netzen und 3 LAN-Netzen)
IPv6 Default Rules für Guest In (bei 2 definierten Guest-Netzen und 3 LAN-Netzen)
IPv6 Default Rules für Guest In (bei 2 definierten Guest-Netzen und 3 LAN-Netzen)

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-SetBeschreibung
UBIOS_guest_pre_allowDieses IP-Set war bei mir leer, so dass die iptables-Regel 4 (s.o.) keine Wirkung hat.
UBIOS_guest_restrictedIn 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_networkDieses 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_networkDieses 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:

  1. 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. 
  2.  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 ein on_boot-Script z.B. nach einem Firmware-Update nicht mehr korrekt funktioniert.
  3. 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

PostadresseE-MailadresseFestnetzMobiltelefonSMS/SignalThreemaTwitter DirektnachrichtFAXWeb Page