Aus Frankreich kommt mit NuFW ein Netfilter-Modul, das mit herkömmlichen Firewall-Prinzipien bricht: Statt einzelnen Rechnern Zugriffe zu erlauben sind NuFW-Regeln identitätsgesteuert. Vom Erfinder dieser Technik kommt die Firewall-Appliance Edenwall, die sich hier einem Test stellt.

Firewalls arbeiten heute meist auf Layer 3 und 4 des OSI-Modells, sie filtern anhand von IP-Adressen und TCP/UDP-Ports. Wer Informationen aus Schicht 7 einbeziehen will, muss auf Proxys oder recht simple Patterns zurückgreifen. Übel sieht es aus, wenn die Regelbasis anhand der Benutzerkennung filtern soll. Die meisten Konzepte hierfür stammen aus den 90er Jahren und gehen davon aus, dass an einem Rechner nur ein User arbeitet. Unter Linux oder auf Terminalservern ist diese Annahme falsch.

Wie es besser geht, zeigt das Open-Source-Lager: In den vergangenen Jahren sind für Netfilter [1] zwei Zusatzmodule erschienen, die es möglich machen, in der Firewall-Regelbasis Benutzer und Gruppen statt Quell-IP-Adressen als Kriterium zu verwenden und Layer-7-Daten einzubeziehen. Ersteres erledigt NuFW [2], das zweite der L7-Filter [3].

Beide Module hat die französische Firma INL [4] in ihrer Firewall-Appliance Edenwall [5] vereinigt (siehe Kasten “Hardware”). Von den INL-Gründern stammt auch das NuFW-Modul, folgerichtig ist die Benutzerauthentifizierung das auffallendste Merkmal der Firewall.

Im Test musste die Edenwall ihre Praxistauglichkeit unter Beweis stellen. Für ihre Administration stehen drei Module innerhalb der Weboberfläche bereit: Nuconf, Nuface (Open Source) und Nulog (ebenfalls Open Source). Letzteres ist ein PHP-gestütztes Frontend für Ulogd [6].

Edenwall

Produkt: Edenwall-Version 2.1 [5] mit NuFW in Version 2.0.22 [2] Funktion: Firewall-Appliance mit Layer-7-Filter und innovativer Benutzerauthentifizierung Hersteller: INL [4] Hardware: 1-HE-Einschub von Portwell [7] Linux: Kernel 2.6.19.4 mit Grsecurity-Patch Lizenz: Die Kernfunktionen der Edenwall sind Open Source: L7-Filter sowie NuFW und dessen Linux-Client stehen unter der GPL. Der Windows-Client ist proprietär und kostenpflichtig, ebenso ein Teil der Admin-Oberfläche (Nuconf). Nuface und Nulog auch als GPL erhältlich. Preise: Je nach Anzahl geschützter Benutzer. Edenwall 50 (für 50 geschützte Benutzer) beginnt bei 4700 Euro, Edenwall 500 (für 500 geschützte Benutzer) trägt ein Preisschild von knapp 22000 Euro. Mit dabei ist Hardware der Firma Portwell. Auf IBMs P5-505-RISC-Hardware liegen die Preise etwa 60 Prozent höher. Support für ein Jahr kostet je nach Option ein Viertel des Anschaffungspreises zusätzlich.

Identitätsfrage

Das Regelwerk der Edenwall kennt auf Layer 3 mit Network Address Translation (NAT), Quell- und Ziel-IP-Adressen, Protokollen und Portnummern alle Parameter, die auch eine konventionelle Stateful Firewall verwendet. Im Test haben auch anspruchsvollere Aufgaben ohne Probleme funktioniert, etwa NAT für ISAKMP (Internet Security Association and Key Management Protocol) sowie UDP-gekapselter Verkehr von VPN-Clients (IPsec mit AH und ESP: Authentication Header und Encapsulated Security Payload).

Oft will ein Firewall-Admin eigentlich gar keine Quell-IP-Adressen verwenden, sondern dem Benutzer Privilegien geben, der gerade den Rechner bedient. Bei herkömmlichen Firewalls helfen nur Notlösungen. In einem verbreiteten Ansatz gibt der DHCP-Server den Rechnern der privilegierten Benutzer oder Gruppen statische IP-Adressen. Der DHCP-Dienst identifiziert die Maschinen anhand ihrer MAC-Adresse. Die Firewall-Regelbasis muss dann darauf vertrauen, dass die Zuordnung MAC/IP stimmt und dass sich am Computer nur der privilegierte Benutzer anmeldet.

