Wenn von Firewalls die Rede ist, dann assoziieren Admins damit oft den Schutz der eigenen IT-Ressourcen vor dem unerlaubten Zugriff durch Dritte. Dabei stehen Szenarien im Vordergrund wie etwa Hackerangriffe aller Art, die sich mittels Schadsoftware oder dem Ausnutzen von Schwachstellen in Software Zugriff auf Firmensysteme verschaffen und Daten klauen oder Geldzahlungen erpressen wollen. Regelmäßig tauchen entsprechende Meldungen in den Medien auf.

Die möglichen Maßnahmen zur Erhöhung der eigenen IT-Sicherheit sind vielfältig. Sie beginnen bei relativ einfachen Schritten, wie dem Verstecken der eigenen Infrastruktur hinter einer globalen IP-Adresse, genannt Network Address Translation (NAT). Wobei anzumerken ist, dass NAT kein Security-Feature per se ist, denn es ersetzt keine Firewall, die den Datenstrom analysieren würde. Einfach ausgedrückt, verhindert NAT nur den Verbindungsaufbau von außen in das eigene Netzwerk.

Weitere Maßnahmen sind Paketfilter, die den Datenverkehr nach einem Regelwerk zulassen oder nicht. Diese sind meistens statuslos, sprich die Firewall merkt sich die Zustände der Datenverbindungen nicht.

Damit wären wir bei Stateful-Firewalls, die den Verbindungsaufbau neuer Sessions sowie die Datenflows bis zum Abbau einer Sitzung anhand eines Regelwerks überwachen. Der Maßnahmenkatalog zur Erhöhung der eigenen Sicherheit lässt sich beliebig erweitern, beispielsweise mit dem Einsatz von Deep Packet Inspection (DPI), mit deren Hilfe Sie den Datenverkehr auf binäre Signaturen untersuchen und gegebenenfalls blockieren lassen.

Die Open-Source-Firewall OPNsense [1] bietet sowohl für Einsteiger als auch Sicherheitsprofis Funktionen, die sich sehen lassen können und den Vergleich mit anderen Produkten nicht zu scheuen brauchen. OPNsense wurde 2015 als Spin-off von pfsense ins Leben gerufen, basiert auf FreeBSD (aktuell in der Version 13.2) und ist in zwei Editions verfügbar: der kostenlosen Community-Edition mit dem Codenamen "Restless Roadunner" (Version 23.7 vom 31.7.2023) und der Business-Edition (aktuell 23.4.1), mit einer jährlichen beziehungsweise dreijährlichen Lizenz. Die beiden Versionen finden Sie auf der rechten Seite im Kasten "Features der Editionen" gegenübergestellt.

In der OPNsense-Version 23.7 haben die Entwickler das Betriebssystem FreeBSD von Version 13.1 auf 13.2 aktualisiert. Weiterhin fand Migrationsarbeit von der alten Architektur hin zum Model-view Controller (MVC) Framework statt. Folgende Features wurden dahingehend angepasst:

- Netzwerkinterfacediagnostik wie Ping, Tracroute et cetera.

- Link-Bündel-(LAGG)-Interfaces

- System-Services

- DHCP-leases (IPv4 und IPv6)

- Erweiterte Möglichkeiten von Unbound-DNS.

Das OpenVPN-Modul wurde komplett überarbeitet und bietet jetzt API-Unterstützung zur automatischen Provisionierung von VPNs. Die Release Notes finden Sie unter [2].

Die Funktionalität von OPNsense können Sie durch Plug-ins erweitern. Die Community-Plug-ins enthalten unter anderem Dienste wie dynamisches DNS, dynamisches Routing (mit entsprechender Routingprotokoll-Unterstützung) oder ClamAV-Antivirus-Webfilter. Eine vollständige Liste finden Sie unter [3]. Darüber hinaus gibt es noch kommerzielle Drittanbieter-Plug-ins, etwa von Deciso oder Sunnyvalley [4].

