RFC2267 日本語訳
2267 Network Ingress Filtering: Defeating Denial of Service Attackswhich employ IP Source Address Spoofing. P. Ferguson, D. Senie. January 1998. (Format: TXT=21032 bytes) (Obsoleted by RFC2827) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Ferguson
Request for Comments: 2267 Cisco Systems, Inc.
Category: Informational D. Senie
BlazeNet, Inc.
January 1998
コメントを求めるワーキンググループP.ファーガソン要求をネットワークでつないでください: 2267年のシスコシステムズInc.カテゴリ: 情報のD.Senie BlazeNet Inc.1998年1月
Network Ingress Filtering:
Defeating Denial of Service Attacks which employ
IP Source Address Spoofing
以下をフィルターにかけるイングレスをネットワークでつないでください。 IP Source Address Spoofingを使うサービス妨害Attacksを破ります。
Status of this Memo
この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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
Recent occurrences of various Denial of Service (DoS) attacks which have employed forged source addresses have proven to be a troublesome issue for Internet Service Providers and the Internet community overall. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point.
偽造ソースアドレスを使った様々なサービス妨害(DoS)攻撃の最近の発生はインターネットサービスプロバイダのための厄介な問題と全体的に見てインターネットコミュニティであると判明しました。 この論文は'behind'からインターネットサービスプロバイダ(ISP)ポイントの集合もので伝播されるのに偽造IPアドレスを使用するDoS攻撃を禁止するのにイングレストラフィックフィルタリングを使用するための簡単で、有効で、簡単なメソッドについて議論します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Restricting forged traffic . . . . . . . . . . . . . . . . 5
4. Further capabilities for networking equipment. . . . . . . 6
5. Liabilities. . . . . . . . . . . . . . . . . . . . . . . . 6
6. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations. . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 9
11. Full Copyright Statement . . . . . . . . . . . . . . . . . 10
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 2 2。 バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . . 2 3。 制限はトラフィック. . . . . . . . . . . . . . . . 5 4を鍛造しました。 ネットワーク設備のためのさらなる能力。 . . . . . . 6 5. 負債。 . . . . . . . . . . . . . . . . . . . . . . . 6 6. 概要。 . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. セキュリティ問題。 . . . . . . . . . . . . . . . . . 7 8. 承認. . . . . . . . . . . . . . . . . . . . . 8 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . 8 10。 作者のアドレス. . . . . . . . . . . . . . . . . . . . 9 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . 10
Ferguson & Senie Informational [Page 1] RFC 2267 Network Ingress Filtering January 1998
1998年1月をフィルターにかけるファーガソンとSenieの情報[1ページ]のRFC2267ネットワークイングレス
1. Introduction
1. 序論
A resurgence of Denial of Service Attacks [1] aimed at various targets in the Internet have produced new challenges within the Internet Service Provider (ISP) and network security communities to find new and innovative methods to mitigate these types of attacks. The difficulties in reaching this goal are numerous; some simple tools already exist to limit the effectiveness and scope of these attacks, but they have not been widely implemented.
インターネットの様々な目標が目的とされたサービス妨害Attacks[1]の再起はこれらのタイプの攻撃を緩和する新しくて革新的なメソッドを見つけるインターネットサービスプロバイダ(ISP)とネットワーク安全保障共同体の中の新しい挑戦を起こしました。 この目標に達することにおける苦労は非常に多いです。 いくつかの簡単なツールがこれらの攻撃の有効性と範囲を制限するために既に存在していますが、それらは広く実装されていません。
This method of attack has been known for some time. Defending against it, however, has been an ongoing concern. Bill Cheswick is quoted in [2] as saying that he pulled a chapter from his book, "Firewalls and Internet Security" [3], at the last minute because there was no way for an administrator of the system under attack to effectively defend the system. By mentioning the method, he was concerned about encouraging it's use.
この攻撃方法はしばらく知られています。 しかしながら、それに対して防御するのは、進行中の関心です。 [2]では、ビルチェスウィックが、事実上、攻撃しているシステムの管理者がシステムを防御する方法が全くなかったので彼が土壇場で彼の本、「ファイアウォールとインターネットセキュリティ」[3]から章を引いたと言ったと伝えられます。 メソッドに言及することによって、彼は奨励に関してそれが使用であることを心配していました。
While the filtering method discussed in this document does absolutely nothing to protect against flooding attacks which originate from valid prefixes (IP addresses), it will prohibit an attacker within the originating network from launching an attack of this nature using forged source addresses that do not conform to ingress filtering rules. All providers of Internet connectivity are urged to implement filtering described in this document to prohibit attackers from using forged source addresses which do not reside within a range of legitimately advertised prefixes. In other words, if an ISP is aggregating routing announcements for multiple downstream networks, strict traffic filtering should be used to prohibit traffic which claims to have originated from outside of these aggregated announcements.
本書では議論したフィルタリングメソッドが絶対に有効な接頭語(IPアドレス)から発するフラッディング攻撃から守るようなことを何もしていない間、それは、この種で攻撃を開始するのから規則をフィルターにかけるイングレスに従わない偽造ソースアドレスを使用することで起因するネットワークの中の攻撃者を禁じるでしょう。 インターネットの接続性のすべてのプロバイダーがさまざまな合法的に広告を出した接頭語の中にない偽造ソースアドレスを使用するのから攻撃者を禁じるためにこのドキュメントで説明されたフィルタリングを実装するよう促されます。 言い換えれば、ISPが複数の川下のネットワークのためにルーティング発表に集められているなら、厳しいトラフィックフィルタリングは、これらの外に集められた発表から発したと主張するトラフィックを禁止するのに使用されるべきです。
An additional benefit of implementing this type of filtering is that it enables the originator to be easily traced to it's true source, since the attacker would have to use a valid, and legitimately reachable, source address.
このタイプのフィルタリングを実装する追加利益は創始者が容易にそれの正しいソースにつけられるのを可能にするということです、攻撃者が有効で、合法的に届いているソースアドレスを使用しなければならないでしょう、したがって。
2. Background
2. バックグラウンド
A simplified diagram of the TCP SYN flooding problem is depicted below:
TCP SYN氾濫問題の略図は以下に表現されます:
9.0.0.0/8
host <----- router <--- Internet <----- router <-- attacker
9.0.0.0/8ホスト<。----- ルータ<。--- インターネット<。----- ルータ<--攻撃者
TCP/SYN
<---------------------------------------------
Source: 192.168.0.4/32
TCP/SYN<。--------------------------------------------- ソース: 192.168.0.4/32
Ferguson & Senie Informational [Page 2] RFC 2267 Network Ingress Filtering January 1998
1998年1月をフィルターにかけるファーガソンとSenieの情報[2ページ]のRFC2267ネットワークイングレス
SYN/ACK
no route
TCP/SYN
<---------------------------------------------
Source: 10.0.0.13/32
SYN/ACK
no route
TCP/SYN
<---------------------------------------------
Source: 172.16.0.2/32
SYN/ACK
no route
ルートのTCP/SYNのSYN/ACKノー<。--------------------------------------------- ソース: ルートのTCP/SYNの10.0.0.13/32SYN/ACKノー<。--------------------------------------------- ソース: SYN/ACKノー、が発送する172.16.0.2/32
[etc.]
[など]
Assume:
仮定します:
o The "host" is the targeted machine.
o 「ホスト」は狙っているマシンです。
o The attacker resides within the "valid" prefix, 9.0.0.0/8.
o 攻撃者は「有効」接頭語、9.0の中に住んでいます。.0 .0/8。
o The attacker launches the attack using randomly changing source
addresses; in this example, the source addresses are depicted as
from within [4], which are not generally present in the global
Internet routing tables, and therefore, unreachable. However, any
unreachable prefix could be used to perpetrate this attack
method.
o 手当たりしだいに変化しているソースアドレスを使用することで攻撃者は攻撃に着手します。 したがって、そして、一般に世界的なインターネット経路指定テーブルでのどんなプレゼントもこの例、アドレスが[4]の中に表現されるソースでは、どのでないか手が届きません。 しかしながら、この攻撃メソッドを犯すのにどんな手の届かない接頭語も使用できました。
Also worthy of mention is a case wherein the source address is forged to appear to have originated from within another legitimate network which appears in the global routing table(s). For example, an attacker using a valid network address could wreak havoc by making the attack appear to come from an organization which did not, in fact, originate the attack and was completely innocent. In such cases, the administrator of a system under attack may be inclined to filter all traffic coming from the apparent attack source. Adding such a filter would then result in a denial of service to legitimate, non-hostile end-systems. In this case, the administrator of the system under attack unwittingly becomes an accomplice of the attacker.
また、言及にふさわしいのは、ソースアドレスが中からグローバルな経路指定テーブルに現れる別の正統のネットワークを溯源したように見えるために偽造されるケースです。 例えば、攻撃を事実上、攻撃を溯源していない、完全に潔白であった組織から来るように見えさせることによって、有効なネットワーク・アドレスを使用している攻撃者は大破壊を加えることができるでしょう。 そのような場合、攻撃しているシステムの管理者は見かけの攻撃ソースから来るすべてのトラフィックをフィルターにかける傾向があるかもしれません。 次に、そのようなフィルタを加えると、正統の、そして、非敵軍のエンドシステムに対するサービスの否定はもたらされるでしょう。この場合、攻撃しているシステムの管理者は攻撃者の共犯に知らず知らずなります。
Further complicating matters, TCP SYN flood attacks will result in SYN-ACK packets being sent to one or many hosts which have no involvement in the attack, but which become secondary victims. This allows the attacker to abuse two or more systems at once.
TCP SYNフラッド攻撃は1つに送られるSYN-ACKパケットか多くのホストをもたらしてさらに件を複雑にする(攻撃におけるかかわり合いを全く持っていませんが、セカンダリ犠牲者になります)。これは、攻撃者がすぐに2台以上のシステムを誤用するのを許容します。
Ferguson & Senie Informational [Page 3] RFC 2267 Network Ingress Filtering January 1998
1998年1月をフィルターにかけるファーガソンとSenieの情報[3ページ]のRFC2267ネットワークイングレス
Similar attacks have been attempted using UDP and ICMP flooding. The former attack (UDP flooding) uses forged packets to try and connect the chargen UDP service to the echo UDP service at another site. Systems administrators should NEVER allow UDP packets destined for system diagnostic ports from outside of their administrative domain to reach their systems. The latter attack (ICMP flooding), uses an insidious feature in IP subnet broadcast replication mechanics. This attack relies on a router serving a large multi- access broadcast network to frame an IP broadcast address (such as one destined for 10.255.255.255) into a Layer 2 broadcast frame (for ethernet, FF:FF:FF:FF:FF:FF). Ethernet NIC hardware (MAC-layer hardware, specifically) will only listen to a select number of addresses in normal operation. The one MAC address that all devices share in common in normal operation is the media broadcast, or FF:FF:FF:FF:FF:FF. In this case, a device will take the packet and send an interrupt for processing. Thus, a flood of these broadcast frames will consume all available resources on an end-system [9]. It is perhaps prudent that system administrators should consider ensuring that their border routers do not allow directed broadcast packets to be forwarded through their routers as a default.
UDPとICMP氾濫を使用することで同様の攻撃を試みてあります。 (UDP氾濫)が使用する前の攻撃は、別のサイトでのエコーUDPサービスに対するchargen UDPサービスを接続してみるためにパケットを鍛造しました。 上級システムアドミニストレータはそれらの管理ドメインの外部からシステムの診断ポートに運命づけられたUDPパケットをそれらのシステムに決して達させるはずがありません。後者は(ICMP氾濫)を攻撃して、用途はIPサブネット放送模写整備士の油断のならない特徴です。 この攻撃は、IP放送演説を縁どるために大きいマルチアクセス放送網に役立ちながら、ルータを当てにします。(1としてのそのようなものは10.255のために、Layer2放送への.255が)縁どる.255(FF:FF:FF:FF:FF: イーサネットのためのFF)を運命づけました。 イーサネットNICハードウェア(明確にMAC-層のハードウェア)は通常の操作における選んだ数のアドレスを聞くだけでしょう。 すべてのデバイスが通常の操作で一般的で共有する1つのMACアドレスが、メディア放送、またはFF:FF:FFです: FF:FF:FF。 この場合、デバイスは、パケットを取って、処理のための中断を送るでしょう。 したがって、これらの放送フレームの洪水はエンドシステム[9]に関するすべての利用可能資源を消費するでしょう。 システム管理者が、彼らの境界ルータが、指示された放送パケットがデフォルトとしてそれらのルータを通して進められるのを許容しないのを確実にすると考えるのは、恐らく慎重です。
When an TCP SYN attack is launched using unreachable source address, the target host attempts to reserve resources waiting for a response. The attacker repeatedly changes the bogus source address on each new packet sent, thus exhausting additional host resources.
TCP SYN攻撃が手の届かないソースアドレスを使用することで進水するとき、目標ホストは、応答を待つリソースを予約するのを試みます。 攻撃者は繰り返して送られた、その結果、追加ホストリソースを枯渇させたそれぞれの新しいパケットに関するにせのソースアドレスを変えます。
Alternatively, if the attacker uses someone else's valid host address as the source address, the system under attack will send a large number of SYN/ACK packets to what it believes is the originator of the connection establishment sequence. In this fashion, the attacker does damage to two systems: the destination target system, as well as the system which is actually using the spoofed address in the global routing system.
あるいはまた、攻撃者がソースアドレスとして他の誰かの有効なホスト・アドレスを使用すると、攻撃しているシステムはそれがコネクション確立系列の創始者であると信じていることに多くのSYN/ACKパケットを送るでしょう。 こんなやり方で、攻撃者はシステムを2まで破損します: 目的地目標システム、および実際にグローバルなルーティングシステムで偽造しているアドレスを使用しているシステム。
The result of both attack methods is extremely degraded performance, or worse, a system crash.
両方の攻撃メソッドの結果は、非常に降格している性能、または、より悪、システムクラッシュです。
In response to this threat, most operating system vendors have modified their software to allow the targeted servers to sustain attacks with very high connection attempt rates. This is a welcome and necessary part of the solution to the problem. Ingress filtering will take time to be implemented pervasively and be fully effective, but the extensions to the operating systems can be implemented quickly. This combination should prove effective against source address spoofing. See [1] for vendor and platform software upgrade information.
この脅威に対応して、ほとんどのオペレーティングシステムベンダーが、狙っているサーバが非常に高い接続試み率で攻撃を支えるのを許容するようにそれらのソフトウェアを変更しました。 これは問題への解決の歓迎されて必要な部分です。 イングレスフィルタリングは普及して実装されて、完全に効果的になるには時間がかかるでしょうが、すぐにオペレーティングシステムへの拡大を実装することができます。 この組み合わせはソースアドレススプーフィングに対して実効を現すべきです。 ベンダーとプラットホームソフトウェアの更新情報のための[1]を見てください。
Ferguson & Senie Informational [Page 4] RFC 2267 Network Ingress Filtering January 1998
1998年1月をフィルターにかけるファーガソンとSenieの情報[4ページ]のRFC2267ネットワークイングレス
3. Restricting forged traffic
3. 偽造トラフィックを制限します。
The problems encountered with this type of attack are numerous, and involve shortcomings in host software implementations, routing methodologies, and the TCP/IP protocols themselves. However, by restricting transit traffic which originates from a downstream network to known, and intentionally advertised, prefix(es), the problem of source address spoofing can be virtually eliminated in this attack scenario.
このタイプの攻撃で行きあたられる問題は、多数であり、ホストソフトウェア実行、ルーティング方法論、およびTCP/IPプロトコル自体に短所にかかわります。 しかしながら、川下のネットワークから知られていて、故意に広告を出した接頭語(es)まで起因するトランジットトラフィックを制限することによって、実際にはこの攻撃シナリオでソースアドレススプーフィングの問題を解決できます。
11.0.0.0/8
/
router 1
/
/
/ 9.0.0.0/8
ISP <----- ISP <---- ISP <--- ISP <-- router <-- attacker
A B C D 2
/
/
/
router 3
/
12.0.0.0/8
11.0.0.0/8 /ルータ1 / / / 9.0.0.0/8ISP<。----- ISP<。---- ISP<。--- ISP<--ルータ<--攻撃者A B C D2///ルータ3 / 12.0.0.0/8
In the example above, the attacker resides within 9.0.0.0/8, which is provided Internet connectivity by ISP D. An input traffic filter on the ingress (input) link of "router 2", which provides connectivity to the attacker's network, restricts traffic to allow only traffic originating from source addresses within the 9.0.0.0/8 prefix, and prohibits an attacker from using "invalid" source addresses which reside outside of this prefix range.
例では、攻撃者は9.0の中に上では、住んでいます。.0 .0/8。(インターネットの接続性はAn入力トラフィックが「攻撃者のネットワークに接続性を提供して、9.0.0.0/8接頭語の中にソースアドレスから発するトラフィックだけを許容するためにトラフィックを制限して、この接頭語範囲の外である「無効」のソースアドレスを使用するのから攻撃者を禁じるルータ2インチ」のイングレス(入力)リンクの上にフィルターにかけるISP D.によってその8に提供されます)。
In other words, the ingress filter on "router 2" above would check:
言い換えれば、「上のルータ2インチは以下をチェックするだろうところ」のイングレスフィルタ
IF packet's source address from within 9.0.0.0/8
THEN forward as appropriate
パケットのソースであるなら、9.0から、.0.0/8THENを前方に適宜扱ってください。
IF packet's source address is anything else
THEN deny packet
パケットのソースアドレスがTHENがパケットを否定する他の何かであるなら
Network administrators should log information on packets which are dropped. This then provides a basis for monitoring any suspicious activity.
ネットワーク管理者は下げられるパケットの情報を登録するべきです。 そして、これはどんな不審な行動もモニターする基礎を提供します。
Ferguson & Senie Informational [Page 5] RFC 2267 Network Ingress Filtering January 1998
1998年1月をフィルターにかけるファーガソンとSenieの情報[5ページ]のRFC2267ネットワークイングレス
4. Further possible capabilities for networking equipment
4. ネットワーク設備のためのさらなる可能な能力
Additional functions should be considered for future platform implementations. The following one is worth noting:
追加機能は将来のプラットホーム実装のために考えられるべきです。 以下の1つは注意する価値があります:
o Implementation of automatic filtering on remote access servers.
In most cases, a user dialing into an access server is an
individual user on a single PC. The ONLY valid source IP address
for packets originating from that PC is the one assigned by the
ISP (whether statically or dynamically assigned). The remote
access server could check every packet on ingress to ensure the
user is not spoofing the source address on the packets which he
is originating. Obviously, provisions also need to be made for
cases where the customer legitimately is attaching a net or
subnet via a remote router, but this could certainly be
implemented as an optional parameter. We have received reports
that some vendors and some ISPs are already starting to
implement this capability.
o リモートアクセス・サーバーに関する自動フィルタリングの実装。 多くの場合、アクセス・サーバーにダイヤルするユーザは単一のPCの上の個々のユーザです。 そのPCから発するパケットのための唯一の有効なソースIPアドレスがISPによって割り当てられたもの(静的かダイナミックに割り当てられるか否かに関係なく)です。 リモートアクセス・サーバーは、ユーザが彼が溯源しているパケットに関するソースアドレスを偽造していないのを保証するためにイングレスのあらゆるパケットをチェックするかもしれません。 また、明らかに、条項は、顧客がリモートルータで合法的にネットかサブネットを付けているケースのために作られている必要がありますが、確かに、任意のパラメタとしてこれを実装することができました。 私たちはいくつかのベンダーといくつかのISPが既にこの能力を実装し始めているというレポートを受け取りました。
We considered suggesting routers also validate the source IP address of the sender as suggested in [8], but that methodology will not operate well in the real networks out there today. The method suggested is to look up source addresses to see that the return path to that address would flow out the same interface as the packet arrived upon. With the number of asymmetric routes in the Internet, this would clearly be problematic.
私たちは、[8]に示されるようにまた、ルータがソースIP送信者のアドレスを有効にするのを示すと考えましたが、その方法論は今日、むこうで本当のネットワークではよく作動しないでしょう。 示されたメソッドはそのアドレスへのリターンパスが到着したパケットと同じインタフェースを浪費することを確認するためにソースアドレスを調べることです。 非対称のルートの数がインターネットにある状態で、これは明確に問題が多いでしょう。
5. Liabilities
5. 責任
Filtering of this nature has the potential to break some types of "special" services. It is in the best interest of the ISP offering these types of special services, however, to consider alternate methods of implementing these services to avoid being affected by ingress traffic filtering.
この種のフィルタリングには、何人かのタイプの「特別な」サービスを壊す可能性があります。 しかしながら、ISPがイングレストラフィックで影響を受けるのを避けるこれらのサービスを実装する代替方法がフィルターにかけていると考えるためにこれらのタイプの特殊業務を提供する最も良い利益のためにはそれがあります。
Mobile IP, as defined in [6], is specifically affected by ingress traffic filtering. As specified, traffic to the mobile node is tunneled, but traffic from the mobile node is not tunneled. This results in packets from the mobile node(s) which have source addresses that do not match with the network where the station is attached. The Mobile IP Working Group is addressing this problem by specifying "reverse tunnels" in [7]. This work in progress provides a method for the data transmitted from the mobile node to be tunneled to the home agent before transmission to the Internet. There are additional benefits to the reverse tunneling scheme, including better handling of multicast traffic. Those implementing mobile IP systems are encouraged to implement this method of reverse tunneling.
[6]で定義されるモバイルIPはイングレストラフィックフィルタリングで明確に影響を受けます。 指定されるように、モバイルノードへのトラフィックはトンネルを堀られますが、モバイルノードからのトラフィックはトンネルを堀られません。 これはステーションが付属しているネットワークに合わせないソースアドレスを持っているモバイルノードからのパケットをもたらします。 モバイルIP作業部会は、[7]で「逆のトンネル」を指定することによって、このその問題を訴えています。 この処理中の作業はインターネットへのトランスミッションの前にホームのエージェントにトンネルを堀られるためにモバイルノードから送られたデータにメソッドを提供します。 マルチキャストトラフィックの、より良い取り扱いを含んでいて、逆のトンネリング体系への付加的な利益があります。 モバイルIPがシステムであると実装するものが逆のトンネリングのこのメソッドを実装するよう奨励されます。
Ferguson & Senie Informational [Page 6] RFC 2267 Network Ingress Filtering January 1998
1998年1月をフィルターにかけるファーガソンとSenieの情報[6ページ]のRFC2267ネットワークイングレス
As mentioned previously, while ingress traffic filtering drastically reduces the success of source address spoofing, it does not preclude an attacker using a forged source address of another host within the permitted prefix filter range. It does, however, ensure that when an attack of this nature does indeed occur, a network administrator can be sure that the attack is actually originating from within the known prefixes that are being advertised. This simplifies tracking down the culprit, and at worst, the administrator can block a range of source addresses until the problem is resolved.
既述のとおり、イングレストラフィックフィルタリングがソースアドレススプーフィングの成功を抜本的に減少させている間、それは、受入れられた接頭語フィルタ範囲の中で別のホストの偽造ソースアドレスを使用することで攻撃者を排除しません。 しかしながら、それは、この種の攻撃が本当に起こるとき、ネットワーク管理者が攻撃が実際に中から広告に掲載されている知られている接頭語を溯源しているのを確信している場合があるのを確実にします。 これは罪人の下側への追跡を簡素化します、そして、最悪の場合は、問題が解決されるまで、管理者はさまざまなソースアドレスを妨げることができます。
If ingress filtering is used in an environment where DHCP or BOOTP is used, the network administrator would be well advised to ensure that packets with a source address of 0.0.0.0 and a destination of 255.255.255.255 are allowed to reach the relay agent in routers when appropriate. The scope of directed broadcast replication should be controlled, however, and not arbitrarily forwarded.
適切であるときに、イングレスフィルタリングがDHCPかBOOTPが使用されている、ネットワーク管理者が0.0のソースアドレスがあるそのパケットに.0を確実にするようにアドバイスされた井戸が255.255の.0と目的地であるならそうする環境で使用されるなら、.255が許容されている.255はルータで中継エージェントに届きます。 指示された放送模写の範囲をしかしながら、制御して、任意に進めるべきではありません。
6. Summary
6. 概要
Ingress traffic filtering at the periphery of Internet connected networks will reduce the effectiveness of source address spoofing denial of service attacks. Network service providers and administrators have already begun implementing this type of filtering on periphery routers, and it is recommended that all service providers do so as soon as possible. In addition to aiding the Internet community as a whole to defeat this attack method, it can also assist service providers in locating the source of the attack if service providers can categorically demonstrate that their network already has ingress filtering in place on customer links.
インターネット接続されたネットワークの周辺のイングレストラフィックフィルタリングはソースアドレススプーフィングサービス不能攻撃の有効性を減少させるでしょう。 ネットワークサービスプロバイダーと管理者は周辺ルータで既にこのタイプのフィルタリングを実装し始めました、そして、すべてのサービスプロバイダーがそれほどできるだけ早くするのは、お勧めです。 また、全体でインターネットコミュニティがこの攻撃メソッドを破るのを支援することに加えて、それはサービスプロバイダーが、それらのネットワークが顧客リンクの上に適所に既にイングレスフィルタリングを持つのを断定的に示すことができるなら攻撃の源の場所を見つけるのにサービスプロバイダーを助けることができます。
Corporate network administrators should implement filtering to ensure their corporate networks are not the source of such problems. Indeed, filtering could be used within an organization to ensure users do not cause problems by improperly attaching systems to the wrong networks. The filtering could also, in practice, block a disgruntled employee from anonymous attacks.
企業ネットワークの管理者は、彼らの企業ネットワークがそのような問題の源でないことを保証するためにフィルタリングを実装するべきです。本当に、ユーザが不適切に間違ったネットワークにシステムを取り付けることによって問題を起こさないのを保証するのに組織の中でフィルタリングは使用できました。 また、フィルタリングは実際には匿名の攻撃から不満を抱いた従業員を妨げるかもしれません。
It is the responsibility of all network administrators to ensure they do not become the unwitting source of an attack of this nature.
彼らがこの種の攻撃の知らず知らずの源にならないのを保証するのは、すべてのネットワーク管理者の責任です。
7. Security Considerations
7. セキュリティ問題
The primary intent of this document is to inherently increase security practices and awareness for the Internet community as a whole; as more Internet Providers and corporate network administrators implement ingress filtering, the opportunity for an attacker to use forged source addresses as an attack methodology will significantly lessen. Tracking the source of an attack is simplified
このドキュメントのプライマリ意図は本来全体でインターネットコミュニティのためにセキュリティ実践と認識を増強することです。 より多くのプロバイダと企業ネットワークの管理者が、イングレスがフィルタリングであると実装するので、攻撃方法論がかなり下がるのに従って、使用する攻撃者の機会はソースアドレスを偽造しました。 攻撃の源を追跡するのは簡易型です。
Ferguson & Senie Informational [Page 7] RFC 2267 Network Ingress Filtering January 1998
1998年1月をフィルターにかけるファーガソンとSenieの情報[7ページ]のRFC2267ネットワークイングレス
when the source is more likely to be "valid." By reducing the number and frequency of attacks in the Internet as a whole, there will be more resources for tracking the attacks which ultimately do occur.
ソースが「有効である」より傾向があるときに。 全体でインターネットの攻撃の数を減らして、頻度に従って、結局起こる攻撃を追跡するための、より多くのリソースがあるでしょう。
8. Acknowledgments
8. 承認
The North American Network Operators Group (NANOG) [5] group as a whole deserves special credit for openly discussing these issues and actively seeking possible solutions. Also, thanks to Justin Newton [Priori Networks] and Steve Bielagus [OpenROUTE Networks, Inc.] for their comments and contributions.
北米のNetwork Operators Group(NANOG)[5]グループ全体はオープンにこれらの問題について議論して、活発に可能なソリューションを求めるための特別なクレジットに値します。 また、彼らのコメントと貢献のためにジャスティン・ニュートン[Priori Networks]とスティーブBielagus[OpenROUTE Networks Inc.]をありがとうございます。
9. References
9. 参照
[1] CERT Advisory CA-96.21; TCP SYN Flooding and IP Spoofing
Attacks; September 24, 1996.
[1] CERT勧告カリフォルニア-96.21。 TCP SYN氾濫とIPスプーフィング攻撃。 1996年9月24日。
[2] B. Ziegler, "Hacker Tangles Panix Web Site", Wall Street
Journal, 12 September 1996.
[2] B.ジーグラー、「ハッカーはPanixウェブサイトをもつれる」ウォール・ストリート・ジャーナル、1996年9月12日。
[3] "Firewalls and Internet Security: Repelling the Wily Hacker";
William R. Cheswick and Steven M. Bellovin, Addison-Wesley
Publishing Company, 1994; ISBN 0-201-63357-4.
[3]、「ファイアウォールとインターネットセキュリティ:」 「陰険なハッカーを退けます」。 ウィリアムR.チェスウィックとスティーブンM.Bellovin、会社、1994を発行するアディソン-ウエスリー。 ISBN0-201-63357-4。
[4] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and
E. Lear, "Address Allocation for Private Internets", RFC 1918,
February 1996.
[4]Rekhter、Y.、マスコウィッツ、R.、Karrenberg、D.、deグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」RFC1918(1996年2月)。
[5] The North American Network Operators Group;
http://www.nanog.org.
[5] 北米のネットワーク・オペレータは分類します。 http://www.nanog.org 。
[6] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[6] パーキンス、C.、「IP移動性サポート」、RFC2002、1996年10月。
[7] Montenegro, G., "Reverse Tunneling Mobile IP",
Work in Progress.
[7] モンテネグロ、G.、「逆のトンネリングモバイルIP」が進行中で働いています。
[8] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[8] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[9] Thanks to: Craig Huegen;
See: http://www.quadrunner.com/~chuegen/smurf.txt.
[9] 以下のことのためにありがとうございます。 クレイグHuegen。 見ます: http://www.quadrunner.com/~chuegen/smurf.txt 。
Ferguson & Senie Informational [Page 8] RFC 2267 Network Ingress Filtering January 1998
1998年1月をフィルターにかけるファーガソンとSenieの情報[8ページ]のRFC2267ネットワークイングレス
10. Authors' Addresses
10. 作者のアドレス
Paul Ferguson cisco Systems, Inc. 400 Herndon Parkway Herndon, VA USA 20170
ヴァージニア米国 ポールファーガソンコクチマスSystems Inc.400ハーンドンパークウェイハーンドン、20170
EMail: ferguson@cisco.com
メール: ferguson@cisco.com
Daniel Senie BlazeNet, Inc. 4 Mechanic Street Natick, MA USA 01760
MA米国 01760のダニエルSenie BlazeNet Inc.4整備士通りナティック
EMail: dts@senie.com
メール: dts@senie.com
Ferguson & Senie Informational [Page 9] RFC 2267 Network Ingress Filtering January 1998
1998年1月をフィルターにかけるファーガソンとSenieの情報[9ページ]のRFC2267ネットワークイングレス
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Ferguson & Senie Informational [Page 10]
ファーガソンとSenie情報です。[10ページ]
一覧
スポンサーリンク
