Fortsetzung von Ausgabe 41/04, Seite 38
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 umfasst 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, sodass Verbindungen erst auf Anfrage einer Gegenstelle hergestellt werden. uniqueids setzen wir auf no, sodass 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 in-ternes 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/fen risCA - 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 Cer-tification 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 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, sodass 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 "einfallslosePassphrase", tragen wir dort folgende Zeile ein:
RSA gwKey.pem "einfallslosePassphrase"
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 Win-dows-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"; RowohltTaschenbuch, 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. Auflage; ISBN 3-8273-1815-7; 39,95 Euro).
GLOSSAR
IPsec: Security Architecture for IP (RFC 2401). Architektur für die sichere Datenübertragung via IPv4 und IPv6. Umfasst Protokolle, Algorithmen und Verfahren für die Schlüsselverwaltung (RFC 2402-2412).
VPN: Virtual Private Network. Beim VPN lassen sich über ein öffentliches Datennetz, wie etwa dem Internet, sichere private Verbindungen beispielsweise in das Firmennetz aufbauen.
AH: IP Authentication Header (RFC 2402). Ermöglicht, die Integrität und Authentizität von Datenpaketen bei der IPsec-Übertragung zu prüfen.
ESP: IP Encapsulated Security Payload (RFC 2406). Sorgt mittels eines Headers und Trailers für die verschüsselte Übermittlung der Nutzdaten über IPsec-Verbindungen.
SA: Security Association, Teil des Internet Security Associa-tion and Key Management Protocol (ISAKMP, RFC 2408/2409). Bezeichnung für eine zwischen zwei Endstellen verhandelte Kommunikationsbeziehung im Rahmen von IPsec.
X.509: ISO/IEC/ITU-Standard für die Public Key Infrastructure (PKI). Siehe auch RFC 2459.
UDP: Das User Datagram Protocol erlaubt das Versenden von Datagrammen zwischen zwei Systemen. Das Protokoll garantiert weder die Zustellungen, noch die korrekte Reihenfolge der zugestellten Datenpakete.
IKE: Internet Key Exchange Protocol (RFC 2409). Definiert Ablauf und Mechanismen für die verschüsselte Verbindungsaufnahme zweier Kommunikations-Endstellen via Internet Protocol Security (IPsec).
CA: Certification Authority, Trustcenter: CAs liefern Schlüssel und digitale Zertifakate für den rechstverbindlichen und vertraulichen Datenverkehr.
tecchannel-Praxis "Sicher ins Internet"
tecChannel.de ist die Nummer eins der Online-Fachmedien in Deutschland (IVW 1/04). Auf www.tecChannel.de finden Sie mehr als 1.700 Beiträge und über 14.000 News zu allen Themen der IT. Das kostenlose Online-Programm wird ergänzt durch das noch umfangreichere kostenpflichtige tecCHANNEL-Premium-Programm und die tecCHANNEL-Compact-Buchreihe.
Die neue Ausgabe von tecCHANNEL-Praxis "Sicher ins Internet, Mail, Fax &-VPN" beschreibt die Installation und Wartung eines kompletten Kommunikationsservers auf Linux-Basis, mit Sicherheits- und Internetfunktionen. Gerade kleinere Unternehmen behandeln die Inter- und Intranet-Kommunikation nach wie vor stiefmütterlich, wie eine aktuelle Studie des Statistischen Bundesamtes belegt.
tecCHANNEL-Praxis "Sicher ins Internet, Mail, Fax &-VPN"-bietet bislang ungesicherten Firmen eine Komplettlösung zum Abschotten ihres Netzzugangs.
Die neue tecCHANNEL-Compact erhalten Sie für 12,95 Euro im Bahnhofshandel sowie im Flughafen-Buchhandel. Sie können tecCHANNEL-Compact auch jederzeit direkt im Online-Shop unterwww.tecChannel.de/shop bestellen. Sie erhalten das Buch dann versandkostenfrei zugeschickt.