13.4    Grundkonfiguration

Nach der Installation des Squid aus den Paketquellen Ihrer Distribution ist bereits eine Grundkonfiguration unter /etc/squid/squid.conf vorhanden – außer unter Debian: Dort müssen Sie hinter allen Pfaden stets die Zahl »3« ergänzen. Hier werden alle Parameter des Squid aufgeführt, und mit Kommentaren wird deren Funktionsweise erläutert. In diesem Abschnitt werden die Kernpunkte der Konfiguration und die Handhabung des Dienstes beschrieben.

Folgende Punkte werden dabei näher betrachtet:

Der komplexeste Konfigurationspunkt, das Regelwerk, wird aufgrund seines Umfangs in den beiden Abschnitten , »Objekte«, und , »Regeln«, im Detail erläutert.

13.4.1    Aufbau des Testumfelds

Alle Konfigurationen in diesem Kapitel legen den Aufbau aus Abbildung 13.1 zugrunde.

Netzwerkübersicht: Testumfeld Proxy

Abbildung 13.1    Netzwerkübersicht: Testumfeld Proxy

13.4.2    Netzwerk

Dem Dienst werden in der squid.conf über den Parameter http_port eine Netzwerkkarte und ein TCP-Port zugewiesen. Nach der Installation ist dieser Parameter so konfiguriert, dass der Squid auf allen Netzwerkschnittstellen auf dem TCP-Port 3128 lauscht:

# Squid normally listens to port 3128
http_port 3128

Listing 13.1    Portdefinition auf allen Netzwerkschnittstellen

Falls Sie dies einschränken wollen, sodass der Proxy nur auf einer Netzwerkschnittstelle läuft, fügen Sie die jeweilige IP-Adresse einfach hinter dem Befehl http_port hinzu, gefolgt von einem Doppelpunkt und der Portangabe:

http_port 10.0.0.1:3128

Listing 13.2    Portdefinition auf einer Netzwerkschnittstelle

13.4.3    Cache

Entsprechend der zur Verfügung stehenden Hardware können Sie dem Squid Hauptspeicher zuweisen. Dies geschieht über den Parameter cache_mem. In der Standardkonfiguration ist dieser bereits wie folgt definiert:

#Default:
# cache_mem 256 MB

Listing 13.3    Hauptspeicherkonfiguration

Den optimalen Wert für Ihr Umfeld finden Sie nur durch Erfahrung heraus, da er wieder sehr stark von der zur Verfügung stehenden Hardware und dem Benutzerverhalten abhängt. Als Grundlage sollten Sie mit einem Viertel bis der Hälfte Ihrer Hauptspeichergröße beginnen. Beachten Sie, dass Ihr OS und der Squid selbst natürlich auch noch Hauptspeicherbedarf haben.

[ ! ]  Zu großer »cache_mem«

Dieser Parameter umschreibt nicht den maximalen von Squid genutzten Hauptspeicher, sondern lediglich den zusätzlich zur Verfügung gestellten Hauptspeicher für Cache-Objekte. Dieses Limit kann bei Bedarf vom Squid auch überschritten werden! Beachten Sie, dass ein zu groß gewählter Wert schnell zum Swapping führt, was die Verarbeitungszeit deutlich verlangsamt.

Des Weiteren können Sie die Größe und den Ort des lokalen Festplatten-Caches über den Parameter cache_dir definieren. Im Standard ist ein Cache bereits vordefiniert, aber nicht aktiviert, wie in Listing 13.4 dargestellt. Hier wird das Verfahren ufs zur Cache-Speicherung im Verzeichnis /var/spool/squid mit 100 MB Größe in 16 Hauptverzeichnissen mit jeweils 256 Unterverzeichnissen angewandt. Das ufs-Verfahren ist das altehrwürdige SquidVerfahren zur Speicherung des Caches. Wesentlich aktueller ist das Verfahren aufs, das ein Update des ufs-Verfahrens darstellt. Hierbei werden die Lese-/Schreibzugriffe asynchron durchgeführt, was zu einer Geschwindigkeitssteigerung führen kann. Selbstverständlich erlaubt der Squid Ihnen auch, mehrere Cache-Pools zu betreiben, sodass Sie effektiv Messwerte erheben können, um somit das beste Verfahren für Ihr Umfeld zu ermitteln.

