Kommunikation

Exchange-Edge-Transport-Server bei Microsoft: Teil 2

Kay Unkroth

Kurz zusammengefasst:

• Verwenden von Edge-Transport-Protokollen und -Ablaufverfolgungen
• Antispamkonfiguration mit Skripts
• Testen typischer Spamszenarios

Laden Sie den Code für diesen Artikel herunter: Edge2007_11.exe (161KB)

Wie können Sie angesichts einer Flut von Spam und anderen schädlichen Inhalten, die das Internet überschwemmen, für die Benutzer innerhalb Ihrer Organisation ein zuverlässiges und sicheres Messaging gewährleisten? Eine Möglichkeit, die im letzten Monat im ersten Teil dieser Reihe beschrieben wurde, besteht darin,

Edge-Transport-Server für Exchange Server 2007 und Forefront Security für Exchange Server in einem Umkreisnetzwerk zwischen dem Internet und der Produktionsumgebung bereitzustellen.

In diesem zweiten und letzten Teil der Artikelreihe wird erläutert, wie sich aktuell ausgeführte Edge-Transport-Agents durch Standardfeatures von Exchange Server 2007 für Agentprotokollierung und -ablaufverfolgung analysieren lassen. Dabei wird auch eine benutzerdefinierte Methode verwendet, um alle Ereignisobjekte aus der Transportpipeline in XML-basierten Dateien zu sichern. Danach wird aufgezeigt, wie Antispameinstellungen gemäß der von Microsoft in der eigenen unternehmensinternen Produktionsumgebung verwendeten Konfiguration auf eine Edge-Transport-Testumgebung angewendet werden. Zum Schluss wird anhand einiger realistischer und interessanter Testszenarios vorgeführt, wie Edge-Transport-Agents auf verschiedene Spamsituationen reagieren.

Weitere Informationen zur Installation der Edge-Transport-Testumgebung und zur allgemeinen Edge-Transport-Architektur finden Sie im ersten Artikel dieser Reihe in der im Oktober 2007 erschienenen Ausgabe des TechNet Magazins, der unter technetmagazine.com/issues/2007/10/Edge verfügbar ist.

Zur Automatisierung der wichtigsten Konfigurationsaufgaben wurden zahlreiche Skripts und Batchdateien verwendet. Diese Skripts finden Sie im Codedownload zu diesem Artikel (unter technetmagazine.com/code07.aspx). Empfehlenswert für ausführlichere Hintergrundinformationen zur von Microsoft verwendeten IT-Konfiguration von Edge-Transport-Agents ist das technische Whitepaper „Microsoft® Exchange Server 2007-Edge-Transport und -Messagingschutz“, das für Microsoft IT Showcase erstellt wurde. Sie können dieses IT Showcase-Whitepaper von microsoft.com/technet/itshowcase/content/edgetransport.mspx herunterladen.

Protokollierung und Ablaufverfolgung

Exchange Server 2007 umfasst eine Reihe von Protokollierungs- und Ablaufverfolgungsfeatures einschließlich der Protokollprotokollierung, der Agentprotokollierung und der Pipelineablaufverfolgung, durch die Diagnose und Problembehandlung von Transport-Agent-Problemen erleichtert werden. Obwohl sich dieser Artikel eigentlich nicht mit der Fehlerbehebung von Transport-Agents beschäftigt, sind die Protokollierungs- und Ablaufverfolgungsinformationen nützlich, um die Funktionsweise von Edge-Transport-Agents zu verstehen.

Wenn Sie Informationen zu SMTP-Sende- und -Empfangsaktivitäten verfolgen möchten, müssen Sie für Sende- und Empfangsconnectors die Protokollprotokollierung aktivieren. Unter Verwendung der im ersten Teil dieser Reihe eingerichteten Testumgebung (siehe Abbildung 1) wurde über die folgende Einstellung in den New-SendConnector- und New-ReceiveConnector-Cmdlets die Protokollprotokollierung aktiviert:

Abbildung 1** Die Testumgebung **

–ProtocolLoggingLevel: Verbose

Die generierten SMTP-Protokolldateien sind standardmäßig in Unterordnern des Ordners %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog zu finden.

Die Protokollprotokollierung ist für eine Analyse des SMTP-Nachrichtenaustauschs nützlich, denn Antispam-Agents greifen nicht immer in die SMTP-Sitzung ein. So kann es beispielsweise vorkommen, dass der Inhaltsfilter-Agent nur eingehende Nachrichten mit einem SCL (Spam Confidence Level)-Wert versieht. Solange der SCL-Wert unter einem festgelegten Grenzwert (Standardeinstellung: 7) liegt, veranlasst der Inhaltsfilter-Agent nicht, dass die Nachricht vom Edge-Transport-Prozess zurückgewiesen wird. Daher wird der SMTP-Nachrichtenaustausch unbeeinträchtigt fortgesetzt.

