Workshop SLOS (Teil 5): Proxy-Server einrichten

11.09.2003 von Konstantin Peter Pfliegl
Der SuSE Linux Office Server bringt in einer Box alles mit, was ein zentraler Unternehmensrechner in kleinen Firmen bieten muss. Dieser Teil des Workshops führt Sie durch die Konfiguration des Proxy-Servers Squid.

Mit dem SuSE Linux Office Server (alias SLOS) offeriert SuSE eine kompakte, umfassend ausgestattete und auch für Linux-Einsteiger handhabbare Server-Komplettlösung für kleine Netze. Dabei bedient der SLOS nicht nur die Linux-Klientel, sondern kommt auch mit Windows-Arbeitsplätzen bestens zurecht.

Der Workshop ist ein Auszug aus unserem tecCHANNEL-Compact "Linux-Server Komplettpaket", das ab 11. Juli 2003 im Handel ist. Dort finden Sie den kompletten Workshop, zusätzliche Beiträge und die Software-CD mit dem SuSE Linux Office-Server. Bei Direktbestellung unter www.tecChannel.de/shop erhalten Sie die Compact-Ausgabe mit CD für nur 8,90 Euro inklusive Versandkosten komfortabel mit der Post.

Der SLOS brilliert nicht nur als File-/Printserver und NT-Server-Ersatz für Windows-Maschinen. Er betätigt sich zudem auch als Internet-Gateway für die Clients, als Firewall für das lokale Netz sowie als Proxy- und Intranet-Server. Mit etwas händischer Nacharbeit erledigt er daneben auch die elektronische Post.

Umfassende Einrichtungs-Assistenten und ein ausführliches Handbuch machen die Einrichtung des SLOS für den Linux-Kenner zum Kinderspiel. Für den weniger mit dem Open-Source-OS vertrauten Anwender bleiben trotzdem an vielen Stellen noch Fragen offen. Die soll unser ausführlicher SLOS-Workshop beseitigen. Zudem bietet er Tipps, Tricks und Ergänzungen zu Funktionen und Einsatzgebieten, die die SLOS-Dokumentation auslässt.

Der vorliegende Teil 5 unserer Reihe beschäftigt sich mit der Einrichtung des Proxyservers Squid.

Überblick: Workshop SLOS

Teil

Überschrift

Teil 1

SuSE Linux Office Server installieren

Teil 2

Windows- und Linux-Clients konfigurieren

Teil 3

Internet-Zugang über ISDN und ADSL

Teil 4

Printserver und Intranet einrichten

Teil 5

Squid: Proxy-Server einrichten

Teil 6

Apache: Webserver einrichten

Teil 7

NIS/NFS, DHCP, DNS und Samba

Teil 8

Security und Firewall

Teil 9

Server-Fernwartung mit Cygwin

Funktion des Proxy-Servers

Bei Squid handelt es sich um den am weitesten verbreiteten Proxyserver für Unix- beziehungsweise Linux-Plattformen. Die Software funktioniert als "Makler". Sie erhält Anfragen von den Clients, in diesem Fall von den Webbrowsern, und leitet diese an die zuständigen Server im Internet weiter. Sind die angeforderten Objekte beim Proxyserver angekommen, leitet dieser sie an den Client im lokalen Netz weiter.

Dabei behält der Proxy eine Kopie im lokalen Festplatten-Cache. Der Vorteil zeigt sich dann, wenn mehrere Clients dieselben Objekte aus dem Internet anfordern. Diese können nun aus dem lokalen Cache ausgeliefert werden, also wesentlich schneller, als wenn sie wieder neu aus dem Internet geladen werden.

Squid: Die Features

Die Software Squid bietet ein großes Spektrum an Features. So ermöglicht der Proxy unter anderem die Festlegung von Hierarchien zum Verteilen der Systemlast beim Einsatz mehrerer Proxyserver. Aber auch das Aufstellen mehrerer Zugriffsregeln für alle Clients, die auf den Proxy zugreifen wollen, Erteilen und Verweigern von Zugriffsrechten auf bestimmte Webseiten mit Hilfe anderer Applikationen sowie die Ausgabe von Statistiken der meistbesuchten Webseiten unterstützt Squid.