# Uncomment and adjust the following to add a disk cache directory.
#cache_dir ufs /var/spool/squid 100 16 256

Listing 13.4    Ort und Umfang des Cache-Verzeichnisses

Definieren Sie darüber hinaus die Größe der Objekte im Hauptspeicher und die maximale Größe von Cache-Objekten auf der Festplatte. Diese Werte sind in der Standardkonfiguration eher verhalten gesetzt. Passen Sie diese an zeitgemäße Werte an.

Über den Parameter maximum_object_size_in_memory definieren Sie die maximale Größe von Objekten im Hauptspeicher:

#Default:
# maximum_object_size_in_memory 512 KB

Listing 13.5    Objektgröße im Hauptspeicher

Ab Version 3.1 wurde dieser Wert auf 512 KB erhöht (vorher 8 KB), damit kleinere Bilddateien auch im Hauptspeicher gehalten werden können.

Der Parameter maximum_object_size gibt die maximale Größe von Objekten an, die auf der Festplatte gespeichert werden. Auf aktuellen Systemen mit entsprechenden Festplatten können Sie diesen Wert durchaus auf 800 MB erhöhen, sodass ein ISO-CD-Image auch aus den Cache an Clients ausgeliefert werden kann.

#Default:
# maximum_object_size 4 MB
maximum_object_size 800 MB

Listing 13.6    Größe von Objekten auf der Festplatte

[+]  Leider gibt es hier erneut keine Faustregel für die Berechnung der perfekten Einstellung. Selbstverständlich können Sie das Caching vollkommen an Ihre Bedürfnisse anpassen, sodass Sie den maximalen Wirkungsgrad zwischen vorhandener Bandbreite, Hauptspeicher, Festplattengröße und dem Surfverhalten Ihrer Nutzer erzielen. Allerdings übersteigen die dazu notwendigen Erläuterungen die Möglichkeiten dieses Buches.

13.4.4    Logging

Neben der Konfigurationsdatei spielen die Log-Dateien des Squid eine zentrale Rolle. Sie dienen nicht nur zur Auswertung der Zugriffe über den Proxy, sondern vor allem zur Fehleranalyse und dazu, Informationen über den Betriebsstatus zu erhalten. Die Logs werden unter dem Standardpfad /var/log/squid abgelegt. Der Squid stellt drei Log-Dateien zur Verfügung: access.log, cache.log und store.log. Im access.log werden alle Zugriffe über den Proxy protokolliert. Jede Zeile repräsentiert einen Zugriff.

Da HTTP nicht auf Sessions beruht, werden beim Aufruf einer Webseite mehrere Zugriffe getätigt, die entsprechend protokolliert werden. So wird beim Aufruf einer Seite nicht nur die URL als solche protokolliert, sondern alle Seiten und Medien (zum Beispiel Bilder), die darin referenziert sind, einzeln für sich. Für den Endbenutzer erscheint der Vorgang zwar als ein Zugriff, in Wahrheit werden aber viele einzelne Dateien zu einem Gesamtbild zusammengefügt. Tabelle 13.1 zeigt die Daten, die bei jedem Zugriff im nativen Squid-Log-Format protokolliert werden.

Bezeichnung Bedeutung
time Timestamp des Zugriffs
elapsed benötigte Zeit des Abrufens
remotehost IP-Adresse des anfragenden Clients
code/status Squid-Ergebnis/HTTP-Statuscode
bytes Größe in Byte
method verwendete Methode (GET, PUT etc.)
URL die angeforderte URL
rfc931 Benutzername (bei erfolgreicher Authentifizierung)
peerstatus/peerhost Abfragetyp (direkt oder über einen weiteren Proxy)
type Typ der abgefragten URL (zum Beispiel text/html)

