• [アーティクル]

通信

マイクロソフトの Exchange エッジ トランスポート サーバー : 第 2 部

Kay Unkroth

 

概要:

  • エッジ トランスポート サーバーのログとトレースの機能を使用する
  • スクリプトを使用したスパム対策の構成
  • 一般的なスパム シナリオをテストする

この記事で使用しているコードのダウンロード: Edge2007_11.exe (161KB)

インターネット上でスパムや悪意のあるコンテンツが氾濫している現在、組織では、どのようにして信頼性と安全性を兼ね備えたメッセージング環境をユーザーに提供できるのでしょうか。その 1 つの方法は、先月、このシリーズの第 1 部で説明した方法ですが、

Exchange Server 2007 エッジ トランスポート サーバーと Forefront Security for Exchange Server をインターネットと組織の運用環境の間にある境界ネットワークに展開することです。

この 2 部シリーズの最終回となる第 2 回では、Exchange Server 2007 の標準機能であるエージェントのログ出力とトレースの機能を使用して、エッジ トランスポート エージェントの動作を分析する方法を説明します。また、独自の方法を使用して、トランスポート パイプラインのすべてのイベント オブジェクトを XML ベースのファイルにダンプする方法についても説明します。その後、マイクロソフトが自社の運用環境で採用している構成に基づいて、エッジ トランスポート サーバーのテスト ラボにスパム対策設定を適用する方法を紹介します。最後に、エッジ トランスポート エージェントが、さまざまなスパムの状況に、どのように対応するのかを示す現実的で興味深いテスト シナリオを紹介して、このシリーズを締めくくりたいと思います。

エッジ トランスポート サーバーのテスト ラボの準備とエッジ トランスポート サーバーの基本アーキテクチャに関する詳細については、2007 年 10 月号の TechNet Magazine に掲載されている、このシリーズの第 1 部の記事 (technetmagazine.com/issues/2007/10/Edge) を参照してください。**

この記事では、スクリプトとバッチ ファイルを数多く使用して、重要な構成作業のほとんどを自動化しています。これらのスクリプトは、この記事に付属しているコード ダウンロードに含まれています (technetmagazine.com/code07.aspx からダウンロードできます)。Microsoft IT で採用しているエッジ トランスポート エージェントの構成に関する詳細な背景情報については、Microsoft IT ショウケースのテクニカル ホワイト ペーパー「Microsoft® Exchange Server 2007 エッジ トランスポートとメッセージング保護」を参照することをお勧めします。この IT ショウケース ホワイト ペーパーは、microsoft.com/technet/itshowcase/content/edgetransport.mspx からダウンロードできます。

ログとトレース

Exchange Server 2007 には、プロトコルのログ出力、エージェントのログ出力、パイプライン トレースなど、さまざまなログ出力とトレースの機能が用意されています。このような機能を使用することで、トランスポート エージェントの問題の診断やトラブルシューティングを簡略化できます。この記事では、実際にトランスポート エージェントのトラブルシューティングを行うわけではありませんが、ログとトレースの情報は、エッジ トランスポート エージェントがどのように動作するのかを検証するうえで役立ちます。

SMTP の送受信に関する情報を追跡するには、送信コネクタと受信コネクタのプロトコルのログ出力を有効にする必要があります。このシリーズの第 1 部でセットアップしたテスト環境 (図 1 参照) を使用し、New-SendConnector コマンドレットと New-ReceiveConnector コマンドレットで次の設定を使用して、プロトコルのログ出力を有効にしました。

図 1 テスト環境

図 1** テスト環境 **

–ProtocolLoggingLevel: Verbose

既定では、SMTP のログ ファイルは、%ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog のサブフォルダに作成されます。

プロトコルのログ出力は、SMTP 通信を分析する場合に有益な手段ですが、スパム対策エージェントで受信するセッションが常に SMTP セッションであるとは限りません。たとえば、コンテンツ フィルタ エージェントでは、Spam Confidence Level (SCL) 値が設定された受信メッセージにしかマークを付けない可能性があります。SCL のレベルが指定のしきい値 (既定値 7) を下回っている限り、コンテンツ フィルタ エージェントにより、エッジ トランスポート プロセスで、そのメッセージが拒否されることはありません。そのため、SMTP 通信が妨げられることはありません。

