Suchen

Netzwerk-Grundlagen – Policy Enforcement, Teil 1 Policy Enforcement auf Basis von RFC 3580 und Multi-User Authentication

Autor / Redakteur: Markus Nispel / Stephan Augsten

Die eindeutige Authentisierung eines Gerätes und/oder Users ist ein wichtiger Teil der Access Control, denn sie bilden die Grundlage fürs Policy Enforcement. Bevor wir und der Durchsetzung von Richtlinien in der Praxis widmen, betrachten wir in diesem Beitrag die verschiedenen Authentisierungsmechanismen am Beispiel der Security-Lösungen von Enterasys.

Firma zum Thema

Um Richtlinien für bestimmte Anwender und Geräte durchzusetzen, muss man um die verschiedenen Möglichkeiten der Authentisierung wissen.
Um Richtlinien für bestimmte Anwender und Geräte durchzusetzen, muss man um die verschiedenen Möglichkeiten der Authentisierung wissen.
( Archiv: Vogel Business Media )

Auf Basis der Authentisierung eines Gerätes und/oder Benutzers gilt es Regelwerke zuzuweisen, die den Zugang mit allen Rechten und Einschränkungen kontrollieren. Bereits die unterschiedlichen Authentisierungsmöglichkeiten zeigen auf, welche differenzierte Vertrauensstellung hier abzubilden ist.

RFC 3580 – Der kleinste gemeinsame Nenner?

Die nähere Betrachtung zeigt, dass die verbreitete Methode aus dem Authentisierungsergebnis eine VLAN-Zuweisung (RFC 3580) abzuleiten, zahlreiche Unzulänglichkeiten birgt. Allein die Notwendigkeit, einen Campus mit weit verzweigten Layer-2-Segmenten zu überziehen, widerspricht dem allgemeinen Trend hin zu gerouteten Segmenten.

Bildergalerie

Eine Usergruppen-/VLAN-Assoziierung generiert in der Praxis mindestens eine umfangreiche Gruppe von Standardusern, vor welchen zwar der Netzwerkkern durch entsprechende Accesslisten geschützt wird, die jedoch untereinander frei und hemmungslos kommunizieren können.

Ist eines dieser Endsysteme durch Schadsoftware kompromittiert, so ist die gesamte Gruppe einer Verbreitung ausgesetzt. Daher wäre es wünschenswert, bereits am ersten Access Port zu entscheiden, welche Informationen überhaupt in das Ökosystem Netzwerk eingespeist werden dürfen.

Policies – Regeln am Rand der Zivilisation

Diese Idee führt tief in die Historie des Enterasys-Vorläufers Cabletron Systems. Bereits mit der zweiten Generation der SmartSwitch-Familie wurde in den späten 90er Jahren die dezidierte Frame-Klassifizierung etabliert. Die Idee, einen Layer-2-Switch zu einer Layer-2/3/4-Analyse zu bewegen, war zu jener Zeit aus Priorisierungsanforderungen mit Blick auf zeitkritische Applikationen wie Voice und Video heraus geboren.

Später wurde klar, dass die Unterscheidung verschiedener Protokolle am Access Port die erste Grundlage darstellt, um unerwünschte Dienste und Protokolle einfach zu verwerfen. Die Idee einer skalierbaren, verteilten Sicherheitsarchitektur eines Netzwerkes hatte etwas Faszinierendes.

„Das Konzept von Zugriffsregeln im Accessbereich hat lediglich akademischen Wert. In der Praxis ist diese Aufgabe zu komplex, um administriert zu werden.“ Diese Aussage eines namhaften Herstellers von Netzwerk-Komponenten bringt es auf den Punkt. Das Pflegen verteilter Zugriffsinformationen mit Bordmitteln ist eine Aufgabe, vor welcher jeder Administrator zurückschrecken wird.

Inhalt

  • Seite 1: Policies – Regeln am Rand der Zivilisation
  • Seite 2: Policy Management nach dem Baukasten-Prinzip
  • Seite 3: Multi-User Authentication and Policy (MUA+P)
  • Seite 4: Sichere Gastfreundschaft mit Default Policies
  • Seite 5: RFC 3580 und Distribution Layer Security

