Hochschule Bremen Fachbereich Elektrotechnik und Informatik

Transkript

1 Hochschule Bremen Fachbereich Elektrotechnik und Informatik Hochmobiler Mitarbeiter Entwicklung einer dedizierten Infrastruktur für die mobile Kommunikation Diplomarbeit eingereicht durch: Axel Schmidt Matrikelnr.: und Andreas Haase Matrikelnr.: Prüfer: Prof. Dr. Richard Sethmann Zweitprüfer: Prof. Dr. Axel Viereck Abgabetermin: 16. April 2007

2 Eidesstattliche Erklärung Ich, Axel Schmidt, erkläre an Eides statt, dass ich die vorliegende Diplomarbeit selbstständig und ohne unzulässige fremde Hilfe verfasst, andere als die angegebenen Quellen nicht benutzt und die aus den benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe. Datum / Unterschrift Seite I

3 Eidesstattliche Erklärung Ich, Andreas Haase, erkläre an Eides statt, dass ich die vorliegende Diplomarbeit selbstständig und ohne unzulässige fremde Hilfe verfasst, andere als die angegebenen Quellen nicht benutzt und die aus den benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe. Datum / Unterschrift Seite II

4 Danksagung An dieser Stelle danken wir all jenen für ihre persönliche und fachliche Unterstützung, welche zum Gelingen dieser Diplomarbeit beigetragen haben. Besonderer Dank gilt unseren Familien und Freunden, die uns nicht nur während der Diplomarbeit, sondern während des gesamten Studiums unterstützt haben. Weiterhin bedanken wir uns bei Herrn Prof. Dr. Richard Sethmann für die Betreuung unserer Diplomarbeit, für die Ratschläge bei der Ausarbeitung und die Bereitstellung eines Diplomandenraumes mit entsprechendem Testequipment. Zu guter Letzt bedanken wir uns bei Herrn Prof. Dr. Axel Viereck, der sich bereit erklärt hat, die Rolle des Zweitprüfers zu übernehmen. Seite III

5 Abstract Mobile Mitarbeiter eines Unternehmens müssen die Möglichkeit erhalten auf Daten eines Unternehmens remote zugreifen zu können. Um den Zugriff abzusichern, existieren teure Lösungen, die sich ein kleines oder mittelständisches Unternehmen nicht leisten können. Ziel dieser Diplomarbeit ist die Entwicklung einer auf Standards basierten Sicherheitsplattform für kleine und mittelständische Unternehmen. Die Anforderungen an die Sicherheitsplattform eines Unternehmens werden in dieser Diplomarbeit untersucht und in einzelne Module unterteilt. Diese Module werden unter Verwendung von Open Source Software -herstellerunabhängig- zu einem Systemkonzept entwickelt. Bei der Entwicklung des Systemkonzeptes wurde auf eine einfache Integration in eine bestehende Infrastruktur eines Unternehmens Wert gelegt. Die prototypische Realisierung zeigt, dass sich eine Umsetzung des Konzeptes mit Open Source Software realisieren lässt, jedoch besteht in manchen Bereichen noch Bedarf zur weiteren Entwicklung, bevor diese Lösung ein kommerzielles Produkt komplett ersetzen oder ablösen kann. Seite IV

6 Inhaltsverzeichnis 1 Einleitung Problemfeld Aufgabenbeschreibung Übersicht Einführung Grundlagen VPN Allgemein Typische VPN-Realisierung für mobile Mitarbeiter Authentisierung Internet Protocol Security (IPSec) Layer 2 Tunneling Protocol (L2TP) over IPSec Firewall Authentisierung, Autorisierung und Accounting (AAA) Authentisierung Autorsisierung Accounting AAA-Server RADIUS Trusted Network Connect Architektur Einheiten Komponenten Layers Interfaces Workflow TNC Cisco Network Admission Control Verschlüsselung von Daten Verschlüsselung einzelner Dateien Verschlüsselung mit virtuellen Laufwerken (Containern) Verschlüsselung des gesamten Mediums Fernadministrierung Seite V

7 2.7 Distributionssoftwareverteilung Client Referenzsystem Unattended / Silent Setup Administrative Installation Interaktives Setup mit automatischen Antworten Neu-Paketierung Entwicklung des Systemkonzeptes Systemübersicht Mobile Endgeräte (Clients) PDA/MDA/iPAQ Remote Notebooks Mobile Security Gateway VPN-Server Firewall Authentisierung, Autorisierung und Accounting (AAA) Trusted Network Connect (TNC) Distributionssoftwareverteilung Prototypische Realisierung Voraussetzungen im Unternehmensnetz Systemarchitektur des Prototypen Hardware Umgebung Software Umgebung Implementierung VPN-Server openswan l2tpd ppp und radiusclient Implementierung Firewall Einleitung Quarantänezone Statische Filterregeln Dynamische Filterregeln Implementierung AAA Authentisierung Autorisierung Accounting Implementierung Distributionssoftwareverteilung Seite VI

8 4.6.1 Server Client Erweiterung für den TNC Erstellen von Paketen Implementierung Trusted Network Connect (TNC) TNC-Komponenten Workflow prototypische TNC-Realisierung Prototyp TNC Client Implementierung Clients Notebooks PDA/MDA/iPAQ Diskussion VPN-Server OpenVPN IPSec IPSec und NAT-T Problembehandlung Firewall und AAA Distributionssoftwareverteilung Trusted Network Connect Verschlüsselung und Zerstörung von Daten Fazit / Ausblick 92 Literaturverzeichnis 94 Glossar 100 A Anhang 104 Seite VII

9 Abbildungsverzeichnis 2.1 Sicherung eines IP-Paketes mit ESP im Tunnel Mode Sicherung eines IP-Paketes mit ESP im Transport Mode IPSec/L2TP/PPP im ISO/OSI-Schichtenmodell Stateful Packet Inspection (SPI) Authentisierung mit Kerberos AAA-Server Ablauf einer RADIUS-Sitzung TNC-Übersicht (Trusted Computing Group) Workflow der TNC-Architektur Workflow Cisco NAC Einfache Dateiverschlüsselung Virtuelle Dateiverschlüsselung (Container) Vollstaendige Laufwerksverschlüsselung Konzeptionelle Gesamtansicht Übersicht Remote-Zugriff Modul Trusted Network Connect Client-Softwareverteilung Client-Betriebssysteminstallation über PXE-Boot Client-Betriebssysteminstallation über Boot-CD Übersicht Systemarchitektur Realisierung des IPSec-L2TP-PPP Protokollstacks unter Linux Scriptablauf dynamische Filterregeln Beispiel einer Access-Request-Nachricht Beispiel einer Access-Accept-Nachricht Beispiel einer Accounting-Start-Nachricht Beispiel einer Accounting-Stop-Nachricht Beispiel Referenzliste für den TNC TNC-Architektur des Prototyps Workflow prototypische TNC-Realisierung Seite VIII

10 4.11 Ablauf Trusted Network Connect Beispiel Log-Datei (Integritätstest bestanden) Beispiel Log-Datei (Integritätstest nicht bestanden) Übersicht VNC Versionen Seite IX

11 Tabellenverzeichnis 2.1 IPSec ohne NAT-T IPSec mit Berücksichtigung von NAT-T Fehler-Codes TNC Client Seite X

12 Kapitel 1 - Einleitung 1 Einleitung 1.1 Problemfeld Mitarbeiter mit Tätigkeitsbereich im Außendienst sind heutzutage auf mobile Kommunikation angewiesen. Eine häufige Anforderung ist zum Beispiel der Zugriff auf einen zentralen Datenbestand im Unternehmen, den der Mitarbeiter im Rahmen seiner Tätigkeit benötigt. Aus Sicht des Mitarbeiters ist ein möglichst transparenter Datenzugriff wünschenswert. Es müssen auf Seiten des Unternehmens und des Außendienstmitarbeiters technische Voraussetzungen geschaffen werden, die dem Außendienstmitarbeiter den Zugriff auf Ressourcen innerhalb des Firmennetzwerkes ermöglichen. Das Unternehmen hat jedoch ein berechtigtes Interesse daran, den Zugriff auf Ressourcen vor unbefugtem Zugang und deren Nutzung durch Dritte zu schützen. Dies betrifft sowohl lokale als auch nicht lokale Ressourcen. Namhafte Hersteller bieten Lösungen an, womit der Mitarbeiter in der Lage ist, seine Innendiensttätigkeit auch im Außendienst zu leisten, indem er sich per VPN-Lösung in das Unternehmen einwählt und so auf das Unternehmensnetz zugreift. Diese Konzepte sind sehr teuer und ein kleines oder mittelständisches Unternehmen ist häufig nicht in der Lage, diese Lösungen zu finanzieren. Daher wird die oben genannte dedizierte Infrastruktur entweder gar nicht oder nur zum Teil, mit Einschränkungen bezüglich Funktionalität und Sicherheit, umgesetzt. Die zunehmende Verbreitung von frei erhältlicher Software könnte in Zukunft dazu beitragen, diese Bedarfslücke zu schließen. Diese Diplomarbeit untersucht die Möglichkeiten, inwiefern solche kommerziellen Lösungen mit herkömmlicher Open Source Software nachgebildet werden können und inwiefern eine Lösung überhaupt realisierbar ist. Seite 1

13 Kapitel 1 - Einleitung 1.2 Aufgabenbeschreibung Alle Aufgaben beziehen sich auf mobile Endgeräte wie zum Beispiel PDAs, Smart- Phones und Notebooks. Die Aufgaben wurden zu Beginn der Arbeit unter beiden Diplomanden aufgeteilt. Eine strikte Trennung der Aufgaben ist jedoch nicht möglich, da die Arbeiten stark miteinander verflochten sind. Aus diesem Grund kann die folgende Auflistung nur die Schwerpunkte des jeweiligen Bearbeiters wiedergeben. Die Schwerpunkte von Herrn Schmidt beziehen sich auf die folgenden Fragestellungen: Wie ist eine Realisierung von Trusted Network Connect möglich? Wie ist eine zentrale Fernadministrierung von Endgeräten möglich? Wie ist eine zentrale Distributionssoftwareverteilung möglich? Wie ist eine Verschlüsselung und Zerstörung der Daten oder ein Sperren des Zugriffs auf abhanden gekommene Endgeräte möglich? Die Schwerpunkte von Herrn Haase beziehen sich auf die folgenden Fragestellungen: Wie ist eine Firewall in ein bestehendes Unternehmensnetz zu integrieren? Wie ist eine Absicherung der Ende-zu-Ende-Kommunikation (VPN) zu realisieren? Welche Möglichkeiten der Realisierung von Sicherheitsrichtlinien für den Benutzer gibt es? Welche Möglichkeiten der Benutzerverwaltung (zum Beispiel über RADIUS und LDAP/ADS) gibt es? Alle vorherigen genannten Punkte sind theoretisch zu erarbeiten und prototypisch innerhalb einer Testumgebung mit Open Source Software umzusetzen. Seite 2

14 Kapitel 1 - Einleitung 1.3 Übersicht Die Diplomarbeit ist in sechs Hauptteile gegliedert: 1. Einführung Grundlagen: Hier werden die grundlegenden Inhalte in Bezug auf die Aufgabenbeschreibung detailliert dargestellt. 2. Entwicklung des Systemkonzepts: In diesem Abschnitt wird das Konzept der dedizierten Infrastruktur anhand der grundlegenden Inhalte entwickelt und in abstrakter Form dargestellt. 3. Prototypische Realisierung: In diesem Abschnitt wird die konkrete Ausprägung des Systemkonzeptes implementiert und erläutert. 4. Diskussion: In der Diskussion wird auf die aufgetauchten Probleme und auf die prototypische Realisierung eingegangen. Außerdem werden mögliche Lösungsansätze diskutiert. 5. Fazit/Ausblick: Hier wird der Stand der Realisierung zusammenfassend dargestellt. Außerdem erfolgt ansatzweise ein Ausblick auf noch ungelöste Probleme und unbehandelte Fragestellungen. 6. Anhang: Der Anhang enthält Installationsanleitungen, Konfigurationsdateien und Quelltexte auf die im Verlauf der Arbeit Bezug genommen werden. Seite 3

15 Kapitel 2 - Einführung Grundlagen 2 Einführung Grundlagen 2.1 VPN Allgemein Ein mobiler Mitarbeiter benötigt an seinem Standort zum Beispiel einen Fernzugriff auf Daten, welche sich nicht auf den mobilen Endgeräten, sondern auf einem Server innerhalb des Unternehmens befinden. Ein solcher Fernzugriff lässt sich grundsätzlich auf zwei Arten bewerkstelligen [URL:01]: Herstellen einer dedizierten Wählverbindung über das herkömmliche Telefonnetz, auch als direkte Einwahl bezeichnet. Abhängig von Standort und Telefonanbieter des mobilen Mitarbeiters fallen für die direkte Einwahl mehr oder weniger hohe Kosten an. Herstellen einer Verbindung über verfügbare IP-Netzwerke, wie dem Internet. Aus Kostengründen gewinnt diese Variante zunehmend an Bedeutung. Hier ist zu beachten, dass unter Umständen sensible Daten über ein unsicheres Netzwerk übertragen werden. Der Kommunikationskanal, über den die Daten transportiert werden sollen, ist deshalb mit geeigneten Methoden abzusichern. In dieser Diplomarbeit wird lediglich die zweite Variante berücksichtigt. Die Absicherung des Kommunikationskanals geschieht in der Praxis durch den Einsatz von Virtual Private Networks ( VPN s). [AHLE01] In Bezug auf die zu schützenden Daten sind drei grundsätzliche Anforderungen an ein VPN zu nennen: 1. Vertraulichkeit: Ein Abhören auf dem Kommunikationskanal ist nicht zu verhindern. Durch den Einsatz leistungsfähiger Verschlüsselung wird die Vertraulichkeit sicher gestellt, weil Unbefugte dann lediglich verschlüsselte Daten sehen. Der Sender verschlüsselt dabei die Daten. Der Empfänger entschlüsselt das Chiffrat und Seite 4

16 Kapitel 2 - Einführung Grundlagen stellt damit die ursprünglichen Daten wieder her. Die Chiffrierung der Daten erfolgt üblich mit symmetrischen Verschlüsselungsverfahren. Bekannte Verfahren sind beispielsweise Triple-DES ( 3DES), Advanced Encryption Standard ( AES) oder Blowfish. Die Schlüssellänge ist hinreichend zu wählen, um erfolgreiche Brute-Force-Attacken zu vermeiden. 2. Integrität: Die Verschlüsselung gewährt zwar die Vertraulichkeit der Daten, sie schützt jedoch nicht vor deren Manipulation. Der Empfänger muss in der Lage sein, zu erkennen, ob die chiffrierten Daten beim Transport verändert wurden. Die Integrität verschlüsselter Daten wird in der Praxis durch Prüfsummenverfahren (Message Digests) wie Hash Message based Authentication Code ( HMAC) realisiert. 3. Authentizität: Ohne die Authentisierung wäre es immer noch denkbar, das Chiffrat auf dem Transportweg zu manipulieren, mit gefälschter Absenderadresse zu versehen (Spoofing) und schließlich mit neu berechneten Prüfsummen an den Empfänger zu leiten. Dies bezeichnet man auch als Man-In-The-Middle Attack. Die Authentisierung garantiert dem Empfänger, dass die Daten tatsächlich von dem vorgegebenen Absender stammen Typische VPN-Realisierung für mobile Mitarbeiter Das mobile Endgerät greift auf unterschiedliche Anwendungen im LAN eines Unternehmens zu. Diese Anwendungen können auf unterschiedliche Systeme verteilt sein. Daher benötigt das mobile Endgerät Zugriff auf das gesamte LAN. Der Kommunikationskanal wird durch eine VPN-Software auf dem mobilen Endgerät und auf einem VPN-Gateway im LAN des Unternehmens gesichert. Die Studie [URL:01] empfiehlt, die Zugriffsmöglichkeiten des mobilen Endgerätes auf Systeme im LAN technisch zu reduzieren. Die verbleibenden Zugriffsmöglichkeiten sind nötig, damit der mobile Mitarbeiter seine Tätigkeit ausüben kann Authentisierung Die Authentisierung ist ein wichtiger Bestandteil, der in die Planung eines VPNs einzubeziehen ist [URL:01]. Die Nutzung im Sinne von Missbrauch durch unternehmensfremde Personen, zum Beispiel nach einem Diebstahl oder einem Verlust, kann bei einem mobilen Endgerät nie ausgeschlossen werden. Daher sollten Aufbau Seite 5

