Diplomarbeit an der Fachhochschule München

Sichere Anbindung eines Funknetzes
an ein bestehendes IP-Netzwerk

Stefan Zehl
<sec@42.org>

Betreuer: Prof. Dr. Klaus Köhler
Zweitprüfer: N.N.
Abgabedatum: 30.9.2002

Zusammenfassung:

Der PC als Arbeitsgerät hat schon vor einigen Jahren in die Hochschulen Einzug gehalten, die dieser Entwicklung durch Rechner-Pools und Labors Rechnung getragen haben in denen Computer für die Studenten fast jederzeit zur Verfügung stehen. In der letzten Zeit wurde nun das Schlagwort des ,,ubiquitous computing``, also der ,,Allgegenwärtigkeit von Informationsverarbeitung`` geprägt. Überall und jederzeit Zugriff auf Informationen und Netzwerke zu haben, ist wichtiger denn je. Immer mehr Studenten besitzen schon zu Studiumsbeginn einen Laptop und wollen diesen auch an der Hochschule einsetzen. Dies schließt auch die Benutzung des hochschulinternen Netzes und des Internets ein. Sie wollen zum Beispiel parallel zur Vorlesung Zugriff auf erklärende und weiterführende Materialien haben und Übungen oder Hausaufgaben auf ihrem eigenen Rechner an der Hochschule erledigen.

Der Zugriff auf Netzwerke muss aber zum einen auf die berechtigten Personen eingeschränkt werden, was gerade bei Funknetzen wichtig ist, auf die ja auch aus gewisser Entfernung noch zugegriffen werden kann. Zum anderen bedarf es auch eines Schutzes der Benutzer voreinander, so dass zur Wahrung der informationellen Selbstbestimmung niemand die Daten eines anderen einsehen kann.

In dieser Arbeit wird eine Lösung vorgestellt, die gleichermaßen für Übungsräume mit Netzsteckdosen sowie für Funknetze verwendet werden kann. Als Basis wurde dabei mit IPSec bewußt eine Technologie verwendet, die bereits jetzt breite Unterstützung erfährt und durch die Tatsache, dass IPSec auch fester Bestandteil von IPv6 ist, gute Zukunftschancen besitzt.

Als Hardware wurde dabei auf einen Linux-Router aus handelsüblichen PC-Komponenten gesetzt, weil dies zum einen als eine kostengünstige Lösung erscheint und dieser zum anderen in Zukunft weitere Dienste übernehmen kann.

Die Lösung ist zwar nicht ohne Mängel - die größtenteils auf das noch geringe Alter der IPSec-Implementationen zurückzuführen sind - aber durchaus praktikabel und bereits heute einsetzbar.

Inhalt

Einleitung

An der FH München soll den Studenten und Mitarbeitern mit mobilen (eigenen) Rechnern der Zugang in das Hochschulnetz sowie das Internet zur Verfügung gestellt werden. Hierfür wird ein Funknetz nach IEEE 802.11b (oder schnellere Varianten) zum Einsatz kommen, um den sonst nötigen Aufwand für die zusätzliche Verkabelung des Gebäudes zu vermeiden.

Diese Vernetzung soll auf eine sichere Art und Weise durchgeführt werden, wobei hier sowohl die missbräuchliche Nutzung des Netzes als auch das Belauschen der Kommunikation zu verhindern sind.

Thema

Heutzutage ein WaveLan-Netzwerk aufzubauen ist nicht schwierig. Die notwendigen Komponenten (Accesspoint, WaveLan-Karten) sind in jedem gut sortierten Computerladen erhältlich. Auch die Konfiguration der einzelnen Komponenten ist einfach, und selbst für einen Neuling in diesem Gebiet schnell durchzuführen. Allerdings weisen die derzeit üblichen Funknetze erhebliche Mängel in der Sicherheit auf. Gerade da ein solches Funknetz oft auch noch außerhalb des Gebäudes empfangen werden kann, besteht die Gefahr, dass unberechtigte Zugriff darauf nehmen. Diese Gefahr zu minimeren, ohne die Benutzer zu sehr zu Beeinträchtigen, ist Ziel dieser Arbeit.

Um dies zu erreichen wird zunächst in Kapitel 2 zusammengefasst an welchen Eckdaten sich das Projekt orientieren muss. Hierzu gehört in diesem Fall in erster Linie die Technik, die an der FH bereits eingesetzt wird bzw. eingesetzt werden soll, sowie eine Liste von Anforderungen, die eine erfolgreiche Lösung erfüllen sollte.

In Kapitel 3 schließt sich dann eine Recherche-Phase an, in der mögliche Lösungen gesucht, analysiert und anhand der oben zusammengestellten Anforderungen kurz bewertet werden. Anhand dessen wird eine Entscheidung getroffen, welche Lösung die Bestmögliche scheint.

Daraufhin wird in Kapitel 4 versucht die gewählte Lösung exemplarisch in einer Installation zu implementieren. Dabei wird genau auf Schwierigkeiten und Schwächen eingegangen und Möglichkeiten zu deren Umgehung aufgezeigt.

In Kapitel 5 wird noch einmal beleuchtet, inwiefern die Lösung tatsächlich für den praktischen Einsatz geeignet ist, und welche Teile eventuell noch überdacht werden sollten.

Kapitel 6 schließt mit einem Fazit über die Erfahrungen, die im Rahmen dieser Arbeit gesammelt wurden.

Zuletzt finden sich in Kapitel 7 und 8 zwei Anleitungen, mit denen die vorgestellte Lösung schnell aufgesetzt und benutzt werden kann.

Technik und Anforderungen

Vorbedingungen

Einführende Gespräche mit Herrn Köhler ergaben, dass ein Funknetz für mobile Clients eingesetzt werden soll und diese Clients größtenteils private Rechner der Teilnehmer sein werden. Eine Übertragung auf Übungsräume mit einem kabelbasierendem Netz, in dem die Übungsteilnehmer ihre mitgebrachten Laptops o.ä. anschließen, sollte aber auch ins Auge gefasst werden. Des weiteren müssen lediglich IP-basierte Dienste zugreifbar sein, d.h. auf nicht IP-basierte Protokolle wie beispielsweise IPX oder NetBEUI muss keine Rücksicht genommen werden.

Anforderungen

In weiteren Gesprächen mit Herrn Köhler und Herrn Ratko wurde eine Liste von Anforderungspunkten erstellt:

Sicherheit
Das Netzwerk, in dem sich die mobilen Geräte aufhalten, soll ``sicher`` sein. Sicherheit bedeutet hier insbesondere:
- Authentizität
  Die Nutzer müssen authentifiziert werden, insbesondere soll niemand außer den registrierten Benutzern das Netzwerk nutzen können.
- Geheimhaltung
  Niemand (möglichst auch nicht andere registrierte Nutzer) soll den Datenverkehr eines Nutzers belauschen können.
Einfachheit
Da Rechner aus dem privaten Besitz von Studenten und Mitarbeitern an diesem Netz teilnehmen sollen, kann nicht mit einer zentral administrierten Lösung gearbeitet werden. Deshalb muss die notwendige Installation und Konfiguration für den Benutzer möglichst einfach gehalten sein.
Portabilität
Da, wie bereits beim letzten Punkt genannt, private Rechner am Netzwerk teilnehmen sollen, muss die Lösung möglichst portabel sein, also auf einer großen Anzahl unterschiedlicher Betriebssysteme verfügbar sein.
Folgende Betriebssysteme kommen derzeit zum Einsatz:
- Windows-basierte: Windows 95, 98, ME; Windows NT 4.0, Windows 2000 und Windows XP
- Unix-basierte: verschiedene Linux-Distributionen, *BSD (FreeBSD, NetBSD, OpenBSD), MacOS X
Offener Standard
Hiervon erhoffen wir uns zum einen eine erhöhte Sicherheit, da von jedermann nachgeprüft werden kann, ob die verwendeten Algorithmen wirklich sicher sind, als auch eine Zukunftssicherheit, da sich ein offener Standard vermutlich besser am Markt durchsetzen kann.
Kostengünstig
Von den einzelnen Teilnehmern kann nicht verlangt werden, dass sie erst Software käuflich erwerben müssen, bevor sie in das Hochschulnetz gelangen können, und einer Hochschule stehen für ein solches Projekt auch nur relativ begrenzte finanzielle Mittel zur Verfügung.

