AWS使って社内CTFやってみたよ
5/22に開催された第五回Security-JAWSにて登壇させていただきました！
Security-JAWS 【第5回】2017年5月22日(月) - Security-JAWS | Doorkeeper
タイトルそのままですが、某社内でAWSを使って社内CTFを開催した際のよもやま話をネタとしてお話しいたしました。 本当は当日投影したスライドとかをそのまま公開したかったのですが、イベント当日の写真とかについてはちょっと諸事情で公開できないので、今回はセッションの中でお話ししたAWSに絡む部分だけをまとめて、私のブログで公開しようかなと思います。
当日のセッションでもお話ししましたが、まずそもそもなんで社内CTFを開催したのかについては、
- なんか社内でエンジニアの人に楽しんでもらえるようなイベントとかをやってみたかった
- セキュリティに興味をもってもらうきっかけ作りとかには丁度いいのかなと思った
- ぶっちゃけちょっと運営側にも興味があった
というようなもので、最初は適当な有志で集まってやってみようかという軽いノリではじめてみた感じです。 社内でやってみたら、思ったよりもウケが良く、数回開催するうちにちょっとづつ規模が大きくなってきて、前回は70人くらいの方に参加していただけるイベントを開催できました。
現在開催しているものは、スタンダードなJeopardy形式のCTFです。 CTFを全くやったことのない方でも参加しやすいように、「CTF for ビギナーズ」のスタイルを極限まで参考にさせていただき、午前中は講義（座学＋ハンズオン）、午後からみんなでCTFをやるような一日コースの集合研修という感じで開催しています。現在はそういう感じですが、今後は常設CTFにしたりとか、他競技形式でのイベント開催なども、実現できるかはわかんないですが検討していきたいですね。
で、そんな中今までは、適当な機材をつかったオンプレの競技環境で開催していたのですが、段々規模が大きくなってきてめでたく予算もついたので、競技環境をクラウド化することになり、今回AWSを使って構築してみましたという感じです。という背景で、競技環境を構築する中でハマったことや、こんな感じでやりましたということなどをここで書かせていただきますｗ
AWSではイベント申請が必要
Security-JAWSのセッションでもお話ししましたが、弊社内CTFの一つの特徴として、競技用のクライント環境を運営側が全部用意しているという点があります。 これはまあ社内イベントならではの悩みなのかなと思うのですが、簡単に言えば社内だと諸事情によって競技用の端末を用意できない方とかもいらっしゃるので、そういう方でも気軽に参加していただくための運営側の配慮って感じですね。ちなみに「いやいや、俺は自前の環境でやりたいし」って方も勿論沢山いらっしゃるので、ご自分で用意できる方については持ち込みPCの利用もOKにしています。
で、まあイベント開催前に運営側で毎回このクライアントPCのキッティングをやっているんですけど、これがまあダルいし、結構大変なんですよね。という中、AWSにはAmazon WorkSpacesというDaaSがあります。
Amazon WorkSpaces (クラウド上の仮想デスクトップサービス） | AWS
これを見て「おお！クライント環境の用意はこれ使えば楽できるんじゃね！」ってそんな風に考えていた時期が俺にもありました。 結論から申しますと、実はその計画はとある理由によってお蔵入りとなってしまいますｗ
話は変わりますが、皆さんはAWSを使ってこういうイベントを開催する場合には専用の申請が必要だということをご存知でしょうか？ 脆弱性診断を実施する際に申請する必要があるペネトレーションテスト申請は結構ご存知だと思うのですが、その解説ページに、「シミュレートされたその他のイベント」という項目の記載があります。
上記には、どうやらこういったイベントをやるには、開催するイベントの内容などを事前にAWSに申請して許可をとらなければいけないルールがあることが記載されています。 私もAWSを利用して今回こういうイベントをやることになって初めてこのルールを知りました。
ペネトレーションテストの申請をされたことがある方は結構いらっしゃるのかなと思いますが、このセキュリティイベントに関する申請をされた方とかはあんまり多くいらっしゃらないのかなと思いましたので、ご参考までに今回どんな感じでやり取りをしたかについて簡単に書いてみました（まあ、そもそもこういったイベントを開催する人が、そこまで沢山いないだろというツッコミは置いておいてくださいｗ）。
まずはこんな感じで問い合わせをしてみたのですが…
ええー！？マジで！？WorkSpaces使えないの！？いきなり予想してなかった回答ををいただいたので、ちょっとビックリしました…。あとやり取りは英語じゃないとNGなようです。ちなみにAWS側から提出を要求された情報については以下のようなものでした。
| 原文そのまま | 自分の理解 |
|---|---|
| Account number(s): | AWSのアカウント情報 |
| Source IP(s) if applicable: | イベント時にAWS環境に接続するアクセス元IP情報 |
| Target IP(s) if applicable: | イベント時に接続するAWS環境サーバのIP情報 |
| Start Date: | イベント開始日 |
| End Date: | イベント終了日 |
| Regions involved in Event: | イベントに関係するAWSリージョン |
| EC2 or RDS Instances involved, if applicable: | イベントに関係するEC2またはRDSインスタンスの情報 |
| Are you an Amazon Enterprise Customer?: | Amazonの企業顧客かどうか |
| Software Used (if commercial): | 使用するソフトウェア（商用の場合） |
| AWS products/Services to be used): | 使用するAWS製品/サービス |
| Type of Simulated Event in detail: | イベント内容の詳細 |
| Dependent on the Simulated Event type, please confirm if target will be aware of the event?: | イベント内容に応じて、対象（対象者？）がそのイベントを把握しているか確認してください。(※1) |
| Whom (email address) should the target party contact to verify this is indeed a Simulated Event?: | これが本当にシミュレートされたイベントであるか確認するための連絡先情報 |
| Please provide target domain name, if applicable: | 対象ドメイン情報 |
| Will your Event require AWS interaction? If so, please let us know in what capacity and why?: | イベントでAWSとのやりとりが必要？もしそうならどんなことかと理由をお知らせください。 |
※1 こちらについてはイマイチ内容がわからなかったので内容について質問したのですが、特にAWS側からの回答はなく申請の許可がおりました。
ペネトレーションテスト申請と同じくらい結構色々情報を要求される感じでした。また、上記の内容については結構イベントの内容とか環境設計ができてる段階じゃないと、なかなか答えづらいんじゃないかなという印象を持ちました。ちょっとでもこの申請をされる方のご参考になれば幸いです。もしかしたら、イベント内容によっては設問が変わったりするのかもしれないですし、今後新しい設問が追加される可能性もあるので、これと全く同様というわけではない可能性はあります。
この回答に対して「ハイ喜んで～」と返信してしまうとまた地獄のクライアントPCキッティング大作戦が確定してしまうのがちょっと嫌だったのと、もしかしたら先方が何か勘違いしているのかもしれないし、ワンチャンあるかなと思ってちょっと食い下がってみたのですが…
というわけで、結局今回はWorkSpacesを使うことができませんでしたｗ 申請自体については、この後、設問に該当する情報を送ったら、次の日にあっさり許可がおりました。 もっと長い時間がかかるものなのかなと思ったのですが、思ったよりも早かったです。
結局どんな環境を構築したの？
上記のような理由により、今回WorkSpacesを使えなかったので、最終的には以下のようなシンプルな構成になっちゃいました。
社内イベントだし、そこまで大量アクセスが来ないだろうと想定し、問題サーバだけをELBを利用して冗長構成にした感じですね。今回やってみたかった取り組みの一つだったのですが、サーバで動作する問題については全部dockerを利用して作成しました。切っ掛けは以下の記事だったりします。
#cmdevio2016 (レポート: B-2) Trend Microのセキュリティコンテストの裏舞台でDockerとAnsibleを使った話 ｜ Developers.IO
以前この記事を拝見して、「おー面白そう！自分もちょっとやってみたい！」と思っていたのと、検証目的でちょこちょこ触ってはいたのですが、サービス提供するようなシステムをdockerで構築した経験が無かったので、丁度良い機会だから今回勉強がてらやってみました。 ※ちなみに元記事の発表をされたトレンドマイクロの岩田さんより、今回の発表の後に、ご挨拶いただきめっちゃ嬉しかったです！ありがとうございました。
AWSであれば、ECR（Amazon EC2 Container Registry）を利用することで、速攻でプライベートレジストリ使ってdockerイメージを管理できるので非常に楽ちんです。 今回やってみた感想としては、docker使うとやっぱり本番へのデプロイがすごい楽だなという印象を持ちました。ローカルの開発環境で開発して、イメージが出来上がったらすぐに本番で稼働させられるのは魅力ですね。
今回作成したコンテナのタイプ的には大きく分けて以下の二種類に分かれます。
今回は全部で13個の問題コンテナを作成して、本番環境で動作させました。ちなみにdockerの管理にはECS(Amazon EC2 Container Service)を使ってみたかったのですが、諸事情によりというか単純に検証の時間が足りなくて断念し、本番時はローカル環境で動かしていたdocker-composeを利用して動作するコンテナを管理しました。
監視には折角AWS使っているので、CloudWatchを利用しようかなとも検討したのですが、やっぱり時間が無くて今回は多少慣れていたZabbixを採用しました。 今回はコンテナの監視もしてみようかなと思い、試験的ですが以下のzabbix-docker-monitoringを利用してDockerコンテナの監視もしてみました。
後は、各問題サーバのポート稼働状況やWebサービスについてはステータスコードの状況を監視したりっていう感じですね。競技中はslackにアラート通知を流すようにして、なんか問題があれば、問題があるdockerコンテナをイメージから再作成するような運用にしていました。ちなみに本番時は想定よりも問題サーバは全然安定稼働していて、特に障害対応することもなかったので一安心でした。
今回構築した環境では、時間的にできなかったことや、色々改善点もあるなあと思っているので、今後またちょこちょこいじっていこうかなと思っています。
ぶっちゃけ費用はおいくら?
Security-JAWSでも発表しましたが、AWSの利用料はこのぐらいでした。
WorkSpaces以外にも色々と検証したので、ただ開催するだけであればもっと安く上がるんじゃないかなと思います。
まとめ
というわけで、今回私がAWSを利用して社内CTFをやってみた所感をツラツラ書いてみました。もしAWSを使ってなにかこういうイベントをやろうと思っている方の参考に少しでもなれば幸いです。 開催したイベントも参加者の方には楽しんでいただけたみたいなので満足しています。まあただ、自分達でイベント運営やってみた感想としては、環境構築を通じて色々新しいことを勉強できたりするので個人的には非常に楽しかったりするのですが、楽しい以上にやはりそれなりに色々準備が大変だったので、運営側の方々の苦労を身をもって痛感しました。今後参加者としてITイベントに参加する時は、運営の方々にはより一層の敬意を払うべきだなと思った次第ですｗ
