前述したように， デュアルホーム・ホストにおいては， 送信元アドレスと到着インタフェースが矛盾するパケットを 廃棄しなければなりません（図 1 参照）。 そのためには入力用チェーンの先頭に
送信元アドレスが内部 LAN のアドレスである 内向きパケットは捨てる
というルールを挿入します。 例えば， 内部 LAN のアドレスが 210.145.125.160 〜 210.145.125.175 の範囲である場合， 図 14 のように実行します。 「-s 210.145.125.160/28」が， パケットの送信元アドレスに対する条件です。 送信元アドレスの先頭 28 ビットの値が 210.145.125.160 であり， かつインターネット側のインタフェース（ppp0）に届いたパケットを廃棄します。
|
# ipchains -I input -j DENY -i ppp0 -s 210.145.125.160/28 |
| 図 14 送信元アドレスが内部 LAN のアドレスである内向きパケットは捨てる |
以上はデュアルホーム・ホストにおけるフィルタリングですが， NIC が 1 枚だけのホストの場合は， 到着インタフェースの条件（-i ppp0 など）の代わりに， 送信元アドレスに基づく条件を用いれば OK です。 例えば， 上記内部 LAN 上のホストにおいて， ACK フラグが 0 で， 内向きのパケットを廃棄するには， 図 15 のように実行します。 「-s !210.145.125.160/28」は， 送信元アドレスの先頭 28 ビットの値が 210.145.125.160 でない（「!」は否定）， という条件です。
|
# ipchains -I input -j DENY -s ! 210.145.125.160/28 -p tcp -y |
| 図 15 ACK フラグが 0 で内向きのパケットを廃棄する |
あるいは， 図 16 のように 3 つのルールで実現することもできます。 この 3 つのコマンドを順に実行すると， 入力用チェーンは図 17 のようになります （「-A」はチェーンの末尾に追加し， 「-I」は先頭に追加するため， 順序が逆になる点に注意してください）。
|
# ipchains -A input -j DENY -p tcp -l # ipchains -I input -j ACCEPT -s 210.145.125.160/28 # ipchains -I input -j ACCEPT -p tcp ! -y |
| 図 16 図 15 の条件を 3 つのルールで実現する |
|
| 図 17 図 16 を実行後の入力用チェーン |
つまり， SYN パケットでなければ最初のルール（!-y）が適用されて ACCEPT, 送信元アドレスが内部のものであれば 2 番目のルール （-s 210.145.125.160/28 ）が適用されて ACCEPT， どちらの条件も成立しなければ最後のルールが適用されて DENY になります。
どちらのフィルタリング設定方法でも構わないのですが， 後者の設定法のように， まずチェーンの最後尾にデフォルトで DENY するルールを設定し， その前に ACCEPT するルールを必要に応じて追加しておく方が， フィルタリング漏れが防げるので好ましいと思います。 いずれの場合も， ローカル・インタフェース（lo）に届いたパケット （つまり自ホストが自身に対して送信したパケット） は無条件に受け入れる設定にしておく必要があります。 図 18 のように実行します。 このルールは， チェーン内において， 他の DENY ルールよりも前にくる必要があります。
|
# ipchains -I input -j ACCEPT -i lo |
| 図 18 自ホストが自身に送信したパケットは無条件に受け入れる |
以上で， 内向き接続を禁止するフィルタリング設定が完了しました。 デュアルホーム・ホストあるいは内部 LAN 上のホストで 対外サービスを行うサーバーを立ち上げる場合は， サービスごとにポートに対する内向き接続のみを許可するルールを挿入していけば OK です。
例えば， SMTP サーバー， ネーム・サーバー， Web サーバーを外部へ公開する場合は， 図 19 を実行します。 「--destination-port」は， あて先ポートの条件を指定するオプションです。
|
# ipchains -I input -j ACCEPT -p tcp --destination-port smtp # ipchains -I input -j ACCEPT -p tcp --destination-port domain # ipchains -I input -j ACCEPT -p tcp --destination-port http |
| 図 19 SMTP サーバーとネーム・サーバーとWeb サーバーを外部へ公開する |
telnet サーバー， POP サーバー， NNTP サーバーなど， よく使われるプロトコルのほとんどはポート番号が違うだけで同様に設定できます。 ところが一筋縄で行かないのがFTP サーバーです。
通常の TCP サービスが， クライアントからサーバーへの TCP 接続だけで済むのに対し， FTP は， もう 1 つ， サーバーからクライアントへの TCP 接続を必要とします。 図 20 のように， FTP クライアントはサーバーに TCP 接続した後， 接続を受け付けるためにポートを開き， そのポート番号をサーバーに伝えます。 するとサーバーはそのポートに対して TCP 接続します。 前者の接続は FTP のコマンドをサーバーに伝えるために使われ， 後者の接続はデータの転送に使われます。
|
|
| 図 20 FTP での接続 |
サーバーからクライアントへ接続する， しかもクライアントが開けるポートはその都度変わる， このプロトコルはファイアウオール管理者にとって頭痛の種と言えるでしょう。 サーバーからクライアントへ接続するのはいくらなんでも論外だ， ということで， 第 2 の接続の方向をクライアントからサーバーへ変更した パッシブ・モードが考案されました。
パッシブ・モードでは， 図 21 のようにクライアントが PASV コマンドをサーバーへ送ると， サーバーは第 2 の接続のポート番号をクライアントへ返します。 これを受けてクライアントは教えられたポートに対して接続します。
|
| 図 21 パッシブ・モードの FTP |
パッシブ・モードだと， クライアント側のファイアウオールは外向き接続のみを通せば良いので， FTP に関して特別扱いをせずに済みます。 現在主流の Web ブラウザの多くが FTP クライアントの機能を持っていますが， FTP クライアントとして動作するときはパッシブ・モードを選択するようです。
パッシブ・モードによりクライアント側の問題は解決されたのですが， 問題がサーバー側に押し付けられただけ， と見ることもできます。 つまりサーバー側から見ると， FTP サーバーが適当に選んだポートに対する内向き接続を 受け付けなければなりません。 このポートは毎回異なるので， それに追随して内向き接続を許可するポートを変更できるファイアウオールが 必要になってしまいます。
仕組みが複雑になればそれだけセキュリティ・ホールの危険が高くなるわけで， パケット・フィルタリングだけのファイアウオールが一番単純で安全なのですが， FTP サーバーを立ち上げようとする限り， ファイアウオールが複雑化してしまいます。 したがって， それだけのコストをかけ， 危険をおかしてまで FTP サーバーを立ち上げる必要があるのか， よく考える必要があります。 Web 登場以前はファイル転送になくてはならない FTP でしたが， 不特定多数のユーザーがサーバーからファイルをダウンロードするために 用いられることがほとんどであり， この用途であれば Web の方がよほど便利です。
特定ユーザー間でのファイル転送であれば， メールに添付して送る＊13， scp コマンドなどで送る， プロバイダなどのホームページ・サービスを利用して， 相手にダウンロードしてもらう， などの方法を使うことができます。
FTP に限らず， セキュリティは常に， 利便性と， 危険性およびコストとのトレードオフの関係にあります。 高機能ファイアウオールのコストと危険性＊14 を考えれば， 大抵の利便性＊15 は犠牲にすべきであると思います。
本稿は日経Linux 2000 年 11 月号に掲載された、 実践で学ぶ、一歩進んだサーバ構築・運用術, 第 8 回「ファイアウォール (後編)」を日経BP 社の許可を得て転載したものです。
Copyright(C)2000 by 仙石浩明 <sengoku@gcd.org>
無断転載を禁じます