Die moderne E-Mail-Kommunikation beschert ihrem Nutzer neben dem erwünschten, schnellen und kostengünstigen Nachrichtenaustausch mit seinen gewohnten Kommunikationspartnern heutzutage den Empfang einer Vielzahl unerwünschter Nachrichten. Deren Bandbreite reicht von lästigen, aber harmlosen Werbesendungen bis zu schädlichen Programmen.
Um die Angriffspunkte des Mediums E-Mail zu veranschaulichen, werden vorangehend die standardisierte Funktionsweise des E-Mail-Versands und ihre Schwachstellen erläutert. Darauf aufbauend stellt der Autor die heutigen Probleme und Bedrohungen der E-Mail-Kommunikation dar und geht neben unerwünschten Werbebotschaften und Internetwürmern besonders auf die immer größere Gefährdung durch „Phishing“ ein, das den Benutzer zur unbedachten Herausgabe vertraulicher Informationen bewegen soll.
Im Folgenden werden schon länger eingesetzte Maßnahmen zusammengefasst, die im Rahmen dieser Standards die Probleme vermindern sollen. Zur effektiven Bekämpfung - insbesondere der Phishing-Problematik - sind jedoch weiter gehende Ansätze nötig, die die gängigen Standards erweitern oder verändern. Als Lösungsansatz stellt der Autor verschiedene Vorschläge zur Absenderauthentifizierung vor und bewertet abschließend ihre Perspektiven.
Inhaltsverzeichnis
2 Grundlagen der E-Mail-Kommunikation
2.1 Simple Mail Transfer Protocol (SMTP)
2.2 Die Rolle des Domain Name System
3 Probleme und Gefahren der E-Mail-Kommunikation
3.1 Kategorien unerwünschte E-Mails
3.1.1 Unverlangt zugesandte Werbung
3.1.2 Schadprogramme (Malware)
3.1.3.3 Angriffspunkte bei E-Mail-Clients
3.1.4 Angriffspunkte bei Webbrowsern
4.1 Alternativen zu Open Relays
4.1.1.1 SMTP Authentifizierung
4.2 Filterung nach äußeren Merkmalen
4.2.1 Realtime Blackhole Lists
5 Erweiterungen des Domain Name System
5.3 Public-Key-Verfahren zur Absenderauthentifzierung
1 Einleitung
Wie in anderen Ländern auch nimmt in Deutschland die Nutzung des Internets stetig zu und erreicht immer weitere Bevölkerungsschichten. Neben den Angeboten des World Wide Web bildet dabei die E-Mail-Kommunikation nach wie vor einen der wichtigsten Dienste dieses Mediums: Nach dem aktuellen Bericht des Statistischen Bundesamtes zur „Informationstechnologie in Unternehmen und Haushalten 2004“ ist die Hälfte der Deutschen mindestens einmal pro Woche im Internet aktiv und 80 % dieser deutschen Internetnutzer verwenden es für den Versand und Empfang von E-Mails (Hauschild et al., 2005, S. 5 / 36).
 |
