Sun Java ロゴ     前へ      目次      索引      次へ     

Sun ロゴ
Sun Java System Messaging Server 6 2004Q2 配備計画ガイド 

第 8 章
スパム防止およびウィルス対策の計画

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

この章には、以下の節があります。

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

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

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

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

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

これらのツールは個別に使用したり、組み合わせて使用したりできます。単独ですべてのスパムを防ぐことのできるツールはありません。しかし、組み合わせて使用することで、これらのツールはメールシステムの不正使用を防ぐ効果的な手段となります。以下の節で、これらのツールについてより詳しく説明します。

アクセス制御

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

詳細は、「アクセス制御」および『Sun Java System Messaging Server 管理ガイド』を参照してください。

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

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

詳細は、「メールボックスフィルタの使用」および『Sun Java System Messaging Server 管理ガイド』を参照してください。

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

アドレス検証

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

『Sun Java System Messaging Server 管理ガイド』で説明されているチャネルキーワード 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.org/rbl

MTA Dispatcher の ENABLE_RBL オプションを使用すると、Messaging Server SMTP サーバーで RBL を有効にできます。詳細は、『Sun Java System Messaging Server 管理ガイド』を参照してください。

リレーブロッキング

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

認証サービス

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

サイドライニング

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

詳細は、『Sun Java System Messaging Server 管理ガイド』を参照してください。

総合追跡

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

変換チャネル

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

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

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

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

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

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

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

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

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

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

注

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

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

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

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 管理ガイド』を参照してください。

Brightmail を使用する

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

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

SpamAssassin を使用する

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

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

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

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

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

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

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



前へ      目次      索引      次へ     

Copyright 2004 Sun Microsystems, Inc. All rights reserved.