Jo's Linux Firewall Howto: HTTP-Proxy

Der Turbo fürs Web: ein Proxy-Chache.

Ein Proxy (englisch für Stellvertreter) ist erstmal ein Vermittler, der die Anfragen, die er erhält, weiterleitet und auf dem Rückweg auch die Antworten entsprechend zum anfragenden Rechner bzw. Programm zurückgibt.

Ein solcher Proxy kann mehrere Aufgaben erfüllen:

Er kann Zugriffe von Rechnern kanalisieren und filtern, die keinen direkten Zugang zum Internet haben (dürfen). Damit ist eine direkte Durchleitung von Paketen gar nicht mehr erforderlich. Ein solcher Proxy realisiert somit eine Firewall-Funktionalität.

Ein Proxy kann aber auch die Informationen filtern oder vorverarbeiten, bevor er sie weitergibt. Bekanntestes Beispiel dafür ist wohl der Junkbuster. Dieser filtert die eingebetteten Banner aus geladenen Seiten und verringert Fso die Datenmenge, welche über die Leitung muß.

Der Proxy-Cache speichert WWW-Seiten lokal, so daß sie beim nächsten Zugriff nicht erst wieder über die Leitung kommen müssen. Dadurch wird der wiederholte Zugriff auf 1 Seite deutlich schneller. Diese Funktion leisten auch die meisten Browser, indem sie die letzten Dateien im Speicher oder auf der lokalen Platte festhalten. Allerdings funktionieren diese Caches nicht so gut, wie ein echter Proxy es tut. Außerdem helfen die Browser-Caches nicht, wenn 1 weitere Rechner aus dem lokalen Netz auf die selbe Seite zugreift.

Ich verwende SQUID2 als Proxy-Cache. Dieser ist in den SuSE Distributionen (Serie n, Paket squid2) enthalten, liegt aber auch unter squid.nlanr.net zum Download bereit.

– — – — – — – — –

Für den Betrieb des Proxies muß ein Nameserver zugänglich sein. Dazu ist in /etc/rc.config in der Variable NAMESERVER die Adresse des Nameservers einzutragen. Sinnvollerweise der lokale Nameserver, also "127.0.0.1". Ein Proxy-Cache, der einen externen Nameserver fragen muß, ist nicht ganz so optimal. (Natürlich kann man diese Einstellung auch mit Yast vornehmen)

– — – — – — – — –

Folgende Einstellungen sind in der Datei /etc/squid.conf vorzunehmen:

