Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Bezieht sich auf SUSE Linux Enterprise Server 11 SP4

33 Der Squid-Proxyserver

Squid ist ein häufig verwendeter Proxy-Cache für Linux- und UNIX-Plattformen. Das bedeutet, dass er angeforderte Internetobjekte, wie beispielsweise Daten auf einem Web- oder FTP-Server, auf einem Computer speichert, der sich näher an der Arbeitsstation befindet, die die Anforderung ausgegeben hat, als der Server. Er kann in mehreren Hierarchien eingerichtet werden. So werden optimale Reaktionszeiten und die Nutzung einer niedrigen Bandbreite garantiert – auch bei Modi, die für den Endbenutzer transparent sind. Zusätzliche Software, wie squidGuard, kann zum Filtern der Webinhalte verwendet werden.

Squid dient als Proxy-Cache. Er leitet Objektanforderungen von Clients (in diesem Fall: von Webbrowsern) an den Server weiter. Wenn die angeforderten Objekte vom Server eintreffen, stellt er die Objekte dem Client zu und behält eine Kopie davon im Festplatten-Cache. Einer der Vorteile des Cachings besteht darin, dass mehrere Clients, die dasselbe Objekt anfordern, aus dem Festplatten-Cache versorgt werden können. Dadurch können die Clients die Daten wesentlich schneller erhalten als aus dem Internet. Durch dieses Verfahren wird außerdem der Datenverkehr im Netzwerk reduziert.

Neben dem eigentlichen Caching bietet Squid eine breite Palette von Funktionen, wie die Verteilung der Last auf mehrere miteinander kommunizierende Hierarchien von Proxyservern, die Definition strenger Zugriffssteuerungslisten für alle Clients, die auf den Proxy zugreifen, das Zulassen oder Verweigern des Zugriffs auf bestimmte Webseiten mithilfe anderer Anwendungen und das Erstellen von Statistiken zu häufig besuchten Webseiten zur Bewertung der Internetgewohnheiten des Benutzers. Squid ist kein generischer Proxy. Er fungiert normalerweise nur bei HTTP-Verbindungen als Proxy. Außerdem unterstützt er die Protokolle FTP, Gopher, SSL und WAIS, nicht jedoch andere Internetprotokolle, wie Real Audio, News oder Video-Konferenzen. Da Squid nur das UDP-Protokoll für die Bereitstellung von Kommunikation zwischen verschiedenen Caches unterstützt, werden zahlreiche andere Multimedia-Programme nicht unterstützt.

33.1 Einige Tatsachen zu Proxy-Caches

Als Proxy-Cache kann Squid auf verschiedene Weise verwendet werden. In Kombination mit einer Firewall kann er die Sicherheit unterstützen. Mehrere Proxies können gemeinsam verwendet werden. Außerdem kann er ermitteln, welche Objekttypen für wie lange im Cache gespeichert werden sollen.

33.1.1 Squid und Sicherheit

Squid kann zusammen mit einer Firewall verwendet werden, um interne Netzwerke mithilfe eines Proxy-Caches gegen Zugriffe von außen zu schützen. Die Firewall verweigert allen Clients Zugriff auf externe Dienste mit Ausnahme von Squid. Alle Webverbindungen müssen vom Proxy erstellt werden. Bei dieser Konfiguration steuert Squid den gesamten Webzugriff.

Wenn zur Firewall-Konfiguration eine DMZ gehört, sollte der Proxy in dieser Zone betrieben werden. In Abschnitt 33.5, „Konfigurieren eines transparenten Proxy“ wird die Implementierung eines transparenten Proxys beschrieben. Dadurch wird die Konfiguration der Clients erleichtert, da sie in diesem Fall keine Informationen zum Proxy benötigen.

33.1.2 Mehrere Caches

Mehrere Instanzen von Squid können für den Austausch von Objekten konfiguriert werden. Dadurch verringert sich die Gesamtlast im System und die Wahrscheinlichkeit, ein Objekt zu finden, das bereits im lokalen Netzwerk vorhanden ist, erhöht sich. Außerdem können Cache-Hierarchien konfiguriert werden, sodass ein Cache Objektanforderungen an gleichgeordnete Caches oder einen übergeordneten Cache weiterleiten kann, sodass er Objekte aus einem anderen Cache im lokalen Netzwerk oder direkt von der Quelle erhält.

Die Auswahl einer geeigneten Topologie für die Cache-Hierarchie ist von entscheidender Bedeutung, da es nicht erstrebenswert ist, das Gesamtaufkommen an Datenverkehr im Netzwerk zu erhöhen. Bei sehr großen Netzwerken ist es sinnvoll, einen Proxyserver für jedes Subnetzwerk zu konfigurieren und mit einem übergeordneten Proxy zu verbinden, der wiederum mit dem Proxy-Cache des ISP verbunden ist.

Diese gesamte Kommunikation wird über das ICP (Internet Cache Protocol) abgewickelt, das über dem UDP-Protokoll ausgeführt wird. Die Übertragungen zwischen den Caches erfolgen über HTTP (Hypertext Transmission Protocol) auf der Grundlage von TCP.

Um den geeignetsten Server zum Abrufen der Objekte zu finden, sendet ein Cache eine ICP-Anforderung an alle gleichgeordneten Proxies. Diese beantworten die Anforderungen über ICP-Antworten mit einem HIT-Code, wenn das Objekt erkannt wurde bzw. mit einem MISS-Code, wenn es nicht erkannt wurde. Wenn mehrere HIT-Antworten gefunden wurden, legt der Proxyserver fest, von welchem Server heruntergeladen werden soll. Diese Entscheidung ist unter anderem davon abhängig, welcher Cache die schnellste Antwort gesendet hat bzw. welcher näher ist. Wenn keine zufrieden stellenden Antworten eingehen, wird die Anforderung an den übergeordneten Cache gesendet.

Tipp
Tipp

Um eine Verdopplung der Objekte in verschiedenen Caches im Netzwerk zu vermeiden, werden andere ICP-Protokolle verwendet, wie beispielsweise CARP (Cache Array Routing Protocol) oder HTCP (Hypertext Cache Protocol). Je mehr Objekte sich im Netzwerk befinden, desto größer ist die Wahrscheinlichkeit, das gewünschte zu finden.

