UDM Pro 3: Netzwerktrennung - Teil 2

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 Firewall-Einstellungen grundlegend ändern.

Da die einzelnen LAN- und Guest-Netzwerke von der Unifi Dream Machine Pro auch mit UnifiOS 3.2.7 und Unifi Network 8.0.26 leider immer noch nicht konsequent voneinander getrennt werden (siehe Artikel UDM Pro 3: Netzwerktrennung - Teil 1) muss das Firewall-Regelwerk wohl oder übel per Script angepasst werden, damit die einzelnen VLANs voneinander getrennt werden. 

01| Voraussetzungen

Da eine Filterung für IPv6 bei dynamischen Prefix über die GUI aktuell nicht zu realisieren ist (siehe UDM Pro 3: Netzwerktrennung - Teil 1), muss das Firewall-Regelwerk per Script aktualisiert werden. Es muss also sichergestellt werden, dass das Script beim Boot der Unifi Dream Machine Pro automatisch ausgeführt wird. Dies lässt sich mit UnifiOS 3.x per systemd erreichen. 

Aber die Ausführung beim Boot alleine ist nicht ausreichend, da mit jeder Änderung am Firewall-Regelwerk per GUI die alten Regeln gelöscht werden. Daher wird nicht nur ein systemd-Service sondern zusätzlich auch noch ein systemd-Timer eingerichtet, der das Script zusätzlich alle zwei Minuten erneut ausführt. Dadurch werden die Regeln wieder eingefügt werden, wenn sie nicht mehr da sind. 

02| Script installieren und konfigurieren

Die Installation des udm-firewall-Sripts ist mit git schnell erledigt:

mkdir -p /data/custom
dpkg -l git || apt install git
git clone https://github.com/nerdiges/udm-firewall.git /data/custom/firewall
chmod +x /data/custom/wireguard/udm-firewall.sh

02.1| Anpassung der Konfiguration

Bei Bedarf kann das Script noch angepasst werden. Dazu können die entsprechenden Konfigurationsvariablen direkt am Anfang des Scripts udm-firewall.sh angepasst werden. Allerdings werden die Änderungen beim nächsten Update des Scripts wieder überschrieben. Muss bzw. soll die Konfiguration angepasst werden, sollten die Änderungen in der Datei /data/custom/firewall/udm-firewall.conf gespeichert werden. Folgende Parameter können aktuell über die Umgebungsvariablen angepasst werden:

######################################################################################
#
# Configuration
#

# Add rules to separate LAN interfaces
separate_lan=true

# Add rules to separate Guest interfaces
separate_guest=true

# interfaces listed in exclude will not be separted and can still access
# the other VLANs. Multiple interfaces are to be separated by spaces.
exclude="br20"

# Add rule to allow established and related network traffic coming in to LAN interface
allow_related_lan=true

# Add rule to allow established and related network traffic coming in to guest interface
allow_related_guest=true

# Remove predefined NAT rules 
disable_nat=true

# List of commands that should be executed before firewall rules are adopted (e.g. setup 
# wireguard interfaces, before adopting ruleset to ensure wireguard interfaces are 
# considerd when  separating VLANs).
# It is recommended to use absolute paths for the commands.
commands_before=(
    "[ -x /data/custom/wireguard/udm-wireguard.sh ] && /data/custom/wireguard/udm-wireguard.sh"
    ""
)

# List of commands that should be executed after firewall rules are adopted.
# It is recommended to use absolute paths for the commands.
commands_after=(
    "[ -x /data/custom/ipv6/udm-ipv6.sh ] && /data/custom/ipv6/udm-ipv6.sh"
    ""
)

#
# No further changes should be necessary beyond this line.
#
######################################################################################

Wurden in der *Unifi Network* Oberfläche zwei Corporate-Network VLANs mit den VLAN-IDs 20 und 21 konfiguriert, so werden in UnifiOS die Interfaces *br20* und *br21* angelegt. Der Traffic *br20* -> *br21* wird dabei grundsätzlich zugelassen (siehe `$exclude`). Alle weiteren LAN und Guest VLANs werden separiert.

Es werden außerdem Firewall-Regeln erstellt, die das Connection-Tracking aktiviert und Pakete mit dem Status `established`und `related` zulässt (siehe `$allow_related_lan`und `$allow_related_guest`) und die Default NAT Regeln werden werden entfernt bzw. deaktiviert (siehe `$disable_nat`).

