Konfiguration und Einrichtung einer VPN Verbindung, gesichert mit Zertifikaten

Transkript

1 Konfiguration und Einrichtung einer VPN Verbindung, gesichert mit Zertifikaten Dieses Dokument stellt in seiner Form wirklich nur ein reines HowTo dar. Das Thema Sicherheit und die damit verbundenen Risiken, bei einer Öffnung des Systems für den Zugriff von außen ist ein ganz anderes und wird hier nicht bis ins kleinste behandelt. Die Funktion von Zertifikaten und der Aufbau einer strategisch geplanten PKI Infrastruktur muss jeder für sein Unternehmen über andere Mittel oder Dienstleister (dafür sind sie da) planen. Hilfen zum Thema findet man in der Literatur, auf Schulungen oder auch im Web: Public Key Infrastructure for Windows Server "Virtual Private Networking with Windows Server 2003: Deploying Remote Access VPNs" "Virtual Private Networking with Windows Server 2003: Deploying Site-to-Site VPNs" Das Thema ist bücherfüllend und aus diesem Grund kann ich hier nur einen kleinen Abschnitt bereitstellen, wie man bei diesem großen Thema mit Richtlinien unterstützend arbeiten kann. Mein hier vorgestelltes Szenario spiegelt die Situation in den meisten kleinen bis mittelständischen Unternehmen dar, die über einen zentralen Zugang ins Internet mittels eines DSL Hardware Router realisieren und eine dynamische IP bei der Einwahl zugewiesen bekommen. Trotz dieser ungünstigen Konstellation besteht oftmals Bedarf auf Daten/Applikationen oder für die Remoteverwaltung und Fernwartung auf das Firmennetz von unterwegs oder zuhause zugreifen zu können. Da dieses über das Internet mittlerweile am kostengünstigsten realisiert werden kann muss hierfür ein großes Stück Sicherheit Sorge getragen werden. 1. Konfiguration des Routers/Firewall 2. Einrichtung der zugelassenen Benutzer über eine Sicherheitsgruppe 3. Einrichtung Routing und RAS über Benutzername und Passwort 4. Ein paar Worte zum Thema Zertifikate 5. Einrichtung einer Zertifizierungsstelle 6. Umstellung des VPN Servers auf Zertifikatgestützte Einwahl 7. Bereitstellen und Installation des Zertifikats am Client PC 8. Konfiguration der DFÜ/VPN Verbindung am Client 9. Umstellung des verwendeten Tunnels von PPTP auf L2TP 10. Umstellung der DFÜ/VPN Verbindung am Client von "Automatisch" auf "L2TP-IPsec-VPN" 11. Integration eines Computer-Zertifikats für Nicht-Domänen-Mitglieder für die Verwendung von L2TP/IPsec 12. Verwendung von L2TP/IPsec mit einer Standalone CA oder der Einsatz eines Preshared Keys 1. Konfiguration des Routers, bzw. der Firewall: Da es hier keine generelle Anleitung geben kann, bzw. die Konfiguration und Einrichtung anhand der eingesetzten Systeme stark variiert, möchte ich hier nur ein paar generelle Punkte ansprechen. - Die meisten DSL Hardware Router können mit einer VPN Einwahl selber nichts anfangen, da ihnen die Möglichkeit zur Authentifizierung eines Benutzers fehlt. Deswegen muss man hier zum Portforwarding zurückgreifen, sodass die Anforderung an einen Server/Rechner weitergeleitet wird, der dafür zuständig ist. Im folgenden Beispiel ein Windows 2003 Server

