Besser gerüstet

von Thomas Zeller

Immer häufiger stellt sich die Frage, ob eine herkömmliche Firewall den Perimeter noch ausreichend schützt. Im Hinblick auf den steigenden Bedarf an Sicherheit bieten Next Generation Firewalls in der Regel ein deutlich höheres Schutzniveau. Allerdings haben sie den Ruf, teuer und kompliziert zu sein. Eine vielversprechende Alternative stellt ZenArmor dar, eine vergleichsweise junge NG-Firewall, die auf verschiedenen Open-Source-Plattformen betrieben werden kann. Wir haben uns die aktuelle Version der Firewall genauer angesehen.

Admins der beliebten OPNsense-Firewall sind eventuell schon zuvor mit ZenArmor [1] (früher "Sensei") des gleichnamigen Herstellers in Berührung gekommen. Denn für diese Plattform steht die Software bereits seit längerem als Plug-in zur Verfügung. Durch Aktivieren des Plug-ins lässt sich auf dieser Firewall vergleichsweise einfach NG-Funktionalität nachrüsten. Alternativ kann ZenArmor auch alleinstehend zum Einsatz kommen, bringt aber kein eigenes Betriebssystem mit. Als Plattform unterstützt die Firewall ausschließlich 64-Bit-Linux und -BSD-Derivate sowie Amazon Linux 2. Ein nativer Einsatz unter Windows ist nicht vorgesehen. Mit entsprechend virtualisiertem Betriebssystem lässt sich ZenArmor aber natürlich in jeder beliebigen virtuellen Umgebung nutzen, darunter auch HyperV.

Breiter Funktionsumfang

Für den Begriff der Next Generation Firewall (NGFW) fehlt eine allgemeingültige Definition. Vielmehr bestimmt jeder Hersteller selbst, was genau er darunter versteht. Nach allgemeiner Auffassung beinhalten NGFWs aber mindestens eine Deep-Packet-Inspection-Engine und mittels eines Intrusion-Detection-Systems können Benutzer Applikationen im Datenverkehr erkennen und entsprechende Filter anwenden. Darüber hinaus sollen die Firewalls auch den SSL/TLS-verschlüsselten Traffic analysieren und überwachen. ZenArmor unterstützt zum Zeitpunkt der Entstehung dieses Artikels die nachfolgenden Features.

Der Webfilter von ZenArmor umfasst nach eigenen Angaben mehr als 300 Millionen Websites in 60 Kategorien. Die Applikationskontrolle analysiert derweil mithilfe von Signaturen den Inhalt von HTTP(S)-Verbindungen und kann so beurteilen, welche (Web)-Applikation sich hinter der jeweiligen Verbindung verbirgt. Auf diese Weise ist es beispielsweise möglich, Google als Suchmaschine zuzulassen, den Zugriff auf unerwünschte Webapplikationen wie Google Mail oder Drive jedoch zu unterbinden. Gleiches gilt auch für native Applikationen. So lässt sich beispielsweise der Einsatz anderer Apps wie des Tor-Browsers oder Teams blockieren.

Die Applikationskontrolle erkennt Anwendungen im Gegensatz zum Webfilter auch dann, wenn der jeweilige Client auf einem Nicht-HTTP(S)-Port kommuniziert. Aktuell kann ZenArmor für SSL/ TLS-basierte Verbindungen allerdings nur eine Zertifikatsprüfung auf Basis des Hostnamens und der IP-Adresse durchführen. Der verschlüsselte Netzwerkverkehr selbst wird also derzeit noch nicht überwacht. Diese "Full SSL/TLS Inspection" befindet sich in der Entwicklung, soll aber im Laufe des kommenden Jahres zur Verfügung stehen. Standardmäßig können Applikationskontrolle und Webfilter auf bestimmte Subnetze oder auch einzelne IP-Adressen angewendet werden. Für viele Anwendungsfälle greift dieser Ansatz allerdings zu kurz. Benutzerbasierte Filterregeln bieten hier deutlich mehr Flexibilität. ZenArmor kann User hierfür über das Captive Portal von OPNsense oder unter Zuhilfenahme eines eigen Active-Directory-Agenten identifizieren.

