DIPLOMARBEIT. Netzwerksicherheit im Accesslayer mit benutzerabhängigen Policies

Transkript

1 DIPLOMARBEIT Netzwerksicherheit im Accesslayer mit benutzerabhängigen Policies durchgeführt am Studiengang Informationstechnik und System Management an der Fachhochschule Salzburg vorgelegt von: Michael Messner Studiengangsleiter: Betreuer: FH-Prof. DI Dr. Thomas Heistracher DI(FH) Karl Pracher Salzburg, Juni 2007

2 Eidesstattliche Erklärung Hiermit versichere ich, Michael Messner, , dass die vorliegende Diplomarbeit von mir selbständig verfasst wurde. Zur Erstellung wurden von mir keine anderen als die angegebenen Hilfsmittel verwendet. Messner Michael Matrikelnummer ii

3 Danksagung Potential intruders are in what military strategists call the position of the interior : the defender has to defend against every possible attack, while the attacker has to find only one weakness. Bruce Schneier ( ) An dieser Stelle möchte ich mich bei all jenen Bedanken die mich im Rahmen meines Studiums und ganz speziell in der Zeit meiner Diplomarbeit fachlich, wie persönlich unterstützt haben. Ganz spezieller Dank gilt meiner Familie, die mich während des ganzen Studiums immer sehr positiv unterstützt hat. Im Rahmen dieser Diplomarbeit ist mir Harald Zwerschina von Enterasys Secure Networks mit seinem Wissen ebenso wie mit einem policyfähigen Switch für die Testumgebung zur Seite gestanden. Vielen Dank dafür. Für die tolle Zusammenarbeit während der Diplomarbeit gilt mein besonderer Dank meinem Studienkollegen Harald Zauner und meinem Betreuer Karl Pracher. iii

4 Informationen Vor- und Zuname: Institution: Studiengang: Titel der Diplomarbeit: Betreuer an der FH: Michael Messner Fachhochschule Salzburg GmbH Informationstechnik & System-Management Netzwerksicherheit im Accesslayer mit benutzerabhängigen Policies DI(FH) Karl Pracher Schlagwörter 1. Schlagwort: Policy 2. Schlagwort: AAA 3. Schlagwort: Radius 4. Schlagwort: Enterasys Abstract This diploma thesis reviews the different technologies and standards that are of importance for a policy-based network security concept. The AAA-framework and the radius protocol allows an authentication concept with dynamical and policy-based access control to be created. Based on a thorough consideration of various security solutions of well-known manufacturers, a policy-based security concept in a heterogeneous test network environment has been implemented. In order to guarantee the future extensibility of the implementation, a central management and the usage of free tools was of high importance. iv

5 Inhaltsverzeichnis Eidesstattliche Erklärung Danksagung Informationen Schlagwörter Abstract Abbildungsverzeichnis Tabellenverzeichnis ii iii iv iv iv viii ix 1 Einleitung 1 2 Grundlagen Hierarchische Netzwerkmodelle Verbreitete Netzwerkmodelle Drei Schichten Modell Access-Layer Sicherheit AAA-Framework Authentication Authorization Accounting Drei Parteien-Authentifizierungsmodell Extensible Authentication Protocol Authentifizierungsserver v

6 x Radius Eigenschaften des Radiusprotokolles Sicherheitsüberlegungen zum Radiusprotokoll Unterschiedliche Radiusserver Diameter Policies Analyse Cisco-Systems Network Admission Control Cisco Security Monitoring, Analysis and Response System Enterasys Secure Networks Policybasiertes Authentifizierungssystem Sentinel-Sichere Endsysteme Dragon-Intrusion Defense Implementierung Versuchsaufbau Topologieplan Topologieelemente Durchführung Beschreibung der Policies Radiusserver Absicherung des Radiusservers Weitere Möglichkeiten Pluggable Authentication Modules FTP-Radius Lokaler Login Endsystem-Anbindung Weitere Dienste Technische Ergebnisse 63 vi

7 6 Schlussfolgerungen 65 Literaturverzeichnis 66 Abkürzungsverzeichnis 69 Anhang 73 A Konfigurationen 74 A.1 FreeRADIUS-Konfigurationen A.1.1 radiusd.conf A.1.2 eap.conf A.1.3 clients.conf A.1.4 huntgroups A.1.5 users A.1.6 Daemontools run-datei A.1.7 chkrootkit Cronjob A.2 Policy-Manager Konfiguration A.3 Enterasys Matrix-Switch Konfiguration A.4 VPN-Gateway A.5 WLAN-Router vii

8 Abbildungsverzeichnis 2.1 Das hierarchische Zwei-Schichtenmodell [28] Das hierarchische Drei-Schichtenmodell [28] Core-Layer redundant [28] Zwischenfälle durch externe und interne Angreifer verursacht [19] Authentication-Beispiel [6] Authorization-Beispiel [6] Accounting-Beispiel [6] Drei Parteien-Authentifizierungssystem (adaptiert aus[21]) EAP Mitteilungen in AAA-Protokollen gekapselt (adaptiert aus [21]) x-portbasierte Authentifizierung [18] Network Admission Control Komponenten[5] Enterasys Single Sign On-Authentifizierungssystem (adaptiert aus [24]) Arbeitsweise von Sentinel (adaptiert aus [13]) Überblick über Dragon Intrusion Defense [26] Anwendungsbeispiel von Dragon [24] Netzwerktopologie der Teststellung A.1 Portübersicht im Policy-Manager A.2 Einrichten einer Defaultpolicy A.3 Aktivieren einer Defaultpolicy A.4 WLAN-Policy A.5 WLAN-Policy A.6 Radiusanbindung einer m0n0wall A.7 Radiusanbindung des Linksys WLAN Routers viii

9 Tabellenverzeichnis 2.1 Auszüge der EAP-Methoden aus [21] Vorteile von Diameter (adaptiert von [8]) Unterschiede zwischen Radius und Diameter (adaptiert aus [8]) ix

10 1 Einleitung In heutigen Netzwerken spielt Sicherheit eine tragende Rolle. Der reibungslose Betrieb muss gewährleistet sein, während die Anwender durch Sicherheitsvorkehrungen nicht bei der Arbeit behindert werden dürfen. Dies stellt die Verantwortlichen im Bereich der Informationstechnologie (IT) vor neue Herausforderungen, einerseits soll den Anwendern vertraut werden und andererseits muss die betreute IT-Infrastruktur vor Fehlbedienung ebenso wie vor böswilliger Zerstörungswut der eigenen Mitarbeiter oder auch Fremder geschützt werden. Der Benutzer darf somit keine Berechtigungen im Netzwerk besitzen, die es ermöglichen, gewollt oder ungewollt, Schaden zu verursachen. Durch unternehmensweite Security-Policies lässt sich zentral ein Berechtigungsmodell definieren, welche Berechtigungen die unterschiedlichen Benutzergruppen besitzen. Aufgrund von Authentifizierungsmechanismen soll es möglich sein, dem Benutzer individuell definierte Rechte im Netzwerk automatisiert zuzuordnen. Durch diese definierten Rechte soll es beispielsweise nicht mehr möglich sein, nicht-authorisierte Dynamic Host Control Protocol (DHCP)-Server zu betreiben oder bekannte Schadsoftware im Netzwerk zu verbreiten. Des Weiteren lassen sich ungewollte oder auch unsichere Protokolle durch Portsperrung am ersten Zugriffspunkt aus dem Netzwerk verbannen, andere wie beispielsweise Voice over IP (VoIP) lassen sich durch Quality of Service (QoS) höher priorisieren. Um das vollständige Netzwerk effektiv zu schützen, müssen diese Rechte bereits beim ersten Zugriffspunkt, dem Access-Switch, angewandt werden. Durch diese Anwendung des Berechtigungsmodells am ersten Netzwerkzugriffspunkt wird ein ausfallsicherer Netzwerkbetrieb gewährleistet. 1

11 1. Einleitung 2 Im folgenden Kapitel werden die technischen Hintergründe wie hierarchisches Netzwerkmodell, AAA (Authentication, Authorization, Accounting)-Framework und Policies genauer erläutert. Mit diesem Hintergrund lassen sich anschließend in Kapitel 3 unterschiedliche Sicherheitslösungen renommierter Hersteller evaluieren. Anschließend wird in Kapitel 4 die Implementierung der policybasierten Netzwerkauthentifizierungslösung von Enterasys Secure Networks in einem praxisnahen Testnetzwerk durchgeführt. Im Rahmen dieser Implementierung wird auf zusätzliche Sicherheitsaspekte des Authentifizierungsservers ebenso eingegangen wie auf zukünftige Erweiterbarkeit in Bereich Single Sign On. Zum Abschluss dieser Arbeit erfolgt eine Zusammenfassung mit persönlichen Kommentaren zu dem Thema der policybasierten Netzwerksicherheit.

12 2 Grundlagen In Kapitel 2 werden die wichtigsten theoretischen Bereiche wie das hierarchische Netzwerkmodell, das AAA-Framework und Authentication-Server behandelt. In Kapitel 4 werden diese Grundlagen bei einer Implementierung der in Kapitel 3 vorgestellten policybasierten Sicherheitslösung, von Enterasys Secure Networks, praktisch umgesetzt. 2.1 Hierarchische Netzwerkmodelle In modernen Netzwerken werden in erster Linie hierarchische Netzwerkmodelle, wie in Abbildung 2.1 oder in Abbildung 2.2 ersichtlich, verwendet. Im Gegensatz zu einem flachen oder vermaschten Netzwerkmodell zeichnet sich das hierarchische Netzwerkmodell durch bessere Skalierbarkeit, Verwaltbarkeit und durch die Unterstützung unterschiedlichster Protokolle aus. Aufgrund der genannten Vorteile ist es in einem hierarchischen Netzwerkmodell auch im Nachhinein möglich, zentral verwaltbare Sicherheitsmechanismen einzuführen Verbreitete Netzwerkmodelle Im Allgemeinen wird zwischen drei unterschiedlichen Netzwerkmodellen unterschieden. Das Ein-Schichten-Modell kommt bei Organisationen mit wenigen geographisch verteilten Standorten zum Einsatz. In diesem Modell stellt jeder Standort eine eigene Broadcast-Domäne dar. 3

13 2. Grundlagen 4 In Netzwerken, in denen das Ein-Schichten-Modell keine ausreichenden Segmentierungsmöglichkeiten bietet, wird ein Zwei-Schichten-Modell, wie in Abbildung 2.1 dargestellt, verwendet. Hierbei werden mehrere meist verteilte Standorte durch Wide Area Network (WAN)-Verbindungen miteinander verknüpft. Innerhalb dieser Standorte kann es zu einer Unterteilung in Broadcast-Domänen, beispielsweise durch logische Segmentierung mittels Virtual Local Area Network (VLAN)-Gruppierung, kommen. [28] Abbildung 2.1: Das hierarchische Zwei-Schichtenmodell [28] Drei Schichten Modell In einem Drei-Schichten-Modell kommt es, wie in Abbildung 2.2 dargestellt, zu einer Aufteilung der Netzwerk-Funktionen auf den Access-Layer, den Distribution-Layer und auf den Core-Layer. Im Folgenden werden die drei Schichten und deren Funktionen ausführlich dargestellt. Access-Layer Als Access-Layer versteht man den Bereich, der für den Netzzugriff der Anwender beziehungsweise derer Systeme verantwortlich ist. In diesem Bereich wird eine logische Gruppierung der Anwender beispielsweise nach Abteilungszugehörigkeit oder nach Zugriffsrechten durchgeführt. Die Hauptfunktion des Access-Layers ist die Begrenzung

14 2. Grundlagen 5 Abbildung 2.2: Das hierarchische Drei-Schichtenmodell [28] des Broadcast-Verkehrs auf einzelne Netzwerkbereiche durch logische oder physikalische Segmentierung. [28] Die bisherigen Access-Layer Anforderungen wurden von dem Netzwerkhersteller Cisco Systems in [28] folgendermaßen definiert: - Gemeinsame Bandbreitennutzung - Switching - Filterung in der Media Access Control (MAC)-Schicht - Mikrosegmentierung

15 2. Grundlagen 6 Aufgrund der Entwicklung der Access-Layer Geräte zu tragenden Sicherheitselementen mussten neue Anforderungen, wie in der folgenden Auflistung und in [25] dargestellt, definiert werden: - Sicherheit * Sicheres Management der Komponenten * Authentisierung des Nutzers und alternativ auch der angeschlossenen Systemhardware (Desktop Integritätskontrolle) * Policy Management - zentrale Regelvergabe auf Layer 2-4 des Open Systems Interconnection (OSI)-Modells * Dynamische Rekonfiguration des Netzes beim Auftreten von Gefahren - Quality of Service * Erkennung und Klassifizierung des Verkehrs auf Layer 2-4 des OSI-Modells * Automatische Erkennung der Konvergenz-Endsysteme * Warteschlangenmanagement (Queueing) * Bandbreitenmanagement (Rate Limiting und Shaping) * Buffermanagement (Drop Probability) * Power over Ethernet - Management * Automatische Erkennung der angeschlossenen Systeme * Zentrale Verwaltung aller Endsystem-Daten * Zentrale Konfiguration aller relevanten Parameter * Detailliertes Monitoring der Verkehrsströme auch in Bezug auf Prioritäten

16 2. Grundlagen 7 Distribution-Layer Die Hauptaufgabe des Distribution-Layers ist die Gebäudevernetzung, welche meistens mit 100 Megabit oder Gigabit Technologien ausgeführt wird. In dieser Schicht werden üblicherweise die in [28] angeführten Funktionen implementiert: - Adress- oder Bereichsgruppierung - Zugriff von Abteilungen oder Arbeitsgruppen auf den Core-Layer - Definition von Broadcast- und Multicast-Domänen - VLAN-Routing - Medienübergänge - Sicherheit (meist durch Access Control Lists) Im Distribution-Layer wird der Verkehr durch Richtlinien wie Unternehmens-Policies beeinflusst und es wird nur ausgewählter Netzwerkverkehr an den Backbone (Core- Layer) weitergeleitet. Um Geschwindigkeitseinbußen durch Paketmanipulation im Core- Layer zu vermeiden, werden Sicherheitsimplementationen wie Access Control Lists (ACL) im Distribution-Layer implementiert. In einem korrekt aufgebauten Netzwerkmodell gibt es im Distribution-Layer keine Endstationen. [28] Core-Layer Im Core-Layer werden beispielsweise geographisch getrennte Standorte durch schnelle WAN-Verbindungen zu einem Unternehmens-Netzwerk zusammengeführt. Normalerweise findet in diesem Netzwerkbereich keine Paket-Manipulation durch Access-Listen oder Ähnlichem mehr statt. Es kommt auf schnelle Datenübertragung zwischen den unterschiedlichen Standorten an. Im Allgemeinen wird der Core-Layer, wie in Abbildung 2.3 ersichtlich, redundant ausgeführt. Dadurch kann auch bei Ausfall einer Verbindung der Betrieb aufrecht erhalten werden. [28]

17 2. Grundlagen 8 Abbildung 2.3: Core-Layer redundant [28] Access-Layer Sicherheit Wie der Bericht Computer Crime and Security Survey 2005 der unter [19] nachzulesen ist, vom Computer Security Institute (CSI) darstellt, ist das Internet nicht mehr der einzige Hauptangriffspunkt von Privaten- und Firmen-Netzwerken. Der externe Zugriff ist durch hoch entwickelte Firewall-Technologien mittlerweile sehr gut geschützt. Es kommt dadurch zu einer Verlagerung des sicherheitskritischen Bereiches in das interne Netzwerk. Wie aus Abbildung 2.4 ersichtlich, bestätigen 46% der Firmen, zwischen ein und fünf erkannte Angriffe aus dem internen Netzwerkbereich. Zu beachten ist dass 44% der Firmen keine Kenntnis über interne Angriffe besitzen. Es ist davon auszugehen, dass diese auch keine internen Sicherheitsvorkehrungen implementiert haben, wodurch sie auch nicht im Stande sind, Gegenmaßnahmen einzuleiten. Da der Access-Layer der erste Zugriffspunkt der Endsysteme ist, muss an diesem Punkt sichergestellt werden, dass die Endsysteme, die Zugriff zu dem Netzwerk benötigen, vertrauenswürdig und sicher sind. Um die benötigte Sicherheit herzustellen, wird unter anderem mit Authentifizierungssystemen, basierend auf dem AAA-Framework, gearbeitet. Alle der in Kapitel 3 behandelten Sicherheitslösungen setzen als erste Grundlage die Authentifizierung über das AAA-Framework, welche im nächsten Abschnitt beschrieben wird, voraus.

