Squid Proxy konfigurieren

Dieser Text befasst sich mit der Installation und Konfiguration des „Squid Web Proxy Cache“. Grundlage ist die Squid Version 2.5.STABLE7, soweit mir aber grundlegende Veränderungen zu vorherigen Versionen aufgefallen sind, werden auch diese vorherigen Einstellungen berücksichtigt.

• „Squid“ installieren
• Basis Konfiguration des „Squid“
  • Netzwerk Optionen
  • Cache Optionen
  • Logfile- und Cache-Verzeichnisse
  • Optionen für externe Programme
  • Administrative Parameter
  • Verschiedenes
• Access Control Lists (ACL)
• User-Authentifizierung
  • Authentifizierung mittels Passwortdatei
  • Authentifizierung mittels Pluggable Authentication Modules (PAM)
  • Authentifizierung mittels Lightweight Directory Access Protokoll (LDAP)
  • Authentifizierung gegen eine Windows NT Domäne
• „Squid“ als Transparenter Proxy
• „Squid“ starten

Die Webseiten des Squid Web Proxy Cache.
Eine deutsche Übersetzung des Squid Proxyserver Administrationshandbuch.

---

„Squid“ installieren

Falls keine aktuelle Version des Squid Proxy der verwendeten Linux Distribution beiliegt, kann die aktuelle Version von der Squid Seite aus bezogen werden. Diese wird mit den folgenden Befehlen kompiliert und installiert:

$ ./configure --prefix=/usr/local/squid
$ make all
# make install

Hierbei wird Squid in das Verzeichnis /usr/local/squid installiert.

Wer die Konfigurationsdateien lieber im Verzeichnis /etc/squid liegen haben möchte statt in /usr/local/squid/etc, der kann bei ./configure auch noch die Option --sysconfdir=/etc/squid angeben.

Wer lieber deutschsprachige Fehlerseiten verwenden möchte, kann ./configure noch zusätzlich die Option --enable-err-language=German übergeben. Somit sähe der ./configure-Aufruf wie folgt aus:

$ ./configure --prefix=/usr/local/squid --sysconfdir=/etc/squid --enable-err-language=German

Basis Konfiguration des „Squid“

Konfiguriert wird der Squid Proxy über die Konfigurationsdatei squid.conf. Eine Vorlage hierfür liegt, ausgehend von der obigen Installation, nun entweder im Verzeichnis /usr/local/squid/etc oder /etc/squid. In älteren GNU/Debian Paketen liegt sie unter /etc. Wenn schon, vielleicht von einer älteren Squid Version, dort eine Konfigurationsdatei liegt, wird diese nicht überschrieben. Zusätzlich wird noch in jedem Fall eine zweite Vorlage squid.conf.default dort angelegt. Diese ist recht praktisch, wenn man von einer älteren Squid Version updatet.

Nachfolgend werden nun relevante Teile der Einstellungen in der Konfigurationsdatei squid.conf beschrieben. Diese Aufstellung erhebt keinen Anspruch auf Vollständigkeit. Besonders auf den Bereich „Proxy-Farmen (neighbor caches)“ wird nicht eingegangen. Ebenso wird auf Einstellungen, deren Default-Werte übernommen werden können, nur selten eingegangen.

Eine ausführlichere Beschreibung ist in der Konfigurationsdatei selbst enthalten oder als FAQs auf den Webseiten des Squid Proxy.

Netzwerk Optionen

Hier sind einige Einstellungen zu den Netzwerkbindungen und den verwendeten Protokollen zu treffen.

Netzwerkbindung:

#  TAG: http_port
#   Usage:  port
#       hostname:port
#       1.2.3.4:port
…
#Default:
# http_port 3128
http_port 10.0.0.1:3128
http_port 10.0.0.1:8080

Hier wird festgelegt, auf welchem Port oder IP-Adresse/Port bzw. Hostname/Port Squid Verbindungen annimmt. Hierbei können mehrere Adressen in unterschiedlichen Zeilen angegeben werden.

Die Standardeinstellung ist, dass Squid Verbindungen auf allen IP-Adressen des Rechners auf Port 3128 entgegen nimmt. Eine sinnvolle Änderung wäre das binden an die interne IP-Adresse (z.B. 10.0.0.1), damit der Proxy nur von intern zu erreichen ist. Außerdem erwachten viele Anwender einen Proxy auf dem Port 8080, deshalb kann es recht sinnvoll sein, Squid auf beiden Ports lauschen zu lassen..

ICP Protokoll:

#  TAG: icp_port
…
#Default:
# icp_port 3130
icp_port 0

Das Internet Cache Protocoll (ICP) dient der Kommunikation des Squids mit anderen Proxies und ist definiert im RFC2186 und RFC2187. Eine Kommunikation mit anderen Proxies wird eher in größeren Netzwerken benötigt und dementsprechend sollte dieses Protokoll im Einzelbetrieb mittels der Portangabe 0 deaktiviert werden.

Cache Optionen

Bestimmte Objekte nicht speichern:

#  TAG: no_cache
…
#We recommend you to use the following two lines.
acl QUERY urlpath_regex cgi-bin ?
no_cache deny QUERY