Die verschiedenen Verfahren

Übersicht

Eine Recherche brachte einige miteinander konkurrierende Protokolle zu Tage, die theoretisch für das anstehende Problem in Frage kommen. Zu jedem dieser Protokolle werden die im Rahmen dieser Diplomarbeit relevanten Positiv/Negativ-Punkte aufgeführt.

WEP - Wired Equivalent Privacy
In allen derzeit erhältlichen Funknetzkarten (nach IEEE 802.11[8] und höher) ist das Verschlüsselungsverfahren WEP fest implementiert. Dabei werden die Datenpakete auf OSI Layer 2, also direkt vor der Funkschnittstelle verschlüsselt.
- wird von allen derzeit auf dem Markt befindlichen Karten unterstützt.
- ist in der Hardware implementiert, und wird daher von (praktisch) allen Betriebssystemen unterstützt.
- funktioniert für alle Protokolle, nicht nur für IP.
- Die verwendete Verschlüsselung ist ungenügend und in kurzer Zeit zu brechen[1,2].
  Es gibt zwar diverse Ansätze, die Verschlüsselung zu verbessern, diese sind zur Zeit aber weder hinreichend verbreitet, noch zwischen den verschiedenen Herstellern kompatibel.
- Der Schlüssel ist allen Teilnehmern bekannt ( $\rightarrow$ Insider-Angriffe), und es existieren keine Vorrichtungen, um ihn periodisch wechseln zu können.
MAC Verifizierung
Bei diesem (derzeit weit verbreitetem Verfahren) werden die einzelnen Funknetzkarten anhand ihrer eindeutigen MAC-Adresse zentral freigeschaltet. Das heißt, Kommunikation findet von Seiten des Servers/der WaveLan-Basestation nur noch mit ausgewählten Clients statt. Eine Verschlüsselung des Netzwerkverkehrs findet hierbei nicht statt.
- Viele Accesspoints und Switches bieten dieses Feature bereits ab Werk.
- Keine Verschlüsselung.
- Bei den meisten gängigen Netzwerkkarten kann die MAC vom Benutzer geändert werden und somit die Adresse eines registrierten Benutzers verwendet werden.
PPTP - Point to Point Tunneling Protocol[4]
Dieses Protokoll ist eine vom Microsoft in Zusammenarbeit mit anderen Herstellern (wie z.B. 3com) definierte Erweiterung von PPP[6] die als RFC 2637 veröffentlicht wurde. Hierbei werden auf OSI Layer 3 IP Pakete in PPP Frames eingepackt, und dann (optional verschlüsselt) über eine TCP-Verbindung versendet. Für die Authentifikation und Verschlüsselung stehen mehrere Protokolle zur Auswahl wie z.B. MS-CHAP-v1/2 oder PAP).
- Gute Integration in Windows.
- Verschlüsselung mangelhaft[12,13].
- Keine breite Unterstützung auf anderen Plattformen.
L2TP - Layer 2 Tunneling Protocol[5]
Dieses von Microsoft, Cisco und Ascend entwickelte Protokoll setzt mit OSI Layer 2 eine Ebene tiefer als PPTP an und kann somit alle über Ethernet verwendeten Protokolle (z.B.: IP, NetBEUI oder IPX) übertragen. Zum Transport dieser Daten sind mehrere Möglichkeiten spezifiziert, im IP-Umfeld sind PPP-Frames über eine UDP-Verbindung üblich. Dieses Protokoll bietet selbst aber keinerlei Verschlüsselung und ist daher nur in Verbindung mit anderen Protokollen (z.B. IPSec) sinnvoll.
- Kann mehr als nur IP transportieren.
- Keine Verschlüsselung.
- Ausschließlich für Windows verfügbar.
IPSec - IP Security[3]
IPSec ist ein eigenes OSI Layer 3 Protokoll mit Authentifikation und Verschlüsselung. Es setzt direkt auf IP auf, und benutzt dazu die IP Protokollnummern 50¹ und 51². Es werden zwei verschiedene Kommunikationsmodi unterstützt: der ,,transport mode``, bei dem jeder Kommunikationspartner IPSec-fähig sein muss, und der für uns interessantere ,,tunnel mode``, der eine gesicherte Verbindung zu einem Gateway benutzt, über den alle Kommunikation abläuft.
- Wird von allen aktuellen Betriebssystemen unterstützt (Windows, Linux, MacOS X, FreeBSD, NetBSD, OpenBSD, Solaris 8)
- Herstellerunabhängig und bereits jetzt weit verbreitet.
- Fester Bestandteil von IPv6, sodass eine mögliche Umstellung hierauf besonders leicht ist.
- 'Relativ' neu und komplex, noch diverse Kinderkrankheiten.
- Wird von Microsoft erst ab Windows 2000 unterstützt.
- Das üblicherweise verwendete Schlüsselaustauschprotokoll (IKE) ist kompliziert, daher ist der Verbindungsaufbau eher langsam.

Entscheidung

In den Anforderungen spielt Sicherheit eine große Rolle. Dies spricht eindeutig für die Verwendung von IPSec, da die anderen Verfahren diesbezüglich alle diverse Mängel aufweisen. Da an der FH hauptsächlich Windows-Clients zum Einsatz kommen, sind bezüglich der Einfachheit von Microsoft entwickelte Verfahren wie PPTP, oder in Hardware implementierte wie WEP klar im Vorteil. Im weiteren Rahmen dieser Arbeit muss also darauf geachtet werden, das Verfahren für den Benutzer möglichst einfach zu halten. Aber auch hier ist absehbar, dass mit wachsender Verbreitung von IPSec die Benutzung unter zukünftigen Windows-Version vereinfacht wird. Bei der Portabilität ist WEP als Hardware-basiertes Verfahren natürlich klar im Vorteil. Unter den Software-basierten ist IPSec deutlich führend. Viele Betriebssysteme unterstützen IPSec bereits heute, bei anderen kann es in Form von Patches nachgerüstet werden und selbst Routerhersteller wie z.b. Cisco unterstützen es bereits. Bei der Offenheit besticht IPSec durch die Tatsache, dass mehrere unabhängige und freie Implementierungen existieren. Preisgünstig sind alle vorgestellten Verfahren, für keines davon fallen notwendigerweise Kosten an, lediglich die Hard- und Software des Servers muss geeignet ausgewählt werden.

Die Entscheidung fällt hier also klar zu Gunsten von IPSec. Von den geforderten Betriebssystemen wird es von Linux³, FreeBSD, NetBSD, OpenBSD, MacOS X⁴und Windows 2000/XP unterstützt. Für Windows-Versionen die noch kein IPSec können, muss noch ein geeigneter Client gefunden werden. Erste Untersuchungen nach gibt es mehrere Firmen, die einen solchen Client zur Verfügung stellen⁵. Das bekannteste diesbezügliche Produkt ist der PGPNet Freeware-Client, der in der Version 7.03 vorliegt. Dieser unterstützt allerdings den in diesem Szenario benötigten ,,Tunnel Mode`` nicht. Auskünften einer Mailingliste⁶zufolge kann diese Beschränkung allerdings durch den Config-Import aus einem Textfile umgangen werden. Im praktischen Versuch konnten leider keine befriedigenden Ergebnisse erzielt werden (beim Import verschiedener Testfiles wurde meist ein Bluescreen erzeugt), und daher wurde diese Möglichkeit verworfen.

Mittlerweile bietet auch die Firma ssh.com ihr VPN-Produkt SSH Sentinel⁷ frei zum nichtkommerziellen Einsatz an. Erste Tests liefen vielversprechend, sowohl die GUI ist übersichtlich, als auch die Dokumentation ausführlich⁸.

Als drittes Produkt kam ursprünglich noch der Cisco vpnclient infrage, der aber Recherchen zufolge nur korrekt mit den Hardware-VPN-Routern der gleichen Firma sprechen kann, welche relativ teuer sind, deshalb soll für oben genannte Windows-Versionen also der ,,SSH Sentinel``-Client zum Einsatz kommen.

Konfiguration

Nun muss getestet werden, ob die bisher skizzierte Lösung auch in der Praxis durchführbar ist. Dazu wird ein Testnetz aufgebaut, in dem Interoperabilitätsprobleme entdeckt und soweit möglich umgangen und Konfigurationen für die verwendeten Programme erarbeitet werden sollen.