http_port 8080
Damit wird die Portnummer eingestellt, unter der der Proxy angesprochen werden kann. Dies ist der Wert, welcher im jeweiligen Browser einzustellen ist. Hier ist 8080 ein weit verbreiteter Wert, es sind aber auch andere Einstellungen möglich. Allerdings sollte man günstigerweise einen Wert über 1024 wählen, damit man sich keinen der Standard-Dienste verbaut.
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
Um einen sauberen Betrieb sicherzustellen, ist es wichtig, einige Seiten nicht zu speichern. Dazu gehören z. B. Abfrageergebnisse. Sonst wird bei einer neuen Abfrage das Ergebnis der alten Abfrage aus dem Speicher geholt und das ist vermutlich nicht das, was der Anwender will.
Um dies einzustellen, wird zunächst mit acl eine Access List (engl. für Zugangsliste) namens QUERY definiert. Diese legt fest, woran URLs die eine Abfrage enthalten erkannt werden können. Anschließend wird mit dem Kommando no_cache deny festgelegt, daß alle Seiten, die durch diese Access List beschrieben sind, nicht gespeichert werden dürfen. Damit wird dann bei jeder Anfrage an 1 Suchmaschine auch wirklich die Suchmaschine gefragt und die neuen Antwort angezeigt.
cache_mem 8 MB
Dies ist die Menge an Arbeitsspeicher, welche der Proxy verwenden darf. Bei Systemen mit wenig Arbeitsspeicher ist hier vermutlich 1 - 2 MB günstiger.
cache_dir /var/squid/cache 100 16 256
Diese Einstellung beschreibt wo und wieviel der Proxy auf der Platte speichern darf. Der Pfadname kann nach Geschmack gewählt werden, wobei Yast (bei SuSE) den hier gezeigten Pfad bei der Installation bereits einrichtet. Wenn ein anderer Pfad gewählt wird, so muß auch dieses Verzeichnis angelegt werden. Die erste Zahl gibt die Anzahl der Megabytes an, welche insgesamt verwendet werden dürfen. Die zweite Zahl ist die Anzahl der Unterverzeichnisse erster Ebene und die dritte Zahl die Anzahl der Unterverzeichnisse zweiter Ebene. Diese Unterverzeichnisstruktur dient dazu, nicht zu viele Dateien in einem Verzeichnis zu speichern, um den Zugriff auf 1 Datei nicht zu langsam werden zu lassen. Wenn man die Anzahl der MB erhöht, sollte man die Anzahl der Verzeichnisse in ähnlichem Maße erhöhen.
Allerdings sollte man bedenken, daß in jedem Verzeichnis der ersten Ebene alle Verzeichnisse zweiten Ebene angelegt werden, d. h. die Gesamtzahl der Verzeichnisse, die Squid anlegt, ist das Produkt der beiden Zahlen. Dies sind in diesem Beispiel bereits 16 * 256 = 4096 Verzeichnisse. Bei höheren Werten kann das Einrichten der Verzeichnisstruktur entsprechend lange dauern.
Wenn die Einstellungen für die Verzeichnisstruktur geändert wurden, so muß Squid die Verzeichnisstruktur neu anlegen. Dies geschieht durch den Aufruf von:
root@gateway:~>su squid -c "/usr/sbin/squid -z"
Dazu muß man als User root eingelogged sein, was aber für die meisten der hier beschriebenen Einstellungen gilt. Mit su squid -c Befehl wird der Befehl als User squid ausgeführt, was bewirkt, das die Verzeichnisstruktur auch dem User squid gehört. Der User squid wird von SuSE automatisch angelegt.
acl localnet src 192.168.0.0/255.255.255.0
acl localhost src 127.0.0.1/255.255.255.255
Hier werden sog. Access Lists definiert, mit denen eingestellt werden kann, wer auf diesen Proxy zugreifen kann.
http_access allow localnet localhost
Hier wird schließlich eingestellt, welche Liste zugreifen darf und welche nicht.
cache_mgr root
Dies ist die eMail-Adresse des Zuständigen für diesen Proxy. Wenn es Problem gibt, sendet der Proxy eine eMail an diese Adresse.

Ansonsten gibt es ein dieser Datei noch 1 gewaltige Menge an Einstellmöglichkeiten, an denen man sich vergehen kann. Diese ermöglichen 1 sehr weitgehende Optimierung auch für den extremsten Außnahmefall. Allerdings sollte der Proxy mit den oben genannten Einstellungen bereits sauber funktionieren. Weitere Änderungen solle man entsprechend vorsichtig vornehmen.

– — – — – — – — –

Hier noch 1 paar evtl. ganz interessante, aber nicht benötigte Einstellungen. Der Proxy kann nämlich dazu verwendet werden, die Privatsphäre zu vergrößern.

Eigentlich enthält der Kopf (engl. header) einer http-Anfrage (engl. http request) eine Menge an Informationen über den Rechner und den Brauser des Benutzers. Diese Information ist für manche Dinge ganz nützlich. So kann der ßöwer z. B. je nach Brausertüp eine andere Seite, die an diesen optimal angepaßt ist, senden. Oder man kann versuchen, Informationen zu sammeln und Benutzerprofile zu erstellen. Vielleicht um gezielter werben zu können.

