English

インターネットファイアウォールのふるまいとその要件
(Behavior of and Requirements for Internet Firewalls)

このメモの位置づけ

このメモは、インターネットコミュニティのために情報を提供します。 これは、 いかなる種類のインターネット標準をも仕様化するものではありません。 このメモの配布に制限はありません。

著作権表記

Copyright (C) The Internet Society (2000). All Rights Reserved.

要旨

このメモは、 インターネットファイアウォールのふるまいについての特徴と、 その相互運用可能性要件を規定します。 これらの事項の大部分は、自明であるかもしれませんが、 現在のファイアウォールのふるまいは、しばしば仕様化されてこなかったり、 もしくは仕様化されておらず、この仕様の欠如が、 しばしば実際に問題を起こしています。 この要件は、ファイアウォールのふるまいを、実装において、 より一貫したものにし、許容されているIPプロトコル実践の流れに納めるようにする最初のステップとなることが意図されています。

1. はじめに English

インターネットは、 ますます多くのミッションクリティカルなアプリケーションによって利用されるようになってきています。 このことによって多くのサイトが、 たとえ分離されたセキュアなイントラネットがインターネットプロトコルに基づいて、 これを使用していても、 彼らのニーズにとって不十分であることを認識するようになってきています。 その代わりに彼らは、しばしば敵意をもつインターネットと、 価値あるデータを扱っている、決定的に重要なサービスを提供している、 あるいは両方であるシステムもしくはネットワークとの間の、 直接的なコミュニケーションパスを提供することが必要不可欠であると認識するようになってきています。

このようなステップから不可避的に提起されるセキュリティの関心事は、 しばしば、ひとつ、もしくはそれ以上の「ファイアウォール」を、 インターネットと内部ネットワークとの間のパス上に挿入することによって扱われます。 「ファイアウォール」は、 何らかのやり方でネットワークトラフィックをスクリーンする、不適切、 危険と認識するトラフィックをブロックする、 あるいは両方であるエージェントです。

ファイアウォール機能は、 NAT (network address translation)機能とは別個のものであることを銘記しておいてください。 (いずれも他方を意味することはありませんが、しばしば、 両者は同一のデバイスによって提供されます。 この文書はファイアウォール機能のみを検討します。)

1.1. 要件の表記法 English

この文書は、しばしば、大文字で表現された用語を使用します。 "MUST"、"SHOULD"、"MUST NOT"、"SHOULD NOT"、 "MAY"といった用語が大文字で表現されている場合、それらは、 この仕様の特定の要件を表現するために使用されています。 これらの用語の意味の検討は、 RFC 2119 にあります [2]。

2. 特徴 English

ファイアウォールは、 プロトコル終点とリレー(例：SMTPクライアント／サーバー、 またはWebプロキシエージェント)としても、パケットフィルタとしても、 両者の何らかの組み合わせとしての役割も果たします。

ファイアウォールがプロトコル終点の役割を果たす場合、これは……

1. 「安全な」そのプロトコルのサブセットを実装します。
2. 拡張的なプロトコルの妥当性チェックを行います。
3. バグの類を最小化するために設計された実装手法を使用します。
4. 分離された「安全な」環境で走らます。
5. これらのテクニックの何らかの組み合わせを縦列に使用します。

パケットフィルタの役割を果たしているファイアウォールは、 プロトコル終点としては見えません。 ファイアウォールは、各パケットを検査し、それから……

1. そのパケットを他のサイドに変更を加えずに転送します。
2. そのパケットを完全にドロップします。
3. そのパケット自体を何らかのやり方で扱います。

ファイアウォールは典型的には、 その判定のいくつかはIPのソースとデスティネーションのアドレスとポート番号に基づいて行います。 例えば、ファイアウォールは……

1. 内部ネットワーク上のシステムのソースアドレスをもったインターネット側からのパケットをブロックします。
2. インターネットから内部ネットワークへのTELNETまたはRLOGINコネクションをブロックします。
3. メールを送ること、 もしくはファイルを動かすことが認可されていない内部システムからインターネットへのSMTPとFTPコネクションをブロックします。
4. 両方向においてSMTPとHTTPコネクションを扱う際に中間のサーバーとしての役割をはたします。
5. インターネットに、内部ネットワークに、または両方に、 アクセスするのにSOCKS [1] のようなアクセスネゴシエーションとカプセル化を行うプロトコルの使用を要求します。

