Modul 42 Spam

Studienbrief 1: Grundlagen Studienbrief 2: Spam-Techniken Studienbrief 3: Anti-Spam Techniken Studienbrief 4: Rechtslage

Autoren: Christopher Wolf Sebastian Uellenbeck

1. Auflage

1. Auflage (17. Juli 2013)

Didaktische und redaktionelle Bearbeitung sowie Produktion: Romy Rahnfeld (M. A. Germanistik Sprachwissenschaft/Erziehungswis- senschaft)

Das Werk einschließlich seiner Teile ist urheberrechtlich geschützt. Jede Ver- wendung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung der Verfasser unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverﬁlmungen und die Einspe- icherung und Verarbeitung in elektronischen Systemen. Inhaltsverzeichnis Seite3

Inhaltsverzeichnis

Einleitung zu den Studienbriefen6 I. Abkürzungen der Randsymbole und Farbkodierungen...... 6 II. Zu den Autoren...... 7 III. Modullehrziele...... 8

Studienbrief 1 Grundlagen9 1.1 Lernziele...... 9 1.2 Einleitung...... 9 1.2.1 E-Mail...... 9 1.2.2 Spam...... 11 1.2.3 RFC (Request for Comments)...... 15 1.2.4 Gliederung...... 16 1.2.5 Kontrollaufgaben...... 16 1.3 Internet...... 17 1.4 E-Mail-Infrastruktur...... 17 1.4.1 Kommunikationsmodell...... 18 1.4.2 Aufbau von E-Mails...... 19 1.4.3 SMTP (Simple Mail Transfer Protocol)...... 20 1.4.4 POP3 (Post Oﬃce Protocol Version 3)...... 26 1.4.5 IMAP (Internet Message Access Protocol)...... 30 1.4.6 DNS (Domain Name System)...... 33 1.4.7 Kontrollaufgaben...... 34 1.5 Anreize und Motivation der Spammer...... 36 1.6 Wirtschaftliche Aspekte...... 36 1.6.1 Durch Spam entstehende Kosten...... 37 1.6.2 Erlös für Spam Verursacher...... 38 1.6.3 Kontrollaufgaben...... 38 1.7 Fallstudie „Click Trajectories: End-to-End Analysis of the Spam Value Chain“...... 39 1.8 Phishing...... 40 1.9 Zusammenfassung...... 41 1.10 Lösungen zu den Kontrollaufgaben...... 41 1.11 Übungen...... 44

Studienbrief 2 Spam-Techniken 48 2.1 Lernziele...... 48 2.2 Einleitung...... 48 2.3 Spammer...... 48 2.3.1 Spammer-Netzwerke...... 49 2.3.2 Adress-Harvesting...... 50 2.3.3 Anti-Harvesting-Methoden...... 52 2.3.4 Kontrollaufgaben...... 57 2.4 Offene Mail-Relays...... 58 2.5 Offene Proxys...... 59 2.6 Mail-Formulare...... 60 2.7 Webmail...... 62 2.8 IP Prefix Hijacking...... 63 2.9 Malware / Botnetze...... 64 2.10 Zusammenfassung...... 68 2.11 Lösungen zu den Kontrollaufgaben...... 69 2.12 Übungen...... 73 Seite4 Inhaltsverzeichnis

Studienbrief 3 Anti-Spam Techniken 75 3.1 Lernziele...... 75 3.2 Einleitung...... 75 3.3 Mailﬁlter...... 75 3.4 IP-Sperren...... 78 3.4.1 Blacklisting...... 78 3.4.2 Whitelisting...... 81 3.4.3 Graylisting...... 82 3.4.4 Kontrollaufgaben...... 83 3.5 Reputationsverfahren...... 84 3.6 Challenge-Response-Verfahren...... 87 3.7 Erweiterungen des E-Mail-Verfahren...... 88 3.7.1 DomainKeys / DKIM...... 88 3.7.2 SPF (Sender Policy Framework)...... 92 3.7.3 Sender ID...... 95 3.7.4 Hashcash...... 96 3.7.5 Receiver-Driven SMTP...... 97 3.7.6 Kontrollaufgaben...... 98 3.8 Echtzeit URL Filterung...... 99 3.9 Netzwerk-basiertes Clustern...... 100 3.10 Erkennung von Botnetzen...... 100 3.11 Botnetz Übernahme...... 103 3.12 Botnet Judo: Automatische Generierung von Spam Signaturen... 105 3.13 SpamAssassin...... 108 3.14 Zusammenfassung...... 109 3.15 Lösungen zu den Kontrollaufgaben...... 109 3.16 Übungen...... 114

Studienbrief 4 Rechtslage 118 4.1 Lernziele...... 118 4.2 Einleitung...... 118 4.2.1 Ursachen für Spam...... 118 4.2.2 Verursachte Kosten und Schäden durch Spam...... 119 4.2.3 Vorgehen der Spammer...... 121 4.2.4 Kontrollaufgaben...... 123 4.3 Datenschutzrecht...... 123 4.4 Anti-Spam Gesetze...... 124 4.4.1 Deutschland...... 125 4.4.2 USA...... 126 4.4.3 Kontrollaufgaben...... 126 4.5 Strafrecht...... 127 4.5.1 Post- und Fernmeldegeheimnis...... 127 4.5.2 Datenunterdrückung und Ausspähen von Daten...... 129 4.5.3 Fälschung der Absenderadresse...... 129 4.5.4 Kontrollaufgaben...... 130 4.6 Zivilrecht...... 131 4.6.1 Schadensersatzpﬂicht...... 131 4.6.2 Blacklists...... 131 4.6.3 Malware vs. Spam...... 132 4.6.4 Filterproblematiken...... 133 4.6.5 Anforderungen an ein Spam-Schutzsystem...... 135 4.6.6 Kontrollaufgaben...... 136 4.7 Wettbewerbsrecht...... 136 4.8 Empfehlungen zur Verhinderung von Spam...... 140 4.9 Zusammenfassung...... 142 4.10 Lösungen zu den Kontrollaufgaben...... 143 4.11 Übungen...... 144 Inhaltsverzeichnis Seite5

Verzeichnisse 151 I. Abbildungen...... 151 II. Deﬁnitionen...... 151 III. Exkurse...... 151 IV. Kontrollaufgaben...... 152 V. Literatur...... 153 VI. Tabellen...... 163 Seite6 Einleitung zu den Studienbriefen

Einleitung zu den Studienbriefen

I. Abkürzungen der Randsymbole und Farbkodierungen

Axiom A

Beispiel B

Deﬁnition D

Exkurs E

Kontrollaufgabe K

Merksatz M

Quelle Q

Satz S

Übung Ü Zu den Autoren Seite7

II. Zu den Autoren

Dr. Christopher Wolf studierte bis 2002 Informatik an der Universität Ulm und wurde 2005 an der K.U. Leu- ven 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 Authentiﬁkationsmöglichkeiten auf Smartphones. Seite8 Einleitung zu den Studienbriefen

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 Tech- niken zu den heute angewendeten ausgeklügelten Techniken. Im dritten Teil werden dann Gegenmaßnahmen betrachtet und auch aktuelle Forschungsprojekte angesprochen. Der vierte Teil betrachtet dann die rechtlichen Grundlagen und beschreibt welche Möglichkeiten ein Empfänger von Spam hat um gegen die uner- wünschten Nachrichten juristisch vorzugehen. Studienbrief 1 Grundlagen Seite9

Studienbrief 1 Grundlagen

1.1 Lernziele

Sie wissen wie E-Mails speziﬁziert sind und können die Unterschiede zu Spam klar abgrenzen. Weiterhin können sie erklären, wie Spam entsteht und kennen die wirtschaftlichen Aspekte, die den Versand von Spam interessant für Krim- inelle machen. Dazu können Sie die Grundlagen der E-Mail-Struktur und deren Protokolle erläutern.

1.2 Einleitung

Elektronische Post (kurz E-Mail) ist heutzutage ein beliebtes Kommunikations- medium. Die E-Mail vereinigt die Vorteile der synchronen und asynchronen Kom- munikation, 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 gelesen werden kann, 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-Mail 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 zu beeinﬂusst 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 wurde 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 verschaﬀen, als auch einzelne besonders interessante Aspekte genau zu betrachten. Dabei werden zum einen Grundlagen vermittelt, die den Leser dazu schulen Zusammenhänge und Techniken zu verstehen. Zum anderen werden aber auch aktuell Forschungsprojekte aufgegriﬀen und besprochen, die einen Einblick in ausgeklügelte Methoden und Ansätze vermitteln.

1.2.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 Seite 10 Studienbrief 1 Grundlagen

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.4 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.

Deﬁnition 1.1: E-Mail D 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 Begriﬀ RFC wird in Abschnitt 1.2.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 Pa- pier benötigt wird und der Transport per LKW, Bahn oder Flugzeug nicht erforderlich ist. • E-Mail-Adressen bieten einen 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. Hi- erdurch 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 Inter- net, die eine E-Mail-Adresse ohne vorherige Anmeldung anbieten, sogenannte Einmal-E-Mail-Adressen (One Time Email) oder auch Wegwerf-E-Mail- Adressen (Disposable Email Address). Hierdurch wird es möglich, für den Empfänger vollständig anonym zu wirken. Löschen die Anbieter ihre Log- Dateien regelmäßig, so ist eine vollkommene Anonymität möglich. • E-Mails können weiterhin problemlos an mehrere Empfänger versendet werden. • Sie sind mithilfe von Software einfach nach bestimmten Suchbegriffen oder Kriterien hin durchsuchbar. Daher können sehr schnell benötigte Informa- tionen gefunden werden. • Es ist außerdem problemlos möglich, E-Mails mit Anhängen zu versehen, die dann mit übertragen werden. • Weiterhin ist die Beantwortung eine E-Mail deutlich einfacher als bei normaler Post. Hier liegen die gleiche Vorteile wie beim Verfassen von E-Mails, wie bspw. Zeit und Kosten. 1.2 Einleitung Seite 11

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.2.2 Spam

Der Begriff Spam bezeichnet in der Regel unerwünschte elektronische Nachricht- en, die auf der einen Seite Werbung verbreiten sollen. Auf der anderen Seite wird Spam allerdings auch zum so genannten Phishing verwendet. Dabei werden E-Mails verschickt, die suggerieren, dass sie von einer offiziellen Stelle, oft einer Bank, verschickt wurden und den Kunden dazu auffordern bspw. seine Be- nutzerdaten 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 und im besten Fall auch an PIN und TAN für die Konten der Empfänger. Phishing wird weiter in Abschnitt 1.8 ab Seite 40 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 Project (The Spamhaus Project[2012b]) zu finden:

Deﬁnition 1.2: Spam Eine Nachricht wird genau dann als Spam bezeichnet, wenn sie sowohl uner- D wünscht (unsolicited) ist als auch in großen Mengen (bulk) verbreitet wird.

• 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 Unsolicited Bulk Massenmail, bezeichnet. Als Abgrenzung dazu bezeichnet der Begriﬀ HAM er- Email wünschte bzw. reguläre E-Mail Nachrichten HAM.

Begriﬀsherkunft

Ursprünglich wurde das von der amerikanischen Firma Hormel Foods Corpora- tion ab dem Jahr 1937 hergestellte Dosenﬂeisch als SPAM® (SPiced hAM, vgl. Ab- bildung 1.1) bezeichnet, nachdem der Name bei einem Wettbewerb durch einen der Teilnehme vorgeschlagen wurde.

Abb. 1.1: SPAM (Hormel Foods Corpo- ration[2012a]). Seite 12 Studienbrief 1 Grundlagen

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 Comedy-Show „Monty Python’s Flying Circus“ als Anlass für einen Sketch genommen, 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 Begriﬀ SPAM® ein registriertes Markenzeichen der Firma Hormel Foods Corporation ist, wohingegen unerwünschte Werbung als Spam bezeichnet wird (vgl. Schreib- weise).

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.

Exkurs 1.1: Instant Messenger Spam E 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 Protokollen, 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ün- schten 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 zu schicken.

Exkurs 1.2: Mobile Phone Spam E 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 Gegen- maßnahmen. Alle deutschen Mobilfunkanbieter stellen E-Mail-Adressen zur Verfügung, an dich sich Nutzer wenden können, sofern sie durch Spam auf ihrem Mobiltelefon belästigt werden. 1.2 Einleitung Seite 13

Exkurs 1.3: Foren Spam E Internet Foren werden generell zum asynchronen Austausch von Informatio- nen genutzt. Dabei kann eine beliebig große Anzahl an Teilnehmern Beiträge zu einem Thema veröffentlichen, die dann linear innerhalb einer Internet- seite 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 An- meldung an ein Forum automatisieren, um zu beliebigen Beiträgen eigene Nachrichten zu erstellen, die zwar nichts mit dem Thema das Beitrag zu tun haben, als Inhalt aber Werbung in Form von Links zu anderen Internet- seiten 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 so genannte 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 E Viele gegenwärtige Spiele bieten die Möglichkeit, dass Teilnehmer innerhalb der Spielewelt untereinander kommunizieren. Oft gehört diese Art der Kom- munikation 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 ﬁndet sich häuﬁg innerhalb von MMORPGs (Massively Multi- player Online Role-Playing Game).

Exkurs 1.5: Spamdexing E Eine weitere Form des Spam findet sich in Suchmaschinen, die das WWW mit Hilfe von Suchbegriffen indizieren. Die als Spamdexing bekannte Tech- nik macht sich die Eigenschaften der Algorithmen der Suchmaschinenbe- treiber zu Nutze, 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 E 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 Infor- mationen missbraucht werden. Seite 14 Studienbrief 1 Grundlagen

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 Ver- breitung 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 ﬁnden 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 Treﬀen für eine Suche nach wissenschaftlichen Artikeln Werbung anzuzeigen.

Ursprung von Spam

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 Open RelayNutzer authentifiziert hatte. Dieses als Open Relay bekannte Verhalten macht- en sich schon frühzeitig Spammer zu Nutze, um unbemerkt und anonym Spam zu verbreiten. Die 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.

Weiterhin existieren in den Anfangszeiten des Internets sehr viele Server, die beliebige Informationen auf freigegebenen Ports weiterleiteten und dabei die Quell- Open Proxy Adresse 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 An- bieter geben darüber hinaus auch weiteren Nutzern die Möglichkeit ein E-Mail Konto zu eröﬀnen, da sie sich bspw. daraus einen höheren Bekanntheitsgrad er- hoﬀen. 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 uner- wünschten Massenmails zu versenden. Dies kann jedoch wiederum durch den 1.2 Einleitung Seite 15

Anbieter erkannt werden, sobald dieser zu Beispiel die Anzahl der ausgehenden E-Mails überprüft und ab einen bestimmten Schwellwert das Konto sperrt. Daher 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ösar- Malware tige 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 einen Computersystem befällt, kann nicht nur lokale Informationen auf dem System auslesen und ändern, sondern auch Netzwerkverbindungen aufnehmen. Mit Hilfe 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 zusammen geschlossen so ergibt sich ein Botnetz aus vielen tausenden Computer- Botnetz,das systemen bestehen kann und durch den Botmaster gesteuert wird. Eine Mögliche Schadfunktionalität kann dabei der Versand von Spam sein, wobei dem vorausge- hend bereits über eine andere Schadfunktion das Adressbuch des Nutzers des Computersystems ausgelesen worden sein kann, damit die Spam Nachrichten an existierende E-Mail-Konten versendet werden. Heutzutage sind Botnetze aufgrund ihrer Flexibilität und sehr schlechten Blockierbarkeit die häufigste Ursache von Spam.

Studienbrief2 ab Seite 48 geht näher auf den Ursprung vom Spam ein.

Abb. 1.2: Der An- teil von Spam am gesamten E- Mailaufkommen nach Symantec Corpo- ration[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.11 ab Seite 103).

1.2.3 RFC (Request for Comments)

Requests for Comments (dt. Bitte um Kommentare) sind Dokumente, die technische Standards im Internet dokumentieren und speziﬁzieren (vgl. Internet So- ciety, Internet Engineering Task Force (IETF)[2012]). Im ursprünglichen Sinne waren die Dokumente dazu gedacht, von anderen Entwicklern Kommentare zu Seite 16 Studienbrief 1 Grundlagen

Ideen zu erhalten, um einen Standard zu erstellen. Innerhalb der darauf folgenden 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 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 umdeﬁnieren, womit die alte RFC obsolet wird. RFCs werden fort- laufend 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.2.4 Gliederung

Das gesamte Modul ist in vier Studienbriefe gegliedert. In diesem ersten Studi- enbrief (1) werden die Grundlagen zur Analyse von Spam betrachtet. Dazu wird zuerst besprochen, was Spam ist und wo er entsteht. Daraufhin wird die E-Mail- Infrastruktur 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 Jahrzehn- ten 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 48 mit Spam-Techniken. Hier wird beschrieben, wie Spam anfangs verbreitet wurde, welche Techniken die an- fänglichen Versuche ablösten und was aktuell für das Spam-Aufkommen verantwortlich ist.

Im dritten Studienbrief werden dann ab Seite 75 Techniken behandelt, die dazu gedacht sind, das Spam-Aufkommen einzudämmen. Es werden Methoden besprochen, die sich aktuell im Einsatz beﬁnden, aber auch zukunftsweisende Forschungsarbeiten vorgestellt, die auf den weltweit wichtigsten Konferenzen von Gutachten als zielführend betrachtet werden.

Der viert Studienbrief beschäftigt sich ab Seite 118 letztendlich mit den rechtlichen Aspekten von Spam. Hier wird untersucht, welche gesetzlichen Grundlagen in verschiedenen Ländern existieren. Unterteilt wird in diesem Studienbrief nach Straf- und Zivilrecht. Nachfolgend wird auch auf das Wettbewerbsrecht eingegangen, bevor Empfehlungen zur Verhinderung vom Spam behandelt werden.

1.2.5 Kontrollaufgaben

In diesem Abschnitt befinden sich verschiedene Kontrollaufgabe, die die Inhalt der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffs beitragen sollen. 1.3 Internet Seite 17

Kontrollaufgabe 1.1: Vorteile von E-Mails K Geben Sie die drei Hauptvorteile von E-Mails im Vergleich zur gewöhnlichen Post an.

Kontrollaufgabe 1.2: Umweltfreundlichkeit von E-Mails K 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 K Nennen Sie vier Medien (außer E-Mail) in denen Spam verschickt wird.

Kontrollaufgabe 1.4: Der Ursprung von Spam K Beschreiben Sie zwei mögliche Entstehungsarten von Spam und nennen Sie Maßnahmen, mit denen Spam aus diesen Quellen unterbunden werden kann.

Die Lösungen zu den Kontrollaufgaben sind in Abschnitt 1.10 ab Seite 41 zu ﬁnd- en.

1.3 Internet

Das Internet ist ein Netz von Computersystemen, das über die ganze Welt verteilt ist und somit einen weltweiten Datenaustausch ermöglichen. 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 bereit gestellt 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. Mit Hilfe dieses Dienstes wird versucht, die positiven Eigenschaften von Briefen zu übernehmen und gleichzeitig die negativen Eigenschaften zu beseitigen.

1.4 E-Mail-Infrastruktur

E-Mails nutzen zwar das Internet, um vom Sender zum Empfänger zu geladen, jedoch mussten dazu Designentscheidungen getroﬀen sowie Protokolle entwickelt werden, die sich um das Behandeln der Daten kümmern. Daher wird im Fol- genden beschrieben, welche Infrastruktur für den Transport von E-Mails im Inter- net notwendig ist, wie E-Mails aufgebaut sind und wie die benötigten Protokolle dafür deﬁniert sind. Seite 18 Studienbrief 1 Grundlagen

1.4.1 Kommunikationsmodell

Der Zweck eine E-Mail besteht darin, Informationen von einem Sender zu einem Empfänger zu schicken. Dazu wäre es theoretisch ausreichend, wenn es eine Di- rektverbindung zwischen Sender und Empfänger geben würde und der Sender die Daten direkt zum Empfänger schickt. Dieses direkte Kommunikationsmod- ell wird als Peer-to-Peer-ModellPeer-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ön- nen, was nur 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 Verwen- dung des Client-Server-ModellsClient-Server-Modell . 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-Server- Modell, 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 Modell 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 Oﬃce Protocol Version 3 (POP3) sowie das Domain Name System (DNS) im späteren Verlauf dieses Studi- enbrief genauer vorgestellt werden.

Abb. 1.3: UML Se- MUA (A) SMTP Server (A) NS Server (B) POP3/SMTP Server (B) MUA (B) quenzdiagramm einer beispielhaften E- E-Mail Versand an eigenen Server. Mail Sitzung, bei der SMTP Nutzer A mit seinem DNS Anfrage nach Adresse des Mail-User-Agent Mail-Servers von B. (MUA) eine E-Mail an DNS Nutzer B schickt. An DNS Antwort mit Adresse des den Pfeilen stehen die Mail-Servers von B. jeweils verwendeten DNS Protokolle. 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.4 E-Mail-Infrastruktur Seite 19

1.4.2 Aufbau von E-Mails

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 In- halt 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] der jedoch durch weitere RFCs bzgl. Internation- RFC 5322)speziﬁziert, alisierung erweitert wurde. Ein weiterer wichtiger Punkt zum generellen Aufbau von E-Mail 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 Hilfs- US-ASCII mittel 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 werden, bei der der Anhang vom Binärformat in ein kompatibles Format vor der Übertra- gung transformiert wird.

Exkurs 1.9: US-ASCII E ASCII steht für American Standard Code for Information Interchange und ist eine Zeichenkodierung, die 33 nicht druchbare sowie 95 druckbare Ze- ichen einem Bitmuster zuweist. Als Zeichenvorrat dient grundsätzlich das Alphabet einer Schreibmaschine für die englische Sprache sowie einige Pro- tokollzeichen bspw. zum Anzeigen des Übertragungsendes. Dabei steht des A an Position 65 und wird somit als Binärstring 01000001 übertragen.

Da nur 128 Zeichen deﬁniert sind, ein Byte aber 256 mögliche Repräsenta- 1 tionen hat, bleibt 8 = 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 Zeilenum- bruch 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 Header Felder. 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änger eine 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 Header Zeilen zu erlauben, wird die Regel eingeführt, dass für jedes syntaktisch korrekte Leerzeichen innerhalb des Inhalts eines Headers, anstelle dessen auch ein Zeilenumbruch vor dem Leerzeichen eingefügt werden kann. Mögliche Head- er Felder sind from, sender, to sowie subject. Seite 20 Studienbrief 1 Grundlagen

Body

Die RFC 5322 deﬁniert 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 dürfen nicht eine Länge von 998 Zeichen und sollten nicht eine Länge von 78 Zeichen überschreiten.

Beispiel 1.1: Eine einfache E-Mail B From: [email protected] To: [email protected] Subject: Beispiel E-Mail Date: Fri, 28 Nov 1997 09:54:05 +0100 Message-ID: <[email protected]>

Das ist eine Beispiel E-Mail.

Zu beachten sind insbesondere die beiden Leerzeilen. Die erste Leerzeile trennt den Header von Body. Ohne eine solche Leerzeile enthält eine E-Mail keine Body sondern nur einen Header. Die zweite Leerzeile deﬁniert das Ende der E-Mail und ist somit auch syntaktisch von essentieller Wichtigkeit.

Im Folgenden werden verschiedene Protokolle beschrieben, die für den Transfer von E-Mails von Bedeutung sind.

1.4.3 SMTP (Simple Mail Transfer Protocol)

RFC 821SMTP 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]RFC5321 ) spezifiziert sind. Das Protokoll hat grundsätzlich zwei Funktio- nen. 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 Server zu ermöglichen. Dies ist bspw. dann notwendig, wenn Server A von einen Client eine E-Mail erhalten hat, das Konto des Empfängers sich allerdings nicht auf dem selben 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 Zeichenkodieren (vgl. Exkurs 1.9) auf und ist somit von Menschen lesbar und auch interpretierbar. Daraus resul- RFC 854 tierend 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 werdenRFC855 . Abbildung 1.4 auf Seite 21 stellt eine SMTP Sitzung beispielhaft dar. 1.4 E-Mail-Infrastruktur Seite 21

Client Server Abb. 1.4: UML Se- quenzdiagramm einer SMTP Sitzung. Wartet auf Verbindungsauf --Verbindungsaufbau

220 service ready

HELO clientname.example.net

250 ok

MAIL FROM:

250 ok

RCPT TO:

250 ok

DATA

354 start mail input

From:

To:

Subject: Beispiel E-Mail

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 Seite 22 Studienbrief 1 Grundlagen

SMTP deﬁniert für die Kommunikation mehrere Status-Codes, die auf den Status- RFC 959 Codes des File Transfer Protocols (FTP) (vgl. Postel and Reynolds[1985] ) basieren, allerdings nicht vollständig identisch sind. Dabei sind Status-Codes immer dreis- tellig und sind als Rückgabe des Server an den Client konzipiert, damit dieser entweder auf Fehler reagieren kann, oder sich vergewissern kann, dass ein Befehl ordnungsgemäß ausgeführt wurde.

Im folgenden Exkurs 1.10 werden die SMTP Status Codes detaillierter beschrieben.

Exkurs 1.10: SMTP Status-Codes E 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 Ziﬀern 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 ausge- fü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 über- mittelt 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 Stan- dard entspricht.

Die zweite Ziﬀer 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 speziﬁziert werden konnten.

Im folgenden Beispiel werden einige mögliche Rückgabewerte angeführt. 1.4 E-Mail-Infrastruktur Seite 23

Beispiel 1.2: SMTP Status-Codes B 220 mail.example.com Dienst verfügbar.

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 Authentiﬁzierung von Nutzern. Es vertraut darauf, dass es nur von ehrlichen Nutzern verwendet wird, die ihre echten Daten angeben.

Es gibt jedoch verschiedene Erweiterung für SMTP, um das Protokoll gegen verschiedene Arten von Angriﬀen abzusichern. Um eine Nutzerauthentiﬁzierung zu erreichen, wurden drei verschiedene Ansätze verfolgt. Im Einzelnen sind dies SMTPS, SMTP-After-POP sowie SMTP-Auth.

SMTPS ist eine Erweiterung, die in RFC 2487 (vgl. Hoﬀman[1999] RFC 2487)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 Nutzer- authentiﬁzierung verwendet, um nach der erfolgreichen Authentiﬁzierung auch E-Mails versenden zu dürfen.

Aufgrund einer relativ aufwendigen Implementierung wird heutzutage allerdings oftmals eher SMTP-Auth verwendet, das erstmals in RFC 2554 (vgl. My- ers[1999]) definiert wurde. RFC 4954 ist eine Überarbeitung davon und gilt als RFC 2554 vorgeschlagener Standard (vgl. Siemborski and Melnikov[2007] RFC 4954).SMTP-Auth beschreibt fünf verschiedene Möglichkeiten zur Authentifizierung. Zum einen wird die PLAIN Authentifizierung vorgeschlagen, die als RFC 4616 (vgl. Zeilen- ga[2006] ) die RFC 2595 (vgl. Newman[1999]) erweitert. Bei dieser Möglichkeit RFC 4616 der Authentifizierung werden Benutzername und Passwort zwar nicht im Klar- text (engl. plain) übertragen, da sie Base64-kodiert (vgl. Exkurs 1.11) werden, jedoch ist eine Base64-Kodierung keine Verschlüsselung, da diese Funktion ohne Passwort auskommt und invertierbar ist (vgl. Merksatz 1.1). Seite 24 Studienbrief 1 Grundlagen

Exkurs 1.11: Base64 Kodierung E Die Base64 Kodierung wird neben der Base16 und Base32 Kodierung in der RFC 4648 (vgl. Josefsson[2006]RFC4648 ) 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 Zuord- nung zwischen dem Wert W , also der dezimalen Darstellung einer 6-bit lan- gen Zeichenkette und dem dafür zu verwendenden Code C:

WCWCWCWC 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w 15 P 32 g 49 x 16 Q 33 h 50 y (pad) =

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 der letzte umzuwandelnde Gruppe 2 Byte, so wird ein padding Zeichen angefügt.

Merksatz 1.1: Base64 Kodierung M Es ist zu beachten, dass die Base64 Kodierung keine Verschlüsselung darstellt, da es ohne weitere Informationen möglich ist, aus einer Base64- kodierten Zeichenkette den ursprünglichen Text zu berechnen.

Das folgende Beispiel 1.3 zeigt exemplarisch die Verwendung der Kodierung. 1.4 E-Mail-Infrastruktur Seite 25

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 Schreib- weise 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.

Als drittes Verfahren gilt das in RFC 2195 (vgl. Klensin et al.[1997] CRAM- RFC 2195)als MD5 vorgestellte Verfahren. CRAM-MD5 steht für Challenge-Response Authenti- cation Mechanism, Message Digest 5 und ist demnach ein Authentiﬁzierungsver- fahren, das nach dem Challenge-Response Prinzip (vgl. auch Abschnitt 3.6 ab Seite 87) funktioniert und auf dem MD5 Algorithmus (vgl. Rivest[1992] RFC 1321basiert. Grundsätzlich verwendet CRAM-MD5 in drei Schritten:

1. Der Server sendet eine Zeichenkette (Challenge) an den Client. Diese Ze- ichenkette muss einen Zeitstempel und den vollständigen Hostnamen des Servers enthalten. Außerdem sollen noch willkürliche Ziﬀern 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. RFC 2104

c) Die verschlüsselte Zeichenkette wird in eine hexadezimale Zeichen- kette überführt.

d) Der Nutzername sowie ein Leerzeichen werden der hexadezimalen Ze- ichenkette vorangestellt.

e) Die resultierende Zeichenkette wird Base64 kodiert und an den Server verschickt. Seite 26 Studienbrief 1 Grundlagen

3. Der Server verwendet die selbe Methode wie der Client, und vergleicht sein Ergebnis mit der vom Client übertragenen Zeichenkette. Falls beide Zeichen- ketten gleich sind, dann war die Authentiﬁzierung erfolgreich.

Durch dieses Vorgehen entstehen drei verschiedene Sicherheitsaspekte:

1.Authentiﬁzierung Es ist für dritte nicht möglich, den generierten Hash zu duplizieren ohne das verwendete Passwort zu kennen. Dadurch wird die Authentiﬁzierung ermöglicht.

2.Replay-Angriﬀ Ein Replay-Angriﬀ 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.

3.Verschwiegenheit 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.

RFC 5802 Die beiden letzten Verfahren sind das in RFC 5802 (vgl. Newman et al.[2010] ) spez- iﬁziert SCRAM-SHA1, sowie NTLM. Auf beide Verfahren wird aufgrund derer Komplexität nicht eingegangen.

Nachdem nun die Eigenschaften von SMTP ausgiebig beschrieben wurden, folgt im nächsten Abschnitt das Post Oﬃce Protokoll in Version 3.

1.4.4 POP3 (Post Oﬃce 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, der das Pro- RFC 918 tokoll spezifiziert ist RFC 918 aus dem Jahr 1984 (Reynolds[1984] ). Wie die Ein- leitung der RFC bereits schreibt, war das Protokoll dazu gedacht, mit Hilfe eines Arbeitsplatz Computers (Workstation) dem Nutzer Zugriff auf E-Mail zu geben, die auf einem E-Mail Server liegen. Zwar wäre es für eine Nutzer auch möglich, seinen eigenen Computer mit Hilfe 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-Mail 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 DNS Domäne des Nutzers angepasst werden und auch im Domain Name System (DNS, RFC 1034 vgl. Mackapetris[1987a,b], Elz and Bush[1997], Gulbrandsen et al.[2000] , siehe auch Abschnitt 1.4.6 ab Seite 33) 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.

Abbildung 1.6 auf Seite 28 zeigt eine POP Sitzung. Zu erkennen ist die Authen- tifikation im ersten Schritt nach dem Verbindungaufbau, was POP3 zu etwas mehr Sicherheit verhilft. Es ist zwar mit Hilfe von SMTP möglich, E-Mails in das Sys- tem unter falschem Namen einzuschleusen, jedoch kann nur derjenige, der die Zugangsdaten für ein Konto hat, die eingetroffenen E-Mails auch abrufen. Nach 1.4 E-Mail-Infrastruktur Seite 27 vielen Detailverbesserungen ist RFC 1939 (Myers and Rose[1996] letzte und RFC 1939)die aktuelle Spezifikation von POP3. Sicherheitskritisch ist dabei jedoch zu beachten, dass auch in diesem Protokoll die Kommunikation unverschlüsselt statt findet und somit abgehört werden kann. Das Passwort wird zusätzlich im Klartext über- tragen, wodurch nicht nur die Inhalte der übertragenen E-Mail an den einzelnen 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 authentiﬁzieren, damit der Server die Verbindung zum richtigen Postfach herstellen kann (Zus- tand: 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 re- servierten 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).

Abb. 1.5: UML Zus- WAITING_FOR_CONNECTION tandsdiagramm einer POP3 Sitzung. Verbindungsaufbau

AUTHORIZATION

Client Identifikation am Server

TRANSACTION Aktionen ausführen Verbindung getrennt

Client sendet QUIT Kommando

UPDATE

Insgesamt sollte festgehalten werden, das POP3 Kommandos textbasiert und ohne Beachtung von Groß- und Kleinschreibung sind. Nach einem Schlüsselwort kön- nen 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. Antwortnachricht- en 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 ab- schließenden Steuerzeichen) lang sein. Als Statusindikatoren dürfen nur der pos- Seite 28 Studienbrief 1 Grundlagen

Abb. 1.6: UML Se- Client Server quenzdiagramm einer POP3 Sitzung. Wartet auf Verbindungsaufbau --Verbindungsaufbau

+OK example.com POP3-Server

USER [email protected]

+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:

To:

Subject: Beispiel E-Mail

Das ist eine Beispiel E-Mail.

Diese E-Mail enthaelt keinen sinnvollen Text.