Um die Aktionen zu analysieren, die diese Antispam-Agents (Verbindungsfilter, Inhaltsfilter, Edge-Regeln, Empfängerfilter, Absenderfilter und Absender-ID) an den Nachrichten durchführen, die die Transportpipeline durchlaufen, müssen Sie statt der Protokollprotokolle die Agentprotokolle überprüfen. Die Agentprotokollierung wird normalerweise über den AgentLogEnabled-Parameter in der Datei „EdgeTransport.exe.config“ aktiviert. Standardmäßig befinden sich Agentprotokolle im Ordner %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\AgentLog. Sie können die Protokolle zwar auch in Editor öffnen, aber das Get-AgentLog-Cmdlet zeigt die Informationen der Agentprotokolle intuitiver in der Exchange-Verwaltungsshell an.

Ein weiteres nützliches Feature ist die Pipelineablaufverfolgung, die es ermöglicht, Snapshots der von einem bestimmten Absender gesendeten Nachrichten aufzuzeichnen, während die Nachrichten die Transportpipeline durchlaufen. Diesem Vorgang liegt eine relativ einfache Idee zugrunde: Der Edge-Transport-Prozess erstellt von jeder Nachricht einen Snapshot, bevor und nachdem die für die Ereignisse „OnEndOfHeaders“, „OnEndofData“, „OnSubmittedMessage“ und „OnRoutedMessage“ registrierten SMTP-Empfangs- und Routing-Agents aufgerufen werden. Durch einen Vergleich der Nachrichtensnapshots können Sie erkennen, wie jede Nachricht von den einzelnen Agents verändert wird. Natürlich sollte dieses nützliche Feature unbedingt in der Testumgebung aktiviert werden.

Durch Verwendung des Set-TransportServer-Cmdlets wie hier gezeigt wird die Pipelineablaufverfolgung für einen Testbenutzer aktiviert. Wie zu erwarten ist, aktiviert der auf „$true“ eingestellte PipelineTracingEnable-Parameter die Pipelineablaufverfolgung. Die E-Mail-Adresse des Testbenutzers wird über den PipelineTracingSenderAddress-Parameter festgelegt:

Set-TransportServer –Identity EDGE01 
–PipelineTracingEnabled $true 
-PipelineTracingSenderAddress Contoso.User@contoso.com

Wenn die Pipelineablaufverfolgung aktiviert ist, sind im Ordner %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing\MessageSnapshots Nachrichtensnapshotdateien für jede vom festgelegten Absender (in diesem Fall heißt der Benutzer „Contoso.User@contoso.com“) gesendete Nachricht verfügbar Dies ist der Standardordner. Die Snapshotdateien für jede Nachricht befinden sich in einem Unterverzeichnis, das gemäß einer der betreffenden Nachricht zugewiesenen GUID benannt wurde. Beachten Sie, dass die ursprüngliche Nachricht in einer Datei namens „Original.eml“ und Kopien der Nachricht in .eml-Dateien zu finden sind, deren Dateinamen abhängig von den aufgetretenen Ereignissen und den installierten Agents mit „SmtpReceive“ oder „Routing“ beginnen. Überprüfen Sie zum Analysieren der für die SMTP-Empfangsereignisse „OnEndofData“ und „OnEndOfHeaders“ registrierten Antispam-Agents die mit „SmtpReceive“ beginnenden .eml-Dateien. Wenn Sie die Verarbeitung von Antivirus-Agents und anderen Agents analysieren möchten, die für die Routingereignisse „OnSubmittedMessage“ und „OnRoutedMessage“ registriert sind, dann überprüfen Sie stattdessen die mit „Routing“ beginnenden .eml-Dateien.

Benutzerdefinierte Pipelinesicherung

Die Standardfeatures von Exchange Server 2007 für Agentprotokollierung und -ablaufverfolgung erfüllen trotz der Tatsache, dass die Standardfeatures nicht alle Transportereignisse abdecken, sämtliche Problembehandlungsanforderungen. So kann die Pipelineablaufverfolgung beispielsweise keine Informationen zu „OnConnectEvent“, „OnEhloCommand“, „OnMailCommand“, „OnRcptCommand“, „OnDataCommand“ und ähnlichen Transportereignissen aufzeichnen, weil der sendende Host noch keine Nachrichten übertragen hat, die in den Ordner %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing geschrieben werden könnten. Wenn Sie ausführliche Informationen zu diesen Ereignissen aufzeichnen möchten, müssen Sie einen benutzerdefinierten Agent implementieren, der die Ereignisdaten in Dateien auf dem Dateisystem sichert.