17 Kapitel 2 - Einführung Grundlagen und Nutzung des Kommunikationskanals erst nach einer starken Authentisierung des mobilen Mitarbeiters möglich sein. Die Authentisierung bei VPNs kann in zwei Klassen aufgeteilt werden [KONG04]: maschinenbezogene Authentisierung: Damit ist die Authentisierung von Netzwerkgeräten gemeint. Die Authentisierung kann in zwei Phasen erfolgen. In der ersten Phase identifizieren sich Sender und Empfänger gegenseitig, bevor die Aushandlung des sicheren Kommunikationskanals abgeschlossen wird. In der zweiten Phase, der Übertragungsphase, überprüft der Empfänger die Authentizität des Senders für jedes eingehende Datenpaket. Die Authentisierung kann unter Verwendung von Preshared Keys (geheime Schlüssel) oder durch ein Public-Key-Verfahren (Zertifikate) erfolgen (siehe auch [URL:01], Seite 15). Preshared Keys ( PSK): Bei diesem Verfahren muss der Preshared Key beiden Endpunkten vor der Authentisierung zur Verfügung stehen. Der PSK bildet gewissermaßen die Berechtigung zur Authentisierung. Die Schlüssel müssen vorher über ein sicheres Medium ausgetauscht werden. Die Authentisierung selbst geschieht häufig nach einer Art Challenge-Response-Verfahren mit Hash-Werten, die aus dem PSK abgeleitet werden. Nachteile bezüglich der Sicherheit sind eher praktischer Natur: ein einziger PSK wird für eine gesamte VPN- Infrastruktur verwendet oder es wurde ein trivialer PSK gewählt. Public-Key-Verfahren: Dieses Verfahren ermöglicht eine Authentisierung mit digitalen Signaturen und asymmetrischer Verschlüsselung. Dafür lassen sich Zertifikate nach Standard ITU-X.509 verwenden. Um die Gültigkeit von Zertifikaten zu verifizieren, ist das Einbetten einer VPN-Infrastruktur innerhalb einer Public-Key-Infrastruktur sinnvoll. Die Verwaltung einer Public-Key- Infrastruktur bedeutet einen zusätzlichen administrativen Aufwand, bietet jedoch ein höheres Maß an Sicherheit. Eine Public-Key-Infrastruktur unter Linux lässt sich mit dem Werkzeug OpenSSL [URL:16] realisieren. personenbezogene Authentisierung: Ein mobiler Mitarbeiter, der via VPN auf Netzwerkdienste im LAN des Unternehmens zugreift, muss sich im Vorfeld eindeutig gegenüber einem Zugangskontrollsystem identifizieren, z.b. durch eine Kombination aus Benutzername und Passwort. Als Beispiel für ein Zugangskontrollsystem sei Seite 6

18 Kapitel 2 - Einführung Grundlagen hier ein AAA-Server genannt. Personenbezogene Authentisierungen werden häufig über spezielle Authentisierungsprotokolle wie Password Authentication Protocol ( PAP), Challenge Handshake Authentication Protocol ( CHAP) und Microsoft Challenge Handshake Authentication Protocol ( MS-CHAP) abgewickelt. Maschinen- und personenbezogene Authentisierung sind kombinierbar: mit der maschinenbasierten Authentisierung handeln Sender und Empfänger zunächst einen sicheren Kommunikationskanal aus. Im Anschluss folgt die personenbezogene Authentisierung am Zugangskontrollsystem. Dieses Verfahren bietet zusätzliche Sicherheit, da die Daten des verwendeten Authentisierungsprotokolles ausschließlich durch den sicheren Kommunikationskanal transportiert werden. Außerdem bietet dieses Verfahren einen gewissen Schutz gegen unautorisierte Zugriffe auf das Zugangskontrollsystem, da dieses nur über den sicheren Kommunikationskanal erreichbar ist Internet Protocol Security (IPSec) IPSec (Internet Protocol Security) ist die derzeit am häufigsten verwendete VPN- Lösung (Quelle: [URL:01] und [AHLE02]). Es erweitert das IP-Protokoll um zwei Sicherungsarten: Authentication Header (AH) bietet Authentizität und Integrität. Encapsulated Security Payload ( ESP) bietet Vertraulichkeit, Authentizität und Integrität. Beide Sicherungsarten können in den Betriebsmodi Tunnel und Transport verwendet werden. Da der Authentification Header keine Vertraulichkeit bietet, wird diese Sicherungsart im Rahmen dieser Diplomarbeit nicht weiter ausgeführt. Die Abbildungen 2.1 und 2.2 Quelle [URL:01] zeigen die Sicherungsart Encapsulated Security Payload in beiden Betriebsmodi. Im Tunnel Mode wird das zu sichernde IP-Paket samt Header in ein ESP-Paket gekapselt. Der Tunnel Mode wird normalerweise für Remote-Access (RAS) und zur Kopplung entfernter Subnetze verwendet. Der Transport Mode sieht lediglich die Kapselung der Payload eines IP-Paketes vor. Der ursprüngliche IP-Header bleibt sichtbar. Soll eine direkte Kopplung zweier Rechner via IPSec erreicht werden, bietet sich der Transport Mode an. Seite 7

19 Kapitel 2 - Einführung Grundlagen Abbildung 2.1: Sicherung eines IP-Paketes mit ESP im Tunnel Mode Abbildung 2.2: Sicherung eines IP-Paketes mit ESP im Transport Mode ESP verwendet symmetrische Verschlüsselung mit dynamisch erzeugten Sitzungsschlüsseln. Die Aushandlung der Sitzungsschlüssel, der Verbindungskonfiguration und der Authentisierung geschieht über ein separates Protokoll, welches als Internet Key Exchange ( IKE) bezeichnet wird. Das Internet Key Exchange Protokoll kann in zwei Modi arbeiten: Aggressive: Dieser Modus ist aus Sicherheitsgründen nicht zu empfehlen: IKE im Aggressive Mode beschleunigt zwar die Aushandlung einer IPSec-Verbindung, überträgt jedoch Authentisierungsnachrichten im Klartext, was ein Angriffspunkt darstellt (besonders bei trivial gewählten PSKs) [THUM07]. Der Aggressive Mode wurde aus Kompatibilitätsgründen eingeführt, um IPSec-Verbindungen mit dynamischen IP-Adressen und Preshared Keys zu ermöglichen. Main Mode: Dieser Modus sollte immer verwendet werden. Der Main Mode unterstützt die Authentisierung basierend auf Zertifikaten und Preshared Keys. Die Verwendung von Preshared Keys funktioniert nur mit statischen IP-Adressen. Die ursprüngliche Spezifikation von IPSec wird kaum noch verwendet. Ein Grund dafür ist z.b. die weit verbreitete Anwendung der Network Address Translation ( NAT) in Netzwerken, da es den Header eines IP-Pakets verändert. Aus diesem Grund hat man die IPSec-Spezifikation um die Erweiterung NAT Traversal Seite 8

20 Kapitel 2 - Einführung Grundlagen ( NAT-T) ergänzt. Die Erweiterung NAT-T sieht eine NAT-Erkennung während der Aushandlung mit IKE vor. Falls NAT erkannt wird, werden alle ESP-Pakete in UDP-Pakete gekapselt. Tabelle 2.1 und 2.2 Quelle [URL:01] zeigen, welche Dienste am VPN-Gateway (bei Einsatz einer Firewall) frei zu schalten sind. Tabelle 2.1: IPSec ohne NAT-T Dienst Protokoll Quellport Zielport IKE UDP(IP 17) nicht definiert 500 ESP IP 50 entfällt entfällt Tabelle 2.2: IPSec mit Berücksichtigung von NAT-T Dienst Protokoll Quellport Zielport IKE UDP(IP 17) nicht definiert 500, 4500 ESP über UDP UDP (IP 17) nicht definiert 4500 ESP IP 50 entfällt entfällt Im Bereich der Open Source Software existieren diverse IPSec-Implementierungen. Eine bekannte Implementierung für Linux ist FreeS/WAN, dessen Entwicklung jedoch im Jahr 2004 eingestellt wurde. Als Nachfolger von FreeS/WAN [URL:07] gelten Openswan [URL:17] und Strongswan [URL:27] Layer 2 Tunneling Protocol (L2TP) over IPSec Das Layer 2 Tunneling Protocol ( L2TP) ist die von Microsoft favorisierte Lösung zum Aufbau von VPN-Verbindungen. Diese Lösung ist ein fester Bestandteil in allen neueren Microsoft Betriebssystemen, wie Windows XP und dem vor kurzem erschienenen Windows Vista ( [DELE07]). Handheld-Geräte mit Windows Mobile zählen ebenfalls dazu. Auf einem mobilen Endgerät mit Microsoft Betriebssystem ist daher keine zusätzliche Software nötig. L2TP bietet allerdings keine Sicherheitsfunktionen für übertragene Nutzdaten. Daher wird IPSec zur Realisierung der VPN- Anforderungen Vertraulichkeit, Integrität und Authentizität eingesetzt. Der Einsatz von IPSec als eigenständiges VPN-Protokoll ist zwar in den Microsoft Betriebssystemen nicht vorgesehen, lässt sich jedoch durch Software von Drittanbietern nachrüsten. Die Nutzung von L2TP in Kombination mit IPSec ist keine properitäre Lösung eines großen Herstellers, sondern ein durch die Internet Engineering Task Force Seite 9

21 Kapitel 2 - Einführung Grundlagen [URL:10] verabschiedeter Standard [URL:23]. L2TP wurde ursprünglich zur Kapselung des Point-to-Point-Protokolls entwickelt [URL:01]. Microsoft hat diesen Ansatz in die VPN-Implementierungen der eigenen Betriebssysteme übernommen. Abbildung 2.3 (Quelle [URL:01]) zeigt die Anordnung von IPSec, L2TP und Point-to-Point Protocol ( PPP) im OSI/ISO- Schichtenmodell. Abbildung 2.3: IPSec/L2TP/PPP im ISO/OSI-Schichtenmodell Mit dieser Anordnung kann eine Kombination von maschinenbezogener und personenbezogener Authentisierung erreicht werden. Die maschinenbezogene Authentisierung findet auf IPSec-Ebene statt (Zertifikate, Preshared Keys), während die personenbezogene Authentisierung über ein PPP-Authentisierungsprotokoll (PAP, CHAP oder MS-CHAP) abgewickelt wird. Vorteile von IPSec/L2TP: Der VPN-Client ist bereits in den aktuellen Microsoft-Betriebssystemen vorhanden. Geringer Konfigurationsaufwand des VPN-Clients. Durch die Verwendung des PPP-Protokolls kann dem Client eine virtuelle IP- Adresse zugewiesen werden. Nachteile von IPSec/L2TP: Geringerer Datendurchsatz im Gegensatz zu anderen IPSec- Implementierungen, da mehrere Protokolle geschachtelt werden (IPSEC- >L2TP->PPP) Der Konfigurationsaufwand auf dem Server ist höher, da neben IPSec noch L2TP und PPP zu implementieren sind. Seite 10

22 Kapitel 2 - Einführung Grundlagen 2.2 Firewall Die Firewall ist die wichtigste Sicherheitskomponente, um den Datenfluss zwischen zwei Netzwerken, basierend auf einer definierten Sicherheitsrichtlinie, zu kontrollieren [URL:02]. Die technische Umsetzung dieser Sicherheitsrichtlinie erfolgt mit Hilfe von Filterregeln, die letztendlich entscheiden, ob ein bestimmter Datenfluss zu erlauben oder zu verhindern ist. Auf den Datenfluss bezogen enthält eine Filterregel daher beispielsweise folgende Angaben: verwendete Netzwerkschnittstelle ein- oder ausgehend verwendetes Netzwerkprotokoll Quelle (einzelner Rechner oder Subnetz) Ziel (einzelner Rechner oder Subnetz) Die Aufgabe einer Firewall in der Praxis besteht meist darin, die Rechner in einem lokalen Netzwerk gegen unerwünschte Zugriffe aus einem nicht vertrauenswürdigen Netzwerk zu schützen. Die einfachste Ausprägung einer Firewall ist ein Paketfilter, welcher auf OSI-Schicht drei arbeitet. Der Paketfilter ist damit in der Lage, Pakete des IP-Protokolls anhand von Eigenschaften des IP-Headers zu behandeln. Somit lässt sich der Zugriff von Rechnern in Netzwerk A auf Dienste von Rechnern in Netzwerk B explizit einschränken. Dieser einfache Paketfilter kann jedoch nicht unterscheiden, ob der in Anspruch genommene Dienst regulär oder missbräuchlich verwendet wird, da er jedes Datenpaket einzeln, ohne Berücksichtigung vorangegangener Datenpakete, bewertet. Die Berücksichtigung vorangegangener Pakete ist jedoch gerade bei verbindungsorientierten Protokollen sinnvoll. Aus diesem Grund wurde der einfache Paketfilter um das Prinzip Stateful Packet Inspection ( SPI) erweitert. Der Paketfilter unterhält dazu eine Statustabelle, die den Zustand aktiver Verbindungen speichert. Dabei werden auch verbindungslose Protokolle berücksichtigt. Abbildung 2.4 Quelle [URL:32] zeigt das Prinzip von Stateful Packet Inspection: Der Client mit der IP-Adresse sendet ein erstes Paket an den Server mit der IP-Adresse Der Paketfilter mit SPI liest den Paket-Header und speichert Quelladresse, Quellport, Zieladresse und Zielport in der Statustabelle. Das Antwort-Paket des Servers wird ebenfalls durch den Paketfilter analysiert. Der Paketfilter lässt das Paket zu, da für die Daten im Paket-Header ein Eintrag in Seite 11

23 Kapitel 2 - Einführung Grundlagen der Statustabelle existiert. Der Server sendet wenig später erneut ein Paket an den Client. Der Paketfilter erkennt dieses Paket als unzulässig und verwirft es, da die Daten im Paket-Header mit keinem Eintrag in der Statustabelle übereinstimmen. Der Server kann also lediglich auf vorangegangene Pakete des Clients antworten jedoch keine neue Verbindung zum Client initiieren. Abbildung 2.4: Stateful Packet Inspection (SPI) Unter Linux ist der Einsatz eines Paketfilters kein Problem, wenn ein vorgefertigter Kernel aus der Paketverwaltung der Linux-Distribution installiert wird. In diesem ist die Paketfilter-Funktionalität mit Stateful Packet Inspection bereits integriert. Für die Konfiguration des Paketfilters steht das Kommandozeilen basierte Werkzeug IPTables [URL:12] zur Verfügung. Seite 12

24 Kapitel 2 - Einführung Grundlagen 2.3 Authentisierung, Autorisierung und Accounting (AAA) Mitarbeiter, die sich mit ihren mobilen Endgeräten per VPN in das Unternehmen einwählen möchten, benötigen im Allgemeinen transparenten Zugriff auf Dienste im lokalen Netzwerk. Ein Problem dabei ist, dass diese Dienste dafür außerhalb des Unternehmens (über einen exponierten Netzzugang) verfügbar sein müssen. Ohne eine Zugriffskontrolle kann prinzipiell jede Person mit Zugriff auf das mobile Endgerät eines Mitarbeiters eine anonyme VPN-Einwahl durchführen. Authentisierung, Autorisierung und Accounting ( AAA) steht für ein Modell, das eine Zugriffskontrolle für entfernte Benutzer vorsieht [URL:04] Authentisierung Nur wenn ein Benutzer sich eindeutig identifiziert hat, können die weiteren Maßnahmen Autorisierung (zulassen des Zugriffs auf bestimmte Dienste im Netzwerk) und Accounting (protokollieren des Zugriffs auf bestimmte Dienste im Netzwerk) wirkungsvoll sein. Aus technischer Sicht erfolgt die Authentisierung von Benutzern meistens über ein Netzwerkprotokoll, dass sowohl die Übertragung von Nutzdaten als auch Authentisierung unterstützt. Dabei wird die Authentisierung des Benutzers verlangt, sobald die Verbindung aufgebaut wurde. PPP-Protokoll Ein klassisches Beispiel ist das Verwenden der Authentisierung innerhalb der so genannten LCP-Erweiterungen des PPP-Protokolls, wie es bei den vielen Internetdienstanbietern der Fall ist. Das PPP-Protokoll definiert zwei Formen der Authentisierung: Kennwörter werden im Klartext von dem entfernten Endgerät zum Einwahlknoten übertragen. Dies ist als Password Authentication Protokoll (PAP) bekannt. Es werden keine Kennwörter im Klartext von dem entfernten Endgerät zum Einwahlknoten übertragen. Stattdessen sendet der Einwahlknoten zunächst ein zufällig generiertes Datagramm (Challenge) an das entfernte Endgerät. Das Endgerät leitet aus diesem Datagramm und dem Kennwort einen Hash-Wert (Response) ab, und sendet diesen an den Einwahlknoten zurück. Der Einwahlknoten hat unterdessen mit der gleichen Hash-Funktion einen Hash-Wert aus dem gesendeten Datagramm und dem hinterlegten Kennwort generiert. Stimmt Seite 13

25 Kapitel 2 - Einführung Grundlagen der empfangene Hash-Wert (Response) mit dem lokal erzeugten Hash-Wert überein, ist die Authentisierung erfolgreich. Dieses Verfahren ist als Challenge- Handshake Authentication Protocol (CHAP) bekannt. Kerberos 5 Kerberos ist ein am MIT entwickeltes Authentisierungsprotokoll, das eine gesicherte Authentisierung zwischen einem Client und einem Applikationsserver erlaubt, die über ein unsicheres TCP/IP-Netzwerk verbunden sind. Die Authentisierung erfolgt dabei über eine vertrauenswürdige dritte Instanz, den Kerberos-Server. Die Sicherung der Authentisierung basiert dabei auf der Verwendung kryptografischer Funktionen um ein Ausspähen geheimer Daten zu verhindern. Die Authentisierung mit Kerberos basiert auf so genannte Tickets, die zwischen den beteiligten Entitäten ausgetauscht werden. Die zentrale Instanz ist ein Kerberos- Server, der ein Kerberos Distribution Center ( KDC) enthält. Das KDC besteht wiederum aus den Entitäten Ticket Granting Server ( TGS) und Authentication Server ( AS). Die grundlegende Funktionsweise der Authentisierung (siehe Abbildung 2.5) ist wie folgt: 1. Ein Client, der auf einen Dienst des Applikationsservers zugreifen möchte, sendet zunächst eine Anfrage mit dem gewünschten Dienst zum AS. Dazu muss der Benutzer normalerweise sein geheimes Passwort eingeben. 2. Der AS verifiziert die Identität des Clients und stellt diesem ein Ticket Granting Ticket ( TGT) aus. 3. Der Client leitet das TGT an den TGS weiter. 4. Der TGS verifiziert das TGT und stellt dem Client ein Service Granting Ticket ( SGT) aus. Das SGT ist nur für den gewünschten Dienst auf dem Applikationsserver gültig. 5. Der Client sendet das SGT an den Applikationsserver. Dieser verifiziert das SGT und schaltet den Dienst für den Client frei. 6. Der Applikationsserver authentisiert sich gegenüber dem Client. Seite 14