Testnetz

Zuerst musste das Testnetz physikalisch aufgebaut werden. Dabei war es nicht unbedingt nötig, WaveLan einzusetzen, weil IPSec vollständig IP-basierend ist und daher über ein Funknetzwerk und ein kabelbasiertes Netzwerk gleichermaßen funktioniert.

Der gesamte Testaufbau wurde bei mir zu Hause durchgeführt. Als 'Client'-Rechner kam mein Arbeitsplatzrechner, basierend auf einem AMD Athlon 600MHz Prozessor - eine zur Zeit durchaus übliche Leistungsklasse - zum Einsatz. Das 'Gateway' wurde aus älteren Einzelteilen zusammengeschraubt und enthält einen Pentium 60. Es bleibt noch zu prüfen, wie viele Clients mit einem solchen, eher veralteten Rechner bedient werden können.

Das 'Gateway' besitzt 2 Ethernetkarten, eine für das öffentliche, zu schützende, Netz und die andere für die Anbindung an das restliche Netz. Im Einsatz kann dann eine herkömmliche WaveLan Basisstation an das öffentliche Netz angeschlossen werden, oder alternativ die Ethernetkarte direkt durch eine WaveLan-Karte ersetzt werden.

**Abbildung:** Das Netz im Überblick
$\includegraphics{img/Netz}$

Gateway

Als Betriebssystem für den Gateway-Rechner wurde von Seiten der FH Linux gefordert. Als Distribution wurde Debian 'Potato' gewählt, was aber im Weiteren keine große Rolle spielt.

Da Linux zur Zeit IPSec noch nicht standardmäßig unterstützt, muss die nötige Funktionalität mittels eines Patches nachgerüstet werden. Die derzeit einzig brauchbare Implementation ist Free S/WAN, die im Moment in der Version 1.98b vorliegt. (Es gibt mit NIST Cerberus⁹noch eine IPSec Reference Implementation für Linux, die aber schlechter dokumentiert ist, und scheinbar auch nicht weiterentwickelt wird.)

Auf das Einbauen der Patches und das darauf nötige Neukompilieren des Kernels soll hier nicht weiter eingegangen werden, da die Dokumentation der Patches hierzu ausreichend ausführlich ist.

Als weitere Serverprogramme, die auf dem Gateway laufen sollen, wurden noch ein DHCP Server und ein HTTP Server installiert, auf deren Funktion später genauer eingegangen werden soll.

Client

Für die Tests wurden Windows 2000 und Windows XP als Client verwendet, weil diese (laut Angaben von Herrn Köhler) die zur Zeit am meisten verwendeten Betriebssystemversionen in und um die FH sind.

Aus verschiedenen Quellen (u.A. [9]) war zu ersehen, dass die Verwendung des nativen IPSec von Windows 2000 nicht ohne Probleme ist. Zum einen ist die Konfiguration über die ``mmc``¹⁰ für den Endbenutzer unzumutbar kompliziert - dies würde somit die Erstellung von automatisierten Einrichtungsscripten voraussetzen, die wiederum Programme benötigen, die teilweise dann erst von Microsoft heruntergeladen werden müssten[10]. Zum anderen bestehen auch noch diverse Interoperabilitätsprobleme mit Free S/WAN an Stellen, an denen der Standard anscheinend Interpretationsspielraum lässt. Diese Probleme konnten in ersten Versuchen auch bestätigt werden, sodass im Weiteren davon abgesehen wurde, die Windows-interne IPSec-Implementierung zu verwenden.

Da der SSH Sentinel auch unter neueren Windows-Versionen funktioniert, wird im Weiteren darauf verzichtet, eine extra Lösung für aktuelle Windows-Versionen zu erarbeiten. Deshalb wurde auch nicht weiter untersucht, inwiefern sich die IPSec-Implementation von Windows XP von der in Windows 2000 unterscheidet. Diese Entscheidung sollte vermutlich später, wenn eine ausreichende Verbreitung von neueren Windows-Versionen vorliegt, noch einmal überprüft werden.

Authentifikation

Die Authentifizierung der Nutzer muss noch geregelt werden. Da IPSec keine Login/Passwort basierende Authentifizierung vorsieht [Es gibt Erweiterungen einzelner Hersteller (z.B. von Cisco), die allerdings weder hinreichend verbreitet sind, um breite Unterstützung zu finden, noch offiziell standardisiert sind.], besteht die Möglichkeit, sich mit einem 'pre-shared-key' zu authentifizieren, was aus mehreren Gründen nicht verwendet werden kann:

Free S/WAN kann kein 'pre-shared-key' in einem ,,roadwarrior`` Setup, also bei Clients mit wechselnden IP-Adressen.
Als Alternative könnten hier fixe IP-Adressen für die einzelnen Clients vergeben werden - das erhöht allerdings den Verwaltungsaufwand und ist für den Benutzer zu kompliziert, da er diese entweder manuell einstellen, oder für die Verwendung von DHCP seine MAC-Adresse registrieren lassen müsste.
'pre-shared-keys' liegen auf dem Server im Klartext.
Eigentlich wünschenswert wäre, wenn die User ihre bestehenden Passwörter weiterverwenden könnten¹¹. Dies wäre aber ein ernstzunehmendes Sicherheitsrisiko für den Fall, dass in den Rechner eingebrochen wird. Auch müsste ein eigener Repliziermechanismus geschaffen werden, um Passwortänderungen zu verteilen.
Eine Alternative wäre, den Benutzern hierfür ein neues Passwort zuzuweisen - dies ist allerdings auch nicht unbedingt wünschenswert.

Aus diesem Grund empfiehlt sich stattdessen die Verwendung von unterschriebenen X.509-Schlüsseln für diesen Zweck. Free S/WAN kann dies zwar nicht 'ab Werk', aber mit einem Patch¹², der zur Zeit in der Version 0.9.15 vorliegt.

Bei der Verwendung von X.509-Schlüsseln gibt es wiederum zwei Möglichkeiten vorzugehen. Beiden Verfahren gemeinsam ist, dass jeder Benutzer einen eigenen X.509-Schlüssel hat, mit dem er sich beim Server authentifiziert. Der Unterschied liegt hier also hauptsächlich in der Verwaltung. Beim Verfahren ohne Unterschriften müssen alle Benutzer-Schlüssel auf dem Server¹³ einzeln bekannt sein, damit diese als legitim erkannt werden können. Beim Verfahren mit Unterschriften dagegen wird der Schlüssel jedes Benutzers mit einem Zertifikat versehen, das den Benutzer legitimiert. Dabei muss auf dem Server nun nur noch der Zertifizierungsschlüssel bekannt sein. Dies hat insbesondere im Falle mehrerer verteilter Server den Vorteil, dass keine Replikation des Datenbestandes nötig ist. Außerdem kann die zertifikatsausgebende Stelle beliebig von den Servern getrennt sein.

Im Folgenden wird hier die zweite Option verfolgt. Dieser Aufbau entspricht technisch einer CA (Certificate Authority), allerdings ist der Aufand geringer als üblich, da keine Bindung des Benutzers zu seinem X.509-Schlüssel vorgenommen wird. Es wird lediglich die Berechtigung das IPSec-gesicherte Netz für jeweils das aktuelle Semester benutzen zu dürfen erteilt¹⁴.

Erlangung der Zertifikate

Der Benutzer muss nun also einen unterschriebenen X.509-Schlüssel erhalten. Prinzipiell bieten sich dabei mehrere Möglichkeiten.

Der SSH Sentinel erzeugt schon während der Installation einen X.509-Key für den Rechner. Um den Benutzer mit diesem Schlüssel zu authentifizieren, muss dieser Schlüssel also nur noch ein Zertifikat erhalten. Hierfür bietet der Client die Möglichkeit des sogenannten ``Online Certificate Enrollments``. Hierbei wird das erzeugte Zertifikat über ein eigenes Protokoll an einen Server geschickt, der mittels eines mitgeschickten Passworts den Request überprüft, und das signierte Zertifikat zurückschickt.

