Installation eines Reverse Proxy mit Squid 3.3 unter Ubuntu zur Absicherung eines Exchange Server 2013

Wir setzen in unserer eigenen Umgebung einen Exchange Server 2013 ein, über den wir unsere zentrale Kommunikation verwalten. Dieses System ist natürlich auch per Internet erreichbar, um unseren Endgeräten oder den mobilen Geräten unterwegs die Möglichkeit zu bieten, in Kontakt zu bleiben. Eine Möglichkeit, dies zu realisieren, wäre die Anbindung des Exchange Server direkt über eine Firewall und der Freigabe von HTTPS. Um den direkten Server nicht direkt in Richtung Internet stellen zu müssen, betreiben wir seit einiger Zeit einen sogenannten Reverse-Proxy. Dieses System ist ein Server, der mit einem Interface Richtung Internet angebunden ist und mit einem zweiten Interface eine Verbindung auf die interne IP-Adresse des Exchange Server aufbauen kann. Bisher lief dieses System unter OpenSuse und Squid in der Version 2.x, dies wollte ich ändern. Wir nutzen mittlerweile fast ausschließlich Ubuntu, wenn wir denn auf ein Linux-System setzen (müssen/wollen). In diesem Beitrag zeige ich, wie die Einrichtung unter Ubuntu in der Version 14.04 (inkl. LTS) funktioniert.

Wir beginnen mit der Installation des Grundsystem, in unserem Fall als VM unter Hyper-V. Die VM braucht recht wenig Ressourcen, da nicht allzu viele Personen eine Verbindung zu dem System aufbauen. Wichtig ist, dass die VM zwei Netzwerkkarten besitzt und diese am besten direkt mit zwei festen MAC-Adressen versehen werden. Dies bewirkt, dass nachträglich keine Anpassungen mehr vorgenommen werden müssen, falls sich die MAC-Adressen einmal ändern.

Nach der Grundinstallation werden die beiden Interfaces mit festen IP-Adressen versehen. Ich nutze auf eth0 eine IP-Adresse aus unserer DMZ (172.16.1.1), eth1 bekommt eine IP-Adresse in unserem internen Netzwerk (192.168.100.3). Sieht dann in etwa so aus:

Nun kommt der erste Knackpunkt: Eine normale Squid-Installation unter Ubuntu unterstützt leider kein SSL. Daher gibt es nun verschiedene Möglichkeiten: Wir kompilieren uns eine eigene Version, in der SSL enthalten ist. Dies hat den Nachteil, das jedes Update per apt die kompilierte Version und somit auch unsere Einstellungen im schlimmsten Fall überschreibt bzw. kaputt macht. Die zweite Möglichkeit wäre die Nutzung einer anderen Distribution, bei dem im Squid direkt SSL enthalten ist. Da kommen wir her, somit entfällt diese Möglichkeit ebenfalls. Eine dritte Möglichkeit ist die, für die ich mich auch entschieden habe: Ich spiele in die Quellen von apt eine neue Source hinzu, bei der bereits kompilierte Pakete liegen und ich diese direkt benutzen kann. Ursprünglich bin ich über den folgenden Beitrag gestolpert:

mydlp.com: Now squid3-ssl packages in MyDLP repository

Problem bei dieser Variante: Meine aktuelle genutzte Version wird nicht mehr aufgeführt, die Installation kann leider nicht durchgeführt werden (oder ich war dazu nicht in der Lage). Nach einer weiteren Suche zu Paketen für meine Version 14.04 bin ich recht schnell zu folgender Seite gekommen:

launchpad.net: “Brightbox” team – Squid with SSL support

Der Vorgang ist recht einfach. Zuerst müssen wir mit dem Befehl

sudo add-apt-repository ppa:brightbox/squid-ssl

die Quellen sowie den Schlüssel zu unserem System hinzufügen. Nachdem dies geschehen ist müssen die Paketlisten mit einem

apt-get update

aktualisiert werden. Wenn als dies ohne Probleme durchläuft können wir nun mit einem

sudo apt-get install squid3-ssl

den benötigten Squid installieren. Die Installation erfolgt in das Verzeichnis

/etc/squid3

dort sind ebenfalls die Dateien der Installation zu finden. Ich habe in meinem Fall die Standard squid.conf umbenannt

sudo mv /etc/squid/squid.conf /etc/squid/squid.conf.default

und eine neue Datei angelegt, in der ausschließlich meine gewünschte Konfiguration enthalten ist. Die Datei kann einfach mit einem

sudo vi /etc/squid3/squid.conf

angelegt werden. Der Inhalt der Datei sieht wie folgt aus:

# Hostname
visible_hostname server.domain.de
# Externer Zugriff
https_port 172.16.1.1:443 accel cert=/etc/squid3/ssl/externes_zertifikat_encrypted.crt key=/etc/squid3/ssl/externes_zertifikat_decrypted.key defaultsite=server.domain.de
# Interner Server
cache_peer 192.168.100.2 parent 443 0 no-query originserver login=PASS ssl sslflags=DONT_VERIFY_PEER sslcert=/etc/squid3/ssl/internes_zertifikat_encrypted.crt sslkey=/etc/squid3/ssl/internes_zertifikat_decrypted.key name=ExchangeServer
# Zugriff auf folgende Adressen ist erlaubt
acl EXCH url_regex -i ^https://server.domain.de/owa.*$
acl EXCH url_regex -i ^https://server.domain.de/Microsoft-Server-ActiveSync.*$
acl EXCH url_regex -i ^https://server.domain.de/ews.*$
acl EXCH url_regex -i ^https://server.domain.de/autodiscover.*$
acl EXCH url_regex -i ^https://server.domain.de/rpc/.*$
# Regeln
cache_peer_access ExchangeServer allow EXCH
never_direct allow EXCH
http_access allow EXCH
http_access deny all
miss_access allow EXCH
miss_access deny all
# Logging
access_log /var/log/squid3/access.log squid