26 Kapitel 2 - Einführung Grundlagen Abbildung 2.5: Authentisierung mit Kerberos Jeder Kerberos-Server hat seinen eigenen Verwaltungsbereich, den so genannten Realm. Bei einem Domänencontroller mit Active Directory ist es häufig anzutreffen, dass der DNS-Name des Domänencontrollers in Großbuchstaben für die Bezeichnung des Realms verwendet wird [BUDD05] Autorsisierung Die Autorisierung dient der Festlegung von Zugriffsrechten auf Netzwerkdienste in Abhängigkeit des jeweiligen Benutzers. Dies kann entweder über ein spezielles Benutzerprofil oder global über ein Gruppenprofil erfolgen, falls eine Anzahl von Benutzern mit identischen Zugriffsrechten auszustatten ist. Benutzer- und Gruppenprofile können über einen Verzeichnisdienst wie LDAP oder Active Directory realisiert werden Accounting Die Allgemeine Aufgabe des Accountings ist das Protokollieren von Benutzeraktivitäten. Die Auswertung dieser Benutzeraktivitäten ist für ein Unternehmen ein wichtiges Instrument, um z.b. die Auslastung des Netzzugangs zu analysieren oder Missbrauch (mehrfache Anmeldungen unter der selben Benutzeridentität, ungewöhnliche Anmeldezeiten) zu erkennen AAA-Server Authentisierung, Autorisierung und Accounting kann zentral über eine Software- Lösung erfolgen. Diese arbeitet nach dem Client-Server-Prinzip (Abbildung 2.6). Seite 15

27 Kapitel 2 - Einführung Grundlagen Abbildung 2.6: AAA-Server Der Network Access Server ( NAS) ist in diesem Fall Einwahlknoten für die entfernten Benutzer und gleichzeitig der AAA-Client. Der entfernte Benutzer stellt mit seinem mobilen Endgerät eine Verbindung zum NAS her und identifiziert sich gegenüber Selbigem. Der NAS reicht die Identität zur Authentisierung an den AAA-Server weiter. Nach erfolgter Authentisierung sendet der AAA-Server die Autorisierung und eventuelle Konfigurationsinformationen (z.b. eine dynamische IP-Adresse) für diesen Benutzer als Antwort an den NAS. Der NAS wiederum sendet nach erfolgter Autorisierung benutzerspezifische Daten zur Aufzeichnung an den AAA-Server RADIUS Die in diesem Abschnitt enthaltenen Information basieren im Wesentlichen auf Informationen der Quelle [BRIL01]. Eigenschaften Die Kommunikation zwischen AAA-Server und NAS findet über ein spezielles AAA-Protokoll statt. Eine weit verbreitete Variante des AAA-Protokolls ist unter der Bezeichnung RADIUS (Remote Authentication Dial-In User Service) implementiert. Das RADIUS-Protokoll hat folgende Eigenschaften: Client-Server-Modell: Der Network Access Server als RADIUS-Client übermittelt die Benutzeridentität an den RADIUS-Server. Der RADIUS-Server entscheidet, ob diese Benutzeridentität zugelassen wird. In jedem Fall sendet der RADIUS-Server eine Antwort an den RADIUS-Client. Seite 16

28 Kapitel 2 - Einführung Grundlagen Verschlüsselung des AAA-Protokolls: Die Kommunikation zwischen RADIUS-Client und RADIUS-Server ist symmetrisch chiffriert (Shared Secret auf Server und Client), um ein Ausspähen von Benutzeridentitäten zu vermeiden. multiple Authentisierungs-Mechanismen: Das RADIUS-Protokoll spezifiziert multiple Mechanismen für die personenbezogene Authentisierung, zum Beispiel PAP (über PPP), CHAP (ebenfalls über PPP) oder UNIX Login. Nachrichtenaustausch über Attribut-Werte-Paare: zum Beispiel: User-Name = Andreas Framed-Protocol = PPP Framed-IP-Address = Mit speziellen Wörterbuch-Listen lässt sich der Vorrat möglicher Attribute flexibel erweitern. Dadurch ist es z.b. möglich, herstellerspezifische Attribute zu verwenden, die in der ursprünglichen Definition des RADIUS-Protokolls nicht enthalten sind. Typischer Ablauf In diesem Szenario möchte der Benutzer einen bestimmten Dienst beanspruchen. Abbildung 2.7 zeigt den Ablauf einer RADIUS-Sitzung zwischen dem RADIUS- Client (NAS) und dem RADIUS-Server: 1. Der RADIUS-Client fordert den Benutzer auf, seinen Benutzernamen und Passwort für einen bestimmten Dienst einzugeben. Im Anschluss daran formt der RADIUS-Client einen verschlüsselten Access-Request mit Attribut-Werte- Paaren, die unter anderem den Benutzernamen und das Kennwort enthalten. 2. Der Access-Request wird an den RADIUS-Server geschickt. Sollte der Server innerhalb einer definierten Zeitspanne nicht antworten, wird der Access-Request wiederholt gesendet, bis der RADIUS-Client abbricht. 3. Der RADIUS-Server bearbeitet den Access-Request. Das heißt, er überprüft ob die im Access-Request gesendeten Attribute-Werte-Paare mit den für diesen Benutzer gültigen Attribute-Werte-Paaren übereinstimmen. Der RADIUS-Server fragt dazu seine interne Datenbank ab. Findet der RADIUS-Server keine Über- Seite 17

29 Kapitel 2 - Einführung Grundlagen einstimmung, sendet dieser ein Access-Reject an den RADIUS-Client. Dieser wird dann dem Benutzer mitteilen, dass der Zugriff verweigert wurde. Bei einer Überprüfung mit positivem Ergebnis schnürt der RADIUS-Server eine Access-Accept-Nachricht mit zusätzlichen Konfigurationsattributen. Diese enthalten zusätzliche Informationen wie Service-Typ (PPP,...), dynamisch zugewiesene IP-Adresse et cetera. 4. Der RADIUS-Client konfiguriert den angeforderten Dienst entsprechend der in der Access-Accept-Nachricht enthaltenen Konfigurationattribute. Damit ist der Benutzer autorisiert. 5. Der RADIUS-Client generiert eine Accounting-Start-Nachricht, nachdem dieser den angeforderten Dienst konfiguriert hat. Die Nachricht enthält Informationen über den Dienst, den Benutzer und gegebenenfalls weitere Parameter. Diese Nachricht wird an den RADIUS-Server gesendet. Der RADIUS-Client wiederholt diese Nachricht, wenn der RADIUS-Server nicht innerhalb einer definierten Zeitspanne den Erhalt quittiert. 6. Wenn der Benutzer den Dienst nicht länger benötigt oder der Dienst auf eine andere Weise terminiert, erzeugt der RADIUS-Client eine Accounting-Stop- Nachricht mit statistischen Informationen über den in Anspruch genommenen Dienst, wie Online-Zeit, übertragenes Datenvolumen et cetera. Der Erhalt dieser Nachricht muss ebenfalls durch den RADIUS-Server quittiert werden. Abbildung 2.7: Ablauf einer RADIUS-Sitzung Seite 18

30 Kapitel 2 - Einführung Grundlagen Ein RADIUS-Server kann unter Linux mit der Open Source Software Freeradius [URL:06] realisiert werden. 2.4 Trusted Network Connect Heutige Rechnersysteme können nicht auf Vertrauenswürdigkeit und Systemintegrität geprüft werden. Aus diesem Grund ist eine vertrauenswürdige Kommunikation zwischen z.b. einem mobilen Mitarbeiter und seinem Unternehmen schwierig. Die Trusted Computing Group ( TCG) entwickelte mit der Spezifikation Trusted Network Connect ( TNC) einen Ansatz zur Realisierung vertrauenswürdiger Verbindungen z.b. über das Internet. Die TNC-Architektur ist die Entwicklung einer offenen und herstellerunabhängigen Spezifikation zur Überprüfung der Integrität von Endpunkten, die einen Verbindungsaufbau starten. Die Architektur bezieht dabei schon bestehende Sicherheitsaspekte, wie VPNs, IEEE 802.1x ( 802.1x), Extensible Authentication Protocol ( EAP), Transport Layer Security ( TLS), Hyper Text Transfer Protocol Security ( HTTPS) und RADIUS mit ein Architektur Die Architektur des Trusted Network Connects ist von der Trusted Computing Group in der Spezifikation 1.1 (Revision 2) vom 1. Mai 2006 veröffentlicht worden (Quelle [URL:29]). Wie in Abbildung 2.8 (Quelle [URL:29]) zu sehen ist, besteht die TNC-Architektur aus der Einheit Access Requestor ( AR) mit den Komponenten Integrity Measurement Collector ( IMC), TNC Client ( TNCC) und Network Access Requestor ( NAR), der Einheit Policy Enforcement Point ( PEP) mit der Komponente Policy Enforcement Point und der Einheit Policy Decision Point ( PDP) mit den Komponenten Integrity Measurement Verifier ( IMV), TNC Server ( TNCS) und Network Access Authority ( NAA). Ähnliche Funktionen oder Rollen in der TNC-Architektur sind durch den Network Access Layer, den Integrity Evaluation Layer und den Integrity Measurement Layer zusammengefasst. Diese drei abstrakten Layer sind waagerecht über die Komponenten der drei Einheiten gelegt worden. Das Zusammenwirken der einzelnen Komponenten wird durch Interfaces realisiert. Seite 19

31 Kapitel 2 - Einführung Grundlagen Abbildung 2.8: TNC-Übersicht (Trusted Computing Group) Einheiten Die Einheiten, sind wie schon erwähnt, der Access Requestor (AR), der Policy Enforcement Point (PEP) und der Policiy Decision Point (PDP) mit den folgenden Aufgaben: Access Requestor (AR) Der Access Requestor stellt die Verbindung in ein geschütztes Netzwerk her. Policiy Decision Point (PDP) Der Policy Decision Point entscheidet für die Anfrage des AR, wie die Zugriffsrechte für die Verbindung aussehen. Policy Enforcement Point (PEP) Der Policy Enforcement Point bildet die von dem PDP erhaltenen Zugriffsberechtigung des AR ab. Alle Einheiten und Komponenten in der Architektur sind logische und nicht physikalische Einheiten oder Komponenten. Die Realisierung der Komponenten oder Einheiten kann in ein Stück Hardware oder Software oder sogar in einem System aus mehreren Maschinen bestehen Komponenten Der AR beinhaltet in der Architektur die folgenden Komponenten: Seite 20

32 Kapitel 2 - Einführung Grundlagen Network Access Requestor (NAR) Der Network Access Requestor ist eine Einheit (z.b. Software-Komponente), welche die Verbindung zu einem Netzwerk herstellt. Es ist nicht ausgeschlossen, dass auf einem AR mehrere NAR s installiert sind, die die Verbindung zu verschiedenen Netzwerken ermöglichen. TNC Client (TNCC) Der TNC Client (Software-Komponente) sammelt die von den IMC s erhaltenen Daten und sendet diese an den TNC-Server. Sind nicht alle Statusinformationen über die IMC s abrufbar, kann der TNC Client zusätzlich selbst Informationen über den Status des Systems abrufen. Integrity Measurement Collector (IMC) Die Integrity Measurement Collectoren sind Software-Komponenten, die den Status des AR (z.b. aktuelle Patch-Infos, aktuelle Viren-Signaturen, Software-Versionen oder den Firewall-Status) an den TNC Client melden. In der TNC-Architektur ist vorgesehen, dass mehrere IMC s auf einem AR installiert sein können und das diese IMC s auch ihre Status-Informationen an mehrere TNC Clients melden können. Der PEP beinhaltet als Komponente nur den Policy Enforcement Point. Diese Komponente regelt die Zugriffe auf das Netzwerk (z.b. durch Access-Listen oder durch VLANs). Der PEP erhält die Berechtigungen für den AR von dem PDP. Der PDP beinhaltet in der Architektur die folgenden Komponenten: Network Access Authority (NAA) Der NAA entscheidet, ob der AR Zugang zu dem Netzwerk erhält. Er kontaktiert den TNCS und fragt dort den Sicherheitsstatus des AR ab. TNC Server (TNCS) Der TNC Server steuert den Datenaustausch zwischen den IMV und dem IMC, sammelt die Empfehlungen (z.b. von dem IMV) und leitet daraus eine Sicherheitsstufe für den NAA ab. Integrity Measurement Verifier (IMV) Der IMV verifiziert (z.b. mit Hilfe eines Integritätstests) den AR anhand der Daten von den IMC s. Seite 21

33 Kapitel 2 - Einführung Grundlagen Layers Die Layers fassen ähnliche Funktionen und Rollen der Einheiten und Komponenten der TNC-Architektur zusammen: Network Access Layer Der Network Access Layer ist für die gesamte Kommunikation von dem AR über den PEP zu dem PDP über ein Netzwerk zuständig. Integrity Evaluation Layer Der Integrity Evaluation Layer ist für eine allgemeine Bestimmung der Zugriffsrechte des AR zuständig. Dabei werden generelle Policies sowie die Ergebnisse des Integrity Measurement Layers gewichtet und berücksichtigt. Integrity Measurement Layer Der Integrity Measurement Layer beinhaltet sämtliche Komponenten (z.b. Plugins oder kleine Programme/Utilities), die eine Sicherheitsüberprüfung des AR ermöglichen Interfaces Für die Kommunikation der Komponenten und Einheiten, sowie für den Austausch von Informationen und Nachrichten untereinander, werden Interfaces benötigt: Integrity Measurement Collector Interface ( IF-IMC) Das Integrity Measurement Collector Interface ist das Interface zwischen dem IMC und dem TNCC. Über dieses Interface werden Informationen über den Status des AR gesammelt und automatisch an den TNCC weitergereicht. Zu beachten ist dabei, dass die IMC s selbstständig und automatisch (ohne Aufforderung) ihren Status an den TNCC melden. Integrity Measurement Verifier Interface ( IF-IMV) Das IMV Interface ist das Interface zwischen den IMV s und dem TNC Server. Über dieses Interface werden die Informationen von den IMC s ausgewertet und eine Empfehlung an den TNC Server über den aktuellen Status des AR s weitergereicht. TNC Client-Server Interface ( IF-TNCCS) Über das TNC Client-Server Interface werden Informationen über den Integritätsstatus des AR s ausgetauscht. Vendor-Specific IMC-IMV Messages (IF-M) Dieses Interface wird für den Austausch von herstellerspezifischen Informatio- Seite 22

34 Kapitel 2 - Einführung Grundlagen nen zwischen den IMCs und den IMVs benötigt. Die Informationen werden über das TNCCS Interface gesendet. Network Authorization Transport Protocol ( IF-T) Über das Network Authorization Transport Protocol Interface werden Nachrichten zwischen dem AR und dem PDP ausgetauscht; also zwischen dem NAR und dem NAA. Policy Enforcement Point Interface ( IF-PEP) Über das Policy Enforcement Point Interface werden Informationen zwischen dem PEP und dem PDP über die Zugriffsrechte (z.b. bestimmtes VLAN, Isolation oder keine Zugangsberechtigung) des AR ausgetauscht Workflow TNC Nachfolgend ist der Verbindungsaufbau eines Trusted Network Connects von einem Network Access Requestor (Client) wie in Abbildung 2.9 (Quelle [URL:29]) zu sehen ist, zum besseren Verständnis, dargestellt: Punkt 0: Vor jedem Verbindungsaufbau muss gewährleistet sein, dass die IMCs gestartet sind und ihre Informationen sowie den Status an den TNC Client melden. Der TNC Client überprüft die Integrität der einzelnen Module; sind alle relevanten Module gestartet und verfügbar, kann mit Punkt 1 fortgefahren werden. Punkt 1: Bei einem automatischen oder manuellen Verbindungsaufbau initiiert der Network Access Requestor auf dem Access Requestor die Verbindung. Punkt 2: Bei einem Verbindungsaufbau des Network Access Requestors sendet der Policy Enforcement Point eine Aufforderung zur Authentisierung an den NAR. Eine Überprüfung der Authentisierung findet dann zwischen dem AR und der NAA statt. Punkt 3: Bei einer erfolgreichen Authentisierung informiert der NAA den TNC Server über den Versuch des Verbindungsaufbaus. Punkt 4: Nun findet eine gegenseitige Authentifizierung zwischen dem TNC Client und dem TNC Server statt. Seite 23

35 Kapitel 2 - Einführung Grundlagen Punkt 5: Nach erfolgreicher gegenseitiger Authentisierung zwischen dem TNCC und dem TNCS signalisiert der TNCS den IMVs, dass ein Verbindungsaufbau generiert werden soll; dies passiert gleichzeitig auch zwischen dem TNCC und den IM- Cs. Der TNCC und der TNCS starten einen Integritätstest; die IMCs senden Informationen (IMC-IMV Messages) zu dem TNCC. Punkt 6A: Der TNCC und der TNCS tauschen Informationen über den Status des AR (Integrität) aus, bis der TNCS mit dem Status des AR zufrieden ist. Der Austausch der Informationen wird durch den NAR, PEP und NAA geleitet. Punkt 6B: Der TNCS leitet alle IMC-Informationen an die betreffenden IMVs weiter. Punkt 6C: Der TNCC leitet alle Anfragen des TNCS an die entsprechenden IMCs weiter. Punkt 7: Nach Beendigung des Integritätstests zwischen dem TNCC und dem TNCS, sendet der TNCS eine Empfehlung des Zugriffs auf das Netzwerk an den NAA. Der NAA entscheidet, welche Zugriffsrechte der NAR bekommt. Punkt 8: Der NAA sendet seine Entscheidung über die Zugriffsberechtigung des NAR an den PEP und den TNCS. Der TNCS leitet die Entscheidung dann an den TNCC weiter, während der PEP den Zugriff des NAR je nach Entscheidung beschränkt oder zulässt. Seite 24

