Linuxで作るファイアウォール［パケットフィルタリング設定編］

いよいよパケットフィルタリングの設定を始める。しっかりと不要なパケットをブロックできれば、ファイアウォールの内側の安全度はより向上する。パケットの性質やiptablesの動作をここでマスターしてほしい。

　前回はNATの設定方法を説明しました。これで見かけ上の経路ができたことになります。今回はファイアウォールの仕上げとして、パケットフィルタリングの設定を行います。

パケットフィルタリングの仕組み

　パケットフィルタリングの設定とはいかなるものかを簡単に説明すると、どのようなパケットを通過させるか、あるいは到達を許可／拒否させるかを定義することです。iptablesではIPアドレスやプロトコル、ポート、フラグメントなどで制限をかけることが可能です。さらに、送信先、送信元なのかといった判断もできます。これを行うのが、filterテーブルに含まれるFORWARD、INPUT、OUTPUTという3つのチェインです。まずは3つのチェインの関係を整理しておきましょう。

図1 iptablesによるパケットフィルタリングの流れ

　パケットを受信した際、まずパケットの送信先をチェックします。送信先がそのパケットを受信したホストそのものであれば、INPUTチェインに送られて定義されているルールに従って処理され、そのパケットを受け取る場合は適切なサービスに渡されます。送信先が別のホストであればFORWARDチェインに送られ、パケットの通過が許可されれば該当するホストへと転送されます。許可されなかったパケットは、そこで破棄されるというわけです。反対に、そのホストのプログラムによって生成されたパケットはOUTPUTチェインでチェックされ、許可されれば送信先へと送り出されます。

　ファイアウォールはインターネットとLANの間でパケットを通過あるいは破棄するのが基本的な役目ですから、FORWARDの設定が中心になります。ただし、ファイアウォール自体に対して何らかの働きかけ（リモートメンテナンスなど）を行いたい場合もあるので、INPUTやOUTPUTの設定も行っておくべきでしょう。

FORWARDチェイン

　FORWARDチェインは、ファイアウォールの肝になるチェインです。必要なパケットだけにDMZ上の目的のホストやサービスへアクセスを許可する（ファイアウォールを通過させる）のが、このFORWARDチェインの仕事です。当然のことながら、FORWARDチェインの基本ポリシーはDROP（パケットを破棄）とします。そして、許可するアクセスのみ「穴をあける」設定を行います。

■基本ポリシーはパケットの破棄

　基本的にFORWARDチェインのポリシーはDROPとするので、まず次のコマンドを実行します。

　-Pオプションは前回説明したとおり、指定したチェインに対して基本ポリシーを設定するオプションです。これで、ファイアウォールを通過してDMZ上のホストへ到達できる経路はすべて絶たれたことになります。

■通過させるパケットの設定

　次にファイアウォールを通過させるパケットの設定です。まずは次のようなルールを想定して設定を行います。

インターネット上のホストからWebサーバ（192.168.0.10）に対するHTTP（80/TCP）のアクセスのみを許可する。

　FORWARDチェインに通過を許可するルールを追加するわけですが、注意しなければならないのは、iptablesでは1つのコネクションを1つのルールだけで許可することができないということです。どういうことかをTCPのコネクションを例に説明します。

図2　TCP 3Way-HandShake

　TCPのセッションは、

1. 接続要求元から接続先へSYNフラグをセットしたパケットを送信
2. SYNパケットを受け取った接続先のホストは、接続元のホストへSYN/ACKフラグをセットしたパケットを送信し、ACKフラグをセットしたパケットを待ち受ける
3. 接続元のホストから送信されたACKフラグがセットされたパケットを接続先のホストが受け取る

という3つの段階を経て開始されます。

　iptablesでは、接続元のホストから接続先のホストへのルール（上図の（1）（3））と接続先のホストから接続元のホストへのルール（上図の（2））とを別々のルールで定義する必要があります（注）。

　これを踏まえたうえで、実際のルールを設定していきます。インターネット上のホストから、Webサーバへのアクセスを許可するには次のコマンドを実行します。

　上記のオプションは、次の内容をFORWARDチェインに追加（APPEND）したことを意味します。これにより、上図の（1）と（3）が可能になります。

　次に、Webサーバからインターネット上のホストへの応答パケットを許可するルールを設定します。これが上図の（2）を可能にするルールです。

　これで、インターネット上のホストからWebサーバへのHTTPのアクセスは許可されたことになります。

　上記のオプションは、次の内容をFORWARDチェインに追加（APPEND）したことを意味します。

　指定したオプションの中に、先ほどとは違うものが含まれています。それは「フラグ」と「ステータス」です。

●flag（フラグ）：

　フラグを条件とする拡張マッチングで、「-p tcp」（--protocol tcp）パラメータを指定したときのみ使用できます。

　TCPパケットには、フラグとしてSYN、SYN/ACK、ACK、RSTなどがセットされています。iptablesでは次のフラグを指定することができます。

　通常は「--tcp-flags」として、チェックするフラグとセットされているべきフラグを指定します。例えば、

とした場合は「すべてのフラグ（ALL）をチェックし、SYNとACKだけがセットされているTCPパケット」を意味します。

　「--syn」は「--tcp-flags SYN,RST,ACK SYN」の省略形で、「SYN、RST、ACKフラグをチェックし、SYNだけがセットされているTCPパケット」という意味になります。上記のオプションには「! --syn」が指定されています。前回も紹介したように「!」は条件を反転させるパラメータですから、「SYNビットがクリアされてACKとFINビットがセットされているTCPパケット」となります。

