Fachbereich Informatik Studiengang Angewandte Informatik Seminar: Netzwerksicherheit B. Seminararbeit. Verhaltensanalyse von Smarthosts

Transkript

1 Fachbereich Informatik Studiengang Angewandte Informatik Seminar: Netzwerksicherheit B Seminararbeit Verhaltensanalyse von Smarthosts Juli 2008 Verfasser Alexander Schuch Bernd Gertzen Mtr-Nr: Mtr-Nr: Leitung Prof. Dr. Norbert Pohlmann

2

3 Inhaltsverzeichnis Inhaltsverzeichnis 1 Aufgabenstellung und Ziel SMTP-Grundlagen SMTP vs. Extended SMTP Mail Transport vs. Mail Transmission Reply Codes Enhanced Statuscodes SMTP-Dialog: Versand einer Realisierung Konzept und Umsetzung Beispielszenario Ergebnisse Klassifizierung von -Adressen Erreichbarkeit auf Zielport 25 und/oder SMTP Service Extensions Message Size Declaration Mehrfaches Ausführen des MAIL FROM-Kommandos Zeitpunkt des Abbruchs des SMTP-Dialogs Enhanced Statuscodes Timeout-Zeit nach Verbindungsaufbau Wann ist eine angekommen? Fazit...27 Anhang...28 Literaturverzeichnis...28 Abbildungsverzeichnis...28 Anhang B...29 I

4 1 Aufgabenstellung und Ziel Die Aufgabenstellung ist das Analysieren des Reaktionsverhaltens von Mailservern, im Speziellen Smarthosts 1, während des SMTP-Dialogs. Es soll der Ist-Zustand der Konfiguration der Smarthosts erfasst werden, um darüber Statistiken über verwendete Technologien zu erstellen, Unterschiede und Gemeinsamkeiten im Verhalten von Smarthosts festzustellen, Fehlverhalten von Smarthosts aufzudecken, Defizite bei sicherheitsrelevanten Einstellungen aufzuzeigen und Verstöße gegen die Vorgaben der RFCs, die das Simple Mail Transfer Protocol und dessen Service Extensions (siehe dazu Kapitel 2 - SMTP- Grundlagen) spezifizieren, aufzuzeigen. 2 SMTP-Grundlagen In diesem Kapitel werden die für dieses Projekt relevanten Grundlagen des Simple Mail Transfer Protocol (SMTP) näher erläutert. 2.1 SMTP vs. Extended SMTP Als SMTP 1982 in [RFC821] definiert wurde, gab es eine überschaubare Anzahl von Hosts im Internet. Da die Verbindungen langsam und instabil waren, wurde auf Zuverlässigkeit großen Wert gelegt. Authentifizierung war nicht vorgesehen, somit war jeder Mailserver ein Open Relay 2, über den Mails an jeden anderen Knoten weitergeleitet werden konnten. Mit der wachsenden Popularität des Internets entstand so das Problem des Spam wurde mit Extended SMTP (ESMTP) in [RFC1869] das Protokoll erweitert. Diese Erweiterung erlaubt, dass über ein modulares Konzept weitere Befehle für das SMTP-Protokoll definiert werden können. (Quelle: [WESM08]) Dadurch wird sichergestellt, dass SMTP den zukünftigen Sicherheitsstandards und weiteren Neuerungen entspricht ohne dass jedes mal der gesamte Standard überarbeitet werden muss. Um zu prüfen, ob ein Mailserver ESMTP unterstützt, schickt man ihm nach dem Verbindungsaufbau den EHLO-Befehl (Extented HELO) anstelle des HELO- 1 Ein Smarthost ist ein Server für den -Versand. Er nimmt s vom Mail User Agent (MUA) des Anwenders entgegen, interpretiert die Empfängeradresse und leitet die s an den richtigen Empfänger- Mailserver weiter. (Quelle: [SMAR05]) 2 Ein Mailserver wird als Open Relay bezeichnet, wenn er von jedem beliebigen Sender annimmt und an beliebige Empfänger weiterleitet, obwohl er weder für Mail vom Sender noch für Mail an den Empfänger zuständig ist. 2

5 Befehls. Wird ESMTP unterstützt, so liefert er als Bestätigung eine Liste der Erweiterungen (SMTP Service Extensions/ESMPT-Erweiterungen) die er unterstützt. Der [RFC821] und der [RFC1869] sind durch den 2001 definierten [RFC2821] obsolet geworden. Welche Erweiterungen es gibt und welche für dieses Projekt von besonderer Relevanz sind, wird im Kapitel 4 (Ergebnisse), in dem die bisherigen Ergebnisse vorgestellt werden, näher erläutert. 2.2 Mail Transport vs. Mail Transmission Ungesichertes SMTP wird auf den zwei Zielports 25 und 587 betrieben. Der -Transport (Mail Transfer) zwischen den Mail Transfer Agents (MTAs) findet über den Zielport 25 statt. Die -Einreichung (Mail Submission) zwischen dem Mail User Agent (MUA) des Clients und dem Mail Submission Agent (MSA) spezifiziert im [RFC4409] findet über den Zielport 587 statt. Der Unterschied zwischen Transport und Einreichung liegt darin, dass MSAs unvollständige s vom MUA aufbereiten und vervollständigen bevor sie sie an den MTA übermitteln. Ein Beispiel dafür ist, dass s ein exaktes Datum inklusive Zeitzone beinhalten müssen. Fehlen diese Angaben in einer , so werden sie vom MSA eingefügt bevor die weitergeleitet wird. Im Gegensatz dazu dürfen MTAs nach dem Standard nur die Received-Zeile der E- Mail, die sie transportieren, verändern. Des Weiteren ist bei dem Message Submission-Verfahren die Authentikation des Clients zwingend erforderlich. Gibt der Client seine Identität nicht preis, darf der MSA die nicht annehmen und muss dem Client eine entsprechende Fehlermeldung zurücksenden. Lässt man lediglich -Verkehr auf Port 587 zu, indem man den Port 25 sperrt, so ist gewährleistet, dass eine Authentikation stattfinden muss, welches dem Missbrauch des Mailservers durch Spammer vorbeugt. 2.3 Reply Codes Sendet der Client dem Mailserver ein SMTP-Kommando, so antwortet er mit einer dreistelligen Zahl, dem Reply Code, in den meisten Fällen gefolgt von einem kurzen Text, der das Ereignis näher beschreibt. Dieser Text ist nach [RFC2821] optional. Die Reply Codes, mit denen ein Mailserver nach [RFC2821] antworten darf, werden durch die erste Ziffer grundsätzlich in fünf Kategorien unterteilt. Diese werden im Folgenden kurz erläutert: 3

