Spam [Spam]

Autoren: Dr. Christopher Wolf Sebastian Uellenbeck

Ruhr-Universität Bochum

Modul Spam [Spam]

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

Autoren: Dr. Christopher Wolf Sebastian Uellenbeck

1. Auflage

Ruhr-Universität Bochum © 2017 Ruhr-Universität Bochum Universitätsstraße 150 44801 Bochum

1. Auflage (30. Mai 2017)

Didaktische und redaktionelle Bearbeitung: Bärbel Wolf-Gellatly

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, Mikroverfilmungen und die Einspei- cherung und Verarbeitung in elektronischen Systemen.

Um die Lesbarkeit zu vereinfachen, wird auf die zusätzliche Formulierung der weiblichen Form bei Personenbezeichnungen verzichtet. Wir weisen des- halb darauf hin, dass die Verwendung der männlichen Form explizit als geschlechtsunabhängig verstanden werden soll.

Das diesem Bericht zugrundeliegende Vorhaben wurde mit Mitteln des Bun- desministeriums für Bildung, und Forschung unter dem Förderkennzeichen 16OH12026 gefördert. Die Verantwortung für den Inhalt dieser Veröffentli- chung liegt beim Autor. Inhaltsverzeichnis Seite3

Inhaltsverzeichnis

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

Studienbrief 1 Grundlagen9 1.1 Lernergebnisse...... 9 1.2 Advanced Organizer...... 9 1.3 Einleitung...... 9 1.3.1 E-Mail...... 10 1.3.2 Spam...... 11 1.3.3 RFC (Request for Comments)...... 15 1.3.4 Gliederung...... 16 1.3.5 Kontrollaufgaben...... 16 1.4 Internet...... 17 1.5 E-Mail-Infrastruktur...... 17 1.5.1 Kommunikationsmodell...... 17 1.5.2 Aufbau von E-Mails...... 18 1.5.3 SMTP (Simple Mail Transfer Protocol)...... 20 1.5.4 POP3 (Post Office Protocol Version 3)...... 25 1.5.5 IMAP (Internet Message Access Protocol)...... 28 1.5.6 DNS (Domain Name System)...... 30 1.5.7 Kontrollaufgaben...... 31 1.6 Anreize und Motivation der Spammer...... 32 1.7 Wirtschaftliche Aspekte...... 33 1.7.1 Durch Spam entstehende Kosten...... 33 1.7.2 Erlös für Spam-Verursacher...... 34 1.7.3 Kontrollaufgaben...... 35 1.8 Fallstudie „Click Trajectories: End-to-End Analysis of the Spam Value Chain“...... 35 1.9 Phishing...... 36 1.10 Zusammenfassung...... 36 1.11 Übungen...... 37

Studienbrief 2 Spam-Techniken 45 2.1 Lernergebnisse...... 45 2.2 Advanced Organizer...... 45 2.3 Einleitung...... 45 2.4 Spammer...... 45 2.4.1 Spammer-Netzwerke...... 46 2.4.2 Adress-Harvesting...... 47 2.4.3 Anti-Harvesting-Methoden...... 49 2.4.4 Kontrollaufgaben...... 54 2.5 Offene Mail-Relays...... 55 2.6 Mail-Formulare...... 57 2.7 Webmail...... 58 2.8 IP Prefix Hijacking...... 60 2.9 Malware / Botnetze...... 61 2.10 Zusammenfassung...... 65 2.11 Übungen...... 66

Studienbrief 3 Anti-Spam-Techniken 69 3.1 Lernergebnisse...... 69 Seite4 Inhaltsverzeichnis

3.2 Advanced Organizer...... 69 3.3 Einleitung...... 69 3.4 Mailfilter...... 69 3.5 IP-Sperren...... 72 3.5.1 Blacklisting...... 72 3.5.2 Whitelisting...... 75 3.5.3 Graylisting...... 76 3.5.4 Kontrollaufgaben...... 77 3.6 Reputationsverfahren...... 78 3.7 Challenge-Response-Verfahren...... 80 3.8 Erweiterungen des E-Mail-Verfahrens...... 82 3.8.1 DomainKeys / DKIM...... 82 3.8.2 SPF (Sender Policy Framework)...... 85 3.8.3 Sender ID...... 88 3.8.4 Hashcash...... 89 3.8.5 Receiver-Driven SMTP...... 90 3.8.6 Kontrollaufgaben...... 90 3.9 Echtzeit URL Filterung...... 91 3.10 Netzwerk-basiertes Clustern...... 93 3.11 Erkennung von Botnetzen...... 93 3.12 Botnetz-Übernahme...... 95 3.13 Botnet Judo: Automatische Generierung von Spam Signaturen.... 98 3.14 SpamAssassin...... 100 3.15 Zusammenfassung...... 101 3.16 Übungen...... 102

Liste der Lösungen zu den Kontrollaufgaben 107

Verzeichnisse 119 I. Abbildungen...... 119 II. Beispiele...... 119 III. Definitionen...... 119 IV. Exkurse...... 119 V. Kontrollaufgaben...... 120 Einleitung zu den Studienbriefen Seite5

Einleitung zu den Studienbriefen

I. Abkürzungen der Randsymbole und Farbkodierungen

Beispiel B

Definition D

Exkurs E

Kontrollaufgabe K

Merksatz M

Übung Ü Seite6 Einleitung zu den Studienbriefen

II. Zu den Autoren

Dr. Christopher Wolf studierte bis 2002 Informatik an der Universität Ulm und wurde 2005 an der K.U. Leuven in Belgien promoviert. Aktuell ist er Leiter der Emmy-Noether Arbeitsgruppe für Langszeitsicherheit an der Ruhr-Universität Bochum und beschäftigt sich mit Post-Quantum Kryptographie.

Sebastian Uellenbeck studierte bis 2010 Informatik an der Technischen Universität Dortmund. Aktuell ist er Doktorand bei Christopher Wolf und beschäftigt sich mit neuartigen Authentifikationsmöglichkeiten auf Smartphones. Modullehrziele Seite7

III. Modullehrziele In diesem Modul erwerben die Teilnehmer Kenntnisse über das globale E-Mail System sowie die Schwach- stellen, die zur Entstehung des Spam Problems führten. Im ersten Teil des Moduls werden Grundlagen des Systems beschrieben, die zum einem aus dem Aufbau von E-Mail und zum anderen aus den benötigten Protokollen bestehen. Der zweite Teil beschäftigt sich mit unterschiedlichen Spam-Techniken chronologisch behandelt von den ursprünglichen naiven Techniken zu den heute angewendeten ausgeklügelten Tech- niken. Im dritten Teil werden dann Gegenmaßnahmen betrachtet und auch aktuelle Forschungsprojekte angesprochen.

Studienbrief 1 Grundlagen Seite9

Studienbrief 1 Grundlagen

1.1 Lernergebnisse Sie können die Struktur einer E-Mail nach RFC822 beschreiben und erkennen. Darüber hinaus können Sie erläutern wie eine E-Mail spezifiziert ist und die Unter- schiede zu SPAM klar abgrenzen. Weiterhin können Sie erklären wie Spam entsteht und die wirtschaftlichen Aspekte, die den Versand von Spam für Kriminelle in- teressant machen, beschreiben. Dazu sind Sie in der Lage, die Grundlagen der E-Mail-Struktur und deren Protokolle zu erläutern.

1.2 Advanced Organizer Welche technischen Grundlagen liegen der heutigen E-Mail-Infrastruktur zugrun- de? Diese Frage wollen wir in diesem Studienbrief einleitend klären. Wir werden hier die Protokolle SMTP, IMAP und POP3 einführen, die bereits aus Netzsicher- heit 2 bekannt sind. Darüber hinaus werden wir uns anschauen, welchen Anreiz ein Spammer hat, Spam-Mail zu versenden und wie eine Mail als Spam spezifiziert wird.

1.3 Einleitung Elektronische Post (kurz E-Mail genannt) ist heutzutage ein beliebtes Kommunika- tionsmedium. Die E-Mail vereinigt die Vorteile der synchronen und asynchronen Kommunikation, da sie im Allgemeinen, im Gegensatz zum gedruckten Brief, mit nur geringen Kosten und fast ohne Zeitverzögerung zugestellt werden kann und auch vom Empfänger abrufbar ist, sobald dieser sich dazu entscheidet.

Seit Jahrzehnten wird die Kommunikation via E-Mail jedoch durch Spam er- schwert, indem der Großteil der verschickten und empfangenen E-Mails nicht mehr aus erwünschten, sondern aus unerwünschten Spam-Nachrichten besteht. Im schlimmsten Fall kann der Empfang von erwünschten Nachrichten sogar soweit beeinträchtigt werden, dass diese durch Spam-Filter fälschlicherweise als Spam erkannt und somit aussortiert werden. In der Literatur werden unterschiedliche Angaben zum Anteil von Spam am gesamten E-Mail Aufkommen gemacht. Dabei wird generell von mindestens 70 % Spam ausgegangen (vgl. Abbildung 1.2 auf Seite 15).

Die Folgen von Spam sind vielfältig: Im privaten Bereich ist Spam hinderlich, da die ungewollten E-Mails teilweise mühevoll per Hand aussortiert werden müssen. Im geschäftlichen Umfeld ist Spam jedoch für einen nicht unerheblichen wirt- schaftlichen 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 wer- den, damit der Transport und die Verarbeitung von erwünschten E-Mails nicht zu sehr beeinflusst wird. Dagegen steigt die Unzufriedenheit eines Kunden, wenn ein Anbieter nicht auf eine für den Kunden wichtige Nachricht reagiert. Der Kunde kann in diesem Fall nicht wissen, ob seine Nachricht wirklich zugestellt oder durch einen Filter entfernt wurde und der Anbieter daraufhin gar nicht in der Lage ist, auf die Nachricht zu antworten.

Das vorliegende Modul hat die Aufgabe, dem Leser sowohl einen breiten Überblick über das Thema Spam zu verschaffen, als auch einzelne besonders interessante Aspekte genau zu betrachten. Dabei werden zum einen Grundlagen vermittelt, die Seite 10 Studienbrief 1 Grundlagen

den Leser dazu schulen, Zusammenhänge und Techniken zu verstehen. Zum an- deren werden aber auch aktuell Forschungsprojekte aufgegriffen und besprochen, die einen Einblick in ausgeklügelte Methoden und Ansätze vermitteln.

1.3.1 E-Mail Wie bereits im obigen Text beschrieben, handelt es sich bei E-Mails (engl.: elec- tronic mail) um elektronische Nachrichten, die in Computernetzen verschickt und empfangen werden. Dabei ist das größte Computernetz ohne Zweifel das weltumspannende Internet und somit ist es mit Hilfe von E-Mail möglich, eine Nachricht mit kaum merkbarem Zeitverzug an jeden beliebigen Ort auf der Erde zu verschicken, der über einen Zugang zum Internet verfügt. Konkreter wird im Abschnitt 1.5 auf die E-Mail und die dazu benötigte Infrastruktur eingegangen.

Es existieren verschiedene Definitionen für den Begriff E-Mail. Der Duden be- schreibt die E-Mail bspw. mit [..] elektronischer Daten- und Nachrichtenaustausch über Computer[..] (vgl. ?). Innerhalb dieser Studienbriefe gilt die folgende Definition 1.1.

Definition 1.1: E-Mail D Eine elektronische Nachricht, die innerhalb eines Computernetzes ver- schickt wird und deren Syntax konform zu RFC 822 (vgl. ?) ist, wird als E-Mail bezeichnet.

Der Begriff RFC wird in Abschnitt 1.3.3 ab Seite 15 behandelt. Insgesamt hat die E-Mail folgende Vorteile gegenüber normaler Post:

• Eine E-Mail gelangt innerhalb von Sekunden vom Versender zum Empfän- ger. • 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 eine gewissen Pseudonymität, teilweise sogar An- onymität. Je nach verwendetem Anbieter ist es möglich, nicht den eigenen Namen zu verwenden, sondern einen eigenen Absender zu wählen. Hier- durch ist es nur noch für den Domain-Inhaber möglich, von der Adresse auf den Absender zu schließen. Es existieren aber auch Dienste im Internet, die eine E-Mail-Adresse ohne vorherige Anmeldung anbieten, sogenann- te 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 mit Hilfe von Software einfach nach bestimmten Suchbegriffen oder Kriterien hin durchsuchbar. Daher können sehr schnell benötigte Informa- tionen gefunden werden. 1.3 Einleitung Seite 11

• Es ist außerdem problemlos möglich, E-Mails mit Anhängen zu versehen, die dann mitübertragen werden. • Weiterhin ist die Beantwortung einer E-Mail deutlich einfacher als bei nor- maler Post. Hier liegen die gleichen Vorteile wie beim Verfassen von E-Mails, wie bspw. Zeit und Kosten.

Im Folgenden wird auf einen Teil des E-Mail-Aufkommens eingegangen, der mit Spam benannt wird und Hauptgrund für die vorliegenden Studienbriefe ist.

1.3.2 Spam Der Begriff Spam bezeichnet in der Regel unerwünschte elektronische Nachrichten, die auf der einen Seite Werbung verbreiten sollen. Auf der anderen Seite wird Spam allerdings auch zum sogenannten Phishing verwendet. Dabei werden E- Mails verschickt, die suggerieren, dass sie von einer offiziellen Stelle, oft einer Bank, verschickt wurden und den Kunden dazu auffordern, bspw. seine Benutzerdaten zu verifizieren. Die E-Mails stammen jedoch von Betrügern, die die Empfänger durch Verweise in der E-Mail auf ihre präparierte Internet-Seite locken wollen, um dort an persönliche Daten zu gelangen - im besten Fall auch an PIN und TAN für die Konten der Empfänger. Phishing wird weiter in Abschnitt 1.9 ab Seite 36 behandelt.

Es existieren verschiedene Definitionen, um den Begriff Spam exakt zu fassen. Eine der am weitesten verbreiteten Definitionen, die innerhalb dieses Moduls verwendet wird, ist auch auf den Internetseiten des Spamhaus Projects (?) zu finden:

Definition 1.2: Spam D Eine Nachricht wird genau dann als Spam bezeichnet, wenn sie sowohl unerwü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ünsch- Unsolicited Bulk Email, te Massenmail, bezeichnet. Als Abgrenzung dazu bezeichnet der Begriff HAM HAM erwünschte bzw. reguläre E-Mail-Nachrichten.

Begriffsherkunft Ursprünglich wurde das von der amerikanischen Firma Hormel Foods Corpo- ration ab dem Jahr 1937 hergestellte Dosenfleisch als SPAM® (SPiced hAM, vgl. Abbildung 1.1) bezeichnet, nachdem der Name bei einem Wettbewerb durch einen der Teilnehme vorgeschlagen wurde.

Während des Zweiten Weltkriegs wurden von der Hormel Foods Corporation mehr als 100 Millionen Pfund SPAM® an die Alliierten verschifft (?), 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. Seite 12 Studienbrief 1 Grundlagen

Abb. 1.1: SPAM (?).

Bis heute verkaufte die Hormel Foods Corporation mehr als sieben Milliarden Dosen SPAM®. Als wichtige Randnotiz sollte angemerkt werden, dass der Begriff SPAM® ein registriertes Markenzeichen der Firma Hormel Foods Corporation ist, wohingegen unerwünschte Werbung als Spam bezeichnet wird (vgl. Schreibwei- se).

Neben der in diesem Modul behandelte Art von Spam in Form von E-Mails exis- tieren 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 ver- sendet werden. Dies geschieht bspw. auch bei Sofortnachrichtendienste (Instant Messenger). Da viele Anbieter von Sofortnachrichtendiensten ein Verzeichnis ihrer Nutzer bereitstellen, in denen persönliche Informationen wie Alter und Geschlecht erfasst sind, ist es für Werbende denkbar einfach, personenbezogene Werbung zu verschicken. Die meisten Protokolle, die für Sofortnachrichtendienste verwendet werden, sind jedoch proprietärer Art und können auf Wunsch des Herstellers verändert und aktualisiert werden. Daher kann auf Schwachstellen eingegangen werden, um den unerwünsch- ten Versand von Nachrichten einzuschränken. Viele Softwareprodukte bie- ten daher die Möglichkeit, dass der Nutzer Nachrichten ausschließlich von bereits bekannten Kontakten erhält und sich neue Kontakte erst beim Nutzer anmelden müssen, um diesem Nachrichten schicken zu können.

Exkurs 1.2: Mobile-Phone-Spam 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 die sich Nutzer wenden können, sofern sie durch Spam auf ihrem Mobiltelefon belästigt werden. 1.3 Einleitung Seite 13

Exkurs 1.3: Foren-Spam E Internet-Foren werden generell zum asynchronen Austausch von Infor- mationen genutzt. Dabei kann eine beliebig große Anzahl an Teilnehmern Beiträge zu einem Thema veröffentlichen, die dann linear innerhalb einer Internetseite dargestellt werden. Um Beiträge Teilnehmern zuzuordnen, müssen sich die Teilnehmer, die Beiträge veröffentlichen wollen, an das System anmelden. Schadsoftware, insbesondere Spam Bots, können die oft- mals einfache Anmeldung an ein Forum automatisieren, um zu beliebigen Beiträgen eigene Nachrichten zu erstellen, die zwar nichts mit dem Thema des Beitrags zu tun haben, als Inhalt aber Werbung in Form von Links zu anderen Internetseiten enthalten. Gegen diese als Foren-Spam bekannte Art von Spam gibt es Gegenmaßnahmen, die zum einen bei der Erstellung von Nutzerkonten greifen, zum anderen aber auch bei der Erstellung von Beiträgen. So müssen nun Nutzer sogenannte CAPTCHAs (Completely Au- tomated 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 inner- halb der Spielewelt untereinander kommunizieren. Oft gehört diese Art der Kommunikation auch zum Konzept des Spiels. Gegeben durch diesen Anlass können auch Nachrichten verschickt werden, die nicht zum Spielge- schehen dazu gehören, sondern bspw. Waren innerhalb aber auch außerhalb des Spiels anbieten. Diese Art des Spam wird auch als Online-Game Spam bezeichnet und findet sich häufig innerhalb von MMORPGs (Massively Multiplayer Online Role-Playing Game).

Exkurs 1.5: Spamdexing E Eine weitere Form des Spams 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 zunutze, um den Suchindex zu manipulieren. Das Ziel davon besteht darin, bestimmte Seiten im Index so weit wie möglich an die Spitze der Ergebnisse zu bringen, damit sie von Benutzern möglichst häufig besucht werden.

Exkurs 1.6: Blog-, Wiki- und Gästebuch-Spam 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öglich- keit, Telefongespräche kostenlos über das Internet zu führen, entstanden auch Möglichkeiten, das System für unerwünschte, automatisch angewählte und im Vorhinein aufgezeichnete Anrufe zu nutzen. Diese Verbreitung wird als SPam over Internet Telephony (SPIT), oft aber auch als Voice-over-IP Spam (VoIP-Spam) bezeichnet. Wobei auch hier Gegenmaßnahmen existie- ren.

Exkurs 1.8: Academic Search Spam E Im akademischen Bereich werden oft unterschiedliche Suchmaschinen genutzt, um wissenschaftliche Literatur zu finden und auch um die Wichtig- keit 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 (?). So war es auch möglich, als Treffen für eine Suche nach wissenschaftlichen Artikeln Werbung anzuzeigen.

Ursprung von Spam Open Relay Spam kann unterschiedliche Ursprünge haben und hat sich im Laufe der Zeit an die gegebenen Möglichkeiten angepasst. Wie im Folgenden noch veranschaulicht wird, wird ein Dienstanbieter benötigt, um E-Mails zu verteilen. Ursprünglich sah die Standardkonfiguration dieser Server vor, dass man E-Mails über einen Dienstanbieter versenden kann, auch wenn man sich nicht vorher als regulärer Nutzer authentifiziert hatte. Dieses als Open Relay bekannte Verhalten machten sich schon frühzeitig Spammer zunutze, um unbemerkt und anonym Spam zu verbreiten. Durch die Möglichkeit, sich nicht authentifizieren zu müssen, konnten beliebige Absenderadressen gewählt werden, um E-Mails zu maskieren. Eine recht einfache aber wirkungsvolle Methode, das Problem der Open Relays zu beheben, besteht darin, das Open Relay über seine IP-Adresse zu identifizieren, um Nachrichten, die von ihm aus verschickt werden, direkt zu blockieren.

Open Proxy Weiterhin existieren in den Anfangszeiten des Internets sehr viele Server, die beliebige Informationen auf freigegebenen Ports weiterleiteten und dabei die Quell- 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 Anbieter geben darüber hinaus auch weiteren Nutzern die Möglichkeit, ein E- Mail-Konto zu eröffnen, da sie sich bspw. daraus einen höheren Bekanntheitsgrad erhoffen. Dadurch bedingt, dass es möglich ist, sich anonym ein E-Mail-Konto zu erstellen, können nun Spammer beliebig viele Konten erstellen, um ihre uner- wünschten Massenmails zu versenden. Dies kann jedoch wiederum durch den Anbieter erkannt werden, sobald dieser zu Beispiel die Anzahl der ausgehenden E-Mails überprüft und ab einen bestimmten Schwellwert das Konto sperrt. Daher 1.3 Einleitung Seite 15 gibt es einen weiteren Bereich, der heutzutage vorherrschend als Ursprung von Spam betrachtet wird.

Malware ist die Kurzform der englischen Begriffe malicious software (dt.: bösartige Malware, Botnetz Programme) und ist ein Oberbegriff für sämtliche schadhafte Software. Unter diesen Begriff fallen Viren, Würmer, trojanische Pferde und viele weitere. Eine Schadsoftware, die über eine Sicherheitslücke ein Computersystem befällt, kann nicht nur lokale Informationen auf dem System auslesen und ändern, sondern auch Netzwerkverbindungen aufnehmen. Mithilfe dieser Funktionalität kann eine solche Schadsoftware den Rechner aus der Ferne steuern und auch neue Befehle nachladen. Werden mehrere dieser Bots über einen Server zusammengeschlossen, so ergibt sich ein Botnetz, das aus vielen tausenden Computersystemen bestehen kann und durch den Botmaster gesteuert wird. Eine mögliche Schadfunktionalität kann dabei der Versand von Spam sein, wobei dem vorausgehend bereits über eine andere Schadfunktion das Adressbuch des Nutzers des Computersystems ausgelesen worden sein kann, damit die Spam-Nachrichten an existierende E-Mail- Konten versendet werden. Heutzutage sind Botnetze aufgrund ihrer Flexibilität und sehr schlechten Blockierbarkeit die häufigste Ursache von Spam.

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

Abb. 1.2: Der Anteil von Spam am gesamten E- Mail-Aufkommen nach ?.

Einen Überblick über den Verlauf des Spamanteils im gesamten E-Mailverkehr von 2006 bis 2012 liefert Abbildung 1.2 (vgl. ?). Zu erkennen ist zum einen, aus welchen Ländern Spam hauptsächlich verschickt wird und zum anderen, dass es immer wieder Schwankungen gibt, die bspw. durch die Übernahme von Botnetzen zu erklären sind (vgl. Abschnitt 3.12 ab Seite 95).

1.3.3 RFC (Request for Comments) Requests for Comments (dt.: Bitte um Kommentare) sind Dokumente, die tech- nische Standards im Internet dokumentieren und spezifizieren (vgl. ?). Im ur- sprünglichen Sinne waren die Dokumente dazu gedacht, von anderen Entwicklern Kommentare zu Ideen zu erhalten, um einen Standard zu erstellen. Innerhalb der darauffolgenden Diskussionen soll eine Idee soweit entwickelt werden, dass daraus ein möglichst fehlerfreier Standard wird. Das endgültige Dokument, das als Standard betrachtet wird, wird weiterhin Request for Comments (RFC) genannt. Spätere Änderungen an RFCs sind nicht möglich. Mögliche Fehler können als RFC Seite 16 Studienbrief 1 Grundlagen

Errata angegeben werden und dem Dokument angefügt werden, jedoch darf das Dokument nicht verändert werden. Wird ein Standard erweitert, so müssen diese Erweiterungen innerhalb einer neuen RFC beschrieben werden. Die Erweiterung kann auch die vorherige RFC umdefinieren, womit die alte RFC obsolet wird. RFCs werden fortlaufend durchnummeriert, um zum einen exakte Referenzierung zu ermöglichen und zum anderen zeitliche Abhängigkeiten kenntlich zu machen. Daraus bedingt ist es möglich, dass zu einem Standard mehrere RFCs existieren, die alle gleichzeitig gültig sein können.

Innerhalb dieses Moduls werden oft bestimmte RFCs referenziert und beschrieben, da Wert auf exakte Informationen gelegt wird. Der Leser ist dazu angehalten, die RFCs als weiterführende Literatur zu betrachten und diese bei Verständnisproble- men als Hilfe zu verstehen.

1.3.4 Gliederung Das gesamte Modul ist in vier Studienbriefe gegliedert. In diesem ersten Stu- dienbrief 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ün- de gibt, warum Spam immer noch existent ist, obwohl es schon seit Jahrzehnten Lösungen gibt. Anschließend wird innerhalb einer Fallstudie berichtet, wie das Geschäft mit dem Versand von Spam funktioniert.

Der zweite Studienbrief befasst sich ab Seite 45 mit Spam-Techniken. Hier wird beschrieben, wie Spam anfangs verbreitet wurde, welche Techniken die anfängli- chen Versuche ablösten und was aktuell für das Spam-Aufkommen verantwortlich ist.

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

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

1.3.5 Kontrollaufgaben In diesem Abschnitt befinden sich verschiedene Kontrollaufgaben, welche die Inhalte der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffes beitragen sollen.

Kontrollaufgabe 1.1: Vorteile von E-Mails K Geben Sie die drei Hauptvorteile von E-Mails im Vergleich zur gewöhnli- chen Post an. 1.4 Internet Seite 17

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.

1.4 Internet Das Internet ist ein Netz von Computersystemen, das über die ganze Welt verteilt ist und somit einen weltweiten Datenaustausch ermöglicht. Aufbauend auf diesem Netz wurden verschiedene Dienste implementiert, von denen das World Wide Web (WWW) vermutlich der bekannteste Teil des Internets ist. Innerhalb des WWW können Informationen von zentralen Servern abgerufen und auch von Nutzern bereitgestellt werden. Ein weiterer bekannter Dienst des Internets ist die E-Mail, die maßgeblicher Bestandteil dieses Moduls ist. Die E-Mail soll das digitale Gegenstück zum analogen Brief sein. Mithilfe dieses Dienstes wird versucht, die positiven Eigenschaften von Briefen zu übernehmen und gleichzeitig die negativen Eigenschaften zu beseitigen.

1.5 E-Mail-Infrastruktur E-Mails nutzen zwar das Internet, um vom Sender zum Empfänger zu gelangen, jedoch mussten dazu Designentscheidungen getroffen sowie Protokolle entwickelt werden, die sich um das Behandeln der Daten kümmern. Daher wird im Folgen- den beschrieben, welche Infrastruktur für den Transport von E-Mails im Internet notwendig ist, wie E-Mails aufgebaut sind und wie die benötigten Protokolle dafür definiert sind.

1.5.1 Kommunikationsmodell Der Zweck einer E-Mail besteht darin, Informationen von einem Sender zu einem Peer-to-Peer-Modell, Empfänger zu schicken. Dazu wäre es theoretisch ausreichend, wenn es eine Di- Client-Server-Modell rektverbindung zwischen Sender und Empfänger geben würde und der Sender die Daten direkt zum Empfänger schickt. Dieses direkte Kommunikationsmodell wird als Peer-to-Peer-Modell bezeichnet, bei der auf eine zentrale Instanz verzichtet wird. Solange beide Kommunikationspartner immer erreichbar sind, wäre es denkbar, ein solches Kommunikationsmodell zu verwenden. Jedoch besteht ein zentrales Ziel der E-Mail-Kommunikation darin, dass das gesamte System asynchron ver- wendet werden können soll. Um dieses Ziel zu erreichen, müsste der Sender so lange mit dem Transfer der Nachricht warten, bis der Empfänger erreichbar ist, um die Informationen zu erhalten. Im allgemeinen Fall möchte der Sender seinen Computer allerdings nach Beendigung der Arbeit ausschalten können, was nur Seite 18 Studienbrief 1 Grundlagen

dann möglich ist, wenn er auf das Versenden der E-Mail verzichtet. Der Empfänger möchte weiterführend auch, dass ein Sender E-Mails an ihn verschicken kann, auch wenn er aktuell Probleme mit seiner Internetverbindung hat. Daraus ergibt sich die Notwendigkeit einer zentralen Instanz und der Verwendung des Client- Server-Modells. In diesem Fall existiert ein Server, der immer verfügbar ist und die Nachricht eines Sender annimmt, um sie später an dem Empfänger weiter zu reichen, sobald dieser verfügbar ist.

Die im Internet verwendete E-Mail-Infrastruktur verwendet das Client-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 Modells notwendig.

Abbildung 1.3 stellt beispielhaft dar, wie eine E-Mail von einem Empfänger zu einem Sender gelangt und zeigt dabei auch die verwendeten Protokolle, von denen das Simple Mail Transfer Protocol (SMTP), das Post Office Protocol Version 3 (POP3) sowie das Domain Name System (DNS) im späteren Verlauf dieses Studienbrief genauer vorgestellt werden.

Abb. 1.3: UML- MUA (A) SMTP Server (A) NS Server (B) POP3/SMTP Server (B) MUA (B) Sequenzdiagramm ei- ner beispielhaften E- E-Mail Versand an eigenen Server. Mail-Sitzung, bei der Nutzer A mit seinem SMTP Mail-User-Agent (MUA) DNS Anfrage nach Adresse des eine E-Mail an Nutzer Mail-Servers von B. B schickt. An den Pfei- DNS

len stehen die jeweils DNS Antwort mit Adresse des verwendeten Protokolle. Mail-Servers von B. DNS

E-Mail Versand an Mail-Server von B. SMTP

Mail-Server von B wartet auf Anfrag von B. Anfrage nach neuen E-Mails von B an eigenen E-Mail-Server. POP3

Gespeicherte E-Mail von A wird ausgeliefert. POP3

1.5.2 Aufbau von E-Mails RFC 5322, US-ASCII E-Mails sind strukturell in zwei Teile unterteilt: Es existiert zum einen ein Header, der wichtige Informationen für den Transport enthält, sowie ein Body, der den Inhalt der E-Mail beinhaltet. Grundlegend wurde der Aufbau von E-Mails durch die Internet Engineering Task Force (IETF) im aktuellen Request for Comments (RFC) 5322 (?) spezifiziert, der jedoch durch weitere RFCs bzgl. Internationalisie- rung erweitert wurde. Ein weiterer wichtiger Punkt zum generellen Aufbau von E-Mails ist, dass E-Mails nur aus druck- bzw. lesbaren Zeichen sowie wenigen Steuerzeichen wie Zeilenumbruch, Leerzeichen und Tabulator (US-ASCII, vgl. Ex- kurs 1.9) bestehen. Das bedeutet zum einen, dass E-Mails ohne weitere Hilfsmittel per Hand von Menschen ausgewertet werden können, da sie nicht die volle Breite eines Bytes von 28 = 256 möglichen Belegungen ausnutzen. Zum anderen können 1.5 E-Mail-Infrastruktur Seite 19 dadurch Binärdateien nicht ohne eine Transformation übertragen werden, bei wel- cher der Anhang vom Binärformat in ein kompatibles Format vor der Übertragung 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 druckbare sowie 95 druckbare Zei- chen 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 das A an Position 65 und wird somit als Binärstring 01000001 übertragen.

Da nur 128 Zeichen definiert sind, ein Byte aber 256 mögliche Reprä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 (?) sind Header-Felder, Zeilen, die mit einem Namen gefolgt von einem Doppelpunkt beginnen, und nach einem Feldinhalt durch einen Zeilenum- bruch (CRLF) beendet werden. Der Feldinhalt darf keinen Zeilenumbruch enthal- ten, 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. Da- bei enthalten unstrukturierte Header-Felder einen Inhalt, der zwar aus druckbaren Zeichen bestehen muss, allerdings keinen weiteren syntaktischen Regeln genügen muss. Im Gegensatz dazu müssen strukturierte Header-Felder syntaktisch nach bestimmten Regeln aufgebaut sein. Zur Optimierung der lexikalischen Analyse von Nachrichten existieren jedoch Regeln zur maximalen Länge einer Zeile. Diese besagen, dass Zeilen nicht länger als 78 Zeichen lang sein sollten und nicht länger als 998 Zeichen lang sein dürfen. Um trotzdem längere Header-Zeilen zu erlauben, wird die Regel eingeführt, dass für jedes syntaktisch korrekte Leerzeichen inner- halb des Inhaltes eines Headers anstelle dessen auch ein Zeilenumbruch vor dem Leerzeichen eingefügt werden kann. Mögliche Header-Felder sind from, sender, to sowie subject.

Body Die RFC 5322 definiert auch syntaktisch den Inhalt des Body-Teils einer E-Mail. An diesen Teil werden nur zwei Anforderungen gestellt.

1. Die Steuerzeichen CR (carriage return = Wagenrücklauf) und LF (line feed = Zeilenvorschub) dürfen nur direkt hintereinander stehen, aber nicht einzeln im Body vorkommen. 2. Zeilen sollten eine Länge von 78 Zeichen nicht überschreiten und dürfen maximal 998 Zeichen lang sein. Seite 20 Studienbrief 1 Grundlagen

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 vom Body. Ohne eine solche Leerzeile enthält eine E-Mail keinen Body, sondern nur einen Header. Die zweite Leerzeile definiert das Ende der E-Mail und ist somit auch syntaktisch von essenzieller Wichtigkeit.

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

1.5.3 SMTP (Simple Mail Transfer Protocol) RFC 821, 5321, SMTP wurde erstmals in RFC 821 (?) im Jahre 1982 spezifiziert und ist ein Kernele- RFC 854, RFC 855 ment der E-Mail-Kommunikation. Über die Jahre wurden einige Erweiterungen und Verbesserungen eingepflegt, die letztendlich durch RFC 5321 (?) spezifiziert sind. Das Protokoll hat grundsätzlich zwei Funktionen. Zum einen wird es ver- wendet, um E-Mails in das System einzuschleusen. In diesem Fall meldet sich ein Client bei einem Server an und definiert innerhalb dieser Sitzung eine E-Mail, die der Server lokal speichert. Zum anderen wird das Protokoll auch verwendet, um eine Kommunikation zwischen verschiedenen Servern zu ermöglichen. Dies ist bspw. dann notwendig, wenn Server A von einem Client eine E-Mail erhalten hat, das Konto des Empfängers sich allerdings nicht auf demselben Server befindet. In diesem Fall baut Server A eine Verbindung zu Server B auf und leitet die E-Mail entsprechend weiter, damit Server B die E-Mail daraufhin in das richtige Postfach einsortieren kann. Das Protokoll baut, ähnlich wie auch die E-Mail selbst, auf der US-ASCII-Zeichenkodierung (vgl. Exkurs 1.9) auf und ist somit von Menschen lesbar und auch interpretierbar. Daraus resultierend kann eine SMTP-Sitzung auch mit Hilfe des Telnet-Protokolls (vgl. ??) initiiert werden und vollständig ohne weite- re Software ausgeführt werden. Abbildung 1.4 auf Seite 41 stellt eine SMTP-Sitzung beispielhaft dar.

RFC 959 SMTP definiert für die Kommunikation mehrere Status-Codes, die auf den Status- Codes des File Transfer Protocols (FTP) (vgl. ?) basieren, allerdings nicht vollständig identisch sind. Dabei sind Status-Codes immer dreistellig und sind als Rückgabe des Servers an den Client konzipiert, damit dieser entweder auf Fehler reagieren kann oder sich vergewissern kann, dass ein Befehl ordnungsgemäß ausgeführt wurde. 1.5 E-Mail-Infrastruktur Seite 21

Im folgenden Exkurs 1.10 werden die SMTP-Status-Codes detaillierter beschrie- ben.

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 Ziffern stehen: 2yz Die Antwort bestätigt den vom Client gesendeten Befehl und zeigt auf, dass der Befehl vollständig ausgeführt wurde. 3yz Die Antwort bestätigt den vom Client gesendeten Befehl, allerdings werden zur vollständigen Verarbeitung weitere Informationen vom Client benötigt. Andernfalls kann der Befehl nicht vollständig verar- beitet werden. 4yz Eine vorübergehende negative Antwort: Der Befehl wurde nicht um- gesetzt und die angefragte Aktion konnte temporär nicht ausgeführt werden. Der Sender soll mit dem Befehl erneut beginnen, damit die- ser 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 umge- setzt, die angefragte Aktion kann nicht ausgeführt werden und der Client soll die gleiche Anfrage auch nicht erneut an den Server sen- den. Dieser Fall tritt ein, wenn bspw. die Syntax des Clients nicht dem Standard entspricht.

Die zweite Ziffer teilt die Status-Codes in weitere Kategorien ein:

x0z Der übersendete Befehl enthält einen syntaktischen Fehler. x1z Für den übersendeten Befehl existieren weitere Informationen, bspw. ein Status oder eine Hilfe. x2z Der Status betrifft den Übertragungskanal. x3z Nicht spezifiziert. x4z Nicht spezifiziert. x5z Der Status betrifft das empfangende Mail-System.

Die dritte Stelle ist letztendlich zur Abgrenzung einzelner Status-Rückgaben gedacht, die durch die zweite Stelle nicht genau genug spezifiziert werden konnten. Seite 22 Studienbrief 1 Grundlagen

Im folgenden Beispiel werden einige mögliche Rückgabewerte angeführt.

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

Es gibt jedoch verschiedene Erweiterungen für SMTP, um das Protokoll gegen verschiedene Arten von Angriffen abzusichern. Um eine Nutzerauthentifizierung zu erreichen, wurden drei verschiedene Ansätze verfolgt. Im Einzelnen sind dies SMTPS, SMTP-After-POP sowie SMTP-Auth.

RFC 2487 SMTPS ist eine Erweiterung, die in RFC 2487 (vgl. ?) 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 Nut- zerauthentifizierung verwendet, um nach der erfolgreichen Authentifizierung auch E-Mails versenden zu können.

RFC 2554, RFC Aufgrund einer relativ aufwendigen Implementierung wird heutzutage allerdings 4954, RFC 4616 oftmals eher SMTP-Auth verwendet, das erstmals in RFC 2554 (vgl. ?) definiert wur- de. RFC 4954 ist eine Überarbeitung davon und gilt als vorgeschlagener Standard (vgl. ?). SMTP-Auth beschreibt fünf verschiedene Möglichkeiten zur Authentifi- zierung. Zum einen wird die PLAIN-Authentifizierung vorgeschlagen, die als RFC 4616 (vgl. ?) die RFC 2595 (vgl. ?) erweitert. Bei dieser Möglichkeit der Authentifi- zierung werden Benutzername und Passwort zwar nicht im Klartext (engl.: plain) übertragen, da sie Base64-kodiert (vgl. Exkurs 1.11) werden, jedoch ist eine Base64- 1.5 E-Mail-Infrastruktur Seite 23

Kodierung keine Verschlüsselung, da diese Funktion ohne Passwort auskommt und invertierbar ist (vgl. Merksatz 1.1).

Exkurs 1.11: Base64-Kodierung E Die Base64-Kodierung wird neben der Base16- und Base32-Kodierung in RFC 4648 der RFC 4648 (vgl. ?) 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 einzel- ne Block umgewandelt. Die folgende Tabelle dient dabei der Zuordnung zwischen dem Wert W, also der dezimalen Darstellung einer 6 Bit langen Zeichenkette und dem dafür zu verwendenden Code C:

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 fol- genden Speicherplatz: n + 2 4 ∗ 3

Enthält die letzte umzuwandelnde Gruppe nur 1 Byte, so wird der resul- tierende Block mit zwei padding-Zeichen (=) aufgefüllt. Enthält die letzte umzuwandelnde Gruppe 2 Byte, so wird ein padding-Zeichen angefügt.

Merksatz 1.1: Base64-Kodierung 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. Seite 24 Studienbrief 1 Grundlagen

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.

RFC 2195, RFC Als drittes Verfahren gilt das in RFC 2195 (vgl. ?) als CRAM-MD5 vorgestellte 1321, RFC 2104 Verfahren. CRAM-MD5 steht für Challenge-Response Authentication Mechanism, Message Digest 5 und ist demnach ein Authentifizierungsverfahren, das nach dem Challenge-Response-Prinzip (vgl. auch Abschnitt 3.7 ab Seite 80) funktioniert und auf dem MD5-Algorithmus (vgl. ? basiert. Grundsätzlich verwendet CRAM-MD5 in drei Schritten:

1. Der Server sendet eine Zeichenkette (Challenge) an den Client. Diese Zei- chenkette muss einen Zeitstempel und den vollständigen Hostnamen des Servers enthalten. Außerdem sollen noch willkürliche Ziffern enthalten sein, um die Zeichenkette möglichst einmalig zu machen. 2. Der Client antwortet mit einer Zeichenkette, die wie folgt erzeugt wird: a) Die Zeichenkette vom Server wurde mit dem Base64-Verfahren ko- diert. Daher muss die Zeichenkette dekodiert werden. b) Die dekodierte Zeichenkette wird per HMAC-MD5 (vgl. ?) mit dem Passwort des Nutzers verschlüsselt. c) Die verschlüsselte Zeichenkette wird in eine hexadezimale Zeichen- kette überführt. d) Der Nutzername sowie ein Leerzeichen werden der hexadezimalen Zeichenkette vorangestellt. e) Die resultierende Zeichenkette wird Base64-kodiert und an den Server verschickt. 3. Der Server verwendet dieselbe Methode wie der Client, und vergleicht sein Ergebnis mit der vom Client übertragenen Zeichenkette. Falls beide Zeichenketten gleich sind, dann war die Authentifizierung erfolgreich.

