Exchange Server 2007

Bekämpfen von SPAM und Phishing mit Sender ID

Craig Spiezle and Alexander Nikolayev

Kurz zusammengefasst:

• Grundlagen von Sender ID
• Konfigurieren von Sender ID in Exchange Server
• Vorteile der Authentifizierung

Um der wachsenden Zahl von Spamnachrichten entgegenzuwirken, wurden schon viele Identifikations- und Filterverfahren entwickelt. Um effektiv zu sein, müssen bei der Anwendung dieser Verfahren bei jeder E-Mail-Nachricht bestimmte Fragen gestellt werden, beispielsweise

wer sie gesendet hat. Leider ist die fundamentale Frage, wer eine bestimmte Nachricht gesendet hat, nicht immer leicht zu beantworten. Eine E-Mail wird in der Regel über das Internet gesendet, ohne dass der Absender oder die vom Absender in Anspruch genommenen Computer authentifiziert werden. Es ist sogar recht einfach, beim Senden einer E-Mail-Nachricht vorzugeben, eine andere Person zu sein, und es gibt keine automatisierte Methode, um gefälschte Nachrichten zu erkennen.

SMTP (Simple Mail Transfer Protocol), das zum Senden und Empfangen von E-Mail-Nachrichten verwendet wird, wurde nie zu dem Zweck entwickelt, den Absender einer E-Mail-Nachricht zu identifizieren. Aufgrund dieser technologischen Sicherheitslücke kann als Absender jeder beliebige Name und jede beliebige Adresse eingefügt werden. Dies hat zur Folge, dass sich Inhaltsfilter- und Spamschutzverfahren nicht auf die Daten im E-Mail-Kopf allein verlassen können, um sicherzustellen, dass Nachrichten tatsächlich von dem Absender kommen, von dem zu kommen sie vorgeben.

Diese Sicherheitslücke versucht die E-Mail-Authentifizierung zu schließen. Bei der Authentifizierung wird sowohl vom sendenden als auch vom empfangenden E-Mail-System überprüft, ob Nachrichten tatsächlich aus den Domänen kommen, aus denen sie zu kommen behaupten. Dies macht es für Organisationen leichter, Junk-E-Mail wirkungsvoll herauszufiltern und zugleich sicherzustellen, dass legitime E-Mail-Nachrichten die gewünschten Empfänger tatsächlich erreichen.

Heute gibt es zwei lizenzgebührenfreie Verfahren zur E-Mail-Authentifizierung: Sender ID Framework (SIDF) und DomainKeys Identified Mail (DKIM). SIDF ist eine auf IP (Internet Protocol) basierende Lösung, die aus dem Zusammenschluss des Sender Policy Framework (SPF) und der Microsoft Caller ID for E-Mail geschaffen wurde. Im April des Jahres 2006 veröffentlichte die IETF (Internet Engineering Task Force) die Sender ID-Spezifikationen als RFC 4405 bis RFC 4408. Eine Koalition von Teilhabern aus Industrie und Wirtschaft einschließlich Microsoft empfiehlt die Bereitstellung von SIDF auf der Grundlage von Faktoren wie etwa geschäftlichem und technischem Wert, Stabilität, Ausgereiftheit, Einfachheit der Bereitstellung, minimale Auswirkung auf die Leistung bei der eingehenden und der ausgehenden Kommunikation sowie Interoperabilität mit dem E-Mail-Ökosystem für ISPs und Unternehmensumgebungen.

DKIM ist der Zusammenschluss der IIM-Spezifikationen (Identified Internet Mail) von Yahoo! DomainKeys und Cisco Systems Inc. Im Januar 2006 genehmigte die IETF die Einrichtung einer DKIM-Arbeitsgruppe, und die Spezifikation wird derzeit von der IETF geprüft.