36 Kapitel 2 - Einführung Grundlagen Abbildung 2.9: Workflow der TNC-Architektur Cisco Network Admission Control Das amerikanische Unternehmen Cisco Systems ( [URL:03]) ist eines der ersten Unternehmen auf dem Weltmarkt, welches die TNC-Architektur der Trusted Computing Group umgesetzt hat. Cisco Systems vermarktet dieses Produkt unter dem Namen Network Admission Control ( NAC). Voraussetzung für die Nutzung der NAC Framework Architektur sind folgende Cisco Komponenten: Trusted Network Agent Der Trusted Network Agent sammelt die Informationen von den auf den Clients installierten NAC-Applikationen. Diese Informationen werden, auf Aufforderung von und an den Network Access Device ( NAD) gesendet. Cisco Secure ACS Der Cisco Secure ACS ist der Policy Server, der für die NAC Architektur benötigt wird. Er überprüft die von dem Trust Agent gesammelten Informationen und bestimmt Anhand des Ergebnisse die Policy (Zugriffsberechtigung) des Clients und sendet diese Information an die Network Access Devices. Network Access Devices (NAD) Die Network Access Devices sind Komponenten von Cisco, wie Switches, Router, VPN-Concentrators oder Access Points, die Network Admission Seite 25

37 Kapitel 2 - Einführung Grundlagen Control unterstützen. Die Komponenten setzen die Zugriffsberechtigung des Clients anhand der empfangenen Informationen von dem Cisco Secure ACS. Nachfolgend (siehe Abbildung 2.10, Quelle [HELF06]) ist der Workflow eines Verbindungsaufbaus des Network Admission Control Systems erläutert: Punkt 1: Ein Client mit installiertem Trusted Network Agent versucht auf das Netz zuzugreifen. Der NAD fragt dabei den Status des Cisco Trusted Network Agent ab. Punkt 2: Der Cisco Trust Agent sammelt die relevanten Sicherheitsinformationen von allen NAC fähigen Applikationen und sendet diese zu dem NAD. Punkt 3: Das NAD leitet die gesammelten Informationen an den Cisco Secure ACS weiter. Punkt 4: Der Cisco Secure ACS überprüft die von dem Trust Agent gesendeten Informationen und fällt dann die Entscheidung über den zukünftigen Status des Clients (Quarantäne oder Netzzugriff). Punkt 5: Die Entscheidung über den Status des Clients wird dem NAD mitgeteilt. Punkt 6: Der NAD setzt, anhand der empfangenen Informationen von dem Cisco Secure ACS, die Berechtigungen (Policies) für den Zugriff des Clients, in diesem Fall z.b. Quarantäne. Alle drei Minuten wird die Überprüfung (ab Punkt 2) erneut gestartet. Punkt 7: Dem Benutzer wird über den Trust Agent eine Mitteilung über den Status seines PCs ausgegeben. Er hat nun die Möglichkeit, gegebenenfalls notwendige Updates zu laden. Spätestens nach drei Minuten wird sein System erneut von dem Trust Agent überprüft. Seite 26

38 Kapitel 2 - Einführung Grundlagen Abbildung 2.10: Workflow Cisco NAC 2.5 Verschlüsselung von Daten Für ein Unternehmen ist es immer ein Problem, wenn komplette Rechner, Festplatten oder sogar nur CDs gestohlen werden, da sich auf diesen Datenträgern hoch sensible Daten befinden können. Ein Schutz vor Diebstahl kann nicht immer gewährleistet werden, deswegen ist es notwendig, sensible Daten zu verschlüsseln. Für die Verschlüsselung von Daten können hauptsächlich drei Methoden angewandt werden: Verschlüsselung einzelner Dateien Verschlüsselung mit virtuellen Laufwerken (Containern) Verschlüsselung des gesamten Mediums Verschlüsselung einzelner Dateien Fast jedes Betriebssystem unterstützt die Möglichkeit in dem Filesystem, einzelne Dateien zu verschlüsseln und bei Verwendung der Datei, diese automatisch zu entschlüsseln. Diese Art der Verschlüsselung ist nicht die sicherste, da nach Start des Betriebssystems und mit korrekter Anmeldung diese verschlüsselte Datei automatisch entschlüsselt wird. Diese Dateien sind also auf andere Medien kopierbar. Ein weiteres Problem dieser Verschlüsselung ist, dass dem Benutzer das Verschlüsseln überlassen wird. Der Benutzer muss also manuell das Verschlüsseln der Datei Seite 27

39 Kapitel 2 - Einführung Grundlagen anstoßen; alle anderen Dateien bleiben dabei unverschlüsselt (siehe Abbildung 2.11 Quelle [URL:02]). Abbildung 2.11: Einfache Dateiverschlüsselung Verschlüsselung mit virtuellen Laufwerken (Containern) Diese Art der Verschlüsselung ist die am häufigsten verwendete. Es wird dabei auf dem Laufwerk eine Datei erzeugt, die mit einem beliebigen Verschlüsselungsalgorithmus verschlüsselt wird. Diese Datei kann dann als virtuelles Laufwerk in in das Betriebssystem eingebunden werden und wird wie ein normales Laufwerk angesprochen. Der Zugriff auf dieses Laufwerk ist durch ein Passwort geschützt. Ein Problem jedoch sind temporäre Dateien, die normalerweise in den unverschlüsselten Bereich der Festplatte angelegt werden. Diese temporäre Dateien (bei Microsoft Windows z.b. die Auslagerungsdatei) werden nicht zwingend wieder gelöscht, dass heißt sie können noch komplett oder auch nur in Fragmenten sensible Daten enthalten (siehe Abbildung 2.12 Quelle [URL:02]). Es ist also notwendig, diese Dateien mit in den verschlüsselten Container zu speichern, welches aber nicht mit der Windows Auslagerungsdatei möglich ist. Im Open Source Bereich gibt es einige Programme, die eine Verschlüsselung der Daten ermöglichen, wie z.b. TrueCrypt [URL:28] oder FreeOTFE [URL:05]. Seite 28

40 Kapitel 2 - Einführung Grundlagen Abbildung 2.12: Virtuelle Dateiverschlüsselung (Container) Verschlüsselung des gesamten Mediums Bei der Verschlüsselung des gesamten Mediums wird die komplette Festplatte verschlüsselt (siehe Abbildung 2.13 Quelle [URL:02]). Damit das Betriebssystem geladen werden kann, muss eine PreBoot-Authentication stattfinden, dass heißt der Benutzer wird nach einem Passwort oder Schlüssel vor dem Start des Betriebssystems gefragt. Wird der Schlüssel (z.b. eine Schlüsseldatei auf einem USB-Stick, eine Key-Karte oder ein Passwort) korrekt eingegeben, wird das Betriebssystems während des Startens on the fly entschlüsselt. Diese Art der Datenverschlüsselung ist am sichersten, da alle vorhandenen Dateien auf der Festplatte verschlüsselt sind und ohne den Schlüssel noch nicht einmal das Betriebssystem gestartet werden kann. Die Daten auf der Festplatte sind ebenfalls nicht lesbar, wenn die Festplatte an einen anderen Rechner angeschlossen wird. Probleme können entstehen, wenn das Betriebssystem einfach stehen bleibt und wichtige offene Dateien (oder auch nur der Cache-Speicher der Festplatte) nicht mehr auf die Festplatte geschrieben werden können. Ein korruptes (aber verschlüsseltes) Filesystem könnte die Folge sein. Seite 29

41 Kapitel 2 - Einführung Grundlagen 2.6 Fernadministrierung Abbildung 2.13: Vollstaendige Laufwerksverschlüsselung In großen und mittelständischen Unternehmen können Personalkosten eingespart werden, indem der Support oder der Help-Desk die Möglichkeit haben, sich auf Endgeräte einzuwählen. Bei Problemen oder auch nur für Hilfestellungen, kann ein Dienst auf dem Endgerät gestartet werden, über diesen sich der Support-Mitarbeiter mit dem Endgerät verbindet. Nachdem der Mitarbeiter mit dem Endgerät verbunden ist, wird die Benutzeroberfläche des Betriebssystems auf den Bildschirm des Support-Mitarbeiters gespiegelt. Der Mitarbeiter ist somit in der Lage, das Endgerät so zu bedienen, als ob er vor Ort wäre. Bei Microsoft Windows werden diese Art von Programmen mitgeliefert. Zu nennen sind Microsoft NetMeeting oder der Microsoft Terminaldienst. 2.7 Distributionssoftwareverteilung Ein System, welches in der Lage ist, zentral Softwarepakete, Softwareupdates oder Patches zur Verfügung zu stellen, ist für das Warten, Unterhalten und Pflegen von vielen Endgeräten sehr hilfreich: Zentrales Einspielen von Patches für Virenscanner und Betriebssysteme möglich Einfache Einführung neuer Softwarepakete möglich Reduzierung von Bandbreite, speziell ins Internet Überblick auf installierte Softwarepakete auf den Endgeräten Seite 30

42 Kapitel 2 - Einführung Grundlagen Inventarisieren von Endgeräten möglich Einsparungen von Personal und Kosten Das hierfür bekannteste kommerzielle Produkt ist NetInstall [URL:14] von enteo. NetInstall besteht aus einer Client-Server-Struktur: Server Der Server stellt über das Netzwerk, als Dateiserver (File Share), Ressourcen zur Verfügung. Auf diesem Server sind sämtliche Softwarepakete sowie die Installationsscripte zur Installation der Softwarepakete hinterlegt. Client Der Client wird auf das zu wartende Endgerät installiert. Bei Start des Endgerätes überprüft der Client, ob Updates oder Softwarepakete auf dem NetInstall- Server bereit stehen (preloginloader) und installiert (Script-Processing) diese dann automatisch, ohne dass der Endbenutzer in den Installationsprozess eingreifen kann. Zusätzlich bietet der Client von NetInstall die Möglichkeit der Software on Demand Funktionalität an. Über diese Funktion kann der Benutzer aus einem angebotenem Software-Pool bestimmte Pakete manuell installieren (z.b. einen zusätzlichen Browser wie den Mozilla Firefox) Client Referenzsystem Das Client-Referenzsystem ist die zweitwichtigste Komponente (nach dem Distributions-Software-Server) einer Distributionssoftwareverteilung. Auf diesem Referenzsystem werden die zu erstellenden Softwarepakete erstellt (Scripting) und getestet. Das Erstellen der Installationsscripte ist sehr zeitaufwendig, da keine einheitliche Installationsroutinen für die Softwarepakete vorhanden sind. Es gibt vier Verfahren, wie sich Softwarepakete für die Distributionssoftwareverteilung klassifizieren lassen: 1. Unattended / Silent Setup 2. Administrative Installation 3. Interaktives Setup mit automatischen Antworten 4. Neu-Paketierung Seite 31

43 Kapitel 2 - Einführung Grundlagen Es gibt bei der Erstellung von Scripten kein Patentrezept, jedoch ähneln sich die Installationsscripte sehr stark. Häufig ist es notwendig, einen Kompromiss bei der Erstellung der Scripte zu finden, das heißt eine Kombination der unterschiedlichen Möglichkeiten der Scripterstellung ist häufig sinnvoll Unattended / Silent Setup Bei der Unattended oder Silent Setup Installation wird der Installationsroutine ein spezieller Parameter übergeben, damit das Programm in dem Silent- oder Unattended-Modus ausgeführt wird. In diesem Modus muss und kann der Benutzer nicht in den Installationsprozess eingreifen. Das Programm wird zumeist komplett installiert; falls Konfigurationen notwendig sind, müssen diese auf jedem installierten System nachträglich manuell durchgeführt werden. Unattended- oder Silent Setup Routinen werden hauptsächlich von Microsoft Installer Paketen ( MSI) angeboten. Die gängigen Parameter sind dabei /s, /silent, /quiet, /passive oder /qn. Eine Auflistung der unterschiedlichen Parameter und Installationsprogramme ist unter [URL:26] zu finden Administrative Installation Bei der administrativen Installation wird das Setup-Programm der Anwendung mit einem zusätzlichem Parameter ausgeführt, damit das Installationsprogramm die Eingaben des Software-Administrators während der Installation aufzeichnet. Die Aufzeichnung wird in eine separate Datei protokolliert. Nach Abschluss der Installation hat der Software-Administrator eine Konfigurationsdatei, die alle Eingaben während der Installation (z.b. Lizenz, Auswahl der Tools, Installationsverzeichnis, Konfiguration, etc.) enthält. Mit dieser Datei können zukünftige Installationen erfolgen, dass heißt, es kann eine Unattended oder Silent Setup Installation mit einem Parameter auf die existierende Konfigurationsdatei durchgeführt werden und die Installationsroutine holt alle benötigen Informationen (die vorherigen Eingaben des Administrators) aus der Konfigurationsdatei. Somit entfällt das nachträgliche manuelle Konfigurieren der installierten Anwendung. Programmpakete, die eine administrative Installation erlauben, sind z.b. alle Microsoft Office Pakete. Seite 32

44 Kapitel 2 - Einführung Grundlagen Interaktives Setup mit automatischen Antworten Falls eine Unattended oder Silent Setup Installation nicht möglich ist, muss ein Installationsscript erstellt werden, dass auf Fragen oder benötigte Eingaben der Installationsroutine reagieren kann. Dieses Installationsscript kann mit Hilfe einer Steuerungssoftware (z.b. AutoIt [URL:09]) erstellt werden. Die Steuerungssoftware wartet auf Eingabefenster und füllt diese gemäß des erstellten Scriptes mit Daten. Diese Art der Installation besitzt jedoch auch Nachteile: Nicht berücksichtigte Fehlerfenster können das Installationsscript zum Stoppen bringen. Der Anwender kann mit der Maus oder Tastatur in den Installationsprozess eingreifen oder sogar das Installationsscript vorzeitig beenden. Aus diesem Grund sollte möglichst eine der beiden vorherigen Arten der Erstellung von Installaionsscripten verwendet werden oder falls dies nicht möglich ist, eine Kombination der beiden Installationsarten, wobei der Steuerungsprozess möglichst kurz gehalten wird Neu-Paketierung Ist eine Generierung eines Installationsscriptes mit den vorherigen drei Methoden nicht möglich, muss der Software-Administrator ein neues Paket erstellen. In diesem Paket fasst der Administrator alle zu kopierenden Dateien, alle zu erstellenden Microsft Windows Registry-Einträge sowie die zu erstellenden Links zu einem neuen und eigenständigen Paket zusammen. Damit der Administrator an die benötigten Dateien und Informationen herankommt, muss er die Installation des Programms mit Hilfe einer Spy-Software überwachen. Die Spy-Software protokolliert dabei alle zu kopierenden Dateien und neu eingetragene Registry-Einträge. Diese Dateien können dann zu einem neuen MSI-Paket (z.b. mit Installer2Go [URL:24]) geschnürt werden und dann in dem Silent Modus wieder verteilt und installiert werden. Seite 33

45 Kapitel 3 - Entwicklung des Systemkonzeptes 3 Entwicklung des Systemkonzeptes 3.1 Systemübersicht Die Abbildung 3.1 zeigt die konzeptionelle Gesamtansicht der dedizierten Infrastruktur: Mobile Endgeräte (Clients) Die mobilen Endgeräte sind in der Lage, einen VPN-Tunnel zum Mobile Security Gateway herzustellen, sofern für sie, wie in der Abbildung 3.1 angedeutet, eine Verbindung zum Transportnetz (hier: Internet) über ein beliebiges Transportmedium besteht. Das Tansportnetz muss dafür das eingesetzte VPN- Protokoll, welches für den VPN-Tunnel zum Einsatz kommt, auf der gesamten Transportstrecke unterstützen. Mobile Security Gateway Das Mobile Security Gateway ist an zwei Netze gekoppelt und hat damit gleichzeitig eine Verbindung sowohl mit dem Internet als auch mit dem lokalen LAN. Es enthält modulare Softwarekomponenten, die in Kombination die Funktionalität der Sicherheitsplattform für die mobile Kommunikation ausprägen. Das Mobile Security Gateway enthält die folgenden Module: Modul Firewall Dieses Modul regelt den Zugriff auf die Netzwerkdienste. Modul VPN Dieses Modul ermöglicht die Einwahl der Remote-Mitarbeiter. Modul AAA Dieses Modul regelt die Authentisierung und Autorisierung sowie das Accounting. Modul TNC Das Modul TNC realisiert den Trusted Network Connect in Zusammen- Seite 34

46 Kapitel 3 - Entwicklung des Systemkonzeptes arbeit mit einem speziellem Client (TNC Client), der auf den Remote- Notebooks installiert ist. Modul Distributionssoftwareverteilung Dieses Modul stellt eine Plattform für die Software-Verteilung an die Clients. Client Referenzsystem Das Client Referenzsystem wird für die Entwicklung und Erstellung von Software-Paketen für die Distributionssoftwareverteilung benötigt. Auf diesem System können die Pakete getestet werden und nach erfolgreichem Test für andere Clients freigegeben werden. Verzeichnisdienst Die Komponente Verzeichnisdienst stellt die zentrale Benutzerverwaltung dar. Für den, in dieser Diplomarbeit erstellten Prototyp, wird davon ausgegangen, dass ein beim Kunden vorhandener Verzeichnisdienst mit eingebunden werden kann. Abbildung 3.1: Konzeptionelle Gesamtansicht 3.2 Mobile Endgeräte (Clients) PDA/MDA/iPAQ Für die Einbindung der Geräte in das Gesamtkonzept werden auf den Geräten das Modul VPN benötigt. Die Geräte können mit dem Unternehmensnetz nur über die Protokolle SMTP, POP3 oder IMAP kommunizieren. Der sonstige Datenverkehr wird gefiltert. Seite 35