18 2. Grundlagen 9 Abbildung 2.4: Zwischenfälle durch externe und interne Angreifer verursacht [19]

19 2. Grundlagen Das AAA-Framework Die drei A des AAA-Frameworks stehen der Reihe nach für Authentication, Authorization und Accounting. Dieses Framework dient unter anderem als Werkzeug zur Kontrolle. Es schafft die Möglichkeit zu prüfen wer Zugriff zu bestimmten Ressourcen bekommt, was er mit diesen Ressourcen machen kann und was er wirklich damit macht. [6] In an ideal world, we wouldn t have to use authentication of any type to gain access to anything. But as long as free enterprise exists and access to private resources is sold, authentication will exist [17, S. 1]. Bei AAA geht es um die in [17] formulierten Fragen: 1. Wer bist du? 2. Was darfst du in diesem Netzwerk? 3. Was machst du mit den Diensten, die du verwenden darfst? In den folgenden Abschnitten werden alle relevanten Bereiche dieses Sicherheitsframeworks genauer betrachtet Authentication Im Rahmen der Authentifizierung wird die Identität eines Benutzer oder eines Endgerätes überprüft. Bisher wurde für diese Überprüfung meist eine Kombination aus Benutzer ID und Passphrase verwendet, mittlerweile finden auch zertifikatsbasierende Systeme oder biometrische Systeme immer breitere Anwendung. [17] An Hand der Abbildungen 2.5, 2.6 und 2.7 wird, unter Zuhilfenahme eines Beispiels aus den Cisco-Unterlagen von [6], erklärt, wie die einzelnen Teilbereiche des AAA- Frameworks funktionieren.

20 2. Grundlagen 11 Abbildung 2.5: Authentication-Beispiel [6] 1. Das Endsystem baut in diesem Beispiel eine Verbindung zum Router auf. Im Allgemeinen wird eine Verbindung zu einem Network Access Server (NAS) hergestellt. 2. Der NAS fragt das Endsystem nach den Benutzerdaten wie Benutzername und Passwort. 3. Anschließend werden diese Benutzerdaten in der lokalen Datenbank überprüft. Bei erfolgreicher Authentifizierung wird dem Benutzer Netzwerkzugriff gewährt Authorization Hat sich ein Benutzer, wie in Abschnitt dargestellt, erfolgreich authentifiziert, muss definiert werden, welche Berechtigungen dieser hat. Berechtigungen werden meist durch Policies, wie in Abschnitt 2.5 beschrieben, umgesetzt. Ein solches Policymodell behandelt ebenso, ob die Internet Protocol (IP)-Adressvergabe per DHCP erfolgt, welche Dienste der Benutzer nutzen darf oder wie lange er gewisse Ressourcen belegen darf. [17] Abbildung 2.6: Authorization-Beispiel [6]

21 2. Grundlagen Für die Durchführung der Authorisierung wird eine Verbindung zu einem AAA- Server aufgebaut. 2. Der Router fragt am AAA-Server nach, ob der Benutzer für den benötigten Dienst die Berechtigung besitzt. 3. Der AAA-Server erlaubt oder verweigert den Zugriff zu dem benötigten Dienst Accounting Im Allgemeinen versteht man unter Accounting den Sammelvorgang von Informationen über den Verbrauch von Ressourcen. Wie die Daten in weiterer Folge verwertet werden, steht in diesem Bereich nicht im Vordergrund. Diese Daten können zur Trendanalyse ebenso aufbereitet werden, wie zur Abrechnung oder zur Evaluierung der Sicherheitsstrategie. Für Sicherheitsanalysen können die zurückgewiesenen Zugriffe relevant sein, bei Ausbau der IT-Infrarstruktur steht die Kenntnis der Zugriffe auf einzelne Dienste im Vordergrund. Da die Accounting-Informationen häufig die Basis für Entscheidungen darstellen und auch als Grundlage für die Abrechnung dienen, stellen diese Daten ein potentielles Angriffsziel dar. Um Integrität und Geheimhaltung der Daten zu gewährleisten, müssen diese über ein gesichertes Accounting Framework gesammelt und aufbereitet werden. [21], [17] Abbildung 2.7: Accounting-Beispiel [6] 1. Sobald sich ein Benutzer erfolgreich authentifiziert hat, wird eine AAA-Accounting Startmitteilung generiert, wodurch der Accounting-Vorgang eingeleitet wird. 2. Sobald der Benutzer den Dienst beendet, wird der Accounting-Vorgang abgeschlossen.

22 2. Grundlagen Drei Parteien-Authentifizierungsmodell Zu Beginn der Authentifizierungssysteme wurden zwei Parteien - Authentifizierungsmodelle verwendet. Bei diesem Modell kommunizieren die beiden Parteien direkt mit- einander und authentifizieren sich gegenseitig, wie es beispielsweise bei direkter Client- Server-Kommunikation üblich ist. [21] Aufgrund des starken Wachstums von Netzwerken und dem dadurch entstehenden Anstieg an Benutzern, die sich authentifizieren müssen, wurden spezielle Zugriffspunkte, die points of presence (POP) genannt wurden, entwickelt. Diese POPs dienen als Zugriffspunkte für Benutzer und kommunizieren direkt mit diesen. Für den Authentifizierungsvorgang wird vom POP eine Anfrage an den Authentifizierungsserver gestellt. [21] Wie aus Abbildung 2.8 ersichtlich, besteht das AAA-Modell prinzipiell aus den folgenden drei Komponenten: 1. Ein Supplicant ist ein Client der beim Authenticator einen Zugang beantragt. Im Falle von 802.1x, welches im Abschnitt genauer behandelt wird, handelt es sich um einen Zugang zu einem Netzwerk. 2. Der Authenticator ist vergleichbar mit einem Türsteher bei einem Firmeneingang. Der Türsteher selbst weiß nicht, ob er einen Besucher einlassen darf oder nicht und fragt bei den zuständigen Authoritäten (Authentication Server) nach, ob der Besucher passieren darf. Im AAA-Modell wird dieser Authenticator meist als NAS bezeichnet. Dieser fungiert als Vermittler zwischen Benutzer (Supplicant) und Authentifizierungsserver der beispielsweise als Radiusserver, wie in Abschnitt 2.3 genauer betrachtet, realisiert wird. Im Bereich der sicheren Netzwerkauthentifizierung wird der NAS meist als Zugriffs-Switch realisiert. [21] 3. Ein Authentication Server oder wie in Abbildung 2.8 AAA Server benannt, ist die Komponente mit den benötigten Benutzerinformationen und der Befugnis, Entscheidungen über den Zugriff eines Benutzers zu treffen. [21]

23 2. Grundlagen 14 Abbildung 2.8: Drei Parteien-Authentifizierungssystem (adaptiert aus[21]) Extensible Authentication Protocol Unter dem Extensible Authentication Protocol (EAP) wird ein Authentifizierungs- Framework verstanden. Die Verwendung eines Frameworks ermöglicht es, verschiedene Authentifizierungsmethoden bereitzustellen, ohne grundlegende Änderungen der Infrastruktur durchführen zu müssen. Durch die unterschiedlichen Authentifizierungsmethoden, die durch das Endsystem gewählt werden können, ist ein solches Modell anfällig gegen so genannte Downgrade Attacks. Durch die Verwendung des in Abschnitt beschriebenen Drei-Parteien Authentifizierungssystems ist es normalerweise möglich, neue EAP-Authentifizierungsmethoden einzuführen, ohne Änderungen, wie beispielsweise Firmware-Updates, an allen NAS durchführen zu müssen. Der NAS leitet die Anfragen an einen zentralen Backend- Server weiter und muss den Authentifizierungsverkehr in den meisten Fällen nicht auswerten. Der Authentifizierungsserver muss in weiterer Folge die verwendeten Authentifizierungsmethoden verarbeiten können. [21]

24 2. Grundlagen 15 Ein EAP-Authentifizierungsvorgang, welcher in einem AAA-Protokoll gekapselt wird, ist in Abbildung 2.9 dargestellt: Abbildung 2.9: EAP Mitteilungen in AAA-Protokollen gekapselt (adaptiert aus [21]) - Der NAS schickt eine EAP-Anfrage (EAP-request) an das Endsystem (Peer). Das Typefeld der EAP-Nachricht gibt an, welche Daten angefragt werden. In dieser Phase erfolgt der Informationsaustausch im Klartext, wodurch zu diesem Zeitpunkt keine Informationen zur Benutzeridentität übermittelt werden. [21] - Das Endsystem antwortet auf die EAP-Anfrage mit einer Nachricht des selben Typs (EAP-response). Für eine Identitätsanfrage mit einem Typefeld von 1 wird beispielsweise eine Identitätsantwort mit einem identen Typefeld von 1 übermittelt. Befindet sich im Typefeld einer der in Tabelle 2.1 dargestellten Werte, werden die Anforderungen der Authentifizierungsmethode in einer Antwort mit demselben Typefeld erfüllt, oder es wird mit einem Typefeld von 3 geantwortet. Dieses Typefeld von 3 (Not Acknoledge-NAK) bedeutet, dass die vorgeschlagene Authentifizierungsmethode nicht verwendet werden kann. [21] - Ab diesem Zeitpunkt wird eine hohe Anzahl weiterer EAP Anfragen und Antworten ausgetauscht, wobei der NAS diese Nachrichten nur weiterleiten muss. Sobald ein Authentifizierungsvorgang erfolgreich abgeschlossen ist, wird das Typefeld leer gelassen. Dadurch ist es auch einem NAS möglich, der den eigentlichen EAP-Vorgang nicht versteht, einen erfolgreichen Authentifizierungsvorgang umzusetzen. [21]

25 2. Grundlagen 16 Type Method 4 MD5-challenge 5 One-Time password 9 RSA Public Key Authentication 21 EAP-TTLS 25 PEAP 43 EAP-FAST Reserved + Experimental Tabelle 2.1: Auszüge der EAP-Methoden aus [21] AAA-Server Wie in Abschnitt bereits dargestellt wurde trifft der Authentifizierungsserver die Entscheidung, ob eine Authentifizierungsanfrage angenommen oder abgelehnt wird. Das Radius-Protokoll, welches in Abschnitt 2.3 detailliert behandelt wird, ist eines dieser Authentifizierungsprotokolle. Dieses wurde bereits vor dem AAA-Framework entwickelt und erfüllte als erstes Protokoll alle AAA-Kriterien. [17] Ein weiteres AAA-Protokoll ist Diameter, das zukünftige Nachfolgeprotokoll von Radius, welches in Abschnitt 2.4 genauer betrachtet wird. Zusätzlich seien hier noch die Protokolle Tacacs und Tacacs+ erwähnt die allerdings in diese Arbeit nicht weiter einfließen werden. Da das Radius-Protokoll in modernen Netzwerkarchitekturen weiterhin vorwiegend im Einsatz ist und auch ständig weiterentwickelt wird, ist dieses Protokoll, trotz seines Alters, den anderen derzeit gleichstellbar und durch breite Anwendung sehr stabil und vielfach erprobt.

26 2. Grundlagen x Bei 802.1x handelt es sich um einen mediumunabhängigen Authentifizierungsstandard in Institute of Electrical and Electronics Engineers (IEEE) 802-Netzwerken. Unter 802.1x wird ein reines Authentifizierungssystem ohne zusätzliche Funktionen wie beispielsweise Accounting verstanden. Die Realisierung ergänzender Mechanismen, wie der in Abschnitt behandelte Accountingvorgang, oder der in Abschnitt dargestellte Authorisierungsvorgang, wird durch das AAA-Framework realisiert. Dieses Authentifizierungssystem beschreibt, wie EAP-Mitteilungen über ein verkabeltes oder ein kabelloses Netzwerk übertragen werden. Da dieses System aus den in Abschnitt beschriebenen Komponenten besteht und der Authentifizierungsvorgang auf dem unter Abschnitt vorgestellten EAP-Framework basiert, wird größtmögliche Sicherheit und Flexibilität ermöglicht. [18] Die 802.1x-Funktionalität basiert, wie aus Abbildung 2.10 ersichtlich, sowohl auf kontrollierten als auch auf unkontrollierten Ports, wodurch es als portbasierte Authentifizierung bezeichnet wird. Abbildung 2.10: 802.1x-portbasierte Authentifizierung [18] Unter den in Abbildung 2.10 dargestellten kontrollierten und unkontrollierten Ports versteht man logische oder virtuelle Ports, die an einem physikalischen Switchport anliegen. Besteht an einem Switchport keine erfolgreich authentifizierte Verbindung, ist der unkontrollierte Port aktiv und der kontrollierte Port inaktiv. Über den aktiven Port

27 2. Grundlagen 18 werden in diesem Status nur Protocol Data Units (PDU) übertragen. Erst nach einem erfolgreich abgeschlossenen Authentifizierungsvorgang wird der kontrollierte Port freigeschalten und somit die Datenübertragung ermöglicht. [18]

28 2. Grundlagen Remote Access Dial-In User Service Bei Remote Access Dial-In User Service, oder in Kurzschreibweise Radius, handelt es sich um das derzeit am weitesten verbreitete AAA-Protokoll. Radius wurde konzipiert um einem NAS die Weiterleitung von Authentifizierungsanfragen zu ermöglichen. Durch die Möglichkeit der Weiterleitung von Authentifizierungsanfragen wurde das in Abschnitt dargestellte Drei-Parteien Authentifizierungsmodell geschaffen. Die Hauptaufgabe von Radius war die Verarbeitung von Password Authentication Protocol (PAP)und Challenge Handshake Authentication Protocol (CHAP) Authentifzierungsanfragen. Durch den modularen Aufbau von Radius wird mittlerweile Authentifizierung mittels EAP ebenso unterstützt wie der in Abschnitt dargestellte Authorisierungsvorgang und der in Abschnitt behandelte Accountingvorgang. [21] Eigenschaften des Radiusprotokolles Bei Radius handelt es sich um einen auf Client-Server basierenden Authentifizierungsvorgang, wobei als Client nicht das Endsystem des Benutzers agiert, sondern der NAS, der als Vermittler zwischen dem Radiusserver und dem Endsystem fungiert. [21] Die RFC Spezifikation [17] und [27] stellen die Eigenschaften des Radiusprotokolles folgendermaßen dar: - Radius ist User Datagram Protocol (UDP) basierend - Verwendung des Hop by Hop Sicherheitsmodell - Radius ist ein zustandsloses Protokoll - Unterstützt PAP und CHAP Authentifizierung über Point-to-Point Protocol (PPP)- Verbindungen - Verwendet Message Digest Algorithm 5 (MD5) für Passwortübertragungen, siehe auch Kapitel 2.3.2

29 2. Grundlagen 20 - Unterstützt über 50 Attribute mit der Möglichkeit der herstellerspezifischen Parameterübermittlung - Unterstützung des AAA-Modells Die Grundspezifikation von Radius findet im RFC 2865, welcher unter [27] zu finden ist, statt. Erweiterungen wie Accounting oder EAP werden in separaten RFCs abgehandelt. Einschränkungen des Radiusprotokolles Wie in Abschnitt genauer behandelt wird, gibt es bei Verwendung des Radiusprotokolls mehrere Einschränkungen im Sicherheitsbereich. Zusätzlich ist zu beachten, dass gerade in Umgebungen mit mehreren Proxy-Radiusservern jeder dieser Proxies die Authentifizierungsdaten der Endsysteme verarbeiten muss. Durch diese Verarbeitung der Nachrichten werden diese auch, je nach verwendeter Authentifizierungsmethode, teilweise geöffnet und analysiert. Durch diesen Bearbeitungsprozess sind alle Informationen an jeden Proxy-Radiusserver, der sich auf dem Weg zum zentralen Radiusserver befindet, abgreifbar. [17] Radius bietet laut RFC Spezifikationen keine Möglichkeit, die Benutzer, die sich erfolgreich authentifiziert haben, wieder abzumelden oder den Zugriff auf gewisse Dienste während einer aktiven Sitzung einzuschränken. Es gibt Herstellerimplementationen, die solche Funktionen nachrüsten, allerdings sind diese überwiegend nicht RFC-spezifiziert. [17] Im Gegensatz zu Diameter, welches in Abschnitt 2.4 dargestellt wird und bei dem Transmission Control Protocol (TCP) oder Stream Control Transmission Protocol (SCTP) als Transportprotokoll zum Einsatz kommt, wird vom Radiusprotokoll UDP als Transportprotokoll eingesetzt. Durch die Verwendung von UDP als Transportprotokoll kann es, wie in RFC 2865 [27] bereits auf der ersten Seite vermerkt wird, bei Radiusimplementierungen in großen Netzwerkumgebungen zu Performanceeinbußen kommen. Experience has shown that it can suffer degraded performance and lost data when used in large scale systems, in part because it does not include provisions for congestion control [27, S. 1].