Obwohl es keine perfekte Lösung zum Schutz gegen Spam gibt, stellt SIDF eine bedeutende Brancheninitiative zum Schutz gegen gefälschte Domänen dar. Aus diesem Grund ist es eine Schlüsselkomponente zur Reduzierung von Spam- und Phishingangriffen und zur Erhöhung des Vertrauens in Onlineverbindungen. Die Zahl der Organisationen, die SIDF nutzen, nimmt in der ganzen Welt rapide zu. Bis heute haben mehr als 5,5 Millionen Unternehmen und Domäneninhaber SPF-Datensätze veröffentlicht, und mehr als 600 Millionen Benutzer werden durch SIDF geschützt. Derzeit ist weltweit mehr als ein Drittel des täglichen E-Mail-Aufkommens authentifiziert und SIDF-kompatibel.

Die Entwicklung und die weltweite Akzeptanz von SIDF wäre ohne den Beitrag und die Unterstützung vieler Organisationen und Unternehmen einschließlich AOL, Authentication and Online Trust Alliance (AOTA), Bell Canada, E-Mail Senders Provider Coalition (ESPC), CipherTrust, Cisco Systems, IronPort Systems, MarkMonitor, Port25 Solutions Inc, Sendmail, Symantec, TRUSTe, VeriSign und anderen nicht möglich.

Einführung in Sender ID

Einige Branchenumfragen zeigen, dass über 95 Prozent der Phishingbetrugsdelikte von gefälschten Domänen herrühren und dabei mit gefälschten Absender-E-Mail-Adressen operiert wird. Dies ist genau der Punkt, an dem SIDF in Sachen Spamschutz einen gewaltigen Vorteil bietet. SIDF alleine wird das Problem der Spamangriffe nicht lösen, aber es trägt beträchtlich dazu bei, die Folgen von Spam- und Phishingangriffen zu minimieren. Durch SIDF wird nicht verhindert, dass Junk-E-Mail gesendet wird. Es macht es aber wesentlich leichter, Junk-E-Mail zu erkennen. Das Framework hilft E-Mail-Absendern, ihren Domänennamen, ihren guten Ruf und ihre Marken zu schützen. Es stellt eine stabile Grundlage bereit, um anhand der Zuverlässigkeit und des E-Mail-Verhaltens des Absenders Filterentscheidungen zu treffen.

Sender ID versucht zu überprüfen, ob jede E-Mail-Nachricht tatsächlich aus der Internetdomäne kommt, aus der sie vorgibt, gesendet worden zu sein. Dies wird bewerkstelligt, indem die Adresse des absendenden Servers anhand einer registrierten Liste von Servern überprüft wird, die der Besitzer der Domäne zum Senden von E-Mail autorisiert hat. Diese Überprüfung wird vom Internetdienstanbieter (ISP) oder vom E-Mail-Server des Empfängers automatisch durchgeführt, bevor die Nachricht zum Posteingang des Benutzers weitergeleitet wird.

Beachten Sie dabei, dass Sender ID oder alle sonstigen Authentifizierungsmechanismen keinen Ersatz für Inhaltsfiltersysteme sind. Weder SIDF noch DKIM überprüfen den Nachrichteninhalt selbst. Stattdessen teilt die Authentifizierung dem Eingangs-E-Mail-System mit, ob überprüft wurde, dass die Nachricht tatsächlich vom angeblichen Absender stammt. Da die meisten Spam- und Phishingversuche in Wirklichkeit nicht aus der angegebenen Domäne kommen, kann dieses Verfahren helfen, diese Nachrichten zu erkennen und sie aus dem Strom der eingehenden E-Mails herauszufiltern.

Innerhalb von SIDF stellt der SPF-Datensatz einen einfachen Textdatensatz aller Ausgangs-E-Mail-Server, die mit einer Domäne verknüpft sind, und ihrer jeweiligen IP-Adressen dar. Eine Organisation veröffentlicht den SPF-Datensatz in seiner DNS-Serverzonendatei, die dann von empfangenden E-Mail-Servern geprüft wird. Das Einrichten eines SPF-Datensatzes ist schnell, einfach und kostenlos. Der SPF-Datensatzassistent von Sender ID Framework (SIDF) stellt einen schrittweisen Prozess zum Überschauen der E-Mail-Server einer Domäne und zum Erstellen individuell angepasster, veröffentlichungsfertiger Datensätze bereit. (Details zur Veröffentlichung eines SPF-Datensatzes stehen unter microsoft.com/senderid zur Verfügung. Auf den Assistenten kann über microsoft.com/senderid/wizard direkt zugegriffen werden.)

