test

Sun Java System Communications Services 6 2005Q4 配備計画ガイド

配備におけるメッセージングコンポーネントの保護

この節では、メッセージング配備でコンポーネントをセキュリティーで保護する方法について説明します。

注 –

それぞれのコンポーネントで、chroot 機能を使用して、各マシンで使用できるコマンドの数を制限します。

MTA の保護

MTA をセキュリティーで保護し、処理リソースやサーバー可用性を保護します。権限を持たないユーザーからメッセージがリレーされた場合、または大量のスパムが配信された場合には、応答速度が遅くなり、ディスク容量が圧迫され、エンドユーザーのための処理リソースが消費されます。スパムはサーバーのリソースを浪費するだけでなく、エンドユーザーを煩わせるものでもあります。

注 –

権限を持たない外部のユーザーから配備を保護するだけでなく、内部ユーザーからシステムを保護する必要もあります。

次の表で、MTA に対する最も一般的な脅威について説明します。

表 13–1 MTA に対する一般的なセキュリティー脅威

脅威 

説明 

UBE (Unsolicited Bulk Email) またはスパム 

多数のユーザーに迷惑メールを送りつける行為のことを言います。

不正なリレー

別の会社の SMTP サーバーを使用してメールをリレーします。スパムの送信者は、証拠を残さないようにするためにこのテクニックを多用します。エンドユーザーは、スパム送信者ではなく、送信したリレーにクレームをつけていることもあります。 

メール爆弾 

同じメッセージを特定のアドレスに繰り返し送るような行為。大量のメッセージにより、メールボックスの容量を超過させるのが狙いです。 

電子メールスプーフィング

別の発信元からの電子メールを、ある発信元からのものにみせかけます。 

サービス拒否攻撃

あるサービスの正規ユーザーがそのサービスを利用できないようにします。たとえば、攻撃者がネットワークを占有し、正規のユーザーのトラフィックを妨害します。 

MTA リレーに関するこの節では、配備で使用できるセキュリティーオプションについて説明します。

アクセス制御

アクセス制御を使用して、特定のユーザーから (へ) のメッセージをシステムレベルで拒否できます。また、特定のユーザー間でより複雑なメッセージトラフィックの制限を構成することもできます。さらに、ユーザーに独自の受信メッセージのフィルタ設定を許可し、メッセージヘッダの内容に基づいてメッセージを拒否することなどができます。

エンベロープレベルでアクセス制御を行うときは、マッピングテーブルを使用してメールのフィルタリングを行います。ヘッダベースでアクセス制御を行う場合、またはユーザー独自の制御を行う場合は、サーバー側の規則とともに一般的なメールボックスフィルタを使用します。

マッピングテーブルの概要

特定の「マッピングテーブル」を設定することにより、メールサービスへのアクセスを制御できます。MTA の多くのコンポーネントでは、テーブル検索指向の情報を利用しています。この種類のテーブルは、変換、すなわち入力文字列を出力文字列へ「マップ」するのに使用されます。マッピングテーブルは通常、2 つの列として表示されます。1 列目 (左側) には、マッチングの対象となる可能性のある入力文字列 (パターン)、2 列目 (右側) には入力文字列のマッピングの結果である出力文字列 (テンプレート) が表示されます。

次の表で、マッピングテーブルの使用により、だれがメールを送信または受信できるのか、あるいは送受信ともにできるのかを制御する方法を説明します。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

表 13–2 アクセス制御マッピングテーブル

マッピングテーブル 

説明 

SEND_ACCESS

エンベロープ From: アドレス、エンベロープ To: アドレス、ソースおよび送信先チャネルに基づいて、着信接続をブロックする場合に使用します。書き換え、エイリアスの展開などが実行されたあとで To: アドレスが調べられます。

ORIG_SEND_ACCESS

エンベロープ From: アドレス、エンベロープ To: アドレス、ソースおよび送信先チャネルに基づいて、着信接続をブロックする場合に使用します。 To: アドレスは、書き換えのあとに、しかしエイリアスの展開より先に調べられます。

MAIL_ACCESS

SEND_ACCESS および PORT_ACCESS の各テーブル内の情報の組み合わせに基づいて着信接続をブロックするために使用します。SEND_ACCESS 内のチャネルおよびアドレス情報と、PORT_ACCESS 内の IP アドレスおよびポート番号情報を組み合わせた情報が基準となります。

ORIG_MAIL_ACCESS