　なぜこのオプションを指定することが必要なのか考えてみましょう。通常、サーバであれば自分自身からほかのホストへ接続することはほとんどないでしょう（注）。上記のルールは、アクセスに対する応答を許可するためのものです。接続の開始にセットされ、シーケンス番号の初期化に使われるSYNフラグがセットされたパケットの通過を許可する必要はないのです。SYNフラグがセットされたパケットの通過を拒否することは、クラッカーに仮に侵入されたとしてもほかのホストへの踏み台とさせないためにとても有効な手段となるのです。

●status（ステータス）：

　パケットの状態をチェックしたりする際に使用する拡張マッチングで、--stateを使うには「-m state」が必要です。つまり、必ず「-m state --state」という形を取ります。今回の例では引数として「ESTABLISHED」が与えられています。ESTABLISHEDなセッション、つまり双方向のコネクションのパケットを許可するということになります。

　flagとセットで指定することで、クラッカーに侵入されてしまってもほかのホストへの踏み台とされないようにします。これも大切なセキュリティ対策の1つと考えられます。

　以上、Webサーバを例に設定方法を紹介しました。メールサーバやDNSサーバへのアクセス許可も、これを参考にすれば設定できるでしょう。

INPUT／OUTPUTチェイン

　外部のホストからファイアウォール自身に、メンテナンスなどのために接続することがあるかもしれません。それを許可するルールを追加するのがINPUTおよびOUTPUTチェインになります。INPUTおよびOUTPUTチェインの設定を行っていないと、ファイアウォールそのもののサービスが無防備になるか、逆にまったくアクセスできないということになってしまいます。

■INPUT／OUTPUTチェインの設定

　メンテナンスを行うためのホストを限定し、22/TCP（ssh）での接続を許可するような場合を考えてみましょう。

メンテナンス用ホスト（172.16.1.150）から、ファイアウォールの外側のインターフェイスeth0（172.16.0.100）に対する22/TCP（ssh）による接続を許可する。

　INPUTチェインには外部からホストへ入ってくるためのルールを、OUTPUTチェインにはホストから外部へ出ていくためのルールを追加します。FORWARDチェインと同じで、入ってくるパケットに対する応答が外部に出ていくことを許可するルールを作成しなければなりません。

　指定されているオプションはこれまでに説明したものばかりなので、特に説明は必要ないでしょう。ここで注意すべき点は、OUTPUTチェインです。FORWARDチェインを作成したときと同じく、flagとstatusにオプションを指定して外部へ接続できないようにすることです。

ICMPの処理

　ホストの生存確認を行うために、pingコマンドを使うことは多いのではないでしょうか。ファイアウォール自身についてはEcho Replyを返す必要はありません。しかしながら、DMZ上のホストに関しては生存確認を行いたいと思うことがあるかもしれません。iptablesでアクセス制御を行っているホストは、ICMPについても意図的に通るようにする必要があります。

■生存確認に必要なICMP-TYPEは？

　iptablesでは、ICMPのTYPEを指定することができます。pingコマンド使うのであれば、Echo Requestを受け付け、Echo Replyを返すことができればいいのです。このICMP-TYPEについて簡単に説明しておきましょう。

　ICMPヘッダの中身は、Typeフィールドから始まります。このTypeフィールドの指定番号によって、ICMPメッセージの種類などが決定されます。ICMPには次のようなTypeメッセージが規定されています。

　iptablesでは、この番号を指定することができます。ホストの生存確認はpingコマンドを用いることが多いかと思います。pingコマンドは、Echo Requestを目的のホストに向かって送信し、その応答としてEcho Replyが返ってくるのを確認します。そこで、ここでは生存確認を目的とし、Echo RequestとEcho Replyを双方向に許可するためのルールを追加することにしましょう。iptalbesのオプションとしては「--icmp-type」を指定し、引数としてICMP Type番号を指定します。

生存確認のためメンテナンス用のホスト（172.16.1.150）から、Webサーバ（192.168.0.10）に対するEcho Requestと、その応答のためのEcho Replyを許可する。

　この設定もまた、これまでに説明したオプションの指定方法とそれほど違いはありません。プロトコルがICMPになったことに注意すればいいでしょう。

■ブロードキャストあてICMPの拒否

　ファイアウォールの外側のインターフェイスに対する生存確認のためのEcho Requestを許可すべきではないでしょう。ましてやブロードキャストあてのicmp-echoには応答する必要もありません。ブロードキャストあてのICMPは、カーネルパラメータを調整することでまったく受け付けなくすることができます。

　ブロードキャストあてICMPを拒否する場合は、/etc/sysctl.confファイルに設定を記述します。OS起動時にsysctlコマンドが実行されることで、この設定が反映されます。ブロードキャストあてのicmp-echoを無視するには、設定ファイルに次の1行を追加します。

　カーネルパラメータを調整することで、ソースアドレスを偽造していないかチェックするような設定もできますが、これには注意が必要です。あまりやり過ぎると、本来の動作をしなくなってしまう危険があります。

総仕上げ：ルールのスクリプト化

　パケットフィルタリングの設定方法について一通り解説してきました。これまでのことが理解できればファイアウォールを構築できるでしょう。では、実際にファイアウォール用のルールを作成していきましょう。

　ルールを1つ1つ入力してもよいのですが、OSをリブートするたびに同じ作業を繰り返すことになります。効率的ではないしミスも発生するでしょう。以前に紹介したipchainsと同様に、スクリプトを作成することをお勧めします。以下のようなスクリプトを適当なファイル名で作成します。

　スクリプトの作成が終わったら、実行権限を与えて実行すればルールが反映されます。

　しかし、このままではOSの起動時にこの設定は反映されません。そこで、次のコマンドを実行します。

　これでファイアウォールの構築作業は取りあえず完了です。次回は、構築したファイアウォールの動作確認方法などについて説明したいと思います。