Access-Control:
Test NAC-Systeme: Mitten im Verkehr

von Dirk Jarzyna

14.02.2008

Um einen erfolgreichen Angriff durchzuführen, benötigt ein Cyber-Krimineller nur eins – Zugriff. NAC-Appliances sorgen dafür, dass der Aggressor diesen nicht bekommt.

Die drei für diese Ausgabe der Network Computing getesteten In-Band-NAC-Produkte von Consentry, Nevis und Vernier starten die Zugriffssteuerung, sobald ein Computer beginnt, mit dem Netzwerk zu kommunizieren. Unterstellt wird, dass alle Hosts Zugriff auf einige Dienste benötigen, beispielsweise DHCP für die IP-Konfiguration, DNS zur Namensauflösung und, in einer Windows-Installation, Zugriff auf einen Domänencontroller. Zugriffs-Controls für weitere Dienste wenden die Systeme auf Grundlage von Bedingungen an, beispielsweise Benutzername, Gruppenzugehörigkeit oder Host-Zustand. Zugriffs-Controls ähneln konventionellen Firewall-Regeln, wo Quell- und Ziel-IP-Adressen, Dienste und Aktionen definiert sind. Ändert sich der Status eines Benutzers oder Computers, ergreift das System Maßnahmen.

Alle Geräte ließen sich sehr einfach installieren – lediglich die Netzwerkkabel waren anzuschließen. Danach offenbarten sich allerdings einige Unterschiede.

ConSentry Networks LANShield Controller CS2400 und InSight

Der CS2400-Lanshield-Controller ist ein passives In-Line-NAC-Gerät, das den Zugriff basierend auf einer Auswahl benutzerdefinierter Kriterien steuert. Als Port-Firewall arbeitet der Controller gut, und mit seiner kräftigen Definitions-Engine hat er das Potenzial für ein leistungsfähiges Access-Control-System. Das Gerät entdeckt aber keine Logoffs – und deshalb ist Consentrys Aussage, dass Lanshield NAC auf Grundlage von ACL-Entscheidungen je Benutzer durchführt, nicht ganz zutreffend.

Das getestete CS2400-Modell besitzt zehn gepaarte GBIC-Ports, die 10, 100 und 1000 GBit/s über Kupfer sowie Single- und Multimode-Glasfaser unterstützen. Ein Out-of-Band-Gigabit-Ethernet-Port steht fürs Management zur Verfügung. Die Appliances lassen sich in einer Aktiv/Aktiv-Konfiguration einrichten und nutzen dann gemeinsame Benutzer-Authentifikationsinformationen. Im Fall eines Hardwarefehlers leiten die Geräte den Verkehr weiter oder blockieren ihn – das ist eine Sache der Geräteeinstellung. Für das Management des Controllers wurde im Test ConSentrys Insight-Command-Center genutzt.

Gepaarte Ports leiten Bridge-Verkehr durch den CS2400; jeder Port ist entweder als host- oder netzwerkorientiert definiert. Diese Unterscheidung ist wichtig, denn der Lanshield-Controller sucht auf den Host-Ports nach Authentifikationsverkehr. Eine Umkehrung der Ports führt zu Access-Control-Problemen. Es ist nicht nötig, Switches und Router neu zu konfigurieren, wie es Out-of-Band-NAC-Produkte ja verlangen. Der Controller entdeckte die existierenden 802.1Q-Trunks.

Rollen und Lücken

Consentrys Rollendefinition ist sehr flexibel. Viele Kriterien, darunter der Authentifikationstyp, Radius-Attribute, Netzwerkinformationen und Uhrzeit, lassen sich kombinieren, um Benutzern Rollen zuzuordnen. Dafür reicht es, Active-Directory-Gruppenzugehörigkeiten mit den Rollen in Insight zu verknüpfen. Der Administrator kann dabei aber auch Netzwerkadressen oder Host-Bedingungen berücksichtigen. Rollen sind zugewiesene Access-Control-Richtlinien, die entscheiden, was ein Benutzer oder Host im Netzwerk tun darf. Die Flexibilität steckt in der Rollenhierarchie des Produkts, worin jede Child-Rolle Controls von ihrem Parent erbt. Regeln verarbeitet das Gerät von der niedrigsten Child-Regel bis hinauf zur All-Users-Rolle. Access-Control-Rollen sind im Wesentlichen Firewall-Regeln, die Netzwerkverkehr erlauben oder ablehnen.

