RFC1948 日本語訳

Network Working Group                                        S. Bellovin
Request for Comments: 1948                                 AT&T Research
Category: Informational                                         May 1996

Bellovinがコメントのために要求するワーキンググループS.をネットワークでつないでください: 大西洋標準時1948とTはカテゴリについて研究します: 情報の1996年5月

               Defending Against Sequence Number Attacks

一連番号攻撃に対して防御します。

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 spoofing attacks based on sequence number spoofing have become a
   serious threat on the Internet (CERT Advisory CA-95:01).  While
   ubiquitous crypgraphic authentication is the right answer, we propose
   a simple modification to TCP implementations that should be a very
   substantial block to the current wave of attacks.

一連番号スプーフィングに基づくIPスプーフィング攻撃はインターネット(CERT勧告カリフォルニア-95: 01)で重大な脅威になりました。 遍在しているcrypgraphic認証は正しい答ですが、私たちは非常にかなりのブロックであるべきであるTCP実装への簡単な変更を攻撃の電流波に提案します。

Overview and Rational

概要的で合理的です。

   In 1985, Morris [1] described a form of attack based on guessing what
   sequence numbers TCP [2] will use for new connections.  Briefly, the
   attacker gags a host trusted by the target, impersonates the IP
   address of the trusted host when talking to the target, and completes
   the 3-way handshake based on its guess at the next initial sequence
   number to be used.  An ordinary connection to the target is used to
   gather sequence number state information.  This entire sequence,
   coupled with address-based authentication, allows the attacker to
   execute commands on the target host.

1985年に、TCP[2]が新しい接続にどんな一連番号を使用するかを推測することに基づいてモリス[1]は攻撃のフォームについて説明しました。 簡潔に、攻撃者は、目標によって信じられたホストを黙らせて、目標と話すとき、信じられたホストのIPアドレスをまねて、使用されるために次の初期シーケンス番号での推測に基づく3ウェイ握手を終了します。 目標との普通の接続は、一連番号州の情報を集めるのに使用されます。 アドレスベースの認証に結びつけられたこの全体の系列で、攻撃者は目標ホストの上でコマンドを実行できます。

   Clearly, the proper solution is cryptographic authentication [3,4].
   But it will quite a long time before that is deployed.  It has
   therefore been necessary for many sites to restrict use of protocols
   that rely on address-based authentication, such as rlogin and rsh.
   Unfortunately, the prevalence of "sniffer attacks" -- network
   eavesdropping (CERT Advisory CA-94:01) -- has rendered ordinary
   TELNET [5] very dangerous as well.  The Internet is thus left without
   a safe, secure mechanism for remote login.

明確に、適切なソリューションは暗号の認証[3、4]です。 しかし、それが配布される前にそれはかなり長い時にそうするでしょう。 したがって、多くのサイトがアドレスベースの認証に依存するプロトコルの使用を制限するのが必要です、rloginやrshのように。 残念ながら、「パケット盗聴プログラム攻撃」の普及(ネットワーク盗聴(CERT勧告カリフォルニア-94: 01))は普通のTELNET[5]をまた、非常に危険にしました。 インターネットは安全で、安全なメカニズムなしでリモート・ログインにこのようにして出られます。

   We propose a simple change to TCP implementations that will block
   most sequence number guessing attacks.  More precisely, such attacks
   will remain possible if and only if the Bad Guy already has the
   ability to launch even more devastating attacks.

私たちはほとんどの一連番号推測攻撃を妨げるTCP実装への簡単な変化を提案します。 そして、 より正確に、そのような攻撃が可能なままで残る、Badガイに始める能力が既にある場合にだけ、さらに多くの荒らすことが攻撃されます。

Bellovin                     Informational                      [Page 1]

RFC 1948                Sequence Number Attacks                 May 1996

Bellovinの情報[1ページ]のRFC1948一連番号は1996年5月に攻撃されます。

Details of the Attack

