Inhaltsverzeichnis
Sichere OGC-Dienste
Allgemeine Erläuterungen z.B. Betrachtungen zu Vor- und Nachteilen finden sich auch im Blog.
Einleitung
Ein bekanntes Problem: OGC-Dienste wie z.B. WMS können nicht abgesichert werden. Jeder, der die URL des Dienstes kennt, kann den Dienst nutzen. Das ist ja eigentlich auch ganz schön, da es ja „Open Geospatial“ Dienste sind 
. Aber es gibt auch Fälle, wo man den Zugang beschränken muss, also nur einer begrenzten Gruppe an Anwendern der Zugriff zu einem oder mehreren Diensten gewährt werden darf.
Alle bekannten (mir) Methoden haben den Nachteil, dass die Dienste auf die eine oder andere Art „verbogen“ werden müssen und somit der Zugriff mit Standard-Werkzeugen nicht mehr klappt und man auf die Client- und Server-Lösungen des jeweiligen Anbieters angewiesen ist. Spätestens wenn man mehrere geschützte Dienste unterschiedlicher Anbieter, die unterschiedliche Systeme einsetzten wirds kompliziert … man könnte auch sagen, dass dann die Interoperabilität, also DER große Vorteil der OGC-Dienste nicht mehr gegeben ist.
Nachfolgend ist beschrieben, wie ein solcher Zugriff so eingerichtet werden kann, dass die volle Interoperabilität gewährleistet bleibt und trotzdem ein geschützter Zugriff gewährleistet werden kann.
Lösung
Es wird durch ein VPN (virtuelles privates Netz) eine sichere Verbindung zwischen Client und Server hergestellt, die einen Zugriff wie im lokalen Netz bzw. wie im Internet ermöglicht. Es wird dazu auf Netzwerkebene ein Tunnel hergestellt über den die OGC-Dienste genutzt werden können ohne dass an den Diensten selbst etwas gemacht werden müsste.
Da es sich um ein virtuelles privates Netz handelt ist keinerlei zusätzliche Hardware erforderlich. Die Verbindung wird über eine zusätzliche Netzwerk-Karte, die per Software eingerichtet wird, hergestellt. Somit ist auch der Zugriff auf mehrere geschützte Dienste auf diese Art und Weise möglich, da für jede Verbindung lediglich eine weitere Netzwerkkarte eingerichtet werden muss. Voraussetzung ist lediglich, dass der Ziel-Server vom Client aus über das Netz erreichbar sein muss.
Die im nachfolgenden skizzierte Lösung verwendet OpenVPN mit selbsterstellten Zertifikaten (easy-rsa)
Mittels eine peer to peer Verbindung wird ein abgesicherter Tunnel zwischen Client und Server aufgebaut.
Testumgebung
- Server: VM ubuntu Linux 8.04 Server
- Client: VM WindowsXP
- Netz: beide „sehen“ sich über das lokale Netz
Server einrichten
sudo apt-get install openvpn
Es werden folgende (im folgenden wichtige) Verzeichnisse angelegt:
Für das Erzeugen der Schlüssel:
./usr/share/doc/openvpn/examples/easy-rsa/2.0/
Und OpenVPN eben:
./etc/openvpn
Keys erzeugen
Quelle … Hier kann man das auch nochmal genauer nachlesen was wozu passiert …
Neues Verzeichnis anlegen (z.B. in /opt/)
sudo mkdir /opt/easy-rsa2/
rüberkopieren:
cp /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /opt/easy-rsa2/
Vars anpassen:
vim /opt/easy-rsa2/vars
Hier folgendes anpassen:
# In how many days should the root CA key expire? export CA_EXPIRE=3650
Laufzeit des Zertifikats eben … kann man aber so stehenlassen
export KEY_COUNTRY="DE" export KEY_PROVINCE="BB" export KEY_CITY="Brandenburg" export KEY_ORG="MeineFirma" export KEY_EMAIL="meine@mailadresse.com"
abspeichern! [ESC] :wq
cd /opt/easy-rsa2/ . ./vars ./clean-all
CA-Key und CA-Cert erzeugen: (einmal und dann nie wieder!)
./build-ca
Diffie-Hellman Parameter erzeugen
./buid-dh
Server Schlüssel bauen:
. ./vars ./build-key-server server01
Natürlich als Servernamen einen sinnvollen Namen verwenden, die Abfragen durchentern, ggf. noch sinnvolle Angaben nachtragen
Nun wurden im Verzeichnis /opt/easy-rsa2/keys etliche Dateien erzeugt. Wir benötigen:
- ca.cert
- dh1024.pem
- server01.crt
- server01.key
Verzeichnis im openvpn-Arbeitsverzeichnis anlegen:
mkdir /etc/openvpn/keys
und die Dateien dorthin kopieren:
cp /opt/easy-rsa2/keys/ca.cert /etc/openvpn/keys cp /opt/easy-rsa2/keys/dh1024.pem /etc/openvpn/keys cp /opt/easy-rsa2/keys/server01.crt /etc/openvpn/keys cp /opt/easy-rsa2/keys/server01.key /etc/openvpn/keys
Client-Schlüssel bauen:
. ./vars ./build-key-pass vpnclient01
Es wurden nun die folgenden Schlüssel für den Client erstellt:
- ca.crt
- vpnclient01.crt
- vpnclient01.key
Wichtig: Anderen Hostnamen als bei der Server-Schlüsseln verwenden! Diese Keys müssen auf einem sicheren Weg an den Client geschickt werden. Diese Dateien dürfen nicht verändert werden, also NICHT via WebServer zum Dowload anbieten, da dann die Zeichensätze evtl. angepasst werden. Am Besten ist es, die Dateien zu packen (tar -cvf …) und so weiterzugeben.
Zum Testen kann man die Keys natürlich als Key.tar nach /var/www kopieren und sich dort via Webserver auf den Client ziehen! ABER BITTE NUR ZUM TESTEN!
Server starten
Verzeichnis anlegen: /etc/openvpn/keys
Keys rüberkopieren:
- ca.crt
- server01.crt
- server01.key
Im Verzeichnis /etc/openvpn/keys Konfigurationsdatei anlegen:
vim /etc/openvpn/vpn1.conf
folgenden Inhalt reinkopieren:
server 10.8.0.0 255.255.255.0 # virtuelles VPN-Netzwerk port 1194 # Auf Port 1194 horchen proto udp # Protokoll UDP, für TCP: proto tcp-server dev tap # evtl. tap0 unter Linux # Hier die Pfade anpassen um auf die erstellten Keys zu verweisen ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/server01.crt key /etc/openvpn/keys/server01.key # Falls eine PKCS#12 Datei verwendet wird, statt ca/cert/key diese Zeile verwenden # pkcs12 server.p12 dh /etc/openvpn/keys/dh1024.pem # float # wenn Clients ihre IPs während der Verbindung wechseln (Modemeinwahl) ping-timer-rem keepalive 20 180 # Alle 20 Sekunden pingen. 3 Minuten Timeout fuer Clientverbindung verb 3 # Zum Debugging erhöhen # Wenn Vista verwendet wird, diese Zeilen einkommentieren # route-method exe # route-delay 2
Starten des Servers:
openvpn --config /etc/openvpn/vpn1.conf
Dann sollten allerhand Meldungen kommen - und am Ende irgendwas von „Initialization Sequence Completed“ stehen. Finger weg - laufenlassen!
Client einrichten & starten
Hier wird das Vorgehen bei einem Windows-Client beschrieben, was ja meist zutreffen sollte.
Installationspaket openVPN runterladen:
Derzeit ist die Version 2.0.9 aktuell, also den Windows-Installer „openvpn-2.0.9-install.exe“ herunterladen und installieren.
Beim Installationsvorgang meckert Windows, das irgendwas nicht freigegeben oder zertifiziert sei → Ignorieren und weitermachen.
Nach erfolgreicher Installation sollte eine neue Netzwerkkarte in den Eigenschaften der Netzwerkumgebung (Rechstklick auf „Netzwerkumgebung“) auftauchen, die „LAN-Verbindung2“ oder so heisst. Rechtsklick, Eigenschaften aufrufen: Dort sollte unter „Verbindung herstellen über:“ folgender Eintrag zu sehen sein „TAP-WIN32 Adapter V8“ - Wenn nicht, ist es nicht die richtige Karte, die nächste bitte und schauen … wenn gefunden, dann die Netzwerkkarte umbenennen (mit F2) auf „openvpn1“.
Im Verzeichnis „C:\Programme\OpenVPN\config“ folgendes tun:
Schlüssel (aus Abschnitt: Schlüssel erzeugen) dorthin kopieren. Alternativ kann man auch ein Verzeichnis angeben, dann ist der Pfad in der Konfigurationsdatei anzugeben, Die dann mit doppelten Backslashes (\\) angeben.
In der Form „C:\\Programme\\OpenVPN\\config\\keys\\ca.crt“).
Datei vpn01.txt anlegen und mit Editor öffnen. Folgenden Inhalt reinkopieren:
Die erste Zeile muss so angepasst werden, dass dort die IP des VPN-Servers steht (Bei mir zum Testen war das die 192.168.1.144 und beide unterhalten sich auf Port 1194, auch dass kann man noch konfigurieren, aber dann natürlich auch in der Server-Konfiguration.
client remote 192.168.1.144 1194 # Hostname/externe IP des Servers/Routers, Port entsprechend anpassen proto udp # Protokoll UDP, für TCP: proto tcp-client dev tap # evtl. tap0 unter Linux # Hier die Pfade anpassen um auf die erstellten Keys zu verweisen ca ca.crt cert vpnclient01.crt key vpnclient01.key # Falls eine PKCS#12 Datei verwendet wird, statt ca/cert/key diese Zeile verwenden # pkcs12 server.p12 ns-cert-type server # verhindert Man-in-the-Middle Attacken verb 3 # Zum Debugging erhöhen # Wenn Vista verwendet wird, diese Zeilen einkommentieren # route-method exe # route-delay 2
vpn01.txt nach vpn01.ovpn umbenennen.
Start durch Rechtsklick auf die vpn01.ovpn, Auswahl: „Start OpenVPN on this config file“
Es geht ein DOS-Fenster auf und es erscheinen allerhand Meldungen, die letzte müsste hier auch wieder „Initialization Sequence Completed“ heissen. Auf dem Server sollten nun auch verschiedene Meldungen kommen, die die Verbindung des Clients anzeigen.
Voila! Der Tunnel steht.
Nun kann in einem weiteren DOS-Fenster (Start → ausführen → cmd eintippen) mittels des Befehls „ipconfig“ überprüft werden, dass es nun eine weitere aktive Netzwerkverbindung am Ethernetadapter openvpn1 mit der IP 10.8.0.2 gibt.
WebServer anpassen
Es ist nun möglich den Apache-WebServer mit der „offenen“ IP-Adresse (hier 192.168.1.146) anzusprechen (http://192.168.1.146/) im Browser aufrufen, wie auch über die sichere Verbindung mit der IP-Adresse (10.8.0.1) anzusprechen (http://10.8.0.1/) aber das bringt natürlich nichts da der WebServer ja nur auf die sichere Verbindung antworten soll.
Dazu müssen in der Konfigurtaionsdatei folgende Einträge erfolgen:
vim /etc/apache2/sites-enabled/000-default
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
deny from 192.168.
allow from 10.8.0.
</Directory>
Der Eintrag „deny from 192.168.“ schliesst alle Anfragen aus dem Netz 192.168.*.* aus und der Eintrag „allow from 10.8.0.“ erlaubt alle Anfragen aus dem Netz 10.8.0.*. Nach eintrag Apachen restarten:
/etc/init.d/apache2 restart
Nun sollten Anfragen vom Client-Browser mit http://192.168.1.146/ ins leere laufen und die Anfragen mit der IP http://10.8.0.1/ eine Website anzeigen.
Da diese Apache-Einstellungen auch für den Mapserver gelten, der ja eine cgi-bin-Anwendung ist, sollten nun nur noch die Dienste über den sicheren Tunnel beantwortet werden.
Nachbemerkung
Die hier dargestellte Vorgehensweise soll das Prinzip des Aufbaus einer gesicherten Verbindung zwischen Client & Server demonstrieren, so dass man diese mit einfachen Mittels durch Abarbeiten der hier dargestellten Anleitung nachvollziehen und testen kann.
Es sollte NICHT eine produktive Lösung gezeigt werden. Um diese Lösung produktiv zu betreiben sind noch folgende Aspekte zu betrachten und einzurichten:
- Die Dienste, auf dem Server zumindest sollten automatisch starten
- Auf dem Client sollte auch ein automatischer Verbindungsaufbau erfolgen, (Einrichten als Dienst)
- IP-Konflikte müssen ausgeschlossen sein (Es wäre doof, wenn die „normale“ IP des Clients im Bereich 10.8.0.* liegen würde)
Folgende weitere Aspekte sind aber interessant:
- Möglichkeit des Aufbaus einer IP-basierten Zugriffskontrolle: Client mit Zertifikat „X“ bekommt immer nur „seine“ Dienste zu sehen.
- Möglichkeit des Aufbaus eines transparenten Tunnels in ein anderes Netz: Somit könnten alle Dienste dieses Netzes auch genutzt werden.
- Zertifikatsverwaltung: Einsatz von Zertifikaten mit einer bestimmten Laufzeit, nach deren Ablauf keine Verbindung mehr möglich ist.