hosts_access

DESCRIPTION

このマニュアルページは、クライアント (ホストネーム/アドレス、ユーザー名) サーバー (プロセス名、ホストネーム/アドレス) 間の単純なアクセス制御の記述法を解説するものである。具体的な設定例は末尾に示すので、てっとりばやい設定を望むせっかちな読者は、"設定例" のセクションへと進んで欲しい。

アクセスコントロール書法の拡張された部分に関しては、 hosts_options(5) の文書で解説する。この拡張は、プログラムが -DPROCESS_OPTIONS を指定して作成されたかどうかに左右される。

以下の文章では、 daemon とはネットワークデーモンのプロセス名を意味し、 client とは、サービスを要求するホストの名前、もしくはホストのアドレスを意味している。ネットワークデーモンのプロセス名は、inetd の設定ファイル中に明示されている。

ACCESS CONTROL FILES

アクセスコントロールのソフトウェアは、二つのファイルを参照する。最初に一致した時点で検索は終了する。

•: (daemon,client) の組合せが /etc/hosts.allow ファイルの中のエントリと一致する場合、アクセスは承諾される。

•: もしくは、(daemon,client) の組合せが /etc/hosts.deny ファイルの中のエントリと一致する場合、アクセスは拒否される。

•: それ以外の場合、アクセスは承諾される。

アクセスコントロールのファイルが存在しない場合は、それらのファイルが空であったとみなされる。したがって、アクセスコントロールは、アクセスコントロールファイルを準備しない事によって停止する事ができる。

ACCESS CONTROL RULES

どちらのアクセスコントロールファイルも、0 行以上のテキストで構成されている。これらの行は出現順に処理される。検索はマッチする行が現れた時点で終了となる。

•: 改行文字は、バックスラッシュが前に置かれた場合は無視される。これによって、楽に編集するために長い行を分割することが許されている。

•: 空行、または `#´ で始まる行は無視される。したがって、コメントを挿入したり、ホワイトスペースを入れて読みやすく整える事が許されている。

•: それ以外の行は、次に示すフォーマットに従わなければならない。ただし [] で囲まれる部分は任意である: daemon_list : client_list [ : shell_command ]

daemon_list は、ひとつ以上のデーモンプロセス名 (argv[0] の値) または、ワイルドカード (後述) を使ったリストである。

client_list は、ひとつ以上の、ホスト名、ホストアドレス、または、ワイルドカード (後述) を使った、クライアントのホスト名かアドレスにマッチするパターンのリストである。

複合化された daemon@host や user@host という形式は、それぞれ SERVER ENDPOINT PATTERNS および CLIENT USERNAME LOOKUP のセクションで解説する。

リストの各要素は空白、またはカンマで分けなければいけない。

NIS (かつての YP) の netgroup 問い合わせという例外を除いては、全てのアクセスコントロールのチェックは大文字小文字を同一視して行なわれる。

PATTERNS

アクセスコントロールの書式は以下のようなパターンを満たすものである。

•: `.' で始まる語。もし、ホスト名の後ろの部分がこの書式で指定されたパターンと一致すると、それはマッチとなる。例えば、`.tue.nl´ というパターンは、`wzv.win.tue.nl´. というホスト名とマッチしている。

•: `.' で終わる語。もし、ホストアドレスの前部の数値フィールドが、この語と一致するなら、それはマッチしている。例えば、`131.155.´ というパターンは、Eindhoven University network (131.155.x.x)に属する (ほぼ)全てのホストのアドレスにマッチしている。

•: `@´ で始まる語は、NIS (かつての YP) のネットグループ名として扱われる。もし、ホストがそこで明示されたネットグループ名のメンバーである場合は一致したものとなる。このネットグループのマッチは、デーモンプロセス名やクライアントユーザー名のためにはサポートされていない。

•: `n.n.n.n/m.m.m.m´ という形式は`net/mask´ の一対として解釈される。ホストアドレスは、`net´ から見て正ビット方向にあり、かつ `mask´ でマスクされた範囲内にある場合に一致する。たとえば、 net/mask が `131.155.72.0/255.255.254.0´となるパターンは、 `131.155.72.0´ から `131.155.73.255´までの範囲にある全てのアドレスにマッチする。

WILDCARDS

アクセスコントロールの書式は、平易なワールドカード群をサポートしている:

ALL: すべてに合致する万能なワイルドカード。

LOCAL: ドット文字を持たない全てのホストにマッチ。

