LUGA
<<>>

Spam-Filter

2. Was ist Spam?

2.1. Etwas zum Essen :-)

  • Spiced Pork And Ham
  • Monty-Python-Sketch

2.2. Usenet

  • Excessive Multiple/Cross-Posting
  • MUDs
  • Erster Usenet-Spam 1988 "HELP ME!".
  • MAKE MONEY FAST
  • ARMM - Retro-Moderation Software hatte Bug und postete 200 Messages nach news.admin.policy. Erste Verwendung des Worts "Spam" im Usenet (1993)
  • Global Alert for All: Jesus is Coming Soon. (1994)
  • Green Card Lottery. (1994)

2.3. E-Mail

  • UBE - Unsolicited Bulk Email
  • UCE - Unsolicited Commercial Email

3. Wieso ist Spam böse?

3.1. Menge

  • Ca. 50 % aller Mails am Backbone.
  • > 100 Spams pro Tag bei manchen Usern

3.2. Schaden: "Verlorene" Mails

  • Wirklich verloren - Mailbox voll, Server überlastet
  • Übersehen, versehentlich gelöscht
  • Postmaster, Double Bounces -> /dev/null
  • False Positives bei Spam-Filtern!

4. Wie wird Spam verschickt?

4.1. Parallel

  • Über hunderte/tausende Server gleichzeitig

4.2. Häufig ohne Einverständnis der "Mittäter"

  • Offene Relays
  • Offene Proxies
  • Trojan Horses

4.3. Versteckspiel

  • Gefälschter Absender
  • Irreführende Subjects
  • Falsche Angaben zur List-Policy

5. Spam-Erkennung

5.1. Sender - Black & White-Lists

5.1.2. Lokale Konfiguration

  • (kein) Offenes Relay
  • Eigene und andere User
  • Outgoing/Incoming
  • Access-Lists am MTA

5.1.3. Problem

  • Wartungsaufwendig! Listen von tausenden Adressen müssten gepflegt werden.

5.1.4. RBLs

  • Zentrale Sammelstellen für "Böse"
  • Unterschiedliche Kriterien (Offene Relays, Spam-Quellen, Dial-Up-User, Nase passt mir nicht)
  • Man gibt Kontrolle ab!

5.2. Content-Filter

5.2.1. Idee: Ich erkenne Spam, wenn ich ihn sehe, das sollte auch ein Computer schaffen

  • Stichwörter
  • Muster (GrOSSSCHREIBUNG, !!!!!!, L.ö.c.h.e.r)
  • Content-Types (text/html)

5.2.2. Im Anfang war procmail

  • Regular Expressions
  • Gewichtungen
  • Handarbeit
  • Sammlungen von Regeln

5.2.3. SpamAssassin

  • Hunderte Tests (positive und negative!)
  • Gewichtungssystem
  • Default-Werte aus Analyse vieler Mails
  • Andere Scores, zusätzliche Regeln
  • CPU- und Memory-aufwendig
  • spamd/spamc

5.2.4. Razor

  • Spam ist was als Spam empfunden wird
  • Einzelne Mails sind Spam
  • Zentrale Mail-Datenbank
  • "Fuzzy" Hashes
  • Voting System
  • Server nicht Open Source
  • Umstritten!

5.2.5. Statistische Filter - All your Bayes are belong to us!

5.2.5.1. Thomas Bayes (1702-1761)
Portrait
  • engl. Mathematiker
  • Theory of Probability
  • berechnet Wahrscheinlichkeit einer Ursache aus Häufigkeit der Symptome
  • von Boole widerlegt und (fast) in Vergessenheit geraten
  • aber für Klassifikationen verwendet
5.2.5.2. Paul Graham: A Plan for Spam (2002)
  • verwendet Bayes'sche Logik
  • (let ((g (* 2 (or (gethash word good) 0))) (b (or (gethash word bad) 0))) (unless (&lt; (+ g b) 5) (max .01 (min .99 (float (/ (min 1 (/ b nbad)) (+ (min 1 (/ g ngood)) (min 1 (/ b nbad)))))))))
  • Spam wird immer erkennbare Merkmale haben
  • Automatische Anpassung an Spam-Trends
5.2.5.3. Lern-Methoden
  • (große) Samples
  • Lernen aus Fehlern (interaktiv)
  • Automatisches Lernen

5.3. Am Verhalten des Senders

5.3.1. Spammer sind atypische Mail-Sender

  • Open Proxies sind für HTTP, nicht SMTP - Protokollfehler.
  • Spammer wollen schnell viel Mail versenden, nicht zuverlässig! Keine Queues, falsche Reaktion auf Fehler.
  • »Trojanisierte« Hosts nicht als Mailserver konfiguriert - erkennbare Konfigurationsfehler (DNS-Config, HELO, ...)
  • Historie

6. Policy

