Basiswissen: Die Technik hinter Network Access Control

Vom Prinzip her ist NAC ganz einfach: Alles, was sich in irgendeiner Form mit dem Netzwerk verbinden will, sollen nur dann Zutritt erhalten, wenn bestimmte Voraussetzungen erfüllt sind. Welche das sind, legt der Administrator bei der Einführung der Lösung fest. In einigen Firmen reicht es, wenn sich der Anschluss Suchende ausweisen kann, also eine gültige digitale Identität besitzt. Andere Firmen gehen viel weiter und fragen mit Hilfe von Software auf dem Endgerät dessen Staus ab: sind die Anti-Virus Signaturen aktuell, ist eine Personal Firewall installiert und aktiv oder hat der Benutzer vielleicht unerlaubte Software an Bord? Wer A sagt muss auch B sagen und die Situation bereinigen oder andere Schritte ergreifen, wenn das Endgerät nicht den Vorgaben entspricht.

In technischen Worten formuliert, sind die generell mit NAC in Verbindung gebrachten Aufgaben die folgenden:

• Eine eindeutige Erkennung von Zugangsversuchen und die Identifizierung der Geräte

• Der Vergleich mit und das Umsetzen von Sicherheitsrichtlinien

• Eine Isolierung und im besten Fall die automatische Korrektur bei fest gestellten Richtlinienverletzungen

• Die Erstellung und Verwaltung der Richtlinien sowie die Auswertung der Ereignisse und gesammelten Daten

Schon die erste Anforderung stellt ein NAC vor maßgebliche Aufgaben. Es fängt schon damit an, den Verbindungsversuch zuverlässig zu erkennen und das Endgerät im Anschluss zu identifizieren. Wenn das Endgerät nichts Böses im Sinn hat, funktionieren die üblichen Verfahren, mit denen man im Netzwerk neue Geräte identifizieren kann. Das kann die Erkennung einer neuen MAC- oder IP-Adresse sein, indem man den ARP-Datenverkehr ausliest. Bei VPN-Geräten erkennt man am Tunnelaufbau die Verbindungsanfrage, in der Regel funktioniert auch das Warten auf eine DHCP-Anfrage.

Schwieriger wird es, wenn man den Goodwill des Endgerätes nicht voraussetzen kann. Ist ein Computer mit Schadsoftware infiziert oder versucht ein Angreifer, durch den direkten Anschluss an das LAN eine Schwachstelle zu finden, wird er alles versuchen, um die Erkennung des Verbindungsversuchs zu unterdrücken. Ein NAC ist dann in einer schwierigen Lage: Um zu beurteilen, ob ein Endgerät Zugang erhält, muss es den Probanden in das Netz hineinlassen, zumindest ein kleines Stückchen. Sobald aber eine physikalische Verbindung zu einem Netzwerksegment besteht, hat der Angreifer Handlungsspielraum. So ist es nicht verwunderlich, dass Sicherheitsanalysten zahlreiche Angriffsmöglichkeiten beschreiben.

Eine Methode, den Verbindungsversuchs zu erkennen, ist ein DHCP-Proxy, der Anfragen aus dem Netz abfängt. Mithilfe der MAC-Adresse kontaktiert er das Endgerät und fragt zusammen mit dem NAC-Server die Richtlinien und deren Einhaltung ab. Das funktioniert gut – allerdings nur im Idealfall. Denn zum einen gibt es zahlreiche Geräte wie Netzwerkdrucker oder Server, die kein DHCP benutzen. Zum anderen kann ein Angreifer einfach durch eine statische IP-Adresse Zugang zum Netzsegment erhalten. Andere Geräte im gleichen Subnetz sind dann im Prinzip für den Angreifer erreichbar.

Bedenklich ist es auch, wenn das NAC-System den Neuzugang in einen Quarantänebereich verschiebt, denn dann hat er die Möglichkeit, andere Endgeräte im gleichen Segment anzugreifen. Diese haben vermutlich irgendwelche Sicherheitsprobleme, sonst wären sie ja nicht in Quarantäne gekommen, sodass die Chancen auf eine erfolgreiche Attacke gut stehen.

Authenticated DHCP