ORIG_SEND_ACCESS および PORT_ACCESS の各テーブル内の情報の組み合わせに基づいて着信接続をブロックするために使用します。ORIG_SEND_ACCESS 内のチャネルおよびアドレス情報と、PORT_ACCESS 内の IP アドレスおよびポート番号情報を組み合わせた情報が基準となります。

FROM_ACCESS

エンベロープ From: アドレスに基づいてメールをフィルタリングする場合に使用します。このテーブルは、To: アドレスが不適切な場合に使用します。

PORT_ACCESS

IP 番号に基づいて着信接続をブロックする場合に使用します。 

図 13–1 は、メール受信プロセスの中でマッピングテーブルが使用される場所を示したものです。

図 13–1 マッピングテーブルとメール受信プロセス

この図は、メール受信プロセスの中で pre-SMTP accept フィルタリングがどのように使用されるかを示したものです。

MTA サービスディスパッチャーが制御するすべてのネットワークポートで、PORT_ACCESS 拒否応答が保証されている場合は、リモートホストから最初の接続が行われた時点で、それが実行されます。FROM_ACCESS による拒否は、送信側が受信者情報またはメッセージデータを送信する前に、MAIL FROM: コマンドへの応答として行われます。SEND_ACCESS または MAIL_ACCESS による拒否は、送信側がメッセージデータを送信する前に、RCPT TO: コマンドへの応答として行われます。SMTP メッセージが拒否された場合は、Messaging Server がメッセージデータを受信せずメッセージデータを確認しないため、そのような拒否を処理するためのオーバーヘッドが最小になります。複数のアクセス制御マッピングテーブルが存在する場合、Messaging Server はそれらをすべて調べます。

注 –

メッセージが受け入れられた場合は、さらに変換チャネルとユーザー定義のフィルタによりフィルタリングされます。

マッピングテーブルによるリレー防止設定

アクセス制御マップを使うことによって、Messaging Server システムが SMTP メールのリレーに利用されるのを防ぐことができます。たとえば、あるユーザーが迷惑メールのリレーにメールシステムを使用して、システム上の多数のメールボックスに送信しようとするような場合です。

Messaging Server のデフォルトでは、ローカルの POP メールクライアントおよび IMAP メールクライアントによるリレーを含むすべての SMTP リレー操作が防止されます。「認証された SMTP を有効にする」で説明しているように、クライアントが SMTP AUTH を使用して認証せず、Messaging Server の SMTP サーバーを介して外部アドレスにメッセージを送信しようとした場合、その送信は拒否されます。このため、内部システムとリレーを許可するサブネットを認識するように設定を変更した方がよいでしょう。

Procedure外部ホストからのリレーを防止するには

ドメイン外にあるホストからドメイン外の別のホストにメッセージがリレーされるのを防ぐには、次の方法を取ります。

手順

  1. 受信メールをいくつかのチャネルに分けます。例:

    • ドメイン内の IP アドレスは tcp_internal チャネルに送られます。

    • 認証されたセッションは tcp_auth チャネルに送られます。

    • その他のすべてのメールは、tcp_local チャネルに送られます。

  2. 『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の「メールのフィルタリングとアクセス制御」の章で詳しく説明されているように、INTERNAL_IP マッピングテーブルを使用して、POP クライアントと IMAP クライアントからのメールを識別し、処理を許可します。

メールボックスフィルタの使用

フィルタは、メッセージに適用される 1 つ以上の条件付き処理で構成されています。Messaging Server フィルタはサーバーに保存され、サーバーによって評価されます。そのため、それらはサーバー側規則 (SSR) と呼ばれることもあります。

