[要約] RFC 2979は、インターネットファイアウォールの動作と要件についてのガイドラインです。このRFCの目的は、ファイアウォールの設計と運用に関するベストプラクティスを提供することです。
Network Working Group N. Freed
Request for Comments: 2979 Sun
Category: Informational October 2000
Behavior of and Requirements for Internet Firewalls
インターネットファイアウォールの動作と要件
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This memo defines behavioral characteristics of and interoperability requirements for Internet firewalls. While most of these things may seem obvious, current firewall behavior is often either unspecified or underspecified and this lack of specificity often causes problems in practice. This requirement is intended to be a necessary first step in making the behavior of firewalls more consistent across implementations and in line with accepted IP protocol practices.
このメモは、インターネットファイアウォールの行動特性と相互運用性要件を定義します。これらのことのほとんどは明白に思えるかもしれませんが、現在のファイアウォールの動作はしばしば不特定または不足しているため、この特異性の欠如は実際に問題を引き起こすことがよくあります。この要件は、実装全体でファイアウォールの動作をより一貫した、受け入れられているIPプロトコルプラクティスに沿って、必要な最初のステップにすることを目的としています。
The Internet is being used for an increasing number of mission critical applications. Because of this many sites find isolated secure intranets insufficient for their needs, even when those intranets are based on and use Internet protocols. Instead they find it necessary to provide direct communications paths between the sometimes hostile Internet and systems or networks which either deal with valuable data, provide vital services, or both.
インターネットは、ミッションクリティカルアプリケーションの数が増えるために使用されています。このため、多くのサイトでは、これらのイントラネットがインターネットプロトコルに基づいて使用している場合でも、孤立した安全なイントラネットがニーズには不十分であると感じています。代わりに、貴重なデータを扱う、重要なサービスを提供する、またはその両方を扱う、時には敵対的なインターネットとシステムまたはネットワークの間に直接通信パスを提供する必要があると感じます。
The security concerns that inevitably arise from such setups are often dealt with by inserting one or more "firewalls" on the path between the Internet and the internal network. A "firewall" is an agent which screens network traffic in some way, blocking traffic it believes to be inappropriate, dangerous, or both.
このようなセットアップから必然的に生じるセキュリティの懸念は、インターネットと内部ネットワーク間のパスに1つ以上の「ファイアウォール」を挿入することにより、しばしば対処されます。「ファイアウォール」とは、何らかの方法でネットワークトラフィックをスクリーニングし、不適切で、危険であると考えられるトラフィックをブロックするエージェントです。
Note that firewall functions are disjoint from network address translation (NAT) functions -- neither implies the other, although sometimes both are provided by the same device. This document only discusses firewall functions.
ファイアウォール関数はネットワークアドレス変換（NAT）関数からばらばらであることに注意してください - どちらも他を意味しませんが、両方とも同じデバイスによって提供されることもあります。このドキュメントでは、ファイアウォール関数のみについて説明します。
This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in RFC 2119 [2].
このドキュメントは、大文字に表示される用語を使用することがあります。「必要はない」、「「必要」、「そうはない」、「そうでない」、および「そうでなければ」、「必要はない」という用語が大文字に表示される場合、この仕様の特定の要件を示すために使用されています。これらの用語の意味の議論は、RFC 2119 [2]に掲載されています。
Firewalls either act as a protocol end point and relay (e.g., a SMTP client/server or a Web proxy agent), as a packet filter, or some combination of both.
ファイアウォールは、プロトコルのエンドポイントとリレー（たとえば、SMTPクライアント/サーバーまたはWebプロキシエージェントなど）として、パケットフィルターとして機能します。
When a firewall acts a protocol end point it may
ファイアウォールがプロトコルのエンドポイントを動作する場合、
(1) implement a "safe" subset of the protocol,
(1) プロトコルの「安全な」サブセットを実装し、
(2) perform extensive protocol validity checks,
(2) 広範なプロトコルの妥当性チェックを実行し、
(3) use an implementation methodology designed to minimize the likelihood of bugs,
(3) バグの可能性を最小限に抑えるために設計された実装方法を使用してください。
(4) run in an insulated, "safe" environment, or
(4) 断熱された「安全な」環境で実行する、または
(5) use some combination of these techniques in tandem.
(5) これらの手法の組み合わせをタンデムで使用します。
Firewalls acting as packet filters aren't visible as protocol end points. The firewall examines each packet and then
パケットフィルターとして機能するファイアウォールは、プロトコルのエンドポイントとして表示されません。ファイアウォールは、各パケットを調べてからです
(1) passes the packet through to the other side unchanged,
(1) パケットを反対側に通過させて変更せずに渡し、
(2) drops the packet entirely, or
(2) パケットを完全にドロップします
(3) handles the packet itself in some way.
(3) 何らかの方法でパケット自体を処理します。
Firewalls typically base some of their decisions on IP source and destination addresses and port numbers. For example, firewalls may
ファイアウォールは通常、IPソースおよび宛先アドレスとポート番号に基づいて決定の一部を基にしています。たとえば、ファイアウォールはそうするかもしれません
(1) block packets from the Internet side that claim a source address of a system on the internal network,
(1) 内部ネットワーク上のシステムのソースアドレスを主張するインターネット側からのパケットをブロックします。
(2) block TELNET or RLOGIN connections from the Internet to the internal network,
(2) インターネットから内部ネットワークへのテルネットまたはrlogin接続をブロックします。
(3) block SMTP and FTP connections to the Internet from internal systems not authorized to send email or move files,
(3) 電子メールの送信またはファイルの移動を許可されていない内部システムからインターネットへのSMTPおよびFTP接続をブロックします。
(4) act as an intermediate server in handling SMTP and HTTP connections in either direction, or
(4) どちらかの方向でSMTPおよびHTTP接続を処理する際に中間サーバーとして機能するか、
(5) require the use of an access negotiation and encapsulation protocol such as SOCKS [1] to gain access to the Internet, to the internal network, or both.
(5) インターネット、内部ネットワーク、またはその両方へのアクセスを得るには、ソックス[1]などのアクセス交渉とカプセル化プロトコルを使用する必要があります。
(This list of decision criteria is only intended to illustrate the sorts of factors firewalls often consider; it is by no means exhaustive, nor are all firewall products able to perform all the operations on this list.)
（この決定基準のリストは、ファイアウォールがしばしば考慮する一種の要因を説明することのみを目的としています。決して網羅的ではなく、すべてのファイアウォール製品がこのリストのすべての操作を実行することもできません。）
Applications have to continue to work properly in the presence of firewalls. This translates into the following transparency rule:
アプリケーションは、ファイアウォールの存在下で適切に機能し続ける必要があります。これは、次の透明性ルールに変換されます。
The introduction of a firewall and any associated tunneling or access negotiation facilities MUST NOT cause unintended failures of legitimate and standards-compliant usage that would work were the firewall not present.
ファイアウォールと関連するトンネリングまたはアクセス交渉施設の導入は、存在しないファイアウォールが機能するのは、正当なおよび標準に準拠した使用の意図しない失敗を引き起こしてはなりません。
A necessary corollary to this requirement is that when such failures do occur it is incumbent on the firewall and associated software to address the problem: Changes to either implementations of existing standard protocols or the protocols themselves MUST NOT be necessary.
この要件の必要な結果は、そのような障害が発生した場合、ファイアウォールと関連するソフトウェアが問題に対処するために義務付けられていることです。既存の標準プロトコルまたはプロトコル自体の実装の変更を必要としないことです。
Note that this requirement only applies to legitimate protocol usage and gratuitous failures -- a firewall is entitled to block any sort of access that a site deems illegitimate, regardless of whether or not the attempted access is standards-compliant. This is, after all, the primary reason to have a firewall in the first place.
この要件は、合法的なプロトコルの使用と無償の障害にのみ適用されることに注意してください。ファイアウォールは、試行が標準に準拠しているかどうかにかかわらず、サイトが非合法とみなすあらゆるアクセスをブロックする権利があります。これは、結局のところ、そもそもファイアウォールを持つ主な理由です。
Also note that it is perfectly permissible for a firewall to provide additional facilities applications can use to authenticate or authorize various sorts of connections, and for the firewall to be configurable to require the use of such facilities. The SOCKS protocol [1] is one example of such a facility. However, the firewall MUST also allow configurations where such facilities are not required for traversal.
また、ファイアウォールがさまざまな種類の接続を認証または承認するために使用できる追加の施設を提供することが完全に許可されており、そのような施設の使用を要求するためにファイアウォールを設定できることに注意してください。ソックスプロトコル[1]は、そのような施設の一例です。ただし、ファイアウォールでは、トラバーサルにそのような施設が必要ない構成も許可する必要があります。
The following sections provide some examples of how the transparency rule actually applies to some specific protocols.
次のセクションでは、透明性ルールが実際にいくつかの特定のプロトコルにどのように適用されるかの例をいくつか示しています。
ICMP messages are commonly blocked at firewalls because of a perception that they are a source of security vulnerabilities. This often creates "black holes" for Path MTU Discovery [3], causing legitimate application traffic to be delayed or completely blocked when talking to systems connected via links with small MTUs.
ICMPメッセージは、セキュリティの脆弱性の源であるという認識のために、一般的にファイアウォールでブロックされます。これにより、Path MTU Discovery [3]の「ブラックホール」が作成され、小さなMTUとのリンクを介して接続されたシステムに通知すると、正当なアプリケーショントラフィックが遅れたり、完全にブロックされたりします。
By the transparency rule, a packet-filtering router acting as a firewall which permits outgoing IP packets with the Don't Fragment (DF) bit set MUST NOT block incoming ICMP Destination Unreachable / Fragmentation Needed errors sent in response to the outbound packets from reaching hosts inside the firewall, as this would break the standards-compliant usage of Path MTU discovery by hosts generating legitimate traffic.
透明性ルールにより、ファイアウォールとして機能するパケットフィルタリングルーターは、発信しないIPパケットを使用しない（DF）ビットセットで発信するIPパケットを許可します。 ホストはファイアウォール内にあります。これにより、正当なトラフィックを生成するホストによるパスMTU発見の標準に準拠した使用が破損するためです。
On the other hand, it's proper (albeit unfriendly) to block ICMP Echo and Echo Reply messages, since these form a different use of the network, or to block ICMP Redirect messages entirely, or to block ICMP DU/FN messages which were not sent in response to legitimate outbound traffic.
一方、ネットワークの異なる使用を形成するか、ICMPをブロックするか、送信されなかったICMP DU/FNメッセージをブロックするため、ICMPエコーとエコーの応答メッセージをブロックし、エコー応答メッセージをブロックすることは適切です（友好的ではありませんが）適切です。合法的なアウトバウンドトラフィックに応じて。
The original SMTP protocol [4] didn't provide a mechanism for negotiating protocol extensions. When this was added [5], some firewall implementations reacted by simply adding the EHLO command to the list of accepted commands. Unfortunately, this is not sufficient: What is necessary is for the firewall to scan the list of EHLO responses and only allow the ones the firewalls understands through. If this isn't done the client and server can end up agreeing to use an extension the firewalls doesn't understand, which can then lead to unnecessary protocol failures.
元のSMTPプロトコル[4]は、プロトコル拡張を交渉するためのメカニズムを提供しませんでした。これが追加された場合[5]、一部のファイアウォール実装は、Ehloコマンドを受け入れられたコマンドのリストに追加するだけで反応しました。残念ながら、これは十分ではありません。必要なのは、ファイアウォールがEhlo応答のリストをスキャンし、ファイアウォールが理解しているもののみを許可することです。これが行われない場合、クライアントとサーバーは、ファイアウォールが理解できない拡張機能を使用することに同意することになり、不要なプロトコルの障害につながる可能性があります。
Firewalls are a fact of life that application protocols must face. As such, application protocols SHOULD be designed to facilitate operation across firewalls, as long as such design choices don't adversely impact the application in other ways. In addition, application protocol specifications MAY include material defining requirements firewalls must meet to properly handle a given application protocol.
ファイアウォールは、アプリケーションプロトコルが直面しなければならない生活の事実です。そのため、アプリケーションプロトコルは、そのような設計の選択が他の方法でアプリケーションに悪影響を与えない限り、ファイアウォール全体の操作を容易にするように設計する必要があります。さらに、アプリケーションプロトコルの仕様には、特定のアプリケーションプロトコルを適切に処理するために、ファイアウォールが満たさなければならない要件を定義する材料の定義が含まれる場合があります。
Examples of proper and improper application protocol design include:
適切で不適切なアプリケーションプロトコル設計の例は次のとおりです。
(1) Wrapping a new protocol around HTTP and using port 80 because it is likely to be open isn't a good idea, since it will eventually result in added complexity in firewall handling of port 80.
(1) HTTPの周りに新しいプロトコルをラップし、ポート80を使用することは、最終的にポート80のファイアウォール処理に複雑さが追加されるため、最終的に複雑になるため、ポート80を使用することは良い考えではありません。
(2) Defining a secure subset of a protocol is a good idea since it simplifies the firewall design process.
(2) プロトコルの安全なサブセットを定義することは、ファイアウォール設計プロセスを簡素化するため、良い考えです。
(3) Specificating an appropriate firewall traversal mechanism if one exists is a good idea.
(3) 適切なファイアウォールトラバーサルメカニズムが存在する場合は、良いアイデアです。
(4) Registering a separate port for new protocols is a good idea.
(4) 新しいプロトコル用に別のポートを登録することは良い考えです。
Good security may occasionally result in interoperability failures between components. This is understood. However, this doesn't mean that gratuitous interoperability failures caused by security components are acceptable.
良好なセキュリティは、コンポーネント間の相互運用性の障害を引き起こすことがあります。これは理解されています。ただし、これは、セキュリティコンポーネントによって引き起こされる無償の相互運用性の障害が受け入れられることを意味するものではありません。
The transparency rule impacts security to the extent that it precludes certain simpleminded firewall implementation techniques. Firewall implementors must therefore work a little harder to achieve a given level of security. However, the transparency rule in no way prevents an implementor from achieving whatever level of security is necessary. Moreover, a little more work up front results in better security in the long run. Techniques that do not interfere with existing services will almost certainly be more widely deployed than ones that do interfere and prevent people from performing useful work.
透明性ルールは、特定の単純なファイアウォール実装手法を排除する限り、セキュリティに影響を与えます。したがって、ファイアウォールの実装者は、特定のレベルのセキュリティを達成するために少し懸命に作業する必要があります。ただし、透明性ルールは、実装者が必要なレベルのセキュリティを達成することを決して妨げません。さらに、もう少し前もって作業すると、長期的にはセキュリティが向上します。既存のサービスを妨げないテクニックは、ほとんど確実に、人々が有用な仕事をすることを妨げ、妨げるものよりもほぼ確実に展開されます。
Some firewall implementors may claim that the burden of total transparency is overly onerous and that adequate security cannot be achieved in the face of such a requirement. And there is no question that meeting the transparency requirement is more difficult than not doing so.
一部のファイアウォールの実装者は、総透明性の負担は過度に面倒であり、そのような要件に直面して適切なセキュリティを達成できないと主張する場合があります。そして、透明性要件を満たすことがそうしないよりも難しいことは間違いありません。
Nevertheless, it is important to remember that the only perfectly secure network is one that doesn't allow any data through at all and that the only problem with such a network is that it is unusable. Anything less is necessarily a tradeoff between usability and security. At present firewalls are being circumvented in ad hoc ways because they don't meet this transparency requirement and this necessarily weakens security dramatically. In other words, the only reason that some firewalls remain in use is because they have essentially been disabled. As such, one reason to have a transparency requirement is to IMPROVE security.
それにもかかわらず、完全に安全なネットワークは、データをまったく許可しないネットワークであり、そのようなネットワークの唯一の問題は使用できないことであることを覚えておくことが重要です。それ以下は、必然的にユーザビリティとセキュリティの間のトレードオフです。現在、この透明性の要件を満たしておらず、これによりセキュリティが劇的に弱体化するため、ファイアウォールはアドホックな方法で回避されています。言い換えれば、一部のファイアウォールが使用されている唯一の理由は、本質的に無効になっているためです。そのため、透明性の要件を持つ理由の1つは、セキュリティを改善することです。
Bill Sommerfeld provided the text for the Path MTU Discovery example. This document has benefited from discussions with a number of people, including but not limited to: Brian Carpenter, Leslie Daigle, John Klensin, Elliot Lear, and Keith Moore.
Bill Sommerfeldは、Path MTU Discoveryの例のテキストを提供しました。この文書は、ブライアン・カーペンター、レスリー・デイグル、ジョン・クレンシン、エリオット・リア、キース・ムーアなど、多くの人々との議論の恩恵を受けていますが、これに限定されません。
[1] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Jones, "SOCKS Protocol Version 5", RFC 1928, April, 1996.
[1] Leech、M.、Ganis、M.、Lee、Y.、Kuris、R.、Koblas、D。、およびL. Jones、「Socks Protocolバージョン5」、RFC 1928、1996年4月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[3] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[4] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[4] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[5] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[5] Klensin、J.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「SMTP Service Extensions」、STD 10、RFC 1869、1995年11月。
Ned Freed Sun Microsystems 1050 Lakes Drive West Covina, CA 91790 USA
Ned Freed Sun Microsystems 1050 Lakes Drive West Covina、CA 91790 USA
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: ned.freed@innosoft.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。