RFC3128 日本語訳

Network Working Group                                          I. Miller
Request for Comments: 3128                                Singularis Ltd
Updates: 1858                                                  June 2001
Category: Informational

コメントを求めるワーキンググループI.ミラーの要求をネットワークでつないでください: 3128のSingularis Ltdアップデート: 1858 2001年6月のカテゴリ: 情報

        Protection Against a Variant of the Tiny Fragment Attack

小さい断片攻撃の異形に対する保護

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 (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

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で説明された「小さい断片攻撃」の異形に被害を受け易い場合があるかについて議論します。 このドキュメントは、攻撃について説明して、修正措置を推薦します。

1. Introduction

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.

RFC1858はインターネットファイアウォールにおける攻撃のクラスの素晴らしい記述を提供して、対策を提案します。 しかしながら、これらのcountmeasuresの1つ、「間接的なメソッド」(セクション3.2.2)は説明された2つの攻撃の組み合わせに被害を受け易いです。

   The attack combines the features of the "Tiny Fragment Attack"
   (section 3) and the "Overlapping Fragment Attack" (section 4).

攻撃は「小さい断片攻撃」(セクション3)と「重なっている断片攻撃」(セクション4)の特徴を結合します。

1.1 The scope of the attack

1.1 攻撃の範囲

   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.

フィルタリング規則がそこのもう一方が移植するマシンANDへの同じホストの上で外向的な接続だけを許す接続要求を許容するところでは、攻撃は推定上外向的に唯一のポートに接続要求を許容します。

   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.

初期の接続メッセージだけが断片化されなければならないことに注意してください。 接続がいったんさらに確立されると、それのトラフィックは法的です。 この弱点の意味は大挙して安全保障政策によるでしょう。

Miller                       Informational                      [Page 1]

RFC 3128       Protection Against a Tiny Fragment Attack       June 2001

小さい断片攻撃2001年6月に対するミラー情報[1ページ]のRFC3128Protection

2. The Tiny Overlapping Fragment Attack

2. 小さい重なっている断片攻撃

   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) 全体のヘッダーを含んで、完全に法的です。 通常、それは25SMTPを移植するために接続要求例えばIncoming接続を受けることができる目標ホストの上のポートに新しいTCP接続を開始するSYNパケットについて説明します。

   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バイトだけであり、法的であるかもしれませんが、Fragment1からの対応するバイトに結合されていた状態で、法的ではありません。 そのような断片は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を断片化してください; メッセージの長さ=残り) ヘッダーを全く含んでいなくて、メッセージを完成します。 (この3番目の断片は攻撃の一部ではありません。 しかしながら、Fragment1が完全なメッセージであるはずがないので、Fragment2が到着する前にそれはアプリケーションまで通過されて、3番目の断片が必要です。)

2.1 Example of the attack

2.1 攻撃に関する例

   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          |
   +---+-------+-------+-------+-------+-----------------------+

+---+-------+-------+-------+-------+-----------------------+ | いいえ|動作| ソース| Dest。 | 旗| 目的| | | | ポート| ポート| | | +===+=======+=======+=======+=======+=======================+ | 1 |許可証| >1023| SMTP| 少しも| 入ってくる電子メール| +---+-------+-------+-------+-------+-----------------------+ | 2 |許可証| >1023| 少しも| Ack=1| 既存のFTPデータ| | | | | | チャンネル接続。 | +---+-------+-------+-------+-------+-----------------------+ | 3 |否定します。| 少しも| 少しも| 少しも| デフォルトは否定します。| +---+-------+-------+-------+-------+-----------------------+

   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 Thisは新しい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: 存在しているAll分野のない攻撃者(1234)->目標(telnet=23)Ack=は規則2に従います、それがFTPパケットの始まりであるかもしれないので。

Miller                       Informational                      [Page 2]

RFC 3128       Protection Against a Tiny Fragment Attack       June 2001

小さい断片攻撃2001年6月に対するミラー情報[2ページ]のRFC3128Protection

   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接続)

2.2 The failure of "Indirect Method"

2.2 「間接的なメソッド」の失敗

   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.

Indirect Methodは、唯一FO=1と共にパケットを拒絶することによってTiny FragmentとOverlapping Fragment攻撃の両方を解決するのを試みます。 しかしながら、上の断片のいずれにはもFO=1がないので、なにも拒絶されません。

   The failure is clear on careful reading.  In section 3.2.2 "Indirect
   Method", RFC 1858 states:-

失敗は熟読に関して明確です。 セクション3.2.2「間接的なメソッド」でRFC1858が以下を述べる、-

      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.

これは断片が一般に誠実なソフトウェアによる本物の断片であるところで通常本当ですが、単にその人が8バイトのFO=0断片を作り出したので断片を作り出すハッカーがやむを得ずFO=1断片を作り出すのは、絶対に本当ではありません。 脆弱性はこの誤った前提から流れます。

3. Countermeasures

3. 対策

   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.

1858明らかに非常に上品なRFC年代のIndirect Methodは強健ではありませんが。 また、FO=1パケットを妨げることに加えて、完全なヘッダーほど成立しない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の当時のDROP PACKETと等しいならFO=0とプロトコルがTCPとTRANSPORTLENの<のtminの当時のDROP PACKETと等しいなら

4. Security Considerations

4. セキュリティ問題

   This memo is concerned entirely with the security implications of
   filtering fragmented IP packets.

このメモは完全に断片化しているIPパケットをフィルターにかけるセキュリティ含意するのに関係があります。

Miller                       Informational                      [Page 3]

RFC 3128       Protection Against a Tiny Fragment Attack       June 2001

小さい断片攻撃2001年6月に対するミラー情報[3ページ]のRFC3128Protection

5. Author's Address

5. 作者のアドレス

   Ian Miller
   Singularis Ltd
   32 Stockwell Street
   Cambridge
   CB1 3ND  UK

イアンミラーSingularis Ltd32ストックウェル・通りケンブリッジCB1 3NDイギリス

   Phone: +44 1223 511943
   EMail: Ian_Miller@singularis.ltd.uk

以下に電話をしてください。 +44 1223 511943はメールされます: Ian_Miller@singularis.ltd.uk

Miller                       Informational                      [Page 4]

RFC 3128       Protection Against a Tiny Fragment Attack       June 2001

小さい断片攻撃2001年6月に対するミラー情報[4ページ]のRFC3128Protection

6. Full Copyright Statement

6. 完全な著作権宣言文

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Miller                       Informational                      [Page 5]

ミラーInformationalです。[5ページ]