N A Control Best Practice Guide - all-about-security.de · (PORT) VLAN ZUWEISUNG ... (oder auch Gruppen) zu übernehmen und als Basis für das NAC Konzept zu verwenden. Ein Verzeichnis-dienst

1 von 26 • NAC: Best Practice Guide

Network Access Control

Best Practice Guide


Einleitung Der „Best Practice Guide“ ist ein kleiner Leitfaden zur Planung und Implementierung von NAC und beleuchtet dabei Stärken und Schwächen der potentiellen Lösungen, die es zur Zeit am Markt gibt. Er geht bewusst nicht auf einzelne Produkte ein, sondern beschäftigt sich hauptsächlich mit den Technologien und der damit zusammenhängenden Konzeptionierung. Viele Kunden berichten uns immer wieder, dass NAC ein schwieriges und unübersichtliches Projekt sei. Das kann es in der Tat werden, sofern man der Vor-bereitung zu wenig Beachtung schenkt oder sich zu wenig Zeit bei der Auswahl lässt. Auch stellt ein NAC Projekt und der Betrieb einer NAC Lösung Anforderungen an die Organistion selbst. Diese müssen in der Planungsphase ebenfalls beachtet werden. Der Leitfaden kann nicht alle Probleme und Bedenken aus der Welt schaffen; allerdings möchten wir hiermit versuchen, die wichtigsten Punkte herauszuarbeiten und damit das Risiko beim Projekt kalkulierbar machen. Wir wünschen viel Vergnügen!


Inhalt EINLEITUNG .......................................................................................................................... 2

WAS IST DENN DIESES NAC? .................................................................................................. 4

VORBEREITUNGEN ................................................................................................................ 6

DAS KONZEPT ........................................................................................................................ 6

IMPLEMENTIERUNG .............................................................................................................. 8

DETECT & AUTHENTICATE: JA WO LAUFEN SIE DENN? .......................................................... 10

802.1X ..................................................................................................................... 10

MAC-BASIERENDE AUTHENTIFIZIERUNG (VIA RADIUS) ........................................................ 11

WEB-BASIERENDE AUTHENTIFIZIERUNG ............................................................................ 11

STATISCHE PORT / MAC KONFIGURATION ......................................................................... 12

DYNAMISCHE PORT / MAC KONFIGURATION (SNMP) ......................................................... 12

KERBEROS SNOOPING ................................................................................................... 13

ZUSAMMENFASSUNG ................................................................................................... 13 ASSESSMENT: VON AGENTEN UND ANDEREN SPIONEN ........................................................ 15

AGENT LESS ................................................................................................................ 16

AGENT BASED ............................................................................................................. 17

ZUSAMMENFASSUNG ................................................................................................... 18 AUTORISIERUNG: DER ANFANG VOM ENDE ......................................................................... 19

(PORT) VLAN ZUWEISUNG ............................................................................................ 19

POLICYS .................................................................................................................... 20

PORTS SPERREN .......................................................................................................... 21

ZUSAMMENFASSUNG ................................................................................................... 21 REMEDIATION: „ABER, ...ICH HABE NICHTS GEMACHT!“ ....................................................... 22

MONITORING: DER GROßE BRUDER ..................................................................................... 23

BEYOND: DIE WELT HINTER DEM SPIEGEL ............................................................................ 23

NAC UND VOIP .......................................................................................................... 24

NAC UND DIE SECURITY INFRASTRUKTUR .......................................................................... 24

NAC UND VIRTUELLE SERVER ......................................................................................... 24

NAC UND DAS USER HELPDESK ....................................................................................... 24 SCHLUSSWORT .................................................................................................................... 25

ANHANG A: BEISPIEL CHECKLISTE ROLLEN / RECHTE ............................................................. 26

ANHANG B: BEISPIEL CHECKLISTE INFRASTRUKTUR .............................................................. 26

ANHANG C: BEISPIEL CHECKLISTE ASSESSMENT CHECKS ....................................................... 26

ANHANG D: BEISPIEL CHECKLISTE REPORTING ...................................................................... 26


Was ist denn dieses NAC? Network Access Control - manche nennen es auch Network Admission Control - oder einfach und kurz „NAC“ ist mittlerweile ein geläufiger Begriff in der IT Security Welt. Doch was steckt genau dahinter? Es ist immer wieder überraschend wie sehr die Erwartungen und Vorstellungen zu NAC auseinander gehen. Manche verbinden hiermit eine schlichte Registrierung und Autorisierung von Endgeräten anhand der (nicht ganz so) eindeutigen MAC Adresse im IP Netzwerk. Andere hingegen verbinden mit NAC den Schutz des gesamten Netzwerks vor Viren, Würmern und Netzwerkgeräten, die nicht den Unternehmens-richtlinien entsprechen; oder auch eine Lösung für den kontrollierten Zugriff von Gästen wird als NAC bezeichnet. Die einfache Antwort auf die Frage, ob dies denn nun NAC sei, lautet kurz: Ja. NAC beinhaltet eine Vielzahl von Prozessen, die den Zugang zum Netzwerk ermöglichen und gleichzeitig die Sicherheit sicherstellen sollen. Die einzelnen Prozesse oder auch Schritte sind:

Detect

Eindeutige Identifizierung und Lokalisierung von neuen Geräten am Netz

Authenticate Eindeutige Authentifizierung der Identität des Nutzers und / oder Gerätes

Assess Prüfung des Endgerätes auf Richtlinienkonformität und / oder Schwachstellen (Vulnerabilities)

Authorize Zugangserlaubnis mit möglichen Beschränkungen (wie Quarantäne) basierend auf dem Ergebnis der Authentifizierung und des Assessments

Remediate Beheben von Problemen und Sicherheitsmängeln – aber auch automatisierte Kommunikation mit den Nutzern (Hilfestellung, Statusmeldungen)

Monitor Überprüfung des Nutzer- und Geräteverhaltens während der gesamten Zeit am Netzwerk

Contain Reaktive Quarantäne bei der Festellung von verdächtigem Verhalten des Endsystems


In den folgenden Kapiteln werden wir uns jeden dieser einzelnen Schritte genauer anschauen und uns mit den jeweiligen ganz eigenen Herausforderungen auseinandersetzen. Manchmal gibt es mehrere Lösungen für ein Problem, welche gesondert durch kleine Infokästen dargestellt werden. Hier gilt: Je grüner, desto besser, umfangreicher oder preiswerter. Ein Beispiel:

€

Natürlich nützt all die Sicherheit niemandem etwas, wenn diese nicht finanziert werden kann bzw. nicht in einem akzeptablen Verhältnis zu den Kosten eines potentiellen Schadenfalles steht, der ohne den Einsatz von NAC eine höhere Eintrittswahrscheinlichkeit hat. Aus diesem Grunde werden ebenfalls Kosten und mögliche Einsparungen innerhalb dieses Leitfadens besprochen. Zuvor sollte zumindest eine rudimentäre Schutzbedarfsfestellung durchgeführt werden und eine Security Policy aufgestellt sein. Zu guter Letzt sind auch Querverweise zu offiziellen Regularien vorhanden, um einen rechtlichen Rahmen zu den Anforderungen und Maßnahmen zu geben.

+ schnelle Implementierung + geringe Einstiegskosten + Anbindung an andere Applikationen

- erhöhter Personalaufwand - hohe Folgekosten - mäßige Security Funktionalität - schlechte Skalierbarkeit

Fazit: Diese Löung eignet sich nur für kleinere Unternehmen mit geringem Budget und kleinen Netzwerken. Der Einsatz in großen / schnell wachsenden Unternehmen ist nicht zu empfehlen.

Einstie

gskosten

& W

artun

g

Skalierb

arkeit

Fun

ktion

sum

fang

Ad

min

istrativer A

ufw

and

Siche

rhe

itswe

rt

Zusätzlich

e Fu

nktio

nen

(auß

er Sich

erh

eit)


Vorbereitungen NAC ist, wenn es unternehmensweit eingeführt wird, ein umfangreiches Projekt, welches eine gute Vorbereitung voraussetzt. In der Tat ist dies sogar entscheidend für den Erfolg der späteren Umsetzung, da viele Probleme im Vorfeld erkannt und gelöst werden können. Dieses Dokument ist ein erster Schritt für genau jene Vorbereitungen. Alle nachfolgenden Kapitel stellen die verschiedenen Phasen der NAC Implementierung dar. Es mag erstaunlich erscheinen, aber der technische Ablauf ist in der Tat auch gleichzeitig der beste Ablauf für den Projektverlauf. Zuerst werden alle Endsysteme und Typen erfasst. Danach wird der beste Weg einer Autorisierung gemäß den Fähigkeiten der Endsysteme gewählt. Für viele endet hiermit schon NAC, was auch ausreichend ist, um eigene Systeme und Gäste oder gar Eindringlinge zu ermitteln und im Netz zu isolieren. Der nächste große Block besteht aus dem Assessment, der Prüfung des Endsystems und der Remediation. Das Ziel hier ist die Sicherstellung einer unternehmensweiten Richtlinie, die den Sicherheitszustand aller Endsysteme erkennt und darüber hinaus den Zugang in das Netzwerk über eine Autorisierung granular reguliert. Ein permanentes Monitoring stellt diesen Zustand auch über den eigentlichen Zugang hinaus sicher und ermöglicht es, jederzeit eine qualitative Aussage zur Sicherheit der gesamten IT Infrastruktur zu treffen. Einzig das Monitoring kann auch sinnvoll in der Implementierung nach vorne gezogen werden, nämlich direkt nach der „Detection“ Phase – falls auschließlich ein reaktives Security Konzept realisiert werden soll.