33.1.3 Caching von Internetobjekten

Nicht alle im Netzwerk verfügbaren Objekte sind statisch. Es gibt eine Vielzahl dynamisch erstellter CGI-Seiten, Besucherzähler und verschlüsselter SSL-Inhaltsdokumente. Derartige Objekte werden nicht im Cache gespeichert, da sie sich bei jedem Zugriff ändern.

Es bleibt die Frage, wie lange alle anderen im Cache gespeicherten Objekte dort verbleiben sollten. Um dies zu ermitteln, wird allen Objekten im Cache einer von mehreren möglichen Zuständen zugewiesen. Web- und Proxyserver ermitteln den Status eines Objekts, indem sie Header zu diesen Objekten hinzufügen, beispielsweise Zuletzt geändert oder Läuft ab, und das entsprechende Datum. Andere Header, die angeben, dass Objekte nicht im Cache gespeichert werden dürfen, werden ebenfalls verwendet.

Objekte im Cache werden normalerweise aufgrund mangelnden Festplattenspeichers ersetzt. Dazu werden Algorithmen, wie beispielsweise LRU (last recently used), verwendet. Dies bedeutet im Wesentlichen, dass der Proxy die Objekte löscht, die am längsten nicht mehr angefordert wurden.

33.2 Systemanforderungen

Die wichtigste Aufgabe besteht darin, die maximale Netzwerklast zu ermitteln, die das System tragen muss. Daher muss besonders auf die Belastungsspitzen geachtet werden, die mehr als das Vierfache des Tagesdurchschnitts betragen können. Im Zweifelsfall ist es vorzuziehen, die Systemanforderungen zu hoch einzuschätzen, da es zu erheblichen Einbußen in der Qualität des Diensts führen kann, wenn Squid an der Grenze seiner Leistungsfähigkeit arbeitet. Die folgenden Abschnitte widmen sich den einzelnen Systemfaktoren in der Reihenfolge ihrer Wichtigkeit.

33.2.1 Festplatten

Da Geschwindigkeit beim Caching eine wichtige Rolle spielt, muss diesem Faktor besondere Aufmerksamkeit gewidmet werden. Bei Festplatten wird dieser Parameter als random seek time (Zufallszugriffszeit, gemessen in Millisekunden) beschrieben. Da die Datenblöcke, die Squid von der Festplatte liest oder auf die Festplatte schreibt, eher klein zu sein scheinen, ist die Zugriffszeit der Festplatte entscheidender als ihr Datendurchsatz. Für die Zwecke von Proxies sind Festplatten mit hoher Rotationsgeschwindigkeit wohl die bessere Wahl, da bei diesen der Lese-Schreib-Kopf schneller an die gewünschte Stelle gebracht werden kann. Eine Möglichkeit zur Systembeschleunigung besteht in der gleichzeitigen Verwendung mehrerer Festplatten oder im Einsatz von Striping-RAID-Arrays.

33.2.2 Größe des Festplatten-Cache

Bei einem kleinen Cache ist die Wahrscheinlichkeit eines HIT (Auffinden des angeforderten Objekts, das sich bereits dort befindet) gering, da der Cache schnell voll ist und die weniger häufig angeforderten Objekte durch neuere ersetzt werden. Wenn beispielsweise 1 GB für den Cache zur Verfügung steht und die Benutzer nur Datenverkehr im Umfang von 10 MB pro Tag in Anspruch nehmen, dauert es mehrere hundert Tage, um den Cache zu füllen.

Die einfachste Methode zur Ermittlung der benötigten Cache-Größe geht von der maximalen Übertragungsrate der Verbindung aus. Bei einer Verbindung mit 1 Mbit/s beträgt die maximale Übertragungsrate 125 KB/s. Wenn dieser Datenverkehr vollständig im Cache gespeichert wird, ergeben sich in einer Stunde 450 MB. Dadurch würden bei 8 Arbeitsstunden 3,6 GB an einem einzigen Tag erreicht. Da normalerweise nicht das gesamte Volumen der Verbindung ausgeschöpft wird, kann angenommen werden, dass das Gesamtdatenvolumen, das auf den Cache zukommt, bei etwa 2 GB liegt. Daher sind bei diesem Beispiel 2 GB Festplattenspeicher erforderlich, damit Squid die durchsuchten Daten eines Tags im Cache speichern kann.

33.2.3 RAM

Der von Squid benötigte Arbeitsspeicher (RAM) steht in direktem Verhältnis zur Anzahl der Objekte im Cache. Außerdem speichert Squid Cache-Objekt-Bezüge und häufig angeforderte Objekte im Hauptspeicher, um das Abrufen dieser Daten zu beschleunigen. RAM ist wesentlich schneller als eine Festplatte.

Außerdem gibt es andere Daten, die Squid im Arbeitsspeicher benötigt, beispielsweise eine Tabelle mit allen IP-Adressen, einen exakten Domänennamen-Cache, die am häufigsten angeforderten Objekte, Zugriffssteuerungslisten, Puffer usw.

Es ist sehr wichtig, dass genügend Arbeitsspeicher für den Squid-Vorgang zur Verfügung steht, da die Systemleistung erheblich eingeschränkt ist, wenn ein Wechsel auf die Festplatte erforderlich ist. Das Werkzeug cachemgr.cgi kan für die Arbeitsspeicherverwaltung des Cache verwendet werden. Dieses Werkzeug wird in Abschnitt 33.6, „cachemgr.cgi“ behandelt.

33.2.4 Prozessor

Die Verwendung von Squid bringt keine intensive CPU-Auslastung mit sich. Die Prozessorlast wird nur erhöht, während die Inhalte des Cache geladen oder überprüft werden. Durch die Verwendung eines Computers mit mehreren Prozessoren wird die Systemleistung nicht erhöht. Um die Effizienz zu steigern, sollten vielmehr schnellere Festplatten oder ein größerer Arbeitsspeicher verwendet werden.

