ファイアウォールは、インターネット トポロジーにおいて接続された特定のセグメントを隔離するために使われる可能性があります。このようなセグメントが外部インターネットへ複数のリンクをもつとき、接続されたファイアウォールマシンは、すべてのリンク上にあることが要求されます。
ファイアウォールは、プロトコルスタックにおいて、異なる層に実装される可能性があります。それらは、転送する(アプリケーション) ゲートウェイによってアプリケーション層 に、あるいは、フィルタリング ルーターによって IP (インターネット) 層にに実装されることが最も多いです。3.2 節 は、アプリケーション ゲートウェイを検討します。3.3 節 は、セキュリティ 境界を出入りする IP データグラムをフィルタするインターネット層ファイアウォールを含みます。
ファイアウォールについての一般的なアーキテクチャモデルは、ポリシーを分離します。すなわち、コントロール（すなわち、 資源へのアクセスを許可された者に制限すること）から、サービスの要求が、そのサービスへのアクセスが許可される必要があるか否かを判断します。3.1.1 ファイアウォールについての利用 English
ファイアウォールは、インターネット コミュニティにおいて非常に感情的な話題です。コミュニティのメンバーには、「ファイアウォールは、セキュリティ機能 を 1ヵ所に集約し、管理・インストール・設定を単純化するので、ファイアウォールの考え方は、非常に力強い。」と感じている者がいます。他に、ファイアウォールは、いくつかの理由により破壊的であると感じている者もいます。： ファイアウォールは、「柔らかく噛みごたえのある内部をもった硬くバリバリとした殻」を提供します。すなわち、ファイアウォールは、セキュリティ の間違ったセンスを助長し、ファイアウォール境界内部のセキュリティを緩くさせることになります。彼らは、「企業環境における「コンピュータ犯罪」の多くは、 内部者によって犯されており、境界防衛戦略とは関連性がない」と観察します。ファイアウォール支持者は、「ファイアウォール は、追加的な対策として重要である」と反論します。； ファイアウォールを、境界における注意深いセキュリティ管理にとって本質的であるとみなしてはいけません。ファイアウォールをけなす者は、また、複数のログインと他のオフラインのメカニズム、および、インターネットの利用可能性と活力をもった、それらのインターフェイスを要求するファイアウォール使用の困難性について関心を持っています。
しかし、ファイアウォールは、今日、インターネットにおける現実です。それらは、ファイアウォール無しの場合に可能なセキュリティよりも高いレベルのセキュリティに関心をもつ組織体によって、実用的な理由で構築されてきました。この節は、いくつかのファイアウォールの利点と欠点、および、これらが有用であるいくつかの事例を概説することを試みます。
幾千ものホストがある大規模組織体を想定してください。すべてのホストが直接に外界と通信できる場合、攻撃者は、組織体 において最も弱いホストを見つけることによって、組織体の防護を破って、侵入を試み、次にそのホストの資源を使いながら、さらに組織体 内部の侵入を進めることを試みます。考え方によっては、ファイアウォールは、セキュリティ問題に対して、たいした解決策ではありません。それは、ファイアウォールは、より基本的なソフトウェアエンジニアリング／運用管理の問題に対する反応であるからです。： 良いセキュリティのために数多くのホストを設定すること。このより基本的な問題が解決できた場合、ファイアウォールは、一般に、必要不可欠ではなくなります。
ファイアウォールを実装することが組織体中の様々な個人にもたらす影響を考察することは、興味深いことです。最初に、組織体の最も セキュアなホストについて起きる影響について考察してみましょう。このホストは、基本的に、ほとんど何も追加的な防護を受けません。それは、自身の境界防護が、ファイアウォールと同等であるか、それ以上に強固であるからです。さらに、ファイアウォールは、おそらく 、外部世界への通信パスの信頼性とともに、このホストが利用可能な接続性を低減することになり、このホストのユーザにとっては不便になるでしょう。この（最もセキュアな）ユーザの視点からは、ファイアウォールは、損失であるといえます。
他方、貧弱なセキュリティ状態のホストは、ファイアウォールの背後に「隠す」ことができます。より制限された外界と通信する能力と引き替えに、このホストは、ファイアウォールによって提供される、より高いレベルのセキュリティの恩恵を受けることができ 、これは、織体全体において利用可能な最善のセキュリティに基づいていると見なされます。このホストが組織体内部の他のホストとのみ通信したい場合、ファイアウォールによってもたらされる外部通信の制約は、気づきさえされない可能性があります。このホストの視点から、より良いセキュリティは、少額の費用、あるいは無償で得られたのです。
最後に、組織体全体の視点を考えます。ファイアウォールは、組織体全体を通じて、組織体における最善のセキュリティの拡張ができるようにします。このことは、便益です 。（組織体中のすべてのホストの防護が等しい場合を除きます。）また、中央集権的アクセス コントロールも、可能になります。その組織体によっては、これは、便益であるか、費用であるかのいずれかでしょう。組織体内部の「セキュア」なホストは、 損失を認識する可能性がある一方、「セキュアでない」ホストは、便益を受ける可能性があります。組織体全体に対する費用対効果は、それゆえ、組織体 中の「セキュア」なホストと「セキュアでない」ホストの相対的比率に依拠します。
ファイアウォールが意味を成さないいくつかの事例を考えてみましょう。個人は、1つのホストの組織体として考えられます。それゆえ、すべてのホストのセキュリティは、 （通常、）同一であり、定義により組織体にとって利用可能な最善のものです。この場合、ファイアウォールの選択は、シンプルです。この個人 は、外部と通信することを望んでいますか？そうでない場合、（接続しないことによって）「完璧な」ファイアウォールが実装されます。そうである場合、ホスト境界は、ファイアウォール境界と同じになり、よって、ファイアウォールは、必要不可欠ではなくなります。
その他の興味深い事例は、あまり共通の関心を持たない個人から成る組織体です。これは、ネットワークへの公衆アクセスを販売するサービス プロバイダーの事例であるといえます。相関関係をもたない登録者は、おそらく、組織体ではなく、個人として考えられる必要があります。組織体全体のためのファイアウォールは、 この場合、あまり意味をもちません。
要するに、ファイアウォールの恩恵は、それが護る組織体の性格に依拠します。ファイアウォールは、 組織体内部における最善の利用可能な防護を組織体全体に拡張するために使うことができます。それゆえ、数多くの、運用管理が行き届かないホストをもつ大規模な組織体に便益を与えます。しかし、ファイアウォールは、 既に強固なホスト境界をもつ組織体内部の個人には、ほとんど何も便益をもたらさないでしょう。
アプリケーション層ファイアウォールは、下記の図によって表現することができます。
C <---> F <---> S
ここで、要求しているクライアント C は、そのトランスポート接続を、望むサーバー S に直接的にではなく、ファイアウォール F に対してオープンしています。C のリクエストを S' の IP アドレスではなく、F の IP アドレスに再指図するためのメカニズムのひとつは、DNS に基づくことができます。C が S の名前を解決することを試みるとき、その DNS lookup は、（MX レコードと類似した）「サービス再指図」レコード を S のために返します。サービス再指図レコードは、F の IP アドレスを返します。
C は、自身を F に識別させるための何らかの認証情報を入れ、S から特定のサービスを要求する意図を記述します。F は、次に「C がこのサービス を呼び出すことが認可されているか否か」を判定します。C が認可された場合、F は、トランスポート層接続を S に対して開始し、運用を開始し、C と S の間のリクエストとレスポンスを転送します。
IP 層ファイアウォール上のこのシナリオの主要な利点は、「生の IP データグラムは、決してファイアウォールを通過しないこと」です。ファイアウォールは、アプリケーション層において動作するので、通過するすべてのデータ を扱って検証する機会をもつので、「不正なランデブー」攻撃（下記参照）に対して、よりセキュアである可能性があります。
アプリケーション層ファイアウォールもまた、重要な短所をもちます。すべての恩恵を得るためには、アプリケーション層ファイアウォールは、各アプリケーションについて個別にコードを書かれなければなりません。このことは、新しいアプリケーションの配備を厳しく制限します。ファイアウォールは、また、新しい 失敗点を現実のものとします。； ファイアウォールが到達可能であることを止めさせる場合、そのアプリケーションは、失敗します。また、アプリケーション層ファイアウォールは、使われている特定のメカニズムによっては、IP 層ファイアウォールよりも性能に影響を与える可能性があります。
我々の IP 層ファイアウォールのモデルは、一式のルールを各入り方向 IP データグラムに、転送するか否かを判断するために適用する多ポートの IP ルーター です。パケット ヘッダーにおいて利用可能な情報に基づいて IP データグラムを「フィルタ」すると言われます。
通常、ファイアウォールルーターは、一式のフィルタリングルールをもち、各ルールは、「パケット属性」と「対処」を規定します。パケット属性は、特定のヘッダー フィールドについて値を定めます。（例： 発信元 IP アドレス、宛先 IP アドレス、プロトコル番号および他の適当な発信元と宛先を識別する情報 （例えば、ポート番号）。）パケット を突き合わせるために使われる可能性のある情報一式は、「関係性（association）」と呼ばれます。関係性の性格は、オープンな論点です。
ファイアウォールにおける高速データグラム転送パスは、各到着パケットを、すべての有効なルールのすべてのパケット 属性に照らして処理し、属性が一致したとき、対応する対処を行います。典型的な機能には、転送、棄却、失敗レスポンスの送信、もしくは、例外追跡のためのログ取得が含まれる可能性があります。 他のルールが該当しないとき、使われるデフォルト ルールがある可能性があります。これは、おそらく、棄却する対処を規定していることでしょう。
パケット属性に加えて、ファイアウォールによっては、下記 3.3.2 節 において記述したように、パケットを認証するために、いくつかの暗号技術的情報も使う可能性があります。
この節は、使われる可能性のある特定のメカニズムの例とともに、ファイアウォール ルーターのコントロールについてのモデルを提供します。
- クライアント C は、サービス S にアクセスを試みます。（ここにおけるクライアントは、人もしくはプロセス のいずれも意味する可能性があります。これもまた。解決すべき論点です。）
- そのサービスへのアクセス開始は、1つ、もしくは複数のファイアウォール ルーター経由の防護境界を通る試みとなる可能性があります。
- ポリシー コントロール レベルは、ファイアウォール ルーターにおいて、その試みを許可または棄却するためのフィルタを設定します。
ポリシー コントロール レベルは、2つの別個の機能である認証と認可から成ります。認証は、主張されたユーザの身元を検証する機能です。認証機能は、組織体 中の 1ユーザが他の組織体に認証されるうるように、インターネットをまたいで配布される必要があります。一旦、ユーザが認証されたら、次は、 「そのユーザがそのローカル資源に対してアクセスすることが認可されているか」を判定する認可サービスの仕事です。認可が通った場合、ファイアウォール中のフィルタは、アクセスを許可するように更新することができます。
この論点の理解を助けるものとして、我々は、特定の詳細なメカニズムを紹介します。我々は、「このメカニズムは、描画的な例示 としてのみ意図されていること」を強調しておきます。； 実際のメカニズムのエンジニアリングは、間違いなく、多くの変更されることになります。我々のメカニズムは、以下のスケッチによって描かれています。ここで、ユーザは、ファイアウォール F1 の背後のコンピュータ C からファイアウォール F2 の背後のサーバー S に接続することを望んでいます。A1 は、 特定の認証サーバーであり、Z1 は、特定の認可サーバーです。
C は、初期パケットを S 宛に送ることによって、その通信開始を試みます。C は、S の名前を解決するために通常の DNS lookup を使い、 通常の IP ルーティング メカニズムを使います。C のパケットは、ファイアウォール ルーター F1 に到着し、これは、いかなる許容可能なパケット属性 と合致しないので、そのパケットを棄却します。F1 は、F1 が信頼する認証/認可サーバーのリストを示す「認証が要求される」エラー表示を C に返します。この表示は、新種の ICMP 宛先到達不能パケット、もしくは、C と通信するための何らかの他のメカニズムである可能性があります。
C がエラー表示を受け取ったとき、A1 の身元を検証した後、自身をエラー表示中に掲載されていた認証サーバーのひとつである A1 に認証させます。C は、次に、（A1 によって提供されたチケットを使って）サーバー Z1 から認可を要求し、Z1 に、実行することを望むアプリケーションを通知し、F1 を通じて転送することを望む属性をパケットに提供します。Z1 は、次に、C が F1 を通過することを許すか否かを判定するために認可を行います。C が許された場合、Z1 は、ファイアウォール F1 に、パケット属性に合致するパケットについてファイアウォール F1を通過することを許すように通知します。
C のパケットが F1 を突破した後、それらは、再度、2番目のファイアウォール F2 によって棄却される可能性があります。C は、F2 が信頼する認証サーバー A2 と認可 サーバー Z2 と、同様の手順を行うことができます。このことは、下記のイベント順の概要図によって描かれています。
繰り返しになりますが、我々は、「これは、1つの可能なメカニズムの部分的なスケッチとして意図されているに過ぎないこと」を強調ておきます。これは、非対称経路（3.3.3節 参照）の可能性、および、「C と S 間における 2つの方向で属性が異なる可能性があること」を含む、いくつかの顕著な論点を省略しています。
我々は、これについて、ファイアウォールを任意の順にするように一般化することができました。しかし、セキュリティは、「各ファイアウォールがデータ パケットが実際に C から来たことを検証することができること」を要求します。次の節において検討されている、このパケット認証問題は、そのデータが複数、おそらく 2つのファイアウォールが順に横断しなければならない場合、極めて困難である可能性があります。
ファイアウォール ルーターは、再認証を要求する可能性があります。その原因は、次のとおりです。：
- ルーティングの変更によって、パスに追加された。
- 属性の項目が期限切れとなった。
- おそらく許容可能な属性のリストを失うクラッシュ後に、新たに再活性化された。
C が、S が信頼する認証・認可サーバーに接続する場合、C は、S の利用開始時に、これらのサーバーによって与えられたチケットを使って、自身を S に再認証させることを避ける可能性があります。
認証サーバー A1 と、認可サーバー Z1 は、概念的には分離されていますが、それらが同一のコンピュータまたはルーター 上で動作する可能性があり、あるいは、1つのプログラムの別の側面である可能性さえあります。C が An に話すプロトコル、C が Zn に話すプロトコル、および Zn が Fn に話すプロトコルは、これらの注意事項には仕様とされていません。An と共に使われる認証メカニズムとファイアウォール Fn によって要求されるパケット属性は、ポリシーの問題であると考えられます。
我々は、次に、どのように IP 発信元アドレスを偽装することを防ぐか、すなわち、C から来たと書かれているが実際にはそうでない入りパケットを考察します。IP 層ファイアウォールにおいて、このような偽装を防ぐために、3つのメカニズムのクラスがあります。ここに概説したメカニズムは、以下の 4.3節 においても検討されます。
o パケット属性のみ
最低レベルのセキュリティは、パケットを純粋にパケット属性に基づいてフィルタする IP 層ファイアウォールを認めることによります。要するに、これは、今日のフィルタリング ルーターによって使われているアプローチであり、
(1) フィルタリング属性を制御するための認証・認可サーバー
(2) 自動的「認証要求」通知メカニズム
が追加されています。このアプローチは、ほとんど何もセキュリティを提供しません。； これは、他のコンピュータを C によって発信されたかのように見える偽装パケットから、あるいは、C の S に対するトランスポート層接続を乗っ取ることから防いでくれません。o 印付けされたパケット
2番目のレベルのセキュリティにおいて、各パケットは、セキュアハッシュ アルゴリズムによって「印付け」されます。認証サーバー Ai は、 秘密を選択し、それをセキュア ホスト S と、ファイアウォール Fi と秘密を共有している認可サーバー Zi とも共有します。C が送るすべてのパケットは、パケットの中身とその秘密値の両方に依拠するハッシュ値を含んでいます。ファイアウォール Fi は、同一のハッシュ関数を計算し、「そのパケットは、 共有された秘密を知っているコンピュータが起点となっていること」を検証することができます。
このアプローチは、C は、どの程度 Zi と Fi を信頼するかという論点を提起します。それは、それらは、C の秘密を知っており、Zi または Fi は、C を偽装できるからです。C がパス中のすべての Z のものや F のものを信頼しない場合、より強いメカニズム（下記参照）が必要とされます。
複数のファイアウォールがあるとき、C のパケットを認証する際に、より困難な問題分野は、パス中にあります。通過する各ファイアウォール用に別々の印を運ぶことは、パケットの大きさの観点から費用がかかります。他方、1つの印を使うようにするために、すべてのファイアウォールは、 協調する必要があり、このことは、前節において概説したものよりも、はるかに複雑なメカニズムを要求する可能性があります。さらに、これは、すべての認証サーバー Ai と認可 サーバー Zi における相互信頼を要求する可能性があります。； これらのサーバーのどれもが、他のすべてを損なう可能性があります。調査されるべき、その他の可能性は、C のパケットの「エンド to エンド」認証ではなく、「ホップ by ホップ」認証を使うことです。すなわち、各ファイアウォールは、次のファイアウォールによって必要とされるパケット中のハッシュに取り替えます。
多ファイアウォールの発信元認証は、より調査する必要がある困難な問題です。
o パケット署名
3番目のレベルのセキュリティとして、各パケットは、公開鍵／私有鍵暗号アルゴリズムを使って「署名され」ます。C は、Zn と、その公開鍵を共有します。Zn は、それを Fn と共有します。このシナリオにおいて、C は、すべての認可サーバーとファイアウォール のための鍵のペア 1つを安全に使うことができます。認可サーバー 、もしくは、ファイアウォールに、 C を偽装できるものはありません。それは、それらは、正しくパケットに署名できないからです。
パケット署名は、はるかに高いレベルのセキュリティを与えますが、特許申請されていて、かつ、現在は、非常に計算費用がかかる公開鍵暗号アルゴリズムを要求します。； それらの時間は、ハッシュ アルゴリズムのための時間に加算されなければなりません。また、ハッシュを署名することは、一般に、それを、より大きくします。
o 性能
インターネット層ファイアウォールは、汎用性と柔軟性の優位性をもちます。しかし、フィルタリングは、潜在的な性能問題を持ち込みます。性能は、 フィルタリングのために使われるパケット フィールドの数と位置、および、パケットが合致する必要があるルールの数に依存する可能性があります。
サービス妨害攻撃は、「パケット単位のルール突き合わせと棄却がインターフェイスの速度についていくことができること」を要求する。
o マルチキャストする
マルチキャスト トラ一フィックにファイアウォール通過を許すために必要とされるルールは、送信者ではなく、受信者によって提供される必要があります。しかし、これは、3.3.1節において概説したチャレンジ メカニズムとは協働しません。それは、「認証が要求される」通知は、送信者に送られ、受信者には送られないからです。
マルチキャスト通信は、以前の節に記述された 3つのレベルのセキュリティのいずれをも使うことができますが、すべてのファイアウォールは、データ ストリーム の起点者と同一の秘密を共有する必要があるでしょう。その秘密は、受信者に他のチャネルを通じて提供される必要があり、（資源が受信者の率先によって行われる RSVP と同様のやり方で、）受信者が率先してファイアウォールに転送されます。
o 非対称ルーティング
その他のコンピュータ S からファイアウォール F を通じてサービスを利用するクライアント コンピュータ C があるとします。： パケットの S から C への戻りが、パケットの C から S へのときと異なる経路をとる場合、それらは、（F とは違って）パケットを S から C に転送することを認可されていないその他のファイアウォール F' に出会う可能性があります。F' は、
C ではなく S にチャレンジを送りますが、S は、F' によって信頼されているサーバーに自身を認証させるクレデンシャルを持たない可能性があります。幸い、この非対称ルーティング状態は、いかなる非対称な経路もファイアウォールにおいて対象範囲とされている
単一ホームの運用管理ドメインの通常の事例については、問題になりません。o 不正なランデブー
これらのメカニズムには、ファイアウォールの対局にいる 2名のユーザが、ファイアウォールを通過することが認可されているあるプロトコル上に 特別に仕立てたアプリケーションによって、ランデブーすることを防いでくれるものはありません。
例えば、組織体が「特定の情報は取り扱いに注意を要し、構外に許してはならない」というポリシーをもつ場合、ファイアウォールは、 ユーザが取り扱いに注意を要する情報をメールに添付し、外部の任意の主体に送ることができるならば、このポリシーを強制するために十分ではありません。同様に、ファイアウォールは、すべての入り方向のデータについての問題を防ぎません。ユーザがプログラムを入れて、それらを 実行する場合、そのプログラムは、取り扱いに注意を要する情報を開示してしまったり、重要なデータ を変更または削除してしまうトロイの木馬をもつ可能性があります。実行可能コードは、とても多くの形態でやって来て、PostScript ファイル、様々なインタプリタ用のスクリプトおよび sendmail 用のリターン アドレスさえも含まれます。ファイアウォールは、 これらのいくつかを検知することや、何らかの形態の潜在的に危険なコードを探査することができまずが、ファイアウォールは、ユーザがプログラム 中に「データ」のように見えるものを仕込むことを止めることはできません。
我々は、これらの問題をファイアウォール ルーター メカニズムの範囲外の問題であると考えます。これは、これらの論点に対応するためにファイアウォールを所有している組織体によって実施されているポリシーの問題です。
o セキュリティパケットについての透過性
上述のメカニズムを運用することについて、クライアント コンピュータとファイアウォールによって信頼されている認証・認可サーバーの間に使われている「認証が要求される」通知と認証／認可プロトコルは、すべてのファイアウォールによって自動的に転送されなければなりません。 これは、セキュリティに関するパケット属性に基づく可能性があります。代わりに、ファイアウォール ルーターは、この種の通信のためのアプリケーション層ファイアウォール として働きます。よって、ファイアウォール ルーターは、偽装または不正なランデブーを避けるために転送するデータを検証することができます。
3.3.4 ファイアウォールと親和性のあるアプリケーション English
ファイアウォールルーターは、サーバーによってリクエストが開始されて、コールバックと複数の接続（例： FTP） を含む場合の特定の通信 パターンについて問題をかかえています。アプリケーション設計者のために「ファイアウォールと親和性のあるアプリケーション」 を構築することを支援するガイドラインをもつことは、有用であることが示唆されました。次のガイドラインが示唆されました。：
1) 入り方向の呼び出しが無いこと。 （xterm 問題）
2) 固定ポート番号。（portmapper または tcpmux 無し）
3) 全体の再指図が良い。(アプリケーション ゲートウェイ）
4) プロトコル中において再指図をしない。
5) 暗号強度の乱数である 32 bit シーケンス番号。
6) 固定長とヘッダー フィールドの数。
Type フィールドは良いが、固定ポート番号がある場合、それらは不要である。
3.3.5 結論 English
アプリケーション層ファイアウォールと比較すると、IP 層ファイアウォールのスキームは、数多くの便益を提供することができます。：
- エンドホストに追加的認証が要求されない。
- 単一認証プロトコルを、すべての意図するアプリケーションに使うことができる。
- IP 層ファイアウォールは、あまり性能劣化をもたらさない。
- IP 層ファイアウォールは、TCP 接続を配布することなく、クラッシュしても状態回復できる。
- 経路がオープンな TCP 接続を配布することなく変更できる。
- 失敗を引き起こす 1点というものが無い。
- これは、アプリケーションと独立している。
しかし、解決すべき本質的な難しい設計論点があります。特に、複数のファイアウォール、非対称経路、マルチキャスティングおよび性能の分野にあります。