Das Konzept Aller Anfang beginnt auf dem Papier oder besser gesagt, mit der Idee. Gerade diese Idee, die Frage „Warum wollen wir NAC?“, ist entscheidend für den Umfang des gesamten Projektes. Ein Beispiel: „Wir wollen NAC einführen, um unseren Gästen in den Besprechungsräumen des Unternehmens Zugang auf das Internet zu gewähren. Allerdings soll die Kommunikation zu unseren eigenen Systemen unter-bunden werden. Darüber hinaus möchten wir die Privatsphäre der Gäste wahren und kein Assessment durchführen, jedoch sollen die eigenen Systeme auf einen Minimalschutz überprüft werden.“ In diesem Beispiel lassen sich schon die fundamentalen Größen einer NAC Planung erkennen. Es geht im Grunde um:

Wer darf sich im Netz anmelden? Wie darf jemand im Netz kommunizieren? Was ist für jemanden im Netz erreichbar? Wo darf dieser Zugang erhalten?

Prinzipiell ist NAC ein Prozess und kann damit aufgeteilt werden in:

Rollen (Wer?) Rechte (Wie?) Ressourcen (Was?) Orte (Wo?)


Alternativ kann noch eine zeitliche Komponente mit integriert werden (Wann darf zugegriffen werden?). Es ist unabdingbar eine entsprechende Zuordnung der Bausteine in einem Konzept vorab zu definieren. Eine mögliche Auflistung für das obigen Beispiel könnte so aussehen:

Rolle Rechte Ressourcen Orte

Administrator Alles Alles Alle

Mitarbeiter Applikationen Anwendungsserver Bürogebäude

Gast Nur HTTP Internet Gateway Besprechungsräume

In den meisten Bereichen existiert sogar schon eine Beschreibung der Rollen und Rechte im lokalen Verzeichnisdienst oder sogar in der Unternehmensstruktur. Es macht durchaus Sinn genau diese Rollen (oder auch Gruppen) zu übernehmen und als Basis für das NAC Konzept zu verwenden. Ein Verzeichnis-dienst kann hierbei allerdings nur eine Grundlage liefern, da leider der Hauptteil aller Netzwerkteilnehmer üblicherweise keine Benutzer sind. In der Tat zeigt sich, dass im Durchschnitt nur 30% bis 50% aller Systeme Workstations oder Laptops sind. Der Löwenanteil besteht aus einer Vielzahl von unterschied-lichsten Geräten unter unterschiedlicher administrativer Kontrolle.

Die größte Herausforderung bei einer NAC Implementierung besteht in der Einbindung der unterschiedlichsten Endgerätetypen unter Berücksichtigung der Möglichkeiten zur Identifizierung, Authentifizierung und eventuellem Assessment am Netzwerk-Access. Wir werden uns damit detailliert im Kapitel „Authenticate“ auseinandersetzen. An dieser Stelle ist es vorerst wichtig zu wissen, welche Geräte existieren und welche Rechte für den Einsatz von Nöten sind. Hierfür sollten ebenso Gruppen und Ressourcen definiert werden wie für die Benutzer zuvor. Man sollte jedoch die einzelnen Gruppen nicht zu spezifisch bilden, damit der administrative Aufwand gering bleibt. In der Praxis hat es sich als vorteilhaft erwiesen, die Gruppen an der tatsächlich genutzten Ressourcen anzulehnen und nur in wenigen Fällen einzelne Ausnahmeregelungen zu spezifizieren.


Kontrollfragen zum Thema:

Sind alle Arten von Teilnehmern und Geräten im Netz bekannt? Wurden alle benötigten Ressourcen für die jeweiligen Gruppen identifiziert? Welche lokalen Beschränkungen gibt es? (physisch / logisch) Sollen auch zeitliche Beschränkungen bestehen? Wenn ja, welche? Können Ressourcen eventuell gruppiert werden? Soll der Zugang generell erlaubt und spezifisch verboten werden oder umgekehrt?

Auch wenn nur mit einigen (Geräte- oder Nutzer-) Gruppen angefangen werden soll, muss eine komplette Übersicht vorhanden sein, da nur dann auch die richtige NAC Architektur und Lösung ausgewählt werden kann. Sonst bleibt man zwischen den Phasen stecken. Beispiel wäre die Verwendungen einer Software-(Agenten)-Lösung für NAC. Diese kann aber nicht alle Endgerätetypen am Netz wie Drucker, VoIP Phones, etc. abdecken. Dass heißt man wird nach dem Rollout auf den eigenen Clients an ein Limit stoßen!

Implementierung Vor der tatsächlichen Implementierung stellt sich nun noch einmal die Frage „Was wollen wir?“, allerdings unter Rücksichtnahme auf den zeitlichen Ablauf. In den wenigsten Fällen wird NAC komplett in einem Zuge eingeführt und meist liegen mehrere Monate zwischen den einzelnen Schritten. Der große Vorteil liegt bei NAC in der Tatsache, dass technisch kein Zwang besteht sofort alles von „Detection“ bis zur „Remediation“ zu implementieren. In der Praxis gliedert sich ein solches Projekt meist in folgende Aufbaustufen:

Phase 1: End-System Detection and Tracking Phase 2: End-System Authorization Phase 3: End-System Authorization with Assessment Phase 4: End-System Authorization with Assessment and Remediation

Phase 1 sammelt nur Informationen über alle Endsysteme ohne den eigentlichen Zugang zu beschränken. Dies entspricht einer Inventarisierung der Endgeräte am Netzwerk und kann durchaus auch begleitend zur Konzeptphase durchgeführt werden. Dies kann mit oder auch ohne Authentifizierung stattfinden.

Regulatorische Verweise zum Thema: BSI Maßnahmenkatalog: M 2.6 (analog ISO27001 - 9.1.6 – public access) Vor der Vergabe von Zutrittsberechtigungen für Personen sind die schutzbedürftigen Räume eines Gebäudes zu bestimmen, z. B. Büro, Datenträgerarchiv, Serverraum, Operating-Raum, Maschinensaal, Belegarchiv, Rechenzentrum. Der Schutzbedarf eines Raumes ist festzustellen anhand der im Raum befindlichen Informationstechnik sowie am Schutzbedarf der eingesetzten IT-Anwendungen und ihrer Informationen. Anschließend ist festzulegen, welche Person zur Ausübung der wahrgenommenen Funktion welches Zutrittsrecht benötigt. Dabei ist die vorher erarbeitete Funktionstrennung (M 2.5 Aufgabenverteilung und Funktionstrennung) zu beachten. Unnötige Zutrittsrechte sind zu vermeiden. Quelle: http://www.bsi.de/gshb/deutsch/m/m02006.htm

http://www.bsi.de/gshb/deutsch/m/m02006.htm


Phase 2 wendet die definierten Regeln und Beschränkungen an und benötigt typischerweise eine Authentifizierung, um sicher zu stellen, dass kein Endgerät sich die Rechte eines Anderen „erschleichen“ kann. Ansonsten wären auch statische Autorisierungsregeln (z.B. pro Port) möglich. Phase 3 erweitert die Informationen zu einem Endsystem um Assessmentdaten. Diese können von einem Agenten, durch externe Managementsysteme (für Softwareverteilung o.ä.) oder durch einen Netzwerk-scanner ermittelt werden. Typischerweise sind dies Daten wie das Betriebssystem, Schwachstellen / Vulnerabilities, offene Ports usw. Phase 4 nutzt die gesammelten Daten aus einem Assessment, um weitere Beschränkungen anzuwenden. Der Benutzer sollte hierbei über die Ergebnisse informiert werden und eine Gelegenheit geboten bekommen wieder einen sicheren Zustand herzustellen. Dies geschieht üblicherweise über Remediation Portale oder eine Auto-Remediation durch einen Agenten. Natürlich gibt es auch hierbei die berühmte Ausnahme zur Regel. In manchen Fällen wird nur ein Assessment mitsamt Remediation durchgeführt und auf Detect und Authorize verzichtet. Dies kann zum Beispiel der Fall sein, wenn ein System über eine VPN Verbindung am Netzwerk teilnimmt. An dieser Stelle findet schon eine Authentifizierung über das VPN statt, welche als „gegeben“ vorausgesetzt werden kann, so dass ein Endsystem nur noch auf Konformität geprüft werden muss. Vorbereitend macht es an dieser Stelle Sinn die bestehende Zuordnung von Ressourcen, Lokationen und / oder Gruppen um die Information zu erweitern, bis zu welcher Phase implementiert werden soll. Es handelt sich hierbei um eine klare Kosten / Nutzen-Rechnung, in der der gewünschte Sicherheitsgrad mit den Kosten einer Implementierung und dem Aufwand im Betrieb in Einklang gebracht werden sollte. Ein weiterer sehr wichtiger Punkt wird zu Beginn meist unterschätzt. NAC ist ein weitreichendes Projekt und erfordert die Zusammenarbeit des gesamten IT Personals. In einem solchen Projekt ist nicht nur der Netzwerkbetrieb involviert, sondern ebenfalls die Abteilungen für Endsysteme, Server, Security Management und Datenschutz. Es sollte unbedingt zuvor ein Treffen angesetzt werden, welche alle Vertreter der einzelnen Abteilungen an einen Tisch holt, informiert und Anforderungen mit aufnimmt. Hierbei bietet es sich ebenfalls an die Geschäftsleitung mit einzubeziehen, um organisatorische Planungssicherheit zu gewährleisten. Wir haben uns bisher bewusst nicht mit der technischen Implementierung auseinandergesetzt, da jeder Schritt im Projekt seine eigenen Tücken hat. Wir werden in den folgenden Kapiteln nun im Detail darauf eingehen und mögliche Lösungen und Ansätze am Markt in diesem Zusammenhang betrachten. Kontrollfragen zum Thema:

Welcher Funktionsumfang ist in welchem Bereich erwünscht? Können bestehende Daten zur Authentifizierung / Autorisierung genutzt werden? Wurde ein Zeitplan zu den einzelnen Implementierungsphasen erstellt? Sind alle IT Abteilungen informiert?


Detect & Authenticate: Ja wo laufen sie denn? Jeder soll sich überall und jederzeit an einer beliebigen Stelle anmelden können und das Netzwerk reagiert vollkommen dynamisch und automatisiert gemäß den Richtlinien. Obwohl sich dies auf den ersten Blick hervorragend anhört, scheitert die Umsetzung fast immer am ersten Schritt. Man muss zuerst wissen, wer im Netzwerk ist und wo sich dieser aufhält. Der Vorteil einer solchen Erkennung ist die Einsparung meist veralteter, aufwändiger Dokumentation des Netzwerkes. Man könnte sagen, das Netzwerk dokumentiert sich selbst. Nun bleibt nur die Frage: „Wie kann man ein Endsystem oder einen Benutzer eindeutig identifizieren?“ Besonders beliebt im Netzwerkbereich sind MAC und IP Adressen, jedoch bieten diese überhaupt keine Sicherheit bezüglich des Wahrheitsgehaltes. Die Adressen können ohne größere Probleme in weniger als 2 Minuten geändert werden und damit eignen sich diese Merkmale nur bedingt für eine Identifizierung. In der Tat hängt die Erkennung der Endgeräte sehr dicht mit der Authentifizierung zusammen. Meist verzichtet man allerdings in diesem ersten Schritt auf die Durchsetzung eines Regelwerkes, nutzt aber dennoch dieselben Mechanismen der Authentifizierung zur Erkennung des Endsystems. Vorab stellt sich aber schon die Frage „Welche Authentifizierung unterstützt das Endsystem?“ Um einen Überblick zu schaffen, schauen wir uns die üblichsten Methoden an und die Szenarien, in denen diese angewandt werden können:

802.1x portbasierende Authentifizierung (via RADIUS) MAC-basierende Authentifizierung (via RADIUS) Web-basierende Authentifizierung Statische Port / MAC Konfiguration Dynamische Port / MAC Konfiguration (SNMP) RADIUS Snooping Kerberos Snooping

Es sind aber auch Kriterien wie Hostnamen oder IP Adressen zur Identifizierung möglich. Insbesondere bei Non-Desktop-Systemen kann dies sehr effektiv und hilfreich sein.

802.1x Die sicherste Lösung besteht zweifelsohne in der Erkennung der Endsysteme am Switchport mittels 802.1x Authentifizierung. Diese erfordert die entsprechenden Funktionalitäten auf Seiten des Switches, des Clients und einer lokalen Authentifizierungsinstanz (RADIUS Server). Darüber hinaus können hier sowohl Geräte als auch Benutzer identifiziert werden. Meist ist dies aber aufgrund von Einschränkungen in einem der genannten Bereiche nicht flächendeckend einsetzbar. So gibt es Endgeräte ohne „802.1x Supplicant“ (die Software zur Authentifizierung), wie zum Beispiel ältere Drucker oder IP Video-Anlagen oder die Switche selbst bieten keine Unterstützung für diesen Standard. Gäste können damit auch nicht erfasst werden. In der Praxis trifft man regelmäßig auf heterogene Netzwerke, die nur teilweise oder gar keine Authentifizierung ermöglichen. Das Ziel hier lautet: Das Maximum mit gegebenen Mitteln erreichen und im Laufe der folgenden Jahre die mangelnden Funktionalitäten nach und nach zu implementieren. Ein kompletter Austausch des Netzwerks ist aufgrund der hohen Kosten meist nicht zu empfehlen. Sollte jedoch ein Tausch der Netzwerkkomponenten anstehen, so sollten diese 802.1x beherrschen und auch mehrere individuelle Authentifizierungssitzungen pro Port halten können sowie unterschiedliche Autorisierungen pro Endgerät - bei mehreren Endgeräten pro Port (Stichwort: VoIP Phone plus PC oder Mini- / Office- / Kabelkanalswitche) ermöglichen.


MAC-basierende Authentifizierung (via RADIUS) Hier wird die selbe Infrastruktur genutzt wie bei einer 802.1x Infrastruktur. Es wird lediglich auf Zertifikate und / oder Anmeldedaten verzichtet. Der Switch benutzt hierbei die MAC Adresse als Ersatz für den Be-nutzernamen und gleicht dies mit dem RADIUS Server ab. Dieses Verfahren kann in 802.1x fähigen Netzen genutzt werden, um Endsysteme ohne „Supplicant“ gegen einen RADIUS Server abzugleichen. Oder man baut alleine auf diese Technologie im gesamten Netz und steigt erst später auf 802.1x bei Teilen der End-geräte um. Die Sicherheit einer solchen Authentifizierung ist jedoch sehr begrenzt und sollte nur in Ver-bindung mit einer sehr restriktiven Autorisierung genutzt werden, falls alle anderen Möglichkeiten nicht zur Verfügung stehen. Weiterhin gibt es keine weiteren Informationen bei der Abfrage, wie zum Beispiel den Benutzernamen und spätere Autorisierungen können nur an die Hardwareadresse des Endgerätes gebunden werden. Ein Vorteil hierbei ist jedoch die zentrale Administration aller Teilnehmer über den RADIUS Dienst.

Web-basierende Authentifizierung Diese Methode lagert den „Supplicant“ auf ein zusätzliches Webportal aus, an dem sich der Benutzer anmelden kann. Somit können sich besonders Gäste und Systeme ohne die nötigen Voraussetzungen im Netzwerk registrieren. Bei Gastzugängen ist teilweise sogar nur eine einfache Registrierung notwendig. Eine elegante Lösung für einen sicheren Gastzugang stellt hierbei eine „sponsored Registration“ dar, bei der ein existierender Benutzer mit seinen Anmeldedaten für einen Gast „bürgt“. Auf diese Weise ist es später bei eventuellen Verstößen wesentlich leichter nachzuvollziehen, wer den Besucher in das Netzwerk gebracht hat und die Verwaltung von Gästen muss nicht durch die IT Abteilung erfolgen. Diese Methode eignet sich jedoch nicht, um Geräte wie Drucker zu authentifizieren. Üblicherweise geht dies einher mit einer Default Policy, die ausschließlich Verbindungen zum Webportal zulässt und erst nach einer

€

€

+ in aktuellen Systemen Standard + zentrale Administration + Echtzeiterkennung + hohe Sicherheit + hohe Skalierbarkeit + Zusatzinformationen (User, Host)

- viele Vorraussetzungen nötig - nachträgliche Aufrüstung teuer

Fazit: Wenn alle Vorraussetzungen gegeben sind, bietet 802.1x eine sehr skalier-bare und dynamische Identifizierung mit einer hohen Sicherheit direkt am Switchport.

Fazit: Diese Methode ist eine Lösung zur Erfassung spezieller Systeme. Es ist besser als statische Port/MAC Zu-ordnungen, da Dynamik und Skalier-barkeit wie bei 802.1x gleich bleiben.

Regulatorische Verweise zum Thema: BSI Maßnahmenkatalog: M 2.10 Um Verstöße gegen das Verbot der Nutzung nicht freigegebener Hard- und Software feststellen zu können, ist eine regelmäßige Überprüfung des Hard- und Software-Bestandes notwendig.... Die Ergebnisse der Überprüfung sind zu dokumentieren, um auch Wiederholungsfälle feststellen zu können. Quelle: http://www.bsi.de/gshb/deutsch/m/m02010.htm

+ in aktuellen Systemen Standard + zentrale Administration + Echtzeiterkennung + hohe Skalierbarkeit

- viele Vorraussetzungen nötig - geringe Sicherheit - wenig Zusatzinformationen

http://www.bsi.de/gshb/deutsch/m/m02006.htm


erfolgreichen Authentifizierung mehr Dienste zulässt. Hierbei gilt jedoch zu beachten, dass die meisten Lösungen diese Beschränkung durch eine dynamische VLAN Konfiguration umsetzen. Dies trennt ein Endsystem zwar vom produktiven Netzwerk, jedoch gibt es meist keine Beschränkung zwischen der Kommunikation unter den Geräten innerhalb eines solchen Quarantäne-VLANs. Man sollte dabei niemals außer Acht lassen, dass VLANs keine Sicherheitscontainer sind, sondern nur logische Broadcastcontainer. Enterasys Switche verwenden hierbei einen anderen Ansatz, der den Verkehr direkt auf OSI Layer 2 bis 4 klassifiziert und ähnlich einer Firewall regulieren kann. Dazu mehr im Kapitel „Autorisierung“.

Statische Port / MAC Konfiguration Die manuelle Zuordnung von MAC Adressen zu einem Switchport hat mittlerweile eine lange Tradition. Sie ist, wie der Name schon sagt, jedoch weder für eine automatisierte Erkennung noch für eine Zugangssicherheit geeignet. Sie soll hier nur der Form halber erwähnt sein, da eine solche Konfiguration noch immer in vielen Unternehmen eingesetzt wird und auch jetzt noch für eine kostengünstige Alternative gehalten werden könnte.