Daneben betreibt ZenArmor eine Datenbank mit Reputations- und Sicherheitsinformationen. Neben dem Webfilter zur Kategorisierung von Websites enthält die Datenbank auch Informationen zur Reputation von Websites und Domains. Auf diese Weise lassen sich beispielsweise erst kürzlich registrierte Domains erkennen, die Angreifer häufig für den Betrieb von Phishing-Seiten nutzen. Inhaber einer ZenArmor-Business-Lizenz profitieren darüber hinaus von einer stark erweiterten Datenbank des Herstellers Brightcloud.

Mithilfe des Live-Session-Explorers kann der Admin Netzwerkverbindungen in Echtzeit überprüfen. Vordefinierte Filterkategorien wie "Threats", "Blocks" oder "Web" helfen dabei, relevante Ereignisse schneller in der Menge der auflaufenden Daten zu finden. Ist die Benutzererkennung über das OPNsense-Captive-Portal oder über das AD-Plug-in aktiv, lässt sich jede Verbindung darüber hinaus einem spezifischen Benutzer zuordnen. Die Reporting-Engine bereitet die Verbindungsdaten über frei wählbare Zeitabschnitte mit übersichtlichen Diagrammen auf und ermöglicht so einen schnellen Überblick über alle Ereignisse im gesamten Datenverkehr. Ein Scheduler sorgt im Bedarfsfall für den Versand vordefinierter Berichte per E-Mail.

Zentrales Management

ZenArmor verfügt mit der "ZenConsole" über ein cloudbasiertes Management. Wird ZenArmor als Plug-in auf einer OPNsense Firewall installiert, erfolgt die Administration der ZenArmor-Komponenten primär über die Benutzeroberfläche von OPNsense. Optional kann die Firewall aber auch zusätzlich über die ZenConsole registriert werden. Die ZenArmor-Funktionen lassen sich dann auch unabhängig von OPNsense steuern. Standalone-Installationen von ZenArmor haben dagegen keine eigene Benutzeroberfläche und werden grundsätzlich über die ZenConsole administriert. Einem ZenConsole-Konto lassen sich dabei mehrere Firewalls zuordnen.

Die RESTful-API ist für Admins interessant, die Informationen ihrer ZenArmorInstallation automatisiert abrufen möchten. Auf diese Weise lässt sich ZenArmor in bestehende Monitoring- beziehungsweise Managementsysteme einbinden. Über das HTTPS-Protokoll sind darüber hinaus Konfigurationsänderungen an der Firewall möglich, ohne dass sich der Admin dafür an deren Benutzeroberfläche anmelden muss. Zudem nutzt ZenArmor die API auch in Kombination mit einem Active-Directory-Agenten zur Benutzeridentifikation.

Systemvoraussetzungen

ZenArmor setzt eine vorhandene OPNsense-Firewall, eine pfSense-Firewall oder ein Linux/BSD-System voraus. Letzteres kann virtualisiert betrieben werden. Empfehlenswert ist dies jedoch nur bei maximal 500 aktiven Geräten im Netzwerk beziehungsweise bis zu einer Internetbandbreite von 500 MBit/s. Als Minimalkonfiguration für die (virtuelle) Hardware ist eine Dual-Core-CPU mit 1 GByte RAM gefragt. Auf Systemen mit weniger Arbeitsspeicher bricht der Installer ab.

Erwartungsgemäß steigen die Systemanforderungen mit der Anzahl geschützter Geräte sowie Benutzer im Netzwerk. Im Bedarfsfall kann die Reportdatenbank (Elasticsearch) deshalb auch auf ein separates System ausgelagert werden. Das ergibt vor allem dann Sinn, wenn der RAM auf der gewählten Plattform begrenzt ist. Folgende Betriebssysteme sind Stand Juli 2023 als Basis für ZenArmor freigegeben:

- OPNsense 19.x bis 23.x

- pfSense software CE 2.5.x-2.6.x

- Ubuntu Linux 18.04 LTS, 20.04 LTS, 22.04 LTS

- Debian Linux 10, 11

- RedHat Enterprise Linux (RHEL) 8.5 bis 9

Ohne Netmap kein vollwertiges ZenArmor

ZenArmor verwendet das Netmap-Framework für den Zugriff auf Raw-Ethernet-Frames, was dieses zu einer zwingenden Voraussetzung für die Nutzung aller Features von ZenArmor macht. Netmap ist eine Kernel-Schnittstelle, die die Firewall zwischen dem physischen oder virtuellen Ethernet-Adapter und dem Linux/BSD-Netzwerk-Stack nutzt, um Netzwerkpakete zu modifizieren, bevor diese ihr jeweiliges Ziel erreichen.