Über die Umgebungsvariablen $commands_before und $commands_after, können Scripte festgelegt werden, die vor bzw. nach der Erstellung der Separationsregeln automatisch ausgeführt werden. Dadurch können Abhängigkeiten von Scripten einfach abgebildet werden. In der Standardkonfiguration wird beispielsweise vor der Implementierung der Firewall-Regeln das Script zum Einrichten von Wireguard-VPNs aufgerufen (siehe udm-wireguard). Dadurch wird sichergestellt, dass die Wireguard-Interfaces bereits existieren und bei der Erstellung des Firewall-Regelwerks direkt mit berücksichtgt werden. Nachdem die Regeln erstellt wurden, wird dann noch die IPv6-Verbindung sichergestellt, so dass erst die Trennung umgesetzt wird, bevor die IPv6-Verbindung final eingerichtet wird (siehe udm-ipv6).

Mit Ausführung des Skriptes werden die VLANs voneinander getrennt. Daher sollten die Verbindungen, die zwischen den Systemen unterschiedlicher VLANs möglich sein sollen, am besten vorher in den Firewall-Einstellungen der UDM-Pro eingerichtet werden werden.

Nach der Konfiguration kann durch manuelles Aufrufen des Skriptes /data/custom/wireguard/udm-firewall.sh das Regelwerk bereits angepasst werden. Dabei sollten keine Fehlermeldungen erscheinen. Ist die Option zur  Trennung der LAN-Segmente aktiv (separate_lan=true) und sind mehr als ein LAN-Netzwerk in der Netzwerk App, dann sollten mit dem Kommando iptables -L lan_separation -v entsprechende Regeln ausgegeben werden:

root@unifi:~# iptables -L lan_separation -v