Die Software lässt sich grundsätzlich auf allen Geräten, auf denen FreeBSD läuft, installieren – auf handelsüblichen PCs und gängigen Servern genauso wie auf den extra dafür verfügbaren Appliances wie denen der holländischen Firma Deciso [5] oder den IPU-Systemen von NRG Systems, die unter anderem Boards der Firma PC-Engines vertreibt [6]. Selbstverständlich lässt sich OPNsense auch in virtualisierten Umgebungen, wie VMware ESXi nutzen oder in der Cloud von AWS und Azure.

Die Hardwareanforderungen von OPNsense sind überschaubar. Empfohlen werden eine Multicore-CPU mit zwei oder mehr Kernen, 4 GByte RAM und eine 128 GByte große SSD, auf die das System installiert werden kann. Dieser Empfehlung folgend können Sie bereits die Standardfunktionen laufen lassen. Für den Einsatz in kleinen Umgebungen und der damit einhergehenden überschaubaren Anzahl an Benutzern sollte diese Konfiguration für einen reibungslosen Betrieb sorgen.

Es ist allerdings klar: Je mehr Features zum Einsatz kommen und je komplexer die Konfiguration ausfällt, desto mehr Ressourcen sind gefragt. Hier gibt es leider keine Daumenregel oder Produktdatenblätter mit Skalierungsangaben, da es unzählige Konstellationen von verwendeten Hardwarekomponenten und Anwendungsfällen gibt.

Für unser Workshopsetup haben wir eine Appliance verwendet, da diese sowohl für den Heimatanwender als auch für den Businesseinsatz universell tauglich ist. Es handelt sich um die IPU 410 von NRG Systems mit Intel N100-Alder-Lake-Quad-Core-CPU, vier 2,5-GBit/s-RJ45-Netzwerkanschlüssen, 32 GByte RAM und einer 500 GByte großen WD-RED-SN700-SSD [7].

Das Einsatzszenario wollen wir wie in Bild 1 dargestellt konfigurieren, sodass die OPNsense-Appliance hinter dem DSL-Router läuft. Auf diese Weise können wir WAN-seitig mit Ethernet als Medium arbeiten. Im Fall eines FTTH-Anschlusses wäre es alternativ selbstverständlich möglich, die Appliance direkt mit der Übergabeschnittstelle des Telekommunikationsanbieters zu verbinden und auf dem WAN-Port PPPoE zu nutzen. Der Einfachheit halber haben wir den DSL-Router jedoch in unserem Setup belassen.

Die OPNsense-Appliance bringt vier Ethernet-Schnittstellen (igc0 bis igc3) mit. Die erste wird standardmäßig mit der LAN-Seite verbunden und die zweite Schnittstelle mit der WAN-Seite. Sie müssen sich die Interface-Namen auch nicht weiter merken, da Sie Aliase wie "LAN", "WAN" et cetera dafür vergeben können. Wie ebenfalls dargestellt, soll die Appliance ihre WAN-IP-Adresse vom DSL Router beziehen und LAN-seitig soll sie als DHCP-Server für alle Geräte fungieren. Jeglicher von der LAN-Seite kommende Verkehr, der durch den WAN-Port die Firewall verlässt, wird standardmäßig auf die Interface-IP-Adresse des WAN-Ports genattet.

Beim Download von der OPNSense-Website müssen Sie das passende aus den vier vorhandenen Images für den eigenen Einsatzzweck auswählen. Der Kasten "Verfügbare Images" gibt hier einen kurzen Überblick. Für den Test haben wir das VGA-Image von der OPNsense-Website heruntergeladen. Dieses lässt sich unter allen Linux-Varianten mit dem dd-Kommmando auf einen USB-Stick schreiben, nachdem es dekomprimiert wurde. Für Windows-Benutzer bietet sich an, Rufus [8] für das Erstellen eines bootbaren USB-Sticks zu verwenden.

Beim Starten vom USB-Stick bootet OPNsense zunächst in ein Livesystem, das nicht auf der lokalen Disk installiert ist. Loggen Sie sich sich als der Benutzer "installer" ein, können Sie OPNsense auf die lokale SSD schreiben. Die Installation geht inklusive der SSD-Partitionierung und Formatierung binnen weniger Minuten vonstatten und schließt mit einem Neustart des neu aufgesetzten Systems ab.