Dabei ist Squid ein so genannter generischer Proxy. Dieser vermittelt normalerweise nur zwischen HTTP-Verbindungen. Ebenfalls unterstützt werden die Protokolle FTP, Gopher, SSL und WAIS. Andere proprietäre Internet-Protokolle wie beispielsweise RealAudio-Streams, also Video und Audio, lassen sich mit der Software nicht zwischenspeichern.

Squid greift auf das UDP-Protokoll nur zur Unterstützung der Kommunikation zwischen verschiedenen Caches zurück. Grundlagen und Details zum UDP-Protokoll finden Sie in unserem Grundlagenartikel zur TCP/IP-Protokollsuite.

Einsatz mehrerer Caches

Auch wenn dies beim Einsatz des SuSE Linux Officer Server und auf Grund der Netzwerkgröße in der Regel nicht der Fall sein sollte, gehen wir der Vollständigkeit halber kurz auf die Möglichkeit ein, mehrere Proxyserver unter Squid einzusetzen. Alle Konfigurationsbeispiele beruhen jedoch darauf, dass der auf dem Office Server laufende Proxyserver der einzige Cache im lokalen Netzwerk ist.

In einem Netzwerk lassen sich mehrere Caches so konfigurieren, dass sie Objekte untereinander austauschen können. Das reduziert die Systemlast und steigert zudem die Wahrscheinlichkeit, dass ein Objekt bereits in einem der Caches zwischengespeichert ist. Daneben lassen sich auch komplette Cache-Hierarchien aufsetzen. So kann jeder Cache Objektanfragen an Caches der gleichen Hierarchie weiterleiten oder einen übergeordneten Cache dazu zu veranlassen, die Objekte von einem anderen Cache im lokalen Netzwerk oder direkt aus dem Internet herunterzuladen.

Die entsprechende Kommunikation wird von dem auf UDP basierenden Internet Cache Protocol (ICP) gesteuert. Der Datenaustausch zwischen den Caches geschieht mittels HTTP. Um den besten Server für ein gewünschtes Objekt zu finden, schickt ein Cache an alle Proxies derselben Hierarchie eine ICP-Anfrage. Die Proxies reagieren daraufhin mit einer ICP-Antwort mit dem Code "HIT", falls das Objekt gefunden wurde oder, falls nicht, mit dem Code "MISS". Im Fall mehrerer HIT-Antworten bestimmt der Proxy einen Server für das Herunterladen. Hierbei spielt bei der Entscheidung unter anderem eine Rolle, welcher Cache die schnellste Antwort sendet.

Umgang mit Internet-Objekten

Nicht alle im Internet verfügbaren Inhalte sind statisch. So existieren zum Beispiel zahlreiche dynamisch generierte Webseiten, Zugriffszähler oder per SSL verschlüsselte Seiten. Diese Objekte können daher auch nicht im Proxyserver zwischengespeichert werden. Bei jedem neuen Zugriff hat sich das entsprechende Objekt bereits wieder verändert.

Bei allen anderen Objekten, wie beispielsweise statischen Webseiten, stellt sich die Frage, wie lange diese im Cache zwischengespeichert werden sollen. Hierzu ordnet man alle Objekte im Cache in drei verschiedene Klassen ein:

Durch Header wie "Last modified" oder "Expires" und dem entsprechenden Datum informiert sich der Proxyserver Squid über den Status eines Objekts. Es werden aber auch andere Header verwendet, die zum Beispiel anzeigen, dass ein Objekt nicht zwischengespeichert werden soll.

Da im Cache nur begrenzter Speicherplatz zur Verfügung steht, müssen regelmäßig Objekte durch andere ersetzt werden. Hierbei kommen spezielle Algorithmen zum Einsatz, wie zum Beispiel "Last Recently Used" (LRU). Im Grunde passiert dabei nicht anderes, als die am seltensten abgerufenen Objekte durch häufiger angeforderte zu ersetzen.

Systemvoraussetzungen