FreeBSD (und damit auch OPNsense und pfSense) haben Netmap bereits an Bord, Linux jedoch nicht. Wer ZenArmor im Standalone-Betrieb auf Linux-Basis einsetzen möchte, muss Netmap daher händisch installieren. Wie das funktioniert, beschreibt der Hersteller unter [2]. Zu beachten ist, dass Netmap nicht mit Hardware-Offloading – konkret: CRC Offloading, TCP Segmentation Offload (TSO) sowie Large Receive Offload (LRO) – und VLAN-Tagging und -Filtering kompatibel ist. Auf Linux- und BSD-Rechnern müssen Sie diese Funktionen daher zuvor unter Umständen deaktivieren. OPNsense und pfSense verfügen in der Regel bereits über die korrekte Einstellung, zu finden unter "Interfaces / Setting".

Wer keine Zeit und Nerven für die Netmap-Installation hat und ZenArmor einfach nur ausprobieren möchte, kann die Firewall dennoch unter Linux installieren. ZenArmor nutzt dann entweder das vorinstallierte Netfilter-Framework (NFQ) oder einen emulierten Netmap-Treiber. Mit Netfilter stehen allerdings nicht alle ZenArmor-Features zur Verfügung. So kann beispielsweise für HTTPS-Verbindungen keine individuelle Blockiert-Seite angezeigt werden. Benutzer erhalten dann lediglich eine Fehlermeldung des Webbrowsers, wenn sie eine SSL-verschlüsselte Website aufrufen, die von einer ZenArmor-Policy geblockt wird. Weitere Einschränkungen sind beim Traffic-Shaping und vor allem bei der Performance der Packet-Engine zu erwarten. ZenArmor unterstützt das Netmap-Team bei der Entwicklung und Verbesserung eines emulierten Treibers für Linux. Dieser soll nach Aussage des Herstellers noch im Laufe dieses Jahres verfügbar sein.

Verschiedene Betriebsformen

Wie erwähnt kann ZenArmor entweder als Plug-in in OPNsense-Firewalls oder alleinstehend auf einem BSD- oder Linux-Host installiert werden. Die Nutzung als Plug-in auf einer bestehenden Firewall bietet den Vorteil, dass ZenArmor die vorhandene Firewall sehr einfach um NG-Funktionalität ergänzt und direkt über das UI der Firewall (und zusätzlich optional über die Cloudkonsole) verwaltet werden kann. Die Firewall arbeitet in der Standardkonfiguration im Layer-3-Routingmodus, die Deep Packet Inspection kann den Netzwerkverkehr daher nach Belieben analysieren und manipulieren.

Standalone-Installationen verfügen über keine eigene Benutzeroberfläche und müssen grundsätzlich über die ZenConsole administriert werden. Derartige Systeme sind so ins Netzwerk einzubinden, dass die ZenArmor-Engine die relevanten Pakete auch zu sehen bekommt. In der Regel findet ZenArmor daher als zusätzliches Gateway in Richtung Internet-Uplink seinen Einsatz – vor oder hinter einer eventuell bereits bestehenden Firewall. Glücklicherweise unterstützt ZenArmor neben dem L3-Routing-Modus aber auch den Betrieb im Bridging-Mode auf Layer 2. Durch den Einsatz als Bridge lässt sich ZenArmor wie ein Inline-Security-Gateway einsetzen und vermeidet damit doppeltes NAT, mit dem diverse Netzwerkanwendungen ihre Probleme haben.

Als rein softwarebasiertes Produkt kann ZenArmor schließlich auch als Bestandteil einer SASE-Architektur in der Cloud installiert werden. Amazon Linux (AWS) wird von ZenArmor direkt unterstützt, auf anderen Cloudplattformen muss ein von ZenArmor freigegebenes Betriebssystem (BSD/Linux) als Installationsbasis virtualisiert werden. Der Betrieb eines Secure-Web-Gateways in einer SASE-Umgebung bietet gegenüber der klassischen Installation im LAN einige Vorteile, erfordert andererseits auch konzeptionelle Änderungen an der Netzwerkarchitektur.

Account für die Cloudkonsole

