Перейти к содержанию

Getting started

От свежего клона до первых результатов скана в графе — примерно десять минут. Umbryx — self-hosted: всё описанное ниже выполняется на ваших собственных машинах. По умолчанию ничего их не покидает — но включаемые вами интеграции (уведомления Telegram/Slack, внешний AI-провайдер, heartbeat лицензии EE на update.umbryx.pro) отправляют ровно то, чему нужны для работы; каждая опциональна и описана на своей странице.

Почему команды выбирают Umbryx

То, чего ни один другой инструмент в этой нише не предлагает в одном продукте:

  • Операции выполняются из платформы — а не логируются в неё. Сканы, валидация учётных данных и C2-таскинг исполняются через ваши атакующие машины по SSH. Umbryx не наблюдает за вашим терминалом — он ведёт engagement.
  • Вывод инструментов становится состоянием — автоматически. Запуск nmap создаёт хосты и порты. Валидированные учётные данные рисуют ребро доступа на графе. Хэш, найденный в выводе задания, попадает в Loot — без copy-paste и без таблиц.
  • Граф — это то, что вы знаете прямо сейчас. Карта сети, пути атак и BloodHound-стильное разделение на тиры перестраиваются из операционных данных — а не из диаграммы, которую вы поддерживаете вручную.
  • Доказательства с защищённой цепочкой владения (chain of custody). Каждый вывод задания, элемент loot и просмотр секрета фиксируются в аудите — кто и когда; журнал аудита поддерживает HMAC-отпечатки и mirror, доступный только на добавление.
  • С секретами обращаются как с секретами. Креды зашифрованы на уровне проекта (иерархия DEK/Fernet), их просмотр — отдельное, аудируемое разрешение — viewer действительно не может увидеть plaintext.
  • Плейбуки вместо работы по памяти. Цепочка от разведки до латерального движения, которую вы перепечатываете каждый engagement, становится запускаемым, планируемым плейбуком с fan-out по хостам.
  • От scope до decommission в одном месте. Контроль ROE, конструктор отчётов, собираемый из живых данных проекта, и (в Enterprise) демонтаж с decommission-отчётом, доказывающим, что каждый хост, ключ и DNS-запись уничтожены.

1. Требования

  • Docker + Docker Compose (v2)
  • 2 CPU / 4 ГБ RAM — практическая рекомендация для небольшой команды (минимум — 2 ГБ, см. «Что такое Umbryx»)
  • Linux-машина, доступная на порту по вашему выбору (по умолчанию 3000)

Umbryx не запускает сканы сам — он управляет атакующей машиной, контролируемой вами, по SSH (подробнее в шаге 5). Community Edition никогда не разворачивает инфраструктуру за вас — приносите свой VPS/VM/контейнер.

2. Настройка и запуск

cp .env.example .env

Отредактируйте .env — значения, важные в первый день:

Переменная Что задать
DB_PASSWORD стойкий пароль для внутреннего PostgreSQL
JWT_SECRET openssl rand -hex 32
ENCRYPTION_KEY Fernet-ключ — python3 -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode())"
ADMIN_PASSWORD пароль первого админского аккаунта
PORT публикуемый HTTP-порт (по умолчанию 3000)

С APP_ENV=production бэкенд отказывается стартовать без валидного ENCRYPTION_KEY — задайте его явно, не полагайтесь на автогенерацию.

docker compose up -d --build

Автоматизированный путь: install.sh

Не хочется править .env вручную? Установщик делает всё одной командой:

./install.sh

Это интерактивный мастер (текстовый UI; на минимальном хосте переключается на простые запросы), который:

  • спрашивает имя/пользователя базы и генерирует стойкий пароль, учётные данные администратора и публикуемый порт
  • генерирует все секреты (JWT_SECRET, корректный Fernet-ключ ENCRYPTION_KEY, WEBHOOK_HMAC_SECRET) — без слабых значений по умолчанию
  • предлагает выбор окружения (production ужесточает проверки ENCRYPTION_KEY), а в production — четыре транспортных режима: обычный HTTP (без TLS), TLS на внешнем прокси, самоподписанный сертификат прямо на nginx платформы или ваш сертификат (пишет compose-override и COMPOSE_FILE сам)
  • в airgap-бандле проверяет контрольные суммы образов и загружает их локально (интернет не нужен)
  • собирает образы, поднимает стек и ждёт health-check бэкенда, после чего печатает URL и учётные данные администратора

Для автоматизации: UMBRYX_INSTALL_NO_TUI=1 переводит мастер в plain-text режим, а --dry-run печатает все изменяющие команды вместо выполнения — удобно посмотреть, что режим сделает на реальном хосте.

Обновление уже установленного экземпляра — тоже одна команда: ./update.sh (резервные копии .env и дампа БД с отметками времени, :rollback-теги образов, перезапуск с health-check — см. Обслуживание).

3. Первый вход

Откройте http://<host>:3000. На свежей базе экран входа предложит создать аккаунт администратора (заранее задайте SETUP_TOKEN в .env, если хотите закрыть экран первого запуска). Войдите как админ.

Вход

4. Создайте проект

Проекты содержат всё: scope, хосты, учётные данные, findings, loot, отчёты.

  1. Сайдбар → New project, задайте имя
  2. Добавьте scope для engagement (CIDR/хосты) в разделе Scope — сканы остаются внутри него
  3. Пригласите коллег в разделе Members с проектной ролью (owner, admin, editor, operator, analyst, viewer, … — см. Контроль доступа). Community Edition допускает до 5 участников и хранит 90-дневный журнал аудита.

Вы автоматически становитесь owner проекта.

5. Подключите свою атакующую машину

Сканы и инструменты выполняются на контролируемой вами машине, по SSH — платформа никогда не исполняет инструменты локально.

  1. Подготовьте машину: SSH-доступность и установленные инструменты, которыми планируете пользоваться (nmap, nuclei, netexec, httpx, ffuf, impacket, …)
  2. В Umbryx: Infra → Connections → добавить SSH executor-цель
  3. Заполните хост, порт, учётные данные (пароль или ключ) — опциональные jump-host и SOCKS-прокси настраиваются на той же панели

Креды шифруются at rest. Используйте выделенный низкопривилегированный аккаунт на атакующей машине; всё, что платформа там запускает, атрибутируется в журнале аудита.

6. Запустите первый скан

  1. Recon → Scans → New scan → nmap
  2. Цель: хост/CIDR из вашего scope, выберите профиль интенсивности
  3. Запуск — задание появляется в Jobs с живым выводом

По завершении результат — не просто лог: хосты и открытые порты попадают в Hosts, рёбра появляются на Network map, а таймлайн фиксирует, кто что запускал.

Дальше обычный поток:

  • Credentials → Add или импорт из вывода инструментов; валидируйте их на хостах (SMB/WinRM/SSH/…) — успешные валидации рисуют рёбра доступа на графе
  • Findings — черновики из доказательств; ревьюеры могут их апрувить
  • Report — соберите клиентский документ из реальных данных проекта

7. Поддерживайте актуальность

Поддерживаемый путь — одна команда ./update.sh (резервные копии с меткой времени, теги отката, рестарт с health-check). Быстрая альтернатива для тех, кто понимает, зачем пропускает страховку:

git pull
docker compose up -d --build

Релизы, трансформирующие существующие данные, помечаются ⚠ DATA в release notes — создавайте резервную копию data/ и базы данных перед обновлением до таких версий.

Куда дальше