アカウント名:
パスワード:
ただし、MD5 Signatureはend-to-endで鍵が共有できていることを仮定しています。もしアプリケーションに依存せず、すべてのTCP接続でこれをやろうとしたら、IKEか何かを動かさないと使いものにならないでしょうね。
3-way handshakeの間にend-to-endで鍵を共有することができれば、TCPだけでheaderの認証ができないでしょうか。例えばDiffie-Hellmanのexponentialを最初のSYNおよびこれに続くSYN + ACKのTCP optionに載せて、それをMD5 Signatureの鍵にしてしまうなど。
各々のendが事前に何らかの知識を(第三者を経由する場合を含めて)共有することなしにman-in-the-middleを防ぐというのは、本質的に不可能ではないでしょうか。TCPは通信相手に対してゼロ知識を仮定しなければならないので、相手を認証する手立ては全くありませんよね。高々、攻撃にさらされる時間を短縮するぐらいしかできないと思います。
ところで、もしこの弱点を狙い、TCPのendではない計算機が攻撃をかけようとすると、IP packetのsource addressをspoofしなければなりません。となると、攻撃元のゲートウェイにおいてsource addressのspoofを弾くようにすれば、TCP接続の経路になり得ないネットワークからの攻撃は防げるのではないでしょうか。もちろん、経路上にあるルータからは依然として攻撃できてしまいますが...
あれ... TCP接続経路上にない計算機がsource addressのsnoopなしに攻撃することって本当に可能ですか? TCP接続って、(source address, source port, destination address, destination port)の4つ組で定義されると思ったんですけど。4つ組の各々に(例えばBSDの場合)PCBが割り当てられるので、第三の計算機から攻撃する場合はspoofしないとPCB lookupが失敗すると見たんですが...
たて続けですみませんが、私が考えてた通り、一般に攻撃計算機は(portだけでなく)source addressをspoofしないとダメなようですよ。NISCC advisoryのsummaryには以下のように書かれています(もしかして、satsukiさんもspoofをsnoopと読み間違えてました?)。
The fact that TCP sessions can be reset by sending suitable RST and SYN packets is a design feature of TCP according to RFC 793, but a reset attack is only possible at all because the source IP address and TCP port can be forged or “spoofed”.
訂正: s/snoop/spoof/
FreeBSDのin_pcblookup_hash()で調べてみましたが、最終的には先の4つ組をすべて調べてますね。pseudocodeはこんな感じです。
in_pcblookup_hash( faddr /* 他計算機アドレス */, fport /* 他計算機ポート */, laddr /* 自計算機アドレス */, lport /* 自計算機ポート */) { hash = PCBHASH(faddr, fport, lport); foreach inp in hash { if (inp->faddr == faddr && inp->fport == fport && inp->laddr == laddr && inp->lport == lport) return (inp); } return (NULL); }
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
SYN flood (スコア:1)
Re:SYN flood (スコア:3, 参考になる)
最も影響をうけるBGPについてはTCP MD5 Signature Option(RFC2385)などの回避作も推奨されているようです.
3-way handshakeで鍵を共有しては? (スコア:2, 興味深い)
ただし、MD5 Signatureはend-to-endで鍵が共有できていることを仮定しています。もしアプリケーションに依存せず、すべてのTCP接続でこれをやろうとしたら、IKEか何かを動かさないと使いものにならないでしょうね。
3-way handshakeの間にend-to-endで鍵を共有することができれば、TCPだけでheaderの認証ができないでしょうか。例えばDiffie-Hellmanのexponentialを最初のSYNおよびこれに続くSYN + ACKのTCP optionに載せて、それをMD5 Signatureの鍵にしてしまうなど。
Re:3-way handshakeで鍵を共有しては? (スコア:1)
Re:3-way handshakeで鍵を共有しては? (スコア:1)
各々のendが事前に何らかの知識を(第三者を経由する場合を含めて)共有することなしにman-in-the-middleを防ぐというのは、本質的に不可能ではないでしょうか。TCPは通信相手に対してゼロ知識を仮定しなければならないので、相手を認証する手立ては全くありませんよね。高々、攻撃にさらされる時間を短縮するぐらいしかできないと思います。
ところで、もしこの弱点を狙い、TCPのendではない計算機が攻撃をかけようとすると、IP packetのsource addressをspoofしなければなりません。となると、攻撃元のゲートウェイにおいてsource addressのspoofを弾くようにすれば、TCP接続の経路になり得ないネットワークからの攻撃は防げるのではないでしょうか。もちろん、経路上にあるルータからは依然として攻撃できてしまいますが...
Re:3-way handshakeで鍵を共有しては? (スコア:1)
知識共有はあまりにもコストが高く付き過ぎるので,中間者攻撃が可能なら可能でかまわないから,軽くて安いちょっとした防御ができたらいいなぁと.それだけです
そこまで心配する危険性でもないのかもしれませんが
ところで,この件ではsnoopはないという前提だと思います.アドレスも推測するだけだと思います.
snoopできれば,window sizeなど関係なくピンポイントでシーケンス番号を決められるので簡単にコネクションを切れます.
今回のは,経路上にいないホストからなんとなくのあてずっぽうで撃った時に,思っていたより的が大きくて当たりやすいんじゃないかしら,ということです
Re:3-way handshakeで鍵を共有しては? (スコア:1)
あれ... TCP接続経路上にない計算機がsource addressのsnoopなしに攻撃することって本当に可能ですか? TCP接続って、(source address, source port, destination address, destination port)の4つ組で定義されると思ったんですけど。4つ組の各々に(例えばBSDの場合)PCBが割り当てられるので、第三の計算機から攻撃する場合はspoofしないとPCB lookupが失敗すると見たんですが...
Re:3-way handshakeで鍵を共有しては? (スコア:1)
たて続けですみませんが、私が考えてた通り、一般に攻撃計算機は(portだけでなく)source addressをspoofしないとダメなようですよ。NISCC advisoryのsummaryには以下のように書かれています(もしかして、satsukiさんもspoofをsnoopと読み間違えてました?)。
Re:3-way handshakeで鍵を共有しては? (スコア:1)
訂正: s/snoop/spoof/
FreeBSDのin_pcblookup_hash()で調べてみましたが、最終的には先の4つ組をすべて調べてますね。pseudocodeはこんな感じです。
Re:3-way handshakeで鍵を共有しては? (スコア:1)
ごめんなさい
自組織だけでなく (スコア:1)
も同じ回避策を適用する必要がある...という理解でいいのでしょうか?