チーム内でCTFをやってみた

この記事は レバテック開発部 Advent Calendar 2025 5日目の記事です。

レバテック開発部の松浪です。
先日、個人戦形式のCTFを所属するチーム内で実施してみました。

この記事では、

• なぜCTFをやってみたのか？
• CTFをやってみてどうだったか？

を振り返りも兼ねて記載します。
もし、CTFを社内でやってみたいなぁ、、とお考えの方がいたら、少しでも参考になれば幸いです。

なぜCTFをやってみたのか？

セキュリティに関わる身として、単純にCTFに興味・関心があったから...と言うのもあるのですが、
セキュリティ関連の勉強会にてCTFを体験し、そこで使用されていたCTFdというツールを知ったのがきっかけです。

登録参加者数が958人...なかなか大盛況ですね。
それだけCTFに興味を持っている人が多いということでしょうね。
開催当時はちょっとゴタゴタがありましたが、CTFを経験する良い機会でした。

CTFdのインストールも結構簡単（らしい）と伺ったので、ならば自分でもCTFを開催してみたいなという思いに至りました。
また、レバテック開発部では勉強会が盛んに行われており、自分でも何か勉強会を企画してみたいという思いも少しありました。
ただ、いきなり部全体に向けてCTFを開催するのは勇気がいるので （小心者）、まずは所属するチーム(自分を含めて計6人)で小さく始めてみることにしました。

CTFdとは

CTFdは、情報セキュリティの知識を競う競技「CTF (Capture The Flag)」が実施できる環境を構築・運営するためのプラットフォームです。

https://ctfd.io/

SaaS版は有料ですがOSSとして公開されていますので、今回はOSS版を使いました。

https://github.com/CTFd/CTFd

準備

AWSにCTFの環境を構築する

CTFdをAWS上で構築するに当たって低コストでシンプルに構築できることを心がけました。
と言うのも、業務の合間に1人で構築する都合上、あまり時間をかけたくなかったからです。
その上で、「HTTPS対応されていること」と「社内からのみアクセスできること」は最低限、対応するようにしました。（まぁセキュリティの競技なのでね...）

なので、インフラ構成は非常にシンプルで、ALBとEC2という単純な構成にしました。

なぜ、ECS(Fargate)ではなくEC2にDockerを直接インストールしたかと言うと、

• OSSとして公開されている公式のdocker-compose.ymlをほぼ変更せずにそのまま利用できる
• sshでサーバにログインしてdockerコマンド（docker compose ps や docker compose logs など）を叩いたり、vi で設定ファイルを直接編集したりとデバッグがしやすい

という理由です。
数百人が参加する大規模なCTFならECSの方がいいと思いますが、小規模ならEC2で十分でしょう。

AWSの詳細な設定や実装は割愛しますが、時間があれば別の機会に「チーム内でCTFをやってみた（AWS環境構築編）」と題して書こうと思います。（たぶん）

問題を作成する

CTFdをEC2上で起動できました。

次は問題を作成する必要があります。
作成するに当たって意識した点は「CTFらしい王道問題」と「業務で利用している技術を扱う」の2点です。

CTFらしい王道問題

CTFでは馴染みのある暗号化された文字列を解読する問題や、隠された文字列を探し出す問題などを作成しました。
CTFを体験してもらう意味もありますが、個人的には問題を通して暗号化・ハッシュ化・エンコードの違いなどを体験してもらう狙いがありました。

例えば、次のような問題を作成しました。

問題例

次の絵文字をデコードして得られる文字は？

🐺👋🐽🐗🐼👥👚👦👛👜🐗🐺👟👘👣👣👜👥👞👜🐘🐘

正解

CTF Encode Challenge!!

業務で利用している技術を扱う

DockerやGitHub Action、AWSなど、普段の業務で触れるツールや技術の問題をいくつか作成しました。
日々の業務に直結する問題...!!とまでは言わずとも、少なくとも全く触れない技術よりかはタメになりそうな問題を心がけました。

あとは、弊社で利用しているNew RelicのSecurity RXやSonarQube（OSS版）が実際に検出してくれた脆弱性情報を元ネタにして問題を作成しました。

例えば、次のような問題を作成しました。

問題例

EC2で稼働しているWebアプリケーションにhttpsとsshでアクセスを可能にしたい。
接続経路が「インターネット→ALB→EC2」の場合、EC2インスタンス用のセキュリティグループに設定しなくてよいルールはどれ？

1. port:80のingressルール
2. port:443のingressルール
3. port:22のingressルール
4. port:0のegressルール

正解

2. port:443のingressルール

CTFをやってみてどうだったか？

個人戦のクイズ形式で制限時間は30分として、実際にCTFをチーム内でやってみました。

Keep（良かったこと）

思いの外、「面白かった」という意見が多くて、準備した側としてはとてもホッとしました。
Google Meetを繋ぎながら実施していたのですが、参加者（チームのみんな）が「わからねー」とか「ミスったー」とか、コメントでも反応してくれたのが良かったです。

あと、どの問題がどれくらい回答されているか、管理者側の画面からリアルタイムで確認できるので、CTFdの使い勝手の良さや利便性を改めて実感しました。

問題ごとの解答率

解答した回数と間違えた回数

Problem（反省点）

やってみて一番の改善点に感じたのは生成AIの利用に関するルールを明確化です。
もっと具体的で人の解釈によってブレないルールを設けておくべきでした。

今回、「AIに問題文やコードを読ませて回答を生成させる」ことはNGというルールにしたのですが、これだと生成AIの利用自体がNGなのか、 GoogleのAIモードはOKなのか、判断が分かれてしまいました。

また、CTFの問題を通して、「何を知ってもらいたいか」をはっきりさせておくことも大切だと思いました。
やはり、あくまでも勉強会の一種として開催するならば、学びを与える必要があります。

Try（次やるとしたら）

解説が欲しいと言う意見が出たので、解説も前もって準備しておけるとよかったなと思います。

まとめ

CTFをやってみて最も学びを得たのはある意味、自分自身かもしれません。
CTFdをAWS上に構築するには多少のインフラ知識は必要ですし、セキュリティの問題を作成するにはその問題で扱う技術について調べる必要があります。
結果として、インプットとアウトプットが両立できたように思います。

そう考えると世の中の勉強会は視聴者として参加する（インプット）よりも、登壇者として参加したり参加後にブログを書いたり学んだことを試したりするなど（＋アウトプット）すると、より学びが得られそうですね。

CTFdはAWS上に比較的簡単に構築できますし、皆さんもCTFの問題を『作る側』に回ってみませんか？