対策もなにも、この内容が事実ならば、「ハァ?」ということ。対応レベル=品質レベルととらえると、こういうのは使えませんね。内部のエンジニアの品質も悪いんでしょう。きっと。まともならもっとまともな対応策などの提案が有るはずです。そもそも、サイトがねらわれれば、IPアドレスなんて変えるのは全く意味がありません。DNSからひいて探してくるでしょうし、サイトがねらわれているのであれば、名前を変更しても、ドメイン名を変更しても、見つけてくるでしょう。所詮いたちごっこなのです。
実際に出来る対応は事業者側での対応。あとは、利用者側としては、可能であれば上位回線が埋まるような攻撃を受けたときのことを想定して、裏口(物理的に違う網)を用意するということ。いわゆるフレッツや専用線などを使ったVPNや広域イーサーなども該当しますし、よくある構成です(大規模になればなるほど)。実際に私がIRCサーバを運用していたときも、syn flood, udp floodなど日常で届き、サービス側の回線真っ黒けになることも。なので、攻撃の種類にもよりますが、物理的に分離、インターフェースも分ける(vlanなんか、役に立ちません)というのが一般的。クラウドサービスやVPSなど仮想化向けサービスになった時点で、ネットワークは共通化されていたりすることもある為、網内(バックボーン〜エッジ含む)に入ってしまったら他のも影響うけるから、借りているサーバー以前に周りの巻き沿いなども有るため、事業者としては対応しなければならなくなるでしょう。また、事業者の立場としては正直面倒でもあるし、対応に迫られると、正直出て行ってほしいというのはあるけど、そうなった時点で事業者がは技術的、コスト的に見捨てたということですね。まあ、バックボーン全体を上回るトラフィックの流入はどうしようも無かったり
*1
しますが、対応可能なトラフィックの範囲内であれば、入り口でフィルタなどを行う方法はあるでしょう。
現実的にこういうのは、いたちごっこなので手での対応は難しいところはあるでしょうけど、多くの攻撃のケースの場合、srcがバラバラ
*2
ということは、そこまで多くないです。時間的にも長時間続くことは余りありません。とはいっても、そうとも限りませんが傾向的に、という話しです。IRCを運用していたときは、長時間続く攻撃が多かったですが…。Webサイトの場合比較的快犯などのことも多く、長時間続くことは珍しいと思います。
*3
網内からの攻撃トラフィックで帯域が埋まるようなケースは、事業者からすれば管理管轄内なので、不正パケットを出しているユーザのトラフィックの締め出しでも良いでしょう。まあ、正直面倒な事には違いないですけどね。にしても、ドメイン変更という事を言い出したGMOクラウドのお客様対応した担当者の低脳な対応には、ちょっとあきれる物が有りますね。まだ、DNSが向いている限り、サーバを落としていても攻撃は続けられ、syn flood / udp floodされている場合は、サーバが生きているか死んでいるかは関係有りません。また、ppsが多い場合、幾らサーバの性能を上げても、CPUやメモリの数を増やしても、NICが先に当たります(10Gだったらずいぶん緩和されますけど)。また、カーネルが一旦受けるわけで、そこのコストはバカになりませんから、同一ホスト上に有るvmはパフォーマンス面で影響を受けるでしょう。また、テーブルが埋まる恐れもあります。
話しを戻して、攻撃を受けたことが不正アクセス若しくはウィルスの感染と決めているのも明らかにおかしい話しです。明らかに、連携が出来ていない、フロントのお客様対応の判断が非常に残念で、適切にエスカレーションをされているようには思えない感じが残念でした。
ということで、Twitterでも話題になっていますが、
そのため、GMOクラウドにおいては「DDoS攻撃は、ドメイン名を変更すれば解決できる可能性が高い」といった対策の提案があったりしました。
とあることから、GMOクラウドでは、gmocloud.com 宛のドメインにDDoSがきたら、ドメイン名の変更をして、解決するようです。これが、共有サーバで、サブドメインを払い出しているケースはどうするんでしょうか。この理屈なら、全部変更なんでしょうね…。てことで、みんな、F5アタックしちゃえば、変更するんですかね...
さらに、記事を読んでいると...
GMO「こちらの第三者というのは意図的でなくとも該当します。現状、お客さまのドメインがDDoS攻撃を受けれる状態になっておりますので、お客さまが 無自覚 でDDoSを誰かに行わせているという解釈になります。」
私「上の方に代わっていただけますでしょうか?」
斜め上を行く回答。某社のどこぞの回答みたいで楽しい。私が見たのはもっと斜め上だったので、あきれてしまったが(笑
ということで、GMOクラウドを使おうとは思わなくなりました(-人-)ナームー...
事実だとするならば、事業者として本当にこれでいいのですか?> 青山さん
最近ふと思うのは、トップが元エンジニアで、且つ有る程度のプライド、ポリシーを持っていて曲げれないところは曲げれないという思想を持っていないと、今回みたいに、現場も含めていい加減な事に感じになってしまうような気がします。某社ではモロ当てはまりましたし。
*1:
ここは、Transitの上位と相談、対応できる関係を築いておくこと、Community等を使って、トラフィックの制御、広告の範囲を制限するなどをして、完全ではないものの、被害を最小限にすることも出来ますね。地道な作業ですが正直私はやりたくないです…w。ここは、事業者としての力量でしょう。いくつか完全ではないけど、出来る対応方法はありますね。ていうか、そんな作業に張り付きたくねぇから、出て行ってくれと言いたいのもわかるけどねw。まあ、即座に判断出来る人は熟練者ぐらいでしょうか。でも、そういう人ほど引きこもりたいものですw
*2:
prefixなど、比較的固まったブロックの範囲内が複数程度
*3:
私が見ている環境と違うケースも十分にありうるけど、一つの意見として。
先日新しいVMware ESXiの新規構築に、生活環境を移そうとし、ついでにメンテナンスをしようとたら、Kernel Panicしてしまい、起動しないいことが判明したので、再構築していた。理由は、完全なオペミス。経緯を説明すると、昨年のいつか忘れた頃に、Debian 6 の時に、apt-get dist-upgrade としたまま放置し再起動せず半年以上。その後、パッケージをインストールしたりしていたら、どうやら環境が壊れてしまい、長期間再起動していなかったこともあり、自動的にfsckが走るようになっていたり、initrdが更新されていないなど、いろんなところで不具合が出ていた。そういうわけで、Debian 7.5 へシステムの再構築。実はDebian5の頃からアップデートをして使っていたんだよなぁと。ずいぶん長い間お世話になった旧環境。幸いにも、移行前のvmは電源を落としていないので、まだ、起動した状態なので、データはそこからrsyncすればよいので、比較的楽。
つーわけで、インストール後、source address routing がちゃんと動かない。ip rule が旨く入らない・・・なんでだ、バグかしら?とおもい、調べていて、以前動いていたスクリプトでもだめで、defaultに向かってパケットが流れてしまう、なぜだということで、バージョンが変わったことによりなにか変わったのかと検証するために、kernel を再構築していた。最終的には、スクリプトを移植する際に、IPアドレスの打ち間違えが原因だったのだが...
理解するために、色々と改めて良い勉強になったので、結果ヨシとしよう。
以前、debian でmake-kpkg でカーネルの再構築をしていたのと少し方法が変わっているので、記しておく。
新システムでカーネルをビルドしたくないので、ビルド用のマシンを新規、最小インストールを行い、ビルド環境としておく。今回、fakerootを使っていないので、そこはご了承を。
ビルド環境の構築は簡単で、コマンド一発でほとんど必要な物が入る。
# apt-get install kernel-package libncurses-dev
libncurses-dev は make menuconfig をつかって、CUI方式でカーネルパラメータを変更する場合に必要だ。Suggested(提案リスト)には入っているだけで、インストールはされないので、一緒にインストールをしておこう。
実行したらこれだけのパッケージが入る。
# apt-get install kernel-package libncurses-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
autopoint binutils build-essential cpp cpp-4.7 dpkg-dev fakeroot g++ g++-4.7 gcc gcc-4.7 gettext
git git-man intltool-debian libalgorithm-diff-perl libalgorithm-diff-xs-perl
libalgorithm-merge-perl libc-dev-bin libc6-dev libcroco3 libcurl3-gnutls libdpkg-perl
liberror-perl libffi5 libfile-fcntllock-perl libgettextpo0 libglib2.0-0 libglib2.0-data libgmp10
libgomp1 libitm1 libmail-sendmail-perl libmpc2 libmpfr4 libquadmath0 librtmp0 libssh2-1
libstdc++6-4.7-dev libsys-hostname-long-perl libtimedate-perl libunistring0 linux-libc-dev make
manpages-dev po-debconf rsync shared-mime-info libncurses-dev
Suggested packages:
binutils-doc cpp-doc gcc-4.7-locales debian-keyring g++-multilib g++-4.7-multilib gcc-4.7-doc
libstdc++6-4.7-dbg gcc-multilib autoconf automake1.9 libtool flex bison gdb gcc-doc
gcc-4.7-multilib libmudflap0-4.7-dev libgcc1-dbg libgomp1-dbg libitm1-dbg libquadmath0-dbg
libmudflap0-dbg libcloog-ppl0 libppl-c2 libppl7 binutils-gold gettext-doc git-daemon-run
git-daemon-sysvinit git-doc git-el git-arch git-cvs git-svn git-email git-gui gitk gitweb
linux-source kernel-source docbook-utils xmlto grub grub2 jfsutils mcelog
oprofile pcmciautils ppp reiserfsprogs squashfs-tools xfsprogs quota btrfs-tools glibc-doc
libstdc++6-4.7-doc make-doc libmail-box-perl
The following NEW packages will be installed:
autopoint binutils build-essential cpp cpp-4.7 dpkg-dev fakeroot g++ g++-4.7 gcc gcc-4.7 gettext
git git-man intltool-debian kernel-package libalgorithm-diff-perl libalgorithm-diff-xs-perl
libalgorithm-merge-perl libc-dev-bin libc6-dev libcroco3 libcurl3-gnutls libdpkg-perl
liberror-perl libffi5 libfile-fcntllock-perl libgettextpo0 libglib2.0-0 libglib2.0-data libgmp10
libgomp1 libitm1 libmail-sendmail-perl libmpc2 libmpfr4 libquadmath0 librtmp0 libssh2-1
libstdc++6-4.7-dev libsys-hostname-long-perl libtimedate-perl libunistring0 linux-libc-dev make
manpages-dev po-debconf rsync shared-mime-info libncurses-dev
0 upgraded, 49 newly installed, 0 to remove and 0 not upgraded.
Need to get 54.6 MB of archives.
After this operation, 142 MB of additional disk space will be used.
Do you want to continue [Y/n]? y
あとは、ビルドしたいカーネルを
http://www.kernel.org/よりダウンロードをして、カーネルをカスタマイズする。
今回は、3.2系の最新版(3.2.59)を持ってくることにして、ビルドした。
Debian 7.5 の初期状態でインストールされている、3.2.0-4-amd64 のカーネルコンフィグは、下記の場所に有るのでこれをベースに必要箇所だけ書き換えると良いで。不要なのは外してもイイですし、必要なのは追加すればよいのです。
/boot/config-3.2.0-4-amd64
てことで、今回、root 環境で作業しちゃうので、ざくざくとコマンドメモを。
# wget wget -4 -c https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.59.tar.xz
# xzcat linux-3.2.59.tar.xz | tar xvf -
# cp /boot/config-3.2.0-4-amd64 /root/linux-3.2.59/.config
今のカーネルは、7zで圧縮されているんですね…。あと、後で教えてもらったのは、GNU tarでも簡単に展開できるよと。BSD tarでは楽なのは知っていたけど、ここまで良くなっているとは…時代を感じます。
ex)
# tar xvf linux-3.2.59.tar.xz
あとは、差分の変更箇所の確認。結構面倒です。
# cd linux-3.2.59
# make oldconfig
面倒であればマージせずすっ飛ばして、
# make menuconfig
これでもいいかもしれません。
あとは、カーネルをビルドするだけ。私は今回VMwareの環境で、メモリを4GB、4Core割り当てたので、make opt に -j 8 としたかったので、変数に入れておきます。設定しないとCPU全然使えませんでした。かなり遊んでた…
# export CONCURRENCY_LEVEL=8
あとは、カーネルのビルド及びカーネルパッケージの作成です。
make-kpkg clean && make-kpkg --initrd --revision=2014.05.21.01 kernel-image kernel_headers
念のため、私の環境でどの程度時間がかかりか、timeをつけておいた。
結果こんなかんじ。
real 29m2.036s
user 66m40.958s
sys 8m4.190s
ビルド中、DL360G6 Xeon X5570 の環境では、電源の消費電力がずどーん!
通常時100弱W程度のものが、190Wまでふくれあがるというので驚きものですね。
参考に、CONCURRENCY_LEVEL の変数を定義した場合としなかった場合の様子でも。
未定義
10:46:10 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
10:46:11 all 20.60 0.00 5.03 0.00 0.00 0.00 0.00 0.00 74.37
10:46:11 0 15.15 0.00 5.05 0.00 0.00 0.00 0.00 0.00 79.80
10:46:11 1 1.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 98.00
10:46:11 2 49.49 0.00 9.09 0.00 0.00 0.00 0.00 0.00 41.41
10:46:11 3 17.00 0.00 4.00 0.00 0.00 0.00 0.00 0.00 79.00
CONCURRENCY_LEVEL=8
10:47:15 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
10:48:17 all 90.34 0.00 9.50 0.00 0.00 0.16 0.00 0.00 0.00
10:48:17 0 89.50 0.00 10.12 0.00 0.00 0.38 0.00 0.00 0.00
10:48:17 1 90.69 0.00 9.28 0.00 0.00 0.03 0.00 0.00 0.00
10:48:17 2 90.65 0.00 9.14 0.00 0.00 0.21 0.00 0.00 0.00
10:48:17 3 90.51 0.00 9.49 0.00 0.00 0.00 0.00 0.00 0.00
完全にCPUを使い切っているのがわかる。無駄が無くて良い。
さて、これでパッケージが出来たはずなので、一つ上のディレクトリへ移動し、パッケージが有るか確認しましょう。
# cd ..
# ls -ld linux*
drwxrwxr-x 25 root root 4096 May 21 12:12 linux-3.2.59
-rw-r--r-- 1 root root 65617552 May 18 23:34 linux-3.2.59.tar.xz
-rw-r--r-- 1 root root 7772480 May 21 12:13 linux-headers-3.2.59_2014.05.21.01_amd64.deb
-rw-r--r-- 1 root root 33947520 May 21 12:11 linux-image-3.2.59_2014.05.21.01_amd64.deb
こんな感じで出来ているはずなので、後は、パッケージのインストールでOK!
# dpkg -i linux-image-3.2.59_2014.05.21.01_amd64.deb linux-headers-3.2.59_2014.05.21.01_amd64.deb
後は再起動して様子を見ましょう。