30 2. Grundlagen Sicherheitsüberlegungen zum Radiusprotokoll Durch die Verwendung von statischen Schlüssel, üblicherweise als shared secret keys bezeichnet, zur Verschlüsselung der Nachrichten zwischen NAS und Radiusserver kommt es zu Schwachstellen im Authentifizierungssystem. [21] Einige dieser Schwachstellen werden in [21] und in folgender Auflistung dargestellt: - Statisch und manuell konfigurierte Secret Keys: Im Radiusprotokoll gibt es keine Möglichkeit der automatisierten und dynamischen Zuweisung der geheimen Schlüssel. Bei weit verteilten Netzwerken kann es bei Änderungen des Schlüssels zu einem hohen administrativen Aufwand kommen. Dies hat zur Folge, dass diese Schlüssel meist nur selten geändert werden. - Shared Secret lookup: Um Spoofing vorzubeugen wird vom Radiusprotokoll für die Ermittlung des geheimen Schlüssels die Quell-IP-Adresse der UDP-Pakete verwendet. Dies führt bei dynamischer Adresszuordnung der NAS, wie sie beispielsweise bei WLAN-Access Points häufig verwendet wird, zu Sicherheitsrisiken aufgrund der dynamischen Adressvergabe. - Proxy-Verkettung: Die Nachrichten des NAS werden mit demselben geheimen Schlüssel, wie der des ersten Proxy Radiusserver und nicht mit dem Schlüssel des End-Radiusservers verschlüsselt. Dadurch kommt es zu keinem durchgehenden Vertrauensverhältnis. Es besteht ein sogenanntes Hop by Hop Vertrauensverhältnis und kein Endpunkt zu Endpunkt Vertrauensverhältnis. - Transport Sicherheit: Aufgrund der Verwendung von UDP ist es mit sehr einfachen Methoden möglich die IP-Adresse eines NAS vorzutäuschen oder Attribute zu verändern. Um die Sicherheitsprobleme durch diese statischen Schlüssel so gering wie möglich zu halten wird empfohlen, Shared Secret Keys mit einer Länge von mindestens 16 Octets zu verwenden. [17]

31 2. Grundlagen 22 Zur Absicherung der Datenübertragung zwischen NAS und Radiusserver wird MD5 verwendet. Aktuellen Quellen zufolge scheint die Sicherheit von MD5 nicht mehr uneingeschränkt zu sein, in [30] wird auf die Möglichkeit, sogenannte collisions zu erzeugen, hingewiesen. Zur Bereitstellung von Authentifizierung und Verschlüsselung für Radiusmitteilungen wird in [21] die Verwendung von IP Security (IPsec) empfohlen Unterschiedliche Radiusserver Die folgende Liste, verfügbarer Radiusserver, stellt keine Wertung der unterschiedlichen Systeme dar und erhebt keinen Anspruch auf Vollständigkeit. - Open Source Radiusserver * Cistron RADIUS * FreeRADIUS * GNU is not Unix (GNU) Radius * JRadius * OpenRADIUS - Kommerzielle Radiusserver * Aradial RADIUS * Internet Authentication Service (IAS) * Radiator * RadiusNT & RadiusX * Steel-Belted Radius

32 2. Grundlagen Diameter Als im Jahr 2000 die Internet Engineering Task Force (IETF ) Radius Arbeitsgruppe ihre Arbeit für beendet erklärte, wurde eine neue Arbeitsgruppe mit dem Nachfolger des Radius-Protokolles beauftragt. Die Anforderungen an das neue AAA-Protokoll wurden im RFC 2989, welcher unter [1] abrufbar ist, gesammelt. [21] Einige dieser Anforderungen laut RFC 2989 waren: - Skalierbarkeit - Verlässlicher AAA-Transportmechanismus - IPv4 und IPv6 Unterstützung - Datenintegrität muss gewährleistet sein - Zertifikatstransport - Proxy und Router Unterstützung - Definiertes Fehlverhalten - Überwachung des Systemverhaltens Als potentielle Kandidaten gab es Radius++, Simple Network Management Protocol (SNMP), Common Open Policy Service Protcol (COPS) und Diameter. Nach einer Evaluierung aller Kandidaten wurde Diameter aufgrund der in RFC 3127 [20] und der in Tabelle 2.2 dargestellten Vorteile als das zukünftige AAA-Protokoll festgelegt. [21] Um einen Umstieg von Radius zu Diameter möglichst sanft durchführen zu können, wurde bei Diameter auf Abwärtskompatibilität zum Radiusprotokoll geachtet. Des Weiteren wurden die in der Tabelle 2.3 und in [8] dargestellten Eigenschaften verbessert.

33 2. Grundlagen 24 Merkmale Peer-to-peer bidirektional Sehr effizient Diameter-Unterstützung * Push und Pull Mechanismus (Radius arbeitet rein unidirektional) * Unterstützt 32 Bit Vendor Specific Attribute (VSA) * Kann wesentlich mehr AAA-Anfragen abhandeln * Nutzt Vorteile neuer Prozessor Technologien Sehr ausfallsicher * Client und Server unterstützen Bestätigungsmechanismus * Server unterstützen keepalive -Mitteilungs- Erhöhte Sicherheit mechanismen um Ausfällen bzw. kommenden Ausfällen vorzubeugen * Verschlüsselungsmechanismen Tabelle 2.2: Vorteile von Diameter (adaptiert von [8]) Aufgrund der hohen Komplexität des Diameterprotokolles und der sehr weiten Verbreitung von Radius als AAA-Protokoll ist es Diameter bisher nicht gelungen sich als primäres AAA-Protokoll zu etablieren. Bisher gibt es sehr wenige kommerzielle Server, beispielsweise Produkte von den Herstellern Interlink und HP. Zusätzlich gibt es ein Open Source Projekt welches sich unter dem Namen Open Diameter mit der Umsetzung des Diameterprotokolles beschäftigt. Cisco Systems weist in [8] ausdrücklich darauf hin, dass das Internetworking Operating System (IOS)-Betriebssystem keine Unterstützung für Diameter bietet.

34 2. Grundlagen 25 Characteristic RADIUS Deficiency Diameter Improvements Strict Limitations of attribute data End-to-end message acknowledgement Silent discarding of packets No failover server support Authentication replay attacks Hop-by-hop security Only 1 byte reserved for the length of a data field (max. 255) in its attribute header Client expects a successful or failed response after a request, but does not know whether the server has received the request Packets that do not contain the expected information, or that have errors, are silently discarded. This might cause the client to operate as if the server is down because it does not receive any response. It would then try to send packets to a secondary server Server has no way of indicating that it is going down or is currently running When using PPP Chap any RADIUS client can generate a challenge response sequence, which can be intercepted by any RADIUS client or proxy server in the chain. Another RADIUS client can then replay this challenge response sequence at any time (partly solved by the RADIUS extension using EAP protocol) Supports only hop-by-hop security: every hop can easily modify information that cannot be traced to its origin Reserves 2 bytes for its length of a data field (max ) Client expects a success of failed response or an acknowledgment of received request by the server Server can notify the client of problem by sending an error message Support keep-alive messages and messages that indicate that a server is going down for a time period Challenge/response attributes can be secured using end-to-end encryption and authentication Supports end-to-end security, which guarantees that information cannot be modified without notice Tabelle 2.3: Unterschiede zwischen Radius und Diameter (adaptiert aus [8])

35 2. Grundlagen Sicherheitspolicies Netzwerkpolicies, die in einem policybasierten Authentifizierungssystem umgesetzt werden, basieren auf einem, für jeden Betrieb individuell kreierten Sicherheitsmodell. Wie aus [16] hervorgeht, bezieht sich ein solches Modell generell auf alle Aspekte der Sicherheit und wird folgendermaßen beschrieben: Eine Sicherheitspolicy beschreibt die formale Aufstellung von Regeln, die von sämtlichen Personen eingehalten werden müssen, die Zugang zu unternehmensrelevanten Techniken und Informationen haben [16, S. 7]. Unter den betrachteten Aspekten befinden sich, wie folgende Auflistung aus [16] zeigt, neben physikalischer Sicherheit der Hardware auch verschiedene andere Kriterien. - Hardware: Prozessoren, Motherboards, Tastaturen, Terminals, Arbeitsplatzrechner, private Rechner, Drucker, Festplatten, Verkabelung, Terminal Server, Netzwerkgeräte - Software: Programme deren Quellcode verfügbar ist, Programme deren Quellcode nicht zur Verfügung steht, Diagnose Programme, Betriebssysteme, Kommunikationsprogramme - Daten: während der Ausführung, während der Übertragung, gespeichert und verfügbar, gespeichert und archiviert, Backups, Logdateien, Datenbanken - Menschen: Benutzer, Administratoren, Hardware-Verwalter - Dokumentation: für Programme, Hardware, Systeme, Einrichtungsszenarien. - Zubehör: verschiedenste Arten von Zubehör Für die Erstellung von Sicherheitspolicies gibt es zwei unterschiedliche Ansätze die in einem flexiblen Sicherheitsmodell auch kombinierbar sind. Zum einen gibt es den Deny all -Ansatz, bei dem als Ausgangssituation alles blockiert wird und der Reihe nach die benötigten Dienste freigeschalten werden. Dieser Ansatz

36 2. Grundlagen 27 ermöglicht ein Maximum an Kontrolle und Sicherheit, da ausschließlich benötigte und somit bekannte Dienste und Services verwendbar sind. Dieser restriktive Ansatz ist in der Umsetzung komplexer und langwieriger als der folgende Allow all -Ansatz. Des Weiteren wird im Rahmen der technischen Umsetzung und der weiteren Betreuung ein sehr gutes Verständnis der unterschiedlichen Services und Protokolle, die von dem Sicherheitsmodell beeinflusst werden, vorausgesetzt. [16] Die zweite Variante ist der Allow all -Ansatz, welcher im Unterschied zum Deny all -Ansatz von Grund keine Einschränkung der Dienste vorsieht. Erst bei Auftreten von Sicherheitsproblemen werden Regeln erstellt die diese Probleme behandeln und beispielsweise den Zugriff auf Dienste, deren Sicherheit nicht mehr uneingeschränkt gewährleistet ist, blockieren. [16] Durch die technische Umsetzung eines solchen Sicherheitsmodells aus der Netzwerkebene heraus, kommt es zu einem erheblichen Sicherheitsgewinn für das vollständige interne Netzwerk. Diese Umsetzung basiert üblicherweise auf einer nach Berechtigungen gestaffelten Benutzergruppierung. Aufbauend auf diesem Berechtigungsmodell wird ein sicheres Netzwerkauthentifizierungsmodell, wie das in Kapitel beschriebene EAP- Framework, eingeführt. Basierend auf diesem Authentifizierungsmodell kommt es zu einer dynamischen Zuordnung von statisch definierten Policies. Generell muss eine auf Policies basierende Netzwerklösung die nachfolgenden und in [23] beschriebenen Bereiche abdecken: - Erstellen von Regeln und Policies - Erkennen von Policy Konflikten - Speicherung von Policies - Verteilung von Policies - Umsetzung von Policies in Befehle, die von der Netzwerkkomponente verstanden werden - Verteilung der Befehle an die Netzwerkkomponenten - Überprüfung der Policy-Verteilung

37 3 Analyse Im folgenden Kapitel 3 werden policybasierte Sicherheitslösungen der renommierten Netzwerk- und Sicherheitsspezialisten Cisco Systems und Enterasys Secure Networks genauer analysiert und verglichen. 3.1 Cisco-Systems Der Netzwerkhersteller Cisco Systems bündelt seine Sicherheitslösungen unter der Bezeichnung Self Defending Network. Self Defending Network bildet aus unterschiedlichsten Sicherheitslösungen für Endsysteme, sowie für Netzwerkgeräte, eine integrierte Sicherheitsarchitektur. Ganz speziell in heutigen, meist örtlich verteilten Netzwerkarchitekturen wird es immer komplexer, von zentraler Stelle aus Sicherheitsverletzungen zu erkennen und gegen diese in Echtzeit vorzugehen. Ziel dieser Architektur ist ein Sicherheitskonzept, dass möglichst automatisiert auf Sicherheitsrisiken oder Angriffe reagiert. Unter Verwendung der Self Defending Network Architektur lässt sich auch in örtlich verteilten Netzwerkstrukturen ein zentral verwaltbares Sicherheitsframework implementieren. 28

38 3. Analyse 29 Wie in [9] dargestellt, umfasst Self Defending Network folgende Technologien und Produkte: - Day Zero Schutzmaßnahmen mit Cisco Security Agent - Zugriffskontrolle durch Network Admission Control (NAC) - Sichere Verbindungen durch VPNs die mit IPSec gesichert sind - Anpassungsfähige Sicherheitslösungen durch zustandsorientierte Firewalls, VPN, Intrusion Prevention System (IPS) und Antivirus - CiscoWorks Management Lösungen In den folgenden Kapiteln werden die zwei Basisbestandteile NAC und IPS genauer betrachtet. In Kapitel 3.2 werden anschließend die Produkte Sentinel und Dragon von Enterasys Secure Networks detailliert dargestellt Network Admission Control Durch den Einsatz von NAC ist es möglich, unternehmensweite Sicherheitsbestimmungen für Endsysteme zentral zu definieren, zu verwalten und deren Umsetzung zu überprüfen. Es wird dadurch sichergestellt, dass nur Endsysteme, die als sicher eingestuft wurden, Zugriff zum internen Netzwerk erlangen. Mit NAC kann beispielsweise überprüft werden, ob auf Endsystemen aktuelle Virenscanner vorhanden sind, alle erforderlichen Updates eingespielt oder die Firewalls aktiviert wurden. Die verwendeten Richtlinien lassen sich individuell adaptieren. Durch diese Individualisierung ist es beispielsweise auch möglich spezielle VPN-Einstellungen wie Verschlüsselungsalgorithmen mittels NAC automatisiert durchzusetzen. [10]

39 3. Analyse 30 Eine NAC-Architektur besteht aus den in Abbildung 3.1 dargestellten Komponenten: Abbildung 3.1: Network Admission Control Komponenten[5] Der Posture Agent sammelt die relevanten Informationen die zur Beurteilung des Sicherheitsstatus des Endsystems benötigt werden und leitet diese Informationen an den Access Control Server (ACS) weiter. Die Network Access Devices sind für die Weiterleitung der Authentifizierungsanfragen ebenso wie für die Umsetzung der Policybeschränkungen zuständig. Für den Authentifizierungsvorgang kommt der Cisco ACS als AAA-Server zum Einsatz. Dieser Server bewertet unter Zuhilfenahme von optionalen Directory Servern und Policy Servern den Authentifizierungsvorgang und den Sicherheitsstatus des Endsystems und leitet die Policyinformationen an das jeweilige Network Access Device weiter. Benötigt ein Endsystem, welches keinen geeigneten Posture Agenten besitzt Netzwerkzugriff, wird dieses System vom Audit Server durch einen Online-Scan, auf die Einhaltung der Sicherheitsrichtlinien überprüft. Ein detaillierter Vergleich weiterer NAC-Produkte unterschiedlichster, renommierter Sicherheitshersteller findet sich unter [12].

40 3. Analyse Cisco Security Monitoring, Analysis and Response System Cisco Security Monitoring, Analysis, and Response System (MARS) ist integraler Bestandteil der Self Defending Network-Architektur und gibt den Netzwerk und Sicherheits-Verantwortlichen die Möglichkeiten, Sicherheitsprobleme zu erkennen, diese zu analysieren und anschließend geeignete Gegenmaßnahmen einzuleiten. MARS lässt sich in eine bereits existierende Sicherheitsinfrastruktur integrieren, wodurch die bereits eingesetzte Sicherheitsarchitektur durch die Funktionalität von MARS erweitert und optimiert wird. Sind bereits unternehmensweite Sicherheitspolicies im Einsatz, unterstützt MARS die Verantwortlichen sowohl bei der Überprüfung der Einhaltung dieser Policies, als auch bei der Einleitung von geeignete Gegenmaßnahmen. [7] MARS dient zur zentralen Auswertung und Analyse von Log-Informationen unterschiedlichster Geräte, wie beispielsweise von Routern oder Switches. Es können Informationen von Sicherheitsanwendungen, wie Firewalls, IDS, Sicherheitsscannern oder Antiviren-Scannern ebenso ausgewertet werden wie unterschiedlichste Datenbanken, Webserver und Authentifizierungsserver. Zur Analyse kann sowohl das Syslog-Informationssystem herangezogen werden, als auch Netzwerk-Verkehrsanalyse unter Zuhilfenahme von Technologien wie Ciscos NetFlow. Um die Komplexität handhabbar zu machen, wird Cisco Security MARS mit einem vordefinierten Regelwerk ausgeliefert. Dieses Regelwerk wird regelmäßig, durch Erweiterungen an aktuelle Bedrohungen angepasst und lässt sich über ein graphisches Verwaltungssystems an die jeweiligen Gegebenheiten anpassen. [7]

