ファイアウォールの設定・動作チェック方法：ゼロから始めるLinuxセキュリティ（6）（1/2 ページ）

　第3回から3回に分けて、ファイアウォールの構築方法を紹介してきました。今回は、構築したファイアウォールの動作の確認方法などについて説明します。

tcpdumpによるファイアウォールの導通確認

　導通確認とは、目的のサーバに対してルールどおりにアクセスできることを確認することです。もちろん、実際にアクセスすれば確認できるでしょう。「導通確認」という観点から考えるとこれだけでも目的は達成できるのですが、今回は接続できないというトラブルも想定してツールを使ってみましょう。

　ファイアウォールを介すると目的のホストに接続できないときは、NATやFORWARDの問題など、さまざまな原因が考えられます。これを回避するには、まず原因の切り分けが必要です。原因の切り分けができないと、どこをどう修正すればいいのか分かりにくいものです。そこで、tcpdump（ftp://ftp.ee.lbl.gov/）というツールを使います（注）。

tcpdumpの動作を制御するオプション

　tcpdumpは、ネットワーク上のパケットをモニタリングするツールです。単純に流れているすべてのパケットをモニタリングするだけでなく、オプションや条件式を指定してそれに一致するパケットのヘッダを表示します。

　代表的なオプションには、以下のようなものがあります。これ以外についてはmanページを参照してください。

tcpdumpの対象を指定する条件式

　条件式を与えると、自分の欲しい情報だけを出力させることができます。何も条件を指定せずにtcpdumpを実行すると、ネットワーク上のすべてのパケットをダンプしてしまうので、それを解析するだけでも大変です。条件式を活用して、ダンプする情報を必要なものだけに絞り込むようにしましょう。

　条件式には次の3つの修飾子があります。

　上記の修飾子で構成された条件を演算子「and」「or」「not」でつなぐことで、複雑な条件を指定することが可能です。

tcpdumpの具体的な使い方

　tcpdumpのオプション／条件式が分かったところで、具体例を見ていきましょう。まずは、次のような条件の情報を取得するとします。

　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状態にあることを前提とします。

　目的のホストやポートに接続できない原因としては、次のことが考えられるでしょう。

　まずは、どこまでパケットが流れているのかを考えてみましょう。

　下記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つ原因を切り分けて設定を再確認してください。