トランスポート パイプラインを通過したメッセージに対するスパム対策エージェント (接続フィルタ エージェント、コンテンツ フィルタ エージェント、エッジ ルール エージェント、受信者フィルタ エージェント、送信者フィルタ エージェント、Sender ID エージェント) の動作を分析するには、プロトコル ログではなく、エージェント ログを確認する必要があります。通常、エージェントのログ出力は、EdgeTransport.exe.config ファイルの AgentLogEnabled パラメータの設定に基づいて有効になります。既定では、エージェント ログは、%ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\AgentLog フォルダにあります。ログはメモ帳で開けますが、Exchange 管理シェルで Get-AgentLog コマンドレッドを使用すると、エージェント ログの情報がわかりやすい状態で表示されます。

パイプライン トレースも便利な機能です。この機能を使用すると、メッセージがトランスポート パイプラインを通過する際に、特定の送信者からのメッセージのスナップショットをキャプチャすることができます。この概念は比較的わかりやすいものです。エッジ トランスポート プロセスでは、OnEndOfHeaders、OnEndofData、OnSubmittedMessage、および OnRoutedMessage イベントに登録されている SMTP 受信エージェントとルーティング エージェントを呼び出す前と後に、メッセージのスナップショットを作成します。メッセージのスナップショットを比較することで、各エージェントでメッセージがどのように変更されるのかを把握できます。もちろん、この有益な機能をテスト環境で有効にすることは必要不可欠です。

次の、Set-TransportServer コマンドレットは、テスト ユーザーのパイプライン トレースを有効にしています。ご想像のように、PipelineTracingEnable パラメータに $true を設定するとパイプライン トレースが有効になります。テスト ユーザーの電子メール アドレスを PipelineTracingSenderAddress パラメータに設定します。

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

パイプライン トレースを有効にすると、特定の送信者 (ここでは、Contoso.User@contoso.com) からのメッセージのメッセージ スナップショット ファイルは、%ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing\MessageSnapshots フォルダに格納されます。これは既定のフォルダです。各メッセージのスナップショット ファイルは、メッセージに割り当てられている GUID に基づいて名前が付けられたサブディレクトリに格納されます。元のメッセージは、Original.eml という名前のファイルで確認できます。メッセージのコピーは、発生したイベントとインストールされているエージェントによって異なりますが、SmtpReceive または Routing で始まる .eml ファイルで確認できます。SMTP 受信イベントの OnEndofData と OnEndOfHeaders に登録されているスパム対策エージェントの処理を分析するには、SmtpReceive*.eml という名前のファイルを確認します。ルーティング イベントの OnSubmittedMessage と OnRoutedMessage に登録されているウイルス対策ソフトや他のエージェントの処理を分析する場合は、Routing*.eml ファイルを確認します。

パイプラインのカスタム ダンプ

Exchange Server 2007 の標準機能では、すべてのトランスポート イベントに対応していませんが、Exchange Server 2007 の標準的なエージェントのログとトレースの機能では、すべてのトラブルシューティングのニーズに対応しています。たとえば、パイプライン トレースでは、送信ホストから %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing フォルダに書き込めるメッセージが転送されていない段階で発生する OnConnectEvent、OnEhloCommand、OnMailCommand、OnRcptCommand、OnDataCommand などの、トランスポート イベントに関する情報をキャプチャできません。このようなイベントの詳細な情報をキャプチャする必要がある場合は、ファイル システムのファイルにイベント データをダンプするカスタム エージェントを実装する必要があります。