Hier kann dem Proxy mittels Access Control Lists (ACL) mitgeteilt werden, welche Seiten nicht gespeichert werden sollen. Die Voreinstellung erfasst einen großen Teil der dynamischen Websites, indem alle Adressen, die ein „cgi-bin“ oder ein Fragezeichen (dieses trennt die Aufrufparameter einer Seite von der Seitenadresse und muss in Regulären Ausdrücken mit einen Backslash „“ maskiert werden) beinhalten, vom Speichern ausgeschlossen werden.

Hier können weitere Adressen, wie zum Beispiel der eigene Server oder das lokale Netzwerk eingetragen werden.

Weitergehende Hinweise zur Verwendung von ACLs folgen später.

Speichergröße:

#  TAG: cache_mem   (bytes)
…
#Default:
# cache_mem 8 MB
cache_mem 32 MB

Hier wird festgelegt, wieviel Arbeitsspeicher Squid maximal dafür verwendet einkommende Daten, sehr oft angefragte Objekte und sog. Negative-Cached Objekte (diverse Statusmeldungen des HTTP-Protokolls) im Arbeitsspeicher zwischen zu speichern. Hierbei haben einkommende Daten absoluten Vorrang.

Diese Angabe bezieht sich nicht auf den von Squid insgesamt benötigten Arbeitsspeicher, sondern ist nur ein bestimmter Teil davon.

Bei der heutigen Ausstattung von PCs mit Arbeitsspeicher kann diese Angabe ruhigverdoppelt oder vervierfacht werden. Auf Proxies, die für die Versorgung ganzer Netzwerke zuständig sind, sollte dies sogar geschehen.

Logfile- und Cache-Verzeichnisse

Cache-Verzeichnis:

#  TAG: cache_dir
…
#Default:
# cache_dir ufs /usr/local/squid/var/cache 100 16 256
cache_dir ufs /var/cache/squid 100 16 256

Hier wird festgelegt, welche Speichermethode verwendet wird, in welchem Verzeichnis der Cache liegen soll, wie groß der Cache sein soll und welche Unterverzeichnisstruktur verwendet werden soll.

Als Speichermethode ist standardmäßig nur „ufs“ (Unix Filesystem) verfügbar. Andere Speichermethoden sind nur dann verfügbar, wenn sie extra mit ein kompiliert wurden.

Das Verzeichnis sollte entsprechend den eigenen Gegebenheiten (Festplattenplatz) und grundsätzlichen Überlegungen (was wird beeinträchtigt, wenn die Festplatte voll ist) angepasst werden. Die obige Vorgabe beruht auf den bei der Installation angegebenen Parameter –prefix=/usr/local/squid. Da es sich aber bei den Inhalten des Squid-Caches um variable Daten handelt, sollten diese besser auch im entsprechenden Bereich /var des Filesystems liegen, der auch oft auf einer eigenen Festplatten-Partition liegt. Deshalb die Angabe /var/cache/squid als Cache-Verzeichnis. Hierbei ist zu beachten, dass dieses Verzeichnis existieren und für Squid beschreibbar sein muss, damit der Squid Proxy starten kann. Mit dem Befehl squid -z kann das Cache-Verzeichnis mit allen benötigten Unterverzeichnissen angelegt werden.

Die anderen Angaben (Größe in MB und Struktur – 16 Unterverzeichnisse mit jeweils 256 weiteren Unterverzeichnissen – des Caches) können so belassen werden.

Logfile-Path:

#  TAG: cache_access_log
…
#Default:
# cache_access_log /usr/local/squid/var/logs/access.log
cache_access_log /var/log/squid/access.log

#  TAG: cache_log
…
#Default:
# cache_log /usr/local/squid/var/logs/cache.log
cache_log /var/log/squid/cache.log

#  TAG: cache_store_log
…
#Default:
# cache_store_log /usr/local/squid/var/logs/store.log
cache_store_log /var/log/squid/store.log

Entsprechend sollten die Logfiles als variable Daten auch unter /var abgelegt werden. Hinzu kommt, dass dort auch die Logfiles der anderen Programme liegen. Hierbei ist zu beachten, dass Squid das Recht haben muss, in diesem Verzeichnis Dateien an zu legen. Deshalb ist ein eigenes Verzeichnis für die Squid-Logfiles sinnvoll.

Access-Log Type:

#  TAG: emulate_httpd_log       on|off
…
#Default:
# emulate_httpd_log off
emulate_httpd_log on

Standardmäßig wird das „access.log“ Logfile, das Auskunft über die Zugriffe gibt, in einem Squid eigenen Format abgespeichert. Es ist aber auch möglich, das sog. „common“ Format zu verwenden, das diverse HTTP-Server, wie z.B. „Apache“, verwenden, wenn man dieses Format besser auswerten kann.

Prozess-ID-Datei:

#  TAG: pid_filename
…
#Default:
# pid_filename /usr/local/squid/var/logs/squid.pid
pid_filename /var/run/squid.pid

Auch die Datei, die die Prozess-ID des Squids beinhaltet, sollte in dem entsprechenden Verzeichnis unter /var abgelegt werden. Auch hier ist unbedingt darauf zu achten, dass Squid das Recht haben muss, diese Datei anzulegen.

Debuging Informationen in den Logfiles:

#  TAG: debug_options
…
#Default:
# debug_options ALL,1

Die Logging-Optionen sind eine Kombination aus Logging-Bereich und Logging-Level, getrennt mittels Komma. Ein geringes Logging-Level führt zu kleinen Logfiles und ein Logging-Level „9“ (als höchster Wert) kann zu sehr großen Logfiles führen. Der Logging-Bereich „ALL“ umfasst alle Bereiche. Die Standardeinstellung „ALL,1“ ist für den Normalbetrieb völlig ausreichend. Nur wenn es Probleme gibt, sollte man sich langsam in den Logging-Levels bis „9“ nach oben arbeiten.

Logging der IP-Adresse oder Rechner-Namens

#  TAG: log_fqdn        on|off
…
#Default:
# log_fqdn off

Standardmäßig wird in den Logfiles nur die IP-Adresse den abfragenden Clients gespeichert. Wenn stattdessen der vollständige Rechnername (mit Domainteil auch Fully Qualified Domain Name = FQDN) gewünscht wird, so ist diese Option zu aktivieren.

Privacy-Einstellung:

#  TAG: client_netmask
…
#Default:
# client_netmask 255.255.255.255

Wenn die Privatsphäre der Clients bewahrt werden soll oder muss (z.B. Datenschutz in Unternehmen), kann hier eine Netzwerk-Maske definiert werden, die dazu führt, dass die einzelnen Logfile-Einträge nicht mehr einem Rechner zuordbar sind.

Eine Netzwerk-Maske von 255.255.255.0 würde dazu führen, dass bei allen IP-Adressen in den Logfiles und der cachemgr Ausgabe die letzte Stelle als „0“ dargestellt wird. Beim Standardwert 255.255.255.255 wird die komplette Adresse angezeigt.

Optionen für externe Programme

Anonymous FTP-User:

#  TAG: ftp_user
…
#Default:
# ftp_user Squid@

Beim Anonymous FTP-Zugriff gilt es als höflich, dass Nutzer als eine E-Mail-Adresse als Passwort eingibt. Da einige FTP-Server ohne Angabe einer gültigen E-Mail-Adresse keinen Zugriff gewähren, sollte hier eine gültige Adresse eingetragen werden.

Passives FTP:

#  TAG: ftp_passive
…
#Default:
# ftp_passive on
ftp_passive off

Wenn passives FTP Probleme bereitet, kann dies hier ausgeschaltet werden.

Aktives FTP ist aber aus Sicherheitsgründen sehr bedenklich, da die Gegenseite dann selber eine Verbindung herstellen muss, und sollte vermieden werden.

Schemas zur User-Authentifizierung:

#  TAG: auth_param
…

Hier können verschiedene Schemata zur User-Authentifizierung eingestellt werden.

Dieses Thema wird später ausführlich in einem separaten Kapitel zur User-Authentifizierung behandelt.

#  TAG: external_acl_type
…

Mittels Hilfsprogramme können hier externe ACLs definiert werden.

Auch dieses Thema wird später ausführlich anhand eines LDAP-Filters erklärt.

Administrative Parameter

E-Mail-Adresse des Admins

#  TAG: cache_mgr
…
#Default:
# cache_mgr webmaster

E-Mail-Adresse des Squid-Admins, an den Meldungen über einen evtl. Absturz des Proxies gesendet werden sollen. Die Standardeinstellung ist „webmaster“.

Standarduser und -gruppe:

#  TAG: cache_effective_user
#  TAG: cache_effective_group
…
#Default:
# cache_effective_user nobody
cache_effective_user squid
cache_effective_group squid

Diese Einstellung bewirkt, dass wenn der Squid Proxy als Root gestartet wird er die angegebene User- und Gruppen-ID annimmt. Ist kein User angegeben, wird UID des Users „nobody“ und als GID dessen Standardgruppe angenommen.

Wenn Squid nicht als Root gestartet wird, behält er die aktuelle UID/GID und es kann nur die GID zu einer der Gruppen gewechselt, wo der aktuelle User auch Mitglied ist.

Dies ist ein Schutz davor, dass der Squid-Prozess als Root volle Kontrolle über das System hätte. Die Voreinstellung „nobody“ sollte aber auch nicht verwendet werden, da evtl. diverse Prozesse unter dieser User-ID laufen und bei einem erfolgreichen Angriff der Angreifer auf zu viele Programme Zugriff hätte. Es ist deshalb sinnvoll, dem Squid Proxy eine eigene UID und GID zu geben, die selbstverständlich auf dem System existieren müssen.

Vollständiger Rechnername

#  TAG: visible_hostname
…
#Default:
# none

Squid benötigt zum Starten einen „Fully Qualified Domain Name (FQDN)“ um diesen z.B. in Fehlermeldungen zu verwenden. Dieser FQDN wird in der Konfiguration des Betriebsystems angegeben. Mittels hostname -f läßt sich der aktuelle FQDN des Rechners ermitteln. Wenn ein ander anderer Rechnername von Squid verwendet werden soll (oder kein FQDN definiert wurde), kann dies durch den Eintrag visible_hostname erfolgen.

Verschiedenes

Anonymisieren der IP-Adresse:

#  TAG: forwarded_for   on|off
…
#Default:
# forwarded_for on

