Zonenbasierte Firewall in UniFi: Rückverkehr, Gateway-Zone und Verkehr innerhalb einer Zone

Die zonenbasierte Firewall hat die Liste von Regeln je Schnittstelle durch ein Raster ersetzt, und das Raster ist das ehrlichere Bild. Jede Zone kann mit jeder Zone sprechen, jede Paarung ist eine eigene Entscheidung, und die Zahl der Entscheidungen wächst im Quadrat der Zonen. Sechs Zonen sind sechsunddreißig Richtungen.

Eine Planung benennt davon meist acht. Die übrigen achtundzwanzig sind nicht ungeplant im Sinne von offen – sie erben eine Voreinstellung -, aber sie sind ungeprüft, und drei von ihnen entscheiden darüber, ob das Netz sicher ist, ob es funktioniert und ob der Unterschied auffällt.

Aus Regeln je Schnittstelle werden Zellen im Raster

Das ältere Modell fragte, was ein Netz verlassen darf. Das Zonenmodell fragt für jedes geordnete Zonenpaar, was hinüber darf – dieselbe Frage also sechsunddreißigmal statt sechsmal. Zonen kommen vordefiniert mit, darunter Internal, Gateway, VPN, Hotspot, DMZ und External, und jedes VLAN landet in genau einer davon.

Was das Raster brauchbar macht, macht es auch leicht falsch zu lesen: Eine Zelle sagt nichts über die an der Diagonale gespiegelte Zelle. LAN zu IoT und IoT zu LAN sind zwei getrennte Entscheidungen, und der ganze nächste Abschnitt handelt davon, dass sie weit weniger symmetrisch sind, als sie aussehen.

Antworten sind keine Richtung

Die Firewall führt Buch über Verbindungen. Eine Sitzung, die aufgebaut werden durfte, darf antworten, und die Antwort fragt die Gegenzelle nie – sie trifft auf den vorhandenen Zustand und geht durch. IoT zu LAN kann also geschlossen bleiben, während ein Telefon im LAN den ganzen Tag mit einer Lampe in der IoT-Zone spricht.

Zonen n = 6          Richtungen n² = 36
geplant              ~ 8
diagonal             6   (innerhalb einer Zone, ohne Regel)

LAN 10.0.1.20:51344  →  IoT 10.0.30.7:80      erlaubt durch LAN → IoT
IoT 10.0.30.7:80     →  LAN 10.0.1.20:51344   ESTABLISHED, keine Regel nötig

Der Fehler, den das verhindert, ist häufig und teuer: IoT zu LAN zu öffnen, damit Antworten ankommen. Nötig war das nie, und die geöffnete Zelle erlaubt es einem übernommenen Gerät nun, selbst Verbindungen in das geschützte Netz aufzubauen. Eine Zelle braucht immer nur, wer zuerst spricht.

Die Zone, die nicht zu sein darf

Das Gateway ist eine eigene Zone, und fast alles, was ein Gerät braucht, bevor es überhaupt etwas tun kann, liegt dort: DHCP, DNS und NTP. IoT zum Gateway zu sperren, liest sich in einer Planung überzeugend – die IoT-Zone hat mit der Infrastruktur nichts zu schaffen – und ergibt eine Zone, die sich anmeldet, eine Adresse bekommt, vollen Empfang zeigt und nichts auflöst.

Der Ausfall ist auf die unangenehmste Art lautlos. Nichts meldet einen Fehler, Anfragen laufen einfach in die Zeitüberschreitung, Geräte wirken langsam statt gesperrt, und die Suche beginnt beim Funk und beim Zugangspunkt statt bei der einen Zelle, die es war. Wenn diese Richtung enger werden soll, wird sie über Ports eingeengt – 53 und 123 zur Gateway-Adresse – und nicht geschlossen.

Die Diagonale, auf die niemand schaut

Verkehr, der innerhalb einer Zone beginnt und endet, erreicht keine Regel. Vierzig Geräte in einer IoT-Zone sind untereinander ein flaches Netz, und die Trennung, die die Matrix zu versprechen scheint, hört an der Zonengrenze auf. Eine Lampe mit alter Firmware sieht die anderen neununddreißig, und die Firewall wurde nie gefragt.

Es gibt zwei Auswege, und beide liegen außerhalb der Matrix. Client-Isolation im Funknetz hindert Geräte am selben Netznamen daran, sich gegenseitig zu erreichen; die Zone aufzuteilen gibt dem Verkehr eine Grenze zum Überqueren. Und es gibt einen dritten Fall, den keiner von beiden löst: Zwei Geräte im selben VLAN am selben Switch tauschen Rahmen aus, die das Gateway nie sieht – was zu wissen sich lohnt, bevor eine Regel geschrieben wird, die sie regeln soll.

Sperren und Abweisen sehen von innen verschieden aus

Jede dieser Zeilen hat außerdem eine Darstellung, und dafür gibt es die zwei sperrenden Aktionen. Sperren verwirft das Paket wortlos, das Gerät wartet seine Zeitüberschreitung ab – dreißig Sekunden nichts, gefolgt von einer Meldung, die die falsche Ursache nennt. Abweisen antwortet sofort, und die Anwendung scheitert augenblicklich und sagt es.

Zur Grenze ins Internet passt das Schweigen: Ein unbeantworteter Anklopfversuch verrät weniger als eine Abfuhr. Zu den Richtungen im Inneren passt die Abfuhr, denn jeder dieser Ausfälle wird von einem Menschen untersucht, und eine Zeitüberschreitung ist das Uninformativste, was eine Firewall hervorbringen kann.

Was die Matrix nicht ausdrücken kann

Portweiterleitungen betreten das Raster nicht so, wie das Raster es nahelegt. Verkehr von außen wird übersetzt, bevor die Zonenregeln ihn sehen, geprüft wird also das Ziel nach der Übersetzung und nicht die öffentliche Adresse, die gewählt wurde. Denselben Dienst von innen über seinen öffentlichen Namen zu erreichen, ist der verwandte Fall und verlangt NAT-Reflexion – eine Einstellung, keine Zelle.

Multicast liegt ganz außerhalb des Modells. Erkennungsprotokolle wie mDNS wandern nicht deshalb nicht zwischen Zonen, weil eine Regel sie sperrt, sondern weil Multicast nicht geroutet wird; ein Drucker, der nur im LAN auftaucht, braucht den mDNS-Wiederholer für beide Zonen, und keine Zelle ersetzt ihn. Und VPN-Verbindungen kommen in einer eigenen Zone an – ein aufgebauter Tunnel ohne Weg zu irgendetwas ist also kein kaputter Tunnel, sondern eine Zeile der Matrix, die niemand ausgefüllt hat.