O que ele realmente faz

• Coleta telemetria de agentes Windows e Linux por um único canal TCP. Eventos de SIEM, alertas, FIM, pacotes, conexões de rede, portas abertas, atividade do Docker, quadros de tela.

• Detecta com regras Sigma, no endpoint. 23 regras cobrindo 23 técnicas do MITRE ATT&CK acompanham o conf/sigma/builtin/; adicione conjuntos de regras da comunidade ao lado delas. O Sigma corresponde a campos nomeados em vez de texto, então Image|endswith: '\vssadmin.exe' não pode ser derrotado pela palavra "vssadmin" aparecendo em uma mensagem não relacionada — e CommandLine|utf16le|base64offset|contains lê dentro de um payload -EncodedCommand em base64, onde a linha de comando em texto puro mostra apenas o wrapper. Medido no corpus de avaliação: 9 de 10 ataques detectados apenas pelo Sigma, 0 de 9 negativos difíceis sinalizados falsamente. Esta camada é determinística e continua funcionando quando o modelo está indisponível.

• Correlaciona entre eventos, o que nenhuma regra por evento consegue fazer. Um único logon com falha é rotina; cinco contas falhando a partir de uma única origem em quarenta segundos é um password spray, e olhar para qualquer um desses cinco eventos nunca lhe dirá isso. Cobre spray, força bruta, um sucesso chegando após falhas repetidas, e rajadas de criação de contas ou instalações de serviços — em ambas as plataformas, a partir de IDs de eventos do Windows ou de linhas analisadas do auth.log.

  Executa em dois pontos de observação, porque eles veem ataques diferentes. Por host no agente, onde um ataque contra uma única máquina é visível por completo. E entre hosts no caminho de ingestão, onde um spray que percorreu uma falha por vez sobre cinquenta máquinas aparece — nenhum agente individual vê mais de um evento, e esse é o ataque mais competente, já que pulverizar amplo e raso permanece abaixo tanto do bloqueio por conta quanto dos limites por host.

  Cobertura total com Sigma: 27 técnicas. Cada janela dispara uma vez em vez de uma vez por evento, e cada contador é limitado — um contador baseado em um nome de usuário fornecido pelo atacante é uma primitiva de esgotamento de memória, não uma detecção.

• Mapeia detecções para o MITRE ATT&CK, a partir das próprias regras. As regras carregam tags: attack.t1490, então não há tabela de mapeamento mantida manualmente que possa ficar desatualizada. A página de cobertura separa três estados que um único "percentual de cobertura" esconderia: coberto e visto, coberto e silencioso, e não coberto de forma alguma — sendo o último o único onde o silêncio do console não significa nada.

• Faz triagem de cada evento com um LLM local. Três workers executam em paralelo: um observa cada evento recebido em tempo real, um executa varreduras profundas orientadas pelo operador, e um decide se deve tomar uma ação defensiva (BLOCK_IP, ISOLATE_HOST, KILL_PROCESS, etc.).

• Modo shadow para o worker defensivo. Ative AI_SHADOW_MODE=1 e cada veredito autônomo é encaminhado para aprovação humana no SOAR Hub em vez de ser despachado. Útil para ajustar o modelo com tráfego real antes de deixá-lo agir por conta própria.

• Indexa tudo no OpenSearch para que você possa pesquisar sua frota com consultas fuzzy / exatas / prefixo a partir de um único lugar.

• Executa playbooks SOAR construídos em um pequeno editor visual com rastreamento de resultados multi-etapa e por nó, podendo ser acionados manualmente ou por veredito da IA.

• Varredura de vulnerabilidades dos pacotes instalados de cada agente contra o OSV (online ou via um mirror interno).

• Puxa feeds de threat-intel do abuse.ch (Feodo, ThreatFox, URLhaus) para uma tabela local de indicadores, com poda por obsolescência e um interruptor de air-gap.

• Valida configurações de agentes antes de enviá-las. Parse de YAML, forma estrutural e compilação de regex — uma regex inválida é YAML válido e silenciosamente desativa a regra que a contém.

• Área de trabalho remota integrada via streaming JPEG por WebSocket, sem necessidade de instalação separada de VNC no endpoint.

Como se parece

A barra lateral agrupa tudo em três seções: telemetria (dashboard, agentes, alertas, ativos, FIM, logs, IA), resposta de automação (ações defensivas, playbooks, regras de automação) e administração.

Visualização por agente

Cada agente registrado tem sua própria página com doze abas. A visão geral mostra medidores de recursos ao vivo, os logs de SIEM mais recentes, metadados do agente e um resumo de ameaças:

Alertas são tudo o que as próprias regras de correlação do agente já sinalizaram. Coloridos por severidade, filtráveis, pesquisáveis:

A aba AI Analysis é o lado voltado ao operador do LLM local. Varreduras manuais e automáticas chegam aqui. Cada insight carrega um chip de veredito, confiança, indicadores MITRE (quando o modelo os retorna), IOCs, próximos passos e um botão View Source que abre a linha exata do log que a IA analisou:

Inventário de ativos

Hardware, software e sockets de rede por agente. A aba Hardware lista cada dispositivo PnP, software lista os pacotes instalados, rede lista cada socket TCP/UDP com seu processo proprietário:

Log Explorer

Pesquisa entre agentes com suporte do OpenSearch. Escolha um agente, escolha um conjunto de dados (eventos de SIEM, alertas de segurança, eventos de processo, rede, FIM, logs de auditoria) e pesquise. Há também um botão para abrir o OpenSearch Dashboards (fork do Kibana) para usuários avançados:

Logs de auditoria

Cada tentativa de login na própria plataforma, tanto local quanto LDAP, com resultado, IP de origem e timestamp. Útil quando alguém está no clima de "quem logou quando":

Início rápido

Você precisará de Docker 24+ com Compose v2 e Python 3.10+ no host (apenas para a etapa única de build do agente). O stack completo quer ~16 GB de RAM, veja Requisitos de sistema abaixo.```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

Implantar um agente: a partir da página Deploy Agent, copie o comando de uma linha para o SO desejado. Na máquina de destino (shell de administrador), cole-o. O instalador baixa o binário, grava uma configuração, registra-se no servidor e registra-se como uma tarefa agendada / unidade systemd.

Serviços no compose

Apenas app e ingest escutam em todas as interfaces. O restante faz bind em BIND_ADDR (padrão 127.0.0.1), porque nenhum deles autentica na configuração padrão — o OpenSearch roda com o plugin de segurança desativado e o Dashboards é uma visão não autenticada de todos os logs coletados. Exponha um colocando-o atrás do mesmo proxy reverso e autenticação que o app, não ampliando BIND_ADDR.

O botão "Open Dashboards" no Log Explorer aponta para a porta 5601 no hostname do servidor, então funciona a partir do próprio host; operadores remotos precisam desse proxy reverso.

Requisitos de sistema

Pegada ociosa:

• Ollama (llama3.2:3b): ~3 GB, mais durante inferência
• OpenSearch: ~2 GB de heap padrão, o disco cresce com a retenção
• MySQL: 500 MB – 1 GB
• RabbitMQ: ~300 MB
• Sanic + ingest + 3 workers de IA: ~1 GB combinados

Se você estiver com pouca RAM, troque para qwen2.5:1.5b ou outro modelo Ollama pequeno e reduza o heap do OpenSearch. Uma GPU não é necessária, mas o Ollama a usará automaticamente se estiver presente.

Ações automáticas de IA defensiva

Quando o veredito do worker defensivo é ACT com confiança ≥ AI_AUTO_ACT_CONF (padrão 0.75) e a ação recomendada está na lista segura abaixo, o worker enfileira a ação diretamente na tabela automations do agente:``` BLOCK_IP KILL_PROCESS RESTART_SERVICE ISOLATE_HOST DISABLE_USER QUARANTINE_FILE SUSPEND_PROCESS LOGOFF_USER CONTAINER_ISOLATE CONTAINER_STOP CONTAINER_KILL

Se essa linha reportar 0 permission-gated, o RBAC não está sendo aplicado — trate isso como uma indisponibilidade.

Cada rota deve ser uma de três coisas: protegida por permissão, listada em _PUBLIC_HANDLERS, ou nomeada em SESSION_ONLY_HANDLERS em tests/test_auth_wiring.py com um comentário explicando por que apenas a sessão é suficiente. Um teste verifica isso, então uma nova rota não pode chegar silenciosamente sem governança — que é como run_playbook, delete_soar_action e test_ldap_connection acabaram acessíveis por qualquer conta que conseguisse fazer login.

Limitação de login

Cinco tentativas falhas para uma conta, ou vinte a partir de um endereço, dentro de quinze minutos, e novas tentativas são recusadas com 429 até que a janela passe. Contadas a partir de login_logs, que já registrava cada falha e que ninguém lia — o bcrypt era o único freio contra adivinhação online.

A verificação ocorre antes da comparação de senha, então também elimina a diferença de tempo entre um nome de usuário conhecido e um desconhecido. Ela falha de forma aberta se login_logs estiver inacessível: uma página de login que não pode ser acessada porque a tabela de auditoria está fora do ar é, por si só, uma indisponibilidade.

