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

Transkript

1 Modul 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

2 2015 Ruhr-Universität Bochum Universitätsstraße Bochum 1. Auflage (27. März 2015) Didaktische und redaktionelle Bearbeitung: Bärbel Wolf-Gellatly Das Werk einschließlich seiner Teile ist urheberrechtlich geschützt. Jede Verwendung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung der Verfasser unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Um die Lesbarkeit zu vereinfachen, wird auf die zusätzliche Formulierung der weiblichen Form bei Personenbezeichnungen verzichtet. Wir weisen deshalb darauf hin, dass die Verwendung der männlichen Form explizit als geschlechtsunabhängig verstanden werden soll.

3 Inhaltsverzeichnis Seite 3 Inhaltsverzeichnis Einleitung zu den Studienbriefen 6 I. Abkürzungen der Randsymbole und Farbkodierungen II. Zu den Autoren III. Modullehrziele Studienbrief 1 Grundlagen Lernergebnisse Advanced Organizer Einleitung Spam RFC (Request for Comments) Gliederung ontrollaufgaben Internet Infrastruktur ommunikationsmodell Aufbau von s SMTP (Simple Mail Transfer Protocol) POP3 (Post Office Protocol Version 3) IMAP (Internet Message Access Protocol) DNS (Domain Name System) ontrollaufgaben Anreize und Motivation der Spammer Wirtschaftliche Aspekte Durch Spam entstehende osten Erlös für Spam-Verursacher ontrollaufgaben Fallstudie Click Trajectories: End-to-End Analysis of the Spam Value Chain Phishing Zusammenfassung Übungen Studienbrief 2 Spam-Techniken Lernergebnisse Advanced Organizer Einleitung Spammer Spammer-Netzwerke Adress-Harvesting Anti-Harvesting-Methoden ontrollaufgaben Offene Mail-Relays Mail-Formulare Webmail IP Prefix Hijacking Malware / Botnetze Zusammenfassung Übungen Studienbrief 3 Anti-Spam-Techniken Lernergebnisse Advanced Organizer Einleitung

4 Seite 4 Inhaltsverzeichnis 3.4 Mailfilter IP-Sperren Blacklisting Whitelisting Graylisting ontrollaufgaben Reputationsverfahren Challenge-Response-Verfahren Erweiterungen des -Verfahrens Domaineys / DIM SPF (Sender Policy Framework) Sender ID Hashcash Receiver-Driven SMTP ontrollaufgaben Echtzeit URL Filterung Netzwerk-basiertes Clustern Erkennung von Botnetzen Botnetz-Übernahme Botnet Judo: Automatische Generierung von Spam Signaturen SpamAssassin Zusammenfassung Übungen Verzeichnisse 111 I. Liste der Lösungen zu den ontrollaufgaben I. Abbildungen II. Beispiele III. Definitionen IV. Exkurse V. ontrollaufgaben

5 Einleitung zu den Studienbriefen Seite 5 Einleitung zu den Studienbriefen I. Abkürzungen der Randsymbole und Farbkodierungen Axiom Beispiel Definition Exkurs ontrollaufgabe Merksatz Quelle Satz Übung A B D E M Q S Ü

6 Seite 6 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.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 ryptographie. 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.

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

8

9 Studienbrief 1 Grundlagen Seite 9 Studienbrief 1 Grundlagen 1.1 Lernergebnisse Sie können die Struktur einer nach RFC822 beschreiben und erkennen. Darüber hinaus können Sie erläutern wie eine spezifiziert ist und die Unterschiede zu SPAM klar abgrenzen. Weiterhin können Sie erklären wie Spam entsteht und die wirtschaftlichen Aspekte, die den Versand von Spam für riminelle interessant machen, beschreiben. Dazu sind Sie in der Lage, die Grundlagen der -Struktur und deren Protokolle zu erläutern. 1.2 Advanced Organizer Welche technischen Grundlagen liegen der heutigen -Infrastruktur zugrunde? Diese Frage wollen wir in diesem Studienbrief einleitend klären. Wir werden hier die Protokolle SMTP, IMAP und POP3 einführen, die bereits aus Netzsicherheit 2 bekannt sind. Darüber hinaus werden wir uns anschauen, welchen Anreiz ein Spammer hat, Spam-Mail zu versenden und wie eine Mail als Spam spezifiziert wird. 1.3 Einleitung Elektronische Post (kurz genannt) ist heutzutage ein beliebtes ommunikationsmedium. Die vereinigt die Vorteile der synchronen und asynchronen ommunikation, da sie im Allgemeinen, im Gegensatz zum gedruckten Brief, mit nur geringen osten und fast ohne Zeitverzögerung zugestellt werden kann und auch vom Empfänger abrufbar ist, sobald dieser sich dazu entscheidet. Seit Jahrzehnten wird die ommunikation via jedoch durch Spam erschwert, indem der Großteil der verschickten und empfangenen s 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 Aufkommen gemacht. Dabei wird generell von mindestens 70 % Spam ausgegangen (vgl. Abbildung 1.2 auf Seite 16). Die Folgen von Spam sind vielfältig: Im privaten Bereich ist Spam hinderlich, da die ungewollten s teilweise mühevoll per Hand aussortiert werden müssen. Im geschäftlichen Umfeld ist Spam jedoch für einen nicht unerheblichen wirtschaftlichen Schaden verantwortlich, da Mitarbeiter in das Aussortieren von Spam Zeit investieren müssen, die ihnen dann für ihre eigentliche Arbeit fehlt. Ebenso müssen erhebliche Rechen- und Netzwerkkapazitäten zur Verfügung gestellt werden, damit der Transport und die Verarbeitung von erwünschten s nicht zu sehr beeinflusst wird. Dagegen steigt die Unzufriedenheit eines unden, wenn ein Anbieter nicht auf eine für den unden wichtige Nachricht reagiert. Der unde 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.

10 Seite 10 Studienbrief 1 Grundlagen 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 den Leser dazu schulen, Zusammenhänge und Techniken zu verstehen. Zum anderen werden aber auch aktuell Forschungsprojekte aufgegriffen und besprochen, die einen Einblick in ausgeklügelte Methoden und Ansätze vermitteln Wie bereits im obigen Text beschrieben, handelt es sich bei s (engl.: electronic mail) um elektronische Nachrichten, die in Computernetzen verschickt und empfangen werden. Dabei ist das größte Computernetz ohne Zweifel das weltumspannende Internet und somit ist es mit Hilfe von 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. onkreter wird im Abschnitt 1.5 auf die und die dazu benötigte Infrastruktur eingegangen. Es existieren verschiedene Definitionen für den Begriff . Der Duden beschreibt die bspw. mit [..] elektronischer Daten- und Nachrichtenaustausch über Computer[..] (vgl.?). Innerhalb dieser Studienbriefe gilt die folgende Definition 1.1. D Definition 1.1: Eine elektronische Nachricht, die innerhalb eines Computernetzes verschickt wird und deren Syntax konform zu RFC 822 (vgl.?) ist, wird als bezeichnet. Der Begriff RFC wird in Abschnitt ab Seite 16 behandelt. Insgesamt hat die folgende Vorteile gegenüber normaler Post: Eine gelangt innerhalb von Sekunden vom Versender zum Empfänger. Der finanzielle Aufwand für den Versand und den Empfang einer 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. s gelten als umweltfreundlicher als physikalische Post, da kein Papier benötigt wird und der Transport per LW, Bahn oder Flugzeug nicht erforderlich ist. -Adressen bieten eine gewissen Pseudonymität, teilweise sogar Anonymität. Je nach verwendetem Anbieter ist es möglich, nicht den eigenen Namen zu verwenden, sondern einen eigenen Absender zu wählen. Hierdurch ist es nur noch für den Domain-Inhaber möglich, von der Adresse auf den Absender zu schließen. Es existieren aber auch Dienste im Internet, die eine -Adresse ohne vorherige Anmeldung anbieten, sogenannte Einmal- -Adressen (One Time ) oder auch Wegwerf- - Adressen (Disposable 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.

11 1.3 Einleitung Seite 11 s können weiterhin problemlos an mehrere Empfänger versendet werden. Sie sind mit Hilfe von Software einfach nach bestimmten Suchbegriffen oder riterien hin durchsuchbar. Daher können sehr schnell benötigte Informationen gefunden werden. Es ist außerdem problemlos möglich, s mit Anhängen zu versehen, die dann mitübertragen werden. Weiterhin ist die Beantwortung einer deutlich einfacher als bei normaler Post. Hier liegen die gleichen Vorteile wie beim Verfassen von s, wie bspw. Zeit und osten. Im Folgenden wird auf einen Teil des -Aufkommens eingegangen, der mit Spam benannt wird und Hauptgrund für die vorliegenden Studienbriefe ist 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 unden dazu auffordern, bspw. seine Benutzerdaten zu verifizieren. Die s stammen jedoch von Betrügern, die die Empfänger durch Verweise in der 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 onten der Empfänger. Phishing wird weiter in Abschnitt 1.9 ab Seite 41 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 Eine Nachricht wird genau dann als Spam bezeichnet, wenn sie sowohl unerwünscht (unsolicited) ist als auch in großen Mengen (bulk) verbreitet wird. D Unerwünschte s sind kein Spam, da es sich bspw. um ernst gemeinte Jobanfragen oder auch Verkaufsanfragen handeln kann. Massen- s stellen auch keinen Spam dar, da bspw. Newsletter oder Mailinglisten von Nutzer erwünscht sind. Spam wird demnach auch als Unsolicited Bulk (UBE ), also unerwünschte Massenmail, bezeichnet. Als Abgrenzung dazu bezeichnet der Begriff HAM erwünschte bzw. reguläre -Nachrichten. Unsolicited Bulk , HAM Begriffsherkunft Ursprünglich wurde das von der amerikanischen Firma Hormel Foods Corporation ab dem Jahr 1937 hergestellte Dosenfleisch als SPAM (SPiced ham, vgl.

12 Seite 12 Studienbrief 1 Grundlagen Abbildung 1.1) bezeichnet, nachdem der Name bei einem Wettbewerb durch einen der Teilnehme vorgeschlagen wurde. Abb. 1.1: SPAM (?). 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 onversation unmöglich macht. Bis heute verkaufte die Hormel Foods Corporation mehr als sieben Milliarden Dosen SPAM. Als wichtige Randnotiz sollte angemerkt werden, dass der Begriff SPAM ein registriertes Markenzeichen der Firma Hormel Foods Corporation ist, wohingegen unerwünschte Werbung als Spam bezeichnet wird (vgl. Schreibweise). Neben der in diesem Modul behandelte Art von Spam in Form von s existieren noch viele weitere Arten von Spam, auf die im Folgenden kurz eingegangen wird. E Exkurs 1.1: Instant-Messenger-Spam Unerwünschte Nachrichten können in vielen ontexten erzeugt und versendet werden. Dies geschieht bspw. auch bei Sofortnachrichtendienste (Instant Messenger). Da viele Anbieter von Sofortnachrichtendiensten ein Verzeichnis ihrer Nutzer bereitstellen, in denen persönliche Informationen wie Alter und Geschlecht erfasst sind, ist es für Werbende denkbar einfach, personenbezogene Werbung zu verschicken. Die meisten Protokolle, die für Sofortnachrichtendienste verwendet werden, sind jedoch proprietärer Art und können auf Wunsch des Herstellers verändert und aktualisiert werden. Daher kann auf Schwachstellen eingegangen werden, um den unerwünschten Versand von Nachrichten einzuschränken. Viele Softwareprodukte bieten daher die Möglichkeit, dass der Nutzer Nachrichten ausschließlich von bereits bekannten ontakten erhält und sich neue ontakte erst beim Nutzer anmelden müssen, um diesem Nachrichten schicken zu können.

13 1.3 Einleitung Seite 13 Exkurs 1.2: Mobile-Phone-Spam Ein weiteres Medium, welches zum Versand von Spam genutzt wird, sind urznachrichtendienste für Mobiltelefone (Mobile-Phone-Spam). Obwohl Spam innerhalb von urznachrichten nur einen sehr geringen Anteil am gesamten Datenvolumen ausmacht und außerdem für den Versender auch osten verursacht, gibt es trotzdem auch in diesem Bereich einige Gegenmaßnahmen. Alle deutschen Mobilfunkanbieter stellen -Adressen zur Verfügung, an die sich Nutzer wenden können, sofern sie durch Spam auf ihrem Mobiltelefon belästigt werden. E Exkurs 1.3: Foren-Spam Internet-Foren werden generell zum asynchronen Austausch von Informationen genutzt. Dabei kann eine beliebig große Anzahl an Teilnehmern Beiträge zu einem Thema veröffentlichen, die dann linear innerhalb einer Internetseite dargestellt werden. Um Beiträge Teilnehmern zuzuordnen, müssen sich die Teilnehmer, die Beiträge veröffentlichen wollen, an das System anmelden. Schadsoftware, insbesondere Spam Bots, können die oftmals einfache Anmeldung an ein Forum automatisieren, um zu beliebigen Beiträgen eigene Nachrichten zu erstellen, die zwar nichts mit dem Thema des Beitrags zu tun haben, als Inhalt aber Werbung in Form von Links zu anderen Internetseiten enthalten. Gegen diese als Foren-Spam bekannte Art von Spam gibt es Gegenmaßnahmen, die zum einen bei der Erstellung von Nutzerkonten greifen, zum anderen aber auch bei der Erstellung von Beiträgen. So müssen nun Nutzer sogenannte CAPTCHAs (Completely Automated Public Turing test to tell Computers and Humans Apart) lösen, um ein onto zu eröffnen oder Beiträge zu veröffentlichen. E Exkurs 1.4: Online-Game-Spam Viele gegenwärtige Spiele bieten die Möglichkeit, dass Teilnehmer innerhalb der Spielewelt untereinander kommunizieren. Oft gehört diese Art der ommunikation auch zum onzept des Spiels. Gegeben durch diesen Anlass können auch Nachrichten verschickt werden, die nicht zum Spielgeschehen dazu gehören, sondern bspw. Waren innerhalb aber auch außerhalb des Spiels anbieten. Diese Art des Spam wird auch als Online-Game Spam bezeichnet und findet sich häufig innerhalb von MMORPGs (Massively Multiplayer Online Role-Playing Game). E

14 Seite 14 Studienbrief 1 Grundlagen E Exkurs 1.5: Spamdexing Eine weitere Form des Spams findet sich in Suchmaschinen, die das WWW mit Hilfe von Suchbegriffen indizieren. Die als Spamdexing bekannte Technik macht sich die Eigenschaften der Algorithmen der Suchmaschinenbetreiber zunutze, um den Suchindex zu manipulieren. Das Ziel davon besteht darin, bestimmte Seiten im Index so weit wie möglich an die Spitze der Ergebnisse zu bringen, damit sie von Benutzern möglichst häufig besucht werden. E Exkurs 1.6: Blog-, Wiki- und Gästebuch-Spam Auch innerhalb von Blogs, Wikis oder Gästebüchern ist Spam ein Problem. Sobald ein Medium zur Verbreitung von Informationen genutzt wird und es gleichzeitig die Möglichkeit bietet, dass Besucher eigene Informationen eintragen, können diese Dienste zur Darstellung von unerwünschten Informationen missbraucht werden. E Exkurs 1.7: SPIT und VoIP-Spam Ebenso existiert Spam auch im Bereich gesprochener Nachrichten. Mit der Entstehung von Voice-over-IP (VoIP) und der damit verbundenen Möglichkeit, Telefongespräche kostenlos über das Internet zu führen, entstanden auch Möglichkeiten, das System für unerwünschte, automatisch angewählte und im Vorhinein aufgezeichnete Anrufe zu nutzen. Diese Verbreitung wird als SPam over Internet Telephony (SPIT), oft aber auch als Voice-over-IP Spam (VoIP-Spam) bezeichnet. Wobei auch hier Gegenmaßnahmen existieren. E Exkurs 1.8: Academic Search Spam Im akademischen Bereich werden oft unterschiedliche Suchmaschinen genutzt, um wissenschaftliche Literatur zu finden und auch um die Wichtigkeit bestimmter Artikel zu erkennen. Beel und Gipp untersuchten dazu das Verhalten von Suchmaschinen und stellten fest, dass diese sich leicht durch manipulierte Dokumente überlisten lassen und in Folge dessen beliebige Suchergebnisse anzeigen (?). 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 s zu verteilen. Ursprünglich sah die Standardkonfiguration dieser Server vor, dass man s über einen Dienstanbieter versenden kann, auch wenn man sich nicht vorher als regulärer

15 1.3 Einleitung Seite 15 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 s zu maskieren. Eine recht einfache aber wirkungsvolle Methode, das Problem der Open Relays zu beheben, besteht darin, das Open Relay über seine IP-Adresse zu identifizieren, um Nachrichten, die von ihm aus verschickt werden, direkt zu blockieren. Weiterhin existieren in den Anfangszeiten des Internets sehr viele Server, die beliebige Informationen auf freigegebenen Ports weiterleiteten und dabei die Quell- 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. Eine Möglichkeit fanden sie in den weit verbreiteten Webmail-Diensten. Alle großen Internetdienstanbieter bieten ihren unden -Adressen an. Viele Anbieter geben darüber hinaus auch weiteren Nutzern die Möglichkeit, ein E- Mail-onto zu eröffnen, da sie sich bspw. daraus einen höheren Bekanntheitsgrad erhoffen. Dadurch bedingt, dass es möglich ist, sich anonym ein -onto zu erstellen, können nun Spammer beliebig viele onten erstellen, um ihre unerwünschten Massenmails zu versenden. Dies kann jedoch wiederum durch den Anbieter erkannt werden, sobald dieser zu Beispiel die Anzahl der ausgehenden s überprüft und ab einen bestimmten Schwellwert das onto sperrt. Daher gibt es einen weiteren Bereich, der heutzutage vorherrschend als Ursprung von Spam betrachtet wird. Malware ist die urzform der englischen Begriffe malicious software (dt.: bösartige Programme) und ist ein Oberbegriff für sämtliche schadhafte Software. Unter diesen Begriff fallen Viren, Würmer, trojanische Pferde und viele weitere. Eine Schadsoftware, die über eine Sicherheitslücke ein Computersystem befällt, kann nicht nur lokale Informationen auf dem System auslesen und ändern, sondern auch Netzwerkverbindungen aufnehmen. Mithilfe dieser Funktionalität kann eine solche Schadsoftware den Rechner aus der Ferne steuern und auch neue Befehle nachladen. Werden mehrere dieser Bots über einen Server zusammengeschlossen, so ergibt sich ein Botnetz, das aus vielen tausenden Computersystemen bestehen kann und durch den Botmaster gesteuert wird. Eine mögliche Schadfunktionalität kann dabei der Versand von Spam sein, wobei dem vorausgehend bereits über eine andere Schadfunktion das Adressbuch des Nutzers des Computersystems ausgelesen worden sein kann, damit die Spam-Nachrichten an existierende - onten versendet werden. Heutzutage sind Botnetze aufgrund ihrer Flexibilität und sehr schlechten Blockierbarkeit die häufigste Ursache von Spam. Open Proxy Webmail Malware, Botnetz Studienbrief 2 ab Seite 47 geht näher auf den Ursprung vom Spam ein. Einen Überblick über den Verlauf des Spamanteils im gesamten verkehr 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 99).

16 Seite 16 Studienbrief 1 Grundlagen Abb. 1.2: Der Anteil von Spam am gesamten E- Mail-Aufkommen nach? RFC (Request for Comments) Requests for Comments (dt.: Bitte um ommentare) sind Dokumente, die technische Standards im Internet dokumentieren und spezifizieren (vgl.?). Im ursprünglichen Sinne waren die Dokumente dazu gedacht, von anderen Entwicklern ommentare 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 Errata angegeben werden und dem Dokument angefügt werden, jedoch darf das Dokument nicht verändert werden. Wird ein Standard erweitert, so müssen diese Erweiterungen innerhalb einer neuen RFC beschrieben werden. Die Erweiterung kann auch die vorherige RFC umdefinieren, womit die alte RFC obsolet wird. RFCs werden fortlaufend durchnummeriert, um zum einen exakte Referenzierung zu ermöglichen und zum anderen zeitliche Abhängigkeiten kenntlich zu machen. Daraus bedingt ist es möglich, dass zu einem Standard mehrere RFCs existieren, die alle gleichzeitig gültig sein können. Innerhalb dieses Moduls werden oft bestimmte RFCs referenziert und beschrieben, da Wert auf exakte Informationen gelegt wird. Der Leser ist dazu angehalten, die RFCs als weiterführende Literatur zu betrachten und diese bei Verständnisproblemen als Hilfe zu verstehen Gliederung Das gesamte Modul ist in vier Studienbriefe gegliedert. In diesem ersten Studienbrief werden die Grundlagen zur Analyse von Spam betrachtet. Dazu wird zuerst besprochen, was Spam ist und wo er entsteht. Daraufhin wird die - Infrastruktur skizziert, um darin die einzelnen Protokollschritte zu verstehen, die eine benötigt, um vom Sender zum Empfänger zu geladen. Weiterhin wird aufgezeigt, welche Anreize bzw. Motivation Spammer antreibt und dass es Gründe gibt, warum Spam immer noch existent ist, obwohl es schon seit Jahrzehnten

17 1.3 Einleitung Seite 17 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 47 mit Spam-Techniken. Hier wird beschrieben, wie Spam anfangs verbreitet wurde, welche Techniken die anfänglichen Versuche ablösten und was aktuell für das Spam-Aufkommen verantwortlich ist. Im dritten Studienbrief werden dann ab Seite 71 Techniken behandelt, die dazu gedacht sind, das Spam-Aufkommen einzudämmen. Es werden Methoden besprochen, die sich aktuell im Einsatz befinden, aber auch zukunftsweisende Forschungsarbeiten vorgestellt, die auf den weltweit wichtigsten onferenzen von Gutachten als zielführend betrachtet werden. Der vierte Studienbrief beschäftigt sich ab Seite?? letztendlich mit den rechtlichen Aspekten von Spam. Hier wird untersucht, welche gesetzlichen Grundlagen in verschiedenen Ländern existieren. Unterteilt wird in diesem Studienbrief nach Strafund Zivilrecht. Nachfolgend wird auch auf das Wettbewerbsrecht eingegangen, bevor Empfehlungen zur Verhinderung vom Spam behandelt werden ontrollaufgaben In diesem Abschnitt befinden sich verschiedene ontrollaufgaben, welche die Inhalte der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffes beitragen sollen. ontrollaufgabe 1.1: Vorteile von s Geben Sie die drei Hauptvorteile von s im Vergleich zur gewöhnlichen Post an. ontrollaufgabe 1.2: Umweltfreundlichkeit von s önnen Sie sich vorstellen, aus welchem Grund Diskussionen über die Umweltfreundlichkeit von s geführt werden? Aus welchem Grund können s weniger umweltfreundlich sein als physikalische Post? ontrollaufgabe 1.3: Spam in anderen Medien Nennen Sie vier Medien (außer ), in denen Spam verschickt wird. ontrollaufgabe 1.4: Der Ursprung von Spam Beschreiben Sie zwei mögliche Entstehungsarten von Spam und nennen Sie Maßnahmen, mit denen Spam aus diesen Quellen unterbunden werden kann.

