3.3. IPフィルタの計画の仕方

ファイヤーウォールを計画する上でまず最初のステップは、それをどこに置くかだ。ネットワークはたいてい、はっきりとセグメントに分かれているので、これにはそう迷わない。最初に頭に浮かぶのはローカルネットワークとインターネットを隔てるゲートウェイ。ここはかなりタイトなセキュリティを施してしかるべき場所だ。また、大規模なネットワークでは、部署同士をファイヤーウォールで仕切るのも良い考えだ。例えば、開発部が人事部のネットワークへアクセスできる必要があるだろうか。経理部を他のネットワークからガードしない道理があるだろうか。早い話、解雇通知をよこされて頭に来ている従業員に給与データベースを見せて気が紛れるはずもないだろう。

上で言えることは、つまり、そもそもネットワーク自体を組み上げる時によく考え、区画に分けておかなければならないということだ。中/大規模なネットワーク (ワークステーションが 100 台以上の場合。何を基準に大小を論じるかにもよるが) では特にそうだ。小分けにしたネットワーク同士を、通過させたいトラフィックだけを通すようなファイヤーウォールでつなぎ合わせればいい。

また、インターネットからアクセスを受けるサーバがある場合には、ネットワーク内にデミリタライズゾーン (De-Militarized Zone = 非武装地帯, DMZ ) を構築するのも一案だ。 DMZ は極限までアクセスを制限した何台かのサーバから成る物理的に独立した小さな隔離ネットワークのこと。この方法を用いれば、 DMZ 内のマシンに誰かが入り込める可能性は低くなり、潜り込んで外界からトロイの木馬などをダウンロードされる危険性が抑えられる。非武装地帯と呼ばれる理由は (DMZ 一般を一口に言ってしまえば) そこが内側からも外側からもアクセスできる、一種のグレーゾーンだからだ。

ファイヤーウォールにポリシーや既定動作を持たせるには幾つかの方法がある。このセクションでは、実際にファイヤーウォールの実装を始める前に検討すべき実践的なセオリーについて説明する。実装に際して有益な判断材料となるだろう。

まず基本中の基本として、ファイヤーウォールにはほぼ必ず、既定の動作というものがあることを理解しておかなければならない。例えば、或るチェーンの中でそのパケットに合致するルールがひとつも無かった時には、既定動作で drop または accept される。残念ながら各チェーンの持てるデフォルトポリシーはひとつだけだが、例えばネットワークインターフェイス毎に別々のポリシーを与えるなどして、この問題を克服することもできる。

一般によく使うポリシーには 2 つのパターンがある。指定したもの以外は全部 drop するか、反対に、破棄すると指定したもの以外を全て accept するかだ。ほとんどの場合に我々の興味を引くのは専ら drop 型ポリシーのほうで、許可したいものは全て具体的に指定して受け入れる。 drop 型ポリシーは、安全性が高いという事実がある反面、ファイヤーウォールを正常に機能するところまで持っていくだけでも accept 型よりずっと手間がかかる。

あなたが迫られる最初の決断は、どちらのタイプのファイヤーウォールが適切かだ。セキュリティの重大性はどれくらいだろうか。ファイヤーウォール越しにどんなアプリケーションを利用するのだろうか。一部のアプリケーションは、データストリームに使用するポートがコントロールセッション内でのネゴシエーション (話し合い)で決められるという理由から、ファイヤーウォールにとって嫌な相手だ。ファイヤーウォールにとっては、開くポートを知るのが非常に困難なのだ。 iptables は一般的なアプリケーションならばそのほどんどを扱えるが、一般的でないアプリケーションの中には、残念ながらまだ対応していないものもある。

また、多重セキュリティ戦略を用いるのも良いことだ。実は、その一部については既に言及している。どういうことかというと、できるだけ多くの安全策を張り巡らし、単一の政策に頼り切らないようにするのだ。そうしたコンセプトを採ることによって、軽く 10倍はセキュリティを高めることができる。例としてこれを見てもらおう。

