許容出来る方のみのアクセスをお願いします。写真への直リンクを張るのはご遠慮下さい。内容に関しては、一切保証致しません。対策もなにも、この内容が事実ならば、「ハァ?」ということ。対応レベル=品質レベルととらえると、こういうのは使えませんね。内部のエンジニアの品質も悪いんでしょう。まともならもっとまともな対応策などの提案が有るはずです。そもそも、サイトがねらわれれば、IPアドレスなんて変えるのは全く意味がありません。DNSからひいて探してくるでしょうし、サイトがねらわれているのであれば、名前を変更しても、ドメイン名を変更しても、見つけてくるでしょう。いたちごっこなのです。実際に出来る対応は事業者側での対応。あとは、利用者側としては、可能であれば上位回線が埋まるような攻撃を受けたときのことを想定して、裏口(物理的に違う網)を用意するということ。いわゆるフレッツや専用線などを使ったVPNや広域イーサーなども該当しますし、よくある構成です(大規模になればなるほど)。floodなど日常で届き、サービス側の回線真っ黒けになることも。攻撃の種類にもよりますが、物理的に分離、インターフェースも分ける(vlanなんか、役に立ちません)というのが一般的。クラウドサービスやVPSなど仮想化向けサービスになった時点で、ネットワークは共通化されていたりすることもある為、網内(バックボーン〜エッジ含む)に入ってしまったら他のも影響うけるから、借りているサーバー以前に周りの巻き沿いなども有るため、事業者としては対応しなければならなくなるでしょう。事業者の立場としては正直面倒でもあるし、対応に迫られると、正直出て行ってほしいというのはあるけど、そうなった時点で事業者がは技術的、コスト的に見捨てたということですね。しますが、対応可能なトラフィックの範囲内であれば、入り口でフィルタなどを行う方法はあるでしょう。いうことは、そこまで多くないです。時間的にも長時間続くことは余りありません。いっても、そうとも限りませんが傾向的に、という話しです。IRCを運用していたときは、長時間続く攻撃が多かったですが...。Webサイトの場合比較的快犯などのことも多く、長時間続くことは珍しいと思います。*3網内からの攻撃トラフィックで帯域が埋まるようなケースは、事業者からすれば管理管轄内なので、不正パケットを出しているユーザのトラフィックの締め出しでも良いでしょう。面倒な事には違いないですけどね。しても、ドメイン変更という事を言い出したGMOクラウドのお客様対応した担当者の低脳な対応には、ちょっとあきれる物が有りますね。floodされている場合は、サーバが生きているか死んでいるかは関係有りません。ppsが多い場合、幾らサーバの性能を上げても、CPUやメモリの数を増やしても、NICが先に当たります(10Gだったらずいぶん緩和されますけど)。カーネルが一旦受けるわけで、そこのコストはバカになりませんから、同一ホスト上に有るvmはパフォーマンス面で影響を受けるでしょう。テーブルが埋まる恐れもあります。話しを戻して、攻撃を受けたことが不正アクセス若しくはウィルスの感染と決めているのも明らかにおかしい話しです。明らかに、連携が出来ていない、フロントのお客様対応の判断が非常に残念で、適切にエスカレーションをされているようには思えない感じが残念でした。いうことで、Twitterでも話題になっていますが、そのため、GMOクラウドにおいては「DDoS攻撃は、ドメイン名を変更すれば解決できる可能性が高い」といった対策の提案があったりしました。宛のドメインにDDoSがきたら、ドメイン名の変更をして、解決するようです。これが、共有サーバで、サブドメインを払い出しているケースはどうするんでしょうか。この理屈なら、全部変更なんでしょうね...。ことで、みんな、F5アタックしちゃえば、変更するんですかね...さらに、記事を読んでいると...GMO「こちらの第三者というのは意図的でなくとも該当します。DDoSを誰かに行わせているという解釈になります。某社のどこぞの回答みたいで楽しい。青山さん最近ふと思うのは、トップが元エンジニアで、且つ有る程度のプライド、ポリシーを持っていて曲げれないところは曲げれないという思想を持っていないと、今回みたいに、現場も含めていい加減な事に感じになってしまうような気がします。某社ではモロ当てはまりましたし。ここは、Transitの上位と相談、対応できる関係を築いておくこと、Community等を使って、トラフィックの制御、広告の範囲を制限するなどをして、完全ではないものの、被害を最小限にすることも出来ますね。地道な作業ですが正直私はやりたくないです...w。ここは、事業者としての力量でしょう。いくつか完全ではないけど、出来る対応方法はありますね。いうか、そんな作業に張り付きたくねぇから、出て行ってくれと言いたいのもわかるけどねw。即座に判断出来る人は熟練者ぐらいでしょうか。私が見ている環境と違うケースも十分にありうるけど、一つの意見として。Panicしてしまい、起動しないいことが判明したので、再構築していた。理由は、完全なオペミス。したまま放置し再起動せず半年以上。その後、パッケージをインストールしたりしていたら、どうやら環境が壊れてしまい、長期間再起動していなかったこともあり、自動的にfsckが走るようになっていたり、initrdが更新されていないなど、いろんなところで不具合が出ていた。実はDebian5の頃からアップデートをして使っていたんだよなぁと。長い間お世話になった旧環境。幸いにも、移行前のvmは電源を落としていないので、まだ、起動した状態なので、データはそこからrsyncすればよいので、比較的楽。