33.3 Starten von Squid

Installieren Sie das squid-Paket, falls es nicht bereits installiert ist. squid gehört nicht mehr zum standardmäßigen Installationsumfang von SUSE Linux Enterprise Server.

Squid ist in SUSE® Linux Enterprise Server bereits vorkonfiguriert. Sie können das Programm unmittelbar nach der Installation starten. Um einen reibungslosen Start zu gewährleisten, sollte das Netzwerk so konfiguriert werden, dass mindestens ein Namenserver und das Internet erreicht werden können. Es können Probleme auftreten, wenn eine Einwahlverbindung zusammen mit einer dynamischen DNS-Konfiguration verwendet wird. In diesem Fall sollte zumindest der Namenserver eingegeben werden, da Squid nicht startet, wenn kein DNS-Server in /etc/resolv.conf gefunden wird.

33.3.1 Befehle zum Starten und Stoppen von Squid

Geben Sie zum Starten von Squid als root in der Kommandozeile den Befehl rcsquid  start ein. Beim ersten Start muss zunächst die Verzeichnisstruktur des Cache in /var/cache/squid definiert werden. Dies geschieht automatisch über das Startskript /etc/init.d/squid und kann einige Sekunden oder sogar Minuten in Anspruch nehmen. Wenn rechts in grüner Schrift done angezeigt wird, wurde Squid erfolgreich geladen. Um die Funktionsfähigkeit von Squid im lokalen System zu testen, geben Sie localhost als Proxy und 3128 als Port im Browser an.

Um Benutzern aus dem lokalen System und anderen Systemen den Zugriff auf Squid und das Internet zu ermöglichen, müssen Sie den Eintrag in den Konfigurationsdateien /etc/squid/squid.conf von http_access deny all in http_access allow all ändern. Beachten Sie dabei jedoch, dass dadurch jedem der vollständige Zugriff auf Squid ermöglicht wird. Daher sollten Sie ACLs definieren, die den Zugriff auf den Proxy steuern. Weitere Informationen hierzu finden Sie in Abschnitt 33.4.2, „Optionen für die Zugriffssteuerung“.

Nach der Bearbeitung der Konfigurationsdatei /etc/squid/squid.conf muss Squid die Konfigurationsdatei erneut laden. Verwenden Sie hierfür rcsquid  reload. Alternativ können Sie mit rcsquid  restart einen vollständigen Neustart von Squid durchführen.

Mit dem Befehl rcsquidstatus können Sie überprüfen, ob der Proxy ausgeführt wird. Mit dem Befehl rcsquidstop wird Squid heruntergefahren. Dieser Vorgang kann einige Zeit in Anspruch nehmen, da Squid bis zu einer halben Minute (Option shutdown_lifetime in /etc/squid/squid.conf) wartet, bevor es die Verbindungen zu den Clients trennt und seine Daten auf die Festplatte schreibt.

Warnung
Warnung: Beenden von Squid

Das Beenden von Squid mit kill oder killall kann den Cache beschädigen. Damit Squid neu gestartet werden kann, muss ein beschädigter Cache gelöscht werden.

Wenn Squid nach kurzer Zeit nicht mehr funktioniert, obwohl das Programm erfolgreich gestartet wurde, überprüfen Sie, ob ein fehlerhafter Namenservereintrag vorliegt oder ob die Datei /etc/resolv.conf fehlt. Squid protokolliert die Ursache eines Startfehlers in der Datei /var/log/squid/cache.log. Wenn Squid beim Booten des Systems automatisch geladen werden soll, müssen Sie Squid mithilfe des YaST-Runlevel-Editors für die gewünschten Runlevels aktivieren. Weitere Informationen hierzu finden Sie unter Abschnitt 10.2.3, „Konfigurieren von Systemdiensten (Runlevel) mit YaST“.

Durch eine Deinstallation von Squid werden weder die Cache-Hierarchie noch die Protokolldateien entfernt. Um diese zu entfernen, müssen Sie das Verzeichnis /var/cache/squid manuell löschen.

33.3.2 Lokaler DNS-Server

Die Einrichtung eines lokalen DNS-Servers ist sinnvoll, selbst wenn er nicht seine eigene Domäne verwaltet. Er fungiert dann einfach als Nur-Cache-Namenserver und kann außerdem DNS-Anforderungen über die Root-Namenserver auflösen, ohne dass irgendeine spezielle Konfiguration erforderlich ist (siehe Abschnitt 25.4, „Starten des BIND-Nameservers“). Wie dies durchgeführt werden kann, hängt davon ab, ob Sie bei der Konfiguration der Internetverbindung dynamisches DNS auswählen.

Dynamisches DNS

Normalerweise wird bei dynamischem DNS der DNS-Server während des Aufbaus der Internetverbindung vom Anbieter festgelegt und die lokale Datei /etc/resolv.conf wird automatisch angepasst. Dieses Verhalten wird in der Datei /etc/sysconfig/network/config mit der sysconfig-Variablen NETCONFIG_DNS_POLICY gesteuert. Legen Sie NETCONFIG_DNS_POLICY mit dem YaST-sysconfig-Editor auf "" fest (weitere Informationen hierzu finden Sie unter Abschnitt 10.3.1, „Ändern der Systemkonfiguration mithilfe des YaST-Editors "sysconfig"“). Geben Sie anschließend den lokalen DNS-Server in der Datei /etc/resolv.conf ein. Verwenden Sie die IP-Adresse 127.0.0.1 für localhost. Auf diese Weise kann Squid immer den lokalen Namenserver finden, wenn er gestartet wird.

Um den Zugriff auf den Namenserver des Anbieters zu ermöglichen, geben Sie ihn zusammen mit seiner IP-Adresse in die Konfigurationsdatei /etc/named.conf unter forwarders ein. Mit dynamischem DNS kann dies automatisch während des Verbindungsaufbaus erreicht werden, indem die sysconfig-Variable NETCONFIG_DNS_POLICY auf auto festgelegt wird.

Statisches DNS