DELE 1

+OK message marked for delete

QUIT

+OK bye 1.4 E-Mail-Infrastruktur Seite 29 itive 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 frei gegeben werden können.

Im folgenden Beispiel 1.4 werden einige wichtige Befehle von POP3 beschreibend aufgelistet.

Beispiel 1.4: POP3 Befehle B 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 zwingend 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. Ab- bilding 1.5 auf Seite 27) geht.

NOOP enthält keinen Befehl, kann aber an den Server gesendet werden, um den Timeout zurück zu setzen, 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-Mail 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öﬀnet 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-Mail entfernen. Ist der Löschvorgang nicht erfolgreich, so quittiert der Server dies mit einer negativen Rückmel- dung.

Wie bereits weiter oben beschrieben, hat POP3 zwei Schwachstellen. Zum einen ﬁndet die Benutzerauthentiﬁkation im Klartext statt. Dadurch bedingt ist es für Seite 30 Studienbrief 1 Grundlagen

Angreifer mit vergleichbar geringem Aufwand möglich, die Kontoinformationen wir Benutzername und Passwort herauszuﬁnden. Zum anderen verwendet POP3 keine Verschlüsselung, wodurch nicht nur die Kontoinformationen sondern auch alle anderen Informationen für Angreifer sichtbar werden.

APOP Um das erste Problem anzugehen, enthält POP3 den optionalen Befehl APOP. Serv- er, 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]RFC822 ) 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]RFC1321 ) 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 Be- nutzerkonto 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 essentieller Bedeutung ist hierbei, dass jeder Zeitstempel einzigartig ist.

Für das zweite Problem der nicht vorhandenen Verschlüsselung bietet POP3 keine POP3S 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 spez- iﬁziert (vgl. Newman[1999]RFC2595 ). Somit existieren Möglichkeiten, die den E-Mail Abruf absichern. Häuﬁg werden diese jedoch aus Bequemlichkeitsgründen nicht angewendet.

1.4.5 IMAP (Internet Message Access Protocol)

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]RFC3501 ) 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]RFC1064 ) im Jahr 1988, damals noch unter dem Namen Interactive Mail Access Proto- col, veröffentlicht. Das direkt in Version 2 erschienene Protokoll galt jedoch genau- RFC 1203 so wie die später in RFC 1203 veröffentlichte Version 3 (vgl. Rice[1991] ) als exper- RFC 1730 imentell. Erst mit der im Jahr 1994 in RFC 1730 (vgl. Crispin[1994] ) veröffentlicht- en 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 Serv- er löschen, sondern E-Mails, Ordnerstrukturen und Einstellungen auf dem Serv- er bleiben, damit diese von unterschiedlichen Computern des selben Benutzers genutzt werden können. Abbildung 1.7 auf Seite 31 zeigt dazu eine Beispiel IMAP Sitzung.

Gegenüber POP3 bietet IMAP verschiedene Vorteile, die im Folgenden näher betrachtet werden. 1.4 E-Mail-Infrastruktur Seite 31

Client Server Abb. 1.7: UML Se- quenzdiagramm einer Wartet auf Verbindungsaufbau IMAP Sitzung. --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 Subject: IMAP4rev1 WG mtg summary and minutes To: [email protected] cc: [email protected], John Klensin Message-Id: 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 Seite 32 Studienbrief 1 Grundlagen

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 Abhol- ung von neuen Nachrichten neu aufgebaut werden. Nachrichten werden dann auf den Client herunter geladen, sobald dieser sie anfordert. Je nach Konfiguration des Clients kann eine neue Nachricht sofort herunter geladen 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 spez- iﬁziert mehrere gleichzeitige Verbindungen an ein Benutzerkonto. Dabei wird sogar eine Mechanismus beschrieben, der die Clients untereinander informiert, sobald einer der Clients eine Änderung vollzogen hat.

Zugriﬀ auf einzelne Bestandteile der E-Mail

POP3 speziﬁziert 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. ﬂags), die für IMAP deﬁniert sind, kann ein Client einer E-Mail bestimmte Statusinformationen an- hängen. So können die E-Mails auf dem Server bspw. als gelesen oder wichtig markiert werden.

Erstellung von Unterkonten und Zuweisung von Zugriﬀsrechten für andere Nutzer

Zur Strukturierung der E-Mails auf dem Server können Nutzer eigene Unterkon- ten 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 Zugriﬀ auf ein eigenes Unterkonto zu geben, was in RFC 4314 (vgl. Melnikov[2005]RFC4314 ) 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 der der Client den Server darum bitten kann, seine E-Mails nach bestimmten Kriterien zu durchsuchen. Dadurch bedingt muss der Client nicht alle E-Mail zuerst herunterladen, bevor er mit der Suche anfangen kann, sondern erhält sofort die passenden Treﬀer. 1.4 E-Mail-Infrastruktur Seite 33

Schnittstelle für Erweiterungen

Die aktuelle Version 4 von IMAP bietet explizit einen Mechanismus, um Er- weiterungen einzubauen.

Grundsätzlich hat IMAP allerdings auch Probleme bzgl. Sicherheit, genauso wie auch SMTP und POP3. Sowohl die Datenübertragung als auch die Authen- tifizierung 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 werden. Hier IMAPSverwendet wird schon während des Verbindungsaufbaus die Verbindung transparent per TLS verschlüsselt (vgl. Newman[1999] anderen besteht die Möglichkeit, RFC 2595).Zum eine bereits bestehende unverschlüsselte Verbindung mit Hilfe des STARTTLS Be- fehls (vgl. Hoffman[2002] eine verschlüsselte Verbindung zu überführen. RFC 3207)in

1.4.6 DNS (Domain Name System)

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 Studienbrief3 ab Seite 75 behandelt werden, wird es hier kurz vorgestellt. DNS wird innerhalb der RFCs 1034 (vgl. Mackapetris[1987a] RFC 1034) und 1035 (vgl. Mackapetris[1987b] und beschreibt, wie einzelne Com- RFC 1035)deﬁniert puter im Internet ausﬁndig gemacht werden können.

Das im Internet verwendete TCP/IP (vgl. Socolofsky and Kale[1991] RFC 1180)set- zte auf numerische Adressen, um Computer zu erreichen. Diese werden bei IPv4 (vgl. Information Sciences Institute, University of Southern California RFC 791 [1981] und Almquist[1992]) durch vier jeweils 8 Bit große Blöcke deﬁniert RFC 1349, 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] Nichols et al.[1998]). Hier werden nicht 32 Bit zur RFC 2460und Adressierung sondern 128 Bit IPv6 Adressen werden aufgrund der RFC 2474verwendet. 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 speziﬁzierte 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 ﬁnden. 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 ﬁnden ist. Der damit verbundene Name open-c3s.de ist dagegen Seite 34 Studienbrief 1 Grundlagen

allerdings einprägsam und hat zumindest für die Leser dieses Studienbriefes eine Semantik.

Die in Studienbrief3 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.4.1 ab Seite 78.

Nachdem in diesem Abschnitt die wichtigen Protokolle für die E-Mail Kommu- nikation vorgestellt wurden, sollen die Kontrollaufgaben im folgenden Abschnitt das Gelernte festigen.

1.4.7 Kontrollaufgaben

In diesem Abschnitt befinden sich verschiedene Kontrollaufgabe, die die Inhalt der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffs beitragen sollen.

Kontrollaufgabe 1.5: Modellentscheidung K Welche Konsequenzen ergeben sich für Sender und Empfänger, falls das Peer-to-Peer-Modells anstelle des Client-Server-Modells verwendet werden würde?

Kontrollaufgabe 1.6: Beschränkung der Zeilenlänge innerhalb von E-Mails 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 K Betrachten Sie die RFC 5322 (Resnick[2008]). Wie groß ist die minimale An- zahl 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 K Zu welchem Zweck wird SMTP verwendet? 1.4 E-Mail-Infrastruktur Seite 35

Kontrollaufgabe 1.9: Base64 Kodierung K Beschreiben Sie, warum die Base64 Kodierung kein Ersatz für eine Verschlüs- selung darstellt.

Kontrollaufgabe 1.10: SMTP Auth K Was passiert bei der SMTP-Auth Variante PLAIN mit dem Passwort und dem Benutzername? Warum ist diese Möglichkeit der Authentiﬁzierung nicht sicher?

Kontrollaufgabe 1.11: POP3 Server Rückmeldungen K Welchen Zweck verfolgen positive bzw. negative Rückmeldungen des Servers?

Kontrollaufgabe 1.12: POP3 Befehl: LIST und RETR K Was ist der Unterschied zwischen den beiden POP3 Befehlen LIST und RETR?

Kontrollaufgabe 1.13: POP3 Befehl: DELE K Welche Konsequenz hat der DELE-Befehl für eine bestimmte E-Mail?

Kontrollaufgabe 1.14: POP3 Befehl: NOOP K Wozu wird der NOOP-Befehl verwendet? Gibt es POP3-Implementierungen, die diesen Befehl überﬂüssig machen?

Kontrollaufgabe 1.15: Verwendung von IMAP K Zu welchem Zweck wird IMAP eingesetzt?

Kontrollaufgabe 1.16: Schächen von IMAP K An welchen Stellen bestehen bei IMAP Schwächen und wie wird versucht diese zu beheben? Seite 36 Studienbrief 1 Grundlagen

Kontrollaufgabe 1.17: DNS K Was ist DNS, wozu wird es benötigt, und was hat es mit Spam zu tun?

Die Lösungen zu den Kontrollaufgaben sind in Abschnitt 1.10 ab Seite 41 zu ﬁnd- en.

1.5 Anreize und Motivation der Spammer

In diesem Abschnitt soll nur kurz auf die Motivation der Spammer eingegangen werden, da Studienbrief4 ab Seite 118 dazu genauere Informationen enthält.

Der allgemeine Konsens zu Spam besteht darin, dass alle Empfänger Spam als hinderlich empﬁnden und oftmals gelernt haben, damit zu leben. Obwohl automatische Mechanismen einen Großteil des Spams aus den Postfächern heraus ﬁltern, kann es trotzdem hin und wieder passieren, dass eine Spam Nachricht nicht als 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 enthielt und der Empfänger sie nie erhalten hat.

Die Frage, die man hier aber 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äuﬁg, 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 Be- trug 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.8 ab Seite 40). Weiterhin wird Spam auch benutzt, um Schadsoftware auf andere Rech- ner 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äuﬁg auf Programmierfehlern des Versenders.

Um die in diesem Abschnitt angesprochene Motivation für Spammer näher auszuführen, wird in Abschnitt 1.7 eine Fallstudie besprochen, die im Jahr 2011 in den USA durchgeführt wurde.

Vorher werden im nächsten Abschnitt allerdings wirtschaftliche Aspekte angesprochen.

1.6 Wirtschaftliche Aspekte

Wirtschaftliche Aspekte lassen sich in zwei Kategorien einteilen. Auf der einen Seite sind dies Kosten, die durch Spam und die daraufhin eingeleiteten Ab- wehrmaßnahmen entstehen. Auf der anderen Seiten entsteht aber auch Gewinne 1.6 Wirtschaftliche Aspekte Seite 37 bei den Versendern von Spam, die den ﬁnanziellen Ertrag als Ziel und den versendeten Spam als Mittel zum Erreichen des Ziels ansehen.

1.6.1 Durch Spam entstehende Kosten

Die Kosten, die durch Spam verursacht werden, entstehen wiederum in zwei Bere- ichen. 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 Nachricht- en benötigt, zwar ein Verlust an Lebenszeit, dieser Verlust kann jedoch ﬁnanziell nicht genau beziﬀert 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.

Neben den Personalkosten entstehen aber auch weitere Kosten bei der Infrastruk- tur. 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, Grußunternehmen, mittelständisches Unternehmen und Kleinunternehmen bzw. Einzelunternehmen.

Ab ca. 3 Millionen verwalteter Postfächern spricht die Studie von einem Großprovider, der im Normalfall pro Tag im Durchschnitt etwa 5 Spam Nachricht- en pro Postfach erhält. Damit beläuft sich das gesamte Spam-Aufkommen auf 15 Millionen Spam Nachrichten in dem genannten Zeitraum. Um wettbewerbs- fähig zu sein und auch zu bleiben, muss sich ein Großprovider um entsprechende Schutzmaßnahmen kümmern. Diese bestehen in der Regel aus mehrstufigen Fil- tersystem mit selbst entwickelter Software oder stark angepassten Lizenzproduk- ten. 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 Daten- verkehr 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 Eng- pässen kommt. Doch nicht nur die Kapazitäten für der 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. Seite 38 Studienbrief 1 Grundlagen

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ösun- gen 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ät- zliche 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.6.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 Werbe- nachrichten zu einer Bestellung von Produkten durch den Spam Empfänger führen.

Im weiteren Verlauf der Studienbriefe werden in anderen Abschnitten weitere Ar- beiten betrachtet und mit dem Ergebnis dieser Arbeit verglichen.

1.6.3 Kontrollaufgaben

In diesem Abschnitt befinden sich verschiedene Kontrollaufgabe, die die Inhalte der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffs beitragen sollen.

Kontrollaufgabe 1.18: Kosten für Spam K Durch welche Faktoren entstehen Kosten für den Empfänger von Spam?

Kontrollaufgabe 1.19: Proﬁt Spamversand K Wie proﬁtieren die Versender vom Spam?

Die Lösungen zu den Kontrollaufgaben sind in Abschnitt 1.10 ab Seite 41 zu ﬁnd- en. 1.7 Fallstudie „Click Trajectories: End-to-End Analysis of the Spam Value Chain“ Seite 39

1.7 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 Wer- bung als Geschäftsmodell. In vielen anderen Veröffentlichungen steht die Erken- nung 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 habe 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.3 ab Seite 75), das URL Blacklisting (vgl. Abschnitt 3.4.1 ab Seite 78) und das vom Netz nehmen von Servern (vgl. Abschnitt 3.11 ab Seite 103). 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 Vermin- derung 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 64), Webmailer (vgl. Abschnitt 2.7 ab Seite 62) und IP Prefix Hijacking (vgl. Abschnitt 2.8 ab Seite 63) gestoßen.

Abb. 1.8: Die für eine einzige URL Wertschöpfungskette verwendete Infrastruk- tur aus Levchenko et al.[2011].

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 Kam- pagnen zu finden. Daraufhin versuchten die Autoren bei 120 Shops einen 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 zusammen arbeiten 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 durch- führen, ist es möglich, das Geschäftsmodell der Spammer empfindlich zu stören. So wäre es möglich, mit nur relativ keinen Eingriffen, die Menge an Spam deutlich zu verringern, das Ziel der Spammer das Verdienen von Geld ist und der Geldfluss so beeinflusst werden könnte. Seite 40 Studienbrief 1 Grundlagen

1.8 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. Telephon) 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 Spiel- er 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 Webbrowser oder E-Mail- Clients eingebaut sind. Dabei kann die Software untersuchen, ob der Nutzer eine Webseite besucht, deren URL (Uniform Resource Locator) bestimmte Schlüs- selwö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-Angriﬀen ist daher immer noch die eigene Wach- samkeit 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 Phishing-E- 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 der anfragenden Stelle per Telefon oder persönlich versichern, dass die Anfrage wirklich von dem entsprechenden Absender kommt.

Kontrollaufgabe 1.20: Phishing K Was wird unter der Bezeichnung Phishing verstanden und was hat dies mit Spam zu tun? 1.9 Zusammenfassung Seite 41

1.9 Zusammenfassung

In diesem Studienbrief wurden die Grundlagen für die folgenden Studienbriefe vermittelt. Beginnend mit einer Deﬁnition für E-Mails und Spam wurde die In- frastruktur 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 Ver- sand von Spam verdient werden kann und auch wie ohne technische Eingriﬀe der Versand von Spam reduziert werden kann.

Im folgenden Abschnitt ﬁnden Sie zunächst die Lösungen der Kontrollaufgaben aus diesem Studienbrief. Daraufhin sollen Sie die gelernten Informationen vertieft, damit sie im weiteren Verlauf dieses Moduls als Grundlage von kompliziert- eren Methoden dienen können. Dazu sind in Abschnitt 1.11 ab Seite 44 einige Übungsaufgabe angegeben.

1.10 Lösungen zu den Kontrollaufgaben

Kontrollaufgabe 1.1 auf Seite 17

E-Mails sind im Vergleich zu gewöhnlicher Post sowohl schneller, als auch gün- stiger im Versand. Hierfür wird jedoch gefordert, dass die zum Versand und Emp- fang benötigte Infrastruktur bereits vorhanden ist. Weiterhin sind E-Mails umweltfreundlicher, da weder Papier benötigt wird, noch ein herkömmlicher Transport stattﬁnden muss.

Kontrollaufgabe 1.2 auf Seite 17

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 Umwelt- freundlichkeit haben kann. Ein zum Empfang und zum Versand benötigter Com- puter 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 All- gemeinen 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.

Kontrollaufgabe 1.3 auf Seite 17

Spam gibt es bspw. auch in Gästebüchern, Foren und Online-Spielen sowie bei Instant Messengern.

Kontrollaufgabe 1.4 auf Seite 17

Ein möglicher Ursprung ist Webmail. Hier können Spamversender kostenlos Kon- ten erstellen, um darüber ihre Werbebotschaften zu verbreiten. Auf der anderen Seite 42 Studienbrief 1 Grundlagen

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.

Kontrollaufgabe 1.5 auf Seite 34

Würde anstelle des Client-Server-Modells das Peer-to-Peer-Modell für die E-Mail- Kommunikation 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 Verbindungsver- such ständig überprüfen, ob ein Empfänger verfügbar wird, was entsprechende Ressourcen kostet.

Kontrollaufgabe 1.6 auf Seite 34

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.

Kontrollaufgabe 1.7 auf Seite 34

Nach RFC 5322 ist es auch möglich, dass keine Empfänger im to Header Feld deﬁniert 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.

Kontrollaufgabe 1.8 auf Seite 34

SMTP wird zum Versand von E-Mail-Nachrichten verwendet. Dabei verbindet sich ein Client mit einem Server und geht dabei die einzelnen Schritte des deﬁnierten 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.

Kontrollaufgabe 1.9 auf Seite 35

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 Ver- schlü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 Angriﬀ sehr einfach möglich wäre, um eine solche Verschlüsselung zu knacken.

Kontrollaufgabe 1.10 auf Seite 35

Bei der SMTP-Auth Variante PLAIN werden das Passwort und der Benutzer- name 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. 1.10 Lösungen zu den Kontrollaufgaben Seite 43

Kontrollaufgabe 1.11 auf Seite 35

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.

Kontrollaufgabe 1.12 auf Seite 35

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.

Kontrollaufgabe 1.13 auf Seite 35

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 POP3- Verbindung wird die E-Mail gelöscht.

Kontrollaufgabe 1.14 auf Seite 35

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.

Kontrollaufgabe 1.15 auf Seite 35

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.

Kontrollaufgabe 1.16 auf Seite 35

Bei IMAP findet die Nutzerauthentifizierung im Klartext statt, wodurch die An- meldedaten bei reinen IMAP-Implementierung 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, abge- hört werden können.

Kontrollaufgabe 1.17 auf Seite 36

DNS ist ein System zur Identiﬁzierung von Computern im Internet. Computer verfügen über numerische Adressen. Da auf Text-basierende Adressen für Men- schen jedoch einfacher zu merken sind, wird DNS dazu verwendet, um aus einer Text-basierten Adresse die dazu passende numerische Adresse zu ﬁnden. Es wird Seite 44 Studienbrief 1 Grundlagen

für Anti-Spam-Maßnahmen wie DNS-basiertes Blacklisting verwendet, um Infor- mationen über eine IP-Adresse zu erhalten.

Kontrollaufgabe 1.18 auf Seite 38

Für die Empfänger von Spam entstehen unterschiedliche Kosten. Auf der einen Seite stehen Personalkosten, sofern Spam von Mitarbeitern in einem Un- ternehmen 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.

Kontrollaufgabe 1.19 auf Seite 38

Die Versender von Spam proﬁtieren indem Spamempfänger die in den Werbe- botschaften beworbenen Produkte kaufen.

Kontrollaufgabe 1.20 auf Seite 40

Der Versuch, der Erlangung von persönlichen Daten, um bspw. Zugriﬀ 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.

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 Authentiﬁzierung als Erweiterung von SMTP: Aus welchem Grund soll die im ersten Schritt vom Server an den Client gesendete Zeichenkette möglichst einzigartig sein? 1.11 Übungen Seite 45

Übung 1.4: SMTP Sitzung Entspricht die folgende Sitzung der RFC 2821? Falls nein: In welchen Punk- Ü ten 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:

550 5.1.1 Unknown recipient.

mail from: 250 2.1.0 Sender accepted.

rcpt to: Hans Mueller 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 Ver- fügung stellt. Was können Sie dabei feststellen? Seite 46 Studienbrief 1 Grundlagen

Übung 1.6: Fehlerhafter E-Mail Header Ü Betrachten Sie folgende E-Mail:

Date: 11 Nov 2009 13:47:07 Message-ID: <49197ECB.9030604hgi.rub.de> From: "Christopher Wolf" "Yvonne Roehrle-Schetz" , To: HGI Office , "Mario Rottorf" [email protected] BCC: [email protected] User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 Subject: Re: Dienstreise Koblenz References: <8E3FF01191314A94BB6A28C05411D310@p76> <[email protected]> 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 24. 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 An- nahme, dass die vom Server verschickten Zeitstempel nicht einzig sind, einen Angriff vorstellen, bei dem der Angreifer Zugriff auf ein bestimmtes Benutzerkonto erlangt?

Übung 1.10: IMAP vs. POP3 Ü Nennen und beschreiben Sie drei Vorteile, die IMAP gegenüber POP3 bietet. 1.11 Übungen Seite 47

Ü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 deﬁniert 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 her- Ü aus, ob es einen Dienst gibt, der zu einer IP-Adresse die damit verbundenen Namen zurück gibt. 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 ﬁnden 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. Seite 48 Studienbrief 2 Spam-Techniken

Studienbrief 2 Spam-Techniken

2.1 Lernziele

Sie wissen welche Infrastruktur von Spammern verwendet wird, um Spam zu versenden und Kapital aus dem Versand zu ziehen. Sie kennen verschiedene Arten von Spam-Techniken und können erklären, wie diese Techniken verwendet werden.

2.2 Einleitung

In diesem Studienbrief werden Techniken vorgestellt, über die Spam in den E- Mail-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ügelten Techniken kommt. Bevor auf die konkreten Methoden eingegangen wird, wird zuerst beleuchtet, wie Spam- mer arbeiten und auch wie ihre Strukturen aufgebaut sind. Dabei wird insbesondere auf Techniken zum Sammeln von Adressen und deren Abwehrmechanis- men 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 Medium E-Mail für Spam gerechnet wurde, konnte diese Lücke relativ schnell geschlossen werden. Offene Proxys 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 Hijack- ing 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.3 Spammer

Ursprünglich wurden Spam Nachrichten von einzelnen Personen aus verschickt, die dabei sehr einfach Techniken nutzten bzw. einfache Schwachstellen in Spezi- fikationen 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, aus zu sortieren oder zu blockieren. Auf der anderen Seite stehen die Versender von Spam, die immer professioneller vorgehen und sich zusammenschließen, um ef- fizienter und effektiver zu werden. Spammer sind mittlerweile so professionell geworden, dass es sogar ein Register von bekannten Spam Operationen (vgl. The ROKSO 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 mind. drei Internet Service Provider (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 2.3 Spammer Seite 49

Nordamerika und Europa verantwortlich sind und fast alle dieser Gruppen in dem Register aufgelistet sind.

2.3.1 Spammer-Netzwerke

Es ist klar, dass Spammer die E-Mail-Infrastruktur verwenden, um Werbe- nachrichten zu verschicken. Es stellt sich aber die Frage, wie die sonstige Infras- truktur von Spamversender genau aufgebaut ist, damit ihr Geschäft möglichst eﬀektiv 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öglich- Partner er Aufbau eines AffiliatesAffiliates Spammer-Netzwerkes Längerfristige (Freie Mitarbeiter) Infrastruktur (Freie Mitarbeiter) (angelehnt an Schober Spamversand,Spamversand, [2009]). Bullet-Proof Server, Harvesting usw. Bankkonten in Harvesting usw. „sicheren“ Ländern

Gewinnbeteiligung

Hauptspammer

Adress- datenbank

Ankauf von Produkten und Koordination des Kundenaufträge Produktversands für E-Mail Marketing nach erfolgtem Kauf An/Verkauf von Adressen Anmieten / Kauf von Botnetzen zum Mailversand

Adress- Händler Produzenten Botnetz- Service- und andere und Versand- betreiber anbieter Spammer Dienstleister

Adress- Käufer datenbank

Im Mittelpunkt der Abbildung steht der Hauptspammer, der zwei Ressourcen benötigt. Das ist zum einen eine Adressdatenbank mit E-Mail-Adressen Adressdatenbank,die 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 Infor- mationen können für den Hauptspammer wichtig sein, wenn er seine Werbe- botschaften an 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, Seite 50 Studienbrief 2 Spam-Techniken

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 Adresse 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 in- teressiert sich für das beworbene Produkt, so folgt er einem Link zum Shop des Versenders. An dieser Stelle wäre ein Eingriﬀ 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-ServerBullet-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 zusammen arbeiten. 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 Mitarbeit- er, sogenannte AﬃliatesAﬃliate. Diese freien Mitarbeiter können sowohl für den Ver- sand 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 BotnetzeBotnetz 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 Bot- netzbetreibern. Diese können ihm dann für einen bestimmten Preis eine feste An- zahl 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 Pro- duzent 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 An- bieter.

Neben ihrer üblichen Infrastruktur und ihrer eigenen Kontakte, haben viele Spam- mer allerdings auch noch Kontakte zu anderen Spammern. Die können dann als Partner eine vergleichbare Infrastruktur aufweisen und bei komplexen Aufträgen helfen.

2.3.2 Adress-Harvesting

Der Versand von Spam ist für Spammer denkbar einfach. Nachdem im vorherigen Abschnitt vorgestellt wurde, wie die Infrastruktur vom Spamversendern aufgebaut ist, stellt sich allerdings noch die Frage, wie genau Spammer ihre E-Mail- Adressdatenbanken füllen. Allgemein wird das Suchen von E-Mail-Adressen als Adress-Harvesting bezeichnet. Für das Adress-Harvesting gibt es unter- 2.3 Spammer Seite 51 schiedliche 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 in- fizierten Computers durchsuchen. So finden die Bots bspw. Adressbücher aus E- Mail-Programmen. Andererseits können die Bots aber auch auf der Suche nach potentiellen 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 reg- ulä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 hin- terlassen. Es können weiterhin auch Webseiten von Firmen sein, die ein Impres- sum 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) nächsten 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, so dass Programme sie nicht als solche identifizieren.

Directory Harvest Angriﬀ

Eine weitere, weniger ausgeklügelte Möglichkeit, um an E-Mail-Adressen zu gelangen, ist der sogenannte Directory Harvest Angriﬀ. Hierbei gibt es zwei mögliche Techniken, um Listen von potentiellen 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 Millio- nen verschiedene Kombinationen. Die zweite Möglichkeit eine solche Liste zu erstellen, besteht darin, geläuﬁge Vorname, Nachnamen und Initialen sinnvoll zu verbinden. So entstehen bspw. E-Mail-Adressen wie max.mustermann@domain Seite 52 Studienbrief 2 Spam-Techniken

oder mmustermann@domain. Diese Methode ist angelehnt an einfache Wörter- buchangriffeWörterbuchangriffe , wogegen die im ersten Schritt genannte Methode zu den Brute- o c n r ff nrt-oc AngriffForce AngriffenBrute-Force zä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 ger- atene Konto zu verschicken. Diese Test-E-Mail enthält im Normalfall noch keine Werbebotschaften, damit keine Filter anschlagen. Der Erfolg des Directory Har- vest 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 dem entsprechend 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 potentiellen 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.3.3 Anti-Harvesting-Methoden

Entsprechend der im vergangenen Abschnitt beschriebenen Harvesting- Methoden existieren wiederum Methoden, um den Adresssammlern das Sam- meln 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 textbasierten Informationen ist es ebenso möglich, eine E-Mail in Form eines Bildes innerhalb einer Internet Seite 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 die selben 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 das Abtippens ist zum einen aufwendiger und zum anderen fehler- anfälliger, wodurch die Kommunikation zwar anfangs erschwert wird, insgesamt die Wahrscheinlichkeit für den Empfänger allerdings steigert, nicht in einer Adressen-Datenbank zu landen. Hier können Adressensammler ihre Soft- ware 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 Adress- sammlern geschützt. 2.3 Spammer Seite 53

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- trolling the Assault of Non-Solicited Pornography And Marketing Act of 2003“ (vgl. 108th United States Congress[2012]). Hierbei müssen Betreiber von Web- seiten 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-Adresse nur für Menschen sichtbar zu machen, eignen sich auch CAPTCHAs. Der Begriﬀ CAPTACH steht für „Completely Automated Public Tur- ing 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 Zeichenket- ten 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 muss. Bei akustischen CAPTCHAs wird oft gesprochene Sprache abge- spielt, 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 Adresssamm- ler abhalten, solange diese nicht entsprechend angepasste Software verwenden, da auch Programme dazu angelernt werden können, graﬁsche 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 überwun- den werden kann. Seite 54 Studienbrief 2 Spam-Techniken

E-Mail-Adressen Verfälschung

Eine weitere Möglichkeit, um eine E-Mail-Adresse vor dem automatischen Sam- meln zu schützen besteht darin, die E-Mail-Adresse an sich zu verfälschen. Diese 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 ersetzt, der Punkt durch oder ein Bindestrich durch . 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, das 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 eine E-Mail-Adresse einen Fehler gemacht hat und die Empfänger- adresse daher nicht existiert.

E-Mail Honepots: Spider Traps

In der IT-Sicherheit wurde vor einigen Jahren erkannt, dass nicht nur proak- tive Techniken also direkte Abwehrmaßnahmen sinnvoll sind, um Sicherheitsan- forderungen durchzusetzen, sondern auch der Einsatz von reaktiven Maßnahmen hilfreich ist, um bestimmte Angriffe zu verstehen. Vor diesem Hintergrund wurden sich so genannte Honeypots (dt. Honigtöpfe) entwickelt, die reale System darstellen und für einen Angreifer als lohnendes Ziel angesehen werden kön- nen, in Wirklichkeit allerdings keine Dienste ausführen, die für den Betreiber wichtig sind. Angriffe aus solche System 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 Sam- meln von E-Mail-Adressen übertragen. Diese Technik kann unterschiedliche Ak- tivitätsgrade verfolgen. Sie lässt sich auf der einen Seite eher passiv nutzen, in dem eine ungenutzte E-Mail-Adresse 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 ausﬁndig zu machen. 2.3 Spammer Seite 55

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 Gestal- tung und Strukturierung von Webseiten, sie beinhaltet auch die Möglichkeit, Elemente im Quellcode zu beschreiben, so dass die Darstellung innerhalb der anzuzeigenden Webseite sich stark vom Quellcode unterscheidet. So können bspw. Elemente wie E-Mail-Adressen mit Hilfe von Bildern unterbrochen werden, die eine 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 in 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 Men- sch 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-Mail- Adressen zu erschweren, hat sich eine Verschleierung der E-Mail-Adressen mit Hilfe 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 aus- führen, die aus der verschlüsselten Zeichenkette die erwünschte E-Mail-Adresse berechnet. Als besonders hilfreich hat sich hier die ROT13-Verschiebechiﬀre (vgl. Exkurs 2.1 und Exkurs 2.2) herausgestellt. Seite 56 Studienbrief 2 Spam-Techniken

Exkurs 2.1: Verschiebechiffre E 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üs- sel, 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.

Etwas formaler gefasst kann die Verschiebechiﬀre mit Hilfe der Modulo- Arithmetik beschrieben werden. Die Buchstaben des Alphabets werden fort- laufend 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:

encryptp(ki) = buchstabe(zahl(ki) + p mod 26)

Die Entschlüsselung eines Geheimtextes wird durch folgende Funktion für jeden Buchstaben ki einzeln durchgeführt:

decryptp(ki) = buchstabe(zahl(ki) − p mod 26)

Gilt p = 1, so wird die Zeichenkette TEST bspw. in UFTU umgewandelt.

Exkurs 2.2: ROT13 E ROT13 ist die Abkürzung für rotate by 13 places. Es handelt sich hierbei um eine gewöhnliche Verschiebechiﬀre (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. Da automatische Programme zum Sammeln von Adressen im Allgemeinen nicht 2.3 Spammer Seite 57 den vollen Funktionsumfang eins Browsers besitzen, also oft auch keine Unter- stü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 einge- sammelte 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 Dien- stleistungen 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öﬀentlichen 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 Kon- taktdaten 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 öﬀentlich 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 Verwen- dung von CAPTCHAs erschwert werden, wie bereits oben in diesem Abschnitt gezeigt wurde.

2.3.4 Kontrollaufgaben

In diesem Abschnitt befinden sich verschiedene Kontrollaufgabe, die die Inhalte der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffs beitragen sollen.

Kontrollaufgabe 2.1: Spammer Netzwerk K Beschreiben Sie die Infrastruktur, die Spamversender nutzen, um Spam zu versenden.

Kontrollaufgabe 2.2: Adress-Harvesting K Was genau versteht man unter dem Begriﬀ Adress-Harvesting? Seite 58 Studienbrief 2 Spam-Techniken

Kontrollaufgabe 2.3: Directory Harvest Attack K Wie viele verschiedene Kombinationen von E-Mail-Adressen entstehen bei der ersten Technik des Directory Harvest Angriﬀs, wenn die Länge der Nutzernamen fünf oder wenige Zeichen betragen darf und von einem Al- phabet 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: Verschiebechiﬀre K

Zeigen Sie, dass die Funktion encryptp(x) und decryptp(x) invers zueinander sind.

Kontrollaufgabe 2.7: ROT13-Verschiebechiﬀre K Welche Besonderheit hat die ROT13-Verschiebechiﬀre?

Die Lösungen zu den Kontrollaufgaben sind in Abschnitt 2.11 ab Seite 69 zu ﬁnd- en.

2.4 Oﬀene Mail-Relays

Wie bereits im ersten Studienbrief in Abschnitt 1.4.3 ab Seite 20 und Abbil- dung 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-Mail vom Com- puter des Benutzers zum einen 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 von Server des Versenders zum Server des RFC 5321 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 Kon- ﬁguration dieses Server kann dieser die Annahme der E-Mail mit dem Antwort Code 2.5 Oﬀene Proxys Seite 59

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 Status Code

551 User not local; please try

(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 SMTP- Server mit dem Status Code

251 User not local; will forward to " 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 beﬁndet. Im Folgenden wird die E-Mail dann an den entsprechenden Server weiter geleitet, 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 Kon- to 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 E- Mail selber zu bestimmen. Beﬁnden sich bspw. unterschiedliche SMTP-Server in einem Firmennetzwerk, wobei der Client selber nur direkten Zugriﬀ 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 Authen- tifizierung 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.

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 Be- ginn des Spam-Aufkommens Mitte der 1990er Jahre auch der meist 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]) diese Lücke schließen sollten. Ebenso wurden RFC 2505,die Empfehlungen in RFC 5321 (vgl. Klensin[2008]) eingearbeitet.

Kontrollaufgabe 2.8: Oﬀene Mail-Relays K Was macht einen SMTP-Server zu einem oﬀenen Mail-Relay?

2.5 Oﬀene Proxys

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 Seite 60 Studienbrief 2 Spam-Techniken

N die Pakete von A an B weiter leiten und entsprechend von B an A. Dabei existieren verschiedene Arten von Proxys wie Proxy-Server, generische Proxys, Proxy-Firewalls, transparente Proxys und auch Reverse Proxys. Im Fall eines Net- zes kann ein Proxy bspw. im allgemeinen Fall dazu verwendet werden, um bestimmte Daten für einen Dienst zu ﬁltern. Dabei bieten sich auch SMTP-Proxys an, die innerhalb von Proxy-Firewalls dazu verwendet werden, um den Datenverkehr zu überwachen und Spam auszuﬁltern.

Ein oﬀener Proxy ist nun ein Proxy, der ohne Anmeldung von jedem verwendet werden kann. Dies ist z.B. sinnvoll, sofern jemand anonym einen Dienst im Inter- net verwenden möchte und seine IP-Adresse daher verschleiern möchte. Ein reales Einsatzszenario sind bspw. Krisenregionen in denen die Regierung den Inter- netverkehr überwacht. Hier kann ein oﬀener Proxy dazu verwendet werden, um mit anderen zu kommunizieren, ohne die eigene IP-Adresse dem Gesprächspart- ner mitteilen zu müssen.

Offene Proxy können aber auch zum E-Mail-Versand verwendet werden. Dabei verschickt ein Sender einer E-Mail an den Empfänger unter Verwendung der IP- Adresse des offenen Proxys. Dadurch sieht der Empfänger nur die IP-Adresse des offenen Proxys 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.4.1 ab Seite 78) stehen, weiterhin mit Hilfe einer anderen IP-Adresse Spam versenden können.

