構築したファイアウォールの動作テスト：ファイアウォール運用の基礎（4）（1/2 ページ）

[田原祐介，株式会社ラック]

　構築したファイアウォールをネットワークに接続する前に、設計どおりに設定が完了しているかを検査する必要があります。検査を怠ると、実際に運用に入ってからうまく接続できなかったり、穴があるファイアウォールに気付かずに使い続けることになりかねません。このような検査は、さまざまなネットワークツールを使いこなして、地道に行うしかありません。そのため、ファイアウォールの構築以上に高度なネットワークの知識を必要とします。

　また、単体のサーバマシンの検査とは違って、ファイアウォールの検査の場合は、ファイアウォールそのものだけでなく、さらにクライアントとサーバも用意する必要があります。ところが、複数のサーバと複数のネットワークセグメントから構成されるサイトだった場合、検査を行うだけでも本番環境を構築するのと同じくらい大掛かりなものになってしまいます。

　実際に、このような環境を用意して検査を行うのは、非現実的といえます。そこで、今回はさまざまなネットワークツールを用いて、ファイアウォールの検査を行う方法を紹介します。

検査に使用するツール

　ここで紹介するほかにも、便利で高機能なツールは多数存在します。もし興味があれば、いろいろ試してみるといいでしょう^＊1。

• nmap
  　最も優れたポートスキャン用のプログラムの1つです。リモートからOSの種類を推測したり、高速にポートスキャンを行うことができます。ポートスキャンは、ファイアウォールのルールに穴がないかをチェックするのに使えます
  
  
• tcpdump
  　最も有名なパケットダンプ用プログラムの1つで、ほとんどのUNIX上で動作します。うまく通信ができないなどのトラブルシューティングのほか、次に紹介するhping2と組み合わせて、ファイアウォールのルールが正しく設定されてパケットが間違いなく通過しているかどうかを確認するのに使えます
  
  
• hping2
  　hping2 は、さまざまな種類のパケットを生成できます。そのため、ファイアウォールで許可されているパケットを生成して、ファイアウォールを通過させることができます
  
  
• VMware Workstation^＊2
  　ネットワークツールではありませんが、複数のOSを仮想ハードウェア上で実行できるソフトウェアです。ネットワークに複数のクライアント／サーバが存在しているような環境で、1台のマシン上に複数のOSが動作しているような実験環境を構築するのに便利です

^＊1ただし、ここで紹介するツールは大変便利である半面、不正アクセスに利用することもできます。これらのツールをほかのネットワークで使用するときは、十分気を付けてください。不正なアクセスと見なされる可能性があります

^＊2ここで紹介しているソフトウェアの中で、VMwareだけは有償の製品です。30日間は試しに使ってみることができますが、その後は正式ライセンスを購入しないと継続して使えません。しかし、使用用途が非常に幅広く、値段もそれほど高くないので、購入しても損はないソフトウェアです（2001年8月16日現在で、Workstation版が299ドル）

テスト用のファイアウォールを構築する

　テスト用のファイアウォールを構築するために、前回設定したファイアウォールのルールの一部を変更します。ネットワーク構成（図1）と、ルールは以下のとおりです。

図1　テスト用システムのネットワーク構成

block in log quick from any to any with short block in log quick from any to any with ipopts block in on iprb0 all head 100 block out on iprb0 all head 150 pass in quick on iprb1 all pass out quick on iprb1 all block in log quick from 10.0.0.0/8 to any group 100 #block in log quick from 172.16.0.0/12 to any group 100 …… (1) block in log quick from 192.168.0.0/16 to any group 100 pass out quick proto icmp from any to any keep state group 150 pass out quick proto udp from any to any keep state group 150 pass out quick proto tcp from any to any flags S/SAFR keep state group 150 pass in log quick proto tcp from any to 192.168.0.10 port = 21 flags S/SAFR keep state group 100 …… (2) pass in log quick proto tcp from any to 192.168.0.10 port = 80 flags S/SAFR keep state group 100 …… (3)

リスト1　変更後のファイアウォールのルール「/etc/opt/ipf/ipf.conf」

(1)：
　前回はファイアウォールとルータを直結していたため、予約アドレスである「172.16.0.0/12」からのパケットを拒否していましたが、今回は実験環境でこのアドレスを使用するため、一時的にこのルールを無効にします。

(2)〜(3)：
　ファイアウォールを通過させて、イントラネットにある「192.168.0.10」というマシンに、ftpとhttpを許可するルールです。ここで、あて先アドレスが「192.168.0.10」なのは、パケットフィルタリングが適用される前に、NATのルールが適用されるためです（図2）。

図2　入ってくるパケットは、パケットフィルタリングより先にアドレス変換が行われる（出て行くパケットの場合は順序が逆）

　以下は NAT のルール（/etc/opt/ipf/ipnat.conf）です。

map iprb0 192.168.0.0/16 -> 172.16.240.241/32 proxy port ftp ftp/tcp map iprb0 192.168.0.0/16 -> 172.16.240.241/32 portmap tcp/udp 1025:65000 …… (6) map iprb0 192.168.0.0/16 -> 172.16.240.241/32 rdr iprb0 172.16.240.241/32 port 21 -> 192.168.0.10 port 21 tcp …… (4) rdr iprb0 172.16.240.241/32 port 80 -> 192.168.0.10 port 80 tcp …… (5)

リスト2　NATのルール「/etc/opt/ipf/ipnat.conf」

(4)〜(5)：
　あて先アドレスが「172.16.240.241」、あて先ポートがftp／httpであるパケットのあて先アドレスを、「192.168.0.10」に書き換えます。前回のファイアウォールでは、インターネットからイントラネットへの通信は、すべて拒否されていましたが、今回はイントラネットにサーバを置いて^＊3、一部のサービスのみアクセスできるようにファイアウォールを設定しています。これらのサービスは、ファイアウォールのアドレスに向けたパケットを、サーバのアドレスにNATすることによって実現しています。

^＊3通常、インターネット向けのサービスを行うサーバを、イントラネットに置いてはいけません。なぜならば、万が一サーバが乗っ取られたときに、同じネットワークのホストが攻撃される可能性があるからです。今回は、設定を簡単にするため、このような構成にしました

　また、前回も説明したとおり、ftpは制御用とデータ用のコネクションに分かれています。データ用のコネクションは、「サーバ→クライアント」に張られるものと、逆向きのものと2種類のタイプがあります。通常のftp接続では、データ用コネクションは「サーバ→クライアント」に張られるため、(6)のNATのルールが適用されます。

　これに対して、クライアント→サーバにコネクションが張られる場合（「passive接続」と呼ばれます）は、ファイアウォールに穴を1つ開けなければなりません。これはセキュリティ的には好ましくないので、ファイアウォールの内側にあるftpサーバに対しては、passive接続は許可しない方がいいでしょう。