前回の記事で説明したように、カスタム エージェントは簡単に作成できます。そのため、トランスポート パイプラインのすべてのイベント オブジェクトを XML ファイルにダンプする SMTP 受信エージェントとルーティング エージェントを作成しました。この記事付属のダウンロードには、これらのエージェントに相当する PipelineXMLDump という名前の Microsoft Visual Studio® 2005 プロジェクトが含まれています。このプロジェクトには 2 つの重要なファイルがあります。1 つは、エージェントのファクトリとエージェントを実装する DumpAgents.cs で、もう 1 つは、System.Reflection 名前空間のメソッドを使用してイベントのソースとイベントの引数オブジェクトのフィールドを XML ファイルに書き込むヘルパ クラスを実装する XMLDump.cs です。ソース コードをコンパイルして、生成された PipelineXMLDump.dll ファイルをエッジ トランスポート テスト サーバーの C:\PipelineXMLDump フォルダにコピーすると、RegisterPipelineXMLDump.ps1 スクリプトと EnableDumpAgents.ps1 スクリプトを使用してカスタム エージェントを登録して有効にすることができます。これらのスクリプトは、ダウンロードの PipelineXMLDump プロジェクト フォルダに収録されています。私が作成したカスタム エージェントは、説明を目的に作成したもので、十分なテストは行っていないので、運用サーバーにはインストールしないでください。これらのエージェントは、各自の責任で実行していただくことになります。

DumpAgents.cs では、トランスポート パイプラインでサポートされている、すべての SMTP 受信イベント ハンドラとルーティング イベント ハンドラを実装する方法を紹介しています。独自のカスタム エージェントを実装する必要がある場合は、このプロジェクトをベースにすると良いかもしれません。私が作成したダンプ エージェントは、%ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineXMLDump のサブフォルダに XML ファイルを書き込みます。このサブフォルダの名前は、SMTP セッションの ID (SMTP 受信エージェントの場合) またはメッセージ ID (ルーティング エージェントの場合) に対応したものになります。図 2 は、OnConnectEvent ハンドラで SMTP 受信エージェントに渡されたイベント引数の情報の例です。この例では、受信接続要求を受け付けたローカル IP エンドポイント (IP アドレスとポート) を特定することができます。

図 2 OnConnect イベントでダンプされた引数の情報

図 2** OnConnect イベントでダンプされた引数の情報 **(画像を拡大するには、ここをクリックします)

テスト実行の準備をする

ログ、トレース、ダンプについての理論の説明は十分でしょう。スパム対策エージェントの動作を見るためのテスト実行の準備を始めましょう。テスト環境で Microsoft IT の構成をできる限り忠実に再現する方法を簡単に説明します。既に紹介しましたが、背景情報については、テクニカル ホワイト ペーパー「Microsoft Exchange Server 2007 エッジ トランスポートとメッセージング保護」を参照してください。

まず、付属のダウンロードに含まれている EDGE01_disable_agents.ps1 スクリプトを実行して、受信用アドレス書き換えエージェント、添付ファイル フィルタ エージェント、および送信用アドレス書き換えエージェントを無効にします。受信者は社内と社外のどちらに対しても同じ電子メール アドレスを使用するので、アドレスの書き換えは必要ありません。Forefront Security に、添付ファイルのフィルタ機能に優先される機能があるので、添付ファイル フィルタ エージェントは使用しません。

テスト環境はインターネットに接続していません。インターネットに接続していないと、接続フィルタ エージェントのテストを行うのが難しくなりますが、この問題は、INTERNET01_create_IP_block_list.bat ファイルを実行して、インターネット ホストに IP 禁止一覧を作成することで解決できます。Windows® サポート ツールには、DNS コマンドライン ツール (dnscmd.exe) が収録されているので、このツール セットをインストールしておいてください。このツール セットをインストールしなかった場合、DNS コンソールを使用して DNS レコードを手動で作成する必要があります。

これで、EDGE01_add_block_list_provider.ps1 スクリプトを実行して、接続フィルタ エージェントを構成する準備ができました。このスクリプトでは、ip-bl.consolidatedmessenger.com の IP 禁止一覧を追加します。これは、既に説明した、INTERNET01_create_IP_block_list.bat ファイルをインターネット ホストで実行したときにテスト環境に作成されている Consolidated Messenger の IP 禁止一覧です。Microsoft IT では、ローカルの IP 禁止一覧と IP 許可一覧を使用していますが、これらの機能を使用するのに手動による構成は必要ありません。Microsoft IT では、IP 許可一覧プロバイダを使用していないことに注意してください。

次は、EDGE01_recipient_filter.ps1 スクリプトを実行して、不明な受信者へのメッセージと、社内専用または送信専用のメールボックスとグローバル配布リスト宛のメッセージをブロックするように受信者フィルタ エージェントを構成します。