Vorlage für diese Datei war der folgende Beitrag auf administrator.de: http://www.administrator.de/wissen/squid-2-x-als-reverse-proxy-f%C3%BCr-exchange-2010-192704.html

Ich musste allerdings ein paar Dinge anpassen, da die Konfiguration von Squid 2 nicht mehr lauffähig ist mit der Konfiguration von Squid 3. Primär war dies die Entfernung der extension_methods und das Entfernen von acl all src all, da dies scheinbar standardmäßig nun enthalten ist.

Die benötigten Zertifikate werden im Verzeichnis /etc/squid3/ssl/ abgelegt. Grundsätzlich werden zwei verschiedene Zertifikate benötigt:

• Externer Zugriff: Dieses Zertifikat wird von dem Browser/Endgerät direkt angesprochen, der Name im Zertifikat wird z.B. bei einer OWA-Sitzung direkt aufgerufen. Hierbei sollte es sich um ein offizielles Zertifikat handeln, z.B. von GoDaddy. Eine Anleitung, wie diese Art von Zertifikat beantragt werden kann, finden Sie hier: Technikblog: Exchange 2010 mit offiziellem SAN Zertifikat betreiben
• Interner Zugriff: Dieses Zertifikat wird auf dem Exchange Server eingezogen und dient zur Kommunikation zwischen dem ReverseProxy und dem Exchange Server.

Ein Tipp meinerseits: Beantragen Sie ein SAN-Zertifikat mit fünf oder mehr Namen und tragen Sie sowohl die Adresse(n) des Exchange Server als auch des ReverseProxy ein. Dies erleichtert die Handhabung, und Sie müssen sich nur mit einem Zertifikat beschäftigen.

Die Erstellung der Zertifikate für die squid.conf-Datei läuft wie folgt ab:

• Erstellen Sie ein Zertifikat für den ReverseProxy. In meinem Fall ist dies das bereits angesprochene Zertifikat von GoDaddy.
• Exportieren Sie das Zertifikat inkl. dem privaten Schlüssel und legen Sie die Datei auf dem ReverseProxy ab. Die Umwandlung kann natürlich auch auf einem anderen System erfolgen, ich führe dies aber direkt auf dem Ubuntu-System aus.
• Entpacken Sie das Zertifikat in insgesamt zwei Dateien:

openssl pkcs12 -in GoDaddy_Zertifikat.pfx -nocerts -out externes_zertifikat_encrypted.key

openssl pkcs12 -in GoDaddy_Zertifikat.pfx -clcerts -nokeys -out externes_zertifikat_encrypted.crt

Quelle: markbrilman.nl: Howto convert a PFX to a seperate .key/.crt file

In dem Verzeichnis, in dem wir die Konvertierung ausgeführt haben, liegen nun insgesamt drei Dateien:

• GoDaddy_Zertifikat.pfx: Das von GoDaddy exportierte Zertifikat inkl. dem privaten Schlüssel
• externes_zertifikat_encrypted.key: Der Schlüssel, extrahiert aus der .pfx-Datei. Diese Datei wird in der Squid-Konfiguration benötigt, zur Erstellung müssen Sie das Kennwort der .pfx-Datei angeben.
• externes_zertifikat_encrypted.crt: Das externe Zertifikat. Diese Datei wird in der Konfiguration  genutzt und dem Client präsentiert. Zur Erstellung muss ebenfalls das Kennwort der .pfx-Datei angegeben werden.

Wenn Sie die Umwandlung abgeschlossen haben sollten Sie die .pfx-Datei wieder von dem System entfernen, allerdings nicht vollständig löschen. Sie sollte nur nicht mehr auf dem Server liegen, der als ReverseProxy genutzt wird.

Nun muss dieser Vorgang erneut für das Zertifikat des Exchange Server gemacht werden. In meinem Fall kann ich das gleiche Zertifikat verwenden, da der Name des Exchange Server ebenfalls enthalten ist. Es ändern sich hier nur die Namen der Dateien, da ich nicht probiert habe ob ich auf die gleichen Dateien zugreifen kann.

openssl pkcs12 -in GoDaddy_Zertifikat.pfx -nocerts -out internes_zertifikat_decrypted.key

openssl pkcs12 -in GoDaddy_Zertifikat.pfx -clcerts -nokeys -out internes_zertifikat_encrypted.crt

Die beiden Dateien können nun ebenfalls in der Konfiguration genutzt werden.

Interessant ist in unserem Fall mit der aktuellen Version von Ubuntu und Squid, dass sich unter /etc/init.d/ keine Datei mehr befindet, mit der sich der Dienst starten oder stoppen lässt. Dies hat sich geändert, der Dienst kann nun über

sudo service squid3 start

gestartet werden (http://askubuntu.com/questions/433803/missing-squid-in-etc-init-d). Weitere Möglichkeiten sind natürlich auch stop, restart oder status. Ganz wichtig ist hierbei, ein sudo vorweg zu schreiben. Selbst wenn man sich vorher per sudo su höhere Rechte vergeben hat, eine Ausführung ohne sudo erwirkt keine Änderung des Zustands. Ich habe ein paar Minuten gebraucht, das zu merken :)

Wenn nun keine Fehler mehr vorhanden sind und das System frei mit dem Internet kommunizieren kann (über HTTPS) sowie intern eine Verbindung zum Exchange Server aufbauen kann sollte einer Nutzung des Systems eigentlich nichts mehr im Wege stehen. Sie sehen in der Logdatei unter /var/log/squid3/ zusätzlich, ob Probleme auftauchen.