© Bildpixel, Pixelio.de

Ein internes Netz ohne virenverseuchte oder einbruchsgefährdete Rechner ist die Idealvorstellung der Network Access Control (NAC). Um das zu erreichen, macht sie für die abgeschottete Produktivumgebung einen Zugangstest obligatorisch. Praktisch durchgesetzt hat sich die Idee jedoch noch nicht.

Das Akronym NAC (Network Access Control) geistert nun schon seit sieben Jahren durch die IT-Welt. Dennoch hat sich die Technologie, die Rechnernetze sichern will, noch immer nicht kommerziell durchgesetzt. In der Open-Source-Welt genießen derzeit nur die beiden NAC-Varianten Open NAC / Free NAC [1] und Packetfence [2] (Abbildung 1) regelmäßige Pflege und Weiterentwicklung. Im kommerziellen Lager haben schon einige NAC-Lösungen schweigend das Handtuch geworfen oder werden nicht mehr aktiv vermarktet, zum Beispiel die auf Open BSD aufsetzende NAC-Appliance der Firma Verniertnetworks.

Abbildung 1: Das Packetfence Dashboard. Im Beispiel sind »Total Nodes« und »Unregistered Nodes« gleich, weil fast alle Benutzer mit statischen IP-Adressen arbeiten und NAC noch nicht verwenden.

Grund genug nachzusehen, was sich hinter dem Schlagwort NAC genau verbirgt, was von den ursprünglichen Visionen Realität wurde, was noch zu erwarten ist und was sich mit den Open-Source-NAC-Systemen erreichen lässt.

Nach den Vorstellungen der NAC-Architekten würde jeder Benutzer, der seinen Computer – in vielen Fällen ein Laptop oder ein mobiles Endgerät – mit dem LAN verbindet, erst einmal in einem Quarantänebereich landen. Dort müsste er sich authentifizieren. Im Anschluss würde ihm das NAC-System ein Profil zuweisen, das weitere Anforderungen an die Sicherheit seines Rechners festschriebe und zugleich die Rechte definierte, die ab dem Moment gelten, ab dem er als sicher eingestuft im Produktivnetzwerk zugelassen würde.

Rechner in Quarantäne

Vorher würde jedoch der Laptop im Quarantänebereich auf Viren gescannt und gegebenenfalls mit den neuesten Patterns und Updates für den Virenscanner versorgt. Erst danach dürfte er das Quarantäne-VLAN verlassen.

Soweit die Theorie. Die Praxis gestaltet sich deutlich schwieriger: Die meisten Anwender wollen ihren Laptop am Arbeitsplatz sofort in Betrieb nehmen. Zumeist langweilt schon der Bootprozess. So gut wie niemand hat Verständnis dafür, dass sich der mobile Rechner dabei noch ein paar Minuten scannen und patchen lassen soll. Zumal für Tests und Updates unter Umständen Fremde mit erweiterten Privilegien auf den eigenen Rechner zugreifen müssten, was Misstrauen weckt.

Patches und NAC

Eine andere Ungereimtheit, die in kommerziellen Umgebungen beim Einsatz von NAC zu Tage tritt, verbindet sich mit der Frage nach dem Patch-Management. Wer ist dafür verantwortlich und wann ist der beste Zeitpunkt? Kommerzielle NAC-Systeme integrieren meist eine schon vorhandene Patch-Management-Lösung (zum Beispiel Patch Link) und greifen auf deren Daten und Technologien zurück. Durch NAC gewinnt man dabei einen Zeitvorsprung, weil es so möglich ist zu patchen, noch bevor der Rechner Zugang zum Produktivnetz erhält. Herkömmliches Patch-Management findet dagegen erst statt, wenn die zu aktualisierenden Rechner bereits im LAN sind.

Andererseits ist es in gut gemanagten Netzwerken üblich, Patches automatisch auszurollen. So synchronisieren sich einige Patch-Management-Lösungen in Abständen mit dem Active Directory und bringen jeden neuen Laptop in der Domain auf den neuesten Stand.