Beim statischen DNS finden beim Verbindunsgsaufbau keine automatischen DNS-Anpassungen statt, sodass auch keine sysconfig-Variablen geändert werden müssen. Sie müssen jedoch den lokalen DNS-Server in die Datei /etc/resolv.conf eingeben, wie oben beschrieben. Außerdem muss der statische Namenserver des Anbieters zusammen mit seiner IP-Adresse manuell in die Datei /etc/named.conf unter Forwarders eingegeben werden.

Tipp
Tipp: DNS und Firewall

Wenn eine Firewall ausgeführt wird, müssen Sie sicherstellen, dass DNS-Anforderungen durchgelassen werden.

33.4 Die Konfigurationsdatei /etc/squid/squid.conf

Alle Einstellungen für den Squid-Proxyserver werden in der Datei /etc/squid/squid.conf vorgenommen. Beim ersten Start von Squid sind keine Änderungen in dieser Datei erforderlich, externen Clients wird jedoch ursprünglich der Zugriff verweigert. Der Proxy ist für localhost verfügbar. Der Standardport ist 3128. Die vorinstallierte Konfigurationsdatei /etc/squid/squid.conf bietet detaillierte Informationen zu den Optionen sowie zahlreiche Beispiele. Fast alle Einträge beginnen mit # (kommentierte Zeilen) und die relevanten Spezifikationen befinden sich am Ende der Zeile. Die angegebenen Werte korrelieren fast immer mit den Standardwerten, sodass das Entfernen der Kommentarzeichen ohne Ändern der Parameter in den meisten Fällen kaum Auswirkungen hat. Lassen Sie die Beispiele nach Möglichkeit unverändert und geben Sie die Optionen zusammen mit den geänderten Parametern in der Zeile darunter ein. Auf diese Weise können die Standardwerte problemlos wiederhergestellt und mit den Änderungen verglichen werden.

Tipp
Tipp: Anpassen der Konfigurationsdatei nach einer Aktualisierung

Wenn Sie eine Aktualisierung einer früheren Squid-Version durchgeführt haben, sollten Sie die neue Datei /etc/squid/squid.conf bearbeiten und nur die in der vorherigen Datei vorgenommenen Änderungen übernehmen. Wenn Sie versuchen, die alte Datei squid.conf zu verwenden, besteht das Risiko, dass die Konfiguration nicht mehr funktioniert, da Optionen manchmal bearbeitet und neue Änderungen hinzugefügt werden.

33.4.1 Allgemeine Konfigurationsoptionen (Auswahl)

http_port 3128

Dies ist der Port, den Squid auf Client-Anforderungen überwacht. Der Standardport ist 3128, 8080 wird jedoch ebenfalls häufig verwendet. Sie können auch mehrere Portnummern durch Leerzeichen getrennt eingeben.

cache_peer hostnametypeproxy-porticp-port

Geben Sie hier einen übergeordneten Proxy ein, beispielsweise wenn Sie den Proxy Ihres ISP verwenden möchten. Geben Sie als hostname den Namen oder die IP-Adresse des zu verwendenden Proxy und als type parent ein. Geben Sie als proxy-port die Portnummer ein, die ebenfalls vom Operator des Parent für die Verwendung im Browser angegeben wurde, in der Regel 8080). Setzen Sie icp-port auf 7 oder 0, wenn der ICP-Port des übergeordneten Proxy nicht bekannt ist und seine Verwendung für den Anbieter nicht wichtig ist. Außerdem können default und no-query nach den Portnummern angegeben werden, um die Verwendung des ICP-Protokolls zu verhindern. Squid verhält sich dann in Bezug auf den Proxy des Anbieters wie ein normaler Browser.

cache_mem 8 MB

Dieser Eintrag legt fest, wie viel Arbeitsspeicher Squid für besonders beliebte Antworten verwenden kann. Der Standardwert ist 8 MB. Dieser Wert gibt nicht die Arbeitsspeichernutzung von Squid an und kann überschritten werden.

cache_dir ufs /var/cache/squid/ 100 16 256

Der Eintrag cache_dir legt das Verzeichnis fest, in dem alle Objekte auf dem Datenträger gespeichert werden. Die Zahlen am Ende geben den maximal zu verwendenden Festplattenspeicher in BM und die Anzahl der Verzeichnisse auf der ersten und zweiten Ebene an. Der Parameter ufs sollte nicht geändert werden. Standardmäßig werden 100 MB Speicherplatz im Verzeichnis /var/cache/squid belegt und 16 Unterverzeichnisse erstellt, die wiederum jeweils 256 Unterverzeichnisse aufweisen. Achten Sie bei der Angabe des zu verwendenden Speicherplatzes darauf, genügend Reserve einzuplanen. Werte von mindestens 50 bis maximal 80 % des verfügbaren Speicherplatzes erscheinen hier am sinnvollsten. Die letzten beiden Werte für die Verzeichnisse sollten nur nach reiflicher Überlegung erhöht werden, da zu viele Verzeichnisse ebenfalls zu Leistungsproblemen führen können. Wenn der Cache von mehreren Datenträgern gemeinsam verwendet wird, müssen Sie mehrere cache_dir-Zeilen eingeben.

cache_access_log /var/log/squid/access.log, cache_log /var/log/squid/cache.log, cache_store_log /var/log/squid/store.log

Diese drei Einträge geben an, in welchen Pfad Squid alle Aktionen protokolliert. Normalerweise werden hier keine Änderungen vorgenommen. Bei hoher Auslastung von Squid kann es sinnvoll sein, Cache und Protokolldateien auf mehrere Datenträger zu verteilen.

emulate_httpd_log off

Wenn der Eintrag auf on gesetzt ist, erhalten Sie lesbare Protokolldateien. Einige Evaluierungsprogramme können solche Dateien jedoch nicht interpretieren.

client_netmask 255.255.255.255

Mit diesem Eintrag werden die IP-Adressen von Clients in den Protokolldateien maskiert. Die letzte Ziffer der IP-Adresse wird auf 0 gesetzt, wenn Sie hier 255.255.255.0 eingeben. Auf diese Weise können Sie den Datenschutz für die Clients gewährleisten.

ftp_user Squid@

