Projekt Spamabwehr http://spam.ani.univie.ac.at/

Projekt Spamabwehr http://spam.ani.univie.ac.at/ Status und Ausblick W. Gansterer, M. Ilger, A. Janecek, P. Lechner, J. Strauß Institut für Distributed und Multimedia Systems / Research Lab Computational Technologies und Applications Universität Wien

Ermöglicht durch

Überblick Motivation (Was / Warum / ) Eigenschaften von Spam Das zugrundeliegende Geschäftsmodell Methoden gegen Spam Eigene Entwicklungen Schlußfolgerungen und Ausblick

(I) Motivation Schätzungen des Spamaufkommens (international) Message Labs: Spamanteil 65% (Jänner 2006) Brighmail: 2004: 60%, 2003: 56%, 2002: 40% Sophos: >60% von Zombies (2005) Postini: >150 Millionen Spamnachrichten pro Tag (2006) Spamquellen Sophos: dirty dozen (2005) country of origin of computers sending spam 1. USA 26,8% - 2. Südkorea 18,4% - 3. Volksrep. China 17,0% 11. Österreich 0,9% [www.messagelabs.com, Sophos Report 2005, www.postini.com, spam-filter-review.topten-reviews.com/spam-statistics.html]

Schaden durch Spam Spam verursacht Kosten Filterungsmechanismen, Arbeitszeit Opportunitätskosten durch falsch klassifizierte Nachrichten Studie an der Christian-Albrechts-Universität (Kiel) [M. Clement, H.-J. Boie: Die Kosten von Spam, 2006] 8000 Mitarbeiter Im Schnitt 24 e-mails pro Tag, 45% davon Spam Verursachen Kosten von durchschnittlich 780 pro Mitarbeiter/Jahr Schätzung laut OECD-Report $ 874 pro Mitarbeiter/Jahr

Schaden durch Spam Outblaze limited, Webmail Provider in Hong Kong [OECD Report: Spam Issues in Developing Countries, 2005] 80% der eintreffenden E-mail als Spam abgewiesen 15% der akzeptierten E-mail ist Spam (passiert den Filter) monatl. Bandbreitekosten für Spam: US$ 6 300,- monatl. Speicherkosten für Spam: US$ 5 400,- monatl. Personalkosten für mail/abuse administrators : US$ 75 000,- Weiters: Kosten für Support von unzufriedenen Benutzern

Transfer der Kosten Spammer haben extrem niedrige Kosten Verursachen jedoch weit größere Kosten bei ISP, Unternehmen, einzelnem Nutzer (Speicher, download, etc.) Umkehr des Systems traditioneller Marketingmethoden sender pays -Modell Kosten für Empfänger vernachlässigbar [OECD Report: Spam Issues in Developing Countries, 2005]

Zielsetzungen - global Das Ziel jeder Antispam-Policy sowie begleitender legislativer Maßnahmen ist es, den Anteil von Spam im E-mail-Verkehr und dessen negative Auswirkungen zu reduzieren. Aktivitäten müssen auf drei Ebenen erfolgen: Maßnahmen, die das Aussenden von Spam verhindern. Mechanismen, die die Menge an Spam im Netzwerk reduziert (nachdem Spam abgeschickt wurde). Maßnahmen, die die Menge an Spam reduziert, die empfangen wird (z.b. beim Enduser). [OECD Report: Anti-Spam Regulation, 2005]

(II) Eigenschaften von Spam Formale inhaltliche Spielen eine wesentliche Rolle für den Erfolg von Abwehrmethoden Basis für die Entwicklung neuer, innovativer Konzepte Statistische Analyse von Spamdaten Datenquellen: ZID der Uni Wien, Projektpartner, Freiwillige Ziel: Zeitraum 1 Jahr (fast 1,5 Mio Spamnachrichten) Erste Zwischenergebnisse eines entsprechenden Tools für die statistische Analyse von Spamdaten liegen vor

Statistiken Sprache

Statistiken Top Level Domains Top Level Domains (Spam) 255741; 26% 1012; 0% 33834; 3% 38763; 4% 171466; 17% 501680; 50% com net de at ungültig sonstige (vorgegeben)

(III) Geschäftsmodell Genaue Analyse des Geschäftsmodells als Grundlage für effiziente Gegenmaßnahmen Schaden verhindern, bevor er entsteht (im Gegensatz zu vielen Standardansätzen) Entwicklung eines Tools SpamSim für die Analyse dieses Geschäftsmodells Resultate bilden die Basis für die Parametrisierung von pre-send -Methoden ( Token Bucket )

