test

Sun Java Communications Suite 5 配備計画ガイド

第 14 章 Messaging Server スパム防止およびウイルス対策の計画

Messaging Server は、一方的に送られてくる大量電子メール (UBE、または「スパム」) とウイルスに対処するためのツールを数多く提供しています。この章では、利用可能なさまざまなツールと対策について説明します。

この章の内容は次のとおりです。

スパム防止およびウイルス対策ツールの概要

インターネットに接続されるコンピュータの数が増加し、オンラインでのビジネスが容易となるにつれて、スパムやウイルスなどのセキュリティーに関する問題の数も増え続けています。そのため、これらの問題に対処するための Messaging Server 配備を計画する必要があります。

Messaging Server を経由して送受信されるメールトラフィックは、さまざまな基準に基づいて異なるチャネル別に分類できます。この基準には、発信元および送信先電子メールアドレスや発信元 IP アドレスまたはサブネットが含まれます。これらのさまざまな電子メールフローやチャネルに異なる処理特性を適用できます。その結果、これらのチャネル上で、さまざまなアクセス制御、メールフィルタ、処理の優先順位、およびツールをさまざまな方法と組み合わせで使用できます。たとえば、ドメイン内から発信されたメールを配備の外部から発信されたメールと区別して処理できます。

チャネルベースのメッセージフロー以外の便利な分類方法として、メーリングリストトラフィックがあります。Messaging Server に送信されてくる特定のメーリングリストのトラフィックは、数多くのチャネルを経由して受信し、また数多くの異なるチャネルに分けて送信できます。メーリングリストを使用すると、チャネルではなく、リスト自体を基準に考えるのが有用であることがわかります。Messaging Server はこの分類を認識し、数多くのチャネル固有のスパム対策ツールをメーリングリスト固有の方法で適用できます。

Messaging Server で使用できるスパム防止およびウイルス対策ツールの概要を次で説明します。

これらのツールは個別に使用したり、組み合わせて使用したりできます。単独ですべてのスパムを防ぐことのできるツールはありません。しかし、組み合わせて使用することで、これらのツールはメールシステムの不正使用を防ぐ効果的な手段となります。次の節で、これらのツールについてより詳しく説明します。詳細については、『Sun Java System Messaging Server 6.3 管理ガイド』を参照してください。

メールの拒否

Messaging Server には、さまざまな検証基準に従ってメールを拒否できる汎用の機能が備わっています。この基準には、メッセージの発信元および送信先電子メールアドレスや発信元 IP アドレスが含まれます。たとえば、このメカニズムを使用して、特定の発信者やドメイン全体 (たとえば spam@public.com というドメイン全体) からのメールを拒否できます。スクリーニング情報のために大量のリストが必要な場合は、アクセス基準を格納したデータベースでリストを拡張することもできます。UBE 関連以外でも、これと同じアクセス制御のメカニズムは、特定のチャネルからのメール送信を許可または禁止された内部ユーザーのデータベースを管理するのに適しています。たとえば、インターネットメールの送受信を許可するか禁止するかを、ユーザー別に制限できます。

詳細については、「アクセス制御」を参照してください。

メールボックスフィルタリング

Messaging Server には、ユーザー別、チャネル別、およびシステム全体で使用できるメールフィルタがあります。ユーザー別チャネルは、Messenger Express のどの Web ブラウザからでも管理が可能です。これらのフィルタを使用して、ユーザーは自分のメールボックスに配信されるメールを制御できます。たとえば、「簡単に儲かる」式の UBE をユーザーが受け取りたくない場合、そのような件名のメールを拒否するよう指定できます。Messaging Server のメールフィルタリング機能は、Internet Engineering Task Force (IETF) により開発された Sieve フィルタリング言語 (RFC 3028 および 3685) に基づいています。

詳細については、「メールボックスフィルタの使用」を参照してください。

Brightmail や SpamAssassin のようなサードパーティーのコンテンツフィルタリングソフトウェアを使用して、コンテンツベースのフィルタリングやウイルススキャニングを実装することも可能です。詳細については、「スパム防止およびウイルス対策の考察」を参照してください。

アドレス検証

UBE メッセージは、しばしば不正発信者のアドレスを使用します。Messaging Server SMTP サーバーは、メッセージを不正な発信者のアドレスと照合させることで、これを利用できます。発信者のアドレスが DNS サーバーに対するクエリーにより有効なホスト名に対応していないと判断された場合、そのメッセージは拒否できます。ただし、DNS をこのように使用する場合は、パフォーマンスが低下する可能性があります。

『Sun Java System Messaging Server 6.3 管理ガイド』で説明されているチャネルキーワー ド mailfromdnsverify を使用して、チャネル別ベースのアドレス検証を有効にします。

Real-time Blackhole List