Es ist jedoch sehr simpel und auch ohne weiteres automatisch möglich, oﬀene Proxys 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. Ab- schnitt 2.3.3, Unterpunkt Kontaktformulare ab Seite 57), 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 RFC 1866 HTML-Standard wurden ab Version 2 (vgl. Berners-Lee and Connolly[1995] ) durch das

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 61 gibt weitere Informationen zu den Feldern von HTML-Formularen. Der Inhalt kann dann wiederum mit Hilfe 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, die 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 mit Hilfe von Formularfeldern durch den Nutzer selber deﬁniert wird. Somit ist es für einen Nutzer möglich, ohne eigenen E-Mail-Client eine E-Mail an eine beliebige Adresse zu verschicken. Au- tomatisierte Programme suchen nach genau diesen fehlerhaften Formularen im 2.6 Mail-Formulare Seite 61

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 K Fassen Sie mit wenigen Worten zusammen, wie Mail-Formulare zum Ver- sand von Spam missbraucht werden können. Gehen Sie dabei explizit auf die Voraussetzungen ein, damit ein Spamversand überhaupt möglich ist.

Exkurs 2.3: Felder in HTML Formularen E Der HTML Standard in Version 4 erlaubt verschiedene Arten von Formula- rfeldern. 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 El- ementen 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 deﬁnierten Standardwerte wiederhergestellt.

select list Mit Hilfe der select list kann der Nutzer aus einer ausklap- penden Liste ein Element auswählen. Je nach Konﬁguration 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 mit Hil- fe der durch das Formular deﬁnierten Methode zu verarbeiten. Im All- gemeinen 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 allerdings auch möglich, mehrzeiligen Text einzugeben.

text box Die text box ist ein Element zur Eingabe von einzeiligen Tex- ten. Hier können Buchstaben, Zahlen und auch beliebige Sonderze- ichen eingetragen werden. Eine text box kann verschiedene Eigen- schaften haben. Dazu zählen vordefinierte Eingaben, Längenbegren- zungen 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 Shoulder-Surfing von anderen entdeckt werden kann. Seite 62 Studienbrief 2 Spam-Techniken

2.7 Webmail

Webmail ist ein Dienst, der von unterschiedlichen Anbietern zur Verfügung gestellt wird, um eine E-Mail-Kommunikation ohne eigenen E-Mail-Client zu er- möglichen. Dazu benötigt der Benutzer als Clientsoftware ausschließlich einen Browser, um den Dienst im WWW zu erreichen. Die gesamte Kommunika- RFC 1945tion zwischen Server und Client läuft über HTTP (Hypertext Transfer Protocol, RFC 2616vgl. 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]RFC2854 ) als Beschreibungssprache verwendet. Die Vorteile von Webmail liegen damit klar auf der Hand: Der Nutzer kann den Di- enst 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 Nachricht- en durch den Benutzer durchgeführt werden. Im Allgemeinen werden die Dat- en durch den Dienstanbieter professionell gesichert und stehen daher auch noch nach einem Hardwarefehler dem Nutzer zur Verfügung. Der Nachteil des Dien- stes 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 Dienstanbi- eter stehen unter Umständen auch nur begrenzt viel Speicherplatz zur Verfügung, oder der Speicherplatz kann nur durch ﬁnanzielle Unterstützung des Dienstanbi- eters 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 Sicherheitsbewusstsein. 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-Mail Konten. Diese können auf der einen Seite durch Phishing (vgl. Abschnitt 1.8 ab Seite 40) von anderen Benutzern übernommen werden. Eine zweite Möglichkeit besteht darin, mit Hilfe von Botnetzen (vgl. Abschnitt 2.9 ab Seite 64) 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 klassiﬁzieren. Dazu zählen bspw. Listenverfahren wie White-, Black- und Greylisting (vgl. Abschnitt 3.4 ab Seite 78) sowie entsprechende Reputationsverfahren (vgl. Abschnitt 3.5 ab Seite 84). 2.8 IP Preﬁx Hijacking Seite 63

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 soll, dass sich wirklich ein Men- sch 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 dem selben Land angemeldet, so ist bei einer erneuten Anmeldung 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 Preﬁx Hijacking

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.4.6 ab Seite 33 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 IP-Adressen 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. Grup- pen 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 andere Autonome Systeme also darüber RFC 4271 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 weiter leiten 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 klassiﬁziert wurden, dass die Spam-Wahrscheinlichkeit einer E- Mail von einer anderen IP-Adresse aus dem gleichen Autonomen System deutlich Seite 64 Studienbrief 2 Spam-Techniken

größer ist. Gründe dafür sind leicht zu finden: Computer, die sich im gleichen Autonomen System befinden, werden auch oft von der selben Instanz gewartet. Auf ihnen läuft die gleiche Software und insbesondere sind die Softwareversio- nen auf den einzelnen Rechner gleich. Wurde nun einer der Rechner aus einem Autonomen System mit Malware (vgl. Abschnitt 2.9 ab Seite 64) 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 dahin gehen zu ändern, dass ihre Nachrichten nicht mehr aufgrund des Autonomen Systems bzw. ihres Präfixes als Spam klassifiziert und danach gefiltert werden. Diese Möglichkeit wird als IP Prefix Hijacking oder IP Hi- jacking bezeichnet. Es existieren verschiedene Möglichkeiten, um diesen Angriff durchzuführen. Zum einen kann ein Autonomes System anderen Autonomen Sys- temen 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 kom- promittierte 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 Au- tonomen 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 das IP Prefix Hijackings liegt also darin, die Ab- senderadresse soweit zu verschleiern bzw. zu fälschen, dass Filtertechniken die E-Mail 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 Netzwerkeigen- schaften 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 Preﬁx Hijacking K Wie funktioniert das IP Preﬁx Hijacking?

2.9 Malware / Botnetze

Als letzte Technik werden in diesem Studienbrief Malware und die damit in direk- tem Zusammenhand stehenden Botnetze behandelt. Malware (vgl. Deﬁnition 2.1) ist eine Kunstwort, das aus den beiden Begriﬀen malicious (dt. schädlich) und Software zusammen gesetzt 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 Funk- tionalität einer Software nur durch deren Ausgabe erkennen kann. Was eine Soft- ware 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 2.9 Malware / Botnetze Seite 65

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 von 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 klassi- ﬁziert wurde. Da die Analyse von Malware allerdings ein sehr komplexes Thema ist, wird sie hier nicht weiter vertieft. Wichtig bleibt zu behalten, dass Malware Software ist, die einem schadhaften Zweck dient.

Deﬁnition 2.1: Malware D Angelehnt an Aycock[2006] wird Malware durch die folgenden drei Charak- teristika deﬁniert:

Selbst-Replikation Die Schadsoftware verbreitet sich entweder aktiv, indem 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 Selbst-Replikation.

Parasitismus Schadsoftware hängt sich an oder vermischt sich mit anderem ausführbaren Code, um unentdeckt zu bleiben. Infolgedessen kann es auch zu einem Populationswachstum kommen. Auch eine passive Selbst-Replikation ist denkbar, sobald der Anwender Kopien des Codes, mit dem sich die Schadsoftware vermischt hat, auf anderen Sys- temen nutzt.

Da der Zweck von Malware auch der Versand von Spam sein kann, ist das Studi- um 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 Selbst-Replikation ist jedoch auf eine Benutzerinteraktion angewiesen, die im Gegensatz zur aktiven Selbst-Replikation sehr langwierig sein kann. Deshalb setzt aktuelle Malware auf eine aktive Selbst-Replikation. 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 Zugriﬀ auf ein System zu bekommen. Der eingeschleuste Schadcode enthält oft allerdings nicht die Malware selbst, sondern dient nur dazu, die Malware nachzu- laden, um sie daraufhin auszuführen. Wurde die Malware erfolgreich nachge- laden, so verfolgt sie generell zwei Ziele. Zum einen versucht sie sich weiter zu replizieren. Dazu sucht sie nach Sicherheitslücken auf anderen an das selbe Netzwerk angeschlossenen Computern. Zum anderen kann sie dann ihre Schad- funktion ausführen. Bei aktueller Malware existiert allerdings nicht eine einzige deﬁnierte Schadfunktion. Vielmehr verbindet sich die Malware mit anderen In- stanzen, um Befehle zu empfangen, die sie dann abarbeiten kann. Seite 66 Studienbrief 2 Spam-Techniken

Ist ein Computer mit Malware inﬁziert, 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 unterteilen werde. 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.

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]RFC1459 , Kalt[2000a], Kalt[2000b], Kalt[2000c] und Kalt[2000d]) deﬁniert. Ursprünglich für die Kommunikation von Menschen gedacht, eigentlich 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 Implemen- tierungen des Protokolls gibt. Weiterhin können auch vorhandene Server verwendet werden. Gleichzeitig können verschiedene Botnetze über den selben 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 Botmas- ter, also in beide Richtungen. Somit kann der Botmaster Befehle an den Bot senden und gleichzeitig Status-Codes vom Bot zurück erhalten, 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 Kommunika- tion ü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 stan- dardmäß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 Infor- mationen 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 beﬁndet, an den Botmaster übertragen werden. 2.9 Malware / Botnetze Seite 67

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 es sich das erste mal mit einem C&C Server verbindet. Daher ist oft eine Reihe von Zieladressen bereist fest im Quell- code des Bots implementiert. Behörden haben die Möglichkeit, einzelne Server zu sperren, wodurch sich die Bots nicht mehr mit dem Botmaster verbinden kön- nen uns somit auch keine weiteren Befehle mehr erhalten. Sind dem Bot mehrere Adressen bekannt, so kann er zumindest versuchen auf andere Kanäle auszuwe- ichen. Trotzdem besitzt dieses zentrale Kommunikationsmodell die Schwach- stelle, dass es ausreicht, wenige Server vom Netz zu nehmen, um die gesamte Kommunikation zu stoppen. Aus diesem Grund wird immer öfter das im näch- sten Abschnitt vorgestellte Peer-To-Peer Modell verwendet.

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 (oberﬂä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 oﬀen. An einer beliebigen Stelle im Netz muss dann nur ein Befehl eingefügt werden, der von jedem Teilnehmer weiter verbreitet wird. Somit erhalten früher oder später alle Bots die aktuellen Befehle und können auch eigene Informationen an andere Bots weiter geben. Der Vorteil von diesem Kommunikationsmodell liegt ganz klar in der Ausfallsicher- heit. 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) Angriﬀe 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 Aktio- nen ausgeführt werden, die den Benutzer des kompromittierten Rechner betref- fen. 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 Nutzer 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 oder 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 Seite 68 Studienbrief 2 Spam-Techniken

bspw. per Brutforce Passwörter zu knacken. Insgesamt existieren viele andere An- griﬀsszenarien, 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 ﬁnden, wie von Provos and Holz[2008] beschrieben.

Zusammenfassen 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. Niko- laenko[2010]) ein mögliches Spam-Volumen von mehr als 200 Milliarden Spam Nachrichten pro Tag.

Kontrollaufgabe 2.14: Malware K Benennen und beschreiben Sie die drei wesentlichen Eigenschaften, die Mal- ware auszeichnen.

Kontrollaufgabe 2.15: Botnetz I K Woraus besteht ein Botnetz?

Kontrollaufgabe 2.16: Botnetz II K Welche Kontrollstukturen existieren für Botnetze? Beschreiben Sie dabei für die einzelnen Strukturen jeweils Vor- und Nachteile.

Kontrollaufgabe 2.17: Botnetz III K 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 K Für welche Zwecke werden Botnetze neben der Verbreitung von Spam verwendet?

2.10 Zusammenfassung

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 2.11 Lösungen zu den Kontrollaufgaben Seite 69 wurden offene Mail-Relays besprochen und beschrieben, wie es zum anonymen Versand von Spam über dieser Strukturen kommen konnte. Die danach ange- sprochenen offenen Proxys waren dann eine generelle Möglichkeit, um anonym Spam zu verschicken, bevor der Abschnitt über Mail-Formulare diese Möglichkeit zur Versand von Spam aufbereitete. Webmail als professionelle aber eigenständi- ge Ausprägung von Mail-Formularen wurde daraufhin behandelt. Um fremde IP- Adressen 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 Studien- brief gestellten Kontrollaufgaben aufgeführt, bevor Abschnitt 2.12 ab Seite 73 die Übungsaufgaben auflistet.

2.11 Lösungen zu den Kontrollaufgaben

Kontrollaufgabe 2.1 auf Seite 57

Spammer benötigen um erfolgreich Spam zu versenden, viele Kontakte, damit sie möglichst eﬀektiv sein können. Ein Spammer selber benötigt eine Adressdaten- bank, 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 Bankkon- ten 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.

Kontrollaufgabe 2.2 auf Seite 57

Unter dem Begriﬀ 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.

Kontrollaufgabe 2.3 auf Seite 58

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 X 36i = 361 + 362 + 363 + 364 + 365 = 62.193.780 i=1

Möglichkeiten. Seite 70 Studienbrief 2 Spam-Techniken

Werden auch Sonderzeichen wie „.“, „-“und „_“erlaubt, so ergibt sich eine Basis- menge von 39 Zeichen. Es entstehen somit

5 X 39i = 391 + 392 + 393 + 394 + 395 = 92.598.519 i=1

Möglichkeiten.

Kontrollaufgabe 2.4 auf Seite 58

Um Adress-Harvesting auszuhebeln gibt es verschiedene Methoden, die die E- Mail-Adresse verändern. Dabei kann die Adresse bspw. durch bestimmte Substi- tutionen verändert werden, indem das @ durch oder der Punkt durch 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.

Kontrollaufgabe 2.5 auf Seite 58

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.

Kontrollaufgabe 2.6 auf Seite 58

Es ist zu zeigen:

encryptp(decryptp(x)) = decryptp(encryptp(x)) = x

Dafür gibt es zwei Möglichkeiten:

1. Durch Iteration über alle möglichen x und alle möglichen p kann die Gle- ichung bewiesen werden.

2. Durch Einsetzen und ausrechnen.

Die zweite Möglichkeit beruht auf mathematischen Kenntnissen der Modulo- Rechnung 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: f o r i in B do f o r j in P do pruefe : encrypt_j(decrypt_j(i )) == decrypt_j(encrypt_j(i)) und encrypt_j(decrypt_j(i)) == i falls Ungleich Ausgabe: Fehler in Gleichung fuer Buchstabe=i und P=j 2.11 Lösungen zu den Kontrollaufgaben Seite 71

brich ab sonst mache weiter done done Ausgabe: alle Gleichungen sind erfuellt

Kontrollaufgabe 2.7 auf Seite 58

Die Besonderheit der ROT13-Verschiebechiﬀre 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.

Kontrollaufgabe 2.8 auf Seite 59

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.

Kontrollaufgabe 2.9 auf Seite 60

Oﬀene Proxys sind Server, die Pakete auf beliebigen vorher deﬁnierten Ports annehmen und weiter leiten.

Kontrollaufgabe 2.10 auf Seite 61

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 hat.

Kontrollaufgabe 2.11 auf Seite 63

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 Web- browser.

Kontrollaufgabe 2.12 auf Seite 63

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 konﬁguriert 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. Seite 72 Studienbrief 2 Spam-Techniken

Kontrollaufgabe 2.13 auf Seite 64

Beim IP Preﬁx 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.

Kontrollaufgabe 2.14 auf Seite 68

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 Schad- software 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. Schad- software kann sich an andere Software hängen oder sich mit ihr vermischen, um unentdeckt zu bleiben. Diese Eigenschaft wird als Parasitismus bezeichnet.

Kontrollaufgabe 2.15 auf Seite 68

Ein Botnetz besteht aus vielen mit Malware inﬁzierten 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.

Kontrollaufgabe 2.16 auf Seite 68

Generell lassen sich die Kontrollstrukturen in zentrale und dezentral gliedern. Bei den zentralen Strukturen kann eine Kommunikation per IRC, HTTP oder auch FTP statt ﬁnden. 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 gekommen werden müssen, damit das gesamte Botnetz keine weiteren Befehle mehr annehmen kann. Eine dezentrale Kommu- nikation 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.

Kontrollaufgabe 2.17 auf Seite 68

Beim IRC Protokoll besteht zwischen Client und Server eine persistente Verbindung. Da es eine Obergrenze für oﬀene Verbindungen innerhalb jeder IRC Implementierung gibt, können sich nicht mehr Bots verbinden, als die Implementierung vorsieht. Bei einer Kommunikation per HTTP kann das Aktual- isierungsintervall prinzipiell fast beliebig groß gewählt werden. Damit sind auch fast beliebig viele anfragende Bots möglich.

Kontrollaufgabe 2.18 auf Seite 68

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 2.12 Übungen Seite 73 auch im WWW. Daneben können Botnetze bspw. auch für DDoS Angriﬀe eingesetzt werden.

2.12 Übungen

Übung 2.1: Adress-Harvesting I Was genau ist Adress-Harvesting und welche verschiedenen Methoden ex- Ü istieren?

Übung 2.2: Adress-Harvesting II Wie sollten E-Mail-Adressen hinterlegt werden, damit sie nicht dem Adress- Ü Harvesting 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 ﬁnden Sie heraus, wie viele Ü Zeichen der Local-Part einer E-Mail-Adresse maximal enthalten darf. Gehen Sie nun davon ausgehen, dass der Local-Part nur die Buchstaben von A bis Z, die Ziﬀern 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-Mail- Adressen dauern, wenn Sie davon ausgehen, dass sie pro E-Mail- Adresse 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 zur versendende E-Mail dann enthalten?

Übung 2.5: ROT13-Verschiebechiﬀre I Begründen Sie, warum bei der ROT13-Verschiebechiﬀre nur eine Funktion Ü sowohl für die Ent- als auch für die Verschlüsselung benötigt wird. Seite 74 Studienbrief 2 Spam-Techniken

Übung 2.6: ROT13-Verschiebechiﬀre II Ü Welche Methoden können bei der ROT13-Verschiebechiﬀre verwendet werden, wenn nicht nur Groß- sondern auch Kleinbuchstaben in einem Klartext auftreten? Unter welcher Voraussetzung lässt sich immer noch Modulo 26 rechnen?

Übung 2.7: ROT13-Verschiebechiﬀre III Ü Berechnen Sie den Geheimtext für „Spam-Techniken“ durch die ROT13- Verschiebechiﬀre unter der Berücksichtigung, dass Groß- und Kleinbuch- staben 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 Al- ternative 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ß en- thä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 Deﬁnition 2.1 auf Seite 65 vorgestellten Eigen- schaften 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? Studienbrief 3 Anti-Spam Techniken Seite 75

Studienbrief 3 Anti-Spam Techniken

3.1 Lernziele

Sie kennen verschiedene Anti-Spam Techniken, darunter ältere Techniken, die aktuell nicht mehr eingesetzt werden, sowie aktuelle. Sie verstehen, wie diese Tech- niken funktionieren und können sie auf E-Mails anwenden, um Spam zu erkennen.

3.2 Einleitung

Dieser Studienbrief behandelt unterschiedliche Anti-Spam Techniken. Dabei beginnt Abschnitt 3.3 mit einfachen Filtermethoden, die ausschließlich nach dem In- halt der Nachrichten klassifizieren. Daraufhin werden in Abschnitt 3.4 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 Im- plementierung des E-Mail-Clients des Senders. Weiter werden aktuellere Metho- den vorgestellt, wie Reputationsverfahren (Abschnitt 3.5) sowie Challenge- und Responds-Verfahren (Abschnitt 3.6), die nicht über statisch Listen die E-Mails erkennen, sondern unterschiedliche Eigenschaften des Senders zur Klassifika- tion verwenden. Danach werden Erweiterungen des klassischen E-Mail-Verfahren vorgestellt, die eine erfolgreiche Klassifikation erleichtern sollen (Abschnitt 3.7). Die weiteren Abschnitte beschreiben dann aktuelle Forschungsarbeiten, die sich mit dem Problem Spam auseinandersetzen. Dabei geht es von der Echtzeitfil- terung von Spam in Abschnitt 3.8 über die Erkennung (Abschnitt 3.10) und Über- nahme (Abschnitt 3.11) von Botnetzen zur automatischen Generierung von Spam Signaturen (Abschnitt 3.12), bevor eine konkrete Implementierung einer Software zur Spamklassifikation vorgestellt wird (Abschnitt 3.13).

3.3 Mailﬁlter

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 Bayesfilter stellvertretend für eine Gruppe von statistischen Filtern besprochen.

Regeln

Die Regel-basierte Filterung von Spam kann eine Liste von Wörtern oder reg- ulären Ausdrücken verwenden, die in einer E-Mail nicht vorkommen dürfen. So können Regeln deﬁniert werden, die entweder nur auf den Header, nur auf den Body oder auf die gesamte E-Mail angewendet werden müssen. Diese Regeln kön- nen auch verbunden werden, so dass ein System von Regeln entsteht, das über- prüft werden muss. Diese Lösung kann sehr aufwendig sein, da im einfachsten Fall für jede einzelne Regel die gesamte Nachricht darauf hin ü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 Seite 76 Studienbrief 3 Anti-Spam Techniken

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 Mailﬁlterung.

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änderun- gen der Spam Nachrichten zu entsprechen. Die Erstellung einer Signatur muss entweder manuell erfolgen oder es bedarf einer vorherigen Klassifikation. Die Klas- sifikation sollte von Menschen durchgeführt werden, damit die dabei entstehenden Fehler so gering wie möglich gehalten werden. Signatur-Datenbanken kön- nen dann auch dezentral gehalten werden, damit viele Empfänger von den Sig- naturen 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 Signa- turen zu verteilen.

Auf Signaturen basierende Filter können zwar bessere Ergebnisse liefern, als Regel-basierte, jedoch benötigen beide Methoden menschliches Eingreifen, um die Regeln bzw. Signaturen ständig zu erweitern. Aus diesem Grund sind Fil- ter, die wahrscheinlichkeitstheoretische Ergebnisse verwenden und nicht ständig vom Menschen neu trainiert werden müssen, eine sinnvolle weitere Filtermeth- ode.

Bayes

Für die Filterung von Spam nach statistischen Methoden gibt es verschiedene An- sätze. Die bekannteste Methode geht auf das Bayestheorem (vgl. Gleichung 3.1) des Mathematikers Thomas Bayes (1701-1761) zurück, das erstmalig 1998 in Saha- mi et al.[1998] zur Klassiﬁkation 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 (B|A) × P (A) P (A ∩ B) P (A|B) = = (3.1) P (B) P (B)

wobei P (A ∩ B) der Wahrscheinlichkeit entspricht, dass die Ereignisse A und B gleichzeitig eintreﬀen (vgl. Schickinger and Steger[2002]).

Das Beispiel 3.1 verdeutlicht die Anwendung des Bayestheorems auf Spam Nachrichten. 3.3 Mailﬁlter Seite 77

Beispiel 3.1: Bayestheorem B 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 klassiﬁziert, von denen 700 die Zeichen- kette „cheap watch“ enthalten und weiterhin 1000 E-Mails als Ham klassi- ﬁziert, von denen 2 die Zeichenkette „cheap watch“ enthalten, dann kann P (A|B) berechnet werden mit

700 5000 5000 × 6000 P (A|B) = 702 ≈ 99, 74% 6000 Weiterhin können dann noch nicht klassiﬁzierte Nachrichten mit einer Wahrscheinlichkeit von 99,74% als Spam klassiﬁziert werden, sofern sie die Zeichenkette „cheap watch“ enthalten.

In der Praxis enthalten E-Mails jedoch mehrere Wörter, so dass das Bayestheorem auf beliebig viele Zeichenketten z1, z2, . . . , zn erweitert werden muss:

P (z1 ∧ z2 ∧ ... ∧ zn|A) × P (A) P (A|z1 ∧ z2 ∧ ... ∧ zn) = . (3.2) P (z1 ∧ z2 ∧ ... ∧ zn)

Dabei beschreibt Gleichung 3.2 die Wahrscheinlichkeit dafür, dass eine E-Mail als Spam klassiﬁziert 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 Q i P (zi|zi+1 ∧ ... ∧ zn ∧ A) × P (A) P (A|z1 ∧ z2 ∧ ... ∧ zn) = . (3.3) P (z1 ∧ z2 ∧ ... ∧ zn)

Ein Bayesﬁlter wird weiterhin als naïve bezeichnet, sofern er vollständige stochastische Unabhängigkeit zwischen den Auftreten der einzelnen zi annimmt. In diesem Fall kann Gleichung 3.3 vereinfacht werden zu Q i P (zi|A) × P (A) P (A|z1 ∧ z2 ∧ ... ∧ zn) = . (3.4) P (z1 ∧ z2 ∧ ... ∧ zn)

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 Übungsauf- gabe hilfreich sein.

Insgesamt bieten Mailfilter einige Nachteile. Sie sind zwar einfach zu implementieren und zu warten, jedoch sind sie sehr ungenau, so dass eine fehlerhafte Klas- sifikation nicht selten passiert. Dabei sind vor allem die falsch positiven Ergeb- nisse 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 Mailfil- ter reagiert, indem sie die Spam Nachrichten regulären Nachrichten angleichen. Daher wird im nächsten Abschnitt eine Methode vorgestellt, die nicht nur den Inhalt einer Nachricht zur Klassifikation verwendet. Seite 78 Studienbrief 3 Anti-Spam Techniken

Kontrollaufgabe 3.1: Mailﬁlter K Welche Arten von Mailﬁltern gibt es?

Kontrollaufgabe 3.2: Bayesfilter K Nennen Sie eine intuitive und kurze Definition eines Bayesfilters.

3.4 IP-Sperren

Bei Verbindungen zwischen zwei Teilnehmern im Internet ist die IP-Adresse bei- der 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 Computer 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.4.1), die IP-Adressen von Computern enthalten, von denen bekannt ist, dass sie Spam versenden. Weiße Listen (engl. Whitelisting, vgl. Abschnitt 3.4.2) sind davon genau das Gegenteil. Sie werden dazu verwendet, Ab- sender zu identiﬁzieren, 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.4.3. Hier wird Spam durch technische Schwächen der von Spamversendern genutzten Software erkannt.

3.4.1 Blacklisting

Blacklisting (vgl. Levine[2010]RFC5782 ) 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 Verbindungsaufgabe die IP-Adresse der Gegenseite und muss dann kurzfristig entscheiden, ob der Verbindungsaufbau durch den Ver- sand 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 in Abschnitt 2.4 ab Seite 58 und offene Proxys in Abschnitt 2.5 ab Seite 59) sondern von Botnetzen (vgl. Ab- schnitt 2.9 ab Seite 64) verursacht wird. Botnetze bestehen aber wiederum aus einzelnen Bots, deren IP-Adressen sich bedingt durch Wählverbindungen (Tele- fon bzw. ISDN) oder Zwangstrennungen (DSL) ständig ändern. Es ist somit nicht 3.4 IP-Sperren Seite 79 möglich, eine IP-Adressen, die einmal Spam versendet 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 hat 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 Spam- versender 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. Ab- schnitt 1.4.6 ab Seite 33) herausgestellt. DNS Blacklists (DNSBL damit DNSBL)benötigen, 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 An- frage 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 DNS- BL angehängt. Handelt es sich bspw. beim DNSBL um dnsbl.rub.de, so wird die 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ück gegeben, 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 eﬀek- tiv 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 wurde, 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. Hier- mit 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 Seite 80 Studienbrief 3 Anti-Spam Techniken

bei DNS eﬀektiver 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 somit Server nicht gefunden werden können.

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 Repu- tation ganzer Netze nicht mehr zur Klassiﬁkation 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 speku- lative Aggregation von IP-Adressen.

Abb. 3.1: Der ur- sprü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 Black- list 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 ﬂießen nicht nur 3.4 IP-Sperren Seite 81

Abb. 3.2: Der neue Ansatz, um Blacklists zu erstellen aus Sinha et al.[2010].

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äfti- gen.

Der nächste Abschnitt befasst sich mit einer sehr ähnlichen Technik, dem Whitelisting.

3.4.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 List mit RFC 5782 erwünschten IP-Adressen zur Klassiﬁkation 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 Ver- fügung gestellt wird, so wird in diesem Fall von einer DNS Whitelist (DNSWL 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 Whiltelists 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 Absender- adresse 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 Klas- siﬁkation 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 Seite 82 Studienbrief 3 Anti-Spam Techniken

rigorose Vorgehen führt dazu, dass nur eine fest deﬁnierte 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 vorge- sehen, so kann dieses Vorgehen den Spam vollständig beseitigen. Im Normalfall soll die E-Mail-Adresse aber auch von anderen Nutzern erreichbar sein, was unter ausschließlicher Verwendung des Whitelistings ausgeschlossen ist. Aus diesem Grund sollte das Whitelisting nur in Kombination mit dem Blacklisting oder anderen Techniken verwendet werden.

Der nächste Abschnitt befasst sich mit der letzten vorgestellten Technik zu IP- Sperren, dem Graylisting.

3.4.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 64) stammen. Die Bots wiederum implementieren jedoch nicht die vollständige Funktion- alitä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 22) 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. Unvoll- stä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. Treﬀen diese Annahmen alle zu, so wird die E- Mail angenommen bzw. an den Empfänger weiter geleitet 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 Aktualisierun- gen der Liste kümmern und kann eine Graylist mit relativ wenig Aufwand in seine Konﬁguration einfügen. 3.4 IP-Sperren Seite 83

• Die Hardwareressourcen, die benötigt werden, um zum einen die Liste zu speichern und zu verwalten und zum anderen eintreﬀende E-Mail 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 weiter geleiteten E-Mails anzuwenden, um Nachrichten, die von Bots mit einer vollständigen Implementierung von SMTP ausgehen, weiter zu behandeln.

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 Implemen- tierung 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 Zugangsdat- en 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 RFC 2821 sind. Daher muss ja nach Greylist-Implementierung auch ein Fehlercode zurück gesendet werden, der nicht auf den wahren Grund des Fehler hin- weist. • 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 Server verteilte Datenbank handelt. In einem solchen Szenario kann nämlich nicht ausgeschlossen werden, dass der zweite Zustellversuch auf einem anderen SMTP-Server statt findet.

Ob Graylisting eingesetzt werden soll, das muss der jeweilige Administrator entscheiden und dabei die Vor- und Nachteile gegeneinander abwägen.

3.4.4 Kontrollaufgaben

In diesem Abschnitt befinden sich verschiedene Kontrollaufgabe, die die Inhalte der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffs beitragen sollen.