18 Seite 18 Studienbrief 1 Grundlagen 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 , die maßgeblicher Bestandteil dieses Moduls ist. Die 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 Infrastruktur s nutzen zwar das Internet, um vom Sender zum Empfänger zu gelangen, jedoch mussten dazu Designentscheidungen getroffen sowie Protokolle entwickelt werden, die sich um das Behandeln der Daten kümmern. Daher wird im Folgenden beschrieben, welche Infrastruktur für den Transport von s im Internet notwendig ist, wie s aufgebaut sind und wie die benötigten Protokolle dafür definiert sind ommunikationsmodell Peer-to-Peer-Modell, Client-Server-Modell Der Zweck einer besteht darin, Informationen von einem Sender zu einem Empfänger zu schicken. Dazu wäre es theoretisch ausreichend, wenn es eine Direktverbindung zwischen Sender und Empfänger geben würde und der Sender die Daten direkt zum Empfänger schickt. Dieses direkte ommunikationsmodell wird als Peer-to-Peer-Modell bezeichnet, bei der auf eine zentrale Instanz verzichtet wird. Solange beide ommunikationspartner immer erreichbar sind, wäre es denkbar, ein solches ommunikationsmodell zu verwenden. Jedoch besteht ein zentrales Ziel der -ommunikation darin, dass das gesamte System asynchron verwendet werden können soll. Um dieses Ziel zu erreichen, müsste der Sender so lange mit dem Transfer der Nachricht warten, bis der Empfänger erreichbar ist, um die Informationen zu erhalten. Im allgemeinen Fall möchte der Sender seinen Computer allerdings nach Beendigung der Arbeit ausschalten können, was nur dann möglich ist, wenn er auf das Versenden der verzichtet. Der Empfänger möchte weiterführend auch, dass ein Sender s 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 -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 -onto immer einem Server zugeordnet ist, prinzipiell aber jeder Nutzer die Möglichkeit hat, einen eigenen -Server zu betreiben, war diese Erweiterung des Modells notwendig.

19 1.5 -Infrastruktur Seite 19 Abbildung 1.3 stellt beispielhaft dar, wie eine 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. MUA (A) SMTP Server (A) NS Server (B) POP3/SMTP Server (B) MUA (B) Versand an eigenen Server. SMTP DNS Anfrage nach Adresse des Mail-Servers von B. DNS DNS Antwort mit Adresse des Mail-Servers von B. DNS Abb. 1.3: UML- Sequenzdiagramm einer beispielhaften - Sitzung, bei der Nutzer A mit seinem Mail-User- Agent (MUA) eine an Nutzer B schickt. An den Pfeilen stehen die jeweils verwendeten Protokolle. Versand an Mail-Server von B. SMTP Mail-Server von B wartet auf Anfrag von B. Anfrage nach neuen s von B an eigenen -Server. POP3 Gespeicherte von A wird ausgeliefert. POP Aufbau von s s 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 beinhaltet. Grundlegend wurde der Aufbau von s durch die Internet Engineering Task Force (IETF) im aktuellen Request for Comments (RFC) 5322 (?) spezifiziert, der jedoch durch weitere RFCs bzgl. Internationalisierung erweitert wurde. Ein weiterer wichtiger Punkt zum generellen Aufbau von s ist, dass s nur aus druck- bzw. lesbaren Zeichen sowie wenigen Steuerzeichen wie Zeilenumbruch, Leerzeichen und Tabulator (US-ASCII, vgl. Exkurs 1.9) bestehen. Das bedeutet zum einen, dass s ohne weitere Hilfsmittel per Hand von Menschen ausgewertet werden können, da sie nicht die volle Breite eines Bytes von 2 8 = 256 möglichen Belegungen ausnutzen. Zum anderen können dadurch Binärdateien nicht ohne eine Transformation übertragen werden, bei welcher der Anhang vom Binärformat in ein kompatibles Format vor der Übertragung transformiert wird. RFC 5322, US-ASCII

20 Seite 20 Studienbrief 1 Grundlagen E Exkurs 1.9: US-ASCII ASCII steht für American Standard Code for Information Interchange und ist eine Zeichenkodierung, die 33 nicht druckbare sowie 95 druckbare Zeichen einem Bitmuster zuweist. Als Zeichenvorrat dient grundsätzlich das Alphabet einer Schreibmaschine für die englische Sprache sowie einige Protokollzeichen bspw. zum Anzeigen des Übertragungsendes. Dabei steht das A an Position 65 und wird somit als Binärstring übertragen. Da nur 128 Zeichen definiert sind, ein Byte aber 256 mögliche Repräsentationen hat, bleibt 1 8 = 12,5% der möglichen Bandbreite bei der Übertragung von Zeichen in ASCII-odierung ungenutzt. Im Folgenden werden die einzelnen Teile von s 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 Zeilenumbruch (CRLF) beendet werden. Der Feldinhalt darf keinen Zeilenumbruch enthalten, es sei denn, es handelt sich um ein Long Header Field, das durch Teilung (engl.: folding) bzw. Invertierung der Teilung entstanden ist. Header-Felder teilen sich weiter auf in unstrukturierte Header-Felder sowie strukturierte Header-Felder. Dabei enthalten unstrukturierte Header-Felder einen Inhalt, der zwar aus druckbaren Zeichen bestehen muss, allerdings keinen weiteren syntaktischen Regeln genügen muss. Im Gegensatz dazu müssen strukturierte Header-Felder syntaktisch nach bestimmten Regeln aufgebaut sein. Zur Optimierung der lexikalischen Analyse von Nachrichten existieren jedoch Regeln zur maximalen Lä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 innerhalb des Inhaltes eines Headers anstelle dessen auch ein Zeilenumbruch vor dem Leerzeichen eingefügt werden kann. Mögliche Header-Felder sind from, sender, to sowie subject. Body Die RFC 5322 definiert auch syntaktisch den Inhalt des Body-Teils einer . 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.

21 1.5 -Infrastruktur Seite 21 Beispiel 1.1: Eine einfache From: To: Subject: Beispiel Date: Fri, 28 Nov :54: Message-ID: B Das ist eine Beispiel- . Zu beachten sind insbesondere die beiden Leerzeilen. Die erste Leerzeile trennt den Header vom Body. Ohne eine solche Leerzeile enthält eine keinen Body, sondern nur einen Header. Die zweite Leerzeile definiert das Ende der und ist somit auch syntaktisch von essenzieller Wichtigkeit. Im Folgenden werden verschiedene Protokolle beschrieben, die für den Transfer von s von Bedeutung sind SMTP (Simple Mail Transfer Protocol) SMTP wurde erstmals in RFC 821 (?) im Jahre 1982 spezifiziert und ist ein ernelement der -ommunikation. Über die Jahre wurden einige Erweiterungen RFC 855 RFC 821, 5321, RFC 854, und Verbesserungen eingepflegt, die letztendlich durch RFC 5321 (?) spezifiziert sind. Das Protokoll hat grundsätzlich zwei Funktionen. Zum einen wird es verwendet, um s in das System einzuschleusen. In diesem Fall meldet sich ein Client bei einem Server an und definiert innerhalb dieser Sitzung eine , die der Server lokal speichert. Zum anderen wird das Protokoll auch verwendet, um eine ommunikation zwischen verschiedenen Servern zu ermöglichen. Dies ist bspw. dann notwendig, wenn Server A von einem Client eine erhalten hat, das onto 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 entsprechend weiter, damit Server B die daraufhin in das richtige Postfach einsortieren kann. Das Protokoll baut, ähnlich wie auch die 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 weitere Software ausgeführt werden. Abbildung 1.4 auf Seite 22 stellt eine SMTP-Sitzung beispielhaft dar. SMTP definiert für die ommunikation mehrere Status-Codes, die auf den Status- RFC 959 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. Im folgenden Exkurs 1.10 werden die SMTP-Status-Codes detaillierter beschrieben.

22 Seite 22 Studienbrief 1 Grundlagen Abb. 1.4: UML- Sequenzdiagramm einer SMTP-Sitzung. Client --Verbindungsaufbau 220 service ready Server Wartet auf Verbindungsauf HELO clientname.example.net 250 ok MAIL FROM:<sender@example.org> 250 ok RCPT TO:<empfaenger@example.org 250 ok DATA 354 start mail input From: <sender@example.org> To: <empfaenger@example.org Subject: Beispiel Date: Fri, 28 Nov :54: Das ist eine Beispiel . Diese enthaelt keinen sinnvollen Text ok QUIT 221 closing channel

23 1.5 -Infrastruktur Seite 23 Exkurs 1.10: SMTP-Status-Codes Für die erste und wichtigste Stelle des SMTP-Status-Codes gibt es vier mögliche Werte, wobei y und z stellvertretend für andere Ziffern stehen: E 2yz Die Antwort bestätigt den vom Client gesendeten Befehl und zeigt auf, dass der Befehl vollständig ausgeführt wurde. 3yz Die Antwort bestätigt den vom Client gesendeten Befehl, allerdings werden zur vollständigen Verarbeitung weitere Informationen vom Client benötigt. Andernfalls kann der Befehl nicht vollständig verarbeitet werden. 4yz Eine vorübergehende negative Antwort: Der Befehl wurde nicht umgesetzt und die angefragte Aktion konnte temporär nicht ausgeführt werden. Der Sender soll mit dem Befehl erneut beginnen, damit dieser ggf. erfolgreich ausgeführt werden kann. Im Gegensatz zu 5yz Status- Codes der nächsten ategorie, sollen diese Status-Codes übermittelt werden, wenn es möglich ist, dass der exakt gleiche Befehl durch erneutes Senden zum Erfolg führt. 5yz Eine permanente negative Antwort: Der Befehl wurde nicht umgesetzt, die angefragte Aktion kann nicht ausgeführt werden und der Client soll die gleiche Anfrage auch nicht erneut an den Server senden. Dieser Fall tritt ein, wenn bspw. die Syntax des Clients nicht dem Standard entspricht. Die zweite Ziffer teilt die Status-Codes in weitere ategorien 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.

24 Seite 24 Studienbrief 1 Grundlagen Im folgenden Beispiel werden einige mögliche Rückgabewerte angeführt. B Beispiel 1.2: SMTP-Status-Codes 220 mail.example.com Dienst verfügbar. 250 Angefragte 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 Nutzerauthentifizierung verwendet, um nach der erfolgreichen Authentifizierung auch s versenden zu können. RFC 2554, RFC 4954, RFC 4616 Aufgrund einer relativ aufwendigen Implementierung wird heutzutage allerdings oftmals eher SMTP-Auth verwendet, das erstmals in RFC 2554 (vgl.?) definiert wurde. RFC 4954 ist eine Überarbeitung davon und gilt als vorgeschlagener Standard (vgl.?). SMTP-Auth beschreibt fünf verschiedene Möglichkeiten zur Authentifizierung. Zum einen wird die PLAIN-Authentifizierung vorgeschlagen, die als RFC 4616 (vgl.?) die RFC 2595 (vgl.?) erweitert. Bei dieser Möglichkeit der Authentifizierung werden Benutzername und Passwort zwar nicht im lartext (engl.: plain) übertragen, da sie Base64-kodiert (vgl. Exkurs 1.11) werden, jedoch ist eine Base64- odierung keine Verschlüsselung, da diese Funktion ohne Passwort auskommt und invertierbar ist (vgl. Merksatz 1.1).

25 1.5 -Infrastruktur Seite 25 Exkurs 1.11: Base64-odierung E Die Base64-odierung wird neben der Base16- und Base32-odierung in RFC 4648 der RFC 4648 (vgl.?) beschrieben. Dabei werden binären Daten in ein von Menschen lesbares Alphabet kodiert. onkreter wird immer eine Gruppe von 24 Bit (3 Byte) in vier 6-Bit-Blöcke unterteilt und danach jeder einzelne Block umgewandelt. Die folgende Tabelle dient dabei der Zuordnung zwischen dem Wert W, also der dezimalen Darstellung einer 6 Bit langen Zeichenkette und dem dafür zu verwendenden Code C: W C W C W C W C 0 A 17 R 34 i 51 z 1 B 18 S 35 j C 19 T 36 k D 20 U 37 l E 21 V 38 m F 22 W 39 n G 23 X 40 o H 24 Y 41 p I 25 Z 42 q J 26 a 43 r b 44 s L 28 c 45 t M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w 15 P 32 g 49 x 16 Q 33 h 50 y (pad) = Eine binäre Zeichenkette der Länge n benötigt nach der Umwandlung folgenden Speicherplatz: n Enthält die letzte umzuwandelnde Gruppe nur 1 Byte, so wird der resultierende Block mit zwei padding-zeichen (=) aufgefüllt. Enthält die letzte umzuwandelnde Gruppe 2 Byte, so wird ein padding-zeichen angefügt. Merksatz 1.1: Base64-odierung Es ist zu beachten, dass die Base64-odierung keine Verschlüsselung darstellt, da es ohne weitere Informationen möglich ist, aus einer Base64-kodierten Zeichenkette den ursprünglichen Text zu berechnen. M Das folgende Beispiel 1.3 zeigt exemplarisch die Verwendung der odierung.

26 Seite 26 Studienbrief 1 Grundlagen B Beispiel 1.3: Base64-odierung In der folgenden Tabelle wird das Wort Studie zuerst in das US-ASCII- Äquivalent in dezimaler Schreibweise überführt. Aus der dezimalen Schreibweise wird die binäre Darstellung bestimmt. Sechs Bits werden dann jeweils als Block betrachtet und wieder in ihre dezimale Darstellung umgeformt. Diese dezimale Darstellung eines 6-Bit-Blocks entspricht dann jeweils dem Index i aus der Tabelle aus Exkurs Zeichen S t u d i e ASCII Dezimal ASCII Binär Index Base64 U 3 R 1 Z G l l Eingesetzt ergibt sich die Zeichenkette U3R1ZGll. Analog ist es möglich, die Berechnung bei der Base64-kodierten Zeichenkette zu starten, um daraus die ursprüngliche Zeichenkette zu erhalten. Die zweite Möglichkeit, die in der RFC 4954 zur Authentifizierung vorgeschlagen wird, ist die LOGIN-Methode. Die LOGIN-Authentifizierung funktioniert ähnlich wie die PLAIN-Authentifizierung. Hier werden Benutzername und Passwort auch per Base64 kodiert, jedoch im Gegensatz zur PLAIN-Authentifizierung in zwei Schritten übertragen. RFC 2195, RFC 1321, RFC 2104 Als drittes Verfahren gilt das in RFC 2195 (vgl.?) als CRAM-MD5 vorgestellte Verfahren. CRAM-MD5 steht für Challenge-Response Authentication Mechanism, Message Digest 5 und ist demnach ein Authentifizierungsverfahren, das nach dem Challenge-Response-Prinzip (vgl. auch Abschnitt 3.7 ab Seite 83) 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 Zeichenkette muss einen Zeitstempel und den vollständigen Hostnamen des Servers enthalten. Außerdem sollen noch willkürliche Ziffern enthalten sein, um die Zeichenkette möglichst einmalig zu machen. 2. Der Client antwortet mit einer Zeichenkette, die wie folgt erzeugt wird: a) Die Zeichenkette vom Server wurde mit dem Base64-Verfahren kodiert. Daher muss die Zeichenkette dekodiert werden. b) Die dekodierte Zeichenkette wird per HMAC-MD5 (vgl.?) mit dem Passwort des Nutzers verschlüsselt. c) Die verschlüsselte Zeichenkette wird in eine hexadezimale Zeichenkette überführt. d) Der Nutzername sowie ein Leerzeichen werden der hexadezimalen Zeichenkette vorangestellt. e) Die resultierende Zeichenkette wird Base64-kodiert und an den Server verschickt.

27 1.5 -Infrastruktur Seite 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. 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, die Replay-Angriff 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 omplexität nicht eingegangen. Nachdem nun die Eigenschaften von SMTP ausgiebig beschrieben wurden, folgt im nächsten Abschnitt das Post-Office-Protokoll in Version POP3 (Post Office Protocol Version 3) Im Gegensatz zu dem im vorherigen Abschnitt vorgestellten SMTP, ist POP3 kein Protokoll zum Versand von s. Es wird vielmehr zum Abholen von s 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 s zu geben, die auf einem - Server liegen. Zwar wäre es für einen Nutzer auch möglich, seinen eigenen Computer mithilfe entsprechender Software als SMTP-Server zu konfigurieren, der Betrieb wäre jedoch aus mehreren Gründen sehr schwierig. Zum einen kann ein Nutzer nicht sicherstellen, dass sein Computer jederzeit erreichbar ist, was den Empfang von s 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 ab Seite 34) entsprechend verteilt werden, damit neue s 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 -Abrufs per POP3 ins Spiel kommt. RFC 918, RFC 1034, DNS Abbildung 1.6 auf Seite 29 zeigt eine POP-Sitzung. RFC 1939 Zu erkennen ist die Authentifikation im ersten Schritt nach dem Verbindungaufbau, was POP3 zu etwas mehr Sicherheit verhilft. Es ist zwar mithilfe von SMTP möglich, s in das System unter falschem Namen einzuschleusen, jedoch kann nur derjenige, der die Zugangsdaten für ein onto hat, die eingetroffenen s auch abrufen. Nach vielen

28 Seite 28 Studienbrief 1 Grundlagen Detailverbesserungen ist RFC 1939 (?) die letzte und aktuelle Spezifikation von POP3. Sicherheitskritisch ist dabei jedoch zu beachten, dass auch in diesem Protokoll die ommunikation unverschlüsselt stattfindet und somit abgehört werden kann. Das Passwort wird zusätzlich im lartext übertragen, wodurch nicht nur die Inhalte der übertragenen s an den einzelnen noten der Datenübertragung sichtbar waren, sondern auch alle notwendigen Informationen über das Benutzerkonto. POP3 sollte daher nicht in unbekannten oder nicht vertrauenswürdigen Netzwerken ohne separate Absicherung verwendet werden. Die Basisoperationen von POP3 lassen sich innerhalb von wenigen Punkten beschreiben und aus Zustandsgraph visualisieren (vgl. Abbildung 1.5). Der POP3-Server wartet auf einen Verbindungsaufbau von einem Client (Zustand: WAITING_FOR_CONNECTION). Nachdem der Client eine Verbindung aufgebaut hat, sendet der Server eine Willkommensnachricht an den Client (Zustand: AUTHORIZATION). Der Client muss sich daraufhin am Server authentifizieren, damit der Server die Verbindung zum richtigen Postfach herstellen kann (Zustand: TRANSACTION). Daraufhin tauschen Server und Client solange Nachrichten aus, bis die Verbindung geschlossen oder abgebrochen wird (Zustand: Update). Nachdem der Server das QUIT-ommando 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). Abb. 1.5: UML- Zustandsdiagramm einer POP3-Sitzung. WAITING_FOR_CONNECTION Verbindungsaufbau AUTHORIZATION Client Identifikation am Server TRANSACTION Aktionen ausführen Verbindung getrennt Client sendet QUIT ommando UPDATE CLOSE Insgesamt sollte festgehalten werden, das POP3-ommandos Text-basiert und ohne Beachtung von Groß- und leinschreibung sind. Nach einem Schlüsselwort können ein oder mehrere Argumente folgen. Schlüsselwörter wiederum können aus drei oder vier Zeichen bestehen, Argumente dürfen bis zu 40 Zeichen lang sein. Beide enthalten ausschließlich druckbaren US-ASCII-Zeichen. Antwortnachrichten bestehen aus einem Statusindikator (+/-) und einem Schlüsselwort, das mit weiteren Informationen erweitert werden darf. Alle Antworten werden durch die beiden Steuerzeichen CRLF beendet und dürfen maximal 512 Zeichen (inkl. die abschließenden Steuerzeichen) lang sein. Als Statusindikatoren dürfen nur der positive Status +O und der negative Status -ERR verwendet werden. Antworten auf

29 1.5 -Infrastruktur Seite 29 Client --Verbindungsaufbau Server Wartet auf Verbindungsaufbau Abb. 1.6: UML- Sequenzdiagramm einer POP3-Sitzung. +O example.com POP3-Server USER +O Please enter password PASS passwort_im_klartext +O mailbox locked and ready STAT +O LIST +O mailbox has 1 message (236 octets) RETR 1 +O message follows Date: Fri, 28 Nov :54: From: <sender@example.org> To: <empfaenger@example.org Subject: Beispiel Das ist eine Beispiel . Diese enthaelt keinen sinnvollen Text.. DELE 1 +O message marked for delete QUIT +O bye

30 Seite 30 Studienbrief 1 Grundlagen 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 ommunikationspartner 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. B Beispiel 1.4: POP3-Befehle USER benutzername wählt das Benutzerkonto mit dem Namen benutzername aus. PASS passwort übergibt das Passwort passwort im lartext an den Server. STAT listet den Status der Mailbox auf. Dabei wird zum einen die Anzahl der vorhandenen s ausgegeben und zum anderen der durch diese s belegte Speicherplatz. LIST (n) zeigt Informationen zur n-ten an. Wird kein Argument mitgegeben, so wird je vorhandener jeweils eine Informationszeile angegeben. RETR n zeigt den Inhalt der n-ten an. Die Angabe von n ist hier zwingend notwendig. DELE n markiert die n-te auf dem Server. Der Speicherplatz wird erst dann freigegeben, sobald der Server in den UPDATE-Zustand (vgl. Abbilding 1.5 auf Seite 28) geht. NOOP enthält keinen Befehl, kann aber an den Server gesendet werden, um den Timeout zurückzusetzen, der optional implementiert sein kann. Dadurch wird der Server daran gehindert, die Verbindung zu beenden und der Client muss nicht erneut eine Verbindung aufbauen. RSET setzt alle als gelöscht markierten s zurück. Dadurch können fälschlicherweise gelöschte s wiederhergestellt werden. Dies ist allerdings nur solange möglich, wie die Verbindung noch geöffnet ist. Sobald die Verbindung zwischen Client und Server einmal geschlossen wurde, wurden die zum Löschen markierten s 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 s entfernen. Ist der Löschvorgang nicht erfolgreich, so quittiert der Server dies mit einer negativen Rückmeldung.

