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

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

[木村靖,三井物産GTI]
前のページへ 1|2|3       

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つだが、設定を一歩間違えると、思わぬところにセキュリティホールが生まれたり、稼働中のサービスに影響を及ぼす恐れがあることに十分注意しよう。次回は管理者特権の利用制限について説明する。

筆者紹介

三井物産GTI (現:三井物産セキュアディレクション株式会社

木村靖



前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。