Zaleman - stock.adobe.com
Zenarmor und OPNsense: Open-Source-Firewall optimal einrichten
OPNsense gehört zu den bekanntesten und umfangreichsten Open-Source-Firewall-Lösungen. Zusammen mit Zenarmor lässt sich eine hochmoderne Next Generation Firewall aufbauen.
In der modernen Netzwerksicherheit sind leistungsstarke Firewall-Lösungen unverzichtbar. Zenarmor (ehemals Sensei) erweitert die Open-Source-Firewall OPNsense um Next-Generation-Funktionen wie Anwendungskontrolle, Netzwerkanalyse und TLS-Inspektion. Diese Kombination bietet Unternehmen jeder Größe eine kosteneffiziente Alternative zu teuren kommerziellen Lösungen, ohne Kompromisse bei der Sicherheit einzugehen. Die Integration von Zenarmor in OPNsense ist unkompliziert und ermöglicht eine schnelle Implementierung fortschrittlicher Sicherheitsfunktionen.
Wir haben uns bereits im Beitrag OPNsense mit Zenarmor zur Next-Generation Firewall aufrüsten mit dem Thema beschäftigt, wie sich mit Open Source-Komponenten eine mächtige Firewall aufbauen lässt, die Enterprise-Lösungen in kaum etwas nachsteht. Sobald die Installation abgeschlossen ist, schützen Zenarmor und OPNsense das Netzwerk bereits zuverlässig, wie im verlinkten Beitrag gezeigt. Es ist allerdings wichtig, die Umgebung regelmäßig zu überprüfen, zu optimieren und die Aktionen von OPNsense und Zenarmor zu überwachen.
Zenarmor in einem OPNsense-Cluster nutzen
Diese Konfiguration lässt sich auch in einem OPNsense-Cluster betreiben. Ein solcher Cluster lässt sich auch für KMU schnell und einfach aufbauen. Dazu sind lediglich zwei identische OPNsense-Installationen erforderlich, die zu einem Cluster verbunden werden. In einem solchen Szenario lässt sich Zenarmor dann ebenfalls hochverfügbar betreiben. Das ist auch für KMU durchaus sinnvoll, da die Hardware für OPNsense nicht teuer sein muss..
Insbesondere in KMU-Szenarien mit mehreren Standorten lässt sich durch die Kombination von OPNsense-Clustern und der Cloud-basierten Zenarmor-Administration eine einheitliche Sicherheitsarchitektur etablieren. Dabei spielt die zentrale Verwaltung über die Konsole eine entscheidende Rolle. Über diese lassen sich sämtliche Knoten konsolidiert überwachen, Richtlinien editieren und Lizenzen verwalten. Für Dienstleister bietet diese Oberfläche zudem Mandantenfähigkeit, wodurch sich mehrere Kundeninstallationen effizient betreuen lassen. In der Praxis bedeutet dies einen reduzierten Administrationsaufwand bei gleichzeitiger Verbesserung der Reaktionsfähigkeit im Falle von Bedrohungen oder Regelverletzungen.
Im Rahmen der Cluster-Konfiguration werden unter System/Hochverfügbarkeit die verschiedenen Einstellungen gesetzt und die Replikation zwischen den Cluster-Knoten konfiguriert. Hier lassen sich auch die Daten von Zenarmor zwischen den Knoten replizieren.
Generell ist es sinnvoll, möglichst alle Daten zwischen den Cluster-Knoten zu replizieren, da dies sicherstellt, dass im Falle eines Ausfalls oder einer Wartung eines Knotens der andere Knoten automatisch alle Dienste, auch die Next-Generation-Firewall-Dienste von Zenarmor, übernehmen kann.
Zenarmor richtig verwalten
Zwar lässt sich Zenarmor auf leistungsschwacher Hardware betreiben, doch stößt die Kombination mit lokalem Elasticsearch schnell an die Grenzen der Ressourcen. Wer mit vielen gleichzeitig aktiven Geräten arbeitet oder umfassende Reports erzeugen möchte, sollte daher mindestens acht GByte RAM und SSD-Speicher einplanen. Alternativ kann die Reporting-Datenbank auf einen separaten Server ausgelagert werden, um OPNsense zu entlasten. Dies ist besonders in virtuellen Umgebungen kritisch. Hier kommt es durch CPU-Overhead und geteilte Netzwerktreiber schnell zu Engpässen, insbesondere bei hohen Durchsatzraten oder aktivierter TLS-Inspektion.
Im ersten Beitrag zu OPNsense und Zemarmor (siehe oben) zeigen wir, wie Zenarmor grundsätzlich installiert und eingerichtet wird. Nach der Implementierung von Zenarmor auf OPNsense findet sich das neue Menü Zenarmor auf der linken Seite. Über Dashboard zeigt Zenarmor eine Zusammenfassung an. Dies funktioniert bei alleinstehenden OPNsense-Installationen genauso wie bei der Nutzung eines Clusters.
Im Dashboard sollte man regelmäßig überprüfen, ob bei Engine und Reporting Engine der Status Running angezeigt wird. Es kann immer wieder einmal passieren, dass die Datenbank Probleme verursacht und neu installiert werden muss. Das lässt sich an dieser Stelle erledigen.
Unter Live Sessions sind die aktuellen Verbindungen aus dem Netzwerk zum Internet oder anderen externen Netzwerken zu sehen. Zenarmor zeigt an dieser Stelle außerdem die Quell-IP-Adressen und -Ports sowie die dazugehörigen Ziele an. In diesem Zusammenhang sind auch die Bereiche Threats und Blocked wichtig, da hier die von Zenarmor gefundenen Bedrohungen angezeigt werden und ob eine Blockierung auf Basis der Regeln erfolgt ist.
Zenarmor stellt umfangreiche Monitoring- und Analysefunktionen bereit, darunter die erwähnten Echtzeit-Session-Ansichten, Block-Reports und Bedrohungsstatistiken. Für größere Umgebungen empfiehlt sich zusätzlich das Streaming der Logdaten an zentrale SIEM-Lösungen wie Splunk oder Graylog über Syslog oder die REST-API. Wenn keine TLS-Inspektion zum Einsatz kommt, sollten DNS-basierte Filtermechanismen deaktiviert werden. Andernfalls können blockierte Inhalte nicht zuverlässig identifiziert werden und Benachrichtigungen werden nicht angezeigt. Zenarmor unterstützt auch Snapshots und lässt sich bei Bedarf durch vollständige Neuinstallation und Konfigurationsimport wiederherstellen.
Ein zentrales Element der Zenarmor-Architektur ist die präzise Steuerung des Datenverkehrs über Richtlinien. Je weniger Kriterien eine Richtlinie verwendet, desto robuster und leistungsfähiger ist ihre Umsetzung. Mehrere Bedingungen innerhalb einer Richtlinie wirken kumulativ, nicht alternativ. Das bedeutet, dass jede einzelne Bedingung auf den Datenstrom zutreffen muss, damit die Regel greift. Für den produktiven Einsatz bedeutet dies, dass möglichst klar definierte und schlank konfigurierte Regeln eingesetzt werden sollten. Fehlerhafte oder überkomplexe Regelwerke führen nämlich nicht nur zu inkonsistentem Verhalten, sondern belasten auch unnötig die Systemressourcen. Besonders wirkungsvoll ist die Kombination von MAC-Adressen mit Gerätezuweisungen, da sich so selbst bei wechselnden IP-Adressen eine zuverlässige Identifikation gewährleisten lässt.
Um HTTPS-Verbindungen analysieren zu können, muss die TLS-Inspektion aktiviert und ein internes Root-Zertifikat auf den Endgeräten installiert werden. Zenarmor bietet hierfür eine eigene Zertifizierungsstelle, deren private Schlüssel unbedingt gesichert werden sollten. Alternativ empfiehlt sich der Aufbau einer Intermediate-CA, die über eine eigene Root-CA signiert wird. Das erleichtert den Austausch kompromittierter Schlüssel und schützt vor manueller Neukonfiguration auf den Clients. Im transparenten Proxy-Modus wird HTTP- und HTTPS-Verkehr automatisch umgeleitet, ohne dass Proxy-Einstellungen auf den Endgeräten nötig sind. Allerdings ist hierfür eine saubere NAT-Regelkonfiguration inklusive korrekter Weiterleitung auf die entsprechenden Ports (3128 für HTTP und 3129 für HTTPS) nötig. Am aufwendigsten ist die Verteilung des Root-Zertifikats, insbesondere in heterogenen Umgebungen mit verschiedenen Betriebssystemen.
Erweiterte Zenarmor-Funktionen freischalten
Sowohl OPNsense als auch Zenarmor lassen sich kostenlos einsetzen. In der kostenlosen Variante von Zenarmor fehlen allerdings verschiedene Funktionen. Dazu gehört das Anlegen eigener Richtlinien sowie erweiterte Einstellungen in den Richtlinien. Wer diese im Netzwerk nutzen will, kann über Einstellungen/Subscription einen Aktivierungs-Key für eine erweiterte Edition eintragen. Die Lizenzierung von Zenarmor erfolgt über das Dashboard in der Zenarmor-Cloud.