Da dies eine für den Benutzer sehr komfortable Lösung darstellt und der SSH Sentinel dies unterstützt, sollte diese verwendet werden. Der SSH Sentinel bietet hierfür zwei Protokolle an, zum einen SCEP[14], das Simple Certificate Enrollment Protocol, das von der Firma Cisco entwickelt wurde und derzeit nur als Internet-Draft verfügbar ist, und zum anderen CMP[7], das Certificate Management Protocol, das bereits als RFC 2510 vorliegt.

Für CMP gibt es derzeit leider keine einzige offene, fertige Implementierung, lediglich die 'cryptlib'¹⁵besitzt laut ihrer Dokumentation die benötigten 'Bausteine' um dieses Protokoll zu realisieren. Nachrichten auf der betreffenden Mailingliste zufolge erschien es aber nicht sinnvoll, im Rahmen dieser Arbeit einen CMP-Server zu implementieren. Für SCEP gibt es andererseits eine freie Implementierung, OpenSCEP¹⁶, die derzeit in der Version 0.4.2 verfügbar ist. OpenSCEP setzt einen funktionierenden Webserver voraus und besteht größtenteils aus CGI-Programmen und dazugehörigen html-Dateien. Dieses Softwarepaket ist zwar für den Einsatz unter Linux gedacht, aber nicht besonders portabel. So waren diverse Modifikationen nötig, um es korrekt zum Laufen zu bekommen.

Obwohl es gelang, OpenSCEP zum Funktionieren, also dem Akzeptieren der Zertifikatsanforderung und zum Erteilen des Zertifikats zu bekommen, lehnte der SSH Sentinel die so erteilten Zertifikate mit der Fehlermeldung ,,Online Enrollment failed`` ab.

Eine Nachfrage bei der Firma SSH ergab lediglich eine Antwort, dass ihr Produkt mit anderen Programmen (z.B. der Firma Cisco) fehlerfrei arbeiten würde und darüber hinaus keine Möglichkeit bestehe herauszufinden, warum das Zertifikat abgelehnt werde. Die Entwickler von OpenSCEP sandten bis zum heutigen Datum gar keine Antwort auf meine Anfrage.

Daher musste diese Möglichkeit, für den Benutzer ein Zertifikat zu erlangen, leider fallen gelassen und eine andere Lösung gefunden werden.

Wenn man nach wie vor davon ausgeht, dass der Benutzer seinen X.509-Schlüssel selbst erzeugt, dann muss sowohl der Transport zum Server und zurück gesichert, als auch die Authentifikation des Benutzers gewährleistet sein. Die offensichtlichste Methode wäre hierbei die, dass der Benutzer seinen Schlüssel auf eine Floppy Disk (o.ä.) speichert, und damit, sowie mit seinem Ausweis im Rechenzentrum vorstellig wird. Dort würde dann die Identität des Benutzers geprüft, sowie sein Schlüssel signiert.
Dies ist aber unpraktikabel, da unbequem für den Nutzer und seitens der FH zu personalaufwändig. Andere Lösungen setzen einen gesicherten Dateitransport vom Rechner des Benutzers zum Server, und wieder zurück, voraus. Dies ist aber unnötigerweise kompliziert, denn es gibt noch eine zweite Möglichkeit:

Man lässt den Server den neuen Schlüssel selbst erstellen und dabei signieren. So ist der Aufwand für den Benutzer geringer als bei der vorherigen Methode und auch einfacher zu implementieren, da nicht mehr separat geprüft werden muss, ob der Benutzer beim Erstellen des Schlüssels korrekte Daten eingegeben hat. Dies setzt natürlich ein gewisses Vertrauen in den Server vorraus, das aber hier als gegeben betrachtet werden kann, da der Server bereits die Authentifikationsdaten des Benutzers erhält.

Die einfachste Lösung schien hier, den Benutzer sich auf einer mit SSL gesicherten Webseite authentifizieren zu lassen (ähnlich dem bei der Notenbekanntgabe genutzten System) und bei Korrektheit der Daten ein für ihn individuell erzeugtes Zertifikat zum Download anzubieten. Dieses muss dann lediglich in den SSH Sentinel Client importiert werden und zum Verbindungsaufbau verwendet werden.

Diese Lösung hat außerdem den Vorteil, dass sie auch für andere IPSec-Produkte verwendet werden kann, die kein ,,Online Certificate Enrollment`` anbieten, wie z.B. die IPSec-Lösungen unter den meisten Unix-artigen Betriebssytemen, und darüberhinaus lässt sie sich, leicht modifiziert, auch mit einem Hardware-Token, wie z.B. der angedachten Studenten-Chipkarte benutzen.

Zertifikatsausgabe

Die Funktionalität der HTTPS-Website wurde dann der Einfachheit halber direkt auf dem Linux-Server implementiert, könnte aber auf jedem beliebigen Rechner laufen. Es können auch mehrere, räumlich und netztechnisch getrennte Instanzen davon betrieben werden, da keinerlei Abstimmung oder Kommunikation zwischen den Servern nötig ist. Allerdings muss der CA-Hauptschlüssel auf allen diesen Servern vorhanden sein, sodass es aus sicherheitstechnischen Überlegungen sinnvoll ist, nicht übermäßig viele Zertifikatsserver zu erstellen.

Das Script zu Zertifikatserstellung besteht im Wesentlichen aus drei Funktionen. Dem Empfangen der Benutzerdaten und deren Verifizierung, dem Erzeugen des Zertifikats und dem Download des Zertifikats. Eine kommentierte Version dieses Scripts ist in Kapitel 7.4 zu sehen. Das Überprüfen von Benutzername und Passwort wurde dabei explizit modular gehalten, damit es leicht an wechselnde Anforderungen angepasst werden kann.

Mit dem importierten Zertifikat kann dann im SSH Sentinel eine VPN Verbindung definiert werden. Dazu ist es nur nötig, das Zertifikat auszuwählen, den Namen des Gateway-Rechners anzugeben und, wie sich nach einem Test herausstellt, die Box ,,Use legacy proposal`` anzuwählen, da Free S/WAN sonst den Verbindungsaufbauwunsch nicht versteht.

Nun kann die Verwendung von IPSec durch einen einfachen Mausklick im Kontextmenü des SSH Sentinel ein- und ausgeschaltet werden, wobei sich herausstellte, das für Linux ein weiterer Patch¹⁷benötigt wird, um einen sauberen Verbindungsabbau zu gewährleisten, da Free S/WAN bisher überhaupt keinen geordneten Verbindungsabbau vorsieht.

Bewertung

Nachdem die Aufgabenstellung nun bearbeitet ist, und eine Lösung geschaffen wurde, gilt es hier nun abzuwägen wie gut die Lösung die Anforderungen erfüllt, wo die Schwachpunkte liegen, in welchen Teilen sich die Voraussetzungen und technischen Gegebenheiten in Zukunft verändern werden, oder gar was in einer zukünftigen Arbeit verbessert werden könnte.

Ausführung

Zuerst einmal ist zu bemerken, dass die bisher vorgestellte Lösung funktioniert und so auch im täglichen Einsatz verwendet werden kann.

Die meisten der Vorgaben aus Kapitel 2.2 werden erfüllt, dennoch soll nicht verschwiegen werden, dass auch noch Kritikpunkte bleiben.

Zum einen ist da die Verwendung des SSH Sentinel Clients für Windows. Wenn auch die Lizenz ausdrücklich eine kostenlose Benutzung im Bereich der Bildung und anderem nichtkommerziellen Umfeld zulässt, so wäre doch eine weniger restriktive Lösung wünschenswert. Hier bleibt außerdem zu untersuchen, ob dies nicht auch mit Bordmitteln von Windows XP und etwaigen Nachfolgeversionen realisiert werden könnte, da die Bedeutung der älteren Windows-Versionen im Laufe der Zeit abnehmen wird.

Obwohl die Bedienung für den Benutzer relativ einfach ist (siehe 8), hätte sie aber durch die Verwendung eines ,,Online Enrollment Protocols`` noch vereinfacht werden können. Hier ist zu überlegen, ob in einer weiterführenden Arbeit ein Server nach dem SCEP oder CMP Standard implementiert werden sollte. In diesem Fall währen die Änderungen an der hier vorgestellten Lösung relativ gering. Der hier eigens implementierte Zertifikatsserver würde dann wegfallen und durch die Verwendung von SCEP/CMP ersetzt. Dies würde dem Benutzer das Besuchen einer extra Webseite mit anschließendem Zertifikats-Import ersparen, da er dies direkt innerhalb des SSH Sentinel erledigen könnte. Auf der Serverseite wäre lediglich darauf zu achten, dass das IPSec den selben CA-Schlüssel wie der SCEP/CMP-Dienst benutzt.

