Gilt für SUSE Linux Enterprise Server 12 SP5

34 Der Proxyserver Squid #

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. Ein Vorteil 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:

Verteilung der Last auf mehrere miteinander kommunizierende Hierarchien von Proxyservern
Definition strenger Zugriffssteuerungslisten für alle Clients, die auf den Proxy zugreifen
Zulassen oder Verweigern des Zugriffs auf bestimmte Webseiten mithilfe anderer Anwendungen
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 das News-Protokoll oder Video-Konferenzen-Protokolle. Da Squid nur das UDP-Protokoll für die Bereitstellung von Kommunikation zwischen verschiedenen Caches unterstützt, werden zahlreiche Multimedia-Programme nicht unterstützt.

34.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.

34.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 die Firewall-Konfiguration eine DMZ enthält, sollte der Proxy in dieser Zone betrieben werden. Unter Abschnitt 34.6, „Konfigurieren eines transparenten Proxy“ wird beschrieben, wie Sie einen transparenten Proxy implementieren. Dadurch wird die Konfiguration der Clients erleichtert, da sie in diesem Fall keine Informationen zum Proxy benötigen.

34.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 erhöht sich, ein Objekt aus dem lokalen Netzwerk abrufen zu können. 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 anfordern kann.

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 Subnetz 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 Anfordern der Objekte zu finden, sendet ein Cache eine ICP-Anforderung an alle gleichgeordneten Proxys. Die gleichgeordneten Proxys beantworten diese Anforderungen über ICP-Antworten. Wenn das Objekt erkannt wurde, verwenden sie einen HIT-Code, wenn nicht, einen MISS-Code.

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 zufriedenstellenden Antworten eingehen, wird die Anforderung an den übergeordneten Cache gesendet.

Anmerkung: Wie vermeidet Squid die Verdoppelung von Objekten?

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.

34.1.3 Caching von Internetobjekten #

Viele im Netzwerk verfügbaren Objekte sind nicht statisch, wie beispielsweise dynamisch generierte Seiten und TLS/SSL-verschlüsselte Inhalte. Derartige Objekte werden nicht im Cache gespeichert, da sie sich bei jedem Zugriff ändern.

Um zu bestimmen, wie lange Objekte im Cache gespeichert werden sollen, wird Objekten einer von mehreren Status 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, können ebenfalls verwendet werden.

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

34.2 Systemanforderungen #

Die Systemanforderungen hängen weitgehend von der maximalen Netzwerkauslastung ab, die das System tragen muss. Prüfen Sie daher die Belastungsspitzen, da diese mehr als das Vierfache des Tagesdurchschnitts betragen können. Im Zweifelsfall ist es vorzuziehen, die Systemanforderungen zu hoch einzuschätzen. Wenn Squid an der Grenze seiner Leistungsfähigkeit arbeitet, kann es zu erheblichen Einbußen in der Qualität des Diensts führen. Die folgenden Abschnitte widmen sich den einzelnen Systemfaktoren in der Reihenfolge ihrer Wichtigkeit:

RAM-Größe
CPU-Geschwindigkeit/physische CPU-Cores
Größe des Festplatten-Cache
Festplatten/SSDs und ihre Architektur

34.2.1 RAM #

Der von Squid benötigte Arbeitsspeicher (RAM) steht in direktem Verhältnis zur Anzahl der Objekte im Cache. RAM ist wesentlich schneller als eine Festplatte/SSD. Daher ist es sehr wichtig, dass genügend Arbeitsspeicher für den Squid-Vorgang zur Verfügung steht, da die Systemleistung erheblich eingeschränkt ist, wenn die Swap-Festplatte verwendet wird.

Außerdem speichert Squid Cache-Objekt-Bezüge und häufig angeforderte Objekte im Hauptspeicher, um das Abrufen dieser Daten zu beschleunigen. 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.

34.2.2 Prozessor #

Squid ist so eingestellt, dass es am besten mit niedrigeren Prozessor-Core-Zahlen arbeitet (4–8 physische Cores), wobei jeder höchste Leistung bietet. Technologien, die virtuelle Cores bereitstellen, wie Hyperthreading, können sich negativ auf die Leistung auswirken.

Um mehrere CPU-Cores am besten zu nutzen, ist es notwendig, mehrere Worker-Threads einzurichten, die in verschiedene Caching-Geräte schreiben. Standardmäßig ist die Unterstützung mehrerer Cores deaktiviert.

34.2.3 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 mehr als 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 128 KB/s. Wenn dieser Datenverkehr vollständig im Cache gespeichert wird, ergeben sich in einer Stunde 460 MB. Bei der Annahme, dass dieser Datenverkehr in nur 8 Arbeitsstunden generiert wird, würden 3,6 GB an einem einzigen Tag erreicht werden. Da in der Regel 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.