Mail Abuse Protection System の Real-time Blackhole List (MAPS RBL) は、発信元 IP アドレスによって識別された既知の UBE 発信元のリストを動的に更新します。Messaging Server SMTP サーバーは MAPS RBL をサポートしており、MAPS RBL が UBE の発信元として認識した IP アドレスからのメッセージ受信を拒否できます。MAPS RBL は、インターネット DNS を使用した無料サービスです。

詳細については、以下を参照してください。

http://mail-abuse.com

MTA Dispatcher の ENABLE_RBL オプションを使用すると、Messaging Server SMTP サーバーで RBL を有効にできます。

リレーブロッキング

総合的な UBE 対策としては、アクセス制御、メールボックスフィルタリング、アドレス検証、RBL を使用して UBE を受け取らないようにする対策と、システムが不正に利用されてメールをほかのシステムにリレーしてしまうことを防ぐ対策が必要です。後者は、リレーブロッキングと呼ばれます。リレーブロッキングの最も単純な方法は、非ローカルシステムからのリレーを拒否しながら、ローカルユーザーとシステムにはメールのリレーを許可することです。IP アドレスを選別の基準として使用すると、ローカルと非ローカルを簡単かつ安全に判断できます。デフォルトでは、Messaging Server はインストール時にリレーブロッキングを行うように設定されます。詳細については、「マッピングテーブルによるリレー防止設定」を参照してください。

認証サービス

Messaging Server の SMTP サーバーには Simple Authentication and Security Layer (SASL、RFC2222) が実装されています。SASL は POP クライアントと IMAP クライアントで使用することができ、SMTP サーバーへのパスワードベースのアクセスを提供しています。SASL の一般的な使用方法は、認証を受けた外部ユーザーにメールのリレーを許可することです。これにより、自宅からまたは出張中に ISP を使用するローカルユーザーに共通の問題が解決されます。そのようなユーザーは、メールシステムに接続するときに、ローカルとは異なる IP アドレスを使用します。発信元 IP アドレスのみを考慮するリレーブロックでは、これらのユーザーのメールはリレーされません。この問題は、SASL を使用してこれらのユーザーの認証を可能にすることで解決できます。一度認証を受けたユーザーは、メールのリレーが許可されます。

メッセージのサイドライニング

前述したアクセス制御のメカニズムでは、疑わしいメッセージの処理を保留しておき、あとで手動で検査することもできます。あるいは保留する代わりに、送信先アドレスを変更して疑わしいメールを特定のメールボックスに配信したり、警告なしで削除したりすることもできます。この対策は、UBE が既知の固定された発信元から送られてきたものである場合に有効で、これを完全に受信拒否してしまうと、悪用者が発信元を変更してしまうだけの結果となってしまいます。Messaging Server のメーリングリストでも同様の機能を使用できます。警告なしでメールを削除する場合には、正当な送信者が影響を受けないよう慎重に行う必要があります。

総合追跡

Messaging Server の SMTP サーバーは、すべての受信メールメッセージに関する重要な発信元情報を検出し、記録します。この情報には、発信元 IP アドレスとそれに対応するホスト名が含まれます。検出されたすべての情報は、設定によりログファイルとともにメッセージの追跡フィールド (たとえば、Received: ヘッダー行) に記録されます。そのような信頼性の高い情報を利用できることは、ヘッダーが詐称されることの多い UBE の発信元を突き止めるのに重要なことです。各サイトでは任意のレポートツールを使用して、プレーンテキストで保存されているこの情報にアクセスできます。

変換チャネル

変換チャネルは非常に汎用的な目的で使われるインタフェースです。チャネル上でスクリプトやプログラムを呼び出して、電子メールメッセージの本文を任意に処理できます。変換プログラムは、それぞれの MIME のメッセージ全体ではなく本文をプログラムまたはスクリプトに渡し、その本文をプログラムまたはスクリプトの出力に置き換えます。変換チャネルは、テキスト形式から PostScript 形式へというようにファイル形式を変換したり、ある言語を別の言語に変換したり、会社の機密情報のためにコンテンツフィルタリングを実行したり、ウイルスを検索したり、メッセージを別のものに置き換えたりするのに使用できます。

サードパーティー製品との統合

Messaging Server の変換チャネルを使用すると、サードパーティーの供給元が提供するコンテンツフィルタリングソフトウェアを配備に統合できます。チャネルキーワードは、Brightmail または SpamAssassin のようなスパム防止およびウイルス対策製品を使用したメールフィルタリングを行うのに使用されます。MTA を設定して、すべてのメッセージまたは特定のチャネルを経由するメッセージのフィルタリングを行なったり、ユーザー別のレベルでフィルタの精度を設定したりできます。スパム防止とウイルス対策のいずれか、または両方の使用を選択できます。SpamAssassin はスパムのフィルタリングのみを行います。