Ein weiteres Problem, das erst im Laufe der Arbeit sichtbar wurde ist, dass derzeit keine verfügbare IPSec-Implementation ,,IPSec over IPSec`` unterstützt. Wenn also ein Benutzer das WaveLan mit IPSec benutzt, kann er nicht zur gleichen Zeit ein IPSec-VPN zu einem anderen Standort (z.B. Firma/zu Hause) aufbauen. Es wird sich zeigen, ob sich dies in der Zukunft ändert. Derzeit ist es mangels Verbreitung von reinen IPSec-Lösungen kein Problem, da andere VPN-Protokolle (wie z.B. PPTP) ohne Probleme funktionieren.

Ausblick/Zusammenfassung

Die Beispielimplementation in dieser Arbeit wird an der FH vorgeführt, um die Benutzbarkeit zu demonstrieren. Die notwendige Doumentation, um einen Linux-Server in einen Router zu verwandeln, ist in Kapitel 7 vorhanden. Die besprochenen Scripte und Konfigurationsdateien sind ebenfalls auf der beigelegten CD vorhanden.

Es bleibt zu hoffen, dass die zuständigen Personen an der FH hinreichend überzeugt werden können, diese Lösung an der FH auch praktisch einzusetzen. Damit sich die Ergebnisse dieser Arbeit eventuell im nächsten Semester im Fachbereich 07 bewähren können.

Fazit

Obwohl das grundsätzliche Ziel dieser Arbeit schon von vornherein festgelegt war und auch die Entscheidung für IPSec relativ rasch getroffen wurde, steckte, wie so oft, der Teufel im Detail.

Die Problematik der mangelnden Interoperabilität des Windows 2000-IPSec mit Free S/WAN war ursprünglich nicht abzusehen. Auch die Suche nach einem geeigneten IPSec-Client für Windows gestaltete sich schwieriger als erwartet. Die diversen in Marketing-Kauderwelsch gehaltenen Ankündigungen von Firmen machten es schwierig, eine geeignete Entscheidung zu treffen. Dies führte auch zur anfänglichen Fehlentscheidung, den PGPnet Client zu verwenden. Zum Glück konnte mit dem SSH Sentinel dann eine adequate Lösung gefunden werden.

Besonders bedauerlich ist auch das Scheitern der Bemühungen bezüglich des ,,Online Enrollments``. Hier wäre eine Verbesserung durchaus wünschenswert.

Abschließend bleibt zu bemerken, dass ich im Laufe der Arbeit einiges gelernt habe. Dass Standards auch nur so gut sind, wie ihre Implementationen, denn das Papier, auf dem sie geschrieben sind, ist geduldig. Dass Hilfestellungen von Autoren freier Software oft genauso schwierig zu bekommen ist wie von Firmen. Und das am Schluß eines Projektes immer die Zeit knapp wird. Größtenteils bestätigt gefunden habe ich meine Vorliebe für sogenannte ,,freie Software``. Deren Qualität ist zwar, wie ich feststellen musste, oft auch nicht besonders gut, aber immerhin bietet sie in der Regel weit umfangreichere Debugging-Möglichkeiten.

Anleitung zur Installation des Linux-Servers

Diese Anleitung soll es ermöglichen, bei Bedarf weitere Linux-Server aufzusetzen. Die Beispielimplementierung erfolgte mit einem Debian-Linux ,,potato``, ist aber prinzipiell leicht mit jeder anderen Linux-Distribution nachzuvollziehen. Die einzig variierenden Punkte hierbei sind die Art und Weise, in der einzelne Pakete nachinstalliert werden, und die Pfade, unter denen deren Konfigurationsdateien dann liegen. Des Weiteren wird die hier verwendete Software natürlich weiterentwickelt. Daher ist davon auszugehen, dass sich die Versionsnummern der Software/Patches ändern werden. Die in teletype wiedergegebenen Zeilen sind (bis auf die oben angesprochenen Änderungen) direkt einzugeben.

Kernel

Da die IPSec-Implementierung Free S/WAN in Linux leider immer noch nicht standardmäßig enthalten ist, muss diese per Hand in den Kernel gepatched werden. Hierzu benötigen wir zuerst den Quellcode des Kernels¹⁸:

cd /usr/src
wget ftp://ftp.kernel.org/pub/linux/kernel/v2.2/\
linux-2.2.22.tar.bz2

Zusätzlich benötigen wir natürlich auch den Free S/WAN-Patch:

wget ftp://ftp.xs4all.nl/pub/crypto/freeswan/\
freeswan-1.98b.tar.gz

Da wir mit Zertifikaten arbeiten, benötigen wir hierfür ebenfalls noch einen Patch:

wget http://www.strongsec.com/freeswan/\
x509patch-0.9.15-freeswan-1.98b.tar.gz

Außerdem noch ein weiterer Patch, um einen sauberen Verbindungsabbau zu ermöglichen.

wget http://open-source.arkoon.net/freeswan/\
notify_delete-freeswan-1.98b-020724.diff.gz

Nun müssen die Sourcen ausgepackt und die Patches angewendet werden.

bzcat linux-2.2.22.tar.bz2| tar xf -
tar xzf freeswan-1.98b.tar.gz
tar xzf x509patch-0.9.15-freeswan-1.98b.tar.gz
cd freeswan-1.98b
patch -p1 ../x509patch-0.9.15-freeswan-1.98b/freeswan.diff
zcat ../notify_delete-freeswan-1.98b-020724.diff.gz|patch -p1

Der Kernel muss nun noch passend konfiguriert werden. Dazu rufen wir das Konfigurationsinterface auf. Danach kompilieren wir einen neuen Kernel.

cd ../linux-2.2.22
make menuconfig
cd ../freeswan-1.98b
make oldgo

Nach dem Ende des Kompiliervorgangs müssen der Kernel und etwaige Module installiert werden. Das Vorgehen hierbei ist stark von der verwendeten Distribution abhängig.

cp System.map /boot/System.map
cp arch/i386/boot/bzImage /boot/vmlinuz
cp .config /boot/config
lilo

Nun werden die im weiteren Verlauf benötigten Services installiert. Dies geschieht am besten mit dem jeweiligen, zur Linux-Distribution gehörenden Paketverwaltungstool. Bei debian ist dies apt-get:

apt-get install openssl
apt-get install apache
apt-get install apache-ssl
apt-get install bind
apt-get install dhcp

Konfiguration IPSec

Zur korrekten Funktion von IPSec müssen zwei X.509 Schlüssel erzeugt werden. Der erste ist der Zertifikations-Schlüssel zur Identifikation der Clients. Dieser ist für alle Gateways gleich und muss also, falls mehrere Gateways zum Einsatz kommen, auf die anderen Rechner kopiert werden. Der Einfachheit halber verwenden wir Steve Hensons CA.pl Skript, welches beim openssl package mitgeliefert wird. In diesem Schritt wird zusätzlich noch nach einem Passwort gefragt, welches später noch gebraucht.

mkdir /root/ssl
cd /root/ssl
cat <<EOF|/usr/lib/ssl/misc/CA.pl -newca

DE
-
Muenchen
FHM
IPSec
ipsec.fhm.edu
ipsec@fhm.edu
EOF

Als zweites wird ein Schlüssel für den lokalen Rechner zur Verschlüsselung erzeugt. Auch hier wird ein Passwort vergeben, das später noch gebraucht wird.

cat <<EOF|/usr/lib/ssl/misc/CA.pl -newcert

DE
-
Muenchen
FHM
IPSec-Host
ipsec@host1.fhm.edu
ipsec@host1.fhm.edu
EOF

Nun muss der Schlüssel des lokalen Rechners noch signiert werden, hierbei sind die beiden oben vergebenen Passwörter der Reihe nach einzugeben.

cat <<EOF|/usr/lib/ssl/misc/CA.pl -signcert
y
y
EOF

Nun müssen die Schlüssel an die richtige Stelle kopiert, und in den Konfigurationsdateien eingetragen werden. Anstelle von 10.10.0.1 ist die IP-Adresse der Ethernetkarte im ,,öffentlichen`` Netz zu wählen.