Wie im vorherigen Artikel erläutert wurde, ist das Erstellen benutzerdefinierter Agents nicht schwer, und daher bot es sich an, einen SMTP-Empfangs-Agent und einen Routing-Agent zu erstellen, um alle Ereignisobjekte aus der Transportpipeline in XML-Dateien zu sichern. Im Download für diesen Artikel finden Sie ein entsprechendes Microsoft Visual Studio® 2005-Projekt namens „PipelineXMLDump“. Wichtig sind zwei Dateien, „DumpAgents.cs“, von der die Agent-Factorys und Agents implementiert werden, und „XMLDump.cs“, die eine Hilfsklasse implementiert, um mithilfe von System.Reflection-Methoden die Felder von Ereignisquell- und Ereignisargumentobjekten in XML-Dateien zu schreiben. Wenn Sie den Quellcode kompilieren und die dadurch entstehende Datei „PipelineXMLDump.dll“ in einen Ordner namens C:\PipelineXMLDump auf dem Edge-Transport-Testserver kopieren, können Sie die benutzerdefinierten Agents mithilfe der RegisterPipelineXMLDump.ps1- und EnableDumpAgents.ps1-Skripts registrieren und aktivieren. Die Skripts sind im Download im PipelineXMLDump-Projektordner enthalten. Die benutzerdefinierten Agents dienen natürlich lediglich zu Demonstrationszwecken, wurden nicht ausreichend getestet und sollten nie auf einem Produktionsserver installiert werden. Die Verwendung dieser Agents ist auf eigene Gefahr.

In der Datei „DumpAgents.cs“ wird aufgezeigt, wie Sie alle SMTP-Empfangs- und Routing-Ereignishandler implementieren können, die von der Transportpipeline unterstützt werden. Sie ist eine gute Ausgangsbasis, wenn Sie Ihre eigenen benutzerdefinierten Agents implementieren möchten. Die Sicherungsagents in diesem Beispiel schreiben XML-Dateien in Unterordner des Ordners %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineXMLDump, die dem Bezeichner der SMTP-Sitzung (SMTP-Empfangs-Agent) oder dem Nachrichtenbezeichner (Routing-Agent) entsprechen. Abbildung 2 enthält ein Beispiel für Ereignisargumentinformationen, die im OnConnectEvent-Handler dem SMTP-Empfangs-Agent übergeben werden. Dieses Beispiel zeigt den lokalen IP-Endpunkt (IP-Adresse und Port), der eine eingehende Verbindungsanforderung akzeptiert hat.

Abbildung 2** Während des OnConnect-Ereignisses gesicherte Argumentinformationen **(Klicken Sie zum Vergrößern auf das Bild)

Vorbereiten der Testläufe

Doch damit genug der Theorie des Protokollierens, der Ablaufverfolgung und des Sicherns. Im Folgenden werden einige Testläufe ausgeführt, um Ihnen die Antispam-Agents in Aktion vorzuführen. Zunächst folgt ein kurzer Überblick der Konfiguration Ihrer Testumgebung, die der IT-Konfiguration von Microsoft so weit wie möglich entspricht. Wie bereits erwähnt sind im technischen Whitepaper „Microsoft Exchange Server 2007-Edge-Transport und -Messagingschutz“ Hintergrundinformationen verfügbar.

Deaktivieren Sie zunächst durch Ausführen des im begleitenden Download enthaltenen Skripts „EDGE01_disable_agents.ps1“ die Agents Address Rewriting Inbound (eingehende Adressumschreibung), Attachment Filter (Anlagenfilter) und Address Rewriting Outbound (ausgehende Adressumschreibung). Eine Adressumschreibung ist nicht erforderlich, weil die Empfänger sowohl intern als auch extern dieselben E-Mail-Adressen verwenden. Ich verwende den Anlagenfilteragent deshalb nicht, weil in Forefront Security vorrangige Anlagenfilterfunktionen verfügbar sind.

Die Testumgebung ist nicht mit dem Internet verbunden. Dies erschwert die Aufgabe, den Verbindungsfilter-Agent zu testen. Um dieses Problem zu beheben, können Sie auf dem Internethost eine IP-Sperrliste erstellen, indem Sie die Datei „INTERNET01_create_IP_block_list.bat“ ausführen. Stellen Sie sicher, dass die Windows®-Supporttools installiert sind, da sie das DNS-Befehlszeilentool (dnscmd.exe) enthalten. Andernfalls müssen die DNS-Einträge zeitaufwändig über die DNS-Konsole manuell erstellt werden.