Mit der zunehmenden Durchdringung der Bevölkerung mit dieser modernen Informations- und Kommunikationstechnologie wird das Medium auch immer mehr für unlautere Zwecke genutzt und dadurch von den Endanwendern in vielen Fällen als Sicherheitsrisiko wahrgenommen. Neben dem erwünschten Nachrichtenaustausch mit anderen Kommunikationspartnern beschert die E-Mail-Kommunikation ihren Anwendern einen stetig steigenden Anteil an unerwünschten Nachrichten. In der oben erwähnten Befragung des Statistischen Bundesamtes gaben 55 % der befragten Internetnutzer an, bereits unerwünschte E-Mails erhalten zu haben. Ein Drittel war bereits von Viren betroffen (Hauschild et al., 2005, S. 33).
Diese Zahlen zeigen bereits, dass im Bewusstsein der Anwender der E-Mail-Verkehr vor allem durch unerwünschte Werbebotschaften beeinträchtigt wird. Diese wirken für den Empfänger zwar störend, verursachen aber zunächst keinen direkten Schaden. Von Bedeutung sind hier eher indirekte Schäden, die derartige Mails mit sich bringen, wie Produktivitätsverlust der Mitarbeiter oder erhöhte Serverlast (siehe hierzu Kapitel 3.1.1.3).
Größeres Gefahrenpotential bergen per E-Mail eintreffende Schadprogramme wie Viren oder Würmer, die beim Anwender zu Datenverlusten und damit zu direkten Kosten führen können oder die Hardware des Empfängers für Zwecke wie Angriffe auf andere Server missbrauchen. Die in jüngster Zeit immer häufiger auftretenden „Phishing“-Attacken zielen direkt auf einen Vermögensschaden beim Empfänger zugunsten des Absenders ab. Dabei sollen Nutzer per E-Mail zur Herausgabe vertraulicher Informationen bewegt werden. Diese verschieden Probleme und Gefahren des E-Mail-Verkehrs stellt Kapitel 3 näher vor und geht dabei insbesondere auf die Phishing-Problematik ein.
Um die Angriffsflächen des E-Mail-Verkehrs aufzuzeigen, beleuchtet Kapitel 2 zunächst die der Mailkommunikation im Internet zugrunde liegenden Abläufe und genutzten Protokolle, bevor anschließend technische Maßnahmen zur Abhilfe erläutert werden.
Insbesondere zur Spam-Bekämpfung haben in den letzten Jahren eine Reihe von Methoden Einsatz gefunden, die innerhalb der Grenzen der verwendeten E-Mail-Kommunikationsprotokolle das Aufkommen an erwünschten Nachrichten senken sollen beziehungsweise diese während oder nach der Zustellung erkennen und aussortieren. Einige der zur Verfügung stehenden Möglichkeiten und ihre grundlegenden Ansätze stellt das Kapitel 4 „Herkömmliche Gegenmaßnahmen“ beispielhaft vor.
Bei genauerer Betrachtung der in Kapitel 2 erkennbaren systemimmanenten Schwachstellen wird deutlich, dass diese Gegenmaßnahmen eigentlich nur Probleme im Nachhinein zu beseitigen versuchen, die durch Lücken der zugrunde liegenden Protokolle entstanden sind. Ein tiefer greifender Ansatz wäre hingegen, diese grundsätzlichen Probleme „an der Wurzel“ zu lösen durch Erweiterungen oder Änderungen der verwendeten Kommunikationsprotokolle. In der Diskussion befindliche Vorschläge hierzu stellt das Kapitel 5 vor, wobei der Schwerpunkt in dieser Arbeit auf dem Aspekt der Absenderauthentifizierung liegen soll.
2 Grundlagen der E-Mail-Kommunikation
E-Mail-Nachrichten werden heute zumeist über TCP/IP-Verbindungen übertragen, für die entsprechende Protokolle auf der Anwendungsschicht gemäß des ISO/OSI-Referenzmodells definiert sind. Im Zusammenhang mit unerwünschten E-Mails ist von den der E-Mail-Kommunikation zugrunde liegenden Übertragungsprotokollen hauptsächlich das Simple Mail Transfer Protocol (SMTP) relevant, das den Versand und die Zustellung von E-Mails zu und zwischen Mailservern, so genannten Message Transfer Agents (MTA), regelt. Dabei nutzt es Informationen, die durch das Domain Name System (DNS) bereitgehalten werden.
Anwendungsprotokolle wie POP3 oder IMAP zum Abruf der E-Mails von einem Mailserver, werden in diesem Kontext nicht weiter betrachtet. Die anhand eines dieser Protokolle abgerufenen E-Mails haben den Mailserver in der Regel zuvor per SMTP erreicht, so dass für die Problematik der unerwünschten E-Mail von nachgeordneter Bedeutung sind. (Dietrich & Pohlmann 2005, S. 2)
2.1 Simple Mail Transfer Protocol (SMTP)
SMTP wurde Anfang der 80er Jahre durch Postel (1981) definiert. Es überträgt sowohl Kontrollbefehle wie auch Inhalt der Mail als ASCII-Text, so dass man sogar mit einem einfachen Telnet-Client eine SMTP-Verbindung simulieren kann. Der Befehlssatz ist klein gehalten, zum Versand einer E-Mail werden nur vier verschiedene Kommandos. benötigt. Die Antworten des Servers erfolgen in Form von dreistelligen Reply-Codes, die um Statusmeldungen im Klartext ergänzt werden.
Rechner bzw. die auf ihnen laufenden Software-Komponenten, die untereinander E-Mail-Nachrichten per SMTP austauschen, werden in der Terminologie nach Postel (1981) als Message Transfer Agents (MTA) bezeichnet. Die Komponente, mit der Benutzer interagiert, ist der Mail User Agent (MUA).
2.1.1 Protokollablauf
Der sendende Rechner (Client) baut zunächst eine TCP-Verbindung zum Zielserver (üblicherweise über TCP-Port 25) auf. Auf Basis dieser Verbindung werden die einzelnen Kommandos und Inhalte als ASCII-Text übertragen (siehe Abbildung 2). Sobald die Verbindung hergestellt ist, meldet sich der angesprochene Mailserver mit einer Willkommensnachricht.
1. Der Client sendet daraufhin das Kommado „HELO“ gefolgt von seinem Rechnernamen als FQDN[1]. Der Server bestätigt das Kommando mit dem Statuscode 250 und begrüßt den sendenden Rechner.
2. Nun gibt der Client mittels des Kommandos „MAIL FROM:“ die E-Mail-Adresse des Absenders an. An diese würden beispielsweise Fehlermeldungen gesendet, die im weiteren Verlauf der Zustellung auftreten. Erst dadurch kann der Absender informiert werden, falls die angeschriebene E-Mail-Adresse gar nicht existiert oder das Postfach voll ist. Nimmt der Server Mails dieses Absenders an, bestätigt der das Kommando wiederum mit dem Statuscode 250.
3. Der Sender gibt die E-Mail-Adresse des Empfänger über das Kommando „RCPT TO:“ (RCPT: Recipient = Empfänger) an. Ist dieselbe Mail an mehrere Nutzer dieses Mailservers gerichtet, wird das Kommando mehrfach mit Angabe der verschiedenen Adressen gesendet. Wenn der Server für die jeweilige Adresse zuständig ist oder die Mail an einen anderen, zuständigen Mailserver weiterleiten kann, wird sie angenommen und bestätigt. Andernfalls lehnt der Mailserver diese Adresse mit entsprechender Fehlermeldung ab.
4. Mit dem „DATA“-Befehl leitet der Client die Übertragung des Mailinhalts ein. Die Übertragung erfolgt im Klartext und wird durch eine Sequenz Leerzeile, „.“ und Leerzeile abgeschlossen. Bestätigt der Server diese Eingabe („Queued mail for delivery“), ist die Zustellung aus Sicht des Clients erfolgreich abgeschlossen.
5. Der Client beendet die Verbindung durch den Befehl „QUIT“.
Abbildung 2: Versand einer E-Mail nach SMTP-Protokoll
Neben den erläuterten Kommandos sieht der SMTP-Standard noch weitere, wenn auch wenige Befehle vor. In diesem Zusammenhang ist besonders das „VRFY“-Kommando erwähnenswert (= Verify). Es ermöglicht die Verifikation einer E-Mail-Adresse durch den Mailserver, ohne dass eine Nachricht zugestellt werden muss. Heutzutage sollte dieser Befehl deaktiviert sein, damit Spammer dieser Weg zum Herausfinden gültiger Adressen durch Ausprobieren verwehrt bleibt.
2.1.2 Struktur
Wie bei einem herkömmlichen Brief aus der realen Welt wird auch die Struktur
von E-Mails unterschieden zwischen dem Umschlag (Envelope), dem
Briefkopf (Header) und dem eigentlichen Inhalt (Body).
Die während der SMTP-Kommunikation als „MAIL FROM:“ und „RCPT TO:“ angegebenen Adressen bilden den Umschlag. Analog zum Postbrief werden diese Daten nur für die Zustellung zum Mailserver verwendet und vom empfangenden Server anschließend verworfen.
Im SMTP-Standard ist für die im „Envelope“ angegebene Absenderadresse keine Überprüfung vorgesehen, genauso wenig wie die Post die Korrektheit einer Absenderangabe auf einem Briefumschlag verifiziert. Doch genau wie im Beispiel der realen Welt wird eine Nachricht an dort angegebenen Absender zurückgesandt, wenn die Zustellung nicht erfolgen kann.
Der Aufbau der eigentlichen Nachricht, die durch den „DATA“-Befehl eingeleitet wird, ist in RFC 2822 spezifiziert und teilt sich auf in Header und Body (vgl. Resnick 2001). Vergleichbar mit einem Briefbogen sieht diese Angaben nur der Empfänger der E-Mail, während Mailserver auf dem Transport normalerweise Adressangaben im Briefkopf ignorieren. Sie können allerdings weitere Angaben zum Kopf hinzufügen, so zu Beispiel „Received“-Header (siehe Abbildung 8 ). Da der Empfangs-MTA den Umschlag verwirft, basieren alle Daten, die der Benutzer in seinem E-Mail-Anwendungsprogramm sieht, auf den Einträgen im Header, neben Betreff und Datum[2] eben auch Absender und Empfänger.
2.1.3 Mail Relaying
Nach obiger Darstellung könnte man annehmen, dass beim Mailversand der PC des
Senders direkt den MTA des Empfängers kontaktiert. Dies ist zwar grundsätzlich
möglich, wird in der Regel aber nicht praktiziert. Üblicherweise schickt der
Versender sämtliche E-Mails an einen so genannten Smarthost oder
Relay, jenen Server, den der Anwender in seinem E-Mail-Client als
SMTP-Server eingerichtet hat. Er wird typischerweise vom Internetprovider oder
im Firmennetzwerk bereitgestellt und nimmt sämtliche E-Mails des Empfängers
entgegen. Ein MTA ist für bestimmte E-Mail-Adressen oder –Domains zuständig und
fungiert für diese als Ziel-MTA. Erhält ein als Relay konfigurierter Server
eine E-Mail, für die er nicht Ziel-MTA ist, leitet er die Nachricht weiter an
den zuständigen Server.
Relays können das vom Versender zu übertragene Datenvolumen verringern, wenn ein- und dieselbe E-Mail an viele Empfänger gesendet werden soll. Der Sender muss die Nachricht nur ein Mal zum Relay übertragen und die Empfänger in mehreren „RCPT TO:“-Befehle angeben. Die Zustellung zu dem für eine einzelne Adresse zuständigen MTA übernimmt dann der Relay. Dieses Verfahren können sich jedoch auch Spammer zu nutze machen, wenn sie fremde Server unberechtigterweise als Relay zur Zustellung von Massen-E-Mails missbrauchen, da die wesentlich Übertragungskosten dabei auf Seiten des Serverbetreibers liegen.
2.2 Die Rolle des Domain Name System
Woher weiß ein MTA beim Versand einer E-Mail, welches der für diese Zieldomain zuständige MTA ist? Diese Information erhält er aus dem Domain Name Systen (DNS), das hauptsächlich für die Umsetzung von Rechner- und Domänennamen (FQDNs, siehe 1) in Adressen des zugrunde liegenden Netzwerkprotokolles IP zuständig ist (Mockapetris 1983).
Das Domain Name System wird von der Internetverwaltung ICANN betreut und ist als verteilte Server-Hierarchie realisiert, in der die Verantwortung für die Einträge einer Domain bei ihrem offiziellen Inhaber bzw. dem von ihm beauftragten Provider liegt. Bei Beantragung einer neuen Domain wird für diese bei der Verwaltung der zugehörigen Top-Level-Domain (bspw. .de oder .com) ein Hinweis auf den zuständigen DNS-Server erstellt, dessen Einträge im gesamten Internet für die neue Domain gelten. Dadurch kann nur der bei der Verwaltung registrierte Inhaber der Domain entscheiden, welche Server im Internet für sie zuständig sind und z.B. als Web- oder Mailserver eintragen sind.
Ein DNS-Server kann für jede Domain, die er verwaltet, Einträge verschiedener Typen vorhalten, so genannte Ressource Records (RR). Neben den Host Records (Typ A) für die Umsetzung von FQDNs in IP-Adressen gibt es den Eintragstyp Mail Exchanger (MX). Dieser gibt Auskunft über die MTAs, die für diese Domain zuständig sind. Muss ein Server eine Mail zustellen oder weiterleiten, kann er durch eine DNS-Abfrage den zu kontaktierenden Mailserver ermitteln.
Neben dem FDQN des zuständigen MTA gibt die Antwort die Priorität des Mailserver zurück. Somit lassen sich mehrere Mailserver einer Domain zuweisen, an die Zustellversuche in der angegebenen Reihenfolge gerichtet werden. Dabei hat der Server mit der niedrigsten Zahl die höchste Priorität, so dass die Zustellung zuerst bei ihm versucht. Ist der Mailserver nicht erreichbar, wird der mit der nächstniedrigeren Priorität (i.e. nächsthöher Zahl) kontaktiert. Unterschiedliche Server mit identischem Prioritätswert gelten als gleichberechtigt, so dass so Lastteilung zwischen den Mailservern erreicht werden kann.
3 Probleme und Gefahren der E-Mail-Kommunikation
Die bereits in der Einleitung erwähnte Studie des Statistischen Bundesamts (Hauschild et al. 2005) zeigt, über welche Reichweite das Medium E-Mail in Deutschland verfügt. Gleichzeitig wird aber auch erkennbar, welches Ausmaß der Empfang unverlangter E-Mail heute erreicht hat, da mehr als die Hälfte der deutschen Internetnutzer angeben, bereits unerwünschte Nachrichten erhalten zu haben (Hauschild et al. 2005, S. 33).
E-Mail ist als ein offenes System realisiert, das technisch keinerlei Beschränkungen in der Kommunikation zweier Teilnehmer vorsieht: Jeder Internetnutzer kann grundsätzlich jedem Inhaber einer gültigen E-Mail-Adresse eine Nachricht zukommen lassen, sofern dem Versender diese Zieladresse bekannt ist. Was eine weltweite Kommunikation aller Internetteilnehmer ermöglichen soll, eröffnet andererseits Mailversendern mit unlauteren Absichten die schnelle und kostengünstige Verbreitung ihrer Botschaften.
Ein wesentlicher Faktor für das hohe Aufkommen unerwünschter E-Mail, insbesondere mit Werbeinhalten, ist auch der niedrige Kostenaufwand auf Seiten des Versenders. Verglichen mit herkömmlicher Direktwerbung per Post oder Wurfsendung sind die Kosten pro Zustellung vernachlässigbar gering. Im (für ihn) günstigsten Fall nutzt der Versender keine eigenen Server, sondern verwendet Ressourcen Dritter, die für die entstehenden Kosten aufkommen müssen (siehe 2.1.3).
Üblicherweise werden unerwünschte Mails massenhaft von bestimmten Absendern an eine Vielzahl von Empfängern gesendet. Als Oberbegriff für unverlangte E-Mails wird daher die englische Bezeichnung Unsolicited Bulk Email (UBE) verwendet. Je nach Inhalt lässt sich UBE hauptsächlich in drei verschiedene Unterkategorien einteilen, die im Weiteren näher erläutert werden sollen:
- Werbemails („Spam“)
- Mails mit schädlichen Inhalten
- so genannte „Phishing“ Attacken.
3.1 Kategorien unerwünschter E-Mails
3.1.1 Unverlangt zugesandte Werbung
Besonders durch unverlangt zugesandte Werbung wird dem E-Mail-Nutzer der häufige Empfang unerwünschter Mails deutlich. Bereits aus der Betreffzeile kann er oft schon erkennen, dass es sich nicht um relevante Inhalte handelt. Doch durch geschickte Gestaltung der Betreffzeile – persönliche Ansprache oder Stichworte wie „letzte Mahnung“ – versuchen die Versender, den Leser doch noch zum Öffnen und Lesen der Nachricht zu bewegen.
3.1.1.1 Definition
Werbemails als Spezialfall der unverlangten Massen-E-Mails (UBE, siehe oben) werden als Unsolicited Commercial Email (UCE) bezeichnet, also unverlangte E-Mails mit kommerziellem Hintergrund.
Inhaltlich werben in UCE meist unseriöse Anbieter für Waren oder Dienstleistungen mit zweifelhaftem Gebrauchswert. So werden in UCE vielfach Wundermittel für diverse Beschwerden, Kreditangebote, Geldanlangen oder kostenpflichtige Internetangebote beworben.
Im Sprachgebrauch hat sich allerdings vor allem der Begriff Spam eingebürgert. Meist ist damit UCE gemeint (Wikipedia 2005a), aber vielfach wird der Begriff auch allgemeiner für jegliche Form unerwünschter E-Mail, also UBE, verwendet (vgl. Dietrich & Pohlmann 2005, S. 3). Bei diesem englischen Wort handelt es sich eigentlich um ein Warenzeichen für Dosenfleisch, das sich aus spiced und ham zusammensetzt. Es hat sich ursprünglich aus einem Sketch der englischen Komikergruppe Monty Phython zu einem Wort für Unnützes und Unerwünschtes entwickelt: In diesem Sketch werden einem Restaurantbesucher vom aufdringlichen Personal immer wieder Gerichte mit Dosenfleisch angeboten, obwohl der Gast ausdrücklich etwas anderes verlangt. Im Internet wurde Spam in diesem Sinne zunächst im Bereich des Usenet verwendet, als massenhaft thematisch unpassende Beiträge ohne Bezug zur laufenden Diskussion in den Usenet-Gruppen veröffentlicht wurden. Schließlich wurde der Begriff auf ähnlich gelagerte E-Mail-Nachrichten übertragen (vgl. Wikipedia 2005b).
3.1.1.2 Aufkommen
Erhebungen zum Ausmaß der Spam-Problematik zeigen, dass derzeit mit einem Anteil
zwischen 60% und 90% unerwünschter Nachrichten am gesamten Mailaufkommen zu
rechnen ist (vgl. Dietrich &
Pohlmann 2005, S. 2).
Das Unternehmen MessageLabs ist nach eigenen Angaben (siehe Messagelabs 2004, S. 3) größter
Anbieter von Dienstleistungen im Bereich E-Mail-Sicherheit und durchsucht als
Application Service Provider für über 10.000 Unternehmen den E-Mail-Verkehr auf
Spam und Viren. In 2004 wurden auf den von MessageLabs administrierten Systemen
insgesamt 12,6 Milliarden Nachrichten gescannt. Von diesen wurden 9,2
Milliarden als Spam klassifiziert, was einem Anteil von 73 % entspricht.
In den einzelnen Monaten des Jahres schwankte der Prozentsatz zwischen 53 und
95 (siehe Abbildung 5). Besonders deutlich wird die insgesamt steigende
Tendenz, wenn man die Zahlen aus 2004 mit den Anteilen aus den beiden Vorjahren
von 40 % (2003) und 9% (2002) vergleicht.
(Messagelabs 2004, S. 6)
Auf ähnliche Zahlen kommt der deutsche Antispam-Dienstleister CleanMX in seinem monatlichen „Spam Report Deutschland“ (CleanMX 2005): So betrugt der Anteil von E-Mails, die Spam beziehungsweise Viren beinhalteten, im Januar 2005 90% verglichen mit 83 % im Vormonat.
3.1.1.3 Kosten
Jeder Abruf einer E-Mail vom Mailserver durch den Empfänger bindet Übertragungskapazitäten für die Dauer der Übermittlung. Ist das Postfach des Empfängers auf dem Server eines Providers untergebracht, erfolgt der Abruf über eine in der Regel kostenpflichtige Internetverbindung, die entweder nach übertragener Datenmenge oder Nutzungsdauer abgerechnet wird. Jeder Abruf einer E-Mail verursacht damit zusätzliche Kosten – von pauschal abgerechneten Internetzugängen einmal abgesehen, doch bindet auch hier die Übertragung unerwünschter Mails Bandbreite, die für andere Zwecke hätte genutzt werden können.
In größeren Organisationen befindet sich der Mailserver, der die Postfächer der Anwender vorhält, in der Regel im lokalen Netzwerk, so dass für den einzelnen Mailabruf das Anwenders keine weiteren, direkt zurechenbaren Kosten durch den Internetprovider entstehen. Stattdessen fallen die Kosten der Übertragung jedoch im Moment der Zustellung an den Mailserver an. Nur in der Konstellation, dass dieselbe unerwünschte E-Mail an mehrere Empfänger in der gleichen Domain des Mailservers adressiert ist, würde sie nur einmal über die kostenpflichtige Leitung übertragen, obwohl sie mehrere interne Benutzer erreicht.
Betrachtet man das Volumen einer einzelnen, wenige Kilobyte großen Spam-E‑Mail, erscheint der Kostenfaktor der Übertragung gering. In größeren Organisationen mit mehreren hundert bis tausend Nutzern auf einem Mailserver bedeutet diese Zahlen, dass bis zu 90 % der Auslastung von Hardware und Datenleitung für unerwünschte Mails aufgewendet werden.
Hinzu kommen die unnötige Ablenkung durch eingehende Spam-E-Mails und der daraus resultierende Verlust an Produktivität des einzelnen Mitarbeiters. Je mehr das persönliche E-Mail-Postfach von unerwünschten Nachrichten durchsetzt ist, umso mehr Zeit kostet es den Empfänger, die relevanten Nachrichten zu erkennen und zu bearbeiten. Zudem kann jeder Nachrichteneingang die Aufmerksamkeit des Anwenders erregen und von anderen Tätigkeiten abhalten, wenn er sich gerade am Rechner aufhält. Das Markforschungsunternehmen Nucleus Research geht davon aus, dass 2004 3,1% der Produktivität durch Spam verschwendet worden ist, was pro Mitarbeiters Kosten in Höhe von $ 1.934 verursacht habe (Nucleus Research 2004, S.1).
3.1.2 Schadprogramme (Malware)
Während Spam-E-Mails nur Werbefunktionen erfüllen und eher indirekt Kosten verursachen, indem sie durch die bloße Beschäftigung mit ihnen Zeit des Empfängers verschwenden und durch ihre schiere Menge die Systeme auslasten, zielen Schadprogramme direkt auf Schäden beim Anwender oder Missbrauch seiner Hardware. Dies können beispielsweise Datenverluste beim Anwender durch Löschen oder Manipulieren von Festplatteninhalten sein oder der Missbrauch des Rechners für
- ferngesteuerten, massenweisen Versand von Spam-E-Mails (Spam-Bots) ,
- verteilte Angriffe auf populäre Internetserver (Denial-of-Service-Attacken)
- Weiterverbreiten des Schadprogramms an andere Rechner im lokalen Netzwerk oder per E-Mail.
 |