Dynamische Port / MAC Konfiguration (SNMP) Es gibt eine Reihe von Nischenlösungen am Markt, die versuchen den Prozess der Erkennung und Authentifizierung mittels SNMP nachzustellen. Gerade kleinere Unternehmen nutzen dies gern, wenn keinerlei Verzeichnis- oder RADIUS-Infrastruktur zu Verfügung steht. Die Vorteile sind klar ein Out-of-Band Management, welches zu allen Systemen mit SNMP Unterstützung kompatibel ist. Genau in dieser Kompatibilität liegt jedoch eines der Probleme. Viele Hersteller liefern mittels SNMP ungenaue oder fehlerhafte Informationen, so dass eine einwandfreie Funktion nicht gewährleistet werden kann. Darüber hinaus ist eine Authentifizierung auf diesem Wege mit keinem Standard konform. Weiterhin ist zu beachten, dass ein solches System nicht echtzeitfähig ist, da die SNMP Anfragen zyklisch über Zeitintervalle erfolgen. Die Abfragen selbst können Lastprobleme auf Routern und Switchen erzeugen und im schlimmsten Fall zu einem Absturz führen. Aus Sicht der Sicherheit wird hier der Prozess der Port / MAC Konfiguration einfach mittels SNMP dynamisch verwaltet. Dies hat den Vorteil, dass man zumindest weiß, wo sich ein Endsystem bei der letzten Abfrage befunden hat; was jedoch auch gut mehrere Minuten her sein kann. Als Gegenmaßnahme wird häufig ein einfaches Abschalten des Ports verwendet oder die Rekonfiguration der Port VLANs. Bei beiden Möglichkeiten hat ein Benutzer jedoch so gut wie keine Chance zu erfahren, warum er nicht in das Netz kommen konnte. Bei VLAN Rekonfigurationen kommt es hierbei auch zu Schwierigkeiten, falls DHCP eingesetzt wird und der Client nicht sofort eine neue Adresse anfragt. Aufgrund der sehr schwachen Sicherheit in Kombination mit den häufigen Problemen sowie dem administrativen Aufwand ist diese Lösung trotz des geringen Preises, wenn überhaupt nur für kleinere

€

€

Fazit: Diese Methode ist eher eine Ergänzung als eine eigenständige Authentifizierungsmethode. Sie erleichtert den administrativen Aufwand für Gäste und ermöglicht den Zugang für ältere Systeme.

+ zentrale Administration + Echtzeiterkennung + gute Skalierbarkeit

- zusätzliche Serververwaltung - zusätzliche Anmeldemaske - zum Teil unsichere Quarantäne

Fazit: Sicherlich die billigste, aber auch nutzloseste Lösung für NAC.

+ billig + in jedem Switch enthalten

- Administrationsaufwand - nicht zentral verwaltbar - ungenügende Sicherheit - keine Zusatzinformationen


Umgebungen ohne Möglichkeiten für 802.1x zu empfehlen. Weiterhin sind massive Probleme bei mehreren Endgeräten pro Port zu erwarten.

Kerberos Snooping Das Kerberos Protokoll wird zur Authentifizierung im Netzwerk verwendet. Typischerweise findet es seinen Einsatz in Windows Active Directory Domänen, obwohl es hierauf nicht zwangsweise beschränkt ist (auch Novell NDS nutzt dies und in Linux Umgebungen wird es auch gern eingesetzt). Kerberos Snooping liest den verschlüsselten Datenverkehr mit und kann somit erkennen, ob ein System sich erfolgreich an der Domäne anmelden konnte. Kerberos liefert hierbei den Benutzernamen und Hostnamen als Identifizierungsmerk-mal. Der große Vorteil einer solchen Lösung besteht darin, dass die einzige Voraussetzung die Verwendung des Kerberosprotokolls ist. Die Erkennung und Authentifizierung ist hierbei vollkommen von den Switchen losgelöst und kann in vielen Fällen direkt ohne größere Eingriffe implementiert werden. Nachteilig ist hingegen, dass für ein solches Feature die Kommunikation von einer In-Line-Appliance ähnlich einem Intrusion Detection System mitgelesen werden muss (bei Enterasys der NAC Controller). Die Appliance sorgt an dieser Stelle jedoch selber für die Autorisierung und bietet meist wesentlich mehr Funktionali-täten als über eine Standard 802.1x Implementierung auf dem Access Switch möglich wären. Ein Nachteil ist, dass der Access Switchport nicht genau identifiziert werden kann, da ein solches System höchstens den eigenen Port identifizieren kann, der zumeist eine Auflösung bis auf Verteilerraumebene bietet. Eine solche Lösung ist durchaus in Bereichen einsetzbar, in denen eine erhöhte Sicherheit ähnlich einer Firewall gewünscht ist und / oder Endsysteme sowie Switche keine anderen Möglichkeiten zur Erkennung bieten. Eine solche Appliance wird typischerweise im Distribution Layer verwendet und kann dort unter anderem auch WAN Übergänge, wie zum Beispiel VPN Zugänge, überwachen. Sie sorgt für eine sehr schnelle Um-setzung von NAC ohne Investment in Access Switche.

Zusammenfassung Dies sind die gängigsten, aber sicherlich nicht alle Möglichkeiten, um ein Endsystem im Netzwerk zu er-kennen. Bei der Frage: „Welche ist denn nun die Passende für mich?“ gibt es keine konkrete Antwort. In fast allen Fällen ist eine Kombination aus diesen Mechanismen erforderlich, um eine flächendeckende NAC Funktionalität zu gewährleisten. Auch wenn ein überwiegender Teil zum Beispiel über 802.1x abzuhandeln ist, so bietet sich eventuell eine zusätzliche In-Line-Appliance an strategischen Punkten an, um entweder mehr Sicherheit für die betroffenen Ressourcen zu gewährleisten oder eine Erkennung von Endsystemen überhaupt erst möglich zu machen. Sobald Gäste hinzukommen, sollte möglicherweise ein Webportal zur Registrierung verwendet werden, um den administrativen Aufwand gering zu halten. Oft wird dies auf den In-Line-Appliances mit integriert.

€

€

Fazit: Günstige, einfache Lösung für kleine Unternehmen. Eignet sich höchstens für eine Lokalisierung von Endsys-temen, bietet jedoch keine nennens-werte Sicherheit.

+ billig + mit vielen Switchen kompatibel

- schlechte Skalierbarkeit - kein Standard - ungenügende Sicherheit - keine Zusatzinformationen - nicht echtzeitfähig

Fazit: Flexible, schnell implementierbare Lösung. Muss In-Line betrieben werden und eignet sich aufgrund des Kostenfaktors nur bedingt für einen flächendeckenden Einsatz.

+ schnelle Implementierung + zentrale Verwaltung + flexible Authentifizierung auch in Layer 3 Netzen + bietet zusätzliche Informationen + viele Sicherheitsfeatures

- kein Standard - erfordert Kerberos Umgebung


Kontrollfragen zum Thema: Welche meiner Endgeräte kann ich wie erfassen? Lassen sich problematische Endgeräte lokal begrenzen? Z.B. in Industrieanlagen? Welche Voraussetzungen bietet mein Netzwerk für die verschiedenen Erkennungsmethoden? Welche Systeme, die jetzt noch problematisch sind, können im Laufe der Zeit angepasst werden? Welche Erkennungsmethoden sind in ein paar Jahren noch verwendbar? Müssen mehrere Endgeräte an einem einzelnen Port unabhängig von einander authentifiziert

werden? Z.B. VoIP Phone und PC. Falls mehrere Endgeräte authentifziert werden müssen, kann dieses auch über unterschiedliche

Methoden geschehen? Z.B. 802.1x und Web.


Assessment: Von Agenten und anderen Spionen Ein fest in den Anmeldeprozess eingebundenes Assessment ist noch nicht sehr weit verbreitet, obwohl dies genauso zu NAC gehört wie die Authentifizierung. Hier sind „Standards“ wie Microsoft NAP (Network Access Protection) und Trusted Computing Group TNC (Trusted Network Connect) anzusiedeln. Die IETF versucht sich hier auch, aber es bleibt abzuwarten wie sich dies entwickelt. Im Assessment möchte man über den Portrand hinaus blicken und prüfen, wie es auf dem Client selbst ausschaut. Man unterscheidet hierbei zwei Hauptvarianten mit den dazugehörigen Unterkategorien:

Agent less:

- Network based – ein Netzwerkscanner, der das Endgerät von „außen“ prüft - Applet based – ein Java Applet, welches nur im Browser ausgeführt wird

Agent based:

- Thin Agent – ein Agent, der nur zur Laufzeit des Systems vorhanden ist - Fat Agent – meist eine persistente Suite mit Firewall und Host Intrusion Detection

