OPNsense Layer 2 Firewall

Transparente Filterbrücke (Layer-2-Firewall)

• Eine transparente Firewall filtert Verkehr, ohne dass unterschiedliche Subnetze angelegt werden
• Die Firewall überbrückt dieselbe Broadcast-Domäne über zwei Schnittstellen und filtert auf der Brücke
• Für die Clients ist sie unsichtbar: kein Gateway, keine neue Adresse, keine Routen
• Typische Einsatzfälle:
  • Ein einzelnes System oder ein Segment absichern, ohne die vorhandene Adressierung anzufassen
  • Altsysteme schützen, die selbst keine Firewall mitbringen
  • Verkehr beobachten und per IDS/IPS untersuchen

Abgrenzung

• Nicht kompatibel mit Traffic Shaping
• Nicht kompatibel mit CARP – eine Filterbrücke ist keine Option für den HA-Cluster, sondern eine eigene Maschine
• Gefiltert wird weiterhin auf Layer 3 und 4. "Layer 2" beschreibt die Einbindung ins Netz, nicht die Filterkriterien – MAC-Adressen sind mit pf keine Regelkriterien

Vorbereitung

• Eine OPNsense-Installation mit drei Netzwerkkarten

Schnittstelle	Name	Rolle	Adresse
em0	MGMT	(Verwaltung)	172.16.99.1/24
em1	OUT	Bridge-Mitglied (außen)	keine
em2	IN	Bridge-Mitglied (innen)	keine

• Die Verwaltung läuft über eine eigene Karte, weil die Brücke selbst keine Adresse trägt
• Ohne diese dritte Karte sperrst du dich aus, sobald die Mitglieds-Interfaces auf None stehen

Hypervisor

• Beide Bridge-Mitglieder müssen in den Promiscuous-Modus geschaltet werden
  • VirtualBox: Maschine => Ändern => Netzwerk => Adapter => Erweitert => Promiscuous-Modus: Alle erlauben
• Eine Brücke leitet Frames fremder MAC-Adressen weiter – ohne Promiscuous verwirft der Hypervisor sie

Konfiguration

Schritt 1: Mitglieds-Interfaces vorbereiten

• Interfaces => em1 und Interfaces => em2:

Parameter	Wert
IPv4 Configuration Type	None
IPv6 Configuration Type	None
Block private networks	deaktiviert
Block bogon networks	deaktiviert

• Ein DHCP-Server, der an eines dieser Interfaces gebunden ist, muss abgeschaltet werden

Schritt 2: Tunables setzen

• System => Settings => Tunables

Tunable	Wert	Bedeutung
net.link.bridge.pfil_bridge	1	Es wird auf der Brücke gefiltert
net.link.bridge.pfil_member	0	Auf den Mitglieds-Interfaces wird nicht gefiltert

Achtung

• Nach dieser Einstellung werden Regeln auf den Mitglieds-Interfaces ignoriert
• Das ist die häufigste Fehlerquelle: Die Regeln stehen unter WAN oder LAN und bleiben wirkungslos

Schritt 3: Bridge anlegen

• Interfaces => Devices => Bridge => +

Parameter	Wert
Member Interfaces	IN, OUT
Description	Bridge

Schritt 4: Bridge zuweisen

• Interfaces => Assignments: die neue bridge0 als Schnittstelle zuweisen und aktivieren
• Configuration Type bleibt None

Schritt 5: Regeln

• Alle Regeln werden auf der Bridge angelegt, nicht auf em1 oder em2

Besonderheit gegenüber einer routenden Firewall

• Bei einer routenden Firewall trennen die Schnittstellen die Richtungen: Was auf LAN reinkommt, geht nach außen, was auf WAN reinkommt, kommt von außen
• Bei der Brücke laufen beide Richtungen über dieselbe Schnittstelle – bridge0 sieht Hin- und Rückweg
• Die Richtung lässt sich deshalb nicht mehr über das Interface unterscheiden, sondern nur noch über Quell- und Zieladresse
• Das ist der gedankliche Unterschied, der im Betrieb die meisten Fehler verursacht: Regeln, die man von einer routenden Firewall übernimmt, greifen an der falschen Stelle

Was pf auf der Brücke nicht sieht