2 - Je nach Hersteller sind die verwendeten Namen für das Portforwarding sehr unterschiedlich, man findet Virtual Server (z.b..: bei SMC), SUA (bei Zyxel) oder andere Begriffe. Ein Blick ins Handbuch und die Suche nach VPN sollte hier bei den meisten Geräten Hilfe verschaffen - Das es unterschiedlich gesicherte Arten der VPN Einwahl gibt, sind die jeweils weiterzuleitenden Ports unterschiedlich und einige Geräte/Systeme verlangen nicht nur die Konfiguration des Ports, sondern auch zusätzlich die Protokoll Art. Unter normalen Umständen (LowCost/Standard DSL Router) reicht die Weiterleitung des Ports 1723 (tcp) auf die interne IP des Windows 2003 Servers. Bei PPTP ist es TCP evt. Protokoll 47 (GRE) bei L2TP ist es UDP UDP 500 (isakmp) 1723 und zusätzlich GRE ist z.b. beim weit verbreiteten Fli4L notwendig. Es gibt hierfür spezielle OPT Pakete für diese MiniLinux Distribution. Eine weitere Problematik ergibt sich aus der dynamisch zugewiesenen IP. Die wenigsten haben eine feste IP zur Verfügung über die der Ziel Rechner immer erreichbar ist. Wobei hier mittlerweile die Angebote diverser ISPs für eine Volumenbegrenzte DSL Leitung inkl. einer festen IP interessant werden wenn man nicht gerade mit dem Rosa Riesen festverbandelt ist (siehe Angebote aktuell von Freenet, QSC und anderen). Damit man den Rechner grundsätzlich unter einem bestimmten Namen erreichen kann muss man auf Anbieter zurückgreifen, die einem die Möglichkeit bieten, die dynamische IP in einen festen Namen umzusetzen. Da diese Angebote kostenlos sind, ist es nicht möglich sich für den Namen eine Wunschdomain oder die der eigenen Firma zuzuweisen. Das ist als kostenloser Service nicht möglich. Anbieter für diese Dienste sind zum Beispiel: Wobei ich persönlich erstgenannten bevorzuge, weil er einer der Ersten war und viele DSL Router Hersteller eine automatische Aktualisierung der IP Adresse bei eben diesem Anbieter schon in die eigene Firmware integriert haben. Wenn der Router diese Möglichkeit nicht bietet, dann bleiben einem noch diverse Freeware Programme, die das zeitintervallgesteuert übernehmen können. Diese kann man auf den Seiten des jeweiligen Anbieters finden. Bei Fli4L findet man wie erwartet ebenfalls ein passendes OPT Paket. 2. Erstellen von Benutzern mit Einwahlrechten Meine Empfehlung: Benutzer, die sich über VPN einwählen dürfen, stehen in einer eigenen Sicherheitsgruppe, sind nicht Mitglieder der Standard-User-Gruppe (Domänen-Benutzer, oder einer selbst definierten Alle -Sicherheitsgruppe). Dem VPNEinwahlUser ist es nur erlaubt sich einzuwählen, aber dem Benutzer-Account ist die Lokale Anmeldung, egal an welchem System in der Firma, untersagt. => Lokale Sicherheitsrichtlinie Lokale Anmeldung verweigern, bzw. Lokale Anmeldung und dort nur die Benutzergruppen eintragen, die es per Default dürfen. Deswegen der Weg über die eigene Sicherheitsgruppe und der Umstellung der Primären Gruppe für diesen Benutzer, um diesen Punkt leichter steuern zu können. Der VPNEinwahlUser wird nur für die Einwahl verwendet. Der Zugriff auf die Systemressourcen lässt sich über net use /user:anderebenutzer oder beim Terminal-Server leicht regeln.

3 Der Hintergrund ist der, dass ein Anderer, nicht Berechtigter (potentieller Angreifer), der den Benutzernamen und das Passwort dieses Benutzers kennt, sich dann zwar einwählen kann, aber der weitere Angriff, bzw. Zugriff wird ihm erschwert. Wenn man in diesem Moment mit sauberen NTFS und SHARE Berechtigungen gearbeitet hat ist der Zugriff über das Netzwerk, oder die Anmeldung an ein System schon mal einiges schwerer. Nicht 100% sicher, aber schwieriger. Wenn ein Einbrecher die Wahl hat zwischen Ihrer Terrassentür und der des Nachbarn, die mit einem einfachen Schloss versehen ist, dann wird er ihre ungesicherte Tür wählen. Die des Nachbarn lässt er nach dem Prinzip des geringsten Widerstandes erst mal außer Acht. Es sein denn man sieht durch die Tür schon was zu holen ist. Dann wird er doch den Gartenstuhl verwenden um die Tür elegant zu öffnen. Wie schon im ersten Abschnitt erwähnt, ich gebe hier kein Sicherheitskonzept bekannt, sondern spreche nur ein paar Dinge an. Ob und wie sie diese als Anregung nehmen ist kein Zwang und sicherlich nicht der Wahrheit letzter Schluss. a) Active Directory Benutzer und Computer, eigene OU VPNUser erstellen, neue Sicherheitsgruppe VPNUser erstellen, neuen Benutzer VPNUser1 erstellen und diesem als Primäre Sicherheitsgruppe die VPNUser geben und die Gruppe der Domänenbenutzer entfernen. b) Der VPNUser1 sollte über ein komplexes Kennwort mit mind. 8 Zeichen verfügen und im Benutzerkonto sollte die Eigenschaft Benutzer kann Kennwort nicht ändern aktiviert sein. c) Im Reiter Einwählen bleibt es bei der Option Zugriff über RAS Richtlinien steuern 3. Einrichtung Routing und RAS

