Spam [Spam] - Lehrstuhl für Netz- und Datensicherheit

Transcription

Spam
[Spam]
Autoren:
Dr. Christopher Wolf
Sebastian Uellenbeck
Ruhr-Universität Bochum
Modul
Spam
[Spam]
Studienbrief 1: Grundlagen
Studienbrief 2: Spam-Techniken
Studienbrief 3: Anti-Spam-Techniken
Autoren:
Dr. Christopher Wolf
Sebastian Uellenbeck
1. Auflage
Ruhr-Universität Bochum
© 2015 Ruhr-Universität Bochum
Universitätsstraße 150
44801 Bochum
1. Auflage (11. Dezember 2015)
Didaktische und redaktionelle Bearbeitung:
Bärbel Wolf-Gellatly
Das Werk einschließlich seiner Teile ist urheberrechtlich geschützt. Jede Verwendung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne
Zustimmung der Verfasser unzulässig und strafbar. Das gilt insbesondere
für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Um die Lesbarkeit zu vereinfachen, wird auf die zusätzliche Formulierung
der weiblichen Form bei Personenbezeichnungen verzichtet. Wir weisen deshalb darauf hin, dass die Verwendung der männlichen Form explizit als
geschlechtsunabhängig verstanden werden soll.
Das diesem Bericht zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung, und Forschung unter dem Förderkennzeichen
16OH12026 gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt beim Autor.
Inhaltsverzeichnis
Seite 3
Inhaltsverzeichnis
Einleitung zu den Studienbriefen
I.
Abkürzungen der Randsymbole und Farbkodierungen . . . . . . . . .
II.
Zu den Autoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III.
Modullehrziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Studienbrief 1 Grundlagen
1.1 Lernergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Advanced Organizer . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2 Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.3 RFC (Request for Comments) . . . . . . . . . . . . . . . . . .
1.3.4 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.5 Kontrollaufgaben . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 E-Mail-Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.1 Kommunikationsmodell . . . . . . . . . . . . . . . . . . . . .
1.5.2 Aufbau von E-Mails . . . . . . . . . . . . . . . . . . . . . . .
1.5.3 SMTP (Simple Mail Transfer Protocol) . . . . . . . . . . . . . .
1.5.4 POP3 (Post Office Protocol Version 3) . . . . . . . . . . . . . .
1.5.5 IMAP (Internet Message Access Protocol) . . . . . . . . . . . .
1.5.6 DNS (Domain Name System) . . . . . . . . . . . . . . . . . .
1.6 Anreize und Motivation der Spammer . . . . . . . . . . . . . . . . . .
1.7 Wirtschaftliche Aspekte . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1 Durch Spam entstehende Kosten . . . . . . . . . . . . . . . .
1.7.2 Erlös für Spam-Verursacher . . . . . . . . . . . . . . . . . . .
1.8 Fallstudie „Click Trajectories: End-to-End Analysis of the Spam Value
Chain“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.9 Phishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.11 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Studienbrief 2 Spam-Techniken
2.1 Lernergebnisse . . . . . . . . . . .
2.2 Advanced Organizer . . . . . . . .
2.3 Einleitung . . . . . . . . . . . . . .
2.4 Spammer . . . . . . . . . . . . . .
2.4.1 Spammer-Netzwerke . . .
2.4.2 Adress-Harvesting . . . . .
2.4.3 Anti-Harvesting-Methoden
2.4.4 Kontrollaufgaben . . . . . .
2.5 Offene Mail-Relays . . . . . . . . .
2.6 Mail-Formulare . . . . . . . . . . .
2.7 Webmail . . . . . . . . . . . . . . .
2.8 IP Prefix Hijacking . . . . . . . . . .
2.9 Malware / Botnetze . . . . . . . . .
2.10 Zusammenfassung . . . . . . . . .
2.11 Übungen . . . . . . . . . . . . . .
5
6
7
9
9
9
10
11
15
16
16
17
17
17
18
20
25
28
30
31
32
33
33
35
35
35
36
37
37
45
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
45
45
45
46
47
49
54
55
57
58
60
61
65
66
Studienbrief 3 Anti-Spam-Techniken
69
3.1 Lernergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Seite 4
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
Inhaltsverzeichnis
Advanced Organizer . . . . . . . . . . . . . . . . . . . . . . .
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mailfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP-Sperren . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1 Blacklisting . . . . . . . . . . . . . . . . . . . . . . . .
3.5.2 Whitelisting . . . . . . . . . . . . . . . . . . . . . . .
3.5.3 Graylisting . . . . . . . . . . . . . . . . . . . . . . . .
3.5.4 Kontrollaufgaben . . . . . . . . . . . . . . . . . . . . .
Reputationsverfahren . . . . . . . . . . . . . . . . . . . . . .
Challenge-Response-Verfahren . . . . . . . . . . . . . . . . .
Erweiterungen des E-Mail-Verfahrens . . . . . . . . . . . . . .
3.8.1 DomainKeys / DKIM . . . . . . . . . . . . . . . . . . .
3.8.2 SPF (Sender Policy Framework) . . . . . . . . . . . . .
3.8.3 Sender ID . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.4 Hashcash . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.5 Receiver-Driven SMTP . . . . . . . . . . . . . . . . . .
3.8.6 Kontrollaufgaben . . . . . . . . . . . . . . . . . . . . .
Echtzeit URL Filterung . . . . . . . . . . . . . . . . . . . . . .
Netzwerk-basiertes Clustern . . . . . . . . . . . . . . . . . . .
Erkennung von Botnetzen . . . . . . . . . . . . . . . . . . . .
Botnetz-Übernahme . . . . . . . . . . . . . . . . . . . . . . .
Botnet Judo: Automatische Generierung von Spam Signaturen
SpamAssassin . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . .
Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Liste der Lösungen zu den Kontrollaufgaben
Verzeichnisse
I.
Abbildungen . .
II.
Beispiele . . . .
III.
Definitionen . . .
IV.
Exkurse . . . . .
V.
Kontrollaufgaben
VI.
Literatur . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
69
69
69
72
72
75
76
77
78
80
82
82
85
88
89
90
90
91
93
93
95
98
101
101
102
107
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
119
. 119
. 119
. 119
. 119
. 120
. 121
Seite 5
I. Abkürzungen der Randsymbole und Farbkodierungen
Beispiel
B
Definition
D
Exkurs
E
Kontrollaufgabe
K
Merksatz
M
Übung
Ü
Seite 6
II. Zu den Autoren
Dr. Christopher Wolf studierte bis 2002 Informatik an der Universität Ulm und
wurde 2005 an der K.U. Leuven in Belgien promoviert. Aktuell ist er Leiter der
Emmy-Noether Arbeitsgruppe für Langszeitsicherheit an der Ruhr-Universität
Bochum und beschäftigt sich mit Post-Quantum Kryptographie.
Sebastian Uellenbeck studierte bis 2010 Informatik an der Technischen Universität
Dortmund. Aktuell ist er Doktorand bei Christopher Wolf und beschäftigt sich mit
neuartigen Authentifikationsmöglichkeiten auf Smartphones.
Modullehrziele
Seite 7
III. Modullehrziele
In diesem Modul erwerben die Teilnehmer Kenntnisse über das globale E-Mail System sowie die Schwachstellen, die zur Entstehung des Spam Problems führten. Im ersten Teil des Moduls werden Grundlagen des
Systems beschrieben, die zum einem aus dem Aufbau von E-Mail und zum anderen aus den benötigten
Protokollen bestehen. Der zweite Teil beschäftigt sich mit unterschiedlichen Spam-Techniken chronologisch
behandelt von den ursprünglichen naiven Techniken zu den heute angewendeten ausgeklügelten Techniken. Im dritten Teil werden dann Gegenmaßnahmen betrachtet und auch aktuelle Forschungsprojekte
angesprochen.
1.1 Lernergebnisse
Sie können die Struktur einer E-Mail nach RFC822 beschreiben und erkennen.
Darüber hinaus können Sie erläutern wie eine E-Mail spezifiziert ist und die Unterschiede zu SPAM klar abgrenzen. Weiterhin können Sie erklären wie Spam entsteht
und die wirtschaftlichen Aspekte, die den Versand von Spam für Kriminelle interessant machen, beschreiben. Dazu sind Sie in der Lage, die Grundlagen der
E-Mail-Struktur und deren Protokolle zu erläutern.
1.2 Advanced Organizer
Welche technischen Grundlagen liegen der heutigen E-Mail-Infrastruktur zugrunde? Diese Frage wollen wir in diesem Studienbrief einleitend klären. Wir werden
hier die Protokolle SMTP, IMAP und POP3 einführen, die bereits aus Netzsicherheit 2 bekannt sind. Darüber hinaus werden wir uns anschauen, welchen Anreiz
ein Spammer hat, Spam-Mail zu versenden und wie eine Mail als Spam spezifiziert
wird.
1.3 Einleitung
Elektronische Post (kurz E-Mail genannt) ist heutzutage ein beliebtes Kommunikationsmedium. Die E-Mail vereinigt die Vorteile der synchronen und asynchronen
Kommunikation, da sie im Allgemeinen, im Gegensatz zum gedruckten Brief, mit
nur geringen Kosten und fast ohne Zeitverzögerung zugestellt werden kann und
auch vom Empfänger abrufbar ist, sobald dieser sich dazu entscheidet.
Seit Jahrzehnten wird die Kommunikation via E-Mail jedoch durch Spam erschwert, indem der Großteil der verschickten und empfangenen E-Mails nicht
mehr aus erwünschten, sondern aus unerwünschten Spam-Nachrichten besteht.
Im schlimmsten Fall kann der Empfang von erwünschten Nachrichten sogar soweit
beeinträchtigt werden, dass diese durch Spam-Filter fälschlicherweise als Spam
erkannt und somit aussortiert werden. In der Literatur werden unterschiedliche
Angaben zum Anteil von Spam am gesamten E-Mail Aufkommen gemacht. Dabei
wird generell von mindestens 70 % Spam ausgegangen (vgl. Abbildung 1.2 auf
Seite 15).
Die Folgen von Spam sind vielfältig: Im privaten Bereich ist Spam hinderlich, da
die ungewollten E-Mails teilweise mühevoll per Hand aussortiert werden müssen.
Im geschäftlichen Umfeld ist Spam jedoch für einen nicht unerheblichen wirtschaftlichen Schaden verantwortlich, da Mitarbeiter in das Aussortieren von Spam
Zeit investieren müssen, die ihnen dann für ihre eigentliche Arbeit fehlt. Ebenso
müssen erhebliche Rechen- und Netzwerkkapazitäten zur Verfügung gestellt werden, damit der Transport und die Verarbeitung von erwünschten E-Mails nicht zu
sehr beeinflusst wird. Dagegen steigt die Unzufriedenheit eines Kunden, wenn ein
Anbieter nicht auf eine für den Kunden wichtige Nachricht reagiert. Der Kunde
kann in diesem Fall nicht wissen, ob seine Nachricht wirklich zugestellt oder durch
einen Filter entfernt wurde und der Anbieter daraufhin gar nicht in der Lage ist,
auf die Nachricht zu antworten.
Das vorliegende Modul hat die Aufgabe, dem Leser sowohl einen breiten Überblick
über das Thema Spam zu verschaffen, als auch einzelne besonders interessante
Aspekte genau zu betrachten. Dabei werden zum einen Grundlagen vermittelt, die
Seite 9
Seite 10
den Leser dazu schulen, Zusammenhänge und Techniken zu verstehen. Zum anderen werden aber auch aktuell Forschungsprojekte aufgegriffen und besprochen,
die einen Einblick in ausgeklügelte Methoden und Ansätze vermitteln.
1.3.1 E-Mail
Wie bereits im obigen Text beschrieben, handelt es sich bei E-Mails (engl.: electronic mail) um elektronische Nachrichten, die in Computernetzen verschickt
und empfangen werden. Dabei ist das größte Computernetz ohne Zweifel das
weltumspannende Internet und somit ist es mit Hilfe von E-Mail möglich, eine
Nachricht mit kaum merkbarem Zeitverzug an jeden beliebigen Ort auf der Erde
zu verschicken, der über einen Zugang zum Internet verfügt. Konkreter wird im
Abschnitt 1.5 auf die E-Mail und die dazu benötigte Infrastruktur eingegangen.
Es existieren verschiedene Definitionen für den Begriff E-Mail. Der Duden beschreibt die E-Mail bspw. mit [..] elektronischer Daten- und Nachrichtenaustausch über
Computer[..] (vgl. Duden Redaktion) [2012a]). Innerhalb dieser Studienbriefe gilt
die folgende Definition 1.1.
D
Definition 1.1: E-Mail
Eine elektronische Nachricht, die innerhalb eines Computernetzes verschickt
wird und deren Syntax konform zu RFC 822 (vgl. Crocker [1982]) ist, wird
als E-Mail bezeichnet.
Der Begriff RFC wird in Abschnitt 1.3.3 ab Seite 15 behandelt. Insgesamt hat die
E-Mail folgende Vorteile gegenüber normaler Post:
• Eine E-Mail gelangt innerhalb von Sekunden vom Versender zum Empfänger.
• Der finanzielle Aufwand für den Versand und den Empfang einer E-Mail
ist vergleichsweise gering, sofern die dafür benötigte Infrastruktur bereits
vorhanden ist. Insbesondere dann, wenn das Aufkommen eher groß ist,
wird der finanzielle Vorteil erkennbar.
• E-Mails gelten als umweltfreundlicher als physikalische Post, da kein Papier benötigt wird und der Transport per LKW, Bahn oder Flugzeug nicht
erforderlich ist.
• E-Mail-Adressen bieten eine gewissen Pseudonymität, teilweise sogar Anonymität. Je nach verwendetem Anbieter ist es möglich, nicht den eigenen
Namen zu verwenden, sondern einen eigenen Absender zu wählen. Hierdurch ist es nur noch für den Domain-Inhaber möglich, von der Adresse
auf den Absender zu schließen. Es existieren aber auch Dienste im Internet,
die eine E-Mail-Adresse ohne vorherige Anmeldung anbieten, sogenannte Einmal-E-Mail-Adressen (One Time Email) oder auch Wegwerf-E-MailAdressen (Disposable Email Address). Hierdurch wird es möglich, für den
Empfänger vollständig anonym zu wirken. Löschen die Anbieter ihre LogDateien regelmäßig, so ist eine vollkommene Anonymität möglich.
• E-Mails können weiterhin problemlos an mehrere Empfänger versendet
werden.
• Sie sind mit Hilfe von Software einfach nach bestimmten Suchbegriffen oder
Kriterien hin durchsuchbar. Daher können sehr schnell benötigte Informationen gefunden werden.
1.3 Einleitung
Seite 11
• Es ist außerdem problemlos möglich, E-Mails mit Anhängen zu versehen,
die dann mitübertragen werden.
• Weiterhin ist die Beantwortung einer E-Mail deutlich einfacher als bei normaler Post. Hier liegen die gleichen Vorteile wie beim Verfassen von E-Mails,
wie bspw. Zeit und Kosten.
Im Folgenden wird auf einen Teil des E-Mail-Aufkommens eingegangen, der mit
Spam benannt wird und Hauptgrund für die vorliegenden Studienbriefe ist.
1.3.2 Spam
Der Begriff Spam bezeichnet in der Regel unerwünschte elektronische Nachrichten,
die auf der einen Seite Werbung verbreiten sollen. Auf der anderen Seite wird
Spam allerdings auch zum sogenannten Phishing verwendet. Dabei werden EMails verschickt, die suggerieren, dass sie von einer offiziellen Stelle, oft einer Bank,
verschickt wurden und den Kunden dazu auffordern, bspw. seine Benutzerdaten
zu verifizieren. Die E-Mails stammen jedoch von Betrügern, die die Empfänger
durch Verweise in der E-Mail auf ihre präparierte Internet-Seite locken wollen,
um dort an persönliche Daten zu gelangen - im besten Fall auch an PIN und TAN
für die Konten der Empfänger. Phishing wird weiter in Abschnitt 1.9 ab Seite 36
behandelt.
Es existieren verschiedene Definitionen, um den Begriff Spam exakt zu fassen. Eine
der am weitesten verbreiteten Definitionen, die innerhalb dieses Moduls verwendet
wird, ist auch auf den Internetseiten des Spamhaus Projects (The Spamhaus Project
[2012b]) zu finden:
Definition 1.2: Spam
Eine Nachricht wird genau dann als Spam bezeichnet, wenn sie sowohl
unerwünscht (unsolicited) ist als auch in großen Mengen (bulk) verbreitet
wird.
D
• Unerwünschte E-Mails sind kein Spam, da es sich bspw. um ernst
gemeinte Jobanfragen oder auch Verkaufsanfragen handeln kann.
• Massen-E-Mails stellen auch keinen Spam dar, da bspw. Newsletter
oder Mailinglisten von Nutzer erwünscht sind.
Spam wird demnach auch als Unsolicited Bulk Email (UBE), also unerwünschte Massenmail, bezeichnet. Als Abgrenzung dazu bezeichnet der Begriff HAM
erwünschte bzw. reguläre E-Mail-Nachrichten.
Begriffsherkunft
Ursprünglich wurde das von der amerikanischen Firma Hormel Foods Corporation ab dem Jahr 1937 hergestellte Dosenfleisch als SPAM® (SPiced hAM, vgl.
Abbildung 1.1) bezeichnet, nachdem der Name bei einem Wettbewerb durch einen
der Teilnehme vorgeschlagen wurde.
Während des Zweiten Weltkriegs wurden von der Hormel Foods Corporation
mehr als 100 Millionen Pfund SPAM® an die Alliierten verschifft (Hormel Foods
Corporation [2012b]), wodurch SPAM® das einzige Nahrungsmittel zu dieser Zeit
war, das im Überfluss vorhanden war. Dieser Umstand wurde 1970 in der ComedyShow „Monty Python’s Flying Circus“ als Anlass für einen Sketch genommen,
Unsolicited Bulk Email,
HAM
Seite 12
Abb. 1.1: SPAM (Hormel Foods Corporation [2012a]).
indem die Ubiquität des Begriffs Spam eine normale Konversation unmöglich
macht.
Bis heute verkaufte die Hormel Foods Corporation mehr als sieben Milliarden
Dosen SPAM® . Als wichtige Randnotiz sollte angemerkt werden, dass der Begriff
SPAM® ein registriertes Markenzeichen der Firma Hormel Foods Corporation ist,
wohingegen unerwünschte Werbung als Spam bezeichnet wird (vgl. Schreibweise).
Neben der in diesem Modul behandelte Art von Spam in Form von E-Mails existieren noch viele weitere Arten von Spam, auf die im Folgenden kurz eingegangen
wird.
E
E
Exkurs 1.1: Instant-Messenger-Spam
Unerwünschte Nachrichten können in vielen Kontexten erzeugt und versendet werden. Dies geschieht bspw. auch bei Sofortnachrichtendienste
(Instant Messenger). Da viele Anbieter von Sofortnachrichtendiensten ein
Verzeichnis ihrer Nutzer bereitstellen, in denen persönliche Informationen
wie Alter und Geschlecht erfasst sind, ist es für Werbende denkbar einfach,
personenbezogene Werbung zu verschicken. Die meisten Protokolle, die für
Sofortnachrichtendienste verwendet werden, sind jedoch proprietärer Art
und können auf Wunsch des Herstellers verändert und aktualisiert werden.
Daher kann auf Schwachstellen eingegangen werden, um den unerwünschten Versand von Nachrichten einzuschränken. Viele Softwareprodukte bieten daher die Möglichkeit, dass der Nutzer Nachrichten ausschließlich von
bereits bekannten Kontakten erhält und sich neue Kontakte erst beim Nutzer
anmelden müssen, um diesem Nachrichten schicken zu können.
Exkurs 1.2: Mobile-Phone-Spam
Ein weiteres Medium, welches zum Versand von Spam genutzt wird, sind
Kurznachrichtendienste für Mobiltelefone (Mobile-Phone-Spam). Obwohl
Spam innerhalb von Kurznachrichten nur einen sehr geringen Anteil am
gesamten Datenvolumen ausmacht und außerdem für den Versender auch
Kosten verursacht, gibt es trotzdem auch in diesem Bereich einige Gegenmaßnahmen. Alle deutschen Mobilfunkanbieter stellen E-Mail-Adressen
zur Verfügung, an die sich Nutzer wenden können, sofern sie durch Spam
auf ihrem Mobiltelefon belästigt werden.
1.3 Einleitung
Exkurs 1.3: Foren-Spam
Internet-Foren werden generell zum asynchronen Austausch von Informationen genutzt. Dabei kann eine beliebig große Anzahl an Teilnehmern
Beiträge zu einem Thema veröffentlichen, die dann linear innerhalb einer
Internetseite dargestellt werden. Um Beiträge Teilnehmern zuzuordnen,
müssen sich die Teilnehmer, die Beiträge veröffentlichen wollen, an das
System anmelden. Schadsoftware, insbesondere Spam Bots, können die oftmals einfache Anmeldung an ein Forum automatisieren, um zu beliebigen
Beiträgen eigene Nachrichten zu erstellen, die zwar nichts mit dem Thema
des Beitrags zu tun haben, als Inhalt aber Werbung in Form von Links zu
anderen Internetseiten enthalten. Gegen diese als Foren-Spam bekannte
Art von Spam gibt es Gegenmaßnahmen, die zum einen bei der Erstellung
von Nutzerkonten greifen, zum anderen aber auch bei der Erstellung von
Beiträgen. So müssen nun Nutzer sogenannte CAPTCHAs (Completely Automated Public Turing test to tell Computers and Humans Apart) lösen, um
ein Konto zu eröffnen oder Beiträge zu veröffentlichen.
Exkurs 1.4: Online-Game-Spam
Viele gegenwärtige Spiele bieten die Möglichkeit, dass Teilnehmer innerhalb der Spielewelt untereinander kommunizieren. Oft gehört diese Art
der Kommunikation auch zum Konzept des Spiels. Gegeben durch diesen
Anlass können auch Nachrichten verschickt werden, die nicht zum Spielgeschehen dazu gehören, sondern bspw. Waren innerhalb aber auch außerhalb
des Spiels anbieten. Diese Art des Spam wird auch als Online-Game Spam
bezeichnet und findet sich häufig innerhalb von MMORPGs (Massively
Multiplayer Online Role-Playing Game).
Exkurs 1.5: Spamdexing
Eine weitere Form des Spams findet sich in Suchmaschinen, die das WWW
mit Hilfe von Suchbegriffen indizieren. Die als Spamdexing bekannte Technik macht sich die Eigenschaften der Algorithmen der Suchmaschinenbetreiber zunutze, um den Suchindex zu manipulieren. Das Ziel davon besteht
darin, bestimmte Seiten im Index so weit wie möglich an die Spitze der
Ergebnisse zu bringen, damit sie von Benutzern möglichst häufig besucht
werden.
Exkurs 1.6: Blog-, Wiki- und Gästebuch-Spam
Auch innerhalb von Blogs, Wikis oder Gästebüchern ist Spam ein Problem.
Sobald ein Medium zur Verbreitung von Informationen genutzt wird und
es gleichzeitig die Möglichkeit bietet, dass Besucher eigene Informationen
eintragen, können diese Dienste zur Darstellung von unerwünschten Informationen missbraucht werden.
Seite 13
E
E
E
E
Seite 14
Exkurs 1.7: SPIT und VoIP-Spam
E
Ebenso existiert Spam auch im Bereich gesprochener Nachrichten. Mit der
Entstehung von Voice-over-IP (VoIP) und der damit verbundenen Möglichkeit, Telefongespräche kostenlos über das Internet zu führen, entstanden
auch Möglichkeiten, das System für unerwünschte, automatisch angewählte
und im Vorhinein aufgezeichnete Anrufe zu nutzen. Diese Verbreitung wird
als SPam over Internet Telephony (SPIT), oft aber auch als Voice-over-IP
Spam (VoIP-Spam) bezeichnet. Wobei auch hier Gegenmaßnahmen existieren.
Exkurs 1.8: Academic Search Spam
E
Im akademischen Bereich werden oft unterschiedliche Suchmaschinen genutzt, um wissenschaftliche Literatur zu finden und auch um die Wichtigkeit
bestimmter Artikel zu erkennen. Beel und Gipp untersuchten dazu das Verhalten von Suchmaschinen und stellten fest, dass diese sich leicht durch
manipulierte Dokumente überlisten lassen und in Folge dessen beliebige
Suchergebnisse anzeigen (Beel and Gipp [2010]). So war es auch möglich,
als Treffen für eine Suche nach wissenschaftlichen Artikeln Werbung anzuzeigen.
Ursprung von Spam
Open Relay
Spam kann unterschiedliche Ursprünge haben und hat sich im Laufe der Zeit an
die gegebenen Möglichkeiten angepasst. Wie im Folgenden noch veranschaulicht
wird, wird ein Dienstanbieter benötigt, um E-Mails zu verteilen. Ursprünglich
sah die Standardkonfiguration dieser Server vor, dass man E-Mails über einen
Dienstanbieter versenden kann, auch wenn man sich nicht vorher als regulärer
Nutzer authentifiziert hatte. Dieses als Open Relay bekannte Verhalten machten
sich schon frühzeitig Spammer zunutze, um unbemerkt und anonym Spam zu
verbreiten. Durch die Möglichkeit, sich nicht authentifizieren zu müssen, konnten
beliebige Absenderadressen gewählt werden, um E-Mails zu maskieren. Eine
recht einfache aber wirkungsvolle Methode, das Problem der Open Relays zu
beheben, besteht darin, das Open Relay über seine IP-Adresse zu identifizieren,
um Nachrichten, die von ihm aus verschickt werden, direkt zu blockieren.
Open Proxy
Weiterhin existieren in den Anfangszeiten des Internets sehr viele Server, die
beliebige Informationen auf freigegebenen Ports weiterleiteten und dabei die QuellAdresse durch ihre eigene Adresse ersetzten. Diese, als Open Proxies bezeichneten
Computer, waren ähnlich wie die Open Relays ideal für Spammer, um andere
Identitäten anzunehmen, um nicht geblockt zu werden. Mit der Zeit wurden jedoch
viele dieser Server vom Netz genommen, sodass sich Spammer neue Möglichkeiten
zum Versand suchen musste.
Webmail
Eine Möglichkeit fanden sie in den weit verbreiteten Webmail-Diensten. Alle
großen Internetdienstanbieter bieten ihren Kunden E-Mail-Adressen an. Viele
Anbieter geben darüber hinaus auch weiteren Nutzern die Möglichkeit, ein EMail-Konto zu eröffnen, da sie sich bspw. daraus einen höheren Bekanntheitsgrad
erhoffen. Dadurch bedingt, dass es möglich ist, sich anonym ein E-Mail-Konto
zu erstellen, können nun Spammer beliebig viele Konten erstellen, um ihre unerwünschten Massenmails zu versenden. Dies kann jedoch wiederum durch den
Anbieter erkannt werden, sobald dieser zu Beispiel die Anzahl der ausgehenden
E-Mails überprüft und ab einen bestimmten Schwellwert das Konto sperrt. Daher
1.3 Einleitung
Seite 15
gibt es einen weiteren Bereich, der heutzutage vorherrschend als Ursprung von
Spam betrachtet wird.
Malware ist die Kurzform der englischen Begriffe malicious software (dt.: bösartige
Programme) und ist ein Oberbegriff für sämtliche schadhafte Software. Unter
diesen Begriff fallen Viren, Würmer, trojanische Pferde und viele weitere. Eine
Schadsoftware, die über eine Sicherheitslücke ein Computersystem befällt, kann
nicht nur lokale Informationen auf dem System auslesen und ändern, sondern
auch Netzwerkverbindungen aufnehmen. Mithilfe dieser Funktionalität kann eine
solche Schadsoftware den Rechner aus der Ferne steuern und auch neue Befehle
nachladen. Werden mehrere dieser Bots über einen Server zusammengeschlossen,
so ergibt sich ein Botnetz, das aus vielen tausenden Computersystemen bestehen
kann und durch den Botmaster gesteuert wird. Eine mögliche Schadfunktionalität
kann dabei der Versand von Spam sein, wobei dem vorausgehend bereits über
eine andere Schadfunktion das Adressbuch des Nutzers des Computersystems
ausgelesen worden sein kann, damit die Spam-Nachrichten an existierende E-MailKonten versendet werden. Heutzutage sind Botnetze aufgrund ihrer Flexibilität
und sehr schlechten Blockierbarkeit die häufigste Ursache von Spam.
Malware, Botnetz
Studienbrief 2 ab Seite 45 geht näher auf den Ursprung vom Spam ein.
Abb. 1.2: Der Anteil von
Spam am gesamten EMail-Aufkommen nach Symantec Corporation
[2012].
Einen Überblick über den Verlauf des Spamanteils im gesamten E-Mailverkehr
von 2006 bis 2012 liefert Abbildung 1.2 (vgl. Symantec Corporation [2012]). Zu
erkennen ist zum einen, aus welchen Ländern Spam hauptsächlich verschickt wird
und zum anderen, dass es immer wieder Schwankungen gibt, die bspw. durch die
Übernahme von Botnetzen zu erklären sind (vgl. Abschnitt 3.12 ab Seite 95).
1.3.3 RFC (Request for Comments)
Requests for Comments (dt.: Bitte um Kommentare) sind Dokumente, die technische Standards im Internet dokumentieren und spezifizieren (vgl. Internet Society,
Internet Engineering Task Force (IETF) [2012]). Im ursprünglichen Sinne waren
die Dokumente dazu gedacht, von anderen Entwicklern Kommentare zu Ideen zu
erhalten, um einen Standard zu erstellen. Innerhalb der darauffolgenden Diskussionen soll eine Idee soweit entwickelt werden, dass daraus ein möglichst fehlerfreier
Standard wird. Das endgültige Dokument, das als Standard betrachtet wird, wird
weiterhin Request for Comments (RFC) genannt. Spätere Änderungen an RFCs
Seite 16
sind nicht möglich. Mögliche Fehler können als RFC Errata angegeben werden
und dem Dokument angefügt werden, jedoch darf das Dokument nicht verändert
werden. Wird ein Standard erweitert, so müssen diese Erweiterungen innerhalb
einer neuen RFC beschrieben werden. Die Erweiterung kann auch die vorherige
RFC umdefinieren, womit die alte RFC obsolet wird. RFCs werden fortlaufend
durchnummeriert, um zum einen exakte Referenzierung zu ermöglichen und zum
anderen zeitliche Abhängigkeiten kenntlich zu machen. Daraus bedingt ist es
möglich, dass zu einem Standard mehrere RFCs existieren, die alle gleichzeitig
gültig sein können.
Innerhalb dieses Moduls werden oft bestimmte RFCs referenziert und beschrieben,
da Wert auf exakte Informationen gelegt wird. Der Leser ist dazu angehalten, die
RFCs als weiterführende Literatur zu betrachten und diese bei Verständnisproblemen als Hilfe zu verstehen.
1.3.4 Gliederung
Das gesamte Modul ist in vier Studienbriefe gegliedert. In diesem ersten Studienbrief werden die Grundlagen zur Analyse von Spam betrachtet. Dazu wird
zuerst besprochen, was Spam ist und wo er entsteht. Daraufhin wird die E-MailInfrastruktur skizziert, um darin die einzelnen Protokollschritte zu verstehen, die
eine E-Mail benötigt, um vom Sender zum Empfänger zu geladen. Weiterhin wird
aufgezeigt, welche Anreize bzw. Motivation Spammer antreibt und dass es Gründe gibt, warum Spam immer noch existent ist, obwohl es schon seit Jahrzehnten
Lösungen gibt. Anschließend wird innerhalb einer Fallstudie berichtet, wie das
Geschäft mit dem Versand von Spam funktioniert.
Der zweite Studienbrief befasst sich ab Seite 45 mit Spam-Techniken. Hier wird
beschrieben, wie Spam anfangs verbreitet wurde, welche Techniken die anfänglichen Versuche ablösten und was aktuell für das Spam-Aufkommen verantwortlich
ist.
Im dritten Studienbrief werden dann ab Seite 69 Techniken behandelt, die dazu gedacht sind, das Spam-Aufkommen einzudämmen. Es werden Methoden
besprochen, die sich aktuell im Einsatz befinden, aber auch zukunftsweisende
Forschungsarbeiten vorgestellt, die auf den weltweit wichtigsten Konferenzen von
Gutachten als zielführend betrachtet werden.
Der vierte Studienbrief beschäftigt sich ab Seite ?? letztendlich mit den rechtlichen
Aspekten von Spam. Hier wird untersucht, welche gesetzlichen Grundlagen in
verschiedenen Ländern existieren. Unterteilt wird in diesem Studienbrief nach Strafund Zivilrecht. Nachfolgend wird auch auf das Wettbewerbsrecht eingegangen,
bevor Empfehlungen zur Verhinderung vom Spam behandelt werden.
1.3.5 Kontrollaufgaben
In diesem Abschnitt befinden sich verschiedene Kontrollaufgaben, welche die
Inhalte der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffes
beitragen sollen.
K
Kontrollaufgabe 1.1: Vorteile von E-Mails
Geben Sie die drei Hauptvorteile von E-Mails im Vergleich zur gewöhnlichen
Post an.
1.4 Internet
Kontrollaufgabe 1.2: Umweltfreundlichkeit von E-Mails
Können Sie sich vorstellen, aus welchem Grund Diskussionen über die
Umweltfreundlichkeit von E-Mails geführt werden? Aus welchem Grund
können E-Mails weniger umweltfreundlich sein als physikalische Post?
Kontrollaufgabe 1.3: Spam in anderen Medien
Nennen Sie vier Medien (außer E-Mail), in denen Spam verschickt wird.
Kontrollaufgabe 1.4: Der Ursprung von Spam
Beschreiben Sie zwei mögliche Entstehungsarten von Spam und nennen
Sie Maßnahmen, mit denen Spam aus diesen Quellen unterbunden werden
kann.
Seite 17
K
K
K
1.4 Internet
Das Internet ist ein Netz von Computersystemen, das über die ganze Welt verteilt
ist und somit einen weltweiten Datenaustausch ermöglicht. Aufbauend auf diesem
Netz wurden verschiedene Dienste implementiert, von denen das World Wide
Web (WWW) vermutlich der bekannteste Teil des Internets ist. Innerhalb des
WWW können Informationen von zentralen Servern abgerufen und auch von
Nutzern bereitgestellt werden. Ein weiterer bekannter Dienst des Internets ist die
E-Mail, die maßgeblicher Bestandteil dieses Moduls ist. Die E-Mail soll das digitale
Gegenstück zum analogen Brief sein. Mithilfe dieses Dienstes wird versucht, die
positiven Eigenschaften von Briefen zu übernehmen und gleichzeitig die negativen
Eigenschaften zu beseitigen.
1.5 E-Mail-Infrastruktur
E-Mails nutzen zwar das Internet, um vom Sender zum Empfänger zu gelangen,
jedoch mussten dazu Designentscheidungen getroffen sowie Protokolle entwickelt
werden, die sich um das Behandeln der Daten kümmern. Daher wird im Folgenden beschrieben, welche Infrastruktur für den Transport von E-Mails im Internet
notwendig ist, wie E-Mails aufgebaut sind und wie die benötigten Protokolle dafür
definiert sind.
1.5.1 Kommunikationsmodell
Der Zweck einer E-Mail besteht darin, Informationen von einem Sender zu einem
Empfänger zu schicken. Dazu wäre es theoretisch ausreichend, wenn es eine Direktverbindung zwischen Sender und Empfänger geben würde und der Sender die
Daten direkt zum Empfänger schickt. Dieses direkte Kommunikationsmodell wird
als Peer-to-Peer-Modell bezeichnet, bei der auf eine zentrale Instanz verzichtet wird.
Solange beide Kommunikationspartner immer erreichbar sind, wäre es denkbar,
ein solches Kommunikationsmodell zu verwenden. Jedoch besteht ein zentrales
Ziel der E-Mail-Kommunikation darin, dass das gesamte System asynchron verwendet werden können soll. Um dieses Ziel zu erreichen, müsste der Sender so
lange mit dem Transfer der Nachricht warten, bis der Empfänger erreichbar ist,
um die Informationen zu erhalten. Im allgemeinen Fall möchte der Sender seinen
Computer allerdings nach Beendigung der Arbeit ausschalten können, was nur
Peer-to-Peer-Modell,
Client-Server-Modell
Seite 18
dann möglich ist, wenn er auf das Versenden der E-Mail verzichtet. Der Empfänger
möchte weiterführend auch, dass ein Sender E-Mails an ihn verschicken kann,
auch wenn er aktuell Probleme mit seiner Internetverbindung hat. Daraus ergibt
sich die Notwendigkeit einer zentralen Instanz und der Verwendung des ClientServer-Modells. In diesem Fall existiert ein Server, der immer verfügbar ist und
die Nachricht eines Sender annimmt, um sie später an dem Empfänger weiter zu
reichen, sobald dieser verfügbar ist.
Die im Internet verwendete E-Mail-Infrastruktur verwendet das Client-ServerModell, erweitert dies jedoch soweit, dass nicht nur ein Server verwendet wird,
sondern beliebig viele als Dienstanbieter fungieren können. Da ein E-Mail-Konto
immer einem Server zugeordnet ist, prinzipiell aber jeder Nutzer die Möglichkeit
hat, einen eigenen E-Mail-Server zu betreiben, war diese Erweiterung des Modells
notwendig.
Abbildung 1.3 stellt beispielhaft dar, wie eine E-Mail von einem Empfänger zu
einem Sender gelangt und zeigt dabei auch die verwendeten Protokolle, von denen
das Simple Mail Transfer Protocol (SMTP), das Post Office Protocol Version 3 (POP3)
sowie das Domain Name System (DNS) im späteren Verlauf dieses Studienbrief
genauer vorgestellt werden.
Abb. 1.3: UMLSequenzdiagramm einer beispielhaften EMail-Sitzung, bei der
Nutzer A mit seinem
Mail-User-Agent (MUA)
eine E-Mail an Nutzer
B schickt. An den Pfeilen stehen die jeweils
verwendeten Protokolle.
MUA (A)
SMTP Server (A)
NS Server (B)
POP3/SMTP Server (B)
MUA (B)
E-Mail Versand an eigenen Server.
SMTP
DNS Anfrage nach Adresse des
Mail-Servers von B.
DNS
DNS Antwort mit Adresse des
Mail-Servers von B.
DNS
E-Mail Versand an Mail-Server von B.
SMTP
Mail-Server von B wartet auf Anfrag
von B.
Anfrage nach neuen E-Mails von B an
eigenen E-Mail-Server.
POP3
Gespeicherte E-Mail von A wird
ausgeliefert.
POP3
1.5.2 Aufbau von E-Mails
RFC 5322, US-ASCII
E-Mails sind strukturell in zwei Teile unterteilt: Es existiert zum einen ein Header,
der wichtige Informationen für den Transport enthält, sowie ein Body, der den
Inhalt der E-Mail beinhaltet. Grundlegend wurde der Aufbau von E-Mails durch
die Internet Engineering Task Force (IETF) im aktuellen Request for Comments
(RFC) 5322 (Resnick [2008]) spezifiziert, der jedoch durch weitere RFCs bzgl. Internationalisierung erweitert wurde. Ein weiterer wichtiger Punkt zum generellen
Aufbau von E-Mails ist, dass E-Mails nur aus druck- bzw. lesbaren Zeichen sowie
wenigen Steuerzeichen wie Zeilenumbruch, Leerzeichen und Tabulator (US-ASCII,
vgl. Exkurs 1.9) bestehen. Das bedeutet zum einen, dass E-Mails ohne weitere
Hilfsmittel per Hand von Menschen ausgewertet werden können, da sie nicht
die volle Breite eines Bytes von 28 = 256 möglichen Belegungen ausnutzen. Zum
anderen können dadurch Binärdateien nicht ohne eine Transformation übertragen
Seite 19
werden, bei welcher der Anhang vom Binärformat in ein kompatibles Format vor
der Übertragung transformiert wird.
Exkurs 1.9: US-ASCII
ASCII steht für American Standard Code for Information Interchange und
ist eine Zeichenkodierung, die 33 nicht druckbare sowie 95 druckbare Zeichen einem Bitmuster zuweist. Als Zeichenvorrat dient grundsätzlich das
Alphabet einer Schreibmaschine für die englische Sprache sowie einige Protokollzeichen bspw. zum Anzeigen des Übertragungsendes. Dabei steht das
A an Position 65 und wird somit als Binärstring 01000001 übertragen.
Da nur 128 Zeichen definiert sind, ein Byte aber 256 mögliche Repräsentationen hat, bleibt 18 = 12, 5% der möglichen Bandbreite bei der Übertragung
von Zeichen in ASCII-Kodierung ungenutzt.
Im Folgenden werden die einzelnen Teile von E-Mails genauer betrachtet.
Header
Nach RFC 5322 (Resnick [2008]) sind Header-Felder, Zeilen, die mit einem Namen
gefolgt von einem Doppelpunkt beginnen, und nach einem Feldinhalt durch einen
Zeilenumbruch (CRLF) beendet werden. Der Feldinhalt darf keinen Zeilenumbruch enthalten, es sei denn, es handelt sich um ein Long Header Field, das durch
Teilung (engl.: folding) bzw. Invertierung der Teilung entstanden ist. Header-Felder
teilen sich weiter auf in unstrukturierte Header-Felder sowie strukturierte HeaderFelder. Dabei enthalten unstrukturierte Header-Felder einen Inhalt, der zwar aus
druckbaren Zeichen bestehen muss, allerdings keinen weiteren syntaktischen
Regeln genügen muss. Im Gegensatz dazu müssen strukturierte Header-Felder
syntaktisch nach bestimmten Regeln aufgebaut sein. Zur Optimierung der lexikalischen Analyse von Nachrichten existieren jedoch Regeln zur maximalen Länge
einer Zeile. Diese besagen, dass Zeilen nicht länger als 78 Zeichen lang sein sollten
und nicht länger als 998 Zeichen lang sein dürfen. Um trotzdem längere HeaderZeilen zu erlauben, wird die Regel eingeführt, dass für jedes syntaktisch korrekte
Leerzeichen innerhalb des Inhaltes eines Headers anstelle dessen auch ein Zeilenumbruch vor dem Leerzeichen eingefügt werden kann. Mögliche Header-Felder
sind from, sender, to sowie subject.
Body
Die RFC 5322 definiert auch syntaktisch den Inhalt des Body-Teils einer E-Mail.
An diesen Teil werden nur zwei Anforderungen gestellt.
1. Die Steuerzeichen CR (carriage return = Wagenrücklauf) und LF (line feed =
Zeilenvorschub) dürfen nur direkt hintereinander stehen, aber nicht einzeln
im Body vorkommen.
2. Zeilen sollten eine Länge von 78 Zeichen nicht überschreiten und dürfen
maximal 998 Zeichen lang sein.
E
Seite 20
Beispiel 1.1: Eine einfache E-Mail
B
From: erika.mustermann@example.org
To: max.mustermann@example.org
Subject: Beispiel E-Mail
Date: Fri, 28 Nov 1997 09:54:05 +0100
Message-ID: <1234@local.example.org>
Das ist eine Beispiel-E-Mail.
Zu beachten sind insbesondere die beiden Leerzeilen. Die erste Leerzeile trennt
den Header vom Body. Ohne eine solche Leerzeile enthält eine E-Mail keinen Body,
sondern nur einen Header. Die zweite Leerzeile definiert das Ende der E-Mail und
ist somit auch syntaktisch von essenzieller Wichtigkeit.
Im Folgenden werden verschiedene Protokolle beschrieben, die für den Transfer
von E-Mails von Bedeutung sind.
1.5.3 SMTP (Simple Mail Transfer Protocol)
RFC 821, 5321,
RFC 854, RFC 855
SMTP wurde erstmals in RFC 821 (Postel [1982]) im Jahre 1982 spezifiziert und
ist ein Kernelement der E-Mail-Kommunikation. Über die Jahre wurden einige
Erweiterungen und Verbesserungen eingepflegt, die letztendlich durch RFC 5321
(Klensin [2008]) spezifiziert sind. Das Protokoll hat grundsätzlich zwei Funktionen. Zum einen wird es verwendet, um E-Mails in das System einzuschleusen.
In diesem Fall meldet sich ein Client bei einem Server an und definiert innerhalb
dieser Sitzung eine E-Mail, die der Server lokal speichert. Zum anderen wird das
Protokoll auch verwendet, um eine Kommunikation zwischen verschiedenen Servern zu ermöglichen. Dies ist bspw. dann notwendig, wenn Server A von einem
Client eine E-Mail erhalten hat, das Konto des Empfängers sich allerdings nicht
auf demselben Server befindet. In diesem Fall baut Server A eine Verbindung zu
Server B auf und leitet die E-Mail entsprechend weiter, damit Server B die E-Mail
daraufhin in das richtige Postfach einsortieren kann. Das Protokoll baut, ähnlich
wie auch die E-Mail selbst, auf der US-ASCII-Zeichenkodierung (vgl. Exkurs 1.9)
auf und ist somit von Menschen lesbar und auch interpretierbar. Daraus resultierend kann eine SMTP-Sitzung auch mit Hilfe des Telnet-Protokolls (vgl. Postel and
Reynolds [1983a,b]) initiiert werden und vollständig ohne weitere Software ausgeführt werden. Abbildung 1.4 auf Seite 41 stellt eine SMTP-Sitzung beispielhaft
dar.
RFC 959
SMTP definiert für die Kommunikation mehrere Status-Codes, die auf den StatusCodes des File Transfer Protocols (FTP) (vgl. Postel and Reynolds [1985]) basieren,
allerdings nicht vollständig identisch sind. Dabei sind Status-Codes immer dreistellig und sind als Rückgabe des Servers an den Client konzipiert, damit dieser
entweder auf Fehler reagieren kann oder sich vergewissern kann, dass ein Befehl
ordnungsgemäß ausgeführt wurde.
Seite 21
Im folgenden Exkurs 1.10 werden die SMTP-Status-Codes detaillierter beschrieben.
Exkurs 1.10: SMTP-Status-Codes
Für die erste und wichtigste Stelle des SMTP-Status-Codes gibt es vier mögliche Werte, wobei y und z stellvertretend für andere Ziffern stehen:
2yz Die Antwort bestätigt den vom Client gesendeten Befehl und zeigt
auf, dass der Befehl vollständig ausgeführt wurde.
3yz Die Antwort bestätigt den vom Client gesendeten Befehl, allerdings
werden zur vollständigen Verarbeitung weitere Informationen vom
Client benötigt. Andernfalls kann der Befehl nicht vollständig verarbeitet werden.
4yz Eine vorübergehende negative Antwort: Der Befehl wurde nicht umgesetzt und die angefragte Aktion konnte temporär nicht ausgeführt
werden. Der Sender soll mit dem Befehl erneut beginnen, damit dieser ggf. erfolgreich ausgeführt werden kann. Im Gegensatz zu 5yz
Status-Codes der nächsten Kategorie, sollen diese Status-Codes übermittelt werden, wenn es möglich ist, dass der exakt gleiche Befehl
durch erneutes Senden zum Erfolg führt.
5yz Eine permanente negative Antwort: Der Befehl wurde nicht umgesetzt, die angefragte Aktion kann nicht ausgeführt werden und der
Client soll die gleiche Anfrage auch nicht erneut an den Server senden. Dieser Fall tritt ein, wenn bspw. die Syntax des Clients nicht dem
Standard entspricht.
Die zweite Ziffer teilt die Status-Codes in weitere Kategorien ein:
x0z Der übersendete Befehl enthält einen syntaktischen Fehler.
x1z Für den übersendeten Befehl existieren weitere Informationen, bspw.
ein Status oder eine Hilfe.
x2z Der Status betrifft den Übertragungskanal.
x3z Nicht spezifiziert.
x4z Nicht spezifiziert.
x5z Der Status betrifft das empfangende Mail-System.
Die dritte Stelle ist letztendlich zur Abgrenzung einzelner Status-Rückgaben
gedacht, die durch die zweite Stelle nicht genau genug spezifiziert werden
konnten.
E
Seite 22
Im folgenden Beispiel werden einige mögliche Rückgabewerte angeführt.
Beispiel 1.2: SMTP-Status-Codes
220 mail.example.com Dienst verfügbar.
B
250 Angefragte E-Mail Aktion erfolgreich ausgeführt.
452 Angefragte Aktion nicht ausgeführt: Ungenügend Speicherplatz.
500 Syntaktischer Fehler, Befehl nicht erkannt.
501 Syntaktischer Fehler innerhalb der Parameter oder Argumente.
SMTP ist unverschlüsselt und enthält keine Maßnahmen zur Authentifizierung
von Nutzern. Es vertraut darauf, dass es nur von ehrlichen Nutzern verwendet
wird, die ihre echten Daten angeben.
Es gibt jedoch verschiedene Erweiterungen für SMTP, um das Protokoll gegen
verschiedene Arten von Angriffen abzusichern. Um eine Nutzerauthentifizierung
zu erreichen, wurden drei verschiedene Ansätze verfolgt. Im Einzelnen sind dies
SMTPS, SMTP-After-POP sowie SMTP-Auth.
RFC 2487
SMTPS ist eine Erweiterung, die in RFC 2487 (vgl. Hoffman [1999]) beschrieben
wird. Hier wird auf der Transportschicht auf das TLS-Protokoll aufgebaut.
Bei SMTP-After-POP wird die im POP3 (vgl. nächster Abschnitt) optionale Nutzerauthentifizierung verwendet, um nach der erfolgreichen Authentifizierung
auch E-Mails versenden zu können.
RFC 2554, RFC
4954, RFC 4616
Aufgrund einer relativ aufwendigen Implementierung wird heutzutage allerdings
oftmals eher SMTP-Auth verwendet, das erstmals in RFC 2554 (vgl. Myers [1999])
definiert wurde. RFC 4954 ist eine Überarbeitung davon und gilt als vorgeschlagener Standard (vgl. Siemborski and Melnikov [2007]). SMTP-Auth beschreibt fünf
verschiedene Möglichkeiten zur Authentifizierung. Zum einen wird die PLAINAuthentifizierung vorgeschlagen, die als RFC 4616 (vgl. Zeilenga [2006]) die RFC
2595 (vgl. Newman [1999]) erweitert. Bei dieser Möglichkeit der Authentifizierung werden Benutzername und Passwort zwar nicht im Klartext (engl.: plain)
übertragen, da sie Base64-kodiert (vgl. Exkurs 1.11) werden, jedoch ist eine Base64-
Seite 23
Kodierung keine Verschlüsselung, da diese Funktion ohne Passwort auskommt
und invertierbar ist (vgl. Merksatz 1.1).
Exkurs 1.11: Base64-Kodierung
E
Die Base64-Kodierung wird neben der Base16- und Base32-Kodierung in der
RFC 4648 (vgl. Josefsson [2006]) beschrieben. Dabei werden binären Daten
in ein von Menschen lesbares Alphabet kodiert. Konkreter wird immer
eine Gruppe von 24 Bit (3 Byte) in vier 6-Bit-Blöcke unterteilt und danach
jeder einzelne Block umgewandelt. Die folgende Tabelle dient dabei der
Zuordnung zwischen dem Wert W , also der dezimalen Darstellung einer 6
Bit langen Zeichenkette und dem dafür zu verwendenden Code C:
W
C
W
C
W
C
W
C
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
R
S
T
U
V
W
X
Y
Z
a
b
c
d
e
f
g
h
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
i
j
k
l
m
n
o
p
q
r
s
t
u
v
w
x
y
51
52
53
54
55
56
57
58
59
60
61
62
63
z
0
1
2
3
4
5
6
7
8
9
+
/
(pad)
=
RFC 4648
Eine binäre Zeichenkette der Länge n benötigt nach der Umwandlung folgenden Speicherplatz:
n+2
4∗
3
Enthält die letzte umzuwandelnde Gruppe nur 1 Byte, so wird der resultierende Block mit zwei padding-Zeichen (=) aufgefüllt. Enthält die letzte
umzuwandelnde Gruppe 2 Byte, so wird ein padding-Zeichen angefügt.
Merksatz 1.1: Base64-Kodierung
Es ist zu beachten, dass die Base64-Kodierung keine Verschlüsselung darstellt, da es ohne weitere Informationen möglich ist, aus einer Base64kodierten Zeichenkette den ursprünglichen Text zu berechnen.
Das folgende Beispiel 1.3 zeigt exemplarisch die Verwendung der Kodierung.
M
Seite 24
Beispiel 1.3: Base64-Kodierung
B
In der folgenden Tabelle wird das Wort „Studie“ zuerst in das US-ASCIIÄquivalent in dezimaler Schreibweise überführt. Aus der dezimalen Schreibweise wird die binäre Darstellung bestimmt. Sechs Bits werden dann jeweils
als Block betrachtet und wieder in ihre dezimale Darstellung umgeformt.
Diese dezimale Darstellung eines 6-Bit-Blocks entspricht dann jeweils dem
Index i aus der Tabelle aus Exkurs 1.11.
Zeichen
S
t
u
d
i
e
ASCII Dezimal
83
116
117
100
105
101
ASCII Binär 0 1 0 1 0 0 1 1 0 1 1 1 0 1 0 0 0 1 1 1 0 1 0 1 0 1 1 0 0 1 0 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 0 1
Index
20
55
17
53
25
6
37
37
Base64
U
3
R
1
Z
G
l
l
Eingesetzt ergibt sich die Zeichenkette „U3R1ZGll“. Analog ist es möglich,
die Berechnung bei der Base64-kodierten Zeichenkette zu starten, um daraus
die ursprüngliche Zeichenkette zu erhalten.
Die zweite Möglichkeit, die in der RFC 4954 zur Authentifizierung vorgeschlagen
wird, ist die LOGIN-Methode. Die LOGIN-Authentifizierung funktioniert ähnlich wie
die PLAIN-Authentifizierung. Hier werden Benutzername und Passwort auch per
Base64 kodiert, jedoch im Gegensatz zur PLAIN-Authentifizierung in zwei Schritten
übertragen.
RFC 2195, RFC
1321, RFC 2104
Als drittes Verfahren gilt das in RFC 2195 (vgl. Klensin et al. [1997]) als CRAM-MD5
vorgestellte Verfahren. CRAM-MD5 steht für Challenge-Response Authentication
Mechanism, Message Digest 5 und ist demnach ein Authentifizierungsverfahren,
das nach dem Challenge-Response-Prinzip (vgl. auch Abschnitt 3.7 ab Seite 80)
funktioniert und auf dem MD5-Algorithmus (vgl. Rivest [1992] basiert. Grundsätzlich verwendet CRAM-MD5 in drei Schritten:
1. Der Server sendet eine Zeichenkette (Challenge) an den Client. Diese Zeichenkette muss einen Zeitstempel und den vollständigen Hostnamen des
Servers enthalten. Außerdem sollen noch willkürliche Ziffern enthalten sein,
um die Zeichenkette möglichst einmalig zu machen.
2. Der Client antwortet mit einer Zeichenkette, die wie folgt erzeugt wird:
a) Die Zeichenkette vom Server wurde mit dem Base64-Verfahren kodiert. Daher muss die Zeichenkette dekodiert werden.
b) Die dekodierte Zeichenkette wird per HMAC-MD5 (vgl. Krawczyk
et al. [1997]) mit dem Passwort des Nutzers verschlüsselt.
c) Die verschlüsselte Zeichenkette wird in eine hexadezimale Zeichenkette überführt.
d) Der Nutzername sowie ein Leerzeichen werden der hexadezimalen
Zeichenkette vorangestellt.
e) Die resultierende Zeichenkette wird Base64-kodiert und an den Server
verschickt.
3. Der Server verwendet dieselbe Methode wie der Client, und vergleicht
sein Ergebnis mit der vom Client übertragenen Zeichenkette. Falls beide
Zeichenketten gleich sind, dann war die Authentifizierung erfolgreich.
Seite 25
Durch dieses Vorgehen entstehen drei verschiedene Sicherheitsaspekte:
1. Es ist für dritte nicht möglich, den generierten Hash zu duplizieren, ohne
das verwendete Passwort zu kennen. Dadurch wird die Authentifizierung
ermöglicht.
Authentifizierung
2. Ein Replay-Angriff ist für Angreifer nicht möglich, da die Zeichenkette,
die vom Client an den Server gesendet wird, von der Zeichenkette des
Servers abhängt, die auf der einen Seite einzigartig und auf der anderen
Seite willkürlich sein soll.
Replay-Angriff
3. Als weiterer Sicherheitsaspekt ist es für Angreifer, die den Netzwerkverkehr
belauschen, nicht möglich, aus den gelesenen Informationen das Passwort
zu erlernen. Diese Eigenschaft wird als Verschwiegenheit bezeichnet.
Verschwiegenheit
Die beiden letzten Verfahren sind das in RFC 5802 (vgl. Newman et al. [2010])
spezifiziert SCRAM-SHA1 sowie NTLM. Auf beide Verfahren wird aufgrund derer
Komplexität nicht eingegangen.
RFC 5802
Nachdem nun die Eigenschaften von SMTP ausgiebig beschrieben wurden, folgt
im nächsten Abschnitt das Post-Office-Protokoll in Version 3.
1.5.4 POP3 (Post Office Protocol Version 3)
Im Gegensatz zu dem im vorherigen Abschnitt vorgestellten SMTP, ist POP3 kein
Protokoll zum Versand von E-Mails. Es wird vielmehr zum Abholen von E-Mails
verwendet, basiert aber ebenfalls wie SMTP auf der US-ASCII-Zeichenkodierung
(vgl. Exkurs 1.9) und ist somit von Menschen lesbar. Die erste RFC, die das Protokoll
spezifiziert, ist RFC 918 aus dem Jahr 1984 (Reynolds [1984]). Wie die Einleitung der
RFC bereits schreibt, war das Protokoll dazu gedacht, mithilfe eines ArbeitsplatzComputers (Workstation) dem Nutzer Zugriff auf E-Mails zu geben, die auf einem
E-Mail-Server liegen. Zwar wäre es für einen Nutzer auch möglich, seinen eigenen
Computer mithilfe entsprechender Software als SMTP-Server zu konfigurieren,
der Betrieb wäre jedoch aus mehreren Gründen sehr schwierig. Zum einen kann
ein Nutzer nicht sicherstellen, dass sein Computer jederzeit erreichbar ist, was
den Empfang von E-Mails erschweren kann. Zum anderen verfügen nur wenige
Nutzer über eine statische IP-Adresse, da sie oftmals durch eine DSL-Verbindung
mit dem Internet verbunden sind und der ISP (Internet Service Provider) nach
der Zwangstrennung dem Nutzer eine neue IP-Adresse zuweist. Nach der Zuweisung einer neuen IP-Adresse müsste dann der MX-Record für die Domäne
des Nutzers angepasst werden und auch im Domain Name System (DNS, vgl.
Mackapetris [1987a,b], Elz and Bush [1997], Gulbrandsen et al. [2000], siehe auch
Abschnitt 1.5.6 ab Seite 30) entsprechend verteilt werden, damit neue E-Mails an
die richtige Adresse gehen. Aufgrund der eben genannten Eigenschaften ist ein
eigener SMTP-Server im Heimnetzwerk für viele Nutzer keine Option, wodurch
dann die Möglichkeit des E-Mail-Abrufs per POP3 ins Spiel kommt.
RFC 918, RFC 1034, DNS
Abbildung 1.6 auf Seite 43 zeigt eine POP-Sitzung. Zu erkennen ist die Authentifikation im ersten Schritt nach dem Verbindungaufbau, was POP3 zu etwas mehr
Sicherheit verhilft. Es ist zwar mithilfe von SMTP möglich, E-Mails in das System unter falschem Namen einzuschleusen, jedoch kann nur derjenige, der die
Zugangsdaten für ein Konto hat, die eingetroffenen E-Mails auch abrufen. Nach
vielen Detailverbesserungen ist RFC 1939 (Myers and Rose [1996]) die letzte und
aktuelle Spezifikation von POP3. Sicherheitskritisch ist dabei jedoch zu beachten,
dass auch in diesem Protokoll die Kommunikation unverschlüsselt stattfindet und
somit abgehört werden kann. Das Passwort wird zusätzlich im Klartext übertragen, wodurch nicht nur die Inhalte der übertragenen E-Mails an den einzelnen
RFC 1939
Seite 26
Knoten der Datenübertragung sichtbar waren, sondern auch alle notwendigen
Informationen über das Benutzerkonto. POP3 sollte daher nicht in unbekannten
oder nicht vertrauenswürdigen Netzwerken ohne separate Absicherung verwendet
werden.
Die Basisoperationen von POP3 lassen sich innerhalb von wenigen Punkten
beschreiben und aus Zustandsgraph visualisieren (vgl. Abbildung 1.5). Der
POP3-Server wartet auf einen Verbindungsaufbau von einem Client (Zustand:
WAITING_FOR_CONNECTION). Nachdem der Client eine Verbindung aufgebaut
hat, sendet der Server eine Willkommensnachricht an den Client (Zustand:
AUTHORIZATION). Der Client muss sich daraufhin am Server authentifizieren, damit
der Server die Verbindung zum richtigen Postfach herstellen kann (Zustand:
TRANSACTION). Daraufhin tauschen Server und Client solange Nachrichten aus, bis
die Verbindung geschlossen oder abgebrochen wird (Zustand: Update). Nachdem
der Server das QUIT-Kommando erhalten hat, gibt es die zuvor reservierten
Ressourcen wieder frei (Zustand: UPDATE) und beendet daraufhin die Verbindung
(Zustand: CLOSE). Nachdem die Verbindung geschlossen wurde, geht der Server
wieder in den Ausgangszustand (WAITING_FOR_CONNECTION).
Insgesamt sollte festgehalten werden, das POP3-Kommandos Text-basiert und
ohne Beachtung von Groß- und Kleinschreibung sind. Nach einem Schlüsselwort
können ein oder mehrere Argumente folgen. Schlüsselwörter wiederum können
aus drei oder vier Zeichen bestehen, Argumente dürfen bis zu 40 Zeichen lang
sein. Beide enthalten ausschließlich druckbaren US-ASCII-Zeichen. Antwortnachrichten bestehen aus einem Statusindikator (+/-) und einem Schlüsselwort, das
mit weiteren Informationen erweitert werden darf. Alle Antworten werden durch
die beiden Steuerzeichen CRLF beendet und dürfen maximal 512 Zeichen (inkl. die
abschließenden Steuerzeichen) lang sein. Als Statusindikatoren dürfen nur der
positive Status +OK und der negative Status -ERR verwendet werden. Antworten auf
bestimmte Befehle dürfen aus mehreren Zeilen bestehen. In diesem Fall müssen
alle Zeilen mit den Steuerzeichen CRLF beendet werden und schlussendlich muss
der Befehl mit einem Punkt (.) und einem weiteren CRLF abgeschlossen werden.
Daraus folgt, dass beim Lesen von CRLF.CRLF der Kommunikationspartner davon
ausgeht, dass damit das Ende des Befehls erreicht wurde. POP3-Server haben die
Möglichkeit, optional einen Timeout zum automatischen Logout eines Nutzers zu
verwenden, damit ungenutzte Ressourcen möglichst schnell wieder freigegeben
werden können.
Im folgenden Beispiel 1.4 werden einige wichtige Befehle von POP3 beschreibend
aufgelistet.
Beispiel 1.4: POP3-Befehle
USER benutzername wählt das Benutzerkonto mit dem Namen benutzername
aus.
PASS passwort übergibt das Passwort passwort im Klartext an den Server.
STAT listet den Status der Mailbox auf. Dabei wird zum einen die Anzahl
der vorhandenen E-Mails ausgegeben und zum anderen der durch
diese E-Mails belegte Speicherplatz.
LIST (n) zeigt Informationen zur n-ten E-Mail an. Wird kein Argument mit-
gegeben, so wird je vorhandener E-Mail jeweils eine Informationszeile
angegeben.
RETR n zeigt den Inhalt der n-ten E-Mail an. Die Angabe von n ist hier zwin-
gend notwendig.
DELE n markiert die n-te E-Mail auf dem Server. Der Speicherplatz wird
erst dann freigegeben, sobald der Server in den UPDATE-Zustand (vgl.
Abbilding 1.5 auf Seite 42) geht.
NOOP enthält keinen Befehl, kann aber an den Server gesendet werden, um
den Timeout zurückzusetzen, der optional implementiert sein kann.
Dadurch wird der Server daran gehindert, die Verbindung zu beenden und der Client muss nicht erneut eine Verbindung aufbauen.
RSET setzt alle als gelöscht markierten E-Mails zurück. Dadurch können
fälschlicherweise gelöschte E-Mails wiederhergestellt werden. Dies
ist allerdings nur solange möglich, wie die Verbindung noch geöffnet ist. Sobald die Verbindung zwischen Client und Server einmal
geschlossen wurde, wurden die zum Löschen markierten E-Mails im
UPDATE-Zustand entfernt und der Speicherplatz freigegeben.
QUIT versetzt den Server in den UPDATE-Zustand. Hierbei soll der Server
alle zum Löschen markierten E-Mails entfernen. Ist der Löschvorgang
nicht erfolgreich, so quittiert der Server dies mit einer negativen
Rückmeldung.
Seite 27
B
Seite 28
Wie bereits weiter oben beschrieben, hat POP3 zwei Schwachstellen. Zum einen
findet die Benutzerauthentifikation im Klartext statt. Dadurch bedingt ist es für
Angreifer mit vergleichbar geringem Aufwand möglich, die Kontoinformationen
wie Benutzername und Passwort herauszufinden. Zum anderen verwendet POP3
keine Verschlüsselung, wodurch nicht nur die Kontoinformationen, sondern auch
alle anderen Informationen für Angreifer sichtbar werden.
APOP, RFC
822, RFC 1321
Um das erste Problem anzugehen, enthält POP3 den optionalen Befehl APOP. Server,
die diesen Befehl implementieren, senden nach dem Verbindungsaufbau durch
den Client nicht nur +OK als Status-Code zurück, sondern auch einen Zeitstempel,
der auf der einen Seite einzigartig sein muss und auf der anderen Seite auch einer
msg-id (vgl. Crocker [1982]) entsprechen muss. Der Client verwendet dann für
die Anmeldung nicht die beiden separaten Befehle USER und PASS, sondern nur
den Befehl APOP. Er konkateniert dazu den übermittelten Zeitstempel des Servers
mit seinem eigenen Passwort. Zu diesem String muss dann der MD5-Hashwert
(vgl. Rivest [1992]) berechnet werden, der wiederum als Passwort übertragen wird.
Der APOP-Befehl enthält dann den Benutzernamen im Klartext sowie den vorher
berechneten Hashwert als Argumente. Der Server, der das Kennwort zu dem
Benutzerkonto kennt, kann dann auch den Hashwert zu dem von ihm generierten Zeitstempel konkateniert mit dem Kennwort des Benutzers berechnen und
somit abgleichen, ob der Benutzer das korrekte Kennwort eingegeben hat. Von
essenzieller Bedeutung ist hierbei, dass jeder Zeitstempel einzigartig ist.
POP3S, RFC 2595
Für das zweite Problem der nicht vorhandenen Verschlüsselung bietet POP3 keine
direkte Lösung. Als Erweiterung von POP3 wird hier POP3S angeführt. Dieses
Protokoll baut auf POP3 auf, verwendet als Protokoll auf der Transport-Schicht
allerdings TLS (Transport Layer Security) und ist innerhalb der RFC 2595 spezifiziert (vgl. Newman [1999]). Somit existieren Möglichkeiten, die den E-Mail-Abruf
absichern. Häufig werden diese jedoch aus Bequemlichkeitsgründen nicht angewendet.
1.5.5 IMAP (Internet Message Access Protocol)
RFC 3501, RFC 1064,
RFC 1203, RFC 1730
Genau wie die beiden vorher beschriebenen Protokolle SMTP und POP3 basiert
IMAP ebenfalls auf der US-ASCII-Zeichenkodierung. Es ist aktuell in RFC 3501
(Crispin [2003]) als Version 4 Revision 1 spezifiziert und für den Datentransfer
vom Server zum Client konzipiert. IMAP wurde erstmals in RFC 1064 (vgl. Crispin
[1988]) im Jahr 1988, damals noch unter dem Namen Interactive Mail Access
Protocol, veröffentlicht. Das direkt in Version 2 erschienene Protokoll galt jedoch
genauso wie die später in RFC 1203 veröffentlichte Version 3 (vgl. Rice [1991])
als experimentell. Erst mit der im Jahr 1994 in RFC 1730 (vgl. Crispin [1994])
veröffentlichten Version 4, die dann den finalen Namen Internet Message Access
Protocol trug, wurde das Protokoll als Standard definiert.
IMAP wurde so geplant und entwickelt, dass Nutzer ihre E-Mails nicht mehr wie
bei POP3 vom Server zum Client transferieren und gleichzeitig auf dem Server
löschen, sondern die E-Mails, Ordnerstrukturen und Einstellungen bleiben auf
dem Server, damit diese von unterschiedlichen Computern desselben Benutzers
genutzt werden können. Abbildung 1.7 auf Seite 44 zeigt dazu eine Beispiel-IMAPSitzung.
Gegenüber POP3 bietet IMAP verschiedene Vorteile, die im Folgenden näher
betrachtet werden.
Seite 29
Permanente Verbindung
Da bei IMAP die Daten auf dem Server bleiben, bietet das Protokoll die Möglichkeit,
dass der Client durchgehend mit dem Server verbunden ist. Dadurch bedingt
können dem Client neue Nachrichten sofort angezeigt werden. Die Verbindung
bleibt offen und muss somit nicht - wie bei POP3 - zu jeder Abholung von neuen
Nachrichten neu aufgebaut werden. Nachrichten werden dann auf den Client
heruntergeladen, sobald dieser sie anfordert. Je nach Konfiguration des Clients
kann eine neue Nachricht sofort heruntergeladen werden. Es ist aber auch möglich,
dass nur die Betreffzeile an den Client übergeben wird und der Benutzer das
Herunterladen der Nachricht anstößt.
Mehrere Clients pro Konto
POP3 ist dahingehend beschränkt, dass sich pro Konto nur ein Client anmeldet
sollte. Innerhalb der Sitzung werden die neuen Nachrichten heruntergeladen
und anschließend, nachdem der Client den QUIT-Befehl gesendet hat, auf dem
Server gelöscht. Dieses Verhalten kann zu Problemen führen, sofern sich für ein
Konto mehr als nur ein Client anmeldet. SMTP geht dieses Problem direkt an und
spezifiziert mehrere gleichzeitige Verbindungen an ein Benutzerkonto. Dabei wird
sogar ein Mechanismus beschrieben, der die Clients untereinander informiert,
sobald einer der Clients eine Änderung vollzogen hat.
Zugriff auf einzelne Bestandteile der E-Mail
POP3 spezifiziert den Befehl RETR n, der eine komplette Nachricht vom Server
auf den Client herunterlädt. E-Mails, die mehrere Anhänge beinhalten, können
dadurch nur komplett heruntergeladen werden. Im Gegensatz dazu besteht bei
IMAP die Möglichkeit, einzelne Anhänge gezielt herunterzuladen, ohne dass die
gesamte Nachricht heruntergeladen werden muss.
Verwendung von Kennzeichen
Durch die Verwendung von sogenannten Kennzeichen (engl.: flags), die für IMAP
definiert sind, kann ein Client einer E-Mail bestimmte Statusinformationen anhängen. So können die E-Mails auf dem Server bspw. als gelesen oder wichtig markiert
werden.
Erstellung von Unterkonten und Zuweisung von Zugriffsrechten für
andere Nutzer
Zur Strukturierung der E-Mails auf dem Server können Nutzer eigene Unterkonten
anlegen, die im Client als Ordner angezeigt werden. Zwischen verschiedenen
Ordnern können E-Mails kopiert oder verschoben werden. Es existiert auch eine
Möglichkeit, anderen Nutzern den Zugriff auf ein eigenes Unterkonto zu geben,
was in RFC 4314 (vgl. Melnikov [2005]) beschrieben wird. Dieses Vorgehen ist
jedoch optional und muss von der Software auf dem Server implementiert und
vom Betreiber freigeschaltet sein, damit es genutzt werden kann.
Suchfunktion auf dem Server
Es existiert eine Funktion, bei welcher der Client den Server darum bitten kann,
seine E-Mails nach bestimmten Kriterien zu durchsuchen. Dadurch bedingt muss
RFC 4314
Seite 30
der Client nicht alle E-Mails zuerst herunterladen, bevor er mit der Suche anfangen
kann, sondern erhält sofort die passenden Treffer.
Schnittstelle für Erweiterungen
Die aktuelle Version 4 von IMAP bietet explizit einen Mechanismus, um Erweiterungen einzubauen.
IMAPS, RFC
2595, RFC 3207
Grundsätzlich hat IMAP allerdings auch Probleme bzgl. Sicherheit, genauso wie
auch SMTP und POP3. Sowohl die Datenübertragung als auch die Authentifizierung des Nutzers finden im Klartext statt. Dabei hat der Server allerdings
die Möglichkeit, die Authentifizierung des Nutzers zu unterbinden, solange die
Verbindung nicht verschlüsselt wurde. Um die Verbindung zu verschlüsseln existieren zwei Möglichkeiten. Zum einen kann IMAPS verwendet werden. Hier wird
schon während des Verbindungsaufbaus die Verbindung transparent per TLS
verschlüsselt (vgl. Newman [1999]). Zum anderen besteht die Möglichkeit, eine
bereits bestehende unverschlüsselte Verbindung mithilfe des STARTTLS-Befehls
(vgl. Hoffman [2002]) in eine verschlüsselte Verbindung zu überführen.
1.5.6 DNS (Domain Name System)
RFC 1034, RFC 1035
Das Domain Name System (DNS) ist eines der wichtigsten Systeme zur Nutzung
des World Wide Web. Da es für einige Maßnahmen zur Abwehr von Spam benötigt wird, die in Studienbrief 3 ab Seite 69 behandelt werden, wird es hier kurz
vorgestellt. DNS wird innerhalb der RFCs 1034 (vgl. Mackapetris [1987a]) und 1035
(vgl. Mackapetris [1987b]) definiert und beschreibt, wie einzelne Computer im
Internet ausfindig gemacht werden können.
RFC 1180, RFC
791, RFC 1349,
RFC RFC
791
2460, RFC 2474
Das im Internet verwendete TCP/IP (vgl. Socolofsky and Kale [1991]) setzte auf
numerische Adressen, um Computer zu erreichen. Diese werden bei IPv4 (vgl. Information Sciences Institute, University of Southern California [1981] und Almquist
[1992]) durch vier jeweils 8 Bit große Blöcke definiert, die durch Trennpunkte unterteilt werden und im dezimalen Zahlensystem dargestellt einen Wert zwischen
0 und 255 annehmen können. Daher sind maximal 232 = 4.294.967.296 Adressen möglich. Eine Adresse hat damit bspw. die lesbare Form 192.168.10.1. Der
Nachfolger von IPv4 ist IPv6 (vgl. Deering and Hinden [1998] und Nichols et al.
[1998]). Hier werden nicht 32 Bit zur Adressierung verwendet sondern 128 Bit.
IPv6-Adressen werden aufgrund der Länge allgemein nicht mehr im dezimalen
System sondern im hexadezimalen System dargestellt. Dazu werden acht jeweils 16
Bit lange Blöcke verwendet, die durch einen Doppelpunkt unterteilt werden. Eine
IPv6-Adresse hat bspw. die Form 20c1:0ab8:85b3:08d3:1319:8b2f:a470:7324.
Es ergibt sich damit ein möglicher Adressraum von 2128 ≈ 3, 4 × 1038 was einer
Vergrößerung gegenüber IPv4 um den Faktor 296 ≈ 7, 9 × 1028 entspricht. IPv4
war einst der Standard und sollte bereits seit Jahren durch IPv6 abgelöst werden.
Der Grund dafür, dass IPv4 nicht mehr ausreichend ist, ist das rasante Wachstum
der an das Internet angeschlossenen Geräte. Die ca. 4,3 Milliarden verfügbaren
Adressen sind daher nicht mehr genug, wodurch eine neue Art der Adressierung
notwendig wird. Dies ist das seit langem spezifizierte IPv6, bei dem der verfügbare
Adressraum so groß ist, das für jeden Quadratmillimeter der Welt ca. 600 Billarden
Adressen zur Verfügung stehen (vgl. Nieschwietz [2011]).
Wie weiter oben beschrieben, hat DNS die Aufgabe, Computer im World Wide Web
zu finden. Dies ist notwendig, da Computer eine numerische Adresse bekommen,
es aber für Menschen einfacher ist, sich eine auf Text-basierende Adresse zu merken
und auch Rückschlüsse über den Inhalt zu ziehen. Die Adresse 141.87.109.3 bietet
nur für sehr wenige Menschen Information darüber, was auf der Seite zu finden
Seite 31
ist. Der damit verbundene Name open-c3s.de ist dagegen allerdings einprägsam
und hat zumindest für die Leser dieses Studienbriefes eine Semantik.
Die in Studienbrief 3 beschriebenen Anti-Spam-Techniken verwenden DNS, um
Informationen über die Absenderadresse einer E-Mail zu erhalten. Daraus soll
erkannt werden, ob es sich bei dem Versender um einen bekannten Spammer
handelt oder nicht. DNS-basierte Blacklists enthalten genau solche Informationen
und werden ständig aktualisiert.
Mehr Informationen dazu folgen allerdings in Abschnitt 3.5.1 ab Seite 72.
Nachdem in diesem Abschnitt die wichtigen Protokolle für die E-MailKommunikation vorgestellt wurden, sollen die Kontrollaufgaben im folgenden
Abschnitt das Gelernte festigen.
beitragen sollen.
Kontrollaufgabe 1.5: Modellentscheidung
Welche Konsequenzen ergeben sich für Sender und Empfänger, falls das
Peer-to-Peer-Modell anstelle des Client-Server-Modells verwendet werden
würde?
Kontrollaufgabe 1.6: Beschränkung der Zeilenlänge innerhalb von EMails
K
K
Welche maximale Zeilenlänge wird für E-Mails empfohlen, welche Zeilenlänge muss eingehalten werden? Welchen Grund gibt es für diese Beschränkungen?
Kontrollaufgabe 1.7: Anzahl der to Header Felder einer E-Mail
Betrachten Sie die RFC 5322 (Resnick [2008]). Wie groß ist die minimale
Anzahl der Empfänger? An wen können E-Mails versendet werden, wenn
die minimale Anzahl an Empfängern verwendet wird?
Kontrollaufgabe 1.8: Verwendung von SMTP
Zu welchem Zweck wird SMTP verwendet?
Kontrollaufgabe 1.9: Base64 Kodierung
Beschreiben Sie, warum die Base64 Kodierung kein Ersatz für eine Verschlüsselung darstellt.
K
K
K
Seite 32
K
K
K
K
K
K
K
K
Kontrollaufgabe 1.10: SMTP Auth
Was passiert bei der SMTP-Auth Variante PLAIN mit dem Passwort und dem
Benutzername? Warum ist diese Möglichkeit der Authentifizierung nicht
sicher?
Kontrollaufgabe 1.11: POP3 Server Rückmeldungen
Welchen Zweck verfolgen positive bzw. negative Rückmeldungen des Servers?
Kontrollaufgabe 1.12: POP3 Befehl: LIST und RETR
Was ist der Unterschied zwischen den beiden POP3 Befehlen LIST und
RETR?
Kontrollaufgabe 1.13: POP3 Befehl: DELE
Welche Konsequenz hat der DELE-Befehl für eine bestimmte E-Mail?
Kontrollaufgabe 1.14: POP3 Befehl: NOOP
Wozu wird der NOOP-Befehl verwendet? Gibt es POP3-Implementierungen,
die diesen Befehl überflüssig machen?
Kontrollaufgabe 1.15: Verwendung von IMAP
Zu welchem Zweck wird IMAP eingesetzt?
Kontrollaufgabe 1.16: Schächen von IMAP
An welchen Stellen bestehen bei IMAP Schwächen und wie wird versucht
diese zu beheben?
Kontrollaufgabe 1.17: DNS
Was ist DNS, wozu wird es benötigt, und was hat es mit Spam zu tun?
1.6 Anreize und Motivation der Spammer
In diesem Abschnitt soll nur kurz auf die Motivation der Spammer eingegangen
werden, da Studienbrief ?? ab Seite ?? dazu genauere Informationen enthält.
Der allgemeine Konsens zu Spam besteht darin, dass alle Empfänger Spam als
hinderlich empfinden und oftmals gelernt haben, damit zu leben. Obwohl automatische Mechanismen einen Großteil des Spams aus den Postfächern herausfiltern,
kann es trotzdem hin und wieder passieren, dass eine Spam-Nachricht nicht als
1.7 Wirtschaftliche Aspekte
solche erkannt wird, was nur hinderlich ist. Es kann jedoch auch passieren, dass
eine E-Mail als Spam erkannt wird, was dann schädlich sein kann, wenn die E-Mail
wichtige Informationen enthält und der Empfänger sie nie erhalten hat.
Die Frage, die hier gestellt werden kann, ist warum Spam überhaupt existiert
und welchen Nutzen hat er. Die Antwort auf diese Frage ist relativ simpel: Für
die Versender von Spam stellt Spam eine Einnahmequelle dar. Spam enthält sehr
oft Werbung und wenn diese Werbung geschickt genug an den Empfänger gebracht wird, passiert es erstaunlicherweise häufig, dass unbedarfte Empfänger
die Produkte, die angepriesen werden, kaufen. Die Informationen, die mittels
Spam übertragen werden, können auch einen Betrugsversuch darstellen, der zum
Betrug wird, sobald der Empfänger an die falschen Informationen glaubt und
die im Spam geforderten Aktionen ausübt. Ebenfalls wird Spam dazu benutzt,
um einen Identitätsdiebstahl zu begehen. Ahnungslose Empfänger glauben, dass
eine Spam-Nachricht wirklich von ihrer Bank gekommen ist und geben PIN und
TAN oder Kreditkartennummer an Betrüger heraus (vgl. Phishing in Abschnitt 1.9
ab Seite 36). Weiterhin wird Spam auch benutzt, um Schadsoftware auf andere
Rechner zu übertragen, damit diese bspw. Teil eines Botnetzes werden.
In all diesen Fällen geht es den Spammern jedoch darum, Geld zu verdienen.
Spam-Nachrichten, bei denen nicht erkennbar ist, wie deren Versender damit Geld
verdienen können, weil die Nachrichten bspw. keinen Text enthalten, basieren
häufig auf Programmierfehlern des Versenders.
Um die in diesem Abschnitt angesprochene Motivation für Spammer näher auszuführen, wird in Abschnitt 1.8 eine Fallstudie besprochen, die im Jahr 2011 in den
USA durchgeführt wurde.
Vorher werden im nächsten Abschnitt allerdings wirtschaftliche Aspekte angesprochen.
1.7 Wirtschaftliche Aspekte
Wirtschaftliche Aspekte lassen sich in zwei Kategorien einteilen. Auf der einen
Seite sind dies Kosten, die durch Spam und die daraufhin eingeleiteten Abwehrmaßnahmen entstehen. Auf der anderen Seiten entstehen aber auch Gewinne bei
den Versendern von Spam, die den finanziellen Ertrag als Ziel und den versendeten
Spam als Mittel zum Erreichen des Ziels ansehen.
1.7.1 Durch Spam entstehende Kosten
Die Kosten, die durch Spam verursacht werden, entstehen wiederum in zwei Bereichen. Zum einen handelt es sich um Personalkosten, sofern das E-Mail-Konto
zu einem Unternehmen gehört. Gehört das E-Mail-Konto einer Privatperson, so ist
die Zeit, die der Empfänger zum Aussortieren der unerwünschten Nachrichten
benötigt, zwar ein Verlust an Lebenszeit, dieser Verlust kann jedoch finanziell
nicht genau beziffert werden und somit ist in diesem Bereich eine Aussage zu
den entstandenen Kosten schwierig. Gehört das Konto aber zu einem Unternehmen, so kann untersucht werden, wie lange ein Mitarbeiter für das Erkennen und
Aussortieren von Spam täglich benötigt. Es gibt viele Untersuchungen, die unterschiedliche Ergebnisse liefern. Nucleus Research Incorporated [2004] kommt
bspw. im Jahr 2004 zu dem Ergebnis, dass Spam in den USA pro Mitarbeiter und
Jahr durchschnittlich $1,934 kostet. Festgehalten werden kann aber, dass Spam den
Empfänger Geld kostet, auch wenn es für den genauen Betrag auf die konkrete
Situation ankommt.
Seite 33
Seite 34
Neben den Personalkosten entstehen aber auch weitere Kosten bei der Infrastruktur.
Dies kann zum einen bei dem Unternehmen sein, dass Spam empfängt und eigene
E-Mail-Server betreibt, oder zum anderen beim Internet Service Provider. Topf et al.
[2005] gehen dabei auf konkrete Zahlen ein und unterteilt nach Großprovider, Provider, Großunternehmen, mittelständisches Unternehmen und Kleinunternehmen
bzw. Einzelunternehmen.
Ab ca. 3 Millionen verwalteten Postfächern spricht die Studie von einem Großprovider, der im Normalfall pro Tag im Durchschnitt etwa 5 Spam-Nachrichten pro
Postfach erhält. Damit beläuft sich das gesamte Spam-Aufkommen auf 15 Millionen
Spam-Nachrichten in dem genannten Zeitraum. Um wettbewerbsfähig zu sein und
auch zu bleiben, muss sich ein Großprovider um entsprechende Schutzmaßnahmen kümmern. Diese bestehen in der Regel aus einem mehrstufigen Filtersystem
mit selbst entwickelter Software oder stark angepassten Lizenzprodukten. Doch
nicht nur die Infrastruktur zur Ausfilterung von Spam muss vorhanden sein, sondern es müssen auch die bereits vorhandenen Datenverbindungen für die erhöhten
Anforderungen ausgelegt sein. In Topf et al. [2005] wird ein Datenverkehr von
ca. 128 TB pro Jahr berechnet, der ausschließlich dazu verwendet wird, um die
Spam-Nachrichten zu transportieren. Die Anbindung muss daher entsprechend
angepasst sein, damit es nicht bei erwünschten E-Mails zu Engpässen kommt.
Doch nicht nur die Kapazitäten für den Datenverkehr müssen entsprechend angepasst sein, auch die vorhandenen Speichersysteme müssen für die zusätzliche
Speicherung der Spam-Nachrichten geeignet ausgelegt werden. Der genannte Bericht geht hier von einem zusätzlichen Speicherbedarf von drei TB pro Tag aus. Aus
Sicht des Großproviders ist es nicht möglich, die als Spam erkannten Nachrichten
zu blocken oder zu löschen, vielmehr müssen diese gesondert dem Nutzer zur
Verfügung gestellt werden, damit dieser ggf. falsch erkannte Nachrichten identifizieren und retten kann. Daher sind mind. 75 % der Gesamtkosten begründet
durch die für die Verarbeitung von Spam bereits zu haltende Infrastruktur. Konkret
entstehen Kosten in Höhe von ca. 1,4 Millionen Euro, was den Preis für eine einzige
Spam-Nachricht auf 0,026 Cent festlegt.
Für kleinere Provider mit 50.000 verwalteten Postfächern wird ein Betrag von 0,2
Cent pro Spam-Nachricht ausgerechnet. Dies ist dadurch begründet, dass kleinerer
Provider in Relation zu Großprovidern deutlich größere Personalkosten haben.
Für ein Großunternehmen sind die Kosten dagegen anders verteilt. Da in diesen Unternehmen die gesamte IT-Infrastruktur oftmals groß genug ausgelegt ist, müssen
keine weiteren Puffer für Spam eingeplant und finanziert werden. Es bedarf jedoch
an Lizenz- und Personalkosten. Gerade die Personalkosten sind hier sehr groß,
da davon ausgegangen werden muss, dass Mitarbeiter durch Spam-Nachrichten
von ihrer produktiven Arbeit abgehalten werden, um die Spam-Nachrichten per
Hand auszusortieren, die automatische Softwarelösungen nicht erkannt haben.
Werden keine Softwarelösungen zu Erkennung von Spam-Nachrichten eingesetzt,
so belaufen sich die Kosten auf 18 Cent pro Spam-Nachricht. Werden hingegen Softwarelösungen eingesetzt, so müssen dafür zusätzliche Lizenzen bezahlt werden.
Bedingt durch eine entsprechende Trefferquote, belaufen sich die Kosten jedoch
nur auf 4 Cent pro Spam-Nachricht, was jedoch immer noch im Vergleich zu den
Providern sehr viel ist.
Bei mittelständischen Unternehmen oder Kleinunternehmen ergeben sich sehr
ähnliche Werte.
1.8 Fallstudie „Click Trajectories: End-to-End Analysis of the Spam Value Chain“
Seite 35
1.7.2 Erlös für Spam-Verursacher
Der Erlös für Spammer ist sehr unterschiedlich und lässt sich nicht exakt bestimmen. Auch hier existieren Untersuchungen, die den Erlös für Spammer ausrechnen.
In Topf et al. [2005] wird bspw. von 1.400 Euro als Erlös für das Versenden von 1 Millionen Spam-Nachrichten ausgegangen, wobei nur 0,01 % der Werbenachrichten
zu einer Bestellung von Produkten durch den Spam-Empfänger führen.
Im weiteren Verlauf der Studienbriefe werden in anderen Abschnitten weitere
Arbeiten betrachtet und mit dem Ergebnis dieser Arbeit verglichen.
In diesem Abschnitt befinden sich verschiedene Kontrollaufgabe, welche die Inhalte
der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffes beitragen
sollen.
Kontrollaufgabe 1.18: Kosten für Spam
Durch welche Faktoren entstehen Kosten für den Empfänger von Spam?
Kontrollaufgabe 1.19: Profit Spamversand
Wie profitieren die Versender vom Spam?
1.8 Fallstudie „Click Trajectories: End-to-End Analysis of the
Spam Value Chain“
In Levchenko et al. [2011] beschäftigen sich die Autoren mit Spam-basierter Werbung als Geschäftsmodell. In vielen anderen Veröffentlichungen steht die Erkennung und Bekämpfung von Spam auf technischer Ebene im Vordergrund, hier
wird die Spam-Problematik allerdings auf einer abstrakteren Ebene angegangen.
Obwohl es eine allgemeine Antipathie der Gesellschaft gegen Spam gibt und trotz
der Industrie, die jährlich hohe Summen in die Bekämpfung von Spam steckt, ist
Spam immer noch ein großes Problem und es scheint keine Lösung in Sicht zu sein.
Daher haben sich die Autoren mit dem Geschäftsmodell hinter Spam beschäftigt,
um die genauen Zusammenhänge zu verstehen, da sie der Anti-Spam-Industrie
vorhalten, dass diese sich nur mit wenigen Aspekten der Wertschöpfungskette von
Spam auseinandersetzen. Dazu zählen die Spam-Filterung (vgl. Abschnitt 3.4 ab
Seite 69), das URL-Blacklisting (vgl. Abschnitt 3.5.1 ab Seite 72) und das vom Netz
nehmen von Servern (vgl. Abschnitt 3.12 ab Seite 95). Ziel der Untersuchung war
es, die Wertschöpfungskette (vgl. Abbilding 1.8) genau zu verstehen, um einzelne
Punkte ausfindig zu machen, die einen gezielten Eingriff zur Verminderung von
Spam ermöglichen. Dazu haben die Autoren zuerst untersucht, wo der Ursprung
von Spam liegt und sind dabei auf Botnetze (vgl. Abschnitt 2.9 ab Seite 61), Webmailer (vgl. Abschnitt 2.7 ab Seite 58) und IP Prefix Hijacking (vgl. Abschnitt 2.8
ab Seite 60) gestoßen.
Um nun zu erfahren, wie man mit vergleichsweise wenig Aufwand das System
der Spammer lahmlegen kann, haben die Autoren untersucht, auf welchem Weg
das Geld transferiert wird, das bei Einkauf von per Spam beworbenen Produkten den Besitzer wechselt. Dazu gruppierten die Autoren zuerst die einzelnen
Shop-Adressen, die sie durch die Spam-Nachrichten bekamen, um die größten
Kampagnen zu finden. Daraufhin versuchten die Autoren bei 120 Shops einen
K
K
Seite 36
Einkauf zu tätigen, von denen allerdings nur 76 Käufe erfolgreich waren. In Kooperation mit der Bank, deren Kreditkarte sie nutzen, erfuhren sie, welche Banken
mit den Versendern von Spam zusammenarbeiten und aus welchen Ländern diese
kommen. Letztendlich stellte sich bei der Untersuchung heraus, dass die Banken der Spammer als Flaschenhals für deren Geschäftsmodell angesehen werden
können. Nur wenige kleinere Banken arbeiten mit Spammern zusammen und
sofern die großen Banken nicht mehr Kreditkartenüberweisungen an diese Banken
durchführen, ist es möglich, das Geschäftsmodell der Spammer empfindlich zu
stören. So wäre es möglich, mit nur relativ kleinen Eingriffen, die Menge an Spam
deutlich zu verringern, da das Ziel der Spammer das Verdienen von Geld ist und
der Geldfluss so beeinflusst werden könnte.
1.9 Phishing
Es existiert Spam, dessen Intention nicht in der Verbreitung von Werbung liegt,
sondern zur Erlangung von persönlichen Daten führen soll. Diese Form des Spams
wird als Phishing bezeichnet. Phishing ist ein Kunstwort, das vom englischen
fishing (dt.: angeln) und dem Begriff Phreaking, der ein Kofferwort bestehen aus
den englischen Begriffen phone (dt.: Telefon) und freak (Person, die sich nicht ins
normale bürgerliche Leben einfügt, die ihre gesellschaftlichen Bindungen aufgegeben hat,
um frei zu sein vgl. Duden Redaktion) [2012b]), abgeleitet wird. Der Duden (Duden
Redaktion) [2012c]) definiert Phishing als Beschaffung persönlicher Daten anderer
Personen (wie Passwort, Kreditkartennummer o. Ä.) mit gefälschten E-Mails oder Websites.
Konkret wird also von Kriminellen Spam versendet, der den Anschein erweckt,
es handele sich um eine offizielle E-Mail von einer Bank oder Behörde. Innerhalb
dieser E-Mail wird der Kunde dazu aufgefordert, im Internet eine Seite zu besuchen,
um dort bestimmte Daten einzugeben oder zu aktualisieren. Diese Seite wiederum
erweckt auch den Anschein, als wäre sie die echte Seite der Bank oder Behörde,
jedoch handelt es sich dabei um eine Kopie der offiziellen Seite. Verlangt wird dann
nach Kreditkartennummern oder Zugangsdaten für Online Banking Konten.
In letzter Zeit treten auch vermehrt Phishing-Versuche auf die Konten der Spieler
von beliebten Online-Spielen auf (vgl. Zuljevic [2009], Lien [2012] und Osena
[2012]). Dabei werden die Benutzer durch eine Phishing-E-Mail auf eine gefälschte
aber echt aussehende Seite des Online-Spiels geleitet, um dort ihre Account-Daten
einzugeben. Die daraus gewonnenen Daten werden dann auf dem Schwarzmarkt
verkauft, um an die virtuelle Währung des Spieler zu gelangen. Das virtuelle Geld
wird dann an andere Konten übertragen, um es bspw. im Spiel an andere Spieler
zu verkaufen.
Es gibt automatische Schutzmechanismen, die in Webbrowsern oder E-Mail-Clients
eingebaut sind. Dabei kann die Software untersuchen, ob der Nutzer eine Webseite besucht, deren URL (Uniform Resource Locator) bestimmte Schlüsselwörter
enthält, oder ob die Seite von anderen Benutzern bereits als verdächtig gemeldet
wurde. Ebenfalls können Zertifikate erkannt werden, die von keiner offiziellen und
vertrauten Zertifizierungsstelle unterschrieben wurden. Dhamija et al. [2006] beschreiben dazu, die Gründe, warum Phishing funktioniert, vgl. dazu auch Zuljevic
[2009].
Der beste Schutz vor Phishing-Angriffen ist daher immer noch die eigene Wachsamkeit und gesunder Menschenverstand. Es sollte klar sein, dass eine Bank nie
nach Daten fragt, die sie entweder schon hat oder die sie nicht benötigt. Ebenso
sollte beachtet werden, dass die Orthographie oder Interpunktion in PhishingE-Mails in den seltensten Fällen korrekt ist und sich Phishing-E-Mails somit oft
leicht erkennen lassen. Im Zweifelsfall sollte sich der Empfänger immer vorher bei
1.10 Zusammenfassung
Seite 37
der anfragenden Stelle per Telefon oder persönlich versichern, dass die Anfrage
wirklich von dem entsprechenden Absender kommt.
Kontrollaufgabe 1.20: Phishing
Was wird unter der Bezeichnung Phishing verstanden und was hat dies mit
Spam zu tun?
K
In diesem Studienbrief wurden die Grundlagen für die folgenden Studienbriefe vermittelt. Beginnend mit einer Definition für E-Mails und Spam wurde die
Infrastruktur beschrieben, die für den Versand und das Empfangen von E-Mails
notwendig sind. Die dafür verwendeten Protokolle wurden detailliert betrachtet.
Die Motivation der Spammer für den Versand von Spam wurde kurz genannt
und zur Veranschaulichung wurde in einer Fallstudie gezeigt, wie Geld mit dem
Versand von Spam verdient werden kann und auch wie ohne technische Eingriffe
der Versand von Spam reduziert werden kann.
1.11 Übungen
Übung 1.1: Nachteile von E-Mails
Im ersten Abschnitt wurden einige Vorteile von E-Mails gegenüber normaler
Post aufgeführt. Können Sie sich vorstellen, dass es auch Nachteile gegenüber
normaler Post gibt, außerhalb von Spam?
Übung 1.2: Leerzeilen in E-Mails
Finden Sie heraus, wie eine Leerzeile in einen E-Mail-Body eingefügt werden
kann, ohne dass ein E-Mail-Programm die Leerzeile als Ende der E-Mail
interpretiert.
Übung 1.3: SMTP: CRAM-MD5
Betrachten Sie die CRAM-MD5-Authentifizierung als Erweiterung von
SMTP: Aus welchem Grund soll die im ersten Schritt vom Server an den
Client gesendete Zeichenkette möglichst einzigartig sein?
Ü
Ü
Ü
Seite 38
Ü
Übung 1.4: SMTP-Sitzung
Entspricht die folgende Sitzung der RFC 2821? Falls nein: In welchen Punkten gibt es Abweichungen?
220 m04.aul.t-home.de T-Online ESMTP receiver fssmtpd2025 ready.
220 T-Online ESMTP receiver ready.
ehlo meinhost.meinedomain.de
250-mailin04.aul.t-online.de ready.
250-SIZE 33554432
250 8BITMIME
250-ENHANCEDSTATUSCODES
250 HELP
rcpt to: <empfaenger1@t-online.de>
550 5.1.1 Unknown recipient.
mail from: <meineemailadress@meinedomain.de>
250 2.1.0 Sender accepted.
rcpt to: Hans Mueller <empfaenger2@t-online.de>
250 2.1.5 Recipient accepted.
Data
Here goes some data
.
quit
221 2.0.0 mailin04.aul.t-online.de closing.
221 2.0.0 Closing.
Connection closed by foreign host.
Ü
Übung 1.5: POP3-Sitzung
Verwenden Sie das Kommandozeilenprogramm Telnet, um sich mit einem
POP3-Server Ihrer Wahl zu verbinden. Gehen Sie dazu die in diesem Modul
beschriebenen Schritte durch und speichern Sie den Quelltext einer E-Mail
Ihrer Wahl. Vergleichen Sie den Quelltext der gespeicherten E-Mail mit dem
Quelltext, den Ihnen ein Programm wie Outlook oder Thunderbird zur
Verfügung stellt. Was können Sie dabei feststellen?
1.11 Übungen
Übung 1.6: Fehlerhafter E-Mail-Header
Betrachten Sie folgende E-Mail:
Seite 39
Ü
Date: 11 Nov 2009 13:47:07
Message-ID: <49197ECB.9030604hgi.rub.de>
From: "Christopher Wolf" <cbw@hgi.rub.de>
"Yvonne Roehrle-Schetz" <yvonne.r-s@ruhr-uni-bochum.de>,
To: HGI Office <hgi-office@rub.de>,
"Mario Rottorf" Mario.Rottorf@ruhr-uni-bochum.de
BCC: dip.farmacologia@unipd.it
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
Subject: Re: Dienstreise
Koblenz
References: <8E3FF01191314A94BB6A28C05411D310@p76>
<8V3Fa01314ABB6438658C05411D310@compi.it>
In-Reply-To: <8E3FF01191314A94BB6A28C05411D310@p76>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Sender: a@tv
Was genau in dieser E-Mail entspricht nicht dem Standard?
Übung 1.7: Base64-Kodierung
Betrachten Sie Exkurs 1.11 auf Seite 23. Wandeln Sie den Text „Hallo Welt!“
zuerst in dezimale Zeichen um und kodieren ihn anschließend in Base64
um.
Ü
Welchen US-ASCII-Text wird durch folgenden Base64-kodierten Text repräsentiert: „U3R1ZGllbmJyaWVmCg==“?
Übung 1.8: Base64-Kodierung: Speicherplatz
Berechnen Sie die Menge an Speicherplatz, die eine Zeichenkette der Länge
19.265 benötigt, wenn diese Base64-kodiert wird.
Übung 1.9: Nutzerauthentifikation bei POP3
Betrachten Sie den APOP Befehl von POP3. Können Sie sich unter der Annahme, dass die vom Server verschickten Zeitstempel nicht einzig sind,
einen Angriff vorstellen, bei dem der Angreifer Zugriff auf ein bestimmtes
Benutzerkonto erlangt?
Ü
Ü
Seite 40
Ü
Ü
Ü
Ü
Ü
Übung 1.10: IMAP vs. POP3
Nennen und beschreiben Sie drei Vorteile, die IMAP gegenüber POP3 bietet.
Übung 1.11: IMAP vs. POP3, mehrere Anmeldungen an das gleiche Konto
Was kann konkret passieren, wenn sich mehrere Benutzer per POP3 an das
gleiche Konto anmelden? Wie umgeht IMAP dieses Problem?
Übung 1.12: SMTP-Fehlercodes
Betrachten Sie die RFCs 821 und 5321 (vgl. Postel [1982], Klensin [2008]):
Welcher Fehlercode wurde fälschlicherweise in RFC 821 definiert und durch
RFC 5321 korrigiert, sofern ein Client mehr Empfänger-Adressen in einer
E-Mail angegeben hatte als der empfangende Server unterstützt?
Übung 1.13: DNS (Domain Name System)
Eine DNS-Anfrage löst einen Namen in eine IP-Adresse auf. Finden Sie heraus, ob es einen Dienst gibt, der zu einer IP-Adresse die damit verbundenen
Namen zurückgibt. Warum ist ein solcher Dienst sinnvoll?
Übung 1.14: Fallstudie „Click Trajectories: End-to-End Analysis of the Spam
Value Chain“
Betrachten Sie Levchenko et al. [2011] und finden Sie heraus, warum nicht
alle der 120 Käufe erfolgreich waren.
Ü
Übung 1.15: Phishing
Betrachten Sie Dhamija et al. [2006] und benennen Sie die drei Gründe sowie
deren Details, die für den Erfolg von Phishing verantwortlich sind.
1.11 Übungen
Seite 41
Client
Server
Wartet auf Verbindungsauf
--Verbindungsaufbau
220 service ready
HELO clientname.example.net
250 ok
MAIL FROM:<sender@example.org>
250 ok
RCPT TO:<empfaenger@example.org
250 ok
DATA
354 start mail input
From: <sender@example.org>
To: <empfaenger@example.org
Date: Fri, 28 Nov 1997 09:54:05 +0100
Das ist eine Beispiel E-Mail.
Diese E-Mail enthaelt keinen sinnvollen Text.
.
250 ok
QUIT
221 closing channel
Abb. 1.4: UMLSequenzdiagramm einer
SMTP-Sitzung.
Seite 42
Abb. 1.5: UMLZustandsdiagramm
einer POP3-Sitzung.
WAITING_FOR_CONNECTION
Verbindungsaufbau
AUTHORIZATION
Client Identifikation am Server
TRANSACTION
Aktionen ausführen
Client sendet QUIT Kommando
UPDATE
CLOSE
Verbindung getrennt
1.11 Übungen
Seite 43
Client
Server
Wartet auf Verbindungsaufbau
--Verbindungsaufbau
+OK example.com POP3-Server
USER benutzer@example.org
+OK Please enter password
PASS passwort_im_klartext
+OK mailbox locked and ready
STAT
+OK 1 236
LIST
+OK mailbox has 1 message (236 octets)
1 236
.
RETR 1
+OK message follows
Date: Fri, 28 Nov 1997 09:54:05 +0100
From: <sender@example.org>
To: <empfaenger@example.org
Das ist eine Beispiel E-Mail.
Diese E-Mail enthaelt keinen sinnvollen Text.
.
DELE 1
+OK message marked for delete
QUIT
+OK bye
Abb. 1.6: UMLSequenzdiagramm einer
POP3-Sitzung.
Seite 44
Abb. 1.7: UMLSequenzdiagramm
einer IMAP-Sitzung.
Client
Server
Wartet auf Verbindungsaufbau
--Verbindungsaufbau
* OK IMAP4rev1 Service Ready
a001 login benutzername passwort
a001 OK LOGIN completed
a002 select inbox
* 18 EXISTS
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* 2 RECENT
* OK [UNSEEN 17] Message 17 is the first unseen message
* OK [UIDVALIDITY 3857529045] UIDs valid
a002 OK [READ-WRITE] SELECT completed
a003 fetch 12 full
* 12 FETCH (BODY[HEADER] {342}
Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
From: Terry Gray <gray@cac.washington.edu>
Subject: IMAP4rev1 WG mtg summary and minutes
To: imap@cac.washington.edu
cc: minutes@CNRI.Reston.VA.US,
John Klensin <KLENSIN@MIT.EDU>
Message-Id: <B27397-0100000@cac.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
)
a004 OK FETCH completed
a005 store 12 +flags \deleted
* 12 FETCH (FLAGS (\Seen \Deleted))
a005 OK +FLAGS completed
a006 logout
* BYE IMAP4rev1 server terminating connection
a006 OK LOGOUT completed
Abb. 1.8: Die für
eine einzige URLWertschöpfungskette
verwendete Infrastruktur aus Levchenko et al. [2011].
Seite 45
2.1 Lernergebnisse
Sie können die von Spammern genutzten Infrastrukturen, um Spam zu versenden
und Kapitel aus dem Versand zu ziehen, benennen und beschreiben. Darüber
hinaus können Sie verschiedene Arten von Spamtechniken unterscheiden und
wiedergeben, wie diese Techniken von Spammern verwendet werden. Sie sind in
der Lage, sich gegen Adress-Harvesting zu schützen.
Mittels welcher Techniken ist SPAM-Versand möglich? Auf welche Infrastruktur
greifen Spammer hier zurück? Wie kommt ein Spammer an gültige E-Mail Adressen und wie kann man sich als Nutzer dagegen wehren, dass die eigene E-Mail
Adresse in die Hände eines Spammers gelangt? Diese Fragen stehen im Mittelpunkt
dieses Studienbriefs.
2.3 Einleitung
In diesem Studienbrief werden Techniken vorgestellt, über die Spam in den EMail-Verkehr eingeschleust werden kann. Dabei wird hier ein chronologischer
Ablauf gewählt, der frühzeitig auf die zuerst verwendeten Methoden eingeht und
im späteren Verlauf zu immer ausgeklügelteren Techniken kommt. Bevor auf die
konkreten Methoden eingegangen wird, wird zuerst beleuchtet, wie Spammer
arbeiten und auch wie ihre Strukturen aufgebaut sind. Dabei wird insbesondere
auf Techniken zum Sammeln von Adressen und deren Abwehrmechanismen eingegangen. Als erste Methode zum Versand von Spam werden daraufhin offene
Mail-Relays behandelt. Obwohl der Grund für das Vorhandensein dieser Methode
ausschließlich darin lag, dass bei der Planung der E-Mail-Infrastruktur nicht mit
dem Missbrauch des Mediums E-Mail für Spam gerechnet wurde, konnte diese
Lücke relativ schnell geschlossen werden. Offene Proxies bieten ähnliche Möglichkeiten zum Versand von Spam an und wurden anfangs auch noch für diesen Zweck
missbraucht. Danach werden Mail-Formulare und Webmail behandelt und es wird
gezeigt, wie diese Dienste ausgenutzt wurden und auch noch aktuell von Spammern verwendet werden. Im Abschnitt über IP Prefix Hijacking wird eine erste
ausgeklügeltere Methode zum Versand von Spam vorgestellt, bevor die Abschnitte
über Malware und Botnetze den größten Ursprung von Spam beschreibt.
2.4 Spammer
Ursprünglich wurden Spam-Nachrichten von einzelnen Personen aus verschickt,
die dabei sehr einfache Techniken nutzten bzw. einfache Schwachstellen in Spezifikationen ausnutzten, wie im späteren Verlauf dieses Studienbriefs deutlich
wird. Um das Thema Spam hat sich aber, nachdem Spam als Problem erkannt
wurde, eine Industrie entwickelt, die jährlich Milliardenumsätze verbucht. Dazu
zählen auf der einen Seite Firmen, die Produkte entwickeln oder Dienstleistungen anbieten, um Spam-Nachrichten zu erkennen, um diese daraufhin zu filtern,
auszusortieren oder zu blockieren. Auf der anderen Seite stehen die Versender
von Spam, die immer professioneller vorgehen und sich zusammenschließen, um
effizienter und effektiver zu werden. Spammer sind mittlerweile so professionell
geworden, dass es sogar ein Register von bekannten Spam-Operationen (vgl. The
Spamhaus Project [2012a], Register of Known Spam Operations (ROKSO)) gibt,
das vom Spamhaus-Project gepflegt wird und Informationen zu verschiedenen
Gruppen auflistet, die sich um den Versand von Spam kümmern. Auf die Liste
kommen nur Gruppen, die bereits durch mindestens drei Internet Service Provider
ROKSO
Seite 46
(ISP) als Spammer erkannt wurden und deren Aktivitäten daraufhin durch diese
ISPs beendet wurde. Aktuell listet das Register 115 verschiedene Gruppen auf, die
aus Ländern verteilt über den gesamten Globus fungieren. Das Spamhaus-Project
gibt weiterhin an, dass ca. 100 Gruppen für etwa 80 % des Spamaufkommens in
Nordamerika und Europa verantwortlich sind und fast alle dieser Gruppen in dem
Register aufgelistet sind.
2.4.1 Spammer-Netzwerke
Es ist klar, dass Spammer die E-Mail-Infrastruktur verwenden, um Werbenachrichten zu verschicken. Es stellt sich aber die Frage, wie die sonstige Infrastruktur von
Spamversender genau aufgebaut ist, damit ihr Geschäft möglichst effektiv arbeitet.
In Sjouwerman and Posluns [2004] und McWilliams [2005] wird von Spammern
beschrieben, wie ihr Geschäftsmodell funktioniert und was dazu genau benötigt
wird. Dazu stellt Abbildung 2.1 den möglichen Aufbau eines Spammer-Netzwerks
da.
Abb. 2.1: Ein möglicher
Aufbau eines SpammerNetzwerkes (angelehnt
an Schober [2009]).
Partner
Affiliates
Affiliates
(Freie
(FreieMitarbeiter)
Mitarbeiter)
Spamversand,
Spamversand,
Harvesting
Harvestingusw.
usw.
Längerfristige
Infrastruktur
Bullet-Proof Server,
Bankkonten in
„sicheren“ Ländern
Gewinnbeteiligung
Hauptspammer
Adressdatenbank
Ankauf von Produkten
und Koordination des
Produktversands
nach erfolgtem Kauf
An/Verkauf
von
Adressen
AdressHändler
und andere
Spammer
Anmieten / Kauf von
Botnetzen zum Mailversand
Produzenten
und VersandDienstleister
Käufer
Adressdatenbank,
Bullet-Proof-Server
Kundenaufträge
für E-Mail Marketing
Botnetzbetreiber
Serviceanbieter
Adressdatenbank
Im Mittelpunkt der Abbildung steht der Hauptspammer, der zwei Ressourcen
benötigt. Das ist zum einen eine Adressdatenbank, die mit E-Mail-Adressen von
möglichen Empfängern gefüllt ist. Idealerweise enthält die Adressdatenbank nicht
nur die E-Mail-Adressen der Empfänger, sondern auch weitere persönliche Informationen wie Namen, Alter und ggf. Interessen. Diese persönlichen Informationen
können für den Hauptspammer wichtig sein, wenn er seine Werbebotschaften an
2.4 Spammer
Seite 47
die richtige Zielgruppe versenden möchte. Die Adressdatenbank ist für den Hauptpammer eine Ressource, die er nutzt, um Spam zu versenden, aber auch gleichzeitig
kann diese Datenbank direkt ein Einkommen erzeugen, indem Adressen an andere
Spammer oder Adresshändler verkauft werden. Um über eine möglichst große
Basis an Adressen zu verfügen, müssen entsprechend auch Adressen von anderen Spammern oder Adresshändlern angekauft werden. Adressen können vom
Hauptspammer auch direkt gesucht werden. Wie dies geschieht, wird im folgenden Abschnitt beschrieben. Als zweite Ressource muss der Hauptspammer über
längerfristige Infrastrukturen verfügen. Dies sind Server, auf denen verschiedene
Shops betrieben werden, die wiederum der Anlaufpunkt für interessierte Kunden sind. Erhält ein Empfänger eine Spam-Nachricht und interessiert sich für das
beworbene Produkt, so folgt er einem Link zum Shop des Versenders. An dieser
Stelle wäre ein Eingriff in die Infrastruktur des Spammers für die Justiz einfach. Es
würde ausreichen, wenn diese Server vom Internet getrennt würden, wodurch der
Spammer die Möglichkeit verlieren würde, einen Gewinn zu erwirtschaften. Aus
diesem Grund suchen und betreiben Spammer sogenannte Bullet-Proof-Server.
Dabei handelt es sich um Server, die bei Betreibern stehen, die wiederum nicht mit
der Justiz zusammen arbeiten. Dies können Server in Nordamerika oder Europa
sein, die sich nicht einfach vom Netz trennen lassen, da deren Hoster mit den
Spamversendern und nicht der Justiz zusammenarbeiten. Erst wenn alle Verbindungen zum Netz dieser Betreiber getrennt sind, kann der Bullet-Proof-Server
nicht mehr erreicht werden.
Neben der eigenen Infrastruktur beschäftigt ein Hauptspammer freie Mitarbeiter,
sogenannte Affiliates. Diese freien Mitarbeiter können sowohl für den Versand
von Spam als auch für das Sammeln von E-Mail-Adressen zuständig sein und
werden am Gewinn des Hauptspammer beteiligt. Der Hauptspammer kann zwar
seine freien Mitarbeiter zum Spamversand einsetzen, hat aber auch bedingt durch
seine Adressdatenbank selber die Möglichkeit, Spam zu versenden. Um einfachen
Erkennungsmöglichkeiten zu entkommen, werden für den Versand von Spam
generell Botnetze verwendet. Daher muss der Hauptspammer entweder selber über
Malware verfügen, die er auf verschiedenen Computern verbreitet, um ein Botnetz
zu betreiben. Es ist aber auch möglich, für Geld Botnetze zu mieten oder auch zu
kaufen. Dazu benötigt der Hauptspammer einen Kontakt zu Botnetzbetreibern.
Diese können ihm dann für einen bestimmten Preis eine feste Anzahl von Computer
zum Versand von Spam Nachrichten zur Verfügung stellen. Zum Ankauf von
Produkten und zur Koordination des Produktversandes nach einem erfolgten
Kauf benötigt ein Spamversender Kontakt zu den Produzenten der Produkte sowie
zu Versanddienstleistern, die sich um den Transport vom Produzent zum Kunden
kümmern. Diese interagieren dann mit den Käufern. Da der Hauptspammer mit
Produzenten und Versanddienstleistern interagiert und über eine Infrastruktur
zum Versand von Spam verfügt, ist es ebenso denkbar, dass er mit Serviceanbietern
in Kontakt tritt, die ihn beauftragen, bestimmte Kampagnen zu betreiben. Somit
vermietet der Hauptspammer seine Ressourcen an andere Anbieter.
Neben ihrer üblichen Infrastruktur und ihrer eigenen Kontakte haben viele Spammer allerdings auch noch Kontakte zu anderen Spammern. Die können dann als
Partner eine vergleichbare Infrastruktur aufweisen und bei komplexen Aufträgen
helfen.
2.4.2 Adress-Harvesting
Der Versand von Spam ist für Spammer denkbar einfach. Nachdem im vorherigen
Abschnitt vorgestellt wurde, wie die Infrastruktur vom Spamversender aufgebaut ist, stellt sich allerdings noch die Frage, wie genau Spammer ihre E-MailAdressdatenbanken füllen. Allgemein wird das Suchen von E-Mail-Adressen als
Affiliate, Botnetz
Seite 48
Adress-Harvesting bezeichnet. Für das Adress-Harvesting gibt es unterschiedliche
Techniken bzw. Methoden, die im Folgenden näher beschrieben werden.
Ankauf oder Tausch
Die einfachste Methode ist sicherlich der Ankauf von Adresshändlern, anderen
Spammern oder Serviceanbietern. Dabei ist die günstige Methode der Austausch
mit anderen Spammern. Doch insgesamt muss es eine Quelle für korrekte und
und aktuelle E-Mail-Adressen geben, egal ob gekauft oder getauscht wird. Dazu
stellen die folgenden Abschnitte verschiedene Techniken vor.
Harvesting Bots
Oft benutzen die Versender von Spam Botnetze, damit sie auf der einen Seite eine
Vielzahl an Spam-Nachrichten verschicken können und es auf der anderen Seite
schwer möglich ist, den Spam aufgrund der IP-Adresse des Versenders zu identifizieren. Genau diese Bots können auch dazu genutzt werden, E-Mail-Adressen
zu sammeln. Dabei können die Bots sowohl sich selber, also den Inhalt des infizierten Computers durchsuchen. So finden die Bots bspw. Adressbücher aus
E-Mail-Programmen. Andererseits können die Bots aber auch auf der Suche nach
potenziellen E-Mail-Adressen das WWW durchforsten. Dabei durchsuchen die Bots
das WWW ähnlich wie Webcrawler. Im Gegensatz zu Webcrawlern werden sie aber
nicht zum Indizieren von Webseiten verwendet, sondern suchen mittels regulärer
Ausdrücke nach E-Mail-Adressen. Diese E-Mail-Adressen können sich innerhalb
von HTML-Dokumenten befinden, genauer gesagt, können es Seiten von Foren
sein, bei denen Mitglieder ihre E-Mail-Adresse zur Kommunikation hinterlassen.
Es können weiterhin auch Webseiten von Firmen sein, die ein Impressum verfassen
müssen und dort eine E-Mail-Adresse angeben oder auch generelle Kontaktdaten,
die von einzelnen Webseitenbetreibern zur Verfügung gestellt werden. Alternativ
können natürlich auch andere Teil des WWWs durchsucht werden. Dazu gehören
bspw. Bilder oder auch PDF-Dokumente, in denen nach E-Mail-Adressen gesucht
werden. Es ist zwar möglich diese Informationen im Internet mit verschiedenen
Techniken zu verschleiern (vgl. nächster Abschnitt) allerdings müssen vieler dieser
Techniken als zweischneidiges Schwert angesehen werden: Die E-Mail-Adressen
sollen so angezeigt werden, dass sie für Nutzer erkenntlich sind, für Maschinen
sollen sie jedoch möglichst verfremdet sein, sodass Programme sie nicht als solche
identifizieren.
Directory-Harvest-Angriff
Wörterbuchangriffe
Eine weitere, weniger ausgeklügelte Möglichkeit, um an E-Mail-Adressen zu gelangen, ist der sogenannte Directory-Harvest-Angriff. Hierbei gibt es zwei mögliche
Techniken, um Listen von potenziellen E-Mail-Adressen zu generieren. Auf der
einen Seite erstellt der Angreifer eine Liste mit allen möglichen Buchstaben- und
Zahlenkombinationen bis zu einer bestimmten Länge und hängt an diese erstellten
Kombinationen dann eine bestimmte Domäne an. Der Nachteil bei dieser Methode
besteht darin, dass die Liste sehr schnell sehr groß wird. Werden bspw. Nutzernamen mit einer Länge von genau vier Zeichen erstellt und dabei nur die Buchstaben
von A bis Z und die Zahlen von 0 bis 9 verwendet, so entsteht eine Basis von
36 Zeichen, die mit der Länge vier potenziert wird. Alleine bei diesem kurzen
Benutzernamen entstehen bereits 364 ≈ 1, 7 Millionen verschiedene Kombinationen. Die zweite Möglichkeit, eine solche Liste zu erstellen, besteht darin, geläufige
Vornamen, Nachnamen und Initialen sinnvoll zu verbinden. So entstehen bspw.
E-Mail-Adressen wie max.mustermann@domain oder mmustermann@domain. Diese
Methode ist angelehnt an einfache Wörterbuchangriffe, wogegen die im ersten
2.4 Spammer
Schritt genannte Methode zu den Brute-Force-Angriffenzählt. In beiden Fällen
werden lange Listen von E-Mail-Adressen erzeugt, die im weiteren Verlauf auf
ihre Korrektheit hin analysiert werden müssen. Eine Analyse besteht dabei aus
einer einfachen Verbindung zum entsprechenden E-Mail-Server und dem Versuch,
eine Test-E-Mail an das geratene Konto zu verschicken. Diese Test-E-Mail enthält
im Normalfall noch keine Werbebotschaften, damit keine Filter anschlagen. Der
Erfolg des Directory-Harvest-Angriffs beruht nun einzig und alleine darauf, dass
E-Mail-Server eine Information an den Versender einer Nachricht schicken, sofern
sie eine Nachricht empfangen haben, die an ein nicht vorhandenes Konto gerichtet
war. Es existieren dementsprechend Implementierungen, die eine solche Nachricht
nicht verschicken, womit prinzipiell alle geratenen E-Mail-Adressen für den Angreifer als valide erscheinen. Würde die Test-E-Mail bereits eine Werbebotschaft
enthalten, so könnte der empfangende E-Mail-Server die Nachricht als Spam und
den versendenden Computer als Spammer erkennen. Daher werden im Normalfall
erst deutlich später nachdem erkannt wurde, dass ein geratenes Postfach wirklich
existiert, Werbebotschaften an dieses Postfach verschickt.
Kostenlose Produktangebote
Eine weitere Möglichkeit, um an E-Mail-Adressen zu gelangen, sind kostenlose
Produktangebote. Hier existieren Dienstanbieter, die kostenfreie Leistungen anbieten und dafür die E-Mail-Adresse des potenziellen Kunden benötigen. Egal ob die
Leistung dann später wirklich erbracht wird oder nicht, die einmal eingetragene
E-Mail-Adresse ist dann bereits in die Adressdatenbank des Anbieters eingetragen
worden und dient daraufhin sicherlich als Empfängeradresse für Spam.
2.4.3 Anti-Harvesting-Methoden
Entsprechend der im vergangenen Abschnitt beschriebenen Harvesting-Methoden
existieren wiederum Methoden, um den Adresssammlern das Sammeln zu erschweren. Ein vollständiges Verhindern des Adresssammelns ist oft nicht möglich,
da eine E-Mail-Adresse für eine Kommunikation benötigt wird und für einen gutartigen Zweck zur Verfügung stehen sollte. Daher erschweren die im Folgenden
vorgestellten Techniken das Sammeln nur.
Bilder
Anstelle von Text-basierten Informationen ist es ebenso möglich, eine E-Mail in
Form eines Bildes innerhalb einer Internetseite zu speichern. Für einen menschlichen Besucher, der eine Kommunikation aufbauen möchte, ist das Bild im Gegensatz zum Text zuerst kein Unterschied, da es dieselben Informationen präsentiert.
Einziger Nachteil besteht darin, dass der Besucher die E-Mail-Adresse nicht direkt in sein E-Mail-Programm kopieren kann, sondern sie abtippen muss. Der
Vorgang des Abtippens ist zum einen aufwendiger und zum anderen fehleranfälliger, wodurch die Kommunikation zwar anfangs erschwert wird, insgesamt die
Wahrscheinlichkeit für den Empfänger allerdings steigert, nicht in einer AdressenDatenbank zu landen. Hier können Adressensammler ihre Software natürlich so
anpassen, dass auch Bilder per Texterkennung durchsucht werden und somit trotzdem an die E-Mail-Adresse gelangen. Je ausgeklügelter die Adresse also innerhalb
des Bilds verschleiert wird, je besser ist sie vor Adresssammlern geschützt.
CAN-Spam-Hinweise
CAN-SPAM ist ein Akronym für ein in den USA im Jahre 2002 beschlossenes und
im Jahre 2003 in Kraft getretenes Gesetz mit dem vollständigen Namen „Con-
Seite 49
Seite 50
trolling the Assault of Non-Solicited Pornography And Marketing Act of 2003“
(vgl. 108th United States Congress [2012]). Hierbei müssen Betreiber von Webseiten
ihren Kunden versichern, dass sie die E-Mail-Adressen, die sie von ihren Kunden
erhalten, nicht an Dritte weitergeben. Dieser Hinweis ist in europäischen Ländern
eher selten, da das genannte Gesetz nur in den USA gilt.
CAPTCHAs
Um E-Mail-Adressen nur für Menschen sichtbar zu machen, eignen sich auch
CAPTCHAs. Der Begriff CAPTACH steht für „Completely Automated Public Turing test to tell Computers and Humans Apart“. Dabei kann es sich um visuelle
CAPTACHAs handeln, also Bilder, die bestimmte Informationen enthalten, die für
Menschen leicht und für Maschinen besonders schwer zu entnehmen sind (vgl.
Abbildung 2.2). Innerhalb dieser Abbildungen kann dann bspw. die Information
direkt enthalten sein, genauso ist es aber auch möglich, dass die Abbildung eine
Aufgabe zeigt, deren Ergebnis in ein entsprechendes Feld eingetragen werden
muss. Oftmals werden Zeichenketten verwendet, die bedingt durch einen bunten
Hintergrund nicht einfach mit Texterkennungssoftware entdeckt werden können.
Als weitere Möglichkeit zur Verschleierung kommen auch verzerrte Zeichenketten
vor. Bei visuellen CAPTCHAs können auch einfache mathematische Aufgaben
zu lösen sein oder bestimmte Dinge gezählt werden. Hier bietet es sich bspw. an,
verschiedene Tierarten innerhalb von einem Bild zu bestimmen. Es kann sich aber
auch um akustische CAPTCHAs handeln, bei denen die Informationen gehört
werden müssen. Bei akustischen CAPTCHAs wird oft gesprochene Sprache abgespielt, die Zahlen enthält, die wiederum durch ein starkes Hintergrundrauschen
verschleiert werden.
Abb. 2.2: Ein von Google erzeugtes CAPTCHA, das zur Erstellung
eines E-Mail-Kontos
gelöst werden muss.
Insgesamt können CAPTCHAs allerdings nur solange automatische Adresssammler abhalten, solange diese nicht entsprechend angepasste Software verwenden, da
auch Programme dazu angelernt werden können, grafische oder auch akustische
CAPTCHAs zu lösen. Das größte Problem in diesem Bereich besteht darin, dass
ausgeklügelte CAPTCHAs nicht nur für Maschinen immer schwerer zu erkennen
sind, sondern auch für Menschen, die eigentlich bei der Lösung kein Problem haben
sollten. Außerdem kann das Lösen von CAPTCHAs zur Not auch in Niedriglohnländer ausgelagert werden, womit ein CAPTCHA zwar nicht mehr automatisch
gelöst werden kann, jedoch für einen relativ kleinen Betrag überwunden werden
kann.
E-Mail-Adressen-Verfälschung
Eine weitere Möglichkeit, um eine E-Mail-Adresse vor dem automatischen Sammeln zu schützen besteht darin, die E-Mail-Adresse an sich zu verfälschen. Diese
2.4 Spammer
als „Address Munging“ bekannte Technik ist einfach zu nutzen. Hier werden
bspw. bestimmte Teile der E-Mail-Adresse durch andere Informationen ersetzt.
Das @-Symbol wird z. B. durch die Zeichenkette <at> ersetzt, der Punkt durch
<dot> oder ein Bindestrich durch <minus>. Diese Textersetzungen sind jedoch
nur so lange hilfreich, bis die Adress-Harvester auch auf konkrete Ersetzungen
reagieren. So können die regulären Ausdrücke, die verwendet werden, um Webseiten nach E-Mail-Adressen zu durchsuchen, soweit angepasst werden, dass auch
E-Mail-Adressen mit oben beschriebenen Ersetzungen erkannt werden.
E-Mail-Server-Überwachung
Anti-Harvesting-Methoden können ebenfalls bei der E-Mail-Server-Software ansetzen. So können E-Mail-Server so implementiert werden, dass sie bspw. keine
E-Mails von einem Absender mehr annehmen, sobald dieser eine E-Mail an eine
nicht vorhandene Adresse verschickt hat. Dies verursacht allerdings die Gefahr,
dass reguläre E-Mails auch nicht mehr angenommen werden, sobald jemand bei
der Eingabe einer E-Mail-Adresse einen Fehler gemacht hat und die Empfängeradresse daher nicht existiert.
E-Mail-Honeypots: Spider Traps
In der IT-Sicherheit wurde vor einigen Jahren erkannt, dass nicht nur proaktive
, also direkte Abwehrmaßnahmen sinnvoll sind, um Sicherheitsanforderungen
durchzusetzen, sondern auch der Einsatz von reaktiven Maßnahmen hilfreich ist,
um bestimmte Angriffe zu verstehen. Vor diesem Hintergrund wurden sogenannte
Honeypots (dt. Honigtöpfe) entwickelt, die reale Systeme darstellen und für einen
Angreifer als lohnendes Ziel angesehen werden können, in Wirklichkeit allerdings
keine Dienste ausführen, die für den Betreiber wichtig sind. Angriffe aus solchen
Systemen können dementsprechend protokolliert werden und es kann aus den
angelegten Protokollen erlernt werden, wie Angreifer vorgehen. Diese eigentlich
im Bereich der Systemsicherheit eingesetzte Methode lässt sich allerdings auch
auf Gegenmaßnahmen gegen das automatische Sammeln von E-Mail-Adressen
übertragen. Diese Technik kann unterschiedliche Aktivitätsgrade verfolgen. Sie
lässt sich auf der einen Seite eher passiv nutzen, in dem eine ungenutzte E-MailAdresse auf einer Webseite veröffentlicht wird und kontrolliert wird, ob E-Mails
an diese Adresse verwendet werden. Auf der anderen Seite kann die Technik
aber auch sehr aktiv eingesetzt werden, in dem eine solche E-Mail-Adresse zur
Anmeldung bei einem Dienstanbieter verwendet wird und daraufhin kontrolliert
wird, ob von einem anderen Anbieter E-Mails an diese Adresse verschickt werden.
So kann auf der einen Seite erkannt werden, ob die Adresse durch Harvesting
Bots gefunden wurde und auf der anderen Seite werden auch Anbieter ausfindig
gemacht, die eine E-Mail-Adresse an andere Anbieter weitergeben.
Die konkrete Implementierung dieser Technik wird als Spider Trap bezeichnet,
da elektronische Fallen aufgestellt werden, um Adresssammler ausfindig zu machen.
HTML-Verschleierung
Die im WWW verwendete Metasprache HTML (Hypertext Markup Language,
vgl. u. a. Connolly and Masinter [2000]) bietet nicht nur die Möglichkeit der Gestaltung und Strukturierung von Webseiten, sie beinhaltet auch die Möglichkeit,
Elemente im Quellcode zu beschreiben, sodass die Darstellung innerhalb der anzuzeigenden Webseite sich stark vom Quellcode unterscheidet. So können bspw.
Elemente wie E-Mail-Adressen mithilfe von Bildern unterbrochen werden, die eine
Seite 51
Seite 52
Breite und eine Höhe von Null Pixeln haben. Somit wird die E-Mail-Adresse im
Quellcode durch ein Element in zwei Teile zerteilt, wirkt aber auf der später zu
betrachtenden Webseite so, als wäre sie ohne Unterbrechung angegeben worden.
Genauso lassen sich bestimmte Zeichen wie das @-Symbol, der Punkt oder der
Bindestrich durch Bilder ersetzen, die für einen menschlichen Betrachter nicht
hinderlich sind, um die vollständige E-Mail-Adresse zu erkennen, für Programme
jedoch nicht direkt erkannt werden können.
Diese Methode ist zwar recht schwer durch automatische Programme zu brechen, allerdings kann sie auf für menschliche Benutzer hinderlich sein, da ein
Mensch solch verschleierte Adresse nicht direkt mit wenigen Mausklicks kopieren
kann, sondern abtippen muss, was letztendlich eine gewisse Fehleranfälligkeit
provoziert.
Javascript-Verschleierung
Als ein wirksames Mittel, um Adress-Harvestern das Sammeln von E-MailAdressen zu erschweren, hat sich eine Verschleierung der E-Mail-Adressen mithilfe von Javascript herausgestellt. Dabei wird die E-Mail-Adresse verschlüsselt im
HTML-Quellcode abgelegt und dann ausschließlich zur Anzeige in einem Browser
entschlüsselt. Dieser Browser muss dazu eine Javascript-Methode ausführen, die
aus der verschlüsselten Zeichenkette die erwünschte E-Mail-Adresse berechnet.
2.4 Spammer
Seite 53
Als besonders hilfreich hat sich hier die ROT13-Verschiebechiffre (vgl. Exkurs 2.1
und Exkurs 2.2) herausgestellt.
Exkurs 2.1: Verschiebechiffre
Verschiebeschriffren gehen bis auf den römischen Kaiser Cäsar zurück und
werden deshalb auch Cäsar-Chiffren genannt. Es handelt sich hierbei um ein
symmetrisches Verschlüsselungsverfahren. Daher entspricht der Schlüssel,
der zum Verschlüsseln verwendet wird, dem Schlüssel, der auch zum Entschlüsseln genutzt werden muss. Die Verschiebechiffre nutzt dabei ein recht
simples Konzept: Jeder Buchstabe ki eines Klartextes K wird um ein festes
ganzzahliges p zyklisch nach rechts verschoben. Das Ergebnis ist dann der
Geheimtext.
E
Etwas formaler gefasst kann die Verschiebechiffre mithilfe der ModuloArithmetik beschrieben werden. Die Buchstaben des Alphabets werden
fortlaufend durchnummeriert:
A = 0, B = 1, . . . , Z = 25
Die Funktion
zahl(x), x ∈ {A, B, . . . , Z}
liefert als Ausgabe diejenige Zahl, der x zugeordnet wird. Die Funktion
buchstabe(x), x ∈ {0, 1, . . . , 25}
liefert als Ausgabe denjenigen Buchstaben, der x zugeordnet wird. zahl(x)
ist also invers zu buchstabe(x). In der Literatur werden die Funktionen
buchstabe(x) und zahl(x) oft weggelassen und die Buchstaben gleichzeitig
als Buchstaben und Zahlen betrachtet.
Zur Verschlüsselung eines Buchstaben ki mit Verschiebung um p Zeichen
ist folgende Funktion zu verwenden:
encrypt p (ki ) = buchstabe(zahl(ki ) + p
mod 26)
Die Entschlüsselung eines Geheimtextes wird durch folgende Funktion für
jeden Buchstaben ki einzeln durchgeführt:
decrypt p (ki ) = buchstabe(zahl(ki ) − p
mod 26)
Gilt p = 1, so wird die Zeichenkette T EST bspw. in UFTU umgewandelt.
Exkurs 2.2: ROT13
ROT13 ist die Abkürzung für rotate by 13 places. Es handelt sich hierbei
um eine gewöhnliche Verschiebechiffre (vgl. Exkurs 2.1), bei der p = 13 gilt.
Durch die Wahl von p = 13 können für Ver- und Entschlüsselung die gleiche
Funktion verwendet werden.
Dabei wird jeder Klartext-Buchstabe auf einen Geheimtext-Buchstaben abgebildet
und der Geheimtext im HTML-Quellcode hinterlegt. Ein Java-Script ist dann im
Browser dafür zuständig, den Geheimtext wieder in den Klartext umzuwandeln.
E
Seite 54
Da automatische Programme zum Sammeln von Adressen im Allgemeinen nicht
den vollen Funktionsumfang eins Browsers besitzen, also oft auch keine Unterstützung für Java-Script anbieten, wird dann entsprechend eine andere E-Mail-Adresse
als die echte eingesammelt. Im Allgemeinen existiert dann für die eingesammelte
E-Mail-Adresse kein Konto und der Versuch, eine Spam-Nachricht an dieses Konto
zu versenden, wird mit einer Fehlermeldung vom E-Mail-Server quittiert.
Kontaktformulare
Die letzte hier betrachtete Methode, um Adress-Harvesting zu erschweren bzw. zu
unterbinden sind Kontaktformulare. Gewerbliche Betreiber von Internetseiten sind
auf die Kommunikation mit Kunden angewiesen, um Produkte oder Dienstleistungen zu verkaufen. Daher ist es auch zwingend notwendig, dass Kunden mit ihnen
in Kontakt treten können. Um auf der einen Seite nicht eine E-Mail-Adresse veröffentlichen zu müssen, auf der anderen Seite für den Kunden aber möglichst einfach
erreichbar zu sein, können Formulare innerhalb einer HTML-Seite eingebunden
werden, in die ein Kunde eine Anfrage und seine eigenen Kontaktdaten eintragen
kann. Das Kontaktformular schickt diese Daten dann zwar auch per E-Mail an
den Empfänger, der Versand der E-Mail geschieht dabei aber Server-seitig und der
Kunde erfährt nicht die E-Mail-Adresse des Empfängers.
So ist es für den Gewerbetreibenden möglich, die Anfrage des Kunden zu erhalten, ohne seine eigene E-Mail-Adresse öffentlich anzugeben. Es ist jedoch nicht
ausgeschlossen, dass Spam-Nachrichten durch diese Technik vollständig geblockt
werden, da bestimmte Spam-Bots nicht nur per SMTP Nachrichten versenden,
sondern auch beim Suchen nach neuen E-Mail-Adressen Formulare gezielt nutzen
und ihre Werbung darin platzieren. Dies kann dann wiederum durch die Verwendung von CAPTCHAs erschwert werden, wie bereits oben in diesem Abschnitt
gezeigt wurde.
beitragen sollen.
K
K
Kontrollaufgabe 2.1: Spammer-Netzwerk
Beschreiben Sie die Infrastruktur, die Spamversender nutzen, um Spam zu
versenden.
Kontrollaufgabe 2.2: Adress-Harvesting
Was genau versteht man unter dem Begriff Adress-Harvesting?
2.5 Offene Mail-Relays
Seite 55
Kontrollaufgabe 2.3: Directory Harvest Attack
K
Wie viele verschiedene Kombinationen von E-Mail-Adressen entstehen bei
der ersten Technik des Directory Harvest Angriffs, wenn die Länge der Nutzernamen fünf oder wenige Zeichen betragen darf und von einem Alphabet
mit 36 Zeichen (A-Z, 0-9) ausgegangen wird?
Was passiert, wenn auch Sonderzeichen wie „.“, „-“und „_“erlaubt werden?
Kontrollaufgabe 2.4: Anti-Adress-Harvesting
K
Welche Methoden gibt es, um Adress-Harvesting zu erschweren oder auszuhebeln? Beschreiben Sie mindestens drei Methoden.
Kontrollaufgabe 2.5: Adress Munging
K
Erläutern Sie die „Adress Munging“ Technik.
Kontrollaufgabe 2.6: Verschiebechiffre
K
Zeigen Sie, dass die Funktion encrypt p (x) und decrypt p (x) invers zueinander
sind.
Kontrollaufgabe 2.7: ROT13-Verschiebechiffre
K
Welche Besonderheit hat die ROT13-Verschiebechiffre?
2.5 Offene Mail-Relays
Wie bereits im ersten Studienbrief in Abschnitt 1.5.3 ab Seite 20 und Abbildung 1.3
auf Seite 18 dargestellt wird, ist SMTP das wichtigste Protokoll für den Versand von
E-Mails. Es wird nicht nur verwendet, um E-Mails vom Computer des Benutzers
zu einem E-Mail-Server zu versenden, sondern auch um diese E-Mails letztendlich
zum E-Mail-Server des Empfängers zu schicken. Diese E-Mails müssen dabei nicht
direkt vom Server des Versenders zum Server des Empfängers verschickt werden.
Nach RFC 5321 (vgl. Klensin [2008] besteht auch die Möglichkeit, dass eine E-Mail
vom SMTP-Server des Versenders nicht direkt zum SMTP-Server des Empfängers
geschickt wird, sondern vom SMTP-Server des Versenders zuerst zu einem anderen
SMTP-Server geschickt wird. Je nach Konfiguration dieses Servers kann dieser die
Annahme der E-Mail mit dem Antwort-Code
550 Requested action not taken: mailbox unavailable (e.g., mailbox
not found, no access, or command rejected for policy reasons)
vollständig ablehnen. Der SMTP Server kann weiterhin die E-Mail mit dem StatusCode
551 User not local; please try <forward-path>
RFC 5321
Seite 56
(vgl. Abschnitt 3.4 aus Klensin [2008]) ablehnen und eine Empfehlung für einen
alternativen SMTP-Server aussprechen. Es ist ebenfalls möglich, dass der SMTPServer mit dem Status-Code
251 User not local; will forward to <forward-path>"
antwortet (vgl. auch Abschnitt 3.4 aus Klensin [2008]). In diesem Fall wird die
E-Mail angenommen, obwohl sich das Konto des Empfängers nicht auf diesem
SMTP-Server befindet. Im Folgenden wird die E-Mail dann an den entsprechenden
Server weitergeleitet, auf dem jedoch wieder nicht das Konto des Empfänger
vorhanden sein muss.
Dieses Verhalten, bei dem der SMTP-Server eine E-Mail annimmt, bei der das Konto
des Empfänger jedoch nicht auf dem eigenen Server liegt, wurde ursprünglich
dazu implementiert, um dem Client die Möglichkeit zu bieten, die Route der EMail selber zu bestimmen. Befinden sich bspw. unterschiedliche SMTP-Server in
einem Firmennetzwerk, wobei der Client selber nur direkten Zugriff auf einen
der Server hat, so kann der Client dem Server vorschlagen, an wen die E-Mail als
Nächstes zu senden ist.
Ursprüngliche Implementierungen von SMTP waren dabei so konfiguriert, dass
sie auch E-Mails von unbekannten Servern ohne jegliche Form der Authentifizierung angenommen haben. Es war somit für den Nutzer möglich, anonym eine
E-Mail zu verfassen und unter einer falschen Benutzerkennung direkt an diese
offenen Weiterleitungs-Server zu schicken, die diese dann in das E-Mail-System
einschleusten.
RFC 2505
K
Diese Möglichkeit > des E-Mail-Versands ist, da sie Anonymität ermöglicht, ideal,
um Spam zu versenden. Aus diesem Grund waren offene Mail-Relays zu Beginn
des Spam-Aufkommens Mitte der 1990er Jahre auch der am meisten verwendete Ursprung vom Spam. Als erkannt wurde, dass offene Mail-Relays häufig für
den Versand von Spam verwendet werden, wurden verschiedene Verfahren empfohlen (vgl. Lindberg [1999]), die diese Lücke schließen sollten. Ebenso wurden
Empfehlungen in RFC 5321 (vgl. Klensin [2008]) eingearbeitet.
Kontrollaufgabe 2.8: Offene Mail-Relays
Was macht einen SMTP-Server zu einem offenen Mail-Relay?
Ein Proxy im Bereich von Computernetzen ist ein Computer, der innerhalb eines
oder zwischen verschiedenen Netzen Pakete vermittelt. Konkret bedeutet dies im
Fall verschiedener Netze, dass Computer A in Netz M mit Computer B in Netz N
kommunizieren möchte, es aber keine direkte Route/Verbindung zwischen den
beiden Netzen gibt. Ein Proxy kann nun zwischen den beiden Netzen M und N die
Pakete von A an B weiterleiten und entsprechend von B an A. Dabei existieren verschiedene Arten von Proxies wie Proxy-Server, generische Proxies, Proxy-Firewalls,
transparente Proxies und auch Reverse Proxies. Im Fall eines Netzes kann ein
Proxy bspw. im allgemeinen Fall dazu verwendet werden, um bestimmte Daten für
einen Dienst zu filtern. Dabei bieten sich auch SMTP-Proxies an, die innerhalb von
Proxy-Firewalls dazu verwendet werden, um den Datenverkehr zu überwachen
und Spam auszufiltern.
Ein offener Proxy ist nun ein Proxy, der ohne Anmeldung von jedem verwendet
werden kann. Dies ist z. B. sinnvoll, sofern jemand anonym einen Dienst im Internet
2.6 Mail-Formulare
Seite 57
verwenden und seine IP-Adresse daher verschleiern möchte. Ein reales Einsatzszenario sind bspw. Krisenregionen, in denen die Regierung den Internetverkehr
überwacht. Hier kann ein offener Proxy dazu verwendet werden, um mit anderen
zu kommunizieren, ohne die eigene IP-Adresse dem Gesprächspartner mitteilen
zu müssen.
Offene Proxies können aber auch zum E-Mail-Versand verwendet werden. Dabei
verschickt ein Sender eine E-Mail an den Empfänger unter Verwendung der IPAdresse des offenen Proxies. Dadurch sieht der Empfänger nur die IP-Adresse des
offenen Proxies, aber nicht diejenige des ursprünglichen Senders. Somit verschleiert
der Sender seine eigene IP-Adresse. Im Fall von Spam wurde dies genutzt, damit
Spamversender, die bereits auf einer Blacklist (vgl. Abschnitt 3.5.1 ab Seite 72)
stehen, weiterhin mithilfe einer anderen IP-Adresse Spam versenden können.
Es ist jedoch sehr simpel und auch ohne Weiteres automatisch möglich, offene
Proxies in Blacklists einzutragen, weshalb diese Möglichkeit des Spamversandes
heutzutage nicht mehr verwendet wird.
Kontrollaufgabe 2.9: Offene Proxies
K
Wodurch sind offene Proxies definiert?
2.6 Mail-Formulare
Mail-Formulare sind nicht nur eine Anti-Harvesting-Methode (vgl. Abschnitt 2.4.3,
Unterpunkt Kontaktformulare ab Seite 54), sondern auch eine Methode zum Spamversand. Formulare dienen generell der Erfassung und Verarbeitung von verschiedensten Daten. Dies können bspw. Grußtexte für ein Gästebuch oder auch Hinweise
an einen Webseitenadministrator sein. Im HTML-Standard wurden ab Version 2
(vgl. Berners-Lee and Connolly [1995]) durch das <form> Schlüsselwort Formulare ermöglicht. Diese Formulare können verschiedene Felder enthalten, die vom
Webseitenbesucher ausgefüllt werden können. Exkurs 2.3 auf Seite 58 gibt weitere
Informationen zu den Feldern von HTML-Formularen. Der Inhalt kann dann wiederum mithilfe von verschiedenen Methoden, in HTML Version 2 ausschließlich
METHOD=GET oder METHOD=POST, an den Webserver zur weiteren Verarbeitung übertragen werden. Die Verarbeitung auf dem Webserver wird separat implementiert.
So ist eine Implementierung denkbar, welche die im Formular angegebenen Daten an eine bestimmte E-Mail-Adresse versendet. Durch Absicht des Entwicklers
oder auch einen Fehler ist es aber auch möglich, dass der Empfänger mithilfe von
Formularfeldern durch den Nutzer selber definiert wird. Somit ist es für einen
Nutzer möglich, ohne eigenen E-Mail-Client eine E-Mail an eine beliebige Adresse
zu verschicken. Automatisierte Programme suchen nach genau diesen fehlerhaften
Formularen im Internet und nutzen diese dann, um eine Werbebotschaft an viele
Empfänger zu schicken. So wird das Formular zur Quelle von Spam.
Kontrollaufgabe 2.10: Mail-Formulare
Fassen Sie mit wenigen Worten zusammen, wie Mail-Formulare zum Versand von Spam missbraucht werden können. Gehen Sie dabei explizit auf
die Voraussetzungen ein, damit ein Spamversand überhaupt möglich ist.
RFC 1866
K
Seite 58
Exkurs 2.3: Felder in HTML Formularen
E
Der HTML Standard in Version 4 erlaubt verschiedene Arten von Formularfeldern. In diesem Exkurs werden die verschiedenen Felder vorgestellt.
check box Dieses Feld wird verwendet, um vom Benutzer eine ja/nein-
Auswahl zu erhalten. Damit können Informationen abgefragt werden,
wie bspw. die Auswahl eines Newsletter-Empfangs.
file select Mit diesem Feld erhält der Benutzer einen Auswahldialog für
Dateien. Hiermit können z. B. Bilder hochgeladen werden.
radio button Diese Felder sind nur in Gruppen von mindestens zwei Ele-
menten sinnvoll. Mit solchen Feldern kann eine von verschiedenen
Optionen ausgewählt werden, wobei alle Informationen durchgehend dargestellt werden. Eine sinnvolle Möglichkeiten zur Nutzung
ist bspw. die Abfrage, ob ein Benutzer männlich oder weiblich ist
reset button Dieses Feld wird im Browser als Knopf dargestellt, der zur
Entfernung der eingegebenen Daten zuständig ist. Es werden daraufhin die vorher definierten Standardwerte wiederhergestellt.
select list Mithilfe der select list kann der Nutzer aus einer ausklap-
penden Liste ein Element auswählen. Je nach Konfiguration ist auch
eine Mehrfachauswahl möglich.
submit button Diese Feld wird im Browser als Knopf dargestellt, der den
Browser dazu veranlasst, die im Formular angegebenen Daten mithilfe der durch das Formular definierten Methode zu verarbeiten. Im
Allgemeinen besteht die Verarbeitung aus einem Transfer der Daten
zum Server, der diese dann weiter bearbeitet.
text area Ein text area ist ein Feld, in das Text eingetragen werden kann.
Im Gegensatz zum nächsten Formularfeld, der text box, ist es aller-
dings auch möglich, mehrzeiligen Text einzugeben.
text box Die text box ist ein Element zur Eingabe von einzeiligen Texten.
Hier können Buchstaben, Zahlen und auch beliebige Sonderzeichen
eingetragen werden. Eine text box kann verschiedene Eigenschaften
haben. Dazu zählen vordefinierte Eingaben, Längenbegrenzungen
oder auch die Kennzeichnung als Passwortfeld. Wird eine text box
als Passwortfeld definiert, so erscheinen bei einer beliebigen Eingabe
ausschließlich Sternsymbole, damit das Passwort nicht per ShoulderSurfing von anderen entdeckt werden kann.
2.7 Webmail
RFC 1945, RFC
2616, RFC 2854
Webmail ist ein Dienst, der von unterschiedlichen Anbietern zur Verfügung gestellt
wird, um eine E-Mail-Kommunikation ohne eigenen E-Mail-Client zu ermöglichen.
Dazu benötigt der Benutzer als Clientsoftware ausschließlich einen Browser, um
den Dienst im WWW zu erreichen. Die gesamte Kommunikation zwischen Server
und Client läuft über HTTP (Hypertext Transfer Protocol, vgl. Berners-Lee et al.
[1996] und Fielding et al. [1999]. Daher wird kein SMTP, IMAP oder POP3 benötigt.
Zumeist wird HTML (Hypertext Markup Language, vgl. Connolly and Masinter
[2000]) als Beschreibungssprache verwendet. Die Vorteile von Webmail liegen
damit klar auf der Hand: Der Nutzer kann den Dienst von jedem an das Internet
angeschlossenen Rechners, der über einen Browser verfügt, verwenden. Es ist
keine Synchronisation des Postfaches auf verschiedenen Computern notwendig
und es muss weiterhin keine Sicherung der Nachrichten durch den Benutzer
2.7 Webmail
durchgeführt werden. Im Allgemeinen werden die Daten durch den Dienstanbieter
professionell gesichert und stehen daher auch noch nach einem Hardwarefehler
dem Nutzer zur Verfügung. Der Nachteil des Dienstes besteht darin, dass E-Mails
bei jeder Betrachtung über die Internetverbindung übertragen werden müssen,
was den Datenverkehr erhöht. Außerdem wird der Nutzer in einem gewissen Grad
abhängiger vom Dienstanbieter: Es ist dem Nutzer nicht möglich, die Ausstattung
des Webmail-Servers zu ändern, um bspw. die Geschwindigkeit beim Durchsuchen
von E-Mails zu erhöhen. Je nach Dienstanbieter stehen unter Umständen auch
nur begrenzt viel Speicherplatz zur Verfügung, oder der Speicherplatz kann nur
durch finanzielle Unterstützung des Dienstanbieters durch den Nutzer vergrößert
werden.
In diesem Kontext müssen nun aber zwei Fragen untersucht werden. Zum einen
muss geklärt werden, warum Webmail überhaupt zum Spamversand verwendet
wird. Zum anderen ist interessant, wie Webmail zur Quelle von Spam wird. Beide
Fragestellungen werden im folgenden Abschnitt geklärt.
Wie bereits in den vorherigen Abschnitten beschrieben, existieren viele Möglichkeiten zum Versand von Spam, die auf Fehlern der ursprünglichen Implementierungen von Protokollen basieren, bzw. auf dem zum Zeitpunkt der Entwicklung
nicht vorhandenen und auch nicht nötigen Sicherheitsbewusstseins. Daher lässt
sich die Frage nach dem „Warum“ leicht beantworten: Nachdem mehr und mehr
Lücken geschlossen wurden und der Versand von Spam immer schwieriger wurde,
wurden von den Versendern von Spam Möglichkeiten gesucht, Spam über andere
Transportwege in das E-Mail-Netz einzuschleusen. Webmail ist neben den im
nächsten Abschnitt behandelten Botnetzen die aktuell am weitesten verbreitete
Möglichkeit, um Spam zu versenden. Das Einzige, was zum Versand von Spam
über Webmail notwendig ist, sind die Benutzerdaten von vorhandenen E-MailKonten. Diese können auf der einen Seite durch Phishing (vgl. Abschnitt 1.9 ab
Seite 36) von anderen Benutzern übernommen werden. Eine zweite Möglichkeit
besteht darin, mithilfe von Botnetzen (vgl. Abschnitt 2.9 ab Seite 61) neue Konten
zu erstellen, die dann ausschließlich für den Versand von Spam verwendet werden.
Sind die Zugangsdaten bekannt, so können sich Bots programmgesteuert an die
Konten der Webmail-Anbietern anmelden, um von dort aus Spam zu versenden.
Der Vorteil, den Webmail für Bots bietet, liegt in der Tatsache begründet, dass die
dann versendeten E-Mails von einem System oder Netzwerk versendet wird, das
über eine gute Reputation verfügt. Die Reputation eines System ist wichtig, da
es einige Techniken gibt, die anhand der Reputation E-Mails in Spam und Ham
klassifizieren. Dazu zählen bspw. Listenverfahren wie White-, Black- und Greylisting (vgl. Abschnitt 3.5 ab Seite 72) sowie entsprechende Reputationsverfahren
(vgl. Abschnitt 3.6 ab Seite 78).
Andererseits versuchen Webmail-Anbieter den angebotenen Dienst entsprechend
gegen Spam-Bots abzusichern. Dazu werden auf der einen Seite CAPTCHAs verwendet, die bei der Anmeldung sicherstellen sollen, dass sich wirklich ein Mensch
und nicht ein automatisiertes Programm anmeldet. Auf der anderen Seite werten
Anbieter wie Google auch die IP-Adresse des anmeldenden Computers aus, um zu
überprüfen, aus welchem Land sich ein Benutzer anmeldet. Hat sich ein Benutzer
immer aus demselben Land angemeldet, so ist bei einer erneuten Anmeldung
Seite 59
Seite 60
aus einem anderen Land z. B. eine andere Aufgabe zu lösen, damit sichergestellt
werden kann, dass das Konto nicht von Dritten kompromittiert wurde.
Kontrollaufgabe 2.11: Webmail I
K
Was ist Webmail und wie unterscheidet sich der Dienst vom klassischen
E-Mail-Verfahren?
Kontrollaufgabe 2.12: Webmail II
K
Nennen Sie jeweils zwei Vor- bzw. Nachteile von Webmail.
2.8 IP Prefix Hijacking
RFC 4271
Das Internet als globales Netzwerk besteht aus vielen Knoten. Jeder dieser Knoten
verfügt über eine eigene IP-Adresse. Dieser Sachverhalte wird in Abschnitt 1.5.6
ab Seite 30 genauer beschrieben. Damit ein Paket sein Ziel erreicht, wird es an
jedem Knoten in die richtige Richtung weiter geleitet. Da Router nur begrenzte
Ressourcen haben und ein Paket möglichst schnell weiter geleitet werden soll,
werden nicht an allen Punkten die exakten Informationen über alle möglichen IPAdressen gespeichert. Bei IPv4 ist dies zwar technisch noch möglich, da nur für ca. 4
Milliarden Einträge ein entsprechendes Ziel vorhanden sein muss, jedoch wäre dies
bei IPv6 technisch nicht mehr machbar. Somit wird nur ein Teil der Ziel-Adresse des
Paketes ausgewertet. Dieser Teil gibt Aufschluss über das autonome System, in dem
sich die Maschine mit der angegebenen IP-Adresse befindet. Autonome Systeme
sind dabei größere Zusammenschlüsse bzw. Gruppen von IP-Adressen, die sich
unter einer zentralen Verwaltung wie bspw. einem ISP, einem großen Unternehmen
oder einer Universität befinden. Um die Routing-Tabellen daher möglichst klein
zu halten und schnell zu aktualisieren, werden die IP-Adressen eines autonomen
Systems zu einem Präfix gruppiert. Diese Präfixe werden dann innerhalb der
Border Gateways verteilt. Die Border Gateways stehen, wie der Name bereits
suggeriert, zwischen einzelnen autonomen Systemen und vermitteln dazwischen.
Für deren Kommunikation wird das Border Gateway Protocol (BGP, vgl. Rekhter
and Li [1994], Rekhter and Li [1995] und Rekhter et al. [2006]) verwendet. Per
BGP werden die anderen autonomen Systeme also darüber informiert, wo sich
bestimmte IP-Adressen befinden. Ein autonomes System teilt dazu den anderen
autonomen Systemen auch mit, zu welchen Präfixen es Pakete annehmen und
weiterleiten kann.
Filtertechniken, deren Aufgabe darin besteht, Spam von Ham zu unterscheiden,
verwenden auch die IP-Adresse des Absenders als Kriterium. Es wird davon ausgegangen, dass wenn bereits viele E-Mails aus einem bestimmten autonomen System
als Spam klassifiziert wurden, dass die Spam-Wahrscheinlichkeit einer E-Mail von
einer anderen IP-Adresse aus dem gleichen autonomen System deutlich größer
ist. Gründe dafür sind leicht zu finden: Computer, die sich im gleichen autonomen System befinden, werden auch oft von derselben Instanz gewartet. Auf ihnen
läuft die gleiche Software und insbesondere sind die Softwareversionen auf den
einzelnen Rechnern gleich. Wurde nun einer der Rechner aus einem autonomen
System mit Malware (vgl. Abschnitt 2.9 ab Seite 61) infiziert, so ist die Wahrscheinlichkeit sehr groß, dass andere Rechner im gleichen autonomen System die gleiche
Sicherheitslücke aufweisen und daher ebenfalls mit Malware infiziert werden.
Den Versendern von Spam ist dies natürlich bewusst und so haben sie nach einer
Möglichkeit gesucht, ihre Absenderadresse bzw. ihr eigenes autonomes System dahingehend zu ändern, dass ihre Nachrichten nicht mehr aufgrund des autonomen
2.9 Malware / Botnetze
Seite 61
Systems bzw. ihres Präfixes als Spam klassifiziert und danach gefiltert werden.
Diese Möglichkeit wird als IP Prefix Hijacking oder IP Hijacking bezeichnet. Es
existieren verschiedene Möglichkeiten, um diesen Angriff durchzuführen. Zum
einen kann ein autonomes System anderen autonomen Systemen mitteilen, dass
es ein Präfix beinhaltet, obwohl dies gar nicht der Fall ist. Zum anderen kann ein
autonomes System auch ankündigen, dass es über eine kürzere Route zu einem
bestimmten autonomen System verfügt und Pakete über dies autonome System
geleitet werden soll, obwohl die Route eigentlich länger ist. In beiden Fällen werden
Pakete durch das autonome System geleitet, die eigentlich einen anderen Weg
gehen sollten. Dies ist soweit noch kein Problem, sofern die Pakete einfach eine
andere Route gehen. Es ist nun aber für das kompromittierte autonome System
möglich, auch Pakete selber zu erstellen und als Quelle das „entführte“ autonome
System anzugeben. Somit können auch E-Mails erstellt werden, deren Ursprung
eine IP-Adresse zu sein scheint, die in einem autonomen System liegt, das nicht
als Ursprung von Spam markiert ist, obwohl der Ursprung der Nachricht in dem
autonomen System liegt, das als Quelle für Spam bereits erkannt wurde. Der Sinn
des IP Prefix Hijackings liegt also darin, die Absenderadresse soweit zu verschleiern bzw. zu fälschen, dass Filtertechniken die E-Mails aufgrund ihres Ursprungs
nicht als Spam klassifizieren. Ramachandran and Feamster [2006] greifen in einer
Untersuchung diesen Sachverhalt auf. Sie finden dabei bspw. auch heraus, dass
eine Klassifikation nach Netzwerkeigenschaften bessere Ergebnisse innerhalb ihrer
Studie liefert, als eine auf dem Inhalt basierende Klassifikation.
Im nächsten Abschnitt wird auf den aktuell am meisten verbreiteten Ursprung
von Spam eingegangen, die sogenannten Botnetze.
Kontrollaufgabe 2.13: IP Prefix Hijacking
Wie funktioniert das IP Prefix Hijacking?
Als letzte Technik werden in diesem Studienbrief Malware und die damit in direktem Zusammenhang stehenden Botnetze behandelt. Malware (vgl. Definition 2.1)
ist ein Kunstwort, das aus den beiden Begriffen malicious (dt. schädlich) und
Software zusammengesetzt ist. Es handelt sich bei Malware also um schädliche
oder schadhafte Software. Dabei ist die Unterscheidung zwischen Goodware, also
gutartiger Software, und Malware nicht trivial für den Benutzer, da er die Funktionalität einer Software nur durch deren Ausgabe erkennen kann. Was eine Software
allerdings im Hintergrund macht, ist für ihn nicht direkt ermittelbar. Um zu erkennen, ob es sich bei einer Software um Malware oder Goodware handelt, werden
verschiedene Techniken eingesetzt, die sich grob in die statische und die dynamische Analyse gliedern. Bei der statischen Analyse von Software wird der Binärcode
betrachtet und es werden Merkmale extrahiert wie bspw. Dateigröße, Entropie
und die enthaltenen Bytefolgen. Bei der dynamischen Analyse wird die Software
hingegen ausgeführt und es wird das Verhalten der Software protokolliert. Zum
Verhalten zählen bspw. Syscalls, also Aufrufe, die vom System abgearbeitet werden
oder auch Netzwerkverbindungen, die zu bestimmten Servern aufgebaut werden.
Anhand des dabei entstehenden Protokolls kann dann geprüft werden, ob das
Verhalten der Software entweder verdächtig ist, oder es vielleicht sogar schon eine
Software mit ähnlichem Verhalten gab, die als Malware klassifiziert wurde. Da die
Analyse von Malware allerdings ein sehr komplexes Thema ist, wird sie hier nicht
K
Seite 62
weiter vertieft. Wichtig bleibt zu behalten, dass Malware Software ist, die einem
schadhaften Zweck dient.
D
Definition 2.1: Malware
Angelehnt an Aycock [2006] wird Malware durch die folgenden drei Charakteristika definiert:
Selbstreplikation Die Schadsoftware verbreitet sich entweder aktiv, in-
dem bspw. Kopien des ausführbaren Codes auf andere Systeme transferiert werden oder passiv, indem der Benutzer die Schadsoftware
versehentlich kopiert.
Populationswachstum Die Gesamtzahl der Instanzen der Schadsoftware
steigt bedingt durch die Selbstreplikation.
Parasitismus Schadsoftware hängt sich an oder vermischt sich mit ande-
rem ausführbaren Code, um unentdeckt zu bleiben. Infolgedessen
kann es auch zu einem Populationswachstum kommen. Auch eine
passive Selbstreplikation ist denkbar, sobald der Anwender Kopien des Codes, mit dem sich die Schadsoftware vermischt hat, auf
anderen Systemen nutzt.
Da der Zweck von Malware auch der Versand von Spam sein kann, ist das Studium
von Malware auch wichtig für das vorliegende Modul. Es wird hier allerdings
nur ein sehr grober Überblick darüber gegeben, wie sich Malware verbreitet und
warum Malware für den meisten weltweiten Spam verantwortlich ist.
Wie schon weiter oben beschrieben, repliziert sich Malware entweder aktiv oder
passiv. Die passive Selbstreplikation ist jedoch auf eine Benutzerinteraktion angewiesen, die im Gegensatz zur aktiven Selbstreplikation sehr langwierig sein kann.
Deshalb setzt aktuelle Malware auf eine aktive Selbstreplikation. Dazu werden
Sicherheitslücken in Server- und auch Client-Software gesucht, über die Schadcode
eingeschleust werden kann. So ließen sich in der Vergangenheit oftmals Standarddienste von Windows Betriebssystemen missbrauchen, um Zugriff auf ein System
zu bekommen. Der eingeschleuste Schadcode enthält oft allerdings nicht die Malware selbst, sondern dient nur dazu, die Malware nachzuladen, um sie daraufhin
auszuführen. Wurde die Malware erfolgreich nachgeladen, so verfolgt sie generell
zwei Ziele. Zum einen versucht sie sich weiter zu replizieren. Dazu sucht sie nach
Sicherheitslücken auf anderen an dasselbe Netzwerk angeschlossenen Computern.
Zum anderen kann sie dann ihre Schadfunktion ausführen. Bei aktueller Malware
existiert allerdings nicht eine einzige definierte Schadfunktion. Vielmehr verbindet
sich die Malware mit anderen Instanzen, um Befehle zu empfangen, die sie dann
abarbeiten kann.
Ist ein Computer mit Malware infiziert, und kann entsprechend von einer dritten
Person kontrolliert werden, so spricht man bei dem Computer von einem Zombie
oder Bot. Verbinden sich viele dieser Bots zu einem Netzwerk, so wird dies als
Botnetz bezeichnet.
Botnetze sind je nach Quelle für ca. 85 % des weltweiten Spams verantwortlich
(vgl. Symantec Corporation [2010]) und unterscheiden sich durch unterschiedliche
Kommunikationsstrukturen. Generell können diese in zentrale und dezentrale
Strukturen unterteilt werden. Der Kommunikationskanal wird dabei als Command
and Control (C&C)-Struktur bezeichnet. Eine zentrale Struktur verfügt über einen
oder wenige Server, die vom Botmaster betrieben werden und viele Bots, die ihre
Befehle direkt von den Servern beziehen.
Seite 63
IRC
Eine der ersten genutzten Techniken, um einen C&C-Kanal zu erzeugen, ist die
Nutzung von IRC (Internet Relay Chat). Das IRC-Protokoll wird in RFC 1459
(vgl. Reed [1993], Kalt [2000a], Kalt [2000b], Kalt [2000c] und Kalt [2000d]) definiert.
Ursprünglich für die Kommunikation von Menschen gedacht, eignet sich IRC auch
zur Kommunikation zwischen Botmaster und den einzelnen Bots. Dabei bietet die
Kommunikation über IRC verschiedene Vorteile. Zum einen ist es für Betreiber sehr
einfach, eigene Server aufzubauen, da es viele Implementierungen des Protokolls
gibt. Weiterhin können auch vorhandene Server verwendet werden. Gleichzeitig
können verschiedene Botnetze über denselben Server verwaltet werden, da einzelne
Kommunikationen durch unterschiedliche Kanäle voneinander getrennt werden
können. Weiterhin bietet IRC die Möglichkeit zur Kommunikation sowohl vom
Botmaster zum Bot als auch vom Bot zum Botmaster, also in beide Richtungen.
Somit kann der Botmaster Befehle an den Bot senden und gleichzeitig Status-Codes
vom Bot zurückerhalten oder Daten von kompromittierten PC abgreifen. Dazu
kommt noch, dass IRC mit einfachen Möglichkeiten redundant ausgelegt werden
kann. Hierfür muss nur ein zweiter separater Server aufgesetzt werden, an den
sich die Bots sowie der Botmaster zusätzlich verbinden und im Falle einer Störung
auf diesen Server ausweichen.
HTTP
Eine weitere Möglichkeit für eine zentralisierte Struktur ist bspw. die Kommunikation über einen Webserver per HTTP (vgl. Berners-Lee et al. [1996] und Fielding
et al. [1999]). Die Kommunikation per HTTP ist weit verbreitet, da Port 80, der
standardmäßig für HTTP verwendet wird, in den seltensten Fällen durch Firewalls
blockiert wird, da dieser Port für das World Wide Web von essentieller Bedeutung
ist. Außerdem ist die Nutzung eines HTTP-Servers aufgrund der Skalierbarkeit
vorteilhaft. Mit einem entsprechend großen Intervall können sich Bots neue Informationen vom Server laden und müssen dazu keine persistente Verbindung
zum Server aufhalten. Bei der im vorherigen Abschnitt vorgestellten Kommunikation per IRC, sind die Bots durchgehend mit dem Server verbunden, wodurch die
maximale Anzahl der verbundenen Bots deutlich kleiner ist.
FTP
Neben IRC und HTTP kann der C&C-Kanal auch per FTP betrieben werden. Hier
können dann auch problemlos Dateien vom Client, auf dem sich der Bot befindet,
an den Botmaster übertragen werden.
Sowohl bei IRC als auch bei HTTP und FTP besteht jedoch das Problem, dass
die Bots wissen müssen, an welche IP oder welche Domain sie sich verbinden
müssen. Diese Information muss der Bot haben, bevor er sich das erste Mal mit
einem C&C-Server verbindet. Daher ist oft eine Reihe von Zieladressen bereits
fest im Quellcode des Bots implementiert. Behörden haben die Möglichkeit, einzelne Server zu sperren, wodurch sich die Bots nicht mehr mit dem Botmaster
verbinden können und somit auch keine weiteren Befehle mehr erhalten. Sind
dem Bot mehrere Adressen bekannt, so kann er zumindest versuchen, auf andere
Kanäle auszuweichen. Trotzdem besitzt dieses zentrale Kommunikationsmodell
die Schwachstelle, dass es ausreicht, wenige Server vom Netz zu nehmen, um die
gesamte Kommunikation zu stoppen. Aus diesem Grund wird immer öfter das im
nächsten Abschnitt vorgestellte Peer-to-Peer-Modell verwendet.
RFC 1459
Seite 64
Peer-to-Peer
Beim Peer-to-Peer-Modell wird generell keine zentrale Instanz eingesetzt. Es existieren zwar auch zentralisierte Peer-to-Peer-Systeme, jedoch bieten diese die gleiche
Schwachstelle wie die in den vorherigen Abschnitten vorgestellten Systeme. Das
Modell ist durch unzählige Tauschbörsen im Internet bekannt geworden, bei denen oft auch illegale Inhalte zwischen verschiedenen Benutzern (oberflächlich
anonym) ausgetauscht werden. Wird dieses Modell zur Kommunikation gewählt,
so fungieren prinzipiell alle Bots sowohl als Client als auch als Server und halten
mehrere Verbindungen zu anderen Teilnehmern offen. An einer beliebigen Stelle
im Netz muss dann nur ein Befehl eingefügt werden, der von jedem Teilnehmer
weiterverbreitet wird. Somit erhalten früher oder später alle Bots die aktuellen
Befehle und können auch eigene Informationen an andere Bots weitergeben. Der
Vorteil von diesem Kommunikationsmodell liegt ganz klar in der Ausfallsicherheit. Wird ein einzelner Bots aus dem Netz entfernt, so funktioniert das Netz
immer noch ohne Einschränkungen. Daher ist es deutlich schwieriger, ein auf dem
Peer-to-Peer-Modell basierendes Botsnetz zu deaktivieren.
Sind mehrere Bots unter der Kontrolle eines Botmasters, so kann dieser diverse
Aktionen von den Bots ausführen lassen. Auf der einen Seite steht der in diesem
Modul behandelte Spam. Einzelne Bots werden dann zum Versand von E-Mails
verwendet. Genauso können Botnetze zum Adress-Harvesting verwendet werden.
Dies kann entweder geschehen, indem die Bots wie Suchmaschinen das Internet
nach Adressen durchsuchen, oder sie können auch auf dem befallenen Computer nach Adressen suchen. Indem bspw. Adressbücher von E-Mail-Programmen
verwendet werden, kann sichergestellt werden, dass echte Adressen gefunden
werden, die einen höheren Wert haben als andere im WWW gefundene Adressen. Ein weiterer Einsatzzweck von Botnetzen können verteilte Denial-of-Service
(DDoS)-Angriffe sein. Hierbei werden an einen Dienst gleichzeitig von vielen verschiedenen Bots so viele Anfragen gestellt, dass der Dienst für reguläre Nutzer
nicht mehr verwendbar/verfügbar wird. Weiterhin können entsprechend auch
Aktionen ausgeführt werden, die den Benutzer des kompromittierten Rechners
betreffen. So können bspw. Werbebanner, die auf Webseiten angezeigt werden,
durch die Schadsoftware auf dem Bot ausgetauscht werden. Der Benutzer kann
genauso ausspioniert werden. Dies geschieht nicht nur für Kontakte des Nutzers
auf Basis der in E-Mail-Programmen vorhandenen E-Mail-Adressen, sondern ebenfalls für das gesamte sonstige Verhalten des Nutzers. Es können Passwörter für
jegliche Webseiten gespeichert und an den Botmaster weiter gegeben werden sowie
auch PIN/TAN beim Online Banking oder Kreditkartennummern beim Einkauf
im Internet. Der Computer des Opfers kann ebenfalls dazu benutzt werden, um
automatisch bestimmte Seiten im WWW zu besuchen, um deren Popularität zu
steigern. Genauso kann die Rechenleistung des Computer verwendet werden,
um bspw. per Brutforce Passwörter zu knacken. Insgesamt existieren viele andere Angriffsszenarien, die jedoch an dieser Stelle nicht weiter behandelt werden
sollen.
Es existieren viele Ansätze, um Botnetze zu deaktivieren. Es gibt jedoch keine
generell Methode, die immer hilfreich ist. Oft hilft nur ein Studium des konkreten
Botnetzes, um die internen Strukturen zu verstehen und mögliche Schwachstellen
zu finden, wie von Provos and Holz [2008] beschrieben.
Zusammenfassend kann jedoch gesagt werden, dass Botnetze insgesamt für eine
große Masse an Spam verantwortlich sind. Dabei haben die fünf zurzeit größten
Botnetze Cutwail (vgl. Waldron [2010]), Srizbi (vgl. BBC [2008]), Grum (vgl. Danchev [2009]), Rustock (vgl. Miller [2008]) und Mega-D (vgl. Nikolaenko [2010]) ein
Seite 65
mögliches Spam-Volumen von mehr als 200 Milliarden Spam-Nachrichten pro
Tag.
Kontrollaufgabe 2.14: Malware
Benennen und beschreiben Sie die drei wesentlichen Eigenschaften, die
Malware auszeichnen.
Kontrollaufgabe 2.15: Botnetz I
Woraus besteht ein Botnetz?
Kontrollaufgabe 2.16: Botnetz II
Welche Kontrollstukturen existieren für Botnetze? Beschreiben Sie dabei für
die einzelnen Strukturen jeweils Vor- und Nachteile.
Kontrollaufgabe 2.17: Botnetz III
Begründen Sie, dass die Anzahl der verbundenen Bots per IRC eine feste
Größenbeschränkung aufweist. Warum ist dies bei einer Kommunikation
per HTTP nicht der Fall?
Kontrollaufgabe 2.18: Botnetz IV
Für welche Zwecke werden Botnetze neben der Verbreitung von Spam
verwendet?
Der Fokus dieses Studienbriefs lag auf den verbreiteten Spam-Techniken. Dabei
wurde beginnend vorgestellt, wie Spammer-Netzwerke aussehen und welche verschiedenen Verknüpfungen zu anderen Instanzen notwendig sind. Daraufhin
wurden offene Mail-Relays besprochen und beschrieben, wie es zum anonymen
Versand von Spam über diese Strukturen kommen konnte. Die danach angesprochenen offenen Proxies waren dann eine generelle Möglichkeit, um anonym Spam
zu verschicken, bevor der Abschnitt über Mail-Formulare diese Möglichkeit zum
Versand von Spam aufbereitete. Webmail als professionelle aber eigenständige
Ausprägung von Mail-Formularen wurde daraufhin behandelt. Um fremde IPAdressen zu nutzen, wurde das IP Prefix Hijacking angeführt, bevor im letzten
Abschnitt die aktuell größte Quelle von Spam, die Botnetze, detailliert besprochen
wurden. Im folgenden Abschnitt werden die Lösungen zu den in diesem Studienbrief gestellten Kontrollaufgaben aufgeführt, bevor Abschnitt 2.11 ab Seite 66 die
Übungsaufgaben auflistet.
K
K
K
K
K
Seite 66
2.11 Übungen
Ü
Ü
Ü
Ü
Übung 2.1: Adress-Harvesting I
Was genau ist Adress-Harvesting und welche verschiedenen Methoden
existieren?
Übung 2.2: Adress-Harvesting II
Wie sollten E-Mail-Adressen hinterlegt werden, damit sie nicht dem AdressHarvesting zum Opfer fallen? Was erschwert das Adress-Harvesting?
Übung 2.3: Adress-Harvesting III
Gehen Sie auf Ihre meistbesuchten Seiten im Internet und suchen sie nach
E-Mail-Adressen der Autoren. Gibt es auf diesen Seiten irgendwelche Schutzmechanismen? Falls ja: Wie äußern sich diese? Falls nein: Was könnte zum
Schutz der E-Mail-Adressen eingesetzt/verändert werden?
Übung 2.4: Directory Harvest Attack
Betrachten Sie RFC 5321 (vgl. Klensin [2008]) und finden Sie heraus, wie
viele Zeichen der Local-Part einer E-Mail-Adresse maximal enthalten darf.
Gehen Sie nun davon aus, dass der Local-Part nur die Buchstaben von A
bis Z, die Ziffern von 0 bis 9 enthält und dass der Versand einer E-Mail 0,1
Sekunde dauert.
1. Wie viele mögliche E-Mail-Adressen lassen sich daraus generieren?
Geben Sie dafür eine Summenformel an und keine konkrete Zahl.
2. Wie lange würde der E-Mail-Versand an alle so generierten E-MailAdressen dauern, wenn Sie davon ausgehen, dass sie pro E-MailAdresse genau eine E-Mail versenden?
3. Gehen Sie nun davon ausgehen, dass sie nur eine einzige E-Mail an
alle Adressen versenden wollen und der Rest des E-Mail-Quellcodes
vernachlässigbar klein ist. Wie viele Bytes würde die zu versendende
E-Mail dann enthalten?
Ü
Ü
Übung 2.5: ROT13-Verschiebechiffre I
Begründen Sie, warum bei der ROT13-Verschiebechiffre nur eine Funktion
sowohl für die Ent- als auch für die Verschlüsselung benötigt wird.
Übung 2.6: ROT13-Verschiebechiffre II
Welche Methoden können bei der ROT13-Verschiebechiffre verwendet werden, wenn nicht nur Groß- sondern auch Kleinbuchstaben in einem Klartext
auftreten? Unter welcher Voraussetzung lässt sich immer noch Modulo 26
rechnen?
2.11 Übungen
Übung 2.7: ROT13-Verschiebechiffre III
Berechnen Sie den Geheimtext für „Spam-Techniken“ durch die ROT13Verschiebechiffre unter der Berücksichtigung, dass Groß- und Kleinbuchstaben getrennt voneinander verschoben werden.
Übung 2.8: Alternativen zu HTTP-GET und HTTP-POST
Finden Sie heraus, welche Methode neben HTTP-GET und HTTP-POST als
Alternative möglich ist.
Übung 2.9: HTML-Formulare
Erstellen Sie eine einfache HTML-Seite, die ein Formular zur Eingabe von
Vornamen, Nachnamen, E-Mail-Adresse und ein Textfeld für einen Gruß enthält. Beschreiben Sie, wie diese Daten auf der Serverseite falsch interpretiert
werden können, damit eine Quelle für Spam entsteht.
Übung 2.10: Shoulder-Surfing
Verwenden Sie eine Suchmaschine Ihrer Wahl, um herauszufinden, was
Shoulder-Surfing ist und welche Abwehrmaßnahmen es dagegen gibt.
Übung 2.11: Malware I
Untersuchen Sie welche verschiedenen Arten es von Malware gibt und
entscheiden Sie, welche der in Definition 2.1 auf Seite 62 vorgestellten Eigenschaften zu den einzelnen Arten passen.
Übung 2.12: Malware II
Finden Sie heraus, was Drive-By-Downloads sind. Wie kann diese Art von
Malware zum Spam-Versand beitragen? Was kann ein Nutzer tun, um diesen
Infektionsvektor zu schließen?
Seite 67
Ü
Ü
Ü
Ü
Ü
Ü
3.1 Lernergebnisse
Sie können sowohl ältere als auch aktuelle Anti-Spam-Techniken benennen und
beschreiben. Sie sind in der Lage, die Funktionsweise dieser Techniken zu erläutern
und auf E-Mails anzuwenden. Des Weiteren können Sie Vor- und Nachteile der
vorgeschlagenen Verfahren benennen.
Wie kann eine Spam-Nachricht erkannt werden, bevor sie dem Empfänger zugestellt wird? Dies ist die zentrale Frage dieses Studienbriefs. Es werden verschiedene
Ansätze vorgestellt, die etwa Nachrichten klassifizieren oder den Absender einer
Nachricht als Spammer erkennen.
3.3 Einleitung
Dieser Studienbrief behandelt unterschiedliche Anti-Spam-Techniken. Dabei beginnt Abschnitt 3.4 mit einfachen Filtermethoden, die ausschließlich nach dem
Inhalt der Nachrichten klassifizieren. Daraufhin werden in Abschnitt 3.5 IP-Sperren
vorgestellt, bei denen nicht der Inhalt für die Klassifikation ausschlaggebend ist,
sondern der Ursprung, also die IP-Adresse des Senders bzw. die Form der Implementierung des E-Mail-Clients des Senders. Weiter werden aktuellere Methoden vorgestellt, wie Reputationsverfahren (Abschnitt 3.6) sowie Challenge- und
Response-Verfahren (Abschnitt 3.7), die nicht über statisch Listen die E-Mails erkennen, sondern unterschiedliche Eigenschaften des Senders zur Klassifikation
verwenden. Danach werden Erweiterungen des klassischen E-Mail-Verfahrens vorgestellt, die eine erfolgreiche Klassifikation erleichtern sollen (Abschnitt 3.8). Die
weiteren Abschnitte beschreiben dann aktuelle Forschungsarbeiten, die sich mit
dem Problem Spam auseinandersetzen. Dabei geht es von der Echtzeitfilterung von
Spam in Abschnitt 3.9 über die Erkennung (Abschnitt 3.11) und Übernahme (Abschnitt 3.12) von Botnetzen zur automatischen Generierung von Spam-Signaturen
(Abschnitt 3.13), bevor eine konkrete Implementierung einer Software zur Spamklassifikation vorgestellt wird (Abschnitt 3.14).
3.4 Mailfilter
Die einfachste Art zur Unterscheidung von Nachrichten in Spam und Ham ist
die Klassifikation durch Filter, wobei die E-Mails auf spezifische Kriterien hin
untersucht werden. Filter können sowohl auf den Header als auch auf den Body
oder auf beide Teile einer E-Mail angewendet werden. Sie können auch sowohl auf
dem Server als auch im E-Mail-Client des Nutzers implementiert sein. Dazu werden
in diesem Abschnitt zuerst Filter betrachtet, die auf Regeln basieren. Danach solche,
die spezielle Signaturen zur Klassifikation einsetzen und abschließend werden
Bayes-Filter stellvertretend für eine Gruppe von statistischen Filtern besprochen.
Regeln
Die Regel-basierte Filterung von Spam kann eine Liste von Wörtern oder regulären
Ausdrücken verwenden, die in einer E-Mail nicht vorkommen dürfen. So können
Regeln definiert werden, die entweder nur auf den Header, nur auf den Body oder
auf die gesamte E-Mail angewendet werden müssen. Diese Regeln können auch
verbunden werden, sodass ein System von Regeln entsteht, das überprüft werden
muss. Diese Lösung kann sehr aufwendig sein, da im einfachsten Fall für jede
Seite 69
Seite 70
einzelne Regel die gesamte Nachricht daraufhin überprüft werden muss, ob sie ein
einziges Wort enthält. Spammer können diese Regeln leicht umgehen, indem sie
bspw. einzelne Wörter nicht mehr verwenden, sondern solche, die ähnlich klingen,
aber anders geschrieben werden. Dabei kann der Vokal I zum Beispiel durch die
Zahl 1 ersetzt werden. Diese Ersetzungen können dann entsprechend wieder in
die Wortlisten eingefügt werden, wodurch die Listen aber immer länger werden
oder die regulären Ausdrücke immer komplizierter.
Daher sind Signaturen eine weitere und verbesserte Form der Mailfilterung.
Signaturen
Bei der Filterung durch Signaturen wird nicht der gesamte Inhalt einer E-Mail
betrachtet. Es geht viel mehr um Eigenschaften der E-Mail, die diese klassifizieren.
Dazu können Hashfunktionen eine kurze Darstellung der E-Mail berechnen, um
diese mit bereits vorhandenen Hashes abzugleichen. Diese Hashes müssen jedoch
robust gegen geringe Abänderungen sein, da zufällige Zeichen in E-Mails enthalten
sein können oder bestimmte Schlüsselwörter, wie weiter oben beschrieben, durch
äquivalente Wörter mit anderer Schreibweise ausgetauscht werden. Sind mehrere Signaturen vorhanden, so können diese innerhalb einer Datenbank verwaltet
werden, müssen jedoch ständig aktualisiert werden, um den Veränderungen der
Spam-Nachrichten zu entsprechen. Die Erstellung einer Signatur muss entweder
manuell erfolgen oder es bedarf einer vorherigen Klassifikation. Die Klassifikation
sollte von Menschen durchgeführt werden, damit die dabei entstehenden Fehler
so gering wie möglich gehalten werden. Signatur-Datenbanken können dann auch
dezentral gehalten werden, damit viele Empfänger von den Signaturen profitieren.
Dafür existieren bereits einige Ansätze (vgl. Damiani et al. [2004]), die bspw. ein
Peer-To-Peer-Protokoll einsetzen, um die so erstellten Signaturen zu verteilen.
Auf Signaturen basierende Filter können zwar bessere Ergebnisse liefern als Regelbasierte, jedoch benötigen beide Methoden menschliches Eingreifen, um die Regeln bzw. Signaturen ständig zu erweitern. Aus diesem Grund sind Filter, die
wahrscheinlichkeitstheoretische Ergebnisse verwenden und nicht ständig vom
Menschen neu trainiert werden müssen, eine sinnvolle weitere Filtermethode.
Bayesfilter
Für die Filterung von Spam nach statistischen Methoden gibt es verschiedene
Ansätze. Die bekannteste Methode geht auf das Bayes-Theorem (vgl. Gleichung 3.1)
des Mathematikers Thomas Bayes (1701-1761) zurück, das erstmalig 1998 in Sahami
et al. [1998] zur Klassifikation von Spam verwendet wurde.
Für zwei Ereignisse A und B mit P(A) > 0 ist die bedingte Wahrscheinlichkeit
(Wahrscheinlichkeit von A gegeben B)
P(A|B) =
P(B|A) × P(A) P(A ∩ B)
=
P(B)
P(B)
(3.1)
wobei P(A ∩ B) der Wahrscheinlichkeit entspricht, dass die Ereignisse A und B
gleichzeitig eintreffen (vgl. Schickinger and Steger [2002]).
3.4 Mailfilter
Seite 71
Das Beispiel 3.1 verdeutlicht die Anwendung des Bayes-Theorems auf SpamNachrichten.
Beispiel 3.1: Bayes-Theorem
Sei A das Ereignis Nachricht ist Spam und B das Ereignis Nachricht enthält die
Zeichenkette „cheap watch“, dann ist P(A|B) die Wahrscheinlichkeit, dass eine
Nachricht Spam ist, wenn sie die Zeichenkette „cheap watch“ enthält.
Sind 5000 E-Mails bereits als Spam klassifiziert, von denen 700 die Zeichenkette „cheap watch“ enthalten und weiterhin 1 000 E-Mails als Ham
klassifiziert, von denen 2 die Zeichenkette „cheap watch“ enthalten, dann
kann P(A|B) berechnet werden mit
P(A|B) =
700
5000
× 5000
6000
702
6000
≈ 99, 72%
Weiterhin können dann noch nicht klassifizierte Nachrichten mit einer Wahrscheinlichkeit von 99,72% als Spam klassifiziert werden, sofern sie die Zeichenkette „cheap watch“ enthalten.
In der Praxis enthalten E-Mails jedoch mehrere Wörter, sodass das Bayes-Theorem
auf beliebig viele Zeichenketten z1 , z2 , . . . , zn erweitert werden muss:
P(A|z1 ∧ z2 ∧ . . . ∧ zn ) =
P(z1 ∧ z2 ∧ . . . ∧ zn |A) × P(A)
.
P(z1 ∧ z2 ∧ . . . ∧ zn )
(3.2)
Dabei beschreibt Gleichung 3.2 die Wahrscheinlichkeit dafür, dass eine E-Mail
als Spam klassifiziert werden kann, wenn sie die Wörter z1 und z2 und . . . und zn
enthält. Nach Schryen [2007] kann Gleichung 3.2 umgeformt werden zu
P(A|z1 ∧ z2 ∧ . . . ∧ zn ) =
∏i P(zi |zi+1 ∧ . . . ∧ zn ∧ A) × P(A)
.
P(z1 ∧ z2 ∧ . . . ∧ zn )
(3.3)
Ein Bayes-Filter wird weiterhin als naïve bezeichnet, sofern er vollständige stochastische Unabhängigkeit zwischen dem Auftreten der einzelnen zi annimmt. In
diesem Fall kann Gleichung 3.3 vereinfacht werden zu
P(A|z1 ∧ z2 ∧ . . . ∧ zn ) =
∏i P(zi |A) × P(A)
.
P(z1 ∧ z2 ∧ . . . ∧ zn )
(3.4)
Genauso wie die Wahrscheinlichkeit dafür, dass einer Nachricht Spam ist, berechnet werden kann, so kann äquivalent auch berechnet werden, ob es sich bei einer
Nachricht um Ham handelt. Diese Tatsache kann für die Lösung einer Übungsaufgabe hilfreich sein.
Insgesamt bieten Mailfilter einige Nachteile. Sie sind zwar einfach zu implementieren und zu warten, jedoch sind sie sehr ungenau, sodass eine fehlerhafte Klassifikation nicht selten passiert. Dabei sind vor allem die falsch positiven Ergebnisse
ein Störfaktor, da reguläre E-Mails, die fälschlicherweise ausgefiltert werden, vom
Empfänger nicht gelesen werden können und der Sender oftmals nicht über die
nicht erfolgte Zustellung unterrichtet wird. Filtermethoden haben oft eine hohe
Ressourcenauslastung. Ist der Filter im E-Mail-Client installiert, so muss auch
zuerst die gesamte E-Mail heruntergeladen werden, wenn bspw. der Body der
Nachricht untersucht werden soll. Weiterhin haben Spam-Versender auf Mailfilter
reagiert, indem sie die Spam-Nachrichten regulärer Nachrichten angleichen. Daher
B
Seite 72
wird im nächsten Abschnitt eine Methode vorgestellt, die nicht nur den Inhalt
einer Nachricht zur Klassifikation verwendet.
Kontrollaufgabe 3.1: Mailfilter
K
Welche Arten von Mailfiltern gibt es?
Kontrollaufgabe 3.2: Bayesfilter
K
Nennen Sie eine intuitive und kurze Definition eines Bayesfilters.
3.5 IP-Sperren
Bei Verbindungen zwischen zwei Teilnehmern im Internet ist die IP-Adresse beider
Teilnehmer von essentieller Bedeutung. Nur anhand dieser Adresse wissen die
Router, die sich auf dem Weg zwischen den beiden Teilnehmern befinden, wohin
ein Paket geschickt werden soll. Bei Verbindungen zu einem E-Mail-Server ist
dies nicht anders. Auch der SMTP-Server muss wissen, zu welcher IP-Adresse
Antworten geschickt werden müssen. Dabei offenbart die IP-Adresse eines Senders viele Informationen. Zum Beispiel kann über die IP-Adresse herausgefunden
werden, aus welchem Land ein Kommunikationspartner kommt und auch über
welchen ISP er mit dem Internet verbunden ist. Da Mechanismen zur Abwehr
von Spam davon ausgehen, dass ein Spammer von einem nicht eine sondern viele
Nachrichten verschickt, erscheint es als sinnvolle Möglichkeit, die IP-Adresse des
Absenders zur Spam-Klassifikation zu verwenden. Insgesamt setzen IP-Sperren
also an genau diesem Punkt an. Wurde von einem bestimmten Computer einmal eine Spam-Nachricht verschickt, so wird davon ausgegangen, dass dieser Computer
in naher Zukunft auch weiterhin Spam-Nachrichten verschicken wird.
IP-Sperren werden über Listen realisiert. Dabei existieren schwarze Listen (engl.
Blacklisting, vgl. Abschnitt 3.5.1), die IP-Adressen von Computern enthalten, von
denen bekannt ist, dass sie Spam versenden. Weiße Listen (engl. Whitelisting, vgl.
Abschnitt 3.5.2) sind davon genau das Gegenteil. Sie werden dazu verwendet,
Absender zu identifizieren, die von weiteren Prüfungen komplett ausgeschlossen werden können. Eine Methoden zwischen den beiden genannten Verfahren
sind graue Listen (engl. Graylisting, vgl. Abschnitt 3.5.3. Hier wird Spam durch
technische Schwächen der von Spamversendern genutzten Software erkannt.
3.5.1 Blacklisting
RFC 5782, DNSBL
Blacklisting (vgl. Levine [2010]) ist eine Technik, die im SMTP-Server genutzt wird,
um IP-Adressen zu identifizieren, die für Spam verantwortlich sind. Dabei erhält
der SMTP Server beim Verbindungsaufbau die IP-Adresse der Gegenseite und
muss dann kurzfristig entscheiden, ob der Verbindungsaufbau durch den Versand
von Spam motiviert ist, oder ob es sich um eine reguläre Anfrage handelt. Diese
Entscheidung kann getroffen werden, indem bspw. auf dem Server eine Datenbank
verwaltet wird, die IP-Adressen von Spamversendern enthält. Das nun entstehende
Problem ist jedoch, dass ein Großteil des weltweiten Spams nicht von wenigen
IP-Adressen (vgl. offene Mail-Relays und offene Proxys in Abschnitt 2.5 ab Seite 55)
sondern von Botnetzen (vgl. Abschnitt 2.9 ab Seite 61) verursacht wird. Botnetze
bestehen aber wiederum aus einzelnen Bots, deren IP-Adressen sich bedingt durch
Wählverbindungen (Telefon bzw. ISDN) oder Zwangstrennungen (DSL) ständig
ändern. Es ist somit nicht möglich, eine IP-Adresse, die einmal Spam versendet
3.5 IP-Sperren
hat, ewig auf eine schwarze Liste zu setzen. Das Blacklisting setzt somit eine gewisse Dynamik voraus. IP-Adressen müssen sowohl entfernt als auch hinzugefügt
werden können. Wird auf einem Server eine Datenbank eingesetzt, so kann bspw.
ein Schwellwert, der die in einem bestimmten Zeitraum erhaltenen E-Mails zählt,
entscheiden, ob eine IP-Adresse geblockt werden soll. Eine solche dezentrale Lösung birgt aber die Gefahr, dass immer nur Verbindungsversuche von Computern
geblockt werden, die bereits vorher vom eigenen Server als Spamversender klassifiziert wurden. Eine sinnvollere Lösung bieten dabei schwarze Listen, die zentrale
verwaltet und dann global genutzt werden können. Hierbei können dann auch
Spamversender von einem SMTP-Server erkannt werden, die durch eine Klassifikation innerhalb eines anderen Netzwerks gefunden wurden. Eine Aktualisierung
des Datenbankstandes kann auf verschiedenen Wegen durchgeführt werden. Es
ist bspw. denkbar, dass der Datenbestand per HTTP abgefragt oder FTP verteilt
werden könnte. Als sinnvoller Verbreitungsweg hat sich dabei jedoch DNS (vgl.
Abschnitt 1.5.6 ab Seite 30) herausgestellt. DNS-Blacklists (DNSBL) benötigen,
damit sie genutzt werden können, nur einen gewöhnlichen DNS-Server, der über
eine Liste durch den Spamversand auffällig gewordenen IP-Adressen verfügt. Eine
Anfrage eines SMTP-Servers an eine DNSBL geschieht dabei in den folgenden vier
Schritten:
1. Der SMTP-Server empfängt eine Verbindungsanfrage von einem Client mit
der IP-Adresse 12.34.56.78, die es zu untersuchen gilt. Er dreht daraufhin
die einzelnen Teile der IP-Adresse um und erhält 78.56.34.12.
2. An den bereits erzeugten Teil des Namens wird der Domain-Name der
DNSBL angehängt. Handelt es sich bspw. beim DNSBL um dnsbl.rub.de,
so wird die Zeichenkette 78.56.34.12.dnsbl.rub.de erstellt.
3. Für die so erstellte Zeichenkette wird dann per DNS die IP-Adresse erfragt.
Als Antwort kann dann entweder eine Adresse kommen. Diese Antwort
besagt, dass die angefragte IP-Adresse auf der Liste des Anbieters vorhanden
ist, oder es wird die Antwort NXDOMAIN (No such domain) zurückgegeben,
die besagt, dass es keinen Eintrag in der Liste gibt.
4. Der Server kann dann noch optional beim DNSBL-Server anfragen, warum
die IP-Adresse auf der Liste steht, um ggf. weitere Informationen dazu zu
erhalten.
Blacklists können erfolgreich eingesetzt werden, wenn Verbindungsanfragen aus
Netzen kommen, die für den Versand von Spam bekannt sind, da sie auf ganze
Netzbereiche ausgeweitet werden können. Insbesondere können Blacklists effektiv
sein, wenn nach bestimmten Clients gesucht wird, die schon seit langer Zeit aktiv
Spam versenden und keine dynamische IP-Adresse habe. Blacklists haben aber
auch eine Reihe von Nachteilen. So können sie gerade bei dynamischen IP-Adressen
schnell zu Fehlern führen, sobald ein Client von seinem Provider eine IP-Adresse
zugeteilt bekommt, die gerade von einem Bot verwendet worden ist, der zum
Versand von Spam missbraucht wurde. Blacklists können nie vollständig aktuell
sein, gerade weil zuerst erkannt werden muss, dass es sich um eine IP-Adresse
handelt, die Spam versendet. Genauso können Blacklists ganze IP-Adressbereiche
enthalten, die zu ISPs gehören, die von Spammern missbraucht wurden. Hiermit wird dann auch der reguläre E-Mail-Verkehr gestört, da der gesamte Bereich
blockiert wird. Weiterhin erhöhen gerade DNS-basierte Blacklists den gesamten
Datenstrom im Internet, da ständig neue DNS-Anfragen gestellt werden müssen.
Das größte Problem ist jedoch, dass DNS somit zu einer Ressource wird, deren
Kompromittierung auch für Spammer interessant wird, da sie durch Störungen
bei DNS effektiver Spam verbreiten können, was aber auch gleichzeitig zu einer
Störung im WWW führt, da dann auch andere Adressen nicht mehr aufgelöst
werden können und es somit möglich ist, dass Server nicht gefunden werden.
Seite 73
Seite 74
Aufgrund der Tatsache, dass Backlists eine hohe Fehlerrate erzielen, wird in Sinha
et al. [2010] eine Überarbeitung des Konzeptes vorgestellt. Hierbei sollen globale Blöcke von IP-Adressen nicht mehr blockiert werden. Genauso soll auch die
Reputation ganzer Netze nicht mehr zur Klassifikation herangezogen werden.
Dagegen wird untersucht, wie gut Spammer erkannt werden können, wenn lokale
Faktoren berücksichtigt werden. Dazu werden zwei neue Techniken vorgestellt,
zum einen die Verwendung eines dynamischen Schwellwertes und zum anderen
eine spekulative Aggregation von IP-Adressen.
Abb. 3.1: Der ursprüngliche Ansatz, um Blacklists zu erstellen aus
Sinha et al. [2010].
Ursprünglich werden Blacklisten erstellt, indem Spam in sogenannten Spam-Traps
landet. Spam-Traps sind spezielle E-Mail-Adressen, die im Internet auf diversen
Webseiten verbreitet werden, die jedoch keinen regulären Personen zugeordnet
sind und nicht für die normalen Kommunikation per E-Mail verwendet werden.
E-Mails, die diese Postfächer erreichen, können mit sehr großer Wahrscheinlichkeit
als Spam gewertet werden. Die E-Mails, die in mehreren Spam-Traps landen können
dann gruppiert werden und deren Absenderadressen können daraufhin in eine
Blacklist eingetragen werden. Dieses Konzept veranschaulicht Abbildung 3.1.
Die Autoren schlagen nun vor, das System um bestimmte Eigenschaften zu ergänzen, um die Erkennung von Spam zu verbessern und damit auch bessere Blacklists
zu erstellen. Um Blacklisten zu erstellen, werden normalerweise statische Faktoren verwendet. Haben bspw. 30 % aller verfügbaren Spam-Traps Spam von einer
bestimmten IP-Adresse erhalten, so wird die IP-Adresse in die Blacklist eingefügt.
Im neuen Ansatz (vgl. Abbildung 3.2) wird aus diesem statischen Schwellwert ein
dynamischer Schwellwert. Die Berechnung des Wertes wird verändert, indem auch
die Anzahl der E-Mails bewertet wird, die von einer IP-Adresse an den lokalen
SMTP-Server versendet wurden. Somit fließen nicht nur globale Informationen
in den Schwellwert ein sondern auch lokale Informationen. Auf die zweite Eigenschaft des vorgestellten System soll an dieser Stelle nicht weiter eingegangen
werden, da sich die Übungsaufgaben mit diesem Thema beschäftigen.
3.5 IP-Sperren
Seite 75
Abb. 3.2: Der neue Ansatz, um Blacklists zu
erstellen aus Sinha et al.
[2010].
Der nächste Abschnitt befasst sich mit einer sehr ähnlichen Technik, dem Whitelisting.
3.5.2 Whitelisting
Das Whitelisting wird ähnlich wie das Blacklisting auch in RFC 5782 (vgl. Levine
[2010]) beschrieben. Es handelt sich dabei um eine Technik, bei der eine Liste mit
erwünschten IP-Adressen zur Klassifikation verwendet wird. Genauso wie beim
Blacklisting kann diese Liste lokal erstellt und verwendet werden, aber auch global
gehalten werden. Handelt es sich um eine globale Liste, die per DNS zur Verfügung
gestellt wird, so wird in diesem Fall von einer DNS-Whitelist (DNSWL) gesprochen.
Im Gegensatz zu Blacklists, bei denen davon ausgegangen wird, das alle Einträge
auf der Liste zu Spam-Versendern gehören, deren Absenderadressen willkürlich
gewählt werden, können die Einträge auf Whitelists anstelle von IP-Adressen auch
E-Mail-Adressen enthalten. Sind diese E-Mail-Adressen allerdings bekannt, so
haben Spammer die Möglichkeit, eine solche Adresse als Absenderadresse in ihre
Spam-Nachrichten einzufügen, damit die E-Mail an den Empfänger übertragen
wird und nicht durch den SMTP-Server blockiert wird. Es sollte dabei außerdem
auch beachtet werden, dass Whitelisting als einzelne Technik zur Klassifikation
von Spam und Ham eine sehr große Fehlerrate hat. Beim Whitelisting werden
alle E-Mails, die nicht auf der Liste stehen, als Spam deklariert. Dieses rigorose
Vorgehen führt dazu, dass nur eine fest definierte Anzahl an Absendern überhaupt
als Sender infrage kommt und alles andere blockiert wird. Ist eine E-Mail-Adresse
nur für die Kommunikation mit bestimmten anderen Konten vorgesehen, so kann
dieses Vorgehen den Spam vollständig beseitigen. Im Normalfall soll die E-MailAdresse aber auch von anderen Nutzern erreichbar sein, was unter ausschließlicher
Verwendung des Whitelistings ausgeschlossen ist. Aus diesem Grund sollte das
RFC 5782, DNSWL
Seite 76
Whitelisting nur in Kombination mit dem Blacklisting oder anderen Techniken
verwendet werden.
Der nächste Abschnitt befasst sich mit der letzten vorgestellten Technik zu IPSperren, dem Graylisting.
3.5.3 Graylisting
Obwohl es der Name vermuten lassen könnte, ist Graylisting keine Kombination
aus Whitelisting und Blacklisting. Vielmehr handelt es sich beim Graylisting um
eine durchdachte Ausprägung einer Listentechnik, die vollständig auf globale bzw.
externe Dienste verzichtet. Beim Graylisting wird davon ausgegangen, dass die
meisten Spam Nachrichten aus Botnetzen (vgl. Abschnitt 2.9 ab Seite 61) stammen.
Die Bots wiederum implementieren jedoch nicht die vollständige Funktionalität
von SMTP, besonders wird auf eine Fehlerbehandlung verzichtet, um die Implementierung möglichst einfach und schnell zu halten. Genau diesen Mangel macht sich
das Graylisting zu nutze, um reguläre E-Mails von Spam zu unterscheiden. Genau
wie das Blacklisting und das Whitelistung setzt das Graylisting beim SMTP-Server
an. Beim Verbindungsaufbau empfängt der SMTP-Server den E-Mail-Header, speichert die IP-Adresse des Senders, die Absender-Adresse aus dem E-Mail-Header
und auch die Empfänger-Adresse aus dem E-Mail-Header in einer Liste. Anschließend schließt der SMTP-Server die Verbindung und gibt vorher einen temporären
Fehlercode (vgl. Exkurs 1.10 auf Seite 21) an den Client zurück. Der temporäre
Fehler signalisiert dem Client, dass der Server aktuell nicht voll funktionstüchtig
ist, der Client aber nach einer kurzen Zeitspanne den Nachrichtentransfer erneut
versuchen kann. Reguläre E-Mail-Clients, die SMTP vollständig implementieren,
verstehen die Antwort, warten daraufhin eine festgelegte Zeitspanne und versuchen den Versand der E-Mail erneut. Unvollständig implementierte Bots befassen
sich nicht weiter mit dem Versand der Spam-Nachricht an den entsprechenden
Empfänger sondern versenden Spam an die weiteren Empfänger in ihrer Liste. Versucht nun der reguläre Sender eine erneute Zustellung der E-Mail und verbindet
sich mit dem SMTP-Server, so überprüft dieser in seiner Liste, ob das Tripel aus
IP-Adresse, Absender-Adresse aus dem Header und Empfänger-Adresse aus dem
Header bereits versucht hat, eine E-Mail zuzustellen. Es wird auch überprüft, ob
die Zeitspanne zwischen dem ersten und dem nun zweiten Versuch groß genug
war. Allgemeine handelt es sich bei der ersten Zeitspanne um 25 Minuten. Treffen
diese Annahmen alle zu, so wird die E-Mail angenommen bzw. an den Empfänger
weitergeleitet und der Absender für eine länger Zeitspanne in eine Whitelist übernommen. Meldet sich der Absender hingegen nicht innerhalb von vier Stunden
nach dem ersten Zustellversuch, so wird der erste Eintrag aus der Liste entfernt.
Insgesamt bietet Graylisting die folgenden Vorteile:
• Bei der Nutzung von Graylisting muss der Anwender an seinem Client
keine Änderungen vornehmen. Bei der normalen Arbeit merkt er nicht, dass
Graylisting eingesetzt wird.
• Der Administrator eines SMTP-Servers muss sich um keine Aktualisierungen der Liste kümmern und kann eine Graylist mit relativ wenig Aufwand
in seine Konfiguration einfügen.
• Die Hardwareressourcen, die benötigt werden, um zum einen die Liste zu
speichern und zu verwalten und zum anderen eintreffende E-Mails mit
einem Fehlercode abzuweisen, sind im Vergleich zu anderen Verfahren sehr
klein. Dadurch ist es auch problemlos möglich, weitere dahinter geschaltete
Verfahren auf die weitergeleiteten E-Mails anzuwenden, um Nachrichten,
die von Bots mit einer vollständigen Implementierung von SMTP ausgehen,
weiter zu behandeln.
3.5 IP-Sperren
Seite 77
Es existieren aber auch Nachteile:
• Aufgrund der Zeitverzögerung wird die erste E-Mail zu einem Tripel aus
Absender-IP, Absender-Adresse und Empfänger-Adresse je nach Implementierung erst nach eine bestimmten Zeitspanne an den Empfänger versendet.
Eines der Kernziele der E-Mail ist jedoch die Geschwindigkeit, die an dieser
Stelle leidet. Diese Zeitverzögerung kann besonders dann zu einem Hindernis werden, wenn ein Nutzer auf einer Webseite die Zugangsdaten zu
seinem Konto zurücksetzen möchte und neue Zugangsdaten per E-Mail
anfordert. Die neuen Zugangsdaten werden dann bedingt durch die Zeitverzögerung erst nach einer festgelegten Zeitspanne empfangen, wobei der
Webserver so konfiguriert sein kann, dass die neuen Zugangsdaten nur
für eine gewisse Zeitspanne gelten. Im schlimmsten Fall hat der Nutzer
dann also keinen Zugriff mehr auf sein Konto und kann auch keinen neuen
Zugriff ohne menschliche Hilfe erlangen.
• Server, die nur zu RFC 821 kompatibel sind, können den temporären Fehler
als permanenten Fehler interpretieren und versuchen daher nach dem ersten
gescheiterten Zustellversuch keinen erneuten Versuch.
• Graylisting entspricht grundsätzlich nicht der RFC 2821 (vgl. Klensin [2001]),
da innerhalb der RFC generelle temporäre Fehler nicht spezifiziert sind.
Daher muss ja nach Greylist-Implementierung auch ein Fehlercode zurückgesendet werden, der nicht auf den wahren Grund des Fehler hinweist.
RFC 2821
• Außerdem ist Greylisting von Spammern sehr einfach zu umgehen. Die
Software zum Spamversand auf den Bots muss nur soweit erweitert werden,
dass bei einem temporären Fehler ein erneuter Zustellversuch nach einer
bestimmten Zeitspanne unternommen wird.
• Bei dem Einsatz von mehreren SMTP-Servern für die gleiche Domain muss
darauf auch geachtet werden, dass es sich bei der Graylist-Datenbank um eine unter den Servern verteilte Datenbank handelt. In einem solchen Szenario
kann nämlich nicht ausgeschlossen werden, dass der zweite Zustellversuch
auf einem anderen SMTP-Server stattfindet.
Ob Graylisting eingesetzt werden soll, das muss der jeweilige Administrator entscheiden und dabei die Vor- und Nachteile gegeneinander abwägen.
beitragen sollen.
Kontrollaufgabe 3.3: IP-Sperren I
Was sind IP-Sperren und welche verschiedenen Arten existieren?
Kontrollaufgabe 3.4: IP-Sperren II
An welcher Stelle werden IP-Sperren eingesetzt?
K
K
Seite 78
K
K
K
K
K
K
Kontrollaufgabe 3.5: Blacklisting I
Welche verschiedenen Arten gibt es, um Blacklisting zu praktizieren?
Kontrollaufgabe 3.6: Blacklisting II
Welche vier Schritte sind beim DNS-basierten Blacklisting notwendig, um
eine IP-Adresse zu überprüfen?
Kontrollaufgabe 3.7: Blacklisting III
Nennen Sie Vor- und auch Nachteile für den Einsatz von Blacklists.
Kontrollaufgabe 3.8: Whitelisting
Was ist Whitelisting und welchen Zweck verfolgt es?
Kontrollaufgabe 3.9: Graylisting
Was macht Graylisting im Gegensatz zu White- und Blacklisting zu einer
besonderen Art der IP-Sperren und warum kommt es auch ohne externe
Dienstanbieter aus?
Kontrollaufgabe 3.10: Graylisting II
Nenne Sie jeweils zwei Vor- und zwei Nachteile von Graylisting.
3.6 Reputationsverfahren
Verfahren, die nicht den Inhalt einer E-Mail auswerten, sondern Metaeigenschaften
zur Klassifikation betrachten, werden als Reputationsverfahren bezeichnet. Eine
konkrete Implementierung eines Reputationsverfahren stellt SNARE dar (vgl. Hao
et al. [2009]). Die Motivation für SNARE war, dass IP-Blacklisting zu schwerfällig
ist und durch Botnetze relativ leicht umgangen werden kann. Blacklisting hat
den Nachteil, dass eine IP-Adresse als Ursprung von Spam ausfindig gemacht
werden muss, bevor sie geblockt werden kann. Dabei haben viele Computer im
Internet eine dynamische IP-Adresse, wodurch ein vorhandener Eintrag in einer
Blacklist nach einem Neuzuweisung einer IP falsch werden kann. Blacklisting hat
daher auch den Nachteil, dass grob 10 % der Spam-Versender vorher noch nicht
als Spammer klassifiziert wurden (vgl. Ramachandran et al. [2007]), wodurch die
Wartung der Listen sehr aufwendig wird. Weiterhin wurde herausgefunden, dass
etwa 20 % der E-Mails, die in eine Spamtrap gehen, nicht auf Blacklists enthalten
(vgl. Ramachandran and Feamster [2006]) sind. Daher wurde in SNARE ein Ansatz
realisiert, der ausschließlich auf den Netzwerkeigenschaften von E-Mails basiert
und ohne die Betrachtung der Inhalte der Nachrichten auskommt.
Die von den Autoren betrachteten Eigenschaften zur Klassifizierung von Nachrichten lassen sich in drei Gruppen einteilen. Zum einen werden Eigenschaften
eingeführt, die nur auf einzelnen Netzwerkpaketen beruhen. Dazu kommt die
3.6 Reputationsverfahren
Seite 79
zweite Gruppe von Eigenschaften, die nur auf einzelnen E-Mail-Headern oder
ganzen Nachrichten aufbaut. Zuletzt werden dann noch über mehrere Nachrichten
gesammelte Eigenschaften betrachtet.
Bei der ersten Gruppe von Merkmalen handelt es sich konkret um die folgenden
Eigenschaften:
1. Die geodätische Distanz zwischen Sender und Empfänger.
Reguläre E-Mails legen normalerweise einen eher kurzen Weg zurück, da es
sich oft um eine Kommunikation handelt, die im gleichen Land stattfindet.
Spam dagegen legt weitere Strecken zurück, sodass der Ursprung oft in
einem anderen Land oder sogar von einem anderen Kontinent stammt.
Geodätische Distanz
2. Die Nachbarschaft der Spam-Versender.
Die von den Autoren der Arbeit aufgestellte These lautet, dass Spamversender oft von anderen Spamversendern umgeben sind. Diese Behauptung
wird in viele Arbeiten verwendet und lässt sich auch leicht nachvollziehen.
Gruppen von Computern werden oft durch einzelne Instanzen verwaltet,
die gewisse Richtlinien auf alle verwalteten Computer anwenden. So kann
bspw. die Software auf einer Menge von Computern den gleichen Versionsstand haben, wodurch eine Sicherheitslücke alle verwalteten Computer
betrifft. Wird nun einer dieser Computer mit Malware infiziert, so trifft dies
früher oder später auch auf die anderen Computer desselben Netzwerkes
zu. Da die Malware zum Versand von Spam verwendet werden kann, würden dann alle kompromittierten Computer Spam versenden, wodurch die
Behauptung bestätigt wird.
Nachbarschaft
3. Die Tageszeit des Spamversandes.
Der Versand von Spam ist geprägt durch die An- und Ausschaltmuster der
Computer. So werden bspw. Spam-Nachrichten vermehrt Morgens versandt,
wenn viele Computer eingeschaltet sind. Der reguläre Nachrichtenversand
weist jedoch ein anderes Muster auf, wodurch eine Klassifikation denkbar
wird.
Tageszeit
4. Das autonome System des Versender.
Da nur wenige autonome Systeme für einen großen Anteil des Spams verantwortlich sind, kann die Nummer des autonomen Systems als Eigenschaft
zur Klassifikation herangezogen werden.
Autonomes System
5. Der Status der einzelnen Ports des Versenders.
Versender von regulären E-Mails sind im Normalfall Server, die auch gleichzeitig für den Eingang von E-Mails verwendet werden. Damit sie von den
Nutzern für den Eingang von E-Mails verwendet werden können, müssen
entsprechende Ports offen sein, damit sich die E-Mail-Clients der Nutzer an
den Server verbinden kann. Computer, die zum Spamversand verwendet
werden, haben normalerweise keine offenen Ports in diesen Bereichen. Daher kann eine Klassifikation nach offenen Ports mögliche Spamversender
identifizieren.
Port-Status
Weiterhin wurden Merkmale aus einzelnen Nachrichten extrahiert.
1. Die Anzahl der Empfänger.
Oft werden Spam-Nachrichten nicht nur an einen sondern an mehrere Empfänger versendet. Ham hat dagegen meist einen oder wenige Empfänger.
Anzahl Empfänger
2. Die Größe der E-Mail.
Reguläre E-Mails variieren in ihrer Größe sehr stark. Es können Bilder oder
Anhänge enthalten sein, wodurch die Nachrichten groß werden können. Ist
nur wenig Text enthalten, so kann die Nachricht sehr klein werden. Spam
E-Mail-Größe
Seite 80
wird häufig aus Templates generiert, wodurch die Nachrichten einer Kampagne eine sehr ähnlich Größe haben. Spam tendiert außerdem dazu, relativ
kein zu sein, wenn bspw. nur ein einzelner Link verschickt wird.
Dazu wurden dann Merkmale betrachtet, die durch Sammlung von mehreren
E-Mails einer IP-Adresse erkennbar wurden.
• Der geodätischen Abstand zwischen Sender und Empfänger.
• Die Anzahl der Empfänger.
• Die Länge der Nachricht.
Für diese Merkmale wurde der Mittelwert sowie die Varianz berechnet und das
Resultat dann als Eigenschaft mitberücksichtigt. Diese Merkmale wurden in den
Prototypen SNARE implementiert und getestet. Dabei zeigt Abbildung 3.3 die
gesamte Funktionsweise des SNARE-Frameworks.
Abb. 3.3: Das SNARE Framework aus
Ramachandran and
Feamster [2006].
Die Autoren planen dabei ein, dass ihr System auf einem dedizierten Rechner
läuft und beschreiben den Arbeitsablauf wie folgt: Nachdem ein SMTP-Server das
erste IP-Paket erhalten hat, wird eine Verbindung zum SNARE-Server aufgebaut
und die oben beschriebenen Informationen übertragen. Dabei kann auch direkt
die ganze Nachricht übertragen werden, wobei in diesem Fall länger gewartet
werden muss, als es für das erste IP-Paket der Fall wäre. Hier muss also zwischen
Erkennungsgenauigkeit und Geschwindigkeit entschieden werden. In einem zweiten Schritt werden E-Mails aussortiert, die über eine Whitelist gefunden werden.
Wird eine E-Mail nicht durch einen Eintrag einer Whitelist erkannt, so wird diese
durch SNARE analysiert, bevor andere Spamfilter oder Inhalts-basierte Analysen
stattfinden. E-Mails erhalten daraufhin eine Bewertung und werden danach in
einem dritten Schritt entweder schnell behandelt bzw. direkt weitergeleitet, sofern
es sich um Ham handelt, oder können weiteren Methoden wie einem Graylisting
unterzogen werden. Ergebnisse, bestehend sowohl aus Ham als auch aus Spam,
können in einem vierten Schritt zurück an die Klassifikation von SNARE geschickt
werden, um diese besser zu trainieren.
3.7 Challenge-Response-Verfahren
Challenge-Response-Verfahren werden im Allgemeinen zur Authentifikation von
Nutzern oder Computern untereinander verwendet. Dabei wird der anmeldenden Instanz eine Aufgabe gestellt, deren Lösung sie zur Anmeldung autorisiert.
3.7 Challenge-Response-Verfahren
Dieses Verfahren kann angewendet werden, um einem Anwender eine Informationen zu zeigen, die bspw. von Bots nicht erkannt werden soll. Dazu werden
CAPTCHAs (vgl. Abschnitt 2.4.3 ab Seite 49) eingesetzt, bei denen der Anwender
entweder Buchstaben aus einem Bild erkennen soll oder gesprochene Wörter aus
einer Aufnahme identifizieren soll. In beiden Fällen können die CAPTCHAs erschwert werden, indem Hintergrundrauschen eingefügt wird. Hierbei kann jeder
die Aufgabe lösen, der die Buchstaben identifiziert oder die Wörter erkennt. Um es
Spammern zu erschweren, ihren Spam zu versenden, können Challenge-ResponseVerfahren auch eingesetzt werden. Hierbei wird davon ausgegangen, dass sich
Spammer ausschließlich um den Versand ihrer Nachrichten kümmern, allerdings
keine Fehlerbehandlung durchführen. Wird nun eine E-Mail vom Absender an den
Empfänger verschickt, so kann der empfangende SMTP-Server die E-Mail temporär
zwischenspeichern und den Absender dazu auffordern, zuerst eine Aufgabe zu
lösen. Erst durch das Lösen der Aufgabe wird die temporär zwischengespeicherte
E-Mail dann an den Empfänger weitergeleitet. Erhält ein reguläre Absender eine
solche Aufforderung, kann er sich mit der Aufgabe auseinandersetzen und sie
lösen. Ein Bot, der nicht für den Empfang von Nachrichten ausgelegt ist, beachtet
die Aufgabe nicht und somit wird die temporäre Nachricht nach einem bestimmten
Zeitintervall verworfen.
Mithilfe dieser Technik können viele Spam-Nachrichten aussortiert werden. Es
existiert jedoch eine Reihe von Gründen, die Challenge-Response-Verfahren für
den alltäglichen Gebrauch ausschließen:
• Die Nutzung des Verfahrens macht die Kommunikation per E-Mail zu einem komplizierten Unterfangen. Für jede versendete Nachricht muss vom
empfangenden SMTP-Server erst eine Anfrage an den Versender geschickt
werden, die diesen um die Lösung einer Aufgabe bittet. Weiterhin muss
der Versender der ursprünglichen Nachricht Zeit in die Lösung der Aufgabe stecken, bevor seine E-Mail an den Empfänger weitergeleitet wird.
Dadurch verzögert sich der gesamte Vorgang und macht die E-Mail als
Kommunikationsmedium weniger interessant.
• Bedingt durch die zusätzlichen E-Mails wird der gesamte Datenverkehr im
Internet weiter erhöht.
• Weiterhin werden auch Versender von regulären Massen-E-Mails wie
Newslettern am Versand der Nachrichten gehindert, da für jeden einzelnen Empfänger eine Aufgabe gelöst werden müsste, was einen sehr großen
Aufwand darstellt.
• Oft versenden Spammer Nachrichten, bei denen die Absenderadresse gefälscht ist, um möglichst unauffällig zu agieren. Wird nun die Absenderadresse gefälscht, so erhalten Unbeteiligte die Aufforderung zur Lösung
einer Aufgabe, was in deren Augen wieder als Spam betrachtet werden
kann.
• Aufgaben, welche die Lösung eines CAPTACHs voraussetzen, diskriminieren damit seh- oder hörbehinderte Menschen, die solche Aufgaben nicht
lösen können. Genauso können nicht behinderte Menschen nicht dazu in
der Lage sein, ein CAPTCHA zu lösen, sofern das Hintergrundrauschen zu
groß ist.
• Spammer können die Aufgaben von Menschen lösen lassen, indem sie die
CAPTCHAs an andere weiterleiten und dabei bestimmte Anreize zum
Lösen anbieten. Somit verlagern die Spammer das Problem auf andere
Menschen und leiden folglich nur an zeitlichen Verzögerungen, wobei die
Spam-Nachrichten jedoch nicht durch das Challenge-Response-Verfahren
aussortiert werden.
Seite 81
Seite 82
Bedingt durch die aufgeführten Nachteile eignet sich die Versendung des
Challenge-Response-Verfahrens nur in Ausnahmefällen oder unter Zuhilfenahme
von anderen Verfahren.
3.8 Erweiterungen des E-Mail-Verfahrens
Die Spezifikationen für den Versand von E-Mails wurden zu einer Zeit entwickelt,
als niemand daran dachte, dass das System auch für kriminelle Handlungen, wie
den Versand von Spam, verwendet werden könnte. Um die Mängel des System zu
beheben, wurden unterschiedliche Erweiterungen vorgeschlagen. Einige dieser
Erweiterungen werden innerhalb dieses Abschnittes beschrieben. Dabei handelt
es sich zum einen um Systeme, die den E-Mail-Header erweitern, um zu zeigen,
dass der Sender die Erlaubnis zum Versand hat (DKIM, SFP, Sender ID) oder
eine bestimmte Arbeit verrichtet hat (Hashcash). Zum andern wird ein Ansatz
vorgestellt, bei dem der Empfänger Möglichkeiten zur Steuerung des Empfangs
hat (Receiver driven SMTP).
3.8.1 DomainKeys / DKIM
RFC 6376
DomainKeys sind ein System zur Authentifizierung von E-Mails, das im Mai 2007
von Yahoo! Inc. als Mittel zur Bekämpfung von Spam in RFC 4870 (vgl. Delany
[2007]) vorgestellt wurde. Unter dem Namen DomainKeys Identified Mail (DKIM)
Signatures wurde das Verfahren in RFC 4871 (vgl. Allman et al. [2007]) spezifiziert.
Nach einer Aktualisierung in RFC 5672 (vgl. Crocker [2009]) wurde mit RFC 6376
(vgl. Crocker et al. [2011]) die aktuelle Fassung im Jahr 2011 veröffentlicht.
Wie in Studienbrief 1 ab Seite 9 beschrieben, werden beim Versand von E-Mails
für den Absender zwei unterschiedliche Felder verwendet. Der beim Empfänger
angezeigte Absender muss also nicht dem Versender entsprechen. Eine Reihe
von Spam-Kampagnen, die insbesondere zur Durchführung von Phishing (vgl.
Abschnitt 1.9 ab Seite 36) verwendet werden, fälschen die Absenderadresse ihrer
versendeten E-Mails, um den Empfänger zu täuschen. So erhalten Empfänger
E-Mails von Banken, die täuschend echt aussehen und auch anscheinend von der
Bank verschickt wurden. DKIM setzt an dieser Stelle an, indem es den Versender
mithilfe asymmetrischer Kryptographie (vgl. Exkurs 3.2 auf Seite 85) gegenüber
dem Empfänger verifiziert. Grob gesagt wird dazu der Hash einer E-Mail mit dem
privaten Schlüssel einer Organisation verschlüsselt und mit der E-Mail zusammen
versendet. Der Empfänger kann dann per DNS den öffentlichen Schlüssel anfordern, den Hash entschlüsseln und überprüfen, ob der erhaltene Klartext mit dem
selbst erstellten Hash übereinstimmt.
Etwas detaillierter passiert Folgendes: Beim Versand einer Nachricht führt
der versendende SMTP-Server ein weiteres Header Feld mit der Bezeichnung
DKIM-Signature in die E-Mail ein (vgl. Beispiel 3.2). Dieses Header-Feld erhält
dann Tupel aus Bezeichnern und Werten, die zur Verifikation verwendet werden
und ausschließlich aus US-ASCII-Zeichen (vgl. Exkurs 1.9 auf Seite 19) bestehen
Seite 83
dürfen. Der generelle Aufbau der DKIM-Signature wird in Exkurs 3.1 beschrieben,
eine konkrete DKIM-Signature liefert Beispiel 3.2.
Exkurs 3.1: DKIM-Signature
E
y
DKIM-Signature: v=1; a={Signaturalgorithmus/Hashalgorithmus};
c={Kanonisierungsmethode};
d={Domain}; s={Selektor};
h={Liste der verwendeten Header-Felder};
bh={Hashwert des Nachrichten-Bodys};
b={Signatur};
Die wichtigsten Tupel innerhalb der DKIM-Signature sind:
b= Digitale Signatur des Inhalts von Header und Body der E-Mail.
bh= Hash des Bodys.
d= Signierende Domain.
s= Selektor, der den passenden Schlüssel auswählt. Für eine Domain können
verschiedene Schlüssel erstellt werden. Die Einteilung kann nach dem Ort
passieren, von dem die E-Mail aus verschickt wurde. Es ist weiterhin eine
Einteilung nach Datum denkbar, damit der öffentliche Schlüssel regelmäßig
problemlos ausgetauscht werden kann. Dazu ist auch denkbar, dass für
einzelne Benutzer individuelle Schlüssel verwendet werden.
Beispiel 3.2: DKIM-Signature
Folgende Zeilen entstammen einer E-Mail, die durch einen SMTP-Server
von Google verschickt wurde und eine gültige DKIM-Signature enthält.
y
Return-Path: <bouncemail+sebastian.uellenbeck=googlemail.com==
sebastian.uellenbeck=rub.de@rub.de>
[..]
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=x-received:message-id:date:from:user-agent:mime-version:to:subject
:content-type:content-transfer-encoding;
bh=z/994Tdmf5f0KwPWF8mUfo3MOE5jKhmHSlp7TcM0SKU=;
b=z2FOrPwVeYLFRd8LIJKnO7+tPkO+X7T7tMDyGjF3w7myjoaQeZijuEH+gre9yQLBDv
TCaHhUBDZw4MHqspVi40crBDRd8tgyV9627BOkFR4B00mm/lgjJfrj8FIh1sEZ7r5Zw8
PrKEOIYGhTormy38DkTvnCBAeEU1Z3NU3oIM4908EjiMKS32JXDpiTrmnL8k8p7Rx+8l
8m04PJcl7ZLiSsx979Q8c81xW0XDxDMUiNwUDW1BmqTAqPc0K/jMxtjtAiFLuE0437JT
VnX0B/0kLFvB7EWxwk8rL6d7Y6ZmWZyvKe0bOm3Y4OgUG6kPWEQcfQYue9oFfWQ5BElo
OdcA==
[..]
Es werden also Hashes von bestimmen Teilen der E-Mail erstellt und diese mithilfe
eines privaten Schlüssels einer Domain verschlüsselt. Dabei kann ein privater
Schlüssel für eine ganze Domain gelten, ebenso können aber für eine Domain
auch unterschiedliche Schlüssel verwendet werden, die über den Bezeichner s=
ausgewählt werden. Nachdem der SMTP-Server die DKIM-Signature zum Header
der E-Mail hinzugefügt hat, wird die E-Mail an den Empfänger verschickt. Der
empfangende SMTP-Server kann nun die E-Mail verifizieren. Dazu wird die DKIM-
B
Seite 84
Signature untersucht, wobei eine DNS-Anfrage (vgl. Abschnitt 1.5.6 ab Seite 30)
verschickt wird, die nach dem TXT-Eintrag, der im Header als Absender aufgeführten Domain fragt. Als Antwort erhält der SMTP-Server dann den öffentlichen
Schlüssel zur angefragten Domain und dem entsprechenden Selektor (vgl. Beispiel 3.3). Mithilfe des Schlüssel kann dann der Hash der E-Mail berechnet werden
und das Resultat mit der entschlüsselten Zeichenkette verglichen werden. Sind
die beiden Zeichenketten gleich, so beweist die Gleichheit, dass die E-Mail von
der entsprechenden Domain signiert wurde und auf dem Weg vom Sender zum
Empfänger nicht verändert wurde. Dies natürlich nur unter der Voraussetzung,
dass der private Schlüssel des Senders nicht öffentlich bekannt ist. Somit kann
unter Zuhilfenahme von DKIM verifiziert werden, ob eine E-Mail wirklich von
dem Absender stammt, der im Header der E-Mail angegeben ist.
Einen Überblick zu den zu DKIM existierenden Diensten wird in RFC 5585
(vgl. Hansen et al. [2009]) gegeben. Eine mögliche Erweiterung, die Author Domain
Signing Practices (ADSP), beschreibt RFC 5617 (vgl. Allman et al. [2009]).
B
Beispiel 3.3: DKIM-Verifikation
Für die aus Beispiel 3.2 erhaltene DKIM-Signature wird nun der öffentliche
Schlüssel angefordert:
$ nslookup -query=txt 20120113._domainkey.googlemail.com
[..]
Non-authoritative answer:
20120113.\_domainkey.googlemail.com
text = "k=rsa\;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1Kd87/U
eJjenpabgbFwh+eBCsSTrqmwIYYvywlbhbqoo2DymndFkbjOVIPIl
dNs/m40KF+yzMn1skyoxcTUGCQs8g3FgD2Ap3ZB5DekAo5wMmk4wi
mDO+U8QzI3SD0" "7y2+07wlNWwIt8svnxgdxGkVbbhzY8i+RQ9Dp
SVpPbF7ykQxtKXkv/ahW3KjViiAH+ghvvIhkx4xYSIc9oSwVmAl5O
ctMEeWUwg8Istjqz8BZeTWbf41fbNhte7Y+YqZOwq1Sd0DbvYAD9N
OZK9vlfuac0598HY+vtSBczUiKERHv1yRbcaQtZFh5wtiRrN04BLU
TD21MycBX5jYchHjPY/wIDAQAB"
DKIM bietet zusammenfassend die Vorteile, dass es als Hilfsmittel gegen Phishing
verwendet werden kann. Signieren Banken ihre E-Mails per DKIM, so können nicht
oder fehlerhaft signierte E-Mails problemlos auch automatisch durch den E-MailClient des Nutzers angezeigt werden. Prinzipiell müssen keine Erweiterungen
den Client betreffend implementiert werden. Das System muss nur innerhalb
der versendenden und empfangenden SMTP-Server implementiert sein. Da es
auf DNS aufsetzt, sind auch zusätzliche Server oder Protokolle nicht notwendig.
Außerdem entsteht aufgrund des Hashings zwar ein Anstieg der für den Versand
einer E-Mail benötigen Prozessorleistung, dieser ist aber im Vergleich zu anderen
Verfahren (vgl. Hashcash in Abschnitt 3.8.4 ab Seite 89) sehr gering. DKIM bietet
zwar keinen direkt Schutz vor Spam (vgl. Levine [2009]), es kann jedoch als Einfluss
für Reputationssysteme (vgl. Abschnitt 3.6 ab Seite 78) verwendet werden.
Gleichzeitig gibt es bei dem Verfahren jedoch einige bisher ungelöste Probleme.
Dazu zählt die Veränderung des E-Mail-Inhalts auf dem Web von Sender zum
Empfänger. SMTP-Server dürfen Nachrichten zwischen verschiedenen Character
Sets konvertieren. Durch diese Veränderung passt die DKIM-Signature nicht mehr
zum E-Mail-Inhalt. Da Botnetze auch Webmail als Quelle für Spam verwenden,
kann nicht ausgeschlossen werden, dass trotz gültiger DKIM-Signature eine EMail doch Spam ist. Besonders E-Mails, die HTML-Quelltext enthalten und darin
Bilder einbinden, können einfach zum Versand von Spam verwendet werden. Ein
Seite 85
weiteres Problem besteht darin, dass DKIM oftmals mit sehr kurzen Schlüsseln
eingesetzt wird. So konnte Zachary Harris die Machbarkeit von E-Mail Spoofing
für Domains von Google, Amazon oder auch Yahoo mit verifizierbaren DKIMSignaturen zeigen (vgl. Zetter [2012]). Aus diesem Grund wird vorgeschlagen,
mindestens 1024-bit Schlüssel zu verwenden. Aufgrund der Tatsache, dass DKIM
für die Verifikation der E-Mails den öffentlichen Schlüssel per DNS anfordert, sind
sämtliche Schwächen von DNS auch gleichzeitig Schwächen von DKIM. Zusätzlich
wird das DNS wird entsprechend stärker belastet.
Exkurs 3.2: Asymmetrische Kryptographie
E
Kryptographische Methoden unterteilen sich in symmetrische und asymmetrische Verfahren. Die symmetrischen Verfahren verwendeten sowohl zur
Ver- als auch zur Entschlüsselung denselben Schlüssel. Im Gegensatz dazu
verwenden asymmetrische Verfahren einen Schlüssel zum Verschlüsseln
und einen anderen Schlüssel zum Entschlüsseln. Asymmetrische Verfahren
werden auch Public-Key-Verfahren genannt, da ein Anwendungsfall darin besteht, dass einer der beiden Schlüssel öffentlich (public) zugänglich
gemacht werden kann, mit dem eine Nachricht verschlüsselt werden und
ausschließlich der Besitzer des anderen (privaten) Schlüssels die Nachricht
entschlüsseln kann.
Nach Paar and Pelzl [2010] existieren vier Hauptfunktionen für asymmetrische Verschlüsselungsverfahren:
Schlüsselaustausch Es existieren Protokolle, mit denen ein geheimer
Schlüssel über einen unsicheren Kanal verschickt werden kann.
Nichtabstreitbarkeit Hiermit kann sichergestellt werden, dass eine Nach-
richt von einer Person stammt, die über einen geheimen Schlüssel
verfügt.
Identifikation Verfahren können die Identifikation von Personen oder
Computern sicherstellen.
Verschlüsselung Nachrichten können entsprechend verschlüsselt werden.
3.8.2 SPF (Sender Policy Framework)
SPF wurde in RFC 4408 (vgl. Wong and Schlitt [2006]) spezifiziert und durch
RFC 6652 (vgl. Kitterman [2012]) aktualisiert. Das System gilt als Alternative zu
DKIM (vgl. Abschnitt 3.8.1 ab Seite 82), da es ebenfalls dazu verwendet werden soll,
die Absenderadresse zu verifizieren und dafür auf DNS aufsetzt. Im Gegensatz zu
DKIM werden allerdings keine kryptographischen Methoden verwendet, um den
Inhalt einer E-Mail zu verifizieren. DKIM kann daher verifizieren, dass der Inhalt
einer E-Mail beim Versand nicht verändert worden ist. Durch SPF kann dagegen
der empfangende SMTP-Server überprüfen, ob die IP-Adresse, von der eine eintreffende E-Mail versendet wird, dazu berechtigt ist, für den spezifizierten Absender
die E-Mail zu verschicken. Um dies durchführen zu können, wird ein spezieller
DNS-Eintrag benötigt. Da SPF bereits vor der Spezifizierung durch RFC 4408 eingesetzt wurde und erst mit RFC 4408 der neue DNS-Eintragstyp SPF eingeführt
wurde, wird empfohlen, sowohl den TXT- als auch den SPF-Eintrag mit Daten
RFC 6652
Seite 86
zu versorgen. Der Aufbau des TXT- bzw. SPF-Eintrags wird dabei im folgenden
Exkurs 3.3 beschrieben. Beispiel 3.4 zeigt einen konkreten DNS-Eintrag.
E
Exkurs 3.3: SPF-DNS-Einträge
Der DNS-Eintrag, der zur Funktionsfähigkeit von SPF benötigt wird, ist eine
Zeichenkette, die aus vielen Teilen bestehen kann, die jeweils durch Leerzeichen getrennt sind. Der Eintrag selber beginnt mit einer Versionsnummer
v=, die aktuell bei 1 liegt (vgl. Beispiel 3.4). Die meisten der einzelnen Teile
werden als Direktiven bezeichnet und können vom SMTP-Server ausgewertet werden. Die Auswertung aller Direktiven wird von links nach rechts für
jede Direktive einzeln abgearbeitet. Dabei können drei Fälle eintreten:
1. Die Direktive passt zur Anfrage, dann wird die Auswertung beendet
und der Wert der Bedingung wird zurückgegeben.
2. Die Direktive passt nicht zur Anfrage, dann wird die nächste Direktive
abgearbeitet.
3. Die Auswertung wirft eine Ausnahme (engl. Exception), dann wird
die Ausarbeitung beendet und der Wert der Ausnahme zurückgegeben.
RFC 4408 definiert vier Bedingungen (engl. qualifier), die zu einer Direktive
das erwünschte Verhalten beim Eintreffen spezifizieren:
Bedingung
Name
Beschreibung
+
Pass
-
Fail
~
SoftFail
?
Neutral
Der Sender ist autorisiert zum Versand einer
Nachricht.
Der Sender ist nicht zum Nachrichtenversand autorisiert.
Die Nachricht sollte irgendwo zwischen und ? behandelt werden.
Der Besitzer der Domain kann oder will
über solche IP-Adressen keine Aussage
treffen.
Ist keine Bedingung angegeben, so wird der Standard-Fall Pass verwendet.
Dazu besteht eine Direktive weiterhin aus einem Mechanismus:
Mechanismus
all
a
mx
ip4
ip6
include
Bedingung für das Eintreffen der Direktive
Trifft immer zu und sollte als letzte Direktive den
Standardfall beschreiben.
Ein A oder AAAA-Record der befragten Domain
enthält die IP-Adresse des Senders.
Ein MX-Record der befragten Domain enthält die
IP-Adresse des Senders.
Die angegebene IPv4-Adresse ist oder enthält die
Die angegebene IPv6-Adresse ist oder enthält die
Verweist auf eine andere Liste.
Seite 87
Beispiel 3.4: SPF-Eintrag für den Google Mail-Dienst
Der SPF-Eintrag für den Google Mail-Dienst kann über den Befehl
B
$ host -t TXT _spf.google.com
erfragt werden. Aktuell wird als Antwort die folgende Zeichenkette zurück
gegeben:
y
y
_spf.google.com descriptive text "v=spf1
include:_netblocks.google.com
include:_netblocks6.google.com ?all"
Durch den Exkurs 3.3 wird deutlich, dass die Informationen aus Beispiel 3.4 noch
weiter aufgelöst werden müssen, damit sie verwendbar sind. Dies wird in Beispiel 3.5 gezeigt.
Beispiel 3.5: SPF-DNS-Einträge: Auflösung einer include Direktive
Da der SPF-DNS-Eintrag aus Beispiel 3.4 zwei include Direktiven enthält,
müssen diese wie folgt weiter aufgelöst werden:
y
$ host -t TXT _netblocks.google.com
_netblocks.google.com descriptive text "v=spf1
ip4:216.239.32.0/19 ip4:64.233.160.0/19
ip4:66.249.80.0/20 ip4:72.14.192.0/18
ip4:209.85.128.0/17 ip4:66.102.0.0/20
ip4:74.125.0.0/16 ip4:64.18.0.0/20
ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all"
y
yy
y
y
$ host -t TXT _netblocks6.google.com
_netblocks6.google.com descriptive text "v=spf1
ip6:2607:f8b0:4000::/36 ip6:2a00:1450:4000::/36 ?all"
Der empfangende SMTP-Server kann nun die Direktiven aus der Antwort der DNSAnfrage auswerten und erhält daraus die Antwort, ob die IP-Adresse des Senders
autorisiert ist, von der angegebenen IP-Adresse E-Mails zu verschicken. E-Mails
sollten durch den SMTP-Server jedoch nicht direkt geblockt werden. Vielmehr
sollte das Ergebnis der Überprüfung mit in den Header der E-Mail aufgenommen
werden, damit es ggf. vom Client des Nutzers angezeigt wird.
Insgesamt besitzt SPF den Vorteil, dass der Client nicht notwendigerweise angepasst werden muss. Auch der SMTP-Server zum Versand von E-Mails bedarf
keinen Erweiterungen. Dagegen muss allerdings eine entsprechende Funktionalität
im empfangenden SMTP-Server vorhanden sein. Weiterhin müssen die entsprechenden DNS-Einträge gepflegt werden. SPF kann daher auch nicht vor Spam
schützen, da auch Versender von Spam ihre eigenen DNS-Einträge entsprechend
pflegen können. Es kann aber vor Phishing helfen, da entschieden werden kann,
ob eine IP-Adresse die Berechtigung hatte, mit einem bestimmten Absender eine
E-Mail abzuschicken.
B
Seite 88
3.8.3 Sender ID
RFC 4406
RFC 4406 (vgl. Lyon and Wong [2006]) beschreibt das experimentelle Protokoll
Sender ID, das eine Alternative zu SPF (vgl. vorheriger Abschnitt) ist und auf der
Funktionalität von SPF aufbaut. Sender ID wurde bereits von der Spezifizierung in
RFC 4406 durch Microsoft und die MARID (MTA Authorization Records In DNS)
IETF (Internet Engineering Task Force) Gruppe entwickelt. Jedoch stellte Microsoft
eigene Patente nicht für die Verwendung unter bestimmten Open-Source-Lizenzen
bereit, weshalb sich MARID von der Entwicklung zurückzog (vgl. Ermert [2004]
und Wilkens [2006]). Sender ID wird aktuell von Microsoft unter der Bezeichnung
Sender ID Framework (SIDF) verwendet und entwickelt.
RFC 4407
Im Gegensatz zu SPF wird unter anderem die Header-Adresse einer E-Mail zur
Verifizierung des Absenders herangezogen. Die Eigenschaften, die vom SIDF
insgesamt zur Verifizierung des Absenders verwendet werden, sind in RFC 4407
als Purported Responsible Address (PRA) spezifiziert (vgl. Lyon [2006]).
Systematisch entspricht das Sender ID Framework dem Sender Policy Framework,
jedoch wird der per DNS vom Versender eingeholte Datensatz angepasst. Die in
SPF beginnende Zeichenkette v=sfp1 kann bei SIDF drei unterschiedliche Ausprägungen haben:
v=spf2.0/mfrom - Hierbei wird der Sender genauso wie bei SPF verifiziert.
v=spf2.0/mfrom,pra - Der Sender wird nach der SPF-Methode sowie anhand der
PRA verifiziert.
v=spf2.0/pra - Der Sender wird ausschließlich per PRA verifiziert.
Die Funktionsweise wird in Abbildung 3.4 gezeigt.
Abb. 3.4: Funktionsweise
von Sender ID aus Microsoft Corporation [2007].
Es werden also die folgenden fünf Schritte ausgeführt:
1. Der Sender versendet eine E-Mail aus seinem E-Mail-Client oder per Webmail. An dieser Stelle ist für SIDF noch keine Änderung notwendig.
2. Der Ziel-SMTP-Server empfängt die E-Mail und erfragt per DNS den PRA
(v=spf2.0/pra) Eintrag.
3. Der Ziel-SMTP-Server überprüft weiterhin, ob die IP-Adresse des Versenders
zum Versand von Nachrichten autorisiert ist.
4. Da für einige Domains bereits Reputationsinformationen vorliegen, werden
diese für die Klassifikation der E-Mail mit berücksichtigt.
5. Basierend auf den erhaltenen und ausgewerteten Informationen wird die
E-Mail dann klassifiziert und an den Benutzer zugestellt.
Seite 89
Für weitere Informationen fasst Microsoft Corporation [2008] die verfügbaren
Ressourcen zum Sender ID Framework zusammen.
3.8.4 Hashcash
Hashcash ist ein von Adam Back im Jahr 1997 vorgeschlagenes und 2002 in Back
[2002] spezifiziertes System, das zur Vermeidung von Spam eingesetzt werden
kann. Aktuell existiert keine RFC zu Hashcash, jedoch gibt es Implementierungen
für verschiedene Anwendungsfälle und den oben genannten technischen Report,
der die Funktionalität beschreibt. Hashcash ist ein Proof-of-Work System, bei dem
der Versender einer E-Mail nachweist, dass er eine bestimmte Arbeit geleistet
hat. Es ist so spezifiziert, dass der Empfänger mit einem sehr geringen Aufwand
nachprüfen kann, ob der Sender diese Arbeit wirklich verrichtet hat.
Proof-of-Work System
Wie bereits in Studienbrief 2 zu Spam-Techniken ab Seite 45 beschrieben, existieren
verschiedene Techniken, um Spam zu verbreiten. Alle Techniken zielen darauf
ab, möglich viele Spam-Nachrichten in die Postfächer der Nutzer zu bringen. Da
gleichzeitig viele Methoden darauf abzielen, möglichst viel Spam auszusortieren,
versuchen Spammer so viele Spam-Nachrichten wie nur möglich zu verschicken.
Der Vorteil der E-Mail liegt ganz klar darin, dass die mit dem Versand einer E-Mail
verbundenen Kosten sehr gering sind. Daher ist meist nur die Internetanbindung
der Flaschenhals, um noch mehr Nachrichten zu verschicken. Hashcash setzt genau
an dieser Problematik an und verlagert den Flaschenhals von der Bandbreite des
Internetanschlusses zum Prozessor des versendenden Computers. Der E-MailClient des Versenders führt dabei folgende Schritte durch:
1. An den Header der E-Mail wird eine Zeile angehängt. Diese Zeile beginnt
mit H-Hashcash: und enthält die E-Mail-Adresse des Empfängers, das Datum sowie eine Zufallszahl.
2. Für die so erzeugte Zeile wird der SHA-1 Hash (vgl. Eastlake and Jones
[2001], Eastlake and Hansen [2006] und Eastlake and Hansen [2011]) berechnet.
3. Falls die ersten 20 Bits des resultierenden Hashes jeweils den Wert 0 haben,
kann die E-Mail so verschickt werden. Ist dies nicht der Fall, so muss der
Wert der Zufallszahl inkrementiert werden und es wird wieder Schritt 2
durchgeführt.
Nach durchschnittlich 220 ≈ 1 Million Iterationen wurde dann eine Header-Zeile
erzeugt, die den gewünschten Kriterien entspricht.
Der Empfänger muss nun die folgende Eigenschaften überprüfen, um die Validität
der E-Mail zu verifizieren.
1. Haben die ersten 20 Stellen des SHA-1 Hashes der Headerzeile H-Hashcash:
den Wert Null?
2. Ist die Differenz aus dem in der Headerzeile angegebenen Datum und dem
Datum der Überprüfung kleiner als 2 Tage?
3. Stimmt der in der Headerzeile H-Hashcash: angegebene Empfänger mit
dem echten Empfänger überein?
Waren alle vorherigen Überprüfungen erfolgreich, so wird die Headerzeile auf
der Seite des Empfängers in eine Datenbank abgelegt. War die Headerzeile schon
vorher in der Datenbank, so kann es sich bei der E-Mail um eine Spam-Nachricht
RFC 6234
Seite 90
handeln. Andernfalls handelt es sich mit sehr großer Wahrscheinlichkeit nicht um
eine Spam-Nachricht.
Insgesamt gesehen bietet Hashcash die Vorteile, dass diese Methode nur innerhalb
der E-Mail-Clients implementiert werden muss. Für die SMTP-Server wird keine
Anpassung benötigt, obwohl eine Filterung auf dem SMTP-Server möglich wäre.
Hier könnt der Server zumindest überprüfen, ob die ersten 20 Stellen des SHA-1
Hashes jeweils den Wert 0 haben. Ist dies nicht der Fall, so könnte die E-Mail schon
vom SMTP-Server gefiltert worden sein. Ein weiterer Vorteil besteht darin, dass im
Gegensatz zu anderen Systemen kein echtes Geld verwendet wird.
Es existieren jedoch auch Nachteile bei Hashcash. Computer mit langsamen Prozessoren oder immer beliebter werdende Smartphones oder Tablett PCs, die über
langsame Hardware verfügen, benötigen zum Versand von E-Mails viel Rechenleistung. Bei mobilen Geräten kann darunter auch die Laufzeit leiden, da der Akku
in Mitleidenschaft gezogen wird. Ebenso müssen Server für Newsletter mit vielen
Empfängern deutlich mehr Leistung für den Versand eines Newsletters aufbringen als ohne Hashcash. Der wohl schwierigste Nachteil besteht darin, dass die
Hauptquelle von Spam, die Botnetze, über sehr viel Rechenleistung verfügen und
somit immer noch sehr viele Spam-Nachrichten verschicken können, auch wenn
die Menge um viele Faktoren sinkt.
3.8.5 Receiver-Driven SMTP
Receiver-Driven SMTP ist eine Erweiterung von SMTP, die zwischen 2005 und 2006
von Forschern der Florida State University und der University of Hawaii entwickelt
wurde (vgl. Duan et al. [2005a], Duan et al. [2005b], Duan et al. [2006a] und Duan
et al. [2006b]). In den Entwürfen beschreiben die Autoren das Differentiated Mail
Transfer Protocol (DMTP) als einfache Erweiterung zum SMTP, durch das der
Empfänger mehr Möglichkeiten hat, den E-Mail-Versandprozess zu beeinflussen.
Konkret soll der Empfänger den Sender in die Kategorien allowed, denied und
unclassified klassifizieren können, um den Versand jeder Kategorie einzeln bearbeiten zu können. Weiterhin sollen DMTP-Empfänger in der Lage sein, für den Fall,
dass ein Sender als unclassified gilt, Nachrichten auf dem Server des Senders
zu speichern, um diese erst bei Bedarf abzuholen. Die Klassifikation geschieht
dabei nur aufgrund der IP-Adressen. Es werden zwei Listen von IP-Adressen gepflegt, zum einen die trusted MTAs, deren E-Mails direkt akzeptiert werden. Zum
anderen die black-listed MTAs, deren E-Mails direkt blockiert und verworfen
werden können. Alle IP-Adressen, die in keiner von beiden Listen auftreten, gelten
als unklassifizierte oder untrusted MTAs. Für diese Mail Transfer Agents gilt die
im obigen Text beschriebene spezielle Nachrichtenbehandlung.
Der Ansatz hat den Status eines Entwurfs jedoch nie verlassen und wurde ab 2006
nicht weiter verfolgt.
beitragen sollen.
K
Kontrollaufgabe 3.11: DKIM I
Wozu wird DKIM verwendet und welches Problem kann das Verfahren
nicht lösen?
3.9 Echtzeit URL Filterung
Seite 91
Kontrollaufgabe 3.12: DKIM II
K
Nennen Sie jeweils zwei Vor- und zwei Nachteile von DKIM.
Kontrollaufgabe 3.13: SPF I
K
Was ist SPF und wie unterscheidet es sich gegenüber DKIM?
Kontrollaufgabe 3.14: SPF II
K
Was sind Direktiven bzw. Bedingungen und wozu werden sie genutzt?
Kontrollaufgabe 3.15: SPF III
K
Können Sie sich vorstellen, wozu es eine ?-Bedingung (Neutral) gibt?
Kontrollaufgabe 3.16: Sender ID
K
Was unterscheidet Sender ID von SPF?
Kontrollaufgabe 3.17: Hashcash I
K
Welche Eigenschaften zeichnen Hashcash aus?
Kontrollaufgabe 3.18: Hashcash II
K
Angenommen, der Empfänger erhält eine E-Mail, bei der sich die Headerzeile H-Hashcash: bereits in seiner Datenbank befindet. Welche beiden
Szenarien können hier eingetroffen sein?
Kontrollaufgabe 3.19: Hashcash III
K
Nennen Sie jeweils zwei Vor- und zwei Nachteile von Hashcash.
3.9 Echtzeit URL Filterung
Die zu Werbezwecken versendeten Spam Nachrichten enthalten oft URLs
(vgl. Berners-Lee et al. [1994]), die auf Phishing Seiten führen oder auf Malware
zielen. Genauso werden diese URLs aber auch durch Web Services in Form von
sozialen Netzwerken von Twitter1 oder Facebook2 verbreitet. Um dieses Problem
zu behandeln, haben sich Thomas et al. [2011] mit der Implementierung und Evaluierung eines Echtzeit-Spam-Filterdienstes für URLs mit dem Namen Monarch
beschäftigt. Abbildung 3.5 zeigt dazu das generelle Vorgehen des Dienstes.
1
2
https://twitter.com/, aufgerufen am 04.11.2013
https://www.facebook.com/, aufgerufen am 04.11.2013
RFC 1738
Seite 92
Abb. 3.5: Die generelle Funktionsweise
des Echtzeit-SpamFilterdienstes Monarch
aus Thomas et al. [2011].
Die von Web-Services verbreiteten URLs könnten in einem ersten Schritt an Monarch verschickt werden. Monarch kann dann jede einzelne URL untersuchen und
in einem zweiten Schritt eine Entscheidung an den Web-Service zurückschicken,
ob die verlinkten Seite bspw. für Phishing verantwortlich ist, Malware verbreitet
oder auch als gutartige Seite einstuft werden kann.
Abb. 3.6: Das Flussdiagramm von Monarch
aus Thomas et al. [2011].
Monarch arbeitet, wie Abbildung 3.6 verdeutlicht, in vier Schritten:
1. Zuerst findet eine Aggregation zwischen einem E-Mail-Strom und den
Tweets des Web-Services Twitter statt. Bei den verwendeten E-Mails handelt
es sich um Nachrichten, die durch Spam-Traps empfangen werden und
daher mit sehr großer Wahrscheinlichkeit als Spam klassifiziert werden
können.
2. Danach findet eine Sammlung der Merkmale statt. Dazu werden die Seiten,
auf welche die URLs zeigen, automatisch durch eine angepasste Version
von Firefox besucht und das Verhalten sowie der Inhalt der Seiten werden
gespeichert. Zum Verhalten zählen bspw. JavaScript-Aktivitäten. Auch die
Infrastruktur, die zum Hosting der Seite verwendet wird, wird in einer
Datenbank abgelegt.
3. Dann werden die Merkmale der einzelnen Seiten extrahiert. Dazu werden
eingebettete URLs in Binärdaten umgewandelt und HTML Inhalte als Listen
von Wörtern abgelegt. Alle genannten Daten werden in Vektoren gespeichert,
die im nächsten Schritt weiterverarbeitet werden können.
4. Der letzte Schritt ist dann die Klassifikation. Ein Offline Training stellt sicher,
dass die Reaktionszeit des Systems möglichst gering bleibt, während ein
Echtzeit-Klassifikator schnelle Ergebnisse liefert.
In einer Evaluation zeigen die Autoren, dass das System mit einer Genauigkeit von
90,78 % arbeitet und als Median 5,54 Sekunden für eine Klassifikation benötigt.
Diese Ergebnisse wurden erreicht, indem der Klassifikator mit 1,2 Millionen SpamNachrichten, 567 000 als schadhaft gekennzeichneten Twitter-URLs und 9 Millionen
regulären URLs angelernt wurde.
K
Kontrollaufgabe 3.20: Monarch
Beschreiben Sie, wie Monarch funktioniert und wie es auch zur Erkennung
von Spam genutzt werden könnte.
3.10 Netzwerk-basiertes Clustern
3.10 Netzwerk-basiertes Clustern
IP-basiertes Blacklisting (vgl. Abschnitt 3.5.1 ab Seite 72) ist eine bekannte und
bewährte Methode, um Spam zu filtern. Das Problem bei dieser Methode besteht
aber darin, dass eine starke Fluktuation innerhalb der Liste durch dynamische
IP-Adressen entsteht. Daher wurde vorgeschlagen, nicht nur IP-Adressen sondern
Adress-Blöcke bzw. Cluster zu verwenden. In Qian et al. [2010] untersuchen die
Autoren, ob dieses Vorgehen sinnvoll ist und liefern einen alternativen Ansatz zur
Listenerstellung. Dabei stoßen die Autoren auf die folgenden Erkenntnisse:
• Die meisten großen BGP-Präfixe sind zu ungenau, um daraus Clusterbasierte Blacklisten zu erstellen. Sogar die BGP-Präfixe im mittleren Bereich
sind in fast 20 % der Fälle ungeeignet für die Spam-Filterung.
• DNS Informationen können helfen, um die BGP Präfixe in kleinere Cluster
zu brechen und so die Falsch Negativ Rate zu senken.
• Ein von den Autoren erarbeitetes System, das BGP-Präfixe und DNSInformationen verbindet, kann mehr als 50 % mehr Spam erkennen als
vorherige Ansätze.
Der von den Autoren vorgeschlagene Ansatz kann dabei problemlos in ein System
wie SpamAssassin (vgl. Abschnitt 3.14 ab Seite 101) eingebaut werden und hilft
somit bei einer besseren Klassifizierung von Spam.
3.11 Erkennung von Botnetzen
Die Erkennung von Botnetzen ist ein wichtiges Mittel ist im Kampf gegen Spam,
da Botnetze als Hauptverursacher für ca. 85% der Spam-Mails verantwortlich sind
(vgl. Symantec Corporation [2012]). Daher werden in diesem Abschnitt einige
Arbeiten betrachtet, die sich mit der Erkennung von Botnetzen beschäftigen.
BotMagnifier
In Stringhini et al. [2011] entwickeln die Autoren eine neue Technik, um die Identifikation und Verfolgung von Bots aus bestimmten Botnetzen zu erleichtern. Eine
bewährte Methode, um Bots zu identifizieren, besteht darin, Spam-Traps einzusetzen und die IP-Adressen der Absender zu verwenden. Dieses Vorgehen birgt
jedoch zwei Gefahren: Zum einen gehört nur eine kleine Menge der so erkannten
IP-Adressen zu einem bestimmten Botnetz. Viel eher werden viele unterschiedliche Botnetze Spam an einzelne Spam-Traps versenden. Zum anderen verschicken
Botnetze oft nur Nachrichten an bestimmte Nutzer aus einer vorher definierten
Region, damit der Nutzer bspw. auch die Sprache, die in einer Spam-Nachricht
verwendet wird, versteht.
Beim vorgeschlagenen Ansatz gehen die Autoren davon aus, dass Bots, die zum
gleichen Botnetz gehören, auch über den selben Quellcode verfügen und die selben
Command and Control Infrastruktur verwenden. Daher haben solche Bots ein
ähnliches Verhalten und können von Bots aus anderen Botnetzen abgegrenzt
werden, die für ihren Spamversand andere Parameter verwenden. Um Bots aus
einem Botnetz zu finden, werden zwei Listen benötigt. Dies ist zum einen eine
initiale Liste von Spambots, die über die klassischen Spam-Traps kommen kann.
Zum anderen werden Protokolle von empfangenden SMTP-Servern benötigt.
• Im ersten Schritt wird dann die Liste der Spambots mit den Protokollen
verglichen. Hierbei werden Überschneidungen zwischen IP-Adressen der
Spambots und der Protokolle gesucht. Diese Überschneidungen werden
dann analysiert und daraus Profile erstellt.
Seite 93
Seite 94
• Im zweiten Schritt wird dann in den Protokollen nach Einträgen gesucht,
die zu den erstellten Profilen passen. Bei diesen Einträgen kann davon
ausgegangen werden, dass es sich auch um Spambots handelt. Daher werden
die IP-Adressen dieser Einträge als mögliche Treffer markiert.
• Im dritten und letzten Schritt werden dann Heuristiken angewendet, die
zum einen die Spam Kampagnen bestimmten Botnetzen zuordnen und zum
anderen die Anzahl der fehlerhaften Treffer (Falsch-Positive) reduzieren.
Das so implementierte Tool wird von den Autoren BotMagnifier genannt,
da es mit Hilfe von wenigen bekannten Spambots eine Liste wie mit einer
Lupe nach ähnlichen Eigenschaften durchsucht, um dort weitere Spambots
zu finden.
Die Ergebnisse, die so durch BotMagnifier gefunden werden, können daraufhin
bspw. beim Blacklisting (vgl. Abschnitt 3.5.1 ab Seite 72) verwendet werden, um
bessere Ergebnisse bei der Klassifikation vom Spam zu erzielen.
BotSniffer
Einen alternativen Ansatz zu BotMagnifier liefern Gu et al. [2008] mit BotSniffer. BotSniffer verwendet eine Netzwerk-basierte Anomalieerkennung, um die
Command and Control-Kanäle von Botnetzen in lokalen Netzwerken zu identifizieren. Dazu werden jedoch nicht, wie beim vorherigen Ansatz, Informationen
über vorhandene Bots benötigt. Der Netzwerkverkehr von Botnetzen ist schwer
zu erkennen, da oftmals gebräuchliche Protokolle wie IRC oder HTTP verwendet
werden. Der Ansatz der Autoren basiert aber auf der Annahme, dass das Verhalten
von Bots räumlichen und zeitlichen Korrelationen unterliegt und somit Ähnlichkeiten aufweist. Diese Annahme wird in Abbildung 3.7 visualisiert. Im linken Teil
der Abbildung werden Antwortnachrichten in der Zeitebene verglichen. Hier fällt
auf, dass die Antworten sich immer in einem zeitlichen Rahmen befinden, die als
mögliches Muster gewertet werden können. Der rechte Teil zeigt verschiedene
Botaktivitäten, wie das Scannen des Netzwerks, den Versand von Spam oder das
Herunterladen einer Datei. Auch hier sind Ähnlichkeiten im zeitlichen Verhalten
erkennbar.
Abb. 3.7: Raum- und
zeitliche Korrelation von
Bot-Antworten aus Gu
et al. [2008]. Links:
einzelne Antwortnachrichten, rechts: verschiedene Aktivitäten.
BotSniffer erkennt dieses Verhalten, indem statistische Algorithmen zur Gruppierung der Muster verwendet werden. Abbildung 3.8 visualisiert dazu eine Übersicht
über die Architektur des Systems. Hierbei erhält BotSniffer als Eingabe den lokalen
Netzwerkverkehr und führt zuerst ein Vorverarbeitung der Daten durch. Dabei
werden nicht relevante Informationen wie ICMP- und UDP-Pakete entfernt. Die
Autoren gehen davon aus, dass innerhalb dieser Pakete bisher keine Command and
Controll-Daten ausgetauscht werden, weshalb sie für die Erkennung von Botnetzen
zum Stand der Veröffentlichung nicht zur Verbesserung der Ergebnisse beitrugen.
Weiterhin werden Verbindungen zur normalen Servern wie Google oder Yahoo
durch ein statisches Whitelisting entfernt. Daraufhin werden zwei Module auf
3.12 Botnetz-Übernahme
Seite 95
die Daten angewendet. Zum einen findet eine Erkennung von Aktivitäten und
Antworten statt. Diese sucht das Modul nach IRC-PRIVMSG-Nachrichten, die für die
Kommunikation verantwortlich gemacht werden, sowie nach DNS-MX-Anfragen
und SMTP-Verbindungen, die zum Versand von Spam benötigt werden. Zum
anderen wird ein Modul zur Protokollzuordnung ausgeführt.
Abb. 3.8: Architekturübersicht von BotSniffer
aus Gu et al. [2008].
Die Autoren versuchen IRC- und HTTP-Verbindungen in den Daten zu finden,
gehen aber davon aus, dass Bots nicht unbedingt die Standardports der Protokolle verwenden. Daher müssen die Datenströme auf allen Ports untersucht werden. IRC-Verbindungen können einfach erkannt werden, da der Start von IRCSitzungen durch drei Nachrichten (PASS, NICK und USER) bestimmt ist, die in RFC
1459 (vgl. Reed [1993]) definiert sind. HTTP-Datenströme können ähnlich leicht
erkannt werden. Hier müssen Anfragen immer mit einem der drei Schlüsselwörter
GET, POST oder HEAD beginnen, wie RFC 1945 beschreibt (vgl. Berners-Lee et al.
[1996]). Beide Module liefern Daten an eine Datenbank, die ein Aktivitätsprotokoll
beinhaltet. Das sind auf der einen Seite Ergebnisse zu schadhaften Aktivitäten aus
der Erkennung von Aktivitäten und Antworten. Auf der anderen Seite werden
erkannte HTTP- und IRC-Verbindungen aus dem Modul zur Protokollzuordnung
eingefügt. Dasselbe Modul stellt auch eine Eingabe für das Modul zur Erkennung
von IRC-Nachrichten und Antworten dar. Dazu werden die IRC Datenströme weitergeleitet und auf ein- und ausgehenden IRC PRIVMSG Nachrichten hin analysiert.
Diese Modul speichert ebenfalls Informationen in der Datenbank zum Aktivitäten
protokollieren ab, generiert aber auch direkt Berichte. Berichte werden auch durch
ein Korrelationsmodul erstellt, das auf die Einträge aus der Datenbank zugreift.
Mithilfe dieser Mechanismen können im Datenverkehr die Command and ControllNachrichten von Botsnetzen gefunden und die Botnetze somit ausfindig gemacht
werden.
Botnetze sind aktuell für den Großteil alle versendeten Spam-Nachrichten verantwortlich. Aus diesem Grund sind Analysen von Botnetzen hilfreich, um deren
Vorgehensweisen zu verstehen und um daraus folgend den Versand von Spam
einzudämmen. In Stone-Gross et al. [2009] haben die Autoren das Botnetz Torpig (auch unter den Namen Sinowal und Anserin bekannt) untersucht. Torpig
RFC 1459, RFC 1945
Seite 96
sammelt sensible Informationen der befallenen Computer wie Konto- und Kreditkarteninformationen. Es basiert auf dem Rootkit Mebroot3 , der den Master Boot
Record erweitert und somit bei jedem Systemstart noch vor dem Betriebssystem
ausgeführt wird.
Generell existieren zwei Möglichkeiten, um ein Botnetz zu analysieren. Zum einen
kann eine passive Analyse stattfinden, bei der der Datenverkehr beobachtet wird.
Zum anderen kann eine Infiltration des Botnetzes durchgeführt werden, indem ein
Bot in einer kontrollierten Umgebung ausgeführt wird und dabei der Netzwerkverkehr beobachtet wird. Dieses Vorgehen ist dann möglich, wenn die Command and
Control-Struktur des Botnetzes per IRC oder HTTP erfolgt. Im besten Fall können
so die internen Abläufe beobachtet werden, um Schwachstellen des Botnetzes
zu finden. Beide Möglichkeiten sind jedoch bei aktuellen Botnetzen schwierig zu
realisieren wenn nicht per IRC oder HTTP kommuniziert wird oder eine dezentrale
Struktur (Peer-To-Peer) verwendet wird. Eine durchaus bessere Alternative bietet
die von den Autoren durchgeführte Entführung des kompletten Botnetzes durch
die Übernahme eines Command and Control Servers. Dies ist zum einen durch die
physikalische Übername des Command and Control Servers möglich, wozu aber
bekannt sein muss, wo der Server gehostet wird, was bei dezentralen Lösungen
sehr schwierig ist, oder die Ausnutzung der Domain-Flux-Technik, die von Torpig
eingesetzt wird.
Domain Flux
Domain Flux ist eine Technik, bei der jeder einzelne Bot unabhängig von den
anderen Bots periodisch eine Liste von Domains erstellt, zu denen er einen Verbindungsaufbau versucht. Der erste Server, der bei einem Verbindungsaufbauversuch
eine valide Antwort zurückmeldet, wird als echter Command and Control Server
betrachtet. Der Bot verbindet sich daraufhin mit dem Server und wartet auf Befehle.
Durch Reverse Engineering (vgl. Exkurs 3.4 auf Seite 97) des Domain Erstellungs
Algorithmus konnten im Vorhinein bereits die entsprechenden Domains registriert
werden, wodurch der Botmaster dazu keine Möglichkeit mehr hat. Die Bots verbindeten sich dann mit einem Server, der unter der Kontrolle der Autoren stand. Die
Autoren erhielten somit Daten von mehr als 180.000 infizierten Computern, die
sie daraufhin analysieren könnten. Unter anderem fanden sie bei ihren Analysen
heraus, wie Torpig genau funktioniert. Dies ist in Abbildung 3.9 dargestellt.
Abb. 3.9: Die TorpigNetzwerk-Infrastruktur
aus Stone-Gross
et al. [2009].
Dabei werden die Computer der Opfer durch Drive-By-Downloads (vgl. Provos
et al. [2008]) infiziert. Hierzu wird der HTML-Quellcode von verwundbaren aber
legitimen Webseiten (1) modifiziert, damit das Opfer speziellen JavaScript Code (2) aufruft. Der JavaScript Code wiederum ruft dann Code von einem Drive-ByDownload Server ab (3), der unter der Kontrolle des Angreifers steht und Schwachstellen im Browser ausnutzt, um eine ausführbare Datei herunterzuladen (4). Nachdem die Schadsoftware heruntergeladen und installiert wurde, nimmt der somit
entstandene Bot Kontakt zum Command and Control Server auf (5) und erhält
Aufgaben in Form von Modulen, die auf dem Host-Computer ausgeführt werden
sollen. Periodisch werden dann die erhaltenen Daten des Host-Computers an einen
3
Eine genaue Analyse von Mebroot kann in Kleissner [2009] (abgerufen am 18.11.2013) gefunden
werden.
Seite 97
weiteren Command and Control Server versendet (6). Um die Adresse des neuen
Servers zu erhalten, wird der oben genannte Algorithmus verwendet. Als weitere
Schadfunktion führt der Bot einen Phishing-Angriff auf dem Host-Computer aus,
sofern diese bspw. entsprechende Onlinebanking-Seiten besucht (7).
Die Autoren fanden heraus, dass bei Torpig jeder Bot eine einzigartige ID erzeugt,
die bei jeder Kommunikation mit übertragen wird. Anhand der Zählung der IDs
konnte herausgefunden werden, dass das Botnetz ca. 182 800 Computer zu diesem
Zeitpunkt enthielt.
Die Autoren lernten bei ihrer Analyse drei wesentliche Dinge:
1. Die Größe eines Botnetzes durch Zählen der einzigartigen IP-Adressen führt
zu falschen Zahlen. Durch Zwangstrennungen erhalten viele Bots oft eine
neue IP-Adresse und werden somit mehrfach gezählt.
2. Die Opfer von Botnetzen sind oft schlecht gewartete Computer, auf denen
leicht zu erratende Passwörter zum Zugriffsschutz für sensible Webseiten
verwendet werden.
3. Die Kommunikation mit Registraren, Webhostern und Anlaufstellen von
Opfern ist ein sehr aufwendiger Prozess.
Durch die Analyse des Botnetzes können so Strategien entwickelt werden, die
zum Abschalten des Botnetzes führen und somit auch den Versand von Spam
beeinflussen.
Exkurs 3.4: Reverse Engineering
Der Prozess der Entdeckung der internen Funktionalität einer Software wird
als Reverse Engineering bezeichnet. Dabei kann zum einen der Quellcode
einer Software untersucht werden. Dies kann sich als aufwendig erweisen,
wenn allgemeine Richtlinien, wie die Verwendung von aussagekräftigen
Namen für Variablen oder Funktionen bei der Erstellung der Software nicht
befolgt werden. Generell ist eine Quellcode-Analyse jedoch durchführbar,
auch wenn je nach Umfang des Quellcodes viel Arbeitszeit investiert werden
muss. Steht ein Softwareprodukt nicht im Quellcode vor, was der Normalfall
ist, so muss das vorhandene Programm im binären Format untersucht werden. Hierbei handelt es sich um Maschinenbefehle, die nicht dazu gedacht
sind, von Menschen interpretiert zu werden. Zur Analyse von Binärcode
existieren drei unterschiedliche Techniken:
1. Analyse durch die Beobachtung des Austausches von Informationen.
Diese Technik wird häufig bei der Analyse von Protokollen eingesetzt.
2. Mithilfe eines Disassembler wird versucht, aus dem Maschinencode
ein Programmcode in Assemblersprache zu erzeugen. Assemblersprache ist zwar immer noch eine Sprache, die sehr nah zur Maschinensprache ist, jedoch handelt es sich um Konstrukte, die für Menschen
einfacher verständlich sind als die ursprüngliche Maschinensprache.
3. Durch Dekompilierung wird versucht, aus dem Maschinencode wieder ein Programmcode einer Hochsprache zu generieren, der von
Menschen einfacherer verstanden werden kann.
E
Seite 98
K
Kontrollaufgabe 3.21: Domain Flux
Wofür wird bei Torpig die Domain-Flux-Technik verwendet?
3.13 Botnet Judo: Automatische Generierung von Spam
Signaturen
Einen weiteren Ansatz zur Bekämpfung vom Spam zeigen Pitsillidis et al. [2010].
Auch in dieser Arbeit werden Botnetze als Hauptquelle von Spam ausgemacht.
Grundsätzlich besteht das Ziel des Systems darin, aus einer Eingabe von E-Mails
eine Signatur zu erstellen, mithilfe derer alle E-Mails gefiltert werden können, die
durch dasselbe Template erzeugt wurden. Die Grundvoraussetzungen bestehen
dabei allerdings darin, dass die E-Mails zum einen durch ein Template generiert
wurden und auch darin, dass nicht zu viele unterschiedliche Templates zur Generierung verwendet wurden. Das Spam-Nachrichten, die aus Botnetzen stammen,
durch Templates erzeugt werden, wurde bereits in Kreibich et al. [2008] und Stern
[2008] gezeigt. Grund für die Verwendung von Templates liegt in der erschwerten
Filterung der Nachrichten. Ist bekannt, dass eine bestimmte E-Mail-Spam darstellt,
so kann bei Spam, der aus Templates erstellt wurde, die Gleichheit nicht direkt
nachgewiesen werden, da jede Spam-Nachricht aus dem Template einen leicht
abgewandelten Inhalt hat. Weiterhin wird in diesem Ansatz der Spamversand als
Blackbox betrachtet. Es ist nicht wichtig, wie die Nachricht vom Sender zum Empfänger gelangt, sondern es kommt ausschließlich auf den Inhalt der Nachricht an,
dabei basieren die erzeugten Signaturen jedoch nicht nur auf dem Betreff oder den
enthaltenen URLs, wie es bei anderen Ansätzen der Fall ist, sondern verwenden
die gesamte E-Mail.
Der grundsätzliche Ablauf, den die Autoren verwenden, wird in Abbildung 3.10
gezeigt.
Abb. 3.10: Der Systemüberblick aus Pitsillidis et al. [2010].
Dabei ist zu erkennen, dass in einem ersten Schritt Spam gesammelt wird. Dies
kann theoretisch durch Spam-Traps erfolgen. Innerhalb dieser Arbeit wurden
allerdings Bots in einer kontrollierten Umgebung ausgeführt und die versendeten
E-Mails aus dem Netzwerkverkehr verwendet. Der zweite Schritt ist die Erzeugung
von Signaturen durch den Signatur-Generator, der als wichtigster Bestandteil der
Arbeit angesehen werden kann. Darauf folgend wird im dritten Schritt eine Menge
von bereist existierenden Signaturen aktualisiert und erweitert und anschließend
im vierten Schritt an einen Spam-Filter verteilt. Die Signaturen bestehen dabei aus
regulären Ausdrücken, die fast in Echtzeit erzeugt werden können und sich somit
auch praktisch in realen Systemen einsetzen lassen.
Da der Algorithmus zur Erstellung der Signatur als wichtiger Bestandteil der
3.13 Botnet Judo: Automatische Generierung von Spam Signaturen
Seite 99
Arbeit angesehen werden kann, wird diese im Folgenden anhand des Beispiels in
Abbildung 3.11 beschrieben.
Abb. 3.11: Eine Beispielinstanz des Algorithmus zum Erstellen einer aus Pitsillidis et al.
[2010].
Der Algorithmus besteht aus zwei Schritten. Im ersten Schritt wird versucht, alle
Zeichenketten zu erkennen, die in jeder E-Mail vorhanden sind. Diese invarianten
Zeichenketten werden als Anker bezeichnet. Im vorliegenden Beispiel werden
Best prices!, http:// und \.com 60% off als Anker identifiziert. Dafür werden
die längsten geordneten Mengen von Zeichenketten gesucht, die in allen E-Mails
vorkommen und mindestens die Länge q haben. Wobei q ein zu konfigurierender
Parameter ist und einen wichtigen Einfluss auf die Qualität der resultierenden
Signatur hat. Die Autoren haben in verschiedenen Versuchen herausgefunden, dass
sich q = 6 eignet, um guter Ergebnisse zu erreichen. Der zweite Schritt versucht die
variable Zeichenfolge zwischen zwei Ankern durch ein Makro zu definieren. Dabei
kann es sich um ein Wörterbuch-Makro, ein Zufalls-Makro oder eine Kombination
mehrerer Makros handeln. Wörterbuch-Makros haben die Eigenschaft, dass sie
aus einer festgelegten Menge von Wörtern, also einem Wörterbuch, stammen
und eines der Elemente zufällig ausgewählt wird. In dem vorliegenden Beispiel
beschreiben chanel, gucci und prada ein Wörterbuch und fenallies und nuserro
ein zweites Wörterbuch. Theoretisch kann jedes Makro durch ein WörterbuchMakro beschrieben werden, jedoch muss der Algorithmus dazu erst alle möglichen
Einträge des Wörterbuchs gesehen haben. Kann eine Zeichenkette zwischen zwei
Ankern nicht durch ein Wörterbuch darstellt werden, weil immer wieder neue
mögliche Einträge auftauchen, so wird davon ausgegangen, dass es sich um ein
Zufalls-Makro handelt.
Anker, Makro
Die so erzeugten Signaturen müssen dann den Datenbestand aller Signaturen
aktualisieren. Um dies zu tun, gibt es in den vorgestellten Ansatz eine spezieller
Funktionalität, den Training Puffer. Für jede neu eintreffende Spam-Nachricht wird
zuerst überprüft, ob es bereits eine Signatur gibt, die dieser Nachricht erkennt.
Trifft dies zu, so kann die Nachricht verworfen werden, da sie keinen Mehrwert
hat. Wird die Nachricht nicht erkannt, so wird sie dem Training-Puffer hinzugefügt und es wird so lange gewartet, bis der Puffer voll ist. Die Größe des Puffers
wird durch den Parameter k bestimmt. Die richtige Wahl von k ist von essentieller
Bedeutung: ist k zu klein, so können Wörterbücher entweder gar nicht oder nur
unvollständig erkannt werden und der Algorithmus würde dementsprechend
Zufalls-Makros anstelle von Wörterbuch-Makros wählen. Wird ein großes k gewählt, so ist die Zeitspanne zwischen dem Eintreffen der ersten Spam-Nachricht
und der Erzeugung einer Signatur gegen diese Nachricht sehr groß. Außerdem
kann es so auch passieren, dass Spam-Nachrichten von unterschiedlichen Templates eintreffen und daraus eine sehr ungenaue und schlechte Signatur erzeugt
wird. Aufgrund der Tatsache, dass in den Tests für k kein Wert gefunden werden
Trainings-Puffer
Seite 100
konnte, der für alle Botnetze gute Ergebnisse liefert, wurden zwei zusätzliche
Mechanismen implementiert, die zur Lösung dieses Problems beitragen sollen.
Second-ChanceAlgorithmus,
Pre-Clustering,
Skelett-Signatur
Der erste Mechanismus ist Second Chance. In vielen Fällen kann eine gute Signatur bereits unter Beachtung nur weniger E-Mails erzeugt werden, auch wenn
mehr Nachrichten benötigt werden würden, um ein vollständiges Wörterbuch zu
erhalten. Daher können bereits erzeugte Signaturen nachträglich erweitert werden, sofern eine neue Nachricht zwar nicht zu den erzeugten Signaturen passt,
jedoch unter Vernachlässigung der Makros von einer Signatur erkannt wird. Als
zweiter Mechanismus wird ein Pre-Clustering verwendet. Im Gegensatz zum
Second Chance Mechanismus soll das Pre-Clustering gegen einen zu großen
Trainings-Puffer helfen, da gerade bei einem großen Trainings-Puffer die Gefahr besteht, dass Nachrichten aus unterschiedlichen Templates vermischt werden. Beim
Pre-Clustering werden unklassifizierte Nachrichten mit sogenannten SkelettSignaturen gruppiert. Dabei ist eine Skelett-Signatur ähnlich zu einer reinen AnkerSignatur, die auch bei Second Chance verwendet wird, jedoch über eine größere
minimale Anker Länge verfügt. Mit q = 14 für Skelett-Signaturen wurde während der Auswertung ein gut funktionierender Wert gefunden. Dabei funktioniert
das Pre-Clustering, indem jeder Skelett-Signatur ein Trainings-Puffer zugewiesen wird und jede Nachricht, die zu keiner normalen Signatur oder einer AnkerSignatur passt, in den Trainings-Puffer einer passenden Skelett-Signatur eingefügt
wird. Funktioniert dies auch nicht, so wird die Nachricht in einen Trainings-Puffer
für unklassifizierte Nachrichten eingefügt. Sobald dieser Trainings-Puffer eine
bestimmte Größe erreicht, wird aus den enthaltenen Nachrichten eine SkelettSignatur erzeugt. Sobald der Trainings-Puffer einer Skelett-Signatur 10 E-Mails
enthält, wird daraus eine normale Signatur erzeugt. So muss nur klargestellt werden, dass mindestens die ersten 10 E-Mails von einem neuen Template unvermischt
mit anderen Templates eintreffen.
Insgesamt bietet der vorgestellte Ansatz also eine gute Möglichkeit, um Spam zu
filtern, benötigt dafür jedoch einige Voraussetzungen, die nicht immer einfach zu
erfüllen sind.
K
K
K
Kontrollaufgabe 3.22: BotMagnifier und BotSniffer
Welche Annahme über Botnetze wird sowohl bei BotMagnifier als auch bei
BotSniffer verwendet?
Kontrollaufgabe 3.23: Botnet Judo I
Warum ist eine automatische Generierung von Signaturen schwierig, wenn
die Anzahl der zur Verfügung stehenden Spam Nachrichten sehr klein ist
und viele unterschiedliche Templates zur Erzeugung verwendet wurden?
Kontrollaufgabe 3.24: Botnet Judo II
Wie funktioniert der Update-Mechanismus und warum ist eine Aktualisierung der Signaturen wichtig in diesem Zusammenhang?
3.14 SpamAssassin
Seite 101
Kontrollaufgabe 3.25: Botnet Judo III
Wozu werden die Parameter q und k benötigt?
3.14 SpamAssassin
SpamAssassin ist ein Software-Produkt, das zur Erkennung von Spam eingesetzt
wird. Es handelt sich dabei um ein Open Source Projekt, das unter der Apache
License 2.04 steht und von der Apache Software Foundation5 entwickelt wird. Der
Quellcode von SpamAssassin basiert auf der Programmiersprache Perl6 und kann
von jedem Nutzer unter Beachtung der Lizenzbedingungen verändert und weiterentwickelt werden. SpamAssassin vereint viele einzelne Module, die teilweise
sequentiell, teilweise parallel E-Mails analysieren. Dabei wird einer E-Mail von
jedem Modul eine Punktezahl zugeordnet, die Auskunft darüber geben soll, ob es
sich bei der E-Mail um Spam oder Ham handelt. Ein Modul kann einer Nachricht
sowohl einen negativen als auch einen positiven Punktewert zuweisen, wobei negative Punktewerte die Nachricht als Ham klassifizieren und positive Punktewerte
Spam anzeigen. Die Punkte der einzelnen Module werden aufaddiert und gelten
dann als Klassifikation der Nachricht.
SpamAssassin vereint viele in diesem Studienbrief beschriebene Techniken. So
wird bspw. ein DNS-basiertes Black- und Whitelisting eingesetzt (vgl. Abschnitt 3.5
ab Seite 89). Mithilfe von Hashcash (vgl. Abschnitt 3.8.4 ab Seite 89) kann verifiziert
werden, ob der Sender Arbeit verrichten musste, bevor er die E-Mail versenden
konnte. Weiterhin werden die SPF-Einträge (vgl. Abschnitt 3.8.2) und die DKIM
Signaturen (vgl. Abschnitt 3.8.1 ab Seite 82) ausgewertet. Die Software verfügt
weiterhin über einen eigenen lernfähigen Bayes-Filter (vgl. Abschnitt 3.4 ab Seite 69)
und verwendet dazu eine Menge von Regeln zur Klassifikation. Diese Regeln
können wiederum in einen deterministischen endlichen Automaten transformiert
werden, um eine schnellere Verarbeitung zu ermöglichen.
Insgesamt kann SpamAssassin in viele vorhandene SMTP-Server eingebaut werden.
In diesem Studienbrief wurden verschiedene Techniken zur Abwehr von Spam
beschrieben. Angefangen wurde dabei mit einfachen Mailfiltern, die statische
Eigenschaften wie den Inhalt, verschiedene Metainformationen oder SpamWahrscheinlichkeiten zur Klassifikation verwenden. Daraufhin wurden IP-Sperren
betrachtet und gezeigt, unter welchen Annahmen Spam blockiert (Blacklisting)
und Ham direkt an den Empfänger weitergeleitet werden kann (Whitelisting).
Dann wurden Verfahren besprochen, die auf der Reputation des Sender basieren
oder den Sender dazu auffordern eine Aufgabe zu lösen, bevor die versandte Nachricht an den Empfänger zugestellt wird. Erweiterungen des E-Mail-Verfahrens
zeigten dann unterschiedliche Ansätze, die zwar auf der einen Seite Verbesserungen bei der Spam-Abwehr bewirken, auf der anderen Seite jedoch auch das System
aufwendiger zu warten und zu benutzen machen. Nachdem eine Möglichkeit
zur Echtzeit-Filterung von URLs beschrieben wurde und auf Netzwerk-basierte
Cluster eingegangen wurde, wurden Botnetze, die aktuell für die meisten Spam
Nachrichten verantwortlich sind, behandelt. Dabei wurde zum einen auf die Erkennung von Botnetzen eingegangen und auch die Übernahme an einem konkreten
4 http://www.apache.org/licenses/LICENSE-2.0.html,
5 http://www.apache.org/, abgerufen am 27.11.2013
6 http://www.perl.org
abgerufen am 26.11.2014
K
Seite 102
Beispiel besprochen. Weiter wurde gezeigt, wie direkt aus den Spam-Nachrichten,
die aus Botnetzen versendet werden, Signaturen erzeugt werden können, die in
Erkennungssysteme eingebaut die Erkennungsrate stark verbessern. Abschließend
wurde dann ein Software-Produkt kurz vorgestellt, das weit verbreitet ist und eine
Vielzahl an hier behandelten Techniken verwendet.
3.16 Übungen
Ü
Ü
Ü
Übung 3.1: Bayes-Theorem I
Sie haben 12.004 E-Mails als Spam klassifiziert, von denen 3.182 die Zeichenkette online pharmacy enthalten. Weiterhin haben Sie 1.045 E-Mails als
Ham klassifiziert, von denen 3 die Zeichenkette online pharmacy enthalten.
Berechnen Sie die bedingte Wahrscheinlichkeit dafür, dass eine E-Mail Spam
ist, wenn sie die Zeichenkette online pharmacy enthält.
Übung 3.2: Bayes-Theorem II
Stellen Sie sich vor, dass die Spam-Wahrscheinlichkeit für eine bestimmte
Kombination von Begriffen nur bei 70 % liegt. Wie kann mit einem solchen
Wert umgegangen werden, um ihn sinnvoll zu nutzen?
Übung 3.3: Bayes-Theorem III
Betrachten Sie folgende Wortverteilungen für Spam und Ham:
Wort
today
shipping
available
medications
here
Spam
Ham
7.513
232
8.863
140
3.865
205
2.564
39
6.749
81
Gehen Sie davon aus, dass die obigen Häufigkeiten in 10.000 SpamNachrichten und 1.000 Ham-Nachrichten enthalten sind. Berechnen Sie
mithilfe des naïven Bayes-Filters jeweils die Spam-Wahrscheinlichkeiten für
E-Mails, welche die folgenden Begriffe enthalten:
1. today, available und here.
2. shipping
3. today, shipping, available, medications und here
Ü
Übung 3.4: Mailfilter
Beschreiben Sie, welche Arten es von Mailfiltern gibt und aus welchem
Grund diese nicht das gesamte Aufkommen an Spam beseitigen können.
3.16 Übungen
Übung 3.5: Blacklisting I
Finden Sie heraus, welche Anbieter es für Blacklisting gibt. Wie finanzieren
sich diese Anbieter? Wie werden die zur Verfügung gestellten Blacklists
aktualisiert?
Übung 3.6: Blacklisting II
Stellen Sie fest, mit welcher zweiten Eigenschaft in Sinha et al. [2010] das
Blacklisting verbessert werden soll.
Übung 3.7: Graylisting
In Abschnitt 3.5.3 auf Seite 76 wurde festgestellt, dass Graylisting eigentlich
nicht kompatibel zur RFC 2821 (vgl. Klensin [2001]) ist. Ist es denn zu der
aktuelleren Spezifizierung von SMTP, der RFC 5321 (vgl. Klensin [2008])
kompatibel?
Übung 3.8: DKIM-Signature
Betrachten Sie RFC 6376 (vgl. Crocker et al. [2011] und finden Sie heraus,
was eine Kanonisierungsmethode (engl. Canonicalization Algorithm) ist
und aus welchem Grund DKIM eine solche Funktionalität benötigt.
Übung 3.9: SPF I
Finden Sie heraus, aus welchem Grund der DNS-Eintrag, der für SPF verwendet wird, maximal 450 Zeichen lang sein soll. Hilfreich hierfür könnte
RFC 4408 (vgl. Wong and Schlitt [2006]) sein.
Übung 3.10: SPF II
Können Sie sich vorstellen, aus welchem Grund Google den DNS-SPFEintrag in Beispiel 3.5 auf Seite 87 für IPv4 und IPv6 aufteilt?
Übung 3.11: SPF III
Aus welchem Grund existiert die Bedingung SoftFail für SPF-DNSDirektiven? Suchen Sie ggf. in RFC 4408 (vgl. Wong and Schlitt [2006]) nach
einer Antwort.
Übung 3.12: Sender ID Framework
Beschreiben Sie den Algorithmus zur Bestimmung der Purported Responsible Address (PRA) nach RFC 4407 (vgl. Lyon [2006]) mit eigenen Worten.
Seite 103
Ü
Ü
Ü
Ü
Ü
Ü
Ü
Ü
Seite 104
Ü
Ü
Ü
Ü
Ü
Ü
Ü
Übung 3.13: Hashcash I
Implementieren Sie Hashcash in einer beliebigen Programmiersprache und
zeigen Sie experimentell, dass bei einem von 220 Headern die ersten 20 Bits
den Wert Null haben. Überprüfen Sie dabei auch, wie lange es dauert, für
eine 1KB große E-Mail den SHA-1 Hash zu berechnen.
Übung 3.14: Hashcash II
Gehen Sie nun davon aus, dass sich die Leistung von integrierten Schaltungen alle 24 Monate verdoppelt (Moores Gesetz) und sich dies für ComputerProzessoren genauso verhält. Wie müsste Hashcash in 40 Jahren angepasst
werden, damit die Erstellung eines validen E-Mail-Header immer noch
genauso lange dauert wie heute?
Übung 3.15: Hashcash III
Begründen Sie, warum die Differenz aus aktuellem Datum und dem in der
Headerzeile eingetragenen Datum maximal 2 Tage betragen darf, damit die
Nachricht verifiziert werden kann?
Übung 3.16: DKIM, SPF, Sender ID und Hashcash
Vergleichen Sie die Verfahren DKIM, SPF, Sender ID und Hashcash. Wo gibt
es Gemeinsamkeiten, wo existieren Unterschiede? Gibt es Verfahren, die Sie
für bestimmte Einsatzzwecke für besonders geeignet halten?
Übung 3.17: Receiver-Driven SMTP
Können Sie sich Gründe dafür vorstellen, dass das vorgeschlagene Verfahren
ab dem Jahr 2006 nicht mehr weiterverfolgt wurde?
Übung 3.18: Monarch
Untersuchen Sie, welche Merkmale in Thomas et al. [2011] zur Klassifizierung von gutartigen oder schadhaften Webseiten herangezogen werden.
Welche dieser Merkmale können auch für E-Mails zur Spamklassifikation
verwendet werden?
Übung 3.19: Torpig-Domain-Generierungs-Algorithmus
Betrachten Sie den Algorithmus zur Generierung von Domain aus StoneGross et al. [2009]. Erzeugen Sie eine Domain für den heutigen Tag.
3.16 Übungen
Übung 3.20: BotMagnifier
Verschaffen Sie sich mithilfe einer Suchmaschine Ihrer Wahl Zugang zu
Stringhini et al. [2011]. Finden Sie heraus, von wem die Autoren die Transaktionenslisten erhalten haben.
Übung 3.21: BotSniffer
Betrachten Sie Gu et al. [2008] und finden Sie heraus, wie das Modul zur
Korrelation der Daten Ergebnisse liefert.
Übung 3.22: Botnet Judo I
Was sind Micro-Anker und wofür werden sie benötigt? Versuchen Sie die
Antwort auf diese Frage in Pitsillidis et al. [2010] zu finden.
Übung 3.23: Botnet Judo II
Können Sie sich vorstellen, aus welchem Grund das System in Pitsillidis
et al. [2010] Botnet Judo genannt wird?
Übung 3.24: Allgemein
Fassen Sie Merkmale zusammen, die für die Erkennung und Vermeidung
von Spam wichtig sind.
Seite 105
Ü
Ü
Ü
Ü
Ü
Lösung zu Kontrollaufgabe 1.1 auf Seite 16
E-Mails sind im Vergleich zu gewöhnlicher Post sowohl schneller, als auch günstiger
im Versand. Hierfür wird jedoch gefordert, dass die zum Versand und Empfang
benötigte Infrastruktur bereits vorhanden ist. Weiterhin sind E-Mails umweltfreundlicher, da weder Papier benötigt wird, noch ein herkömmlicher Transport
stattfinden muss.
E-Mails werden zwar generell als umweltfreundlicher als herkömmliche Post angesehen, jedoch muss dabei beachtet werden, das die für das Versenden und dem
Empfang benötigte Infrastruktur einen erheblichen Einfluss auf die Umweltfreundlichkeit haben kann. Ein zum Empfang und zum Versand benötigter Computer
muss bspw. erst durch aufwendige Techniken gebaut werden, wobei nicht unerhebliche Mengen an schadhaften Stoffen entstehen. Weiterhin muss ein solcher
Computer betrieben werden, was entsprechend Energie erfordert, die im Allgemeinen nicht umweltfreundlich hergestellt wird. Weiterhin muss auch die gesamte
Infrastruktur berücksichtigt werden, angefangen vom Rechenzentrum, in dem der
E-Mail-Server betrieben wird, bis hin zu den Datenleitungen, die die Informationen
übertragen. Dies alles in eine Rechnung zur Umweltfreundlichkeit einfließen zu
lassen ist aufgrund der Komplexität sehr schwierig, wodurch nicht mit absoluter
Sicherheit gesagt werden kann, dass elektronische Post umweltfreundlicher als
gewöhnliche Post ist.
Spam gibt es bspw. auch in Gästebüchern, Foren und Online-Spielen sowie bei
Instant Messengern.
Ein möglicher Ursprung ist Webmail. Hier können Spamversender kostenlos Konten erstellen, um darüber ihre Werbebotschaften zu verbreiten. Auf der anderen
Seite werden heutzutage immer öfter Botnetze zum Versand von Spam versendet.
Hier ist es für die Spammer hilfreich, dass die einzelnen Bots bedingt durch täglich
wechselnde IP-Adressen nur schwer zu blockieren sind.
Würde anstelle des Client-Server-Modells das Peer-to-Peer-Modell für die E-MailKommunikation verwendet werden, so müssten entweder sichergestellt sein, dass
immer alle Computer, also auch die Computer der Endnutzer, verfügbar sind, oder
die Software zum Versand müsste nach erfolglosem Verbindungsversuch ständig
überprüfen, ob ein Empfänger verfügbar wird, was entsprechende Ressourcen
kostet.
Zeilen sollten eine Länge von 78 Zeichen nicht überschreiten und dürfen maximal
998 Zeichen lang sein. Diese Beschränkung wurde in den Standard aufgenommen,
damit einzelne Zeilen einfacher durch Softwareprodukte zu bearbeiten sind. Hier
können bspw. reguläre Ausdrücke schneller abgearbeitet werden.
Seite 107
Seite 108
Nach RFC 5322 ist es auch möglich, dass keine Empfänger im to Header Feld
definiert werden. E-Mails, die keine Empfänger im to Header Feld enthalten,
müssen dann jedoch mindestens einen Empfänger im cc oder bcc Header Feld
enthalten, da sonst wirklich kein Empfänger existiert.
SMTP wird zum Versand von E-Mail-Nachrichten verwendet. Dabei verbindet sich
ein Client mit einem Server und geht dabei die einzelnen Schritte des definierten
Protokolls durch. Mit SMTP können jedoch keine Nachrichten von einem Server
abgeholt werden. Es ist ein reines unidirektionales Protokoll zum Versand von
E-Mails.
Bei der Base64 Kodierung wird die gleiche Zuordnungstabelle sowohl für die
Kodierung als auch für die Dekodierung verwendet. Aufgrund dieser Tatsache, ist
der Schlüssel, also die Tabelle allgemein bekannt und ersetzt daher keine Verschlüsselung. Es wäre zwar möglich, mit verschiedenen Tabellen zu arbeiten, allerdings
ist die Anzahl der möglichen Tabellen sehr stark begrenzt, weshalb ein Brute-Force
Angriff sehr einfach möglich wäre, um eine solche Verschlüsselung zu knacken.
Bei der SMTP-Auth Variante PLAIN werden das Passwort und der Benutzername
jeweils mit dem Base64 Verfahren kodiert. Das verhindert zwar kurzfristig, dass sie
direkt im Klartext sichtbar sind, jedoch können sie sehr einfach wieder dekodiert
werden, da die Zuordnungstabelle für die Base64 Kodierung allgemein bekannt
ist.
Durch positive bzw. negative Server-Rückmeldungen erfährt der Client, was genau
auf der Gegenseite passiert ist und kann den Benutzer darauf hinweisen, damit
dieser entsprechend reagieren kann. Je nach Rückmeldung ist es auch möglich,
dass der Client selbstständig auf die negative Antwort reagieren kann. Es gibt
z. B. temporäre negative Rückmeldungen, bei denen der Client nach einer kurzen
Zeitspanne versuchen kann, den Befehl erneut an den Server zu senden. Bei einem
endgültigen Fehlschlag ist es jedoch sinnvoll, den Nutzer darüber zu informieren.
Der LIST Befehl gibt nur einige weniger Header Felder der vorhandenen E-Mails
auf dem Server aus. Im Gegensatz dazu kann mit Hilfe des RETR Befehls die komplette E-Mail abgerufen werden.
Wird der DELE Befehl auf eine bestimmte E-Mail angewendet, so wird diese zum
Löschen markiert, jedoch nicht direkt gelöscht. Erst bei Beendigung der POP3Verbindung wird die E-Mail gelöscht.
Der NOOP-Befehl ist notwendig, sofern der POP3-Server einen Timer einsetzt, um die
Verbindung bei Inaktivität zu schließen, der Client des Benutzers die Verbindung
aber weiterhin verwenden will. Sofern der POP3-Server keinen Timer einsetzt, ist
die Verwendung des NOOP-Befehls nicht notwendig.
IMAP wird verwendet, um eine Kommunikation zu einem E-Mail-Server aufzubauen. Dabei ist nicht nur ein Abruf der E-Mails vom Server möglich, sondern
auch eine Veränderung oder eine Suche nach E-Mails auf dem Server. So können
bspw. bestimmte Schlüsselwörter an E-Mails angehängt werden, die E-Mails z. B.
als gelesen markieren.
Bei IMAP findet die Nutzerauthentifizierung im Klartext statt, wodurch die Anmeldedaten bei reinen IMAP-Implementierungen leicht abgegriffen werden können.
Weiterhin ist auch der Rest der Kommunikation nicht verschlüsselt, wodurch alle
Informationen, die während einer Sitzung vom Nutzer abgerufen werden, abgehört
werden können.
DNS ist ein System zur Identifizierung von Computern im Internet. Computer
verfügen über numerische Adressen. Da auf Text-basierende Adressen für Menschen jedoch einfacher zu merken sind, wird DNS dazu verwendet, um aus einer
Text-basierten Adresse die dazu passende numerische Adresse zu finden. Es wird
für Anti-Spam-Maßnahmen wie DNS-basiertes Blacklisting verwendet, um Informationen über eine IP-Adresse zu erhalten.
Für die Empfänger von Spam entstehen unterschiedliche Kosten. Auf der einen
Seite stehen Personalkosten, sofern Spam von Mitarbeitern in einem Unternehmen
aussortiert werden muss. Hier wird Arbeitszeit verwendet, die nicht der Wertschöpfung im Unternehmen dient. Auf der anderen Seite entstehen Kosten für die
Infrastruktur. Das sind zum einen die Internetanbindung und die Speicherplatzlösungen, die entsprechend größer dimensioniert werden müssen, zum anderen
muss aber auch entsprechende Software zur Filterung von Spam erworben werden,
wodurch wieder Kosten entstehen.
Die Versender von Spam profitieren indem Spamempfänger die in den Werbebotschaften beworbenen Produkte kaufen.
Der Versuch, der Erlangung von persönlichen Daten, um bspw. Zugriff auf das
Bankkonto einer Person zu erhalten, wird als Phishing bezeichnet. Spam kann
als Medium für Phishing dienen, in dem keine Werbebotschaft übertragen wird,
sondern der Nutzer eine E-Mail erhält, die ihn auf eine gefälschte Internetseite
leitet, auf der er bestimmte persönliche Daten eingeben soll, mit denen Kriminelle
das Opfer betrügen.
Seite 109
Seite 110
Spammer benötigen um erfolgreich Spam zu versenden, viele Kontakte, damit sie
möglichst effektiv sein können. Ein Spammer selber benötigt eine Adressdatenbank, aus der er Adressen an Adresshändler oder andere Spammer verkaufen kann.
Genauso muss er seine Datenbank ständig durch den Ankauf neuer Adressen erweitern. Er benötigt ebenfalls Bullet-Proof Server sowie Bankkonten in Ländern, die
nicht mit Regierungen kooperieren, die versuchen gegen die Spammer vorzugehen.
Der Spammer benötigt Kontakte zu den Produzenten und Versanddienstleistern
der Produkte, die er bewirbt. Er muss Botnetze anmieten oder kaufen, um darüber
Spam zu versenden und kann auch seine Infrastruktur anderen zur Verfügung
stellen. Weiterhin kann er freie Mitarbeiter haben, die für ihn Adressen suchen
oder Spam verschicken.
Unter dem Begriff Adress-Harvesting versteht man das Suchen und Sammeln
von E-Mail-Adressen, die daraufhin als Empfänger für den Versand von Spam
missbraucht werden.
Wenn die Länge des Nutzernamens fünf oder weniger Zeichen betragen darf und
von einem Alphabet mit 36 Zeichen ausgegangen wird, dann ergeben sich
5
∑ 36i = 361 + 362 + 363 + 364 + 365 = 62.193.780
i=1
Möglichkeiten.
Werden auch Sonderzeichen wie „.“, „-“und „_“erlaubt, so ergibt sich eine Basismenge von 39 Zeichen. Es entstehen somit
5
∑ 39i = 391 + 392 + 393 + 394 + 395 = 92.598.519
i=1
Möglichkeiten.
Um Adress-Harvesting auszuhebeln gibt es verschiedene Methoden, die die E-MailAdresse verändern. Dabei kann die Adresse bspw. durch bestimmte Substitutionen
verändert werden, indem das @ durch <at> oder der Punkt durch <dot> ersetzt
wird. Genauso können für Teile der E-Mail-Adresse auch Bilder angezeigt werden,
was natürlich auch für die gesamte E-Mail-Adresse möglich ist. Eine weitere Möglichkeit besteht darin, eine E-Mail-Adresse auf einer Webseite erst dann anzuzeigen,
sobald der Benutzer ein CAPTCHA gelöst hat.
Adress-Munging ist eine Technik, die die E-Mail-Adresse verfremdet. Hier werden Teil der E-Mail-Adresse durch andere Teile ersetzt, die von Menschen leicht
substituiert werden können.
Es ist zu zeigen:
encrypt p (decrypt p (x)) = decrypt p (encrypt p (x)) = x
Dafür gibt es zwei Möglichkeiten:
1. Durch Iteration über alle möglichen x und alle möglichen p kann die Gleichung bewiesen werden.
2. Durch Einsetzen und ausrechnen.
Die zweite Möglichkeit beruht auf mathematischen Kenntnissen der ModuloRechnung und soll hier nicht weiter betrachtet werden. Die Behauptung lässt
sich zwar für die erste Möglichkeit von Hand zeigen, benötigt dann allerdings
für 26 Buchstaben (b ∈ {A, . . . , Z} := B) und 26 verschiedene Verschiebungen
p ∈ {0, . . . , 25} := P 26 × 26 = 676 Gleichungen. Daher wird hier eine Lösung in
Pseudocode angegeben:
for i in B
do
for j in P
do
pruefe :
encrypt_j ( decrypt_j ( i ) )
== d e c r y p t _ j ( e n c r y p t _ j ( i ) )
und
e n c r y p t _ j ( d e c r y p t _ j ( i ) ) == i
f a l l s Ungleich
Ausgabe : F e h l e r i n Gleichung f u e r
Buchstabe= i und P= j
b r i c h ab
sonst
mache w e i t e r
done
done
Ausgabe : a l l e Gleichungen sind e r f u e l l t
Die Besonderheit der ROT13-Verschiebechiffre liegt darin begründet, dass sowohl
für Ver- als auch für Entschlüsselung die gleiche Funktion verwendet werden kann.
Da Modulo 26 gerechnet wird, entspricht die Addition der Subtraktion, wodurch
nur eine Funktion benötigt wird.
SMTP-Server, die keine Nutzerauthentifizierung durchführen, nehmen von jedem
beliebigen Client Nachrichten an und schicken sie an ihr Ziel. Dieses offene Verschicken von Nachrichten macht einen SMTP-Server zu einem offenen Mail-Relay.
Offene Proxys sind Server, die Pakete auf beliebigen vorher definierten Ports annehmen und weiter leiten.
Seite 111
Seite 112
Mail-Formulare können dann zum Versand von Spam missbraucht werden, wenn
der Entwickler des Formulars nicht alle möglichen Verwendungszwecke betrachtet
hat und das Formular somit fehlerhaft implementiert wurde.
Webmail ist ein Dienst, der im WWW von verschiedenen Anbietern den Nutzern
zur Verfügung gestellt wird, um per E-Mail zu kommunizieren. Der Nutzer benötigt dafür jedoch kein eigenes E-Mail-Programm sondern nur einen Webbrowser.
Webmail bietet die Vorteile, dass die E-Mails von Dienstanbieter zentral gesichert
werden können. Auch kann das E-Mail-Konto von jedem beliebigen Computer mit
Internetanschluss und Webbrowser genutzt werden, da keine spezielle Software
installiert und konfiguriert werden muss. Als Nachteil stehen dem aber gegenüber,
dass der Nutzer keine Möglichkeit hat, die Hardwareausstattung des Webservers
zu verändern, sondern er mit der Geschwindigkeit nicht zufrieden ist. Er verfügt
außerdem über keine eigene Sicherung seiner E-Mails und ist somit stark vom
Anbieter abhängig.
Beim IP Prefix Hijacking täuscht ein Netzbereich vor, die Pakete von einem anderen Netzbereich auch weiterleiten zu können. Dann ist es möglich, dass aus
diesem Netzbereich Pakete kommen, die zwar dort entstanden sind, für andere
Netzbereiche aber so aussehen, als ob sie aus einem anderen Netz kommen.
Malware zeichnet sich durch drei wesentliche Eigenschaften aus. Zum einen verbreitet sich die Schadsoftware aktiv, indem Kopien des ausführbaren Codes auf
andere Systeme transferiert werden oder passiv, indem der Benutzer die Schadsoftware versehentlich kopiert. Dieses Merkmal wird als Selbst-Replikation bezeichnet.
Bedingt durch die Selbst-Replikation steigt die Gesamtzahl der vorhandenen Instanzen. Hierbei wird von einem Populationswachstum gesprochen. Schadsoftware kann
sich an andere Software hängen oder sich mit ihr vermischen, um unentdeckt zu
bleiben. Diese Eigenschaft wird als Parasitismus bezeichnet.
Ein Botnetz besteht aus vielen mit Malware infizierten Computern, die von einer
bestimmten Stelle (zentral oder dezentral) aus gesteuert werden können. Dabei
können die einzelnen Rechner dazu missbraucht werden E-Mail-Adressen zu
sammeln oder auch Spam zu verschicken.
Generell lassen sich die Kontrollstrukturen in zentrale und dezentrale Strukturen
gliedern. Bei den zentralen Strukturen kann eine Kommunikation per IRC, HTTP
oder auch FTP statt finden. Ein Vorteil bei der zentralen Kontrollstruktur besteht in
der einfachen Implementierung und auch darin, dass bspw. HTTP nur in seltenen
Fällen durch Firewall-Regeln blockiert wird. Der Nachteil liegt jedoch darin, dass
nur die zentralen Server vom Netz genommen werden müssen, damit das gesamte
Botnetz keine weiteren Befehle mehr annehmen kann. Eine dezentrale Kommuni-
kation setzt auf Peer-To-Peer Protokolle. Hierbei sind mehrere Bots miteinander
verbunden und geben die Befehle dann jeweils an die verbundenen Bots weiter. Die
Implementierung ist hierbei aufwendiger, jedoch ist die Ausfalltoleranz deutlich
größer. Es existiert keine zentrale Instanz, die vom Netz genommen werden kann,
somit sind solche Botsnetze deutlich robuster.
Beim IRC Protokoll besteht zwischen Client und Server eine persistente Verbindung.
Da es eine Obergrenze für offene Verbindungen innerhalb jeder IRC Implementierung gibt, können sich nicht mehr Bots verbinden, als die Implementierung
vorsieht. Bei einer Kommunikation per HTTP kann das Aktualisierungsintervall
prinzipiell fast beliebig groß gewählt werden. Damit sind auch fast beliebig viele
anfragende Bots möglich.
Botnetze können neben dem Versand von Spam auch für das Adress-Harvesting
eingesetzt werden. Dies kann sowohl auf dem befallen Computer passieren, als
auch im WWW. Daneben können Botnetze bspw. auch für DDoS Angriffe eingesetzt
werden.
Mailfiter können auf der einen Seite durch statische Regeln definiert werden. Dabei wird überprüft, ob eine Regel zutrifft oder nicht. Weiterhin sind Signaturen
möglich, die nicht den gesamten Inhalt einer E-Mail analysieren, sondern nur
Metainformationen auswerten. Eine ausgeklügeltere Form von Mailfiltern stellen stochastische Analysen dar, wie bspw. Bayesfilter. Mit Hilfe von Bayesfiltern
kann die Spam-Wahrscheinlichkeit bestimmt werden, sofern eine E-Mail gewisse
Begriffe enthält.
Bayesfilter ermöglichen die Vorhersage ob eine E-Mail Spam ist, wenn sie bestimmte
Wörter enthält und bieten dazu eine bestimmte Wahrscheinlichkeit.
IP-Sperren sich Mechanismen, die aufgrund der IP-Adresse einer anfragenden
Verbindung darüber eine Aussage treffen, ob die IP-Adresse zu einem Computer
gehört, der Spam versendet oder nicht. Es existieren drei Arten von IP-Sperren,
das Blacklisting, das Whitelisting und das Graylisting.
Sinnvollerweise werden IP-Sperren in SMTP-Servern eingesetzt. SMTP spezifiziert,
dass ein Ablehnen einer E-Mail geschehen muss, noch wären die Verbindung
zwischen Client und Server geöffnet ist. Eine einmal angenommene E-Mail soll
demnach auch dem Empfänger zugestellt werden. Soll also aufgrund eines Listeneintrags eine E-Mail von einem bestimmten Client nicht angenommen werden, so
muss dies noch während des Transfers unterbrochen werden, was nur innerhalb
des empfangenden SMTP-Server geschehen kann.
Seite 113
Seite 114
Blacklisting kann auf der einen Seite lokal praktiziert werden. Hier kann der SMTPServer sich selber um eine Liste kümmern, die er bspw. durch Reputationsverfahren
aktualisiert. Im Gegensatz zu dieser lokalen Methode gibt es aber auch eine zentrale
Methode, bei der ein Server im Internet Anfragen aus unterschiedlichen Netzen
beantwortet. Für die zentrale Methode hat sich DNS als Protokoll für die Anfrage
ob ein Eintrag in der Liste vorhanden ist etabliert.
Um eine IP-Adresse zu überprüfen müssen zuerst die Reihenfolge der vier Teile
der IP-Adresse umgedreht werden. Aus 192.168.2.1 wird 1.2.168.192; An die
resultierende Adresse wird im zweiten Schritt die Adresse des DNSBL-Servers angehängt (bspw. 1.2.168.192.dnsbl.rub.de). Im dritten Schritt wird diese Adresse
dann per DNS aufgelöst. Das Resultat kann entweder eine IP-Adresse sein, die
einen positiven Treffen in der Liste des Servers anzeigt, oder kein Datensatz, was
bedeutet, dass es keinen Eintrag zu dieser IP-Adresse in der Liste des Servers gab.
Im vierten Schritt kann dann noch der Grund beim DNSBL-Server für den Eintrag
der IP-Adresse angefragt werden.
Blacklists können einfach implementiert werden und sind gut dazu geeignet Spammer zu blockieren, die Spam von statische IP-Adressen aus senden. Da eine E-Mail
aber erst als Spam von einem anderen System erkannt werden muss, unterliegen
Blacklists immer eine gewissen zeitlichen Verzögerung und können somit nicht
alle Verbindungsanfragen von Spammern blockieren. Als problematisch stellt sich
aber auch die Zweckentfremdung von DNS für die Spambekämpfung dar, da DNS
somit ein mögliches Ziel für Spammer wird, die das System stören könnten, um
daraufhin effektiver Spam versenden zu können.
Beim Whitelisting wird im Gegensatz zum Blacklisting nicht eine Liste mit Spamversendern gepflegt, sondern eine Liste mit regulären E-Mail-Versendern. Auch
hier wird unterschieden in lokales Whitelisting und globales Whitelisting, das
auch per DNS ausgeführt werden kann. Whitelisting soll sicherstellen, dass nur
E-Mails ein Konto erreichen, deren Absender im Vorhinein bereits als erwünschte
Absender festgelegt wurden.
Beim Graylisting werden beim Zustellversuch IP-Adresse, Absender-Adresse sowie
Empfänger-Adresse im E-Mail-Header gespeichert und der Versuch durch einen
temporären Fehlercode durch den SMTP-Server beendet. Der Client muss nun
nach mindestens 25 Minuten und maximal vier Stunden eine erneute Zustellung
versuchen. Wird die Zustellung innerhalb dieser Zeitspanne wiederholt, so wird
die E-Mail an den Empfänger zugestellt. Ist dies nicht der Fall, so beginnt bei einem
Zustellversuch ein neues Intervall. Graylisting kommt ohne externe Dienstanbieter
aus, da alle Daten dazu lokal gespeichert und gehalten werden können. Eine
globale Lösung hätte keinen Mehrwert und wäre auch nicht sinnvoll, da der lokale
SMTP-Server nur E-Mails empfängt, die an lokale Konten adressiert sind.
Graylisting bietet den Vorteil, dass es für den Administrator des SMTP-Servers
einfach zu installieren und zu konfigurieren ist. Es ist relativ wartungsfrei und
wird daher auch gerne eingesetzt. Ein weiterer Vorteil liegt beim Client, der für
Graylisting nicht angepasst werden muss. Der Nutzer merkt eigentlich nur an der
verzögerten Zustellung, dass Graylisting aktiv ist. Dieser Punkt ist aber auch direkt
ein Nachteil, da beim Graylisting der eigentliche Vorteil der schnellen Zustellung
durch das Verfahren verzögert wird. Weiterhin bietet Graylisting keinen vollständigen Schutz gegen Spam. Es baut auf einer unvollständigen Implementierung
der E-Mail-Software von Spam verbreitenden Bots auf, die prinzipiell ohne große
Probleme in diesem Punkt vervollständigt werden kann.
DKIM ist eine Methode, um den Absender einer E-Mail zu verifizieren. Dazu fügt
der SMTP-Server des Absenders ein weiteres Header Feld zur E-Mail hinzu, die den
Hash von Teilen der E-Mail, mit dem privaten Schlüssel der Domain verschlüsselt,
enthält. Der empfangende SMTP-Server kann dann per DNS den öffentlichen
Schlüssel anfordern und den selber erstellten Hash mit dem entschlüsselten Hash
vergleichen, um den Absender der E-Mail zu verifizieren. DKIM kann dabei jedoch
nicht entscheiden, ob es sich bei einer E-Mail um Spam handelt oder nicht. Reguläre
E-Mails, die keine oder keine gültige DKIM-Signature enthalten, können nicht
als Spam klassifiziert werden, genauso können E-Mails, die eine gültige DKIMSignature enthalten, nicht automatisch als Ham klassifiziert werden, da Spammer
auch gültige DKIM-Signaturen an ihre E-Mails anhängen können, sofern sie den
DNS Eintrag zu der zum Versand verwendeten Domain verändern können.
DKIM ist auf der einen Seite für den Benutzer transparent, da alle Änderungen
und Verifikationen auf den SMTP-Servern durchgeführt werden. Eine fehlerhafte
oder nicht vorhandene DKIM Signature von einer Bank ist ein starkes Indiz für
Phishing. Auf der anderen Seite kann eine E-Mail aber beim Transfer zwischen
unterschiedlichen Character Sets konvertiert werden, wodurch die DKIM Signature
nicht mehr zum Inhalt der E-Mail passt. Letztendlich muss wie bei allen anderen
Verfahren, die auf kryptographischen Methoden aufbauen, darauf geachtet werden,
dass die Schlüssellängen nicht zu kurz gewählt werden, da sonst durch einen
Bruteforce-Angriff das Verfahren gestört werden kann.
SPF ist ähnlich wie DKIM ein System zur Verifikation von E-Mails. Dabei wird
bei SPF allerdings untersucht, ob der Versender die Berechtigung hat für die
Absenderadresse eine Nachricht zu verschicken. Es wird jedoch nicht überprüft,
ob der Inhalt der Nachricht während des Transports vom Sender zum Empfänger
geändert wurde.
Direktiven werden benötigt, um auszuwerten, ob eine IP-Adresse zum Versenden
einer E-Mail mit einer bestimmten Absenderadresse autorisiert ist. Die Direktiven
werden auf die IP-Adresse des Versenders angewendet und die zur Direktive
gehörende Bedingung gibt bei einem Treffer an, wie mit der E-Mail weiter verfahren
werden soll.
Die ?-Bedingung soll für IP-Adressen zutreffen, bei denen der Besitzer der Domain
Seite 115
Seite 116
explizit erklärt, dass es zu diesen IP-Adressen keine Aussage treffen kann oder
will. Die Antwort soll vom Server wie eine leere Antwort behandelt werden.
Zur Verifizierung des Senders wird beim Sender ID Framework nicht nur die IP des
Absenders verwendet, sondern auch die Purported Responsible Address (PRA).
Hashcash ist ein System, bei dem der Sender einer E-Mail einen Proof-of-Work
an den Empfänger schickt, der wiederum mit einem vergleichsweise geringen
Aufwand überprüfen kann, ob der Sender diese Arbeit wirklich verrichtet hat.
Erhält der Empfänger eine E-Mail, bei der sich die Headerzeile H-Hashcash: bereits
in seiner Datenbank befand, so kann dies zwei Gründe haben:
1. Der Sender hat am selben Tag zwei unterschiedliche E-Mails an den Empfänger verschickt, bei denen die Zufallszahlen jeweils gleich waren.
2. Eine reguläre E-Mail wurde auf dem Transfer zwischen Sender und Empfänger von einem Spammer mitgeschnitten und nun versucht der Spammer
durch Angabe eines regulären Headers Spam an den Empfänger zu versenden.
Hashcash bietet den Vorteil, dass es sich um ein Client-seitiges System handelt.
Es müssen also nur Erweiterungen innerhalb der E-Mail-Clients implementiert
werden, die SMTP-Server müssen jedoch nicht verändert werden. Auch wird nur
Rechenleistung verbraucht, aber kein echtes Geld. Die Nachteile sind allerdings
dadurch begründet, dass langsame Computer deutlich benachteiligt werden. Auch
müssen Versender von Newslettern deutlich mehr Leistung zum Versand der
Nachrichten investieren.
Monarch untersucht URLs darauf, ob sie gutartig sind, oder schadhafte Software
oder Skripte enthalte oder auch zum Phishing verwendet werden. Das System
könnte zur Erkennung von Spam verwendet werden, indem URLs aus E-Mails
vom System untersucht werden und das Resultat dann als Merkmal für die Klassifikation der E-Mail eingesetzt wird.
Beim Torpig Botnetz wird die Domain Flux Technik eingesetzt, damit die einzelnen
Bots den Command und Control Server finden. Da es sich bei Torpig um eine PeerTo-Peer Archtitektur mit Command and Control Struktur handelt, kann es mehrere
Command and Control Server geben, mit denen sich die Bots verbinden. Daher
wird eine Technik benötigt, um immer den aktuellen Server zu finden.
In beiden Ansätzen wird davon ausgegangen, dass Bots eines Botnetzes ein ähn-
liches Verhalten aufweisen. Durch diesen Ansatz ist es möglich, Gruppen mit
ähnlichem Verhalten zu erstellen, die dann einem Botnetz zugewiesen werden
können.
Damit eine Signatur erzeugt werden kann, müssen Spam Nachrichten vorliegen, die
große Ähnlichkeiten aufweisen. Nur so kann erkannt werden, welche Teile in der
Nachricht statisch und welche Teile dynamisch sind. Liegen nur sehr wenige Spam
Nachrichten vor, so ist es schwieriger Ähnlichkeiten innerhalb der Nachrichten
ausfindig zu machen. Genauso wichtig ist es, dass die Nachrichten nicht von
vielen unterschiedlichen Templates stammen, sonst ist eine Zuordnung von Spam
Nachricht zu Template sehr schwierig. Sind insgesamt nur wenige Nachrichten
vorhanden die auch noch aus unterschiedlichen Templates stammen, so kann keine
gute Signatur erzeugt werden, d. h. die resultierende Signatur hat nachher eine
hohe Fehlerrate.
Bei dem Update-Mechanismus werden bereits fertige Signaturen nachträglich
verändern, sofern E-Mails erkannt werden und die Makros deaktiviert sind. Eine
Aktualisierung ist in diesem Zusammenhang wichtig, da die Anzahl der Signaturen
immer möglichst klein gehalten werden sollte, damit eine Erkennung auch in
annehmbarer Zeit möglich ist.
Der Parameter q gibt die minimale Anker-Länge an, die für die Erzeugung von
Ankern verwendet wird. Sehr kurze minimale Anker-Längen können zu Ankern
führen, die allgemeine Zeichen enthalten, sich jedoch nicht als Anker eignen. Zu
lange minimale Anker-Längen wiederum können dazu führen, dass mögliche
kurze Anker gar nicht betrachtet werden.
Der Parameter k ist verantwortlich für die Größe des Trainings-Puffers. Ist der
Trainings-Puffer zu klein, kann es passieren, dass Signaturen erstellt werden, obwohl Wörterbücher noch nicht komplett erkannt wurden. Ist der Trainings-Puffer
zu groß, so können Nachrichten von unterschiedlichen Templates zu ungenauen
Signaturen führen.
Seite 117
Verzeichnisse
Seite 119
Verzeichnisse
I. Abbildungen
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
1.1:
1.2:
1.3:
1.4:
1.5:
1.6:
1.7:
1.8:
2.1:
2.2:
3.1:
3.2:
3.3:
3.4:
3.5:
3.6:
3.7:
3.8:
3.9:
3.10:
3.11:
SPAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Spamanteil von 2006-2012 aus Symantec Corporation [2012] .
UML-Sequenzdiagramm einer beispielhaften E-Mail-Sitzung. . .
UML-Sequenzdiagramm einer SMTP-Sitzung. . . . . . . . . . . .
UML-Zustandsdiagramm einer POP3-Sitzung. . . . . . . . . . .
UML-Sequenzdiagramm einer POP3-Sitzung. . . . . . . . . . . .
UML-Sequenzdiagramm einer IMAP-Sitzung. . . . . . . . . . . .
Spam-Wertschöpfungskette . . . . . . . . . . . . . . . . . . . .
Aufbau eines Spammer-Netzwerks . . . . . . . . . . . . . . . .
Ein visuelles CAPTCHA. . . . . . . . . . . . . . . . . . . . . . . .
Blacklist-Erstellung aus Sinha et al. [2010] . . . . . . . . . . . .
Blacklist-Erstellung nach Sinha et al. [2010] . . . . . . . . . . .
SNARE-Framework aus Ramachandran and Feamster [2006] . .
Funktionsweise von Sender ID aus Microsoft Corporation [2007]
Funktionsweise von Monarch aus Thomas et al. [2011] . . . . .
Flussdiagramm von Monarch aus Thomas et al. [2011] . . . . .
Raum- und zeitliche Korrelation von Bot-Antworten aus Gu et al.
Architekturübersicht von BotSniffer aus Gu et al. [2008] . . . .
Torpig-Netzwerk-Infrastruktur aus Stone-Gross et al. [2009] . .
Systemüberblick aus Pitsillidis et al. [2010] . . . . . . . . . . .
Signatur Erstellungs Algorithmus aus Pitsillidis et al. [2010] . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
[2008]
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
15
18
41
42
43
44
44
46
50
74
75
80
88
92
92
94
95
96
98
99
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
22
24
27
71
83
84
87
87
Definition 1.1: E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Definition 1.2: Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Definition 2.1: Malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
11
62
II. Beispiele
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
1.1:
1.2:
1.3:
1.4:
3.1:
3.2:
3.3:
3.4:
3.5:
Eine einfache E-Mail . . . . . . . . . . . . . . . . . . .
SMTP-Status-Codes . . . . . . . . . . . . . . . . . . .
Base64-Kodierung . . . . . . . . . . . . . . . . . . . .
POP3-Befehle . . . . . . . . . . . . . . . . . . . . . . .
Bayes-Theorem . . . . . . . . . . . . . . . . . . . . .
DKIM-Signature . . . . . . . . . . . . . . . . . . . . .
DKIM-Verifikation . . . . . . . . . . . . . . . . . . . . .
SPF-Eintrag für den Google Mail-Dienst . . . . . . . . .
SPF-DNS-Einträge: Auflösung einer include Direktive
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
III. Definitionen
IV. Exkurse
Exkurs
Exkurs
Exkurs
Exkurs
Exkurs
1.1:
1.2:
1.3:
1.4:
1.5:
Instant-Messenger-Spam
Mobile-Phone-Spam . . .
Foren-Spam . . . . . . .
Online-Game-Spam . . .
Spamdexing . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
12
13
13
13
Seite 120
Exkurs 1.6:
Exkurs 1.7:
Exkurs 1.8:
Exkurs 1.9:
Exkurs 1.10:
Exkurs 1.11:
Exkurs 2.1:
Exkurs 2.2:
Exkurs 2.3:
Exkurs 3.1:
Exkurs 3.2:
Exkurs 3.3:
Exkurs 3.4:
Verzeichnisse
Blog-, Wiki- und Gästebuch-Spam
SPIT und VoIP-Spam . . . . . . . .
Academic Search Spam . . . . . .
US-ASCII . . . . . . . . . . . . . .
SMTP-Status-Codes . . . . . . . .
Base64-Kodierung . . . . . . . . .
Verschiebechiffre . . . . . . . . .
ROT13 . . . . . . . . . . . . . . . .
Felder in HTML Formularen . . . .
DKIM-Signature . . . . . . . . . .
Asymmetrische Kryptographie . .
SPF-DNS-Einträge . . . . . . . . .
Reverse Engineering . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
14
14
19
21
23
53
53
58
83
85
86
97
Vorteile von E-Mails . . . . . . . . . . . . . . . . . .
Umweltfreundlichkeit von E-Mails . . . . . . . . . .
Spam in anderen Medien . . . . . . . . . . . . . . .
Der Ursprung von Spam . . . . . . . . . . . . . . . .
Modellentscheidung . . . . . . . . . . . . . . . . . .
Beschränkung der Zeilenlänge innerhalb von E-Mails
Anzahl der to Header Felder einer E-Mail . . . . . .
Verwendung von SMTP . . . . . . . . . . . . . . . .
Base64 Kodierung . . . . . . . . . . . . . . . . . . .
SMTP Auth . . . . . . . . . . . . . . . . . . . . . . .
POP3 Server Rückmeldungen . . . . . . . . . . . . .
POP3 Befehl: LIST und RETR . . . . . . . . . . . . .
POP3 Befehl: DELE . . . . . . . . . . . . . . . . . . .
POP3 Befehl: NOOP . . . . . . . . . . . . . . . . . . .
Verwendung von IMAP . . . . . . . . . . . . . . . . .
Schächen von IMAP . . . . . . . . . . . . . . . . . .
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kosten für Spam . . . . . . . . . . . . . . . . . . . .
Profit Spamversand . . . . . . . . . . . . . . . . . .
Phishing . . . . . . . . . . . . . . . . . . . . . . . .
Spammer-Netzwerk . . . . . . . . . . . . . . . . . .
Adress-Harvesting . . . . . . . . . . . . . . . . . . .
Directory Harvest Attack . . . . . . . . . . . . . . .
Anti-Adress-Harvesting . . . . . . . . . . . . . . . .
Adress Munging . . . . . . . . . . . . . . . . . . . .
Verschiebechiffre . . . . . . . . . . . . . . . . . . .
ROT13-Verschiebechiffre . . . . . . . . . . . . . . . .
Offene Mail-Relays . . . . . . . . . . . . . . . . . . .
Offene Proxies . . . . . . . . . . . . . . . . . . . . .
Mail-Formulare . . . . . . . . . . . . . . . . . . . . .
Webmail I . . . . . . . . . . . . . . . . . . . . . . . .
Webmail II . . . . . . . . . . . . . . . . . . . . . . .
IP Prefix Hijacking . . . . . . . . . . . . . . . . . . .
Malware . . . . . . . . . . . . . . . . . . . . . . . .
Botnetz I . . . . . . . . . . . . . . . . . . . . . . . .
Botnetz II . . . . . . . . . . . . . . . . . . . . . . . .
Botnetz III . . . . . . . . . . . . . . . . . . . . . . .
Botnetz IV . . . . . . . . . . . . . . . . . . . . . . .
Mailfilter . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
17
17
17
31
31
31
31
31
32
32
32
32
32
32
32
32
35
35
37
54
54
55
55
55
55
55
56
57
57
60
60
61
65
65
65
65
65
72
V. Kontrollaufgaben
Kontrollaufgabe 1.1:
Literatur
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Seite 121
3.2:
3.3:
3.4:
3.5:
3.6:
3.7:
3.8:
3.9:
3.10:
3.11:
3.12:
3.13:
3.14:
3.15:
3.16:
3.17:
3.18:
3.19:
3.20:
3.21:
3.22:
3.23:
3.24:
3.25:
Bayesfilter . . . . . . . . .
IP-Sperren I . . . . . . . . .
IP-Sperren II . . . . . . . .
Blacklisting I . . . . . . . .
Blacklisting II . . . . . . . .
Blacklisting III . . . . . . .
Whitelisting . . . . . . . .
Graylisting . . . . . . . . .
Graylisting II . . . . . . . .
DKIM I . . . . . . . . . . .
DKIM II . . . . . . . . . . .
SPF I . . . . . . . . . . . .
SPF II . . . . . . . . . . . .
SPF III . . . . . . . . . . . .
Sender ID . . . . . . . . . .
Hashcash I . . . . . . . . .
Hashcash II . . . . . . . . .
Hashcash III . . . . . . . .
Monarch . . . . . . . . . .
Domain Flux . . . . . . . .
BotMagnifier und BotSniffer
Botnet Judo I . . . . . . . .
Botnet Judo II . . . . . . . .
Botnet Judo III . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
72
77
77
78
78
78
78
78
78
90
91
91
91
91
91
91
91
91
92
98
100
100
100
101
VI. Literatur
108th United States Congress. 15 USC Chapter 103 - Controlling the Assault of Non-Solicited Pornography
And Marketing, Public Law No. 108-187. Website, 2012. Online verfügbar auf http://uscode.house.gov/
download/pls/15C103.txt; besucht am 10.12.2012.
E. Allman, J. Callas, M. Delany, M. Libbey, J. Fenton, and M. Thomas. RFC 4871: DomainKeys Identified Mail
(DKIM) Signatures. Website, 2007. Online verfügbar auf http://tools.ietf.org/html/rfc4871; besucht am
01.01.2013.
E. Allman, J. Fenton, M. Delany, and J. Levine. RFC 5617: DomainKeys Identified Mail (DKIM) Author Domain
Signing Practices (ADSP). Website, 2009. Online verfügbar auf http://tools.ietf.org/html/rfc5617;
besucht am 02.01.2013.
P. Almquist. RFC 1349: Type of Service in the Internet Protocol Suite. Website, 1992. Online verfügbar auf
http://tools.ietf.org/html/rfc1349; besucht am 20.12.2012.
John Aycock. Computer Viruses and Malware. Advances in Information Security. Springer, 2006. ISBN
978-0-387-30236-2.
Adam Back. Hashcash - A Denial of Service Counter-Measure. Technical report, 2002.
BBC. Spam on rise after brief reprieve. Website, 2008. Online verfügbar auf http://news.bbc.co.uk/2/hi/
technology/7749835.stm; besucht am 30.12.2012.
Joeran Beel and Bela Gipp. Academic search engine spam and Google Scholar’s resilience against it. Journal of
Electronic Publishing, 13(3), December 2010. doi: 10.3998/3336451.0013.305. URL http://quod.lib.umich.edu/
cgi/t/text/text-idx?c=jep;view=text;rgn=main;idno=3336451.0013.305.
T. Berners-Lee and D. Connolly. RFC 1866: Hypertext Markup Language - 2.0. Website, 1995. Online
verfügbar auf http://tools.ietf.org/html/rfc1866; besucht am 19.12.2012.
Seite 122
Verzeichnisse
T. Berners-Lee, L. Masinter, and M. McCahill. RFC 1738: Uniform Resource Locators (URL). Website, 1994.
Online verfügbar auf http://tools.ietf.org/html/rfc1738; besucht am 03.01.2013.
T. Berners-Lee, R. Fielding, and H. Frystyk. RFC 1945: Hypertext Transfer Protocol – HTTP/1.0. Website,
1996. Online verfügbar auf http://tools.ietf.org/html/rfc1945; besucht am 13.12.2012.
D. Connolly and L. Masinter. RFC 2854: The ’text/html’ Media Type. Website, 2000. Online verfügbar auf
M. Crispin. RFC 1064: Interactive Mail Access Protocol - Version 2. Website, 1988. Online verfügbar auf
M. Crispin. RFC 1730: Internet Message Access Protocol - Version 4. Website, 1994. Online verfügbar auf
M. Crispin. RFC 3501: Internet Message Access Protocoll - Version 4rev1. Website, 2003. Online verfügbar
auf http://tools.ietf.org/html/rfc3501; besucht am 18.09.2012.
D. Crocker. RFC 5672: RFC 4871 DomainKeys Identified Mail (DKIM) Signatures – Update. Website, 2009.
D. Crocker, T. Hansen, and M. Kucherawy. RFC 6376: DomainKeys Identified Mail (DKIM) Signatures.
Website, 2011. Online verfügbar auf http://tools.ietf.org/html/rfc6376; besucht am 01.01.2013.
David H. Crocker. RFC 822: Standard for the Format of ARPA Internet Text Messages. Website, 1982. Online
Ernesto Damiani, Sabrina De Capitani di Vimercati, Stefano Paraboschi, and Pierangela Samarati. P2P-Based
Collaborative Spam Detection and Filtering. In Germano Caronni, Nathalie Weiler, and Nahid Shahmehri,
editors, Peer-to-Peer Computing, pages 176–183. IEEE Computer Society, 2004. ISBN 0-7695-2156-8.
Dancho Danchev. Research: Small DIY botnets prevalent in enterprise networks. Website, 2009. Online verfügbar auf http://www.zdnet.com/blog/security/research-small-diy-botnets-prevalent-in-enterprisenetworks/4485; besucht am 30.12.2012.
S. Deering and R. Hinden. RFC 2460: Internet Protocol, Version 6 (IPv6) Specification. Website, 1998. Online
M. Delany. RFC 4870: Domain-Based Email Authentication Using Public Keys Advertised in the DNS
(DomainKeys). Website, 2007. Online verfügbar auf http://tools.ietf.org/html/rfc4870; besucht am
01.01.2013.
Rachna Dhamija, J. D. Tygar, and Marti A. Hearst. Why Phishing Works. In Rebecca E. Grinter, Tom Rodden,
Paul M. Aoki, Edward Cutrell, Robin Jeffries, and Gary M. Olson, editors, CHI, pages 581–590. ACM, 2006.
ISBN 1-59593-372-7.
Z. Duan, K. Gopalan, and Y. Dong. Receiver-Driven Extensions to SMTP draft-duan-smtp-receiver-driven00.txt. Website, 2005a. Online verfügbar auf http://tools.ietf.org/html/draft-duan-smtp-receiverdriven-00; besucht am 03.01.2013.
Z. Duan, K. Gopalan, and Y. Dong. Receiver-Driven Extensions to SMTP draft-duan-smtp-receiver-driven01.txt. Website, 2005b. Online verfügbar auf http://tools.ietf.org/html/draft-duan-smtp-receiverdriven-01; besucht am 03.01.2013.
Z. Duan, K. Gopalan, and Y. Dong. Receiver-Driven Extensions to SMTP draft-duan-smtp-receiver-driven03.txt. Website, 2006a. Online verfügbar auf http://tools.ietf.org/html/draft-duan-smtp-receiverdriven-02; besucht am 03.01.2013.
Literatur
Seite 123
Z. Duan, K. Gopalan, and Y. Dong. Receiver-Driven Extensions to SMTP draft-duan-smtp-receiver-driven03.txt. Website, 2006b. Online verfügbar auf http://tools.ietf.org/html/draft-duan-smtp-receiverdriven-03; besucht am 03.01.2013.
Duden Redaktion). duden.de: E-Mail. Website, 2012a. Online verfügbar auf http://www.duden.de/
rechtschreibung/E_Mail; besucht am 27.12.2012.
Duden Redaktion).
duden.de: Freak.
Website, 2012b.
rechtschreibung/Freak; besucht am 27.12.2012.
Online verfügbar auf http://www.duden.de/
Duden Redaktion). duden.de: Phishing. Website, 2012c. Online verfügbar auf http://www.duden.de/
rechtschreibung/Phishing; besucht am 20.12.2012.
D. Eastlake and T. Hansen. RFC 4634: US Secure Hash Algorithms (SHA and HMAC-SHA). Website, 2006.
D. Eastlake and T. Hansen. RFC 6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF).
D. Eastlake and P. Jones. RFC 3174: US Secure Hash Algorithm 1 (SHA1). Website, 2001. Online verfügbar
R. Elz and R. Bush. RFC 2181: Clarifications to the DNS Specification. Website, 1997. Online verfügbar auf
Monika Ermert. Anti-Spam-Standard Sender ID: Zurück auf Start. Website, 2004. Online verfügbar auf http://www.heise.de/newsticker/meldung/Anti-Spam-Standard-Sender-ID-Zurueck-auf-Start104602.html; besucht am 03.01.2013.
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. RFC 2616: Hypertext
Transfer Protocol – HTTP/1.1. Website, 1999. Online verfügbar auf http://tools.ietf.org/html/rfc2616;
Guofei Gu, Junjie Zhang, and Wenke Lee. BotSniffer: Detecting Botnet Command and Control Channels in
Network Traffic. In NDSS. The Internet Society, 2008.
A. Gulbrandsen, P. Vixie, and L. Esibov. RFC 2782: A DNS RR for specifying the location of services (DNS
SRV). Website, 2000. Online verfügbar auf http://tools.ietf.org/html/rfc2782; besucht am 25.11.2012.
T. Hansen, D. Crocker, and P. Hallam-Baker. RFC 5585: DomainKeys Identified Mail (DKIM) Service Overview.
Shuang Hao, Nadeem Ahmed Syed, Nick Feamster, Alexander G. Gray, and Sven Krasser. Detecting Spammers
with SNARE: Spatio-temporal Network-level Automatic Reputation Engine. In USENIX Security Symposium,
pages 101–118. USENIX Association, 2009. ISBN 978-1-931971-69-0.
P. Hoffman. RFC 2487: SMTP Service Extension for Secure SMTP over TLS. Website, 1999. Online verfügbar
P. Hoffman. RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security. Website,
Hormel Foods Corporation. SPAM Classic. Website, 2012a. Online verfügbar auf http://www.spam.com/
varieties/spam-classic; besucht am 19.04.2012.
Hormel Foods Corporation. History of the SPAM Brand / The SPAM Story. Website, 2012b. Online verfügbar
auf http://www.spam.com/spam-101/history-of-spam; besucht am 19.04.2012.
Seite 124
Verzeichnisse
IEEE S&P 2011. 32nd IEEE Symposium on Security and Privacy, S&P 2011, 22-25 May 2011, Berkeley, California,
USA, 2011. IEEE Computer Society. ISBN 978-1-4577-0147-4.
Information Sciences Institute, University of Southern California. RFC 791: Internet Protocol, DARPA Internet
Program, Protocol Specification. Website, 1981. Online verfügbar auf http://tools.ietf.org/html/rfc791;
Internet Society, Internet Engineering Task Force (IETF). RFC Editor. Website, 2012. Online verfügbar auf
http://www.rfc-editor.org/; besucht am 26.11.2012.
S. Josefsson. RFC 4648: The Base16, Base32, and Base64 Data Encodings. Website, 2006. Online verfügbar auf
C. Kalt. RFC 2810: Internet Relay Chat: Architecture. Website, 2000a. Online verfügbar auf http://
tools.ietf.org/html/rfc2810; besucht am 28.12.2012.
C. Kalt. RFC 2811: Internet Relay Chat: Channel Management. Website, 2000b. Online verfügbar auf
C. Kalt. RFC 2812: Internet Relay Chat: Client Protocol. Website, 2000c. Online verfügbar auf http:
//tools.ietf.org/html/rfc2812; besucht am 28.12.2012.
C. Kalt. RFC 2813: Internet Relay Chat: Server Protocol. Website, 2000d. Online verfügbar auf http:
S. Kitterman. RFC 6652: Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse
Reporting Format. Website, 2012. Online verfügbar auf http://tools.ietf.org/html/rfc6652; besucht am
02.01.2013.
Peter Kleissner.
Advanced Analysis of Sinowal.
Website, 2009.
Online verfügbar auf http://
web17.webbpro.de/index.php?page=advanced-analysis-of-sinowal; besucht am 07.01.2013.
J. Klensin.
RFC 2821: Simple Mail Transfer Protocol.
Website, 2001.
Online verfügbar auf http:
J. Klensin.
RFC 5321: Simple Mail Transport Protocol.
Website, 2008.
Online verfügbar auf http:
J. Klensin, R. Catoe, and P. Krumviede. RFC 2195: IMAP/POP AUTHorize Extension for Simple Challenge/Response. Website, 1997. Online verfügbar auf http://tools.ietf.org/html/rfc2195; besucht am
27.11.2012.
H. Krawczyk, M. Bellare, and R. Canetti. RFC 2104: HMAC: Keyed-Hashing for Message Authentication.
Christian Kreibich, Chris Kanich, Kirill Levchenko, Brandon Enright, Geoffrey M. Voelker, Vern Paxson, and
Stefan Savage. On the Spam Campaign Trail. In Fabian Monrose, editor, LEET. USENIX Association, 2008.
Kirill Levchenko, Andreas Pitsillidis, Neha Chachra, Brandon Enright, Márk Félegyházi, Chris Grier, Tristan Halvorson, Chris Kanich, Christian Kreibich, He Liu, Damon McCoy, Nicholas Weaver, Vern Paxson,
Geoffrey M. Voelker, and Stefan Savage. Click Trajectories: End-to-End Analysis of the Spam Value Chain. In
IEEE S&P 2011, pages 431–446. ISBN 978-1-4577-0147-4.
J. Levine. RFC 5782: DNS Blacklists and Whitelists. Website, 2010. ISSN 2070-1721. Online verfügbar auf
Literatur
Seite 125
John R. Levine. Three myths about DKIM. Website, 2009. Online verfügbar auf http://jl.ly/Email/
threemyths.html; besucht am 02.01.2013.
Tracey Lien.
Guild Wars 2 phishing attempts continue.
Website, 2012.
Online verfügbar auf http://www.polygon.com/gaming/2012/9/10/3307300/guild-wars-2-phishing-attempts-standat-more-than-11000; besucht am 27.12.2012.
G. Lindberg. RFC 2505: Anti-Spam Recommendations for SMTP MTAs. Website, 1999. Online verfügbar auf
J. Lyon. RFC 4407: Purported Responsible Address in E-Mail Messages. Website, 2006. Online verfügbar auf
J. Lyon and M. Wong. RFC 4406: Sender ID: Authenticating E-Mail. Website, 2006. Online verfügbar auf
P. Mackapetris. RFC 1034: Domain Names - Concepts and Facilities. Website, 1987a. Online verfügbar auf
P. Mackapetris. RFC 1035: Domain Names - Implementation and Specification. Website, 1987b. Online
Brian S. McWilliams. Spam Kings. Elsevier Inc., 2005. ISBN 978-0-596-00732-4.
A. Melnikov. RFC 4314: IMAP4 Access Control List (ACL) Extension. Website, 2005. Online verfügbar auf
Microsoft Corporation. Sender ID Framework Overview - Verification System Aims to Reduce Spam and
Increase Safety Online. Website, 2007. Online verfügbar auf http://www.microsoft.com/mscorp/safety/
technologies/senderid/overview.mspx; besucht am 03.01.2013.
Microsoft Corporation. Sender ID Home Page. Website, 2008. Online verfügbar auf http://
www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx/; besucht am 03.01.2013.
Chuck Miller. The Rustock botnet spams again. Website, 2008. Online verfügbar auf http://
www.scmagazine.com/the-rustock-botnet-spams-again/article/112940/; besucht am 30.12.2012.
J. Myers. RFC 2554: SMTP Service Extension for Authentication. Website, 1999. Online verfügbar auf
J. Myers and M. Rose. RFC 1939: Post Office Protocol - Version 3. Website, 1996. Online verfügbar auf
NDSS 2010. Proceedings of the Network and Distributed System Security Symposium, NDSS 2010, San Diego,
California, USA, 28th February - 3rd March 2010, 2010. The Internet Society.
C. Newman. RFC 2595: Using TLS with IMAP, POP3 and ACAP. Website, 1999. Online verfügbar auf
C. Newman, A. Menon-Sen, A. Melnikov, and N. Williams. RFC 5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms. Website, 2010. Online verfügbar auf
K. Nichols, S. Blake, F. Baker, and D. Black. RFC 2474: Definition of the Differentiated Services Field (DS Field)
in the IPv4 and IPv6 Headers. Website, 1998. Online verfügbar auf http://tools.ietf.org/html/rfc2474;
Seite 126
Verzeichnisse
Alexander Nieschwietz. tagesschau.de: Das Internet wird neu durchnummeriert. Website, 2011. Online
verfügbar auf http://www.tagesschau.de/inland/ipvday100.html; besucht am 20.12.2012.
Oleg Nikolaenko. Mega-D Botmaster to Stand Trial. Website, 2010. Online verfügbar auf http://
garwarner.blogspot.de/2010/12/oleg-nikolaenko-mega-d-botmaster-to.html; besucht am 30.12.2012.
Nucleus Research Incorporated. Spam - the Serial ROI Killer, Mai 2004. http://nucleusresearch.com/
research/notes-and-reports/spam-the-serial-roi-killer/.
Menard Osena. World of Warcraft Scams: Mist of Pandaria, Free Mounts and Phishing Galore. Website,
2012. Online verfügbar auf http://blog.trendmicro.com/trendlabs-security-intelligence/world-ofwarcraft-scams-mist-of-pandaria-free-mounts-and-phishing-galore/; besucht am 27.12.2012.
Christof Paar and Jan Pelzl. Understanding Cryptography - A Textbook for Students and Practitioners. Springer,
2010. ISBN 978-3-642-04100-6.
Andreas Pitsillidis, Kirill Levchenko, Christian Kreibich, Chris Kanich, Geoffrey M. Voelker, Vern Paxson,
Nicholas Weaver, and Stefan Savage. Botnet Judo: Fighting Spam with Itself. In NDSS 2010.
Jonathan B. Postel. RFC 821: Simple Mail Transfer Protocol. Website, 1982. Online verfügbar auf http:
Jonathan B. Postel and J. Reynolds. RFC 854: Telnet Protocol Specification. Website, 1983a. Online verfügbar
Jonathan B. Postel and J. Reynolds. RFC 855: Telnet Option Specifications. Website, 1983b. Online verfügbar
Jonathan B. Postel and J. Reynolds. RFC 959: File Transfer Protocol (FTP). Website, 1985. Online verfügbar
Niels Provos and Thorsten Holz. Virtual Honeypots - From Botnet Tracking to Intrusion Detection. Addison-Wesley,
2008. ISBN 978-0-321-33632-3.
Niels Provos, Panayiotis Mavrommatis, Moheeb Abu Rajab, and Fabian Monrose. All Your iFRAMEs Point
to Us. In Paul C. van Oorschot, editor, USENIX Security Symposium, pages 1–16. USENIX Association, 2008.
ISBN 978-1-931971-60-7.
Zhiyun Qian, Zhuoqing Morley Mao, Yinglian Xie, and Fang Yu. On Network-level Clusters for Spam
Detection. In NDSS 2010.
Anirudh Ramachandran and Nick Feamster. Understanding the Network-Level Behavior of Spammers. In
Luigi Rizzo, Thomas E. Anderson, and Nick McKeown, editors, SIGCOMM, pages 291–302. ACM, 2006. ISBN
1-59593-308-5.
Anirudh Ramachandran, Nick Feamster, and Santosh Vempala. Filtering spam with behavioral blacklisting.
In Peng Ning, Sabrina De Capitani di Vimercati, and Paul F. Syverson, editors, ACM Conference on Computer
and Communications Security, pages 342–351. ACM, 2007. ISBN 978-1-59593-703-2.
D. Reed. RFC 1459: Internet Relay Chat Protocol. Website, 1993. Online verfügbar auf http://tools.ietf.org/
html/rfc1459; besucht am 28.12.2012.
Y. Rekhter and T. Li. RFC 1654: A Border Gateway Protocol 4 (BGP-4). Website, 1994. Online verfügbar auf
Y. Rekhter and T. Li. RFC 1771: A Border Gateway Protocol 4 (BGP-4). Website, 1995. Online verfügbar auf
Literatur
Seite 127
Y. Rekhter, T. Li, and S. Hares. RFC 4271: A Border Gateway Protocol 4 (BGP-4). Website, 2006. Online
Peter W. Resnick. RFC 5322: Internet Message Format. Website, 2008. Online verfügbar auf http://
tools.ietf.org/html/rfc5322; besucht am 18.09.2012.
J. K. Reynolds. RFC 918: Post Office Protocol. Website, 1984. Online verfügbar auf http://tools.ietf.org/
html/rfc918; besucht am 23.11.2012.
J. Rice. RFC 1203: Interactive Mail Access Protocol - Version 3. Website, 1991. Online verfügbar auf
R. Rivest. RFC 1321: The MD5 Message-Digest Algorithm. Website, 1992. Online verfügbar auf http:
M. Sahami, S. Dumais, D. Heckerman, and E. Horvitz. A Bayesian Approach to Filtering Junk E-Mail. In
Proceedings of the AAAI Workshop on Learning for Text Categorization, 1998.
Thomas Schickinger and Angelika Steger. Diskrete Strukturen Band 2 - Wahrscheinlichkeitstheorie und Statistik.
Springer, 2002. ISBN 3-540-67599-X.
Marc Schober. Spam - eine praktische Analyse, Juli 2009. Studienarbeit am Lehrstuhl für Netz- und
Datensicherheit / Horst Görtz Institut für IT-Sicherheit, Fakultät für Elektrotechnik und Informationstechnik,
Ruhr-Universität Bochum.
Guido Schryen. Anti-Spam Measures - Analysis and Design. Springer, 2007. ISBN 978-3-540-71748-5.
R. Siemborski and A. Melnikov. RFC 4954: SMTP Service Extension for Authentication. Website, 2007. Online
Sushant Sinha, Michael Bailey, and Farnam Jahanian. Improving Spam Blacklisting Through Dynamic
Thresholding and Speculative Aggregation. In NDSS 2010.
Stu Sjouwerman and Jeffrey Posluns. Inside the SPAM Cartel. Elsevier Inc., 2004. ISBN 978-1-932266-86-3.
T. Socolofsky and C. Kale. RFC 1180: A TCP/IP Tutorial. Website, 1991. Online verfügbar auf http:
Henry Stern. A Survey of Modern Spam Tools. In CEAS, 2008.
Brett Stone-Gross, Marco Cova, Lorenzo Cavallaro, Bob Gilbert, Martin Szydlowski, Richard A. Kemmerer,
Christopher Kruegel, and Giovanni Vigna. Your Botnet is My Botnet: Analysis of a Botnet Takeover. In Ehab
Al-Shaer, Somesh Jha, and Angelos D. Keromytis, editors, ACM Conference on Computer and Communications
Security, pages 635–647. ACM, 2009. ISBN 978-1-60558-894-0.
Gianluca Stringhini, Thorsten Holz, Brett Stone-Gross, Christopher Kruegel, and Giovanni Vigna. BOTMAGNIFIER: Locating Spambots on the Internet. In USENIX Security Symposium. USENIX Association,
2011.
Symantec Corporation. Symantec Announces MessageLabs Intelligence 2010 Annual Security Report.
Website, 2010. Online verfügbar auf http://www.symantec.com/about/news/release/article.jsp?prid=
20101207_01; besucht am 03.01.2013.
Symantec Corporation.
Symantec Intelligence Report: November 2012, November 2012.
http:
//www.symantec.com/content/en/us/enterprise/other_resources/b-intelligence_report_11_2012.enus.pdf.
Seite 128
Verzeichnisse
The Spamhaus Project. Register of Known Spam Operations (ROKSO. Website, 2012a. Online verfügbar auf
http://www.spamhaus.org/rokso/; besucht am 05.12.2012.
The Spamhaus Project.
The Definition of Spam.
Website, 2012b.
www.spamhaus.org/consumer/definition/; besucht am 11.09.2012.
Online verfügbar auf http://
Kurt Thomas, Chris Grier, Justin Ma, Vern Paxson, and Dawn Song. Design and Evaluation of a Real-Time
URL Spam Filtering Service. In IEEE S&P 2011, pages 447–462. ISBN 978-1-4577-0147-4.
Jochen Topf, Matthias Etrich, Joerg Heidrich, Leslie Romeo, Marco Thorbrügge, and Bert Ungerer. Antispam - Strategien, Unerwünschte E-Mails erkennen und abwehren, März 2005. https://www.bsi.bund.de/
SharedDocs/Downloads/DE/BSI/Publikationen/Studien/Antispam/antispam_pdf.pdf.
Harry Waldron. Pushdo Botnet - New DDOS attacks on major web sites. Website, 2010. Online
verfügbar auf http://msmvps.com/blogs/harrywaldron/archive/2010/02/02/pushdo-botnet-new-ddosattacks-on-major-web-sites.aspx; besucht am 30.12.2012.
Andreas Wilkens. Microsoft stellt Technik für die Spamkennzeichnung zur Nutzung frei. Website, 2006.
Online verfügbar auf http://www.heise.de/newsticker/meldung/Microsoft-stellt-Technik-fuer-dieSpamkennzeichnung-zur-Nutzung-frei-175513.html; besucht am 03.01.2013.
M. Wong and W. Schlitt. RFC 4408: Sender Policy Framework (SPF) for Authorizing Use of Domains in
E-Mail, Version 1. Website, 2006. Online verfügbar auf http://tools.ietf.org/html/rfc4408; besucht am
02.01.2013.
K. Zeilenga. RFC 4616: The PLAIN Simple Authentication and Security Layer (SASL) Mechanism. Website,
Kim Zetter. How a Google Headhunter’s E-Mail Unraveled a Massive Net Security Hole. Website, 2012. Online
verfügbar auf http://www.wired.com/threatlevel/2012/10/dkim-vulnerability-widespread; besucht am
02.01.2013.
Strahinja Zuljevic. World of Warcraft: Phishing-Angriff auf Online-Spieler. Website, 2009. Online verfügbar auf http://www.netzwelt.de/news/80897-world-of-warcraft-phishing-angriff-onlinespieler.html; besucht am 27.12.2012.

Spam [Spam] - Lehrstuhl für Netz- und Datensicherheit

Transcription

Similar documents

Spam, Viren und Phishing - e

Systemnahe Programmierung [Sysprog] - IT

Handbuch zur Einrichtung und Konfiguration

Lernen lernen im DaZ-Unterricht

Analysing a single statistical variable

HLZ 12/2013 - GEW Hessen

- Heftarchiv - Internet World Business

Cyber-Security aus Sicht der Sicherheitspolitik

pdf-Datei - TU Ilmenau

E-Mailversand beim BVB

Adrian Schneider: Symmetrische Kryptographie