チャネルレベルのフィルタと MTA 全体のフィルタを作成し、不正メールの配信を防止できます。また、フィルタテンプレートを作成し、Messenger Express を使用してそれをエンドユーザーに使わせることもできます。エンドユーザーはテンプレートを使用して個人のメールボックスフィルタを構築し、不要なメールメッセージが自分のメールボックスに配送されないようにすることができます。サーバーは、次の優先順位に従ってフィルタを適用します。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

  1. ユーザー単位のフィルタ

    ユーザー単位のフィルタは、特定ユーザーのメールボックスに送信されるメッセージに適用されます。フィルタテンプレートを作成し、Messenger Express クライアントを使用してそれをエンドユーザーに使わせることができます。エンドユーザーはテンプレートを使用して個人のサーバーフィルタを構築し、自分のメールボックスへのメールメッセージの配送を管理できます。フィルタにより、不要なメッセージ、リダイレクトメールなどの拒否や、メールボックスフォルダに配信されるメッセージのフィルタリングなどが行われます。

    個人用メールボックスフィルタにメッセージの許可あるいは拒否が定義されている場合は、メッセージに対してそのフィルタ処理が行われます。

    フィルタテンプレートは、Sieve スクリプトの「ハードコード」された要素をプロンプトと入力フィールドに置き換えることで、Sieve スクリプトを一般化します。Java サーブレットは、Sieve テンプレートを解析し、ブラウザ内でユーザーインタフェースを生成するのに使用されます。エンドユーザーが入力フィールドに値を入力すると、サーブレットがその値を取得して、ユーザーのディレクトリにあるプロファイルエントリ内の Sieve スクリプトに保存します。Messenger Express インタフェースを通じて、プロンプトと入力フィールドがエンドユーザーに提示されます。

    しかし、受取人がメールボックスフィルタを設定していない場合、またはユーザーのメールボックスフィルタが明示的に適用されないメッセージの場合、Messaging Server によってチャネルレベルのフィルタが適用されます。

  2. チャネルレベルのフィルタ

    チャネルレベルのフィルタは、チャネルのキューに入った各メッセージに適用されます。この種のフィルタの一般的な用途は、特定のチャネルから入ってくるメッセージをブロックすることです。

    チャネルレベルのフィルタを作成するには、Sieve を使用してフィルタを書く必要があります。Sieve を使用してフィルタを作成する場合の指示の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 17 章「メールのフィルタリングとアクセス制御」を参照してください。

    チャネルレベルのフィルタにメッセージの許可あるいは拒否が定義されている場合は、メッセージに対してそのフィルタ処理が行われます。それ以外の場合は、Messaging Server によって MTA 全体のフィルタが適用されます (該当する場合)。

  3. MTA 全体のフィルタ

    MTA 全体のフィルタは、MTA のキューに入るすべてのメッセージに適用されます。この種のフィルタの一般的な用途は、メッセージの送信先とは関係なく、ダイレクトメールや受信したくないメッセージをブロックすることです。

    MTA 全体のフィルタを作成するには、Sieve を使用してフィルタを書く必要があります。Sieve を使用してフィルタを作成する場合の指示の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 17 章「メールのフィルタリングとアクセス制御」を参照してください。

    デフォルト設定を使用した場合、それぞれのユーザーはメールボックスフィルタを所有していません。ユーザーが Messenger Express インタフェースにアクセスして 1 つまたは複数のフィルタを作成すると、そのフィルタが LDAP ディレクトリに保存されます。

変換チャネルとサードパーティーのフィルタリングツール

変換チャネルは、MTA を通じて配信されるメッセージを本文部分ごとに変換します。この処理は、サイトで提供されるプログラムかコマンドにより行われます。変換チャネルは、テキストや画像のフォーマット変換、ウイルスのスキャン、言語の変換などを行うことができます。MTA で通信するさまざまなメッセージ形式を変換することができ、特定の処理やプログラムをメッセージの本文部分に指定することができます。変換チャネルをウイルススキャニングプログラムと併用する場合は、ウイルスの除去、メッセージの保留または拒否を選択できます。特別な変換チャネル設定を使用すると、それぞれのメッセージ本文に対する適切な変換を選択できます。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 13 章「定義済みチャネルを使用する」を参照してください。

注 –

変換チャネルのような特別な処理を行うと、システムに余分の負荷がかかります。戦略のサイズを検討する場合には、この点を考慮してください。

変換チャネルを使用すると、サードパーティーのスパム防止およびウイルス対策ソフトウェアソリューションを利用できます。また、MTA API を使用してチャネルを作成し、リモートスキャニングエンジンを起動することもできます。MTA API の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。

一般に、サードパーティーのソリューションは外部サイトから保護して、バックエンドまたは中間のリレーのみで使用するのが最も適した使い方です。

Brightmail ソリューションは、Brightmail サーバーと、リアルタイムのスパム防止およびウイルス対策 (サービスプロバイダ向けのみ) 規則アップデートで構成されており、規則はメッセージングサーバーにダウンロードされます。Brightmail Logistics and Operations Center (BLOC) が電子メールプローブからスパムを受信すると、オペレータがただちに適切なスパム防止規則を作成します。次に、これらの規則が Brightmail カスタママシンにダウンロードされます。同様に、Symantec Security Response のリアルタイムのウイルス規則が Brightmail から送信されます。これらの規則は顧客の Brightmail サーバーでスパムやウイルスを検出するために使用されます。