6 1xy: Positive Preliminary reply Mailserver hat die Anforderung akzeptiert, ist aber selbst noch nicht tätig geworden. Eine Bestätigungsmeldung ist erforderlich. 2xy: Positive Completion reply Mailserver hat die Anforderung erfolgreich ohne Fehler ausgeführt. 3xy: Positive Intermediate reply Mailserver hat die Anforderung verstanden, benötigt aber zur Verarbeitung weitere Informationen. 4xy: Transient Negative Completion reply Mailserver hat einen temporären Fehler festgestellt. Wenn die Anforderung ohne jegliche Änderung wiederholt wird, kann die Verarbeitung möglicherweise abgeschlossen werden. 5xy: Permanent Negative Completion reply Mailserver hat einen fatalen Fehler festgestellt. Die Anforderung kann nicht verarbeitet werden. Im weiteren Verlauf des Dokuments werden die Reply Codes der Gruppe 4xy und 5xy, die im Falle eines aufgetretenen Fehlers vom Mailserver geschickt werden, auch als Fehlercodes bezeichnet. 2.4 Enhanced Statuscodes Neben den in Kapitel 2.3 (Reply Codes) erwähnten Reply Codes gibt es noch die Enhanced Statuscodes, welche im [RFC2034] SMTP Service Extension for Returning Enhanced Error Codes spezifiziert sind. Sie sind eine Erweiterung zu den normalen Reply Codes und dienen zur spezielleren, maschinenlesbaren Beschreibung von Fehlern, so dass Clients auf diese besser reagieren können. 4

7 2.5 SMTP-Dialog: Versenden einer In Abbildung 1 ist der idealisierte und durch den [RFC2821] spezifizierte SMTP- Dialog zwischen Client und Server für das Versenden einer in sieben Phasen dargestellt und beschrieben. Dabei ist es wichtig, die Reihenfolge der Kommandos einzuhalten, da es sonst zu einem Fehler kommen kann. Die Ausnahme ist das EHLO-Kommando, auf das in Phase 2 näher eingegangen wird. Abbildung 1: SMTP-Dialog: Versenden einer . Phase 1 Der Client baut eine Verbindung zum Mailserver auf und der Mailserver schickt ihm eine Nachricht mit dem positiven Reply Code 220 und einer Begrüßungsnachricht in der z.b. die verwendete Software und die Version 5

8 stehen kann. Phase 2 Über das EHLO-Kommando identifiziert sich der Client gegenüber dem Mailserver durch die Angabe seiner Domain. Der Mailserver antwortet mit einer mehrzeiligen Nachricht, welche die von ihm unterstützten SMTP Service Extensions enthält. In jeder Zeile steht der positive Reply Code 250 gefolgt von einer Extension. Das EHLO-Kommando kann jederzeit im SMTP-Dialog ausgeführt werden und sorgt dafür, dass der Mailserver seine Puffer wieder löscht. Wurde z.b. schon die -Adresse des Absenders über das MAIL FROM-Kommando angegeben und vom Mailserver in dem dafür vorgesehen Puffer gespeichert, so wird dieser wieder geleert. Phase 3 Über das MAIL TO-Kommando wird der Absender der angegeben. Der Mailserver speichert die -Adresse in dem dafür vorgesehenen Puffer und antwortet mit einem positiven Reply Code 250 gefolgt von einem optionalen Text. Phase 4 Mit dem RCPT TO-Kommando werden die Empfänger der -Nachricht an den Mailserver übertragen. Mehrere Empfänger können über die mehrfache Ausführung des RCPT TO-Kommandos angegeben werden. Der Mailserver speichert die -Adressen in dem dafür vorgesehenen Puffer und antwortet mit einem positiven Reply Code 250 gefolgt von einem optionalen Text. Phase 5 Über das DATA-Kommando kündigt der Client an, dass er mit dem Übertragen der beginnen möchte. Der Mailserver antwortet mit dem Reply Code 354, wodurch er dem Client symbolisiert, dass er anfangen kann zu senden. Phase 6 Der Client überträgt die Daten der und beendet die Übertragung durch die Zeichenfolge <CRLF>.<CRLF> (CRLF ist die Abkürzung für Carriage Return Line Feed. Line Feed ist das Bewegen des Cursors in die nächste Zeile. Carriage Return ist das Bewegen des Cursors an den Anfang der Zeile.). Phase 7 Über das QUIT-Kommando beendet der Client die Verbindung zum Mailserver. Dieser antwortet mit dem positiven Reply Code 221 und bestätigt dadurch dem Client, dass die Verbindung nun beendet ist. 6