Darüber hinaus gibt es die manuelle Authentifizierung über HTTP oder Telnet gegen die Firewall. Dieses Feature implementieren die meisten kommerziellen Produkte; es leitet den ersten Webzugriff von einem internen Rechner auf eine Login-Seite um oder verlangt, dass sich der User vorab per Telnet an der Firewall anmeldet. Erst danach schaltet der Regelsatz den Rechner frei, von dem die Authentifizierung stammt.

Das Verfahren ist umständlich für den Anwender und bei Multi-User-Clients unsicher, da es immer für die Quell-IP-Adresse gilt. Admins setzen diese Techniken daher nur ein, wenn ihnen keine andere Wahl bleibt.

Glücklicherweise sind diese Arbeitsweisen nicht per RFC oder anderweitig in Stein gemeißelt, denn es geht besser: NuFW erkennt den Benutzer, von dessen Account eine Verbindung stammt, anhand eines eigens auf dem Clientrechner installierten Programms. Diesen NuFW-Client gibt es derzeit für Linux und Windows und bald auch für Mac OS X.

Damit lassen sich in der Edenwall Regeln anlegen, die anstelle von Quell-IP-Adressen einen Benutzer oder eine Benutzergruppe verwenden. Die Kombination ist grundlegend anders und deutlich sicherer und flexibler als die herkömmliche Implementierung mit Telnet- oder HTTP/HTTPS-Authentifizierung.

Gut integriert

Viel Mühe hat sich Hersteller INL damit gegeben, die Edenwall in ein Windows-Umfeld zu integrieren. Das Produkt bindet sich an eine Active-Directory-Domäne (Abbildung 1) und es gibt neben dem Linux- auch einen Windows-Client (Abbildung 2). Die NuFW schafft es zusammen mit dem Client (getestet: Nuwinc für Windows) festzustellen, welcher Benutzer welches TCP-Paket losgeschickt hat. Der Overhead bleibt dabei sehr gering. Die Identity-basierten Regeln in der NuFW sind permanent vorhanden und folgen mobilen Benutzern von Computer zu Computer.

Abbildung 1: Statt selbst jeden Account zu verwalten, greift Edenwall auf einen Directory-Service zurück. Zur Wahl stehen LDAP und das Active Directory.

Abbildung 2: Dank NuFW-Client (hier in der Windows-Version) authentifiziert sich der Benutzer an der Edenwall. Die filtert dann anhand der User-Kennung und nicht anhand seiner Quell-IP-Adresse.

Auch ist es möglich, auf einer Multi-User-Maschine, einem Mainframe oder Terminalserver einzelne Benutzer zu unterscheiden und ihnen andere Rechte zu geben, selbst wenn alle Pakete von der gleichen Quell-IP-Adresse kommen.

Für die Authentifizierung einer Verbindung arbeiten Edenwall und Client-Computer zusammen:

• Auf der Edenwall laufen eine Firewall mit NuFW und ein
  Authentication Server (Nuauth), die miteinander kommunizieren.
• Auf dem Client ist der Nuwinc installiert, der sich nach dem
  Starten auf TCP-Port 4130 mit dem Authentication Server verbindet.
  Über diese TCP-Verbindung authentifiziert später Edenwall
  die bei ihr eintreffenden SYN-Pakete. Arbeiten mehrere Benutzer zur
  gleichen Zeit auf demselben Host, dann startet jeder seinen eigenen
  Client.

Sendet eine Applikation ein SYN-Paket für eine neue Verbindung, läuft das Paket erst einmal in eine Queue der Firewallsoftware NuFW (Schritt 1 in Abbildung 3). Die Firewall NuFW fragt dann beim Authentifizierungsdienst Nuauth nach, ob er das Paket authentifizieren kann (2). Nuauth nutzt die bereits vorhanden Verbindung, die von dem Client ausgeht, der auch das SYN-Paket gesendet hat. Nuauth fragt den Client nach den aktuellen Credentials (3, 4). Gibt es mehrere User auf der Maschine, fragt der Dienst der Reihe nach jeden Client.

Abbildung 3: Damit die Firewall einen internen Benutzer erkennt und je nach Identität die Verbindungen filtert, greift NuFW auf die Dienste von Nuauth zurück. Der kommuniziert wiederum mit einem eigens auf dem Client installieren Programm.