送信者フィルタ エージェントの構成も変更する必要があります。Microsoft IT では、特定の送信者のアドレスからのメール フラッディング攻撃の対策として、また、業務に関係ないと思われる特定のサーバーや類似ソースからのメールをブロックする手段として送信者フィルタを使用しています。また、送信者情報が無効または存在しないメッセージをブロックする目的にも、送信者フィルタを使用しています。エッジ トランスポート サーバーで EDGE01_sender_filter.ps1 スクリプトを実行して、この構成をテスト環境に適用します。

Microsoft IT の構成を再現するには、DNS の Sender Policy Framework (SPF) レコードを構成する必要もあります。ドメインから送信されたメッセージに対してエッジ トランスポート サーバーが適切に作用することを保証する SPF レコードを生成するには、Microsoft Sender ID Framework SPF Record Wizard (Microsoft Sender ID SPF レコード ウィザード) を使用できます。このウィザードは、microsoft.com/mscorp/safety/content/technologies/senderid/wizard からダウンロードしてご利用いただけます。既存のインターネット ドメイン名を指定して、使ってみてください。テスト環境では、ウィザードを使用する代わりにインターネット ホストで INTERNET01_create_SPF_record.bat ファイルを実行します。

これで準備完了です。多くのエージェントの既定の設定は、適切に構成されているので、これ以外に構成しなければならないパラメータはありません。エッジ トランスポート サーバーで EDGE01_check_defaults.ps1 スクリプトを実行して、エッジ ルール エージェント、Sender ID エージェント、プロトコル分析エージェント、およびコンテンツ フィルタ エージェントで最も重要な既定の設定を簡単に確認します。

エッジ トランスポート エージェントの動作

では、エッジ トランスポート エージェントを、いくつかの現実的なメッセージング シナリオで動作させてみましょう。エッジ トランスポート サーバーにテスト メッセージを送信する際には、Windows Server 2003 に同梱されている SMTP サービスと POP3 サービスを使用し、メッセージング クライアントには Outlook® Express を使用しました。多くの場合、既定の設定を使用しましたが、ログ出力は有効にしました。

ただし、注意事項が 1 点あります。テスト環境が運用システムやインターネットと接続されている場合、このセクションで説明する手順やスクリプトは実行しないでください。テストは各自の責任で実行していただくことになります。

最初にテストするのは、接続フィルタ エージェントです。このエージェントは、エッジ トランスポート サーバーで最も負荷の高いエージェントなので最初にテストするエージェントとして適任です。マイクロソフトでは、接続フィルタ エージェントにより、送信されてきたインターネット メッセージの約 88% がブロックされています。通常の 1 営業日に送られてくる 1,300 万件のメッセージのうち、正当な送信者からのメッセージはたった 150 万件です。

では、Fabrikam.User@Fabrikam.com から Administrator@adventure-works.com 宛てに電子メール メッセージを送信してみましょう。テスト ラボが適切に構成されていれば、このメッセージは Administrator に届きません。そして、Fabrikam.User は、受信者にメッセージを配信できなかったことを知らせる配信状態通知 （DSN） メッセージを受信します。Fabrikam.User は、電子メール アドレスが間違っていないことを確認し、再度メッセージを送信しても、また DSN を受信します。Fabrikam.User は、この問題をヘルプ デスクに報告しました。この問題は他のユーザーから既に報告済みでした。Fabrikam のすべてのユーザーが Adventure Works に電子メールを送信できないという状況が発生していました。何かが起こっているようです。この問題は急を要します。この問題を迅速に解決するために、INTERNET01 の %systemroot%\system32\Logfiles\SMTPSVC1 フォルダにある SMTP ログを確認すると、図 3 で赤色の文字で示されているように問題の原因がわかりました。

Figure 3 問題を示している SMTP ログ

... 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,

エラー応答 550 によると、Consolidated Messenger が、Fabrikam のインターネット ホストの IP アドレスを IP 禁止一覧に登録しているようです。まあ、仕方がないでしょう。Consolidated Messenger に連絡をして、IP 禁止一覧からアドレスを削除してもらうように依頼をしました。実は、Consolidated Messenger にとっては、IP アドレスを禁止一覧から削除する作業よりも、禁止一覧に追加する作業の方が簡単です。この禁止一覧を整理するのに、何週間もかかることはありませんが、数日はかかります。