Abbildung 2: In den Registrierungsoptionen zeigt die Liste neben »registration.auth«, in welche bestehenden Userdatenbanken und Directories sich Packetfence einklinken lässt.

Abbildung 3: Ein Auszug aus der Liste mit Violations, die Packetfence überwacht. Die Spalte »URL« gibt an, auf welches Template des Captive-Portals der Benutzer gelangt, nachdem er einen Regelverstoß auslöst.

Packetfence

Die folgenden Beispiele stammen von der VMware-Version des Packetfence Zero Effort NAC (ZEN). Dabei handelt es sich um ein fertiges VMware-Image, das man zum Beispiel auf einem ESX-Server oder mittels VMware-Player laufen lassen kann. Dadurch entfällt die Installation und es ist sichergestellt, dass alle Komponenten (Webserver, MySQL, Packetfence) Hand in Hand arbeiten. Das VMware-Image selber baut auf Cent OS 5.2 auf.

Sobald das Image läuft, ist eine Entscheidung über den Einsatzmodus nötig. Packetfence kennt drei Betriebsarten: ARP-Manipulation, DHCP/DNS und VLAN-Isolation. Bei der ARP-Manipulation muss sich Packetfence mit einem Netzwerkinterface im selben Subnetz oder VLAN befinden wie die PCs und Laptops, die es sichern soll. Packetfence betreibt in diesem Modus ARP-Poisoning und sendet jedem neuen Host gefälschte ARP-Replies für die IP-Adresse des Default-Gateways. Der getäuschte Rechner wird also Pakete, die er an sein Default-Gateway adressiert, in Wahrheit immer zum Packetfence-Host schicken. Packetfence kann so ein Captive-Portal einblenden.

Im Fall der VLAN-Isolation ist Voraussetzung, dass Packetfence den eingesetzten Switch administrieren kann. Der Switch ist so konfiguriert, dass alle Client-Ports per Default einem MAC-Detection-VLAN zugeordnet sind. Packetfence verwendet hier VID 4 als Voreinstellung. Sollte das schon belegt sein, lässt es sich ändern – der einzige Nachteil ist, dass dann die ohnehin schon spartanische Dokumentation nicht mehr ganz passt. Der Switch informiert Packetfence per SNMP-Traps sobald ein neuer Host auftaucht.

Wie der Switch den neuen Teilnehmer erkennt, hängt vom Hersteller des Switch ab. Manche nutzen den Link-up/down-Event aus. Packetfence ermittelt die MAC-Adresse mit SNMP-Queries. Andere Hersteller erzwingen durch Portsecurity-Einstellungen einen Event. Auf Cisco-Switches unterstützt Packetfence beide Varianten. Manche dieser Switche können zusammen mit dem benötigten Event auch gleich einen MAC Learned Trap an Packetfence schicken.

Nachdem Packetfence die MAC-Adresse des neuen Hosts gelernt hat, ändert es die VID des Client-Ports und bringt damit den Client ins Registration-VLAN. Das VLAN leitet alle HTTP-Requests des neuen Hosts auf die Registration-Webseite um – entweder mit ARP- oder DNS-Manipulationen. Registrieren bedeutet hier, dass sich der Benutzer über diese SSL-verschlüsselte Webseite des Packetfence-Portals anmeldet, wodurch Packetfence die MAC-Adresse des neuen Hosts mit dem Benutzernamen des authentifizierten Benutzers verbinden kann. 802.1x findet hier nicht statt. Danach geht es weiter ins Produktions-VLAN.

Adresserkennung

MAC Address Detection funktioniert in der Praxis recht zuverlässig. So spielt der Einsatz von zum Beispiel Media-Convertern keine Rolle, obwohl dann der Link am Switchport solange unverändert bleibt, wie der Media-Converter mit dem Switchport verbunden ist. Der SNMP MAC Learned Trap wird immer dann gesendet, wenn der Switch eine neue MAC-Adresse an einem Port lernt.

