In diesem Artikel möchte ich zeigen, wie man die Firewall IPCop und einen Ubuntu-Host so konfigurieren kann, dass normaler Webtraffic einerseits gecached (Squid Proxy), andererseits mit Hilfe von HAVP (HTTP Antivirus Proxy) auf Malware on-the-fly gescanned werden kann. Dazu benötigen wir beim IPCop-System min. 3 Netzwerk-Schnittstellen und einen zusätzlichen Host, auf dem wir die Ubuntu-Server Distribution aufspielen und der dann als Antiviren- und Proxy-Server dient. Dieser Antiviren-Server muss nicht auf einem physikalischen Host laufen, bei uns läuft dieser z.B. in einer Hyper-V VM (wobei hier noch etwas mehr Aufwand betrieben werden muss). Von einer Virtualisierung der Firewall-Distribution IPCop sollte man aber aus Sicherheitsgründen Abstand nehmen.

Abgrenzung des Artikelinhaltes zum Copfilter-Projekt

Der Copfilter bietet einen Mail-/Webscanner und Spam-Erkennung im IPCop selber. Es gibt für mich 3 Gründe, was gegen den Copfilter spricht:

1. Sicherheitsbedenken: Jeder zusätzliche Dienst auf einer Firewall stellt ein potentielles Sicherheitsrisiko dar.
2. Performance: Durch schnelle Internetanschlüsse kann es trotz schnellem Rechner zu einer hohen Auslastung und damit erhöhten Latenzen (schlecht für Online-Gamer) kommen.
3. zusätzliche Antiviren-Scanner: Noch werden einige AV-Scanner wie der freie von AVG nicht von Copfilter supportet.

Wer ansonsten mit obigen Bedenken leben kann, dem kann ich eigentlich nur den Copfilter empfehlen und sich die Arbeit und zusätzlichen Ressourcenaufwand ersparen.

Grafische Veranschaulichung des Vorhabens

Und hier nochmal ein Prinzip-Bild der Squid-HAVP-Squid Sandwich-Konfiguration:

Dabei muss man noch anmerken, dass diese Sandwich-Konfiguration ihre Vorteile bietet: Man kann FTP per Browser benutzen, was der HAVP allein aus nicht unterstützt. Benutzt man nur 1x Squid und 1x den HAVP funktioniert es ebenfalls nicht. Zusätzlich kann man so das eigentliche HDD-Caching auf ein größeres und ausgefeilteres Storage-System im AV-Proxy Server vornehmen, was vor allem in sehr großen Netzwerken interessant sein dürfte und hier zu einem Performance Plus führen sollte. Wenn man will, kann man das Spielchen natürlich noch weiter treiben und HAVP-Proxy und 2. Squid nochmals trennen.

1. IPCop Konfiguration

Für die Installation und sonstige Fragen verweis ich einfach nur auf die gut geschriebenen Handbücher. Als Netzwerk-Konfiguration für unser Vorhaben benötigen wir mindestens die „Rot-Orange-Grün“- oder „Rot-Blau-Grün“-Konstellation, es funktioniert natürlich auch mit der „Rot-Orange-Blau-Grün“-Kombi – hier sieht man noch ein Beispiel-Netzwerk. Wer noch die alte 1.4.21 Version benutzt, dem empfehle ich das AdvancedProxy-Addon, im 2.xxer ist es schon enthalten.

1.1. (Advanced-)Proxy Einstellungen

Als Beispiel hol ich hier meinen Screenshot aus dem Artikel „IPCop als RAM-only Proxy“ hervor:

Ich gehe mal die wichtigsten Punkte für unser Vorhaben durch, für den Rest verweis ich auf das gut geschriebene Handbuch zum AdvancedProxy bzw. den (zum Zeitpunkt des Artikels noch unvollständigen) Handbüchern des IPCop 2.

Aktiviert auf Grün: Sollte natürlich angehakt sein, wenn der Proxy vom Grünen Netz genutzt werden soll.

Aktiviert auf Blau: Falls der AV-Proxy Server im Blauen Netz stehen soll, sollte hier der Haken rausgenommen werden. Benutzt man eine Rot/Orange/Blau/Grün-Netzwerkkonfiguration und der AV-Proxy Server steht in Orange, kann diese Option natürlich aktiviert werden, falls WLAN-Clients über den Proxy mit dem Internet kommunizieren sollen.