Nun können Sie den Verbindungsfilter-Agent durch Ausführen des Skripts „EDGE01_add_block_list_provider.ps1“ konfigurieren. Dieses Skript fügt ip-bl.consolidatedmessenger.com einen IP-Sperrlistenanbieter hinzu. Dies ist die IP-Sperrliste von Consolidated Messenger, die in der Testumgebung bereits erstellt wurde, indem auf dem Internethost, wie bereits erwähnt, die Datei „INTERNET01_create_IP_block_list.bat“ ausgeführt wurde. In der IT-Konfiguration von Microsoft wird ebenfalls die lokale IP-Sperrliste und die lokale IP-Zulassungsliste verwendet, aber diese Features erfordern keine manuelle Konfiguration. An dieser Stelle ist es wichtig, darauf hinzuweisen, dass bei Microsoft keine IP-Zulassungslistenanbieter verwendet werden.

Konfigurieren Sie im nächsten Schritt durch Ausführen des EDGE01_recipient_filter.ps1-Skripts den Empfängerfilter-Agent so, dass sowohl Nachrichten an nicht existierende Empfänger als auch Nachrichten an Postfächer und globale Verteilerlisten, die nur zur internen oder ausgehenden Verwendung vorgesehen sind, blockiert werden.

Die Konfiguration des Absenderfilter-Agent muss ebenfalls aktualisiert werden. In der IT-Konfiguration von Microsoft wird als Gegenmaßnahme zum Schutz gegen Angriffe durch eine Überschwemmung mit E-Mails von bestimmten Absenderadressen und zum Blockieren bestimmter Listenserver und ähnlicher Quellen, die für das Unternehmen als irrelevant erachtet werden, ebenfalls Absenderfilterung verwendet. Absenderfilterung wird in der IT-Konfiguration von Microsoft auch dafür eingesetzt, Nachrichten mit ungültigen oder fehlenden Absenderangaben zu blockieren. Wenden Sie diese Konfiguration auf die Testumgebung an, indem Sie auf dem Edge-Transport-Server das EDGE01_sender_filter.ps1-Skript ausführen.

Sie müssen auch SPF (Sender Policy Framework)-Datensätze im DNS konfigurieren, wenn Sie die IT-Konfiguration von Microsoft nachahmen möchten. Zum Generieren eines SPF-Datensatzes, der die Befugnis Ihres Edge-Transport-Servers für Nachrichten aus Ihrer Domäne (adventure-works.com) attestiert, können Sie den SPF-Datensatzassistent von Sender ID Framework (SIDF) von Microsoft verwenden, der über die Website microsoft.com/mscorp/safety/content/technologies/senderid/wizard verfügbar ist. Geben Sie versuchsweise einen existierenden Internet-Domänennamen an. In der Testumgebung können Sie die Datei „INTERNET01_create_SPF_record.bat“ auf dem Internethost ausführen.

Das ist schon alles. Es müssen keine weiteren Parameter konfiguriert werden, weil die meisten Agents sinnvolle Standardeinstellungen besitzen. Um eine schnelle Überprüfung der wichtigsten Standardeinstellungen für den Edge-Regeln-Agent, den Absender-ID-Agent, den Protokollanalyse-Agent und den Inhaltsfilter-Agent durchzuführen, führen Sie das EDGE01_check_defaults.ps1-Skript auf dem Edge-Transport-Server aus.

Edge-Transport-Agents in Aktion

Nun werden die Edge-Transport-Agents in einigen realistischen Messagingszenarios eingesetzt. Um Testnachrichten an den Edge-Transport-Server zu senden, wird als Messaging-Client der in Windows Server 2003 und Outlook® Express enthaltene SMTP- und POP3-Dienst verwendet, wobei in den meisten Fällen die Standardeinstellungen beibehalten werden, die Protokollierung allerdings immer aktiviert ist.

Doch zunächst eine Warnung: Führen Sie keinen der in diesem Abschnitt beschriebenen Schritte und keines dieser Skripts aus, wenn Ihre Testumgebung mit einem Produktionssystem oder dem Internet verbunden ist. Sie testen auf eigene Gefahr.

Der erste hier getestete Agent ist der Verbindungsfilter-Agent. Dieser Agent verdient es, an erster Stelle zu stehen, weil er auf einem Edge-Transport-Server die Schwerarbeit leistet. Bei Microsoft blockiert der Verbindungsfilter-Agent ungefähr 88 Prozent aller Internet-Nachrichtenübermittlungen. Von 13 Millionen Übertragungsversuchen, die an einem normalen Arbeitstag unternommen werden, stammen nur ungefähr 1,5 Millionen von legitimen Absendern.

