Defense only: что это такое и как в него играют
Обновлено 21.08.2026
Defense only («только защита») — формат соревнований Capture The Flag, в котором участники выступают исключительно в роли защитников и обеспечивают безопасность своих ресурсов от атак со стороны автоматики организаторов.
Ключевое отличие от классического Attack-Defense: там команды одновременно и защищаются, и нападают на соперников. В Defense only нападение вынесено за скобки — роль атакующего берут на себя автоматические скрипты (боты) организаторов, а участники сосредоточены только на защите собственной инфраструктуры. Успех зависит от одного: насколько эффективно закрываются уязвимости в сервисах и насколько стабильно эти сервисы работают на протяжении игры.
Проще говоря: командам выдают сервер с заведомо «дырявыми» приложениями, а система периодически пытается их взломать. Задача — найти и залатать уязвимости раньше, чем через них пройдёт атака, и при этом не сломать сами приложения.
Чем Defense only отличается от Attack-Defense
Attack-Defense
Две задачи одновременно
Каждая команда ломает сервисы всех остальных и защищает свои. Атаку и оборону приходится вести параллельно.
Defense only
Одна задача: оборона
Атакующую сторону берёт на себя система организаторов. Между собой участники не воюют и чужие машины не трогают.
| Критерий | Attack-Defense | Defense only |
|---|---|---|
| Кто атакует | Команды друг друга | Автоматика организаторов |
| Задачи участника | Атака и защита одновременно | Только защита |
| Работа с флагами | Обязательна: флаги крадут и сдают | Может не требоваться вовсе |
| Что определяет счёт | Атака, защита и доступность | Доступность и число закрытых уязвимостей |
| Темп игры | Задают действия соперников | Задаёт расписание проверок |
Формат считают мостиком между Task-Based и полноценным Attack-Defense. Особенности, которые из этого следуют:
- Не нужно писать эксплойты под чужие машины. Половина сложности Attack-Defense — атака соперников — здесь отсутствует, и всё внимание уходит на защиту.
- Понятная и измеримая цель. Есть конкретный набор уязвимостей, которые нужно закрыть, и наглядная статистика прогресса.
- Прикладные навыки. Чтение чужого кода, поиск уязвимостей в нём, работа с Docker и сетевыми сервисами — то же, чем занимаются в реальной работе по защите инфраструктуры.
- Другой темп. Не нужно молниеносно реагировать на действия соперников: ритм задаёт расписание проверок системы.
Как проходит игра
Общий ход участия выглядит так:
- Доступ. Организаторы выдают конфигурационный файл VPN, по которому участники подключаются к внутренней игровой сети.
- Подключение к своему серверу. Через VPN команда заходит по SSH на свой виртуальный сервер (vulnbox), где уже развёрнуты уязвимые сервисы.
- Старт. Игра идёт раундами (их также называют тиками). В каждом раунде система проверяет все сервисы всех участников.
- Анализ и защита. Изучаются исходники сервисов, ищутся заложенные уязвимости и закрываются так, чтобы не нарушить нормальную работу приложений.
- Мониторинг атак. Параллельно отслеживается, как система обращается к сервисам, — это показывает, какие уязвимости под ударом.
- Отслеживание результата. Прогресс и очки видны в реальном времени на табло (Scoreboard) в клиентской части платформы.
Базовая инфраструктура
Vulnbox — сервер команды
Vulnbox (от vulnerable box — «уязвимая машина») — отдельный виртуальный сервер, который выдаётся каждой команде. Именно на нём расположены сервисы, которые предстоит защищать.
На старте все находятся в абсолютно равных условиях: на каждом vulnbox развёрнуты одни и те же исходники сервисов с одинаковым набором заранее заложенных уязвимостей — без исключений для кого-либо. Операционная система — на усмотрение организаторов, но чаще всего это Ubuntu или Debian.
Сервисы: бинарные и веб
Сервис — отдельное приложение, которое выполняет определённые функции и работает по сети, то есть к нему можно обратиться удалённо. Именно в сервисах спрятаны уязвимости, которые нужно найти и закрыть. Сервисы бывают двух основных типов:
- бинарные — скомпилированные программы; уязвимости в них чаще связаны с работой с памятью и низкоуровневой логикой;
- веб-сервисы — приложения на веб-основе, сайты и API; здесь встречаются типичные для веба классы уязвимостей.
Важный нюанс: закрывая уязвимость, нельзя ломать легитимную функциональность. Сервис должен продолжать корректно работать и отвечать на проверки — иначе команда теряет очки за его недоступность.
Docker и контейнеры
Чаще всего сервисы упаковываются и запускаются с помощью Docker. Если объяснять просто, Docker — это технология, которая «упаковывает» приложение вместе со всеми его зависимостями в изолированную коробку — контейнер. Такой контейнер запускается одинаково на любом компьютере, что снимает классическую проблему «на моей машине работает, а на другой — нет».
Docker используется ради удобства развёртывания и устранения проблем совместимости и зависимостей. Рядом с ним почти всегда идёт Docker Compose — инструмент, который позволяет запускать несколько связанных контейнеров сразу, описав их в одном файле. Базовая работа с Docker и Docker Compose — обязательная часть формата: без неё не получится ни закрыть уязвимость, ни перезапустить сервис.
SSH и VPN
- SSH (Secure Shell) — способ безопасно подключиться к удалённому серверу и управлять им через командную строку. Участник «заходит» на свой vulnbox и работает в его терминале так, будто сервер стоит перед ним.
- VPN (Virtual Private Network) — защищённый туннель между машиной участника и игровой сетью соревнования. Организаторы дают конфигурационный файл; по нему участник попадает во внутреннюю сеть, где становятся доступны vulnbox и игровая платформа.
Чек-система: как проверяют сервисы
За отслеживание прогресса и определение того, работают ли сервисы, отвечает специальная чек-система. Она периодически выполняет все необходимые проверки сервисов у всех команд, фиксирует результаты и на их основе формирует как общую статистику по турниру, так и детальную по каждой отдельной команде.
Checker
Checker (чекер) — скрипт, который проверяет корректность работы сервиса, имитируя действия обычного пользователя. Один чекер обычно проверяет только часть функционала конкретного сервиса, поэтому на один сервис может приходиться несколько чекеров — их количество зависит от того, сколько у сервиса функциональных блоков.
Ключевое правило формата: система атакует сервис только тогда, когда его статус — OK. Пока сервис не проходит проверки, боты его не трогают, но и очков за него команда не получает.
Sploit (Bot)
Sploit — скрипт, противоположный чекеру по назначению. Если чекер имитирует нормальные действия пользователя, то sploit атакует уязвимый сервис: демонстрирует уязвимость и получает несанкционированный доступ к цели. Поскольку в Defense only роль атакующего берёт на себя сама система, такие скрипты называют ещё ботами.
Раунды (тики)
Игра идёт раундами, которые также называют тиками. В каждом раунде система заново прогоняет проверки всех сервисов и, если сервис в статусе OK, проводит по нему атаки. Именно по раундам считается статистика и начисляются очки.
Статусы сервисов
Результат проверки сервиса система выражает статусом:
- UNKNOWN — состояние сервиса неизвестно. Обычно так бывает до старта игры.
- OK — проверяющие скрипты подтверждают корректную работу: тесты функционала проходят и возвращают ожидаемые результаты. Только в этом статусе по сервису идут атаки.
- CORRUPT — проверяющие скрипты не могут получить данные пользователя. Например, не удаётся вытащить данные из его профиля.
- MUMBLE — часть функционала работает некорректно. Например, не срабатывает регистрация пользователя.
- DOWN — проверяющие скрипты не могут получить доступ к сервису по сети: сервис недоступен.
- CHECKER ERROR — чекер вернул внутреннюю ошибку, не связанную непосредственно с проверкой функциональности сервиса.
OK
Все проверки пройдены: сервис отвечает и отдаёт ровно то, что должен.
Раунд засчитан в доступность. Только в этом статусе сервис приносит очки.
MUMBLE
Сервис отвечает, но работает неправильно: часть штатных функций сломана.
Раунд не засчитан. Типичная причина — патч, задевший легитимную логику.
CORRUPT
Сервис работает, но теряет или портит данные: положенное значение не читается обратно.
Раунд не засчитан: данные пользователя недоступны.
DOWN
Сервис недоступен по сети: упал, завис или закрыт наглухо.
Раунд не засчитан. Закрытый от атак сервис теряет очки так же, как взломанный.
Набор статусов зависит от проверяющей системы. Часто встречаются ещё два: UNKNOWN — состояние ещё неизвестно (обычно до старта игры) и CHECKER ERROR — сбой самого проверяющего скрипта, не связанный с работой сервиса.
Целевое состояние для команды — держать все свои сервисы в статусе OK как можно дольше, при этом постепенно закрывая уязвимости.
Как начисляются очки
Баллы начисляются за два фактора: стабильность сервисов и работу по устранению уязвимостей.
Шаг 1 · доступность
SLA — доля раундов, где сервис был в статусе OK
20 из 24 раундов OK → SLA = 83%
Каждый раунд пересчитывает показатель: один упавший тик стоит доли процента, серия — заметной части итога.
Шаг 2 · очки
S = Sпрошлый раунд + SLA × закрытые уязвимости − штраф × всего уязвимостей
Работоспособность
Чем выше SLA, тем дороже каждая закрытая уязвимость.
Закрытые уязвимости
Основной источник роста балла: система перестаёт пробивать сервис.
Открытые уязвимости
Каждая незакрытая дыра списывает часть очков каждый раунд.
Точные коэффициенты зависят от проверяющей системы конкретного соревнования, но логика везде одна: выгодно и держать сервисы живыми, и закрывать уязвимости.
SLA
Service Level Agreement (SLA) — показатель жизнеспособности сервиса. В общем виде это доля прошедших раундов, которые сервис провёл в статусе OK, относительно общего числа раундов. Чем стабильнее работает сервис, тем выше его SLA.
На практике SLA пересчитывается каждый раунд с учётом накопленного значения:
SLA_новый = ( ( SLA_текущий · (R − 1) + R_результат ) / R ) × 100%где SLA_новый — новое значение SLA в процентах, SLA_текущий — текущее значение в процентах, R — номер текущего раунда, R_результат — результат текущего раунда (OK или другой статус).
Score
Итоговый балл учитывает и стабильность сервиса, и число закрытых уязвимостей, и штраф за оставшиеся открытыми:
S_новый = S_прошлый + ( SLA_новый · V_закрытые ) − ( L · V_всего )где S_новый — новый балл, S_прошлый — предыдущий рассчитанный балл, SLA_новый — новое значение SLA в процентах, V_закрытые — количество устранённых уязвимостей, L — штраф за наличие уязвимостей, V_всего — общее количество уязвимостей в сервисе.
Логика читается интуитивно: чем выше SLA и чем больше уязвимостей закрыто, тем выше балл; за каждую всё ещё открытую уязвимость начисляется штраф. Поэтому в формате одинаково значимо и держать сервисы работоспособными, и активно устранять уязвимости. Конкретные коэффициенты зависят от чек-системы соревнования.
Как выглядит защита сервиса
Защита в этом формате складывается из трёх повторяющихся действий.
Чтение исходников. Сервисы выдаются вместе с кодом, и заложенные уязвимости ищут именно в нём: необработанный пользовательский ввод, доступ к чужим объектам, ошибки логики, небезопасная работа с памятью.
Патч без потери функциональности. Уязвимость закрывается правкой кода или конфигурации, после чего сервис пересобирается и перезапускается. Проверка чекера при этом должна продолжать проходить: сломанная штатная функция даёт статус MUMBLE или CORRUPT, и раунд не идёт в зачёт доступности.
Мониторинг трафика. Чтобы понимать, какие именно уязвимости под ударом, на vulnbox настраивают анализ сетевого трафика: он показывает, как система обращается к сервисам и какие запросы приходят перед срабатыванием атаки. Готовые системы мониторинга для этого пришли из Attack-Defense — изначально они создавались под него, но применимы и здесь. Оговорка: многие такие системы завязаны на поиск флагов в трафике, а в Defense-формате работа с флагами может не требоваться вовсе — полезной остаётся именно возможность видеть характер обращений к сервису.
Словарь
- CTF (Capture The Flag) — соревнования по кибербезопасности, где нужно захватывать или защищать «флаги».
- Флаг — секретная строка-метка, доказательство решённой задачи.
- Task-Based (Jeopardy) — формат CTF с набором независимых заданий по категориям.
- Attack-Defense (AD) — формат, где команды одновременно защищают свои сервисы и атакуют чужие.
- Defense only — формат, где команды только защищаются от автоматических атак системы.
- Vulnbox — уязвимый виртуальный сервер, выданный команде.
- Сервис — сетевое приложение с заложенными уязвимостями, которое нужно защищать.
- Docker / контейнер — технология упаковки приложения с зависимостями в изолированную среду.
- Docker Compose — инструмент запуска нескольких контейнеров по единому описанию.
- SSH — безопасное удалённое управление сервером через командную строку.
- VPN — защищённый туннель до игровой сети.
- Чек-система — платформа, которая проверяет сервисы, проводит атаки и считает статистику.
- Checker (чекер) — скрипт, проверяющий корректность работы сервиса.
- Sploit / Bot — скрипт, атакующий уязвимый сервис.
- Раунд (тик) — игровой цикл, в рамках которого проходят проверки и атаки.
- Статус сервиса — результат проверки: OK, DOWN, MUMBLE, CORRUPT, UNKNOWN, CHECKER ERROR.
- SLA — показатель жизнеспособности сервиса, доля раундов в статусе OK.
- Score — итоговое количество очков команды.
- Scoreboard — табло с прогрессом и статистикой команд.
Частые вопросы
Чем Defense only отличается от обычного CTF? «Обычный» CTF чаще всего означает формат Task-Based — набор независимых заданий, которые решают поодиночке. Defense only — командный формат про защиту инфраструктуры: команда обороняет сервер с уязвимыми сервисами от автоматических атак.
Нужно ли атаковать другие команды? Нет. В этом и суть формата: участники только защищаются. Атаки проводит система организаторов (боты), а не другие участники.
Нужно ли уметь программировать? Базовое понимание кода очень желательно — чтобы читать исходники сервисов и находить в них уязвимости. Глубокие навыки разработки при этом не обязательны.
Что такое флаг и нужно ли с ним работать в Defense only? Флаг — секретная строка-метка, доказательство решённой задачи. В части Defense-платформ работа с флагами не требуется вовсе: важны стабильность сервисов и число закрытых уязвимостей.
На какой операционной системе работает vulnbox? Это решают организаторы, но чаще всего используются Ubuntu или Debian.
Почему по сервису вдруг перестали идти атаки? Потому что атаки идут только по сервисам в статусе OK. Если сервис не проходит проверку, система его не трогает — но и очки за доступность в этом раунде не начисляются.
Что означают статусы OK, DOWN, MUMBLE, CORRUPT? Это результаты проверок сервиса: OK — всё работает; DOWN — сервис недоступен по сети; MUMBLE — часть функций сломана; CORRUPT — не удаётся получить данные; UNKNOWN — состояние неизвестно; CHECKER ERROR — ошибка самого чекера. Подробный разбор — в разделе «Статусы сервисов».