Messaging Server では、SpamAssassin の使用もサポートされています。SpamAssassin はフリーウェアのメールフィルタで、スパムの特定に使用されます。SpamAssassin では、すべてのメッセージのスコアが計算されます。スコアは、メッセージヘッダーや本文の情報に対して一連のテストを実行することによって計算されます。各テストに成功するか失敗するかによってスコアは調整されます。スコアは正または負の実数です。スコアが一定のしきい値を超えると、スパムであるとみなされます。

Brightmail および SpamAssassin の Messaging Server に対する設定の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 14 章「スパムとウィルスのフィルタ処理プログラムを Messaging Server に統合する」を参照してください。

RBL チェック

Mail Abuse Protection System の Real-time Blackhole List (MAPS RBL) は、スパムの発信やリレーを行なったり、スパムのサポートサービスを提供したりしてホストやネットワークを悪用している者に好意的、あるいは中立的な立場を取っていると判断されたホストとネットワークのリストです。

外部からの MAPS RBL に対する接続の比較を行うように、MTA を設定することができます。また、DNS ベースのデータベースを使用して、不特定多数宛のメールを送る可能性のある受信 SMTP 接続を判別できます。

詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 17 章「メールのフィルタリングとアクセス制御」を参照してください。

クライアントアクセスの制御

Messaging Server は、POP、IMAP、および HTTP について、サービスごとの高度なアクセス制御機能をサポートしています。Messaging Server のアクセス制御機能は、TCP デーモンと同じポートで待機するプログラムです。アクセス制御機能では、アクセスフィルタによるクライアントの識別情報の検証が行われ、そのクライアントがフィルタリング処理を通過した場合は、デーモンへのアクセスが許可されます。

大企業やサービスプロバイダのメッセージングサービスを管理する場合、これらの機能を使用して、スパム (大量メール送信) や DNS スプーフィングを行うユーザーをシステムから除外したり、ネットワークの全般的なセキュリティーを強化したりできます。

Messaging Server の TCP クライアントアクセス制御システムは、必要な場合、その処理の一部として、次のようなソケットの終端アドレスの分析を行います。

システムは、この情報を「フィルタ」と呼ばれるアクセス制御文と比較して、アクセスの許可または拒否を決定します。サービスごとに、個別の許可フィルタと拒否フィルタのセットを使用して、アクセスを制御します。許可フィルタは明示的にアクセスを許可し、拒否フィルタは明示的にアクセスを禁止します。

クライアントがサービスへのアクセスを要求すると、アクセス制御システムは、そのクライアントのアドレスまたは名前情報を、次の条件を使用して順番に対象のサービスのフィルタと比較します。

  1. 検索は、最初の一致項目が見つかった時点で終了する。許可フィルタは、拒否フィルタより先に処理されるため、許可フィルタが優先される。

  2. クライアント情報が対象のサービスの許可フィルタに一致した場合は、アクセスが許可される。

  3. クライアント情報がそのサービスの拒否フィルタに一致した場合は、アクセスが拒否される。

  4. どの許可または拒否フィルタにも一致しなかった場合、アクセスが許可される。例外は、許可フィルタは存在しているが拒否フィルタが存在しない場合で、その場合にはフィルタに一致しなかったアクセスは拒否される。

ここで説明するフィルタの構文は柔軟性に富んでいるため、わかりやすい簡単な方法で、さまざまなアクセス制御ポリシーを実装できます。許可フィルタと拒否フィルタは自由に組み合わせて使用できますが、大半のアクセスを許可するフィルタまたは大半のアクセスを拒否するフィルタを使用すると、ほとんどのポリシーを実装できます。

クライアントアクセスフィルタは、問題のあるドメインの数が把握できる場合に特に有効です。UBE の場合、Messaging Server はすべてのスパムメッセージを格納し処理する必要がありますが、クライアントアクセスフィルタの場合はスパムメッセージを処理する必要がありません。クライアントアクセスフィルタはドメイン全体からのメールをブロックするため、この機能は慎重に使用する必要があります。

クライアントアクセスフィルタには、次の制限があります。

クライアントアクセスフィルタの詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 19 章「セキュリティーとアクセス制御を設定する」を参照してください。

セキュリティー戦略の監視

