サービスをセキュアにするための利用制限〜TCP Wrapperによるサービスのアクセス制限〜：止められないUNIXサーバのセキュリティ対策（3）（2/3 ページ）

[木村靖，三井物産GTI]

TCP Wrapperの設定

アクセス制御ファイル （hosts.allowとhosts.deny）

　TCP Wrapperのアクセス制御ルールは、すべて/etc/hosts.allowと/etc/hosts.denyファイルで行われる。hosts.allowに許可するルール、そしてhosts.denyに拒否するルールをそれぞれ記述する。また、これら記述したルールが適用される順番は以下のとおりとなる。

1. /etc/hosts.allowファイルの先頭行から順に読み、ルールに一致した時点で、そのホストからのアクセスを許可（granted）する。それ以降のルールは無視される。
2. /etc/hosts.denyファイルを先頭行から順に読み、ルールに一致した時点で、そのホストからのアクセスを禁止（denied）する。それ以降のルールは無視される。
3. /etc/hosts.allowおよび/etc/hosts.denyのいずれのルールにも一致しない場合、そのホストからのアクセスは許可（granted）される。

　注意しなければならないのは3番目のルールで、いずれのルールにも一致しなかった場合はアクセスが許可されてしまうことだ。そのため、/etc/hosts.denyの最終行には、必ずALL：ALLを記述し、許可したホスト以外のアクセスはすべて拒否することをお勧めする。

　また、新たに設定した内容は、/etc/hosts.allowまたは/etc/hosts.denyのファイルを保存した時点で有効となる。そのため、設定した内容を安全かつ慎重に反映させるためには、ファイルをいったん別ディレクトリにコピーして、それを編集するのが望ましい。編集後、後述の妥当性チェックをクリアできた後に、/etc/hosts.allowまたは/etc/hosts.denyにコピーして反映させればよいだろう。

• /etc/hosts.denyの最終行にALL：ALLを記述する（許可していないホストからはすべて禁止）。
• /etc/hosts.allowおよび /etc/hosts.denyは直接編集しない（いったん別ディレクトリにコピーし、それを編集する）。
• 後述の「実際に確認する」は別のターミナル上から行う（設定を行っているターミナルは、作業が完了するまでログアウトしない）。

ルールを安全かつ慎重に適用するためのポイント

アクセス制御ファイルの記述形式

hosts.allow と hosts.deny への記述形式は、以下が基本となる。

daemon_list : client_list [ : shell_command ]

記述項目	指定する内容
daemon_list	デーモンプロセス名またはワイルドカード（表1）を指定。複数指定する場合はカンマ（,）で区切る
client_list	アクセス制限の対象となる接続元を指定。ホスト名、IPアドレス、ワイルドカードを指定することが可能。複数指定する場合はカンマ（,）で区切る
shell_command	この行のルールが適用された場合に実行されるコマンドやオプションを指定する。省略可

ワイルドカード	マッチする条件
ALL	すべてデーモンプロセス、ホスト
LOCAL	ドット（.）が含まれないホスト名
UNKNOWN	（identによる）ユーザー名が不明、ホスト名およびIPアドレスが不明（DNS 正引き／逆引きできない）なホスト
KNOWN	（identによる）ユーザー名が一致、ホスト名およびIPアドレスが正引き／逆引き可能なホスト
EXCEPT	除外対象となるプロセス名a EXCEPT bのように表記する（bを除外したaに一致する）
PARANOID	ホスト名からIPアドレス、IPアドレスからホスト名の結果が異なるホスト
表1 ワイルドカード

変数名	展開される内容
%a （%A）	接続元（接続先）ホストのIP アドレス
%c	接続元の情報（user@host、user@address、ホスト名、IPアドレス）
%d	デーモンプロセス名
%h （%H）	接続元（%Hはサーバ）のホスト名 （ホスト名を得られなければIPアドレス）
%n （%N）	接続元（%Hはサーバ）のホスト名 （ホスト名を得られなければIPアドレス）
%p	デーモンプロセスID
%s	サーバ情報（daemon@host、daemon@address、デーモン名）
%u	接続元ユーザー名（またはunknown）
%% %	文字そのもの
表2 オプション（shell_command）で指定可能な変数