9 3 Realisierung In diesem Kapitel wird auf die Konzeption und Umsetzung des Projekts eingegangen. 3.1 Konzept und Umsetzung Die Datenbasis Um Smarthosts untersuchen und deren Verhalten analysieren zu können, wird eine Datenbasis mit Adressen von diesen benötigt. Die Beschaffung der Adressen der Smarthosts wird durch intensives Recherchieren im Internet durchgeführt. Des Weiteren können mit Hilfe des Kommandozeilen-Tools nslookup 3 die MX-Records mittels DNS von Domains abgefragt werden. Darüber können dann die Adressen der Mailserver von Unternehmen abgefragt werden. Es kommt vor, dass die Adresse des dort angegebenen Mailservers gleichzeitig der Smarthost ist. Ob das der Fall ist, muss händlisch überprüft werden. Die gesammelten Adressdaten werden auf ihre Existenz überprüft und in einer Datenbank, zusammen mit anderen Daten, wie z.b. dem Namen des Unternehmens, der Domain des Unternehmens, usw., gespeichert. Insgesamt wurden die Adressen von 76 Smarthosts zusammengetragen, welche die Datenbasis darstellen. Um die Aussagekraft der Ergebnisse zu verstärken, sind unter Anderem auch große deutsche Service Provider (ESP) wie Web.de, GMX.de und T-Online, sowie ein Großteil der 30 DAX-Unternehmen enthalten. Analyse Um das Verhalten der Smarthosts zu analysieren, müssen ganz gezielt deren Protokolleigenschaften abgefragt werden. Zu interessanten Fragestellungen müssen Szenarien generiert werden. Diese Szenarien werden dann auf die Smarthosts angewandt, um über deren Verhalten in speziellen Situationen an die gewünschten Informationen zu kommen. Kommunikation mit den Smarthosts Damit das Verhalten der Smarthosts nicht einzeln und händisch analysiert werden muss, wird ein Tool zur Ansteuerung bzw. Kommunikation mit den einzelnen Smarthosts benötigt. In diese Applikation können dann Szenarien implementiert werden, die automatisiert die entsprechenden Befehlsfolgen an 3 Der Befehl nslookup kann unter Mac OS X, Windows und Unix verwendet werden, um IP-Adressen oder Domänen eines bestimmen Computers mittels DNS herauszufinden. Der Name des Befehls bedeutet Name Server lookup, was so viel heißt wie den Namen des Servers nachschlagen. 7

10 alle Smarthosts der Datenbasis absetzt und deren Antwortdaten weiter verarbeitet. Das hat den Vorteil, dass neue Szenarien schnell und einfach in das Tool implementiert werden können. Die Entwicklung der Applikation wurde in der objektorientierten Programmiersprache Java durchgeführt. Dabei wurde das Java Development Kit (JDK) in der Version 1.6.0_06 genutzt. Datenspeicherung Die Antwortdaten der Smarthosts sollen über einen längeren Zeitraum abrufbar sein und werden deshalb in einer Datenbank abgespeichert. Die Daten werden aus der Applikation heraus direkt an die Datenbank weitergeleitet. Dort werden sie gespeichert und stehen dann zur Analyse bereit. Dabei ist eine gut durchdachte Struktur der Tabellen notwendig, um im Nachhinein mit Hilfe von Abfragen Ergebnisse aus den Rohdaten zu extrahieren. Die folgende Abbildung verdeutlicht die Arbeitsweise des Tools: Abbildung 2: Arbeitsweise des Tools. 3.2 Beispielszenario Ein grundlegendes Szenario, welches implementiert wurde, ist die Durchführung der SMTP-Transaktion zum Versenden einer , die bereits in Kapitel 2.5 (SMTP-Dialog: Versenden einer ) ausführlich behandelt wurde. Jedes gesendete SMTP-Kommando wird dabei zusammen mit der Antwort des Smarthosts, welche vorher in ihre Einzelteile zerlegt wurde, und weiteren relevanten Informationen in die Datenbank geschrieben. 8

11 Die Struktur dieser Tabelle sieht folgendermaßen aus: ID: Eindeutige Nummer des Datensatzes PROVIDER: Name des geprüften Providers SMARTHOST_ADDRESS: Adresse des geprüften Smarthosts des Providers. (Zu einem Provider können mehrere Smarthost-Adressen existieren.) ERROR_ON: Gibt die aktuelle Phase des Dialogs an (GREETING, EHLO, MAIL FROM, RCPT TO,...). _TYPE: Enthält den Typen der -Adresse, mit der der aktuelle Test durchgeführt wurde. Warum es wichtig ist verschiedene Typen von -Adressen zu unterscheiden und welche Typen das sind, wird in Kapitel 4.1 (Klassifizierung von -Adressen) erläutert. STATUSCODE: Der geantwortete Reply Code des Smarthosts auf das vorher abgesetzte SMTP-Kommando. ENHANCED_STATUSCODE: Ist in der Antwort des Smarthosts ein Enhanced Statuscode enthalten, so wird dieser auch abgespeichert. MESSAGE: Der nach dem Reply Code folgende Text der Antwort des Smarthosts. Auch die Liste der unterstützen ESMTP-Extensions wird in diesem Feld abgelegt, um diese später auswerten zu können. Mit Hilfe dieser Tabelle können z.b. folgende Fragestellungen beantwortet werden: In welcher Phase des SMTP-Dialogs hat der Smarthost aufgrund mangelnder Authentikation oder anderer Gründe einen Fehlercode geliefert? Welche ESMTP-Extensions sind am meisten verbreitet? Welche Fehlercodes treten in welcher Phase des SMTP-Dialogs auf? Wie häufig werden Enhanced Statuscodes verwendet? Wie unterscheidet sich das Verhalten der Smarthosts, in Abhängigkeit des Typs der -Adresse, mit dem der SMTP-Dialog durchgeführt wurde? Auf diese Art und Weise wurden weitere Szenarien in die Applikation implementiert. Die Ergebnisse werden im folgenden Kapitel vorgestellt. 9

12 4 Ergebnisse Am 17. Juni 2008 wurde eine Messung durchgeführt, in der das Reaktionsverhalten und die unterstützten Technologien der 73 Smarthosts analysiert wurden. Alle Ergebnisse der Messung werden in diesem Kapitel dargestellt. Zudem werden weitere Erkenntnisse, die während des Projekts gemacht wurden, angeführt. Die Ergebnisse werden teilweise mithilfe von Kreisdiagrammen veranschaulicht. Repräsentiert ein Kreissektor ein Intervall, so wird die aus der Mathematik bekannte Intervallschreibweise (vgl. [WINT08]) verwendet 4.1 Klassifizierung von -Adressen Eine wichtige Erkenntnis die gemacht wurde und die bei der Durchführung der Szenarien unbedingt berücksichtigt werden muss, ist die Unterscheidung von verschiedenen -Adress-Typen. Dies ist so wichtig, da die Smarthosts sich unterschiedlich verhalten, wenn bei dem MAIL FROM- oder dem RCTP TO- Kommando unterschiedliche Typen von -Adressen als Argument angegeben werden. Es gilt drei Typen zu unterscheiden: Typ 1 Eine nicht existierende, ausgedachte -Adresse, deren Domain nicht existiert. Beispiel: askficne@sdiehdskfjd.de Typ 2 Eine -Adresse deren Existenz sichergestellt ist, wie z.b. die eigene - Adresse (Beispiel: max.mustermann@gmx.de). Typ 3 Eine -Adresse, die im Unternehmen des überprüften Smarthosts existiert. Eine solche Adresse könnte z.b. info@domain.com, webmaster@domain.com oder support@domain.com sein, wobei domain.com für die Domain des Unternehmens steht. Das unterschiedliche Verhalten resultiert daher, dass viele Smarthosts die Existenz der Domain, der bei MAIL FROM als Argument angegebenen - Adresse, überprüfen. Existiert die Domain nicht, so wird mit einem Fehlercode geantwortet und der SMTP-Dialog kann nicht fortgeführt werden. Das wäre mit einer Adresse vom Typ 1 der Fall. Existiert die Domain, so wird ein positiver Reply Code geantwortet und es kann mit dem RCPT TO-Kommando 10