Tabelle 13.1    Elemente »access.log«

Der Block code/status stellt das Ergebnis der Anfrage dar: zum einen das Squid-Ergebnis und zum anderen den HTTP-Statuscode. Das Squid-Ergebnis umschreibt, wie der Squid den Inhalt abgerufen hat oder warum dieser nicht abgerufen wurde. Tabelle 13.2 zeigt eine Übersicht über die gängigsten Squid-Ergebnisse und deren Bedeutung.

Code Bedeutung
TCP_HIT Inhalt ist im Cache vorhanden.
TCP_MISS Inhalt ist nicht im Cache vorhanden.
TCP_REFRESH_MISS Inhalt musste neu abgerufen werden (veralteter Cache-Inhalt).
TCP_REFRESH_HIT Inhalt ist noch im Cache (kein erneuter Abruf).
TCP_CLIENT_REFRESH_MISS Der Proxy wurde angewiesen, den Inhalt neu zu laden.
TCP_DENIED Der Zugriff wurde untersagt.

Tabelle 13.2    Auszug aus den Squid-Ergebnissen

Zusätzlich werden die HTTP-Statuscodes protokolliert, die den Browserfehlermeldungen entsprechen. Tabelle 13.3 gibt einen Überblick über die gängigsten HTTP-Statuscodes.

Code Wert Bedeutung
200 OK Die Abfrage verlief ohne Fehler.
301 Moved Permanently Weiterleitung
304 Not Modified Unverändert – Zustellung aus dem Cache
403 Forbidden Zugriff untersagt
407 Proxy Authentication Required Authentifizierung erforderlich
503 Service Unavailable Der Inhalt kann zurzeit nicht abgerufen werden.

Tabelle 13.3    HTTP-Statuscodes

Selbstverständlich können die Squid-Fehlermeldungen angepasst werden. Über den Parameter error_directory können Sie das Verzeichnis und damit die Fehlermeldungen fixieren. In der Grundkonfiguration wird die Sprache der Fehlermeldungen anhand der Browsereinstellungen des Clients gewählt (multi-language support).

# Sprache fest auf "deutsch" einstellen:
# error_directory /usr/share/squid-langpack/de

Listing 13.7    Konfiguration der Fehlerausgabe

Falls Sie über eine ganzheitliche Lösung zur Log-Auswertung verfügen, können Sie das Format auch mittels logformat anpassen. Beim cache.log hingegen handelt es sich nicht etwa um ein Log der im Proxy-Cache abgelegten Daten, sondern um das Fehler-Log des Squid. In ihm wird zum Beispiel bei jedem reload und restart die Verarbeitungs- und Fehlerausgabe protokolliert. Im store.log hingegen werden die einzelnen Cache-Objekte protokolliert. Deaktivieren Sie dieses Log, da es unnötige I/O-Last erzeugt und für den Betrieb keine große Relevanz hat – es sei denn, Sie möchten ein voll angepasstes Caching etablieren. Falls Sie die Pfadangaben oder Dateinamen ändern wollen oder das entsprechende Log nicht anlegen lassen wollen, steht Ihnen das natürlich frei. Der Squid bietet hierfür die Parameter access_log, cache_log und cache_store_log, jeweils gefolgt von der Dateiangabe inklusive des Pfads oder der Option none, um das Log zu deaktivieren.

13.4.5    Handhabung des Dienstes

Sie starten den Dienst über die Konsole mittels squid im Daemon-Modus oder besser über systemd oder das init.d-Skript. Über die Systemmethoden können Sie den Dienst wie gewohnt starten, stoppen, neu starten und die Konfiguration neu laden. Änderungen in der squid.conf können aber über zwei Methoden aktiviert werden: zum einen, wie bereits beschrieben, über das System selbst und zum anderen über den Squid-Parameter reconfigure.