Policy Management nach dem Baukasten-Prinzip

Bereits im Jahre 2001 stellte Enterasys Networks mit dem Enterasys NMS Policy Manager ein Werkzeug vor, mit welchem das Erstellen und Verbreiten komplexer Regelwerke zu einem Baukastenspiel wird. Der Schlüssel liegt in einer dreistufigen Hierarchie:

Policies - Hierarchisches Regelwerkzeug. (Archiv: Vogel Business Media)

Die oberste Ebene definiert sich zunächst aus der Rolle, die ein Benutzer in der Struktur des Unternehmens selbst spielt. Da sich diese Rolle bereits in den Regelwerken des Usermanagements einer zentralen Betriebssystemplattform abzeichnet, liegt es nahe, bereits bei der Authentisierung auf diese Informationen zuzugreifen.

Unterhalb dieser Ebene sind die Services definiert, welche bereits im Groben beschreiben, was der Benutzer tun darf – und was nicht. Diese Services setzen sich nun aus einzelnen Regeln zusammen, die den Datenverkehr zunächst nach Kriterien der Layer 2, 3 und 4 klassifizieren.

Trifft die Regel zu, so wird eine zugewiesene Aktion ausgeführt:

  • Access Control – zulassen oder verwerfen
  • Tagging des Frames mit einer definierten VLAN ID
  • Redefinition von Quality of Service Parametern
  • Rate Limiting (Port, Applikations-Flow, Protokoll, Nutzer - IP oder MAC)

Mittels des Policy Managers ist es nun möglich ein solches Konstrukt aus Rollen und Regeln zusammenzustellen und per SNMP auf allen Netzwerkkomponenten bekannt zu machen. Die flächendeckende Bereitstellung von Zugriffsinformationen im Access-/Distributionbereich ist ein Garant für Skalierbarkeit einer solchen Lösung.

Granularität der Secure Networks Policies. (Archiv: Vogel Business Media)

Wie hier dargestellt, liegt die Stärke von Policy Enforcement bei Secure Networks in der Kombination aus Authentisierung, Klassifizierung und Kontrolle. Mit diesen Maßnahmen ist es nun möglich einem breiten Spektrum von Bedrohungen zu begegnen, wie die in der Bildergalerie hinterlegte Tabelle beispielhaft aufzeigt.

Inhalt

  • Seite 1: Policies – Regeln am Rand der Zivilisation
  • Seite 2: Policy Management nach dem Baukasten-Prinzip
  • Seite 3: Multi-User Authentication and Policy (MUA+P)
  • Seite 4: Sichere Gastfreundschaft mit Default Policies
  • Seite 5: RFC 3580 und Distribution Layer Security

Multi-User Authentication and Policy (MUA+P)

Kombination von Access Control und Policy Enforcement. (Archiv: Vogel Business Media)

Die bisher aufgezeigte Kommunikationskette für den Authentisierungsprozess wird nun also um die Management-Funktion erweitert, mit deren Hilfe Rollen und Regeln verteilt werden.

Nun gibt das zentrale Verzeichnis neben der positiven Authentisierungsbestätigung auch die Gruppenmitgliedschaften des Benutzers an den RADIUS-Server zurück. Mittels eines kleinen Filterwerks ermittelt dieser die relevante Gruppe, deren Name dem Switch nun als Schlüssel dient, um dem Port die entsprechende Policy zu zu weisen.

Die Authentisierungsmethode wird also lediglich um eine Filter-ID erweitert, alle weiteren Funktionen führt die verteilte Netzwerkarchitektur selbsttätig aus. Das an sich sehr schlanke Standard-RADIUS Protokoll bietet damit die Grundlage für eine hoch skalierbare Gesamtlösung.

Im Kontext heterogener Netze, in welchen nicht alle Accesskomponenten den Einsatz von Policies unterstützen, ist es, wie bereits beschrieben, notwendig mehrere Benutzer an einem Port des nachgeschalteten Distributionlayers zu authentisieren. Die Flexiblität der N-Serie Switche erlaubt nun eine Kopplung der benutzerabhängigen Policy an die jeweils involvierte MAC Adresse.

