Authentifizierung an der Firewall dank Netfilter-Modul

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.