　このほか特殊な例として、行にバックスラッシュ（\）が指定されると、次行に続くことを意味し、行頭が空白または#の場合は、すべてコメント扱いになる。

　なお、ここで説明した以外にもTCP Wrapperにはいくつかのオプションが存在する。詳しくは付属マニュアルのhosts_access（5）およびhosts_options（5）を参照していただきたい。

TCP Wrapperの設定例

　設定例を以下に示す。これらの設定を実際のサーバ上で行う場合は、バックアップや後述の「設定内容の確認」を行ってから適用すること（理由は前述のとおり）。

　また、「表1 ワイルドカード」のKNOWN、UNKNOWN、PARANOIDは、DNSサーバにトラブルがあった場合に機能しなくなるため、特に理由がなければ利用しない方が無難だろう。

　例：特定サービスのみ許可する

　接続元192.168.0.10からのデーモンプログラムftpd（21/tcp）に対するアクセスを許可する。それ以外からのアクセスはすべて禁止する。

hosts.allowへの記述

ftpd: 192.168.0.10

hosts.denyへの記述

ALL：ALL

　例：特定サービスのみ拒否する

　接続元192.168.0.10からのデーモンプログラムftpd（21/tcp）に対するアクセスのみを禁止する。それ以外からのアクセスはすべて許可する。

hosts.allowへの記述

なし

hosts.denyへの記述

ftpd: 192.168.0.10

　例：接続元をネットワーク単位に指定

　接続元192.168.1.0/24からのデーモンプログラムftpd（21/tcp）に対するアクセスを許可する。それ以外からのアクセスはすべて禁止する。

hosts.allowへの記述

ftpd: 192.168.1.

hosts.denyへの記述

ALL：ALL

　上記のほかにサブネットマスクを指定することで、ネットワークの範囲を指定することもできる。

hosts.allowへの記述

ftpd: 192.168.1.0/255.255.255.0

　例：デーモンプログラムと接続元を複数指定

　接続元192.168.0.10および192.168.0.136からのftpd（21/tcp）およびtelnetd（23/tcp）に対するアクセスを許可する。それ以外からのアクセスはすべて禁止する。

hosts.allowへの記述

ftpd,telnetd: 192.168.0.10,192.168.0.136

hosts.denyへの記述

ALL：ALL

　例： コマンドの実行（アクセス拒否をメールで通知）

　接続元192.168.0.10以外からのin.ftpd（21/tcp）に対するアクセスがあった場合に、管理者（root）にメールで通知する。

hosts.allowへの記述

in.ftpd: 192.168.0.10

hosts.denyへの記述

in.ftpd: ALL: spawn (/usr/sbin/safe_finger -l @%h | \

/usr/ucb/mail -s "[%d] %h" root) &

ALL: ALL

　管理者（root）には、以下のようなメールが届く。また、safe_fingerコマンドにより、以下のような接続元の情報を入手できる場合がある。

From: Super-User ＜root＞
  To: root
Subject: [in.ftpd] www.example.co.jp
 [www.example.co.jp]
   Login name: kimu
 Directory: /home/kimu             Shell: /usr/bin/tcsh
 On since Jul 24 04:06:27 on pts/1 from www.example.co.jp
 Mail last read Thu Jul 23 23:12:47 2003
 No Plan.

コラム〜safe_fingerの必要性

前述の例では、TCP Wrapper付属のsafe_fingerコマンドにより、接続の身元確認を行なった。しかし、これが有効なのは、接続元（攻撃者）のOS上でfingerサービス（79/tcp）が有効になっている必要がある。

ひと昔前までは、標準でfingerサービスは有効になっていたものだが、最近のUNIXの傾向としては、もはやfingerは利用されていない。また、利用できたとしても、それほど有効な情報を入手できる訳でもないし、自分自身からのアクセスに失敗した場合、safe_fingerが無限ループに陥る可能性もあるため、いまとなってはsafe_fingerの必要性はないといってもよい。