Durch dieses Vorgehen entstehen drei verschiedene Sicherheitsaspekte: 1.5 E-Mail-Infrastruktur Seite 25

1. Es ist für dritte nicht möglich, den generierten Hash zu duplizieren, ohne Authentifizierung das verwendete Passwort zu kennen. Dadurch wird die Authentifizierung ermöglicht. 2. Ein Replay-Angriff ist für Angreifer nicht möglich, da die Zeichenkette, Replay-Angriff 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. Als weiterer Sicherheitsaspekt ist es für Angreifer, die den Netzwerkverkehr Verschwiegenheit belauschen, nicht möglich, aus den gelesenen Informationen das Passwort zu erlernen. Diese Eigenschaft wird als Verschwiegenheit bezeichnet.

Die beiden letzten Verfahren sind das in RFC 5802 (vgl. ?) spezifiziert SCRAM- RFC 5802 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-Office-Protokoll in Version 3.

1.5.4 POP3 (Post Office Protocol Version 3) Im Gegensatz zu dem im vorherigen Abschnitt vorgestellten SMTP, ist POP3 kein RFC 918, RFC 1034, DNS Protokoll zum Versand von E-Mails. Es wird vielmehr zum Abholen von E-Mails verwendet, basiert aber ebenfalls wie SMTP auf der US-ASCII-Zeichenkodierung (vgl. Exkurs 1.9) und ist somit von Menschen lesbar. Die erste RFC, die das Protokoll spezifiziert, ist RFC 918 aus dem Jahr 1984 (?). Wie die Einleitung der RFC bereits schreibt, war das Protokoll dazu gedacht, mithilfe eines Arbeitsplatz-Computers (Workstation) dem Nutzer Zugriff auf E-Mails zu geben, die auf einem E-Mail- Server liegen. Zwar wäre es für einen Nutzer auch möglich, seinen eigenen Com- puter mithilfe entsprechender Software als SMTP-Server zu konfigurieren, der Betrieb wäre jedoch aus mehreren Gründen sehr schwierig. Zum einen kann ein Nutzer nicht sicherstellen, dass sein Computer jederzeit erreichbar ist, was den Empfang von E-Mails erschweren kann. Zum anderen verfügen nur wenige Nutzer über eine statische IP-Adresse, da sie oftmals durch eine DSL-Verbindung mit dem Internet verbunden sind und der ISP (Internet Service Provider) nach der Zwangstrennung dem Nutzer eine neue IP-Adresse zuweist. Nach der Zuweisung einer neuen IP-Adresse müsste dann der MX-Record für die Domäne des Nutzers angepasst werden und auch im Domain Name System (DNS, vgl. ????, siehe auch Abschnitt 1.5.6 ab Seite 30) entsprechend verteilt werden, damit neue E-Mails an die richtige Adresse gehen. Aufgrund der eben genannten Eigenschaften ist ein eigener SMTP-Server im Heimnetzwerk für viele Nutzer keine Option, wodurch dann die Möglichkeit des E-Mail-Abrufs per POP3 ins Spiel kommt.

Abbildung 1.6 auf Seite 43 zeigt eine POP-Sitzung. Zu erkennen ist die Authentifi- RFC 1939 kation im ersten Schritt nach dem Verbindungaufbau, was POP3 zu etwas mehr Sicherheit verhilft. Es ist zwar mithilfe von SMTP möglich, E-Mails in das System unter falschem Namen einzuschleusen, jedoch kann nur derjenige, der die Zu- gangsdaten für ein Konto hat, die eingetroffenen E-Mails auch abrufen. Nach vielen Detailverbesserungen ist RFC 1939 (?) die letzte und aktuelle Spezifikation von POP3. Sicherheitskritisch ist dabei jedoch zu beachten, dass auch in diesem Proto- koll die Kommunikation unverschlüsselt stattfindet und somit abgehört werden kann. Das Passwort wird zusätzlich im Klartext übertragen, wodurch nicht nur die Inhalte der übertragenen E-Mails an den einzelnen Knoten der Datenübertragung sichtbar waren, sondern auch alle notwendigen Informationen über das Benutzer- konto. POP3 sollte daher nicht in unbekannten oder nicht vertrauenswürdigen Netzwerken ohne separate Absicherung verwendet werden. Seite 26 Studienbrief 1 Grundlagen

Die Basisoperationen von POP3 lassen sich innerhalb von wenigen Punkten beschreiben und aus Zustandsgraph visualisieren (vgl. Abbildung 1.5). Der POP3-Server wartet auf einen Verbindungsaufbau von einem Client (Zustand: WAITING_FOR_CONNECTION). Nachdem der Client eine Verbindung aufgebaut hat, sendet der Server eine Willkommensnachricht an den Client (Zustand: AUTHORIZATION). Der Client muss sich daraufhin am Server authentifizieren, damit der Server die Verbindung zum richtigen Postfach herstellen kann (Zustand: TRANSACTION). Daraufhin tauschen Server und Client solange Nachrichten aus, bis die Verbindung geschlossen oder abgebrochen wird (Zustand: Update). Nachdem der Server das QUIT-Kommando erhalten hat, gibt es die zuvor reservierten Ressourcen wieder frei (Zustand: UPDATE) und beendet daraufhin die Verbindung (Zustand: CLOSE). Nachdem die Verbindung geschlossen wurde, geht der Server wieder in den Ausgangszustand (WAITING_FOR_CONNECTION).

Insgesamt sollte festgehalten werden, das POP3-Kommandos Text-basiert und ohne Beachtung von Groß- und Kleinschreibung sind. Nach einem Schlüsselwort können ein oder mehrere Argumente folgen. Schlüsselwörter wiederum können aus drei oder vier Zeichen bestehen, Argumente dürfen bis zu 40 Zeichen lang sein. Beide enthalten ausschließlich druckbaren US-ASCII-Zeichen. Antwortnach- richten bestehen aus einem Statusindikator (+/-) und einem Schlüsselwort, das mit weiteren Informationen erweitert werden darf. Alle Antworten werden durch die beiden Steuerzeichen CRLF beendet und dürfen maximal 512 Zeichen (inkl. die abschließenden Steuerzeichen) lang sein. Als Statusindikatoren dürfen nur der positive Status +OK und der negative Status -ERR verwendet werden. Antworten auf bestimmte Befehle dürfen aus mehreren Zeilen bestehen. In diesem Fall müssen alle Zeilen mit den Steuerzeichen CRLF beendet werden und schlussendlich muss der Befehl mit einem Punkt (.) und einem weiteren CRLF abgeschlossen werden. Daraus folgt, dass beim Lesen von CRLF.CRLF der Kommunikationspartner davon ausgeht, dass damit das Ende des Befehls erreicht wurde. POP3-Server haben die Möglichkeit, optional einen Timeout zum automatischen Logout eines Nutzers zu verwenden, damit ungenutzte Ressourcen möglichst schnell wieder freigegeben werden können.

Im folgenden Beispiel 1.4 werden einige wichtige Befehle von POP3 beschreibend aufgelistet. 1.5 E-Mail-Infrastruktur Seite 27

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 zwin- gend notwendig. DELE n markiert die n-te E-Mail auf dem Server. Der Speicherplatz wird erst dann freigegeben, sobald der Server in den UPDATE-Zustand (vgl. Abbilding 1.5 auf Seite 42) geht. NOOP enthält keinen Befehl, kann aber an den Server gesendet werden, um den Timeout zurückzusetzen, der optional implementiert sein kann. Dadurch wird der Server daran gehindert, die Verbindung zu been- den und der Client muss nicht erneut eine Verbindung aufbauen. RSET setzt alle als gelöscht markierten E-Mails zurück. Dadurch können fälschlicherweise gelöschte E-Mails wiederhergestellt werden. Dies ist allerdings nur solange möglich, wie die Verbindung noch geöff- 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-Mails entfernen. Ist der Löschvorgang nicht erfolgreich, so quittiert der Server dies mit einer negativen Rückmeldung. Seite 28 Studienbrief 1 Grundlagen

Wie bereits weiter oben beschrieben, hat POP3 zwei Schwachstellen. Zum einen findet die Benutzerauthentifikation im Klartext statt. Dadurch bedingt ist es für Angreifer mit vergleichbar geringem Aufwand möglich, die Kontoinformationen wie Benutzername und Passwort herauszufinden. Zum anderen verwendet POP3 keine Verschlüsselung, wodurch nicht nur die Kontoinformationen, sondern auch alle anderen Informationen für Angreifer sichtbar werden.

APOP, RFC Um das erste Problem anzugehen, enthält POP3 den optionalen Befehl APOP. Server, 822, RFC 1321 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. ?) 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. ?) berechnet werden, der wiederum als Passwort übertragen wird. Der APOP-Befehl enthält dann den Benutzernamen im Klartext sowie den vorher berechneten Hashwert als Argumente. Der Server, der das Kennwort zu dem Benutzerkonto kennt, kann dann auch den Hashwert zu dem von ihm generierten Zeitstempel konkateniert mit dem Kennwort des Benutzers berechnen und somit abgleichen, ob der Benutzer das korrekte Kennwort eingegeben hat. Von essenzieller Bedeutung ist hierbei, dass jeder Zeitstempel einzigartig ist.

POP3S, RFC 2595 Für das zweite Problem der nicht vorhandenen Verschlüsselung bietet POP3 keine direkte Lösung. Als Erweiterung von POP3 wird hier POP3S angeführt. Dieses Protokoll baut auf POP3 auf, verwendet als Protokoll auf der Transport-Schicht al- lerdings TLS (Transport Layer Security) und ist innerhalb der RFC 2595 spezifiziert (vgl. ?). Somit existieren Möglichkeiten, die den E-Mail-Abruf absichern. Häufig werden diese jedoch aus Bequemlichkeitsgründen nicht angewendet.

1.5.5 IMAP (Internet Message Access Protocol) RFC 3501, RFC 1064, Genau wie die beiden vorher beschriebenen Protokolle SMTP und POP3 basiert RFC 1203, RFC 1730 IMAP ebenfalls auf der US-ASCII-Zeichenkodierung. Es ist aktuell in RFC 3501 (?) als Version 4 Revision 1 spezifiziert und für den Datentransfer vom Server zum Client konzipiert. IMAP wurde erstmals in RFC 1064 (vgl. ?) im Jahr 1988, damals noch unter dem Namen Interactive Mail Access Protocol, veröffentlicht. Das direkt in Version 2 erschienene Protokoll galt jedoch genauso wie die später in RFC 1203 veröffentlichte Version 3 (vgl. ?) als experimentell. Erst mit der im Jahr 1994 in RFC 1730 (vgl. ?) veröffentlichten Version 4, die dann den finalen Namen Internet Message Access Protocol trug, wurde das Protokoll als Standard definiert.

IMAP wurde so geplant und entwickelt, dass Nutzer ihre E-Mails nicht mehr wie bei POP3 vom Server zum Client transferieren und gleichzeitig auf dem Server löschen, sondern die E-Mails, Ordnerstrukturen und Einstellungen bleiben auf dem Server, damit diese von unterschiedlichen Computern desselben Benutzers genutzt werden können. Abbildung 1.7 auf Seite 44 zeigt dazu eine Beispiel-IMAP- Sitzung.

Gegenüber POP3 bietet IMAP verschiedene Vorteile, die im Folgenden näher betrachtet werden.

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 1.5 E-Mail-Infrastruktur Seite 29 können dem Client neue Nachrichten sofort angezeigt werden. Die Verbindung bleibt offen und muss somit nicht - wie bei POP3 - zu jeder Abholung von neuen Nachrichten neu aufgebaut werden. Nachrichten werden dann auf den Client heruntergeladen, sobald dieser sie anfordert. Je nach Konfiguration des Clients kann eine neue Nachricht sofort heruntergeladen werden. Es ist aber auch möglich, dass nur die Betreffzeile an den Client übergeben wird und der Benutzer das Herunterladen der Nachricht anstößt.

Mehrere Clients pro Konto

POP3 ist dahingehend beschränkt, dass sich pro Konto nur ein Client anmeldet sollte. Innerhalb der Sitzung werden die neuen Nachrichten heruntergeladen und anschließend, nachdem der Client den QUIT-Befehl gesendet hat, auf dem Server gelöscht. Dieses Verhalten kann zu Problemen führen, sofern sich für ein Konto mehr als nur ein Client anmeldet. SMTP geht dieses Problem direkt an und spezifiziert mehrere gleichzeitige Verbindungen an ein Benutzerkonto. Dabei wird sogar ein Mechanismus beschrieben, der die Clients untereinander informiert, sobald einer der Clients eine Änderung vollzogen hat.

Zugriff auf einzelne Bestandteile der E-Mail

POP3 spezifiziert den Befehl RETR n, der eine komplette Nachricht vom Server auf den Client herunterlädt. E-Mails, die mehrere Anhänge beinhalten, können dadurch nur komplett heruntergeladen werden. Im Gegensatz dazu besteht bei IMAP die Möglichkeit, einzelne Anhänge gezielt herunterzuladen, ohne dass die gesamte Nachricht heruntergeladen werden muss.

Verwendung von Kennzeichen

Durch die Verwendung von sogenannten Kennzeichen (engl.: flags), die für IMAP definiert sind, kann ein Client einer E-Mail bestimmte Statusinformationen anhän- gen. So können die E-Mails auf dem Server bspw. als gelesen oder wichtig markiert werden.

Erstellung von Unterkonten und Zuweisung von Zugriffsrechten für andere Nutzer

Zur Strukturierung der E-Mails auf dem Server können Nutzer eigene Unterkonten RFC 4314 anlegen, die im Client als Ordner angezeigt werden. Zwischen verschiedenen Ordnern können E-Mails kopiert oder verschoben werden. Es existiert auch eine Möglichkeit, anderen Nutzern den Zugriff auf ein eigenes Unterkonto zu geben, was in RFC 4314 (vgl. ?) beschrieben wird. Dieses Vorgehen ist jedoch optional und muss von der Software auf dem Server implementiert und vom Betreiber freigeschaltet sein, damit es genutzt werden kann.

Suchfunktion auf dem Server

Es existiert eine Funktion, bei welcher der Client den Server darum bitten kann, seine E-Mails nach bestimmten Kriterien zu durchsuchen. Dadurch bedingt muss der Client nicht alle E-Mails zuerst herunterladen, bevor er mit der Suche anfangen kann, sondern erhält sofort die passenden Treffer. Seite 30 Studienbrief 1 Grundlagen

Schnittstelle für Erweiterungen

Die aktuelle Version 4 von IMAP bietet explizit einen Mechanismus, um Erweite- rungen einzubauen.

IMAPS, RFC Grundsätzlich hat IMAP allerdings auch Probleme bzgl. Sicherheit, genauso wie 2595, RFC 3207 auch SMTP und POP3. Sowohl die Datenübertragung als auch die Authentifi- zierung 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 exis- tieren zwei Möglichkeiten. Zum einen kann IMAPS verwendet werden. Hier wird schon während des Verbindungsaufbaus die Verbindung transparent per TLS verschlüsselt (vgl. ?). Zum anderen besteht die Möglichkeit, eine bereits beste- hende unverschlüsselte Verbindung mithilfe des STARTTLS-Befehls (vgl. ?) in eine verschlüsselte Verbindung zu überführen.

1.5.6 DNS (Domain Name System) RFC 1034, RFC 1035 Das Domain Name System (DNS) ist eines der wichtigsten Systeme zur Nutzung des World Wide Web. Da es für einige Maßnahmen zur Abwehr von Spam benö- tigt wird, die in Studienbrief3 ab Seite 69 behandelt werden, wird es hier kurz vorgestellt. DNS wird innerhalb der RFCs 1034 (vgl. ?) und 1035 (vgl. ?) definiert und beschreibt, wie einzelne Computer im Internet ausfindig gemacht werden können.

RFC 1180, RFC Das im Internet verwendete TCP/IP (vgl. ?) setzte auf numerische Adressen, um 791, RFC 1349,RFC RFC791 Computer zu erreichen. Diese werden bei IPv4 (vgl. ? und ?) durch vier jeweils 2460, RFC 2474 8 Bit große Blöcke definiert, die durch Trennpunkte unterteilt werden und im dezimalen Zahlensystem dargestellt einen Wert zwischen 0 und 255 annehmen können. Daher sind maximal 232 = 4.294.967.296 Adressen möglich. Eine Adresse hat damit bspw. die lesbare Form 192.168.10.1. Der Nachfolger von IPv4 ist IPv6 (vgl. ? und ?). Hier werden nicht 32 Bit zur Adressierung verwendet sondern 128 Bit. IPv6-Adressen werden aufgrund der Länge allgemein nicht mehr im dezimalen System sondern im hexadezimalen System dargestellt. Dazu werden acht jeweils 16 Bit lange Blöcke verwendet, die durch einen Doppelpunkt unterteilt werden. Eine IPv6-Adresse hat bspw. die Form 20c1:0ab8:85b3:08d3:1319:8b2f:a470:7324. Es ergibt sich damit ein möglicher Adressraum von 2128 ≈ 3,4 × 1038 was einer Vergrößerung gegenüber IPv4 um den Faktor 296 ≈ 7,9 × 1028 entspricht. IPv4 war einst der Standard und sollte bereits seit Jahren durch IPv6 abgelöst werden. Der Grund dafür, dass IPv4 nicht mehr ausreichend ist, ist das rasante Wachstum der an das Internet angeschlossenen Geräte. Die ca. 4,3 Milliarden verfügbaren Adressen sind daher nicht mehr genug, wodurch eine neue Art der Adressierung notwendig wird. Dies ist das seit langem spezifizierte IPv6, bei dem der verfügbare Adressraum so groß ist, das für jeden Quadratmillimeter der Welt ca. 600 Billarden Adressen zur Verfügung stehen (vgl. ?).

Wie weiter oben beschrieben, hat DNS die Aufgabe, Computer im World Wide Web zu finden. Dies ist notwendig, da Computer eine numerische Adresse bekommen, es aber für Menschen einfacher ist, sich eine auf Text-basierende Adresse zu merken und auch Rückschlüsse über den Inhalt zu ziehen. Die Adresse 141.87.109.3 bietet nur für sehr wenige Menschen Information darüber, was auf der Seite zu finden ist. Der damit verbundene Name open-c3s.de ist dagegen allerdings einprägsam und hat zumindest für die Leser dieses Studienbriefes eine Semantik.

Die in Studienbrief3 beschriebenen Anti-Spam-Techniken verwenden DNS, um Informationen über die Absenderadresse einer E-Mail zu erhalten. Daraus soll 1.5 E-Mail-Infrastruktur Seite 31 erkannt werden, ob es sich bei dem Versender um einen bekannten Spammer handelt oder nicht. DNS-basierte Blacklists enthalten genau solche Informationen und werden ständig aktualisiert.

Mehr Informationen dazu folgen allerdings in Abschnitt 3.5.1 ab Seite 72.

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

1.5.7 Kontrollaufgaben In diesem Abschnitt befinden sich verschiedene Kontrollaufgaben, welche die Inhalte der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffes beitragen sollen.

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

Kontrollaufgabe 1.6: Beschränkung der Zeilenlänge innerhalb von E- Mails K Welche maximale Zeilenlänge wird für E-Mails empfohlen, welche Zeilen- länge muss eingehalten werden? Welchen Grund gibt es für diese Beschrän- kungen?

Kontrollaufgabe 1.7: Anzahl der to Header Felder einer E-Mail K Betrachten Sie die RFC 5322 (?). Wie groß ist die minimale Anzahl der Empfänger? An wen können E-Mails versendet werden, wenn die minimale Anzahl an Empfängern verwendet wird?

Kontrollaufgabe 1.8: Verwendung von SMTP K Zu welchem Zweck wird SMTP verwendet?

Kontrollaufgabe 1.9: Base64 Kodierung K Beschreiben Sie, warum die Base64 Kodierung kein Ersatz für eine Ver- schlüsselung 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 Authentifizierung nicht sicher? Seite 32 Studienbrief 1 Grundlagen

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

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 überflü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?

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

1.6 Anreize und Motivation der Spammer In diesem Abschnitt soll nur kurz auf die Motivation der Spammer eingegangen werden, da Studienbrief ?? ab Seite ?? dazu genauere Informationen enthält.

Der allgemeine Konsens zu Spam besteht darin, dass alle Empfänger Spam als hinderlich empfinden und oftmals gelernt haben, damit zu leben. Obwohl automa- tische Mechanismen einen Großteil des Spams aus den Postfächern herausfiltern, 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 enthält und der Empfänger sie nie erhalten hat.

Die Frage, die hier gestellt werden kann, ist warum Spam überhaupt existiert und welchen Nutzen hat er. Die Antwort auf diese Frage ist relativ simpel: Für die Versender von Spam stellt Spam eine Einnahmequelle dar. Spam enthält sehr 1.7 Wirtschaftliche Aspekte Seite 33 oft Werbung und wenn diese Werbung geschickt genug an den Empfänger ge- bracht wird, passiert es erstaunlicherweise häufig, dass unbedarfte Empfänger die Produkte, die angepriesen werden, kaufen. Die Informationen, die mittels Spam übertragen werden, können auch einen Betrugsversuch darstellen, der zum Betrug wird, sobald der Empfänger an die falschen Informationen glaubt und die im Spam geforderten Aktionen ausübt. Ebenfalls wird Spam dazu benutzt, um einen Identitätsdiebstahl zu begehen. Ahnungslose Empfänger glauben, dass eine Spam-Nachricht wirklich von ihrer Bank gekommen ist und geben PIN und TAN oder Kreditkartennummer an Betrüger heraus (vgl. Phishing in Abschnitt 1.9 ab Seite 36). Weiterhin wird Spam auch benutzt, um Schadsoftware auf andere Rechner zu übertragen, damit diese bspw. Teil eines Botnetzes werden.

In all diesen Fällen geht es den Spammern jedoch darum, Geld zu verdienen. Spam-Nachrichten, bei denen nicht erkennbar ist, wie deren Versender damit Geld verdienen können, weil die Nachrichten bspw. keinen Text enthalten, basieren häufig auf Programmierfehlern des Versenders.

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

Vorher werden im nächsten Abschnitt allerdings wirtschaftliche Aspekte angespro- chen.

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

1.7.1 Durch Spam entstehende Kosten Die Kosten, die durch Spam verursacht werden, entstehen wiederum in zwei Be- reichen. Zum einen handelt es sich um Personalkosten, sofern das E-Mail-Konto zu einem Unternehmen gehört. Gehört das E-Mail-Konto einer Privatperson, so ist die Zeit, die der Empfänger zum Aussortieren der unerwünschten Nachrichten benötigt, zwar ein Verlust an Lebenszeit, dieser Verlust kann jedoch finanziell nicht genau beziffert werden und somit ist in diesem Bereich eine Aussage zu den entstandenen Kosten schwierig. Gehört das Konto aber zu einem Unternehmen, so kann untersucht werden, wie lange ein Mitarbeiter für das Erkennen und Aussortie- ren von Spam täglich benötigt. Es gibt viele Untersuchungen, die unterschiedliche Ergebnisse liefern. ? 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. ? gehen dabei auf konkrete Zahlen ein und unterteilt nach Großprovider, Provider, Großunternehmen, mittelständisches Unternehmen und Kleinunternehmen bzw. Einzelunternehmen. Seite 34 Studienbrief 1 Grundlagen

Ab ca. 3 Millionen verwalteten Postfächern spricht die Studie von einem Großpro- vider, der im Normalfall pro Tag im Durchschnitt etwa 5 Spam-Nachrichten pro Postfach erhält. Damit beläuft sich das gesamte Spam-Aufkommen auf 15 Millionen Spam-Nachrichten in dem genannten Zeitraum. Um wettbewerbsfähig zu sein und auch zu bleiben, muss sich ein Großprovider um entsprechende Schutzmaßnah- men kümmern. Diese bestehen in der Regel aus einem mehrstufigen Filtersystem mit selbst entwickelter Software oder stark angepassten Lizenzprodukten. Doch nicht nur die Infrastruktur zur Ausfilterung von Spam muss vorhanden sein, son- dern es müssen auch die bereits vorhandenen Datenverbindungen für die erhöhten Anforderungen ausgelegt sein. In ? wird ein Datenverkehr von ca. 128 TB pro Jahr berechnet, der ausschließlich dazu verwendet wird, um die Spam-Nachrichten zu transportieren. Die Anbindung muss daher entsprechend angepasst sein, da- mit es nicht bei erwünschten E-Mails zu Engpässen kommt. Doch nicht nur die Kapazitäten für den Datenverkehr müssen entsprechend angepasst sein, auch die vorhandenen Speichersysteme müssen für die zusätzliche Speicherung der Spam-Nachrichten geeignet ausgelegt werden. Der genannte Bericht geht hier von einem zusätzlichen Speicherbedarf von drei TB pro Tag aus. Aus Sicht des Groß- providers ist es nicht möglich, die als Spam erkannten Nachrichten zu blocken oder zu löschen, vielmehr müssen diese gesondert dem Nutzer zur Verfügung gestellt werden, damit dieser ggf. falsch erkannte Nachrichten identifizieren und retten kann. Daher sind mind. 75 % der Gesamtkosten begründet durch die für die Verar- beitung von Spam bereits zu haltende Infrastruktur. Konkret entstehen Kosten in Höhe von ca. 1,4 Millionen Euro, was den Preis für eine einzige Spam-Nachricht auf 0,026 Cent festlegt.