Im Prinzip die gleichen Probleme gibt es bei der Verwendung von Authenticated DHCP oder eines DHCP-basierten NAC direkt im Switch. Immer sind die Systeme auf DHCP-Anfragen angewiesen, und die Isolierung erfolgt nur auf dem OSI-Layer 3. Computer haben also die Möglichkeit, Verbindung zum Netzwerksegment aufzunehmen, egal ob sie zugelassen oder in Quarantäne geschickt werden. Das ist besonders bedeutsam, weil keine Geräte erkannt werden, die sich hinter NAT oder einer ähnlichen Technologie verstecken, mit der die IP-Adresse eines Systems verschleiert wird. Virtualisierungslösungen wie VMware Workstation oder Virtualbox fallen in der Standardkonfiguration in diese Kategorie: Wenn der Computer mehrere VMs hostet, kann ein NAC, dass auf Layer 3 arbeitet, sie nicht erkennen.

Bei einem Authenticated DHCP wird die Anmeldung durch ein Web-Portal vorgenommen, das in der Regel durch ein VLAN vom Rest des Netzwerks getrennt ist und trotzdem vom unindentifizierten Endgerät erreicht werden kann. Ein Vorteil ist die einfache Umsetzung und die Möglichkeit, auch Besucher und Gäste bedienen zu können. Einige Hersteller schlagen vor, die Zulassung eines Gasts mit den Daten des Mitarbeiters zu koppeln, der den Besucher in Empfang nimmt. So ist später leichter nachvollziehbar, wer für den Gast zuständig war, und die IT-Abteilung bleibt von der täglichen Vergabe von Gästepässen verschont.

Der Vorteil besteht darin, dass Unternehmen diese Lösung einfach und relativ schnell umsetzen können. Ohnehin empfehlen die meisten NAC-Berater, darauf zu achten, dass mehrere Identifizierungs- und Authentisierungsverfahren gleichzeitig unterstützt werden. Ein Netzwerkdrucker muss nun mal über die MAC-Adresse im System registriert werden, der Druckerhersteller lässt keinen anderen Weg zu. Doch für Computer oder Smartphones sollte eine andere Methode möglich sein.

Lauscher im Netz

Wenn sich ein Endgerät nicht freiwillig identifizieren lässt, gibt es auch andere Methoden. Sogenannte Broadcast Listener lauschen, wie der Name schon sagt, nach Datenpaketen von bekannten und neuen Geräten. Ein Endgerät, das versucht, eine Verbindung zu Ressourcen im Netz aufzubauen, muss das über ausgesendete Pakete tun; die Entdeckung ist also garantiert.

Allerdings hat auch diese Methode Nachteile. Einer ist, dass pro Subnetz je ein Gerät mit der entsprechenden Software ausgestattet sein muss. Genaue Kenntnis des eigenen Netzwerks ist also Pflicht. Zudem sind solche Listener rein passiv und müssen für die Quarantäne mit Switchen zusammenarbeiten, Kompatibilität sollte also gewährleistet sein. Endgeräte hinter einer NAT-Firewall bleiben dem Listener ebenfalls verborgen.

Noch raffinierter arbeiten Listener, die die Anmeldedaten zwischen Endgerät und Verzeichnisdienst im Netzwerk abfangen, dekodieren und auf dieser Basis NAC umsetzen. Bei Microsoft-Netzwerken mit Active Directory ist das in der Regel das Kerberos-Protokoll. Kerberos Snooping liest den verschlüsselten Datenverkehr mit und kann erkennen, ob sich ein System erfolgreich an der Domäne anmelden konnte. Kerberos liefert den Benutzer- und den Hostnamen als Identifizierungsmerkmal. Der große Vorteil einer solchen Lösung besteht darin, dass die einzige Voraussetzung die Verwendung des Kerberos-Protokolls ist. Das Erkennen und Authentifizieren ist hierbei vollkommen von den Switchen losgelöst und kann in vielen Fällen direkt ohne größere Eingriffe implementiert werden.

Perfekte Lösung: 802.1x

Der wichtigste Mechanismus zur Authentisierung dürfte das klassische 802.1x (RADIUS) sein. Es setzt einen Supplikanten (Client) auf dem Endgerät sowie einen 802.1x Server im Netzwerk voraus. Auch der Switch, an dessen Port das Endgerät angeschlossen ist, muss 802.1x unterstützen. Das können nur Managed-Switche der oberen Preisklassen – ein Problem für viele Firmen, die am Rand des Netzwerks simple Unmanaged-Switche mit hoher Port-Kapazität einsetzen. Dafür können damit sowohl Geräte als auch Benutzer identifiziert werden. Allerdings sind auch für viele Endgeräte keine 802.1x Supplikanten verfügbar, sodass diese Art der Erkennung und Authentisierung nur einen Teil des Netzwerks abdeckt. Gäste lassen sich damit auch nur mit viel Aufwand erfassen.