4 Die aktuelle Netzwerkkonfiguration sieht wie folgt aus: - Der Windows 2003 Server verfügt nur über eine einzige Netzwerkkarte ( ) - Der Internet Zugang wird über einen DSL Router ( ) geregelt. - Der Windows 2003 Server ist der DHCP, DNS und WINS Server für das Netzwerk. - Der Adressbereich des DHCP Server erstreckt sich von bis , der Adress Raum bis.150 ist als von der Verteilung ausgeschlossener Bereich definiert, da wir diesen später für die RAS Clients nutzen werden. - Der DHCP Server ist mit folgenden Bereichsoptionen konfiguriert: o 003 Router o 006 DNS o 044 WINS o 045 NetBIOS over TCP/IP o 046 WINS/NBT Knotentyp 0x8 a.) Aufruf der MMC Routing und RAS b.) Aktuell dürfte der Rechner noch mit einem roten Pfeil versehen sein, da dieser Dienst noch nicht konfiguriert ist. Über das Kontextmenü auf dem Servereintrag kann die Konfiguration des Routing und RAS Dienstes gestartet werden. Es öffnet sich ein Wizard (Assistent) dem wir folgen. Wir wählen die Benutzerdefinierte Konfiguration, da der Punkt RAS (DFÜ oder VPN) an der Stelle aus Ermangelung einer 2ten Netzwerkkarte stoppen würde

5 c.) Selbsterklärend d.) Konfiguration fertig stellen und den Dienst starten.

6 e.) Die MMC sollte jetzt so aussehen: f.) Konfiguration der Eigenschaften des Servers. 1. Reiter Allgemein, der Server ist nur RAS Server, da er über keine 2te NIC verfügt.

7 2. Reiter Sicherheit bleibt erst einmal so wie sie aktuell eingestellt ist auf Windows- Authentifizierung und Windows-Kontoführung stehen. Diese Einstellung würde sich ändern, wenn man zur Authentifizierung einen RADIUS Server einsetzen würde. 3. Reiter IP, hier ist IP Routing aktivieren wichtig, wenn der Remote Client nicht nur Zugriff auf den Einwahl Server haben soll, sondern auch auf weitere Geräte im lokalen Netzwerk. Wir weisen einen Statischen IP Adress Pool zu: bis.150, den wir im DHCP ausgegrenzt haben, um ihn für den RAS Server zur Verfügungen zu haben. Mit dieser Einstellung wären 11 gleichzeitige Verbindungen von außen möglich. Hier muss jeder für sein Netzwerk entscheiden, ob das reicht, oder ob es gar zu viele sind. g.) Konfiguration der Ports. Hier kann man die Anzahl anpassen und auf die verfügbare Anzahl der IP Adressen abstimmen, was es unterm Strich wesentlich übersichtlicher gestaltet und auch ein Teil des Sicherheitskonzepts ist, damit nicht unnötig geöffnete Türen zum Eintritt einladen.

8 h.) Eintrag des DHCP Relay Agents. Über diesen Eintrag werden dem Remote Client die Einstellungen und Bereichsoptionen des dort eingetragenen DHCP Server übermittelt. Der DHCP Relay Agent vergibt selbständig eine IP aus seinem statischen Pool an den Client. Für die weiteren Optionen wird der zuständige DHCP Server kontaktiert.