Je kleiner der Cache, desto geringer ist auch die Wahrscheinlichkeit eines HIT, also dass sich das gewünschte Objekt im Cache befindet. Das Objekt muss in vielen Fällen aus dem Internet geladen werden. Zur Ermittlung der geeigneten Cache-Größe ist ein wenig Rechenarbeit angesagt. Steht zum Beispiel 1 GByte Festplattenspeicher für den Squid-Cache zur Verfügung, während die User im lokalen Netzwerk nur 10 MByte pro Tag zum Surfen benötigen, so dauert es mehr als 100 Tage, bis der Proxyserver voll ist.

Am einfachsten berechnet man die Größe des Cache an Hand der Verbindungsgeschwindigkeit ins Internet. Bei einer Verbindung mit 1 Mbit/s liegt die Durchsatzrate bei rund 125 kByte/s. Würde der gesamte Datenverkehr zwischengespeichert so landeten in einer Stunde theoretisch rund 450 MByte Daten im Speicher. Über einem achtstündigen Arbeitstag fielen also 3,6 GByte an. Da aber nicht acht Stunden lang durchgehend Daten aus dem Internet abgerufen werden, reicht eine Cache-Größe von 1,5 bis 2 GByte in der Regel aus, um die Daten aller aufgerufenen Internet-Seiten für einen Tag zwischenzuspeichern.

Der von Squid benötigte Arbeitsspeicher hängt von der Größe des Festplatten-Cache ab. Das liegt daran, dass der Proxy häufig angeforderte Objekte zusätzlich im Hauptspeicher vorhält, um sie noch schneller ausliefern zu können. Zudem lagern auch weitere Informationen im Arbeitsspeicher. Dazu zählen etwa eine Tabelle mit allen vergebenen IP-Adressen sowie diverse Listen zur Zugriffskontrolle. Grundsätzlich gilt also auch hier die Regel: je mehr Arbeitsspeicher, desto besser.

Squid unter SLOS

Nach der Installation des SuSE Linux Office Server ist der Proxyserver Squid schon grundlegend konfiguriert und wird automatisch beim Booten des Systems gestartet. Dabei stellt der Proxy einige Grundfunktionen bereits zur Verfügung, ohne dass Sie sich weiter darum kümmern müssen:

Im folgenden erläutern wir, wie Sie den Proxyserver weiter auf Ihre Bedürfnisse hin optimieren. Unter anderem zeigen wir, wie Sie Zugriffsregeln zum Internet erstellen und bestimmte Webseiten für die Clients im lokalen Netzwerk sperren, so dass kein Zugriff mehr darauf möglich ist.

Schaltzentrale rcsquid

Mit dem Kommando "rcsquid" können Sie als User root den Proxyserver Squid bequem manuell steuern. Das Kommando "rcsquid start" startet den Server und liefert Ihnen nach dem erfolgreichen Starten den Status "Starting WWW-proxy squid done" zurück. Hat man Änderungen an der zentralen Konfigurationsdatei "/etc/squid.conf" vorgenommen, so muss man Squid stets neu starten.

Hier gibt es zwei Möglichkeiten: "rcquid reload" veranlasst den Server, lediglich diese Datei neu einzulesen, alternativ startet man mit "rcsquid restart" den Server komplett neu. Das Kommando "rcsquid status" zeigt den aktuellen Betriebsstatus des Servers an, also ob dieser aktuell läuft oder nicht. Der Befehl "rcsquid stop" beendet den Proxyserver. Ob Letzterer beim Booten des Systems automatisch gestartet wird oder nicht, legen Sie in der Datei "/etc/rc.config" mit der Option "START_SQUID" fest.

Squid beenden

Das Beenden des Servers kann eine Weile dauern, da Squid bis zu einer halben Minute wartet, bevor Verbindungen zu den Clients unterbrochen werden und er dann seine Daten auf die Festplatte schreiben muss. Die Wartezeit hängt von der Option "shutdown_lifetime" in der Datei "/etc/squid.conf" ab.

Ein "gewaltsames" Beenden des Proxyservers mit "kill" beziehungsweise "killall" kann einen zerstörten Cache zur Folge haben. In diesem Fall müssen Sie den Pufferspeicher komplett löschen, bevor Sie Squid erneut starten können.

