フィルタ文には、サービス情報とクライアント情報の両方が含まれています。サービス情報には、サービス名、ホスト名、ホストアドレスを含めることができます。クライアント情報には、ホスト名、ホストアドレス、ユーザー名を含めることができます。サービス情報とクライアント情報の両方で、ワイルドカード名やパターンを使用できます。
以下に、非常に単純な形式のフィルタを示します。
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 などのワイルドカード名の詳細は、「ワイルドカード名」を参照してください。
フィルタ内のサーバー (サービス) 情報やクライアント情報は、これよりも少々複雑になることがあります。次に、その場合の一般的な形式を示します。
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 サービスへのアクセスを拒否します。これらの詳細なサーバーおよびクライアントに対する指定を使用する状況については、「サーバーホストの指定」および 「クライアントのユーザー名の指定」を参照してください。
もっとも一般的なフィルタの形式は次のようになります。
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 サービスへのアクセスが許可されます。ドメインやサブネットを指定する場合の先頭に付けるドットやほかのパターンの使用方法については、「ワイルドカードのパターン」を参照してください。
次の構文も使用できます。
「+」または「-」serviceList:*$next_rule
+ (許可フィルタ) は、デーモンリストサービスがクライアントリストに付与されることを意味します。
- (拒否フィルタ) は、クライアントリストに対してサービスが拒否されることを意味します。
* (ワイルドカードフィルタ) は、すべてのクライアントにこれらのサービスの使用を許可します。
$ は、ルールの区切りです。
次の例では、すべてのクライアントで複数のサービスを有効にしています。
+imap,pop,http:*
次の例では、複数のルールを単純化して各ルールが単一のサーバー名を所有し、クライアントリスト用のワイルドカードを使用するようにします。これは、LDIF ファイルでアクセス制御を指定するためのもっとも一般的な方法です。
+imap:ALL$+pop:ALL$+http:ALL
次の例では、あるユーザーに対してすべてのサービスを許可しない方法を示します。
-imap:*$-pop:*$-http:*
次のワイルドカード名を使用して、サービス名、ホストの名前やアドレス、またはユーザー名を表すことができます。
表 19–3 サービスフィルタのワイルドカード名
ワイルドカード名 |
説明 |
---|---|
ALL, * |
汎用のワイルドカードです。すべての名前に一致します。 |
LOCAL |
すべてのローカルホスト (ドット文字を含まない名前を持つホスト) に一致します。ただし、正規名のみを使用しているシステムの場合は、ローカルホスト名もドットを含むため、このワイルドカードに一致しません。 |
UNKNOWN |
名前が不明なすべてのユーザー、あるいは名前またはアドレスが不明なすべてのホストに一致します。 このワイルドカード名は、次のことに注意して使用する必要があります。 一時的な DNS サーバーの問題により、ホスト名が使用できなくなる場合があります。このような場合、UNKNOWN を使用しているすべてのフィルタはすべてのクライアントホストに一致します。 ソフトウェアが通信相手のネットワークのタイプを識別できない場合は、ネットワークアドレスを使用できません。そのような場合、UNKNOWN を使用しているすべてのフィルタは、そのネットワーク上にあるすべてのクライアントホストに一致します。 |
KNOWN |
名前が認識されているすべてのユーザー、または名前およびアドレスが認識されているすべてのホストに一致します。 このワイルドカード名は、次のことに注意して使用する必要があります。 一時的な DNS サーバーの問題により、ホスト名が使用できなくなる場合があります。このような場合、KNOWN を使用しているすべてのフィルタはどのクライアントホストにも一致しません。 ソフトウェアが通信相手のネットワークのタイプを識別できない場合は、ネットワークアドレスを使用できません。そのような場合、KNOWN を使用しているすべてのフィルタは、そのネットワーク上にあるどのクライアントホストにも一致しません。 |
DNSSPOOFER |
IP アドレスと DNS 名が一致しないすべてのホストに一致します。 |
サービスまたはクライアントアドレスを指定するときは、次のパターンを使用できます。
ドット文字 (.) から始まる文字列。ホスト名の最後の部分が指定したパターンに一致する場合、そのホスト名は一致します。たとえば、ワイルドカードパターン .siroe.com は、ドメイン siroe.com 内のすべてのホストに一致します。
ドット文字 (.) で終わる文字列。ホストアドレスの最初の数値フィールドが指定したパターンに一致する場合、そのホストアドレスは一致します。たとえば、ワイルドカードパターン 123.45. は、サブネット 123.45.0.0 内のすべてのホストのアドレスに一致します。
n.n.n.n/m.m.m.m 形式の文字列。このワイルドカードパターンは、net/mask のペアと解釈されます。ホストアドレスの net が、アドレスと mask のビット単位の論理積と等しい場合、そのホストアドレスは一致します。たとえば、123.45.67.0/255.255.255.128 というパターンは、123.45.67.0 〜 123.45.67.127 の範囲内のすべてのアドレスに一致します。
アクセス制御システムでは、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)
serviceSpec エントリにサーバーホストの名前またはアドレス情報を含めることで、要求される特定のサービスをフィルタ内で識別することができます。この場合、次の形式でエントリを指定します。
service@hostSpec
この機能は、Messaging Server ホストマシンが、異なるインターネットホスト名を持つ複数のインターネットアドレス用に設定されている場合に有効です。サービスプロバイダの場合、この機能を使用することで、異なるアクセス制御ルールを持つ複数のドメインを 1 つのサーバーインスタンス上でホストできます。
RFC 1413 に記載された identd サービスをサポートするクライアントホストマシンの場合は、フィルタの clientSpec エントリ内にクライアントのユーザー名を含めることにより、サービスを要求している特定のクライアントを識別することができます。この場合、次の形式でエントリを指定します。
user@hostSpec
user は、クライアントの identd サービスによって返されるユーザー名 (またはワイルドカード名) です。
フィルタ内でクライアントユーザー名を指定すると便利ですが、次のことに注意する必要があります。
identd サービスは認証機能ではないため、クライアントシステムが安全性に欠ける場合は、クライアントから返されるクライアントユーザー名を信頼することができません。一般的に、特定のユーザー名を使用せずに、ALL、KNOWN、UNKNOWN などのワイルドカード名だけを使用します。
identd は最新のクライアントマシンではサポートされていないため、最近の導入ではあまり付加価値がありません。将来のバージョンでは identd のサポートを廃止することが検討されているため、今後もこの機能を使う必要がある場合は Sun Java System にお知らせください。
ユーザー名の検索は時間がかかるので、すべてのユーザーについて検索を実行すると、identd をサポートしていないクライアントのアクセスが遅くなる場合があります。ユーザー名の検索を選択的に実行すると、この問題を緩和することができます。たとえば次のように指定します。
serviceList: @xyzcorp.com ALL@ALL
この場合、xyzcorp.com ドメイン内のユーザーは、ユーザー名の検索を実行せずに一致します。ただし、ほかのすべてのシステムについては、ユーザー名の検索が実行されます。
ユーザー名検索の機能は、クライアントホスト上の承認されていないユーザーからの攻撃を防ぐために役立つ場合があります。たとえば、一部の TCP/IP の実装環境では、侵入者が rsh (リモートシェルサービス) を使用して信頼されているクライアントホストになりすます場合があります。クライアントホストが ident サービスをサポートしている場合は、ユーザー名の検索を使用してそのような攻撃を検出できます。