Im Test: Firewall V50 von Barracuda
Sicherheit der nächsten Generation
Früher konnten Administratoren ein Unternehmensnetzwerk durch das einfache Blockieren von Port-Adressen sichern. Seit moderne Programme häufig ungeschützte Zugänge wie Port 80 und 443 für ihre Verbindungen nutzen, sind diese Zeiten vorbei. Wir stellen eine moderne Firewall vor, die den Netzverkehr auf OSI-Layer 7 überwacht und zeigen zugleich, dass eine solche Lösung auch anders als als Hardware-Box zum Einsatz kommen kann.Bis vor wenigen Jahren war der Aufbau eine Schutzinfrastruktur für das Unternehmensnetz für IT-Verantwortliche und Administratoren eine klare Sache: Während auf den Client-Systemen eine intensive Virussuche stattfand, kam auf den Servern ein eher moderater Virenschutz zum Einsatz. Proxy-Server mit Blacklists für die Internet-Anbindung und eine zentrale Firewall, die alle unerwünschten Protokolle an der Peripherie des Unternehmensnetzwerks abfing, rundeten dieses Standardkonzept ab. Doch leider kann eine derartige Strategie gegen die Angriffe, die heute die Unternehmens-IT bedrohen, nicht mehr bestehen.
Viele Wege, viele Gefahren und ein Lösungsansatz
Zu vielfältig sind die Wege geworden, die aus dem Internet ins Unternehmen und natürlich auch wieder zurück in das weltweite Netzwerk führen: So geht beispielsweise nicht nur Arbeitszeit, sondern häufig auch wichtige Information durch den Gebrauch nicht freigegebener, aber problemlos über die Firewall hinweg arbeitender Instant-Messaging-Lösungen verloren. Die Liste solcher Gefahren lässt sich beliebig fortsetzen. Um ihnen zu begegnen, bieten Firmen wie die Sicherheitsspezialisten von Barracuda moderne Firewall-Lösungen an, die mit Namenszusätzen wie UTMs (Unified Threat Management) oder NG (Next Generation) Abhilfe bei diesen Problemen versprechen. Barracuda liefert die eigenen Sicherheitsprodukte klassisch als Hardware-Appliance aus, zunehmend jedoch auch als virtuelle Appliance für den Einsatz unter VMwares ESX/ESXi-Hypervisor.
Für diesen Test hat uns der Hersteller eine seiner "Next Generation" Firewalls (Modell V50) zur Verfügung gestellt, die wir als virtuelle Appliance näher betrachtet haben. Dazu kam die Firewall in unserem Testszenario unter VMware Workstation 7 mit zwei zugewiesenen Netzwerkkarten, 2 GByte Arbeitsspeicher und einer zugewiesenen 18 GByte großen virtuellen Festplatte zum Einsatz. Die Verwendung der Appliance auf der VMware Workstation eignet sich nicht zum Einsatz in Produktivumgebungen, lässt sich jedoch sehr gut zu Testzwecken heranziehen. Im Praxisbetrieb kann die V50 für rund 50 Benutzer arbeiten. Sie ist dabei typischerweise als zentrale Firewall auf dem Hypervisor zwischen der DMZ und dem eigenen internen Netzwerk positioniert.
Die Einrichtung und Konfiguration einer solchen virtuellen Maschine unterscheidet sich kaum von der Bereitstellung einer physischen Appliance. Auch hier muss der Administrator zunächst eine interne IP-Adresse als Gateway beziehungsweise Proxy-Server festlegen, um dann eine externe IP-Adresse, die die Appliance mit dem Internet-Router in der DMZ verbindet, sowie eine interne Management-IP-Adresse zu bestimmen. Die Firewall-Appliance basiert auf einem 64-Bit Linux-Systems der Kernel-Generation 2.6, dessen Installation in der virtuellen Maschine ohne Probleme ablief. Der Administrator kommt im normalen Betrieb mit der Linux-Konsole auf der virtuellen Maschine kaum Berührung, da alle Konfigurationsschritte über eine Windows-Software von der Workstation aus vorzunehmen sind.
Dass Barracuda zur Verwaltung seiner Firewalls keine Browser-Applikation bietet, klingt beinahe ein wenig archaisch. Nahezu jeder Konkurrent im Segment Firewall nutzt eine SSL-gesicherte Verbindung über den Web-Browser, um auf sein System zuzugreifen. Ein Weg, der bei dieser Lösung nicht zur Verfügung steht: Der Administrator ist somit zwangsläufig auf den Einsatz einer aktuellen Windows-Maschine angewiesen, wenn er die Firewall verwalten will, was wir alles andere als zeitgemäß nennen. Auf Nachfrage bestätigte uns der Hersteller jedoch, dass man in absehbarer Zeit Abhilfe schaffen will.
Für den Test positionierten wir die NG-Firewall als zweites Gerät neben unserem externen Router in die DMZ. Dabei war weiterhin der interne Router für die Namensauflösung unseres Testnetzwerks zuständig. So mussten wir lediglich noch die Standard-Gateway-Einstellungen manuell oder per DHCP so anpassen, dass der Netzwerkverkehr durch die virtuelle Appliance floss. Wer bei einen derartigen Konfiguration keine verschlüsselte HTTPs/SSL-Verbindungen einsetzt, benötigt auch keinen transparenten Proxy-Service, da die Appliance den Standard-HTTP-Transfer intern umlenkt. Sollen jedoch auch die verschlüsselten Verbindungen durch diese Firewall gesichert sein, dann muss sie den Client-Browsern als Proxy-Server bekannt gemacht werden. Die Administratoren werden dies in einer Active-Directory-Umgebung typischerweise per Gruppenrichtlinie oder mithilfe von Regedit-Befehlen im Anmelde-Skript erledigen. Soll dann noch sichergestellt sein, dass alle lokalen Benutzer über die gesicherte Firewall-Anbindung mit dem Internet verbunden sind, müssen die Systembetreuer den regulären internen Router so umstellen, dass er grundsätzlich auf die Barracuda-Firewall zeigt, wenn es um eine Verbindung ins Internet geht.
Grundeinstellungen und Anpassungen
Wie es sich für alle modernen und ausgereiften Firewall-Produkte gehört, blockiert auch dieses Produkt nach der Aktivierung zunächst einmal jede Verbindung. Wir fanden es dabei sehr gut, dass die Entwickler bei Barracuda den Administrator nicht dazu zwingen, jede noch so allgemeine und gewöhnliche Einstellung selbst anzulegen. So artet die Einrichtung einer typischen Internet-Verbindung unter Verwendung der gängigen Protokolle HTTP, POP3 oder SMTP für den Administrator auch nicht zu einer Prüfung aus, ob er denn wirklich alle "well-known Port Addresses" im Kopf hat. Er muss in einem ersten Schritt lediglich die Firewall-Regel "BLOCK ALL" von der obersten Position der Hierarchie an die unterste Stelle schieben. Dadurch ist sichergestellt, dass die vorgegebene Standardkonfiguration mit der Genehmigung für die Internet- und VPN-Nutzung aktiviert ist und zunächst nur alle individuellen Regelwerke deaktiviert sind (Bild 2).
Für unseren Test wählten wir einige typische Firewall-Regeln aus, wie sie auch in Bild 2 zu sehen sind: So sollten der traditionelle Internet- und Intranet-Verkehr mit HTTP, HTTPs und den Mail-Protokollen passieren dürfen, während RDP-Verbindungen in Richtung Internet unterbunden sind. In der Standardeinstellung des Herstellers heißen diese Verbindungen in Richtung Internet folgerichtig "world". Diese Regeleinstellung konnten wir dann auch ohne vorheriges Briefing schnell und einfach einrichten: Wir mussten dazu nur unter "Forwarding-Rules" das Fenster mit den Einstellungen durch einen Klick auf die Schaltfläche "Lock" entsperren. Die Schaltfläche heißt danach "Unlock". Anschließend konnten wir die Regel anlegen, das gewünschte Protokoll aus den vordefinierten Services auswählen und die Änderung durch einen Mausklick auf "Activate" einschalten.
Abhängig von Protokoll und Regel ist es durchaus möglich, dass eine schon vor der Regelerstellung aktive Client-Verbindung, ungehindert aktiv bleibt, obwohl sie es nach der aktuell geänderten Regel nicht mehr sein sollte. In einem solchen Fall kann der Administrator so lange warten, bis der Client die Session von allein neu aufbaut. Will er aber ein sofortiges Ende der Verbindung und damit die Einhaltung der neu erstellten Regel erreichen, dann kann er in das Fenster "Live" wechseln, in dem alle aktuellen Verbindungen aufgelistet sind. Dort hat er die Möglichkeit, die Session manuell zu beenden, sodass die Einschränkung beim nächsten Verbindungsaufbau des Clients greifen. Insgesamt bewerten wir das Fenster "Live" als sehr nützlich, da es einem Systembetreuer sehr viele Informationen in Bezug auf Details der Verbindungen zu bieten hat. Dazu gehören unter anderem so interessante Daten wie Quelle, Ziel, Port, Service, Byte/s, Zeit der Inaktivität und beteilige Protokolle mit allen Zählern. Zudem kann ein Administrator dort Sessions direkt im "Trace" näher betrachten, was die Nachverfolgung von Aktionen deutlich vereinfacht.
Der Angriff erfolgt - die Firewall wackelte nicht
Im nächsten Testszenario wollten wir wissen, wie sich die Firewall gegenüber Port-Scannern und Firewall-Penetrationstests mit Exploit-Check und Bruteforce-Attacken verhält. Der einfache Port-Scan mit den Netzwerk-Tools eines aktuellen Imac-System dauerte über eine halbe Stunde und ergab keinen einzigen geöffneten Port. Das Ergebnis verwundert, da ja die Internet-Proxy-Verbindung zulässig ist. Im zweiten Schritt kam dann die etablierte Firewall-Penetration-Software "Metasploit" zum Einsatz. In der kostenpflichtigen Express-Edition erspart die Software dem Benutzer die Aktivierung der entsprechenden Tests von Hand und arbeitet diese automatisiert ab. Der Versuch des Durchbruchs verlief ebenso erfolglos wie die gezielte Suche nach Löchern mit Nexpose in der kostenfreien Community Edition. Lediglich ein Eintrag im Logfile der Barracuda unter "Threat Scan" protokolliert beinahe gelangweilt den Vorgang im Bereich "Intrusion Prevention System" (IPS) in der Kategorie "mittel".
Da es sich bei diesem Gerät um eine Firewall-Lösung der neuen Generation handelt, die für sich in Anspruch nimmt, auch auf dem höheren Layer der Anwendungen eine entsprechende Sicherheit zu bieten, wollten wir in einem weiteren Testszenario sicherstellen, dass keine ungenehmigte Kommunikation über Chat-Protokolle wie Jabber möglich ist. Dieses Protokoll nennen Experten heute auch "Extensible Messaging and Presence Protocol" (XMPP - erweiterbares Nachrichten- und Anwesenheitsprotokoll). Ein bekannter Vertreter dieser Kategorie ist die kostenfreie und seit Jahren als Beta klassifizierte "Google Talk"-Software, die sowohl über eine Client-Variante unter Windows, in Ichat oder Miranda als Jabber-Chat wie auch über den Web-Browser direkt nutzbar ist. Während sich Seiten wie Facebook im Unternehmen bekanntlich recht leicht sperren lassen, ist eine Blockade der Google-Seite eher kontraproduktiv. Folglich kann jeder Benutzer mit nur ein wenig Fantasie die Chat-Funktion nutzen, ohne dass der Administrator dies verhindern kann.
Zunächst versuchten wir es mit einer klassischen Port-Regel auf der Firewall und blockierten die "well-known" Ports 5222/TCP, 5269/TCP und 5223/TCP(SSL), die dem XMPP-Protokoll assoziiert sind. Dies brachte keinen Erfolg - Google Talk lief unbeeindruckt weiter. Erst nachdem wir den transparenten HTTP-Proxy durch einen nicht-transparenten HTTPs-Proxy ersetzten und zudem die so genannte "Application Detection" der Firewall aktivierten, verstummte Google Talk im Testnetzwerk (Bild 3): Die Software kommuniziert über den SSL-Port 443 und erfordert deshalb diesen Weg der Blockade.
Grundsätzlich muss sich der Administrator bei dieser Lösung jedoch um die Protokolldetails keine Gedanken machen - in der schier endlosen Liste von Applikationen findet sich alles von Spielanbindungen, Musik-Downloads, Streams, Fernwartungs- und Chat-Lösungen bis hin zu Businessprogrammen, denen man gezielt die Kommunikation entziehen kann. Zum Zeitpunkt der Artikelerstellung sind es bereits 844 Details von Anwendungen, die in rund 220 Knoten zusammengefasst sind. So können Administratoren Aktivitäten wie beispielsweise Rapidshare gezielt unterbinden.
Sicherheit auf dem Gateway durch Schadcode-Test
Es gehört beinahe schon zum guten Ton einer ausgereiften Firewall, insbesondere wenn sie sich mit dem Untertitel "Next Generation" schmückt, dass der Netzwerkverkehr gleichzeitig auf Schadcode wie Trojaner, Viren oder Würmer hin überprüft wird. Der Hersteller bietet bei dieser Lösung die Echtzeit-Prüfung mit der kostenfreien Open-Source Clam-AV-Engine und der optionalen Avira-Engine an. Das Doppelgespann an Virenschutz konnte im Test alle gestellten Aufgaben leicht bewältigen: Dazu gehörten unter anderem der Download der Eicar-Datei sowohl über HTTP und HTTPs als auch als COM-Datei, gezippt und doppelt gezippt. Zudem konnte die Lösung auch die auf www.testvirus.de zu findenden Schädlinge, zu denen der Trojaner TR/PRoxy.Mitg.gen2 und der Wurm Bagle.AT.1 gehören, sicher entdecken und blocken (Bild 4). Ein solcher Virenschutz auf Gateway-Ebene bietet einen sehr großen Vorteil: Auf diese Weise auch ältere Systeme von einem aktuellen Virenschutz profitieren, beispielsweise Windows 2000 Server, für die es keinen aktuellen Virenschutz mehr gibt, oder PC-Systeme, die aufgrund von starken Compliance-Regeln nicht mit einem sich selbst aktualisierenden AV-Client ausgestattet werden können.
Fazit: Professionell und ausgereift
Die Barracuda NG-Firewall wurde im Testszenario allen unseren Anforderungen gerecht und hat uns durch ihre Leistung überzeugt. Ohne die tatkräftige und hilfreiche Unterstützung durch den Hersteller und dessen Support hätten wir allerdings viele Konfigurationsschritte erst nach intensivem Lesen der Dokumentation und einigen (Fehl-)Versuchen vornehmen können: Die große Zahl der Konfigurationsmöglichkeiten und die Menge beinahe gleichlautender Einstellungen machen die Einstellung zu einer komplexen Angelegenheit.
Der Autor auf LANline.de: Bär
Der Autor auf LANline.de: Frank-Michael Schlede
Lesen Sie mehr zum Thema
