Home
Über die LugBE | Mailing List | Treff & Events | Projekte | lost+found | Support

IPSec-Installation - FreeS/WAN

Hands-on VPN mit Linux und FreeS/WAN

Begleitete Installation, HTA Bern, 13. Juli 2002

Als 2. Teil unseres IPSec-Zyklus folgte dieser praktische Teil dem Theorievortrag vom April im Café Kairo.

Neu: Auch mit FreeBSD als Gateway/Firewall bekommt man eine sehr schöne Lösung. Hier ein Beitrag dazu.

Es ging jetzt darum, die verschiedenen theoretischen Ausführungen über IPSec und FreeS/WAN, die uns alle mehr oder weniger über die Funktionsweise der verschiedenen Sicherheits- und Verschlüsselungsprotokolle erleuchtet hatten, in die Tat umzusetzen (oder fachsprachlich ausgedrückt: "Vergiss, was Du gehört hast, und bring das Ding irgendwie zum Fliegen."). Ein/e jede/r sollte die Ausrüstung und zumindest eine vage Idee vom Wunsch-Setup mitbringen, und zusammen sollte das dann implementiert werden.

An der HTA Bern durften wir freundlicherweise wieder einen Raum als Labor verwenden - ein grosses Dankeschön an Tobias, der uns auch sonst mit Rat und Tat und Hardware zur Seite stand (man kann ja wohl von einem Haufen Informatiker nicht erwarten, dass sie wirklich alles Material dabeihaben, oder? Besonders so Nebensächlichkeiten wie Bildschirm, Tastatur oder Power-Kabel braucht man ja nicht ständig ... ;-)

Nachdem Mathias erfolgreich die verschiedenen Sicherheitseinstellungen von OpenBSD niedergekämpft hatte und unser Router einsatzbereit war, konnten wir loslegen. Das Setup sah mehrere Subnetze vor, die über IPSec-Gateways an ein gemeinsames Transportnetz angeschlossen waren und von dort aus weiter ins Internet. Die Verschlüsselung fand dabei zwischen den Clients und den Gateways statt. Ein solcher Client-Gateway-Tunnel macht wohl vor allem dann Sinn, wenn die Strecke zwischen den beiden unsicher ist, wie das z.B. bei Wireless-LAN-Verbindungen der Fall ist. Mit kleinen Änderungen lässt sich daraus aber auch eine Gateway-Gateway-Verbindung ableiten, die dann verschiedene Subnetze über ein unsicheres Transportnetz (z.B. Internet) miteinander verbindet.

Schema des Netzaufbaus am Event

Eine Besonderheit von FreeS/WAN ist es, dass auf Client und Gateway beinahe identische Konfigurationsdateien verwendet werden. Von diesen gibt es genau zwei, nämlich /etc/ipsec.conf (die Hauptkonfiguration) und /etc/ipsec.secrets (hier werden die privaten, geheimen Verbindungsparameter gespeichert).
Wir verwendeten zum Einstieg Pre-Shared Secrets (PSK) zur Authentisierung der Rechner untereinander. Dank des X.509-Patches können aber auch X.509-Zertifikate verwendet werden. Leider fehlte uns am Schluss die Zeit, auch das aufzusetzen (und vor allem fehlte wohl Markus das nötige Fingerspitzengefühl im Umgang mit openssl :-)

Wir haben folgende Versionen verwendet:

Der Patch- und Installationsprozess ist hier ausführlich beschrieben.

Bei anderen, früheren Versionen kann die Syntax der Konfigurationsdateien abweichen. Insbesondere haben frühere Versionen des X.509-Patches das Einlesen von Zertifikaten und Keys aus externen Dateien nicht unterstützt. Die Parameter mussten dort mit Hilfe eines besonderen Programms aus den Keys/Zertifikaten extrahiert und in der Konfiguration von Hand eingetragen werden.


Auf einem Client-Gateway-Paar sahen die Konfigurationen schliesslich wie folgt aus (Die Einrückungen müssen übrigens Tabs sein):

/etc/ipsec.conf