Transparent auf Grün: Der transparente Modus ermöglicht das automatische Umleiten von HTTP-Verkehr auf den Proxy des IPCop, ohne dass an den Clients der Proxy konfiguriert werden muss. Hierfür wird im IPCop eine interne Portweiterleitungs-Regel von Port 80 auf den im GUI festgelegten Proxy-Port gesetzt.

Transparent auf Blau: siehe „Transparent auf Grün„.

Der wichtigste Punkt ist vorgelagerter Proxy (Host:Port): Hier wird die IP-Adresse und der Port des HAVP Antiviren-Proxys eingetragen. Unter dieser IP und dem Port muss später der HAVP-Proxy auf dem Ubuntu-Server erreichbar sein. Die IP muss natürlich aus dem Blauen oder Orangenen Netz kommen, je nachdem, wo man den AV-Server hinverfrachtet.

Die anderen Optionen unter „Vorgelagerter Proxy“ lassen wir für unser Vorhaben frei. Wer hierüber genaueres wissen will, siehe Handbuch.

Die Werte für Cachegröße im Arbeitsspeicher (MB) und Cachegröße auf der Festplatte (MB) kann jeder selber festlegen, im Screenshot sind die Werte für eine RAM-only Konfiguration des Squid eingestellt, was bei dem 1.4.21 IPCop erst nach einem Kniff funktioniert.

Wichtig ist noch, dass unter „Netzwerkbasierte Zugriffskontrolle“ das Grüne und evt. Blaue Netz als die „Erlaubten Netzwerke“ eingetragen sind.

Die anderen Optionen wie MIME-Type Filter, Download-Drosselungen oder Zeitbeschränkungen können nach Belieben verändert werden.

1.2. Konfiguration beim IPCop 1.4.21

Bei der Zugriffs-Konfiguration sollte man folgende Tabelle vor Augen haben:

Welcher Datenverkehr ist zwischen den Schnittstellen erlaubt?

Dadurch erklären sich die beiden folgenden Unterpunkte etwas besser.

1.2.1. HAVP Antiviren Server im Orangenen Netzwerk (DMZ)

Wir haben bei uns den AV-Proxy in der DMZ stehen. Normalerweise stehen da nur richtige Server drin. Ein Web-Proxy ist aber eher ein Stellvertreter oder Vermittler zwischen Client und Webserver. Damit der AV-Proxy auf den Proxy des IPCop zugreifen kann, müssen wir sogenannte DMZ-Schlupflöcher erstellen:

Dabei ist die Quelle unser AV-Proxy Server in der DMZ (Orange) und das Ziel der IPCop-Proxy.

1.2.2. HAVP Antiviren Server im Blauen Netzwerk (WLAN)

Steht der AV-Proxy Server im Blauen Netz, müssen wir diesen in den MAC-/IP-Adressfilter (Zugriff auf Blau) eintragen. Standardmäßig wird jeglicher Zugriff von Blau ins Internet unterbunden.

Wahlweise kann anstatt der IP-Adresse auch die MAC-Adresse benutzt werden. Der DHCP-Server und DNS-Proxy des IPCop können hier im Gegensatz zur Stellung im Orangenen Netz normal benutzt werden.

1.3. Firewall-Regeln beim IPCop 2

Auch hier gelten bestimmte Regeln zwischen den Schnittstellen, die von der verwendeten Firewallrichtlinie abhängig sind:

Welcher Traffic ist zwischen den Schnittstellen erlaubt?

1.3.1. HAVP Antivirus Server in Orange

Beim IPCop 2 wurde das Firewall-Menü grundlegend geändert, da das ehemalige 1.4er-Addon „Block Outgoing Traffic BOT“ nun standardmäßig mit von der Partie ist. Den Punkt DMZ-Schlupflöcher gibt es nicht mehr, stattdessen wird dies (und anderes) im Menüpunkt „Firewall-Regeln“ eingestellt.

• als erstes im Firewall-Menü unter Firewall-Einstellungen den erweiterten Modus aktivieren, denn nur so erlaubt uns IPCop die Firewall zwischen Orange und dem IPCop-Proxy zu öffnen

• im Firewall-Menü den Punkt Firewall-Regeln wählen
• dann oben den Punkt „Zugriff auf IPCop„
• die Regel entsprechend dem Screenshot erstellen, die Quell-IP-Adresse und den Quell-Port auf den HAVP-Proxy (HAVP-Port wird später in der Konfiguration des HAVP eingestellt) anpassen

