目次

3.1 − How it works（作動方法）
3.2 − Where the logging information goes（ログを取った情報の行方）

4.1 − Access control（アクセスコントロ−ル）
4.2 − Host name spoofing（偽造ホスト名）
4.3 − Host address spoofing（偽造ホストアドレス）
4.4 − Client username lookups（クライアントユ−ザ−名ルックアップ）
4.5 − Language extensions（言語拡張）
4.6 − Multiple ftp/gopher/www archives on one host（1ホスト上の多数のftp/gopher/www記録保管場所）
4.7 − Banner messages（バ−ナ−メッセ−ジ）
4.8 − Sequence number guessing（シ−ケンスナンバ−の推測）

5.1 − Related documents（ドキュメント関連）
5.2 − Related software（ソフトウェア関連）

6.1 − Known wrapper limitations（既知のラッパ−制限）
6.2 − Known system software bugs（既知のシステムソフトウェアバグ）

7.1 − Easy configuration and installation（初級編）
7.2 − Advanced configuration and installation（上級編）
7.3 − Daemons with arbitrary path names（任意のパス名を備えたデ−モン）
7.4 − Building and testing the access control rules（アクセスコントロ−ルの構築とテスト）
7.5 − Other applications（他のアプリケ−ション）

1 − Introduction（説明）

このパッケ−ジでは、SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, 
TFTP, TALKや他のネットワ−クサ−ビスのリクエストをいち早く見ること
ができます。 
これは、4.3BSDスタイルソケットとシステムV.4スタイルTLIの両方をサポ
−トします。もしあなたがこれがどういう意味だか分からないのなら、あな
たは幸運な自分自身を誉めてあげてください。
このパッケ−ジは小さなデ−モンラッパ−プログラムを提供します。これは、
ソフトウェアやコンフィギュレーションファイルの変更無しにインスト−
ルすることができます。ラッパ−はクライアントホストやリクエストサ−ビ
スの名前を記憶します。
ラッパ−はクライアントやサ−バ−アプリケ−ションと情報を交換しませ
ん。また、クライアントおよびサ−バ−アプリケ−ション間の実際の通信で
オ−バ−ヘッドを押し付けません。
オプションとして：どのようなシステムがどのようなネットワ−クデ−モン
と接続出来るかを制限するアクセス制御装置：ユ−ザ−名をRFC 931 etc.プ
ロトコ−ルで探す：他の人のホスト名の真似をしたホストに対する追加の防
御：他の人のホストアドレスの真似をしたホストに対する追加の防御。
このプログラムはとてもポ−タブルです。構成手続きはたくさんの共通（共
通でないものもある）の環境が提供されています。そして、ガイドラインは
あなたの環境がそうではない場合提供されます。
必要条件として、ネットワ−クデ−モンは4.3BSDスタイルソッケットプロ
グラミングインタ−フェイスやシステムV.4スタイルTLIプログラミングイ
ンタ−フェイスのようなス−パ−サ−バ−にによって大量に発生されてい
ます。そして、syslog(3)ライブラリやsyslogd(8)デ−モンの利用度によります。
ラッパ−はそれらの要求を満足させるシステムの修正なしに実行すべきで
す。回避策はシステムソフトウェア中のいくつかの共通のバグ用に実装され
ています。

ラッパ−プログラムを初めて行う場合、あなたのすべきことは、 １） tutorial sections（目次３）のコンセプトや専門用語の手引きを読んで ください。 ２） この書類のsecurityに関する所をちらっと見てください。 ３） 装置の使用説明書（初級編か応用編）に従ってください。 あなたは初めにセキュリティ−の特徴のセッティングにデフォルトを使用 する事を勧めます。アクセスを切断したり、booby traps（まぬけなトラップ） をインスト−ルするような強烈なことをしてしまう前に、まずラッパ−に慣 れるようにそのログで2、3日実行してみて下さい。

2 − Disclaimer（断り書き）

ラッパ−プログラムはネットワ−クパッケ−ジから得たソ−スアドレス情
報によります。この情報はクライアントホストによって提供されます。ラッ
パ−は偽造の発見に最善をつくしますが、それは100％信じられるものでは
有りません。
メッセ−ジ内容の暗号保護、メッセ−ジ発信者の暗号認証がないので、ネッ
トワ−クからの全てのデ−タは正常な懐疑で処理されることになります。
この制限は決してTCP/IP PROTOCOLS特有ではありません。

3 − Tutorials（チュ−トリアル）

このセクションではラッパ−プログラムのオペレ−ションについての一般 的な説明をいたします。そして、ドキュメントの残余の中で使用された専門 用語（client, server, inetdやsyslogd daemons,それとそのコンフィギュレー ションファイル）のいくつかの紹介もします。

3.1 − How it works（作動方法）

ほとんど全てのTCP/IPプロトコ−ルのアプリケ−ションはクライアントサ
−バ−モデルに基づいています。例えば、ユ−ザ−があなたのシステムの一
つに接続するためのテルネットコマンドを起動した時、テルネットサ−バ−
プロセスはタ−ゲットホストの上で実行されます。テルネットサ−バ−プロ
セスはログインプロセスをユ−ザ−と接続します。クライアントやサ−バ−
プログラムのいくつかの例を下記の表で御見せしましょう。

              client   server    application
              −−−−−−−−−−−−−−−
              telnet   telnetd   remote login
              ftp      ftpd      file transfer
              finger   fingerd   show users

通常のアプロ−チとは入ってくるネットワ−ク接続のすべての種類を待っ
て一つのシングルデ−モンプロセスを実行することです。接続が確立される
場合は常に、このデ−モン（通常inetdと呼ぶ）は適切なサ−バ−プログラム
を実行し、他の接続を待って休止します。
ラッパ−プログラムはシンプルかつ強力メカニズムを目指しています。要求
したサ−バ−プログラムが実行しているディレクトリの代りに、inetdは騙さ
れてスモ−ルラッパ−プログラムを実行させられています。ラッパ−はクラ
イアントホスト名或いはアドレスをログし、いくつかの追加事項のチェック
を実行します。全てがうまく行った時にラッパ−は要求したサ−バ−プログ
ラムを実行して消えます。
ラッパ−プログラムはクライアントユ−ザ−（或いはクライアントプロセ
ス）との相互作用はありません。そしてまたラッパ−はサ−バ−アプリケ−
ションとも相互に作用しません。これには、二つの重要な利点が有ります。

1）ラッパ−はアプリケ−ションが独立していること。よって、同じプログ
ラムはネットワ−クサ−ビスの沢山の種類の中から防御出来る。2）相互作
用は更にラッパ−が外部から（少なくとも指定されたユ−ザ−の為に）非可
視であると言うこともまた意味のないことである。
別の重要なプロパティはクライアントとサ−バ−間の初期の接触が確立さ
れる場合に限り、ラッパ−プログラムはアクティブになります。一度ラッパ
−プログラムがその作業を行ったならば、クライアントサ−バ−の通信上に
オ−バ−ヘッドはありません。
シンプルメカニズムは重要な欠点が一つあります。ラッパ−はクライアント
とサ−バ−プロセス間の初期接続の後、終わって消えます。したがって、ラ
ッパ−は、2つ以上のクライアントをサ−ビスするネットワ−クデ−モンで
役に立ちます。ラッパ−は最初にこのようなサ−バ−と接続を試したクライ
アントにだけ見えるでしょう。
NFSマウントデ−モンは多様なクライアントからのサ−ビスリクエストの
デ−モンの典型です。そのようなサ−バ−プログラムを処理する方法のソフ
トウェアに関する項目を参照してください。
ラッパ−プログラムを使用するには二つの方法があります。