Beendet sich der Proxyserver nach kurzer Zeit, nachdem er scheinbar erfolgreich gestartet wurde, liegt dies möglicherweise an einem fehlerhaften Nameserver-Eintrag oder an einer fehlenden Datei "/etc/resolv.conf". Den Grund für einen gescheiterten Start protokolliert der Server in seiner Protokolldatei, die sich unter "/var/squid/logs/cache.log" findet.

Kooperation mit BIND

Es ist durchaus sinnvoll, einen lokalen Nameserver wie BIND8 oder BIND9 aufzusetzen, auch wenn dieser keine eigene Domain verwaltet. Dieser fungiert dann lediglich als "Caching-only DNS" und kann ohne spezielle Konfiguration DNS-Anfragen über die Root-Nameserver auflösen.

Tragen Sie diesen in der Datei "/etc/resolv.conf" mit der IP-Adresse 127.0.0.1 für localhost ein, so findet Squid beim Starten stets einen gültigen Nameserver.

Hierbei reicht es aus, das entsprechende Paket zu installieren und BIND zu starten. Zudem sollte man den Nameserver des Providers in der Konfigurationsdatei "/etc/named.conf" unter "forwarders" eintragen.

Konfigurationsdatei /etc/squid.conf

Alle Einstellungen zum Proxyserver werden in der Datei "/etc/squid.conf" vorgenommen. Die einzelnen Optionen sind dort ausführlich und mit zahlreichen Beispielen dokumentiert.

Die meisten Einträge wurden dabei mit einer Raute auskommentiert, am Zeilenende finden sich die relevanten Spezifikationen. Dabei entsprechen die angegebenen Werte meist den voreingestellten Settings. Das Entfernen der Raute, ohne den Parameter der Option zu ändern, hat also in den meisten Fällen keine Auswirkungen.

Es empfiehlt sich, die Beispiele stehen zu lassen und die Optionen mit den geänderten Parametern in der darunter liegenden Zeile erneut einzufügen. So können Sie später die voreingestellten Werte und deren Änderungen problemlos nachvollziehen.

Optionen von squid.conf

Die folgende Tabelle erläutert Ihnen die wichtigsten Optionen der Datei "/etc/squid.conf", deren Funktion und gibt Vorschläge zur Konfiguration.

Optionen in /etc/squid.conf

Option

Bedeutung

http_port 3128

Dies ist der Port, auf dem Squid auf Anfragen der Clients wartet. Voreingestellt ist 3128, gebräuchlich ist auch 8080. Mehrere Portnummern geben Sie durch Leerzeichen getrennt an.

cache_peer [hostname] [type] [proxy-port] [icp-port]

Mit dieser Option legt man einen übergeordneten Proxy als "Parent" fest, wenn man zum Beispiel den des Providers nutzen will oder muss. Als [hostname] tragen Sie den Namen oder die IP-Adresse des Proxy ein und als [type] "parent". Für [proxy-port] geben Sie die Portnummer des Proxy ein. Den [icp-port] kann man auf 7 oder 0 setzen, wenn man den ICP-Port des Parent nicht kennt. Zusätzlich sollten Sie noch "default" und "no-query" nach den Portnummern angeben, um die Verwendung des ICP-Protokolls ganz zu unterbinden. Squid verhält sich dann wie ein normaler Webbrowser gegenüber dem Proxyserver des Internet-Providers.

cache_mem 8 MB

Diese Option legt fest, wie viel Arbeitsspeicher von Squid für das Zwischenspeichern maximal verwendet wird. Voreingestellt sind 8 Megabyte.

cache_dir ufs / var/cache/squid 100 16 256

Legt das Verzeichnis fest, in dem alle Objekte auf der Festplatte abgelegt werden. Die Zahlen geben den maximal zu verwendenden Speicherplatz in Megabyte an sowie die Anzahl der Verzeichnisse in erster und zweiter Ebene. Den Parameter "ufs" sollten Sie unverändert lassen. Bei dem zu verwendenden Plattenplatz sollte man genügend Reserven lassen und Werte zwischen 50 und 80 Prozent des verfügbaren Platzes wählen. Die Werte für die Zahl der Verzeichnisse sollten Sie nur mit Vorsicht vergrößern. Zu viele Verzeichnisse gehen auf Kosten der Performance. Wollen Sie den Cache auf mehrere Platten verteilen, so geben Sie entsprechend viele cache_dir-Zeilen an.