root@web-proxy:~# squid -k reconfigure

Listing 13.8    Neuladen der Konfiguration

[+]  Abweichungen: »systemd«

Auf Debian- und Ubuntu-Systemen wird das init-Skript konvertiert. Auf CentOS und openSUSE Leap existieren »echte« systemd-Skripte, in denen zum Teil Konfigurationen vorhanden sind.

Das Neuladen der Konfiguration erfolgt unterbrechungsfrei, sodass Sie Änderungen auch im laufenden Betrieb ohne Aussetzer einbinden können. Dagegen hat das Neustarten des Dienstes – je nach Konfiguration des für den Squid zur Verfügung gestellten Speichers und der Festplattengeschwindigkeit – einen längeren Ausfall zur Folge. Dies beruht darauf, dass beim Neustart der gesamte Inhalt des im Hauptspeicher befindlichen Caches in Dateien geschrieben werden muss, was eine sehr hohe I/O-Last hervorruft.

Setzen Sie zusätzlich in der squid.conf den Benutzer und die Gruppe, unter dem bzw. der der Squid laufen soll. Jede Distribution liefert unterschiedliche Standards mit. Trotz dieser Standards sollten Sie den Benutzer und die Gruppe über die Parameter cache_effective_user und cache_effective_group, jeweils gefolgt von dem Benutzer bzw. der Gruppe, definieren. Dadurch haben Sie die Daten präsent, um den Dateien, auf die der Dienst zugreifen soll, die korrekten Rechte geben zu können.

Neben der reinen Konfiguration des Dienstes finden in der squid.conf auch die sogenannten ACLs (Access Control Lists) ihren Platz. Über sie werden die Authentifizierung und die Regulierung der Zugriffe realisiert. Die Definition erfolgt über Regeln und Objekte. Da diese die größten Stolpersteine bei der Konfiguration darstellen, werden wir uns in den nächsten beiden Abschnitten die Erstellung von und den Umgang mit Objekten und Regeln genauer ansehen.

[ ! ]  Verwechslungsgefahr

Leider überschneiden sich beim Squid-Regelwerk die gängigen Bezeichnungen. Wird im Squid von einer acl gesprochen, so ist dort eigentlich die Objektdefinition gemeint. Die Regel als solche wird hingegen mit http_access definiert. In diesem Buch werden nur die Begriffe »Objekt« und »Regel« verwendet, um einer Verwechslung vorzubeugen.

13.4.6    Objekte

Der Grundpfeiler einer jeden Regel sind Objekte. Sie umschreiben unter anderem Hosts, Netze, Ports oder Protokolle. Jedes Objekt enthält die in Tabelle 13.4 dargestellten Elemente.

Element Bedeutung
acl Einleitung der Objektdefinition
NAME Name des Objekts, auf den innerhalb von Regeln verwiesen wird
TYPE Typ des Objekts (src, dst, port, proto, url_regex, dstdomain etc.)
DATA Daten des Typs (direkt oder in Dateien durch Anführungszeichen umschlossen)

Tabelle 13.4    Objektdetails

In der Standardkonfiguration sind bereits einige Objekte definiert:

acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl CONNECT method CONNECT

Listing 13.9    Standardobjekte der »squid.conf«

Um einem Objekt mehrere Werte zuzuweisen, wird das Objekt mehrfach deklariert, zum Beispiel in Listing 13.9 Safe_ports. Oder die Werte werden in einer Zeile angegeben. Ebenfalls ist eine Mischform möglich, der Squid summiert die Auflistung stets zusammen.

In Objektdefinitionen werden keine Wildcards unterstützt. Der Squid bietet hierfür aber ein besonderes Domain-Handling an. Werden Domains mit einem führenden Punkt deklariert, dann sind in diesem Objekt auch alle Subdomains mit eingeschlossen. Bei der Angabe von .example.net sind die Domains www.example.net und mail.example.net enthalten. Zudem sind Objektnamen case sensitive, sodass das Objekt linuxdistributionen ungleich dem Objekt LinuxDistributionen ist.