Für kleinere Provider mit 50.000 verwalteten Postfächern wird ein Betrag von 0,2 Cent pro Spam-Nachricht ausgerechnet. Dies ist dadurch begründet, dass kleinerer Provider in Relation zu Großprovidern deutlich größere Personalkosten haben.

Für ein Großunternehmen sind die Kosten dagegen anders verteilt. Da in diesen Un- ternehmen die gesamte IT-Infrastruktur oftmals groß genug ausgelegt ist, müssen keine weiteren Puffer für Spam eingeplant und finanziert werden. Es bedarf jedoch an Lizenz- und Personalkosten. Gerade die Personalkosten sind hier sehr groß, da davon ausgegangen werden muss, dass Mitarbeiter durch Spam-Nachrichten von ihrer produktiven Arbeit abgehalten werden, um die Spam-Nachrichten per Hand auszusortieren, die automatische Softwarelösungen nicht erkannt haben. Werden keine Softwarelösungen zu Erkennung von Spam-Nachrichten eingesetzt, so belaufen sich die Kosten auf 18 Cent pro Spam-Nachricht. Werden hingegen Soft- warelösungen eingesetzt, so müssen dafür zusätzliche Lizenzen bezahlt werden. Bedingt durch eine entsprechende Trefferquote, belaufen sich die Kosten jedoch nur auf 4 Cent pro Spam-Nachricht, was jedoch immer noch im Vergleich zu den Providern sehr viel ist.

Bei mittelständischen Unternehmen oder Kleinunternehmen ergeben sich sehr ähnliche Werte.

1.7.2 Erlös für Spam-Verursacher Der Erlös für Spammer ist sehr unterschiedlich und lässt sich nicht exakt bestim- men. Auch hier existieren Untersuchungen, die den Erlös für Spammer ausrech- nen. In ? wird bspw. von 1.400 Euro als Erlös für das Versenden von 1 Millionen Spam-Nachrichten ausgegangen, wobei nur 0,01 % der Werbenachrichten zu einer Bestellung von Produkten durch den Spam-Empfänger führen.

Im weiteren Verlauf der Studienbriefe werden in anderen Abschnitten weitere Arbeiten betrachtet und mit dem Ergebnis dieser Arbeit verglichen. 1.8 Fallstudie „Click Trajectories: End-to-End Analysis of the Spam Value Chain“ Seite 35

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

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

Kontrollaufgabe 1.19: Profit Spamversand K Wie profitieren die Versender vom Spam?

1.8 Fallstudie „Click Trajectories: End-to-End Analysis of the Spam Value Chain“ In ? beschäftigen sich die Autoren mit Spam-basierter Werbung als Geschäftsmo- dell. In vielen anderen Veröffentlichungen steht die Erkennung und Bekämpfung von Spam auf technischer Ebene im Vordergrund, hier wird die Spam-Problematik allerdings auf einer abstrakteren Ebene angegangen. Obwohl es eine allgemeine Antipathie der Gesellschaft gegen Spam gibt und trotz der Industrie, die jährlich hohe Summen in die Bekämpfung von Spam steckt, ist Spam immer noch ein großes Problem und es scheint keine Lösung in Sicht zu sein. Daher haben sich die Autoren mit dem Geschäftsmodell hinter Spam beschäftigt, um die genauen Zusammenhänge zu verstehen, da sie der Anti-Spam-Industrie vorhalten, dass diese sich nur mit wenigen Aspekten der Wertschöpfungskette von Spam aus- einandersetzen. Dazu zählen die Spam-Filterung (vgl. Abschnitt 3.4 ab Seite 69), das URL-Blacklisting (vgl. Abschnitt 3.5.1 ab Seite 72) und das vom Netz nehmen von Servern (vgl. Abschnitt 3.12 ab Seite 95). Ziel der Untersuchung war es, die Wertschöpfungskette (vgl. Abbilding 1.8) genau zu verstehen, um einzelne Punkte ausfindig zu machen, die einen gezielten Eingriff zur Verminderung von Spam ermöglichen. Dazu haben die Autoren zuerst untersucht, wo der Ursprung von Spam liegt und sind dabei auf Botnetze (vgl. Abschnitt 2.9 ab Seite 61), Webmai- ler (vgl. Abschnitt 2.7 ab Seite 58) und IP Prefix Hijacking (vgl. Abschnitt 2.8 ab Seite 60) gestoßen.

Um nun zu erfahren, wie man mit vergleichsweise wenig Aufwand das System der Spammer lahmlegen kann, haben die Autoren untersucht, auf welchem Weg das Geld transferiert wird, das bei Einkauf von per Spam beworbenen Produk- ten den Besitzer wechselt. Dazu gruppierten die Autoren zuerst die einzelnen Shop-Adressen, die sie durch die Spam-Nachrichten bekamen, um die größten Kampagnen zu finden. Daraufhin versuchten die Autoren bei 120 Shops einen Einkauf zu tätigen, von denen allerdings nur 76 Käufe erfolgreich waren. In Ko- operation mit der Bank, deren Kreditkarte sie nutzen, erfuhren sie, welche Banken mit den Versendern von Spam zusammenarbeiten und aus welchen Ländern diese kommen. Letztendlich stellte sich bei der Untersuchung heraus, dass die Ban- ken der Spammer als Flaschenhals für deren Geschäftsmodell angesehen werden können. Nur wenige kleinere Banken arbeiten mit Spammern zusammen und sofern die großen Banken nicht mehr Kreditkartenüberweisungen an diese Banken durchführen, ist es möglich, das Geschäftsmodell der Spammer empfindlich zu stören. So wäre es möglich, mit nur relativ kleinen Eingriffen, die Menge an Spam deutlich zu verringern, da das Ziel der Spammer das Verdienen von Geld ist und der Geldfluss so beeinflusst werden könnte. Seite 36 Studienbrief 1 Grundlagen

1.9 Phishing Es existiert Spam, dessen Intention nicht in der Verbreitung von Werbung liegt, sondern zur Erlangung von persönlichen Daten führen soll. Diese Form des Spams wird als Phishing bezeichnet. Phishing ist ein Kunstwort, das vom englischen fis- hing (dt.: angeln) und dem Begriff Phreaking, der ein Kofferwort bestehen aus den englischen Begriffen phone (dt.: Telefon) und freak (Person, die sich nicht ins normale bürgerliche Leben einfügt, die ihre gesellschaftlichen Bindungen aufgegeben hat, um frei zu sein vgl. ?), abgeleitet wird. Der Duden (?) definiert Phishing als Beschaffung persön- licher Daten anderer Personen (wie Passwort, Kreditkartennummer o.Ä.) mit gefälschten E-Mails oder Websites. Konkret wird also von Kriminellen Spam versendet, der den Anschein erweckt, es handele sich um eine offizielle E-Mail von einer Bank oder Behörde. Innerhalb dieser E-Mail wird der Kunde dazu aufgefordert, im Internet eine Seite zu besuchen, um dort bestimmte Daten einzugeben oder zu aktualisieren. Diese Seite wiederum erweckt auch den Anschein, als wäre sie die echte Seite der Bank oder Behörde, jedoch handelt es sich dabei um eine Kopie der offiziellen Seite. Verlangt wird dann nach Kreditkartennummern oder Zugangsdaten für Online Banking Konten.

In letzter Zeit treten auch vermehrt Phishing-Versuche auf die Konten der Spieler von beliebten Online-Spielen auf (vgl. ?, ? und ?). Dabei werden die Benutzer durch eine Phishing-E-Mail auf eine gefälschte aber echt aussehende Seite des Online- Spiels geleitet, um dort ihre Account-Daten einzugeben. Die daraus gewonnenen Daten werden dann auf dem Schwarzmarkt verkauft, um an die virtuelle Währung des Spieler zu gelangen. Das virtuelle Geld wird dann an andere Konten übertragen, um es bspw. im Spiel an andere Spieler zu verkaufen.

Es gibt automatische Schutzmechanismen, die in Webbrowsern oder E-Mail-Clients eingebaut sind. Dabei kann die Software untersuchen, ob der Nutzer eine Web- seite besucht, deren URL (Uniform Resource Locator) bestimmte Schlüsselwörter enthält, oder ob die Seite von anderen Benutzern bereits als verdächtig gemeldet wurde. Ebenfalls können Zertifikate erkannt werden, die von keiner offiziellen und vertrauten Zertifizierungsstelle unterschrieben wurden. ? beschreiben dazu, die Gründe, warum Phishing funktioniert, vgl. dazu auch ?.

Der beste Schutz vor Phishing-Angriffen 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.10 Zusammenfassung In diesem Studienbrief wurden die Grundlagen für die folgenden Studienbrie- fe vermittelt. Beginnend mit einer Definition für E-Mails und Spam wurde die Infrastruktur beschrieben, die für den Versand und das Empfangen von E-Mails notwendig sind. Die dafür verwendeten Protokolle wurden detailliert betrachtet. Die Motivation der Spammer für den Versand von Spam wurde kurz genannt 1.11 Übungen Seite 37 und zur Veranschaulichung wurde in einer Fallstudie gezeigt, wie Geld mit dem Versand von Spam verdient werden kann und auch wie ohne technische Eingriffe der Versand von Spam reduziert werden kann.

1.11 Übungen

Übung 1.1: Nachteile von E-Mails Ü Im ersten Abschnitt wurden einige Vorteile von E-Mails gegenüber normaler Post aufgeführt. Können Sie sich vorstellen, dass es auch Nachteile gegenüber normaler Post gibt, außerhalb von Spam?

Übung 1.2: Leerzeilen in E-Mails Ü Finden Sie heraus, wie eine Leerzeile in einen E-Mail-Body eingefügt werden kann, ohne dass ein E-Mail-Programm die Leerzeile als Ende der E-Mail interpretiert.

Übung 1.3: SMTP: CRAM-MD5 Ü Betrachten Sie die CRAM-MD5-Authentifizierung als Erweiterung von SMTP: Aus welchem Grund soll die im ersten Schritt vom Server an den Client gesendete Zeichenkette möglichst einzigartig sein? Seite 38 Studienbrief 1 Grundlagen

Ü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 Verfügung stellt. Was können Sie dabei feststellen? 1.11 Übungen Seite 39

Ü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 23. Wandeln Sie den Text „Hallo Welt!“ zuerst in dezimale Zeichen um und kodieren ihn anschließend in Base64 um.

Welchen US-ASCII-Text wird durch folgenden Base64-kodierten Text reprä- sentiert: „U3R1ZGllbmJyaWVmCg==“?

Übung 1.8: Base64-Kodierung: Speicherplatz Ü Berechnen Sie die Menge an Speicherplatz, die eine Zeichenkette der Länge 19.265 benötigt, wenn diese Base64-kodiert wird.

Übung 1.9: Nutzerauthentifikation bei POP3 Ü Betrachten Sie den APOP Befehl von POP3. Können Sie sich unter der 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 bie- tet. Seite 40 Studienbrief 1 Grundlagen

Ü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. ??): Welcher Fehlercode wurde fälschlicherweise in RFC 821 definiert und durch RFC 5321 korrigiert, sofern ein Client mehr Empfänger-Adressen in einer E-Mail angegeben hatte als der empfangende Server unterstützt?

Übung 1.13: DNS (Domain Name System) Ü Eine DNS-Anfrage löst einen Namen in eine IP-Adresse auf. Finden Sie her- aus, ob es einen Dienst gibt, der zu einer IP-Adresse die damit verbundenen Namen zurückgibt. Warum ist ein solcher Dienst sinnvoll?

Übung 1.14: Fallstudie „Click Trajectories: End-to-End Analysis of the Spam Ü Value Chain“ Betrachten Sie ? und finden Sie heraus, warum nicht alle der 120 Käufe erfolgreich waren.

Übung 1.15: Phishing Ü Betrachten Sie ? und benennen Sie die drei Gründe sowie deren Details, die für den Erfolg von Phishing verantwortlich sind. 1.11 Übungen Seite 41

Client Server Abb. 1.4: UML- Sequenzdiagramm 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 42 Studienbrief 1 Grundlagen

Abb. 1.5: UML- Zustandsdiagramm WAITING_FOR_CONNECTION einer POP3-Sitzung. Verbindungsaufbau

AUTHORIZATION

Client Identifikation am Server

TRANSACTION Aktionen ausführen Verbindung getrennt

Client sendet QUIT Kommando

UPDATE

CLOSE 1.11 Übungen Seite 43

Client Server Abb. 1.6: UML- Sequenzdiagramm 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 Seite 44 Studienbrief 1 Grundlagen

Abb. 1.7: UML- Client Server Sequenzdiagramm einer IMAP-Sitzung. Wartet auf Verbindungsaufbau --Verbindungsaufbau

* OK IMAP4rev1 Service Ready

a001 login benutzername passwort

a001 OK LOGIN completed

a002 select inbox

* 18 EXISTS * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * 2 RECENT * OK [UNSEEN 17] Message 17 is the first unseen message * OK [UIDVALIDITY 3857529045] UIDs valid a002 OK [READ-WRITE] SELECT completed a003 fetch 12 full

* 12 FETCH (BODY[HEADER] {342} Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT) From: Terry Gray 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

Abb. 1.8: Die für eine einzige URL- Wertschöpfungskette verwendete In- frastruktur aus ?. Studienbrief 2 Spam-Techniken Seite 45

Studienbrief 2 Spam-Techniken

2.1 Lernergebnisse Sie können die von Spammern genutzten Infrastrukturen, um Spam zu versenden und Kapitel aus dem Versand zu ziehen, benennen und beschreiben. Darüber hinaus können Sie verschiedene Arten von Spamtechniken unterscheiden und wiedergeben, wie diese Techniken von Spammern verwendet werden. Sie sind in der Lage, sich gegen Adress-Harvesting zu schützen.

2.2 Advanced Organizer Mittels welcher Techniken ist SPAM-Versand möglich? Auf welche Infrastruktur greifen Spammer hier zurück? Wie kommt ein Spammer an gültige E-Mail Adres- sen und wie kann man sich als Nutzer dagegen wehren, dass die eigene E-Mail Adresse in die Hände eines Spammers gelangt? Diese Fragen stehen im Mittelpunkt dieses Studienbriefs.

2.3 Einleitung In diesem Studienbrief werden Techniken vorgestellt, über die Spam in den 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ügelteren Techniken kommt. Bevor auf die konkreten Methoden eingegangen wird, wird zuerst beleuchtet, wie Spammer arbeiten und auch wie ihre Strukturen aufgebaut sind. Dabei wird insbesondere auf Techniken zum Sammeln von Adressen und deren Abwehrmechanismen ein- gegangen. Als erste Methode zum Versand von Spam werden daraufhin offene Mail-Relays behandelt. Obwohl der Grund für das Vorhandensein dieser Methode ausschließlich darin lag, dass bei der Planung der E-Mail-Infrastruktur nicht mit dem Missbrauch des Mediums E-Mail für Spam gerechnet wurde, konnte diese Lücke relativ schnell geschlossen werden. Offene Proxies bieten ähnliche Möglich- keiten 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 Spam- mern verwendet werden. Im Abschnitt über IP Prefix Hijacking wird eine erste ausgeklügeltere Methode zum Versand von Spam vorgestellt, bevor die Abschnitte über Malware und Botnetze den größten Ursprung von Spam beschreibt.

2.4 Spammer Ursprünglich wurden Spam-Nachrichten von einzelnen Personen aus verschickt, ROKSO die dabei sehr einfache Techniken nutzten bzw. einfache Schwachstellen in Spezifi- kationen ausnutzten, wie im späteren Verlauf dieses Studienbriefs deutlich wird. Um das Thema Spam hat sich aber, nachdem Spam als Problem erkannt wurde, ei- ne Industrie entwickelt, die jährlich Milliardenumsätze verbucht. Dazu zählen auf der einen Seite Firmen, die Produkte entwickeln oder Dienstleistungen anbieten, um Spam-Nachrichten zu erkennen, um diese daraufhin zu filtern, auszusortieren oder zu blockieren. Auf der anderen Seite stehen die Versender von Spam, die immer professioneller vorgehen und sich zusammenschließen, um effizienter und effektiver zu werden. Spammer sind mittlerweile so professionell geworden, dass es sogar ein Register von bekannten Spam-Operationen (vgl. ?, 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 mindes- tens drei Internet Service Provider (ISP) als Spammer erkannt wurden und deren Seite 46 Studienbrief 2 Spam-Techniken

Aktivitäten daraufhin durch diese ISPs beendet wurde. Aktuell listet das Register 115 verschiedene Gruppen auf, die aus Ländern verteilt über den gesamten Globus fungieren. Das Spamhaus-Project gibt weiterhin an, dass ca. 100 Gruppen für etwa 80 % des Spamaufkommens in Nordamerika und Europa verantwortlich sind und fast alle dieser Gruppen in dem Register aufgelistet sind.

2.4.1 Spammer-Netzwerke Es ist klar, dass Spammer die E-Mail-Infrastruktur verwenden, um Werbenach- richten zu verschicken. Es stellt sich aber die Frage, wie die sonstige Infrastruktur von Spamversender genau aufgebaut ist, damit ihr Geschäft möglichst effektiv arbeitet. In ? und ? 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ögli- cher Aufbau eines Partner Spammer-Netzwerkes AffiliatesAffiliates (angelehnt an ?). Längerfristige (Freie Mitarbeiter) Infrastruktur (Freie Mitarbeiter) Spamversand,Spamversand, 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

Adressdatenbank, Im Mittelpunkt der Abbildung steht der Hauptspammer, der zwei Ressourcen Bullet-Proof-Server benötigt. Das ist zum einen eine Adressdatenbank, die mit E-Mail-Adressen von möglichen Empfängern gefüllt ist. Idealerweise enthält die Adressdatenbank nicht nur die E-Mail-Adressen der Empfänger, sondern auch weitere persönliche Infor- mationen wie Namen, Alter und ggf. Interessen. Diese persönlichen Informationen können für den Hauptspammer wichtig sein, wenn er seine Werbebotschaften an die richtige Zielgruppe versenden möchte. Die Adressdatenbank ist für den Haupt- pammer eine Ressource, die er nutzt, um Spam zu versenden, aber auch gleichzeitig 2.4 Spammer Seite 47 kann diese Datenbank direkt ein Einkommen erzeugen, indem Adressen an andere Spammer oder Adresshändler verkauft werden. Um über eine möglichst große Basis an Adressen zu verfügen, müssen entsprechend auch Adressen von ande- ren Spammern oder Adresshändlern angekauft werden. Adressen können vom Hauptspammer auch direkt gesucht werden. Wie dies geschieht, wird im folgen- den 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 Kun- den sind. Erhält ein Empfänger eine Spam-Nachricht und interessiert sich für das beworbene Produkt, so folgt er einem Link zum Shop des Versenders. An dieser Stelle wäre ein Eingriff in die Infrastruktur des Spammers für die Justiz einfach. Es würde ausreichen, wenn diese Server vom Internet getrennt würden, wodurch der Spammer die Möglichkeit verlieren würde, einen Gewinn zu erwirtschaften. Aus diesem Grund suchen und betreiben Spammer sogenannte Bullet-Proof-Server. Dabei handelt es sich um Server, die bei Betreibern stehen, die wiederum nicht mit der Justiz zusammen arbeiten. Dies können Server in Nordamerika oder Europa sein, die sich nicht einfach vom Netz trennen lassen, da deren Hoster mit den Spamversendern und nicht der Justiz zusammenarbeiten. Erst wenn alle Verbin- dungen zum Netz dieser Betreiber getrennt sind, kann der Bullet-Proof-Server nicht mehr erreicht werden.

Neben der eigenen Infrastruktur beschäftigt ein Hauptspammer freie Mitarbeiter, Affiliate, Botnetz sogenannte Affiliates. Diese freien Mitarbeiter können sowohl für den Versand von Spam als auch für das Sammeln von E-Mail-Adressen zuständig sein und werden am Gewinn des Hauptspammer beteiligt. Der Hauptspammer kann zwar seine freien Mitarbeiter zum Spamversand einsetzen, hat aber auch bedingt durch seine Adressdatenbank selber die Möglichkeit, Spam zu versenden. Um einfachen Erkennungsmöglichkeiten zu entkommen, werden für den Versand von Spam generell Botnetze verwendet. Daher muss der Hauptspammer entweder selber über Malware verfügen, die er auf verschiedenen Computern verbreitet, um ein Botnetz zu betreiben. Es ist aber auch möglich, für Geld Botnetze zu mieten oder auch zu kaufen. Dazu benötigt der Hauptspammer einen Kontakt zu Botnetzbetreibern. Diese können ihm dann für einen bestimmten Preis eine feste Anzahl von Computer zum Versand von Spam Nachrichten zur Verfügung stellen. Zum Ankauf von Produkten und zur Koordination des Produktversandes nach einem erfolgten Kauf benötigt ein Spamversender Kontakt zu den Produzenten der Produkte sowie zu Versanddienstleistern, die sich um den Transport vom Produzent zum Kunden kümmern. Diese interagieren dann mit den Käufern. Da der Hauptspammer mit Produzenten und Versanddienstleistern interagiert und über eine Infrastruktur zum Versand von Spam verfügt, ist es ebenso denkbar, dass er mit Serviceanbietern in Kontakt tritt, die ihn beauftragen, bestimmte Kampagnen zu betreiben. Somit vermietet der Hauptspammer seine Ressourcen an andere Anbieter.

Neben ihrer üblichen Infrastruktur und ihrer eigenen Kontakte haben viele 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.4.2 Adress-Harvesting Der Versand von Spam ist für Spammer denkbar einfach. Nachdem im vorherigen Abschnitt vorgestellt wurde, wie die Infrastruktur vom Spamversender aufge- baut 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 unterschiedliche Techniken bzw. Methoden, die im Folgenden näher beschrieben werden. Seite 48 Studienbrief 2 Spam-Techniken

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 identi- fizieren. 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 potenziellen E-Mail-Adressen das WWW durchforsten. Dabei durchsuchen die Bots das WWW ähnlich wie Webcrawler. Im Gegensatz zu Webcrawlern werden sie aber nicht zum Indizieren von Webseiten verwendet, sondern suchen mittels regulärer Ausdrücke nach E-Mail-Adressen. Diese E-Mail-Adressen können sich innerhalb von HTML-Dokumenten befinden, genauer gesagt, können es Seiten von Foren sein, bei denen Mitglieder ihre E-Mail-Adresse zur Kommunikation hinterlassen. Es können weiterhin auch Webseiten von Firmen sein, die ein Impressum verfassen müssen und dort eine E-Mail-Adresse angeben oder auch generelle Kontaktdaten, die von einzelnen Webseitenbetreibern zur Verfügung gestellt werden. Alternativ können natürlich auch andere Teil des WWWs durchsucht werden. Dazu gehören bspw. Bilder oder auch PDF-Dokumente, in denen nach E-Mail-Adressen gesucht werden. Es ist zwar möglich diese Informationen im Internet mit verschiedenen Techniken zu verschleiern (vgl. nächster Abschnitt) allerdings müssen vieler dieser Techniken als zweischneidiges Schwert angesehen werden: Die E-Mail-Adressen sollen so angezeigt werden, dass sie für Nutzer erkenntlich sind, für Maschinen sollen sie jedoch möglichst verfremdet sein, sodass Programme sie nicht als solche identifizieren.

Directory-Harvest-Angriff

Wörterbuchangriffe Eine weitere, weniger ausgeklügelte Möglichkeit, um an E-Mail-Adressen zu gelan- gen, ist der sogenannte Directory-Harvest-Angriff. Hierbei gibt es zwei mögliche Techniken, um Listen von potenziellen E-Mail-Adressen zu generieren. Auf der einen Seite erstellt der Angreifer eine Liste mit allen möglichen Buchstaben- und Zahlenkombinationen bis zu einer bestimmten Länge und hängt an diese erstellten Kombinationen dann eine bestimmte Domäne an. Der Nachteil bei dieser Methode besteht darin, dass die Liste sehr schnell sehr groß wird. Werden bspw. Nutzerna- men mit einer Länge von genau vier Zeichen erstellt und dabei nur die Buchstaben von A bis Z und die Zahlen von 0 bis 9 verwendet, so entsteht eine Basis von 36 Zeichen, die mit der Länge vier potenziert wird. Alleine bei diesem kurzen Benutzernamen entstehen bereits 364 ≈ 1,7 Millionen verschiedene Kombinatio- nen. Die zweite Möglichkeit, eine solche Liste zu erstellen, besteht darin, geläufige Vornamen, Nachnamen und Initialen sinnvoll zu verbinden. So entstehen bspw. E-Mail-Adressen wie max.mustermann@domain oder mmustermann@domain. Diese Methode ist angelehnt an einfache Wörterbuchangriffe, wogegen die im ersten Schritt genannte Methode zu den Brute-Force-Angriffenzählt. In beiden Fällen werden lange Listen von E-Mail-Adressen erzeugt, die im weiteren Verlauf auf ihre Korrektheit hin analysiert werden müssen. Eine Analyse besteht dabei aus einer einfachen Verbindung zum entsprechenden E-Mail-Server und dem Versuch, 2.4 Spammer Seite 49 eine Test-E-Mail an das geratene Konto zu verschicken. Diese Test-E-Mail enthält im Normalfall noch keine Werbebotschaften, damit keine Filter anschlagen. Der Erfolg des Directory-Harvest-Angriffs beruht nun einzig und alleine darauf, dass E-Mail-Server eine Information an den Versender einer Nachricht schicken, sofern sie eine Nachricht empfangen haben, die an ein nicht vorhandenes Konto gerichtet war. Es existieren dementsprechend Implementierungen, die eine solche Nachricht nicht verschicken, womit prinzipiell alle geratenen E-Mail-Adressen für den An- greifer 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 anbie- ten und dafür die E-Mail-Adresse des potenziellen Kunden benötigen. Egal ob die Leistung dann später wirklich erbracht wird oder nicht, die einmal eingetragene E-Mail-Adresse ist dann bereits in die Adressdatenbank des Anbieters eingetragen worden und dient daraufhin sicherlich als Empfängeradresse für Spam.

2.4.3 Anti-Harvesting-Methoden Entsprechend der im vergangenen Abschnitt beschriebenen Harvesting-Methoden existieren wiederum Methoden, um den Adresssammlern das Sammeln zu er- schweren. 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 gut- artigen Zweck zur Verfügung stehen sollte. Daher erschweren die im Folgenden vorgestellten Techniken das Sammeln nur.

Bilder

Anstelle von Text-basierten Informationen ist es ebenso möglich, eine E-Mail in Form eines Bildes innerhalb einer Internetseite zu speichern. Für einen menschli- chen Besucher, der eine Kommunikation aufbauen möchte, ist das Bild im Gegen- satz zum Text zuerst kein Unterschied, da es dieselben Informationen präsentiert. Einziger Nachteil besteht darin, dass der Besucher die E-Mail-Adresse nicht di- rekt in sein E-Mail-Programm kopieren kann, sondern sie abtippen muss. Der Vorgang des Abtippens ist zum einen aufwendiger und zum anderen fehleranfäl- liger, 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 Software natürlich so anpassen, dass auch Bilder per Texterkennung durchsucht werden und somit trotz- dem an die E-Mail-Adresse gelangen. Je ausgeklügelter die Adresse also innerhalb des Bilds verschleiert wird, je besser ist sie vor Adresssammlern geschützt.

CAN-Spam-Hinweise

CAN-SPAMist 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 „Controlling the Assault of Non-Solicited Pornography And Marketing Act of 2003“ (vgl. ?). Hierbei müssen Betreiber von Webseiten ihren Kunden versichern, dass sie die E-Mail-Adressen, die sie von ihren Kunden erhalten, nicht an Dritte weitergeben. Seite 50 Studienbrief 2 Spam-Techniken

Dieser Hinweis ist in europäischen Ländern eher selten, da das genannte Gesetz nur in den USA gilt.

CAPTCHAs

Um E-Mail-Adressen nur für Menschen sichtbar zu machen, eignen sich auch CAPTCHAs. Der Begriff CAPTACH steht für „Completely Automated Public Tu- ring test to tell Computers and Humans Apart“. Dabei kann es sich um visuelle CAPTACHAs handeln, also Bilder, die bestimmte Informationen enthalten, die für Menschen leicht und für Maschinen besonders schwer zu entnehmen sind (vgl. Abbildung 2.2). Innerhalb dieser Abbildungen kann dann bspw. die Information direkt enthalten sein, genauso ist es aber auch möglich, dass die Abbildung eine Aufgabe zeigt, deren Ergebnis in ein entsprechendes Feld eingetragen werden muss. Oftmals werden Zeichenketten verwendet, die bedingt durch einen bunten Hintergrund nicht einfach mit Texterkennungssoftware entdeckt werden können. Als weitere Möglichkeit zur Verschleierung kommen auch verzerrte Zeichenketten vor. Bei visuellen CAPTCHAs können auch einfache mathematische Aufgaben zu lösen sein oder bestimmte Dinge gezählt werden. Hier bietet es sich bspw. an, verschiedene Tierarten innerhalb von einem Bild zu bestimmen. Es kann sich aber auch um akustische CAPTCHAs handeln, bei denen die Informationen gehört werden müssen. Bei akustischen CAPTCHAs wird oft gesprochene Sprache abge- spielt, die Zahlen enthält, die wiederum durch ein starkes Hintergrundrauschen verschleiert werden.

Abb. 2.2: Ein von Goo- gle erzeugtes CAPT- CHA, 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, grafische oder auch akustische CAPTCHAs zu lösen. Das größte Problem in diesem Bereich besteht darin, dass ausgeklügelte CAPTCHAs nicht nur für Maschinen immer schwerer zu erkennen sind, sondern auch für Menschen, die eigentlich bei der Lösung kein Problem haben sollten. Außerdem kann das Lösen von CAPTCHAs zur Not auch in Niedriglohn- länder ausgelagert werden, womit ein CAPTCHA zwar nicht mehr automatisch gelöst werden kann, jedoch für einen relativ kleinen Betrag überwunden werden kann.

E-Mail-Adressen-Verfälschung

Eine weitere Möglichkeit, um eine E-Mail-Adresse vor dem automatischen 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 2.4 Spammer Seite 51

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 Web- seiten nach E-Mail-Adressen zu durchsuchen, soweit angepasst werden, dass auch E-Mail-Adressen mit oben beschriebenen Ersetzungen erkannt werden.

E-Mail-Server-Überwachung

Anti-Harvesting-Methoden können ebenfalls bei der E-Mail-Server-Software an- setzen. So können E-Mail-Server so implementiert werden, dass sie bspw. keine E-Mails von einem Absender mehr annehmen, sobald dieser eine E-Mail an eine nicht vorhandene Adresse verschickt hat. Dies verursacht allerdings die Gefahr, dass reguläre E-Mails auch nicht mehr angenommen werden, sobald jemand bei der Eingabe einer E-Mail-Adresse einen Fehler gemacht hat und die Empfänger- adresse daher nicht existiert.

E-Mail-Honeypots: Spider Traps

In der IT-Sicherheit wurde vor einigen Jahren erkannt, dass nicht nur proaktive , also direkte Abwehrmaßnahmen sinnvoll sind, um Sicherheitsanforderungen durchzusetzen, sondern auch der Einsatz von reaktiven Maßnahmen hilfreich ist, um bestimmte Angriffe zu verstehen. Vor diesem Hintergrund wurden sogenannte Honeypots (dt. Honigtöpfe) entwickelt, die reale Systeme darstellen und für einen Angreifer als lohnendes Ziel angesehen werden können, in Wirklichkeit allerdings keine Dienste ausführen, die für den Betreiber wichtig sind. Angriffe aus solchen Systemen können dementsprechend protokolliert werden und es kann aus den angelegten Protokollen erlernt werden, wie Angreifer vorgehen. Diese eigentlich im Bereich der Systemsicherheit eingesetzte Methode lässt sich allerdings auch auf Gegenmaßnahmen gegen das automatische Sammeln von E-Mail-Adressen übertragen. Diese Technik kann unterschiedliche Aktivitätsgrade verfolgen. Sie lässt sich auf der einen Seite eher passiv nutzen, in dem eine ungenutzte E-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 ausfindig zu ma- chen.

HTML-Verschleierung

Die im WWW verwendete Metasprache HTML (Hypertext Markup Language, vgl. u.a. ?) bietet nicht nur die Möglichkeit der Gestaltung und Strukturierung von Webseiten, sie beinhaltet auch die Möglichkeit, Elemente im Quellcode zu be- schreiben, sodass die Darstellung innerhalb der anzuzeigenden Webseite sich stark vom Quellcode unterscheidet. So können bspw. Elemente wie E-Mail-Adressen mithilfe von Bildern unterbrochen werden, die eine Breite und eine Höhe von Null Pixeln haben. Somit wird die E-Mail-Adresse im Quellcode durch ein Element in zwei Teile zerteilt, wirkt aber auf der später zu betrachtenden Webseite so, als wäre sie ohne Unterbrechung angegeben worden. Genauso lassen sich bestimmte Seite 52 Studienbrief 2 Spam-Techniken

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 bre- chen, allerdings kann sie auf für menschliche Benutzer hinderlich sein, da ein Mensch solch verschleierte Adresse nicht direkt mit wenigen Mausklicks kopieren kann, sondern abtippen muss, was letztendlich eine gewisse Fehleranfälligkeit provoziert.

Javascript-Verschleierung

Als ein wirksames Mittel, um Adress-Harvestern das Sammeln von E-Mail- Adressen zu erschweren, hat sich eine Verschleierung der E-Mail-Adressen mithil- fe von Javascript herausgestellt. Dabei wird die E-Mail-Adresse verschlüsselt im HTML-Quellcode abgelegt und dann ausschließlich zur Anzeige in einem Browser entschlüsselt. Dieser Browser muss dazu eine Javascript-Methode ausführen, die aus der verschlüsselten Zeichenkette die erwünschte E-Mail-Adresse berechnet. 2.4 Spammer Seite 53

Als besonders hilfreich hat sich hier die ROT13-Verschiebechiffre (vgl. Exkurs 2.1 und Exkurs 2.2) herausgestellt.

Exkurs 2.1: Verschiebechiffre 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üssel, der zum Verschlüsseln verwendet wird, dem Schlüssel, der auch zum Entschlüsseln genutzt werden muss. Die Verschiebechiffre nutzt dabei ein recht simples Konzept: Jeder Buchstabe ki eines Klartextes K wird um ein festes ganzzahliges p zyklisch nach rechts verschoben. Das Ergebnis ist dann der Geheimtext.

Etwas formaler gefasst kann die Verschiebechiffre mithilfe der Modulo- Arithmetik beschrieben werden. Die Buchstaben des Alphabets werden fortlaufend durchnummeriert:

A = 0,B = 1,...,Z = 25

Die Funktion zahl(x), x ∈ {A,B,...,Z} liefert als Ausgabe diejenige Zahl, der x zugeordnet wird. Die Funktion

buchstabe(x), x ∈ {0,1,...,25}

liefert als Ausgabe denjenigen Buchstaben, der x zugeordnet wird. zahl(x) ist also invers zu buchstabe(x). In der Literatur werden die Funktionen buchstabe(x) und zahl(x) oft weggelassen und die Buchstaben gleichzeitig als Buchstaben und Zahlen betrachtet.

Zur Verschlüsselung eines Buchstaben ki mit Verschiebung um p Zeichen ist folgende Funktion zu verwenden:

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 Verschiebechiffre (vgl. Exkurs 2.1), bei der p = 13 gilt. Durch die Wahl von p = 13 können für Ver- und Entschlüsselung die gleiche Funktion verwendet werden.

Dabei wird jeder Klartext-Buchstabe auf einen Geheimtext-Buchstaben abgebildet und der Geheimtext im HTML-Quellcode hinterlegt. Ein Java-Script ist dann im Browser dafür zuständig, den Geheimtext wieder in den Klartext umzuwandeln. Seite 54 Studienbrief 2 Spam-Techniken

Da automatische Programme zum Sammeln von Adressen im Allgemeinen nicht den vollen Funktionsumfang eins Browsers besitzen, also oft auch keine Unterstüt- zung für Java-Script anbieten, wird dann entsprechend eine andere E-Mail-Adresse als die echte eingesammelt. Im Allgemeinen existiert dann für die eingesammelte E-Mail-Adresse kein Konto und der Versuch, eine Spam-Nachricht an dieses Konto zu versenden, wird mit einer Fehlermeldung vom E-Mail-Server quittiert.

Kontaktformulare

Die letzte hier betrachtete Methode, um Adress-Harvesting zu erschweren bzw. zu unterbinden sind Kontaktformulare. Gewerbliche Betreiber von Internetseiten sind auf die Kommunikation mit Kunden angewiesen, um Produkte oder Dienstleistun- gen 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öf- fentlichen zu müssen, auf der anderen Seite für den Kunden aber möglichst einfach erreichbar zu sein, können Formulare innerhalb einer HTML-Seite eingebunden werden, in die ein Kunde eine Anfrage und seine eigenen Kontaktdaten eintragen kann. Das Kontaktformular schickt diese Daten dann zwar auch per E-Mail an den Empfänger, der Versand der E-Mail geschieht dabei aber Server-seitig und der Kunde erfährt nicht die E-Mail-Adresse des Empfängers.

So ist es für den Gewerbetreibenden möglich, die Anfrage des Kunden zu erhal- ten, ohne seine eigene E-Mail-Adresse öffentlich anzugeben. Es ist jedoch nicht ausgeschlossen, dass Spam-Nachrichten durch diese Technik vollständig geblockt werden, da bestimmte Spam-Bots nicht nur per SMTP Nachrichten versenden, sondern auch beim Suchen nach neuen E-Mail-Adressen Formulare gezielt nutzen und ihre Werbung darin platzieren. Dies kann dann wiederum durch die Verwen- dung von CAPTCHAs erschwert werden, wie bereits oben in diesem Abschnitt gezeigt wurde.

2.4.4 Kontrollaufgaben In diesem Abschnitt befinden sich verschiedene Kontrollaufgaben, welche die Inhalte der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffes 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 Begriff Adress-Harvesting? 2.5 Offene Mail-Relays Seite 55

Kontrollaufgabe 2.3: Directory Harvest Attack K Wie viele verschiedene Kombinationen von E-Mail-Adressen entstehen bei der ersten Technik des Directory Harvest Angriffs, wenn die Länge der Nutzernamen fünf oder wenige Zeichen betragen darf und von einem Alphabet mit 36 Zeichen (A-Z, 0-9) ausgegangen wird?

Was passiert, wenn auch Sonderzeichen wie „.“, „-“und „_“erlaubt wer- den?

Kontrollaufgabe 2.4: Anti-Adress-Harvesting K Welche Methoden gibt es, um Adress-Harvesting zu erschweren oder aus- zuhebeln? Beschreiben Sie mindestens drei Methoden.

Kontrollaufgabe 2.5: Adress Munging K Erläutern Sie die „Adress Munging“ Technik.

Kontrollaufgabe 2.6: Verschiebechiffre K Zeigen Sie, dass die Funktion encryptp(x) und decryptp(x) invers zueinander sind.

Kontrollaufgabe 2.7: ROT13-Verschiebechiffre K Welche Besonderheit hat die ROT13-Verschiebechiffre?

2.5 Offene Mail-Relays Wie bereits im ersten Studienbrief in Abschnitt 1.5.3 ab Seite 20 und Abbildung 1.3 RFC 5321 auf Seite 18 dargestellt wird, ist SMTP das wichtigste Protokoll für den Versand von E-Mails. Es wird nicht nur verwendet, um E-Mails vom Computer des Benutzers zu einem E-Mail-Server zu versenden, sondern auch um diese E-Mails letztendlich zum E-Mail-Server des Empfängers zu schicken. Diese E-Mails müssen dabei nicht direkt vom Server des Versenders zum Server des Empfängers verschickt werden. Nach RFC 5321 (vgl. ? besteht auch die Möglichkeit, dass eine E-Mail vom SMTP-Server des Versenders nicht direkt zum SMTP-Server des Empfängers geschickt wird, sondern vom SMTP-Server des Versenders zuerst zu einem anderen SMTP-Server geschickt wird. Je nach Konfiguration dieses Servers kann dieser die Annahme der E-Mail mit dem Antwort-Code

550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) vollständig ablehnen. Der SMTP Server kann weiterhin die E-Mail mit dem Status- Code

551 User not local; please try Seite 56 Studienbrief 2 Spam-Techniken

(vgl. Abschnitt 3.4 aus ?) 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 ?). In diesem Fall wird die E-Mail ange- nommen, obwohl sich das Konto des Empfängers nicht auf diesem SMTP-Server befindet. Im Folgenden wird die E-Mail dann an den entsprechenden Server wei- tergeleitet, auf dem jedoch wieder nicht das Konto des Empfänger vorhanden sein muss.