41 3. Analyse Das Enterasys Secure Networks Konzept Secure Networks ist eine unternehmensweite Lösung, die Sicherheitstechnologien direkt in eine verteilte Netzwerkinfrastruktur integriert. Alle sicherheitsrelevanten Komponenten arbeiten zusammen und automatisiert. Sie stellen damit eine geschlossene Sicherheitsarchitektur dar, die auch noch einfach und effizient durch eine gemeinsame Managementoberfläche und ein einheitliches Policy-Management administriert werden kann. [24] Wie in Abbildung 3.2 ersichtlich, lässt sich das Secure Networks Konzept zu einem vollwertigen Single Sign On ausbauen. Abbildung 3.2: Enterasys Single Sign On-Authentifizierungssystem (adaptiert aus [24]) In Abbildung 3.2 sind alle Hauptbestandteile eines Single Sign On-Systems dargestellt. Die Authentifizierung erfolgt durch einen zentralen Radiusserver, der über eine LDAP-Anbindung verfügt. Die Policykonfiguration wird unter Zuhilfenahme des Netsight Policy Managers, der üblicherweise auf einem Managementserver betrieben wird,

42 3. Analyse 33 durchgeführt. Es ist möglich WLAN-Zugriffe ebenso wie verkabelte Netzwerkanschlüsse und auch Virtual Private Network (VPN)-Verbindungen durch den zentralen Radiusserver mit benutzerbasierter Policyzuordnung abzuwickeln Policybasiertes Authentifizierungssystem Grundbestandteile des policybasierten Netzwerkauthentifizierungssystems sind der Net- Sight R Policy Manager, welcher auf der NetSight R Console aufbaut, und die policyfähigen Enterasys Matrix Switches. Es ist auch möglich Geräte anderer Hersteller zu integrieren, allerdings ohne die Möglichkeit der policybasierenden Zugriffsregelung. Eine dynamische VLAN-Zuordnung ist jedoch auch bei Geräten anderer Hersteller möglich. Durch ein flexibles Authentifizierungssystem, welches von 802.1x über MAC-basierender Authentifizierung bis hin zu webbasierender Authentifizierung reicht, ist es möglich, den Zugriff aller möglichen Endsysteme mittels Authentifizierungsmechanismen zu versorgen Sentinel-Sichere Endsysteme Mittels Enterasys Sentinel ist es möglich, Endsysteme, bevor ein aktiver Netzzugriff hergestellt ist, auf Sicherheitslücken, fehlende Patches und allgemeine System-Schwachstellen, wie beispielsweise nicht aktivierte Firewall oder veraltete Virensignatur, zu überprüfen. Diese Überprüfung geschieht mittels Scanwerkzeugen, wie beispielsweise dem Lockdown Enforcer oder dem Open Source Produkt Nessus. Zusätzlich ist eine Verkürzung des Scanvorganges durch Installation von Client-Software auf den Endsystemen möglich.

43 3. Analyse 34 Abbildung 3.3: Arbeitsweise von Sentinel (adaptiert aus [13]) Wie aus Abbildung 3.3 in Schritt 1 ersichtlich ist, werden erst die Policies über den Policy Manager und dem Trusted Access Manager konfiguriert und an die Zugriffssysteme (NAS) verteilt. Ein Endsystem initiiert unter Punkt 2 einen Authentifizierungsvorgang, welcher unter Punkt 3 vom NAS (Enterasys Access Device) an den Radiusserver weitergeleitet wird. Ist der Authentifizierungsvorgang erfolgreich, wird diese Rückmeldung vom Proxy Radius (Enterasys Sentinel Trusted Access Gateway) abgefangen und es wird der Scanvorgang unter Punkt 4 gestartet. Dieser Scanvorgang erfolgt entweder durch einen Lockdown Enforcer oder durch den Open Source Nessus Security Scanner. Während des Scanvorganges wird der Zugangsport mittels einer temporären Scan-Policy, welche vorab unter Punkt 1 definiert wurde, freigeschaltet. Besteht das Endsystem den Sicherheitsscan, wird unter Punkt 5 die originale Radiusmeldung weitergeleitet und die definierte Policy am Switchport angewendet. Bei Nichtbestehen des Scanvorganges, wird der Switchport mit einer Quarantäne-Policy belegt und es wird jeder Hypertext Transfer Protocol (HTTP)-Verbindungsaufbau an

44 3. Analyse 35 den Remediation Server weitergeleitet. Dieser Remediation Server gibt weitere Informationen zu den nichterfüllten Kriterien, nach deren Behebung wird ein erneuter Scanvorgang initiiert Dragon-Intrusion Defense In den meisten Unternehmensnetzwerken sind bereits Sicherheitsimplementationen wie Intrusion Detection Systems (IDS) oder IPS vorhanden. Durch Dragon Intrusion Defense wird eine zentrale Verwaltungs- und Auswertungsplattform geschaffen. Wie aus Abbildung 3.4 ersichtlich, lassen sich mit Dragon Geräte unterschiedlichster Hersteller ebenso verwalten, wie sich Open Source Sicherheitssysteme integrieren lassen. Zur Erkennung von Attacken oder Anomalien lässt sich das Syslog-Nachrichtensystem integrieren. Des Weiteren lassen sich beispielsweise SNMP-Abfragen oder unterschiedliche Datenbanksysteme auswerten. Zudem ist es durch verhaltensbasierte Netzwerkanalyse möglich Day Zero Attacken zu erkennen und dagegen effektiv vorzugehen. [26] Abbildung 3.4: Überblick über Dragon Intrusion Defense [26]

45 3. Analyse 36 Anwendungsbeispiel Das in Abbildung 3.5 dargestellte Beispiel aus [24], zeigt eine Anwendung des Dragon Security Systems in Kombination mit policybasierter Authentifizierung. Abbildung 3.5: Anwendungsbeispiel von Dragon [24] - Ein bereits authentifizierter Benutzer des Netzwerkes startet einen Portscan auf den Domain Name System (DNS)-Server - Dragon Intrusion Defense erkennt diese Aktivität und übergibt eine Warnung an den NetSight Automated Security Manager - Dieser ermittelt anhand der Quell-IP-Adressse, die MAC-Adresse des Benutzers ebenso wie den Port, von dem aus dieser Benutzer agiert - Durch die bereits implementierte unternehmensweite Sicherheitspolicy kann eine der unten angeführten Aktionen automatisiert ausgelöst werden: * Der Netzwerkzugriff des Benutzers wird mit sofortiger Wirkung deaktiviert * Der Netzwerkzugriff des Benutzers wird für eine gewisse Zeit deaktiviert oder eingeschränkt * Dem Benutzer werden alle Dienste, abgesehen von HTTP, deaktiviert * Die Bandbreite des Benutzers wird begrenzt

46 4 Implementierung Im folgenden Kapitel wird die Implementierung eines policybasierenden Netzwerk- Authentifizierungssystems in einem heterogenen Netzwerk behandelt. Durch die Komplexität eines heterogenen Netzwerkes wurde bei dem gewählten Versuchsaufbau auf Redundanz des Radiusserver ebenso verzichtet wie auf einen professionellen Directory Server oder getrennter Parametermitgabe an den WLAN-Access Point. Aus Gründen der Übersichtlichkeit wurden alle verwendeten Konfigurationen auf die Basisbestandteile gekürzt und nur die für die Implementierung relevanten Teile beschrieben. Eine vollständige Ausgabe aller verwendeter Konfigurationen befindet sich in Anhang A, wodurch es möglich ist den Versuchsaufbau nachzubilden. 4.1 Versuchsaufbau In Kapitel 4.2 werden alle Komponenten, die für eine Implementierung des in Abschnitt dargestellten Testnetzwerkes nötig sind, detailliert beschrieben. Anschließend wird in Kapitel 4.3 dargestellt, wie das bereits implementierte Sicherheitssystem zu einem vollwertigen Single Sign On ausgebaut werden kann. Zusätzlich wird in Abschnitt auf erweiterte Möglichkeiten der Absicherung eines Radiusservers eingegangen. In diesem Abschnitt werden grundlegende Möglichkeiten dargestellt um den Radiusdienst vor Abstürzen abzusichern, Änderungen an Systemdateien festzustellen, sowie um Rootkits zu erkennen. 37

47 4. Implementierung Topologieplan In Abbildung 4.1 ist die Netzwerktopologie der Testumgebung dargestellt. Die einzelnen Elemente werden in Abschnitt aufgelistet und detailliert erklärt. Abbildung 4.1: Netzwerktopologie der Teststellung Ziel des in Abbildung 4.1 dargestellten Testnetzwerkes ist ein sicheres Netzwerkauthentifizierungssystem für alle möglichen Endsysteme. Dabei ist zu beachten, dass auch Serversysteme an denen kein lokaler Benutzer arbeitet, eine Authentifizierungsmöglichkeit benötigen. Durch dieses Authentifizierungssystem ist es möglich nur bekannte Systeme im Netzwerk zuzulassen. Aufgrund der Verwendung eines zentralen Radiusssystems mit policybasierter Authentifizierung wird die Möglichkeit geschaffen Benutzergruppen zu definieren und diesen Gruppen automatisch definierte Rechte zuzuordnen. Um eine breite Unterstützung an Endsystemen zu erreichen wird für die Benutzerauthentifizierung Protected EAP

48 4. Implementierung 39 (PEAP), welches von den meisten aktuellen Betriebssystemen unterstützt wird, verwendet. Durch den Authentifizierungsvorgang lässt sich eine dynamische Zuteilung der Policies durchführen, wodurch jeder Benutzer die ihm zugeordneten Rechte im Netzwerk erhält Topologieelemente Nachfolgend die Aufstellung aller in Abbildung 4.1 dargestellten Elemente der Netzwerkumgebung: - Gateway * IP Adresse: * Betriebssystem: m0n0wall v1.22 * Weitere Dienste: Webserver für Konfigurationsinterface, VPN-Gateway * Switchport Nr.: Port 2 * Authentifizierungstyp: MAC basierte Authentifizierung * Switchport Defaultpolicy: default Das VPN-Gateway arbeitet als Radius-Endsystem (NAS) für Point-to-Point Tunneling Protocol (PPTP) Anfragen, dessen Konfiguration wird im Anhang A in Abbildung A.6 dargestellt. Ein PPTP Authentifizierungsvorgang wird ebenso in Anhang A, in Listing A.6, dargestellt. - WLAN-Router * IP Adresse: * Typ/Bezeichnung: Linksys DD-WRT 54G v2.2 * Betriebssystem: DD-WRT v23 SP2 * Kernel: pre2 * Weitere Dienste: Webserver für Konfigurationsinterface * Switchport Nr.: Port 9 * Authentifizierungstyp: MAC basierte Authentifizierung * Switchport Defaultpolicy: default

49 4. Implementierung 40 Der WLAN-Access Point arbeitet als Radius-Endsystem (NAS) für 802.1x Anfragen, dessen Konfiguration wird in Anhang A in Abbildung A.7 dargestellt. Da der WLAN-Access Point nicht policyfähig ist, wirkt für alle authentifizierten Benutzer die Default-Policy am Switchport des policyfähigen Enterasys-Switches. - Switch * IP Adresse: * Typ/Bezeichnung: Matrix E1 WS-24 Workgroup Switch * Firmware: * Modell: 1H * Serien Nummer: C * Boot Prom Version: * Portanzahl: 24 Ausgehend von der Werkskonfiguration wurden am Switch, wie in [15] beschrieben, Telnet, Webserver und der Standard-Account deaktiviert. Zusätzlich wird, wie in Listing 4.1 dargestellt, in dem beschriebenen Testaufbau SNMPv2 verwendet. Aus Sicherheitsgründen, wie Unterstützung von Verschlüsselung durch Data Encryption Standard (DES) und Integritätssicherung durch MD5 - oder Secure Hash Algorithm-1 (SHA-1) - Hashalgorithmen, die in [29] genauer dargestellt werden, ist in Produktivumgebungen SNMPv3 vorzuziehen. Enterasys stellt unter [14] ein grafisches Programm zur Sicherheitsüberprüfung der Switches zur Verfügung. Um einen reibungslosen Testaufbau zu gewährleisten, wird diese Absicherung erst am Ende des Konfigurationsabschnittes durchgeführt. Listing 4.1: SNMPv2 Konfiguration 1 Matrix > sh snmp community 2 3 Community Name : % m1k3_ s3cr3t % 4 Security User Name : initial 5 SNMP Engine ID: 80:00:38:18:03:00:01: f4 :71:20:48 6 Storage Type : nonvolatile 7 Row Status : active

50 4. Implementierung 41 - Radiusserver In der Testumgebung übernimmt der Radiusserver auch weitere Aufgaben, wie DHCP-, DNS-, File- und Webserver. In Produktivumgebungen wird nicht zu einer solchen Vorgehensweise geraten, da eventuell vorhandene Sicherheitslücken in diesen Diensten den Radiusserver angreifbar machen. * IP Adresse: * Betriebssystem: Debian GNU/Linux 3.1 * Kernel: * Radiusserver: FreeRadius * Weitere Dienste: DHCP-Server, Fileserver (NFS/SMB), DNS-Server, Webserver * Switchport Nr.: Port 1 * Authentifizierungstyp: keine Authentifizierung * Switchport Defaultpolicy: rserver Der Radiusserver erhält seine eigene Defaultpolicy, da er das einzige Gerät im Netzwerk ist, welches sich nicht authentifizieren muss. Dementsprechend ist er immer an einem fixen Switchport angeschlossen, bei dem Authentifizierung deaktiviert ist. Auf Grund der zusätzlichen Funktionen, die der Radiusserver in der Testumgebung übernimmt, ist es nicht möglich eine eingeschränkte Defaultpolicy rserver zu erstellen. Da Endgeräte mit dem Betriebssystem Windows Vista erst seit dem Release von FreeRadius unterstützt werden, wurde diese Version nach Anleitung des FreeRadius-Wiki [4] aus dem Quellcode installiert und in die Debian- Paketverwaltung integriert.

51 4. Implementierung 42 - Monitoringserver * IP Adresse: * Betriebssystem: Debian GNU/Linux 3.1 * Kernel: tsc * Weitere Dienste: Nagios, Multi Router Traffic Grapher (MRTG), Webserver * Switchport Nr.: Port 3 * Authentifizierungstyp: MAC basierte Authentifizierung * Switchport Defaultpolicy: default - Managementserver Im Versuchsaufbau befindet sich die Management-Clientsoftware sowie die Serversoftware auf demselben Rechner. Im Produktivbetrieb ist es zusätzlich noch möglich auf weiteren Rechnern die Clientsoftware zu installieren und sich somit immer auf den Verwaltungsserver zu verbinden. * IP Adresse: per DHCP vergeben * Betriebssystem: Windows XP SP2 * Weitere Dienste: Netsight Console, Policy Manager * Switchport Nr.: Port 23 * Authentifizierungstyp: 802.1x * Switchport Default Policy: default - Desktoprechner Darunter werden die mobilen Endgeräte ebenso wie die fixen Standgeräte verstanden verstanden. * IP Adresse: per DHCP vergeben * Betriebssysteme: Windows XP SP2, Windows Vista, MAC OS X , Debian GNU/Linux testing * Switchport Nr.: unterschiedlich * Authentifizierungstyp: 802.1x * Switchport Default Policy: default

52 4. Implementierung 43 Von Windows-XP (Service Pack 2), Windows Vista und MAC OS X wird Authentifizierung über 802.1x direkt unterstützt. Bei linuxbasierenden Betriebsystemen sollte die Dokumentation der Distribution hinzugezogen werden. Im Falle von Debian GNU/Linux 4.0 muss mit dem Paketverwaltungssystem das Paket xsupplicant nachinstalliert und anschließend über die Konfigurationsdatei /etc/xsupplicant/xsupplicant.conf eingerichtet werden. 4.2 Praktische Umsetzung In den nachfolgenden Punkten wird die praktische Umsetzung genauer betrachtet. Die Festlegung, Erstellung und Implementierung der Policies wird in Abschnitt behandelt. Im Anschluss werden die wichtigsten Konfigurationen des Radiusservers in Abschnitt ausgearbeitet. Abschließend werden in Abschnitt Überlegungen zur weiteren Absicherung des Radiusservers angestellt Beschreibung der Policies Bei den nachfolgenden Policies handelt es sich um reine Testpolicies, die für Demonstrationszwecke kreiert wurden. - default Diese Policy liegt als Defaultpolicy auf allen Switchports, ausgenommen ist nur der Port des Radiusservers. Die Defaultpolicy hat die Aufgabe keinen Netzwerkverkehr weiterzuleiten und wird wie in Abbildung A.2 dargestellt eingerichtet und wie in Abbildung A.3 dargestellt aktiviert. In Abbildung A.1 ist ersichtlich, dass bis auf den Radiusport alle Switchports mit der default-policy belegt sind und bei einem erfolgreichen Authentifizierungsvorgang dynamisch die zugeordnete Rolle übernehmen. - rserver Wird als allgemeine Serverpolicy verwendet und es kommt für diese Endgeräte zu keinen Einschränkungen. In Abbildung A.1 ist die dynamische Zuordnung an Port zwei, drei und fünf ersichtlich. Diese dynamische Zuordnung erfolgt aufgrund