Im Test wurde die Rolle »Unauthenticated« erzeugt, die ausschließlich Zugriff auf die für die Anmeldung in der Active-Directory-Domäne erforderlichen Dienste gewährte. In einer »Authenticated«-Rolle wurden ACLs für authentifizierte Benutzer erzeugt, beispielsweise Zugriff auf DNS und das Internet. Für die »Guest«-Rolle brauchten keine zusätzlichen Zugriffsregeln definiert werden, denn sie war ein Child der »Authenticated«-Rolle. Eine »Sales«-Rolle, die von einer Active-Directory-Sales-Gruppe abgeleitet wurde, erhielt Zugriff auf eine zusätzliche Gruppe von Servern.

Kommt ein Host zum ersten Mal ins Netzwerk, fällt er in die »Unauthenticated«-Rolle. Sobald sich ein Benutzer authentifiziert, entweder durch Kerberos oder durch das Portal, erhält er eine neue Rolle, und die ACLs werden auf den Host angewandt. Authentifiziert sich eine neuer Benutzer vom selben Host aus über das Netzwerk, entdeckt das System die neue Authentifikation und weist die neue Rolle entsprechend zu.

Spezifische Rollen lassen sich auch unter Verwendung mehrerer komplexerer Kriterien, beispielsweise IP-Adressen oder VLAN-Zuordnungen, zuweisen. Hier glänzt Consentry. So ist beispielsweise eine Richtlinie machbar, die einem HR-Benutzer, der sich von einer Arbeitsstation im HR-Netzwerk aus anmeldet, Zugriff auf das ERP-System gewährt. Meldet sich dieser Benutzer aber von einem Host aus an, der sich nicht im HR-VLAN befindet, erhält er keinen Zugriff.

Leider gibt es ein Riesenloch in Consentrys Zugriffssteuerung auf Benutzerbasis: Der Lanshield-Controller entdeckt keine Logoffs. Ein arglistiger Benutzer könnte auf diesem Weg höhere Netzwerkprivilegien erlangen. Ein Beispiel: Ein Anwender in der Domänenadministrator-Rolle meldet sich über ein Active-Directory-Konto bei einer Arbeitsstation an. Er erhält den dieser Rolle entsprechenden Zugriff. Nun meldet sich der Domänenadministrator vom Computer ab und ein anderer Benutzer meldet sich anschließend auf demselben Computer mit einem lokalen Benutzerkonto an. Dieser User erhält plötzlich den Zugriff, der der Domänenadministrator-Rolle zugeordnet war.

Ein böswilliger Benutzer könnte auch einfach das Netzwerkkabel ziehen, sich mit den Anmeldeinformationen im Cache anmelden und denselben Zugriff erlangen.


Hosts, Applikationen und Abnormitäten

Consentry hält Host-Scanning für überbewertet und sagt, dass, was wichtig ist, sei die Aktivität, die ein Host zeigt, sobald er im Netzwerk ist. Statt eigene Host-Assessment-Fähigkeiten zu entwickeln, lizenziert Consentry Check Points Intergrity-Clientless-Security, ICS. Dieses nutzt einen sich selbst wieder entfernenden Agenten, der auf der Maschine des Benutzers läuft und eine Einschätzung zurück liefert. Besteht der Host den Test, benachrichtigt ICS den Lanshield-Controller, und der Host darf den nächsten Schritt im Authentifikationsprozess ausführen.

Assessment-Richtlinien sind im Lanshield-Controller global und gelten für alle Hosts. Für solche, die diese Assessment-Phase umgehen sollen, sind also Ausnahmen zu erzeugen. Das ist ein kleiner Schwachpunkt in Consentrys ansonsten robuster Richtliniendefinition.

