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

» 2003年08月09日 00時00分公開

[木村靖，三井物産GTI]

TCP Wrapperの設定確認

設定内容の妥当性チェック（tcpdchk）

　TCP Wrappers付属のtcpdchkを使い、hosts.allowおよびhosts.denyの設定に不備がないかをチェックする。存在しないパス名やプロセス名が含まれていた場合は、その問題点が報告される。

% tcpdchk [オプション]


オプション	意味
-a：	allowが明示的に使われていない場合で、アクセスが許可されているルールを表示
-d：	hosts.allow と hosts.deny
-i：	inet_conf inetd.confファイルを指定する
-v：	詳細モード

　tcpdchk による確認は、単にtcpdchkコマンドを実行するだけでよいが、その場合は/etc/hosts.allowと/etc/hosts.denyのチェックが行われる。ここでは稼働中のサービスへの影響を考慮し、/etc/hosts.allowと/etc/hosts.denyファイルは、保存した時点で反映されるため直接編集しない。いったん別ディレクトリにファイルをコピーして編集することにした。そのため、tcpdchkには-dオプションを指定して、現在位置（カレント）ディレクトリ上のhosts.allowとhosts.denyをチェックすることにした。

　例：プロセス名を間違えていた場合（/etc/inetd.confに存在しないプロセス名を指定）

　hosts.allowに、以下のような存在しないプロセス名（ftp）が指定されていた場合、

ftp: 192.168.0.10

　tcpdchkを実行すると以下のエラーが出力される。

% tcpdchk -d
warning: hosts.allow, line 1: ftp: no such process name in /etc/inetd.conf

　上記より、カレントディレクトリ上のhosts.allowの1行目に設定ミスがあることが分かる。正しいプロセス名（ftpd）を指定して、もう一度tcpdchkを実行すると、エラーは出力されなくなる。

設定したアクセス制限をシミュレーションする（tcpdmatch）

　tcpdchkと同様に、TCP Wrapper付属のtcpdmatchコマンドを使うことで、設定したアクセス制限のルールを疑似的に確認することが可能だ。

% tcpdmatch [オプション] daemon[@server] [user@]client


オプション	意味
-d	hosts.allowとhosts.denyファイルがカレントディレクトリ上の存在する場合
-i inet_conf	inetd.confファイルを指定する。デフォルトは/etc/inetd.conf が指定される
daemon	デーモンプロセス名を指定する。telnetであれば、telnetd、in.telnetdなど
server	serverの部分には、ホスト名またはネットワークアドレスを指定する。省略した場合、“unknown”が仮定される
client	接続元のホスト名、ネットワークアドレス、または“unknown”、 “paranoid”といったワイルドカードパターンを指定する

　例： telnetdへのアクセス制限を確認（許可：192.168.0.10、禁止：それ以外）

hosts.allowへの記述

telnetd: 192.168.0.10

hosts.denyの記述

ALL: ALL

　hosts.allowおよびhosts.denyファイルはカレントディレクトリにあるものとして説明する。まずは許可されている接続元192.168.0.10の確認から行う。

% tcpdmatch -d telnetd 192.168.0.10
client:   address  192.168.0.10
server:   process  telnetd
matched:  hosts.allow line 1
access:   granted

　hosts.allowの1行目のルールで、許可（granted）されていることが分かる。続いて、禁止されている接続元192.168.0.136の確認を行う。

% tcpdmatch -d telnetd 192.168.0.136
client:   address  192.168.0.136
server:   process  telnetd
matched:  hosts.deny line 1
access:   denied

　hosts.denyの1行目のルールで、禁止（denied）されていることが分かる。このようにして、許可・禁止されている条件をいくつか試してから適用する。

　tcpdchkおよびtcpdmatchのチェックをクリアできたら、編集したhosts.allowおよびhosts.denyを/etcにコピーして設定を反映させる。反映させたら直接アクセスしてみて確認する。

※注
このとき、tcpdmatchなどを実行した（サーバにログイン中の）ターミナルは、後述の「実際に確認する」が完了するまで、決してログアウトしてはいけない。

実際に確認する

　前述のtcpdmatchは、あくまでルールを疑似的にチェックするものだ。そのため設定内容を反映させた後は、実際にアクセスしてみて、本当に正しく設定されているかの確認を忘れずに行うこと。

　確認は、アクセス許可／禁止されているホストから行う。例えば、禁止されているホストからtelnetやftpを実行すると、以下のとおり利用できないことを確認できる。

% telnet 192.168.0.136
Trying 192.168.0.136...
Connected to 192.168.0.136.
Escape character is '^]'.
Connection closed by foreign host.
%
%
ftp 192.168.0.136
Connected to 192.168.0.136.
421 Service not available, remote server has closed connection.
ftp>

TCP Wrapperのアクセスログを確認

syslogへの出力

　TCP Wrapperは、syslog経由でログを残す。デフォルトでは、facilityがmailでseverity がinfoとなっているが、標準インストールされている場合はOSによって異なる。

　例えばRed Hat Linux 7.3やNetBSDのfacilityは、authprivに設定されており、さらに出力先のログファイルはRed Hatが/var/log/secureに対して、NetBSDは /var/log/authlogとなっている。それらの違いは各OSの/etc/syslog.confの内容を確認する必要がある。

アクセスログの様子

　syslog経由で、アクセスに成功／失敗した結果がログに保存される。例として、192.168.0.10からftpサービス（21/tcp）に対するアクセスに成功／失敗した結果のログを以下に示す。

アクセスに成功した場合

Jul 24 04:19:47 t23 inetd[10040]: connection from 192.168.0.10, service ftp （tcp）

　192.168.0.10からのftpに対するアクセスが許可されていることがうかがえる。

アクセスに失敗した場合

Jul 24 04:23:36 t23 inetd[10065]: refused connection from 192.168.0.10, service ftp （tcp）

　192.168.0.10からのftpに対するアクセスが拒否されていることがうかがえる。

severity/facirity を変更

　syslogに出力する際のseverityとfacirityを変更する場合は、オプション（shell_command部分）にseverityを設定する。

　例：severityをauthpriv.infoに変更

ftpd: 192.168.0.10: severity authpriv.info

ログに残らない通信

　TCP Wrapperは、TCPの場合3ウェイ・ハンドシェイクが確立された時点でログファイルに記録される。そのためTCP SYN scan（half scan）などの正規の手順を踏んでいないものについては、ログに残らないことに注意する。例えば、nmapの-sT（TCP connect（） scan）はログに残るが、-sS（TCP SYN scan）や-sF（FIN scan）などの通信はログに残らない。

　直接的な対策ではないが、最近のルータやファイアウォールでは、こういった違法な通信を検知しブロックできる、ステートフル・インスペクションなどの機能が搭載されている。それらの機能を使って違法な通信（パケット）は、サーバに到達する前に防ぐというやり方が主流になりつつある。

　今回はTCP Wrapperを使ったアクセス制限について説明した。アクセス制限は、サーバのセキュリティを向上させるために欠かせない機能の1つだが、設定を一歩間違えると、思わぬところにセキュリティホールが生まれたり、稼働中のサービスに影響を及ぼす恐れがあることに十分注意しよう。次回は管理者特権の利用制限について説明する。