Beim Stochern in alten Backups fand ich ein Tutorial zu squid, das ich vor einiger Zeit einmal verfaßt, aber nie veröffentlicht habe. Ich hab’s noch ein wenig überarbeitet und ziehe die Veröffentlichung hiermit nach :) Bei mir handelt es sich um ein NetBSD-current, auf $LEEENUCKS sind die Pfade anders. Viel Spaß damit…

Beginnen wir mit einer Grundkonfiguration: das Programm soll auf dem Standard-Port 3128 lauschen, Cache-Manager ist meine Wenigkeit, und Username und Gruppe des Programms sollen squid sein; als Sprache wählen wir deutsch, auch wenn die Übersetzungen grausig sind, und wir setzen den User-Agent-String auf Blödsinn um, was aus diversen Gründen vorteilhaft sein kann, zudem wird es auf den IP-Adreßbereich des VPN begrenzt:

http_port 3128
cache_mgr spillerm@localwurst.de
cache_effective_user squid
cache_effective_group squid
error_directory /usr/pkg/share/squid/errors/German
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 to_localhost dst 127.0.0.0/8
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
acl localwurst-vpn src 10.0.16.0/24
http_access allow localhost
http_access allow localwurst-vpn
http_access deny all
header_access User-Agent deny all
header_replace User-Agent Gozilla/4711.0815 (CP/M; 11-bit; 42 KByte)

Danach lassen wir das Programm seinen Speicher einrichten:

/usr/pkg/sbin/squid -z

Anschließend können wir es starten:

/etc/rc.d/squid start

Nun folgt die erste Testphase: den Browser einrichten und beobachten, was die Logfiles des Squid beim Surfen so von sich geben. Das ist wichtig :) Wenn alles funktioniert können wir mit dem Finetuning und einigen Spielereien beginnen.

Gehen wir mal aus von einem Anschluß, an dem (zumindest temporär) mehrere Leute arbeiten; arbeiten bedeutet in diesem Falle, sich jede verfügbare Form vom Free-, Share- & SpyWare auf den Rechner zu ziehen, bei jedem Wurm und Virus »Hier!« zu schreien und diese solange weiterverteilen, bis die feste IP des Anschlusses auf allen denkbaren Blacklists des Webs zu finden ist. Oder aber die faulen Mitarbeiter sausen den lieben langen Tag auf bildschirmarbeiter.de umher und arbeiten nicht.

Es gibt mehrere Ansätze, diesen Mißstand in den Griff zu bekommen, und DAUs den Stecker zu ziehen ist vielleicht nichteinmal der uneleganteste. Per squid geht es jedoch auch anders: beispielsweise, indem man *.zip- und *.exe-Dateien einfach blockt oder eine Blacklist unerwünschter Domains verwaltet.

Als freundlicher Admin (der sich Anrufe à la »Ich kann xyz nicht downloaden!!!11einself« ersparen möchte) weist man die User darauf hin, daß an dieser Stelle Inhalte weggefiltert werden; die benötigten Textfiles sind in /usr/pkg/share/squid/error/German/ (analog zu error_directory in squid.conf) zu erstellen (immer hübsch höflich):

ERR_NO_DOWNLOAD

Sorry!
Wegen sicherheitskritischer Aspekte wurde der angeforderte Inhalt geblockt.
Bei Fragen wenden Sie sich bitte an den zuständigen Mitarbeiter!

Hier bloß nicht angeben, *wer* der zuständige Mitarbeiter ist. Noch wichtiger: das ‘%w’ für die Mailadresse rauslassen! Es sei denn, die Mailadresse geht direkt nach /dev/null. Oder möchtet Ihr wirklich im Sekundentakt Mails genervter User erhalten? ;)

ERR_NO_DOMAIN

Sorry!
Es ist nicht erwünscht, daß Sie während Ihrer Arbeitszeit diese Domain aufrufen.
Tun Sie dies bitte von zu Hause aus und nach Feierabend.

Was an den Ansprechpartner angeht, gelten an dieser Stelle die selben Restriktionen wie eben beschrieben.

Okay, und wie blocken wir die Domains nun? Der Einfachheit halber erstellen wir uns Blacklists, die wir dann nach Belieben füllen. Dazu legen wir uns einen Ordner an, sehen, zu, daß dieser dem User und der Gruppe squid gehört und kreieren eine erste Blacklist:

$ mkdir /usr/pkg/etc/squid/blacklists

/usr/pkg/etc/squid/blacklists/domains

.spiegel.de # der vorausgehende Punkt schließt Subdomains mit ein
.bildschirmarbeiter.de
.ebay.de

/usr/pkg/etc/squid/blacklists/binary

.exe
.zip
.mp3

Nun muß noch in die Konfiguration eingebaut werden, daß diese beiden Dateien ausgewertet und ihr Inhalt entsprechend geblockt werden soll; das sieht dann in etwa so aus:

acl domain-blacklist url_regex "/usr/pkg/etc/squid/blacklists/domains"
acl binary-blacklist url_regex "/usr/pkg/etc/squid/blacklists/binary"
deny_info ERR_NO_DOMAIN domain-blacklist
deny_info ERR_NO_DOWNLOAD binary-blacklist
http_access deny domain-blacklist
http_access deny binary-blacklist

Wem das zuviel Aufwand ist und wer nur einige wenige Dinge sperren will, der kann sich auch so behelfen:

acl faul dstdomain .bildschirmarbeiter.de
acl binary url_regex -i \\. (exe|zip)($|\\?)
deny_info ERR_NO_DOMAIN faul
deny_info ERR_NO_DOWNLOAD binary
http_access deny faul
http_access deny binary

So oder so muß der squid anschließend rekonfiguriert werden:

$ /usr/pkg/sbin/squid -k reconfigure

Achtet auf Fehlermeldungen! Prüft die Funktionsweise, prüft alles, was Euch einfällt, streßt das Ding mal ein bißchen ;) Und seid begeistert wie ich darüber, wie schnell sich so manches realisieren läßt.

/usr/pkg/etc/squid/blacklists/huge-data

.flv
.watch?
.view?
.get_video?

Mit den huge-data haben wir etwas anderes vor: die werden wir nicht vollständig blocken, sondern lediglich in der Geschwindigkeit drosseln. Dazu erweitern wir unsere Konfiguration an den entsprechenden Stellen um diese Zeilen:

acl huge-data url_regex "/usr/pkg/etc/squid/blacklists/huge-data"
delay_pools 1
delay_class 1 2
delay_parameters 1 5000/150000 5000/120000
delay_access 1 allow huge-data

Diese Konfiguration kann noch in alle Richtungen angepaßt werden, beispielsweise könnte die Bandbreite nur tagsüber beschränkt werden, nachts hingegen Download mit voller Geschwindigkeit erlaubt sein usw. Der Phantasie sind ersteinmal wenige Grenzen gesetzt :)

Zuletzt können wir noch die Header ein wenig manipulieren (und dabei den HTTP-Standard verletzen, aber das nur so am Rande):

header_access From deny all
header_access Referer deny all
header_access Server deny all
header_access User-Agent deny all
header_access WWW-Authenticate deny all
header_access Link deny all

Da dieser Squid ohnehin nur im Bereich des VPN lauschen darf, ist hier keinerlei User-Authentifizierung vorgesehen — einbauen läßt sich die natürlich schon. Schickerweise nutze ich den Proxy nun über einen SSH-Tunnel — und umgehe damit so einiges, auf das ich hier nicht näher eingehen darf ;)

$ ssh -L 3128:localhost:3128 <$VPN>

Anschließend im Browser den Proxy angeben mit Host localhost und Port 3128 :)

Mittels MRTG oder webalizer (oder diversen anderen) kann man sich entsprechende Graphiken bzgl. der Nutzung aufmalen lassen — beachtet rechtliche Hintergründe gesondert!

Fällt das Ding mit Fehlermeldungen wie diesen hier um, so checkt die Logfiles — eines davon ist zu groß geworden und muß wegrotiert werden:

Jul 26 13:08:45 xxxx squid[20523]: Squid Parent: child process 20539 started
Jul 26 13:08:45 xxxx squid[20523]: Squid Parent: child process 20539 exited due to signal 25
Jul 26 13:08:48 xxxx squid[20523]: Squid Parent: child process 20576 started
Jul 26 13:08:47 xxxx squid[20523]: Squid Parent: child process 20576 exited due to signal 25
Jul 26 13:08:47 xxxx squid[20523]: Exiting due to repeated, frequent failures

Baut Ihr einen transparenten Proxy, so müßt Ihr das zum einen beim Kompilieren mit angeben (echo "PKG_OPTIONS.squid = ipf-transparent" >> /etc/mk.conf); üblicherweise müssen dem Client-Programm, also beispielsweise dem Browser, die genauen Proxy-Einstellungen mitgegeben werden, was mehrere Nachteile mit sich bringt:

• Jeder Client muß manuell angepaßt werden.
• Es liegt im Ermessen des jeweiligen Users, was genau er eingibt; in aller Regel ist das etwas Falsches.
• Auch die Erstellung einer *.pac-Datei bringt einen da nicht unbedingt weiter, weil es immer wieder User gibt, die diese nicht finden können bzw. nicht wissen, wo sie diese einzufüttern haben.

Der transparente Proxy umgeht dieses Problem, indem einfach alle Anfragen von Port 80 auf Port 3128 umgelenkt werden; hierzu ist ein Eintrag in der /etc/ipnat.confnötig:

rdr sq0 0/0 port 80 -> 127.0.0.1 port 3128 tcp/udp

Diese Änderungen sollten dann auch entsprechend eingelesen werden:

$ ipnat -CF -f /etc/ipnat.conf