47 Kapitel 3 - Entwicklung des Systemkonzeptes Verschlüsselung von Daten Die Verschlüsselung der Daten soll nur mit Open Source Software realisiert werden. Die einzige Möglichkeit, die Verschlüsselung zu realisieren, ist mit Hilfe von Containern (virtuellen Laufwerken) möglich. Falls eine komplette Verschlüsselung des Datenträgers gewünscht oder erforderlich ist, muss auf eine kommerzielle Lösung, wie z.b. SafeGuard des Herstellers utimaco [URL:31] zurückgegriffen werden. Fernadministrierung Eine ausführliche Suche nach geeigneter Software für die Fernadministrierung ist negativ ausgefallen. Es gibt zwar Client-Module die Remote-Bildschirme auf den PDA spiegeln können jedoch nicht umgekehrt. Deswegen ist eine Fernadministrierung der PDAs aufgrund von fehlender Software noch nicht möglich Remote Notebooks Für den Trusted Network Connect und die Remote-Einwahl der Notebooks werden auf den Notebooks folgende Module benötigt: VPN / TNC Client Das Modul VPN / TNC Client stellt die Verbindung zum Mobile Security Gateway her und überprüft die Integrität des Notebooks vor der Einwahl. preloginloader Das Modul preloginloader verhindert den Eingriff des Benutzers in den Installationsprozess der Distributionssoftwareverteilung. Script-Processing Dieses Modul stellt die Verbindung zu dem File Share her und führt die Installationsroutinen der zu installierenden Pakete aus. Verschlüsselung von Daten Die Verschlüsselung der sensiblen Daten auf den Notebooks kann durch zwei Möglichkeiten erreicht werden: 1. Erstellen von Containern 2. Verschlüsseln der gesamten Festplatte Für die Verschlüsselung von Daten mit Hilfe von Containern wird ein Verschlüsselungsmodul in das Betriebssystem integriert; bei einer Verschlüsselung der gesamten Seite 36

48 Kapitel 3 - Entwicklung des Systemkonzeptes Platte werden Zusatzprogramme benötigt, welche die Festplatte verschlüsseln und eine Pre-Boot-Authentication in den Boot-Sector der Festplatte schreiben. Fernadministrierung Die Fernadministrierung auf den mobilen Endgeräten ermöglicht ein Server-Modul, welches als Dienst auf den Endgeräten läuft und somit bei Start des Betriebssystems immer verfügbar ist. Bei bestehender Verbindung des Endgerätes in das Unternehmensnetz kann ein Client-Modul sich mit dem Server-Modul verbinden. Über diese Verbindung wird die Benutzeroberfläche des zu administrierenden Endgerätes auf die Benutzeroberfläche des Administrationssystems gespiegelt. Der Verbindungsaufbau zu dem Server-Modul ist mit einem Passwort geschützt; zusätzlich wird die Datenübertragung ebenfalls verschlüsselt. Seite 37

49 Kapitel 3 - Entwicklung des Systemkonzeptes 3.3 Mobile Security Gateway Das mobile Security Gateway (siehe Abbildung 3.2) ist die zentrale Komponente der mobilen Kommunikation und stellt folgende fünf Module zur Verfügung: VPN-Server Firewall Authentisierung, Autorisierung und Accounting (AAA) Trusted Network Connect (TNC) Distributionssoftwareverteilung / Betriebssysteminstallation Abbildung 3.2: Übersicht Remote-Zugriff Seite 38

50 Kapitel 3 - Entwicklung des Systemkonzeptes VPN-Server Dieses Modul ermöglicht eine abhörsichere VPN-Transportverbindung über ein unsichere Transportnetz. Bei der Aushandlung einer VPN-Transportverbindung wird die Identität des Remote-Benutzers angefordert und an das Modul AAA zur Überprüfung weiter gereicht. Bei erfolgloser Überprüfung wird die Aushandlung der VPN-Transportverbindung durch dieses Modul abgebrochen Firewall Das Modul Firewall beschränkt die Zugriffe auf Netzwerkressourcen unter Verwendung statischer Filterregeln. Dies betrifft Zugriffe sowohl aus dem unsicheren Transportnetz, als auch der mobilen Endgeräte mit bestehender VPN-Verbindung. Zusätzliche dynamische Filterregeln erlauben es, den Zugriff mobiler Endgeräte auf Netzwerkressourcen für das Modul Trusted Network Connect anzupassen Authentisierung, Autorisierung und Accounting (AAA) Das Untermodul Authentisierung überprüft die durch das Modul VPN übergebene Benutzeridentität gegen einen externen Verzeichnisdienst im lokalen LAN. Dies entspricht dem Konzept einer zentralen Benutzerverwaltung. Das Ergebnis dieser Überprüfung wird an das Modul VPN zurückgegeben. Das Modul Autorisierung veranlasst nach erfolgreicher Authentisierung die Vergabe einer IP-Adresse für den Endpunkt der VPN-Verbindung auf Seiten des mobilen Endgerätes. Zusätzlich wird für diesen Client eine dynamische Filterregel durch das Modul Firewall, für den Trusted Network Connect in Abhängigkeit von der Benutzeridentität und vergebener IP-Adresse, gesetzt. Das Modul Accounting protokolliert Verbindungsinformationen, wie Online- oder Offline-Status für jede Benutzeridentität auf der Basis von Logdateien. Die Logdateien werden an zentraler Stelle auf einem nichtflüchtigen Speichermedium abgelegt Trusted Network Connect (TNC) Für den Trusted Network Connect werden sowohl auf dem Server, als auch auf dem Client Funktionen benötigt. Seite 39

51 Kapitel 3 - Entwicklung des Systemkonzeptes Server Das Mobile Security Gateway stellt für das Modul Trusted Network Connect (siehe Abbildung 3.3) folgende Funktionen zur Verfügung: Umleiten der VPN-Verbindung in ein gesichertes Segment (Quarantäne) Das Umleiten der VPN-Verbindung in das Quarantäne-Segment geschieht mit Hilfe der Authentifizierung des Benutzers; falls der spezielle Benutzer (hier in dem Prototyp der Benutzer pcpatch) sich anmeldet, wird über den Radius-Server eine Firewall-Regel erstellt. Diese Regel leitet alle Pakete in die Quarantäne-Zone um, so dass nur Softwareupdates und eine Sicherheitsüberprüfung durchgeführt werden können. Filterregeln für PDAs, MDAs und ipaqs Das Mobile Security Gateway erkennt anhand der Benutzerkennung die VPN- Einwahl von PDAs, MDAs und ipaqs. Für diese Geräte wird keine Sicherheitsüberprüfung (wegen eines nicht realisierten VPN-Moduls für diese Geräte) durchgeführt. Es werden automatisch Filterregeln aktiviert, die nur Zugriffe auf s über SMTP, POP3 oder IMAP zulassen. Bereitstellen der Client-Listen Die Client-Listen enthalten alle installierten Software-Pakete der Clients. Darunter befinden sich Patches, Updates, Service-Packs sowie alle weiteren installierten Pakete. Bereitstellen der Referenzliste Die Referenzliste enthält alle relevanten Informationen für die Sicherheitsüberprüfung und wird von dem Modul VPN des Notebooks ausgelesen. Notebooks Der Trusted Network Connect (siehe Abbildung 3.3) wird über eine spezielles Modul (VPN) realisiert. Dieses Modul startet eine VPN-Einwahl (VPN-speziell) mit den folgenden Funktionen: Durchführung relevanter Updates (Software und Signaturen für Virenscanner). Sicherheitsüberprüfung für den Netzzugang. Seite 40

52 Kapitel 3 - Entwicklung des Systemkonzeptes Bei erfolgreicher Sicherheitsüberprüfung wird der mobile Mitarbeiter über eine normale VPN-Verbindung mit dem Unternehmensnetz verbunden. Firewall-Regeln werden in diesem Fall nicht aktiviert. PDA/MDA/iPAQ Bei einer Einwahl eines PDAs, MDAs oder ipaqs (siehe Abbildung 3.3) wird der eingehende Datenverkehr dieser Endgeräte über eine Firewall-Regel in das lokale LAN des Unternehmens weiter geleitet. Die Firewall-Regel erlaubt lediglich Zugriffe auf s über SMTP, POP3 oder IMAP. Abbildung 3.3: Modul Trusted Network Connect Seite 41

53 Kapitel 3 - Entwicklung des Systemkonzeptes Distributionssoftwareverteilung Softwarepakete Für die Client-Softwareverteilung (siehe Abbildung 3.4) stellt das Modul File Share auf dem Mobile Security Gateway ein Laufwerk zur Verfügung. Auf dieses Laufwerk greift der Client mit dem Modul Script-Processing zu und führt die Installation der bereitstehenden Softwarepakete durch. Das Modul preloginloader auf dem Client verhindert ein Eingreifen des Benutzers in den Installationsprozess. Abbildung 3.4: Client-Softwareverteilung Betriebssysteminstallation Für eine Neuinstallation des Client-Betriebssystems werden auf dem Mobile Security Gateway zusätzlich folgende Module benötigt: DHCP-Server (Vergabe der Netzinformationen) TFTP-Server (Starten und übertragen eines Boot-Images) Betriebsysteminstallation Die Client-Betriebssysteminstallation kann entweder über PXE-Boot (siehe Abbildung 3.5) oder über eine Boot-CD (siehe Abbildung 3.6) gestartet werden. Nach Abschluss der Installation wird mit der Softwareverteilung des Clients fortgefahren. Seite 42

54 Kapitel 3 - Entwicklung des Systemkonzeptes Abbildung 3.5: Client-Betriebssysteminstallation über PXE-Boot Abbildung 3.6: Client-Betriebssysteminstallation über Boot-CD Seite 43

55 Kapitel 4 - Prototypische Realisierung 4 Prototypische Realisierung 4.1 Voraussetzungen im Unternehmensnetz Folgende Voraussetzungen müssen in dem Unternehmensnetz geschaffen werden, damit die hier vorgestellte prototypische Lösung optimal in ein vorhandenes Unternehmensnetz integriert werden kann: Primary Domain Controller Es muss ein Primary Domain Controller mit Active Directory in dem Unternehmensnetz installiert sein. Die Authentifizierung und das festlegen der Sicherheitsrichtlinien der mobilen Mitarbeiter erfolgt über den PDC. Die hier vorgestellte Lösung ist mit Microsoft Advanced 2000 Server und Microsoft Advanced 2003 Server getestet. Da die gesamte prototypische Umsetzung einem modularen Konzept entspricht, kann der Primary Domain Controller auch durch ein anderes Modul (z.b. durch LDAP) ersetzt werden. DNS-Server Für die Namensauflösung von Endgeräten der mobilen Mitarbeiter ist ein Domain Name Server (DNS) notwendig; häufig ist auf dem PDC der DNS-Dienst integriert. DHCP-Server Für eine mögliche Installation eines Clients über PXE-Boot muss der neue Server (Mobile Security Gateway) als DHCP-Server fungieren. Ist dies nicht möglich, kann eine PXE-Boot-Installation nicht durchgeführt werden; alternativ kann der Client mit Hilfe einer Boot-CD installiert werden. Auf dem DHCP-Server ist ein IP-Bereich für die Einwahl der mobilen Mitarbeiter auszuklammern. Mobile Security Gateway Für die Einwahl und Authentifizierung der mobilen Mitarbeiter ist es notwendig, den neuen Mobile Security Gateway Server möglichst nah an die Internetanbindung aufzustellen und diesen Server mit in die Domäne aufzunehmen. Seite 44

56 Kapitel 4 - Prototypische Realisierung Zusätzlich ist für den TNC ein neuer Benutzer (pcpatch) auf dem PDC anzulegen. 4.2 Systemarchitektur des Prototypen Hardware Umgebung Abbildung 4.1 zeigt die Gesamtansicht des Versuchsaufbaus. Dieser besteht aus den folgenden Systemen: Mobile Security Gateway: Das mobile Security Gateway ist ein x86-basierter Standard-PC. Dieses System enthält drei Netzwerkschnittstellen: eth0: Diese Schnittstelle ist an ein gedachtes öffentliches Netzwerk angeschlossen. Um die Testumgebung möglichst realitätsnah aufzusetzen, werden in diesem Netz keine privaten IP-Adressen nach RFC1918 verwendet. eth1: Diese Schnittstelle ist an das Lokale LAN angeschlossen. In diesem Netzwerk werden IP-Adressen aus RFC1918 verwendet. eth2: Diese Schnittstelle verfügt über eine Verbindung zum Internet. Diese ist nötig, damit eine Online-Installation sowohl des Debian-Betriebssystems als auch der im Rahmen der Realisierung benötigen Software-Pakete erfolgen kann. Weiterhin simuliert das Mobile Security Gateway das Standard- Gateway für die Clients im lokalen LAN. Primary Domain Controller: Der Primary Domain Controller ist ein x86-basierter Standard-PC. Dieses System beinhaltet den Verzeichnisdient. Client-1: Dieses System ist ebenfalls ein x86-basierter Standard-PC, der das Notebook eines mobilen Mitarbeiters an unterschiedlichen Standorten repräsentiert. Client- 1 besitzt zwei Netzwerkschnittstellen für die drahtlose und drahtgebundene Kommunikation PDA: Der verwendete PDA ist das Modell ipaq hw6910/hw6915 [URL:11] der Seite 45

57 Kapitel 4 - Prototypische Realisierung Firma Hewlett Packard. Dieses Modell ist ein so genanntes Smartphone. Geboten werden unterschiedliche Arten der Netzwerkkonnektivität, wobei in dieser Realisierung die Netzwerkanbindung über Wireless LAN, nach dem Standard b, erfolgt. Die übrigen Möglichkeiten der Netzwerkanbindung konnten nicht getestet werden, da keine entsprechenden Zugriffspunkte für den Versuchsaufbau verfügbar waren. Abbildung 4.1: Übersicht Systemarchitektur Software Umgebung Dieser Abschnitt beschreibt die Softwareumgebung der in dieser Realisierung verwendeten Systeme: Mobile Security Gateway: Auf diesem System wird Debian GNU/Linux 3.1 (Sarge) benötigt (Installationsanleitung siehe Anhang A). Primary Domain Controller: Auf diesem System wird der Verzeichnisdienst Active Directory unter Windows 2000 Server oder Windows 2003 Server ausgeführt (Installationsanleitungen siehe Anhang A). Die Realisierung konnte als Ganzes mit beiden Betriebssystemen erfolgreich getestet werden. Client-1: Für diese Maschine wird als Betriebssystem Windows XP oder Windows 2000 Seite 46

58 Kapitel 4 - Prototypische Realisierung verwendet. Die Installation dieser Betriebssystems erfolgt mit Hilfe der Distributionssoftwareverteilung via PXE-Boot. Da für diese Arbeit nicht genügend Hardware (ein weiterer PC) zur Verfügung stand, wurde dieser Client zusätzlich als Client-Referenzsystem verwendet. Aus diesem Grund wurde zusätzlich das Script-Paket AutoIT in der Version 3 installiert. PDA: Auf diesem Gerät ist werksseitig das Betriebssystem Windows Mobile 5.0 installiert. Seite 47

59 Kapitel 4 - Prototypische Realisierung 4.3 Implementierung VPN-Server Die Funktionalität des VPN-Servers wurde durch Standard-Software unter Verwendung von umfassenden Hilfestellungen und Konfigurationsbeispielen in [DELE07] realisiert (Installationsanleitung siehe Anhang A). Es wurden insgesamt vier Software-Pakete benötigt: 1. Openswan, Version (Debian stable) 2. l2tpd, 0.70-pre (Debian testing) 3. ppp, Version (Debian testing) 4. radiusclient1, Version (Debian testing) Die ersten drei Pakete realisieren den benötigten Protokollstack (siehe auch Abbildung 4.2): Openswan implementiert das IPSec-Protokoll. Das Paket l2tpd implementiert das Layer-2 Tunneling Protocol. Für die Realisierung des PPP-Protokolls ist das Paket ppp zuständig. Abbildung 4.2: Realisierung des IPSec-L2TP-PPP Protokollstacks unter Linux openswan Die Voraussetzung für den Betrieb von IPSec setzt die Unterstützung durch den Linux-Kernel voraus. Die in der Debian-Distribution enthaltenen Kernel erfüllen diese Voraussetzung bereits. Seite 48

60 Kapitel 4 - Prototypische Realisierung Die IPSec-Konfiguration spezifiziert einen Ende-Zu-Ende Tunnel zwischen dem mobilen Endgerät und dem Openswan-Server auf dem Mobile Security Gateway. Sobald diese Verbindung besteht, initiiert das mobile Endgerät eine Verbindung zum L2TP- Server auf dem Mobile Security Gateway. Openswan unterstützt die Authentisierung sowohl mit Zertifikaten als auch mit Preshared Keys. Da die Konfiguration von IPSec sehr komplex ausfallen kann, wurden für die prototypische Realisierung der IPSec-Implementierung Pre-Shared-Keys als Basis für die maschinenbezogene Authentisierung aller Clients gewählt. Diese Art der maschinenbezogenen Authentisierung ist nicht die sicherste, deshalb sollte für einen späteren produktiven Einsatz die Verwendung von Zertifikaten in Erwägung gezogen werden. Die hier verwendete Konfiguration entspricht einer leicht modifizierten Version, die hier [DELE07] (Abschnitt ) vorgestellt wurde l2tpd Das Layer-2 Tunneling Protocol (L2TP) erfüllt im Rahmen dieser Realisierung keine Sicherungsfunktionen. Diese sind auch nicht notwendig, da die VPN-Eigenschaften Vertraulichkeit, Integrität und Authentizität bereits auf IPSec-Ebene gesichert sind. L2TP transportiert lediglich Pakete des PPP-Protokolls. Die Konfiguration des L2TP-Servers ist mit nur elf notwendigen Zeilen in der Konfigurationsdatei (siehe auch [DELE07] (Abschnitt 14)) wenig aufwendig. Der L2TP-Daemon übergibt nach dem Aufbau einer L2TP-Verbindung die Kontrolle der Verbindung selbstständig an den PPP-Daemon ppp und radiusclient1 Die PPP-Implementierung ppp, in Kombination mit dem Paket radiusclient1 stellt den Network Access Server (NAS) im Sinne von AAA dar. Über die LCP- Erweiterungen des PPP-Protokolls erfolgt die personenbezogene Authentisierung via CHAP (Hier: MS-CHAPv2) sowie die Aushandlung weiterer Verbindungsparameter, z.b. die Konfiguration des entfernten Endpunktes mit einer durch den RADIUS- Server vergebenen IP-Adresse. Das Plugin radius.so, enthalten im Paket ppp und das Paket radiusclient1 kommunizieren über eine gemeinsame Schnittstelle. Das Plugin hat dabei direkten Einfluss auf die Verbindungssteuerung der PPP-Implementierung. Für jede PPP-Verbindung erscheint unter Linux ein entsprechendes virtuelles PPP- Device mit der durch den AAA-Server zugewiesenen IP-Adresse als entfernter Tunnelendpunkt. Anhand der IP-Adresse ist eine unabhängige Paketfilterung mittels Seite 49