13 fortgefahren werden. Gibt man beim MAIL FROM-Kommando als Argument eine -Adresse an, deren Domain die des Unternehmens des Smarthosts ist, so kommt es vor, dass nicht nur die Domain, sondern direkt die Existenz der -Adresse selbst geprüft wird. Existiert die -Adresse nicht, so wird der Smarthost entsprechend mit einem Fehlercode antworten. Wie sich das unterschiedliche Verhalten in den durchgeführten Analysen widerspiegelt, ist in Kapitel 4.6 (Zeitpunkt des Abbruchs des SMTP-Dialogs) zu sehen. 4.2 Erreichbarkeit auf Zielport 25 und/oder 587 Bei der Messung wurde untersucht, welche Smarthosts SMTP auf dem Zielport 25 und/oder 587 betreiben. Der Unterschied wurde bereits in Kapitel 2.2 (Mail Transport vs. Mail Transmission) erläutert. Das Ergebnis ist dem folgenden Kreisdiagramm zu entnehmen: Abbildung 3: Ergebnis des Überprüfung der Erreichbarkeit der Smarthosts auf dem Zielport 25 und/oder 587 in Form eines Kreisdiagramms. Alle 73 überprüften Smarthosts erlauben den Verbindungsaufbau über den Zielport der 73 Smarthosts, was 39,7% entspricht, erlauben zusätzlich 11

14 den Verbindungsaufbau über Port 587, über den eine Authentikation des Client erforderlich ist, bevor dieser s über den Smarthost versenden darf. Ein Grund für die doch geringe Verbreitung der Verwendung des Zielports 587 liegt darin, dass es andere Methode zur Authentikation wie z.b. POP-before- SMTP 4 und die SMTP Service Extension SMTP-AUTH gibt, die über den Port 25 verwendet werden. 4.3 SMTP Service Extensions Es wurde ausgewertet, welche ESMTP-Extensions wie häufig von Smarthosts unterstützt werden. Das Ergebnis der Auswertung, der wichtigsten von den überprüften Smarthosts unterstützten SMTP Service Extensions, ist der folgenden Tabelle und dem Balkendiagramm aus Abbildung 4 zu entnehmen: ESMTP-Extension Anzahl der Smarthosts SIZE 66 PIPELINING 56 8BITMIME 56 AUTH 53 HELP 32 STARTTLS 32 ETRN 30 DSN 30 ENHANCEDSTATUSCODES 30 VRFY 13 DELIVERBY X-CP-DELLIVER-AFTER 7 BINARYMIME 6 CHUNKING 6 TURN 4 DELIVERBY 4 OK Tabelle 1: Ergebnis der Auswertung, der wichtigsten von den überprüften Smarthosts unterstützten SMTP Service Extensions. 4 Bei POP-Before-SMTP greift ein Benutzer zunächst über das POP3-Protokoll auf sein Postfach auf dem Mailserver zu und authentisiert sich dabei mit seinem Benutzernamen und dem zugehörigen Passwort. Anschließend verbleibt ihm ein definiertes Zeitfenster von beispielsweise 15 Minuten, in dem er s per SMTP versenden darf. Als Autorisierung für den Versand per SMTP dient somit die erfolgreiche POP3- Authentifizierung. (Quelle: [WPBS08]) 12

15 Abbildung 4: Balkendiagramm über die Häufigkeit der Unterstützung der wichtigsten SMTP Service Extensions. Im Folgenden werden die Funktion und der Nutzen der wichtigsten in Abbildung 4 genannten SMTP-Erweiterungen erläutert: SIZE Ein SMTP-Server kann mithilfe der SMTP Service Extension namens Message Size Declaration (siehe [RFC1870]) eine obere Grenze für die Größe einer E- Mail, die er entgegen nimmt, definieren. Näheres zu dieser Service Extension folgt in Kapitel 4.4 (Message Size Declaration). SIZE ist eine weit verbreitete ESMTP-Extension und wird von 90,4% der geprüften Smarthosts unterstützt 8BITMIME Der SMTP-Server unterstützt die SMTP Service Extension for 8bit- MIMEtransport (siehe [RFC1652]). Diese definiert den 8BitMIME Kodierstandard, welcher Zeichen außerhalb des 7-Bit ASCII Standards zulässt. Unterstützt ein Smarthost diese SMTP-Erweiterung, so können also Nachrichten, die auch Zeichen außerhalb des 7-Bit ASCII Standards beinhalten, von diesem Server angenommen, verarbeitet und weiter transportiert werden. 13

