Unternehmensnetzwerke

Kein grösseres Unternehmen das am Markt überleben möchte, verzichtet auf Schutzmasnahmen für seine IT Infrastruktur. Neben Virenscannern für die Windows-Desktops sind Proxyserver für den Zugriff auf Webseiten inzwischen etabliert. Zugriff auf http- und https-Seiten kann somit einzig über einen zwingend vorgeschriebenen Proxyserver erfolgen. Oft scannt auf diesem Proxy ein Virenscanner nach den bekannten Schädlingen wie Viren oder Trojaner. Gegen ein solches Konstrukt ist nichts einzuwenden, allerdings bringt es für den Anwender je nach Konfiguration durchaus Nachteile mit sich

• Bestimmte Server sind unerreichbar (Internethändler, Auktionshäuser, Mitbewerber)
• Nur Standdardports 80 und 443 sind erreichbar (primär Webradios bleiben aussen vor)

Eine Möglichkeit diese Restriktionen zu umgehen besteht darin, durch den vorgeschriebenen Proxyserver hindurch einen Netzwerktunnel nach draussen zu öffnen. Als Ausgang diese Tunnels dient ein (eigener) Rechner, der mittels eines eigenen Proxies Zugriff auf beliebige Webserver erlaubt.

Abb. 1: Zwangsproxy für Port 80 und 443 (click to enlarge)

Warum umständlich wenn es auch einfach geht?

Wer ein wenig mit Netzwerken vertraut ist kommt sofort auf die rettende Idee: Ein ssh-Tunnel durch den Proxy muss her! Dank putty ist ein solcher Tunnel nach draussen in kurzer Zeit zusammen geklickt.  Diese vermeintlich einfache Lösung hat jedoch einen gravierenden Nachteil: ein ssh-Tunnel ist für einen erfahrenen Netzwerker leicht nachweisbar. Mit wenig Aufwand kann zwischen einem Internetzugriff per ssh-Tunnel und einer echten https-Verbindung unterschieden werden. Dafur genügt ein Blick in das erste (!) Paket des Verbindungsaufbaus.

Abb. 2: Der Inhalt des ersten Paketes verrät seine Natur: ssh (click to enlarge)

Darum umständlich wenn es auch einfach geht!

Besser also, wenn statt eines ssh-Tunnels ein ssl-Tunnel verwendet wird. Dieser bietet eine ähnliche Funktionalität, ist mit einem Paketsniffer jedoch nicht von einer richtigenSSL-Verbindung zu unterscheiden.

Abb. 3: Ein eigener Proxy als offenes Tor zum WWW (click to enlarge)

Ein Programm das den Aufbau eines SSL-Tunnels erlaubt ist stunnel, das die meisten Distributionen in der Version 4 von Haus aus mitbringen. Unter Debian genügt ein Aufruf von apt-get zur Installation

dante:~# apt-get install stunnel4
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
  openssl
The following NEW packages will be installed:
  openssl stunnel4
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 1088kB of archives.
After unpacking 2548kB of additional disk space will be used.
Do you want to continue [Y/n]? Y
Get:1 http://security.debian.org etch/updates/main openssl 0.9.8c-4etch3 [1001kB]
Get:2 http://ftp.de.debian.org etch/main stunnel4 2:4.26-dfsg-1 [87.2kB]
Fetched 1088kB in 0s (1103kB/s)
Selecting previously deselected package openssl.
(Reading database ... 69897 files and directories currently installed.)
Unpacking openssl (from .../openssl_0.9.8c-4etch3_i386.deb) ...
Creating directory /etc/ssl
Selecting previously deselected package stunnel4.
Unpacking stunnel4 (from .../stunnel4_2%3a4.26-dfsg-1_i386.deb) ...
Setting up openssl (0.9.8c-4etch3) ...

Setting up stunnel4 (4.26-dfsg-1) ...

Listing. 1: Installation von stunnel unter Debian

Den Weg durch den Unternehmensproxy kann stunnel ebenfalls bahnen. Hierfür wird die Konfiguration entsprechend erweitert.

Auf der Serverseite, also der Seite auf dem auch der Proxyserver läuft, bekommt stunnel eine passende Konfigurationsdatei. Darin wird festgelegt, unter welchem Benutzer stunnel laufen soll. Zudem wird wird in der Sektion [BreakOut] der Port 443, also der üblicherweise für https genutzte Port, als Listenerport einer bestimmten IP-Adresse (hier der Name bei DynDNS.org) festgelegt sowie bestimmt, welcher Service angesprochen werden soll; hier ist ein lokal installierter squid auf Port 3128. Im Beispielscript ist der Hostname des Unternehmensproxy zwangsproxy.example.com, der eigene Proxyserver bekommt via DynDNS.org einen festen Hostnamen, im Beispiel myproxy.dyndns.org.