Jetzt können Sie von einem PC, der am LAN-Port angeschlossen ist, über die URL "https://192.168.1.1/" auf die Firewall zugreifen und sich anmelden (siehe Kasten "Installationsdefaults"). Natürlich ist aktuell ein von OPNsense selbst signiertes SSL-Zertifikat auf der Firewall hinterlegt, das sich über das Webinterface tauschen lässt. Let's-Encrypt-Zertifikate lassen sich ebenfalls in OPNsense einbinden. Eine gutes Tutorial auf Deutsch finden Sie online unter [9].

Wenn Sie sich über die Weboberfläche anmelden, landen Sie in der Lobby – genauer gesagt im Dashboard – und bekommen dort einen groben Überblick über das aktuell laufende System sowie über laufende Dienste und die beiden Interfaces "LAN" und "WAN".

Unter dem Menüpunkt "System" auf der linken Seite lassen Sie über den Unterpunkt "Aktualisierungen" die Installation und die benutzten Komponenten auf verfügbare Updates überprüfen und spielen diese gegebenenfalls gleich ein. Über das Systemmenü erreichen Sie auch alle anderen Dienste und alles, was es zu konfigurieren gibt. An dieser Stelle erwähnenswert ist noch der "Assistent", mit dem Sie die Basisinstallation, abweichend von den Defaults wie beispielsweise das root-Passwort oder die Eigenschaften und Verhalten aller vorhandenen Netzwerkinterfaces auf die eigenen Bedürfnisse anpassen können. Es ist empfehlenswert, den Assistenten an dieser Stelle durchlaufen zu lassen.

Die Basiskonfiguration ist jetzt fertiggestellt. Sie sehen im Dashboard auf der rechten Seite, dass bereits einige Dienste laufen, unter anderem NTP, unbound DNS, DHCP als Client auf dem WAN-Interface und als Server auf dem LAN-Interface. Dadurch erhalten Systeme, die am LAN-Port verbunden werden, von diesem die für sie notwendige Netzwerkkonfigurationsparameter und können eine Verbindung ins Netzwerk herstellen. Das in Bild 1 dargestellte DHCP-Client-Testsystem hat sich bereits automatisch konfiguriert.

An dieser Stelle haben Sie bereits eine funktionierende Internetverbindung aufgrund der Standardeinstellungen samt NAT. Eine der wichtigsten Komponenten einer Firewall ist das Regelwerk, mit dem Sie definieren, welche Datenflüsse in welcher Richtung erlaubt sein sollen und welche nicht. In OPNsense steuern Sie mit dem Regelwerk auch, wie der Datenverkehr geroutet werden soll (Policy-based Routing). Das ist bei redundanten Uplink-Szenarien relevant, in denen Sie auf einer OPNsense-Firewall oder im Cluster mehrere WAN-Interfaces zu unterschiedlichen Internetprovidern nutzen.

So ein Regelwerk kann recht umfangreich ausfallen. Sie finden dieses in der OPNsense-WebGUI links unter "Firewall / Regeln". Die Regeln sind unterteilt in "Fließende" (Floating) sowie "Interface Groups" (LAN, WAN, Loopback). Per se greifen solche Richtlinien immer in einer Richtung, eingehend und ausgehend und mit einem Interface als Bezugspunkt. Daher erschließt sich die Verwendung der Interface-Aliasnamen im Regelwerkmenü quasi automatisch. Fließende Policies hingegen sind nicht an ein Interface gebunden, sondern können über mehrere Anschlüsse oder Netzwerke zeitgleich benutzt werden. Auf diese im Detail einzugehen, würde den Rahmen unseres Artikels sprengen.