Der Hersteller redet viel über Applikationsdurchsetzung (Enforcement) und die Entdeckung von Netzwerkabnormitäten, aber die Realität entspricht dem ganzen Rummel nicht. Lanshield entdeckt 30 Applikationen auf Schicht 7, aber den Zugriff steuert es für eine geringere Anzahl. Beispielsweise sind Applikationen mit konfigurierbaren Aktionen auf HTTP, Cifs und FTP eingeschränkt. Zugriffssteuerungsregeln beschränken sich generell auf Datei- und Benutzernamen. Nicht sonderlich nützlich.

Entdeckte Applikationen sind gleichfalls limitiert. Die IM-Protokolle sind AIM, Yahoo-Messenger und MSN, während als P-to-P-Protokoll das obskure Winny unterstützt wird. Ohne die Möglichkeit, Applikationen hinzuzufügen, bietet dieses Feature wenig Nutzen.

Die Entdeckung von Abnormitäten sah vielversprechend aus. Als dieses Feature lief, entdeckte es allgemein übliche Abnormitäten wie Port-Scans. Allerdings war es nicht möglich, dieses Feature lange genug laufen zu lassen, um es gründlich zu testen.

Insight bietet einige hübsche Übersichtsgrafiken, die auf den Status von Hosts im Netzwerk hindeuten. Aber der Abruf von Details ist bestenfalls entmutigend und schlimmstenfalls wertlos. Viele hübsche Bilder sind zwar nett anzusehen, aber sie helfen nicht beim Aufspüren von Problemen. Beispielsweise Verbindungen, die nicht vollständig hergestellt werden, oder Benutzer, die anscheinend nicht authentifiziert werden. Es gibt keine Logdateien, die das Troubleshooting unterstützen.


Einzig mit »CLI show«-Kommandos ließen sich einige Informationen abrufen. Aber es blieb schwierig, und selbst nach der Konfiguration von Debug-Output via Syslog waren relevante Ereignisse nicht verfügbar.

Administratoren benötigen für das Troubleshooting Zugriff auf Logdateien. Es gibt kaum etwas Schlimmeres als eine Funktion, die nicht funktioniert, und ein Gerät, das nicht darauf hinweist, warum sie nicht funktioniert. Nirgendwo ließ sich auch nur ein einziges Ereignis finden, das auf ein Problem hätte hinweisen können.


Vernier Networks EdgeWall 8800 und Control-Server

Diese Kombination nutzt wie andere In-Band-Produkte einen passiven In-Band-NAC-Enforcement-Punkt. Der Controller schätzt ein und setzt die Richtlinien durch. Das Assessment eines Hosts erfolgt über den gesamten Verbindungszeitraum. Die Edgewall-Appliance hat allerdings zwei riesige Probleme: Wie beim Lanshield-Controller von Consentry war es möglich, die Rechte eines angemeldeten Benutzers zu erben. Dazu reichte es, sich ab- und anschließend mit lokalen Anmeldeinformationen erneut anzumelden. Das zweite Problem war, dass Edgewall selbst bei einer Anmeldung beim Active-Directory den neuen Benutzer nicht erkannte. Vernier-Techniker haben inzwischen herausgefunden, dass es sich dabei um einen Konfigurationsfehler handelte. Der wurde bei einem erneuten Test korrigiert, und das System funktionierte dann auch richtig. Schuld – zumindest teilweise – hat die schlecht entworfene Managementplattform, die Schlüssel-Richtlinienelemente mehrere Schichten tief versteckt.

Die Administrationsschnittstelle war verwirrend. Häufig funktionierten neue Richtlinien nicht sofort, nachdem sie definiert waren. Gelegentlich waren Änderungen mehrere Male zuzuweisen, bevor das System sie endlich akzeptierte. Vernier gab zu, die Richtlinienentwicklung in dem Bemühen, sie kraftvoll zu machen, langweilig und wenig intuitiv gestaltet zu haben.