Für das Remote-Management von ZenArmor über die cloudbasierte ZenConsole wird ein Benutzeraccount benötigt, den Sie auf der Herstellerseite [1] und dem Punkt "Login / Sign Up" registrieren können. Mit der hier angegebenen E-Mail-Adresse und Passwort erfolgt später auch die Anmeldung der Firewall an der Cloudkonsole. Für die Administration per ZenConsole verwenden Sie die gleichen Zugangsdaten. Für OPNsense-Admins ist dieser Schritt übrigens optional. Für Nutzer anderer Plattformen ist ein Account dagegen obligatorisch, da für diese Systeme eine Administration ausschließlich über die Cloud vorgesehen ist.

Die Installation der ZenArmor-Software ist schnell erledigt. OPNsense-Admins suchen im Web-GUI unter "System / Firmware / Plugins" nach "zenarmor" und installieren zunächst das Repository "os-sunnyvalley". Nach dessen Download und Aktivierung stehen auf der Plug-in-Seite von OPNsense die drei Pakete "os-sensei", "os-sensei-agent" und "os-sensei-updater" zur Verfügung. Nachdem auch diese installiert wurden, erscheint im Hauptmenü der OPNsense-Administrationsoberfläche der zusätzliche Eintrag "ZenArmor", über den sich der Wizard für die Erstkonfiguration starten lässt.

Admins von pfSense/FreeBSD und Linux loggen sich dagegen per SSH auf ihrem zuvor installierten System ein, starten die Installation von ZenArmor per Kommandozeile und melden im zweiten Schritt die Installation bei Bedarf gleich an der Cloudkonsole an:

Nach Eingabe des letzten Befehls werden die zuvor registrierte E-Mail-Adresse und das zugehörige Passwort abgefragt. Im Anschluss an die erfolgreiche Registrierung des Systems melden Sie sich mit den selben Zugangsdaten im Portal unter "https://dash.zenarmor.com" an. Die neue Firewall findet sich unter ihrem Hostnamen im Abschnitt "Firewall / Projects".

Konfiguration über OPNsense und ZenConsole

ZenArmor benötigt zunächst eine Datenbank für die Reporting-Engine. Weiterhin müssen Sie die zu überwachenden Netzwerkinterfaces festlegen und den Deployment-Modus (Routing, Bridging oder Passive Mode) auswählen.

In der OPNsense-Oberfläche werden diese Informationen beim ersten Aufruf des neuen Menüeintrags für ZenArmor mithilfe eines Wizards abgefragt. Bei Stand-alone-Installationen erfolgt die Basiskonfiguration dagegen über die ZenConsole. Zwischen der ZenArmor-Sektion in OPNsense und der ZenConsole gibt es derzeit noch ein paar Unterschiede. So stehen zwar alle Konfigurationsoptionen der ZenConsole auch in OPNsense zur Verfügung.

Umgekehrt sind aber noch nicht alle Funktionen aus der OPNsense-GUI auch in die ZenConsole implementiert. Beispielsweise bietet OPNsense einen eigenen Backupmechanismus zur Sicherung sämtlicher ZenArmor-Einstellungen an. Nach Auskunft des Herstellers werden aber sämtliche Konfigurationsoptionen aus OPNsense künftig auch in der ZenConsole bereitstehen. Da sowohl OPNsense- als auch Standalone-Installation über die ZenConsole administriert werden können, beschreiben wir die weitere Konfiguration ab hier auf Basis der ZenConsole.

Sie erreichen die Basiskonfiguration über das Drei-Punkte-Menü beziehungsweise über "Settings". Als Report-Datenbank bietet ZenArmor derzeit neben Elastic-search, SQLite und OPNsense auch MongoDB an. SQLite ist für den produktiven Einsatz nur dann sinnvoll, wenn dauerhaft weniger als 100 Geräte im Netzwerk aktiv sind.

Möchten Sie flexibel bleiben, wählen Sie hier besser gleich Elasticsearch. Letzteres kann aus Performancegründen auch auf einem seperaten Host betrieben werden. ZenArmor kommuniziert mit dieser Instanz dann über das Netzwerk, was allerdings eine Business-Lizenz voraussetzt. Wir entscheiden uns in diesem Workshop deshalb für die lokale Installation von Elasticsearch.

Netzwerkschnittstelle und Deployment-Mode

Grundsätzlich lässt sich ZenArmor im Routing-, Bridging oder Passive-Modus betreiben. Läuft ZenArmor auf einer OPNsense- oder pfSense-Firewall, arbeitet es per Default im Layer-3-Routingmodus. Für Standalone-Gateways wählen Sie den gewünschten Modus im Konfigurationsdialog der ZenConsole aus. Linux-Systeme benötigen für den reibungslosen Betrieb von ZenArmor wie bereits erwähnt das Netmap-Framework. Aktivieren Sie im Konfigurationsdialog anschließend noch die Schnittstellen, auf denen ZenArmor arbeiten soll.