サーバーの監視は、セキュリティー戦略で重要な位置を占めます。システムに対する攻撃を識別するには、メッセージキューのサイズ、CPU の使用率、ディスクの空き容量、ネットワークの使用率を監視します。メッセージキューのサイズが異常に大きくなったり、サーバーの応答時間が長くなったりするのは、MTA リレーへの攻撃の可能性があります。また、通常とは異なるシステムの負荷パターンや接続についても調査します。ログを毎日チェックして、異常な活動がないか調べます。

メッセージストアの保護

メッセージングサーバーで最も重要なデータは、メッセージストア内のユーザーのメールです。メールメッセージは、暗号化されない個別のファイルとして格納されることに留意してください。したがって、物理的なアクセスや root アクセスからメッセージストアを保護する必要があります。

メッセージストアをセキュリティーで保護するには、ストアがインストールされているマシンへのアクセスを制限します。暗号化されないプレーンテキストのパスワードの代わりに、CRAM-MD5 パスワードまたは Digest-MD5 パスワードを使用できます。パスワードの詳細については、「メッセージングユーザー認証の計画」を参照してください。

ストアマシンの認証にパスワードを作成するだけでなく、VPN アクセス、ssh、または pam のような、マシンへのログインが許可された有効なユーザーを一覧表示するツールを使用することもあります。

また、1 層のアーキテクチャーよりも 2 層のアーキテクチャーをお勧めします。メッセージストアは、メッセージングシステムのコンポーネント中で最もディスクに負担をかける作業を行うため、フィルタリング、ウイルススキャニング、およびその他のディスクに負担をかけるセキュリティー処理を同じマシンで行わないようにします。2 層のアーキテクチャーでは、システムに余分な負荷がかかるメッセージストアと同じマシンで UBE フィルタ、リレー防止機能、およびクライアントアクセスフィルタを使用せずにすみます。代わりに、MTA がその処理を行います。さらに、ストアへのユーザーアクセスが 2 階層配備の MMP または MEM により制限され、実質的にメッセージストアにセキュリティー層を追加したことになります。

1 層のアーキテクチャーで配備を行う場合は、セキュリティー処理の追加と、SSL やウイルススキャニングなどに必要となる負荷を考慮してください。詳細については、第 10 章「Messaging Server サイズ決定戦略の計画」を参照してください。

メッセージストアにセキュリティー処理を追加する場合は、ユーザーごとにディスク割り当てを行なって、ディスクの使用率を制限します。また、空き容量が制限に近づいたときには管理アラームを出すようにします。さらに、MTA の場合と同様に、サーバーの状態、ディスク容量、サービスの応答時間を監視します。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 18 章「メッセージストアを管理する」を参照してください。

MMP と MEM の保護

MMP はメッセージストアのプロキシとして機能するため、エンドユーザーデータへのアクセスを防ぎ、権限のないアクセスから保護する必要があります。ユーザー ID とパスワードは、基本的な認証機能となります。さらに、クライアントアクセスフィルタを使用すれば、ユーザーが特定のドメインや特定の IP アドレスの範囲にアクセスするのを制限できます。SMTP リレーサーバーのセキュリティーを提供する方法としては、SMTP 認証または SMTP AUTH (RFC 2554) をお勧めします。SMTP AUTH は、認証済みのユーザーだけに MTA を介したメール送信を許可します。詳細については、「認証された SMTP を有効にする」を参照してください。

POP サービスまたは IMAP サービスの前に、MMP を別のマシンまたは別のユーザー ID のもとに配置します。フロントエンドマシンには MMP と MTA のみを配置してから、フロントエンドマシン、メールストア、および LDAP サーバー間で、物理的にセキュリティー保護されたネットワークを構築できます。

ユーザーがインターネットからログインする場合は、Messenger Express からメッセージストアへのアクセスのセキュリティーには特に配慮が必要となります。一般的には、ストアはファイアウォールにより外部と分離します。さらに、HTTP アクセスサービスへの単一の接続ポイントとして機能する特別なサーバーとして、Messenger Express マルチプレクサ (MEM) を使用することも考えられます。MMP と同様に、MEM は、メールクライアントとの間で、暗号化されていない通信と暗号化された (SSL) 通信の両方をサポートしています。MEM は、エンドユーザーデータへのアクセスと権限のないアクセスからの保護も行う必要があります。

ログファイルを定期的に監視することで、権限のないアクセスを防ぐことができます。