アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
隙? (スコア:3, すばらしい洞察)
隙があろうが無かろうが成立するから、DDoSって厄介だねって話じゃなかったんですかね。
なんか最近、こういう事にかこつけて関係のない主張を通そうとするのが多い気がします。
Re:隙? (スコア:1)
>隙があろうが無かろうが成立するから、DDoSって厄介だねって話じゃなかったんですかね。
いえ、隙があればDoSが成立しやすくなります。
UDPで、IPを偽装を許容してしまっている設計であれば、通信仕様に何らかの隙があったといっても確かにいいかもしれません。
それがUDP自身か運営者側の隙かはわかりませんが。
DDoSに限定すればおっしゃってるとおりですが、想像するに、今回のはそんなにクライアント多いとはおもえないんですよね。
ウィルスでクライアントに潜伏して・・ってあたりまで手順踏んでIP偽装して・・ってそこまで面倒な手順を踏むとはとてもおもえないんですよねぇ・・。
Re:隙? (スコア:0)
許容しない設計があなたの頭にあるのなら。それはとても画期的なものになります。
是非、お知恵を拝借したいところです。
Re:隙? (スコア:1)
TCPで万事解決じゃないけど、防ぐ手段はUDPよりは多い・・・ってのは、間違ってるかなぁ・・。(SYNFlood とかいろいろあるけど)
もしくは、許容しているアドレスからしか、UDPの処理を受け付けないとか?
私は、DoSなら対応方法があるんじゃいかといったつもりだったんですが、なんか、自分で読んでもなんか変な文書だな・・。
DDoSが難しいというは理解しているつもりです。
元記事からは、DDoSなのか、DoSなのかは判別つかなかったので、なんともいえませんが。
高い負荷を起こす動作を、IPを限定せずに連続して行わせるのを許容
してしまってるなら、仕様に問題ありの場合もあるよね程度です。
ま、こういうのは、起こってしまったことうんぬんいうよりは、これからどうするか考えるほうが建設的なんですけどね。
Re:隙? (スコア:2, 参考になる)
>してしまってるなら、仕様に問題ありの場合もあるよね程度です。
許容していようがいまいが、UDPパケットがマシンの物理インターフェースに届いた時点でDoSは成立するでしょ?各サーバーは、パケットの中身が正しいかどうか確認する為だけでもリソースを使う。要はゴミパケットの処理にもリソースは使われる。ゴミパケットの処理で本来のサービスが出来なくなるとこを狙った攻撃がDoSアタックではないのですか?
IP限定ってどこでやるの?パケットをカーネルが処理するのであれば、言い換えれば、カーネルに届く前にどこかでハードウェア処理でもできなければ、そのパケットを選別するのにもマシンリソースが必要ってことを理解していますか?
TCP-SYNFloodでも同様。
>もしくは、許容しているアドレスからしか、UDPの処理を受け付けないとか?
イントラネットサーバーですか?
そんなネットワークゲーム楽しいですか?
まじめにやるとしても、どう許容しますか?そのパケットの選別はどの機材が行うのですか?
>私は、DoSなら対応方法があるんじゃいかといったつもりだったんですが、なんか、自分で読んでもなんか変な文書だな・・。
>DDoSが難しいというは理解しているつもりです。
攻撃の物理的量以外なにが違うんでしょうか?
定義がわかりません。どうしてDoSなら防げそうなのか。
間によけいな機材をかませたくない上に、基本的にポートを閉じることが不可能であるならば、どういうアプローチが考えられるのでしょうか?
防ぐためにはパケットの中身が正常かどうかをマシンの物理インターフェースの届く前にはじくしか方法は無い。ギガビットを超えるインターフェースで接続されている環境で、ポートを閉じず、レイテンシーを悪化させずに解決する方法がありそうなんでしょうか?
さらに言えば、FFIXで大量に使用されているCISCOの機材はショートパケットに弱く、FFXIが導入された頃の機材、例えば6500で何らかのACLを設定した運用では最高30Mppsしかでません。パケットのヘッダが最小の20バイトだった場合は、たったの48Mbpsで、サーバー群よりも先に6500スイッチが飽和することを意味します。
*最新製品でもこの10倍の性能しか出ませんので、480Mbpsで飽和します。
ということは、CISCOの機材が飽和するだけの細切れパケットを投げつけられた場合は、パケットの中身、宛先に関わらずDoSが成立するということを意味します。
CISCOを狙うのであればワーム型の自動拡散攻撃ツールなんか使用しなくても日本全国の光接続ユーザーが100人もいれば成立しますよね?
浅知恵で発言するなとは言いたくありませんが、自分の意見が正しいと思うならちゃんと説明しましょうよ。
正論に対して根拠も経験も無い感覚だけで反論しているようにしか見えないのです。だから突っ込まれているんですよ。
Re:隙? (スコア:1)
浅知恵でした。そして解説ありがとうございます。
私がDoSとDDoSを分けていたのは、アプリケーションレイヤーで意識をしていました。
ゆえに、DoSならば、アプリケーションレイヤで対応できる場合があるんじゃないかといいたいだけでした。
物理インターフェースで、飽和を起こす・・・(まぁよく読めば今回はそれらしいということがわかるわけですが)というのを、認識してなかったのに問題があったのだと思います。たしかにそのレベルのレイヤで飽和されると、かなり難しいですね。
>CISCOを狙うのであればワーム型の自動拡散攻撃ツールなんか使用しなくても日本全国の光接続ユーザーが100人もいれば成立しますよね?
この人数が攻撃者として多いのか少ないのかは、わかりませんが、比較的少人数で成立するものなのですね。
>防ぐためにはパケットの中身が正常かどうかをマシンの物理インターフェースの届く前にはじくしか方法は無い。ギガビットを超えるインターフェースで接続されている環境で、ポートを閉じず、レイテンシーを悪化させずに解決する方法がありそうなんでしょうか?
つまりこの部分を理解してなかった自分に問題があるようです。
お騒がせしました。
ネットゲームは高速化処理とかその他で、複雑な管理をしている分、比較的単純なHTTPより対応難しそうな話ですなぁ・・。
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パケットが届いてしまう
っちゅーのが、最近の傾向かな
Re:隙? (スコア:0)
ゲーム用につけられたヘッダというなら納得ですが。
次はショートパケットで攻撃しろと煽っているようにも読めちゃいますが、
こういうこと
Re:隙? (スコア:0)
30Mppsでているのであれば、64byteパケットでDoSが来たとしても、
30,000,000 * 64 * 8 = 15,360,000,000(15Gbps強)
でギガのインターフェースを収容するルータとしては十分な気がしますが…
Re:隙? (スコア:0)
Re:隙? (スコア:0)
私がやっているMMOは、ログインサーバ・コミュニケーションサーバ・ゲームサーバxNという構成です。
ログインサーバ以外は認証されたユーザー以外はアクセスできなくても問題がありません。
ゲームサーバーでのログイン時にクライアントのIPアドレスがサーバ側で把握できるの為、利用者として認証されたIPアドレス以外はサーバへ到達させる手前で捨てるように動的に管理するってのは無し