34.2.4 Festplatten-/SSD-Architektur #

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) oder random read performance (Zufallsleseleistung) beschrieben – gemessen in Millisekunden. Da die Datenblöcke, die Squid von der Festplatte/SSD liest oder auf die Festplatte/SSD schreibt, tendenziell eher klein sind, ist die Zugriffszeit/Leseleistung der Festplatte/SSD entscheidender als ihr Datendurchsatz.

Für die Verwendung als Proxy sind Festplatten mit hoher Rotationsgeschwindigkeit oder SSDs die beste Wahl. Bei der Verwendung von Festplatten kann es besser sein, mehrere kleinere Festplatten zu verwenden. Dabei sollte jede ein einzelnes Cache-Verzeichnis aufweisen, um übermäßige Lesezeiten zu vermeiden.

Die Verwendung von RAID-Systemen bietet eine erhöhte Zuverlässigkeit, bedeutet jedoch Einschränkungen bei der Geschwindigkeit. Vermeiden Sie jedoch aus Leistungsgründen (Software-)RAID5 und ähnliche Einstellungen.

Die Wahl des Dateisystems ist in der Regel nicht entscheidend. Jedoch kann mit der Einhängeoption noatime die Leistung verbessert werden. Squid stellt eigene Zeitstempel bereit und erfordert daher nicht, dass das Dateisystem die Zugriffszeiten überwacht.

34.3 Grundlegende Verwendung von Squid #

Installieren Sie das Paket, falls es nicht bereits installiert ist squid bereitgestellt. squid gehört nicht zu den Paketen, die standardmäßig auf SUSE Linux Enterprise Server installiert werden.

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 Nameserver angegeben werden, da Squid nicht startet, wenn kein DNS-Server in /etc/resolv.conf gefunden wird.

34.3.1 Starten von Squid #

Verwenden Sie zum Starten von Squid Folgendes:

tux > sudo systemctl start squid

Wenn Sie möchten, dass Squid zusammen mit dem System gestartet wird, aktivieren Sie den Dienst mit systemctl enable squid.

34.3.2 Überprüfen, ob Squid ausgeführt wird #

Wählen Sie zum Überprüfen, ob Squid ausgeführt wird, eine der folgenden Optionen:

Mithilfe von systemctl:
```
tux > systemctl status squid
```
Die Ausgabe dieses Kommandos sollte Folgendes für Squid anzeigen: loaded (geladen) und active (running) (aktiv (wird ausgeführt)).
Mithilfe von Squid:
```
tux > sudo squid -k check | echo $?
```
Die Ausgabe dieses Befehls sollte 0 lauten, kann jedoch zusätzliche Warnungen oder Meldungen umfassen.

Um die Funktionsfähigkeit von Squid im lokalen System zu testen, wählen Sie eine der folgenden Optionen:

Zum Testen können Sie squidclient verwenden, ein Kommandozeilenwerkzeug, das die Antwort auf eine Webanforderung ausgeben kann, ähnlich wie wget oder curl.

Anders als diese Werkzeuge verbindet squidclient sich automatisch mit dem Standard-Proxy-Setup von Squid, localhost:3128. Wenn Sie jedoch die Konfiguration von Squid geändert haben, müssen Sie squidclient mithilfe von Kommandozeilenoptionen so konfigurieren, dass es andere Einstellungen verwendet. Weitere Informationen erhalten Sie mit squidclient --help.

Beispiel 34.1: Eine Anforderung mit squidclient #

tux > squidclient http://www.example.org
HTTP/1.1 200 OK
Cache-Control: max-age=604800
Content-Type: text/html
Date: Fri, 22 Jun 2016 12:00:00 GMT
Expires: Fri, 29 Jun 2016 12:00:00 GMT
Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT
Server: ECS (iad/182A)
Vary: Accept-Encoding
X-Cache: HIT
x-ec-custom-error: 1
Content-Length: 1270
X-Cache: MISS from moon1
X-Cache-Lookup: MISS from moon:3128
Via: 1.1 moon (squid/3.5.16)2
Connection: close

<!doctype html>
<html>
<head>
    <title>Example Domain</title>
[...]
</body>
</html>

Die in Beispiel 34.1, „Eine Anforderung mit squidclient“ angezeigte Ausgabe kann in zwei Teile aufgeteilt werden:

Die Protokoll-Header der Antwort: die Zeilen vor der leeren Zeile.
Der eigentliche Inhalt der Antwort: die Zeilen nach der leeren Zeile.

Um zu überprüfen, ob Squid verwendet wird, sehen Sie sich im Header die ausgewählten Zeilen an:

Der Wert X-Cache im Header gibt an, dass das angeforderte Dokument nicht im Squid-Cache (MISS) des Computers moon gespeichert war.

Das Beispiel oben enthält zwei X-Cache-Zeilen. Sie können den ersten X-Cache-Header ignorieren. Er wird von der internen Caching-Software erstellt, die vom Webserver stammt.

Der Wert Via im Header gibt die HTTP-Version, den Namen des Computers und die verwendete Squid-Version an.

