test

Sun Java System Messaging Server 6.3 管理ガイド

23.7 POP、IMAP、および HTTP サービスへのクライアントアクセスを構成する

ここで説明する内容は、次のとおりです。

Messaging Server には、IMAP、POP、HTTP の各サービスを個別に制御できる精巧なアクセス制御機能があります。これにより、クライアントによるサーバーへのアクセスを広範囲に細かく制御できます。

大企業やインターネットサービスプロバイダのメッセージングサービスを管理する場合、これらの機能を使用して、スパム (大量メール送信) や DNS スプーフィングを行うユーザーをシステムから除外したり、ネットワークの全般的なセキュリティーを強化したりできます。不特定多数宛メールを制御するための具体的な方法については、第 18 章「メールのフィルタリングとアクセス制御」を参照してください。

注 –

IP アドレスによるアクセス制御が重要な問題ではない場合は、この節で説明しているフィルタを作成する必要はありません。最小限のアクセス制御だけが必要な場合は、その設定手順について、「23.7.3.2 大半のアクセスを許可」を参照してください。

23.7.1 クライアントアクセスフィルタのしくみ

Messaging Server のアクセス制御機能は、プログラムであり、TCP デーモンと同じポートで応答を待機します。このプログラムは、アクセスフィルタを使用してクライアントの識別情報を確認し、クライアントがフィルタリングプロセスを通過した場合に、そのクライアントに対してデーモンへのアクセス権を与えます。

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

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

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

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

次の節では、フィルタの構文について詳しく説明し、さらに使用例を紹介します。アクセスフィルタの作成手順については、「23.7.4 各サービス用のアクセスフィルタを作成する」を参照してください。

23.7.2 フィルタの構文

フィルタ文には、サービス情報とクライアント情報の両方が含まれています。サービス情報には、サービス名、ホスト名、ホストアドレスを含めることができます。クライアント情報には、ホスト名、ホストアドレス、ユーザー名を含めることができます。サービス情報とクライアント情報の両方で、ワイルドカード名やパターンを使用できます。

以下に、非常に単純な形式のフィルタを示します。

service: hostSpec

service には、サービス名 (smtp、pop、imap、http など) を指定し、hostSpec には、ホスト名、IP アドレス、またはアクセス要求元のクライアントを表すワイルドカード名やパターンを指定します。フィルタが処理されるときに、アクセス要求元のクライアントが client に一致すると、service で指定されているサービスへのアクセスが、フィルタのタイプに応じて許可または拒否されます。次に例をいくつか示します。

imap: roberts.newyork.siroe.com
pop: ALL
http: ALL

これらが許可フィルタの場合は、最初の行によって roberts.newyork.siroe.com というホストに対して、IMAP サービスへのアクセスが許可されます。さらに 2 行目と 3 行目によって、それぞれ POP サービスと HTTP サービスへのアクセスがすべてのクライアントに許可されます。これらが拒否フィルタの場合は、それらのクライアントによる指定したサービスへのアクセスが拒否されます。ALL などのワイルドカード名の詳細は、「23.7.2.1 ワイルドカード名」を参照してください。

フィルタ内のサーバー (サービス) 情報やクライアント情報は、これよりも少々複雑になることがあります。次に、その場合の一般的な形式を示します。

serviceSpec: clientSpec

serviceSpec は service または service@hostSpec のどちらかを示し、clientSpec は hostSpec または user@hostSpec のどちらかを示します。user はアクセス要求元のクライアントホストに関連付けられたユーザー名 (またはワイルドカード名) です。次に 2 つの例を示します。

pop@mailServer1.siroe.com: ALL
imap: srashad@xyz.europe.siroe.com

これらが拒否フィルタの場合、最初のフィルタは、すべてのクライアントに対して、ホスト mailServer1.siroe.com 上の SMTP サービスへのアクセスを拒否します。2 番目のフィルタは、ホスト xyz.europe.siroe.com のユーザー srashad に対して、IMAP サービスへのアクセスを拒否します。これらの詳細なサーバーおよびクライアントに対する指定を使用する状況については、「23.7.2.4 サーバーホストの指定」および 「23.7.2.5 クライアントのユーザー名の指定」を参照してください。

もっとも一般的なフィルタの形式は次のようになります。

serviceList: clientList

serviceList は、1 つ以上の serviceSpec エントリで構成され、clientList は、1 つ以上の clientSpec エントリで構成されます。serviceList と clientList 内の各エントリは、空白またはカンマで区切ります。