61 Kapitel 4 - Prototypische Realisierung Firewall für jede VPN-Verbindung möglich. Die Konfiguration dieser Pakete basiert auf einem HowTo über die Nutzung des Authentisierungsprotokolls MS-CHAPv2 mit dem AAA-Server Freeradius [KWOK07]. Der Autor geht in seinem HowTo von der Nutzung des Point-To-Point Tunneling Protokolls (PPTP) als VPN-Lösung für Windows mit einem Linux VPN Server aus. PPTP wurde allerdings als unsicher eingestuft (siehe auch: [URL:01]). Die in dem HowTo beschriebene Umsetzung ließ sich jedoch auf die hier realisierte Lösung mit IPSec/L2TP übertragen, indem statt PPTP das normale PPP-Protokoll verwendet wurde. Seite 50

62 Kapitel 4 - Prototypische Realisierung 4.4 Implementierung Firewall Einleitung Für die Realisierung der Firewall-Funktionen kommt der unter Linux verfügbare Paketfilter IPTables [URL:15] zum Einsatz (Installationsanleitung siehe Anhang A). Die Firewall erfüllt folgende Funktionen: Zugriffsbeschränkung von außen: Aus dem nicht vertrauenswürdigen Netzwerk (dem Internet) ist lediglich der Zugriff auf den IPSec-Dienst möglich, um den mobilen Mitarbeitern die VPN- Einwahl zu gestatten. Zugriffsbeschränkung von innen: Zugriffe auf interne Dienste des Mobile Security Gateway und das lokale LAN werden zur Laufzeit einer VPN-Verbindung aus Sicht der mobilen Endgeräte benutzerabhängig eingeschränkt. Auf diese Weise wird einerseits die Quarantänezone für die mobilen Endgeräte während der Sicherheitsüberprüfung realisiert. Andererseits wird dadurch erreicht, dass mobile Endgeräte nach erfolgreicher Sicherheitsüberprüfung zwar Zugriff auf das lokale LAN, jedoch nicht auf das Mobile Security Gateway selbst bekommen. Dies ist sinnvoll, um sicher zu stellen, dass ein Zugriff auf administrative Dienste des Mobile Security Gateways nur über Arbeitsstationen im lokalen LAN erfolgen kann Quarantänezone Für die Sicherheitsüberprüfung und Softwareupdates benötigt das mobile Endgerät Zugriff auf ein File Share. Dieses befindet sich auf dem Mobile Security Gateway und verwendet die Protkolle CIFS (Common Internet File System) via Port 445/TCP und Netbios Name Service via Port 137/UDP. Weiterhin muss es dem mobilen Endgerät möglich sein, einen Ping an das Mobile Security Gateway abzusetzen, da die korrekte Funktion der Softwareversorgung davon abhängt. Daraus lassen sich direkt die Zugriffsrechte der mobilen Endgeräte innerhalb der Quarantänezone ableiten: Der Zugriff darf nur lokal auf das Mobile Security Gateway erfolgen. Es ist lediglich das Verwenden der benötigten Protokolle CIFS (Port: 445/T- CP), Netbios Name Service (Port: 137/UDP) und ICMP möglich. Die übrigen Seite 51

63 Kapitel 4 - Prototypische Realisierung Dienste auf dem Mobile Security Gateway sind vor Zugriffen der mobilen Endgeräte zu schützen Statische Filterregeln Die statischen Filterregeln wurden über ein Shell-Skript definiert. Während des Systemstarts wird das Skript automatisch abgearbeitet und ermöglicht so das Setzen der statischen Filterregeln. Die davon betroffenen Filterlisten (in der IPTables-Notation als Chains bezeichnet), sind die in der Netfilter-Architektur Vorgegebenen, mit der Bezeichnung filter/input, filter/forward und filter/output. Generelle Filterregeln (Sicherheitsrichtlinien) Die generellen Sicherheitsrichtlinien (in der IPTables-Notation als Policy bezeichnet) entscheiden, wie zu verfahren ist, wenn auf ein Datenpaket keine spezielle Filterregel zutrifft. Diese Richtlinien gelten für alle Netzwerkschnittstellen und wurden wie folgt definiert: Eingehende Pakete an die lokale Maschine (Mobile Security Gateway) sind zu verwerfen. Ausgenommen sind Antwortpakete, die bestehenden Verbindungen zugeordnet werden können (Stateful Packet Inspection). Über die lokale Maschine (Mobile Security Gateway) zu routende Pakete sind zu verwerfen. Ausgenommen sind auch hier Antwortpakete, die bestehenden Verbindungen zugeordnet werden können. Ausgehende Pakete der lokalen Maschine sind erlaubt. Schnittstellenabhängige Filterregeln Die statischen Filterregeln behandeln den Datenfluss in Abhängigkeit der verwendeten Netzwerkschnittstelle. Im Folgenden sind unterschiedliche Filterregeln für jede relevante Netzwerkschnittstelle definiert: Loopback-Interface (lo): Die Definition der generellen Filterregeln unterbindet auch die Kommunikation lokaler Prozesse über das Loopback-Interface. Von dem Loopback-Interface eingehende Datenpakete müssen daher akzeptiert werden. Seite 52

64 Kapitel 4 - Prototypische Realisierung Internet-Schnittstelle (eth0): Von dieser Schnittstelle werden, mit Ausnahme der für den Betrieb von IPSec erforderlichen Protokolle, alle eingehenden und zu routenden Pakete verworfen. LAN-Schnittstelle (eth1): Datenverkehr von dieser Schnittstelle unterliegt keiner Beschränkung, das heißt, eingehende und zu routende Datenpakete werden akzeptiert. Einwahl-Schnittstellen (pppx): Datenverkehr von diesen Schnittstellen (der VPN-Endpunkte) unterliegt unterschiedlichen Zugriffsbeschränkungen, die benutzerabhängig sind. Diese Zugriffsbeschränkungen werden durch dynamische Filterregeln während der VPN-Einwahl realisiert. Der Datenverkehr von diesen Schnittstellen wird daher nicht statisch gefiltert, sondern zunächst in zwei benutzerdefinierte Filterlisten umgeleitet: Filterliste vpn in für eingehende Datenpakete (in die Quarantänezone) Filterliste vpn fwd für zu routende Datenpakete (in das lokale LAN) Dynamische Filterregeln Die benutzerabhängige Filterung des Datenverkehrs wird durch ein Shell-Skript ermöglicht, welches der AAA-Server selbstständig anstößt wenn ein VPN-Benutzer erfolgreich authentisiert wurde oder die VPN-Verbindung terminiert. Das Skript verarbeitet drei Argumente: 1. Aktion: Dieses Argument hat drei Ausprägungen: Init, Start und Stop. Init: Erstellt die benutzerdefinierten Filterlisten vpn in, vpn fwd und erzeugt in beiden Filterlisten eine dauerhafte Filterregel, die ICMP-Pakete der mobilen Endgeräte akzeptiert. Diese Aktion wird einmal, während der Erstellung der statischen Filterregeln, ausgeführt. Start: dient dem Hinzufügen einer Filterregel. Stop: dient der Löschung einer Filterregel. 2. Benutzername: Anhand des Benutzernamens entscheidet das Skript, welche der benutzerdefinierten Filterlisten zu manipulieren sind und welche Regelvorlagen dort ange- Seite 53

65 Kapitel 4 - Prototypische Realisierung wendet werden. Bei einem VPN-Verbindungsaufbau mit dem Benutzernamen pcpatch wird die benutzerdefinierte Filterliste vpn in manipuliert. 3. IP-Adresse: Die IP-Adresse bildet in Kombination mit einer im Skript definierten Vorlage die Ausprägung einer konkreten Filterregel. Bei Beendigung einer VPN- Verbindung wird die zu löschende Filterregel anhand der IP-Adresse selektiert. Die folgende Abbildung (siehe 4.3) zeigt den Ablauf des Skripts, wenn dieses durch den AAA-Server angestoßen wird. Abbildung 4.3: Scriptablauf dynamische Filterregeln Seite 54

66 Kapitel 4 - Prototypische Realisierung 4.5 Implementierung AAA Die Realisierung des AAA-Servers erfolgt durch die Software Freeradius [URL:06]. Die erste Version wurde im Jahr 1999 veröffentlicht und seitdem ständig weiterentwickelt. Neben dem ursprünglichen RADIUS-Protokoll werden auch herstellerspezifische Erweiterungen unterstützt. Dadurch wird es beispielsweise ermöglicht, das CHAP-Protokoll mit den von Microsoft spezifizierten Erweiterungen, als MS-CHAP bezeichnet, für die Authentisierung zu verwenden. Die Umsetzung erfolgte im Wesentlichen nach der in [KWOK07] beschriebenen Prozedur (Installationsanleitung siehe Anhang A). Es wurden die folgenden Pakete benötigt: Freeradius, Version (Debian Testing) Samba, Version (Debian Testing) krb5-user, Version (Debian Testing) Authentisierung Damit Freeradius die Authentisierung der Benutzer gegen den Verzeichnisdienst Active Directory vornehmen kann, sind zusätzliche Vorbereitungen nötig: Freeradius kann nicht direkt auf den Active Directory Verzeichnisdienst zugreifen. Stattdessen verwendet Freeradius während des Ablaufs einer Authentisierung ein externes Werkzeug aus dem Paket Samba. Dieses Werkzeug ist in der Lage, direkt mit dem Active Directory Verzeichnisdienst zu kommunizieren und geeignete Rückgabewerte zu erzeugen. Anhand der Rückgabewerte entscheidet Freeradius über den Status der Authentisierung eines Benutzers. Vorbereitungen Das Mobile Security Gateway ist in die Windows-Domäne zu integrieren. Dazu wird ein Samba-Server aufgesetzt. Das Ziel dabei ist nicht der Zugriff auf ein File Share, sondern der Einsatz einiger mitgelieferter Werkzeuge. Die zwei wichtigsten Komponenten sind: Winbind: Dieser Dienst ermöglicht die Kommunikation mit einer Windows-Umgebung und das Abbilden von Active Directory Benutzern auf Unix-Benutzer. ntlm auth: Dieses Werkzeug verarbeitet NTLM (NT Lan Manager) Anfragen in Zusamm- Seite 55

67 Kapitel 4 - Prototypische Realisierung menarbeit mit Winbind. Es ermöglicht die Verifikation von Benutzern auf dem Windows-Domänencontroller und gibt bei Aufruf entweder eine Erfolgs- oder eine Fehlermeldung zurück: vpn-gateway:~# ntlm_auth --username andreas --password andreas NT_STATUS_OK: Success (0x0) vpn-gateway:~# ntlm_auth --username andreas --password xyx NT_STATUS_WRONG_PASSWORD: Wrong Password (0xc000006a) Die Integration des Mobile Security Gateway in die Windows-Domäne erfolgt generell durch Anlegen eines Computerkontos auf dem Active Directory Domänencontroller. Dies geschieht mit Hilfe der im Paket Samba enthaltenen Werkzeuge. Diese erlauben es, den Active Directory Domänencontroller in Grenzen zu konfigurieren. Es können zum Beispiel auch normale Benutzer hinzugefügt, geändert oder gelöscht werden. Da Active Directory das Kerberos-Protokoll für die Authentisierung verwendet, ist eine Minimalkonfiguration des Mobile Security Gateways als Kerberos- Client, mit Hilfe des Paketes krb5-user, unumgänglich. Auf dem Domänencontroller selbst sind zusätzlich weder Einstellungen noch Software nötig. Ablauf der Authentisierung Wenn sich ein Benutzer per VPN einwählt, erhält der RADIUS-Server eine Access- Request-Nachricht (Abbildung 4.4). Aus dieser werden die notwendigen Daten zur Authentisierung extrahiert, übersetzt und anschließend an das externe Programm ntlm auth übergeben. Der folgende Auszug zeigt die erfolgreiche Verifikation des Benutzers pcpatch; ntlm auth erzeugt den Rückgabewert null. Kann der Benutzer nicht erfolgreich verifiziert werden, liefert ntlm auth eine Fehlermeldung, die dazu führt, dass der RADIUS-Server eine Access-Reject-Nachricht an den VPN-Server sendet. Dieser trennt darauf hin die Verbindung zum Client. Seite 56

68 Kapitel 4 - Prototypische Realisierung rad_recv: Access-Request packet from host :32768, id=162, length=135 Service-Type = Framed-User Framed-Protocol = PPP User-Name = "pcpatch" MS-CHAP-Challenge = 0x8d7be22aff2dfa7f71901a2db3cdeec6 MS-CHAP2-Response = 0xf300773a62435f53df283 (gekürzt) NAS-IP-Address = NAS-Port = 0 Processing the authorize section of radiusd.conf <snip> Exec-Program: /usr/bin/ntlm_auth --request-nt-key --username=pcpatch --challenge=7b8baeb26f8eb740 --nt-response=124e057b53895bfd a693ed5c a9 Exec-Program output: NT_KEY: B8513A4460C6FBF875C76B3DE49FB156 Exec-Program-Wait: plaintext: NT_KEY: B8513A4460C6FBF875C76B3DE49FB156 Exec-Program: returned: 0 Abbildung 4.4: Beispiel einer Access-Request-Nachricht Autorisierung Nach der erfolgreichen Authentisierung eines VPN-Benutzers wird dem entsprechenden mobilen Endgerät eine IP-Adresse aus einem reservierten Bereich des lokalen LANs zugewiesen. Die IP-Adresse wird als zusätzliches RADIUS-Attribut der Access-Accept-Nachricht hinzugefügt (Abbildung 4.5). Anschließend stößt der RADIUS-Server ein externes Skript an, und übergibt diesem zwei RADIUS-Attribute: den Namen des Benutzers sowie die soeben zugewiesene IP-Adresse. Dieses externe Skript legt darauf hin eine dynamische Filterregel für den mobilen Client an. rlm_ippool: Allocated ip to client on nas ,port 0 modcall[post-auth]: module "main_pool" returns ok for request 0 modcall: leaving group post-auth (returns ok) for request 0 Sending Access-Accept of id 162 to port Framed-Protocol == PPP MS-CHAP2-Success = 0xf3533d (gekürzt) MS-MPPE-Recv-Key = 0xc8abbd bffe15444a0dd42c59d MS-MPPE-Send-Key = 0xc12a e700709a181ec53e311 MS-MPPE-Encryption-Policy = 0x MS-MPPE-Encryption-Types = 0x Framed-IP-Address = Framed-IP-Netmask = Finished request 0 Abbildung 4.5: Beispiel einer Access-Accept-Nachricht Seite 57

69 Kapitel 4 - Prototypische Realisierung Accounting Der RADIUS-Server erhält durch den ppp-daemon eine Accounting-Start-Nachricht bei Beginn einer VPN-Sitzung, sowie eine Accounting-Stop-Nachricht bei Ende einer VPN-Sitzung. Diese Nachrichten werden in einem dedizierten Accounting- Verzeichnis nach folgender Struktur organisiert: /var/log/freeradius/radacct/benutzername/detail-jjjjmmtt Somit werden die Aktivitäten eines Benutzers in einer täglichen Übersicht zusammengefasst. Die folgenden Auszüge (Abbildung 4.6 und 4.7) zeigen beispielhaft die durch den RADIUS-Server aufgezeichneten Accounting-Nachrichten für den Benutzer pcpatch in verkürzter Form: Thu Apr 5 12:33: Acct-Session-Id = "4614D084562A00" User-Name = "pcpatch" Acct-Status-Type = Start Framed-Protocol = PPP Framed-IP-Address = NAS-IP-Address = NAS-Port = 0 Acct-Unique-Session-Id = "3b19040a f" Timestamp = Abbildung 4.6: Beispiel einer Accounting-Start-Nachricht Thu Apr 5 13:45: Acct-Session-Id = "4614D084562A00" User-Name = "pcpatch" Acct-Status-Type = Stop Framed-Protocol = PPP Acct-Session-Time = 4326 Acct-Output-Octets = 33 Acct-Input-Octets = Acct-Output-Packets = 2 Acct-Input-Packets = 124 Acct-Terminate-Cause = User-Request Framed-IP-Address = NAS-IP-Address = NAS-Port = 0 Acct-Unique-Session-Id = "3b19040a f" Timestamp = Abbildung 4.7: Beispiel einer Accounting-Stop-Nachricht Die Accounting-Stop-Nachricht enthält zusätzliche Statusinformationen bezüglich Verbindungsdauer, übertragenem Datenvolumen sowie dem Grund der Verbindungstrennung. Als Erweiterung dieser Lösung wäre es sinnvoll, die gesammelten Daten einer Auswertung zu unterziehen. Dabei sind zum Beispiel die folgenden Kriterien Seite 58

