AWS Game Day Japan 2014 に参加した
JAWS DAYS 2014 の前日に開かれた、 Game Day Japan 2014 に参加してきました。 AWS Game Day Japan 2014 Spring (Tokyo) - JAWS DAYS 2014 | Doorkeeper
Game Day そのものの詳細はクラスメソッドさんの Blog 記事が詳しいと思います。 すごく大雑把に言うと AWS で構築したシステムを全力で攻撃して全力で修復するというものです。
過去にも行われたようですが僕は今回が初参加でした。 Game Day そのものに興味はあったので今年もやるという噂をききつけてエントリー。 全会場で50人いかなかったら中止って書いてあって、平日ということもあり開催されるのかなーとちょっと不安でしたが 無事開催されることになって嬉しかったです。
会場に着いて説明のち、早速チーム分け。 チームメイトは @moomindani さんと @nginks さん。 自己紹介しつつまずはコミュニケーションツールを作る。 Google Docs だけでなんとかなるかと思ったけどチャットが欲しかった(声でバレるから)ので Skype も併用することにしました。
構築と防御
まず最初は構築フェーズ。EC2 と SQS を使ったシステムを手順に沿って作っていきます。 去年と同じだったらしいんだけど、どうせ問題変わるだろうと思って何ら予習しなかったので 2回目でーすって人が手挙げてたりして冷や汗ものでした。 構築はチームのお二人に任せつつ、防御周りのことをしたり構築を手伝ったり。 やったことはこんな感じ
- CloudTrail を有効化してログを他アカウントの S3 バケットに投げるように
- SQS の Dead letter queue を有効化して変なキューは自動で流せるように
- piculet でセキュリティグループの状態をコードとして保持
- 自作の IAM エクスポートスクリプトで IAM の構造とかを保持 (今回は IAM のみ触れないのであまり意味はないけど、読みやすいように)
などなど。色々考えましたがすっと手が動かないなーという反省。。。
EC2 が実行するワーカーに OS コマンドインジェクションを見つけて (去年も全く同じだったらしいけど) パッチ当てようか迷ったのだけど、 コード読んでたのが終了3分前くらいで間に合いませんでした。。。 あと CloudTrail のログを他アカウントに出すのは反則かなーと思ったけど、実際有効なんじゃないかなーと思ってやってみました。 ほんとは loggly の free account から読めるようにしてたんだけど、インポートがなぜかうまくいってなかったので諦めることに。 ちまちま作っていた自作のパーサと JSONView でなんとかしていました。
攻撃・修復
どんな攻撃があったかは ijin さんの Blog にほとんど記載されてるのでそちらをご参照ください。
AWS Game Day Japan 2014春を開催してきた - @ijin
相手に渡すアカウントは IAM の操作のみができない Power User Template だけを入れたアカウントだったので、 事実上ほとんどなんでもできる状態。 リソース全消しなどではなくバレにくく修復しにくい攻撃が評価されるとのことで、 事前に考えていた攻撃としては S3 の Bucket Policy 周り、Auto Scaling, OS コマンドインジェクション、VPC のネットワーク機能あたりを 攻めようと考えていたのですが、
攻撃用アカウントをもらってざっと目を通すとまさかの VPC 使わない (EC2-Classic) 環境…………
これで考えてた攻撃をかなり潰されてヒーという感じでした。その発想はなかった。。。
修復はだいたいできたものの、AutoScaling の Scheduled Action に仕込まれた攻撃を修復しきれず。 CloudTrail は多くのチームが壊しにかかったようですが、うちのチームは S3 Bucket を外に出していたこともあり無傷。 これについては後述。 1チームが複数チームから攻撃されるというアクシデントなどもありつつも修復フェーズおわり。
結果発表
結果、ほとんどのサービスに加えて Management Console も壊した (表示を触りまくった？) チームが優勝。 うちは厳しいんじゃないかしらと思ってたけどなんと地方賞(仙台賞)をいただきました。 どこ攻撃されたかわからないような攻撃が多かったのが評価対象だったようです。やったー。
感想
限られた時間でシステム作って修復するというのはなかなか難しく、 改めて思ったのは"正しい状態を保持して比較し続ける"ことの重要性でした。 例えばコードにエクスポートしていたセキュリティグループへの攻撃は、変更把握も修復も一発でしたし。
CloudTrail は正直 SQS や AutoScaling 周りへの攻撃がメインだった今回、あまり威力を発揮する場面はなかったかなーという印象。 ただ、リージョンが US だったこともあり、CloudTrail 環境下で作業をしていくとこういうログが取れるのかーというものが 手に入ったのは大きいと思いました。 Management Console も実際は各操作で API を呼んでいるので、相手がどんな順番でシステムの概要を把握していったのかある程度想像できたり。
IAM の Power User template では IAM の変更のみが禁止されてますが、監査という点から考えると CloudTrail への変更も デフォルトで禁止してほしいところです。。。
また、ログの保存場所について自分の考えを確認できたのも良かったです。 CloudTrail しかり ELB しかり、AWS への操作のログが徐々に取得できるようになってきてますが、 確実なログ運用のためには全く違うアカウント管理下にあるバケットへの格納など、どうやっても手がとどかない場所に保持しておくのは 一つの運用として良いのかなーと思いました。
色々と勉強になりました。次回も参加したいです。 運営の皆様、チームメイトの皆様、参加された皆様、ありがとうございました。
