Diplomarbeit - Weblearn

Transcrição

Hochschule Bremen
Fachbereich Elektrotechnik und Informatik
Hochmobiler Mitarbeiter
Entwicklung einer dedizierten Infrastruktur
für die mobile Kommunikation
Diplomarbeit
eingereicht durch:
Axel Schmidt
Matrikelnr.: 94416
und
Andreas Haase
Matrikelnr.: 32425
Prüfer:
Prof. Dr. Richard Sethmann
Zweitprüfer:
Prof. Dr. Axel Viereck
Abgabetermin: 16. April 2007
Eidesstattliche Erklärung
Ich, Axel Schmidt, erkläre an Eides statt, dass ich die vorliegende Diplomarbeit
selbstständig und ohne unzulässige fremde Hilfe verfasst, andere als die angegebenen
Quellen nicht benutzt und die aus den benutzten Quellen wörtlich oder inhaltlich
entnommenen Stellen als solche kenntlich gemacht habe.
Datum / Unterschrift
Seite I
Eidesstattliche Erklärung
Ich, Andreas Haase, erkläre an Eides statt, dass ich die vorliegende Diplomarbeit
selbstständig und ohne unzulässige fremde Hilfe verfasst, andere als die angegebenen
Quellen nicht benutzt und die aus den benutzten Quellen wörtlich oder inhaltlich
entnommenen Stellen als solche kenntlich gemacht habe.
Datum / Unterschrift
Seite II
Danksagung
An dieser Stelle danken wir all jenen für ihre persönliche und fachliche Unterstützung, welche zum Gelingen dieser Diplomarbeit beigetragen haben. Besonderer Dank
gilt unseren Familien und Freunden, die uns nicht nur während der Diplomarbeit,
sondern während des gesamten Studiums unterstützt haben.
Weiterhin bedanken wir uns bei Herrn Prof. Dr. Richard Sethmann für die Betreuung
unserer Diplomarbeit, für die Ratschlä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
erklärt hat, die Rolle des Zweitprüfers zu übernehmen.
Seite III
Abstract
Mobile Mitarbeiter eines Unternehmens müssen die Möglichkeit erhalten auf Daten
eines Unternehmens remote zugreifen zu können. Um den Zugriff abzusichern, existieren teure Lösungen, die sich ein kleines oder mittelständisches Unternehmen nicht
leisten können. Ziel dieser Diplomarbeit ist die Entwicklung einer auf Standards basierten Sicherheitsplattform für kleine und mittelstä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 -herstellerunabhä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 lässt, jedoch besteht in manchen Bereichen noch
Bedarf zur weiteren Entwicklung, bevor diese Lösung ein kommerzielles Produkt
komplett ersetzen oder ablösen kann.
Seite IV
Inhaltsverzeichnis
1 Einleitung
1
1.1
Problemfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Aufgabenbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2 Einführung Grundlagen
2.1
4
VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.1
Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.2
Typische VPN-Realisierung für mobile Mitarbeiter . . . . . .
5
2.1.3
Authentisierung . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.4
Internet Protocol Security (IPSec) . . . . . . . . . . . . . . . .
7
2.1.5
Layer 2 Tunneling Protocol (L2TP) over IPSec
9
. . . . . . . .
2.2
Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3
Authentisierung, Autorisierung und Accounting (AAA) . . . . . . . . 13
2.4
2.5
2.6
2.3.1
Authentisierung . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2
Autorsisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.3
Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.4
AAA-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.5
RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Trusted Network Connect . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.1
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.2
Einheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.3
Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.4
Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.5
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.6
Workflow TNC . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.7
Cisco Network Admission Control . . . . . . . . . . . . . . . . 25
Verschlüsselung von Daten . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5.1
Verschlüsselung einzelner Dateien . . . . . . . . . . . . . . . . 27
2.5.2
Verschlüsselung mit virtuellen Laufwerken (Containern) . . . . 28
2.5.3
Verschlüsselung des gesamten Mediums . . . . . . . . . . . . . 29
Fernadministrierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Seite V
2.7
Distributionssoftwareverteilung . . . . . . . . . . . . . . . . . . . . . 30
2.7.1
Client Referenzsystem . . . . . . . . . . . . . . . . . . . . . . 31
2.7.2
Unattended / Silent Setup . . . . . . . . . . . . . . . . . . . . 32
2.7.3
Administrative Installation . . . . . . . . . . . . . . . . . . . . 32
2.7.4
Interaktives Setup mit automatischen Antworten . . . . . . . 33
2.7.5
Neu-Paketierung . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 Entwicklung des Systemkonzeptes
34
3.1
Systemübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2
Mobile Endgeräte (Clients) . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3
3.2.1
PDA/MDA/iPAQ . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.2
Remote Notebooks . . . . . . . . . . . . . . . . . . . . . . . . 36
Mobile Security Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.1
VPN-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.2
Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.3
Authentisierung, Autorisierung und Accounting (AAA) . . . . 39
3.3.4
Trusted Network Connect (TNC) . . . . . . . . . . . . . . . . 39
3.3.5
Distributionssoftwareverteilung . . . . . . . . . . . . . . . . . 42
4 Prototypische Realisierung
44
4.1
Voraussetzungen im Unternehmensnetz . . . . . . . . . . . . . . . . . 44
4.2
Systemarchitektur des Prototypen . . . . . . . . . . . . . . . . . . . . 45
4.3
4.4
4.5
4.6
4.2.1
Hardware Umgebung . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.2
Software Umgebung
. . . . . . . . . . . . . . . . . . . . . . . 46
Implementierung VPN-Server . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1
openswan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.2
l2tpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.3
ppp und radiusclient1 . . . . . . . . . . . . . . . . . . . . . . . 49
Implementierung Firewall . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4.1
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4.2
Quarantänezone . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4.3
Statische Filterregeln . . . . . . . . . . . . . . . . . . . . . . . 52
4.4.4
Dynamische Filterregeln . . . . . . . . . . . . . . . . . . . . . 53
Implementierung AAA . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5.1
Authentisierung . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5.2
Autorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.5.3
Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Implementierung Distributionssoftwareverteilung . . . . . . . . . . . . 60
Seite VI
4.7
4.8
4.6.1
Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.6.2
Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.6.3
Erweiterung für den TNC . . . . . . . . . . . . . . . . . . . . 61
4.6.4
Erstellen von Paketen
Implementierung Trusted Network Connect (TNC) . . . . . . . . . . 68
4.7.1
TNC-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . 68
4.7.2
Workflow prototypische TNC-Realisierung . . . . . . . . . . . 70
4.7.3
Prototyp TNC Client . . . . . . . . . . . . . . . . . . . . . . . 72
Implementierung Clients . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.8.1
Notebooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.8.2
PDA/MDA/iPAQ . . . . . . . . . . . . . . . . . . . . . . . . . 79
5 Diskussion
5.1
. . . . . . . . . . . . . . . . . . . . . . 62
81
VPN-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.1.1
OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.1.2
IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.1.3
IPSec und NAT-T . . . . . . . . . . . . . . . . . . . . . . . . 83
5.1.4
Problembehandlung . . . . . . . . . . . . . . . . . . . . . . . . 83
5.2
Firewall und AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.3
Distributionssoftwareverteilung . . . . . . . . . . . . . . . . . . . . . 85
5.4
Trusted Network Connect . . . . . . . . . . . . . . . . . . . . . . . . 87
5.5
Verschlüsselung und Zerstörung von Daten . . . . . . . . . . . . . . . 90
6 Fazit / Ausblick
92
Literaturverzeichnis
94
Glossar
100
A Anhang
104
Seite VII
Abbildungsverzeichnis
2.1
Sicherung eines IP-Paketes mit ESP im Tunnel Mode . . . . . . . . .
8
2.2
Sicherung eines IP-Paketes mit ESP im Transport Mode . . . . . . .
8
2.3
IPSec/L2TP/PPP im ISO/OSI-Schichtenmodell . . . . . . . . . . . . 10
2.4
Stateful Packet Inspection (SPI) . . . . . . . . . . . . . . . . . . . . . 12
2.5
Authentisierung mit Kerberos . . . . . . . . . . . . . . . . . . . . . . 15
2.6
AAA-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.7
Ablauf einer RADIUS-Sitzung . . . . . . . . . . . . . . . . . . . . . . 18
2.8
TNC-Übersicht (Trusted Computing Group) . . . . . . . . . . . . . . 20
2.9
Workflow der TNC-Architektur . . . . . . . . . . . . . . . . . . . . . 25
2.10 Workflow Cisco NAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.11 Einfache Dateiverschlüsselung . . . . . . . . . . . . . . . . . . . . . . 28
2.12 Virtuelle Dateiverschlüsselung (Container) . . . . . . . . . . . . . . . 29
2.13 Vollstaendige Laufwerksverschlüsselung . . . . . . . . . . . . . . . . . 30
3.1
Konzeptionelle Gesamtansicht . . . . . . . . . . . . . . . . . . . . . . 35
3.2
Übersicht Remote-Zugriff
3.3
Modul Trusted Network Connect . . . . . . . . . . . . . . . . . . . . 41
3.4
Client-Softwareverteilung . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.5
Client-Betriebssysteminstallation über PXE-Boot . . . . . . . . . . . 43
3.6
Client-Betriebssysteminstallation über Boot-CD . . . . . . . . . . . . 43
4.1
Übersicht Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . 46
4.2
Realisierung des IPSec-L2TP-PPP Protokollstacks unter Linux . . . . 48
4.3
Scriptablauf dynamische Filterregeln . . . . . . . . . . . . . . . . . . 54
4.4
Beispiel einer Access-Request-Nachricht . . . . . . . . . . . . . . . . . 57
4.5
Beispiel einer Access-Accept-Nachricht . . . . . . . . . . . . . . . . . 57
4.6
Beispiel einer Accounting-Start-Nachricht . . . . . . . . . . . . . . . . 58
4.7
Beispiel einer Accounting-Stop-Nachricht . . . . . . . . . . . . . . . . 58
4.8
Beispiel Referenzliste für den TNC . . . . . . . . . . . . . . . . . . . 62
4.9
TNC-Architektur des Prototyps . . . . . . . . . . . . . . . . . . . . . 68
. . . . . . . . . . . . . . . . . . . . . . . . 38
4.10 Workflow prototypische TNC-Realisierung . . . . . . . . . . . . . . . 72
Seite VIII
4.11 Ablauf Trusted Network Connect . . . . . . . . . . . . . . . . . . . . 75
4.12 Beispiel Log-Datei (Integritätstest bestanden) . . . . . . . . . . . . . 76
4.13 Beispiel Log-Datei (Integritätstest nicht bestanden) . . . . . . . . . . 76
4.14 Übersicht VNC Versionen . . . . . . . . . . . . . . . . . . . . . . . . 79
Seite IX
Tabellenverzeichnis
2.1
IPSec ohne NAT-T . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2
IPSec mit Berücksichtigung von NAT-T . . . . . . . . . . . . . . . .
9
4.1
Fehler-Codes TNC Client . . . . . . . . . . . . . . . . . . . . . . . . . 76
Seite X
Kapitel 1 - Einleitung
1 Einleitung
1.1 Problemfeld
Mitarbeiter mit Tätigkeitsbereich im Außendienst sind heutzutage auf mobile Kommunikation angewiesen. Eine häufige Anforderung ist zum Beispiel der Zugriff auf
einen zentralen Datenbestand im Unternehmen, den der Mitarbeiter im Rahmen
seiner Tätigkeit benötigt. Aus Sicht des Mitarbeiters ist ein möglichst transparenter
Datenzugriff wünschenswert.
Es müssen auf Seiten des Unternehmens und des Außendienstmitarbeiters technische
Voraussetzungen geschaffen werden, die dem Außendienstmitarbeiter den Zugriff auf
Ressourcen innerhalb des Firmennetzwerkes ermöglichen. Das Unternehmen hat jedoch ein berechtigtes Interesse daran, den Zugriff auf Ressourcen vor unbefugtem
Zugang und deren Nutzung durch Dritte zu schützen. Dies betrifft sowohl lokale als
auch nicht lokale Ressourcen.
Namhafte Hersteller bieten Lösungen an, womit der Mitarbeiter in der Lage ist, seine
Innendiensttätigkeit auch im Außendienst zu leisten, indem er sich per VPN-Lösung
in das Unternehmen einwählt und so auf das Unternehmensnetz zugreift. Diese Konzepte sind sehr teuer und ein kleines oder mittelständisches Unternehmen ist häufig
nicht in der Lage, diese Lösungen zu finanzieren. Daher wird die oben genannte dedizierte Infrastruktur entweder gar nicht oder nur zum Teil, mit Einschränkungen
bezüglich Funktionalität und Sicherheit, umgesetzt.
Die zunehmende Verbreitung von frei erhältlicher Software könnte in Zukunft dazu
beitragen, diese Bedarfslücke zu schließen.
Diese Diplomarbeit untersucht die Möglichkeiten, inwiefern solche kommerziellen
Lösungen mit herkömmlicher Open Source Software nachgebildet werden können
und inwiefern eine Lösung überhaupt realisierbar ist.
Seite 1
1.2 Aufgabenbeschreibung
Alle Aufgaben beziehen sich auf mobile Endgeräte wie zum Beispiel PDAs, SmartPhones und Notebooks. Die Aufgaben wurden zu Beginn der Arbeit unter beiden
Diplomanden aufgeteilt. Eine strikte Trennung der Aufgaben ist jedoch nicht
mö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“ möglich?
”
• Wie ist eine zentrale Fernadministrierung von Endgeräten möglich?
• Wie ist eine zentrale Distributionssoftwareverteilung möglich?
• Wie ist eine Verschlüsselung und Zerstörung der Daten oder ein Sperren des
Zugriffs auf abhanden gekommene Endgeräte mö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 Möglichkeiten der Realisierung von Sicherheitsrichtlinien für den Benutzer gibt es?
• Welche Möglichkeiten der Benutzerverwaltung (zum Beispiel ü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
1.3 Übersicht
Die Diplomarbeit ist in sechs Hauptteile gegliedert:
1. Einfü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 Ausprägung des Systemkonzeptes implementiert und erläutert.
4. Diskussion:
In der Diskussion wird auf die aufgetauchten Probleme und auf die prototypische Realisierung eingegangen. Außerdem werden mögliche Lösungsansätze
diskutiert.
5. Fazit/Ausblick:
Hier wird der Stand der Realisierung zusammenfassend dargestellt. Außerdem
erfolgt ansatzweise ein Ausblick auf noch ungelöste Probleme und unbehandelte
Fragestellungen.
6. Anhang:
Der Anhang enthält Installationsanleitungen, Konfigurationsdateien und
Quelltexte auf die im Verlauf der Arbeit Bezug genommen werden.
Seite 3
Kapitel 2 - Einführung Grundlagen
2 Einführung Grundlagen
2.1 VPN
2.1.1 Allgemein
Ein mobiler Mitarbeiter benötigt an seinem Standort zum Beispiel einen Fernzugriff
auf Daten, welche sich nicht auf den mobilen Endgeräten, sondern auf einem
Server innerhalb des Unternehmens befinden. Ein solcher Fernzugriff lässt sich
grundsätzlich auf zwei Arten bewerkstelligen →[URL:01]:
• Herstellen einer dedizierten Wählverbindung über das herkömmliche Telefonnetz, auch als direkte Einwahl bezeichnet. Abhängig von Standort und Telefonanbieter des mobilen Mitarbeiters fallen für die direkte Einwahl mehr oder
weniger hohe Kosten an.
• Herstellen einer Verbindung über verfügbare IP-Netzwerke, wie dem Internet.
Aus Kostengründen gewinnt diese Variante zunehmend an Bedeutung. Hier
ist zu beachten, dass unter Umständen sensible Daten über ein unsicheres
Netzwerk übertragen werden. Der Kommunikationskanal, über den die Daten
transportiert werden sollen, ist deshalb mit geeigneten Methoden abzusichern.
In dieser Diplomarbeit wird lediglich die zweite Variante berücksichtigt. Die
Absicherung des Kommunikationskanals geschieht in der Praxis durch den Einsatz
von Virtual Private Networks (→VPN’s). →[AHLE01]
In Bezug auf die zu schützenden Daten sind drei grundsätzliche Anforderungen an
ein VPN zu nennen:
1. Vertraulichkeit:
Ein Abhören auf dem Kommunikationskanal ist nicht zu verhindern. Durch
den Einsatz leistungsfähiger Verschlüsselung wird die Vertraulichkeit sicher
gestellt, weil Unbefugte dann lediglich verschlüsselte Daten sehen. Der Sender
verschlüsselt dabei die Daten. Der Empfänger entschlüsselt das Chiffrat und
Seite 4
stellt damit die ursprünglichen Daten wieder her. Die Chiffrierung der Daten
erfolgt üblich mit symmetrischen Verschlüsselungsverfahren. Bekannte Verfahren sind beispielsweise Triple-DES (→3DES), Advanced Encryption Standard
(→AES) oder Blowfish. Die Schlüssellänge ist hinreichend zu wählen, um erfolgreiche Brute-Force-Attacken zu vermeiden.
2. Integrität:
Die Verschlüsselung gewährt zwar die Vertraulichkeit der Daten, sie schützt
jedoch nicht vor deren Manipulation. Der Empfänger muss in der Lage sein,
zu erkennen, ob die chiffrierten Daten beim Transport verändert wurden. Die
Integrität verschlüsselter Daten wird in der Praxis durch Prüfsummenverfahren
(Message Digests) wie Hash Message based Authentication Code (→HMAC)
realisiert.
3. Authentizität:
Ohne die Authentisierung wäre es immer noch denkbar, das Chiffrat auf dem
Transportweg zu manipulieren, mit gefälschter Absenderadresse zu versehen
(Spoofing) und schließlich mit neu berechneten Prüfsummen an den Empfänger
zu leiten. Dies bezeichnet man auch als Man-In-The-Middle Attack.
Die Authentisierung garantiert dem Empfänger, dass die Daten tatsächlich von
dem vorgegebenen Absender stammen.
2.1.2 Typische VPN-Realisierung für mobile Mitarbeiter
Das mobile Endgerät greift auf unterschiedliche Anwendungen im LAN eines Unternehmens zu. Diese Anwendungen können auf unterschiedliche Systeme verteilt sein.
Daher benötigt das mobile Endgerät Zugriff auf das gesamte LAN. Der Kommunikationskanal wird durch eine VPN-Software auf dem mobilen Endgerät und auf
einem VPN-Gateway im LAN des Unternehmens gesichert. Die Studie →[URL:01]
empfiehlt, die Zugriffsmöglichkeiten des mobilen Endgerätes auf Systeme im LAN
technisch zu reduzieren. Die verbleibenden Zugriffsmöglichkeiten sind nötig, damit
der mobile Mitarbeiter seine Tätigkeit ausüben kann.
2.1.3 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 Endgerät nie ausgeschlossen werden. Daher sollten Aufbau
Seite 5
und Nutzung des Kommunikationskanals erst nach einer starken Authentisierung
des mobilen Mitarbeiters möglich sein.
Die Authentisierung bei VPNs kann in zwei Klassen aufgeteilt werden →[KONG04]:
• maschinenbezogene Authentisierung:
Damit ist die Authentisierung von Netzwerkgeräten gemeint. Die Authentisierung kann in zwei Phasen erfolgen. In der ersten Phase identifizieren sich Sender
und Empfänger gegenseitig, bevor die Aushandlung des sicheren Kommunikationskanals abgeschlossen wird. In der zweiten Phase, der Übertragungsphase,
überprüft der Empfänger die Authentizität des Senders für jedes eingehende
Datenpaket. Die Authentisierung kann unter Verwendung von Preshared Keys
(geheime Schlü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 Verfügung stehen. Der PSK bildet gewissermaßen die
Berechtigung zur Authentisierung. Die Schlüssel müssen vorher über ein sicheres Medium ausgetauscht werden. Die Authentisierung selbst geschieht
häufig nach einer Art Challenge-Response-Verfahren mit Hash-Werten, die
aus dem PSK abgeleitet werden. Nachteile bezüglich der Sicherheit sind
eher praktischer Natur: ein einziger PSK wird für eine gesamte VPNInfrastruktur verwendet oder es wurde ein trivialer PSK gewählt.
– Public-Key-Verfahren:
Dieses Verfahren ermöglicht eine Authentisierung mit digitalen Signaturen und asymmetrischer Verschlüsselung. Dafür lassen sich Zertifikate
nach Standard ITU-X.509 verwenden. Um die Gültigkeit von Zertifikaten
zu verifizieren, ist das Einbetten einer VPN-Infrastruktur innerhalb einer Public-Key-Infrastruktur sinnvoll. Die Verwaltung einer Public-KeyInfrastruktur bedeutet einen zusätzlichen administrativen Aufwand, bietet
jedoch ein höheres Maß an Sicherheit. Eine Public-Key-Infrastruktur unter
Linux lä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 gegenüber einem
Zugangskontrollsystem identifizieren, z.B. durch eine Kombination aus Benutzername und Passwort. Als Beispiel für ein Zugangskontrollsystem sei
Seite 6
hier ein AAA-Server genannt. Personenbezogene Authentisierungen werden
häufig ü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 Empfänger zunächst einen
sicheren Kommunikationskanal aus. Im Anschluss folgt die personenbezogene Authentisierung am Zugangskontrollsystem. Dieses Verfahren bietet zusä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 über den sicheren Kommunikationskanal erreichbar ist.
2.1.4 Internet Protocol Security (IPSec)
IPSec (Internet Protocol Security) ist die derzeit am häufigsten verwendete VPNLösung (Quelle: →[URL:01] und →[AHLE02]). Es erweitert das IP-Protokoll um
zwei Sicherungsarten:
• Authentication Header (AH) bietet Authentizität und Integrität.
• Encapsulated Security Payload (→ESP) bietet Vertraulichkeit, Authentizität
und Integrität.
Beide Sicherungsarten kö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 ausgefü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 für Remote-Access (RAS) und zur
Kopplung entfernter Subnetze verwendet. Der Transport Mode sieht lediglich die
Kapselung der Payload eines IP-Paketes vor. Der ursprüngliche IP-Header bleibt
sichtbar. Soll eine direkte Kopplung zweier Rechner via IPSec erreicht werden,
bietet sich der Transport Mode an.
Seite 7
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 Verschlüsselung mit dynamisch erzeugten Sitzungsschlüsseln. Die Aushandlung der Sitzungsschlüssel, der Verbindungskonfiguration
und der Authentisierung geschieht ü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 Sicherheitsgründen nicht zu empfehlen: IKE im Aggressive Mode beschleunigt zwar die Aushandlung einer IPSec-Verbindung, überträgt jedoch Authentisierungsnachrichten im Klartext, was ein Angriffspunkt
darstellt (besonders bei trivial gewählten PSKs) →[THUM07]. Der Aggressive
Mode wurde aus Kompatibilitätsgründen eingeführt, um IPSec-Verbindungen
mit dynamischen IP-Adressen und Preshared Keys zu ermöglichen.
• Main Mode:
Dieser Modus sollte immer verwendet werden. Der Main Mode unterstützt
die Authentisierung basierend auf Zertifikaten und Preshared Keys. Die
Verwendung von Preshared Keys funktioniert nur mit statischen IP-Adressen.
Die ursprüngliche Spezifikation von IPSec wird kaum noch verwendet. Ein Grund
dafür ist z.B. die weit verbreitete Anwendung der Network Address Translation
(→NAT) in Netzwerken, da es den Header eines IP-Pakets verändert. Aus diesem Grund hat man die IPSec-Spezifikation um die Erweiterung NAT Traversal
Seite 8
(→NAT-T) ergänzt. Die Erweiterung NAT-T sieht eine NAT-Erkennung wä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
entfällt
entfällt
Tabelle 2.2: IPSec mit Berücksichtigung von NAT-T
Dienst
Protokoll
Quellport
Zielport
IKE
UDP(IP 17)
nicht definiert
500, 4500
ESP über UDP
UDP (IP 17)
nicht definiert
4500
ESP
IP 50
entfällt
entfällt
Im Bereich der Open Source Software existieren diverse IPSec-Implementierungen.
Eine bekannte Implementierung fü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].
2.1.5 Layer 2 Tunneling Protocol (L2TP) over IPSec
Das Layer 2 Tunneling Protocol (→L2TP) ist die von Microsoft favorisierte Lösung zum Aufbau von VPN-Verbindungen. Diese Lösung ist ein fester Bestandteil
in allen neueren Microsoft Betriebssystemen, wie Windows XP und dem vor kurzem
erschienenen Windows Vista (→[DELE07]). Handheld-Geräte mit Windows Mobile
zählen ebenfalls dazu. Auf einem mobilen Endgerät mit Microsoft Betriebssystem
ist daher keine zusätzliche Software nötig. L2TP bietet allerdings keine Sicherheitsfunktionen für übertragene Nutzdaten. Daher wird IPSec zur Realisierung der VPNAnforderungen Vertraulichkeit, Integrität und Authentizität eingesetzt. Der Einsatz
von IPSec als eigenständiges VPN-Protokoll ist zwar in den Microsoft Betriebssystemen nicht vorgesehen, lässt sich jedoch durch Software von Drittanbietern nachrüsten.
Die Nutzung von L2TP in Kombination mit IPSec ist keine properitäre Lösung
eines großen Herstellers, sondern ein durch die Internet Engineering Task Force
Seite 9
→[URL:10] verabschiedeter Standard →[URL:23].
L2TP wurde ursprünglich zur Kapselung des Point-to-Point-Protokolls entwickelt
→[URL:01]. Microsoft hat diesen Ansatz in die VPN-Implementierungen der eigenen Betriebssysteme übernommen. Abbildung 2.3 (Quelle →[URL:01]) zeigt die
Anordnung von IPSec, L2TP und Point-to-Point Protocol (→PPP) im OSI/ISOSchichtenmodell.
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), während die
personenbezogene Authentisierung ü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 IPAdresse 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 höher, da neben IPSec noch
L2TP und PPP zu implementieren sind.
Seite 10
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 enthä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 unerwünschte Zugriffe aus einem nicht vertrauenswürdigen
Netzwerk zu schützen. Die einfachste Ausprä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
lässt sich der Zugriff von Rechnern in Netzwerk A auf Dienste von Rechnern in
Netzwerk B explizit einschränken.
Dieser einfache Paketfilter kann jedoch nicht unterscheiden, ob der in Anspruch
genommene Dienst regulär oder missbräuchlich verwendet wird, da er jedes Datenpaket einzeln, ohne Berücksichtigung vorangegangener Datenpakete, bewertet. Die
Berü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 unterhält
dazu eine Statustabelle, die den Zustand aktiver Verbindungen speichert. Dabei
werden auch verbindungslose Protokolle berücksichtigt.
Abbildung 2.4 Quelle →[URL:32] zeigt das Prinzip von Stateful Packet Inspection:
Der Client mit der IP-Adresse 192.168.51.50 sendet ein erstes Paket an den Server
mit der IP-Adresse 172.16.3.4. 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 lässt das Paket zu, da für die Daten im Paket-Header ein Eintrag in
Seite 11
der Statustabelle existiert. Der Server sendet wenig später erneut ein Paket an den
Client. Der Paketfilter erkennt dieses Paket als unzulässig und verwirft es, da die
Daten im Paket-Header mit keinem Eintrag in der Statustabelle ü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-Funktionalität mit Stateful Packet Inspection bereits integriert.
Für die Konfiguration des Paketfilters steht das Kommandozeilen basierte Werkzeug
IPTables →[URL:12] zur Verfügung.
Seite 12
2.3 Authentisierung, Autorisierung und Accounting (AAA)
Mitarbeiter, die sich mit ihren mobilen Endgeräten per VPN in das Unternehmen
einwählen möchten, benötigen im Allgemeinen transparenten Zugriff auf Dienste im
lokalen Netzwerk. Ein Problem dabei ist, dass diese Dienste dafür außerhalb des Unternehmens (über einen exponierten Netzzugang) verfügbar sein müssen. Ohne eine
Zugriffskontrolle kann prinzipiell jede Person mit Zugriff auf das mobile Endgerät
eines Mitarbeiters eine anonyme VPN-Einwahl durchführen.
Authentisierung, Autorisierung und Accounting (→AAA) steht für ein Modell, das
eine Zugriffskontrolle für entfernte Benutzer vorsieht →[URL:04].
Nur wenn ein Benutzer sich eindeutig identifiziert hat, kö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 über ein Netzwerkprotokoll, dass sowohl die Übertragung von Nutzdaten
als auch Authentisierung unterstü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:
• Kennwörter werden im Klartext von dem entfernten Endgerät zum Einwahlknoten übertragen. Dies ist als Password Authentication Protokoll (PAP) bekannt.
• Es werden keine Kennwörter im Klartext von dem entfernten Endgerät zum
Einwahlknoten übertragen. Stattdessen sendet der Einwahlknoten zunächst ein
zufällig generiertes Datagramm (Challenge) an das entfernte Endgerät. Das
Endgerät leitet aus diesem Datagramm und dem Kennwort einen Hash-Wert
(Response) ab, und sendet diesen an den Einwahlknoten zurü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
der empfangene Hash-Wert (Response) mit dem lokal erzeugten Hash-Wert
überein, ist die Authentisierung erfolgreich. Dieses Verfahren ist als ChallengeHandshake 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 über ein unsicheres TCP/IP-Netzwerk verbunden sind. Die Authentisierung
erfolgt dabei über eine vertrauenswürdige dritte Instanz, den Kerberos-Server. Die
Sicherung der Authentisierung basiert dabei auf der Verwendung kryptografischer
Funktionen um ein Ausspähen geheimer Daten zu verhindern.
Die Authentisierung mit Kerberos basiert auf so genannte Tickets, die zwischen den
beteiligten Entitäten ausgetauscht werden. Die zentrale Instanz ist ein KerberosServer, der ein Kerberos Distribution Center (→KDC) enthält. Das KDC besteht
wiederum aus den Entitä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 möchte, sendet zunächst eine Anfrage mit dem gewünschten Dienst zum AS. Dazu muss
der Benutzer normalerweise sein geheimes Passwort eingeben.
2. Der AS verifiziert die Identitä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 für den gewünschten Dienst auf dem Applikationsserver gültig.
5. Der Client sendet das SGT an den Applikationsserver. Dieser verifiziert das
SGT und schaltet den Dienst für den Client frei.
6. Der Applikationsserver authentisiert sich gegenüber dem Client.
Seite 14
Abbildung 2.5: Authentisierung mit Kerberos
Jeder Kerberos-Server hat seinen eigenen Verwaltungsbereich, den so genannten
Realm. Bei einem Domänencontroller mit Active Directory ist es häufig anzutreffen,
dass der DNS-Name des Domänencontrollers in Großbuchstaben für die Bezeichnung
des Realms verwendet wird →[BUDD05].
2.3.2 Autorsisierung
Die Autorisierung dient der Festlegung von Zugriffsrechten auf Netzwerkdienste in
Abhängigkeit des jeweiligen Benutzers. Dies kann entweder über ein spezielles Benutzerprofil oder global über ein Gruppenprofil erfolgen, falls eine Anzahl von Benutzern
mit identischen Zugriffsrechten auszustatten ist. Benutzer- und Gruppenprofile können über einen Verzeichnisdienst wie LDAP oder Active Directory realisiert werden.
2.3.3 Accounting
Die Allgemeine Aufgabe des Accountings ist das Protokollieren von Benutzeraktivitäten. Die Auswertung dieser Benutzeraktivitäten ist für ein Unternehmen ein wichtiges Instrument, um z.B. die Auslastung des Netzzugangs zu analysieren oder Missbrauch (mehrfache Anmeldungen unter der selben Benutzeridentität, ungewöhnliche
Anmeldezeiten) zu erkennen.
2.3.4 AAA-Server
Authentisierung, Autorisierung und Accounting kann zentral über eine SoftwareLösung erfolgen. Diese arbeitet nach dem Client-Server-Prinzip (Abbildung 2.6).
Seite 15
Abbildung 2.6: AAA-Server
Der Network Access Server (→NAS) ist in diesem Fall Einwahlknoten für die entfernten Benutzer und gleichzeitig der AAA-Client. Der entfernte Benutzer stellt mit
seinem mobilen Endgerät eine Verbindung zum NAS her und identifiziert sich gegenüber Selbigem. Der NAS reicht die Identitä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) für diesen Benutzer als Antwort an den NAS. Der NAS wiederum sendet nach erfolgter
Autorisierung benutzerspezifische Daten zur Aufzeichnung an den AAA-Server.
2.3.5 RADIUS
Die in diesem Abschnitt enthaltenen Information basieren im Wesentlichen auf Informationen der Quelle [BRIL01].
Eigenschaften
Die Kommunikation zwischen AAA-Server und NAS findet ü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 übermittelt die Benutzeridentität an den RADIUS-Server. Der RADIUS-Server entscheidet, ob diese Benutzeridentität zugelassen wird. In jedem Fall sendet der RADIUS-Server eine
Antwort an den RADIUS-Client.
Seite 16
• Verschlüsselung des AAA-Protokolls:
Die Kommunikation zwischen RADIUS-Client und RADIUS-Server ist symmetrisch chiffriert (Shared Secret auf Server und Client), um ein Ausspähen
von Benutzeridentitäten zu vermeiden.
• multiple Authentisierungs-Mechanismen:
Das RADIUS-Protokoll spezifiziert multiple Mechanismen für die personenbezogene Authentisierung, zum Beispiel PAP (über PPP), CHAP (ebenfalls über
PPP) oder UNIX Login.
• Nachrichtenaustausch über Attribut-Werte-Paare:
zum Beispiel:
User-Name = Andreas
Framed-Protocol = PPP
Framed-IP-Address = 10.0.3.32
Mit speziellen Wörterbuch-Listen lässt sich der Vorrat möglicher Attribute
flexibel erweitern. Dadurch ist es z.B. möglich, herstellerspezifische Attribute
zu verwenden, die in der ursprünglichen Definition des RADIUS-Protokolls
nicht enthalten sind.
Typischer Ablauf
In diesem Szenario möchte der Benutzer einen bestimmten Dienst beanspruchen.
Abbildung 2.7 zeigt den Ablauf einer RADIUS-Sitzung zwischen dem RADIUSClient (NAS) und dem RADIUS-Server:
1. Der RADIUS-Client fordert den Benutzer auf, seinen Benutzernamen und
Passwort für einen bestimmten Dienst einzugeben. Im Anschluss daran formt
der RADIUS-Client einen verschlüsselten Access-Request mit Attribut-WertePaaren, 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 überprüft ob
die im Access-Request gesendeten Attribute-Werte-Paare mit den für diesen Benutzer gültigen Attribute-Werte-Paaren übereinstimmen. Der RADIUS-Server
fragt dazu seine interne Datenbank ab. Findet der RADIUS-Server keine ÜberSeite 17
einstimmung, sendet dieser ein Access-Reject an den RADIUS-Client. Dieser
wird dann dem Benutzer mitteilen, dass der Zugriff verweigert wurde.
Bei einer Überprüfung mit positivem Ergebnis schnürt der RADIUS-Server
eine Access-Accept-Nachricht mit zusätzlichen Konfigurationsattributen. Diese enthalten zusä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 enthält Informationen ü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 länger benötigt oder der Dienst auf eine
andere Weise terminiert, erzeugt der RADIUS-Client eine Accounting-StopNachricht mit statistischen Informationen über den in Anspruch genommenen
Dienst, wie Online-Zeit, ü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
Ein RADIUS-Server kann unter Linux mit der Open Source Software Freeradius
[URL:06] realisiert werden.
2.4 Trusted Network Connect
Heutige Rechnersysteme können nicht auf Vertrauenswürdigkeit und Systemintegrität geprüft werden. Aus diesem Grund ist eine vertrauenswü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 vertrauenswürdiger Verbindungen z.B. über das Internet. Die TNC-Architektur ist die Entwicklung einer
offenen und herstellerunabhängigen Spezifikation zur Überprüfung der Integritä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.
2.4.1 Architektur
Die Architektur des Trusted Network Connects ist von der Trusted Computing
Group in der Spezifikation 1.1 (Revision 2) vom 1. Mai 2006 verö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).
Ä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 über die Komponenten der drei Einheiten gelegt worden.
Das Zusammenwirken der einzelnen Komponenten wird durch Interfaces realisiert.
Seite 19
Abbildung 2.8: TNC-Übersicht (Trusted Computing Group)
2.4.2 Einheiten
Die Einheiten, sind wie schon erwä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 geschütztes Netzwerk her.
• Policiy Decision Point (PDP)
Der Policy Decision Point entscheidet für die Anfrage des AR, wie die Zugriffsrechte fü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 Stück Hardware oder Software oder sogar in einem System
aus mehreren Maschinen bestehen.
2.4.3 Komponenten
Der AR beinhaltet in der Architektur die folgenden Komponenten:
Seite 20
• 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 ermö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 über die IMC’s abrufbar, kann der TNC Client zusätzlich selbst
Informationen ü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 können und das diese IMC’s auch ihre Status-Informationen an
mehrere TNC Clients melden kö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 erhält die Berechtigungen fü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 erhä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 für den NAA ab.
• Integrity Measurement Verifier (IMV)
Der IMV verifiziert (z.B. mit Hilfe eines Integritätstests) den AR anhand der
Daten von den IMC’s.
Seite 21
2.4.4 Layers
Die Layers fassen ähnliche Funktionen und Rollen der Einheiten und Komponenten
der TNC-Architektur zusammen:
• Network Access Layer
Der Network Access Layer ist für die gesamte Kommunikation von dem AR
über den PEP zu dem PDP über ein Netzwerk zuständig.
• Integrity Evaluation Layer
Der Integrity Evaluation Layer ist für eine allgemeine Bestimmung der Zugriffsrechte des AR zuständig. Dabei werden generelle Policies sowie die Ergebnisse
des Integrity Measurement Layers gewichtet und berücksichtigt.
• Integrity Measurement Layer
Der Integrity Measurement Layer beinhaltet sämtliche Komponenten (z.B.
Plugins oder kleine Programme/Utilities), die eine Sicherheitsüberprüfung des
AR ermöglichen.
2.4.5 Interfaces
Für die Kommunikation der Komponenten und Einheiten, sowie für den Austausch
von Informationen und Nachrichten untereinander, werden Interfaces benötigt:
• Integrity Measurement Collector Interface (→IF-IMC)
Das Integrity Measurement Collector Interface ist das Interface zwischen dem
IMC und dem TNCC. Über dieses Interface werden Informationen über den
Status des AR gesammelt und automatisch an den TNCC weitergereicht.
Zu beachten ist dabei, dass die IMC’s selbststä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.
Über dieses Interface werden die Informationen von den IMC’s ausgewertet
und eine Empfehlung an den TNC Server über den aktuellen Status des AR’s
weitergereicht.
• TNC Client-Server Interface (→IF-TNCCS)
Über das TNC Client-Server Interface werden Informationen über den Integritätsstatus des AR’s ausgetauscht.
• Vendor-Specific IMC-IMV Messages (IF-M)
Dieses Interface wird für den Austausch von herstellerspezifischen Informatio-
Seite 22
nen zwischen den IMCs und den IMVs benötigt. Die Informationen werden
über das TNCCS Interface gesendet.
• Network Authorization Transport Protocol (→IF-T)
Ü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)
Über das Policy Enforcement Point Interface werden Informationen zwischen
dem PEP und dem PDP über die Zugriffsrechte (z.B. bestimmtes VLAN, Isolation oder keine Zugangsberechtigung) des AR ausgetauscht.
2.4.6 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 Verständnis, dargestellt:
• Punkt 0:
Vor jedem Verbindungsaufbau muss gewährleistet sein, dass die IMCs gestartet
sind und ihre Informationen sowie den Status an den TNC Client melden. Der
TNC Client überprüft die Integrität der einzelnen Module; sind alle relevanten
Module gestartet und verfü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
Überprüfung der Authentisierung findet dann zwischen dem AR und der NAA
statt.
• Punkt 3:
Bei einer erfolgreichen Authentisierung informiert der NAA den TNC Server
über den Versuch des Verbindungsaufbaus.
• Punkt 4:
Nun findet eine gegenseitige Authentifizierung zwischen dem TNC Client und
dem TNC Server statt.
Seite 23
• 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 IMCs. Der TNCC und der TNCS starten einen Integritätstest; die IMCs senden
Informationen (IMC-IMV Messages) zu dem TNCC.
• Punkt 6A:
Der TNCC und der TNCS tauschen Informationen über den Status des AR
(Integritä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 Integritä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 über die Zugriffsberechtigung des NAR
an den PEP und den TNCS. Der TNCS leitet die Entscheidung dann an den
TNCC weiter, während der PEP den Zugriff des NAR je nach Entscheidung
beschränkt oder zulässt.
Seite 24
Abbildung 2.9: Workflow der TNC-Architektur
2.4.7 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 fü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 für die NAC Architektur benötigt wird. Er überprü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
Control unterstü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 erlä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 fä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 überprüft die von dem Trust Agent gesendeten Informationen und fällt dann die Entscheidung über den zukünftigen Status des
Clients (Quarantäne oder Netzzugriff).
• Punkt 5:
Die Entscheidung ü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) für den Zugriff des Clients, in diesem Fall
z.B. Quarantäne. Alle drei Minuten wird die Überprüfung (ab Punkt 2) erneut
gestartet.
• Punkt 7:
Dem Benutzer wird über den Trust Agent eine Mitteilung über den Status
seines PCs ausgegeben. Er hat nun die Möglichkeit, gegebenenfalls notwendige
Updates zu laden. Spätestens nach drei Minuten wird sein System erneut von
dem Trust Agent überprüft.
Seite 26
Abbildung 2.10: Workflow Cisco NAC
2.5 Verschlüsselung von Daten
Für ein Unternehmen ist es immer ein Problem, wenn komplette Rechner, Festplatten oder sogar nur CDs gestohlen werden, da sich auf diesen Datenträgern
hoch sensible Daten befinden können. Ein Schutz vor Diebstahl kann nicht immer
gewährleistet werden, deswegen ist es notwendig, sensible Daten zu verschlüsseln.
Für die Verschlüsselung von Daten können hauptsächlich drei Methoden angewandt
werden:
• Verschlüsselung einzelner Dateien
• Verschlüsselung mit virtuellen Laufwerken (Containern)
• Verschlüsselung des gesamten Mediums
2.5.1 Verschlüsselung einzelner Dateien
Fast jedes Betriebssystem unterstützt die Möglichkeit in dem Filesystem, einzelne
Dateien zu verschlüsseln und bei Verwendung der Datei, diese automatisch zu entschlüsseln. Diese Art der Verschlüsselung ist nicht die sicherste, da nach Start des
Betriebssystems und mit korrekter Anmeldung diese verschlüsselte Datei automatisch entschlüsselt wird. Diese Dateien sind also auf andere Medien kopierbar.
Ein weiteres Problem dieser Verschlüsselung ist, dass dem Benutzer das Verschlüsseln überlassen wird. Der Benutzer muss also manuell das Verschlüsseln der Datei
Seite 27
anstoßen; alle anderen Dateien bleiben dabei unverschlüsselt (siehe Abbildung 2.11
Quelle →[URL:02]).
Abbildung 2.11: Einfache Dateiverschlüsselung
2.5.2 Verschlüsselung mit virtuellen Laufwerken (Containern)
Diese Art der Verschlüsselung ist die am häufigsten verwendete. Es wird dabei auf
dem Laufwerk eine Datei erzeugt, die mit einem beliebigen Verschlüsselungsalgorithmus verschlü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 geschützt.
Ein Problem jedoch sind temporäre Dateien, die normalerweise in den unverschlüsselten Bereich der Festplatte angelegt werden. Diese temporäre Dateien (bei Microsoft Windows z.B. die Auslagerungsdatei) werden nicht zwingend wieder gelöscht,
dass heißt sie kö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 verschlüsselten Container zu speichern, welches aber nicht mit
der Windows Auslagerungsdatei möglich ist.
Im Open Source Bereich gibt es einige Programme, die eine Verschlüsselung der Daten ermöglichen, wie z.B. TrueCrypt [URL:28] oder FreeOTFE [URL:05].
Seite 28
Abbildung 2.12: Virtuelle Dateiverschlüsselung (Container)
2.5.3 Verschlüsselung des gesamten Mediums
Bei der Verschlüsselung des gesamten Mediums wird die komplette Festplatte verschlü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 Schlüssel vor dem Start des Betriebssystems gefragt. Wird der Schlüssel (z.B. eine Schlüsseldatei auf einem USB-Stick, eine
Key-Karte oder ein Passwort) korrekt eingegeben, wird das Betriebssystems während des Startens on the fly entschlüsselt.
Diese Art der Datenverschlüsselung ist am sichersten, da alle vorhandenen Dateien
auf der Festplatte verschlüsselt sind und ohne den Schlü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 kö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 können. Ein korruptes (aber verschlüsseltes) Filesystem könnte die Folge sein.
Seite 29
Abbildung 2.13: Vollstaendige Laufwerksverschlüsselung
2.6 Fernadministrierung
In großen und mittelständischen Unternehmen können Personalkosten eingespart
werden, indem der Support oder der Help-Desk die Möglichkeit haben, sich auf
Endgeräte einzuwählen. Bei Problemen oder auch nur für Hilfestellungen, kann ein
Dienst auf dem Endgerät gestartet werden, über diesen sich der Support-Mitarbeiter
mit dem Endgerät verbindet.
Nachdem der Mitarbeiter mit dem Endgerät verbunden ist, wird die Benutzeroberfläche des Betriebssystems auf den Bildschirm des Support-Mitarbeiters gespiegelt.
Der Mitarbeiter ist somit in der Lage, das Endgerät so zu bedienen, als ob er vor
Ort wä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 Verfügung zu stellen, ist für das Warten, Unterhalten und Pflegen von
vielen Endgeräten sehr hilfreich:
• Zentrales Einspielen von Patches für Virenscanner und Betriebssysteme möglich
• Einfache Einführung neuer Softwarepakete möglich
• Reduzierung von Bandbreite, speziell ins Internet
• Überblick auf installierte Softwarepakete auf den Endgeräten
Seite 30
• Inventarisieren von Endgeräten möglich
• Einsparungen von Personal und Kosten
Das hierfür bekannteste kommerzielle Produkt ist NetInstall [URL:14] von enteo.
NetInstall besteht aus einer Client-Server-Struktur:
• Server
Der Server stellt über das Netzwerk, als Dateiserver (File Share), Ressourcen
zur Verfügung. Auf diesem Server sind sämtliche Softwarepakete sowie die Installationsscripte zur Installation der Softwarepakete hinterlegt.
• Client
Der Client wird auf das zu wartende Endgerät installiert. Bei Start des Endgerätes überprüft der Client, ob Updates oder Softwarepakete auf dem NetInstallServer bereit stehen (preloginloader) und installiert (Script-Processing) diese
dann automatisch, ohne dass der Endbenutzer in den Installationsprozess eingreifen kann.
Zusätzlich bietet der Client von NetInstall die Möglichkeit der Software on
Demand Funktionalität an. Über diese Funktion kann der Benutzer aus einem
angebotenem Software-Pool bestimmte Pakete manuell installieren (z.B. einen
zusätzlichen Browser wie den Mozilla Firefox).
2.7.1 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 für die Softwarepakete vorhanden sind. Es gibt
vier Verfahren, wie sich Softwarepakete für die Distributionssoftwareverteilung
klassifizieren lassen:
1. Unattended / Silent Setup
2. Administrative Installation
3. Interaktives Setup mit automatischen Antworten
4. Neu-Paketierung
Seite 31
Es gibt bei der Erstellung von Scripten kein Patentrezept, jedoch ähneln sich die
Installationsscripte sehr stark. Häufig ist es notwendig, einen Kompromiss bei der
Erstellung der Scripte zu finden, das heißt eine Kombination der unterschiedlichen
Möglichkeiten der Scripterstellung ist häufig sinnvoll.
2.7.2 Unattended / Silent Setup
Bei der Unattended oder Silent Setup Installation wird der Installationsroutine
ein spezieller Parameter übergeben, damit das Programm in dem Silent- oder
Unattended-Modus ausgefü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, müssen diese auf jedem installierten System nachträglich manuell durchgeführt werden.
Unattended- oder Silent Setup Routinen werden hauptsächlich von Microsoft Installer Paketen (→MSI) angeboten. Die gängigen Parameter sind dabei /s, /silent,
/quiet, /passive oder /qn.
Eine Auflistung der unterschiedlichen Parameter und Installationsprogramme ist
unter [URL:26] zu finden.
2.7.3 Administrative Installation
Bei der administrativen Installation wird das Setup-Programm der Anwendung mit
einem zusätzlichem Parameter ausgeführt, damit das Installationsprogramm die Eingaben des Software-Administrators wä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 während der Installation (z.B. Lizenz, Auswahl der Tools,
Installationsverzeichnis, Konfiguration, etc.) enthält. Mit dieser Datei können zukünftige Installationen erfolgen, dass heißt, es kann eine Unattended oder Silent
Setup Installation mit einem Parameter auf die existierende Konfigurationsdatei
durchgeführt werden und die Installationsroutine holt alle benötigen Informationen
(die vorherigen Eingaben des Administrators) aus der Konfigurationsdatei. Somit
entfällt das nachträgliche manuelle Konfigurieren der installierten Anwendung.
Programmpakete, die eine administrative Installation erlauben, sind z.B. alle Microsoft Office Pakete.
Seite 32
2.7.4 Interaktives Setup mit automatischen Antworten
Falls eine Unattended oder Silent Setup Installation nicht möglich ist, muss ein
Installationsscript erstellt werden, dass auf Fragen oder benö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 füllt diese gemäß des erstellten Scriptes mit Daten.
Diese Art der Installation besitzt jedoch auch Nachteile:
• Nicht berücksichtigte Fehlerfenster kö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 möglichst eine der beiden vorherigen Arten der Erstellung
von Installaionsscripten verwendet werden oder falls dies nicht möglich ist, eine
Kombination der beiden Installationsarten, wobei der Steuerungsprozess möglichst
kurz gehalten wird.
2.7.5 Neu-Paketierung
Ist eine Generierung eines Installationsscriptes mit den vorherigen drei Methoden
nicht mö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-Einträge sowie die zu erstellenden Links zu einem neuen
und eigenständigen Paket zusammen.
Damit der Administrator an die benötigten Dateien und Informationen herankommt,
muss er die Installation des Programms mit Hilfe einer Spy-Software überwachen.
Die Spy-Software protokolliert dabei alle zu kopierenden Dateien und neu eingetragene Registry-Einträge. Diese Dateien können dann zu einem neuen MSI-Paket (z.B.
mit Installer2Go [URL:24]) geschnürt werden und dann in dem Silent Modus wieder
verteilt und installiert werden.
Seite 33
Kapitel 3 - Entwicklung des Systemkonzeptes
3 Entwicklung des Systemkonzeptes
3.1 Systemübersicht
Die Abbildung 3.1 zeigt die konzeptionelle Gesamtansicht der dedizierten Infrastruktur:
• Mobile Endgeräte (Clients)
Die mobilen Endgeräte sind in der Lage, einen VPN-Tunnel zum Mobile Security Gateway herzustellen, sofern für sie, wie in der Abbildung 3.1 angedeutet, eine Verbindung zum Transportnetz (hier: Internet) über ein beliebiges
Transportmedium besteht. Das Tansportnetz muss dafür das eingesetzte VPNProtokoll, welches für den VPN-Tunnel zum Einsatz kommt, auf der gesamten
Transportstrecke unterstü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 enthält modulare Softwarekomponenten, die in Kombination
die Funktionalität der Sicherheitsplattform für die mobile Kommunikation
ausprägen.
Das Mobile Security Gateway enthält die folgenden Module:
– Modul Firewall
Dieses Modul regelt den Zugriff auf die Netzwerkdienste.
– Modul VPN
Dieses Modul ermö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 ZusammenSeite 34
arbeit mit einem speziellem Client (TNC Client), der auf den RemoteNotebooks installiert ist.
– Modul Distributionssoftwareverteilung
Dieses Modul stellt eine Plattform für die Software-Verteilung an die
Clients.
• Client Referenzsystem
Das Client Referenzsystem wird für die Entwicklung und Erstellung von
Software-Paketen für die Distributionssoftwareverteilung benötigt. Auf diesem
System können die Pakete getestet werden und nach erfolgreichem Test für
andere Clients freigegeben werden.
• Verzeichnisdienst
Die Komponente Verzeichnisdienst stellt die zentrale Benutzerverwaltung dar.
Fü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 Endgeräte (Clients)
3.2.1 PDA/MDA/iPAQ
Für die Einbindung der Geräte in das Gesamtkonzept werden auf den Geräten das
Modul VPN benötigt. Die Geräte können mit dem Unternehmensnetz nur über die
Protokolle SMTP, POP3 oder IMAP kommunizieren. Der sonstige Datenverkehr
wird gefiltert.
Seite 35
Verschlüsselung von Daten
Die Verschlüsselung der Daten soll nur mit Open Source Software realisiert werden.
Die einzige Möglichkeit, die Verschlüsselung zu realisieren, ist mit Hilfe von Containern (virtuellen Laufwerken) möglich.
Falls eine komplette Verschlüsselung des Datenträgers gewünscht oder erforderlich
ist, muss auf eine kommerzielle Lösung, wie z.B. SafeGuard des Herstellers utimaco
[URL:31] zurückgegriffen werden.
Fernadministrierung
Eine ausführliche Suche nach geeigneter Software für die Fernadministrierung ist negativ ausgefallen. Es gibt zwar Client-Module die Remote-Bildschirme auf den PDA
spiegeln können jedoch nicht umgekehrt. Deswegen ist eine Fernadministrierung der
PDAs aufgrund von fehlender Software noch nicht möglich.
3.2.2 Remote Notebooks
Für den Trusted Network Connect und die Remote-Einwahl der Notebooks werden
auf den Notebooks folgende Module benötigt:
• VPN / TNC Client
Das Modul VPN / TNC Client stellt die Verbindung zum Mobile Security
Gateway her und überprüft die Integritä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 führt die Installationsroutinen der zu installierenden Pakete aus.
Die Verschlüsselung der sensiblen Daten auf den Notebooks kann durch zwei Möglichkeiten erreicht werden:
1. Erstellen von Containern
2. Verschlüsseln der gesamten Festplatte
Für die Verschlüsselung von Daten mit Hilfe von Containern wird ein Verschlüsselungsmodul in das Betriebssystem integriert; bei einer Verschlüsselung der gesamten
Seite 36
Platte werden Zusatzprogramme benötigt, welche die Festplatte verschlüsseln und
eine Pre-Boot-Authentication in den Boot-Sector der Festplatte schreiben.
Fernadministrierung
Die Fernadministrierung auf den mobilen Endgeräten ermöglicht ein Server-Modul,
welches als Dienst auf den Endgeräten läuft und somit bei Start des Betriebssystems
immer verfügbar ist.
Bei bestehender Verbindung des Endgerätes in das Unternehmensnetz kann ein
Client-Modul sich mit dem Server-Modul verbinden. Über diese Verbindung wird
die Benutzeroberfläche des zu administrierenden Endgerätes auf die Benutzeroberfläche des Administrationssystems gespiegelt.
Der Verbindungsaufbau zu dem Server-Modul ist mit einem Passwort geschützt;
zusätzlich wird die Datenübertragung ebenfalls verschlüsselt.
Seite 37
3.3 Mobile Security Gateway
Das mobile Security Gateway (siehe Abbildung 3.2) ist die zentrale Komponente der
mobilen Kommunikation und stellt folgende fünf Module zur Verfügung:
• VPN-Server
• Firewall
• Authentisierung, Autorisierung und Accounting (AAA)
• Trusted Network Connect (TNC)
• Distributionssoftwareverteilung / Betriebssysteminstallation
Abbildung 3.2: Übersicht Remote-Zugriff
Seite 38
3.3.1 VPN-Server
Dieses Modul ermöglicht eine abhörsichere VPN-Transportverbindung über ein unsichere Transportnetz. Bei der Aushandlung einer VPN-Transportverbindung wird
die Identität des Remote-Benutzers angefordert und an das Modul AAA zur Überprüfung weiter gereicht.
Bei erfolgloser Überprüfung wird die Aushandlung der VPN-Transportverbindung
durch dieses Modul abgebrochen.
3.3.2 Firewall
Das Modul Firewall beschränkt die Zugriffe auf Netzwerkressourcen unter Verwendung statischer Filterregeln. Dies betrifft Zugriffe sowohl aus dem unsicheren Transportnetz, als auch der mobilen Endgeräte mit bestehender VPN-Verbindung. Zusätzliche dynamische Filterregeln erlauben es, den Zugriff mobiler Endgeräte auf
Netzwerkressourcen für das Modul Trusted Network Connect anzupassen.
3.3.3 Authentisierung, Autorisierung und Accounting (AAA)
Das Untermodul Authentisierung überprüft die durch das Modul VPN übergebene Benutzeridentität gegen einen externen Verzeichnisdienst im lokalen LAN. Dies
entspricht dem Konzept einer zentralen Benutzerverwaltung. Das Ergebnis dieser
Überprüfung wird an das Modul VPN zurückgegeben.
Das Modul Autorisierung veranlasst nach erfolgreicher Authentisierung die Vergabe
einer IP-Adresse für den Endpunkt der VPN-Verbindung auf Seiten des mobilen
Endgerätes. Zusätzlich wird für diesen Client eine dynamische Filterregel durch das
Modul Firewall, für den Trusted Network Connect in Abhängigkeit von der Benutzeridentität und vergebener IP-Adresse, gesetzt.
Das Modul Accounting protokolliert Verbindungsinformationen, wie Online- oder
Offline-Status für jede Benutzeridentität auf der Basis von Logdateien. Die Logdateien werden an zentraler Stelle auf einem nichtflüchtigen Speichermedium abgelegt.
3.3.4 Trusted Network Connect (TNC)
Für den Trusted Network Connect werden sowohl auf dem Server, als auch auf dem
Client Funktionen benötigt.
Seite 39
Server
Das Mobile Security Gateway stellt für das Modul Trusted Network Connect (siehe
Abbildung 3.3) folgende Funktionen zur Verfügung:
• Umleiten der VPN-Verbindung in ein gesichertes Segment (Quarantäne)
Das Umleiten der VPN-Verbindung in das Quarantäne-Segment geschieht
mit Hilfe der Authentifizierung des Benutzers; falls der spezielle Benutzer
(hier in dem Prototyp der Benutzer pcpatch) sich anmeldet, wird über den
Radius-Server eine Firewall-Regel erstellt. Diese Regel leitet alle Pakete in die
Quarantäne-Zone um, so dass nur Softwareupdates und eine Sicherheitsüberprüfung durchgeführt werden können.
• Filterregeln für PDAs, MDAs und iPAQs
Das Mobile Security Gateway erkennt anhand der Benutzerkennung die VPNEinwahl von PDAs, MDAs und iPAQs. Für diese Geräte wird keine Sicherheitsüberprüfung (wegen eines nicht realisierten VPN-Moduls für diese Geräte) durchgeführt. Es werden automatisch Filterregeln aktiviert, die nur Zugriffe
auf E-Mails ü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 enthält alle relevanten Informationen für die Sicherheitsüberprüfung und wird von dem Modul VPN des Notebooks ausgelesen.
Notebooks
Der Trusted Network Connect (siehe Abbildung 3.3) wird über eine spezielles
Modul (VPN) realisiert. Dieses Modul startet eine VPN-Einwahl (VPN-speziell)
mit den folgenden Funktionen:
• Durchführung relevanter Updates (Software und Signaturen für Virenscanner).
• Sicherheitsüberprüfung für den Netzzugang.
Seite 40
Bei erfolgreicher Sicherheitsüberprüfung wird der mobile Mitarbeiter ü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 Endgeräte über eine Firewall-Regel in das lokale
LAN des Unternehmens weiter geleitet. Die Firewall-Regel erlaubt lediglich Zugriffe
auf E-Mails über SMTP, POP3 oder IMAP.
Abbildung 3.3: Modul Trusted Network Connect
Seite 41
3.3.5 Distributionssoftwareverteilung
Softwarepakete
Für die Client-Softwareverteilung (siehe Abbildung 3.4) stellt das Modul File Share
auf dem Mobile Security Gateway ein Laufwerk zur Verfügung. Auf dieses Laufwerk
greift der Client mit dem Modul Script-Processing zu und fü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
Für eine Neuinstallation des Client-Betriebssystems werden auf dem Mobile Security
Gateway zusätzlich folgende Module benötigt:
• DHCP-Server (Vergabe der Netzinformationen)
• TFTP-Server (Starten und übertragen eines Boot-Images)
• Betriebsysteminstallation
Die Client-Betriebssysteminstallation kann entweder über PXE-Boot (siehe Abbildung 3.5) oder über eine Boot-CD (siehe Abbildung 3.6) gestartet werden.
Nach Abschluss der Installation wird mit der Softwareverteilung des Clients fortgefahren.
Seite 42
Abbildung 3.5: Client-Betriebssysteminstallation über PXE-Boot
Abbildung 3.6: Client-Betriebssysteminstallation über Boot-CD
Seite 43
Kapitel 4 - Prototypische Realisierung
4 Prototypische Realisierung
4.1 Voraussetzungen im Unternehmensnetz
Folgende Voraussetzungen müssen in dem Unternehmensnetz geschaffen werden,
damit die hier vorgestellte prototypische Lö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 über den PDC.
Die hier vorgestellte Lö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
Für die Namensauflösung von Endgeräten der mobilen Mitarbeiter ist ein Domain Name Server (DNS) notwendig; häufig ist auf dem PDC der DNS-Dienst
integriert.
• DHCP-Server
Für eine mögliche Installation eines Clients über PXE-Boot muss der neue
Server (Mobile Security Gateway) als DHCP-Server fungieren. Ist dies nicht
möglich, kann eine PXE-Boot-Installation nicht durchgeführt werden; alternativ kann der Client mit Hilfe einer Boot-CD installiert werden.
Auf dem DHCP-Server ist ein IP-Bereich für die Einwahl der mobilen Mitarbeiter auszuklammern.
• Mobile Security Gateway
Für die Einwahl und Authentifizierung der mobilen Mitarbeiter ist es notwendig, den neuen Mobile Security Gateway Server möglichst nah an die Internetanbindung aufzustellen und diesen Server mit in die Domäne aufzunehmen.
Seite 44
Zusätzlich ist für den TNC ein neuer Benutzer (pcpatch) auf dem PDC anzulegen.
4.2 Systemarchitektur des Prototypen
4.2.1 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 enthält drei Netzwerkschnittstellen:
– eth0:
Diese Schnittstelle ist an ein gedachtes öffentliches Netzwerk angeschlossen. Um die Testumgebung möglichst realitä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 verfügt über eine Verbindung zum Internet. Diese ist
nötig, damit eine Online-Installation sowohl des Debian-Betriebssystems
als auch der im Rahmen der Realisierung benötigen Software-Pakete erfolgen kann. Weiterhin simuliert das Mobile Security Gateway das StandardGateway fü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 repräsentiert. Client1 besitzt zwei Netzwerkschnittstellen für die drahtlose und drahtgebundene
Kommunikation
• PDA:
Der verwendete PDA ist das Modell iPAQ hw6910/hw6915 →[URL:11] der
Seite 45
Firma Hewlett Packard. Dieses Modell ist ein so genanntes Smartphone. Geboten werden unterschiedliche Arten der Netzwerkkonnektivität, wobei in dieser
Realisierung die Netzwerkanbindung über Wireless LAN, nach dem Standard
802.11b, erfolgt. Die übrigen Möglichkeiten der Netzwerkanbindung konnten
nicht getestet werden, da keine entsprechenden Zugriffspunkte für den Versuchsaufbau verfügbar waren.
Abbildung 4.1: Übersicht Systemarchitektur
4.2.2 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) benötigt (Installationsanleitung siehe Anhang A).
• Primary Domain Controller:
Auf diesem System wird der Verzeichnisdienst Active Directory unter Windows
2000 Server oder Windows 2003 Server ausgeführt (Installationsanleitungen
siehe Anhang A). Die Realisierung konnte als Ganzes mit beiden Betriebssystemen erfolgreich getestet werden.
• Client-1:
Für diese Maschine wird als Betriebssystem Windows XP oder Windows 2000
Seite 46
verwendet. Die Installation dieser Betriebssystems erfolgt mit Hilfe der Distributionssoftwareverteilung via PXE-Boot. Da für diese Arbeit nicht genügend
Hardware (ein weiterer PC) zur Verfügung stand, wurde dieser Client zusätzlich als Client-Referenzsystem verwendet. Aus diesem Grund wurde zusätzlich
das Script-Paket AutoIT in der Version 3 installiert.
• PDA:
Auf diesem Gerät ist werksseitig das Betriebssystem Windows Mobile 5.0 installiert.
Seite 47
4.3 Implementierung VPN-Server
Die Funktionalitä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 benötigt:
1. Openswan, Version 2.2.0-8 (Debian stable)
2. l2tpd, 0.70-pre20031121-2.2 (Debian testing)
3. ppp, Version 2.4.4 (Debian testing)
4. radiusclient1, Version 0.3.2-11 (Debian testing)
Die ersten drei Pakete realisieren den benötigten Protokollstack (siehe auch Abbildung 4.2): Openswan implementiert das IPSec-Protokoll. Das Paket l2tpd implementiert das Layer-2 Tunneling Protocol. Für die Realisierung des PPP-Protokolls
ist das Paket ppp zuständig.
Abbildung 4.2: Realisierung des IPSec-L2TP-PPP Protokollstacks unter Linux
4.3.1 openswan
Die Voraussetzung für den Betrieb von IPSec setzt die Unterstützung durch den
Linux-Kernel voraus. Die in der Debian-Distribution enthaltenen Kernel erfüllen
diese Voraussetzung bereits.
Seite 48
Die IPSec-Konfiguration spezifiziert einen Ende-Zu-Ende Tunnel zwischen dem mobilen Endgerät und dem Openswan-Server auf dem Mobile Security Gateway. Sobald
diese Verbindung besteht, initiiert das mobile Endgerät eine Verbindung zum L2TPServer auf dem Mobile Security Gateway.
Openswan unterstützt die Authentisierung sowohl mit Zertifikaten als auch mit Preshared Keys. Da die Konfiguration von IPSec sehr komplex ausfallen kann, wurden
für die prototypische Realisierung der IPSec-Implementierung Pre-Shared-Keys als
Basis für die maschinenbezogene Authentisierung aller Clients gewählt. Diese Art
der maschinenbezogenen Authentisierung ist nicht die sicherste, deshalb sollte für
einen späteren produktiven Einsatz die Verwendung von Zertifikaten in Erwägung
gezogen werden. Die hier verwendete Konfiguration entspricht einer leicht modifizierten Version, die hier →[DELE07] (Abschnitt 10.1.1) vorgestellt wurde.
4.3.2 l2tpd
Das Layer-2 Tunneling Protocol (L2TP) erfüllt im Rahmen dieser Realisierung keine
Sicherungsfunktionen. Diese sind auch nicht notwendig, da die VPN-Eigenschaften
Vertraulichkeit, Integrität und Authentizitä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 übergibt nach dem Aufbau einer L2TP-Verbindung die Kontrolle
der Verbindung selbstständig an den PPP-Daemon.
4.3.3 ppp und radiusclient1
Die PPP-Implementierung ppp, in Kombination mit dem Paket radiusclient1 stellt
den Network Access Server (NAS) im Sinne von AAA dar. Über die LCPErweiterungen 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 RADIUSServer vergebenen IP-Adresse. Das Plugin radius.so, enthalten im Paket ppp und das
Paket radiusclient1 kommunizieren über eine gemeinsame Schnittstelle. Das Plugin
hat dabei direkten Einfluss auf die Verbindungssteuerung der PPP-Implementierung.
Für jede PPP-Verbindung erscheint unter Linux ein entsprechendes virtuelles PPPDevice mit der durch den AAA-Server zugewiesenen IP-Adresse als entfernter Tunnelendpunkt. Anhand der IP-Adresse ist eine unabhängige Paketfilterung mittels
Seite 49
Firewall für jede VPN-Verbindung möglich.
Die Konfiguration dieser Pakete basiert auf einem HowTo ü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-Lösung fü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
Lösung mit IPSec/L2TP übertragen, indem statt PPTP das normale PPP-Protokoll
verwendet wurde.
Seite 50
4.4 Implementierung Firewall
4.4.1 Einleitung
Für die Realisierung der Firewall-Funktionen kommt der unter Linux verfügbare
Paketfilter IPTables →[URL:15] zum Einsatz (Installationsanleitung siehe Anhang
A). Die Firewall erfüllt folgende Funktionen:
• Zugriffsbeschränkung von außen:
Aus dem nicht vertrauenswürdigen Netzwerk (dem Internet) ist lediglich der
Zugriff auf den IPSec-Dienst möglich, um den mobilen Mitarbeitern die VPNEinwahl zu gestatten.
• Zugriffsbeschrä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 Endgeräte
benutzerabhängig eingeschränkt. Auf diese Weise wird einerseits die Quarantänezone für die mobilen Endgeräte während der Sicherheitsüberprüfung realisiert. Andererseits wird dadurch erreicht, dass mobile Endgeräte nach erfolgreicher Sicherheitsüberprü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 über Arbeitsstationen im lokalen LAN erfolgen kann.
4.4.2 Quarantänezone
Für die Sicherheitsüberprüfung und Softwareupdates benötigt das mobile Endgerä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
Endgerät möglich sein, einen Ping an das Mobile Security Gateway abzusetzen,
da die korrekte Funktion der Softwareversorgung davon abhängt. Daraus lassen
sich direkt die Zugriffsrechte der mobilen Endgeräte innerhalb der Quarantänezone
ableiten:
• Der Zugriff darf nur lokal auf das Mobile Security Gateway erfolgen.
• Es ist lediglich das Verwenden der benötigten Protokolle CIFS (Port: 445/TCP), Netbios Name Service (Port: 137/UDP) und ICMP möglich. Die übrigen
Seite 51
Dienste auf dem Mobile Security Gateway sind vor Zugriffen der mobilen Endgeräte zu schützen.
4.4.3 Statische Filterregeln
Die statischen Filterregeln wurden über ein Shell-Skript definiert. Während des Systemstarts wird das Skript automatisch abgearbeitet und ermö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 fü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 können (Stateful Packet Inspection).
• Über die lokale Maschine (Mobile Security Gateway) zu routende Pakete sind
zu verwerfen. Ausgenommen sind auch hier Antwortpakete, die bestehenden
Verbindungen zugeordnet werden können.
• Ausgehende Pakete der lokalen Maschine sind erlaubt.
Schnittstellenabhängige Filterregeln
Die statischen Filterregeln behandeln den Datenfluss in Abhängigkeit der verwendeten Netzwerkschnittstelle. Im Folgenden sind unterschiedliche Filterregeln für
jede relevante Netzwerkschnittstelle definiert:
• Loopback-Interface (lo):
Die Definition der generellen Filterregeln unterbindet auch die Kommunikation lokaler Prozesse über das Loopback-Interface. Von dem Loopback-Interface
eingehende Datenpakete müssen daher akzeptiert werden.
Seite 52
• Internet-Schnittstelle (eth0):
Von dieser Schnittstelle werden, mit Ausnahme der für den Betrieb von IPSec
erforderlichen Protokolle, alle eingehenden und zu routenden Pakete verworfen.
• LAN-Schnittstelle (eth1):
Datenverkehr von dieser Schnittstelle unterliegt keiner Beschränkung, das
heißt, eingehende und zu routende Datenpakete werden akzeptiert.
• Einwahl-Schnittstellen (pppX):
Datenverkehr von diesen Schnittstellen (der VPN-Endpunkte) unterliegt
unterschiedlichen Zugriffsbeschränkungen, die benutzerabhängig sind. Diese
Zugriffsbeschränkungen werden durch dynamische Filterregeln während der
VPN-Einwahl realisiert. Der Datenverkehr von diesen Schnittstellen wird
daher nicht statisch gefiltert, sondern zunächst in zwei benutzerdefinierte
Filterlisten umgeleitet:
– Filterliste vpn in für eingehende Datenpakete (in die Quarantänezone)
– Filterliste vpn fwd für zu routende Datenpakete (in das lokale LAN)
4.4.4 Dynamische Filterregeln
Die benutzerabhängige Filterung des Datenverkehrs wird durch ein Shell-Skript
ermöglicht, welches der AAA-Server selbstständig anstößt wenn ein VPN-Benutzer
erfolgreich authentisiert wurde oder die VPN-Verbindung terminiert. Das Skript
verarbeitet drei Argumente:
1. Aktion:
Dieses Argument hat drei Ausprä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
Endgeräte akzeptiert. Diese Aktion wird einmal, während der Erstellung der
statischen Filterregeln, ausgeführt.
Start: dient dem Hinzufügen einer Filterregel.
Stop: dient der Lö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
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 Ausprägung einer konkreten Filterregel. Bei Beendigung einer VPNVerbindung wird die zu lö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
4.5 Implementierung AAA
Die Realisierung des AAA-Servers erfolgt durch die Software Freeradius →[URL:06].
Die erste Version wurde im Jahr 1999 veröffentlicht und seitdem ständig weiterentwickelt. Neben dem ursprünglichen RADIUS-Protokoll werden auch herstellerspezifische Erweiterungen unterstützt. Dadurch wird es beispielsweise ermöglicht, das
CHAP-Protokoll mit den von Microsoft spezifizierten Erweiterungen, als MS-CHAP
bezeichnet, fü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 benötigt:
• Freeradius, Version 1.1.3-3 (Debian Testing)
• Samba, Version 3.0.24 (Debian Testing)
• krb5-user, Version 1.4.4-6 (Debian Testing)
Damit Freeradius die Authentisierung der Benutzer gegen den Verzeichnisdienst Active Directory vornehmen kann, sind zusätzliche Vorbereitungen nötig: Freeradius
kann nicht direkt auf den Active Directory Verzeichnisdienst zugreifen. Stattdessen verwendet Freeradius wä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 Rückgabewerte
zu erzeugen. Anhand der Rückgabewerte entscheidet Freeradius über den Status der
Authentisierung eines Benutzers.
Vorbereitungen
Das Mobile Security Gateway ist in die Windows-Domä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 ermö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 ZusammSeite 55
menarbeit mit Winbind. Es ermöglicht die Verifikation von Benutzern auf dem
Windows-Domänencontroller und gibt bei Aufruf entweder eine Erfolgs- oder
eine Fehlermeldung zurü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-Domäne erfolgt generell durch Anlegen eines Computerkontos auf dem Active Directory Domänencontroller. Dies geschieht mit Hilfe der im Paket Samba enthaltenen Werkzeuge. Diese
erlauben es, den Active Directory Domänencontroller in Grenzen zu konfigurieren.
Es können zum Beispiel auch normale Benutzer hinzugefügt, geändert oder gelöscht
werden. Da Active Directory das Kerberos-Protokoll für die Authentisierung verwendet, ist eine Minimalkonfiguration des Mobile Security Gateways als KerberosClient, mit Hilfe des Paketes krb5-user, unumgänglich. Auf dem Domänencontroller
selbst sind zusätzlich weder Einstellungen noch Software nötig.
Ablauf der Authentisierung
Wenn sich ein Benutzer per VPN einwählt, erhält der RADIUS-Server eine AccessRequest-Nachricht (Abbildung 4.4). Aus dieser werden die notwendigen Daten zur
Authentisierung extrahiert, übersetzt und anschließend an das externe Programm
ntlm auth übergeben. Der folgende Auszug zeigt die erfolgreiche Verifikation des
Benutzers pcpatch; ntlm auth erzeugt den Rückgabewert null.
Kann der Benutzer nicht erfolgreich verifiziert werden, liefert ntlm auth eine Fehlermeldung, die dazu führt, dass der RADIUS-Server eine Access-Reject-Nachricht
an den VPN-Server sendet. Dieser trennt darauf hin die Verbindung zum Client.
Seite 56
rad_recv: Access-Request packet from host 127.0.0.1:32768, id=162, length=135
Service-Type = Framed-User
User-Name = "pcpatch"
MS-CHAP-Challenge = 0x8d7be22aff2dfa7f71901a2db3cdeec6
MS-CHAP2-Response = 0xf300773a62435f53df283 (gekürzt)
NAS-IP-Address = 127.0.0.1
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=124e057b53895bfd6741649a693ed5c948426914782124a9
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
4.5.2 Autorisierung
Nach der erfolgreichen Authentisierung eines VPN-Benutzers wird dem entsprechenden mobilen Endgerät eine IP-Adresse aus einem reservierten Bereich des
lokalen LANs zugewiesen. Die IP-Adresse wird als zusätzliches RADIUS-Attribut
der Access-Accept-Nachricht hinzugefügt (Abbildung 4.5).
Anschließend stößt der RADIUS-Server ein externes Skript an, und übergibt diesem
zwei RADIUS-Attribute: den Namen des Benutzers sowie die soeben zugewiesene
IP-Adresse. Dieses externe Skript legt darauf hin eine dynamische Filterregel für
den mobilen Client an.
rlm_ippool: Allocated ip 192.168.1.146 to client on nas 127.0.0.1,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 127.0.0.1 port 32768
Framed-Protocol == PPP
MS-CHAP2-Success = 0xf3533d3138303 (gekürzt)
MS-MPPE-Recv-Key = 0xc8abbd8759976bffe15444a0dd42c59d
MS-MPPE-Send-Key = 0xc12a700153757e700709a181ec53e311
MS-MPPE-Encryption-Policy = 0x00000002
MS-MPPE-Encryption-Types = 0x00000004
Framed-IP-Netmask = 255.255.255.255
Finished request 0
Abbildung 4.5: Beispiel einer Access-Accept-Nachricht
Seite 57
4.5.3 Accounting
Der RADIUS-Server erhä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 AccountingVerzeichnis nach folgender Struktur organisiert:
/var/log/freeradius/radacct/Benutzername/detail-JJJJMMTT
Somit werden die Aktivitäten eines Benutzers in einer täglichen Übersicht zusammengefasst. Die folgenden Auszüge (Abbildung 4.6 und 4.7) zeigen beispielhaft
die durch den RADIUS-Server aufgezeichneten Accounting-Nachrichten für den
Benutzer pcpatch“ in verkürzter Form:
”
Thu Apr
5 12:33:40 2007
Acct-Session-Id = "4614D084562A00"
Acct-Status-Type = Start
NAS-Port = 0
Acct-Unique-Session-Id = "3b19040a9345401f"
Timestamp = 1175769220
Abbildung 4.6: Beispiel einer Accounting-Start-Nachricht
Thu Apr
5 13:45:46 2007
Acct-Session-Id = "4614D084562A00"
Acct-Status-Type = Stop
Acct-Session-Time = 4326
Acct-Output-Octets = 33
Acct-Input-Octets = 12408
Acct-Output-Packets = 2
Acct-Input-Packets = 124
Acct-Terminate-Cause = User-Request
NAS-Port = 0
Acct-Unique-Session-Id = "3b19040a9345401f"
Timestamp = 1175773546
Abbildung 4.7: Beispiel einer Accounting-Stop-Nachricht
Die Accounting-Stop-Nachricht enthält zusätzliche Statusinformationen bezüglich
Verbindungsdauer, übertragenem Datenvolumen sowie dem Grund der Verbindungstrennung.
Als Erweiterung dieser Lösung wäre es sinnvoll, die gesammelten Daten einer
Auswertung zu unterziehen. Dabei sind zum Beispiel die folgenden Kriterien
Seite 58
denkbar:
• Auswertung nach Login-Zeiten:
Dies ermöglicht dem Administrator beispielsweise, Zugänge auf Mißbrauch zu
überwachen (Feststellung ungewöhnlicher Anmeldezeiten)
• Auswertung nach Datenvolumen:
Dadurch kann der Administrator beispielsweise die Auslastung der Zugänge
einschätzen, aber auch Mißbrauch feststellen, wenn ein Benutzer in einem
bestimmten Zeitraum ein ungewöhnlich hohes Datenvolumen beansprucht.
Anhand dieser Kriterien kann der Administrator entsprechende Maßnahmen ergreifen, zum Beispiel Zeitfenster für die Einwahl definieren oder Benutzer sperren. Es
wäre auch denkbar, die Sperrung eines Benutzerkontos nach einer bestimmten Anzahl fehlgeschlagener Anmeldeversuche in einem definierten Zeitraum automatisch
zu veranlassen.
Seite 59
4.6 Implementierung Distributionssoftwareverteilung
Fü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 für eine Landesverwaltung und ist
seitdem auf über 2000 PCs produktiv im Einsatz.
Die Wahl fiel auf dieses Produkt, da eine langjährige Erfahrung des Unternehmens
mit diesem Produkt besteht, dieses Produkt weiter entwickelt wird, ein umfangreiches Forum zur Verfügung steht und gegebenenfalls Unterstützung bei Problemen
durch das Unternehmen eingekauft werden kann.
Die Software hat Funktionen einer automatischen Softwareverteilung auf PCs und
die Mö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
verfügbar. Aus diesem Grunde kommt die stabile Version 2.5 zum Einsatz.
4.6.1 Server
Der opsi-depotserver stellt die Komponenten für die automatische Softwareverteilung und Betriebssysteminstallation zur Verfügung. Die Software basiert auf Debian
GNU/Linux als Server, um eine hohe Verfügbarkeit und Stabilität zu gewährleisten.
Der Server basiert auf einem File Share (realisiert mit Samba) und stellt weitere
Dienste (DHCP, BOOTP und TFTP) für eine automatische Installation von Softwarepaketen oder Betriebs Eine Installationsanleitung des opsi-depotservers, sowie
Anpassungen für diese prototypische Realisierung der mobilen Infrastruktur sind im
Anhang A) zu finden.
4.6.2 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 überprüft nach jedem Boot und vor einem Login des Users
anhand von Konfigurationsdateien auf einem File Share, ob relevante Updates für
den Client zur Verfügung stehen. Bei einem vorhandenem Update wird das InstalSeite 60
lationsprogramm Winst aufgerufen, welches die Installation der notwendigen Programme durchführt.
Die Komponente opsi-Winst ist ein Interpreter für eine einfache Script-Sprache,
mit der Installationen von Programmen durchgeführt werden können. Der Interpreter unterstützt dabei die folgenden Vorteile gegenüber einer Installation mit
Commandshell-Aufrufen:
• Der Ablauf der Installation wird protokolliert.
• Kopieraktionen können differenziert werden (welche Dateien und inwieweit
schon vorhandene Dateien überschrieben werden sollen)
• Systemdateien können vor dem Überschreiben auf ihre interne Version überprüft werden.
• Manipulationen der Windows-Registry sind möglich.
Eine ausführliche Syntax der unterstützten Befehle und Funktionen des Interpreters,
sowie der Aufbau des opsi-Winst-Scriptes sind im Anhang A zu finden.
4.6.3 Erweiterung für den TNC
Für die Realisierung des Trusted Network Connects und der integrierten Sicherheitsüberprüfung, muss eine Client-Referenzliste auf dem Server hinterlegt werden. Diese
Referenzliste enthä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 Integritä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 Integritä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 Sicherheitsüberprü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
Clients ihre Informationen über die installierten Softwarepakete eintragen.
Nach jedem Hinzufügen eines Paketes für die Distributionssoftwareverteilung ist das
Attribut des Paketes in der Referenzliste von Hand anzupassen. In Abbildung 4.8
ist ein Beispiel der Referenzliste aufgeführt:
; Hinweis: Diese Datei enthaelt alle Produkteintragungen, die auf einem Client
;
installiert sein muessen, damit der Client sich über TNC
;
einwählen und arbeiten darf.
;
; Syntax: on
= Paket muss installiert sein
;
off
= Paket muss deinstalliert sein (wg. evtl. Sicherheitslü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 für den TNC
4.6.4 Erstellen von Paketen
Die Erstellung von Paketen ist in dem Opsi Integrations Handbuch →[URL:19] (Abschnitt 5.2) detailliert beschrieben. Diese Vorgehensweise ist für alle Pakete gleich.
Der einzige Unterschied sind die Installationsdateien des Softwarepaketes in dem
Ordner files und die selbst erstellten Installations- und Deinstallationsroutinen für
den Interpreter Winst. Ausführliche Informationen ü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 4.1.2 vom 12.05.2006. Dieses Programm erwartet bei der Installation
Eingaben des Users, um die Installation und Konfiguration durchführen zu können.
Damit eine Silent Installation inklusive Konfiguration des Programms durchgeführt
werden kann, wird nachfolgend dargestellt, wie die benötigten zusätzlichen Dateien
generiert werden können. Mit diesen Dateien kann eine neue Installationsroutine für
den Interpreter Winst programmiert werden:
1. Ausführen der Installation von RealVNC Version 4.1.2 mit einem zusätzlichem
Parameter für das Erstellen einer Konfigurationsdatei auf dem Client Referenzsystem (es wird nur der VNC-Dienst installiert):
Seite 62
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 Startmenü
hinterlegt werden, muss der Parameter NoIcons=0 in der Datei vnc.inf auf
NoIcons=1 geändert werden.
4. Nach der Installation von VNC sind alle Konfigurationen wie Passwort, erlaubte Oberfläche, Ports, Freigabe der Ports in der Windows XP Firewall, etc.
durchzuführen. Diese Konfiguration muss nun von Hand aus der Registry des
Client Referenzsystems in eine Datei (z.B. insvnc.reg) exportiert werden. Die
Schlü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]
StandardProfile\GloballyOpenPorts\List]
Seite 63
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:00000000
"QueryOnlyIfLoggedOn"=dword:00000000
"PortNumber"=dword:0000170c
"IdleTimeout"=dword:00000e10
"HTTPPortNumber"=dword:00000000
"LocalHost"=dword:00000000
"Hosts"="+,"
"AcceptKeyEvents"=dword:00000001
"AcceptPointerEvents"=dword:00000001
"AcceptCutText"=dword:00000001
" SendCutText"=dword:00000001
"DisableLocalInputs"=dword:00000000
"DisconnectClients"=dword:00000001
"AlwaysShared"=dword:00000000
"NeverShared"=dword:00000000
"DisconnectAction"="None"
"RemoveWallpaper"=dword:00000001
"RemovePattern"=dword:00000001
"DisableEffects"=dword:00000001
"UpdateMethod"=dword:00000001
"PollConsoleWindows"=dword:00000001
"UseCaptureBlt"=dword:00000001
"UseHooks"=dword:00000001
"Protocol3.3"=dword:00000000
"5900:TCP"="5900:TCP:*:Enabled:VNC"
"5900:TCP"="5900:TCP:*:Enabled:VNC"
5. Analog dazu nachfolgend die Datei delvnc.reg, die benötigt wird, falls das Produkt wieder deinstalliert werden soll:
Windows Registry Editor Version 5.00
[-HKEY_LOCAL_MACHINE\SOFTWARE\RealVNC]
"5900:TCP"=[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\
"5900:TCP"=-
6. Zu diesem Zeitpunkt sind alle benötigten Dateien für die Installation von
RealVNC generiert worden. Nun fehlen nur noch das Installationsscript für
Winst, welches die Silent Installation aufruft und danach automatisch die
Registry-Einträge auf dem Client einträgt:
Seite 64
[Initial]
Message=Installiere Fernwartung RealVNC Release 4.1.2
;Erstellt am 23.02.2007 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 genünd Platz auf C: . 5 MB auf C: für RealVNC Release 4.1.2 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
7. Abschließend folgt das Deinstallationsscript:
[Initial]
Message=Deinstallation Fernwartung RealVNC Release 4.1.2
......
;Erstellt am 23.02.2007 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 genügend Platz auf C fü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
Die Installations- und Deinstallationsscripte der Pakete ähneln einander sehr, da
für gleiche Methoden der Installation auch meistens die gleichen Scripte genutzt
werden können.
Zu beachten ist, dass jede Teilinstallation in dem Winst-Script zu überprü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 für die folgenden erstellten Pakete für
die opsi Softwareverteilung aufgeführt:
• Windows XP Professional Patches (Stand: 13.03.2007)
• Windows 2000 Service Pack 4
• Adobe Acrobat Reader Version 7.0.9
• Microsoft Office Professonal 2007 (Evaluierung)
• RealVNC Version 4.1.2
• Trusted Network Connect
Seite 67
4.7 Implementierung Trusted Network Connect (TNC)
In diesem Kapitel ist die prototypische Realisierung des Trusted Network Connects
mit den einzelnen Komponenten dargestellt.
4.7.1 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 für die Zugriffsberechtigung realisiert.
• VPN-Gateway
Das VPN-Gateway besteht aus mehreren Untermodulen:
Seite 68
– Openswan
Openswan ist die IPSec-Implementierung, damit die Einwahl über IPSec
realisiert werden kann.
– l2tpd
L2TPD ermöglicht das Layer 2 Tunnel Protokoll für die Einwahl.
– ppp
PPP wird für die Übertragung (Microsoft VPN-Stack) benötigt.
– radiusclient1
Der RADIUS-Client stellt die Anfrage an den PDP, um die Netzwerkzugriffe der Clients in geeigneter Weise zu beschrä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 für den Trusted Network Connect her, zusä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 ü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 ermöglicht die Überprüfung
und einen Integritätstest auf dem Client.
• Network Access Requestor
Der Network Access Requestor wird durch zwei VPN-Verbindungen auf dem
AR abgebildet.
Seite 69
Interfaces
Die in diesem Prototyp benutzten Schnittstellen sind die gleichen, wie in der TNCArchitektur 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 Änderung der Schnittstelle
IMV in Integrity Measurements (IM). Diese Umbenennung ist sinnvoll, da keine
IMVs in diesem Prototyp genutzt werden, sondern nur IMs für den Integritätstest
(TNC Client) zur Verfügung gestellt werden.
Die Aufgabe der Komponente IMC ist in den eigens für dieses Projekt erstellten
Prototyp (TNC Client) integriert worden.
4.7.2 Workflow prototypische TNC-Realisierung
Nachfolgend ist das Zusammenwirken der einzelnen Komponenten des Trusted Network Connects detailliert (siehe Abbildung 4.10) dargestellt:
• Punkt 0:
Voraussetzung für die Initiierung des Trusted Network Connects ist das
Vorhandensein des TNC Clients sowie die Konfiguration der beiden VPNVerbindungen 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
Überprüfung der Authentisierung findet dann zwischen dem AR und dem NAA
statt.
• Punkt 3:
Bei einer erfolgreichen Authentisierung informiert der NAA den TNC Server
über den Versuch des Verbindungsaufbaus.
• Punkt 4:
Anhand der Authentisierung des ARs beschränkt der NAA die Zugriffsrechte
des ARs über den PEP, das heißt Zugriffe des ARs werden automatisch nur
auf die Quarantänezone beschränkt.
Seite 70
• 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 benötigten Informationen für die Softwareupdates von den
IMs.
• Punkt 6A:
Der TNCC initiiert führt jetzt den Integritätstest des ARs durch. Der Austausch der Informationen wird ebenfalls durch den NAR, PEP und NAA geleitet.
• Punkt 6B:
Der TNCS holt alle benötigten Informationen für den Integritätstest von den
IMs.
• Punkt 7:
Nach erfolgreichem Integritätstest wird die bestehende VPN-Verbindung des
NAR beendet und eine neue VPN-Verbindung für die normale Einwahl des AR
über den NAR gestartet. Der Zugriff der zweiten Verbindung wird durch den
NAA autorisiert und nicht weiter beschränkt.
Scheitert der Integritätstest, wird keine zweite VPN-Verbindung gestartet; somit kann sich der AR nicht einwählen.
Die Idee dieses Konzeptes ist, dass nach jedem positiven Ergebnis der Sicherheitsüberprü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 Verfügung stehen könnten.
Seite 71
Abbildung 4.10: Workflow prototypische TNC-Realisierung
4.7.3 Prototyp TNC Client
Der Trusted Network Connect wird über ein eigens programmierten Software-Client
(Prototyp) realisiert. Dieser Prototyp wurde mit der Script-Sprache AutoIT in der
Version 3.2.0.0 geschrieben. Diese Script-Sprache ist der Programmiersprache Visual
Basic sehr ähnlich und damit gegebenenfalls auch auf andere Systeme (Programmiersprachen) sehr einfach zu portieren.
Dieses Script benötigt für den Ablauf zwei VPN-Profile (Profil 1: Softwareverteilung,
Profil 2: Unternehmen), die auf dem Client mit Administrationsrechten hinterlegt
sein müssen (Installationsanleitung siehe Anhang A). Die Hinterlegung mit Administrationsrechten ist sehr wichtig, damit der Benutzer nicht die Möglichkeit hat, die
VPN-Einwahl manuell zu starten.
In dem Source Code (siehe Anhang A) des Programms sind Variablen hinterlegt,
um Passwörter und Benutzernamen für die Administrationsrechte des Clients zu
hinterlegen. Diese Passwörter und Benutzernamen werden mit dem Kompilieren des
Source Codes verschleiert und verschlüsselt.
Funktionen des Programms
Das Programm ist modular aufgebaut wobei jedes Modul einer Funktion in dem
Programm entspricht und somit auch für zusätzliche Zwecke einfach erweiterbar ist.
Nachfolgend sind die Funktionen aufgelistet:
Seite 72
• Func initialisierung ()
Diese Funktion setzt den Registrierungs-Schlüssel mit Start des Programms
zurück, das heißt der Status des Integritä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 kö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 führt
den Integritä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 Sicherheitsüberprüfung (z.B. MAC-Adresse der Netzwerkkarte oder Hardwareausstattung) berücksichtigen, mö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 einwählen kann. Zugriffsrechte werden hier nicht mehr
beschränkt, da die Einwahl nur nach erfolgreichem Integritätstest gestartet
wird. Die einzige mögliche Beschränkung des Zugriffs kann noch von der
Benutzerverwaltung (PDC) kommen. Diese Beschränkungen beziehen sich
dann allerdings nur noch auf das lokale Netz des Unternehmens (DomänenSicherheitsrichtlinien).
Seite 73
Ablauf des Programms
Der mobile Mitarbeiter startet diesen Software-Client, um sich in das Unternehmen
ein zu wählen. In diesem Client sind alle notwendigen Parameter für den TNC hinterlegt und der mobile Mitarbeiter bekommt erst die Möglichkeit sich anzumelden,
wenn die Sicherheitsüberprü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
”
überprüft.“
2. VPN-Aufbau mit User: pcpatch
Dieser Verbindungsaufbau wird benötigt, damit die Überprüfung des Systems
durchgeführt werden kann:
• Starten der Softwareverteilung, um alle Patches und Signaturen des Virenscanners zu aktualisieren.
• Überprüfung, ob alle notwendigen Pakete und Patches installiert wurden.
Die Überprü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 Domä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
Abbildung 4.11: Ablauf Trusted Network Connect
Fehler-Codes / LOG-Dateien
Der TNC Client protokolliert den Ablauf der Sicherheitsüberprüfung auf dem
TNC Server in LOG-Dateien. Diese LOG-Dateien (siehe Beispiele Auszug 4.12 und
Seite 75
Auszug 4.13) geben dem Systemadministrator die Möglichkeit einer Fehleranalyse;
zusätzlich werden Fehler-Codes des TNC Clients sichtbar für den Benutzer ausgegeben. Die Fehler-Codes sind in Tabelle 4.1 hinterlegt.
2007-03-01
2007-03-01
2007-03-01
2007-03-01
2007-03-01
2007-03-01
2007-03-01
2007-03-01
2007-03-01
2007-03-01
12:19:47
12:19:47
12:19:47
12:19:47
12:19:47
12:19:47
12:19:47
12:19:47
12:19:47
12:19:47
:
:
:
:
:
:
:
:
:
:
P:\pcpatch\CLIENT-3.ini erfolgreich ausgelesen.
P:\pcpatch\security.ini erfolgreich ausgelesen.
Teste Produkt: acroread - Status: OK (soll=optional, ist=on)
Teste Produkt: office2007 - Status: OK (soll=optional, ist=off)
Teste Produkt: preloginloader - Status: OK (soll=on, ist=on)
Teste Produkt: tnc - Status: OK (soll=on, ist=on)
Teste Produkt: vnc - Status: OK (soll=on, ist=on)
Teste Produkt: win2k_sp4 - Status: OK (soll=off, ist=off)
Teste Produkt: winxp_patches - Status: OK (soll=on, ist=on)
Setze Registry Wert: HKLM\Software\opsi.org\security\berechtigung = 1
Abbildung 4.12: Beispiel Log-Datei (Integritätstest bestanden)
2007-04-05
2007-04-05
2007-04-05
2007-04-05
2007-04-05
2007-04-05
2007-04-05
2007-04-05
2007-04-05
2007-04-05
12:26:26
12:26:26
12:26:26
12:26:26
12:26:26
12:26:26
12:26:26
12:26:26
12:26:26
12:26:26
:
:
:
:
:
:
:
:
:
:
P:\pcpatch\CLIENT-1.ini erfolgreich ausgelesen.
P:\pcpatch\security.ini erfolgreich ausgelesen.
Teste Produkt: acroread - Status: OK (soll=optional, ist=on)
Teste Produkt: office2007 - Status: OK (soll=optional, ist=on)
Teste Produkt: preloginloader - Status: OK (soll=on, ist=on)
Teste Produkt: tnc - Status: OK (soll=on, ist=on)
Teste Produkt: vnc - Status: OK (soll=on, ist=on)
Teste Produkt: win2k_sp4 - Status: OK (soll=off, ist=off)
Teste Produkt: winxp_patches - Status: nicht OK (soll=on, ist=off)
Setze Registry Wert: HKLM\Software\opsi.org\security\berechtigung = 0
Abbildung 4.13: Beispiel Log-Datei (Integritätstest nicht bestanden)
Tabelle 4.1: Fehler-Codes TNC Client
Code
Fehler
0x01
Log-Datei konnte nicht geöffnet werden
0x02
PCNAME.ini konnte nicht geöffnet werden
0x03
security.ini konnte nicht gelesen werden
0x04
ungleiche Anzahl Zeilen von PCNAME.ini und security.ini
Seite 76
4.8 Implementierung Clients
4.8.1 Notebooks
Die Notebooks der mobilen Mitarbeiter eines Unternehmens werden für die interne
sowie externe Kommunikation erweitert:
• Kommunikation intern:
Für die interne Kommunikation wird auf den Clients lediglich der winst-Client
für die Softwareversorgung benö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 benötigte Client-Software
(Installationsanleitung siehe Anhang A).
• Kommunikation extern:
Für die externe Kommunikation der Mitarbeiter werden zusätzlich zu dem
winst-Client zwei VPN-Verbindungen benötigt, die von dem Administrator in
dem Client-Profil Administrator angelegt werden müssen. Die Konfiguration
dieser beiden Verbindungen erfolgt manuell (Installationsanleitung siehe Anhang A). Zusätzlich muss der TNC Client auf dem Notebook des mobilen
Mitarbeiters installiert werden. Diese Installation kann automatisch mit der
Softwareverteilung durchgeführt werden.
• Entzug der Administrationsrechte der mobilen Mitarbeiter:
Fü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 zusätzlichen Softwarepakete installieren
oder löschen. Das Installieren oder Deinstallieren der Notebooks mit zusätzlicher Software erfolgt ab diesem Zeitpunkt nur noch ü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 möglich:
• PXE-Boot:
Bietet der Client die Möglichkeit, den PC über Netzwerk zu starten, kann ein
Seite 77
minimales Image über das Netzwerk geladen werden und damit die Neuinstallation des Clients gestartet werden.
• Boot-CD:
Ist der Client nicht in der Lage, über das Netzwerk zu starten, kann er über
eine Boot-CD gestartet werden und darü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 benötigte Programme zu installieren.
Nach der Komplettinstallation ist nur noch das Anlegen der beiden VPNVerbindungen notwendig; dies kann aber über die Remoteadministrierung erledigt
werden.
Für die Verschlü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 für eine virtuelle Laufwerksverschlüsselung zur Verfügung und unterstützt alle gängigen Verschlü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 zusätzlich das Programm FreeOTFE getestet.
• FreeOTFE Version 2.00 vom 18. März 2007 (URL →[URL:05])
Dieses Programm stellt ebenfalls verschlüsselte Container für virtuelle Laufwerke zur Verfü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 4.1.2
vom 12.05.2006 (Quelle →[URL:22]) getestet. Die Installation und Konfiguration
Seite 78
des benötigten Clients wurde mit Hilfe der Softwareverteilung durchgefü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 unterstützt einen Viewer und einen Server. Diese Kombination reicht völlig
aus, um Notebooks remote zu administrieren. Eine mögliche Verschlüsselung der Verbindung durch diese Programme ist nicht notwendig, da die Remote-Administrierung
nur über die VPN-Einwahl der Notebooks oder über das lokale LAN erfolgt.
Für zusätzliche Features, wie z.B. Verschlüsselung oder einen File Transfer, wird
eine Lizenz benötigt.
Abbildung 4.14: Übersicht VNC Versionen
4.8.2 PDA/MDA/iPAQ
Zur Verschlüsselung von Daten wurde das Programm FreeOTFE4PDA in der Version 2.00 vom 18. März 2007 getestet. Dieses Programm verrichtete ohne Auffälligkeiten die Verschlüsselung von Daten mit Hilfe von Containern, jedoch sollten
alle überflüssigen Library-Dateien für nicht genutzte Verschlüsselungsalgorithmen
vor dem Programmstart gelöscht werden, da der Start des Programms sonst zur
Geduldsprobe wird.
Seite 79
Fernadministrierung
Aufgrund von fehlender Software ist es zur Zeit nicht möglich, diese Gerätegruppe
remote zu administrieren.
Seite 80
Kapitel 5 - Diskussion
5 Diskussion
5.1 VPN-Server
Durch einen Vergleich der Vor- und Nachteile für den Einsatz von OpenVPN oder
IPSec als VPN-Server wurde die Entscheidung getroffen IPSec als VPN-Server zu
nutzen, da mit OpenVPN Unzulänglichkeiten in Bezug auf die Integration in das
Systemkonzept auftraten
Nachfolgend sind unsere Überlegungen der Vor- und Nachteile von OpenVPN und
IPSec aufgeführt.
5.1.1 OpenVPN
In den Überlegungen zur Implementierung der client- und server-seitigen VPNFunktionalität fiel die Wahl zunächst auf die Software OpenVPN, auf Grund
folgender Eigenschaften (Vor- und Nachteile), siehe auch →[URL:18]:
• Lauffähig auf verschiedenen Betriebssystemen, darunter auch Windows und
Linux
• Sicherstellung der VPN-Eigenschaften Authentizität, Integrität und Vertraulichkeit durch anerkannte Verfahren (Transport Layer Security/Secure Sockets
Layer, siehe auch →[URL:16])
• Vereinfachter Konfigurationsaufwand gegenüber IPSec, sowohl client- als auch
server-seitig, denn die Konfiguration von OpenVPN erfolgt zentralisiert in einer
einzigen Konfigurationsdatei.
• Die Sicherstellung der VPN-Eigenschaften erfolgt innerhalb der Anwendungsschicht (OSI-Layer 7) und nicht wie bei IPSec bereits auf Ebene der Transportschicht (OSI-Layer 4). Aus diesem Grund existieren beispielsweise keine
Probleme im Zusammenhang mit NAT.
• Server-seitig bietet OpenVPN nach dem derzeitigen Stand keine offizielle Unterstützung für ein AAA-Protokoll, zum Beispiel RADIUS. Es existiert nur
eine experimentelle Unterstützung in Form eines Plugins →[LUEB07].
Seite 81
• Die Portierung von OpenVPN auf Geräte mit Windows Mobile befindet sich
noch in der Entwicklungsphase. Die Portierung wurde mit einer Emulationssoftware →[URL:13] für Pocket PCs unter Windows Mobile 5.0 getestet, jedoch
konnte die VPN-Verbindung nicht immer zuverlässig hergestellt werden.
• Das Systemkonzept sieht den Entzug von Administrationsrechten auf den mobilen Endgeräten (Notebooks) vor. OpenVPN benötigt dort jedoch administrative Rechte zum Setzen von Routingeinträgen für die VPN-Verbindung.
• OpenVPN bietet eine grafische Oberfläche zum Starten der VPN-Verbindung.
Diese kann auf Notebooks mit Windows nur mit Administrationsrechten fehlerfrei gestartet werden.
• Die Konfiguration einer VPN-Verbindung wird klartext-basiert im Dateisystem abgelegt. Es ist daher potenziell möglich, die Konfiguration auf ein externes Speichermedium zu kopieren und für eine unautorisierte VPN-Einwahl zu
verwenden.
5.1.2 IPSec
Als Alternative zu OpenVPN bestand auch die Möglichkeit der Nutzung von IPSec
mit den folgenden Vor- und Nachteilen:
• Die Mobilen Endgeräte mit Microsoft Windows benötigen keine zusätzliche
Software, da die VPN-Funktionalität bereits nativ in das Betriebssystem integriert wurde. Dadurch ist der Konfigurationsaufwand seitens des Clients gering.
• Die VPN-Verbindungen auf dem Mobilen Endgerät können nicht auf einen
externen Datenträger kopiert werden, da sie in das Betriebssystem eingebettet
sind. Die Konfiguration der VPN-Verbindungen wird dabei verschleiert.
• Das Mobile Endgerät erhält eine IP-Adresse aus dem internen lokalen Netzwerk. Damit ist das Mobile Endgerät direkt über Arbeitsstationen im lokalen
LAN, zum Zweck der Fernadministrierung, erreichbar.
• Die maschinenbasierte Authentisierung erfolgt zuerst auf Ebene des IPSecProtokolls durch Preshared Keys, die personenbezogene Authentisierung auf
der Ebene des PPP-Protokolls. Beide Authentisierungsarten müssen erfolgreich
durchgeführt werden, um die VPN-Einwahl zu ermöglichen.
• L2TP über IPSec ist ein offizieller IETF-Standard und kein properitäres VPNProtokoll.
Seite 82
• Die Einstellung der IPSec-Parameter über den Konfigurationsdialog auf dem
mobilen Endgerät ist fest vorgegeben:
Es können keine Parameter, z.B. ein alternativer Kryptoalgorithmus, vorgegeben werden. Die IPSec-Verbindung arbeitet im Transport Mode mit der Sicherungsart ESP. Der Transport Mode ist fest vorgegeben da der Hersteller,
Microsoft, sich an die Definition in RFC9193 - Securing L2TP using IPSec
hält. Diese Definition beschreibt, dass der Transport Mode unterstützt werden
muss; die Verwendung des Tunnel Mode ist optional (Siehe auch: →[URL:23]).
Zur Sicherung der Vertraulichkeit kommt der Kryptoalgorithmus 3DES zum
Einsatz. Dieser ist weit verbreitet und anerkannt, benötigt jedoch im Gegensatz zu Standard-DES die dreifache Rechenzeit. (Siehe auch →[KONG04]).
• Der server-seitige Konfigurationsaufwand ist im Vergleich mit OpenVPN komplexer, da für jede Komponente des benötigten Protokollstacks eine entsprechende Server-Komponente zu implementieren ist.
• Die Schachtelung mehrerer Netzwerkprotokolle erzeugt zusätzlichen Overhead
im Gegensatz zu nativen IPSec-Implementierungsarten.
5.1.3 IPSec und NAT-T
Die korrekte Funktion von NAT-T konnte im Rahmen dieser Realisierung nicht verifiziert werden. Gründe dafür sind zum einen die verwendete Netzwerkkonfiguration
(Siehe Abbildung 4.1), in der die mobilen Endgeräte über eine direkte Netzwerkverbindung (ohne NAT-Router) zum Mobile Security Gateway verfügen. Zum Anderen
konnte nicht ermittelt werden, ob die IPSec-Implementierung, Openswan, NAT-T
unter Verwendung einer maschinenbezogenen Authentisierung mit Preshared Keys
unterstützt.
Es existiert jedoch ein Konfigurationsbeispiel →[CARL07] für Openswan, dass die
Funktion von NAT-T ermöglichen sollte, wenn Zertifikate eingesetzt werden.
5.1.4 Problembehandlung
Für die korrekte Funktion dieser Implementierung ist es unbedingt erforderlich,
mindestens die angegebenen Versionen der einzelnen Pakete zu verwenden. Für die
Fehlersuche ist es sinnvoll, die erweiterten Protokollierungsfunktionen der einzelnen
Komponenten temporär einzuschalten.
• openswan:
In
der
Konfigurationsdatei
/etc/ipsec.conf
ist
der
Parameter
Seite 83
plutodebug="control parsing" zu setzen. Die Ausgaben werden in die
Datei /var/log/auth.log geschrieben.
• l2tpd, ppp und radiusclient1:
In der Konfigurationsdatei /etc/l2tpd.conf ist der Parameter ppp debug =
yes zu setzen. Die Ausgaben werden in die Datei /var/log/syslog geschrieben.
5.2 Firewall und AAA
Die Zugriffsbeschränkungen für MDAs auf die Protokolle POP3, SMTP und IMAP
wurden noch nicht realisiert. Sie besitzen daher die gleichen Zugriffsrechte im lokalen
LAN wie Notebooks, denn die Unterscheidung der Zugriffsrechte findet anhand eines
Benutzernamens und nicht durch eine Geräte-Identifikation statt: der AAA-Server
kann in dieser Realisierung nicht den Typus eines mobilen Endgerätes feststellen, da
der VPN-Server kein entsprechendes Attribut an den AAA-Server sendet.
Als Lösung für dieses Problem bietet sich an, spezielle Benutzernamen auf den MDAs
zu verwenden. Diese Benutzernamen besitzen beispielsweise ein gemeinsames Präfix,
gefolgt von einer fortlaufenden Nummer.
Das Firewall-Skript mit den dynamischen Filterregeln ist um eine zusätzliche Abfrage nach dem Präfix zu erweitern. Diesem Präfix wird je eine Regelvorlage für die
Protokolle POP3, SMTP und IMAP in der Filterliste vpn fwd zugeordnet.
Eventuell besteht die Möglichkeit, ein anderes Authentisierungsprotokoll als das derzeit verwendete MS-CHAP zu nutzen welches die Möglichkeit bietet, eine maschinenbezogene Kennung zu übermitteln. Weiterhin muss der RADIUS-Server dieses
Protokoll, unter der Randbedingung, dass die Authentisierung gegen den Verzeichnisdienst Active Directory damit immer noch möglich ist, unterstützen.
Der AAA-Server Freeradius bietet umfangreiche Konfigurationsmöglicheiten und
kann mit allen gängigen Authentisierungsverfahren (PAP, CHAP, MSCHAP sowie
verschiedene EAP-Derivate) und Benutzerdatenbanken (SQL, LDAP) arbeiten. Eine gute Möglichkeit zur Fehlersuche das Nutzen der Debug-Funktion, welche eine
umfangreiche Ausgabe liefert. Dazu wird der RADIUS-Server zuerst gestoppt und
anschließend über die Linux-Konsole mit dem Debug-Parameter (Eingabe: freeradius -X) neu gestartet. Dabei werden bereits während des Starts inkonsistente Einträge in den Konfigurationsdateien festgestellt und der Start gegebenenfalls mit einer
detaillierten Fehlerbeschreibung abgebrochen. Der Nachteil dieser Software ist die
Seite 84
Organisation der serverseitigen Konfigurationsparameter in einer zentralen Datei. Es
empfiehlt sich daher, Änderungen schrittweise durchzuführen und das gewünschte
Ergebnis zu kontrollieren.
5.3 Distributionssoftwareverteilung
In diesem Abschnitt werden die in dieser Arbeit gesammelten Erfahrungen mit der
Distributionssoftwareverteilung dargestellt:
• Installation von Software mit Winst nicht möglich
Ist eine Installation über Winst nicht möglich (z.B. erlaubt Winst keine Benutzerabfragen wie z.B.: Soll das Paket jetzt oder später installiert werden?)
kann eine Installationsroutine mit dem Entwicklungswerkzeug AutoIT programmiert werden. Das Winst-Script ruft in diesem Fall das mit AutoIT erstellte Setup-Programm auf und wartet auf die Beendigung des Setup-Programms.
Danach muss nur noch mit dem Winst-Script überprüft werden, ob das SetupProgramm erfolgreich verlaufen ist. Diese Art von Installation wurde bei Microsoft Office Professional 2007 (Evaluierung) angewendet.
• Softwareinstallation mit Winst scheitert
Oftmals ist das selbst erstellte Installationsscript für ein bestimmtes Softwareprodukt fehlerhaft. Um Fehler analysieren zu können, kann in dem Installationsscript die Debug-Funktion eingeschaltet werden. Die Debug-Informationen
werden dann lokal auf dem Client protokolliert.
Die Debug-Information protokolliert nicht alle Fehler. Eine Lösung hierfür ist,
die Skriptinstallation auf über den Winst-Interpreter manuell zu starten. Vorher muss allerdings das Share Laufwerk vom opsi-depotserver gemountet werden und von dort das Installationsscript in den Winst-Interpreter geladen werden. Mit dieser Methode konnten bisher alle Fehler und Probleme bei selbst
erstellten Installationsscripten gefunden und beseitigt werden.
• Gruppenverwaltung
Eine Gruppenverwaltung von PCs mit unterschiedlichen Softwarepaketen ist
möglich, jedoch umständlich. Die DNS-Namen der Clients die zu einer Gruppe
zusammengefasst werden sollen, müssen dafür in eine separate Datei eingetragen werden. Mit dem Tool winipatch (siehe →[URL:20] Abschnitt 4.6.6) kann
diese Datei durchsucht werden und ein Paket für die Softwareverteilung für jeden Client dieser Gruppe hinzugefügt werden. Problematisch wird es, wenn für
den Trusted Network Connect unterschiedliche Gruppen mit unterschiedlichen
Seite 85
sicherheitsrelevanten Softwarepaketen die Verbindung in das Unternehmensnetz herstellen, da die Referenzdatei zur Zeit keine Gruppe separieren kann.
Ist es erforderlich, Gruppen von Clients mit unterschiedlichen Softwarepaketen
auszustatten und diese einen Remotezugriff auf das Unternehmensnetz zu gestatten, muss die Referenzdatei und der TNC Client erweitert und angepasst
werden.
• Software on Demand
Die Software opsi unterstützt zur Zeit noch nicht die Möglichkeit einer Software
on Demand Funktionalität, wie es z.B. bei NetInstall der Fall ist.
• Fehlerhafte Installationen
Fehlerhafte Installationen werden auf dem opsi-Depotserver nur als Fehler gekennzeichnet, wenn die Installationsroutine mit dem kritischen Laufzeitfehler
isFatalerror abbricht. Läuft das Installationsscript ohne Abbruch durch, wird
dieses Paket automatisch als korrekt installiert gekennzeichnet.
Bei mit Fehler gekennzeichneten Installationen, muss der Administrator den
Parameter in der Client-Software-Liste manuell wieder auf einen anderen Status (z.B. setup oder off) setzen. Bei vielen Clients kann diese Arbeit sehr viel
Zeit in Anspruch nehmen, deswegen erledigt das folgende Script diese Funktion
von selbst:
#!/bin/bash
# Suchen aller PCs mit fehlerhafter Installation
MYGROUP=‘grep -l " *=failed" /opt/pcbin/pcpatch/*.ini‘
if [ "$MYGROUP" = "" ];
then
echo "Keine fehlerhaften Installationen !"
else
# setzen des Status failed auf setup
sed ’s/failed/setup/g’ -i $MYGROUP
echo $MYGROUP >> /opt/pcbin/pcpatch/pclog/failed.log
fi
Dieses Script muss über den Cron-Job des Linux-Systems in bestimmten
Zeitabständen kontinuierlich gestartet werden.
• Benutzer bricht Installation manuell ab
Hat der Benutzer Zugriff mit der Tastatur oder der Maus, ist er in der Lage,
Installationen, welche Fenster mit Buttons zeigen, abzubrechen. Aus diesem
Seite 86
Grund sollte möglichst immer eine Silent Installation durchgeführt werden,
oder wo es nicht möglich ist, sollte die Tastatur und Maus während des Installationsvorgangs gesperrt werden.
• Hinzufügen eines Softwarepaketes
Wird dem opsi-Depotserver ein neues Paket mit opsiinst hinzugefügt, wird
dieses Paket zwar in die Client-Referenzliste für den Trusted Network Connect
übernommen, jedoch ist der Status dort noch einmal zu überprüfen und gegebenenfalls richtig zu setzen.
• Verlust der Netzwerkverbindung
Bei einem Verlust der Netzwerkverbindung wird der Status des zu installierenden Paketes in der Client-Software-Liste nicht verändert, das heißt die Installation würde bei erneuter Verbindung mit dem opsi-Depotserver neu gestartet.
Das Problem hierbei ist, wenn das Installationsprogramm schon Daten auf den
Client geschrieben hat und mit diesen vorhandenen Daten nicht umgehen kann,
ist ein wiederholtes Scheitern der Installation möglich. In diesem Fall muss der
Systemadministrator diese Dateien manuell löschen, bevor die Installation erneut gestartet werden kann.
• Neuer Microsoft Windows Patch
Falls neue Microsoft Windows Patches zur Verfügung stehen und der Systemadministrator diese Pakete verteilen möchte, muss für jeden Patch (oder
auch Gruppe von Patches) ein neues Paket generiert oder das vorhandene
Paket winxp patches erweitert und neu verteilt werden.
Zusammenfassend ist zu sagen, dass die Distributionssoftwareverteilung eine brauchbare Alternative zu der kommerziellen Software NetInstall ist.
5.4 Trusted Network Connect
Um die prototypische Realisierung bewerten zu können, ist ein Vergleich mit der
kommerziellen Lösung Network Admission Control von Cisco Systems sinnvoll:
• Zugang von einem internen oder externen Netzwerk
Die NAC-Lösung von Cisco Systems ist für den Zugang von einem externen
Netz (z.B. Internet) und dem internen Netz konzipiert worden. Diese Lösung
ermöglicht eine lückenlose Kontrolle, Identifikation und Überprüfung mit z.B.
Integritätstest durch den Trust Agent von Cisco. Diese Lösung garantiert, dass
Seite 87
ein Client, der auch im Außendienst eingesetzt wird, keine Viren oder schädliche Programme in das Unternehmen einschleusen kann.
Die hier vorgestellte Lösung ist zur Zeit nur für einen Remote-Zugang konzipiert. Die Lösung kann zwar auf das lokale Netz übertragen werden, jedoch ist
dann der Einsatz von VPN-Verbindungen (wenn das Konzept beibehalten werden soll) auch im lokalen Netz notwendig. Das Nutzen von VPN’s im lokalen
Netz bietet Vor- und Nachteile:
Der Vorteil besteht in einer verschlüsselten Datenübertragung in lokalen Netzen. Es kann also kein Eindringling den Datenverkehr in Klartextform aufzeichnen.
Der Nachteil für den Einsatz von VPN’s in lokalen Netzen besteht in der Notwendigkeit zusätzlicher Zugangspunkte und der Erweiterung der vorhandenen
Infrastruktur (insbesondere Server) mit VPN-Funktionalität.
• Benötigte Komponenten für den TNC
Die Cisco Network Admission Control Lösung setzt zusätzlich zu dem Trusted
Agent spezielle Network Access Devices voraus, die NAC unterstützen. Cisco
empfiehlt dabei natürlich den Einsatz der eigenen Produktpalette, um diese
Funktionalität realisieren zu können. Diese Komponenten sind sehr teuer und
ein mittelständisches Unternehmen ist nicht unbedingt in der Lage, die evtl.
vorhandene Infrastruktur auszutauschen, wenn diese Komponenten von Cisco
nicht ohnehin im Einsatz sind.
Die hier vorgestellte Lösung hat keine teuren oder notwendigen Anforderungen
an die Infrastruktur eines Unternehmens. Der hier eingesetzte Server mit entsprechender Open Source Software ist in Bezug auf fixe und variable Kosten
günstig, da als Server jeder beliebige Rechner mit einem Linux Betriebssystem zum Einsatz kommen kann. Der Server arbeitet hauptsächlich nur als File
Share, somit sollte mehr Wert auf eine schnelle Anbindung an das Unternehmensnetz geachtet werden, als an eine hohe Prozessorleistung.
Es werden außerdem keine herstellerspezifischen Netzwerkkomponenten benötigt.
• Unterstützung 802.1x
Die Cisco NAC Lösung unterstützt das Protokoll 802.1x mit den entsprechenden Netzwerkkomponenten. Die hier vorgestellte Lösung ist mit 802.1x nicht
getestet worden, jedoch ist eine Implementierung von 802.1x und dafür die
wichtigste Komponente (RADIUS-Server) bei Remote-Einwahlen vorgesehen.
Seite 88
Damit die Funktion des Trusted Network Connect umgesetzt werden kann,
muss der RADIUS-Server folgende Zugriffsrechte setzen:
1. Die erste Einwahl mit dem User pcpatch muss auf ein Quarantäne-VLAN
beschränkt werden, in dem auch der Distributionsoftwareverteilungsserver
angeschlossen ist.
2. Die zweite Einwahl kann dann individuell behandelt werden, z.B. Zuweisung eines VLAN’s anhand des Benutzers.
• Benötigte Software für TNC.
Die Cisco Lösung für den Trusted Network Connect setzt 3rd Party Software
(z.B. Virenscanner oder NAC-fähige Anwendungen) voraus, die ihren aktuellen
Status selbstständig, in periodischen Zeitabständen, an den Cisco Trust Agent
melden. Dieses periodische Melden kann dazu führen, dass der Client bei der
Einwahl die Sicherheitsüberprüfung bestanden hat und während des Arbeitens
zu einem ungünstigen Zeitpunkt in die Quarantänezone verschoben wird, weil
ein neues Update für den Virenscanner zur Verfügung steht.
Die hier vorgestellte Lösung kann jede beliebige Software sehr einfach in den
Prozess der Integritätsprüfung mit einbeziehen, da auf installierte Pakete geprüft wird. Falls wider Erwarten und trotz Entzug der Administrationsrechte,
ein Virus (durch z.B. eine Sicherheitslücke im Betriebssystem) in das System
eindringen kann, wird dieser Angriff in dieser Lösung nicht erkannt. Andererseits führt ein neues Update nicht sofort dazu, dass der Client in die Quarantänezone verschoben wird. Erst nach erneuter Einwahl wird das neue Paket
dann eingespielt.
• Erweiterungen
Der Cisco Trust Agent bietet die Möglichkeit über benutzerdefinierte Scripte,
eigene Richtlinien in die Sicherheitsüberprüfung mit einzubeziehen. Zusätzlich
ist das System durch Scannen des Datenverkehrs innerhalb des Netzwerks in
der Lage, Angriffe über unbekannte Ports (z.B. unnatürlich viele Pakete auf
einem Port) zu erkennen und zu filtern.
Die Möglichkeit der Erweiterung kann in dieser Lösung entweder durch das
Hinzufügen von Paketen auf dem opsi-Depotserver oder durch die Integration
neuer Funktionen in den TNC Client erfolgen.
Der Einsatz weiterer Pakete auf dem Mobile Security Gateway kann die Sicherheit noch zusätzlich erhöhen:
– Snort (URL →[URL:25])
Snort ist ein Open Source Projekt für ein Intrusion Detection System
Seite 89
(→IDS), welches in der Lage ist, Angriffsmuster im Datenverkehr über
bestimmte Ports zu erkennen und zu melden.
– Virenscanner
Ein Virenscanner auf dem File Share kann verhindern, dass sich schädlicher Programmcode innerhalb der Quarantänezone auf die mobilen
Endgeräte verteilt. Hierzu ist der Einsatz eines Open Source Virenscanners, zum Beispiel ClamAV, denkbar.
Abschließend ist zu erwähnen, dass das Programmieren des TNC Clients mit der
Script-Sprache AutoIT zwar schnell vollzogen wurde, jedoch sollte der Client in einer
’richtigen’ Programmiersprache (z.B. C++) geschrieben werden. Die Programmiersprache AutoIT wurde nur gewählt, weil sie für Installationsroutinen der Softwarepakete bei der Distributionssoftwareverteilung zum Einsatz gekommen ist und nur
gezeigt werden sollte, wie der TNC Client prototypisch umgesetzt werden kann.
5.5 Verschlüsselung und Zerstörung von Daten
Die Motivation für den Diebstahl von mobilen Endgeräten kann differenziert werden:
• Interesse an dem Gerät
Besteht ausschließlich Interesse an dem Gerät, um dieses zu veräußern, würde eine Verschlüsselung von Daten mit Hilfe von Containern, den Ansprüchen
genügen. Das Gerät wird selbst genutzt oder auf dem Schwarzmarkt verkauft.
Die vorhandenen Daten und das Betriebssystem werden dabei einfach mit einem neuen Betriebssystem überschrieben.
Diebstähle können nachweislich durch eine Kennzeichnug der Notebooks (z.B.
mit einer Gravur) reduziert werden.
• Diebstahl von Daten
Wenn Geräte mit der Absicht gestohlen werden, die vorhandenen Daten zu extrahieren, reicht eine normale Verschlüsselung mit Hilfe von Containern nicht
mehr aus. Der Container kann extern gespeichert werden und beliebig lang mit
Versuchen, das Passwort zu entschlüsseln, attackiert werden.
Um weitestgehende Sicherung zu erreichen, ist eine komplette Laufwerksverschlüsselung mit Pre-Boot-Authentification unumgänglich.
Für eine komplette Laufwerksverschlüsselung wird das Produkt SafeGuard Easy von Utimaco empfohlen, da sogar die Deutsche Bundeswehr dieses Produkt
einsetzt (Quelle →[URL:08]), um ihre 20.000 mobilen Notebooks zu schützen.
Seite 90
Die vollständige Zerstörung von Daten ist ohne zusätzliche Hardware nicht ohne
weiteres möglich, da eine gestohlene Festplatte mit vorhandenen Daten immer aus
dem Original-Gerät ausgebaut und in ein anderes Gerät wieder eingebaut werden
könnte. Aus diesem Grund entfällt die Möglichkeit einer Zerstörung oder das Löschen
der Daten mit Hilfe von Software. Die einzige Möglichkeit, solche Daten auf der
Festplatte zu zerstören ist, wenn die Festplatte selbstständig erkennt, dass sie in
ein anderes Gerät eingebaut wurde. Sie muss dann die Zerstörung der Daten lokal
vornehmen.
Seite 91
Kapitel 6 - Fazit / Ausblick
6 Fazit / Ausblick
Die hier entwickelte Lösung lässt sich in ein Unternehmensnetzwerk mit einem vorhandenen Verzeichnisdienst (hier: Active Directory) integrieren und ermöglicht den
mobilen Mitarbeitern mit Microsoft Windows basierten Endgeräten einen transparenten Zugriff auf Netzwerkressourcen innnerhalb des Unternehmens.
Die Absicherung der VPN-Strecke durch IPSec/L2TP ermöglicht die Nutzung der
in den Microsoft-Betriebssystemen vorhandenen VPN-Clients ohne zusätzliche Software. Die Alternative dazu, OpenVPN erschien zunächst vielversprechend, konnte
jedoch auf Grund funktionaler Nachteile nicht die IPSec/L2TP-Lösung ersetzen.
Der Trusted Network Connect isoliert das mobile Endgerät während der VPNEinwahl zunächst in eine Quarantänezone. In dieser Zone werden gegebenenfalls Updates eingespielt und die Sicherheitsüberprüfung anhand eines Soll-Ist-Vergeiches installierter Software-Pakete durchgeführt. Nur nach erfolgreicher Sicherheitsüberprüfung ist dem mobilen Endgerät der Zugriff auf das Unternehmensnetzwerk gestattet.
Die TNC Implementierung sieht derzeit nocht nicht vor, dass für mobile Endgeräte unter Umständen unterschiedliche sicherheitsrelevante Software-Konfigurationen
notwendig sind. Eine Erweiterung der TNC-Implementierung um eine Gruppenverwaltung mobiler Endgeräte erscheint daher sinnvoll. Die Einbindung von Handhelds
(PDAs) gestaltet sich schwierig. Zum Einen muss für solche Geräte eine entsprechende Client-Software programmiert werden; uum Anderen müssen diese Geräte
serverseitig berücksichtigt werden, da sie andere Software-Pakete benötigen wie beispielsweise Notebooks.
Die Möglichkeit zur Fernadministrierung mobiler Endgeräte ist derzeit auf Notebooks beschränkt, da es für PDAs keine entsprechende Software gibt.
Die Distributionssoftwareverteilung opsi ermöglicht die zuverlässige Installation von
Software über das Netzwerk und ist deshalb eine brauchbare Alternative zu dem
kommerziellen Softwareprodukt NetInstall. Die kommende Version, die sich zur Zeit
noch im Beta-Status befindet, verspricht eine komfortablere Verwaltung von Gruppen mobiler Endgeräte. Dies ist auch für eine weitere Entwicklung des Trusted Network Connects interessant, da auf diese Weise die Gruppenverwaltung sicherheitsSeite 92
Kapitel 6 - Fazit / Ausblick
relevanter Software-Pakete realisiert werden kann.
Das Schützen von Daten auf den mobilen Endgeräten ist möglich, indem diese Daten
in verschlüsselte Containerdateien ausgelagert werden. Eine komplette Verschlüsselung der Festplatte bei Notebooks ist nur bei Verwendung eines kommerziell angebotenen Produktes wie SafeGuard möglich. Die Zerstörung von Daten auf den mobilen
Endgeräten kann derzeit durch Open Source Software nicht realisiert werden.
Zusammenfassend betrachtet, ist die Realisierung einer dedizierten Infrastruktur für
die mobile Kommunikation auf der Basis von Open Source Software grundsätzlich
möglich. In einigen Bereichen besteht noch Entwicklungsbedarf, bevor eine solche
Lösung ein kommerzielles Produkt ersetzen kann. Ein großer Vorteil ist jedoch die
Unabhängigkeit des Systems von einer spezifischen Hardwareplattform oder Netzwerkinfrastruktur.
Seite 93
Literaturverzeichnis
[AHLE01] Ahlers, Ernst
Das Netz im Netz
c’t Magazin 7/2006
Verlag Heinz Heise, S. 104f.
[AHLE02] Ahlers, Ernst
VPN-Knigge
c’t Magazin 7/2006
Verlag Heinz Heise, S. 114ff.
[BRIL01] Brill, Gerwin
AAA-Protokolle
Seminararbeit WS01/02
Institut für Informatik, Universität Bonn
http://web.informatik.uni-bonn.de/IV/martini/Lehre/
Veranstaltungen/WS0102/Sem_Rechnernetze/Vortraege/gerwin_
brill.pdf
zuletzt besucht: 07.04.2007
[BUDD05] Budde, Rainer
Samba 3.x als Domänen-Mitglied
http://www.pro-linux.de/work/server/samba3-domaene.html
[CARL07] Carlson, Nate
Configuring an IPSec Tunnel with openswan and l2tpd
http://www.natecarlson.com/linux/ipsec-l2tp.php
[DELE07] De Leuw, Jacco
Using a Linux L2TP/IPsec VPN server
http://www.jacco2.dds.nl/networking/freeswan-l2tp.html
Seite 94
[HELF06] Helfrich, Denise and Ronnau, Lou and Frazier, Jason and Forbes, Paul
(2006)
Cisco Network Admission Control: Volume I, NAC Framework Architecture and Design
ISBN: 1-58705-241-5
1. Ausgabe
Cisco Press
[KONG04] Kongnin, Atnarong u.a.
Neue VPN-Lösungen
IIS - Seminar Mobile Systeme III - WT04
Universität der Bundeswehr München, 2004
http://www.informatik.unibw-muenchen.de/reports/reports/
2004-02.pdf
[LUEB07] Lübben, Ralf
Radiusplugin for OpenVPN
http://www.nongnu.org/radiusplugin/
[SOEL02] Söldner, Guido
Das Kerberos-Protokoll
Seminararbeit SS02
Institut für Informatik, Universität Erlangen
http://www4.informatik.uni-erlangen.de/Lehre/SS02/PS_KVBK/
talks/folien_guido.pdf
[THUM07] Thumann, Rey
PSK Cracking using IKE Aggressive Mode
http://www.ernw.de/download/pskattack.pdf
[KWOK07] Kwok, Wing Ss
PopTop, MSCHAPv2, Samba, Radius, Microsoft Active Directory
Howto
http://www.members.optushome.com.au/~wskwok/poptop_ads_
howto_1.htm
Seite 95
[URL:01]
Bundesamt für Sicherheit in der Informationstechnik
Aufbau von Virtual Private Networks (VPN) und Integration in Sicherheitsgateways
http://www.bsi.de/fachthem/sinet/loesungen_transport/VPN.
pdf
[URL:02]
CIPHERBOX
Sicherheit - Festplatte schützen
http://www.cipherbox.de/sicherheit-hdprotect.html
[URL:03]
Cisco Systems
Hersteller von Netzwerkkomponenten http://www.cisco.com/
[URL:04]
DFN-CERT
Die drei A’s: Authentisierung, Autorisierung und Accounting
http://www.dfn-cert.de/dfn/berichte/db081/dialin/node4.html
[URL:05]
FreeOTFE
Free Open Source Disk Encryption Software
http://www.freeotfe.org/
[URL:06]
Freeradius
The world’s most popular RADIUS Server
http://www.freeradius.org
[URL:07]
FreeS/WAN
Open-Source IPSec-Implementierung für Linux
http://www.freeswan.org/
[URL:08]
Golem.de
IT-News für Profis
http://www.golem.de/0501/35873.html
[URL:09]
Hiddensoft
AutoIt BASIC-like scripting language
Seite 96
http://www.hiddensoft.com/autoit3/
[URL:10]
Homepage der Internet Engineering Task Force (IETF)
http://www.ietf.org
[URL:11]
Homepage HP
HP iPAQ hw6915 Mobile Messenger
http://h10010.www1.hp.com/wwpc/de/de/sm/WF05a/
21259-21265-21265-21265-297361-12343262.html
[URL:12]
IPTABLES
Werkzeug zur Konfiguration des Linux-Paketfilters
http://www.netfilter.org/
[URL:13]
Microsoft
Standalone Device Emulator 1.0 with Windows Mobile OS Images
http://www.microsoft.com/downloads/details.aspx?FamilyId=
C62D54A5-183A-4A1E-A7E2-CC500ED1F19A&displaylang=en
[URL:14]
net-solution
enteo v6 NetInstall
http://www.netinstall.ch/index.php
[URL:15]
Netfilter.org
Linux 2.4 Packet Filtering Howto
http://www.netfilter.org/documentation/HOWTO/de/
packet-filtering-HOWTO.html
[URL:16]
OpenSSL
The Open Source toolkit for SSL/TLS
www.openssl.org
[URL:17]
Openswan
http://www.openswan.org/
Seite 97
[URL:18]
OpenVPN
An Open Source SSL VPN Solution by James Jonan
http://openvpn.net/
[URL:19]
opsi FTP-Server
Einbindung und Integration in die Softwareverteilung
http://download.uib.de/opsi2/doku/opsi_integrations_
handbuch.pdf
[URL:20]
opsi FTP-Server
Dokumentation opsi Version 2.5
http://download.uib.de/opsi2/doku/opsi_v2_handbuch.pdf
[URL:21]
opsi FTP-Server
PC-Software- installation mit wInst
http://download.uib.de/doku/winst_handbuch.pdf
[URL:22]
RealVNC Ltd
RealVNC remote control software
http://www.realvnc.com/
[URL:23]
RFC3193
Securing L2TP using IPsec
http://www.ietf.org/rfc/rfc3193.txt
[URL:24]
SDS Software
Installer2GO Home Page
http://dev4pc.com/installer2go.html
[URL:25]
SNORT.ORG
Open Source Network Intrusion Prevention And Detection System
http://www.snort.org/
[URL:26]
Sourceforge.net
Installers
Seite 98
http://unattended.sourceforge.net/installers.php
[URL:27]
Strongswan
http://www.strongswan.org/
[URL:28]
TrueCrypt
Free Open Source Disk Encryption Software
http://www.truecrypt.org
[URL:29]
Trusted Computing Group
Trusted Network Connect Work Group
https://www.trustedcomputinggroup.org/groups/network
[URL:30]
uib umwelt informatik büro gmbh
http://www.uib.de/www/home/
[URL:31]
utimaco
The Data Security Company
http://www.utimaco.de/
[URL:32]
Wikipedia:
Stateful Packet Inspection
http://de.wikipedia.org/wiki/Stateful_Packet_Inspection
Seite 99
Glossar
3DES
Triple-DES. Triple DES bezeichnet die Verschlüsselung nach dem symmetrischen Verfahren Data Encryption Standard. Das Präfix Triple bedeutet die dreimalige Hintereinanderausführung des DES-Algorithmus um eine höhere Verschlüsselungsstärke zu
erreichen., S. 5.
802.1x
IEEE 802.1x. IEEE 802.1x ist ein Standard für die Authentisierung und Autorisierung
in Rechnernetzen., S. 19.
AAA
Authentisierung, Autorisiserung und Accounting. Authentisierung, Autorisierung und
Accounting (AAA) steht für ein Modell, das eine Zugriffskontrolle für entfernte Benutzer vorsieht., S. 13.
AES
Advanced Encryption Standard. Advanced Encryption Standard ist der designierte
Nachfolger des Verschlüsselungsalgorithmus Data Encryption Standard. Dieser bietet
eine höhere Verschlüsselungsstärke als Triple-DES bei geringerem Rechenaufwand.,
S. 5.
AR
Access Requestor. Der Access Requestor ist in der Trusted Network Connect Architektur die Einheit (Client), die eine Netzwerkverbindung aufbauen möchte., S. 19.
AS
Authentication Server. Der Authentication Server ist in der Kerberos-Architektur für
das Verarbeiten von Ticket Granting Tickets und das Erzeugen von Service Granting
Tickets zuständig., S. 14.
CHAP
Challenge Handshake Authentication Protocol. Authentisierungsprotokoll, bei dem jedoch keine Kennwörter im Klartext, wie bei PAP, übertragen werden., S. 7.
EAP
Extensible Authentication Protocol. EAP ist ein Authentisierungsprotokoll, das für die
Zugriffskontrolle auf Netzwerke eingesetzt wird., S. 19.
ESP
Encapsulated Security Payload. Sicherungsart von IPSec, welche Vertraulichkeit, Authentizität und Integrität bietet., S. 7.
HMAC
Hash Message based Authentication Code. Ein Verfahren zur Integritätssicherung, basierend auf Prüfsummenverfahren wie Message Digest 5 (MD5) oder Secure Hash
Algorithm 1 (SHA1)., S. 5.
HTTPS
Hyper Text Transfer Protocol Security. HTTPS erweitert das ursprüngliche Hyper
Text Transfer Protocol um die Möglichkeit einer verschlüsselten und manipulationssicheren Datenübertragung., S. 19.
IDS
Intrusion Detection System. Ein Intrusion Detection System erkennt durch Scannen
der Daten eines Netzwerks Angriffe (z.B. Würmer)., S. 90.
Seite 100
IF-IMC
Integrity Measurement Collector Interface. In der TNC-Architektur werden über diese
Schnittstelle Informationen über den Integritätsstatus eines Clients an den TNCClient gereicht., S. 22.
IF-IMV
Integrity Measurement Verifier Interface. In der TNC-Architektur werden über diese Schnittstelle Informationen über den Integritätsstand eines Clients an den TNCServer in Form einer Empfehlung, was mit diesem Client zu tun ist, gereicht., S. 22.
IF-PEP
Policy Enforcement Point Interface. Über diese Schnittstelle werden in der TNCArchitektur die Zugriffsrechte für einen Client (Access Requestor) zwischen Policy
Enforcement Point (der ausführenden Instanz) und dem Policy Decision Point (der
maßgebenden Instanz) verhandelt., S. 23.
IF-T
Network Authorization Transport Protocol Interface. Über diese Schnittstelle werden in der TNC-Architektur Nachrichten über ein konkretes Transportprotokoll zwischen dem Client (Access Requestor) und einem Autorisierungsserver (Policy Decision
Point) übertragen. Der Autorisierungsserver kann dabei ein Radius-Server sein., S. 23.
IF-TNCCS TNC Client-Server Interface. Über diese Schnittstelle erfolgt der Austausch von Nachrichten bezüglich des Integritätsstatus eines Clients (Access Requestor)., S. 22.
IKE
Internet Key Exchange. Die Aushandlung der Sitzungsschlüssel, der Verbindungskonfiguration und der Authentisierung geschieht bei IPSec über ein separates Protokoll,
als Internet Key Exchange bezeichnet., S. 8.
IMC
Integrity Measurement Collector. Der Integrity Measurement Collector ist in der Trusted Network Connect Architektur die Komponente, die automatisch und selbstständig
ihren Sicherheitsstatus an den Trusted Network Connect Client meldet., S. 19.
IMV
Integrity Measurement Verifier. Der Integrity Measurement Verifier ist in der Trusted
Network Connect Architektur die Komponente, die eine Empfehlung anhand der erhaltenen Informationen von den Integrity Measurement Collectoren an den Trusted
Network Connect Server weitergibt., S. 19.
KDC
Kerberos Distribution Center. Das Kerberos Distribution Center ist die zentrale Instanz zur Vergabe von Kerberos-Tickets., S. 14.
L2TP
Layer 2 Tunneling Protocol. Das Protokoll L2TP ist die von Microsoft favorisierte
Lösung zum Aufbau von VPN-Verbindungen., S. 9.
MS-CHAP Microsoft Challenge Handshake Authentication Protocol. Authentisierungsprotokoll,
bei dem jedoch keine Kennwörter im Klartext, wie bei PAP, übertragen werden. Hier
mit Microsoft-spezifischen Erweiterungen., S. 7.
MSI
Microsoft Installer. Der Microsoft Installer ist eine System welches die Installationsroutinen von Softwarepaketen unter Microsoft Windows vereinheitlicht., S. 32.
NAA
Network Access Authority. Der Network Access Authority ist in der Trusted Network
Connect Architektur die Komponente, die entscheidet, ob der Access Requestor Zugang zu dem Netzwerk erhält. Er kontaktiert den Trusted Network Connect Server
und fragt dort den Sicherheitsstatus des Access Requestor ab., S. 19.
Seite 101
NAC
Network Admission Control. Network Admission Control ist eine Bezeichnung des
Unternehmens Cisco Systems und realisiert den Aufbau vertrauenswürdiger Verbindungen, wie sie von der Trusted Computing Group empfohlen wird., S. 25.
NAD
Network Access Device. Die Network Access Devices sind Komponenten von Cisco,
wie Switches, Router, VPN-Concentrators oder Access Points, die Network Admission
Control unterstützen. Die Komponenten setzen die Zugriffsberechtigung des Clients
anhand der empfangenen Informationen von dem Cisco Secure ACS., S. 25.
NAR
Network Access Requestor. Der Network Access Requestor ist in der Trusted Network Connect Architektur die Komponente, die die Verbindung zu einem Netzwerk
herstellt., S. 19.
NAS
Network Access Server. Der Network Access Server ist in der AAA-Architektur der
Einwahlknoten für entfernte Benutzer, an dem eine Zugriffskontrolle statt findet.,
S. 16.
NAT
Network Address Translation. Bei diesem Verfahren verändert ein Router die Quelladresse oder Zieladresse eines IP-Paketes. Dies ermöglicht es, dass mehrere LANClients mit privaten IP-Adressen eine Verbindung zum Internet über eine einzige
öffentliche IP-Adresse hertellen können., S. 8.
NAT-T
NAT-Traversal. Erweiterung der IPSec-Spezifikation, um den Betrieb von IPSec über
NAT-Router sicherzustellen., S. 9.
PAP
Password Authentication Protocol. Authentisierungsprotokoll, bei dem Kennwörter im
Klartext von dem entfernten Endgerät zum Einwahlknoten übertragen werden., S. 7.
PDP
Policy Decision Point. Der Policy Decision Point ist in der Trusted Network Connect
Architektur die Einheit, die die Zugriffsrechte für den Client anhand von Integritätstests empfiehlt., S. 19.
PEP
Policy Enforcement Point. Der Policy Enforcement Point ist in der Trusted Network
Connect Architektur die Einheit (Switch, Firewall oder VPN Gateway), die für einen
Client Sicherheitsrichtlinien anwendet., S. 19.
PPP
Point-to-Point Protocol. Über das Point-To-Point Protocol wird eine Ende-Zu-Ende
Verbindung realsiert. Da PPP auf OSI-Schicht zwei arbeitet, transportiert es typischerweise Protokolle höherer Schichten, wie das IP-Protokoll., S. 10.
PSK
Preshared Key. Geheimer Schlüssel, der beiden Kommunikationsendpunkten vor Aufbau einer VPN-Verbindung zur verfügung stehen muss. Diese Schlüssel müssen vorher
über ein sicheres Medium kommuniziert werden., S. 6.
SGT
Service Granting Ticket. Das Service Granting Ticket stellt in der KerberosArchitektur die Berechtigung für einen Kerberos-Client dar, einen Kerberos-fähigen
Dienst auf einem bestimmten Server zu nutzen., S. 14.
SPI
Stateful Packet Inspection. Stateful Packet Inspection ist eine dynamische Filtertechnik, bei der jedes untersuchte Datenpaket einer Session zugeordnet wird., S. 11.
Seite 102
TCG
Trusted Computing Group. Die Trusted Computing Group entwickelt und veröffentlicht offene Standards für Sicherheitstechologien und herstellerunabhängige Spezifikationen für den Aufbau vertrauenswürdiger Verbindungen im Computerbereich., S. 19.
TGS
Ticket Granting Server. Der Ticket Granting Server in der Kerberos-Architektur
nimmt Authentisierungswünsche von Benutzern via Kerberos entgegen und erstellt
dem Benutzer ein Ticket Granting Ticket für den gewünschen Dienst., S. 14.
TGT
Ticket Granting Ticket. Das Ticket Granting Ticket ist in der Kerberos-Architektur
die Berechtigung, ein Service Granting Ticket vom Authentication Server anzufordern., S. 14.
TLS
Transport Layer Security. Transport Layer Security ist ein Netzwerkprotokoll oberhalb
der Transportschicht (OSI-Layer 4) das eine verschlüsselte Übertragung von Daten
ermöglicht., S. 19.
TNC
Trusted Network Connect. Der Trusted Network Connect ist ein Ansatz der Trusted
Computing Group, vertrauenswürdige Verbindungen anhand von Integritätsprüfungen aufzubauen., S. 19.
TNCC
TNC Client. Der TNC Client ist in der Trusted Network Connect Architektur die
Komponente, die den Status der Integrity Measurement Collectoren empfängt und
diesen Status an den Trusted Network Connect Server weiterleitet., S. 19.
TNCS
TNC Server. Der TNC Server ist in der Trusted Network Connect Architektur die
Komponente, die den Datenaustausch zwischen den Integrity Measurement Verifier
und dem Integrity Measurement Collector steuert. Zusätzlich sammelt sie die Empfehlungen von dem Integrity Measurement Verifier und leitet daraus eine Sicherheitsstufe
für den Network Access Authority ab., S. 19.
VPN
Virtual Private Network. Ein Virtual Private Network ist eine Punkt zu Punkt Verbindung, die Daten über ein öffentliches Transportnetz überträgt. Die Verbindung
wird meistens durch technische Maßnahmen gegen Ausspähen und Manipulation der
übertragenen Daten besonders geschützt., S. 4.
Seite 103
A Anhang
Aufgrund des Umfangs der Scripte und der Installationsanleitungen wurden diese
nicht in Papierform der Diplomarbeit beigefügt, sondern als PDF-Datei (Portable
Document Format) auf der beiligenden CD gespeichert. Die folgende Tabelle zeigt,
welches Dokument unter welchem Dateinamen auf der CD zu finden ist:
Nr.
Titel
Ort
Datei
1
System-Dokumentation:
CD
debian-Install.pdf
Installationsanleitung Debian GNU/Linux
\sys-inst
CD
Installationsanleitung VPN-Server
\sys-inst
CD
Installationsanleitung Firewall
\sys-inst
CD
Installationsanleitung AAA-Server
\sys-inst
CD
Installationsanleitung opsi-Depotserver und opsi-
\sys-inst
2
3
4
5
vpn-install.pdf
fw-install.pdf
aaa-install.pdf
opsi-Install.pdf
Client
6
7
8
9
10
CD
Installationsanleitung Windows 2000 Server
\sys-inst
CD
Installationsanleitung Windows 2003 Server
\sys-inst
CD
Installationsanleitung VPN-Profile
\sys-inst
CD
Source Code Trusted Network Connect Client
\sys-source-codes
CD
Installations-Scripte für neue Pakete der Distribu-
\sys-scripte
win2000-Install.pdf
win2003-Install.pdf
vpn-profil.pdf
tnc.pdf
winst-scripte.pdf
tionssoftwareverteilung
Seite 104

Diplomarbeit - Weblearn

Transcrição

Documentos relacionados

Neue gamona Netzwerkseite zu RF Online

Heydt 1 Berlin Tiergarten

Die drei Blockaden - Saskia Anders

aber nicht unsere HÃ¤user Gucci Schuhe Herren

Erster Lauf zur Waldeck-Frankenberger Laufcup

Aktueller Newsletter aus Ipswich, UK

Auf der Via Gebennensis von La Côte-Saint-André nach Le Puy

Deckenhalterung für IP Kamera

5,99 - Liebig Apotheke

Das Noether-Theorem in der klassischen Feldtheorie