Client

config setup

interfaces=%defaultroute
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
uniqueids=yes

conn %default

keyingtries=0
disablearrivalcheck=no
#authby=rsasig *)
auto=add
keylife=3600s
rekey=yes
auth=esp
pfs=yes

conn lugbe-out

left=%defaultroute
right=192.168.1.1
rightsubnet=0.0.0.0/0


Gateway

config setup

interfaces=ipsec0=eth1
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
uniqueids=yes

conn %default

keyingtries=0
disablearrivalcheck=no
#authby=rsasig *)
auto=add
keylife=3600s
rekey=yes
auth=esp
pfs=yes

conn lugbe-out

left=%any
right=192.168.1.1
rightsubnet=0.0.0.0/0


config setup
Dieser Abschnitt beschreibt Parameter zur Initialisierung des gesamten IPSec-Subsystems.

interfaces=%defaultroute bereitet genau ein Interface, nämlich das, über das die Defaultroute geht, als IPSec-Interface vor.

interfaces=ipsec0=eth1 bereitet Interface eth1 als IPSec-Interface vor.

conn %default

Diese Sektion enthält die Parameter, die für alle Verbindungen gelten. Wir haben die Defaults belassen.
auto=add bewirkt, dass der Host auf Verbindungen wartet, von selbst aber keine initiiert. Um das zu bewirken, müsste es auto=start heissen. Das ist eigentlich nur bei Clients sinnvoll.

Alle Parameter in conn %default können genausogut pro Verbindung einzeln in einer conn Verbindungsname-Sektion angegeben werden. Was am Ende wo steht, hängt nur von den Anforderungen des jeweiligen Netzwerk-Layouts ab.

*) authby=rsasig: Um eine reine RSA-Authentisierung ohne den x509-Patch zu verwirklichen, muss auf beiden Hosts je ein RSA-Key-Paar mittels ipsec newhostkey erzeugt werden. Der Output dieses Kommandos wird dann in /etc/ipsec.secrets eingetragen. Mit ipsec showhostkey --left bzw. ipsec showhostkey --right wird auf dem jeweiligen Host der RSA-Public-Key extrahiert. Diese Keys werden dann als leftrsasigkey bzw. rightrsasigkey in /etc/ipsec.conf eingetragen. Aber Achtung: Da diese Keys pro Host unique sein müssen, funktioniert dann natürlich der Parameter left=%any auf dem Gateway nicht mehr. Statt dessen muss für jeden Host, der diese Methode verwendet, eine eigene conn-Sektion erstellt werden. Für alle andern Hosts müsste (untested!) wohl nach left=%any dann mittels authby=psk festgelegt werden, dass sie Preshared Secrets verwenden.

Per default wird authby=psk angenommen.

conn lugbe-out
Unter conn Verbindungsname werden die Parameter angegeben, die für eine bestimmte Verbindung gelten. Sinnvollerweise kommmt hier alles hin, was mit IP-Adressen, Zertifikaten und anderen Host-spezifischen Einstellungen zu tun hat. Da ein Host beliebig viele Verbindungen (Tunnels) aufbauen kann, können beliebig viele conn-Sektionen bestehen. Der Name Verbindungsname ist beliebig und wird nur lokal verwendet.

left und right bezeichnen die beiden Tunnel-Endpunkte. Welcher Host als left und welcher als right bezeichnet wird, spielt keine Rolle, FreeS/WAN ist schlau genug, herauszufinden, welcher Parameter für welchen Host gilt. Eine einheitliche Nomenklatur erhöht die Übersichtlichkeit aber exponentiell! In unserem Beispiel ist left immer der Client und right immer der Gateway.

left=%defaultroute: Die IP-Adresse des Interfaces mit der Defaultroute wird verwendet. Das funktioniert nur, wenn bei config setup auch interfaces=%defaultroute angegeben wurde. Wird dort ein bestimmtes Interface angegeben (etwa interface=ipsec0=eth0), muss hier eine IP-Adresse stehen.