Das auf das LAN-Interface gebundene Regelwerk lässt sowohl für IPv4 als auch für IPv6 allen Datenverkehr unabhängig von der Ziel-IP-Adresse und Port (am LAN-Interface) eingehend durch. WAN-seitig muss der LAN Verkehr ausgehend nicht explizit erlaubt werden. Daher sind auf der WAN-Seite standardmäßig gar keine Policies vorhanden. Allein die implizite Deny-all-Regel sehen Sie nicht, sie ist aber immer da. Auch erhalten Sie einen entsprechenden Hinweis darauf.

In der Konsequenz bedeutet dies, dass kein Datenverkehr auf dem WAN-Port in Richtung LAN durchkommt. Die einzige Ausnahme ist Datenverkehr, der LAN-seitig initiiert wurde. Der Verbindungsaufbau einer Session muss also von innen erfolgen. OPNsense weiß das, da es für jede Verbindung einen Eintrag in der sogenannten Session-Table solange vorhält, bis eine Verbindung geschlossen wird. Diese Tabelle können Sie sich unter "Firewall / Diagnose / Sitzungen" anzeigen lassen. In der Session-Table gehören immer zwei Zeilen paarweise zusammen.

Die erste Zeile zeigt den Initiator der Session, in diesem Beispiel LAN-seitig, der auf ein System im Internet auf TCP-Port 993 zugreifen will. Ganz rechts am Ende der Zeile sehen Sie, welche Regel diesen Datenfluss und dessen Richtung erlaubt hat. Die zweite Zeile bezieht sich auf die erweiterten Firewalleinstellungen. Hier greifen NAT-Regeln, auf die wir gleich eingehen. Wichtig ist jedoch zu beachten, dass nicht-erlaubte und dadurch blockierte Datenflüsse in dieser Session-Table nicht auftauchen. Möchten Sie also einen Datenfluss zulassen und es funktioniert nicht, lohnt sich ein Blick in die Session-Table. Wenn Sie dort keinen Eintrag vorfinden, haben Sie einen Fehler bei den Regeln gemacht.

Die Standardregeln sind ein guter Start. Allerdings ergibt sich durch unterschiedliche Anforderungen an die lokale IT-Infrastruktur die Notwendigkeit, dieses Regelwerk zu erweitern, und vielleicht reicht auch ein Catch-all-Regelwerk nicht mehr aus. Schnell gelangen Nutzer auch zu der Frage, in welcher Reihenfolge das Regelwerk abgearbeitet wird: Erst kommen alle Regeln in der Floating-Sektion der Konfiguration zum Zug, dann die Interface-Groups und schlussendlich die aus der Interfaces-Sektion.

Innerhalb der Konfigurationssektionen werden die Regeln sequenziell – aus Sicht der GUI von oben nach unten – abgearbeitet. Hier ist die Reihenfolge wichtig, denn wenn ein Deny-all-Policy vor einer Regel kommt, die einen bestimmten Verkehr erlauben soll, greift die zweite Regel nicht. Hier wäre noch der sogenannte Quick- beziehungsweise Schnellmodus zu erwähnen, den Sie in den Eigenschaften jeder Policy aktivieren oder deaktivieren können. Aktiviert bedeutet, dass die erste Matching-Regel gewinnt. Im deaktivierten Zustand gewinnt die letzte. Im Zweifelsfall können Sie Quick aktivieren und dann alle Regeln von oben nach unten evaluieren.

Network Address Translation (NAT) ist standardmäßig für allen Verkehr konfiguriert, der auf dem LAN-Interface hereinkommt und über das WAN-Interface die Firewall verlässt. NAT-Regeln kommen vor den Firewallregeln zum Einsatz. Diesem Umstand sollten Sie Beachtung schenken, da Sie ansonsten im Zweifelsfall Ihr Regelwerk auf die falschen IP-Adressen münzen. NAT-Regeln werden im Webinterface unter "Firewall / NAT" konfiguriert. Hier gibt es vier Untermenüs:

- Portweiterleitung, auch bekannt als Destination-NAT.

- 1:1-NAT für die sprichwörtliche Übersetzung und Abbildung von IP-Adresspaaren zueinander;

