NAME

       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) のペア。

SEE ALSO

       tcpd(8) tcp/ip daemon wrapper プログラム
       tcpdchk(8), tcpdmatch(8), test programs.

BUGS

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

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

AUTHOR

       Wietse Venema (wietse@wzv.win.tue.nl)
       Department of Mathematics and Computing Science
       Eindhoven University of Technology
       Den Dolech 2, P.O. Box 513,
       5600 MB Eindhoven, The Netherlands

翻訳者

       FUKUSHIMA Osamu/福島於修 <fuku@amorph.rim.or.jp>

                                                                                                 HOSTS_ACCESS(5)