(Archiv: Vogel Business Media)

Diese Grafik verdeutlicht das Konzept der so genannten Distribution Layer Security. Diese Technik erlaubt die Integration

  • unterschiedlicher Benutzer (bis zu 256)
  • unterschiedlicher Authentisierungsmethoden (802.1x, MAC, PWA, CEP)
  • unterschiedlicher Regelwerke (Policies)

am selben Uplinkport.

Inhalt

  • Seite 1: Policies – Regeln am Rand der Zivilisation
  • Seite 2: Policy Management nach dem Baukasten-Prinzip
  • Seite 3: Multi-User Authentication and Policy (MUA+P)
  • Seite 4: Sichere Gastfreundschaft mit Default Policies
  • Seite 5: RFC 3580 und Distribution Layer Security

Sichere Gastfreundschaft mit Default Policies

Gäste spielen eine wachsende Rolle in Netzen, deren Mobilitätsanforderungen kontinuierlich ausgebaut werden. Schüler und Studenten, Besucher, Wartungstechniker oder einfach Mitarbeiter fremder Firmen, die manchmal über lange Zeiträume im Unternehmen präsent sind – sie alle haben den Anspruch, an den Ressourcen der IT-Infrastruktur teilzuhaben. Ein Horrorszenario für jeden Administrator! Der Balanceakt, einerseits diesem Bedarf nachzukommen ohne andererseits die Sicherheitsrichtlinien des Unternehmens zu kompromittieren, stellt eine echte Herausforderung dar.

Ein Teil der genannten Personengruppen lässt sich organisatorisch registrieren und technisch mittels Webauthentication und einer restriktiven Policy in das Sicherheitskonzept integrieren. Für die oft große Zahl sporadischer Besucher ist dieser Aufwand unangemessen hoch. Eine einfache Lösung muss her, die ohne Eingriff des Administrators funktioniert.

Den Schlüssel hierzu stellt die Default Policy dar. Sie erlaubt einem nicht-authentisierten Benutzer den minimalen Zugriff auf die Netzwerkinfrastruktur. Eine solche „soziale Grundversorgung“ definiert sich beispielsweise über den Zugriff auf VPN-, HTTP-, DHCP- und DNS-Services sowie dem Zugang zum Webproxy des Unternehmens. Ein Rate Limiting begrenzt die nutzbare Bandbreite und verhindert exzessiven Gebrauch.

Der Gast erhält also an jedem freigegeben Port Basisdienste, ist jedoch von den internen Ressourcen der IT-Infrastruktur eindeutig ausgeschlossen. Aber auch andere Szenarien lassen sich über Default Policies abbilden. Softwareverteilung findet regulär außerhalb der Bürozeiten statt. Eine angepasste Default Policy stellt den Zugriff eines Updateservers auf das Endgerät auch dann sicher, wenn der Benutzer nicht angemeldet ist.

Fazit: Default Policies schaffen die nötige Flexibilität in einem sicheren Netzwerk, um Nischenszenarien zu ermöglichen ohne die Security durch manuelle Schaffung von Ausnahmen und Lücken zu kompromittieren.

Inhalt

  • Seite 1: Policies – Regeln am Rand der Zivilisation
  • Seite 2: Policy Management nach dem Baukasten-Prinzip
  • Seite 3: Multi-User Authentication and Policy (MUA+P)
  • Seite 4: Sichere Gastfreundschaft mit Default Policies
  • Seite 5: RFC 3580 und Distribution Layer Security

RFC 3580 und Distribution Layer Security

Die Einführung flächendeckender Netzwerk Security in heterogenen Netzen stellt den Administrator, wie bereits beschrieben, vor eine Reihe spannender Herausforderungen. Gerade im Bereich der Low-Cost Switche hat sich das Prinzip der User/VLAN-Zuordnung gemäß Standard RFC 3580 weitgehend etabliert. Daher soll dieses Thema nochmals eingehender mit Fokus auf eine Secure-Networks-Integration beleuchtet werden.

User/VLAN-Zuordnung gemäß RFC 3580. (Archiv: Vogel Business Media)