• anschließend die Regel „Speichern„.

Auch hier gilt, dass man von der DMZ aus keinen Zugriff auf den IPCop internen DHCP-Server und DNS-Proxy hat – man muss also die IP-Adress- und DNS-Daten im AV-Proxy statisch vergeben und als DNS-Eintrag externe DNS-Server verwenden!

1.3.2. HAVP Antivirus Server in Blau

Beim IPCop 2 sieht es hier ähnlich dem alten Cop aus – vorausgesetzt, der Adressfilter ist in den Schnittstellen-Richtlinien aktiviert:

Der Punkt im IPCop 2 heißt hier jetzt sinnvollerweise „Adress-Filter“ im Firewall-Menü. Ansonsten gilt dasselbe wie beim alten Cop.

Damit ist die Konfiguration des IPCops abgeschlossen. Wenn man jetzt versucht vom grünen (bzw. auch vom blauen, je nach Konfiguration des IPCops) Netz aus Webseiten aufzurufen, wird man mit einer netten Fehlermeldung konfrontriert, was auch vollkommen normal ist, denn es fehlt ja noch unser AV-Proxy Server.

2. Konfiguration des Ubuntu-Servers zum HAVP- und Squid-Proxy

Ich empfehle für größere Netze einen dedizierten Server mit mindestens 2 Festplatten (nicht im RAID-Verbund) oder 1 Server-SSD (SLC- oder für Serverbetrieb ausgelegte MLC-SSDs). Wir lassen den AV-Proxy Server in einer Hyper-VM laufen, dessen zwei virtuelle Festplatten auf jeweils zwei physikalischen Festplatten liegen. Je mehr User gleichzeitig das Web nutzen, je stärker werden die Zugriffszeiten der Storages eine Rolle spielen, vor allem, wenn man sehr große Caches anlegen will.

Warum eigentlich Ubuntu 11.10? Diese Version unterstützt die letzten ClamAV- und HAVP-Versionen in den Paketquellen, so dass die Installation deutlich einfacher wird.

2.1. Installation von Ubuntu 11.10 Server Edition

• Image runterladen: http://www.ubuntu.com/download/server/download
• auf CD brennen (oder die .iso in der virtuellen Maschine mounten)
• den Rechner/VM vom CD-/DVD-LW booten lassen

Nach allgemeinen Sprach-, Länder- und Tastaturabfragen wird das Netzwerk eingerichtet.

2.1.1. Netzwerk- und Host-Einstellungen

AV-Server in der DMZ (Orange): Es müssen die Adress-Einstellungen manuell vorgenommen werden.

• IP-Adresse: muss aus dem Orangenen Netz kommen und der IP-Adresse des „vorgelagerten Proxys“ in der Proxy-Weboberfläche des IPCops entsprechen
• Subnet-Mask: entspicht der Subnet-Maske des Orangenen Netzes
• Gateway: IP-Adresse der Orange-Schnittstelle des IPCop
• DNS-Server: muss ein externer sein! (z.B. Google DNS 8.8.8.8, 8.8.4.4 oder DNS des ISP)

AV-Server in Blau: Hier ist der automatische Adress-Bezug über DHCP-Server möglich.

Über den DHCP-Server (im IPCop unter DHCP-Optionen „Aktiviert auf Blau“ wählen) des IPCop kann die IP-Adresse über MAC-IP-Adress Bindung fixiert werden. Ansonsten können die Adress-Daten natürlich auch manuell eingestellt werden, als DNS-Server und Gateway wird die IP-Adresse der Blauen Schnittstelle des IPCops benutzt.

Im Anschluss muss noch der Host– und Domain-Name angegeben werden, bevor das Setup mit der Partitionierung fortfährt.

2.1.2. Partitionierung

• „Manuelle“ Partitionierung wählen
• 1. Datenträger auswählen (meist „sda“ oder „hda“)
• neue Partitionstabelle schreiben lassen

Ich empfehle 4 Partitionen (bzw 5 falls man nur ein Laufwerk verwendet) auf dem 1. Datenträger anzulegen. Am Ende des Anlegens einer Partition „Anlegen der Partition beenden“ wählen.

Die Einhängepunkte /var/log, /havp-scan und /squid-cache müssen „von Hand eingegeben“ werden.

