Cosa fa realmente

• Raccoglie telemetria dagli agenti Windows e Linux su un singolo canale TCP. Eventi SIEM, alert, FIM, pacchetti, connessioni di rete, porte aperte, attività Docker, frame dello schermo.

• Rileva con regole Sigma, sull'endpoint. 23 regole che coprono 23 tecniche MITRE ATT&CK sono incluse in conf/sigma/builtin/; aggiungi set di regole della community accanto a esse. Sigma confronta campi nominati anziché testo, quindi Image|endswith: '\vssadmin.exe' non può essere aggirato dalla parola "vssadmin" che compare in un messaggio non correlato — e CommandLine|utf16le|base64offset|contains legge all'interno di un payload -EncodedCommand in base64, dove la riga di comando in chiaro mostra solo il wrapper. Misurato sul corpus di valutazione: 9 attacchi su 10 rilevati dal solo Sigma, 0 falsi positivi su 9 negativi difficili. Questo livello è deterministico e continua a funzionare quando il modello non è disponibile.

• Correla tra eventi, cosa che nessuna regola per singolo evento può fare. Un singolo accesso fallito è routine; cinque account che falliscono da un'unica sorgente in quaranta secondi è un password spray, e guardare uno qualsiasi di quei cinque eventi non te lo dirà mai. Copre spray, brute force, un successo che arriva dopo ripetuti fallimenti e raffiche di creazione di account o installazioni di servizi — su entrambe le piattaforme, dagli event ID di Windows o dalle righe auth.log analizzate.

  Viene eseguito da due punti di osservazione, perché vedono attacchi diversi. Per host sull'agente, dove un attacco contro una singola macchina è visibile per intero. E tra host nel percorso di ingestione, dove uno spray che ha percorso un fallimento alla volta su cinquanta macchine emerge — nessun singolo agente vede più di un evento, e questo è l'attacco più competente, poiché spruzzare in modo ampio e superficiale resta sotto sia il lockout per-account che le soglie per-host.

  Copertura totale con Sigma: 27 tecniche. Ogni finestra scatta una volta anziché una volta per evento, e ogni contatore è limitato — un contatore basato su un nome utente fornito dall'attaccante è una primitiva di esaurimento della memoria, non un rilevamento.

• Mappa i rilevamenti su MITRE ATT&CK, direttamente dalle regole. Le regole portano tags: attack.t1490, quindi non esiste una tabella di mappatura mantenuta a mano che possa diventare obsoleta. La pagina di copertura separa tre stati che un singolo "percentuale di copertura" nasconderebbe: coperto e visto, coperto e silenzioso, e per niente coperto — quest'ultimo essendo l'unico in cui il silenzio della console non significa nulla.

• Esegue il triage di ogni evento con un LLM locale. Tre worker girano in parallelo: uno osserva ogni evento in arrivo in tempo reale, uno esegue scan approfonditi guidati dall'operatore e uno decide se intraprendere un'azione difensiva (BLOCK_IP, ISOLATE_HOST, KILL_PROCESS, ecc.).

• Modalità shadow per il worker difensivo. Attiva AI_SHADOW_MODE=1 e ogni verdetto autonomo viene messo in attesa di approvazione umana nel SOAR Hub invece di essere inviato. Utile per ottimizzare il modello sul traffico reale prima di lasciarlo agire da solo.

• Indicizza tutto in OpenSearch così puoi cercare nella tua flotta con query fuzzy / esatte / con prefisso da un unico posto.

• Esegue playbook SOAR creati in un piccolo editor visivo con tracciamento dei risultati multi-step e per-nodo, attivabili manualmente o tramite verdetto AI.

• Scansione delle vulnerabilità dei pacchetti installati di ogni agente contro OSV (online o tramite un mirror interno).

• Recupera feed di threat-intel da abuse.ch (Feodo, ThreatFox, URLhaus) in una tabella di indicatori locale, con pruning per obsolescenza e uno switch per air-gap.

• Valida le configurazioni degli agenti prima di inviarle. Parsing YAML, forma strutturale e compilazione delle regex — una regex non valida è YAML valido e disabilita silenziosamente la regola che la contiene.

• Desktop remoto integrato tramite streaming JPEG su WebSocket, nessuna installazione VNC separata necessaria sull'endpoint.

Come appare

La barra laterale raggruppa tutto in tre sezioni: telemetria (dashboard, agenti, alert, asset, FIM, log, AI), automazione della risposta (azioni difensive, playbook, regole di automazione) e amministrazione.

Vista per agente

Ogni agente registrato ha la propria pagina con dodici schede. La panoramica mostra misuratori delle risorse in tempo reale, i log SIEM più recenti, i metadati dell'agente e un riepilogo delle minacce:

Gli alert sono tutto ciò che le regole di correlazione dell'agente hanno già segnalato. Colorati per gravità, filtrabili, ricercabili:

La scheda AI Analysis è il lato rivolto all'operatore del LLM locale. Gli scan manuali e automatici arrivano entrambi qui. Ogni insight porta un chip di verdetto, confidenza, indicatori MITRE (quando il modello li restituisce), IOC, passaggi successivi e un pulsante View Source che apre la riga di log esatta che l'AI ha esaminato:

Inventario degli asset

Hardware, software e socket di rete per agente. La scheda Hardware elenca ogni dispositivo PnP, Software elenca i pacchetti installati, Network elenca ogni socket TCP/UDP con il processo proprietario:

Log Explorer

Ricerca cross-agente basata su OpenSearch. Scegli un agente, scegli un dataset (eventi SIEM, alert di sicurezza, eventi di processo, rete, FIM, log di audit) e cerca. C'è anche un pulsante per aprire OpenSearch Dashboards (fork di Kibana) per gli utenti avanzati:

Log di audit

Ogni tentativo di accesso alla piattaforma stessa, sia locale che LDAP, con risultato, IP sorgente e timestamp. Utile quando qualcuno è nell'umore "chi-ha-acceduto-quando":

Avvio rapido

Ti serviranno Docker 24+ con Compose v2 e Python 3.10+ sull'host (solo per il passaggio di build dell'agente una tantum). L'intero stack richiede ~16 GB di RAM, vedi Requisiti di sistema qui sotto.```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

Distribuzione di un agente: dalla pagina Deploy Agent, copia il comando one-liner per il sistema operativo desiderato. Sulla macchina target (shell di amministrazione), incollalo. L'installer scarica il binario, crea un file di configurazione, si registra con il server e si configura come attività pianificata / unità systemd.

Servizi nel compose

Solo app e ingest ascoltano su tutte le interfacce. Gli altri si legano a BIND_ADDR (default 127.0.0.1), perché nessuno di essi autentica nella configurazione predefinita — OpenSearch viene eseguito con il plugin di sicurezza disabilitato e Dashboards è una vista non autenticata di ogni log raccolto. Esponine uno mettendolo dietro lo stesso reverse proxy e la stessa autenticazione di app, non allargando BIND_ADDR.

Il pulsante "Open Dashboards" in Log Explorer collega alla porta 5601 sul hostname del server, quindi funziona dall'host stesso; gli operatori remoti necessitano di quel reverse proxy.

Requisiti di sistema

Impronta a riposo:

• Ollama (llama3.2:3b): ~3 GB, di più durante l'inferenza
• OpenSearch: ~2 GB di heap predefinito, il disco cresce con la retention
• MySQL: 500 MB – 1 GB
• RabbitMQ: ~300 MB
• Sanic + ingest + 3 worker AI: ~1 GB in totale

Se hai poca RAM, passa a qwen2.5:1.5b o a un altro modello Ollama piccolo e riduci l'heap di OpenSearch. Una GPU non è richiesta, ma Ollama la userà automaticamente se presente.

Azioni automatiche AI difensive

Quando il verdetto del worker difensivo è ACT con confidenza ≥ AI_AUTO_ACT_CONF (default 0.75) e l'azione raccomandata è nella lista sicura di seguito, il worker accoda l'azione direttamente nella tabella automations dell'agente:``` BLOCK_IP KILL_PROCESS RESTART_SERVICE ISOLATE_HOST DISABLE_USER QUARANTINE_FILE SUSPEND_PROCESS LOGOFF_USER CONTAINER_ISOLATE CONTAINER_STOP CONTAINER_KILL

Se quella riga riporta 0 permission-gated, RBAC non è applicato — trattalo come un'interruzione del servizio.

Ogni route deve essere una di tre cose: protetta da permessi, elencata in _PUBLIC_HANDLERS, oppure nominata in SESSION_ONLY_HANDLERS in tests/test_auth_wiring.py con un commento che spieghi perché la sola sessione è sufficiente. Un test lo verifica, quindi una nuova route non può arrivare silenziosamente senza controllo — ed è così che run_playbook, delete_soar_action e test_ldap_connection erano finite raggiungibili da qualsiasi account che potesse accedere.

Limitazione dei tentativi di login

Cinque tentativi falliti per un account, o venti da un singolo indirizzo, entro quindici minuti, e ulteriori tentativi vengono rifiutati con 429 finché la finestra non scade. Contati da login_logs, che registrava già ogni fallimento e che nessuno leggeva — bcrypt era l'unico freno contro l'indovinamento online.

Il controllo viene eseguito prima del confronto della password, quindi elimina anche la differenza di tempo tra un nome utente noto e uno sconosciuto. Fallisce in modalità aperta se login_logs non è raggiungibile: una pagina di login che non può essere raggiunta perché la tabella di audit è giù è di per sé un'interruzione del servizio.