Mithilfe eines Browsers: Richten Sie localhost als Proxy und 3128 als Port ein. Sie können dann eine Seite laden und die Antwort-Header in der Kontrollleiste Netzwerk des Inspektors oder der Entwicklertools des Browsers überprüfen. Die Header sollten ähnlich wie in Beispiel 34.1, „Eine Anforderung mit squidclient“ reproduziert werden.

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. Legen Sie daher ACLs (Access Control Lists = Zugriffssteuerungslisten) fest, die den Zugriff auf den Proxy steuern. Nach Bearbeiten der Konfigurationsdatei muss Squid neu geladen oder neu gestartet werden. Weitere Informationen zu ACLs finden Sie in Abschnitt 34.5.2, „Optionen für die Zugriffssteuerung“.

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.

34.3.3 Stoppen, Neuladen und Neustarten von Squid #

Zum Neuladen von Squid stehen die folgenden Verfahren zur Auswahl:

Mithilfe von systemctl:

root # systemctl reload squid

Alternativ:

root # systemctl restart squid

Verwenden von YaST:
Klicken Sie im Squid-Modul auf die Schaltfläche Einstellungen jetzt speichern und Squid neu starten Schaltfläche.

Zum Anhalten von Squid stehen die folgenden Verfahren zur Auswahl:

Mithilfe von systemctl:
```
root # systemctl stop squid
```
Verwenden von YaST
Klicken Sie im Squid-Modul auf die Schaltfläche Squid jetzt stoppen Schaltfläche.

Das Herunterfahren von Squid kann einige Zeit dauern, da Squid bis zu eine halbe Minute wartet, bis die Verbindungen zu den Clients unterbrochen und die Daten auf die Festplatte geschrieben werden (siehe Option shutdown_lifetime in /etc/squid/squid.conf),

Warnung: Beenden von Squid

Das Beenden von Squid mit kill oder killall kann den Cache beschädigen. Damit Squid neu gestartet werden kann, müssen beschädigte Caches gelöscht werden.

34.3.4 Entfernen von Squid #

Durch das Entfernen von Squid aus dem System werden die Cache-Hierarchie und die Protokolldateien nicht entfernt. Um diese zu entfernen, müssen Sie das Verzeichnis /var/cache/squid manuell löschen.

34.3.5 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 26.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.

Fügen Sie anschließend den lokalen DNS-Server in der Datei /etc/resolv.conf hinzu. Verwenden Sie die IP-Adresse 127.0.0.1 für localhost. Auf diese Weise kann Squid immer den lokalen Nameserver finden, wenn er gestartet wird.

Um den Zugriff auf den Nameserver des Anbieters zu ermöglichen, geben Sie ihn zusammen mit seiner IP-Adresse in der Konfigurationsdatei /etc/named.conf unter forwarders an. Mit dynamischem DNS kann dies automatisch während des Verbindungsaufbaus erreicht werden. Setzen Sie hierzu die sysconfig-Variable NETCONFIG_DNS_POLICY mit dem YaST-sysconfig-Editor auf autobereitgestellt.

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 der Datei /etc/resolv.conf, wie unter Dynamisches DNS beschrieben, angeben. Außerdem muss der statische Nameserver des Anbieters zusammen mit seiner IP-Adresse manuell in der Datei /etc/named.conf unter Forwarders angegeben werden.

Tipp: DNS und Firewall

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

34.4 Das YaST-Squid-Modul #

Das YaST-Squid-Modul enthält die folgenden Registerkarten:

Start: Gibt an, wie Squid gestartet wird und welcher Firewall-Port auf welchen Schnittstellen geöffnet ist.
HTTP-Ports: Definiert alle Ports, die Squid auf HTTP-Anforderungen von Clients überwacht.
Aktualisierungsschemata: Gibt an, wie Squid die Objekte im Cache behandelt.
Cache-Einstellungen: Definiert Einstellungen für den Cache-Speicher, die maximale und minimale Objektgröße und vieles mehr.
Cache-Verzeichnis: Definiert das übergeordnete Verzeichnis, in dem Squid alle Cache-Swap-Dateien speichert.
Zugriffssteuerung: Steuert den Zugriff auf den Squid-Server mithilfe von ACL-Gruppen.
Protokollierung und Zeitüberschreitung: Definiert die Pfade zu den Protokolldateien für Zugriff, Cache und Cache-Speicher sowie die Zeitüberschreitung für die Verbindungen und die Client-Lebensdauer.
Sonstige: Legt die Sprache und die Email-Adresse des Administrators fest.

34.5 Die Squid-Konfigurationsdatei #

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.