cert = /etc/stunnel/boulder.crt
key = /etc/stunnel/boulder.key
pid = /tmp/stunnel.pid
setuid = nobody
setgid = nogroup
output = /var/log/stunnel4.log
sslVersion = all
exec = /etc/stunnel/stest.sh
verify = 0

[BreakOut]
accept = myproxy.dyndns.org:443
connect = 127.0.0.1:3128

Listing 2: serverseitige stunnel-Konfigurationsdatei

Der Inhalt des ersten Paketes verrät seine Natur: ssh (click to enlarge) Die Konfiguration der Clientseite fällt etwas spartanischer aus, da der Client dem Server nicht zwingend ein Zertifikat vorweissen muss Der Loglevel ist auf das Maximum gestellt. Sobald alles funktioniert können Sie den Wert getrost auf 1 reduzieren.

setuid = stunnel4
setgid = stunnel4
pid = /tmp/stunnel4.pid
verify = 0
debug = 7
output = /var/log/stunnel4.log
client = yes

[BreakOut]
accept = 127.0.0.1:8080
connect = myproxy.dyndns.org:443

[BreakOut]
accept=localhost:8080
connect=zwangsploxy.example.com:3128
protocol=connect
protocolHost=myproxy.dyndns.org:443

Listing 3: clientseitige stunnel-Konfigurationsdatei

Programmstart

Serverseitig kann man den start von stunnel getrost den mitgelieferten Scripten überlassen. Auch auf der Clientseite

Inbetriebnahme

Sind auf beiden Seiten die Tunnel gestartet ist einzig der Browser so zu konfigurieren, dass nicht mehr der Unternehmensproxy angesprochen wird, sondern das lokale Ende der verschachtelten Tunnelkonstruktion: localhost auf Port xxxx.

Admin liest mit

Die Tatsache, dass solch ein Tunnel nicht auf Paketebene entdeckt werden kann bedeutet nicht, dass der Tunnel nicht mit statistischen Mitteln entdeckt werden kann:

Anzahl der Seitenaufrufe von diesem Server (vor allem im Verhältnis zu anderen Servern)

Anzahl der übertragenen Bytes (z.B. beim hören eines mp3-Streams)

Ist erst einmal die Aufmerksamkeit eines gewitzten Admins geweckt kommt dieser früher oder später auf die Idee zu schauen welcher Dienst auf diesem Rechner läuft. Ein simpler Test auf https://myproxy.dyndns.org bringt die Natur dieses Rechners an den Tag.

Abb. 5: Der gewitzte Admin prüft die Logs und verfolgt auffällige Verbindungen

Abb. 6: Zugriff mit dem Browser auf https://myproxy.dyndns.org (click to enlarge)

Ich sehe was das Du nicht siehst

Einen Ausweg weist eine Erweiterung der Konfiguration, die dem berechtigten Benutzer die Proxydienste bietet, während anderen ein gewöhnlicher Webserver vorgegaugelt wird. Möglich wird dies durch ein SSL-Zertifikat, das der Client dem Server vorweisen muss um zum Proxy zu dürfen. Zugriffe ohne oder mit dem falschen Zertifikat führen dazu, dass die Seiten eines lokalen oder entfernten Webservers ausgeliefert werden. Die Seite http://www.stunnel.org/examples/client_cert.html bietet eine gute Anleitung zur Erzeugung von Zertifikaten, wie sie von stunnel für diesen Zweck benötigt werden. Wer mag kann natürlich auch tinyCA nutzen! Letztlich ist nur wichtig, dass sowohl auf Server- als auch auf Clientseite in /etc/stunnel/ ein Zertifikat und eine Schlüsseldatei liegt. Ausserdem muss das Zertifikat der CA auf diesen Rechnern liegen, in den folgenden Beispielen /etc/ssl/certs/vbox4php.pem. Die Dateien stunnel.conf sind nun entsprechende Einträge zu erweitern. Ausserdem soll der Proxyserver zukünftig nur mit einem passenden Zertifikat angesprochen werden; diese Prüfung übernimmt das Script /etc/stunnel/stest.sh auf dem Server.

cert = /etc/stunnel/mars.crt
key = /etc/stunnel/mars.key

sslVersion = SSLv3
setuid = stunnel4
setgid = stunnel4
pid = /tmp/stunnel4.pid

verify = 0
debug = 7
output = /var/log/stunnel4.log
client = yes
[BreakOut]
accept = 127.0.0.1:8080
connect = 78.47.22.220:443

