sentora

Sentora Community Edition es una plataforma de operaciones de seguridad autoalojada dirigida a equipos pequeños y medianos sin un SOC dedicado. Su README describe una pila que combina la recopilación de registros SIEM, la detección y respuesta de endpoints, y la automatización SOAR, todo iniciado con un único comando docker compose up. Telemetría y detección: los agentes de Windows y Linux envían eventos SIEM, alertas, monitoreo de integridad de archivos (FIM), paquetes instalados, conexiones de red, puertos abiertos, actividad de Docker y fotogramas de pantalla a través de un canal TCP. La detección se ejecuta en el endpoint con reglas Sigma: el repositorio incluye 43 reglas integradas que cubren 47 técnicas de MITRE ATT&CK en conf/sigma/builtin, y las reglas llevan sus propias etiquetas ATT&CK en lugar de depender de una tabla de mapeo mantenida manualmente. Una segunda capa determinista correlaciona eventos a lo largo del tiempo para encontrar patrones como spray de contraseñas, fuerza bruta, éxito después de fallos repetidos, y ráfagas de creación de cuentas o instalación de servicios; el README señala que esto se ejecuta en dos puntos de vista, por host en el agente y entre hosts en la ruta de ingesta. Las configuraciones de los agentes se validan (análisis de YAML, forma estructural, compilación de regex) antes de ser enviadas a los sensores. Triage por IA: tres procesos de trabajo utilizan un modelo Ollama en ejecución local (por defecto llama3.2:3b, intercambiable en .env) para revisar eventos entrantes en tiempo real, ejecutar escaneos profundos iniciados por el operador y decidir acciones defensivas. Un modo sombra (AI_SHADOW_MODE=1) pone en cola los veredictos autónomos como propuestas para la aprobación humana en el SOAR Hub en lugar de despacharlos. Solo una lista fija de acciones seguras — incluyendo BLOCK_IP, ISOLATE_HOST, KILL_PROCESS, DISABLE_USER, QUARANTINE_FILE y acciones a nivel de contenedor — pueden ser despachadas automáticamente, y solo por encima de un umbral de confianza configurable; cualquier otra cosa se degrada a una visión de asesoramiento. Búsqueda, activos y automatización: los eventos se indexan en OpenSearch con un explorador de registros entre agentes y una vista opcional de OpenSearch Dashboards al estilo de Kibana. Una página por agente expone el inventario de hardware, software y sockets de red, además del análisis de IA con veredictos, confianza, IOC y un enlace de vuelta a la fila de registro fuente. Los playbooks SOAR se construyen en un pequeño editor visual con seguimiento de resultados por nodo y pueden ser activados manualmente o por un veredicto de IA. Los agentes también tienen sus paquetes instalados escaneados contra OSV (en línea o a través de un espejo interno), y los feeds de inteligencia de amenazas de abuse.ch (Feodo, ThreatFox, URLhaus) pueblan una tabla de indicadores local con poda de obsolescencia y un interruptor de desconexión aérea. Despliegue: Docker 24+ con Compose v2, más Python 3.10+ en el host para la construcción única del agente. El README enumera perfiles de tamaño desde un laboratorio de hasta 5 agentes (4 núcleos, 12 GB de RAM) hasta más de 50 agentes, y da las huellas de inactividad para Ollama, OpenSearch, MySQL y RabbitMQ. Solo los servicios de aplicación e ingesta escuchan en todas las interfaces por defecto; MySQL, RabbitMQ, Ollama y OpenSearch se vinculan a localhost, y el README advierte contra exponerlos ampliando BIND_ADDR. Los secretos generados por máquina provienen de scripts/init_secrets.py, los certificados TLS se generan por instalación en lugar de ser enviados, y la cuenta de administrador sembrada se crea con una bandera de cambio de contraseña obligatorio aplicada en el middleware. La postura de seguridad descrita en el README incluye sesiones del lado del servidor con cookies HttpOnly opacas (solo se almacena un hash SHA-256), enrutamiento de denegación por defecto con manejadores protegidos por permisos aplicados a través de un registro de middleware, limitación de inicio de sesión por cuenta y por IP contada a partir de los registros de inicio de sesión existentes, X-Forwarded-For honrado solo desde proxies de confianza configurados, y gestión de WebSocket iniciada por el agente para que los endpoints no ejecuten una API de gestión entrante. Una prueba afirma que cada ruta está protegida por permisos, listada como pública o explícitamente nombrada como solo de sesión con una justificación. La documentación operativa en el repositorio cubre la arquitectura, el despliegue en producción, un manual de actualización y un informe de progreso.