Senden Sie also als „Fabrikam.User@Fabrikam.com“ eine E-Mail an „Administrator@adventure-works.com“. Wenn alles richtig funktioniert, dürfte der Administrator die Nachricht nicht erhalten. Stattdessen müsste „Fabrikam.User“ eine Benachrichtigung über den Zustellungsstatus (Delivery Status Notification, DSN) erhalten, die besagt, dass die Zustellung der E-Mail an diesen Empfänger fehlgeschlagen ist. Der Benutzer „Fabrikam.User“ überprüft die Richtigkeit der E-Mail-Adresse, sendet dieselbe Nachricht erneut und erhält wieder eine DSN. Danach ruft „Fabrikam.User“ den Helpdesk an und meldet das Problem. Er ist nicht der erste Benutzer, der sich an den Helpdesk wendet. Tatsächlich kann überhaupt niemand mehr bei Fabrikam mit Adventure Works kommunizieren. Es ist ein Problem aufgetreten, das dringend behoben werden muss. Für eine schnelle Problemlösung überprüfen Sie die SMTP-Protokolle im Ordner %systemroot%\system32\Logfiles\SMTPSVC1 auf INTERNET01 und stoßen auf das, was der rote Text in Abbildung 3 zeigt.

Figure 3 SMTP-Protokolle machen das Problem sichtbar

... 220 mail.adventure-works.com Microsoft ESMTP MAIL Service ready at Thu, 
31 May 2007 12:21:33 -0700,
... EHLO, -, INTERNET01,
... 250-mail.adventure-works.com Hello [192.168.1.100],
... MAIL, -, FROM:<Fabrikam.User@fabrikam.com> SIZE=840,
... 250 2.1.0 Sender OK,
... RCPT, -, TO:<Administrator@adventure-works.com>,
... 550 5.7.1 E-mail rejected because your IP address is listed by 
ip-bl.consolidatedmessenger.com. Please visit 
http://www.consolidatedmessenger.com/ip-bl for more information. 
If you still need assistance, contact cmipbl@adventure-works.com.,
... RSET, -, -,
... 250 2.0.0 Resetting,
... QUIT, -, -,
... 221 2.0.0 Service closing transmission channel,

Fehler 550 besagt, dass Consolidated Messenger die IP-Adresse Ihres Internethosts in eine IP-Sperrliste aufgenommen hat. Das erklärt natürlich die Sache. Sie kontaktieren Consolidated Messenger, um aus dieser Liste entfernt zu werden. Wie es sich herausstellt, ist es leichter, in die Sperrliste von Consolidated Messenger aufgenommen als aus ihr entfernt zu werden. Es wird Tage oder vielleicht sogar Wochen dauern, um hier wieder Ordnung zu schaffen.

Sie müssen jedoch schneller Abhilfe schaffen, und deshalb wenden Sie sich über die E-Mail-Adresse „cmipbl@adventure-works.com“ an Adventure Works. Sie senden eine E-Mail als „Fabrikam.Admin@Fabrikam.com“, beschreiben die Lage und bitten darum, die Blockierung der Internet-IP-Adresse Ihres Hosts (192.168.1.100) aufzuheben. Nach Überprüfung Ihrer Identität hebt Adventure Works mithilfe des folgenden Befehls, der eine nach 30 Tagen automatisch endende temporäre Ausnahme gewährt, die Blockierung der Adresse auf:

Add-IPAllowListEntry -IPAddress 192.168.1.100 
-ExpirationTime (get-date).AddDays(30)

Dreißig Tage müssten genügen, um das Problem mit Consolidated Messenger zu regeln, und Adventure Works muss keine Zeit dafür aufwenden, die Ausnahme manuell zu warten. Durch Gewähren von Ausnahmen, die automatisch beendet werden, hält Adventure Works den mit der Verwaltung von IP-Zulassungslisten verbundenen zusätzlichen administrativen Aufwand so gering wie möglich.

Sicherer Absender

Testen Sie im nächsten Schritt die Fähigkeit der Inhaltsfilterung, sichere Absender zu erkennen, denn dies ist ein interessantes neues Feature, durch das die Spamfilterung präziser arbeitet. „EdgeSync“ überträgt aus der internen Umgebung Informationen über sichere Absender in auf Hashwerten basierendem und verschlüsseltem Format an Edge-Transport-Server. Der Inhaltsfilter-Agent verwendet diese Informationen während des Filterungsprozesses, um auf Daten basierende intelligente Entscheidungen zu treffen. Sie müssen lediglich die Informationen über sichere Absender (d. h. die Liste der sicheren Absender, die Liste der sicheren Empfänger, die Liste der blockierten Absender und die externen Kontakte) mithilfe des Update-SafeList-Cmdlets in Active Directory® einlesen und diese Informationen anschließend mithilfe des Start-EdgeSynchronization-Cmdlets auf dem Edge-Transport-Server replizieren. In der IT-Konfiguration von Microsoft wird in Zeiten mit geringem Arbeitsaufkommen regelmäßig das Update-SafeList-Cmdlet ausgeführt. In Ihrer Testumgebung genügt es, ein entsprechendes Skript (HUB-MBX-01_update_safelist.ps1) manuell auszuführen.