(この検討クライテリアのリストは、 ファイアウォールがしばしば考慮する要素の類を表現することのみを意図しています。； これは決して網羅性があるわけでも、 すべてのファイアウォール製品がこのリスト上のすべてのオペレーションを行うことができるわけでもありません。)

3. ファイアウォール要件 English

アプリケーションは、 ファイアウォールが存在していても正しく働き続ける必要があります。 これは下記の透過性ルールに換言されます。：

ファイアウォールや、いかなる類似のトンネリング、 もしくはアクセスネゴシエーションファシリティの導入は、 ファイアウォールが存在しなかったら動作するであろう、正規の、 標準に準拠した用法の意図しない失敗を引き起こしてはなりません(MUST NOT)。

この要件による必要不可欠な帰結は、このような失敗が実際に起きた場合、 その問題に対応することは、 そのファイアウォールと関連するソフトウェアの義務であるということです。： 既存の標準プロトコルの実装への変更も、そのプロトコル自体への変更も、 必要不可欠であってはなりません(MUST NOT)。

この要件は、 正規のプロトコル用法と根拠のない失敗にのみ適用されることを銘記しておいてください。 ファイアウォールは、 試みられたアクセスが標準に準拠しているか否かにかかわらず、 サイトが正規でないとみなすいかなる類のアクセスをもブロックすることができます。 結局のところ、 これが真っ先にファイアウォールをもつ主要な理由のひとつです。

ファイアウォールには、 アプリケーションが様々な種類のコネクションを認証、 もしくは認可するのに使用できる追加的なファシリティを提供することと、 そのファイアウォールが、 そのようなファシリティの使用を要求する設定が可能であることが、 完全に許容されていることも銘記しておいてください。 SOCKSプロトコル [1] は、このようなファシリティの一例です。 しかし、ファイアウォールは、また、 そのようなファシリティが通過に要求されない設定も許容しなければなりません(MUST)。

3.1. 例示 English

以降の節は、 どのように透過性ルールが実際に特定のプロトコルに適用されるかについて、 いくつかの例示を提供します。

3.1.1. Path MTU DiscoveryとICMP English

ICMPメッセージは通常、セキュリティ脆弱性の元であるという認識により、 ファイアウォールでブロックされます。 このことは、しばしば、Path MTU Discovery [3] について「ブラックホール」を作り出し、 正規のアプリケーショントラフィックが小さなMTUのリンク経由でシステムと話す場合、 遅延したり、または完全にブロックされるようにしてしまいます。