1)初級編：ネットワ−クデ−モンを他のディレクトリ−に移し、ラッパ−
プログラムのコピ−でその生じた穴を埋めてください。このアプロ−チは
システムコンフィギュレーションファイルへの変更を含んでいません。し
たがって、現状を壊す危険はほとんどありません。

2）応用編：ネットワ−クデ−モンをそのままにして、inetdコンフィギュ
レーションファイルを修正してください。例えば次のようなエントリ−、

     tftp  dgram  udp  wait  root  /usr/etc/tcpd  in.tftpd −s /tftpboot

Tftpリクエストが届いた時に、inetdはラッパ−プログラム（tcpd）はプロセ
ス名`in.tftpd'で実行します。これは、ラッパ−がリクエストを記憶するとき、
そしてオプションのアクセスコントロ−ルテ−ブルを細かく調べる時に使
用する名前です。`in.tftpd'はまた、全ての状態が良い時に、ラッパ−が実行
を試すサ−バ−プログラムの名前でもあります。いくらかのア−ギュメント
（`−s /tftpboot'は特別なたとえ）は、サ−バ−プログラムへ移動するのは明
らかです。
ラッパ−プログラムの入力コマンドの経歴のアカウントの為の、日常的なた
とえはドキュメントに関するものの次の項目をご覧ください。

3.2 − Where the logging information goes（ログを取った情報の行方）

ラッパ−プログラムは記録された情報をシスログデ−モン(syslogd)に送りま
す。このラッパ−ログの性質はシスログコンフィギュレーションファイル 
(通常 /etc/syslog.conf) によって限定されます。メッセ−ジはファイル、制御
装置に書かれるか、あるいは、@loghostに転送されます。いくつかのsyslogd
バ−ジョンはパイプラインの下へメッセ−ジを転送することもできます。 
旧syslogsの実装（Ultrixシステムがまだ基礎になっている）は9（デバグ−
レベルメッセ−ジ）から0（警戒）までの優先レベルの並びをサポ−トする
だけです。優先レベルの全ての記録された情報、あるいは、もっと緊急事態
については、同じ目的で書かれています。syslog.confファイルの中の、優先
レベルはニュ−メリックフォ−ムで明記されています。例えば、

    8/usr/spool/mqueue/syslog

優先度8（情報のメッセ−ジ）との全てのメッセ−ジの為、そしてもっと緊
急事態の何かの為、 file/usr/spool/mqueue/ syslogに追加されます。
新シスログの実装は優先レベルを追加したメッセ−ジクラスをサポ−トし
ます。メッセ−ジクラスの例は、mail, daemon, auth, newsです。syslog.conf
ファイルの中で、優先レベルはシンボル名（debug, info, notice, ..., emerg）で
明記されます。
例えば、
    mail.debug                  /var/log/syslog

優先デバッグ（或いはもっと緊急）とのクラスメ−ルの全てのメッセ−ジが、
/var/log/syslogファイルに追加するため。
デファルトによって、ラッパ−ログは送信メ−ルデ−モンの処理ログと同じ
所にいきます。この性質は、Makefileと／や syslog.confファイルの編集によ
って変えられることができます。`kill −HUP' をコンフィギュレーションフ
ァイルに変更した後にsyslogdに送って下さい。syslogdを思い出してくださ
い。それは送信メ−ルのようなもの、そのコンフィギュレーションファイル
のleft−handとright−handの一つかそれ以上のTABsを主張するものなのです。

4 − Features（特徴）

4.1 − Access control（アクセスコントロ−ル）

DHOSTS_ACCESSを編集する時、ラッパ−プログラムはアクロスコントロ
−ルのシンプルフォ−ムをサポ−トします。アクセスはそれぞれのホスト、
サ−ビス、これらに結合するものをコントロ−ルすることができます。ソフ
トウェア−はアクセスがル−ルファイヤ−をコントロ−ルする時シェルコ
マンドの制作のためのフックを条件とします。この特徴は"booby traps"をイ
ンスト−ルすることに慣れています。詳細は、hosts_access.5マニュアルペ−
ジを参照してください。これは`nroff −man'フォ−マットの中にあります。
後の章にあなたのアクセスコントロ−ルル−ルのテストの方法が記述され
ています。
Access control can also be used to connect clients to the "right"
service. What is right may depend on the requested service, the origin
of the request, and what host address the client connects to. Examples:
アクセスコントロ−ルはクライアントと "right"サ−ビス接続にも使用する
ことができます。 rightとは何か？それはリクエストサ−ビスに依るもので
あり、リクエストそのものであり、クライアントのホストアドレスと接続す
る何かです。
例えば、

(1)gopherやwwwデ−タベ−スが国内、もしくは英語圏のどこかからつな
がる時、その国の言葉で話すこと。

(2) サ−ビスプロバイダ−が一つのホスト(section 4.6)から違ったインタ−
ネットホスト名で、違ったftpやgopher或いはwwwサ−ビスを提供すること。

アクセスコントロ−ルはデファルトによって機能状態になります。それはメ
イクファイルの編集によって、或いはコントロ−ルテ−ブルにアクセスしな
いことを条件に、消すことが可能です。インスト−ルの説明はメイクファイ
ル編集プロセスの下を参照してください。
hosts_options.5マニュアルペ−ジ(`nroff −man' フォ−マット)はアクセスコ
ントロ−ルの言語の拡張バ−ジョンをドキュメント化しました。拡張機能は
デファルトによって不機能状態になります。 language extensions（4.5）の下
の項目を参照してください。

後のシステムＶの実装はトランスポ−トレベルインタ−フェ−ス(TLI)、バ−
クレ−ソケットプログラミングインタ−フェ−スに似ている機能を実行す
るネットワ−クプログラミングインタ−フェ−スを提供します。バ−クレ−
ソケットに類似して、TLIはインタ−ネットではなく、多様なプルトコ−ル
のカバ−としてデザインされました。
ラッパ−はTLIインタ−フェ−スがTCP/IPやUDP/IP通信のトップにあるこ
とを発見した時に、従来のソケットベ−スアプリケ−ションのような同じ機
能を提供するという情報を使用します。他のいくつかのプロトコ−ルがTLI
の下で使用される時、ホストアドレスは、アクセスコントロ−ル目的には恐
らく適さないユニバ−サルマジッククッキ−（普遍的不思議なクッキ−）に
なるでしょう。

4.2 − Host name spoofing（偽造ホスト名）