Neben dem Routing- oder Bridging-Mode lässt sich ZenArmor auch im Passive-Mode installieren. Diese Option ist interessant, wenn das eingesetzte Betriebssystem für ZenArmor nicht mit dem Netmap- Netzwerktreiber betrieben werden kann und Performanceeinbrüche zu erwarten sind. In der passiven Variante kann die Firewall den Netzwerkverkehr zwar auswerten (Monitoring), aber keine Filter zum Blockieren bestimmter Applikationen oder Websites anwenden.

Privacy-Einstellungen und Ausnahmen

Die weiteren Menüpunkte der Basiskonfiguration "Cloud Threat Intelligence", "Data Management", "Scheduled Reports", "Health Check", "Subscription" und "DNS Enrichment" sind selbsterklärend. Etwas mehr Beachtung verdienen dagegen die Einstellungen unter "Privacy" und "Exempted VLANs & Networks". Denn die Erfassung beziehungsweise Auswertung personenbezogener Daten wie sie in ZenArmor massenhaft anfallen, ist nicht in jedem Fall erlaubt oder erwünscht. Unter "Exempted VLANs & Networks" können Sie deshalb einzelne VLANS, einzelne IP-Adressen oder auch ganze IP-Netzwerke von der Überwachung ausnehmen.

Das ist zum Beispiel dann sinnvoll, wenn ein Betriebsrat im Unternehmen vorhanden ist. Dessen Netzwerkverkehr etwa darf in der Regel vom Betreiber der Firewall nicht überwacht werden. Die Einstellungen im Bereich "Privacy" beziehen sich hingegen auf alle Teilnehmer im Netzwerk. Unter "Reporting and Data" können lokale und Remote IP-Adressen anonymisiert sowie die Benutzererkennung für das Reporting ein- oder ausgeschaltet werden. Reports ohne Benutzernamen sind immer dann sinnvoll, wenn aus Datenschutzgründen keine Rückschlüsse auf die Aktivitäten einzelner Benutzer erfolgen soll.

Mit dem Schalter "Enter Bypass" auf dem Dashboard der ZenConsole können Sie übrigens die Packet-Engine von ZenArmor vorübergehend komplett deaktivieren. Die Firewall verhält sich dann wie eine L2-Bridge und leitet den Datenverkehr ungefiltert weiter. Das kann bei der Fehlersuche im Netzwerk ungemein hilfreich sein, um eine Beteiligung der ZenArmor-Packet-Engine an Verbindungsfehlern auszuschließen.

Verwaltung der Firewall delegieren

Die Einstellungen im Bereich "Users" beziehen sich auf die Benutzer der ZenConsole. Inhaber einer Business-Lizenz können mit den vier Rollenmodellen "Viewer", "Operator", "Admin" und "Owner" granulare Berechtigungsprofile für den Zugriff auf die Firewall-Administration via ZenConsole festlegen. Auf diese Weise lassen sich Firewalls von unterschiedlichen Administratoren verwalten. Der Gesamtüberblick bleibt beim Owner, der die Berechtigungen für die Admins auch jederzeit korrigieren oder entziehen kann.

Die Viewer-Rolle ist beispielsweise für Revisoren interessant. Diese können Einstellungen auf den zugewiesenen Firewalls zwar überprüfen, aber keine Änderungen vornehmen. Neu hinzugefügte Benutzer werden per E-Mail benachrichtigt, wenn diese sich zuvor mit ihrer E-Mail-Adresse einen Account unter der URL "https:// dash.zenarmor.com/register/newuser" erstellt haben. Um einem Benutzer letztlich mit seinen Berechtigungen Zugriff auf eine Instanz zu gewähren, wählen Sie aus dem Drei-Punkte-Menü der entsprechenden Firewall den Befehl "Share Firewall" aus.

Individuelle Block-Page und Bypass Codes

Derzeit noch als "Beta" bezeichnet ZenArmor die "individuelle Block-Page". Diese bekommen Nutzer angezeigt, wenn sie eine unzulässige Website aufrufen. Mit dem integrierten Editor lassen sich die Texte des mitgelieferten Templates direkt in der ZenConsole bearbeiten und ein Unternehmenslogo einbinden. Über die drei Punkte rechts über dem Editor können Sie alternativ auch ein eigenes Template hochladen. Damit das auch bei SSL/TLS-verschlüsselten Websites funktioniert, müssen drei Voraussetzungen erfüllt sein:

1. Das Host-System hat den Netmap-Treiber im Kernel geladen.

2. Der Schalter "Display Block Notification Pages for TLS encrypted connections" steht auf aktiv.

3. Das CA-Zertifikat der ZenArmor-Installation wurde heruntergeladen und als vertrauenswürdige CA in die Browser der Benutzer importiert.

Bypass-Codes entlasten Sie dabei als Admin, wenn Anwender trotz aktiver Web- oder App-Richtlinie temporär auf bestimmte Ressourcen zugreifen möchten. Die Codes werden für User oder Admins mit einer vordefinierten Laufzeit ausgestellt. Der betroffene Benutzer gibt diesen Code dann auf der Block-Page ein und kann, solange dieser gültig ist, entsprechend der Bypass-Konfiguration entweder sämtliche Beschränkungen oder nur bestimmte geblockte App- oder Webkategorien umgehen.

Den Hinweis auf den Beta-Status für die individuellen Block-Pages sollten Sie übrigens ernst nehmen. Nachdem wir beispielsweise an unserer Block-Page kleinere Änderungen vorgenommen hatten, wurde das blaue Schlosssymbol für die Eingabe der Bypass-Codes nicht mehr auf der Seite angezeigt. Vor eigenen Experimenten ist es deshalb sinnvoll, den voreingestellten HTML-Code mit der Download-Funktion (erreichbar über die drei Punkte rechts über dem Editor) herunterzuladen und zu sichern.

NG-Funktionen einrichten

Die Konfiguration der eigentlichen Next-Generation-Funktionen finden Sie unter dem Menüpunkt "Policies" im Hauptmenü. Standardmäßig bringt ZenArmor bereits eine Default-Policy mit. Diese können Sie zwar an den individuellen Bedarf anpassen, jedoch ist die Position im Regelwerk nicht veränderbar; die Default-Policy bleibt also grundsätzlich an letzter Stelle stehen. Individuelle Richtlinien erfordern eine kommerzielle Lizenz von ZenArmor. Mit dem Button "Create new Policy" erstellen Sie dann eine oder mehrere neue Regeln. Ist der Schalter "Real-Time Sync" aktiviert, werden die an den Policies vorgenommenen Anpassungen sofort an die Firewall übertragen und sind auch unmittelbar aktiv. Firewall-typisch werden die Policies von oben nach unten abgearbeitet (first hit).

Diese Tatsache sollten Sie im Hinterkopf behalten, denn die Reihenfolge der Policies lässt sich einfach per Drag-and-Drop ändern. Die kostenfreie Version schränkt die Konfigurationsmöglichkeiten für Policies allerdings deutlich ein. So ist das Erstellen individueller oder zentraler Policies nicht möglich. Auch die Echtzeitsynchronisation für Änderungen am Regelwerk lässt sich mit diesem Lizenztyp nicht aktivieren. Für kleinere Netzwerke genügen Anpassungen an der Default-Policy und ein manueller Sync aber durchaus.

Der Policy-Dialog besteht aus fünf Rubriken. Bei "Configurations" legen Sie fest, für welche IP-Netze und/oder MAC-Adressen beziehungsweise Benutzer oder Benutzergruppen die Policy Gültigkeit hat. Für jede Richtlinie kann darüber hinaus auch eine zeitliche Gültigkeit bestimmt werden. Mit diesen "Time Schedules" ließe sich beispielsweise die Kernarbeitszeit im Unternehmen mit einer restriktiven Policy verbinden, die nicht arbeitsrelevante Aktivitäten unterbindet. Entsprechend könnten Zeiträume außerhalb der regulären Arbeitszeit mit einer zweiten Policy und Time Schedule verknüpft werden, um Restriktionen für die Benutzer außerhalb der Arbeitszeit aufzuheben.

Unabhängig von den Kategorien des Webfilters lässt sich im Bereich "Security" üblicherweise unerwünschter Web-Traffic wie Hacking-, Malware-, Botnet- oder Proxy- und Spam-Sites grundsätzlich blockieren. Was genau gesperrt wird, ist leider nicht ersichtlich, Sie müssen sich bei dieser Einstellung also auf den Hersteller verlassen.