Ein einfacherer Weg, RADIUS für die Authentisierung zu nutzen, besteht darin, auf Zertifikate und Anmeldedaten zu verzichten und lediglich die MAC-Adresse abzuprüfen. So können Endsysteme ohne Supplikant gegen einen RADIUS-Server abgeglichen werden. Weil sich eine MAC-Adresse aber selbst mit Windows-Bordmitteln innerhalb von 30 Sekunden fälschen lässt, darf diese Methode nur in solchen Bereichen zum Einsatz kommen, in denen das Angriffsrisiko sehr gering ist.

Ebenfalls möglich ist das Erkennen und Authentisieren über SNMP. Die Open-Source-NAC-Lösung Packetfence nutzt dieses Verfahren beispielsweise zur Anmeldung. Dazu müssen aber die Switche im Netzwerk mitspielen und die notwendigen Informationen per SNMP liefern können. Weil der Inhalt dieser Nachrichten nicht komplett genormt ist, mag das zu Schwierigkeiten führen. Quarantäne und Isolierung funktionieren bei korrekter Umsetzung natürlich sehr gut, schließlich hat der Switch volle Kontrolle über den physikalischen Port-Zustand und die VLAN-Verwaltung.

Agenten und andere Helfer

Welche Optionen es für die Erkennung und Authentisierung gibt, ist nun klar, doch NAC soll, zumindest in der ursprünglichen Idee, erheblich mehr leisten. Ein Endgerät muss auch den Richtlinien des Unternehmens entsprechen, um Zugang zu erhalten. Die richtige Benutzername-Passwort-Kombination allein reicht nicht. Vielmehr sind weitere Informationen notwendig; ein beliebtes Beispiel ist die Version der Antivirensignatur und das installierte Service-Pack des Betriebssystems. Generell gibt es zwei Wege, um an die Daten zu kommen: Entweder mit einem Agenten auf dem Endgerät oder komplett ohne zusätzliche Software.

Fast alle NAC-Anbieter erlauben beide Varianten. Schließlich sind die Agenten meist nur für Windows-Betriebssysteme verfügbar. Alles, was nicht von Microsoft kommt, wie Netzwerkdrucker oder VoIP-Telefone, wäre sonst ausgeschlossen. Vermutlich wird sich die Frage nach dem Agenten über kurz oder lang ohnehin erledigen. Seit Windows XP SP3 ist zumindest ein rudimentärer NAP-Agent im Betriebssystem eingebaut, Windows Vista, Windows 7 und Windows Server 2008 verfügen über vollwertige NAP-Agents. Nachdem Microsoft die Spezifikationen zumindest so weit freigegeben hat, das jeder über ein API auf die Daten zuzugreifen kann, werden die meisten Anbieter kaum daran vorbeikommen, die Daten abzugreifen.

Alternativ haben viele Hersteller eigene Lösungen im Angebot, allen voran Cisco mit dem Cisco Trust Agent (CTA). Der wurde in der Vergangenheit allerdings schon mehrfach ausgetrickst, Hacker und Entwickler liefern sich ein munteres Wettrüsten. Lösungen mit einem fest im Betriebssystem verankerten Agenten bieten mittlerweile auch mehrere Antivirenhersteller wie Symantec oder Sophos. Nachdem sich die AV-Engine ohnehin tief im Kernel verankert und meist noch eine Firewall enthält, lag die Idee nahe, auch gleich einen NAC-Client zu integrieren. Daten über den AV- und Firewall-Zustand stehen diesen Clients ohnehin zur Verfügung.

Lösungen mit temporären Agenten

Was in der Regel als "agentenlos" bezeichnet wird, sind meistens temporäre Lösungen. Sie werden als Applet im Browser geladen. Der Benutzer muss dann dem Scan zustimmen – eine gute Wahl für Gast- und Besucherzugänge, daher ist diese Option für NAC-Interessenten mit häufigem Kunden- und Dienstleisterverkehr wichtig. Eine andere Lösung sind Agents, die als "Wegwerfsoftware" implementiert wurden. Sie leben nur im RAM und sind beim nächsten Neustart wieder verschwunden. Zahlreiche NAC-Anbieter zapfen auch die diversen Management-Interfaces wie WMI (Windows Management Instrumentation) an, um deren Daten zu nutzen.