53 4. Implementierung 44 von MAC-basierender Authentifizierung. Zusätzlich ist die statische Zuordnung des Ports, an dem der Radisuserver hängt, ersichtlich. - wlan Wird verwendet um mittels MAC-basierender Authentifizierung die nichtpolicyfähigen WLAN-Access Points zu authentifizieren. Durch diese Vorgehensweise erhalten alle Benutzer, die sich über WLAN am Netzwerk anmelden, dieselbe Policy. Diese Policy ist aus Sicherheitsgründen erheblich eingeschränkt und lässt nur die wichtigsten Dienste im Netzwerk zu. Mit einer solchen Vorgehensweise ist es möglich weitere nicht-policyfähige NAS zu verwenden und einen langsamen Umstieg auf ein policybasiertes Authentifizierungssystem durchzuführen. Durch MAC-basierte Authentifizierung der WLAN-Access Points können zugelassene Access Points wiederum zentral, durch einen Benutzereintrag wie in Listing 4.8 dargestellt, freigegeben werden. Durch den Authentifizierungsvorgang der Access Points wird sichergestellt dass keine unbekannten WLAN-Zugriffspunkte im Netzwerk vorhanden sind. Die im Rahmen dieser Implementierung verwendete Policy, welche in Abbildung A.4 und in Listing 4.12 dargestellt ist, dient rein zu Demonstrationszwecken und stellt keinen praktischen Nutzen dar. - users Im Testbetrieb wird als 802.1x-Benutzerpolicy die WLAN-Policy, die in Abbildung A.4 und in Listing 4.12 dargestellt ist, verwendet. - admins Für Administratoren gibt es keine Einschränkungen im Netzwerk. Sie sind privilegiert sich auf den Switches anzumelden und diese zu verwalten. In Abbildung A.1 ist die dynamische Zuordnung der administrativen Policy an Port 23 zu erkennen Einrichtung des Radiusservers Aus Sicherheitsgründen wird der Radiusserver nicht im privilegierten Modus betrieben. Durch die Verwendung einer anderen Benutzerkennung als der administrativen Root-Kennung (mit User ID (UID) von Null) hat ein Angreifer, der beispielsweise

54 4. Implementierung 45 durch eine Schwachstelle im Radiusdienst eindringt, keine privilegierten Berechtigungen. Durch ein solches, abgestuftes Berechtigunsmodell ist es möglich administrative Aufgaben hierarchisch zu unterteilen, wodurch automatisch ein zusätzlicher Schutz gegen Fehlbedienung geschaffen wird. Wie aus Listing 4.2 ersichtlich ist, wird der Radiusdienst unter der Benutzer- und Gruppenkennung freerad betrieben. Listing 4.2: /etc/freeradius/radiusd.conf 1 #... 2 user = freerad 3 group = freerad 4 #... 5 port = #... Laut RFC 2865 [27] beantwortet der Radiusdienst Anfragen auf Port An Port 1813 werden Accouting-Informationen übermittelt. In der Praxis wird häufig Port 1645 für Radiusanfragen verwendet, wodurch sich der Accounting-Port zu 1646 ändert. Durch die weite Verbreitung von PEAP wird dieses, wie in Listing 4.3 folgt, unter Verwendung von Microsoft Challenge Handshake Authentication Protocol Version 2 (MSCHAPv2), konfiguriert. Die Zertifikatskonfiguration von PEAP wird im Bereich der Transport Layer Security (TLS)-Konfiguration durchgeführt. Um für die Generierung der Zufallszahlen das Linux-Device /dev/urandom zu verwenden, muss der Parameter random file auf /dev/urandom gesetzt werden. MSCHAPv2 benötigt keine weitere Konfiguration. Listing 4.3: /etc/freeradius/eap.conf 1 eap { 2 default_ eap_ type = peap 3 #... 4 tls { 5 private_ key_ password = whatever 6 private_key_file = ${ raddbdir }/ certs /cert - srv. pem 7 certificate_file = ${ raddbdir }/ certs /cert - srv. pem

55 4. Implementierung 46 8 CA_file = ${ raddbdir }/ certs / democa / cacert. pem 9 dh_file = ${ raddbdir }/ certs /dh 10 random_ file = ${ raddbdir }/ certs / random } 11 # peap { 13 default_ eap_ type = mschapv2 14 copy_request_to_tunnel = yes 15 use_ tunneled_ reply = yes } 16 mschapv2 { } 17 } Um unterschiedlichen Geräten die benötigten Parameter mitzugeben, werden huntgroups, wie in Listing 4.4 folgt, konfiguriert. Bei der Definition von huntgroups ist darauf zu achten, dass immer Geräte, welche die gleichen Parameter benötigen, zusammengefasst werden. Durch diese Gruppierung ist es anschließend unter Verwendung der Benutzerdatei möglich für unterschiedliche Gerätegruppen die korrekten Parameter zu definieren. Listing 4.4: /etc/freeradius/huntgroups 1 local NAS -IP - Address == local NAS -IP - Address == linksys NAS -IP - Address == #... In der vorhandenen Testumgebung wird die Parameterübermittlung nur für den Enterasys-Switch benötigt. Durch eine Aufteilung in huntgroups ist es ohne weiteres möglich, auch zu einem späteren Zeitpunkt unterschiedliche Geräteparameter zu definieren. Einem Enterasys-Switch wird mit dem Parameter Filter-ID mitgeteilt, welche Policy anzuwenden ist und welche Privilegien der Benutzer erhalten soll. Ein beispielhafter Eintrag einer Filter-ID ist in Listing 4.5 dagestellt. Die Konfiguration der Übergabeparameter durch eine Filter-ID erfolgt in der FreeRADIUS-Benutzer-Konfigurationsdatei. Listing 4.5: Filter-ID 1 Filter -ID ==" Enterasys : version =1: mgmt =su: policy = Admin - Policy " Wird der Parameter mgmt=su entfernt, hat der Benutzer keine Berechtigung sich auf dem NAS einzuloggen und die Konfiguration zu bearbeiten.

56 4. Implementierung 47 Ein vollständiges Konfigurationsbeispiel wird in Listing 4.8, in dem auch die Verwendung von huntgroups ersichtlich ist, dargestellt. Um einem Cisco-Switch mittels Parametermitgabe dynamische VLAN-Zuordnung zu ermöglichen, wird ein Benutzereintrag wie in Listing 4.6 erweitert: Listing 4.6: dynamische VLAN Zuordnung per Parameter 1 micmes User - Password == " geheim ", Huntgroup - Name == " cisco " 2 Tunnel - Type :1=13, 3 Tunnel - Medium - Type :1=6, 4 Tunnel - Private - Group -ID :1=1 5 Reply - Message = " Hello, %u", 6 Fall - Through = No Die verwendeten Parameter Tunnel-Type, Tunnel-Medium-Type und Tunnel-Private- Group-ID geben an, dass es sich um ein 802-Netzwerk handelt, dass eine VLAN-ID übergeben wird und welches VLAN zugeordnet wird. Eine genauere Darstellung dieser Parameter erfolgt in [31]. In [11] wird die Parameterübergabe durch Radius detailliert beschrieben. In Listing 4.7 sind Ausschnitte der Clientkonfiguration ersichtlich. In dieser Datei muss jedes Gerät, welches als NAS fungiert, mit dem korrekten geheimen Schlüssel eingetragen werden. Anschließend dient der shortname als Identifizierungsmöglichkeit in den Logfiles. Listing 4.7: /etc/freeradius/clients.conf 1 #... 2 client { 3 secret = % m1k3_ s3cr3t % 4 shortname = m1k3_ wlan 5 nastype = other 6 } 7 client { 8 secret = % m1k3_ s3cr3t % 9 shortname = m1k3_ enterasys 10 nastype = rfc }

57 4. Implementierung 48 Der nastype ist geräteabhängig und lässt sich über die dictionary-datei, welche im FreeRADIUS-Konfigurationsverzeichnis zu finden ist, bestimmen. Für Cisco-Switches als NAS müsste der nastype auf cisco geändert werden. Listing 4.8: /etc/freeradius/users 1 #... 2 micmes User - Password == "* geheim *", Huntgroup - Name == " enterasys " 3 Filter -ID == " Enterasys : version =1: mgmt =su: policy = admins ", 4 Reply - Message = " Hello, %u", 5 Fall - Through = No 6 7 micmes User - Password == "* geheim *", Huntgroup - Name!= " enterasys " 8 Reply - Message = " Hello, %u", 9 Fall - Through = No micmes User - Password == "* geheim *" 12 Reply - Message = " Hello, %u", 13 Fall - Through = No ##################################################### 16 ## Geraete die per MAC-Adr. Authentifiziert werden ## 17 ##################################################### #WLAN - Access Point F-B7-6B User - Password == " m1k3s3cr3t ", \\ 21 Huntgroup - Name == " enterasys " 22 Filter -ID == " Enterasys : version =1: policy = wlan ", 23 Reply - Message = " Hello, %u", 24 Fall - Through = No WLAN-Policy Der verwendete WLAN-Access Point ist nicht policyfähig, wodurch Access Points mittels MAC-basierender Authentifizierungstechnologie am Netzwerk angemeldet werden und ihnen eine definierte Policy zugeordnet werden kann. In Abbildung A.5 ist sowohl ein erfolgreich authentifizierter WLAN-Access Point dargestellt als auch ein abgeschlossener 802.1x-Authentifizierungsvorgang. Um zu verhindern, dass Parameter eines

58 4. Implementierung 49 Enterasys-Gerätes an ein nicht-policyfähiges Endgerät übermittelt werden, kann mit dem in Listing 4.9 dargestellten Benutzereintrag gearbeitet werden. Listing 4.9: Paramterunterdrückung bei WLAN-Usern 1 micmes User - Password ==" geheim ",Huntgroup - Name!=" enterasys " 2 Reply - Message =" Hello, %u", 3 Fall - Through =No Durch Anwendung von 802.1x Authentifizierung ohne Policies, ist das Netzwerk, sobald ein Benutzer Zugriff erlangt hat, nicht weitergehend geschützt. In Listing 4.10 ist ein Portscan eines authentifizierten WLAN-Endsytems ersichtlich. Der Portscan richtet sich gegen den verwendeten Radiusserver. Listing 4.10: Portscan vor WLAN-Policy 1 nmap Interesting ports on : 4 ( The 1651 ports scanned but not shown below are in state : closed ) 5 PORT STATE SERVICE 6 21/ tcp open ftp 7 25/ tcp open smtp 8 53/ tcp open domain 9 80/ tcp open http / tcp open rpcbind / tcp open auth / tcp open netbios - ssn / tcp open smux / tcp open rsh - spx / tcp open https / tcp open microsoft - ds / tcp open ipp / tcp open unknown / tcp open unknown / tcp open nessus / tcp open nfs / tcp open ppp / tcp open mysql / tcp open postgres

59 4. Implementierung / tcp open mythtv / tcp open mythtv 27 MAC Address : 00: 02: 44: 53: E1 :3 C ( Surecom Technology Co.) Die in den Listings 4.11, 4.12 und 4.13 dargestellte Policykonfigurationen werden vollständig über den in Abschnitt vorgestellten NetSight R Policy Manager konfiguriert. In Anhang A.3 befinden sich Screenshots der Policy Manager Konfiguration. Listing 4.11: Policyerstellung 1! policy profile 2 set policy profile 1 " admins " disable 1 disable 0 3 set policy profile 1 enable 4 set policy profile 2 " wlan " disable 1 disable 0 5 set policy profile 2 enable 6 set policy profile 3 " users " disable 1 disable 0 7 set policy profile 3 enable 8 set policy profile 4 " rserver " disable 1 disable 0 9 set policy profile 4 enable 10 set policy profile 5 " default " enable 0 disable 0 11 set policy profile 5 enable Der Konfigurationseintrag der Defaultpolicy erstellt eine Policy mit einer ID von fünf und den Namen default. Der folgende Eintrag enable 0 gibt an dass der vollständige Netzwerkverkehr, der nicht authentifiziert ist, verworfen wird. Der abschließende Eintrag disable 0 behandelt Class of Service welches für die praktische Umsetzung im Rahmen dieser Arbeit nicht weiter betrachtet wird, für genauere Informationen wird auf das Konfigurationshandbuch, welches unter [15] verfügbar ist, verwiesen. Zu Demonstrationszwecken wurde aufbauend auf den Portscan aus Listing 4.10 die in Listing 4.12 und in Abbildung A.4 dargestellte Policy für WLAN-Zugriffe erstellt: Listing 4.12: Einrichten der Policies 1 set policy classify 2 1 vlan 0 tcpbilrange set policy classify 2 2 vlan 0 tcpportbil set policy classify 2 3 vlan 0 tcpportbil set policy classify 2 5 vlan 0 tcpportbil set policy classify 2 6 vlan 0 tcpportbil 5432

60 4. Implementierung 51 6 set policy classify 2 7 vlan 0 tcpportbil set policy classify 2 8 vlan 0 tcpportbil set policy classify 2 9 vlan 0 tcpportbil set policy classify 2 10 vlan 0 tcpportbil set policy classify 2 11 vlan 0 tcpportbil set policy classify 2 12 vlan 0 tcpbilrange 1 19 In Listing 4.12 werden die als letzter Parameter angegebenen TCP-Ports gesperrt. Alle angegebenen Regeln gehören zur Policy zwei, die in Listing 4.11 als WLAN-Policy definiert wurde. Die Port-Zuordnung der Defaultpolicy wird an Hand der Ports sieben bis neun in Listing 4.13 dargestellt. Port sieben und acht werden mit der Policy fünf, welche in Listing 4.12 eingerichtet wurde, belegt. Bei Port neun handelt es sich um den Port des WLAN-Access Points. Port neun wird mit Policy zwei, die wiederum in Listing 4.11 erstellt wurde und in Listing 4.12 eingerichtet wurde, ausgestattet. Listing 4.13: Aktivierung der Policies 1 set policy port fe set policy port fe set policy port fe Sobald die Zuordnung einer Policy zu einem Port, wie in Listing 4.13 ersichtlich ist, durchgeführt wurde, ist diese Policy aktiv und es kommt bei einem erneuten Portscan zu dem in Listing 4.14 dargestellten Ergebnis. Listing 4.14: Portscan mit aktiver WLAN-Policy 1 nmap Interesting ports on : 4 ( The 1631 ports scanned but not shown below are in state : closed ) 5 PORT STATE SERVICE / tcp filtered msp 8 19/ tcp filtered chargen 9 21/ tcp open ftp 10 23/ tcp filtered telnet

61 4. Implementierung / tcp open smtp 12 53/ tcp open domain 13 80/ tcp open http / tcp open rpcbind / tcp open auth / tcp open netbios - ssn / tcp filtered smux / tcp open rsh - spx / tcp open https / tcp open microsoft - ds / tcp filtered ipp / tcp filtered unknown / tcp filtered unknown / tcp filtered nessus / tcp open nfs / tcp filtered ppp / tcp filtered mysql / tcp filtered postgres / tcp filtered mythtv / tcp filtered mythtv 31 MAC Address : 00: 02: 44: 53: E1 :3 C ( Surecom Technology Co.) Absicherung des Radiusservers Der Radiusserver stellt - als zentrale Schnittstelle zwischen dem Netzwerk und dem Authentication-Service - einen Single Point of Failure dar. Neben den vorausgesetzten Sicherungsmaßnahmen, wie unter anderem Virenscanner, deaktivieren unnötiger Dienste, regelmäßige Sicherheitsupdates, werden in den folgenden Punkten der Schutz von Schadsoftware durch chkrootkit behandelt. Zusätzliche wird eine automatisierte Überprüfung auf Dateiänderungen mit tripwire durchgeführt und mit den Daemontools wird der Radiusdienst bei Abstürzen automatisiert neu gestartet.

