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

NAME

       hosts_access - ホストアクセスコントロールファイルの書式

DESCRIPTION

       このマニュアルページは、クライアント       (ホストネーム/アドレス、ユー
       ザー名)   サーバー    (プロセス名、ホストネーム/アドレス)    間の単純な
       アクセス制御の欺卷,魏鮴發垢襪發里任△襦6饌療な設定例は末尾に
       示すので、てっとりばやい設定を望むせっかちな読者は、"設定例"         の
       セクションへと進んで欲しい。

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

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

ACCESS CONTROL FILES

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

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

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

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

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

ACCESS CONTROL RULES

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

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

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

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

                 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

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

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

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

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

       o      `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
              名前の明らかでないユーザーにマッチ。そして名前    __

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

       o      クライアントのユーザー名に関する情報は、例えばクライアントシステ
              ムが信用するに造蠅覆い發里箸覆辰討い觧には、信頼する事はでい
              い。一般的には、ALL  と (UN)KNOWN は意味のあるユーザー名のパター
              ンのためにある。

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

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

       o      ユーザー名の探査は、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')でも、充分に信頼でい襪箸聾世だ擇譴覆ぁC韻縫ライ
       アントのコネクションを誤魔化すよりは難しいが、それでも侵入者はク
       ライアントのコネクションと、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 (引っかけ罠) を仕掛けな い事。

       ネットワークファイヤーウォールにおいては、このトリックはさらに大
       幅に拡張することがでい襦E儀薪なネットワークファイヤーウォール
       は、外部に対して限定されたサービスしか提供しない。それ以外のサー
       ビスは、上気   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)