数日も待てないので、電子メール アドレス cmipbl@adventure-works.com にメッセージを送って、Adventure Works に連絡をしました。Fabrikam.Admin@Fabrikam.com から電子メール メッセージを送信し、状況を説明して、Fabrikam のホスト インターネット IP アドレス (この場合は、192.168.1.100) を禁止一覧から外してもらうように依頼しました。Fabrikam.Admin の身元を確認した後、Adventure Works では、次のコマンドを使用して、30 日後に有効期限が切れるという一時的な例外を適用することで、この IP アドレスのブロックを解除しました。

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

30 日あれば、Consolidated Messenger との問題を解決するのには十分な時間を確保できますし、Adventure Works で、この例外を手動で管理するのに時間を割く必要もありません。自動的に有効期限が切れる例外を適用することで、Adventure Works では、IP 許可一覧をメンテナンスに伴う管理オーバーヘッドを最小限に抑えています。

安全な送信者

次は、コンテンツ フィルタ エージェントの安全な送信者を識別する機能をテストしましょう。これは、スパム フィルタ処理の精度を高める興味深い新機能です。EdgeSync では、社内環境で安全な送信者の情報を取得し、ハッシュおよび暗号化された形式でエッジ トランスポート サーバーに伝達します。コンテンツ フィルタ エージェントでは、フィルタ処理で、この情報を使用して詳細な情報に基づいた判断を下しています。必要な作業は、Update-SafeList コマンドレットを使用して、安全な送信者の情報 (差出人セーフ リスト、宛先セーフ リスト受信拒否リスト、および外部の連絡先) を Active Directory® に伝達してから、Start-EdgeSynchronization コマンドレットを使用して、この情報をエッジ トランスポート サーバーに複製するだけです。Microsoft IT では、オフピーク時に Update-SafeList コマンドレットを定期的に実行しています。テスト環境では、対応するスクリプト (HUB-MBX-01_update_safelist.ps1) を手動で実行すれば十分です。

エッジ トランスポート サーバーで EDGE01_clean_up.ps1 スクリプトを実行し、以前に作成した IP 許可一覧のエントリを削除して、テスト環境を初期状態に戻します。コンテンツ フィルタ エージェントでは、この許可一覧に登録されているソースからのメッセージは制御しないため、このスクリプトの実行が必要になります。次に、インターネット ホストで INTERNET01_clean_up.bat ファイルを実行して、Consolidated Messenger の禁止一覧から 100.1.168.192.ip-bl.consolidatedmessenger.com の IP 禁止一覧エントリを削除します。既に説明したように、このファイルを実行しないと、シミュレーション用のインターネット ホストでメッセージを送信することができません。

最後に、コンテンツ フィルタ エージェントで、確実にスパムと認識されるようなメッセージを送信します。コンテンツ フィルタ エージェントでは、誤検知を最小限に抑えるために、SCL による拒否のしきい値の既定値を使用してユーザーに大半のメッセージを配信しているので、厄介な部分です。何度かテスト メッセージを送信したところで、SCL のレベルを上げるメッセージの種類があることを発見しました。インターネット ホストで INTERNET01_contoso_msg.vbs スクリプトを実行して、Contoso.User@Contoso.com からメッセージを送信します。

このスクリプトでは、匿名 SMTP 接続を使用して、INTERNET01 の SMTP サービスにメッセージを送信しています。このスクリプトが動作するには、匿名ユーザーのメッセージを中継するように SMTP サービスを構成する必要があります。IIS マネージャで、既定の SMTP 仮想サーバーのプロパティを開きます。[アクセス] タブで、[中継] ボタンをクリックし、[以下のリストに含まれるコンピュータ以外のすべて] をクリックします。この設定の影響については、この後で説明します。

このメッセージを送信するスクリプトを実行すると、Contoso.User は、Diagnostic-Code: smtp;550 5.7.1 Message rejected due to content restrictions というエラーで配信に失敗したことを示す DNS を受信します。この応答は、インターネット ホストの SMTP ログでも確認できます。エッジ トランスポート サーバーで、Get-AgentLog | Select-Object -Last 1 コマンドを実行して、エージェント ログの最後のエントリを表示すると、図 4 に示すように SCL のレベルが 7 であることが原因でメッセージが拒否されたことを確認できます。