Aufgabe des Assessments ist die Prüfung des Endsystems auf Konformität und / oder Schwachstellen. Hierzu gehören unter anderem Tests, ob die Firewall arbeitet oder wie verwundbar ein System in Bezug auf Angriffe ist. Auf die Frage, welche Methode (Agent less oder Agent based) denn nun die Bessere ist, lautet wieder einmal die Antwort klar und deutlich: Beide. Analog zu den Authentifizierungsmechanismen hängt es hierbei davon ab, was man prüfen möchte und welche Möglichkeiten ein Endsystem zur Prüfung bietet. Offensichtlich wäre es eine große Herausforderung einen Agenten auf einem Drucker oder einem Telefon zu installieren. Andererseits hat ein Netzwerkscanner Schwierigkeiten bei der Prüfung auf aktuelle Virensignaturen beim lokalen Anti-Virus Programm. Ein weiterer großer Unterschied ist die Zeit und Last im Netzwerk, die bei den verschiedenen Verfahren benötigt werden. Ein Netzwerkscanner arbeitet (wie der Name vermuten lässt) mit Scans im Netzwerk, die natürlich auch mehr Last erzeugen und Bandbreite benötigen. Ein Agent verlagert diese Prüfungen auf den Client und benötigen somit „nur“ die lokalen Ressourcen bis ein endgültiger Bericht zu einer zentralen Stelle gesendet wird. Die lokalen Ressourcen, die benötigt werden, können bei Fat Agents aber erheblich sein, da diese oft per Self Enforcement arbeiten (und damit als Personal Firewall und / oder Host Intrusion Prevention System). Beim zeitlichen Aspekt lässt sich nur sehr schwierig eine konkrete Aussage treffen, da die Dauer einer solchen Prüfung von den Tests und Intentionen abhängt. Eine schnelle Prüfung, ob der lokale Firewall Prozess läuft, geht wesentlich schneller als ein Netzwerkscan über Tausende von Ports mit

Health Check

Agent less

Network based

Applet based

Agent based

Thin Agent

Fat Agent


anschließenden Tests auf Verwundbarkeiten. Auf der anderen Seite bietet ein umfangreiches Assessment nicht nur Informationen über die „Gesundheit“ eines Teilnehmers (leider nur die Software, nicht der Benutzer selbst), sondern kann auch zusätzliche Daten für eine Inventarisierung abfragen.

Agent less Der Umfang der Testmöglichkeiten hängt hier sehr stark von der eingesetzten Software für ein Assessment ab. Der Markt für Vulnerability Scanner ist mittlerweile gut ausgeprägt und bietet eine Vielzahl von Pro-grammen, die genau eine solche Aufgabe übernehmen und durch ständig neue Testsets aktuell gehalten werden können. Üblicherweise besteht eine solche Prüfung aus den beliebig kombinierbaren Schritten:

1. Verfügbarkeit & Identifikation – Ping, DNS Lookup 2. Portscan – TCP/UDP 3. Vulnerability Identifikation 4. Vulnerability Exploits

Jeder dieser Punkte sollte in sich selbst noch konfigurierbar sein und die Auswahl bieten, ob die Ergebnisse aus einem vorhergehenden Schritt als Ausgang für den Nächsten genutzt werden. So bietet es sich aus Gründen der Geschwindigkeit und Last an, nur Ports auf Verwundbarkeiten zu testen, die auch tatsächlich geöffnet sind. Einige Netzwerkscanner können sich sogar mit dem Client selbst verbinden (unter Angabe eines gültigen Benutzernamens / Passworts) und lokale Tests durchführen. Bei den Vulnerability Exploits ist jedoch Vorsicht geboten, da diese möglicherweise ein Endsystem zum Absturz bringen. Andererseits ist dies jedoch die sicherste Möglichkeit das Vorhandensein einer Sicherheitslücke zu testen. Ein Nachteil einer solchen Prüfung ist die Genauigkeit der Ergebnisse, da auf der einen Seite nur bekannte Verwundbarkeiten geprüft werden können und auf der Anderen Dienste und Versionen nicht immer hundertprozentig über das Netzwerk identifiziert werden können. Solche Informationen und Tests sollten sich in den meisten Fällen noch anpassen lassen, allerdings wird in der Praxis häufig der Weg gewählt eher wenige, wichtige Dinge zu prüfen. Ein weiteres Problem stellt die Last eines solchen Scanvorganges auf dem Scanserver selbst dar. Es ist meist unrealistisch Tausende von Endsystemen von einem einzelnen Server regelmäßig prüfen zu lassen, was einen flächendeckenden Einsatz in größeren Umgebungen aus finanziellen Gründen meist scheitern lässt. Diese Art des Assessments hat allerdings auch seinen Charme, da die Prüfungen meist umfangreicher sind als das, was ein kleiner Agent leisten kann und gerade bei Gästen umgeht man hiermit den Zwang, dass man seinem Besucher zuerst eine fremde Software installieren muss. Der größte Vorteil liegt allerdings in der Prüfung von Endsystemen, die keinen Agenten aufnehmen können und damit ist auch gleichzeitig die Anzahl der zu scannenden Systeme auf ein erträgliches Maß begrenzt.

€

Fazit: Netzwerkscans automatisieren viele manuelle Tests und werden von zentralen Servern im Netzwerk durch-geführt. Besonders in Bereichen zu empfehlen, in denen kein Agent ver-wendet werden kann.

+ schnelle Implementierung + häufige Signatur-Updates + umfangreiche Tests + detaillierte Clientinformationen + hohe Endsystemkompatibilität

- limitierte Skalierbarkeit - eventuell lange Scandauer - hohe Netzwerklast


Agent based Ein Agent ist eine eigenständige Software, die autonom auf einem Endsystem ausgeführt wird und dort, hinter den feindlichen Linien des Switchports, sowohl über den Zustand berichtet und in manchen Fällen sogar proaktiv gegen Verstöße vorgeht (Self Enforcement). Der große Vorteil ist die Möglichkeit alle Daten auf einem System direkt abfragen und sofort prüfen zu können. Damit hat man allerdings auch gleich die Kehrseite der Medallie erkannt, da ein Agent erst einmal auf einem Endsystem installiert werden muss und darüber hinaus wissen muss, was überhaupt zu prüfen ist. Gerade in Bereichen mit vielen unterschiedlichen Betriebssystemen und Anwendungen kann dies besonders viele Konfigurationsänderungen am Client nach sich ziehen oder erst gar nicht zum Einsatz kommen. Weiterhin muss der Agent „sozial“ sein und sehr viel mit seiner Umgebung kommunizieren können, was sich allerdings bei einem Einsatz von Soft- und Hardware verschiedener Hersteller meist als schwierig darstellt. Es ist kein besonders gut gehütetes Geheimnis, dass viele Hersteller versuchen die Bindung zu ihrer NAC Lösung mit eigenen Agenten zu stärken und somit eine Diversifizierung mit anderen Lösungen zu unterbinden. Neuere Betriebssysteme und NAC Lösungen bieten jedoch schon Frameworks an, die eine Anbindung beliebiger Agenten und anderer Informanten ermöglichen. Microsoft bietet hier Network Access Protection (NAP) als Schnittstelle zwischen Agenten und NAC auf dem Betriebssystem selbst an. Generell sollte bei der Auswahl die Zukunftsfähigkeit und Kompatibilität beachtet werden, um die Flexibilität für spätere Entscheidungen zu wahren. Ein Agent bietet typischerweise folgende Prüfmöglichkeiten:

Ist die Firewall eingeschaltet? Läuft ein Antivirenprogramm und sind die Signaturen aktuell? Welches Betriebssystem ist installiert? Wie aktuell ist das Patchlevel des Systems? Besteht die Verbindung zum Agenten? Welche Software ist installiert? Welche Prozesse und / oder Dienste sind gestartet?

Theoretisch sind die Möglichkeiten nahezu unbegrenzt, allerdings ziehen spezifische Tests weiteren Aufwand nach sich, da der Agent erst einmal erfahren muss, was getestet werden soll und wie „gut“ von „böse“ zu unterscheiden ist. Im Gegensatz zum „Agent less“ Scan verrichtet der Agent seine Arbeit und meldet sich mit den Ergebnissen zurück, so dass die Prüfung in der Regel wesentlich schneller stattfindet und die Last auf das Endsystem verlagert. Somit wird eine optimale Skalierbarkeit besonders in größeren Netzen gewährleistet. Gegebenenfalls kann sogar direkt eine Behebung des Problems (sogenannte Auto Remediation) erfolgen, wie z.B. das Einschalten der Firewall. Durch die Verwendung von sogenannten „dissolvable Agents“ lassen sich auch Gäste gut integrieren, da sich der Agent nur im RAM des Endsystems befindet und nach einem Neustart wieder verschwunden ist.

€

Fazit: Agenten können (fast) alles, sind aber leider nicht auf jedem Endsystem aus-führbar. Gegenmaßnahmen können lokal auf dem Client ausgeführt werden und sowohl Last als auch Skalierbarkeit sind optimal.

+ Zugriff auf jede Clientinformation + proaktive Gegenmaßnahmen + sehr gute Skalierbarkeit + sehr gutes Lastverhalten + kurze Scanzeit

- Endsystemkompatibilität - meistens single-vendor benötigt - teils hoher Konfigurationsaufwand


Zusammenfassung Es ist offensichtlich, dass es auch beim Assessment keine einzelne, alles umfassende Lösung für alle Endgeräte gibt. Der beste Ansatz für einen tagtäglichen Einsatz lässt sich für die meisten Umgebungen zusammenfassen als: „Agenten wo möglich, Netzwerkscan wo nötig“, wenn überhaupt Assessment zum Einsatz kommen soll und man sich nicht auf bestehendes Softwaremanagement und Softwareverteilungs-systeme verlassen möchte. Beide Varianten ergänzen sich komplementär und in Bereichen mit extrem hohen Sicherheitsanforderungen macht es sogar Sinn, beides gleichzeitig einzusetzen. Neben der Möglichkeit jederzeit eine Aussage über den Sicherheitszustand aller Netzwerkteilnehmer zu treffen, ist der größte Vorteil eines Assessments eine umfangreiche Dokumentation aller Netzwerkgeräte. Dieser Vorteil wird umso größer, sobald die eingesetzte NAC Lösung offene Schnittstellen zur Verwendung beliebiger Daten anbietet. Hier können sogar weitere Informationen aus Inventarisierungssoftware, Update Servern oder anderen Systemen mit relevanten Daten über ein Endsystem hinzugezogen werden und in die Beurteilung mit einfließen. Kontrollfragen zum Thema:

Was soll auf einem Endsystem geprüft werden? Welche Methoden der Prüfung lässt ein Endsystem zu? Wie lange dauert eine Prüfung? Wie kann das Assessment unternehmensweit skalieren?

Regulatorische Verweise zum Thema:

BSI Maßnahmenkatalog (Auszüge): M 2.9 Nutzungsverbot nicht freigegebener Hard- und Software

(ISO 27001 - 10.4.x - Protection against malicious and mobile software)

M 2.10 Überprüfung des Hard- und Software-Bestandes M 2.11 Regelung des Passwortgebrauchs

(ISO 27001 - 11.2.3 - User password management)

M 4.3 Regelmäßiger Einsatz eines Anti-Viren-Programms ...und viele weitere Quelle: http://www.bsi.de/gshb/deutsch/m/m01.htm


Autorisierung: Der Anfang vom Ende An dieser Stelle wissen wir nun wie die unterschiedlichsten Endsysteme erkannt und authentifiziert werden können. Darüber hinaus liegen auch weiterführende Informationen eines Assessments vor, die ebenfalls zum Entscheidungsprozess beitragen, wer „gut“ und wer „böse“ ist. Und nun? Nun müssen wir dem Ganzen Taten folgen lassen und kommen zu dem Teil des NAC Projektes, vor dem überraschend viele Administratoren und Benutzer Angst haben - der Autorisierung. Die Autorisierung trennt im wahrsten Sinne die Spreu vom Weizen und setzt die Restriktionen um, die in der vorbereitenden Konzeptionierung geplant worden sind. Wir haben bereits vorher einige Methoden kurz genannt, die wir uns nun genauer anschauen wollen. Wieder einmal stehen uns mehrere Möglichkeiten zur Verfügung, die im Wesentlichen von dem abhängen, was das Netzwerk und / oder die NAC Lösung zu leisten im Stande ist. Die Entscheidungs-grundlage für diese Typen des „Enforcements“ gestaltet sich darüber hinaus aus den Sicherheits-anforderungen und des Aufbaus der Infrastruktur selbst. So sollte zuvor bedacht werden, ob mehrere Endsysteme sich einen Zugang am Switchport teilen oder ob Geräte, Benutzer, ganze Ports oder einzelner Verkehr berücksichtigt werden sollen.

(Port) VLAN Zuweisung Dies ist die häufigste und darüber hinaus sogar standardisierte Art (RFC 3580 mittels 802.1x und RADIUS) Zugriffsrechte zu gewähren. Hierbei befindet sich jeder Port per Default in einem Gast- oder auch Quarantäne-VLAN, welches nach erfolgreicher Authentifizierung und Assessment in ein produktives VLAN geändert wird. Diese Form der Autorisierung ist deshalb so verbreitet, weil mittlerweile so gut wie jeder Switch den Einsatz von VLANs unterstützt und sich durch die Verwendung verschiedener VLANs isolierte Zonen im Netzwerk bilden lassen. Doch auch diese Methode hat trotz ihrer Beliebtheit einige Schwach-stellen. Einerseits ist ein VLAN in sich kein Security Container und andererseits ist die Verwendung vieler unterschiedlicher VLANs nicht praktikabel genug bzw. es erhöht den Aufwand für den Betrieb des Gesamt-netzes erheblich (mehr VLANs = mehr IP Subnetze = mehr IP Routerkonfiguration, etc). Auch im Zusam-menspiel mit 802.1x und DHCP muss ein Client über seinen „Supplicant“ mitgeteilt bekommen, dass er in einem anderen VLAN ist und eine neue IP Adresse anfordern muss. Ohne dies wird es bei einer reinen VLAN Änderung ohne 802.1x (z.B. über SNMP) zu Konnektivitätsausfällen kommen. Einige Hersteller versuchen hier einen Workaround mittels eines kurzen Ab-/Einschalten des Ports zu erreichen, was aller-dings zu Kommunikationsunterbrechungen für andere Teilnehmer führt, sobald mehrere Endgeräte an einem Switchport angeschlossen wurden (Stichwort: Voice over IP Telefon) und nur einer der Teilnehmer neu autorisiert werden müsste. Die Handhabung multipler Clients an einem Switchport für sich ist schon problematisch. Bestehende Lösungen nutzen besonders im Zusammenhang mit VoIP die Variante, dass eines der beiden Geräte (üblicherweise das Telefon) seine Kommunikationsdaten mit der passenden VLAN ID vorab „tagged“. Damit kann der Switch danach die Kommunikationsbeziehung auseinanderhalten, jedoch ist dies eine sehr unsaubere Lösung, da die Teilnehmer im Netzwerk die Zuordnung von VLANs eigentlich dem Netz selber überlassen sollten. Die Alternative nur je ein Gerät pro Port zuzulassen, ist nicht überall mach-bar und treibt die Kosten des Netzwerkes in die Höhe. Ebenfalls kann einzelner Verkehr hier-bei nicht unterschieden werden und ermöglicht so nur eine Klassifizierung für den gesamten Port oder das einzelne Gerät. Die Port VLAN Zuweisung stellt einen brauchbaren Kompromiss dar, allerdings sollte man seine Schwachstellen kennen und zuvor in der Planung berücksichtigen.


Policys In einem Satz gesagt sind Policys mit NAC die dynamische Firewall am Switchport. Die Funktionalität von Policys am Switchport gehört schon immer zu Enterasys Secure Networks™ und stammt noch aus der Zeit von Cabletron Systems. Mit Policys besteht die Möglichkeit vom Switchport über den Benutzer bis hin zum Traffic selbst zu regulieren, was erlaubt ist und was nicht – und welche Priorität und Bandbreite einzelnen Applikationen pro Nutzer zur Verfügung steht. Dadurch lassen sich auch mehrere Systeme unabhängig voneinander beschränken und es besteht noch nicht einmal die Notwendigkeit einer Trennung durch verschiedene VLANs. Der Traffic kann zusätzlich zur Authentifizierung anhand einer Vielzahl an Eigen-schaften klassifiziert und individuell behandelt werden. Typische Beispiele hierfür sind:

Betrieb von DHCP Server an Userports wird verboten HTTP Zugriff auf Quarantäne / Remediation Server ist für Systeme immer erlaubt, der Rest nur

nach erfolgreichem Assessment Legacy Protokolle wie IPX oder anomaler Traffic wird direkt am Switchport verworfen Anwendungen wie Skype oder P2P können gedrosselt werden. Damit sucht die Applikation selbst

nicht permanent nach offenen Ports und ist dennoch limitiert. SIP Traffic wird ab dem Switchport mit den korrekten Quality of Service Informationen versehen Einzelne Flows können in ein anderes VLAN „geschoben“ werden, ohne dass der Client darauf

Einfluss hat oder dies bemerkt

Obwohl Policys schier unendliche Möglichkeiten und die höchste Granularität bieten, ist dies auch gleichzeitig ein Problem. Man muss zuvor sehr genau wissen, was erlaubt ist und was nicht. Vereinfacht wird die Administration allerdings durch ein rollen- und servicebasiertes Regelwerk, welches eine Wiederverwendung üblicher Definitionen vereinfacht. Leider besteht dieses Maß an Kontrolle zum jetzigen Zeitpunkt nur auf Enterasys Switchen und den In-Line NAC Appliances von Enterasys.

Sept 5, 2003 17Enterasys Confidential (Internal Only)

Dynamic Flow-based Packet Classification (DFPC)

Deny

Permit

Contain

Priority/QoS

Rate Limit

Access ControlLayer 2 MAC Address

EtherType (IP, IPX, AppleTalk, etc)

Layer 3 IP Address

IP Protocol (TCP, UDP, etc)

ToS

Layer 4 TCP/UDP port (HTTP, SAP, Kazaa, etc)

Layer 2 MAC Address

EtherType (IP, IPX, AppleTalk, etc)

Layer 3 IP Address

IP Protocol (TCP, UDP, etc)

ToS

Layer 4 TCP/UDP port (HTTP, SAP, Kazaa, etc)

Class of Service

Use

rP

ort

Matrix N-Series

Sw

itc

hF

low

VL

AN

€

Fazit: Diese Methode is weit verbreitet und genügt in vielen Bereichen den erfor-derlichen Ansprüchen. Nach-teilig ist der erhöhte Aufwand bei der Konzep-tionierung sowie beim Betrieb und Einschränkungen bei mehreren Systemen pro Port.

+ in vielen Switchen integriert + logische Isolierung vom Netz + standardisiert

- nicht verkehrsspezifisch- problematisch bei multiplen Systemen pro Port - teils umfangreiche Konfiguration