9 i.) Erstellen einer RAS Richtlinie, bzw. löschen der vorhanden und Implementation einer eigenen Richtlinie die 24/7 (rund um die Uhr) eine Einwahl über VPN erlaubt, aber nur, wenn der Benutzer Mitglied der Sicherheitsgruppe VPNUser ist. Wir löschen die beiden Richtlinien (bei Windows 2000 nur eine ) und erstellen uns mit dem Wizard eine neue 1. Richtlinien Name Einwahl zu meinen Bedingungen (oder jeder andere beliebige Name) 2. diese gilt für VPN 3. Als erlaubte Gruppe tragen wir die VPNUser ein 4. wählen MS-Chap V2 für die Authentifizierung 5. als einzige zugelassene Verschlüsselungsstärke benutzen wir Stärkste Verschlüsselung (Ipsec dreifach DES oder MPPE 128Bit) Jetzt müssen noch 2 kleine Änderungen durchgeführt werden. Die Eigenschaften der Richtlinie aufrufen und über Profil bearbeiten konfigurieren Als erstes werden die Uhrzeiten festgelegt, zu denen man sich einwählen darf und danach der NAS Typ, der den Zugriff nur über VPN erlaubt. Der Zugriff von außen über eine Microsoft VPN/DFÜ Verbindung auf Basis von Benutzername und Kennwort über das Internet ist jetzt fertig eingerichtet. 4. Ein paar Worte zum Thema Zertifikate Betrachtet man Zertifikate aus ihrer praktischen Funktion, dann kommt man schnell zu dem Schluss, dass es sich dabei um nichts anderes als eine besondere Form des Vertrauens handelt.

10 Nehmen wir ein Beispiel aus der Praxis: Wenn ich mich in meine Stammkneipe stelle und behaupte Ich bin Mark Heitbrink, dann werden es alle Anwesenden glauben und nicht weiter nachfragen, denn schließlich treffen wir uns seit Jahren hier und niemand hat je etwas anderes behauptet, oder versucht sich als Mark Heitbrink auszugeben. Ganz anders sieht das jetzt aus, wenn ich verreise und mich vor dem Zollbeamten aufbaue und ihm sage Ich bin Mark nach spätestens 60 Sekunden des Unverständnisses, bin ich entweder direkt weggeschlossen oder werde solange auf den Kopf gestellt und geschüttelt, bis mein Ausweis heraus fällt und dieser beweist, dass ich derjenige bin, der ich behaupte zu sein. Genau betrachtet macht es aber überhaupt keinen Unterschied, ob ich behaupte ich selbst zu sein, oder ob der Aussteller des Ausweises, also der Staat, bestätigt, dass ich ich bin. - Wer hat denn überprüft, ob der Staat nicht gelogen hat? - Wer entscheidet, dass der Staat vertrauenswürdig ist? - Wer hat dem Staat damals, als die Papiere ausgestellt wurden die vorhandenen Daten beglaubigt und bestätigt? Diese Kette lässt sich endlos weiterführen. Letztlich läuft es auf Vertrauen hinaus. Die Frage ist nur, wem ich vertraue oder wer mir bestätigt, dass jemand vertrauenswürdig ist, vorausgesetzt, dass ich demjenigen vertraue, der mir sagt man kann ihm vertrauen die Schleife ist Endlos. Für uns hat dieser Hintergrund aber einen verdammt praktischen Nutzen. Der Windows 2000 und 2003 Server lässt sich als Zertifikatsserver konfigurieren, sodass er derjenige ist, der Zertifikate (Reisepässe, Personalausweise, Führerscheine) ausstellen kann und er auch jedem glaubt und vertraut der ihm ein Zertifikat vorlegt, dass er selber ausgestellt hat. Ist ja auch klar. Wenn ich behaupte Mark Heitbrink zu sein, dann bin ich ja auch die erste Person die das glaubt und mir vertraut. Wenn nicht, wäre es traurig. An dieser Stelle werden einige Stimmen im Hinterkopf der Schizophrenen laut... Jetzt geht es um die Frage, ob ich bereit (in einigen Konfigurationen gezwungen) bin eine öffentliche Zertifizierungsstellen zu benutzen wie z.b..: Verisign, Thawte etc. oder ob es mir reicht die Zertifikate selber auszustellen, da sie nur für den hausinternen Gebrauch (in der Stammkneipe) sind und nicht von anderen dritten (Auslandsaufenthalt, Reisepass) akzeptiert werden müssen. Ich möchte erreichen, dass sich die User bei mir per Zertifikat (Ausweis) ausweisen. Nennen wir es einen Mitgliedsausweis, denn sie sind Mitglieder meines Active Directories und mein hausinternes Zertifikat ist von seiner Aussagekraft weit weg von einem Reispass, aber für unsere Zwecke genügt es. Nur wer Mitglied ist und von mir vorher dazu gemacht wurde, bekommt überhaupt einen Ausweis ausgestellt. Jeder der einen Ausweis vorweisen kann ist aus meiner Sicht vertrauenswürdig. Wer keinen Ausweis oder Zertifikat hat, oder sogar versucht mir einen ganz andern unterzuschieben, der kann nicht vertrauenswürdig sein und ist keiner meiner Clubmitglieder. Natürlich könnte es jemand mit einem Zertifikat von einem befreundeten Club sein, diesem würde ich vertrauen. Denn dann weiß ich, dass derjenige schon von jemand anderem überprüft wurde und seine eindeutige Zugehörigkeit geklärt ist. Dafür gibt es den Punkt Vertrauenswürdige Stammzertifikate in der Verwaltung der Zertifizierungsstelle, später mehr dazu... Die Konsequenz ist: Ich stelle in meiner Domäne eigene Zertifikate bereit. Nur Benutzer meiner Domäne können diese Zertifikate überhaupt von meiner Zertifizierungststelle erhalten. Jeder der im Besitz eines Zertifikats ist, das von mir ausgestellt wurde, ist berechtigt auf Ressourcen meiner Domäne zuzugreifen und hat damit gesichert dokumentiert, wer er ist und das er auch derjenige ist, der er vorgibt zu sein. Über diesen Weg haben wir jetzt eine zusätzliche Kontrollinstanz und eine höhere Sicherheit erreicht, als mit einer reinen Authentifizierung basierend auf Benutzername + Passwort. Werden diese Daten von jemandem eingegeben, kann ich als Kontrollinstanz nicht dafür garantieren, wer er wirklich ist.