- Ausgehend, auch "Source-NAT" genannt;

- Network Prefix Translation (NPT), die im Prinzip ähnlich zu 1:1-NAT funktioniert, nur für IPv6.

Standardmäßig verwendet OPNsense die Variante Source-NAT, gebunden auf das LAN-Interface.

Source-NAT kennt vier Modi: automatische, manuelle, hybride oder deaktivierte Erzeugung von NAT-Regeln. Während die ersten drei Modi selbsterklärend sind, bedarf es für das deaktivierte Erstellen ausgehender NAT-Regeln eines Beispiels zum besseren Verständnis. Üblicherweise arbeiten Firewalls auf den OSI-Schichten 4 bis 7. Das bedeutet, dass die Firewall am IP-Routing teilnimmt und mit IP-Adressen als Quelle oder Ziel arbeitet. Sie können eine Firewall aber auch auf OSI-Schicht 2 arbeiten lassen. In diesem Modus gibt es im Header keine IP-Adressen, auf die Regeln anwendbar sind. NAT greift hier demnach auch nicht. In diesem Modus arbeitet die Firewall im sogenannten transparenten Modus. Sie taucht beispielsweise bei einer Routenverfolgung mitttels "traceroute" im Pfad nicht auf. Es ist daher nicht ersichtlich, ob und an welcher Stelle eine Firewall im Netzwerk verbaut ist.

OPNsense erzeugt für ausgehenden Verkehr standardmäßig Source-NAT-Regeln. Die erste erstellte Policy braucht es für den IPSec-VPN-Verkehr, damit Traffic für die IKE-Phase 1 (ausgehend auf Port 500/UDP) die ausgehende IP-Adresse stets auf die WAN-IP-Adresse der OPN­Sense-Firewall umgeschrieben wird. Das gilt auch für IPSec-VPN-Verbindungen, die von PCs im LAN initiiert werden. Vorsicht, auch hier wird gegebenenfalls nochmal genattet, wenn die Firewall nicht direkt am Anschluss des Telekommunikationsanbieters läuft.

Die zweite Regel greift für jeglichen Verkehr, der von der Firewall selbst – inklusive Loopback-Netzwerke – oder von Systemen im LAN initiiert wird. Hier wird also das interne Netzwerk hinter der WAN-IP-Adresse versteckt. Abschließend soll jetzt noch eine Regel folgen, die das Arbeiten mit der Reihenfolge im Regelwerk illustriert. So wollen wir den E-Mail-Verkehr zu privaten Anbietern wie beispielsweise Gmail aus dem LAN unterbinden, sodass Mitarbeiter aus dem Netzwerk keine private Nachrichten senden und nur den firmeneigenen Mailserver benutzen. Dies soll freilich nur als Beispiel dienen.

Wir brauchen nun zwei Regeln: Die erste, die E-Mail-Traffic von Clients zu einem bestimmten Mailserver erlaubt. Die zweite Regel soll allen anderweitig ausgehenden Mailverkehr blockieren. Es ist wichtig, dass die beiden neuen Regeln an die erste Stelle und in genau dieser Reihenfolge einsortiert werden, denn es soll in Zeile 1 zunächst Traffic zu einem bestimmten Mailserver erlaubt und in Zeile 2 jeglicher anderer Mailverkehr verboten werden. Würden wir das andersherum sortieren, würde die Regel mit dem Firmenserver nicht greifen. Jegliche andere IPv4- und IPv6-Kommunikation kommt ans Ende des Regelwerks und kümmert sich somit um allen anderen – nicht E-Mail-bezogenen – Verkehr.

Bei der Arbeit mit OPNsense wird schnell deutlich, dass die Firewall ziemlich mächtig ist und die Konfiguration über das Webinterface einen hohen Grad an Flexibilität bietet. Bei allem Komfort, die OPNsense und dessen Webinterface bieten, bleibt aber eine Erkenntnis: Es gibt keinen simplen Ein- und Ausschalter. Wer sich mit Firewalls beschäftigt, kommt an Netzwerkwissen nicht vorbei.