Dieses Verhalten, bei dem der SMTP-Server eine E-Mail annimmt, bei der das Konto des Empfänger jedoch nicht auf dem eigenen Server liegt, wurde ursprünglich dazu implementiert, um dem Client die Möglichkeit zu bieten, die Route der E- Mail selber zu bestimmen. Befinden sich bspw. unterschiedliche SMTP-Server in einem Firmennetzwerk, wobei der Client selber nur direkten Zugriff auf einen der Server hat, so kann der Client dem Server vorschlagen, an wen die E-Mail als Nächstes zu senden ist.

Ursprüngliche Implementierungen von SMTP waren dabei so konfiguriert, dass sie auch E-Mails von unbekannten Servern ohne jegliche Form der Authentifizie- rung angenommen haben. Es war somit für den Nutzer möglich, anonym eine E-Mail zu verfassen und unter einer falschen Benutzerkennung direkt an diese offenen Weiterleitungs-Server zu schicken, die diese dann in das E-Mail-System einschleusten.

RFC 2505 Diese Möglichkeit > des E-Mail-Versands ist, da sie Anonymität ermöglicht, ideal, um Spam zu versenden. Aus diesem Grund waren offene Mail-Relays zu Beginn des Spam-Aufkommens Mitte der 1990er Jahre auch der am meisten verwendete Ursprung vom Spam. Als erkannt wurde, dass offene Mail-Relays häufig für den Versand von Spam verwendet werden, wurden verschiedene Verfahren empfohlen (vgl. ?), die diese Lücke schließen sollten. Ebenso wurden Empfehlungen in RFC 5321 (vgl. ?) eingearbeitet.

Kontrollaufgabe 2.8: Offene Mail-Relays K Was macht einen SMTP-Server zu einem offenen Mail-Relay?

Ein Proxy im Bereich von Computernetzen ist ein Computer, der innerhalb eines oder zwischen verschiedenen Netzen Pakete vermittelt. Konkret bedeutet dies im Fall verschiedener Netze, dass Computer A in Netz M mit Computer B in Netz N kommunizieren möchte, es aber keine direkte Route/Verbindung zwischen den beiden Netzen gibt. Ein Proxy kann nun zwischen den beiden Netzen M und N die Pakete von A an B weiterleiten und entsprechend von B an A. Dabei existieren ver- schiedene Arten von Proxies wie Proxy-Server, generische Proxies, Proxy-Firewalls, transparente Proxies und auch Reverse Proxies. Im Fall eines Netzes kann ein Proxy bspw. im allgemeinen Fall dazu verwendet werden, um bestimmte Daten für einen Dienst zu filtern. Dabei bieten sich auch SMTP-Proxies an, die innerhalb von Proxy-Firewalls dazu verwendet werden, um den Datenverkehr zu überwachen und Spam auszufiltern.

Ein offener Proxy ist nun ein Proxy, der ohne Anmeldung von jedem verwendet werden kann. Dies ist z.B. sinnvoll, sofern jemand anonym einen Dienst im Internet 2.6 Mail-Formulare Seite 57 verwenden und seine IP-Adresse daher verschleiern möchte. Ein reales Einsatz- szenario sind bspw. Krisenregionen, in denen die Regierung den Internetverkehr überwacht. Hier kann ein offener Proxy dazu verwendet werden, um mit anderen zu kommunizieren, ohne die eigene IP-Adresse dem Gesprächspartner mitteilen zu müssen.

Offene Proxies können aber auch zum E-Mail-Versand verwendet werden. Dabei verschickt ein Sender eine E-Mail an den Empfänger unter Verwendung der IP- Adresse des offenen Proxies. Dadurch sieht der Empfänger nur die IP-Adresse des offenen Proxies, aber nicht diejenige des ursprünglichen Senders. Somit verschleiert der Sender seine eigene IP-Adresse. Im Fall von Spam wurde dies genutzt, damit Spamversender, die bereits auf einer Blacklist (vgl. Abschnitt 3.5.1 ab Seite 72) stehen, weiterhin mithilfe einer anderen IP-Adresse Spam versenden können.

Es ist jedoch sehr simpel und auch ohne Weiteres automatisch möglich, offene Proxies in Blacklists einzutragen, weshalb diese Möglichkeit des Spamversandes heutzutage nicht mehr verwendet wird.

Kontrollaufgabe 2.9: Offene Proxies K Wodurch sind offene Proxies definiert?

2.6 Mail-Formulare Mail-Formulare sind nicht nur eine Anti-Harvesting-Methode (vgl. Abschnitt 2.4.3, RFC 1866 Unterpunkt Kontaktformulare ab Seite 54), sondern auch eine Methode zum Spam- versand. Formulare dienen generell der Erfassung und Verarbeitung von verschie- densten Daten. Dies können bspw. Grußtexte für ein Gästebuch oder auch Hinweise an einen Webseitenadministrator sein. Im HTML-Standard wurden ab Version 2 (vgl. ?) durch das

Schlüsselwort Formulare ermöglicht. Diese Formulare können verschiedene Felder enthalten, die vom Webseitenbesucher ausgefüllt wer- den können. Exkurs 2.3 auf Seite 58 gibt weitere Informationen zu den Feldern von HTML-Formularen. Der Inhalt kann dann wiederum mithilfe von verschiede- nen Methoden, in HTML Version 2 ausschließlich METHOD=GET oder METHOD=POST, an den Webserver zur weiteren Verarbeitung übertragen werden. Die Verarbei- tung auf dem Webserver wird separat implementiert. So ist eine Implementierung denkbar, welche die im Formular angegebenen Daten an eine bestimmte E-Mail- Adresse versendet. Durch Absicht des Entwicklers oder auch einen Fehler ist es aber auch möglich, dass der Empfänger mithilfe von Formularfeldern durch den Nutzer selber definiert wird. Somit ist es für einen Nutzer möglich, ohne eigenen E-Mail-Client eine E-Mail an eine beliebige Adresse zu verschicken. Automatisierte Programme suchen nach genau diesen fehlerhaften Formularen im Internet und nutzen diese dann, um eine Werbebotschaft an viele Empfänger zu schicken. So wird das Formular zur Quelle von Spam.

Kontrollaufgabe 2.10: Mail-Formulare 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. Seite 58 Studienbrief 2 Spam-Techniken

Exkurs 2.3: Felder in HTML Formularen E Der HTML Standard in Version 4 erlaubt verschiedene Arten von Formular- feldern. In diesem Exkurs werden die verschiedenen Felder vorgestellt. check box Dieses Feld wird verwendet, um vom Benutzer eine ja/nein- Auswahl zu erhalten. Damit können Informationen abgefragt werden, wie bspw. die Auswahl eines Newsletter-Empfangs. file select Mit diesem Feld erhält der Benutzer einen Auswahldialog für Dateien. Hiermit können z.B. Bilder hochgeladen werden. radio button Diese Felder sind nur in Gruppen von mindestens zwei Ele- menten sinnvoll. Mit solchen Feldern kann eine von verschiedenen Optionen ausgewählt werden, wobei alle Informationen durchge- hend 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 darauf- hin die vorher definierten Standardwerte wiederhergestellt. select list Mithilfe der select list kann der Nutzer aus einer ausklap- penden Liste ein Element auswählen. Je nach Konfiguration ist auch eine Mehrfachauswahl möglich. submit button Diese Feld wird im Browser als Knopf dargestellt, der den Browser dazu veranlasst, die im Formular angegebenen Daten mithil- fe der durch das Formular definierten Methode zu verarbeiten. Im Allgemeinen besteht die Verarbeitung aus einem Transfer der Daten zum Server, der diese dann weiter bearbeitet. text area Ein text area ist ein Feld, in das Text eingetragen werden kann. Im Gegensatz zum nächsten Formularfeld, der text box, ist es aller- dings auch möglich, mehrzeiligen Text einzugeben. text box Die text box ist ein Element zur Eingabe von einzeiligen Texten. Hier können Buchstaben, Zahlen und auch beliebige Sonderzeichen eingetragen werden. Eine text box kann verschiedene Eigenschaften haben. Dazu zählen vordefinierte Eingaben, Längenbegrenzungen oder auch die Kennzeichnung als Passwortfeld. Wird eine text box als Passwortfeld definiert, so erscheinen bei einer beliebigen Eingabe ausschließlich Sternsymbole, damit das Passwort nicht per Shoulder- Surfing von anderen entdeckt werden kann.

2.7 Webmail RFC 1945, RFC Webmail ist ein Dienst, der von unterschiedlichen Anbietern zur Verfügung gestellt 2616, RFC 2854 wird, um eine E-Mail-Kommunikation ohne eigenen E-Mail-Client zu ermöglichen. Dazu benötigt der Benutzer als Clientsoftware ausschließlich einen Browser, um den Dienst im WWW zu erreichen. Die gesamte Kommunikation zwischen Server und Client läuft über HTTP (Hypertext Transfer Protocol, vgl. ? und ?. Daher wird kein SMTP, IMAP oder POP3 benötigt. Zumeist wird HTML (Hypertext Markup Language, vgl. ?) als Beschreibungssprache verwendet. Die Vorteile von Webmail liegen damit klar auf der Hand: Der Nutzer kann den Dienst von jedem an das Internet angeschlossenen Rechners, der über einen Browser verfügt, verwenden. Es ist keine Synchronisation des Postfaches auf verschiedenen Computern notwendig und es muss weiterhin keine Sicherung der Nachrichten durch den Benutzer durchgeführt werden. Im Allgemeinen werden die Daten durch den Dienstanbieter professionell gesichert und stehen daher auch noch nach einem Hardwarefehler 2.7 Webmail Seite 59 dem Nutzer zur Verfügung. Der Nachteil des Dienstes besteht darin, dass E-Mails bei jeder Betrachtung über die Internetverbindung übertragen werden müssen, was den Datenverkehr erhöht. Außerdem wird der Nutzer in einem gewissen Grad abhängiger vom Dienstanbieter: Es ist dem Nutzer nicht möglich, die Ausstattung des Webmail-Servers zu ändern, um bspw. die Geschwindigkeit beim Durchsuchen von E-Mails zu erhöhen. Je nach Dienstanbieter stehen unter Umständen auch nur begrenzt viel Speicherplatz zur Verfügung, oder der Speicherplatz kann nur durch finanzielle Unterstützung des Dienstanbieters durch den Nutzer vergrößert werden.

In diesem Kontext müssen nun aber zwei Fragen untersucht werden. Zum einen muss geklärt werden, warum Webmail überhaupt zum Spamversand verwendet wird. Zum anderen ist interessant, wie Webmail zur Quelle von Spam wird. Beide Fragestellungen werden im folgenden Abschnitt geklärt.

Wie bereits in den vorherigen Abschnitten beschrieben, existieren viele Möglich- keiten zum Versand von Spam, die auf Fehlern der ursprünglichen Implementie- rungen von Protokollen basieren, bzw. auf dem zum Zeitpunkt der Entwicklung nicht vorhandenen und auch nicht nötigen Sicherheitsbewusstseins. Daher lässt sich die Frage nach dem „Warum“ leicht beantworten: Nachdem mehr und mehr Lücken geschlossen wurden und der Versand von Spam immer schwieriger wurde, wurden von den Versendern von Spam Möglichkeiten gesucht, Spam über andere Transportwege in das E-Mail-Netz einzuschleusen. Webmail ist neben den im nächsten Abschnitt behandelten Botnetzen die aktuell am weitesten verbreitete Möglichkeit, um Spam zu versenden. Das Einzige, was zum Versand von Spam über Webmail notwendig ist, sind die Benutzerdaten von vorhandenen E-Mail- Konten. Diese können auf der einen Seite durch Phishing (vgl. Abschnitt 1.9 ab Seite 36) von anderen Benutzern übernommen werden. Eine zweite Möglichkeit besteht darin, mithilfe von Botnetzen (vgl. Abschnitt 2.9 ab Seite 61) neue Konten zu erstellen, die dann ausschließlich für den Versand von Spam verwendet werden. Sind die Zugangsdaten bekannt, so können sich Bots programmgesteuert an die Konten der Webmail-Anbietern anmelden, um von dort aus Spam zu versenden. Der Vorteil, den Webmail für Bots bietet, liegt in der Tatsache begründet, dass die dann versendeten E-Mails von einem System oder Netzwerk versendet wird, das über eine gute Reputation verfügt. Die Reputation eines System ist wichtig, da es einige Techniken gibt, die anhand der Reputation E-Mails in Spam und Ham klassifizieren. Dazu zählen bspw. Listenverfahren wie White-, Black- und Grey- listing (vgl. Abschnitt 3.5 ab Seite 72) sowie entsprechende Reputationsverfahren (vgl. Abschnitt 3.6 ab Seite 78).

Andererseits versuchen Webmail-Anbieter den angebotenen Dienst entsprechend gegen Spam-Bots abzusichern. Dazu werden auf der einen Seite CAPTCHAs ver- wendet, die bei der Anmeldung sicherstellen sollen, dass sich wirklich ein Mensch und nicht ein automatisiertes Programm anmeldet. Auf der anderen Seite werten Anbieter wie Google auch die IP-Adresse des anmeldenden Computers aus, um zu überprüfen, aus welchem Land sich ein Benutzer anmeldet. Hat sich ein Benutzer immer aus demselben Land angemeldet, so ist bei einer erneuten Anmeldung 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? Seite 60 Studienbrief 2 Spam-Techniken

Kontrollaufgabe 2.12: Webmail II K Nennen Sie jeweils zwei Vor- bzw. Nachteile von Webmail.

2.8 IP Prefix Hijacking RFC 4271 Das Internet als globales Netzwerk besteht aus vielen Knoten. Jeder dieser Knoten verfügt über eine eigene IP-Adresse. Dieser Sachverhalte wird in Abschnitt 1.5.6 ab Seite 30 genauer beschrieben. Damit ein Paket sein Ziel erreicht, wird es an jedem Knoten in die richtige Richtung weiter geleitet. Da Router nur begrenzte Ressourcen haben und ein Paket möglichst schnell weiter geleitet werden soll, werden nicht an allen Punkten die exakten Informationen über alle möglichen 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. Gruppen von IP-Adressen, die sich unter einer zentralen Verwaltung wie bspw. einem ISP, einem großen Unternehmen oder einer Universität befinden. Um die Routing-Tabellen daher möglichst klein zu halten und schnell zu aktualisieren, werden die IP-Adressen eines autonomen Systems zu einem Präfix gruppiert. Diese Präfixe werden dann innerhalb der Border Gateways verteilt. Die Border Gateways stehen, wie der Name bereits suggeriert, zwischen einzelnen autonomen Systemen und vermitteln dazwischen. Für deren Kommunikation wird das Border Gateway Protocol (BGP, vgl. ?, ? und ?) verwendet. Per BGP werden die anderen autonomen Systeme also darüber informiert, wo sich bestimmte IP-Adressen befinden. Ein autonomes System teilt dazu den anderen autonomen Systemen auch mit, zu welchen Präfixen es Pakete annehmen und weiterleiten kann.

Filtertechniken, deren Aufgabe darin besteht, Spam von Ham zu unterscheiden, verwenden auch die IP-Adresse des Absenders als Kriterium. Es wird davon aus- gegangen, dass wenn bereits viele E-Mails aus einem bestimmten autonomen System als Spam klassifiziert wurden, dass die Spam-Wahrscheinlichkeit einer E-Mail von einer anderen IP-Adresse aus dem gleichen autonomen System deutlich größer ist. Gründe dafür sind leicht zu finden: Computer, die sich im gleichen autonomen System befinden, werden auch oft von derselben Instanz gewartet. Auf ihnen läuft die gleiche Software und insbesondere sind die Softwareversio- nen auf den einzelnen Rechnern gleich. Wurde nun einer der Rechner aus einem autonomen System mit Malware (vgl. Abschnitt 2.9 ab Seite 61) infiziert, so ist die Wahrscheinlichkeit sehr groß, dass andere Rechner im gleichen autonomen System die gleiche Sicherheitslücke aufweisen und daher ebenfalls mit Malware infiziert werden. Den Versendern von Spam ist dies natürlich bewusst und so haben sie nach einer Möglichkeit gesucht, ihre Absenderadresse bzw. ihr eigenes autonomes System dahingehend zu ändern, dass ihre Nachrichten nicht mehr aufgrund des autonomen Systems bzw. ihres Präfixes als Spam klassifiziert und danach gefiltert werden. Diese Möglichkeit wird als IP Prefix Hijacking oder IP Hijacking bezeichnet. Es existieren verschiedene Möglichkeiten, um diesen An- griff durchzuführen. Zum einen kann ein autonomes System anderen autonomen Systemen mitteilen, dass es ein Präfix beinhaltet, obwohl dies gar nicht der Fall ist. Zum anderen kann ein autonomes System auch ankündigen, dass es über eine kürzere Route zu einem bestimmten autonomen System verfügt und Pakete über dies autonome System geleitet werden soll, obwohl die Route eigentlich länger ist. In beiden Fällen werden Pakete durch das autonome System geleitet, die eigentlich einen anderen Weg gehen sollten. Dies ist soweit noch kein Problem, sofern die 2.9 Malware / Botnetze Seite 61

Pakete einfach eine andere Route gehen. Es ist nun aber für das kompromittierte autonome System möglich, auch Pakete selber zu erstellen und als Quelle das „ent- führte“ autonome System anzugeben. Somit können auch E-Mails erstellt werden, deren Ursprung eine IP-Adresse zu sein scheint, die in einem autonomen System liegt, das nicht als Ursprung von Spam markiert ist, obwohl der Ursprung der Nachricht in dem autonomen System liegt, das als Quelle für Spam bereits erkannt wurde. Der Sinn des IP Prefix Hijackings liegt also darin, die Absenderadresse soweit zu verschleiern bzw. zu fälschen, dass Filtertechniken die E-Mails aufgrund ihres Ursprungs nicht als Spam klassifizieren. ? greifen in einer Untersuchung diesen Sachverhalt auf. Sie finden dabei bspw. auch heraus, dass eine Klassifikation nach Netzwerkeigenschaften bessere Ergebnisse innerhalb ihrer Studie liefert, als eine auf dem Inhalt basierende Klassifikation.

Im nächsten Abschnitt wird auf den aktuell am meisten verbreiteten Ursprung von Spam eingegangen, die sogenannten Botnetze.

Kontrollaufgabe 2.13: IP Prefix Hijacking K Wie funktioniert das IP Prefix Hijacking?

2.9 Malware / Botnetze Als letzte Technik werden in diesem Studienbrief Malware und die damit in direk- tem Zusammenhang stehenden Botnetze behandelt. Malware (vgl. Definition 2.1) ist ein Kunstwort, das aus den beiden Begriffen malicious (dt. schädlich) und Software zusammengesetzt ist. Es handelt sich bei Malware also um schädliche oder schadhafte Software. Dabei ist die Unterscheidung zwischen Goodware, also gutartiger Software, und Malware nicht trivial für den Benutzer, da er die Funktio- nalität einer Software nur durch deren Ausgabe erkennen kann. Was eine Software allerdings im Hintergrund macht, ist für ihn nicht direkt ermittelbar. Um zu erken- nen, ob es sich bei einer Software um Malware oder Goodware handelt, werden verschiedene Techniken eingesetzt, die sich grob in die statische und die dynami- sche Analyse gliedern. Bei der statischen Analyse von Software wird der Binärcode betrachtet und es werden Merkmale extrahiert wie bspw. Dateigröße, Entropie und die enthaltenen Bytefolgen. Bei der dynamischen Analyse wird die Software hingegen ausgeführt und es wird das Verhalten der Software protokolliert. Zum Verhalten zählen bspw. Syscalls, also Aufrufe, die vom System abgearbeitet werden oder auch Netzwerkverbindungen, die zu bestimmten Servern aufgebaut werden. Anhand des dabei entstehenden Protokolls kann dann geprüft werden, ob das Verhalten der Software entweder verdächtig ist, oder es vielleicht sogar schon eine Software mit ähnlichem Verhalten gab, die als Malware klassifiziert wurde. Da die Analyse von Malware allerdings ein sehr komplexes Thema ist, wird sie hier nicht Seite 62 Studienbrief 2 Spam-Techniken

weiter vertieft. Wichtig bleibt zu behalten, dass Malware Software ist, die einem schadhaften Zweck dient.

Definition 2.1: Malware D Angelehnt an ? wird Malware durch die folgenden drei Charakteristika definiert: Selbstreplikation Die Schadsoftware verbreitet sich entweder aktiv, in- dem bspw. Kopien des ausführbaren Codes auf andere Systeme trans- feriert werden oder passiv, indem der Benutzer die Schadsoftware versehentlich kopiert. Populationswachstum Die Gesamtzahl der Instanzen der Schadsoftware steigt bedingt durch die Selbstreplikation. Parasitismus Schadsoftware hängt sich an oder vermischt sich mit ande- rem ausführbaren Code, um unentdeckt zu bleiben. Infolgedessen kann es auch zu einem Populationswachstum kommen. Auch eine passive Selbstreplikation ist denkbar, sobald der Anwender Kopi- en des Codes, mit dem sich die Schadsoftware vermischt hat, auf anderen Systemen nutzt.

Da der Zweck von Malware auch der Versand von Spam sein kann, ist das Studium von Malware auch wichtig für das vorliegende Modul. Es wird hier allerdings nur ein sehr grober Überblick darüber gegeben, wie sich Malware verbreitet und warum Malware für den meisten weltweiten Spam verantwortlich ist.

Wie schon weiter oben beschrieben, repliziert sich Malware entweder aktiv oder passiv. Die passive Selbstreplikation ist jedoch auf eine Benutzerinteraktion ange- wiesen, die im Gegensatz zur aktiven Selbstreplikation sehr langwierig sein kann. Deshalb setzt aktuelle Malware auf eine aktive Selbstreplikation. Dazu werden Sicherheitslücken in Server- und auch Client-Software gesucht, über die Schadcode eingeschleust werden kann. So ließen sich in der Vergangenheit oftmals Standard- dienste von Windows Betriebssystemen missbrauchen, um Zugriff auf ein System zu bekommen. Der eingeschleuste Schadcode enthält oft allerdings nicht die Mal- ware selbst, sondern dient nur dazu, die Malware nachzuladen, um sie daraufhin auszuführen. Wurde die Malware erfolgreich nachgeladen, so verfolgt sie generell zwei Ziele. Zum einen versucht sie sich weiter zu replizieren. Dazu sucht sie nach Sicherheitslücken auf anderen an dasselbe Netzwerk angeschlossenen Computern. Zum anderen kann sie dann ihre Schadfunktion ausführen. Bei aktueller Malware existiert allerdings nicht eine einzige definierte Schadfunktion. Vielmehr verbindet sich die Malware mit anderen Instanzen, um Befehle zu empfangen, die sie dann abarbeiten kann.

Ist ein Computer mit Malware infiziert, und kann entsprechend von einer dritten Person kontrolliert werden, so spricht man bei dem Computer von einem Zombie oder Bot. Verbinden sich viele dieser Bots zu einem Netzwerk, so wird dies als Botnetz bezeichnet.

Botnetze sind je nach Quelle für ca. 85 % des weltweiten Spams verantwortlich (vgl. ?) und unterscheiden sich durch unterschiedliche Kommunikationsstrukturen. Generell können diese in zentrale und dezentrale Strukturen unterteilt werden. Der Kommunikationskanal wird dabei als Command and Control (C&C)-Struktur bezeichnet. Eine zentrale Struktur verfügt über einen oder wenige Server, die vom Botmaster betrieben werden und viele Bots, die ihre Befehle direkt von den Servern beziehen. 2.9 Malware / Botnetze Seite 63

IRC

Eine der ersten genutzten Techniken, um einen C&C-Kanal zu erzeugen, ist die RFC 1459 Nutzung von IRC (Internet Relay Chat). Das IRC-Protokoll wird in RFC 1459 (vgl. ?, ?, ?, ? und ?) definiert. Ursprünglich für die Kommunikation von Menschen ge- dacht, eignet sich IRC auch zur Kommunikation zwischen Botmaster und den einzelnen Bots. Dabei bietet die Kommunikation über IRC verschiedene Vorteile. Zum einen ist es für Betreiber sehr einfach, eigene Server aufzubauen, da es viele Implementierungen des Protokolls gibt. Weiterhin können auch vorhandene Server verwendet werden. Gleichzeitig können verschiedene Botnetze über denselben Server verwaltet werden, da einzelne Kommunikationen durch unterschiedliche Kanäle voneinander getrennt werden können. Weiterhin bietet IRC die Möglich- keit zur Kommunikation sowohl vom Botmaster zum Bot als auch vom Bot zum Botmaster, also in beide Richtungen. Somit kann der Botmaster Befehle an den Bot senden und gleichzeitig Status-Codes vom Bot zurückerhalten oder Daten von kompromittierten PC abgreifen. Dazu kommt noch, dass IRC mit einfachen Möglichkeiten redundant ausgelegt werden kann. Hierfür muss nur ein zweiter separater Server aufgesetzt werden, an den sich die Bots sowie der Botmaster zusätzlich verbinden und im Falle einer Störung auf diesen Server ausweichen.

HTTP

Eine weitere Möglichkeit für eine zentralisierte Struktur ist bspw. die Kommunika- tion über einen Webserver per HTTP (vgl. ? und ?). Die Kommunikation per HTTP ist weit verbreitet, da Port 80, der standardmäßig für HTTP verwendet wird, in den seltensten Fällen durch Firewalls blockiert wird, da dieser Port für das World Wide Web von essentieller Bedeutung ist. Außerdem ist die Nutzung eines HTTP-Servers aufgrund der Skalierbarkeit vorteilhaft. Mit einem entsprechend großen Intervall können sich Bots neue Informationen vom Server laden und müssen dazu keine persistente Verbindung zum Server aufhalten. Bei der im vorherigen Abschnitt vorgestellten Kommunikation per IRC, sind die Bots durchgehend mit dem Server verbunden, wodurch die maximale Anzahl der verbundenen Bots deutlich kleiner ist.

FTP

Neben IRC und HTTP kann der C&C-Kanal auch per FTP betrieben werden. Hier können dann auch problemlos Dateien vom Client, auf dem sich der Bot befindet, an den Botmaster übertragen werden.

Sowohl bei IRC als auch bei HTTP und FTP besteht jedoch das Problem, dass die Bots wissen müssen, an welche IP oder welche Domain sie sich verbinden müssen. Diese Information muss der Bot haben, bevor er sich das erste Mal mit einem C&C-Server verbindet. Daher ist oft eine Reihe von Zieladressen bereits fest im Quellcode des Bots implementiert. Behörden haben die Möglichkeit, ein- zelne Server zu sperren, wodurch sich die Bots nicht mehr mit dem Botmaster verbinden können und somit auch keine weiteren Befehle mehr erhalten. Sind dem Bot mehrere Adressen bekannt, so kann er zumindest versuchen, auf andere Kanäle auszuweichen. Trotzdem besitzt dieses zentrale Kommunikationsmodell die Schwachstelle, dass es ausreicht, wenige Server vom Netz zu nehmen, um die gesamte Kommunikation zu stoppen. Aus diesem Grund wird immer öfter das im nächsten Abschnitt vorgestellte Peer-to-Peer-Modell verwendet. Seite 64 Studienbrief 2 Spam-Techniken

Peer-to-Peer

Beim Peer-to-Peer-Modell wird generell keine zentrale Instanz eingesetzt. Es existie- ren 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 de- nen oft auch illegale Inhalte zwischen verschiedenen Benutzern (oberflächlich anonym) ausgetauscht werden. Wird dieses Modell zur Kommunikation gewählt, so fungieren prinzipiell alle Bots sowohl als Client als auch als Server und halten mehrere Verbindungen zu anderen Teilnehmern offen. An einer beliebigen Stelle im Netz muss dann nur ein Befehl eingefügt werden, der von jedem Teilnehmer weiterverbreitet wird. Somit erhalten früher oder später alle Bots die aktuellen Befehle und können auch eigene Informationen an andere Bots weitergeben. Der Vorteil von diesem Kommunikationsmodell liegt ganz klar in der 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 Compu- ter 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 Adres- sen. Ein weiterer Einsatzzweck von Botnetzen können verteilte Denial-of-Service (DDoS)-Angriffe sein. Hierbei werden an einen Dienst gleichzeitig von vielen ver- schiedenen Bots so viele Anfragen gestellt, dass der Dienst für reguläre Nutzer nicht mehr verwendbar/verfügbar wird. Weiterhin können entsprechend auch Aktionen ausgeführt werden, die den Benutzer des kompromittierten Rechners betreffen. So können bspw. Werbebanner, die auf Webseiten angezeigt werden, durch die Schadsoftware auf dem Bot ausgetauscht werden. Der Benutzer kann genauso ausspioniert werden. Dies geschieht nicht nur für Kontakte des Nutzers auf Basis der in E-Mail-Programmen vorhandenen E-Mail-Adressen, sondern eben- falls für das gesamte sonstige Verhalten des Nutzers. Es können Passwörter für jegliche Webseiten gespeichert und an den Botmaster weiter gegeben werden sowie auch PIN/TAN beim Online Banking oder Kreditkartennummern beim Einkauf im Internet. Der Computer des Opfers kann ebenfalls dazu benutzt werden, um automatisch bestimmte Seiten im WWW zu besuchen, um deren Popularität zu steigern. Genauso kann die Rechenleistung des Computer verwendet werden, um bspw. per Brutforce Passwörter zu knacken. Insgesamt existieren viele ande- re Angriffsszenarien, die jedoch an dieser Stelle nicht weiter behandelt werden sollen.

Es existieren viele Ansätze, um Botnetze zu deaktivieren. Es gibt jedoch keine generell Methode, die immer hilfreich ist. Oft hilft nur ein Studium des konkreten Botnetzes, um die internen Strukturen zu verstehen und mögliche Schwachstellen zu finden, wie von ? beschrieben.

Zusammenfassend kann jedoch gesagt werden, dass Botnetze insgesamt für eine große Masse an Spam verantwortlich sind. Dabei haben die fünf zurzeit größ- ten Botnetze Cutwail (vgl. ?), Srizbi (vgl. ?), Grum (vgl. ?), Rustock (vgl. ?) und 2.10 Zusammenfassung Seite 65

Mega-D (vgl. ?) 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 Malware 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 ver- schiedenen Verknüpfungen zu anderen Instanzen notwendig sind. Daraufhin wurden offene Mail-Relays besprochen und beschrieben, wie es zum anonymen Versand von Spam über diese Strukturen kommen konnte. Die danach angespro- chenen offenen Proxies waren dann eine generelle Möglichkeit, um anonym Spam zu verschicken, bevor der Abschnitt über Mail-Formulare diese Möglichkeit zum Versand von Spam aufbereitete. Webmail als professionelle aber eigenständige Ausprägung von Mail-Formularen wurde daraufhin behandelt. Um fremde 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.11 ab Seite 66 die Übungsaufgaben auflistet. Seite 66 Studienbrief 2 Spam-Techniken

2.11 Übungen

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

Übung 2.2: Adress-Harvesting II Ü Wie sollten E-Mail-Adressen hinterlegt werden, damit sie nicht dem 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 Schutz- mechanismen? 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. ?) und finden Sie heraus, wie viele Zeichen der Local-Part einer E-Mail-Adresse maximal enthalten darf. Gehen Sie nun davon aus, dass der Local-Part nur die Buchstaben von A bis Z, die Ziffern von 0 bis 9 enthält und dass der Versand einer E-Mail 0,1 Sekunde dauert. 1. Wie viele mögliche E-Mail-Adressen lassen sich daraus generieren? Geben Sie dafür eine Summenformel an und keine konkrete Zahl. 2. Wie lange würde der E-Mail-Versand an alle so generierten E-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 zu versendende E-Mail dann enthalten?