Kontrollaufgabe 3.3: IP-Sperren I K Was sind IP-Sperren und welche verschiedenen Arten existieren? Seite 84 Studienbrief 3 Anti-Spam Techniken

Kontrollaufgabe 3.4: IP-Sperren II K An welcher Stelle werden IP-Sperren eingesetzt?

Kontrollaufgabe 3.5: Blacklisting I K Welche verschiedenen Arten gibt es, um Blacklisting zu praktizieren?

Kontrollaufgabe 3.6: Blacklisting II K Welche vier Schritte sind beim DNS-basierten Blacklisting notwendig, um eine IP-Adresse zu überprüfen?

Kontrollaufgabe 3.7: Blacklisting III K Nennen Sie Vor- und auch Nachteile für den Einsatz von Blacklists.

Kontrollaufgabe 3.8: Whitelisting K Was ist Whitelisting und welchen Zweck verfolgt es?

Kontrollaufgabe 3.9: Graylisting K Was macht Graylisting im Gegensatz zu White- und Blacklisting zu eine besonderen Art der IP-Sperren und warum kommt es auch ohne externe Di- enstanbieter aus?

Kontrollaufgabe 3.10: Graylisting II K Nenne Sie jeweils zwei Vor- und zwei Nachteile von Graylisting.

Die Lösungen zu den Kontrollaufgaben sind in Abschnitt 3.15 ab Seite 109 zu ﬁnd- en.

3.5 Reputationsverfahren

Verfahren, die nicht den Inhalt einer E-Mail auswerten, sondern Metaeigen- schaften 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 3.5 Reputationsverfahren Seite 85 schwerfällig ist und durch Botnetze relativ leicht umgangen werden kann. Black- listing hat den Nachteil, dass eine IP-Adresse als Ursprung von Spam ausfindig gemacht werden muss, bevor sie geblockt werden kann. Dabei haben viele Com- puter im Internet eine dynamische IP-Adresse wodurch ein vorhandener Eintrag in einer Blacklist nach einem Neuzuweisung einer IP falsch werden kann. Black- listing 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 Klassiﬁzierung von Nachrichten lassen sich in drei Gruppen einteilen. Zum einen werden Eigen- schaften eingeführt, die nur auf einzelnen Netzwerkpaketen beruhen. Dazu kommt die 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. Geodätische Distanz Reguläre E-Mails legen normalerweise einen eher kurzen Weg zurück, da es sich oft um eine Kommunikation handelt, die im gleichen Land statt ﬁndet. Spam dagegen legt weitere Strecken zurück, so dass der Ursprung oft in einem anderen Land oder sogar von einem anderen Kontinent stammt.

2. Die Nachbarschaft der Spam Versender. Nachbarschaft Die von den Autoren der Arbeit aufgestellte These lautet, dass Spam- versender oft von anderen Spamversendern umgeben sind. Diese Behaup- tung wird in viele Arbeiten verwendet und lässt sich auch leicht nachvol- lziehen. 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 Ver- sionsstand 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ür- den dann alle kompromittierten Computer Spam versenden, wodurch die Behauptung bestätigt wird.

3. Die Tageszeit des Spamversandes. Tageszeit 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 Klassiﬁkation denkbar wird.

4. Das Autonome System des Versender. Autonomes System Da nur wenige Autonome Systeme für einen großen Anteil des Spams verantwortlich sind, kann die Nummer des Autonomen Systems als Eigen- schaft zur Klassiﬁkation herangezogen werden.

5. Der Status der einzelnen Ports des Versenders. Port-Status Versender von regulären E-Mails sind im Normalfall Server, die auch gle- Seite 86 Studienbrief 3 Anti-Spam Techniken

ichzeitig 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 ein Klassifikation nach offenen Ports mögliche Spamversender identifizieren.

Weiterhin wurden Merkmale aus einzelnen Nachrichten extrahiert.

1. Die Anzahl der Empfänger.AnzahlEmpfänger Oft werden Spam Nachrichten nicht nur an einen sondern an mehrere Empfänger versendet. Ham hat dagegen meist einen oder wenige Empfänger.

2. Die Größe der E-Mail.E-Mail-Größe 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 wird häuﬁg aus Templates generiert, wodurch die Nachrichten einer Kam- pagne 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 mit berü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 Ra- machandran 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 3.6 Challenge-Response-Verfahren Seite 87 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 Erken- nungsgenauigkeit 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 weiter geleitet, 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.6 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. Dieses Verfahren kann angewendet werden, um einem Anwender eine Informa- tionen zu zeigen, die bspw. von Bots nicht erkannt werden soll. Dazu werden CAPTCHAs (vgl. Abschnitt 2.3.3 ab Seite 52) eingesetzt, bei denen der Anwen- der 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- Response-Verfahren 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 von Ab- sender 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 zwis- chengespeicherte E-Mail dann an den Empfänger weiter geleitet. Erhält ein reg- ulä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.

Mit Hilfe 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 empfangende SMTP-Server erst eine Anfrage an den Versender geschickt werden, die diesen um die Lösung einer Aufgabe bittet. Weit- erhin muss der Versender der ursprünglichen Nachricht Zeit in die Lösung der Aufgabe stecken, bevor seine E-Mail an den Empfänger weiter geleitet 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 einzel- Seite 88 Studienbrief 3 Anti-Spam Techniken

nen 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 unauﬀällig zu agieren. Wird nun die Absender- adresse gefälscht, so erhalten Unbeteiligte die Auﬀorderung zur Lösung einer Aufgabe, was in deren Augen wieder als Spam betrachtet werden kann. • Aufgaben, die 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.

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.7 Erweiterungen des E-Mail-Verfahren

Die Speziﬁkationen 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 Sys- tem 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 Emp- fangs hat (Receiver driven SMTP).

3.7.1 DomainKeys / DKIM

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]RFC6376 ) die aktuelle Fassung im Jahr 2011 veröffentlicht.

Wie in Studienbrief1 ab Seite9 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. Ab- schnitt 1.8 ab Seite 40) 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 3.7 Erweiterungen des E-Mail-Verfahren Seite 89 mithilfe asymmetrischer Kryptographie (vgl. Exkurs 3.2 auf Seite 92) gegenüber dem Empfänger veriﬁziert. 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 öﬀentlichen 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). Diese Header Feld erhält dann Tupel aus Bezeichnern und Werten, die zu Veriﬁkation verwendet werden und ausschließlich aus US-ASCII Zeichen (vgl. Exkurs 1.9 auf Seite 19) bestehen 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 DKIM-Signature: v=1; a={Signaturalgorithmus/Hashalgorithmus}; y c={Kanonisierungsmethode}; d={Domain}; s={Selektor}; h={Liste der verwendeten Header-Felder}; bh={Hashwert des Nachrichten-Bodys}; b={Signatur};

Die wichtigesten 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ön- nen 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 öﬀentliche Schlüssel regelmäßig problemlos ausgetauscht werden kann. Dazu ist auch denkbar, dass für einzelne Benutzer individuelle Schlüssel verwendet werden. Seite 90 Studienbrief 3 Anti-Spam Techniken

Beispiel 3.2: DKIM-Signature B Folgende Zeilen entstammen einer E-Mail, die durch einen SMTP-Server von Google verschickt wurde und eine gültige DKIM Signature enthält.

Return-Path: [..] 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 private 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 Head- er 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-Signature untersucht, wobei eine DNS (vgl. Abschnitt 1.4.6 ab Seite 33) An- frage verschickt wird, die nach dem TXT Eintrag der im Header als Absender aufgeführte Domain fragt. Als Antwort erhält der SMTP-Server dann den öf- fentlichen 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 von Sender zum Empfänger nicht verändert wurde. Dies natürlich nur unter der Vorausset- zung, 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 den 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 Do- main Signing Practices (ADSP), beschreibt RFC 5617 (vgl. Allman et al.[2009]). 3.7 Erweiterungen des E-Mail-Verfahren Seite 91

Beispiel 3.3: DKIM Veriﬁkation B Für die aus Beispiel 3.2 erhaltene DKIM Signature wird nun der öﬀentliche 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 Phish- ing 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- Mail Client des Nutzers angezeigt werden. Prinzipiell müssen keine Erweiterun- gen den Client betreﬀend 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.7.4 ab Seite 96) sehr gering. DKIM bietet zwar keinen direkt Schutz vor Spam (vgl. Levine[2009]), es kann jedoch als Ein- ﬂuss für Reputationssysteme (vgl. Abschnitt 3.5 ab Seite 84) 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 E- Mail doch Spam ist. Besonders E-Mails, die HTML-Quelltext enthalten und darin Bilder einbinden, können einfach zum Versand von Spam verwendet werden. Ein 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 DKIM- Signatures 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 und DNS wird entsprechend stärker belastet. Seite 92 Studienbrief 3 Anti-Spam Techniken

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 den selben Schlüssel. Im Gegensatz dazu verwenden asymmetrische Verfahren einen Schlüssel zum Verschlüs- seln und einen anderen Schlüssel zum Entschlüsseln. Asymmetrische Ver- fahren werden auch Public-Key Verfahren genannt, da ein Anwendungsfall darin besteht, dass einer der beiden Schlüssel öﬀentlich (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üs- sel über einen unsicheren Kanal verschickt werden kann.

Nichtabstreitbarkeit Hiermit kann sichergestellt werden, dass eine Nachricht von einer Person stammt, die über einen geheimen Schlüssel verfügt.

Identiﬁkation Verfahren können die Identiﬁkation von Personen oder Com- putern sicherstellen.

Verschlüsselung Nachrichten können entsprechend verschlüsselt werden.

3.7.2 SPF (Sender Policy Framework)

SPF wurde in RFC 4408 (vgl. Wong and Schlitt[2006]) spezifiziert und durch RFC 6652 (vgl. Kitterman[2012]RFC6652 ) aktualisiert. Das System gilt als Alternative zu DKIM (vgl. Abschnitt 3.7.1 ab Seite 88), da es ebenfalls dazu verwendet werden soll die Absenderadresse zu verifizieren und dafür auf DNS aufsetzt. Im Gegen- satz 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 wurden 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 zu versorgen. Der Aufbau des TXT bzw. SPF Eintrags wird dabei im folgende Exkurs 3.3 beschrieben, Beispiel 3.4 zeigt einen konkreten DNS Eintrag. 3.7 Erweiterungen des E-Mail-Verfahren Seite 93

Exkurs 3.3: SPF DNS Einträge E Der DNS Eintrag, der zur Funktionsfähigkeit von SPF benötigt wird, ist eine Zeichenkette, die aus vielen Teilen bestehen kann, die jeweils durch Leerze- ichen 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ück gegeben.

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ück gegeben.

RFC 4408 definiert vier Bedingungen (engl. qualifier), die zu einer Direktive das erwünschte Verhalten beim Eintreffen spezifizieren:

Bedingung Name Beschreibung + Pass Der Sender ist autorisiert zum Versand einer Nachricht. - Fail Der Sender ist nicht zum Nachrichtenver- sand autorisiert. ~ SoftFail Die Nachricht sollte irgendwo zwischen - und ? behandelt werden. ? Neutral Der Besitzer der Domain kann oder will über solche IP-Adressen keine Aussage treﬀen.

Ist keine Bedingung angegeben, so wird der Standard-Fall Pass verwendet. Dazu besteht eine Direktive weiterhin aus einem Mechanismus:

Mechanismus Bedingung für das Eintreﬀen der Direktive all Triﬀt immer zu und sollte als letzte Direktive den Standardfall beschreiben. a Ein A oder AAAA-Record der befragten Domain enthält die IP-Adresse des Senders. mx Ein MX-Record der befragten Domain enthält die IP-Adresse des Senders. ip4 Die angegebene IPv4-Adresse ist oder enthält die IP-Adresse des Senders. ip6 Die angegebene IPv6-Adresse ist oder enthält die IP-Adresse des Senders. include Verweist auf eine andere Liste. Seite 94 Studienbrief 3 Anti-Spam Techniken

Beispiel 3.4: SPF Eintrag für den Google Mail-Dienst B Der SPF Eintrag für den Google Mail-Dienst kann über den Befehl

$ host -t TXT _spf.google.com

erfragt werden. Aktuell wird als Antwort die folgende Zeichenkette zurück gegeben:

_spf.google.com descriptive text "v=spf1 y include:_netblocks.google.com y 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: Auﬂösung einer include Direktive B Da der SPF DNS Eintrag aus Beispiel 3.4 zwei include Direktiven enthält, müssen diese wie folgt weiter aufgelöst werden:

$ host -t TXT _netblocks.google.com _netblocks.google.com descriptive text "v=spf1 y ip4:216.239.32.0/19 ip4:64.233.160.0/19 y ip4:66.249.80.0/20 ip4:72.14.192.0/18 y ip4:209.85.128.0/17 ip4:66.102.0.0/20 y ip4:74.125.0.0/16 ip4:64.18.0.0/20 y ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all"

$ host -t TXT _netblocks6.google.com _netblocks6.google.com descriptive text "v=spf1 y ip6:2607:f8b0:4000::/36 ip6:2a00:1450:4000::/36 ?all"

Der empfangende SMTP-Server kann nun die Direktiven aus der Antwort der DNS Anfrage 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 Funktion- alität im empfangenden SMTP-Server vorhanden sein. Weiterhin müssen die entsprechenden DNS Einträge gepﬂegt werden. SPF kann daher auch nicht vor Spam schützen, da auch Versender von Spam ihre eigenen DNS Einträge entsprechend pﬂegen 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. 3.7 Erweiterungen des E-Mail-Verfahren Seite 95

3.7.3 Sender ID

RFC 4406 (vgl. Lyon and Wong[2006] das experimentelle Protokoll RFC 4406)beschreibt 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 Speziﬁzierung in RFC 4406 durch Microsoft und die MARID (MTA Authorization Records In DNS) IETF (Internet Engineering Task Force) Gruppe entwickelt. Jedoch stellte Mi- crosoft eigene Patente nicht für die Verwendung unter bestimmten Open Source Lizenzen bereit, weshalb sich MARID von der Entwicklung zurück zog (vgl. Er- mert[2004] und Wilkens[2006]). Sender ID wird aktuell von Microsoft unter der Bezeichnung Sender ID Framework (SIDF) verwendet und entwickelt.

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] RFC 4407).

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 Aus- prä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 Mi- crosoft 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 Web- mail. 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. Seite 96 Studienbrief 3 Anti-Spam Techniken

4. Da für einige Domain bereits Reputationsinformationen vorliegen, werden diese für die Klassiﬁkation der E-Mail mit berücksichtigt.

5. Basierend auf den erhaltenen und ausgewerteten Informationen wird die E-Mail dann klassiﬁziert und an den Benutzer zugestellt.

Für weitere Informationen fasst Microsoft Corporation[2008] die verfügbaren Ressourcen zum Sender ID Framework zusammen.

3.7.4 Hashcash

Hashcash ist ein von Adam Back im Jahr 1997 vorgeschlagenes und 2002 in Back [2002] speziﬁziertes 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, Proof-of-Work Systemder die Funktionalität beschreibt. Hashcash ist ein , bei dem der Versender einer E-Mail nachweist, dass er eine bestimmte Arbeit geleistet hat. Es ist so speziﬁziert, dass der Empfänger mit einem sehr geringen Aufwand nachprüfen kann, ob der Sender diese Arbeit wirklich verrichtet hat.

Wie bereits in Studienbrief2 zu Spam-Techniken ab Seite 48 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 Ver- sand 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 Internetanschluss zum Prozessor des versendenden Com- puters. Der E-Mail Client des Versender 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 Da- tum sowie eine Zufallszahl.

2. Für die so erzeugte Zeile wird der SHA-1 Hash (vgl. Eastlake and Jones RFC 6234 [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 Millionen 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 Valid- ität der E-Mail zu veriﬁzieren.

1. Haben die ersten 20 Stellen des SHA-1 Hashes der Headerzeile H-Hashcash: den Wert Null?

2. Ist die Diﬀerenz aus dem in der Headerzeile angegebene Datum und dem Datum der Überprüfung kleiner als 2 Tage? 3.7 Erweiterungen des E-Mail-Verfahren Seite 97

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 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 geﬁltert werden. 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.7.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 Differen- tiated Mail Transfer Protocol (DMTP) als einfache Erweiterung zum SMTP, durch das der Empfänger mehr Möglichkeiten hat den E-Mail-Versandprozess zu bee- influssen. Konkret soll der Empfänger den Sender in die Kategorien allowed, denied und unclassified klassifizieren können, um den Versand jeder Kate- gorie einzeln bearbeiten zu können. Weiterhin sollen DMTP Empfänger in der Lage sein, für den Fall das ein Sender als unclassified gilt, Nachrichten auf dem Server des Senders zu speichern, um diese erst bei Bedarf abzuholen. Die Klassi- fikation 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 Nachrichten- behandlung.

Der Ansatz hat den Status eines Entwurfs jedoch nie verlassen und wurde ab 2006 nicht weiter verfolgt. Seite 98 Studienbrief 3 Anti-Spam Techniken

3.7.6 Kontrollaufgaben

In diesem Abschnitt befinden sich verschiedene Kontrollaufgabe, die die Inhalt der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffs beitragen sollen.

Kontrollaufgabe 3.11: DKIM I K Wozu wird DKIM verwendet und welches Problem kann das Verfahren nicht lösen?

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 Head- erzeile H-Hashcash: bereits in seiner Datenbank beﬁndet. Welche beiden Szenarien können hier eingetroﬀen sein? 3.8 Echtzeit URL Filterung Seite 99

Kontrollaufgabe 3.19: Hashcash III K Nennen Sie jeweils zwei Vor- und zwei Nachteile von Hashcash.

Die Lösungen zu den Kontrollaufgaben sind in Abschnitt 3.15 ab Seite 109 zu ﬁnd- en.

3.8 Echtzeit URL Filterung

Die zu Werbezwecken versendeten Spam Nachrichten enthalten oft URLs (vgl. Berners-Lee et al.[1994] auf Phishing Seiten führen oder auf Mal- RFC 1738),die ware 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 Di- entes.

Abb. 3.5: Die generelle Funktionsweise des Echtzeit-Spam- Filterdienstes 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ück schicken, ob die verlinkten Seite bspw. für Phishing verantwortlich ist, Malware verbreitet oder auch als gutartige Seite einstuft werden kann.

Abb. 3.6: Das Flussdia- gramm von Monarch aus Thomas et al. [2011].

Monarch arbeitet, wie Abbilding 3.6 verdeutlicht, in vier Schritten:

1. Zuerst ﬁnde 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 klassiﬁziert werden kön- nen.

2. Danach ﬁndet eine Sammlung der Merkmale statt. Dazu werden die Seiten, auf die die URLs zeigen, automatisch durch eine angepasste Version von

1https://twitter.com/ 2https://www.facebook.com/ Seite 100 Studienbrief 3 Anti-Spam Techniken

Firefox besucht und das Verhalten sowie der Inhalt der Seite werden gespeichert. Zum Verhalten zählen bspw. Java Script Aktivitäten. Auch die Infras- truktur, die zum Hosting der Seite verwendet wird, wir 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 Liste von Wörtern abgelegt. Alle genannten Daten werden in Vektoren gespeichert, die im nächsten Schritt weiter verarbeitet werden können.

4. Der letzte Schritt ist dann die Klassifikation. Ein offline Training stellt sicher, dass die Reaktionszeit des System 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 Klassiﬁkation benötigt. Diese Ergebnisse wurden erreicht, indem der Klassiﬁkator mit 1,2 Millionen Spam Nachrichten, 567.000 als schadhaft gekennzeichneten Twitter URLs und 9 Millio- nen regulären URLs angelernt wurde.

Kontrollaufgabe 3.20: Monarch K Beschreiben Sie, wie Monarch funktioniert und wie es auch zur Erkennung von Spam genutzt werden könnte.

3.9 Netzwerk-basiertes Clustern

IP-basiertes Blacklisting (vgl. Abschnitt 3.4.1 ab Seite 78) ist eine bekannte und bewährte Methode, um Spam zu ﬁltern. 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 Cluster- basierte 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 senken. • Ein von den Autoren erarbeitetes System, das BGP Präfixe und DNS Infor- mationen 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.13 ab Seite 108) eingebaut werden und hilft somit bei einer besseren Klassiﬁzierung von Spam.

3.10 Erkennung von Botnetzen

Die Erkennung von Botnetzen ist ein wichtiges Mittel ist im Kampf gegen Spam, da Botnetze als Hauptverursacher für ca. 85% des Spam verantwortlich sind 3.10 Erkennung von Botnetzen Seite 101

(vgl. Symantec Corporation[2012]). Daher werden in diesem Abschnitt einige Ar- beiten betrachtet, die sich mit der Erkennung von Botnetzen beschäftigen.

BotMagniﬁer

In Stringhini et al.[2011] entwickeln die Autoren eine neue Technik, um die Iden- tifikation und Verfolgung von Bots aus bestimmten Botnetzen zu erleichtern. Eine bewährte Methode, um Bots zu identifizieren, besteht darin, Spam-Traps einzuset- zen 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 Bot- netze oft nur Nachrichten an bestimmte Nutzer aus eine 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 Botnet- zen 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 Spam- bots und der Protokolle gesucht. Diese Überschneidungen werden dann analysiert und daraus Profile erstellt. Im zweiten Schritt werden 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 An- zahl der fehlerhaften Treffer (Falsch Positiv) 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 BotMagniﬁer gefunden werden, können daraufhin bspw. beim Blacklisting (vgl. Abschnitt 3.4.1 ab Seite 78) verwendet werden, um bessere Ergebnisse bei der Klassiﬁkation vom Spam zu erzielen.

BotSniﬀer

Einen alternativen Ansatz zu BotMagnifier liefern Gu et al.[2008] mit BotSnif- fer. 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 erkenne, 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 raum- und zeitlichen Korrelationen unterliegt und somit Ähnlichkeit- en 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 Seite 102 Studienbrief 3 Anti-Spam Techniken

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 Grup- pierung der Muster verwendet werden. Abbildung 3.8 visualisiert dazu eine Über- sicht ü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 Erken- nung von Botnetzen zum Stand der Veröffentlichung nicht zur Verbesserung der Ergebnisse beitrugen. Weiterhin werden Verbindungen zur normalen Servern wie Google oder Yahoo durch eine statisches Whitelisting entfernt. Daraufhin werden zwei Module auf 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 ausge- führt.

Abb. 3.8: Architektur- übersicht von Bot- Sniﬀer aus Gu et al. [2008].

Die Autoren versuchen IRC und HTTP Verbindungen in den Daten zu ﬁnden, 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 IRC Sitzun- gen durch drei Nachrichten (PASS, NICK und USER) bestimmt ist, die in RFC 1459 3.11 Botnetz Übernahme Seite 103

(vgl. Reed[1993]) deﬁniert sind. HTTP Datenströme können ähnlich leicht erkan- RFC 1459 nt 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] RFC 1945). 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 Erken- nung von IRC Nachrichten und Antworten dar. Dazu werden die IRC Daten- ströme weitergeleitet und auf ein- und ausgehenden IRC PRIVMSG Nachrichten hin analysiert. Diese Modul speichert ebenfalls Informationen in der Datenbank zum Aktivitätsprotokollieren ab, generiert aber auch direkt Berichte. Berichte werden auch durch ein Korrelationsmodul erstellt, das auf die Einträge aus der Datenbank zugreift.

Mit Hilfe dieser Mechanismen können im Datenverkehr die Command and Con- troll Nachrichten von Botsnetzen gefunden und die Botnetze somit ausﬁndig gemacht werden.

3.11 Botnetz Übernahme

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 Tor- pig (auch unter den Namen Sinowal und Anserin bekannt) untersucht. Torpig sammelt sensible Informationen der befallenen Computer wie Konto- und Kred- itkarteninformationen. Es basiert auf dem Rootkit Mebroot3, der den Master Boot Record erweitert und somit bei jedem Systemstart noch vor dem Betriebssys- tem 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 Botnet- zes durchgeführt werden, indem ein Bot in einer kontrollierten Umgebung ausge- fü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 Ent- führung des kompletten Botnetzes durch die Übernahme eines Command and Control Servers. Dies ist zum einen durch die physikalische Übername des Com- mand and Control Server möglich, wozu aber bekannt sein muss, wo der Server gehostet wird, was bei dezentralen Lösungen sehr schwierig ist, oder die Aus- nutzung der Domain Flux Technik, die von Torpig eingesetzt wird.

Domain Fluxist eine Technik, bei der jeder einzelne Bot unabhängig von den Domain Flux anderen Bots periodisch eine Liste von Domains erstellt, zu denen er einen Verbindungsaufbau versucht. Der erste Server, der bei einem Verbindungsaufbau- versuch eine valide Antwort zurück meldet, wird als echter Command and Con- trol Server betrachtet. Der Bot verbindet sich daraufhin mit dem Server und wartet auf Befehle. Durch Reverse Engineering (vgl. Exkurs 3.4 auf Seite 105) des Domain Erstellungs Algorithmus konnten im Vorhinein bereits die entsprechenden Do- mains registriert werden, wodurch der Botmaster dazu keine Möglichkeit mehr

3Eine genaue Analyse von Mebroot kann in Kleissner[2009] gefunden werden. Seite 104 Studienbrief 3 Anti-Spam Techniken

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 inﬁzierten Computer, 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 Torpig Netzwerk Infrastruk- tur 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 verwundbare aber legitimen Webseiten (1) modifiziert, damit das Opfer speziellen JavaScript Code (2) aufruft. Der JavaScript Code wiederum ruft dann Code von einem Drive-By-Download 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 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 Zugriﬀsschutz 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 beeinﬂussen. 3.12 Botnet Judo: Automatische Generierung von Spam Signaturen Seite 105

Exkurs 3.4: Reverse Engineering E 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 Na- men für Variablen oder Funktionen bei der Erstellung der Software nicht be- folgt werden. Generell ist eine Quellcodeanalyse 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. Hi- erbei 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äuﬁg bei der Analyse von Protokollen eingesetzt.

2. Mit Hilfe eines Disassember wird versucht aus dem Maschinencode ein Programmcode in Assemblersprache zu erzeugen. Assembler- sprache ist zwar immer noch eine Sprache, die sehr nah zur Maschinen- sprache 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.

Kontrollaufgabe 3.21: Domain Flux K Wofür wird bei Torpig die Domain Flux Technik verwendet?

3.12 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, mit Hilfe derer alle E-Mails geﬁltert werden können, die durch das selbe 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 erschw- erten 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 Betreﬀ oder Seite 106 Studienbrief 3 Anti-Spam Techniken

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 Sys- temüberblick aus Pit- sillidis 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 System einsetzen lassen.

Da der Algorithmus zur Erstellung der Signatur als wichtiger Bestandteil der Ar- beit angesehen werden kann, wird diese im Folgenden anhand des Beispiels in Abbildung 3.11 beschrieben.

Abb. 3.11: Eine Beispielinstanz des Signatur Erstellungs Algorithmus aus Pit- sillidis 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 AnkerAnker 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 konfiguri- erender 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 3.12 Botnet Judo: Automatische Generierung von Spam Signaturen Seite 107

Schritt versucht die variable Zeichenfolge zwischen zwei Ankern durch ein Makro Makro zu deﬁnieren. 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 prade ein Wörterbuch und fenallies und nuserro ein zweites Wörterbuch. Theoretisch kann jedes Makro durch ein Wörterbuch-Makro beschrieben werden, jedoch muss der Algorithmus dazu erst alle möglichen Einträge des Wörterbuchs gesehen haben. Kann eine Ze- ichenkette 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.

Die so erzeugten Signaturen müssen dann den Datenbestand aller Signaturen aktualisieren. Um diese 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 Training-Puffer hinzugefügt und es wird so lange gewartet, bis der Puffer voll ist. Der Größe des Puffers wird durch den Parameter k bestimmt. Die richtige Wahl von k ist von essentieller Bedeutet: 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 konnte, der für alle Botnetze gute Ergebnisse liefert, wurden zwei zusätzliche Mechanismen implementiert, die zur Lösung dieses Problems beitragen sollen.

Der erste Mechanismus ist Second Chance. In vielen Fällen kann eine gute Sig- Second Chance Algo- natur bereits unter Beachtung nur weniger E-Mails erzeugt werden, auch wenn rithmus mehr Nachrichten benötigt werden würde, 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 zweite Mechanismus wird ein Pre-Clustering verwendet Gegensatz Pre-Clustering.Im zu Second Chance 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 Skelett- Signaturen gruppiert. Dabei ist eine Skelett-Signatur zu einer reinen Skelett-Signatureineähnlich Anker-Signatur, 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 Anker-Signatur 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 Skelett-Signatur erzeugt. Sobald der Trainings-Puffer einer Skelett-Signatur 10 E-Mails enthält wird daraus eine normale Signatur erzeugt. Seite 108 Studienbrief 3 Anti-Spam Techniken

So muss nur klargestellt werden, dass mindestens die ersten 10 E-Mail von einem neuen Template unvermischt mit anderen Templates eintreﬀen.

Insgesamt bietet der vorgestellte Ansatz also eine gute Möglichkeit, um Spam zu ﬁltern, benötigt dafür jedoch einige Voraussetzungen, die nicht immer einfach zu erfüllen sind.

Kontrollaufgabe 3.22: BotMagnifier und BotSniffer K Welche Annahme über Botnetze wird sowohl bei BotMagnifier als auch bei BotSniffer verwendet?

Kontrollaufgabe 3.23: Botnet Judo I K 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 K Wie funktioniert der Update-Mechanismus und warum ist eine Aktual- isierung der Signaturen wichtig in diesem Zusammenhang?

Kontrollaufgabe 3.25: Botnet Judo III K Wozu werden die Parameter q und k benötigt?

3.13 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 vom SpamAssassin basiert auf der Programmiersprache Perl6 und kann von jedem Nutzer unter Beachtung der Lizenzbedingen verändert und weit- erentwickelt 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. Eine Modul kann einer Nachricht sowohl einen negativen als auch einen positiven Punktewert zuweisen, wobei negative Punktewerte die Nachricht als Ham klassiﬁzieren und positive Punktewerte Spam anzeigen. Die Punkte der einzelnen Module werden aufaddiert und gelten dann als Klassiﬁkation der Nachricht.

4http://www.apache.org/licenses/LICENSE-2.0.html 5http://www.apache.org/ 6http://www.perl.org 3.14 Zusammenfassung Seite 109

SpamAssassin vereint viele in diesem Studienbrief beschriebene Techniken. So wird bspw. ein DNS-basiertes Black- und Whitelisting eingesetzt (vgl. Ab- schnitt 3.4 ab Seite 96). Mit Hilfe von Hashcash (vgl. Abschnitt 3.7.4 ab Seite 96) 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.7.2) und die DKIM Signaturen (vgl. Abschnitt 3.7.1 ab Seite 88) ausgewertet. Die Software verfügt weiterhin über einen eigenen lernfähigen Bayesfilter (vgl. Ab- schnitt 3.3 ab Seite 75) und verwendet dazu eine Menge von Regeln zur Klassifika- tion. Diese Regeln können wiederum in einen deterministischen endlichen Auto- maten transformiert werden, um eine schnellere Verarbeitung zu ermöglichen.

Insgesamt kann SpamAssassin in viele vorhandene SMTP-Server eingebaut werden.

3.14 Zusammenfassung

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 Spam- Wahrscheinlichkeiten zur Klassifikation verwenden. Daraufhin wurden IP- Sperren betrachtet und gezeigt, unter welchen Annahmen Spam blockiert (Black- listing) und Ham direkt an den Empfänger weitergeleitet werden kann (Whitelist- ing). Dann wurden Verfahren besprochen, die auf der Reputation des Sender basieren oder den Sender dazu auffordern eine Aufgabe zu lösen, bevor die ver- sandte Nachricht an den Empfänger zugestellt wird. Erweiterungen des E-Mail- Verfahren 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 Clustern 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 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 Softwareprodukt kurz vorgestellt, das weit verbreitet ist und eine Vielzahl an hier behandelten Techniken verwendet.

3.15 Lösungen zu den Kontrollaufgaben

Kontrollaufgabe 3.1 auf Seite 78

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 Seite 110 Studienbrief 3 Anti-Spam Techniken

die Spam-Wahrscheinlichkeit bestimmt werden, sofern eine E-Mail gewisse Be- griﬀe enthält.

Kontrollaufgabe 3.2 auf Seite 78

Bayesﬁlter ermöglichen die Vorhersage ob eine E-Mail Spam ist, wenn sie bestimmte Wörter enthält und bieten dazu eine bestimmte Wahrscheinlichkeit.

Kontrollaufgabe 3.3 auf Seite 83

IP-Sperren sich Mechanismen, die aufgrund der IP-Adresse einer anfragenden Verbindung darüber eine Aussage treﬀen, ob die IP-Adresse zu einem Comput- er gehört, der Spam versendet oder nicht. Es existieren drei Arten von IP-Sperren, das Blacklisting, das Whitelisting und das Graylisting.

Kontrollaufgabe 3.4 auf Seite 84

Sinnvollerweise werden IP-Sperren in SMTP-Servern eingesetzt. SMTP spez- iﬁziert, dass ein Ablehnen einer E-Mail geschehen muss, noch wären die Verbindung zwischen Client und Server geöﬀnet ist. Eine einmal angenommene E-Mail soll demnach auch zum 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.

Kontrollaufgabe 3.5 auf Seite 84

Blacklisting kann auf der einen Seite lokal praktiziert werden. Hier kann der SMTP-Server sich selber um eine Liste kümmern, die er bspw. durch Reputa- tionsverfahren 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 Pro- tokoll für die Anfrage ob ein Eintrag in der Liste vorhanden ist etabliert.

Kontrollaufgabe 3.6 auf Seite 84

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 Treﬀen in der Liste des Servers anzeigt, oder kein Daten- satz, 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.

Kontrollaufgabe 3.7 auf Seite 84