Endereços de clientes atrás de um proxy

X-Forwarded-For é honrado apenas a partir de um peer listado em TRUSTED_PROXIES (endereços ou CIDRs separados por vírgula, vazio por padrão). Sem nada na frente do aplicativo, o cabeçalho é fornecido pelo atacante, então acreditar nele incondicionalmente — que é o que isso substituiu — permitia que um chamador gravasse qualquer endereço no trilho de auditoria e redefinisse seu próprio limite de taxa na mesma requisição.``` TRUSTED_PROXIES=10.0.0.0/8,192.168.1.5

As chaves antigas ainda estão no histórico do git. Trate o par que foi enviado antes desta alteração como queimado; novas instalações não o utilizam mais.

Chaves Fernet locais

O servidor usa duas chaves Fernet, ambas geradas automaticamente no primeiro boot:

chmod 600 em ambas. Faça backup delas. Perder qualquer uma torna os dados criptografados correspondentes ilegíveis. Ainda não há rotação no local.

Threat intel

Dois mecanismos independentes, ambos opcionais:

Enriquecimento por veredito (ai/intel.py). O worker de IA cruza indicadores encontrados em um log com AlienVault OTX e VirusTotal. Requer OTX_API_KEY / VT_API_KEY; se não definidos, nenhuma chamada externa é feita.

Feeds de indicadores (core/threat_feeds.py). Popula a tabela threat_intel a cada hora a partir do abuse.ch — Feodo Tracker (endereços C2 de botnets), ThreatFox (IoCs mistos com pontuação de confiança) e URLhaus (URLs que distribuem malware).

Os indicadores carregam last_seen e são removidos após THREAT_INTEL_STALE_DAYS (padrão 30): um endereço que hospedou um C2 no último trimestre geralmente pertence a outra pessoa agora, e mantê-lo gera falsos positivos indefinidamente. Cada feed é limitado a THREAT_INTEL_MAX_PER_FEED linhas porque a tabela é lida no caminho de alerta.

O abuse.ch tem movido downloads para trás de uma chave de conta gratuita. Um feed que retorna 401/403 informa isso no log do servidor; defina THREAT_INTEL_AUTH_KEY.

Verifique o que realmente chegou:```bash docker logs sentora-server | grep ThreatIntel

Com esses definidos, além de OTX_API_KEY / VT_API_KEY não definidos, nada sai da rede. As fontes estão incluídas, o Ollama é local, nenhum CDN é contatado.

Exposição da frota

/api/exposure/report conta pacotes sem correção e eventos de integridade de arquivos em toda a frota, por agente, do pior para o melhor. Ele informa sua própria cobertura: complete: false quando um agente não pôde ser lido, porque um total sobre metade da frota não é um total da frota.

Não há deliberadamente nenhuma pontuação. O endpoint anteriormente retornava 100 - vulns*2 - fim*5 como uma "pontuação de conformidade" — isso não corresponde a nenhum framework, não escala com o tamanho da frota e trava em zero em qualquer frota real. A classificação de gravidade está ausente pelo mesmo motivo: vulnerabilities_report não tem coluna de gravidade e seus campos são criptografados em repouso, então qualquer nota teria que ser inventada.

Validação de configuração do agente

POST /<agent>/config/<type> valida antes que qualquer coisa chegue a um sensor: análise YAML, forma estrutural e — a camada que importa — compilação de regex. Uma regex inválida é YAML perfeitamente válido e desativa silenciosamente a categoria que a contém, então uma verificação apenas de sintaxe a enviaria direto para o endpoint. O editor faz lint contra o mesmo endpoint enquanto você digita e relata problemas com números de linha clicáveis.

Visão geral da arquitetura```

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

Trabalhadores de IA manualmente

Mesmo script, três papéis:```bash WORKER_TYPE=automation python ai_worker.py WORKER_TYPE=manual python ai_worker.py WORKER_TYPE=defensive python ai_worker.py

3. Novos endpoints devem ser envolvidos em @require_permission(...). O log de inicialização imprime a contagem; se ele reportar 0 permission-gated, algo está errado com a fiação, não com a sua rota.
4. Qualquer coisa que alcance um agente ou um host externo precisa de validação no lado do servidor, não apenas no navegador. Duas implementações divergem, e a cópia do navegador é a que os operadores acabam confiando.

Para qualquer coisa maior que uma correção, abra uma issue primeiro para que possamos alinhar a abordagem.

Estrutura do projeto```

. ├── 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