11 Gerade wenn man so einfache Benutzername wie VPNUser1 wie in unserem Beispiel verwendet hat und dann sogar noch mit Leeren Paaswörtern oder 1234 als Passwort arbeitet. Das ist nicht sicher! Ist die Einwahl zertifikatsbasierend, dann ist es mir sogar möglich mit dem richtigen Benutzernamen der Domäne zu arbeiten, also nicht mit extra EinwahlBenutzern, da der Benutzername alleine und das Passwort, selbst wenn es bekannt ist, nicht für eine Anmeldung über VPN ausreichen. Ohne Zertifikat kommt man nicht hinein. Dieses hat jetzt zur Folge, dass man auf das Zertifikat genauso sorgsam aufpassen muss, wie auf alle anderen Anmeldedaten auch. Wenn das Zertifikat fest im Rechner integriert ist und dieser entwendet wird (Notebooks auf Messen sind ein beliebtes Ziel), dann ist es genauso unsicher, wie ein einfacher Name und ein leeres Kennwort. Eine Verringerung dieser Gefahr lässt sich über Smartcards erreichen. Das Zertifikat wird dann nicht auf dem Rechner abgelegt, sondern liegt nur auf der Smartcard, die in Form einer Scheckkarte oder auch eines USB Sticks daherkommt. Das Zertifikat wird dann bei Zugriff oder wenn die Anwendung es erfordert von der Smartcard gelesen. Wird die Smartcard entfernt kann der Computer z.b. automatisch gesperrt werden oder der Rechner wird heruntergefahren (Einstellung über die Sicherheitsoptionen der Lokalenrichtlinie). Natürlich muss man jetzt auf diese Smartcard wiederum genauso aufpassen wie auf schon auf alle anderen Daten. Der Kreis ist wie immer endlos. Der Einsatz solcher Technologien ohne dem Benutzer die Vor- und Nachteile zu zeigen und ihm den richtigen Umgang mit dem Arbeitsgerät zu erklären, bzw. den Sinn solcher Technologien zu vermitteln führt direkt ins Chaos und verurteilt jeden Ansatz des Sicherheitskonzepts direkt zum Scheitern. Was passiert, wenn ein Zertifikat verloren geht? Notebook wird geklaut, oder der Stick oder oder oder? Jede Zertifizierungsstelle führt eine Liste aller jemals ausgestellten Zertifikate. Zusätzlich wird ein Liste der Gesperrten Zertifikate, die so genannte CRL Certificate Revocation List, geführt. Alle auf dieser Liste geführten Zertifikate sind nicht mehr zugelassen. Entweder lag ein Missbrauchs vor oder die Dauer der Gültigkeit des Zertifikats ist abgelaufen. Damit ist die Kontrollinstanz in der Lage echte gültige Zertifikate von alten geklauten zu unterscheiden. Man kennt es von Sicherheitsschlössern in einer Firma. Geht ein Schlüssel verloren müssen alle Schlüssel und Schlösser der Firma erneuert werden. Das kostet einen Haufen Geld und Zeit. Die Zertifikatsdienste sind da etwas gnädiger, denn hier lassen sich einzelne verlorene Schlüssel ausgrenzen. Ist eine Zertifizierungsstelle einmal eingerichtet, ist eine Umbenennung des Zertifizierungsservers und der Domäne nicht mehr möglich, ohne dass die Zertifikate ihre Gültigkeit verlieren! Ein ganz wichtiges Thema an dieser Stelle ist die Datensicherung! Man denke bitte an EFS, da die Dateiverschlüsselung mit dem gleichen Benutzerzertifikat ausgeführt wird, wie die Benutzeranmeldung. Deswegen hier noch mal der Link vom Anfang: Public Key Infrastructure for Windows Server Das waren ein paar Worte zum Thema Zertifikate, jetzt geht's auch los. 5. Einrichtung einer Zertifizierungsstelle. Hatte ich Public Key Infrastructure for Windows Server schon erwähnt? Wenn nicht, dann jetzt, wenn doch dann schadet es nicht.

