manual/tcp_wrappers/release/man8/tcpd.8

   1 .TH TCPD 8
   2 .SH 名前
   3 tcpd \- internet services のためのアクセスコントロール機能
   4 .SH 説明
   5 .PP
   6 \fItcpd\fR プログラムは、\fItelnet\fR, \fIfinger\fR, \fIftp\fR,
   7 \fIexec\fR, \fIrsh\fR, \fIrlogin\fR, \fItftp\fR, \fItalk\fR,
   8 \fIcomsat\fR や、その他、実行ファイルと一対一にマップされたサー
   9 ビスに対するリクエストを監視するために設定するものである。
  10 .PP
  11 プログラムは 4.3BSD スタイルの sockets と System V.4 スタイルの
  12 TLI の両方をサポートしている。ただし、TLI の元にあるプロトコルが
  13 インターネットのプロトコルでない場合、機能は制限される可能性があ
  14 る。
  15 .PP
  16 その仕組みは次のようになっている: サービスを求めるリクエストが届くと、
  17 \fIinetd\fP デーモンは、要求されたサービスを起動する代わりに、
  18 \fItcpd\fP に役目を交替する。\fItcpd\fP はリクエストをログに記録
  19 し、いくつかのチェックを実行する。すべてよしとなれば、\fItcpd\fP
  20 は適切なサーバプログラムを起動し、そして姿を消す。
  21 .PP
  22 オプショナルな機能として: パターン形式のアクセスコントロール、
  23 RFC 931 などのプロトコルに基づく、クライアントのユーザ名の探査、
  24 別のホスト名を装っているホストからの防御、そして、別のネットワー
  25 クアドレスを装っているホストからの防御、などがある。
  26 .SH ログの記録
  27 .I tcpd によって監視の対象となる接続は、
  28 \fIsyslog\fR(3) 機能を通して報告される。どの記録も、時刻、クライ
  29 アントホストの名前、要求されたサービス名を含んでいる。この情報は、
  30 特にログファイル中に複数のホストの情報が混在している場合でも、好
  31 ましからざる行動を察知するには有用である。
  32 .PP
  33 あなたのログがどこに記録されるのか調べるためには、syslog の設定
  34 ファイル (大抵の場合は /etc/syslog.conf) を参照すること。
  35 .SH アクセスの制御
  36 オプションとして、
  37 .I tcpd
  38 は、パターンマッチングに基づくアクセスコントロールのシンプルな書
  39 式をサポートしている。アクセスコントロールのソフトウェアは、パター
  40 ンに合致した時に、シェルコマンドを実行するためのフックを提供して
  41 いる。詳細は \fIhosts_access\fR(5) のマニュアルを参照のこと。
  42 .SH ホスト名の検証
  43 いくつかのプロトコル (\fIrlogin, rsh\fR) の認証の仕組みは、ホス
  44 トの名前に頼っている。ある実装は、ランダムなネームサーバから得
  45 たホスト名を信用するようになっている。別の実装ではもっと注意深い
  46 が、欠陥のあるアルゴリズムを使っている。
  47 .PP
  48 .I tcpd
  49 は、アドレス→名前の翻訳を行なう DNS サーバから返答されるクラ
  50 イアントのホスト名と、名前→アドレスの翻訳を行なう DNS サーバ
  51 から返答されるホスト名とを突き合わせ、確認を行う。何らかの矛盾
  52 が発覚すると、
  53 .I tcpd
  54 は、これはどこかよそのホストの名前を偽装しているホストとの取り引
  55 きである、と判定する。ソースが -DPARANOID でコンパイルされている
  56 なら、
  57 .I tcpd
  58 は、ホスト名/アドレスの不一致がある場合、接続を切断することにな
  59 る。さもなくば、しかるべき行動がとられたのちに、ホスト名を
  60 \fIPARANOID\fR のワイルドカードにマッチさせることができる。
  61 .SH ホストアドレスの詐称
  62 オプションとして、
  63 .I tcpd
  64 は、取り引きする接続のたびに source-routing socket option を無効
  65 にできる。これによって、よそのネットワークに属するアドレスを偽装
  66 しているホストからの、大抵の攻撃に備えることができるだろう。UDP
  67 サービスについては、この防御は役に立たない。この機能については、
  68 コンパイル時に有効になっていなければならない。
  69 .SH RFC 931
  70 RFC 931 などに基づく問い合わせが有効な場合 (これはコンパイル時の
  71 オプション設定)、\fItcpd\fR はクライアントユーザの名前を検証しよ
  72 うと試みる。これは、クライアントホストが RFC 931 互換のデーモン
  73 を動作させている場合にだけ成功する。このクライアントユーザ名の問
  74 い合わせは、データ指向の高いコネクションに対しては機能せず、また
  75 パーソナルシステム(PCs) からの接続の場合は、著しく遅くなるかも知
  76 れない。
  77 .SH 例
  78 \fItcpd\fR の利用法の詳細は、コンパイル時にプログラムの中に入れ
  79 られた pathname に依存する。
  80 .SH 例 1
  81 この例では、\fItcpd\fR は、オリジナルのネットワークデーモンが別
  82 の場所に移動されることを期待している。
  83 .PP
  84 \fIfinger\fR サービスへのアクセスを監視するためには、オリジナル
  85 の finger デーモンは別の場所へと移動し、元々 finger デーモンがい
  86 た場所には tcpd をインストールする。設定ファイルへの変更は必要な
  87 い。
  88 .nf
  89 .sp
  90 .in +5
  91 # mkdir /other/place
  92 # mv /usr/etc/in.fingerd /other/place
  93 # cp tcpd /usr/etc/in.fingerd
  94 .fi
  95 .PP
  96 この例では、ネットワークデーモンは /usr/etc にあるものとする。シ
  97 ステムによっては、ネットワークデーモンは /usr/sbin または
  98 /usr/libexec に置かれていたり、名前の頭に `in.\' という文字を持っ
  99 ていなかったりする。
 100 .SH 例 2
 101 この例で \fItcpd\fR は、ネットワークデーモンは、そのオリジナルの
 102 場所に置かれている事を想定している。
 103 .PP
 104 \fIfinger\fR サービスへのアクセスを監視するためには、次に示すよ
 105 うな変更を \fIinetd\fR の設定ファイル (大抵の場合、
 106 \fI/etc/inetd.conf\fR または \fI/etc/inet/inetd.conf\fR) に対し
 107 て行なう:
 108 .nf
 109 .sp
 110 .ti +5
 111 finger  stream  tcp  nowait  nobody  /usr/etc/in.fingerd  in.fingerd
 112 .sp
 113 これを次のように:
 114 .sp
 115 .ti +5
 116 finger  stream  tcp  nowait  nobody  /some/where/tcpd     in.fingerd
 117 .sp
 118 .fi
 119 .PP
 120 この例では、ネットワークデーモンは /usr/etc にあるものとする。シ
 121 ステムによっては、ネットワークデーモンは /usr/sbin または
 122 /usr/libexec に置かれていたり、名前の頭に `in.\' という文字を持っ
 123 ていなかったり、あるいは inetd の設定ファイルには userid の項目
 124 が存在しないこともある。
 125 .PP
 126 似たような変更が、\fItcpd\fR でカバーされるその他のサービスに対
 127 しても必要になるだろう。変更を有効なものとするため、
 128 \fIinetd\fR(8) のプロセスに対して `kill -HUP\' を送出する。AIX
 129 のユーザは `inetimp\' コマンドも実行する必要があるかもしれない。
 130 .SH 例 3
 131 デーモンが普通でないディレクトリ("secret" やその他)に置かれてい
 132 る場合、\fIinetd\fR の設定ファイルを編集して、プロセス名の項には
 133 絶対パス名で明示するように。例:
 134 .nf
 135 .sp
 136     ntalk  dgram  udp  wait  root  /some/where/tcpd  /usr/local/lib/ntalkd
 137 .sp
 138 .fi
 139 .PP
 140 パス名の一番最後の要素 (ntalkd) だけがアクセスコントロールと、ロ
 141 グの記録に使われる。
 142 .SH バグ
 143 いくつかの UDP (そして RPC) デーモンは、その仕事が終わって、別の
 144 リクエストがやって来ても、しばらくの間、名残惜しそうにプロセス空
 145 間をうろついている。これらのサービスは、inetd の設定ファイルの中
 146 で、\fIwait\fR オプションとともに登録されている。このようなデー
 147 モンは、それを起動したリクエストだけがログに記録されることになる。
 148 .PP
 149 プログラムは、TCP 経由の RPC サービスにおいては動作しない。これ
 150 らのサービスは、inetd の設定ファイルの中で、\fIrpc/tcp\fR として
 151 登録されている。この制限によって影響される唯一特別なサービスは、
 152 \fIon(1)\fR コマンドによって利用される\fIrexd\fR である。しかし、
 153 これは大したロスではない。大抵のシステムにおいて、\fIrexd\fR は
 154 /etc/hosts.equiv の中のワイルドカードよりも安全度が低いのだ。
 155 .PP
 156 RPC broadcast リクエスト (例: \fIrwall, rup, rusers\fR) が、応答
 157 のあるホストから常にやってくることがある。クライアントが、そのネッ
 158 トワーク上の全ての \fIportmap\fR デーモンに対してブロードキャス
 159 トしている、というのがその実態である; どの \fIportmap\fR デーモ
 160 ンも、リクエストはローカルのデーモンへと転送する。\fIrwall\fR な
 161 どのデーモンが知る限り、リクエストはローカルホストから送られてく
 162 るのである。
 163 .SH ファイル
 164 .PP
 165 ホストアクセスコントロールテーブル:
 166 .PP
 167 /etc/hosts.allow
 168 .br
 169 /etc/hosts.deny
 170 .SH 関連項目
 171 .na
 172 .nf
 173 hosts_access(5), ホストアクセスコントロールファイルの書式
 174 syslog.conf(5), syslogd コントロールファイルの書式
 175 inetd.conf(5), the inetd コントロールファイルの書式
 176 .SH 著者
 177 .na
 178 .nf
 179 Wietse Venema (wietse@wzv.win.tue.nl),
 180 Department of Mathematics and Computing Science,
 181 Eindhoven University of Technology
 182 Den Dolech 2, P.O. Box 513,
 183 5600 MB Eindhoven, The Netherlands
 184 .SH 翻訳
 185 FUKUSHIMA Osamu <fuku@amorph.rim.or.jp>
 186
 187 \" @(#) tcpd.8 1.5 96/02/21 16:39:16
 188 .\" -----------------------------------------------------------------------
 189 .\" Translation of tcpd.8
 190 .\" Japanese Version Copyright (c) 1997 FUKUSHIMA Osamu
 191 .\"         all rights reserved.
 192 .\" Translated: Sat Feb 12  10:00:00 1997 GMT
 193 .\"         by FUKUSHIMA Osamu <fuku@amorph.rim.or.jp>
 194 .\" -----------------------------------------------------------------------