いくつかのネットワ−クアプリケ−ションと、RSHやRLOGINの様なものと、
クライアントホスト名は認証プロセスに重要な役割を果たします。もしクラ
イアントIPアドレスを信頼することができれば、ルックアップが_local_ hosts
テ−ブルから行われた場合、ホスト名情報は確実になります。
_distributed_ nameサ−ビスで、ホスト名による認証概要はより問題になりま
す。あなたのシステムのセキュリティ−は今、あなた自身のコントロ−ルの
外側の far−away DNS（領域名サ−バ−）にかかっています。
ラッパ−プログラムはaddress−>name DNSサ−バ−によって、また次の見解
によって、戻ってくるクライアントホスト名を証明します。この目的の為に、
プログラムはthe name−>address DNSサ−バ−（恐らくこれは全く異なった
ホスト）によって戻ってきた名前とアドレスを考察します。
もし、いくつかの名前やアドレスの相違が発覚した場合、或いは次のDNS
オピニオンが使用不可能な場合、ラッパ−は実在する二つのネ−ムサ−バ−
の内の一つが実在すると仮定するか、またはクライアントホストが他の誰か
のホスト名を持つふりをすると仮定します。
DPARANOIDをコンパイルしたときに、ラッパ−はルックアップとクライア
ントホスト名を再確認することを常に試みるでしょう。そしていつも、ホス
ト名やアドレスが食い違う場合には、サ−ビスを拒否します。これは、多く
のシステムの為の適切なポリシ−です。
DPARANOIDなしにコンパイルしたときに、デファルトによるラッパ−はさ
らにホスト名のルックアップを実行します。あなたはホストをPARANOID
ワイルドカ−ド、名前／アドレスの相違と整合できます。そしてサ−ビスを
するかどうかを決定してください。

自動ホスト名の照合はデファルトによって可能になりました。自動ホスト名
ルックアップと照合はMakefileの編集によって消すことができます。構成と
インスト−ルの項目は、Makefileの編集プロセスの下を参照してください。

4.3 − Host address spoofing（偽造ホストアドレス）

偽造のホスト名はその次の見解を求めることによって見つけ出すことが出
来る一方、他の誰かのネットワ−クアドレスを持つことを要求するホストを
見つけ出すことはとても困難なことです。そしてホスト名はネットワ−クア
ドレスから推測されて以来、アドレスを偽造することは少なくとも名前を偽
造する事と同じくらい有効なことです。

ラッパ−プログラムは自分のネットワ−ク外にアドレスを持つことを要求
するホストに対して、追加の防御を与えることができます。例えば、いくつ
かのfar−awayホストはあなたのネットワ−ク内の信頼されたホストである
ことを要求するホストです。このような事は偽造システムが立ち上がって実
行している間もまた可能です。

この追加防御は私の発明ではありません。それはBSD rshとrloginデ−モン
の中に少なくとも5年は存在しています。あいにく、この特徴は*after* 4.3 
BSDが出て追加されました。もしあるのなら希に、UNIX vendorsはそれを選
んでいるでしょう。我々サイト、そして沢山の他の人は、悪い影響無しで、
数年間デ−モンの向上に努めています。

プログラムを−DKILL_IP_OPTIONSとコンパイルする時に、ソ−スル−ティ
ングは、ラッパ−プログラムによって操作されるすべてのTCP接続ができな
くなるでしょう。
あなたが、SunOS 4.1.xでこの特徴を使用する場合、パッチ100804−03+か、
SunOSバ−ジョンによる101790−何かを作動させるはずです。そうでなけれ
ば、TCP RESETが受理された後、getsockopt()システムコ−ルが実行される
場合、"BAD TRAP" や "Data fault"パニックを経験するのも良いでしょう。
これは、カ−ネルバグで、ラッパ−の欠陥ではありません。
この特徴は、デファルトによって不機能状態になります。それは、メイクフ
ァイルの編集によって起動できます。この構成とインスト−ルセクションは
メイクファイル編集プロセスの下を参照してください。
UDPサ−ビスはこの追加防御からは役に立ちません。UDPと、あなたが確
信できる全ては、ネットワ−クパケットの目的アドレスです。

4.4 − Client username lookups（クライアントユ−ザ−名ルックアップ）

RFC 931に提案されたプロトコ−ルはクライアントホストからクライアント
ユ−ザ名を得る手段を提供します。必要条件はクライアントホストが
RFC931用デ−モンを実行することです。そのようなデ−モンによって提供
される情報は、認証目的に使用されることはありません。しかし、それはTCP
接続の所有者に関する補足情報を提供することができます。
RFC 931プロトコ−ルは異なった使用説明(IDENT,TAP, RFC 1413)の中へ分
けました。混乱状態に追加すること、それは全て同じネットワ−クポ−トを
使用します。このデ−モンラッパ−はプロトコ−ルの共通の部分集合を実装
します。 

いくつかの制限があります。RFC931（あるいはコンパチ式）デ−モンを実
行するホストの数は、制限されています（しかし増大する）。クライアント
ユ−ザ−名ルックアップはdatagram (UDP)サ−ビスの為には動きません。も
っと重要なことに、クライアントユ−ザ−名ルックアップは、UNIX PCsで
はないものからの接続は遅れの原因となることがあります。最近のPCソフ
トウェアはこれ（例えばNCSA telnet）が固定されているようです。ラッパ
−は遅いネットワ−クや遅いホストを適用させるRFC931ルックアップの為
10秒の時間制限を用いています。

デファルトによって、アクセスコントロ−ルル−ルがそのように（user@host
クライアントパタ−ンによって〈hosts_access.5マニュアルペ−ジを参照〉）
行うことをそれらに要求した場合に限り、あるいはユ−ザ−名が %<letter> 
拡張に必要な場合、ラッパ−はユ−ザ−名ルックアップを行うでしょう。
クライアントユ−ザ−名ルックアップを常に実行するために、メイクファイ
ルの編集によって、ラッパ−を形成することができます。クライアントユ−
ザ−ネ−ムの時間制限（10秒デファルト）はメイクファイルの編集によって
変更することができます。インスト−ルの項目はMakefile編集プロセスの後
に記述してあります。
TLI−basedネットワ−クサ−ビスとのシステムV上において、クライアント
ユ−ザ−名ルックアップは基本ネットワ−クプロトコ−ルがTCP/IPの場合
のみ可能となるでしょう。

4.5 − Language extensions（言語拡張）

ラッパ−は特徴の制限のある数だけをスポ−ツします。これは以下の通り十
分な理由のためであります。高い特権レベルで実行するプログラムを確認す
ることは容易であるに違いありません。そしてより小さなプログラムは、確
認することはより簡単です。しかしながら、特徴を加える為の準備が必要で
す。

options.cモジュ−ルは言語の拡張の為の枠組みを提供します。かなり多数の
拡張は既に実行されています。それは、hosts_options.5ドキュメント（これ
は`nroff −man'フォ−マットの中）でドキュメントされています。例えば、
サ−ビスの要請がどれかをログされる厳しさレベルの変更、"allow" や 
"deny" キ−ワ−ド、標準なものの代りに特注したサ−バ−を実行する、他、
沢山のことが有ります。
言語の拡張はデファルトによってでは可能にはなりません。なぜなら、それ
らはアクセスコントロ−ル言語シンタックスに非互換性の変更を導入する
からです。拡張を可能にするための指示はMakefileの中を参照してください。

4.6 − Multiple ftp/gopher/www archives on one host

多数のインタ−ネットアドレスを持つ１つのホストを想像してみてくださ
い。これらのアドレスは同じインタ−ネットホスト名を持つ必要はありませ
ん。したがって、たった一つのホストから異なるインタ−ネットホスト名を
備えたサ−ビスを提示することは可能です。

サ−ビスプロバイダ−は、それらの構成がインタ−ネットに全く接続されな
い場合にでも、構成に自分のインタ−ネットホスト名を用いて“net”上の存
在を提示するために、これを使用することができます。エンドユ−ザへ、ア
プリケ−ションがインタ−ネットホスト名を使用するので、それは相違なく
作ります。
１台のマシ−ンに多数のアドレスを割り当てるいくつかの方法があります。
よい方法は、既存のネットワ−クインタ−フェ−スをとり、 `ifconfig' コマ
ンドで付加的なインタ−ネットアドレスを割り当てることです。