この場合、フィルタが処理されるときに、アクセス要求元のクライアントが、clientList 内の clientSpec エントリのいずれかと一致すると、serviceList で指定されているすべてのサービスへのアクセスが、フィルタのタイプに応じて許可または拒否されます。次に例を示します。

pop, imap, http: .europe.siroe.com .newyork.siroe.com

これが許可フィルタの場合、europe.siroe.comドメインおよび newyork.siroe.com ドメイン内のすべてのクライアントに対して、POP、IMAP、HTTP サービスへのアクセスが許可されます。ドメインやサブネットを指定する場合の先頭に付けるドットやほかのパターンの使用方法については、「23.7.2.2 ワイルドカードのパターン」を参照してください。

次の構文も使用できます。

「+」または「-」serviceList:*$next_rule

+ (許可フィルタ) は、デーモンリストサービスがクライアントリストに付与されることを意味します。

- (拒否フィルタ) は、クライアントリストに対してサービスが拒否されることを意味します。

* (ワイルドカードフィルタ) は、すべてのクライアントにこれらのサービスの使用を許可します。

$ は、ルールの区切りです。

次の例では、すべてのクライアントで複数のサービスを有効にしています。

+imap,pop,http:*

次の例では、複数のルールを単純化して各ルールが単一のサーバー名を所有し、クライアントリスト用のワイルドカードを使用するようにします。これは、LDIF ファイルでアクセス制御を指定するためのもっとも一般的な方法です。

+imap:ALL$+pop:ALL$+http:ALL

次の例では、あるユーザーに対してすべてのサービスを許可しない方法を示します。

-imap:*$-pop:*$-http:*

23.7.2.1 ワイルドカード名

次のワイルドカード名を使用して、サービス名、ホストの名前やアドレス、またはユーザー名を表すことができます。

表 23–3 サービスフィルタのワイルドカード名

ワイルドカード名 

意味 

ALL, *

汎用のワイルドカードです。すべての名前に一致します。 

LOCAL

すべてのローカルホスト (ドット文字を含まない名前を持つホスト) に一致します。ただし、正規名のみを使用しているシステムの場合は、ローカルホスト名もドットを含むため、このワイルドカードに一致しません。 

UNKNOWN

名前が不明なすべてのユーザー、あるいは名前またはアドレスが不明なすべてのホストに一致します。 

このワイルドカード名は、次のことに注意して使用する必要があります。 

一時的な DNS サーバーの問題により、ホスト名が使用できなくなる場合があります。このような場合、UNKNOWN を使用しているすべてのフィルタはすべてのクライアントホストに一致します。

ソフトウェアが通信相手のネットワークのタイプを識別できない場合は、ネットワークアドレスを使用できません。そのような場合、UNKNOWN を使用しているすべてのフィルタは、そのネットワーク上にあるすべてのクライアントホストに一致します。

KNOWN

名前が認識されているすべてのユーザー、または名前およびアドレスが認識されているすべてのホストに一致します。

このワイルドカード名は、次のことに注意して使用する必要があります。 

一時的な DNS サーバーの問題により、ホスト名が使用できなくなる場合があります。このような場合、KNOWN を使用しているすべてのフィルタはどのクライアントホストにも一致しません。

ソフトウェアが通信相手のネットワークのタイプを識別できない場合は、ネットワークアドレスを使用できません。そのような場合、KNOWN を使用しているすべてのフィルタは、そのネットワーク上にあるどのクライアントホストにも一致しません。

DNSSPOOFER

IP アドレスと DNS 名が一致しないすべてのホストに一致します。 

23.7.2.2 ワイルドカードのパターン

サービスまたはクライアントアドレスを指定するときは、次のパターンを使用できます。

23.7.2.3 EXCEPT 演算子

アクセス制御システムでは、1 つの演算子がサポートされています。この EXCEPT 演算子を使うと、serviceList または clientList 内に複数のエントリがある場合に、名前やパターンの一致に関する例外を指定することができます。たとえば、次のような式を使用します。

list1 EXCEPT list2

この式では、list1 に一致するもので、list2 に一致しないものが、すべて一致します。

次に例を示します。

ALL: ALL EXCEPT isserver.siroe.com

これが拒否フィルタの場合、ホストマシン isserver.siroe.com 上のクライアントを除くすべてのクライアントに対して、すべてのサービスへのアクセスが拒否されます。

EXCEPT 句は入れ子にすることができます。次に入れ子の式の例を示します。