Anders sieht es aus, wenn die eigene Umgebung nicht sauber strukturiert ist und Switchports mit nicht verwalteten Hubs verbunden sind. Zwar lernt Packetfence auch dann alle neuen MAC-Adressen, aber unter Umständen mischen sich am Hub authentifizierte Clients mit neuen Clients und es ist nicht klar in welchem VLAN der Switchport sich nun befinden muss. Als Backup-Strategie kann man in solchen Umgebungen auf eine der anderen Technologien wie zum Beispiel ARP-Spoofing zurückgreifen.

Mehr Features

Packetfence kann noch einiges mehr. Zum Beispiel vergleicht es den Netzwerkverkehr an einem Mirrorport des Switch mit Snort-Patterns und prüft auf Verstöße. Was ein Verstoß sein soll, legt die firmeneigene Acceptable Use Policy (AUP) fest, die der Anwender beim Anmelden akzeptiert. So ist zum Beispiel das Verwenden von P2P-Software als Verstoß interpretierbar und kann dazu führen, dass Packetfence den Benutzer ins Quarantäne-VLAN 3 verfrachtet. Dort trifft der uneinsichtige Anwender wieder auf das Captive-Portal und bekommt eine entsprechende Belehrung.

Auch andere Netzwerk-Anomalitäten, die zum Beispiel auf Viren hinweisen, lassen sich als Verstoß konfigurieren. Genauso der Versuch, Verbindungen zu nicht vorhandenen IP-Subnetzen, so genannten Darknets, aufzubauen. Bei einem positiven Befund startet die Software beispielsweise einen AV-Scanner. Packetfence vermag zum Beispiel auch, neue Hosts mit Nessus auf fehlende oder kritische Patches abklopfen, bevor es sie für das produktive LAN zulässt (Abbildung 3).

Dabei vergeht – wie schon erwähnt – Zeit. Wenn der neue Host die Anforderungen nicht erfüllt, vergeht nochmals Zeit, was wieder zum Problem mit dem ungeduldigen Mitarbeiter führt, der endlich loslegen möchte.

Aufholbedarf

Allerdings fehlen Packetfence im Vergleich mit kommerzieller NAC-Software etliche Features. Kommerzielle Programme haben häufig bessere Möglichkeiten Sicherheitschecks (wie den Nessus-Scan, den auch manche kommerzielle NACs einsetzen) mit professionellen Patch-Management-Systemen zu verbinden.

Auch die Integration von Active-Directory-Benutzer-Accounts gelingt Packetfence nur holprig – via LDAP oder Radius. Überhaupt ist die Benutzerverwaltung nicht ganz schlüssig. Administratoren lassen sich im GUI erzeugen aber nur auf der Kommandozeile listen oder löschen. Gruppen kann man keine anlegen. Kommerzielle NACs greifen hier auf vorhandene AD-Infrastrukturen zurück und arbeiten gruppen- und profilbasiert.

Im Klartext: Kommerzielle NAC-Systeme erkennen einen Benutzer und ordnen ihm ein definiertes Anforderungsprofil zu. So lässt sich bei Usern in Testumgebungen zum Beispiel tolerieren, wenn ihr Patchlevel nicht dem neuesten Stand entspricht. Gleichzeitig kann ein solches System etwa für Benutzer aus dem Personalbüro verlangen, dass ihre Patches immer up to date zu sein haben, damit es sie für die Produktivumgebung zulässt.Kurz: kommerzielle NAC-Systeme haben in fast allen Bereich eine viel höhere Granularität. In großen Umgebungen wird die auch benötigt – schließlich gilt es ja gerade die Anwender nach dem Risiko zu differenzieren, das sie verursachen.

Es ist aber auch ein Nachteil von kommerziellen NACs, dass sich dort der Administrator in einem Berg von Gruppen und Profilen wiederfindet und erst lange im Manual lesen muss, bevor er versteht, welcher Benutzer was benötigt. Wer von einem solchen System zu Packetfence umsteigt, ist überrascht, wie einfach Dinge sein können (Abbildung 2).

Natürlich ist nicht jede kommerzielle Software gleich: Nicht alle verwenden Nessus, einige setzen einen Client voraus, der sich auf dem Hosts befinden muss und beim Einloggen die Security Checks durchführt. Manche Clients sind ständig installiert und laufen mit Windows-Systemaccounts, andere Clients sind Java-Anwendungen. Manche löschen sich nach den Checks selber.