Für die Größe der Partitionen kommt es wieder drauf an, wie man Squid einrichtet. Squid legt nämlich eine sogenannte Cache-Swap-State Datei an, die soweit ich das mitbekommen habe durchaus die Größe des eigentlichen Caches annehmen kann (man möge mich berichtigen). Standardmäßig wird diese Datei in dem selben Verzeichnis wie der eigentliche Cache angelegt (hier gibt es dann wieder Performance-Optimierungs-Potential für Squid, wenn man die Cache-Swap-State Datei auf ein dediziertes Laufwerk legt). Belässt man diese Einstellung also auf „default“, würde die /squid-cache-Partition den Mammut-Anteil (bei nur einem verbauten Laufwerk 60-70% des Laufwerk-Speicherplatzes) bekommen. Für das root-Verzeichnis / reichen dann 5-20GB (je nachdem was man mit dem Server noch alles machen will auch mehr), /var/log würde ich 5-10GB schenken (je nach Auslastung und logrotate-Einstellungen) und für das /havp-scan-Verzeichnis, in dem HAVP die zu scannenden Dateien anlegt, reichen 1GB. Die Swap-Partition würde ich maximal mit 1GB anlegen – wird diese stark benutzt, ist der Server sowieso fehlkonfiguriert.

Die /havp-scan-Partition muss nicht unbedingt angelegt werden. Die Paket-Installation von HAVP unter der neuesten Ubuntu-Version legt hier schon automatisch ein Loopback-Device an, welches die von HAVP benötigten Eigenschaften besitzt (mandatory locks). Wer die Partition selber anlegen will, muss diese später mit der Option „mand“ mounten (siehe 2.3.1.).

Mit „Partitionierung beenden und Änderungen übernehmen“ schließen wir die Partitionierung des 1. Laufwerkes ab.

Haben wir 2 Festplatten verbaut, kommt hier das Cache-Verzeichnis von Squid drauf. Der Vorgang ist ansonsten analog.

• 2. Festplatte wählen („sdb“ oder „hdb“ muss hier nicht stimmen, es hängt auch davon ab, an welchem Port das Laufwerk angeschlossen ist)
• neue Partitionstabelle schreiben lassen
• wir benötigen nur eine Partition:

Am Ende wieder „Partitionierung beenden und Änderungen übernehmen“ auswählen.

2.1.3. Benutzername und Softwareauswahl

Im Anschluss an die Partitionierung müssen wir uns einen Benutzernamen mit zugehörigem Passwort ausdenken. Dieser Benutzer bekommt automatisch sudo-Rechte.

Bei der darauf folgenden „Software-Auswahl“ benötigen wir nur den OpenSSH-Server, der Rest bleibt abgehakt. Danach noch die Grub Boot-Loader Abfrage abnicken. Das System führt am Ende einen automatischen Neustart durch – die Grundinstallation ist damit abgeschlossen.

 2.1.4. nachträgliches Ändern der Netzwerk-Einstellungen

Natürlich kann man IP-Adresse, Gateway etc. unter Ubuntu auch nachträglich ändern, dazu die Datei /etc/network/interfaces öffnen:

sudo nano /etc/network/interfaces

Der Inhalt sieht je nach vorherigem Setup (manuell oder DHCP) so aus:

automatisch/DHCP:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

manuell/statisch:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.10.3
netmask 255.255.255.0
gateway 192.168.10.1

Nach einer Anpassung mit Str-O speichern und per Str-X nano wieder verlassen.

Für die DNS-Server folgende Datei bearbeiten:

sudo nano /etc/resolv.conf

und den/die DNS-Server eintragen:

# z.B. für DNS-Proxy an blaue Schnittstelle
nameserver 192.168.1.1

# für DMZ
nameserver 8.8.8.8
nameserver 8.8.4.4

Ist man mit den Einstellungen fertig, muss man das Netzwerk nochmal neu starten:

sudo /etc/init.d/networking restart

Im Anschluss mit

ping google.com

die Internetverbindung testen.

2.1.5. Ubuntu updaten

Funktioniert die Netzwerk- und Internet-Anbindung sollten wir als allererstes Ubuntu auf den neuesten Stand bringen:

sudo aptitude update && sudo aptitude full-upgrade

2.1.6. Optional: root freischalten

Dies ist sicherheitstechnisch nicht empfohlen. Wer aber z.B. viel mit WinSCP arbeitet und die ständigen Konsolenbefehle scheut, der wird den root-Zugang benötigen, da dem normalen Benutzer ohne sudo-Zugriff administrative Rechte fehlen.

