Spam - die Zukunft ist grau!

Status Quo: Anti-Spam-Maßnahmen an der TU Chemnitz

• Mail-Relays: zwei Linux-Server, über die alle externen E-Mails der TU Chemnitz laufen
• Keine externen MX
• -> einheitliche Spamschutz-Policy an wenigen definierten Stellen

Status Quo: Anti-Spam-Maßnahmen (2)

Status Quo: Statistiken der Anti-Spam-Maßnahmen

Status Quo: Spam-Plage schlimmer denn je :-(

• Menge an Spams, Mail-Würmer, "Viren-Warnungen"
• Genervte Mail-Benutzer, panische Mail-Admins, überlastete Infrastruktur
• Starke Akzeptanzverluste, Unerreichbarkeit, Abschaltung
• Spammer passen sich an: Check gegen SpamAssassin, "Futter" für Filter ... "Arms race" :-(

• Juristisch: Gesetzeslage uneinheitlich, verworren
• Technisch/administrativ:
  • war sehr lange kein Thema bei IETF, ISOC ... :-(
  • Mailadmins mit (Not-) Lösungen
  • Mail-Server-Konfiguration komplexer, fehleranfälliger, z.B. Exim-ACLs
• Mail-Benutzer: "Bayes-Filter": Verbreitung, Bedienbarkeit, Robustheit, Wirksamkeit?

Immer gut: Wachsamer Administrator

HELO 134.109.132.58
HELO hrz.tu-chemnitz.de -> abweisen

seit 2004-03-22 via Spamschutz Administrator

Weitere Maßnahmen

• SpamAssassin mit Bayes?
• SpamAssassin mit Online-Spam-DBs (DCC, Razor)?
• Neue DNSBL-Listen: sbl-xbl.spamhaus.org seit 2004-05-03

• Call back bei Annahme einer E-Mail?
• Prävention: Schutz von E-Mail-Adressen:
  • Gegen Spambots: Keine Mailadressen direkt auf WWW-Seiten - Verschleierung:
    Meine Mailadresse
  • "Wegwerf-Mailadressen"?: frank.richter-0815@hrz.tu-chemnitz.de
  • Spamfallen: WWW-Seiten mit automatisch kodierten Mailadressen IP-Adresse+Zeit@trap.tu-chemnitz.de

Standardisierungsbemühungen: LMAP

Lightweight MTA Authentication Protocol ... Überprüfung der Absende-Adresse

• Domain-Inhaber publizieren im DNS Informationen, von welchen IP-Adressen Mails mit deren Absende-Domains versendet werden dürfen.
• Empfänger prüft, ob Domain der Absende-Adresse von erlaubter IP-Adresse gesendet wird
• Verschiede Vorschläge: RMX, DMP, SPF

• hrz.tu-chemnitz.de. IN TXT "v=spf1 mx"
• bisher über 13.000 Domains, u.a. aol.com, amazon.com, gmx.net, w3.org
• Schutz der Envelope Sender-Adresse

• _ep.hrz.tu-chemnitz.de. IN TXT "<ep xmlns= http://ms.net/1 ><out><m> <mx/> </m></out></ep>"
• z.B. hotmail.com, microsoft.com
• Schutz der Absender-Mail-Header - gegen address phishing

SPF + Caller-ID = Sender ID

• Forward - Sender Rewriting Scheme (SRS)
• Mobile Nutzer - SMTP AUTH, Port 25 via Firewall?
  -> Port 587: Message Submission Agent (MSA, RFC 2476)
• Mailing Listen

Greylisting

Evan Harris: The Next Step in the Spam Control War: Greylisting

• Spammer wollen schnell und unerkannt E-Mails an viele Empfänger senden.
• Es gibt eine funktionierende "Blacklist-Infrastruktur", die mit gewisser Verzögerung auf Spam-Vorfälle reagiert.
• Wie reagieren andere Systeme in Überlastsituationen?

• IP-Adresse des Senders, Absende-Adresse, Empfängeradresse = Tripel -> mit Zeitstempel speichern

• Wenn Tripel unbekannt: Annahme für eine Weile mit temporärem Fehler abweisen.

Verbindung von IP 1.2.3.4
-> MAIL FROM: <sender@somedomain.com>
<- 250 2.1.0 Sender ok
-> RCPT TO: <recipient@otherdomain.com>
  Prüfen: Kennen wir das Tripel (1.2.3.4, sender@somedomain.com, recipient@otherdomain.com) schon? 
          Ist initiale Wartezeit abgelaufen?
     NEIN:
<- 451 4.7.1 Please try again later
  ... und tschüss!
     JA:
<- 250 2.1.5 Recipient ok
-> DATA
<- 354 Enter mail
-> ...
<- 250 2.0.0 Message accepted for delivery
  Tripel mit langer Gültigkeit versehen

Greylisting (2)

• Reguläre Sende-MTAs werden Mail in Queue stellen und später versuchen -> verzögerte Zustellung
• Spam- (und Viren-) Sender haben i.a keine Queue-Verwaltung -> Zustellung wird nicht wieder versucht.

• Greylisting wirkt im SMTP vor Annahme einer E-Mail:
  • E-Mail wird noch gar nicht übertragen
  • Greylisting muss durch Betreiber vom MTA installiert werden.
• Transparent zum Benutzer, keine Einflussnahme in Mail-Programm

Greylisting: Einführung

• 1.356.445 Tripel, davon 1.293.573 Tripel, über die nur eine Mail kam

• von Alun Jones, University of Wales, Aberystwyth
• zusätzlicher Daemon, macht DB-Arbeit (MySQL)
• Exim Recipient ACL:
  • fragt Daemon via Unix-Socket:
    -> Tripel
    <- Verzögerung in Sekunden
  • Bei techn. Problem: Timeout -> Annahme der Mail
• Mitlernendes System: Viele Tripel über eine IP-Adresse -> gesamte IP-Adresse wird frei geschaltet.

• Eine Datenbank für beide Mail-Relays: Unbedingt nötig, aber single point of failure
• "Trockentest":
  • Abfrage der Tripel - Füllen der Datenbank, aber trotzdem Annahme - Logging
  • Abschätzung der benötigten Ressourcen: Datenmenge, Last
  • Abschätzung der "Wirksamkeit" schwierig
  • "gefüllte Datenbank" -> "Verschmutzung", da auch Tripel der Spams -> weiche Einführung

• 2004-04-29 für alle mit Spamschutz Administrator

Greylisting: Erfahrungen

• Deutliche Verringerung des Spam-Aufkommens
• Gewisse Irritationen der Benutzer: "So wenig Mails?"
• Anfängliche Verzögerungen bei "guten Mails" -> entschärft sich durch automatisches Whitelisting
• Greylisting wirkt auch gegen Mail-Würmer!

• Untaugliche MTAs: Kein erneutes Senden nach temporärem Fehler, z.B *.grp.scd.yahoo.com oder zu schnelle Wiederholung
  -> manuelle Whitelist
• Initiale Wartezeit zu lang für zeitkritische Anwendungen
  -> wenige Benutzer: Spamschutz abschalten oder manuelle Whitelist

Greylisting: Erfahrungen (2)

Die Beschwerden der Benutzer gehen enorm zurück - der Mail-Admin atmet auf!

Greylisting ist toll!

• Weitergeleitete E-Mails: via GMX/Web.de/... zu uns: Greylisting wirkt nicht
• Gewisse "Verschmutzung" der Greylisting-Datenbasis: Einträge der automatischen Whitelist gegen strengere DNSBL (bl.spamcop.net) testen und ggf. löschen.
• Spammerfreundliche Provider
• Neue Spam-Attacken erwartet: Infizierte PCs senden massenweise E-Mails nicht mehr selbst direkt, sondern über Provider-Server

Kombination der Spamschutz-Maßnahmen

Der Mix aus verschiedenen Maßnahmen bringt es.

• statische Blacklists und triviale Tests (z.B. existiert Empfängeradresse?)
• DNSBL
• Greylisting
• Textanalyse, Virencheck