Mit dieser Option wird das Passwort festgelegt, das Squid für die anonyme FTP-Anmeldung verwenden soll. Es kann sinnvoll sein, hier eine gültige E-Mail-Adresse anzugeben, da einige FTP-Server die Adressen auf Gültigkeit prüfen.

cache_mgr webmaster

Eine E-Mail-Adresse, an die Squid eine Meldung sendet, wenn es plötzlich abstürzt. Der Standardwert ist webmaster.

logfile_rotate 0

Wenn Sie squid -k rotate ausführen, kann Squid ein Rotationssystem für gesicherte Protokolldateien einführen. Bei diesem Prozess werden die Dateien nummeriert und nach dem Erreichen des angegebenen Werts wird die älteste Datei überschrieben. Der Standardwert ist 0, da das Archivieren und Löschen von Protokolldateien in SUSE Linux Enterprise Server von einem in der Konfigurationsdatei /etc/logrotate/squid festgelegten Cronjob durchgeführt wird.

append_domain <Domaene>

Mit append_domain können Sie angeben, welche Domäne automatisch angefügt wird, wenn keine angegeben wurde. Normalerweise wird hier die eigene Domäne angegeben, sodass bei der Eingabe von www im Browser ein Zugriff auf Ihren eigenen Webserver erfolgt.

forwarded_for on

Wenn Sie den Eintrag auf off setzen, entfernt Squid die IP-Adresse und den Systemnamen des Client aus den HTTP-Anforderungen. Anderenfalls wird eine Zeile zum Header hinzugefügt, beispielsweise:

X-Forwarded-For: 192.168.0.1
negative_ttl 5 minutes; negative_dns_ttl 5 minutes

Die hier angegebenen Werte müssen in der Regel nicht geändert werden. Bei einer Einwahlverbindung kann das Internet jedoch zeitweise nicht verfügbar sein. Squid protokolliert die nicht erfolgreichen Anforderungen und lässt dann keine weiteren zu, auch wenn die Internetverbindung zwischenzeitlich wieder hergestellt wurde. In solchen Fällen sollten Sie minutes durch seconds ersetzen. Danach sollte nach dem Klicken auf Neu laden im Browser der Einwahlvorgang nach wenigen Sekunden wieder aktiviert werden.

never_direct allow ACL-Name

Um zu verhindern, dass Squid Anforderungen direkt aus dem Internet entgegennimmt, müssen Sie mit dem oben stehenden Befehl die Verbindung mit einem anderen Proxy erzwingen. Dieser muss zuvor unter cache_peer eingegeben worden sein. Wenn als acl_name all angegeben wird, werden alle Anforderungen zwangsweise direkt an den übergeordneten Proxy (parent) weitergeleitet. Dies kann beispielsweise dann erforderlich sein, wenn Sie einen Anbieter verwenden, der die Verwendung der eigenen Proxies strikt vorschreibt oder der durch seine Firewall direkten Internetzugriff verweigert.

33.4.2 Optionen für die Zugriffssteuerung

Squid bietet ein detailliertes System für die Steuerung des Zugriffs auf den Proxy. Durch die Implementierung von ACLs kann es problemlos und umfassend konfiguriert werden. Dazu gehören Listen mit Regeln, die nacheinander verarbeitet werden. Die ACLs müssen zuerst definiert werden, bevor sie verwendet werden können. Einige Standard-ACLs, wie beispielsweise all und localhost, sind bereits vorhanden. Die bloße Definition einer ACL bedeutet jedoch noch nicht, dass sie tatsächlich angewendet wird. Dies geschieht nur in Verbindung mit http_access-Regeln.

acl <ACL-Name> <Typ> <Daten>

Für die Definition eines ACL sind mindestens drei Spezifikationen erforderlich. Der Name <ACL-Name> kann frei gewählt werden. Als <Typ> können Sie aus einer Vielzahl verschiedener Optionen wählen, die Sie im Abschnitt ACCESS CONTROLS in der Datei /etc/squid/squid.conf finden. Die Spezifikation für <Daten> hängt vom einzelnen ACL-Typ ab und kann auch aus einer Datei gelesen werden, beispielsweise über Hostnamen, IP-Adressen oder URLs. Im Folgenden finden Sie einige einfache Beispiele:

acl mysurfers srcdomain .my-domain.com
acl teachers src 192.168.1.0/255.255.255.0
acl students src 192.168.7.0-192.168.9.0/255.255.255.0
acl lunch time MTWHF 12:00-15:00
http_access allow <ACL-Name>

http_access legt fest, wer den Proxy verwenden kann und wer auf welche Seiten im Internet zugreifen kann. Hierfür müssen ACLs angegeben werden. localhost und all wurden bereits oben definiert. Diese Optionen können den Zugriff über deny oder allow verweigern oder zulassen. Es können Listen mit einer beliebigen Anzahl von http_access- Einträgen erstellt und von oben nach unten verarbeitet werden. Je nachdem, was zuerst vorkommt, wird der Zugriff auf die betreffende URL gestattet oder verweigert. Der letzte Eintrag muss immer http_access deny all sein. Im folgenden Beispiel hat localhost freien Zugriff auf alle Elemente, während allen anderen Hosts der Zugriff vollständig verweigert wird.

http_access allow localhost
http_access deny all

In einem anderen Beispiel, bei dem diese Regeln verwendet werden, hat die Gruppe teachers immer Zugriff auf das Internet. Die Gruppe students erhält nur montags bis freitags während der Mittagspause Zugriff.

http_access deny localhost
http_access allow teachers
http_access allow students lunch time
http_access deny all

Die Liste mit den http_access-Einträgen sollte um der besseren Lesbarkeit willen nur an der angegebenen Position in der Datei /etc/squid/squid.conf eingegeben werden. Also zwischen dem Text

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR
# CLIENTS

und dem letzten

http_access deny all
redirect_program /usr/bin/squidGuard