Übung 2.5: ROT13-Verschiebechiffre I Ü Begründen Sie, warum bei der ROT13-Verschiebechiffre nur eine Funktion sowohl für die Ent- als auch für die Verschlüsselung benötigt wird.

Übung 2.6: ROT13-Verschiebechiffre II Ü Welche Methoden können bei der ROT13-Verschiebechiffre verwendet wer- den, wenn nicht nur Groß- sondern auch Kleinbuchstaben in einem Klartext auftreten? Unter welcher Voraussetzung lässt sich immer noch Modulo 26 rechnen? 2.11 Übungen Seite 67

Übung 2.7: ROT13-Verschiebechiffre III Ü Berechnen Sie den Geheimtext für „Spam-Techniken“ durch die ROT13- Verschiebechiffre unter der Berücksichtigung, dass Groß- und Kleinbuchsta- ben getrennt voneinander verschoben werden.

Übung 2.8: Alternativen zu HTTP-GET und HTTP-POST Ü Finden Sie heraus, welche Methode neben HTTP-GET und HTTP-POST als Alternative möglich ist.

Übung 2.9: HTML-Formulare Ü Erstellen Sie eine einfache HTML-Seite, die ein Formular zur Eingabe von Vornamen, Nachnamen, E-Mail-Adresse und ein Textfeld für einen Gruß ent- hält. Beschreiben Sie, wie diese Daten auf der Serverseite falsch interpretiert werden können, damit eine Quelle für Spam entsteht.

Übung 2.10: Shoulder-Surfing Ü Verwenden Sie eine Suchmaschine Ihrer Wahl, um herauszufinden, was Shoulder-Surfing ist und welche Abwehrmaßnahmen es dagegen gibt.

Übung 2.11: Malware I Ü Untersuchen Sie welche verschiedenen Arten es von Malware gibt und entscheiden Sie, welche der in Definition 2.1 auf Seite 62 vorgestellten Ei- genschaften 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 69

Studienbrief 3 Anti-Spam-Techniken

3.1 Lernergebnisse Sie können sowohl ältere als auch aktuelle Anti-Spam-Techniken benennen und beschreiben. Sie sind in der Lage, die Funktionsweise dieser Techniken zu erläutern und auf E-Mails anzuwenden. Des Weiteren können Sie Vor- und Nachteile der vorgeschlagenen Verfahren benennen.

3.2 Advanced Organizer Wie kann eine Spam-Nachricht erkannt werden, bevor sie dem Empfänger zuge- stellt wird? Dies ist die zentrale Frage dieses Studienbriefs. Es werden verschiedene Ansätze vorgestellt, die etwa Nachrichten klassifizieren oder den Absender einer Nachricht als Spammer erkennen.

3.3 Einleitung Dieser Studienbrief behandelt unterschiedliche Anti-Spam-Techniken. Dabei be- ginnt Abschnitt 3.4 mit einfachen Filtermethoden, die ausschließlich nach dem Inhalt der Nachrichten klassifizieren. Daraufhin werden in Abschnitt 3.5 IP-Sperren vorgestellt, bei denen nicht der Inhalt für die Klassifikation ausschlaggebend ist, sondern der Ursprung, also die IP-Adresse des Senders bzw. die Form der Im- plementierung des E-Mail-Clients des Senders. Weiter werden aktuellere Metho- den vorgestellt, wie Reputationsverfahren (Abschnitt 3.6) sowie Challenge- und Response-Verfahren (Abschnitt 3.7), die nicht über statisch Listen die E-Mails er- kennen, sondern unterschiedliche Eigenschaften des Senders zur Klassifikation verwenden. Danach werden Erweiterungen des klassischen E-Mail-Verfahrens vor- gestellt, die eine erfolgreiche Klassifikation erleichtern sollen (Abschnitt 3.8). Die weiteren Abschnitte beschreiben dann aktuelle Forschungsarbeiten, die sich mit dem Problem Spam auseinandersetzen. Dabei geht es von der Echtzeitfilterung von Spam in Abschnitt 3.9 über die Erkennung (Abschnitt 3.11) und Übernahme (Ab- schnitt 3.12) von Botnetzen zur automatischen Generierung von Spam-Signaturen (Abschnitt 3.13), bevor eine konkrete Implementierung einer Software zur Spam- klassifikation vorgestellt wird (Abschnitt 3.14).

3.4 Mailfilter Die einfachste Art zur Unterscheidung von Nachrichten in Spam und Ham ist die Klassifikation durch Filter, wobei die E-Mails auf spezifische Kriterien hin untersucht werden. Filter können sowohl auf den Header als auch auf den Body oder auf beide Teile einer E-Mail angewendet werden. Sie können auch sowohl auf dem Server als auch im E-Mail-Client des Nutzers implementiert sein. Dazu werden in diesem Abschnitt zuerst Filter betrachtet, die auf Regeln basieren. Danach solche, die spezielle Signaturen zur Klassifikation einsetzen und abschließend werden Bayes-Filter stellvertretend für eine Gruppe von statistischen Filtern besprochen.

Regeln

Die Regel-basierte Filterung von Spam kann eine Liste von Wörtern oder regulären Ausdrücken verwenden, die in einer E-Mail nicht vorkommen dürfen. So können Regeln definiert werden, die entweder nur auf den Header, nur auf den Body oder auf die gesamte E-Mail angewendet werden müssen. Diese Regeln können auch verbunden werden, sodass ein System von Regeln entsteht, das überprüft werden muss. Diese Lösung kann sehr aufwendig sein, da im einfachsten Fall für jede Seite 70 Studienbrief 3 Anti-Spam-Techniken

einzelne Regel die gesamte Nachricht daraufhin überprüft werden muss, ob sie ein einziges Wort enthält. Spammer können diese Regeln leicht umgehen, indem sie bspw. einzelne Wörter nicht mehr verwenden, sondern solche, die ähnlich klingen, aber anders geschrieben werden. Dabei kann der Vokal I zum Beispiel durch die Zahl 1 ersetzt werden. Diese Ersetzungen können dann entsprechend wieder in die Wortlisten eingefügt werden, wodurch die Listen aber immer länger werden oder die regulären Ausdrücke immer komplizierter.

Daher sind Signaturen eine weitere und verbesserte Form der Mailfilterung.

Signaturen

Bei der Filterung durch Signaturen wird nicht der gesamte Inhalt einer E-Mail betrachtet. Es geht viel mehr um Eigenschaften der E-Mail, die diese klassifizieren. Dazu können Hashfunktionen eine kurze Darstellung der E-Mail berechnen, um diese mit bereits vorhandenen Hashes abzugleichen. Diese Hashes müssen jedoch robust gegen geringe Abänderungen sein, da zufällige Zeichen in E-Mails enthalten sein können oder bestimmte Schlüsselwörter, wie weiter oben beschrieben, durch äquivalente Wörter mit anderer Schreibweise ausgetauscht werden. Sind mehre- re Signaturen vorhanden, so können diese innerhalb einer Datenbank verwaltet werden, müssen jedoch ständig aktualisiert werden, um den Veränderungen der Spam-Nachrichten zu entsprechen. Die Erstellung einer Signatur muss entweder manuell erfolgen oder es bedarf einer vorherigen Klassifikation. Die Klassifikation sollte von Menschen durchgeführt werden, damit die dabei entstehenden Fehler so gering wie möglich gehalten werden. Signatur-Datenbanken können dann auch dezentral gehalten werden, damit viele Empfänger von den Signaturen profitieren. Dafür existieren bereits einige Ansätze (vgl. ?), die bspw. ein Peer-To-Peer-Protokoll einsetzen, um die so erstellten Signaturen zu verteilen.

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

Bayesfilter

Für die Filterung von Spam nach statistischen Methoden gibt es verschiedene Ansätze. Die bekannteste Methode geht auf das Bayes-Theorem (vgl. Gleichung 3.1) des Mathematikers Thomas Bayes (1701-1761) zurück, das erstmalig 1998 in ? zur Klassifikation von Spam verwendet wurde.

Für zwei Ereignisse A und B mit P(A) > 0 ist die bedingte Wahrscheinlichkeit (Wahrscheinlichkeit von A gegeben B)

P(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 eintreffen (vgl. ?). 3.4 Mailfilter Seite 71

Das Beispiel 3.1 verdeutlicht die Anwendung des Bayes-Theorems auf Spam- Nachrichten.

Beispiel 3.1: Bayes-Theorem 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 klassifiziert, von denen 700 die Zei- chenkette „cheap watch“ enthalten und weiterhin 1 000 E-Mails als Ham klassifiziert, von denen 2 die Zeichenkette „cheap watch“ enthalten, dann kann P(A|B) berechnet werden mit

700 5000 5000 × 6000 P(A|B) = 702 ≈ 99,72% 6000 Weiterhin können dann noch nicht klassifizierte Nachrichten mit einer Wahr- scheinlichkeit von 99,72% als Spam klassifiziert werden, sofern sie die Zei- chenkette „cheap watch“ enthalten.

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

P(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 klassifiziert werden kann, wenn sie die Wörter z1 und z2 und ... und zn enthält. Nach ? kann Gleichung 3.2 umgeformt werden zu

∏i P(zi|zi+1 ∧ ... ∧ zn ∧ A) × P(A) P(A|z1 ∧ z2 ∧ ... ∧ zn) = . (3.3) P(z1 ∧ z2 ∧ ... ∧ zn)

Ein Bayes-Filter wird weiterhin als naïve bezeichnet, sofern er vollständige sto- chastische Unabhängigkeit zwischen dem Auftreten der einzelnen zi annimmt. In diesem Fall kann Gleichung 3.3 vereinfacht werden zu

∏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, berech- net 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 implementie- ren und zu warten, jedoch sind sie sehr ungenau, sodass eine fehlerhafte Klassifi- kation nicht selten passiert. Dabei sind vor allem die falsch positiven Ergebnisse ein Störfaktor, da reguläre E-Mails, die fälschlicherweise ausgefiltert werden, vom Empfänger nicht gelesen werden können und der Sender oftmals nicht über die nicht erfolgte Zustellung unterrichtet wird. Filtermethoden haben oft eine hohe Ressourcenauslastung. Ist der Filter im E-Mail-Client installiert, so muss auch zuerst die gesamte E-Mail heruntergeladen werden, wenn bspw. der Body der Nachricht untersucht werden soll. Weiterhin haben Spam-Versender auf Mailfilter reagiert, indem sie die Spam-Nachrichten regulärer Nachrichten angleichen. Daher Seite 72 Studienbrief 3 Anti-Spam-Techniken

wird im nächsten Abschnitt eine Methode vorgestellt, die nicht nur den Inhalt einer Nachricht zur Klassifikation verwendet.

Kontrollaufgabe 3.1: Mailfilter K Welche Arten von Mailfiltern gibt es?

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

3.5 IP-Sperren Bei Verbindungen zwischen zwei Teilnehmern im Internet ist die IP-Adresse beider Teilnehmer von essentieller Bedeutung. Nur anhand dieser Adresse wissen die Router, die sich auf dem Weg zwischen den beiden Teilnehmern befinden, wohin ein Paket geschickt werden soll. Bei Verbindungen zu einem E-Mail-Server ist dies nicht anders. Auch der SMTP-Server muss wissen, zu welcher IP-Adresse Antworten geschickt werden müssen. Dabei offenbart die IP-Adresse eines Sen- ders viele Informationen. Zum Beispiel kann über die IP-Adresse herausgefunden werden, aus welchem Land ein Kommunikationspartner kommt und auch über welchen ISP er mit dem Internet verbunden ist. Da Mechanismen zur Abwehr von Spam davon ausgehen, dass ein Spammer von einem nicht eine sondern viele Nachrichten verschickt, erscheint es als sinnvolle Möglichkeit, die IP-Adresse des Absenders zur Spam-Klassifikation zu verwenden. Insgesamt setzen IP-Sperren also an genau diesem Punkt an. Wurde von einem bestimmten Computer einmal ei- ne Spam-Nachricht verschickt, so wird davon ausgegangen, dass dieser Computer in naher Zukunft auch weiterhin Spam-Nachrichten verschicken wird.

IP-Sperren werden über Listen realisiert. Dabei existieren schwarze Listen (engl. Blacklisting, vgl. Abschnitt 3.5.1), die IP-Adressen von Computern enthalten, von denen bekannt ist, dass sie Spam versenden. Weiße Listen (engl. Whitelisting, vgl. Abschnitt 3.5.2) sind davon genau das Gegenteil. Sie werden dazu verwendet, Absender zu identifizieren, die von weiteren Prüfungen komplett ausgeschlos- sen werden können. Eine Methoden zwischen den beiden genannten Verfahren sind graue Listen (engl. Graylisting, vgl. Abschnitt 3.5.3. Hier wird Spam durch technische Schwächen der von Spamversendern genutzten Software erkannt.

3.5.1 Blacklisting RFC 5782, DNSBL Blacklisting (vgl. ?) ist eine Technik, die im SMTP-Server genutzt wird, um IP- Adressen zu identifizieren, die für Spam verantwortlich sind. Dabei erhält der SMTP Server beim Verbindungsaufbau die IP-Adresse der Gegenseite und muss dann kurzfristig entscheiden, ob der Verbindungsaufbau durch den Versand von Spam motiviert ist, oder ob es sich um eine reguläre Anfrage handelt. Diese Ent- scheidung kann getroffen werden, indem bspw. auf dem Server eine Datenbank verwaltet wird, die IP-Adressen von Spamversendern enthält. Das nun entstehende Problem ist jedoch, dass ein Großteil des weltweiten Spams nicht von wenigen IP-Adressen (vgl. offene Mail-Relays und offene Proxys in Abschnitt 2.5 ab Seite 55) sondern von Botnetzen (vgl. Abschnitt 2.9 ab Seite 61) verursacht wird. Botnetze bestehen aber wiederum aus einzelnen Bots, deren IP-Adressen sich bedingt durch Wählverbindungen (Telefon bzw. ISDN) oder Zwangstrennungen (DSL) ständig ändern. Es ist somit nicht möglich, eine IP-Adresse, die einmal Spam versendet 3.5 IP-Sperren Seite 73 hat, ewig auf eine schwarze Liste zu setzen. Das Blacklisting setzt somit eine ge- wisse Dynamik voraus. IP-Adressen müssen sowohl entfernt als auch hinzugefügt werden können. Wird auf einem Server eine Datenbank eingesetzt, so kann bspw. ein Schwellwert, der die in einem bestimmten Zeitraum erhaltenen E-Mails zählt, entscheiden, ob eine IP-Adresse geblockt werden soll. Eine solche dezentrale Lö- sung birgt aber die Gefahr, dass immer nur Verbindungsversuche von Computern geblockt werden, die bereits vorher vom eigenen Server als Spamversender klassi- fiziert wurden. Eine sinnvollere Lösung bieten dabei schwarze Listen, die zentrale verwaltet und dann global genutzt werden können. Hierbei können dann auch Spamversender von einem SMTP-Server erkannt werden, die durch eine Klassifi- kation innerhalb eines anderen Netzwerks gefunden wurden. Eine Aktualisierung des Datenbankstandes kann auf verschiedenen Wegen durchgeführt werden. Es ist bspw. denkbar, dass der Datenbestand per HTTP abgefragt oder FTP verteilt werden könnte. Als sinnvoller Verbreitungsweg hat sich dabei jedoch DNS (vgl. Abschnitt 1.5.6 ab Seite 30) herausgestellt. DNS-Blacklists (DNSBL) benötigen, damit sie genutzt werden können, nur einen gewöhnlichen DNS-Server, der über eine Liste durch den Spamversand auffällig gewordenen IP-Adressen verfügt. Eine Anfrage eines SMTP-Servers an eine DNSBL geschieht dabei in den folgenden vier Schritten:

1. Der SMTP-Server empfängt eine Verbindungsanfrage von einem Client mit der IP-Adresse 12.34.56.78, die es zu untersuchen gilt. Er dreht daraufhin die einzelnen Teile der IP-Adresse um und erhält 78.56.34.12. 2. An den bereits erzeugten Teil des Namens wird der Domain-Name der DNSBL angehängt. Handelt es sich bspw. beim DNSBL um dnsbl.rub.de, so wird die Zeichenkette 78.56.34.12.dnsbl.rub.de erstellt. 3. Für die so erstellte Zeichenkette wird dann per DNS die IP-Adresse erfragt. Als Antwort kann dann entweder eine Adresse kommen. Diese Antwort besagt, dass die angefragte IP-Adresse auf der Liste des Anbieters vorhanden ist, oder es wird die Antwort NXDOMAIN (No such domain) zurückgegeben, die besagt, dass es keinen Eintrag in der Liste gibt. 4. Der Server kann dann noch optional beim DNSBL-Server anfragen, warum die IP-Adresse auf der Liste steht, um ggf. weitere Informationen dazu zu erhalten.

Blacklists können erfolgreich eingesetzt werden, wenn Verbindungsanfragen aus Netzen kommen, die für den Versand von Spam bekannt sind, da sie auf ganze Netzbereiche ausgeweitet werden können. Insbesondere können Blacklists effektiv sein, wenn nach bestimmten Clients gesucht wird, die schon seit langer Zeit aktiv Spam versenden und keine dynamische IP-Adresse habe. Blacklists haben aber auch eine Reihe von Nachteilen. So können sie gerade bei dynamischen IP-Adressen schnell zu Fehlern führen, sobald ein Client von seinem Provider eine IP-Adresse zugeteilt bekommt, die gerade von einem Bot verwendet worden ist, der zum Versand von Spam missbraucht wurde. Blacklists können nie vollständig aktuell sein, gerade weil zuerst erkannt werden muss, dass es sich um eine IP-Adresse handelt, die Spam versendet. Genauso können Blacklists ganze IP-Adressbereiche enthalten, die zu ISPs gehören, die von Spammern missbraucht wurden. 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 bei DNS effektiver Spam verbreiten können, was aber auch gleichzeitig zu einer Störung im WWW führt, da dann auch andere Adressen nicht mehr aufgelöst werden können und es somit möglich ist, dass Server nicht gefunden werden. Seite 74 Studienbrief 3 Anti-Spam-Techniken

Aufgrund der Tatsache, dass Backlists eine hohe Fehlerrate erzielen, wird in ? eine Überarbeitung des Konzeptes vorgestellt. Hierbei sollen globale Blöcke von IP-Adressen nicht mehr blockiert werden. Genauso soll auch die Reputation gan- zer Netze nicht mehr zur Klassifikation herangezogen werden. Dagegen wird untersucht, wie gut Spammer erkannt werden können, wenn lokale Faktoren be- rücksichtigt werden. Dazu werden zwei neue Techniken vorgestellt, zum einen die Verwendung eines dynamischen Schwellwertes und zum anderen eine spekulative Aggregation von IP-Adressen.

Abb. 3.1: Der ursprüng- liche Ansatz, um Black- lists zu erstellen aus ?.

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än- zen, um die Erkennung von Spam zu verbessern und damit auch bessere Blacklists zu erstellen. Um Blacklisten zu erstellen, werden normalerweise statische Fakto- ren verwendet. Haben bspw. 30 % aller verfügbaren Spam-Traps Spam von einer bestimmten IP-Adresse erhalten, so wird die IP-Adresse in die Blacklist eingefügt. Im neuen Ansatz (vgl. Abbildung 3.2) wird aus diesem statischen Schwellwert ein dynamischer Schwellwert. Die Berechnung des Wertes wird verändert, indem auch die Anzahl der E-Mails bewertet wird, die von einer IP-Adresse an den lokalen SMTP-Server versendet wurden. Somit fließen nicht nur globale Informationen in den Schwellwert ein sondern auch lokale Informationen. Auf die zweite Ei- genschaft des vorgestellten System soll an dieser Stelle nicht weiter eingegangen werden, da sich die Übungsaufgaben mit diesem Thema beschäftigen. 3.5 IP-Sperren Seite 75

Abb. 3.2: Der neue An- satz, um Blacklists zu erstellen aus ?.

Der nächste Abschnitt befasst sich mit einer sehr ähnlichen Technik, dem Whitelis- ting.

3.5.2 Whitelisting Das Whitelisting wird ähnlich wie das Blacklisting auch in RFC 5782 (vgl. ?) be- RFC 5782, DNSWL schrieben. Es handelt sich dabei um eine Technik, bei der eine Liste mit erwünschten IP-Adressen zur Klassifikation verwendet wird. Genauso wie beim Blacklisting kann diese Liste lokal erstellt und verwendet werden, aber auch global gehalten werden. Handelt es sich um eine globale Liste, die per DNS zur Verfügung gestellt wird, so wird in diesem Fall von einer DNS-Whitelist (DNSWL) gesprochen. Im Gegensatz zu Blacklists, bei denen davon ausgegangen wird, das alle Einträge auf der Liste zu Spam-Versendern gehören, deren Absenderadressen willkürlich gewählt werden, können die Einträge auf Whitelists anstelle von IP-Adressen auch E-Mail-Adressen enthalten. Sind diese E-Mail-Adressen allerdings bekannt, so haben Spammer die Möglichkeit, eine solche Adresse als Absenderadresse in ihre Spam-Nachrichten einzufügen, damit die E-Mail an den Empfänger übertragen wird und nicht durch den SMTP-Server blockiert wird. Es sollte dabei außerdem auch beachtet werden, dass Whitelisting als einzelne Technik zur Klassifikation von Spam und Ham eine sehr große Fehlerrate hat. Beim Whitelisting werden alle E-Mails, die nicht auf der Liste stehen, als Spam deklariert. Dieses rigorose Vorgehen führt dazu, dass nur eine fest definierte Anzahl an Absendern überhaupt als Sender infrage kommt und alles andere blockiert wird. Ist eine E-Mail-Adresse nur für die Kommunikation mit bestimmten anderen Konten vorgesehen, so kann dieses Vorgehen den Spam vollständig beseitigen. Im Normalfall soll die E-Mail- Adresse aber auch von anderen Nutzern erreichbar sein, was unter ausschließlicher Verwendung des Whitelistings ausgeschlossen ist. Aus diesem Grund sollte das Seite 76 Studienbrief 3 Anti-Spam-Techniken

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.5.3 Graylisting Obwohl es der Name vermuten lassen könnte, ist Graylisting keine Kombination aus Whitelisting und Blacklisting. Vielmehr handelt es sich beim Graylisting um eine durchdachte Ausprägung einer Listentechnik, die vollständig auf globale bzw. externe Dienste verzichtet. Beim Graylisting wird davon ausgegangen, dass die meisten Spam Nachrichten aus Botnetzen (vgl. Abschnitt 2.9 ab Seite 61) stammen. Die Bots wiederum implementieren jedoch nicht die vollständige Funktionalität von SMTP,besonders wird auf eine Fehlerbehandlung verzichtet, um die Implemen- tierung 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, spei- chert die IP-Adresse des Senders, die Absender-Adresse aus dem E-Mail-Header und auch die Empfänger-Adresse aus dem E-Mail-Header in einer Liste. Anschlie- ßend schließt der SMTP-Server die Verbindung und gibt vorher einen temporären Fehlercode (vgl. Exkurs 1.10 auf Seite 21) an den Client zurück. Der temporäre Fehler signalisiert dem Client, dass der Server aktuell nicht voll funktionstüchtig ist, der Client aber nach einer kurzen Zeitspanne den Nachrichtentransfer erneut versuchen kann. Reguläre E-Mail-Clients, die SMTP vollständig implementieren, verstehen die Antwort, warten daraufhin eine festgelegte Zeitspanne und versu- chen den Versand der E-Mail erneut. Unvollständig implementierte Bots befassen sich nicht weiter mit dem Versand der Spam-Nachricht an den entsprechenden Empfänger sondern versenden Spam an die weiteren Empfänger in ihrer Liste. Ver- sucht nun der reguläre Sender eine erneute Zustellung der E-Mail und verbindet sich mit dem SMTP-Server, so überprüft dieser in seiner Liste, ob das Tripel aus IP-Adresse, Absender-Adresse aus dem Header und Empfänger-Adresse aus dem Header bereits versucht hat, eine E-Mail zuzustellen. Es wird auch überprüft, ob die Zeitspanne zwischen dem ersten und dem nun zweiten Versuch groß genug war. Allgemeine handelt es sich bei der ersten Zeitspanne um 25 Minuten. Treffen diese Annahmen alle zu, so wird die E-Mail angenommen bzw. an den Empfänger weitergeleitet und der Absender für eine länger Zeitspanne in eine Whitelist über- nommen. 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 Konfiguration einfügen. • Die Hardwareressourcen, die benötigt werden, um zum einen die Liste zu speichern und zu verwalten und zum anderen eintreffende E-Mails mit einem Fehlercode abzuweisen, sind im Vergleich zu anderen Verfahren sehr klein. Dadurch ist es auch problemlos möglich, weitere dahinter geschaltete Verfahren auf die weitergeleiteten E-Mails anzuwenden, um Nachrichten, die von Bots mit einer vollständigen Implementierung von SMTP ausgehen, weiter zu behandeln. 3.5 IP-Sperren Seite 77

Es existieren aber auch Nachteile:

• Aufgrund der Zeitverzögerung wird die erste E-Mail zu einem Tripel aus Absender-IP, Absender-Adresse und Empfänger-Adresse je nach 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 Hin- dernis werden, wenn ein Nutzer auf einer Webseite die Zugangsdaten zu seinem Konto zurücksetzen möchte und neue Zugangsdaten per E-Mail anfordert. Die neuen Zugangsdaten werden dann bedingt durch die Zeit- verzö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. ?), da innerhalb RFC 2821 der RFC generelle temporäre Fehler nicht spezifiziert sind. Daher muss ja nach Greylist-Implementierung auch ein Fehlercode zurückgesendet wer- den, der nicht auf den wahren Grund des Fehler hinweist. • 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 ei- ne unter den Servern verteilte Datenbank handelt. In einem solchen Szenario kann nämlich nicht ausgeschlossen werden, dass der zweite Zustellversuch auf einem anderen SMTP-Server stattfindet.

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

3.5.4 Kontrollaufgaben In diesem Abschnitt befinden sich verschiedene Kontrollaufgaben, welche die Inhalte der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffes beitragen sollen.

Kontrollaufgabe 3.3: IP-Sperren I K Was sind IP-Sperren und welche verschiedenen Arten existieren?

Kontrollaufgabe 3.4: IP-Sperren II K An welcher Stelle werden IP-Sperren eingesetzt? Seite 78 Studienbrief 3 Anti-Spam-Techniken

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 einer besonderen Art der IP-Sperren und warum kommt es auch ohne externe Dienstanbieter aus?

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

3.6 Reputationsverfahren Verfahren, die nicht den Inhalt einer E-Mail auswerten, sondern Metaeigenschaften zur Klassifikation betrachten, werden als Reputationsverfahren bezeichnet. Eine konkrete Implementierung eines Reputationsverfahren stellt SNARE dar (vgl. ?). Die Motivation für SNARE war, dass IP-Blacklisting zu schwerfällig ist und durch Botnetze relativ leicht umgangen werden kann. Blacklisting hat den Nachteil, dass eine IP-Adresse als Ursprung von Spam ausfindig gemacht werden muss, bevor sie geblockt werden kann. Dabei haben viele Computer im Internet eine dynamische IP-Adresse, wodurch ein vorhandener Eintrag in einer Blacklist nach einem Neuzuweisung einer IP falsch werden kann. Blacklisting hat daher auch den Nachteil, dass grob 10 % der Spam-Versender vorher noch nicht als Spammer klassifiziert wurden (vgl. ?), 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. ?) sind. Daher wurde in SNARE ein Ansatz realisiert, der ausschließlich auf den Netzwerkeigenschaften von E- Mails basiert und ohne die Betrachtung der Inhalte der Nachrichten auskommt.

Die von den Autoren betrachteten Eigenschaften zur Klassifizierung von Nach- richten lassen sich in drei Gruppen einteilen. Zum einen werden Eigenschaften eingeführt, die nur auf einzelnen Netzwerkpaketen beruhen. Dazu kommt die zweite Gruppe von Eigenschaften, die nur auf einzelnen E-Mail-Headern oder 3.6 Reputationsverfahren Seite 79 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 stattfindet. Spam dagegen legt weitere Strecken zurück, sodass 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 Spamver- sender oft von anderen Spamversendern umgeben sind. Diese Behauptung wird in viele Arbeiten verwendet und lässt sich auch leicht nachvollziehen. Gruppen von Computern werden oft durch einzelne Instanzen verwaltet, die gewisse Richtlinien auf alle verwalteten Computer anwenden. So kann bspw. die Software auf einer Menge von Computern den gleichen Versi- onsstand 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 Klassifikation denkbar wird. 4. Das autonome System des Versender. Autonomes System Da nur wenige autonome Systeme für einen großen Anteil des Spams ver- antwortlich sind, kann die Nummer des autonomen Systems als Eigenschaft zur Klassifikation herangezogen werden. 5. Der Status der einzelnen Ports des Versenders. Port-Status Versender von regulären E-Mails sind im Normalfall Server, die auch gleich- zeitig 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. Da- her kann eine Klassifikation nach offenen Ports mögliche Spamversender identifizieren.

Weiterhin wurden Merkmale aus einzelnen Nachrichten extrahiert.

1. Die Anzahl der Empfänger. Anzahl Empfänger Oft werden Spam-Nachrichten nicht nur an einen sondern an mehrere Emp- fä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äufig aus Templates generiert, wodurch die Nachrichten einer Kam- Seite 80 Studienbrief 3 Anti-Spam-Techniken

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 mitberücksichtigt. Diese Merkmale wurden in den Prototypen SNARE implementiert und getestet. Dabei zeigt Abbildung 3.3 die gesamte Funktionsweise des SNARE-Frameworks.

Abb. 3.3: Das SNA- RE Framework aus ?.

Die Autoren planen dabei ein, dass ihr System auf einem dedizierten Rechner läuft und beschreiben den Arbeitsablauf wie folgt: Nachdem ein SMTP-Server das erste IP-Paket erhalten hat, wird eine Verbindung zum SNARE-Server aufgebaut und die oben beschriebenen Informationen übertragen. Dabei kann auch direkt die ganze Nachricht übertragen werden, wobei in diesem Fall länger gewartet werden muss, als es für das erste IP-Paket der Fall wäre. Hier muss also zwischen Erkennungsgenauigkeit und Geschwindigkeit entschieden werden. In einem zwei- ten Schritt werden E-Mails aussortiert, die über eine Whitelist gefunden werden. Wird eine E-Mail nicht durch einen Eintrag einer Whitelist erkannt, so wird diese durch SNARE analysiert, bevor andere Spamfilter oder Inhalts-basierte Analysen stattfinden. E-Mails erhalten daraufhin eine Bewertung und werden danach in einem dritten Schritt entweder schnell behandelt bzw. direkt weitergeleitet, sofern es sich um Ham handelt, oder können weiteren Methoden wie einem Graylisting unterzogen werden. Ergebnisse, bestehend sowohl aus Ham als auch aus Spam, können in einem vierten Schritt zurück an die Klassifikation von SNARE geschickt werden, um diese besser zu trainieren.

3.7 Challenge-Response-Verfahren Challenge-Response-Verfahren werden im Allgemeinen zur Authentifikation von Nutzern oder Computern untereinander verwendet. Dabei wird der anmelden- den Instanz eine Aufgabe gestellt, deren Lösung sie zur Anmeldung autorisiert. 3.7 Challenge-Response-Verfahren Seite 81

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.4.3 ab Seite 49) eingesetzt, bei denen der Anwender entweder Buchstaben aus einem Bild erkennen soll oder gesprochene Wörter aus einer Aufnahme identifizieren soll. In beiden Fällen können die CAPTCHAs er- schwert 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 vom Absender an den Empfänger verschickt, so kann der empfangende SMTP-Server die E-Mail temporär zwischenspeichern und den Absender dazu auffordern, zuerst eine Aufgabe zu lösen. Erst durch das Lösen der Aufgabe wird die temporär zwischengespeicherte E-Mail dann an den Empfänger weitergeleitet. Erhält ein reguläre Absender eine solche Aufforderung, kann er sich mit der Aufgabe auseinandersetzen und sie lösen. Ein Bot, der nicht für den Empfang von Nachrichten ausgelegt ist, beachtet die Aufgabe nicht und somit wird die temporäre Nachricht nach einem bestimmten Zeitintervall verworfen.

