Fedora 14 Beitrag 3.)
Der Proxycache Squid und seine Services
Wir betreiben mehrere PCs, die alle für sich alleine gesehen keinen eigenen Internetzugang haben. Alle PCs verfügen jedoch über eine Netzwerkkarte und sind über diese an einen Switch angeschlossen. Weiterhin haben wir einen Rechner, der uns im Folgenden als Gateway dienen soll. Er ist mit zwei Netzwerkkarten ausgestattet. Die eine Netzwerkkarte ist - genau wie bei den PCs auch - mit dem besagten Switch verdrahtet. Die andere Netzwerkkarte stellt die Verbindung zu einer Fritz-Box her. Die Fritz-Box ihrerseits macht über eine DSL-Telefonleitung die Verbindung ins Internet. Dies ist ein ganz und gar üblicher Aufbau, wie er in tausenden von Betrieben und inzwischen wohl auch in tausenden von Haushalten anzutreffen ist. Die folgende Abbildung illustriert die Zusammenhänge.
Natürlich besteht der Sinn der ganzen Angelegenheit darin, allen PCs des Netzwerkes über das Gateway einen Zugang zum Internet zur Verfügung zu stellen.
Obwohl der Aufbau an sich recht einfach ist, so ist er doch auch komplizierter als unbedingt notwendig. So kann man berechtigterweise fragen, wozu denn das Gateway überhaupt nötig ist? Kann man die Fritz-Box nicht einfach direkt an den Switch anschließen und somit die Anschaffung eines ganzen Rechners einsparen?
Wenn wir uns hier den Rechner nicht sparen wollen, so liegt das an dem Zusatznutzen den solch ein Gateway bietet. Und dieser Zusatznutzen besteht im Wesentlichen in dreierlei: erstens der Caching-Funktionalität (= mehr Leistung), zweitens der Content-Filterung (= mehr Kontrolle) und drittens des Schutzes vor Viren (= mehr Sicherheit). Dies alles wird durch die Software "Squid" verwaltet. "Squid" leistet das aber nicht alleine, es braucht auch noch "SquidGuard" und "SquidClamav" - von mir hier als Services bezeichnet - dazu. Quasi der Klebstoff, der alle diese Komponenten zusammenhält ist die Software "C-ICAP".
Worin dieser Zusatznutzen nun im Einzelnen besteht, will ich hier nicht näher ausführen. Diejenigen, an die ich mich wende, wissen um die Notwendigkeit dieser drei Dinge ohnehin Bescheid. Mich interessiert eher das Zusammenspiel der vier Softwarekomponenten "Squid", "SquidGuard", "SquidClamav" und "C-ICAP". Das ist es, was ich nun ein wenig erläutern will.
1.) Squid ohne alle Services
Squid ist schnell installiert. Der übliche Befehl "yum install squid" bringt ihn auf die Festplatte. Muß ich noch erwähnen, daß die Installation natürlich auf dem Gateway (bei mir gw01 genannt) erfolgt und nicht auf den Clientrechnern (pc01 bis pc10)? Nein, muß ich nicht, ist doch klar.
1.1.) Squid nur als Proxy
Im aller einfachsten Fall, in dem Squid nur als Proxy laufen soll, ohne irgendwelche Inhalte zu cachen, kann die Konfigurationsdatei "/etc/squid/squid.conf" folgendermaßen aussehen:
acl localnet src 192.168.1.0/24 http_access allow localnet http_access deny all http_port 192.168.1.11:3128 hierarchy_stoplist cgi-bin ? coredump_dir /var/spool/squid refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320
Mehr braucht man nicht. Das ist schon alles. Noch einige Worte zur Erläuterung: Die erste Zeile, beginnend mit "acl", definiert die Variable "localnet". Und zwar umfaßt "localnet" sämtliche IP-Nummern, die mit 192.168.1. beginnen. Zu "localnet" gehören also 192.168.1.1, 192.168.1.2, 192.168.1.3 usw. bis 192.168.1.255. Man hätte anstelle des Variablennamens "localnet" z.B. auch "mynet" oder "intranet" nehmen können. Der Variablenname ist frei wählbar. Allerdings hätte man diesen frei gewählten Namen dann auch in der nun folgenden Zeile verwenden müssen. Diese nun folgende Zeile, die mit "http_access allow" beginnt, besagt, daß alle soeben definierten IP-Nummern unseren Squid benutzen dürfen. Die dritte Zeile stellt dann - quasi im Umkehrschluß - noch einmal klar, daß alle anderen, außer den soeben definierten, Squid nicht benutzen dürfen. Die "http_port" Zeile halte ich persönlich für besonders wichtig, denn sie bringt zum Ausdruck, daß unser Squid Anfragen nur über die Netzwerkkarte 192.168.1.11 und dort nur auf Port 3128 entgegennimmt. Üblicherweise lautet diese Zeile nur "http_port 3128", was allerdings zur Folge hat, daß Squid Anfragen auf allen Netzwerkkarten, also auch auf der zur Fritz-Box gerichteten Netzwerkkarte entgegennimmt. Das will ich aber gerade nicht. Nur unserem internen Netzwerk soll der Internetzugang gestattet sein.
Nun starten wir Squid und überprüfen ob unser Internetzugang funktioniert:
[root@gw01 ~]# chkconfig --list squid squid 0:Aus 1:Aus 2:Aus 3:Aus 4:Aus 5:Aus 6:Aus [root@gw01 ~]# chkconfig --level 2345 squid on [root@gw01 ~]# chkconfig --list squid squid 0:Aus 1:Aus 2:Ein 3:Ein 4:Ein 5:Ein 6:Aus [root@gw01 ~]# /etc/rc.d/init.d/squid status squid wurde beendet [root@gw01 ~]# /etc/rc.d/init.d/squid start squid starten: . [ OK ] [root@gw01 ~]# /etc/rc.d/init.d/squid status squid (PID 27538) wird ausgeführt ... [root@gw01 ~]#
Und, funtionierts? Na, prima! Wenn nicht: Prüfen Sie zunächst Ihre Clients. Haben Sie Ihre Rechner auch so eingestellt, daß sie ihre Anfragen an das Gateway Port 3128 stellen? Prüfen Sie sodann Ihr Gateway. Laufen beide Netzwerkkarten? Stimmen insbesondere die Dateien "/etc/hosts" und "/etc/resolv.conf"? Können Sie die Rechner Ihres Intranets anpingen? Können Sie Ihre Fritz-Box anpingen? Ist Ihre Defaultroute richtig gesetzt? Haben Sie Squid in Ihrer Firewall freigeschaltet? Sie schaffen das schon!
1.2.) Squid als Proxy und als Cache
Bitte schauen Sie zunächst in das Verzeichnis "/var/spool/squid" hinein. Sofern Sie Squid zuvor noch nie installiert und laufen hatten, werden Sie feststellen, daß es leer ist. Im Moment muß das auch so sein. Wir werden das jetzt aber ändern. Dazu erweitern wir die schon bekannte Konfigurationsdatei um nur eine einzige Zeile.
acl localnet src 192.168.1.0/24
http_access allow localnet
http_access deny all
http_port 192.168.1.11:3128
hierarchy_stoplist cgi-bin ?
cache_dir ufs /var/spool/squid 1000 16 256
coredump_dir /var/spool/squid
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
Damit ist die Caching-Funktionalität eingeschaltet. Auch hier muß ich noch etwas klären: "/var/spool/squid" ist das Verzeichnis, das Squid fortan zum Cachen benutzen wird. Die 1000 bedeutet, daß Squid sich 1.000MB Speicherplatz für dieses Verzeichnis reservieren wird. In der Squid-Standardkonfiguration findet sich häufig 100 anstatt der von mir gewählten 1000. Das führt in der Regel zu einer Fehlermeldung. Der Grund ist hier zu suchen: Moderne Rechner verfügen häufig über mehrere GB an Arbeitsspeicher. Diese großzügige Ausstattung mit RAM veranlaßt den Installer dazu auch eine entsprechend große Swap-Partition anzulegen. Wenn nun die Größe der Swap-Partition größer ist als der reservierte Festplattencache von Squid, dann ist Squid besorgt darüber, daß es einen voll ausgelasteten Swap-Bereich nicht mehr in seinen reservierten Festplattenspeicher schreiben kann und es kommt zu der besagten Fehlermeldung. Stellen Sie also sicher, daß die Größe des reservierten Festplattencaches die Größe Ihrer Swap-Partition übertrifft.
Der Befehl "/etc/rc.d/init.d/squid restart" aktiviert den Festplattencache. Schauen Sie sich jetzt noch einmal das Verzeichnis "/var/spool/squid" an. Nun ist es reichlich mit Unterverzeichnissen angefüllt.
2.) Voraussetzungen schaffen
Bevor wir die Einbindung der verschiedenen Services in Squid besprechen können, müssen wir sicherstellen, daß alles was wir benötigen auch installiert ist. Außerdem werden wir das, was wir hier installieren mit einer Basiskonfiguration versehen, damit alles für sich alleine gesehen auch betriebsbereit ist. Dann können wir uns daran anschließend voll und ganz auf das Zusammenspiel der verschiedenen Services konzentrieren. Doch zunächst zu den einzelnen Voraussetzungen.
2.1.) Erste Voraussetzung: SquidGuard
Auch SquidGuard will zunächst installiert werden. Das besorgt wieder das bekannte "yum install squidGuard". Anschließend kümmere ich mich um die Konfiguration. Die Konfigurationsdatei findet man hier: "/etc/squid/squidGuard.conf". Bei mir sieht die folgendermaßen aus:
dbhome /var/squidGuard/blacklists
logdir /var/log/squidGuard
dest gambling {
log gambling.log
domainlist gambling/domains
urllist gambling/urls
redirect http://192.168.1.101/error-page-gambling.html
}
dest porn {
log porn.log
domainlist porn/domains
urllist porn/urls
redirect http://192.168.1.101/error-page-porn.html
}
dest warez {
log warez.log
domainlist warez/domains
urllist warez/urls
redirect http://192.168.1.101/error-page-warez.html
}
acl {
default {
pass !gambling !porn !warez all
}
}
Schon der erste Blick auf diese Konfigurationsdatei verrät, daß die Content-Filterung anhand sogenannter Blacklists erfolgt. In meinem Fall beziehe ich mich auf drei verschiedene Blacklists: eine zur Filterung von Glücksspiel- und Zocker-Seiten (gambling), eine zweite um pornografische Webseiten (porn) auszufiltern und eine weitere um Raubkopierer-Seiten (warez) auszusperren.
Die benötigten Blacklists müssen zunächst angelegt, eventuell aktualisiert und sodann transformiert werden damit SquidGuard sie benutzen kann. Das Anlegen geht so:
[root@gw01 ~]# cd /var/squidGuard [root@gw01 squidGuard]# ls -al insgesamt 5576 drwxr-xr-x 2 root root 4096 7. Feb 15:17 . drwxr-xr-x. 19 root root 4096 7. Feb 15:17 .. -rw-r--r-- 1 root root 5697876 21. Okt 2009 blacklists.tar.gz [root@gw01 squidGuard]# gunzip blacklists.tar.gz [root@gw01 squidGuard]# ls -al insgesamt 21388 drwxr-xr-x 2 root root 4096 7. Feb 15:33 . drwxr-xr-x. 19 root root 4096 7. Feb 15:17 .. -rw-r--r-- 1 root root 21893120 21. Okt 2009 blacklists.tar [root@gw01 squidGuard]# tar -xf blacklists.tar [root@gw01 squidGuard]# ls -al insgesamt 21392 drwxr-xr-x 3 root root 4096 7. Feb 15:35 . drwxr-xr-x. 19 root root 4096 7. Feb 15:17 .. drwxr-xr-x 16 root root 4096 7. Feb 15:35 blacklists -rw-r--r-- 1 root root 21893120 21. Okt 2009 blacklists.tar [root@gw01 squidGuard]# rm -f blacklists.tar [root@gw01 squidGuard]# ls -al insgesamt 12 drwxr-xr-x 2 root root 4096 7. Feb 15:35 . drwxr-xr-x. 19 root root 4096 7. Feb 15:17 .. drwxr-xr-x 16 root root 4096 7. Feb 15:35 blacklists [root@gw01 squidGuard]# tree -aD --noreport blacklists blacklists ├── [Feb 15 14:00] ads │ ├── [Sep 24 2009] domains │ └── [Sep 24 2009] urls ├── [Feb 15 14:00] aggressive │ ├── [Sep 24 2009] domains │ └── [Sep 24 2009] urls ├── [Feb 15 14:00] audio-video │ ├── [Sep 24 2009] domains │ └── [Sep 24 2009] urls ├── [Feb 15 14:00] drugs │ ├── [Sep 24 2009] domains │ └── [Sep 24 2009] urls ├── [Feb 15 14:00] gambling │ ├── [Sep 24 2009] domains │ └── [Sep 24 2009] urls ├── [Feb 15 14:00] hacking │ ├── [Sep 24 2009] domains │ └── [Sep 24 2009] urls ├── [Feb 15 14:00] mail │ └── [Sep 24 2009] domains ├── [Feb 15 14:00] porn │ ├── [Sep 24 2009] domains │ └── [Sep 24 2009] urls ├── [Feb 15 14:00] proxy │ ├── [Sep 24 2009] domains │ └── [May 25 2002] urls ├── [Feb 15 14:00] redirector │ ├── [Sep 24 2009] domains │ └── [Sep 23 2009] urls ├── [Feb 15 14:00] spyware │ ├── [Sep 24 2009] domains │ └── [Sep 24 2009] urls ├── [Feb 15 14:00] suspect │ ├── [Apr 3 2007] domains │ └── [Feb 21 2007] urls ├── [Feb 15 14:00] violence │ ├── [Sep 24 2009] domains │ └── [Sep 24 2009] urls └── [Feb 15 14:00] warez ├── [Sep 24 2009] domains └── [Sep 24 2009] urls [root@gw01 squidGuard]# cd [root@gw01 ~]#
Obwohl die entpackten Dateien bestenfalls vom 24. September 2009 datieren und damit schon sehr betagt sind, spare ich mir das Aktualisieren und mache gleich mit der Transformation weiter.
[root@gw01 squidGuard]# squidGuard -C all [root@gw01 squidGuard]# tree -aD --noreport blacklists blacklists ├── [Feb 15 14:00] ads │ ├── [Sep 24 2009] domains │ └── [Sep 24 2009] urls ├── [Feb 15 14:00] aggressive │ ├── [Sep 24 2009] domains │ └── [Sep 24 2009] urls ├── [Feb 15 14:00] audio-video │ ├── [Sep 24 2009] domains │ └── [Sep 24 2009] urls ├── [Feb 15 14:00] drugs │ ├── [Sep 24 2009] domains │ └── [Sep 24 2009] urls ├── [Feb 15 14:31] gambling │ ├── [Sep 24 2009] domains │ ├── [Feb 15 14:31] domains.db │ ├── [Sep 24 2009] urls │ └── [Feb 15 14:31] urls.db ├── [Feb 15 14:00] hacking │ ├── [Sep 24 2009] domains │ └── [Sep 24 2009] urls ├── [Feb 15 14:00] mail │ └── [Sep 24 2009] domains ├── [Feb 15 14:31] porn │ ├── [Sep 24 2009] domains │ ├── [Feb 15 14:31] domains.db │ ├── [Sep 24 2009] urls │ └── [Feb 15 14:31] urls.db ├── [Feb 15 14:00] proxy │ ├── [Sep 24 2009] domains │ └── [May 25 2002] urls ├── [Feb 15 14:00] redirector │ ├── [Sep 24 2009] domains │ └── [Sep 23 2009] urls ├── [Feb 15 14:00] spyware │ ├── [Sep 24 2009] domains │ └── [Sep 24 2009] urls ├── [Feb 15 14:00] suspect │ ├── [Apr 3 2007] domains │ └── [Feb 21 2007] urls ├── [Feb 15 14:00] violence │ ├── [Sep 24 2009] domains │ └── [Sep 24 2009] urls └── [Feb 15 14:31] warez ├── [Sep 24 2009] domains ├── [Feb 15 14:31] domains.db ├── [Sep 24 2009] urls └── [Feb 15 14:31] urls.db [root@gw01 squidGuard]# cd [root@gw01 ~]#
Nach dieser Operation sind sechs Datenbankdateien - erkennbar an der Endung .db - hinzugekommen. Je zwei in den Bereichen "gambling", "porn" und "warez" (Weil ich nur diese drei Rubriken in meiner Konfigurationsdatei aufgeführt habe). Nur mit diesen Dateien kann SquidGuard etwas anfangen. So ist also "domains.db" die maschinenlesbare Fassung der Datei "domains" und "urls.db" die maschinenlesbare Variante der Datei "urls".
Übrigens: SquidGuard wird nicht über den Init-V Startprozeß gestartet, weil SquidGuard später über Squid und dessen andere Services mit gestartet wird. Stellen Sie also sicher, daß das Folgende gilt:
[root@gw01 ~]# chkconfig --list squidGuard
squidGuard 0:Aus 1:Aus 2:Aus 3:Aus 4:Aus 5:Aus 6:Aus
[root@gw01 ~]#
2.2.) Zweite Voraussetzung: C-ICAP
Auch C-ICAP muß zunächst installiert werden. C-ICAP ist leider nicht Bestandteil der offiziellen Fedora Repositorys. Es findet sich aber in meinem eigenen Repository, das ich im Internet öffentlich zugänglich gemacht habe. Eine Anleitung hierzu findet man in meinem Artikel "Gebrauch des Seeburger Fedora Repositorys" weiter vorne. Sofern mein Repository gangbar gemacht wurde, genügt ein "yum install c-icap". Dieser Befehl installiert dann die beiden Pakete c-icap-libs und c-icap jeweils in der aktuellen Version.
Sie haben es sicherlich schon vermutet: Auch C-ICAP muß zunächst wieder konfiguriert werden. Es reicht aus wenn Sie in der Datei "/etc/c-icap/c-icap.conf" lediglich zwei Zeilen anpassen. Hier ist der entsprechende Ausschnitt:
. . . # about this server (logs, info service, etc) # Default: # No value ServerAdmin root@gw01.sundermeier-werkzeugbau.de # TAG: ServerName # Format: ServerName aServerName # Description: # A name for this server. Used when displaying information about this # server (logs, info service, etc) # Default: # No value ServerName gw01 # TAG: TmpDir # Format: TmpDir dir . . .
Nun versuchen wir den C-ICAP-Server so einzustellen, daß er fortan bei jedem Systemstart automatisch mit startet und anschließend starten wir ihn erstmalig manuell. Das geht bekanntermaßen - wie schon eben bei Squid - so:
[root@gw01 ~]# chkconfig --list c-icap c-icap 0:Aus 1:Aus 2:Aus 3:Aus 4:Aus 5:Aus 6:Aus [root@gw01 ~]# chkconfig --level 2345 c-icap on [root@gw01 ~]# chkconfig --list c-icap c-icap 0:Aus 1:Aus 2:Ein 3:Ein 4:Ein 5:Ein 6:Aus [root@gw01 ~]# /etc/rc.d/init.d/c-icap status c-icap wurde beendet [root@gw01 ~]# /etc/rc.d/init.d/c-icap start Starting the ICAP server (c-icap): [ OK ] [root@gw01 ~]# /etc/rc.d/init.d/c-icap status c-icap (PID 10165 10160 10159 10157) wird ausgeführt ... [root@gw01 ~]#
Nun läuft C-ICAP zwar bereits, aber das tut er sozusagen nur standalone, ohne irgendetwas von Squid und dessen Services zu wissen. Und genauso wenig weiß Squid irgendetwas über C-ICAP. Beide leben einfach so aneinander vorbei. Später werden wir beide miteinander verknüpfen aber für den Augenblick belassen wir es hierbei.
2.3.) Dritte Voraussetzung: ClamAV
Den freien Virenscanner ClamAV ans Laufen zu bekommen ist komplizierter als das bei den anderen hier betrachteten Softwarekomponenten der Fall ist. Dennoch behandele ich dieses Thema hier am stiefmütterlichsten, denn ClamAV ist hier nicht das eigentliche Thema. Einen kurzen Abriß will ich aber trotzdem versuchen.
Zunächst wird die nackte ClamAV-Engine installiert. Der Befehl dazu lautet "yum install clamav". In der Regel installiert dieser Befehl drei Pakete: "clamav-data-empty", "clamav-lib" und "clamav". ClamAV ist zu diesem Zeitpunkt noch so rudimentär, daß man damit noch nichts anfangen kann, weil es noch nicht einmal irgendwelche Virensignaturen kennt.
Um es überhaupt gangbar zu machen benötigen wir nun aktuelle Virensignaturen. Die allerdings besorgen wir uns nicht über den Paketmanager, sondern taufrisch aus dem Internet. Zu diesem Zweck installiere ich das Paket "clamav-update". Dieses Paket beinhaltet im Wesentlichen das Binary "freshclam", was den Internetdownload erledigt. Die Installation geht wie gehabt mit "yum install clamav-update". Sofern noch nicht geschehen, wird dieser Befehl die Pakete "fedora-usermgmt-default-fedora-setup", "fedora-usermgmt-core", "fedora-usermgmt-shadow-utils", "fedora-usermgmt", "clamav-filesystem" und "clamav-update" installieren.
Der Befehl "freshclam" hat eine eigene Konfigurationsdatei "/etc/freshclam.conf". Die muß nun konfiguriert werden. Aber das ist nicht schwer. Durch das Auskomentieren einer Zeile wird freshclam scharfgeschaltet und mit einer weiteren Zeile geben wir den regionalen Downloadserver an. Hier zeige ich die entsprechenden Passagen:
. . . # Comment or remove the line below. #Example # Path to the database directory. # WARNING: It must match clamd.conf's directive! . . . # Uncomment the following line and replace XY with your country # code. See http://www.iana.org/cctld/cctld-whois.htm for the full list. # You can use db.XY.ipv6.clamav.net for IPv6 connections. DatabaseMirror db.de.clamav.net # database.clamav.net is a round-robin record which points to our most # reliable mirrors. It's used as a fall back in case db.XY.clamav.net is . . .
Jetzt erledigt der simple Befehl "/usr/bin/freshclam" den ganzen Rest. Mit einem Blick in das Verzeichnis "/var/lib/clamav" können Sie sich davon überzeugen, daß nun alle Virensignaturen vorhanden und auf dem aktuellen Stand sind.
Nun ist der Zeitpunkt gekommen unsere ClamAV-Engine zu testen. Nun ist sie nämlich voll funktionstüchtig. Probieren Sie das folgende:
[root@gw01 ~]# clamscan
/root/.bash_history: OK
/root/.bash_logout: OK
/root/.bash_profile: OK
/root/.bashrc: OK
/root/.cshrc: OK
/root/.tcshrc: OK
----------- SCAN SUMMARY -----------
Known viruses: 903226
Engine version: 0.96.5
Scanned directories: 1
Scanned files: 6
Infected files: 0
Data scanned: 0.02 MB
Data read: 0.01 MB (ratio 2.00:1)
Time: 9.351 sec (0 m 9 s)
[root@gw01 ~]#
Sie haben soeben die Dateien des Heimatverzeichnisses von root gescannt. Hier haben wir das erhoffte Ergebnis "Infected files: 0" erhalten. Oft erscheint zusätzlich auch ein deutlicher Warnhinweis von LibClamAV, daß die ClamAV Engine "outdated" sei. Dies können Sie getrost ignorieren, denn das besagt nur, daß die Engine selbst aktualisierungsbedürftig sei, nicht aber die Virensignaturen. Um die Engine selbst kümmert sich aber yum. Gewisse zeitliche Verwerfungen zwischen der ClamAV-Entwicklung und der Fedora-Paketierung sind einfach unvermeidlich.
Obwohl ClamAV nun im Prinzip läuft, reicht das dennoch nicht aus. ClamAV muß nämlich als Daemon laufen, damit SquidClamav später auf die ClamAV-Engine zugreifen kann. Das heißt, ClamAV soll als Serverprozeß ständig im Hintergrund laufen und nicht nur bei Bedarf einmalig angeschmissen werden. Dazu brauchen wir nun auch noch das Paket "clamav-server". Sie kennen das nun schon zu genüge: "yum install clamav-server".
Nun wirds etwas niggelig. Ich kann jetzt nur empfehlen, wechseln Sie in das Verzeichnis "/usr/share/doc/clamav-server-*" und befolgen Sie sehr genau die Anweisungen in der Datei README. Dort hat Enrico Scholz die weitere Vorgehensweise sehr gut beschrieben. Außer der Datei README finden Sie dort noch vier weitere Dateien die allesamt an einen anderen Ort kopiert, umbenannt und editiert werden müssen. Außerdem muß auch noch ein weiterer Benutzer angelegt werden, unter dessen Kennung der Daemon dann später läuft.
Wenn das erledigt ist, starten wir den ClamAV-Daemon für jetzt und für immer. Bei mir sieht das so aus:
[root@gw01 ~]# chkconfig --list clamd.gw01service clamd.gw01service 0:Aus 1:Aus 2:Aus 3:Aus 4:Aus 5:Aus 6:Aus [root@gw01 ~]# chkconfig --level 2345 clamd.gw01service on [root@gw01 ~]# chkconfig --list clamd.gw01service clamd.gw01service 0:Aus 1:Aus 2:Ein 3:Ein 4:Ein 5:Ein 6:Aus [root@gw01 ~]# /etc/rc.d/init.d/clamd.gw01service status clamd.gw01service wurde beendet [root@gw01 ~]# /etc/rc.d/init.d/clamd.gw01service start clamd.gw01service starten: [ OK ] [root@gw01 ~]# /etc/rc.d/init.d/clamd.gw01service status clamd.gw01service (PID 30204) wird ausgeführt ... [root@gw01 ~]#
Auf meinem Rechner gw01 gibt es nun einen Socket auf dem der ClamAV Daemon Anfragen auf Virenüberprüfungen entgegennimmt. Getreu dem alten UNIX-Prinzip "Alles ist eine Datei", ist dieser Socket die Datei "/var/run/clamd.gw01service/clamd.sock". Schauen Sie mal nach, ob Sie auch so eine Socket-Datei bei sich haben. Diese Socket-Datei müssen wir gleich SquidClamav bekanntgeben.
2.4.) Vierte Voraussetzung: SquidClamav
Zunächst wieder die Installation: "yum install squidclamav". Bei mir gabs nach diesem Befehl die Pakete "perl-FCGI", "perl-CGI" und natürlich "squidclamav".
Auch hier muß wieder konfiguriert werden, und zwar die Datei "/etc/squidclamav.conf":
. . . maxsize 5000000 # When a virus is found then redirect the user to this URL redirect http://192.168.1.101/error-page-virus.html # Path to the squiGuard binary if you want URL filtering #squidguard /usr/bin/squidGuard # Path to the clamd socket, use clamd_local if you use Unix socket or if clamd # is listening on an Inet socket, comment clamd_local and set the clamd_ip and # clamd_port to the corresponding value. clamd_local /var/run/clamd.gw01service/clamd.sock #clamd_ip 192.168.1.5,127.0.0.1 #clamd_port 3310 . . .
Die erste abgeänderte Zeile gibt an was Squid tun soll, wenn das Gespann SquidClamav/ClamAV tatsächlich einmal auf einen Virus stößt. Bei mir soll dann die Webpage "error-page-virus.html" von meinem eigenen Webserver angezeigt werden. Auf diese Seite können Sie allerdings nicht zugreifen. Sie müssen sich daher eine eigene "Virus gefunden!"-Webpage basteln und diese auf Ihrem eigenen Webserver ablegen. Können Sie nicht? Haben Sie nicht? Nun, dann tragen sie doch einfach die Zeile "redirect http://www.google.de" ein. Dann bekommen Sie statt des Viruses die Google Startseite zu sehen.
Die zweite geänderte Zeile verweist auf den schon erwähnten ClamAV-Socket. Sie weist SquidClamav an, über eben diese Socket-Datei mit ClamAV zu kommunizieren.
Leider sind wir an dieser Stelle noch nicht ganz durch. SquidClamav ist ganz und gar von C-ICAP abhängig. Deshalb würde yum auch bei der Installation von SquidClamav sofort C-ICAP als Voraussetzung mitinstallieren. Deshalb habe ich hier auch C-ICAP in der Kapitelreihenvolge vor SquidClamav behandelt. Diese Abhängigkeit zeigt sich auch darin, daß nun SquidClamav konfigurationstechnisch mit C-ICAP verheiratet werden muß. Dazu muß erneut die C-ICAP Konfigurationsdatei "/etc/c-icap/c-icap.conf" angepaßt werden.
. . . # Simple test service # Example: # Service echo srv_echo.so #Service echo srv_echo.so Service squidclamav squidclamav.so # Module: sys_logger # Description: . . .
Dieser Verbindung muß der Pastor noch seinen Segen geben, damit sie wirksam wird: "/etc/rc.d/init.d/c-icap restart".
3.) Squid nur mit SquidGuard
Jetzt ist der Moment gekommen wo Squid nicht mehr alleine laufen soll, sondern seinen ersten Service spendiert bekommt. Wir starten mit SquidGuard. Auch weil der mit nur einer einzigen Konfigurationszeile in Betrieb genommen werden kann. Ich hoffe also auf ein frühes Erfolgserlebnis.
3.1.) Einbinden von SquidGuard in Squid mittels URL-Rewrite
Nachdem SquidGuard installationstechnisch insoweit vorbereitet ist, stellt sich nun erstmals die Frage, wie SquidGuard in Squid eingebunden wird.
Dafür gibt es prinzipiell zwei Methoden. Die erste und einfachste Methode besteht darin, daß Squid den aus dem Internet empfangenen Datenstrom zunächst direkt und ohne Umwege an SquidGuard weiterleitet. Dann wartet Squid das Urteil von SquidGuard ab und erst danach - sofern die Website unbedenklich erscheint - reicht Squid dann den Datenstrom an den anfragenden PC weiter. Dieser Sachverhalt ist in der nebenstehenden Abbildung verdeutlicht.
Bei dieser Methode wird SquidGuard aus Squid heraus aufgerufen, weshalb SquidGuard auch unter der Benutzerkennung von Squid also UID=squid=23 und GID=squid=23 ausgeführt wird. Darum ist es wichtig, daß alle Blacklist-Dateien auch genau diesem Benutzer gehören. Der Befehl "chown -R squid /var/squidGuard/blacklists" gefolgt von "chgrp -R squid /var/squidGuard/blacklists" erreicht genau das. Was für die Blacklist-Dateien gilt, gilt auch für die Log-Dateien. Ohne entsprechende Rechte kann SquidGuard Nichts protokollieren. Wir brauchen also auch noch ein "chown -R squid /var/log/squidGuard" und ein "chown -R squid /var/log/squidGuard".
Diese Methode läßt sich, wie schon gesagt, mit nur einer einzigen Textzeile in Squids Konfigurationsdatei aktivieren. Dazu erweitern wir die Datei "/etc/squid/squid.conf" so wie hier gezeigt:
acl localnet src 192.168.1.0/24
http_access allow localnet
http_access deny all
http_port 192.168.1.11:3128
hierarchy_stoplist cgi-bin ?
cache_dir ufs /var/spool/squid 1000 16 256
coredump_dir /var/spool/squid
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf
Ein Neustart von Squid mit "/etc/rc.d/init.d/squid restart" sollte nun auch SquidGuard zum Leben erwecken. Prüfen Sie doch einfach mal und versuchen Sie eine der einschlägig bekannten Porno-Websites aufzurufen, wie z.B. http://www.youporn.com. Sofern Sie sich schon eine entsprechende "Zugriff untersagt!"-Seite gebastelt haben, kriegen Sie die jetzt zu sehen, andernfalls eine Fehlermeldung von Squid, der die "Zugriff untersagt!"-Seite nicht findet. Wie auch immer, keinesfalls sollten Sie die Porno-Seite zu sehen bekommen. Und schauen Sie nun auch mal in die Protokoll-Datei "/var/log/squidGuard/porno.log". Hier finden Sie einen Eintrag, daß die Porno-Seite soeben geblockt wurde. So soll es ja auch sein.
3.2.) Einbinden von SquidGuard in Squid mittels C-ICAP
Rein theoretisch ist man nun versucht zwischen Squid und SquidGuard eine weitere Softwareschicht zu schieben. Diese Software ist der C-ICAP Server. Im Moment - solange SquidGuard der einzige Service von Squid ist - würde das natürlich noch keinen Sinn machen. Allerdings ist C-ICAP in der Lage beliebig viele weitere Services für Squid zu verwalten. Und bereits ab zwei Services würde das Zusammenspiel aller Softwarekomponenten schon deutlich strukturierter. Die nachfolgende Abbildung zeigt wie ich mir das vorstellen könnte.
Für Squid würde sich nur wenig ändern. Anstatt den empfangenen Datenstrom an SquidGuard weiterzuleiten würde nun an C-ICAP übergeben. C-ICAP seinerseits übergibt nun an SquidGuard, empfängt dann SquidGuards Entscheidung und reicht diese Entscheidung anschließend an Squid weiter. Squid liefert dann aus oder lenkt um, je nachdem.
Leider funktioniert das beschriebene Verfahren nicht, weil SquidGuard nur das URL-Rewrite-Verfahren unterstützt und nicht (oder vielleicht noch nicht) das C-ICAP-Verfahren. Zwar finden sich im Internet gelegentlich Hinweise, wonach das angeblich möglich sein soll, allerdings irren die Verfasser dieser Hinweise hinsichtlich der verwendeten Software. Und zwar handelt es sich dann nicht um SquidGuard selbst, sondern lediglich um ein SquidGuard ähnliches Modul zu C-ICAP. Dieses Modul ist der "URL filtering service" aus den "c-icap-modules" von Christos Tsantilas dem Autor von C-ICAP selbst. Der Irrtum hat wahrscheinlich seinen Grund darin, daß dieser "URL filtering service" mit den Blacklist-Datenbanken von SquidGuard umgehen kann. Allerdings hinkt der "URL filtering service" in seiner Funktionalität doch erheblich hinter SquidGuard hinterher.
Diesen Ansatz verfolge ich nicht weiter. Wäre ja auch sinnlos, es läuft ja schließlich nicht.
4.) Squid nur mit SquidClamav
Anders als SquidGuard ist die 6er Version von SquidClamav extra daraufhin konzipiert worden als C-ICAP-Service zu laufen. Deshalb ergibt sich nun auf jeden Fall das folgende Bild:
Unsere Aufgabe wird nun sein, erstens SquidGuard wieder stillzulegen, denn hier interessiert ja nur SquidClamav und wir wollen mit der Stilllegung von SquidGuard eine mögliche Fehlerquelle ausschalten. Zweitens wollen wir SquidClamav einschalten. Genauergesagt wollen wir Squid dazu überreden SquidClamav auch zu benutzen, denn eigentlich läuft SquidClamav ja schon. Es wurde ja schon oben im Kapitel 2.4.) gleichzeitig mit dem Start von C-ICAP zum Leben erweckt.
Das Erste ist unsere leichteste Übung. Die eben noch eingefügte Konfigurationszeile "url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf" wird einfach auskommentiert. Das Zweite ist komplizierter. Hierfür kennt Squid zahlreiche eigene Konfigurationsparameter, die alle mit "icap_" beginnen.
Probiern wir es aus und editieren wir die Datei "/etc/squid/squid.conf" wie folgt:
acl localnet src 192.168.1.0/24 http_access allow localnet http_access deny all http_port 192.168.1.11:3128 hierarchy_stoplist cgi-bin ? cache_dir ufs /var/spool/squid 1000 16 256 coredump_dir /var/spool/squid refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 #url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf icap_enable on icap_send_client_ip on icap_send_client_username on icap_client_username_encode off icap_client_username_header X-Authenticated-User icap_preview_enable on icap_preview_size 1024 icap_service squidclamav_service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav icap_service squidclamav_service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_access squidclamav_service_req allow all adaptation_access squidclamav_service_resp allow all
Wirklich interessant sind nur die beiden Zeilen die mit "icap_service" beginnen. Ich selbst habe nämlich lange Zeit fälschlicherweise gedacht, Squid würde dahingehend konfiguriert C-ICAP zu benutzen und C-ICAP dahingehend SquidClamav zu benutzen. Das ist aber falsch. Die Erwähnung von SquidClamav in der Konfigurationsdatei von C-ICAP - erinnern Sie sich noch: "Service squidclamav squidclamav.so" - hat zunächst nur rein deklaratorischen Charakter und bedeutet noch lange nicht, daß SquidClamav auch verwendet wird. Erst der explizite Aufruf von SquidClamav in der Konfigurationsdatei von Squid führt auch zur tatsächlichen Verwendung. Und Achtung: Es gibt gleich zwei icap_service-Konfigurationsdirektiven für nur einen Service, einmal für den Request-Teil und einmal für den Respond-Teil.
Nach einem Neustart von Squid mit "/etc/rc.d/init.d/squid restart" ist nun der Zeitpunkt für den ultimativen Härtetest gekommen. Gehen Sie doch mal an einen Ihrer Clientrechner und schmeißen Sie dort den Browser Ihrer Wahl an. Dann besuchen Sie die Referenz-Website für Testviren schlechthin unter der URL http://www.eicar.org/anti_virus_test_file.htm. Anschließend versuchen Sie eine der dort gelisteten Virusdateien downzuloaden. Wenn Sie alles richtig gemacht haben, verweigert Squid nun den Download und präsentiert Ihnen stattdessen eine schlichte "Virus gefunden!"-Webpage.
Ach ja, das geht natürlich nur bei den Viren über das http-Protokoll, nicht bei denen über https. Squid ist ein Proxy - also wie der Name schon sagt, nur ein Stellvertreter - und als solcher kann er einen SSL-verschlüsselten Datenstrom nicht einsehen. Das können nur die jeweiligen Endpunkte der Übertragungskette. Und das ist auch gut so, denn gelänge Squid die Einsicht in den Datenstrom, was wäre eine Verschlüsselung dann noch wert.
Noch eine Bemerkung: Gefundene Viren werden in den Logfiles von clamd mitprotokolliert. Für einen schnellen Überblick können Sie diesen Befehl verwenden: "grep FOUND /var/log/clamd.gw02service". Im Erfolgsfall sehen Sie so etwas: "stream(127.0.0.1@1881): Eicar-Test-Signature FOUND".
5.) Squid mit SquidGuard und mit SquidClamav
Im Prinzip sind drei Konstellationen möglich. Die erste sollte funktionieren, die zweite funktioniert definitiv nicht - ist aber als Anregung dennoch beschrieben - und die dritte ist die empfohlene. Ich behandele alle drei der Reihe nach.
5.1.) Variante 1 - Die ungetestete Variante
Wer kein Spaß am Experimentieren hat und nur ein ähnliches System ans Laufen bringen möchte, dem empfehle ich, diese Variante nicht auszuprobieren und lieber gleich mit der Variante 3 fortzufahren.
Wenn man nun die Services SquidGuard, so wie in 6.1. erläutert, und SquidClamav, wie in 7. dargestellt, unreflektiert miteinander kombiniert ergibt sich das nebenstehende Bild. SquidGuard wird mit der URL-Rewrite-Methode, und SquidClamav mit der C-ICAP-Methode aufgerufen. Ob sich die Reihenfolge in der dies geschieht irgendwie bestimmen läßt, weiß ich nicht, die Reihenfolge in der Konfigurationsdatei ist sicherlich nicht maßgeblich.
Die Konfigurationsdatei von Squid "/etc/squid/squid.conf":
acl localnet src 192.168.1.0/24
http_access allow localnet
http_access deny all
http_port 192.168.1.11:3128
hierarchy_stoplist cgi-bin ?
cache_dir ufs /var/spool/squid 1000 16 256
coredump_dir /var/spool/squid
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf
icap_enable on
icap_send_client_ip on
icap_send_client_username on
icap_client_username_encode off
icap_client_username_header X-Authenticated-User
icap_preview_enable on
icap_preview_size 1024
icap_service squidclamav_service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav
icap_service squidclamav_service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav
adaptation_access squidclamav_service_req allow all
adaptation_access squidclamav_service_resp allow all
5.2.) Variante 2 - Die unmögliche Variante
Persönlich hätte ich diese Variante am elegantesten empfunden:
Aber leider funktioniert dies nicht, weil SquidGuard das C-ICAP-Verfahren nicht unterstützt. Dennoch will ich mir es nicht nehmen lassen aufzuzeigen, wie eine mögliche Konfiguration ausgesehen hätte.
Die Konfigurationsdatei von Squid "/etc/squid/squid.conf":
acl localnet src 192.168.1.0/24 http_access allow localnet http_access deny all http_port 192.168.1.11:3128 hierarchy_stoplist cgi-bin ? cache_dir ufs /var/spool/squid 1000 16 256 coredump_dir /var/spool/squid refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 #url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf icap_enable on icap_send_client_ip on icap_send_client_username on icap_client_username_encode off icap_client_username_header X-Authenticated-User icap_preview_enable on icap_preview_size 1024 icap_service squidguard_service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidguard icap_service squidguard_service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidguard icap_service squidclamav_service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav icap_service squidclamav_service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_service_chain gw01_req_chain squidguard_service_req squidclamav_service_req adaptation_service_chain gw01_resp_chain squidguard_service_resp squidclamav_service_resp adaptation_access gw01_req_chain allow all adaptation_access gw01_resp_chain allow all
Aber wie gesagt: Dieses Verfahren funktioniert leider nicht und alle weiteren Spekulationen darüber sind müßig.
5.3.) Variante 3 - Die offizielle Variante
Dies ist quasi die offizielle Methode SquidGuard und SquidClamav gleichzeitig in Squid zum Laufen zu bringen.
Gilles Darold - der Entwickler von SquidClamav - hat in seiner Software extra einen Einklinkmechanismus für SquidGuard vorgesehen. Mittels einer eigenen Konfigurationsdirektive in SquidClamavs Konfigurationsdatei, läßt sich SquidGuard aus SquidClamav heraus aufrufen. Dadurch ergibt sich ein gestufter Prozeß. SquidGuard und SquidClamav stehen nicht gleichberechtigt nebeneinander, sondern SquidGuard steht hierarchisch unter SquidClamav.
Weil C-ICAP SquidClamav aufruft erbt SquidClamav auch die UID und die GID von C-ICAP. Und weil SquidClamav seinerseits SquidGuard aufruft erbt SquidGuard gleichfalls die UID und die GID von SquidClamav. Also werden unterm Strich sowohl C-ICAP als auch SquidClamav als auch SquidGuard unter der UID=c-icap=497 und unter der GID=c-icap=497 betrieben.
Damit SquidGuard also funktionieren kann, sind zunächst wieder die Rechte an den Blacklists und an den Log-Dateien zu ändern. Das Beste wird sein, wir stoppen Squid, C-ICAP und ClamAV bevor wir die Rechte ändern. Das alles geht so:
[root@gw01 ~]# /etc/rc.d/init.d/squid stop squid beenden: ................ [ OK ] [root@gw01 ~]# /etc/rc.d/init.d/c-icap stop Shutting down the ICAP server (c-icap): . [ OK ] [root@gw01 ~]# /etc/rc.d/init.d/clamd.gw01service stop clamd.gw01service beenden: [ OK ] [root@gw01 ~]# chown -R c-icap /var/squidGuard/blacklists [root@gw01 ~]# chgrp -R c-icap /var/squidGuard/blacklists [root@gw01 ~]# chown -R c-icap /var/log/squidGuard [root@gw01 ~]# chown -R c-icap /var/log/squidGuard [root@gw01 ~]#
In der Konfigurationsdatei von Squid "/etc/squid/squid.conf" wird die URL-Rewrite-Methode auskommentiert:
acl localnet src 192.168.1.0/24
http_access allow localnet
http_access deny all
http_port 192.168.1.11:3128
hierarchy_stoplist cgi-bin ?
cache_dir ufs /var/spool/squid 1000 16 256
coredump_dir /var/spool/squid
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
#url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf
icap_enable on
icap_send_client_ip on
icap_send_client_username on
icap_client_username_encode off
icap_client_username_header X-Authenticated-User
icap_preview_enable on
icap_preview_size 1024
icap_service squidclamav_service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav
icap_service squidclamav_service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav
adaptation_access squidclamav_service_req allow all
adaptation_access squidclamav_service_resp allow all
Und die Konfigurationsdatei von SquidClamav "/etc/squidclamav.conf" wird um den SquidGuard-Aufruf erweitert:
.
.
.
redirect http://192.168.1.101/error-page-virus.html
# Path to the squiGuard binary if you want URL filtering
squidguard /usr/bin/squidGuard
# Path to the clamd socket, use clamd_local if you use Unix socket or if clamd
# is listening on an Inet socket, comment clamd_local and set the clamd_ip and
.
.
.
Jetzt starten wir alle Serverprozesse wieder ordentlich und in der richtigen Reihenfolge.
[root@gw01 ~]# /etc/rc.d/init.d/clamd.gw01service start clamd.gw01service starten: [ OK ] [root@gw01 ~]# /etc/rc.d/init.d/c-icap start Starting the ICAP server (c-icap): [ OK ] [root@gw01 ~]# /etc/rc.d/init.d/squid start squid starten: . [ OK ] [root@gw01 ~]#
Nun testen Sie noch ein letztes mal. Wird die Porno-Website geblockt? Wird der Testvirus zuverlässig erkannt? Ich hoffe, es hat alles geklappt und Ihr Internet ist nun schneller, kontrollierter und sicherer. Bleib nur noch die Frage nach der Stabilität und Zuverlässigkeit des ganzen Aufbaus, aber das wird die Zeit zeigen.