Ganz ohne Agent funktioniert es nur auf eine Art: über einen Vulnerability-Scanner im Netzwerksegment. Dieser nutzt, angefangen bei den Ports bis zu verschickten Datenpaketen, alles, was ihm Hinweise auf mögliche Schwachstellen geben kann. Das dauert natürlich seine Zeit und bedeutet, dass ein Zero-Day Exploit, von dem der Scanner noch nichts weiß, Chancen hat, der Entdeckung zu entgehen.

Schon aufgrund der verschiedenen Endgeräte kann es hier nicht „die“ richtige Lösung geben. Je nach Ziel des NAC-Systems muss der Kunde entscheiden, welche Geräte mit welchen Daten erfasst werden können. Einerseits lässt sich ein Agent nicht auf einem Drucker oder einem IP-Telefon installieren. Andererseits hat ein Netzwerkscanner Schwierigkeiten, die aktuelle Version des Virenscanners zu finden. Eine Rolle spielt auch die verfügbare Bandbreite und Zeit: Ein Scan kann je nach Detailtiefe viele Tage dauern. In der Praxis wird normalerweise der Weg gewählt, wenige, aber wichtige Dinge zu prüfen.

Ein weiteres Problem stellt die Last eines solchen Vulnerability-Scans auf dem Scan-Server selbst dar. Es ist unrealistisch, Tausende von Endsystemen von einem einzelnen Server regelmäßig prüfen zu lassen. Ein flächendeckender Einsatz in größeren Umgebungen scheitert deshalb meist aus finanziellen Gründen. Dafür entfällt die Installation einer Software oder eines Applets, was Besucher zu schätzen wissen. Der größte Vorteil eines Vulnerability-Scanners liegt in der Prüfung von Endsystemen, die keinen Agenten aufnehmen können.

Handeln und umsetzen

Ist das Endgerät mit dem Netzwerk verbunden, die Identität des Benutzers geklärt und der Status des Systems bekannt, kommt der entscheidende Punkt: Was tun, wenn die definierten Richtlinien nicht eingehalten werden? Das "C" in NAC steht für Kontrolle, die Lösung muss handeln können, um wirklichen Schutz zu bieten. Wie und wo das sogenannte Enforcement stattfindet, ergibt sich zum Teil schon aus der Architektur der vorangegangenen Schritte.

Wenn es im NAC-Konzept nur um das Blockieren von Risiken geht, genügt eine relativ grobe Lösung. Im einfachsten Fall verweigert der DHCP-Server eine IP-Adresse. Oder ein 802.1x-fähiger Switch kappt dem Endgerät den Zugang am Port. Das klappt auch mit SNMP-Switches problemlos. Doch einen Benutzer auszusperren, nur weil sein Service-Pack nicht up to date ist, wird den Administrator sehr schnell sehr unbeliebt machen. Wegsperren darf nur eine vorübergehende Maßnahme sein. Abhilfe statt Abhalten heißt die Losung.

Je reichhaltiger die abgefragten Daten über das Endgerät sind, desto mehr Baustellen können sich auftun, die der Abhilfe bedürfen. Das Isolieren und Parken in einem Quarantänesegment sorgt dafür, dass der PC zunächst in einem kontrollierten Bereich auf weitere Aktionen wartet. Ein Weg kann jetzt sein, den Benutzer per Web-Portal durch die notwendigen Schritte zu führen, um die Probleme zu lösen. Das setzt zumindest rudimentäre Computerkenntnisse voraus. Besser wäre es, die Abhilfe automatisch zu leisten, doch das erfordert einen Agenten mit umfassenden Eingriffsrechten im Betriebssystem. Zudem kann der Agent kompromittiert werden, wie bei der Technologie-Demo von Ciscos CTA. Dann ist die Sicherheit durch das Enforcement ebenfalls dahin. Den Support anzurufen und mit ihm per Fernsteuerung alle bemängelten Punkte abzuhaken dürfte die bequemste Variante für den Benutzer sein. Doch den administrativen Mehraufwand werden nur die wenigsten Unternehmen bewältigen können und wollen.

Ausgewogene Mischung für die Remediation

Nach mehr als sechs Jahren NAC-Erfahrung raten die meisten Hersteller zu einer Mischung der Vorgehensweisen. Das Antiviren-UUpdate schafft die AV-Engine von ganz allein, wenn sie nur einen Netzwerkzugang bekommt. Auch ein Service-Pack lässt sich automatisch installieren, wenn der Benutzer ein bisschen Zeit mitbringt. Bei Verdacht auf Viren und Trojaner sollte sich der Support um den Computer kümmern, der Admin ist mit einem radikalen Block hier am besten bedient. Allerdings sollte man darauf achten, dass ein Angreifer daraus keine lokale Denial-of-Service-Attacke macht, indem er alle Ports der Reihe nach ausprobiert.