Ports sperren Dort wo Policys das Skalpel im Netzwerk sind, wäre die Schrotflinte ein passender Vergleich zu einer Portsperrung. Hier wird zwar das Endsystem ebenfalls vom Netzwerk getrennt, allerdings bestehen keinerlei Möglichkeiten einer späteren Remediation. Ebenso ist nicht festzustellen, ob das unerlaubte System noch mit dem Port verbunden ist oder nicht. Meistens wird hier der Port nach einiger Zeit wieder eingeschaltet, erneut geprüft und im Zweifel wieder geschlossen. Falls dies nicht passiert, besteht die Gefahr eines findigen Menschen, der alle Switchports nacheinander sperrt und weite Teile im Unternehmen lahm legen kann. Auch ist diese Methode denkbar ungeeignet, um multiple Geräte an einem Switchport zu handhaben. Immerhin beherrscht aber auch wirklich jeder Switch diese Methode, aber eine derart restriktive Beschränkung ohne Möglichkeit einer dynamischen Fehlerbehebung, ist in fast allen Fällen nicht zu empfehlen. Sie kommt dennoch bei einigen Out-of-Band Lösungen mit dynamischer Portkontrolle via SNMP oder Telnet / SSH zum Einsatz und sollte, wenn überhaupt, nur in sehr kleinen Bereichen verwendet werden.

Zusammenfassung In der Praxis werden 802.1x und andere Authentifizierungsverfahren in Kombination mit RFC 3580 (Port / VLAN Zuweisung) oder Policys, wo verfügbar, verwendet. In anderen Fällen kommen üblicherweise In-Line-Appliances zum Einsatz, die diese Funktionalität nachliefern. Vor dem Erwerb einer solchen Appliance sollte jedoch bedacht werden, ob nicht das Netzwerk in naher Zukunft sowieso aufgerüstet wird. Für den Einsatz einer solchen Appliance könnte allerdings auch der Sicherheitsbedarf sprechen, falls das Netzwerk keine Policys unterstützt und diese nachträglich mit einer solchen Lösung umgesetzt werden sollen. Eine solche Variante bietet sich für zentrale WAN Übergänge an, besonders wenn kein direkter Zugriff auf die Infrastruktur der Remote Sites besteht. Kontrollfragen zum Abschluss:

Wie granular soll autorisiert werden? Auf Port-, User-, Geräte- oder Traffic-Ebene? Soll alles verboten werden und nur explizit erlaubt oder umgekehrt? Wie kann eine Autorisierung multipler Geräte am Switchport realisiert werden?

€

€

Fazit: Die umfangreichste Methode des Enforcements stellen Policys dar. Hiermit lassen sich komplexe Zugriffs-rechte abbilden. Leider nicht auf jedem Switch verfügbar.

+ maximale Sicherheit + umfangreiche Optionen + erlaubt multiple Endsysteme + arbeitet pro Verkehrsstrom + hoher Zusatznutzen

- kein Standard

Fazit: Das sperren von Ports ist wirkung-svoll, bietet aber so gut wie keine Kontrolle. Es ist eine binäre Ent-scheidung, die in dynamischen, wachsenden Netzen mehr Probleme verursacht als Nutzen bringt.

+ in jedem Switch integriert + billig

- problematisch bei multiplen Systemen pro Port - stellt selbt ein Sicherheitsrisko dar für eine DoS Attacke - keine Remediation möglich


Remediation: „Aber, ...ich habe nichts gemacht!“ Nun ist das Kind in den Brunnen gefallen, keiner darf mehr in das Netz und alles ist ruhig. So kann natürlich NAC auch aussehen, ist aber nicht besonders förderlich für die Produktivität im Unternehmen. Natürlich können wir nicht einen Anstieg der Produktivität durch NAC garantieren, denn das liegt im Ermessen jedes Angestellten, aber die bestehende Produktivität sollte durch NAC zumindest nicht abfallen. Für diesen Fall gibt es das letzte große Kapitel im Projekt: Die Remediation. Bei der Remediation geht es darum ein Endsystem wieder in einen konformen Zustand zu bringen und damit bestehende Restriktionen im Zugang zum Netzwerk aufzuheben. Aus der Gewohnheit mag so manch Einer schon die Notwendigkeit zum Upgrade des User Helpdesks sehen, da alle in Zukunft nur noch mit der manuellen Remediation der Endsysteme beschäftigt sind. Natürlich ist dies nicht notwendig, allerdings benötigt es hierfür Möglichkeiten entweder Probleme automatisiert zu beheben oder den Benutzer in den Prozess mit einzubeziehen. Eine automatisierte Remediation ist fast nur mit einem Agenten umsetzbar, da in den meisten Fällen die Konfiguration geändert werden oder gar Dienste gestartet werden müssen, wie zum Beispiel die Firewall. Eventuell kann ein Softwaremanagement durch die NAC Lösung getriggert werden, um das Problem zu beheben. Bei einer manuellen Remediation bietet sich in der Regel ein Webserver an, auf den der Benutzer umgeleitet wird. Dies hat den Vorteil der zentralen Verwaltung und Möglichkeit zur einfachen Anpassung von Sprache, sowie dem Layout und der Corporate Identity. Möglich sind auch Emails, etc. Wichtige Inhalte eines solchen Portals sollten sein:

Angabe zum Zustand des Endsystems: Quarantäne, zugelassen... Angaben zu den einzelnen Verstößen: Firewall ausgeschaltet, Virensignaturen veraltet... Hinweise zur Lösung der Probleme: Firewall einschalten, Updateserver kontaktieren.. Hinweise, welche Zugänge erlaubt sind: Microsoft Update Server ... Link, um eine erneute Prüfung nach Behebung der Probleme zu starten

Eine Remediation lässt sich bei Endsystemen ohne Benutzereingriff oder Automatisierung so gut wie gar nicht ohne zusätzlichen administrativen Eingriff realisieren. Auf der anderen Seite sollten solche Systeme auch wesentlich weniger Änderungen unterworfen sein als ein normaler Client, auf dem zusätzliche Software installiert werden kann oder sonstiger Schabernack betrieben wird. In der Tat entscheidet eine gut implementierte Remediation darüber, wie viel Zusatzaufwand NAC im laufenden Betrieb bereitet, da dies den Löwenanteil im Troubleshooting auf den Benutzer oder die Agenten auslagert und somit viel Zeit sparen kann. Kontrollfragen zum Thema:

Wer führt die Remediation durch? Ein Agent, Benutzer oder ein Administrator? Wie lange dauert die Remediation und erneute Zulassung? Ist das Remediation Portal für jeden Benutzer zugänglich? Lässt sich das Portal an Anforderungen wie Sprache oder CI anpassen?


Monitoring: Der große Bruder Bislang haben wir nur die Prüfung des Endsystems im Pre-Connect-Zustand betrachtet. Doch wer garantiert, dass jemand nicht nachdem er Zugang erhalten hat Änderungen an seinem System vornimmt? Richtig - niemand. Glücklicherweise sind an dieser Stelle alle Werkzeuge vorhanden, um auch ein regelmäßiges Monitoring durchzuführen – auch zusätzlich zur wiederkehrenden Prüfung der Pre-Connect-Parameter. Wichtig ist hierbei die Frage: „Wann?“. Je nach verwendeter Methode sollten unterschiedliche Intervalle für nachfolgende Prüfungen verwendet werden. Ein Agent kann ohne Schwierigkeiten Prüfungen im Minutentakt durchführen, wohingegen ein Netzwerkscan sicherlich nicht in dieser Häufigkeit verwendet werden sollte. Darüber hinaus sollten hier generell umfassende Konfigurationsmöglichkeiten bestehen, um unterschiedlichen Anforderungen innerhalb eines Netzwerkes gerecht zu werden. Die NAC Lösung sollte flexibel nach einer wiederverwendbaren Vorlage arbeiten, um den administristrativen Aufwand möglichst gering zu halten. Außerdem ist ein solches Vorgehen wesentlich transparenter bei Problemen und der Fehlersuche. Einige Parameter, die in der Planung berücksichtigt werden sollten, sind:

Soll bei vor jedem Zugang geprüft werden? (unabhängig von zuvor erfolgreichen Tests) Nach welchem Intervall muss spätestens geprüft werden? (z.B. eine Woche) In welchen Abständen soll der Agent das lokale System prüfen? In welchen Abständen soll der Agent seine Ergebnisse weiterleiten? Darf der Client während der Prüfung verbunden bleiben oder wird er immer zuerst in Quarantäne

versetzt?

Aber nicht nur die Assessment Funktionalitäten von NAC selbst sollten an dieser Stelle genutzt werden. NAC eignet sich hier als ideale Ergänzung zu Behaviour und Anomaly Based Security. Solche Systeme werten in der Regel Flowdaten aus und erkennen damit Angriffe auf Layer 3-7, können jedoch diese nicht auf die physikalische Infrastruktur abbilden. Eine solches Monitoring kann hier in NAC integriert werden, um ein effektives und granulares Schutzkonzept umzusetzen und das Beste aus beiden Welten zu vereinen. Je offener die Schnittstellen der NAC Lösung (z.B. der Automated Security Manager von Enterasys) sind und je mehr Sicherheitssysteme sich diese zu Nutze machen können, umso größer ist der dabei entstehende Nutzen. Eine andere denkbar ähnliche Konstellation ist die Nutzung von Intrusion Detection Systemen zusammen mit NAC, um eine möglichst performante Erkennung von Angriffen (im Gegenzug zu Intrusion Prevention Systemen) zu erzielen und dennoch ein wirksames Mittel für eine automatisierte Gegenwehr zu haben.