31 1.5 -Infrastruktur Seite 31 Wie bereits weiter oben beschrieben, hat POP3 zwei Schwachstellen. Zum einen findet die Benutzerauthentifikation im lartext statt. Dadurch bedingt ist es für Angreifer mit vergleichbar geringem Aufwand möglich, die ontoinformationen wie Benutzername und Passwort herauszufinden. Zum anderen verwendet POP3 keine Verschlüsselung, wodurch nicht nur die ontoinformationen, sondern auch alle anderen Informationen für Angreifer sichtbar werden. Um das erste Problem anzugehen, enthält POP3 den optionalen Befehl APOP. Server, die diesen Befehl implementieren, senden nach dem Verbindungsaufbau durch den Client nicht nur +O 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 lartext sowie den vorher berechneten Hashwert als Argumente. Der Server, der das ennwort zu dem Benutzerkonto kennt, kann dann auch den Hashwert zu dem von ihm generierten Zeitstempel konkateniert mit dem ennwort des Benutzers berechnen und somit abgleichen, ob der Benutzer das korrekte ennwort eingegeben hat. Von essenzieller Bedeutung ist hierbei, dass jeder Zeitstempel einzigartig ist. APOP, RFC 822, RFC 1321 Für das zweite Problem der nicht vorhandenen Verschlüsselung bietet POP3 keine POP3S, RFC 2595 direkte Lösung. Als Erweiterung von POP3 wird hier POP3S angeführt. Dieses Protokoll baut auf POP3 auf, verwendet als Protokoll auf der Transport-Schicht allerdings TLS (Transport Layer Security) und ist innerhalb der RFC 2595 spezifiziert (vgl.?). Somit existieren Möglichkeiten, die den -Abruf absichern. Häufig werden diese jedoch aus Bequemlichkeitsgründen nicht angewendet IMAP (Internet Message Access Protocol) Genau wie die beiden vorher beschriebenen Protokolle SMTP und POP3 basiert IMAP ebenfalls auf der US-ASCII-Zeichenkodierung. Es ist aktuell in RFC 3501 (?) 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. RFC 3501, RFC 1064, RFC 1203, RFC 1730 IMAP wurde so geplant und entwickelt, dass Nutzer ihre s nicht mehr wie bei POP3 vom Server zum Client transferieren und gleichzeitig auf dem Server löschen, sondern die s, Ordnerstrukturen und Einstellungen bleiben auf dem Server, damit diese von unterschiedlichen Computern desselben Benutzers genutzt werden können. Abbildung 1.7 auf Seite 32 zeigt dazu eine Beispiel-IMAP- Sitzung. Gegenüber POP3 bietet IMAP verschiedene Vorteile, die im Folgenden näher betrachtet werden.

32 Seite 32 Studienbrief 1 Grundlagen Abb. 1.7: UML- Sequenzdiagramm einer IMAP-Sitzung. Client --Verbindungsaufbau Server Wartet auf Verbindungsaufbau * O IMAP4rev1 Service Ready a001 login benutzername passwort a001 O LOGIN completed a002 select inbox * 18 EXISTS * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * 2 RECENT * O [UNSEEN 17] Message 17 is the first unseen message * O [UIDVALIDITY ] UIDs valid a002 O [READ-WRITE] SELECT completed a003 fetch 12 full * 12 FETCH (BODY[HEADER] {342} Date: Wed, 17 Jul :23: (PDT) From: Terry Gray <gray@cac.washington.edu> Subject: IMAP4rev1 WG mtg summary and minutes To: imap@cac.washington.edu cc: minutes@cnri.reston.va.us, John lensin <LENSIN@MIT.EDU> Message-Id: <B @cac.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII ) a004 O FETCH completed a005 store 12 +flags \deleted * 12 FETCH (FLAGS (\Seen \Deleted)) a005 O +FLAGS completed a006 logout * BYE IMAP4rev1 server terminating connection a006 O LOGOUT completed

33 1.5 -Infrastruktur Seite 33 Permanente Verbindung Da bei IMAP die Daten auf dem Server bleiben, bietet das Protokoll die Möglichkeit, dass der Client durchgehend mit dem Server verbunden ist. Dadurch bedingt können dem Client neue Nachrichten sofort angezeigt werden. Die Verbindung bleibt offen und muss somit nicht - wie bei POP3 - zu jeder Abholung von neuen Nachrichten neu aufgebaut werden. Nachrichten werden dann auf den Client heruntergeladen, sobald dieser sie anfordert. Je nach onfiguration 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 onto POP3 ist dahingehend beschränkt, dass sich pro onto 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 onto 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 POP3 spezifiziert den Befehl RETR n, der eine komplette Nachricht vom Server auf den Client herunterlädt. s, 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 ennzeichen Durch die Verwendung von sogenannten ennzeichen (engl.: flags), die für IMAP definiert sind, kann ein Client einer bestimmte Statusinformationen anhängen. So können die s auf dem Server bspw. als gelesen oder wichtig markiert werden. Erstellung von Unterkonten und Zuweisung von Zugriffsrechten für andere Nutzer Zur Strukturierung der s auf dem Server können Nutzer eigene Unterkonten RFC 4314 anlegen, die im Client als Ordner angezeigt werden. Zwischen verschiedenen Ordnern können s 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 s nach bestimmten riterien zu durchsuchen. Dadurch bedingt muss

34 Seite 34 Studienbrief 1 Grundlagen der Client nicht alle s zuerst herunterladen, bevor er mit der Suche anfangen kann, sondern erhält sofort die passenden Treffer. Schnittstelle für Erweiterungen Die aktuelle Version 4 von IMAP bietet explizit einen Mechanismus, um Erweiterungen einzubauen. IMAPS, RFC 2595, RFC 3207 Grundsätzlich hat IMAP allerdings auch Probleme bzgl. Sicherheit, genauso wie auch SMTP und POP3. Sowohl die Datenübertragung als auch die Authentifizierung des Nutzers finden im lartext statt. Dabei hat der Server allerdings die Möglichkeit, die Authentifizierung des Nutzers zu unterbinden, solange die Verbindung nicht verschlüsselt wurde. Um die Verbindung zu verschlüsseln existieren zwei Möglichkeiten. Zum einen kann IMAPS verwendet werden. Hier wird schon während des Verbindungsaufbaus die Verbindung transparent per TLS verschlüsselt (vgl.?). Zum anderen besteht die Möglichkeit, eine bereits bestehende unverschlüsselte Verbindung mithilfe des STARTTLS-Befehls (vgl.?) in eine verschlüsselte Verbindung zu überführen DNS (Domain Name System) RFC 1034, RFC 1035 RFC 1180, RFC 791, RFC 1349, RFC RFC , RFC 2474 Das Domain Name System (DNS) ist eines der wichtigsten Systeme zur Nutzung des World Wide Web. Da es für einige Maßnahmen zur Abwehr von Spam benötigt wird, die in Studienbrief 3 ab Seite 71 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. Das im Internet verwendete TCP/IP (vgl.?) setzte auf numerische Adressen, um Computer zu erreichen. Diese werden bei IPv4 ( vgl.? und?) durch vier jeweils 8 Bit große Blöcke definiert, die durch Trennpunkte unterteilt werden und im dezimalen Zahlensystem dargestellt einen Wert zwischen 0 und 255 annehmen können. Daher sind maximal 2 32 = Adressen möglich. Eine Adresse hat damit bspw. die lesbare Form 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 , was einer Vergrößerung gegenüber IPv4 um den Faktor , 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 bietet nur für sehr wenige Menschen Information darüber, was auf der Seite zu finden

35 1.5 -Infrastruktur Seite 35 ist. Der damit verbundene Name open-c3s.de ist dagegen allerdings einprägsam und hat zumindest für die Leser dieses Studienbriefes eine Semantik. Die in Studienbrief 3 beschriebenen Anti-Spam-Techniken verwenden DNS, um Informationen über die Absenderadresse einer zu erhalten. Daraus soll erkannt werden, ob es sich bei dem Versender um einen bekannten Spammer handelt oder nicht. DNS-basierte Blacklists enthalten genau solche Informationen und werden ständig aktualisiert. Mehr Informationen dazu folgen allerdings in Abschnitt ab Seite 74. Nachdem in diesem Abschnitt die wichtigen Protokolle für die - ommunikation vorgestellt wurden, sollen die ontrollaufgaben im folgenden Abschnitt das Gelernte festigen ontrollaufgaben In diesem Abschnitt befinden sich verschiedene ontrollaufgaben, welche die Inhalte der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffes beitragen sollen. ontrollaufgabe 1.5: Modellentscheidung Welche onsequenzen ergeben sich für Sender und Empfänger, falls das Peer-to-Peer-Modell anstelle des Client-Server-Modells verwendet werden würde? ontrollaufgabe 1.6: Beschränkung der Zeilenlänge innerhalb von s Welche maximale Zeilenlänge wird für s empfohlen, welche Zeilenlänge muss eingehalten werden? Welchen Grund gibt es für diese Beschränkungen? ontrollaufgabe 1.7: Anzahl der to Header Felder einer Betrachten Sie die RFC 5322 (?). Wie groß ist die minimale Anzahl der Empfänger? An wen können s versendet werden, wenn die minimale Anzahl an Empfängern verwendet wird? ontrollaufgabe 1.8: Verwendung von SMTP Zu welchem Zweck wird SMTP verwendet?

36 Seite 36 Studienbrief 1 Grundlagen ontrollaufgabe 1.9: Base64 odierung Beschreiben Sie, warum die Base64 odierung kein Ersatz für eine Verschlüsselung darstellt. ontrollaufgabe 1.10: SMTP Auth Was passiert bei der SMTP-Auth Variante PLAIN mit dem Passwort und dem Benutzername? Warum ist diese Möglichkeit der Authentifizierung nicht sicher? ontrollaufgabe 1.11: POP3 Server Rückmeldungen Welchen Zweck verfolgen positive bzw. negative Rückmeldungen des Servers? ontrollaufgabe 1.12: POP3 Befehl: LIST und RETR Was ist der Unterschied zwischen den beiden POP3 Befehlen LIST und RETR? ontrollaufgabe 1.13: POP3 Befehl: DELE Welche onsequenz hat der DELE-Befehl für eine bestimmte ? ontrollaufgabe 1.14: POP3 Befehl: NOOP Wozu wird der NOOP-Befehl verwendet? Gibt es POP3-Implementierungen, die diesen Befehl überflüssig machen? ontrollaufgabe 1.15: Verwendung von IMAP Zu welchem Zweck wird IMAP eingesetzt? ontrollaufgabe 1.16: Schächen von IMAP An welchen Stellen bestehen bei IMAP Schwächen und wie wird versucht diese zu beheben?

37 1.6 Anreize und Motivation der Spammer Seite 37 ontrollaufgabe 1.17: DNS Was ist DNS, wozu wird es benötigt, und was hat es mit Spam zu tun? 1.6 Anreize und Motivation der Spammer In diesem Abschnitt soll nur kurz auf die Motivation der Spammer eingegangen werden, da Studienbrief?? ab Seite?? dazu genauere Informationen enthält. Der allgemeine onsens zu Spam besteht darin, dass alle Empfänger Spam als hinderlich empfinden und oftmals gelernt haben, damit zu leben. Obwohl automatische Mechanismen einen Großteil des Spams aus den Postfächern herausfiltern, kann es trotzdem hin und wieder passieren, dass eine Spam-Nachricht nicht als solche erkannt wird, was nur hinderlich ist. Es kann jedoch auch passieren, dass eine als Spam erkannt wird, was dann schädlich sein kann, wenn die wichtige Informationen enthält und der Empfänger sie nie erhalten hat. Die Frage, die hier gestellt werden kann, ist warum Spam überhaupt existiert und welchen Nutzen hat er. Die Antwort auf diese Frage ist relativ simpel: Für die Versender von Spam stellt Spam eine Einnahmequelle dar. Spam enthält sehr oft Werbung und wenn diese Werbung geschickt genug an den Empfänger gebracht wird, passiert es erstaunlicherweise häufig, dass unbedarfte Empfänger die Produkte, die angepriesen werden, kaufen. Die Informationen, die mittels Spam übertragen werden, können auch einen Betrugsversuch darstellen, der zum Betrug wird, sobald der Empfänger an die falschen Informationen glaubt und die im Spam geforderten Aktionen ausübt. Ebenfalls wird Spam dazu benutzt, um einen Identitätsdiebstahl zu begehen. Ahnungslose Empfänger glauben, dass eine Spam-Nachricht wirklich von ihrer Bank gekommen ist und geben PIN und TAN oder reditkartennummer an Betrüger heraus (vgl. Phishing in Abschnitt 1.9 ab Seite 41). Weiterhin wird Spam auch benutzt, um Schadsoftware auf andere Rechner zu übertragen, damit diese bspw. Teil eines Botnetzes werden. In all diesen Fällen geht es den Spammern jedoch darum, Geld zu verdienen. Spam-Nachrichten, bei denen nicht erkennbar ist, wie deren Versender damit Geld verdienen können, weil die Nachrichten bspw. keinen Text enthalten, basieren häufig auf Programmierfehlern des Versenders. Um die in diesem Abschnitt angesprochene Motivation für Spammer näher auszuführen, wird in Abschnitt 1.8 eine Fallstudie besprochen, die im Jahr 2011 in den USA durchgeführt wurde. Vorher werden im nächsten Abschnitt allerdings wirtschaftliche Aspekte angesprochen. 1.7 Wirtschaftliche Aspekte Wirtschaftliche Aspekte lassen sich in zwei ategorien einteilen. Auf der einen Seite sind dies osten, die durch Spam und die daraufhin eingeleiteten Abwehrmaßnahmen entstehen. Auf der anderen Seiten entstehen aber auch Gewinne bei

38 Seite 38 Studienbrief 1 Grundlagen den Versendern von Spam, die den finanziellen Ertrag als Ziel und den versendeten Spam als Mittel zum Erreichen des Ziels ansehen Durch Spam entstehende osten Die osten, die durch Spam verursacht werden, entstehen wiederum in zwei Bereichen. Zum einen handelt es sich um Personalkosten, sofern das -onto zu einem Unternehmen gehört. Gehört das -onto 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 osten schwierig. Gehört das onto aber zu einem Unternehmen, so kann untersucht werden, wie lange ein Mitarbeiter für das Erkennen und Aussortieren von Spam täglich benötigt. Es gibt viele Untersuchungen, die unterschiedliche Ergebnisse liefern.? 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 osten bei der Infrastruktur. Dies kann zum einen bei dem Unternehmen sein, dass Spam empfängt und eigene -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 leinunternehmen bzw. Einzelunternehmen. Ab ca. 3 Millionen verwalteten Postfächern spricht die Studie von einem Großprovider, der im Normalfall pro Tag im Durchschnitt etwa 5 Spam-Nachrichten pro Postfach erhält. Damit beläuft sich das gesamte Spam-Aufkommen auf 15 Millionen Spam-Nachrichten in dem genannten Zeitraum. Um wettbewerbsfähig zu sein und auch zu bleiben, muss sich ein Großprovider um entsprechende Schutzmaßnahmen kümmern. Diese bestehen in der Regel aus einem mehrstufigen Filtersystem mit selbst entwickelter Software oder stark angepassten Lizenzprodukten. Doch nicht nur die Infrastruktur zur Ausfilterung von Spam muss vorhanden sein, sondern es müssen auch die bereits vorhandenen Datenverbindungen für die erhöhten Anforderungen ausgelegt sein. In? wird ein Datenverkehr von ca. 128 TB pro Jahr berechnet, der ausschließlich dazu verwendet wird, um die Spam-Nachrichten zu transportieren. Die Anbindung muss daher entsprechend angepasst sein, damit es nicht bei erwünschten s zu Engpässen kommt. Doch nicht nur die apazitäten für den Datenverkehr müssen entsprechend angepasst sein, auch die vorhandenen Speichersysteme müssen für die zusätzliche Speicherung der Spam-Nachrichten geeignet ausgelegt werden. Der genannte Bericht geht hier von einem zusätzlichen Speicherbedarf von drei TB pro Tag aus. Aus Sicht des Großproviders ist es nicht möglich, die als Spam erkannten Nachrichten zu blocken oder zu löschen, vielmehr müssen diese gesondert dem Nutzer zur Verfügung gestellt werden, damit dieser ggf. falsch erkannte Nachrichten identifizieren und retten kann. Daher sind mind. 75 % der Gesamtkosten begründet durch die für die Verarbeitung von Spam bereits zu haltende Infrastruktur. onkret entstehen osten 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 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.

39 1.7 Wirtschaftliche Aspekte Seite 39 Für ein Großunternehmen sind die osten dagegen anders verteilt. Da in diesen Unternehmen die gesamte IT-Infrastruktur oftmals groß genug ausgelegt ist, müssen keine weiteren Puffer für Spam eingeplant und finanziert werden. Es bedarf jedoch an Lizenz- und Personalkosten. Gerade die Personalkosten sind hier sehr groß, da davon ausgegangen werden muss, dass Mitarbeiter durch Spam-Nachrichten von ihrer produktiven Arbeit abgehalten werden, um die Spam-Nachrichten per Hand auszusortieren, die automatische Softwarelösungen nicht erkannt haben. Werden keine Softwarelösungen zu Erkennung von Spam-Nachrichten eingesetzt, so belaufen sich die osten auf 18 Cent pro Spam-Nachricht. Werden hingegen Softwarelösungen eingesetzt, so müssen dafür zusätzliche Lizenzen bezahlt werden. Bedingt durch eine entsprechende Trefferquote, belaufen sich die osten 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 leinunternehmen ergeben sich sehr ähnliche Werte Erlös für Spam-Verursacher Der Erlös für Spammer ist sehr unterschiedlich und lässt sich nicht exakt bestimmen. Auch hier existieren Untersuchungen, die den Erlös für Spammer ausrechnen. In? wird bspw. von 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 ontrollaufgaben In diesem Abschnitt befinden sich verschiedene ontrollaufgabe, welche die Inhalte der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffes beitragen sollen. ontrollaufgabe 1.18: osten für Spam Durch welche Faktoren entstehen osten für den Empfänger von Spam? ontrollaufgabe 1.19: Profit Spamversand Wie profitieren die Versender vom Spam?

40 Seite 40 Studienbrief 1 Grundlagen 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äftsmodell. In vielen anderen Veröffentlichungen steht die Erkennung und Bekämpfung von Spam auf technischer Ebene im Vordergrund, hier wird die Spam-Problematik allerdings auf einer abstrakteren Ebene angegangen. Obwohl es eine allgemeine Antipathie der Gesellschaft gegen Spam gibt und trotz der Industrie, die jährlich hohe Summen in die Bekämpfung von Spam steckt, ist Spam immer noch ein großes Problem und es scheint keine Lösung in Sicht zu sein. Daher haben sich die Autoren mit dem Geschäftsmodell hinter Spam beschäftigt, um die genauen Zusammenhänge zu verstehen, da sie der Anti-Spam-Industrie vorhalten, dass diese sich nur mit wenigen Aspekten der Wertschöpfungskette von Spam auseinandersetzen. Dazu zählen die Spam-Filterung (vgl. Abschnitt 3.4 ab Seite 71), das URL-Blacklisting (vgl. Abschnitt ab Seite 74) und das vom Netz nehmen von Servern (vgl. Abschnitt 3.12 ab Seite 99). 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 63), Webmailer (vgl. Abschnitt 2.7 ab Seite 61) und IP Prefix Hijacking (vgl. Abschnitt 2.8 ab Seite 62) gestoßen. Abb. 1.8: Die für eine einzige URL- Wertschöpfungskette verwendete Infrastruktur aus?. Um nun zu erfahren, wie man mit vergleichsweise wenig Aufwand das System der Spammer lahmlegen kann, haben die Autoren untersucht, auf welchem Weg das Geld transferiert wird, das bei Einkauf von per Spam beworbenen Produkten den Besitzer wechselt. Dazu gruppierten die Autoren zuerst die einzelnen Shop-Adressen, die sie durch die Spam-Nachrichten bekamen, um die größten ampagnen zu finden. Daraufhin versuchten die Autoren bei 120 Shops einen Einkauf zu tätigen, von denen allerdings nur 76 äufe erfolgreich waren. In ooperation mit der Bank, deren reditkarte sie nutzen, erfuhren sie, welche Banken mit den Versendern von Spam zusammenarbeiten und aus welchen Ländern diese kommen. Letztendlich stellte sich bei der Untersuchung heraus, dass die Banken der Spammer als Flaschenhals für deren Geschäftsmodell angesehen werden können. Nur wenige kleinere Banken arbeiten mit Spammern zusammen und sofern die großen Banken nicht mehr reditkartenü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.

41 1.9 Phishing Seite 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 unstwort, das vom englischen fishing (dt.: angeln) und dem Begriff Phreaking, der ein offerwort 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önlicher Daten anderer Personen (wie Passwort, reditkartennummer o. Ä.) mit gefälschten s oder Websites. onkret wird also von riminellen Spam versendet, der den Anschein erweckt, es handele sich um eine offizielle von einer Bank oder Behörde. Innerhalb dieser wird der unde 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 opie der offiziellen Seite. Verlangt wird dann nach reditkartennummern oder Zugangsdaten für Online Banking onten. In letzter Zeit treten auch vermehrt Phishing-Versuche auf die onten der Spieler von beliebten Online-Spielen auf (vgl.?,? und?). Dabei werden die Benutzer durch eine Phishing- 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 onten übertragen, um es bspw. im Spiel an andere Spieler zu verkaufen. Es gibt automatische Schutzmechanismen, die in Webbrowsern oder -Clients eingebaut sind. Dabei kann die Software untersuchen, ob der Nutzer eine Webseite besucht, deren URL (Uniform Resource Locator) bestimmte Schlüsselwörter enthält, oder ob die Seite von anderen Benutzern bereits als verdächtig gemeldet wurde. Ebenfalls können Zertifikate erkannt werden, die von keiner offiziellen und vertrauten Zertifizierungsstelle unterschrieben wurden.? beschreiben dazu, die Gründe, warum Phishing funktioniert, vgl. dazu auch?. Der beste Schutz vor Phishing-Angriffen ist daher immer noch die eigene Wachsamkeit und gesunder Menschenverstand. Es sollte klar sein, dass eine Bank nie nach Daten fragt, die sie entweder schon hat oder die sie nicht benötigt. Ebenso sollte beachtet werden, dass die Orthographie oder Interpunktion in Phishing- s in den seltensten Fällen korrekt ist und sich Phishing- s 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. ontrollaufgabe 1.20: Phishing Was wird unter der Bezeichnung Phishing verstanden und was hat dies mit Spam zu tun?

42 Seite 42 Studienbrief 1 Grundlagen 1.10 Zusammenfassung In diesem Studienbrief wurden die Grundlagen für die folgenden Studienbriefe vermittelt. Beginnend mit einer Definition für s und Spam wurde die Infrastruktur beschrieben, die für den Versand und das Empfangen von s notwendig sind. Die dafür verwendeten Protokolle wurden detailliert betrachtet. Die Motivation der Spammer für den Versand von Spam wurde kurz genannt und zur Veranschaulichung wurde in einer Fallstudie gezeigt, wie Geld mit dem Versand von Spam verdient werden kann und auch wie ohne technische Eingriffe der Versand von Spam reduziert werden kann Übungen Ü Übung 1.1: Nachteile von s Im ersten Abschnitt wurden einige Vorteile von s gegenüber normaler Post aufgeführt. önnen Sie sich vorstellen, dass es auch Nachteile gegenüber normaler Post gibt, außerhalb von Spam? Ü Übung 1.2: Leerzeilen in s Finden Sie heraus, wie eine Leerzeile in einen -Body eingefügt werden kann, ohne dass ein -Programm die Leerzeile als Ende der 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?

