アカウント名:
パスワード:
で、普通は切れたら張り直しておしまいなわけですが、BGPの場合、
BGP peerで使ってるアドレスをソースにしたパケットが外から入り込まないようにフィルタすればいいような気もするけど、IXだったりmultihopだったりすると面倒な場面もあるかも。
As a general rule, all protocols where a TCP connection stays established for longer than one minute should be considered exposed.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
これだけじゃわからん (スコア:0)
概要 (スコア:5, 参考になる)
- TCPコネクションはRSTフラグ(ないし，特定の条件下ではSYNフラグ)を立てたパケットを送ると切れる．
- しかし，TCPのシーケンス番号(32bit)が正しくないパケットは不正なものとして受け付けてもらえない．
- 従って，従来は，ターゲットとするコネクションのsource/destinationのIPアドレス/TCPポート番号を知った上で，適当なシーケンス番号をつけたパケットを送っても，それが受け付けられる確率は1/(2**32)だと考えられていた．
- しかし，TCPには"window"という概念があるため(詳細はTCP/IPの解説書を参照)，偽造したパケットのシーケンス番号がこのwindowに入れば受け付けられる．
- 従って，偽造パケットによりTCPコネクションを切られるDoS攻撃が成功する確率は1/(2**32)よりずっと大きい(実施可能なレベルになる)．
ここからは想像ですが，長期間つなぎっぱなしなTCPコネクションだとwindow sizeが大きく，またそのwindowが32bit空間をずりずりと移動していくため，攻撃が成功しやすい，ということなのかな? TCP windowのサイズって最大どのくらいでしたっけ?あとは"Slipping In The Window: TCP Reset Attacks"という原論文(名前しか出てない)を読んでみるしかないのかな．
Re:概要 (スコア:3, 参考になる)
シーケンス番号が変な(windowに入ってない)セグメントが来る、というのは RFC792(STD7) で言うところの Half-Open Connection の場合によくあることだと思います。
ただ、普通シーケンスがおかしいセグメントに対しては、次のシーケンスを示すACKを返して終わりですし、それだけでは乗っ取れないわけですが、RST は window 内に入ってればいいということで、目的が達成できる確率が高まるわけですね。
で、普通は切れたら張り直しておしまいなわけですが、BGPの場合、
- 基本的にずっと張りっ放し
- 切れたら一旦経路が消える(flapping)
- flapするとルータのCPUを余計に使う
- flapすると不安定な経路としてペナルティをくらう
- ある程度ペナルティが溜ると、たとえupしてても長時間(数十分とか)経路を受け付けてもらえなくなる(dampening)
という、切れずに張りっ放しを前提とした運用をしているので、影響甚大、と。BGP peerで使ってるアドレスをソースにしたパケットが外から入り込まないようにフィルタすればいいような気もするけど、IXだったりmultihopだったりすると面倒な場面もあるかも。
Re:概要 (スコア:2, 参考になる)
Re:概要 (スコア:1)
=^..^=
Enjoy Computing, Skiing, as much as Horse Racing.
Re:概要 (スコア:1)
ちなみにJuniperのアナウンスは上記pageでは(none yet, will be updated when available)となっているようですが、Releaseが出た [juniper.net]ようですので参考まで。
KyaTanaka
ＭＤ５を使え (スコア:0)
Re:概要 (スコア:2)
> * 従って，偽造パケットによりTCPコネクションを切られるDoS攻撃が成功する確率は1/(2**32)よりずっと大きい(実施可能なレベルになる)．
なるほど。そうすると「攻撃の成功しやすさ」、は TCP window size による、ってことになりそうですね。
最近はブロードバンド接続にあわせて windows size を大きくするってのが流行ってますからその分危険性が増すってことでいいのかな。
ただ、この window size ってもとは 16k とか 32k のものが 256k とかそのぐらいになるだけだから極めて危険、ってわけでもなさげって理解でいいんでしょうか。
Re:概要 (スコア:3, 参考になる)
ということで確率としては最悪1/(2**16)ということになります
40億分の1から6万分の1になるというのは確かに恐い話ではありますが結局，数撃ちゃ当たる攻撃しかないし，しかも成功したかどうかが分からない攻撃というのは中々大変ではないかと思います
# もちろん途中でパケットを拾われていない，という条件で
Re:概要 (スコア:0)
てことは、６万回くらい攻撃すれば１回は成功するわけですね？
スクリプトを組んだとして、2**16回の攻撃を行うにはどのくらいのコストがかかるもんなのか。
この攻撃は、コストに見合った成果を上げられるものなのか。
詳しい人の解説きぼー。
Re:概要 (スコア:0)
古い規格ではその通りなのですが、最近ではTCP Extensions for High Performance (RFC1323 [ietf.org])があって、これで1GBくらいまでいけそうです。
Re:概要 (スコア:1)
でも，windowサイズはパケットを受ける側に決定権があるのでそんなに問題にはならないのかなと思います
Re:概要 (スコア:0)
>最近ではTCP Extensions for High Performance (RFC1323[ietf.org])があって、
>これで1GBくらいまでいけそうです。
これは、16bit空間を使って大きいWinサイズを表現する手法なので
この脆弱性ネタとは関係ないような。。。（結局16bit）
Re:概要 (スコア:3, 興味深い)
> >これで1GBくらいまでいけそうです。
> これは、16bit空間を使って大きいWinサイズを表現する手法なので
> この脆弱性ネタとは関係ないような。。。（結局16bit）
RFC1323によって64KBより大きなwindow sizeを指定できるようになった。
すなわちwindow sizeはもはや64KBに制限されないということです。
このストーリーの脆弱性はwindow sizeが大きいほどリスクが大きい
ので、関係します。
# 実際、window size 1GBなら4回のトライで確実に切れるわけだ
Slipping In The Window: TCP Reset Attacks (スコア:1)
# WORD読める環境つくらなきゃ
@@@@