Categories
Internet, Unix en security

SpamAssassin op automatische piloot

In de afgelopen periode is SpamAssassin al meerdere malen aanbod gekomen en vooral in de context met Bayesian-filtering, maar er is nog veel meer. Zeker nu recentelijk release 3.3 het daglicht heeft gezien wordt het tijd om eens wat dieper in SpamAssassin te duiken.

Een van de grootste probleempunten met SpamAssassin was altijd de ruleset en de strijd met de spammers om die rules net te omzeilen. Bayesian-filtering lost een deel van dit probleem op, maar het andere probleem is de ruleset zelf. Voorheen werden rules met SpamAssassin meegeleverd en werden ze pas bijgewerkt als je een nieuwe versie van SpamAssassin installeerde. Het mag duidelijk zijn dat dit een onbegonnen strijd is, maar ook een gevaarlijke strijd. Zeker voor installaties die afhankelijk waren van DNS blacklists cq whitelists en waarbij de beheerder van de lijst besloot om zijn lijst op te heffen bijvoorbeeld.

De SARE-regels zijn een hele tijd populair geweest en zijn dat helaas nog steeds. Dit terwijl ze stelselmatig worden opgenomen in de ruleset van SpamAssassin zelf. Gelukkig heeft oa SARE er wel voor gezorgd dat er een update methode kwam die met de 3.3 release verplicht is geworden. Hiermee volgt SpamAssassin eigenlijk ClamAV in de voetsporen en is het verspreiden van een vaste ruleset overbodig geworden.

De eerste stap is eigenlijk heel simpel met het draaien van het commando sa-update als de gebruiker root op Debian. Als we nu in /var/lib/spamassassin/ kijken dan zien we het volgende:

$ ls -l /var/lib/spamassassin/ /var/lib/spamassassin/*/
/var/lib/spamassassin/:
total 8
drwxr-xr-x 3 root root 4096 2010-01-02 14:46 3.002005

/var/lib/spamassassin/3.002005/:
total 8
drwxr-xr-x 2 root root 4096 2010-01-02 14:46 updates_spamassassin_org
-rw-r--r-- 1 root root 2431 2010-01-02 14:46 updates_spamassassin_org.cf

We zien netjes de betreffende versie van SpamAssassin en in die directory de ruleset zoals die nu voor versie 3.2.5 wordt aanbevolen door SpamAssassin. Deze regels worden automatisch meegenomen als SpamAssassin de volgende keer start. Nu kan je zelf een paar regels in de crontab van de gebruiker root zetten, maar in Debian zijn al voorzieningen getroffen. Door het onderstaande aan te passen in het bestand /etc/dedault/spamassassin zal automatisch de sa-update worden gedaan en wanneer nodig SpamAssassin worden geherstart.

CRON=1

Helaas stopt hier het verhaal niet, want op dit moment worden services zoals Amavisd-new, die ook de SpamAssassin ruleset kan gebruiken, niet herstart. Op moment van schrijven staan bugs 315961 en 567205 hier nog over open. Totdat die zijn opgelost kan de volgende extra code geen kwaad aan het einde van /etc/cron.daily/spamassassin

test -f /var/run/amavis/amavisd.pid && /etc/init.d/amavis force-reload

Dit laatste is natuurlijk op eigen risico, maar het lost de bug voor mij al een redelijke tijd op.

Categories
Internet, Unix en security

GPG onderhouden

Het is alweer ruim een jaar geleden dat ik een posting deed om automagisch GnuPG te onderhouden, maar de tijd heeft niet stilgestaan. Helaas is de tijd ook weer niet zo snel gegaan als gehoopt. Hoewel het framework binnen GNOME belooft om ontbrekende keys automagisch op te halen is de volgende aanpassing aan ~/.gnupg/gpg.conf wel aan te raden om alle “legacy” applicaties ook correct te laten werken.

keyserver-options auto-key-retrieve timeout=5

Helaas zal hierdoor je public keyring wel groeien naarmate de tijd vordert. In de posting van 2008 werden keys in de public keyring al ververst en deze opdracht in nu uitgebreid om verlopen en/of ingetrokken keys uit de locale cache te gooien.

37 20 * * Sun ( gpg -q --refresh-keys ; gpg -q --check-trustdb --batch --yes ; gpg --delete-keys --batch --yes `LANG=C gpg --list-keys | egrep '\[(expired|revoked):' | sed -e 's/^.*\///; s/ .*$//' | sort -u` ) >/dev/null 2>&1

Op deze manier blijft de public keyring nog enigsinds beheersbaar en snel.

Bijgewerkt: Een wildcard verwijdert en de ANDs vervangen door een semicolons.

Categories
Internet, Unix en security

GnuPG onderhouden

PGP is een mooie vinding en hoewel het web of trust zwakheden kan hebben doordat mensen onzorgvuldig omgaan met hoe ze sleutels moeten ondertekenen. Maar helaas of gelukkig blijven er wijzigingen aan die web of trust plaats vinden doordat sleutels verlopen of relaties met andere sleutels zijn opgezet.

Om de lokale keystore te verversen en opnieuw het web of trust te berekenen is het verstandig om dit een per maand of per paar weken te doen. Dit afhankelijk van de wijzigingen die je verwacht en hoe actief je bent. Het volgende commando in cron doet alles wat nodig is om de keystore elke zondagavond bij te werken.


37 20 * * * Sun ( gpg -q --refresh-keys && gpg -q --check-trustdb --batch --yes ) >/dev/null 2>&1

Wel een punt van aandacht. De tijd 20:37 is een gekozen random tijd, maar kies een eigen tijdstip zodat de keyservers niet elke zondagavond op hetzelfde tijdstip worden bestookt.