16 PIPELINING Durch das EHLO-Keyword PIPELINING wird signalisiert, dass der SMTP-Server die SMTP Service Extension for Command Pipelining, welche im [RFC2920] spezifiziert ist, unterstützt. Dieser Service unterstützt die Übertragung von mehreren Befehlen innerhalb einer TCP-Sendeoperation. Dadurch kann die Performance einer SMTP-Kommunikation signifikant gesteigert werden. Das ist auch der Grund dafür, dass es von 76,8% der geprüften Smarthosts unterstützt wird. AUTH Kurzform für Authentifizierung. Ist im [RFC2554] SMTP Service Extension for Authentication definiert. Sie ermöglicht dem Smarthost eine Authentifizierung des Clients anhand seines Nutzernamens und Kennworts. Über einen SMTP- AUTH-fähigen Smarthost können normalerweise nur noch authentifizierte Absender Mails versenden, was dazu beiträgt, den Missbrauch des Smarthosts für Spam zu verhindern. Immerhin 72,6% der geprüften Smarthosts unterstützen diese Service Extension. Manche Internet Service Provider (ISPs) betreiben IP-Authentifikation, d.h. wenn ein Kunde eine über den Smarthost des ISPs verschicken möchte, muss dieser sich vorher nicht mehr mit seinem Benutzernamen und Passwort authentifzieren, da dies vom ISP über die IP-Adresse gemacht wird. Das könnte unter anderem ein Grund dafür sein, dass die Unterstützung von SMTP-AUTH nicht höher als die gemessenen 72,6% ausfällt. Es wird meist zwischen den drei Authentikationsarten PLAIN, LOGIN und CRAM- MD5 unterschieden. Deren Bedeutung und die Häufigkeit der verwendeten Authentikationsmechanismen wird im Verlauf dieses Kapitels noch genauer behandelt. STARTTLS STARTTLS ist eine Erweiterung die im [RFC3207] SMTP Service Extension for Secure SMTP over Transport Layer Security spezifiziert ist. Sie gibt an, dass über den SMTP-Server eine TLS-Verbindung über den Port 25 zur privaten und authentisierten Kommunikation durchgeführt werden kann. 43,8% der überprüften Smarthosts unterstützen diese ESMTP-Extension. Dass dieser Wert nur so gering ausfällt liegt daran, dass viele Mailserver noch die verschlüsselte Kommunikation über das alte SMTPS auf Port 465 verwenden. HELP Definiert im [RFC1869] SMTP Service Extensions. Mit der HELP-Erweiterung kann vom Client eine Liste der Standardbefehle eingeholt werden, die nicht in der Liste der vom Mailserver unterstützten SMTP- Extensions aufgeführt sind, jedoch von ihm unterstützt werden. 14

17 ENHANCEDSTATUSCODES Definiert im [RFC2034] SMTP Service Extension for Returning Enhanced Error Codes. Dieses EHLO-Keyword signalisiert, dass Enhanced-Statuscodes im SMTP-Dialog verwendet werden. Diese Codes werden zusätzlich zum Reply Code angegeben und dienen der genaueren Beschreibung eines Fehlers. Nur 41% der geprüften Smarthosts unterstützen diese ESMTP-Extension. Detailliertere Ergebnisse zu Enhanced Statuscodes sind dem Kapitel 4.7 (Enhanced Statuscodes) zu entnehmen. DSN DSN steht für Delivery Service Notification und ist spezifiziert im [RFC3461]. Eine DSN ist eine Nachricht, die an den Absender der zurück gesendet wird und den Lieferstatus einer enthält. Die Nachricht kann ein Mailserver, z.b. auf Anfrage, erstellen. Der Absender kann drei unterschiedliche Statusnachrichten anfordern: Erfolg, Verzögerung und Nichtauslieferung. (Quelle: [WDSN08]) ETRN Steht für Extended TURN, als Nachfolger zum Befehl TURN und ist im [RFC1985] SMTP Service Extension for Remote Message Queue Starting definiert. Dieser Befehl ist für Mailserver gedacht, die nicht über eine Standleitung mit dem Internet verbunden sind und daher nur einen begrenzten Zeitraum haben, Mails abzurufen. Hierbei sendet ein SMTP-Server A den ETRN- Befehl zu einem SMTP-Server B und signalisiert damit, dass dieser bereit ist, die für ihn bestimmten Mail (falls vorhanden) aus der Warteschlange zu empfangen. Daraufhin öffnet der SMTP-Server B eine neue SMTP-Verbindung und sendet anschließend die Mails aus der Warteschlange an den SMTP-Server A. VRFY Dieser Befehl ist im [RFC2821] definiert. Über ihn kann auf einem Mailserver abgefragt werden, ob die als Argument angegebene Zeichenkette einen User oder eine Mailbox auf diesem Server identifiziert. Existiert eine Mailbox, so wird diese als Antwort vom Mailserver geliefert. Dieser Befehl ist sehr sicherheitskritisch, da Spammer darüber auf die Existenz von -Adressen schließen können. Das ist auch der Grund dafür, dass Mailserver diesen Befehl zwar implementieren, da es der [RFC2821] so vorgibt, jedoch bei dem Versuch der Ausführung dieses Befehls einen Fehlercode liefern. 15

18 Authentikationsverfahren von SMTP-AUTH Wie bereits angemerkt, wurde die Verteilung der verschiedenen Authentikationsverfahren der SMTP-AUTH Extension separat analysiert. Aus der folgenden Tabelle ist abzulesen wie viele der 73 überprüften Smarthosts die verschiedenen Verfahren unterstützen: AUTH-Verfahren Anzahl der Smarthosts PLAIN 45 LOGIN 49 CRAM-MD5 21 Tabelle 2: Verbreitung der verschiedenen Authentikationsverfahren. Im Folgenden wird die Bedeutung der verschiedenen Verfahren kurz erläutert: PLAIN Die PLAIN-Authentifizierung ist im [RFC2595] standardisiert. Hierbei wird Benutzername und Passwort zusammen unverschlüsselt, allerdings Base64- kodiert, übertragen. LOGIN Bei der LOGIN-Authentifizierung wird, wie bei der PLAIN-Authentifizierung, der Benutzername und das Passwort unverschlüsselt und Base64-kodiert übertragen. Im Unterschied zur PLAIN-Authentifizierung werden die beiden Zeichenketten jedoch in zwei Schritten gesendet. CRAM-MD5 Die CRAM-MD5-Authentifizierung ist im [RFC2195] IMAP/POP AUTHorize Extension for Simple Challenge/Response standardisiert. CRAM steht für Challenge-Response Authentication Mechanism, Message Digest 5 und ist ein Authentifizierungsverfahren nach dem Challenge-Response-Prinzip auf Basis des Message Digest 5 Hash-Algorithmus. Der Tabelle 2 ist zu entnehmen, dass die Häufigkeit der Unterstützung von CRAM-MD5 verhältnismäßig gering ausfällt. Das liegt daran, dass durch Verfahren wie STARTTLS oder SMTPS ohnehin die gesamte Kommunikation verschlüsselt stattfindet. 16