Bereinigen Sie zunächst die Testumgebung, indem Sie das EDGE01_clean_up.ps1-Skript auf dem Edge-Transport-Server ausführen, um den zuvor erstellten IP-Zulassungslisteneintrag zu entfernen. Dies ist erforderlich, weil der Inhaltsfilter-Agent auf Nachrichten aus Quellen, die in dieser Liste eingetragen sind, nicht reagiert. Entfernen Sie danach den IP-Sperrlisteneintrag für 100.1.168.192.ip-bl.consolidatedmessenger.com aus der Consolidated Messenger-Sperrliste, indem Sie die Datei „INTERNET01_clean_up.bat“ auf dem Internethost ausführen. Andernfalls kann der simulierte Internethost, wie bereits demonstriert wurde, keine Nachrichten senden.

Senden Sie zum Schluss eine Nachricht, die der Inhaltsfilter-Agent mit fast absoluter Sicherheit als Spam betrachten wird. Dies ist schwierig, da der Inhaltsfilter-Agent zum Zustellen der meisten Nachrichten an die Benutzer den standardmäßigen SCL-Zurückweisungsgrenzwert verwendet, um die Anzahl falscher Positivdiagnosen möglichst gering zu halten. Nach einigen Tests habe ich jedoch eine Nachrichtenversion gefunden, die die SCL-Bewertung bis auf die Zurückweisungsstufe hochtreibt. Um die Nachricht als „Contoso.User@Contoso.com“ zu senden, führen Sie das Skript „INTERNET01_contoso_msg.vbs“ auf dem Internethost aus.

In diesem Skript wird eine anonyme SMTP-Verbindung verwendet, um die Nachricht an den SMTP-Dienst auf INTERNET01 zu senden. Damit es funktioniert, müssen Sie den SMTP-Dienst so konfigurieren, dass Nachrichten anonymer Benutzer weitergeleitet werden. Öffnen Sie in IIS Manager die Eigenschaften für den virtuellen SMTP-Standardserver. Klicken Sie auf der Registerkarte „Access“ (Zugriff) auf die Schaltfläche „Relay“ (Weiterleiten), und wählen Sie danach die Option „All except the list below“ (Alle außer der unten stehenden Liste) aus. Die Auswirkungen dieser Konfiguration werden etwas weiter unten erläutert.

Wenn Sie das Skript ausführen, um diese Nachricht zu senden, müsste „Contoso.User“ eine DSN erhalten, die besagt, dass die Zustellung aus folgendem Grund fehlgeschlagen ist: Diagnostic-Code: smtp;550 5.7.1 Message rejected due to content restrictions (Nachricht aufgrund von Inhaltsbeschränkungen zurückgewiesen). Diese Antwort ist auch im SMTP-Protokoll auf dem Internethost aufgeführt, und wenn Sie den Befehl „Get-AgentLog“ | „Select-Object -Last 1“ auf dem Edge-Transport-Server ausführen, um den letzten Eintrag des Agentprotokolls anzuzeigen, erkennen Sie, dass die Nachricht zurückgewiesen wurde, weil sie die SCL-Bewertung 7 besitzt, wie in Abbildung 4 zu sehen ist.

Abbildung 4** Aufgrund von Inhaltsbeschränkungen blockierte Nachricht **(Klicken Sie zum Vergrößern auf das Bild)

Allerdings ist „Contoso.User“ kein Spammer. Bedauerlicherweise wurde die Nachricht in diesem Fall nicht durchgelassen, aber normalerweise kann „Contoso.User“ mit Empfängern bei Adventure Works kommunizieren. Daher informiert „Contoso.User“ in einer weiteren E-Mail den Administrator, dass die ursprüngliche Nachricht versehentlich blockiert wurde. Der Administrator kennt „Contoso.User“ und nimmt „Contoso.User“ in die Liste der sicheren Absender auf, um sicherzustellen, dass seine Nachrichten zukünftig nicht mehr durch Spamfilter blockiert werden. Um dies in Office Outlook 2007 durchzuführen, klicken Sie mit der rechten Maustaste auf eine von „Contoso.User“ eingetroffene Nachricht, richten Sie den Mauszeiger auf „Junk-E-Mail“, und klicken Sie auf „Absender zur Liste sicherer Absender hinzufügen“.