cp newreq.pem /etc/ipsec.d/private/host_key.pem
chmod 400 /etc/ipsec.d/private/host_key.pem
cp newcert.pem /etc/ipsec.d/host_cert.pem
echo ': RSA host_key.pem "<host-password"'>/etc/ipsec.secrets
cat <<'EOF' >/etc/ipsec.conf
config setup
        # THIS SETTING MUST BE CORRECT or almost nothing will work:
        interfaces="ipsec0=eth1"
        klipsdebug=none
        plutodebug=none
        plutoload=%search
        plutostart=%search
        uniqueids=yes

conn %default
        keyingtries=0
        disablearrivalcheck=no
        keyexchange=ike
        ikelifetime=240m
        keylife=60m
        pfs=yes
        compress=no
        authby=rsasig
        right=%any
        rightrsasigkey=%cert
        left=10.10.0.1
        leftcert=host_cert.pem
        auto=add
EOF

Damit ist die Konfiguration des IPSec abgeschlossen.

Webserver

Der HTTPS-Webserver benötigt zum korekten funktionieren auch ein Zertifikat, das aber bereits vom Paketverwaltungssystem angelegt worden sein sollte.

Darübehinaus sollten die eingestellten Pfade überprüft werden. Dieser Text geht im weiteren davon aus, das CGI-Scripten unter /usr/lib/cgi-bin, und die HTML-Dateien unter /var/www liegen.

Zertifikatsserver-Script

Nun muss der Zertifikatsserver installiert werden. Dazu müss das Installationsarchiv von der beiliegenden CD ausgepackt werden:

cd /root
mount /cdrom
tar xvzf /cdrom/linux/DA.tgz

Dieses Archiv enthält das CGI-Script (cert.pl und cgi-lib.pl) das nun in das CGI-Directory und eine Einstiegsseite die in das HTML-Directory des installierten Webservers gelegt werden muss.

cd DA
mv cert.pl cgi-lib.pl /usr/lib/cgi-bin/
mv index.html /var/www/

Dieses Script benutzt die soeben ausgepackten Templates unter /root/DA/templates, mit denen das Aussehen und die Meldungen konfiguriert werden können.
Auch muss der SSH Sentinel zum Download in das Webserver-Verzeichniss gelegt werden.

mv SSHSentinel1.3.2.exe /var/www/

Anschließend müssen noch ein paar Berechtigungen angepasst werden, so dass der Zertifikatsserver auf die Zerfikatsdateien zugreifen kann. Auch muss ein cron-job angelegt werden, der dafür sorgt, dass die herunterladbaren Zertifikate nach einer gewissen Zeit wieder gelöscht werden.

mkdir /root/certs
chgrp www-data certs ssl/demoCA ssl/demoCA/newcerts
chmod 1770 certs
chmod g+w ssl/demoCA ssl/demoCA/newcerts
echo '*/5 * * * * find /root/certs -xdev -maxdepth 1'\
'-type f -amin +5 -print0|xargs -0 rm -f' | crontab -

DHCP

Der DHCP-Server muss für das ,,öffentliche`` Subnetz konfiguriert werden. Dazu müssen ein paar Einträge in die /etc/dhcpd.conf gemacht werden. Auch hierbei sind die IP-Adressen an die tatsächlich vorhandenen anzupassen.

cat <<EOM >/etc/dhcpd.conf
option domain-name "ipsec.fhm.edu";
option domain-name-servers 10.10.0.1;

option subnet-mask 255.255.255.0;
default-lease-time 30000;
max-lease-time 43200;

subnet 10.10.0.0 netmask 255.255.0.0 {
  range 10.10.1.1 10.10.99.255;
  option routers 10.10.0.1;
}
EOM

DNS

Der Nameserver in erster Linie die Anfragen der Clients beantworten. Zusätzlich sollte er für das öffentliche Netz ein reverse-Resolving bereitstellen, damit alle Dienste reibungslos funktionieren.

Die dafür verwendeten Einträge in der named.conf sehen so aus:

echo <<EOF >>/etc/bin/named.conf
zone "ipsec.fhm.edu" {
        type master;
        file "/etc/bind/db.fwd";
};
zone "10.10.in-addr.arpa" {
        type master;
        file "/etc/bind/db.rev";
};
EOF

Die beiden Dateien db.fwd und db.rev sind als Beispiele auch auf der CD-Rom enthalten.

cp /cdrom/linux/db.* /etc/bind/

Damit ist die Installation abgeschlossen und der Linux-Server sollte neu gestartet werden, um alle Änderungen wirksam werden zu lassen.

Anleitung für Windows-Benutzer

Diese Anleitung ist für Studenten und Mitarbeiter der FH München gedacht, die aus einem mit IPSec gesicherten Netz (WaveLan oder Übungsraum) auf andere Rechner zugreifen wollen. Als Betriebssystem wird hierbei Windows XP vorausgesetzt, wobei die Lösung auch unter älteren Windows-Varianten funktionieren sollte. Hinweise für Benutzer von anderen Betriebssystemen finden sich am Ende des Dokuments.

Konfiguration von Windows

Der Rechner muss für die Verwendung von DHCP konfiguriert sein¹⁹. Beim Anschluss an das Netz (mittels WaveLan-Karte oder Ethernetkabel) wird dem Rechner dann automatisch eine eigene IP-Adresse zugewiesen.

Sollte DHCP bereits konfiguriert sein, so kann gleich mit Kapitel 8.3 fortgefahren werden.

Einrichtung von DHCP

Zuerst muss das Fenster Netzwerkverbindungen geöffnet werden. Der einfachste Weg ist mit einem Klick der Rechten Maustaste auf das Netzwerkumgebungs-Icon dessen Kontext-Menü zu öffnen, und darin den Punkt ,,Eigenschaften`` auszuwählen.

**Abbildung 2:** Netzwerkumgebung $\rightarrow$ Eigenschaften
$\includegraphics{img-win/d1}$

Im nun erscheinenenden Fenster muss wiederum durch Klicken der rechten Maustaste auf der LAN-Verbindung das Kontextmenü geöffnet werden, und darin der Punkt ``Eigenschaften`` ausgewählt werden.

**Abbildung 3:** Netzwerkverbindungen
$\includegraphics{img-win/d3}$

Nun muss durch Doppelklick auf den Eintrag ,,Internetprotokoll (TCP/IP)`` dessen Eigenschaftsfenster aufgerufen werden.

**Abbildung 4:** Eigenschaften von LAN-Verbindung
$\includegraphics{img-win/d4}$

Hier müssen die Punkte ,,IP-Adresse automatisch beziehen`` und ,,DNS-Serveradresse automatisch beziehen`` angewählt werden, um die Verwendung von DHCP zu aktivieren.

**Abbildung 5:** Eigenschaften von TCP/IP
$\includegraphics{img-win/d5}$

Danach können die verbleibenden Fenster mit ,,OK`` geschlossen werden. Nun wird der Rechner seine IP-Adresse immer mittels DHCP im lokalen Netzwerk erfragen.

Installation des SSH Sentinel

Nun kann von http://gateway/ der IPSec-Client ,,SSH Sentinel`` in einer aktuellen Version heruntergeladen werden.

Achtung: Der SSH Sentinel benoetigt zum korrekten Funktionieren eine korrekt eingestellte Systemuhr. Es empfiehlt sich vor Beginn der Prozedur zu kontrollieren ob das Datum stimmt.

Des weiteren funktioniert der SSH Sentinel Client leider nicht, wenn bereits der PGPNet-Freeware-Client installiert ist. Dieser muss also vorher deinstalliert werden.

Durch Doppelklick auf das Installationsprogramm wird die Installation gestartet. Nach einigen Momenten erscheint ein Begrüßungsfenster:

**Abbildung:** Begrüßung
$\includegraphics{img-win/i1}$

Nach einem Klick auf Next erscheint das ,,Licence Agreement`` welches durch einen Klick auf Yes bestätigt wird.

Im nächsten Fenster kann der Installationspfad gewählt werden.

**Abbildung 7:** Wahl des Installationspfades
$\includegraphics{img-win/i3}$