Danach kann Nuauth entscheiden, ob die Credentials passen und im positiven Fall die Firewallsoftware NuFW informieren, um welchen Benutzer es sich handelt (5). Abhängig von der Regelbasis weiß NuFW dann, ob das Paket für diesen Benutzer erlaubt ist oder nicht (6). Um alle weiteren Pakete dieser Verbindung kümmert sich Netfilter, ohne weiteren Overhead zu erzeugen.

Das Schema erinnert an den Ident-Daemon [9]. Ident verzichtet aber auf Authentifizierung, er ist nur als Informationsdienst ausgelegt und setzt voraus, dass der Administrator des Clients vertrauenswürdig ist. Ident-Angaben lassen sich trivial fälschen, Nuauth nicht.

Hardware

Die getestete Edenwall-Hardware basiert auf der Portwell NAR-5060 Communication Appliance [7]. Das 19-Zoll-Rackgerät ist laut Hersteller für kleine bis mittlere Unternehmen geeignet. Drinnen rechnet ein Intel Pentium 4 mit 2,8 GHz (mit 512 KByte L2-Cache und FSB 533) unter Zuhilfenahme von 512 MByte RAM (DDR 400, Timing 3-3-3) und einer 1-GByte-Compactflash-Karte. Die CF-Card ist leider nicht mit einem Bügel in dem Socket arretiert und es steht zu befürchten, dass sie sich beim Transport oder bei längerem Betrieb durch Vibration lockert. Das Chassis ist eigentlich für eine 2,5-Zoll-Festplatte vorbereitet (rechts unten in Abbildung 4). Die würde Strom sparen und somit Hitzeentwicklung, außerdem sind Laptop-Festplatten unempfindlicher gegenüber Stößen und Vibrationen. Die Firma INL hat sich jedoch stattdessen für eine IDE-PATA-Festplatte in herkömmlicher Bauform entschieden (Seagate ST340015A mit 40 GByte). Abbildung 4: Die Hardware der Edenwall stammt von Portwell. Das Compactflash-Modul (Mitte unten) dient zur Neuinstallation und zum Komplett-Reset. Statt der vorgesehenen Seagate-PC-Festplatte (links unten) wäre es sinnvoll gewesen, den Halter rechts unten mit einer Notebook-Platte zu bestücken. Um die Spannungsversorgung kümmert sich ein einzelnes 250-Watt-Netzteil. Des weiteren sind ein freier IDE- und ein Com-Port vorhanden, die für den Endkunden nicht nutzbar sind. Der serielle Port an der Frontseite der Appliance ist deaktiviert. Das LCD-Display an der Frontseite der Appliance setzt INL sehr durchdacht ein. Es bietet zusammen mit den umliegenden vier Tasten nützliche Funktionen wie zum Beispiel Shutdown und Reboot sowie eine sehr clevere Funktion: Hat sich der Admin per Regelwerk selbst ausgesperrt, kann er die HTTPS-Administration auf diesem Wege wieder freischalten.

Zusatzschutz

Zusätzlich zum identitätsbasierten Firewalling bringt die Edenwall-Appliance zwei Features mit, die die Sicherheit erhöhen. Der NuFW-Client schickt mit jedem authentifizierten Paket den Pfad der Applikation mit, die es geschickt hat. Eine Regel kann zum Beispiel bestimmen, dass Benutzer 1 auf TCP-Port 80 mit Firefox ins Internet darf, aber nicht mit Internet Explorer. Das vermeidet, dass Applikationen (Trojanische Pferde, Viren, Würmer) ohne Wissen des Benutzers nach Hause telefonieren.

Dieses Konzept erinnert an Checkpoint Integrity [8]. Deren Produkt sieht aber vor, verdächtige Applikationen bereits an der Netzwerkkarte des Client-PC durch eine Personal Firewall zu blocken. Damit verhindert Checkpoint Integrity, dass ein PC andere PCs im selben Netzwerk mit Viren oder Ähnlichem infiziert. Im Grunde handelt es sich bei dieser Clientsoftware nur um eine Zonelabs Personal Firewall, die Checkpoint im Jahr 2004 erworben hat und jetzt unter neuem Konzept als Integrity vermarktet.

All zu sehr sollte sich zwar kein Admin darauf verlassen, dass die Client-seitigen Integritätsmechanismen funktionieren. Es gibt genug Beispiele, in denen Würmer eine Personal Firewall abschalten oder umgehen. Auch der mitgeschickte Pfad garantiert nicht, dass sich dahinter eine unveränderte Anwendung verbirgt. Dennoch lohnt dieser Schutz, da er die Hürde für Angreifer höher legt.