Mit dieser Option können Sie eine Umleitungsfunktion, wie beispielsweise squidGuard, angeben, die das Blockieren unerwünschter URLs ermöglicht. Der Internetzugang kann mithilfe der Proxy-Authentifizierung und der entsprechenden ACLs individuell für verschiedene Benutzergruppen gesteuert werden. squidGuard ist ein gesondertes Paket, das installiert und konfiguriert werden kann.

auth_param basic program /usr/sbin/pam_auth

Wenn die Benutzer auf dem Proxy authentifiziert werden müssen, geben Sie ein entsprechendes Programm an, beispielsweise pam_auth. Beim ersten Zugriff auf pam_auth wird dem Benutzer ein Anmeldefenster angezeigt, in das er den Benutzernamen und das Passwort eingeben muss. Außerdem ist noch immer eine ACL erforderlich, sodass nur Clients mit einer gültigen Anmeldung das Internet benutzen können.

acl password proxy_auth REQUIRED

http_access allow password
http_access deny all

Das REQUIRED nach proxy_auth kann durch eine Liste der zulässigen Benutzernamen oder durch den Pfad zu einer solchen Liste ersetzt werden.

ident_lookup_access allow <ACL-Name>

Lassen Sie damit eine ident-Anforderung für alle ACL-definierten Clients ausführen, um die Identität der einzelnen Benutzer zu ermitteln. Wenn Sie all auf <ACL-Name> anwenden, gilt dies für alle Clients. Außerdem muss ein ident-Dämon auf allen Clients ausgeführt werden. Bei Linux installieren Sie zu diesem Zweck das Paket „pidentd“. Für Microsoft Windows steht kostenlose Software zum Herunterladen aus dem Internet zur Verfügung. Um sicherzustellen, dass nur Clients mit einem erfolgreichen ident-Lookup zulässig sind, definieren Sie hier eine entsprechende ACL:

acl identhosts ident REQUIRED

http_access allow identhosts
http_access deny all

Ersetzen Sie auch hier REQUIRED durch eine Liste der zulässigen Benutzernamen. Durch die Verwendung von ident kann die Zugriffszeit erheblich reduziert werden, da die ident-Lookups für jede Anforderung wiederholt werden.

33.5 Konfigurieren eines transparenten Proxy

In der Regel arbeiten Sie folgendermaßen mit Proxyservern: der Web-Browser sendet Anforderungen an einen bestimmten Port im Proxyserver und der Proxy liefert die angeforderten Objekte unabhängig davon, ob sie sich im Cache befinden oder nicht. Bei der Arbeit in einem Netzwerk können verschiedene Situationen entstehen:

  • Aus Sicherheitsgründen sollten alle Clients einen Proxy für den Zugriff auf das Internet verwenden.

  • Alle Clients müssen einen Proxy verwenden, unabhängig davon, ob sie sich dessen bewusst sind.

  • Der Proxy in einem Netzwerk wird verschoben, die vorhandenen Clients sollten jedoch ihre alte Konfiguration beibehalten.

In all diesen Fällen kann ein transparenter Proxy verwendet werden. Das Prinzip ist einfach: Der Proxy fängt die Anforderungen des Webbrowsers ab und beantwortet sie. Der Webbrowser erhält die angeforderten Seiten, ohne zu wissen, woher sie kommen. Wie der Name schon andeutet, verläuft der gesamte Prozess transparent.

33.5.1 Konfigurationsoptionen in /etc/squid/squid.conf

Um squid mitzuteilen, dass es als ein transparenter Proxy fungieren soll, verwenden Sie die Option transparent am Tag http_port in der Hauptkonfigurationsdatei /etc/squid/squid.conf. Nach dem Neustart von squid muss nur noch die Firewall umkonfiguriert werden, damit sie den HTTP-Port an den Port umleitet, der in http_port angegeben ist. In der folgenden squid-Konfigurationszeile wäre dies der Port 3128.

http_port 3128 transparent

33.5.2 Firewall-Konfiguration mit SuSEfirewall2

Leiten Sie nun alle eingehenden Anforderungen über die Firewall mithilfe einer Port-Weiterleitungsregel an den Squid-Port um. Verwenden Sie dazu das beigefügte Werkzeug SuSEFirewall2 (in Section 15.4.1, “Configuring the Firewall with YaST” beschrieben). Die Konfigurationsdatei dieses Programms finden Sie in /etc/sysconfig/SuSEfirewall2. Die Konfigurationsdatei besteht aus gut dokumentierten Einträgen. Um einen transparenten Proxy festzulegen, müssen Sie mehrere Firewall-Optionen konfigurieren:

  • Gerät zeigt auf das Internet: FW_DEV_EXT=„eth1“

  • Gerät zeigt auf das Netzwerk: FW_DEV_INT=„eth0“

Definieren Sie Ports und Dienste (siehe /etc/services) auf der Firewall, auf die ein Zugriff von nicht verbürgten (externen) Netzwerken, wie beispielsweise dem Internet, erfolgt. In diesem Beispiel werden nur Webdienste für den Außenbereich angeboten:

FW_SERVICES_EXT_TCP="www"

Definieren Sie Ports und Dienste (siehe /etc/services) auf der Firewall, auf die vom sicheren (internen) Netzwerk aus zugegriffen wird (sowohl über TCP als auch über UDP):

FW_SERVICES_INT_TCP="domain www 3128"
FW_SERVICES_INT_UDP="domain"

Dies ermöglicht den Zugriff auf Webdienste und Squid (Standardport: 3128). Der Dienst domain steht für DNS (Domain Name Service, Domänennamen-Dienst). Dieser Dienst wird häufig verwendet. Andernfalls nehmen Sie einfach die oben stehenden Einträge heraus und setzten Sie die folgende Option auf no:

FW_SERVICE_DNS="yes"

Die wichtigste Option ist Option Nummer 15:

Beispiel 33.1: Firewall-Konfiguration: Option 15
# 15.)
# Which accesses to services should be redirected to a local port on
# the firewall machine?
#
# This option can be used to force all internal users to surf via
# your squid proxy, or transparently redirect incoming webtraffic to
# a secure webserver.
#
# Format: 
# list of <source network>[,<destination network>,<protocol>[,dport[:lport]]
# Where protocol is either tcp or udp. dport is the original
# destination port and lport the port on the local machine to
# redirect the traffic to
#
# An exclamation mark in front of source or destination network
# means everything EXCEPT the specified network
#
# Example: "10.0.0.0/8,0/0,tcp,80,3128 0/0,172.20.1.1,tcp,80,8080"

