Что это на самом деле делает

• Собирает телеметрию с агентов Windows и Linux по одному TCP-каналу. События SIEM, оповещения, FIM, пакеты, сетевые подключения, открытые порты, активность Docker, кадры экрана.

• Обнаруживает с помощью правил Sigma на конечной точке. 23 правила, покрывающих 23 техники MITRE ATT&CK, поставляются в conf/sigma/builtin/; рядом можно размещать сообщества наборы правил. Sigma сопоставляет именованные поля, а не текст, поэтому Image|endswith: '\vssadmin.exe' нельзя обойти словом «vssadmin», встречающимся в несвязанном сообщении — а CommandLine|utf16le|base64offset|contains читает внутри полезной нагрузки base64 -EncodedCommand, где в открытой командной строке виден только обёрточный код. По результатам оценки на корпусе: 9 из 10 атак ловятся одним лишь Sigma, 0 из 9 жёстких негативов ложно помечаются. Этот слой детерминирован и продолжает работать, когда модель недоступна.

• Коррелирует события между собой, чего не может сделать ни одно правило для отдельного события. Один неудачный вход в систему — обычное дело; пять учётных записей, терпящих неудачу из одного источника за сорок секунд — это password spray, и просмотр любого из этих пяти событий никогда не покажет вам этого. Покрывает spray, brute force, успешный вход после повторных неудач, а также всплески создания учётных записей или установки служб — на обеих платформах, по идентификаторам событий Windows или по разобранным строкам auth.log.

  Работает с двух точек обзора, потому что они видят разные атаки. На каждом хосте на агенте, где атака против одной машины видна полностью. И между хостами на пути приёма данных, где spray, прошедший по одной неудаче за раз по пятидесяти машинам, становится видимым — ни один агент не видит более одного события, и это более компетентная атака, поскольку широкий и неглубокий spray остаётся ниже как порогов блокировки на учётную запись, так и порогов на хост.

  Общее покрытие с Sigma: 27 техник. Каждое окно срабатывает один раз, а не один раз на событие, и каждый счётчик ограничен — счётчик, привязанный к имени пользователя, предоставленному атакующим, — это примитив исчерпания памяти, а не обнаружение.

• Сопоставляет обнаружения с MITRE ATT&CK на основе самих правил. Правила содержат tags: attack.t1490, поэтому нет вручную поддерживаемой таблицы сопоставлений, которая могла бы устареть. Страница покрытия разделяет три состояния, которые скрыл бы один «процент покрытия»: покрыто и замечено, покрыто и тихо, и вообще не покрыто — последнее — единственное, где тишина консоли ничего не значит.

• Проводит триаж каждого события с помощью локальной LLM. Три воркера работают параллельно: один следит за каждым входящим событием в реальном времени, один выполняет управляемые оператором глубокие сканирования, а один решает, следует ли предпринять защитное действие (BLOCK_IP, ISOLATE_HOST, KILL_PROCESS и т. д.).

• Теневой режим для защитного воркера. Включите AI_SHADOW_MODE=1 — и каждое автономное решение будет отправляться на утверждение человеку в SOAR Hub вместо выполнения. Полезно для настройки модели на реальном трафике, прежде чем позволить ей действовать самостоятельно.

• Индексирует всё в OpenSearch, чтобы вы могли искать по своему флоту с помощью нечётких / точных / начинающихся-с запросов из одного места.

• Запускает плейбуки SOAR, созданные в небольшом визуальном редакторе с многошаговым отслеживанием результатов по узлам; могут запускаться вручную или по решению ИИ.

• Сканирует уязвимости установленных пакетов каждого агента по OSV (онлайн или через внутреннее зеркало).

• Подтягивает каналы threat-intel с abuse.ch (Feodo, ThreatFox, URLhaus) в локальную таблицу индикаторов, с очисткой устаревших данных и переключателем для автономного режима.

• Проверяет конфигурации агентов перед их отправкой. Разбор YAML, структурная форма и компиляция регулярных выражений — недопустимое регулярное выражение — это валидный YAML, который молча отключает содержащее его правило.

• Встроенный удалённый рабочий стол через потоковую передачу JPEG по WebSocket, без отдельной установки VNC на конечной точке.

