More than 1 year has passed since last update.

taskctf22 運営の振り返り

Posted at 2022-12-04

はじめに

今年も、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 オプションもうまく作動していなかったようでという気持ちです。