UNKNOWN: 名前の明らかでないユーザーにマッチ。そして名前 または アドレスが不明な全てのホストにマッチ。この形式は注意を持って使用すべきである:ホスト名は、一時的なネームサーバーの問題により、使えない場合がありうる。また、ネットワークアドレスは、ソフトウェアから見て、どんなタイプのネットワークと会話しているのか、特定できない場合は利用できなくなる。

KNOWN: 名前の明らかなユーザーにマッチする。さらに、名前とアドレスの明らかなホストにマッチする。この形式は注意を持って使用すべきである:ホスト名は、一時的なネームサーバーの問題により、使えない場合がありうる。また、ネットワークアドレスは、ソフトウェアから見て、どんなタイプのネットワークと会話しているのか、特定できない場合は利用できなくなる。

PARANOID: 名前とアドレスの一致しない全てのホストにマッチする。もし tcpd が -DPARANOID (これはデフォルトである) で作成されているなら、アクセスコントロールテーブルが参照されるより前に、そのようなクライアントからの要求は落とされてしまう。そのような要求を、さらにコントロールしたい場合は -DPARANOID を外して tcpd を構築する事。

OPERATORS

EXCEPT: 基本的には、次に示すような形式で使用する: `list_1 EXCEPT list_2´;これは list_2 にマッチするものを除く、 list_1 にマッチするもの全て、に合致する。この EXCEPT 演算子は、daemon_lists と client_lists の中でも使用できる。EXCEPT 演算子は、ネスト(入れ子に)して使う事もできる: もしコントロール書式が丸括弧を使う事を許可していたなら、`a EXCEPT b EXCEPT c´は、 `(a EXCEPT (b EXCEPT c))´ と解釈されるであろう。

SHELL COMMANDS

もし、最初にマッチしたアクセスコントロールのルールがシェルコマンドを含んでいるなら、そのコマンドは、%<letter> の置き換え(次のセクションを参照) があると仮定される。その結果、 /bin/sh の子プロセスが標準入力を伴って実行され、出力とエラーは /dev/null へ送られる。もし、そのプロセスが終了するまで待ちたくない場合には、コマンドの末尾に `&´ が明示すること。

シェルコマンドは、inetd の PATH 設定と関連させてはいけない。代わりに絶対パスを用いるか、冒頭で明示的に PATH=whatever を宣言するべきである。

hosts_options(5) の文書では、互換性のない異なる方法でシェルコマンドのフィールドを使うための、もうひとつの書式を解説している。

% EXPANSIONS

シェルコマンドの中では下記の拡張表記が利用できる:

%a (%A): クライアント (サーバー) ホストのアドレス。

%c: クライアントの情報: user@host, user@address. ホスト名か単にアドレスかは、利用できる情報に依存する。

%d: デーモンプロセス名 (argv[0] の値)。

%h (%H): クライアント (サーバー) ホストの名前、もしホスト名が利用できない場合には、そのアドレス。

%n (%N): クライアント (サーバー) ホストの名前 (もしくは、"unknown" あるいは "paranoid")。

%p: デーモンプロセスの id。

%s: サーバーの情報: daemon@host, daemon@address, あるいは単にデーモンの名前。これは利用できる情報に依存する。

%u: クライアントのユーザー名 (もしくは、"unknown")。

%%: 文字 `%´ へ展開される。

% の展開が行なわれることによって、シェルを混乱させる可能性のある文字群は、アンダースコアへと置き換えられる。

SERVER ENDPOINT PATTERNS

接続されているネットワークアドレスによって、クライアントを厳密に区別するためには、以下の形式でパターンを記述する:

process_name@host_pattern : client_list ...

このようなパターンは、マシンが複数の異なるインターネットのホスト名とインターネットのアドレスを持っている場合に使用する。サービスプロバイダは、異なる組織に属するようなインターネット上の名前を持つFTP, GOPHER あるいは WWW を提供するために、この機能を利用できる。hosts_options(5) 文書の中の `twist' のオプションも参照する事。あるシステム (Solaris, FreeBSD) では、ひとつの物理的なインターフェースが、複数のインターネットアドレスを持つ事ができる(それ以外のシステムでは、専用のネットワークアドレス空間にあるSLIP や PPP などの疑似インターフェースの助けを借りなければならないだろう )。

host_pattern は、client_lists の解説文にあった、ホスト名とアドレスのような、いくつかの文法に従うことになる。一般的には、server endpoint information (サーバー側末端での情報)は、 connection-oriented serveices (コネクション指向の高いサービス)でのみ利用する事ができる。

