もしも運用しているサーバにDDoS攻撃をされて、大量のトラフィックを理由にホスティング業者から、そのサーバの利用停止を唐突に宣告されたらどうしますか? なにか対策を考えていますか?
by woodleywonderworks. CC BY 2.0
「ファイアウォールでそういった攻撃を防いでいるから大丈夫」「まさか契約上そんな一方的なことができるはずない」と思うかもしれません。私もそのような認識でした。しかし、実際にDDoS攻撃を受けてみると業者の対応は次のようでした。
- ホスティング業者は味方をしてくれない
- ホスティング業者は技術的に的はずれな対策を講じる
- ホスティング業者は利用規約を拡大解釈し、サービス停止を迫ってくる
この3点を信じられない方のために、「付録:DDoS攻撃を受けた時のGMOクラウドPublicと私のやりとり」をこの記事の最後に書いたので、現実のホスティング業者の対応が実際どんなものだったかご覧いただければ分かるかと思います。
確かに、GMOクラウドPublicの対応は思ったよりひどいものでしたが、この記事は同社を批判するものではなく、ホスティング業者が突然サービスを停止することがゼロじゃない以上、使う側も対策を考えておく必要があり、そのきっかけとなるようにこの記事を公開しました。
問題: ホスティング業者は一方的にサービス提供を停止する
by Tomaž Štolfa. CC BY-NC 2.0
レンタルサーバの構造的な問題は ホスティング業者が一方的にサービス提供を停止することがある ということだと思います。停止の理由はDDoS攻撃に限らず様々でしょう。ハリケーンのような天災もあれば、ロンチしたての頃のさくらのクラウドの事例のようにストレージに欠陥もあることでしょう。こんなにあった！クラウド大規模障害まとめ - NAVER まとめを見ると分かりますが、大規模障害も決して珍しくありません。
業者によって対応のクオリティもさまざまでしょうが、最悪なケースではGMOクラウドPublicのように、味方してくれない・技術的に的はずれな対策を講じる・利用規約を拡大解釈しサービス停止を迫るという状況に陥ることもあります。
ホスティング業者は味方をしてくれない
ご利用中のホスティング業者によっては、DDoS攻撃を受けたときに味方になってくれないかもしれません。サーバを借りている顧客も、サーバを貸している業者もともにDDoSの被害者であるのにも関わらずです。サービス全体の安定性を優先して、あなた個人のサーバは切り捨てられても仕方ないという判断が下る場合もあるでしょう。
ホスティング業者は技術的に的はずれな対策を講じる
ホスティング業者の担当者が必ずしも、DDoS攻撃の手法やIP/TCPの仕組みに詳しいとは限りません。そのため、GMOクラウドにおいては「DDoS攻撃は、ドメイン名を変更すれば解決できる可能性が高い」といった対策の提案があったりしました。
ホスティング業者は利用規約を拡大解釈しサービス停止を迫る
ホスティング業者の中には、DDoS攻撃を受けた時に該当サーバを一方的に停止する業者があります。もちろん、同意した利用規約に準じてとられる措置なら理解できるでしょう。しかし、停止についての規約上の根拠を聞いても即答できず回答までに何十分もかかったり、該当する条項がころころ変わったり、挙句の果てには拡大解釈してとにかくサービス停止に持ち込もうとする業者もあります。
「業者を追及する方法」ではなく「素早く別の業者に移行できる方法」を持とう!
この記事を読んでいて誤解してほしくないのは、あるホスティング業者の対応がひどいからといって、その業者を追及することに躍起になることです。業者を責めても、サービスはすぐには復旧しません。私たちユーザがすべきことは、例え業者がある日突然滅んでも、サービスを続行できる仕組みづくりや「素早く別の業者に移行できる方法」の準備だと思います。では、どのような準備が行えるのか考えてみましょう。
素早く別のホスティングサービスに移行するための8つの対策
by Uli Harder. CC BY-NC-SA 2.0
1. ポータビリティの高い環境を構築しておく
chefなどのプロビジョニングツールでOSの環境構築を自動化するとともに、dockerでOSまるごとの環境をビルドしておくことで、ポータビリティの高い環境にしておくことができます。
継続的インテグレーションでアプリケーションのビルドを行っている方も多いかと思いますが、OSを含めてビルドしてOSをデプロイするような運用にしておくと、ホスティングサービスを切り替えるときにも普段の運用が通用するので、備えておくといいでしょう。
また、アプリケーションの設計においては、抽象に依存する形にできればポータビリティの高い環境になります。例えば、IPアドレスに依存しないような実装が必要です。IPアドレスはハードコーディングせずに設定に持たせるようにすれば、あまり手間をかけずにIPアドレスに依存の少ない実装になります。IPアドレスではなくホスト名に依存するなども検討するといいかもしれません。他にも、ホスティングサービスが提供するインフラサービスに利用する場合も、直接実装が依存するようなことを避け、ポリモーフィックにしOpen Closed Principleに従うような設計になっていると、移行もスムーズになるかもしれません。
2. データのオフサイトバックアップを取る
サーバを失ったらデータも失うことになります。そうならないように、データのバックアップは普段から自動化しておくべきです。バックアップは他のホスティングサービスや、自社のローカルにダウンロードしてくるなど、地理的に分散するオフサイトバックアップにすべきです。同じホスティングサービス内のバックアップでは、そのサービス全体が提供不能になったら、取り出すことができません。
MySQLであれば定期的にmysqldumpを行い、それをインターネット経由で他の場所に送ることはそう難しくありません。RDBMSのようなState Sourcingのストレージであればリモートレプリケーションという選択肢もありますし、EventStoreのようなEvent Sourcingのストレージであれば、イベントが発生した瞬間に他のホスティングにイベントを送るということをすれば、最新のデータがバックアップできている可能性がぐんと高まります。
3. 事前にDDoSを受けた時の対応を聞いておく
DDoS攻撃を受けた時の対応は、ホスティングサービスによってさまざまです。攻撃時の対応をイメージするためにも、利用しているホスティングサービスがどのような対応をするのか事前に確認しておくことも大切です。
例えば、AWSのようにDDoSへの対策がすでにされていることを公表している場合もありますし、PhotonVPSのようにDDoSへの対応を有償オプションとして提供している場合もあります。GMOクラウドPublicのように、DDoS対策へのオプションはなくネットワークから切り離された後に「IPアドレスを変える」「ドメイン名を変更する」といった対応を要求される場合もあります。「もしDDoS攻撃を受けたらどのような対応になるか?」を一度問い合わせてみるといいでしょう。
4. 利用規約を準備しておく
ホスティングサービスを切り替える間、ユーザにサービスを提供できない状態になることが考えられます。例え自分に落ち度がなかったとしても、ユーザにとってはそれは障害と認識されるかもしれません。全てのユーザが理解のある人であればいいですが、中には障害に対してクレームをつける人もいるでしょう。そうなった時に、ユーザに説明することになりますが、軸となる利用規約を準備しておけば公正な対応ができるようになります。
5. ユーザとの関係性を築いておく
それでも利用規約は最後の手段としてとっておくべきです。契約でクレームをかわすこともできるでしょうが、それよりもユーザとの関係性を築いておくべきでしょう。
サーバがダウンしたとしても、ユーザとコミュニケーションが取れるチャネルを作っておくのも1つの関係性の構築です。それはTwitterやFacebookのようなソーシャルメディアも考えられますし、ブログやメールでもいいでしょう。ただし、ブログ用のサーバは、アプリケーションのサーバとは別のホスティングサービスにしておくべきできです。これは、異なるホスティングサービスが同時にダウンすることは考えにくいからです。
チャネル作りはいわば物理的な関係性ですが、心理的な関係性を築くことは大きな障害のときにとてもプラスに働きます。Bufferはサービスの売上をリアルタイムで公開するほど、透明性の高いサービスを運営することで、ユーザとの関係性を上手く築いているサービスです。そのBufferのサーバがクラックされ障害に陥ったとき、ユーザはBufferにクレームをつけるどころか応援のメッセージで溢れました。そのメッセージは今でもBufferのブログで見ることができます。
6. ホスティングサービスをまたいで分散配置しておく
もし可能であれば、ホスティングサービスをまたいでサーバを分散配置しておくことも1つの選択肢になるかと思います。なぜなら、1つのホスティングサービスにだけ依存するよりも、複数のホスティングサービスにまたがっていたほうが、いざというときに全体障害になりにくいからです。ホスティングサービス間はVPNでつないで、通信しあうような構成にしたり、サイトやサービス単位で分割する方法もあるかと思います。
7. 避難先のアカウントを取っておく
いざホスティング業者を変えようとしたとき、意外にも最初の関門はアカウントを持っていないことです。ホスティングサービスによっては、アカウント登録後すぐに使えるところもありますが、審査が必要だったり承認を経ないとアカウントがアクティベートされないところもあります。
避難先候補のホスティングサービスをリストアップしたら、そこがアカウントを簡単に作れるかどうか確認しておき、承認に時間がかかるようなところであれば予めアカウントだけ作っておくということも些細ではありますが重要な工夫です。
8. 裏口を用意しておく
今回DDoS攻撃(SYN flood攻撃)を受けて最も困ったのは、攻撃を受けている間、ポートが攻撃の通信でうめつくされてしまいSSHが繋がらないということです。対象サーバにログインしてメンテナンスしようにもできないわけです。そうならないように、サーバに裏口を用意しておくことが大切だと思いました。通常の通信はロードバランサを経由するようにしておき、攻撃が起きたらロードバランサからサーバを切り離せるようにしておき、またメンテナンスのためにログインできるようにVPN経由でSSHにログインできるようにしておくと良いかもしれません。
上位回線が攻撃で埋め尽くされると、裏口からの接続も難しくなる場合があります。このような時のために、物理的に別の回線を用意しておくという方法もあります。
まとめ
実際にDDoS攻撃を受けたことによりホスティング業者にサーバが切り離された出来事から、素早く別の業者に移行するための対策を8つ考えてみました。お使いのサーバはDDoS攻撃を受けた時にどのような対応をしてくれそうですか? 一度確認してみてください。その上で、自分たちでできる対策もしておくといいでしょう。備えあれば憂いなしです。
付録:DDoS攻撃を受けた時のGMOクラウドPublicと私のやりとり
ざっくりとしたやりとりの内容
この付録はかなり文量があるので、どんなやりとりがあったかざっくり知りたい方のために、簡単にまとめました。もっと詳しいやりとりを知りたい方は、次のセクションの「やりとりの内容」をご覧ください。
- DDoS攻撃を受ける
- ネットワークから私のサーバが隔離され、電話がかかってくる
- GMO「DDoS攻撃を受けたからサーバを隔離しておいた。」
- GMO「IPアドレスが狙われている可能性がある。IPアドレスを再割当てしろ」
- 私「変えました」
- GMO「また攻撃された。ドメインを変更しろ」
- 私「ドメイン変更は対策として意味ないと思います…」
- GMO「ドメインを変更しないとサービスは提供しない。それが我が社のルールだ。」
- 私「ルールと言えば、何を根拠に隔離したのですか?」
- GMO「事前にメールで通告した。サービス提供できなくなるのは仕方ない。」
- 私「契約上の根拠はあるんですか?」
- GMO「お客さまの義務の事項に違反している。不正アクセスだ」
- 私「DDoSは不正アクセスではないです。」
- GMO「感じ方の違いだ」
- 私「でも一般常識的には不正アクセスではないと思います…」
- GMO「禁止事項の事項に違反している。本人が、または第三者に命じて、設備に負荷を与えてはいけないことになっている」
- 私「負荷を与えたのは私ではないですし、第三者に命じたわけでもないので該当しないと思います」
- GMO「DDoSされる状態になっているのが問題。お客さまは無自覚に第三者にDDoS攻撃をさせたので該当する」
- 私「無自覚って…」
- GMO「DDoSへの根本的な対策は、ドメインを変更することだ」
やりとりの内容
DDoS攻撃を受けた数時間後にGMOクラウドのサポートからメールが来ました。その内容はというと、
- 外部サーバから私のサーバに向けて大量通信を検知した
- サーバーが第三者に不正に利用されているケースが考えられる
GMOクラウドからの要請としては「下記を確認して、1週間以内に連絡してほしい」というものでした。
- 不審プロセスの確認、及び不審プロセスの停止や削除
- 進入経路の確認、及び必要なセキュリティ対処策の実施
- 必要に応じた、各種プログラムの脆弱性への対処を実施
- 必要に応じた、各種アカウントのパスワード変更
- ROOT権限が奪取されていないかの確認
また、注意事項としては
- 期日までに対応しない場合はサーバーを止める
- 期日前でもGMOクラウド全体へ影響が出ると判断したらサーバーを止める
以上が最初に来たメールの内容です。
これに対して私は、下記の内容でメールを返信しました。
- ログからSYN flood攻撃であること
- iptablesでSYN flood攻撃の対応をしているが、限界がある
- 私だけでなくクラウド全体に影響しないように、上位ネットワークで対応してほしい
この私のメールに対しての返信がありました。その内容は、
- 該当サーバはiptablesのみ使っている様だった
- クラウドコンソールにもファイアーウォール機能があるので検討してほしい: http://support.gmocloud.com/public/guide/portal_manual/fw.html
- GMOクラウドの上位ネットワークにてファイアーウォールの対応を行うサービスはない
クラウドコンソールのファイアウォール機能は見た限りDDoS対策ができるような設定はなく、結局こちらで対応できることは無かった。
クラウドコンソールのファイアウォール設定画面
その後またDDoS攻撃があり、GMOクラウドの担当者から電話がくる。
GMO「IPアドレスが標的になっているかもしれないので、IPアドレスを変更してほしい」
言われるがままにIPアドレスを変更。Zone情報も変更。
IPアドレスを変えてもDDoS攻撃がやまず、またGMOの担当から電話がかかってくる。
話のはじめは次のような内容だった。
・ 事後報告になるが、他のお客さまのご迷惑になるので、 対応期日よりも前だが サーバをネットワークから切り離した(最初は1週間以内の対応を要求してきたが、実質与えられたのは42時間(そのうち平日は10時間)だった)
・ドメインが標的になっているかもしてないのでドメイン変えて欲しい
私「標的型だからドメインを変更しても、またすぐに攻撃が再開するのでは? Googleにインデックスされれば、攻撃者はまた見つけて攻撃を再開すると思うのですが…。」
GMO「ドメインを狙っているから、ドメインを変えれば解決すると思います。」
私「ドメインを変更してもネットで検索すれば見つけられるし、ドメインを変更しても意味ないと思うんですが…?」
GMO「ドメインを変更できないということであれば、サービスは提供できません。」
GMOはこの一点張りだったので、上位ネットワークがどうなっているか聞いてみることにした。
私「上位ネットワークでは打つ手無しという感じなんですか?」
GMO「監視はしてますが、上位ネットワークでの対策というのはできないんですよ。」
私「そもそもなぜ切り離したんですか?」
GMO「他のお客さまのご迷惑になるからです。お客さんの利用状況を鑑みてとめました。」
私「そういうことじゃなくて、何を根拠に停止したのか教えて欲しいんです。利用規約に書いてありましたっけ?」
GMO「書いてありますよ。登録するときに、規約同意してますよね?」
私「見てますし、同意もしてますが、どの条項が該当するんでしょうか?」
GMO「確認しますので、このままでお待ち下さい。」
約10分ほど保留に。本当に根拠があるなら、即答できそうなものですが、何故か保留にされました。
GMO「『ＧＭＯクラウドパブリックサービス利用約款』の第4章に該当します。」
私「第4章のどの条項ですか?」
GMO「第6条の2項です。」
第４章 お客さまの義務
第６条（仮想サーバー等の管理）
[…中略…]
２． 当社は、お客さまの管理する仮想サーバーが不正にアクセスされ、又はウィルスに感染している場合には、期限を定めて適切な管理作業を行うよう通知することがあります。当社からの通知にもかかわらず、期限までに適切な管理作業が行われない場合には、当社は、仮想サーバー等を停止することができるものとします。
https://www.gmocloud.com/pdf/gmocloud_public.pdf
私「これがDDosに該当するんでしょうか?」
GMO「該当します。」
私「DDoS攻撃を受けたのは、不正アクセスでもウイルスでもないじゃないですか」
GMO「『など』に該当します」
私「『など』なんてどこあるんですか? 『または』じゃないんですか?」
GMO「確認します…」
約10分後
GMO「第9条の禁止行為の(7)に該当します。」
なぜかさっきの規約とは違う「禁止行為」の条項を根拠に切り替えた。
第９条（禁止行為）
１． お客さまは、本サービスを利用して、次の各号に掲げる行為を行い、又は第三者に行わせてはいけません。
(…中略…)
(7) 当社の設備に過大な負荷を与える行為。
(…中略…)
２． 当社は、お客さまが前項の禁止行為を行い、又は第三者に行わせているときは、直ちに無催告で本サービス
の提供を停止することができるものとします。
https://www.gmocloud.com/pdf/gmocloud_public.pdf
私「これは該当しないと思いますが…? DDoS攻撃を行ったのは私ではないですし、第三者にやらせたわけでもないからです。ましてや、DDoS攻撃を受けた側なんですが…。」
GMO「こちらの第三者というのは意図的でなくとも該当します。現状、お客さまのドメインがDDoS攻撃を受けれる状態になっておりますので、お客さまが 無自覚 でDDoSを誰かに行わせているという解釈になります。」
私「上の方に代わっていただけますでしょうか?」
あまりにもすごい論理だったので、交代をお願いした。
「ドメインが狙われている =第三者がDDoS行えるようになっている= あなたが第三者に行わせている」という論理になるわけで、これを賃貸契約に照らしあわせてみたら「アパートが狙われている = 第三者がアパートの窓を壊せるようになっている = 第三者が泥棒できるようにしているアパートを借りてるお前が泥棒だ!」と言っているようなものです。
30分ほどして上司の方から直接電話がかかってきた。
私「先ほどの担当者の方が『禁止行為に該当する』と言っていましたが、DDoS攻撃を受けることは禁止行為なんでしょうか?」
GMO上司「禁止行為ではありません。」
私「あと、先ほどの担当の方は『第４章 お客さまの義務』に違反していると言っていたのですが、こちらにも該当しないと思うんです。今回はDDoS攻撃で、不正アクセスでもウイルスでもないですし。」
GMO上司「それは、『感じ方の違い』です。」
私「でも、常識的に考えてサーバーが乗っ取られたわけではないから、該当しないと思うんですよ。root権限が乗っ取られたとか、WordPressの脆弱性をつかれておかしなプログラムを仕込まれたとかなら納得できるのですが。」
私「どんな条項が根拠になってサーバーをネットワークから切り離したか、もう一度確認してもらえますか?」
GMO上司「『不正利用サーバーに対する弊社の取り組み』が根拠になっています。」
今度根拠に上げてきたのは規約ではなくマニュアルの一部。
不正利用サーバーに対する弊社の取り組み
弊社では被害の拡大を防止するため、不正利用を発見した場合には、仮想サーバーの停止を行い、さらに該当IPアドレスの隔離を行います。その為、再度別IPアドレスの仮想サーバー構築、データ移行が必要となります。予めご了承いただきますよう、お願いいたします。
http://support.gmocloud.com/public/guide/security_manual/
GMO上司「今回は規約とうより、どちらかというとこちらのほうが強いです。」
規約よりもマニュアルが優先されるという論理が理解できなかったので聞いてみた。
私「DDoS攻撃を受けることは不正利用ではないと思いますし、私はサインアップするときに、この文章には同意してませんが…。」
GMO上司「担当部署に確認します…」
30分して電話がかかってきた。
GMO上司「切り離しの根拠は、『お客さまの義務』というトピックの6条3項の太字の部分に該当します。」
第４章 お客さまの義務
第６条（仮想サーバー等の管理）
[…中略…]
３． 当社（当社が作業を委託する第三者を含む。）は、お客さまの依頼がある場合のほか、本サービスを提供するための機器に不具合が発生した場合、仮想サーバー内のプログラム等が当社の設備に過大な負荷を与えている場合、 その他本サービスを提供するために必要がある場合には、お客さまに提供する仮想サーバー内における調査、仮想サーバー等の設定変更その他の管理作業を行うことができるものとします。
https://www.gmocloud.com/pdf/gmocloud_public.pdf
私「『お客さまの義務』は全うしていると思うんですが…」
GMO上司「義務を全うしているかどうかではなく、3項にそう定めてあるので。」
GMO上司「ネットワークの遮断も『その他本サービスを提供するために必要がある』と『その他の管理作業」に該当します。』
私「サービスを提供するためなんですね。では、いつ復旧するか教えていただけますでしょうか?」
GMO上司「ドメインやコンテンツの問題が解決しないと復旧はできません。」
私「標的型のDDoSなのでコンテンツとかドメインを変更するとか問題ではないですよね。TCP/IPの通信は常にIPアドレスに対して発生するんですから。」
GMO上司「そうおっしゃるのであれば、お客さまのほうで ログの提示など証拠を示して証明していただく必要 があります。ドメインではなく、IPが問題ということであれば、本日中に対応させていただきます。」
調査して改めて伝えた内容:
・不正なプログラムはしこまれていないのでコンテンツの問題ではない点
・外部から、IPへ対してのDoS攻撃であることが間違いな点
・借りているサーバでは為す術がなく、上位のネットワークで対応が必要である点
GMO上司「お客さまの調査結果はごもっともだと思います。しかし、できるかぎり制限しようとしましたが、ソースのIPアドレスが詐称されているのでとめてもいたちごっこになっております。改善が見込めない通信ですので、やはり 根本的な対策 としてドメインを変更する必要があります。」
私「ドメインを変更すれば解決すると本当にお考えですか?」
GMO上司「解決の可能性が高いです。」
私「それは技術的な根拠があってのことでしょうか?」
GMO上司「IPアドレスを変えても変わらなかったので、ドメインに対して攻撃がきていると判断しました。」
私「では、もし http://gmocloud.com というドメインにDDoS攻撃を受けたらドメインを変更するんですか?」
GMO上司「はい、そのように対応するルールになっています。」
私「DDoS攻撃への対策として、これまでにドメインを変更して対応するという施策は今までに行ったことがあるんですか?」
GMO上司「弊社で把握をしている範囲での回答となりますが、ドメイン変更による対処は過去ございません。しかしながら、Dos攻撃による同事例は過去にもあり、その都度対象となるお客様へ今回のような対応依頼を行っております。」
GMO上司「その際に 最終的な対処 としてこの度ご依頼をさせていただきました。 ドメイン変更 を行われているお客様もいらっしゃる可能性はございます。」
私「ドメインを変更したとして、その新しいドメインにDDoS攻撃が再度発生したときはどうするんでしょうか?」
GMO上司「状況にもよるかと存じますが、再度ログからの調査と、ドメイン変更が必要な場合は再度ご対応いただく必要があります」
つまり、攻撃が止むまでドメインを変更し続けるのが、GMOのDDoS対策のようでした。
運用しているサーバには1つのドメインとその言語切替のためのサブドメイン(Wikipediaのように)が20数個割り当てられているのですが、GMOの方は大変親切にも、どのドメインが攻撃の対象になっているか切り分け検証をしてくださり、メインのドメインが攻撃の対象であることを突き止めてくださりました。
最終的にGMO側の要求としては、そのメインのドメインのAレコードを外してほしい、さもなければGMOクラウドPublic上ではサービスを提供できないということでした。もし、メインのドメインを運用したいのであれば、IDSなりDDoSに耐えうる機材・機器(GMOの方曰く数千万円する機材とのこと)を自分で導入して外部で運用したらどうかという具体的な提案をいただきました。
結局のところ、メインのドメインはGMOクラウドPublic上では運用できないので、出ていくのが現実的なところかなと考えながら、次のホスティングサービスを検討しています。(ここは、AWSに行きたいところですが、月間転送量が6TBほどでパケ死が見えているため悩ましい…)
さくらのクラウドが出たての頃、同クラウド全体で大規模障害が発生して、復旧が見込めなかったので、とりあえず類似サービスのGMOクラウドPublicに移転したのが使い始めた理由ですが、当時もGMOに移行すると言ったら、おすすめしないとツイートされたことがあったのを覚えてます。仮移転したあとも、GMOクラウドはPublicを2年ほど運用していましたが、特に大きな障害もなくサポートも悪くなかったので使い続けてきましたが、ついにXデイが来てしまったようです。
追記
同じGMOグループのConoHaは次のように述べておりましたが、
GMOクラウドさんは別会社なのでちょっとわかりませんが、ConoHaはDoS攻撃には上位ネットワークのフィルタリングで対処しています @atomfe
— 美雲このは (@MikumoConoHa) 2014, 5月 21
実際のところDDoS攻撃を喰らったらConoHaを解約する羽目になった話 | トコトコ日記という話も出ています。
追記 2016-09-02
後々になってTwitterでご指摘いただきましたが、この件の以後ＧＭＯクラウドパブリックサービス利用約款の内容が改定され「当社は、お客さまに提供するサーバー等がＤＤｏｓ攻撃等、第三者による攻撃を受けた場合には、お客さまに事前に通知することなく、サーバー等の停止、ネットワークの切断、その他必要な措置を取ることがあります。この場合、当社の措置によりお客さまに生じた損害について、一切の責任を負いません。」といった内容が追加されたそうです。
GMOクラウドの利用規約を見たら、DDoSされたらサーバーを止めたりネットを切断したりするぞと書いてあった。Qiitaの記事ではこの条項は出てこないから、後で追加されたのだろうか。https://t.co/X9aMyAqoIt pic.twitter.com/RYGubAuQ6v
— kusanoさん@がんばらない (@kusano_k) 2016年9月2日
追記 2016-09-02
2016年8月末より国内で発生している大規模なDDoS攻撃の被害にあった関係で、本件同様にGMO VPSから立ち退きせざるをえない状況になったという事例もあるようです。