ロリポップ騒動から、AWS移行で死んだ日

2013年8月30日

昨日は疲れました。死んだといっても過言では無い。このサーバもほとんど落ちた。1日のアクセス数60000人。ただしアドセンスはたいしたことない。だってみんな必死で検索してるんだもの・・・。

1
ここいうツイートで癒やされました・・・涙

ロリポップと契約していた顧客がロリポップのサーバ改ざん発表のあとで直撃弾くらいました。ショップでなくてブログだったので引っ越しを先に考えていたのが甘かったです。それもパスワードを複雑にして2段階認証を設定して、wp-config.phpも推奨通り404にしていてやられました。のちにロリポップ側で400に強制変更したようだが、404だってそうそう入れるものじゃ無い。侵入されたサイトのバックアップを直前に取ってあったので、時限爆弾の可能性もあるなとエンジニアが半日かけて精査したけどないようでした。ログイン画面からプルートフォースアタックで入って来たわけではないのは確か。2段階認証突破するのはめちゃ大変です。このハッカーさん達はサイトを見ると、かなり高レベルのみなさんでコンテストのノリでアタックしている。面白半分だから怖い。たぶん痕跡もきれいさっぱりレベルなのではと思う。

やられたのは文字コードの変更やプラグイン除去など、データベースのダイレクトな書き換え。なんらかの手段でユーザーのデータベースのパスワードをまとめて入手し、踏み台となる隣人経由でやられたという見方で間違いないのではないか。それともこれも風評ですか??
このままでは修復しても同じと考えて、急遽、Amazonのデータセンター(AWS)への引っ越しを決意。サポート会社に無理を言ってセットアップしてもらい、いまDNSの切り替え目前のテストしています。
移転前にまた書き換えられたら大変だと、データベースのパスワードを変更しようとしたが・・・できない・・・ものすごいうっちゃりを食いました。正確に言うとロリポップの管理画面では新しいパスワードに変更されたように見えるのだが、実は変更されていない。ググったらみんな同じで困っているからどうも仕様らしい。これじゃ入られ放題だ。犯行声明したハッカーの他にも、「入れる」とわかった中国人のみなさんとかが同じ方法でトライしまくってる可能性もある。こちらはゲーム感覚では無くてマジな悪人。個人情報抜いたり、仕掛けをしてフィッシングサイトに誘導したりするためである。ぞっとするよ。

今朝の4時13分だが、ロリポップのリリースでは

2013/08/29 22:40 にご報告した対策に加えて、お客様のデータベースの安全性を確保するため、ロリポップ!レンタルサーバー上にある全てのWordPressで使用しているデータベースのパスワード、および該当するデータベースを使用しているCMSの設定ファイル上のパスワードの書き換えを行います。

というのが出た。やっと気づいたらしい。これをもっと前に・・・おそらく改ざんが発覚した当初にやって入れば、万単位の被害は出なかったのではないか。しかし当初は「パスワードを変更して」とか「固定IPにして」(そんな人いるかっての!)とか割と的外れのことをアナウンスしていたし、原因究明に時間がかかったのはどうかと思います。それにどういう経路でユーザーのデータベースのパスワードがブッコ抜かれたのか、その発表がまだない。パスワードを変更してもまたブッコ抜かれたら同じなんだが・・。TLでもいろいろな可能性が出ていたが、それについてはエンジニアではない私は触れるのやめておきます。

現段階のロリポップの見解では

[対象のお客様]
「ロリポップ!レンタルサーバー」のユーザーサーバーにおいてWordPressをインストールされている一部のお客様(8,438件)

[現在までに判明している被害状況]
WordPressのプラグインやテーマの脆弱性を利用し、不正なファイルがアップロードされました。
またそのファイルを利用し、wp-config.phpの設定情報が抜き出されることにより、データベースの書き換えが行われ、WordPressサイトが改ざんされました。

だそうです。

今回の教訓、それは「(ヤバイ)共用サーバは危ない」ということに尽きる。自分でサーバ借りずにブログサービス借りればいいという後戻り意見もあったが、

サイバーエージェント「ameba」が4ヶ月問題放置で24万件という見事な個人情報漏洩事件をやらかす

にあるとおり、どこでも同じなのである。
共用サーバにいる限り、隣が素人だったら同じ。誰もがきちんとした身元の人ばかりの住民のマンションに住みたいと思うが、中にはヤクザとか、夜中に叫び出す人とがが混じると、一気に住環境は悪化する。鍵もかけないで出かける住民が空き巣にはいられるのは勝手だが、空き巣がベランダ伝いにやってきたというのが今回の事件。

そうなると手としては「一戸建て(専用サーバ)を借りる」というのが安心度が高い。複数管理しているなら1台を借りてそれにみんな入れる。しかし専用サーバもいろいろ試したが、1~2年でサーバスペックが古くなってしまうし、そもそも安価な専用サーバではハイスペックなマシンの共用より表示が遅くなるしすぐ落ちる。つまりそこそこのコストがかかってしまう。このブログもサーバにけっこうなお金を払っているが、昨日は何度も瞬断しApacheの再起動を定期的にしてもらった。

んで、自分が採った手段がコレ。「AmazonのクラウドサーバAWSを借りて、管理している顧客のサイトを収納する」である。つまり信用できる隣人しかいれない管理体制のマンションを作る。

http://aws.amazon.com/jp/

AWSは従量課金でサーバ使用料は安いし、画像はS3という別サーバだから表示がめちゃ速くなる。アクセスが集中しても分散化できるからサクサクだ。しかしマネージドではないのでOSのインストールから始まり、素人では運用できない。一般的には月々3万円くらいの運用コスト+サーバ代を専門の会社に支払って運用するわけだが、個人企業レベルではこれは厳しい。ちょうどわたしのメルマガにこうした会社を起業した人から質問メールが来て回答した経緯から、そこにお願いして安い料金体系を1日で設定(といっても共用よりはずっと高い)してやってみようということになり、その第1弾で専用サーバを立てて1日で移転しました。このブログ移転は後回しで来週です・・・。ひょうたんから駒、メルマガから新ビジネス。

ちなみに表示速度ですが、WordPress3本搭載で朝の空いてる時間帯で、ロリポップ0.89秒にたいし、AWSは0.21秒でした。
それではこれからDNS切り替えのチェックです。2日間これで潰したよ・・・涙

ちなみにプロによって原因はほぼ特定されたようです。WordPress関係無いじゃん!!↓下の方にてできます
http://bylines.news.yahoo.co.jp/yamamotoichiro/20130830-00027700/

AWSについてはたくさん本も出ています。まずは勉強。

  • 0
    このエントリーをはてなブックマークに追加
  • 0
    follow us in feedly
PAGE TOP