19 4.4 Message Size Declaration Ein SMTP-Server kann mithilfe der SMTP Service Extension namens Message Size Declaration (siehe [RFC1870]) eine obere Grenze für die Größe einer E- Mail, die er entgegen nimmt, definieren. Jeder Versuch eines Clients, eine Nachricht, die größer ist als diese Grenze zu übermitteln, schlägt fehl. Ein Client der das unerweiterte SMTP-Protokoll, so wie es in [RFC821] definiert ist, verwendet, kann erst über einen solchen Fehler informiert werden, wenn die Nachricht komplett zum Server übertragen wurde und dieser sie dann verwirft. Unterstützen aber beide, der Client und der Server, die Message Size Declaration, so können solche Fehler erkannt werden, bevor der Transfer der Nachricht beginnt. Unterstützt ein Mailserver diese SMTP-Erweiterung, so wird beim Empfang des EHLO-Befehls das EHLO-Keyword SIZE in der Liste der unterstützten ESMTP- Extensions mit aufgeführt. Dem SIZE-Schlüsselwort kann optional eine Zahl folgen, die die maximale Nachrichtengröße in Bytes angibt, die der Server bereit ist anzunehmen. Versucht ein Client eine größere Nachricht zu übertragen, so antwortet der Mailserver mit einem permanenten Fehler, für den der Reply Code 552 vorgesehen ist. Ist der Wert 0, so existiert keine maximale Größenbeschränkung. Um herauszufinden, wie die Verteilung der angebotenen Nachrichtengrößen ist, wurde bei der Analyse der unterstützten SMTP Service Extensions der SIZE- Parameter genauer betrachtet. Das Resultat war, dass 66 der 73 untersuchten Smarthosts diese SMTP- Erweiterung unterstützen, welches 90,4% entspricht. Die genaue Verteilung der maximalen Nachrichtengrößen der Smarthosts, die diese Erweiterung unterstützen, ist im Kreisdiagramm auf der folgenden Seite dargestellt. 17

20 Abbildung 5: Resultat der Auswertung des SIZE-Parameters in Form eines Kreisdiagramms. Der folgenden Tabelle ist zu entnehmen, welche Nachrichtengrößen die großen ESPs und ISPs erlauben: provider smarthost_address size/megabyte GMX mail.gmx.net - GMail smtp.gmail.com 27 HotmailPlus smtp.live.com 34 Arcor mail.arcor.de 45 1und1 smtp.1und1.com 50 Web.de smtp.web.de 66 T-Online mxb.t-online.net 350 Tabelle 3: Maximale Nachrichtengrößen von großen ESPs und ISPs. 18

21 4.5 Mehrfaches Ausführen des MAIL FROM-Kommandos Es wurde getestet, ob man bei Smarthosts mehrfach hintereinander den Absender der über das MAIL FROM-Kommando angeben kann. Zu diesem Szenario sind im [RFC2821] keine weiteren Angaben gemacht. Hier verhalten sich die Smarthost unterschiedlich. Entweder kommt es bei dem Versuch ein zweites Mal das MAIL FROM-Kommando abzusetzen zu einem Fehler oder der Smarthost überschreibt die -Adresse des Absenders aus dem ersten MAIL FROM mit der Adresse, die beim zweiten MAIL FROM als Argument angegeben wurde. Im zweiten Fall ist es also so, dass am Ende die E- Mail-Adresse des letzten abgesetzten MAIL FROM-Kommandos verwendet wird. Abbildung 6: Kreisdiagramm, welches darstellt wie viele Smarthosts die mehrfache Hintereinanderausführung des MAIL FROM-Kommandos erlauben bzw. nicht erlauben. Die Fehlercodes, die von den Smarthosts geantwortet werden, wenn es nicht erlaubt ist, sind hier sehr einheitlich. 95,7% liefern den Fehlercode 503, der nach [RFC2821] die Bedeutung Bad sequence of commands hat. Der von den Smarthosts mitgeschickte, beschreibende Text des Fehlers ist auch sehr einheitlich und passend: Sender already specified oder Sender already given. Lediglich zwei Smarthosts wichen davon ab und antworten mit den Fehlercodes 500 Syntax error, command unrecognized und 502 Command not implemented, welche an dieser Stelle nicht sehr sinnvoll sind. 19

22 4.6 Zeitpunkt des Abbruchs des SMTP-Dialogs Wie bereits in Kapitel 3.2 (Beispielszenario) beschrieben, wurde der SMTP- Dialog zum Versenden einer als Szenario implementiert. Bei diesem Dialog gibt es, wie bereits in Kapitel 2.5 (SMTP-Dialog: Versenden einer ) genauer beschrieben, drei Phasen in der eine Domain bzw. eine E- Mail-Adresse angegeben werden muss. Zur Erinnerung an dieser Stelle eine kurze Zusammenfassung der relevanten Phasen: EHLO: Das EHLO-Kommando, dessen Argument die Domain, über die sich der Client gegenüber dem Mailserver identifiziert, ist. MAIL FROM: Das MAIL FROM-Kommando, dessen Argument die - Adresse des Absenders der ist. RCPT TO: Das RCPT TO-Kommando, dessen Argument die - Adresse des Empfängers der , ist. Bei der hier durchgeführten Analyse, soll geprüft werden, wie sich das Verhalten der Smarthosts während des Dialogs ändert, wenn in den oben genannten drei Phasen unterschiedliche -Adress-Typen als Argument angegeben werden. Um genau zu sein geht es um den Zeitpunkt des Abbruchs des Dialogs, in dem der Smarthost mit einem Fehlercode antwortet, da z.b. die Domain der bei MAIL FROM angegebenen -Adresse nicht existiert oder keine Authentifizierung durchgeführt wurde. Die unterschiedlichen Typen von -Adressen wurden bereits in Kapitel Kapitel 4.1 (Klassifizierung von -Adressen) näher definiert. Da es drei Phasen und drei verschiedene Typen von Adressen gibt, wird der Dialog für jeden Smarthost 27 mal durchlaufen, um jede denkbare Kombination zu erfassen. Als -Adresse des Typs 3 (eine -Adresse die in dem Unternehmen des geprüften Smarthost existiert) wurde info@domain.com gewählt. Da nicht sichergestellt ist, dass diese Adresse wirklich in jedem Unternehmen existiert, kann es sein, dass die gemessenen Ergebnisse leicht verfälscht sind. Die Aussage die durch diese Messung gemacht werden kann, verliert dadurch jedoch nicht an Bedeutung. In Tabelle 4 sind die gemessenen Ergebnisse zusammengefasst. In der Spalte Type sind jeweils drei Buchstaben angegeben. Die Buchstaben N, F und O stehen für: N steht für not existing. Damit ist eine nicht existierende Domain bzw. eine -Adresse vom Typ 1 gemeint. F steht für foreign. Damit ist eine existierende Domain, die jedoch nicht die des Unternehmens selbst ist bzw. eine -Adresse vom Typ 2 gemeint. O steht für own. Damit ist die unternehmenseigene Domain bzw. eine -Adresse vom Typ 3 gemeint. 20