62 4. Implementierung 53 System mit chkrootkit vor Schadsoftware schützen: Das System wird täglich durch den in Listing A.7 dargestellten Cron-Job und unter zu Hilfenahme von chkrootkit-0.46a [22] auf Schadsoftware untersucht. Bei Systemveränderungen erfolgt eine Benachrichtigung an den Administrator. Listing 4.15: /etc/cron.daily/chkrootkit $loggeropt " starting chkrootkit " 3 cd $CHKPATH 4./ chkrootkit > / tmp / chkrootkit 5 6 message = grep INFECTED "/ tmp / chkrootkit " 7 if [ $? -eq 0 ]; then 8 $loggeropt " WARNING : INFEKTION wurde festgestellt!!" 9 $loggeropt $message 10 cat / tmp / chkrootkit mail $MAILTO echo - s WARNING : \\ 11 chkrootkit INFECTED auf _ hostname 12 else 13 $loggeropt " keine Infektion wurde festgestellt!!" 14 cat / tmp / chkrootkit mail $MAILTO echo - s chkrootkit - \\ 15 output von _ hostname 16 fi $loggeropt " chkrootkit fuer hostname. $domainname wurde durchgefuehrt " 19 $loggeropt " =========== date +% F -% T =========== " exit 0 Radiusdienst vor Abstürzen sichern: Mit Hilfe der Daemontools von [3] ist es möglich, Dienste, deren Ausfall kritisch ist, bei einem Ausfall automatisiert neu zu starten. Durch den in Listing 4.16 dargestellten Inittab-Eintrag starten die Daemontools beim Startvorgang des Betriebssystems alle unter dem service-verzeichnis konfigurierten Dienste.

63 4. Implementierung 54 Listing 4.16: /etc/inittab #-- daemontools-run begin 3 SV :3: respawn :/ command / svscanboot 4 #-- daemontools-run end Wie aus dem Startscript in Listing 4.17 durch den Parameter X ersichtlich, wird im Rahmen der ersten Testphase der Radiusserver im Debug-Modus betrieben. Die Standardausgabe wird mit Hilfe des Programmes tee in eine eigenständige log-datei (radius-complete.log) umgeleitet und gleichzeitig auf die Standardausgabe ausgegeben. Aufgrund des hohen Umfanges dieser Meldungen werden zusätzlich, durch Listing 4.18, die Anmeldeversuche in einer seperaten log-datei (radius.log) mitprotokolliert. Listing 4.17: /etc/radiusd/run ARGS ="-X" 4 5 test - f $RADIUSD exit 0 6 test - f $RADDBDIR / radiusd. conf exit $loggeropt " ============ date +% F -% T ============ " 9 $loggeropt " Starting $DESC... " 10 exec nice - n $NICELEVEL $RADIUSD $ARGS \\ 11 tee $logdir / radius - complete. log 12 $loggeropt "... Finished $DESC " 13 $loggeropt " ============ date +% F -% T ============ " exit 0 Damit der Radiusdienst mit einer höheren Prozesspriorität arbeitet als normale Benutzerund System- Programme, wird zusätzlich mit dem Programm nice die Priorität auf -10 gestellt.

64 4. Implementierung 55 Listing 4.18: /etc/init.d/rc.local - gekürzt 1 #! /bin/sh 2 # 3 #... 4 #waehrend der radiusd im debug-mode betrieben wird, wird mit 5 #folgender Zeile das normale radius.log geschrieben: 6 tail -f / var / log / freeradius / radius - complete. log \\ 7 grep -- line - buffered Login >> \\ 8 / var / log / freeradius / radius. log & System mit Tripwire vor Veränderungen schützen: Mit Tripwire ist es möglich, die Dateiintegrität eines Systems mit verschiedenen Algorithmen zu überprüfen. Für die Überprüfung unterstützt Tripwire Cyclic Redundancy Check-32 (CRC32), MD2, MD4, MD5, SHA und Snefru. Standardmäßig wird MD5 und Snefru verwendet [2]. Damit Tripwire auch nicht von einem Angreifer, der root-rechte erlangt hat, manipuliert werden kann, werden sowohl die Datenbanken als auch die Konfigurationen von Tripwire verschlüsselt abgelegt [2]. Die Tripwire-Konfiguration am Radiusserver wurde um die in Listing 4.19 dargestellten Einträge für FreeRADIUS ergänzt: Listing 4.19: /etc/tripwire/twpol.txt 1 # 2 # freeradius 3 # 4 ( 5 rulename = " freeradius Files ", 6 severity = $( SIG_HI ), 7 to = root 8 ) 9 { 10 / etc / freeradius / radiusd. conf -> $( SEC_CRIT ) ; 11 / etc / freeradius / clients. conf -> $( SEC_CRIT ) ; 12 / etc / freeradius / certs -> $( SEC_CRIT ) ; 13 / etc / freeradius / huntgroups -> $( SEC_CRIT ) ;

65 4. Implementierung / etc / freeradius / eap. conf -> $( SEC_CRIT ) ; 15 / etc / freeradius / users -> $( SEC_CRIT ) ; 16 / etc / radiusd / run -> $( SEC_CRIT ) ; 17 / etc / inittab -> $( SEC_CRIT ) ; 18 / usr / sbin / freeradius -> $( SEC_BIN ) ; 19 / package / admin / daemontools / command -> $( SEC_BIN ) ; } Wie aus Listing 4.19 ersichtlich ist, werden mittels Tripwire alle relevanten FreeRADIUS Konfigurationsdateien, ausführbare Dateien sowie die von den Daemontools benötigten Dateien überwacht. Tripwire führt - mittels Cron-Job - einmal täglich eine Überprüfung auf Dateiänderungen durch und benachrichtigt den Administrator anschließend per Mail.

66 4. Implementierung Weitere Möglichkeiten In heutigen Netzwerkumgebungen gibt es verschiedenste Dienste, die durch Authentifizierungssysteme abgesichert sind. Ein Beispiel hierfür sind Webserver, die mittels htaccess abgesichert sind, oder einfache Anmeldevorgänge an linuxbasierenden Betriebssystemen. Benutzer müssen sich an File Transfer Protocol (FTP)-Zugängen ebenso anmelden wie an gesicherten VPN-Netzwerkzugängen. Jeder dieser Dienste verwendet üblicherweise seine eigenen Passwortinformationen. Durch die Implementierung des radiusbasierenden Netzwerkauthentifizierungssystems besteht bereits eine einheitliche Schnittstelle zwischen Directory-Service und den zu authentifizierenden Endsystemen. Diese Schnittstelle lässt sich unter Zuhilfenahme von Pluggable Authentication Modules (PAM) für die meisten Dienste, die keine Radiusunterstützung besitzen, zur Anbindung an einen Radiusserver verwenden Pluggable Authentication Modules Mit PAM ist es möglich festzulegen, wie Linux-Anwendungen ihre Authentifizierung durchführen, ohne diese umschreiben und neu kompilieren zu müssen. In aktuellen Distributionen sind bereits PAMs für die meisten Dienste, die Authentifizierung erfordern, integriert [2]. Folgende Auflistung stellt einige typische PAM-Module, die in [2] definiert wurden, dar: - pam cracklib Dient zur proaktiven Prüfung von Passwörtern. - pam deny Dieses Modul dient der Benachrichtigung von Anwendungen über fehlgeschlagene Authentifizierungen. - pam pwdb Durch dieses Passwortdatenbankmodul werden Warnmeldungen, Passwortablauf und Passwortalterung bereit gestellt.

67 4. Implementierung Radiusanbindung von proftp Für die Radiusanbindung mittels PAM muss auf einem Debian-Linux das libpamradius-auth Paket nachinstalliert werden. Wie in Listing 4.20 ersichtlich, muss der Radiusserver mit dem geheimen Schlüssel in der Konfigurationsdatei des Moduls eingetragen werden. Listing 4.20: /etc/pam radius auth.conf - gekürzt 1 # server[:port] shared_secret timeout (s) :1812 % m1k3_s3cr3t % 2 Die in Listing 4.20 dargestellte Konfigurationsdatei gilt für alle PAM-Module und kann auch mehrere Radiuseinträge enthalten. Wenn mehrere Radiuseinträge vorhanden sind, werden diese erst verwendet, wenn der erste Radiusserver auf die Authentifizierungsanfrage nicht antwortet. Das PAM-Modul des ProFTP-Servers muss für die Verwendung des Radiusservers folgendermaßen vorbereitet werden: Listing 4.21: /etc/pam.d/proftpd - gekürzt 1 #%PAM auth sufficient pam_ radius_ auth. so debug Wie aus den Statusmeldungen des Radiusservers in Listing 4.22 und 4.23 ersichtlich, wird ein Loginversuch am FTP Server über den Radiusserver abgewickelt und der Benutzer wird über den im Hintergrund liegenden, Directory-Service authentifiziert. Listing 4.22: FTP-Authentifizierungvorgang - Teil 1 1 rad_ recv : Access - Request packet from host : 22335, id =221, 2 length =94 3 User - Name = " micmes " 4 User - Password = "* entfernt *" 5 NAS -IP - Address = NAS - Identifier = " proftpd " 7 NAS - Port = NAS - Port - Type = Virtual 9 Service - Type = Authenticate - Only 10 Calling - Station -Id = " "