cache_access_log [path]

Diese Option legt fest, wo Squid die Protokolldatei für die Zugriffe speichert.

cache_log [path]

Pfandangabe für die allgemeine Protokolldatei des Proxyservers.

cache_store_log [path]

Diese Protokolldatei speichert alle Aktivitäten des Caches, zum Beispiel welche Objekte gelöscht wurden.

emulate_httpd_log off

Wenn man diese Option auf "on" setzt, so erhält man Protokolldateien indem Format, wie sie zahlreiche Webserver speichern. Allerdings kann dies zu Problemen mit einigen Programmen zur Auswertung der Dateien kommen.

client_netmask 255.255.255.255

Mit diesem Eintrag kann man die protokollierten IP-Adressen in den Protokolldateien maskieren. Damit können Sie die Identität der Clients verbergen. Wenn Sie 255.255.255.0 angeben, wird die letzte Stelle der IP-Adressen auf 0 gesetzt.

ftp_user Squid@

Diese Option legt das Passwort fest, welches für anonymes FTP verwendet wird. Da manche Server die E-Mail-Adresse auf Ihre Gültigkeit hin überprüfen, kann es sinnvoll sein, eine gültige Adresse anzugeben.

cache_mgr webmaster

E-Mail-Adresse, an welchen Squid eine E-Mail schickt, falls der Proxyserver abstürzt.

logfile_rotate 0

Der Proxyserver ist in der Lage, die gespeicherten Protokolldateien zu rotieren, wenn man den Befehl "squid -k rotate" aufruft. Dabei werden die Dateien, entsprechend der angegebenen Anzahl, durchnummeriert, und nach Erreichen des angegebenen Wertes wird die jeweils älteste Datei wieder überschrieben. Standardmäßig steht dieser Wert auf 0.

append_domain [domain]

Mit dieser Option können Sie festlegen, welche Domain automatisch angehängt wird, wenn keine angegeben wird. Meist gibt man hier die eigene Domain an, so genügt es "www" einzugeben und man landet auf dem eigenen Webserver.

forwarded_for on

Wenn Sie diese Option auf "off" setzen, entfern Squid die IP-Adresse beziehungsweise den Systemnamen des Clients aus den HTTP-Anfragen.

negative_ttl 5 minutes; negative_dns_ttl 5 minutes

Diese beiden Werte brauchen Sie in der Regel nicht zu ändern. Bei einer Wählverbindung ins Internet kann es jedoch vorkommen, dass das Internet zeitweise nicht verfügbar ist. Der Proxyserver merkt sich diese erfolglosen Anfragen und verweigert erneute Anfragen, auch wenn die Internetverbindung bereits wieder besteht. In diesem all ändern Sie "minutes" in "seconds". So lädt ein Reload im Webbrowser einigen Sekunden nach dem Einwählen ins Internet die gewünschte Seite problemlos.

Bei den hier genannten Optionen handelt es sich nur um die wichtigsten Eistellungen. Der Proxyserver Squid bietet daneben zahlreiche weitere Konfigurationsmöglichkeiten. Die Datei "/etc/squid.conf" umfasst bei SuSE Linux Office Server rund 2.200 Zeilen - also genug Platz für Einstellungen und Werte.

Zugriffskontrolle mit Squid

Squid bietet ein komplexes System, das den Zugriff auf den Proxyserver steuert. Durch die Verwendung so genannter Access Control Lists, kurz ACLs, konfigurieren Sie den Zugriff einfach und vielseitig. Bei den ACLs handelt es sich im Grunde um einfache Listen mit Regeln, die der Reihe nach abgearbeitet werden.

Jedoch bewirkt das alleinige Festlegen der Access Control Lists zunächst gar nichts. Erst wenn diese beispielsweise in Verbindung mit "http_access" einsetzen, werden die von Ihnen definierten Regeln abgearbeitet.

Im folgenden erläutern wir Ihnen die wichtigsten Optionen für die Access Control Lists.

Definition einer ACL

Zur Definition einer Access Control List werden mindestens drei Angaben benötigt:

acl [acl_name] [type] [data]