43 1.11 Übungen Seite 43 Übung 1.4: SMTP-Sitzung Entspricht die folgende Sitzung der RFC 2821? Falls nein: In welchen Punkten gibt es Abweichungen? Ü 220 m04.aul.t-home.de T-Online ESMTP receiver fssmtpd2025 ready. 220 T-Online ESMTP receiver ready. ehlo meinhost.meinedomain.de 250-mailin04.aul.t-online.de ready. 250-SIZE BITMIME 250-ENHANCEDSTATUSCODES 250 HELP rcpt to: Unknown recipient. mail from: Sender accepted. rcpt to: Hans Mueller Recipient accepted. Data Here goes some data. quit mailin04.aul.t-online.de closing Closing. Connection closed by foreign host. Übung 1.5: POP3-Sitzung Verwenden Sie das ommandozeilenprogramm 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 Ihrer Wahl. Vergleichen Sie den Quelltext der gespeicherten mit dem Quelltext, den Ihnen ein Programm wie Outlook oder Thunderbird zur Verfügung stellt. Was können Sie dabei feststellen? Ü

44 Seite 44 Studienbrief 1 Grundlagen Ü Übung 1.6: Fehlerhafter -Header Betrachten Sie folgende Date: 11 Nov :47:07 Message-ID: <49197ECB hgi.rub.de> From: "Christopher Wolf" <cbw@hgi.rub.de> "Yvonne Roehrle-Schetz" <yvonne.r-s@ruhr-uni-bochum.de>, To: HGI Office <hgi-office@rub.de>, "Mario Rottorf" Mario.Rottorf@ruhr-uni-bochum.de BCC: dip.farmacologia@unipd.it User-Agent: Thunderbird (Windows/ ) MIME-Version: 1.0 Subject: Re: Dienstreise oblenz References: <8E3FF A94BB6A28C05411D310@p76> <8V3Fa01314ABB C05411D310@compi.it> In-Reply-To: <8E3FF A94BB6A28C05411D310@p76> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: a@tv Was genau in dieser entspricht nicht dem Standard? Ü Übung 1.7: Base64-odierung Betrachten Sie Exkurs 1.11 auf Seite 25. 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-odierung: Speicherplatz Berechnen Sie die Menge an Speicherplatz, die eine Zeichenkette der Länge benötigt, wenn diese Base64-kodiert wird. Ü Übung 1.9: Nutzerauthentifikation bei POP3 Betrachten Sie den APOP Befehl von POP3. önnen Sie sich unter der Annahme, dass die vom Server verschickten Zeitstempel nicht einzig sind, einen Angriff vorstellen, bei dem der Angreifer Zugriff auf ein bestimmtes Benutzerkonto erlangt? Ü Übung 1.10: IMAP vs. POP3 Nennen und beschreiben Sie drei Vorteile, die IMAP gegenüber POP3 bietet.

45 1.11 Übungen Seite 45 Übung 1.11: IMAP vs. POP3, mehrere Anmeldungen an das gleiche onto Was kann konkret passieren, wenn sich mehrere Benutzer per POP3 an das gleiche onto 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 angegeben hatte als der empfangende Server unterstützt? Ü Übung 1.13: DNS (Domain Name System) Eine DNS-Anfrage löst einen Namen in eine IP-Adresse auf. Finden Sie heraus, ob es einen Dienst gibt, der zu einer IP-Adresse die damit verbundenen Namen zurückgibt. Warum ist ein solcher Dienst sinnvoll? Ü Übung 1.14: Fallstudie Click Trajectories: End-to-End Analysis of the Spam Value Chain Betrachten Sie? und finden Sie heraus, warum nicht alle der 120 ä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. Ü

46

47 Studienbrief 2 Spam-Techniken Seite 47 Studienbrief 2 Spam-Techniken 2.1 Lernergebnisse Sie können die von Spammern genutzten Infrastrukturen, um Spam zu versenden und apitel 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 Adressen und wie kann man sich als Nutzer dagegen wehren, dass die eigene 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 eingegangen. Als erste Methode zum Versand von Spam werden daraufhin offene Mail-Relays behandelt. Obwohl der Grund für das Vorhandensein dieser Methode ausschließlich darin lag, dass bei der Planung der -Infrastruktur nicht mit dem Missbrauch des Mediums für Spam gerechnet wurde, konnte diese Lücke relativ schnell geschlossen werden. Offene Proxies bieten ähnliche Möglichkeiten zum Versand von Spam an und wurden anfangs auch noch für diesen Zweck missbraucht. Danach werden Mail-Formulare und Webmail behandelt und es wird gezeigt, wie diese Dienste ausgenutzt wurden und auch noch aktuell von Spammern verwendet werden. Im Abschnitt über IP Prefix Hijacking wird eine erste ausgeklügeltere Methode zum Versand von Spam vorgestellt, bevor die Abschnitte über Malware und Botnetze den größten Ursprung von Spam beschreibt. 2.4 Spammer Ursprünglich wurden Spam-Nachrichten von einzelnen Personen aus verschickt, die dabei sehr einfache Techniken nutzten bzw. einfache Schwachstellen in Spezifikationen ausnutzten, wie im späteren Verlauf dieses Studienbriefs deutlich wird. Um das Thema Spam hat sich aber, nachdem Spam als Problem erkannt wurde, eine Industrie entwickelt, die jährlich Milliardenumsätze verbucht. Dazu zählen auf der einen Seite Firmen, die Produkte entwickeln oder Dienstleistungen anbieten, um Spam-Nachrichten zu erkennen, um diese daraufhin zu filtern, auszusortieren ROSO

48 Seite 48 Studienbrief 2 Spam-Techniken 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 nown Spam Operations (ROSO)) gibt, das vom Spamhaus-Project gepflegt wird und Informationen zu verschiedenen Gruppen auflistet, die sich um den Versand von Spam kümmern. Auf die Liste kommen nur Gruppen, die bereits durch mindestens drei Internet Service Provider (ISP) als Spammer erkannt wurden und deren Aktivitäten daraufhin durch diese ISPs beendet wurde. Aktuell listet das Register 115 verschiedene Gruppen auf, die aus Ländern verteilt über den gesamten Globus fungieren. Das Spamhaus-Project gibt weiterhin an, dass ca. 100 Gruppen für etwa 80 % des Spamaufkommens in Nordamerika und Europa verantwortlich sind und fast alle dieser Gruppen in dem Register aufgelistet sind Spammer-Netzwerke Es ist klar, dass Spammer die -Infrastruktur verwenden, um Werbenachrichten zu verschicken. Es stellt sich aber die Frage, wie die sonstige Infrastruktur von Spamversender genau aufgebaut ist, damit ihr Geschäft möglichst effektiv arbeitet. In? 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öglicher Aufbau eines Spammer-Netzwerkes (angelehnt an?). Längerfristige Infrastruktur Bullet-Proof Server, Bankkonten in sicheren Ländern Partner Affiliates (Freie Mitarbeiter) Spamversand, Harvesting usw. usw. Gewinnbeteiligung Hauptspammer Adressdatenbank An/Verkauf von Adressen Ankauf von Produkten und oordination des Produktversands nach erfolgtem auf Anmieten / auf von Botnetzen zum Mailversand undenaufträge für Marketing Adress- Händler und andere Spammer Produzenten und Versand- Dienstleister Botnetzbetreiber Serviceanbieter äufer Adressdatenbank

49 2.4 Spammer Seite 49 Im Mittelpunkt der Abbildung steht der Hauptspammer, der zwei Ressourcen benötigt. Das ist zum einen eine Adressdatenbank, die mit -Adressen von möglichen Empfängern gefüllt ist. Idealerweise enthält die Adressdatenbank nicht nur die -Adressen der Empfänger, sondern auch weitere persönliche Informationen wie Namen, Alter und ggf. Interessen. Diese persönlichen Informationen können für den Hauptspammer wichtig sein, wenn er seine Werbebotschaften an die richtige Zielgruppe versenden möchte. Die Adressdatenbank ist für den Hauptpammer eine Ressource, die er nutzt, um Spam zu versenden, aber auch gleichzeitig kann diese Datenbank direkt ein Einkommen erzeugen, indem Adressen an andere Spammer oder Adresshändler verkauft werden. Um über eine möglichst große Basis an Adressen zu verfügen, müssen entsprechend auch Adressen von anderen Spammern oder Adresshändlern angekauft werden. Adressen können vom Hauptspammer auch direkt gesucht werden. Wie dies geschieht, wird im folgenden Abschnitt beschrieben. Als zweite Ressource muss der Hauptspammer über längerfristige Infrastrukturen verfügen. Dies sind Server, auf denen verschiedene Shops betrieben werden, die wiederum der Anlaufpunkt für interessierte unden sind. Erhält ein Empfänger eine Spam-Nachricht und interessiert sich für das beworbene Produkt, so folgt er einem Link zum Shop des Versenders. An dieser Stelle wäre ein Eingriff in die Infrastruktur des Spammers für die Justiz einfach. Es würde ausreichen, wenn diese Server vom Internet getrennt würden, wodurch der Spammer die Möglichkeit verlieren würde, einen Gewinn zu erwirtschaften. Aus diesem Grund suchen und betreiben Spammer sogenannte Bullet-Proof-Server. Dabei handelt es sich um Server, die bei Betreibern stehen, die wiederum nicht mit der Justiz zusammen arbeiten. Dies können Server in Nordamerika oder Europa sein, die sich nicht einfach vom Netz trennen lassen, da deren Hoster mit den Spamversendern und nicht der Justiz zusammenarbeiten. Erst wenn alle Verbindungen zum Netz dieser Betreiber getrennt sind, kann der Bullet-Proof-Server nicht mehr erreicht werden. Neben der eigenen Infrastruktur beschäftigt ein Hauptspammer freie Mitarbeiter, sogenannte Affiliates. Diese freien Mitarbeiter können sowohl für den Versand von Spam als auch für das Sammeln von -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 ontakt 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 oordination des Produktversandes nach einem erfolgten auf benötigt ein Spamversender ontakt zu den Produzenten der Produkte sowie zu Versanddienstleistern, die sich um den Transport vom Produzent zum unden kümmern. Diese interagieren dann mit den ä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 ontakt tritt, die ihn beauftragen, bestimmte ampagnen zu betreiben. Somit vermietet der Hauptspammer seine Ressourcen an andere Anbieter. Adressdatenbank, Bullet- Proof-Server Affiliate, Botnetz Neben ihrer üblichen Infrastruktur und ihrer eigenen ontakte haben viele Spammer allerdings auch noch ontakte zu anderen Spammern. Die können dann als Partner eine vergleichbare Infrastruktur aufweisen und bei komplexen Aufträgen helfen.

50 Seite 50 Studienbrief 2 Spam-Techniken Adress-Harvesting Der Versand von Spam ist für Spammer denkbar einfach. Nachdem im vorherigen Abschnitt vorgestellt wurde, wie die Infrastruktur vom Spamversender aufgebaut ist, stellt sich allerdings noch die Frage, wie genau Spammer ihre - Adressdatenbanken füllen. Allgemein wird das Suchen von -Adressen als Adress-Harvesting bezeichnet. Für das Adress-Harvesting gibt es unterschiedliche Techniken bzw. Methoden, die im Folgenden näher beschrieben werden. Ankauf oder Tausch Die einfachste Methode ist sicherlich der Ankauf von Adresshändlern, anderen Spammern oder Serviceanbietern. Dabei ist die günstige Methode der Austausch mit anderen Spammern. Doch insgesamt muss es eine Quelle für korrekte und und aktuelle -Adressen geben, egal ob gekauft oder getauscht wird. Dazu stellen die folgenden Abschnitte verschiedene Techniken vor. Harvesting Bots Oft benutzen die Versender von Spam Botnetze, damit sie auf der einen Seite eine Vielzahl an Spam-Nachrichten verschicken können und es auf der anderen Seite schwer möglich ist, den Spam aufgrund der IP-Adresse des Versenders zu identifizieren. Genau diese Bots können auch dazu genutzt werden, -Adressen zu sammeln. Dabei können die Bots sowohl sich selber, also den Inhalt des infizierten Computers durchsuchen. So finden die Bots bspw. Adressbücher aus -Programmen. Andererseits können die Bots aber auch auf der Suche nach potenziellen -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 -Adressen. Diese -Adressen können sich innerhalb von HTML-Dokumenten befinden, genauer gesagt, können es Seiten von Foren sein, bei denen Mitglieder ihre -Adresse zur ommunikation hinterlassen. Es können weiterhin auch Webseiten von Firmen sein, die ein Impressum verfassen müssen und dort eine -Adresse angeben oder auch generelle ontaktdaten, 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 -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 -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 -Adressen zu gelangen, ist der sogenannte Directory-Harvest-Angriff. Hierbei gibt es zwei mögliche Techniken, um Listen von potenziellen -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 ombinationen dann eine bestimmte Domäne an. Der Nachteil bei dieser Methode besteht darin, dass die Liste sehr schnell sehr groß wird. Werden bspw. Nutzernamen mit einer Länge von genau vier Zeichen erstellt und dabei nur die Buchstaben von A bis Z und die Zahlen von 0 bis 9 verwendet, so entsteht eine Basis von

51 2.4 Spammer Seite Zeichen, die mit der Länge vier potenziert wird. Alleine bei diesem kurzen Benutzernamen entstehen bereits ,7 Millionen verschiedene ombinationen. Die zweite Möglichkeit, eine solche Liste zu erstellen, besteht darin, geläufige Vornamen, Nachnamen und Initialen sinnvoll zu verbinden. So entstehen bspw. -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 -Adressen erzeugt, die im weiteren Verlauf auf ihre orrektheit hin analysiert werden müssen. Eine Analyse besteht dabei aus einer einfachen Verbindung zum entsprechenden -Server und dem Versuch, eine Test- an das geratene onto zu verschicken. Diese Test- enthält im Normalfall noch keine Werbebotschaften, damit keine Filter anschlagen. Der Erfolg des Directory-Harvest-Angriffs beruht nun einzig und alleine darauf, dass -Server eine Information an den Versender einer Nachricht schicken, sofern sie eine Nachricht empfangen haben, die an ein nicht vorhandenes onto gerichtet war. Es existieren dementsprechend Implementierungen, die eine solche Nachricht nicht verschicken, womit prinzipiell alle geratenen -Adressen für den Angreifer als valide erscheinen. Würde die Test- bereits eine Werbebotschaft enthalten, so könnte der empfangende -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. ostenlose Produktangebote Eine weitere Möglichkeit, um an -Adressen zu gelangen, sind kostenlose Produktangebote. Hier existieren Dienstanbieter, die kostenfreie Leistungen anbieten und dafür die -Adresse des potenziellen unden benötigen. Egal ob die Leistung dann später wirklich erbracht wird oder nicht, die einmal eingetragene -Adresse ist dann bereits in die Adressdatenbank des Anbieters eingetragen worden und dient daraufhin sicherlich als Empfängeradresse für Spam Anti-Harvesting-Methoden Entsprechend der im vergangenen Abschnitt beschriebenen Harvesting-Methoden existieren wiederum Methoden, um den Adresssammlern das Sammeln zu erschweren. Ein vollständiges Verhindern des Adresssammelns ist oft nicht möglich, da eine -Adresse für eine ommunikation benötigt wird und für einen gutartigen Zweck zur Verfügung stehen sollte. Daher erschweren die im Folgenden vorgestellten Techniken das Sammeln nur. Bilder Anstelle von Text-basierten Informationen ist es ebenso möglich, eine in Form eines Bildes innerhalb einer Internetseite zu speichern. Für einen menschlichen Besucher, der eine ommunikation aufbauen möchte, ist das Bild im Gegensatz zum Text zuerst kein Unterschied, da es dieselben Informationen präsentiert. Einziger Nachteil besteht darin, dass der Besucher die -Adresse nicht direkt in sein -Programm kopieren kann, sondern sie abtippen muss. Der Vorgang des Abtippens ist zum einen aufwendiger und zum anderen fehleranfälliger, wodurch die ommunikation 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

52 Seite 52 Studienbrief 2 Spam-Techniken anpassen, dass auch Bilder per Texterkennung durchsucht werden und somit trotzdem an die -Adresse gelangen. Je ausgeklügelter die Adresse also innerhalb des Bilds verschleiert wird, je besser ist sie vor Adresssammlern geschützt. CAN-Spam-Hinweise CAN-SPAM ist ein Akronym für ein in den USA im Jahre 2002 beschlossenes und im Jahre 2003 in raft 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 unden versichern, dass sie die -Adressen, die sie von ihren unden erhalten, nicht an Dritte weitergeben. Dieser Hinweis ist in europäischen Ländern eher selten, da das genannte Gesetz nur in den USA gilt. CAPTCHAs Um -Adressen nur für Menschen sichtbar zu machen, eignen sich auch CAPTCHAs. Der Begriff CAPTACH steht für Completely Automated Public Turing test to tell Computers and Humans Apart. Dabei kann es sich um visuelle CAPTACHAs handeln, also Bilder, die bestimmte Informationen enthalten, die für Menschen leicht und für Maschinen besonders schwer zu entnehmen sind (vgl. Abbildung 2.2). Innerhalb dieser Abbildungen kann dann bspw. die Information direkt enthalten sein, genauso ist es aber auch möglich, dass die Abbildung eine Aufgabe zeigt, deren Ergebnis in ein entsprechendes Feld eingetragen werden muss. Oftmals werden Zeichenketten verwendet, die bedingt durch einen bunten Hintergrund nicht einfach mit Texterkennungssoftware entdeckt werden können. Als weitere Möglichkeit zur Verschleierung kommen auch verzerrte Zeichenketten vor. Bei visuellen CAPTCHAs können auch einfache mathematische Aufgaben zu lösen sein oder bestimmte Dinge gezählt werden. Hier bietet es sich bspw. an, verschiedene Tierarten innerhalb von einem Bild zu bestimmen. Es kann sich aber auch um akustische CAPTCHAs handeln, bei denen die Informationen gehört werden müssen. Bei akustischen CAPTCHAs wird oft gesprochene Sprache abgespielt, die Zahlen enthält, die wiederum durch ein starkes Hintergrundrauschen verschleiert werden. Abb. 2.2: Ein von Google erzeugtes CAPT- CHA, das zur Erstellung eines -ontos gelöst werden muss. Insgesamt können CAPTCHAs allerdings nur solange automatische Adresssammler abhalten, solange diese nicht entsprechend angepasste Software verwenden, da auch Programme dazu angelernt werden können, grafische oder auch akustische CAPTCHAs zu lösen. Das größte Problem in diesem Bereich besteht darin, dass ausgeklügelte CAPTCHAs nicht nur für Maschinen immer schwerer zu erkennen sind, sondern auch für Menschen, die eigentlich bei der Lösung kein Problem haben

53 2.4 Spammer Seite 53 sollten. Außerdem kann das Lösen von CAPTCHAs zur Not auch in Niedriglohnländer ausgelagert werden, womit ein CAPTCHA zwar nicht mehr automatisch gelöst werden kann, jedoch für einen relativ kleinen Betrag überwunden werden kann. -Adressen-Verfälschung Eine weitere Möglichkeit, um eine -Adresse vor dem automatischen Sammeln zu schützen besteht darin, die -Adresse an sich zu verfälschen. Diese als Address Munging bekannte Technik ist einfach zu nutzen. Hier werden bspw. bestimmte Teile der -Adresse durch andere Informationen ersetzt. wird z. B. durch die Zeichenkette <at> ersetzt, der Punkt durch <dot> oder ein Bindestrich durch <minus>. Diese Textersetzungen sind jedoch nur so lange hilfreich, bis die Adress-Harvester auch auf konkrete Ersetzungen reagieren. So können die regulären Ausdrücke, die verwendet werden, um Webseiten nach -Adressen zu durchsuchen, soweit angepasst werden, dass auch -Adressen mit oben beschriebenen Ersetzungen erkannt werden. -Server-Überwachung Anti-Harvesting-Methoden können ebenfalls bei der -Server-Software ansetzen. So können -Server so implementiert werden, dass sie bspw. keine s von einem Absender mehr annehmen, sobald dieser eine an eine nicht vorhandene Adresse verschickt hat. Dies verursacht allerdings die Gefahr, dass reguläre s auch nicht mehr angenommen werden, sobald jemand bei der Eingabe einer -Adresse einen Fehler gemacht hat und die Empfängeradresse daher nicht existiert. -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 -Adressen übertragen. Diese Technik kann unterschiedliche Aktivitätsgrade verfolgen. Sie lässt sich auf der einen Seite eher passiv nutzen, in dem eine ungenutzte - Adresse auf einer Webseite veröffentlicht wird und kontrolliert wird, ob s an diese Adresse verwendet werden. Auf der anderen Seite kann die Technik aber auch sehr aktiv eingesetzt werden, in dem eine solche -Adresse zur Anmeldung bei einem Dienstanbieter verwendet wird und daraufhin kontrolliert wird, ob von einem anderen Anbieter s 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 -Adresse an andere Anbieter weitergeben. Die konkrete Implementierung dieser Technik wird als Spider Trap bezeichnet, da elektronische Fallen aufgestellt werden, um Adresssammler ausfindig zu machen.

54 Seite 54 Studienbrief 2 Spam-Techniken 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 beschreiben, sodass die Darstellung innerhalb der anzuzeigenden Webseite sich stark vom Quellcode unterscheidet. So können bspw. Elemente wie -Adressen mithilfe von Bildern unterbrochen werden, die eine Breite und eine Höhe von Null Pixeln haben. Somit wird die -Adresse im Quellcode durch ein Element in zwei Teile zerteilt, wirkt aber auf der später zu betrachtenden Webseite so, als wäre sie ohne Unterbrechung angegeben worden. Genauso lassen sich bestimmte Zeichen wie der Punkt oder der Bindestrich durch Bilder ersetzen, die für einen menschlichen Betrachter nicht hinderlich sind, um die vollständige -Adresse zu erkennen, für Programme jedoch nicht direkt erkannt werden können. Diese Methode ist zwar recht schwer durch automatische Programme zu brechen, allerdings kann sie auf für menschliche Benutzer hinderlich sein, da ein Mensch solch verschleierte Adresse nicht direkt mit wenigen Mausklicks kopieren kann, sondern abtippen muss, was letztendlich eine gewisse Fehleranfälligkeit provoziert. Javascript-Verschleierung Als ein wirksames Mittel, um Adress-Harvestern das Sammeln von - Adressen zu erschweren, hat sich eine Verschleierung der -Adressen mithilfe von Javascript herausgestellt. Dabei wird die -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 -Adresse berechnet. Als besonders hilfreich hat sich hier die ROT13-Verschiebechiffre (vgl. Exkurs 2.1 und Exkurs 2.2) herausgestellt.

