アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
隙? (スコア:3, すばらしい洞察)
隙があろうが無かろうが成立するから、DDoSって厄介だねって話じゃなかったんですかね。
なんか最近、こういう事にかこつけて関係のない主張を通そうとするのが多い気がします。
Re:隙? (スコア:1)
>隙があろうが無かろうが成立するから、DDoSって厄介だねって話じゃなかったんですかね。
いえ、隙があればDoSが成立しやすくなります。
UDPで、IPを偽装を許容してしまっている設計であれば、通信仕様に何らかの隙があったといっても確かにいいかもしれません。
それがUDP自身か運営者側の隙かはわか
Re:隙? (スコア:0)
許容しない設計があなたの頭にあるのなら。それはとても画期的なものになります。
是非、お知恵を拝借したいところです。
Re:隙? (スコア:1)
TCPで万事解決じゃないけど、防ぐ手段はUDPよりは多い・・・ってのは、間違ってるかなぁ・・。(SYNFlood とかいろいろあるけど)
もしくは、許容しているアドレスからしか、UDPの処理を受け付けないとか?
私は、DoSなら対応方法があるんじゃいかといったつもりだったんですが、なんか、自分で読んでもなんか変な文書だな・・。
DDoSが難しいというは理解しているつもりです。
元記事か
Re:隙? (スコア:2, 参考になる)
>してしまってるなら、仕様に問題ありの場合もあるよね程度です。
許容していようがいまいが、UDPパケットがマシンの物理インターフェースに届いた時点でDoSは成立するでしょ?各サーバーは、パケットの中身が正しいかどうか確認する為だけでもリソースを使う。要はゴミパケットの処理にもリソースは使われる。ゴミパケットの処理で本来のサービスが出来なくなるとこを狙った攻撃がDoSアタックではないのですか?
IP限定ってどこでやるの?パケットをカーネルが処理するのであれば、言い換えれば、カーネルに届く前にどこ
Re:隙? (スコア:1, 参考になる)
>、FFXIが導入された頃の機材、例えば6500で何らかのACLを設定した
>運用では最高30Mppsしかでません。パケットのヘッダが最小の20バ
>イトだった場合は、たったの48Mbpsで、サーバー群よりも先に6500ス
>イッチが飽和することを意味します。
>*最新製品でもこの10倍の性能しか出ませんので、480Mbpsで飽和
>します。
これってスマートビットで測定してます?Catalyst6513-NBR+Supervisor Engine 2(Native IOS,MSFC2;BGP+EIGRPで運用)の組み合わせでinとoutパケットに対してACLを設定して測定したときには最小パケットサイズでも飽和しませんでしたよ。
これが本当ならDDoSのパケットを転送している途中経路でCisco機器を使用しているプロバイダ側で飽和しませんか?
Re:隙? (スコア:1, 参考になる)
>これってスマートビットで測定してます?
私も例に挙がっているCatalyst6500を触ったときには、1Gbpsまではショートパケットのときにもワイヤレートが出たような記憶があります
(そのときに20オクテットだったかは覚えていません)
元コメントの方は、7200とかと混同されていませんでしょうか?
>これが本当ならDDoSのパケットを転送している途中経路でCisco機器を使用しているプロバイダ側で飽和しませんか?
いまどき、国内上位20社のISPのcoreにそんな安物は無いと信じています
逆に (スコア:0)
>いまどき、国内上位20社のISPのcoreにそんな安物は無いと信じています
ISPの導入機器の性能が良くなっているために
カスタマーまで、綺麗にDoSパケットが届いてしまう
っちゅーのが、最近の傾向かな