list1 EXCEPT list2 EXCEPT list3

これは次の式と同様に評価されます。

list1 EXCEPT (list2 EXCEPT list3)

23.7.2.4 サーバーホストの指定

serviceSpec エントリにサーバーホストの名前またはアドレス情報を含めることで、要求される特定のサービスをフィルタ内で識別することができます。この場合、次の形式でエントリを指定します。

service@hostSpec

この機能は、Messaging Server ホストマシンが、異なるインターネットホスト名を持つ複数のインターネットアドレス用に設定されている場合に有効です。サービスプロバイダの場合、この機能を使用することで、異なるアクセス制御ルールを持つ複数のドメインを 1 つのサーバーインスタンス上でホストできます。

23.7.2.5 クライアントのユーザー名の指定

RFC 1413 に記載された identd サービスをサポートするクライアントホストマシンの場合は、フィルタの clientSpec エントリ内にクライアントのユーザー名を含めることにより、サービスを要求している特定のクライアントを識別することができます。この場合、次の形式でエントリを指定します。

user@hostSpec

user は、クライアントの identd サービスによって返されるユーザー名 (またはワイルドカード名) です。

フィルタ内でクライアントユーザー名を指定すると便利ですが、次のことに注意する必要があります。

ユーザー名検索の機能は、クライアントホスト上の承認されていないユーザーからの攻撃を防ぐために役立つ場合があります。たとえば、一部の TCP/IP の実装環境では、侵入者が rsh (リモートシェルサービス) を使用して信頼されているクライアントホストになりすます場合があります。クライアントホストが ident サービスをサポートしている場合は、ユーザー名の検索を使用してそのような攻撃を検出できます。

23.7.3 フィルタの例

この節では、さまざまなアクセス制御方法の例を紹介します。これらの例を参照する際には、許可フィルタが拒否フィルタよりも先に処理されること、一致するものが見つかった時点で検索が終了すること、および一致するものがまったく見つからないとアクセスが許可されることに注意してください。

ここに記載した例では、IP アドレスではなく、ホスト名とドメイン名を使用します。フィルタにアドレス情報やネットマスク情報を含めておくと、ネームサービスに障害が発生した場合の信頼性を向上させることができます。

23.7.3.1 大半のアクセスを拒否

この例では、デフォルトでアクセスを拒否します。明示的に許可したホストだけにアクセスを許可します。

デフォルトのポリシー (アクセスなし) は、次のような 1 つの単純な拒否フィルタを使用して実装します。

ALL: ALL

このフィルタは、許可フィルタによって明示的にアクセスを許可されていないすべてのクライアントに対して、すべてのサービスへのアクセスを拒否します。この場合の許可フィルタは、たとえば次のようになります。

ALL: LOCAL @netgroup1

ALL: .siroe.com EXCEPT externalserver.siroe.com

最初のルールは、ローカルドメイン内のすべてのホスト (ドットを含まないホスト名を持つすべてのホスト) からのアクセス、および netgroup1 というグループのメンバーからのアクセスを許可します。2 番目のルールでは、先頭にドットが付いたワイルドカードパターンを使用することで、siroe.com ドメイン内のすべてのホストからのアクセスを許可しますが、ホスト externalserver.siroe.com は除外されます。

23.7.3.2 大半のアクセスを許可

この例では、デフォルトでアクセスを許可します。明示的に拒否したホストだけにアクセスを拒否します。

デフォルトのポリシー (アクセス許可) により、許可フィルタは不要になります。次のように、アクセスを拒否するクライアントのリストを拒否フィルタ内に明示的に指定します。

ALL: externalserver.siroe1.com, .siroe.asia.com
ALL EXCEPT pop: contractor.siroe1.com, .siroe.com

最初のフィルタは、特定のホストおよびドメインに対して、すべてのサービスを拒否します。2 番目のフィルタは、特定のホストおよびドメインからの POP アクセスだけを許可します。

23.7.3.3 スプーフィングされたドメインのアクセスを拒否

フィルタ内で、DNSSPOOFER を使用すると、ホスト名のスプーフィングを検出できます。DNSSPOOFER を指定すると、アクセス制御システムによって正引きまたは逆引きの DNS 検索が実行され、クライアントが提示したホスト名とホストの実際の IP アドレスが一致するかどうかが調べられます。以下に拒否フィルタの例を示します。

ALL: DNSSPOOFER

このフィルタは、IP アドレスとその DNS ホスト名が一致しないすべてのリモートホストに対して、すべてのサービスを拒否します。