Как это выглядит

Боковая панель группирует всё в три раздела: телеметрия (панель управления, агенты, оповещения, активы, FIM, журналы, ИИ), автоматизация реагирования (защитные действия, плейбуки, правила автоматизации) и администрирование.

Представление агента

У каждого зарегистрированного агента есть своя страница с двенадцатью вкладками. Обзор показывает живые измерители ресурсов, самые последние журналы SIEM, метаданные агента и сводку угроз:

Оповещения — это всё, что уже пометили собственные правила корреляции агента. Окрашены по серьёзности, фильтруются, ищутся:

Вкладка AI Analysis — это сторона локальной LLM, обращённая к оператору. Ручные и автоматические сканирования попадают сюда. Каждое аналитическое заключение несёт чип вердикта, уверенность, индикаторы MITRE (когда модель их возвращает), IOC, следующие шаги и кнопку View Source, открывающую точную строку журнала, на которую смотрел ИИ:

Инвентаризация активов

Аппаратное обеспечение, программное обеспечение и сетевые сокеты на агента. Вкладка Hardware перечисляет каждое устройство PnP, Software — установленные пакеты, Network — каждый сокет TCP/UDP с его владеющим процессом:

Log Explorer

Поиск по всем агентам на базе OpenSearch. Выберите агента, выберите набор данных (события SIEM, оповещения безопасности, события процессов, сеть, FIM, журналы аудита) и ищите. Также есть кнопка для открытия OpenSearch Dashboards (форк Kibana) для опытных пользователей:

Журналы аудита

Каждая попытка входа в саму платформу, как локальная, так и LDAP, с результатом, исходным IP-адресом и временной меткой. Полезно, когда кто-то в настроении «кто-когда-входил»:

Быстрый старт

Вам понадобится Docker 24+ с Compose v2 и Python 3.10+ на хосте (только для одноразового шага сборки агента). Полный стек требует ~16 ГБ ОЗУ, см. Системные требования ниже.```bash git clone https://github.com/d3vhex/Sentora.git cd Sentora

.env holds your local secrets. Never commit it.

cp .env.example .env

Generate the machine-generated secrets (FERNET_KEY, RABBITMQ_PASSWORD,

AGENT_SHARED_SECRET, OPENSEARCH_PASSWORD). Safe to re-run — it never

overwrites a value that is already set.

python scripts/init_secrets.py

Then set DB_PASSWORD by hand. Compose refuses to start without it.

On an existing deployment, rotate it with scripts/rotate_db_password.py

instead — MySQL fixes the root password at first init, so editing .env

alone locks the app out rather than changing the account.

Build the agent binary once. The server serves it via

/api/agent/download/{linux,windows}; skipping this means agents can't be

deployed because the download endpoint returns 404.

cd Sentora ./build_agent.sh # on Linux/macOS/WSL

.\build_agent.ps1 # on Windows

cd ..

docker compose up --build -d

Развёртывание агента: на странице Deploy Agent скопируйте однострочную команду для нужной ОС. На целевой машине (в оболочке администратора) вставьте её. Установщик скачивает бинарник, сохраняет конфиг, регистрирует агента на сервере и добавляет себя в качестве запланированного задания / systemd-юнита.

Сервисы в compose

Только app и ingest слушают все интерфейсы. Остальные привязаны к BIND_ADDR (по умолчанию 127.0.0.1), потому что ни один из них не требует аутентификации в конфигурации по умолчанию — OpenSearch работает с отключённым плагином безопасности, а Dashboards — это неаутентифицированный просмотр всех собранных логов. Откройте доступ к какому-либо из них, разместив его за тем же обратным прокси и аутентификацией, что и app, а не расширяя BIND_ADDR.

Кнопка «Open Dashboards» в Log Explorer ведёт на порт 5601 по имени хоста сервера, поэтому она работает с самого хоста; удалённым операторам нужен этот обратный прокси.

Системные требования

Фоновое потребление ресурсов:

• Ollama (llama3.2:3b): ~3 ГБ, больше при инференсе
• OpenSearch: ~2 ГБ кучи по умолчанию, диск растёт с retention
• MySQL: 500 МБ – 1 ГБ
• RabbitMQ: ~300 МБ
• Sanic + ingest + 3 AI-воркера: ~1 ГБ суммарно

Если RAM в обрез, переключитесь на qwen2.5:1.5b или другую небольшую модель Ollama и уменьшите кучу OpenSearch. GPU не обязателен, но Ollama использует его автоматически, если он есть.

Автоматические действия защитного ИИ

Когда вердикт защитного воркера — ACT с уверенностью ≥ AI_AUTO_ACT_CONF (по умолчанию 0.75) и рекомендуемое действие входит в безопасный список ниже, воркер ставит действие в очередь прямо в таблицу automations агента:``` BLOCK_IP KILL_PROCESS RESTART_SERVICE ISOLATE_HOST DISABLE_USER QUARANTINE_FILE SUSPEND_PROCESS LOGOFF_USER CONTAINER_ISOLATE CONTAINER_STOP CONTAINER_KILL