55 2.4 Spammer Seite 55 Exkurs 2.1: Verschiebechiffre Verschiebeschriffren gehen bis auf den römischen aiser 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 onzept: Jeder Buchstabe k i eines lartextes wird um ein festes ganzzahliges p zyklisch nach rechts verschoben. Das Ergebnis ist dann der Geheimtext. E Etwas formaler gefasst kann die Verschiebechiffre mithilfe der Modulo- Arithmetik beschrieben werden. Die Buchstaben des Alphabets werden fortlaufend durchnummeriert: Die Funktion A = 0,B = 1,...,Z = 25 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 k i mit Verschiebung um p Zeichen ist folgende Funktion zu verwenden: encrypt p (k i ) = buchstabe(zahl(k i ) + p mod 26) Die Entschlüsselung eines Geheimtextes wird durch folgende Funktion für jeden Buchstaben k i einzeln durchgeführt: decrypt p (k i ) = buchstabe(zahl(k i ) p mod 26) Gilt p = 1, so wird die Zeichenkette T EST bspw. in UFTU umgewandelt. Exkurs 2.2: ROT13 ROT13 ist die Abkürzung für rotate by 13 places. Es handelt sich hierbei um eine gewöhnliche Verschiebechiffre (vgl. Exkurs 2.1), bei der p = 13 gilt. Durch die Wahl von p = 13 können für Ver- und Entschlüsselung die gleiche Funktion verwendet werden. E Dabei wird jeder lartext-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 lartext umzuwandeln.

56 Seite 56 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ützung für Java-Script anbieten, wird dann entsprechend eine andere -Adresse als die echte eingesammelt. Im Allgemeinen existiert dann für die eingesammelte -Adresse kein onto und der Versuch, eine Spam-Nachricht an dieses onto zu versenden, wird mit einer Fehlermeldung vom -Server quittiert. ontaktformulare Die letzte hier betrachtete Methode, um Adress-Harvesting zu erschweren bzw. zu unterbinden sind ontaktformulare. Gewerbliche Betreiber von Internetseiten sind auf die ommunikation mit unden angewiesen, um Produkte oder Dienstleistungen zu verkaufen. Daher ist es auch zwingend notwendig, dass unden mit ihnen in ontakt treten können. Um auf der einen Seite nicht eine -Adresse veröffentlichen zu müssen, auf der anderen Seite für den unden aber möglichst einfach erreichbar zu sein, können Formulare innerhalb einer HTML-Seite eingebunden werden, in die ein unde eine Anfrage und seine eigenen ontaktdaten eintragen kann. Das ontaktformular schickt diese Daten dann zwar auch per an den Empfänger, der Versand der geschieht dabei aber Server-seitig und der unde erfährt nicht die -Adresse des Empfängers. So ist es für den Gewerbetreibenden möglich, die Anfrage des unden zu erhalten, ohne seine eigene -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 -Adressen Formulare gezielt nutzen und ihre Werbung darin platzieren. Dies kann dann wiederum durch die Verwendung von CAPTCHAs erschwert werden, wie bereits oben in diesem Abschnitt gezeigt wurde ontrollaufgaben In diesem Abschnitt befinden sich verschiedene ontrollaufgaben, welche die Inhalte der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffes beitragen sollen. ontrollaufgabe 2.1: Spammer-Netzwerk Beschreiben Sie die Infrastruktur, die Spamversender nutzen, um Spam zu versenden. ontrollaufgabe 2.2: Adress-Harvesting Was genau versteht man unter dem Begriff Adress-Harvesting?

57 2.5 Offene Mail-Relays Seite 57 ontrollaufgabe 2.3: Directory Harvest Attack Wie viele verschiedene ombinationen von -Adressen entstehen bei der ersten Technik des Directory Harvest Angriffs, wenn die Länge der Nutzernamen fünf oder wenige Zeichen betragen darf und von einem Alphabet mit 36 Zeichen (A-Z, 0-9) ausgegangen wird? Was passiert, wenn auch Sonderzeichen wie., - und _ erlaubt werden? ontrollaufgabe 2.4: Anti-Adress-Harvesting Welche Methoden gibt es, um Adress-Harvesting zu erschweren oder auszuhebeln? Beschreiben Sie mindestens drei Methoden. ontrollaufgabe 2.5: Adress Munging Erläutern Sie die Adress Munging Technik. ontrollaufgabe 2.6: Verschiebechiffre Zeigen Sie, dass die Funktion encrypt p (x) und decrypt p (x) invers zueinander sind. ontrollaufgabe 2.7: ROT13-Verschiebechiffre Welche Besonderheit hat die ROT13-Verschiebechiffre? 2.5 Offene Mail-Relays Wie bereits im ersten RFC 5321 Studienbrief in Abschnitt ab Seite 21 und Abbildung 1.3 auf Seite 19 dargestellt wird, ist SMTP das wichtigste Protokoll für den Versand von s. Es wird nicht nur verwendet, um s vom Computer des Benutzers zu einem -Server zu versenden, sondern auch um diese s letztendlich zum -Server des Empfängers zu schicken. Diese s 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 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 onfiguration dieses Servers kann dieser die Annahme der mit dem Antwort-Code

58 Seite 58 Studienbrief 2 Spam-Techniken 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 mit dem Status- Code 551 User not local; please try <forward-path> (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 <forward-path>" antwortet (vgl. auch Abschnitt 3.4 aus?). In diesem Fall wird die angenommen, obwohl sich das onto des Empfängers nicht auf diesem SMTP-Server befindet. Im Folgenden wird die dann an den entsprechenden Server weitergeleitet, auf dem jedoch wieder nicht das onto des Empfänger vorhanden sein muss. Dieses Verhalten, bei dem der SMTP-Server eine annimmt, bei der das onto 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 als Nächstes zu senden ist. Ursprüngliche Implementierungen von SMTP waren dabei so konfiguriert, dass sie auch s von unbekannten Servern ohne jegliche Form der Authentifizierung angenommen haben. Es war somit für den Nutzer möglich, anonym eine zu verfassen und unter einer falschen Benutzerkennung direkt an diese offenen Weiterleitungs-Server zu schicken, die diese dann in das -System einschleusten. RFC 2505 Diese Möglichkeit > des -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. ontrollaufgabe 2.8: Offene Mail-Relays Was macht einen SMTP-Server zu einem offenen Mail-Relay? Ein Proxy im Bereich von Computernetzen ist ein Computer, der innerhalb eines oder zwischen verschiedenen Netzen Pakete vermittelt. onkret bedeutet dies im Fall verschiedener Netze, dass Computer A in Netz M mit Computer B in Netz N kommunizieren möchte, es aber keine direkte Route/Verbindung zwischen den beiden Netzen gibt. Ein Proxy kann nun zwischen den beiden Netzen M und N die Pakete von A an B weiterleiten und entsprechend von B an A. Dabei existieren verschiedene Arten von Proxies wie Proxy-Server, generische Proxies, Proxy-Firewalls,

59 2.6 Mail-Formulare Seite 59 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 verwenden und seine IP-Adresse daher verschleiern möchte. Ein reales Einsatzszenario sind bspw. risenregionen, 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 -Versand verwendet werden. Dabei verschickt ein Sender eine 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 ab Seite 74) 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. ontrollaufgabe 2.9: Offene Proxies Wodurch sind offene Proxies definiert? 2.6 Mail-Formulare Mail-Formulare sind nicht RFC 1866 nur eine Anti-Harvesting-Methode (vgl. Abschnitt 2.4.3, Unterpunkt ontaktformulare ab Seite 56), sondern auch eine Methode zum Spamversand. Formulare dienen generell der Erfassung und Verarbeitung von verschiedensten Daten. Dies können bspw. Grußtexte für ein Gästebuch oder auch Hinweise an einen Webseitenadministrator sein. Im HTML-Standard wurden ab Version 2 (vgl.?) durch das <form> Schlüsselwort Formulare ermöglicht. Diese Formulare können verschiedene Felder enthalten, die vom Webseitenbesucher ausgefüllt werden können. Exkurs 2.3 auf Seite 60 gibt weitere Informationen zu den Feldern von HTML-Formularen. Der Inhalt kann dann wiederum mithilfe von verschiedenen Methoden, in HTML Version 2 ausschließlich METHOD=GET oder METHOD=POST, an den Webserver zur weiteren Verarbeitung übertragen werden. Die Verarbeitung auf dem Webserver wird separat implementiert. So ist eine Implementierung denkbar, welche die im Formular angegebenen Daten an eine bestimmte - 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 -Client eine 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.

60 Seite 60 Studienbrief 2 Spam-Techniken ontrollaufgabe 2.10: Mail-Formulare Fassen Sie mit wenigen Worten zusammen, wie Mail-Formulare zum Versand von Spam missbraucht werden können. Gehen Sie dabei explizit auf die Voraussetzungen ein, damit ein Spamversand überhaupt möglich ist. E Exkurs 2.3: Felder in HTML Formularen Der HTML Standard in Version 4 erlaubt verschiedene Arten von Formularfeldern. In diesem Exkurs werden die verschiedenen Felder vorgestellt. check box Dieses Feld wird verwendet, um vom Benutzer eine ja/nein- Auswahl zu erhalten. Damit können Informationen abgefragt werden, wie bspw. die Auswahl eines Newsletter-Empfangs. file select Mit diesem Feld erhält der Benutzer einen Auswahldialog für Dateien. Hiermit können z.b. Bilder hochgeladen werden. radio button Diese Felder sind nur in Gruppen von mindestens zwei Elementen sinnvoll. Mit solchen Feldern kann eine von verschiedenen Optionen ausgewählt werden, wobei alle Informationen durchgehend dargestellt werden. Eine sinnvolle Möglichkeiten zur Nutzung ist bspw. die Abfrage, ob ein Benutzer männlich oder weiblich ist reset button Dieses Feld wird im Browser als nopf dargestellt, der zur Entfernung der eingegebenen Daten zuständig ist. Es werden daraufhin die vorher definierten Standardwerte wiederhergestellt. select list Mithilfe der select list kann der Nutzer aus einer ausklappenden Liste ein Element auswählen. Je nach onfiguration ist auch eine Mehrfachauswahl möglich. submit button Diese Feld wird im Browser als nopf dargestellt, der den Browser dazu veranlasst, die im Formular angegebenen Daten mithilfe der durch das Formular definierten Methode zu verarbeiten. Im Allgemeinen besteht die Verarbeitung aus einem Transfer der Daten zum Server, der diese dann weiter bearbeitet. text area Ein text area ist ein Feld, in das Text eingetragen werden kann. Im Gegensatz zum nächsten Formularfeld, der text box, ist es allerdings 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 ennzeichnung 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.

61 2.7 Webmail Seite Webmail Webmail ist ein Dienst, der von unterschiedlichen Anbietern zur Verfügung gestellt wird, um eine -ommunikation ohne eigenen -Client zu ermöglichen. Dazu benötigt der Benutzer als Clientsoftware ausschließlich einen Browser, um den Dienst im WWW zu erreichen. Die gesamte ommunikation 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 dem Nutzer zur Verfügung. Der Nachteil des Dienstes besteht darin, dass s 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 s 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. RFC 1945, RFC 2616, RFC 2854 In diesem ontext müssen nun aber zwei Fragen untersucht werden. Zum einen muss geklärt werden, warum Webmail überhaupt zum Spamversand verwendet wird. Zum anderen ist interessant, wie Webmail zur Quelle von Spam wird. Beide Fragestellungen werden im folgenden Abschnitt geklärt. Wie bereits in den vorherigen Abschnitten beschrieben, existieren viele Möglichkeiten zum Versand von Spam, die auf Fehlern der ursprünglichen Implementierungen von Protokollen basieren, bzw. auf dem zum Zeitpunkt der Entwicklung nicht vorhandenen und auch nicht nötigen Sicherheitsbewusstseins. Daher lässt sich die Frage nach dem Warum leicht beantworten: Nachdem mehr und mehr Lücken geschlossen wurden und der Versand von Spam immer schwieriger wurde, wurden von den Versendern von Spam Möglichkeiten gesucht, Spam über andere Transportwege in das -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 - onten. Diese können auf der einen Seite durch Phishing (vgl. Abschnitt 1.9 ab Seite 41) von anderen Benutzern übernommen werden. Eine zweite Möglichkeit besteht darin, mithilfe von Botnetzen (vgl. Abschnitt 2.9 ab Seite 63) neue onten 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 onten 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 s 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 s in Spam und Ham klassifizieren. Dazu zählen bspw. Listenverfahren wie White-, Black- und Greylisting (vgl. Abschnitt 3.5 ab Seite 74) sowie entsprechende Reputationsverfahren (vgl. Abschnitt 3.6 ab Seite 81). Andererseits versuchen Webmail-Anbieter den angebotenen Dienst entsprechend

62 Seite 62 Studienbrief 2 Spam-Techniken gegen Spam-Bots abzusichern. Dazu werden auf der einen Seite CAPTCHAs verwendet, die bei der Anmeldung sicherstellen sollen, dass sich wirklich ein Mensch und nicht ein automatisiertes Programm anmeldet. Auf der anderen Seite werten Anbieter wie Google auch die IP-Adresse des anmeldenden Computers aus, um zu überprüfen, aus welchem Land sich ein Benutzer anmeldet. Hat sich ein Benutzer immer aus demselben Land angemeldet, so ist bei einer erneuten Anmeldung aus einem anderen Land z.b. eine andere Aufgabe zu lösen, damit sichergestellt werden kann, dass das onto nicht von Dritten kompromittiert wurde. ontrollaufgabe 2.11: Webmail I Was ist Webmail und wie unterscheidet sich der Dienst vom klassischen -Verfahren? ontrollaufgabe 2.12: Webmail II Nennen Sie jeweils zwei Vor- bzw. Nachteile von Webmail. 2.8 IP Prefix Hijacking RFC 4271 Das Internet als globales Netzwerk besteht aus vielen noten. Jeder dieser noten verfügt über eine eigene IP-Adresse. Dieser Sachverhalte wird in Abschnitt ab Seite 34 genauer beschrieben. Damit ein Paket sein Ziel erreicht, wird es an jedem noten 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 ommunikation 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 riterium. Es wird davon ausgegangen, dass wenn bereits viele s aus einem bestimmten autonomen System als Spam klassifiziert wurden, dass die Spam-Wahrscheinlichkeit einer von einer anderen IP-Adresse aus dem gleichen autonomen System deutlich

63 2.9 Malware / Botnetze Seite 63 größer ist. Gründe dafür sind leicht zu finden: Computer, die sich im gleichen autonomen System befinden, werden auch oft von derselben Instanz gewartet. Auf ihnen läuft die gleiche Software und insbesondere sind die Softwareversionen auf den einzelnen Rechnern gleich. Wurde nun einer der Rechner aus einem autonomen System mit Malware (vgl. Abschnitt 2.9 ab Seite 63) 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 Angriff durchzuführen. Zum einen kann ein autonomes System anderen autonomen Systemen mitteilen, dass es ein Präfix beinhaltet, obwohl dies gar nicht der Fall ist. Zum anderen kann ein autonomes System auch ankündigen, dass es über eine kürzere Route zu einem bestimmten autonomen System verfügt und Pakete über dies autonome System geleitet werden soll, obwohl die Route eigentlich länger ist. In beiden Fällen werden Pakete durch das autonome System geleitet, die eigentlich einen anderen Weg gehen sollten. Dies ist soweit noch kein Problem, sofern die Pakete einfach eine andere Route gehen. Es ist nun aber für das kompromittierte autonome System möglich, auch Pakete selber zu erstellen und als Quelle das entführte autonome System anzugeben. Somit können auch s 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 s aufgrund ihres Ursprungs nicht als Spam klassifizieren.? greifen in einer Untersuchung diesen Sachverhalt auf. Sie finden dabei bspw. auch heraus, dass eine lassifikation nach Netzwerkeigenschaften bessere Ergebnisse innerhalb ihrer Studie liefert, als eine auf dem Inhalt basierende lassifikation. Im nächsten Abschnitt wird auf den aktuell am meisten verbreiteten Ursprung von Spam eingegangen, die sogenannten Botnetze. ontrollaufgabe 2.13: IP Prefix Hijacking Wie funktioniert das IP Prefix Hijacking? 2.9 Malware / Botnetze Als letzte Technik werden in diesem Studienbrief Malware und die damit in direktem Zusammenhang stehenden Botnetze behandelt. Malware (vgl. Definition 2.1) ist ein unstwort, das aus den beiden Begriffen malicious (dt. schädlich) und Software zusammengesetzt ist. Es handelt sich bei Malware also um schädliche oder schadhafte Software. Dabei ist die Unterscheidung zwischen Goodware, also gutartiger Software, und Malware nicht trivial für den Benutzer, da er die Funktionalität einer Software nur durch deren Ausgabe erkennen kann. Was eine Software allerdings im Hintergrund macht, ist für ihn nicht direkt ermittelbar. Um zu erkennen, ob es sich bei einer Software um Malware oder Goodware handelt, werden

64 Seite 64 Studienbrief 2 Spam-Techniken verschiedene Techniken eingesetzt, die sich grob in die statische und die dynamische Analyse gliedern. Bei der statischen Analyse von Software wird der Binärcode betrachtet und es werden Merkmale extrahiert wie bspw. Dateigröße, Entropie und die enthaltenen Bytefolgen. Bei der dynamischen Analyse wird die Software hingegen ausgeführt und es wird das Verhalten der Software protokolliert. Zum Verhalten zählen bspw. Syscalls, also Aufrufe, die vom System abgearbeitet werden oder auch Netzwerkverbindungen, die zu bestimmten Servern aufgebaut werden. Anhand des dabei entstehenden Protokolls kann dann geprüft werden, ob das Verhalten der Software entweder verdächtig ist, oder es vielleicht sogar schon eine Software mit ähnlichem Verhalten gab, die als Malware klassifiziert wurde. Da die Analyse von Malware allerdings ein sehr komplexes Thema ist, wird sie hier nicht weiter vertieft. Wichtig bleibt zu behalten, dass Malware Software ist, die einem schadhaften Zweck dient. D Definition 2.1: Malware Angelehnt an? wird Malware durch die folgenden drei Charakteristika definiert: Selbstreplikation Die Schadsoftware verbreitet sich entweder aktiv, indem bspw. opien des ausführbaren Codes auf andere Systeme transferiert werden oder passiv, indem der Benutzer die Schadsoftware versehentlich kopiert. Populationswachstum Die Gesamtzahl der Instanzen der Schadsoftware steigt bedingt durch die Selbstreplikation. Parasitismus Schadsoftware hängt sich an oder vermischt sich mit anderem ausführbaren Code, um unentdeckt zu bleiben. Infolgedessen kann es auch zu einem Populationswachstum kommen. Auch eine passive Selbstreplikation ist denkbar, sobald der Anwender opien des Codes, mit dem sich die Schadsoftware vermischt hat, auf anderen Systemen nutzt. Da der Zweck von Malware auch der Versand von Spam sein kann, ist das Studium von Malware auch wichtig für das vorliegende Modul. Es wird hier allerdings nur ein sehr grober Überblick darüber gegeben, wie sich Malware verbreitet und warum Malware für den meisten weltweiten Spam verantwortlich ist. Wie schon weiter oben beschrieben, repliziert sich Malware entweder aktiv oder passiv. Die passive Selbstreplikation ist jedoch auf eine Benutzerinteraktion angewiesen, die im Gegensatz zur aktiven Selbstreplikation sehr langwierig sein kann. Deshalb setzt aktuelle Malware auf eine aktive Selbstreplikation. Dazu werden Sicherheitslücken in Server- und auch Client-Software gesucht, über die Schadcode eingeschleust werden kann. So ließen sich in der Vergangenheit oftmals Standarddienste von Windows Betriebssystemen missbrauchen, um Zugriff auf ein System zu bekommen. Der eingeschleuste Schadcode enthält oft allerdings nicht die Malware selbst, sondern dient nur dazu, die Malware nachzuladen, um sie daraufhin auszuführen. Wurde die Malware erfolgreich nachgeladen, so verfolgt sie generell zwei Ziele. Zum einen versucht sie sich weiter zu replizieren. Dazu sucht sie nach Sicherheitslücken auf anderen an dasselbe Netzwerk angeschlossenen Computern. Zum anderen kann sie dann ihre Schadfunktion ausführen. Bei aktueller Malware existiert allerdings nicht eine einzige definierte Schadfunktion. Vielmehr verbindet

65 2.9 Malware / Botnetze Seite 65 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 ommunikationsstrukturen. Generell können diese in zentrale und dezentrale Strukturen unterteilt werden. Der ommunikationskanal wird dabei als Command and Control (C&C)-Struktur bezeichnet. Eine zentrale Struktur verfügt über einen oder wenige Server, die vom Botmaster betrieben werden und viele Bots, die ihre Befehle direkt von den Servern beziehen. IRC Eine der ersten genutzten Techniken, um einen C&C-anal 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 ommunikation von Menschen gedacht, eignet sich IRC auch zur ommunikation zwischen Botmaster und den einzelnen Bots. Dabei bietet die ommunikation ü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 ommunikationen durch unterschiedliche anäle voneinander getrennt werden können. Weiterhin bietet IRC die Möglichkeit zur ommunikation 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 ommunikation über einen Webserver per HTTP (vgl.? und?). Die ommunikation 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 ommunikation 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-anal 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.

66 Seite 66 Studienbrief 2 Spam-Techniken Sowohl bei IRC als auch bei HTTP und FTP besteht jedoch das Problem, dass die Bots wissen müssen, an welche IP oder welche Domain sie sich verbinden müssen. Diese Information muss der Bot haben, bevor er sich das erste Mal mit einem C&C-Server verbindet. Daher ist oft eine Reihe von Zieladressen bereits fest im Quellcode des Bots implementiert. Behörden haben die Möglichkeit, einzelne Server zu sperren, wodurch sich die Bots nicht mehr mit dem Botmaster verbinden können und somit auch keine weiteren Befehle mehr erhalten. Sind dem Bot mehrere Adressen bekannt, so kann er zumindest versuchen, auf andere anäle auszuweichen. Trotzdem besitzt dieses zentrale ommunikationsmodell die Schwachstelle, dass es ausreicht, wenige Server vom Netz zu nehmen, um die gesamte ommunikation zu stoppen. Aus diesem Grund wird immer öfter das im nächsten Abschnitt vorgestellte Peer-to-Peer-Modell verwendet. Peer-to-Peer Beim Peer-to-Peer-Modell wird generell keine zentrale Instanz eingesetzt. Es existieren zwar auch zentralisierte Peer-to-Peer-Systeme, jedoch bieten diese die gleiche Schwachstelle wie die in den vorherigen Abschnitten vorgestellten Systeme. Das Modell ist durch unzählige Tauschbörsen im Internet bekannt geworden, bei denen oft auch illegale Inhalte zwischen verschiedenen Benutzern (oberflächlich anonym) ausgetauscht werden. Wird dieses Modell zur ommunikation 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 ommunikationsmodell liegt ganz klar in der Ausfallsicherheit. Wird ein einzelner Bots aus dem Netz entfernt, so funktioniert das Netz immer noch ohne Einschränkungen. Daher ist es deutlich schwieriger, ein auf dem Peer-to-Peer-Modell basierendes Botsnetz zu deaktivieren. Sind mehrere Bots unter der ontrolle 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 s verwendet. Genauso können Botnetze zum Adress-Harvesting verwendet werden. Dies kann entweder geschehen, indem die Bots wie Suchmaschinen das Internet nach Adressen durchsuchen, oder sie können auch auf dem befallenen Computer nach Adressen suchen. Indem bspw. Adressbücher von -Programmen verwendet werden, kann sichergestellt werden, dass echte Adressen gefunden werden, die einen höheren Wert haben als andere im WWW gefundene Adressen. Ein weiterer Einsatzzweck von Botnetzen können verteilte Denial-of-Service (DDoS)-Angriffe sein. Hierbei werden an einen Dienst gleichzeitig von vielen verschiedenen Bots so viele Anfragen gestellt, dass der Dienst für reguläre Nutzer nicht mehr verwendbar/verfügbar wird. Weiterhin können entsprechend auch Aktionen ausgeführt werden, die den Benutzer des kompromittierten Rechners betreffen. So können bspw. Werbebanner, die auf Webseiten angezeigt werden, durch die Schadsoftware auf dem Bot ausgetauscht werden. Der Benutzer kann genauso ausspioniert werden. Dies geschieht nicht nur für ontakte des Nutzers auf Basis der in -Programmen vorhandenen -Adressen, sondern ebenfalls für das gesamte sonstige Verhalten des Nutzers. Es können Passwörter für jegliche Webseiten gespeichert und an den Botmaster weiter gegeben werden sowie auch PIN/TAN beim Online Banking oder reditkartennummern 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-