Chain lan_separation (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REJECT     all  --  br0    br11    anywhere             anywhere             reject-with icmp-port-unreachable
    0     0 REJECT     all  --  br0    br12    anywhere             anywhere             reject-with icmp-port-unreachable
 [...]

02.2| systemd-Service einrichten

Nachdem das Skript grundsätzlich funktioniert, muss noch sichergestellt werden, dass es beim Systemstart automatisch ausgeführt wird. Da unter unifiOS 3.x systemd fenutzt werden kann, muss das  on-boot-script der unifios-utilities nicht mehr installiert werden. Stattdessen habe ich einen systemd-Service für udm-firewall zusammen mit einem systemd-Timer eingerichtet. Über den Timer wird sichergestellt, dass das Script nicht nur beim Systemstart, sondern zusätzlich auch alle 90 Sekunden ausgeführt wird. Werden die Firewall-Anpassungen von der Network App gelöscht, so sind sie also spätestens nach 90 Sekunden wieder aktiv. Der Timer und Service werden folgendermaßen eingerichtet:

# Install udm-firewall.service und timer definition file in /etc/systemd/system via:
ln -s /data/custom/firewall/udm-firewall.service /etc/systemd/system/udm-firewall.service
ln -s /data/custom/firewall/udm-firewall.timer /etc/systemd/system/udm-firewall.timer

# Reload systemd, enable and start the service and timer:
systemctl daemon-reload
systemctl enable udm-firewall.service
systemctl start udm-firewall.service
systemctl enable udm-firewall.timer
systemctl start udm-firewall.timer

# check status of service and timer
systemctl status udm-firewall.timer udm-firewall.service

03| Erläuterungen zum Script 

Das Script udm-firewall.sh enthält einige Kommentare, die die Funktionsweise grundsätzlich erklären. Ergänzend dazu hier noch ein paar Hinweise zum Aufbau des Scriptes:

03.1| Hilfsfunktionen

Im Script muss öfter mal geprüft werden, ob eine Regel bereits existiert, damit eine Regel nur bei Bedarf eingefügt werden. Zur Optimierung wird das Firewall-Regelwerk dabei in einer Umgebungsvariable zwischengespeichert, damit es nur einmal abgerufen werden muss und das Script somit deutlich performanter wird:

# Buffer IPv4 ruleset
ipv4rules=$(/usr/sbin/iptables --list-rules)
function in_ip4rules () { [[ $ipv4rules =~ ${1// /\\ } ]] || return 1; }

# Buffer IPv6 ruleset
ipv6rules=$(/usr/sbin/ip6tables --list-rules)
function in_ip6rules () { [[ $ipv6rules =~ ${1// /\\ } ]] || return 1; }

03.2| Interfaces ermitteln

Es  müssen die LAN, Guest und WAN-Interfaces ermittelt werden, damit wir sie später im Script verwendet werden können. Die Interfaces können relativ einfach über die iptables-Chain UBIOS_FORWARD_IN_USER ermittelt werden:

# Get list of relevant LAN interfaces and total number of interfaces
lan_if=$(echo -e "$ipv4rules" | /usr/bin/awk '/^-A UBIOS_FORWARD_IN_USER.*-j UBIOS_LAN_IN_USER/ { print $4 }')
lan_if_count=$(echo $lan_if | /usr/bin/wc -w)

# Get list of relevant guest interfaces and total number of interfaces
guest_if=$(echo -e "$ipv4rules" | /usr/bin/awk '/^-A UBIOS_FORWARD_IN_USER.*-j UBIOS_GUEST_IN_USER/ { print $4 }')
guest_if_count=$(echo $guest_if | /usr/bin/wc -w)

# Get list of WAN interfacess 
wan_if=$(echo -e "$ipv4rules" | /usr/bin/awk '/^-A UBIOS_FORWARD_IN_USER.*-j UBIOS_WAN_IN_USER/ { print $4 }')

03.3| iptables Chains

Damit die Firewall-Regeln des Scripts sauber von den internen Regeln getrennt werden legt das Script zwei neue iptables-Chains an:

ChainBeschreibung
lan_separationIn dieser Chain werden die REJECT-Regeln zur Separierung der LAN-Netzwerke hinterlegt.
guest_separationIn dieser Chain werden die REJECT-Regeln zur Separierung der guest-Netzwerke hinterlegt.
[...]
    # prepare ip(6)tables chains lan_separation
    in_ip4rules "-N lan_separation" || (/usr/sbin/iptables -N lan_separation &> /dev/null  && /usr/bin/logger "$me: IPv4 chain created (lan_separation)")
    in_ip6rules "-N lan_separation" || (/usr/sbin/ip6tables -N lan_separation &> /dev/null && /usr/bin/logger "$me: IPv6 chain created (lan_separation)")

[...]

    # prepare ip(6)tables chains guest_separation
    in_ip4rules "-N guest_separation" || (/usr/sbin/iptables -N guest_separation &> /dev/null && /usr/bin/logger "$me: IPv4 chain created (guest_separation)")
    in_ip6rules "-N guest_separation" || (/usr/sbin/ip6tables -N guest_separation &> /dev/null && /usr/bin/logger "$me: IPv6 chain created (guest_separation)")
[...]

03.4| Firewall-Regeln

Das Script erzeugt insgesamt fünf unterschiedliche Typen von Firewall-Regeln:

03.4.1| Allow Established & Related

Damit später gezielte Verbindungen zwischen den einzelnen VLANs freigegeben werden können, sollten alle eingehenden Pakete zugelassen werden, die einer bestehenden Verbindung zuzuordnen sind (Pakete mit dem Status Established oder Related) an den LAN und Guest Interfaces zugelassen werden. Dies kann entweder manuell in der GUI eingetragen werden oder automatisch vom Script eingefügt werden. Da in der Regel die meisten Pakete einer bereits bestehenden Verbindung zugeordnet werden können, sollten die entsprechenden Regeln möglichst weit vorne im iptables-Regelwerk eingetragen werden, um die Firewall-Performance zu verbessern. Mit dem folgenden Code wird daher im Script sichergestellt, dass die Regeln für die LAN-Interfaces in der Standard-Chain UBIOS_LAN_IN_USER an erster Stelle eingetragen werden:

[...]
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# add allow related/established to UBIOS_LAN_IN_USER if requested
#
if [ $allow_related_lan == "true" ]; then
    rule="-A UBIOS_LAN_IN_USER -m conntrack --ctstate RELATED,ESTABLISHED.*-j RETURN"
    in_ip4rules "$rule" || /usr/sbin/iptables -I UBIOS_LAN_IN_USER 1 -m conntrack --ctstate RELATED,ESTABLISHED -j RETURN
    in_ip6rules "$rule" || /usr/sbin/ip6tables -I UBIOS_LAN_IN_USER 1 -m conntrack --ctstate RELATED,ESTABLISHED -j RETURN
fi

[...]

#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# add allow related/established to UBIOS_LAN_IN_USER if requested
#
if [ $allow_related_guest == "true" ]; then
    rule="-A UBIOS_GUEST_IN_USER -m conntrack --ctstate RELATED,ESTABLISHED -j RETURN"
    in_ip4rules "$rule" || /usr/sbin/iptables -I UBIOS_GUEST_IN_USER 1 -m conntrack --ctstate RELATED,ESTABLISHED -j RETURN
    in_ip6rules "$rule" || /usr/sbin/ip6tables -I UBIOS_GUEST_IN_USER 1 -m conntrack --ctstate RELATED,ESTABLISHED -j RETURN
fi
[...]

Ob die Established & Related-Regeln vom Script automatisch erzeugt werden, kann über die Variablen allow_related_lan und allow_related_guest festgelegt werden. Per Default sind diese aktiviert, so dass das Script sicherstellt, dass entsprechende Regeln vorhanden sind. Um doppelte Regeln zu vermeiden, fügt das Script nur dann eine entsprechende Regel ein, wenn nicht bereits über die GUI eine Regel hinzugefügt wurde.

03.4.2| LAN > LAN Kommunikation unterbinden

Bevor die LAN-Trennung umgesetzt wird, muss zunächst sichergestellt werden, dass von den LAN-Interfaces der Datenverkehr zu öffentlichen IP-Adressen weiterhin möglich bleibt. Ansonsten funktioniert der Internet-Zugriff nicht mehr. In der Chain lan_separation muss daher zunächst Pakete zum WAN zugelassen werden, die nicht an RFC1918 (IPv4) oder ULA-Adressen (IPv6) gerichtet sind:

    # allow Outbound internet traffic to WAN
    for o in $wan_if; do
        # Reject Outbound RFC1918 to deny DMZ access
        rule="-A lan_separation -d 192.168.0.0/16 -o $o -j REJECT"
        in_ip4rules "$rule" || /usr/sbin/iptables $rule
        rule="-A lan_separation -d 172.16.0.0/12 -o $o -j REJECT"
        in_ip4rules "$rule" || /usr/sbin/iptables $rule
        rule="-A lan_separation -d 10.0.0.0/8 -o $o -j REJECT"
        in_ip4rules "$rule" || /usr/sbin/iptables $rule
        rule="-A lan_separation -d 169.254.0.0/16 -o $o -j REJECT"
        in_ip4rules "$rule" || /usr/sbin/iptables $rule

        # Reject Outbound ULA to deny DMZ access
        rule="-A lan_separation -d fc00::/7 -o $o -j REJECT"
        in_ip6rules "$rule" || /usr/sbin/ip6tables $rule

        # Allow all other traffic
        rule="-A lan_separation -o $o -j RETURN"
        in_ip4rules "$rule" || /usr/sbin/iptables $rule
        in_ip6rules "$rule" || /usr/sbin/ip6tables $rule
    done

Für jedes LAN-Interface wird eine Regel erzeugt, die eine Kommunikation zu anderen LAN-Interfaces unterbinden (REJECT-Regeln). Ausgenommen werden allerdings die Interfaces, die in der Variable $exclude aufgelistet sind. Zusammen mit der Regel Allow Established & Related (s.o.) führt das dazu, dass aus diesen Netzwerk-Segmenten auf alle anderen LAN-Netzwerke ungefiltert zugegriffen werden kann. Die entsprechenden Regeln werden in einer for-Schleife automatisch erzeugt:

    # Add rules to separate LAN-VLANs to chain lan_separation
    for i in $lan_if; do
        case "$exclude " in 
            *"$i "*)
                /usr/bin/logger "$me: Excluding $i from LAN separation as requested in config."
            ;;

            *)
                rule="-A lan_separation -i $i -j REJECT"
                in_ip4rules "$rule" || /usr/sbin/iptables $rule
                in_ip6rules "$rule" || /usr/sbin/ip6tables $rule
            ;;
        esac
    done 

Existieren beispielsweise vier Corporate-Networks mit den VLANs 0-3, sowie einem wireguard-Interface wg0 und soll die Kommunikation aus VLAN 1 in alle anderen Netzwerke ermöglicht werden, so muss lediglich das zugehörige Interface br1 in der Exclude-Variablen aufgenommen werden (exclude="br1"). Die erzeugten VLAN-Regeln sollten danach so aussehen:

-N lan_separation
-A UBIOS_LAN_IN_USER -j lan_separation
-A lan_separation -d 192.168.0.0/16 -o eth9 -j REJECT --reject-with icmp-port-unreachable
-A lan_separation -d 172.16.0.0/12 -o eth9 -j REJECT --reject-with icmp-port-unreachable
-A lan_separation -d 10.0.0.0/8 -o eth9 -j REJECT --reject-with icmp-port-unreachable
-A lan_separation -d 169.254.0.0/16 -o eth9 -j REJECT --reject-with icmp-port-unreachable
-A lan_separation -o eth9 -j RETURN
-A lan_separation -d 192.168.0.0/16 -o eth8 -j REJECT --reject-with icmp-port-unreachable
-A lan_separation -d 172.16.0.0/12 -o eth8 -j REJECT --reject-with icmp-port-unreachable
-A lan_separation -d 10.0.0.0/8 -o eth8 -j REJECT --reject-with icmp-port-unreachable
-A lan_separation -d 169.254.0.0/16 -o eth8 -j REJECT --reject-with icmp-port-unreachable
-A lan_separation -o eth8 -j RETURN
-A lan_separation -i br0 -j REJECT --reject-with icmp-port-unreachable
-A lan_separation -i br2 -j REJECT --reject-with icmp-port-unreachable
-A lan_separation -i br3 -j REJECT --reject-with icmp-port-unreachable
-A lan_separation -i wg0 -j REJECT --reject-with icmp-port-unreachable

03.4.3| Guest > Guest Kommunikation unterbinden

Vergleichbar zur Trennung der LAN-Segmente, werden auch die Guest-Netzwerke voneinander getrennt. Diese Regeln werden allerdings in der Chain guest_separation eingetragen. Auch für die Guest-Netzwerke gilt: Wird ein Guest-Interface in die Exclude Liste aufgenommen, so wird es von der Filterung ausgenommen. 

03.4.5| Einbindung der Chains lan_separation un guest-separation

Nachdem die Firewall-Regeln zur VLAN-Trennung in den Chains lan_spearation und guest_separation eingefügt wurden, werden entsprechende JUMP-Regeln in die Chains UBIOS_LAN_IN_USER und UBIOS_GUEST_IN_USER eingefügt. Dabei wird vom Script automatisch die richtige Position für die JUMP-Regeln ermittelt, so dass die Regeln direkt  vor den jeweiligen ALLOW-Regeln des Standard-Regelwerks eingefügt werden. Für die IPv4-Regeln zur LAN-Trennung sieht das im Script so aus:

[...]

    # add IPv4 rule to include rules in chain lan_separation
    if ! in_ip4rules "-A UBIOS_LAN_IN_USER -j lan_separation" ; then
        rules=$(/usr/sbin/iptables -L UBIOS_LAN_IN_USER --line-numbers | /usr/bin/awk 'END { print $1 }')
        v4_idx=$(/usr/bin/expr $rules - $lan_if_count)
        /usr/sbin/iptables -I UBIOS_LAN_IN_USER $v4_idx -j lan_separation
    fi 

    # add IPv6 rule to include rules in chain lan_separation
    if ! in_ip6rules "-A UBIOS_LAN_IN_USER -j lan_separation" ; then
        v6_idx=$(/usr/sbin/ip6tables -L UBIOS_LAN_IN_USER --line-numbers | /usr/bin/awk '/match-set UBIOS_ALL_NETv6_br[0-9]+ src \/\*/{ print $1; exit}')
        /usr/sbin/ip6tables -I UBIOS_LAN_IN_USER $v6_idx -j lan_separation
    fi

[...]

    if ! in_ip6rules "-A UBIOS_GUEST_IN_USER -j guest_separation" ; then
        # add IPv4 rule to include rules in chain guest_separation
        rules=$(/usr/sbin/iptables -L UBIOS_GUEST_IN_USER --line-numbers | /usr/bin/awk 'END { print $1 }')
        v4_idx=$(expr $rules - $guest_if_count)
        /usr/sbin/iptables -I UBIOS_GUEST_IN_USER $v4_idx -j guest_separation
    fi

    # add IPv6 rule to include rules in chain guest_separation
    if ! in_ip6rules "-A UBIOS_GUEST_IN_USER -j guest_separation" ; then
        v6_idx=$(/usr/sbin/ip6tables -L UBIOS_GUEST_IN_USER --line-numbers | /usr/bin/awk '/RETURN.*match-set UBIOS_ALL_NETv6_br[0-9]+ src \/\*/ { print $1; exit }')
        /usr/sbin/ip6tables -I UBIOS_GUEST_IN_USER $v6_idx -j guest_separation
    fi
[...]

03.4.6| NAT deaktivieren

Zu guter letzt entfernt das Script noch die Default NAT-Regeln (sofern $disable_nat == "true"), die über die GUI leider nicht deaktiviert werden können:

#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# disable NAT if requested
#
if [ $disable_nat == "true" ]; then
    # identify MASQUERADE jump target in UBIOS_POSTROUTING_USER_HOOK chain
    # which will be added per default for UBIOS_ADDRv4_ethX (eth8/eth9) to
    # manage NAT throught WAN
    rules=$(/usr/sbin/iptables -t nat -L UBIOS_POSTROUTING_USER_HOOK --line-numbers | \
            /usr/bin/awk '/MASQUERADE .* UBIOS_.*ADDRv4_eth. src/ { print $1 }')

    # for each rule identified we issue a delete operation in reverse
    # order so that UBIOS_POSTROUTINE_USER_HOOK will really only contain
    # NAT rules a user manually defined in the Network UI.
    for rulenum in $(echo -e "${rules}" | /usr/bin/sort -r); do
        /usr/sbin/iptables -t nat -D UBIOS_POSTROUTING_USER_HOOK ${rulenum}
    done
fi

03.5| Keine Kommentare für Firewall-Regeln

Auf der UDM Pro werden die Kommentare der Firewall-Regeln für die Verwaltung genutzt und scheinbar mit einer internen Datenbank abgeglichen. Alle Regeln, die einen unbekannten Kommentar enthalten (iptablesParamter -m comment) werden in /var/log/messages ca alle 30 Sekunden Warnmeldungen ausgegeben:

2024-01-21T14:33:24+01:00 dreamerhomenerdiges ubios-udapi-server[1254]: firewall: Found unexpected rule --comment 'Test'
2024-01-21T14:33:58+01:00 dreamerhomenerdiges ubios-udapi-server[1254]: firewall: Found unexpected rule --comment 'Test'
2024-01-21T14:34:31+01:00 dreamerhomenerdiges ubios-udapi-server[1254]: firewall: Found unexpected rule --comment 'Test'
2024-01-21T14:35:03+01:00 dreamerhomenerdiges ubios-udapi-server[1254]: firewall: Found unexpected rule --comment 'Test'

Das führt dazu, dass das Syslog schnell umfangreich wird. Um das zu vermeiden sollte sichergestellt werden, dass alle Firewall-Regeln, die per Script oder manuell per Kommandozeile manuell hinzugefügt werden keinen Kommentar beinhalten.

04| Separierung dauerhaft sicherstellen

Da das Script von Unifi offiziell nicht unterstützt wird, besteht mit jedem UnifiOS-Update das Risiko, dass das Script nicht mehr funktioniert. Das kann dazu führen, dass nach einem Update die Regeln nicht mehr greifen. Im schlimmsten Falle wird die VLAN-Separierung dann unbemerkt wieder aufgehoben und es kann wieder frei zwischen den VLANs kommuniziert werden. Um das zu unterbinden können verschiedenen Maßnahmen ergriffen werden: 

04.1| Ergänzende Firewall-Regeln über die GUI

Die vom Script erzeugten Regeln sollten, so weit möglich, auch in der GUI konfiguriert werden. Zumindest für den IPv4-Datenverkehr kann dies beispielsweise einfach über die RFC1918 + Unique Local IP-Adressbereiche erfolgen (siehe auch erster Teil der Artikelserie). Werden die Firewall-Regeln vom Script nach einem Update nicht mehr korrekt gesetzt, so wird wenigstens für IPv4 die Trennung weiterhin aufrecht erhalten. Wie aber bereits im ersten Teil beschrieben ist das bei dynamischen IPv6-Prefixen für den IPv6-basierten Datenverkehr leider aktuell nicht möglich.

04.2| Monitoring der Filterung

Ist eine Hausautomatisierung im Einsatz, so kann auch durch VLAN-übergreifende Netzwerktest z.B. per ping oder nmap (siehe [04]) regelmäßig überprüft werden, ob die VLAN-Trennung noch aktiv ist. Sind bei einem solchen Test interne Systeme erreichbar, obwohl die Kommunikationsbeziehung nicht explizit freigegeben ist, dann kann beispielsweise eine Alarmierung per Mail erfolgen.

05| Quelle:

[01] UDM Pro 3: Netzwerktrennung - Teil 1
[02] https://github.com/nerdiges/udmp-seperate-vlans
[03] UDM / UDMPro Boot Script von boostchicken
[04] https://nmap.org/ 

Kommentare

PostadresseE-MailadresseFestnetzMobiltelefonSMS/SignalThreemaTwitter DirektnachrichtFAXWeb Page