Sieve の広範囲なサポートにより、スパムやウイルスであると判定されたメッセージの処理設定に大きな柔軟性を持たせることが可能となりました。ウイルスとスパムの削除をデフォルトの動作とするか、スパムを特定のフォルダに集めることができます。ただし、Sieve を使用する場合は、メッセージのコピーを特別なアカウントに転送するか、カスタムヘッダーを追加するか、spamtest Sieve 拡張を使用して、SpamAssassin から返されるレイティングに基づいて異なる動作を行うことができます。

Milter

Milter は、Sendmail Content Management API と、この API を使用して作成されたソフトウェアのことです。Milter はサードパーティー製ソフトウェアに対するプラグインインタフェースを提供します。このインタフェースは、MTA を通過するメッセージを検証、修正、またはブロックするためのものです。Sendmail の Milter は、Sendmail 自体のサポートコードと、別個の Milter ライブラリで構成されます。フィルタの作成者は、作成したフィルタをこのライブラリにリンクすることで、サーバーを生成します。次に、これらの Milter サーバーに接続するように Sendmail が設定されます。Messaging Server では、Milter インタフェースの Sendmail 側をエミュレートするライブラリを提供しています。したがって、Sendmail 用に作成された Milter も Messaging Server とともに使用できます。Milter サーバーは、さまざまな設定で動作します。別個の専用のシステムで動作することも、Messaging Server と同じシステムで動作することもできるほか、単体システム配備にも 2 層配備にもすることができます。Messaging Server は、複数の Milter サーバーへの接続もサポートしています。

スパム防止およびウイルス対策の考察

この節では、スパム防止またはウイルス対策の技術を使用した配備を計画する場合の留意事項について説明します。

スパム防止およびウイルス対策を配備する場合のアーキテクチャー上の問題

Messaging Server MTA は、Brightmail や SpamAssassin のようなメールフィルタリングシステムと同じシステムでも、別のシステムでも使用することができます。MTA をメールフィルタリングサーバーから分離することのメリットは、ハードウェアを追加してサーバーのクローンを使用すれば、簡単にフィルタリングの処理能力を上げられることです。システムの能力に余裕があり、過負荷状態になっていない場合は、メールフィルタリングサーバーソフトウェアを MTA と同じサーバーに置くことができます。

一般には、MTA がメールのフィルタリングに使用する Brightmail サーバーの「ファーム」を配備することを検討します。MTA が Brightmail サーバー名のリストを使用するように設定すると、MTA の負荷を分散できます。このロードバランス機能は、Brightmail SDK により可能になります。Brightmail サーバーのファームを導入するメリットは、より多くの処理パワーが必要な場合に、Brightmail サーバーを追加するだけで対応できることです。

メールフィルタリング製品は、一般に高い CPU 占有率を要求します。MTA とメールフィルタリング製品をそれぞれ専用のマシンに分けるアーキテクチャーを構築することで、メッセージング配備の全体的なパフォーマンスを向上させることができます。

注 –

メールフィルタリングサーバーの CPU 占有率が高い傾向にあるため、フィルタリングの対象となる MTA ホスト以上の数のメールフィルタリングシステムを使用するアーキテクチャーに行き着く場合もあります。

大規模な配備では、それぞれのインバウンドメールとアウトバウンドメールの MTA プールに対応する、サーバーのインバウンドおよびアウトバウンドフィルタリングプールを構築することも検討します。また、「スイング」プールを構築して、必要とされる状況に応じてインバウンド、アウトバウンドのいずれかのプールとして機能させることもできます。

そのほかの配備全般と同様に、メールフィルタリング層を常時監視する必要があります。経験上、CPU 占有率 50% をしきい値とするのが良い指針です。このしきい値に達したら、メールフィルタリング層の能力増強を検討する必要があります。

スパム防止およびウイルス対策を配備する場合のセキュリティー上の問題

スパム防止やウイルス対策技術の配備を計画する場合は、誤った配備によってセキュリティー対策が損なわれる可能性があることに注意してください。図 14–1 は、スパム防止/ウイルス対策のフィルタソリューションの誤った配備を示しています。

図 14–1 スパム防止/ウイルス対策ソリューションの誤った配備

この図は、スパム防止/ウイルス対策ソリューションの誤った配備を示します。

図 14–2 は、スパム防止/ウイルス対策のフィルタソリューションの正しい配備を示しています。

図 14–2 スパム防止/ウイルス対策ソリューションの正しい配備

この図は、スパム防止/ウイルス対策ソリューションの正しい配備を示します。

MTA は、次の機能を含め、特定の機能を正常に実行します。