left=%any: Clients mit beliebiger IP-Adresse können Verbindungen aufbauen. Das ist eine typische Gateway-Einstellung. Es wäre auch möglich, für jeden Client eine eigene conn-Sektion zu erstellen.

right=192.168.1.1: Die IP-Adresse des Gateways. In unserem Beispiel liegt der Gateway im gleichen Subnetz wie der Client, daher braucht es keine weiteren Parameter. Wenn der IPSec-Gateway über einen weiteren Gateway erreichbar ist, muss man diesen noch mit leftnexthop=IP.des.Gate.ways angeben.

right=192.168.1.1: Die IP-Adresse des Gateways.

rightsubnet=0.0.0.0/0: Verbindungen in dieses Subnetz (das hinter dem Gateway right liegt) werden bis zum Gateway verschlüsselt. Im VPN-Jargon die "Encryption Domain". In userem Fall werden alle Verbindungen, die über den Gateway gehen, verschlüsselt; das sind alle Verbindungen zu Hosts ausserhalb des eigenen Subnetzes 192.168.1.0/24.

rightsubnet=0.0.0.0/0: Verbindungen in dieses Subnetz werden bis zum Gateway verschlüsselt.

/etc/ipsec.secrets

Client

192.168.1.5 192.168.1.1 : PSK "secret pw"

Gateway

%any 192.168.1.1 : PSK "secret pw"

Die Authentisierung der Hosts 192.168.1.5 (Client) und 192.168.1.1 (Gateway) untereinander erfolgt über ein geheimes Passwort ("Pre-Shared Secret", PSK). Dieses muss beiden Hosts bekannt sein. Das Secret dient dabei nur dem Aufbau eines ersten verschlüsselten Tunnels, über den dann die eigentlichen Verschlüsselungsparameter ("Security Association", SA) ausgehandelt werden.

192.168.1.5 192.168.1.1 : PSK "secret pw"
Pro IP-Adressen-Paar kann ein eigenes Secret konfiguriert werden. Als Adressen sind dabei immer die Tunnel-Endpunkte anzugeben. (untested: Es müsste statt der eigenen IP auch %defaultroute funktionieren, also
%defaultroute 192.168.1.1 : PSK "secret pw")

%any 192.168.1.1 : PSK "secret pw"
Hier verwenden alle Clients das selbe Secret, um sich am Gateway zu authentisieren. Möglich wäre auch hier eine strikte Client-Gateway-Kopplung. Spätestens beim 10. Client wird das ganze aber unübersichtlich, und die Wartbarkeit spottet jeder Beschreibung.


Mit dem obigen Setup muss die Verbindung lugbe-out noch von einer Seite initialisiert werden, da ja beide mit auto=add nur auf Verbindungen warten. Am einfachsten geht das mit ipsec auto --up lugbe-out (auf dem Client). Danach gibt es einiges an Output. Wenn zuletzt so etwas steht wie "SA established", war der Aufbau des IPSec-Tunnels erfolgreich. Wenn es jetzt immer noch nicht funktioniert, liegt das Problem ziemlich sicher am Routing. ipsec eroute gibt Auskunft über das Routing im Tunnel, ipsec look zeigt die aktuellen Verbindungsparameter. man ipsec schliesslich ist jetzt sonst wohl Dein bester Freund. IP-Forwarding muss übrigens beidseitig aktiviert werden (echo "1" > /proc/sys/net/ipv4/ip_forward)


... und jetzt das Ganze nochmal mit X.509-Zertifikaten

Das bisherige Setup funktioniert ohne den X.509-Patch. Um die Authentisierung der Hosts nicht mittels Pre-Shared Secrets, sondern mit Zertifikaten zu machen, braucht man - neben dem Patch - noch ein RSA-Schlüsselpaar im X.509-Format. Wie man dieses erzeugt, ist schon oft beschrieben worden, unter anderem hier. Dort ist auch der ganze Setup detailliert und verständlich beschrieben.
In unserem Beispiel ergäben sich folgende Änderungen:

/etc/ipsec.conf (mit X.509-Zertifikaten)