Wenn keine persönlichen Präferenzen dagegen sprechen, kann dieser so belassen und mit Next bestätigt werden. Das gleiche gilt für das nächste Fenster, in dem der Name des Unterpunkts im Start-Menü gewählt wird.

**Abbildung 8:** Select Program Folder
$\includegraphics{img-win/i4}$

Im nächsten Fenster werden Zufallszahlen erzeugt, die für die weitere Funktion des Clients benötigt werden.

**Abbildung 9:** Zufallszahlenerzeugung
$\includegraphics{img-win/i5}$

Hierzu muss lediglich die Maus so lange bewegt werden, bis der blaue Fortschrittsbalken den rechten Rand erreicht hat. Auch dieses Fenster wird danach durch betätigen der ,,Next >``-Schaltfläche erledigt.

In den nächsten zwei Schritten wird ein Schlüssel für den lokalen Rechner erzeugt, der in diesem Setup allerdings nicht weiter benötigt wird. Daher werden hier alle Einstellungen auf dem default belassen, und nur mit Next bestätigt.

Nun werden noch ein paar Geschwindigkeits- und Konsistenztests vorgenommen

**Abbildung 10:** Diagnostics
$\includegraphics{img-win/i9}$

die nach einem Moment ebenfalls mit Next bestätigt werden können. Zum Schluss muss, wie bei Windows üblich, der Rechner noch einmal neu gestartet werden:

**Abbildung 11:** Abschluss der Installation
$\includegraphics{img-win/iEND}$

womit die Installation des ,,SSH Sentinel`` abgeschlossen ist.

Erhalten des Zertifikats

Nun muss das X.509-Zertifikat für die Benutzung des Netzes beantragt werden. Dazu muss mit einem Webbrowser der URL https://gateway/ aufgerufen werden, und dem Link ,,Zertifikat beantragen`` gefolgt werden.

**Abbildung 12:** Zertifikat beantragen
$\includegraphics{img-win/cneu}$

In dem nun erscheinenden Formular muss die Benutzerkennung und das dazugehörige Passwort eingtragen werden. Schliesslich muss nur noch auf den ,,Submit``-Knopf geklickt werden.

**Abbildung 13:** Zertifikat downloaden
$\includegraphics{img-win/cdone}$

Die Erstellung des Zertifikats dauert bis zu 30 Sekunden. Danach erscheint eine Bestätigungsseite, auf der durch Klick auf ,,hier``²⁰das Zertifikat heruntergeladen werden kann.
Die soeben heruntergeladen Zertifikatsdatei wird dann im nächsten Schritt benötigt, um die Verbindung korrekt einzurichten.

Konfiguration des SSH Sentinel

Nach erfolgreicher Installation ist der SSH Sentinel als viereckiges Icon in der rechten unteren Ecke im sogenannten ,,System Tray`` zu finden.

**Abbildung:** System Tray und Kontextmenü
$\includegraphics{img-win/m0}$ $\includegraphics{img-win/n0}$

Durch Klicken mit der rechten Maustaste öffnet sich das Kontext-Menü, aus dem ,,Run Policy Editor`` ausgewählt wird.

In dem nun erscheinenden Fenster muss der Reiter ,,Key Management`` und darunter der Punkt ,,Certification Authorities`` ausgewählt werden.

**Abbildung 15:** Policy Editor, Reiter Key Management
$\includegraphics{img-win/n1}$

Nach einem Klick auf die ,,Add...``-Schaltfläche öffnet sich eine Dialogbox, in der das im vorherigen Kapitel erhaltene Zertifikat ausgewählt werden muss.

**Abbildung 16:** Auswahl der Zertifikatsdatei
$\includegraphics{img-win/n2}$

Das Zertifikat hat üblicherweise den Usernamen als Dateinamen.

Daraufhin wird nach einem Passwort für die Zertifikatsdatei gefragt:

**Abbildung 17:** Passworteingabe
$\includegraphics{img-win/n3}$

Hier ist als Passwort der Benutzername einzugeben.
Daraufhin erscheinen zwei Rückfragen, ob dieses Zertifikat wirklich verwendet werden soll.

**Abbildung:** Bestätigungsdialoge
$\includegraphics{img-win/n4}$ $\includegraphics{img-win/n5}$

Beide sind mit Yes zu beantworten.

Nun muss noch die IPSec-Verbindung eingerichtet werden. Dazu muss im Policy-Editor die Lasche ,,Security Policy`` und darin der Punkt ,,VPN Connection`` ausgewählt werden.

**Abbildung 19:** Policy Editor, Lasche Security Policy
$\includegraphics{img-win/n6}$

Hier ist wiederum auf ,,Add...`` zu klicken, worauf ein neues Fenster erscheint, in dem ein paar Einstellungen vorzunehmen sind.

**Abbildung 20:** Einrichtung des VPNs
$\includegraphics{img-win/n7}$

Zum einen muss in das Feld ,,Gateway name`` gateway eingetragen werden, als ,,Authentication key`` das eben erhaltene Zertifikat ausgewählt werden und der Haken bei ,,Use legacy proposal`` gesetzt werden.

Nach dem Schließen der verbleibenden Fenster mit ,,OK`` ist die Konfiguration des SSH Sentinel beendet.

Nun sollte noch die heruntergeladene Zeritifkatsdatei geloescht werden, da diese nicht mehr benoetigt wird.

Es bleibt anzumerken, das der SSH Sentinel die Berechtigung zum Verbindungsaufbau in unverschluesselter Form speichert. Deshalb sollten sie niemand unberechtigtes an die Dateien auf ihrem Computer lassen.

Verbindungsaufbau

Um nun die Verbindung zu aktivieren, muss nur noch im Kontext-Menü des ,,SSH Sentinel`` unter ,,Select VPN`` die soeben eingerichtete Verbindung angewählt werden.

**Abbildung 21:** Aktivieren des VPNs
$\includegraphics{img-win/n8}$

Nach einem kurzen Moment, in dem der Verbindungsaufbau geschieht, sollte nun ein voller Internetzugang möglich sein.

**Abbildung 22:** Verbindungsaufbau
$\includegraphics{img-win/n9}$

Dies kann am besten mit einem Webbrowser getestet werden.

Glossar

