ファイアウォールの設定・動作チェック方法：ゼロから始めるLinuxセキュリティ（6）（1/2 ページ）
ファイアウォールを構築したらサーバにアクセスできなくなった。あるいは、一見正しく動作しているようでもルールに抜け穴があれば意味がない。ファイアウォールの動作が本当に適切かどうか、各種のツールを利用してチェックしよう。
第3回から3回に分けて、ファイアウォールの構築方法を紹介してきました。今回は、構築したファイアウォールの動作の確認方法などについて説明します。
tcpdumpによるファイアウォールの導通確認
導通確認とは、目的のサーバに対してルールどおりにアクセスできることを確認することです。もちろん、実際にアクセスすれば確認できるでしょう。「導通確認」という観点から考えるとこれだけでも目的は達成できるのですが、今回は接続できないというトラブルも想定してツールを使ってみましょう。
ファイアウォールを介すると目的のホストに接続できないときは、NATやFORWARDの問題など、さまざまな原因が考えられます。これを回避するには、まず原因の切り分けが必要です。原因の切り分けができないと、どこをどう修正すればいいのか分かりにくいものです。そこで、tcpdump（ftp://ftp.ee.lbl.gov/）というツールを使います（注）。
tcpdumpの動作を制御するオプション
tcpdumpは、ネットワーク上のパケットをモニタリングするツールです。単純に流れているすべてのパケットをモニタリングするだけでなく、オプションや条件式を指定してそれに一致するパケットのヘッダを表示します。
代表的なオプションには、以下のようなものがあります。これ以外についてはmanページを参照してください。
| -a | ネットワークとブロードキャストアドレスをDNS名に変換する |
|---|---|
| -F file | フィルタ条件式の入力にfileを用いる。このオプションの後ろにコマンドラインによる条件式があっても無視する |
| -i interface name | 引数として指定したインターフェイスを監視する |
| -l | 標準出力をバッファリングする。データを蓄積しながら監視する場合に使用する |
| -n | ホストアドレスやポート番号を名前に変換しない |
| -N | ホストのドメイン名を表示しない |
| -w filename | ダンプしたパケットを表示せずにそのままファイルに書き出す |
| -r filename | -wオプションで作成したファイルからパケットを読み込む |
| -t | ダンプ行に時間情報を表示しない |
| -tt | ダンプ行に表示する時間情報を整形しない |
| -v | 詳細に出力する。IPパケットにおける生存時間（TTL）やサービスの種類などが表示される |
| -vv | -vオプションよりも詳細に出力する |
| -vvv | さらに詳細に出力する |
| -x | すべてのパケットを16進数で表示する |
| -X | 16進数表示するとともに、ASCII文字も表示する |
| tcpdumpのオプション | |
tcpdumpの対象を指定する条件式
条件式を与えると、自分の欲しい情報だけを出力させることができます。何も条件を指定せずにtcpdumpを実行すると、ネットワーク上のすべてのパケットをダンプしてしまうので、それを解析するだけでも大変です。条件式を活用して、ダンプする情報を必要なものだけに絞り込むようにしましょう。
条件式には次の3つの修飾子があります。
- type
対象にするパケットの種類を指定する。typeで指定できるのはhost（ホスト）、net（ネットワーク）、port（ポート）の3種類例：host hogehoge、port 80など - dir
通信の方向を特定する。方向として指定できるのはsrc（ソースアドレス）、dst（ディスティネーションアドレス）、src or dst、src and srcの4種類。dir修飾子がない場合は、「src or dst」が指定されたものと見なされる - proto
プロトコルを特定する。プロトコルとして利用可能なのは、
| ether | fddi | mopdl | ip | ip6 | arp | rarp | decnet | |
| lat | sca | moprc | icmp | icmp6 | tcp | udp |
の15種類。proto修飾子がない場合は、（type修飾子と矛盾しない範囲で）すべてのプロトコルが指定されたものと見なされる
上記の修飾子で構成された条件を演算子「and」「or」「not」でつなぐことで、複雑な条件を指定することが可能です。
tcpdumpの具体的な使い方
tcpdumpのオプション／条件式が分かったところで、具体例を見ていきましょう。まずは、次のような条件の情報を取得するとします。
80/TCP（HTTP）のアクセスを監視
tcpdumpの条件式でプロトコル、ポート番号を指定することが可能です。つまり、プロトコルが「tcp」、ポート番号が「80」という条件を与えればいいのです。
さらに、ホストアドレスやポート番号を名前に変換しないように-nオプションを指定します。これをまとめると次のようになります（注）。
# tcpdump tcp port 80 -n
ここまでは、特に難しくないと思います。しかし、これだけではネットワークを流れるすべての80/TCPのパケットをダンプしてしまいます。これを特定のホストに対するアクセスのパケットに限定してみましょう。
複数の条件を与えたい場合は、and演算子を使います。そこで、ソース、ディスティネーションに関係なく、IPアドレス192.168.0.100に関する80/TCPのパケットを監視したい場合は、次のように条件を指定します。
# tcpdump tcp port 80 and host 192.168.0.100 -n
さらに、ソースアドレス（src）やディスティネーションアドレス（dst）を分けることも可能です。これは、type修飾子のhostの後ろにdstやsrcを付けるだけです。
# tcpdump tcp port 80 and host dst 192.168.0.100 -n
前述したように、演算子にはand以外にorやnotがあります。例えば、80/TCP「以外」のパケットを監視する（80/TCPだけ監視しない）ならnot演算子を使います。
# tcpdump not tcp port 80 -n
sshなどを利用してリモートから操作しているときに、そのホストに対するすべてのパケットを監視しようとすると、22/TCPに関するパケットが大量に出力されてしまいます。このような場合はnot演算子を付けて22/TCPを監視対象から外すといいでしょう。つまり、特定の条件を無視したいときに非常に有効な演算子なのです。
tcpdumpを使った導通確認
では、実際に導通確認を行ってみましょう。Webサーバ（192.168.0.10）に対して、80/TCPのアクセスができないというトラブルを想定して話を進めます。Webサーバ上では、80/TCPがLISTEN状態にあることを前提とします。
目的のホストやポートに接続できない原因としては、次のことが考えられるでしょう。
- 仮想IPアドレスが適切に設定されていない
- NATが適切に行われていない
- 経路が適切に設定されていない
- そのほか
まずは、どこまでパケットが流れているのかを考えてみましょう。
- ファイアウォールの外側のインターフェイス（仮想インターフェイス）まで到達しているのか
- ファイアウォールから、目的のサーバに向かってパケットが出ていけているのか
- サーバまで到達しているにもかかわらずリプライパケットが返ってきていないのか
下記2つのコマンドを同時に実行し、2つのコンソールで同時にパケットの流れを見ます。
# tcpdump -i eth0 -n tcp and port 80 User level filter, protocol ALL, datagram packet socket tcpdump: listening on eth0 19:48:32.782168 < 172.16.1.150.2751 > 192.168.0.10.80: S 753558824:753558824(0 win 64240 <mss 1460,nop,nop,sackOK> (DF) 19:48:35.699014 < 172.16.1.150.2751 > 192.168.0.10.80: S 753558824:753558824(0 win 64240 <mss 1460,nop,nop,sackOK> (DF) 19:48:41.707790 < 172.16.1.150.2751 > 192.168.0.10.80: S 753558824:753558824(0 win 64240 <mss 1460,nop,nop,sackOK> (DF) 19:48:53.725317 < 172.16.1.150.2751 > 192.168.0.10.80: S 753558824:753558824(0 win 64240 <mss 1460,nop,nop,sackOK> (DF)
# tcpdump -i eth1 -n tcp and port 80 User level filter, protocol ALL, datagram packet socket tcpdump: listening on eth1
上記の結果から、目的のホストへのNATは適切に行われていることが分かります。しかし、SYNフラグをセットしたパケットを送信していますがSYN/ACKフラグがセットされたパケットが戻ってきていないことから、接続できていないようです。
eth1には何も出力されていないので、パケットが流れていないことが分かります。つまり、経路が適切に設定されていないなどの原因が考えられます。FORWARDチェインのルールを再度確認してみてください。リプライパケットの経路を設定することも忘れずに行ってください。
このように、ファイアウォールを通過して目的のサーバに接続できているか否か、要求に対する応答を送る経路は存在しているのか、サーバ自身のルーティング情報に間違いはないのかなど、どこまでパケットが流れているのかをインターフェイスごとにモニタリングし、順に判断していくことでどこに問題があるのか分かってきます。1つ1つ原因を切り分けて設定を再確認してください。
Copyright © ITmedia, Inc. All Rights Reserved.