sudo passwd root
(neues root-Passwort 2x eingeben)

Im Anschluss kann man sich mit logout abmelden und mit dem Benutzer „root“ und dem eben vergebenen Passwort wieder anmelden.

2.2. Antivirus-Scanner

Damit der HAVP-Proxy überhaupt Malware erkennen kann, benötigt er mindestens einen Antiviren-Scanner. Wir werden hier die beiden freien Scanner „ClamAV“ und „AVG Free Linux“ benutzen. Natürlich kann man noch weitere Scanner wie Kaspersky, TrendMicro oder F-Prot einbauen, diese benötigen aber eine Lizenz.

2.2.1. Installation von ClamAV

ClamAV befindet sich in den Ubuntu-Paketquellen und kann daher sehr einfach installiert werden.

sudo aptitude install clamav-daemon

HAVP bietet die Möglichkeit, ClamAV über die Bibliotheken von ClamAV oder über den Daemon anzubinden. Ubuntu hat das Anbinden von ClamAV über die „libclamav6„-Bibliothek nun gefixed, so dass man wieder den bewährten, Ressourcen schonenderen Library-Scanner benutzen kann und der auch durch die HAVP Ubuntu-Paket-Installation standardmäßig aktiviert wird.

2.2.2. Installation von AVG Free Linux Edition

AVG Free Linux laden wir als Debian-Paket (Ubuntu stammt von Debian ab) von der AVG-Webseite herunter: http://free.avg.com/de-de/download-free-all-product

cd /tmp
wget http://download.avgfree.com/filedir/inst/avg2011flx-r1408-a4116.i386.deb

Am besten kopiert man sich den Download-Link von der AVG-Webseite in die putty-Konsole da sich die Versions-Nummern natürlich ändern werden.

Anschließend wird AVG installiert:

sudo dpkg -i ./avg2011flx-r1408-a4116.i386.deb

Danach den avgd-Daemon starten:

sudo service avgd start

Und die Viren-Definitionen aktualisieren:

sudo avgupdate

Ich empfehle noch folgende Einstellungen, die einige Fehler im Zusammenspiel mit HAVP beheben:

sudo avgcfgctl -w Default.tcpd.avg.read_timeout=500
sudo avgcfgctl -w Default.tcpd.avg.request_timeout=500

Ohne diese Einstellungen kommt es hin und wieder zu Scanner-Timeouts (sieht man in der /var/log/havp/error.log) und Webseiten werden nicht vollständig geladen.

Die komplette AVG-Konfiguration kann man sich übrigens mit folgendem Befehl erstellen lassen:

sudo avgdiag.sh

Dies erstellt ein .tar.gz-Paket in dem sich unter anderen eine config.txt Datei befindet. Hier kann man auch den eingestellten TCP-Port einsehen, den wir später für die HAVP-Konfiguration benötigen:

Default.tcpd.avg.ports=|54322|

2.3. HAVP-Proxy

2.3.1. Vorbereitungen

Als erstes müssen wir unserer /havp-scan-Partition die „mandatory locks“ beibringen, falls wir unsere eigene Partition hierfür angelegt haben:

sudo nano /etc/fstab

Dann den Eintrag für die /havp-scan-Partition suchen, hier mein Beispiel:

# /havp-scan was on /dev/sda6 during installation
UUID=f5d02458-8ee8-492d-b83d-54e578fb8e08 /havp-scan  ext2  defaults  0  2

Das ändern wir in:

# /havp-scan was on /dev/sda6 during installation
UUID=f5d02458-8ee8-492d-b83d-54e578fb8e08 /havp-scan  ext2  defaults,mand  0  2

Str-O + Str-X und mit einem Reboot testen, ob die Einträge wirken:

sudo reboot

Mit

mount

prüfen wir, ob die mandatory-locks auch aktiv sind, so sollte es in etwa aussehen:

/dev/sda6 on /havp-scan type ext2 (rw,mand)

2.3.2. Installation von HAVP

Dank aktueller Ubuntu-Paketquellen ist das jetzt sehr einfach geworden:

sudo aptitude install havp

Wer den Installationsprozess verfolgt, wird feststellen, dass Ubuntu selbständig ein Loopback-Device für HAVP und auch passende Benutzernamen (havp:havp) anlegt. Außerdem wird auch ein „logrotate„-Script angelegt, damit die Log-Dateien nicht zu groß werden.

Wer eine eigene Scan-Partition verwendet, muss noch die richtigen Rechte setzen:

sudo chown havp:havp /havp-scan

2.3.3. HAVP-Konfiguration

Die aktuelle HAVP-Konfiguration befindet sich unter /etc/havp/havp.config. Ich möchte hier nicht jede Einstellung durchgehen, sondern nur die für uns wichtigsten.

2.3.3.1. Scan-Verzeichnis setzen

Wer seine eigene Scan-Partition angelegt hat, muss den richtigen Pfad angeben. Wir suchen nach folgenden Abschnitt:

# SCANTEMPFILE /var/spool/havp/havp-XXXXXX

und ändern das in:

SCANTEMPFILE /havp-scan/havp-XXXXXX

2.3.3.2. squid als Parent-Proxy setzen

Da wir den squid-Proxy auf dem selben Host laufen haben, müssen wir folgenden Eintrag

# PARENTPROXY localhost
# PARENTPORT 3128
# PARENTUSER username
# PARENTPASSWORD password

zu

PARENTPROXY localhost
PARENTPORT 3128
# PARENTUSER username
# PARENTPASSWORD password

ändern. Der Port „3128“ ist der Standard-Port von Squid.

Testweise kann man diesen Eintrag auch auskommentiert lassen, um erstmal nur die Kombination IPCop-Proxy und HAVP zu testen.

2.3.3.3. HAVP-Port setzen

Den Eintrag

# PORT 8080

nach

PORT 8088

ändern.

2.3.3.4. AVG-Scanner einbinden

nach folgenden Absatz (ziemlich am Ende) suchen:

##### AVG Socket Scanner
#####

ENABLEAVG false

# AVG daemon needs to run on the same server as HAVP
#
# Default:
# AVGSERVER 127.0.0.1
# AVGPORT 55555

und nach

##### AVG Socket Scanner
#####

ENABLEAVG true

# AVG daemon needs to run on the same server as HAVP
#
# Default:
AVGSERVER 127.0.0.1
AVGPORT 54322

ändern. Den AVG-Port bekommt man mit avgdiag.sh wie unter 2.2.2. beschrieben heraus.

2.3.3.5. Anpassung für eigene Fehlerseiten

unter dem Punkt

# TEMPLATEPATH /etc/havp/templates/en

kann man den Verzeichnispfad seiner eigenen Fehlerseiten anpassen. Am besten einfach mal die vorhandenen Seiten angucken.

2.4. Squid-Proxy

Wer noch in der HAVP-Konfiguration den parent-proxy-Eintrag zum Testen auskommentiert hat (siehe 2.3.3.2.), der sollte diesen nun wieder aktivieren, immerhin wollen wir ja eine Squid-HAVP-Squid-Sandwich Konfiguration nutzen.

2.4.1. Installation von Squid

Auch die Installation von Squid ist dank der Paketquellen einfach.

Für Squid 2.x:
sudo aptitude install squid

Für Squid 3.x:
sudo aptitude install squid3

Welche Squid-Version sollte man nehmen?

Squid3 ist kompatibler zu neueren Webservern (z.B. beim http1.1-Standard) und sollte somit weniger Probleme mit manchen Seiten bereiten. Leider ist das COSS-Dateisystem zum Zeitpunkt der Artikelerstellung noch instabil, so dass Administratoren, die dieses Cache-System bevorzugen, auf die 2.x-Versionen ausweichen müssen.

Damit squid auf unser eigens angelegtes Cache-Verzeichnis auch Zugriff hat, müssen wir noch die passenden Rechte setzen:

sudo chown proxy:proxy /squid-cache

2.4.2. Konfiguration von Squid

Die Konfiguration von Squid3 finden wir unter /etc/squid3/squid.conf – und die ist nicht gerade kurz. Bei Squid2 weicht der Ort minimal ab: /etc/squid/squid.conf

Da man mit der Konfiguration des Squids ein eigenes Buch füllen könnte, will ich hier nur die für unser Vorhaben wichtigen Einstellungen durchnehmen. Alle Optionen von Squid sind in der squid.conf nochmal dokumentiert.

2.4.2.1. http_port

http_port localhost:3128

Das localhost sorgt dafür, dass Squid nur auf lokale Anfragen antwortet (HAVP-Proxy läuft bei uns ja auf demselben Host). Wer HAVP-Proxy und Squid später trennen will, sollte die defaults wiederherstellen:

http_port 3128

2.4.2.2. cache_mem, maximum_object_size_in_memory und memory_replacement_policy