Das Update-SafeList-Cmdlet wird zum normalen Intervall ausgeführt, um in Active Directory die Informationen der Liste der sicheren Absender zu aktualisieren, und nach der nächsten Edge-Synchronisierung kann „Contoso.User“ mit dem Administrator kommunizieren, ohne eine falsche Positivdiagnose auszulösen. Um diesen Vorgang zu simulieren, führen Sie das Skript „HUB-MBX-01_update_safelist.ps1“ aus.

Führen Sie nun das Skript „INTERNET01_contoso_msg.vbs“ aus, um die Nachricht von „Contoso.User“ erneut zu senden. Überprüfen Sie danach mithilfe des Befehls „Get-AgentLog“ | „Select-Object -Last 1“ das Agentprotokoll auf dem Edge-Transport-Server. Wie Sie unter „ReasonData“ sehen können, wurde jetzt die Inhaltsfilterung umgangen. Für „Contoso.User“ wird es keine falsche Positivdiagnose mehr geben!

Spamangriff

Ziehen Sie zum Abschluss der Testläufe alle Register. Wie Sie zweifellos bemerkt haben, wurde während des vorherigen Tests der Internethost als offenes Relay konfiguriert, was den Spammern Tür und Tor öffnet. Sehen Sie sich jetzt an, was geschieht, wenn „Spam.Sender@cohovineyards.com“ diese unzulängliche Konfiguration bemerkt und den Host dazu missbraucht, Tausende von Spamnachrichten an Adventure Works zu senden. Das Skript „INTERNET01_spam_msg.vbs“ sendet nur eine einzige Spamnachricht, aber Sie können das Skript bearbeiten und den max_loop-Wert ändern, damit mehr Spamnachrichten generiert werden.

Um einen Spamangriff zu simulieren, wurden dem gefährdeten Host 1.000 Nachrichten zur Weiterleitung an den Edge-Transport-Server gesendet. Da der SMTP-Dienst die Anzahl der Nachrichten pro ausgehender Verbindung auf 20 beschränkt, dauerte es einige Zeit, genügend Spamnachrichten zu übertragen, bis der Protokollanalyse-Agent auf dem Edge-Transport-Server in Aktion trat.

Der Protokollanalyse-Agent unterstützt den Verbindungsfilter-Agent, indem er basierend auf der SMTP-Protokollanalyse und auf IP-Zuverlässigkeitsupdates von Microsoft Update automatisch IP-Sperrlisteneinträge führt. In diesem Fall wurden die Spam-E-Mails von der SMTP-Protokollanalyse erfasst. Der Protokollanalyse-Agent verfolgt die SCL-Bewertung jeder Nachricht, um einen durchschnittlichen SCL-Wert zu errechnen, der dazu verwendet wird, eine Absenderzuverlässigkeitssstufe (Sender Reputation Level, SRL) zu bestimmen. Als während des simulierten Spamangriffs immer mehr illegitime Nachrichten eintrafen, erhöhte sich die SRL-Bewertung des Internethosts, bis sie schließlich die SRL-Sperrschwelle überschritt. Dies hatte zur Folge, dass der Host 24 Stunden lang in die IP-Sperrliste aufgenommen wurde. Von diesem Host wird also keine einzige Spamnachricht mehr angenommen. Dies erfolgte vollkommen automatisch. Es war kein Administratoreingriff erforderlich.

Abbildung 5 zeigt den resultierenden IP-Sperrlisteneintrag und die entsprechenden Änderungen in der Nachrichtenverarbeitung. Vor dem Blockieren des Hosts hat der Edge-Transport-Server jede Spamnachricht während des OnEndOfData-Ereignisses zurückgewiesen, weil basierend auf dem SCL-Grenzwert der Inhaltsfilter-Agent bei jeder Nachricht in Aktion getreten ist (zu Referenzzwecken siehe Abbildung 4). Die Nachricht wurde, wenn auch erfolglos, übertragen. Nach der Blockierung des Hosts wurde die Verbindung während des OnMailCommand-Ereignisses durch den Verbindungsfilter-Agent zurückgewiesen. Es werden keine Nachrichten mehr übertragen. Wenn Spammer bereits vor dem Übertragen von Nachrichten getrennt werden, führt dies zu Einsparungen bei der Netzwerkbandbreite und den Verarbeitungsressourcen.

Abbildung 5** Stoppen eines angreifenden Internethosts **(Klicken Sie zum Vergrößern auf das Bild)

Weitere Tests