Client

conn %default

[...]
rightrsasigkey=%cert
leftcert=client.crt
[...]

conn lugbe-out

[...]
rightid="C=CH, ST=BE, O=LugBE, OU=IT Net Services, CN=gateway.lugbe.ch"
[...]

Gateway

conn %default

[...]
leftrsasigkey=%cert
rightcert=gateway.crt
[...]

conn lugbe-out

[...]
leftid="C=CH, ST=BE, O=LugBE, OU=IT Guests, CN=client.lugbe.ch"
[...]

Sämtliche Parameter können, wie schon gesagt, auch in der jeweiligen conn Verbindungsname-Sektion stehen. YMMV.

rightrsasigkey=%cert: Extrahiere RSA-Public-Key aus dem von der Gegenseite präsentierten Zertifikat.

leftcert=client.crt: Das Zertifikat, mit dem der Client sich

gegenüber anderen Hosts/Gateways authentisiert, liegt hier unter /etc/ipsec.d/client.crt.

leftrsasigkey=%cert: Extrahiere RSA-Public-Key aus dem von der Gegenseite präsentierten Zertifikat.

rightcert=gateway.crt: Das Zertifikat, mit dem der Gateway sich gegenüber anderen Hosts/Gateways authentisiert, liegt hier unter /etc/ipsec.d/gateway.crt

Wenn man das Zertifikat wie hier bei conn %default angibt, wird es zum Default-Zertifikat. Den gleichen Effekt erzielt man, wenn man das Zertifikat im DER-Format unter /etc/x509.der speichert.

rightid="C=CH, ST=BE, ..."

leftid="C=CH, ST=BE, ..."

Der einfachste Fall ist, die Gegenseite anhand des Subjects ihres Zertifikats zu erkennen. Aus dem Zertifikat kann das Subject wie folgt extrahiert werden: openssl x509 -in dateiname.crt -noout -subject

/etc/ipsec.secrets (mit X.509-Zertifikaten)

Client

: RSA client.key ""

Gateway

: RSA gateway.key ""

Der private Teil des Schlüssels, client.key bzw. gateway.key wird meist zusammen mit dem Zertifikat erzeugt. FreeS/WAN sucht den private key per default unter /etc/ipsec.d/private. Ist der Key verschlüsselt abgelegt, kann am Ende der Zeile noch die Passphrase zur Entschlüsselung angegeben werden. Bei uns war der Key nicht verschlüsselt, daher keine Passphrase.

Wird der Key wie oben angegeben, wird er wieder zum Default-Key. Neuerdings unterstützt FreeS/WAN auch mehrere private Keys. Diese können dann wieder pro IP-Adresse(-Paar) angegeben werden. (192.168.1.1 : RSA client.key "" bzw. 192.168.1.5 192.168.1.1 : RSA client.key "")


Wundersamerweise funktionierte der Setup auf Anhieb. Was? Haben wir etwa Murphys Gesetz widerlegt? Nicht ganz. Immerhin fiel das anschliessend geplante Grillfest im Freien dem Regen zum Opfer - dafür konnten wir uns bis zu nachtschlafener Stunde von Marcs Kochkünsten und den Vorteilen von Gentoo Linux überzeugen.

Hier noch ein paar Schnappschüsse von der Installation. Besonders deutlich zu erkennen sind die freien Plätze derjenigen, die sich zwar angemeldet, dann aber den weiten Weg zur HTA doch nicht gefunden hatten (Hint, Hint).



Gruppenbild mit Kugelfisch:
Warten auf OpenBSD und eine
statische Route ...



An Computern hat es
also offensichtlich nicht
gefehlt.



Networkinformationcenter-
remotedisplayhhostencryption-
masterconsole


Webmaster at lugbe.ch

Die Artikel dieser Seite stehen unter Copyleft ihrer jeweiligen Autor*innen. Ihre Nutzung, Wiedergabe etc. untersteht den Bedingungen der GNU Free Documentation License (http://www.gnu.org/copyleft/fdl.html), wo nicht explizit anders vermerkt.