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

WinServ2012-KernelWir 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:

image

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

image

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

apt-get update

image

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

sudo apt-get install squid3-ssl

image

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

image

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.

Teilen:

Jan Kappen

Jan Kappen ist ausgebildeter Fachinformatiker in der Richtung Systemintegration. Er hat seine Ausbildung im Sommer 2008 abgeschlossen und arbeitet seitdem bei der Rachfahl IT-Solutions GmbH & Co. KG. Jan Kappen ist unter anderen MCITP Server Administrator, Enterprise Administrator und Enterprise Messaging Administrator 2010 sowie MCTS für System Center Virtual Machine Manager 2008, Windows Server 2008 Active Directory, Windows Server Virtualization und Windows Server 2008 Network Infrastructure. Im April 2015 wurde Jan Kappen im Bereich "File System Storage" für seine Expertise und seine Community-Arbeit mit dem MVP Award von Microsoft ausgezeichnet.

6 Kommentare:

  1. Hallo Jan,

    sehr schönes und gutes Tutorial!! So etwas habe ich gesucht :-)
    Ich wollte kurz fragen – da ich das erst in einer virtuellen Umgebung mal testen will – ob das Ganze auch mit dem selbstsignierten Exchange 2013 Zertifikat laufen kann (extern und intern dann in der conf auf das gleiche zert?) welches bei der Exchange Installation automatisch erstellt wird, oder ob man zwingend ein offizielles Zertifikat benötigt?

    Vielen Dank!
    Grüße,
    Steran

  2. Hi,
    grundsätzlich ist es egal was für ein Zertifikat du nimmst, solange Name und Gültigkeit passen. LEtztendlich ja alle Zertifikate selbstsigniert, bei manchen ist die CA im Browser schon bekannt, bei anderen nicht. Ob das komplett eigene geht weiß ich nicht, ich würde mir wenn dann eins über eine eigene Windows-CA erstellen.
    Gruß, Jan

  3. Vielen Dank! Der Test hat auch mit dem selbstsignierten Zertifikat geklappt.

    Musste nur den privaten Schlüssel mit openssl rsa zusätzlich zu Deiner Anweisung erzeugen:
    openssl pkcs12 -in cert.pfx -nocerts -out decrypted.key
    openssl rsa -in decrypted.key -out cert.key

    Habe nun aber ein offizielles Zertifikat für den produktiven Einsatz.

    Jedoch ist mir aufgefallen, dass in der squid access.log oftmals Einträge mit tcp_miss_aborted/000 auftreten.

    Haben den Server in einer virtuellen Hyper-V Maschine laufen.

    Grüße,
    Steran

  4. Thomas Dittrich

    Hallo,

    welche Anpassungen sind für Ubuntu 14.10 notwendig??
    Bei mir funktioniert der Download nicht.

    Gruß
    T. Dittrich

  5. Hallo Jan,

    wir möchten auch Squid als Reverse Proxy einsetzen und sind auf diesen Beitrag gestoßen. Du hattest geschrieben:
    “Bisher lief dieses System unter OpenSuse und Squid in der Version 2.x, dies wollte ich ändern.” und “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.” Daraus haben wir geschlossen, das in OpenSuse direkt ein Squid SSL Paket enthalten ist. Da dies für uns die einfachste Möglichkeit war, haben wir OpenSuse installiert und sind dann weiter nach Deiner Anleitung zur Konfiguration von Squid vorgegangen. Leider bekommen wir immer einen Zertifikatsfehler:

    Sep 14 09:48:58 linux-p7fr squid[8736]: No valid signing SSL certificate configured for HTTPS_port 192.168.26.2:443
    Sep 14 09:48:58 linux-p7fr sh[8730]: FATAL: No valid signing SSL certificate configured for HTTPS_port 192.168.26.2:443

    Mit der Abfrage “squid -v” sollte für Squid mit SSL Suppport folgendes zu finden sein: “–enable-ssl‘ ‚–with-open-ssl=/etc/ssl/openssl.cnf‘” .
    Dies ist bei uns nicht der Fall. Liegen wir richtig, das in OpenSuse das Squid-Paket mit SSL installiert wird?

    Viele Grüße aus Berlin,
    Christian

  6. Hallo,
    ich habe länger keine Installation mehr von Squid durchgeführt, daher bin ich leider nicht mehr im Thema. Das Thema ist schon einige Jahre alt, ich weiß nicht wie der aktuelle Stand im Squid und in den aktuellen Distributionen ist.
    Gruß, Jan

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.