Ein weiterer Schwachpunkt: Der Control-Server und die Edgewall müssen permanent miteinander kommunizieren. Andere NAC-Produkte, beispielsweise Consentry, pflegen die jüngste konfigurierte Richtlinie. Vernier trifft aber alle Zugriffsentscheidungen auf dem Control-Server. Administratoren können einen sekundären Controller installieren, der beim Ausfall des primären die Arbeit übernimmt.

Natürlich gibt es auch Positives zu berichten. Die Edgewall besitzt einige einmalige Features, welche die Netzwerkintegration unterstützen. Das getestete 8800-System enthält 24 SFP-Ports, die über vier Kartenslots verteilt sind. Während bei den Produkten von Consentry und Nevis Networks Eingangs- und Ausgangs-Ports eins zu eins gepaart sind, ist die Port-Zuordnung der Edgewall flexibel. Beispielsweise lassen sich mehrere zu den Hosts gerichtete Ports mit einem einzelnen Uplink-Port verknüpfen. Bridge-Gruppen und VLAN-Zuordnungen bestimmen, welche Frames die Edgewall passieren. Administratoren können Bridge-Regeln erzeugen, die spezifischen Verkehr an der Sicherheitsverarbeitung der Edgewall vorbei leiten.

Die Wurstfabrik

Wurst ist eines dieser Nahrungsmittel, die schmutzig herzustellen sind, aber am Ende befriedigen. Die Managementschnittstelle von Vernier ist genauso. Benutzer bewegen sich, so wie die Bedingungen sich ändern, von Richtlinie zu Richtlinie – vom Booten zum Assessment und zum Login. Verniers Richtlinien werden gebildet aus einem Identitätsprofil, einem Verbindungsprofil, einem Integritätsprofil und den Zugriffsrichtlinien. Das Identitätsprofil kombiniert Host- und Benutzerdaten, das Verbindungsprofil berücksichtigt den Standort der Edgewall. Die Zugriffsrichtlinien entscheiden, wohin sich ein Host im Netzwerk bewegen darf.

Der Hersteller hat die Richtlinienliste abstrahiert, indem er Features innerhalb von Features kombiniert hat, aber einige Teile hat er nicht abstrahiert – und das ist ein Problem. Administratoren haben eine Menge Knöpfe zu drücken, selbst um nur eine wenig strikte Richtlinie zuzuweisen. Das System definiert 160 unterschiedliche Statuskombinationen, und jede verlangt ihre eigene Richtlinie. Im Test sollte Gästen Zugriff gewährt werden, aber nur dann, wenn sie einem Richtlinien-Scan zustimmen. Bei Ablehnung war der Zugriff zu verweigern. Dies erforderte vier unterschiedliche Richtlinieneinträge: Einen für unbekannten Scan-Status (bei erstmaliger Verbindung mit dem Netzwerk), einen für gerade laufenden Scan, einen für willfährige und einen für nicht willfährige Hosts. Ist das detailliert? Ja, sicher. Ist das unhandlich? Selbstverständlich. Eine bessere Rollengruppierung könnte sich wiederholende Aufgaben verringern.


Assessment, wie es sich der User wünscht

Verniers Host-Scanning nutzt auf dem Netzwerk oder auf Agenten basierende Scans, um einen Host einzuschätzen. Scans laufen beim Login und anschließend periodisch. Ändern sich die Bedingungen (oder der Zustand) eines Hosts, wendet das System die entsprechende Richtlinie an. Neue Richtlinien weist das System zu, sobald sie eingestellt sind, aber ein neues Assessment der Hosts erfolgt nicht unmittelbar.

Die Edgewall nutzt die Nessus-Scanning-Engine für Netzwerk-Richtlinien-Scans oder einen sich selbst wieder entfernenden Agenten. Die Richtlinien-Scans konzentrieren sich auf die Host-Konfiguration, während Schwachstellen-(Vulnerabillity-)Scans unbekannte Schwachstellen in den Hosts suchen. Die beiden Scans getrennt zu halten, ist sinnvoll, denn es kann Zeiten geben, zu denen Richtlinien-Scans nicht ausführbar sind, Schwachstellen-Scans aber laufen können.

