32.7 Proxyserver

Filter bieten Schutz

Was haben Proxyserver in einem Kapitel zur Sicherheit zu suchen? 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. Betrachten wir zunächst die Definition eines Proxyservers:

Ein Proxyserver (abgeleitet vom englischen proxy representative = Stellvertreter, und vom Lateinischen proximus = sehr nah) 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 – die Verbindung transparent 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.

32.7.1 Funktion

Resultierend aus seiner Position wird ein Proxy Daten in irgendeiner Form weiterleiten, da sonst keine Kommunikation stattfinden würde. Zu dieser Aufgabe kommt auch oft eine oder mehrere der folgenden Funktionen:

• Cache
  Im einfachsten Fall arbeitet der Proxy als Zwischenspeicher (Cache), um die Netzlast durch das Zwischenspeichern häufig gestellter Anfragen zu reduzieren.
• Filter
  Können Benutzer etwa auf Webinhalte nur über einen Proxy zugreifen, so kann man natürlich auch konfigurieren, welche Inhalte sie überhaupt zu sehen bekommen. Eine solche Filterung kann recht praktisch sein, wenn zum Beispiel das »eBayen« am Arbeitsplatz überhandnimmt.

Ein Filter könnte auch heruntergeladene Dateien auf Viren überprüfen, ist also aus Sicherheitsaspekten gleich doppelt interessant.

• Zugriffskontrolle
  Steht ein Proxy »näher« beim Server als beim Client – befindet er sich vielleicht sogar in der Infrastruktur des Dienstgebers --, so 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 dem Proxy 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. Der Client greift 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 der Netzwerkkommunikation, wenngleich wir schon auf das Haupteinsatzgebiet als HTTP-Proxy für Webseiten hingewiesen haben. Prinzipiell können Proxys allerdings 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 angemerkt, den Zugriff beschleunigen. In Firmen dagegen werden Proxyserver oft zur Kontrolle und Einschränkung der Mitarbeiter eingesetzt. Die optimale 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 das Herunterladen von Dateien ermöglichen, die auf entsprechenden Servern abgelegt sind.
• SMTP
  Durch das Design des Simple Mail Transfer Protocol kann jeder SMTP-Server auch SMTP-Proxy sein. Dies 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.

32.7.2 Einsatz

Betrachten wir im Folgenden, wie man einen Proxy einsetzen kann. Schaut man sich einen HTTP-Proxy in einer typischen Umgebung an, so 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 am Server manipuliert werden. Der Proxy ist somit 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 anstelle des eigentlichen Servers 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.

32.7.3 Beispiel: Squid unter Linux

Im Folgenden wollen wir kurz und exemplarisch die Konfiguration des Proxyservers Squid 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 im Unix-/Linux-Umfeld meistgenutzte Proxyserver bringt Squid eine Reihe wichtiger und interessanter Features mit:

• Proxy- und Cache-Funktion für verschiedene Protokolle wie HTTP und FTP
• SSL-Support (HTTPS)
• Cache-Hierarchien
• ICP, HTCP, CARP, Cache Digests
• transparentes Caching
• ab Squid 2.3: WCCP (Web Cache Coordination Protocol)
• gut konfigurierbare Zugriffskontrollen
• HTTP-Beschleunigung
• SNMP (Simple Network Management Protocol)
• DNS-Caching

Eigentlich sind in jeder wichtigen Linux-Distribution Squid-Binaries bereits vorinstalliert oder entsprechende Pakete werden 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 Autotools-basierte Software gilt.

Installation

Zuerst laden Sie die Datei squid-*-src.tar.gz in der neuesten Version von www.squid-cache.org herunter und entpacken sie:

Listing 32.2 Entpacken der Software

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

Konfigurieren und übersetzen

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

Listing 32.3 Die Sourcen übersetzen

# ./configure
# make
# make install

Bei der gesamten Installationsprozedur benötigen Sie nur für den letzten Schritt root-Rechte, da hier 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 können Sie mit ./configure --help eine Liste aller möglichen Konfigurationsoptionen zur Übersetzungszeit ausgeben lassen.

Darüber könnten Sie auch den Installationspfad ändern, was aber nur selten 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 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 und cache_effective_group
  Unter diesen Rechten wird das Cache-Verzeichnis auf der Platte genutzt.
• http_port
  Der Port, auf dem der Dienst laufen soll – standardmäßig ist dies der Port 3128.

Zugriff erlauben

• http_access
  Nach der Installation ist der Squid meist so konfiguriert, dass niemand auf ihn zugreifen kann. Dies ist sinnvoll, 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:

Listing 32.4 Minimale Zugriffsrechte für Squid

# 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

Wofür die einzelnen Bezeichner stehen, können Sie mit folgender Deklaration klären:

Listing 32.5 Sichere Ports definieren

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

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

Nach diesem einfachen, aber lauffähigen Beispiel möchten wir im Folgenden die Konfiguration von Squid als transparentem Proxy wiederum exemplarisch durchspielen. Warum »nur« exemplarisch? Immerhin lesen Sie gerade ein Sicherheitskapitel, 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 zum Beispiel auf der Homepage des Projekts fündig werden.

Squid als transparenter Proxy

NAT nutzen

Die Konfiguration von Squid als transparenter Proxy erfordert zwei Schritte: Zuerst muss Squid so konfiguriert werden, dass er auch mit normalen Requests umgehen kann, die nicht eigens auf Proxys zugeschnitten sind. [Fn. 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.]

Diese Optionen sind in wenigen Zeilen zusammengefasst:

Listing 32.6 squid.conf: Konfiguration als transparenter Proxy

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

Als Nächstes muss der für das Web bestimmte Traffic zum Squid umgeleitet werden, was in der Regel durch einfaches NAT erfolgt. Wie diese Umleitung 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 Zugriff auf das Netz ohne diese Umleitung braucht.

Squid starten

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

Listing 32.7 Cache anlegen

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

Nach dem Abschluss dieser Aktion kann man Squid mit den Optionen -NCd1 im Debug-Modus starten. 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 Dämonprozess im Hintergrund. über die Datei cache.log im log-Verzeichnis kann man dann eventuelle Laufzeitfehler oder andere Nachrichten überwachen.

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.