Если эта строка сообщает 0 permission-gated, RBAC не применяется — относитесь к этому как к инциденту.

Каждый маршрут должен быть одним из трёх вариантов: ограниченным разрешениями, указанным в _PUBLIC_HANDLERS, или названным в SESSION_ONLY_HANDLERS в tests/test_auth_wiring.py с комментарием, объясняющим, почему одной сессии достаточно. Тест проверяет это, поэтому новый маршрут не может незаметно появиться без контроля — именно так run_playbook, delete_soar_action и test_ldap_connection оказались доступны любой учётной записи, способной войти в систему.

Ограничение скорости входа

Пять неудачных попыток для одной учётной записи или двадцать с одного адреса в течение пятнадцати минут — и дальнейшие попытки отклоняются с кодом 429, пока окно не пройдёт. Подсчёт ведётся из login_logs, который уже записывал каждый сбой и который никто не читал — bcrypt был единственным тормозом для онлайн-подбора.

Проверка выполняется до сравнения пароля, поэтому она также устраняет разницу во времени между известным и неизвестным именем пользователя. Она завершается открыто, если login_logs недоступен: страница входа, которую невозможно открыть, потому что аудиторская таблица не работает, — это сам по себе инцидент.

Адреса клиентов за прокси

X-Forwarded-For учитывается только от узла, указанного в TRUSTED_PROXIES (адреса или CIDR через запятую, по умолчанию пусто). Если перед приложением ничего нет, заголовок предоставляется атакующим, поэтому безусловное доверие к нему — именно это и было заменено — позволяло вызывающему коду записать любой адрес в аудиторский журнал и сбросить собственный лимит скорости в том же запросе.``` TRUSTED_PROXIES=10.0.0.0/8,192.168.1.5

Старые ключи всё ещё находятся в истории git. Считайте пару, выпущенную до этого изменения, скомпрометированной; новые установки её больше не используют.

Локальные ключи Fernet

Сервер использует два ключа Fernet, оба автоматически генерируются при первом запуске:

Установите chmod 600 для обоих. Сделайте их резервные копии. Потеря любого из них сделает соответствующие зашифрованные данные нечитаемыми. Ротации на месте пока нет.

Threat intel

Два независимых механизма, оба необязательные:

Обогащение по вердиктам (ai/intel.py). AI-воркер перекрёстно проверяет индикаторы, найденные в логе, по AlienVault OTX и VirusTotal. Требуются OTX_API_KEY / VT_API_KEY; если не заданы — внешние вызовы не выполняются вовсе.

Каналы индикаторов (core/threat_feeds.py). Ежечасно заполняет таблицу threat_intel из abuse.ch — Feodo Tracker (адреса C2 ботнетов), ThreatFox (смешанные IoC с оценкой доверия) и URLhaus (URL-адреса, распространяющие вредоносное ПО).

Индикаторы содержат last_seen и удаляются после THREAT_INTEL_STALE_DAYS (по умолчанию 30): адрес, размещавший C2 в прошлом квартале, обычно теперь принадлежит кому-то другому, и его сохранение приводит к бесконечным ложным срабатываниям. Каждый канал ограничен THREAT_INTEL_MAX_PER_FEED строками, поскольку таблица читается на пути срабатывания оповещений.

abuse.ch переводит загрузки за бесплатный ключ аккаунта. Если канал возвращает 401/403, об этом сообщается в логе сервера; задайте THREAT_INTEL_AUTH_KEY.

Проверьте, что фактически поступило:```bash docker logs sentora-server | grep ThreatIntel

