VPN – Virtuelle Private Netze, Teil III:
Tunnelarbeiten

Ein Kunde der ORDIX AG richtete vor einigen Wochen eine neue Geschäftsstelle ein. Bei der Eingliederung in das Unternehmensnetzwerk wurde aus Kosten- und Flexibilitätsgründen eine VPN-Lösung auf Linux Basis realisiert.

In diesem Beitrag wird nun die konkrete Umsetzung eines VPN mit IPsec auf Basis des freien Betriebssystems Linux dargestellt. Die technischen Hintergründe, die bei der Realisierung eines solchen VPN in IP-Netzwerken Anwendung finden, stellten wir bereits in der Ausgabe 2/2003 vor.

Arbeitsvorbereitung

Der Kernel des Linux-Betriebssystems enthält standardmäßig keine IPsec-Funktionalität. Sie kann aber nachträglich hinzugefügt werden. Benötigt wird dazu die Software des FreeS/WAN Projekts (http://www.freeswan.org). Neben der Anpassung des Kernels (Kernel IPsec Support - KLIPS) stellt dieses Produkt ein Dienstprogramm (ipsec) zur Administration der IPsec-Verbindungen sowie einen Dämon (pluto) zur Aushandlung von Security Associations über das IKE-Protokoll zur Verfügung.

Um die RSA-Authentifizierung mit Zertifikaten nach X.509 Standard realisieren zu können, müssen die Quellen des FreeS/WAN Projekts zudem mit einem Patch erweitert werden. Dieser wird von der strongSec GmbH im Internet kostenlos zum Download angeboten (http://www.strongsec.com).

Die Anpassung des Linux-Systems läuft in folgenden Schritten ab (siehe Abb. 1):

• Quellen des aktuellen Linux-Kernels (derzeit Version 2.4.21) in das Verzeichnis /usr/src/linux entpacken.
• Quellen der FreeS/WAN Software in das Verzeichnis /usr/src/freeswan-<Version> entpacken.
• Quellen des X.509-Patch für FreeS/WAN in das Verzeichnis /usr/src/X509patch-<Version>-freeswan-<Version> entpacken.
• Quellen von FreeS/WAN mit dem X.509-Patch anpassen.
• Kernel konfigurieren.
• Kernel und Kernelmodule sowie FreeS/WAN Dienstprogramme übersetzen und installieren.

cd /usr/src
tar xvfz linux-2.4.21.tar.gz
tar xvfz freeswan-2.00.tar.gz
tar xvfz x509-1.3.3-freeswan-2.00.tar.gz
cd freeswan-2.00
patch -p1 < ../x509-1.3.3-freeswan-2.00
           /freeswan.diff
make menumod
make kinstall

Im Anschluss daran ist das Kernelmodul /lib/modules/2.4.21/kernel/net/ipsec/ipsec.o verfügbar und kann mit insmod ipsec geladen werden. Es ist aber auch möglich, KLIPS fest in den Kernel einzubinden.

Wie im vorhergehenden Artikel erläutert wurde, ist zur Kommunikation über IPsec zunächst die Aushandlung einer Security Association über das IKE-Protokoll notwendig. Zu diesem Zweck enthält die FreeS/WAN Software den Dämon pluto, welcher eingehende IKE-Verbindungen auf dem UDP Port 500 annimmt und verarbeitet. Er wird über zwei Dateien konfiguriert:

• /etc/ipsec.secrets enthält Daten zur Authentifizierung, wie z. B. private Schlüssel oder Passwörter
• /etc/ipsec.conf enthält die Konfiguration der IPsec-Verbindungen

Grabungsarbeiten

Bei einem Kunden der ORDIX AG wurde vor einigen Wochen eine neue Geschäftsstelle errichtet. Bei der Eingliederung in das Unternehmensnetzwerk wurde aus Kosten- und Flexibilitätsgründen eine VPN-Lösung auf Linux Basis realisiert. Zu diesem Zweck wurden seitens der ORDIX AG zunächst zwei Linux Server mit IPsec Funktionalität ausgestattet, wie eingangs beschrieben.

Anschließend wurden mit der GNU-Software openssl RSA-Schlüsselpaare für die beteiligten VPN-Gateways erzeugt und von einer ebenfalls mittels openssl eingerichteten Certification Authority (CA) signierte Zertifikate erstellt.

Der private Schlüssel, die Widerrufsliste für Zertifikate (CRL), das Zertifikat des Gateways sowie der Zertifizierungsstelle wurden dann auf die Gateways übertragen.

Der private Schlüssel wird im Verzeichnis /etc/ipsec.d/private abgelegt, die Certification Revocation List im Verzeichnis /etc/ipsec.d/crls, das Gateway-Zertifikat im Verzeichnis /etc/ipsec.d und das Zertifikat der CA in /etc/ipsec.d/cacerts. Danach wird die Verbindung in die Konfigurationsdatei /etc/ipsec.conf (siehe Abb. 2) eingetragen.

Diese Datei teilt sich in drei Bereiche auf:

• config setup: Allgemeine Einstellungen zur Konfiguration des pluto-Dämon.
• conn %default: Standardeinstellungen für alle Verbindungen.
• conn <Name der Verbindung>: Die speziellen Einstellungen für eine Verbindung.

Es ist empfehlenswert, aus Gründen der Übersichtlichkeit für jede Verbindung eine zusätzliche Konfigurationsdatei zu erstellen und diese mittels include in die ipsec.conf einzubinden (siehe Abb. 2).

# /etc/ipsec.conf - FreeS/WAN IPsec
  configuration file

# Grundeinstellungen
config setup
  interfaces=ipsec1=eth1
  klipsdebug=none
  plutodebug=none
  plutoload=%search
  plutostart=%search
  forwardcontrol=yes

# Default
conn %default
  keyingtries=0
  disablearrivalcheck=no
  authby=rsasig
  compress=yes

# HQ-GSneu VPN
include /etc/ipsec.d/site2site/
  HQ-GSneu-tunnel.conf

Diese Datei enthält nun alle spezifischen Einstellungen der neuen Verbindung. Für die beiden Kommunikationspartner werden die Pseudonyme left und right benutzt. Die wichtigsten Konfigurationseinträge werden nachfolgend erläutert. Die Einstellungen für die beiden Gateways finden Sie in Abb. 3.

Abb. 3: Einstellungen für die beiden Gateways der Kommunikationspartner mit den Pseudonymen left und right.

conn HQ-GSneu:
Der Name der Verbindung.

interfaces=ipsec1=eth1:
Das Netzwerkinterface eth1 wird für IPsec-Verbindungen genutzt.

authby=rsasig:
Die Authentifizierung erfolgt über RSA.

Testfahrt

Der Aufbau des Tunnels wird über den Aufruf des Kommandos

ipsec auto —up HQ-GSneu

initiiert. Erst nachdem die Security Association eingerichtet ist, werden die Routing-Einträge auf den Gateways durch das mit leftupdown bzw. rightupdown definierte Skript automatisch so angepasst, dass IP-Pakete aus den dahinterliegenden Subnetzen weitergeleitet werden. Zudem werden eventuell benötigte Firewall-Einstellungen durch diese Skripte angepasst.

Auf diese Weise wird verhindert, dass Daten unverschlüsselt über das unsichere Netz transportiert werden können.

total 12
drwxr-xr-x   2 root  root  4096 Apr 24 11:19 cacerts
drwxr-xr-x   2 root  root  4096 Apr 24 11:19 crls
drw———       2 root  root  4096 Apr 24 11:33 private
drwxr-xr-x   2 root  root  4096 May 28 09:21 site2site
-rw-r—r—     1 root  root  4529 Apr 24 11:33 HQgwCert.pem

./cacerts:
total 4
-rw-r—r—	    1 root  root  934 Apr 24 11:19 RootCA.der

./crls:
total 4
-rw-r—r—	    1 root  root  589 Apr 24 11:19 crl.pem

./private:
total 4
-rw———	    1 root  root  1743 Apr 24 11:33 HQgwKey.pem

./site2site:
total 4
-rw-r—r—	    1 root  root  510 May 12 23:02 HQ-GSneu-tunnel.conf

Eröffnung

Das Linux-System leitet zudem nur dann IP-Pakete weiter, wenn der Kernel mit Unterstützung für IP-Forwarding kompiliert wurde und die Weiterleitung zudem explizit aktiviert ist. Dies geschieht über einen Eintrag im Pseudo-Dateisystem /proc:

echo 1 > /proc/sys/net/ipv4/ip_forward

Beim Systemstart ist dieser Wert auf 0 gesetzt. Eine Weiterleitung von Paketen wird somit verhindert. Um die Weiterleitung beim Start des pluto zu aktivieren sowie bei dessen Stop wieder zu deaktivieren wird folgender Eintrag in die /etc/ipsec.conf hinzugefügt:

forwardcontrol=yes

Auf diese Weise wird zusätzlich verhindert, dass Pakete weitergeleitet werden, obwohl der Dämon zur Verarbeitung von IPsec-Verbindungen nicht gestartet ist. Ist der IPsec-Tunnel zwischen den VPN-Gateways aufgebaut und sind die Routingeinträge entsprechend angepasst, können nun die Rechner aus den Subnetzen 192.168.1.0/24 und 192.168.2.0/24 durch den Tunnel miteinander kommunizieren.

Wie dicht ist der Tunnel?

Durch den Einsatz von ESP im Tunnelmodus sind die IP-Pakete während des Transfers durch das Internet komplett verschlüsselt. Standardmäßig geschieht dies bei FreeS/WAN mit dem als sehr sicher geltenden symmetrischen Verschlüsselungsverfahren Triple-DES, welches mit einer Schlüssellänge von 168 Bit arbeitet. Durch die vollständige Einkapselung der IP-Pakete ist auch die ursprüngliche Quell- und Zieladresse für einen Angreifer nicht nachvollziehbar.

Zur Authentifizierung der Kommunikationspartner werden Zertifikate mit 2048 Bit Länge des öffentlichen Schlüssels eingesetzt. Solche Schlüssel sind auch auf lange Sicht als praktisch nicht zu knacken anzusehen. Zur Integritätsprüfung werden wahlweise die Verfahren SHA1-96 oder MD5-96 genutzt, welche beide ebenfalls als sehr sicher einzuschätzen sind.

Und wozu das alles?

Durch den Einsatz Virtueller Privater Netze lassen sich z. T. erhebliche Kostensenkungen realisieren. Der Aufwand für die Anbindung der neuen Geschäftsstelle reduzierte sich auf die Anschaffung und Einrichtung der Router-Hardware sowie die Kosten für den Internetanschluss. Das VPN-Gateway sowie der Internetanschluss in der Zentrale waren bereits vorhanden, so dass dort lediglich anteilige Kosten berechnet werden müssen. Insgesamt erzielt die VPN-Lösung nach Aufrechnung aller Aufwände bei diesem Szenario einen Kostenvorteil von 500-700 Euro pro Monat gegenüber einer Standardfestverbindung der Deutschen Telekom. Bei einer Erhöhung der Bandbreite steigen die Kostenvorteile zudem überproportional.

Blick in die Zukunft

Alle aktuellen Studien gehen von einer stark wachsenden Bedeutung der IP VPN in den nächsten Jahren aus. Dabei werden für IPsec als offener Standard zur gesicherten Datenübertragung sowie der Authentifizierung von Systemen besonders gute Aussichten bescheinigt. Einer Studie im Auftrag des Bundesministeriums für Sicherheit in der Informationstechnik zufolge wird sich IPsec zur Authentifizierung von Endsystemen durchsetzen und im Laufe der nächsten Jahre zudem zum wichtigsten Verfahren zur Sicherung von Vertraulichkeit und Integrität von Daten entwickeln.

Seitenanfang

Seite drucken

Seite weiterempfehlen