攻撃の詳細

   In order to understand the particular case of sequence number
   guessing, one must look at the 3-way handshake used in the TCP open
   sequence [2].  Suppose client machine A wants to talk to rsh server
   B.  It sends the following message:

一連番号推測の特定のケースを理解するために、TCPの開いている系列[2]に使用される3ウェイ握手を見なければなりません。 クライアントマシンAがItが以下のメッセージを送るrshサーバB.と話したがっていると仮定してください:

           A->B: SYN, ISNa

1>のB: SYN、ISNa

   That is, it sends a packet with the SYN ("synchronize sequence
   number") bit set and an initial sequence number ISNa.

すなわち、それはSYN(「一連番号を同期させる」)ビットがセットしたことでのパケットと初期シーケンス番号ISNaを送ります。

   B replies with

Bは返答します。

           B->A: SYN, ISNb, ACK(ISNa)

B>A: SYN、ISNb、ACK(ISNa)

   In addition to sending its own initial sequence number, it
   acknowledges A's.  Note that the actual numeric value ISNa must
   appear in the message.

それ自身の初期シーケンス番号を送ることに加えて、それはAのものを承認します。 実際の数値ISNaがメッセージに現れなければならないことに注意してください。

   A concludes the handshake by sending

Aは、発信することによって、握手を結論づけます。

           A->B: ACK(ISNb)

1>のB: ACK(ISNb)

   The initial sequence numbers are intended to be more or less random.
   More precisely, RFC 793 specifies that the 32-bit counter be
   incremented by 1 in the low-order position about every 4
   microseconds.  Instead, Berkeley-derived kernels increment it by a
   constant every second, and by another constant for each new
   connection.  Thus, if you open a connection to a machine, you know to
   a very high degree of confidence what sequence number it will use for
   its next connection.  And therein lies the attack.

初期シーケンス番号が多少無作為であることを意図します。 より正確に、RFC793は、32ビットのカウンタが4マイクロセカンド毎に関する下位桁の1つ増加されると指定します。 代わりに、バークレーによって派生させられたカーネルはそれを毎秒の定数、およびそれぞれの新しい接続のための別の定数増加します。 したがって、マシンに接続を開くなら、あなたは、それが次の接続にどんな一連番号を使用するかを非常に高度合いの信用に知っています。 そして、そこに、攻撃があります。

   The attacker X first opens a real connection to its target B -- say,
   to the mail port or the TCP echo port.  This gives ISNb.  It then
   impersonates A and sends

攻撃者Xは最初に、目標Bに本当の接続を開きます--言ってください、メールポートかTCPエコーポートに。 これはISNbに与えます。 それは、次に、Aをまねて、発信します。

        Ax->B: SYN, ISNx

斧>B: SYN、ISNx

   where "Ax" denotes a packet sent by X pretending to be A.

「斧」がAであるふりをしながらXによって送られたパケットを指示するところ。

   B's response to X's original SYN (so to speak)

XのオリジナルのSYNへのビーズの応答(言わば)

        B->A: SYN, ISNb', ACK(ISNx)

B>A: 'SYN、ISNb'、ACK(ISNx)

Bellovin                     Informational                      [Page 2]

RFC 1948                Sequence Number Attacks                 May 1996

Bellovinの情報[2ページ]のRFC1948一連番号は1996年5月に攻撃されます。

   goes to the legitimate A, about which more anon.  X never sees that
   message but can still send

周囲に正統のAに行く、どれ、 よりやがて。 Xは、そのメッセージを決して見ませんが、まだ発信できます。

        Ax->B: ACK(ISNb')

斧>B: ACK'、(ISNb、'、)

   using the predicted value for ISNb'.  If the guess is right -- and
   usually it will be -- B's rsh server thinks it has a legitimate
   connection with A, when in fact X is sending the packets.  X can't
   see the output from this session, but it can execute commands as more
   or less any user -- and in that case, the game is over and X has won.

'ISNbに予測値を使用します'。 推測が正しいなら(そして、通常それはそうでしょう)、ビーズrshサーバは、それにはAとの正統の接続があると思います、事実上、Xがパケットを送るとき。 だいたいどんなユーザとしてもコマンドを実行できます、そして、その場合、ゲームは終わっています、そして、Xはこのセッションから出力を見ることができませんが、Xは勝ちました。

   There is a minor difficulty here.  If A sees B's message, it will
   realize that B is acknowledging something it never sent, and will
   send a RST packet in response to tear down the connection.  There are
   a variety of ways to prevent this; the easiest is to wait until the
   real A is down (possibly as a result of enemy action, of course).  In
   actual practice, X can gag A by exploiting a very common
   implementation bug; this is described below.

小さい方の困難がここにあります。 Aがビーズメッセージを見ると、それは、Bがそれが決して送らなかった何かを承認しているとわかって、接続の下側への裂け目に対応してRSTパケットを送るでしょう。 これを防ぐさまざまな方法があります。 最も簡単であるのは、本当のAが下がるまで(ことによると敵の動作の結果、もちろん)待つことです。 実際行なわれているところでは非常に一般的な実装バグを利用するのによるX缶のギャグA。 これは以下で説明されます。

The Fix

フィックス

   The choice of initial sequence numbers for a connection is not
   random.  Rather, it must be chosen so as to minimize the probability
   of old stale packets being accepted by new incarnations of the same
   connection [6, Appendix A].  Furthermore, implementations of TCP
   derived from 4.2BSD contain special code to deal with such
   reincarnations when the server end of the original connection is
   still in TIMEWAIT state [7, pp. 945].  Accordingly, simple
   randomization, as suggested in [8], will not work well.

接続の初期シーケンス番号の選択は無作為ではありません。 むしろ、同じ接続[6、Appendix A]の新しい肉体化によって受け入れられる古い聞き古したパケットの確率を最小にするためにそれを選ばなければなりません。 その上、4.2BSDから得られたTCPの実装はオリジナルの接続のサーバ終わりがまだTIMEWAIT状態にあるときそのような生まれ変わりに対処する特別なコードを含んでいます。[7、ページ 945]. それに従って、[8]に示される簡単な無作為化はうまくいかないでしょう。

   But duplicate packets, and hence the restrictions on the initial
   sequence number for reincarnations, are peculiar to individual
   connections.  That is, there is no connection, syntactic or semantic,
   between the sequence numbers used for two different connections.  We
   can prevent sequence number guessing attacks by giving each
   connection -- that is, each 4-tuple of <localhost, localport,
   remotehost, remoteport> -- a separate sequence number space.  Within
   each space, the initial sequence number is incremented according to
   [2]; however, there is no obvious relationship between the numbering
   in different spaces.

しかし、個々の接続に、写しパケット、およびしたがって、生まれ変わりの初期シーケンス番号における制限は奇妙です。 接続が全くないというそれは、2つの異なった接続に使用される一連番号の間で構文的であるか、または意味的です。 私たちは、各接続(<localhost、localport、remotehost、remoteport>のすなわち各4-tuple)に別々の一連番号スペースを与えることによって、一連番号推測攻撃を防ぐことができます。 各スペースの中では、[2]によると、初期シーケンス番号は増加されます。 しかしながら、異なった空間での付番の間には、どんな明白な関係もありません。

   The obvious way to do this is to maintain state for dead connections,
   and the easiest way to do that is to change the TCP state transition
   diagram so that both ends of all connections go to TIMEWAIT state.
   That would work, but it's inelegant and consumes storage space.
   Instead, we use the current 4 microsecond timer M and set

それをする最も簡単な方法がこれをする当たり前の方法が停止コネクションのために状態を維持することであり、TCP状態遷移ダイヤグラムを変えることであるので、すべての接続の両端はTIMEWAIT状態に行きます。 それが働いているでしょうが、それは、優美でなく、集積スペースを消費します。 代わりに、私たちは、4マイクロセカンドの現在のタイマMを使用して、セットします。

           ISN = M + F(localhost, localport, remotehost, remoteport).

ISNはM+F(localhost、localport、remotehost、remoteport)と等しいです。

Bellovin                     Informational                      [Page 3]

RFC 1948                Sequence Number Attacks                 May 1996

Bellovinの情報[3ページ]のRFC1948一連番号は1996年5月に攻撃されます。

   It is vital that F not be computable from the outside, or an attacker
   could still guess at sequence numbers from the initial sequence
   number used for some other connection.  We therefore suggest that F
   be a cryptographic hash function of the connection-id and some secret
   data.  MD5 [9] is a good choice, since the code is widely available.
   The secret data can either be a true random number [10], or it can be
   the combination of some per-host secret and the boot time of the
   machine.  The boot time is included to ensure that the secret is
   changed on occasion.  Other data, such as the host's IP address and
   name, may be included in the hash as well; this eases administration
   by permitting a network of workstations to share the same secret data
   while still giving them separate sequence number spaces.  Our
   recommendation, in fact, is to use all three of these items: as
   random a number as the hardware can generate, an administratively-
   installed pass phrase, and the machine's IP address.  This allows for
   local choice on how secure the secret is.

Fが外部から計算できないのが、重大であるか、または攻撃者はある他の接続に使用される初期シーケンス番号から一連番号をまだ推測できました。 したがって、私たちは、Fが接続イドといくつかの機密データの暗号のハッシュ関数であると示唆します。 コードが広く利用可能であるので、MD5[9]は良い選択です。 それは、機密データが正しい乱数[10]であるかもしれないか何らかの1ホストあたりの秘密の組み合わせとマシンのブート時間であるかもしれません。 ブート時間は、秘密が時々変えられるのを保証するために含まれています。 ホストのIPアドレスや名前などの他のデータはまた、ハッシュに含まれるかもしれません。 まだ別々の一連番号空間をそれらに与えている間、ワークステーションのネットワークが同じ機密データを共有することを許可することによって、これは管理を緩和します。 私たちの推薦は事実上、これらのすべての3つの項目を使用することです: ハードウェアが生成することができるのと同じくらい無作為の数、行政上インストールされたパス句、およびマシンのIPアドレス。 これは秘密がどれくらい安全であるかに関するローカルの選択を考慮します。

   Note that the secret cannot easily be changed on a live machine.
   Doing so would change the initial sequence numbers used for
   reincarnated connections; to maintain safety, either dead connection
   state must be kept or a quiet time observed for two maximum segment
   lifetimes after such a change.

動いているマシンで容易に秘密を変えることができないことに注意してください。 そうするのは生まれ変わっている接続に使用される初期シーケンス番号を変えるでしょう。 安全を維持するために、停止コネクション状態を維持しなければならない、さもなければ、静かな時間はそのような変化の後に2つの最大のセグメント生涯見ました。

A Common TCP Bug

一般的なTCPバグ

   As mentioned earlier, attackers using sequence number guessing have
   to "gag" the trusted machine first.  While a number of strategies are
   possible, most of the attacks detected thus far rely on an
   implementation bug.

先に述べたように、一連番号推測を使用している攻撃者は最初に、信じられたマシンを「黙らせなければなりません」。 多くの戦略が可能である間、これまでのところ検出された攻撃の大部分は実装バグを当てにします。

   When SYN packets are received for a connection, the receiving system
   creates a new TCB in SYN-RCVD state.  To avoid overconsumption of
   resources, 4.2BSD-derived systems permit only a limited number of
   TCBs in this state per connection.  Once this limit is reached,
   future SYN packets for new connections are discarded; it is assumed
   that the client will retransmit them as needed.

接続のためにSYNパケットを受け取るとき、受電方式はSYN-RCVD状態で新しいTCBを作成します。 リソースの過剰消費を避けるために、4.2BSDによって派生させられたシステムはこの1接続あたりの状態のTCBsの限られた数だけを可能にします。 この限界にいったん達していると、新しい接続のための将来のSYNパケットは捨てられます。 クライアントが必要に応じてそれらを再送すると思われます。

   When a packet is received, the first thing that must be done is a
   search for the TCB for that connection.  If no TCB is found, the
   kernel searches for a "wild card" TCB used by servers to accept
   connections from all clients.  Unfortunately, in many kernels this
   code is invoked for any incoming packets, not just for initial SYN
   packets.  If the SYN-RCVD queue is full for the wildcard TCB, any new
   packets specifying just that host and port number will be discarded,
   even if they aren't SYN packets.

パケットが受け取られているとき、しなければならない最初のことはその接続のためのTCBの検索です。 TCBが全く見つけられないなら、カーネルはサーバによって使用される、すべてのクライアントから接続を受け入れる「ワイルドカード」TCBを捜し求めます。 残念ながら、多くのカーネルでは、このコードは初期のSYNパケットだけのために呼び出されるのではなく、どんな入って来るパケットのためにも呼び出されます。 ワイルドカードTCBに、SYN-RCVD待ち行列が完全であるなら、まさしくそのホストとポートナンバーを指定するどんな新しいパケットも捨てられるでしょう、それらがSYNパケットでなくても。

Bellovin                     Informational                      [Page 4]

RFC 1948                Sequence Number Attacks                 May 1996

Bellovinの情報[4ページ]のRFC1948一連番号は1996年5月に攻撃されます。

   To gag a host, then, the attacker sends a few dozen SYN packets to
   the rlogin port from different port numbers on some non-existent
   machine.  This fills up the SYN-RCVD queue, while the SYN+ACK packets
   go off to the bit bucket.  The attack on the target machine then
   appears to come from the rlogin port on the trusted machine.  The
   replies -- the SYN+ACKs from the target -- will be perceived as
   packets belonging to a full queue, and will be dropped silently.
   This could be avoided if the full queue code checked for the ACK bit,
   which cannot legally be on for legitimate open requests.  If it is
   on, RST should be sent in reply.

次に、ホストを黙らせるために、攻撃者はある実在しないマシンでいくつかのダースのSYNパケットを異なったポートナンバーからrloginポートに送ります。 これはSYN-RCVD待ち行列を満たしますが、SYN+ACKパケットはビット・バケットへ去ります。 そして、ターゲットマシンに対する攻撃は信じられたマシンの上のrloginポートから来るように見えます。 パケットが完全な待ち行列に属して、静かに下げられるのに従って、回答(目標からのSYN+ACKs)は知覚されるでしょう。 完全な待ち行列コードがACKビット(正統の開いている要求に、法的にオンであるはずがない)がないかどうかチェックするなら、これを避けることができるでしょうに。 それがオンであるなら、回答でRSTを送るべきです。

Security Considerations

セキュリティ問題

   Good sequence numbers are not a replacement for cryptographic
   authentication.  At best, they're a palliative measure.

良い一連番号は暗号の認証への交換ではありません。 それらはせいぜい、緩和剤の測定です。

   An eavesdropper who can observe the initial messages for a connection
   can determine its sequence number state, and may still be able to
   launch sequence number guessing attacks by impersonating that
   connection.  However, such an eavesdropper can also hijack existing
   connections [11], so the incremental threat isn't that high.  Still,
   since the offset between a fake connection and a given real
   connection will be more or less constant for the lifetime of the
   secret, it is important to ensure that attackers can never capture
   such packets.  Typical attacks that could disclose them include both
   eavesdropping and the variety of routing attacks discussed in [8].

接続に関して初期のメッセージを観測できる立ち聞きする者は、一連番号状態を決定できて、その接続をまねることによって攻撃を推測しながら、まだ一連番号を始めることができるかもしれません。 しかしながら、また、そのような立ち聞きする者が既存の接続[11]をハイジャックできるので、増加の脅威はそんなに高くはありません。 それでも、にせの接続と与えられた本当の接続の間のオフセットが秘密の生涯多少一定になるので、攻撃者がそのようなパケットを決してキャプチャすることができないのを保証するのは重要です。 それらを明らかにすることができた典型的な攻撃が盗聴と[8]で議論したルーティング攻撃のバラエティーの両方を含んでいます。

   If random numbers are used as the sole source of the secret, they
   MUST be chosen in accordance with the recommendations given in [10].

乱数が秘密の指定企業として使用されるなら、[10]で与えられた推薦に従って、それらを選ばなければなりません。

Acknowledgments

承認

   Matt Blaze and Jim Ellis contributed some crucial ideas to this RFC.
   Frank Kastenholz contributed constructive comments to this memo.

マットBlazeとジム・エリスはいくつかの重要な考えをこのRFCに寄付しました。 フランクKastenholzはこのメモに建設的なコメントを寄付しました。

References

参照

   [1]  R.T. Morris, "A Weakness in the 4.2BSD UNIX TCP/IP Software",
        CSTR 117, 1985, AT&T Bell Laboratories, Murray Hill, NJ.

[1] R.T.モリス、「4.2BSD UNIX TCP/IPソフトウェアの弱点」、CSTR117、1985、AT&Tベル研究所、マリー・ヒル、ニュージャージー。

   [2]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        September 1981.

[2] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。

   [3]  Kohl, J., and C. Neuman, "The Kerberos Network Authentication
        Service (V5)", RFC 1510, September 1993.

[3] コール、J.、およびC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。

   [4]  Atkinson, R., "Security Architecture for the Internet
        Protocol", RFC 1825, August 1995.

[4] アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC1825、1995年8月。

Bellovin                     Informational                      [Page 5]

RFC 1948                Sequence Number Attacks                 May 1996

Bellovinの情報[5ページ]のRFC1948一連番号は1996年5月に攻撃されます。

   [5]  Postel, J., and J. Reynolds, "Telnet Protocol Specification",
        STD 8, RFC 854, May 1983.

[5] STD8、RFC854がそうするポステル、J.とJ.レイノルズ、「telnetプロトコル仕様」1983。

   [6]  Jacobson, V., Braden, R., and L. Zhang, "TCP Extension for
        High-Speed Paths", RFC 1885, October 1990.

1990年10月の[6] ジェーコブソンとV.とブレーデン、R.とL.チャン、「高速経路のためのTCP拡張子」RFC1885。

   [7]  G.R. Wright, W. R. Stevens, "TCP/IP Illustrated, Volume 2",
        1995.  Addison-Wesley.

[7] G.R.ライト、W.R.スティーブンス、「TCP/IPは1995をボリューム2インチ例証しました」。 アディソン-ウエスリー。

   [8]  S. Bellovin, "Security Problems in the TCP/IP Protocol Suite",
        April 1989, Computer Communications Review, vol. 19, no. 2, pp.
        32-48.

[8] S.Bellovin、「TCP/IPプロトコル群の警備上の問題」、1989年4月、コンピュータCommunications Review、vol.19、No.2、ページ 32-48.

   [9]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
        April 1992.

[9] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。

   [10] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
        Recommendations for Security", RFC 1750, December 1994.

1994年12月の[10] イーストレークとD.とクロッカー、S.とJ.シラー、「セキュリティのための偶発性推薦」RFC1750。

   [11] L. Joncheray, "A Simple Active Attack Against TCP, 1995, Proc.
        Fifth Usenix UNIX Security Symposium.

[11]L.Joncheray、「TCPに対する簡単な活発な攻撃、1995、Proc。」 第5Usenix UNIXセキュリティシンポジウム。

Author's Address

作者のアドレス

   Steven M. Bellovin
   AT&T Research
   600 Mountain Avenue
   Murray Hill, NJ  07974

スティーブンのM.Bellovin AT&Tの研究600山のアベニューマレー丘、ニュージャージー 07974

   Phone: (908) 582-5886
   EMail: smb@research.att.com

以下に電話をしてください。 (908) 582-5886 メールしてください: smb@research.att.com

Bellovin                     Informational                      [Page 6]

Bellovin情報です。[6ページ]