Bager & Mollard (2004, S. 142) geben beispielsweise an, dass heutzutage 30-40 % aller Spam-Mails von infizierten „Zombie-PCs“ ohne Wissen ihrer Besitzer versendet werden.
Genau genommen wird Malware unterschieden in Viren, Würmer und Trojaner (Wikipedia 2005d):
- Viren stellen die Urform der Computerschädlinge dar und sind ursprünglich Schadroutinen, die sich an vorhandenen Programmcode oder Dokumente anhängen und somit „infizieren“.
- Charakteristisch für Würmer ist der Versuch, sich über lokale oder globale Netzwerke wie das Internet auf andere Rechner weiter zu verbreiten, um auch diese zu befallen
- Trojaner müssten analog der griechischen Mythologie korrekterweise Trojanische Pferde genannt werden, da es sich um anscheinend sinnvolle, oft gratis zur Verfügung gestellte Software handelt, die versteckte Schadfunktionen, beispielsweise Hintertüren ins System, beinhaltet.
Im Sprachgebrauch werden diese Ausprägungen allerdings nicht immer sauber unterschieden, sondern häufig alle drei Arten an Malware mit der Bezeichnung Viren als Oberbegriff gleichgesetzt. So zeigen auch die von Sophos 2004 gemeldeten „Top-Ten Viren“, dass es sich in der Hauptsache um Würmer handelt, erkennbar an der Spezifikation W32 für Würmer auf 32bit Windows Systemen.
3.1.2.1 Aufkommen
Verglichen mit der Spam-Problematik ist das Aufkommen an E-Mails, die Malware enthalten, relativ gering. MessageLabs (2004, S. 7) identifiziert für das Jahr 2004 einen Anteil von 6,1 % mit Viren, Würmern oder Trojanern infizierter Mails in den von MessageLabs betreuten Mailsystemen, in denen im Jahresverlauf 147 Mrd. Nachrichten auf Viren überprüft worden waren. Dietrich & Pohlmann (2005, S. 4) haben bei den befragten Organisationen sogar nur ein Virenaufkommen von durchschnittlich 2,9 % ermittelt, wobei der Anteil je nach Art der Einrichtung schwankt.
3.1.2.2 Erkennung
Malware läßt sich relativ einfach durch geeignete Virenscanner erkennen, sofern die Software über aktuelle Vireninformationen verfügt. Da E-Mails mit dem gleichen Virus trotz möglicherweise abweichenden Nachrichtentexts meist den identischen Programmcode enthalten, kann über die Charakteristika der Malware ein solches Erkennungsmuster gebildetet werden, welches dem Scanner zur Identifizierung dient.
3.1.2.3 Verbreitung
Per E-Mail verbreiten sich Schadprogramme durch aktiven Programmcode, der in der Nachricht enthalten sein muss und sich meist plattformspezifisch gegen Microsoft Windows-Betriebssysteme richtet. Typisch hierfür sind an die E-Mail angehängte ausführbare Dateien mit Endungen wie EXE, COM, PIF oder SCR. Mitunter sind diese noch in zunächst unverdächtig erscheinende Archive (ZIP-Dateien) verpackt. Dateianhänge erfordern in der Regel das Öffnen durch den Benutzer, bevor das Schadprogramm aktiv werden kann. Immer öfter nutzen Schadprogramme aber auch Sicherheitslücken in E-Mailprogrammen oder Webbrowserkomponenten durch manipulierte Bilddateien oder Scriptcode im Quelltext einer HTML-E-Mail aus, so dass hier schon das Öffnen und Betrachten ausreicht, um das Schadprogramm zu aktivieren. (vgl. Heise Security 2005)
Sicherheitslücken in E-Mailprogrammen, die die direkte Ausführung von Malware ohne Öffnen eines Anhangs ermöglichen, werden nach ihrer Entdeckung innerhalb mehr oder weniger kurzer Zeit vom Hersteller behoben. Eine entsprechend schnelle Reaktionszeit des Herstellers und regelmäßige Updates durch den Anwender vorausgesetzt, könnte Malware also nur begrenzte Zeit auf diesen Lücken aufbauen.
Daher legen es die Programmierer von Schadprogramm immer mehr darauf an, den Anwender durch geschickte inhaltliche Gestaltung der E-Mail dazu zu bewegen, einen Dateianhang auszuführen. Dies wird umso schwieriger, je besser der Anwender für die Gefährlichkeit von ausführbaren Dateianhängen sensibilisiert worden ist. Je mehr Problembewusstsein durch Öffentlichkeitsarbeit oder firmeninterne Weiterbildungen zur IT-Sicherheit geschaffen worden ist, umso weniger werden Anwender bereit sein, Dateianhänge von unbekannten Absendern zu öffnen.
3.1.2.4 Beispiel Sober.I
 |
