23.7 Proxyserver 

Filter sind Schutz

Proxyserver in einem Kapitel mit der Thematik »Firewalls«? Wer Proxys nur als Caches versteht, mag sich diese Frage vielleicht stellen. Im Allgemeinen kann man Proxys aber auch als Zugangsschutzsysteme verstehen, da sie viel mehr Möglichkeiten als nur das Caching bieten. Aber erst einmal zur Definition:

Ein Proxyserver (vom engl. proxy representative = Stellvertreter und lat. proximativ = angenähert) bezeichnet eine Software, die »zwischen« einem Server und einem Client postiert wird. Aus dieser Position heraus kann der Proxyserver – für den Client als Server und für den Server als Client – quasi transparent die Verbindung vermitteln.

Die Nomenklatur erklärt sich also durch den Fakt, dass ein Proxy meist »näher« am Client oder auch eben näher am Server ist. Mit dieser Architektur lassen sich Zugangsschutzsysteme – wir wollen mit Absicht nicht nur von Firewalls sprechen – durchaus sinnvoll erweitern, wie ein Blick auf die möglichen Funktionen eines solchen Servers zeigt.

23.7.1 Funktion 

Resultierend aus seiner Position wird ein Proxy natürlich immer irgendwie Daten weiterleiten, da ansonsten keine Kommunikation stattfinden würde. Hinzu kommt auch oft eine oder mehrere der folgenden Funktionen:

• Cache

• Im einfachsten Fall arbeitet der Proxy als Zwischenspeicher (Cache), um die Netzlast durch eben das Zwischenspeichern häufig gestellter Anfragen zu reduzieren.

• Filter

• Können Benutzer nur über einen Proxy zum Beispiel auf Webinhalte zugreifen, so kann man natürlich auch konfigurieren, welche Inhalte sie überhaupt zu sehen bekommen. Das kann recht praktisch sein, wenn zum Beispiel das Ebayen am Arbeitsplatz überhandnimmt. Aber ein Filter könnte in so einem Fall auch heruntergeladene Dateien auf Viren überprüfen, wäre also aus Sicht der Sicherheit gleich doppelt interessant.

• Zugriffskontrolle

• Steht ein Proxy »näher« beim Server als beim Client – mit anderen Worten, befindet er sich in der Infrastruktur des Dienstgebers --, kann er auch einen Server maskieren und so vor einem direkten Angriff schützen. Schließlich ist ein Proxy weniger komplex als der Server selbst.

• An dieser Stelle sollte man sich noch einmal den Unterschied zwischen diesem Konzept und der bereits erläuterten Network Address Translation verdeutlichen, bei der der entsprechende Traffic einfach nur weitergeleitet und nicht »getunnelt« wird.

• Vorverarbeitung

• Natürlich können Proxys auch auf den von ihnen vermittelten Daten operieren und so zum Beispiel eine Konvertierung oder eine anderweitige Vorverarbeitung vornehmen.

• Anonymisierung

• Da laut unserer Definition ein Proxy für beide Kommunikationspartner transparent ist, kann ein externer Proxy auch als Anonymisierungsdienst genutzt werden. Schließlich greift der Client dann nicht mehr direkt auf den Server zu, sondern der Server loggt die IP-Adresse des Proxys, der ja den Zugriff für den Client erledigt.

Protokolle

Bisher ist für uns ein Proxy nur ein abstraktes Konzept für eine Netzwerkkommunikation, selbst wenn wir schon auf das Haupteinsatzgebiet als HTTP-Proxy für Webseiten hingewiesen haben. Prinzipiell allerdings können Proxys für jedes TCP-basierte – also verbindungsorientierte – Protokoll eingesetzt werden.

• HTTP

• Privatanwender können oft Proxys ihrer Provider nutzen, die häufig aufgerufene Seiten cachen und somit, wie bereits angedeutet, den Zugriff beschleunigen. In Firmen dagegen werden Proxyserver oft zur Kontrolle und Einschränkung der Mitarbeiter eingesetzt. Die optimalere Nutzung der vorhandenen Bandbreite ist da oft nur ein positiver Nebeneffekt.

• FTP

• Die meisten HTTP-Proxyserver können auch als FTP-Proxy fungieren und so den Benutzern auch das Herunterladen von Dateien ermöglichen, die auf entsprechenden Servern abgelegt sind.

• SMTP

• Durch das Design des Simple Mail Transfer Protocols kann jeder SMTP-Server auch SMTP-Proxy sein. Das ist vor allem dann nützlich, wenn man unabhängig von der bereits existierenden Mail-Infrastruktur noch einen Filter gegen Spam, Viren und Trojaner aufsetzen will.

23.7.2 Einsatz 

Die nächste Frage ist natürlich, wie man einen Proxy einsetzen kann. Schaut man sich einen HTTP-Proxy in einer typischen Umgebung an, sieht man, dass oft die Clients – also die Webbrowser – erst entsprechend konfiguriert werden müssen, um den Proxy zu nutzen. Aber es geht auch eleganter:

• Transparenter Proxy