23 Die Position des Buchstabens hat die folgende Bedeutung: 1. Buchstabe: Typ der bei EHLO angegebenen Domain. 2. Buchstabe: Typ der bei MAIL FROM angegebenen -Adresse 3. Buchstabe: Typ der bei RCPT TO angegebenen -Adresse Die Prozentzahlen in den Spalten MAIL FROM und RCPT TO geben die Häufigkeit an, in der die Smarthosts, bei der geprüften Kombination von Domain und -Adressen, mit einem Fehlercode geantwortet haben. Der Wert in der Spalte Message accepted gibt an, wie häufig eine erfolgreich über einen Smarthost verschickt werden konnte. Nr. Type MAIL FROM RCPT TO Message accepted 1 OOO 32,86% 48,57% 18,57% 2 OOF 29,85% 70,15% 0,00% 3 OON 30,88% 69,12% 0,00% 4 OFO 17,91% 62,69% 19,40% 5 OFF 17,91% 82,09% 0,00% 6 OFN 17,91% 82,09% 0,00% 7 ONO 43,28% 52,24% 4,48% 8 ONF 42,03% 57,97% 0,00% 9 ONN 42,65% 57,97% 0,00% 10 FOO 32,35% 48,53% 19,12% 11 FOF 30,30% 69,70% 0,00% 12 FON 30,30% 69,70% 0,00% 13 FFO 18,18% 62,12% 19,70% 14 FFF 18,18% 81,82% 0,00% 15 FFN 18,18% 81,82% 0,00% 16 FNO 45,31% 48,44% 6,25% 17 FNF 43,28% 56,72% 0,00% 18 FNN 42,03% 57,97% 0,00% 19 NOO 30,30% 51,52% 18,18% 20 NOF 30,30% 69,70% 0,00% 21 NON 30,30% 69,70% 0,00% 22 NFO 18,18% 63,64% 18,18% 23 NFF 18,18% 81,82% 0,00% 24 NFN 18,18% 81,82% 0,00% 25 NNO 43,94% 50,00% 6,06% 26 NNF 42,65% 57,35% 0,00% 27 NNN 42,65% 57,35% 0,00% Tabelle 4: Timeout-Zeiten der großen ESPs und ISPs. 21

24 Die erste Erkenntnis ist, dass es offensichtlich Smarthosts gibt, bei denen der komplette SMTP-Dialog durchlaufen wird, ohne dass der Client sich dabei Authentifizieren muss. Die in der Tabelle grau hinterlegten Zeilen sind die Typ- Kombinationen, bei denen der Versand einer ohne jegliche Authentifizierung durchgeführt werden konnte. Im Schnitt hat es bei 13 von 70 getesteten Smarthosts funktioniert. Festzustellen ist, dass es nur bei den Kombinationen funktioniert, in denen bei RCPT TO eine -Adresse der eigenen Domain ( O ) verwendet wird (hier info@domain.de). Es ist nicht möglich gewesen eine an eine Adresse außerhalb der eigenen Domain des Unternehmens zu versenden ohne sich zu authentifizieren. Bei den Kombinationen der Zeilen 7, 16 und 25 ist diese Quote geringer. Dies hängt damit zusammen, dass dort bei MAIL FROM eine nicht existierende E- Mail-Adresse ( N ) angegeben wurde. Daraus lässt sich schließen, dass die Existenz der Domain der angegebenen -Adresse von den Smarthosts geprüft wird. Existiert die Domain nicht, so wird ein Fehlercode geliefert und man kommt über das MAIL FROM nicht hinaus. Existiert sie, so kann im SMTP-Dialog fortgefahren werden. Bei der Betrachtung der MAIL FROM -Spalte fallen sehr hohe (rot markiert) aber auch geringe Werte (blau markiert) auf. Bei den rot markierten Fällen wurde bei MAIL FROM eine nicht existierende -Adresse ( N ) angegeben. Wird bei MAIL FROM eine -Adresse vom Typ2 ( F ) angegeben, so ist zu beobachten, dass seltener ein Fehlercode von den Smarthosts geantwortet wird und mit der RCPT TO-Phase fortgefahren werden kann. Daraus lässt sich schließen, dass die Smarthosts die -Adresse oder wenigstens deren Domain auf Existenz überprüfen. In den Zeilen in denen bei MAIL FROM eine -Adresse vom Typ 3 ( O ) angegeben wurde (grün markiert) wird der Dialog zu 30% abgebrochen. Betrachtet man im Vergleich dazu die in blau markierten Werte, bei denen beim MAIL FROM eine fremde -Adresse ( F ) angegeben wurde, so ist festzustellen, dass dort der Dialog nur zu 18% abgebrochen wurde. Das liegt dran, dass manche Smarthosts, in dem Fall, dass bei MAIL FROM eine unternehmenseigene -Adresse ( O ) angeben wird, nicht nur die Domain auf Existenz prüft, sondern direkt verifiziert, ob diese -Adresse auch wirklich im Unternehmen existiert. Existiert also die gewählte Typ 3-Adresse info@domain.com in einem Unternehmen nicht, so kommt es vor, dass der Dialog bei MAIL FROM direkt abgebrochen wird. Des Weiteren ist daraus abzuleiten, dass Sender Address Verification, bei der die gesamte -Adresse auf Existenz geprüft wird, bei Typ 2-Adressen ( F ) nicht angewandt wird. Grund dafür sind die zusätzlich anfallenden Abfragen, welche nur zusätzlich die Mailserver belasten und den gesamten -Vorgang verlangsamen würden. 22