Der App-Filter unter "App-Controls" von ZenArmor basiert auf einer gut gepflegten Datenbank. Die Apps sind in 30 Kategorien organisiert, eine Suchfunktion hilft beim Aufspüren der passenden Kategorie. Blockiert werden können entweder ganze Kategorien oder auch spezifische Apps aus einer Kategorie. So blockieren Sie beispielsweise Remote-Access-Applikationen, geben die Nutzung bestimmter Anwendungen wie TeamViewer oder AnyDesk für einzelne IP-Netzwerke oder Benutzer aber frei.

Der Webfilter kategorisiert nach Angaben von ZenArmor mehr als 300 Millionen Websites. Bekanntermaßen ergibt es schon lange keinen Sinn mehr, einzelne Websites zu blockieren. Stattdessen können Sie aus folgenden vordefinierten Webfilter-Profilen auswählen:

- Permissive: Keinerlei Einschränkungen beim Surfen.

- Moderate Control: Gefährliche und potenziell riskante Websites aus den Kategorien Drogen, Gewalt, Erwachseneninhalte, Gewalt und Werbung werden vom Filter geblockt.

- High Control: Unterbindet den Zugriff auf Onlineforen, Webseiten zu Alkohol, Blogs, Spiele, Chats, Datingseiten, Jobsuche, Onlinespeicher, Soziale Netzwerke, Downloads, Waffen, Militär, Bademoden, Tabak und Warez.

- Custom: Mit dieser Einstellung lassen sich beliebige und individuell auf die Anforderung des Unternehmens abgestimmte Kategorien in einem eigenen Profil zusammenfassen.

Zusätzlich kann der Webfilter die Safe-Search-Option gängiger Suchmaschinen aktivieren. Damit werden bereits in der Vorschau der Suchergebnisse potenziell problematische Inhalte ausgeblendet. Übrigens: Unter der URL "https://www.zenarmor.com/site-classification" stellt ZenArmor eine Schnittstelle zu seiner Datenbank zur Verfügung. Hier können Sie einzelne Domains oder URLs auf deren Kategorisierung hin überprüfen.

Der wesentliche Unterschied zwischen der Applikationskontrolle und dem Webfilter besteht darin, dass Letzterer eine gezieltere Richtlinienverwaltung für HTTP(S)-Verbindungen ermöglicht. Die Applikationskontrolle greift dagegen auch bei anderen Protokollen und Verbindungstypen. Ein gutes Beispiel dafür ist der TOR-Browser. Dieser lässt sich auf einen beliebigen TCP-Port einstellen und wird von der Applikationskontrolle auch dann zuverlässig erkannt, wenn er nicht über Port 80 oder 443 kommuniziert.

Unter dem "Exclusion"-Tab der Policy-Verwaltung können eigene Block- oder Allowlists für Websites erstellt werden, die bisher nicht vom Webfilter erfasst werden (Blocklist). In einer Allowlist werden dagegen Domains eingetragen, die von einer Webfilter-Kategorie blockiert aber dennoch an die Benutzer ausgeliefert werden sollen.

Firewall-Restore ohne vollwertiges Backup

ZenArmor verfügt leider über keinen Policy-Tester, mit dem sich die Auswirkungen neuer Filter auf die Benutzer vor deren Aktivierung überprüfen lässt. Entsprechend vorsichtig sollten Sie beim Erstellen Ihrer Policies vorgehen, um unerwünschte Effekte oder gar eine Störung der Geschäftsprozesse zu verhindern.

Um die Auswirkung solcher Fehler zumindest zu begrenzen, steht die Funktion "Firewall Restore" im Policy-Hauptmenü zur Verfügung. Damit setzen Sie vor dem Hinzufügen oder Ändern von Regeln einen Restore-Point, zu dem Sie im Bedarfsfall per Mausklick wieder zurückkehren können. Eine Backupfunktion, mit der sich die Gesamtkonfiguration einer Firewall aus der ZenConsole exportieren lässt, steht bisher leider nicht zur Verfügung – im Gegensatz zur OPNsense-GUI.

Policies erstellen