С этими настройками, плюс OTX_API_KEY / VT_API_KEY не заданы, ничего не покидает сеть. Шрифты встроены, Ollama локальный, CDN не используется.

Доступность флота

/api/exposure/report подсчитывает незакрытые пакеты и события целостности файлов по всему флоту, по каждому агенту, начиная с худших. Он сообщает о собственном покрытии: complete: false, когда агента не удалось прочитать, потому что итог по половине флота — это не итог по всему флоту.

Намеренно нет никакой оценки. Ранее конечная точка возвращала 100 - vulns*2 - fim*5 как «оценку соответствия» — она не соответствует ни одному фреймворку, не масштабируется с размером флота и обнуляется на любом реальном флоте. Градация серьёзности отсутствует по той же причине: в vulnerabilities_report нет колонки серьёзности, а её поля зашифрованы в состоянии покоя, поэтому любую оценку пришлось бы выдумывать.

Проверка конфигурации агента

POST /<agent>/config/<type> выполняет проверку до того, как что-либо достигнет сенсора: разбор YAML, структурная форма и — самый важный слой — компиляция регулярных выражений. Некорректное регулярное выражение — это вполне валидный YAML, который молча отключает категорию, содержащую его, поэтому проверка только синтаксиса отправила бы его прямо на конечную точку. Редактор проверяет через ту же конечную точку по мере ввода и сообщает о проблемах с кликабельными номерами строк.

Обзор архитектуры```

Agent (Win / Linux) │ TCP frames + REST polling ▼ ingest (:5001) ──► RabbitMQ ──► AI worker fleet (3 modes) │ │ ▼ ▼ MySQL (per-agent _db) ai_analysis_results │ ▼ app (Sanic :8000) ──► React UI + REST + WebSocket screen proxy

ИИ-работники вручную

Тот же скрипт, три роли:```bash WORKER_TYPE=automation python ai_worker.py WORKER_TYPE=manual python ai_worker.py WORKER_TYPE=defensive python ai_worker.py

3. Новые конечные точки должны быть обёрнуты в @require_permission(...). Журнал загрузки выводит итоговое количество; если он сообщает 0 permission-gated, что-то не так с подключением, а не с вашим маршрутом.
4. Всё, что достигает агента или внешнего хоста, нуждается в проверке на стороне сервера, а не только в браузере. Две реализации расходятся, и именно копия в браузере — та, которой операторы в итоге доверяют.

Для чего-то большего, чем исправление, сначала откройте issue, чтобы мы могли согласовать подход.

Структура проекта```

. ├── app.py # Sanic API + React SPA host ├── server.py # TCP ingest ├── ai_worker.py # AI worker fleet (3 modes) ├── ai/ │ ├── utils.py # LLM helpers, AI cache, SOAR queueing │ └── intel.py # OTX / VT per-verdict enrichment (opt-in) ├── core/ │ ├── mq.py # RabbitMQ publisher │ ├── opensearch.py # OpenSearch index/search │ ├── config_validation.py # Agent YAML validation (parse, shape, regex) │ └── threat_feeds.py # abuse.ch indicator feeds ├── security/ │ ├── session.py # Server-side session store │ └── ssrf.py # Proxy destination rules ├── scanners/ │ └── vuln.py # Server-side OSV scanner ├── scripts/ │ ├── init_secrets.py # Generate the secrets .env needs │ ├── rotate_db_password.py # Rotate the MySQL root password safely │ └── api_smoke_test.py # Exercise every route against a live server ├── tests/ # pytest; no MySQL or RabbitMQ required ├── frontend/ # React 18 + TS SPA │ └── src/lib/ # Shared logic (playbook action catalogue) ├── Sentora/ # Cross-platform agent ├── certs/ # Self-signed dev certs ├── docs/ # Architecture + screenshots └── docker-compose.yaml