ロリポップ騒動から、AWS移行で死んだ日(永江一石) – BLOGOS(ブロゴス)

ロリポップのハッキング事件関連。
ロリポップ!、WordPress利用サイトで不正アクセスによる改ざん被害 -INTERNET Watch – けにあmemo

顧客がロリポップを使っていてその対応をされたというブログ記事が生々しくて、いろいろ参考になりそう。
ロリポップ騒動から、AWS移行で死んだ日(永江一石) – BLOGOS(ブロゴス)


侵入から始まったのではなく、アカウント情報の漏洩があったのではないかと示唆されている。

パスワードを複雑にして2段階認証を設定して、wp-config.phpも推奨通り404にしていてやられました。のちにロリポップ側で400に強制変更したようだが、404だってそうそう入れるものじゃ無い。侵入されたサイトのバックアップを直前に取ってあったので、時限爆弾の可能性もあるなとエンジニアが半日かけて精査したけどないようでした。ログイン画面からプルートフォースアタックで入って来たわけではないのは確か。2段階認証突破するのはめちゃ大変です。このハッカーさん達はサイトを見ると、かなり高レベルのみなさんでコンテストのノリでアタックしている。面白半分だから怖い。たぶん痕跡もきれいさっぱりレベルなのではと思う。
やられたのは文字コードの変更やプラグイン除去など、データベースのダイレクトな書き換え。なんらかの手段でユーザーのデータベースのパスワードをまとめて入手し、踏み台となる隣人経由でやられたという見方で間違いないのではないか。

事後の対応は相当混乱したみたい。
原因説明や対策が二転三転したあたりのことも書かれている。
想定していない問題にもぶつかったらしい。

移転前にまた書き換えられたら大変だと、データベースのパスワードを変更しようとしたが・・・できない・・・ものすごいうっちゃりを食いました。正確に言うとロリポップの管理画面では新しいパスワードに変更されたように見えるのだが、実は変更されていない。ググったらみんな同じで困っているからどうも仕様らしい。これじゃ入られ放題だ。

これはWordpressで使っているDBのことかな。
そして、教訓。

今回の教訓、それは「共用サーバは危ない」ということに尽きる。自分でサーバ借りずにブログサービス借りればいいという後戻り意見もあったが、
サイバーエージェント「ameba」が4ヶ月問題放置で24万件という見事な個人情報漏洩事件をやらかす
にあるとおり、どこでも同じなのである。

採用された対策。

んで、自分が採った手段がコレ。「AmazonのクラウドサーバAWSを借りて、管理している顧客のサイトを収納する」である。つまり信用できる隣人しかいれない管理体制のマンションを作る。
http://aws.amazon.com/jp/
AWSは従量課金でサーバ使用料は安いし、画像はS3という別サーバだから表示がめちゃ速くなる。アクセスが集中しても分散化できるからサクサクだ。しかしマネージドではないのでOSのインストールから始まり、素人では運用できない。一般的には月々3万円くらいの運用コスト+サーバ代を専門の会社に支払って運用する

AWSもまた最近止まったとかでニュースになってたみたいだけど。
AWSのサーバー問題で、Instagram、Vine、Airbnb、IFTTTらがダウン | TechCrunch Japan

コストと手間とセキュリティ(CIA)とビジネス要件の方程式で、選択肢が決まるんだろうな。

Amazon Web Services クラウドデザインパターン実装ガイド
大澤 文孝
日経BP社
売り上げランキング: 3,425

コメントを残す

メールアドレスが公開されることはありません。