Packetfence und WLANs

Egal was er vorhat, der typische Anwender öffnet in der Regel bald nach dem Booten einen Browser. Vielleicht benötigt er das WWW für die tägliche Arbeit, vielleicht will er sich durch das Ansurfen einer bekannten Seite auch nur überzeugen, dass alles in Ordnung ist. Genau das machen sich so genannte Captive-Portals zunutze, wie man sie von WLAN-Hotspots in Hotels oder von Konferenzen her kennt.

Captive-Portals fangen die Clients von offenen WLAN-Hotspots ein und unterrichten sie im Browser entweder über Nutzungsbedingungen oder Preise und das weitere Prozedere. NAC-Lösungen verwenden die gleiche Technologie, um den Benutzer eines neuen Hosts zu informieren, was er tun muss, um in die Produktivumgebung zu gelangen.

Die Packetfence-Webseite schlägt eine Möglichkeit vor, das Projekt zusammen mit bestimmten Wireless-Accesspoints zu integrieren. Ein Cisco-Accesspoint bietet die Möglichkeit, auf ihm mehrere SSIDs zu hosten, die sich logisch in getrennten VLANs befinden. Ausgehend von diesem Feature macht Packetfence für Wireless-Netzwerke dann Ähnliches wie für Hosts, die in einem Kabelnetz zu einem Switch gepatcht sind.

802.1.x versus NAC

Die beschriebene Authentifizierung an einem Captive-Portal und 802.1x unterscheiden sich wesentlich. Mit 802.1x ist der Netzwerk-Switch dann gleichzeitig auch der Authenticator und ein Angreifer kann nichts machen, solange er nicht wenigstens gültige Credentials hat. Mit 802.1x oder EAP-Protokollen lassen sich deshalb Benutzer sehr zuverlässig und sicher identifizieren. Sicherheitschecks von Workstations sind auf diesem Weg allerdings nicht möglich.

Der Nachteil ist, dass nicht alle kabelgebundenen (also gepatchten) Endsystemen ohne Zusatzsoftware 802.1x unterstützen. Ältere Linux-Versionen benötigen zum Beispiel Xsupplicant. In ernst zu nehmenden kommerziellen WLAN-Installationen spielt 802.1x zum Beispiel in Gestalt von EAP-TLS oder PEAP sowieso immer eine Rolle.

Captive-Portals dagegen lassen die Benutzer so weit ins Netzwerk, dass sie versuchen können es zu hacken, bevor sie identifiziert sind. Als Gegenmaßnahme bieten sich Sicherheitschecks und die Nutzung von Profilen an.

Kommerzielle Hersteller behaupten gerne, dass NAC sehr viel mehr sei als nur 802.1x. Aus diesem Blickwinkel umfasst NAC immer auch den Mehrwert der Sicherheitschecks und des Patchens von Rechnern. Weil sie die Vorteile von 802.1x durchaus nutzen möchten, arbeiten manche kommerzielle NAC-Systeme – und auch Packetfence – mit 802.1x zusammen.

Wer braucht’s?

Wer die zusätzliche Sicherheit durch Security-Checks und das Patch-Management verlangt, für den hat NAC sicher auch in Wireless-Netzwerken eine Daseinsberechtigung. Wer dagegen NAC auf den Standard 802.1x reduziert und alles, was darüber hinausgeht, für überflüssig hält, dem erscheint NAC sicherlich eher vezichtbar.

Folgt man einigen Analysten, dann sollen im Jahr 2011 die Hälfte aller Netzwerke NAC in irgendeiner Form verwenden. Wenn man NAC auf 802.1x reduziert, dann erfüllt sich die Prognose wahrscheinlich allein schon durch das starke Wachstum der WLANs. Der Autor dieses Beitrags fasst die Definition aber wesentlich weiter. Und mit dem umfassenderen NAC-Begriff scheint ihm die Prognose eher zweifelhaft. (jcb)