6.1. Zentral vs. Dezentral

6.1.1. Zentrale Verwaltung

  • Insgesamt weniger Arbeit
  • Sehr viel weniger Arbeit für den einzelnen
  • Besserer Überblick

6.1.2. Dezentrale Verwaltung

  • Spam ist subjektiv
  • Kein Single Point of Failure
  • Accountability

6.2. Wo filtern?

6.2.1. Im User Agent

  • Interaktives Feedback vom Benutzer
  • freie Wahl der Software
  • Benutzer bekommt trotzdem den Spam
  • langsam
  • (normalerweise) keine Bounces

6.2.2. Im Delivery Agent

  • Feedback schwieriger
  • relativ flexibel für Benutzer
  • Verarbeitung im Hintergrund
  • (normalerweise) keine Bounces

6.2.3. Im Transfer Agent

  • Feedback noch schwieriger
  • unflexibel für Benutzer
  • Verarbeitung im Hintergrund
  • Mail wird gar nicht erst angenommen
  • Mehr Information über Sender
  • Benutzer bemerkt false positives nicht!
  • Mail bounct (aber beim Sender!)

7. Toolbox

7.1. qpsmtpd

7.1.1. Blurb

  • Drop-in replacement for qmail-smtpd
  • Can support other "queing backends" than qmail-queue via the plugin system
  • Advanced but simple to use plugin system to easily install extra functionality and write local rules.
  • Advanced anti spam features, can be enabled or disabled per local address
  • Can be configured to know about local addresses and bounce invalid addresses at the smtp level.