68 4. Implementierung 59 In Listing 4.22 ist die PAM-Anfrage des FTP-Moduls ersichtlich. Die NAS-IP Adresse ist in diesem Fall der lokale Rechner, Identifier ist der ProFTP-Daemon und der Benutzer micmes benötigt einen Zugang. Listing 4.23: FTP-Authentifizierungvorgang - Teil 2 1 users : Matched entry micmes at line modcall [ authorize ]: module " files " returns ok for request 0 3 modcall : leaving group authorize ( returns ok) for request 0 4 auth : type Local 5 auth : user supplied User - Password matches local User - Password 6 radius_ xlat : Hello, micmes 7 Login OK: [ micmes /* entfernt *] ( from client localhost port cli ) Sending Access - Accept of id 221 to port Reply - Message = " Hello, micmes " Der Radiusdienst findet den Benutzer micmes in seiner Benutzerdatenbank und kann diesen auch erfolgreich authentifizieren. Der anfragende Benutzer erhält somit den gewünschten FTP-Zugang Radiusanbindung des Loginsystems von Linux Für den lokalen Loginvorgang ist es empfehlenswert ein System, das auch bei Ausfall des Radiusservers funktioniert, einzurichten. In Listing 4.24 wird ein solches Beispiel gezeigt. Listing 4.24: /etc/pam.d/login - gekürzt ##Radius-Authentifizierung 3 auth sufficient pam_ radius_ auth. so debug 4 #Fallback falls Authentifizierung über Radius fehl schlägt: include common - auth 6 ## 7...

69 4. Implementierung 60 In der Datei /etc/pam.d/login wird die Zeile der Authentifizierung nicht ersetzt, sondern die Zeile der Radiusauthentifzierung davor eingefügt. Dadurch wird der erste Login-Versuch über den Radiusserver abgewickelt. Schlägt dieser Authentifizierungsvorgang fehl, wird ein zweiter Versuch mit den lokalen Benutzerdaten durchgeführt Radius-Anbindung eines Linux-Endsystems Um alle PAM-fähigen Dienste eines Linux-Endanwendersystems, mit Debian-Testing (Etch) als Betriebssystem, an einen zentralen Radiusserver anzubinden, müssen die in diesem Kapitel dargestellten Anpassungen vorgenommen werden. Wie in Kapitel dargestellt, muss das PAM-Radiusmodul nachinstalliert und eingerichtet werden. Durch die in Listing 4.26 dargestellten Anpassungen des Listings 4.25 werden alle Dienste, die ihre Authentifizierung mittels PAM duchführen, automatisch auf Radius- Authentifizierung umgestellt. Listing 4.25: /etc/pam.d/common-auth - original 1 auth required pam_ unix. so nullok_ secure Listing 4.26: /etc/pam.d/common-auth - Radius 1 auth sufficient pam_ radius_ auth. so debug Durch die Definition unterschiedlicher huntgroups, wie aus Listing 4.4 deutlich wird, lässt sich nun über die Benutzerdefinition festlegen, an welchen NAS welche Parameter übergeben werden. Im Listing 4.27 ist ein Authentifizierungsvorgang einer - durch kscreensaver - gesperrten Arbeitsstation ersichtlich. Listing 4.27: Beispiel eines Authentifizierungsvorgang 1 rad_ recv : Access - Request packet from host : 5347, id =52, 2 length =84 3 User - Name = " micmes " 4 User - Password = "* entfernt *" 5 NAS -IP - Address = NAS - Identifier = " kscreensaver "

70 4. Implementierung 61 7 NAS - Port = NAS - Port - Type = Virtual 9 Service - Type = Authenticate - Only Wie in Listing 4.27 ersichtlich, erfolgt die Anfrage von der Arbeitsstation mit der IP- Adresse Durch die Verwendung von PAM wird der virtuelle NAS mit der IP-Adresse verwendet. Durch den in Listing 4.28 dargestellten Benutzereintrag in /etc/freeradius/users erhalten alle Anfragen, die von keinem Enterasys Gerät stammen, keine Parametermitgabe. Listing 4.28: FreeRADIUS - Benutzereintrag micmes User - Password == "* entfernt *", Huntgroup - Name!= 2 " enterasys " Reply - Message = " Hello, %u", Fall - Through = No Durch den in Listing 4.28 dargestellten Benutzereintrag, kommt es zu der in 4.29 dargestellten Authentifizierung und der Benutzer erhält Zugang zur Arbeitsstation. Listing 4.29: Beispiel eines Authentifizierungsvorgang 1 users : Matched entry micmes at line modcall [ authorize ]: module " files " returns ok for request 0 3 modcall : leaving group authorize ( returns ok) for request 0 4 auth : type Local 5 auth : user supplied User - Password matches local User - Password 6 radius_ xlat : Hello, micmes 7 Login OK: [ micmes /* entfernt *] ( from client m1k3_ clients port 4322) Sending Access - Accept of id 52 to port Reply - Message = " Hello, micmes "

71 4. Implementierung Weitere Dienste Folgende Dienste wurden im Rahmen der Diplomarbeit getestet und lassen sich ebenso mit Hilfe des PAM-Moduls an einen zentralen Radiusserver anbinden: - Switch User (su) - Substitute User Do (sudo) - Change Shell (chsh) - Change Full Name (chfn) - Secure Shell (SSH)-Zugriff - VPN (z.b. über die verwendete m0n0wall) - Graphical Display Manager (GDM) - KDE Display Manager (KDM) - Kscreensaver - Xscreensaver - Apache (Authentifizierung mittels htaccess)

72 5 Technische Ergebnisse Im Rahmen der praktischen Umsetzung eines policybasierenden Netzwerk-Authentifizierungssystems wurde ein möglichst praxisnahes und heterogenes Testnetzwerk aufgebaut, in dem sich alle modernen Client-Betriebssysteme einbinden lassen. Bevor ein Benutzer Zugriff zum Netzwerk und somit auch Zugriff zu den unterschiedlichen Services erhält, findet ein Authentifizierungsvorgang statt. Bei diesem Vorgang muss sich jeder Benutzer mit einem Benutzernamen und einem Passwort ausweisen. Als erster Zugriffspunkt für kabelgebunde Endgeräte wurde ein policyfähiger Switch der Matrix Serie von Enterasys verwendet. Die Konfiguration der Policies wurde mit dem von Enterasys vorgesehen Policy-Manager durchgeführt. Endgeräte mit WLAN-Unterstützung können sich über einen Linksys-WLAN Router authentifizieren. Da dieses Gerät nicht policyfähig ist, wird eine sehr eingeschränkte Default-Policy am Switchport des Enterasys Gerätes angewendet. Durch die Nutzung von Default-Policies ist es möglich, für eine Übergangsphase unterschiedliche, nicht policyfähige Netzzugriffspunkte einzusetzen. Um ein flexibles Sicherheitssystem zu erstellen, wurde das AAA-Modell unter Zuhilfenahme des 802.1x Authentifizierungssystems verwendet. Für den Authentifizierungsvorgang kommt PEAP zum Einsatz. Dieses Protokoll gehört dem EAP- Framework an und ermöglicht einen abgesicherten und für den Anwender möglichst einfachen Authentifizierungsvorgang. Aufgrund der Verwendung des EAP-Frameworks ist eine zukünftige Erweiterbarkeit des Authentifizierungssystems gewährleistet. Als Authentifizierungsserver kam der flexible Open Source Radiusserver FreeRADIUS zum Einsatz. Über den Radiusserver, als zentrale Schnittstelle zum Directory Dienst, wurde zusätzlich zu 802.1x Authentifizierung auch die Anmeldefunktion verschiedener anderer 63

73 5. Technische Ergebnisse 64 Dienste, die in Abschnitt dargestellt sind, abgewickelt. Alle diese Dienste greifen auf eine zentrale Benutzerdatenbank zu, wodurch ein einheitliches Verwaltungssystem geschaffen werden kann. Durch die Policyanwendung am ersten Netzwerkzugriffspunkt wird es ermöglicht, das interne Netzwerk bereits ab diesem äußersten Zugriffspunkt abzusichern und somit nur genau definierte Dienste und Funktionen zuzulassen.

74 6 Schlussfolgerungen Im Zuge der vorliegenden Arbeit wurden alle theoretischen und praktischen Teilbereiche eines policybasierenden Netzwerksicherheitssystems, das bereits im Access-Layer wirksam ist, behandelt. Dieses Sicherheitssystem dient als erster Schritt eines vollständigen Sicherheitskonzepts, welches ausgehend von Authentifizierung und Zugriffspolicies, über eine automatisierte Überprüfung der Endssyteme, bis hin zu Einbruchserkennung und automatisierter Einbruchsbekämpfung alles abdeckt. Durch vorgestellte Technologien, wie beispielsweise das AAA-Framework, Single Sign On, Enterasys Sentinel oder Cisco Self Defending Network, sind bereits heute Technologien und Produkte verfügbar, mit denen ein umfassendes Sicherheitskonzept ermöglicht wird. Solche Sicherheitssysteme sind allerdings nur zielführend, wenn sie auf Basis einer zentral verwalteten Sicherheitspolitik mit firmeninternen Sicherheitsrichtlinien basieren. Das Ziel eines policybasierten Sicherheitskonzeptes liegt in der Prevention unautorisierter Zugriffe auf Systeme und Dienste, wodurch die Sicherheitsrichtlinien, auf denen das Policymodell basiert, autoritär sein müssen. Durch solche Richtlinien wird vermieden, dass das System von Anfang an umgangen wird. Kommt es bei der Umsetzung, auf Grund einer schlecht definierten Sicherheitspolitik zu Ausnahmen bei der Erstellung der Policies, so bleibt der resultierende Sicherheitsgewinn minimal. 65

75 Literaturverzeichnis [1] Aboba, B. et al.: Criteria for Evaluating AAA Protocols for Network Access (IETF RFC 2989). The Internet Society, November [2] Anonymous: Der neue Linux Hacker s Guide - Sicherheit für Linux-Server und -Netze. Markt + Technik, [3] Bernstein, D. J.: daemontools. ( ). [4] Bonner, K.: Build - FreeRadius Wiki. Building_Debian_packages ( ), [5] Capite, D.: Self-Defending Networks: The Next Generation of Network Security. Cisco Press, [6] Carroll, B.: Cisco Access Control Security: AAA Administrative Services. Cisco Press, [7] Cisco Systems Inc.: Cisco Security Monitoring, Analysis and Response System Data Sheet. [8] Cisco Systems Inc.: Authentication, Authorization, and Accounting. Eine Online- Version ist verfügbar unter ( ), [9] Cisco Systems Inc.: CISCO SELF-DEFENDING NETWORKS - Overview. Eine Online-Version ist verfügbar unter ( ), [10] Cisco Systems Inc.: Cisco Network Admission Control - Q&A. Eine Online-Version ist verfügbar unter ( ),

76 Literaturverzeichnis 67 [11] Cisco Systems Inc.: Dynamic VLAN Assignment with RADIUS Server and Wireless LAN Controller Configuration Example. Eine Online-Version ist verfügbar unter ( ), [12] Conover, J.: NAC Vendors Square Off. Eine Online-Version ist verfügbar unter ( ), [13] Enterasys Networks, Inc.: Enterasys Sentinel Trusted Access Manager and Trusted Access Gateway - Data Sheet. Eine Online-Version ist verfügbar unter ( ), [14] Enterasys Networks, Inc.: Enterasys Technical Support: Online Tools. ( ), [15] Enterasys Networks, Inc.: Matrix E1 Series (1G58x-09 and 1H582-xx) Configuration Guide. Eine Online-Version ist verfügbar unter com/products/switching/e1/ ( ), [16] Fraser, B.: Site Security Handbook (IETF RFC 2196). The Internet Society, September [17] Hassel, J.: RADIUS. O Reilly, Sebastopol, [18] Institute of Electrical and Electronics Engineers: IEEE Standard for Local and metropolitan area networks - Port-Based Network Access Control. Institute of Electrical and Electronics Engineers, Inc., Juni [19] Lawrance, A.G. et al: 2005 CSI/FBI Computer Crime and Security Survey. Eine Online-Version ist verfügbar unter Documents/ ( ), [20] Mitton, D. et al.: Authentication, Authorization, and Accounting: Protocol Evaluation (IETF RFC 3127). The Internet Society, Juni [21] Nakhjiri, M. und Nakhjiri M.: AAA and Network Security for Mobile Access. Wiley, West Sussex, 2005.

77 Literaturverzeichnis 68 [22] Nelson, M. and Steding-Jessen, K.: chkrootkit locally checks for signs of a rootkit. ( ), [23] Nispel, M.: AAA Architekturen - Policy based Management und seine Zukunft. Eine Online-Version ist verfügbar unter products/whitepapers/ ( ), April [24] Nispel, M.: Secure Networks - Ein sicheres Netzwerk, nicht nur Netzwerk Sicherheit. Eine Online-Version ist verfügbar unter products/whitepapers/ ( ), April [25] Nispel, M.: Anforderungen an heutige Switching-Produkte. Eine Online-Version ist verfügbar unter ( ), Mai [26] Prantl, D. et al: Enterasys Networks - Solution Guide , [27] Rigney, C. et al.: Remote Authentication Dial In User Service (IETF RFC 2865). The Internet Society, Juni [28] Schawohl, E.: Cisco Networking Academy Program - Lehrbuch 3. und 4. Semester. Markt + Technik, [29] SNMP Research International, Inc: Security in SNMPv3 versus SNMPv1 or v2c. Eine Online-Version ist verfügbar unter snmp_research/ ( ), [30] Wang, X. et al.: Collisions for Hash Functions MD4, MD5, HAVAL-128 and RI- PEMD. Cryptology eprint Archive, Report 2004/199, /199, [31] Zorn, G. et al.: RADIUS Attributes for Tunnel Protocol Support (IETF RFC 2868). The Internet Society, Juni 2000.

78 Abkürzungsverzeichnis A AAA ACL ACS Authentication, Authorization, Accounting Access Control List Access Control Server C CHAP CHFN CHSH COPS CRC CSI Challenge Handshake Authentication Protocol Change Full Name Change Shell Common Open Policy Service Protcol Cyclic Redundancy Check-32 Computer Security Institiute D DES DHCP DNS Data Encryption Standard Dynamic Host Control Protocol Domain Name System E EAP Extensible Authentication Protocol F FTP File Transfer Protocol 69

79 Abkürzungsverzeichnis 70 G GDM GNU Graphical Display Manager GNU is not Unix H HTTP Hypertext Transfer Protocol I IAS IDS IEEE IETF IOS IP IPS IPsec IT Internet Authentication Server Intrusion Detection System Institute of Electrical and Electronics Engineers Internet Engineering Task Force Internetworking Operating System Internet Protocol Intrusion Prevention System IP Security Informationstechnologie K KDM KDE Display Manager M MAC Media Access Control MARS Monitoring, Analysis and Response System MD2/4/ Message Digest Algorithm Version 2/4/5 MRTG Multi Router Traffic Grapher MSCHAP Microsoft CHAP

80 Abkürzungsverzeichnis 71 N NAC NAK NAS Network Admission Control Not Acknoledge Network Access Server O OSI Open Systems Interconnection P PAM PAP PEAP PDU POP PPP PPTP Pluggable Authentication Modules Password Authentication Protocol Protected EAP Protocol Data Unit Point of Presence Point-to-Point Protocol Point-to-Point Tunneling Protocol Q QoS Quality of Service R Radius Remote Authentication Dial-In User Service S SCTP SHA SNMP SSH SU SUDO Stream Control Transmission Protocol Secure Hash Algorithm Simple Network Management Protocol Secure Shell Switch User Substitute User Do

81 Abkürzungsverzeichnis 72 T TCP TLS U UDP UID Transmission Control Protocol Transport Layer Security User Datagram Protocol User ID V VLAN VoIP VPN VSA Virtual Local Area Network Voice over IP Virtual Private Network Vendor Specific Attribute W WAN WLAN Wide Area Network Wireless Local Area Network

82 Anhang 73

83 A Konfigurationen In den folgenden Abschnitten sind alle Konfigurationen angeführt, die bei der Implementierung der policybasierenden Netzwerkauthentifizierung in Kapitel 4 verwendet wurden. Die Konfigurationen sind vollständig, es wurden ausschließlich die Kommentarzeilen entfernt. A.1 FreeRADIUS-Konfigurationen A.1.1 radiusd.conf Listing A.1: /etc/freeradius/radiusd.conf 1 prefix = / usr 2 exec_ prefix = / usr 3 sysconfdir = / etc 4 localstatedir = / var 5 sbindir = ${ exec_ prefix }/ sbin 6 logdir = / var / log / freeradius 7 raddbdir = / etc / freeradius 8 radacctdir = ${ logdir }/ radacct 9 confdir = ${ raddbdir } 10 run_ dir = ${ localstatedir }/ run / freeradius 11 log_file = ${ logdir }/ radius. log 12 libdir = / usr / lib / freeradius 13 pidfile = ${ run_dir }/ freeradius. pid 14 user = freerad 15 group = freerad 16 max_ request_ time = delete_blocked_requests = no 18 cleanup_ delay = 5 19 max_ requests =

84 A. Konfigurationen bind_ address = * 21 port = hostname_ lookups = no 23 allow_ core_ dumps = no 24 regular_ expressions = yes 25 extended_ expressions = yes 26 log_ stripped_ names = yes 27 log_ auth = yes 28 log_ auth_ badpass = yes 29 log_ auth_ goodpass = yes 30 usercollide = no 31 lower_ user = no 32 lower_ pass = no 33 nospace_ user = no 34 nospace_ pass = no 35 checkrad = ${ sbindir }/ checkrad 36 security { 37 max_ attributes = reject_ delay = 1 39 status_ server = no 40 } 41 proxy_ requests = yes 42 $INCLUDE ${ confdir }/ proxy. conf 43 $INCLUDE ${ confdir }/ clients. conf 44 snmp = no 45 $INCLUDE ${ confdir }/ snmp. conf 46 thread pool { 47 start_ servers = 5 48 max_ servers = min_ spare_ servers = 3 50 max_ spare_ servers = max_requests_per_server = 0 52 } 53 modules { 54 pap { 55 encryption_ scheme = crypt 56 } 57 chap {

85 A. Konfigurationen authtype = CHAP 59 } 60 pam { 61 pam_ auth = radiusd 62 } 63 unix { 64 cache = yes 65 cache_ reload = passwd = / etc / passwd 67 shadow = / etc / shadow 68 group = / etc / group 69 radwtmp = ${ logdir }/ radwtmp 70 } 71 $INCLUDE ${ confdir }/ eap. conf 72 mschap { 73 require_ encryption = yes 74 require_ strong = yes 75 } 76 ldap { 77 server = " ldap. your. domain " 78 basedn = "o=my Org,c=UA" 79 filter = "( uid =%{ Stripped -User - Name : -%{ User - Name }}) " 80 start_ tls = no 81 access_ attr = " dialupaccess " 82 dictionary_ mapping = ${ raddbdir }/ ldap. attrmap 83 ldap_connections_number = 5 84 timeout = 4 85 timelimit = 3 86 net_ timeout = 1 87 } 88 realm IPASS { 89 format = prefix 90 delimiter = "/" 91 ignore_ default = no 92 ignore_ null = no 93 } 94 realm suffix { 95 format = suffix

86 A. Konfigurationen delimiter = "@" 97 ignore_ default = no 98 ignore_ null = no 99 } 100 realm realmpercent { 101 format = suffix 102 delimiter = "%" 103 ignore_ default = no 104 ignore_ null = no 105 } 106 realm ntdomain { 107 format = prefix 108 delimiter = "\\" 109 ignore_ default = no 110 ignore_ null = no 111 } 112 checkval { 113 item - name = Calling - Station - Id 114 check - name = Calling - Station - Id 115 data - type = string 116 } preprocess { 119 huntgroups = ${ confdir }/ huntgroups 120 hints = ${ confdir }/ hints 121 with_ ascend_ hack = no 122 ascend_channels_per_line = with_ ntdomain_ hack = no 124 with_specialix_jetstream_hack = no 125 with_ cisco_ vsa_ hack = no 126 } 127 files { 128 usersfile = ${ confdir }/ users 129 acctusersfile = ${ confdir }/ acct_ users 130 preproxy_ usersfile = ${ confdir }/ preproxy_ users 131 compat = no 132 } 133 detail {

87 A. Konfigurationen detailfile = ${ radacctdir }/%{ Client -IP - Address }/ det \\ 135 ail -%Y%m%d 136 detailperm = } 138 detail auth_ log { 139 detailfile = ${ radacctdir }/%{ Client -IP - Address }/ auth \\ 140 -detail -%Y%m%d 141 detailperm = } 143 detail reply_ log { 144 detailfile = ${ radacctdir }/%{ Client -IP - Address }/ reply \\ 145 -detail -%Y%m%d 146 detailperm = } 148 detail pre_ proxy_ log { 149 detailfile = ${ radacctdir }/%{ Client -IP - Address }/ pre -\\ 150 proxy - detail -%Y%m%d 151 detailperm = } 153 detail post_ proxy_ log { 154 detailfile = ${ radacctdir }/%{ Client -IP - Address }/ post -\\ 155 proxy - detail -%Y%m%d 156 detailperm = } 158 acct_ unique { 159 key = "User -Name, Acct - Session -Id, NAS -IP - Address, \\ 160 Client -IP - Address, NAS - Port " 161 } 162 $INCLUDE ${ confdir }/ sql. conf radutmp { 165 filename = ${ logdir }/ radutmp 166 username = %{ Stripped -User - Name : -%{ User - Name }} 167 case_ sensitive = yes 168 check_ with_ nas = yes 169 perm = callerid = " yes " 171 }

88 A. Konfigurationen radutmp sradutmp { 173 filename = ${ logdir }/ sradutmp 174 perm = callerid = " no" 176 } 177 attr_ filter { 178 attrsfile = ${ confdir }/ attrs 179 } 180 counter daily { 181 filename = ${ raddbdir }/ db. daily 182 key = User - Name 183 count - attribute = Acct - Session - Time 184 reset = daily 185 counter - name = Daily - Session - Time 186 check - name = Max - Daily - Session 187 allowed - servicetype = Framed - User 188 cache - size = } 190 sqlcounter dailycounter { 191 counter - name = Daily - Session - Time 192 check - name = Max - Daily - Session 193 sqlmod - inst = sql 194 key = User - Name 195 reset = daily 196 query = " SELECT SUM ( AcctSessionTime - \ 197 GREATEST ((% b - UNIX_ TIMESTAMP ( AcctStartTime )), 0)) \ 198 FROM radacct WHERE UserName = %{% k} AND \ 199 UNIX_ TIMESTAMP ( AcctStartTime ) + AcctSessionTime >\\ 200 %b " 201 } 202 sqlcounter monthlycounter { 203 counter - name = Monthly - Session - Time 204 check - name = Max - Monthly - Session 205 sqlmod - inst = sql 206 key = User - Name 207 reset = monthly 208 query = " SELECT SUM ( AcctSessionTime - \ 209 GREATEST ((% b - UNIX_ TIMESTAMP ( AcctStartTime )), 0)) \

89 A. Konfigurationen FROM radacct WHERE UserName = %{% k} AND \ 211 UNIX_ TIMESTAMP ( AcctStartTime ) + AcctSessionTime >\\ 212 %b " 213 } 214 always fail { 215 rcode = fail 216 } 217 always reject { 218 rcode = reject 219 } 220 always ok { 221 rcode = ok 222 simulcount = mpp = no 224 } 225 expr { 226 } 227 digest { 228 } 229 exec { 230 wait = yes 231 input_ pairs = request 232 } 233 exec echo { 234 wait = yes 235 program = "/ bin / echo %{ User - Name }" 236 input_ pairs = request 237 output_ pairs = reply 238 } 239 ippool main_ pool { 240 range - start = range - stop = netmask = cache - size = session -db = ${ raddbdir }/ db. ippool 245 ip - index = ${ raddbdir }/ db. ipindex 246 override = no 247 maximum - timeout = 0

90 A. Konfigurationen } 249 } 250 instantiate { 251 exec 252 expr 253 } 254 authorize { 255 preprocess 256 auth_ log chap 259 mschap 260 suffix 261 eap 262 files 263 } 264 authenticate { 265 Auth - Type PAP { 266 pap 267 } 268 Auth - Type CHAP { 269 chap 270 } 271 Auth - Type MS - CHAP { 272 mschap 273 } 274 pam 275 unix 276 eap 277 } 278 preacct { 279 preprocess 280 acct_ unique 281 suffix 282 files 283 } 284 accounting { 285 detail

91 A. Konfigurationen unix 287 radutmp 288 } 289 session { 290 radutmp 291 } 292 post - auth { 293 reply_ log 294 } 295 pre - proxy { 296 } 297 post - proxy { 298 eap 299 } A.1.2 eap.conf Listing A.2: /etc/freeradius/eap.conf 1 eap { 2 default_ eap_ type = peap 3 timer_ expire = 60 4 ignore_unknown_eap_types = no 5 cisco_accounting_username_bug = no 6 md5 { 7 } 8 leap { 9 } 10 gtc { 11 auth_ type = PAP 12 } 13 tls { 14 private_ key_ password = whatever 15 private_key_file = ${ raddbdir }/ certs /cert -\\ 16 srv. pem 17 certificate_ file = ${ raddbdir }/ certs / cert -\\ 18 srv. pem 19 CA_file = ${ raddbdir }/ certs / democa / cacert. pem 20 dh_file = ${ raddbdir }/ certs /dh

92 A. Konfigurationen random_ file = / dev / urandom 22 } 23 peap { 24 default_ eap_ type = mschapv2 25 copy_request_to_tunnel = no 26 use_ tunneled_ reply = no 27 proxy_tunneled_request_as_eap = no 28 } 29 mschapv2 { 30 } 31 } A.1.3 clients.conf Listing A.3: /etc/freeradius/clients.conf 1 client { 2 secret = % m1k3_ s3cr3t % 3 shortname = localhost 4 } 5 client { 6 secret = % m1k3_ s3cr3t % 7 shortname = m1k3_ nagios 8 nastype = other 9 } 10 client { 11 secret = % m1k3_ s3cr3t % 12 shortname = m1k3_ VPN 13 nastype = other 14 } 15 client { 16 secret = % m1k3_ s3cr3t % 17 shortname = m1k3_ wlan 18 nastype = other 19 } 20 client { 21 secret = % m1k3_ s3cr3t % 22 shortname = m1k3_ enterasys 23 }

93 A. Konfigurationen client / 24 { 25 secret = % m1k3_ s3cr3t % 26 shortname = m1k3_ clients 27 nastype = other 28 } A.1.4 huntgroups Listing A.4: /etc/freeradius/huntgroups 1 local NAS -IP - Address == local NAS -IP - Address == linksys NAS -IP - Address == enterasys NAS - IP - Address == m0n0wall NAS - IP - Address == A.1.5 users Listing A.5: /etc/freeradius/users 1 nagiosadmin User - Password == " nagiosadmin " 2 Reply - Message = " Hello, %u", 3 Fall - Through = No 4 widhalmt User - Password == " geheim ", Huntgroup - Name == " enterasys " 5 Filter -ID == " Enterasys : version =1: mgmt =su: policy = Admin - Pol \\ 6 icy ", 7 Reply - Message = " Hello, %u", 8 Fall - Through = No 9 widhalmt User - Password == " geheim ", Huntgroup - Name!= " enterasys " 10 Reply - Message = " Hello, %u", 11 Fall - Through = No 12 widhalmt User - Password == " geheim " 13 Reply - Message = " Hello, %u", 14 Fall - Through = No 15 micmes User - Password == " geheim ", Huntgroup - Name == " enterasys " 16 Filter -ID == " Enterasys : version =1: mgmt =su: policy = Admin - Policy ", 17 Reply - Message = " Hello, %u", 18 Fall - Through = No 19 micmes User - Password == " geheim ", Huntgroup - Name!= " enterasys "

94 A. Konfigurationen Reply - Message = " Hello, %u", 21 Fall - Through = No 22 micmes User - Password == " geheim " 23 Reply - Message = " Hello, %u", 24 Fall - Through = No B-E User - Password == " m1k3s3cr3t ", Huntgroup - Name ==\\ 26 " enterasys " 27 Filter -ID == " Enterasys : version =1: policy =MAC -Auth - Policy ",\\ Reply - Message = " Hello, %u", 30 Fall - Through = No A8 User - Password == " m1k3s3cr3t ", Huntgroup - Name ==\\ 32 " enterasys " 33 Filter -ID == " Enterasys : version =1: policy =MAC -Auth - Policy ",\\ Reply - Message = " Hello, %u", 36 Fall - Through = No BA -E5 -F5-67 User - Password == " m1k3s3cr3t ", Huntgroup - Name ==\\ 38 " enterasys " 39 Filter -ID == " Enterasys : version =1: policy =MAC -Auth - Policy ",\\ Reply - Message = " Hello, %u", 42 Fall - Through = No 43 DEFAULT Auth - Type = System 44 Fall - Through = No A.1.6 Daemontools run-datei Listing A.6: /etc/radiusd/run 1 #!/bin/sh 2 # 3 # radiusd Start the radius daemon. 4 # /etc/radiusd/run 5 6 prefix =/ usr / 7 exec_prefix =${ prefix } 8 sbindir =${ exec_prefix }/ sbin 9 localstatedir =/ var

95 A. Konfigurationen logdir =${ localstatedir }/ log / freeradius 11 rundir =${ localstatedir }/ run / freeradius 12 sysconfdir =/ etc 13 loggeropt =" logger -p local6. info -t radiusd -s" 14 export LD_ LIBRARY_ PATH LD_ RUN_ PATH LD_ PRELOAD RADIUSD = $sbindir / freeradius 17 RADDBDIR = ${ sysconfdir }/ freeradius 18 NICELEVEL =" -10" 19 DESC =" FreeRADIUS " ARGS ="-X" test - f $RADIUSD exit 0 24 test - f $RADDBDIR / radiusd. conf exit $loggeropt " ============ date +% F -% T ============ " 27 $loggeropt " Starting $DESC... " 28 exec nice - n $NICELEVEL $RADIUSD $ARGS \\ 29 tee $logdir / radius - complete. log 30 $loggeropt "... Finished $DESC " 31 $loggeropt " ============ date +% F -% T ============ " exit 0 A.1.7 chkrootkit Cronjob 1 #!/bin/bash Listing A.7: /etc/cron.daily/chkrootkit 2 3 loggeropt =" logger - t chkrootkit - s" 4 domainname =" m1k3. local " 5 MAILTO = root 6 7 $loggeropt " =========== date +% F -% T =========== " 8 $loggeropt " chkrootkit fuer hostname. $domainname wird gestartet " 9 10 CHKPATH =/ usr / share / chkrootkit

96 A. Konfigurationen if [! - x $CHKPATH / chkrootkit ]; then 13 $loggeropt " WARNING : chkrootkit befindet sich nicht unter \\ 14 dem angegebenen Pfad " mail $MAILTO echo - s WARNING : \\ 15 chkrootkit wurde nicht gefunden _ hostname 16 $loggeropt " chkrootkit fuer hostname. $domainname wurde \\ 17 NICHT erfolgreich durchgefuehrt " 18 $loggeropt " =========== date +% F -% T =========== " 19 exit 1 20 fi 21 if [ -f / tmp / chkrootkit ]; then 22 $loggeropt " removing old tmp file " 23 rm - rf / tmp / chkrootkit 24 fi $loggeropt " starting chkrootkit " 27 cd $CHKPATH 28./ chkrootkit > / tmp / chkrootkit message = grep INFECTED "/ tmp / chkrootkit " 31 if [ $? -eq 0 ]; then 32 $loggeropt " WARNING : INFEKTION wurde festgestellt!!" 33 $loggeropt $message 34 cat / tmp / chkrootkit mail $MAILTO echo - s WARNING : \\ 35 chkrootkit INFECTED auf _ hostname 36 else 37 $loggeropt " keine Infektion wurde festgestellt!!" 38 cat / tmp / chkrootkit mail $MAILTO echo - s chkrootkit - \\ 39 output von _ hostname 40 fi $loggeropt " chkrootkit fuer hostname. $domainname wurde durchgefuehrt " 43 $loggeropt " =========== date +% F -% T =========== " exit 0

97 A. Konfigurationen 88 A.2 Policy-Manager Konfiguration Abbildung A.1: Portübersicht im Policy-Manager Abbildung A.2: Einrichten einer Defaultpolicy

98 A. Konfigurationen 89 Abbildung A.3: Aktivieren einer Defaultpolicy Abbildung A.4: WLAN-Policy

99 A. Konfigurationen 90 Abbildung A.5: WLAN-Policy A.3 Enterasys Matrix-Switch Konfiguration Listing A.8: Konfiguration - Enterasys Switch 1! Enterasys Networks, Inc. 1H Rev /30/ :\\ 2 24 ofc 3! 4! cdp 5! 6! community 7 set community F2DA92CE94CCA08CCC9C8DCC8BDA FD8D88 8! 9! dns 10! 11! garp 12! 13! gvrp 14! 15! history 16! 17! host vlan 18! 19! igmp 20! 21! ip 22 set ip address mask gateway \\ !

100 A. Konfigurationen 91 25! filter database 26! 27! priority queue 28! 29! banner 30! 31! prompt 32! 33! rad 34! 35! system 36! 37! telnet 38 set telnet disable inbound 39 set telnet disable outbound 40! 41! terminal 42! 43! trap 44! 45! vlan 46 set vlan 2 create 47 set vlan name 2 " deny " 48 set vlan dynamicegress 1 enable 49! 50! webview 51 set webview disable 52! 53! sntp 54! 55! rmon 56! 57! summertime 58! 59! dot1x 60 set dot1x auth - config authcontrolled - portcontrol forced - auth fe. 0\\ set dot1x enable

101 A. Konfigurationen 92 63! 64! port commands 65! 66! priority classification 67 set priority classification enable 68! 69! vlan classification 70 set vlan classification enable 71! 72! syslog 73! 74! mac - lock 75! 76! mac authentication 77 set macauthentication enable 78 set macauthentication password m1k3s3cr3t 79 set macauthentication port enable fe ! 81! snmp 82 set snmp community m1k3_ s3cr3t0ser initial nonvolatile 83 84! 85! buffer thresholds 86! 87! pwa 88! 89! ssh 90! 91! Multi - User support 92 set passwordrw 020 E8000F87731AD7EDC24F2CA6529EE4CCC8930D45AE54D3DC \\ D05CF F96D9D 95! 96! spanning tree 97 set spantree spanguardtrapenable enable 98! 99! radius 100 set radius server D800014B5B6927EDC24F2CA65 \\

102 A. Konfigurationen EE4CCC8930B 102 C663B2A32CD488612E66953F881100E 103 set radius enable 104! 105! radius accounting 106! 107! ciscodp 108! 109! trunk 110! 111! policy profile 112 set policy profile 1 " admins " disable 1 disable set policy profile 1 enable 114 set policy profile 2 " wlan " disable 1 disable set policy profile 2 enable 116 set policy profile 3 " users " disable 1 disable set policy profile 3 enable 118 set policy profile 4 " rserver " disable 1 disable set policy profile 4 enable 120 set policy profile 5 " default " enable 0 disable set policy profile 5 enable 122 set policy classify 2 1 vlan 0 tcpbilrange set policy classify 2 2 vlan 0 tcpportbil set policy classify 2 3 vlan 0 tcpportbil set policy classify 2 5 vlan 0 tcpportbil set policy classify 2 6 vlan 0 tcpportbil set policy classify 2 7 vlan 0 tcpportbil set policy classify 2 8 vlan 0 tcpportbil set policy classify 2 9 vlan 0 tcpportbil set policy classify 2 10 vlan 0 tcpportbil set policy classify 2 11 vlan 0 tcpportbil set policy classify 2 12 vlan 0 tcpbilrange set policy classify 3 4 vlan 0 tcpbilrange set policy classify 3 13 vlan 0 tcpportbil set policy classify 3 14 vlan 0 tcpportbil set policy classify 3 15 vlan 0 tcpportbil set policy classify 3 16 vlan 0 tcpportbil set policy classify 3 17 vlan 0 tcpportbil 971

103 A. Konfigurationen set policy classify 3 18 vlan 0 tcpportbil set policy classify 3 19 vlan 0 tcpportbil set policy classify 3 20 vlan 0 tcpportbil set policy classify 3 21 vlan 0 tcpbilrange set policy classify 3 22 vlan 0 tcpportbil set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe set policy port fe ! 169! cep 170! 171! nodealias 172! 173! flow limiting 174! 175! newaddrtrap 176!

104 A. Konfigurationen ! vlanauthorization 178! 179! begin router 180 router 181 router enable 184 config t ! 187 write file 188 exit 189!

105 A. Konfigurationen 96 A.4 VPN-Gateway Abbildung A.6: Radiusanbindung einer m0n0wall Listing A.9: PPTP Authentifizierung über m0n0wall 1 rad_ recv : Access - Request packet from host : 3277, id =66,\\ 2 length =171 3 NAS - Identifier = " m0n0wall. m1k3. local " 4 NAS - Port = 0 5 NAS - Port - Type = Virtual 6 Service - Type = Framed - User 7 Framed - Protocol = PPP

106 A. Konfigurationen 97 8 Calling - Station -Id = " " 9 User - Name = " widhalmt " 10 MS -CHAP - Challenge = 0 xbb1e681d04af5aa5eece8e5ebc190c16 11 MS - CHAP2 - Response = 0 x bd52dc7f3c0acb754a23a418dd146 \\ e0ab9dffd49a90102ea1a18882c04fd189ba00f Processing the authorize section of radiusd. conf 14 modcall : entering group authorize for request 1 15 modcall [ authorize ]: module " preprocess " returns ok for request 1\\ radius_xlat : / var / log / freeradius / radacct / / auth - detail \\ rlm_detail : / var / log / freeradius / radacct /%{ Client -IP - Address }/ auth -\\ 20 detail -%Y%m%d expands to / var / log / freeradius / radacct / / a\\ 21 uth - detail modcall [ authorize ]: module " auth_ log " returns ok for request 1 23 modcall [ authorize ]: module " chap " returns noop for request 1 24 rlm_ mschap : Found MS - CHAP attributes. Setting Auth - Type = msc \\ 25 hap 26 modcall [ authorize ]: module " mschap " returns ok for request 1 27 rlm_ realm : in User - Name = " widhalmt ", looking up realm \\ 28 NULL 29 rlm_ realm : No such realm " NULL " 30 modcall [ authorize ]: module " suffix " returns noop for request 1 31 rlm_ eap : No EAP - Message, not doing EAP 32 modcall [ authorize ]: module " eap " returns noop for request 1 33 users : Matched entry widhalmt at line modcall [ authorize ]: module " files " returns ok for request 1 35 modcall : leaving group authorize ( returns ok) for request 1 36 rad_ check_ password : Found Auth - Type MS - CHAP 37 auth : type "MS - CHAP " 38 Processing the authenticate section of radiusd. conf 39 modcall : entering group MS - CHAP for request 1 40 rlm_ mschap : Told to do MS - CHAPv2 for widhalmt with NT - Password 41 rlm_ mschap : adding MS - CHAPv2 MPPE keys 42 modcall [ authenticate ]: module " mschap " returns ok for request 1 43 modcall : leaving group MS - CHAP ( returns ok) for request 1 44 radius_ xlat : Hello, widhalmt 45 Login OK: [ widhalmt / < no User - Password attribute >] ( from client m1k \\

107 A. Konfigurationen _ VPN port 0 cli ) 47 Processing the post - auth section of radiusd. conf 48 modcall : entering group post - auth for request 1 49 radius_xlat : / var / log / freeradius / radacct / / reply - detai \\ 50 l rlm_detail : / var / log / freeradius / radacct /%{ Client -IP - Address }/ reply \\ 52 -detail -%Y%m%d expands to / var / log / freeradius / radacct / /\\ 53 reply - detail modcall [ post - auth ]: module " reply_ log " returns ok for request 1 55 modcall : leaving group post - auth ( returns ok) for request 1 56 Sending Access - Accept of id 66 to port Reply - Message = " Hello, widhalmt " 58 MS - CHAP2 - Success = 0 x01533d \\ MS -MPPE -Recv - Key = 0 xb50673c598d e9f MS -MPPE -Send - Key = 0 xaf0c813d4836b218a8bc24df5a4ac MS - MPPE - Encryption - Policy = 0 x MS - MPPE - Encryption - Types = 0 x Finished request 1 A.5 WLAN-Router Abbildung A.7: Radiusanbindung des Linksys WLAN Routers