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