| TCPD(8) | FreeBSD System Manager's Manual | TCPD(8) |
名前
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