70 Kapitel 4 - Prototypische Realisierung denkbar: Auswertung nach Login-Zeiten: Dies ermöglicht dem Administrator beispielsweise, Zugänge auf Mißbrauch zu überwachen (Feststellung ungewöhnlicher Anmeldezeiten) Auswertung nach Datenvolumen: Dadurch kann der Administrator beispielsweise die Auslastung der Zugänge einschätzen, aber auch Mißbrauch feststellen, wenn ein Benutzer in einem bestimmten Zeitraum ein ungewöhnlich hohes Datenvolumen beansprucht. Anhand dieser Kriterien kann der Administrator entsprechende Maßnahmen ergreifen, zum Beispiel Zeitfenster für die Einwahl definieren oder Benutzer sperren. Es wäre auch denkbar, die Sperrung eines Benutzerkontos nach einer bestimmten Anzahl fehlgeschlagener Anmeldeversuche in einem definierten Zeitraum automatisch zu veranlassen. Seite 59

71 Kapitel 4 - Prototypische Realisierung 4.6 Implementierung Distributionssoftwareverteilung Für die Distributionssoftwareverteilung kommt das nach GPL Open Source Produkt opsi (open - PC ServerIntegration) in der Version 2.5 vom September 2006 des Dienstleistungsunternehmens uib (URL [URL:30]) zum Einsatz. Diese Software entwickelte das Unternehmen uib vor 8 Jahren für eine Landesverwaltung und ist seitdem auf über 2000 PCs produktiv im Einsatz. Die Wahl fiel auf dieses Produkt, da eine langjährige Erfahrung des Unternehmens mit diesem Produkt besteht, dieses Produkt weiter entwickelt wird, ein umfangreiches Forum zur Verfügung steht und gegebenenfalls Unterstützung bei Problemen durch das Unternehmen eingekauft werden kann. Die Software hat Funktionen einer automatischen Softwareverteilung auf PCs und die Möglichkeit einer automatischen Betriebssysteminstallation. Diese Funktionen werden durch Module auf dem Client (opsi-winst mit opsi-preloginloader) und auf dem Server (opsi-depotserver) realisiert. Zu Beginn dieser Diplomarbeit ist die opsi Version 3.0 nur mit dem Status Beta verfügbar. Aus diesem Grunde kommt die stabile Version 2.5 zum Einsatz Server Der opsi-depotserver stellt die Komponenten für die automatische Softwareverteilung und Betriebssysteminstallation zur Verfügung. Die Software basiert auf Debian GNU/Linux als Server, um eine hohe Verfügbarkeit und Stabilität zu gewährleisten. Der Server basiert auf einem File Share (realisiert mit Samba) und stellt weitere Dienste (DHCP, BOOTP und TFTP) für eine automatische Installation von Softwarepaketen oder Betriebs Eine Installationsanleitung des opsi-depotservers, sowie Anpassungen für diese prototypische Realisierung der mobilen Infrastruktur sind im Anhang A) zu finden Client Die Integration des Clients in die Softwareverteilung mit Hilfe der Software opsi wird durch die Komponenten opsi-winst in der Version 4.2 und durch den opsipreloginloader realisiert. Der opsi-preloginloader überprüft nach jedem Boot und vor einem Login des Users anhand von Konfigurationsdateien auf einem File Share, ob relevante Updates für den Client zur Verfügung stehen. Bei einem vorhandenem Update wird das Instal- Seite 60

72 Kapitel 4 - Prototypische Realisierung lationsprogramm Winst aufgerufen, welches die Installation der notwendigen Programme durchführt. Die Komponente opsi-winst ist ein Interpreter für eine einfache Script-Sprache, mit der Installationen von Programmen durchgeführt werden können. Der Interpreter unterstützt dabei die folgenden Vorteile gegenüber einer Installation mit Commandshell-Aufrufen: Der Ablauf der Installation wird protokolliert. Kopieraktionen können differenziert werden (welche Dateien und inwieweit schon vorhandene Dateien überschrieben werden sollen) Systemdateien können vor dem Überschreiben auf ihre interne Version überprüft werden. Manipulationen der Windows-Registry sind möglich. Eine ausführliche Syntax der unterstützten Befehle und Funktionen des Interpreters, sowie der Aufbau des opsi-winst-scriptes sind im Anhang A zu finden Erweiterung für den TNC Für die Realisierung des Trusted Network Connects und der integrierten Sicherheitsüberprüfung, muss eine Client-Referenzliste auf dem Server hinterlegt werden. Diese Referenzliste enthält alle Softwarepakete (die automatisch an die Clients verteilt werden) mit einem Attribut: on Das Attribut on besagt, dass dieses Paket auf dem Client installiert sein muss. Ist dieses Paket nicht auf dem Client installiert, wird der Integritätstest des TNC Clients negativ ausfallen. off Das Attribut off besagt, dass dieses Paket auf dem Client nicht installiert sein darf. Ist dieses Paket trotzdem auf dem Client installiert, wird der Integritätstest des TNC Clients ebenfalls negativ ausfallen. optional Das Attribut optional besagt, dass dieses Paket installiert oder nicht installiert sein kann. Ist ein Paket in der Referenzliste auf den Status optional gesetzt, wird dieses Paket in die Sicherheitsüberprüfung nicht mit einbezogen. Die Referenzliste (in dieser prototypischen Realisierung security.ini benannt) wird mit in den Ordner (hier /opt/pcbin/pcpatch) auf dem Server hinterlegt, in dem die Seite 61

73 Kapitel 4 - Prototypische Realisierung Clients ihre Informationen über die installierten Softwarepakete eintragen. Nach jedem Hinzufügen eines Paketes für die Distributionssoftwareverteilung ist das Attribut des Paketes in der Referenzliste von Hand anzupassen. In Abbildung 4.8 ist ein Beispiel der Referenzliste aufgeführt: ; Hinweis: Diese Datei enthaelt alle Produkteintragungen, die auf einem Client ; installiert sein muessen, damit der Client sich über TNC ; einwählen und arbeiten darf. ; ; Syntax: on = Paket muss installiert sein ; off = Paket muss deinstalliert sein (wg. evtl. Sicherheitslücken) ; optional = Paket kann auf dem Client installiert sein, ; Paket ist aber nicht sicherheitstechnisch relevant ; [Products-installed] winxp_patches=on preloginloader=on vnc=on acroread=optional office2007=optional tnc=on win2k_sp4=off Abbildung 4.8: Beispiel Referenzliste für den TNC Erstellen von Paketen Die Erstellung von Paketen ist in dem Opsi Integrations Handbuch [URL:19] (Abschnitt 5.2) detailliert beschrieben. Diese Vorgehensweise ist für alle Pakete gleich. Der einzige Unterschied sind die Installationsdateien des Softwarepaketes in dem Ordner files und die selbst erstellten Installations- und Deinstallationsroutinen für den Interpreter Winst. Ausführliche Informationen über den Befehlssatz des Interpreters sind in dem Winst Handbuch [URL:21] beschrieben. Ein gutes Beispiel eines selbst erstellten Softwarepaketes ist das Programm RealVNC in der Version vom Dieses Programm erwartet bei der Installation Eingaben des Users, um die Installation und Konfiguration durchführen zu können. Damit eine Silent Installation inklusive Konfiguration des Programms durchgeführt werden kann, wird nachfolgend dargestellt, wie die benötigten zusätzlichen Dateien generiert werden können. Mit diesen Dateien kann eine neue Installationsroutine für den Interpreter Winst programmiert werden: 1. Ausführen der Installation von RealVNC Version mit einem zusätzlichem Parameter für das Erstellen einer Konfigurationsdatei auf dem Client Referenzsystem (es wird nur der VNC-Dienst installiert): Seite 62

74 Kapitel 4 - Prototypische Realisierung vnc-4_1_2-x86_win32.exe /SAVEINF="vnc.inf" 2. Nach der Installation von RealVNC sind die angegebenen Parameter in die Konfigurationsdatei vnc.inf geschrieben worden: [Setup] Lang=default Dir=C:\Programme\RealVNC\VNC4 Group=RealVNC NoIcons=0 Components=winvnc 3. Damit bei der Installation keine Icons auf dem Desktop oder im Startmenü hinterlegt werden, muss der Parameter NoIcons=0 in der Datei vnc.inf auf NoIcons=1 geändert werden. 4. Nach der Installation von VNC sind alle Konfigurationen wie Passwort, erlaubte Oberfläche, Ports, Freigabe der Ports in der Windows XP Firewall, etc. durchzuführen. Diese Konfiguration muss nun von Hand aus der Registry des Client Referenzsystems in eine Datei (z.b. insvnc.reg) exportiert werden. Die Schlüssel lauten: Nachfolgend ist der Inhalt der Datei insvnc.reg dargestellt: [HKEY_LOCAL_MACHINE\SOFTWARE\RealVNC] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\ DomainProfile\GloballyOpenPorts\List] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\ StandardProfile\GloballyOpenPorts\List] Seite 63

75 Kapitel 4 - Prototypische Realisierung Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\RealVNC] [HKEY_LOCAL_MACHINE\SOFTWARE\RealVNC\WinVNC4] "Password"=hex:b8,70,1a,1a,8d,1d,24,da "SecurityTypes"="VncAuth" "ReverseSecurityTypes"="None" "QueryConnect"=dword: "QueryOnlyIfLoggedOn"=dword: "PortNumber"=dword: c "IdleTimeout"=dword:00000e10 "HTTPPortNumber"=dword: "LocalHost"=dword: "Hosts"="+," "AcceptKeyEvents"=dword: "AcceptPointerEvents"=dword: "AcceptCutText"=dword: " SendCutText"=dword: "DisableLocalInputs"=dword: "DisconnectClients"=dword: "AlwaysShared"=dword: "NeverShared"=dword: "DisconnectAction"="None" "RemoveWallpaper"=dword: "RemovePattern"=dword: "DisableEffects"=dword: "UpdateMethod"=dword: "PollConsoleWindows"=dword: "UseCaptureBlt"=dword: "UseHooks"=dword: "Protocol3.3"=dword: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\ DomainProfile\GloballyOpenPorts\List] "5900:TCP"="5900:TCP:*:Enabled:VNC" [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\ StandardProfile\GloballyOpenPorts\List] "5900:TCP"="5900:TCP:*:Enabled:VNC" 5. Analog dazu nachfolgend die Datei delvnc.reg, die benötigt wird, falls das Produkt wieder deinstalliert werden soll: Windows Registry Editor Version 5.00 [-HKEY_LOCAL_MACHINE\SOFTWARE\RealVNC] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\ DomainProfile\GloballyOpenPorts\List] "5900:TCP"=- [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\ StandardProfile\GloballyOpenPorts\List] "5900:TCP"=- 6. Zu diesem Zeitpunkt sind alle benötigten Dateien für die Installation von RealVNC generiert worden. Nun fehlen nur noch das Installationsscript für Winst, welches die Silent Installation aufruft und danach automatisch die Registry-Einträge auf dem Client einträgt: Seite 64

76 Kapitel 4 - Prototypische Realisierung [Initial] Message=Installiere Fernwartung RealVNC Release ;Erstellt am von Axel Schmidt LogLevel=-2 ExitOnError=off ScriptErrorMessages=on TraceMode=off StayOnTop=true [Aktionen] DefVar $SCRIPTPATH$ Set $SCRIPTPATH$ = "%SCRIPTPATH%" DefVar $SETUP_FILE$ Set $SETUP_FILE$ = $SCRIPTPATH$ + "\files\vnc-4_1_2-x86_win32.exe" DefVar $INF_FILE$ Set $INF_FILE$ = $SCRIPTPATH$ + "\files\vnc.inf" DefVar $REG_FILE$ Set $REG_FILE$ = $SCRIPTPATH$ + "\files\insvnc.reg" DefVar $OS$ set $OS$=GetOS DefVar $MinorOS$ set $MinorOS$ = GetNTVersion if ( $OS$ = "Windows_NT" OR $OS$ = "Windows_95" ) if not (HasMinimumSpace ("%SYSTEMDRIVE%", "5 MB")) LogError "Nicht genünd Platz auf C:. 5 MB auf C: für RealVNC Release erforderlich." isfatalerror else WinBatch_vnc_installieren sub_check_exe dosbatch_regedit sub_check_reg endif endif [sub_check_exe] if Not ( FileExists ("c:\programme\realvnc\vnc4\winvnc4.exe")) LogError "VNC wurde nicht korrekt installiert." isfatalerror else Message "VNC wurde korrekt installiert." endif [sub_check_reg] DefVar $EXISTS_REG$ set $EXISTS_REG$ = GetRegistryStringValue ("[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List] 5900:TCP") if ( $EXISTS_REG$ = "5900:TCP:*:Enabled:VNC" ) Message "VNC wurde korrekt installiert." else Message "VNC wurde nicht korrekt installiert." isfatalerror endif [WinBatch_vnc_installieren] $SETUP_FILE$ /verysilent /loadinf="$inf_file$" /log [dosbatch_regedit] regedit /s "$REG_FILE$" Seite 65

77 Kapitel 4 - Prototypische Realisierung 7. Abschließend folgt das Deinstallationsscript: [Initial] Message=Deinstallation Fernwartung RealVNC Release ;Erstellt am von Axel Schmidt LogLevel=-2 ExitOnError=off ScriptErrorMessages=on TraceMode=off StayOnTop=true [Aktionen] DefVar $SCRIPTPATH$ Set $SCRIPTPATH$ = "%SCRIPTPATH%" DefVar $SETUP_FILE$ Set $SETUP_FILE$ = "c:\programme\realvnc\vnc4\unins000.exe" DefVar $REG_FILE$ Set $REG_FILE$ = $SCRIPTPATH$ + "\files\delvnc.reg" DefVar $OS$ set $OS$=GetOS DefVar $MinorOS$ set $MinorOS$ = GetNTVersion if ( $OS$ = "Windows_NT" OR $OS$ = "Windows_95" ) if not (HasMinimumSpace ("%SYSTEMDRIVE%", "5 MB")) LogError "Nicht genügend Platz auf C für die Deinstallation." isfatalerror else WinBatch_vnc_deinstallieren dosbatch_regedit sub_check endif endif [sub_check] DefVar $EXISTS_REG$ set $EXISTS_REG$ = GetRegistryStringValue ("[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List] 5900:TCP") if not ( $EXISTS_REG$ = "5900:TCP:*:Enabled:VNC" ) Message "VNC wurde korrekt deinstalliert." else Message "VNC wurde nicht korrekt deinstalliert." isfatalerror endif [WinBatch_vnc_deinstallieren] $SETUP_FILE$ /verysilent [dosbatch_regedit] regedit /s "$REG_FILE$" Seite 66

78 Kapitel 4 - Prototypische Realisierung Die Installations- und Deinstallationsscripte der Pakete ähneln einander sehr, da für gleiche Methoden der Installation auch meistens die gleichen Scripte genutzt werden können. Zu beachten ist, dass jede Teilinstallation in dem Winst-Script zu überprüfen ist und bei Fehler sofort das Script abgebrochen wird, da nach einem erfolgreichen Abarbeiten des Scriptes automatisch das Softwarepaket als installiert gekennzeichnet ist. Im Anhang A sind die Installationsscripte für die folgenden erstellten Pakete für die opsi Softwareverteilung aufgeführt: Windows XP Professional Patches (Stand: ) Windows 2000 Service Pack 4 Adobe Acrobat Reader Version Microsoft Office Professonal 2007 (Evaluierung) RealVNC Version Trusted Network Connect Seite 67

79 Kapitel 4 - Prototypische Realisierung 4.7 Implementierung Trusted Network Connect (TNC) In diesem Kapitel ist die prototypische Realisierung des Trusted Network Connects mit den einzelnen Komponenten dargestellt TNC-Komponenten Die server-seitigen TNC-Komponenten sind die Module PEP und PDP (siehe Abbildung 4.9), die auf dem Mobile Security Gateway hinterlegt sind, die client-seitige TNC-Komponente ist der AR. Dieses Modell entspricht dem TNC-Modell der TCG, wobei der PEP und PDP nicht im Netzwerk verteilt sind, sondern zusammen auf dem Mobile Security Gateway implementiert sind. Abbildung 4.9: TNC-Architektur des Prototyps PEP Der PEP ist in diesem Prototyp durch folgende Komponenten realisiert: Firewall Die Firewall wird durch das Paket iptables in Zusammenarbeit mit selbst erstellten Scripten für die Zugriffsberechtigung realisiert. VPN-Gateway Das VPN-Gateway besteht aus mehreren Untermodulen: Seite 68

80 Kapitel 4 - Prototypische Realisierung Openswan Openswan ist die IPSec-Implementierung, damit die Einwahl über IPSec realisiert werden kann. l2tpd L2TPD ermöglicht das Layer 2 Tunnel Protokoll für die Einwahl. ppp PPP wird für die Übertragung (Microsoft VPN-Stack) benötigt. radiusclient1 Der RADIUS-Client stellt die Anfrage an den PDP, um die Netzwerkzugriffe der Clients in geeigneter Weise zu beschränken. PDP Der PDP ist durch folgende Komponenten realisiert: Network Access Authority (NAA) Diese Komponente wird durch das Modul AAA realisiert. TNC Server (TNCS) Der TNC Server stellt in Kombination mit der Firewall die entsprechenden Zugriffsrechte für den Trusted Network Connect her, zusätzlich reicht er die Integrity Measurements an den TNC Client weiter. Integrity Measurements (IM) Die Integrity Measurements sind auf dem Mobile Security Gateway Referenzlisten, in der alle Informationen über den Soll- und Ist-Zustand der anfragenden Clients gespeichert sind. AR Der AR ist durch die folgenden Module realisiert: TNC Client/Integrity Measurements Verifier Der TNC Client/Integrity Measurements Verifier ermöglicht die Überprüfung und einen Integritätstest auf dem Client. Network Access Requestor Der Network Access Requestor wird durch zwei VPN-Verbindungen auf dem AR abgebildet. Seite 69