Mithilfe dieser Technik können viele Spam-Nachrichten aussortiert werden. Es existiert jedoch eine Reihe von Gründen, die Challenge-Response-Verfahren für den alltäglichen Gebrauch ausschließen:

• Die Nutzung des Verfahrens macht die Kommunikation per E-Mail zu ei- nem komplizierten Unterfangen. Für jede versendete Nachricht muss vom empfangenden SMTP-Server erst eine Anfrage an den Versender geschickt werden, die diesen um die Lösung einer Aufgabe bittet. Weiterhin muss der Versender der ursprünglichen Nachricht Zeit in die Lösung der Auf- gabe stecken, bevor seine E-Mail an den Empfänger weitergeleitet wird. Dadurch verzögert sich der gesamte Vorgang und macht die E-Mail als Kommunikationsmedium weniger interessant. • Bedingt durch die zusätzlichen E-Mails wird der gesamte Datenverkehr im Internet weiter erhöht. • Weiterhin werden auch Versender von regulären Massen-E-Mails wie Newslettern am Versand der Nachrichten gehindert, da für jeden einzel- 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 ge- fälscht ist, um möglichst unauffällig zu agieren. Wird nun die Absender- adresse gefälscht, so erhalten Unbeteiligte die Aufforderung zur Lösung einer Aufgabe, was in deren Augen wieder als Spam betrachtet werden kann. • Aufgaben, welche die Lösung eines CAPTACHs voraussetzen, diskriminie- ren damit seh- oder hörbehinderte Menschen, die solche Aufgaben nicht lösen können. Genauso können nicht behinderte Menschen nicht dazu in der Lage sein, ein CAPTCHA zu lösen, sofern das Hintergrundrauschen zu groß ist. • Spammer können die Aufgaben von Menschen lösen lassen, indem sie die CAPTCHAs an andere weiterleiten und dabei bestimmte Anreize zum Lösen anbieten. Somit verlagern die Spammer das Problem auf andere Menschen und leiden folglich nur an zeitlichen Verzögerungen, wobei die Spam-Nachrichten jedoch nicht durch das Challenge-Response-Verfahren aussortiert werden. Seite 82 Studienbrief 3 Anti-Spam-Techniken

Bedingt durch die aufgeführten Nachteile eignet sich die Versendung des Challenge-Response-Verfahrens nur in Ausnahmefällen oder unter Zuhilfenahme von anderen Verfahren.

3.8 Erweiterungen des E-Mail-Verfahrens Die Spezifikationen für den Versand von E-Mails wurden zu einer Zeit entwickelt, als niemand daran dachte, dass das System auch für kriminelle Handlungen, wie den Versand von Spam, verwendet werden könnte. Um die Mängel des System zu beheben, wurden unterschiedliche Erweiterungen vorgeschlagen. Einige dieser Erweiterungen werden innerhalb dieses Abschnittes beschrieben. Dabei handelt es sich zum einen um Systeme, die den E-Mail-Header erweitern, um zu zeigen, dass der Sender die Erlaubnis zum Versand hat (DKIM, SFP, Sender ID) oder eine bestimmte Arbeit verrichtet hat (Hashcash). Zum andern wird ein Ansatz vorgestellt, bei dem der Empfänger Möglichkeiten zur Steuerung des Empfangs hat (Receiver driven SMTP).

3.8.1 DomainKeys / DKIM RFC 6376 DomainKeys sind ein System zur Authentifizierung von E-Mails, das im Mai 2007 von Yahoo! Inc. als Mittel zur Bekämpfung von Spam in RFC 4870 (vgl. ?) vorge- stellt wurde. Unter dem Namen DomainKeys Identified Mail (DKIM) Signatures wurde das Verfahren in RFC 4871 (vgl. ?) spezifiziert. Nach einer Aktualisierung in RFC 5672 (vgl. ?) wurde mit RFC 6376 (vgl. ?) 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. Abschnitt 1.9 ab Seite 36) verwendet werden, fälschen die Absenderadresse ihrer versendeten E-Mails, um den Empfänger zu täuschen. So erhalten Empfänger E-Mails von Banken, die täuschend echt aussehen und auch anscheinend von der Bank verschickt wurden. DKIM setzt an dieser Stelle an, indem es den Versender mithilfe asymmetrischer Kryptographie (vgl. Exkurs 3.2 auf Seite 85) gegenüber dem Empfänger verifiziert. Grob gesagt wird dazu der Hash einer E-Mail mit dem privaten Schlüssel einer Organisation verschlüsselt und mit der E-Mail zusammen versendet. Der Empfänger kann dann per DNS den öffentlichen Schlüssel anfor- dern, den Hash entschlüsseln und überprüfen, ob der erhaltene Klartext mit dem selbst erstellten Hash übereinstimmt.

Etwas detaillierter passiert Folgendes: Beim Versand einer Nachricht führt der versendende SMTP-Server ein weiteres Header Feld mit der Bezeichnung DKIM-Signature in die E-Mail ein (vgl. Beispiel 3.2). Dieses Header-Feld erhält dann Tupel aus Bezeichnern und Werten, die zur Verifikation verwendet werden und ausschließlich aus US-ASCII-Zeichen (vgl. Exkurs 1.9 auf Seite 19) bestehen 3.8 Erweiterungen des E-Mail-Verfahrens Seite 83 dürfen. Der generelle Aufbau der DKIM-Signature wird in Exkurs 3.1 beschrieben, eine konkrete DKIM-Signature liefert Beispiel 3.2.

Exkurs 3.1: DKIM-Signature E y DKIM-Signature: v=1; a={Signaturalgorithmus/Hashalgorithmus}; c={Kanonisierungsmethode}; d={Domain}; s={Selektor}; h={Liste der verwendeten Header-Felder}; bh={Hashwert des Nachrichten-Bodys}; b={Signatur};

Die wichtigsten Tupel innerhalb der DKIM-Signature sind:

b= Digitale Signatur des Inhalts von Header und Body der E-Mail. bh= Hash des Bodys. d= Signierende Domain. s= Selektor, der den passenden Schlüssel auswählt. Für eine Domain können verschiedene Schlüssel erstellt werden. Die Einteilung kann nach dem Ort passieren, von dem die E-Mail aus verschickt wurde. Es ist weiterhin eine Einteilung nach Datum denkbar, damit der öffentliche Schlüssel regelmäßig problemlos ausgetauscht werden kann. Dazu ist auch denkbar, dass für einzelne Benutzer individuelle Schlüssel verwendet werden.

Beispiel 3.2: DKIM-Signature B Folgende Zeilen entstammen einer E-Mail, die durch einen SMTP-Server von Google verschickt wurde und eine gültige DKIM-Signature enthält. y Return-Path: [..] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=z/994Tdmf5f0KwPWF8mUfo3MOE5jKhmHSlp7TcM0SKU=; b=z2FOrPwVeYLFRd8LIJKnO7+tPkO+X7T7tMDyGjF3w7myjoaQeZijuEH+gre9yQLBDv TCaHhUBDZw4MHqspVi40crBDRd8tgyV9627BOkFR4B00mm/lgjJfrj8FIh1sEZ7r5Zw8 PrKEOIYGhTormy38DkTvnCBAeEU1Z3NU3oIM4908EjiMKS32JXDpiTrmnL8k8p7Rx+8l 8m04PJcl7ZLiSsx979Q8c81xW0XDxDMUiNwUDW1BmqTAqPc0K/jMxtjtAiFLuE0437JT VnX0B/0kLFvB7EWxwk8rL6d7Y6ZmWZyvKe0bOm3Y4OgUG6kPWEQcfQYue9oFfWQ5BElo OdcA== [..]

Es werden also Hashes von bestimmen Teilen der E-Mail erstellt und diese mithilfe eines privaten Schlüssels einer Domain verschlüsselt. Dabei kann ein privater Schlüssel für eine ganze Domain gelten, ebenso können aber für eine Domain auch unterschiedliche Schlüssel verwendet werden, die über den Bezeichner s= ausgewählt werden. Nachdem der SMTP-Server die DKIM-Signature zum Header der E-Mail hinzugefügt hat, wird die E-Mail an den Empfänger verschickt. Der empfangende SMTP-Server kann nun die E-Mail verifizieren. Dazu wird die DKIM- Seite 84 Studienbrief 3 Anti-Spam-Techniken

Signature untersucht, wobei eine DNS-Anfrage (vgl. Abschnitt 1.5.6 ab Seite 30) verschickt wird, die nach dem TXT-Eintrag, der im Header als Absender aufge- führten Domain fragt. Als Antwort erhält der SMTP-Server dann den öffentlichen Schlüssel zur angefragten Domain und dem entsprechenden Selektor (vgl. Bei- spiel 3.3). Mithilfe des Schlüssel kann dann der Hash der E-Mail berechnet werden und das Resultat mit der entschlüsselten Zeichenkette verglichen werden. Sind die beiden Zeichenketten gleich, so beweist die Gleichheit, dass die E-Mail von der entsprechenden Domain signiert wurde und auf dem Weg vom Sender zum Empfänger nicht verändert wurde. Dies natürlich nur unter der Voraussetzung, dass der private Schlüssel des Senders nicht öffentlich bekannt ist. Somit kann unter Zuhilfenahme von DKIM verifiziert werden, ob eine E-Mail wirklich von dem Absender stammt, der im Header der E-Mail angegeben ist.

Einen Überblick zu den zu DKIM existierenden Diensten wird in RFC 5585 (vgl. ?) gegeben. Eine mögliche Erweiterung, die Author Domain Signing Practices (ADSP), beschreibt RFC 5617 (vgl. ?).

Beispiel 3.3: DKIM-Verifikation B Für die aus Beispiel 3.2 erhaltene DKIM-Signature wird nun der öffentliche Schlüssel angefordert:

$ nslookup -query=txt 20120113._domainkey.googlemail.com [..] Non-authoritative answer: 20120113.\_domainkey.googlemail.com text = "k=rsa\; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1Kd87/U eJjenpabgbFwh+eBCsSTrqmwIYYvywlbhbqoo2DymndFkbjOVIPIl dNs/m40KF+yzMn1skyoxcTUGCQs8g3FgD2Ap3ZB5DekAo5wMmk4wi mDO+U8QzI3SD0" "7y2+07wlNWwIt8svnxgdxGkVbbhzY8i+RQ9Dp SVpPbF7ykQxtKXkv/ahW3KjViiAH+ghvvIhkx4xYSIc9oSwVmAl5O ctMEeWUwg8Istjqz8BZeTWbf41fbNhte7Y+YqZOwq1Sd0DbvYAD9N OZK9vlfuac0598HY+vtSBczUiKERHv1yRbcaQtZFh5wtiRrN04BLU TD21MycBX5jYchHjPY/wIDAQAB"

DKIM bietet zusammenfassend die Vorteile, dass es als Hilfsmittel gegen Phishing verwendet werden kann. Signieren Banken ihre E-Mails per DKIM, so können nicht oder fehlerhaft signierte E-Mails problemlos auch automatisch durch den E-Mail- Client des Nutzers angezeigt werden. Prinzipiell müssen keine Erweiterungen den Client betreffend implementiert werden. Das System muss nur innerhalb der versendenden und empfangenden SMTP-Server implementiert sein. Da es auf DNS aufsetzt, sind auch zusätzliche Server oder Protokolle nicht notwendig. Außerdem entsteht aufgrund des Hashings zwar ein Anstieg der für den Versand einer E-Mail benötigen Prozessorleistung, dieser ist aber im Vergleich zu anderen Verfahren (vgl. Hashcash in Abschnitt 3.8.4 ab Seite 89) sehr gering. DKIM bietet zwar keinen direkt Schutz vor Spam (vgl. ?), es kann jedoch als Einfluss für Reputationssysteme (vgl. Abschnitt 3.6 ab Seite 78) verwendet werden.

Gleichzeitig gibt es bei dem Verfahren jedoch einige bisher ungelöste Probleme. Dazu zählt die Veränderung des E-Mail-Inhalts auf dem Web von Sender zum Empfänger. SMTP-Server dürfen Nachrichten zwischen verschiedenen Character Sets konvertieren. Durch diese Veränderung passt die DKIM-Signature nicht mehr zum E-Mail-Inhalt. Da Botnetze auch Webmail als Quelle für Spam verwenden, kann nicht ausgeschlossen werden, dass trotz gültiger DKIM-Signature eine 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 3.8 Erweiterungen des E-Mail-Verfahrens Seite 85

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-Signaturen zeigen (vgl. ?). Aus diesem Grund wird vorgeschlagen, mindestens 1024-bit Schlüssel zu verwenden. Aufgrund der Tatsache, dass DKIM für die Verifikation der E- Mails den öffentlichen Schlüssel per DNS anfordert, sind sämtliche Schwächen von DNS auch gleichzeitig Schwächen von DKIM. Zusätzlich wird das DNS wird entsprechend stärker belastet.

Exkurs 3.2: Asymmetrische Kryptographie E Kryptographische Methoden unterteilen sich in symmetrische und asym- metrische Verfahren. Die symmetrischen Verfahren verwendeten sowohl zur Ver- als auch zur Entschlüsselung denselben Schlüssel. Im Gegensatz dazu verwenden asymmetrische Verfahren einen Schlüssel zum Verschlüsseln und einen anderen Schlüssel zum Entschlüsseln. Asymmetrische Verfahren werden auch Public-Key-Verfahren genannt, da ein Anwendungsfall dar- in besteht, dass einer der beiden Schlüssel öffentlich (public) zugänglich gemacht werden kann, mit dem eine Nachricht verschlüsselt werden und ausschließlich der Besitzer des anderen (privaten) Schlüssels die Nachricht entschlüsseln kann.

Nach ? existieren vier Hauptfunktionen für asymmetrische Verschlüsse- lungsverfahren:

Schlüsselaustausch Es existieren Protokolle, mit denen ein geheimer Schlüssel über einen unsicheren Kanal verschickt werden kann. Nichtabstreitbarkeit Hiermit kann sichergestellt werden, dass eine Nach- richt von einer Person stammt, die über einen geheimen Schlüssel verfügt. Identifikation Verfahren können die Identifikation von Personen oder Computern sicherstellen. Verschlüsselung Nachrichten können entsprechend verschlüsselt werden.

3.8.2 SPF (Sender Policy Framework) SPF wurde in RFC 4408 (vgl. ?) spezifiziert und durch RFC 6652 (vgl. ?) aktualisiert. RFC 6652 Das System gilt als Alternative zu DKIM (vgl. Abschnitt 3.8.1 ab Seite 82), da es ebenfalls dazu verwendet werden soll, die Absenderadresse zu verifizieren und dafür auf DNS aufsetzt. Im Gegensatz zu DKIM werden allerdings keine kryp- tographischen Methoden verwendet, um den Inhalt einer E-Mail zu verifizieren. DKIM kann daher verifizieren, dass der Inhalt einer E-Mail beim Versand nicht verändert worden ist. Durch SPF kann dagegen der empfangende SMTP-Server überprüfen, ob die IP-Adresse, von der eine eintreffende E-Mail versendet wird, dazu berechtigt ist, für den spezifizierten Absender die E-Mail zu verschicken. Um dies durchführen zu können, wird ein spezieller DNS-Eintrag benötigt. Da SPF bereits vor der Spezifizierung durch RFC 4408 eingesetzt wurde und erst mit RFC 4408 der neue DNS-Eintragstyp SPF eingeführt wurde, wird empfohlen, sowohl den TXT- als auch den SPF-Eintrag mit Daten zu versorgen. Der Aufbau des Seite 86 Studienbrief 3 Anti-Spam-Techniken

TXT- bzw. SPF-Eintrags wird dabei im folgenden Exkurs 3.3 beschrieben. Beispiel 3.4 zeigt einen konkreten DNS-Eintrag.

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 Leerzei- chen 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 ausgewer- tet werden. Die Auswertung aller Direktiven wird von links nach rechts für jede Direktive einzeln abgearbeitet. Dabei können drei Fälle eintreten: 1. Die Direktive passt zur Anfrage, dann wird die Auswertung beendet und der Wert der Bedingung wird zurückgegeben. 2. Die Direktive passt nicht zur Anfrage, dann wird die nächste Direktive abgearbeitet. 3. Die Auswertung wirft eine Ausnahme (engl. Exception), dann wird die Ausarbeitung beendet und der Wert der Ausnahme zurückgege- ben.

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 Nachrichten- versand autorisiert. ~ SoftFail Die Nachricht sollte irgendwo zwischen - und ? behandelt werden. ? Neutral Der Besitzer der Domain kann oder will über solche IP-Adressen keine Aussage treffen.

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

Mechanismus Bedingung für das Eintreffen der Direktive all Trifft 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. 3.8 Erweiterungen des E-Mail-Verfahrens Seite 87

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: y _spf.google.com descriptive text "v=spf1 y include:_netblocks.google.com include:_netblocks6.google.com ?all"

Durch den Exkurs 3.3 wird deutlich, dass die Informationen aus Beispiel 3.4 noch weiter aufgelöst werden müssen, damit sie verwendbar sind. Dies wird in Bei- spiel 3.5 gezeigt.

Beispiel 3.5: SPF-DNS-Einträge: Auflö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 y _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 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all"

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

Der empfangende SMTP-Server kann nun die Direktiven aus der Antwort der 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 an- gepasst werden muss. Auch der SMTP-Server zum Versand von E-Mails bedarf keinen Erweiterungen. Dagegen muss allerdings eine entsprechende Funktionalität im empfangenden SMTP-Server vorhanden sein. Weiterhin müssen die entspre- chenden DNS-Einträge gepflegt werden. SPF kann daher auch nicht vor Spam schützen, da auch Versender von Spam ihre eigenen DNS-Einträge entsprechend pflegen können. Es kann aber vor Phishing helfen, da entschieden werden kann, ob eine IP-Adresse die Berechtigung hatte, mit einem bestimmten Absender eine E-Mail abzuschicken. Seite 88 Studienbrief 3 Anti-Spam-Techniken

3.8.3 Sender ID RFC 4406 RFC 4406 (vgl. ?) beschreibt das experimentelle Protokoll Sender ID, das eine Alternative zu SPF (vgl. vorheriger Abschnitt) ist und auf der Funktionalität von SPF aufbaut. Sender ID wurde bereits von der Spezifizierung in RFC 4406 durch Microsoft und die MARID (MTA Authorization Records In DNS) IETF (Internet Engineering Task Force) Gruppe entwickelt. Jedoch stellte Microsoft eigene Patente nicht für die Verwendung unter bestimmten Open-Source-Lizenzen bereit, weshalb sich MARID von der Entwicklung zurückzog (vgl. ? und ?). Sender ID wird aktuell von Microsoft unter der Bezeichnung Sender ID Framework (SIDF) verwendet und entwickelt.

RFC 4407 Im Gegensatz zu SPF wird unter anderem die Header-Adresse einer E-Mail zur Verifizierung des Absenders herangezogen. Die Eigenschaften, die vom SIDF insgesamt zur Verifizierung des Absenders verwendet werden, sind in RFC 4407 als Purported Responsible Address (PRA) spezifiziert (vgl. ?).

Systematisch entspricht das Sender ID Framework dem Sender Policy Framework, jedoch wird der per DNS vom Versender eingeholte Datensatz angepasst. Die in SPF beginnende Zeichenkette v=sfp1 kann bei SIDF drei unterschiedliche Ausprä- gungen haben:

v=spf2.0/mfrom - Hierbei wird der Sender genauso wie bei SPF verifiziert. v=spf2.0/mfrom,pra - Der Sender wird nach der SPF-Methode sowie anhand der PRA verifiziert. v=spf2.0/pra - Der Sender wird ausschließlich per PRA verifiziert.

Die Funktionsweise wird in Abbildung 3.4 gezeigt.

Abb. 3.4: Funktionsweise von Sender ID aus ?.

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. 4. Da für einige Domains bereits Reputationsinformationen vorliegen, werden diese für die Klassifikation der E-Mail mit berücksichtigt. 5. Basierend auf den erhaltenen und ausgewerteten Informationen wird die E-Mail dann klassifiziert und an den Benutzer zugestellt. 3.8 Erweiterungen des E-Mail-Verfahrens Seite 89

Für weitere Informationen fasst ? die verfügbaren Ressourcen zum Sender ID Framework zusammen.

3.8.4 Hashcash Hashcash ist ein von Adam Back im Jahr 1997 vorgeschlagenes und 2002 in ? Proof-of-Work System spezifiziertes System, das zur Vermeidung von Spam eingesetzt werden kann. Aktuell existiert keine RFC zu Hashcash, jedoch gibt es Implementierungen für verschiedene Anwendungsfälle und den oben genannten technischen Report, der die Funktionalität beschreibt. Hashcash ist ein Proof-of-Work System, bei dem der Versender einer E-Mail nachweist, dass er eine bestimmte Arbeit geleistet hat. Es ist so spezifiziert, dass der Empfänger mit einem sehr geringen Aufwand nachprüfen kann, ob der Sender diese Arbeit wirklich verrichtet hat.

Wie bereits in Studienbrief2 zu Spam-Techniken ab Seite 45 beschrieben, existieren verschiedene Techniken, um Spam zu verbreiten. Alle Techniken zielen darauf ab, möglich viele Spam-Nachrichten in die Postfächer der Nutzer zu bringen. Da gleichzeitig viele Methoden darauf abzielen, möglichst viel Spam auszusortieren, versuchen Spammer so viele Spam-Nachrichten wie nur möglich zu verschicken. Der Vorteil der E-Mail liegt ganz klar darin, dass die mit dem Versand einer E-Mail verbundenen Kosten sehr gering sind. Daher ist meist nur die Internetanbindung der Flaschenhals, um noch mehr Nachrichten zu verschicken. Hashcash setzt genau an dieser Problematik an und verlagert den Flaschenhals von der Bandbreite des Internetanschlusses zum Prozessor des versendenden Computers. Der E-Mail- Client des Versenders führt dabei folgende Schritte durch:

1. An den Header der E-Mail wird eine Zeile angehängt. Diese Zeile beginnt mit H-Hashcash: und enthält die E-Mail-Adresse des Empfängers, das Da- tum sowie eine Zufallszahl. 2. Für die so erzeugte Zeile wird der SHA-1 Hash (vgl. ?, ? und ?) berechnet. RFC 6234 3. Falls die ersten 20 Bits des resultierenden Hashes jeweils den Wert 0 haben, kann die E-Mail so verschickt werden. Ist dies nicht der Fall, so muss der Wert der Zufallszahl inkrementiert werden und es wird wieder Schritt 2 durchgeführt.

Nach durchschnittlich 220 ≈ 1 Million Iterationen wurde dann eine Header-Zeile erzeugt, die den gewünschten Kriterien entspricht.

Der Empfänger muss nun die folgende Eigenschaften überprüfen, um die Validität der E-Mail zu verifizieren.

1. Haben die ersten 20 Stellen des SHA-1 Hashes der Headerzeile H-Hashcash: den Wert Null? 2. Ist die Differenz aus dem in der Headerzeile angegebenen Datum und dem Datum der Überprüfung kleiner als 2 Tage? 3. Stimmt der in der Headerzeile H-Hashcash: angegebene Empfänger mit dem echten Empfänger überein?

Waren alle vorherigen Überprüfungen erfolgreich, so wird die Headerzeile auf der Seite des Empfängers in eine Datenbank abgelegt. War die Headerzeile schon vorher in der Datenbank, so kann es sich bei der E-Mail um eine Spam-Nachricht handeln. Andernfalls handelt es sich mit sehr großer Wahrscheinlichkeit nicht um eine Spam-Nachricht. Seite 90 Studienbrief 3 Anti-Spam-Techniken

Insgesamt gesehen bietet Hashcash die Vorteile, dass diese Methode nur innerhalb der E-Mail-Clients implementiert werden muss. Für die SMTP-Server wird keine Anpassung benötigt, obwohl eine Filterung auf dem SMTP-Server möglich wäre. Hier könnt der Server zumindest überprüfen, ob die ersten 20 Stellen des SHA-1 Hashes jeweils den Wert 0 haben. Ist dies nicht der Fall, so könnte die E-Mail schon vom SMTP-Server gefiltert worden sein. Ein weiterer Vorteil besteht darin, dass im Gegensatz zu anderen Systemen kein echtes Geld verwendet wird.

Es existieren jedoch auch Nachteile bei Hashcash. Computer mit langsamen Pro- zessoren oder immer beliebter werdende Smartphones oder Tablett PCs, die über langsame Hardware verfügen, benötigen zum Versand von E-Mails viel Rechen- leistung. 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 aufbrin- gen als ohne Hashcash. Der wohl schwierigste Nachteil besteht darin, dass die Hauptquelle von Spam, die Botnetze, über sehr viel Rechenleistung verfügen und somit immer noch sehr viele Spam-Nachrichten verschicken können, auch wenn die Menge um viele Faktoren sinkt.

3.8.5 Receiver-Driven SMTP Receiver-Driven SMTP ist eine Erweiterung von SMTP, die zwischen 2005 und 2006 von Forschern der Florida State University und der University of Hawaii entwickelt wurde (vgl. ?, ?, ? und ?). In den Entwürfen beschreiben die Autoren das Differentiated Mail Transfer Protocol (DMTP) als einfache Erweiterung zum SMTP, durch das der Empfänger mehr Möglichkeiten hat, den E-Mail-Versandprozess zu beeinflussen. Konkret soll der Empfänger den Sender in die Kategorien allowed, denied und unclassified klassifizieren können, um den Versand jeder Kategorie einzeln bearbeiten zu können. Weiterhin sollen DMTP-Empfänger in der Lage sein, für den Fall, dass ein Sender als unclassified gilt, Nachrichten auf dem Server des Senders zu speichern, um diese erst bei Bedarf abzuholen. Die Klassifikation geschieht dabei nur aufgrund der IP-Adressen. Es werden zwei Listen von IP- Adressen gepflegt, zum einen die trusted MTAs, deren E-Mails direkt akzeptiert werden. Zum anderen die black-listed MTAs, deren E-Mails direkt blockiert und verworfen werden können. Alle IP-Adressen, die in keiner von beiden Listen auftreten, gelten als unklassifizierte oder untrusted MTAs. Für diese Mail Transfer Agents gilt die im obigen Text beschriebene spezielle Nachrichtenbehandlung.

Der Ansatz hat den Status eines Entwurfs jedoch nie verlassen und wurde ab 2006 nicht weiter verfolgt.

3.8.6 Kontrollaufgaben In diesem Abschnitt befinden sich verschiedene Kontrollaufgaben, welche die Inhalte der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffes beitragen sollen.

Kontrollaufgabe 3.11: DKIM I K Wozu wird DKIM verwendet und welches Problem kann das Verfahren nicht lösen? 3.9 Echtzeit URL Filterung Seite 91

Kontrollaufgabe 3.12: DKIM II K Nennen Sie jeweils zwei Vor- und zwei Nachteile von DKIM.

Kontrollaufgabe 3.13: SPF I K Was ist SPF und wie unterscheidet es sich gegenüber DKIM?

Kontrollaufgabe 3.14: SPF II K Was sind Direktiven bzw. Bedingungen und wozu werden sie genutzt?

Kontrollaufgabe 3.15: SPF III K Können Sie sich vorstellen, wozu es eine ?-Bedingung (Neutral) gibt?

Kontrollaufgabe 3.16: Sender ID K Was unterscheidet Sender ID von SPF?

Kontrollaufgabe 3.17: Hashcash I K Welche Eigenschaften zeichnen Hashcash aus?

Kontrollaufgabe 3.18: Hashcash II K Angenommen, der Empfänger erhält eine E-Mail, bei der sich die Hea- derzeile H-Hashcash: bereits in seiner Datenbank befindet. Welche beiden Szenarien können hier eingetroffen sein?

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

3.9 Echtzeit URL Filterung Die zu Werbezwecken versendeten Spam Nachrichten enthalten oft URLs (vgl. ?), RFC 1738 die auf Phishing Seiten führen oder auf Malware zielen. Genauso werden diese URLs aber auch durch Web Services in Form von sozialen Netzwerken von Twitter1 oder Facebook2 verbreitet. Um dieses Problem zu behandeln, haben sich ? mit der Implementierung und Evaluierung eines Echtzeit-Spam-Filterdienstes für URLs mit dem Namen Monarch beschäftigt. Abbildung 3.5 zeigt dazu das generelle Vorgehen des Dienstes.

1 https://twitter.com/, aufgerufen am 04.11.2013 2 https://www.facebook.com/, aufgerufen am 04.11.2013 Seite 92 Studienbrief 3 Anti-Spam-Techniken

Abb. 3.5: Die ge- nerelle Funktions- weise des Echtzeit- Spam-Filterdienstes Monarch aus ?.

Die von Web-Services verbreiteten URLs könnten in einem ersten Schritt an Mon- arch verschickt werden. Monarch kann dann jede einzelne URL untersuchen und in einem zweiten Schritt eine Entscheidung an den Web-Service zurückschicken, ob die verlinkten Seite bspw. für Phishing verantwortlich ist, Malware verbreitet oder auch als gutartige Seite einstuft werden kann.