Indirizzi client dietro un proxy

X-Forwarded-For viene onorato solo da un peer elencato in TRUSTED_PROXIES (indirizzi o CIDR separati da virgole, vuoto di default). Con nulla davanti all'app, l'header è fornito dall'attaccante, quindi crederci incondizionatamente — che è ciò che questo ha sostituito — permetteva a un chiamante di scrivere qualsiasi indirizzo nella traccia di audit e di azzerare il proprio limite di velocità nella stessa richiesta.``` TRUSTED_PROXIES=10.0.0.0/8,192.168.1.5

Le vecchie chiavi sono ancora nella cronologia di git. Tratta la coppia distribuita prima di questa modifica come compromessa; le nuove installazioni non la usano più.

Chiavi Fernet locali

Il server usa due chiavi Fernet, entrambe generate automaticamente al primo avvio:

chmod 600 su entrambe. Fai un backup. Perderne una rende illeggibili i dati crittografati corrispondenti. Non esiste ancora una rotazione in-place.

Threat intel

Due meccanismi indipendenti, entrambi opzionali:

Arricchimento per-verdict (ai/intel.py). Il worker AI incrocia gli indicatori trovati in un log con AlienVault OTX e VirusTotal. Richiede OTX_API_KEY / VT_API_KEY; se non impostate, non viene effettuata alcuna chiamata esterna.

Feed di indicatori (core/threat_feeds.py). Popola la tabella threat_intel ogni ora da abuse.ch — Feodo Tracker (indirizzi C2 di botnet), ThreatFox (IoC misti con punteggio di confidenza) e URLhaus (URL che distribuiscono malware).

Gli indicatori portano last_seen e vengono eliminati dopo THREAT_INTEL_STALE_DAYS (default 30): un indirizzo che ospitava un C2 lo scorso trimestre di solito ora appartiene a qualcun altro, e mantenerlo produce falsi positivi all'infinito. Ogni feed è limitato a THREAT_INTEL_MAX_PER_FEED righe perché la tabella viene letta sul percorso di alert.

abuse.ch ha spostato i download dietro una chiave account gratuita. Un feed che restituisce 401/403 lo segnala nel log del server; imposta THREAT_INTEL_AUTH_KEY.

Controlla cosa è effettivamente arrivato:```bash docker logs sentora-server | grep ThreatIntel

Con quelle impostazioni, più OTX_API_KEY / VT_API_KEY non impostate, nulla lascia la rete. I font sono inclusi, Ollama è locale, nessuna CDN viene contattata.

Esposizione della flotta

/api/exposure/report conta i pacchetti non aggiornati e gli eventi di integrità dei file in tutta la flotta, per agente, peggiori per primi. Riporta la propria copertura: complete: false quando un agente non può essere letto, perché un totale su metà della flotta non è un totale di flotta.

Non c'è deliberatamente alcun punteggio. L'endpoint in precedenza restituiva 100 - vulns*2 - fim*5 come "punteggio di conformità" — che non corrisponde a nessun framework, non scala con la dimensione della flotta e si azzera su qualsiasi flotta reale. La classificazione della gravità è assente per lo stesso motivo: vulnerabilities_report non ha una colonna di gravità e i suoi campi sono crittografati a riposo, quindi qualsiasi voto dovrebbe essere inventato.

Validazione della configurazione dell'agente

POST /<agent>/config/<type> valida prima che qualsiasi cosa raggiunga un sensore: analisi YAML, forma strutturale e — il livello che conta — compilazione delle regex. Una regex non valida è YAML perfettamente valido e disabilita silenziosamente la categoria che la contiene, quindi un controllo solo sintattico la spingerebbe direttamente all'endpoint. L'editor esegue il lint sullo stesso endpoint mentre digiti e segnala i problemi con numeri di riga cliccabili.

Panoramica dell'architettura```

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

Lavoratori AI manualmente

Stesso script, tre ruoli:```bash WORKER_TYPE=automation python ai_worker.py WORKER_TYPE=manual python ai_worker.py WORKER_TYPE=defensive python ai_worker.py

3. I nuovi endpoint devono essere avvolti in @require_permission(...). Il log di avvio stampa il conteggio; se riporta 0 permission-gated, c'è qualcosa che non va con il cablaggio, non con la tua rotta.
4. Tutto ciò che raggiunge un agente o un host esterno necessita di validazione lato server, non solo nel browser. Due implementazioni divergono, e la copia del browser è quella di cui gli operatori finiscono per fidarsi.

Per qualsiasi cosa più grande di una correzione, apri prima un issue così possiamo allinearci sull'approccio.

Struttura del progetto```

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