Außerdem verfügt die Edenwall über einen L7-Filter ([3], Version 2.9). Dessen Patterns, die man übrigens selber einfach erweitern kann, erkennen weit mehr Protokolle als die meisten konventionellen Firewalls. Auch ohne einen Proxy einzusetzen lässt sich so bestimmen, dass auf TCP-Port 80 nur HTTP laufen darf (Abbildung 5) und keine Peer-to-Peer-Software oder gar VPN-Lösungen.

Abbildung 5: Mit Hilfe eines L7-Filters kann Edenwall ein Protokoll nicht nur anhand der Portnummer erkennen, sondern auch anhand der Daten, die es übermittelt. Mit der HTTP-Strict-Einstellung darf auf Port 80 nur HTTP-Verkehr passieren.

Installation

Die Edenwall-Appliance ist fürs Rack ausgelegt und eine Höheneinheit groß (siehe Kasten “Hardware”). Nach dem Einschalten ist sie auf dem Port »GbE1« – mit der IP-Adresse 192.168.1.1 vorkonfiguriert – per Browser mit HTTPS erreichbar (Abbildung 6). Das Web-GUI der Edenwall fasst drei Komponenten zusammen: Nuconf versorgt die Appliance mit IP-Adressen, Routen und anderen Parametern. Nuface ist das Frontend zu NuFW. Dort legt der Admin seine Regelbasis an. Nulog ist ein Frontend für den Netfilter-Ulogd [6]. Das GUI der Edenwall verwendet leider auch diese kryptischen Bezeichnungen.

Abbildung 6: Bei der Erstinstallation gibt der Admin per Nuface-GUI die wichtigsten Parameter der Appliance vor. Dass das externe Netz immer am Interface »GbE0« angeschlossen ist, erscheint unnötig starr.

Die ersten Einstellungen sind in Nuconf zu tätigen. Die Firewall braucht mindestens eine IP-Adresse auf ihrem externen Interface (»GbE0«), einen internen Port sowie einen Directory-Service mit der User-Datenbank. Als Directory-Service kennt sie Active Directory und LDAP (siehe Kasten “Edenwall mit LDAP”). Bei der anschließenden Konfiguration der Edenwall als Member-Server im Active Directory ist zu beachten, dass alle Komponenten sauber funktionieren:

• Systemzeit und Zeitzone müssen auf dem AD-DC (Active
  Directory Domain Controller) und der Edenwall-Appliance
  übereinstimmen. Am besten klappt dies, wenn der AD-DC als
  NTP-Zeitserver im Edenwall-GUI eingetragen ist.
• Der interne AD-Nameserver muss in der Edenwall eingetragen sein
  und funktionieren.
• Der Benutzeraccount, mit dem sich die Edenwall in die AD-Domain
  einklinkt, muss korrekte Rechte besitzen.

Im Test kam ein Windows 2003 Enterprise Domain Controller als AD zum Einsatz. Die Tester haben viel Zeit darauf verwendet, die Edenwall-Appliance zur AD-Domain zu joinen. Zweimal musste der Hersteller mit einem Patch reagieren. Einmal davon wurden die Tester für den Remote-Zugriff des Herstellers aufgefordert, über eine versteckte Funktion im GUI einen SSH-Daemon auf der Appliance zu aktivieren, der nur den Key des Herstellers zum Login akzeptiert. Nötig war dies, weil das Logging beim Einbinden in die Domain sehr dürftig ausfällt. Gescheitert war die Inbetriebnahme des Geräts an einem DNS-Bug und einem NAT-Device.

smbldap-useradd -u 1501 user1
smbldap-usermod -G 'Domain Users' user1
smbldap-useradd -u 1502 user2
smbldap-usermod -G 'Domain Guests' user2
smbldap-passwd user1

NAT-Hürden

Das Sicherheitskonzept der NuFW kann nicht akzeptieren, dass NAT die Quell-IP-Adresse und -Portnummer auf dem Weg zur Edenwall verändert. Bei den meisten Source-NAT-Konfigurationen auf Routern verstecken sich mehrere Quell-IP-Adressen hinter einer einzigen NAT-IP-Adresse. Die üblichen NAT-Implementierungen modifizieren dann den Quell-Port der TCP/UDP-Pakete, wodurch es NuFW unmöglich wird, die Benutzer zu unterscheiden.

