連載：止められない基幹業務サーバの管理対策
第3回 サービスをセキュアにするための利用制限
〜TCP Wrapperによるサービスのアクセス制限〜
三井物産GTI （現：三井物産セキュアディレクション株式会社）
木村 靖
2003/8/9
|
TCP Wrapperの設定確認 |
●設定内容の妥当性チェック （tcpdchk）
TCP Wrappers付属のtcpdchkを使い、hosts.allowおよびhosts.denyの設定に不備がないかをチェックする。存在しないパス名やプロセス名が含まれていた場合は、その問題点が報告される。
|
|
| オプション | 意味 |
| -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を実行すると以下のエラーが出力される。
|
|
上記より、カレントディレクトリ上のhosts.allowの1行目に設定ミスがあることが分かる。正しいプロセス名（ftpd）を指定して、もう一度tcpdchkを実行すると、エラーは出力されなくなる。
●設定したアクセス制限をシミュレーションする（tcpdmatch）
tcpdchkと同様に、TCP Wrapper付属のtcpdmatchコマンドを使うことで、設定したアクセス制限のルールを疑似的に確認することが可能だ。
|
|
| オプション | 意味 |
| -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 |
hosts.allowの1行目のルールで、許可（granted）されていることが分かる。続いて、禁止されている接続元192.168.0.136の確認を行う。
% tcpdmatch -d telnetd 192.168.0.136 |
hosts.denyの1行目のルールで、禁止（denied）されていることが分かる。このようにして、許可・禁止されている条件をいくつか試してから適用する。
tcpdchkおよびtcpdmatchのチェックをクリアできたら、編集したhosts.allowおよびhosts.denyを/etcにコピーして設定を反映させる。反映させたら直接アクセスしてみて確認する。
| ※注 このとき、tcpdmatchなどを実行した（サーバにログイン中の）ターミナルは、後述の「実際に確認する」が完了するまで、決してログアウトしてはいけない。 |
●実際に確認する
前述のtcpdmatchは、あくまでルールを疑似的にチェックするものだ。そのため設定内容を反映させた後は、実際にアクセスしてみて、本当に正しく設定されているかの確認を忘れずに行うこと。
確認は、アクセス許可／禁止されているホストから行う。例えば、禁止されているホストからtelnetやftpを実行すると、以下のとおり利用できないことを確認できる。
% telnet 192.168.0.136 |
|
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）に対するアクセスに成功／失敗した結果のログを以下に示す。
・アクセスに成功した場合
|
|
192.168.0.10からのftpに対するアクセスが許可されていることがうかがえる。
・アクセスに失敗した場合
|
|
192.168.0.10からのftpに対するアクセスが拒否されていることがうかがえる。
●severity/facirity を変更
syslogに出力する際のseverityとfacirityを変更する場合は、オプション（shell_command部分）にseverityを設定する。
例：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つだが、設定を一歩間違えると、思わぬところにセキュリティホールが生まれたり、稼働中のサービスに影響を及ぼす恐れがあることに十分注意しよう。次回は管理者特権の利用制限について説明する。
 |
3/3 | 「第4回」へ |
| index | |
| 第1回 不要なサービスの停止こそ管理の第一歩 | |
| 第2回 ソフトウェアの現状確認とアップグレード | |
| 第3回 サービスをセキュアにするための利用制限 | |
| Page1 特定サービスの利用制限 TCP Wrapperとは？ TCP Wrapperのインストール |
|
| Page2 TCP Wrapperの設定 |
|
 |
Page3 TCP Wrapperの設定確認 TCP Wrapperのアクセスログを確認 |
| 第4回 スーパーユーザーの特権を制限する | |
| 第5回 管理者権限を制限するためのsuとsudoの基本 | |
| 第6回 特権ユーザーの安全性向上を行うsudoの設定例 | |
| 第7回 UNIXサーバの運用管理で欠かせないログ管理 | |
| 関連記事 | |
| 連載：Webアプリケーションに潜むセキュリティホール | |
| 特集：クロスサイトスクリプティング対策の基本 | |
| 連載：インシデントレスポンスはじめの一歩〜rootkitを検出するために |
 |
Security&Trust記事一覧 |
- Webを見るだけで――ここまできたiPhoneの脅威 （2010/8/26）
スマートフォンも常にアップデートを――iPhoneだって例外ではありません。iOSへの攻撃例を動画で解説します - 日本的なリスク回避策と、それに代わる技術 （2010/8/20）
持ち運べるデバイスには、さまざまなリスクがある。そのリスク回避の歴史と、回避のための技術動向を3回にわたり解説する - “感染後をケアするエンジン”の必要性 （2010/8/11）
ウイルスを検知する4つのエンジンの裏で、ひっそりと働くエンジンがある。エンジニアはなぜ、その製作に取り組んだのか - クラウドセキュリティにコストをかける覚悟はあるか （2010/8/9）
プライベートクラウドが盛り上がる理由は、それで得する人たちがいるからです。言いなりにならないためには、何をすべき？
 |
|
|
|
|
スキルアップ／キャリアアップ（JOB@IT）
スポンサーからのお知らせ
- - PR -
- - PR -
お勧め求人情報
*＊先週の人気講座ランキング＊*
〜ITIL編〜
著作権はアイティメディア株式会社またはその記事の筆者に属します。（著作権について）
当サイトに掲載されている記事や画像などの無断転載を禁止します。
「＠IT」「＠IT自分戦略研究所」「＠IT情報マネジメント」「JOB＠IT」「＠ITハイブックス」「＠IT MONOist」「ITmedia」「誠」「BARKS」は、アイティメディア株式会社の登録商標です。
当サイトに関するお問い合わせは「＠ITへのお問い合わせ」をご覧ください。