Was der http header so alles mitteilt, kann man auf der Einstellungen-Seite zu meinen Fotoseiten sehen. Und welche Einstellungen bei in /etc/squid.conf dies beeinflussen können, hier:

anonymize_headers deny From Referer Server
anonymize_headers deny User-Agent WWW-Authenticate Link
Mit anonymize_headers kann man einzelne Bestandteile des Kopfes ein bzw. ausschalten. Ähnlich wie bei diversen anderen Einstellungen gilt hier auch: nur 1 Richtung ist möglich. Also, man schaltet einzelne Teile aus (deny) und damit den gesamten Rest ein oder man schaltet einzelne Teile ein (allow) und damit alles andere aus. Hier werden Deine eMail-Adresse (From), die verweisende Seite (Referer) und der fragende Server (sic) [1.Zeile] sowie Browsertyp (User-Agent) ? (WWW-Authenticate) und ? (Link) ausgeschaltet. Dies entspricht der Standard Anonymisierung von Squid 1. Mit dieser Option lasse sich alle Kopf-Bestandteile einzeln ein- bzw. ausschalten. Aber vorsicht: einige Bestandteile sind nötig, damit die Anfragen funktionieren! Hier muß jeder seinen eigenen Kompromiss zwischen Leichtsinn und Paranoia finden ;-)).
fake_user_agent Wolpertinger/5.6 (Apple IIe)
Manche (schlecht programmierte) Sites stürzen ab, wenn sie keinen Browsertyp gemeldet bekommen. Hier ist es besser, 1 falschen Typ anzugeben. Am besten 1 Blödsinnigen, damit es keine Verwechselung mit real existierenden Brausern gibt und man besonders unverdauliche Seiten bekommt (Leider kommen auch damit einige Seiten nicht klar - halt wiedereinmal sehr schlecht programmiert!).
forwarded_for off
Normalerweise meldet der Proxy in einem Extra-Eintrag im Anfrage-Kopf, für wen er diese Anfrage tätigt. Damit würde trotz Proxy und IP-Masquerading die IP-Adresse der Workstation weitergeben. Da ist das Ausschalten dieser Option schon ganz sinnvoll. (Währe diese Option in unserer Firma aktiviert, könnte ich leicht feststellen, welcher Kollege auf meine Seiten gesehen hat :-)

Privatsphäre kann es aber auch innerhalb des lokalen Netzes geben. Um Fehler zu suchen ist es ganz nützlich, alle Anfragen an den Proxy in der Log-datei zu finden. Aber eigentlich geht es auch den Sysop nichts an, wer wann wohin surft! Also sollte man nach erfolgreichem Probebetrieb zumindest einen Teil der Logs ausschalten (damit wird der Proxy auch etwas schneller):

#cache_access_log ...
Das Auskommentieren der Zeile, welche den Dateinamen für das Zugriffsprotkoll enthält, beendet das Loggen.
– — – — – — – — –

weitere Doku:

– — – — – — – — –

Um den Proxy zu nutzen, muß jeder (!) Browser darauf eingestellt werden. Solange man es ihm nicht explizit sagt, wendet sich der Browser direkt an den jeweiligen Server. (Wie das geht steht bei Klienten)

Um bei eventuellen Erweiterungen, wenn z. B. der Proxy auf einen anderen Rechner wandern soll, nicht jeden Browser neu einstellen zu müssen ist es sinnvoll, den Proxy von vornherein durch einen eigenen Namen anzusprechen. Hier bietet sich, entsprechend der bereits genannten Konvention, wwwproxy.klaus.home an. Diese Adresse muß natürlich beim lokalen Nameserver eingetragen sein.

– — – — – — – — –

Weiter mit: Klienten, also wie konfiguriere ich die PCs am lokalen Netz, damit sie über die Firewall auf alle Dienste zugreifen können.

Urheber © Dr. Joachim Wiesemann

Letzte Aktualisierung: 28.5.2006