Den Namen der ACL unter [acl_Name] können Sie frei wählen. Für [type] existieren eine Vielzahl verschiedener Möglichkeiten, welche Sie im Abschnitt "ACCESS CONTROLS" in der Datei "/etc/squid.conf" nachlesen können. Was Sie unter [data] angeben, hängt vom jeweiligen Typ der ACL hat und kann auch aus einer Datei zum Beispiel mit Rechnernamen oder IP-Adressen eingelesen werden.

Hierzu ein paar einfache Beispiele:

acl chef src 192.168.0.34/255.255.255.0
acl vertrieb src 192.169.0.20-192.168.0.24/255.255.255.0
acl mittags time MTWHF 12:00-15:00

Definition von Zugriffsrechten

Zur Festlegung von Zugriffsrechten verwenden Sie den Befehl:

http_access allow [acl_name]

Diese Option legt fest, wer den Proxy verwenden darf und auf was er im Internet zugreifen darf. Dabei geben Sie ACLs an, die mit "deny" oder "allow" den Zugriff sperren oder freigeben. Hier können Sie eine Liste mit mehreren "http_access"-Einträgen erstellen, die von oben nach unten abgearbeitet wird. Als letzter Eintrag sollte jedoch aus Gründen der Sicherheit stets "http_access deny all" stehen.

Im folgenden Beispiel hat nur der Rechner 192.168.0.3 Zugriff auf alles, während er für alle anderen gesperrt ist:

http_acess allow 192.168.0.3
http_access deny all

In folgendem Beispiel werden zuvor definierte ACLs verwendet. Der Chef hat jederzeit Zugriff auf das Internet, der Vertrieb darf nur Montags bis Freitags surfen, und auch da nur jeweils mittags:

http_access allow chef
http_access allow vertrieb mittags
http_access deny all

Damit die Datei /etc/squid.conf" halbwegs übersichtlich bleibt, sollten Sie Ihr eigenen "http_access"-Einträge nur an der entsprechenden vorgesehenen Stelle eintragen, zwischen "# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS" und dem abschließenden "http_access deny all".

Pfadangaben

Mit der Option redirect_program [pfad] legen Sie einen so genannten "Redirector" fest, wie beispielswise SquidGuard, der in der Lage ist, unerwünschte URLs zu sperren. In Verbindung mit der Proxy-Authentifizierung und den entsprechenden ACLs können Sie den Zugriff auf das Internet sehr detailliert steuern. Auf Details zur Installation und Konfiguration von SquidGuard gehen wir im folgenden noch ein.

Die Benutzeranmeldung regelt die Option authenticate_program [path]. Zur Authentifizierung der Benutzer am Proxyserver benötigen Sie ein entsprechendes Programm wie beispielsweise "pam_auth". Beim ersten Zugriff öffnet sich ein Dialogfenster, das den Anwender auffordert, sich mit Benutzernamen und Passwort zu authentifizieren. Hierzu ist eine ACL erforderlich, die sicherstellt, dass Clients nur nach erfolgreichem Login surfen dürfen:

acl password proxy_auth REQUIRED
http_access allow password
http_access deny all

SquidGuard

Da Squid mit eigenen Bordmitteln nicht alle gewünschten Zugriffsbeschränkungen abdecken kann, installieren wir zusätzlich die Software SquidGuard. Bei SquidGuard handelt es sich um einen unter der GPL freien, flexiblen und zugleich sehr schnellen Filter für den Proxyserver Squid. Er ermöglicht das Festlegen einer Vielzahl von Zugriffsregeln mit unterschiedlichen Beschränkungen für verschiedene Benutzergruppen.

SquidGuard unterstützt unter anderem folgende Optionen:

Weder mit dem Proxyserver Squid noch mit der Erweiterung SquidGuard können Sie jedoch Text innerhalb eines Dokuments sowie in HTML eingebettete Skriptsprachen wie JavaScript filtern.

Installation

Die Installation der Erweiterung SquidGuard ist in wenigen Schritten erledigt. Gehen Sie hierzu auf dem Office-Server auf "Office Server Control Center, Software, Software installieren/löschen". Suchen Sie nun nach dem Begriff "squid". YaST2 findet daraufhin zwei Pakete: Die bereits Installierte Squid-Software sowie das Paket "squidgrd". Letzteres ist nun zu installieren.