81 Kapitel 4 - Prototypische Realisierung Interfaces Die in diesem Prototyp benutzten Schnittstellen sind die gleichen, wie in der TNC- Architektur der TCG beschrieben wurde. Der einzige relevante Unterschied zu der TNC-Architektur ist der Wegfall der Komponente IMC und damit verbunden die Schnittstellen IF-M und IF-IMC sowie die funktionale Änderung der Schnittstelle IMV in Integrity Measurements (IM). Diese Umbenennung ist sinnvoll, da keine IMVs in diesem Prototyp genutzt werden, sondern nur IMs für den Integritätstest (TNC Client) zur Verfügung gestellt werden. Die Aufgabe der Komponente IMC ist in den eigens für dieses Projekt erstellten Prototyp (TNC Client) integriert worden Workflow prototypische TNC-Realisierung Nachfolgend ist das Zusammenwirken der einzelnen Komponenten des Trusted Network Connects detailliert (siehe Abbildung 4.10) dargestellt: Punkt 0: Voraussetzung für die Initiierung des Trusted Network Connects ist das Vorhandensein des TNC Clients sowie die Konfiguration der beiden VPN- Verbindungen des AR. Der Verbindungsaufbau wird dann durch das Starten des TNC Clients initiiert. Punkt 1: Ist ein Verbindungsaufbau durch den TNC Client initiiert worden, baut der Network Access Requestor auf dem Access Requestor die Verbindung auf. Punkt 2: Bei einem Verbindungsaufbau des Network Access Requestors sendet der Policy Enforcement Point eine Aufforderung zur Authentisierung an den NAR. Eine Überprüfung der Authentisierung findet dann zwischen dem AR und dem NAA statt. Punkt 3: Bei einer erfolgreichen Authentisierung informiert der NAA den TNC Server über den Versuch des Verbindungsaufbaus. Punkt 4: Anhand der Authentisierung des ARs beschränkt der NAA die Zugriffsrechte des ARs über den PEP, das heißt Zugriffe des ARs werden automatisch nur auf die Quarantänezone beschränkt. Seite 70

82 Kapitel 4 - Prototypische Realisierung Punkt 5A: Der TNCC initiiert die Prozedur Softwareupdate, um den AR auf den aktuellen Software- und Patchlevel-Stand zu bringen. Der Austausch der Informationen wird durch den NAR, PEP und NAA geleitet. Punkt 5B: Der TNCS holt alle benötigten Informationen für die Softwareupdates von den IMs. Punkt 6A: Der TNCC initiiert führt jetzt den Integritätstest des ARs durch. Der Austausch der Informationen wird ebenfalls durch den NAR, PEP und NAA geleitet. Punkt 6B: Der TNCS holt alle benötigten Informationen für den Integritätstest von den IMs. Punkt 7: Nach erfolgreichem Integritätstest wird die bestehende VPN-Verbindung des NAR beendet und eine neue VPN-Verbindung für die normale Einwahl des AR über den NAR gestartet. Der Zugriff der zweiten Verbindung wird durch den NAA autorisiert und nicht weiter beschränkt. Scheitert der Integritätstest, wird keine zweite VPN-Verbindung gestartet; somit kann sich der AR nicht einwählen. Die Idee dieses Konzeptes ist, dass nach jedem positiven Ergebnis der Sicherheitsüberprüfung sofort die Einwahl des Mitarbeiters gestartet werden kann. Nach Trennen der normalen Verbindung und erneuter Einwahl durch den TNC Client, beginnt automatisch die Prozedur wieder ab Punkt 0, da zwischen Trennen und erneutem Herstellen der Verbindung wieder sicherheitsrelevante Patches auf dem TNC-Server zur Verfügung stehen könnten. Seite 71

83 Kapitel 4 - Prototypische Realisierung Abbildung 4.10: Workflow prototypische TNC-Realisierung Prototyp TNC Client Der Trusted Network Connect wird über ein eigens programmierten Software-Client (Prototyp) realisiert. Dieser Prototyp wurde mit der Script-Sprache AutoIT in der Version geschrieben. Diese Script-Sprache ist der Programmiersprache Visual Basic sehr ähnlich und damit gegebenenfalls auch auf andere Systeme (Programmiersprachen) sehr einfach zu portieren. Dieses Script benötigt für den Ablauf zwei VPN-Profile (Profil 1: Softwareverteilung, Profil 2: Unternehmen), die auf dem Client mit Administrationsrechten hinterlegt sein müssen (Installationsanleitung siehe Anhang A). Die Hinterlegung mit Administrationsrechten ist sehr wichtig, damit der Benutzer nicht die Möglichkeit hat, die VPN-Einwahl manuell zu starten. In dem Source Code (siehe Anhang A) des Programms sind Variablen hinterlegt, um Passwörter und Benutzernamen für die Administrationsrechte des Clients zu hinterlegen. Diese Passwörter und Benutzernamen werden mit dem Kompilieren des Source Codes verschleiert und verschlüsselt. Funktionen des Programms Das Programm ist modular aufgebaut wobei jedes Modul einer Funktion in dem Programm entspricht und somit auch für zusätzliche Zwecke einfach erweiterbar ist. Nachfolgend sind die Funktionen aufgelistet: Seite 72

84 Kapitel 4 - Prototypische Realisierung Func initialisierung () Diese Funktion setzt den Registrierungs-Schlüssel mit Start des Programms zurück, das heißt der Status des Integritätstests ist false (nicht bestanden). Func vpn softwareverteilung start () Diese Funktion startet die automatische VPN-Einwahl mit dem User pcpatch. Dieser spezielle Username ist notwendig, damit der RADIUS-Server und die Firewall die entsprechenden Zugriffsrechte setzen können. Func softwareversorgung () Diese Funktion wird automatisch nach der Einwahl gestartet, damit relevante Patches und Sicherheitsupdates automatisch installiert werden. Func security ueberpruefung () Diese Funktion ist die Hauptfunktion des TNC Clients. Diese Funktion führt den Integritätstest des Clients anhand einer Referenzliste durch. Die Referenzliste wird mit der Liste der installierten Softwarepakete auf dem Client verglichen und das Ergebnis in die Registry des Clients geschrieben. Das Ergebnis wird in die Registry geschrieben, um Manipulationen zu verhindern. Hier ist das Einbinden weitere Funktionen, die andere Aspekte der Sicherheitsüberprüfung (z.b. MAC-Adresse der Netzwerkkarte oder Hardwareausstattung) berücksichtigen, möglich. Func vpn softwareverteilung stop () Diese Funktion beendet die automatische Einwahl mit dem User pcpatch. Func vpn unternehmen start () Diese Funktion startet eine erneute VPN-Einwahl, damit der User sich in das Unternehmensnetz einwählen kann. Zugriffsrechte werden hier nicht mehr beschränkt, da die Einwahl nur nach erfolgreichem Integritätstest gestartet wird. Die einzige mögliche Beschränkung des Zugriffs kann noch von der Benutzerverwaltung (PDC) kommen. Diese Beschränkungen beziehen sich dann allerdings nur noch auf das lokale Netz des Unternehmens (Domänen- Sicherheitsrichtlinien). Seite 73

85 Kapitel 4 - Prototypische Realisierung Ablauf des Programms Der mobile Mitarbeiter startet diesen Software-Client, um sich in das Unternehmen ein zu wählen. In diesem Client sind alle notwendigen Parameter für den TNC hinterlegt und der mobile Mitarbeiter bekommt erst die Möglichkeit sich anzumelden, wenn die Sicherheitsüberprüfung erfolgreich abgeschlossen wurde (siehe Abbildung 4.11). Nachfolgend ist der globale Ablauf des TNC dargestellt: 1. Der Benutzer startet die TNC Client-Software. Bei Start der Software wird die Tastatur und Maus des Clients gesperrt sowie eine Meldung an den mobilen Mitarbeiter ausgegeben: Das System wird überprüft. 2. VPN-Aufbau mit User: pcpatch Dieser Verbindungsaufbau wird benötigt, damit die Überprüfung des Systems durchgeführt werden kann: Starten der Softwareverteilung, um alle Patches und Signaturen des Virenscanners zu aktualisieren. Überprüfung, ob alle notwendigen Pakete und Patches installiert wurden. Die Überprüfung findet mit Hilfe einer Referenzliste statt, die auf dem Software-Server hinterlegt ist. Verglichen wird dabei die Referenzliste mit der Software-Liste des Clients (hier sind alle installierten Programme aufgelistet), die ebenfalls auf dem Software-Server hinterlegt ist. Speichern des Ergebnisses als Registry-Eintrag auf dem Client. 3. Tastatur und Maus wieder freigeben. 4. Bei negativem Ergebnis: Fehlermeldung und Fehlercode ausgeben. 5. Bei positivem Ergebnis: Meldung an Benutzer und normale VPN-Einwahl starten. Der Benutzer kann sich direkt an die Domäne anmelden, um das Profil von dem PDC zu laden. Der Benutzer bleibt lokal angemeldet und baut die VPN-Verbindung normal auf und arbeitet so in dem Netz des Unternehmens. Seite 74

86 Kapitel 4 - Prototypische Realisierung Abbildung 4.11: Ablauf Trusted Network Connect Fehler-Codes / LOG-Dateien Der TNC Client protokolliert den Ablauf der Sicherheitsüberprüfung auf dem TNC Server in LOG-Dateien. Diese LOG-Dateien (siehe Beispiele Auszug 4.12 und Seite 75

87 Kapitel 4 - Prototypische Realisierung Auszug 4.13) geben dem Systemadministrator die Möglichkeit einer Fehleranalyse; zusätzlich werden Fehler-Codes des TNC Clients sichtbar für den Benutzer ausgegeben. Die Fehler-Codes sind in Tabelle 4.1 hinterlegt :19:47 : P:\pcpatch\CLIENT-3.ini erfolgreich ausgelesen :19:47 : P:\pcpatch\security.ini erfolgreich ausgelesen :19:47 : Teste Produkt: acroread - Status: OK (soll=optional, ist=on) :19:47 : Teste Produkt: office Status: OK (soll=optional, ist=off) :19:47 : Teste Produkt: preloginloader - Status: OK (soll=on, ist=on) :19:47 : Teste Produkt: tnc - Status: OK (soll=on, ist=on) :19:47 : Teste Produkt: vnc - Status: OK (soll=on, ist=on) :19:47 : Teste Produkt: win2k_sp4 - Status: OK (soll=off, ist=off) :19:47 : Teste Produkt: winxp_patches - Status: OK (soll=on, ist=on) :19:47 : Setze Registry Wert: HKLM\Software\opsi.org\security\berechtigung = 1 Abbildung 4.12: Beispiel Log-Datei (Integritätstest bestanden) :26:26 : P:\pcpatch\CLIENT-1.ini erfolgreich ausgelesen :26:26 : P:\pcpatch\security.ini erfolgreich ausgelesen :26:26 : Teste Produkt: acroread - Status: OK (soll=optional, ist=on) :26:26 : Teste Produkt: office Status: OK (soll=optional, ist=on) :26:26 : Teste Produkt: preloginloader - Status: OK (soll=on, ist=on) :26:26 : Teste Produkt: tnc - Status: OK (soll=on, ist=on) :26:26 : Teste Produkt: vnc - Status: OK (soll=on, ist=on) :26:26 : Teste Produkt: win2k_sp4 - Status: OK (soll=off, ist=off) :26:26 : Teste Produkt: winxp_patches - Status: nicht OK (soll=on, ist=off) :26:26 : Setze Registry Wert: HKLM\Software\opsi.org\security\berechtigung = 0 Abbildung 4.13: Beispiel Log-Datei (Integritätstest nicht bestanden) Code 0x01 0x02 0x03 0x04 Tabelle 4.1: Fehler-Codes TNC Client Fehler Log-Datei konnte nicht geöffnet werden PCNAME.ini konnte nicht geöffnet werden security.ini konnte nicht gelesen werden ungleiche Anzahl Zeilen von PCNAME.ini und security.ini Seite 76

88 Kapitel 4 - Prototypische Realisierung 4.8 Implementierung Clients Notebooks Die Notebooks der mobilen Mitarbeiter eines Unternehmens werden für die interne sowie externe Kommunikation erweitert: Kommunikation intern: Für die interne Kommunikation wird auf den Clients lediglich der winst-client für die Softwareversorgung benötigt. Die Installation dieses Clients wird remote erledigt. Der Administrator verbindet sich mit dem freigegebenen Laufwerk auf dem Mobile Security Server und installiert von dort aus die benötigte Client-Software (Installationsanleitung siehe Anhang A). Kommunikation extern: Für die externe Kommunikation der Mitarbeiter werden zusätzlich zu dem winst-client zwei VPN-Verbindungen benötigt, die von dem Administrator in dem Client-Profil Administrator angelegt werden müssen. Die Konfiguration dieser beiden Verbindungen erfolgt manuell (Installationsanleitung siehe Anhang A). Zusätzlich muss der TNC Client auf dem Notebook des mobilen Mitarbeiters installiert werden. Diese Installation kann automatisch mit der Softwareverteilung durchgeführt werden. Entzug der Administrationsrechte der mobilen Mitarbeiter: Für das Konzept des Trusted Network Connects (TNC) ist es notwendig, den mobilen Mitarbeitern die Administrationsrechte (falls vorhanden) zu entziehen. Der Mitarbeiter soll und darf keine zusätzlichen Softwarepakete installieren oder löschen. Das Installieren oder Deinstallieren der Notebooks mit zusätzlicher Software erfolgt ab diesem Zeitpunkt nur noch über die automatische Softwareverteilung. Einstellungen Netzwerkkarten: Da dem mobilem Benutzer die Administrationsrechte entzogen werden, sollten die Netzwerkkarten auf DHCP eingestellt werden, damit der Mitarbeiter automatisch eine IP-Adresse (intern und extern) bekommt. Bei Bedarf ist eine komplette Neuinstallation eines Clients mit Hilfe der Softwareverteilung möglich: PXE-Boot: Bietet der Client die Möglichkeit, den PC über Netzwerk zu starten, kann ein Seite 77

89 Kapitel 4 - Prototypische Realisierung minimales Image über das Netzwerk geladen werden und damit die Neuinstallation des Clients gestartet werden. Boot-CD: Ist der Client nicht in der Lage, über das Netzwerk zu starten, kann er über eine Boot-CD gestartet werden und darüber die Neuinstallation des Clients angestoßen werden. Bei der Neuinstallation des Clients wird automatisch das Betriebssystem (Windows XP oder Windows 2000) mit allen notwendigen Treibern, dem Profil Administrator sowie dem winst-client des Clients installiert. Nach dem Neustart des Clients wird die Softwareverteilung automatisch gestartet, um weitere Programme, wie z.b. Service Packs, Remoteverwaltung, TNC, Virenscanner und andere benötigte Programme zu installieren. Nach der Komplettinstallation ist nur noch das Anlegen der beiden VPN- Verbindungen notwendig; dies kann aber über die Remoteadministrierung erledigt werden. Verschlüsselung von Daten Für die Verschlüsselung der Daten auf den Notebooks wurden die beiden Programme TrueCrypt und FreeOTFE getestet: TrueCrypt Version 4.2a vom 3. Juli 2006 (URL [URL:28]) Dieses Programm wurde von der TrueCrypt Foundation entwickelt. Das Programm stellt Container für eine virtuelle Laufwerksverschlüsselung zur Verfügung und unterstützt alle gängigen Verschlüsselungsarten. Das Programm bereitete jedoch unter Microsoft Windows XP einige Probleme beim Unmounten der virtuellen Laufwerke, das heißt das Laufwerk ließ sich nicht unmounten, deswegen wurde noch zusätzlich das Programm FreeOTFE getestet. FreeOTFE Version 2.00 vom 18. März 2007 (URL [URL:05]) Dieses Programm stellt ebenfalls verschlüsselte Container für virtuelle Laufwerke zur Verfügung. Die Container sind zu der PDA-Version kompatibel. Im Betrieb traten keine Probleme im Gegensatz zu TrueCrypt auf. Fernadministrierung Die Fernadministrierung wurde mit dem Programm RealVNC in der Version vom (Quelle [URL:22]) getestet. Die Installation und Konfiguration Seite 78

90 Kapitel 4 - Prototypische Realisierung des benötigten Clients wurde mit Hilfe der Softwareverteilung durchgeführt. Das Programm gibt es in drei Versionen (Lizenzen), wobei nur die Free Edition kostenfrei ist: Free Edition Personal Edition Enterprise Edition Die Unterschiede sind in der Abbildung 4.14 (Quelle [URL:22]) zu sehen. Die Free Edition unterstützt einen Viewer und einen Server. Diese Kombination reicht völlig aus, um Notebooks remote zu administrieren. Eine mögliche Verschlüsselung der Verbindung durch diese Programme ist nicht notwendig, da die Remote-Administrierung nur über die VPN-Einwahl der Notebooks oder über das lokale LAN erfolgt. Für zusätzliche Features, wie z.b. Verschlüsselung oder einen File Transfer, wird eine Lizenz benötigt. Abbildung 4.14: Übersicht VNC Versionen PDA/MDA/iPAQ Verschlüsselung von Daten Zur Verschlüsselung von Daten wurde das Programm FreeOTFE4PDA in der Version 2.00 vom 18. März 2007 getestet. Dieses Programm verrichtete ohne Auffälligkeiten die Verschlüsselung von Daten mit Hilfe von Containern, jedoch sollten alle überflüssigen Library-Dateien für nicht genutzte Verschlüsselungsalgorithmen vor dem Programmstart gelöscht werden, da der Start des Programms sonst zur Geduldsprobe wird. Seite 79