Spammer Szenario 1 Spammer versendet Spam über Einzelplatzrechner Fixkosten Hardware, Software (inklusive spezieller Spamsoftware) Arbeitskosten, Betriebskosten Variable Kosten Open proxy (um Identität zu verschleiern) Erlös Bezahlung per Kampagne : Durchschnitt über diverse Spammerberichte pro Nachricht ca. 0,00434 Euro Gegenmaßnahme 1: Token Bucket für die Beschränkung ausgehender Nachrichten Gewinn erst über 8400 Spams/Tag

Einsatz eines Token Bucket Token Bucket Spammen profitabel Spammen nicht profitabel Gesendete Nachrichten 50 1000 8400 Normales E-Mail Aufkommen 5 10 15 20 25 Tage

Spammer Szenario 2 Spammer versendet Spam mit handelsüblichem PC über gemieteten Server Kosten Zusätzlich: Servermiete Keine Kosten für open proxy Erlös Bezahlung per Kampagne : Durchschnitt über diverse Spammerberichte pro Nachricht ca. 0,00434 Euro Gegenmaßnahme: Spamfilter Gewinn nur dann, wenn Filterperformance unter 98,45%

Filtereinsatz Gewinn Spammer abhängig von Filterperformance 35000 30000 25000 Gewinn/Monat 20000 15000 10000 5000 0-5000 75 77,5 80 82,5 85 87,5 90 92,5 95 97,5 100 Filtereffektivität in % Gewinn

Spammer Szenario 3 Spammer versendet Spam über Einzelplatzrechner Fixkosten Hardware, Software (inklusive spezieller Spamsoftware) Arbeitskosten, Betriebskosten Variable Kosten Open proxy (um Identität zu verschleiern) Erlös Bezahlung pro verkauftem Stück (auf Provisionsbasis) Restriktion: Antwortrate Gewinn bei Antwortraten über 0,002% Quellenangaben: Antwortraten bei Spam 0,0015% 0,005% [vgl. 0,36% bis 2% Antwortrate bei seriöser Werbung]

Auswirkung der Antwortrate Gewinn Spammer abhängig von Antwortrate Gewinn in Euro 1800000 1600000 1400000 Gewinn / Euro 1200000 1000000 800000 600000 400000 200000 0-200000 1 0,5 0,25 0,125 0,0625 0,036 0,03125 0,015625 0,0015 0,001 Response Rate in %

Screenshot SpamSim

(IV) Methoden gegen Spam Post-send Pre-send Neue Protokolle

Zielsetzungen Umfassend, flexibel Selbstadaptiv, automatisch, intelligent Robust, einfach zu handhaben Wirksam bevor Schaden eintritt

Evaluierungen Leistungsevaluierungen verschiedener Methoden verschiedener Tools (kommerziell, public domain) Speziell: Mozilla Thunderbird Trainingssensitivität des Bayes Filters SpamAssassin Regelset

(V) Neue Methoden Token Buckets gegen outgoing Spam Prototyp für Spamabwehr

Token Buckets Verhinderung von outgoing Spam Veröffentlicht auf The IASTED International Conference on COMMUNICATION, NETWORK AND INFORMATION SECURITY (CNIS) 2005 (USA), November 2005. Pre-send Methode: Für outgoing Mailserver, flexibles Limit für outgoing Nachrichten (z.b. pro User) Bei richtiger Parametrisierung wird Geschäftsmodell des Spammers gestört ohne reguläre User zu beeinträchtigen Vorteile: Selbstschutz für ISP Selektive Maßnahme gegen Spammer Problematik der Fehlklassifizierung nicht existent Bei breitem Einsatz: deutliche Reduktion des Spamvolumens möglich

Prototyp 3 Komponenten: Greylisting Merkmalsselektion Klassifikation Vorteile Ressourcenschonend (Klassifizierung bevor Nachricht endültig akzeptiert) Nachrichtenannahme und Klassifizierung asynchron möglich (daher arbeitsintensive Klassifikationsmethoden anwendbar) Skalierbarkeit, Robustheit gegenüber Hochlast

Struktur des Prototyps Data Storage

Ergebnisse Prototyp - Greylisting Zeitraum: 27.01.06 03.04.06 Live Spam-Stream, insgesamt 921 Nachrichten Ergebnisse: kein Virus (clamav) Im Live-Stream richtig klassifiziert: 97% bei Schwellenwert 0.35 91% bei Schwellenwert 0.5 Gesamt daher: 99,89% der Spams abgewiesen (greylisting + Klassifizierung) Greylisted Greylisted wegen Timestamp ungültig Abgelehnt aufgrund Klassifikation Angenommen 833 [90.45%] 85 [9.23%] 2 [0.22%] 1 [0.11%]

Erkennungsraten SpamAssassin

Erkennungsraten Prototyp