Blacklists können einfach implementiert werden und sind gut dazu geeignet Spammer zu blockieren, die ihren 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 3.15 Lösungen zu den Kontrollaufgaben Seite 111 somit nicht alle Verbindungsanfragen von Spammern blockieren. Als problematisch stellt sich aber auch die Zweckentfremdung von DNS für die Spambekämp- fung dar, da DNS somit ein mögliches Ziel für Spammer wird, die das System stören könnten, um daraufhin eﬀektiver Spam versenden zu können.

Kontrollaufgabe 3.8 auf Seite 84

Beim Whitelisting wird im Gegensatz zum Blacklisting nicht eine Liste mit Spam- versendern gepﬂegt, 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.

Kontrollaufgabe 3.9 auf Seite 84

Beim Graylisting werden beim Zustellversuch IP-Adresse, Absender-Adresse im E-Mail-Header 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.

Kontrollaufgabe 3.10 auf Seite 84

Graylisting bietet den Vorteil, dass es für den Administrator des SMTP-Servers einfach zu installieren und zu konﬁgurieren 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 Zustel- lung durch das Verfahren verzögert wird. Weiterhin bietet Graylisting keinen vollständigen Schutz gegen Spam. Es baut auf einer unvollständigen Implemen- tierung der E-Mail-Software von Spam verbreitenden Bots auf, die prinzipiell ohne große Probleme in diesem Punkt vervollständigt werden kann.

Kontrollaufgabe 3.11 auf Seite 98

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 verschlüsselt mit dem privaten Schlüssel der Domain enthält. Der empfangende SMTP-Server kann dann per DNS den öf- fentlichen Schlüssel anfordern und den selber erstellten Hash mit dem entschlüs- selten 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 DKIM-Signature enthalten, nicht automatisch als Ham klassifiziert werden, da Spammer auch gültige DKIM-Signaturen an ihre E-Mails anhängen Seite 112 Studienbrief 3 Anti-Spam Techniken

können, sofern sie den DNS Eintrag zu der zum Versand verwendeten Domain verändern können.

Kontrollaufgabe 3.12 auf Seite 98

DKIM ist auf der einen Seite für den Benutzer transparent, da alle Änderungen und Veriﬁkationen 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 Signa- ture 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-Angriﬀ das Verfahren gestört werden kann.

Kontrollaufgabe 3.13 auf Seite 98

SPF ist ähnlich wie DKIM ein System zur Veriﬁkation von E-Mails. Dabei wird bei SPF allerdings untersucht, ob der Versender die Berechtigung hat für die Ab- senderadresse 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.

Kontrollaufgabe 3.14 auf Seite 98

Direktiven werden benötigt, um auszuwerten, ob eine IP-Adresse zum Versenden einer E-Mail mit einer bestimmten Absenderadresse autorisiert ist. Die Direktiv- en werden auf die IP-Adresse des Versenders angewendet und die zur Direktive gehörende Bedingung gibt bei einem Treﬀer an, wie mit der E-Mail weiter verfahren werden soll.

Kontrollaufgabe 3.15 auf Seite 98

Die ?-Bedingung soll für IP-Adressen zutreﬀen, bei denen der Besitzer der Do- main explizit erklärt, dass es zu diesen IP-Adressen keine Aussage treﬀen kann oder will. Die Antwort soll vom Server wie eine leere Antwort behandelt werden.

Kontrollaufgabe 3.16 auf Seite 98

Zur Veriﬁzierung des Senders wird beim Sender ID Framework nicht nur die IP des Absenders verwendet, sondern auch die Purported Responsible Address (PRA).

Kontrollaufgabe 3.17 auf Seite 98

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. 3.15 Lösungen zu den Kontrollaufgaben Seite 113

Kontrollaufgabe 3.18 auf Seite 98

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.

Kontrollaufgabe 3.19 auf Seite 99

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.

Kontrollaufgabe 3.20 auf Seite 100

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 Klas- siﬁkation der E-Mail eingesetzt wird.

Kontrollaufgabe 3.21 auf Seite 105

Beim Torpig Botnetz wird die Domain Flux Technik eingesetzt, damit die einzelnen Bots den Command und Control Server ﬁnden. Da es sich bei Torpig um eine Peer-To-Peer Command and Control Struktur handelt, kann es mehrere Com- mand and Control Server geben, mit denen sich die Bots verbinden. Daher wird eine Technik benötigt, um immer den aktuellen Server zu ﬁnden.

Kontrollaufgabe 3.22 auf Seite 108

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 ähn- lichem Verhalten zu erstellen, die dann einem Botnetz zugewiesen werden kön- nen.

Kontrollaufgabe 3.23 auf Seite 108

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 Seite 114 Studienbrief 3 Anti-Spam Techniken

Nachrichten ausﬁndig zu machen. Genauso ist es wichtig, dass die Nachricht- en nicht von vielen unterschiedlichen Templates stammen. Sonst ist eine Zuord- nung 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.

Kontrollaufgabe 3.24 auf Seite 108

Bei dem Update-Mechanismus werden bereits fertige Signaturen nachträglich verändern, sofern E-Mails erkannt werden, die durch diese Signatur erkannt werden, sofern die Makros deaktiviert sind. Eine Aktualisierung ist in diesem Zusam- menhang wichtig, da die Anzahl der Signaturen immer möglichst klein gehalten werden sollte, damit eine Erkennung auch in annehmbarer Zeit möglich ist.

Kontrollaufgabe 3.25 auf Seite 108

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, jedoch nicht als Anker taugen. 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.

3.16 Übungen

Übung 3.1: Bayestheorem I Ü Sie haben 12.004 E-Mails als Spam klassiﬁziert, von denen 3.182 die Ze- ichenkette online pharmacy enthalten. Weiterhin haben sie 1.045 E-Mails als Ham klassiﬁziert, 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: Bayestheorem II Ü Stellen Sie sich vor, dass die Spam-Wahrscheinlichkeit für eine bestimmte Kombination von Begriﬀen nur bei 70% liegt. Wie kann mit einem solchen Wert umgegangen werden, um in sinnvoll zu nutzen? 3.16 Übungen Seite 115

Übung 3.3: Bayestheorem III Betrachten Sie folgende Wortverteilungen für Spam und Ham: Ü

Wort today shipping available medications here Spam 7.513 8.863 3.865 2.564 6.749 Ham 232 140 205 39 81

Gehen Sie davon aus, dass die obigen Häufigkeiten in 10.000 Spam Nachrichten und 1.000 Ham Nachrichten enthalten sind. Berechnen Sie mit Hilfe des naïven Bayesfilters jeweils die Spam-Wahrscheinlichkeiten für E-Mails, die die folgenden Begriffe enthalten:

1. today, available und here.

2. shipping

3. today, shipping, available, medications und here

Übung 3.4: Mailﬁlter Beschreiben Sie welche Arten es von Mailﬁltern gibt und aus welchem Ü Grund diese nicht das gesamte Aufkommen an Spam beseitigen können.

Übung 3.5: Blacklisting I Finden Sie heraus welche Anbieter es für Blacklisting gibt. Wie ﬁnanzieren Ü 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.4.3 auf Seite 82 wurde festgestellt, dass Graylisting eigentlich Ü nicht kompatibel zur RFC 2821 (vgl. Klensin[2001]) ist. Ist es denn zu der ak- tuelleren Speziﬁzierung von SMTP, der RFC 5321 (vgl. Klensin[2008]) kompatibel?

