Qué hace realmente

• Recopila telemetría de agentes Windows y Linux a través de un único canal TCP. Eventos SIEM, alertas, FIM, paquetes, conexiones de red, puertos abiertos, actividad de Docker, capturas de pantalla.

• Detecta con reglas Sigma, en el endpoint. 23 reglas que cubren 23 técnicas de MITRE ATT&CK se incluyen en conf/sigma/builtin/; coloca conjuntos de reglas de la comunidad junto a ellas. Sigma compara campos con nombre en lugar de texto, por lo que Image|endswith: '\vssadmin.exe' no puede ser derrotado por la palabra "vssadmin" apareciendo en un mensaje no relacionado — y CommandLine|utf16le|base64offset|contains lee dentro de un payload -EncodedCommand en base64, donde la línea de comandos en texto plano muestra solo el envoltorio. Medido en el corpus de evaluación: 9 de 10 ataques detectados solo por Sigma, 0 de 9 negativos duros marcados falsamente. Esta capa es determinista y sigue funcionando cuando el modelo no está disponible.

• Correlaciona entre eventos, algo que ninguna regla por evento puede hacer. Un único inicio de sesión fallido es rutinario; cinco cuentas fallando desde una misma fuente en cuarenta segundos es un ataque de fuerza bruta por pulverización (password spray), y mirar cualquiera de esos cinco eventos nunca te lo dirá. Cubre pulverización, fuerza bruta, un éxito que llega después de fallos repetidos, y ráfagas de creación de cuentas o instalación de servicios — en ambas plataformas, desde IDs de eventos de Windows o desde líneas de auth.log analizadas.

  Se ejecuta en dos puntos de observación, porque ven ataques diferentes. Por host en el agente, donde un ataque contra una máquina es visible en su totalidad. Y entre hosts en la ruta de ingesta, donde una pulverización que recorrió un fallo a la vez sobre cincuenta máquinas aparece — ningún agente individual ve más de un evento, y ese es el ataque más competente, ya que pulverizar amplio y superficial se mantiene por debajo tanto del bloqueo por cuenta como de los umbrales por host.

  Cobertura total con Sigma: 27 técnicas. Cada ventana se dispara una vez en lugar de una vez por evento, y cada contador está acotado — un contador basado en un nombre de usuario proporcionado por el atacante es una primitiva de agotamiento de memoria, no una detección.

• Mapea las detecciones a MITRE ATT&CK, desde las propias reglas. Las reglas llevan tags: attack.t1490, por lo que no hay una tabla de mapeo mantenida a mano que pueda quedar obsoleta. La página de cobertura separa tres estados que un único "porcentaje de cobertura" ocultaría: cubierto y visto, cubierto y silencioso, y no cubierto en absoluto — siendo el último el único donde el silencio de la consola no significa nada.

• Hace triaje de cada evento con un LLM local. Tres workers se ejecutan en paralelo: uno observa cada evento entrante en tiempo real, uno ejecuta escaneos profundos impulsados por el operador, y uno decide si tomar una acción defensiva (BLOCK_IP, ISOLATE_HOST, KILL_PROCESS, etc.).

• Modo sombra para el worker defensivo. Activa AI_SHADOW_MODE=1 y cada veredicto autónomo se prepara para aprobación humana en el SOAR Hub en lugar de ser despachado. Útil para ajustar el modelo con tráfico real antes de dejarlo actuar por su cuenta.

• Indexa todo en OpenSearch para que puedas buscar en tu flota con consultas difusas / exactas / de prefijo desde un solo lugar.

• Ejecuta playbooks SOAR construidos en un pequeño editor visual con seguimiento de resultados multi-paso y por nodo, que pueden activarse manualmente o por veredicto de IA.

• Escaneos de vulnerabilidades de los paquetes instalados de cada agente contra OSV (en línea o mediante un mirror interno).

• Extrae fuentes de inteligencia de amenazas de abuse.ch (Feodo, ThreatFox, URLhaus) a una tabla local de indicadores, con poda por obsolescencia y un interruptor de aislamiento (air-gap).

• Valida las configuraciones de los agentes antes de enviarlas. Análisis YAML, forma estructural y compilación de regex — una regex inválida es YAML válido y silenciosamente desactiva la regla que la contiene.

• Escritorio remoto integrado mediante transmisión JPEG por WebSocket, sin necesidad de instalación separada de VNC en el endpoint.

Cómo se ve

La barra lateral agrupa todo en tres secciones: telemetría (panel, agentes, alertas, activos, FIM, registros, IA), respuesta de automatización (acciones defensivas, playbooks, reglas de automatización) y administración.

Vista por agente

Cada agente registrado tiene su propia página con doce pestañas. La vista general muestra medidores de recursos en vivo, los registros SIEM más recientes, metadatos del agente y un resumen de amenazas:

Las alertas son todo lo que las propias reglas de correlación del agente ya han marcado. Con colores por severidad, filtrables, buscables:

La pestaña Análisis de IA es el lado orientado al operador del LLM local. Los escaneos manuales y automáticos aterrizan aquí. Cada insight lleva una etiqueta de veredicto, confianza, indicadores MITRE (cuando el modelo los devuelve), IOCs, siguientes pasos, y un botón Ver fuente que abre la fila de registro exacta que la IA observó:

Inventario de activos

Hardware, software y sockets de red por agente. La pestaña de hardware lista cada dispositivo PnP, el software lista los paquetes instalados, la red lista cada socket TCP/UDP con su proceso propietario:

Explorador de registros

Búsqueda entre agentes respaldada por OpenSearch. Elige un agente, elige un conjunto de datos (eventos SIEM, alertas de seguridad, eventos de procesos, red, FIM, registros de auditoría) y busca. También hay un botón para abrir OpenSearch Dashboards (fork de Kibana) para usuarios avanzados:

Registros de auditoría

Cada intento de inicio de sesión contra la propia plataforma, tanto local como LDAP, con resultado, IP de origen y marca de tiempo. Útil cuando alguien está de humor "quién-inició-sesión-cuándo":

Inicio rápido

Necesitarás Docker 24+ con Compose v2 y Python 3.10+ en el host (solo para el paso único de compilación del agente). El stack completo requiere ~16 GB de RAM, consulta Requisitos del sistema a continuación.```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

Desplegar un agente: desde la página Deploy Agent, copia el comando de una línea para el sistema operativo que quieras. En la máquina de destino (shell de administrador), pégalo. El instalador descarga el binario, coloca una configuración, se registra con el servidor y se registra a sí mismo como una tarea programada / unidad systemd.

Servicios en el compose

Solo app e ingest escuchan en todas las interfaces. El resto se vincula a BIND_ADDR (por defecto 127.0.0.1), porque ninguno de ellos se autentica en la configuración predeterminada — OpenSearch se ejecuta con su plugin de seguridad deshabilitado y Dashboards es una vista sin autenticación de cada registro recopilado. Expón uno colocándolo detrás del mismo proxy inverso y autenticación que app, no ampliando BIND_ADDR.

El botón "Open Dashboards" en Log Explorer enlaza al puerto 5601 en el nombre de host del servidor, por lo que funciona desde el propio host; los operadores remotos necesitan ese proxy inverso.

Requisitos del sistema

Huella en reposo:

• Ollama (llama3.2:3b): ~3 GB, más durante la inferencia
• OpenSearch: ~2 GB de heap predeterminado, el disco crece con la retención
• MySQL: 500 MB – 1 GB
• RabbitMQ: ~300 MB
• Sanic + ingest + 3 trabajadores de IA: ~1 GB combinados

Si tienes poca RAM, cambia a qwen2.5:1.5b u otro modelo pequeño de Ollama y reduce el heap de OpenSearch. No se requiere GPU, pero Ollama la usará automáticamente si está presente.

Acciones automáticas de IA defensiva

Cuando el veredicto del trabajador defensivo es ACT con confianza ≥ AI_AUTO_ACT_CONF (por defecto 0.75) y la acción recomendada está en la lista segura a continuación, el trabajador pone la acción directamente en la cola de la tabla automations del agente:``` BLOCK_IP KILL_PROCESS RESTART_SERVICE ISOLATE_HOST DISABLE_USER QUARANTINE_FILE SUSPEND_PROCESS LOGOFF_USER CONTAINER_ISOLATE CONTAINER_STOP CONTAINER_KILL

Si esa línea informa 0 permission-gated, RBAC no se está aplicando — trátalo como una interrupción del servicio.

Cada ruta debe ser una de tres cosas: con permiso restringido, listada en _PUBLIC_HANDLERS, o nombrada en SESSION_ONLY_HANDLERS en tests/test_auth_wiring.py con un comentario que explique por qué la sesión sola es suficiente. Un test lo verifica, así que una ruta nueva no puede llegar silenciosamente sin gobernanza — que es como run_playbook, delete_soar_action y test_ldap_connection habían terminado siendo accesibles por cualquier cuenta que pudiera iniciar sesión.

Limitación de intentos de inicio de sesión

Cinco intentos fallidos para una cuenta, o veinte desde una dirección, dentro de quince minutos, y los intentos posteriores se rechazan con 429 hasta que pase la ventana. Se cuenta desde login_logs, que ya registraba cada fallo y que nadie leía — bcrypt era el único freno contra la adivinación en línea.

