xenial (8) tcpd.8.gz

Provided by: manpages-ja_0.5.0.0.20140515+dfsg-2_all bug

名前

       tcpd - internet services のためのアクセスコントロール機能

説明

       tcpd  プログラムは、telnet, finger, ftp, exec, rsh, rlogin, tftp, talk, comsat や、その他、実行ファイルと
       一対一にマップされたサー ビスに対するリクエストを監視するために設定するものである。

       プログラムは 4.3BSD スタイルの sockets と System V.4 スタイルの TLI の両方をサポートしている。ただし、TLI
       の元にあるプロトコルが インターネットのプロトコルでない場合、機能は制限される可能性があ る。

       その仕組みは次のようになっている: サービスを求めるリクエストが届くと、 inetd デーモンは、要求されたサービ
       スを起動する代わりに、 tcpd に役目を交替する。tcpd はリクエストをログに記録  し、いくつかのチェックを実行
       する。すべてよしとなれば、tcpd は適切なサーバプログラムを起動し、そして姿を消す。

       オプショナルな機能として: パターン形式のアクセスコントロール、 RFC 931 などのプロトコルに基づく、クライア
       ントのユーザ名の探査、 別のホスト名を装っているホストからの防御、そして、別のネットワー  クアドレスを装っ
       ているホストからの防御、などがある。

ログの記録

       tcpd によって監視の対象となる接続は、 syslog(3) 機能を通して報告される。どの記録も、時刻、クライ アントホ
       ストの名前、要求されたサービス名を含んでいる。この情報は、 特にログファイル中に複数のホストの情報が混在し
       ている場合でも、好 ましからざる行動を察知するには有用である。

       あなたのログがどこに記録されるのか調べるためには、syslog  の設定 ファイル (大抵の場合は /etc/syslog.conf)
       を参照すること。

アクセスの制御

       オプションとして、 tcpd は、パターンマッチングに基づくアクセスコントロールのシンプルな書 式をサポートして
       いる。アクセスコントロールのソフトウェアは、パター ンに合致した時に、シェルコマンドを実行するためのフック
       を提供して いる。詳細は hosts_access(5) のマニュアルを参照のこと。

ホスト名の検証

       いくつかのプロトコル (rlogin,  rsh)  の認証の仕組みは、ホス  トの名前に頼っている。ある実装は、ランダムな
       ネームサーバから得  たホスト名を信用するようになっている。別の実装ではもっと注意深い が、欠陥のあるアルゴ
       リズムを使っている。

       tcpd は、アドレス→名前の翻訳を行なう DNS サーバから返答されるクラ イアントのホスト名と、名前→アドレスの翻
       訳を行なう  DNS サーバ から返答されるホスト名とを突き合わせ、確認を行う。何らかの矛盾 が発覚すると、 tcpd
       は、これはどこかよそのホストの名前を偽装しているホストとの取り引           きである、と判定する。ソースが
       -DPARANOID でコンパイルされている なら、 tcpd は、ホスト名/アドレスの不一致がある場合、接続を切断すること
       にな る。さもなくば、しかるべき行動がとられたのちに、ホスト名を PARANOID のワイルドカードにマッチさせるこ
       とができる。

ホストアドレスの詐称

       オプションとして、 tcpd は、取り引きする接続のたびに source-routing socket option を無効 にできる。これに
       よって、よそのネットワークに属するアドレスを偽装 しているホストからの、大抵の攻撃に備えることができるだろ
       う。UDP サービスについては、この防御は役に立たない。この機能については、 コンパイル時に有効になっていなけ
       ればならない。

RFC 931

       RFC 931 などに基づく問い合わせが有効な場合 (これはコンパイル時の オプション設定)、tcpd はクライアントユー
       ザの名前を検証しよ うと試みる。これは、クライアントホストが RFC 931 互換のデーモン を動作させている場合に
       だけ成功する。このクライアントユーザ名の問 い合わせは、データ指向の高いコネクションに対しては機能せず、ま
       た パーソナルシステム(PCs) からの接続の場合は、著しく遅くなるかも知 れない。

       tcpd の利用法の詳細は、コンパイル時にプログラムの中に入れ られた pathname に依存する。