cache_mem 1024 MB

Legt den (zusätzlichen) Cachespeicher im RAM fest.

Das ist nicht der maximal genutzte RAM von Squid. Je nachdem wie groß der Cache auf der Festplatte ist, benutzt Squid pro GigaByte Festplatten-Cache 10-15MB an zusätzlichen RAM!

maximum_object_size_in_memory 128 KB

Legt die maximale Größe der Objekte im RAM fest. Zu große Werte füllen den RAM schneller mit unwichtigen Dateien, die besser auf die Festplatte gecached werden sollten.

memory_replacement_policy heap GDSF

Ich empfehle für den RAM-Cache heap GDSF, um hier die Cache-Hitraten zu erhöhen.

2.4.2.3. cache_replacement_policy, cache_dir und maximum_object_size

cache_replacement_policy heap LFUDA

heap LFUDA erhöht die Byte-Rate beim Cachen auf die Festplatte.

cache_dir aufs /squid-cache 20000 32 256

Damit legen wir ein 20GB großes Dateisystem mit 32 Verzeichnissen mit jeweils 256 Unterverzeichnissen auf unser eigens angelegtes Cache-Verzeichnis an.

maximum_object_size 20480 KB

Wir erhöhen die Größe der Objekte, die auf der Festplatte gecached werden können.

Alle anderen Einstellungen lassen wir auf Standardwerte. Wer möchte, kann sich die einzelnen Optionen noch anschauen, ich empfehle aber erstmal das Grundsystem in Gang zu bringen und später Optimierungen oder weitere Anpassungen vorzunehmen.

Nachdem die squid.conf gespeichert wurde, müssen wir Squid nochmal neustarten, damit die neuen Einstellungen wirksam werden und das Cache-System angelegt wird:

Squid 3:

sudo service squid3 restart

Squid 2:

sudo service squid restart

2.4.3. Optional: der Squid Cache-Manager

Wer möchte, kann noch den Cache-Manager von Squid installieren:

sudo aptitude install squid-cgi

Im Anschluss müssen wir noch einen Cache-Manager Benutzer in der /etc/squid3/squid.conf festlegen:

cache_mgr oli
cachemgr_passwd your_Password all

Danach die Squid-Konfiguration neu laden:

sudo service squid reload

Unter http://<IP des AV-Proxys>/cgi-bin/cachemgr.cgi kann man dann die Cache-Manager Weboberfläche aufrufen.

2.4.4. Cache-Dateisystem optimieren

Um die Festplattenzugriffe weiter einzugrenzen kann man noch die „noatime“ Option in der /etc/fstab für das Cache-Verzeichnis setzen:

UUID=1bef607f-dd66-489f-97bd-8708a9e55265 /squid-cache ext2  defaults,noatime  0  2

3. Abschluss, Test und Fehlerbehandlung

Zum Abschluss des Projekts sollte man nochmal alles durchtesten:

• Netzwerkzugriff (z.B. mit ping)
• DNS-Abfragen (nslookup, dig)
• HTTP- und HTTPS-Zugriff auf verschiedenste Webseiten
• HTTP-Video-/Audio-Streaming Dienste
• HTTP- und FTP-Downloads
• Messenger-Kommunikation
• Online-Spiele
• Patchvorgänge (Games, Windows, AV-Software etc.)
• Wirksamkeit der Scanner (z.B. mit dem Eicar-Testvirus)
• Auslastung des AV-Servers (z.B. mit htop: sudo aptitude install htop)

3.1. Was tun bei Fehlermeldungen?

Hier gibts natürlich kein Patentrezept, dazu können Fehler einfach zu viele Ursachen haben, aber eines sollte man immer beherzigen: Logs lesen! Ich fasse die für dieses Projekt relevanten Log-Verzeichnisse hier nochmal zusammen:

IPCop

/var/log/squid/ – Error- und Access-Logs vom Proxy im IPCop

Der IPCop bietet außerdem über seine Weboberfläche unter dem Menüpunkt „Protokolle“ eine sehr komfortable Möglichkeit, alle relevanten Logdateien durchzuschauen.

AV-Proxy Server

/var/log/havp/ – Error- und Access-Logs von HAVP
/var/log/squid3/ – System- und Access-Logs von Squid 3
/var/log/squid/ – System- und Access-Logs von Squid 2
/opt/avg/av/log/0/ – verschiedenste Logdateien des AVG-Scanners
/var/log/clamav/ – Logs von ClamAV und dem Update-Mechanismus
/var/log/apache2/ – Apache2-Webserver Logs (bei Squid Cache-Manager Problemen)