Wenn der Directory Service funktioniert, sind ein paar Feineinstellungen an der Reihe, zum Beispiel ob der eingebaute Squid-Proxy mit einem Virenscanner arbeiten soll oder ob Edenwall als DHCP-Server dient. Danach gilt es, die Clientsoftware auf den PCs zu verteilen. Für Windows kommt der bereits erwähnte Nuwinc zum Einsatz. Für Linux gibt es den Kommandozeilen-Client »nutcpc« sowie das Gnome-Applet Nuapplet und die Gnome-Applikation Nuapp.

Konfiguration mit Nuface

Bei der Konfiguration baut Nuface die Accesslisten (ACLs) aus Subjekten, Ressourcen, Protokollen, Applikationen und L7-Filtern auf. Alle diese Elemente sind aus so genannten Working Elements zusammengesetzt. Unter Subjekt versteht die Edenwall die Quelle eines Pakets (ein Benutzer oder eine IP-Adresse, Abbildung 7); Ressourcen dienen als Ziel eines Pakets (immer eine IP-Adresse, nie ein Benutzer). L7-Filter sind dafür da, nicht stur TCP- oder UDP-Ports zu öffnen, sondern auch festzustellen, welches Protokoll tatsächlich den jeweiligen Port verwendet.

Abbildung 7: Nuface zeigt sich beim Administrieren reichlich unübersichtlich. Hier legt der Admin ein Subjekt an, das als Quelle von Verbindungen in den ACLs dient. Das Subjekt »authenticated.users« fasst die Verbindungen aller Benutzer zusammen, die sich erfolgreich authentifiziert haben.

An vielen Stellen gibt sich das Nuface-GUI störrisch. Es scheint schwer zu sein, die vielen Funktionen der Edenwall so zu zähmen, dass am Ende ein für jeden Admin verständlicher Ablauf entsteht. Zwei Dinge haben die Tester besonders gestört: Eine saubere Cleanup-ACL ist nur auf Layer 3 möglich (any – any – any – deny – log, um alle unerlaubten Versuche sauber zu verbieten und zu loggen). Und es scheint kaum möglich, diese ACL bei der weiteren Arbeit am Ende der Regelbasis zu halten. Die Abfolge der ACLs lässt sich nur in bestimmten Ansichten des GUI per Drag&Drop beeinflussen. Die Bedeutung der einzelnen Ansichten erschließt sich nicht.

Dass beim Test viel Zeit für die Einarbeitung und das Aufspüren von Fehlern im Setup nötig war, ist größtenteils der Weboberfläche anzulasten. Die Konfiguration läuft schmucklos und ohne benutzerfreundliche Symbole ab. Bereits angelegte ACLs lassen sich nur manchmal wieder ändern. Oft hilft nur noch, sie ganz zu löschen und neu anzulegen. Um herauszufinden, dass sich User-Identitäten mit dem Working Element »nufw_« verwenden lassen, ist ein längerer Exkurs ins Manual nötig. Diese oberflächlichen Schwächen sind besonders ärgerlich, da die Idee hinter der Edenwall deutlich besser ist als bei konventionellen Firewalls.

Sehr zum Erstaunen der Tester kommt nach Auskunft des Herstellers die Edenwall auch mit Userauthentifizierung über Zertifikate und Smartcards zurecht. Hersteller INL hat dazu ein neues Modul mit dem Namen NuPKI entwickelt. Es soll in der nächsten Edenwall-Release zusammen mit Site-to-Site-VPN enthalten sein. Derzeit läuft NuPKI beim französischen Bildungsministerium als einem Pilotkunden. Sogar um IPv6 kümmert sich INL in der NuFW-Release 2.2 und sorgt damit für ein zukunftssicheres Produkt.

Innere Werte

Schwächen zeigt die Edenwall vor allem am GUI. Es ist unübersichtlich und schwer bedienbar. Mehr als etwa 100 Accesslisten lassen sich damit kaum beherrschen. Auch die Hardware der getesteten Appliance überzeugt nicht. Trotz Fehler und Schwächen und der beiden Bugs, die den Start erschwerten, sind NuFW und die Edenwall-Appliance aber auf dem richtigen Weg. Seit Jahren versuchen Hersteller (etwa unter dem Schlagwort “AAA”) das Verständnis und die Akzeptanz von Identity-basierten Systemen und Rechten auf dem Markt zu etablieren. Die Edenwall geht hier genau in die richtige Richtung. (fjl)