TCPD(8)

FreeBSD System Manager's Manual

TCPD(8)

名称

tcpd -インターネットサービスのためのアクセスコントロール (制御) 機能

解説

tcpd プログラムは、実行可能なファイルで 1 対 1 でマップされている telnet、 finger、 ftp、 exec、 rsh、 rlogin、 tftp、 talk、 comsat と他のサービスのために着信するリクエストをモニタするためにセットアップすることができます。

プログラムは 4.3BSD スタイルソケットおよび System V.4 スタイル TLI の両方をサポートします。プロトコル下部 TLI がインターネットプロトコルでない場合、機能性は制限されているかもしれません。

操作 (オペレーション) は次のとおりです。サービスのリクエストが到着する場合は常に、 inetd デーモンはだまされて希望のサーバの代わりに tcpd プログラムを実行します。 tcpd はリクエストをログに記録し、いくつかの追加のチェックを行います。すべてがうまくいく場合、 tcpd は適切なサーバプログラムを実行し消え去ります。

オプションの特徴は、パターンに基づいたアクセスコントロール、 RFC 931 その他のプロトコルでクライアントユーザ名の検索、誰か他の人のホスト名を持つように偽るホストからの保護、誰か他の人のネットワークアドレスを持つように偽るホストからの保護、です。

ロギング

tcpd によってモニタされる接続は syslog(3) 機能を介して報告されます。各レコードはタイムスタンプ、クライアントホスト名および要求されたサービスの名前を含んでいますす。特にいくつかのホストからの logfile 情報が併合される場合、情報は望まれない活動を検知するのに便利になりえます。

利用者のログがどこに出力されるか知るためには、通常 /etc/syslog.conf である、syslog 設定ファイルを調べてください。

アクセスコントロール

オプションで、 tcpd は、パターンマッチングに基づくアクセスコントロールの単純な形式をサポートします。アクセスコントロールソフトウェアは、パターンが発火する時、shell (シェル) コマンドの実行のホック (仕掛け) を供給します。詳細に関しては、 hosts_access(5) マニュアルページを参照してください。

ホスト名の検証

いくつかのプロトコル ( rlogin, rsh) の認証スキームはホスト名に依存します。いくつかの実装は、それらが任意のランダムネームサーバから取得するホスト名を信じます。他の実装はより注意深いが、欠陥のあるアルゴリズムを使用します。

tcpd は、ホスト名を検索することによってアドレス->名前 DNS サーバによって返されるクライアントホスト名と、名前->アドレス DNS サーバによって返されるアドレスを検証します。不一致が検知される場合、 tcpd はそれが誰か他のホスト名を持つように偽るホストで処理していると結論を出します。

ソースが -DPARANOID でコンパイルされる場合、 tcpd はホスト名/アドレス不一致の場合の接続を中断します。そうでなければ、ホスト名は、適切な処置が取られた後に PARANOID ワイルドカードと一致させることができます。

ホスト名のなりすまし (スプーフイング)

オプションで、 tcpd は、それを処理するすべての接続でソースルーティングソケットオプションを不能にします。これは、誰か他の人のネットワークを所有しているアドレスを持つように偽るホストからほとんどの攻撃を処理して片付けます。 UDP サービスはこの保護からの利点はありません。この特徴はコンパイル時にオンにしなければなりません。

RFC 931

RFC 931 その他の検索が (コンパイル時オプションで) 可能になった場合、 tcpd は、クライアントユーザの名前を確立することを試みるでしょう。クライアントホストが RFC 931-規格デーモンを実行する場合のみ、これは成功します。クライアントユーザ名の検索はデータグラム指向の接続では働かず、 PC からの接続の場合で顕著な遅れを生じるかもしれません。

使用例

tcpd の使用の詳細は、プログラムの中へコンパイルされたパスネーム情報に依存します。

使用例 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

("秘密"または別の) 共通のディレクトリに生きていないデーモンの場合には、それがプロセス名フィールドの絶対的なパス名を指定するように、 inetd 設定ファイルを編集します。例えば:

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

パスネームの最後の構成要素 (ntalkd) だけがアクセスコントロールとログの記録のために使用されます。

バグ

いくつかの UDP (と RPC) デーモンは、別のリクエストが到着する場合、仕事を終了した後、しばらくの間居座ります。 inetd 設定ファイルでは、これらのサービスは wait オプションで登録されます。そのようなデーモンを始めたリクエストだけがログに記録されます。

プログラムは TCP オーバ RPC サービスで働きません。これらのサービスは inetd 設定ファイルで rpc/tcp として登録されます。この制限によって影響される唯一の重要なサービスは rexd です。それは on(1) で使用されます。これは大損失ではありません。ほとんどのシステムにおいては、 rexd は、 /etc/hosts.equiv の中のワイルドカードほど安全ではありません。

RPC ブロードキャストリクエスト (例えば: rwall, rup, rusers) は、常に応答ホストから来るように見えます。何が起こるかは、クライアントがそのネットワーク上のすべての portmap デーモンへのリクエストをブロードキャストすることです。各 portmap デーモンはローカルデーモンへリクエストを転送します。 rwall その他のデーモンが知っている限り、リクエストはローカルホストから来ます。

作者

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

YOS OPENSONAR

名称

解説