透過性ルールによって、 DF (Don't Fragment)ビットセットをもった外に出ていくIPパケットを許容する、 ファイアウォールとしての役割を果たしているパケットフィルタリングルーターは、 ファイアウォール内の到達ホストからの外に出ていくパケットに対応して送られた、 中に入ってくるICMP Destination Unreachable／Fragmentation Neededエラーをブロックしてはなりません(MUST NOT)。 それは、これが、正規のトラフィックを生成するホストによるPath MTU discoveryの標準に準拠した用法を破るからです。

他方で(親しみにくいのですが)、 ICMP EchoとEcho Replyメッセージをブロックすること、 ICMP Redirectメッセージを完全にブロックすること、 正規の外に出ていくトラフィックへの対応としてではないICMP DU/FNメッセージをブロックすることは正しいことです。 それは、これらが、ネットワークの別の用法を形成するからです。

3.1.2. SMTP拡張 English

当初のSMTPプロトコル [4] は、 ネゴシエーションプロトコル拡張のための機構を提供しませんでした。 これが追加されたとき [5]、 ファイアウォール実装者には、 単にEHLOコマンドを受容されるコマンドのリストに追加することによって対応した者がいました。 残念ながら、これでは不充分です。： 必要不可欠なことは、 ファイアウォールがEHLOレスポンスのリストをスキャンし、 ファイアウォールが理解するもののみを許容することです。 これがなされていない場合、そのクライアントとサーバーは、 ファイアウォールが理解しない拡張を使用する同意を得ることを止めることがあり、 これは不要なプロトコルの失敗を招く可能性があります。

4. アプリケーション要件 English

ファイアウォールは、 アプリケーションプロトコルが直面しなければならない避けがたい現実です。 このようにアプリケーションプロトコルは、このような設計の選択肢が逆に、 アプリケーションを別なやり方で影響を与えない限り、 ファイアウォールをまたぐオペレーションを容易にするように設計される必要があります(SHOULD)。 さらにアプリケーションプロトコル仕様は、 ファイアウォールが与えられたアプリケーションプロトコルを正しく扱うために適合しなければならない要件を規定する題材を含むことができます(MAY)。

正しい／正しくない、アプリケーションプロトコル設計の例には、 下記のものが含まれます。：

1. 新しいプロトコルをHTTPで包み、80番ポートを、 それが空いていることが多いという理由で使用することは、 良いアイディアではありません。 それは最終的に、ファイアウォールに、 ポート80の扱いにおいて、 追加的な複雑性をもたらすことになるからです。
2. プロトコルのセキュアなサブセットを規定することは、 良いアイディアです。 それは、ファイアウォール設計プロセスを単純化するからです。
3. 適切なファイアウォール通過機構が存在すれば、 それを仕様化することは、良いアイディアです。
4. 新しいプロトコルに個別のポートを登録することは、良いアイディアです。

5. セキュリティについての考慮事項 English

良いセキュリティは、ときとして、 コンポーネント間の相互運用可能性の失敗をもたらします。 このことは、理解されています。 しかし、このことは、 セキュリティコンポーネントによって引き起こされた根拠のない相互運用可能性の失敗が受容可能であることを意味するものではありません。

透過性ルールは、 特定の単純化されたファイアウォール実装テクニックを除外する程度に、 セキュリティに影響を与えます。 それゆえ、ファイアウォール実装者は、 一定のレベルのセキュリティを達成するために、 もう少し働かなければなりません。 しかし透過性ルールは、 どのようなレベルのセキュリティが必要不可欠であれ、 実装者が達成することを妨げるものではありません。 さらに、もう少し働くことは、長期的に、 より良いセキュリティをもたらします。 既存のサービスと干渉しないテクニックは、 人々が有用な作業をすることを干渉し妨げるテクニックよりも、 ほぼ確実に広く採用されるようになります。

ファイアウォールの実装者には、 総合的透過性の重い仕事は過度に面倒であり、 このような要件に直面すると適切なセキュリティは達成しえないと批判する者がいるかもしれません。 そして、透過性要件に適合することは、 そうしないことに比べてより困難であることに疑いの余地はありません。

それにもかかわらず、唯一の完全にセキュアなネットワークは、 いかなるデータの通過も全く許容しないものであり、 そのようなネットワークの唯一の問題はそれらが使えないことであることを覚えておくことは重要です。 その次は、不可避的なユーザビリティとセキュリティ間のトレードオフです。 現状においては、ファイアウォールは、この透過性要件に適合しないので、 アドホックなやり方で回避されており、 これは不可避的にセキュリティを劇的に弱くします。 換言すれば、ファイアウォールが使用され続ける唯一の理由は、 それらが実質的に不能にされてきたからです。 このように、透過性要件をもつ理由のひとつは、 セキュリティを「向上させる」ことにあります。

6. 謝辞 English

Bill Sommerfeld氏は、 Path MTU Discoveryの例示のための文章を提供してくれました。 この文書は、多くの人々との検討から恩恵を受けています。 次の人を含みますが、これがすべてではありません。： Brian Carpenter 氏、Leslie Daigle 氏、John Klensin 氏、 Elliot Lear 氏、Keith Moore 氏。

7. 参考文献

8. 著者のアドレス

Ned Freed
Sun Microsystems
1050 Lakes Drive
West Covina, CA 91790
USA

電話： +1 626 919 3600
Fax： +1 626 919 3614
EMail： ned.freed＠innosoft.com

翻訳者のアドレス

宮川 寧夫
情報処理振興事業協会
セキュリティセンター

EMail： miyakawa＠ipa.go.jp

9. 著作権表記全文

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

謝辞

RFCエディタのための財源は現在、 Internet Societyによって提供されています。