Die oben angegebenen Kommentare geben die zu verwendende Syntax an. Geben Sie zuerst die IP-Adresse und die Netzmaske der internen Netzwerke ein, die auf die Proxy-Firewall zugreifen. Geben Sie als Zweites die IP-Adresse und die Netzmaske ein, an die diese Clients ihre Anforderungen senden. Geben Sie bei Webbrowsern die Netzwerke 0/0 an. Dieser Platzhalter bedeutet „überallhin“. Geben Sie anschließend den ursprünglichen Port ein, an den diese Anforderungen gesendet werden, und schließlich den Port, an den alle diese Anforderungen umgeleitet werden. Da Squid andere Protokolle als HTTP unterstützt, müssen Anforderungen von anderen Ports an den Proxy umgeleitet werden, beispielsweise FTP (Port 21), HTTPS oder SSL (Port 443). In diesem Beispiel werden Webdienste (Port 80) an den Proxy-Port (Port 3128) umgeleitet. Wenn mehrere Netzwerke bzw. Dienste hinzugefügt werden sollen, müssen diese im entsprechenden Eintrag durch ein Leerzeichen getrennt sein.

FW_REDIRECT="192.168.0.0/16,0/0,tcp,80,3128"

Um die Firewall mit der neuen Konfiguration zu starten, müssen Sie einen Eintrag in der Datei /etc/sysconfig/SuSEfirewall2 ändern. Der Eintrag START_FW muss auf „yes“ gesetzt werden.

Starten Sie Squid wie in Abschnitt 33.3, „Starten von Squid“ gezeigt. Sehen Sie sich die Squid-Protokolle unter /var/log/squid/access.log an, um zu überprüfen, ob alles ordnungsgemäß funktioniert. Führen Sie eine Port-Absuche auf dem Computer von einem Computer außerhalb Ihres Netzwerks durch, um zu überprüfen, ob alle Ports korrekt konfiguriert sind. Nur die Webdienste (Port 80) sollten verfügbar sein. Die Befehlssyntax für das Scannen der Ports mit nmap lautet nmap-O IP_address.

33.6 cachemgr.cgi

Der Cache-Manager (cachemgr.cgi) ist ein CGI-Dienstprogramm für die Anzeige der Statistiken zur Arbeitsspeichernutzung eines laufenden Squid-Prozesses. Außerdem bietet er eine bequemere Methode zur Verwaltung des Cache und zur Anzeige der Statistiken ohne Anmeldung beim Server.

33.6.1 Einrichtung

Zunächst muss ein Webserver in Ihrem System ausgeführt werden. Konfigurieren Sie Apache, wie in Kapitel 31, Der HTTP-Server Apache beschrieben. Um zu überprüfen, ob Apache bereits ausgeführt wird, geben Sie als root den Befehl rcapachestatus ein. Wenn eine Meldung der folgenden Art angezeigt wird:

Checking for service httpd: OK 
Server uptime: 1 day 18 hours 29 minutes 39 seconds

wird Apache auf dem Rechner angezeigt. Ansonsten starten Sie Apache mit dem Kommando rcapace start mit den SUSE Linux Enterprise Server-Standardeinstellungen. Der letzte Schritt besteht darin, die Datei cachemgr.cgi in das Apache-Verzeichnis cgi-bin zu kopieren. Für 32-Bit funktioniert das wie folgt:

cp /usr/lib/squid/cachemgr.cgi /srv/www/cgi-bin/

In einer 64-Bit-Umgebung befindet sich die Datei cachemgr.cgi unter /usr/lib64/squid/ und das Kommando, sie in das Apache-Verzeichnis zu kopieren, lautet:

cp /usr/lib64/squid/cachemgr.cgi /srv/www/cgi-bin/

33.6.2 Cache-Manager-ACLs in /etc/squid/squid.conf

Es gibt einige Standardeinstellungen in der Originaldatei, die für den Cache-Manager erforderlich sind. Zuerst werden zwei ACLs definiert. Anschließend verwenden die http_access-Optionen diese ACLs, um Zugriff vom CGI-Script auf Squid zu gewähren. Die erste ACL ist die wichtigste, da der Cache-Manager versucht, über das cache_object-Protokoll mit Squid zu kommunizieren.

acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255

Folgende Regeln gewähren Apache Zugriffsrechte auf Squid:

http_access allow manager localhost
http_access deny manager

Diese Regeln setzen voraus, dass der Webserver und Squid auf demselben Computer ausgeführt werden. Wenn die Kommunikation zwischen Cache-Manager und Squid von dem Webserver auf einem anderen Computer ihren Ausgang nimmt, müssen Sie eine zusätzliche ACL aufnehmen, wie in Beispiel 33.2, „Zugriffsregeln“ beschrieben.

Beispiel 33.2: Zugriffsregeln
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl webserver src 192.168.1.7/255.255.255.255 # webserver IP

Fügen Sie dann die Regeln in Beispiel 33.3, „Zugriffsregeln“ hinzu, um den Zugriff vom Webserver zu gestatten.

Beispiel 33.3: Zugriffsregeln
http_access allow manager localhost
http_access allow manager webserver
http_access deny manager

Konfigurieren Sie ein Passwort für den Manager für den Zugriff auf weitere Optionen, wie das Schließen des Cache über entfernten Zugriff oder die Anzeige weiterer Informationen zum Cache. Konfigurieren Sie hierfür den Eintrag cachemgr_passwd mit einem Passwort für den Manager und der Liste der anzuzeigenden Optionen. Diese Liste wird als Teil des Eintragskommentars in /etc/squid/squid.conf angezeigt.

Starten Sie Squid nach jeder Änderung der Konfigurationsdatei neu. Verwenden Sie hierfür einfach rcsquidreload.

33.6.3 Anzeige der Statistiken

