Построение полностью автономного CTF‑платформы (CTFd) в Termux с автоматическим деплоем и бэкапом данных

CTFd — популярная CTF‑платформа с веб‑интерфейсом и базой данных участников, заданий, флагов и настроек. Если требуется развернуть CTF‑песочницу или тренировочную площадку без внешних сервисов и с возможностью быстрого восстановления, удобнее всего собрать полностью автономную схему прямо в Termux: поднять контейнеризацию/сервис, обеспечить постоянство данных и автоматизировать деплой.

В этой статье мы опишем легальный подход к развертыванию CTFd в среде Termux с автоматическим деплоем и регулярным бэкапом. Материал ориентирован на владельца инфраструктуры и учебные/внутренние мероприятия.

Что потребуется

Android‑устройство с Termux.
Термис: доступ к сети (желательно стабильная Wi‑Fi сеть).
Достаточно места для базы данных и загрузок.
Возможность периодического хранения бэкапов (внутренняя карта памяти/смонтированное хранилище, либо внешний носитель).
Технические утилиты: Docker в Termux или альтернативный подход на базе локального окружения. В рамках универсальности ниже приведён вариант с контейнером, который обычно проще сопровождать.

Ограничения и правовой контекст

В РФ размещение и эксплуатация серверов должна соответствовать общему законодательству (в т.ч. требованиям к обработке персональных данных, если вы их используете, и соблюдению правил доступа/хранения). Данный гайд предназначен для запуска собственной тренировочной платформы в закрытой среде и не предполагает использование для обхода ограничений или вредоносных целей.

Архитектура автономной платформы

Рекомендуемая схема:

Контейнер с CTFd.
База данных (как отдельный контейнер либо управляемая БД в составе orchestration).
Объём для persistent storage: настройки, базы, загрузки.
Скрипт деплоя: проверка окружения, создание директорий, запуск контейнеров.
Скрипт бэкапа: регулярное архивирование persistent‑директорий (и/или дампа БД).
Планировщик: cron внутри Termux (или аналог).

Подготовка Termux

Начнём с базовой подготовки. Выполните команды последовательно.

pkg update && pkg upgrade -y

pkg install -y curl git tar tsu proot

Дальше — сетевые и файловые утилиты, а также средства для планирования.

pkg install -y cron netcat-openbsd

Если вы планируете контейнеризацию, подготовьте среду Docker (или совместимую реализацию). На разных устройствах установка может отличаться. Поэтому ниже мы оставим общий каркас под контейнерный деплой и акцент на структуре данных и автоматизации.

Каталоги persistent storage

В Termux важно заранее выделить каталоги под данные, чтобы бэкап был стабильным и повторяемым.

mkdir -p ~/ctfd/{data,db,backups,config,scripts}

Рекомендуем закреплять:

~/ctfd/data — файлы CTFd (загрузки, если используются в конфигурации).
~/ctfd/db — файлы БД (если вы храните их как volume).
~/ctfd/backups — архивы бэкапов.
~/ctfd/config — конфигурационные файлы, переменные окружения.
~/ctfd/scripts — скрипты деплоя и бэкапа.

Конфигурация CTFd: переменные и настройки

CTFd поддерживает настройку через переменные окружения и конфиги. Ниже — практический подход: вынести “секреты” и параметры в файл .env, чтобы деплой и бэкап работали одинаково после перезапусков.

Создайте файл окружения:

cat > ~/ctfd/config/ctfd.env <<'EOF'
# Примерные переменные. Подставьте значения под ваш сценарий.
# Внутренние параметры зависят от образа/версии CTFd и способа деплоя.
CTFD_HOST=0.0.0.0
CTFD_PORT=8000

# Убедитесь, что секреты (если используются) задаются корректно.
# Пример (если применимо в вашем варианте):
# CTFD_SECRET_KEY=change-me

# Данные для подключения к БД задаются согласно вашей схеме.
EOF

Если в вашем варианте деплоя используется отдельная БД-контейнеризация, параметры подключения будут зависеть от имени контейнера/сети и версии CTFd. Важно: не храните ключи в публичных репозиториях и ограничивайте доступ к файлам в ~/ctfd.

Автоматический деплой (скрипт)