12 Die Einrichtung und der Vorgang selber sind relativ langweilig und einfach. Systemsteuerung => Software => Windows Komponenten => Zertifikatsdienste Wenn es die erste Zertifizierungsstelle für die Domäne werden soll, die auch eine Domänenanmeldung erlaubt (Benutzer-Zertifikate), dann muss man hier eine Stammzertifizierungsstelle des Unternehmens (Enterprise Root CA) wählen. Es folgt die Frage nach dem Aussteller des Zertifikats und die Dauer der Gültigkeit des Stammzertifikats wird festgelegt. 6. Umstellung des VPN Servers auf Zertifikatgestützte Einwahl a.) Über die Eigenschaften des RAS Servers wird die Art der Authentifizierungsmethode geändert. MS-CHAP wird abgewählt und zum Einsatz kommt EAP Extensible Authentication Protocol b.) Als EAP Methode stehen Geschütztes EAP (PEAP) und MD5 Challenge zur Verfügung, die aber nicht explizit ausgewählt werden müssen. Die RAS-Richtlinie Einwahl zu meinen Bedingungen muss jetzt noch angepasst werden, sodass es nunmehr nur noch möglich ist sich in das System einzuwählen, wenn ein Zertifikat verwendet wird. Eigenschaften der Richtlinie wählen kann über die Schaltfläche Profil bearbeiten die Einstellung vorgenommen werden. Im Reiter Verschlüsselung bleibt alles beim alten Stärkste Verschlüsselung (MPPE 128 Bit)

13 Reiter Authentifizierung : - Microsoft verschlüsselte Authentifizierung, Version 2 (MS-CHAP v2) wird abgewählt - EAP Methoden => Hinzufügen => Smartcard oder anderes Zertifikat Ab diesem Moment, werden keine Einwahlen über Benutzername + Passwort mehr zugelassen. Der Remote-User muss ein gültiges Zertifikat vorlegen. 7. Bereitstellen und Installation des Zertifikats am Client PC Ich bleibe bei meinem Beispiel und verwende die Zertifikate als festintegrierte Zertifikate im Zertifikatsspeicher des Benutzerkontos. Meine Sicherheitsbedenken habe ich dazu weiter oben schon geäußert. Eine Smartcard wäre an dieser Stelle der sicherere Weg, da das Zertifikat nicht auf dem Computer hinterlegt wird, sondern eben nur bei Bedarf verwendet wird und es, ob nun als USB Stick, oder Checkkarte immer wieder aus dem PC entfernt werden kann. Da die wenigsten der Betriebe, für die ich hauptsächlich dieses HowTo schreibe über die entsprechende Hardware für Smartcards verfügen, ist das gewählte System leider mit dem Nachteil der Festintegration des Zertifikats verbunden. Wie kommt nun ein Benutzer an ein Zertifikat? Als erstes muss dem User eine Zertifikatsvorlage bereitgestellt werden, über die er dann ein für ihn gültiges Zertifikat erhalten kann. Zu finden sind diese in der Verwaltung der Zertifizierungsstelle. Dort befindet sich ein Punkt Zertifikatsvorlagen. Dort sollte eine Vorlage Benutzer vorhanden sein. Wenn diese noch nicht vorhanden ist, so kann sie über Zertifikatsvorlage => Neu => Auszustellende Zertifikatsvorlage hinzugefügt werden.