Der empfangende SMTP-E-Mail-Server sendet eine Pinganforderung an die Zonendatei der Domäne im DNS, um zu prüfen, ob ein SPF-Datensatz vorhanden ist. Sobald der Datensatz gefunden wurde, wird die IP-Adresse des sendenden Servers anhand der aufgelisteten IP-Adressen geprüft. Wenn die IP-Adresse übereinstimmt, wird die Nachricht als authentisch gewertet. Stimmt dagegen der SPF-Datensatz in der Domäne des Absenders nicht mit der IP-Adresse überein, von der die Nachricht gesendet wurde, wird dies als negatives Ergebnis gewertet und die Nachricht möglicherweise im Ordner für Junk-E-Mail abgelegt. Abbildung 1 veranschaulicht diesen Prozess.

Abbildung 1** Überprüfen der SPF-Datensätze bei eingehenden Nachrichten **(Klicken Sie zum Vergrößern auf das Bild)

Nachdem die Nachricht markiert wurde, ermöglicht SIDF dem empfangenden E-Mail-Server, die Nachricht auf vergangenes Verhalten, Zuverlässigkeit des Absenders, Inhalt und andere von Ihnen nach Bedarf festgelegte Kriterien zu analysieren. Durch diese Fähigkeit werden zusätzliche Schutzvorrichtungen bereitgestellt. Spammer könnten beispielsweise im Aussehen ähnliche Domänen und SPF-Datensätze registrieren, um Benutzern und empfangenden Netzwerken vorzutäuschen, die E-Mail komme von einem legitimen Absender. Doch auch wenn die E-Mail-Nachricht die Authentifizierungsüberprüfung bestehen sollte, würde der Ruf des Absenders als Spammer genügen, die Nachricht zu blockieren, an den Papierkorb weiterzuleiten oder zu löschen.

Optionen zur Bereitstellung von Sender ID

Die Authentifizierung ausgehender E-Mails über SIDF erfordert keine Änderungen der Infrastruktur oder Softwareaktualisierungen und ist an keine spezielle Client- oder Serversoftware gebunden. Organisationen jedoch, die eine Eingangsauthentifizierung einrichten möchten, um ihr Unternehmen und ihre Arbeitnehmer zu schützen, müssen ihre Eingangssysteme und ihren MTA (Message Transfer Agent) aktualisieren und Software oder ein Gerät bereitstellen, das SIDF unterstützt. Die Mehrheit der führenden Anbieter von kommerziellen MTAs, Open Source-MTAs und Spamschutzprodukten einschließlich Microsoft® Exchange Server und Exchange Hosted Filtering bieten integrierte Lösungen an.

Microsoft hat SIDF in alle Messagingprodukte von Microsoft einschließlich Microsoft Exchange Server 2003 Service Pack 2 (SP2), Exchange Server 2007, Microsoft Exchange Hosted Filtering, Microsoft Windows Live™ Mail, MSN® Hotmail®, Outlook® und die Messaging- und Zusammenarbeitsclients von Office Outlook integriert.

Doch selbst Microsoft bleibt von Spam nicht verschont. Der täglich eingehende Datenverkehr beträgt bei Microsoft im Durchschnitt ungefähr 15 Millionen Nachrichten, und bei den in letzter Zeit erfolgten Spamangriffen sind zwei- bis viermal so viele Nachrichten eingegangen. In einer derartigen Umgebung lässt sich ein erfolgreicher Spamschutz am besten durch die rechtzeitige Implementierung der jeweils verfügbaren Technologien erzielen.

Bei Microsoft wird eine interne Exchange Server-Spamschutzlösung ausgeführt, die in Exchange Server 2003 auf dem Sender ID-Filter und in Exchange Server 2007 auf dem Sender ID-Agent beruht. In beiden Versionen von Exchange Server basiert der Sender ID-Status auf der Auswertung des Sender ID-Datensatzes, der sich auf den entsprechenden DNS-Servern befindet. Die tatsächliche Domäne wird ermittelt, indem die RFC 2822-Nachrichtenköpfe in der folgenden Reihenfolge untersucht werden:

1. Erneut gesendet-Absender
2. Erneut gesendet-Von
3. Absender
4. Von

Die Domäne des Absenders (oder die Entität, die zuletzt für das Einleiten einer Nachricht in den Messagingdatenstrom verantwortlich war, weil E-Mail-Systeme völlig legitim im Auftrag anderer E-Mail-Server E-Mail-Nachrichten weiterleiten können) wird ermittelt, indem in der festgelegten Reihenfolge nach der ersten Definition der eben erwähnten Nachrichtenköpfe gesucht wird. Wenn keiner dieser Nachrichtenköpfe gefunden wird, verwendet SIDF den SMTP RFC 2821 MAIL FROM-Wert.

Konfigurieren von Sender ID

In Exchange Server 2007 kann auf Servern, auf denen die Rolle „Edge Transport“ installiert ist, der Sender ID-Agent aktiviert werden. Wenn der Sender ID-Agent aktiviert ist, werden durch ihn Nachrichten gefiltert, die durch die Empfangsconnectors eintreffen. Dabei wird der gesamte aus externen Quellen eingehende nicht authentifizierte Datenverkehr dieser Verarbeitung durch Sender ID unterzogen. In Exchange Server 2003 ist der Sender ID-Status von Server zu Server im EXCH50-Blob festgeschrieben. In Exchange Server 2007 wurde er auch den Nachrichtenmetadaten hinzugefügt. Am endgültigen Ziel werden beide für die zukünftige clientseitige Nutzung in eine MAPI-Eigenschaft umgewandelt.

Die Konfiguration der Sender ID-Filter in Exchange Server 2003, die unter den Nachrichtenübermittlungseigenschaften zur Verfügung steht, besteht nur aus der Festlegung, wie Exchange Server auf fehlgeschlagene Prüfungen reagieren soll.

Um Sender ID in Exchange Server 2007 zu aktivieren, öffnen Sie einfach für einen Server, für den die Rolle „Edge Transport“ konfiguriert wurde, die Exchange-Verwaltungskonsole, wählen die Registerkarte „Anti-spam“ (Spamschutz), wählen „Sender ID“ aus und klicken wie in Abbildung 2 dargestellt im Fenster „Actions“ (Aktionen) auf „Enable“ (Aktivieren) oder „Disable“ (Deaktivieren), um den Sender ID-Agent ein- bzw. auszuschalten. Sie können auch wie in Abbildung 3 dargestellt die Exchange-Verwaltungsshell verwenden, um Sender ID zu aktivieren oder zu deaktivieren.

Abbildung 2** Steuerelemente der Exchange-Verwaltungskonsole für den Sender ID-Agent in Exchange Server 2007 **(Klicken Sie zum Vergrößern auf das Bild)

Abbildung 3** Aktivieren von Sender ID mithilfe der Exchange-Verwaltungsshell **(Klicken Sie zum Vergrößern auf das Bild)

Im Dialogfeld „Properties“ (Eigenschaften) von Sender ID wird der Status (aktiviert bzw. deaktiviert) des Agent angezeigt. Auf der Registerkarte „Action“ (Aktion) werden Optionen bereitgestellt, die den in Exchange Server 2003 verfügbaren Optionen sehr ähnlich sind (siehe Abbildung 4).

Abbildung 4** Aktionseigenschaften des Sender ID-Agent in Exchange Server 2007 **(Klicken Sie zum Vergrößern auf das Bild)

Hinsichtlich der Implementierung und der Funktionalität von Sender ID besteht zwischen Exchange Server 2003 und Exchange Server 2007 kein großer Unterschied. Sowohl der Sender ID-Filter (in Exchange Server 2003) als auch der Sender ID-Agent (in Exchange Server 2007) verwenden zur Extrahierung und Überprüfung denselben Basisalgorithmus. Die Palette der möglichen Aktionen ist ebenfalls identisch: Nachricht löschen (stilles Löschen), Nachricht zurückweisen (500-Level-SMTP-Protokollantwort) sowie Nachricht mit Sender ID-Ergebnis bestempeln und Verarbeitung fortsetzen. Die zuletzt genannte Option ist in beiden Versionen von Exchange Server die Standardaktion.