Natürlich gibt es noch andere Agentfeatures und Szenarios, die getestet werden können. Sie können beispielsweise die Absenderfilterung testen, indem Sie als „Blocked.User@Contoso.com“ oder „Blocked.User@Fabrikam.com“ Nachrichten senden, oder Sie können die Empfängerfilterung testen, indem Sie Nachrichten an „Blocked.User@adventure-works.com“ senden. Sie können auch Telnet verwenden, um Verzeichnisdiebstahl-Angriffe (Directory Harvest Attack, DHA) mit verschiedenen Teergrubenintervallen zu simulieren. In der IT-Konfiguration von Microsoft wird auf dem mit dem Internet verbundenen Empfangsconnector für SMTP 5yz-Anworten ein Standardintervall von fünf Sekunden verwendet, was für die IT-Konfiguration von Microsoft genügt, um DHA-Angriffe für Spammer undurchführbar zu machen. Sie können jedoch mithilfe des Set-ReceiveConnector-Cmdlets andere Werte verwenden, was durch das Skript „EDGE01_tarpitting.ps1“ erläutert wird.

Wenn Sie noch weiter in die Materie eindringen möchten, sehen Sie sich die Snapshotdateien an, die die Pipelineablaufverfolgung für die Nachrichten von „Contoso.User@Contoso.com“ erstellt. Untersuchen Sie die Antivirusstempel „X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0“, die Forefront Security verwendet, um gescannte Nachrichten zu markieren. Wenn Forefront Security auf dem Hub-Transport-Server diesen Stempel mit neueren Versionsinformationen vorfindet, muss die betreffende Nachricht kein zweites Mal gescannt werden. Wenn Sie versuchen, Forefront Security zu täuschen, indem Sie in die Testnachrichten gefälschte Antivirusstempel einfügen, tritt die Headerfirewall in Aktion und entfernt diese Stempel unmittelbar nach dem OnDataCommand-Ereignis, also lange, bevor das OnSubmittedMessage-Ereignis ausgelöst wird, das den FSE-Routing-Agent aufruft.

Beim Betrachten der Nachrichtenheader in den Snapshotdateien kommen Sie vielleicht auf die Idee, einen SPF-Testdatensatz für Contoso.com zu erstellen, der eine falsche IP-Adresse als legitimen Absender identifiziert. Eine Möglichkeit hierfür besteht darin, die Datei „INTERNET01_wrong_SPF_record.bat“ auf dem Internethost auszuführen. Danach sollten Sie eine Testnachricht als „Contoso.User@Contoso.com“ senden und sich den „X-MS-Exchange-Organization-SenderIdResult“- und „Received-SPF“-Header ansehen:

X-MS-Exchange-Organization-SenderIdResult: SoftFail
Received-SPF: SoftFail (EDGE01.extranet.adventure-works.com: domain of transitioning
Contoso.User@Contoso.com discourages use of 192.168.1.100 as permitted sender)

Zusammenfassung

Wie Sie in diesem und im vorherigen Artikel gesehen haben, sind Exchange Server 2007-Edge-Transport-Server mit einem umfassenden Satz von Transport-Agents ausgestattet, um zuverlässige, mit hoher Präzision arbeitende Antispamfunktionen einschließlich Verbindungsfilterung, Protokollanalyse und Inhaltsfilterung zu implementieren. Die Transportarchitektur ist erweiterbar und unterstützt die Implementierung weiterer Agents, um zusätzliche Funktionalität zu erhalten. Der FSE-Routing-Agent ist ein gutes Beispiel für einen zusätzlichen Agent, der Forefront Security für Exchange Server in die Transportarchitektur integriert.

In Kombination mit zusätzlichen Features wie Verbindungsteergruben, Headerfirewalls, TLS und Authentifizierung stellen Edge-Transport-Server die erforderlichen Mittel bereit, um eine sehr hohe Stufe an Messagingschutz auf mehreren Ebenen und ohne einzelne Fehlerquellen zu erreichen. Durch den Einsatz von Edge-Transport-Servern und Forefront Security in einem Umkreisnetzwerk, das streng von der internen Exchange Server-Organisation getrennt ist, können Sie die Flut illegitimer und schädlicher Inhalte von Ihrer Messagingumgebung fernhalten und zugleich Ihren Benutzern legitime Nachrichten mit einer sehr niedrigen Rate falscher Positivdiagnosen zustellen.

Kay Unkroth ist Unternehmer und bereits seit mehr als 15 Jahren als Supporttechniker, Systementwickler, Berater, Schulungsleiter und Autor für Microsoft-Servertechnologien tätig. Außerdem ist er Gründungsmitglied und Vorsitzender der Biblioso Corporation. Dieses Unternehmen spezialisiert sich auf verwaltete Dokumentations- und Lokalisierungsdienste.

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