Далее создадим скрипт деплоя. Он:

проверяет наличие директорий;
поднимает сеть/контейнеры;
включает постоянные volumes;
инициализирует CTFd при первом запуске (при необходимости).

Создайте файл деплоя:

cat > ~/ctfd/scripts/deploy-ctfd.sh <<'EOF'
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

BASE_DIR="$HOME/ctfd"
DATA_DIR="$BASE_DIR/data"
DB_DIR="$BASE_DIR/db"

mkdir -p "$DATA_DIR" "$DB_DIR" "$BASE_DIR/backups" "$BASE_DIR/config" "$BASE_DIR/scripts"

echo "[deploy] Using BASE_DIR=$BASE_DIR"

# Ниже — каркас для контейнерного деплоя.
# Конкретные команды зависят от того, как у вас устроен Docker в Termux.
# Смысл: поднять CTFd и БД, подключить volumes к persistent storage.

echo "[deploy] Starting CTFd stack..."

# Примерно (псевдокод-стиль): замените на реальные команды под вашу среду.
# docker network create ctfd-net || true
# docker run -d --name ctfd-db -v "$DB_DIR":/var/lib/postgresql/data ...
# docker run -d --name ctfd -p 8000:8000 -v "$DATA_DIR":/var/ctfd/uploads --env-file "$BASE_DIR/config/ctfd.env" ...

echo "[deploy] Stack started. Next: verify logs/health."
# docker logs -n 100 ctfd || true
EOF

chmod +x ~/ctfd/scripts/deploy-ctfd.sh

Запуск:

~/ctfd/scripts/deploy-ctfd.sh

Важно: поскольку Termux на разных устройствах может отличаться в плане контейнеризации, вы подстроите конкретные команды под вашу реализацию контейнеров. Однако структура persistent storage, логика автоматизации и подход к бэкапу остаются теми же.

Проверка доступности CTFd

После деплоя убедитесь, что сервис слушает порт. Если CTFd доступен только внутри локальной сети, вы можете ограничиться LAN.

Проверка порта (локально на устройстве):

netstat -tunlp 2>/dev/null | grep -E ':(8000|80|443)' || true

Проверка HTTP на локальный интерфейс:

curl -sS -o /dev/null -w "%{http_code}
" http://127.0.0.1:8000/ || true

Если CTFd не отвечает, смотрите логи контейнера/сервиса и корректность переменных окружения.

Создание локальной сети для доступа (опционально)

Если вы хотите открыть доступ участникам в пределах дома/офиса, создайте локальную сеть в рамках вашего сценария (например, через точку доступа на Android). Мы не рассматриваем обход блокировок и не используем VPN для таких целей.

Опционально, при наличии необходимости, вы можете использовать VPN исключительно для организации локального сетевого сегмента для устройств участников, если ваш сценарий требует “единый адресный план”.

Автоматический бэкап данных

Надёжный бэкап должен сохранять:

данные CTFd (uploads/файлы, если они есть отдельно);
данные БД (важнейшее);
конфигурацию и переменные окружения (чтобы восстановление было предсказуемым);
желательно — версию образов и краткий “manifest” деплоя.

Вариант 1 (самый универсальный в контейнерной схеме): архивировать persistent‑директории. Это просто и часто достаточно, если ваши volumes — это “честные” файлы на диске.

Создадим скрипт бэкапа:

cat > ~/ctfd/scripts/backup-ctfd.sh <<'EOF'
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

BASE_DIR="$HOME/ctfd"
STAMP="$(date +'%Y%m%d-%H%M%S')"
OUT_DIR="$BASE_DIR/backups"
WORK_DIR="$BASE_DIR/backups/work"
ARCHIVE="$OUT_DIR/ctfd-backup-$STAMP.tar.gz"

mkdir -p "$OUT_DIR" "$WORK_DIR"

echo "[backup] Creating archive $ARCHIVE"

# Перед архивированием можно остановить сервисы, если вы хотите абсолютной консистентности.
# Если вы не хотите останавливать, то хотя бы ограничьте риск частичных записей.
# В зависимости от вашей БД/volume подход может отличаться.