図 4 コンテンツの制限によりブロックされたメッセージ

図 4** コンテンツの制限によりブロックされたメッセージ **(画像を拡大するには、ここをクリックします)

しかし、Contoso.User はスパムの送信者ではありません。Contoso.User が送信したメッセージがブロックされてしまったのは残念なことですが、通常は、Adventure Works の受信者と通信できます。そこで、Contoso.User は、Administrator に、もう 1 通電子メールを送信して、メッセージが誤ってブロックされていることを報告しました。Administrator は Contoso.User の身元を把握しているので、今後、彼女が送信したメッセージがスパム フィルタでブロックされることがないように、Contoso.User を送信者セーフ リストに追加しました。Office Outlook 2007 で、Contoso.User を送信者セーフ リストに追加するには、彼女からのメッセージを右クリックし、[迷惑メール] をポイントして、[送信者を [差出人セーフ リスト] に追加] をクリックします。

指定の間隔で Update-SafeList コマンドレットが実行され、Active Directory のセーフ リスト情報が更新されます。次のエッジ同期が行われた後、Contoso.User は、送信したメッセージが誤検知されることなく、Administrator と連絡を取ることができるようになります。HUB-MBX-01_update_safelist.ps1 スクリプトを実行して、この手順のシミュレーションを行います。

INTERNET01_contoso_msg.vbs スクリプトを実行して、Contoso.User のメッセージを再度送信します。スクリプトの実行後に、Get-AgentLog | Select-Object -Last 1 コマンドを使用してエッジ トランスポート サーバーのエージェント ログを確認します。ログの ReasonData には、コンテンツのフィルタ処理が省略されるようになったことが記録されています。これで Contoso.User は誤検知に悩まされることがなくなりました。

スパム攻撃

テスト実行の最後に、極端なシナリオを試してみましょう。お気付きだと思いますが、前のテストでは、第三者中継を許可するようにインターネット ホストを構成しました。この構成では、スパムの送信者に門戸を開放していることになります。Spam.Sender@cohovineyards.com が、この脆弱な構成に目を付け、Adventure Works に何千通ものスパム メッセージを送信してホストに負荷をかけたらどうなるでしょうか。INTERNET01_spam_msg.vbs スクリプトではスパム メッセージを 1 通しか送信しませんが、スクリプトを編集し、max_loop の値を変更して、多くのスパム メッセージを生成するようにすることができます。

スパム攻撃のシミュレーションを行うため、エッジ トランスポート サーバーに中継する必要がある 1,000 通のメッセージを脆弱な構成のホストに送信しました。SMTP サービスでは、1 つの送信接続で送信するメッセージが 20 通に制限されています。そのため、エッジ トランスポート サーバーのプロトコル分析エージェントが、十分なメッセージを受信して作動するまでには、多少時間がかかりました。

プロトコル分析エージェントは、SMTP プロトコルの分析結果と Microsoft Update から提供される IP 評価の更新情報に基づいて、自動的に IP 拒否一覧のエントリを管理することで、接続フィルタ エージェントをサポートしています。この場合は、SMTP プロトコル分析により、スパム メッセージが検出されました。プロトコル分析エージェントでは、各メッセージの SCL のレベルを追跡して、送信者評価レベル (SRL) を特定する際に使用する SCL の平均値を割り出しています。スパム メッセージを大量に送信するシミュレーションで多くの正当でないメッセージを受信するうちに、インターネット ホストの SRL のレベルは上がり、SRL による禁止のしきい値を超えました。最終的に、インターネット ホストでは、24 時間にわたって IP 禁止一覧にエントリを追加し続けました。これで、このホストは、スパム メッセージから解放されるでしょう。この処理は自動的に行われるので、管理者による作業は必要ありませんでした。

図 5 は、このシミュレーションにより作成された IP 禁止一覧のエントリと、それによってメッセージの処理がどのように変更されるのかを示しています。ホストでブロックする以前は、SCL によるしきい値 (図 4 参照) に基づいてコンテンツ フィルタ エージェントが各メッセージを制御していたので、エッジ トランスポート サーバーでは、OnEndOfData イベントでスパム メッセージを拒否していました。メッセージは、配信されませんでしたが、送信されていました。ホストでブロックするようになった後、接続は、接続フィルタ エージェントにより OnMailCommand イベントで拒否されるようになりました。メッセージは送信することができなくなるので、メッセージを送信する前に、スパム送信者を切断するためのネットワーク帯域幅と処理リソースを節約できます。