14 Der Zertifikatsserver ist per Webseite erreichbar. An dieser URL beißen sich einige schon die Zähne aus, denn: 1. Die Eingabe erfordert die FQDN des Zertifikatsservers, bzw. die Angabe wie sie im AD hinterlegt ist, und 2. Die URL ist CASE-SENSITIV! Gerade der letzte Punkt kann einen zur Verzweiflung bringen, denn wenn der Name nicht 100% mit dem im AD hinterlegten übereinstimmt, kommt es zu unerklärlichen Fehlern bei der Ausstellung des Zertifikats. Die Fehlermeldung sieht dann so aus: Selbst bei Eingabe der richtigen schreibweise des FQDNs kann einem der Internet Explorer einen Strich durch die Rechnung machen, da er die URL in Kleinbuchstaben umsetzt. Hilfe schafft hier nur ein manueller Eingriff in das AD und die Umstellung/Angabe des FQDNs des Zertifikatservers in Kleinbuchstaben. Zusätzlich muss noch eine Textdatei im %systemroot%\system32\certsrv der Servers angepasst werden. No Certificate Templates Could Be Found" Error Message When User Requests Certificate from CA Web Enrollment Pages

15 Relevante Zeile in certdat.inc: sserverconfig="big-al.cssoft.bayern\cs Softwareentwicklung" Diese beiden Einträge müssen zwingend übereinstimmen und als Name des Servers für die URL verwendet werden. Hat man nun die Zertifizierungsseite erreicht, kann der Benutzer über Ein Zertifikat anfordern => Eine Anforderung an diese Zertifizierungsstelle erstellen und einreichen => Vorlage Benutzer das Zertifikat anfordern. Wichtig ist, dass das Zertifikat exportierbar markiert ist. Danach kann dieses Zertifikat automatisch über die Webseite installiert werden und der Benutzer hat es automatisch an seinem Gerät in seinem Profil unter Eigene Zertifikate liegen. Da an einer Workstation die lokale Zertifikatverwaltung nicht per Default in der Verwaltung integriert sind, hilft hier eine MMC mit dem passenden SnapIn. Über dieses SnapIn lässt sich das Zertifikat auch verwalten und exportieren, um es z.b. auf einem Notebook oder Heimarbeitsplatz zu integrieren, da letzterer unter normalen Umständen nicht auf die interne Zertifikatsseite der Firma zugreifen kann, um es zu anzufordern und zu installieren. Deswegen musste das Zertifikat auch als exportierbar markiert sein. Nachteil ist jetzt natürlich, dass das Zertifikat auf jeden beliebigen PC integriert werden kann, wenn es

16 erst einmal exportiert und auf einem Datenträger abgelegt wurde. Also muss man auch hier wieder über die möglichen Sicherheitslücken nachgedacht werden. 8. Konfiguration der DFÜ/VPN Verbindung am Client Wie man eine neue VPN/DFÜ Verbindung erstellt sollte jedem geläufig sein, bzw. der Wizard ist selbsterklärend. Deswegen kommen hier nur die Eigenschaften der Verbindung zur Sprache, die nötig sind, um das Zertifikat für die Einwahl zu benutzen. Der Zielrechnername sollte über eine feste IP, dessen FQDN oder einen der verschiedenen Dynamic DNS Dienste geklärt worden sein. a.) Reiter Sicherheit : Umstellung auf Erweitert (benutzerdefinierte Einstellungen)

17 b.) Einstellungen: c.) Eigenschaften: Zertifikat auf diesem Computer verwenden und Einfache Zertifikatsauswahl verwenden auswählen, bzw. Eigene Smartcard verwenden, wenn vorhanden.

