はじめに

今年も、2022/12/03に初心者から中級者向けにtaskctfを開催しました。ご参加いただいた皆さん、ありがとうございました！
https://ctf.task4233.dev/scoreboard

taskctf22用の記事は2つあり、本記事は運営の振り返りのための記事です。

作問者writeupはこちらをご覧ください。

この振り返りでは、開催までにやったこと、開催直後にやったこと、障害が起きた時の対応、開催後にやったことの4項目を紹介します。

開催までにやったこと

開催までには、

作問
スコアサーバの用意
開催の告知ツイート
問題サーバの用意
をやりました。

作問(2ヶ月前〜)

アイデアはGitHubのIssueに書き出していました。その一部を選択して作問しました。1問あたり、調査から作問終了までに1週間くらいかかっていたと思います。

1ヶ月くらいあれば終わると高を括っていましたが、他の作業で実際に作業できる時間は少なく、後述するように本番中も作問していました。

今年はSECCON Beginners CTFやTsukuCTFにも問題提供をしたりしたのも要因の1つかもしれません。

そのため、来年は4ヶ月前くらいから1ヶ月に2問程度のペースで作れれば良いかなと思っています。(できるのか？)

スコアサーバの用意(1ヶ月前〜)

スコアサーバは例年通りOSSでコンテストページをサーブできるCTFdを利用しました。

例年はポチポチで問題を追加していたのですが、今回はCTFdをCLIベースで一括管理できるctfcliを一部利用しました。

ctfcliは以下のようなフォーマットのYAMLファイルを書きました。
https://github.com/CTFd/ctfcli/blob/fcaf51a422dbc54bb7ced18964774502801316c6/ctfcli/spec/challenge-example.yml

以下のシェルスクリプトで全てのYAMLをinstallできます。

for file in `find . -name "challenge.y*ml"`; do
    echo ${file};
    ctf challenge install ${file};
        if [ $? -ne 0 ]; then
            exit 1;
        fi;
done

同様にして、以下のCIで配布ファイルにFlagが紛れ込んでいないかも確認していました。便利ですね。

name: ci

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  lint:
    name: lint challenge.yaml
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.10"]
    steps:
      - uses: actions/checkout@v3
      - name: setup python
        uses: actions/setup-python@v4
        with:
          python-version: ${{ matrix.python-version }}
      - name: install dependencies
        run: |
          python -m pip install ctfcli
      - name: lint
        run: |
          sh -c 'for file in `find . -name "challenge.y*ml"`; do echo ${file}; ctf challenge lint ${file}; if [ $? -ne 0 ]; then exit 1; fi; done'

検知された時の図

開催の告知ツイート(2週間前)

以下のツイートをしました。

問題サーバの用意(1日前〜)

問題サーバは例年通りGCEインスタンスに乗せていました。今年はサーバ負荷が高くなりそうだったため、e2-standard-2(2 vCPUs, 8GB Memory)に乗せていました。

結果として、CPU使用率も最大10%くらいでしたし、もう1つ下のインスタンスでも良かったかなと思っています。

開催中にやったこと

作問(？)

作問が間に合わなかったので、本番中も作問していました。

障害対応で時間が取れず、集中して作問できなかったため、来年以降は本番中に作問するのはやめようと思いました。

提出されたFlagの監視

登録されたFlagに問題がないか
ほぼ正解なのに失敗しているようなFlagがないか

を確認していました。

実際に、douroでほぼ正解なのに精度が厳しすぎるせいでIncorrectになっている提出が多かったので、要求する精度を落とす対応をしました。

問題修正とアナウンス

このdouroのような問題修正をした後には、問題の修正時間を問題に記載したり、アナウンスをしたりするようにしました。
私はCTF等でのサイレント修正は最悪だと思っているので、今回はするようにしました。

問題サーバの外形監視

対象サーバが生きているか確認するために、cURLで対象サーバが生きていることを確認するためのシェルスクリプトを書いて、定期的に実行していました。

障害対応

今回は anti_detection と shellgei で障害が発生したため、対応を行いました。

手順としては、上から順に

障害が再現するか確認
ユーザへの連絡
原因究明
方針決定
復旧対応
ユーザへの連絡
復旧後の監視
を行いました。

今回の問題はDockerfileの不備によるものだったのですが、ローカル環境では再現しない不備で、ずっと唸っていました。
この理由はDockerImageをビルドするときに、オプションを指定しないとキャッシュが利用されていたためです。
Docker Composeを利用してビルドする際はキャッシュを利用する設定なのでキャッシュを利用しないようにしたかったのですが、Docker Compose Pluginには --no-cache の設定がなく、 --force-recreate オプションもうまく作動していなかったようでという気持ちです。

結果的に、1つ1つのDockerfileをBuildした時に、ローカルでうまく作動しないことに気づきました。その後、Docker Composeでビルドしていた各問題を別々のprojectオプションで起動し直し、修正が他の環境に影響しないように隔離してから、ゆっくりと対処を行いました。

最終的に、修正後に同じような障害は起きなくなったので良かったと思っています。

全完者のお祝いツイート

全完した人のお祝いツイートをしました。

開催後にやったこと

アンケート結果の確認

こちらのアンケートを実施しました。ご回答いただきありがとうございました。回答数は2022/12/04時点で47で35%でした。

結果

今回のCTFは楽しめましたか(1:楽しめなかった/4:楽しめた)

今回のCTFの難易度についてどう思いましたか(1:簡単だった/4:難しかった)

今回のCTFの開催時間についてどう思いましたか(1:短かった/4:長かった)

問題数はどうでしたか(1:少なかった/4:多かった)

ご指摘いただいた部分は、来年また開催できる場合は参考にさせていただこうと思います。

writeupの確認

確認しました。確認できたものは以下のwriteupに記載しましたが、漏れているものがあれば教えてください。

おわりに

参加してくださった方々はありがとうございました。来年も開催できるか分かりませんが、開催できたら良いなと思っています。