Abb. 3.6: Das Fluss- diagramm von Monarch aus ?.

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

1. Zuerst findet eine Aggregation zwischen einem E-Mail-Strom und den Tweets des Web-Services Twitter statt. Bei den verwendeten E-Mails handelt es sich um Nachrichten, die durch Spam-Traps empfangen werden und daher mit sehr großer Wahrscheinlichkeit als Spam klassifiziert werden können. 2. Danach findet eine Sammlung der Merkmale statt. Dazu werden die Seiten, auf welche die URLs zeigen, automatisch durch eine angepasste Version von Firefox besucht und das Verhalten sowie der Inhalt der Seiten werden gespeichert. Zum Verhalten zählen bspw. JavaScript-Aktivitäten. Auch die Infrastruktur, die zum Hosting der Seite verwendet wird, wird in einer Datenbank abgelegt. 3. Dann werden die Merkmale der einzelnen Seiten extrahiert. Dazu werden eingebettete URLs in Binärdaten umgewandelt und HTML Inhalte als Listen von Wörtern abgelegt. Alle genannten Daten werden in Vektoren gespeichert, die im nächsten Schritt weiterverarbeitet werden können. 4. Der letzte Schritt ist dann die Klassifikation. Ein Offline Training stellt sicher, dass die Reaktionszeit des Systems möglichst gering bleibt, während ein Echtzeit-Klassifikator schnelle Ergebnisse liefert.

In einer Evaluation zeigen die Autoren, dass das System mit einer Genauigkeit von 90,78 % arbeitet und als Median 5,54 Sekunden für eine Klassifikation benötigt. Diese Ergebnisse wurden erreicht, indem der Klassifikator mit 1,2 Millionen Spam- Nachrichten, 567 000 als schadhaft gekennzeichneten Twitter-URLs und 9 Millionen 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.10 Netzwerk-basiertes Clustern Seite 93

3.10 Netzwerk-basiertes Clustern IP-basiertes Blacklisting (vgl. Abschnitt 3.5.1 ab Seite 72) ist eine bekannte und bewährte Methode, um Spam zu filtern. Das Problem bei dieser Methode besteht aber darin, dass eine starke Fluktuation innerhalb der Liste durch dynamische IP-Adressen entsteht. Daher wurde vorgeschlagen, nicht nur IP-Adressen sondern Adress-Blöcke bzw. Cluster zu verwenden. In ? 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 zu senken. • Ein von den Autoren erarbeitetes System, das BGP-Präfixe und DNS- Informationen verbindet, kann mehr als 50 % mehr Spam erkennen als vorherige Ansätze.

Der von den Autoren vorgeschlagene Ansatz kann dabei problemlos in ein System wie SpamAssassin (vgl. Abschnitt 3.14 ab Seite 100) eingebaut werden und hilft somit bei einer besseren Klassifizierung von Spam.

3.11 Erkennung von Botnetzen Die Erkennung von Botnetzen ist ein wichtiges Mittel ist im Kampf gegen Spam, da Botnetze als Hauptverursacher für ca. 85% der Spam-Mails verantwortlich sind (vgl. ?). Daher werden in diesem Abschnitt einige Arbeiten betrachtet, die sich mit der Erkennung von Botnetzen beschäftigen.

BotMagnifier

In ? entwickeln die Autoren eine neue Technik, um die Identifikation und Ver- folgung von Bots aus bestimmten Botnetzen zu erleichtern. Eine bewährte Me- thode, um Bots zu identifizieren, besteht darin, Spam-Traps einzusetzen und die IP-Adressen der Absender zu verwenden. Dieses Vorgehen birgt jedoch zwei Ge- fahren: Zum einen gehört nur eine kleine Menge der so erkannten IP-Adressen zu einem bestimmten Botnetz. Viel eher werden viele unterschiedliche Botnetze Spam an einzelne Spam-Traps versenden. Zum anderen verschicken Botnetze oft nur Nachrichten an bestimmte Nutzer aus einer vorher definierten Region, damit der Nutzer bspw. auch die Sprache, die in einer Spam-Nachricht verwendet wird, versteht.

Beim vorgeschlagenen Ansatz gehen die Autoren davon aus, dass Bots, die zum gleichen Botnetz gehören, auch über den selben Quellcode verfügen und die selben Command and Control Infrastruktur verwenden. Daher haben solche Bots ein ähnliches Verhalten und können von Bots aus anderen Botnetzen abgegrenzt werden, die für ihren Spamversand andere Parameter verwenden. Um Bots aus einem Botnetz zu finden, werden zwei Listen benötigt. Dies ist zum einen eine initiale Liste von Spambots, die über die klassischen Spam-Traps kommen kann. Zum anderen werden Protokolle von empfangenden SMTP-Servern benötigt.

• Im ersten Schritt wird dann die Liste der Spambots mit den Protokollen verglichen. Hierbei werden Überschneidungen zwischen IP-Adressen der Spambots und der Protokolle gesucht. Diese Überschneidungen werden dann analysiert und daraus Profile erstellt. Seite 94 Studienbrief 3 Anti-Spam-Techniken

• Im zweiten Schritt wird dann in den Protokollen nach Einträgen gesucht, die zu den erstellten Profilen passen. Bei diesen Einträgen kann davon ausgegangen werden, dass es sich auch um Spambots handelt. Daher werden die IP-Adressen dieser Einträge als mögliche Treffer markiert. • Im dritten und letzten Schritt werden dann Heuristiken angewendet, die zum einen die Spam Kampagnen bestimmten Botnetzen zuordnen und zum anderen die Anzahl der fehlerhaften Treffer (Falsch-Positive) reduzieren. Das so implementierte Tool wird von den Autoren BotMagnifier genannt, da es mit Hilfe von wenigen bekannten Spambots eine Liste wie mit einer Lupe nach ähnlichen Eigenschaften durchsucht, um dort weitere Spambots zu finden.

Die Ergebnisse, die so durch BotMagnifier gefunden werden, können daraufhin bspw. beim Blacklisting (vgl. Abschnitt 3.5.1 ab Seite 72) verwendet werden, um bessere Ergebnisse bei der Klassifikation vom Spam zu erzielen.

BotSniffer

Einen alternativen Ansatz zu BotMagnifier liefern ? mit BotSniffer. BotSniffer verwendet eine Netzwerk-basierte Anomalieerkennung, um die Command and Control-Kanäle von Botnetzen in lokalen Netzwerken zu identifizieren. Dazu wer- den jedoch nicht, wie beim vorherigen Ansatz, Informationen über vorhandene Bots benötigt. Der Netzwerkverkehr von Botnetzen ist schwer zu erkennen, da oft- mals gebräuchliche Protokolle wie IRC oder HTTP verwendet werden. Der Ansatz der Autoren basiert aber auf der Annahme, dass das Verhalten von Bots räumli- chen und zeitlichen Korrelationen unterliegt und somit Ähnlichkeiten aufweist. Diese Annahme wird in Abbildung 3.7 visualisiert. Im linken Teil der Abbildung werden Antwortnachrichten in der Zeitebene verglichen. Hier fällt auf, dass die Antworten sich immer in einem zeitlichen Rahmen befinden, die als mögliches Muster gewertet werden können. Der rechte Teil zeigt verschiedene Botaktivitäten, wie das Scannen des Netzwerks, den Versand von Spam oder das Herunterladen einer Datei. Auch hier sind Ähnlichkeiten im zeitlichen Verhalten erkennbar.

Abb. 3.7: Raum- und zeitliche Korrelation von Bot-Antworten aus ?. Links: einzelne Antwort- nachrichten, rechts: ver- schiedene Aktivitäten.

BotSniffer erkennt dieses Verhalten, indem statistische Algorithmen zur Gruppie- rung der Muster verwendet werden. Abbildung 3.8 visualisiert dazu eine Übersicht über die Architektur des Systems. Hierbei erhält BotSniffer als Eingabe den lokalen Netzwerkverkehr und führt zuerst ein Vorverarbeitung der Daten durch. Dabei werden nicht relevante Informationen wie ICMP- und UDP-Pakete entfernt. Die Autoren gehen davon aus, dass innerhalb dieser Pakete bisher keine Command and Controll-Daten ausgetauscht werden, weshalb sie für die Erkennung von Botnetzen zum Stand der Veröffentlichung nicht zur Verbesserung der Ergebnisse beitrugen. Weiterhin werden Verbindungen zur normalen Servern wie Google oder Yahoo durch ein statisches Whitelisting entfernt. Daraufhin werden zwei Module auf die Daten angewendet. Zum einen findet eine Erkennung von Aktivitäten und 3.12 Botnetz-Übernahme Seite 95

Antworten statt. Diese sucht das Modul nach IRC-PRIVMSG-Nachrichten, die für die Kommunikation verantwortlich gemacht werden, sowie nach DNS-MX-Anfragen und SMTP-Verbindungen, die zum Versand von Spam benötigt werden. Zum anderen wird ein Modul zur Protokollzuordnung ausgeführt.

Abb. 3.8: Architektur- übersicht von BotSniffer aus ?.

Die Autoren versuchen IRC- und HTTP-Verbindungen in den Daten zu finden, RFC 1459, RFC 1945 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-Sitzungen durch drei Nachrichten (PASS, NICK und USER) bestimmt ist, die in RFC 1459 (vgl. ?) definiert sind. HTTP-Datenströme können ähnlich leicht erkannt werden. Hier müssen Anfragen immer mit einem der drei Schlüsselwörter GET, POST oder HEAD beginnen, wie RFC 1945 beschreibt (vgl. ?). Beide Module liefern Daten an eine Datenbank, die ein Aktivitätsprotokoll beinhaltet. Das sind auf der einen Seite Ergebnisse zu schadhaften Aktivitäten aus der Erkennung von Aktivitäten und Antworten. Auf der anderen Seite werden erkannte HTTP- und IRC-Verbindungen aus dem Modul zur Protokollzuordnung eingefügt. Dasselbe Modul stellt auch eine Eingabe für das Modul zur Erkennung von IRC-Nachrichten und Antworten dar. Dazu werden die IRC Datenströme weitergeleitet und auf ein- und ausge- henden IRC PRIVMSG Nachrichten hin analysiert. Diese Modul speichert ebenfalls Informationen in der Datenbank zum Aktivitäten protokollieren ab, generiert aber auch direkt Berichte. Berichte werden auch durch ein Korrelationsmodul erstellt, das auf die Einträge aus der Datenbank zugreift.

Mithilfe dieser Mechanismen können im Datenverkehr die Command and Controll- Nachrichten von Botsnetzen gefunden und die Botnetze somit ausfindig gemacht werden.

3.12 Botnetz-Übernahme Botnetze sind aktuell für den Großteil alle versendeten Spam-Nachrichten verant- wortlich. Aus diesem Grund sind Analysen von Botnetzen hilfreich, um deren Vorgehensweisen zu verstehen und um daraus folgend den Versand von Spam einzudämmen. In ? haben die Autoren das Botnetz Torpig (auch unter den Namen Sinowal und Anserin bekannt) untersucht. Torpig sammelt sensible Informationen der befallenen Computer wie Konto- und Kreditkarteninformationen. Es basiert Seite 96 Studienbrief 3 Anti-Spam-Techniken

auf dem Rootkit Mebroot3, der den Master Boot Record erweitert und somit bei jedem Systemstart noch vor dem Betriebssystem ausgeführt wird.

Generell existieren zwei Möglichkeiten, um ein Botnetz zu analysieren. Zum einen kann eine passive Analyse stattfinden, bei der der Datenverkehr beobachtet wird. Zum anderen kann eine Infiltration des Botnetzes durchgeführt werden, indem ein Bot in einer kontrollierten Umgebung ausgeführt wird und dabei der Netzwerkver- kehr beobachtet wird. Dieses Vorgehen ist dann möglich, wenn die Command and Control-Struktur des Botnetzes per IRC oder HTTP erfolgt. Im besten Fall können so die internen Abläufe beobachtet werden, um Schwachstellen des Botnetzes zu finden. Beide Möglichkeiten sind jedoch bei aktuellen Botnetzen schwierig zu realisieren wenn nicht per IRC oder HTTP kommuniziert wird oder eine dezentrale Struktur (Peer-To-Peer) verwendet wird. Eine durchaus bessere Alternative bietet die von den Autoren durchgeführte Entführung des kompletten Botnetzes durch die Übernahme eines Command and Control Servers. Dies ist zum einen durch die physikalische Übername des Command and Control Servers möglich, wozu aber bekannt sein muss, wo der Server gehostet wird, was bei dezentralen Lösungen sehr schwierig ist, oder die Ausnutzung der Domain-Flux-Technik, die von Torpig eingesetzt wird.

Domain Flux Domain Flux ist eine Technik, bei der jeder einzelne Bot unabhängig von den anderen Bots periodisch eine Liste von Domains erstellt, zu denen er einen Verbin- dungsaufbau versucht. Der erste Server, der bei einem Verbindungsaufbauversuch eine valide Antwort zurückmeldet, wird als echter Command and Control Server betrachtet. Der Bot verbindet sich daraufhin mit dem Server und wartet auf Befehle. Durch Reverse Engineering (vgl. Exkurs 3.4 auf Seite 97) des Domain Erstellungs Algorithmus konnten im Vorhinein bereits die entsprechenden Domains registriert werden, wodurch der Botmaster dazu keine Möglichkeit mehr hat. Die Bots verbin- deten sich dann mit einem Server, der unter der Kontrolle der Autoren stand. Die Autoren erhielten somit Daten von mehr als 180.000 infizierten Computern, die sie daraufhin analysieren könnten. Unter anderem fanden sie bei ihren Analysen heraus, wie Torpig genau funktioniert. Dies ist in Abbildung 3.9 dargestellt.

Abb. 3.9: Die Torpig-Netzwerk- Infrastruktur aus ?.

Dabei werden die Computer der Opfer durch Drive-By-Downloads (vgl. ?) infiziert. Hierzu wird der HTML-Quellcode von verwundbaren aber legitimen Webseiten (1) modifiziert, damit das Opfer speziellen JavaScript Code (2) aufruft. Der JavaScript Code wiederum ruft dann Code von einem Drive-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 her- untergeladen 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

3 Eine genaue Analyse von Mebroot kann in ? (abgerufen am 18.11.2013) gefunden werden. 3.12 Botnetz-Übernahme Seite 97

Phishing-Angriff auf dem Host-Computer aus, sofern diese bspw. entsprechende Onlinebanking-Seiten besucht (7).

Die Autoren fanden heraus, dass bei Torpig jeder Bot eine einzigartige ID erzeugt, die bei jeder Kommunikation mit übertragen wird. Anhand der Zählung der IDs konnte herausgefunden werden, dass das Botnetz ca. 182 800 Computer zu diesem Zeitpunkt enthielt.

Die Autoren lernten bei ihrer Analyse drei wesentliche Dinge:

1. Die Größe eines Botnetzes durch Zählen der einzigartigen IP-Adressen führt zu falschen Zahlen. Durch Zwangstrennungen erhalten viele Bots oft eine neue IP-Adresse und werden somit mehrfach gezählt. 2. Die Opfer von Botnetzen sind oft schlecht gewartete Computer, auf denen leicht zu erratende Passwörter zum Zugriffsschutz für sensible Webseiten verwendet werden. 3. Die Kommunikation mit Registraren, Webhostern und Anlaufstellen von Opfern ist ein sehr aufwendiger Prozess.

Durch die Analyse des Botnetzes können so Strategien entwickelt werden, die zum Abschalten des Botnetzes führen und somit auch den Versand von Spam beeinflussen.

Exkurs 3.4: Reverse Engineering 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 Namen für Variablen oder Funktionen bei der Erstellung der Software nicht befolgt werden. Generell ist eine Quellcode-Analyse jedoch durchführbar, auch wenn je nach Umfang des Quellcodes viel Arbeitszeit investiert werden muss. Steht ein Softwareprodukt nicht im Quellcode vor, was der Normalfall ist, so muss das vorhandene Programm im binären Format untersucht wer- den. Hierbei handelt es sich um Maschinenbefehle, die nicht dazu gedacht sind, von Menschen interpretiert zu werden. Zur Analyse von Binärcode existieren drei unterschiedliche Techniken: 1. Analyse durch die Beobachtung des Austausches von Informationen. Diese Technik wird häufig bei der Analyse von Protokollen eingesetzt. 2. Mithilfe eines Disassembler wird versucht, aus dem Maschinencode ein Programmcode in Assemblersprache zu erzeugen. Assemblerspra- che 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 wie- der 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? Seite 98 Studienbrief 3 Anti-Spam-Techniken

3.13 Botnet Judo: Automatische Generierung von Spam Signaturen Einen weiteren Ansatz zur Bekämpfung vom Spam zeigen ?. Auch in dieser Arbeit werden Botnetze als Hauptquelle von Spam ausgemacht. Grundsätzlich besteht das Ziel des Systems darin, aus einer Eingabe von E-Mails eine Signatur zu erstellen, mithilfe derer alle E-Mails gefiltert werden können, die durch dasselbe Template erzeugt wurden. Die Grundvoraussetzungen bestehen dabei allerdings darin, dass die E-Mails zum einen durch ein Template generiert wurden und auch darin, dass nicht zu viele unterschiedliche Templates zur Generierung verwendet wurden. Das Spam-Nachrichten, die aus Botnetzen stammen, durch Templates erzeugt werden, wurde bereits in ? und ? gezeigt. Grund für die Verwendung von Templates liegt in der erschwerten Filterung der Nachrichten. Ist bekannt, dass eine bestimmte E-Mail-Spam darstellt, so kann bei Spam, der aus Templates erstellt wurde, die Gleichheit nicht direkt nachgewiesen werden, da jede Spam-Nachricht aus dem Template einen leicht abgewandelten Inhalt hat. Weiterhin wird in diesem Ansatz der Spamversand als Blackbox betrachtet. Es ist nicht wichtig, wie die Nachricht vom Sender zum Empfänger gelangt, sondern es kommt ausschließlich auf den Inhalt der Nachricht an, dabei basieren die erzeugten Signaturen jedoch nicht nur auf dem Betreff oder den enthaltenen URLs, wie es bei anderen Ansätzen der Fall ist, sondern verwenden die gesamte E-Mail.

Der grundsätzliche Ablauf, den die Autoren verwenden, wird in Abbildung 3.10 gezeigt.

Abb. 3.10: Der Sys- temüberblick aus ?.

Dabei ist zu erkennen, dass in einem ersten Schritt Spam gesammelt wird. Dies kann theoretisch durch Spam-Traps erfolgen. Innerhalb dieser Arbeit wurden allerdings Bots in einer kontrollierten Umgebung ausgeführt und die versendeten E-Mails aus dem Netzwerkverkehr verwendet. Der zweite Schritt ist die Erzeugung von Signaturen durch den Signatur-Generator, der als wichtigster Bestandteil der Arbeit angesehen werden kann. Darauf folgend wird im dritten Schritt eine Menge von bereist existierenden Signaturen aktualisiert und erweitert und anschließend im vierten Schritt an einen Spam-Filter verteilt. Die Signaturen bestehen dabei aus regulären Ausdrücken, die fast in Echtzeit erzeugt werden können und sich somit auch praktisch in realen Systemen einsetzen lassen.

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

Anker, Makro Der Algorithmus besteht aus zwei Schritten. Im ersten Schritt wird versucht, alle Zeichenketten zu erkennen, die in jeder E-Mail vorhanden sind. Diese invarianten Zeichenketten werden als Anker bezeichnet. Im vorliegenden Beispiel werden Best prices!, http:// und \.com 60% off als Anker identifiziert. Dafür werden die längsten geordneten Mengen von Zeichenketten gesucht, die in allen E-Mails 3.13 Botnet Judo: Automatische Generierung von Spam Signaturen Seite 99

Abb. 3.11: Eine Beispiel- instanz des Algorithmus zum Erstellen einer aus ?.

vorkommen und mindestens die Länge q haben. Wobei q ein zu konfigurierender Parameter ist und einen wichtigen Einfluss auf die Qualität der resultierenden Signatur hat. Die Autoren haben in verschiedenen Versuchen herausgefunden, dass sich q = 6 eignet, um guter Ergebnisse zu erreichen. Der zweite Schritt versucht die variable Zeichenfolge zwischen zwei Ankern durch ein Makro zu definieren. Dabei kann es sich um ein Wörterbuch-Makro, ein Zufalls-Makro oder eine Kombination mehrerer Makros handeln. Wörterbuch-Makros haben die Eigenschaft, dass sie aus einer festgelegten Menge von Wörtern, also einem Wörterbuch, stammen und eines der Elemente zufällig ausgewählt wird. In dem vorliegenden Beispiel beschreiben chanel, gucci und prada ein Wörterbuch und fenallies und nuserro ein zweites Wörterbuch. Theoretisch kann jedes Makro durch ein Wörterbuch- Makro beschrieben werden, jedoch muss der Algorithmus dazu erst alle möglichen Einträge des Wörterbuchs gesehen haben. Kann eine Zeichenkette zwischen zwei Ankern nicht durch ein Wörterbuch darstellt werden, weil immer wieder neue mögliche Einträge auftauchen, so wird davon ausgegangen, dass es sich um ein Zufalls-Makro handelt.

Die so erzeugten Signaturen müssen dann den Datenbestand aller Signaturen Trainings-Puffer aktualisieren. Um dies zu tun, gibt es in den vorgestellten Ansatz eine spezieller Funktionalität, den Training Puffer. Für jede neu eintreffende Spam-Nachricht wird zuerst überprüft, ob es bereits eine Signatur gibt, die dieser Nachricht erkennt. Trifft dies zu, so kann die Nachricht verworfen werden, da sie keinen Mehrwert hat. Wird die Nachricht nicht erkannt, so wird sie dem Training-Puffer hinzuge- fügt und es wird so lange gewartet, bis der Puffer voll ist. Die Größe des Puffers wird durch den Parameter k bestimmt. Die richtige Wahl von k ist von essentieller Bedeutung: ist k zu klein, so können Wörterbücher entweder gar nicht oder nur unvollständig erkannt werden und der Algorithmus würde dementsprechend Zufalls-Makros anstelle von Wörterbuch-Makros wählen. Wird ein großes k ge- wä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 Tem- plates 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 Si- Second-Chance- gnatur bereits unter Beachtung nur weniger E-Mails erzeugt werden, auch wenn Algorithmus, Pre- mehr Nachrichten benötigt werden würden, um ein vollständiges Wörterbuch zu Clustering, Skelett- erhalten. Daher können bereits erzeugte Signaturen nachträglich erweitert wer- Signatur den, sofern eine neue Nachricht zwar nicht zu den erzeugten Signaturen passt, Seite 100 Studienbrief 3 Anti-Spam-Techniken

jedoch unter Vernachlässigung der Makros von einer Signatur erkannt wird. Als zweiter Mechanismus wird ein Pre-Clustering verwendet. Im Gegensatz zum Second Chance Mechanismus soll das Pre-Clustering gegen einen zu großen Trainings-Puffer helfen, da gerade bei einem großen Trainings-Puffer die Gefahr be- steht, dass Nachrichten aus unterschiedlichen Templates vermischt werden. Beim Pre-Clustering werden unklassifizierte Nachrichten mit sogenannten Skelett- Signaturen gruppiert. Dabei ist eine Skelett-Signatur ähnlich zu einer reinen 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äh- rend der Auswertung ein gut funktionierender Wert gefunden. Dabei funktioniert das Pre-Clustering, indem jeder Skelett-Signatur ein Trainings-Puffer zugewie- sen 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. So muss nur klargestellt wer- den, dass mindestens die ersten 10 E-Mails von einem neuen Template unvermischt mit anderen Templates eintreffen.

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

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 Aktualisie- rung der Signaturen wichtig in diesem Zusammenhang?

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

3.14 SpamAssassin SpamAssassin ist ein Software-Produkt, das zur Erkennung von Spam eingesetzt wird. Es handelt sich dabei um ein Open Source Projekt, das unter der Apache 3.15 Zusammenfassung Seite 101

License 2.04 steht und von der Apache Software Foundation5 entwickelt wird. Der Quellcode von SpamAssassin basiert auf der Programmiersprache Perl6 und kann von jedem Nutzer unter Beachtung der Lizenzbedingungen verändert und wei- terentwickelt werden. SpamAssassin vereint viele einzelne Module, die teilweise sequentiell, teilweise parallel E-Mails analysieren. Dabei wird einer E-Mail von jedem Modul eine Punktezahl zugeordnet, die Auskunft darüber geben soll, ob es sich bei der E-Mail um Spam oder Ham handelt. Ein Modul kann einer Nachricht sowohl einen negativen als auch einen positiven Punktewert zuweisen, wobei ne- gative Punktewerte die Nachricht als Ham klassifizieren und positive Punktewerte Spam anzeigen. Die Punkte der einzelnen Module werden aufaddiert und gelten dann als Klassifikation der Nachricht.

SpamAssassin vereint viele in diesem Studienbrief beschriebene Techniken. So wird bspw. ein DNS-basiertes Black- und Whitelisting eingesetzt (vgl. Abschnitt 3.5 ab Seite 89). Mithilfe von Hashcash (vgl. Abschnitt 3.8.4 ab Seite 89) kann verifiziert werden, ob der Sender Arbeit verrichten musste, bevor er die E-Mail versenden konnte. Weiterhin werden die SPF-Einträge (vgl. Abschnitt 3.8.2) und die DKIM Signaturen (vgl. Abschnitt 3.8.1 ab Seite 82) ausgewertet. Die Software verfügt weiterhin über einen eigenen lernfähigen Bayes-Filter (vgl. Abschnitt 3.4 ab Seite 69) und verwendet dazu eine Menge von Regeln zur Klassifikation. Diese Regeln können wiederum in einen deterministischen endlichen Automaten transformiert werden, um eine schnellere Verarbeitung zu ermöglichen.

Insgesamt kann SpamAssassin in viele vorhandene SMTP-Server eingebaut wer- den.

3.15 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 (Blacklisting) und Ham direkt an den Empfänger weitergeleitet werden kann (Whitelisting). Dann wurden Verfahren besprochen, die auf der Reputation des Sender basieren oder den Sender dazu auffordern eine Aufgabe zu lösen, bevor die versandte Nach- richt an den Empfänger zugestellt wird. Erweiterungen des E-Mail-Verfahrens zeigten dann unterschiedliche Ansätze, die zwar auf der einen Seite Verbesserun- gen bei der Spam-Abwehr bewirken, auf der anderen Seite jedoch auch das System aufwendiger zu warten und zu benutzen machen. Nachdem eine Möglichkeit zur Echtzeit-Filterung von URLs beschrieben wurde und auf Netzwerk-basierte Cluster eingegangen wurde, wurden Botnetze, die aktuell für die meisten Spam Nachrichten verantwortlich sind, behandelt. Dabei wurde zum einen auf die Erken- nung 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 Software-Produkt kurz vorgestellt, das weit verbreitet ist und eine Vielzahl an hier behandelten Techniken verwendet.

4 http://www.apache.org/licenses/LICENSE-2.0.html, abgerufen am 26.11.2014 5 http://www.apache.org/, abgerufen am 27.11.2013 6 http://www.perl.org Seite 102 Studienbrief 3 Anti-Spam-Techniken

3.16 Übungen

Übung 3.1: Bayes-Theorem I Ü Sie haben 12.004 E-Mails als Spam klassifiziert, von denen 3.182 die Zei- chenkette online pharmacy enthalten. Weiterhin haben Sie 1.045 E-Mails als Ham klassifiziert, von denen 3 die Zeichenkette online pharmacy enthalten. Berechnen Sie die bedingte Wahrscheinlichkeit dafür, dass eine E-Mail Spam ist, wenn sie die Zeichenkette online pharmacy enthält.

Übung 3.2: Bayes-Theorem II Ü Stellen Sie sich vor, dass die Spam-Wahrscheinlichkeit für eine bestimmte Kombination von Begriffen nur bei 70 % liegt. Wie kann mit einem solchen Wert umgegangen werden, um ihn sinnvoll zu nutzen?

Übung 3.3: Bayes-Theorem III Ü Betrachten Sie folgende Wortverteilungen für Spam und Ham:

Wort today shipping available medications here Spam 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 mithilfe des naïven Bayes-Filters jeweils die Spam-Wahrscheinlichkeiten für E-Mails, welche die folgenden Begriffe enthalten:

1. today, available und here. 2. shipping 3. today, shipping, available, medications und here

Übung 3.4: Mailfilter Ü Beschreiben Sie, welche Arten es von Mailfiltern gibt und aus welchem Grund diese nicht das gesamte Aufkommen an Spam beseitigen können.

Übung 3.5: Blacklisting I Ü Finden Sie heraus, welche Anbieter es für Blacklisting gibt. Wie finanzieren sich diese Anbieter? Wie werden die zur Verfügung gestellten Blacklists aktualisiert? 3.16 Übungen Seite 103

Übung 3.6: Blacklisting II Ü Stellen Sie fest, mit welcher zweiten Eigenschaft in ? das Blacklisting verbes- sert werden soll.

Übung 3.7: Graylisting Ü In Abschnitt 3.5.3 auf Seite 76 wurde festgestellt, dass Graylisting eigentlich nicht kompatibel zur RFC 2821 (vgl. ?) ist. Ist es denn zu der aktuelleren Spezifizierung von SMTP, der RFC 5321 (vgl. ?) kompatibel?

Übung 3.8: DKIM-Signature Ü Betrachten Sie RFC 6376 (vgl. ? und finden Sie heraus, was eine Kanoni- sierungsmethode (engl. Canonicalization Algorithm) ist und aus welchem Grund DKIM eine solche Funktionalität benötigt.

Übung 3.9: SPF I Ü Finden Sie heraus, aus welchem Grund der DNS-Eintrag, der für SPF ver- wendet wird, maximal 450 Zeichen lang sein soll. Hilfreich hierfür könnte RFC 4408 (vgl. ?) 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 87 für IPv4 und IPv6 aufteilt?

Übung 3.11: SPF III Ü Aus welchem Grund existiert die Bedingung SoftFail für SPF-DNS- Direktiven? Suchen Sie ggf. in RFC 4408 (vgl. ?) 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. ?) 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. Seite 104 Studienbrief 3 Anti-Spam-Techniken

Ü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 Differenz aus aktuellem Datum und dem in der Headerzeile eingetragenen Datum maximal 2 Tage betragen darf, damit die Nachricht verifiziert werden kann?

Übung 3.16: DKIM, SPF, Sender ID und Hashcash Ü Vergleichen Sie die Verfahren DKIM, SPF, Sender ID und Hashcash. Wo gibt es Gemeinsamkeiten, wo existieren Unterschiede? Gibt es Verfahren, die Sie für bestimmte Einsatzzwecke für besonders geeignet halten?

Übung 3.17: Receiver-Driven SMTP Ü Können Sie sich Gründe dafür vorstellen, dass das vorgeschlagene Verfahren ab dem Jahr 2006 nicht mehr weiterverfolgt wurde?

Übung 3.18: Monarch Ü Untersuchen Sie, welche Merkmale in ? zur Klassifizierung von gutartigen oder schadhaften Webseiten herangezogen werden. Welche dieser Merkmale können auch für E-Mails zur Spamklassifikation verwendet werden?

Übung 3.19: Torpig-Domain-Generierungs-Algorithmus Ü Betrachten Sie den Algorithmus zur Generierung von Domain aus ?. Erzeu- gen Sie eine Domain für den heutigen Tag.

Übung 3.20: BotMagnifier Ü Verschaffen Sie sich mithilfe einer Suchmaschine Ihrer Wahl Zugang zu ?. Finden Sie heraus, von wem die Autoren die Transaktionenslisten erhalten haben.

Übung 3.21: BotSniffer Ü Betrachten Sie ? und finden Sie heraus, wie das Modul zur Korrelation der Daten Ergebnisse liefert. 3.16 Übungen Seite 105

Ü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 ? zu finden.

Übung 3.23: Botnet Judo II Ü Können Sie sich vorstellen, aus welchem Grund das System in ? Botnet Judo genannt wird?

Übung 3.24: Allgemein Ü Fassen Sie Merkmale zusammen, die für die Erkennung und Vermeidung von Spam wichtig sind.

Liste der Lösungen zu den Kontrollaufgaben Seite 107

Liste der Lösungen zu den Kontrollaufgaben

Lösung zu Kontrollaufgabe 1.1 auf Seite 16 E-Mails sind im Vergleich zu gewöhnlicher Post sowohl schneller, als auch günstiger im Versand. Hierfür wird jedoch gefordert, dass die zum Versand und Empfang benötigte Infrastruktur bereits vorhanden ist. Weiterhin sind E-Mails umwelt- freundlicher, da weder Papier benötigt wird, noch ein herkömmlicher Transport stattfinden muss.

Lösung zu Kontrollaufgabe 1.2 auf Seite 17 E-Mails werden zwar generell als umweltfreundlicher als herkömmliche Post an- gesehen, jedoch muss dabei beachtet werden, das die für das Versenden und dem Empfang benötigte Infrastruktur einen erheblichen Einfluss auf die Umweltfreund- lichkeit haben kann. Ein zum Empfang und zum Versand benötigter Computer muss bspw. erst durch aufwendige Techniken gebaut werden, wobei nicht uner- hebliche Mengen an schadhaften Stoffen entstehen. Weiterhin muss ein solcher Computer betrieben werden, was entsprechend Energie erfordert, die im Allge- meinen 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.

