[要約] RFC 7288は、ホストファイアウォールに関する洞察と考察を提供するものであり、ネットワークセキュリティの向上を目的としています。
Internet Architecture Board (IAB) D. Thaler
Request for Comments: 7288 Microsoft
Category: Informational June 2014
ISSN: 2070-1721
Reflections on Host Firewalls
ホストファイアウォールに関する考察
Abstract
概要
In today's Internet, the need for firewalls is generally accepted in the industry, and indeed firewalls are widely deployed in practice. Unlike traditional firewalls that protect network links, host firewalls run in end-user systems. Often the result is that software may be running and potentially consuming resources, but then communication is blocked by a host firewall. It's taken for granted that this end state is either desirable or the best that can be achieved in practice, rather than (for example) an end state where the relevant software is not running or is running in a way that would not result in unwanted communication. In this document, we explore the issues behind these assumptions and provide suggestions on improving the architecture going forward.
今日のインターネットでは、ファイアウォールの必要性は業界で一般に受け入れられており、実際にファイアウォールは実際に広く配備されています。ネットワークリンクを保護する従来のファイアウォールとは異なり、ホストファイアウォールはエンドユーザーシステムで実行されます。多くの場合、結果はソフトウェアが実行されていてリソースを消費している可能性がありますが、通信はホストファイアウォールによってブロックされます。この最終状態は、（たとえば）関連するソフトウェアが実行されていない、または望ましくない通信が発生しない方法で実行されている最終状態ではなく、実際に望ましいまたは実際に達成できる最良の状態であると当然と見なされます。 。このドキュメントでは、これらの仮定の背後にある問題を探り、今後のアーキテクチャの改善に関する提案を提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7288.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7288で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Firewall Rules . . . . . . . . . . . . . . . . . . . . . . . 5
3. Category 1: Attack Surface Reduction . . . . . . . . . . . . 6
3.1. Discussion of Approaches . . . . . . . . . . . . . . . . 7
3.1.1. Fix the Software . . . . . . . . . . . . . . . . . . 7
3.1.2. Don't Use the Software . . . . . . . . . . . . . . . 8
3.1.3. Run the Software behind a Host Firewall . . . . . . . 8
4. Category 2: Security Policy . . . . . . . . . . . . . . . . . 9
4.1. Discussion of Approaches . . . . . . . . . . . . . . . . 9
4.1.1. Security Policies in Applications . . . . . . . . . . 9
4.1.2. Security Policies in Host Firewalls . . . . . . . . . 9
4.1.3. Security Policies in a Service . . . . . . . . . . . 10
5. Stealth Mode . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. IAB Members at the Time of Approval . . . . . . . . . . . . . 12
9. Informative References . . . . . . . . . . . . . . . . . . . 12
[BLOCK-FILTER] discusses the issue of blocking or filtering abusive or objectionable content and communications, and the effects on the overall Internet architecture. This document complements that discussion by focusing on the architectural effects of host firewalls on hosts and applications.
[BLOCK-FILTER]は、乱用または不快なコンテンツおよび通信のブロックまたはフィルタリングの問題、およびインターネットアーキテクチャ全体への影響について説明します。このドキュメントは、ホストファイアウォールがホストとアプリケーションに及ぼすアーキテクチャ上の影響に焦点を当てることで、その議論を補足します。
"Behavior of and Requirements for Internet Firewalls" [RFC2979] provides an introduction to firewalls and the requirement for transparency in particular, stating:
「インターネットファイアウォールの動作と要件」[RFC2979]には、ファイアウォールの概要と、特に透過性の要件が記載されています。
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.
ファイアウォールおよび関連するトンネリングまたはアクセスネゴシエーション機能の導入により、ファイアウォールが存在しなかった場合に機能する、正当で標準に準拠した使用法の意図しない障害が発生してはなりません。
Many firewalls today do not follow that guidance, such as by blocking traffic containing IP options or IPv6 extension headers (see [RFC7045] for more discussion).
今日のファイアウォールの多くは、IPオプションやIPv6拡張ヘッダーを含むトラフィックをブロックするなど、そのガイダンスに従っていません（詳細については、[RFC7045]を参照してください）。
In Section 2.1 of "Reflections on Internet Transparency" [RFC4924], the IAB provided additional thoughts on firewalls and their impact on the Internet architecture, including issues around disclosure obligations and complexity as applications evolve to circumvent firewalls. This document extends that discussion with additional considerations.
「インターネットの透過性に関する考察」[RFC4924]のセクション2.1で、IABはファイアウォールと、インターネットのアーキテクチャへの影響について、アプリケーションがファイアウォールを迂回するように進化するにつれ、情報開示の義務や複雑さに関する問題など、追加の考えを提供しました。このドキュメントは、追加の考慮事項でその議論を拡張します。
Traditionally, firewalls have been about arming customers to protect against bugs in applications and services. This document discusses a number of fundamental questions, such as who a firewall is meant to protect from what. It does so primarily, though not exclusively, from an end system perspective with a focus on host firewalls in particular.
従来、ファイアウォールは、アプリケーションとサービスのバグから保護するために顧客を武装させるものでした。このドキュメントでは、ファイアウォールを何から保護するかなど、基本的な質問について説明します。特にホストファイアウォールに重点を置いたエンドシステムの観点から、排他的ではありませんが主にそうします。
While the Internet Security Glossary [RFC4949] contains an extended definition of a firewall, informally, most people would tend to think of a firewall as simply "something that blocks unwanted traffic" (see [RFC4948] for a discussion on many types of unwanted traffic). A fundamental question is, however: "unwanted by whom?"
インターネットセキュリティ用語集[RFC4949]にはファイアウォールの拡張定義が含まれていますが、非公式に言えば、ほとんどの人はファイアウォールを単に「不要なトラフィックをブロックするもの」と考える傾向があります（多くの種類の不要なトラフィックの説明については[RFC4948]を参照してください） ）。ただし、基本的な質問は、「誰が望まないのか」です。
Possible answers include end users, application developers, network administrators, host administrators, firewall vendors, and content providers. We will exclude by definition the sender of the traffic in question, since the sender would generally want such traffic to be delivered. Still, the other entities have different, and often conflicting, desires which means that a type of traffic might be wanted by one entity and unwanted by another entity. Thus, not surprisingly, there exist various types of firewalls, and various types of "arms race" as we will discuss in Section 4.1.2.
考えられる答えには、エンドユーザー、アプリケーション開発者、ネットワーク管理者、ホスト管理者、ファイアウォールベンダー、およびコンテンツプロバイダーが含まれます。送信者は通常、このようなトラフィックの配信を希望するため、問題のトラフィックの送信者を定義から除外します。それでも、他のエンティティには異なる、そしてしばしば相反する欲求があります。これは、あるタイプのトラフィックが1つのエンティティによって要求され、別のエンティティによって望ましくない可能性があることを意味します。したがって、当然のことながら、セクション4.1.2で説明するように、さまざまなタイプのファイアウォールとさまざまなタイプの「武装競争」が存在します。
In this document we distinguish between a "host firewall", which simply intends to protect the single computer on which it runs, and a "network firewall", which is located in the network and intends to protect the network and any hosts behind it.
このドキュメントでは、それが実行されている単一のコンピューターを保護することを単に目的とする「ホストファイアウォール」と、ネットワーク内にあり、ネットワークとその背後にあるホストを保護することを目的とする「ネットワークファイアウォール」を区別します。
A Network Address Translator (NAT) is also often viewed, or even marketed, as a type of network firewall; Section 2.2 of [RFC4864] addresses this misconception, but nevertheless some of the same observations in the present document may also apply to NATs.
Network Address Translator（NAT）も、一種のネットワークファイアウォールと見なされたり、販売されたりします。 [RFC4864]のセクション2.2はこの誤解に対処していますが、それでも本書の同じ観察の一部はNATにも適用される場合があります。
Sandboxed environments, such as those provided by browsers, can also be thought of as a type of host firewall in the more general sense. For example, a cross-site check in a browser can be thought of as a mechanism to block unwanted outbound traffic per a "same origin policy" where a script can only communicate with the "site" from which the script was obtained, for some definition of site such as the scheme and authority in a URI.
ブラウザーによって提供される環境などのサンドボックス環境も、より一般的な意味でのホストファイアウォールの一種と考えることができます。たとえば、ブラウザのクロスサイトチェックは、スクリプトが取得された「サイト」としか通信できない「同じ送信元ポリシー」に従って、不要な送信トラフィックをブロックするメカニズムと考えることができます。 URIでのスキームや権限などのサイトの定義。
The term "application" is used in this document generically to apply to any component that can receive traffic. In this sense, it could refer to a process running on a computer (including a system service) or even to a portion of a TCP/IP stack itself, such as a component that responds to pings.
このドキュメントでは、「アプリケーション」という用語を総称して、トラフィックを受信できるすべてのコンポーネントに適用しています。この意味で、コンピューター（システムサービスを含む）で実行されているプロセス、またはpingに応答するコンポーネントなど、TCP / IPスタック自体の一部を指す場合もあります。
Desires for wanted or unwanted traffic can be expressed in terms of "allow" vs. "block" rules, with some way to resolve conflicting rules. Many firewalls are actually implemented in terms of such rules. Figure 1 shows some typical sources of such rules.
必要なトラフィックまたは不要なトラフィックの要望は、「許可」ルールと「ブロック」ルールの観点から表現でき、競合するルールを解決する方法がいくつかあります。多くのファイアウォールは、実際にはそのようなルールの観点から実装されています。図1は、そのようなルールのいくつかの典型的なソースを示しています。
Source | Consumer | Consumer | Enterprise | Enterprise
| Scenario | Scenario | Scenario | Scenario
| Host | Network | Host | Network
| Firewall | Firewall | Firewall | Firewall
----------+------------+-------------+------------+------------
End user | Sometimes | Sometimes | |
| (as host | (as network | |
| admin) | admin) | |
----------+------------+-------------+------------+------------
App | Yes | Sometimes | |
developer | | (via | |
| | protocols) | |
----------+------------+-------------+------------+------------
Network | | Sometimes | | Yes
admin | | | |
----------+------------+-------------+------------+------------
Host | Sometimes | | Yes |
admin | | | |
----------+------------+-------------+------------+------------
Firewall | Yes | Yes | Yes | Yes
vendor | | | |
----------+------------+-------------+------------+------------
Figure 1: Common Sources of Firewall Rules
図1：ファイアウォールルールの一般的なソース
Figure 1 assumes that network firewalls are administered by network administrators (if any), and host firewalls are administered by host administrators (if any). A firewall may also have rules provided by the firewall vendor itself.
図1は、ネットワークファイアウォールがネットワーク管理者（存在する場合）によって管理され、ホストファイアウォールがホスト管理者（存在する場合）によって管理されることを前提としています。ファイアウォールには、ファイアウォールベンダー自体によって提供されるルールも含まれる場合があります。
End users typically cannot directly provide rules to firewalls that affect other users, unless the end user is a host or network administrator. Application developers can, however, provide such rules to some firewalls, such as providing rules at installation time. They can do this, for example, by invoking an API provided by a host firewall included with the operating system, or by providing metadata to the operating system for use by firewalls, or by using a protocol such as Universal Plug and Play (UPnP) [UPNPWANIP] or the Port Control Protocol (PCP) [RFC6887] to communicate with a network firewall (see Section 4.1.3 for a longer discussion).
エンドユーザーがホストまたはネットワーク管理者でない限り、エンドユーザーは通常、他のユーザーに影響を与えるファイアウォールに直接ルールを提供できません。ただし、アプリケーション開発者は、インストール時にルールを提供するなど、一部のファイアウォールにそのようなルールを提供できます。たとえば、オペレーティングシステムに含まれているホストファイアウォールによって提供されるAPIを呼び出すことによって、ファイアウォールで使用するためにオペレーティングシステムにメタデータを提供することによって、またはユニバーサルプラグアンドプレイ（UPnP）などのプロトコルを使用することによって、これを行うことができます。 [UPNPWANIP]またはポート制御プロトコル（PCP）[RFC6887]を使用してネットワークファイアウォールと通信します（詳細については、セクション4.1.3を参照してください）。
Firewall rules generally fall into two categories:
ファイアウォールルールは通常、次の2つのカテゴリに分類されます。
1. Attack surface reduction: Rules intended to prevent an application from doing things the developer does not want it to do.
1. 攻撃面の縮小：開発者が望まないことをアプリケーションが実行するのを防ぐことを目的としたルール。
2. Security policy: Rules intended to prevent an application from doing things the developer might want it to do, but an administrator does not.
2. セキュリティポリシー：開発者が望んでいることをアプリケーションが実行できないようにすることを目的としたルールですが、管理者はそうではありません。
A firewall is unnecessary if both categories are empty. We will now treat each category in turn, focusing specifically on host firewalls (although some points might be equally applicable to network firewalls).
両方のカテゴリが空の場合、ファイアウォールは不要です。次に、特にホストファイアウォールに重点を置いて、各カテゴリを順番に扱います（ただし、一部のポイントはネットワークファイアウォールにも同様に適用できる場合があります）。
As noted above, this category of firewall rule typically attempts to prevent applications from doing things the developer did not intend.
上記のように、このカテゴリのファイアウォールルールは、通常、アプリケーションが開発者の意図しない動作を行わないようにします。
One might ask whether this category of rules is typically empty, and the answer is that it is not, at present. One reason stems from mitigating the threat of vulnerability exploitation by putting a security barrier in a separate process, isolated from the potentially compromised process. Furthermore, there is also some desire for a "stealth mode" (see Section 5 below).
このカテゴリのルールが通常は空であるかどうかを尋ねる人がいるかもしれませんが、現時点では空ではないという答えがあります。 1つの理由は、セキュリティバリアを潜在的に危険にさらされているプロセスから分離された別のプロセスに配置することにより、脆弱性の悪用の脅威を軽減することから生じます。さらに、「ステルスモード」も必要です（セクション5を参照）。
Hence, typically a firewall will have rules to block everything by default. A one-time, privileged, application-install step adds one or more Allow rules, and then normal (unprivileged) application execution is then constrained by the resulting rules.
したがって、通常、ファイアウォールにはデフォルトですべてをブロックするルールがあります。 1回限りの特権付きのアプリケーションインストール手順で1つ以上の許可ルールが追加され、通常の（特権のない）アプリケーション実行は結果のルールによって制限されます。
A second reason this category of rules is non-empty is where they are used as workarounds for cases the application developer found too onerous to implement. These cases include:
このカテゴリのルールが空ではない2つ目の理由は、アプリケーション開発者が実装するのが面倒すぎると判断した場合の回避策として使用されるためです。これらのケースは次のとおりです。
1. Simple policies that the developer would want but that are difficult to implement. One example might be a policy that an application should communicate only within the local network (e.g., a home or enterprise), but not be reachable from the global Internet or while the device is moved to some public network such as a hotspot. A second example might be the reverse, i.e., a policy to communicate over the Internet but not with local entities. The need for this category would be reduced by better platform support for such policies, making them easier for developers to implement and use.
1. 開発者が望んでも、実装するのが難しい単純なポリシー。 1つの例として、アプリケーションがローカルネットワーク（家庭や企業など）内でのみ通信し、グローバルインターネットからアクセスできない、またはデバイスがホットスポットなどのパブリックネットワークに移動している間は通信できないというポリシーが考えられます。 2番目の例はその逆、つまり、インターネットを介して通信するがローカルエンティティとは通信しないというポリシーです。このカテゴリの必要性は、そのようなポリシーのプラットフォームサポートが改善され、開発者が実装および使用しやすくなるため、減少します。
2. Complex policies where the developer cannot possibly be aware of specifics. One example might be a policy to communicate only during, or only outside of, normal business hours, where the exact hours may vary by location and time of year. Another example might be a policy to avoid communication over links that cost too much, where the definition of "too much" may vary by customer, and indeed, the end host and application might not even be aware of the costs. The need for this category would be reduced by better platform support for such policies, allowing the application to communicate through some simple API with some other library or service that can deal with the specifics.
2. 開発者が詳細を認識できない可能性がある複雑なポリシー。 1つの例としては、通常の営業時間中または営業時間外にのみ通信するポリシーが考えられます。正確な時間は場所や時期によって異なる場合があります。別の例としては、コストがかかりすぎるリンクを介した通信を回避するポリシーがあります。「多すぎる」の定義は顧客によって異なり、実際、エンドホストとアプリケーションはコストを認識していません。このカテゴリの必要性は、そのようなポリシーに対するプラットフォームサポートの改善によって軽減され、アプリケーションは、単純なAPIを介して、詳細を処理できる他のライブラリまたはサービスと通信できるようになります。
When running an application would result in unwanted behavior, customers have three choices, which we will discuss in turn:
アプリケーションを実行すると望ましくない動作が発生する場合、お客様には3つの選択肢があります。
a. fix (or get the developer to fix) the software,
a. ソフトウェアを修正（または開発者に修正を依頼）
b. not use the software, or
b. ソフトウェアを使用しない、または
c. let the software run, but then use a firewall to thwart it and prevent it from working in unwanted ways.
c. ソフトウェアを実行させますが、ファイアウォールを使用してソフトウェアを阻止し、不要な方法で動作しないようにします。
Firewall vendors point out that one can more quickly and reliably update firewall rules than application software. Indeed, some applications might have no way to update them, and support for other applications might no longer be available (e.g., if the developers are no longer around). Most modern operating systems (and any applications that come with them) have automatic updates, as do some independent applications. But until all applications have automatic updates, and automatic updates are actually used, it will still be the case that firewall rules can be updated more quickly than software patches. Furthermore, in some contexts (e.g., within some enterprises), a possibly lengthy retesting and recertification process must be employed before applications can be updated.
ファイアウォールベンダーは、アプリケーションソフトウェアよりも迅速かつ確実にファイアウォールルールを更新できると指摘しています。実際、一部のアプリケーションはそれらを更新する方法がなく、他のアプリケーションのサポートが利用できなくなる場合があります（たとえば、開発者がもういない場合）。最近のほとんどのオペレーティングシステム（およびそれらに付属するすべてのアプリケーション）には、いくつかの独立したアプリケーションと同様に、自動更新があります。ただし、すべてのアプリケーションに自動更新があり、自動更新が実際に使用されるまで、ファイアウォールルールはソフトウェアパッチよりも迅速に更新できる場合があります。さらに、一部のコンテキスト（一部の企業内など）では、アプリケーションを更新する前に、時間がかかる可能性のある再テストと再認証のプロセスを採用する必要があります。
In short, mechanisms to encourage and ease the use of secure automatic software updates are important and would greatly reduce overall complexity. Such mechanisms should allow scheduling updates at appropriate times, taking into account operational considerations such as dependencies, compatibility, testing and maintenance windows.
つまり、安全な自動ソフトウェア更新の使用を促進および容易にするメカニズムは重要であり、全体的な複雑さを大幅に軽減します。このようなメカニズムでは、依存関係、互換性、テスト、メンテナンスウィンドウなどの運用上の考慮事項を考慮して、適切なタイミングで更新をスケジュールできるようにする必要があります。
A key question to ask is whether the application could still do something useful when firewalled. If the answer is yes, then not using the software is probably unrealistic. For example, a game with both single-player and multi-player capabilities could still be useful in single-player mode when firewalled. If instead the answer is no, it is better to not allow the application to run in the first place, and some host firewalls can indeed block applications from running.
重要な質問は、ファイアウォールで保護されている場合でも、アプリケーションが何か有用なことを実行できるかどうかです。答えが「はい」の場合、ソフトウェアを使用しないことはおそらく非現実的です。たとえば、シングルプレイヤーモードとマルチプレイヤー機能の両方を備えたゲームは、ファイアウォールが設定されている場合でも、シングルプレイヤーモードで役立つ場合があります。代わりに答えが「いいえ」の場合は、最初からアプリケーションを実行できないようにすることをお勧めします。一部のホストファイアウォールは、アプリケーションの実行を実際にブロックする可能性があります。
As noted earlier, one disadvantage of this approach is that resources still get consumed. For example, the application can still consume memory, CPU, bandwidth (up to the point of blockage), ports in the transport layer protocol, and possibly other resources depending on the application, for operations that provide no benefit while firewalled.
前述のように、このアプローチの1つの欠点は、リソースがまだ消費されることです。たとえば、アプリケーションは、メモリ、CPU、帯域幅（ブロックポイントまで）、トランスポート層プロトコルのポート、およびアプリケーションによっては他のリソースを消費する可能性がありますが、ファイアウォールで保護されている間はメリットのない操作を実行できます。
A second important disadvantage of this approach is the bad user experience. Typically the application and the end-user won't know why the application doesn't work. A poorly designed application might not cope well and consume even more resources (e.g., retrying an operation that continually fails).
このアプローチの2番目の重要な欠点は、ユーザーエクスペリエンスが悪いことです。通常、アプリケーションとエンドユーザーは、アプリケーションが機能しない理由を知りません。適切に設計されていないアプリケーションは、うまく処理できず、さらに多くのリソースを消費する可能性があります（たとえば、継続的に失敗する操作を再試行するなど）。
A third disadvantage is that it is common for a firewall rule to block more that is appropriate for attack surface reduction, impacting protocol operation and even having adverse effects on other endpoints. For example, some firewalls that cannot perform full deep packet inspection at line speed have adopted a block by default approach to anything they don't understand from the first few bytes; this is very harmful to innovation as it interferes with the ability to deploy new protocols and features.
3番目の欠点は、ファイアウォールルールが攻撃面の縮小に適したものをより多くブロックし、プロトコルの動作に影響を与え、他のエンドポイントに悪影響を与えることもよくあることです。たとえば、回線速度で完全なディープパケットインスペクションを実行できない一部のファイアウォールは、最初の数バイトからは理解できないものに対して、デフォルトでブロックアプローチを採用しています。これは、新しいプロトコルと機能を展開する機能を妨害するため、イノベーションにとって非常に有害です。
As another example, blocking ICMP adversely affects path MTU discovery which can cause problems for other entities (see [RFC4890] and Section 3.1.1 of [RFC2979] for further discussion). This can happen due to lack of understanding all the details of application behavior, or due to accidental misconfiguration. Section 2.1 of [RFC5505] states, "Anything that can be configured can be misconfigured," and discusses this in more detail.
別の例として、ICMPをブロックすると、パスMTUの発見に悪影響を及ぼし、他のエンティティに問題を引き起こす可能性があります（詳細については、[RFC4890]および[RFC2979]のセクション3.1.1を参照してください）。これは、アプリケーションの動作の詳細をすべて理解していないか、誤って設定を誤っているために発生する可能性があります。 [RFC5505]のセクション2.1は、「構成可能なものはすべて誤って構成されている可能性がある」と述べており、これについて詳しく説明しています。
In short, it is important to make applications more aware of the constraints of their environment, and hence better able to behave well when constrained.
要するに、環境の制約をアプリケーションに認識させることが重要であり、制約された場合に適切に動作することができます。
As noted in Section 2, this category of firewall rule typically attempts to prevent an application from doing things an administrator does not want them to do, even if the application developer did.
セクション2で述べたように、このファイアウォールルールのカテゴリは通常、たとえアプリケーション開発者がそうしたとしても、管理者が望まないことをアプリケーションが実行することを妨げようとします。
One might ask whether this category of rules is typically empty, and the answer varies somewhat. For enterprise-scenario firewalls, it is almost never empty, and hence the problems discussed in Section 3.1.3 can be common here too. Similarly, for consumer-scenario firewalls, it is generally not empty but there are some notable exceptions. For example, for the host firewall in some operation systems, this category always starts empty and most users never change this.
このカテゴリのルールが通常は空かどうかを尋ねる人もいるかもしれませんが、答えは多少異なります。エンタープライズシナリオのファイアウォールの場合、ファイアウォールが空になることはほとんどないため、セクション3.1.3で説明した問題がここでも一般的になる可能性があります。同様に、コンシューマーシナリオのファイアウォールの場合、それは通常空ではありませんが、いくつかの注目すべき例外があります。たとえば、一部のオペレーティングシステムのホストファイアウォールでは、このカテゴリは常に空で始まり、ほとんどのユーザーがこれを変更することはありません。
Security policy can be implemented in any of three places, which we will discuss in turn: the application, a firewall, or a library/ service that the application explicitly uses.
セキュリティポリシーは、アプリケーション、ファイアウォール、またはアプリケーションが明示的に使用するライブラリ/サービスの3つの場所のいずれかに実装できます。
In this option, each application must implement support for potentially complex security policies, along with ways for administrators to configure them. Although the explicit interaction with applications avoids the problems discussed in Section 3.1.3, this approach is impractical for a number of reasons. First, the complexity makes it difficult to implement and is error-prone, especially for application developers whose primary expertise is not networking. Second, the potentially large number of applications (and application developers) results in an inconsistent experience that makes it difficult for an administrator to manage common policies across applications, thus driving up training and operational costs.
このオプションでは、各アプリケーションは、複雑になる可能性のあるセキュリティポリシーのサポートと、管理者がそれらを構成する方法を実装する必要があります。アプリケーションとの明示的な相互作用により、セクション3.1.3で説明されている問題が回避されますが、このアプローチは多くの理由で非実用的です。まず、複雑さは実装を困難にし、エラーが発生しやすくなります。特に、ネットワーキングを専門としないアプリケーション開発者にとってはそうです。第2に、潜在的に多数のアプリケーション（およびアプリケーション開発者）は一貫性のないエクスペリエンスをもたらし、管理者がアプリケーション間で共通のポリシーを管理することを困難にし、トレーニングと運用コストを押し上げます。
Putting security policies in firewalls without explicit interaction with the applications results in the problems discussed in Section 3.1.3. In addition, this leads to "arms races" where the applications are incented to evolve to get around the security policies, since the desires of the end user or developer can conflict with the desires of an administrator. As stated in Section 2.1 of [RFC4924]:
アプリケーションと明示的に対話せずにファイアウォールにセキュリティポリシーを配置すると、セクション3.1.3で説明した問題が発生します。さらに、エンドユーザーまたは開発者の欲求が管理者の欲求と競合する可能性があるため、これはアプリケーションが進化してセキュリティポリシーを回避するように動機づけられる「武力競争」につながります。 [RFC4924]のセクション2.1に記載されているとおり：
In practice, filtering intended to block or restrict application usage is difficult to successfully implement without customer consent, since over time developers will tend to re-engineer filtered protocols so as to avoid the filters. Thus, over time, filtering is likely to result in interoperability issues or unnecessary complexity. These costs come without the benefit of effective filtering since many application protocols began to use HTTP as a transport protocol after application developers observed that firewalls allow HTTP traffic while dropping packets for unknown protocols.
実際には、アプリケーションの使用をブロックまたは制限することを目的としたフィルタリングは、顧客の同意なしに正常に実装することは困難です。これは、開発者がフィルターを回避するために、フィルタリングされたプロトコルを再設計する傾向があるためです。したがって、時間の経過とともに、フィルタリングは相互運用性の問題または不要な複雑さをもたらす可能性があります。ファイアウォールが未知のプロトコルのパケットをドロップする一方でHTTPトラフィックを許可することをアプリケーション開発者が確認した後、多くのアプリケーションプロトコルがトランスポートプロトコルとしてHTTPを使用し始めたため、これらのコストには効果的なフィルタリングの利点がありません。
Such arms races stem from inherent tussles between the desires of different entities. For example, the tussle between end-user desires and administrator desires leads to an arms race between firewalls and deep packet inspection on the one hand, vs. the use of obfuscation or tunnels on the other.
そのような軍拡競争は、異なる実体の欲望間の固有の闘争から生じます。たとえば、エンドユーザーの欲望と管理者の欲求の間の闘争は、一方ではファイアウォールとディープパケットインスペクションとの間の競争、他方では難読化またはトンネルの使用につながります。
Although such arms races are often thought of in the context of network firewalls, they also occur with host firewalls. It is, however, generally easier for a host firewall to overcome, since it may be more practical for a host firewall to establish some form of trust between the policy-desiring entities, and have a trusted arbiter.
このような競争は、ネットワークファイアウォールのコンテキストでよく考えられますが、ホストファイアウォールでも発生します。ただし、ホストファイアウォールがポリシーを要求するエンティティ間で何らかの形の信頼を確立し、信頼されたアービターを持つことがより現実的である場合があるため、ホストファイアウォールの方が一般的に簡単です。
In this approach, applications use a library or other external service whereby the applications have explicit knowledge of the impact of the security policies in order to avoid the problems in Section 3.1.3, and in a sandboxed environment, this might be the application's only way to interact with the network.
このアプローチでは、アプリケーションはライブラリまたはその他の外部サービスを使用します。これにより、アプリケーションは、セクション3.1.3の問題を回避するためにセキュリティポリシーの影響を明確に認識し、サンドボックス環境では、これがアプリケーションの唯一の方法である可能性があります。ネットワークと対話する。
Thus, in this opt-in approach, applications provide a description of the network access requested, and the library/service can ensure that applications and/or users are informed in a way they can understand and that administrators can craft policy that affects the applications.
したがって、このオプトインアプローチでは、アプリケーションは要求されたネットワークアクセスの説明を提供し、ライブラリ/サービスは、アプリケーションまたはユーザー、あるいはその両方が理解できる方法で通知され、管理者がアプリケーションに影響を与えるポリシーを作成できることを保証できます。
This approach is very difficult to do in a firewall-vendor-specific library/service when there can be multiple firewall implementations (including ones in the middle of the network), since it is usually impractical for an application developer to know about and develop for many different firewall APIs. It is, however, possible to employ this approach with a firewall-vendor-agnostic library/service that can communicate with both applications and firewalls. Thus, application developers and firewall developers can use a common platform.
このアプローチは、ファイアウォールのベンダー固有のライブラリ/サービスで実行することが非常に困難です。これは、複数のファイアウォール実装（ネットワークの中央にあるものを含む）が存在する可能性がある場合、通常、アプリケーション開発者が知って開発することは実際的ではないためです。多くの異なるファイアウォールAPI。ただし、アプリケーションとファイアウォールの両方と通信できるファイアウォールベンダーに依存しないライブラリ/サービスでこのアプローチを採用することは可能です。したがって、アプリケーション開発者とファイアウォール開発者は共通のプラットフォームを使用できます。
We observe that this approach is very different from the classic firewall approach. It is, however the approach used by some host operating system firewalls, and it is also the approach used by PCP in the IETF. As such, we encourage the deployment and use of this model.
このアプローチは、従来のファイアウォールアプローチとは大きく異なります。ただし、これは一部のホストオペレーティングシステムのファイアウォールで使用されているアプローチであり、IETFでPCPが使用しているアプローチでもあります。そのため、このモデルの導入と使用を推奨しています。
Furthermore, while this approach lessens the incentive for arms races as discussed above, one important issue still remains. Namely, there is no standard mechanism today for a library/service to learn complex policies from the network. Further work in this area is needed.
さらに、このアプローチは上記のように軍拡競争に対するインセンティブを減少させますが、1つの重要な問題がまだ残っています。つまり、ライブラリ/サービスがネットワークから複雑なポリシーを学習するための標準的なメカニズムは現在ありません。この領域でのさらなる作業が必要です。
There is often a desire to hide from address and port scans on a public network. However, compliance to many RFCs requires responding to various messages. For example, TCP [RFC0793] compliance requires sending a RST in response to a SYN when there is no listener, and ICMPv6 [RFC4443] compliance requires sending an Echo Reply in response to an Echo Request.
パブリックネットワーク上のアドレスおよびポートスキャンから隠したいという要望がよくあります。ただし、多くのRFCに準拠するには、さまざまなメッセージに応答する必要があります。たとえば、リスナーが存在しない場合、TCP [RFC0793]コンプライアンスではSYNに応答してRSTを送信する必要があり、ICMPv6 [RFC4443]コンプライアンスでは、エコー要求に応答してエコー応答を送信する必要があります。
Firewall rules can allow such stealth without changing the statement of compliance of the basic protocols. However, stealth mode could instead be implemented as a configurable option used by the applications themselves. For example, rather than a firewall rule to drop a certain outbound message after an application generates it, fewer resources would be consumed if the application knew not to generate it in the first place.
ファイアウォールルールは、基本的なプロトコルのコンプライアンスのステートメントを変更することなく、そのようなステルスを許可できます。ただし、ステルスモードは、アプリケーション自体が使用する構成可能なオプションとして実装することもできます。たとえば、アプリケーションがメッセージを生成した後に特定の送信メッセージをドロップするファイアウォールルールではなく、アプリケーションがそもそもメッセージを生成しないことを知っていれば、消費されるリソースは少なくなります。
There is a common misconception that firewalls protect users from malware on their computer, when in fact firewalls protect users from buggy software. There is some concern that firewalls give users a false sense of security; firewalls are not invulnerable and will not prevent malware from running if the user allows it.
ファイアウォールはバグのあるソフトウェアからユーザーを保護しているのに、ファイアウォールはコンピューター上のマルウェアからユーザーを保護しているという一般的な誤解があります。ファイアウォールがユーザーに誤った安心感を与えるという懸念があります。ファイアウォールは無傷ではなく、ユーザーが許可した場合でもマルウェアの実行を妨げることはありません。
This document has focused primarily on host firewalls. For additional discussion (focused more on network firewalls) see [RFC2979] and [BLOCK-FILTER].
このドキュメントは、主にホストファイアウォールに焦点を当てています。 （ネットワークファイアウォールに重点を置いた）追加の説明については、[RFC2979]および[BLOCK-FILTER]を参照してください。
Stuart Cheshire provided the motivation for this document by asking the thought-provoking question of why one would want to firewall an application rather than simply stop running it. The ensuing discussion, and subsequent IAB tech chat in November 2011, led to this document. Dan Simon, Stephen Bensley, Gerardo Diaz Cuellar, Brian Carpenter, and Paul Hoffman also provided helpful suggestions.
スチュアートチェシャーは、アプリケーションの実行を単に停止するのではなく、なぜアプリケーションをファイアーウォール化したいのかという考えさせられる質問をすることで、このドキュメントの動機を提供しました。その後の議論、および2011年11月のその後のIABテクニカルチャットが、このドキュメントにつながっています。 Dan Simon、Stephen Bensley、Gerardo Diaz Cuellar、Brian Carpenter、Paul Hoffmanも参考になった。
Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Joel Halpern Russ Housley Eliot Lear Xing Li Erik Nordmark Andrew Sullivan Dave Thaler Hannes Tschofenig
バーナードアボバジャリアルコマルクブランシェロスカロンアリッサクーパージョエルハルパーンラスハウズリーエリオットリアシンリーエリックノードマークアンドリューサリバンデイブターラーハネスチョーフェニグ
[BLOCK-FILTER] Barnes, R., Cooper, A., and O. Kolkman, "Technical Considerations for Internet Service Blocking and Filtering", Work in Progress, January 2014.
[BLOCK-FILTER] Barnes、R.、Cooper、A。、およびO. Kolkman、「インターネットサービスのブロックとフィルタリングに関する技術的な考慮事項」、進行中の作業、2014年1月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC2979] Freed、N。、「インターネットファイアウォールの動作と要件」、RFC 2979、2000年10月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、「インターネット制御メッセージプロトコル（ICMPv6）、インターネットプロトコルバージョン6（IPv6）仕様」、RFC 4443、2006年3月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864] Van de Velde、G.、Hain、T.、Droms、R.、Carpenter、B。、およびE. Klein、「IPv6のローカルネットワーク保護」、RFC 4864、2007年5月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890] Davies、E。およびJ. Mohacsi、「ファイアウォールでのICMPv6メッセージのフィルタリングに関する推奨事項」、RFC 4890、2007年5月。
[RFC4924] Aboba, B. and E. Davies, "Reflections on Internet Transparency", RFC 4924, July 2007.
[RFC4924] Aboba、B。およびE. Davies、「Reflections on Internet Transparency」、RFC 4924、2007年7月。
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, August 2007.
[RFC4948] Andersson、L.、Davies、E。、およびL. Zhang、「2006年3月9〜10日のIABワークショップからの不要なトラフィックに関するレポート」、RFC 4948、2007年8月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、RFC 4949、2007年8月。
[RFC5505] Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, "Principles of Internet Host Configuration", RFC 5505, May 2009.
[RFC5505] Aboba、B.、Thaler、D.、Andersson、L。、およびS. Cheshire、「Principles of Internet Host Configuration」、RFC 5505、2009年5月。
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[RFC6887] Wing、D.、Cheshire、S.、Boucadair、M.、Penno、R。、およびP. Selkirk、「Port Control Protocol（PCP）」、RFC 6887、2013年4月。
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, December 2013.
[RFC7045] Carpenter、B。およびS. Jiang、「IPv6拡張ヘッダーの送信と処理」、RFC 7045、2013年12月。
[UPNPWANIP] UPnP Forum, "WANIPConnection:2 Service", September 2010, <http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v2-Service.pdf>.
[UPNPWANIP] UPnPフォーラム、「WANIPConnection：2 Service」、2010年9月、<http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v2-Service.pdf>。
Author's Address
著者のアドレス
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
だゔぇ てゃぇｒ みｃろそｆｔ こｒぽらちおん おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ うさ
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com