Inhaltsverzeichnis
Bewertung 2
Die Kandidaten sollten in der Lage sein, einen Proxyserver unter Verwendung von Squid zu installieren und zu konfigurieren. Dieses Lernziel beinhaltet die Implementierung von Zugriffsregeln, die Einrichtung von Authentisierung und die Nutzung von Speicherverwendung.
Schlüsseldateien, Begriffe und Hilfsmittel beinhalten:
- squid.conf
- acl
- http_access
Konfiguration von SQUID
Die gesamte Konfiguration des Proxies läuft – analog zur Konfiguration von Apache – in einer einzigen Datei squid.conf ab. In der Regel liegt diese Datei in /etc oder einem separaten Verzeichnis /etc/squid. Diese Konfigurationsdatei kann sehr umfangreich sein, es gibt alleine etwa 200 verschiedene Direktiven, die zum Teil auch mehrfach vorkommen dürfen. Hier werden nur einige wichtige Direktiven besprochen, die zur Inbetriebnahme von SQUID nötig sind. http_port [Hostname:|IP-Adresse:]Portnummer Die Portnummer auf der Squid nach Anfragen von Clients lauscht. Ohne die Angaben von Hostnamen bzw. IP-Adressen gilt der angegebene Port für alle Clients. Ansonsten kann diese Anweisung für verschiedene Clients verschiedene Ports benutzen. Dazu muß für jeden gewünschten Port eine separate Befehlszeile angegeben werden. cache_mem GrößeMB|KB Gibt die Größe des von SQUID reservierten Arbeitsspeichers für bestimmte Objekte an. Das ist NICHT die Größe des gesamten von SQUID als Cache verwendeten Speichers! cache_dir ufs Verzeichnis MinSpeicher FirstLevelDir SecondLevelDir Legt fest, in welchem Verzeichnis der Plattencache von SQUID angelegt werden soll. Das ufs gibt den Dateisystemtyp an, es gibt auch andere, aber ufs ist der gebräuchlichste. Das Verzeichnis ist ein Pfad zu einem Verzeichnis, in dem ausreichend Platz vorhanden sein muss und SQUID Schreibrecht hat. MinSpeicher ist die minimale Anzahl von Megabytes, die reserviert werden kann. In der Praxis wird dieser Wert aber häufig überschritten. FirstLevelDir gibt die Anzahl der in erster Ebene liegenden Verzeichnisse an, die SQUID im Cache anlegt. Ein üblicher Wert ist hier 16. SecondLevelDir ist die Anzahl der Verzeichnisse, die in jedem FirstLevelDir angelegt werden. Ein üblicher Wert wäre hier 256. Eine typische Angabe dieses Befehls wäre also etwa
cache_dir ufs /var/squid/cache 100 16 256
Diese Angabe ist zwingend zum Betrieb des Proxies erforderlich.
Eine Minimalkonfiguration schließt natürlich noch ein paar ACLs und Zugriffsregeln ein, die weiter unten beschrieben werden. An dieser Stelle schon mal eine absolut minimalistische Konfigurationsdatei, mit der ein Anfang gemacht werden kann:
cache_mem 8 MB cache_dir ufs /var/squid/cache 100 16 256 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl all src 0.0.0.0/0.0.0.0 acl allowed_hosts src 192.168.10.0/255.255.255.0 http_access allow manager localhost http_access deny manager all http_access allow allowed_hosts http_access deny all icp_access allow allowed_hosts icp_access deny all
Zugriffskontrolle mit Access-Listen (ACLs)
Zugriffskontrolle unter SQUID läuft grundsätzlich über sogenannte Access-Listen (ACLs). Diese Listen sind noch keine Einschränkung (oder Erlaubnis) von Rechten, sondern sie definieren zunächst einmal nur eine Liste eines bestimmten Typs. Später können dann Zugriffsrechte gesetzt werden, die diese Listen benutzen.
Die Definition von ACLs kann auf zwei verschiedene Arten erfolgen. Entweder wird mit
acl ACLName ACLTyp Element1 Element2 ...
Eine Liste mit dem Namen ACLName und dem Typ ACLTyp erzeugt, die den Inhalt Element1 Element2 … enthält, oder der Inhalt wird aus einer Datei gelesen, indem geschrieben wird
acl ACLName ACLTyp "Dateiname"
Die Anführungszeichen um den Dateinamen sind notwendig, damit SQUID nicht glaubt, der Dateiname wäre ein Element der Liste.
Jede ACL benötigt einen eindeutigen und einmaligen Namen. Wenn mehrere ACL-Direktiven sich auf den selben Namen beziehen, so wird das additiv gewertet, d.h. die Konstruktion
acl VERSUCH src 192.168.1.1/32 acl VERSUCH src 192.168.1.2/32
hat exakt die selbe Bedeutung wie
acl VERSUCH src 192.168.1.1/32 192.168.1.2/32
SQUID bietet eine Vielzahl verschiedener ACL-Typen an, die es ermöglichen, unterschiedlichste Kriterien für die Formulierung von Zugriffsrechten zu nutzen. Die wichtigsten sind arp MAC-Adresse … Nimmt eine Liste von MAC-Adressen (Ethernet-Adressen) als Argument an.
acl VERSUCH arp 00:00:11:22:33:44 00:33:44:55:66:77
src IP-Adresse/Netzmaske … Nimmt eine Liste von IP-Adressen und Netzmasken als Argument an. Die Netzmasken können entweder in der Kurzform (z.B. /24) angegeben werden, oder in der klassischen Form (z.B. /255.255.255.0). Die Liste bezeichnet die Adressen der Clients, die SQUID benutzen wollen.
acl VERSUCH src 192.168.1.0/24 192.168.100.7/255.255.255.255
dst IP-Adresse/Netzmaske … Nimmt eine Liste von IP-Adressen und Netzmasken als Argument an. Die Netzmasken können entweder in der Kurzform (z.B. /24) angegeben werden, oder in der klassischen Form (z.B. /255.255.255.0). Die Liste bezeichnet die Adressen der Server, auf die SQUID zugreifen soll. srcdomain Domainname … Nimmt eine Liste von Domainnamen an, die durch Rückwärtsauflösung eines DNS-Servers verifizierbar sein müssen. Die Domainnamen sollten mit einem Punkt beginnen, etwa .mydomain.de. Die Liste bezeichnet die Domainnamen der Clients, die SQUID benutzen wollen.
acl VERSUCH srcdomain .mydomain.de .myseconddomain.de
dstdomain Domainname … Nimmt eine Liste von Domainnamen von (Web-)Servern an, auf die SQUID zugreifen soll. time [Tag] h1:m1-h2:m2 … Nimmt eine Liste von Zeitfenstern auf. Der optional angegebene Wochentag wird mit den folgenden Buchstaben ausgedrückt: M=Montag, T=Dienstag, W=Mittwoch, H=Donnerstag, F=Freitag, A=Samstag, S=Sonntag. Die Angaben h1:m1 und h2:m2 geben Stunden und Minuten an.
acl VERSUCH time 09:30-17:00 # Jeden Tag von 9:30 bis 17:00 Uhr acl VERSUCH time S 00:00-23:59 # Sonntags immer
url_regex [-i] Regulärer_Ausdruck … Nimmt eine Liste von regulären Ausdrücken entgegen, die URLs beschreiben. Das optionale -i Argument schaltet die Unterscheidung zwischen Groß- und Kleinschreibung ab.
acl VERSUCH url_regex http://.* ftp://.*
urlpath_regex [-i] Regulärer_Ausdruck … Nimmt eine Liste von regulären Ausdrücken entgegen, die nur den Pfadanteil einer URL beschreiben (ohne Protokollheader und Hostname)
acl VERSUCH urlpath_regex -i \.gif$ \.jpg$ \.png$
port Portnummer … Nimmt eine Liste von Ziel-Portnummern von Servern an, die entweder als Liste einzelner Ports oder als Bereich (mit Bindestrich getrennt) formuliert werden.
acl VERSUCH port 80 81 443 1234-1299
proto Protokollnamen … Nimmt eine Liste von durch SQUID unterstützte Protokollnamen an
acl VERSUCH proto FTP HTTP
browser [-i] Regulärer_Ausdruck … Nimmt eine Liste von regulären Ausdrücken an, die den Browser des Clients beschreiben (Wert von User-Agent im Header der Anfrage).
acl VERSUCH browser [mM]ozilla.*
proxy_auth Username … Nimmt eine Liste von Usernamen an, die über einen externen Prozeß authentifiziert wurden. Das Schlüsselwort REQUIRED bedeutet, dass jeder existierende Benutzer gemeint ist.
acl VERSUCH proxy_auth peter michael gabi
proxy_auth_regex [-i] Regulärer_Ausdruck … Wie proxy_auth, nur dass reguläre Ausdrücke statt Usernamen verwendet werden.
Wenn über die ACLs die entsprechenden Listen formuliert wurden, so können anschließend sogenannte Access-Regeln mit Hilfe einzelner ACLs formuliert werden. Zu diesem Zweck stehen verschiedene Regeltypen zur Verfügung. Dem Regeltyp folgt die Angabe von entweder allow oder deny und eine oder mehrere vorher definierte ACLs. Den ACLs kann ein Ausrufungszeichen (NOT) vorangestellt werden, was zu einer logischen Negation führt.
acl VERSUCH src 192.168.1.0/24 http_access allow VERSUCH
Zunächst wird eine ACL mit Name VERSUCH erstellt, die alle Rechner des Netzes 192.168.1.0 beinhaltet. In der zweiten Anweisung wird formuliert, dass eine HTTP-Anfrage für diese ACL erlaubt ist. Wenn ein Client also eine IP-Adresse hat, deren erste drei Bytes 192.168.1 sind, so kann er HTTP-Anfragen machen.
Die wichtigsten Access-Regeln werden hier kurz erklärt: http_access Erlaubt oder verbietet Clients den Zugriff auf den HTTP-Port von SQUID. Wenn keine solche Anweisung in der Konfigurationsdatei steht, dann ist HTTP-Zugriff verboten. Sind aber http_access Regeln formuliert, treffen aber nicht zu, so wird die letzte http_access Regel in ihrem Wahrheitswert umgedreht und als Standard-Einstellung verwendet. Hat also die letzte http_access-Anweisung ein deny, so ist die Voreinstellung für alle nicht zutreffenden Fälle ein allow und umgekehrt. allways_direct Definiert, welche Anfragen direkt an den Server geschickt werden, ohne den Cache zu benutzen. never_direct Definiert, welche Anfragen nie direkt an den Server geschickt werden, ohne den Cache zu benutzen.
Benutzerauthentifizierung
SQUID kann Zugang auf seine Dienste abhängig von Benutzerauthentifizierung ermöglichen. Das ist oft besser, als nur über IP-Adressen oder Domainnamen zu entscheiden, ob ein Zugriff gewährt wird oder nicht, insbesondere, wenn es sich um ein Mehrbenutzersystem wie Linux handelt.
Wenn ein Zugriff über die ACL proxy_auth gesteuert wird, dann wird eine Authentifizierung eingeleitet. Es gibt verschiedenste Modelle, mit denen SQUID diese Authentifizierung erledigt. Es kann sowohl über Unix-Passwörter, als auch über externe Dienste wie Windows-Auth-Server, LDAP-Server oder PAM gesteuert werden.
Der Vorgang ist mehr oder weniger immer der selbe:
- Der Client reicht eine Anfrage an SQUID weiter
- SQUID beantwortet diese Anfrage mit einem 401 (Unauthorized) und veranlasst damit den Browser des Clients, eine User- und Passwortabfrage anzuzeigen.
- Der Client füllt diese Abfrage aus und wiederholt die Anfrage an SQUID, diesmal mit Username und Passwort im Header.
- SQUID überprüft anhand der in der Konfigurationsdatei eingetragenen Methode, ob die Angaben passen. Eventuell benötigt SQUID dazu externe Authentifizierungsserver.
- Das Authentifizierungsmodul sendet entweder ein OK oder ein ERR an den Proxy zurück und er kann dann entweder die gewünschte Seite holen oder seine Mitarbeit verweigern.
Mit Hilfe der Direktive auth_param kann festgelegt werden, welche Programme zur Authentifizierung verwendet werden sollen.