• ARP wird von pf nicht gefiltert und läuft immer durch
• Standardmäßig werden nur IP-Pakete gefiltert, alle anderen Frames passieren ungeprüft
• Wer auch Nicht-IP-Verkehr filtern will, setzt zusätzlich:

Tunable	Wert	Bedeutung
net.link.bridge.pfil_onlyip	0	Auch Nicht-IP-Frames unterliegen dem Regelwerk

• Im Kurs ist das ein guter Prüfpunkt: Eine Brücke ist keine MAC-Firewall, auch wenn sie auf Layer 2 sitzt

Erste Stufe: transparent schalten

• Zunächst eine einzige Regel auf bridge0:

Parameter	Wert
Action	Pass
Interface	Bridge
Direction	in
Protocol	any
Source	any
Destination	any
Log	aktiviert

• Damit ist die Brücke vollständig durchlässig und verhält sich wie ein Kabel
• Erst prüfen, ob der Verkehr durchläuft. Läuft er hier nicht, liegt es an der Brücke selbst und nicht am Regelwerk
• Das Logging bleibt an: Im Live-Log sieht man jetzt sämtlichen Verkehr, der die Brücke passiert, und kann daraus die späteren Regeln ableiten

Zweite Stufe: filtern

• Beispiel: Hinter der Brücke steht ein Altsystem 192.168.1.60, das nur noch per HTTPS erreichbar sein soll

#	Action	Source	Destination	Port	Zweck
1	Pass	any	192.168.1.60	443	Zugriff auf den Dienst
2	Pass	192.168.1.60	any	53, 123	DNS und Zeit für das Altsystem
3	Block	any	192.168.1.60	any	Alles andere zum System
4	Block	192.168.1.60	any	any	Alles andere vom System
5	Pass	any	any	any	Übriger Verkehr im Segment bleibt unberührt

• Die Reihenfolge ist entscheidend: pf wertet von oben nach unten aus, die erste passende Regel gewinnt
• Regel 5 ist der Punkt, der eine Brücke von einer routenden Firewall unterscheidet: Der restliche Verkehr im Segment läuft weiter über die Brücke und darf nicht versehentlich mit blockiert werden
• Regel 3 und 4 mit Logging versehen – nur so wird im Kurs sichtbar, was die Brücke tatsächlich abfängt

Antwortverkehr

• Die Regeln arbeiten mit States, der Rückweg ist damit automatisch erlaubt
• Nimmt ein Teil des Verkehrs einen anderen Weg als der Hinweg, sieht die Brücke nur eine Richtung und verwirft die Antwortpakete
• In diesem Fall hilft im Regel-Dialog unter Advanced der State Type sloppy – er verzichtet auf die strenge Sequenznummernprüfung
• Im Labor mit einer einzelnen Brücke tritt das nicht auf; in der Praxis mit mehreren Wegen durch das Segment schon

=== Aussperren

Funktionstest

• Client hinter der Brücke behält seine bisherige Adresse, sein bisheriges Gateway und seinen bisherigen DNS-Server
• Erreichbarkeit prüfen:

ping 192.168.HS.254

• Auf der Firewall mitlesen:

tcpdump -n -i bridge0

• Die MAC-Tabelle der Brücke anzeigen:

ifconfig bridge0 addr

• Danach eine Blockregel setzen, etwa auf ICMP, und prüfen, dass der Ping stoppt – der Client merkt dabei nicht, wodurch er blockiert wird

Debugging

Beobachtung	Ursache
Regeln greifen nicht	Regeln liegen auf den Mitglieds-Interfaces statt auf der Bridge
Kein Verkehr über die Brücke	Promiscuous-Modus im Hypervisor fehlt
Verwaltung nicht mehr erreichbar	Kein eigenes MGMT-Interface vorhanden
Einzelne Protokolle kommen nicht durch	Mitglieds-Interface steht noch auf "Block private networks"

• Zustand der Brücke prüfen:

ifconfig bridge0

• Zählen, ob Regeln überhaupt matchen:

pfctl -s rules -v

IDS/IPS auf der Brücke

• Der Aufbau ist ausdrücklich dafür gedacht, den gesamten Verkehr zusätzlich per Netmap-Treiber durch IDS/IPS zu schicken
• Suricata wird dabei auf die Mitglieds-Interfaces gelegt, nicht auf die Brücke
• Siehe OPNsense Suricata Einrichtung