Viele Einträge sind kommentiert und beginnen deshalb mit dem Kommentarzeichen #. Die relevanten Spezifikationen finden Sie am Ende der Zeile. Die angegebenen Werte entsprechen in der Regel den Standardwerten, daher hat das Entfernen der Kommentarzeichen ohne Ändern der Parameter in der Regel keine Auswirkungen. Lassen Sie die kommentierten Zeilen nach Möglichkeit unverändert und geben Sie die Optionen zusammen mit den geänderten Werten in der Zeile darunter ein. Auf diese Weise können die Standardwerte problemlos wiederhergestellt und mit den Änderungen verglichen werden.

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.

Manchmal werden Squid-Optionen hinzugefügt, entfernt oder geändert. Daher kann Squid möglicherweise aufhören, ordnungsgemäß zu funktionieren, wenn Sie die alte squid.conf-Datei verwenden.

34.5.1 Allgemeine Konfigurationsoptionen #

Nachfolgend finden Sie eine Liste mit einer Auswahl an Konfigurationsoptionen für Squid. Die Liste ist nicht vollständig. Das Squid-Paket enthält eine vollständige Liste mit einfacher Veranschaulichung in der Datei /etc/squid/squid.conf.documented.

http_port PORT

Dies ist der Port, den Squid auf Client-Anforderungen überwacht. Der Standardport ist 3128, 8080 wird jedoch ebenfalls häufig verwendet.

cache_peer HOSTNAME TYP PROXY-PORT ICP-PORT

Mit dieser Option kann ein Netzwerk mit Caches erstellt werden, die zusammen arbeiten. Der Cache-Peer ist ein Computer, der auch ein Netzwerk-Cache hostet und in einer Beziehung zu Ihrem eigenen steht. Der Typ der Beziehung wird als TYP angegeben. Der Typ kann entweder parent oder sibling sein.

Geben Sie als HOSTNAME den Namen oder die IP-Adresse des verwendeten Proxy an. Geben Sie für PROXY-PORT die Portnummer zur Verwendung in einem Browser an (in der Regel 8080). Legen Sie für ICP-PORT den Wert 7 oder, wenn der ICP-Port des übergeordneten Proxy nicht bekannt ist und seine Verwendung für den Anbieter nicht wichtig ist, den Wert 0 fest.

Damit Squid sich wie ein Webbrowser verhält und nicht wie ein Proxy, verbieten Sie die Verwendung des ICP-Protokolls. Sie können dies verbieten, indem Sie die Optionen default und no-query anhängen.

cache_mem GRÖSSE

Diese Option 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 SPEICHERTYP CACHE-VERZEICHNIS CACHE-GRÖSSE EBENE-1-VERZEICHNISSE EBENE-2-VERZEICHNISSE

Die Option cache_dir legt das Verzeichnis für den Festplatten-Cache fest. In der Standardkonfiguration auf SUSE Linux Enterprise Server erstellt Squid keinen Festplatten-Cache.

Der Platzhalter SPEICHERTYP kann einen der folgenden Werte haben:

Verzeichnisbasierte Speichertypen: ufs, aufs (Standard), diskd. Alle drei Typen sind Variationen des Speicherformats ufs. Dabei wird ufs als Teil des Squid-Core-Threads ausgeführt, aufs wird in einem separaten Thread ausgeführt und diskd verwendet einen separaten Prozess. Dies bedeutet, dass die letzten beiden Typen das Blockieren von Squid aufgrund von Datenträger-E/A vermeiden.
Datenbankbasierte Speichersysteme: rock. Dieses Speicherformat basiert auf einer einzelnen Datenbankdatei, in der jedes Objekt eine oder mehrere Arbeitsspeichereinheiten einer festen Größe („Slots“) einnimmt.

Im Folgenden werden nur die Parameter für Speichertypen beschrieben, die auf ufs basieren. rock weist etwas andere Parameter auf.

Der Parameter CACHE-VERZEICHNIS steht für das Verzeichnis des Festplatten-Cache. Standardmäßig lautet dieses /var/cache/squid. CACHE-GRÖSSE ist die maximale Größe dieses Verzeichnisses in Megabyte. Der festgelegte Standardwert ist 100 MB. Legen Sie eine Größe zwischen 50 % und maximal 80 % des verfügbaren Speicherplatzes fest.

Die letzten zwei Werte EBENE-1-VERZEICHNISSE und EBENE-2-VERZEICHNISSE geben an, wie viele Unterverzeichnisse im CACHE-VERZEICHNIS erstellt werden. Standardmäßig werden 16 Unterverzeichnisse auf der ersten Ebene unter CACHE-VERZEICHNIS und 256 jeweils innerhalb dieser Ebenen erstellt. Diese Werte sollten nur nach reiflicher Überlegung erhöht werden, da zu viele Verzeichnisse zu Leistungsproblemen führen können.

Wenn ein Cache von mehreren Datenträgern gemeinsam verwendet wird, müssen Sie mehrere cache_dir-Zeilen angeben.

cache_access_log PROTOKOLLDATEI , cache_log PROTOKOLLDATEI , cache_store_log PROTOKOLLDATEI