Beyond: Die Welt hinter dem Spiegel Leider ist es fast immer so, dass Security allein nicht immer der ausschlaggebende Punkt ist, um ein Projekt umzusetzen. Daher stellt sich im Zusammenhang mit Projekten in diesem Bereich die Frage, welche Vorteile für die tägliche Arbeit sonst noch entstehen können. Gerade bei NAC ist diese Frage durchaus berechtigt, da hier unter anderem viele Daten gesammelt werden und auch Informationen in Echtzeit vorliegen, die zuvor nur mühsam manuell gesucht werden mussten. Der Prozess an sich birgt ebenfalls Vorteile, da hiermit Probleme schon direkt ausgeschlossen werden können, die vielleicht nicht sicherheitskritisch sind, aber besonders viele Ressourcen binden, wenn es um das Troubleshooting geht. Es lohnt sich sehr bei der Auswahl der geeigneten NAC Lösung einen genauen Blick auf verfügbare Schnittstellen und Integrationsmöglichkeiten zu beliebigen anderen Produkten zu werfen. Im Folgenden


nennen wir ein paar bereits verfügbare Beispiele, prinzipiell ist dies aber nur ein Denk-anstoß und sollte dazu verleiten mögliche Synergien zwischen der eigenen Infrastruktur und NAC zu erkennen.

NAC und VoIP Voice over IP stellt als Technologie einige Ansprüche an das Netzwerk. Dies bezieht sich besonders auf die Lokalisierung und Priorisierung der Endgeräte. Diese Ansprüche an sich umzusetzen ist schon schwierig, werden jedoch fast unmöglich in großen Umgebungen mit vielen Änderungen und bei mobilen Telefonen an und für sich. NAC kann hier einen großen Dienst leisten und aktuelle Infrastrukturdaten in Echtzeit zur Verfügung stellen sowie (z.B. mit Policys) eine besondere Handhabung bei der Priorisierung der Endgeräte ab dem Switchport durchsetzen. Ein weiteres großes Problem bei VoIP Telefonen ist die Lokalisierung in Echtzeit (z.B. für die Bestimmung / Ortung bei Notrufen). Hier existieren schon jetzt Lösungen einer Intergration von NAC und VoIP Management Diensten, die es ermöglichen eine solche Herausforderung zu bewältigen. Weitere Vorteile ergeben sich aus Funktionalitäten wie einer automatischen Rufum-leitung oder einer kompletten Rekonfiguration je nach Standort. Auf der anderen Seite ermöglicht es die Integration des VoIP Managements in NAC, Telefone vorab zu kennen und somit die Konfiguration von NAC erheblich zu erleichtern.

NAC und die Security Infrastruktur So gut wie jedes Unternehmen setzt heutzutage zumindest eine Firewall ein. In vielen weiteren Fällen existieren Intrusion Detection / Prevention Systeme, Application Layer Gateways oder gar Security Information und Event Management Systeme. Diese Systeme erkennen in der Regel zuverlässig Angriffe auf das oder im Netzwerk. Allerdings besteht hier immer die Beschränkung, dass Gegenmaßnahmen nur am jeweiligen System selbst durchgeführt werden können. So erkennt eine Firewall unerlaubt Zugriffe auf bestimmte Ressourcen und kann auch diese unterbinden, jedoch kann sie nichts gegen den Verursacher an sich ausrichten. An dieser Stelle kommt NAC mit zwei Funktionalitäten ins Spiel. Einerseits können die Daten zur Identität an andere Systeme weitergereicht werden. Dies vereinfacht die Nutzung eines Security Management Systems erheblich, da dort zusätzlich nun Informationen zur Lokation, Verbindungstyp, Benutzer und Sicherheitszustand des Endgerätes zur Verfügung stehen. Somit wird ein zentraler Punkt geschaffen an dem alle Informationen auf einen Blick zur Verfügung stehen. Andererseits bietet NAC die wirkungsvollste Gegenmaßnahme. Wenn ein Endgerät abnormales Verhalten aufweist oder gar einen Angriff ausführt, kann die Zugangsberechtigung entzogen werden und somit eine höchst präzise Gegenmaßnahme umgesetzt werden.

NAC und virtuelle Server Cluster und virtuelle Server werden in Netzwerken immer beliebter. Besonders, da eine dynamische Umverteilung der Software auf die Hardware eine optimale Auslastung und Flexibilität garantiert. Jedoch sind Netzwerke meist nicht so flexibel und es ist umständlich Konfigurationen (z.B. Priorisierung von Daten) manuell anzupassen. Noch schwieriger wird dies, falls virtuelle Systeme automatisch „umziehen“ – z.B. bei einem Hardware Ausfall. Damit auch das Netzwerk beim typischen Drag-and-Drop Verhalten mithalten kann, bietet NAC mit der Lokalisierung der Server einen einfachen Weg, Rekonfigurationen im Netzwerk zu automatisieren. Obwohl NAC eigentlich eine Lösung ist, die Endsysteme im Auge behalten soll und mit den Servern meist wenig zu tun hat, so kann dennoch diese Funktionalität sinnvoll sein.

NAC und das User Helpdesk Sobald Probleme im Netzwerk auftreten, gilt es diese zu lokalisieren. NAC bietet hier eine zentrale Datenbank, die für die eindeutige Identifizierung, den Zustand und den Benutzer des Endsystems herhalten kann. Idealerweise sollte die NAC Lösung auch Reportingmöglichkeiten der Assessment Informationen bieten und so historische Daten zu allen Endsystemen zur Verfügung stellen. Durch den Einsatz von Policys lassen sich viele Probleme sogar sofort im Keim ersticken, da unerwünschte Protokolle im Netzwerk direkt am Switchport abgefangen werden können und sich so nicht weiter ausbreiten.


Schlusswort Wir hoffen hiermit das große, unbekannte Biest „NAC“ etwas entmystifiziert und einige Denkanstöße für die eigene NAC Implementierung gegeben zu haben. NAC an sich ist kein besonders schwieriges Projekt, da es sich in einfache Bausteine zerlegen lässt, die zwar nacheinander abgehandelt werden sollten, jedoch keinen knappen zeitlichen Rahmen technisch erforderlich machen. Der Erfolg eines NAC Projektes hängt schlicht und ergreifend von der Planung zu Beginn ab. Je mehr Informationen vorliegen und je genauer die Definition von Rollen und Rechten ist, umso stressfreier ist die eigentlich Implementierung im Nachgang. Viele NAC Projekte scheitern aufgrund der mangelnden Planung, weil man einfach einmal loslegt und im Verlauf über all die Probleme stolpert, die in diesem Leitfaden angesprochen wurden. Im Anhang befinden sich hierzu noch einige Beispiele für mögliche Planungs- / Checklisten. Natürlich können diese auch noch durch individuelle Informationen angereichert werden. Es empfiehlt sich in jedem Fall ein kleine, repräsentative Testumgebung zu erstellen und anhand dieser das Konzept im Kleinen vorab zu evaluieren. Im Übrigen ist es ein Irrglaube zu meinen, dass man für so etwas wie NAC „zu klein“ ist oder das Netz sowieso überschaubar ist. Es ist wesentlich einfacher NAC mit einem Netz wachsen zu lassen, als es später in einem großen Netz komplett neu einzuführen. Trotzdem sollte man in all seiner Planung den wichtigsten aller Punkte niemals außer Acht lassen: Keep it simple ! Vielen Dank


Anhang A: Beispiel Checkliste Rollen / Rechte Gruppe Rolle Rechte Ressourcen Orte

Vertrieb Sales SAP, Mail, Internet Sales Server Vertriebsbüro Marketing Sales SAP, Mail, Internet Marketing Server Marketingbüro Administrator Allow All Uneingeschränkt Uneingeschränkt Uneingeschränkt Gast Guest Internet Keine Besprechungsräume Quarantäne Quarantine Nur Remediation Keine Überall

Anhang B: Beispiel Checkliste Infrastruktur Gerätetyp Standort VLAN Authentifizierungs-

möglichkeiten Assessment-möglichkeiten

PC Vertrieb 2 802.1x, WPA, MAC Agent, Netzscan PC Marketing 3 Kerberos, MAC Agent, Netzscan PC Administrator 4 802.1x, WPA, MAC Agent, Netzscan Server Vertrieb 5 802.1x, MAC Agent, Netzscan VoIP Vertrieb 6 802.1x, MAC Netzscan

Anhang C: Beispiel Checkliste Assessment Checks Gerätetyp Rolle Typ Checks

PC Vertrieb Agent Firewall, Antivirus, Patchlevel PC Marketing Agent Firewall, Antivirus, Patchlevel VPN VPN Agent Firewall, Antivirus, Patchlevel, Schadsoftware Server Vertrieb Netzscan Portscan, Vulnerability Scan, Password Guessing VoIP Vertrieb Netzscan Portscan, Vulnerability Scan (alles) Laptop Gast Netzscan Portscan, Vulnerability Scan (ohne DoS)

Anhang D: Beispiel Checkliste Reporting Information Zeitplan Empfänger Bemerkungen

Authentifizierte Systeme Täglich Administratoren Mit Angabe der Methode Quarantänesysteme Täglich Administratoren Mit Angabe des Grundes Top 10 Vulnerabilities Wöchentlich Security Officer Weitergabe Geschäftsleitung Anzahl VoIP Phones Monatlich Administratoren Nach Hersteller Gastzugänge Wöchentlich Security Officer Mit Dauer, Sponsorinformation Geräte nach Lokation Monatlich Administratoren Unterteilt in Gerätetypen

Documents

N A Control Best Practice Guide - all-about-security.de · (PORT) VLAN ZUWEISUNG ... (oder auch Gruppen) zu übernehmen und als Basis für das NAC Konzept zu verwenden. Ein Verzeichnis-dienst