In Exchange Server 2007 können sowohl der Statuscode „Fail“ (Durchgefallen) als auch der Statuscode „TempError“ (Temporärer Fehler) die Aktion „Nachricht zurückweisen“ auslösen. (In Exchange Server 2003 kann diese Aktion nur durch den Statuscode „Fail“ (Durchgefallen) ausgelöst werden.) Der Sender ID-Agent muss explizit konfiguriert werden, damit die Aktion „Nachricht zurückweisen“ auch bei Nachrichten mit dem Statuscode „TempError“ (Temporärer Fehler) ausgelöst wird, weil Nachrichten dieser Art standardmäßig im System akzeptiert, mit dem Sender ID-Ergebnis bestempelt und danach verarbeitet werden.

Da die dafür zuständige Konfigurationsoption nicht in der grafischen Benutzeroberfläche zur Verfügung steht, müssen Sie die Exchange-Verwaltungsshell verwenden, um Sender ID-Aktionen für den Statuscode „TempError“ (Temporärer Fehler) zu konfigurieren. Wenn Sie beispielsweise den Sender ID-Agent dafür konfigurieren möchten, Nachrichten mit dem Statuscode „TempError“ (Temporärer Fehler) zurückzuweisen, führen Sie das folgende Cmdlet des Sender ID-Agent aus:

Set-SenderIDConfig -TempErrorAction Reject

Die Palette der Sender ID-Statusergebnisse und der möglichen Aktionen in Exchange Server 2007 ähnelt der Palette des Sender ID-Filters in Exchange Server 2003 und wird in Abbildung 5 dargestellt.

Figure 5 Sender ID-Status und Sender ID-Aktionen in Exchange Server 2007

Exchange löscht (sofern es dafür konfiguriert wurde) nur Nachrichten, die bei der Sender ID-Überprüfung durchgefallen sind. Keine anderen Ergebnisse lösen das Löschen von Nachrichten aus. Eingehende Nachrichten, denen der Status „Neutral“, „None“ (Kein), „SoftFail“ (Leicht durchgefallen), „TempError“ (Temporärer Fehler) oder „PermError“ (Permanenter Fehler) zugewiesen wurde, werden entsprechend bestempelt und zur weiteren Spamschutzüberprüfung weitergeleitet. In einigen Fällen, wenn die Nachricht extrem fehlerhaft ist und die VON-Angabe der IP-Adresse des Absenders fehlt, kann der Sender ID-Status nicht auf die Nachricht gestempelt werden. In diesem Fall wird die Nachricht nicht verworfen oder zurückgewiesen. Stattdessen wird sie ohne Zuweisung eines Sender ID-Status zur weiteren Verarbeitung weitergeleitet, und es wird ein entsprechendes Ereignis ins Protokoll aufgenommen, um auf diese Nachricht aufmerksam zu machen.

In Exchange Server 2007 ist es leicht, Absenderdomänen und Exchange Server-Empfänger festzulegen, die von der Sender ID-Überprüfung ausgeschlossen werden sollen. Auch diese Konfigurationsoption ist nur über die Exchange-Verwaltungsshell verfügbar. Um beispielsweise die Domäne „contoso.com“ von der Sender ID-Filterung auszuschließen, führen Sie den folgenden Befehl aus:

Set-SenderIDConfig -BypassedSenderDomains contoso.com

Ähnlich können Sie auch Nachrichten, die an bestimmte festgelegte Exchange Server-Empfänger gesendet werden, von der Sender ID-Filterung ausschließen, indem Sie den folgenden Befehl ausführen:

Set-SenderIDConfig -BypassedRecipients user@contoso.com

In Exchange Server 2007 können Sender ID-Konfigurationswerte, die über Cmdlets von der Exchange-Verwaltungsshell eingestellt wurden, aber über die grafische Benutzeroberfläche nicht eingesehen werden können, problemlos abgerufen werden, indem wie in Abbildung 6 dargestellt in der Exchange-Verwaltungsshell der Befehl „Get-SenderIDConfig“ ausgeführt wird.

Abbildung 6** Konfigurations-Cmdlets von Sender ID **(Klicken Sie zum Vergrößern auf das Bild)

