CTF редко срывается из-за одной большой ошибки. Обычно проблемы копятся: таски не проверены, инфраструктура не выдерживает старт, участники не понимают правила, а у команды нет человека, который отвечает за инциденты. Разберём, как спланировать турнир, распределить работу и провести его так, чтобы после финиша все остались довольны.
Здесь разбираем подготовку Jeopardy: от набора команды до публикации результатов. Для A/D нужны отдельные решения по инфраструктуре, чекерам и игровой механике.
Пункт 0: собираем команду мечты
На моей памяти были разные крайности: существовал AeroCTF, который успешно проводился тремя людьми, которые отвечали за всё: от коммуникации с участниками до девопса платформы и написания хардкорных гробов. Был и международный турнир, где в организацию позвали столько лишних людей, что в час ночи при застройке площадки они начали играть в паровозик. Так кто же нужен вам?
Тимлид всему голова. Не так важен опыт остальной команды разработчиков, как опыт разработки заданий человека, который будет нести ответственность за идеи заданий, тестирование тасков и финальное ревью. Это может быть как человек с опытом промышленного программирования с несколькими годами игр CTF, так и матерый разработчик тасков из другой команды — попробуйте обратиться к кому-то из русскоязычного сообщества. Вряд ли вам откажут в помощи, даже если из бюджета только голый энтузиазм. Только сэкономьте чужое время: сразу объясните, какая помощь нужна — проверить один таск или сопровождать весь контест.
Команда разработчиков. Тут всё понятно: если вы решили делать контест, скорее всего, решение было принято всей командой. Главное помните, что следует соблюдать гармоничное распределение категорий: сколько собрались делать бинарных тасков, столько нужно веба, крипты и других категорий. Соберите сетку заданий по категориям и сложности. Проверьте, что участникам вашей аудитории будет из чего выбирать. Если контест посвящён одной категории, обозначьте это в анонсе.
DevOps. Человек, которому предстоит поднять платформу и задания, обеспечить их стабильность и доступность на протяжении всего контеста и отразить DDoS, если такой последует.
Менеджер. Необязательный пункт, но гораздо легче проводить соревнования, когда есть человек, который отвечает за все внешние коммуникации: пишет анонсы, договаривается о репостах, в сотый раз пересказывает в чате правила и, по возможности, ищет спонсоров на ивент.
Как вести проект
Секрет прост — как удобнее вам и команде, так и ведите. Кто-то предпочитает Kanban-доски, списки, чек-листы, гугл-таблицы, просто обсуждение в Телеграме. Главное — все договорённости должны быть зафиксированы и вам должно быть легко менять статус у задач. Для каждого таска заведите карточку: автор, категория, предполагаемая сложность, тестировщик, ссылка на репозиторий и текущий статус.
Пункт 1: выбираем дату
Для начала представьте, сколько времени вам требуется на разработку, тестирование и деплой. Заложите к этому 1-2 недели на форс-мажоры: оставьте время на повторное тестирование после правок. Таск, который починили в ночь перед стартом, ещё никто не проверял в его окончательном виде.
Георгий Кигурадзе: Часто такое бывало с PWN-ом: когда пишешь какой-то таск, прикидывая примитив, а потом оказывается, что он не не решается в той конфигурации, которая у тебя есть. Вот бывало что за пару часов до соревнования или вообще во время проведения собирался таск с упрощением.
Если вы — опытная команда и регулярно проводите CTF, то уложитесь в 2-3 месяца. Если это ваш первый контест, смело закладывайте до полугода.
Георгий Кигурадзе: Пару раз мы отказывались от тасков уже на финальной стадии. Наверное, в идеале заданий должно быть чуть больше, чем нужно, чтобы это не было заметно. Но по факту, если таска нет, то просто отказываешься от него, и всё. Участники до соревнований не знают ведь, сколько заданий будет, если это не объявлено, а так редко кто делает.
Следующий этап: проверка даты на CTFtime. Посмотрите, какие выходные уже заняты в выбранном месяце. Если проводитесь в сезон высокой активности (осень и апрель-май) и все выходные уже заняты, старайтесь не накладываться на соревнования с высоким рейтингом, крупными призовыми или Attack/Defense, — шанс того, что кто-то предпочтёт ваше соревнование, будет стремиться к нулю.
Также не стоит выбирать месяцы с сессиями, если ваша целевая аудитория — студенты; май-июнь — если школьники. В последнем случае следите, чтобы не попасть на олимпиады, особенно те, которые позволяют поступить в вузы БВИ.
Пункт 2: разработка и тестирование. И еще раз тестирование.
Где брать идеи для тасков
Посмотрите видео Георгия Кигурадзе. Несмотря на то, что доклад посвящен преимущественно бинарным заданиям, принципы создания тасков других категорий мало чем отличаются. Прочитайте CTF Design Guidelines — рекомендации для авторов заданий и организаторов CTF, собранные с участием игроков известных команд и организаторов Google CTF.
Если собираетесь делать таски или сервисы на относительно регулярной основе, заведите себе отдельный документ для идей, которые вдохновят в течение года: ресерчи на работе или учёбе, докручивание (но не реюз!) чужого задания, 0day в какой-либо программе…
Обсудите идеи с командой и тимлидом — это будет первый этап ревью.
Приступайте к реализации
Как только будет готов прототип, можете отдавать идею таска на ревью тиммейтам, — и не забудьте подготовить собственный эксплоит. В идеале на этом этапе таск должен проверить человек, который разбирается в категории как минимум на вашем уровне.
После кросс-тестирования задание можно доделывать (подготовить файлы для раздатки, окружение для деплоя, контейнеризацию) и передавать на ревью тимлиду. Его задача — проверить полностью весь таск: от логики и до того, не забыли ли вы проверить, что не отдаете флаг участникам открытым текстом.
Помните, что правилом хорошего тона при разработке таска считается сдача его вместе с райтапом и собственным авторским эксплоитом.
Георгий Кигурадзе: Владимир Черепанов очень часто решал мои таски абсолютно не так, как я думал, или вообще через какой-то анинтендед. Потом просто переделываешь задание и закрываешь те пути, которые он нашёл.
Владимир Черепанов: На одно из соревнований я придумал очень сложный (как мне казалось) таск на крипту, где нужно было реализовать нетривиальный алгоритм атаки, код которого нигде не был опубликован. Но в дизайне таска была обидная проблема: из-за очевидного анинтендеда он решался очень просто, буквально в два действия, что и сделали участники. К сожалению, в команде разработки не было никого, кто разбирается в криптографии, поэтому эту проблему не нашли.
Готовьте платформу
После деплоя и загрузки тасков проверьте, что у каждого таска есть описание, нужный флаг, и вы отдаете участникам все файлы, которые им нужны для решения. Не забудьте проверить также, что вы не отдаете ненужные файлы: были случаи, когда случайно загружались и файлы с флагами, и полноценные эксплоиты.
До старта договоритесь, кто следит за доступностью платформы и сервисов, куда приходят уведомления о сбоях и у кого есть доступ для восстановления. Проверьте, что делать при падении задания: как его перезапустить и какие данные при этом сохранятся.
Пункт 3: приглашаем участников
Анонс и регистрацию готовьте параллельно с заданиями. К публикации должны быть определены дата, формат, аудитория, ограничения на состав команды и основные правила.
Если готовы платформа с регистрацией, правила и есть анонс на CTFtime, то можете прислать новость нам: не обязательно красивый готовый текст, мы сами его напишем по вашим тезисам.
Готовьтесь к тому, что вам несколько дней или недель придётся отвечать на однотипные вопросы про правила и регистрацию: это хорошая репетиция самого ивента, когда разработчикам заданий придется целые сутки отвечать на одинаковые вопросы по их таскам.
Виктория Лепилова: Чаще всего участники спрашивали, кто и при каких условиях может стать куратором команды. В анкете регистрации на турнир описание куратора присутствовало, но в Положении информации по данному вопросу не хватало. Поэтому мы внесли правки с более подробным описанием роли куратора. Обновили Положение не так давно, поэтому оценить результат не смогу, но пока больше вопросов по этой теме не было.
Пункт 4: проверяем турнир глазами участника
Перед стартом пройдите путь участника: зарегистрируйте команду, откройте задания, скачайте файлы, подключитесь к сервисам и сдайте тестовый флаг. Делайте это с обычной учётной записи: администратор может не заметить проблему с доступом.
Отдельно проверьте задания после деплоя. Работающий таск на ноутбуке автора ещё не означает, что участникам доступны нужные файлы и сервис с теми же настройками.
Алексей Соколовский: Я делал таск hackerchat, это задание с XSS. После деплоя на прод проблема вылезла в админском боте: почему-то на некоторых компьютерах его поведение отличалось от ожидаемого — вместо логина он получал ответ от главной страницы. Мы до сих пор не поняли, почему так получилось. Впрочем, и фронт, и бэк я писал на незнакомых ранее мне технологиях, поэтому ошибка могла быть там.
Пункт 5: проводим игру: дежурства, поддержка и спорные решения
Во время игры у каждого обращения должен быть ответственный. Иначе участник пишет в общий чат, менеджер пересылает вопрос разработчикам, разработчики обсуждают его между собой — а ответ до участника так и не доходит.
До старта договоритесь, кто разбирает технические проблемы и кто принимает решения об изменении заданий. Автор может предложить исправление, но его влияние на игру нужно обсудить: часть команд уже потратила время на старую версию.
На длинном контесте заранее распределите дежурства. При смене передавайте список открытых проблем, обещанных ответов и изменений в заданиях.
На одном из турниров платформа была недоступна из-за DDoS. Тимлид подготовил архив со статичными заданиями, чтобы участники могли продолжить решать. Но человек, который вёл канал турнира, узнал об архиве только через несколько часов.
Виктория Лепилова: Один раз во время турнира было очень много жалоб на нерабочую платформу. Это произошло из-за активной DDoS-атаки. Техническая команда тут же отреагировала и взялась за решение данной проблемы. К сожалению, точного времени возвращения борды к жизни не было известно, поэтому в чат я сообщила предполагаемое время восстановления, а дальше держала постоянный контакт с технической командой и уже сообщала в чат, как обстоят дела в процессе.
Пункт 6: завершаем турнир
До старта решите, кто отвечает за результаты, публикацию райтапов и отправку призов. После финиша команда устанет, и задачи без владельца легко останутся в состоянии «сделаем завтра». Особенно это касается сохранения скорборда: неважно, выложите ли вы его на CTFtime, сохранить его в каком-либо виде — первоочередная задача после окончания турнира.
Перед объявлением окончательных результатов разберите спорные случаи и обращения команд. Если проверка займёт время, сообщите, когда опубликуете итоги.
Для внутреннего разбора сохраните конкретные случаи: какое задание пришлось чинить, где потерялось обращение участника, почему проверка не заметила ошибку. На следующий турнир полезнее унести несколько изменений в процессе, чем общее обещание «в следующий раз начнём раньше».