Standardmäßig wird in jede HTTP-Anfrage die IP-Adresse oder der Name des Clients über die „X-Forwarded-For“-Umgebungsvariable an den externen Server mitgeteilt:

X-Forwarded-For: 192.1.2.3

Wenn dies aus irgend welchen Gründen nicht gewünscht wird, muss die Option mittels forwarded_for off ausgeschaltet werden. Dies führt zu der folgenden Mitteilung an den externen Server:

X-Forwarded-For: unknown

Access Control Lists (ACL)

Die Zugriffskontrollen teilen sich in zwei unterschiedliche Bereiche auf. Zuerst werden mit dem Tag acl bestimmte Zugriffslisten definiert und danach werden mittels des Tags http_access die Listen angewendet.

Hierbei können ACLs auf Basis von Quell- und Ziel-Adressen, URLs, Zeitangaben, Protokolle, Ports und User definiert werden.

Die Default-Einstellung unterbindet jegliche Verbindung nach außen und es wird zuerst einmal dies geändert. Eine weitergehende Beschreibung erfolgt evtl. zu einem später Zeitpunkt oder sollte in der Konfigurationsdatei squid.conf nachgelesen werden.

#  TAG: acl
…
#Recommended minimum configuration:
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443 563     # https, snews
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

Hier sind nun diverse ACLs definiert worden. Bis auf die ersten drei ACLs können diese m.e. gleich ganz gelöscht werden (besonders die ACLs, die vermeidlich sichere Ports definieren), da sie von einer doppelt falschen Ausgangsvoraussetzung ausgehen. Das auf Port 80 ein HTTP-Server laufen soll, ist nur eine Empfehlung. Es kann dort genau so gut eine unerwünschte Anwendung laufen. Ebenso ist es möglich, dass ein HTTP-Server (zusätzlich) auf einem anderen Port läuft. Dies kommt besonders bei „Geschlossenen Benutzer Gruppen“ vor. Somit handelt man sich mit einer solchen Einstellung nur eine vermeidliche Sicherheit ein („Security by Obscurity“ ist keine Sicherheit) und evtl. noch zusätzliche Probleme, weil ein Server nicht erreichbar ist.

Auch das Tunneln von Verbindungen von Clients durch den Proxy lässt sich so nicht verhindern, da die Gegenseite durchaus auf einem der „Safe_ports“ lauschen kann. Die ISO/OSI-Leyer 3-5 sind nicht geeignet, dies zu unterbinden und bei darüber liegenden Leyern muss man dann jedes Paket einzeln bewerten, womit man sich die SSL-Einstellungen auch schenken kann, denn dies schließt sich gegenseitig aus.

Die Argumentation der Squid-FAQ hierzu, dass jemand den Proxy als SMTP-Relay benutzen könnte, ist insoweit nicht überzeugend, als dies bedeuten würde, dass der Proxy von außen für jede interessierte Person erreichbar ist. Wer eine solche Umgebung betreibt, der hat aber eher noch ganz andere Probleme.

#  TAG: http_access
#   Allowing or Denying access based on defined access lists
…
#Recommended minimum configuration:
#
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager
# Deny requests to unknown ports
http_access deny !Safe_ports
# Deny CONNECT to other than SSL ports
http_access deny CONNECT !SSL_ports
#
# We strongly recommend to uncomment the following to protect innocent
# web applications running on the proxy server who think that the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
# Exampe rule allowing access from your local networks. Adapt
# to list your (internal) IP networks from where browsing should
# be allowed
#acl our_networks src 192.168.1.0/24 192.168.2.0/24
#http_access allow our_networks
# And finally deny all other access to this proxy
http_access deny all

Mittels „allow“ oder „deny“ wird der Zugriff, basierend auf ACLs erlaubt oder unterbunden.

Wenn keine Access-Einstellung vorhanden ist, wird jeder Zugriff zurück gewiesen. Anders aber, wenn keine Access-Einstellung zutrifft, dann wird das Gegenteil der letzten Einstellung verwendet, d.h. wenn die Letzte Einstellung eine Ablehnung „deny“ ist, wird der Zugriff erlaubt. Deshalb ist es sindvoll, als letzte Einstellung je nach Bedarf, ein „deny all“ oder „allow all“ zu verwenden. Ansonsten gilt, dass die erste passende Einstellung verwendet wird.

Die obigen ersten beiden Access-Einstellungen erlauben den Zugriff auf die ACL „manager“ mittels der ACL „localhost“, die die Client-IP-Adressen auf 127.0.0.1 (Localhost) reduziert, und verbietet ihn ansonsten für alle anderen. Zuvor war in der ACL „manager“ definiert worden, dass es sich hierbei um das Protokoll „cache_object“ handelt. Somit wird hier festgelegt, dass dieses Protokoll nur vom lokalem Rechner aus aufgerufen werden kann.

Die beiden nächsten Access-Einstellungen können dann auch gelöscht werden, wenn die entsprechenden ACLs gelöscht wurden. Ansonsten definieren sie, dass der Zugriff auf alles, was nicht als „Safe_port“ angesehen wird, unterbunden wird, ebenso wie SSL-Verbindungen auf nicht SSL-Ports.