Lösung zu Kontrollaufgabe 1.3 auf Seite 17 Spam gibt es bspw. auch in Gästebüchern, Foren und Online-Spielen sowie bei Instant Messengern.

Lösung zu 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 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.

Lösung zu Kontrollaufgabe 1.5 auf Seite 31 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 Verbindungsversuch ständig überprüfen, ob ein Empfänger verfügbar wird, was entsprechende Ressourcen kostet.

Lösung zu Kontrollaufgabe 1.6 auf Seite 31 Zeilen sollten eine Länge von 78 Zeichen nicht überschreiten und dürfen maximal 998 Zeichen lang sein. Diese Beschränkung wurde in den Standard aufgenommen, damit einzelne Zeilen einfacher durch Softwareprodukte zu bearbeiten sind. Hier können bspw. reguläre Ausdrücke schneller abgearbeitet werden. Seite 108 Liste der Lösungen zu den Kontrollaufgaben

Lösung zu Kontrollaufgabe 1.7 auf Seite 31 Nach RFC 5322 ist es auch möglich, dass keine Empfänger im to Header Feld definiert werden. E-Mails, die keine Empfänger im to Header Feld enthalten, müssen dann jedoch mindestens einen Empfänger im cc oder bcc Header Feld enthalten, da sonst wirklich kein Empfänger existiert.

Lösung zu Kontrollaufgabe 1.8 auf Seite 31 SMTP wird zum Versand von E-Mail-Nachrichten verwendet. Dabei verbindet sich ein Client mit einem Server und geht dabei die einzelnen Schritte des definierten Protokolls durch. Mit SMTP können jedoch keine Nachrichten von einem Server abgeholt werden. Es ist ein reines unidirektionales Protokoll zum Versand von E-Mails.

Lösung zu Kontrollaufgabe 1.9 auf Seite 31 Bei der Base64 Kodierung wird die gleiche Zuordnungstabelle sowohl für die Kodierung als auch für die Dekodierung verwendet. Aufgrund dieser Tatsache, ist der Schlüssel, also die Tabelle allgemein bekannt und ersetzt daher keine Verschlüs- selung. Es wäre zwar möglich, mit verschiedenen Tabellen zu arbeiten, allerdings ist die Anzahl der möglichen Tabellen sehr stark begrenzt, weshalb ein Brute-Force Angriff sehr einfach möglich wäre, um eine solche Verschlüsselung zu knacken.

Lösung zu Kontrollaufgabe 1.10 auf Seite 31 Bei der SMTP-Auth Variante PLAIN werden das Passwort und der Benutzername jeweils mit dem Base64 Verfahren kodiert. Das verhindert zwar kurzfristig, dass sie direkt im Klartext sichtbar sind, jedoch können sie sehr einfach wieder dekodiert werden, da die Zuordnungstabelle für die Base64 Kodierung allgemein bekannt ist.

Lösung zu Kontrollaufgabe 1.11 auf Seite 32 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 informie- ren.

Lösung zu Kontrollaufgabe 1.12 auf Seite 32 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 kom- plette E-Mail abgerufen werden.

Lösung zu Kontrollaufgabe 1.13 auf Seite 32 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. Liste der Lösungen zu den Kontrollaufgaben Seite 109

Lösung zu Kontrollaufgabe 1.14 auf Seite 32 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.

Lösung zu Kontrollaufgabe 1.15 auf Seite 32 IMAP wird verwendet, um eine Kommunikation zu einem E-Mail-Server aufzu- bauen. 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.

Lösung zu Kontrollaufgabe 1.16 auf Seite 32 Bei IMAP findet die Nutzerauthentifizierung im Klartext statt, wodurch die Anmel- dedaten bei reinen IMAP-Implementierungen leicht abgegriffen werden können. Weiterhin ist auch der Rest der Kommunikation nicht verschlüsselt, wodurch alle Informationen, die während einer Sitzung vom Nutzer abgerufen werden, abgehört werden können.

Lösung zu Kontrollaufgabe 1.17 auf Seite 32 DNS ist ein System zur Identifizierung 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 finden. Es wird für Anti-Spam-Maßnahmen wie DNS-basiertes Blacklisting verwendet, um Infor- mationen über eine IP-Adresse zu erhalten.

Lösung zu Kontrollaufgabe 1.18 auf Seite 35 Für die Empfänger von Spam entstehen unterschiedliche Kosten. Auf der einen Seite stehen Personalkosten, sofern Spam von Mitarbeitern in einem Unternehmen aussortiert werden muss. Hier wird Arbeitszeit verwendet, die nicht der Wert- schöpfung im Unternehmen dient. Auf der anderen Seite entstehen Kosten für die Infrastruktur. Das sind zum einen die Internetanbindung und die Speicherplatz- lö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.

Lösung zu Kontrollaufgabe 1.19 auf Seite 35 Die Versender von Spam profitieren indem Spamempfänger die in den Werbebot- schaften beworbenen Produkte kaufen.

Lösung zu Kontrollaufgabe 1.20 auf Seite 36 Der Versuch, der Erlangung von persönlichen Daten, um bspw. Zugriff auf das Bankkonto einer Person zu erhalten, wird als Phishing bezeichnet. Spam kann als Medium für Phishing dienen, in dem keine Werbebotschaft übertragen wird, sondern der Nutzer eine E-Mail erhält, die ihn auf eine gefälschte Internetseite leitet, auf der er bestimmte persönliche Daten eingeben soll, mit denen Kriminelle das Opfer betrügen. Seite 110 Liste der Lösungen zu den Kontrollaufgaben

Lösung zu Kontrollaufgabe 2.1 auf Seite 54 Spammer benötigen um erfolgreich Spam zu versenden, viele Kontakte, damit sie möglichst effektiv 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 er- weitern. Er benötigt ebenfalls Bullet-Proof Server sowie Bankkonten in Ländern, die nicht mit Regierungen kooperieren, die versuchen gegen die Spammer vorzugehen. Der Spammer benötigt Kontakte zu den Produzenten und Versanddienstleistern der Produkte, die er bewirbt. Er muss Botnetze anmieten oder kaufen, um darüber Spam zu versenden und kann auch seine Infrastruktur anderen zur Verfügung stellen. Weiterhin kann er freie Mitarbeiter haben, die für ihn Adressen suchen oder Spam verschicken.

Lösung zu Kontrollaufgabe 2.2 auf Seite 54 Unter dem Begriff Adress-Harvesting versteht man das Suchen und Sammeln von E-Mail-Adressen, die daraufhin als Empfänger für den Versand von Spam missbraucht werden.

Lösung zu Kontrollaufgabe 2.3 auf Seite 55 Wenn die Länge des Nutzernamens fünf oder weniger Zeichen betragen darf und von einem Alphabet mit 36 Zeichen ausgegangen wird, dann ergeben sich

5 ∑ 36i = 361 + 362 + 363 + 364 + 365 = 62.193.780 i=1

Möglichkeiten.

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

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

Möglichkeiten.

Lösung zu Kontrollaufgabe 2.4 auf Seite 55 Um Adress-Harvesting auszuhebeln gibt es verschiedene Methoden, die die E-Mail- Adresse verändern. Dabei kann die Adresse bspw. durch bestimmte Substitutionen 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ög- lichkeit besteht darin, eine E-Mail-Adresse auf einer Webseite erst dann anzuzeigen, sobald der Benutzer ein CAPTCHA gelöst hat.

Lösung zu Kontrollaufgabe 2.5 auf Seite 55 Adress-Munging ist eine Technik, die die E-Mail-Adresse verfremdet. Hier wer- den Teil der E-Mail-Adresse durch andere Teile ersetzt, die von Menschen leicht substituiert werden können. Liste der Lösungen zu den Kontrollaufgaben Seite 111

Lösung zu Kontrollaufgabe 2.6 auf Seite 55 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 Glei- chung 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 brich ab sonst mache weiter done done Ausgabe: alle Gleichungen sind erfuellt

Lösung zu Kontrollaufgabe 2.7 auf Seite 55 Die Besonderheit der ROT13-Verschiebechiffre liegt darin begründet, dass sowohl für Ver- als auch für Entschlüsselung die gleiche Funktion verwendet werden kann. Da Modulo 26 gerechnet wird, entspricht die Addition der Subtraktion, wodurch nur eine Funktion benötigt wird.

Lösung zu Kontrollaufgabe 2.8 auf Seite 56 SMTP-Server, die keine Nutzerauthentifizierung durchführen, nehmen von jedem beliebigen Client Nachrichten an und schicken sie an ihr Ziel. Dieses offene Verschi- cken von Nachrichten macht einen SMTP-Server zu einem offenen Mail-Relay.

Lösung zu Kontrollaufgabe 2.9 auf Seite 57 Offene Proxys sind Server, die Pakete auf beliebigen vorher definierten Ports an- nehmen und weiter leiten. Seite 112 Liste der Lösungen zu den Kontrollaufgaben

Lösung zu Kontrollaufgabe 2.10 auf Seite 57 Mail-Formulare können dann zum Versand von Spam missbraucht werden, wenn der Entwickler des Formulars nicht alle möglichen Verwendungszwecke betrachtet hat und das Formular somit fehlerhaft implementiert wurde.

Lösung zu Kontrollaufgabe 2.11 auf Seite 59 Webmail ist ein Dienst, der im WWW von verschiedenen Anbietern den Nutzern zur Verfügung gestellt wird, um per E-Mail zu kommunizieren. Der Nutzer benö- tigt dafür jedoch kein eigenes E-Mail-Programm sondern nur einen Webbrowser.

Lösung zu Kontrollaufgabe 2.12 auf Seite 60 Webmail bietet die Vorteile, dass die E-Mails von Dienstanbieter zentral gesichert werden können. Auch kann das E-Mail-Konto von jedem beliebigen Computer mit Internetanschluss und Webbrowser genutzt werden, da keine spezielle Software installiert und konfiguriert werden muss. Als Nachteil stehen dem aber gegenüber, dass der Nutzer keine Möglichkeit hat, die Hardwareausstattung des Webservers zu verändern, sondern er mit der Geschwindigkeit nicht zufrieden ist. Er verfügt außerdem über keine eigene Sicherung seiner E-Mails und ist somit stark vom Anbieter abhängig.

Lösung zu Kontrollaufgabe 2.13 auf Seite 61 Beim IP Prefix Hijacking täuscht ein Netzbereich vor, die Pakete von einem an- deren 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.

Lösung zu Kontrollaufgabe 2.14 auf Seite 65 Malware zeichnet sich durch drei wesentliche Eigenschaften aus. Zum einen ver- breitet sich die Schadsoftware aktiv, indem Kopien des ausführbaren Codes auf andere Systeme transferiert werden oder passiv, indem der Benutzer die Schadsoft- ware versehentlich kopiert. Dieses Merkmal wird als Selbst-Replikation bezeichnet. Bedingt durch die Selbst-Replikation steigt die Gesamtzahl der vorhandenen Instan- zen. Hierbei wird von einem Populationswachstum gesprochen. Schadsoftware kann sich an andere Software hängen oder sich mit ihr vermischen, um unentdeckt zu bleiben. Diese Eigenschaft wird als Parasitismus bezeichnet.

Lösung zu Kontrollaufgabe 2.15 auf Seite 65 Ein Botnetz besteht aus vielen mit Malware infizierten Computern, die von einer bestimmten Stelle (zentral oder dezentral) aus gesteuert werden können. Dabei können die einzelnen Rechner dazu missbraucht werden E-Mail-Adressen zu sammeln oder auch Spam zu verschicken.

Lösung zu Kontrollaufgabe 2.16 auf Seite 65 Generell lassen sich die Kontrollstrukturen in zentrale und dezentrale Strukturen gliedern. Bei den zentralen Strukturen kann eine Kommunikation per IRC, HTTP oder auch FTP statt finden. Ein Vorteil bei der zentralen Kontrollstruktur besteht in der einfachen Implementierung und auch darin, dass bspw. HTTP nur in seltenen Fällen durch Firewall-Regeln blockiert wird. Der Nachteil liegt jedoch darin, dass nur die zentralen Server vom Netz genommen werden müssen, damit das gesamte Botnetz keine weiteren Befehle mehr annehmen kann. Eine dezentrale Kommuni- Liste der Lösungen zu den Kontrollaufgaben Seite 113 kation setzt auf Peer-To-Peer Protokolle. Hierbei sind mehrere Bots miteinander verbunden und geben die Befehle dann jeweils an die verbundenen Bots weiter. Die Implementierung ist hierbei aufwendiger, jedoch ist die Ausfalltoleranz deutlich größer. Es existiert keine zentrale Instanz, die vom Netz genommen werden kann, somit sind solche Botsnetze deutlich robuster.

Lösung zu Kontrollaufgabe 2.17 auf Seite 65 Beim IRC Protokoll besteht zwischen Client und Server eine persistente Verbindung. Da es eine Obergrenze für offene Verbindungen innerhalb jeder IRC Implemen- tierung gibt, können sich nicht mehr Bots verbinden, als die Implementierung vorsieht. Bei einer Kommunikation per HTTP kann das Aktualisierungsintervall prinzipiell fast beliebig groß gewählt werden. Damit sind auch fast beliebig viele anfragende Bots möglich.

Lösung zu Kontrollaufgabe 2.18 auf Seite 65 Botnetze können neben dem Versand von Spam auch für das Adress-Harvesting eingesetzt werden. Dies kann sowohl auf dem befallen Computer passieren, als auch im WWW. Daneben können Botnetze bspw. auch für DDoS Angriffe eingesetzt werden.

Lösung zu Kontrollaufgabe 3.1 auf Seite 72 Mailfiter können auf der einen Seite durch statische Regeln definiert werden. Da- bei 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 stel- len stochastische Analysen dar, wie bspw. Bayesfilter. Mit Hilfe von Bayesfiltern kann die Spam-Wahrscheinlichkeit bestimmt werden, sofern eine E-Mail gewisse Begriffe enthält.

Lösung zu Kontrollaufgabe 3.2 auf Seite 72 Bayesfilter ermöglichen die Vorhersage ob eine E-Mail Spam ist, wenn sie bestimmte Wörter enthält und bieten dazu eine bestimmte Wahrscheinlichkeit.

Lösung zu Kontrollaufgabe 3.3 auf Seite 77 IP-Sperren sich Mechanismen, die aufgrund der IP-Adresse einer anfragenden Verbindung darüber eine Aussage treffen, ob die IP-Adresse zu einem Computer gehört, der Spam versendet oder nicht. Es existieren drei Arten von IP-Sperren, das Blacklisting, das Whitelisting und das Graylisting.

Lösung zu Kontrollaufgabe 3.4 auf Seite 77 Sinnvollerweise werden IP-Sperren in SMTP-Servern eingesetzt. SMTP spezifiziert, dass ein Ablehnen einer E-Mail geschehen muss, noch wären die Verbindung zwischen Client und Server geöffnet ist. Eine einmal angenommene E-Mail soll demnach auch dem Empfänger zugestellt werden. Soll also aufgrund eines Listen- eintrags eine E-Mail von einem bestimmten Client nicht angenommen werden, so muss dies noch während des Transfers unterbrochen werden, was nur innerhalb des empfangenden SMTP-Server geschehen kann. Seite 114 Liste der Lösungen zu den Kontrollaufgaben

Lösung zu Kontrollaufgabe 3.5 auf Seite 78 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 Reputationsverfahren aktualisiert. Im Gegensatz zu dieser lokalen Methode gibt es aber auch eine zentrale Methode, bei der ein Server im Internet Anfragen aus unterschiedlichen Netzen beantwortet. Für die zentrale Methode hat sich DNS als Protokoll für die Anfrage ob ein Eintrag in der Liste vorhanden ist etabliert.

Lösung zu Kontrollaufgabe 3.6 auf Seite 78 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 an- gehängt (bspw. 1.2.168.192.dnsbl.rub.de). Im dritten Schritt wird diese Adresse dann per DNS aufgelöst. Das Resultat kann entweder eine IP-Adresse sein, die einen positiven Treffen in der Liste des Servers anzeigt, oder kein Datensatz, was bedeutet, dass es keinen Eintrag zu dieser IP-Adresse in der Liste des Servers gab. Im vierten Schritt kann dann noch der Grund beim DNSBL-Server für den Eintrag der IP-Adresse angefragt werden.

Lösung zu Kontrollaufgabe 3.7 auf Seite 78 Blacklists können einfach implementiert werden und sind gut dazu geeignet Spam- mer zu blockieren, die Spam von statische IP-Adressen aus senden. Da eine E-Mail aber erst als Spam von einem anderen System erkannt werden muss, unterliegen Blacklists immer eine gewissen zeitlichen Verzögerung und können somit nicht alle Verbindungsanfragen von Spammern blockieren. Als problematisch stellt sich aber auch die Zweckentfremdung von DNS für die Spambekämpfung dar, da DNS somit ein mögliches Ziel für Spammer wird, die das System stören könnten, um daraufhin effektiver Spam versenden zu können.

Lösung zu Kontrollaufgabe 3.8 auf Seite 78 Beim Whitelisting wird im Gegensatz zum Blacklisting nicht eine Liste mit Spam- versendern gepflegt, sondern eine Liste mit regulären E-Mail-Versendern. Auch hier wird unterschieden in lokales Whitelisting und globales Whitelisting, das auch per DNS ausgeführt werden kann. Whitelisting soll sicherstellen, dass nur E-Mails ein Konto erreichen, deren Absender im Vorhinein bereits als erwünschte Absender festgelegt wurden.

Lösung zu Kontrollaufgabe 3.9 auf Seite 78 Beim Graylisting werden beim Zustellversuch IP-Adresse, Absender-Adresse sowie Empfänger-Adresse im E-Mail-Header gespeichert und der Versuch durch einen temporären Fehlercode durch den SMTP-Server beendet. Der Client muss nun nach mindestens 25 Minuten und maximal vier Stunden eine erneute Zustellung versuchen. Wird die Zustellung innerhalb dieser Zeitspanne wiederholt, so wird die E-Mail an den Empfänger zugestellt. Ist dies nicht der Fall, so beginnt bei einem Zustellversuch ein neues Intervall. Graylisting kommt ohne externe Dienstanbieter aus, da alle Daten dazu lokal gespeichert und gehalten werden können. Eine globale Lösung hätte keinen Mehrwert und wäre auch nicht sinnvoll, da der lokale SMTP-Server nur E-Mails empfängt, die an lokale Konten adressiert sind.

Lösung zu Kontrollaufgabe 3.10 auf Seite 78 Graylisting bietet den Vorteil, dass es für den Administrator des SMTP-Servers Liste der Lösungen zu den Kontrollaufgaben Seite 115 einfach zu installieren und zu konfigurieren ist. Es ist relativ wartungsfrei und wird daher auch gerne eingesetzt. Ein weiterer Vorteil liegt beim Client, der für Graylisting nicht angepasst werden muss. Der Nutzer merkt eigentlich nur an der verzögerten Zustellung, dass Graylisting aktiv ist. Dieser Punkt ist aber auch direkt ein Nachteil, da beim Graylisting der eigentliche Vorteil der schnellen Zustellung durch das Verfahren verzögert wird. Weiterhin bietet Graylisting keinen vollstän- digen Schutz gegen Spam. Es baut auf einer unvollständigen Implementierung der E-Mail-Software von Spam verbreitenden Bots auf, die prinzipiell ohne große Probleme in diesem Punkt vervollständigt werden kann.

Lösung zu Kontrollaufgabe 3.11 auf Seite 90 DKIM ist eine Methode, um den Absender einer E-Mail zu verifizieren. Dazu fügt der SMTP-Server des Absenders ein weiteres Header Feld zur E-Mail hinzu, die den Hash von Teilen der E-Mail, mit dem privaten Schlüssel der Domain verschlüsselt, enthält. Der empfangende SMTP-Server kann dann per DNS den öffentlichen Schlüssel anfordern und den selber erstellten Hash mit dem entschlüsselten Hash vergleichen, um den Absender der E-Mail zu verifizieren. DKIM kann dabei jedoch nicht entscheiden, ob es sich bei einer E-Mail um Spam handelt oder nicht. Reguläre E-Mails, die keine oder keine gültige DKIM-Signature enthalten, können nicht als Spam klassifiziert werden, genauso können E-Mails, die eine gültige DKIM- Signature enthalten, nicht automatisch als Ham klassifiziert werden, da Spammer auch gültige DKIM-Signaturen an ihre E-Mails anhängen können, sofern sie den DNS Eintrag zu der zum Versand verwendeten Domain verändern können.

Lösung zu Kontrollaufgabe 3.12 auf Seite 91 DKIM ist auf der einen Seite für den Benutzer transparent, da alle Änderungen und Verifikationen auf den SMTP-Servern durchgeführt werden. Eine fehlerhafte oder nicht vorhandene DKIM Signature von einer Bank ist ein starkes Indiz für Phishing. Auf der anderen Seite kann eine E-Mail aber beim Transfer zwischen unterschiedlichen Character Sets konvertiert werden, wodurch die DKIM Signature nicht mehr zum Inhalt der E-Mail passt. Letztendlich muss wie bei allen anderen Verfahren, die auf kryptographischen Methoden aufbauen, darauf geachtet werden, dass die Schlüssellängen nicht zu kurz gewählt werden, da sonst durch einen Bruteforce-Angriff das Verfahren gestört werden kann.

Lösung zu Kontrollaufgabe 3.13 auf Seite 91 SPF ist ähnlich wie DKIM ein System zur Verifikation von E-Mails. Dabei wird bei SPF allerdings untersucht, ob der Versender die Berechtigung hat für die Absenderadresse eine Nachricht zu verschicken. Es wird jedoch nicht überprüft, ob der Inhalt der Nachricht während des Transports vom Sender zum Empfänger geändert wurde.

Lösung zu Kontrollaufgabe 3.14 auf Seite 91 Direktiven werden benötigt, um auszuwerten, ob eine IP-Adresse zum Versenden einer E-Mail mit einer bestimmten Absenderadresse autorisiert ist. Die Direktiven werden auf die IP-Adresse des Versenders angewendet und die zur Direktive gehörende Bedingung gibt bei einem Treffer an, wie mit der E-Mail weiter verfahren werden soll.

Lösung zu Kontrollaufgabe 3.15 auf Seite 91 Die ?-Bedingung soll für IP-Adressen zutreffen, bei denen der Besitzer der Domain Seite 116 Liste der Lösungen zu den Kontrollaufgaben

explizit erklärt, dass es zu diesen IP-Adressen keine Aussage treffen kann oder will. Die Antwort soll vom Server wie eine leere Antwort behandelt werden.

Lösung zu Kontrollaufgabe 3.16 auf Seite 91 Zur Verifizierung des Senders wird beim Sender ID Framework nicht nur die IP des Absenders verwendet, sondern auch die Purported Responsible Address (PRA).

Lösung zu Kontrollaufgabe 3.17 auf Seite 91 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.

Lösung zu Kontrollaufgabe 3.18 auf Seite 91 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 Emp- fänger verschickt, bei denen die Zufallszahlen jeweils gleich waren. 2. Eine reguläre E-Mail wurde auf dem Transfer zwischen Sender und Emp- fänger von einem Spammer mitgeschnitten und nun versucht der Spammer durch Angabe eines regulären Headers Spam an den Empfänger zu versen- den.

Lösung zu Kontrollaufgabe 3.19 auf Seite 91 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.

Lösung zu Kontrollaufgabe 3.20 auf Seite 92 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 Klassi- fikation der E-Mail eingesetzt wird.

Lösung zu Kontrollaufgabe 3.21 auf Seite 97 Beim Torpig Botnetz wird die Domain Flux Technik eingesetzt, damit die einzelnen Bots den Command und Control Server finden. Da es sich bei Torpig um eine Peer- To-Peer Archtitektur mit Command and Control Struktur handelt, kann es mehrere Command and Control Server geben, mit denen sich die Bots verbinden. Daher wird eine Technik benötigt, um immer den aktuellen Server zu finden.

Lösung zu Kontrollaufgabe 3.22 auf Seite 100 In beiden Ansätzen wird davon ausgegangen, dass Bots eines Botnetzes ein ähn- Liste der Lösungen zu den Kontrollaufgaben Seite 117 liches Verhalten aufweisen. Durch diesen Ansatz ist es möglich, Gruppen mit ähnlichem Verhalten zu erstellen, die dann einem Botnetz zugewiesen werden können.

Lösung zu Kontrollaufgabe 3.23 auf Seite 100 Damit eine Signatur erzeugt werden kann, müssen Spam Nachrichten vorliegen, die große Ähnlichkeiten aufweisen. Nur so kann erkannt werden, welche Teile in der Nachricht statisch und welche Teile dynamisch sind. Liegen nur sehr wenige Spam Nachrichten vor, so ist es schwieriger Ähnlichkeiten innerhalb der Nachrichten ausfindig zu machen. Genauso wichtig ist es, dass die Nachrichten nicht von vielen unterschiedlichen Templates stammen, sonst ist eine Zuordnung von Spam Nachricht zu Template sehr schwierig. Sind insgesamt nur wenige Nachrichten vorhanden die auch noch aus unterschiedlichen Templates stammen, so kann keine gute Signatur erzeugt werden, d.h. die resultierende Signatur hat nachher eine hohe Fehlerrate.

Lösung zu Kontrollaufgabe 3.24 auf Seite 100 Bei dem Update-Mechanismus werden bereits fertige Signaturen nachträglich verändern, sofern E-Mails erkannt werden und die Makros deaktiviert sind. Eine Aktualisierung ist in diesem Zusammenhang wichtig, da die Anzahl der Signaturen immer möglichst klein gehalten werden sollte, damit eine Erkennung auch in annehmbarer Zeit möglich ist.

Lösung zu Kontrollaufgabe 3.25 auf Seite 100 Der Parameter q gibt die minimale Anker-Länge an, die für die Erzeugung von Ankern verwendet wird. Sehr kurze minimale Anker-Längen können zu Ankern führen, die allgemeine Zeichen enthalten, sich jedoch nicht als Anker eignen. Zu lange minimale Anker-Längen wiederum können dazu führen, dass mögliche kurze Anker gar nicht betrachtet werden.

Der Parameter k ist verantwortlich für die Größe des Trainings-Puffers. Ist der Trainings-Puffer zu klein, kann es passieren, dass Signaturen erstellt werden, ob- wohl 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.

Verzeichnisse Seite 119

Verzeichnisse

I. Abbildungen

Abb. 1.1: SPAM...... 12 Abb. 1.2: Spamanteil von 2006-2012 aus ? ...... 15 Abb. 1.3: UML-Sequenzdiagramm einer beispielhaften E-Mail-Sitzung...... 18 Abb. 1.4: UML-Sequenzdiagramm einer SMTP-Sitzung...... 41 Abb. 1.5: UML-Zustandsdiagramm einer POP3-Sitzung...... 42 Abb. 1.6: UML-Sequenzdiagramm einer POP3-Sitzung...... 43 Abb. 1.7: UML-Sequenzdiagramm einer IMAP-Sitzung...... 44 Abb. 1.8: Spam-Wertschöpfungskette...... 44 Abb. 2.1: Aufbau eines Spammer-Netzwerks...... 46 Abb. 2.2: Ein visuelles CAPTCHA...... 50 Abb. 3.1: Blacklist-Erstellung aus ? ...... 74 Abb. 3.2: Blacklist-Erstellung nach ? ...... 75 Abb. 3.3: SNARE-Framework aus ? ...... 80 Abb. 3.4: Funktionsweise von Sender ID aus ? ...... 88 Abb. 3.5: Funktionsweise von Monarch aus ? ...... 92 Abb. 3.6: Flussdiagramm von Monarch aus ? ...... 92 Abb. 3.7: Raum- und zeitliche Korrelation von Bot-Antworten aus ? ...... 94 Abb. 3.8: Architekturübersicht von BotSniffer aus ? ...... 95 Abb. 3.9: Torpig-Netzwerk-Infrastruktur aus ? ...... 96 Abb. 3.10: Systemüberblick aus ? ...... 98 Abb. 3.11: Signatur Erstellungs Algorithmus aus ? ...... 99

II. Beispiele

Beispiel 1.1: Eine einfache E-Mail...... 20 Beispiel 1.2: SMTP-Status-Codes...... 22 Beispiel 1.3: Base64-Kodierung...... 24 Beispiel 1.4: POP3-Befehle...... 27 Beispiel 3.1: Bayes-Theorem...... 71 Beispiel 3.2: DKIM-Signature...... 83 Beispiel 3.3: DKIM-Verifikation...... 84 Beispiel 3.4: SPF-Eintrag für den Google Mail-Dienst...... 87 Beispiel 3.5: SPF-DNS-Einträge: Auflösung einer include Direktive...... 87

III. Definitionen

Definition 1.1: E-Mail...... 10 Definition 1.2: Spam...... 11 Definition 2.1: Malware...... 62

IV. 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 Seite 120 Verzeichnisse

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...... 21 Exkurs 1.11: Base64-Kodierung...... 23 Exkurs 2.1: Verschiebechiffre...... 53 Exkurs 2.2: ROT13 ...... 53 Exkurs 2.3: Felder in HTML Formularen...... 58 Exkurs 3.1: DKIM-Signature...... 83 Exkurs 3.2: Asymmetrische Kryptographie...... 85 Exkurs 3.3: SPF-DNS-Einträge...... 86 Exkurs 3.4: Reverse Engineering...... 97

V. Kontrollaufgaben

Kontrollaufgabe 1.1: Vorteile von E-Mails...... 16 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...... 31 Kontrollaufgabe 1.6: Beschränkung der Zeilenlänge innerhalb von E-Mails...... 31 Kontrollaufgabe 1.7: Anzahl der to Header Felder einer E-Mail...... 31 Kontrollaufgabe 1.8: Verwendung von SMTP...... 31 Kontrollaufgabe 1.9: Base64 Kodierung...... 31 Kontrollaufgabe 1.10: SMTP Auth...... 31 Kontrollaufgabe 1.11: POP3 Server Rückmeldungen...... 32 Kontrollaufgabe 1.12: POP3 Befehl: LIST und RETR ...... 32 Kontrollaufgabe 1.13: POP3 Befehl: DELE ...... 32 Kontrollaufgabe 1.14: POP3 Befehl: NOOP ...... 32 Kontrollaufgabe 1.15: Verwendung von IMAP...... 32 Kontrollaufgabe 1.16: Schächen von IMAP...... 32 Kontrollaufgabe 1.17: DNS...... 32 Kontrollaufgabe 1.18: Kosten für Spam...... 35 Kontrollaufgabe 1.19: Profit Spamversand...... 35 Kontrollaufgabe 1.20: Phishing...... 36 Kontrollaufgabe 2.1: Spammer-Netzwerk...... 54 Kontrollaufgabe 2.2: Adress-Harvesting...... 54 Kontrollaufgabe 2.3: Directory Harvest Attack...... 55 Kontrollaufgabe 2.4: Anti-Adress-Harvesting...... 55 Kontrollaufgabe 2.5: Adress Munging...... 55 Kontrollaufgabe 2.6: Verschiebechiffre...... 55 Kontrollaufgabe 2.7: ROT13-Verschiebechiffre...... 55 Kontrollaufgabe 2.8: Offene Mail-Relays...... 56 Kontrollaufgabe 2.9: Offene Proxies...... 57 Kontrollaufgabe 2.10: Mail-Formulare...... 57 Kontrollaufgabe 2.11: Webmail I...... 59 Kontrollaufgabe 2.12: Webmail II...... 60 Kontrollaufgabe 2.13: IP Prefix Hijacking...... 61 Kontrollaufgabe 2.14: Malware...... 65 Kontrollaufgabe 2.15: Botnetz I...... 65 Kontrollaufgabe 2.16: Botnetz II...... 65 Kontrollaufgabe 2.17: Botnetz III...... 65 Kontrollaufgabe 2.18: Botnetz IV...... 65 Kontrollaufgabe 3.1: Mailfilter...... 72 Kontrollaufgaben Seite 121

Kontrollaufgabe 3.2: Bayesfilter...... 72 Kontrollaufgabe 3.3: IP-Sperren I...... 77 Kontrollaufgabe 3.4: IP-Sperren II...... 77 Kontrollaufgabe 3.5: Blacklisting I...... 78 Kontrollaufgabe 3.6: Blacklisting II...... 78 Kontrollaufgabe 3.7: Blacklisting III...... 78 Kontrollaufgabe 3.8: Whitelisting...... 78 Kontrollaufgabe 3.9: Graylisting...... 78 Kontrollaufgabe 3.10: Graylisting II...... 78 Kontrollaufgabe 3.11: DKIM I...... 90 Kontrollaufgabe 3.12: DKIM II...... 91 Kontrollaufgabe 3.13: SPF I...... 91 Kontrollaufgabe 3.14: SPF II...... 91 Kontrollaufgabe 3.15: SPF III...... 91 Kontrollaufgabe 3.16: Sender ID...... 91 Kontrollaufgabe 3.17: Hashcash I...... 91 Kontrollaufgabe 3.18: Hashcash II...... 91 Kontrollaufgabe 3.19: Hashcash III...... 91 Kontrollaufgabe 3.20: Monarch...... 92 Kontrollaufgabe 3.21: Domain Flux...... 97 Kontrollaufgabe 3.22: BotMagnifier und BotSniffer...... 100 Kontrollaufgabe 3.23: Botnet Judo I...... 100 Kontrollaufgabe 3.24: Botnet Judo II...... 100 Kontrollaufgabe 3.25: Botnet Judo III...... 100