CLIENT USERNAME LOOKUP

クライアントホストが RFC 931 か、そこから派生したプロトコル(TAP, IDENT, RFC 1413) のどれかをサポートしている場合、ラッパープログラムは接続の持ち主に関する、追加の情報を引き出す事が可能である。クライアントユーザー名の情報が利用可能であるなら、それはクライアントのホスト名とともに記録され、次のようなパターンにマッチさせるために使う事ができる:

daemon_list : ... user_pattern@host_pattern ...

デーモンラッパーは、ルールに従う形でユーザー名を探査するように振舞うか(デフォルト)、あるいは常にクライアントホストに問い合わせるのか、コンパイル時に設定可能となっている。ルールに従う形式でユーザー名の探査を行なう場合には、上の記述ルールは daemon_list と host_pattern の両方がマッチした場合にのみ、ユーザー名の探査を行なうであろう。

user_pattern は、デーモンプロセスのパターンと同じ文法であり、すなわち同じワイルドカード群が適用される(ただしネットグループのメンバーシップはサポートされない)。しかしながら、これはユーザー名の探査に独占されるべきではない。

•: クライアントのユーザー名に関する情報は、例えばクライアントシステムが信用するに足りないものとなっている時には、信頼する事はできない。一般的には、ALL と (UN)KNOWN は意味のあるユーザー名のパターンのためにある。

•: ユーザー名の探査は TCP ベースのサービスで、そして、クライアントホストが適切なデーモンを起動している場合にのみ可能である。そして、それ以外のケースは "unknown" の結果を得る事になる。

•: ユーザー名の探査がファイヤーウォールによって阻まれた場合、有名な UNIX カーネルのバグがサービスに損害をもたらすかもしれない。 wrapper の README 文書には、あなたのカーネルに、このバグが存在するかどうかを調べる手順が紹介されている。

•: ユーザー名の探査は、non-UNIX ユーザーに対して行なわれた場合、著しく遅くなるかも知れない。ユーザー名の探査がタイムアウトで終了するまでの既定値は10 秒となっている: これは遅いネットワークにとっては短すぎるが、PC ユーザーをじらすには充分すぎる。

ユーザー名の探査を選択可能とすることにより、最後の問題を軽減することができる。たとえば、こんなルール:

daemon_list : @pcnetgroup ALL@ALL

これはユーザー名の探査を行なわない PC ネットグループのメンバーにもマッチするだろうし、それ以外のシステムに対してはユーザー名の探査を行なうだろう。

DETECTING ADDRESS SPOOFING ATTACKS

多くの TCP/IP の実装に見られる sequence number generator 中の欠陥は、侵入者が信頼できるホストであることを簡単に装い、例えばリモートシェルサービスを通して押し入ることを許してしまう。IDENT (RFC931 ほか) サービスはそのようなホストアドレスのペテンによる攻撃を察知するために使う事ができる。

クライアントの要求に答える前に、TCP ラッパー群は本当のクライアントが実際には全く要求を送って来ていなかったことを発見する目的で、 IDENT サービスを使う事ができる。

