Archiv

Artikel Tagged ‘Spamassassin’

Spamassassin optimieren – Jahre später

27. Dezember 2011 Kommentare ausgeschaltet

Ich bin gerade dabei ein paar alte Zöpfe abzuschneiden, dazu gehört für mich auch mein Spamfilter-Setup zu entrümpeln. Durch neuere Spamassassin-Versionen haben sich viele Konfigurationen überlebt, werden nicht weitergeführt bzw. sind in Spammassassin aufgegangen wie z.B. das Rules Emporium – SARE.

Ganz besonders die externen Regelwerke sind doch deutlich geschrumpft und somit auch die Konfiguration von /etc/spamassassin/sare-sa-update-channels.txt

updates.spamassassin.org
khop-bl.sa.khopesh.com
khop-blessed.sa.khopesh.com
khop-dynamic.sa.khopesh.com
khop-general.sa.khopesh.com
khop-sc-neighbors.sa.khopesh.com
sought.rules.yerp.org

Die khop-Kanäle stammen übrigens von Adam Katz, der auch noch andere sinnvolle Tipps hat.

Die benötigten Keys zur Validierung in /etc/spamassassin/sa-update-keys.txt

856AA88A
6C6191E3
E8B493D6

und deren Installation:

wget -qO - http://khopesh.com/sa/GPG.KEY http://yerp.org/rules/GPG.KEY \
http://daryl.dostech.ca/sa-update/sare/GPG.KEY |sudo sa-update --import -

Der Aufruf für das Update sieht dann so aus:

/usr/bin/sa-update -D --channelfile /etc/spamassassin/sare-sa-update-channels.txt --gpgkeyfile /etc/spamassassin/sa-update-keys.txt

Das war es eigentlich auch schon. Ein paar Punkte bringen dann noch DNSBLs wie ixHash und/oder inps und das deutschsprachige Regelwerk ZMI_german. Leider gibt es hierfür zur Zeit kein automatisches Update mehr, der Autor möchte aber anscheinend einen eigenen Update-Channel einrichten.

Barracuda DSBL für SpamAssassin

11. November 2008 2 Kommentare

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.

Tags: ,

Spamassassin optimieren – Erfolgskontrolle

15. Juli 2008 Kommentare ausgeschaltet

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.

Tags:

Spamassassin: Zeit für neuere Regeln

16. März 2008 11 Kommentare

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

19. August 2007 Kommentare ausgeschaltet

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
  • P0fP0f 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

14. August 2007 8 Kommentare

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

19. Juni 2007 Kommentare ausgeschaltet

Beide obigen via Planet Debian