Diese drei Optionen geben die Pfade an, in denen Squid alle Aktionen protokolliert. In der Regel muss hier nichts geändert werden. Bei hoher Auslastung von Squid kann es sinnvoll sein, Cache und Protokolldateien auf mehrere Datenträger zu verteilen.

client_netmask NETZMASKE

Diese Option ermöglicht die Maskierung von IP-Adressen des Client in der Protokolldatei, indem eine Teilnetzmaske angewendet wird. Um beispielsweise für die letzte Zahl der IP-Adresse 0 festzulegen, geben Sie 255.255.255.0 an.

ftp_user E-MAIL

Diese Option ermöglicht die Einstellung des Passworts, das Squid für die anonyme FTP-Anmeldung verwenden soll. Geben Sie hier eine gültige E-Mail-Adresse ein, da manche FTP-Server diese auf Gültigkeit überprüfen.

cache_mgr E-MAIL

Bei unerwartetem Absturz sendet Squid eine Nachricht an diese E-Mail-Adresse. Der Standardwert ist webmaster.

logfile_rotate WERT

Wenn Sie squid -k rotate ausführen, kann Squid ein Rotationssystem für 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 10. Hierdurch werden Protokolldateien mit den Nummern 0 bis 9 rotiert.

Auf SUSE Linux Enterprise Server erfolgt die Rotation der Protokolldateien jedoch mithilfe von logrotate und der Konfigurationsdatei /etc/logrotate.d/squid automatisch.

append_domain DOMÄNE

Verwenden Sie append_domain, um anzugeben, welche Domäne automatisch angefügt wird, wenn keine angegeben wurde. In der Regel wird hier die eigene Domäne angegeben, sodass bei der Angabe von www im Browser ein Zugriff auf Ihren eigenen Webserver erfolgt.

forwarded_for STATUS

Ist für diese Option on festgelegt, wird eine Zeile wie die folgende zum Header hinzugefügt:

X-Forwarded-For: 192.168.0.1

Wenn Sie für diese Option off festlegen, entfernt Squid die IP-Adresse und den Systemnamen des Client aus den HTTP-Anforderungen.

negative_ttl ZEIT , negative_dns_ttl ZEIT

Sind diese Optionen festgelegt, speichert Squid manche Fehlertypen im Cache, wie beispielsweise 404-Antworten. Squid lässt dann keine neuen Anforderungen mehr zu, selbst wenn die Ressource verfügbar wäre.

Standardmäßig sind für negative_ttl der Wert 0 und für negative_dns_ttl der Wert 1 minutes festgelegt. Dies bedeutet, dass negative Antworten auf Webanforderungen standardmäßig nicht im Cache gespeichert werden und negative Antworten auf DNS-Anforderungen für eine Minute im Cache gespeichert werden.

never_direct allow ACL-NAME

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

34.5.2 Optionen für die Zugriffssteuerung #

Squid bietet ein detailliertes System für die Steuerung des Zugriffs auf den Proxy. Diese ACLs (Access Control Lists = Zugriffssteuerungslisten) sind 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 passiert nur dann, wenn eine entsprechende http_access-Regel vorhanden ist.

Die Syntax für die Option acl lautet:

acl ACL_NAME TYPE DATA

Die Platzhalter innerhalb dieser Syntax stehen für Folgendes:

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.

Sollen Regeln in das YaST-Squid-Modul eingefügt werden, öffnen Sie das Modul und klicken Sie auf die Registerkarte Zugriffssteuerung. Klicken Sie unter der Liste der ACL-Gruppen auf Hinzufügen und geben Sie den Namen Ihrer Regel, den Typ und die zugehörigen Parameter ein.

Weitere Informationen zu den Typen von ACL-Regeln finden Sie in der Squid-Dokumentation unter http://www.squid-cache.org/Versions/v3/3.5/cfgman/acl.html.

Beispiel 34.2: Definieren von ACL-Regeln #

acl mysurfers srcdomain .example.com 1
acl teachers src 192.168.1.0/255.255.255.0 2
acl students src 192.168.7.0-192.168.9.0/255.255.255.0 3
acl lunch time MTWHF 12:00-15:00 4

1	Diese ACL legt fest, dass `mysurfers` alle Benutzer sind, die von `.example.com` kommen (wie durch Reverse-Lookup für die IP bestimmt wurde).
2	Diese ACL legt fest, dass `teachers` die Benutzer von Computern sind, deren IP-Adressen mit `192.168.1.` beginnen.
3	Diese ACL legt fest, dass `students` die Benutzer von Computern sind, deren IP-Adressen mit `192.168.7.`, `192.168.8.` oder `192.168.9.` starten.
4	Diese ACL legt fest, dass `lunch` eine Zeit an den Tagen Montag, Dienstag, ... Freitag zwischen 12 und 15 Uhr ist.

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 festgelegt werden. localhost und all wurden bereits oben festgelegt. Sie können den Zugriff dafür verweigern oder erlauben mit deny bzw. allow. 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

