File: tcpd.8

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

\" @(#) tcpd.8 1.5 96/02/21 16:39:16
.\" -----------------------------------------------------------------------
.\" Translation of tcpd.8
.\" Japanese Version Copyright (c) 1997 FUKUSHIMA Osamu
.\"         all rights reserved.
.\" Translated: Sat Feb 12  10:00:00 1997 GMT
.\"         by FUKUSHIMA Osamu <fuku@amorph.rim.or.jp>
.\" -----------------------------------------------------------------------