Sobald sich der Host im Netzwerk befindet, überwacht die Edgewall ihn auf feindliche Aktivitäten. Dazu nutzt das System Netzwerk-Intrusion-Prevention, Protokoll- und Netzwerk-Abnormitätenentdeckung. Die IDS-Funktionalität ist ein Standard-Signatur-Matching. Protokollabnormitäten sind typischerweise ungewöhnlich formatierter oder arglistiger Verkehr. Die Netzwerk-Abnormitätenentdeckung sucht nach solchen Verkehrsmustern, beispielsweise hohen Verbindungsraten und Flooding – übliche Charakteristiken, die auf Scanning, Denial-of-Service-Attacken oder Wurmaktivitäten hindeuten.

Logging und Troubleshooting

Schon Consentrys Log-Grafiken konnten nicht überzeugen, aber Verniers sind sogar noch weniger nützlich. Client-Daten sind nicht lange genug sichtbar. Und jedes Mal, wenn die Sitzungsseite des Clients aktualisiert wird, zeigt das System die aktuellsten Statistiken, und die früheren verschwinden in der Managementstation.

Als sie funktionierten, erwiesen sich zwei Werkzeuge als wertvoll: Das Simulate-User-Rights-Werkzeug zeigt die Rechte, die ein Benutzer auf Grundlage verschiedener Bedingungen, beispielsweise Benutzername, MAC-Adresse und Richtlinien-Assessment, erhalten würde. Das Trace-Transaction-Werkzeug prüft, ob Benutzer sich korrekt authentifizieren, und zeigt die Daten, die der Authentifikations-Server zurückliefert. Das Simulate-User-Rights-Tool erwartet leider, dass sich der Benutzer authentifiziert. Mit dem Fall, dass ein Benutzer dies nicht tut, weiß das Tool offenbar nichts anzufangen.

Die Komplexität der Richtlinienerzeugung auf Verniers System macht Simulationswerkzeuge zu einer Notwendigkeit.


Nevis Networks LANenforcer 2024 und LANsight One

Der LAN-Enforcer war in diesem Test trotz einiger noch zu beseitigenden Schmutzränder das polierteste NAC-Produkt. Die Monitoring- und Troubleshooting-Werkzeuge auf der LAN-Sight-One-Management-Plattform waren mit großem Abstand die vollständigsten und nützlichsten. Und Nevis’ Endpoint-Assessment-Agent, Clientless-Endpoint-Integrity (CEI), offeriert so einmalige Features wie Login-Tracking und Messaging.

CEI verlangt allerdings Scripting für die automatische Installation und Ausführung beim Systemstart. Auch sind die Richtlinienoptionen nicht so flexibel wie die in Verniers Produkt.

Assessment-Richtlinien sind nicht an Benutzer oder Gruppen gebunden.

Nevis verlangt vom Administrator bei der Installation von LAN-Enforcer und LANs-Sight ein paar interessante Entscheidungen. Er kann die Appliance in-Band oder out-of-Band verwalten. In-Band bedeutet, dass sich der Managementverkehr zwischen LAN-Sight und LAN-Enforcer mit Log- und Netzwerkverkehr vermischt. Beim Out-of-Band-Management sind Management-, Log- und Netzwerkverkehr voneinander getrennt – und das ist sinnvoll. Kaufen Organisationen LAN-Sight-Appliances als Paar und installieren sie in einer Aktiv/Passiv-Konfiguration, bleibt der Systemzustand aktuell. Im Fehlerfall übernimmt das passive System die Aufgaben.

Die Richtlinienverarbeitung führt die Benutzer bei Statusänderungen durch mehrere Richtlinien. LAN-Sight kommt mit einigen definierten Richtlinienvorlagen für allgemeine Aktivitäten, darunter das Erlauben der Authentifizierung für unbekannte Hosts und das Umleiten zu einer Web-Portal-Seite. Das Produkt entdeckt leider nur eine beschränkte Anzahl Applikationen und reagiert darauf. Wünschenswert wären eine breitere Applikationsunterstützung und die Fähigkeit, erlaubte und abgelehnte Funktionen sowie Methoden innerhalb von Applikationen zu definieren. Benutzergruppen sind mit Gruppennamen in Active-Directory verknüpfbar.