Neben den individuell je Firewall konfigurierbaren Policies können Sie in der ZenConsole auch zentrale Regeln erstellen. Die Konfiguration dieser "Centralized Policies" erfolgt analog zu den lokalen Richtlinien und vereinfacht die Verwaltung einer großen Anzahl von Firewalls sehr, da für deren Aktivierung kein explizites Login mehr auf der jeweiligen Firewall erforderlich ist. Stattdessen können ZenConsole-Benutzer mit der Berechtigung "Owner" zentrale Policies einfach auf Firewalls in der zentralen Verwaltung pushen. Für dieses Enterprise-Feature setzt ZenArmor allerdings eine Business-Subscription voraus.

Ein zentrales Element von NG-Firewalls ist das Erstellen benutzerspezifischer Filterregeln. Mit diesen sperren Sie bestimmte Webressourcen oder Apps für individuelle Benutzer oder ganze Benutzergruppen. Voraussetzung dafür ist, dass ZenArmor die Benutzer zweifelsfrei identifizieren kann. Für die Benutzererkennung stehen zwei Verfahren zur Verfügung:

1. Nutzung des Captive-Portals auf OPNsense-Firewalls.

2. Einsatz eines Active-Directory-Agenten auf einem Windows-Domaincontroller.

Das Feature "User-based Filtering Policy" in Verbindung mit dem OPNsense-Captive-Portal setzt mindestens eine kommerzielle Lizenz vom Typ "Home" voraus. Für die Nutzung des AD-Agenten ist dagegen eine Business-Lizenz erforderlich. Weitere Informationen zu den verschiedenen Lizenztypen finden Sie im Kasten "Lizenzierung und Support" und unter [4].

Kommt ZenArmor auf einer OPNsense-Firewall zum Einsatz, müssen Sie für die Benutzererkennung zunächst das Captive-Portal aktivieren. Die Benutzer lassen sich dann entweder mit der integrierten Datenbank (local database) oder über externe Authentifizierungsdienste wie LDAP, RADIUS oder VOUCHER verwalten. Zusätzliche Authentifizierungserver sind gegebenenfalls zuvor im Webinterface von OPNsense unter "System / Access / Servers" anzulegen. Die mbeziehungsweise Benutzergruppen können Sie dann beim Aufbau benutzerspezfischer Filter auf dem Karteireiter "Policy Configuration" im Bereich "User & Groups" des Policy-Konfigurationsdialogs einbeziehen.

Der ZenArmor-AD-Agent [5] kommuniziert wahlweise mit dem ZenArmor-Plug-in einer OPNsense-Firewall oder mit einem Standalone-Gateway. Nach der Installation des AD-Agenten ist daher die IP-Adresse des OPNsense oder Standalone-Hosts einzutragen, mit dem die Userinformationen ausgetauscht werden sollen. In beiden Fällen ist für die Kommunikation darüber hinaus ein API-Key erforderlich. Diesen müssen Sie zuvor in der ZenConsole erstellen und im vorgesehenen Feld des AD-Agenten einfügen.

Fazit

Das Duo bestehend aus OPNsense und ZenArmor stellt derzeit die attraktivste Betriebsform von ZenArmor dar. Die Installation als Plug-in gestaltet sich einfach und die Administration von ZenArmor ist direkt über die Firewall-GUI möglich. Admins, die sich für eine Standalone-Installation im Layer-3-Routingmodus unter Linux entscheiden, müssen dagegen noch einen größeren Aufwand einplanen. Darüber hinaus lassen sich alleinstehende Installationen von ZenArmor ausschließlich mittels Cloudkonsole verwalten.

Wer diesen zusätzlichen Aufwand nicht scheut, erhält mit ZenArmor aber auch auf einem Linux-Host ein ausgereiftes, verständlich dokumentiertes und preislich attraktives Produkt. Größtes Manko in der NG-Funktionalität von ZenArmor ist die derzeit noch fehlende SSL/TLS Full-Inspection. Diese soll aber spätestens Anfang des kommenden Jahres zur Verfügung stehen.

Firewall ZenArmor aufsetzen

Besser gerüstet

Breiter Funktionsumfang

Breiter Funktionsumfang

Zentrales Management

Systemvoraussetzungen

Ohne Netmap kein vollwertiges ZenArmor

Verschiedene Betriebsformen

Account für die Cloudkonsole

Konfiguration über OPNsense und ZenConsole

Netzwerkschnittstelle und Deployment-Mode

Privacy-Einstellungen und Ausnahmen

Verwaltung der Firewall delegieren

Individuelle Block-Page und Bypass Codes

NG-Funktionen einrichten

Firewall-Restore ohne vollwertiges Backup

Policies erstellen

Fazit