• Für einen transparenten Proxy macht man sich meist NAT zunutze, indem man zum Beispiel auf dem Gateway alle an Port 80 adressierten Pakete an den Proxy selbst weiterleitet. In diesem Fall muss weder am Client noch erst recht nicht am Server manipuliert werden, und der Proxy ist nicht nur in seiner Funktion, sondern auch als Zugangsschutzsystem an sich transparent.

• Aufgrund des benötigten NAT werden transparente Proxys meist nur in Firmennetzwerken ab einer gewissen »Grundkomplexität« eingesetzt, da für einfachere Strukturen andere Lösungen leichter umzusetzen sind.

• Reverse Proxy

• Ein reverse Proxy ist ein Proxyserver, der statt dem eigentlichen Server in Erscheinung tritt. So kann ein Webserver beispielsweise Content eines anderen Servers anbieten, oder es können im einfachsten Fall schlicht Caches realisiert werden.

Spätestens die Anwendungsmöglichkeit als transparenter Proxy hat deutlich gemacht, wieso Proxys in ein Kapitel über Zugangsschutz und Zugangskontrolle gehören. Während Firewalls nämlich nur den Zugriff auf TCP/IP-Ebene kontrollieren, kann man über Proxys in beschränktem Umfang den Inhalt des erlaubten Traffics überwachen und auch einschränken – und zwar ohne Konfigurationsaufwand bei den Clients.

23.7.3 Beispiel: Squid unter Linux 

Im Folgenden wollen wir kurz und exemplarisch die Konfiguration des Squid-Proxyservers unter Linux betrachten. Squid (www.squid-cache.org) ist Open Source, steht also als Quellcode und Binary frei im Netz und ist ohne Lizenzkosten für jeden verfügbar.

Features

Als der am meisten im Unix/Linux-Umfeld genutzte Proxyserver bringt Squid natürlich eine Reihe wichtiger und interessanter Features mit:

• Proxy- & Cachefunktion für verschiedene Protokolle wie HTTP und FTP

• SSL-Support (»https«)

• Cachehierarchien

• ICP, HTCP, CARP, Cache Digests

• transparentes Caching

• ab Squid 2.3 WCCP

• gut konfigurierbare Zugriffskontrollen

• HTTP-Beschleunigung

• SNMP

• DNS-Caching

Eigentlich sind in jeder wichtigen Linux-Distribution Squid-Binaries bereits vorinstalliert oder werden entsprechende Pakete bereitgestellt. Sollten Sie jedoch die Software von Hand von www.squid-cache.org herunterladen und installieren wollen, können Sie auch die folgende Installationsanleitung nutzen, die für jede autoconf/automake-basierte Software gilt.

Installation

Zuerst muss man wie gesagt die Datei squid-*-src.tar.gz in der neuesten Version von www.squid-cache.org herunterladen und danach entpacken:

# tar -xvzf squid-*-src.tar.gz 
# cd squid -*

Listing 23.2    Entpacken der Software

Konfigurieren und übersetzen

Um den Quellcode für das eigene System zu konfigurieren, die Sourcen zu übersetzen und schließlich die kompilierten Binaries an die richtigen Stellen im System zu verschieben, benötigen Sie die folgenden drei Kommandos:

# ./configure 
# make 
# make install

Listing 23.3    Die Sourcen übersetzen

Bei der gesamten Installationsprozedur benötigen Sie nur für den letzten Schritt root-Rechte, da hier standardmäßig auf das Systemverzeichnis /usr/local – Squid wird per Default unter /usr/local/squid installiert – zugegriffen werden muss.

Sollen Übersetzungs- beziehungsweise Installationsoptionen geändert werden, so kann mit ./configure --help eine Liste aller möglichen Konfigurationsoptionen zur Übersetzungszeit ausgegeben werden.

Über diese Optionen könnten Sie auch den Installationspfad ändern, was aber nur in den wenigsten Ausnahmefällen sinnvoll ist. Schließlich gibt es eine wohldefinierte und durchdachte Ordnung, welche Verzeichnisse für welche Dateien bestimmt sind – und anstatt in /etc, /var oder /usr/bin (wie die vom Paketmanagement der Distribution verwaltete Software) gehört Selbstübersetztes eigentlich in ein Verzeichnis unterhalb von /usr/local.

Die eigentliche Konfiguration

Während man bei ./configure nur mit den Installationsoptionen in Berührung kommt, enthält die Datei /usr/local/squid/etc/squid.conf – beziehungsweise /etc/squid.conf oder /etc/squid/squid.conf nach der paketbasierten Installation über ihre Distribution – die eigentliche Konfiguration zum Betrieb des Proxyservers.

Die Optionen in dieser Datei sollen im Folgenden nur so weit behandelt werden, wie es für eine lauffähige Konfiguration nötig ist.

• cache_dir

• In diesem Verzeichnis wird der Cache abgelegt, es sollte also genügend Plattenplatz vorhanden sein.

• cache_effective_user & cache_effective_group

• Unter diesen Rechten wird das Cacheverzeichnis auf der Platte genutzt.

• http_port

• Der Port, auf dem der Dienst hören soll – standardmäßig 3128.

