「ニコニコ動画、DDoS攻撃をうけサービス停止中」記事へのコメント

SYN floodって台数わかるの?

[Anonymous Coward]

SYN flood攻撃って、普通送信元のアドレスを偽装するのでは?

詳しい人解説希望。

Re:SYN floodって台数わかるの?

[Mizar (27267)]

まともなISPや組織であれば、自らのネットワークから容易にIP spoofing（送信元IPアドレス詐称）を行えないよう対策を取っている筈です。そういったネットワークの中に攻撃者が居る限りにおいては、IPアドレスの数をカウントする事は有効でしょう。

＃というか、ちゃんと対策してますよね？ね？お願いしますよ？

Re:SYN floodって台数わかるの?

[barrel (25979)]

unicast RPFをかけてるISPってそんなに多いですか？
ある意味マナーでしょうが、義務ではないというか
どうせ簡単には気づかれないしいいや、みたいなところもありそうな気がします。
あるいは非対称ルーティングしていてどうしても無理とか。

Re:SYN floodって台数わかるの?

[Mizar (27267)]

ISPが1ユーザ毎に送信元の偽装を防ぐ対策を取れない場合があると譲ったとしても、例えばAS（自律システム）レベルで、自己の組織に割り当てられていないはずのIPアドレスを送信元として騙るパケットを内部から他のASに対して駄々漏れに流しているようであれば、ASの信頼問題に関わりそうですがどうなんでしょう？

そのようなザル状態のASが仮にトランジットASであれば、そこから来るパケットがそのAS内部から送信元を騙って出てきたものなのか、他のASから中継されてきたものなのか、送信元アドレスを見ただけでは判断が難しくなるでしょう。そうでなくとも、自分の所で起きた醜態をむざむざ他の組織に晒すことになるわけで。

＃同様の事は他のネットワーク単位や事象についても言えるでしょうが。

Re:SYN floodって台数わかるの?

[Anonymous Coward]

ISPにぶら下がったユーザーノードが、IPsec等の暗号トンネル張ってて、
そのトンネルを抜けたパケットをさらにルーティングする場合はどうしましょうか。
ISPは全ての暗号を解析して、このパケットは、あの暗号トンネルを抜けてきたもので、
正統なトランジットだから通してもOK、このパケットはどこから来たか分からず送信元は、
他ISPのアドレスで、なんとなく偽装っぽいからNG、とすべきでしょうか。

結論から言うと、
＞自己の組織に割り当てられていないはずのIPアドレスを送信元として騙るパケットを内部から他のASに対して駄々漏れに流している
のを防ぐのは、少なくともユーザーノード間で張られた暗号トンネルをリアルタイムで解析できない限り技術的に不可能です。
できたとして、約款にもよりますが、法律論争に発展する可能性は高いです。

Re:SYN floodって台数わかるの?

[Mizar (27267)]

これはIPsecのトンネルモード通信での話でしょうか？

IPsecで暗号化された部分の内容は、IPsecゲートウェイ自身、もしくはその内容がルーティングされる先の網で責任を負う話ではあるでしょう。しかしゲートウェイとゲートウェイの間の網にとって責任を負うべきはそのパケットのESP（暗号化された部分）の前についてるIPヘッダ（これは暗号化されていません。トンネルモードのIPsecの通信であれば送信元・宛先のIPアドレスはそれぞれのゲートウェイのIPアドレスになります。）が改竄されてない事を確認する事であって、所詮はIPパケットのセグメント・データであるESPは今回関係ない話ですね。

Re:SYN floodって台数わかるの?

[Anonymous Coward]

一方が望めばいつでもトンネルが張れるとか思ってないよな？
チェックしなくていいものまでチェックしたい理由がわかりません。

  ＃トンネリングを抜けたあと、さらにその先へ通信したければ
  ＃トンネリング先のアドレスでなけりゃ当然ダメです