Darauf haben die Entwickler von Malware reagiert, in dem sie immer besser den Eindruck einer vertrauenswürdigen Nachricht zu erwecken versuchen. Ein besonders perfides Beispiel hierfür bietet der Internetwurm Sober.I, der Ende 2004 eines der am weitesten verbreiteten Schadprogramme war (vgl. Sophos 2004).
Abbildung 7 zeigt eine typische mit Sober-I infizierte E-Mail, die befallener Rechner an ein Postfach der Domain @cs.uni-hildesheim.de gesendet hat, wie sie vom Mailclient des Anwenders gezeigt würde. Betrachtet man die Informationen zum Absender, kommt die Nachricht vermeintlich aus der Domain des Internetproviders T-Online. Die E-Mail-Adresse info@t-online.de soll hier als eine zu administrativen Zwecken genutzte Adresse des Providers erscheinen, da Adressen wie info@, kontakt@ oder support@ üblicherweise nicht von individuellen Benutzern der Domain genutzt werden, sondern allgemein der Kontaktaufnahme mit dem Unternehmen beispielsweise in Problemfällen dienen sollen. Außerdem erscheint „T-Online“ im Dateinamen des Anhangs sowie innerhalb der vermeintlichen Fehlermeldung. Zusätzlich verweist wird zu Beginn der Mail auf die T-Online Webseite für weitere Informationen hingewiesen.
Die E-Mail soll schon durch den entsprechenden Betreff, vermeintliche Fehlerausgaben eines Mailservers und die beschriebene sonstige Gestaltung den Eindruck erwecken, es handle sich um eine automatische Mitteilung von einem Server eines Internetdienstleisters. Dem Empfänger wird suggeriert, er selbst hätte die Fehlermeldung beim vorangehenden Versand einer E-Mail zerzeugt und müsse darauf reagieren. Um die ursächliche E-Mail für diese Fehlermeldung zu sehen, soll der Anwender den Dateianhang öffnen, bei dem es sich tatsächlich um eine ausführbare Datei mit dem Code des Schadprogrammes handelt.
Betrachtet man jedoch in den Kopfzeilen der E-Mail die Received-Einträge, die
der empfangende Mailserver hinzugefügt hat (siehe Abbildung 8), wird man
feststellen, dass die Mail in Wirklichkeit nie über Mailserver von T-Online
gesendet worden ist. Sober.I nutzt also hier unter anderem die fehlende
Überprüfung der Absenderadressen aus, um durch einen gefälschten Absender
Vertrauen zu erwecken und den Anwender zum Öffnen des Anhangs zu bewegen.Führt
der Benutzer diesen aus, installiert sich der Wurm auf seinem Rechner und
sendet sich an weitere E-Mail-Adressen, die im Adressbuch des E-Mailprogramms
finden kann.
Bei Sober.I kommt hinzu, dass er eine Vielzahl unterschiedlicher Absenderdomain, Betreffzeilen und Fehlermeldungen im Nachrichtentext permutiert und so die Erkennung durch Virenscanner erschwert. Außerdem wird am Ende des Nachrichtentextes der Vermerk auf einen bestandenen Virustest hinzugefügt. Dieser verweist auf eine Webseite der Domain des Empfängers und verstärkt beim Leser der Nachricht auf subtile Weise den Eindruck, es handle sich um eine unbedenkliche Nachricht.
3.1.3 Phishing
Vertrauen gegenüber Inhalt und Absender einer E-Mail ist auch zentraler Angriffspunkt der in jüngster Zeit immer häufiger auftretenden so genannten Phishing-Angriffe. Der Begriff leitet sich von Fishing (=Fischen / Angeln) ab. Die Verfälschung der korrekten englischen Orthografie ist dabei ein Kennzeichen für typischen Internet- oder Hackerjargon, das sich auch bei anderen Wörtern dieser Szenesprache wie Warez (= „where is“) oder Crackz findet (vgl. Wikipedia 2005c) findet.
Wie der Name nahe legt, handelt es sich dabei um das „Angeln“ von vertraulichen Informationen, die ein Internet-Benutzer auf den Erhalt einer E-Mail als Köder preisgeben soll. Es zielt ab auf persönliche Informationen und Auktionsplattformen, die ein Betrüger zum Betrug oder Identitätsdiebstahl nutzen kann, wie Zugangsdaten für Online-Banking, Kreditkartennummern oder Passwörter für Onlineshops.Durch Fälschung des Absenders und die weitere Gestaltung der Nachricht entsteht der Eindruck, die Mail stamme von einer vertrauenswürdigen Einrichtung, mit der der Empfänger in Verbindung steht.
3.1.3.1 Aufkommen
Besonders
in der zweiten Jahreshälfte 2004 haben sich Phishing-Mails stark verbreitet: Im
Oktober haben die Filtersysteme von Messagelabs fast 5 Mio. E-Mail mit Links zu
betrügerischen Webseiten verzeichnet (MessageLabs
2004, S. 8). Die Anti-Phishing Working
Group (2005, S. 1) hat im Februar 2005 insgesamt über 2600
unterschiedliche aktive Phishing-Websites ermittelt, während es im November
noch knapp über 1500 waren (siehe ). Die Steigerungsrate dieser Zahl seit Juli
des Vorjahres entspricht dabei 26 % .
3.1.3.2 Funktionsprinzip
E-Mails dienen beim Phishing hauptsächlich der Verbreitung der Nachrichten, mit denen der Benutzer zur Eingabe der erhofften Daten auf einer verlinkten Webseite aufgefordert werden soll. Ein Phishing-Betrüger würde so massenhaft E-Mails beispielsweise unter dem Absender eines bekannten Kreditinstituts versenden in der Hoffnung, unter den Empfängern Kunden der Bank zu erreichen, die dem Link folgen und die Daten preisgeben.
Auch der Inhalt der Phishing-Emails macht dabei von Methoden des Social Engineerings Gebrauch (vgl. Wikipedia 2005c), indem er einen vertrauten Absender vorspiegelt. Oft wird dabei Druck auf den Benutzer ausgeübt, dass er bei Nichtbeachtung der Nachricht negative Konsequenzen zu tragen habe. So könnte ihm beispielsweise mit einer Kontosperrung gedroht werden, falls er nicht auf der angegebenen Webseite die geforderten Angaben macht.
3.1.3.3 Angriffspunkte bei E-Mail-Clients
Dabei macht sich der Versender die Unzulänglichkeiten der E-Mail-Zustellung zu nutze, indem er den Absender so fälscht, dass die Nachricht von der vorgegebenen vertrauten Stelle zu kommen scheint. Außerdem nutzt er Schwachstellen von E-Mail-Clients aus, um das tatsächliche Ziel eines scheinbar vertrauenswürdigen Links in der E-Mail zu verschleiern. So könnte beispielsweise in einer HTML- E-Mail der Text http://www.postbank.de sichtbar, der Text jedoch mit völlig einer anderer URL auf dem Webserver eines Betrügers verknüpft sein. Andere Phishing-E-Mails beinhalten Scripting Code, der auf Windows-Rechnern die zur Namensauflösung verwendbare Hosts-Datei manipuliert. Der Code fügt der Datei einen Eintrag für die Website zum Beispiel einer Bank hinzu, verknüpft diesen aber mit der IP-Adresse eines anderen, nicht vertrauenswürdigen Webservers. In der Konsequenz könnte der Benutzer in seinem Webbrowser zwar die Internetadresse seiner Bank eingeben kann, aber tatsächlich mit dem Webserver des Betrügers verbunden werden. Wenn die gefälschte Seite in ihrer Gestaltung der Originalseite nachempfunden ist und der Benutzer nicht auf ein korrektes Sicherheitszertifikat achtet, würde er seine Zugangsdaten einem Betrüger übermitteln.
3.1.4 Angriffspunkte bei Webbrowsern
Hauptproblem beim Phishing sind aber Unzulänglichkeiten bei Webbrowsern, der schließlich zum Aufruf der gefälschten Webseite verwendet wird. Durch eine geschickte Manipulation von HTML-Frames können beispielsweise fremde Inhalte im Rahmen der Originalseiten angezeigt werden, so dass Menüstruktur und angezeigte Internetadresse noch authentisch sind, das Formular zur Dateneingabe aber von einer nicht vertrauenswürdigen Seite stammt und die Eingaben an Dritte sendet. Dies fiele selbst bei einer gesicherten HTTPS-Verbindung mit Zertifikaten nicht auf, da sich das Hauptfenster mit der Adressangabe tatsächlich auf der korrekten Seite befindet. (Heise Security 2005a).
Die weiteren Schwachstellen von Webseiten und -browsern, die sich Phishing hauptsächlich zunutze macht, werden an dieser Stelle nicht weiter vertieft, da sie nicht ursächlich mit der E-Mail-Kommunikation zusammenhängen. Phishing im großem Umfang wird jedoch durch die Unzulänglichkeiten des E-Mail-Verkehrs – vor allem der einfachen Fälschbarkeit der Absenderadressen – erst möglich, da die gesendeten Phishing-Mails Ausgangspunkt für den Aufruf der gefälschten Webseiten sind.
4 Herkömmliche Gegenmaßnahmen
4.1 Alternativen zu Open Relays
Ursprünglich war jeder Mailserver im Internet als Relayhost konfiguriert, um bei temporärem Ausfall eines Systems eine zuverlässige Weiterleitung zu erreichen. Wie gezeigt (siehe 2.1.3), können Relays jedoch sehr einfach zum massenweisen Versenden von E-Mails missbraucht werden, wofür der Serverbetreiber die Kosten trägt. Mailserver, die von jedem Rechner im Internet Mail für jede beliebige E-Mail-Adresse entgegennehmen und diese an den für die Adresse zuständigen MTA weiterleiten, werden als Open Relays bezeichnet. Logfiles von Mailservern zeigen, dass Spammer sich jeden Tag auf der Suche nach solchen offenen Relays befinden, die sie für ihre Zwecke missbrauchen können.
Oberste Prämisse ist es also für jeden Betreiber eines Mailservers,
- den Relaybetrieb zu deaktivieren, so dass er nur Mails entgegennimmt, für die er direkt zuständig ist oder
- den Relaybetrieb nur für bestimmte Clients zuzulassen.
4.1.1 IP-Filter
Eine Möglichkeit, Relaying nur bestimmten Clients zu erlauben, besteht schon auf IP-Ebene, Dies ist zum einen durch Firewalls denkbar, die den Zugriff zu einem Relayserver schon auf der Netzwerkebene filtern, so dass Clients von unberechtigten Adressen gar keine IP-Verbindung zu Relay aufbauen können.
Aber auch in gängiger Mailserversoftware lassen sich so genannte Whitelists konfigurieren, so dass nur von darauf enthaltenen IP-Adressen oder Adressbereichen Mails zur Weiterleitung entgegengenommen werden. Dieses Vorgehen ist vor allem interessant, wenn der Server Ziel-MTA für bestimmte Domains ist - also TCP/IP-Verbindungen von jedem möglichen Mailserver im Internet zulassen muss -, und gleichzeitig beispielsweise von eigenen Kunden zum Relaying genutzt werden soll.
Whitelists bzw. Filter auf IP-Ebene, die den Zugang zu Relay-Server nur bestimmten Client erlauben, können nur dann Anwendung finden, wenn sich die erlaubten Rechner tatsächlich auf einen bestimmten Adressbereich eingrenzen lassen. Das ist beispielsweise praktikabel bei internen Firmen-Netzwerken oder bei Relay-Servern von Internet-Providern, deren Kunden stets über bestimmte Adressen aus dem Bereich des Providers verfügen.
4.1.1.1 SMTP Authentifizierung
Da die Zugangssteuerung zu Relayservern nicht immer nur auf IP-Ebene realisierbar ist, wurde der SMTP-Standard um Anmeldeprozeduren erweitert (vgl. Myers 1999). Benutzer können sich durch Eingabe von Benutzernamen und Kennwort am Server anmelden, um ihm Mails an andere Domains zur Weiterleitung zu übergeben. Wird eine SMTP-Verbindung ohne Anmeldung aufgebaut, nimmt der Mailserver nur Nachrichten für lokale Domains an.
Außerdem ist die Servernutzung durch die benutzerspezifische Anmeldung weniger anonym, so dass der Serverbetreiber im Zweifelsfall nachvollziehen kann, welcher Benutzer den Server unter Umständen für das Versenden von Spam missbraucht.
Dies ist vor allem für Anbieter von E-Mail-Diensten interessant, deren Kunden von überall aus dem Internet auf den Mailserver zugreifen können sollen, so dass eine ausschließlich IP-basierende Zugriffssteuerung nicht in Frage kommt.
Eine Variante der SMTP-Authentifizierung ist das SMTP-after-POP-Verfahren. Es ist vor allem für ältere Mailclients geeignet, die noch nicht über die zur SMTP-Authentifizierung erforderlichen Erweiterungen verfügen. Hierbei muss sich der Benutzer sich nicht für den Sendevorgang authentizieren, sondern kurz vorher seine Mailbox per POP3-Verfahren abgerufen haben, welches seit jeher Authenfizierung vorsieht. (Wikipedia 2005e)
4.2 Filterung nach äußeren Merkmalen
4.2.1 Realtime Blackhole Lists
Auf IP-Ebene wird auch bei Realtime Blackhole Lists (RBL) sondiert. Allerdings steuern diese nicht den Zugang zu Relay-Servern, sondern sollen auf einem Ziel-MTA den Zugriff von offenen Relays verhindern. Damit kann der Mailserver bei Eingang einer Mail erkennen, ob diese möglicherweise von einem Offenen Relay versendet worden ist und es sich demnach höchstwahrscheinlich um Spam handelt.
RBLs sind im Internet verfügbare Datenbanken, in denen die IP-Adressen bekannter offener Relays (oder auch anderer als Spam-Versender bekannter Rechner) abgelegt sind. Sie können ähnlich wie DNS-Server abgefragt werden. Bei Eingang einer neuen Nachricht stellt der MTA eine Anfrage über den einliefernden Server an die konfigurierte RBL. Erhält er darauf eine positive Antwort, ist dieser als Spammer bekannt und der empfangende Mailserver kann die Mail abweisen.(vgl. Dietrich & Pohlmann 2004, S. 11)
Neben bekannten offenen Relay-Servern sind in RBL meist auch die IP-Adressbereiche verzeichnet, die Internetprovider ihren Kunden bei der Einwahl zuweisen. Endkunden benutzen zum E-Mail-Versand normalerweise den Smarthost ihres Providers, so dass von den Adressen aus diesem Bereich üblicherweise keine Mail direkt an die Ziel-MTAs zugestellt werden müssen. Erhält ein Mailserver eine Mail für eine lokale Domain von einer solchen IP, handelt es sich meist um Spam, den ein Kunde des Providers während einer Onlinesitzung von seinem eigenen PC verschickt.
4.2.2 Portfilter
Um die Nutzung seiner Internet-Zugänge zum Versenden von Spam zu vermeiden, hat der Provider AOL ausgehenden SMTP-Verbindungen seiner Nutzer eigene Server zwischengeschaltet: Versucht ein Kunde über seinen AOL-Internetzugang eine Verbindung auf den TCP-Port 25 (SMTP) zu einem anderen Rechner im Internet aufzubauen, leitet AOL diesen Verbindungsversuch auf den eigenen Server um. Auf diesem scannt AOL die ausgehenden Mails auf Spam- oder Virenverdacht und leitet erst nach bestandenem Test die Nachricht an den eigentlich kontaktierten Server weiter. AOL zufolge soll damit vor allem die Verbreitung der Schädlinge über das AOL-Netz durch wurminfizierte Rechner verhindert werden (vgl. Bleich 2005).
4.3 Inhaltsanalyse
4.3.1 Headeranalyse
Schon während der laufenden SMTP-Kommunikation kann ein Mailserver Envelope und Header auf Merkmale massenhaft versendeter E-Mails untersuchen. Auch ohne die in Kapitel 5 beschriebenen Erweiterungen lassen sich innerhalb gewisser Grenzen Angaben wie Absenderadresse oder Hostname auf Plausibilität untersuchen: Existiert der beim HELO-Kommando angegebene Name des Rechners nicht, handelt es sich höchstwahrscheinlich nicht um einen legitimen Zustellversuch. Die Existenz des Hostnamens kann durch eine einfache Abfrage beim DNS der angegebenen Domain überprüft werden. Ebenso lässt sich die Domain der Absenderadresse verifizieren, für die zumindest Host- oder Mailexchanger-Eintrag existieren sollten.
Die Analyse von Envelope- und Header-Angaben hat den Vorteil, dass eine Mail zurückgewiesen werden kann, noch bevor die SMTP-Kommunikation vollständig abgeschlossen ist. Der Server kann dabei auf das entsprechende SMTP-Kommando mit einem negativen Response-Code antworten, so dass der Sender über den gescheiterten Versandvorgang in Kenntnis gesetzt wird. Eine derart abgewiesene Mail gilt damit als nicht zugestellt.
4.3.2 Statische Filter
Moderne MTA-Software bietet die Möglichkeit, Filterlisten bestehend aus regulären Ausdrücken zu integrieren. In diese können für Spam oder Viren typische Wörter oder Zeichensequenzen integriert werden, die zum Abweisen der Mail führen. Ihr Nachteil ist, dass diese Listen manuell gepflegt werden müssen. Das macht es umso schwieriger, passende Regeln zu definieren, die unerwünschte E-Mails erfassen. Mit zu einfach gestalteten Filtern könnten erwünschte Nachrichten erfasst werden, während zu spezifische Filterdefinitionen nur auf wenige unerwünschte Mails passen.
4.3.3 Statistische Verfahren
Flexibler sind statistische Verfahren, bei denen es sich um selbstlernende Systeme handelt. Sie beruhen auf dem Prinzip der bedingten Wahrscheinlichkeiten nach Bayes (vgl. Linke 2003). Stark vereinfacht ausgedrückt, zählen sie die Häufigkeit bestimmter Wörter und vergleichen sie mit der Häufigkeit ihres Auftretens in zuvor gelernten Mengen von Spam-Mails und erwünschten Mails. Daraus berechnen sie die Wahrscheinlichkeit, dass es sich bei zu der prüfenden Mail um Spam handelt.
5 Erweiterungen des Domain Name System
5.1 MARID
MARID ist die Abkürzung für “MTA authorization records in DNS” und bezeichnet die grundsätzliche Überlegung, das Domain Name System (siehe 2.2) um Informationen über gültige MTAs zu erweitern.
Für die genaue Realisierung des MARID-Prinzips existieren bereits längere Zeit einige konkrete Vorschläge, die sich in Details unterscheiden. Vor allem die in der genauen Syntax der DNS-Einträge weichen sie voneinander ab. Außer ist in der Diskussion, ob nur die Absenderangabe im Envelope oder auch im Header überprüft werden soll.
Eine gleichnamige Arbeitsgruppe der IETF hatte den Auftrag, Umsetzungen des MARID-Konzeptes zu sammeln und zu einem neuen RFC zusammenzuführen. Im Folgenden seien einige der Vorschläge vorgestellt (nach Bager & Mollard 2004, Bleich 2004 und Topf 2004).
Da es unter den Mitgliedern unter Mitgliedern dieser Arbeitsgruppe jedoch nicht zu einer Einigung auf ein zu verabschiedendes Verfahren gekommen ist, hat sie sich im September 2004 wieder aufgelöst (vgl. Ermert & Bager 2004). Besonders Microsofts Patentansprüche auf sein bevorzugtes Verfahren Sender ID (siehe 5.2.3) hatten zu erheblichen Kontroversen unter den Teilnehmern geführt. Somit ist der weitere Fortgang des Standardisierungsprozesses momentan unklar. Die Teilnehmer wollen jedoch ihre einzelnen Vorschläge unabhängiger voneinander einreichen.
5.2 Reverse MX
Nach diesem Konzept soll auf dem DNS-Server einer Domain eine Liste gültiger MTAs vorgehalten und durch eine standardkonforme DNS-Abfrage abgerufen werden können. Da der DNS-Server einer Domain im offiziellen Registrierungseintrag zusammen mit Informationen zu ihrem Inhaber festgelegt ist, können nur diese Einträge nur autorisierte Personen verändern.
Dieser Ansatz überlässt dem Inhaber einer Domain die Verantwortung, Mailserver zum Versenden von E-Mails zu autorisieren. Dahinter steckt die Überlegung, dass der Domaininhaber als natürliche Person mit Name und Anschrift identifizierbar ist und für Missbrauch der durch ihn autorisierten Mailserver verantwortlich gemacht werden kann. Werden also unerwünschte E-Mails versendet und der einliefernde Server verfügt über einen gültigen Eintrag für die Absenderdomains, so muss der dieser im Einflussbereich des Inhabers liegen.
Stellt diese Mails jedoch ein Server zu, der nicht in der Liste der autorisierten MTAs enthalten ist, ist dies ein Indiz für gefälschte Absenderadressen und unerwünschte E-Mails. Voraussetzungen für die Effektivität des Ansatzes sind natürlich, dass für eine Domain diese Liste überhaupt vorhanden ist und Mail Exchanger diese bei Erhalt einer E-Mail auch abfragen.
5.2.1 Grundprinzip
Den ersten Entwurf des MARID-Konzepts stellt Danisch (2002) dar und liefert die Grundidee für die weiteren Implementierungen (vgl. Bager & Mollard, 2004, S. 143).
Er beschreibt das grundsätzliche Verfahren, Informationen über autorisierte MTAs einer Domain auf ihrem DNS-Server vorzuhalten. Da es sich dabei prinzipiell um das Gegenteil der unter 2.2 beschriebenen DNS-Einträge für Mail Exchanger handelt, hat Danisch die Bezeichnung „Reverse MX“ (RMX) gewählt: Statt die für eine Domain zuständigen empfangenden MTAs (MX) anzugeben, definieren sie die MTAs, die Mail mit Absenderadressen der Domain versenden dürfen. Danisch sieht für diesen Zweck die bereits existierenden Freitexteinträge (RR-Typ TXT) im DNS vor.
 |