23.7.3.4 仮想ドメインへのアクセス制御

メッセージングシステムで仮想ドメインを使用し、1 つのサーバーインスタンスが複数の IP アドレスおよびドメイン名に関連付けられている場合は、許可フィルタと拒否フィルタを組み合わせて各仮想ドメインのアクセスを制御できます。たとえば、次のような許可フィルタを使用できます。

ALL@msgServer.siroe1.com: @.siroe1.com
ALL@msgServer.siroe2.com: @.siroe2.com
...

この場合、次のような拒否フィルタと組み合わせることができます。

ALL: ALL

各許可フィルタは、domainN 内のホストだけに、msgServer.siroeN.com に対応する IP アドレスを持つサービスへの接続を許可します。ほかの接続はすべて拒否されます。

23.7.3.5 Webmail へのアクセスを許可したまま IMAP アクセスを制御する

ユーザーが Webmail にアクセスできるが、IMAP にはアクセスできないようにする場合は、次のようなフィルタを作成します。


+imap:access_server_host, access_server_host

これにより、アクセスサーバーホストからは IMAP のみが許可されます。このフィルタは、service.imap.domainallowed を使用して IMAP サーバーのレベルで、または LDAP 属性を使用してドメイン/ユーザーのレベルで設定できます。

23.7.4 各サービス用のアクセスフィルタを作成する

IMAP、POP、HTTP の各サービス用の許可フィルタと拒否フィルタを作成できます。SMTP サービス用に作成することもできますが、認証済みの SMTP セッションにしか適用されないため、あまり価値はありません。第 18 章「メールのフィルタリングとアクセス制御」を参照してください。

Procedureフィルタを作成する

  1. コマンド行: 次のように、コマンド行を使用して許可フィルタや拒否フィルタを指定することもできます。

    各サービス用のアクセスフィルタを作成または編集するには、次のように入力します。


    configutil -o service.service.domainallowed -v filter

    service には pop、imap、http のいずれかを指定し、filter は 「23.7.2 フィルタの構文」で説明した構文ルールに従って指定します。

    各サービス用の拒否フィルタを作成または編集するには、次のように入力します。


    configutil -o service.service.domainnotallowed -v filter

    service には pop、imap、http のいずれかを指定し、filter は 「23.7.2 フィルタの構文」で説明した構文ルールに従って指定します。各種の例については、「23.7.3 フィルタの例」を参照してください。

23.7.5 HTTP プロキシ認証用のアクセスフィルタを作成する

すべてのストア管理者は、任意のサービスに対してプロキシ認証を行うことができます (ストア管理者の詳細については、「20.4 ストアへの管理者によるアクセスを指定する」を参照)。HTTP サービスの場合にだけ、すべてのエンドユーザーがサービスに対してプロキシ認証を行うことができます。ただし、ユーザーが使用するクライアントホストが、プロキシ認証アクセスフィルタを介してアクセスを許可されている必要があります。

プロキシ認証を使用すると、ポータルサイトなどのほかのサービスが、ユーザーを認証して、HTTP ログインサービスに認証資格情報を渡すことができます。たとえば、1 つのポータルサイトが複数のサービスを提供し、そのうちの 1 つが Messenger Express の Web ベースの電子メールだとします。HTTP プロキシ認証機能を使用すると、エンドユーザーはポータルサービスに対する認証を一度行うだけで済み、電子メールにアクセスするために再び認証を行う必要はありません。ただし、ポータルサイトでは、クライアントとサービス間のインタフェースとして機能するログインサーバーを構成する必要があります。Messenger Express の認証用にログインサーバーを設定する場合は、Sun Java System が提供する Messenger Express 認証 SDK を利用できます。

この節では、許可フィルタを使用し、IP アドレスを基準として、HTTP プロキシ認証を許可する方法について説明します。ログインサーバーの設定方法や Messenger Express 認証 SDK の使用方法については説明しません。Messenger Express 用のログインサーバーの設定方法や、認証 SDK の使用方法については、Sun Java System の担当者に問い合わせてください。

ProcedureHTTP プロキシ認証用のアクセスフィルタを作成する

  1. コマンド行: 次のように、コマンド行を使用して、HTTP サービスに対するプロキシ認証用のアクセスフィルタを指定します。


    configutil -o service.service.proxydomainallowed -v filter

    filter は、「23.7.2 フィルタの構文」 で説明した構文ルールに従って指定します。