67 2.9 Malware / Botnetze Seite 67 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 Mega-D (vgl.?) ein mögliches Spam-Volumen von mehr als 200 Milliarden Spam- Nachrichten pro Tag. ontrollaufgabe 2.14: Malware Benennen und beschreiben Sie die drei wesentlichen Eigenschaften, die Malware auszeichnen. ontrollaufgabe 2.15: Botnetz I Woraus besteht ein Botnetz? ontrollaufgabe 2.16: Botnetz II Welche ontrollstukturen existieren für Botnetze? Beschreiben Sie dabei für die einzelnen Strukturen jeweils Vor- und Nachteile. ontrollaufgabe 2.17: Botnetz III Begründen Sie, dass die Anzahl der verbundenen Bots per IRC eine feste Größenbeschränkung aufweist. Warum ist dies bei einer ommunikation per HTTP nicht der Fall? ontrollaufgabe 2.18: Botnetz IV Für welche Zwecke werden Botnetze neben der Verbreitung von Spam verwendet?

68 Seite 68 Studienbrief 2 Spam-Techniken 2.10 Zusammenfassung Der Fokus dieses Studienbriefs lag auf den verbreiteten Spam-Techniken. Dabei wurde beginnend vorgestellt, wie Spammer-Netzwerke aussehen und welche verschiedenen Verknüpfungen zu anderen Instanzen notwendig sind. Daraufhin wurden offene Mail-Relays besprochen und beschrieben, wie es zum anonymen Versand von Spam über diese Strukturen kommen konnte. Die danach angesprochenen offenen Proxies waren dann eine generelle Möglichkeit, um anonym Spam zu verschicken, bevor der Abschnitt über Mail-Formulare diese Möglichkeit zum Versand von Spam aufbereitete. Webmail als professionelle aber eigenständige Ausprägung von Mail-Formularen wurde daraufhin behandelt. Um fremde 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 Studienbrief gestellten ontrollaufgaben aufgeführt, bevor Abschnitt 2.11 ab Seite 68 die Übungsaufgaben auflistet Ü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 -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 -Adressen der Autoren. Gibt es auf diesen Seiten irgendwelche Schutzmechanismen? Falls ja: Wie äußern sich diese? Falls nein: Was könnte zum Schutz der -Adressen eingesetzt/verändert werden?

69 2.11 Übungen Seite 69 Übung 2.4: Directory Harvest Attack Betrachten Sie RFC 5321 (vgl.?) und finden Sie heraus, wie viele Zeichen der Local-Part einer -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 0,1 Sekunde dauert. Ü 1. Wie viele mögliche -Adressen lassen sich daraus generieren? Geben Sie dafür eine Summenformel an und keine konkrete Zahl. 2. Wie lange würde der -Versand an alle so generierten - Adressen dauern, wenn Sie davon ausgehen, dass sie pro - Adresse genau eine versenden? 3. Gehen Sie nun davon ausgehen, dass sie nur eine einzige an alle Adressen versenden wollen und der Rest des -Quellcodes vernachlässigbar klein ist. Wie viele Bytes würde die zu versendende dann enthalten? Übung 2.5: ROT13-Verschiebechiffre I Begründen Sie, warum bei der ROT13-Verschiebechiffre nur eine Funktion sowohl für die Ent- als auch für die Verschlüsselung benötigt wird. Ü Übung 2.6: ROT13-Verschiebechiffre II Welche Methoden können bei der ROT13-Verschiebechiffre verwendet werden, wenn nicht nur Groß- sondern auch leinbuchstaben in einem lartext auftreten? Unter welcher Voraussetzung lässt sich immer noch Modulo 26 rechnen? Ü Ü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 leinbuchstaben 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. Ü

70 Seite 70 Studienbrief 2 Spam-Techniken Ü Übung 2.9: HTML-Formulare Erstellen Sie eine einfache HTML-Seite, die ein Formular zur Eingabe von Vornamen, Nachnamen, -Adresse und ein Textfeld für einen Gruß enthält. Beschreiben Sie, wie diese Daten auf der Serverseite falsch interpretiert werden können, damit eine Quelle für Spam entsteht. Ü Übung 2.10: Shoulder-Surfing Verwenden Sie eine Suchmaschine Ihrer Wahl, um herauszufinden, was Shoulder-Surfing ist und welche Abwehrmaßnahmen es dagegen gibt. Ü Übung 2.11: Malware I Untersuchen Sie welche verschiedenen Arten es von Malware gibt und entscheiden Sie, welche der in Definition 2.1 auf Seite 64 vorgestellten Eigenschaften zu den einzelnen Arten passen. Ü Übung 2.12: Malware II Finden Sie heraus, was Drive-By-Downloads sind. Wie kann diese Art von Malware zum Spam-Versand beitragen? Was kann ein Nutzer tun, um diesen Infektionsvektor zu schließen?

71 Studienbrief 3 Anti-Spam-Techniken Seite 71 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 s 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 zugestellt wird? Dies ist die zentrale Frage dieses Studienbriefs. Es werden verschiedene Ansätze vorgestellt, die etwa Nachrichten klassifizieren oder den Absender einer Nachricht als Spammer erkennen. 3.3 Einleitung Dieser Studienbrief behandelt unterschiedliche Anti-Spam-Techniken. Dabei beginnt Abschnitt 3.4 mit einfachen Filtermethoden, die ausschließlich nach dem Inhalt der Nachrichten klassifizieren. Daraufhin werden in Abschnitt 3.5 IP-Sperren vorgestellt, bei denen nicht der Inhalt für die lassifikation ausschlaggebend ist, sondern der Ursprung, also die IP-Adresse des Senders bzw. die Form der Implementierung des -Clients des Senders. Weiter werden aktuellere Methoden vorgestellt, wie Reputationsverfahren (Abschnitt 3.6) sowie Challenge- und Response-Verfahren (Abschnitt 3.7), die nicht über statisch Listen die s erkennen, sondern unterschiedliche Eigenschaften des Senders zur lassifikation verwenden. Danach werden Erweiterungen des klassischen -Verfahrens vorgestellt, die eine erfolgreiche lassifikation erleichtern sollen (Abschnitt 3.8). Die weiteren Abschnitte beschreiben dann aktuelle Forschungsarbeiten, die sich mit dem Problem Spam auseinandersetzen. Dabei geht es von der Echtzeitfilterung von Spam in Abschnitt 3.9 über die Erkennung (Abschnitt 3.11) und Übernahme (Abschnitt 3.12) von Botnetzen zur automatischen Generierung von Spam-Signaturen (Abschnitt 3.13), bevor eine konkrete Implementierung einer Software zur Spamklassifikation vorgestellt wird (Abschnitt 3.14). 3.4 Mailfilter Die einfachste Art zur Unterscheidung von Nachrichten in Spam und Ham ist die lassifikation durch Filter, wobei die s auf spezifische riterien hin untersucht werden. Filter können sowohl auf den Header als auch auf den Body oder auf beide Teile einer angewendet werden. Sie können auch sowohl auf dem Server als auch im -Client des Nutzers implementiert sein. Dazu werden in diesem Abschnitt zuerst Filter betrachtet, die auf Regeln basieren. Danach solche, die spezielle Signaturen zur lassifikation einsetzen und abschließend werden Bayes-Filter stellvertretend für eine Gruppe von statistischen Filtern besprochen.

72 Seite 72 Studienbrief 3 Anti-Spam-Techniken Regeln Die Regel-basierte Filterung von Spam kann eine Liste von Wörtern oder regulären Ausdrücken verwenden, die in einer nicht vorkommen dürfen. So können Regeln definiert werden, die entweder nur auf den Header, nur auf den Body oder auf die gesamte 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 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 betrachtet. Es geht viel mehr um Eigenschaften der , die diese klassifizieren. Dazu können Hashfunktionen eine kurze Darstellung der berechnen, um diese mit bereits vorhandenen Hashes abzugleichen. Diese Hashes müssen jedoch robust gegen geringe Abänderungen sein, da zufällige Zeichen in s enthalten sein können oder bestimmte Schlüsselwörter, wie weiter oben beschrieben, durch äquivalente Wörter mit anderer Schreibweise ausgetauscht werden. Sind mehrere Signaturen vorhanden, so können diese innerhalb einer Datenbank verwaltet werden, müssen jedoch ständig aktualisiert werden, um den Veränderungen der Spam-Nachrichten zu entsprechen. Die Erstellung einer Signatur muss entweder manuell erfolgen oder es bedarf einer vorherigen lassifikation. Die lassifikation 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 Regelbasierte, jedoch benötigen beide Methoden menschliches Eingreifen, um die Regeln bzw. Signaturen ständig zu erweitern. Aus diesem Grund sind Filter, die wahrscheinlichkeitstheoretische Ergebnisse verwenden und nicht ständig vom Menschen neu trainiert werden müssen, eine sinnvolle weitere Filtermethode. Bayesfilter Für die Filterung von Spam nach statistischen Methoden gibt es verschiedene Ansätze. Die bekannteste Methode geht auf das Bayes-Theorem (vgl. Gleichung 3.1) des Mathematikers Thomas Bayes ( ) zurück, das erstmalig 1998 in? zur lassifikation von Spam verwendet wurde. Für zwei Ereignisse A und B mit P(A) > 0 ist die bedingte Wahrscheinlichkeit (Wahrscheinlichkeit von A gegeben B) P(A B) = P(B A) P(A) P(B) = P(A B) P(B) (3.1)

73 3.4 Mailfilter Seite 73 wobei P(A B) der Wahrscheinlichkeit entspricht, dass die Ereignisse A und B gleichzeitig eintreffen (vgl.?). Das Beispiel 3.1 verdeutlicht die Anwendung des Bayes-Theorems auf Spam- Nachrichten. Beispiel 3.1: Bayes-Theorem Sei A das Ereignis Nachricht ist Spam und B das Ereignis Nachricht enthält die Zeichenkette cheap watch, dann ist P(A B) die Wahrscheinlichkeit, dass eine Nachricht Spam ist, wenn sie die Zeichenkette cheap watch enthält. B Sind s bereits als Spam klassifiziert, von denen 700 die Zeichenkette cheap watch enthalten und weiterhin s als Ham klassifiziert, von denen 2 die Zeichenkette cheap watch enthalten, dann kann P(A B) berechnet werden mit P(A B) = ,72% Weiterhin können dann noch nicht klassifizierte Nachrichten mit einer Wahrscheinlichkeit von 99,72% als Spam klassifiziert werden, sofern sie die Zeichenkette cheap watch enthalten. In der Praxis enthalten s jedoch mehrere Wörter, sodass das Bayes-Theorem auf beliebig viele Zeichenketten z 1,z 2,...,z n erweitert werden muss: P(A z 1 z 2... z n ) = P(z 1 z 2... z n A) P(A). (3.2) P(z 1 z 2... z n ) Dabei beschreibt Gleichung 3.2 die Wahrscheinlichkeit dafür, dass eine als Spam klassifiziert werden kann, wenn sie die Wörter z 1 und z 2 und... und z n enthält. Nach? kann Gleichung 3.2 umgeformt werden zu P(A z 1 z 2... z n ) = i P(z i z i+1... z n A) P(A). (3.3) P(z 1 z 2... z n ) Ein Bayes-Filter wird weiterhin als naïve bezeichnet, sofern er vollständige stochastische Unabhängigkeit zwischen dem Auftreten der einzelnen z i annimmt. In diesem Fall kann Gleichung 3.3 vereinfacht werden zu P(A z 1 z 2... z n ) = i P(z i A) P(A) P(z 1 z 2... z n ). (3.4) Genauso wie die Wahrscheinlichkeit dafür, dass einer Nachricht Spam ist, berechnet werden kann, so kann äquivalent auch berechnet werden, ob es sich bei einer Nachricht um Ham handelt. Diese Tatsache kann für die Lösung einer Übungsaufgabe hilfreich sein. Insgesamt bieten Mailfilter einige Nachteile. Sie sind zwar einfach zu implementieren und zu warten, jedoch sind sie sehr ungenau, sodass eine fehlerhafte lassifikation nicht selten passiert. Dabei sind vor allem die falsch positiven Ergebnisse ein Störfaktor, da reguläre s, 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

74 Seite 74 Studienbrief 3 Anti-Spam-Techniken Ressourcenauslastung. Ist der Filter im -Client installiert, so muss auch zuerst die gesamte 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 wird im nächsten Abschnitt eine Methode vorgestellt, die nicht nur den Inhalt einer Nachricht zur lassifikation verwendet. ontrollaufgabe 3.1: Mailfilter Welche Arten von Mailfiltern gibt es? ontrollaufgabe 3.2: Bayesfilter 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 -Server ist dies nicht anders. Auch der SMTP-Server muss wissen, zu welcher IP-Adresse Antworten geschickt werden müssen. Dabei offenbart die IP-Adresse eines Senders viele Informationen. Zum Beispiel kann über die IP-Adresse herausgefunden werden, aus welchem Land ein ommunikationspartner 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-lassifikation zu verwenden. Insgesamt setzen IP-Sperren also an genau diesem Punkt an. Wurde von einem bestimmten Computer einmal eine Spam-Nachricht verschickt, so wird davon ausgegangen, dass dieser Computer in naher Zukunft auch weiterhin Spam-Nachrichten verschicken wird. IP-Sperren werden über Listen realisiert. Dabei existieren schwarze Listen (engl. Blacklisting, vgl. Abschnitt 3.5.1), die IP-Adressen von Computern enthalten, von denen bekannt ist, dass sie Spam versenden. Weiße Listen (engl. Whitelisting, vgl. Abschnitt 3.5.2) sind davon genau das Gegenteil. Sie werden dazu verwendet, Absender zu identifizieren, die von weiteren Prüfungen komplett ausgeschlossen werden können. Eine Methoden zwischen den beiden genannten Verfahren sind graue Listen (engl. Graylisting, vgl. Abschnitt Hier wird Spam durch technische Schwächen der von Spamversendern genutzten Software erkannt 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

75 3.5 IP-Sperren Seite 75 dann kurzfristig entscheiden, ob der Verbindungsaufbau durch den Versand von Spam motiviert ist, oder ob es sich um eine reguläre Anfrage handelt. Diese Entscheidung kann getroffen werden, indem bspw. auf dem Server eine Datenbank verwaltet wird, die IP-Adressen von Spamversendern enthält. Das nun entstehende Problem ist jedoch, dass ein Großteil des weltweiten Spams nicht von wenigen IP-Adressen (vgl. offene Mail-Relays und offene Proxys in Abschnitt 2.5 ab Seite 57) sondern von Botnetzen (vgl. Abschnitt 2.9 ab Seite 63) 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 hat, ewig auf eine schwarze Liste zu setzen. Das Blacklisting setzt somit eine gewisse Dynamik voraus. IP-Adressen müssen sowohl entfernt als auch hinzugefügt werden können. Wird auf einem Server eine Datenbank eingesetzt, so kann bspw. ein Schwellwert, der die in einem bestimmten Zeitraum erhaltenen s zählt, entscheiden, ob eine IP-Adresse geblockt werden soll. Eine solche dezentrale Lösung birgt aber die Gefahr, dass immer nur Verbindungsversuche von Computern geblockt werden, die bereits vorher vom eigenen Server als Spamversender klassifiziert wurden. Eine sinnvollere Lösung bieten dabei schwarze Listen, die zentrale verwaltet und dann global genutzt werden können. Hierbei können dann auch Spamversender von einem SMTP-Server erkannt werden, die durch eine lassifikation 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 ab Seite 34) 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 , die es zu untersuchen gilt. Er dreht daraufhin die einzelnen Teile der IP-Adresse um und erhält 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 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

76 Seite 76 Studienbrief 3 Anti-Spam-Techniken sein, gerade weil zuerst erkannt werden muss, dass es sich um eine IP-Adresse handelt, die Spam versendet. Genauso können Blacklists ganze IP-Adressbereiche enthalten, die zu ISPs gehören, die von Spammern missbraucht wurden. Hiermit wird dann auch der reguläre -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 ompromittierung 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. Aufgrund der Tatsache, dass Backlists eine hohe Fehlerrate erzielen, wird in? eine Überarbeitung des onzeptes vorgestellt. Hierbei sollen globale Blöcke von IP-Adressen nicht mehr blockiert werden. Genauso soll auch die Reputation ganzer Netze nicht mehr zur lassifikation herangezogen werden. Dagegen wird untersucht, wie gut Spammer erkannt werden können, wenn lokale Faktoren berücksichtigt werden. Dazu werden zwei neue Techniken vorgestellt, zum einen die Verwendung eines dynamischen Schwellwertes und zum anderen eine spekulative Aggregation von IP-Adressen. Abb. 3.1: Der ursprüngliche Ansatz, um Blacklists zu erstellen aus?. Ursprünglich werden Blacklisten erstellt, indem Spam in sogenannten Spam-Traps landet. Spam-Traps sind spezielle -Adressen, die im Internet auf diversen Webseiten verbreitet werden, die jedoch keinen regulären Personen zugeordnet sind und nicht für die normalen ommunikation per verwendet werden. s, die diese Postfächer erreichen, können mit sehr großer Wahrscheinlichkeit als Spam gewertet werden. Die s, die in mehreren Spam-Traps landen können dann gruppiert werden und deren Absenderadressen können daraufhin in eine Blacklist eingetragen werden. Dieses onzept veranschaulicht Abbildung 3.1. Die Autoren schlagen nun vor, das System um bestimmte Eigenschaften zu ergänzen, um die Erkennung von Spam zu verbessern und damit auch bessere Blacklists

77 3.5 IP-Sperren Seite 77 Abb. 3.2: Der neue Ansatz, um Blacklists zu erstellen aus?. zu erstellen. Um Blacklisten zu erstellen, werden normalerweise statische Faktoren verwendet. Haben bspw. 30 % aller verfügbaren Spam-Traps Spam von einer bestimmten IP-Adresse erhalten, so wird die IP-Adresse in die Blacklist eingefügt. Im neuen Ansatz (vgl. Abbildung 3.2) wird aus diesem statischen Schwellwert ein dynamischer Schwellwert. Die Berechnung des Wertes wird verändert, indem auch die Anzahl der s bewertet wird, die von einer IP-Adresse an den lokalen SMTP-Server versendet wurden. Somit fließen nicht nur globale Informationen in den Schwellwert ein sondern auch lokale Informationen. Auf die zweite Eigenschaft des vorgestellten System soll an dieser Stelle nicht weiter eingegangen werden, da sich die Übungsaufgaben mit diesem Thema beschäftigen. Der nächste Abschnitt befasst sich mit einer sehr ähnlichen Technik, dem Whitelisting Whitelisting Das Whitelisting wird ähnlich wie das Blacklisting auch in RFC 5782 (vgl.?) beschrieben. Es handelt sich dabei um eine Technik, bei der eine Liste mit erwünschten IP-Adressen zur lassifikation 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 RFC 5782, DNSWL

78 Seite 78 Studienbrief 3 Anti-Spam-Techniken -Adressen enthalten. Sind diese -Adressen allerdings bekannt, so haben Spammer die Möglichkeit, eine solche Adresse als Absenderadresse in ihre Spam-Nachrichten einzufügen, damit die 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 lassifikation von Spam und Ham eine sehr große Fehlerrate hat. Beim Whitelisting werden alle s, 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 -Adresse nur für die ommunikation mit bestimmten anderen onten vorgesehen, so kann dieses Vorgehen den Spam vollständig beseitigen. Im Normalfall soll die - Adresse aber auch von anderen Nutzern erreichbar sein, was unter ausschließlicher Verwendung des Whitelistings ausgeschlossen ist. Aus diesem Grund sollte das Whitelisting nur in ombination mit dem Blacklisting oder anderen Techniken verwendet werden. Der nächste Abschnitt befasst sich mit der letzten vorgestellten Technik zu IP- Sperren, dem Graylisting Graylisting Obwohl es der Name vermuten lassen könnte, ist Graylisting keine ombination 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 63) stammen. Die Bots wiederum implementieren jedoch nicht die vollständige Funktionalität von SMTP, besonders wird auf eine Fehlerbehandlung verzichtet, um die Implementierung möglichst einfach und schnell zu halten. Genau diesen Mangel macht sich das Graylisting zu nutze, um reguläre s 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 -Header, speichert die IP-Adresse des Senders, die Absender-Adresse aus dem -Header und auch die Empfänger-Adresse aus dem -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 23) 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 -Clients, die SMTP vollständig implementieren, verstehen die Antwort, warten daraufhin eine festgelegte Zeitspanne und versuchen den Versand der erneut. Unvollständig implementierte Bots befassen sich nicht weiter mit dem Versand der Spam-Nachricht an den entsprechenden Empfänger sondern versenden Spam an die weiteren Empfänger in ihrer Liste. Versucht nun der reguläre Sender eine erneute Zustellung der 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 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 angenommen bzw. an den Empfänger weitergeleitet und der Absender für eine länger Zeitspanne in eine Whitelist übernommen. Meldet sich der Absender hingegen nicht innerhalb von vier Stunden nach dem ersten Zustellversuch, so wird der erste Eintrag aus der Liste entfernt. Insgesamt bietet Graylisting die folgenden Vorteile:

79 3.5 IP-Sperren Seite 79 Bei der Nutzung von Graylisting muss der Anwender an seinem Client keine Änderungen vornehmen. Bei der normalen Arbeit merkt er nicht, dass Graylisting eingesetzt wird. Der Administrator eines SMTP-Servers muss sich um keine Aktualisierungen der Liste kümmern und kann eine Graylist mit relativ wenig Aufwand in seine onfiguration einfügen. Die Hardwareressourcen, die benötigt werden, um zum einen die Liste zu speichern und zu verwalten und zum anderen eintreffende s 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 s anzuwenden, um Nachrichten, die von Bots mit einer vollständigen Implementierung von SMTP ausgehen, weiter zu behandeln. Es existieren aber auch Nachteile: Aufgrund der Zeitverzögerung wird die erste zu einem Tripel aus Absender-IP, Absender-Adresse und Empfänger-Adresse je nach Implementierung erst nach eine bestimmten Zeitspanne an den Empfänger versendet. Eines der ernziele der ist jedoch die Geschwindigkeit, die an dieser Stelle leidet. Diese Zeitverzögerung kann besonders dann zu einem Hindernis werden, wenn ein Nutzer auf einer Webseite die Zugangsdaten zu seinem onto zurücksetzen möchte und neue Zugangsdaten per anfordert. Die neuen Zugangsdaten werden dann bedingt durch die Zeitverzögerung erst nach einer festgelegten Zeitspanne empfangen, wobei der Webserver so konfiguriert sein kann, dass die neuen Zugangsdaten nur für eine gewisse Zeitspanne gelten. Im schlimmsten Fall hat der Nutzer dann also keinen Zugriff mehr auf sein onto 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 werden, 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 eine unter den Servern verteilte Datenbank handelt. In einem solchen Szenario kann nämlich nicht ausgeschlossen werden, dass der zweite Zustellversuch auf einem anderen SMTP-Server stattfindet. Ob Graylisting eingesetzt werden soll, das muss der jeweilige Administrator entscheiden und dabei die Vor- und Nachteile gegeneinander abwägen.

80 Seite 80 Studienbrief 3 Anti-Spam-Techniken ontrollaufgaben In diesem Abschnitt befinden sich verschiedene ontrollaufgaben, welche die Inhalte der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffes beitragen sollen. ontrollaufgabe 3.3: IP-Sperren I Was sind IP-Sperren und welche verschiedenen Arten existieren? ontrollaufgabe 3.4: IP-Sperren II An welcher Stelle werden IP-Sperren eingesetzt? ontrollaufgabe 3.5: Blacklisting I Welche verschiedenen Arten gibt es, um Blacklisting zu praktizieren? ontrollaufgabe 3.6: Blacklisting II Welche vier Schritte sind beim DNS-basierten Blacklisting notwendig, um eine IP-Adresse zu überprüfen? ontrollaufgabe 3.7: Blacklisting III Nennen Sie Vor- und auch Nachteile für den Einsatz von Blacklists. ontrollaufgabe 3.8: Whitelisting Was ist Whitelisting und welchen Zweck verfolgt es? ontrollaufgabe 3.9: Graylisting Was macht Graylisting im Gegensatz zu White- und Blacklisting zu einer besonderen Art der IP-Sperren und warum kommt es auch ohne externe Dienstanbieter aus?

81 3.6 Reputationsverfahren Seite 81 ontrollaufgabe 3.10: Graylisting II Nenne Sie jeweils zwei Vor- und zwei Nachteile von Graylisting. 3.6 Reputationsverfahren Verfahren, die nicht den Inhalt einer auswerten, sondern Metaeigenschaften zur lassifikation 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 s, 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 lassifizierung von Nachrichten 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 -Headern oder ganzen Nachrichten aufbaut. Zuletzt werden dann noch über mehrere Nachrichten gesammelte Eigenschaften betrachtet. Bei der ersten Gruppe von Merkmalen handelt es sich konkret um die folgenden Eigenschaften: 1. Die geodätische Distanz zwischen Sender und Empfänger. Geodätische Distanz Reguläre s legen normalerweise einen eher kurzen Weg zurück, da es sich oft um eine ommunikation 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 ontinent stammt. 2. Die Nachbarschaft der Spam-Versender. Nachbarschaft Die von den Autoren der Arbeit aufgestellte These lautet, dass Spamversender oft von anderen Spamversendern umgeben sind. Diese Behauptung wird in viele Arbeiten verwendet und lässt sich auch leicht nachvollziehen. Gruppen von Computern werden oft durch einzelne Instanzen verwaltet, die gewisse Richtlinien auf alle verwalteten Computer anwenden. So kann bspw. die Software auf einer Menge von Computern den gleichen Versionsstand haben, wodurch eine Sicherheitslücke alle verwalteten Computer betrifft. Wird nun einer dieser Computer mit Malware infiziert, so trifft dies früher oder später auch auf die anderen Computer desselben Netzwerkes zu. Da die Malware zum Versand von Spam verwendet werden kann, würden dann alle kompromittierten Computer Spam versenden, wodurch die Behauptung bestätigt wird.

82 Seite 82 Studienbrief 3 Anti-Spam-Techniken Tageszeit Autonomes System Port-Status 3. Die Tageszeit des Spamversandes. Der Versand von Spam ist geprägt durch die An- und Ausschaltmuster der Computer. So werden bspw. Spam-Nachrichten vermehrt Morgens versandt, wenn viele Computer eingeschaltet sind. Der reguläre Nachrichtenversand weist jedoch ein anderes Muster auf, wodurch eine lassifikation denkbar wird. 4. Das autonome System des Versender. Da nur wenige autonome Systeme für einen großen Anteil des Spams verantwortlich sind, kann die Nummer des autonomen Systems als Eigenschaft zur lassifikation herangezogen werden. 5. Der Status der einzelnen Ports des Versenders. Versender von regulären s sind im Normalfall Server, die auch gleichzeitig für den Eingang von s verwendet werden. Damit sie von den Nutzern für den Eingang von s verwendet werden können, müssen entsprechende Ports offen sein, damit sich die -Clients der Nutzer an den Server verbinden kann. Computer, die zum Spamversand verwendet werden, haben normalerweise keine offenen Ports in diesen Bereichen. Daher kann eine lassifikation nach offenen Ports mögliche Spamversender identifizieren. Weiterhin wurden Merkmale aus einzelnen Nachrichten extrahiert. Anzahl Empfänger -Größe 1. Die Anzahl der Empfänger. Oft werden Spam-Nachrichten nicht nur an einen sondern an mehrere Empfänger versendet. Ham hat dagegen meist einen oder wenige Empfänger. 2. Die Größe der . Reguläre s 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 ampagne 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 s 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. 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

83 3.7 Challenge-Response-Verfahren Seite 83 Abb. 3.3: Das SNARE Framework aus?. Erkennungsgenauigkeit und Geschwindigkeit entschieden werden. In einem zweiten Schritt werden s aussortiert, die über eine Whitelist gefunden werden. Wird eine nicht durch einen Eintrag einer Whitelist erkannt, so wird diese durch SNARE analysiert, bevor andere Spamfilter oder Inhalts-basierte Analysen stattfinden. s 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 lassifikation von SNARE geschickt werden, um diese besser zu trainieren. 3.7 Challenge-Response-Verfahren Challenge-Response-Verfahren werden im Allgemeinen zur Authentifikation von Nutzern oder Computern untereinander verwendet. Dabei wird der anmeldenden Instanz eine Aufgabe gestellt, deren Lösung sie zur Anmeldung autorisiert. Dieses Verfahren kann angewendet werden, um einem Anwender eine Informationen zu zeigen, die bspw. von Bots nicht erkannt werden soll. Dazu werden CAPTCHAs (vgl. Abschnitt ab Seite 51) eingesetzt, bei denen der Anwender entweder Buchstaben aus einem Bild erkennen soll oder gesprochene Wörter aus einer Aufnahme identifizieren soll. In beiden Fällen können die CAPTCHAs erschwert werden, indem Hintergrundrauschen eingefügt wird. Hierbei kann jeder die Aufgabe lösen, der die Buchstaben identifiziert oder die Wörter erkennt. Um es Spammern zu erschweren, ihren Spam zu versenden, können Challenge-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 vom Absender an den Empfänger verschickt, so kann der empfangende SMTP-Server die 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 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.

84 Seite 84 Studienbrief 3 Anti-Spam-Techniken 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 ommunikation per zu einem komplizierten Unterfangen. Für jede versendete Nachricht muss vom empfangenden SMTP-Server erst eine Anfrage an den Versender geschickt werden, die diesen um die Lösung einer Aufgabe bittet. Weiterhin muss der Versender der ursprünglichen Nachricht Zeit in die Lösung der Aufgabe stecken, bevor seine an den Empfänger weitergeleitet wird. Dadurch verzögert sich der gesamte Vorgang und macht die als ommunikationsmedium weniger interessant. Bedingt durch die zusätzlichen s wird der gesamte Datenverkehr im Internet weiter erhöht. Weiterhin werden auch Versender von regulären Massen- s wie Newslettern am Versand der Nachrichten gehindert, da für jeden einzelnen Empfänger eine Aufgabe gelöst werden müsste, was einen sehr großen Aufwand darstellt. Oft versenden Spammer Nachrichten, bei denen die Absenderadresse gefälscht ist, um möglichst unauffällig zu agieren. Wird nun die Absenderadresse gefälscht, so erhalten Unbeteiligte die Aufforderung zur Lösung einer Aufgabe, was in deren Augen wieder als Spam betrachtet werden kann. Aufgaben, welche die Lösung eines CAPTACHs voraussetzen, diskriminieren damit seh- oder hörbehinderte Menschen, die solche Aufgaben nicht lösen können. Genauso können nicht behinderte Menschen nicht dazu in der Lage sein, ein CAPTCHA zu lösen, sofern das Hintergrundrauschen zu groß ist. Spammer können die Aufgaben von Menschen lösen lassen, indem sie die CAPTCHAs an andere weiterleiten und dabei bestimmte Anreize zum Lösen anbieten. Somit verlagern die Spammer das Problem auf andere Menschen und leiden folglich nur an zeitlichen Verzögerungen, wobei die Spam-Nachrichten jedoch nicht durch das Challenge-Response-Verfahren aussortiert werden. 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 -Verfahrens Die Spezifikationen für den Versand von s 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 -Header erweitern, um zu zeigen, dass der Sender die Erlaubnis zum Versand hat (DIM, 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).

85 3.8 Erweiterungen des -Verfahrens Seite Domaineys / DIM Domaineys sind ein System zur Authentifizierung von s, das im Mai 2007 RFC 6376 von Yahoo! Inc. als Mittel zur Bekämpfung von Spam in RFC 4870 (vgl.?) vorgestellt wurde. Unter dem Namen Domaineys Identified Mail (DIM) 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 Studienbrief 1 ab Seite 9 beschrieben, werden beim Versand von s für den Absender zwei unterschiedliche Felder verwendet. Der beim Empfänger angezeigte Absender muss also nicht dem Versender entsprechen. Eine Reihe von Spam-ampagnen, die insbesondere zur Durchführung von Phishing (vgl. Abschnitt 1.9 ab Seite 41) verwendet werden, fälschen die Absenderadresse ihrer versendeten s, um den Empfänger zu täuschen. So erhalten Empfänger s von Banken, die täuschend echt aussehen und auch anscheinend von der Bank verschickt wurden. DIM setzt an dieser Stelle an, indem es den Versender mithilfe asymmetrischer ryptographie (vgl. Exkurs 3.2 auf Seite 88) gegenüber dem Empfänger verifiziert. Grob gesagt wird dazu der Hash einer mit dem privaten Schlüssel einer Organisation verschlüsselt und mit der zusammen versendet. Der Empfänger kann dann per DNS den öffentlichen Schlüssel anfordern, den Hash entschlüsseln und überprüfen, ob der erhaltene lartext 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 DIM-Signature in die 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 20) bestehen dürfen. Der generelle Aufbau der DIM-Signature wird in Exkurs 3.1 beschrieben, eine konkrete DIM-Signature liefert Beispiel 3.2. Exkurs 3.1: DIM-Signature E DIM-Signature: v=1; a={signaturalgorithmus/hashalgorithmus}; c={anonisierungsmethode}; d={domain}; s={selektor}; h={liste der verwendeten Header-Felder}; bh={hashwert des Nachrichten-Bodys}; b={signatur}; Die wichtigsten Tupel innerhalb der DIM-Signature sind: b= Digitale Signatur des Inhalts von Header und Body der . 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 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.

86 Seite 86 Studienbrief 3 Anti-Spam-Techniken B Beispiel 3.2: DIM-Signature Folgende Zeilen entstammen einer , die durch einen SMTP-Server von Google verschickt wurde und eine gültige DIM-Signature enthält. Return-Path: <bounc +sebastian.uellenbeck=googl .com== sebastian.uellenbeck=rub.de@rub.de> [..] DIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s= ; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=z/994tdmf5f0wpwf8mufo3moe5jhmhslp7tcm0su=; b=z2forpwveylfrd8lijno7+tpko+x7t7tmdygjf3w7myjoaqezijueh+gre9yqlbdv TCaHhUBDZw4MHqspVi40crBDRd8tgyV9627BOkFR4B00mm/lgjJfrj8FIh1sEZ7r5Zw8 PrEOIYGhTormy38DkTvnCBAeEU1Z3NU3oIM4908EjiMS32JXDpiTrmnL8k8p7Rx+8l 8m04PJcl7ZLiSsx979Q8c81xW0XDxDMUiNwUDW1BmqTAqPc0/jMxtjtAiFLuE0437JT VnX0B/0kLFvB7EWxwk8rL6d7Y6ZmWZyve0bOm3Y4OgUG6kPWEQcfQYue9oFfWQ5BElo OdcA== [..] Es werden also Hashes von bestimmen Teilen der 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 DIM-Signature zum Header der hinzugefügt hat, wird die an den Empfänger verschickt. Der empfangende SMTP-Server kann nun die verifizieren. Dazu wird die DIM- Signature untersucht, wobei eine DNS-Anfrage (vgl. Abschnitt ab Seite 34) verschickt wird, die nach dem TXT-Eintrag, der im Header als Absender aufgeführten Domain fragt. Als Antwort erhält der SMTP-Server dann den öffentlichen Schlüssel zur angefragten Domain und dem entsprechenden Selektor (vgl. Beispiel 3.3). Mithilfe des Schlüssel kann dann der Hash der berechnet werden und das Resultat mit der entschlüsselten Zeichenkette verglichen werden. Sind die beiden Zeichenketten gleich, so beweist die Gleichheit, dass die 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 DIM verifiziert werden, ob eine wirklich von dem Absender stammt, der im Header der angegeben ist. Einen Überblick zu den zu DIM existierenden Diensten wird in RFC 5585 (vgl.?) gegeben. Eine mögliche Erweiterung, die Author Domain Signing Practices (ADSP), beschreibt RFC 5617 (vgl.?).

87 3.8 Erweiterungen des -Verfahrens Seite 87 Beispiel 3.3: DIM-Verifikation Für die aus Beispiel 3.2 erhaltene DIM-Signature wird nun der öffentliche Schlüssel angefordert: B $ nslookup -query=txt _domainkey.googl .com [..] Non-authoritative answer: \_domainkey.googl .com text = "k=rsa\; p=miibijanbgkqhkig9w0baqefaaocaq8amiibcgcaqea1d87/u ejjenpabgbfwh+ebcsstrqmwiyyvywlbhbqoo2dymndfkbjovipil dns/m40f+yzmn1skyoxctugcqs8g3fgd2ap3zb5dekao5wmmk4wi mdo+u8qzi3sd0" "7y2+07wlNWwIt8svnxgdxGkVbbhzY8i+RQ9Dp SVpPbF7ykQxtXkv/ahW3jViiAH+ghvvIhkx4xYSIc9oSwVmAl5O ctmeewuwg8istjqz8bzetwbf41fbnhte7y+yqzowq1sd0dbvyad9n OZ9vlfuac0598HY+vtSBczUiERHv1yRbcaQtZFh5wtiRrN04BLU TD21MycBX5jYchHjPY/wIDAQAB" DIM bietet zusammenfassend die Vorteile, dass es als Hilfsmittel gegen Phishing verwendet werden kann. Signieren Banken ihre s per DIM, so können nicht oder fehlerhaft signierte s problemlos auch automatisch durch den - 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 benötigen Prozessorleistung, dieser ist aber im Vergleich zu anderen Verfahren (vgl. Hashcash in Abschnitt ab Seite 92) sehr gering. DIM bietet zwar keinen direkt Schutz vor Spam (vgl.?), es kann jedoch als Einfluss für Reputationssysteme (vgl. Abschnitt 3.6 ab Seite 81) verwendet werden. Gleichzeitig gibt es bei dem Verfahren jedoch einige bisher ungelöste Probleme. Dazu zählt die Veränderung des -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 DIM-Signature nicht mehr zum -Inhalt. Da Botnetze auch Webmail als Quelle für Spam verwenden, kann nicht ausgeschlossen werden, dass trotz gültiger DIM-Signature eine doch Spam ist. Besonders s, die HTML-Quelltext enthalten und darin Bilder einbinden, können einfach zum Versand von Spam verwendet werden. Ein weiteres Problem besteht darin, dass DIM oftmals mit sehr kurzen Schlüsseln eingesetzt wird. So konnte Zachary Harris die Machbarkeit von Spoofing für Domains von Google, Amazon oder auch Yahoo mit verifizierbaren DIM-Signaturen zeigen (vgl.?). Aus diesem Grund wird vorgeschlagen, mindestens 1024-bit Schlüssel zu verwenden. Aufgrund der Tatsache, dass DIM 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 DIM. Zusätzlich wird das DNS wird entsprechend stärker belastet.

88 Seite 88 Studienbrief 3 Anti-Spam-Techniken E Exkurs 3.2: Asymmetrische ryptographie ryptographische Methoden unterteilen sich in symmetrische und asymmetrische Verfahren. Die symmetrischen Verfahren verwendeten sowohl zur Ver- als auch zur Entschlüsselung denselben Schlüssel. Im Gegensatz dazu verwenden asymmetrische Verfahren einen Schlüssel zum Verschlüsseln und einen anderen Schlüssel zum Entschlüsseln. Asymmetrische Verfahren werden auch Public-ey-Verfahren genannt, da ein Anwendungsfall darin besteht, dass einer der beiden Schlüssel öffentlich (public) zugänglich gemacht werden kann, mit dem eine Nachricht verschlüsselt werden und ausschließlich der Besitzer des anderen (privaten) Schlüssels die Nachricht entschlüsseln kann. Nach? existieren vier Hauptfunktionen für asymmetrische Verschlüsselungsverfahren: Schlüsselaustausch Es existieren Protokolle, mit denen ein geheimer Schlüssel über einen unsicheren anal verschickt werden kann. Nichtabstreitbarkeit Hiermit kann sichergestellt werden, dass eine Nachricht 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 SPF (Sender Policy Framework) RFC 6652 SPF wurde in RFC 4408 (vgl.?) spezifiziert und durch RFC 6652 (vgl.?) aktualisiert. Das System gilt als Alternative zu DIM (vgl. Abschnitt ab Seite 85), da es ebenfalls dazu verwendet werden soll, die Absenderadresse zu verifizieren und dafür auf DNS aufsetzt. Im Gegensatz zu DIM werden allerdings keine kryptographischen Methoden verwendet, um den Inhalt einer zu verifizieren. DIM kann daher verifizieren, dass der Inhalt einer 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 versendet wird, dazu berechtigt ist, für den spezifizierten Absender die zu verschicken. Um dies durchführen zu können, wird ein spezieller DNS-Eintrag benötigt. Da SPF bereits vor der Spezifizierung durch RFC 4408 eingesetzt wurde und erst mit RFC 4408 der neue DNS-Eintragstyp SPF eingeführt wurde, wird empfohlen, sowohl den TXT- als auch den SPF-Eintrag mit Daten zu versorgen. Der Aufbau des TXT- bzw. SPF-Eintrags wird dabei im folgenden Exkurs 3.3 beschrieben. Beispiel 3.4 zeigt einen konkreten DNS-Eintrag.

89 3.8 Erweiterungen des -Verfahrens Seite 89 Exkurs 3.3: SPF-DNS-Einträge Der DNS-Eintrag, der zur Funktionsfähigkeit von SPF benötigt wird, ist eine Zeichenkette, die aus vielen Teilen bestehen kann, die jeweils durch Leerzeichen getrennt sind. Der Eintrag selber beginnt mit einer Versionsnummer v=, die aktuell bei 1 liegt (vgl. Beispiel 3.4). Die meisten der einzelnen Teile werden als Direktiven bezeichnet und können vom SMTP-Server ausgewertet werden. Die Auswertung aller Direktiven wird von links nach rechts für jede Direktive einzeln abgearbeitet. Dabei können drei Fälle eintreten: E 1. Die Direktive passt zur Anfrage, dann wird die Auswertung beendet und der Wert der Bedingung wird zurückgegeben. 2. Die Direktive passt nicht zur Anfrage, dann wird die nächste Direktive abgearbeitet. 3. Die Auswertung wirft eine Ausnahme (engl. Exception), dann wird die Ausarbeitung beendet und der Wert der Ausnahme zurückgegeben. RFC 4408 definiert vier Bedingungen (engl. qualifier), die zu einer Direktive das erwünschte Verhalten beim Eintreffen spezifizieren: Bedingung Name Beschreibung + Pass Der Sender ist autorisiert zum Versand einer Nachricht. - Fail Der Sender ist nicht zum Nachrichtenversand 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 all a mx ip4 ip6 include Bedingung für das Eintreffen der Direktive Trifft immer zu und sollte als letzte Direktive den Standardfall beschreiben. Ein A oder AAAA-Record der befragten Domain enthält die IP-Adresse des Senders. Ein MX-Record der befragten Domain enthält die IP-Adresse des Senders. Die angegebene IPv4-Adresse ist oder enthält die IP-Adresse des Senders. Die angegebene IPv6-Adresse ist oder enthält die IP-Adresse des Senders. Verweist auf eine andere Liste.

90 Seite 90 Studienbrief 3 Anti-Spam-Techniken B Beispiel 3.4: SPF-Eintrag für den Google Mail-Dienst Der SPF-Eintrag für den Google Mail-Dienst kann über den Befehl $ host -t TXT _spf.google.com erfragt werden. Aktuell wird als Antwort die folgende Zeichenkette zurück gegeben: _spf.google.com descriptive text "v=spf1 include:_netblocks.google.com include:_netblocks6.google.com?all" Durch den Exkurs 3.3 wird deutlich, dass die Informationen aus Beispiel 3.4 noch weiter aufgelöst werden müssen, damit sie verwendbar sind. Dies wird in Beispiel 3.5 gezeigt. B Beispiel 3.5: SPF-DNS-Einträge: Auflösung einer include Direktive Da der SPF-DNS-Eintrag aus Beispiel 3.4 zwei include Direktiven enthält, müssen diese wie folgt weiter aufgelöst werden: $ host -t TXT _netblocks.google.com _netblocks.google.com descriptive text "v=spf1 ip4: /19 ip4: /19 ip4: /20 ip4: /18 ip4: /17 ip4: /20 ip4: /16 ip4: /20 ip4: /20 ip4: /16?all" $ host -t TXT _netblocks6.google.com _netblocks6.google.com descriptive text "v=spf1 ip6:2607:f8b0:4000::/36 ip6:2a00:1450:4000::/36?all" Der empfangende SMTP-Server kann nun die Direktiven aus der Antwort der DNS- Anfrage auswerten und erhält daraus die Antwort, ob die IP-Adresse des Senders autorisiert ist, von der angegebenen IP-Adresse s zu verschicken. s sollten durch den SMTP-Server jedoch nicht direkt geblockt werden. Vielmehr sollte das Ergebnis der Überprüfung mit in den Header der aufgenommen werden, damit es ggf. vom Client des Nutzers angezeigt wird. Insgesamt besitzt SPF den Vorteil, dass der Client nicht notwendigerweise angepasst werden muss. Auch der SMTP-Server zum Versand von s bedarf keinen Erweiterungen. Dagegen muss allerdings eine entsprechende Funktionalität im empfangenden SMTP-Server vorhanden sein. Weiterhin müssen die entsprechenden DNS-Einträge gepflegt werden. SPF kann daher auch nicht vor Spam schützen, da auch Versender von Spam ihre eigenen DNS-Einträge entsprechend pflegen können. Es kann aber vor Phishing helfen, da entschieden werden kann,