Schickt beispielsweise joe@example.com eine Mail an walter@example.org, wird Joe diese im Normalfall über seinen SMTP-Server (SmartHost) mail.example.com absenden (1):
- Joes Mailserver ermittelt wie gewohnt durch eine DNS-Anfrage den MTA mail.example.org als Mailexchanger für die Domain example.org und stellt diesem die Mail zu.
- mail.example.org erfragt daraufhin beim DNS-Server der Domain example.com (bspw. ns.example.com) die Liste der autorisierten Hosts, die Mails mit Absenderadressen dieser Domain zustellen dürfen.
- In der Antwort des DNS-Servers ist auch mail.example.com enthalten, so dass mail.example.org die eingehende Nachricht akzeptiert und zustellt.
Würde nun ein Spammer über seinen Mailserver mail.spammer.com eine Mail von der Absenderadresse joe@example.com an mail.example.org zuzustellen versuchen, wäre dieser Mailserver nicht in der Liste der gültigen Sende-MTAs enthalten und die Mail würde abgewiesen.
5.2.2 Server Policy Framework
Das Spezifikation des Server Policy Framework (SPF) wurde ursprünglich unter der Bezeichnung “Sender Permitted From” veröffentlicht und von Mong Weng Wong, Chef des amerikanischen E-Mail-Anbieters POBox, als Open Source zur Verfügung gestellt. SPF basiert auf der Idee von RMX und überprüft dabei lediglich die Absenderangabe des Envelopes. Um die Problematik der E-Mail-Weiterleitungen zu entschärfen, hat SPF zusätzlich einen „Sender Rewriting Scheme“ genannten Workaround entwickelt.
Nach Bager & Mollard (2004, S.144) sollen bereits mehr als 20.000 Domains über SPF-Einträge verfügen. Zur einfachen Implementierung gibt für es gängige MTA-Software wie Sendmail oder Postfix bereits Updates. Neben AOL hat auch der deutsche E-Mail-Anbieter GMX SPF-Einträge veröffentlicht und nutzt das System ebenso für die Filterung eingehender Mails. Nach Bleich (2004, S. 136) werden bei GMX dadurch täglich 850.000 Mails aussortiert, die meisten allerdings aufgrund gefälschter AOL-Absender.
Die SPF-Freitexteinträge verfügen über eine einfache Syntax (siehe unten), für deren Generierung auf der SPF-Homepage ein Software-Assistent zur Verfügung steht.
Tabelle 1: Syntaxbeispiele für SPF
|
Beispiel 1: DNS-Eintrag: example.com IN TXT „v=spf1 +a:mail.example.com –all“ |
|
|
v=spf1 |
Versionsnummer |
|
+a:mail.example.com |
erlaube A RR mail.example.com |
|
-all |
verbiete alle übrigen |
|
Beispiel 2: DNS-Eintrag: example.com IN TXT „v=spf1 +mx –all“: Alle MTAs, für die MX-Einträge existieren, dürfen senden; alle übrigen nicht. |
|
Quelle: Topf 2004, S. 92
5.2.3 Microsoft Sender ID
Mit dem ursprünglich „Caller ID“ genannten Verfahren zur Absenderauthenfizierung hat Microsoft ein SPF sehr ähnliches Prinzip entwickelt. Der technische Unterschied besteht in der Struktur der TXT-Einträge: Anders als bei SPF sind diese in XML formatiert.
Das Parsen von XML-Daten erfordert allerdings einigen Aufwand verglichen mit der Freitextstruktur von SPF. Ein Mailserver müsste dazu über einen XML-Parser verfügen; die Interpretation der XML-Daten würde deutlich mehr Performance kosten. Noch problematischer ist nach Bleich (2004, S. 135) die Tatsache, dass Microsoft die Syntax zum Patent angemeldet hat: Soll das Verfahren in eine MTA-Software integriert werden, muss der Entwickler hierfür eine Lizenz erwerben, was Microsoft harsche Kritik insbesondere von Open-Source-Verfechtern eingebracht hat.
5.2.4 Einschränkungen
Es gibt jedoch durchaus Fälle, in denen eine E-Mail nicht durch für die Domain zuständige MTAs zugestellt wird, obwohl es nicht um Spam handelt:
Ein Beispiel sind E-Mail-Weiterleitungen: Beispielsweise möchte ein Nutzer die Nachrichten seines privaten E-Mail-Kontos an sein Postfach am Arbeitsplatz weitergeleitet bekommen. Bei vielen Anbietern kann man hierzu eine E-Mail-Weiterleitung konfigurieren. Private E-Mails gehen dabei zunächst auf dem zuständigen Mailserver des privaten Kontos ein. Dieser ändert lediglich die „RCPT TO“-Adresse im Envelope auf die dienstliche Adresse des Empfängers, aber lässt den „MAIL FROM“-Eintrag aber unverändert. Die umzuleitende Nachricht sendet er an den Mailserver am Arbeitsplatz. Somit ist die Mail durch einen nicht für die Domain der Absenderadresse autorisierten Server zugestellt worden, da der MTA des privaten Mailkontos im Regelfall nicht für die Domain des ursprünglichen Absenders zuständig ist (siehe Abbildung 11).
Abbildung 11: Absenderauthentifizierung schlägt fehl bei E-Mailweiterleitungen
5.3 Public-Key-Verfahren zur Absenderauthentifzierung
Einen anderen Ansatz verfolgen Verfahren, die unter dem Begriff „Message Authentication Signature Standard“ (MASS) zusammenfasst werden. Sie verwenden asymmetrische Verschlüsselung und bauen auf einer Public-Key-Infrastruktur auf. Prominentestes Beispiel sind Yahoos „DomainKeys“ (vgl. Bleich 2004, S. 137).
Hierbei fügt der Mailserver, von dem aus die Mail versendet wird, dem Header eine Signatur hinzu, in dem er einen Hashwert der Nachricht bildet und mit einem privaten Schlüssel chiffriert. Im DNS-Server der Domain ist der öffentliche Schlüssel hinterlegt, den der empfangende Mailserver abruft und zur Überprüfung der Signatur nutzt.
5.4 Festlegung von Sende-IPs
Dieser Vorschlag erweitert ebenso wie die vorangegangenen das Domain Name System, um effektiver gegen unerwünschte E-Mails vorzugehen. Anders als RMX- oder MASS-basierte Verfahren werden die nötigen Einträge aber nicht auf den DNS-Servern von möglichen Absenderdomains vorgenommen. Stattdessen soll durch ein Flag für jede IP-Adresse vermerkt werden, ob sich dahinter ein Mailserver verbirgt oder nicht (vgl. Topf 2004).
Die Verantwortung für die Pflege dieser Daten liegt damit bei den Internet-Providern, die die Reverse-Lookup-Zonen (siehe Mockapetris , 1983) der IP-Adressbereiche verwalten. Das Verfahren stellt also eine Art Realtime Blackhole List dar, über deren Einträge aber der Verwalter eines IP-Adressbereiches entscheidet.
Der Ansatz geht damit auch in die Richtung der Filterung von ausgehenden SMTP-Verbindungen wie in 4.2.2 beschrieben. Im Unterschied dazu verhindert er aber nicht grundsätzlich ausgehende SMTP-Verbindungen von nicht MX-Servern zugeordneten IPs. Die Entscheidung, von nicht verzeichneten IPs Mails entgegen zu nehmen, kann damit ein Serverbetreiber fällen, in dem er nicht auf die DNS-Einträge zur Filterung zurückgreift.
6 Perspektiven
Die Kontroversen in der MARID-Arbeitsgruppe haben gezeigt, dass erweiterte Methoden zur Bekämpfung unerwünschter E-Mails ein umstrittenes Thema sind. Langfristig erfolgreich können sie jedoch nur sein, wenn sie sich auf breiter Basis durchsetzen lassen und Netzeffekte entstehen. Konzepte wie SPF können nur funktionieren, wenn auch die zugehörigen Einträge in den Domains gepflegt werden.
Die Einführung von SPF bei großen Anbietern wie AOL und GMX zeigt erste Erfolge bei der Spam-Bekämpfung (vgl. Bleich 2004, S. 136). Doch schaffen die Anbieter durch eine einseitige Einführung auch Fakten, die ein Nebeneinander unterschiedlicher Technologien zur Folge haben können. So könnten AOL, Microsoft und Yahoo dazu übergehen, auf ihren Mailsystemen nur Nachrichten anzunehmen, die einer Verifikation durch das jeweils präferierte System standhalten. Domaininhaber müssten mehrere konkurrierende Methoden implementieren, was sich langfristig kaum realisieren und keinem Verfahren zur Durchsetzung verhelfen dürfte. Entsprechend zögerlich sind andere Provider wie T-Online, 1&1 oder Web.de bei der Einführung (vgl. Bleich 2004, S. 126).
Der Schritt von Microsoft, Sender ID abwärtskompatibel zu SPF zu gestalten ist ein Schritt in die richtige Richtung. Problematisch sind bei Sender ID aber vor allem die noch ungeklärten Patentansprüche. Im Markt der MTA-Software, in dem mit Sendmail, Postfix und anderen viele Open-Source-Produkte vertreten sind, kann sich dies als Hindernis für die weitere Verbreitung des Vorschlags darstellen.
Die vorgeschlagenen Alternativen erscheinen zunächst einfach zu realisieren, erfordern aber doch umfangreiche Ergänzungen an der E-Mail-Infrastruktur: Die verwendete Serversoftware muss um Abfragefunktionen für die einzelnen Systeme erweitert werden, was teilweise bei Postfix und Sendmail bereits geschehen ist. Aber auch das Einpflegen der zugehörigen Informationen in das Domain System gestaltet sich aufwändig. Die Einträge für stark frequentierte E-Mail-Domains wie AOL.com sind schnell erstellt, Probleme bekommen aber vor allem die Nutzer von Millionen eigener privater oder kommerzieller Domains, wenn SPF-Einträge obligatorisch werden, um Kunden einzelner Provider zu erreichen.
Auch sind noch nicht alle Probleme, die die neuen Verfahren mit sich brächten, hinreichend gelöst: Ansätze wie das Sender Rewriting Scheme zur Umgehung der Forwarding-Problematik würden zusätzlichen Implementierungsaufwand bedeuten und das „einst so simple System E-Mail ein gutes Stück komplex machen“ (Bleich 2004, S. 137).
Solange sich noch kein System endgültig durchgesetzt und verbreitet hat, kann ein fehlender Autorisierungseintrag eines zustellenden MTAs wohl kaum alleiniges Merkmal zur Erkennung unerwünschter E-Mails ausreichen. Vorerst werden diese neuen Mechanismen nach Bager & Mollard (2004, S. 144) wohl vorrangig als Ergänzung zu anderen Techniken wie IP- oder Inhaltsbasierten Filtern zum Einsatz kommen.
7 Glossar
|
DNS |
Domain Name System Verteilte Serverinfrastruktur im Internet zur Umsetzung von Rechner- und Domänennamen in zugehörige Protokolladressen (IP) und zuständige Server für dieses Domains. Im E-Mailkontext verwendet zur Abfrage des zuständigen Mailservers |
|
FQDN |
Fully Qualified Domain Name Die vollständige, im Internet erreichbare Bezeichnung des Rechners bestehend aus dem Rechnernamen und dem gültigen Domain-Namen. Bsp.: www.uni-hildesheim.de |
|
IETF |
Internet Engineering Task Force Für Internet-Standards verantwortliche Organisation |
|
MARID |
MTA Authrorization Records in DNS - Ansatz zur MTA-Authentifizierung durch zusätzliche Einträge im DNS. - Gleichnamige Arbeitsgruppe der Internet Engineering Task Force zur Erarbeitung und Verabschiedung eines konkreten Verfahrens auf Basis dieses Ansatzes |
|
MTA |
Message Transfer Agent An Versand oder Empfang einer E-Mailnachricht beteiligter Mailserver im Internet |
|
MUA |
Mail User Agent Software-Komponente des E-Mailsystems, mit der Benutzer direkt interagiert, beispielsweise zum Lesen seiner Mails oder zur Weitergabe einer zu sendenden Mail an MTA. I.d.R. zusammengefasst als Mailclient. |
|
NDR |
Non Delivery Report Automatisierte Fehlermeldung als E-Mail, die ein Versender einer Mail von einem der beteiligten E-Mailserver erhält, wenn die Zustellung der Nachricht fehlgeschlagen ist. |
|
RCPT |
Recipient Abkürzung für Empfänger einer E-Mail, wird also Kommando bei der SMTP-Kommunikation angegeben. |
|
RFC |
Request For Comments Ausformulierte Vorschläge zu Verfahrensweisen, die zu einem Internet-Standard erhoben werden sollen. |
|
RR |
Resource Record Eintrag eines bestimmten Typs im DNS |
|
SMTP |
Simple Mail Transfer Protocol Im Internet hauptsächlich verwendetes Protokoll zur Zustellung von E-Mails von einem versendenden Mailserver an den zuständigen Mailserver des Empfängers. Ursprünglich definiert in der RFC 821 (Postel 1981), aktualisiert durch RFC 2821 (Klensin 2001). |
|
UBE |
Unsolicited Bulk E-Mail Oberbegriff für jede Form von massenhaft versandten, unverlangten E-Mails |
|
UCE |
Unsolicited Commercial E-Mail Unverlangt per E-Mail zugesandte Werbenachrichten |
8 Literatur
[Anti-Phishing Working Group 2005] Anti-Phishing Working Group: Phishing Activity Trends Report. -URL:http://antiphishing.org/APWG_Phishing_Activity_Report_Feb05.pdf – Zugriffsdatum:31.03.2005.
[Bachfeld 2004] Bachfeld, Daniel: Neuer Sober-Wurm verbreitet sich schnell. - URL: http://www.heise.de/newsticker/meldung/53427 – Zugriffsdatum: 31.03.2005.
[Bachfeld 2004a] Bachfeld, Daniel: Phishing-Tricks werden immer ausgefeilter. - URL: http://www.heise.de/security/news/meldung/52935 – Zugriffsdatum: 31.03.2005.
[Bager & Mollard 2004] Bager, Jo; von Mollard, Michael F.: Wider die E-Mail-Massen. Neue Verfahren gegen Spam. In: c’t Magazin für Computertechnik (2004). Heft 15, S. 142-144.
[Bleich 2004] Bleich, Holger: Säuberungsmaßnahmen. Absenderauthentifizierung zum Schutz vor Spam und Betrug. In: c’t Magazin für Computertechnik (2004). Heft 19, S. 134-137.
[Bleich 2005] Bleich, Holger: AOL filtert Verbindungen auf SMTP-Port TCP. – URL: http://www.heise.de/newsticker/meldung/56418 – Zugriffdatum: 31.03.2005
[Bleich & Schmidt 2004] Bleich, Holger; Schmidt, Jürgen: Auf Phishzug. Passwort-Diebstahl im Web wird immer raffinierter. In: c’t Magazin für Computertechnik (2004). Heft 17, S. 178f.
[CleanMx 2005] Clean MX: Spam Report Deutschland Januar 2005. - URL: http://www.clean-mx.de/?1_fakten.htm#Spam – Zugriffsdatum: 31.03.2005.
[Danisch 2002]
Danisch, Hadmut: A DNS RR for simple SMTP sender authentication. - URL: http://www.danisch.de/work/security/txt/
draft-danisch-dns-rr-smtp-00.txt– Zugriffsdatum: 31.03.2005.
[Dietrich
& Pohlmann 2005] Dietrich, Christian; Pohlmann, Norbert: E-Mail
Verlässlichkeit. Auswertung der Umfrage Ende 2004. - URL: http://www.forschung.informatik.fh-gelsenkirchen.de/
online-fragebogen/Auswertung_der_OnlineUmfrage-E-Mail-Verlaesslichkeit-Dietrich_Pohlmann.pdf.
– Zugriffsdatum: 31.03.2005.
[Ermert & Bager 2004] Emert, Monika; Bager, Jo: Bemühungen um Anti-Spam-Standard gescheitert. In: c’t Magazin für Computertechnik (2004). Heft 21, S. 48.
[Hauschild et
al. 2005] Hauschild, Wolfgang; Kahle, Irene; Schäfer, Dieter; Timm,
Ulrike: Informationstechnologie in Unternehmen und Haushalten 2004. Statistisches
Bundesamt. - URL: http://www.destatis.de/download
/d/veroe/pb_ikt_04.pdf – Zugriffsdatum: 6.12.2004.
[Heise
Security 2005] Heise Security: HTML-E-Mails. - URL: http://
www.heise.de/security/dienste/emailcheck/text/html.shtml. – Zugriffsdatum: 31.03.2005.
[Heise
Security 2005a] Heise Security: Phishing mit Frames - URL:
http://www.heise.de/security/dienste/browsercheck/demos/
ie/frame.shtml. – Zugriffsdatum: 31.03.2005.
[Klensin 2001] Klensin, J. (Editor): Simple Mail Transfer Protocol. RFC 2821. - URL: http://www.ietf.org/rfc/rfc2821.txt. – Zugriffsdatum: 31.03.2005.
[Kossel 2004] Kossel, Axel: Das E-Mail-Fiasko. Dem veralteten System droht der Kollaps. In: c’t Magazin für Computertechnik (2004). Heft 19, S. 132f.
[Kossel & Schmidt 2004] Kossel, Axel ; Schmidt, Jürgen: Ausgebootet. Mit digitalen Signaturen gegen die Mail-Plagen. In: c’t Magazin für Computertechnik (2004). Heft 17, S. 138ff.
[Linke 2003] Linke, Andreas: Spam oder nicht Spam? E-Mail sortieren mit Bayes-Filtern. In: c’t Magazin für Computertechnik (2003). Heft 17, S. 150-153.
[Messagelabs
2004] MessageLabs Intelligence: Annual Email Security Report 2004.
URL: http://www.messagelabs.com/binaries/
LAB480_endofyear_v2.pdf – Zugriffsdatum: 28.03.2004.
[Microsoft 2004] Microsoft Corporation: Sender ID Overview. 2004. URL: http://www.microsoft.com/mscorp/twc/privacy/spam/senderid/overview.mspx – Zugriffsdatum: 6.12.2004.
[Mockapetris 1983] Mockapetris, P.: Domain Names – Concepts and Facilities. RFC 882. URL: http://www.ietf.org/rfc/rfc882.txt. – Zugriffsdatum: 31.03.2005.
[Myers 1999] Myers, John G.: SMTP Service Extension for Authentication. RFC 2554. URL: http://www.ietf.org/rfc/rfc2554.txt. – Zugriffsdatum: 31.03.2005.
[Nucleus Research 2004] Nucleus Research Inc.: Spam: The Serial ROI Killer. URL: http://www.nucleusresearch.com/research/e50.pdf – Zugriffsdatum: 31.03.2005.
[Postel 1981] Postel, Jonathan B.: Simple Mail Transfer Protocol. RFC 821. URL: http://www.ietf.org/rfc/rfc821.txt. – Zugriffsdatum: 31.03.2005.
[Resnick 2001] Resnik, P..: Internet Message Format. RFC 2822. URL: http://www.ietf.org/rfc/rfc2822.txt. – Zugriffsdatum: 31.03.2005.
[Sophos 2004] Sophos: Bei Sophos gemeldete Top-Ten-Viren November 2004– URL http://www.sophos.de/virusinfo/topten/200411.html – Zugriffsdatum: 30.03.2004
[Topf 2004] Topf, Jochen: Lizenz zum Senden. Authentifizierung der Absenderdomain bei E-Mails. In: iX Magazin für professionelle Informationstechnik (2004). Heft 6, S. 90-93.
[Wikipedia 2005] o.V.: Unsolicited Bulk Email – URL http://de.wikipedia.org/wiki/Unsolicited_Bulk_Email – Zugriffsdatum: 28.03.2004
[Wikipedia
2005a] o.V.: Spam (E-Mail) – URL http://de.wikipedia.org/
wiki/Spam_(E-Mail) – Zugriffsdatum: 30.03.2004
[Wikipedia
2005b] o.V.: Spam (Usenet) – URL http://de.wikipedia.org/
wiki/Spam_(Usenet) – Zugriffsdatum: 30.03.2004
[Wikipedia
2005c] o.V.: Phishing – URL http://de.wikipedia.org/wiki/
Phishing – Zugriffsdatum: 28.03.2004
[Wikipedia
2005d] o.V.: Malware – URL http://de.wikipedia.org/
wiki/Malware – Zugriffsdatum: 28.03.2004^
[Wikipedia
2005e] o.V.: SMTP-After-POP – URL http://de.wikipedia.org/
wiki/SMTP-After-POP – Zugriffsdatum: 29.03.2004