7.1.2. Erfahrungen

  • Plugins wirklich einfach zu schreiben (wenn man Perl kann)
    • aliases (+ per-user options)
    • queue/postix
  • Qualität der vorhandenen Plugins variiert
  • Extrem verboses Logging (wenn gewünscht).
  • Performance ist für kleine Sites brauchbar. (für große: PPerl o.ä., persistenter Daemon ist in Entwicklung)
  • 7.2. SpamAssassin

    • Hunderte Tests (positive und negative!)
    • Gewichtungssystem
    • Default-Werte aus Analyse vieler Mails
    • Andere Scores, zusätzliche Regeln
    • CPU- und Memory-aufwendig
    • spamd/spamc

    7.3. Greylisting

    7.3.1. Beobachtungen

    • SMTP unterscheidet temporäre von permanenten Fehlern.
    • "Richtige" Mailserver legen bei temporären Fehlern Mail in Queue und versuchen es in regelmäßigen Abständen (einige Minuten bis einige Stunden) wieder.
    • Spamware verwirft die Mail.
    • "Normale" Mails zwischen zwei Personen haben immer den gleichen Absender, Empfänger und laufen über eine kleine Menge an Servern.
    • Spam-Mails haben häufig zufällige Absender und kommen von vielen Sendern.

    7.3.2. Idee

    • Tripel (Absender-Email-Adresse, Sender-IP-Adresse, Empfänger-Email-Adresse)
    • Ist Tripel unbekannt: temporärer Fehler und Eintrag in die "greylist".
    • Ist Tripel in der Greylist und seit dem Eintrag eine bestimmtes Zeitintervall (default 1-3 Stunden) vergangen: Mail annehmen und Eintrag in die "whitelist" (für 36 Tage).
    • Ist Tripel in der Whitelist: Mail annehmen, und Ablaufdatum der Whitelist verlängern.
    • Abgelaufene Einträge werden wie unbekannte behandelt.

    7.3.3. Probleme

    • Welches Greylisting-Intervall? Was sind übliche Queuing-Intervalle? ([15 Minuten ... 9 Stunden] scheint brauchbarer Kompromiss zu sein)
    • Wechselnde Absender-Adressen (VERP), insbesondere bei Mailinglisten. Teilweise pro Zustellversuch!
    • Wechselnde IP-Adressen bei Mail-Server-Farmen (Chello, Yahoo)
    • Kaputte Mailer: Keine Unterscheidung zwischen temporären und permanenten Fehlern, keine Queue-Runs, falsche Fehlermeldungen, etc.
    • -> Whitelisting
    • -> Optional

    8. Fallbeispiele

    8.1. Fallbeispiele: hjp.at

    8.1.1. Anforderungen

    • 1-Benutzer-System
    • always-online, statische IP
    • User verwendet Usenet und Mailinglisten (d.h., viel Spam, aber ich erwarte Mails von Unbekannten)
    • RFC-Faschist
    • qmail (bounct!)

    8.1.2. Mail-Kategorisierung

  • Verschiedene Mail-Adressen für Mailinglisten, Usenet, ...
  • procmail, .qmail, Mail::Audit
  • Razor, SpamAsssassin, Mail::Filter::Bayesian
  • 8.1.3. Mail-Reject

    • qpsmtpd
    • Blackhole-Listen
    • Spamassassin (qpmtpd-Plugin + spamd) Reject, wenn Score > 5. Custom-Rules (Virenwarnungen)
    • "klez"-Filter

    8.1.4. Resultat

    • Nur eine Handvoll Spams pro Tag wird angenommen
    • und meistens "richtig" einsortiert
    • Blackhole-Listen liefern gelegentlich false positives (und werden dann meist entsorgt)

    8.2. Fallbeispiele: luga.at

    8.2.1. Anforderungen

    • Keine Enduser (nur Admins)
    • Mailinglists

    8.2.2. Mail-Kategorisierung

  • Implizit durch Mailinglists
  • Öffentliche Listen: Nur Subscriber dürfen senden
  • Geschlossene Listen/Aliases (office, ...): Alle dürfen senden :-(
  • Die öffentlichen Listen waren durch die »Nur Subscriber dürfen senden«-Regel ausreichend geschützt. Nur selten hat es ein Spammer geschafft, mit einer subscribierten Adresse auf die Liste zu posten.

    Insbesondere office wurde aber ziemlich mit Spam belastet - beim normalen Lesen eher ein geringes Problem (Spamassassin am eigenen Rechner filtert genauso zuverlässig, ob die Mail an mich direkt oder über office geschickt wurde) aber die Mailinglist-Archive wurden ziemlich unübersichtlich.

    8.2.3. Und dann kam Sobig

    Und ich sah, dass die Welt schlecht war

    • Mein MTA hat das Zeug rejected (Klez-Filter)
    • Günthers Mailbox war voll
    • -> viele Bounces.
    • + Virenwarnungen
    • = Handlungsbedarf

    8.2.4. Mail-Reject

    • Blackhole-Listen
    • qpsmtpd
    • Spamassassin (qpmtpd-Plugin + spamd)
    • greylisting
    • earlytalker
    • SMTP-Forward-Modul (-> sendmail)

    8.2.5. Resultat

    Anmerkung: In der Graphik fehlen die Mails, die sendmail an Hand des Content-Types filtert.

    • Deutliche Verringerung das Spam-Aufkommens (office-Liste: 80% (137/166) im Juli, 15% (12/91) im Oktober).
    • Nach "Einschleifphase" problemlos.

    8.3. wsr.ac.at

    • Kleines Rechenzentrum, Provider für 4 Institute
    • ca. 200 Enduser
    • Unterschiedliche Anforderungen der User
    • geringes technisches Verständnis der User

    8.3.1. Maßnahmen

    • SpamAssassin im MDA (nur Markieren, Filtern können die User im MUA)
    • SpamAssassin-Rules werden von uns gepflegt (AFAIK tut das kein User selbst)
    • qpsmtpd (+ standard-checks (resolvable_from, etc.))
    • Optional greylisting

    8.3.2. Resultat

    • Wahlmöglichkeit für User ist wichtig!
    • Ca. 50% der User verwenden Greylisting.
    • Gelegentlich verspätet oder gar nicht zugestellte Mails.
    Spam-Filter
    Was ist Spam?
    Etwas zum Essen :-)
    Usenet
    E-Mail
    Wieso ist Spam böse?
    Menge
    Schaden: "Verlorene" Mails
    Wie wird Spam verschickt?
    Parallel
    Häufig ohne Einverständnis der "Mittäter"
    Versteckspiel
    Spam-Erkennung
    Sender - Black & White-Lists
    Kategorisierung der Sender in Gute und Böse
    Lokale Konfiguration
    Problem
    RBLs
    Content-Filter
    Idee: Ich erkenne Spam, wenn ich ihn sehe, das sollte auch ein Computer schaffen
    Im Anfang war procmail
    SpamAssassin
    Razor
    Statistische Filter - All your Bayes are belong to us!
    Thomas Bayes (1702-1761)
    Paul Graham: A Plan for Spam (2002)
    Lern-Methoden
    Am Verhalten des Senders
    Spammer sind atypische Mail-Sender
    Policy
    Zentral vs. Dezentral
    Zentrale Verwaltung
    Dezentrale Verwaltung
    Wo filtern?
    Im User Agent
    Im Delivery Agent
    Im Transfer Agent
    Toolbox
    qpsmtpd
    Blurb
    Erfahrungen
    SpamAssassin
    Greylisting
    Beobachtungen
    Idee
    Probleme
    Fallbeispiele
    Fallbeispiele: hjp.at
    Anforderungen
    Mail-Kategorisierung
    Mail-Reject
    Resultat
    Fallbeispiele: luga.at
    Anforderungen
    Mail-Kategorisierung
    Und dann kam Sobig
    Mail-Reject
    Resultat
    wsr.ac.at
    Maßnahmen
    Resultat

    Peter J. Holzer,,, <hjp@wsr.ac.at>, 2007-5-26