(VI) Zusammenfassung Spam ist weiterhin ein schwerwiegendes Problem Es sind noch keine umfassenden und völlig zufriedenstellenden Lösungen vorhanden Standardtechnologie funktioniert im großen und ganzen nicht schlecht, schafft es aber nicht, den Schaden einzugrenzen bzw. zu verhindern Viele praktisch verfügbare Methoden haben entweder ad hoc Charakter oder benötigen hohen Trainingsaufwand, um zufriedenstellende Leistung zu erreichen Weitere Forschung und Entwicklung ist erforderlich, um adaptive, intelligente Systeme zu entwickeln, die eine Reduktion des durch Spam bewirkten Schadens ermöglicht.

Ausblick (1) Derzeitiges Projekt endet am 30.April 2006. Darüber hinaus sind wir an weiteren Kooperationen/Projekten interessiert. Weiterführende Themen: Phishing Unterscheidung von lästigem und gefährlichem Spam Selbstadaptive Anpassung von Trainingssets Reduktion des Aufwandes für die Wartung (Performance!) Neue Ansätze zur Selektion von Merkmalen Längerfristige Entwicklungen der Merkmale von Spam, um mehr invariante Merkmale zu identifizieren

Ausblick (2) Weiterführende Themen: Light-weight Ansätze für Endgeräte (PDA, Handy, etc.) Geringere Kapazität von Endgeräten Damit im ZH: verteilte Konzepte Optimierung klassischer Filterkonzepte Reduktion der false positives

Kontakt, Publikationen: http://spam.ani.univie.ac.at/ Vielen Dank für Ihre Aufmerksamkeit!

Weitere Folien

Kurzfassungen (MI) Welcher Schaden durch Spam (MI) Welcher Umfang von Spam (wieviel ist Spam) (JS) 2 konkrete Szenarien SpamSim (JS) Screenshots Daberger-Statistiken Bründl Graphiken Report II-1: Was daraus sollte/könnte im Vortrag vorkommen?

Statistiken Ankunftszeit Spam nach Wochentagen Anzahl 180000 160000 140000 120000 100000 80000 60000 40000 20000 0 MO DI MI DO FR SA SO Tag

Statistiken Mail-Client sendender Mail-Client (Spam) Microsoft Outlook Express 100.782; 22% Microsoft Outlook 47.008; 10% 10.437; 2% 17.485; 4% 33.249; 7% 30.976; 7% 209.185; 48% The Bat! Apple Mail IPB PHP Mailer Sonstige über 1000 E-Mails Sonstige bis 1000 E-Mails

Statistiken Mail-Client sendender Mail-Client (Ham) Microsoft Outlook 716; 24% 155; 5% 167; 5% 1.009; 34% Microsoft Outlook Express WWW-Mail 1.6 (Global Message Exchange) Pegasus Mail 196; 6% 800; 26% Mailbox Webmail Sonstige

Response Rate (0,0025%)

Modeling Spammers Business Model Cost - Profit Model Spammer 10000000 1000000 revenue without token bucket (only limited by bandwidth) Cost/Revenue in Euro 100000 10000 1000 100 10 actual cost opportunity cost (8% interest) revenue token bucket (100 msg per day) revenue token bucket (1000 msg per day) 1 1 2 3 4 5 6 7 8 9 10 11 12 Month

Trainingssensitivität Mozilla Thunderbird

Prototyp 1 Return 354 Accept DATA Sender whitelisted? No Yes Return 250 Deliver Message 3 No QTupel in TupelDB? No Sender blacklisted? 2 Yes Return 550 Save QTupel -> Timestamp Yes TimeStamp OK? 6 No Message too late? Yes Yes Return 450 Increase Reliability Counter Delete QTupel 4 5 No Message is Spam? Yes Delete QTupel Increase Suspicious Counter Ùpdate Qtupel -> TimeStamp No Classify Message Return 250 Return 550 Return 450 Update SpamDB Deliver Message

Gegenüberstellung Vergleich der Spam-Erkennungsraten bei unterschiedlichen false positives Raten false postitives 0.05% 0.10% 0.15% 0.20% SpamAssassin 72.19% 73.73% 76.25% 82.12% Prototyp (VSM) 85.90% 87.49% 91.52% 92.45%

Nur Prototyp

Zukunftspläne (1/2) Detailanalyse des Spamaufkommens Langfristige Entwicklung der Eigenschaften von Spam Fluktuationen in der Gesamtmenge Änderung in Versendemethoden Lifecycle von Spamtraps Dauer zwischen Veröffentlichung und erstem Eintreffen von Spam Reaktion auf verschiedene Arten der Veröffentlichung Grad der Individualisierung der Nachrichten

Zukunftspläne (2/2) Optimierung klassischer Filterkonzepte Fehlklassifizierung von legitimen Nachrichten minimieren Evaluierung kostenbasierter Ansätze Finding the right mix Richtige Mischung aus Spamfiltern Outgoing limitations

Weitere Zukunftspläne Analyse von Spam Traps Evt. laufende Bewertung State-of-the-art