| HOSTS_ACCESS(5) | File Formats Manual | HOSTS_ACCESS(5) |
hosts_access - ホストアクセスコントロールファイルの書式
このマニュアルページは、クライアント (ホストネーム/アドレス、ユー ザー名) サーバー (プロセス名、ホストネーム/アドレス) 間の単純な アクセス制御の記述法を解説するものである。具体的な設定例は末尾に 示すので、てっとりばやい設定を望むせっかちな読者は、"設定例" の セクションへと進んで欲しい。
アクセスコントロール書法の拡張された部分に関しては、 hosts_options(5) の文書で解説する。この拡張は、プログラム が -DPROCESS_OPTIONS を指定して作成されたかどうかに左右される。
以下の文章では、daemon とはネットワークデーモンのプロセス 名を意味し、client とは、サービスを要求するホストの名前、 もしくはホストのアドレスを意味している。ネットワークデーモンのプ ロセス名は、inetd の設定ファイル中に明示されている。
アクセスコントロールのソフトウェアは、二つのファイルを参照する。 最初に一致した時点で検索は終了する。
アクセスコントロールのファイルが存在しない場合は、それらのファイ ルが空であったとみなされる。したがって、アクセスコントロールは、 アクセスコントロールファイルを準備しない事によって停止する事がで きる。
どちらのアクセスコントロールファイルも、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 問い合わせという例外を除いては、 全てのアクセスコントロールのチェックは大文字小文字を同一視して行 なわれる。
アクセスコントロールの書式は以下のようなパターンを満たすものであ る。
アクセスコントロールの書式は、平易なワールドカード群をサポートし ている:
この形式は注意を持って使用すべきである:ホスト名は、一時的なネー ムサーバーの問題により、使えない場合がありうる。また、ネットワー クアドレスは、ソフトウェアから見て、どんなタイプのネットワークと 会話しているのか、特定できない場合は利用できなくなる。
この形式は注意を持って使用すべきである:ホスト名は、一時的なネー ムサーバーの問題により、使えない場合がありうる。また、ネットワー クアドレスは、ソフトウェアから見て、どんなタイプのネットワークと 会話しているのか、特定できない場合は利用できなくなる。
もし、最初にマッチしたアクセスコントロールのルールがシェルコマン ドを含んでいるなら、そのコマンドは、%<letter> の置き換え(次のセ クションを参照) があると仮定される。その結果、/bin/sh の子 プロセスが標準入力を伴って実行され、出力とエラーは /dev/null へ送られる。もし、そのプロセスが終了するまで待ち たくない場合には、コマンドの末尾に `&´ が明示すること。
シェルコマンドは、inetd の PATH 設定と関連させてはいけない。代わ りに絶対パスを用いるか、冒頭で明示的に PATH=whatever を宣言する べきである。
hosts_options(5) の文書では、互換性のない異なる方法でシェ ルコマンドのフィールドを使うための、もうひとつの書式を解説してい る。
シェルコマンドの中では下記の拡張表記が利用できる:
% の展開が行なわれることによって、シェルを混乱させる可能性のある 文字群は、アンダースコアへと置き換えられる。
接続されているネットワークアドレスによって、クライアントを厳密に 区別するためには、以下の形式でパターンを記述する:
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 (コネクション指向の高いサービス)で のみ利用する事ができる。
クライアントホストが RFC 931 か、そこから派生したプロトコル(TAP, IDENT, RFC 1413) のどれかをサポートしている場合、ラッパープログ ラムは接続の持ち主に関する、追加の情報を引き出す事が可能である。 クライアントユーザー名の情報が利用可能であるなら、それはクライア ントのホスト名とともに記録され、次のようなパターンにマッチさせる ために使う事ができる:
daemon_list : ... user_pattern@host_pattern ...
デーモンラッパーは、ルールに従う形でユーザー名を探査するように振 舞うか(デフォルト)、あるいは常にクライアントホストに問い合わせる のか、コンパイル時に設定可能となっている。ルールに従う形式でユー ザー名の探査を行なう場合には、上の記述ルールは daemon_list と host_pattern の両方がマッチした場合にのみ、ユーザー名の 探査を行なうであろう。
user_pattern は、デーモンプロセスのパターンと同じ文法であり、す なわち同じワイルドカード群が適用される(ただしネットグループのメ ンバーシップはサポートされない)。しかしながら、これはユーザー名 の探査に独占されるべきではない。
ユーザー名の探査を選択可能とすることにより、最後の問題を軽減する ことができる。たとえば、こんなルール:
daemon_list : @pcnetgroup ALL@ALL
これはユーザー名の探査を行なわない PC ネットグループのメンバーに もマッチするだろうし、それ以外のシステムに対してはユーザー名の探 査を行なうだろう。
多くの TCP/IP の実装に見られる sequence number generator 中の欠 陥は、侵入者が信頼できるホストであることを簡単に装い、例えばリモー トシェルサービスを通して押し入ることを許してしまう。IDENT (RFC931 ほか) サービスはそのようなホストアドレスのペテンによる攻 撃を察知するために使う事ができる。
クライアントの要求に答える前に、TCP ラッパー群は本当のクライアン トが実際には全く要求を送って来ていなかったことを発見する目的で、 IDENT サービスを使う事ができる。
クライアントホストが IDENT サービスを用意しているなら、IDENT の 問い合わせをして、返って来た結果が否定的(クライアントマシンが `UNKNOWN@host') であれば、それはペテン攻撃の確固たる証拠となる。
肯定的な IDENT の問い合わせ結果 (クライアントマシンは `KNOWN@host')でも、充分に信頼できるとは言い切れない。単にクライ アントのコネクションを誤魔化すよりは難しいが、それでも侵入者はク ライアントのコネクションと、IDENT の問い合わせの両方を偽っている 可能性がある。さらには、クライアントの IDENT サーバーそのものが 嘘をついていることさえ考えられる。
Note: IDENT の問い合わせは UDP サービスと共存して動作する事はできない。
文法は最小限の苦労で、さまざまなタイプのアクセスコントロールが表 現可能な、柔軟なものである。この文法は二つのアクセスコントロール のリストが必要なのだが、身もフタもない方策としては、片方のリスト を極めて単純なものとするか、空にしておくことが挙げられる。
以下の記述例を読むにあたっては、allow の記述は deny の記述より先 に検索され、その検索は最初にマッチしたもので終了となり、マッチし たものが全く見つからない場合には、アクセスは承認される、というこ とをはっきりと理解しておくことが重要である。
記述例はホストとドメインの名前を使う。ネームサーバーへの問い合わ せが一時的に失敗した場合の影響を軽減するためには、これらにアドレ ス、かつ、あるいは network/netmask の情報を含めることで、改善す る事ができる。
この場合、アクセスはデフォルトで拒絶される。明示的に権限を授けら れたホストのみがアクセスを許される。
デフォルトのポリシー(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 ドメイン(ドットで始まることが宣言されている) の、全てのホストからのアクセスが許可されている。
明示的にサービスを拒否するホストを除き、アクセスはデフォルトで許 可となる。
デフォルトのポリシー(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 リクエストに限って許可が与えられている。
次のサンプルはローカルドメインのホスト(ドットで始まる事が宣言さ れている)からの 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
の例のように
"盗聴"
することができる。その結
果、極めて優れた早期警戒装置となる。
以下の場合にエラーが報告される。ホストコントロールファイルに文法 エラーが見つかった場合。アクセスコントロールのルールの長さが内部 のバッファの容量を越えた場合。アクセスコントロールのルールが、改 行文字によって終わっていない場合。%<letter> 展開の結果、内部バッ ファが溢れてしまった場合。期待に反して、システムコールが失敗した 場合。すべての問題は、syslog デーモンを通じて報告される。
/etc/hosts.allow, アクセスを許可する (daemon,client) のペア。 /etc/hosts.deny, アクセスを拒否する (daemon,client) のペア。
tcpd(8) tcp/ip daemon wrapper プログラム tcpdchk(8), tcpdmatch(8), test programs.
ネームサーバーの問い合わせがタイムアウトとなると、ホスト名は、た とえ登録されていても、アクセスコントロールソフトからは利用できな い。
ドメインネームサーバーの問い合わせは、大文字小文字を同一視する。 一方 NIS (かつての YP) のネットグループは、大文字小文字を区別す る。
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>