Geben Sie für eine bessere Lesbarkeit in der Konfigurationsdatei /etc/squid/squid.conf alle http_access-Optionen in einem Block an.

url_rewrite_program PFAD

Geben Sie mit dieser Optionen einen URL-Rewriter an. Dies kann beispielsweise squidGuard sein (/usr/sbin/squidGuard), der das Blockieren unerwünschter URLs ermöglicht. Damit kann der Internetzugriff individuell für verschiedene Benutzergruppen mithilfe von Proxy-Authentifizierung und entsprechenden ACLs gesteuert werden.

Weitere Informationen zu squidGuard finden Sie in Abschnitt 34.8, „squidGuard“.

auth_param basic program PFAD

Wenn Benutzer auf dem Proxy authentifiziert werden müssen, geben Sie ein geeignetes Programm an, beispielsweise /usr/sbin/pam_auth. Beim ersten Ausführen von pam_auth wird ein Anmeldefenster geöffnet, in dem der Benutzer den Benutzernamen und das Passwort eingeben muss. Außerdem ist 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

Wird in der Option acl proxy_auth der Wert REQUIRED verwendet, bedeutet dies, dass alle gültigen Benutzernamen akzeptiert werden. REQUIRED kann auch durch eine Liste mit erlaubten Benutzernamen ersetzt werden.

ident_lookup_access allow ACL-NAME

Lassen Sie damit eine ident-Anforderung für alle Clients, die mit einer ACL des Typs src festgelegt sind, ausführen, um die Identität der einzelnen Benutzer zu ermitteln. Alternativ dazu (verwenden Sie dies für alle Clients) können Sie die vordefinierte ACL all als ACL-NAME anwenden.

Auf allen Clients, die durch ident_lookup_access abgedeckt sind, muss ein ident-Daemon ausgeführt werden. Unter Linux können Sie pidentd (package pidentd ) als ident-Daemon verwenden. Für andere Betriebssysteme ist in der Regel kostenlose Software verfügbar. Um sicherzustellen, dass nur Clients mit einem erfolgreichen ident-Lookup zulässig sind, definieren Sie eine entsprechende ACL:

acl identhosts ident REQUIRED

http_access allow identhosts
http_access deny all

Wird in der Option acl identhosts ident der Wert REQUIRED verwendet, bedeutet dies, dass alle gültigen Benutzernamen akzeptiert werden. REQUIRED kann auch durch eine Liste mit erlaubten Benutzernamen ersetzt werden.

Durch die Verwendung von ident kann die Zugriffszeit erheblich reduziert werden, da die ident-Lookups für jede Anforderung wiederholt werden.

34.6 Konfigurieren eines transparenten Proxy #

In der Regel arbeiten Sie folgendermaßen mit Proxyservern: Der Webbrowser sendet Anforderungen an einen bestimmten Port des Proxyservers und der Proxy liefert immer diese erforderlichen Objekte, unabhängig davon, ob sie sich im Cache befinden oder nicht. In manchen Fällen ist die Verwendung des transparenten Proxy-Modus von Squid empfehlenswert:

Wenn aus Sicherheitsgründen alle Clients einen Proxy für den Zugriff auf das Internet verwenden sollten.
Wenn alle Clients einen Proxy verwenden müssen, unabhängig davon, ob sie sich dessen bewusst sind.
Wenn der Proxy in einem Netzwerk verschoben wird, die vorhandenen Clients jedoch ihre alte Konfiguration beibehalten müssen.

Ein transparenter Proxy fängt die Anforderungen des Webbrowsers ab und beantwortet sie, sodass der Webbrowser die angeforderten Seiten erhält, ohne dass bekannt ist, woher sie kommen. Wie der Name bereits andeutet, verläuft der gesamte Prozess für den Benutzer transparent.

Vorgehen 34.1: Squid als ein transparenter Proxy (Befehlszeile) #