クライアントホストが IDENT サービスを用意しているなら、IDENT の問い合わせをして、返って来た結果が否定的(クライアントマシンが `UNKNOWN@host') であれば、それはペテン攻撃の確固たる証拠となる。

肯定的な IDENT の問い合わせ結果 (クライアントマシンは `KNOWN@host')でも、充分に信頼できるとは言い切れない。単にクライアントのコネクションを誤魔化すよりは難しいが、それでも侵入者はクライアントのコネクションと、IDENT の問い合わせの両方を偽っている可能性がある。さらには、クライアントの IDENT サーバーそのものが嘘をついていることさえ考えられる。

Note: IDENT の問い合わせは UDP サービスと共存して動作する事はできない。

EXAMPLES

文法は最小限の苦労で、さまざまなタイプのアクセスコントロールが表現可能な、柔軟なものである。この文法は二つのアクセスコントロールのリストが必要なのだが、身もフタもない方策としては、片方のリストを極めて単純なものとするか、空にしておくことが挙げられる。

以下の記述例を読むにあたっては、allow の記述は deny の記述より先に検索され、その検索は最初にマッチしたもので終了となり、マッチしたものが全く見つからない場合には、アクセスは承認される、ということをはっきりと理解しておくことが重要である。

記述例はホストとドメインの名前を使う。ネームサーバーへの問い合わせが一時的に失敗した場合の影響を軽減するためには、これらにアドレス、かつ、あるいは network/netmask の情報を含めることで、改善する事ができる。

MOSTLY CLOSED (ほぼ閉鎖)

この場合、アクセスはデフォルトで拒絶される。明示的に権限を授けられたホストのみがアクセスを許される。

デフォルトのポリシー(no access)は、単に deny file の中で記述される:

/etc/hosts.deny:
ALL: ALL

これによって、allow file の中のエントリでアクセスが許可されない限り、全てのホストへのサービスは拒否となる。

明示的に権限を授けるホストは、allow file の中でリストされる。記述例:

/etc/hosts.allow:
ALL: LOCAL @some_netgroup

ALL: .foobar.edu EXCEPT terminalserver.foobar.edu

最初のルールでは、ローカルドメイン(ホスト名に `.´を必要としない) と、 some_netgroup に属するホストからのアクセスが許可されている。二番目のルールでは、 terminalserver.foobar.edu. を除く foobar.edu ドメイン(ドットで始まることが宣言されている) の、全てのホストからのアクセスが許可されている。

MOSTLY OPEN (ほぼ解放)

明示的にサービスを拒否するホストを除き、アクセスはデフォルトで許可となる。

デフォルトのポリシー(access granted) に従えば、どんな allow file でも、まったく省略可能なほど冗長なものとなる。明示的に権限を与えないホストは、deny file にリストする。記述例:

/etc/hosts.deny:
ALL: some.host.name, .some.domain

ALL EXCEPT in.fingerd: other.host.name, .other.domain

最初のルールでは、いくつかのホストと、ドメインへの全てのサービスが拒否される。二番目のルールでは、それ以外のホストとドメインからの finger リクエストに限って許可が与えられている。

BOOBY TRAPS (ひっかけ罠)

次のサンプルはローカルドメインのホスト(ドットで始まる事が宣言されている)からの tftp リクエストを許可するものである。それ以外のホストからのリクエストは拒否される。そして要求されたファイルの代わりに、finger の探り針がその無礼なるホストへと放たれる。結果はスーパーユーザーへメイルで送られる。

/etc/hosts.allow:

in.tftpd: LOCAL, .my.domain

/etc/hosts.deny:


in.tftpd: ALL: (/some/where/safe_finger -l @%h | \
	/usr/ucb/mail -s %d-%h root) &

safe_finger コマンドは tcpd wrapper に付属しており、適切な場所にインストールされるべきである。これはリモートの finger サーバーから送られてくるデータによってダメージが与えられる可能性を制限してる。これは標準の finger コマンドよりも優れた防御をもたらす。

%h (client host) と %d (service name) の展開については、shell commands のセクションで解説されている。

警告: finger の無限ループへの対処ができないなら、あなた自身の finger デーモンに対して、この booby-trap (引っかけ罠) を仕掛けない事。

ネットワークファイヤーウォールにおいては、このトリックはさらに大幅に拡張することができる。典型的なネットワークファイヤーウォールは、外部に対して限定されたサービスしか提供しない。それ以外のサービスは、上記の tftp の例のように "盗聴" することができる。その結果、極めて優れた早期警戒装置となる。

DIAGNOSTICS

以下の場合にエラーが報告される。ホストコントロールファイルに文法エラーが見つかった場合。アクセスコントロールのルールの長さが内部のバッファの容量を越えた場合。アクセスコントロールのルールが、改行文字によって終わっていない場合。%<letter> 展開の結果、内部バッファが溢れてしまった場合。期待に反して、システムコールが失敗した場合。すべての問題は、syslog デーモンを通じて報告される。

FILES

/etc/hosts.allow, アクセスを許可する (daemon,client) のペア。
/etc/hosts.deny, アクセスを拒否する (daemon,client) のペア。

BUGS

ネームサーバーの問い合わせがタイムアウトとなると、ホスト名は、たとえ登録されていても、アクセスコントロールソフトからは利用できない。

ドメインネームサーバーの問い合わせは、大文字小文字を同一視する。一方 NIS (かつての YP) のネットグループは、大文字小文字を区別する。

AUTHOR

Wietse Venema ([email protected])
Department of Mathematics and Computing Science
Eindhoven University of Technology
Den Dolech 2, P.O. Box 513, 
5600 MB Eindhoven, The Netherlands

翻訳者

FUKUSHIMA Osamu/福島於修 <[email protected]>