Richtlinien nutzen ein mit LAN-Sight vergleichbares, hierarchisches Modell und sind wiederverwendbar. Der Hersteller versucht, die Richtlinienfenster aufzuräumen, indem er Inbound- und Outbound-Zugriffs-Controls präsentiert, die für eine gegebene Richtlinie definiert wurden. Unter dem Gesichtspunkt der Wiederverwendung von Richtlinien ist das effizient, kann aber ungewünschte Konsequenzen nach sich ziehen.

Wie die anderen getesteten In-Line-NAC-Produkte entdeckt auch LAN-Enforcer passiv keine Benutzer-Logoffs. Nevis löst dieses Problem mit einem Host-Agenten, der einen Heartbeat pflegt. Verschwindet dieser Heartbeat, geht das System davon aus, dass sich der mit dem betreffenden Host verknüpfte Benutzer abgemeldet hat. Auf diese Art erkennt LAN-Enforcer Logoffs schnell und schließt offene Ports prompt.

Die Host-Assessments reichen von simplen Prüfungen auf Antivirus-Software bis zu tiefgehenden Konfigurationsanalysen, die Arbeit duplizieren, die andere Managementwerkzeuge bereits getan haben. Nevis’ CEI-Agent, der das Host-Assessment durchführt, ist eine Active-X-Komponente, die dynamisch über den Internet-Explorer oder via MSI zu installieren ist. CEI muss durch einen Browser oder ein Anmeldescript gestartet werden. Darin unterscheidet sich dieser Agent von den meisten anderen persistenten Agenten. Für den Administrator bedeutet dieser Umstand natürlich zusätzliche Arbeit. Hier sollte Nevis ein wenig aufräumen.

CEI-Richtlinien sind global für LAN-Sight, und es gibt keinen Weg, verschiedene Anforderungen für unterschiedliche Hosts zu definieren. Das CEI-Scanning pro Schnittstelle ein- oder auszuschalten, ist schon alles, was ein Administrator tun kann. Die Antivirus- und Anti-Spyware-Inspektionen beschränken sich auf Prüfungen der jüngsten Updates und System-Scans.

Sobald ein Host im Netzwerk ist, muss er überwacht werden. Hier kommt Nevis’ Threat-Control ins Spiel. Das Tool nutzt zur Entdeckung verdächtiger Aktivitäten verschiedene Techniken: Netzwerk- und Protokoll-Abnormitätenentdeckung sowie Signaturen, die schlechtes Verhalten erkennen, dass auf bekannte Malware, Adware und anderen potenziell unerwünschten Verkehr schließen lässt. Administratoren können die Abnormitäten-Einstellungen tunen und Signaturen ein- oder ausschalten.

Threat-Control arbeitet mit einem einfachen Score-Mechanismus: »Gute« Aktionen, beispielsweise eine abgeschlossene TCP-Verbindung, verringern den Score, während »schlechte« Aktionen, beispielsweise Netzwerk-Scanning, den Score erhöhen. Überschreitet der Score eines Hosts einen Schwellenwert, wird der Hosts durch CEI-Messaging benachrichtigt, in Quarantäne gestellt oder blockiert.

Monitoring und Berichterstellung sind wichtige Features eines jeden Netzwerkgeräts. Bei Sicherheitssystemen, die damit beauftragt sind, Verkehr zu blockieren oder zu erlauben, ist die Fähigkeit, schnell an die Details und den Status eines spezifischen Hosts oder Benutzers zu gelangen, enorm wichtig fürs Troubleshooting. Die Monitoring-Features von LAN-Sight sind erstklassig. Sie liefern schnell informative und detaillierte Ansichten. Zwar protokollieren alle NAC-Appliances Ereignisse, aber an Nevis’ Ereignisdaten kommt der Administrator am einfachsten ran, und im Test erwiesen sie sich als die nützlichsten.

dj@networkcomputing.de