Fügen Sie in der Datei /etc/squid/squid.conf in der Zeile mit der Option http_port den Parameter transparent hinzu:
```
http_port 3128 transparent
```
Starten Sie Squid neu:
```
tux > sudo systemctl restart squid
```
Richten Sie SuSEFirewall2 so ein, dass HTTP-Datenverkehr an den in http_proxy angegebenen Port umgeleitet wird (im Beispiel oben war dies Port 3128). Bearbeiten Sie hierzu die Konfigurationsdatei /etc/sysconfig/SuSEfirewall2.
In diesem Beispiel wird angenommen, dass Sie die folgenden Geräte verwenden:
- Auf das Internet zeigendes Gerät: FW_DEV_EXT="eth1"
- Auf das Netzwerk zeigendes Gerät: FW_DEV_INT="eth0"
Definieren Sie Ports und Dienste (siehe /etc/services) auf der Firewall, auf die von nicht verbürgten (externen) Netzwerken, wie beispielsweise dem Internet, zugegriffen wird. 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. Entfernen Sie andernfalls einfach domain aus dem obigen Eintrag und legen Sie für die folgende Option no fest:
```
FW_SERVICE_DNS="yes"
```
Die Option FW_REDIRECT ist sehr wichtig, da sie für das tatsächliche Umleiten des HTTP-Datenverkehrs auf einen bestimmten Port verwendet wird. In der Konfigurationsdatei wird die Syntax in einem Kommentar über der Option erläutert:
```
# 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
```
Das heißt:
1. Geben Sie die IP-Adresse und die Netzmaske der internen Netzwerke an, die auf die Proxy-Firewall zugreifen.
2. Geben Sie die IP-Adresse und die Netzmaske an, an die diese Clients ihre Anforderungen senden. Geben Sie bei Webbrowsern die Netzwerke 0/0 an. Dieser Platzhalter bedeutet „überallhin“.
3. Geben Sie den ursprünglichen Port an, an den diese Anforderungen gesendet werden.
4. Geben Sie den Port an, an den alle diese Anforderungen umgeleitet werden. In dem Beispiel unten werden Webdienste (Port 80) an den Proxy-Port (Port 3128) umgeleitet. Wenn mehr Netzwerke oder Dienste hinzugefügt werden sollen, trennen Sie diese durch ein Leerzeichen im entsprechenden Eintrag.
  Da Squid auch andere Protokolle als HTTP unterstützt, können Sie auch Anforderungen von anderen Ports zum Proxy umleiten. Beispielsweise können Sie auch Port 21 (FTP) und Port 443 (HTTPS oder SSL) umleiten.
Daher könnten Sie für eine Squid-Konfiguration das folgende Kommando verwenden:
```
FW_REDIRECT="192.168.0.0/16,0/0,tcp,80,3128"
```
Stellen Sie sicher, dass in der Konfigurationsdatei /etc/sysconfig/SuSEfirewall2 der Eintrag START_FW auf "yes" festgelegt ist.

Starten Sie SuSEFirewall2 neu:

tux > sudo systemctl restart SuSEfirewall2

Sehen Sie sich die Squid-Protokolle unter /var/log/squid/access.log an, um zu überprüfen, ob alles ordnungsgemäß funktioniert. Führen Sie einen Portscan 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. Um die Ports mit nmap zu scannen, verwenden Sie:
```
nmap -O IP_ADDRESS
```

Vorgehen 34.2: Squid als ein transparenter Proxy (YaST) #

Starten Sie das YaST-Squid-Modul:
1. Aktivieren Sie im Karteireiter Start die Option Firewall-Ports öffnen. Klicken Sie auf Firewall-Details, um die Schnittstellen auszuwählen, über die der Port geöffnet werden soll. Diese Option ist nur verfügbar, wenn die Firewall aktiviert ist.
2. Wählen Sie im Karteireiter HTTP-Ports die erste Zeile mit dem Port 3128 aus.
3. Klicken Sie auf die Schaltfläche Bearbeiten. Es öffnet sich ein kleines Fenster, in dem Sie den aktuellen HTTP-Port bearbeiten können. Wählen Sie Transparent aus.
4. Klicken Sie abschließend auf OK.
Konfigurieren Sie die Firewall-Einstellungen so, wie unter Schritt 3 in Prozedur 34.1, „Squid als ein transparenter Proxy (Befehlszeile)“ beschrieben.

34.7 Verwenden der Cache-Manager-CGI von Squid (`cachemgr.cgi`) #

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

Vorgehen 34.3: Einrichten von cachemgr.cgi #

Stellen Sie sicher, dass der Apache-Webserver auf Ihrem System ausgeführt wird. Konfigurieren Sie Apache, wie in Kapitel 32, Der HTTP-Server Apache beschrieben. Lesen Sie insbesondere Abschnitt 32.5, „Aktivieren von CGI-Skripten“. Um zu überprüfen, ob Apache bereits ausgeführt wird, verwenden Sie:
```
tux > sudo systemctl status apache2
```
Wenn inactive angezeigt wird, können Sie Apache mit den Standardeinstellungen von SUSE Linux Enterprise Server starten:
```
tux > sudo systemctl start apache2
```
Aktivieren Sie nun cachemgr.cgi in Apache. Erstellen Sie hierzu eine Konfigurationsdatei für ein ScriptAlias.
Erstellen Sie die Datei im Verzeichnis /etc/apache2/conf.d und nennen Sie sie cachemgr.conf. Fügen Sie Folgendes in der Datei hinzu:
```
ScriptAlias /squid/cgi-bin/ /usr/lib64/squid/

<Directory "/usr/lib64/squid/">
Options +ExecCGI
AddHandler cgi-script .cgi
Require host HOST_NAME
</Directory>
```
Ersetzen Sie HOSTNAME durch den Hostnamen des Computers, über den Sie auf cachemgr.cgi zugreifen möchten. Dies erlaubt es nur Ihrem Computer, auf cachemgr.cgi zuzugreifen. Um den Zugriff von allen Computern zu erlauben, verwenden Sie stattdessen Require all granted.
- Wenn Squid und Ihr Apache-Webserver auf demselben Computer ausgeführt werden, sollten keine Änderungen an /etc/squid/squid.conf notwendig sein. Überprüfen Sie jedoch, ob /etc/squid/squid.conf die folgenden Zeilen enthält:
```
  http_access allow manager localhost
  http_access deny manager
```
  Diese Zeilen erlauben Ihnen den Zugriff auf die Manager-Schnittstelle über Ihren eigenen Computer (localhost), jedoch nicht über andere Computer.
