Das ist der Port, auf dem Squid auf Anfragen der Clients lauscht. Voreingestellt ist 3128, gebräuchlich ist auch 8080. Es ist möglich, hier mehrere Portnummern, durch Leerzeichen getrennt, anzugeben.

Hier kann man einen übergeordneten Proxy als „Parent“ eintragen, zum Beispiel wenn man den des Providers nutzen will. Als hostname trägt man den Namen bzw. die IP-Adresse des zu verwendenden Proxys und als type parent ein. Für proxy-port trägt man die Portnummer ein, die der Betreiber des Parent auch zur Verwendung im Browser angibt, meist 8080. Den icp-port kann man auf 7 oder 0 setzen, wenn man den ICP-Port des Parent nicht kennt und die Benutzung dieses Ports mit dem Provider nicht vereinbart wurde. Zusätzlich sollte man dann noch default und no-query nach den Portnummern angeben, um die Verwendung des ICP-Protokolls ganz zu unterbinden. Squid verhält sich dann gegenüber dem Proxy des Providers wie ein normaler Browser.

Dieser Eintrag gibt an, wie viel Arbeitsspeicher von Squid für das Cachen maximal verwendet wird. Voreingestellt sind 8 MB.

Der Eintrag cache_dir gibt das Verzeichnis an, in dem alle Objekte auf Platte abgelegt werden. Die Zahlen dahinter geben den maximal zu verwendenden Plattenplatz in „MB“ und die Anzahl der Verzeichnisse in erster und zweiter Ebene an. Den Parameter ufs sollte man unverändert lassen. Voreingestellt sind „100 MB“ Plattenplatz im Verzeichnis /var/cache/squid zu belegen und darin 16 Unterverzeichnisse anzulegen, die jeweils wiederum 256 Verzeichnisse enthalten. Bei Angabe des zu verwendenden Plattenplatzes sollte man genügend Reserven lassen, sinnvoll sind Werte zwischen 50 und maximal 80 Prozent des verfügbaren Platzes. Die beiden letzten Zahlen für die Anzahl der Verzeichnisse sollte man nur mit Vorsicht vergrößern, da zu viele Verzeichnisse auch wieder auf Kosten der Performance gehen können. Hat man mehrere Platten, auf die der Cache verteilt werden soll, kann man entsprechend viele cache_dir-Zeilen eintragen.

Pfadangabe für Protokoll-Dateien.

Pfadangabe für Protokoll-Dateien.

Pfadangabe für Protokoll-Dateien. Diese drei Einträge geben den Pfad zur Protokolldatei von Squid an. Normalerweise wird man daran nichts ändern. Wird der Squid stark beansprucht, kann es sinnvoll sein, den Cache und die Protokoll-Dateien auf verschiedene Platten zu legen.

Ändert man diesen Eintrag auf on, erhält man lesbare Protokoll-Dateien. Allerdings kommen manche Auswerteprogramme damit nicht zurecht.

Mit diesem Eintrag kann man die protokollierten IP-Adressen in den Protokoll-Dateien maskieren, um die Identität der Clients zu verbergen. Trägt man hier 255.255.255.0 ein, wird die letzte Stelle der IP-Adresse auf Null gesetzt.

Hiermit kann man das Passwort setzen, welches Squid für den anonymen FTP-Login verwenden soll. Es kann aber sinnvoll sein, hier eine gültige E-Mail-Adresse in der eigenen Domain anzugeben, da einige FTP-Server diese auf Gültigkeit überprüfen.

Eine E-Mail-Adresse, an die Squid eine Nachricht schickt, wenn er unerwartet abstürzt. Voreingestellt ist webmaster.

Squid ist in der Lage, die gesicherten Protokoll-Dateien zu rotieren, wenn man squid -k rotate aufruft. Die Dateien werden dabei, entsprechend der angegebenen Anzahl, durchnummeriert, und nach Erreichen des angegebenen Wertes wird die jeweils älteste Datei wieder überschrieben. Dieser Wert steht standardmäßig auf 0, weil das Archivieren und Löschen der Protokoll-Dateien bei SUSE LINUX von einem eigenen Cronjob durchgeführt wird, dessen Konfiguration man in der Datei /etc/logrotate/squid findet.

Mit append_domain kann man angeben, welche Domain automatisch angehängt wird, wenn keine angegeben wurde. Meist wird man hier die eigene Domain eintragen, dann genügt es, im Browser www einzugeben, um auf den eigenen Webserver zu gelangen.

Setzt man diesen Eintrag auf off, entfernt Squid die IP-Adresse bzw. den Systemnamen des Clients aus den HTTP-Anfragen.

Normalerweise braucht man diese Werte nicht zu verändern. Hat man aber eine Wählleitung, kann es vorkommen, dass das Internet zeitweilig nicht erreichbar ist. Squid merkt sich dann die erfolglosen Anfragen und weigert sich, diese neu anzufragen, obwohl die Verbindung in das Internet wieder steht. Für diesen Fall sollte man die minutes in seconds ändern, dann führt auch ein Reload im Browser, wenige Sekunden nach der Einwahl, wieder zum Erfolg.

