Network Working Group I. Miller
Request for Comments: 3128 Singularis Ltd
Updates: 1858 June 2001
Category: Informational
Protection Against a Variant of the Tiny Fragment Attack
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 (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document discusses how RFC 1858 compliant filters can be vulnerable to a variant of the "Tiny Fragment Attack" described in section 3.1 of the RFC. This document describes the attack and recommends corrective action.
この文書は、RFC 1858に準拠し、フィルタはRFCのセクション3.1に記載された「タイニーフラグメント攻撃」の変形に対して脆弱であることができる方法について説明します。この文書では、攻撃を説明し、是正措置を推奨しています。
RFC 1858 provides an excellent description of a class of attack on Internet firewalls and proposes countermeasures. However one of these countmeasures, the "Indirect Method" (section 3.2.2) is vulnerable to a combination of two of the attacks described.
RFC 1858は、インターネットファイアウォールへの攻撃のクラスの優れた記述を提供し、対策を提案しています。しかしながら、これらcountmeasuresの一つに、「間接法」（セクション3.2.2）に記載さ攻撃の二つの組み合わせに対して脆弱です。
The attack combines the features of the "Tiny Fragment Attack" (section 3) and the "Overlapping Fragment Attack" (section 4).
攻撃は（セクション3）と「オーバーラッピングフラグメント攻撃」（第4章）、「タイニーフラグメント攻撃」の機能を兼ね備えています。
Where the filtering rules allow incoming connections to a machine AND there other ports which allow only outgoing connections on the same host, the attack allows incoming connections to the supposedly outgoing-only ports.
フィルタリングルールは、マシンへの着信接続と同じホスト上にのみ発信接続を許可するが、他のポートを許可する場合、攻撃はおそらく、発信専用ポートへの着信接続を許可します。
Note that only the initial connection message need be fragmented. Once the connection is established further traffic on it is legal. The significance of this weakness will depend on the security policy in force.
唯一の初期接続メッセージを断片化する必要があることに注意してください。接続が確立されると、その上にさらにトラフィックが合法です。この弱点の意義は、力のセキュリティポリシーに依存します。
The attack typically consists of sending three fragments.
攻撃は通常、3つのフラグメントを送信する構成されています。
Fragment 1: (Fragment offset = 0; length >= 16) Includes whole header and is entirely legal. Typically it describes a SYN packet initiating a new TCP connection to a port on the target host that is allowed to receive incoming connections. e.g., Incoming connection to port 25 SMTP.
フラグメント1：（フラグメントオフセット= 0;長さ> = 16）全体ヘッダを含み、完全に合法的です。一般的に、それは、着信接続を受信することが許可されているターゲットホスト上のポートへの新しいTCP接続を開始SYNパケットを説明します。例えば、ポート25 SMTPへの着信接続。
Fragment 2: (Fragment offset = 0; length = 8) Is only the first 8 bytes and could be legal depending on the other 8-bytes of the header, but is NOT legal combined with the corresponding bytes from Fragment 1. Such a fragment includes only the port numbers and sequence number from the TCP header. Typically this packet replaces the destination port number with a port number on which the destination host that is not allowed to receive incoming connections.
断片2：（フラグメントオフセット= 0;長さ= 8）最初の8バイトであり、ヘッダの他の8バイトに依存合法かもしれないが、そのような断片断片1から対応するバイトと組み合わせる有効ではありませんTCPヘッダからのみポート番号とシーケンス番号を含みます。典型的には、このパケットは、宛先ホストが着信接続を受信するように許可されていないポート番号と宛先ポート番号を置き換えます。
Fragment 3: (Fragment offset >= 2; length = rest of message) Contains no header and completes the message. (This third fragment is not part of the attack. However Fragment 1 cannot be the complete message or it would be passed up to the application before Fragment 2 arrived so a third fragment is necessary.)
断片3：（フラグメントオフセット> = 2であり、メッセージの長さ=残り）はヘッダを含まず、メッセージを終了します。 （この第三の断片は、攻撃の一部ではない。しかし、フラグメント1は、完全なメッセージではないか、またはフラグメント2が第三の断片が必要であるので、到着する前に、それがアプリケーションに渡されることになります。）
Consider the following trivial set of rules for incoming packets:
着信パケットのための規則の以下の些細なセットを考えてみましょう：
+---+-------+-------+-------+-------+-----------------------+
| No|Action | Source| Dest. | Flags | Purpose |
| | | Port | Port | | |
+===+=======+=======+=======+=======+=======================+
| 1 |Permit | >1023 | SMTP | ANY | Incoming E-mail |
+---+-------+-------+-------+-------+-----------------------+
| 2 |Permit | >1023 | ANY | Ack=1| Existing FTP data |
| | | | | channel connections. |
+---+-------+-------+-------+-------+-----------------------+
| 3 |Deny | ANY | ANY | ANY | Default deny |
+---+-------+-------+-------+-------+-----------------------+
Fragment 1: attacker(1234) -> target(SMTP) Ack=0 This is a new SMTP connection and is permitted by rule 1.
断片1：攻撃（1234） - >ターゲット（SMTP）ACK = 0これは、新しいSMTP接続であり、ルール1によって許可されています。
Fragment 2: attacker(1234) -> target(Telnet=23) Ack=absent All fields present conform to rule 2, as it could be the start of an FTP packet.
断片2：攻撃（1234） - それはFTPパケットの開始とすることができるように、本>ターゲット（Telnetの= 23）ACK =存在しないすべてのフィールドは、2のルールに従います。
Depending on the precise implementation of the fragment reassembly in the target machine's IP stack, fragment B may overwrite fragment A to produce:-
ターゲットマシンのIPスタック内の断片再組み立ての正確な実装に応じて、フラグメントBを生成するために、フラグメントAを上書きすることができます： -
attacker(1234) -> target(Telnet) Ack=0 (new telnet connection)
攻撃者（1234） - >ターゲット（Telnetの）ACK = 0（新しいtelnet接続）
The Indirect Method attempts to solve both Tiny Fragment and Overlapping Fragment attacks, solely by rejecting packets with FO=1. However none of the above fragments have FO=1, so none are rejected.
間接的な方法は、単にFO = 1のパケットを拒否することにより、小型フラグメントとオーバーラッピングフラグメント攻撃の両方を解決しようとします。しかし、上記の断片のいずれもがFO = 1持っていないので、どれも拒否されていません。
The failure is clear on careful reading. In section 3.2.2 "Indirect Method", RFC 1858 states:-
失敗は慎重に読書に明らかです。セクション3.2.2、 "間接法" では、RFC 1858の状態： -
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有するフラグメントが存在しなければならないという観察に依存しています。
This is normally true where the fragments are genuine fragments, generally by bona fide software, but it is simply not true that a hacker forging fragments is forced to produce an FO=1 fragment simply because (s)he has produced an 8-byte FO=0 fragment. The vulnerability flows from this false premise.
これは、フラグメントは、一般的に真正なソフトウェアによる本物のフラグメント、どこ通常は本当ですが、（s）は、彼が8バイトのFOを生産しているという理由だけで断片を鍛造ハッカーがFO = 1フラグメントを生成するように強制されていることを単に本当ではありません= 0断片。脆弱性は、この誤った前提から流れ。
Whereas apparently very elegant, RFC 1858's Indirect Method is not robust. In addition to blocking FO=1 packets, it is also necessary to block FO=0 that hold less than a complete header.
明らかに非常にエレガントなのに対し、RFC 1858の間接法は、堅牢ではありません。 = 1つのパケットFOをブロックすることに加えて、完全なヘッダ未満を保持FO = 0をブロックすることも必要です。
if FO=0 and PROTOCOL=TCP and TRANSPORTLEN < tmin then DROP PACKET if FO=1 and PROTOCOL=TCP then DROP PACKET
FO = 1及びプロトコルは= TCPは、パケットをドロップするとFO = 0とPROTOCOL = TCPとTRANSPORTLEN <Tminが、パケットをドロップした場合
This memo is concerned entirely with the security implications of filtering fragmented IP packets.
このメモは、断片化されたIPパケットをフィルタリングするセキュリティへの影響を完全に関係しています。
Ian Miller Singularis Ltd 32 Stockwell Street Cambridge CB1 3ND UK
イアン・ミラーシンガラリス株式会社32ストックウェル・ストリートケンブリッジCB1 3ND英国
Phone: +44 1223 511943 EMail: Ian_Miller@singularis.ltd.uk
電話：+44 1223 511943 Eメール：Ian_Miller@singularis.ltd.uk
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。