- Wenn Squid und Ihr Apache-Webserver auf verschiedenen Computern ausgeführt werden, müssen Sie zusätzliche Regeln hinzufügen, um den Zugriff über das CGI-Skript auf Squid zu erlauben. Geben Sie eine ACL für Ihren Server an (ersetzen Sie WEBSERVER-IP durch die IP-Adresse Ihres Webservers):
```
acl webserver src WEB_SERVER_IP/255.255.255.255
```
  Stellen Sie sicher, dass die folgenden Regeln in der Konfigurationsdatei enthalten sind. Verglichen mit der Standardkonfiguration ist nur die Regel in der Mitte neu. Jedoch ist die Sequenz wichtig.
```
http_access allow manager localhost
http_access allow manager webserver
http_access deny manager
```
(Optional) Optional können Sie ein oder mehrere Passwörter für cachemgr.cgi konfigurieren. Dies erlaubt auch den Zugriff auf weitere Aktionen, wie das Schließen des Cache per Fernzugriff oder das Anzeigen weiterer Informationen zum Cache. Konfigurieren Sie hierfür die Optionen cache_mgr und cachemgr_passwd mit einem oder mehreren Passwörtern für den Manager und einer Liste der erlaubten Aktionen.
Beispiel: Verwenden Sie die folgende Konfiguration, um explizit das Anzeigen der Indexseite, des Menüs und des 60-minütigen Durchschnitts der Zähler ohne Authentifizierung zu aktivieren, das Umschalten des Offline-Modus mithilfe des Passworts secretpassword zu aktivieren und alles andere vollständig zu deaktivieren:
```
cache_mgr user
cachemgr_passwd none index menu 60min
cachemgr_passwd secretpassword offline_toggle
cachemgr_passwd disable all
```
cache_mgr legt einen Benutzernamen fest. cache_mgr legt fest, welche Aktionen mit welchen Passwort erlaubt sind.
Die Schlüsselwörter none und disable haben besondere Eigenschaften: none entfernt die Notwendigkeit eines Passworts, disable inaktiviert die Funktion vollständig.
Die vollständige Liste der Aktionen finden Sie nach der Anmeldung bei cachemgr.cgi. Wie die Operation in der Konfigurationsdatei zu referenzieren ist, sehen Sie in der Zeichenkette nach &operation= in der URL der Aktionsseite. all ist ein besonderes Schlüsselwort und steht für alle Aktionen.
Laden Sie Squid und Apache neu, nachdem die Konfigurationsdatei geändert wurde:
```
tux > sudo systemctl reload squid
```
Um die Statistiken anzuzeigen, rufen Sie die Seite cachemgr.cgi auf, die Sie zuvor eingerichtet haben. Diese könnte beispielsweise http://webserver.example.org/squid/cgi-bin/cachemgr.cgi lauten.
Wählen Sie den richtigen Server und geben Sie, falls dies festgelegt wurde, den Benutzernamen und das Passwort ein. Klicken Sie dann auf Fortsetzen und blättern Sie durch die verschiedenen Statistiken.

34.8 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 Skripten, wie JavaScript.

Vorgehen 34.4: Einrichten von squidGuard #

Vor der Verwendung müssen Sie squidGuard installieren.
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 HTML-Seite mit „Zugriff verweigert“ oder eine CGI-Seite, zu der Squid umgeleitet werden kann, 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 zuerst niedrige Zahlen, beispielsweise 4:
```
redirect_children 4
```
Lassen Sie Squid abschließend die neue Konfiguration laden; führen Sie hierzu systemctl reload squid aus. Testen Sie nun Ihre Einstellungen mit einem Browser.

34.9 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://cord.de/calamaris-english. 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 Folgendes ein:

cat access1.log [access2.log access3.log] | calamaris OPTIONS > reportfile

Wenn Sie mehr als eine Protokolldatei verwenden, stellen Sie sicher, dass sie chronologisch geordnet sind, wobei ältere Dateien zuerst aufgelistet werden. Dies können Sie erreichen, indem Sie die Dateien eine nach der anderen wie im Beispiel oben auflisten oder indem Sie access{1..3}.log verwenden.

calamaris erfordert die folgenden Optionen:

-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.

34.10 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.

Außerdem sind Mailinglisten für Squid unter http://www.squid-cache.org/Support/mailing-lists.html verfügbar.