18 Die Einwahl funktioniert jetzt, kann über die lokale LAN-Verbindung getestet werden und die Verbindung läuft über PPTP + GRE mit Zerifikatsbasierter Authentifizierung. Mögliche Fehlerquellen sind aber weiterhin die Konfiguration des Router, der Firewall und deswegen sollte der interne Test durchgeführt werden, damit man bei einem Fehler diese leichter eingrenzen kann. 9. Umstellung des verwendeten Tunnels von PPTP auf L2TP Zur Vergößerung der Sicherheit im verwendeten Tunnels wird dieser von PPTP (Point-to-Point- Tunneling Protocol) auf einen L2TP (Layer-Two Tunneling Protocol) umgestellt. Mit L2TP ist es erst möglich innerhalb der Verbindung IPSec zu tunneln. Diese Möglichkeit ist im PPTP nicht gegeben. PPTP verschlüsselt die Pakete nach einem RC4 Verfahren mit 40, 56 oder 128 Bit (welches wir eingestellt hatten), aber hat keine Integritätsprüfung der Pakete implemetiert und kann nicht zusammen mit IPSec verwendet werden. L2TP alleine bietet keine Sicherheit, da es über keine Verschlüsselungsmechnismen verfügt. Deswegen sollte es mit IPSec kombiniert werden. Wesentlich mehr dazu unter: L2TP: ftp://ftp.isi.edu/in-notes/rfc2661.txt, und "Securing L2TP using IPsec" ftp://ftp.isi.edu/in-notes/rfc3193.txt IPSec alleine kann nicht durch ein NAT geschickt werden, da durch das NAT die Pakete verändert werden. Mit der Veränderung des Paketes wird dieses für ungültig erklärt. IPSec stützt sich auch 4 grundlegende Pfeiler, die für die Echheit der Sende und Empfangsquelle garantieren.

19 - Verschlüsselung - als Schutz gegen unbefugtes Mitlesen - Authentisierung der Nachricht - zum Beweis der Unverfälschtheit einer Nachricht (Paketintegrität) - Authentisierung des Absenders - zur unzweifelhaften Zuordnung eines Senders/ Empfängers (Paketauthentizität) - Verwaltung von Schlüsseln Der 2te Punkt verhindert den Einsatz von IPSec mit einem herkömmlichen NAT. Für den Einsatz von L2TP/IPSec ist ein Computerzertifikat zwingend erforderlich. Dieses Zertifikat wird für die Domänen-Computer automatisch ausgestellt, wenn es in der Default Domain Policy so definiert wurde. Jedes Computerkonto der Domäne ist damit automatisch in der Lage einen L2TP VPN Tunnel mit dem Server aufzubauen. Änderungen an unserer aktuellen Konfiguration: a.) Im Routing und RAS => Ports müssen natürlich die L2TP Schnittstellen zur Verfügung stehen. Wer diese in der ersten Konfiguration (siehe oben) komplett entfernt hat muss diese natürlich wieder hinzufügen b.) Änderung der vorhandenen RAS-Richtlinie: Wir fügen hier den Tunnel-Typ "Layer Two Tunneling Protocol (L2TP)" hinzu. Damit ist gewährleistet, daß eine Verbindung nur noch über L2TP und nicht mehr PPTP möglich ist. 10. Umstellung der vorhandenen DFÜ/VPN Verbindung am Client von "Automatisch" auf

20 "L2TP-IPSec-VPN" Über die Eigenschaften der Verbindung => Reiter "Netzwerk wird der VPN-Typ bestimmt. 11. Integration eines Computer-Zertifikats für Nicht-Domänen-Mitglieder für die Verwendung von L2TP/IPsec Leider haben ist es in unserer aktuellen Konfiguration keine leichte Aufgabe die Nicht-Domain- Mitglieder ebenfalls über L2TP/IPsec laufen zu lassen. Das zwingend benötigte Computerzertifikat ist an das Computerkonto im AD gekoppelt. Kein Domain-Mitgleid = Kein Computerkonto. Das Computerzertifikat kann im Gegensatz zu einem Benutzerzertifikat nicht exportiert werden. Das heisst exportiert werden kann es schon, aber nur ohne den privaten Schlüssel und damit ist es zwar an einem anderen Rechner zu importieren, aber ohne den privaten Key kommt keine Verbindung zustande. Es gibt jetzt nur 2 Möglichkeiten: 1. Der Einsatz einer Stand-Alone CA... fällt aus, da wir hier nur einen Server haben... Anleitung siehe Punkt Ein großer Umweg: Aufbau der Verbindung über PPTP, geht natürlich nur, wenn wir die RAS Richtlinie noch nicht - konfiguriert haben, bzw. wir müssen sie kurzfristig noch mal auf PPTP zuallen einstellen - Hinzufügen der Workstation zur Domäne und dann das Auto-Enrollment abwarten, daß das Computerzertifikat vergibt. Oder dieses über die MMC - SnapIn Zertifikate anfordern