25 4.7 Enhanced Statuscodes Um eine Aussage über die Verbreitung der Verwendung von Enhanced Statuscodes machen zu können, wurde ausgewertet in welchen Fällen und wie häufig diese von Smarthosts verwendet wurden. Im Folgenden sind die wichtigsten Ergebnisse, die bei den Untersuchung gemacht wurden, aufgeführt: 30 der 73 (41,1%) getesteten Smarthosts unterstützen Enhanced Statuscodes. Generell wurden beim GREETING, sowie nach dem Absetzen des EHLO-Kommandos keine Enhanced Statuscodes verwendet. Beim MAIL FROM-Kommando haben 28 der 30 (93,3%) Smarthosts, die Enhanced Statuscodes unterstützen, diese auch verwendet. Zwei Smarthosts, die im Fehlerfall einen Enhanced Statuscode mit angegeben haben, taten dies bei einem positiven Reply Code nicht. Beim RCPT TO-Kommando haben 21 der 23 (91,3%) Smarthosts, bei denen der Test nicht schon beim MAIL FROM mit einem Fehlercode abgewiesen wurde, Enhanced Statuscodes verwendet. Zwei Smarthosts, die im Fehlerfall einen Enhanced Statuscode mit angegeben haben, taten dies bei einem positiven Reply Code nicht. Aus diesen Zahlen ist ersichtlich, dass Enhanced Statuscodes zwar bereits verwendet werden, sich allerdings noch nicht durchgesetzt haben. Des Weiteren werden vereinzelt die Erweiterungen nicht bei positiven Reply Codes mit angegeben, sondern nur in Fehlerfällen. Insgesamt wäre eine höhere Anzahl der Smarthosts, die Enhanced Statuscodes verwenden, wünschenswert, damit Clients entsprechend präziser auf Fehler reagieren können. 4.8 Timeout-Zeit nach Verbindungsaufbau Es wurde die Timeout-Zeit bis zum automatischen Abbruch der Verbindung durch den Smarthost gemessen. Dazu wird eine Verbindung auf Port 25 zum Smarthost aufgebaut und dann solange gewartet, bis die Verbindung aufgrund von Inaktivität abgebrochen wird. Bei der Messung wurde maximal 1860 Sekunden, was 31 Minuten entspricht, auf den Verbindungsabbruch gewartet. Im [RFC2821] wird empfohlen, dass ein Mailserver eine Timeout-Zeit von mindestens fünf Minuten haben sollte, in der er auf das nächste Kommando des Senders wartet, bevor er dann die Verbindung abbricht. Bei diesem Test ist als erstes aufgefallen, dass es Smarthosts gibt, die die Verbindung abbrechen, ohne vorher noch eine Meldung über den Grund des Abbruchs in Form eines Fehlercode an den Client zu liefern. 23

26 Das folgende Kreisdiagramm zeigt, wie viele Smarthosts vor dem Abbruch noch einen bzw. keinen Reply Code schicken: Abbildung 7: Ergebnis darüber, wie viele Smarthosts bei einem Timeout nach dem Verbindungsaufbau mit bzw. ohne einen Fehlercode abbrechen, in Form eines Kreisdiagramms. Wird die Verbindung mit einem Fehlercode abgebrochen, so gibt es auch hier Unterschiede zu verzeichnen. Das kann unter anderem daran liegen, dass im [RFC2821] für diesen Fehler kein bestimmter Reply Code spezifiziert ist. Dies wiederum könnte auch der Grund dafür sein, dass so viele Smarthosts die Verbindung direkt abbrechen. 24

27 Die folgende Grafik zeigt, welche Fehlercodes Verwendung finden und veranschaulicht deren Häufigkeit: Abbildung 8: Kreisdiagramm, welches die Verteilung der beim Verbindungsabbruch gelieferten Reply Codes der Smarthosts darstellt. In den meisten Fällen schickten die Smarthosts den Reply Code 421, bevor sie die Verbindung abbrachen. Die Bedeutung dieses Codes ist Service not available, closing transmission channel und kann nach [RFC2821] immer dann verwendet werden, wenn das System aus bestimmten Gründen die Verbindung abbrechen muss. Dieser Code ist an dieser Stelle durchaus angebracht. 4 der 73 (12%) Smarthosts liefern den Reply Code 451 der nach [RFC2821] die Bedeutung Requested action aborted: error in processing hat. Einer der getesteten Smarthosts antwortet mit dem Reply Code 450 Requested mail action not taken: mailbox unavailable, welcher an dieser Stelle überhaupt keinen Sinn macht. 25

28 Das folgende Kreisdiagramm zeigt die Verteilung der Timeout-Zeiten der Smarthosts: Abbildung 9: Timeout-Zeiten der Smarthosts nach dem Verbindungsaufbau. Es ist ersichtlich, dass sich ein großer Teil der Smarthosts an die empfohlene Timeout-Zeit von fünf Minuten hält. Jedoch ist die Timeout-Zeit bei 36% geringer als die empfohlenen fünf Minuten. Dies hat wahrscheinlich wirtschaftliche Gründe, da die benötigten Ressourcen für eine Verbindung, dann entsprechend für einen kürzeren Intervall reserviert werden müssen. Das ist vor allem für große ESPs von Vorteil, die mehrere Millionen Kunden haben und deren Smarthosts durch sehr viele parallele SMTP-Verbindungen beansprucht werden. Erstaunlich ist, dass vier Smarthosts (5%) innerhalb des gesamten gemessenen Zeitfensters von 31 Minuten die Verbindung gar nicht abgebrochen haben. Dadurch hätten Angreifer sehr viel Zeit, um möglichst viele Verbindungen aufzubauen, um dadurch dann zu versuchen den Smarthost zu überlasten. 26