Listing 6: clientseitige stunnel-Konfigurationsdatei mit Zertifikaten

cert = /etc/stunnel/boulder.crt
key = /etc/stunnel/boulder.key
;chroot = /var/run/stunnel/
pid = /tmp/stunnel.pid
setuid = nobody
setgid = nogroup
output = /var/log/stunnel4.log
; Protocol version (all, SSLv2, SSLv3, TLSv1)
sslVersion = all
exec = /etc/stunnel/stest.sh
verify = 0
; Don't forget to c_rehash CApath
; CApath is located inside chroot jail
;CApath = /etc/ssl/certs
; It's often easier to use CAfile
;CAfile = /etc/ssl/certs/vbox4php.pem
; Don't forget to c_rehash CRLpath
; CRLpath is located inside chroot jail
;CRLpath = /crls
; Alternatively you can use CRLfile
;CRLfile = /etc/stunnel/crls.pem

[BreakOut]
accept = 78.47.22.220:443
;connect = 127.0.0.1:3128

Listing 7: serverseitige stunnel-Konfigurationsdatei mit Zertifikaten

Das Script /etc/stunnel/stest.sh prüft anhand der Umgebungsvariablen SSL_CLIENT_DN ob er als Webserver oder Proxyserver auftreten soll. Diese Variable wird von stunnel an das Script gereicht. Für den ersten Test was der eigene Client zum Server überträgt empfiehlt sich Blick in die Logdatei, nachdem ein erster Zugriff versucht wurde:

VERIFY IGNORE: depth=0, /C=DE/ST=Germany/L=Munich/O=vbox4php/OU=stunnel client/CN=mars.vbox4php.org/emailAddress=michael.renner@gmx.de
VERIFY OK: depth=0, /C=DE/ST=Germany/L=Munich/O=vbox4php/OU=stunnel client/CN=mars.vbox4php.org/emailAddress=michael.renner@gmx.de
VERIFY IGNORE: depth=0, /C=DE/ST=Germany/L=Munich/O=vbox4php/OU=stunnel client/CN=mars.vbox4php.org/emailAddress=michael.renner@gmx.de
VERIFY OK: depth=0, /C=DE/ST=Germany/L=Munich/O=vbox4php/OU=stunnel client/CN=mars.vbox4php.org/emailAddress=michael.renner@gmx.de
VERIFY IGNORE: depth=0, /C=DE/ST=Germany/L=Munich/O=vbox4php/OU=stunnel client/CN=mars.vbox4php.org/emailAddress=michael.renner@gmx.de
VERIFY OK: depth=0, /C=DE/ST=Germany/L=Munich/O=vbox4php/OU=stunnel client/CN=mars.vbox4php.org/emailAddress=michael.renner@gmx.de

Listing 8: Auszug aus der /var/log/stunne4.log

Nun kann das Script erstellt werden

#!/bin/sh                                                                                                                                                                                                     
if [ "${SSL_CLIENT_DN}" == "/C=DE/ST=Germany/L=Munich/O=vbox4php/OU=stunnel client/CN=mars.vbox4php.org/emailAddress=michael.renner@gmx.de" ]; then
   nc localhost 3128
   else
      #echo "this server is offline, please try again later"
      #nc www.example.org 80
      cat /etc/stunnel/404.html
fi

Listing 9: Das Script /etc/stunnel/stest/sh steuert das Verhalten

Security is not my Problem

Virtualisieren Rechner verwenden (VMware, Virtualbox)

Risiken und Nebenwirkungen

Unternehmen, die nach aussen hin nur einen begrenzten Zugriff erlauben, tun dies selten aus Spass an Schikanen. Sei es um Netzwerkbandbreite zu sparen, sicher zu stellen dass alle besuchten Webseiten unter herunter geladenen Dateien von einem zentralen Virenscanner untersucht werden oder schlicht um Angestellte vom Besuch von Webseiten abzuhalten, die mit Sicherheit nicht mit der beruflichen Tätigkeit zu tun haben. Wer die beschriebene Technik einsetzt, um sich am vorgeschriebenen Proxy vorbei Zugang zu verbotenen Webservern zu verschaffen verstösst sehr wahrscheinlich gegen Betriebsvereinbarungen oder andere verbindliche Absprachen zur Nutzung der Netzwerkinfrastruktur. Wird dieser Missbrauch ruchbar kann dies Auswirkungne auf das Arbeitsverhältnis haben. Schlimmer noch wird die Situation, wenn ein Virus, ein Trojaner, Wurm oder ein anderer der unzähligen Computerschädlinge auf diesem Weg einen Zugang zu den eigentlich geschützten Computern findet. Die Folgen mag sich jeder selbst ausmalen!