Vor der weiteren Konfiguration sollten Sie eine einfache HTML-Seite "Zugriff verweigert" erzeugen, um Squid umzuleiten, falls ein Client eine gesperrte Seite aufruft. Alternativ können Sie auch eine etwas komplexe CGI-Seite erzeugen.

squid.conf anpassen

Als nächstes müssen wir dem Proxyserver Squid noch mitteilen, dass dieser den soeben installierten SquidGuard auch benutzen soll. Hierzu verwenden Sie die bereits erläuterte Option "redirect_program [pfad]" in der Datei "/etc/squid.conf". Den Pfad passen Sie entsprechend Ihrer Konfiguration an. Nach der Installation mit YaST2 befindet sich SquidGuard standardmäßig unter "/usr/bin/squidGuard", also "redirect_programm /usr/bin/squidGuard".

Direkt unter der Option "redirect_program" finden Sie die Option "redirect_children". Mit dieser legen Sie fest, wie viele verschiedene Umleitungsprozesse auf dem Rechner laufen sollen. Da SquidGuard ein sehr flottes Programm ist, sind vier Prozesse völlig ausreichend.

Zum Schluss der Installation von SquidGuard geben Sie auf der Konsole als User root noch das Kommando "squid -k reconfigure". Damit liest der Proxyserver Squid die Konfigurationsdatei "/etc/squid.conf" neu an und nutzt auch die darin vorgenommenen Änderungen. Ohne dem Ausführen dieses Kommandos würde der Proxy erst bei einem Neustart die Änderungen "bemerken".

Konfiguration

Im Verzeichnis "/etc" befindet sich bereits eine zentrale Konfigurationsdatei "squidguard.conf". Diese ist aber in der Praxisnicht wirklich zu gebrauchen, so dass wir an dieser Stelle eine neue entsprechende Datei anlegen. Diese sollte mindestens folgenden Inhalt haben:

logdir /var/squidGuard/logs

acl {
default {
pass all
}
}

Die erstellte HTML-Seite "Zugriff verweigert", die zum umleiten von Squid für den Fall dient, dass ein Client eine gesperrte Webseite aufruft, fügen Sie mit "redirect [pfad]" in die entsprechende Zugriffsregel ein.

Auf der SquidGuard-Website finden Sie eine ausführliche Anleitung zum Erstellen von Zugriffsregeln für SquidGuard. Auch entsprechende Beispieldateien für "/etc/squidguard.conf" stehen zum Herunterladen zur Verfügung.

Cache-Manager

Der Cache-Manager ist ein CGI-Hilfsprogramm zur Ausgabe von Statistiken über den Speicherbedarf der laufenden Squid-Prozesse. Im Gegensatz zu den Protokolldateien erleichtert dies die Cache-Verwaltung und die Anzeige von Statistikenüber den Proxy.

Da der Webserver Apache auf dem SuSE Linux Office Server samt der Unterstützung für CGIs bereits fertig konfiguriert ist, gestaltet sich das Einrichten des Cache-Managers recht einfach. Ihrerseits sind somit keine umfangreichen Konfigurationen mehr nötig.

Im ersten Schritt kopieren Sie die Datei "cachemgr.cgi" in das Verzeichnis "cgi-bin" von Apache. Da sich die datei bereits auf Ihrem Rechner befindet, erledigen Sie dies ohen größen Aufwand mit folgendem Befehl auf der Konsole:

cp /usr/share/doc/packages/squid/scripts/cachemgr.cgi
/usr/local/httpd/cgi-bin

Konfiguration

In der Regel dürfte nun bereits alles soweit funktionieren und der Zugriff auf den Cache-Manager über die URL "http://[server].[domain]/cgi-bin/cachemgr.cgi" möglich sein. Den Server- sowie den Domainnamen müssen Sie auch hier wieder entsprechend Ihrer Umgebung anpassen.

Sollte es Schwierigkeiten beim Zugriff auf den Cache-Manager geben, so überprüfen Sie, ob die CGI-Datei auch ausführbar ist und ob die folgenden Access Control Lists in der Datei "/etc/squid.conf" vorhanden sind. Normalerweise müssten diese Standardeinstellungen und Regeln jedoch bereits eingetragen sein:

acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
http_access allow manager localhost
http_access deny manager

Am wichtigsten ist hierbei die erste ACL. Der Cache-Manager kommuniziert mit dem Proxyserver Squid über das "cache_object"-Protokoll. Die folgenden Regeln setzen voraus, dass der Webserver, in unserem Fall Apache, und Squid auf demselben Rechner ihren Dienst verrichten. Die Kommunikation zwischen dem Cache-Manager und dem Proxyserver findet auf dem Server statt. Läuft der Webserver nun auf einem anderen Rechner als Squid, so müssten Sie eine entsprechende ACL hinzufügen und das Ganze würde folgendermaßen aussehen:

acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl webserver src 192.168.0.5/255.255.255.255

http_access allow manager localhost
http_access allow manager webserver
http_access deny all

Optionen

Sie können für den Cache-Manager auch ein Passwort konfigurieren, wenn auf mehrere Optionen zugegriffen werden soll, wie beispielsweise das Schließen des Cache von Remote oder die Anzeige weiterer Informationen über den Cache. Hierzu müssen Sie den Eintrag "cachemgr_passwd" sowie die Liste der anzuzeigenden Optionen mit einem Passwort für den Manager konfigurieren. Diese Liste erscheint als Teil der Eintragkommentare in "/etc/squid.conf".

Beachten Sie, dass immer wenn sich die Konfigurationsdatei von Squid geändert hat, müssen Sie den Proxyserver mitteilen, dass er die Datei "/etc/squid.conf" neu einliest:

squid -k reconfigure

Neben dem standardmäßig verfügbaren Cache-Manager gibt es zahlreiche weitere Programme zur Auswertung der Squid-Protokolldateien. Empfehlenswert ist unter anderem der sehr umfangreiche Webalizer, welcher die Daten übersichtlich grafisch darstellt. Eine Anleitung zum Einrichten des Webalizer für die Nutzung mit dem Proxyserver Squid finden Sie in unserem Beitrag "Squid: Proxy-Server unter Linux".

Transparenter Proxy

In der Regel schickt der Browser seine Anfragen an einen Port des Proxyservers, meist 3128 oder 8080, und der Proxy stellt die angeforderten Objekte zur Verfügung. Innerhalb eines lokalen Netzwerks ist es aber oft praktischer, wenn alle Clients einen Proxyserver benutzen, egal ob sie sich dessen bewusst sind oder nicht.

In diesem Fall kommt ein transparenter Proxy zum Einsatz. Dabei nimmt der Proxy alle Anfragen der Webbrowser entgegen. Der Browser erhält die angeforderten Objekte, ohne aber zu wissen woher diese tatsächlich kommen. Standardmäßig ist der im Office-Server integrierte Proxyserver Squid als transparenter Proxy konfiguriert. Herzu sind in der Datei "/etc/squid.conf" folgende Optionen aktiviert:

Ausblick

Mit der maßgeschneiderten Einrichtung des Proxyservers Squid befinden wir uns schon mitten in den erweiterten Konfigurationsarbeiten am SuSE Linux Office Server. Im nächsten Teil unserer Serie gehen wir auf die erweiterten Anpassungsmöglichkeiten für den Webserver Apache ein.

Dabei zeigen wir Ihnen, wie Sie mit Apache gezielt Zugriffsregeln vergeben und Features wie SSI und CGI sowie die mächtige Skriptsprache PHP im Zusammenspiel mit dem Webserver nutzen. (jlu)

Überblick: Workshop SLOS

Teil

Überschrift

Teil 1

SuSE Linux Office Server installieren

Teil 2

Windows- und Linux-Clients konfigurieren

Teil 3

Internet-Zugang über ISDN und ADSL

Teil 4

Printserver und Intranet einrichten

Teil 5

Squid: Proxy-Server einrichten

Teil 6

Apache: Webserver einrichten

Teil 7

NIS/NFS, DHCP, DNS und Samba

Teil 8

Security und Firewall

Teil 9

Server-Fernwartung mit Cygwin