名前

       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)