Rufen Sie die entsprechende Website auf: http://webserver.example.org/cgi-bin/cachemgr.cgi. Drücken Sie continue (Fortsetzen) und blättern Sie durch die verschiedenen Statistiken.

33.7 squidGuard

In diesem Abschnitt wird keine umfassende Konfiguration von squidGuard erläutert. Er gibt lediglich eine Einführung und einige Hinweise zur Verwendung. Eine Behandlung tiefer gehender Konfigurationsfragen finden Sie auf der squidGuard-Website unter http://www.squidguard.org.

squidGuard ist ein kostenloses (GPL), flexibles und schnelles Filter-, Umleitungs- und Zugriffssteuerungs-Plugin für Squid. Damit können Sie mehrere Zugriffsregeln mit verschiedenen Einschränkungen für verschiedene Benutzergruppen in einem Squid-Cache erstellen. squidGuard verwendet die Standard-Umleitungsschnittstelle von Squid und bietet folgende Möglichkeiten:

  • Einschränken des Webzugriffs für einige Benutzer auf eine Liste akzeptierter oder gut bekannter Webserver bzw. URLs.

  • Blockieren des Zugriffs auf einige gelistete oder in einer Blacklist stehende Webserver bzw. URLs für einige Benutzer.

  • Blockieren des Zugriffs bestimmter Benutzer auf URLs, die reguläre Ausdrücke oder Wörter aus einer entsprechenden Liste enthalten.

  • Umleiten blockierter URLs an eine „intelligente“ CGI-basierte Informationsseite.

  • Umleiten nicht registrierter Benutzer zu einem Registrierungsformular.

  • Umleiten von Bannern in eine leere GIF-Datei.

  • Verwenden verschiedener Zugriffsregeln je nach Tageszeit, Wochentag, Datum usw.

  • Verwenden verschiedener Regeln für verschiedene Benutzergruppen.

squidGuard und Squid können nicht zu folgenden Zwecken eingesetzt werden:

  • Bearbeiten, Filtern oder Zensieren von Text in Dokumenten.

  • Bearbeiten, Filtern oder Zensieren von in HTML eingebetteten Skriptsprachen, wie JavaScript oder VBscript.

Vor der Verwendung muss squidGuard zunächst installiert werden. Geben Sie eine Datei mit der Minimalkonfiguration als /etc/squidguard.conf an. Konfigurationsbeispiele finden Sie unter http://www.squidguard.org/Doc/examples.html. Später können Sie mit komplizierteren Konfigurationseinstellungen experimentieren.

Erstellen Sie als Nächstes eine Dummy-Seite mit „Zugriff verweigert“ oder eine mehr oder weniger komplexe CGI-Seite, um Squid umzuleiten, wenn der Client eine Website anfordert, die auf der schwarzen Liste steht. Die Verwendung von Apache wird dringend empfohlen.

Konfigurieren Sie nun Squid für die Verwendung von squidGuard. Verwenden Sie folgenden Eintrag in der Datei /etc/squid/squid.conf:

redirect_program /usr/bin/squidGuard

Eine weitere Option, redirect_children, konfiguriert die Zahl von redirect-Prozessen (in diesem Fall squidGuard), die auf dem Rechner ausgeführt werden. Je mehr Prozesse Sie angeben, desto mehr RAM ist erforderlich. Versuchen Sie zunächst niedrige Zahlen (z. B. 4).

redirect_children 4

Abschließend kann Squid die neue Konfiguration laden, indem Sie rcsquid reload ausführen. Testen Sie nun Ihre Einstellungen mit einem Browser.

33.8 Erstellung von Cache-Berichten mit Calamaris

Calamaris ist ein Perl-Skript, mit dem Berichte über die Cache-Aktivität im ASCII- oder HTML-Format erstellt werden können. Es arbeitet mit nativen Squid-Zugriffsprotokolldateien. Die Calamaris-Homepage befindet sich unter http://Calamaris.Cord.de/. Dieses Werkzeug gehört nicht zum standardmäßigen Installationsumfang von SUSE Linux Enterprise Server. Zum Verwenden installieren Sie das Paket calamaris.

Melden Sie sich als root an und geben Sie cat access.log | calamaris options > reportfile ein. Beim Piping mehrerer Protokolldateien ist darauf zu achten, dass die Protokolldateien chronologisch (die ältesten Dateien zuerst) geordnet sind. Im Folgenden finden Sie einige Optionen des Programms:

Tipp
Tipp: Shell und Dateisequenzen

Wenn Sie über mehrere ähnliche Dateien verfügen, z. B. access.log.1, access.log.2 usw., würde die Standard-Bash-Shell diese Dateien beim Auflisten von access.log nicht in der Zahlensequenz sortieren.*. Um dieses Problem zu lösen, können Sie die Syntax access.log{1..42} verwenden, die eine Liste von Dateien, erweitert durch Nummern von 1 bis 42, generiert.

-a

Ausgabe aller verfügbaren Berichte

-w

Ausgabe als HTML-Bericht

-l

Einschließen einer Meldung oder eines Logos in den Berichtsheader

Weitere Informationen zu den verschiedenen Optionen finden Sie auf der man-Seite des Programms (mancalamaris.

Typisches Beispiel:

cat access.log.{10..1} access.log | calamaris -a -w \ 
> /usr/local/httpd/htdocs/Squid/squidreport.html

Dadurch wird der Bericht im Verzeichnis des Webservers gespeichert. Zur Anzeige des Berichts ist Apache erforderlich.

33.9 Weiterführende Informationen

Besuchen Sie die Squid-Homepage unter http://www.squid-cache.org/. Hier finden Sie das Squid-Benutzerhandbuch und eine umfassende Sammlung mit FAQ zu Squid.

Nach der Installation ist eine kleine HOWTO-Datei zu transparenten Proxies in howtoenh verfügbar: /usr/share/doc/howto/en/txt/TransparentProxy.gz. Außerdem sind Mailinglisten für Squid unter squid-users@squid-cache.org verfügbar. Das zugehörige Archiv finden Sie unter http://www.squid-cache.org/mail-archive/squid-users/.

Diese Seite drucken