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
などに基づく問い合わせが有効な場合
(これはコンパイル時の
オプション設定)、
tcpd
はクライアントユーザの名前を検証しよ
うと試みる。これは、クライアントホストが
RFC 931 互換のデーモン
を動作させている場合にだけ成功する。このクライアントユーザ名の問
い合わせは、データ指向の高いコネクションに対しては機能せず、また
パーソナルシステム(PCs)
からの接続の場合は、著しく遅くなるかも知
れない。
tcpd
の利用法の詳細は、コンパイル時にプログラムの中に入れ
られた pathname
に依存する。
この例では、
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.´ という文字を持っ
ていなかったりする。
この例で
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´
コマンドも実行する必要があるかもしれない。
デーモンが普通でないディレクトリ("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 ([email protected]),
Department of Mathematics and Computing Science,
Eindhoven University of Technology
Den Dolech 2, P.O. Box 513,
5600 MB Eindhoven, The Netherlands
FUKUSHIMA Osamu <
[email protected]>