Übung 3.8: DKIM-Signature Betrachten Sie RFC 6376 (vgl. Crocker et al.[2011] und ﬁnden Sie heraus, was Ü eine Kanonisierungsmethode (engl. Canonicalization Algorithm) ist und aus welchem Grund DKIM eine solche Funktionalität benötigt. Seite 116 Studienbrief 3 Anti-Spam Techniken

Ü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 SPF Eintrag in Beispiel 3.5 auf Seite 94 für IPv4 und IPv6 aufteilt?

Übung 3.11: SPF III Ü Aus welchem Grund existiert die Bedingung SoftFail für SPF DNS Direktiv- en? 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 Responsi- ble Address (PRA) nach RFC 4407 (vgl. Lyon[2006]) mit eigenen Worten.

Ü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 Schaltun- gen alle 24 Monate verdoppelt (Moores Gesetz) und sich dies für Computer Prozessoren 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 Diﬀerenz aus aktuellem Datum und dem in der Headerzeile eingetragenen Datum maximal 2 Tage betragen darf, damit die Nachricht veriﬁziert 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? 3.16 Übungen Seite 117

Ü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 weiter verfolgt wurde?

Übung 3.18: Monarch Untersuchen Sie welche Merkmale in Thomas et al.[2011] zur Klassi- Ü ﬁzierung von gutartigen oder schadhaften Webseiten herangezogen werden. Welche dieser Merkmale können auch für E-Mails zur Spamklassiﬁkation verwendet werden?

Übung 3.19: Torpig Domain Generierungs Algorithmus Betrachten Sie den Algorithmus zur Generierung von Domain aus Stone- Ü Gross et al.[2009]. Erzeugen Sie eine Domain für den heutigen Tag.

Übung 3.20: BotMagniﬁer Verschaﬀen Sie sich mit Hilfe einer Suchmaschine Ihrer Wahl Zugang zu Ü Stringhini et al.[2011]. Finden Sie heraus, von wem die Autoren die Transak- tionenslisten erhalten haben.

Übung 3.21: BotSniﬀer Betrachten Sie Gu et al.[2008] und ﬁnden 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 ﬁnden.

Übung 3.23: Botnet Judo II Können Sie sich vorstelle 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 118 Studienbrief 4 Rechtslage

Studienbrief 4 Rechtslage

4.1 Lernziele

Sie kennen die Gesetze, die sich mit dem Spamversand in Europa und den USA beschäftigen. Sie können weiterhin nach Strafrecht und Zivilrecht Konsequenzen für Spammer abschätzen.

4.2 Einleitung

In diesem Studienbrief werden abschließend zum Modul rechtliche Aspekte von Spam behanldent. Dazu wird zuerst wiederholend kurz auf die Ursache von Spam, die durch Spam entstehenden Kosten und das Vorgehen der Spammer eingegangen. Daraufhin folgt eine Betrachtung des Datenschutzrechtes sowie der Anti-Spam Gesetze für Deutschland und die USA. Danach werden unterschiedliche Aspekte des Straf- und Zivilrechtes betrachtet bevor das Wettbewerb- srecht betrachtet wird. Empfehlungen zur Verhinderung von Spam schließen den Inhalt dieses Studienbriefes ab.

4.2.1 Ursachen für Spam

Jeder E-Mail-Account Besitzer kennt das Problem der regelmäßig kommenden Werbenachrichten, welche günstige Produkte oder Dienstleistungen enthalten, die allerdings ihre Wirkung verfehlen und nur als Störfaktor wahrgenommen werden. Damit sind E-Mails bzw. so genannte „Spam Nachrichten“ gemeint, die unerwünscht und unaufgefordert versendet werden. Spam entwickelt sich immer weiter zu einem hindernden Vorgang, welcher nicht nur eine Belästigung der Nutzer bedeutet, sondern die Dienstleistung der E-Mail als Kommunikations- mittel beeinträchtigt. Einen wesentlichen Faktor in der Wertschöpfungskette stellt hinsichtlich der Eindämmung von Spam, die IT-Sicherheit dar. Grundsätzlich kön- nen Spam-Nachrichten von jedem Rechner mit Internetverbindung aus versandt werden. Das Prinzip des Spam-Versands ist einfach. Der Spammer verschickt E- Mails mit einem werbenden Charakter in der Hoffnung, dass einer der Empfänger sein Angebot wahrnimmt. Hierbei geht der Anreiz der Spammer aus einem fi- nanziellen Gedanken hervor. Der Versand einer Spam-E-Mail ist äußerst gün- stig, der mögliche Gewinn dagegen vergleichsweise hoch. Beispielsweise hat die Zustellung von 150 Millionen E-Mails lediglich einen Kostenaufwand von 100 Euro (vgl. Ivanov[2007]). Demgegenüber bedeutet eine einzige Bestellung aus einer Million versandter Nachrichten bereits einen Profit für den Spammer. In- folgedessen ist die Verlockung für den Spammer hoch, denn die Einnahmen sind beinahe immerzu größer als die Ausgaben.

Das relativ problemlose und einfache Versenden von Spam ist vor allem auf Grund des SMTP-Protokolls möglich. Spam-Verursacher können Werbung mit Hilfe von nur einer E-Mail an tausende Empfänger verschicken. Dazu muss der Mailserver sich um den Versand kümmern und der Spammer ist nur zu einem sehr geringen Anteil an der Arbeit und den damit verbundenen Aufwendungen beteiligt. Die entstehenden Kosten für Spam sind für den Verursacher auch deshalb so gering, weil dieser häuﬁg nur Botnetze (Bots = kommunizierende Rech- ner) anmieten muss (vgl. Topf et al.[2005]). Ein hoher Anteil der Kosten wird somit nicht durch den Spamversender getragen, sondern von den Providern und den Empfängern selbst. Ferner kommt hinzu, dass ebenfalls Software mit einer automatischen Zustellung von Nachrichten das Versenden erleichtern. 4.2 Einleitung Seite 119

4.2.2 Verursachte Kosten und Schäden durch Spam

Die immer größer werdende Menge von Spam verursacht im System der weltweiten Kommunikation erhebliche Beeinträchtigungen, denn der damit verbundene zunehmende volkswirtschaftliche Schaden zieht rechtliche Maßnahmen nach sich. Dies ergibt sich insbesondere auf Grund der höheren Datenfülle und dem dadurch verbundenen Bearbeitungsaufwand. Zum einen hängt das Aussortieren und Lesen von Spam mit einer höheren Arbeitszeit zusammen. Zum anderen kommt noch hinzu, dass Spamﬁlter beschaﬀt und gewartet werden müssen. Des Weiteren erfolgt die Leitungsabrechnung der Unternehmen und Internetdienstan- bieter üblicherweise nicht nach Zeit, sondern nach übertragener Datenmenge. Somit entstehen Ausgaben für jedes Byte Spam, welches übertragen wird (vgl. Solf [2012]).

Die verursachten Kosten durch Spam bedeuten für die Betroffenen eine erhebliche Belastung. Abgesehen von den damit entstehenden Produktivitätsein- bußen auf Grund der aufkommenden Personalkosten bei dem Internetdienstleis- ter (da dieser keine Zusatzvergütung durch seine Kunden erhält), um der Spam- belästigung entgegenzuwirken und infolgedessen sich mit den Kundenbeschwer- den auseinanderzusetzen, sind dabei auch andere nachteilige Entwicklungen zu betrachten. Dazu zählen unter anderem der Vertrauensverlust innerhalb der elektronischen Interaktion und die auf diese Weise einhergehende schwächer wach- sende Entwicklung des elektronischen Nachrichtendienstes. Zusätzlich kommen technische Probleme hinzu, die mittels der Massenzustellung von Spam entstehen. Die Leistungsfähigkeit der Infrastruktur muss angehoben werden, um so den Qualitätsstandard zu halten. Damit werden unerwünschte Nachrichten an die Kunden nicht zugestellt. Es ist davon auszugehen, dass stets mindestens die Hälfte aller versandten E-Mails an nicht bestehende Adressen zugestellt werden und folglich auch zurückgewiesen werden. Da aber die Absenderadresse nicht vorhanden ist, entsteht ein „Ping-Pong Effekt“. Dieser Effekt bildet eines der Gründe für die Bestimmung der Massenversendungssperre (vgl. Braun et al. [2004]).

Abb. 4.1: Spam-Anteil im E-Mail-Traﬃc in den Jahren 2007-2011 aus Gudkova and Namestnikova[2012]

Die Abbildung 4.1 zeigt den Spam-Anteil im gesamten elektronischen Nachricht- enumlauf. Dabei ist zu erkennen, dass der Spam-Versand zwischen 2007 und 2009 stark angestiegen ist (von ca. 79,1% auf 85,2%), jedoch im Jahr 2011 wieder zurück auf 80,3% ging, Tendenz weiter sinkend (vgl. Gudkova and Namestnikova[2012] und hierzu auch Abbildung 1.2 auf Seite 15).

Des Weiteren zeigt Abbildung 4.2 die Verteilung der Spam-Quellen nach Regio- nen in den Jahren 2010 und 2011. Das Wachstum der Spam-Menge ist in Asien sowie Lateinamerika deutlich zu verzeichnen, welche zusammen bereits mehr als die Hälfte des Gesamtvolumens ausmachen. Dafür ging der Anteil in Europa Seite 120 Studienbrief 4 Rechtslage

sowie insbesondere in Nordamerika stark zurück. Die Zusammenhänge lassen sich dadurch erklären, dass die befallenen Rechner sowohl in Lateinamerika als auch in Asien von denselben Botnetzen stammen. Die Betreiber dieser illegalen Botnetze sehen ihre Chance auf Grund der mangelhaften Computerkenntnisse der Internetnutzer, einer guten Internetverbindung und vor allem der fehlenden Anti-Spam-Gesetze (vgl. Solf[2012]).

Abb. 4.2: Verteilung der Spam-Quellen nach Regionen in den Jahren 2010 und 2011 aus Gudkova and Namestnikova[2012]

Die Aufteilung nach thematischen Kategorien ist Abbildung 4.3 zu entnehmen. Insbesondere die Bereiche der Bildung, andere Waren und Dienstleistungen, Mak- ler sowie Gesundheit und Medikamente sind von Spam betroﬀen.

Abb. 4.3: Spam- Verteilung nach thematischen Kate- gorien im Jahr 2011 aus Gudkova and Namestnikova[2012]

Immer häuﬁger stehen deshalb die durch Spam verursachten Problematiken in der Kritik und somit auf der Tagesordnung von Gesetzeserweiterungen. Mit 4.2 Einleitung Seite 121 strafrechtlichen Konsequenzen ist in vielen unterschiedlichen Bereichen zu rechnen. Dazu zählt zum Beispiel die Computersabotage ( und die Computersabotage§303a/bStGB) damit folglich entstehenden Datenveränderungen per Aufbau von Botnetzen Datenveränderungen,die durch die Verwendung von Malware auftreten. Aber auch der Computerbetrug (§263a StGB) mittels Phishing (vgl. Abschnitt 1.8 ab Seite 40) fällt in das Beobach- Computerbetrug tungsfeld der Gesetzeshüter. Es ist jedoch hierbei stets die tatsächliche Intention des Verursachers zu hinterfragen, denn erst bei Vorsatz wird Spam zur Straftat. Die Sanktionen gegen die Spammer werden derweil nicht nur mit Strafzahlun- gen sondern auch mit der Freiheitsstrafe gehandhabt. Insbesondere in den USA ist mit dem „CAN-SPAM Act“ ein Zeichen für die Bekämpfung von Spam gesetzt worden, welches in Abschnitt 4.4.2 erläutert wird (vgl. Karge et al.[2006]). Doch zunächst ist das genaue Vorgehen der Spammer näher zu betrachten.

Weitere Analysen zeigen auf, dass die elektronischen Nachrichten zwar sowohl mit Spam als auch mit Viren inﬁziert sind. Dabei enthält der deutlich höherer An- teil, mit über 50%, jedoch Spam, wogegen nur 5,4% Viren enthalten. Durch Spam entsteht bspw. in den USA jährlich ein Schaden von 22 Mrd. US-Dollar. Nach einer im Jahr 2009 durchgeführten Studie verbrauchen 62 Bill. Spam-Mails jährlich ca. 33 Mrd. KWh Energie sowie 100 Mrd. Stunden an Arbeitszeit, die unter anderem zum Sichten und Löschen der Spam-Mails benötigt wird. Aktuelle Studi- en gehen sogar davon aus, dass die Spam inzwischen 89-97% des gesamten E- Mail-Volumens ausmacht (vgl. Bundesministerium für Wirtschaft und Technolo- gie[2012]).

4.2.3 Vorgehen der Spammer

Laut einer Studie erfolgt jeder dritte Angriff auf Unternehmensnetzwerke per E-Mail. Gewiss ist die Virenproblematik nicht zu vernachlässigen, jedoch bildet Spam ebenfalls einen großen Teil solcher Angriffe. Momentan stehen viele unterschiedliche Ansätze zur Diskussion, die diese Mängel beheben sollen. Die Er- wartungen beruhen darauf, dass das Spam-Volumen deutlich zurückgeht, falls die Spammer nicht weiterhin diskret bleiben und demnach zurückverfolgt werden können. Das eigentliche Problem ist, dass das Versenden von E-Mails mittels SMTP (vgl. Abschnitt 1.4.3 ab Seite 20) erfolgt. Anfänglich war für die Program- mierer der Missbrauch von elektronischer Post nicht absehbar und die Zustel- lung einer Nachricht mittels eines falschen Absenders wurde folglich nicht be- dacht. Allerdings beginnt gerade an dieser Stelle die Rückverfolgung eines Spam- mers und wird damit beträchtlich behindert. Hinzu kommt, dass die Spam durch schlecht konfigurierte sowie unzureichend geschützte Server begünstigt wird. Ganz zu Anfang des E-Mails-Transfers stellten die Administratoren ihre Mailserv- er sogar der Öffentlichkeit zur Verfügung. Dies war vor allem durch den sehr beschränkten direkten Zugang der Allgemeinheit auf die elektronische Post zu begründen. Mittlerweile werden Mailserver nur so konfiguriert, dass sie auss- chließlich für die eigenen Kunden E-Mails versenden. Sollte dies dennoch nicht der Fall sein, so handelt es sich um „Offene Relays“. Diese werden indes sehr häufig und gerne von Spammern genutzt, denn sie erleichtern ihnen die Arbeit und somit auch den Verkehr der Nachrichtenzustellung. Hinzu kommt außer- dem die Verwendung der „Offenen Proxies“, die ein noch viel schwerwiegen- deres Problem darstellen. Im Vergleich zu den „Offenen Mail-Relays“bleibt hierbei die IP-Adresse des E-Mail-Versenders vollständig unbekannt. Folglich ist es offensichtlich, dass gerade diese Eigenschaft bei den Spammern auf große Be- liebtheit trifft. Derweil sind sogar Viren im Netz vorzufinden, welche auf dem befallenen Rechner vorsätzlich einen „Offenen Proxy“einrichten, damit auf diese Weise mehr gespammt werden kann. Ferner kommt es, wie bereits in Abbil- dung 4.2 aufgezeigt, oft vor, dass gerade in Drittländern viele Provider an Spam Seite 122 Studienbrief 4 Rechtslage

mitverdienen und anstatt die Spammer abzuklemmen, ganz im Gegenteil mit ihnen „Pink ContractsPinkContract “ abschließen. Dabei ist es zwischen den seriösen als auch den so genannte „Bullet-Proof“-Providern zu unterscheiden. Die letztgenannten ermöglichen dem Spammer ungestörtes Arbeiten, indem der Spammer entweder hinter einer gefälschten oder nicht bestehenden IP-Adresse sich versteckt. Im Gegenzug wird dieser am Gewinn beteiligt. Demgemäß steigt der Schaden sowie mit ihm aufkommende Beschwerden der Betroﬀenen (vgl. Braun et al.[2004]).

Vielfach ist Spam auch auf so genannte „Zombie-PCs“ zurückzuführen. Dies sind Rechner, welche absichtlich von Virenverteilern mit Schadcodes angesteckt werden, um später für das Verschicken von Spam verwendet zu werden. Diese Rech- ner werden aus Botnetzen bzw. zu fernsteuerbaren Netzwerken konsolidiert. Da- raufhin werden Befehle des Netzinhabers durchgeführt. Dabei ist darauf zu achten, dass kein ersichtlicher Schaden auf dem Rechner entsteht, da dem betroﬀe- nen Nutzer keine Veränderung direkt auﬀallen darf. Im Folgenden können die Rechner für die Spam-Verbreitung weiter unbeschränkt genutzt werden (Morawe [2009]).

Abbildung 4.4 zeigt in acht einzelnen Schritten die Entstehung und weitere En- twicklung des Spamverkehrs. Dabei ergibt sich der folgende Ablauf:

• Der Spammer (2) betreibt Webseiten (1), die ihm einen Ertrag einbringen. • Er verschickt Spam (3) und kann daher Computer mit Malware inﬁzieren (4). • Die mit Malware inﬁzierten Rechner (5) verschicken wiederrum Spam an E-Mail-Server (6). • Diese werden von noch nicht anderen Nutzern (7) abgerufen, die dann wiederum die verbreitete Werbung zum Kauf eines Produkts im Shop des Spammers nutzen.

Dieser Kreislauf verdeutlicht die schnelle und unkomplizierte Verbreitung von Spam.

Abb. 4.4: Spamverkehr im Internet

Damit lassen sich weder die herkömmlichen Massen-E-Mails noch die E-Mails mit gefährdetem Inhalt (z.B. mit Viren oder Dialer) nachhaltig alleine an Hand der Quelle unterbinden. Infolgedessen muss entweder der Internetdienstleister, welcher die Nachrichten für den Empfänger zustellt, oder sogar der Empfänger selbst, Spam mit Hilfe von Filter-Maßnahmen aussortieren. 4.3 Datenschutzrecht Seite 123

Doch um eine Nachricht als „Spam“ einzustufen, bedarf es nicht zwangsläufig einer massenhaften Zustellung von Nachrichten. Häufig empfinden die Empfänger E-Mails als Belästigung, selbst wenn sie diese vorher eigenständig angefordert haben oder der Lieferung zugestimmt haben (beispielsweise Geschäftskontak- te, welche gesetzlich zulässig sind). Trotzdem fordert laut einer Umfrage die Mehrheit der Spam-Opfer ausdrücklich nach einer Strafverfolgung von Spam- mern (vgl. Braun et al.[2004]).

Die Verfolgung von Spammern ist allerdings problematisch, da diese sich meistens im Ausland aufhalten und das juristische Vorgehen oft nicht im nationalen Recht durchsetzbar ist. Damit stößt die Fahndung auf ein vielfach unlösbares Hin- dernis. Aus diesem Grund ist es in der Regel nur sehr schwer möglich (wenn über- haupt) bestehende Ansprüche durchzusetzen. Die Empfänger versuchen deshalb immer häuﬁger sich mittels unterschiedlicher Maßnahmen gegen die unerwün- schten Nachrichten bzw. Spam zu wehren. Dabei müssen allerdings auch erforder- liche Richtlinien beachtet werden, denn technische Maßnahmen gegen Spam kön- nen rechtliche Probleme nach sich ziehen und somit gegebenenfalls gegen gel- tendes Recht verstoßen (vgl. Topf et al.[2005]).

Vorab ist jedoch auf das Datenschutzrecht einzugehen, welches mit Hilfe der enthaltenen Grundsätze die Grundlage für die nächsten Kapitel bildet.

4.2.4 Kontrollaufgaben

In diesem Abschnitt befinden sich verschiedene Kontrollaufgabe, die die Inhalt der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffs beitragen sollen.

Kontrollaufgabe 4.1: Motivation der Spammer K Aus welchem Grund wird Spam versendet?

Kontrollaufgabe 4.2: Anfälligkeit der E-Mail-Infrastruktur für Spam K Warum ist die E-Mail-Infrastruktur für Spam anfällig?

Die Lösungen zu den Kontrollaufgaben sind in Abschnitt 1.10 ab Seite 143 zu ﬁnd- en.

4.3 Datenschutzrecht

Das Datenschutzrechts beschäftigt sich insbesondere mit der „Informationelle Selbstbestimmung“. Diese setzt voraus, dass jeder Einzelne über seine Daten selb- Informationelle Selb- st bestimmen kann. Allerdings muss in diesem Zusammenhang bestimmt wer- stbestimmung den, was alles unter dem Begriff der „personenbezogenen Daten“ zu verstehen ist. Nach Paragraph §3 Abs. 1 BDSG wird dieser definiert als: Personenbezogene Daten sind Einzelangaben über persönliche oder sachliche Verhältnisse einer bestimmten oder bestimmbaren natürlichen Person (Betroffener). Zur Unterstützung des genannten Richtlinie werden verschiedene Grundsätze angewandt. Diese können weiter in die Bereiche „rechtsstaatlich“ und „datenschutzrechtlich“ unterteilt werden. Seite 124 Studienbrief 4 Rechtslage

Der erstgenannte Bereich gilt im Zusammenhang mit den Richtlinien der Normen- klarheit und der Verhältnismäßigkeit. Die datenschutzrechtlichen Grundsätze dagegen beschäftigen sich mit der gesetzlichen Sicherheit auf informationelle Selbstbestimmung. An dieser Stelle sind die Grundsätze der Datenvermeidung, Datensparsamkeit, Zweckbindung, Verbot mit Erlaubnisvorbehalt und der Trans- parenz zu benennen (vgl. Geis[2007]).

Handeln soll „geeignet“ und „erforderlich“ sowie „angemessen“ hinsichtlich des erforderlichen Vorgehens sind. Dabei ist eine Anordnung „geeignet“, wenn sie das beabsichtigte Ziel zutreﬀen formuliert. „Erforderlich“ ist diese dann, wenn sie die „mildeste“ geforderte Handlung darstellt und „angemessen“, wenn sie im zweckmäßigen Verhältnis zum Vorgehen ist. Damit steht die Angemessenheit im engen Zusammenhang zur Verhältnismäßigkeit. Dagegen besagt das Gebot der „Normenklarheit“, dass die gesetzgebende Gewalt keine „allzu unbestimmte Rechtsbegriﬀe und Generalklauseln“ sich zunutze machen darf. Damit muss es für jeden stets feststellbar sein, was die genauen Anhaltspunkte sind und wie sich die gesetzlichen Klauseln zusammensetzen (vgl. Keil[2005]).

Wird die datenschutzrechtliche Perspektive betrachtet, so sind die Grundsätze der „Datenvermeidung“ sowie der „Datensparsamkeit“ anzuwenden. Diese fungieren um die Verarbeitung der personenbezogenen Daten so gering wie möglich zu halten. Dazu zählen auch ihre Erhebung und die eigentliche Nutzung. Damit wird direkt zu Anfang beabsichtigt die Klausel des Rechts auf informationelle Selbstbestimmung einzudämmen. Folglich wird mittels dieser beiden Be- griffe der Verhältnismäßigkeitsgrundsatz näher bestimmt. Eine der Möglichkeit- Anonymität en die personenbezogenen Daten nicht herauszugeben, ist die Anonymität zu wahren oder ein Pseudonym zu benutzen. Unter einer Anonymisierung ist die Datenveränderung zu verstehen, welche dazu führt, dass diese mit keiner Person mehr in Verbindung gebracht werden kann. Besonders häufig ist die Anonymität bei Umfragen anzuwenden, damit keine Rückschlüssel der Antworten auf die Befragten hergestellt werden können.. Die Identität der Person ist dabei vielfach irrelevant, es geht einzig und allein um die Datenverarbeitung der Befragung selbst. Indessen ist mit Hilfe eines Austausches der Identifikationsmerkmale eine PseudonymisierungPseudonymisierung möglich, indem bestimmte Schlüssel zur Identifizierung verwendet werden. Die betroffene Person ist demzufolge nur anhand des Schlüssels wiederzuerkennen, was eine anonyme Datenverarbeitung nach sich ziehen kann (vgl. Geis[2007]).

Im nächsten Abschnitt werden unterschiedliche Gesetzte aufgeführt, die im Falle von Spam greifen sollen. Diese werden weltweit verschieden gehandhabt. Daher wird insbesondere zwischen Deutschland und der USA unterschieden.

4.4 Anti-Spam Gesetze

Die tatsächliche Umsetzung der Anti-Spam Gesetze ﬁndet seit den letzten zehn Jahren immer häuﬁger Anwendung und wird in vielen Punkten in ihrer Form kontinuierlich ergänzt. Dabei werden jedoch die Gesetze in den verschiedenen Ländern unterschiedlich gehandhabt. So auch zum Beispiel in Deutschland und den USA. Die Hauptüberlegung ist, dass Spam kein statisches Problem darstellt. Während das Massenversenden von unerwünschten elektronischen Nachricht- en zunimmt, verändern sich gleichzeitig auch ebenso die Vorgehensweisen der Spammer. Wie bereits erwähnt, stellt Spam eine erhebliche Beeinträchtigung dar und kostet die Länder jährlich Millionen. Auf Grund dessen ist das Vorgehen gegen Spam-Verursacher sowohl zivilrechtlich als auch strafrechtlich geregelt. 4.4 Anti-Spam Gesetze Seite 125

4.4.1 Deutschland

Angesichts der kontinuierlich steigenden Zahl von Internetnutzern, ist auch das Ausmaß an elektronischer Post deutlich gewachsen. Doch tatsächlich ist ein Großteil dieser Post mit Spam verbunden. Einzig in Deutschland beläuft sich die Anzahl an E-Mails mit 1,1 Mrd. pro Tag (vgl. HighText Verlag Graf und Treplin OHG[2010]). Auf Grund des exponentiell wachsenden Spam-Volumens kommt es oft vor, dass die ordnungsgemäßen Nachrichten in der Menge unwillkommen- er Werbe-E-Mails unbemerkt bleiben oder sogar versehentlich gelöscht werden. Für den Empfänger ist dies wiederum ein zu tragender Schaden, welcher in Kauf genommen werden muss. Das Überprüfen auf Viren und Spam wird häu- ﬁg als rechtlich bedenkenlos eingestuft, aber auch nur, wenn kein Einsehen der E-Mails erfolgt und keine personenbezogenen Daten notiert werden. Es können allerdings dort rechtliche Problematiken entstehen, wo die Nachricht- en markiert, in einen Spam-Ordner sortiert, geblockt oder sogar gelöscht werden. Nach §4 Abs. 1 des BDSG (Bundesdatenschutzgesetz) ist die Ermittlung, Bearbeitung und Verwendung personenbezogener Daten nur erlaubt, wenn sie gesetzlich berechtigt oder vom Betroﬀenen eingeräumt ist. Jedoch ist hier zu be- denken, dass das automatische Filtern dem aber nicht entgegensteht und deshalb nach dem Bundesdatenschutzgesetz angewendet werden kann. Die Rechtferti- gung ist die Störerbekämpfung nach §100 Absatz 1 TKG (Telekommunikations- gesetz) sowie die Missbrauchsbekämpfung nach Absatz 3. Das Telekommunika- tionsgesetz sorgt sowohl für den Schutz der Infrastruktur als auch der Datenverar- beitungssysteme. Ferner regelt es das Verhalten und die Konsequenzen beim uner- laubten Zugang von Datenverarbeitungssystemen, um folglich andere Teilnehmer vor Störungen zu schützen. Spam ist dabei ein wichtiges Problem, da der Filter- vorgang mit Schwierigkeiten verbunden ist. Infolge des Paragraphen §100 TKG werden alle Daten mindestens sechs Monate verdachtsunabhängig gespeichert, wobei jedoch nach Paragraph §15 TMG (Telemediengesetz) die Inhalte gesetzlich geschützt sind. Dies ist darauf zurückzuführen, dass es vor der zweckgebundenen Werbung geschützt werden soll (vgl. Ivanov[2007]). Somit sind hier vor allem die Datensparsamkeit sowie das Verhältnismäßigkeit- und Anonymitätsprinzip zu betonen.

Eine weitere mögliche Maßnahme gegen Spam vorzugehen, ist das Kopplungsver- bot. Darunter ist zu verstehen, dass das Registrieren der verschiedenen Newslet- ter freiwillig sein muss sowie dass es an andere Verträge oder Aktivitäten nicht „gekoppelt“ ist. Dabei ist die Werbeabsicht für den Empfänger deutlich hervorzuheben und das Einverständnis nach eigenem Wunsch einzuholen. Die Be- weislast für die Bedingungen liegt beim Spam-Versender. Der Provider speichert die Nutzerdaten bzw. die IP-Adresse lediglich temporär. Deshalb ist der Nach- weis für eine tatsächliche Anmeldung für ein Newsletter häuﬁg unmöglich. Die Lösung des Problems stellt das Double-OPT-IN allerdings ohne dabei eine Double-OPT-INdar, weitere Werbung anzuzeigen. Dieser fragt nach der Aufnahme in die Abonnenten- liste um eine zusätzliche Bestätigung, die häuﬁg in der Art einer weiteren E-Mail erfolgt. Die eingetragene Kontaktadresse wird im Wunschfall bejaht oder durch das Ignorieren der Nachricht verneint (vgl. Topf et al.[2005]).

Werden die deutschen Gesetze mit denen der USA verglichen, so sind einige Un- terschiede festzustellen. Gerade die USA ist der Vorläufer im Hinblick auf die Bekämpfung von Spam. Dennoch ist das Vorgehen, im Vergleich zu dem strik- ten Umgang in Deutschland, wesentlich lockerer, was allerdings nicht am Erfolg hindert. Seite 126 Studienbrief 4 Rechtslage

4.4.2 USA

Laut einer Statistik kamen im Jahr 2003 ca. 60% der weltweiten Spam aus den USA. Bereits ein Jahr später (am 01.01.2004) nach dem CAN-SPAM Act 43 („Con- trolling the Assault of Non-Solicited Pornography and Marketing“) waren es nur noch 26%. Erwähnenswert ist dabei, dass im Jahr 2004 ca. 300 Versender zu einer Gesamtstrafe von über 1 Mrd. US $ verurteilt wurden. Die Folgen des verabschiedeten Gesetzes reichen sogar soweit, dass im Jahr 2011 sich das Spam-Volumen nur noch lediglich auf 2% beläuft. Im Vergleich zu dem eu- ropäischen Gesetzesvorgehen wurde mit dem CAN-SPAM Act 43 das OPT- OUT PrinzipOPT-OUT angewandt. Damit wird dem Spammer die eigentliche Gelegenheit gewährt, überhaupt Spam zu versenden, wobei die Empfänger jedoch sogleich die Möglichkeit haben sich von der Verteilerliste austragen zu lassen. Folglich wird der CAN-SPAM Act auch häuﬁg als „YOU-CAN-SPAM Act“ bezeichnet. Zu beachten sind dennoch viele Aspekte in Bezug auf die Umsetzung. Vorab müssen die versendeten Spam-Nachrichten auf die notwendigen Informationen zu der OPT-OUT Möglichkeit verweisen. Des Weiteren darf keine Verschleierung der Ab- senderdaten (Adresse/ Header) stattﬁnden. Darüber hinaus ist vorgeschrieben, dass die Absenderadresse für mindestens 30 Tage nach Versand funktionsfähig bleiben muss. Zuletzt ist davon auszugehen, dass der geforderte OPT-OUT nach spätestens 10 Tagen Bearbeitungszeit greift (vgl. Morawe[2009]).

Ferner verbietet das Gesetz die Anwendung von Harvestern. E-Mail-Harvester oder Spambots sind Programme, die das Internet gezielt nach E-Mail-Adressen (auch Telefonnummern) oder Blogs durchsuchen, um an diese erneut Spam zu verschicken (vgl. Abschnitt 2.3.3 ab Seite 52). Ebenso der Gebrauch von „durch zufälliges Raten“ gewonnenen Empfängeradressen ist nicht erlaubt. Dagegen werden die Spam-Nachrichten innerhalb der Geschäftsbeziehungen nicht zurückge- halten. Diese sind zulässig und in den meisten Fällen auch gewollt. Die Eigenheit des CAN-SPAM Act besteht darin, dass die Durchsetzung des Gesetzes nur der FTC (Federal Trade Commission) und den Generalstaatsanwaltschaften der jew- eiligen Bundesstaaten oﬀen steht. Indessen sind die Privatklagen nur von Seiten der betroﬀenen Internetserviceprovider denkbar (vgl. Karge et al.[2006]).

Damit ist festzuhalten, dass es weltweit Spamproblematiken gibt, gegen die jedoch rechtlich vorgegangen wird, auch wenn es bis heute nicht auf alle Länder zutriﬀt. Das nächste Kapitel geht deshalb auf die strafrechtlichen Konsequen- zen von Spam ein, woraufhin ebenfalls die zivilrechtlichen Fragen und Folgen erläutert werden.

4.4.3 Kontrollaufgaben

In diesem Abschnitt befinden sich verschiedene Kontrollaufgabe, die die Inhalt der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffs beitragen sollen.

Kontrollaufgabe 4.3: Double-OPT-IN K Erklären Sie wie das Double-OPT-IN Verfahren funktioniert. 4.5 Strafrecht Seite 127

Kontrollaufgabe 4.4: CAN-SPAM Act K Nennen Sie Eigenschaften, die E-Mails aufweisen müssen, damit sie nach dem CAN-SPAM Act 43 verschickt werden dürfen.

Die Lösungen zu den Kontrollaufgaben sind in Abschnitt 1.10 ab Seite 143 zu ﬁnd- en.

4.5 Strafrecht

Die zuvor erwähnten Problematiken durch Spam sind in den nachfolgenden Ab- schnitten unter den gesetzesrechtlichen Gesichtspunkten zu prüfen. Häuﬁg wird den Spammern vorgeworfen sowohl gegen das Zivil- als auch das Strafrecht ver- stoßen zu haben. Zunächst sind die Vergehen aus der Perspektive des Strafrechts zu betrachten. Das Strafrecht setzt sich mit den Rechtsfolgen der Straftat auseinander. Im Zusammenhang mit Spam ist vor allem der Aspekt der Bewahrung von Grundrechten zu betrachten, welcher sich hierbei speziell mit der Eigentumsfrage beschäftigt.

4.5.1 Post- und Fernmeldegeheimnis

Das aktuell geltende Strafrecht gegenüber Spam deckt das Vergehen des Phishing (Computerbetrug), der Porno-Werbung sowie der Viren und Trojaner ab. Dabei soll das Ausspähen von Daten, die Datenveränderung sowie die Computersab- otage verhindert werden. In diesem Zusammenhang kommen insbesondere die folgenden Richtlinien hinsichtlich des Strafrechts zum Einsatz:

• §202 StGB - Verletzung des Briefgeheimnisses • §202a StGB - Ausspähen von Daten • §206 StGB - Verletzung des Post- und Fernmeldegeheimnisses • §303a StGB - Datenveränderung • §303b StGB - Computersabotage

Wie bereits erwähnt, ist die Zusendung von Spam, aber auch dessen Filterung, mit datenschutzrechtlichen Problemen verbunden. Denn nicht nur die Spammer handeln rechtswidrig, auch die Umsetzung von Anti-Spam Schutzmaßnahmen auf den Seiten der Mailserverbetreiber ist häuﬁg unrechtmäßig. Ein Problem von Anti-Spam Maßnahmen ist dabei, dass Inhalte einer Nachricht gelesen werden müssen, um eine unerwünschte Sendung zu blockieren. Hierbei wird allerdings gegen den Paragraphen §206 StGB verstoßen. Seite 128 Studienbrief 4 Rechtslage

Exkurs 4.1: StGB §206 Verletzung des Post- oder Fernmeldegeheimnisses E (1) Wer unbefugt einer anderen Person eine Mitteilung über Tatsachen macht, die dem Post- oder Fernmeldegeheimnis unterliegen und die ihm als Inhaber oder Beschäftigtem eines Unternehmens bekanntge- worden sind, das geschäftsmäßig Post- oder Telekommunikationsdi- enste erbringt, wird mit Freiheitsstrafe bis zu fünf Jahren oder mit Geldstrafe bestraft. (2) Ebenso wird bestraft, wer als Inhaber oder Beschäftigter eines in Ab- satz 1 bezeichneten Unternehmens unbefugt 1. eine Sendung, die einem solchen Unternehmen zur Übermit- tlung anvertraut worden und verschlossen ist, öffnet oder sich von ihrem Inhalt ohne Öffnung des Verschlusses unter Anwen- dung technischer Mittel Kenntnis verschafft, 2. eine einem solchen Unternehmen zur Übermittlung anvertraute Sendung unterdrückt oder 3. eine der in Absatz 1 oder in Nummer 1 oder 2 bezeichneten Hand- lungen gestattet oder fördert. (3) Die Absätze 1 und 2 gelten auch für Personen, die 1. Aufgaben der Aufsicht über ein in Absatz 1 bezeichnetes Un- ternehmen wahrnehmen, 2. von einem solchen Unternehmen oder mit dessen Ermächtigung mit dem Erbringen von Post- oder Telekommunikationsdiensten betraut sind oder 3. mit der Herstellung einer dem Betrieb eines solchen Un- ternehmens dienenden Anlage oder mit Arbeiten daran betraut sind. (4) Wer unbefugt einer anderen Person eine Mitteilung über Tatsachen macht, die ihm als außerhalb des Post- oder Telekommunikationsbere- ichs tätigem Amtsträger auf Grund eines befugten oder unbefugten Eingriffs in das Post- oder Fernmeldegeheimnis bekannt geworden sind, wird mit Freiheitsstrafe bis zu zwei Jahren oder mit Geldstrafe bestraft. (5) Dem Postgeheimnis unterliegen die näheren Umstände des Postverkehrs bestimmter Personen sowie der Inhalt von Postsendun- gen. Dem Fernmeldegeheimnis unterliegen der Inhalt der Telekom- munikation und ihre näheren Umstände, insbesondere die Tatsache, ob jemand an einem Telekommunikationsvorgang beteiligt ist oder war. Das Fernmeldegeheimnis erstreckt sich auch auf die näheren Umstände erfolgloser Verbindungsversuche.

Zusätzlich entsteht das Problem, dass in den untersuchten Nachrichteninhal- ten nicht nur die gewünschten Spam identiﬁziert und abgewiesen werden, sondern es kann ebenfalls unbeabsichtigt vorkommen, dass ungewollt die legitimen Nachrichten ausgeﬁltert werden (vgl. Ivanov[2007]). Des Weiteren muss zugleich der Punkt der Datenunterdrückung betrachtet werden. 4.5 Strafrecht Seite 129

4.5.2 Datenunterdrückung und Ausspähen von Daten

Das Nichtzustellen einer E-Mail verletzt dagegen das Post- und Fernmeldegeheim- nis, denn darunter fällt die „Unbefugte Unterdrückung einer zur Übermittlung anvertrauten Sendung“. Allerdings ist es hierbei fraglich, ob eine elektronische Nachricht als eine verschlossene Sendung, wie diese in Form eines Briefes vorliegt, gilt. Laut StGB (2) 1. triﬀt diese auf die E-Mail nicht zu, dagegen StGB (2) 2. „Unterdrückung“ kann im Falle einer elektronischen Post bejaht werden. Hinzu kommt der Paragraph §303a StGB, der diesen Tatbestand ebenfalls bestätigt.

Exkurs 4.2: StGB §303a Datenveränderung E (1) Wer rechtswidrig Daten (§202a Abs. 2) löscht, unterdrückt, unbrauch- bar macht oder verändert, wird mit Freiheitsstrafe bis zu zwei Jahren oder mit Geldstrafe bestraft. (2) Der Versuch ist strafbar. (3) Für die Vorbereitung einer Straftat nach Absatz 1 gilt §202c entsprechend.

Es ist festzuhalten, dass die Verschließung im Falle einer E-Mail nicht relevant ist, denn die Verschlüsselung ist laut dem Oberlandesgericht Karlsruhe (OLG) nicht gleichzusetzen mit dem Verschließen. Die elektronische Nachricht wird so definiert, dass diese „zur Übermittlung anvertraut“ ist, d.h. das Gesetz kann hier bindend greifen. Das vorliegende Problem hierbei ist aber, dass die Botnet- ze die E-Mail versenden. Der Tatbestand der „Unbefugten Unterdrückung einer zur Übermittlung anvertrauten Sendung“ existiert weiterhin, wenn der Provider eine E-Mail-Zustellung verhindert, denn es ist nicht von Relevanz wer genau die Nachricht versendet. Ferner entsteht die Frage: „Ab wann gilt eine E-Mail als anvertraut?“Ein Hindernis stellen die unterschiedlichen Definitionen des Wortes “anvertrauen„dar. Bei einem mehrstufigen Protokollablauf (zuerst TCP Hand- shake, dann SMTP) ist es ungewiss, ab welchem Zeitpunkt die E-Mail als „dem Gegenüber anvertraut“ betrachtet werden kann. Die Meinungen driften hierbei soweit auseinander, dass vereinzelt bereits das Annehmen der TCP Verbindung als Annahme der Sendung gilt. Andere wiederum akzeptieren erst nach dem DATA-Befehl die Zustellung der Nachricht. Die Tendenz geht in Richtung der letzten Variante. Handelt es sich jedoch um das „Ausspähen von Daten“ nach Paragraph §202a StGB bzw. um die E-Mail-Filterung, so gilt es in diesem Falle nicht. Der Mailserververtreiber muss keine Zugangssicherung überwinden, weshalb auch der Vorsatz der Datenverschaffung bei einer Filterung der E-Mail nicht bestehen dürfte (vgl. Topf et al.[2005]). Ein weiteres Problem bereitet die Spam auf Grund der Verwendung der gefälschten Absenderadressen.

4.5.3 Fälschung der Absenderadresse

Nicht zuletzt ist die Beliebtheit von Spam auf die Anonymität der Spammer zurückzuführen. Vielfach wird Spam insbesondere durch fremde oder nicht bestehende Absenderadressen verschickt, aber auch der Einsatz von gefälschten IP- Adressen ist üblich. Die Spammer verwenden die falschen Adressen aus bereits vorhandenen Domains, um dann Spam-E-Mails zu versenden. Das wahllose Än- dern der Versenderinformationen ist auf Grund der Mängel von SMTP möglich (vgl. Abschnitt 1.4.3). Damit versteckt sich der Spammer hinter einer imitierten Adresse und befürchtet keine rechtlichen Maßnahmen, da das Ausﬁndigmachen Seite 130 Studienbrief 4 Rechtslage

sich als sehr schwierig erweist. Die sich daraus ergebenden Schlussfolgerungen sind, dass die bestehenden Gesetze alleine keine optimale Lösung des Prob- lems sind und die hierbei existierenden Lücken beseitigt werden müssen (Ivanov [2007]). Auf Grund dessen wird beim Eingang einer Nachricht durch die Mailserv- er kontrolliert, ob es sich bei der versendeten E-Mail um eine reguläre Ab- senderdomain handelt. Ist dies nicht der Fall, so wird die E-Mail direkt als Spam eingeordnet. Die unangenehmen Folgen müssen jedoch die Domaininhab- er tragen. Es ist mit verschiedenen Fehlermeldungen zu rechnen, die natürlich auch dafür sorgen, dass die Postfächer der „falschen Absenderadressen“ unnötig verstopft sind. Dies wiederum stört die Verfügbarkeit des Mailservers. Hierbei kann jedoch der Anbieter weder gegen Urkundenfälschung noch gegen Betrug oder Computersabotage vorgehen. In dieser Sachlage greift nur das Markenrecht nach Paragraph §143 MarkenG (Markengesetz), welches die „strafbare Kennze- ichenrechtsverletzung“ untersagt. Folglich sind Klagen gegen die Verletzung des Markenrechts möglich. Darunter ist allgemein der Missbrauch von Marken durch den Spammer zu verstehen, falls dieser gefälschte Absender wie beispielsweise @hotmail.com oder @yahoo.com verwendet. Die Strafe sieht vor fünf Jahre lang kein angemeldetes Geschäftszeichen sowie eine Marke ohne das Einvernehmen des Eigentümers zu verwenden. Des Weiteren ist auch der „Joe Job“ zu benennen. Dieser verändert nicht nur die Absenderadresse, sondern ebenfalls den Inhalt der Nachricht. Der aufgeführte Inhalt wirbt dann für den vermeintlichen Adressaten und lenkt damit die Aufmerksamkeit auf seine Gegenwart. Trotzdem ist in der Re- alität zu beobachten, dass die gestellten Anzeigen keinen Rechtsspruch erwirken können (vgl. Topf et al.[2005]).

Das Versenden von Spam muss ferner auch hinsichtlich des Zivilrechts betrachtet werden, denn alleine anhand des Strafrechts sind nicht alle gesetzeswidrigen Punkte abgedeckt.

4.5.4 Kontrollaufgaben

In diesem Abschnitt befinden sich verschiedene Kontrollaufgabe, die die Inhalt der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffs beitragen sollen.

Kontrollaufgabe 4.5: Filterung auf SMTP-Server K Aus welchem Grund machen sich Betreiber von SMTP-Servern strafbar, wenn sie inhaltsbasierte Filter anwenden?

Kontrollaufgabe 4.6: Fälschung der Absenderadresse K Auf welches Recht können sich Inhaber eine Domain berufen, wenn sie gegen die Verwendung ihrer Domain als Absenderadresse für Spam klagen wollen?

Die Lösungen zu den Kontrollaufgaben sind in Abschnitt 1.10 ab Seite 143 zu ﬁnd- en. 4.6 Zivilrecht Seite 131

4.6 Zivilrecht

Das Zivilrecht beschäftigt sich im Vergleich zum Strafrecht mit rechtlichen Beziehungen der natürlichen oder juristischen Personen untereinander und damit insbesondere mit dem Gegenstand der Haftungsfrage zwischen dem Provider und seinem Kunden. Besonders wichtig ist in diesem Zusammenhang die Frage: Wer genau haftet für die Spam? Ist es stets der Verursacher oder sind die Provider ebenfalls daran beteiligt? Ferner sind die Aspekte der Schadenersatzpﬂicht als auch insbesondere der Filtermaßnahmen von Spam zu klären.

4.6.1 Schadensersatzpﬂicht

Zuallererst muss der Begriff eines „Marktteilnehmers“ erklärt werden. Ein Markt- teilnehmer wird nach Paragraph §2 UWG sowohl als Gewerbetreibender als auch Privatperson definiert. Damit sind „neben Mitbewerbern und Verbrauchern alle Personen, die als Anbieter oder Nachfrager von Waren oder Dienstleistungen tätig sind“gemeint. Auf Grund dessen ist es hervorzuheben, wie die Schadener- satzpflicht gehandhabt wird. Laut Paragraph §823 BGB (vgl. Exkurs 4.3) haben alle Spam-Empfänger gegenüber dem Spam-Versender einen Anspruch auf Schaden- ersatz.

Exkurs 4.3: BGB §823 Schadensersatzpflicht E (1) Wer vorsätzlich oder fahrlässig das Leben, den Körper, die Gesund- heit, die Freiheit, das Eigentum oder ein sonstiges Recht eines anderen widerrechtlich verletzt, ist dem anderen zum Ersatz des daraus entstehenden Schadens verpflichtet. (2) Die gleiche Verpflichtung trifft denjenigen, welcher gegen ein den Schutz eines anderen bezweckendes Gesetz verstößt. Ist nach dem In- halt des Gesetzes ein Verstoß gegen dieses auch ohne Verschulden möglich, so tritt die Ersatzpflicht nur im Falle des Verschuldens ein.

Doch ab wann genau kann der Empfänger tatsächlich Schadenersatz verlangen? Zunächst ist darauf hinzuweisen, dass der Empfänger grundsätzlich keine juristischen Ansprüche durchsetzen kann, falls er Spam-E-Mails erhält. Ein ISP (Inter- net Service Provider bzw. Internetdienstleister) dagegen kann gesetzlich vorgehen und sein Recht geltend machen. Dabei kann er gegen mehrere Aspekte vorgehen. Zum einen können Unterlassungsklagen gegen den Spam-Verursacher eingere- icht werden. Zum anderen ist ein Schadenersatz gegen den Spam-Verursacher auf Grund von Eigentumsverletzungen möglich (vgl. Topf et al.[2005]).

4.6.2 Blacklists

Wie im Studienbrief 3 Kapitel 3.4 bereits erklärt, werden E-Mails anhand von Black, Gray- und Whitelists klassifiziert. Diejenigen Nachrichten, die nicht von diesen drei Listen erfasst werden, besitzen eine unklare Klassifizierung. Die Ju- risten beurteilen die verschiedene Maßnahmen wie das Blacklisting, die Behand- lung von Dateianhängen oder das Filtern von E-Mails in unterschiedlicher Art und Weise. Der Sachverhalt eines Blacklisting ist komplex, wenn dieses von einem Provider oder Dritten gepflegt wird. Eine Quarantäne bedenklicher E-Mails wäre juristisch gesehen zwar akzeptabel, aber widerspricht dem Konzept des Black- listing (vgl. Abschnitt 3.4.1 ab Seite 78). Unproblematisch ist die Verwendung Seite 132 Studienbrief 4 Rechtslage

von Blacklists nur, wenn die E-Mails in einen separaten Ordner abgelegt werden oder wenn diese vom Nutzer selbst gepﬂegt werden. Auch das Abtrennen von gefährlichen Dateianhängen unterliegt denselben Gesichtspunkten wie das Black- listing, weil damit ein Teil der Nachrichten zurückgehalten wird. Ein weiterer wichtiger Aspekt ist, dass die Nachrichten nicht verloren gehen dürfen. Gleiches gilt für das Entfernen von Anhängen, die unter Spam-Verdacht stehen. Wenn es sich um eine automatische Filterung handelt, so ergeben sich keine Problematiken bezüglich des Datenschutzes, da die E-Mail von niemandem gelesen wird. Um die Filter jedoch auch gänzlich zu umgehen, werden häuﬁg Bilder verwendet, weil die eigentliche Filterung lediglich auf die Analyse der Textinhalte ausgerichtet ist (vgl. Karge et al.[2006]).

Indem die Blacklist den Inhalt einer Nachricht nach bestimmten Stichworten oder dem Absender auf Einträge überprüft und infolgedessen diese Stichworte aussortiert, ist die Datenunterdrückung näher zu betrachten. Diese erfolgt nach Para- graph §303a StGB beim Empfänger durch den Provider und braucht die Zus- timmung des Empfängers. Das Ausspähen von Daten ist dagegen in dem Para- graphen §202a StGB festgehalten. Hiernach ist es nicht erlaubt sich Daten zu ver- schaﬀen. Trotzdem ist es nicht völlig ersichtlich, welche Daten darunter fallen, denn die E-Mails sind vom Provider teils nicht gesichert. Es lässt sich hier festhal- ten, dass die Paragraphen §202a und §303 nicht relevant sind, wenn das Einver- ständnis des Empfängers vorliegt (vgl. Ivanov[2007]).

Eine Empfehlung für das „legitime“ E-Mail-Versenden ist die Whitelist. In diesem Zusammenhang ist auf das Double OPT-INDoubleOPT-IN Verfahren zu verweisen. Die Auf- nahme von Nutzern in die E-Mail-Verteiler erfolgt in einem zweistuﬁgen Ver- fahren. Zuerst muss der Benutzer sich mit seiner E-Mail-Adresse anmelden. Danach wird eine E-Mail an die angegebene Adresse verschickt, die einen Bestä- tigungslink enthält. Mit diesem Link kann der Benutzer bejahen, dass er sich für einen E-Mail-Verteiler anmeldet. Weiterhin ist auch die frühzeitige Nennung der Absenderadresse in der versendeten Nachricht notwendig. Der Empfänger sollte möglichst schnell wissen, von wem diese ist und was der genaue Betreﬀ ist, damit der Inhalt bzw. die Absicht direkt erkennbar ist. Damit soll für den Benutzer vor allem ersichtlich sein, von welcher E-Mail-Adresse er Nachrichten bekommt. Fern- er muss eine X-OPT-IN Zeile im Header eingefügt werden, welche die IP und den Zeitstempel enthält. Diese Information ermöglicht das Tracking einer Anmeldung und damit die Zurückverfolgung. Demgemäß ist feststellbar, wann sowie von wem die Empfängeradresse in den Newsletter aufgenommen wurde. Außerdem sollte der MX-Eintrag für die Domain des Absenders auf den sendenden Rech- ner zeigen. Darüber hinaus sollen die Newsletter, die an Neukunden gesendet werden, nicht von einem Rechner versandt werden, der auf einer Whitelist steht, da von der Gruppe der Neukunden die meisten Spam-Beschwerden zu erwarten sind (vgl. Ivanov[2007]).

Ferner soll auf den Unterschied zwischen Spam und Malware verwiesen werden. Diese Begriﬀe sind nicht identisch und müssen gerade aus der gesetzlichen Sicht voneinander getrennt werden.

4.6.3 Malware vs. Spam

Unter juristischen Gesichtspunkten muss auch zwischen Spam und Malware unterschieden werden. Spam an sich ist in der Regel lediglich unerwünscht und wird auf Grund der Kostenreduzierung eliminiert. Malware indessen ist auch noch zusätzlich schädlich und muss zum Schutz der Infrastruktur beseitigt werden. Eine Filterung ist dabei jedoch zur Kostenreduktion (Spam) nicht akzeptabel. Eine Filterung zum Schutz der eigenen Infrastruktur (Malware) dagegen schon. 4.6 Zivilrecht Seite 133

Das bedeutet, dass wenn die Malware die Infrastruktur des Providers schädigt, so ist dieser berechtigt, diese zu ﬁltern. Jedoch darf Spam und Malware erst straf- frei aussortiert werden, wenn es vertraglich geregelt worden ist. Hierbei ist auf den Paragraphen §206 StGB hinzuweisen (vgl. Topf et al.[2005]).

Abb. 4.5: Unterschiede zwischen Spam und Malware.

Abbildung 4.5 zeigt noch einmal den Unterschied zwischen Spam und Malware auf. Insbesondere die verschiedenen Gründe, warum Spam bzw. Malware zu beseitigen ist, sind klar zu trennen.

Im nächsten Abschnitt sind vor allem die Filterproblematiken aus rechtlicher Sicht zu hinterfragen. Ferner ist auf die Anforderungen an ein Spam-Schutzsystem einzugehen und ihre Wichtigkeit zu begründen.

4.6.4 Filterproblematiken

Zunächst ist zu bemerken, dass Spam immer subjektiv zu betrachten ist, da es stets auf den Empfänger ankommt und was dieser als Belästigung empfindet. Es kann möglicherweise vorkommen, dass lediglich nur die pornografischen Nachricht- en als störend wirken und unerwünscht sind, dagegen beliebige Newsletter jedoch nicht. Auf Grund dessen existiert kein Schutzsystem, welches die Kriterien für „One size fits all!“ erfüllt. Jeder Empfänger erhält unterschiedliche E-Mails, was die Suche nach einer einheitlichen Lösung nur zusätzlich erschwert. Ferner ist darauf hinzuweisen, dass eine Zensur grundsätzlich erst einmal unerwünscht ist. Der ISP hat hauptsächlich zur Aufgabe, die Netzanbindung für seine Kun- den bereitzustellen und nicht Nachrichten, die als Spam gelten, auszusortieren. Jedoch besteht hierbei ein Ausweg, indem die Anwender sich bestimmte Verhal- tensweisen aneignen, die vom Provider empfohlen werden und somit den Um- gang mit Spam erlernen. Trotzdem zieht es die Folge nach sich, dass ohne den Eingriff und Zuspruch des Anwenders keine Beseitigung von E-Mails, sei es auch Spam, möglich ist. Ferner kommt die Problematik des „False Positives“ (hier handelt es sich um zu Unrecht als Spam erkannte E-Mails) sowie des „False Nega- tives“ (hier ist es eine tatsächliche Spam-Nachricht, die allerdings nicht als solche erkannt wurde) hinzu. Damit besteht die schwierigste Aufgabe jedes Spam-Filters darin, zwischen erwünschten und unerwünschten E-Mails zu unterscheiden und zu gewährleisten, dass ausschließlich nur die Spam-Nachrichten aussortiert werden (vgl. Braun et al.[2004] und Abbildung 4.6).

Aufgrund dessen muss dem Anwender immer die Möglichkeit oﬀen stehen den Filterungsprozess zu beeinﬂussen. So muss er beispielsweise Änderungen Seite 134 Studienbrief 4 Rechtslage

Abb. 4.6: Klassiﬁzierung von Ham und Spam in unterschiedliche Gruppen.

vornehmen dürfen, wenn es sich um die „False Positives“ handelt, da diese weder gefährlich noch unerwünscht sind. Eine Ausnahme bei der der Internet Ser- vice Provider eingreifen darf, ohne die vorherige Zustimmung des Anwenders einzuholen, bildet die kurzzeitige Störung des Systems, welche auf externe An- griﬀe (z.B. DOS-Angriﬀe) zurückzuführen ist. Dabei handelt es sich um eine vorübergehende Instabilität des Systems, für die das Blocken der Spam-Nachricht notwendig ist, um den E-Mail-Dienst wieder herstellen zu können. Zu beachten ist jedoch dabei, dass die Deaktivierung des Blockierens so schnell wie möglich wieder aufgehoben wird, damit das Filtern nicht wieder einen unrechtmäßigen Charakter bekommt (vgl. Bundesministerium für Wirtschaft und Technologie [2012]).

Das grundsätzliche Problem, welchem jeder Filter entgegensteht, ist dass es keinen zu 100% fehlerfreien Filter gibt. Es kann also nicht davon ausgegangen werden, dass es generell zu keinen „False Positives“ kommt und lediglich die tat- sächlichen Nachrichten aussortiert werden. Aus diesem Grund kann nicht von einer perfekt zuverlässigen Methode gesprochen werden, welche fehlerfrei funktioniert. Zudem weitet sich die Filterproblematik auch auf die Unternehmen aus, die nicht zu der Gruppe der Spam-Versender zählen, sondern bloß bei den Kun- den mittels elektronischer Marketingmethoden für ihre neuen Produkte werben. Bei vielen Massen-E-Mails handelt es sich folglich auch um erwünschte Newslet- ter, die jedoch auf Grund der Filtermaßnahmen bei den Kunden nicht ankommen. Daraus lässt sich schlussfolgern, dass ein einzelner Filter zu keiner Lösung führt, da dieser alleine nicht genügt. Wird dagegen eine Kombination verschiedener Fil- ter verwendet, so sind die Ergebnisse weitaus zielsicherer. Zu diesem Zweck werden die Filter häuﬁg nacheinander geschaltet und beeinﬂussen somit die Entschei- dung, ob es sich um eine Spam-E-Mail handelt oder nicht. Dementsprechend läuft die Fehlerquote gegen Null und kann fast gänzlich vermieden werden (Braun et al. [2004]).

Die Filtertechniken sind ebenfalls aus der juristische Sicht zu betrachten, denn das Filtern ist nichts anderes als ebenso ein Überwachungssystem der an den Kunden gerichteten Kommunikation. Damit müssen die ISPs ebenfalls mit Haf- tungsrisiken rechnen. Die Ursache liegt im unaufgeforderten Entfernen von Nachrichten. Auch wenn die Spam-E-Mails unerwünscht sind, kann das Fil- tern jedoch wiederum zu einer Vertragsverletzung führen. Der Mailservice liegt dem Kunden vielfach uneingeschränkt vor und kann deshalb auch nicht geﬁltert werden. Des Weiteren ist auf die Überprüfung von Nachrichten während des Filterungsprozesses einzugehen. Diese ist generell automatisiert, von ein- 4.6 Zivilrecht Seite 135 er manuellen Überprüfung kann jedoch auch Gebrauch gemacht werden. Auf Grund dessen können sich datenschutzrechtliche, telekommunikationsrechtliche sowie strafrechtliche Probleme ergeben. Grundsätzlich ist allerdings davon auszugehen, dass die Reaktion des Kunden ganz anders ausfällt. Dieser sieht sich nur äußerst selten gewillt gegen seinen Provider vorzugehen. Zum einen wird häuﬁg erst überhaupt nicht wahrgenommen bestimmte Nachrichten nicht erhalten zu haben. Zum anderen ist natürlich auch die Erkenntlichkeit keine Spam-E-Mails bekommen zu haben, nicht zu vernachlässigen.

Letztendlich lässt sich zusammenfassen, dass mittels der Filterung die elektronischen Nachrichten in vier verschiedene Gruppen einzuteilen sind:

True Positive Erwünschte E-Mail, die regulär und gesetzmäßig zugestellt wird.

True Negative Spam-E-Mail, die entweder direkt in den Spam-Folder geﬁltert oder sogar überhaupt nicht an den Empfänger überbracht wird.

False Positive Erwünschte E-Mail, die jedoch vom Spam-Filter aussortiert wird.

False Negative Unerwünschte E-Mail, die allerdings nicht vom Spam-Filter als solche erkannt wird und folglich zugestellt wird.

Dabei ist es sowohl für den Kunden als auch den Internet Service Provider von Vorteil die serverbasierte Lösung zu wählen. Damit werden die Nachrichten noch vor der Zustellung beim Empfänger gefiltert. Demgemäß können Personalkosten und andere Ressourcen eingespart werden. Herauszuheben ist dabei, dass ein Fil- ter umso genauer und besser seinen Zweck erfüllt, je mehr er auf den Endanwen- der angepasst ist sowie umso effektiver, je näher er sich am Ursprung des Spam- mers befindet. Zuvor jedoch muss der ISP verschiedene Bedingungen bezüglich der Zielgruppe der Nutzer beachten, um Ansprüche bei den technischen Filter- maßnahmen gegen Spam durchsetzen zu können (vgl. Braun et al.[2004]).

4.6.5 Anforderungen an ein Spam-Schutzsystem

In Folge der oben genannten Prämissen sind viele verschiedene Anforderungen an das Spam-Schutzsystem zu stellen. Als erstes müssen Nachrichten mit dem Kri- terium „Spam“ oder solche die diesem Charakteristikum entsprechen, erfasst und gekennzeichnet werden. Hierbei werden allerdings auch E-Mails erfasst, die eine schädliche Meldung beinhalten. Zu beachten ist an dieser Stelle, dass dies kein Hauptkriterium für ein Spam-Schutzsystem, Viren und ähnliches auszusieben, darstellt. Dementsprechend handelt es sich hierbei nicht um das eigentliche Spam- Problem, sodass diese unerwünschte Art von E-Mails vom System gänzlich nicht erkannt sowie gegebenenfalls auch nicht berücksichtigt wird. Des Weiteren ist davon auszugehen, dass die Anzahl der „False Positives“ nach Möglichkeit gering gehalten wird. Dies ist vor allem wegen den Verlustgründen von entscheidender Bedeutung und dem Leitgedanken „Lieber ein False Negative als ein False Posi- tive!“, zuzuschreiben (vgl. Braun et al.[2004]). Außerdem ist es wichtig den Ver- waltungsaufwand zu minimieren, da Spam zusätzliche Personalkosten verursacht und für das Unternehmen überplanmäßige und hohe Ausgaben bedeutet. Die Er- wartungen dagegen an das Schutzsystem sind, dass dieses mit einer schnellen und leistungsfähigen Verarbeitung von Daten verbunden ist. Damit wird sichergestellt, dass das E-Mail-System bei Angriﬀen oder bei sonstigen Beeinträchtigungen stets funktionsfähig bleibt. Jedoch ist bei einem Spam-Schutzsystem auch gleichzeitig darauf zu achten, dass dieses keine zu hohen Kosten nach sich zieht, denn mit Hilfe des Systems wird das Einsparen von Kosten beabsichtigt und nicht dessen Ausweitung. Auf Grund dessen darf die Implementierung selbst nicht teurer sein Seite 136 Studienbrief 4 Rechtslage

als seine beabsichtigte Wirkung. Überdies kommt hinzu, dass gerade die kleineren Endanwender häuﬁg keine Nachsicht in Bezug auf ein Spam-Schutzsystem und folglich den damit verbundenen Kosten, zeigen werden. Bei größeren Endan- wendern dagegen sieht es möglicherweise schon ganz anders aus. Diese Nutzer zeigen sich durchaus oft damit einverstanden für zusätzliche Dienstleistungen zu bezahlen, wenn sie einen Vorteil daraus ziehen und beispielsweise dadurch ihre eigenen Mittel (Netz, Administration, etc.) entlasten. Ein weiterer Punkt ist, dass die Filter vor den anderen „Features“ (z.B. Autoresponder) greifen müssen, um Rückläufer und gegebenenfalls sogar eine Adressenveriﬁzierung für den Spam- mer zu umgehen (vgl. Topf et al.[2005]).

4.6.6 Kontrollaufgaben

In diesem Abschnitt befinden sich verschiedene Kontrollaufgabe, die die Inhalt der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffs beitragen sollen.

Kontrollaufgabe 4.7: Spamﬁlterung durch den ISP K Aus welchen Gründen ist eine Spamﬁlterung durch die ISPs problematisch?

Kontrollaufgabe 4.8: Klassiﬁzierungen von Nachrichten K In welche vier Gruppen lassen sich die Ergebnisse der Nachrichtenklassiﬁka- tion gliedern? Beschreiben Sie die einzelnen Gruppen kurz.

Die Lösungen zu den Kontrollaufgaben sind in Abschnitt 1.10 ab Seite 143 zu ﬁnd- en.

4.7 Wettbewerbsrecht

Auch das Wettbewerbsrecht ist im Zusammenhang mit Spam nicht zu vernach- lässigen, denn diese ist eine unerlaubte Werbeform und grundsätzlich wettber- werbswidrig. Folglich darf gegen jeden Verursacher vorgegangen werden, um weitere Schäden zu vermeiden. Dabei ist insbesondere der Eingriﬀ in das Daten- schutzrecht schwerwiegend, denn darunter fallen Vorgänge wie die Nutzung personenbezogener Daten sowie die Erhebung und Verarbeitung davon. Selbst wenn einmal die Zustimmung des Empfänger für Direktwerbung vorliegt, darf diese weder unendlich lange Geltung haben, noch soll die denkbar zukünftige Unter- sagung von Spam mit hohen Übermittlungskosten verbunden sein. Ferner ist üblicherweise davon auszugehen, dass Nachrichten mit werbendem Charakter spätestens nach zwei Jahren der Zustimmung unzulässig sind. Genau geregelt werden die zuvor genannten Punkten in der am 12. Juli 2002 verabschiedeten Datenschutzrichtlinie 2002/58/EG der Europäischen Union (EU) für „Unerbetene Nachrichten“ durch die elektronische Post, welche die Anwendung des OPT-IN Prinzips vorschreibt. Diese gilt für die Zustellung von E-Mails mit Werbeabsicht- en und trägt nach sich, dass eine Werbung ohne vorherige ausdrückliche Einwilli- gung nicht verschickt werden darf (vgl. Keber[2005]).

Die Spam-Versender greifen jedoch auf unterschiedliche Vorgehensweisen zurück, um an die E-Mail-Adressen heranzukommen und damit das OPT-IN 4.7 Wettbewerbsrecht Seite 137

Prinzip zu umgehen. Vielfach werden die Adressen einfach aus dem Internet mittels Harvester gesannekt. Die Erfassung von Adressen kommt unter anderem in Newsgroups, Chats oder Internet-Präsenzen zu Stande. Außerdem kommen Adressbücher von E-Mail-Clients hinzu, die auf Grund vireninfizierte Rechn- er sich den Spammern anbieten. Äußerst gängig ist ferner die rechtswidrige Nutzung vorerst legal erhobener Daten. Dazu zählt beispielsweise die Lieferung von personenbezogenen Daten an Dritte ohne Rechtfertigungsgrund. Darunter fallen sowohl die Weitergabe der Daten an Partnerunternehmen, als auch die Ver- mietung von E-Mail-Adressen zum werblichen Gebrauch. Auch die unbegründete Verwendung personenbezogener Daten, wie zum Beispiel werbliche Nutzung für eine Teilnahme an einem Gewinnspiel, kommt vielfach vor. Das entscheidende Problem dabei ist, dass die Daten des Adresseninhabers mit einer „erschlichenen“ Einwilligung vorliegen. Dies ist vor allem mittels einer versteckten Einverständnis des Betroffenen möglich. In den Allgemeinen Geschäftsbedingungen oder in den Teilnahmebedingungen wird auf die werbliche Verwendung zwar hingewiesen, aber von den Betroffenen sehr häufig überlesen (vgl. Verband der deutschen Internetwirtschaft e. V.[2006]). Ein weiteres Vorgehen ist die Darstellung einer zwingenden Bedingung für den Erwerb eines Vorzugs, indem die Einwilligung zur werbenden Nutzung der E-Mail-Adresse verlangt wird. Damit ist laut dem Artikel 13 EG0258 (vgl. Exkurs 4.4) der Versand von Werbe-Mails mit gefälschten bzw. verschleierten Absenderangaben verboten. Der genannte Artikel ist seit dem 31.10.2003 in den Mitgliedsstaaten der EU ebenfalls ins nationale Recht umgesetzt worden. Seite 138 Studienbrief 4 Rechtslage

Exkurs 4.4: Datenschutzrichtlinie für elektronische Kommunikation, Ar- E tikel 13 - Unerbetene Nachrichten

(1) Die Verwendung von automatischen Anrufsystemen ohne menschlichen Eingriff (automatische Anrufmaschinen), Faxgeräten oder elektronischer Post für die Zwecke der Direktwerbung darf nur bei vorheriger Einwilligung der Teilnehmer gestattet werden. (2) Ungeachtet des Absatzes 1 kann eine natürliche oder juristische Person, wenn sie von ihren Kunden im Zusammenhang mit dem Verkauf eines Produkts oder einer Dienstleistung gemäß der Richtlin- ie 95/46/EG deren elektronische Kontaktinformationen für elektronische Post erhalten hat, diese zur Direktwerbung für eigene ähn- liche Produkte oder Dienstleistungen verwenden, sofern die Kunden klar und deutlich die Möglichkeit erhalten, eine solche Nutzung ihrer elektronischen Kontaktinformationen bei deren Erhebung und bei jeder Übertragung gebührenfrei und problemlos abzulehnen, wenn der Kunde diese Nutzung nicht von vornherein abgelehnt hat. (3) Die Mitgliedstaaten ergreifen geeignete Maßnahmen, um - gebühren- frei für die Teilnehmer - sicherzustellen, dass außer in den in den Absätzen 1 und 2 genannten Fällen unerbetene Nachrichten zum Zweck der Direktwerbung, die entweder ohne die Einwilligung der betreffenden Teilnehmer erfolgen oder an Teilnehmer gerichtet sind, die keine solchen Nachrichten erhalten möchten, nicht gestattet sind; welche dieser Optionen gewählt wird, ist im innerstaatlichen Recht zu regeln. (4) Auf jeden Fall verboten ist die Praxis des Versendens elektronischer Nachrichten zu Zwecken der Direktwerbung, bei der die Identität des Absenders, in dessen Auftrag die Nachricht übermittelt wird, verschleiert oder verheimlicht wird oder bei der keine gültige Adresse vorhanden ist, an die der Empfänger eine Aufforderung zur Einstel- lung solcher Nachrichten richten kann. (5) Die Absätze 1 und 3 gelten für Teilnehmer, die natürliche Person- en sind. Die Mitgliedstaaten tragen im Rahmen des Gemeinschaft- srechts und der geltenden einzelstaatlichen Rechtsvorschriften außer- dem dafür Sorge, dass die berechtigten Interessen anderer Teilnehmer als natürlicher Personen in Bezug auf unerbetene Nachrichten ausreichend geschützt werden.

Hierbei ist allerdings eine Ausnahme zu beachten. Besteht eine Kundenbeziehung, so ist die Zusendung von Werbung zulässig. Die „Direktwerbung für eigene ähnliche Produkte oder Dienstleistungen“ und somit auch das Versenden von Werbe-E-Mails ist nur dann erlaubt, falls kein Widerspruch gegenüber der gewerblichen Nutzung seitens des Kunden erfolgt ist. Dabei muss aber die OPT-OUT Möglichkeit dem Kunden stets bestehen bleiben. Dieser Anhaltspunkt ist dem Paragraphen §7 Abs. 3 Punkt 4 (vgl. Exkurs 4.5) zu entnehmen, welcher darauf verweist, dass in jeder Spam-Nachricht auf eine Austragung verwiesen werden muss. Das bedeutet wiederum, dass der Empfänger automatisch in einer Verteilerliste für Newsletter landet und nach dem Erhalt bzw. der Zusendung von Spam, sich aus der Verteilerliste austragen kann. 4.7 Wettbewerbsrecht Seite 139

Exkurs 4.5: UWG §7 Unzumutbare Belästigung E (1) Eine geschäftliche Handlung, durch die ein Marktteilnehmer in unzu- mutbarer Weise belästigt wird, ist unzulässig. Dies gilt insbesondere für Werbung, obwohl erkennbar ist, dass der angesprochene Markt- teilnehmer diese Werbung nicht wünscht. (2) Eine unzumutbare Belästigung ist stets anzunehmen 1. bei Werbung unter Verwendung eines in den Nummern 2 und 3 nicht aufgeführten, für den Fernabsatz geeigneten Mittels der kommerziellen Kommunikation, durch die ein Verbraucher hart- näckig angesprochen wird, obwohl er dies erkennbar nicht wün- scht; 2. bei Werbung mit einem Telefonanruf gegenüber einem Ver- braucher ohne dessen vorherige ausdrückliche Einwilligung oder gegenüber einem sonstigen Marktteilnehmer ohne dessen zumindest mutmaßliche Einwilligung, 3. bei Werbung unter Verwendung einer automatischen Anrufmas- chine, eines Faxgerätes oder elektronischer Post, ohne dass eine vorherige ausdrückliche Einwilligung des Adressaten vorliegt, oder 4. bei Werbung mit einer Nachricht, bei der die Identität des Absenders, in dessen Auftrag die Nachricht übermittelt wird, verschleiert oder verheimlicht wird oder bei der keine gültige Adresse vorhanden ist, an die der Empfänger eine Auﬀorderung zur Einstellung solcher Nachrichten richten kann, ohne dass hi- erfür andere als die Übermittlungskosten nach den Basistarifen entstehen. (3) Abweichend von Absatz 2 Nummer 3 ist eine unzumutbare Belästi- gung bei einer Werbung unter Verwendung elektronischer Post nicht anzunehmen, wenn 1. ein Unternehmer im Zusammenhang mit dem Verkauf einer Ware oder Dienstleistung von dem Kunden dessen elektronische Postadresse erhalten hat, 2. der Unternehmer die Adresse zur Direktwerbung für eigene ähn- liche Waren oder Dienstleistungen verwendet, 3. der Kunde der Verwendung nicht widersprochen hat und 4. der Kunde bei Erhebung der Adresse und bei jeder Verwendung klar und deutlich darauf hingewiesen wird, dass er der Verwen- dung jederzeit widersprechen kann, ohne dass hierfür andere als die Übermittlungskosten nach den Basistarifen entstehen.

Eine Schwierigkeit ergibt sich aber auch für die Versender legitimer Werbe-Mails, da diese von der notwendigen Einwilligung des Empfängers abhängig sind. Diese kann aber nicht immer eindeutig aufgezeigt werden. Ein Beispiel dafür sind Online-Anmeldungen. Hierbei ist es fraglich, ob ein Nachweis tatsächlich ohne jegliche Hindernisse erfasst werden kann. Infolgedessen verweist der Branchen- verband eco e.V. in seiner „Richtlinie für zulässiges Online-Marketing“ (ECO09) auf den Einsatz von „Double-OPT-IN“ Anmeldungen (vgl. Keber[2005]).

Ferner zeigt auch die Umsetzung des Paragraphen §7 UWG (Gesetz gegen den unlauteren Wettbewerb) und die dadurch verbundenen „Unzumutbare Belästigung“ Seite 140 Studienbrief 4 Rechtslage

die Unzulässigkeit von unerwünschter Werbung. Damit ist ebenfalls der Begriff von Spam erfasst und klar definiert. Die Anwendung auf nicht-kommerziellen Spam wird allerdings ausgeschlossen. Mit dem Paragraphen §7 Absatz (2) Punkt 3 wird wiederholt die Anwendbarkeit der E-Mail-Werbung als auch des Telefon- und Fax-Spams einbezogen. Es ist festzuhalten, dass das OPT-IN Prinzip die einzige zulässige Werbeform ist, da diese die Zustimmung des Empfängers braucht. Dagegen das Verbot der Verschleierung von Absenderangaben ist im Ab- satz 4 wiederzufinden (vgl. Exkurs 4.5 und Bundesministerium für Wirtschaft und Technologie[2012]).

Einen Gesamtüberblick über die Rechtslage im Zusammenhang mit Spam stellt Abbildung 4.7 dar.

4.8 Empfehlungen zur Verhinderung von Spam

Spam kann auf verschiedene Arten und Weisen bekämpft werden. Zum einen ist es für den ISP möglich und wird sogar empfohlen ein vertragliches Verbot der Versendung von Spam mit dem Kunden auszumachen. Auch das Werben von Diensten mit Hilfe von Spam sollte mit inbegriﬀen sein. Geht der Kunde dem Wunsch des Providers nicht nach und verstößt gegen die vertraglichen Regeln, so ist es diesem gestattet, die angebotene Dienste zu sperren und bei einer erneuten Verletzung den Kunden zu kündigen. Wichtig ist hierbei auch, dass der Vertrag ebenfalls für die Kunden der Kunden des Providers gilt. Eine weitere Möglichkeit Spam zu umgehen, ist die Einstellungen des Mailservers zu bearbeiten, um somit jeglichen Missbrauch ausschließen zu können. Damit würde die Gefahr des Ver- sandes von Spam durch Dritte nicht mehr bestehen (vgl. Karge et al.[2006]). Des Weiteren ist es denkbar den Ursprung der E-Mail nach zu verfolgen. Der ISP verschickt dabei nur diejenigen Nachrichten weiter, dessen Adresse er kennt. Ferner können weitere Anti-Spam-Maßnahmen durch die Teilnahme an „Trusted Net- work“ erworben werden. Dort kommen Experten zusammen und beraten über die möglichen zukünftigen Methoden sowie über die Eﬃzienz der Bekämpfung von Spam. Ebenso empfehlenswert ist die Teilnahme am „Positivlistenprojekt“ des eco e.V. (Verband der deutschen Internetwirtschaft) in Kooperation mit dem DDV e.V. Dieses Projekt fördert den gesetzmäßigen E-Mail-Versand, insbesondere im Zusammenhang mit dem ressourcenschonenden Aufwand. Die Besonderheit liegt darin, dass dieses Konzept außerordentlichen sowie besonders hohen Qual- itätsanforderungen an das Versenden von Nachrichten entspricht und von den In- ternetdienstleister eingehalten werden muss. Außerdem kommt hinzu, dass eine Unterstützung der Verfolgung von Spammern zu fördern ist. Dies ist mittels der vom eco e.V. angebotenen ICTF-Hotline, welche als Zentralmeldestelle der Inter- netwirtschaft fundiert, möglich. Diese ist deshalb nützlich, weil sowohl auf na- tionaler als auch auf internationaler Ebene vorgegangen werden kann (vgl. Bun- desministerium für Wirtschaft und Technologie[2012]).

Aber auch die Kunden selbst können sich gegen Spam schützen. Die Provider kön- nen ihren Kunden neben sonstigen Dienstleistungen auch noch zusätzlich Spam- ﬁlter anbieten, weil die E-Mail-Filter alleine bekanntlich keine Lösung des Prob- lems darstellen und die Belästigung der Kunden weiter präsent ist. Ferner ist es von Vorteil die Kunden erneut auf die bestehenden Filtermaßnahmen sowie ihrer Funktionsweisen hinzuweisen. Auch das Risiko von „False Positives“ muss verdeutlicht werden. In diesem Sinne ist die Einstellung und der Gebrauch von Fil- termethoden dem Kunden selbst anzuvertrauen, dass diese überwiegend eigen- ständig reguliert werden. Trotz alldem ist darauf zu achten, dass der Provider keine E-Mails ohne die Kenntnis des Kunden entfernt oder zurückweist. Eine Zurückweisung ist allerdings möglich, wenn die Nachricht einen gefährlichen Code beinhaltet oder wenn eine Gefahr der technischen Infrastruktur des ISPs 4.8 Empfehlungen zur Verhinderung von Spam Seite 141

Abb. 4.7: Zusammenfassung der Spam Rechtslage nach Keber[2005] Seite 142 Studienbrief 4 Rechtslage

vorliegt, aber auch wenn es sich bereits um eine grundsätzliche Verletzung gegen die technischen Richtlinien handelt. Ferner sollte die Spambekämpfung auch dem Kunden nahe gelegt werden. Ein Anti-Spam-Leitfaden ist unter der Inter- netadresse www.eco.de zu ﬁnden (vgl Verband der deutschen Internetwirtschaft e. V.[2006]).

4.9 Zusammenfassung

Die Relevanz des Spamversands spielt sowohl im Zivil-, dem Straf- als auch dem Wettbewerbsrecht eine Rolle. Das Strafrecht setzt sich mit der Verhaltensweise der Spammer auseinander. Diese verstoßen gegen das Rechtsgut „Eigentum“, wie zum Beispiel im Falle der Verwendung oder sogar Fälschung von Absender- adressen. Das Zivilrecht dagegen beschäftigt sich mit dem Rechtsverkehr der Bürger untereinander und klärt das Sachverhältnis zwischen dem Provider und seinem Kunden. Hierbei sind unter anderem vertragliche Klauseln gemeint, die das Filtern der Spam berechtigen. Auch die Frage der Schadenersatzpﬂicht wird aufgegriﬀen. Dabei kann der Provider entweder Unterlassungsklagen einreichen oder Schadenersatz auf Grund der Eigentumsverletzung gegenüber dem Spam- Verursacher verlangen. Zuletzt ist das Wettbewerbsrecht zu benennen. Dieses versucht hinsichtlich der Spam wettbewerbswidriges Vorgehen zu verbieten. Damit werden unerwünschte Nachrichten mit werbendem Charakter untersagt, um so den entstehenden Vorteil eines Unternehmens gegenüber dem anderen zu verhindern.

Auf Grund der genannten Rechtsgebiete haben alle Empfänger einen Unterlassungs- und Schadenersatzanspruch gegenüber dem Versender. Trotz der Einführung sowie Verschärfung der Gesetze und damit abgesehen von jeglicher Rechtslage, ist es auch noch in der nahen Zukunft davon auszugehen, dass es nicht möglich sein wird in einem öffentlichen Netz das Zustellen von unwillkommenen Nachrichten abzuwenden. Daher werden die Unternehmen, Empfänger sowie ISPs auch weiterhin nach Maßnahmen suchen, um das Spam- Volumen zu reduzieren und nach Möglichkeit gänzlich einzudämmen. Das größte Problem liegt in der gefälschten Verwendung der IP-Adressen und damit dem Gebrauch nicht existenter oder fremder Absenderadressen. Wird jedoch dem Spammer nachgestellt und dessen Ursprung nachverfolgt, so besteht gleichzeitig die Gefahr, den zu Unrecht beschuldigten Besitzer einer E-Mail-Adresse zu erfassen. Deshalb wird häufig kein erfolgreiches Entgegenwirken bezüglich der Bekämpfung von Spammern erreicht. Der Diebstahl von E-Mail-Adressen tritt mittels vieler Wege ein, denn das Risiko von einem Spammer beklaut zu werden, besteht fast überall. Dazu zählen beispielsweise Chatrooms, Gästebucheinträge oder die Veröffentlichung auf Websites, die dem Spammer einen Zugriff auf eine E-Mail-Adresse ermöglichen. Dabei bleiben die Betroffenen sogar häufig vorerst unwissend und nehmen den Datenklau (gegen den eigenen Willen) erst nachdem die ersten Spam-Nachrichten sie erreicht haben, zur Kenntnis.

Spam kann gemieden werden, indem diese mit Hilfe von Filtermethoden aus- gesiebt wird. Trotzdem wirkt dieses Vorgehen diversen Hindernissen entgegen, denn das Filtern bzw. Überprüfen und damit das zielgerichtete Beschaﬀen von Daten ist eine Ordnungswidrigkeit. Diese ist deshalb bei Vorsatz eine Straftat und wird dementsprechend zivilrechtlich gehandhabt. Um Haftungsrisiken jedoch zu vermeiden, besteht die Möglichkeit, die notwendigen Zustimmungen des Kunden bezüglich der Filtermaßnahmen einzuholen.

Da die Spammer stets versuchen ihre Anonymität zu wahren, ist es meistens nur sehr schwer möglich gegen sie strafrechtlich vorzugehen. Trotz der bestehenden 4.10 Lösungen zu den Kontrollaufgaben Seite 143

Gesetze, die gegen das Verschicken von Spam bestehen, sind tatsächliche Umset- zungen und damit Verurteilungen selten der Fall. Auch wenn beispielsweise Eu- ropa und insbesondere die USA immense Schritte zur Bekämpfung von Spam unternommen haben und das ebenfalls größtenteils erfolgreich, so wird es doch stets Spammer geben, die sich der gesetzgebenden Gewalt widersetzen. Das besagte Verhalten ist teilweise dadurch zu begründen, dass immer noch in vielen Ländern keine Spam-Gesetze umgesetzt wurden. Auf Grund dessen sind Spam-Angriﬀe gerade aus Asien, Lateinamerika, aber auch aus Osteuropa zu erwarten.

Im folgenden Abschnitt ﬁnden Sie zunächst die Lösungen der Kontrollaufgaben aus diesem Studienbrief. Daraufhin ﬁnden Sie in Abschnitt 4.11 ab Seite 144 einige Übungsaufgabe zur Vertiefung des Gelernten.

4.10 Lösungen zu den Kontrollaufgaben

Kontrollaufgabe 4.1 auf Seite 123

Der Versender von Spam hoﬀt darauf, dass die Werbung beim Empfänger zu einem Kauf eines Produktes führt, um daraus einen Gewinn ziehen zu können.

Kontrollaufgabe 4.2 auf Seite 123

Das für die E-Mail-Kommunikation verwendete SMTP bietet die Möglichkeit, eine E-Mail mit einem gefälschten Absender zu verschicken. Das erschwert die Suche nach dem Verursacher von Spam und macht die gesamte E-Mail- Infrastruktur anfällig für Spam.

Kontrollaufgabe 4.3 auf Seite 126

Bei der Aufnahme der E-Mail-Adresse in eine Abonnentenliste wird der Antrag- steller per E-Mail erneut gefragt, ob er in die Liste aufgenommen werden möchte. Erst durch eine zweite Bestätigung erfolgt eine Aufnahme. Wird keine erneute Bestätigung ausgesprochen, so wird der erste Aufnahmeversuch als gegenstands- los betrachtet.

Kontrollaufgabe 4.4 auf Seite 127

Nach dem CAN-SPAM Act müssen versendete E-Mails die notwendigen Infor- mationen zur OPT-OUT Möglichkeit aufweisen. Weiterhin darf der Absender nicht gefälscht oder verschleiert werden und muss gleichzeitig noch 30 Tag nach Versand funktionsfähig sein. Außerdem muss die OPT-OUT Möglichkeit nach spätestens 10 Tagen ausgeführt werden.

Kontrollaufgabe 4.5 auf Seite 130

Sofern der Betreiber eines SMTP-Servers die E-Mails anhand des Inhalts ﬁltert, muss die dazu verwendete Software den Inhalt einer Nachricht analysieren. Diese Betrachtung des Inhalts verstößt jedoch gegen §206 des Strafgesetzbuches, da sie das Post- und Fernmeldegeheimnis verletzt. Seite 144 Studienbrief 4 Rechtslage

Kontrollaufgabe 4.6 auf Seite 130

Inhaber einer Domain können sich auf §143 des Markengesetzes berufen, das die Kennzeichensrechtsverletzung untersagt.

Kontrollaufgabe 4.7 auf Seite 136

Die Filterung von Spam durch den Internet Service Provider ist aus unterschiedlichen Gründen schwierig. Auf der einen Seite stehen Gesetze wie das Briefgeheimnis, die es dem ISP untersagen, den Inhalt der Nachricht zu betrachten. Auf der anderen Seite stehen dem der Schutz der eigenen Infrastruktur gegenüber. Durch Malware kann die Infrastruktur bspw. angegriﬀen oder stark belastet werden, wodurch reguläre Dienste nicht mehr in dem Maße funktioniere, damit sie vom Kunden einwandfrei verwendet werden können.

Kontrollaufgabe 4.8 auf Seite 136

Nachrichten lassen sich nach der Klassifizierung in die vier Gruppen True Posi- tive, True Negative, False Positive und False Negative einteilen. Der Klassifikator gibt dabei eine Aussage über eine Nachricht. Klassifiziert ein Filter eine Nachricht als Ham und hat dabei die richtige Entscheidung getroffen, so handelt es sich um True Positiv, also einen wahren Treffer. Wird eine Spam Nachricht korrekt als Spam erkannt, so ist das Resultat als True Negativ zu bezeichnen. Wird eine Spam Nachricht jedoch als Ham klassifiziert, so spricht man von einem False Negative. Ham Nachrichten, die fälschlicherweise als Spam klassifiziert werden gelten als True Negative.

4.11 Übungen

Übung 4.1: Spam Statistik Ü Die Abbildungen 1.2 auf Seite 15 und 4.1 auf Seite 119 zeigen den Spam- Anteil am E-Mail Aufkommen aus unterschiedlichen Quellen. Finden Sie eine weitere Quelle im Internet. Liefern Sie Gründe dafür, dass unterschiedliche Studien zu unterschiedlichen Ergebnissen zum Spam-Anteil am gesamten E-Mail Aufkommen haben.

Übung 4.2: Pink Contract Ü Finden Sie heraus, was ein „Pink Contracts“ ist.

Übung 4.3: Datenschutrecht I Ü Erläutern Sie die Begriﬀe Datenvermeidung, Datensparsamkeit und Zweck- bindung.

Übung 4.4: Datenschutzrecht II Ü Untersuchen Sie welche Unterschiede zwischen Anonymisierung und Pseudonymisierung bestehen. Warum kann die Pseudonymisierung dem Recht auf informationelle Selbstbestimmung nur oberﬂächlich gerecht werden? 4.11 Übungen Seite 145

Übung 4.5: Datenschutzrecht III Weshalb könnte das Gebot der Normenklarheit das Eindämmen von Spam Ü erschweren?

Übung 4.6: Kopplungsverbot Was ist unter Kopplungsverbot zu verstehen? Ü

Übung 4.7: OPT-OUT Erläuterung Sie das OPT-OUT Prinzip. Ü

Übung 4.8: Post- und Fernmeldegeheimnis Was ist die Höchststrafe für die Verletzung des Post- und Fernmeldege- Ü heimnisses?

Übung 4.9: Anvertraute E-Mail Warum ist das Schlüsselwort „anvertraut“aus §206 des StGB unglücklich Ü gewähnt, wenn es um den Versand bzw. die Filterung von Spam geht?

Übung 4.10: Newsletter I Welche Eigenschaften sollen für Newsletter gelten, damit sie nicht als Spam Ü klassiﬁziert werden?

Übung 4.11: Newsletter II Ein Unternehmen entschließt sich einen Newsletter einzurichten und diesen Ü an alle Kontakte zu versenden. Unter den Kontakten beﬁnden sich E-Mail Adressen von privaten Endkunden, Geschäftskunden und Zulieferern. Ist der Versand aus rechtlicher Sicht für alle Empfänger jeweils zulässig?

Übung 4.12: Empfänger E-Mail-Adressen Wie werden E-Mail-Adressen für den Spam-Versand identiﬁziert und gegen Ü welche Rechte verstoßen diese Methoden?

Übung 4.13: Newsletter OPT-OUT Welche Gefahr birgt die OPT-OUT Option in Newslettern für Kunden im Ü Kontext von Adress-Harvesting? Seite 146 Studienbrief 4 Rechtslage

Übung 4.14: Recht Ü Fassen Sie zusammen welche Rechte beim E-Mail-Versand beachtet werden müssen und wie sich diese auf Ham oder Spam auswirken.

Übung 4.15 Ü Warum erreichen weiterhin Spam Nachrichten die Postfächer der meisten Nutzer, obwohl entsprechende Gesetze gegen den Versand von Spam existieren? Index

Academic Search Spam, 14 DomainKeys, 88 Address Munging, 54 Double OPT-IN, 132 Adress-Harvesting, 50 Double-OPT-IN, 125, 139 Adressdatenbank, 49 ADSP, 90 E-Mail,9 Affiliate, 50 Body, 20 Anker, 106 Header, 19 Anonymität, 124 eco e.V., 140 Asymmetrische Kryptographie, 92 Ausfallsicherheit, 67 Foren Spam, 13 Ausspähen von Daten, 127 Gästebuch Spam, 13 Authentifizierung, 26 Gesetz gegen den unlauteren Wettbe- Autonomes System, 63 werb Bürgerliches Gesetzbuch §2, 131 §823, 131 §7, 139 Bayesfilter, 76 Graylisting, 82 Bayestheorem, 76 HAM, 11 Blacklisting, 78 Harvesting Bots, 51 Blog Spam, 13 Hashcash, 96 Bot, 66 Honeypot, 54 BotMagnifier, 101 HTML, 55 Botnet Judo, 105 Botnetz, 15, 50, 64 Identifikation, 92 BotSniffer, 101 IMAP, 30, 62 Brute-Force Angriff, 52 IMAPS, 33 Bullet-Proof-Server, 50 Informationelle Selbstbestimmung, Bundesdatenschutzgesetz 123 §3 Abs. 1, 123 Instant Messenger Spam, 12 §4 Abs. 1, 125 Internet, 17 Internet Engineering Task Force CAPTCHA, 13, 53, 63, 87 (IETF), 95 Challenge-Response-Verfahren, 87 Internet Service Provider (ISP), 26 Client-Server-Modell, 18 IRC, 66 Computerbetrug, 121 Computersabotage, 121, 127 Kopplungsverbot, 125 CRAM-MD5, 25 Mailfilter, 75 Datenschutzrichtlinie 2002/58/EG, Bayesfilter, 76 136 Regeln, 75 Datensparsamkeit, 124 Signaturen, 76 Datenunterdrückung, 128 Makro, 107 Datenveränderung, 127 Malware, 15, 64, 99 Datenveränderungen, 121 Markengesetz Datenvermeidung, 124 §143, 130 Differentiated Mail Transfer Protocol Missbrauchsbekämpfung, 125 (DMTP), 97 Mobile Phone Spam, 12 Directory Harvest Angriff, 51 Monarch, 99 Distributed Denial-of-Service, 67 MTA Authorization Records In DNS DKIM, 88 (MARID), 95 DNS, 18, 26, 33 DNSBL, 79 Nichtabstreitbarkeit, 92 DNSWL, 81 Normenklarheit, 124 Domain Flux, 103 Online-Game Spam, 13

147 Seite 148 Index

Open Proxy, 14 RFC 1738: Uniform Resource Loca- Open Relay, 14 tors (URL), 99 OPT-IN, 136 RFC 1771: A Border Gateway Proto- OPT-OUT, 126, 138 col 4 (BGP-4), 63 RFC 1866: Hypertext Markup Lan- Parasitismus, 65 guage - 2.0, 60 Peer-To-Peer, 67 RFC 1939: Post Office Protocol - Ver- Peer-to-Peer-Modell, 18 sion 3, 27 Phishing, 11, 40, 99 RFC 1945: Hypertext Transfer Proto- Phreaking, 40 col – HTTP/1.0, 62, 103 Pink Contract, 122 RFC 2104: HMAC: Keyed-Hashing POP3, 18, 62 for Message Authentica- APOP, 30 tion, 25 DELE, 29 RFC 2195: IMAP/POP AUTHorize NOOP, 29 Extension for Simple Chal- PASS, 29 lenge/Response, 25 QUIT, 29 RFC 2460: Internet Protocol, Version RETR, 29 6 (IPv6) Specification, 33 RSET, 29 RFC 2474: Definition of the Differ- STAT, 29 entiated Services Field (DS USER, 29 Field) in the IPv4 and IPv6 POP3S, 30 Headers, 33 Populationswachstum, 65 RFC 2487: SMTP Service Extension Post Office Protocol Version 3 for Secure SMTP over TLS, (POP3), 26 23 Pre-Clustering, 107 RFC 2505: Anti-Spam Recommenda- Proof-of-Work System, 96 tions for SMTP MTAs, 59 Pseudonymisierung, 124 RFC 2554: SMTP Service Extension Public-Key Kryptographie, 92 for Authentication, 23 Purported Responsible Address, 95 RFC 2595: Using TLS with IMAP, POP3 and ACAP, 30, 33 Receiver-Driven SMTP, 97 RFC 2616: Hypertext Transfer Proto- Regeln, 75 col – HTTP/1.1, 62 Replay-Angriff, 26 RFC 2810: Internet Relay Chat: Archi- Reputationsverfahren, 84 tecture, 66 RFC, 15 RFC 2811: Internet Relay Chat: Chan- RFC 1034: Domain Names - Con- nel Management, 66 cepts and Facilities, 26, 33 RFC 2812: Internet Relay Chat: Client RFC 1035: Domain Names - Imple- Protocol, 66 mentation and Specifica- RFC 2813: Internet Relay Chat: Serv- tion, 33 er Protocol, 66 RFC 1064: Interactive Mail Access RFC 2821: Simple Mail Transfer Pro- Protocol - Version 2, 30 tocol, 83 RFC 1180: A TCP/IP Tutorial, 33 RFC 2854: The ’text/html’ Media RFC 1203: Interactive Mail Access Type, 62 Protocol - Version 3, 30 RFC 3174: US Secure Hash Algo- RFC 1321: The MD5 Message-Digest rithm 1 (SHA1), 96 Algorithm, 25, 30 RFC 3207: SMTP Service Exten- RFC 1349: Type of Service in the In- sion for Secure SMTP over ternet Protocol Suite, 33 Transport Layer Security, RFC 1459: Internet Relay Chat Proto- 33 col, 66, 103 RFC 3501: Internet Message Access RFC 1654: A Border Gateway Proto- Protocoll - Version 4rev1, 30 col 4 (BGP-4), 63 RFC 4271: A Border Gateway Proto- RFC 1730: Internet Message Access col 4 (BGP-4), 63 Protocol - Version 4, 30 RFC 4314: IMAP4 Access Control List (ACL) Extension, 32 Index Seite 149

RFC 4406: Sender ID: Authenticating ure Reporting Using the E-Mail, 95 Abuse Reporting Format, RFC 4407: Purported Responsible 92 Address in E-Mail Mes- RFC 791: Internet Protocol, DARPA sages, 95 Internet Program, Protocol RFC 4408: Sender Policy Framework Specification, 33 (SPF) for Authorizing Use RFC 821: Simple Mail Transfer Proto- of Domains in E-Mail, Ver- col, 20 sion 1, 92 RFC 822: Standard for the Format RFC 4616: The PLAIN Simple Au- of ARPA Internet Text Mes- thentication and Security sages, 30 Layer (SASL) Mechanism, RFC 854: Telnet Protocol Specifica- 23 tion, 20 RFC 4634: US Secure Hash Algo- RFC 855: Telnet Option Specifica- rithms (SHA and HMAC- tions, 20 SHA), 96 RFC 918: Post Office Protocol, 26 RFC 4648: The Base16, Base32, and RFC 959: File Transfer Protocol (FTP), Base64 Data Encodings, 24 22 RFC 4870: Domain-Based Email Au- ROKSO, 48 thentication Using Pub- lic Keys Advertised in the Schlüsselaustausch, 92 DNS (DomainKeys), 88 Second Chance Algorithmus, 107 RFC 4871: DomainKeys Identified Selbstreplikation, 65 Mail (DKIM) Signatures, Sender ID, 95 88 Sender ID Framework (SIDF), 95 RFC 4954: SMTP Service Extension Signaturen, 76 for Authentication, 23 Skelett-Signatur, 107 RFC 5321: Simple Mail Transfer Pro- SMTP, 18, 20, 62 tocol, 20, 58 Spam, 11 RFC 5322: Internet Message Format, SPam over Internet Telephony 19 (SPIT), 14 RFC 5585: DomainKeys Identi- Spam-Trap, 80, 99 fied Mail (DKIM) Service SpamAssassin, 108 Overview, 90 Spamdexing, 13 RFC 5617: DomainKeys Identified SPF (Sender Policy Framework), 92 Mail (DKIM) Author Do- Direktive, 93 main Signing Practices Mechanismus, 93 (ADSP), 90 Qualifier, 93 RFC 5672: RFC 4871 DomainKeys Störerbekämpfung, 125 Identified Mail (DKIM) Sig- Strafgesetzbuch natures – Update, 88 §206, 128 RFC 5782: DNS Blacklists and §263a: Computerbetrug, 121 Whitelists, 78, 81 §303a, 129 RFC 5802: Salted Challenge Re- §303a/b: Computersabotage, sponse Authentication 121 Mechanism (SCRAM) Telekommunikationsgesetz SASL and GSS-API Mecha- §100 Abs. 1: Störerbekämpfung, nisms, 26 125 RFC 6234: US Secure Hash Algo- §100 Abs. 3: Missbrauchs- rithms (SHA and SHA- bekämpfung, 125 based HMAC and HKDF), Telemediengesetz 96 §15, 125 RFC 6376: DomainKeys Identified TLS, 30 Mail (DKIM) Signatures, Torpig, 103 88 Transparenz, 124 RFC 6652: Sender Policy Framework (SPF) Authentication Fail- Unsolicited Bulk Email, 11 Seite 150 Index

URL, 40, 99 US-ASCII, 19

Verbot mit Erlaubnisvorbehalt, 124 Verschlüsselung, 92 Verschwiegenheit, 26 Voice over IP (VoIP) Spam, 14

Wörterbuchangriﬀe, 52 Webmail, 14, 62 Whitelisting, 81 Wiki Spam, 13

X-OPT-IN, 132

Zombie, 66 Zweckbindung, 124 Verzeichnisse Seite 151

Verzeichnisse

I. Abbildungen Abb. 1.1: SPAM...... 11 Abb. 1.2: Spamanteil von 2006-2012 aus Symantec Corporation[2012]... 15 Abb. 1.3: UML Sequenzdiagramm einer beispielhaften E-Mail Sitzung... 18 Abb. 1.4: UML Sequenzdiagramm einer SMTP Sitzung...... 21 Abb. 1.5: UML Zustandsdiagramm einer POP3 Sitzung...... 27 Abb. 1.6: UML Sequenzdiagramm einer POP3 Sitzung...... 28 Abb. 1.7: UML Sequenzdiagramm einer IMAP Sitzung...... 31 Abb. 1.8: Spam Wertschöpfungskette...... 39 Abb. 2.1: Aufbau eines Spammer-Netzwerks...... 49 Abb. 2.2: Ein visuelles CAPTCHA...... 53 Abb. 3.1: Blacklist-Erstellung aus Sinha et al.[2010]...... 80 Abb. 3.2: Blacklist-Erstellung nach Sinha et al.[2010]...... 81 Abb. 3.3: SNARE Framework aus Ramachandran and Feamster[2006]... 86 Abb. 3.4: Funktionsweise von Sender ID aus Microsoft Corporation[2007] 95 Abb. 3.5: Funktionsweise von Monarch aus Thomas et al.[2011]...... 99 Abb. 3.6: Flussdiagramm von Monarch aus Thomas et al.[2011]...... 99 Abb. 3.7: Raum- und zeitliche Korrelation von Bot Antworten aus Gu et al. [2008]...... 102 Abb. 3.8: Architekturübersicht von BotSniffer aus Gu et al.[2008]..... 102 Abb. 3.9: Torpig Netzwerk Infrastruktur aus Stone-Gross et al.[2009]... 104 Abb. 3.10: Systemüberblick aus Pitsillidis et al.[2010]...... 106 Abb. 3.11: Signatur Erstellungs Algorithmus aus Pitsillidis et al.[2010]... 106 Abb. 4.1: Spam-Anteil im E-Mail-Traffic in den Jahren 2007-2011 aus Gud- kova and Namestnikova[2012]...... 119 Abb. 4.2: Regionale Spam-Verteilung aus Gudkova and Namestnikova[2012]120 Abb. 4.3: Spam-Verteilung nach Themen aus Gudkova and Namestnikova [2012]...... 120 Abb. 4.4: Spamverkehr im Internet...... 122 Abb. 4.5: Unterschiede zwischen Spam und Malware...... 133 Abb. 4.6: Klassifizierung von Ham und Spam in unterschiedliche Gruppen. 134 Abb. 4.7: Zusammenfassung Rechtslage nach Keber[2005]...... 141

II. Definitionen Definition 1.1: E-Mail...... 10 Definition 1.2: Spam...... 11 Definition 2.1: Malware...... 65

III. Exkurse Exkurs 1.1: Instant Messenger Spam...... 12 Exkurs 1.2: Mobile Phone Spam...... 12 Exkurs 1.3: Foren Spam...... 13 Exkurs 1.4: Online-Game Spam...... 13 Exkurs 1.5: Spamdexing...... 13 Exkurs 1.6: Blog-, Wiki- und Gästebuch Spam...... 13 Exkurs 1.7: SPIT und VoIP Spam...... 14 Exkurs 1.8: Academic Search Spam...... 14 Exkurs 1.9: US-ASCII...... 19 Exkurs 1.10: SMTP Status-Codes...... 22 Exkurs 1.11: Base64 Kodierung...... 24 Seite 152 Verzeichnisse

Exkurs 2.1: Verschiebechiﬀre...... 56 Exkurs 2.2: ROT13 ...... 56 Exkurs 2.3: Felder in HTML Formularen...... 61 Exkurs 3.1: DKIM-Signature...... 89 Exkurs 3.2: Asymmetrische Kryptographie...... 92 Exkurs 3.3: SPF DNS Einträge...... 93 Exkurs 3.4: Reverse Engineering...... 105 Exkurs 4.1: StGB §206 Verletzung des Post- oder Fernmeldegeheimnisses. 128 Exkurs 4.2: StGB §303a Datenveränderung...... 129 Exkurs 4.3: BGB §823 Schadensersatzpﬂicht...... 131 Exkurs 4.4: Datenschutzrichtlinie für elektronische Kommunikation, Ar- tikel 13 - Unerbetene Nachrichten...... 138 Exkurs 4.5: UWG §7 Unzumutbare Belästigung...... 139

IV. Kontrollaufgaben Kontrollaufgabe 1.1: Vorteile von E-Mails...... 17 Kontrollaufgabe 1.2: Umweltfreundlichkeit von E-Mails...... 17 Kontrollaufgabe 1.3: Spam in anderen Medien...... 17 Kontrollaufgabe 1.4: Der Ursprung von Spam...... 17 Kontrollaufgabe 1.5: Modellentscheidung...... 34 Kontrollaufgabe 1.6: Beschränkung der Zeilenlänge innerhalb von E-Mails 34 Kontrollaufgabe 1.7: Anzahl der to Header Felder einer E-Mail...... 34 Kontrollaufgabe 1.8: Verwendung von SMTP...... 34 Kontrollaufgabe 1.9: Base64 Kodierung...... 35 Kontrollaufgabe 1.10: SMTP Auth...... 35 Kontrollaufgabe 1.11: POP3 Server Rückmeldungen...... 35 Kontrollaufgabe 1.12: POP3 Befehl: LIST und RETR ...... 35 Kontrollaufgabe 1.13: POP3 Befehl: DELE ...... 35 Kontrollaufgabe 1.14: POP3 Befehl: NOOP ...... 35 Kontrollaufgabe 1.15: Verwendung von IMAP...... 35 Kontrollaufgabe 1.16: Schächen von IMAP...... 35 Kontrollaufgabe 1.17: DNS...... 36 Kontrollaufgabe 1.18: Kosten für Spam...... 38 Kontrollaufgabe 1.19: Profit Spamversand...... 38 Kontrollaufgabe 1.20: Phishing...... 40 Kontrollaufgabe 2.1: Spammer Netzwerk...... 57 Kontrollaufgabe 2.2: Adress-Harvesting...... 57 Kontrollaufgabe 2.3: Directory Harvest Attack...... 58 Kontrollaufgabe 2.4: Anti-Adress-Harvesting...... 58 Kontrollaufgabe 2.5: Adress Munging...... 58 Kontrollaufgabe 2.6: Verschiebechiffre...... 58 Kontrollaufgabe 2.7: ROT13-Verschiebechiffre...... 58 Kontrollaufgabe 2.8: Offene Mail-Relays...... 59 Kontrollaufgabe 2.9: Offene Proxies...... 60 Kontrollaufgabe 2.10: Mail-Formulare...... 61 Kontrollaufgabe 2.11: Webmail I...... 63 Kontrollaufgabe 2.12: Webmail II...... 63 Kontrollaufgabe 2.13: IP Prefix Hijacking...... 64 Kontrollaufgabe 2.14: Malware...... 68 Kontrollaufgabe 2.15: Botnetz I...... 68 Kontrollaufgabe 2.16: Botnetz II...... 68 Kontrollaufgabe 2.17: Botnetz III...... 68 Kontrollaufgabe 2.18: Botnetz IV...... 68 Kontrollaufgabe 3.1: Mailfilter...... 78 Kontrollaufgabe 3.2: Bayesfilter...... 78 Kontrollaufgabe 3.3: IP-Sperren I...... 83 Literatur Seite 153

Kontrollaufgabe 3.4: IP-Sperren II...... 84 Kontrollaufgabe 3.5: Blacklisting I...... 84 Kontrollaufgabe 3.6: Blacklisting II...... 84 Kontrollaufgabe 3.7: Blacklisting III...... 84 Kontrollaufgabe 3.8: Whitelisting...... 84 Kontrollaufgabe 3.9: Graylisting...... 84 Kontrollaufgabe 3.10: Graylisting II...... 84 Kontrollaufgabe 3.11: DKIM I...... 98 Kontrollaufgabe 3.12: DKIM II...... 98 Kontrollaufgabe 3.13: SPF I...... 98 Kontrollaufgabe 3.14: SPF II...... 98 Kontrollaufgabe 3.15: SPF III...... 98 Kontrollaufgabe 3.16: Sender ID...... 98 Kontrollaufgabe 3.17: Hashcash I...... 98 Kontrollaufgabe 3.18: Hashcash II...... 98 Kontrollaufgabe 3.19: Hashcash III...... 99 Kontrollaufgabe 3.20: Monarch...... 100 Kontrollaufgabe 3.21: Domain Flux...... 105 Kontrollaufgabe 3.22: BotMagnifier und BotSniffer...... 108 Kontrollaufgabe 3.23: Botnet Judo I...... 108 Kontrollaufgabe 3.24: Botnet Judo II...... 108 Kontrollaufgabe 3.25: Botnet Judo III...... 108 Kontrollaufgabe 4.1: Motivation der Spammer...... 123 Kontrollaufgabe 4.2: Anfälligkeit der E-Mail-Infrastruktur für Spam.... 123 Kontrollaufgabe 4.3: Double-OPT-IN...... 126 Kontrollaufgabe 4.4: CAN-SPAM Act...... 127 Kontrollaufgabe 4.5: Filterung auf SMTP-Server...... 130 Kontrollaufgabe 4.6: Fälschung der Absenderadresse...... 130 Kontrollaufgabe 4.7: Spamfilterung durch den ISP...... 136 Kontrollaufgabe 4.8: Klassifizierungen von Nachrichten...... 136

V. Literatur

108th United States Congress. 15 USC Chapter 103 - Controlling the As- sault 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 Identiﬁed Mail (DKIM) Signatures. Website, 2007. Online verfüg- bar auf http://tools.ietf.org/html/rfc4871; besucht am 01.01.2013.

E. Allman, J. Fenton, M. Delany, and J. Levine. RFC 5617: DomainKeys Identiﬁed 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. Seite 154 Verzeichnisse

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 Schol- ar’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.

T. Berners-Lee, L. Masinter, and M. McCahill. RFC 1738: Uniform Resource Loca- tors (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 Proto- col – HTTP/1.0. Website, 1996. Online verfügbar auf http://tools.ietf.org/ html/rfc1945; besucht am 13.12.2012.

Dietmar Braun, Jan Kocovski, Thomas Rickert, and Béla Waldhauser. Anti Spam Task Force - ASTF. Technical report, Verband der deutschen Internetwirtschaft, 2004.

Bundesministerium für Wirtschaft und Technologie. E-Mail und Spam - Die Rechtslage in Deutschland. Website, 2012. Online verfügbar auf http: //www.bmwi.de/DE/Themen/Digitale-Welt/Recht/verbraucherschutz,did= 186842.html; besucht am 05.11.2012.

D. Connolly and L. Masinter. RFC 2854: The ’text/html’ Media Type. Website, 2000. Online verfügbar auf http://tools.ietf.org/html/rfc2854; besucht am 10.12.2012.

M. Crispin. RFC 1064: Interactive Mail Access Protocol - Version 2. Website, 1988. Online verfügbar auf http://tools.ietf.org/html/rfc1064; besucht am 28.11.2012.

M. Crispin. RFC 1730: Internet Message Access Protocol - Version 4. Website, 1994. Online verfügbar auf http://tools.ietf.org/html/rfc1730; besucht am 28.11.2012.

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 Identiﬁed Mail (DKIM) Signatures – Update. Website, 2009. Online verfügbar auf http://tools.ietf.org/html/ rfc5672; besucht am 01.01.2013.

D. Crocker, T. Hansen, and M. Kucherawy. RFC 6376: DomainKeys Identi- ﬁed 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 verfügbar auf http://tools.ietf.org/html/ rfc822; besucht am 26.11.2012. Literatur Seite 155

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-enterprise-networks/4485; besucht am 30.12.2012.

S. Deering and R. Hinden. RFC 2460: Internet Protocol, Version 6 (IPv6) Spec- iﬁcation. Website, 1998. Online verfügbar auf http://tools.ietf.org/html/ rfc2460; besucht am 20.12.2012.

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 Jeﬀries, 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-driven-00.txt. Website, 2005a. Online verfügbar auf http: //tools.ietf.org/html/draft-duan-smtp-receiver-driven-00; besucht am 03.01.2013.

Z. Duan, K. Gopalan, and Y. Dong. Receiver-Driven Extensions to SMTP draft- duan-smtp-receiver-driven-01.txt. Website, 2005b. Online verfügbar auf http: //tools.ietf.org/html/draft-duan-smtp-receiver-driven-01; besucht am 03.01.2013.

Z. Duan, K. Gopalan, and Y. Dong. Receiver-Driven Extensions to SMTP draft- duan-smtp-receiver-driven-03.txt. Website, 2006a. Online verfügbar auf http: //tools.ietf.org/html/draft-duan-smtp-receiver-driven-02; besucht am 03.01.2013.

Z. Duan, K. Gopalan, and Y. Dong. Receiver-Driven Extensions to SMTP draft- duan-smtp-receiver-driven-03.txt. Website, 2006b. Online verfügbar auf http: //tools.ietf.org/html/draft-duan-smtp-receiver-driven-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. Online verfügbar auf http: //www.duden.de/rechtschreibung/Freak; besucht am 27.12.2012.

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. Online verfügbar auf http://tools.ietf.org/ html/rfc4634; besucht am 01.01.2013. Seite 156 Verzeichnisse

D. Eastlake and T. Hansen. RFC 6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF). Website, 2011. Online verfügbar auf http:// tools.ietf.org/html/rfc6234; besucht am 01.01.2013.

D. Eastlake and P.Jones. RFC 3174: US Secure Hash Algorithm 1 (SHA1). Website, 2001. Online verfügbar auf http://tools.ietf.org/html/rfc3174; besucht am 01.01.2013.

R. Elz and R. Bush. RFC 2181: Clariﬁcations to the DNS Speciﬁcation. Website, 1997. Online verfügbar auf http://tools.ietf.org/html/rfc2181; besucht am 25.11.2012.

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-Start-104602.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; besucht am 13.12.2012.

Ivo Geis. Datenschutzrecht, 2007. http://www.ivo-geis.de/ veroeffentlichungen/datenschutzrecht.pdf.

Guofei Gu, Junjie Zhang, and Wenke Lee. BotSniﬀer: Detecting Botnet Command and Control Channels in Network Traﬃc. In NDSS. The Internet Society, 2008.

Darja Gudkova and Maria Namestnikova. Kaspersky Lab Security Bulletin 2011/2012. Spam im Jahr 2011. Website, 2012. Online verfügbar auf http: //www.viruslist.com/de/analysis?pubid=200883770; besucht am 05.11.2012.

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 Identiﬁed Mail (DKIM) Service Overview. Website, 2009. Online verfügbar auf http:// tools.ietf.org/html/rfc5585; besucht am 02.01.2013.

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.

HighText Verlag Graf und Treplin OHG. Marktzahlen: Anzahl der täglich empfangenen E-Mails in Deutschland 2010. Website, 2010. Online verfügbar auf http://www.ibusiness.de/charts/ct/220114sb.html; besucht am 05.11.2012.

P. Hoﬀman. RFC 2487: SMTP Service Extension for Secure SMTP over TLS. Web- site, 1999. Online verfügbar auf http://tools.ietf.org/html/rfc2487; besucht am 26.11.2012.

P. Hoﬀman. RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security. Website, 2002. Online verfügbar auf http://tools.ietf.org/ html/rfc3207; besucht am 28.11.2012. Literatur Seite 157

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. Web- site, 2012b. Online verfügbar auf http://www.spam.com/spam-101/history-of- spam; besucht am 19.04.2012.

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: Inter- net Protocol, DARPAInternet Program, Protocol Speciﬁcation. Website, 1981. On- line verfügbar auf http://tools.ietf.org/html/rfc791; besucht am 20.12.2012.

Internet Society, Internet Engineering Task Force (IETF). RFC Editor. Web- site, 2012. Online verfügbar auf http://www.rfc-editor.org/; besucht am 26.11.2012.

Ivo Ivanov. Rechtliche Rahmenbedingungen für Provider beim Filtern, Scan- nen und Löschen von Spam, Späh- und Schadsoftware (Gutachten). Web- site, 2007. Online verfügbar auf http://jugendschutz.eco.de/files/2011/04/ Gutachten_Provider_gegen_Spam2007_Final.pdf; besucht am 05.11.2012.

S. Josefsson. RFC 4648: The Base16, Base32, and Base64 Data Encodings. Website, 2006. Online verfügbar auf http://tools.ietf.org/html/rfc4648; besucht am 26.11.2012.

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 http://tools.ietf.org/html/rfc2811; besucht am 28.12.2012.

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://tools.ietf.org/html/rfc2813; besucht am 28.12.2012.

Sven Karge, Frank Ackermann, and Ivo Ivanov. Anti-SPAM: Ein Leitfaden über und gegen unverlangte E-Mail-Werbung. HA Hessen Agentur, 2006. ISBN 978- 3939358558.

Tobias O. Keber. Spam - Rechtslage vor und nach der UWG Reform, 2005. http: //www.dsri.de/downloads/ha2005/Tobias_Keber_Spam_180905.pdf.

Oliver Keil. Grundsätze des Datenschutzrechts, 2005. http://www2.informatik.hu-berlin.de/~keil/docs/ Grundsaetze_des_Datenschutzrechts.pdf.

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. Seite 158 Verzeichnisse

Peter Kleissner. Advanced Analysis of Sinowal. Website, 2009. Online verfüg- bar 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://tools.ietf.org/html/rfc2821; besucht am 01.01.2013.

J. Klensin. RFC 5321: Simple Mail Transport Protocol. Website, 2008. Online verfügbar auf http://tools.ietf.org/html/rfc5321; besucht am 18.09.2012.

J. Klensin, R. Catoe, and P. Krumviede. RFC 2195: IMAP/POP AUTHorize Ex- tension 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. Website, 1997. Online verfügbar auf http:// tools.ietf.org/html/rfc2104; besucht am 27.11.2012.

Christian Kreibich, Chris Kanich, Kirill Levchenko, Brandon Enright, Geoﬀrey 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éle- gyházi, Chris Grier, Tristan Halvorson, Chris Kanich, Christian Kreibich, He Liu, Damon McCoy, Nicholas Weaver, Vern Paxson, Geoﬀrey 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 http://tools.ietf.org/html/rfc5782; besucht am 01.01.2013.

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 ver- fügbar auf http://www.polygon.com/gaming/2012/9/10/3307300/guild-wars- 2-phishing-attempts-stand-at-more-than-11000; besucht am 27.12.2012.

G. Lindberg. RFC 2505: Anti-Spam Recommendations for SMTP MTAs. Website, 1999. Online verfügbar auf http://tools.ietf.org/html/rfc2505; besucht am 18.12.2012.

J. Lyon. RFC 4407: Purported Responsible Address in E-Mail Messages. Website, 2006. Online verfügbar auf http://tools.ietf.org/html/rfc4407; besucht am 03.01.2013.

J. Lyon and M. Wong. RFC 4406: Sender ID: Authenticating E-Mail. Website, 2006. Online verfügbar auf http://tools.ietf.org/html/rfc4406; besucht am 02.01.2013.

P. Mackapetris. RFC 1034: Domain Names - Concepts and Facilities. Website, 1987a. Online verfügbar auf http://tools.ietf.org/html/rfc1034; besucht am 25.11.2012. Literatur Seite 159

P. Mackapetris. RFC 1035: Domain Names - Implementation and Speciﬁcation. Website, 1987b. Online verfügbar auf http://tools.ietf.org/html/rfc1035; besucht am 25.11.2012.

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 http://tools.ietf.org/html/rfc4314; besucht am 28.11.2012.

Microsoft Corporation. Sender ID Framework Overview - Veriﬁcation System Aims to Reduce Spam and Increase Safety Online. Website, 2007. Online verfüg- bar 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üg- bar 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 ver- fügbar auf http://www.scmagazine.com/the-rustock-botnet-spams-again/ article/112940/; besucht am 30.12.2012.

Randolph Morawe. Spam - Prävention und Bekämpfung. Grin Verlag, 2009. ISBN 978-3640412068.

J. Myers. RFC 2554: SMTP Service Extension for Authentication. Website, 1999. Online verfügbar auf http://tools.ietf.org/html/rfc2554; besucht am 26.11.2012.

J. Myers and M. Rose. RFC 1939: Post Oﬃce Protocol - Version 3. Website, 1996. Online verfügbar auf http://tools.ietf.org/html/rfc1939; besucht am 18.09.2012.

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 http://tools.ietf.org/html/rfc2595; besucht am 26.11.2012.

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 http://tools.ietf.org/ html/rfc5802; besucht am 28.11.2012.

K. Nichols, S. Blake, F. Baker, and D. Black. RFC 2474: Deﬁnition of the Dif- ferentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. Website, 1998. Online verfügbar auf http://tools.ietf.org/html/rfc2474; besucht am 20.12.2012.

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. Seite 160 Verzeichnisse

Oleg Nikolaenko. Mega-D Botmaster to Stand Trial. Website, 2010. Online ver- fü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-of- warcraft-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, Geof- frey 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://tools.ietf.org/html/rfc821; besucht am 22.11.2012.

Jonathan B. Postel and J. Reynolds. RFC 854: Telnet Protocol Speciﬁcation. Web- site, 1983a. Online verfügbar auf http://tools.ietf.org/html/rfc854; besucht am 22.11.2012.

Jonathan B. Postel and J. Reynolds. RFC 855: Telnet Option Speciﬁcations. Web- site, 1983b. Online verfügbar auf http://tools.ietf.org/html/rfc855; besucht am 22.11.2012.

Jonathan B. Postel and J. Reynolds. RFC 959: File Transfer Protocol (FTP). Website, 1985. Online verfügbar auf http://tools.ietf.org/html/rfc959; besucht am 23.11.2012.

Niels Provos and Thorsten Holz. Virtual Honeypots - From Botnet Tracking to Intru- sion 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 McKe- own, 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. Literatur Seite 161

Y. Rekhter and T. Li. RFC 1654: A Border Gateway Protocol 4 (BGP-4). Website, 1994. Online verfügbar auf http://tools.ietf.org/html/rfc1654; besucht am 29.11.2012.

Y. Rekhter and T. Li. RFC 1771: A Border Gateway Protocol 4 (BGP-4). Website, 1995. Online verfügbar auf http://tools.ietf.org/html/rfc1771; besucht am 29.11.2012.

Y. Rekhter, T. Li, and S. Hares. RFC 4271: A Border Gateway Protocol 4 (BGP- 4). Website, 2006. Online verfügbar auf http://tools.ietf.org/html/rfc4271; besucht am 29.11.2012.

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 Oﬃce 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 http://tools.ietf.org/html/rfc1203; besucht am 28.11.2012.

R. Rivest. RFC 1321: The MD5 Message-Digest Algorithm. Website, 1992. Online verfügbar auf http://tools.ietf.org/html/rfc1321; besucht am 26.11.2012.

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 - Wahrschein- lichkeitstheorie 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 Authen- tication. Website, 2007. Online verfügbar auf http://tools.ietf.org/html/ rfc4954; besucht am 26.11.2012.

Sushant Sinha, Michael Bailey, and Farnam Jahanian. Improving Spam Black- listing Through Dynamic Thresholding and Speculative Aggregation. In NDSS 2010.

Stu Sjouwerman and Jeﬀrey 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://tools.ietf.org/html/rfc1203; besucht am 20.12.2012.

Peter Solf. Spam-Bekämpfung. Website, 2012. Online verfügbar auf http:// www.wettbewerbszentrale.de/de/branchen/spam/ueberblick/default.aspx; besucht am 05.11.2012. Seite 162 Verzeichnisse

Henry Stern. A Survey of Modern Spam Tools. In CEAS, 2008.

Brett Stone-Gross, Marco Cova, Lorenzo Cavallaro, Bob Gilbert, Martin Szyd- lowski, 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 Commu- nications 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.en-us.pdf.

The Spamhaus Project. Register of Known Spam Operations (ROKSO. Web- site, 2012a. Online verfügbar auf http://www.spamhaus.org/rokso/; besucht am 05.12.2012.

The Spamhaus Project. The Deﬁnition of Spam. Website, 2012b. Online verfügbar auf http://www.spamhaus.org/consumer/definition/; besucht am 11.09.2012.

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.

Verband der deutschen Internetwirtschaft e. V. Spam oder wenn sich die Mail- box in eine Müllkipper verwandelt. 7 Tipps was sie dagegen tun können! Web- site, 2006. Online verfügbar auf http://jugendschutz.eco.de/files/2011/04/ Anti-Spam-Leitfaden_AUG2006.pdf; besucht am 05.11.2012.

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-ddos-attacks-on-major-web-sites.aspx; besucht am 30.12.2012.

Andreas Wilkens. Microsoft stellt Technik für die Spamkennzeich- nung zur Nutzung frei. Website, 2006. Online verfügbar auf http: //www.heise.de/newsticker/meldung/Microsoft-stellt-Technik-fuer- die-Spamkennzeichnung-zur-Nutzung-frei-175513.html; besucht am 03.01.2013.

M. Wong and W. Schlitt. RFC 4408: Sender Policy Framework (SPF) for Autho- rizing 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. Tabellen Seite 163

K. Zeilenga. RFC 4616: The PLAIN Simple Authentication and Security Layer (SASL) Mechanism. Website, 2006. Online verfügbar auf http:// tools.ietf.org/html/rfc4616; besucht am 26.11.2012.

Kim Zetter. How a Google Headhunter’s E-Mail Unraveled a Mas- sive 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-Angriﬀ auf Online-Spieler. Website, 2009. Online verfügbar auf http://www.netzwelt.de/news/80897- world-of-warcraft-phishing-angriff-online-spieler.html; besucht am 27.12.2012.

VI. Tabellen