# Пример: архивируем persistent storage и конфиги.
tar -C "$BASE_DIR" 
  -czf "$ARCHIVE" 
  "data" "db" "config/ctfd.env"

# Сохраняем небольшой файл с метаданными.
echo "[backup] $(date -Is)" > "$WORK_DIR/last-backup.info"
echo "archive=$ARCHIVE" >> "$WORK_DIR/last-backup.info"

# Удаление бэкапов старше N дней (опционально).
# Например, оставим 14 дней:
find "$OUT_DIR" -type f -name 'ctfd-backup-.tar.gz' -mtime +14 -print -delete || true

echo "[backup] Done."
EOF

chmod +x ~/ctfd/scripts/backup-ctfd.sh

Тестовый запуск:

~/ctfd/scripts/backup-ctfd.sh

Проверьте, что архив создался:

ls -lah ~/ctfd/backups | tail -n 20

Вариант 2 (опционально, если вы хотите консистентность на уровне БД): делать дамп из СУБД. Этот подход обычно предпочтительнее, но требует знания конкретной БД и способа доступа из Termux/контейнера.

Планировщик задач в Termux (cron)

Настроим регулярный запуск бэкапа, например, раз в сутки в 03:30.

Откройте crontab:

crontab -e

Добавьте строку:

30 3    $HOME/ctfd/scripts/backup-ctfd.sh >> $HOME/ctfd/backups/backup.log 2>&1

Перезапустите cron в Termux (иногда требуется после смены конфигурации):

sv stop crond 2>/dev/null || true
sv start crond 2>/dev/null || true

Если у вас cron управляется иначе, ориентируйтесь на текущую реализацию пакета. В любом случае, убедитесь, что запись в backup.log появляется после назначенного времени.

Ручное восстановление из бэкапа

Восстановление должно быть простым и воспроизводимым:

Остановите сервисы CTFd/контейнеры (если используются volumes).
Распакуйте архив в ~/ctfd.
Проверьте права доступа к файлам.
Запустите деплой-скрипт.

Пример команд восстановления (аккуратно, замените файл):

cd "$HOME/ctfd"
tar -xzf "$HOME/ctfd/backups/ctfd-backup-YYYYMMDD-HHMMSS.tar.gz" -C "$HOME/ctfd"

После этого выполните:

~/ctfd/scripts/deploy-ctfd.sh

Если платформа не поднялась, проверьте логи и совместимость версии CTFd с форматом вашей БД.

Устойчивость: обновления без потери данных

Чтобы автономная платформа оставалась “живой”:

Перед обновлением делайте бэкап.
Обновляйте контейнеры/версии CTFd постепенно.
Храните конфигурацию (ctfd.env) в persistent storage и бэкапьте её вместе с данными.
Следите за дисковым пространством на устройстве.

Практические рекомендации по безопасности

Ограничьте доступ к веб‑интерфейсу только локальной сетью.
Создавайте учетные записи администраторов и управляйте ролями.
Не публикуйте секреты в открытые чаты/репозитории.
Регулярно проверяйте корректность резервных копий (делайте пробное восстановление раз в период).
Не запускайте CTFd “снаружи” без необходимости и контроля.

Типовые сценарии эксплуатации

1) Локальная тренировочная площадка: платформа доступна участникам в пределах домашней Wi‑Fi сети. Бэкап раз в сутки, деплой по одной кнопке/команде.

2) Лабораторная среда для мастер‑классов: быстрое восстановление после “экспериментов” участников.

3) Сдача поточных занятий: задания и флаги управляются в интерфейсе, а данные регулярно резервируются.

Заключение

Полностью автономная CTF‑платформа на базе CTFd в Termux — это реальный и практичный подход для внутренних CTF, тренировок и лабораторных сценариев: вы получаете независимую среду, контролируемые данные и управляемый жизненный цикл. Ключевые элементы успешного внедрения: persistent storage, автоматический деплой, плановый бэкап и понятная процедура восстановления.

Если хотите сделать развёртывание “под ключ”, подобрать стабильную схему для вашей модели Android и настроить автоматизацию деплоя/бэкапа под ваш сценарий, обращайтесь в РыбинскЛАБ: мы поможем спроектировать и внедрить решение в удобной для вас форме.