[ ! ]  Stolperstein »Namensgebung«

Jedes Objekt muss über einen eindeutigen Namen verfügen, den Sie in der acl-Zeile als zweiten Parameter angeben. Die Wahl des Namens ist Ihnen überlassen, wobei Sie sich an die Spielregeln halten müssen. Verwenden Sie nur Buchstaben, Zahlen, Binde- und Unterstriche. Leerzeichen, deutsche Umlaute oder Sonderzeichen sind nicht erlaubt und führen zu Fehlern!

13.4.7    Objekttypen

Der Squid unterscheidet Objekte nach Typen. Diese müssen Sie für jedes Objekt angeben, damit der Squid weiß, wie er das Objekt verarbeiten soll. Tabelle 13.5 zeigt eine Übersicht über die gängigsten Objekttypen.

Typ Beispiel Bedeutung
src 192.168.0.0/24 Quell-IP-Adresse, -Range oder -Netz
dst 192.168.1.0/30 Ziel-IP-Adresse, -Range oder -Netz
srcdomain .example.com Quellname
dstdomain www.example.com Zielname
port 8443 TCP-Port
dstdom_regex s[0-9]*\.example\.com regulärer Ausdruck auf Zieldomänen
proxy_auth - Authentifizierung

Tabelle 13.5    Objekttypen

13.4.8    Objektlisten in Dateien

