| SUSE LINUX – Administrationshandbuch Kapitel 18. Internet / 18.3. Proxy-Server: Squid | ||||
|---|---|---|---|---|
 | 18.2. Konfiguration eines ADSL / T-DSL Anschlusses | Kapitel 19. Sicherheit im Netzwerk |  | |
| SUSE LINUX – Administrationshandbuch Kapitel 18. Internet / 18.3. Proxy-Server: Squid | ||||
|---|---|---|---|---|
| 18.2. Konfiguration eines ADSL / T-DSL Anschlusses | Kapitel 19. Sicherheit im Netzwerk | | |
Squid ist ein weit verbreiteter Proxy-Cache für Linux/UNIX-Plattformen. Wir werden beschreiben, wie er zu konfigurieren ist, welche Systemanforderungen bestehen, wie das eigene System konfiguriert sein muss, um transparentes Proxying durchzuführen, wie man Statistiken über den Nutzen des Cache mithilfe von Programmen wie Calamaris und cachemgr erhält oder wie man Web-Inhalte mit squidGuard filtert.
Squid fungiert als Proxy-Cache. Es verhält sich wie ein Makler, der Anfragen von Clients erhält (in diesem Fall Web-Browser) und an den zuständigen Server-Provider weiterleitet. Wenn die angeforderten Objekte beim Vermittler ankommen, behält er eine Kopie davon in einem Festplatten-Cache.
Vorteilhaft ist das, wenn mehrere Clients dasselbe Objekt anfordern: Sie können nun direkt aus dem Festplatten-Cache bedient werden, also wesentlich schneller als aus dem Internet. Dies spart gleichzeitig Netzwerk Transfervolumen.
Squid ist kein generischer Proxy. Normalerweise vermittelt er nur zwischen HTTP-Verbindungen. Außerdem unterstützt er die Protokolle FTP, Gopher, SSL und WAIS, jedoch keine anderen Internet-Protokolle wie Real Audio, News oder Videokonferenzen. Squid greift auf das UDP-Protokoll nur zur Unterstützung der Kommunikation zwischen verschiedenen Caches zurück. Aus diesem Grund werden auch andere Multimedia-Programme nicht unterstützt.
Man kann Squid zusammen mit einer Firewall verwenden, um interne Netzwerke durch den Einsatz eines Proxy-Cache nach außen zu schützen. Die Firewall verweigert mit Ausnahme von Squid allen Clients den Verbindungsaufbau zu externen Diensten. Alle WWW-Verbindungen müssen dann durch den Proxy aufgebaut werden.
Im Falle einer Firewall-Konfiguration mit einem DMZ würde man dort den Proxy einsetzen. In diesem Fall ist es wichtig, dass alle Rechner in der DMZ ihre Protokolldateien an Rechner innerhalb des gesicherten Netzwerks senden.
Ein Möglichkeit der Implementierung eines so genannten „transparenten“ Proxy wird in Abschnitt 18.3.6. “Transparente Proxy-Konfiguration” behandelt.
Man kann mehrere Proxies so konfigurieren, dass Objekte zwischen ihnen ausgetauscht werden können, um die Systemlast zu reduzieren und die Wahrscheinlichkeit zu steigern, ein bereits im lokalen Netzwerk vorhandenes Objekt zu finden. Möglich sind auch Cache-Hierarchien, so dass ein Cache in der Lage ist, Objektanfragen an Caches der gleichen Hierarchie weiterzuleiten oder einen übergeordneten Cache zu veranlassen, die Objekte von einem anderen Cache im lokalen Netzwerk oder direkt aus der Quelle herunterzuladen.
Die Wahl der richtigen Topologie für die Cache-Hierarchie ist sehr wichtig, da Netzwerkverkehr insgesamt nicht erhöht werden soll. In einem großen Netzwerk bietet es sich an, für jedes Subnetz einen Proxy-Server zu konfigurieren und diesen dann mit einem übergeordneten Proxy zu verbinden, der wiederum mit dem Proxy-Cache vom ISP verbunden wird.
Die gesamte Kommunikation wird vom ICP Internet Cache Protocol gesteuert, das auf dem UDP-Protokoll aufgesetzt ist. Der Datenaustausch zwischen Caches geschieht mittels HTTP Hyper Text Transmission Protocol basierend auf TCP.
Um den besten Server für die gewünschten Objekte zu finden, schickt ein Cache an alle Proxies der gleichen Hierarchie eine ICP-Anfrage. Die Proxies werden mittels ICP-Antworten mit dem Code „HIT“ auf die Anfragen reagieren, falls das Objekt gefunden wurde oder, falls nicht, mit dem Code „MISS“. Im Falle mehrerer HIT-Antworten wird der Proxy-Server einen Server für das Herunterladen bestimmen. Diese Entscheidung wird unter anderem dadurch bestimmt, welcher Cache die schnellste Antwort sendet oder welcher näher ist. Bei einer nicht zufrieden stellenden Antwort wird die Anfrage an den übergeordneten Cache geschickt.
![[Tip]](admon/tip.png) | Tipp |
|---|---|
Zur Vermeidung einer mehrfachen Speicherung von Objekten in verschiedenen Caches des Netzwerks werden ebenfalls ICP-Protokolle verwendet, wie zum Beispiel CARP Cache Array Routing Protocol oder HTCP Hyper-Text Cache Protocol. Je mehr Objekte sich im Netzwerk befinden, desto leichter wird es, das Gesuchte zu finden. | |
Nicht alle im Netzwerk verfügbaren Objekte sind statisch. Es existieren viele dynamisch generierte CGI-Seiten, Zugriffszähler oder verschlüsselte SSL-Dokumente für eine höhere Sicherheit. Aus diesem Grund werden solche Objekte nicht im Cache gehalten: Bei jedem neuen Zugriff hat sich das Objekt bereits wieder verändert.
Für alle anderen im Cache befindlichen Objekte stellt sich jedoch die Frage, wie lange sie dort bleiben sollen. Für diese Entscheidung werden alle Objekte im Cache verschiedenen Stadien zugeordnet.
Durch Header wie Last modified („zuletzt geändert“) oder Expires („läuft ab“) und dem entsprechenden Datum informieren sich Web- und Proxy-Server über den Status eines Objekts. Es werden auch andere Header verwendet, die zum Beispiel anzeigen, dass ein Objekt nicht zwischengespeichert werden muss.
Objekte im Cache werden normalerweise aufgrund fehlenden Speichers ersetzt, und zwar durch Algorithmen wie LRU (engl. Last Recently Used), die zum Ersetzen von Cache-Objekten entwickelt wurden. Das Prinzip besteht im Wesentlichen darin, zuerst die am seltensten gewünschten Objekte zu ersetzen.
Zuerst sollte die maximale Systemlast bestimmt werden. Es ist wichtig, den Systemspitzen besondere Aufmerksamkeit zu schenken, da diese mehr als viermal so hoch wie der Tagesdurchschnitt sein können. Im Zweifelsfall ist es besser, die Systemanforderungen zu überschätzen, da ein am Limit arbeitender Squid zu einem ernsthaften Qualitätsverlust des Dienstes führen kann.
Geordnet nach Wichtigkeit werden in den folgenden Abschnitten die verschiedenen Systemfaktoren aufgezeigt.
Für das Zwischenspeichern spielt Geschwindigkeit eine hohe Rolle. Man sollte sich also um diesen Faktor besonders kümmern. Bei Festplatten ist dieser Parameter als „Zugriffszeit“ in Millisekunden beschrieben. Als Faustregel gilt: Je niedriger dieser Wert, desto besser. Für eine hohe Geschwindigkeit empfiehlt es sich, schnelle Festplatten zu wählen.
Da Squid zumeist kleinere Datenblöcke von der Festplatte zu liest oder abspeichert, ist die Zugriffszeit einer Festplatte wichtiger als der Durchsatz. Gerade hierbei rentieren sich Festplatten mit hohen Drehzahlen, die eine schnelle Positionierung des Lesekopfes ermöglichen. Schnelle SCSI Festplatten erreichen heute Zugriffszeiten unter 4 Millisekunden.
Eine Möglichkeit, die Geschwindigkeit zu erhöhen, ist gleichzeitige Einsatz mehrerer Festplatten oder striping Raid Arrays.
In einem kleinen Cache ist die Wahrscheinlichkeit eines HIT (das gewünschte Objekt befindet sich bereits dort) sehr gering, da der Cache schnell gefüllt sein wird. In diesem Fall werden die selten gewünschten Objekte durch neue ersetzt. Steht jedoch zum Beispiel 1 GB für den Cache zur Verfügung und die Benutzer benötigen nur 10 MB pro Tag zum Surfen, dann dauert es mehr als hundert Tage, bis der Cache voll ist.
Am leichtesten lässt sich die Größe des Cache durch die maximale Übertragungsrate der Verbindung bestimmen. Mit einer Verbindung von 1 Mbit/s wird die maximale Übertragungsrate bei 125 KB/s liegen. Landet der gesamte Datenverkehr im Cache, kommen innerhalb einer Stunde 450 MB zusammen. Wenn man nun annimmt, dass der gesamte Datenverkehr lediglich während acht Arbeitsstunden erzeugt wird, erreicht man innerhalb eines Tages 3,6 GB. Da die Verbindung normalerweise nicht bis zur Kapazitätsgrenze ausgeschöpft wird, kann man davon ausgehen, dass die gesamte Datenmenge, die der Cache bearbeitet, bei ungefähr 2 GB liegt. In diesem Beispiel werden demnach 2 GB Speicher für Squid benötigt, um die Daten aller aufgerufenen Seiten eines Tages im Cache zu halten.
Der von Squid benötigte Speicher ist abhängig von der Anzahl der im Cache zugewiesenen Objekte. Squid speichert Cache-Objektverweise und häufig angeforderte Objekte zusätzlich im Hauptspeicher, damit diese Daten schneller abgefragt werden können. Der Hauptspeicher ist sehr viel schneller als eine Festplatte!
Squid hält auch andere Daten im Speicher, zum Beispiel eine Tabelle mit allen vergebenen IP-Adressen, einen genau festgelegten Domainnamen-Cache, die am häufigsten gewünschten Objekte, Puffer, Zugriffskontrolllisten, etc.
Es ist sehr wichtig, dass ausreichend Speicher für den Squid-Prozess zur Verfügung steht. Sollte er auf Festplatte ausgelagert werden müssen, wird sich die Systemleistung drastisch reduzieren. Für die Cache-Speicherverwaltung kann das Tool cachemgr.cgi verwendet werden. Es wird im Abschnitt 18.3.7.1. “cachemgr.cgi” erläutert.
Das Programm Squid benötigt nicht viel CPU. Nur beim Start und während der Überprüfung des Cache-Inhalts ist die Prozessorlast höher. Der Einsatz eines Multiprozessorrechners steigert die Systemleistung nicht. Zur Effektivitätssteigerung ist es besser, schnellere Festplatten zu verwenden oder mehr Speicher hinzuzufügen.
Der Squid auf SUSE LINUX ist bereits soweit vorkonfiguriert, dass man ihn problemlos sofort nach der Installation starten kann. Als Voraussetzung für einen reibungslosen Start sollte das Netzwerk soweit konfiguriert sein, dass mindestens ein Nameserver und sinnvollerweise auch das Internet erreichbar sind. Probleme kann es bereiten, wenn man eine Wählverbindung mit dynamischer DNS-Konfiguration verwendet. In so einem Fall sollte mindestens der Nameserver fest eingetragen sein, da Squid erst gar nicht startet, wenn er in der /etc/resolv.conf keinen DNS Server findet.
Um Squid zu starten, gibt man auf der Kommandozeile (als root) den Befehl rcsquid start ein. Beim ersten Mal wird zunächst die Verzeichnisstruktur in /var/squid/cache angelegt. Dies wird vom Startskript /etc/init.d/squid automatisch durchgeführt und kann ein paar Sekunden bis Minuten dauern. Erscheint rechts in grün done, wurde Squid erfolgreich gestartet. Auf dem lokalen System kann man die Funktionsfähigkeit von Squid sofort testen, indem man im Browser als Proxy localhost und Port 3128 einträgt. Um den Zugriff auf Squid und somit das Internet für alle zu ermöglichen, braucht man in der Konfigurationsdatei /etc/squid/squid.conf lediglich den Eintrag http_access deny all auf http_access allow all zu ändern. Allerdings sollte man dabei bedenken, dass man den Squid damit komplett für jedermann öffnet. Von daher sollte man unbedingt ACLs definieren, die den Zugriff auf den Proxy regeln. Dazu mehr im Abschnitt 18.3.5.2. “Optionen zur Zugriffskontrolle”.
Hat man Änderungen an der Konfigurationsdatei /etc/squid/squid.conf vorgenommen, muss man Squid dazu bringen, diese neu einzulesen. Das gelingt mit: rcsquid reload.
Alternativ kann man Squid auch komplett neu starten: rcsquid restart. Wichtig ist noch folgendes Kommando: rcsquid status. Damit kann man feststellen, ob der Proxy läuft und mit rcsquid stop wird Squid beendet. Letzteres kann eine Weile dauern, da Squid bis zu einer halben Minute (Option shutdown_lifetime in /etc/squid/squid.conf) wartet, bevor die Verbindungen zu den Clients unterbrochen werden und er dann noch seine Daten auf Platte schreiben muss.
![[Warning]](admon/warning.png) | Beenden von Squid |
|---|---|
Beendet man Squid mit einem kill oder killall, kann das einen zerstörten Cache zur Folge haben, den man dann löschen muss, um Squid wieder starten zu können. | |
Beendet sich Squid nach kurzer Zeit, obwohl er scheinbar erfolgreich gestartet wurde, kann das an einem fehlerhaften Nameserver-Eintrag oder einer fehlenden /etc/resolv.conf liegen. Den Grund für einen gescheiterten Start protokolliert Squid dabei in der Datei /var/squid/logs/cache.log . Soll Squid bereits beim Booten automatisch gestartet werden, muss im YaST Runlevel-Editor Squid für bestimmte Runlevel aktiviert werden.
Bei einer Deinstallation von Squid werden weder Cache noch Log-Dateien entfernt. Man muss das Verzeichnis /var/cache/squid manuell löschen.
Einen lokalen DNS-Server wie BIND9 aufzusetzen, ist durchaus sinnvoll, auch wenn er keine eigene Domain verwaltet. Er fungiert dann lediglich als „Caching-only DNS“ und kann ohne spezielle Konfiguration DNS-Anfragen über die Root-Nameserver auflösen. Trägt man diesen in der /etc/resolv.conf mit der IP-Adresse 127.0.0.1 für localhost ein, findet Squid beim Starten immer einen gültigen Nameserver. Es reicht aus, das Paket zu installieren und BIND zu starten. Den Nameserver des Providers sollte man in der Konfigurationsdatei /etc/named.conf unter forwarders mit seiner IP-Adresse eintragen. Falls man eine Firewall laufen hat, muss man aber darauf achten, dass die DNS-Anfragen auch durchgelassen werden.
Alle Einstellungen zum Squid Proxyserver sind in der Datei /etc/squid/squid.conf vorzunehmen. Um Squid erstmalig starten zu können, sind darin keine Änderungen erforderlich, der Zugriff von externen Clients ist jedoch zunächst gesperrt. Für localhost ist der Proxy freigegeben und als Port wird standardmäßig 3128 verwendet. Die Optionen sind ausführlich und mit vielen Beispielen in der vorinstallierten /etc/squid/squid.conf dokumentiert. Annähernd alle Einträge sind am Zeilenanfang durch ein #-Zeichen auskommentiert; am Zeilenende befinden sich die relevanten Spezifikationen. Die angegebenen Werte entsprechen fast immer den voreingestellten Werten, so dass das Entfernen des Kommentarzeichens, ohne den Parameter der Option zu ändern, bis auf wenige Ausnahmen keine Wirkung hat. Besser ist es, das Beispiel stehen zu lassen und die Option mit dem geänderten Parameter in der Zeile darunter neu einzufügen. So kann man die voreingestellten Werte und Änderungen problemlos nachvollziehen.
![[Important]](admon/important.png) | Update von Version 2.4 auf Version 2.5 |
|---|---|
Nach einem Update von Squid von Version 2.4 auf Version 2.5 muss der Cache des Squid gelöscht werden, da sich das Layout der Verzeichnissstruktur geändert hat. | |
Hat man ein Update von einer älteren Squid-Version durchgeführt, ist es unbedingt zu empfehlen, die neue /etc/squid/squid.conf zu verwenden und nur die Änderungen von der ursprünglichen Datei zu übernehmen. Versucht man die alte squid.conf weiter zu verwenden, läuft man Gefahr, dass die Konfiguration nicht mehr funktioniert, da Optionen immer wieder geändert werden und neue hinzukommen.
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 oder muss. Als <hostname> trägt man den Namen bzw. die IP-Adresse des zu verwendenden Proxies 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 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 Log-Dateien.
Pfadangabe für Log-Dateien.
Pfadangabe für Log-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 Log-Dateien auf verschiedene Platten zu legen.
Ändert man diesen Eintrag auf on, erhält man lesbare Log-Dateien. Allerdings kommen manche Auswerteprogramme damit nicht zurecht.
Mit diesem Eintrag kann man die protokollierten IP-Adressen in den Log-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 Log-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 Log-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 Proxies 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 Proxies zwingend vorschreibt oder die Firewall keinen direkten Zugriff auf das Internet durchlässt.
Squid bietet ein ausgeklügeltes System, um den Zugriff auf den Proxy zu steuern. Durch die Verwendung von ACLs ist es einfach und vielseitig konfigurierbar. Dabei handelt es sich um Listen mit Regeln, die der Reihe nach abgearbeitet werden. ACLs müssen zuerst definiert werden, bevor sie verwendet werden können. Einige Standard-ACLs wie all und localhost sind bereits vorhanden. Das Festlegen einer ACL an sich bewirkt aber noch gar nichts. Erst wenn sie tatsächlich eingesetzt wird, zum Beispiel in Verbindung mit http_access, werden die definierten Regeln abgearbeitet.
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 zum Beispiel 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 zum Beispiel 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.
Normalerweise schickt der Web-Browser an einen bestimmten Port des Proxy-Servers Anfragen und der Proxy stellt die angeforderten Objekte zur Verfügung, ob sie nun im Cache sind oder nicht. Innerhalb eines echten Netzwerks können verschiedene Situationen auftreten:
Aus Sicherheitsgründen ist es besser, wenn alle Clients zum Surfen im Internet einen Proxy verwenden.
Es ist notwendig, dass alle Clients einen Proxy verwenden, egal ob sie sich dessen bewusst sind oder nicht.
In einem Netzwerk wird der Proxy umgezogen, die bestehenden Clients sollen jedoch ihre alte Konfiguration behalten.
In jedem dieser Fälle kann ein transparenter Proxy eingesetzt werden. Das Prinzip ist denkbar einfach: Der Proxy nimmt die Anfragen des Web-Browsers entgegen und bearbeitet sie, sodass der Web-Browser die angeforderten Seiten erhält ohne zu wissen, woher sie kommen. Der gesamte Prozess wird transparent ausgeführt, daher der Name für den Vorgang.
Zuerst sollte sicherstellt sein, dass der Kernel des Proxy-Servers einen transparenten Proxy unterstützt. Andernfalls muss man dem Kernel diese Optionen hinzufügen und ihn neu kompilieren. Genauere Informationen dazu entnehmen Sie bitte dem Kapitel 11. Der Linux Kernel. Kernel Module verändern sich von Version zu Version. Prüfen Sie den aktuellen Stand unter /usr/share/doc/howto/en/html/mini/TransparentProxy-3.html bzw. im Internet: http://www.tldp.org/HOWTO/mini/TransparentProxy-3.html.
Folgende Optionen in der Datei /etc/squid/squid.conf müssen aktiviert werden, um einen transparenten Proxy aufzusetzen:
httpd_accel_host virtual
httpd_accel_port 80 # Port, auf dem sich der tatsächliche HTTP-Server befindet.
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
Alle durch die Firewall eingehenden Anfragen müssen mithilfe einer Port-Weiterleitungsregel an den Squid-Port weitergeleitet werden. Dafür eignet sich das SuSE-eigene Tool SuSEfirewall2. Dessen Konfigurationsdatei findet man in der Datei /etc/sysconfig/SuSEfirewall2. Die Konfigurationsdatei wiederum setzt sich aus gut dokumentierten Einträgen zusammen. Auch wenn wir nur einen transparenten Proxy einrichten wollen, müssen wir einige Firewall-Optionen konfigurieren. Beispielsweise:
Gerät zeigt auf Internet: FW_DEV_EXT="eth1"
Gerät zeigt auf Netzwerk: FW_DEV_INT="eth0"
Auf Ports und Dienste (siehe /etc/services) in der Firewall wird von nicht vertrauenswürdigen Netzwerken also dem Internet zugegriffen. In diesem Beispiel bieten wir lediglich Web-Dienste nach außen hin an:
FW_SERVICES_EXT_TCP="www"
Auf Ports/Dienste (siehe /etc/services) in der Firewall wird vom sicheren Netzwerk, sowohl TCP und UDP, zugegriffen.
FW_SERVICES_INT_TCP="domain www 3128"
FW_SERVICES_INT_UDP="domain"
Wir greifen auf Web-Dienste und Squid (dessen Standardport ist 3128) zu. Der oben beschriebene Dienst „Domain“ steht für DNS oder Domain Name Server. Es ist üblich, diesen Dienst zu nutzen. Andernfalls entfernen wir ihn einfach aus obigem Eintrag und setzen folgende Option auf no:
FW_SERVICE_DNS="yes"
Die wichtigste Option ist die Ziffer 15:
Beispiel 18.1. Option 15 der Firewallkonfiguration
#
# 15.)
# Welcher Zugriff auf die einzelnen Dienste soll an einen lokalen
# Port auf dem Firewall-Rechner umgeleitet werden?
#
# Damit können alle internen Benutzer gezwungen werden, über den
# Squid-Proxy zu surfen oder es kann eingehender Webverkehr
# transparent an einen sicheren Web-Server umgeleitet werden.
#
# Wahl: keinen Eintrag vornehmen oder folgend erklärte Syntax von
# Umleitungsregeln, getrennt durch Leerzeichen, verwenden.
# Eine Umleitungsregel besteht aus 1) Quelle IP/Netz, 2) Ziel
# IP/Netz, 3) ursprünglicher Zielport und 4) lokaler Port, an den
# der Verkehr umgeleitet werden soll, getrennt durch Kommata, z.B.:
# "10.0.0.0/8,0/0,80,3128 0/0,172.20.1.1,80,8080"
#
Im obigen Kommentar wird die einzuhaltende Syntax gezeigt. Zuerst greifen die IP-Adresse und die Netzwerkmaske der „internen Netzwerke“ auf die Proxy-Firewall zu. Dann die IP-Adresse und die Netzwerkmaske, an die Anfragen von den Clients „gesendet“ werden. Im Fall von Web-Browsern wählt man die Netzwerke 0/0. Dies ist eine Wildcard und bedeutet „überallhin“. Danach kommt der „ursprüngliche“ Port, an den diese Anfragen geschickt wurden und schließlich folgt der Port, an den die Anfragen „umgeleitet“ wurden.
Da Squid mehr Protokolle unterstützt als nur HTTP, können auch Anfragen von anderen Ports an den Proxy umgeleitet werden, so zum Beispiel FTP (Port 21), HTTPS oder SSL (Port 443).
Im konkreten Fall werden Web-Dienste (Port 80) auf den Proxy-Port (hier 3128 umgeleitet. Falls mehrere Netzwerke oder Dienste hinzugefügt werden sollen, müssen diese durch ein Leerzeichen im entsprechenden Eintrag getrennt werden.
FW_REDIRECT_TCP="192.168.0.0/16,0/0,80,3128 192.168.0.0/16,0/0,21,3128"
FW_REDIRECT_UDP="192.168.0.0/16,0/0,80,3128 192.168.0.0/16,0/0,21,3128"
Zum Starten der Firewall und der neuen Konfiguration muss man einen Eintrag in der Datei /etc/sysconfig/SuSEfirewall2 editieren. Der Eintrag START_FW muss auf "yes" gesetzt werden:
Starten Sie Squid wie in Abschnitt 18.3.4. “Squid starten” beschrieben. Anhand der Protokolldateien in /var/log/squid/access.log kann überprüft werden, ob alles richtig funktioniert. Um zu überprüfen, ob alle Ports korrekt konfiguriert wurden, kann von jedem beliebigen Rechner außerhalb unserer Netzwerke auf dem Rechner ein Portscan ausgeführt werden. Nur der Web-Dienst-Port (80) sollte offen sein. Der Portscan führt über nmap -O IP-Adresse.
In diesem Abschnitt wird gezeigt, wie andere Applikationen mit Squid interagieren. cachemgr.cgi ermöglicht dem Systemadministrator, den benötigten Speicher für das Zwischenspeichern von Objekten zu überprüfen. squidGuard filtert Webseiten, und calamaris ist ein Berichtsgenerator für Squid.
Der Cache-Manager (cachemgr.cgi) ist ein CGI-Hilfsprogramm zur Ausgabe von Statistiken über den benötigten Speicher des laufenden Squid-Prozesses. Im Gegensatz zum Protokollieren erleichtert dies die Cache-Verwaltung und die Anzeige von Statistiken.
Zuerst wird ein lauffähiger Web-Server auf dem System benötigt. Als Benutzer root gibt man Folgendes ein, um herauszufinden, ob Apache bereits läuft: rcapache status.
Erscheint eine Nachricht wie die folgende, läuft Apache auf unserem Rechner:
Checking for service httpd: OK Server uptime: 1 day 18 hours 29 minutes 39 seconds
Andernfalls müssen Sie folgenden Befehl eingeben: rcapache start. So wird Apache mit den Standardeinstellungen von SUSE LINUX gestartet.
Als letzten Schritt muss man die Datei cachemgr.cgi aus dem Verzeichnis /usr/share/doc/packages/squid/scripts/ in das Verzeichnis /srv/www/cgi-bin von Apache kopieren.
Folgende Standardeinstellungen sind für den Cache-Manager erforderlich:
acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255
Folgende Regeln sollten enthalten sein:
http_access allow manager localhost http_access deny manager
Die erste ACL ist am wichtigsten, da der Cache-Manager versucht, mit dem Squid über das cache_object-Protokoll zu kommunizieren. Die folgenden Regeln setzen voraus, dass der Web-Server und Squid auf demselben Rechner laufen. Die Kommunikation zwischen dem Cache-Manager und Squid entsteht beim Web-Server, nicht beim Browser. Befindet sich der Web-Server also auf einem anderen Rechner, müssen Sie extra eine ACL wie in der Beispieldatei 18.2. “Zugriffsregeln” hinzufügen.
Beispiel 18.2. Zugriffsregeln
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl webserver src 192.168.1.7/255.255.255.255 # IP Webserver
Dann werden noch folgende Regeln aus Datei 18.3. “Zugriffsregeln” benötigt.
Beispiel 18.3. Zugriffsregeln
http_access allow manager localhost
http_access allow manager webserver
http_access deny manager
Es ist auch möglich, ein Passwort für den Manager zu konfigurieren, wenn auf mehrere Optionen zugegriffen werden soll, wie z. B. Schließen des Cache von Remote oder Anzeigen weiterer Informationen über den Cache. Dann müssen Sie den Eintrag cachemgr_passwd und die Optionenliste, die angezeigt werden soll, mit einem Passwort für den Manager konfigurieren. Diese Liste erscheint als Teil der Eintragkommentare in /etc/squid/squid.conf.
Immer wenn sich die Konfigurationsdatei geändert hat, muss Squid neu gestartet werden. Dies geschieht am einfachsten mit dem Befehl: rcsquid reload
Gehen Sie zur entsprechenden Web-Seite, beispielsweise http://webserver.example.org/cgi-bin/cachemgr.cgi Drücken Sie auf und lassen Sie sich die verschiedenen Statistiken anzeigen. Weitere Informationen über die einzelnen Einträge, die vom Cache-Manager ausgegeben werden, finden sich in den FAQs zu Squid: http://www.squid-cache.org/Doc/FAQ/FAQ-9.html
Dieses Kapitel soll lediglich eine Einführung zur Konfiguration von squidGuard sowie ein paar Ratschläge zu dessen Einsatz geben. Auf eine umfangreiche Erklärung wird an dieser Stelle verzichtet. Tiefer gehende Informationen finden sich auf den Webseiten zu squidGuard: http://www.squidguard.org
squidGuard ist ein freier (GPL), flexibler und ultraschneller Filter, ein Umleiter und „PlugIn“ zur Zugriffskontrolle für Squid. Er ermöglicht das Festlegen einer Vielzahl von Zugriffsregeln mit unterschiedlichen Beschränkungen für verschiedene Benutzergruppen für einen Squid-Cache. squidGuard verwendet die Standardschnittstelle von Squid zum Umleiten. squidGuard kann u. a. für Folgendes verwendet werden:
Beschränkung des Internetzugriffs für einige Benutzer auf bestimmte akzeptierte/bekannte Web-Server und/oder URLs.
Zugriffsverweigerung für einige Benutzer auf bestimmte Web-Server und/oder URLs.
Zugriffsverweigerung für einige Benutzer auf URLs, die bestimmte reguläre Ausdrücke oder Wörter enthalten.
Umleiten gesperrter URLs an eine „intelligente“ CGI-basierte Infoseite.
Umleiten nicht registrierter Benutzer an ein Registrationsformular.
Umleiten von Bannern an ein leeres GIF.
Unterschiedliche Zugriffsregeln abhängig von der Uhrzeit, dem Wochentag, dem Datum etc.
Unterschiedliche Regeln für die einzelnen Benutzergruppen.
Weder mit squidGuard noch mit Squid ist Folgendes möglich:
Text innerhalb von Dokumenten filtern, zensieren oder editieren.
In HTML eingebettete Skriptsprachen wie JavaScript oder VBscript filtern, zensieren oder editieren.
Installieren Sie das squidGuard. Editieren Sie die Konfigurationsdatei /etc/squidguard.conf. Es gibt zahlreiche andere Konfigurationsbeispiele unter http://www.squidguard.org/config/. Sie können später mit komplizierteren Konfigurationseinstellungen experimentieren.
Der nächste Schritt besteht darin, eine Dummy-Seite „Zugriff verweigert“ oder eine mehr oder weniger intelligente CGI-Seite zu erzeugen, um Squid umzuleiten, falls der Client eine verbotene Webseite anfordert. Der Einsatz von Apache wird auch hier wieder empfohlen.
Nun müssen wir Squid sagen, dass er squidGuard benutzen soll. Dafür verwenden wir folgende Einträge in der Datei /etc/squid/squid.conf:
redirect_program /usr/bin/squidGuard
Eine andere Option namens redirect_children konfiguriert die Anzahl der verschiedenen auf dem Rechner laufenden „redirect“, also Umleitungsprozesse (in diesem Fall squidGuard). squidGuard ist schnell genug, um eine Vielzahl von Anfragen (squidGuard ist wirklich schnell: 100.000 Anfragen innerhalb von 10 Sekunden auf einem 500MHz Pentium mit 5900 Domains, 7880 URLs,gesamt 13780) zu bearbeiten. Es wird daher nicht empfohlen, mehr als 4 Prozesse festzusetzen, da die Zuweisung dieser Prozesse unnötig viel Speicher braucht.
redirect_children 4
Als Letztes lassen Sie den Squid seine neue Konfiguration einlesen: rcsquid reload. Nun können Sie Ihre Einstellungen in einem Browser testen.
Calamaris ist ein Perl-Skript, das zur Erzeugung von Aktivitätsberichten des Cache im ASCII- oder HTML-Format verwendet wird. Es arbeitet mit Squid-eigenen Zugriffsprotokolldateien. Die Homepage zu Calamaris befindet sich unter: http://Calamaris.Cord.de/. Das Programm ist einfach zu verwenden. Melden Sie sich als root an und geben Sie folgenden Befehl ein: cat access.log.files | calamaris [options] > reportfile.
Beim Verketten mehrerer Protokolldateien ist die Beachtung der chronologischen Reihenfolge wichtig, das heisst ältere Dateien kommen zuerst. Die verschiedenen Optionen:
wird normalerweise zur Ausgabe aller verfügbaren Berichte verwendet, mit
erhält man einen HTML-Bericht und mit
eine Nachricht oder ein Logo im Header des Berichts.
Weitere Informationen über die verschiedenen Optionen finden Sie in der Manual Page zu calamaris: man calamaris.
Ein weiteres, leistungsstarkes Tool zum Erzeugen von Cache-Berichten ist SARG (Squid Analysis Report Generator). . Weitere Informationen dazu gibt es auf der entsprechenden Internetseite unter: http://web.onda.com.br/orso/
Besuchen Sie die Homepage von Squid: http://www.squid-cache.org/. Hier finden Sie den Squid User Guide und eine sehr umfangreiche Sammlung von FAQs zu Squid. Das Mini-Howto zum transparenten Proxy im howtoen finden Sie unter: /usr/share/doc/howto/en/mini/TransparentProxy.gz
Des Weiteren gibt es Mailinglisten für Squid unter: squid-users@squid-cache.org. Das Archiv dazu befindet sich unter: http://www.squid-cache.org/mail-archive/squid-users/.
