AWS Game Day Tokyo 2013に参加してきた #awsgameday #jawsug
AWS Game day Tokyo
6/8(土)に開催された、[AWS Game Day Tokyo 2013]に参加してきました。
「AWS Game Day Tokyo 2013」 日本初!対戦型システム信頼性向上策を体感しよう!
AWS SAの皆様、面白い体験をありがとうございました!
簡単なルール
バッチ処理システムをAWS上に構築した後、他チームのAWSアカウントのPower User(IAM以外へのFull Control)をもらい、他チームのシステムをめちゃくちゃにする。 その上で、
- 最もEvilな攻撃をしたチーム(Most Evil Break)
- 最も強靭な防御をしたチーム(Most Awesome Fix)
- 最も面白い画像を出力したチーム(Funniest Image)
の3つが表彰対象となります。
システム構成概要
画像加工バッチ処理クラスタを構築しました。 簡単にシステム説明すると、以下のような感じ。
|--->S3 SQS -> Batch(EC2) -| |--->SQS
- 画像URLをSQS Inputとして渡す
- Batchクラスタが画像をモンタージュ加工
- 加工した画像をS3にアップロードし、完了メッセージのQueueを流す
という感じの流れになります。
参加前はWebアプリケーションが攻撃対象かなー、なんて考えていましたが、かなり裏をかかれた感じです。
諸事情あり、構築自体はほとんどCloudFormationでポチポチするだけでだったので、どうやって守りを固めるかが大事になりました。
攻撃
実行した攻撃は、主に下の4つです。
S3のBucketPolicyをいじる
AutoScalingをいじる
SQSのConfigurationを変更する
SQSにおかしなqueueを流す
1については、BucketPolicyでAll Denyにしました。これはバレやすいかなー、とも思いましたが、攻撃の一つとして決行。
2はAutoScalingのScheduled policyを変更して1分おきに全てのインスタンスがterminateされるようにしたり(この方法は向かいの席の方に教えて頂きました)、 launchConfigurationいじってインスタンスサイズをかえてみたりしました。
3はqueueのDelivery DelayをInput, Outputともに最大の15分に設定して、いつまで経ってもキューが消化されない状態を作りました。
4については、相方の@sunadoriさんに調査をしてもらいながら、私が個人のAWSアカウントにApacheを立てて設定かえて、無限RedirectするURLをqueueに流し込むことにしました。 また、バッチ処理の実行スクリプトの挙動を見て、渡すURL文字列にOSコマンドを入れこめることがわかったので、それでchmodやkillを流したりしました(SQS Injection...)
CloudWatchとAutoscalingを連動させて、ある閾値に達したらサーバを自動でシャットダウンさせる案も考えたんですが、時間が足りなかった・・・ autoscalingのcliに慣れていなかったせいで、2にかなり時間を使ってしまいました。
参加前は、SecurityGroupとかでネットワークを不通にさせることも考えていましたが、EC2インスタンスへのInbound通信がほとんどない構成だったので断念しました。non-VPC環境ではOutboundの設定がいじれないですしね。
被攻撃 & 修復
40分間の攻撃が終わったら、今度は攻撃を受けた自システムを修復する時間でした。 私のシステムが受けた攻撃は、SQSとbucketの名前が変わっているという、比較的単純かつ気づきにくいものでした。 が、バッチプロセスが落ちる現象の修復に手間取ってしまい、時間内に実行できた画像処理は一件だけという結果に。。。 修復がうまくできなかったことは、大きな反省点です。
振り返り&懇親会
その後は、他のチームと手の内を明かし合う時間でした。 Cloudwatchの案はかなり好評で、時間が足りなかったことが悔やまれました。(負け惜しみ) ですが、無限Redirectが結構いい評価だったようなのでよかったです。 SQSInjectionに対する対策されていたチームがあるのには驚きました。とてもそこまでできる余裕がなかったです。。。 そして、出力できた唯一の画像が、まさかのFunniest Image賞に!www その画像がこちら。
終了後の懇親会も、様々な話が聞けてよかったです。
終わってから思ったこと
SQSのPermissionをいじって、外部アカウントからのenqueue/dequeueを許可してしまえば、外部マシンからSQSに対して継続的に好き勝手やることができるので、攻撃の一つとして試しておくべきだったと思いました。
これから
AWSを真剣に触り始めて半年ほどで、初めてAWSの勉強会(と呼んでいいかわかりませんが)に参加しました。 CloudFormationはまともに使ったことがないサービスでしたが、強力さが痛いほどわかりました。
一番印象的だったのは、Milesがプレゼンで
- 最適な基盤状態を定義しておいて、いつでもその状態に戻せるようにしておく
- 基盤は"Repair"ではなく"Rebuild"してしまえばいい
と言っていたことです。Milesの話に関しては@KenTamagawaさんのブログが参考になります。 http://uncloudedeyes.hatenablog.com/entry/2013/06/09/001620
とにかく得る物が多い一日でした。
相方の@sunadoriさん、ありがとうございました!
次回のGame Dayもぜひ参加したいですね。今度こそMost Evil Attackの称号を手に入れます!