Mit der Exchange-Verwaltungsshell kann eine schnelle manuelle Überprüfung der IP-Adresse und des zugehörigen Domänennamens durchgeführt werden. Um den Sender ID-Status zu prüfen, führen Sie den folgenden Befehl aus:

Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>

Wenn die Domäne nicht existiert, werden Sie ein Ergebnis sehen, das dem in Abbildung 7 gezeigten Ergebnis ähnelt.

Abbildung 7** Überprüfung des Sender ID-Status einer Adresse **(Klicken Sie zum Vergrößern auf das Bild)

Vorteile von Sender ID

Neben seinen offensichtlichen Vorteilen beim Authentifizieren von E-Mail-Nachrichten und beim Reduzieren der Zahl der Spam-E-Mails, die bei den Benutzern eintreffen, bietet SIDF als Protokoll noch weitere Vorzüge. Bei seiner Entwicklung hat man sich bei Microsoft auf mehrere Schlüsselziele wie beispielsweise Leistung, Kosten, Bereitstellung und Skalierbarkeit sowie Interoperabilität konzentriert.

SIDF authentifiziert zuerst den E-Mail-Absender und zieht die Zuverlässigkeit dieses Absenders in Betracht. Dadurch lässt sich die Anzahl der Spam-E-Mails und der mit falschen Angaben eintreffenden E-Mail-Nachrichten beträchtlich verringern und die Zustellung legitimer E-Mail-Nachrichten von bekannten und vertrauenswürdigen Absendern im gleichen Maße verbessern. Weil das Erstellen eines SPF-Datensatzes kostenlos ist, kann jede Organisation, die ihr System SIDF-kompatibel machen möchte, dies problemlos tun. Organisationen, die den Wunsch haben, den Richtlinien eines neuen Standards zu entsprechen, sollten in der Lage sein, dies in die Tat umzusetzen. Mit SIDF ist das Erreichen dieser Kompatibilität nicht schwerer als das Veröffentlichen eines SPF-Datensatzes.

SIDF wurde mit dem Ziel entwickelt, innerhalb bereits vorhandener Software zu arbeiten, sofern dies möglich ist. Es kann mit einer breiten Palette von E-Mail-Architekturen sowie Client- und Serversoftware verwendet werden. Um effektiv zu arbeiten, muss jeder Authentifizierungsdienst in der Lage sein, die Anforderungen der größten ISPs genauso leicht wie die des kleinsten privaten E-Mail-Servers zu erfüllen. SIDF kann einen einzelnen E-Mail-Server oder auch tausende von E-Mail-Servern unterstützen, einschließlich derjenigen E-Mail-Server, die in andere Organisationen ausgelagert wurden.

Am 18. und 19. April 2007 werden Microsoft und ein Branchenkonsortium von über 30 Organisationen und Partnern in Boston (Massachusetts) den „Authentication & Online Identity Summit“ veranstalten. Bei dieser zweitägigen Veranstaltung werden Fallstudien erörtert und eine technische Begutachtung von Sender ID vorgestellt, in der im Einzelnen auf den Geschäftswert der E-Mail-Authentifizierung eingegangen wird. Weitere Informationen finden Sie unter aotalliance.org/summit2007. Zusätzliche Informationen sowie Tools und Ressourcen finden Sie unter microsoft.com/senderid und microsoft.com/exchange.

Craig Spiezle ist Direktor von Technology Strategy and Planning for Windows Live Safety bei Microsoft. Als Produktmanager für E-Mail-Authentifizierung war Craig eine der treibenden Kräfte, die in der Branche Sender ID eingeführt haben. Seit Craig im Jahr 1992 bei Microsoft angefangen hat, hatte er mehrere Verwaltungspositionen inne, darunter Positionen in den Bereichen internationales Marketing, Produktsupportstrategien, OEM und Entwicklung neuer Märkte.

Alexander Nikolayev ist bei Microsoft als Program Manager für serverseitige Protokolle, Transportkern und Antispamkomponenten für Exchange Server und Windows Server zuständig. Er besitzt einen MBA der Universität von Mary. Lesen Sie die Beiträge von Alexander auf dem Exchange-Teamblog unter blogs.technet.com/exchange.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.