BSD:: Berkeley Software Distribution
BSD ist die weiterentwicklung von UNIXv6 an der Universität von Berkeley. BSD4.2 stellte 1983 mit der Aufnahme von TCP/IP die Weichen für den Siegeszug des Internets. Heute steht BSD für eine ganze Reihe von Unix-Systemen, die aus der letzen Version dieses ,,Ur-BSDs``, nämlich 4.4BSD, hervorgegangen sind.
CGI:: Common Gateway Interface
Eine De-Facto-Standard, der die Interaktion zwischen einem Webserver und den auf dem Webserver gestarteten Programmen zur Realisierung dynamischen Contents festlegt.
DHCP:: Dynamic Host Configuration Protocol
Von der IETF gestartete Weiterentwicklung von BOOTP (Bootstrap Protocol), das zur automatischen Konfiguration von IP-Adresse, Nameserver und weiteren Daten auf Clients in einem LAN eingesetzt wird.
HTTP:: HyperText Transport Protocol
Einfaches, textbasiertes Protokoll das benutzt wird um Webseiten anzufordern und zu übertragen. Die aktuelle Version, HTTP/1.1, ist in RFC 2616 standardisiert, und wird von allen gängigen Webbrowsern unterstützt.
IEEE:: Institute of Electrical and Electronics Engineers, Inc.
Das IEEE ist eine 1963 gegründete nichtkommerzielle Organisation, die über 700 Standards, überwiegend in den Bereichen Bus-Topologien, Übertragungsprotokollen, Datenübertragung und Verkabelung verwaltet.
IKE:: Internet Key Exchange
IKE ist ein aus Teilen der ISAKMP und Oakley-Standards entwickeltes Schlüsselaustausch-Protokoll für IPSec, das über UDP Port 500 abgewickelt wird. Obwohl IPSec nicht vorschreibt, welches Schlüsselaustauschprotokoll zu verwenden ist, hat sich IKE fast überall durchgesetzt.
IP:: Internet Protocol
Das dem Internet zugrundeliegnde Protokoll, welches im OSI-Modell auf der Netzwerk-Schicht einzuordnen ist. Auf IP aufbauend gibt es mit TCP und UDP je ein Verbindungsorientiertes und ein Verbindungsloses Protokoll.
IPX:: Internetwork Packet Exchange.
IPX ist ein von Novell entwickeltes Protokoll, das im OSI-Modell auf der Netzwerk-Schicht angesiedelt ist. Es ist verbindungslos, paketorientiert und in etwa vergleichbar mit IP.
Linux:: Linux ist ein 1991 von Linux Torvalds begonnenes, frei verfügbares Multitasking und Multiuser Betriebssystem, das inzwischen von vielen freien Entwicklern weltweit in Zusammenarbeit entwickelt wird.
MAC:: Media Access Control
Die MAC-Adresse einer Netzwerkkarte ist fest auf der Karte gespeichert und weltweit eindeutig. Es handelt sich sozusagen um die unverwechselbare Seriennummer einer Netzwerkarte. Die Adressen werden aus 48 Bit gebildet, wovon die ersten 24 Bit den Hersteller identifizieren.
MacOS X:: MacOS X ist Apples aktuelles Betriebssystem. Im Gegensatz zu Vorgängerversionen ist es auf einen Unix-artigen Kernel aufgebaut, der nahe an BSD angelehnt ist.
NetBEUI:: NetBIOS Enhanced User Interface.
NetBEUI ist eine von IBM entwickeltes Protokoll das auf NetBios aufbaut. Es ist zur schnellen Datenübertragung in kleinen Netzwerken gedacht, kann nicht geroutet werden, und daher nur im lokalen Netz einsetzbar. Es ist im OSI-Modell auf der Netzwerk- und Transportschicht anzusiedeln.
OSI:: Open System Interconnection
OSI ist ein offenes Schichtenmodell, das seit den 70er Jahren entwickelt wird und standardisiert (ISO 7498-1 / ITU-T X.200) wurde. Das OSI-Referenzmodell besteht aus sieben Schichten. Diese Schichten sind keine Protokolle, sondern geben Funktionen wieder. OSI selbst definiert die Dienste und Funktionen, die auf den einzelnen Schichten erfüllt werden sollen.
RFC:: Request for Comments
Die Sammlung der RFCs enthält neben allen gültigen Internet-Standards auch eine Reihe von rein informativen oder übeholten Dokumenten, die allerdings als solche gekennzeichnet sind.
SSL:: Secure Socket Layer
Ein von der Firma Netscape entwickeltes auf TCP aufsetzendes Protokoll auf Basis von X.509-Zertifikaten zur sicheren Datenübertragung in Client-Server-Anwendungen. Am bekanntesten ist sicherlich HTTPS, die SSL-geschütze Variante von HTTP, aber auch SMTP, IMAP oder NNTP werden immer öfter damit geschützt.
VPN:: Virtual Private Network
Ein VPN ist ein Netzwerk bestehend aus virtuellen Verbindungen (Tunnel über bestehende IP-Verbindungen z.B. das Internet), über die nicht-öffentliche bzw. firmeninterne Daten sicher übertragen werden.
WEP:: Wired Equivalent Privacy
Die in Funknetzen nach 802.11b verwendete Verschlüsselungsmethode, die dem Namen nach äquivalent zu einem Kabelgebundenem Netz sein soll. Leider wurde dies nicht erreicht, und modernere Funknetze müssen andere Verschlüsselungsmethoden einsetzen..

Quellen

Literatur

1

Stefan Zehl
Wired Equivalent Privacy, eine kurze Analyse der WaveLan-Verschlüsselung

http://www.42.org/~sec/Studium/wep/, 2001

2

Nikita Borisov, Ian Goldberg, David Wagner
(In)Security of the WEP algorithm,

http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html, 2000

3

S. Kent [BBN Corp],
R. Atkinson [@Home Network]
Security Architecture for the Internet Protocol,

RFC 2401 und folgende, 1998

4

K. Hamzeh [Ascend Communications], G. Pall [Microsoft Corporation], W. Verthein [3Com], J. Taarud [Copper Mountain Networks], W. Little [ECI Telematics], G. Zorn [Microsoft Corporation]
Point-to-Point Tunneling Protocol (PPTP),

RFC 2637, Juli 1999

5

W. Townsley [cisco Systems], A. Valencia [cisco Systems], A. Rubens [Ascend Communications], G. Pall [Microsoft Corporation], G. Zorn [Microsoft Corporation], B. Palter [Redback Networks]
Layer Two Tunneling Protocol ``L2TP``,

RFC 2661, August 1999

6

W. Simpson [Daydreamer]
The Point-to-Point Protocol (PPP),

RFC 1661, July 1994

7

C. Adams [Entrust Technologies], S. Farrell [SSE]
Internet X.509 Public Key Infrastructure - Certificate Management Protocols,

RFC 2510, March 1999

8

ANSI/IEEE Std 802.11 Working group
Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications,

http://standards.ieee.org/getieee802/802.11.html, 1999

9

Sven Lachmund
IPSec - Sicherheitsaspekte und Konfiguration unter Windows 2000 und Linux

Diplomarbeit an der FH München, FB 07 Informatik, Februar 2002

10

Marcus Müller
Windows 2000 / Windows XP - Freeswan VPN,

http://vpn.ebootis.de/, 2002

11

The RFC Database,

http://www.rfc-editor.org/rfc.html

12

Bruce Schneier [Counterpane Systems], Mudge [L0pht Heavy Industries]
Cryptanalysis of Microsoft's Point-to-Point Tunneling Protocol (PPTP),

Proceedings of the 5th ACM Conference on Communications and Computer Security, ACM Press, November 1998

http://www.counterpane.com/pptp.pdf

13

Bruce Schneier [Counterpane Systems], Mudge [L0pht Heavy Industries]
Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2),

http://www.counterpane.com/pptpv2-paper.html

14

Cheryl Madson, David McGrew, Andrew Nourse
Cisco Systems' Simple Certificate Enrollment Protocol,

http://www.ietf.org/internet-drafts/draft-nourse-scep-06.txt, Revision 6: 15. Mai 2002

Fußnoten

... 50 ¹: ESP - Encapsulated Security Payload (RFC2406)
... 51 ²: AH - Authentication Header (RFC2402)
... Linux ³: mit Free S/WAN-Patch
... MacOS X ⁴: ab 10.2 / Jaguar
... stellen ⁵: Es werden nur solche Betrachtet, die zumindest für den nichtkommerziellen Einsatz frei zu benutzen sind.
... Mailingliste ⁶: http://lists.freeswan.org/pipermail/users/2001-October/003792.html und http://lists.freeswan.org/pipermail/users/2001-September/003479.html
... Sentinel ⁷: http://www.ssh.com/products/sentinel/overview.cfm
... ausführlich ⁸: http://www.ssh.com/products/sentinel/SSH-Sentinel-1.3-FreeSWAN.pdf
... Cerberus ⁹: http://snad.ncsl.nist.gov/cerberus/
... ``mmc``¹⁰: Management Console
... könnten ¹¹: Nicht zu verwechseln mit einer ,,Single-Sign-On``-Lösung bei der der Benutzer sein Passwort an dieser Stelle überhaupt nicht mehr eingeben müsste.
... Patch ¹²: x509patch-0.9.15-freeswan-1.98b.tar.gz, u.a. erhältlich von http://www.strongsec.com/freeswan/
... Server ¹³: Beim Einsatz mehrerer Server natürlich auf jedem Server
... erteilt ¹⁴: Das ausgestellte Zertifikat hat eine passend begrenze Gültigkeitsdauer.
... 'cryptlib'¹⁵: http://www.cryptlib.orion.co.nz/
... OpenSCEP ¹⁶: http://openscep.othello.ch/
... Patch ¹⁷: http://open-source.arkoon.net/freeswan/notify_delete-freeswan-1.98b-020724.diff.gz
... Kernels ¹⁸: Es empfiehlt sich immer, den Kernelquellcode direkt von kernel.org zu holen, da die verschiedenen Distirbutionen dazu neigen, modifizierten Quellcode zu verteilen.
... sein ¹⁹: Selbst wenn der Rechner bisher eine fixe IP innerhalb der FH hatte, so kann diese aus Routingtechnischen Gründen nicht weiter verwendet werden.
... ,,hier``²⁰: Das Zertifikat bleibt ca. 10 Minuten unter diesem Link verfügbar.

Stefan `Sec` Zehl 2003-01-21