Artikel-Schlagworte: „Spamassassin“
Barracuda DSBL für SpamAssassin
11. November 2008 | 
Autor: Die Firma Barracuda ist für ihre Antispam-Appliances bekannt. Weniger bekannt ist, das sie auch eine DNS Blackliste zur Verfügung stellen. Wer sie in SpamAssassin nutzen möchte kann es folgendermaßen tun:
header RCVD_IN_BRBL eval:check_rbl('brbl-lastexternal', 'b.barracudacentral.org.', '127.0.0.2')
describe RCVD_IN_BRBL Received via relay listed in Barracuda RBL
score RCVD_IN_BRBL 1.0
tflags RCVD_IN_BRBL net
Ab SpamAssassin 3.3 ist die Abfrage dann in der Standard-Konfiguration vorhanden.
Spamassassin optimieren – Erfolgskontrolle
Seit den beiden ersten Teilen über die Optimierung von Spamassassin (unten in den related Links) ist ein wenig Zeit vergangen. Mittlerweile setze ich Spamassassin in der Version 3.25 ein, wodurch sich an meinen Setup aber nichts Grundlegendes geändert hat. Hier mal ein neues Regelwerk (Sought), da ein Plugin rausgeflogen (OCR-Plugin), mehr ist es nicht gewesen.
Für diese kontinuierliche Verbesserung ist es wichtig immer auf den Laufenden zu bleiben und dafür braucht man natürlich Helferlein, mit denen man messen kann wie erfolgreich (oder auch nicht) das eigene Setup wirklich ist. Eines davon ist sa-stats , welches ich im ersten Teil kurz angesprochen hatte. sa-stats liefert ein paar grundlegende Daten über den Email-Traffic, wieviel davon als Spam oder Ham eingestuft wurde und die Trefferquote von Regeln:
Email: 1719 Autolearn: 1553 AvgScore: 29.84 AvgScanTime: 3.75 sec Spam: 1571 Autolearn: 1505 AvgScore: 33.42 AvgScanTime: 3.74 sec Ham: 148 Autolearn: 48 AvgScore: -8.16 AvgScanTime: 3.75 sec Time Spent Running SA: 1.79 hours Time Spent Processing Spam: 1.63 hours Time Spent Processing Ham: 0.15 hours TOP SPAM RULES FIRED ---------------------------------------------------------------------- RANK RULE NAME COUNT %OFMAIL %OFSPAM %OFHAM ---------------------------------------------------------------------- 1 BAYES_99 1540 89.59 98.03 0.00 2 RAZOR2_CHECK 1351 78.77 86.00 2.03 3 RAZOR2_CF_RANGE_51_100 1342 78.07 85.42 0.00 4 URIBL_BLACK 1233 71.90 78.49 2.03 5 PYZOR_CHECK 1221 71.09 77.72 0.68 6 RAZOR2_CF_RANGE_E8_51_100 1143 66.49 72.76 0.00 7 DIGEST_MULTIPLE 1108 64.46 70.53 0.00 [..] TOP HAM RULES FIRED ---------------------------------------------------------------------- RANK RULE NAME COUNT %OFMAIL %OFSPAM %OFHAM ---------------------------------------------------------------------- 1 AWL 136 11.58 4.01 91.89 2 BAYES_00 91 5.29 0.00 61.49 3 BAYES_50 50 3.66 0.83 33.78 4 HTML_MESSAGE 39 57.88 60.85 26.35 5 SPF_HELO_FAIL 18 4.07 3.31 12.16 6 TW_GM 13 0.81 0.06 8.78 7 USER_IN_WHITELIST 11 0.64 0.00 7.43
Hier ist sehr schnell ersichtlich ob etwas falsch läuft, weil z.B. Regeln im Spam-Bereich auftauchen, welche eigentlich in den Ham-Bereich gehören. Etwas ausführlicher, was die selbst hinzugefügten Regeln angeht, ist sa-addon-stats:
Addon Rules hitting the most spam (top 20) Ruleset Rule Name % of Spam ----------------------------------------------------------- local.cf BAYES_99 93.86% local.cf RCVD_IN_BL_SPAMCOP_NET 64.41% iXhash.cf LOGINHASH 49.27% iXhash.cf LOGINHASH2 46.33% iXhash.cf IXHASH 24.57% local.cf AWL 4.95% local.cf GP_SCAM_CN 1.60% local.cf GEOCITIES1_NUM 0.52% local.cf BAYES_80 0.46% local.cf BAYES_60 0.36% local.cf GEOCITIES_NUM 0.11%
Addon Rules hitting the most ham (top 20) Ruleset Rule Name % of Ham ----------------------------------------------------------- local.cf AWL 85.89% local.cf BAYES_60 0.33% local.cf BAYES_80 0.21% local.cf BAYES_99 0.14% local.cf RCVD_IN_BL_SPAMCOP_NET 0.12% pdfinfo.cf GMD_PDF_ENCRYPTED 0.09% iXhash.cf LOGINHASH2 0.05% local.cf GEOCITIES1_NUM 0.05%
Hier lassen sich recht leicht ineffektive Regeln identifizieren. Ein wichtiger Punkt, denn Spamassassin wird durch jede nicht benutzte Regel schlanker und damit schneller. Beides Dinge worüber sich mein kleiner, gequälter Root-Server sich immer freut.
Spamassassin: Zeit für neuere Regeln
Mein Spamassassin-Setup hat sich in der letzten Zeit nicht geändert. Natürlich versuchen die Spammer immer etwas neues. Mir ist auch aufgefallen das Blacklisten immer ineffektiver werden, das der Geocities-Spam wieder zunahm und vermehrt Spam für ‘günstige’ Software immer öfters durchkam ohne erkannt zu werden.
Bei den ersten beiden gab es schnelle Abhilfe, denn Spamassassin kann sehr gut auf Inhalte reagieren, daher ist die Sache mit den Blacklisten nicht so schlimm und wird intern durch die Bayes-DB, Razor und DCC abgefangen. Besser (für die Systemlast) wäre es natürlich der Spam würde schon vor dem Annehmen abgelehnt und nicht erst durch eine resscourcen-intensive Verarbeitung in Spamassassin.
Komischerweise waren die Scores für den Software-Spam sehr niedrig – kein DNS-Blacklist, nur ein bischen Inhalts-Scores. Auf der Suche nach Abhilfe bin ich auf das Sought-Regelwerk gestoßen, das mir seitdem gute Dienste erweisst. Es ist nicht etwas fundamental Neues, sondern bringt oft die Extra-Punkte um eine Mail vom Ham- zum Spam-Status zu schubsen.
So sieht das dann bei mir aus:
horatio:# wget http://yerp.org/rules/GPG.KEY horatio:# sa-update --import GPG.KEY horatio:# echo sought.rules.yerp.org >> /etc/spamassassin/sare-sa-update-channels.txt horatio:# echo 6C6191E3 >> /etc/spamassassin/keys
Spamassassin optimieren – Plugins
Im ersten Teil habe ich ganz bewusst darauf verzichtet auf Plugins einzugehen. Sie sind für mich so ein bißchen das Salz in der Suppe mit denen man den Spamtöter um beliebige Funktionen erweitern kann.
SpamAssassin liefert ein Anzahl Plugins mit welche hauptsächlich über die Datei v310.pre ein- und ausgeschaltet werden können. Ich weiss nicht welche schon an sind, aber bei mir haben sich folgende bewährt:
- DCC – Distributed Checksum Clearinghouse. Zieht eine Checksumme über die Mail und vergleicht sie mit einer Online-Datenbank
- Pyzor – Ähnliche Funktionalität wie DCC
- Razor2 – Ähnliche Funktionalität wie DCC
- SpamCop – DNS Blacklist
- MIMEHeader – Regular Expressions auf Mime Header anwenden
- ReplaceTags – Lest selbst
Neben den offiziellen Plugins gibt es noch eine Reihe andere Plugins. Einige sind im SpamAssassin-Wiki genannt, hier ein paar zu denen ich etwas sagen kann:
- iXhash – Ähnliche Funktionalität wie DCC. Liefert sehr gute Ergebnisse
- BotNet – Versucht zu erkennen, ob der Versender einem Botnet angehört. Funktioniert gut
- ImageInfo – Ermittelt welche Art Bilder eine Mail enthält und welchen Anteil sie an der gesamten Mail haben. Funktioniert eigentlich sehr gut, kann allerdings zu False Positives führen wenn die Benutzer eine Vorliebe für Gif-Smilies haben
- PDFInfo – Module gegen PDF-Spam. Die erste PDF-Spamwelle kam bei mir durch. Mittlerweile bleiben PDF-, XLS- und DOC-Spam meist am Bayesfilter hängen. Sollte das Versagen bleibt dann noch PDFinfo und liefert gute Ergebnisse
- FuzzyOcr – Macht OCR (Texterkennung) bei Bildern in Mails. Sollte man damit Probleme haben kann man es einsetzen, ansonsten stört es nicht weiter
- P0f – P0f macht passives Fingerprinting vom Absender. Für alle die der Meinung sind, das Spam sowieso nur von Windows-Rechnern kommt. Charmante Idee, aber irgendwie bin ich von der Sinnhaftigkeit nicht sonderlich überzeugt
Spamassassin optimieren
Die Kunst beim Optimieren von Spamassassin heisst gute Planung, beobachten können und sich in Zurückhaltung üben. Man sollte zuallerst nie die Relationen aus den Augen verlieren. Wenn bei 100 Spams eine durchkommt liegt die Erkennungsrate immer noch bei 99 Prozent. Aktuell bekomme ich ca. 250 Spams am Tag. Selten wird davon eine nicht erkannt, womit ich schon im Nachkommta-Bereich bin. Auch Nutzer die aufgeregt anrufen, das eine Spam-Mail durchgekommen ist oder entsprechende Mails weiterleiten sollte man getrost ignorieren. Die Welt geht auch nicht unter, wenn eine Mail vom Bayes-System[1] vermeintlich falsch gelernt wurde. Dabei wird vergessen das es sich um eine statistische Wahrscheinlichkeit handelt und dafür braucht man die entsprechenden Wörter sowohl in der Spam, als auch in der Ham Datenbank. Ein Beispiel:
Kommt das Wort Viagra in 3000 Spam-Mails 500 mal vor und in 5 von 600, liegt die Wahrscheinlichkeit bei:
(300/5000) / (5/600 + 300/5000) = 0,98
Ausserdem macht die Bayes-Bewertung nur einen Teil des Gesamt-Score aus. Lange Rede, kurzer Sinn: Ruhe bewahren ist wichtig. Meiner Erfahrung nach bringt es ausser schlechten Erkennungsraten und False Positives nicht viel an den vorgegeben Scores herumzudrehen. Je mehr man daran rumdreht, umso mehr Arbeit macht man sich an anderer Stelle. Im Folgenden also ein paar Dinge, die man beim Betrieb von Spamassassin auf Servern beachten, tun und sein lassen sollte.
Ist das System schon in Betrieb und leidet unter schlechten Ergebnissen, sollte man zuerst feststellen welche Regeln für die Einteilung in Spam und Ham überhaupt greifen. Gute Dienste leistet hier sa-stats, welches allerdings ein Logfile des Spamd benötigt um aussagekräftige Statistiken zu erzeugen. Bei Debian wird hierzu /etc/default/spamassassin angepasst und das OPTIONS-Feld um -s /var/log/maillog erweitert. Anschließend einmal
touch /var/log/maillog
und den Spamd durchtreten nicht vergessen. Je nach Mail-Durchsatz muss man nun ein wenig warten, also Zeit logrotate einzurichten. Für die meisten sollte es reichen wöchentlich das Spamd-Logfile zu rotieren und somit einen guten Kompromiss zwischen Grösse des Logfiles und Aussagekraft der Statistik zu erreichen. So hat /etc/logrotate.d/spamassassin auszusehen:
/var/log/maillog {
weekly
missingok
rotate 12
compress
delaycompress
notifempty
create 640 root root
sharedscripts
postrotate
/etc/init.d/spamassassin reload >/dev/null
endscript
}
Sind genug Daten gesammelt heisst es sa-stats auszuführen. Dem Ergebniss sieht man sofort ein paar wichtige Informationen an wie z.B. das Verhältnis von Spam und Ham oder der generelle Durchsatz an Mail. Am intressantesten sind natürlich die Top Fired Rules für Spam und Ham, die man unter den Gesichtspunkt durchschauen sollte, das Regeln welche für die Spamerkennung da sind, wie z.B. BAYES_99 für Spam oder AWL für Ham (AWL), auf den richtigen Seiten stehen. Tun sie es nicht sollte man mit diesen Datenbanken von vorne beginnen.
Das Bayes-System
Ich persönlich arbeite mit einer generellen Bayes- und AWL-DB für alle. Eigene Datenbanken für Benutzer sind ein stetiger Quell von False-Positives, da entweder komplett falsch gelernt wird oder garnicht. Es ist einfach zu aufwendig und ineffektiv an dieser Stelle hinterherzuräumen, daher lohnt es sich nicht. Solch generelles Setup erreicht man entweder durch ein Site-Wide Setup oder weil Spamassassin von z.B. Amavis getriggert wird und sich somit im Home-Verzeichnis vom Amavis-User die Datenbanken aufbauen.
Bevor es los geht noch ein paar Worte zu den Bayes- und AWL-DBs. Zu einem ist es gut, wenn man die Funktion der AWL versteht:
The AWL is actually a very simple system. In short, the AWL is a score averaging system. It keeps track of the historical average of a sender, and pushes any subsequent mail towards that average. So if someone that never sent you mail before sends you a mail that scores 20, and then sends you a second mail that would score 2.0 without the AWL, the AWL will push the score up to 11 on the second mail. This is auto blacklisting, based on their past history of spam.
Zum anderen sollte man sich abgewöhnen an der Bayes-DB rumzudrehen. Das Autolearning funktioniert bei vernünftigen Regelsätzen besser als jeder Mensch, also Finger weg. Bei solch einen Setup lohnt es sich auch nicht alle erkannten Spams und Hams nachträglich nocheinmal manuell nachzulernen, denn sie wurden bereits durch das Auto-Learning hinzugefügt.
Arbeitet das Bayes-System garnicht liegt es mit hoher Wahrscheinlichkeit an zu wenig gelernten Spam und Ham.
amavis@rte:$ sa-learn --dump magic 0.000 0 3 0 non-token data: bayes db version 0.000 0 21852 0 non-token data: nspam 0.000 0 7754 0 non-token data: nham 0.000 0 150913 0 non-token data: ntokens 0.000 0 1184319834 0 non-token data: oldest atime 0.000 0 1187116894 0 non-token data: newest atime 0.000 0 0 0 non-token data: last journal sync atime 0.000 0 1187084641 0 non-token data: last expiry atime 0.000 0 2764800 0 non-token data: last expire atime delta 0.000 0 1991 0 non-token data: last expire reduction count
Die Werte nham und nspam stehen für die Anzahl bereits gelernter Mails. Liegen sie unter 200 ist das Bayes-System deaktiviert. Möchte man es trotzdem starten kann man dies mit bayes_min_ham_num und bayes_min_spam_num in der Spamassassin-Konfiguration beeinflussen. Auch empfiehlt es sich vor der Inbetriebnahme Gedanken über wichtige Email-Partner zu machen und diese in die Whitelist zu nehmen. Man kann sie später wieder entfernen, da die Whitlist-Scores in die AWL eingegangen ist.
Netzwerkbasierte Tests
Spamassassin basiert im Grunde aus drei Teilen: Festen Regelsätzen, die in der Mail nach bestimmten Pattern suchen, dem Bayes-System und den Netzwerk-basierten Tests wie Razor, Pyzor und (Su)RBLs. Bei Debian geht die Installation recht einfach:
apt-get install libnet-dns-perl razor pyzor dcc-client dcc-common
Man sollte darauf achten einen schnellen DNS-Server in Reichweite zu haben oder lokal einen Caching-DNS betreiben um die Antwortzeiten und damit die Durchlaufzeit einer Mail zu minimieren. Steht der Server hinter einer Firewall sind entsprechende Regeln einzupflegen, näheres hier.
Externe Regelwerke
Die mitgelieferten Regelsätze von Spamassassin sind schon recht gut, man kann sie aber noch verbessern. Aber auch hier sollte man Vorsicht walten lassen. Viele Regeln helfen nicht viel, im schlimmsten Fall machen sie Spamassassin zu einen Ram fressenden Monster. Meine Daumenregel ist dabei, das ich sie wieder lösche wenn sie nach einer Woche nicht in den Top 20 Regeln auftauchen.
Ein guter Anfang sind die Regeln vom RulesEmporium. Die kann man einfach ins Konfigurations-Verzeichnis werfen und Spamassassin durchstarten. Da sie sich aber hin und wieder ändern ist ein automatisches Update wünschenswert. Anfangs gab es RulesDuJour das aber seit dem erscheinen von sa-update nicht mehr weiterentwickelt wird.
sa-update arbeite mit sogenannten Channels, die quasi jeder zur Verfügung stellen kann. Ich nutze zum einen den Update-Channel von Spamassassin und einen von Daryl O’Shea. Zuerst muss man die GPG-Keys installieren:
wget wget http://daryl.dostech.ca/sa-update/sare/GPG.KEY gpg --import GPG.KEY sa-update --import GPG.KEY rm GPG.KEY wget http://spamassassin.apache.org/updates/GPG.KEY gpg --import GPG.KEY sa-update --import GPG.KEY
Anschließend legt man ein File an, indem die Channels hinterlegt werden:
touch /etc/spamassassin/sare-sa-update-channels.txt
Und packt folgende Daten rein, welche die externen Regelwerke repräsentieren die geladen werden sollen:
updates.spamassassin.org 70_sare_stocks.cf.sare.sa-update.dostech.net 70_sare_adult.cf.sare.sa-update.dostech.net 70_sare_spoof.cf.sare.sa-update.dostech.net 70_sare_bayes_poison_nxm.cf.sare.sa-update.dostech.net 70_sare_genlsubj_x30.cf.sare.sa-update.dostech.net 70_sare_oem.cf.sare.sa-update.dostech.net 70_sare_random.cf.sare.sa-update.dostech.net 70_sare_specific.cf.sare.sa-update.dostech.net 70_zmi_german.cf.zmi.sa-update.dostech.net 88_FVGT_Bayes_Poison.cf.sare.sa-update.dostech.net 88_FVGT_Tripwire.cf.sare.sa-update.dostech.net 88_FVGT_rawbody.cf.sare.sa-update.dostech.net 88_FVGT_subject.cf.sare.sa-update.dostech.net chickenpox.cf.sare.sa-update.dostech.net
Um beide Channels gleichzeitig updaten zu können braucht es nun noch ein Key-File
touch /etc/spamassassin/keys
indem die Keys stehen:
856AA88A 5244EC45
Nun kann man mit
sa-update -D --channelfile /etc/spamassassin/sare-sa-update-channels.txt --gpgkeyfile /etc/spamassassin/keys
die Regelsätze herunterladen und im späteren mit dem selben Befehl auf Stand halten. Vor dem Neustart von Spamassasin ist dringenden ein
spammassassin -D --lint
angesagt um Fehler im Regelwerk rechtzeitig zu erkennen.
Ausblick
Im zweiten Teil geht es um allerlei Plugins mit denen man unter Spamassassin arbeiten kann.
[1] – Kampf dem Spam
Links for 2007-06-19
- lolcode.vim – lolcode syntax und indent file für vim
- Chatting about the CDDL – Debian und die CDDL Lizenz von Sun. Vorallem Debian OpenSolaris klingt so schön
- CapFuzzy – Capping Patch für Spamassassins FuzzyOCr
- Offices of Music 2.0 – Nette Fotoreihe über die Büros von Internet-Firmen
Beide obigen via Planet Debian
Veröffentlicht in Debian, Linux, Software, Solaris, Spam | 
Schlagworte: Capping patch, CDDL, Debian, FuzzyOcr, GPL, lolcode, OpenSolaris, Spamassassin, vim | 
Kommentare geschlossen