Provided by: manpages-ja_0.5.0.0.20110915-1_all bug

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@hostuser@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_listhost_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)