La comprobación se ejecuta antes de la comparación de contraseñas, por lo que también elimina la diferencia de tiempo entre un nombre de usuario conocido y uno desconocido. Falla en abierto si login_logs no es accesible: una página de inicio de sesión que no se puede alcanzar porque la tabla de auditoría está caída es su propia interrupción del servicio.

Direcciones de cliente detrás de un proxy

X-Forwarded-For solo se respeta desde un peer listado en TRUSTED_PROXIES (direcciones o CIDRs separados por comas, vacío por defecto). Sin nada delante de la aplicación, la cabecera la suministra el atacante, así que creerla incondicionalmente — que es lo que esto reemplazó — permitía a un llamador escribir cualquier dirección en el registro de auditoría y restablecer su propio límite de tasa en la misma solicitud.``` TRUSTED_PROXIES=10.0.0.0/8,192.168.1.5

Las claves antiguas siguen en el historial de git. Trata el par que se envió antes de este cambio como quemado; las nuevas instalaciones ya no lo usan.

Claves Fernet locales

El servidor usa dos claves Fernet, ambas generadas automáticamente en el primer arranque:

chmod 600 en ambas. Haz copias de seguridad. Perder cualquiera de las dos hace que los datos cifrados correspondientes sean ilegibles. Aún no hay rotación in situ.

Inteligencia de amenazas

Dos mecanismos independientes, ambos opcionales:

Enriquecimiento por veredicto (ai/intel.py). El trabajador de IA contrasta los indicadores encontrados en un registro contra AlienVault OTX y VirusTotal. Necesita OTX_API_KEY / VT_API_KEY; si no están definidas, no se realiza ninguna llamada externa.

Fuentes de indicadores (core/threat_feeds.py). Rellena la tabla threat_intel cada hora desde abuse.ch — Feodo Tracker (direcciones C2 de botnets), ThreatFox (IoCs mixtos con una puntuación de confianza) y URLhaus (URLs que distribuyen malware).

Los indicadores llevan last_seen y se podan después de THREAT_INTEL_STALE_DAYS (por defecto 30): una dirección que alojó un C2 el último trimestre normalmente pertenece a otra persona ahora, y mantenerla produce falsos positivos indefinidamente. Cada fuente está limitada a THREAT_INTEL_MAX_PER_FEED filas porque la tabla se lee en la ruta de alertas.

abuse.ch ha estado moviendo las descargas detrás de una clave de cuenta gratuita. Una fuente que devuelve 401/403 lo indica en el registro del servidor; establece THREAT_INTEL_AUTH_KEY.

Comprueba qué llegó realmente:```bash docker logs sentora-server | grep ThreatIntel

Con esos valores configurados, más OTX_API_KEY / VT_API_KEY sin definir, nada sale de la red. Las fuentes están incluidas, Ollama es local, no se contacta con ningún CDN.

Exposición de la flota

/api/exposure/report cuenta paquetes sin parchear y eventos de integridad de archivos en toda la flota, por agente, de peor a mejor. Informa su propia cobertura: complete: false cuando un agente no pudo leerse, porque un total sobre la mitad de la flota no es un total de flota.

Deliberadamente no hay puntuación. El endpoint anteriormente devolvía 100 - vulns*2 - fim*5 como una "puntuación de cumplimiento" — eso no se corresponde con ningún marco, no escala con el tamaño de la flota y se fija en cero en cualquier flota real. La clasificación por gravedad está ausente por la misma razón: vulnerabilities_report no tiene columna de gravedad y sus campos están cifrados en reposo, por lo que cualquier calificación tendría que inventarse.

Validación de configuración del agente

POST /<agent>/config/<type> valida antes de que cualquier cosa llegue a un sensor: análisis YAML, forma estructural y — la capa que importa — compilación de regex. Una regex inválida es YAML perfectamente válido y desactiva silenciosamente la categoría que la contiene, por lo que una verificación solo de sintaxis la enviaría directamente al endpoint. El editor valida contra el mismo endpoint mientras escribes y reporta problemas con números de línea en los que se puede hacer clic.

Resumen de la arquitectura```

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

Trabajadores de IA manualmente

Mismo script, tres roles:```bash WORKER_TYPE=automation python ai_worker.py WORKER_TYPE=manual python ai_worker.py WORKER_TYPE=defensive python ai_worker.py

3. Los nuevos endpoints deben envolverse en @require_permission(...). El registro de arranque imprime el recuento; si informa 0 permission-gated, algo está mal con la conexión, no con tu ruta.
4. Todo lo que llegue a un agente o a un host externo necesita validación en el lado del servidor, no solo en el navegador. Dos implementaciones divergen, y la copia del navegador es en la que los operadores terminan confiando.

Para cualquier cosa más grande que una corrección, abre un issue primero para que podamos alinearnos en el enfoque.

Estructura del proyecto```

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