Ansonsten findet man natürlich unter/var/log/ noch jede Menge andere Logdateien, die evt Hinweise auf Probleme geben könnten.

3.2. Hilfe bei störrischen HTTP-Servern

Es gibt leider einige Server (Login-Server von ICQ z.B.), womit der HAVP-Proxy nicht klarkommt. Mit dem IPCop und dem Advanced-Proxy hat man aber über ACLs die Möglichkeit, das Weiterleiten an den HAVP-Proxy für bestimmte Domains, IPs oder sogar URLs zu umgehen. In diesem Fall stellt der Squid im IPCop die Anfrage selber an die entsprechenden Server. Ein Scannen nach Viren findet dann aber von diesen Quellen nicht statt!

Um bestimmte Quellen am HAVP vorbeizuleiten muss in die Datei /var/ipcop/proxy/advanced/acls/include.acl (IPCop 1.4.21) bzw. /var/ipcop/proxy/acls (IPCop 2) folgendes hinzugefügt werden (am Beispiel des ICQ-Logins):

acl icq-login dstdomain login.icq.com
acl icq-login dstdomain login.oscar.aol.com
acl icq-login dstdomain ibucp-vip-d.blue.aol.com
acl icq-login dstdomain ibucp-vip-m.blue.aol.com
acl icq-login dstdomain bucp2-vip-m.blue.aol.com
acl icq-login dstdomain bucp-m08.blue.aol.com
acl icq-login-ip dst 205.188.153.98
acl icq-login-ip dst 205.188.153.97
acl icq-login-ip dst 64.12.161.153
acl icq-login-ip dst 178.237.23.235
acl icq-login-ip dst 64.12.239.116
acl icq-login-ip dst 64.12.249.116
acl icq-login-ip dst 4.23.47.126
acl icq-login-ip dst 198.78.197.254
acl icq-login-ip dst 205.188.95.208
acl icq-login-ip dst 8.27.131.126
acl icq-login-ip dst 62.52.45.177
acl icq-login-ip dst 205.188.27.208
always_direct allow icq-login
always_direct allow icq-login-ip

Es kann sein, dass das für ICQ noch nicht alle Login-Server sind, diese hier habe ich auch nur durch ausprobieren rausgefunden. Ich denke aber, dass das Prinzip klar ist, so dass man ohne Probleme diese Liste notfalls erweitern kann. Am Ende noch „Speichern und Neustart“ im (Advanced-)Proxy-Menü in der Weboberfläche wählen.

Dieser Trick mit der „always_direct allow„-Regel funktioniert, zumindest mit dem IPCop 2.xx (hier ist der neue 3.xx Squid eingebaut), auch noch wegen eines anderen Problems: Es gibt Webseiten, die mit den 2.7er Squid-Versionen inkompatibel sind und nur mit den neuen 3.xx Squid Versionen aufrufbar sind (Thread zum Problem im IPCop-Forum). Je nachdem welche Linux-Distribution man für den AV-Proxy Server benutzt, bekommt man hier ebenfalls noch die alte 2.7er Squid Version geliefert oder man möchte einfach noch das COSS-Dateisystem benutzen, welches mit den 3er Versionen des Squids zum Zeitpunkt der Artikelerstellung noch instabil ist. Hier kann man jetzt „always_direct allow„-Regeln im IPCop als Abhilfe festlegen.

3.3. Warum wird kein HTTPS- oder FTP-Verkehr gescannt?

HTTPS-Verbindungen sind verschlüsselt und können prinzipbedingt nicht gescannt werden. Für FTP-Verbindungen gibt es den frox-Proxy, der z.B. im Copfilter-Projekt verwendet wird. Wer möchte, kann sich das gern anschauen. Ich habe es nicht in den Artikel eingebaut, weil ich mit dem Copfilter und aktiviertem frox so einige Probleme mit ftp-Downloads bekam. Es scheint auch so, dass frox ein reiner transparenter Proxy ist, der dann sehr wahrscheinlich nur auf Gateways sinnvoll ist. Aber vlt hat ja von euch einer ne Idee, wie man FTP-Verkehr halbwegs effektiv scannen kann.

Ich freu mich jedenfalls auf eure Kommentare, Anregungen, Wünsche und Kritiken.