図 5 悪質なインターネット ホストに対する対策

図 5** 悪質なインターネット ホストに対する対策 **(画像を拡大するには、ここをクリックします)

追加のテスト

これまでに紹介したもの以外にもテストできるエージェントの機能やシナリオはあります。たとえば、Blocked.User@Contoso.com または Blocked.User@Fabrikam.com からメッセージを送信して、送信者のフィルタをテストできます。また、Blocked.User@adventure-works.com にメッセージを送信して、受信者のフィルタをテストできます。Telnet を使用して、さまざまなタールピット間隔でディレクトリ ハーベスト攻撃のシミュレーションを行うこともできます。Microsoft IT では、インターネットに接続している受信コネクタで SMTP 5yz 応答に既定の間隔 5 秒を使用していますが、これはスパムの送信者がディレクトリ ハーベスト攻撃を仕掛けられないようにするのに十分な時間です。ただし、EDGE01_tarpitting.ps1 スクリプトで示しているように、Set-ReceiveConnector コマンドレットを使用して他の値を適用することは可能です。

さらに掘り下げて、Contoso.User@Contoso.com から送信されたメッセージについてパイプライン トレースで作成されたスナップショット ファイルを確認することもできます。Forefront Security がスキャン済みのメッセージとしてマークする際に使用するウイルス対策ソフトのスタンプ X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 を確認してみましょう。ハブ トランスポート サーバーの Forefront Security で、最近のバージョン情報を持つスタンプが検出された場合、Forefront Security では、メッセージを再度スキャンする必要はありません。テスト メッセージに偽のウイルス対策ソフトのスタンプを挿入して Forefront Security をごまかそうとしても、ヘッダー ファイアウォールが動作しているので、このようなスタンプは、FSE ルーティング エージェントを起動する OnSubmittedMessage イベントがトリガされる前に発生する OnDataCommand イベントの直後に削除されます。

スナップショット ファイルのメッセージ ヘッダーを参照する際には、正当な送信者として適切ではない IP アドレスを認識する Contoso.com の SPF テスト レコードを作成することをお勧めします。このようなレコードは、インターネット ホストで INTERNET01_wrong_SPF_record.bat ファイルを実行して作成できます。バッチ ファイルを実行したら、Contoso.User@Contoso.com からテスト メッセージを送信して、X-MS-Exchange-Organization-SenderIdResult と Received-SPF ヘッダーを確認します。

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)

まとめ

この記事と前回の記事で説明したように、Exchange Server 2007 エッジ トランスポート サーバーには、接続フィルタ、プロトコルの分析、コンテンツ フィルタなど、信頼性と精度の高いスパム対策機能を実装するための包括的な一連のトランスポート エージェントが用意されています。トランスポート アーキテクチャは、拡張可能で、追加機能を実現するのために他のエージェントを実装することができます。FSE ルーティング エージェントは、トランスポート アーキテクチャで Forefront Security for Exchange Server と統合できる追加のエージェントの一例です。

エッジ トランスポート サーバーでは、接続のタールピット、ヘッダー ファイアウォール、TLS、認証などの追加機能と併用することで、単一障害点がなく、複数のレベルで高水準のメッセージング保護を実現するのに必要な手段を提供します。社内の Exchange Server 環境から完全に分離された境界ネットワークにエッジ トランスポート サーバーと Forefront Security を展開することで、大量に送信されてくる、正当でない、悪意のあるコンテンツをメッセージング環境から排除しながら、誤検知を最小限に抑えて、従業員に正当なメッセージを配信することができるようになります。

Kay Unkroth は、15 年間、マイクロソフトのサーバー テクノロジを専門とするサポート エンジニア、システム開発者、コンサルタント、トレーナー、著者としての職歴を持つ企業家です。また、ドキュメント管理とローカライズ サービスの専門企業 Biblioso Corporation の共同創立者であり、会長でもあります。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.