ご覧のように、この例では全てのネットワークコネクションの接点となる位置に 1台の Cisco PIX ファイヤーウォールを据えている。このファイヤーウォールは内部の LAN を NAT し、また必要に応じて DMZ に対しても NAT を行ことになるだろう。また、 http, ftp, ssh の戻りのトラフィックを除いた外向きのトラフィックをすべてブロック。 LAN 及びインターネットからやってくる http トラフィックは通し、 LAN からは ftp, ssh トラフィックも許可するとしよう。これに加えて、 WEB サーバはいずれも Linux で動いていると仮定して、それらサーバ自体にも iptables 及び netfilter を投入し、基本的にファイヤーウォールと同様のポリシーを持たせる。このようにしておけば、万が一何者かが Cisco PIX の陥落に成功したとしても、各マシンのローカルの netfilter ファイヤーウォールが我々を守ってくれるし、その逆もまた大丈夫というわけだ。こうした施策を多重セキュリティと呼ぶ。

そこへ上乗せして、各マシンで Snort を動かすという手もある。 Snort は優れたオープンソースのネットワーク侵入検出システム (NIDS = network intrusion detection system) で、接したパケットの中のシグネチャを検査する。そしてもし何らかのアタックや侵入を示すシグネチャを発見したら、システム管理者へ eメールで知らせたり、さらに一歩踏み込んで、アタックの出所だった IP をブロックするなどの積極的対応を行うこともできる。ただし、積極的対応 は安易に使用してはならないということも言い添えておく。というのも、 Snort にはかなりの誤検出をレポートする悪い癖 (本当はアタックではないのにアタックとして報告するなど) があるからだ。

WEB サーバの手前にプロキシを導入して不正なパケットを捕まえるというのも良い考えだ。あるいはまた、ローカルネットワークからの WEB トラフィック用のプロキシを配置するという手もある。 WEBプロキシを使うと、従業員によって消費されるトラフィックが削減でき、さらに、彼らの WEB 使用量を或る程度制限することさえ可能だ。自社 WEB サーバ用 WEBプロキシのほうは、典型的な侵入の企みを防ぐ効果もある。使ってみる価値のある優秀なプロキシといえば Squid だ。

それ以外に考え得る防衛策のひとつに Tripwire のインストールがある。これは、最終防衛ラインとも言うべき優れたアプリケーションで、ホスト侵入検知システム (Host Intrusion Detection System) と呼ばれるもののひとつだ。 Tripwire は、設定ファイルで指定した全てのファイルに対してチェックサムを作成し、 cron で定期的にチェックすることにより、ファイルが前と変わりないか、改変されていないかを確認する。つまり、何者かがシステムに侵入して不正書き換えを行っていないかを、監視できるわけだ。お勧めするのは、全ての WEB サーバでこれを動かしておくことだ。

そして最後に挙げる重要な留意事項は、もう承知のことかもしれないが、標準化されていない技術や規格を使用しないのが最善であるということだ。 ICQ の話でも分かったように、標準化されていないシステムは使わないようにしないと、ほころびがほころびを呼んで酷いことになる。閉じた環境内でなら多少のことは問題ないが、ブロードバンドサービスやモデムプールを運営する場合には、これは大変重要な問題だ。あなたのところと遣り取りする人は全員あなたのところの規格に従わなければならないわけだが、全員に同じオペレーティングシステムを期待するのは無理な話。ある人は Windows、ある人は Linux、さらには VMS を使いたがる人もいるかもしれない、といった具合だ。セキュリティを特殊なパテント技術に負っていると、某かの問題を抱え込むことになる。

その典型例に、スウェーデンで最近始まった一種のブロードバンドサービスがある。このサービスはマイクロソフトネットワークログオンの上に成り立っている。そう聞いただけでは名案だと思えるかもしれないが、オペレーティングシステムが異なる場合を考えると、これはもう名案どころではない。 Linux ユーザはどうしたらログインできるのか? VAX/VMS だったら? HP/UX は? もちろん Linux であれば利用も不可能ではないが、それもネットワーク管理者がそんなブロードバンドサービス通信をブロックしていなかったとしての話だ。何はともあれ、当文書はどれが一番かを論じる宗教論争本ではないので、非標準化技術の利用が間違いであるという例として触れるだけに留めておく。