RFC 3580 ist eine Methode, welche der Authentisierungsantwort des RADIUS-Servers eine VLAN-ID beifügt, anhand welcher der Switch dem Userport ein entsprechendes VLAN zuweist. In diesem Abschnitt soll beleuchtet werden, wie sich derartige Komponenten in eine policybasierte Lösung integrieren lassen.

Enhanced Policy mit RFC 3580. (Archiv: Vogel Business Media)

In dem abgebildeten Beispiel agiert der Distribution Layer Switch vom Typ N-Serie N7 nicht als Authentisierungsinstanz, sondern weist den eingehenden Frames anhand der VLAN-ID eine entsprechende Policy zu.

Damit reduziert sich das Risiko unkontrollierter Client-zu-Client Kommunikation auf den Bereich des VLANs innerhalb des einzelnen Access Switchs. Auch das VLAN-to-Role Mapping lässt sich an zentraler Stelle im Policy Manager konfigurieren und flächendeckend an alle Switches kommunizieren (siehe Bild 2 der Bildergalerie).

Port Protection

Im Gegensatz zum Policy Enforcement direkt am Access Port verbleibt bei allen Szenarien der Distributed Layer Security ein Restrisiko, da die Access Control erst in der nachgelagerten Instanz ausgeführt wird.

Um diese Lücke zu schließen, haben die Entwickler von Enterasys die Funktionalität des Cabletron ELS10-27MDU (Multiple Dwelling Unit) den neuen Anforderungen angepasst und in das Portfolio der A/B/C-Serie integriert.

Port Protection (Archiv: Vogel Business Media)

Das Port-Protection- oder Private-VLAN-Feature, welches Datenaustausch nur in Richtung definierter (Uplink-) Ports zulässt, leitet die gesamte Kommunikation des Switchs direkt in die Distribution Zone und das Regelwerk der Policies. Diese Schutzmaßnahme bewahrt die Enduser vor unkontrolliertem Verkehr innerhalb des Switchs/VLANs.

Über den Autor

(Archiv: Vogel Business Media)

Markus Nispel ist als Vice President Solutions Architecture zuständig für die strategische Produkt- und Lösungsentwicklung bei Enterasys. Sein Fokus liegt auf dem Ausbau der Sicherheits- und dort insbesondere der Network-Access-Control-Lösung (NAC) von Enterasys; hier zeichnet er als Architekt verantwortlich. Diese Position knüpft an seine vorherige Tätigkeit bei Enterasys als Director Technology Marketing an. Bereits hier war er intensiv in die weltweite Produktentwicklung und -strategie von Enterasys im Office des CTO involviert. Darüber hinaus berät er Key Accounts in Zentraleuropa, Asien und dem mittleren Osten bei strategischen Netzwerkentscheidungen und verantwortet die technischen Integrationsprojekte zwischen Enterasys und der Siemens Enterprise Communications Group.

In Zentraleuropa und Asien verantwortet er zudem das Security Business Development und steht mit einem Team an Security Spezialisten für die Implementierung von Security Projekten mit höchsten Anforderungen bereit.

Vor seiner Tätigkeit für Enterasys Networks war Markus Nispel als Systems Engineer bei Cabletron Systems aktiv. Hier führte er 1998 die ersten Layer 3 Switches für den europäischen Kundenstamm ein.

Markus Nispel studierte an der Fachhochschule der Deutschen Telekom in Dieburg und schloss sein Studium 1996 als Dipl.-Ing. Nachrichtentechnik erfolgreich ab. Erste Berufserfahrung sammelte er unter anderem bei der E-Plus Mobilfunk GmbH innerhalb der Netzwerkoptimierungsgruppe für DCS Mobile Networks.

Inhalt

  • Seite 1: Policies – Regeln am Rand der Zivilisation
  • Seite 2: Policy Management nach dem Baukasten-Prinzip
  • Seite 3: Multi-User Authentication and Policy (MUA+P)
  • Seite 4: Sichere Gastfreundschaft mit Default Policies
  • Seite 5: RFC 3580 und Distribution Layer Security

(ID:2046686)