例：
    Solaris 2:	ifconfig le0:1 <address> netmask <mask> up
    4.4 BSD:	ifconfig en0 alias <address> netmask <mask>

他のシステムにおいて、それはネットワ−クインタ−フェ−スの数を増加さ
せなければなりません。ハ−ドウェアインタ−フェ−ス、あるいはSLIPま
たは PPPに類似した仮のインタ−フェ−スでのいずれかでです。インタ−
フェイスを何にでも付ける必要はありません。それはただ、起動させる事や、
適切なインタ−ネットアドレスやマスクを割り当てることが必要です。
ラッパ−ソフトウェアで、`daemon@host' アクセスコントロ−ルパタ−ンは
それらが目的とするネットワ−クアドレスによってリクエストを識別する
ために、使用することができます。`twist' オプション（`nroff −man' format
のhosts_options.5 file参照)の賢明な利用法は正しいサ−バ−にリクエストを
ガイドすることができます。
これらは個別のchroot areasで生きているサ−バ−であり、或いはコマンドラ
インからの補足情況やコンビネ−ションをとるための修正済のサ−バ−で
あります。

別の方法は、それらが単に特定の１つのネットワ−クアドレスへ結び付ける
為に、gopherや www listenersを修正することです。並んで実行する時、多数
のgopherや wwwサ−バ−はそれぞれのネットワ−クアドレスへ送られたリ
クエストをそれぞれ取る事が出来ます。

4.7 − Banner messages（バ−ナ−メッセ−ジ）