スパム防止/ウイルス対策フィルタは、電子メールがスパムかどうか、またはウイルスを含んでいるかどうかを調べる点では有用ですが、通常は、優れた MTA に期待されるような処理能力はありません。したがって、そのような処理の実行はスパム防止/ウイルス対策フィルタに依存しないでください。スパム防止/ウイルス対策フィルタを MTA と適切に統合する方がより「正しい」配備であり、Messaging Server はこれに該当します。Messaging Server のスパムフィルタプラグインサポートは、早期にメッセージを拒否するために、可能性のあるあらゆる理由を提供し、すべての理由を同時に適用します。

Messaging Server の MTA など、堅牢な MTA には SSL/TLS、IP アドレスによるトラフィック分割、サービス拒否攻撃を低減するための早期でのアドレス拒否、IP アドレス/ドメインによる接続抑制などのセキュリティー機能が備わっていますが、フロントにスパム防止/ウイルス対策フィルタを配備するとこれらのセキュリティー機能が損なわれます。さらに、SMTP プロトコルを使用して通信するスパム防止/ウイルス対策フィルタは、SMTP の堅牢性要件に従っていない場合が多いため、重要な電子メールが失われてしまうことがあります。正しい配備には、スパム防止/ウイルス対策フィルタと堅牢な MTA を併用するようにしてください。

RBL の実装

一般的には、RBL を実装するとすぐにスパムを減らすことができます。MTA によって RBL が実装されれば、スパムを少なくとも 10% 以上、すぐに減らすことができます。この数字が 50% にまで達する場合もあります。

RML と Brightmail とは併用できます。Brightmail が一定の時間内に特定の IP アドレスの電子メール 100 件のうち 95 件を処理した場合、その IP アドレスを RBL に追加する必要があります。Brightmail の分析を行う際、Brightmail のメール判定基準のために RBL を調整できます。この調整により、RBL はスパムが集中する場合の処理に十分に備えられます。

スパム防止およびウイルス対策配備の一般的なシナリオ

この節では、Brightmail および SpamAssassin の一般的な配備例について説明します。詳細については、『Sun Java System Messaging Server 6.3 管理ガイド』を参照してください。

Symantec Brightmail の使用

Symantec Brightmail には、次の一般的な配備シナリオがあります。

Brightmail がスパムとウイルスの両方のチェックを実行する場合、MTA のメッセージスループットは 50% ほど低下する可能性があります。MTA のスループットを維持するには、各 MTA につき 2 台の Brightmail サーバーが必要です。

SpamAssassin の使用

Messaging Server では、SpamAssassin の使用がサポートされています。SpamAssassin はフリーウェアのメールフィルタで、スパムの特定に使用されます。SpamAssassin は Perl で記述されたライブラリ、アプリケーションのセット、および SpamAssassin のメッセージングシステムへの統合に使用するユーティリティーで構成されています。

SpamAssassin では、すべてのメッセージのスコアが計算されます。スコアは、メッセージヘッダーや本文の情報に対して一連のテストを実行することによって計算されます。各テストに成功するか失敗するかによってスコアは調整されます。スコアは正または負の実数です。スコアが一定のしきい値 (通常 5.0) を超えると、スパムであるとみなされます。

SpamAssassin には高い設定性があります。テストはいつでも追加したり削除したりでき、既存テストのスコアは調整できます。これらはすべてさまざまな設定ファイルを通じて実行されます。SpamAssassin の詳細については、SpamAssassin の Web サイトを参照してください。

http://www.spamassassin.org

Brightmail のスパムおよびウイルススキャンライブラリに接続する場合と同じ方法で SpamAssassin spamd サーバーに接続できます。

Symantec AntiVirus Scan Engine (SAVSE) の使用

Messaging Server は SAVSE の使用をサポートします。SAVSE は、TCP/IP サーバーアプリケーションおよび通信用の API であり、高性能なウイルススキャニングを提供します。SAVSE は、ネットワークインフラストラクチャーデバイス経由で送受信されるトラフィックやそれらのデバイス上に格納されているトラフィックを保護するように設計されています。

スパム防止およびウイルス対策のためのサイトポリシーの開発

スパムとスパムのリレーを防止するためのポリシーを開発する場合には、スパムの防止機能と電子メールがサイトにタイムリーに配信されることのバランスを取る必要があります。したがってベストのポリシーは、処理時間があまり長くない判定基準をコアとして最初に配置して、スパムの大半を捕捉することです。最終アーキテクチャーでストレステストを行なったあとに、この判定基準のコアセットを定義できます。最初の判定基準は次の内容で始めます。システムを配備したら、捕捉されたスパムと捕捉されなかったスパムを分析してシステムの微調整を行い、必要に応じて機能を入れ替えたり、新機能を追加したりします。

サイトのスパム防止およびウイルス対策ポリシーの開始点として、次の判定基準を使用します。