1

       この例では、tcpd は、オリジナルのネットワークデーモンが別 の場所に移動されることを期待している。

       finger  サービスへのアクセスを監視するためには、オリジナル  の  finger デーモンは別の場所へと移動し、元々
       finger デーモンがい た場所には tcpd をインストールする。設定ファイルへの変更は必要な い。

            # mkdir /other/place
            # mv /usr/etc/in.fingerd /other/place
            # cp tcpd /usr/etc/in.fingerd

       この例では、ネットワークデーモンは /usr/etc にあるものとする。シ ステムによっては、ネットワークデーモンは
       /usr/sbin または /usr/libexec に置かれていたり、名前の頭に `in.´ という文字を持っ ていなかったりする。

2

       この例で tcpd は、ネットワークデーモンは、そのオリジナルの 場所に置かれている事を想定している。

       finger  サービスへのアクセスを監視するためには、次に示すよ  うな変更を inetd の設定ファイル (大抵の場合、
       /etc/inetd.conf または /etc/inet/inetd.conf) に対し て行なう:

            finger  stream  tcp  nowait  nobody  /usr/etc/in.fingerd  in.fingerd

       これを次のように:

            finger  stream  tcp  nowait  nobody  /some/where/tcpd     in.fingerd

       この例では、ネットワークデーモンは /usr/etc にあるものとする。シ ステムによっては、ネットワークデーモンは
       /usr/sbin  または /usr/libexec に置かれていたり、名前の頭に `in.´ という文字を持っ ていなかったり、あるい
       は inetd の設定ファイルには userid の項目 が存在しないこともある。

       似たような変更が、tcpd でカバーされるその他のサービスに対  しても必要になるだろう。変更を有効なものとする
       ため、  inetd(8) のプロセスに対して `kill -HUP´ を送出する。AIX のユーザは `inetimp´ コマンドも実行する必
       要があるかもしれない。

3

       デーモンが普通でないディレクトリ("secret"  やその他)に置かれてい   る場合、inetd   の設定ファイルを編集し
       て、プロセス名の項には 絶対パス名で明示するように。例:

           ntalk  dgram  udp  wait  root  /some/where/tcpd  /usr/local/lib/ntalkd

       パス名の一番最後の要素 (ntalkd) だけがアクセスコントロールと、ロ グの記録に使われる。

バグ

       いくつかの  UDP  (そして  RPC)  デーモンは、その仕事が終わって、別の リクエストがやって来ても、しばらくの
       間、名残惜しそうにプロセス空 間をうろついている。これらのサービスは、inetd の設定ファイルの中 で、wait オ
       プションとともに登録されている。このようなデー モンは、それを起動したリクエストだけがログに記録されること
       になる。

       プログラムは、TCP 経由の RPC サービスにおいては動作しない。これ らのサービスは、inetd  の設定ファイルの中
       で、rpc/tcp  として 登録されている。この制限によって影響される唯一特別なサービスは、 on(1) コマンドによっ
       て利用されるrexd     である。しかし、      これは大したロスではない。大抵のシステムにおいて、rexd      は
       /etc/hosts.equiv の中のワイルドカードよりも安全度が低いのだ。

       RPC broadcast リクエスト (例: rwall, rup, rusers) が、応答 のあるホストから常にやってくることがある。クラ
       イアントが、そのネッ トワーク上の全ての portmap デーモンに対してブロードキャス トしている、というのがその
       実態である; どの portmap デーモ ンも、リクエストはローカルのデーモンへと転送する。rwall な どのデーモンが
       知る限り、リクエストはローカルホストから送られてく るのである。

ファイル

       ホストアクセスコントロールテーブル:

       /etc/hosts.allow
       /etc/hosts.deny

関連項目

       hosts_access(5), ホストアクセスコントロールファイルの書式
       syslog.conf(5), syslogd コントロールファイルの書式
       inetd.conf(5), the inetd コントロールファイルの書式

著者

       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>

                                                                                                         TCPD(8)