Mitarbeitern den Zugriff von unterwegs oder zu Hause auf das Firmennetz anzubieten war bislang eine teuere Angelegenheit. Der Remote Access per Direkteinwahl setzt zum einen nicht unerhebliche Investitionskosten für Hardware voraus. Zum anderen laufen im Betrieb schnell stattliche Verbindungskosten auf, da die Connections zu Telefontarifen abgerechnet werden müssen. Schon bei einem mittelständischen Betrieb mit mehr als nur einer Handvoll mobiler oder in den heimischen vier Wänden agierenden Mitarbeiter kommen da schnell mehrere zehntausend Euro zusammen.
Als vielversprechende, weil deutlich kostengünstigere Alternative bietet sich der Ersatz der Dial-in-Connections durch eine Anbindung via Internet an. Das Netz der Netze ist nahezu überall zugänglich und lässt sich zu minimalen Kosten nutzen. Für der Anbindung von Home- oder Remote-Offices eignet sich eine DSL-Flatrate-Verbindung ideal als Standleitungsersatz zur Firma. Als Haar in der Suppe erweist sich bei dieser Idee jedoch die Sicherheit: Via Internet transportierte Daten kann jedermann mitlesen oder - noch schlimmer - unterwegs modifizieren.
Die Einrichtung eines virtuellen privaten Netzes (VPN) über das Internet bietet die Lösung des Problems. Die Authentizität und Integrität der transportierten Daten schützt dabei die Security Architecture for the Internet Protocol (RFC 2401) , besser bekannt unter dem Kürzel IPsec. Eine ebenso preiswerte wie performante Plattform für die Implementation gibt dabei das Duo Linux und Free S/WAN ab.
VPN mit Linux
Zwar eignet sich Linux sowohl als stabile und gut abzusichernde Betriebssystemplattform als auch wegen seiner umfassenden Firewalling-Fähigkeiten ideal als Grundlage für einen IPsec-basierten Security Gateway. Allerdings bringt es von Haus aus noch keine IPsec-Implementation mit.
Die bietet das Paket Linux Free S/WAN, ein Gemeinschaftsprojekt eines guten Dutzends ambitionierter Programmier und Kontributoren. Free S/WAN besteht aus zwei Hauptkomponenten: KLIPS (kernel IPsec) implementiert die notwendigen Protokolle und das zugehörige Handling im Kernel. Der Daemon Pluto kümmert sich um den Verbindungsaufbau und Schlüsselaustausch. Eine ganze Reihe von Scripts schließlich ergänzen den Free-S/WAN-Kern um ein Administrationsinterface.
Der vorliegende ersten Teil unseres Workshops beschreibt, wie IPsec funktioniert und sich mit Hilfe von Free S/WAN unter Linux aufsetzen und für den VPN-Einsatz konfigurieren lässt. Des weiteren zeigen wir, wie sich durch den zusätzlichen Einsatz von X.509-Zertifikaten eine für den Unternehmenseinsatz taugliche Infrastruktur zur Authentifizierung implementieren lässt. Ein zweiter Teil des Workshops schildert die Konfiguration und den Einsatz von Windows-Clients mit Free S/WAN.
IPsec im Überblick
Das gerne als Secure Internet Protokoll apostrophierte IPsec stellt eigentlich eine Suite aus Protokollen und Techniken dar, mit deren Hilfe sich sichere Verbindungen via Internet aufbauen lassen. Den allgemeinen Aufbau dieser offiziell als Internet Protocol Security bezeichneten Architektur beschreiben die RFCs 2401 bis 2410, Ergänzungen für spezielle Einsatzzwecke finden sich in den RFCs 2207, 2709, 3104 und 3193.
Zur Realisierung einer sicheren Verbindung stellt IPsec die Integrität und Vertraulichkeit der transportierten Daten durch Authentifikation sowie Verschlüsselung sicher und ermöglich parallel dazu eine Zugriffskontrolle auf Benutzerebene. Zu diesem Zweck implementiert es auf der Netzwerkebene zwei Transportmodi und zwei zugehörige Sicherheitsfunktionen.
Transport vs. Tunnel Mode
Im Transport Mode kommunizieren zwei Hosts direkt via Internet miteinander. In diesem Szenario lässt sich IPsec zum einen dazu nutzen, die Authentizität und Integrität der Daten zu gewährleisten. Man kann also nicht nur sicher sein, mit wem man da gerade kommuniziert, sondern sich auch darauf verlassen, dass die Pakete nicht unterwegs verändert wurden. Per optionaler Verschlüsselung kann man zudem verhindern, dass Unbefugte die transportierten Inhalte mitlesen. Da hier zwei Rechner direkt über ein frei zugängliches Netz miteinander Daten austauschen, lassen sich jedoch Ursprung und Ziel des Datenstroms nicht verschleiern.
Der Tunnel Mode kommt stets dann zum Einsatz, wenn zumindest einer der beteiligten Rechner nicht direkt angesprochen, sondern als Security Gateway genutzt wird. In diesem Fall bleibt zumindest einer der Kommunikationspartner - der hinter dem Gateway - anonym. Tauschen gar zwei Netze über ihre Security Gateways Daten aus, dann lässt sich von außen gar nicht mehr bestimmen, welche Rechner hier tatsächlich miteinander sprechen. Auch im Tunnel Mode lassen sich natürlich Authentifizierung, Integritätskontrolle und Verschlüsselung einsetzen.
Authentication Header (AH)
Der IP Authentication Header (AH, RFC 2402) sorgt dafür, dass sich Herkunftsangabe und Inhalt der transportierten Daten nicht unbemerkt durch Dritte verändern lassen. Dazu wird ein Hashwert über alle statischen IP-Headerdaten sowie die gesamten Nutzdaten errechnet und zusammen mit weiteren Kontrollfeldern hinter dem ursprünglichen IP-Header eingefügt. Durch die Überprüfung dieses Werts kann der Empfänger nachträgliche Manipulationen an Kopf- oder Nutzdaten sofort erkennen. Variable IP-Headerdaten, die sich im Verlauf der Übertragung verändern können, bleiben von diesem Schutz notgedrungen ausgeklammert.
Der Authentication Header kommt sowohl im Transport wie auch im Tunnel-Mode zum Einsatz. In der Transportvariante residiert er zwischen dem ursprünglichen IP-Header des Paketes und den Nutzdaten. Beim Tunneling dagegen verpackt der Gateway das komplette Datenpaket samt Headerdaten in ein neues IP-Packet. Hier findet sich der AH zwischen den neuen Kopfdaten und dem ursprünglichen Paket. In beiden Modi stellt er jedoch nur Authentizität und Integrität der Daten sicher, nicht aber deren Vertraulichkeit: Er implementiert keinerlei Verschlüsselung.
Encapsulated Security Payload (ESP)
Für die Vertraulichkeit der Daten sorgt durch Verschlüsselung die IP Encapsulated Security Payload (ESP, RFC 2406). Mittels eines Headers und eines Trailers umschließt das Protokoll die verschlüsselten Nutzdaten. Ein optionales ESP-Auth-Feld am Paketende kann ähnlich wie der Authentication Header Informationen zur Integrität der verschlüsselten Daten aufnehmen.
Im Transportmodus schließen ESP Header und Trailer lediglich die reinen IP-Nutzdaten ein, der Paketheader bleibt völlig ungeschützt. Im Tunneling Mode allerdings umfassen die "Nutzdaten" das gesamte Ursprungspaket des Absenders, das der Security Gateway in ein neues Datenpaket eingebunden hat. Damit lassen sich nur noch die Transportdaten des Gateways einsehen. Das gesamte ursprüngliche IP-Paket samt Sender- und Empfängerdaten dagegen liegt verschlüsselt vor. In diesem Fall gewährleistet ESP also nicht nur die Vertraulichkeit der Daten, sondern auch die der Verbindung.
In beiden Fällen profitiert ESP von der Kombination mit einem AH, der zusätzlich die Integrität und Authentizität der wichtigsten IP-Headerdaten absichert. Erst das Duo ESP/AH bietet einen perfekten Schutz gegen Datenmanipulation und Ausspähung.
Security Association (SA)
Um für eine Verbindung ESP/AH einsetzen zu können, müssen sich allerdings die Kommunikationspartner erst einmal über die Mechanismen und Algorithmen für das Hashing sowie die Authentifizierung und Verschlüsselung einig sein. Des weiteren müssen beiden Seiten die notwendigen Schlüssel sowie deren Gültigkeitsdauer kennen.
Alle diese Parameter handeln die beiden Endpunkte einer IPsec-Connection bei jedem Verbindungsaufbau aus. Es kommt quasi ein Vertrag - die sogenannte Security Association (SA, RFC 2408 und 2409) - zwischen den Kommunikationspartnern zustande. Um die Sicherheit der Verbindung zu erhöhen, können über die SA die Schlüssel auch bei laufender Verbindung neu vereinbart werden. Dies erfolgt wahlweise in bestimmten Zeitabständen oder nach bestimmten Übertragungsmengen.
Zudem sorgt die Security Association durch die Möglichkeit zur individuellen Parametrisierung jeder Verbindung auch für die Zugriffskontrolle auf Benutzerebene. So lassen sich über die SA jedem Verbindungspartner eigene Schlüssel- und Authentifizierungsverfahren und Kennungen zuordnen.
Internet Key Exchange (IKE)
Das Internet Key Exchange Protocol (IKE, RFC 2409) definiert den Ablauf beim Aushandeln einer IPsec SA inklusive der dazu notwendigen Mechanismen. Das Verfahren wird auch als Internet Security Association and Key Management Protocol (ISAKMP) bezeichnet. Es löst das Problem des vertraulichen Verbindungsaufbaus zwischen zwei Gegenstellen, die keinerlei Informationen und ergo auch keine Schlüssel vom jeweiligen Kommunikationspartner haben.
In IKE Phase 1 ("Main Mode") vereinbaren die Verbindungspartner zunächst im Wechselspiel eine mögliche SA-Konfiguration samt der Algorithmen für Hashing, Authentifizierung und Verschlüsselung. Der Initiator der Verbindung unterbreitet der Gegenstelle (dem "Responder") einen entsprechenden Vorschlag, der mehrere Varianten umfassen kann. Der Responder sucht sich etwas Passendes heraus und quittiert den Vorschlag entsprechend. Anschließend handeln die beiden Gegenstellen im Wechselspiel über den Diffie-Hellman-Algorithmus einen Secret Key aus, auf dessen Grundlage sich nun alle weiteren Daten verschlüsseln lassen.
Dies gilt insbesondere für den jetzt fälligen Austausch der Identifikationsparameter (ID), die der Absender jeweils mit seinem Public Key signiert. Optional kann auch ein Zertifikat mit übertragen werden. Ist dies der Fall, ermittelt der Empfänger daraus den Public Key des Absenders und kann damit die Signatur und somit die Identität des Senders eindeutig ermitteln. Fehlt das Zertifikat, benötigt der Empfänger eine lokale Liste von IDs und zugehörigen Schlüsseln, aus denen er den fraglichen Public Key ersieht.
Damit sind nun die Authentizität der Gegenstellen und die Vertraulichkeit der Verbindung gewährleistet. Damit kann IKE Phase 2 starten, der sogenannte Quick Mode. Er baut die eigentliche IPsec SA durch die Vereinbarung der Parameter und Mechanismen für ESP und AH auf. Während einer IPsec-Session lässt sich der Quick Mode beliebig oft neu anstoßen, um neue Schlüssel für beide Seiten zu generieren.
X.509-Zertifikate
Wie bereits erwähnt, lässt sich der Austausch der Public Keys am Besten über X.509-Zertifikate (RFC 2459) bewerkstelligen. Ein solches Zertifikat ordnet einen Public Key eindeutig seinem Inhaber zu. Für die Glaubwürdigkeit des Zertifikats steht dessen Aussteller gerade, die Certification Authority (CA).
Das Zertifikat beinhaltet Daten über den verwendeten Signaturalgorithmus, den Aussteller, den Inhaber und die Gültigkeitsdauer. Als wichtigste Information enthält es den Public Key des Inhabers. Die CA unterzeichnet das Zertifikat, indem sie einen Hash über die gesamten Daten bildet und diesen mit ihrem eigenen Public Key signiert. Um die Gültigkeit eines vorliegenden Zertifikats zu prüfen, muss der Empfänger also lediglich die Signatur mit dem Public Key der CA entschlüsseln und anschließend mit dem Hashwert vergleichen.
Den Knackpunkt an diesem Verfahren bildet offensichtlich die Glaubwürdigkeit der CA. Die lässt sich erhöhen, indem sie ihr Zertifikat von einer weiteren Certification Authority signieren lässt - und so weiter. Damit kann eine "Kette des Vertrauens" aufgebaut werden, an deren Spitze die sogenannte Root CA steht. Sie unterschreibt ihr Zertifikat selbst. Die Zertifikatskette ist also letztlich nur so glaubwürdig wie ihre Root CA.
Beim Einsatz von Zertifikaten für VPN-Verbindungen stellt das allerdings kein größeres Problem dar: Der Administrator des zu kontaktierenden Netzes ernennt sich einfach selbst zur Root CA und zertifiziert sowohl den Security Gateway als auch die in Frage kommenden Verbindungspartner.
IPsec mit Free S/WAN
Wie eingangs bereits beschrieben, liegt mit Free S/WAN eine komplette IPsec-Implementation für Linux mehr oder weniger gebrauchsfertig vor. Zwar bringen die meisten Distributionen das Paket bereits mit. Erfahrungsgemäß empfiehlt es sich aber, bei der Einrichtung sowohl mit der neuesten Kernel- als auch der aktuellsten Free-S/WAN-Variante zu arbeiten.
Für unser Beispiel haben wir ein Red Hat Linux 7.2 mit aktualisiertem Kernel 2.4.18 sowie Free S/WAN 1.97 genutzt. Im Bedarfsfall lässt sich Free S/WAN jedoch auch mit Kerneln der 2.2er-Serie zusammen nutzen. Hier benötigen Sie jedoch wenigstens Linux 2.2.19. Zudem gilt es zu bedenken, dass für den praktischen Einsatz meist die Kombination VPN-Gateway/Firewall zum Zug kommt. Hier bietet Kernel 2.4 durch die integrierte netfilter-Architektur Vorteile.
Eine kleine Lücke lässt Free S/WAN in seinem Funktionsumfang allerdings bislang offen: Es unterstützt die Verwendung von X.509-Zertifikaten nicht. Dem lässt sich aber mit einem an der Schweizer Uni Winterthur entwickelten Patch leicht abhelfen.
Installation
Zur Installation entpacken Sie die Kernel-Sourcen an die übliche Stelle in /usr/scr/linux und den Free-S/WAN-Tarball nach /usr/src/freeswan-versionsnummer. Anschließend nehmen Sie mit make menuconfig respektive make xconfig die Konfiguration des Kernels vor. Neben den für Ihr System gewünschten Einstellungen konfigurieren Sie dabei unter Networking Options / IPsec Options (Free S/WAN) die Einstellungen für Free S/WAN. Hier sind als Voreinstellung alle vorhandenen Features ausgewählt. Dabei sollten Sie es auch belassen.
Um den X.509-Patch einzuspielen, entpacken Sie den entsprechenden Tarball und kopieren die Datei freeswan.diff in das Quellverzeichnis von Free S/WAN. Das Kommando patch -p1 < freeswan.diff nimmt anschließend die notwendigen Modifikationen vor.
Zu guter Letzt kompilieren Sie den modifizierten Kernel, was sich am komfortabelsten durch die Eingabe von make kinstall im Free-S/WAN-Quellverzeichnis anstoßen lässt. Nach dem Eintrag des neuen Kernels beim Bootmanager und dem Neustart des Rechners können Sie die Wirksamkeit Ihrer Modifikationen in Augenschein nehmen: Ein dmesg an der Kommandozeile sollte Initialisierungsmeldungen von KLIPS und Pluto zu Tage fördern. Zudem lassen sich bei funktionierendem Free S/WAN mit ipsec --version die Versionsnummer und mit ipsec whack --status ein Statusreport von Pluto abfragen.
Eventuell ist anschließend noch etwas Nacharbeit an den Runleveln notwendig. Da Free S/WAN den bestehenden Ethernet-Interfaces eth0 und eth1 noch ein ipsec0 hinzufügt, sollte das System zuerst das Networking, anschließend Free S/WAN und schließlich iptables starten. Unser Red Hat 7.2 initialisierte dagegen die Firewall vor Free S/WAN und ließ sich erst durch entsprechende Modifikationen in /etc/rc.d eines Besseren belehren.
Konfiguration
Unser Security Gateway soll gleichzeitig als Firewall agieren und externe Rechner mit beliebiger IP-Adresse bei Authentifizierung über ein X.509-Zertifikat an das interne Netz (172.16.0.0/16) anbinden. Er verfügt dazu über die zwei Interfaces eth0 (intern, 172.16.0.0/16) und eth1 (extern). Zwischen den beiden Interfaces muss das IP-Forwarding aktiviert sein.
Zunächst einmal gilt es die Firewall des Security Gateway dazu zu bewegen, die entsprechenden AH - und ESP-Pakete akzeptieren. Wir lassen also auf dem externen Interface - in unserem Fall eth1 - UDP-Pakete zu Port 500 (ESP) sowie den IP-Protokolltyp 50 (AH) passieren.
Die Konfiguration von Free S/WAN selbst erfolgt über die Datei /etc/ipsec.conf. Hier benötigen wir drei Gruppen von Parametern: config setup umfaßt die grundlegenden Settings, conn %default enthält die Basiseinstellungen für alle Verbindungen. Ein dritter Abschnitt, der ebenfalls mit dem Schlüsselwort conn sowie einem beliebigen Namen gekennzeichnet ist, regelt die Parameter für eine gleichnamige Verbindung. In unserem Beispiel nennen wir ihn nach der gängigen neuhochdeutschen Bezeichnung für mobile externe Mitarbeiter conn Roadwarrior.
/etc/ipsec.conf
Unter config setup ist zunächst einmal das Interface anzugeben, über das die IPsec-Verbindungsanfragen eingehen. Hier genügt in der Regel ein interfaces=%defaultroute, alternativ ist die IP-Adresse der Schnittstelle anzugeben. Das Debugging schalten wir durch Angabe von none für klipsdebug und plutodebug aus. plutoload und plutostart setzen wir auf %search, so dass Verbindungen erst auf Anfrage einer Gegenstelle hergestellt werden. uniqueids setzen wir auf no, so dass uns eine Connection-Beschreibung für alle Roadwarriors genügt. Anderenfalls müssten wir für jeden mobilen Mitarbeiter eine eigene Verbindungsbeschreibung erstellen.
Bei conn %default weisen wir mit keyingtries=0 den Gateway an, bei der Neuverhandlung von Schlüsseln möglichst viel Geduld walten zu lassen. Als Authentifizierungsmethode nutzen wir authby=rsasig, wobei sich beide Verbindungsseiten über ein Zertifikat ausweisen sollen: leftrsasigkey=%cert und rightrsasigkey=%cert. Als left geben wir wiederum %defaultroute an, als leftsubnet unser internes Netz (hier: 172.16.0.0/16). Später werden wir hier noch den Parameter leftid ergänzen, den Bezeichner unseres Zertifikats für den Gateway.
Für unsere Verbindung conn Roadwarrior lassen wir alle Kommunikationspartner zu, die sich mit einem Zertifikat ausweisen können: right=%any. Als Verbindungsmodus wählen wir type=tunnel, der Schlüsselaustausch soll via IKE (keyexchange=ike) mit Perfect Forwarding Secrecy (pfs=yes) erfolgen. Über auto=add weisen wir Free S/WAN an, die Verbindung erst auf Anfrage des Roadwarriors auszuhandeln.
Zertifikate
Jetzt ist Free S/WAN für eine Verbindung mit starker Verschlüsselung per Zertifikatsaustausch konfiguriert. Die notwendigen Zertifikate für Gateway und die Roadwarriors stellen wir uns selber aus. Dazu nutzen wir die Fähigkeiten von OpenSSL.
Zunächst generieren wir uns eine Verzeichnisstruktur zur Generierung der Zertifikate. In unserem Beispiel residiert sie unter /etc/fenrisCA - in Anlehnung an den Hostnamen unseres Gateways. Hier erstellen wir die Verzeichnisse certs und newcerts (für die Ablage von Zertifikaten), crl (für unsere Certification Revocation List) und private (für private Keys). Das Directory private darf logischerweise ebenso wie die enthaltenen Keys ausschließlich für root zugänglich sein.
In /etc/fenrisCA benötigen wir noch die beiden Dateien index.txt und serial. Mit touch legen wir index.txt als leere Datei an. Hierin führt OpenSSL später eine Liste der ausgestellten Zertifikate. Welche Seriennummer es dem nächsten Zertifikat zuweisen soll, entnimmt openssl dem File serial. Wir belegen es mit dem Wert 00 vor.
Nun tragen wir noch in in der Konfigurationsdatei openssl.cnf (je nach Distribution meist in /usr/ssl oder /usr/share/ssl) den Pfad zu unserem CA-Verzeichnis in den Parameter dir ein. Optional können wir dort auch die Bestandteile des Identifier-Strings, wie country, state und organizationName mit Default-Werten vorbelegen. Das spart später bei der Zertifikatsausstellung Tipparbeit.
Für die folgenden Arbeiten mit openssl muss das CA-Stammverzeichnis (bei uns /etc/fenrisCA) stets unser aktuelles Arbeitsverzeichnis sein.
Root CA
Nun schwingen wir uns zunächst einmal zur Root CA auf. Dazu generieren wir als erstes einen RSA Private Key mit 2048 Bit Schlüssellänge:
openssl genrsa -des3 -out private/caKey.pem 2048
Die Option des3 verschlüsselt unseren Key per TripleDES unter Angabe einer Passphrase, so dass nicht Unbefugte eine Zertifikat damit signieren können. Wir allerdings auch nicht, falls wir die Passphrase vergessen sollten.
Jetzt generieren wir unser Root-CA-Zertifikat und limitieren es durch Angabe einer Gültigkeitsdauer auf einen - nicht zu knapp bemessenen - Zeitraum:
openssl req -new -x509 -days=1825 -key private/caKey.pem -out caCert.pem
Als Passphrase ist hier diejenige unseres eben generierten Private Keys anzugeben. Anschließend fragt openssl die einzelnen Elemente des Subject-Eintrags ab, welcher der Identifikation des Zertifikatsinhabers dient. Die einzelnen Bestandteil sind praktisch selbsterklärend, bis auf den Common Name. Für diesen können Sie einen beliebigen Bezeichner vergeben, der aber tunlichst eine griffige Beschreibung des Subject liefern sollte. Das dazugehörige Email-Element beschreibt, wie der Zertifikatsinhaber erreichbar ist.
Dass alles geklappt hat, können wir überprüfen, in dem wir das Zertifikat im Klartext ausgeben lassen:
openssl x509 -in caCert.pem -noout -text
Zu guter Letzt kopieren wir unser Root-CA-Zertifikat nach /etc/ipsec.d/cacerts/, wo es von Free S/WAN erwartet wird.
Gateway-Zertifikat
Ganz ähnlich wie die Generierung des Root-CA-Zertifikats läuft die Erstellung des Zertifikats für unser Gateway ab. Mit diesem beweisen wir später unseren Roadwarriors, dass sie auch mit dem richtigen Security Gateway kommunizieren.
Zunächst benötigen wir wieder einen Private Key, diesmal mit 1024 Bit Länge:
openssl genrsa -des3 -out private/gwKey.pem 1024
Dabei vergeben wir eine eigen Passphrase für den Gateway. Nun erstellen wir einen Zertifikatsantrag für die Root CA:
openssl req -new -key private/gwKey.pem -out gwReq.pem
Wir bestätigen dabei den Antrag mit unserer Gateway-Passphrase und ignorieren die Anfragen nach den extra attributes.
Nun unterschreiben wir den Request als Root CA:
openssl ca -notext -in gwReq.pem -out gwCert.pem
Dazu geben wir auf Anfrage die Root-CA-Passphrase an. Unser eben erstelltes Zertifikat müssen wir noch als /etc/x509cert.der in binärer Form für den Gateway ablegen. Dazu konvertieren wir das Zertifikat mit dem Befehl:
openssl x509 -in gwCwert.pem -outform der -out /etc/x509cert.der
Den Private Key gwKey.pem kopieren wir für Free S/WAN nach /etc/ipsec.d/private. Außerdem muss die zugehörige Passphrase in der Datei /etc/ipsec.secrets im Klartext vorgehalten werden. Lautet unsere Passphrase beispielsweise "einfaltslosePassphrase", tragen wir dort folgende Zeile ein:
: RSA gwKey.pem "einfaltslosePassphrase"
Es versteht sich, dass ipsec.secrets nur für root zugänglich sein darf.
Mit dem Bezeicher für den Inhaber des Gateway-Zertifikats stopfen wir jetzt noch de letzte Lücke in unserer /etc/ipsec.conf. Dort tragen wir den kompletten Bezeichner als leftid im Abschnitt conn %default ein. In unserem Beispiel lautet die entsprechende Zeile:
leftid="C=DE, ST=Bavaria, L=Munich, O=IDG Interactive GmbH, OU=tecCHANNEL, CN=fenrisGW, Email=jluther@tecchannel.de"
Benutzerzertifikate
Für jeden Benutzer gilt es jetzt das Zertifizierungsspiel noch einmal zu wiederholen. Bei der Erstellung des Private Key für eine User mit:
openssl genrsa -des3 -out private/userKey.pem 1024
vergeben Sie für jeden Benutzer eine eigene Passphrase. Mit dieser beantragen sie anschließend ein Zertifikat:
openssl req -new -key private/userKey.pem -out userReq.pem
Es soll gemäß der Voreinstellung in der openssl.cnf für 365 Tage gültig bleiben.
Jetzt erzeugen Sie das Zertifikat, das sie als Root CA signieren. Dabei beschränken Sie die Gültigkeitsdauer praktischerweise mit -enddate auf das laufende Quartal:
openssl ca -notext -enddate 0209301200Z -in userReq.pem -out userCert.pem
So ersparen Sie sich ein Zurückrufen von Zertifikaten bei der üblichen Personalfluktuation zum Quartalsende. Zudem erhöht eine regelmäßige Neuvergabe die Sicherheit.
Von diesem Zertifikat erzeugen Sie im letzten Schritt eine binäre Version im PKCS#12-Format, die wir im nächsten Teil des Workshops für die Nutzung mit Windows-2K/XP-Clients benötigen:
openssl pkcs12 -export -in userCert.pem -inkey private/userKey.pem -certfile caCert.pem -out user.p12
Certificate Revocation List
Auch bei einer Laufzeitbeschränkung der Zertifikate lässt es sich gelegentlich nicht umgehen, ein bereits ausgegebenes Zertifikat manuell wieder zu sperren. Dafür benötigen wir eine CRL, die wir in regelmäßigen Zeitabständen erneuern müssen. Das entsprechende Intervall geben wir in der openssl.cnf mit dem Eintrag default_crl_days an, der als Vorgabe auf 30 Tage gesetzt ist.
Die CRL generieren wir als Root CA mit:
openssl ca -gencrl -out crl/crl.pem
wobei wir die Gültigkeitsdauer über die optionalen Parameter -crldays und -crlhours manuell auf wenige Tage oder gar Stunden beschränken können. Anschließend kopieren wir die crl.pem nach /etc/ipsec.d/crls.
Die Sperrung eines Zertifikats wird durch den Aufruf:
openssl ca -revoke userCert.pem
Er markiert in der index.txt das entsprechende Zertifikat als ungültig, was allerdings erst bei der nächsten Aktualisierung der CRL zum Tragen kommt.
Soll die CRL auf einem Server öffentlich zugänglich gemacht werden, muss sie noch ins binäre DER-Format konvertiert werden:
openssl -crl -in crl/crl.pem -outform der -out crl/cert.crl
Ausblick
Damit haben wir die Konfiguration des Security Gateways erfolgreich hinter uns gebracht. Im zweiten Teil des Workshops nehmen wir uns die Konfiguration entsprechender VPN-Clients für Windows unter die Lupe.
Dabei kommen dann sowohl die VPN-Bordmittel von Windows 2000 und XP zum Zuge als auch spezielle VPN-Client-Software wie das für private Zwecke kostenlose PGPnet.
Literatur
Konfiguration und Einsatz der bei VPNs verwendeten kryptologischen Verfahren und Algorithmen erscheinen oft recht undurchsichtig, wenn man nicht über einige grundlegende Kenntnisse zu deren Ursprung und Wirkungsweise verfügt.
Jedem, der sich mit Kryptologie im Allgemeinen beschäftigen muss, kann man als Einstieg das Buch Verschlüsselte Botschaften von Rudolf Kippenhahn wärmstens empfehlen. Es erzählt in spannender, durchaus auch Nachttisch-tauglicher Form die Geschichte der Verschlüsselung und des Kryptoangriffs von Julius Caesar bis zu PGP. Die eingehende Beschreibung der über die Jahrhunderte weiterentwickelten Kryptoverfahren vertieft insbesondere das Verständnis für Wirkungsweise und Probleme der verwendeten Algorithmen.
(Kippenhahn, R: Verschlüsselte Botschaften; Geheimschrift, Enigma und Chipkarte; Rowohlt-Taschenbuch, 1999; ISBN 3-449-60807-3; 9,90 Euro)
Wer bei der Lektüre von Kippenhahns Standardwerk Blut geleckt hat, kann seine Kenntnisse mit dem Titel Abenteuer Kryptologie von Reinhard Wobst ausbauen. Es behandelt die rechnergestützte Kryptologie und beschreibt eingehend Verfahren und Algorithmen gängiger Krypto-Implementationen wie DES, RSA, IDEA, RC5, Blowfish, PGP oder SSH. Codebeispiele liegen jeweils auf CD bei, eigenen Experimenten steht also nichts im Weg.
(Wobst, R.: Abenteuer Kryptologie; Methoden, Risiken und Nutzen der Datenverschlüsselung; Addison Wesley Longman, 2001 (3.Aufl.); ISBN 3-8273-1815-7; 39,95 Euro)