Bleibt nur noch die Frage zu klären, wer technisch für den Remediation-Prozess zuständig ist. Wer intelligente Switche im Netzwerk einsetzt, kann die Arbeit direkt im Switch erledigen lassen, kontrolliert durch einen zentralen NAC-Server. Wer Microsoft NAP und Cisco NAC koppelt, teilt den Vorgang in zwei Teile: Cisco kümmert sich um Zugang und Authentifizierung, Microsoft übernimmt den Status-Check des Computers.

Mittlerweile bieten viele Firmen fertige Appliances an, die entweder im Datenpfad liegen oder extern nur die Informationen der Agents und Switche verarbeiten. Wichtig ist, dass die Lösung, ob Appliance-, Server- oder Switch-basiert, mit den zahlreichen VLAN-Konfigurationsänderungen klarkommt und einen einfachen Zugang zu den gesammelten Informationen für Compliance-Zwecke bietet.

Schnuppertest mit NAC

Wer Network Access Control mit allen Features umsetzen will, muss ein großes Budget haben. Planung und Implementation kosten viel Geld und nehmen sowohl interne als auch externe Ressourcen in Anspruch. Zudem muss die Software selbst bezahlt werden, die Angebote der großen Hersteller wie Enterasys, Cisco oder Symantec sind auf die Belange größerer Unternehmen und deren Finanzkraft zugeschnitten. Weit günstiger, zumindest was das NAC-System selbst angeht, lässt sich die Sicherheitslösung mit einem Open-Source-Angebot angehen. Das mag in einigen Firmen nicht der offiziellen Policy entsprechen, aber für den Test und erste Erfahrungen mit NAC genügen die kostenlosen Angebote auf alle Fälle.

Stillsecure bietet eine abgespeckte Version seiner NAC-Software Safe Access mit dem Namen SALite an. Die Software basiert zwar nicht auf Open Source, ist aber kostenlos. Sie wird als VMware-Image verteilt und setzt einen sofort nutzbaren NAC-Server auf. Die Erkennung der Endgeräte erfolgt wahlweise über einen Agenten, DHCP-Erkennung mit Browser oder ganz ohne Software über einen RPC-Dienst auf dem (Windows-) Endgerät. Die Anzahl der Geräte ist auf 250 beschränkt, eine kleine Firma sollte damit hinkommen. Stillsecure hat dem Linux-Server eine ansprechende GUI verpasst, sodass Anwender nichts vom Betriebssystem mitbekommen. Ergebnisse und Einstellungsdialoge werden sehr übersichtlich und ansprechend präsentiert.

NAC mit Open Source

Packetfence ist ein echtes Open-Source-Projekt und nun schon seit geraumer Zeit aktiv. Die umfassende Lösung bietet eine komplette NAC-Umgebung samt Erkennung von Endgeräten, Isolierung mit Quarantäne und Remediation. Obwohl Packetfence herstellerunabhängig ist, lässt es sich mit Switchen kombinieren. Eine Liste der aktuell unterstützten Modelle ist hier zu finden. Auch Packetfence kann als VMware-Image bezogen werden, der vorkonfiguriertes Server heißt dann "Zero Effort NAC", kurz ZEN. Die Lösung beherrscht zahlreiche Methoden, um Endgeräte zu erkennen, und isoliert sie per VLAN-Segmentierung. Basis sind 802.1x für die Authentifizierung und SNMP-Traps der Switch-Ports, um einen Anschlussversuch zu erkennen.

Darüber hinaus gibt es Captive-Portals, mit denen man die Benutzer zur Abgabe einer Nutzungserklärung zwingen kann. Diese lassen sich sogar – wichtig für Gäste und Dienstleister – zeitlich einschränken. Ebenfalls eingebunden werden Snort-Sensoren, um innerhalb der Segmente nach verdächtigen Aktivitäten zu fahnden. Proaktive Vulnerability-Scans leistet Nessus. Laut den Entwicklern können dabei auch drahtlose Netzwerke eingebunden werden.

Und wer nur auf der Suche nach einem umfangreichen 802.1x-Supplikant ist, wird bei der OpenSEA Alliance fündig. In dem Konsortium sind Branchengrößen wie TippingPoint und Symantec vertreten. Ihr kostenloser Supplikant Open1X, die Client-Komponente der 802.1x-Authentisierung, ist für Linux- und Windows-Betriebssysteme erhältlich. (ala)