• http_access

Zugriff erlauben

• Nach der Installation ist der Squid meist so konfiguriert, dass niemand auf ihn zugreifen kann. Das macht Sinn, da so die Software nach der Installation und vor der Konfiguration kaum anfällig für Angreifer ist. Eine minimale Konfiguration, die nur dem Proxyserver selbst Zugriff auf den Dienst erlaubt, könnte zum Beispiel so aussehen:

# Only allow cachemgr access from localhost 
http_access allow manager localhost 
http_access deny manager 
 
# Only allow purge requests from localhost 
http_access allow purge localhost 
http_access deny purge 
 
# Deny requests to unknown ports 
http_access deny !Safe_ports 
 
# Deny CONNECT to other than SSL ports 
http_access deny CONNECT !SSL_ports 
# 
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS 
# FROM YOUR CLIENTS 
# 
http_access allow localhost 
# And finally deny all other access to this proxy 
http_access deny all

Listing 23.4    Minimale Zugriffsrechte für Squid

• Wofür die einzelnen Identifier stehen, kann man mit folgender Deklaration klären:

acl all src 0.0.0.0/0.0.0.0 
acl manager proto cache_object 
acl localhost src 127.0.0.1/255.255.255.255 
acl SSL_ports port 443 563 
acl Safe_ports port 80          # http 
acl Safe_ports port 21          # ftp 
acl Safe_ports port 443 563     # https, snews 
acl Safe_ports port 70          # gopher 
acl Safe_ports port 210         # wais 
acl Safe_ports port 1025-65535  # unregistered 
                                # ports 
acl Safe_ports port 280         # http-mgmt 
acl Safe_ports port 488         # gss-http 
acl Safe_ports port 591         # filemaker 
acl Safe_ports port 631         # cups 
acl Safe_ports port 777         # multiling http 
acl Safe_ports port 901         # SWAT 
acl purge method PURGE 
acl CONNECT method CONNECT

Listing 23.5    Sichere Ports etc. definieren

• Wie Sie sehen, sind diese Deklarationen sehr einfach gehalten. Port-Bereiche von Port A bis Port B werden durch A-B angegeben.

Nach diesem lauffähigen, aber doch sehr einfachen Beispiel möchten wir im Folgenden die Konfiguration von Squid als transparentem Proxy wiederum exemplarisch durchspielen.

Warum »nur« exemplarisch? Immerhin lesen Sie gerade ein Sicherheitsbuch, da wäre es fatal, einem einfachen, nur einen Sachverhalt illustrierenden Beispiel gleich den Status einer komplexen »Lösung« geben zu wollen. Wenn Sie detaillierte Informationen für Ihre spezifische Konfiguration für Squid suchen, sollten Sie wissen, dass Sie zum Beispiel auf der Homepage des Projektes fündig werden können.

Squid als transparenter Proxy

NAT nutzen

Diese Konfiguration benötigt natürlich insgesamt zwei Schritte: Zuerst muss Squid so konfiguriert werden, dass es auch mit normalen, nicht extra auf Proxys zugeschnittenen Requests <Speziell für Proxys generierte Requests werden von Browsern benutzt, bei denen man einen Proxy per Hand eingestellt hat. In unserem Fall jedoch soll diese explizite Konfiguration durch den Einsatz eines transparenten Proxys vermieden werden, daher muss Squid mit normalen HTTP-Requests umgehen können.> umgehen kann.

Diese Optionen sind in wenigen Zeilen zusammengefasst:

httpd_accel_host virtual 
httpd_accel_port 80 
httpd_accel_with_proxy on 
httpd_accel_uses_host_header on

Listing 23.6    squid.conf: Konfiguration als transparenter Proxy

Als Nächstes muss natürlich der für das Web bestimmte Traffic zum Squid umgeleitet werden, was meistens durch einfaches NAT erfolgt. Wie dies nun genau auszusehen hat, hängt von Ihrer Firewall ab. Im Prinzip muss aber nur jeglicher aus dem internen Netz kommender, auf Port 80 adressierter Traffic auf den Squid-Rechner umgeleitet werden – der natürlich ohne diese Umleitung Zugriff auf das Netz braucht.

Squid starten

Wenn man Squid zum ersten Mal startet, muss zuerst die Cachestruktur im angegebenen Verzeichnis angelegt werden. Viele von den Distributionen mitgelieferte Startskripts machen dies automatisch; bei einer manuellen Installation muss man dies aber noch per Hand durch das Starten von Squid mit der Option »-z« erledigen:

/usr/local/squid/bin/squid -z

Listing 23.7    Cache anlegen

Nach dem Abschluss dieser Aktion kann man Squid mit den Optionen »-NCd1« im Debugmodus starten, und die Meldung »Ready to serve requests« sollte signalisieren, dass die Software korrekt konfiguriert wurde. Startet man Squid nun ohne Optionen, läuft der Server ganz normal als Daemonprozess im Hintergrund.

Über die Datei cache.log im log-Verzeichnis kann man dann eventuelle Laufzeitfehler oder andere Nachrichten überwachen.

Ihr Kommentar