91 3.8 Erweiterungen des -Verfahrens Seite 91 ob eine IP-Adresse die Berechtigung hatte, mit einem bestimmten Absender eine abzuschicken Sender ID RFC 4406 (vgl.?) beschreibt das experimentelle Protokoll Sender ID, das eine RFC 4406 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. Im Gegensatz zu SPF wird unter anderem die Header-Adresse einer zur RFC 4407 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 aus seinem -Client oder per Webmail. An dieser Stelle ist für SIDF noch keine Änderung notwendig. 2. Der Ziel-SMTP-Server empfängt die und erfragt per DNS den PRA (v=spf2.0/pra) Eintrag.

92 Seite 92 Studienbrief 3 Anti-Spam-Techniken 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 lassifikation der mit berücksichtigt. 5. Basierend auf den erhaltenen und ausgewerteten Informationen wird die dann klassifiziert und an den Benutzer zugestellt. Für weitere Informationen fasst? die verfügbaren Ressourcen zum Sender ID Framework zusammen Hashcash Proof-of-Work System Hashcash ist ein von Adam Back im Jahr 1997 vorgeschlagenes und 2002 in? 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 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 Studienbrief 2 zu Spam-Techniken ab Seite 47 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 liegt ganz klar darin, dass die mit dem Versand einer verbundenen osten 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 - Client des Versenders führt dabei folgende Schritte durch: 1. An den Header der wird eine Zeile angehängt. Diese Zeile beginnt mit H-Hashcash: und enthält die -Adresse des Empfängers, das Datum sowie eine Zufallszahl. RFC Für die so erzeugte Zeile wird der SHA-1 Hash (vgl.?,? und?) berechnet. 3. Falls die ersten 20 Bits des resultierenden Hashes jeweils den Wert 0 haben, kann die 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 Million Iterationen wurde dann eine Header-Zeile erzeugt, die den gewünschten riterien entspricht. Der Empfänger muss nun die folgende Eigenschaften überprüfen, um die Validität der zu verifizieren. 1. Haben die ersten 20 Stellen des SHA-1 Hashes der Headerzeile H-Hashcash: den Wert Null?

93 3.8 Erweiterungen des -Verfahrens Seite 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 um eine Spam-Nachricht handeln. Andernfalls handelt es sich mit sehr großer Wahrscheinlichkeit nicht um eine Spam-Nachricht. Insgesamt gesehen bietet Hashcash die Vorteile, dass diese Methode nur innerhalb der -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 schon vom SMTP-Server gefiltert worden sein. Ein weiterer Vorteil besteht darin, dass im Gegensatz zu anderen Systemen kein echtes Geld verwendet wird. Es existieren jedoch auch Nachteile bei Hashcash. Computer mit langsamen Prozessoren oder immer beliebter werdende Smartphones oder Tablett PCs, die über langsame Hardware verfügen, benötigen zum Versand von s viel Rechenleistung. Bei mobilen Geräten kann darunter auch die Laufzeit leiden, da der Akku in Mitleidenschaft gezogen wird. Ebenso müssen Server für Newsletter mit vielen Empfängern deutlich mehr Leistung für den Versand eines Newsletters aufbringen als ohne Hashcash. Der wohl schwierigste Nachteil besteht darin, dass die Hauptquelle von Spam, die Botnetze, über sehr viel Rechenleistung verfügen und somit immer noch sehr viele Spam-Nachrichten verschicken können, auch wenn die Menge um viele Faktoren sinkt 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 -Versandprozess zu beeinflussen. onkret soll der Empfänger den Sender in die ategorien allowed, denied und unclassified klassifizieren können, um den Versand jeder ategorie 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 lassifikation geschieht dabei nur aufgrund der IP-Adressen. Es werden zwei Listen von IP- Adressen gepflegt, zum einen die trusted MTAs, deren s direkt akzeptiert werden. Zum anderen die black-listed MTAs, deren s 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.

94 Seite 94 Studienbrief 3 Anti-Spam-Techniken ontrollaufgaben In diesem Abschnitt befinden sich verschiedene ontrollaufgaben, welche die Inhalte der vorherigen Abschnitte auffassen und daher zur Vertiefung des Stoffes beitragen sollen. ontrollaufgabe 3.11: DIM I Wozu wird DIM verwendet und welches Problem kann das Verfahren nicht lösen? ontrollaufgabe 3.12: DIM II Nennen Sie jeweils zwei Vor- und zwei Nachteile von DIM. ontrollaufgabe 3.13: SPF I Was ist SPF und wie unterscheidet es sich gegenüber DIM? ontrollaufgabe 3.14: SPF II Was sind Direktiven bzw. Bedingungen und wozu werden sie genutzt? ontrollaufgabe 3.15: SPF III önnen Sie sich vorstellen, wozu es eine?-bedingung (Neutral) gibt? ontrollaufgabe 3.16: Sender ID Was unterscheidet Sender ID von SPF? ontrollaufgabe 3.17: Hashcash I Welche Eigenschaften zeichnen Hashcash aus?

95 3.9 Echtzeit URL Filterung Seite 95 ontrollaufgabe 3.18: Hashcash II Angenommen, der Empfänger erhält eine , bei der sich die Headerzeile H-Hashcash: bereits in seiner Datenbank befindet. Welche beiden Szenarien können hier eingetroffen sein? ontrollaufgabe 3.19: Hashcash III 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 Twitter 1 oder Facebook 2 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. Abb. 3.5: Die generelle Funktionsweise des Echtzeit-Spam- Filterdienstes Monarch aus?. Die von Web-Services verbreiteten URLs könnten in einem ersten Schritt an Monarch verschickt werden. Monarch kann dann jede einzelne URL untersuchen und in einem zweiten Schritt eine Entscheidung an den Web-Service zurückschicken, ob die verlinkten Seite bspw. für Phishing verantwortlich ist, Malware verbreitet oder auch als gutartige Seite einstuft werden kann. Abb. 3.6: Das Flussdiagramm von Monarch aus?. Monarch arbeitet, wie Abbildung 3.6 verdeutlicht, in vier Schritten: 1. Zuerst findet eine Aggregation zwischen einem -Strom und den Tweets des Web-Services Twitter statt. Bei den verwendeten s handelt es sich 1 aufgerufen am aufgerufen am

96 Seite 96 Studienbrief 3 Anti-Spam-Techniken 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 lassifikation. Ein Offline Training stellt sicher, dass die Reaktionszeit des Systems möglichst gering bleibt, während ein Echtzeit-lassifikator 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 lassifikation benötigt. Diese Ergebnisse wurden erreicht, indem der lassifikator mit 1,2 Millionen Spam- Nachrichten, als schadhaft gekennzeichneten Twitter-URLs und 9 Millionen regulären URLs angelernt wurde. ontrollaufgabe 3.20: Monarch Beschreiben Sie, wie Monarch funktioniert und wie es auch zur Erkennung von Spam genutzt werden könnte Netzwerk-basiertes Clustern IP-basiertes Blacklisting (vgl. Abschnitt ab Seite 74) 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 Clusterbasierte Blacklisten zu erstellen. Sogar die BGP-Präfixe im mittleren Bereich sind in fast 20 % der Fälle ungeeignet für die Spam-Filterung. DNS Informationen können helfen, um die BGP Präfixe in kleinere Cluster zu brechen und so die Falsch Negativ Rate zu senken. Ein von den Autoren erarbeitetes System, das BGP-Präfixe und DNS- Informationen verbindet, kann mehr als 50 % mehr Spam erkennen als vorherige Ansätze.

97 3.11 Erkennung von Botnetzen Seite 97 Der von den Autoren vorgeschlagene Ansatz kann dabei problemlos in ein System wie SpamAssassin (vgl. Abschnitt 3.14 ab Seite 104) eingebaut werden und hilft somit bei einer besseren lassifizierung von Spam Erkennung von Botnetzen Die Erkennung von Botnetzen ist ein wichtiges Mittel ist im ampf 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 Verfolgung von Bots aus bestimmten Botnetzen zu erleichtern. Eine bewährte Methode, um Bots zu identifizieren, besteht darin, Spam-Traps einzusetzen und die IP-Adressen der Absender zu verwenden. Dieses Vorgehen birgt jedoch zwei Gefahren: Zum einen gehört nur eine kleine Menge der so erkannten IP-Adressen zu einem bestimmten Botnetz. Viel eher werden viele unterschiedliche Botnetze Spam an einzelne Spam-Traps versenden. Zum anderen verschicken Botnetze oft nur Nachrichten an bestimmte Nutzer aus einer vorher definierten Region, damit der Nutzer bspw. auch die Sprache, die in einer Spam-Nachricht verwendet wird, versteht. Beim vorgeschlagenen Ansatz gehen die Autoren davon aus, dass Bots, die zum gleichen Botnetz gehören, auch über den selben Quellcode verfügen und die selben Command and Control Infrastruktur verwenden. Daher haben solche Bots ein ähnliches Verhalten und können von Bots aus anderen Botnetzen abgegrenzt werden, die für ihren Spamversand andere Parameter verwenden. Um Bots aus einem Botnetz zu finden, werden zwei Listen benötigt. Dies ist zum einen eine initiale Liste von Spambots, die über die klassischen Spam-Traps kommen kann. Zum anderen werden Protokolle von empfangenden SMTP-Servern benötigt. Im ersten Schritt wird dann die Liste der Spambots mit den Protokollen verglichen. Hierbei werden Überschneidungen zwischen IP-Adressen der Spambots und der Protokolle gesucht. Diese Überschneidungen werden dann analysiert und daraus Profile erstellt. 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 ampagnen 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 ab Seite 74) verwendet werden, um bessere Ergebnisse bei der lassifikation vom Spam zu erzielen.

98 Seite 98 Studienbrief 3 Anti-Spam-Techniken BotSniffer Einen alternativen Ansatz zu BotMagnifier liefern? mit BotSniffer. BotSniffer verwendet eine Netzwerk-basierte Anomalieerkennung, um die Command and Control-anäle von Botnetzen in lokalen Netzwerken zu identifizieren. Dazu werden jedoch nicht, wie beim vorherigen Ansatz, Informationen über vorhandene Bots benötigt. Der Netzwerkverkehr von Botnetzen ist schwer zu erkennen, da oftmals gebräuchliche Protokolle wie IRC oder HTTP verwendet werden. Der Ansatz der Autoren basiert aber auf der Annahme, dass das Verhalten von Bots räumlichen und zeitlichen orrelationen 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 orrelation von Bot-Antworten aus?. Links: einzelne Antwortnachrichten, rechts: verschiedene Aktivitäten. BotSniffer erkennt dieses Verhalten, indem statistische Algorithmen zur Gruppierung der Muster verwendet werden. Abbildung 3.8 visualisiert dazu eine Übersicht über die Architektur des Systems. Hierbei erhält BotSniffer als Eingabe den lokalen Netzwerkverkehr und führt zuerst ein Vorverarbeitung der Daten durch. Dabei werden nicht relevante Informationen wie ICMP- und UDP-Pakete entfernt. Die Autoren gehen davon aus, dass innerhalb dieser Pakete bisher keine Command and Controll-Daten ausgetauscht werden, weshalb sie für die Erkennung von Botnetzen zum Stand der Veröffentlichung nicht zur Verbesserung der Ergebnisse beitrugen. Weiterhin werden Verbindungen zur normalen Servern wie Google oder Yahoo durch ein statisches Whitelisting entfernt. Daraufhin werden zwei Module auf die Daten angewendet. Zum einen findet eine Erkennung von Aktivitäten und Antworten statt. Diese sucht das Modul nach IRC-PRIVMSG-Nachrichten, die für die ommunikation 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. RFC 1459, RFC 1945 Die Autoren versuchen IRC- und HTTP-Verbindungen in den Daten zu finden, gehen aber davon aus, dass Bots nicht unbedingt die Standardports der Protokolle verwenden. Daher müssen die Datenströme auf allen Ports untersucht werden. IRC-Verbindungen können einfach erkannt werden, da der Start von IRC-Sitzungen durch drei Nachrichten (PASS, NIC 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

99 3.12 Botnetz-Übernahme Seite 99 Abb. 3.8: Architekturübersicht von BotSniffer aus?. eine Eingabe für das Modul zur Erkennung von IRC-Nachrichten und Antworten dar. Dazu werden die IRC Datenströme weitergeleitet und auf ein- und ausgehenden IRC PRIVMSG Nachrichten hin analysiert. Diese Modul speichert ebenfalls Informationen in der Datenbank zum Aktivitäten protokollieren ab, generiert aber auch direkt Berichte. Berichte werden auch durch ein orrelationsmodul 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 Botnetz-Übernahme Botnetze sind aktuell für den Großteil alle versendeten Spam-Nachrichten verantwortlich. Aus diesem Grund sind Analysen von Botnetzen hilfreich, um deren Vorgehensweisen zu verstehen und um daraus folgend den Versand von Spam einzudämmen. In? haben die Autoren das Botnetz Torpig (auch unter den Namen Sinowal und Anserin bekannt) untersucht. Torpig sammelt sensible Informationen der befallenen Computer wie onto- und reditkarteninformationen. Es basiert auf dem Rootkit Mebroot 3, der den Master Boot Record erweitert und somit bei jedem Systemstart noch vor dem Betriebssystem ausgeführt wird. Generell existieren zwei Möglichkeiten, um ein Botnetz zu analysieren. Zum einen kann eine passive Analyse stattfinden, bei der der Datenverkehr beobachtet wird. Zum anderen kann eine Infiltration des Botnetzes durchgeführt werden, indem ein Bot in einer kontrollierten Umgebung ausgeführt wird und dabei der Netzwerkverkehr beobachtet wird. Dieses Vorgehen ist dann möglich, wenn die Command and Control-Struktur des Botnetzes per IRC oder HTTP erfolgt. Im besten Fall können so die internen Abläufe beobachtet werden, um Schwachstellen des Botnetzes zu finden. Beide Möglichkeiten sind jedoch bei aktuellen Botnetzen schwierig zu realisieren wenn nicht per IRC oder HTTP kommuniziert wird oder eine dezentrale Struktur (Peer-To-Peer) verwendet wird. Eine durchaus bessere Alternative bietet die von den Autoren durchgeführte Entführung des kompletten Botnetzes durch 3 Eine genaue Analyse von Mebroot kann in? (abgerufen am ) gefunden werden.

100 Seite 100 Studienbrief 3 Anti-Spam-Techniken die Übernahme eines Command and Control Servers. Dies ist zum einen durch die physikalische Übername des Command and Control Servers möglich, wozu aber bekannt sein muss, wo der Server gehostet wird, was bei dezentralen Lösungen sehr schwierig ist, oder die Ausnutzung der Domain-Flux-Technik, die von Torpig eingesetzt wird. Domain Flux Domain Flux ist eine Technik, bei der jeder einzelne Bot unabhängig von den anderen Bots periodisch eine Liste von Domains erstellt, zu denen er einen Verbindungsaufbau versucht. Der erste Server, der bei einem Verbindungsaufbauversuch eine valide Antwort zurückmeldet, wird als echter Command and Control Server betrachtet. Der Bot verbindet sich daraufhin mit dem Server und wartet auf Befehle. Durch Reverse Engineering (vgl. Exkurs 3.4 auf Seite 101) des Domain Erstellungs Algorithmus konnten im Vorhinein bereits die entsprechenden Domains registriert werden, wodurch der Botmaster dazu keine Möglichkeit mehr hat. Die Bots verbindeten sich dann mit einem Server, der unter der ontrolle der Autoren stand. Die Autoren erhielten somit Daten von mehr als 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 ontrolle des Angreifers steht und Schwachstellen im Browser ausnutzt, um eine ausführbare Datei herunterzuladen (4). Nachdem die Schadsoftware heruntergeladen und installiert wurde, nimmt der somit entstandene Bot ontakt zum Command and Control Server auf (5) und erhält Aufgaben in Form von Modulen, die auf dem Host-Computer ausgeführt werden sollen. Periodisch werden dann die erhaltenen Daten des Host-Computers an einen weiteren Command and Control Server versendet (6). Um die Adresse des neuen Servers zu erhalten, wird der oben genannte Algorithmus verwendet. Als weitere Schadfunktion führt der Bot einen Phishing-Angriff auf dem Host-Computer aus, sofern diese bspw. entsprechende Onlinebanking-Seiten besucht (7). Die Autoren fanden heraus, dass bei Torpig jeder Bot eine einzigartige ID erzeugt, die bei jeder ommunikation mit übertragen wird. Anhand der Zählung der IDs konnte herausgefunden werden, dass das Botnetz ca 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

101 3.13 Botnet Judo: Automatische Generierung von Spam Signaturen Seite 101 leicht zu erratende Passwörter zum Zugriffsschutz für sensible Webseiten verwendet werden. 3. Die ommunikation mit Registraren, Webhostern und Anlaufstellen von Opfern ist ein sehr aufwendiger Prozess. Durch die Analyse des Botnetzes können so Strategien entwickelt werden, die zum Abschalten des Botnetzes führen und somit auch den Versand von Spam beeinflussen. Exkurs 3.4: Reverse Engineering Der Prozess der Entdeckung der internen Funktionalität einer Software wird als Reverse Engineering bezeichnet. Dabei kann zum einen der Quellcode einer Software untersucht werden. Dies kann sich als aufwendig erweisen, wenn allgemeine Richtlinien, wie die Verwendung von aussagekräftigen Namen für Variablen oder Funktionen bei der Erstellung der Software nicht befolgt werden. Generell ist eine Quellcode-Analyse jedoch durchführbar, auch wenn je nach Umfang des Quellcodes viel Arbeitszeit investiert werden muss. Steht ein Softwareprodukt nicht im Quellcode vor, was der Normalfall ist, so muss das vorhandene Programm im binären Format untersucht werden. Hierbei handelt es sich um Maschinenbefehle, die nicht dazu gedacht sind, von Menschen interpretiert zu werden. Zur Analyse von Binärcode existieren drei unterschiedliche Techniken: E 1. Analyse durch die Beobachtung des Austausches von Informationen. Diese Technik wird häufig bei der Analyse von Protokollen eingesetzt. 2. Mithilfe eines Disassembler wird versucht, aus dem Maschinencode ein Programmcode in Assemblersprache zu erzeugen. Assemblersprache ist zwar immer noch eine Sprache, die sehr nah zur Maschinensprache ist, jedoch handelt es sich um onstrukte, die für Menschen einfacher verständlich sind als die ursprüngliche Maschinensprache. 3. Durch Dekompilierung wird versucht, aus dem Maschinencode wieder ein Programmcode einer Hochsprache zu generieren, der von Menschen einfacherer verstanden werden kann. ontrollaufgabe 3.21: Domain Flux Wofür wird bei Torpig die Domain-Flux-Technik verwendet? 3.13 Botnet Judo: Automatische Generierung von Spam Signaturen Einen weiteren Ansatz zur Bekämpfung vom Spam zeigen?. Auch in dieser Arbeit werden Botnetze als Hauptquelle von Spam ausgemacht. Grundsätzlich besteht das Ziel des Systems darin, aus einer Eingabe von s eine Signatur zu erstellen, mithilfe derer alle s gefiltert werden können, die durch dasselbe Template

102 Seite 102 Studienbrief 3 Anti-Spam-Techniken erzeugt wurden. Die Grundvoraussetzungen bestehen dabei allerdings darin, dass die s 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 -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 . Der grundsätzliche Ablauf, den die Autoren verwenden, wird in Abbildung 3.10 gezeigt. Abb. 3.10: Der Systemü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 s 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 vorhanden sind. Diese invarianten Zeichenketten werden als Anker bezeichnet. Im vorliegenden Beispiel werden Best prices!, und \.com 60% off als Anker identifiziert. Dafür werden die längsten geordneten Mengen von Zeichenketten gesucht, die in allen s 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 ombination

103 3.13 Botnet Judo: Automatische Generierung von Spam Signaturen Seite 103 Abb. 3.11: Eine Beispielinstanz des Algorithmus zum Erstellen einer aus?. 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. ann 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 aktualisieren. Um dies zu tun, gibt es in den vorgestellten Ansatz eine spezieller Funktionalität, den Training Puffer. Für jede neu eintreffende Spam-Nachricht wird zuerst überprüft, ob es bereits eine Signatur gibt, die dieser Nachricht erkennt. Trifft dies zu, so kann die Nachricht verworfen werden, da sie keinen Mehrwert hat. Wird die Nachricht nicht erkannt, so wird sie dem Training-Puffer hinzugefügt und es wird so lange gewartet, bis der Puffer voll ist. Die Größe des Puffers wird durch den Parameter k bestimmt. Die richtige Wahl von k ist von essentieller Bedeutung: ist k zu klein, so können Wörterbücher entweder gar nicht oder nur unvollständig erkannt werden und der Algorithmus würde dementsprechend Zufalls-Makros anstelle von Wörterbuch-Makros wählen. Wird ein großes k gewählt, so ist die Zeitspanne zwischen dem Eintreffen der ersten Spam-Nachricht und der Erzeugung einer Signatur gegen diese Nachricht sehr groß. Außerdem kann es so auch passieren, dass Spam-Nachrichten von unterschiedlichen Templates eintreffen und daraus eine sehr ungenaue und schlechte Signatur erzeugt wird. Aufgrund der Tatsache, dass in den Tests für k kein Wert gefunden werden 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 Signatur bereits unter Beachtung nur weniger s erzeugt werden, auch wenn mehr Nachrichten benötigt werden würden, um ein vollständiges Wörterbuch zu erhalten. Daher können bereits erzeugte Signaturen nachträglich erweitert werden, sofern eine neue Nachricht zwar nicht zu den erzeugten Signaturen passt, jedoch unter Vernachlässigung der Makros von einer Signatur erkannt wird. Als zweiter Mechanismus wird ein Pre-Clustering verwendet. Im Gegensatz zum Second Chance Mechanismus soll das Pre-Clustering gegen einen zu großen Trainings-Puffer helfen, da gerade bei einem großen Trainings-Puffer die Gefahr besteht, dass Nachrichten aus unterschiedlichen Templates vermischt werden. Beim Pre-Clustering werden unklassifizierte Nachrichten mit sogenannten Skelett- Trainings-Puffer Second-Chance- Algorithmus, Pre- Clustering, Skelett- Signatur