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 2003”
http://www.microsoft.com/windowsserver2003/technologies/pki/default.mspx
"Virtual Private Networking with Windows Server
2003: Deploying Remote Access VPNs"
http://www.microsoft.com/downloads/details.aspx?familyid=a93e566c-92c7-4849-80e6-2337f1d09697&displaylang=en
"Virtual Private Networking with Windows Server 2003: Deploying Site-to-Site
VPNs"
http://www.microsoft.com/downloads/details.aspx?familyid=8540f553-1711-402f-b451-2f8ea7fac379&displaylang=en
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"
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
- 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 1723 + evt. Protokoll 47 (GRE)
bei L2TP ist es UDP 1701 + 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.
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
Die aktuelle Netzwerkkonfiguration sieht wie folgt aus:
- Der Windows 2003 Server verfügt nur über eine einzige Netzwerkkarte (192.168.100.1)
- Der Internet Zugang wird über einen DSL Router (192.168.100.254) geregelt.
- Der Windows 2003 Server ist der DHCP, DNS und WINS Server für das Netzwerk.
- Der Adressbereich des DHCP Server erstreckt sich von 192.168.100.100 bis 192.168.100.150, der Adress Raum 192.168.100.140 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 192.168.100.254
o 006 DNS 192.168.100.1
o 044 WINS 192.168.100.1
o 045 NetBIOS over TCP/IP 192.168.100.1
o 046 WINS/NBT Knotentyp 0x8
a.)
Aufruf der MMC
Routing und RAS
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.
b.)
Wir wählen die Benutzerdefinierte Konfiguration, da der Punkt „RAS
(DFÜ oder VPN)“ an der Stelle aus Ermangelung einer 2ten Netzwerkkarte stoppen
würde
c.)
Selbsterklärend
d.)
Konfiguration
fertig stellen und den Dienst starten.
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.
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: 192.168.100.140 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.
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.
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.
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.
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 2003”
http://www.microsoft.com/windowsserver2003/technologies/pki/default.mspx
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 2003”
http://www.microsoft.com/windowsserver2003/technologies/pki/default.mspx schon erwähnt? Wenn nicht, dann jetzt, wenn doch dann schadet es nicht.
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änen-anmeldung 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
Als EAP Methode stehen Geschütztes EAP (PEAP) und MD5 Challenge zur Verfügung,
die aber nicht explizit ausgewählt werden müssen.
b.)
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)“
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.
Der
Zertifikatsserver ist per Webseite erreichbar. http://DerRechnerFQDNderRechners/certsrv
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”
http://support.microsoft.com/?kbid=811418
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 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)“
b.)
Einstellungen:
c.)
Eigenschaften: „Zertifikat auf diesem Computer verwenden“ und „Einfache Zertifikatsauswahl verwenden auswählen“,
bzw. „Eigene Smartcard verwenden“, wenn
vorhanden.
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.
- 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 "L2TP-IPSec-VPN"
Über die Eigenschaften der Verbindung => Reiter "Netzwerk wird der VPN-Typ
bestimmt.
 |
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 12. ...
2. 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 |
| - | Das Notebook wieder aus der Domäne entfernen. Das Zertifikat bleibt erhalten |