Die letzte Access-Einstellung unterbindet jeglichen sonstigen Zugriff und sollte entweder in „http_access allow all“ geändert werden, wenn man weiterhin surfen möchte oder es sollte zuvor eine ACL für die Clients definiert die dies dürfen und ein entsprechender Access-Tag gesetzt werden.

Eine ACL und ein Access-Eintrag in einem Netz (10.0.0.0/255.255.255.255), wo die erste Hälfte der Clients das Internet benutzen darf und die zweite nicht, sähe wie folgt aus:

acl our_networks src 10.0.0.0/25
http_access allow our_networks

Hierbei wird in die ACL „our_networks“ der Bereich der IP-Adressen definiert, diesen dann Zugriff gewährt und allen anderen nicht. Dieses müsste nun vor der ACL http_access deny all in die Konfigurationsdatei eingefügt werden.

Ebenso ist es möglich bestimmte URLs aus zu schießen:

acl banner url_regex ^http://banner[0-9]*.
http_access deny banner

Hier wird zuerst mittels eines Regulären Ausdruckes (Regex) eine ACL auf URLs gebildet, die mit http://banner beginnen und dann keine bis unendlich viele Zahlen im Hostnamen haben. Danach wird mittels „deny“ diese ACL angewendet.

Wenn anstelle des Wertes einer ACL (als in den beiden obigen Beispielen 10.0.0.0/25 oder ^http://banner[0-9]*.) eine in Anführungsstrichen stehender Dateiname angegeben wird, wird der Inhalt dieser Datei zeilenweise ausgewertet. Hiermit erspart man sich die Definition mehrerer ACLs für eine Aufgabe. Es ist so z.B. möglich, sich ganze Listen von Begriffen an zu legen, wo kein Zugriff auf eine URL möglich ist, wenn dieser Begriff bestandteil der URL ist.

Dies ist aber nicht ganz unproblematisch, da der Begriff, nach dem gefiltert wird, immer auch Bestandteil von URLs sein, die nicht gefiltert werden sollen. Wenn man z.B. nach dem Begriff Sex filtert, wird man auch immer den Zugriff auf Webseiten wie z.B. www.staatsexamen.de oder www.rechtsexperte.de mit verhindern. Anderseits wird man mit solchen Filterbegriffen niemals alle evtl. unerwünschten Seiten ausschließen können.

ACLs auf Basis einer User-Authentifizierung sind auch möglich, da hier unterschiedliche Methoden möglich, die auf verschiedenen zusätzlichen Modulen aufbauen, wird dies in einem separaten Kapitel behandelt.

User-Authentifizierung

Die User-Authentifizierung ist beim Squid in zwei unterschiedliche Komponenten aufgeteilt: Authentifikations-Schemas und Authentifikations-Module.

Das Authentifikations-Schema beschreibt, wie der Squid-Proxy die Anmeldeinformationen (Username und Passwort) vom User erhält. Hierbei werden die Schemas entsprechend der im Konfigurationsfile vorgegebenen Reihenfolge angewendet. Der Hauptunterschied bei den drei vorhandenen Schemata ist ein Sicherheitsaspekt. Beim Basis-Schema wird auch das Passwort im Klartext im Netz übertragen.

Das Authentifikations-Modul übernimmt dann die eigentliche Überprüfung der übermittelten Anmeldeinformationen, wobei es aus externen Komponenten besteht. Die auf das Basis- oder NTLM-Schema aufsetzenden Module lesen in einer Endlosschleife von „STDIN“, erwachten „username password“ (entweder bei Basis unverschlüsselt oder bei NTLM verschlüsselt) und geben entsprechend dem Ergebnis der Authentifizierungsprüfung „OK“ oder „ERR“ auf „STDOUT“ zurück. Auf diese Basis lässt sich auch eine eigene Lösung aufsetzen.

Der Squid Proxy bietet somit diverse Authentifizierungsmöglichkeiten an, mit denen es sowohl möglich ist, für den Squid eine eigenständige Passwort-Datei zu nutzen, die „Pluggable Authentication Modules (PAM)“ zu verwenden, gegen eine Windows NT Domäne, ein Windows „Active Directory Service (ADS)“ oder einen „LDAP“-Server zu authentifizieren oder selber ein Programm/Skript hierfür zu schreiben.

Authentifizierung mittels Passwortdatei

Bei einem selbst kompilierten „Squid“ muss zuerst das entsprechende Modul erzeugt werden. Hierfür muss in dem Verzeichnis, in dem der Source-Code des Squids liegt in das entsprechende Verzeichnis gewechselt werden.

$ cd helpers/basic_auth/NCSA/
$ make
# make install

Nun liegt das entsprechende Modul „ncsa_auth“ in dem Verzeichnis /usr/local/squid/bin und kann in der „squid.conf“ eingebunden werden. Bei einem GNU/Debian-Paket liegen alle Module im Verzeichnis /usr/lib/squid.

#  TAG: auth_param
…
#Default:
# none
auth_param basic program /usr/local/squid/bin/ncsa_auth /usr/local/squid/etc/passwd
# auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd # bei GNU/Debian
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours

Die Angabe children 5 bezieht sich auf die Anzahl an Prozessen die für die User-Authentifizierung gleichzeitig gestartet wird. Der bei realm stehende Text wird bei der Passwort-Abfrage den Usern angezeigt. Bei credentialsttl wird die Dauer der Gültigkeit einer User-Authentifizierung angegeben. Alle diese Werten können so übernommen werden.

Mittels einer entsprechenden ACL wird nun der Zugriff geregelt:

#  TAG: acl
…
acl manager proto cache_object
acl users proxy_auth "/etc/squid/admins"
acl users proxy_auth REQUIRED
#  TAG: http_access
…
http_access allow manager admins
http_access deny manager
http_access allow users

Mittels dieser ACL wird fest gelegt, welche Benutzer Zugriff erhalten sollen. Hierbei können auch mehrere, durch Leerzeichen getrennte, Benutzernamen oder eine, in Anführungszeichen eingeschlossene, Datei angegeben werden. Da aber schon das Authentifizierung-Modul gegen eine Datei prüft, würde dies bei diesem Modul eine Doppelpflege bedeutet. Dies lässt sich mittels der Verwendung von „REQUIRED“, anstelle der Usernamen, vermeiden. Damit wird jede gültige Anmeldung akzeptiert.

Man kann aber zusätzlich eine Benutzerliste dazu verwenden, den Zugriff auf geschlossene Bereiche, wie dem Squid-Management, nur bestimmten Usern zu ermöglichen.

Nun muss nur noch die entsprechende Passwort-Datei angelegt werden. Diese Datei ist im sog. NCSA-Format, wie es auch vom Web-Server „Apache“ verwendet wird. Deshalb kann auch dessen Programm htpasswd hierzu verwendet werden, es erfüllt die gleiche Aufgabe. Ansonsten gibt es noch unter htpasswd ein Source-File.

Ansonsten ist noch darauf zu achten, dass die Passwort-Datei von Squid gelesen werden kann, aber von keinem anderen user.

chown squid.squid passwd
chmod 600 passwd

Squid 2.4:

#  TAG: authenticate_program
…
#       authenticate_program /usr/local/squid/bin/ncsa_auth /usr/local/squid/etc/passwd
#
#Default:
# none

Diese Option ist mit der Squid Version 2.5. durch die Option auth_param ersetzt worden und ist dort mit dem „Basis-Schema“ zu vergleichen. Dieses Beispiel bewirkt die gleiche Authentifizierung gegen eine Passwort-Datei wie das vorherige Beispiel.

Authentifizierung mittels Pluggable Authentication Modules (PAM)

Bei PAM handelt es sich um ein System von Software-Bibliotheken die die Authentifizierungs-Anfragen einzelner Programme gegenüber dem System verarbeiten.

Das Squid-Modul, das die Verbindung zu diesen Bibliotheken herstellt, wird wie folgt kompiliert:

$ cd helpers/basic_auth/PAM/
$ make
# make install

Bestimmte PAM Module (z.B. „shadow password authentication“) benötigen dieses Programm installiert als Root mit gesetztem setuid-Bit um Zugriff auf die Passwort-Datei zu erhalten:

# chown root /usr/local/squid/libexec/pam_auth
# chmod u+s /usr/local/squid/libexec/pam_auth

Nun muss dieses Modul noch in die Squid Konfiguration eingebunden werden:

#  TAG: auth_param
…
#Default:
# none
auth_param basic program /usr/local/squid/libexec/pam_auth
# auth_param basic program /usr/lib/squid/pam_auth # bei GNU/Debian
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
#  TAG: acl
…
acl users proxy_auth "/etc/squid/allow_users"
#  TAG: http_access
…
http_access allow users

Im Idealfall war es dies schon und die Zugriffskontrolle funktioniert über die zentrale Passwort-Datei des Systems. Da nun alle authentifizierten User über den Squid Zugriff auf das Web haben, kann es in diesem Fall sinnvoll sein, einen eigenständige Berechtigungsdatei zu führen und mittels einer ACL einzubinden.

Falls die PAM-Voreinstellungen nicht greifen, muss für den Squid Proxy noch ein entsprechende Eintrag in der PAM-Konfiguration erstellt werden. Konfiguriert wird PAM mittels einer Datei /etc/pam.conf oder eines Verzeichnis /etc/pam.d. Wenn dieses Verzeichnis vorhanden ist, wird die Datei ignoriert.

Entsprechend der lokalen Gegebenheit (Datei oder Verzeichnis) müssen für den Squid noch mindestens zwei Einträge erstellt werden.

In der Datei /etc/pam.conf:

squid auth    required pam_unix.so
squid account required pam_unix.so

Oder in der neu anzulegenden Datei /etc/pam.d/squid:

auth    required pam_unix.so
account required pam_unix.so

Ebenso müssen eigene Einträge erstellt werden, wenn ein anderes PAM-Modul verwendet werden soll, um zum Beispiel eine Authentifizierung mittels PAM gegen einen LDAP-Server zu betreiben.

Mehr Infos zu PAM bietet man 8 pam.

Authentifizierung mittels Lightweight Directory Access Protokoll (LDAP)

Für eine Authentifizierung mittels „LDAP“ gibt es unterschiedliche Ansätze.

Der einfachste Ansatz ist hierbei auf die Authentifizierung per PAM zurück zu greifen und dieses Verfahren um LDAP-Support zu erweitern.

Hierfür müssen in der Datei /etc/pam.d/squid die folgenden Einträge stehen:

auth    sufficient pam_ldap.so
auth    required   pam_unix.so try_first_pass
account sufficient pam_ldap.so
account required   pam_unix.so

Hier wird nun zuerst gegen einen LDAP-Server geprüft und wenn dies erfolglos war, ohne erneute Passwort-Eingabe, gegen die zentrale Passwort-Datei.

Eine andere Möglichkeit besteht in der Verwendung des Moduls „squid_ldap_auth“ (bei GNU/Debian hat man es in „ldap_auth“ umbenannt). Der Aufruf des Moduls erfolgt über squid_ldap_auth -b basedn [options] [ldap_server_name[:port]]…. Welche Optionen im Detail zur Verfügung stehen lässt sich durch einen einfachen Aufruf des Moduls auf einer Konsole feststellen.

Die Option -b basedn ist auf jeden Fall zwingend und Erfahrungsgemäß ist auch die Übergabe der Protokollversion mittels -v 2|3 oft sinnvoll, da das Module nicht immer die richtige Version erkennt und somit unnötig Fehler produziert werde. Es sollte auf jeden Fall auf einer Konsole eine Abfrage getestet werden, bevor das Module in der „squid.conf“ aktiviert wird:

echo "
" | /usr/local/squid/libexec/squid_ldap_auth -v 3 -b dc=example,dc=org -f "uid=%s" localhost, wobei „dc=example,dc=org“ nur ein Beispiel für einen Base DN ist.

Wenn als Ausgabe ein „OK“ erscheint, hat alles funktioniert und der Integration der LDAP-Authentifizierung in Squid steht nichts mehr im Wege. Bei einem Fehler sollte auf jeden Fall in den Logfiles des LDAP-Servers nachgesehen werden (bzw. das Log-Level dort erhöht werden und die Abfrage wiederholt).

Die Einbindung in die Squid-Konfiguration erfolgt dann wie gewohnt:

#  TAG: auth_param
…
#Default:
# none
auth_param basic program /usr/local/squid/libexec/squid_ldap_auth -v 3 -b dc=example,dc=org -f "uid=%s" localhost
# auth_param basic program /usr/lib/squid/ldap_auth -v 3 -b dc=example,dc=org -f "uid=%s" localhost # bei GNU/Debian
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours

Für eine dettailierter Zugriffsnegelung muss auch hier wieder eine ACL definiert werden. Neben der schon bekannten Form der externen Liste bietet sich gerade hier eine LDAP-Abfrage an. Hierfür steht das zum Squid gehörende Programm „squid_ldap_group“ zur Verfügung.

Wenn „squid_ldap_group“ nicht über die verwendete Linux-Distribution installiert wurde, muss es als erstes kompiliert werden. Wichtig ist hierbei, dass beim Kompilieren die Header-Dateien von OpenLDAP installiert sind.

$ cd helpers/external_acl/ldap_group/
$ make
# make install

Dann sollte ein Test dieses Programms und des Filters auf einer Konsole erfolgen:

echo " " | /usr/lib/squid/squid_ldap_group -b dc=example,dc=org -v 3 -f "(&(objectClass=posixGroup)(cn=%a)(memberUid=%v))" localhost

Hier wird mittels eines LDAP-Filter getestet, ob es einen LDAP-Eintrag gibt, der als Inhalt die Klasse „posixGroup“ hat – also eine Benutzergruppe ist – und den Übergebenen Gruppennamen z.B. „squid_user“ hat und den Eintrag „memberUid“ mit dem übergebenen User-Name. Oder anders gesagt, ist der übergebene Benutzer Mitglied der Benutzergruppe „squid_user“.

Bei einem „OK“ als Rückgabewert sollte man aber auch einmal mit falschen Werten testen um zu sehen, ob der Filter dann einer „ERR“ zurück gibt oder nicht einfach alles bestätigt.

Die Einbindung des Filters erfolgt nun an mehreren Stellen.

#  TAG: external_acl_type
#         external_acl_type name [options] FORMAT.. /path/to/helper [helper arguments..]
…
external_acl_type ldap_filter %LOGIN /usr/local/squid/libexec/squid_ldap_group -b ou=group,dc=example,dc=org -v 3 
	-f "(&(objectClass=posixGroup)(cn=%a)(memberUid=%v))" localhost
…
#  TAG: acl
#       acl acl_name external class_name [arguments...]
…
acl users external ldap_filter squid_user

Zuerst wird die externe ACL-Klasse „ldap_filter“ definiert. Das übergebene Format „%LOGIN“ beinhaltet den schon durch die Authentifizierung festgestellten Usernamen. Aufgerufen wird diese externe ACL-Klasse dann mit dem zweiten Eintrag, dem als Parameter „squid_user“ übergeben wird. Durch diese Übergabe des abzufragenden Gruppennamens ist es möglich, mehrere Gruppen abzufragen und somit strukturiertere Zugriffsberechtigungen zu setzen. Nun muss nur noch der Zugriff für diese ACL definiert werden:

#  TAG: http_access
…
http_access allow users

Authentifizierung gegen eine Windows NT Domäne

Für die Authentifizierung gegen die Konten einer Windows NT Domäne gibt es z.Zt. zwei unterschiedliche Module („SMB“ und „MSNT“). Nachfolgend wird sich nur auf das Modul „SMB“ bezogen.

Dieses Module prüft die Zugangsberechtigung wahlweise gegen einen SaMBa-Server als auch gegen eine NT-Domäne. Es setzt hierbei aber eine SaMBa-Installation zwingend voraus, ermöglicht aber eine Konfiguration über Rechtevergabe auf der NT-Domäne.

Auch hier muss das entsprechende Modul zuerst kompiliert werden:

$ cd helpers/basic_auth/SMB/
$ make
# make install

Die weitere Konfiguration erfolgt über den NT-Domän-Kontroller (bzw. dem entsprechenden SaMBa-Server), indem die Datei netlogonproxyauth ausgewertet wird. Die Datei hat als einzigen Inhalt das Wort „allow“. Nun muss noch auf Seiten der NT-Rechteverwaltung einem User oder einer Lokalen bzw. Globalen Gruppe (z.B. „Internet-Nutzer“) Leserecht für diese Datei gewährt. Danach können sich die User mit ihrem NT-Passwort am Squid-Proxy anmelden.

In der Squid Konfiguration wird dieses Modul wie folgt eingebunden:

#  TAG: auth_param
…
auth_param basic program /usr/local/bin/smb_auth -W
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
#  TAG: acl
…
acl domainusers proxy_auth REQUIRED
#  TAG: http_access
…
http_access allow domainusers

Dem Module smb_auth wird mittels der Option der Domänname der NT-Domäne (bitte nicht mit der DNS-Domain verwechseln) übergeben. Dies ist zwar nicht absolut notwendig, da das Modul ansonsten per Broadcast-Umfrage diesen finden würde, aber es beschleunigt die Anmeldung doch ungemein.

Ansonsten wird mittels „REQUIRED“ allen gültig Angemeldeten, sprich die, die die entsprechenden Rechte auf NT-Seite erhalten haben, Zugriff auf den Proxy gewährt.

„Squid“ als Transparenter HTTP-Proxy

Ein beliebtest Einsatzgebiet des Squids ist der Einsatz als Transparenter Proxy. Der Vorteil hierbei ist, dass auf den Clients kein Proxy im Browser eingetragen werden muss (wobei hierfür in Netzwerken durchaus zentrale Möglichkeiten bestehen, die Konfiguration der Clients zu verändern). Der evtl. Nachteil ist aber, dass auf einem transparenten Proxy keine User-Authentifizierung möglich ist und dass das Ganze nur bei HTTP (und nicht bei HTTPS oder FTP) funktioniert.

Umgesetzt wird dies durch eine Umleitung aller TCP-Pakete am Router, die von den Clients zu einem externen Port 80 gesendet werden. Diese Pakete werden nun direkt an den Squid-Proxy umgeleitet. Da die Clients nun aber nichts über einen Proxy in ihrer Verbindung zu externen Servern wissen, können sie auch keine speziellen Anfragen an diesen Proxy stellen. Hierdurch versagen nun die HTTPS- und FTP-Requests, da erstere, auf Sicherheit beruhend, nun den Proxy als „man-in-the-middle attack“ ansehen und letztere neben der Download-Verbindung eine weitere Verbindung für das Senden von Daten benötigen (beim normalen Proxy wird zwischen Client und Proxy eine HTTP-Verbindung aufgebaut und erst vom Proxy zum FTP-Server eine FTP-Verbindung).

Damit der Squid als transparenter Proxy arbeitet müssen die folgenden Einstellungen geändert werden:

#  TAG: httpd_accel_host
#  TAG: httpd_accel_port
…
#Default:
# httpd_accel_port 80
httpd_accel_host virtual
httpd_accel_port 80
#  TAG: httpd_accel_with_proxy  on|off
…
httpd_accel_with_proxy on
#  TAG: httpd_accel_uses_host_header    on|off
…
httpd_accel_uses_host_header on

Weiterhin ist es notwendig mittels „iptables“-Regeln alle TCP-Pakete an den Proxy umzuleiten:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

Diese Regel sollte dann in einem Skript stehen, dass automatisch nach dem Booten ausgeführt wird.

„Squid“ starten

Nun kann der Squid Proxy mittels /usr/local/squid/bin/squid gestartet werden. Wenn dies nicht zu dem gewünschten Erfolg führt und der Squid auch keine Fehlermeldung ausgibt, sollte man folgendes prüfen:

• Sind die für den Start des Proxies angegebene User und Gruppe vorhanden?
• Ist ein „Fully Qualified Domain Name“ für den Proxy-Server definiert?
• Hat der Squid Schreibrechte auf sein PID-File, seinen Cache und seine Logfiles?
• Das Logfile-Debuging hoch setzen um evtl. mehr Fehlermeldungen zu erhalten.

Wenn der Squid läuft, sollte man für ihn ein Runlevel-Skript anlegen und die entsprechenden Links in den Runlevel-Verzeichnissen anlegen. Eine Vorlage für dieses Skript ist bei den meisten Distributionen unter /etc/rc.d/init.d/skeleton zu finden.