RFC1858 日本語訳
1858 Security Considerations for IP Fragment Filtering. G. Ziemba, D.Reed, P. Traina. October 1995. (Format: TXT=20468 bytes) (Updated by RFC3128) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Ziemba
Request for Comments: 1858 Alantec
Category: Informational D. Reed
Cybersource
P. Traina
cisco Systems
October 1995
Ziembaがコメントのために要求するワーキンググループG.をネットワークでつないでください: 1858年のAlantecカテゴリ: 情報のD.のリードCybersource P.TrainaコクチマスSystems1995年10月
Security Considerations for IP Fragment Filtering
IP断片フィルタリングのためのセキュリティ問題
Status of This Memo
このメモの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
IP fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document describes two methods of attack as well as remedies to prevent them.
ルータとホストで使用されるIPフィルタからTCPパケットを変装するのにIP断片化を使用できます。 このドキュメントは療法と同様に攻撃がそれらを防ぐ2つのメソッドを説明します。
1. Background
1. バックグラウンド
System administrators rely on manufacturers of networking equipment to provide them with packet filters; these filters are used for keeping attackers from accessing private systems and information, while permitting friendly agents to transfer data between private nets and the Internet. For this reason, it is important for network equipment vendors to anticipate possible attacks against their equipment and to implement robust mechanisms to deflect such attacks.
システム管理者はパケットフィルタを彼らに提供するためにネットワーク設備のメーカーに頼ります。 これらのフィルタは、好意的なエージェントが個人的なネットとインターネットの間にデータを移すことを許可している間、攻撃者が個人的なシステムと情報にアクセスするのを妨げるのに使用されます。 この理由で、ネットワーク装置ベンダーがそれらの設備に対して可能な攻撃を予期して、そのような攻撃から向きをそらすために強健なメカニズムを実装するのは重要です。
The growth of the global Internet has brought with it an increase in "undesirable elements" manifested in antisocial behavior. Recent months have seen the use of novel attacks on Internet hosts, which have in some cases led to the compromise of sensitive data.
世界的なインターネットの成長はそれと共に反社会的行動で表される「有害分子」の増加をもたらしました。 最近の月はインターネット・ホストにおける目新しい攻撃の使用を見ました。いくつかの場合、彼は極秘データの感染に通じました。
Increasingly sophisticated attackers have begun to exploit the more subtle aspects of the Internet Protocol; fragmentation of IP packets, an important feature in heterogeneous internetworks, poses several potential problems which we explore here.
ますます洗練された攻撃者はインターネットプロトコルの、より微妙な局面を利用し始めました。 IPパケットの断片化(異種のインターネットワークにおける重要な特徴)は私たちがここで探るいくつかの潜在的な問題を引き起こします。
Ziemba, Reed & Traina Informational [Page 1] RFC 1858 Security Considerations - IP Fragment Filtering October 1995
Ziemba、リード、およびTrainaの情報[1ページ]のRFC1858セキュリティ問題--IP断片フィルタリング1995年10月
2. Filtering IP Fragments
2. IP断片をフィルターにかけます。
IP packet filters on routers are designed with a user interface that hides packet fragmentation from the administrator; conceptually, an IP filter is applied to each IP packet as a complete entity.
ルータのIPパケットフィルタはパケット断片化を管理者から隠すユーザーインタフェースで設計されています。 概念的に、IPフィルタは完全な実体としてそれぞれのIPパケットに適用されます。
One approach to fragment filtering, described by Mogul [1], involves keeping track of the results of applying filter rules to the first fragment (FO==0) and applying them to subsequent fragments of the same packet. The filtering module would maintain a list of packets indexed by the source address, destination address, protocol, and IP ID. When the initial (FO==0) fragment is seen, if the MF bit is set, a list item would be allocated to hold the result of filter access checks. When packets with a non-zero FO come in, look up the list element with a matching SA/DA/PROT/ID and apply the stored result (pass or block). When a fragment with a zero MF bit is seen, free the list element.
ムガール人[1]によって説明されたフィルタリングを断片化する1つのアプローチが、最初の断片(FO==0)にフィルタ規則を適用して、同じパケットのその後の断片にそれらを適用するという結果の動向をおさえることを伴います。 フィルタリングモジュールはソースアドレス、送付先アドレス、プロトコル、およびIP IDによって索引をつけられたパケットのリストを維持するでしょう。 MFビットを設定するなら初期の(FO==0)断片を見ると、フィルタアクセスチェックの結果を保持するためにリスト商品を割り当てるでしょう。 非ゼロFOがあるパケットが入るときには合っているSA/DA/PROT/IDと共にリスト要素を調べてください、そして、保存された結果(通るか、または妨げる)を適用してください。 MFが噛み付いたゼロがある断片が見られたら、リスト要素を解放してください。
Although this method (or some refinement of it) might successfully remove any trace of the offending whole packet, it has some difficulties. Fragments that arrive out of order, possibly because they traveled over different paths, violate one of the design assumptions, and undesired fragments can leak through as a result. Furthermore, if the filtering router lies on one of several parallel paths, the filtering module will not see every fragment and cannot guarantee complete fragment filtering in the case of packets that should be dropped.
このメソッド(または、それの何らかの気品)は首尾よく怒っている全体のパケットのどんな跡も取り除くかもしれませんが、それは苦労します。 ことによると異なった経路の上を旅行したので故障していた状態で届く断片はデザイン仮定の1つに違反します、そして、望まれない断片はその結果突き抜けた状態で漏れることができます。 その上、フィルタリングルータがいくつかの平行な経路の1つにあるなら、フィルタリングモジュールは、あらゆる断片を見るというわけではなくて、パケットのケースでそれをフィルターにかけるのが下げられるべきであるのを完全な断片に保証できません。
Fortunately, we do not need to remove all fragments of an offending packet. Since "interesting" packet information is contained in the headers at the beginning, filters are generally applied only to the first fragment. Non-first fragments are passed without filtering, because it will be impossible for the destination host to complete reassembly of the packet if the first fragment is missing, and therefore the entire packet will be discarded.
幸い、私たちは怒っているパケットのすべての断片を取り除く必要はありません。 「おもしろい」パケット情報が始めにヘッダーに含まれているので、一般に、フィルタは最初の断片だけに適用されます。 非まず最初に、断片はフィルタリングなしで渡されます、最初の断片がなくなるとあて先ホストがパケットの再アセンブリを完成するのが、不可能であり、したがって、全体のパケットは捨てられるでしょう。
The Internet Protocol allows fragmentation of packets into pieces so small as to be impractical because of data and computational overhead. Attackers can sometimes exploit typical filter behavior and the ability to create peculiar fragment sequences in order to sneak otherwise disallowed packets past the filter. In normal practice, such pathalogical fragmentation is never used, so it is safe to drop these fragments without danger of preventing normal operation.
インターネットプロトコルはばらばらにデータとコンピュータのオーバーヘッドで非実用的であるほど小さくパケットの断片化を許します。 攻撃者は時々典型的なフィルタの振舞いを利用できます、そして、そうでなければ、潜入するために独特の断片系列を作成する能力はフィルタの先でパケットを禁じました。 実際には、正常なそのようなpathalogical断片化が決して使用されないので、通常の操作を防ぐという危険なしでこれらの断片を下げるのは安全です。
Ziemba, Reed & Traina Informational [Page 2] RFC 1858 Security Considerations - IP Fragment Filtering October 1995
Ziemba、リード、およびTrainaの情報[2ページ]のRFC1858セキュリティ問題--IP断片フィルタリング1995年10月
3. Tiny Fragment Attack
3. 小さい断片攻撃
With many IP implementations it is possible to impose an unusually small fragment size on outgoing packets. If the fragment size is made small enough to force some of a TCP packet's TCP header fields into the second fragment, filter rules that specify patterns for those fields will not match. If the filtering implementation does not enforce a minimum fragment size, a disallowed packet might be passed because it didn't hit a match in the filter.
多くのIP実装では、異常に小さい断片サイズを出発しているパケットに課すのは可能です。 断片サイズをTCPパケットのTCPヘッダーフィールドのいくつかを2番目の断片に強制できるくらい小さくすると、それらの分野にパターンを指定するフィルタ規則が合わないでしょう。 フィルタリング実装が最小の断片サイズを実施しないなら、フィルタでマッチを打たなかったので、禁じられたパケットは通過されるかもしれません。
STD 5, RFC 791 states:
STD5、RFC791州:
Every internet module must be able to forward a datagram of 68
octets without further fragmentation. This is because an internet
header may be up to 60 octets, and the minimum fragment is 8
octets.
あらゆるインターネットモジュールがさらなる断片化なしで68の八重奏のデータグラムを進めることができなければなりません。 これはインターネットヘッダーが最大60の八重奏であるかもしれなく、最小の断片が8つの八重奏であるからです。
Note that, for the purpose of security, it is not sufficient to merely guarantee that a fragment contains at least 8 octets of data beyond the IP header because important transport header information (e.g., the CODE field of the TCP header) might be beyond the 8th data octet.
重要な輸送ヘッダー情報(例えば、TCPヘッダーのCODE分野)が8番目のデータ八重奏を超えているかもしれないので断片がIPヘッダーを超えてデータの少なくとも8つの八重奏を含むのを単に保証するのがセキュリティの目的のために十分でないことに注意してください。
3.1 Example of the Tiny Fragment Attack
3.1 小さい断片攻撃に関する例
In this example, the first fragment contains only eight octets of
data (the minimum fragment size). In the case of TCP, this is
sufficient to contain the source and destination port numbers, but
it will force the TCP flags field into the second fragment.
この例では、最初の断片はデータ(最小の断片サイズ)の8つの八重奏だけを含んでいます。 TCPの場合に、これがソースと目的地ポートナンバーを含むことができるくらいそれは2番目の断片に旗がさばくTCPを力づくで押すでしょう。
Filters that attempt to drop connection requests (TCP datagrams
having SYN=1 and ACK=0) will be unable to test these flags in the
first octet, and will typically ignore them in subsequent
fragments.
接続要求(SYN=1とACK=0を持っているTCPデータグラム)を下げるのを試みるフィルタが、最初の八重奏でこれらの旗を検査できないで、その後の断片でそれらを通常無視するでしょう。
FRAGMENT 1
断片1
IP HEADER
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
| | ... | Fragment Offset = 0 | ... | |
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
IPヘッダー++++++++++++++++++++| | ... | 断片は=0を相殺しました。| ... | | +-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
TCP HEADER
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCPヘッダー+++++++++++++++++++++++++++++++++| ソースポート| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ziemba, Reed & Traina Informational [Page 3] RFC 1858 Security Considerations - IP Fragment Filtering October 1995
Ziemba、リード、およびTrainaの情報[3ページ]のRFC1858セキュリティ問題--IP断片フィルタリング1995年10月
FRAGMENT 2
断片2
IP HEADER
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
| | ... | Fragment Offset = 1 | ... | |
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
IPヘッダー++++++++++++++++++++| | ... | 断片は=1を相殺しました。| ... | | +-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
TCP HEADER
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCPヘッダー+++++++++++++++++++++++++++++++++| 確認応答番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ| |U|A|P|R|S|F| | | 相殺されます。| 予約されます。|R|C|S|S|Y|I| 窓| | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2 Prevention of the Tiny Fragment Attack
3.2 小さい断片攻撃の防止
In a router, one can prevent this sort of attack by enforcing
certain limits on fragments passing through, namely, that the
first fragment be large enough to contain all the necessary header
information.
ルータでは、1つは、すべての必要なヘッダー情報を含むことができるくらい大きい状態である限界に最初の断片があるすなわち、通り抜ける断片に押しつけることによって、この種類の攻撃を防ぐことができます。
There are two ways to guarantee that the first fragment of a
"passed" packet includes all the required fields, one direct, the
other indirect.
aの最初の断片がすべての必須項目、1をパケットインクルードにダイレクトに「通った」という保証、もう片方への間接的な2つの方法があります。
3.2.1 Direct Method
3.2.1 ダイレクトメソッド
There is some number TMIN which is the minimum length of a
transport header required to contain "interesting" fields
(i.e., fields whose values are significant to packet filters).
This length is measured from the beginning of the transport
header in the original unfragmented IP packet.
「おもしろい」分野(すなわち、値がパケットフィルタに重要である分野)を含むのに必要である輸送ヘッダーの最小の長さである何らかの数のTMINがあります。 この長さはオリジナルの非断片化しているIPパケットで輸送ヘッダーの始まりから測定されます。
Note that TMIN is a function of the transport protocol involved
and also of the particular filters currently configured.
TMINがかかわって、現在特定のフィルタについても構成されているトランスポート・プロトコルの機能であることに注意してください。
The direct method involves computing the length of the
transport header in each zero-offset fragment and comparing it
against TMIN. If the transport header length is less than
TMIN, the fragment is discarded. Non-zero-offset fragments
need not be checked because if the zero-offset fragment is
discarded, the destination host will be unable to complete
reassembly. So far we have:
ダイレクトメソッドは、それぞれのゼロオフセット断片の輸送ヘッダーの長さを計算して、TMINに対してそれを比較することを伴います。 輸送ヘッダ長がTMIN以下であるなら、断片は捨てられます。 ゼロオフセット断片が捨てられると、あて先ホストが再アセンブリを完成できないので、非ゼロオフセット断片はチェックされる必要はありません。 今までのところ、私たちには、以下があります。
Ziemba, Reed & Traina Informational [Page 4] RFC 1858 Security Considerations - IP Fragment Filtering October 1995
Ziemba、リード、およびTrainaの情報[4ページ]のRFC1858セキュリティ問題--IP断片フィルタリング1995年10月
if FO=0 and TRANSPORTLEN < tmin then
DROP PACKET
FO=0とTRANSPORTLEN<が当時のDROP PACKETをtminするなら
However, the "interesting" fields of the common transport
protocols, except TCP, lie in the first eight octets of the
transport header, so it isn't possible to push them into a
non-zero-offset fragment. Therefore, as of this writing, only
TCP packets are vulnerable to tiny-fragment attacks and the
test need not be applied to IP packets carrying other transport
protocols. A better version of the tiny fragment test might
therefore be:
しかしながら、TCP以外に、輸送ヘッダーの最初の8つの八重奏には一般的なトランスポート・プロトコルの「おもしろい」分野があるので、非ゼロオフセット断片にそれらを押し込むのは可能ではありません。 したがって、この書くこと現在TCPパケットだけが小さい断片攻撃に被害を受け易いです、そして、テストは他のトランスポート・プロトコルを運ぶIPパケットに適用される必要はありません。 したがって、小さい断片テストの、より良いバージョンは以下の通りです。
if FO=0 and PROTOCOL=TCP and TRANSPORTLEN < tmin then
DROP PACKET
FO=0とプロトコルがTCPとTRANSPORTLENの<のtminの当時のDROP PACKETと等しいなら
As discussed in the section on overlapping fragments below,
however, this test does not block all fragmentation attacks,
and is in fact unnecessary when a more general technique is
used.
以下で断片を重ね合わせるところのセクションで議論するように、しかしながら、このテストは、すべての断片化攻撃を妨げるというわけではなくて、事実上、より一般的なテクニックが使用されているとき、不要です。
3.2.2 Indirect Method
3.2.2 間接的なメソッド
The indirect method relies on the observation that when a TCP
packet is fragmented so as to force "interesting" header fields
out of the zero-offset fragment, there must exist a fragment
with FO equal to 1.
間接的なメソッドはTCPパケットがゼロオフセット断片から「おもしろい」ヘッダーフィールドを強制するために断片化されるとき、1と等しいFOがある断片が存在しなければならないという観測に依存します。
If a packet with FO==1 is seen, conversely, it could indicate
the presence, in the fragment set, of a zero-offset fragment
with a transport header length of eight octets Discarding this
one-offset fragment will block reassembly at the receiving host
and be as effective as the direct method described above.
FO==1があるパケットが見られるなら、逆に、存在を示すかもしれません、断片セットで8八重奏Discardingの輸送ヘッダ長があるゼロオフセット断片では、この1によるオフセットの断片は、受信ホストで再アセンブリを妨げて、ダイレクトメソッドが上で説明したのと同じくらい有効でしょう。
4. Overlapping Fragment Attack
4. 断片攻撃を重ね合わせます。
RFC 791, the current IP protocol specification, describes a reassembly algorithm that results in new fragments overwriting any overlapped portions of previously-received fragments.
RFC791(現在のIPプロトコル仕様)は以前に容認された断片のどんな重ね合わせられた部分も上書きする新しい断片をもたらす再アセンブリアルゴリズムを説明します。
Given such a reassembly implementation, an attacker could construct a series of packets in which the lowest (zero-offset) fragment would contain innocuous data (and thereby be passed by administrative packet filters), and in which some subsequent packet having a non- zero offset would overlap TCP header information (destination port, for instance) and cause it to be modified. The second packet would be passed through most filter implementations because it does not have a zero fragment offset.
そのような再アセンブリ実装を考えて、攻撃者は非ゼロオフセットを持っているあるその後のパケットで最も低い(ゼロオフセット)断片が無毒のデータ(そして、その結果、管理パケットフィルタで、通過される)を含んで、TCPヘッダー情報(例えば、仕向港)を重ね合わせて、それを変更する一連のパケットを組み立てることができました。 ゼロがそれでオフセットを断片化しないので、2番目のパケットはほとんどのフィルター実現を通り抜けるでしょう。
Ziemba, Reed & Traina Informational [Page 5] RFC 1858 Security Considerations - IP Fragment Filtering October 1995
Ziemba、リード、およびTrainaの情報[5ページ]のRFC1858セキュリティ問題--IP断片フィルタリング1995年10月
RFC 815 outlines an improved datagram reassembly algorithm, but it concerns itself primarily with filling gaps during the reassembly process. This RFC remains mute on the issue of overlapping fragments.
RFC815はデータグラムの改良された再アセンブリアルゴリズムを概説しますが、それは主として再アセンブリプロセスの間、いっぱいにするのに不足をタッチします。 重なることの問題におけるこのRFC残り無言は断片化します。
Thus, fully-compliant IP implementations are not guaranteed to be immune to overlapping-fragment attacks. The 4.3 BSD reassembly implementation takes care to avoid these attacks by forcing data from lower-offset fragments to take precedence over data from higher- offset fragments. However, not all IP implementations are based on the original BSD code, and it is likely that some of them are vulnerable.
したがって、完全に対応することのIP実装は、重なっている断片攻撃に免疫があるために保証されません。 4.3BSD reassembly実装は、下側のオフセット断片からのデータをより高いオフセット断片からのデータの上で優先させることによってこれらの攻撃を避けるために注意されます。 しかしながら、すべてのIP実装が元のBSDコードに基づくというわけではありません、そして、それらのいくつかが被害を受け易いのは、ありそうです。
4.1 Example of the Overlapping Fragment Attack
4.1 重なっている断片攻撃に関する例
In this example, fragments are large enough to satisfy the minimum
size requirements described in the previous section. The filter
is configured to drop TCP connection request packets.
この例では、断片は前項で説明された最小規模要件を満たすことができるくらい大きいです。 フィルタは、TCP接続リクエスト・パケットを下げるために構成されます。
The first fragment contains values, e.g., SYN=0, ACK=1, that
enable it to pass through the filter unharmed.
最初の断片は値、SYN=0、例えば無傷でフィルタを通り抜けるのを可能にするACK=1を含んでいます。
The second fragment, with a fragment offset of eight octets,
contains TCP Flags that differ from those given in the first
fragment, e.g., SYN=1, ACK=0. Since this second fragment is not a
0-offset fragment, it will not be checked, and it, too will pass
through the filter.
8つの八重奏の断片オフセットで、2番目の断片は最初の断片で与えられたものと異なっているTCP Flags、例えばSYN=1(ACK=0)を含んでいます。 そして、この2番目の断片が0によるオフセットの断片でないので、それがチェックされない、それ、また、フィルタを通り抜けるでしょう。
The receiving host, if it conforms fully to the algorithms given
in RFC 791, will reconstitute the packet as a connection request
because the "bad" data arrived later.
RFC791で与えられたアルゴリズムに完全に従うと、「悪い」データが後で到着したので、受信ホストは接続要求としてパケットを再編成するでしょう。
Ziemba, Reed & Traina Informational [Page 6] RFC 1858 Security Considerations - IP Fragment Filtering October 1995
Ziemba、リード、およびTrainaの情報[6ページ]のRFC1858セキュリティ問題--IP断片フィルタリング1995年10月
FRAGMENT 1
断片1
IP HEADER
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
| | ... | Fragment Offset = 0 | ... | |
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
IPヘッダー++++++++++++++++++++| | ... | 断片は=0を相殺しました。| ... | | +-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
TCP HEADER
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Other data) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCPヘッダー+++++++++++++++++++++++++++++++++| ソースポート| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 確認応答番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ| |U|A|P|R|S|F| | | 相殺されます。| 予約されます。|R|C|S|S|Y|I| 窓| | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (他のデータ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FRAGMENT 2
断片2
IP HEADER
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
| | ... | Fragment Offset = 1 | ... | |
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
IPヘッダー++++++++++++++++++++| | ... | 断片は=1を相殺しました。| ... | | +-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
TCP HEADER
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Other data) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCPヘッダー+++++++++++++++++++++++++++++++++| 確認応答番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ| |U|A|P|R|S|F| | | 相殺されます。| 予約されます。|R|C|S|S|Y|I| 窓| | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (他のデータ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ziemba, Reed & Traina Informational [Page 7] RFC 1858 Security Considerations - IP Fragment Filtering October 1995
Ziemba、リード、およびTrainaの情報[7ページ]のRFC1858セキュリティ問題--IP断片フィルタリング1995年10月
If the receiving host has a reassembly algorithm that prevents new
data from overwriting data received previously, we can send
Fragment 2 first, followed by Fragment 1, and accomplish the same
successful attack.
受信ホストに新しいデータが以前に受け取られたデータを上書きするのを防ぐ再アセンブリアルゴリズムがあるなら、私たちは、最初にFragment2を送って、Fragment1で続いて、同じうまくいっている攻撃を実行できます。
4.2 Prevention of the Overlapping Fragment Attack
4.2 重なっている断片攻撃の防止
Since no standard requires that an overlap-safe reassembly
algorithm be used, the potential vulnerability of hosts to this
attack is quite large.
どんな規格も、オーバラップ安全な再アセンブリアルゴリズムが使用されるのを必要としないので、この攻撃へのホストの潜在的脆弱性はかなり大きいです。
By adopting a better strategy in a router's IP filtering code, one
can be assured of blocking this "attack". If the router's
filtering module enforces a minimum fragment offset for fragments
that have non-zero offsets, it can prevent overlaps in filter
parameter regions of the transport headers.
コードをフィルターにかけるルータのIPの、より良い戦略を採用することによって、この「攻撃」を妨げるのを1を保証できます。 ルータのフィルタリングモジュールが非ゼロオフセットを持っている断片のために相殺された最小の断片を実施するなら、それは輸送ヘッダーのフィルタパラメタ領域でオーバラップを防ぐことができます。
In the case of TCP, this minimum is sixteen octets, to ensure that
the TCP flags field is never contained in a non-zero-offset
fragment. If a TCP fragment has FO==1, it should be discarded
because it starts only eight octets into the transport header.
Conveniently, dropping FO==1 fragments also protects against the
tiny fragment attack, as discussed earlier.
TCPの場合では、この最小限は、旗がさばくTCPが非ゼロオフセット断片に決して含まれていないのを保証するためには16の八重奏です。 TCP断片にFO==1があるなら、それは、8つの八重奏だけを輸送ヘッダーに始めるので、捨てられるべきです。 また、好都合なことに、FO==1断片を下げると、小さい断片攻撃より早く議論するように守られます。
RFC 791 demands that an IP stack must be capable of passing an 8
byte IP data payload without further fragmentation (fragments sit
on 8 byte boundaries). Since an IP header can be up to 60 bytes
long (including options), this means that the minimum MTU on a
link should be 68 bytes.
RFC791は、IPスタックがさらなる断片化なしで8バイトのIPデータペイロードを渡すことができなければならないのを要求します(断片が8つのバイト境界にあります)。 IPヘッダーが最大60バイト長であるかもしれない(オプションを含んでいて)ので、これは、リンクの上の最小のMTUが68バイトであるべきであることを意味します。
A typical IP header is only 20 bytes long and can therefore carry
48 bytes of data. No one in the real world should EVER be
generating a TCP packet with FO=1, as it would require both that a
previous system fragmenting IP data down to the 8 byte minimum and
a 60 byte IP header.
典型的なIPヘッダーは、20バイト長だけであり、したがって、48バイトのデータを運ぶことができます。 本当の世界のだれはも前のシステムがIPデータを断片化して、8バイトの最小限と60バイトのIPヘッダーにダウンする両方を必要とするだろう、そうしながらFO=1と共にTCPパケットを生成することであるEVERがそうするべきです。
A general algorithm, then, for ensuring that filters work in the
face of both the tiny fragment attack and the overlapping fragment
attack is:
一般的なアルゴリズム、そして、フィルタが小さい断片攻撃と重なることの両方に直面して働くのを確実にするために、断片攻撃は以下の通りです。
IF FO=1 and PROTOCOL=TCP then
DROP PACKET
IF FO=1とプロトコルはTCPの当時のDROP PACKETと等しいです。
If filtering based on fields in other transport protocol headers
is provided in a router, the minimum could be greater, depending
on the position of those fields in the header. In particular, if
filtering is permitted on data beyond the sixteenth octet of the
transport header, either because of a flexible user interface or
他のトランスポート・プロトコルヘッダーの分野に基づくフィルタリングをルータに提供するなら、最小限は、よりすばらしいかもしれません、ヘッダーのそれらの分野の位置によって。 またはフィルタリングがどちらかフレキシブルなユーザーインタフェースのためにデータで特に輸送ヘッダーの16番目の八重奏を超えて受入れられる。
Ziemba, Reed & Traina Informational [Page 8] RFC 1858 Security Considerations - IP Fragment Filtering October 1995
Ziemba、リード、およびTrainaの情報[8ページ]のRFC1858セキュリティ問題--IP断片フィルタリング1995年10月
the implementation of filters for some new transport protocol,
dropping packets with FO==1 might not be sufficient.
何らかの新しいトランスポート・プロトコルのためのフィルタの実装であり、FO==1と共にパケットを下げるのは十分でないかもしれません。
5. Security Considerations
5. セキュリティ問題
This memo is concerned entirely with the security implications of filtering fragmented IP packets.
このメモは完全に断片化しているIPパケットをフィルターにかけるセキュリティ含意するのに関係があります。
6. Acknowledgements
6. 承認
The attack scenarios described above grew from discussions that took place on the firewalls mailing list during May of 1995. Participants included: Darren Reed <avalon@coombs.anu.edu.au>, Tom Fitzgerald <fitz@wang.com>, and Paul Traina <pst@cisco.com>.
上で説明された攻撃シナリオは1995年5月にファイアウォールメーリングリストで行われた議論から成長しました。 関係者は:だった ダーレン Reed <avalon@coombs.anu.edu.au 、gt;、トム Fitzgerald <fitz@wang.com 、gt;、ポール Traina <pst@cisco.com 、gt。
7. References
7. 参照
[1] Mogul, J., "Simple and Flexible Datagram Access Controls for
Unix-based Gateways", Digital Equipment Corporation, March 1989.
[1] ムガール人、J.、「unixベースのゲートウェイへの簡単でフレキシブルなデータグラムアクセス制御」、ディジタルイクイップメント社、1989年3月。
[2] Postel, J., Editor, "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 791, USC/Information Sciences
Institute, September 1981.
[2] ポステル、J.、エディタ、「インターネットは議定書を作ります--DARPAインターネットプログラムプロトコル仕様」、STD5、RFC791、科学が設けるUSC/情報、1981年9月。
[3] Postel, J., Editor, "Transmission Control Protocol - DARPA
Internet Program Protocol Specification", STD 7, RFC 793,
USC/Information Sciences Institute, September 1981.
[3] ポステル、J.、エディタ、「転送管理は議定書を作ります--DARPAインターネットプログラムプロトコル仕様」、STD7、RFC793、科学が設けるUSC/情報、1981年9月。
[4] Clark, D., "IP Datagram Reassembly Algorithms", RFC 815, MIT
Laboratory for Computer Science/Computer Systems and
Communications Group, July 1982.
[4] クラーク、D.、「IPデータグラムReassemblyアルゴリズム」、RFC815、MITコンピュータサイエンス研究所/コンピュータ・システム、およびコミュニケーションは1982年7月に分類されます。
Ziemba, Reed & Traina Informational [Page 9] RFC 1858 Security Considerations - IP Fragment Filtering October 1995
Ziemba、リード、およびTrainaの情報[9ページ]のRFC1858セキュリティ問題--IP断片フィルタリング1995年10月
Authors' Addresses
作者のアドレス
G. Paul Ziemba Alantec 2115 O'Nel Drive San Jose, CA 95131
G.ポールZiemba Alantec2115O'Nel Driveサンノゼ、カリフォルニア 95131
EMail: paul@alantec.com
メール: paul@alantec.com
Darren Reed Cybersource 1275A Malvern Rd Melbourne, Vic 3144 Australia
ダーレン・リード・Cybersource 1275Aマルバーンヴィク3144・第メルボルン(オーストラリア)
EMail: darrenr@cyber.com.au
メール: darrenr@cyber.com.au
Paul Traina cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95028
サンノゼ、ポールTrainaコクチマスSystems Inc.170W.タスマン博士カリフォルニア 95028
EMail: pst@cisco.com
メール: pst@cisco.com
Ziemba, Reed & Traina Informational [Page 10]
Ziemba、リード、およびTraina情報です。[10ページ]
一覧
スポンサーリンク