Große Objektlisten innerhalb der Konfiguration zu pflegen ist nicht nur unübersichtlich, sondern stört zum Beispiel auch bei einer skriptgestützten Verarbeitung. Daher wurde die Möglichkeit geschaffen, Objektlisten in eine Datei auszulagern. Diese müssen nicht umständlich importiert werden. Hierfür genügt es, bei der Objektdefinition als Wert den Pfad zur Datei anzugeben und diesen mit doppelten Anführungszeichen (") zu umschließen. Wollen Sie zum Beispiel eine Liste der Windows-Update-Server in eine Datei auslagern, legen Sie zunächst die Textdatei /etc/squid/windowsUpdate.txt mit folgendem Inhalt an:

windowsupdate.microsoft.com
.update.microsoft.com
download.windowsupdate.com
.metaservices.microsoft.com
c.microsoft.com
www.download.windowsupdate.com
wustat.windows.com
crl.microsoft.com
sls.microsoft.com
productactivation.one.microsoft.com

Listing 13.10    Externe »dstdomain«-Datei »/etc/squid/windowsUpdate.txt«

Damit der Squid die soeben angelegte Datei auch verarbeiten kann, müssen Sie die Rechte anpassen. Dies können Sie mit chwon proxy:proxy windowsUpdate.txt erreichen. Anschließend deklarieren wir das Objekt windowsUpdate in der squid.conf:

acl windowsUpdate dstdomain "/etc/squid/windowsUpdate.txt"

Listing 13.11    Objektdefinition der externen »dstdomain«-Datei »windowsUpdate«

Somit wird der Squid angewiesen, den Inhalt aus der Datei /etc/squid/windowsUpdate.txt als Objekte des Typs dstdomain zu verarbeiten. Beachten Sie dabei, dass in der Datei pro Zeile nur ein Wert aufgeführt sein darf.

13.4.9    Regeln

Regeln stellen den größten Stolperstein für beginnende Proxy-Administratoren dar. Daher werden wir uns diese im Detail ansehen. Regeln erlauben oder verweigern nicht nur den Zugriff, sondern können diesen auch einschränken. Wie bei den Objekten sind in der Standardkonfiguration bereits Regeln definiert:

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localhost
http_access deny all

Listing 13.12    Standardregeln

Eine Regel liest sich von links nach rechts. In Pseudocode lautet die Regel http_access deny CONNECT !SSL_ports: »Verbiete Zugriff auf das Objekt CONNECT (Zugriffsmethode CONNECT) für Nicht-Inhalte des Objekts SSL_ports.« Was so viel bedeutet wie: »Verbiete alle Zugriffe auf Nicht-SSL-Ports.« Das führende Ausrufezeichen (!) bei !SSL_ports negiert das Objekt. Dies ist ein zentrales Mittel bei der Regelerstellung. Im Detail enthält jede Regel die in Tabelle 13.6 dargestellten Elemente.

Element Bedeutung
http_access Einleitung einer Regel
AKTION Regelart: erlauben/verweigern (allow/deny)
OBJEKT Objekt, auf das die Aktion angewendet wird
(optional) OBJEKT Objekt, das den Zugriff einschränkt

Tabelle 13.6    Beschreibung »http_access«

Regeln verfügen noch über ein paar Besonderheiten, die wir nun genauer betrachten. Da das Regelwerk sequenziell abgearbeitet wird, ist die Positionierung einer Regel von essenzieller Bedeutung. Es gilt der Grundsatz: »Die Reihenfolge ergibt sich vom Objekt mit den geringsten Rechten hin zu dem Objekt mit den meisten Rechten«. Darauf werden wir im weiteren Verlauf dieses Kapitels mehrfach eingehen.

Da der Squid das Prinzip des first match anwendet (Abbruch der Verarbeitung beim ersten Zutreffen einer Regel), sollte am Ende des Regelwerks immer eine catch all-Regel stehen, die alle Anfragen abfängt, die nicht bereits durch eine deklarierte Regel verarbeitet wurden. In der Standardkonfiguration ist dies bereits enthalten, wie in Listing 13.13 dargestellt:

# And finally deny all other access to this proxy
http_access deny all

Listing 13.13    Regel »catch all«

Betrachten wir in Tabelle 13.7 die zwei Methoden um eine Freigabe zu definieren.

Beispiel Regelwerk
A http_access allow myClients whitelist
http_access deny all
B http_access deny myClients !whitelist
http_access deny all

Tabelle 13.7    Zwei Arten, Freigaben zu definieren

Auf den ersten Blick erreichen beide Varianten das gleiche Ziel: Alle Mitglieder des Objekts myClients dürfen nur auf den Inhalt des Objekts whitelist zugreifen, und alle anderen Zugriffe werden verboten. Die beiden Beispiele werden von Squid aber unterschiedlich verarbeitet. Das Beispiel A arbeitet so, wie man es auf den ersten Blick erwartet. Beim Beispiel B hingegen werden alle Zugriffe unterbunden. Dies ist darauf zurückzuführen, dass für das Objekt myClients lediglich deny-Regeln definiert sind und keine Regel, die einen Zugriff erlaubt.

[ ! ]  Stolperstein

Falls keine Regel auf einen Zugriff zutrifft, wendet Squid das Gegenteil der letzten Regel in der Konfiguration an.

13.4.10    Überlagerung mit »first match«

Eine Feinheit der Regeln muss noch betrachtet werden: das Überlagern von Objektdefinitionen mithilfe von first match.

[»]  Den Mitarbeitern einer Firma ist der Zugriff auf Tageszeitungen untersagt, der Chef hingegen darf Boulevardzeitungen aufrufen. Dafür wurden folgende Objekte angelegt:

acl Chef src 192.168.0.10/32
acl Mitarbeiter src 192.168.0.0/24
acl Tageszeitungen dstdomain .bild.de
acl Tageszeitungen dstdomain .express.de
acl Tageszeitungen dstdomain .faz.de
acl Tageszeitungen dstdomain .waz.de
acl Boulevard dstdomain .bild.de
acl Boulevard dstdomain .express.de

Listing 13.14    Beispiel für eine Überlagerung: Objekte

Folgende Regeln müssten definiert werden, damit der Chef trotz der Überlagerung die Webseiten aufrufen darf:

http_access allow Chef Boulevard
http_access allow Mitarbeiter !Tageszeitungen
http_access deny all

Listing 13.15    Beispiel für eine Überlagerung: Regeln

Somit darf der Chef alle im Objekt Boulevard deklarierten URLs aufrufen. Allerdings würde auch dem Chef der Zugriff auf www.waz.de oder www.faz.de untersagt werden, da er durch die Class-C-Netz-Definition des Objekts Mitarbeiter ebenso Mitglied dieser Gruppe ist. Fassen wir das erworbene Wissen über Objekte und Regeln noch einmal zusammen:

13.4.11    Anwendung von Objekten und Regeln

Um den Clients aus dem Beispiel, das in Abbildung 13.1 dargestellt ist, Vollzugriff über den Proxy zu gewähren, muss zuerst ein Objekt definiert werden:

acl myClients src 192.168.1.0/24

Listing 13.16    Objektdefinition »myClients«

Mit diesem Objekt wird nun eine Regel oberhalb des bestehenden Regelblocks erstellt.

http_access allow myClients

Listing 13.17    Regel »myClients«

Nach einem reload sind alle Clients des Netzes 192.168.1.0/24 in der Lage, Webseiten über den Proxy abzurufen. Wie bereits erwähnt wurde, kann der Zugriff auch eingeschränkt werden. Da Server im Normalfall lediglich Zugriff auf Update-Server benötigen, genügt es, zum Beispiel einem Ubuntu-Server Zugriff auf die Seiten de.archive.ubuntu.com und security.ubuntu.com zu gewähren. Dafür deklarieren wir ein neues Objekt ubuntuUpdate für die URLs und ein Objekt myServer für das Servernetz 10.0.0.0/24.

acl ubuntuUpdate dstdomain de.archive.ubuntu.com
acl ubuntuUpdate dstdomain security.ubuntu.com
acl myServer src 10.0.0.0/24

Listing 13.18    Objektdefinition »ubuntuUpdate« und »myServer«

Da für Windows-Updates deutlich mehr URLs deklariert werden müssen, empfiehlt es sich, die Auflistung in einer externen Datei vorzunehmen. Dafür legen wir die Textdatei /etc/squid/windowsUpdate.txt mit folgendem Inhalt an:

windowsupdate.microsoft.com
.update.microsoft.com
download.windowsupdate.com
.metaservices.microsoft.com
c.microsoft.com
www.download.windowsupdate.com
wustat.windows.com
crl.microsoft.com 
sls.microsoft.com
productactivation.one.microsoft.com

Listing 13.19    Externe »dstdomain«-Datei »windowsUpdate.txt«

[ ! ]  Achten Sie darauf, dass der Benutzer, unter dem der Squid3-Daemon ausgeführt wird, Leserechte auf diese Datei besitzt.

Anschließend deklarieren wir das Objekt windowsUpdate in der squid.conf:

acl windowsUpdate dstdomain "/etc/squid/windowsUpdate.txt"

Listing 13.20    Objektdefinition der externen »dstdomain«-Datei »windowsUpdate«

Damit unsere Server im 10.0.0.0/24-Netz ausschließlich diese URLs aufrufen dürfen, muss noch eine entsprechende Regel erstellt werden. Dies sieht dann wie folgt aus:

http_access allow myClients
http_access allow myServer ubuntuUpdate
http_access allow myServer windowsUpdate

http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost

http_access deny all

Listing 13.21    Gesamtregelwerk

[ ! ]  Gefahrenquelle: HTTPS-Zugriffe

Die Konfiguration in Listing 13.21 birgt noch eine Gefahr in sich. Da hier lediglich Whitelists definiert wurden und nur eine catch all-Regel am Ende definiert wurde, könnten die Mitglieder des Objekts myServer auch HTTPS-Seiten aufrufen, die nicht in den Objekten ubuntuUpdate oder windowsUpdate enthalten sind – first match! Um dies zu verhindern, muss hierfür eine separate catch all-Regel vor der Regel http_access deny !Safe_ports eingefügt werden.