Will man verhindern, dass Squid Anfragen direkt aus dem Internet fordert, kann man hiermit die Verwendung eines anderen Proxys erzwingen. Diesen muss man zuvor unter cache_peer eingetragen haben. Gibt man als acl_name all an, erzwingt man, dass sämtliche Anfragen direkt an den parent weitergegeben werden. Das kann zum Beispiel nötig sein, wenn man einen Provider verwendet, der die Verwendung seines Proxys zwingend vorschreibt oder die Firewall keinen direkten Zugriff auf das Internet durchlässt.

Eine ACL benötigt zur Definition mindestens drei Angaben. Der Name <acl_name> kann frei gewählt werden. Für <type> kann man aus einer Vielzahl unterschiedlicher Möglichkeiten auswählen, die man im Abschnitt ACCESS CONTROLS in der /etc/squid/squid.conf nachlesen kann. Was für <data> anzugeben ist, hängt vom jeweiligen Typ der ACL ab und kann auch aus einer Datei, zum Beispiel mit Rechnernamen, IP-Adressen oder URLs eingelesen werden. Im folgenden einige einfache Beispiele:

acl meinesurfer srcdomain .meine-domain.com
acl lehrer src 192.168.1.0/255.255.255.0
acl studenten src 192.168.7.0-192.168.9.0/255.255.255.0
acl mittags time MTWHF 12:00-15:00

Mit http_access wird festgelegt, wer den Proxy verwenden darf und auf was er im Internet zugreifen darf. Dabei sind ACLs anzugeben, localhost und all sind weiter oben bereits definiert, die mit deny oder allow den Zugriff sperren oder freigeben. Man kann hier eine Liste mit vielen http_access-Einträgen erstellen, die von oben nach unten abgearbeitet werden; je nachdem, was zuerst zutrifft, wird der Zugriff auf die angeforderte URL freigegeben oder gesperrt. Als letzter Eintrag sollte immer http_access deny all stehen. Im folgenden Beispiel hat localhost, also der lokale Rechner, freien Zugriff auf alles, während er für alle anderen komplett gesperrt ist:

http_access allow localhost
http_access deny all

Noch ein Beispiel, in dem die zuvor definierten ACLs verwendet werden: Die Gruppe lehrer hat jederzeit Zugriff auf das Internet, während die Gruppe studenten nur Montags bis Freitags, und da nur mittags, surfen darf:

http_access deny localhost
http_access allow lehrer
http_access allow studenten mittags
http_access deny all

Die Liste mit den eigenen http_access-Einträgen sollte man der Übersichtlichkeit halber nur an der dafür vorgesehenen Stelle in der /etc/squid/squid.conf eintragen. Das bedeutet zwischen dem Text

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

und dem abschließenden

http_access deny all

Mit dieser Option kann man einen „Redirector“ wie squidGuard angeben, der in der Lage ist, unerwünschte URLs zu sperren. In Verbindung mit Proxy-Authentifizierung und den passenden ACLs kann man so den Zugriff auf das Internet für verschiedene Benutzergruppen sehr differenziert steuern. squidGuard ist ein eigenes Paket, das separat zu installieren und konfigurieren ist.

Sollen sich die Benutzer am Proxy authentifizieren müssen, kann man hier ein entsprechendes Programm wie beispielsweise pam_auth angeben. Bei der Verwendung von pam_auth öffnet sich für den Anwender beim ersten Zugriff ein Loginfenster, in dem er Benutzername und Passwort eingeben muss. Zusätzlich ist noch eine ACL erforderlich, damit nur Clients mit gültigem Login surfen können:

acl password proxy_auth REQUIRED
     
http_access allow password
http_access deny all

Das REQUIRED nach proxy_auth kann man auch durch eine Liste von erlaubten Benutzernamen oder einen Pfad zu solch einer Liste ersetzen.

Hiermit erreicht man, dass auf alle durch die ACL definierten Clients eine Ident-Anfrage ausgeführt wird, um die Identität des jeweiligen Benutzers zu ermitteln. Setzt man für <acl_name> all ein, erfolgt dies generell für alle Clients. Auf den Clients muss dazu ein Ident-Daemon laufen, bei Linux kann man dafür das Paket pidentd installieren, für Windows gibt es freie Software, die man sich aus dem Internet besorgen kann. Damit nur Clients mit erfolgreichem Ident-Lookup zugelassen werden, ist auch hier wieder eine entsprechende ACL zu definieren:

acl identhosts ident REQUIRED

http_access allow identhosts
http_access deny all

Auch hier kann man das REQUIRED wieder durch eine Liste erlaubter Benutzernamen ersetzen. Die Verwendung von Ident kann den Zugriff merklich verlangsamen, da die Ident-Lookups durchaus für jede Anfrage wiederholt werden.