いくつかのサイトはそれらがログインを試す前に、ユ−ザへ情報のメッセ−
ジを提示することが要求されます。拒否しているサ−ビスの場合、バ−ナ−
メッセ−ジはさらに役に立つでしょう。それは接続を単に落とす代りに、最
初に丁寧な説明が得られることです。最終的に、バ−ナ−はあなたのシステ
ムにより個人のタッチを与えるために使用することができます。
ラッパ−ソフトウェアはシングルプロトタイプバ−ナ−テキストファイル
から ftp, telnet, rloginなどのためのpre−loginバ−ナ−を生成する為のeasy
−to−useツ−ルを提供します。バ−ナ−やon−the−fly %<letter>拡張の詳細
はhosts_options.5マニュアルペ−ジ(`nroff −man' format)にあります。例は、
Banners.Makefileの中にあります。
バ−ナ−メッセ−ジをサポ−トするために、ラッパ−は可能な言語拡張で構
築しなければなりません。言語拡張についてのセクションを参照して下さい。

4.8 − Sequence number guessing（シ−ケンスナンバ−の推測）

最近、システムは、TCP/IPシ−ケンスナンバ−ジェネレイタ−内のよく知ら れた弱点を開発したイントル−ダ−（侵入者）からの攻撃を受けました。こ の弱点は、侵入者が信頼あるホストに扮することを可能にします。Break−ins はrshサ−ビスによって報告されました。実際、いくつかのネットワ−クサ −ビスは、クライアントホスト名あるいはアドレスの信頼を開発する事は可 能です。 長期的な解決は、クライアントホスト名あるいはアドレスを信頼するネット ワ−クサ−ビスの使用をやめて、デ−タ暗号化を代わりに使用することです。 短期的な解決は、 in CERT advisory CA−95:01のなかの要点を述べるとして、 それらが、"inside"ソ−スアドレスと"outside"からデ−タグラムを捨てる為の ネットワ−クル−タ−を構成することです。あなたのロ−カルネットワ−ク 外のいかなるホストも信頼しない場合、このアプロ−チは最も有益でありま す。 IDENT (RFC931 etc.)クライアントユ−ザ−名ルックアッププロトコ−ルは、 ホスト偽造攻撃の発見の手助けが出来ます。クライアントリクエストを受け る前に、ラッパ−はクライアントのIDENTサ−バ−を疑うことができ、クラ イアントがそのリクエストを送信しなかったことを知ることができます。 クライアントホストがIDENTサ−ビスを提供する場合、消極的なIDENTル ックアップの結果（クライアントは`UNKNOWN@host'と一致する）は、ホス ト偽造攻撃を示す強い証拠であります。 積極的なIDENTルックアップの結果（クライアントは`KNOWN@host'と一致 する）は、より少ない信頼でしかありません。それは、クライアントリクエ スト或いはIDENTルックアップ接続の両方をだます攻撃者にとって可能な ことです。そのように行うことは単なるクライアントのリクエストをだます ことよりもより困難であるに違いありません。他の可能性としてはクライア ントのIDENTサ−バ−を設置することです。 クライアントユ−ザ−名ルックアップは、前の項目にもっと詳しく記述され ています。IDENTデ−モンソフトウェアのポイントはソフトウェアに関する 項目に記述されています。

5 − Other works（その他の作動）

5.1 − Related documents（ドキュメント関連）

tcpラッパ−ツ−ルの背後のワ−スト−リ−（対戦話）は次に記述してあり
ます。

    W.Z. Venema, "TCP WRAPPER, network monitoring, access control and
    booby traps", UNIX Security Symposium III Proceedings (Baltimore),
    September 1992. 
    ftp.win.tue.nl:/pub/security/tcp_wrapper.ps.Z (postscript)
    ftp.win.tue.nl:/pub/security/tcp_wrapper.txt.Z (flat text)

同じクラッカ−もまた下記の通り：
    W.R. Cheswick, "An Evening with Berferd, In Which a Cracker is
    Lured, Endured, and Studied", Proceedings of the Winter USENIX
    Conference (San Francisco), January 1992.
    research.att.com:/dist/internet_security/berferd.ps

レタ−ペイパ− に現れたものの最近のバ−ジョンは：
    W.R. Cheswick, S.M. Bellovin, "Firewalls and Internet Security",
    Addison−Wesley, 1994.

インタ−ネットファイヤ−ウォ−ルのディスカッションはftp greatcircle com
に記憶されます。下記アドレスに送られたメッセ−ジによりメ−ルリストに
記述（署名）をします。
    majordomo@greatcircle.com
ボディ−（主ではない）の中で、つまり、ファイヤ−ウォ−ルに署名するこ
と。

5.2 − Related software（ソフトウェア関連）

ネットワ−クデ−モンなどは増強され記憶された能力で莫大な量の情報を
生成することができます。我々の150+ workstationsは一日に数百kbytesを生
成します。egrep−basedフィルタ−は、雑音を少しを抑えることができます。
より強力なツ−ルはStephen E. HansenとE. Todd Atkinsによる、Swatch 
monitoring systemです。Swatchはリアルタイムでログファイルをプロセスで
き、そしてパタ−ンに任意のアクションを関連させることができます。その
アプリケ−ションはセキュリティ−を制限することは全くありません。

Swatchはsierra.stanford.edu, directory /pub/sourcesから利用することが出来ます。
ソックス、UNIX Security III proceedingsで記述したことは、ファイア−ウォ−
ルホストによって外部の世界へ、内部ネットワ−ク上のホストからのネット
ワ−クの往来を制御するために、使用することができます。デ−モンから成
るソックスは、ファイア−ウォ−ルホスト上で実行するデ−モンと、ファイ
ア−ウォ−ルデ−モンによってリディレクトアプリケ−ションソケットコ
−ルのル−チンから成ります。ソックスは/pub/firewalls/socks.tar.Zの中の
s1.gov から利用可能です。

Ying−Da Lee (ylee@syl.dl.nec.com)によるSocksバ−ジョンの修正のため
ftp.nec.com, directory /pub/security/socks.cstc.を試して下さい。 
Tcprは、Paul Ziembaによるperlスクリプトのセットです。それはファイア−
ウォ−ルと交差するftpやテルネットコマンドを実行することを可能にしま
す。ソックスと異なり、それは未修正のクライアントソフトウェアと共に使
用することができます。それは、ftp.alantec.com, /pub/tcprから利用出来ます。
TISファイア−ウォ−ルツ−ルキットはあなたのインタ−ネットファイア−
ウォ−ルシステム ftp.tis.com, directory /pub/firewalls.の構築のツ−ルの多くを
提供します。

Rshdやrlogindヴァ−ジョンは、クライアントホスト名に加えてクライアン
トユ−ザ名を報告するために修正され、また匿名の
ftp(ftp.win.tue.nl:/pub/security/logdaemon−XX.tar.Z)で手に入ります。これらの
プログラムはSunOS 4.x, Ultrix 4.x, SunOS 5.xや HP−UX9.x.の為の交換所
です。この記録保管所はさらにS/Key１回のパスワ−ド、およびUNIXの再
使用可能なパスワ−ドの両方を支援するftpd/rexecd/login versionsを含んでい
ます。

William LeFebvreによるライブラリを共有したsecurelibは、ネットワ−クデ
−モンへのアクセスを制御するために使用することができます。それはinetd
のコントロ−ルの下では実行せず、または機械が落ちるまで実行するNFS
マウントデ−モンのような、一つのクライアントよりもっと貢献します。そ
れは、eecs.nwu.edu, file /pub/securelib.tar.から利用出来ます。
xinetd ( comp.sources.unixに記入されたもの)は、特に提供するinetdの置換え、
logging、ユ−ザ−名ルックアップ、アクセスコントロ−ルです。しかしなが
ら、それはシステムV TLIサ−ビスをサポ−トせず、デ−モンラッパ−プロ
グラムより非常に多くのソ−スコ−ドを含んでいます。
Texas A&Mからのnetlogは、the SunOS 4.x /dev/nitインタ−フェ−スに、ネ
ットワ−ク上全てのTCPとUDPネットワ−クトラフィックの消極的なウォ
ッチを依存します。最近のバ−ジョンは/pub/security/TAMU.の中の
net.tamu.eduです。

共有されたライブラリ、あるいはrouter−basedパケットをフィルタリングす
ることがオプションでない場合、代りのポ−トマップデ−モンは、ハッカ−
が代理RPC設備を使用して、あなたのNFSファイルシステムをマウントす
るのを妨げることを促進することができます。
ftp.win.tue.nl:/pub/security/portmap-X.shar.ZはSunOS 4.1.X Ultrix 3.0とUltrix 
4.xやHP−UX 8.xやAIXのいくつかのヴァ−ジョンをテストさせました。ポ
−トマップがほとんど辞書サ−ビスなので、保護は、securelibライブラリの
それほど役には立ちません。
rpcbind置換(ポ−トマップの同価値のSolaris 2.xモラル)はftp.win.tue.nl in 
/pub/security上で見つけることができます。それは、代理RPC設備の使用に
よって、ハッカ−があなたのNFSファイルシステムをマウントするのを防ぎ
ます。

Peter Erikssonによるポ−タブルRFC 931 (TAP, IDENT, RFC 1413)デ−モンの
ソ−スはftp.lysator.liu.se:/pub/ident/serversから利用することができます。
いくつかのTCP/IP実装はsyslogライブラリなしで入ってきます。若干はラ
イブラリに付属しますが、syslogデ−モンは持っていません。置換えは、
ftp.win.tue.nl:/pub/security/surrogate-syslog.tar.Zで見つけることが出来ます。
nntpソ−スに伝えられる所によれば、付属するfakesyslogライブラリもまた
うまく行くでしょう。

6 − Limitations（制限）

6.1 − Known wrapper limitations（既知のラッパ−制限）

他のリクエストが入るといけないので、リクエストをサ−ビスした後、多く
のUDP (及び rpc/udp)デ−モンはしばらくその中で残っています。inetdコン
フィギュレーションファイルではこれらのデ−モンは`wait'オプションで登
録されます。そのようなデ−モンを始めたリクエストだけがラッパ−によっ
て参照されるでしょう。そのようなデ−モンはsecurelibに共有されたライブ
ラリ（Related software参照）でよりよく保護されます。

ラッパ−は、TCPを超えるRPCサ−ビスでは作動しません。このサ−ビス
は、inetdコンフィギュレーションファイル中のrpc/tcpとして登録されます。
この制限がrexdであることによって影響される些細なことではない唯一のサ
−ビスは(1)コマンドによって使用されます。これは大きなロスではあるませ
ん。多くのシステム上で、rexdは/etc/hosts.equiv上でワイルドカ−ドよりも決
して安全ではないのです。

いくつかのRPCリクエスト（例えば：rwall, rup, rusers）は、サ−バ−ホスト
から来る為に現れます。そのネットワ−ク上で全てのportmapデ−モンへの
リクエストをクライアントがいっせいに送信したら、何が起こるのでしょう。
それぞれのportmapデ−モンは自分のシステム上のデ−モンへのリクエスト
を転送します。rwall etcの範囲の限りです。デ−モンはリクエストがロ−カ
ルホストから来ることを見分けます。
セキュリティ−の中のPortmapとRPC (例えばNISとNFS)はそれ自体がトピ
ックです。ソフトウエアに関するこのドキュメントの中の項目を参照してく
ださい。

6.2 − Known system software bugs（既知のシステムソフトウェアバグ）

回避策は、システムソフトウェア中のいくつかのバグの為に実装されました。
それは Makefileに記述されています。あいにく、いくつかのシステムソフト
ウェアバグはまわりに動かすことができません。機能性の損失がその結果で
す。

IRIXはREADME.IRIX fileにとても沢山のバグを持っています。
旧ConvexOS バ−ジョンは壊れたrecvfrom(2)の実装に付属します。
これは、UDPリクエストの場合に、デ−モンラッパ−が、クライアントホス
トアドレスを調べることを不可能にします。パッチはConvexOS 10.1に利用
可能で、後の解放も恐らくOKでしょう。

初期の Solaris (SunOS 5)バ−ジョンで、logged−inユ−ザに手紙を書いた場
合、 syslogデ−モンはゾンビプロセスの後ろに残るでしょう。回避策は、ユ
−ザにロギングするためのsyslogdの入り口を増加させるか、あるいはラッ
パ−のロギングの厳しさを緩和させて下さい。
いくつかのシステム、オプションのRFC 931等で、クライアントユ−ザ−名
ルックアップがカ−ネルバグを引き起こすかもしれません。クライアントホ
ストがあなたのシステムに接続する、またRFC 931があなたのシステムから
ル−タによって拒絶されたクライアントへ接続される場合、あなたのカ−ネ
ルはそのクライアントとの全ての接続が落ちる可能性が有ります。これはラ
ッパ−プログラム中のバグではありません。すなわちベンダ−に苦情を言い、
バグが正常に戻るまで、クライアントユ−ザ名ルックアップを機能状態には
しません。

聞くところによれば、SunOS 4.1.1やNext 2.0a、TCP 1.3とのISC 3.0とAIX 
3.2.2と後はOKです

Sony News/OS 4.51とHP−UX 8−何とかとUltrix 4.3はまだバグを持ってい
ます。聞くところによるとUltrixへの不正行為は可能(CXO−8919)です。
次の手続きは（tue.nl domainの外側から）あなたのカ−ネルがバグをもって
いる場合に、それを見つけ出すために使用することができます。テスト済み
のシステムから、やって見てください

        % ftp 131.155.70.19

このコマンドは、我々のanonymous ftp server (ftp.win.tue.nl))へftp接続を試し
てみてください。接続が確立された場合、ftp接続を開いた状態の間、テスト
済みの同じシステムからの下記コマンドを実行して下さい。

        % telnet 131.155.70.19 111

コマンドの最後の `111' を忘れないでください。このtelnetコマンドは我々
のportmapプロセスとの接続を試みます。telnetコマンドは"host not reachable"
やその手の何かとでは恐らく失敗（欠乏）するでしょう。あなたのftp接続
がめちゃくちゃになったら、あなたはバグを持っています。telnetコマンド
が失敗（欠乏）でないなら、出来るだけ早く私に知らせてください。 
注意をする人用へ、バグは、入ってくるICMP UNREACHABLEコントロ−
ルメッセ−ジ（それはlocalとremote port numbersを無視した、そしてそれ故
に *all*のリモ−トシステムとの接続を殺す）と十分な注意のないBSDカ−
ネルコ−ドです。バグは、BSD NET/1ソ−スリリ−ス(1989年)の中にまだ存
在しますが、どうもBSD NET/2 (1991年)で元の状態にに戻ったらしい。

7 − Configuration and installation（構成とインスト−ル）

7.1 − Easy configuration and installation（初級編）

"easy" recipe（簡単な方法）は既存のソフトウェアやコンフィギュレーション
ファイルへの変更なしを要求します。基本的に、異なるディレクトリ−に保
護したいデ−モンを移動させて、生じる穴にラッパ−プログラムのコピ−で
栓をしてください。
Ultrixを実行しなければ、miscdラッパ−プログラムを必要としないでしょう。
miscdデ−モンはSYSTATサ−ビス（それはWHOコマンドと同じ出力を生
産する）を共通して実装します。

`make'のタイプと説明書に続きます。Makefileは、多くの共通のＵＮＩＸ実装
(sun, ultrix, hp−ux, aix, irix,...)のためのready−to−useテンプレ−トに付属し
ます。

IRIXはREADME.IRIX fileの中にとても沢山のバグを持っています。
`make'が結果に続く時、5つの実行可能なものがあります。（ Ultrixの場合
は6つ）

あなたのラッパ−およびintendコンフィギュレーションファイルの中の最も
一般的な問題を識別するために、`tcpdchk'プログラムを使用することが出来
ます。
`tcpdmatch'プログラムで、あなたはラッパ−がサ−ビスの特定のリクエスト
にどのように反応するかを検査することができます。
Booby trapsを実装する場合、 `safe_finger'コマンドは使用されるべきです。そ
れは、リモ−トホストがあなたのフィンガ−調査に応じて行ってもよいと言
う邪魔物に対する良い保護を与えます。
`try−from'プログラムはホストおよびユ−ザ−名ルックアップコ−ドをテス
トします。リモ−トシェルコマンド(`rsh host /some/where/try−from')からそれ
を実行し、そしてそれはコ−ルされるどんなシステムからも解くことが可能
でしょう。

tcpdプログラムはtelnet, finger, ftp, exec, rsh, rlogin, tftp, talk, comsatと他のtcp
或いはudpサ−ビスをモニタ−するために、使用することができます。そし
てそれには実行可能なファイル上に１対１の写像があります。

さらに tcpdプログラムはinetdコンフィギュレーションファイル中のrpc/udp
として特徴づけられたサ−ビスを使用することが出来ます。しかしrexdのよ
うなrpc/tcpサ−ビスではありません。とにかくあなたはrexdを実行したくは
ないと思います。ほとんどのシステム上で、それは/etc/hosts.equivの中のワ
イルドカ−ドよりさらに安全性は少ないのです。

システムV.4−styleシステムと、tcpdプログラムはさらにTLIサ−ビスを扱
うことができます。TCP/IPまたはUDP/IPがTLIの下で使用される場合、tcpd
はソケットベ−スアプリケ−ションのような同じ機能を提供します。他のい
くつかのプロトコ−ルはTLIの下で使用される場合、機能（クライアントユ
−ザ−名ルックアップなし、奇妙なネットワ−クアドレスフォ−マット）は
制限されるでしょう。

モニタ−にどのサ−ビスを望むか決定してください。Makefile中で一定の
REAL_DAEMON_DIRによって指定された位置にvendor−providedデ−モンプ
ログラムに対応するものを移動させ、そしてtcpdプログラムのコピ−で穴を
埋めてください。すなわちあなたがモニタ−に望む各サ−ビスのためのtcpd
プログラムの一つのコピ−（あるいはリンク）です。例えば、あなたのフィ
ンガ−サ−ビスの使用をモニタ−するために、

    # mkdir REAL_DAEMON_DIR
    # mv /usr/etc/in.fingerd REAL_DAEMON_DIR
    # cp tcpd /usr/etc/in.fingerd

この例はSunOS 4に当てはまります。ネットワ−クデ−モンの他のUNIX実
装で、ネットワ−クデ−モンはin /usr/libexecや/usr/sbinもしくは in /etc、或
いはそれらの名前に"in."を前置しないものに存在します。しかし、あなたは
アイデアをゲットします。
ファイル保護：ラッパ−、ラッパ−によって使用されるすべてのファイル、
およびパスの通るそれらのファイルのすべてのディレクトリ−は、アクセス
可能でしょう。しかし特許されていないユ−ザ(mode755或いはmode555)への
書き込みは可能ではありません。ラッパ−set−uidをインスト−ルしてはい
けません。
Ultrixのみ：あなたがSYSTATサ−ビスをモニタ−したい場合、vendor−
provided miscdデ−モンをMakefile中で一定のREAL_DAEMON_DIRによって
指定された位置に移動させ、オリジナルmiscdロケ−ションでmiscdラッパ
−をインスト−ルしてください。
任意のアクセスコントロ−ルテ−ブルがない状態で、デ−モンラッパ−はあ
なたのシステムに作られたネットワ−ク接続の記録を保存するでしょう。

7.2 − Advanced configuration and installation（上級編）

一歩進んだ方法はあなたの実行可能デ−モンを単独で残しますが、inetdコン
フィギュレーションファイルへの単純な修正を含んでいます。
`make'のタイプと説明書に続きます。Makefileは、多くの共通のＵＮＩＸ実装
(sun, ultrix, hp−ux, aix, irix,...)のためのready−to−useテンプレ−トに付属し
ます。
IRIXユ−ザ−はまず始めにREADME.IRIXファイルを読むはずです。
`make'が結果に続く時、5つの実行可能なものがあります。（Ultrixの場合6
つ）
あなたのラッパ−およびinetdコンフィギュレーションファイルの中の最も
一般的な問題を識別するために、`tcpdchk' プログラムを使用する事が出来ま
す。
`tcpdmatch'プログラムで、あなたはラッパ−がサ−ビスの特定のリクエスト
にどのように反応するするかを検査することができます。
`try−from' プログラムはホストとユ−ザ−名ルックアップコ−ドをテスト
します。リモ−トシェルコマンド(`rsh host /some/where/try−from')から実行し、
そしてそれはコ−ルされたどんなシステムからも解くことができるでしょ
う。

Booby trapsを実装する場合、 `safe_finger'コマンドは使用されるべきです。そ
れは、リモ−トホストがあなたのフィンガ−調査に応じて行ってもよいと言
う邪魔物に対する良い保護を与えてくれます。

tcpdプログラムはtelnet, finger, ftp, exec, rsh, rlogin, tftp, talk, comsatと他のtcp
或いはudpサ−ビスをモニタ−するために、使用することができます。そし
てそれには実行可能なファイル上に１対１の写像があります。
システムV.4−styleシステムと、tcpdプログラムはさらにTLIサ−ビスを扱
うことができます。TCP/IPまたはUDP/IPがTLIの下で使用される場合、tcpd
はソケットベ−スアプリケ−ションのような同じ機能を提供します。他のい
くつかのプロトコ−ルはTLIの下で使用される場合、機能（クライアントユ
−ザ−名ルックアップなし、奇妙なネットワ−クアドレスフォ−マット）は
制限されるでしょう。
さらに tcpdプログラムはinetdコンフィギュレーションファイル中のrpc/udp
として特徴づけられたサ−ビスを使用することが出来ます。しかしrexdのよ
うなrpc/tcpサ−ビスではありません。とにかくあなたはrexdを実行したくは
ないと思います。ほとんどのシステム上で、それは/etc/hosts.equivの中のワ
イルドカ−ドよりさらに安全性は少ないのです。
適切な場所にtcpdコマンドをインスト−ルして下さい。名前"tcpd"が既に得
られているので、Apollo UNIXユ−ザは異なる名前の下でそれをインスト−
ルした方が良いです。適切な名前は"frontd"でしょう。
ファイル保護：ラッパ−、ラッパ−によって使用されるすべてのファイル、
およびパスの通るそれらのファイルのすべてのディレクトリ−は、アクセス
可能でしょう。しかし特許されていないユ−ザ(mode755或いはmode555)への
書き込みは可能ではありません。ラッパ−set−uidをインスト−ルしてはい
けません。
それからinetdコンフィギュレーションファイル(usually /etc/inetd.conf か 
/etc/inet/inetd.conf)上で下記編集を行ってください。

    finger  stream  tcp     nowait  nobody  /usr/etc/in.fingerd     in.fingerd
                                            ^^^^^^^^^^^^^^^^^^^
次のようになります：

    finger  stream  tcp     nowait  nobody  /usr/etc/tcpd  in.fingerd
                                            ^^^^^^^^^^^^^
`kill −HUP'を、変更を有効にするinetdプロセスに送ってください。いくつ
かのinetd実装は、修正バ−ジョンをつける前にあなたがフィンガ−サ−ビス
(finger serviceやinetdの`kill −HUP'以外のコメントをすること)を最初に使用
できないようにすることを必要とします。
この例はSunOS 4に当てはまります。他のネットワ−クデ−モンのUNIX実
装は、/usr/libexec或いは /usr/sbinか/etc,に存在します。ネットワ−クデ−モ
ンはそれらの名前にの前に"in."を前置しないか、或いはinetdコンフィギュレ
ーションファイル内のユ−ザ−名フィ−ルドは欠けているかもしれません。
フィンガ−サ−ビスが期待通りに作動している時に、あなたは他のネットワ
−クサ−ビスへ似たような変更を実行することが出来ます。`kill −HUP'を
忘れてはいけません。
Ultrixに付属するmiscdデ−モンはいくつかのネットワ−クサ−ビスを実装
します。それは、そのプロセス名を見ることにより何を行うべきであるかを
決定します。サ−ビスのうちの１つはsystat（それは一種の制限のあるフィ
ンガ−サ−ビス）です。あなたがsystat サ−ビスをモニタ−したければ、適
切な場所にmiscdラッパ−をインスト−ルしてください。。そして、inetdコ
ンフィギュレーションファイルを更新して下さい。

    systat  stream  tcp     nowait  /suitable/place/miscd      systatd

Ultrix 4.3は、あなたが実行されるデ−モンの下でユ−ザidを指定することを
可能にします。この特徴はマニュアルペ−ジにドキュメントされていません。
したがって、例は次のようになります。

    systat  stream  tcp     nowait  nobody /suitable/place/miscd    systatd

定着するように、旧Ultrixシステムは全てのそのネットワ−クデ−モンをな
お実行しています。
任意のアクセスコントロ−ルテ−ブルがない状態で、デ−モンラッパ−はあ
なたのシステムに作られたネットワ−ク接続の記録を保存するでしょう。

7.3 − Daemons with arbitrary path names（任意のパス名を備えたデ−モン）

上記のtcpdの例は、共通のディレクトリ−の中に存在するネットワ−クデ−
モンで素晴らしい仕事をします。しかし、時々それは実際的ではありません。
あなたのファイルシステムの至る所でソフトリンクを持っていることもま
た明白な解決ではありません。
あなたが明細に記する事が出来る代わりに、inetdコンフィギュレーションフ
ァイルの中で、デ−モンプロセス名のためのパス名が確実になります。例え
ば、
    ntalk   dgram   udp     wait    root    /usr/etc/tcpd /usr/local/lib/ntalkd

デ−モンプロセス名が絶対的なパス名である場合、tcpdは
REAL_DAEMON_DIR定数の値を無視し、ログイングとアクセスコントロ−
ルのためのデ−モンプロセス名の最後のパスコンポ−ネントを使用します。

7.4 − Building and testing the access control rules（アクセスコントロ−ルル−ルの構築とテスト）

アクセスコントロ−ルをサポ−トするためにラッパ−は−
DHOSTS_ACCESSオプションで編集するに違いありません。アクセスコン
トロ−ルの手段は、２つのテ−ブル(デファルト: /etc/hosts.allowと
/etc/hosts.deny)の形で与えられます。アクセスコントロ−ルテ−ブルがない場
合、あるいはテ−ブルが空の場合、アクセスコントロ−ルは無効になります。
もしあなたが、私が勧める前にラッパ−を使用していなかったら、あなたは、
始めに如何なるアクセスコントロ−ルの制限無しに2〜3日間それを実行し
ます。ログファイルの記録はあなたにアクセスコントロ−ルの中に構築しな
ければならないホスト名及びプロセス名についての与えてくれるでしょう。
アクセスコントロ−ルル−ルの構文は`nroff −man'フォ−マットの中にある
hosts_access.5のファイル中でドキュメント化されます。これは長ったらしい
ドキュメントであり、誰も始めから最後までそれをすぐに読むことは期待し
ていません。代わりに、説明のセクションを読んだ後、言語の一般的な考え
を思いつくように、終わりで例にスキップをしてください。その後、ドキュ
メントの始めの方の詳細な参照セクションを認識することができます。
hosts_access.5ドキュメント(`nroff −man'フォ−マット)中の例はアクセスコ
ントロ−ル手段の特定の２つのタイプを示しています。１）主にクロ−ズす
る（システムの制限数から許されたアクセスのみ）２）主にオ−プンする（ト
ラブルメ−カ−の制限数以外の全ての人からの許されたアクセス）。
あなたは、あなたの状況に一番適したモデルを選ばなければなりません。実
装した混合手段もまた、過度に困難ではあってはならないのです。
アクセスコントロ−ル言語に対するオプションの拡張はhosts_options.5ドキ
ュメント (`nroff −man' format)に記述されています。
`tcpdchk'プログラムはあなたのアクセスコントロ−ルファイル中の全てのル
−ルを検査し、それが見つけることができるいくつかの問題を報告します。
`tcpdchk −v'は標準出力にすべてのル−ルのきれいな印刷されたリストを書
き込みます。 `tcpdchk −d'は現在のディレクトリ−中でhosts.access及び
hosts.allowファイルを検査します。このプログラムはtcpdchk.8ドキュメント
(`nroff −man' format)に記述されています。
`tcpdmatch'コマンドはあなたの局所的なアクセスコントロ−ルファイルを試
みるために使用することができます。コマンド構文は次のとおりです。

    tcpdmatch process_name hostname (e.g.: tcpdmatch in.tftpd localhost)

    tcpdmatch process_name address  (e.g.: tcpdmatch in.tftpd 127.0.0.1)

このように、ホストがあなた独自のシステムに接続する場合、決定がなされ
るもの、および処置が取られるものをシミュレ−トすることができます。プ
ログラムは、tcpdmatch.8ドキュメント(`nroff −man' format)に記述されていま
す。

注意１：`tcpdmatch −d'はホストを捜すでしょう。 カレントワ−キングデ
ィレクトリ−中の{allow,deny}テ−ブル。これはあなたのユ−ザの邪魔無し
に、新しいル−ルをテストするのに役立ちます。

注意２：局所的なシステムが他のホストに接続する場合に起こることをシ
ミュレ−トするのに`tcpdmatch'コマンドを使用することができません。
何のプロセス名を使用するべきであるか知るためには、サ−ビスを利用する
か、ログファイルの中で現われるプロセス名を見てください。二者択一で、
inetdコンフィギュレーションファイルからの名前を調べることができます。
上記のtutorial sectionのtftp例に戻ってください。

    tftp  dgram  udp  wait  root  /usr/etc/tcpd  in.tftpd −s /tftpboot

このエントリ−はinetdにプロセス名前`in.tftpd'でラッパ−プログラム(tcpd)を
実行させます。これはアクセスコントロ−ルテ−ブルを走査した場合に、ラ
ッパ−が使用する名前です。したがって、`in.tftpd'は`tcpdmatch'コマンドに与
えられるべきプロセス名です。あなたのシステム上で実際の inetd.confエン
トリ−は異なるかもしれません（in.tftpdの代わりのtftpdと`root'フィ−ルド
はない）しかし、あなたはアイデアをゲットします。
ホスト名を指定した場合、`tcpdmatch'プログラムはホスト名およびアドレス
の両方を使用するでしょう。この方法はラッパ−がホストアドレスおよびホ
スト名の両方の見分けがついたところで、最も一般的な場合をシミュレ−ト
することができます。`tcpdmatch'プログラムは与えられたホスト名を探す事
のできるすべてのアドレス上でそれを繰り返すでしょう。
ホスト名の代わりにホストアドレスを指定した場合、`tcpdmatch'プログラム
は、ラッパ−がクライアントホスト名を調べることができない場合に何が起
こるかをシミュレ−トする為に、ホスト名が未知であるというふりをするで
しょう。

7.5 − Other applications（他のアプリケ−ション）

アクセスコントロ−ルル−チンは他のものに容易に統合することができま
す。hosts_access.3マニュアルペ−ジ (`nroff −man'フォ−マット)に、libwrap.a
ライブラリの外付けインタ−フェ−スについて記述してあります。
tcpdプログラムはメ−ルサ−ビスへのアクセスを制御するために、使用する
ことができます。誰かがある不明瞭なsendmailバグを試みているのではない
かと、疑問に思う場合、あるいはリモ−トサイトがミスコンフィギュア（構
成ミス）され、あなたのメ−ルデ−モンを打ち続ける場合、これは役に立つ
でしょう。
その場合、センドメ−ルがstand−aloneのネットワ−クリスナ−として実行
されてはいけません。しかし、それはinetdコンフィギュレーションファイル
中で登録されるべきであります。例えば、

    smtp    stream  tcp     nowait  root    /usr/etc/tcpd/usr/lib/sendmail − bs

あなたはキュ−アップアウトゴ−イングメ−ルを操作するバックグランド
プロセスをなお実行する必要があるでしょう。コマンドは次の様なものです。
    /usr/lib/sendmail −q15m

(no `−bd' flag)はそれに気を付けさせてください。ネットワ−ク上に多くの無
防備のsmtpデ−モンがあるので、実際にあなたは、作ったメイルをこの方
法でポスティングすることから人々を妨げることはできません。

8 − Acknowledgements

Many people contributed to the evolution of the programs, by asking
inspiring questions, by suggesting features or bugfixes, or by
submitting source code.  Nevertheless, all mistakes and bugs in the
wrappers are my own.

Thanks to Brendan Kehoe (cs.widener.edu), Heimir Sverrisson (hafro.is)
and Dan Bernstein (kramden.acf.nyu.edu) for feedback on an early
release of this product.  The host name/address check was suggested by
John Kimball (src.honeywell.com).  Apollo's UNIX environment has some
peculiar quirks: Willem−Jan Withagen (eb.ele.tue.nl), Pieter
Schoenmakers (es.ele.tue.nl) and Charles S. Fuller (wccs.psc.edu)
provided assistance.  Hal R.  Brand (addvax.llnl.gov) told me how to
get the client IP address in case of datagram−oriented services, and
suggested the optional shell command feature.  Shabbir Safdar
(mentor.cc.purdue.edu) provided a first version of a much−needed manual
page.  Granville Boman Goza, IV (sei.cmu.edu) suggested to use the
client IP address even when the host name is available.  Casper H.S.
Dik (fwi.uva.nl) provided additional insight into DNS spoofing
techniques.  The bogus daemon feature was inspired by code from Andrew
Macpherson (BNR Europe Ltd).  Steve Bellovin (research.att.com)
confirmed some of my suspicions about the darker sides of TCP/IP
insecurity. Risks of automated fingers were pointed out by Borja Marcos
(we.lc.ehu.es). Brad Plecs (jhuspo.ca.jhu.edu) was kind enough to try
my early TLI code and to work out how DG/UX differs from Solaris.

John P.  Rouillard (cs.umb.edu) deserves special mention for his
persistent, but constructive, nagging about wrong or missing things,
and for trying out and discussing embryonic code or ideas.

Last but not least, Howard Chu (hanauma.jpl.nasa.gov), Darren Reed
(coombs.anu.edu.au), Icarus Sparry (gdr.bath.ac.uk), Scott Schwartz
(cs.psu.edu), John A. Kunze (violet.berkeley.edu), Daniel Len Schales
(engr.latech.edu), Chris Turbeville (cse.uta.edu), Paul Kranenburg
(cs.few.eur.nl), Marc Boucher (cam.org), Dave Mitchell
(dcs.shef.ac.uk), Andrew Maffei, Adrian van Bloois, Rop Gonggrijp, John
C. Wingenbach, Everett F. Batey  and many, many others provided fixes,
code fragments, or ideas for improvements.

        Wietse Venema (wietse@wzv.win.tue.nl)
        Department of Mathematics and Computing Science
        Eindhoven University of Technology
        P.O. Box 513
        5600 MB Eindhoven
        The Netherlands