Servizi fondamentali

Che cosa sono

Per i motivi (discussione): L'officina: analisi, compilazione e catena di fornitura, Alerting.
Nella guida pratica: L'officina e lo scambio con il nodo.

I servizi fondamentali sono gli strumenti che rendono un nodo Tutanum vivo e difendibile: la catena di fornitura del software (analisi, compilazione, repository firmato), il monitoraggio delle risorse e delle difese, i backup cifrati, e gli avvisi che arrivano al telefono attraverso I2P, senza servizi di terzi. Sono piccoli programmi indipendenti: se un tassello cade, gli altri restano. Il codice è in questa cartella (README), in forma generica e riutilizzabile: nessun segreto e nessun riferimento a un nodo specifico.

Nodo e officina

Il lavoro è diviso tra due macchine con una regola netta: è sempre il nodo a iniziare. Il nodo custodisce i segreti ed espone i servizi; l'officina (una macchina separata) analizza e compila il software non fidato e non ha uscite proprie (esce solo dal proxy Tor del nodo). Le due si parlano solo in SSH, a comando imposto, e per iniziativa del nodo; ciò che arriva dall'officina è dato, che il nodo valida e rifirma con una chiave che non lascia mai il nodo. Il dettaglio è in L'officina e lo scambio con il nodo.

Sul nodo

Girano sull'host, che custodisce i segreti. Li installano gli script dedicati, e sono schedulati da cron-servizi.

Strumento	Fa
tutanum-monitor	Controlla risorse, difese (firewall, securelevel, esca) e servizi; avvisa ai cambi di stato. Config: tutanum-monitor.conf.
tutanum-edr	Rilevatore d'intrusione, solo osservativo (non tocca mai firewall o sistema): accessi (ssh, console, su/doas su host e in ogni jail), canary token (file-esca e path-esca nel web), uscite in chiaro e beaconing, DoS. Classifica ogni evento con un riferimento CAPEC e, con una correlazione comportamentale, mette in sequenza gli eventi recenti in catene note (per esempio accesso seguito da elevazione e poi da un'uscita in chiaro, oppure un brute force seguito da un accesso riuscito dalla stessa origine), legandoli per soggetto (stesso utente o indirizzo) dove ha senso ed emettendo un unico avviso "comportamento sospetto" con un punteggio dinamico. Config: tutanum-edr.conf; si installa con installa-edr.sh.
tutanum-esca	Riepilogo degli honeypot (cowrie, endlessh): login riusciti, comandi e download finiscono in allarme, scansioni e tentativi falliti sono riassunti a conteggi per non inondare il telefono. Le intrusioni ATTIVE (login riuscito, comando, trasferimento file) vengono inoltre passate a tutanum-edr, che le correla con gli eventi del nodo reale (per esempio esca colpita seguita da un accesso o da un'uscita in chiaro). Config: tutanum-esca.conf.
tutanum-avvisi	Il notificatore: firma il file di stato (Ed25519) e lo pubblica nella jail che lo serve via I2P, per l'app del telefono. Si installa con installa-avvisi.sh.
tutanum-versione	Pubblica un file versione firmato accanto allo stato: l'app lo verifica e mostra il banner di aggiornamento. Uso manuale a ogni rilascio.
tutanum-verdetti	Ritira dall'eepsite i verdetti di triage che l'app invia (una PUT firmata, autenticata con una chiave del telefono arruolata sul nodo), ne verifica la firma Ed25519 e li applica: un blocco marcato "falso positivo" il notificatore smette di pubblicarlo. È l'anello di retroazione della behaviour detection, lato nodo.
tutanum-inventario	Inventario dei pacchetti dell'host e di ogni jail, con l'origine di ciascun port; segnala all'app le variazioni (pacchetti installati, aggiornati o rimossi).
tutanum-backup	Backup cifrato e deduplicato con restic, in sola aggiunta (--append-only) verso l'officina, con verifica a rotazione. Config: tutanum-backup.conf.
tutanum-hackalendar	Riversa le issue in un'agenda/roadmap auto-ospitata (file di sincronizzazione su un repository), attraverso Tor.
tutanum-officina-scambio	Il solo canale verso l'officina: consegna l'inventario, ritira le issue, ritira il repository compilato e lo rifirma. Gira per iniziativa del nodo.
tutanum-blinda-jail	Nelle jail: etc/usr/local/compat in sola lettura, tmp/var/home/root non eseguibili. Ciò che si scrive non si esegue, ciò che si esegue non si scrive.

I log confluiscono in due destinazioni di syslog (syslog-avvisi.conf, con rotazione da newsyslog-avvisi.conf): gli allarmi al notificatore, le informazioni al file di stato.

La logica delicata del nodo (la chiave con cui app e nodo concordano il triage, la correlazione comportamentale con i suoi punteggi, la verifica delle firme dei verdetti, l'estrazione degli honeypot) ha una suite di prove riproducibili, prove.sh: gira in locale su dati sintetici, senza il nodo e senza toccare nulla, ed estrae le funzioni dai file reali così da cogliere le regressioni se il codice cambia.

Sull'officina

Girano su una macchina separata, senza segreti: analizzano e compilano il software non fidato. Funzioni comuni in officina.subr; preparazione con installa-officina.sh.

Strumento	Fa
…sorveglia	Sorveglia l'albero dei port e i repository a monte dei pacchetti installati; accoda un lavoro quando qualcosa si muove.
…lavora	Esegue i lavori in coda, uno alla volta: scarica i sorgenti attraverso Tor, li fa analizzare e, superata la soglia, compila in una jail effimera senza rete (poudriere).
…analizza	La catena di scanner (Gitleaks, Trivy, Semgrep, Bearer, Syft, Grype, osv-scanner) con una soglia che blocca la compilazione oltre il livello di gravità scelto (fail-closed).
…caccia	Caccia ai bug nei sorgenti a monte: analizzatori statici per C/C++ e fuzzing degli harness già forniti dagli autori.
…va	Vulnerability assessment: confronta l'inventario con il database VuXML e apre una issue per ogni vulnerabilità nuova.
…bugbounty	Scansione periodica dei propri servizi esposti (onion, eepsite, SSH), come farebbe un attaccante.
…scambio	Il dispatcher lato officina: l'unico comando che il nodo può eseguire, con un elenco chiuso di richieste (inventario, issue).

Ogni risultato (vulnerabilità, errore di build, bug a monte) diventa una issue, legata in un registro a catena di hash; il nodo la ritira e la porta all'agenda e, se urgente, al telefono.

App del telefono

L'app riceve gli avvisi del nodo: scarica via I2P il file di stato firmato e verifica la firma Ed25519 con la chiave pubblica inquadrata da un QR prima di interpretarne il contenuto. Non dipende da alcun servizio di terzi. Mostra le risorse e i servizi del nodo e l'elenco degli avvisi, e notifica quando compare un nuovo evento o quando il nodo smette di dare segni di vita.

Può seguire più nodi insieme. Oltre allo stato, riceve come avvisi gli accessi (al server e ai servizi), i rilevamenti d'intrusione classificati con CAPEC e gli esiti degli honeypot prodotti da tutanum-edr ed tutanum-esca; segnala le variazioni dei pacchetti del nodo e, se il nodo pubblica un file versione firmato, mostra il banner di aggiornamento. Può usare un router I2P incorporato, con un registro consultabile dentro l'app, invece di un proxy esterno, e lascia scegliere ogni quanto controllare. Il router incorporato avvia il proprio netDb da un elenco di reseed imbarcato nell'app, così funziona anche sulle reti che bloccano il reseed via HTTPS; il registro del router è copiabile e azzerabile dalla sua schermata.

Le attività sospette non restano un elenco piatto: l'app le raggruppa in blocchi omogenei (stessa origine e stessa classe d'attacco) a cui si può dare un verdetto di triage, come fa un EDR/XDR: malevola, lecita o falso positivo, con un filtro per vedere solo ciò che resta da valutare. Il verdetto è un'annotazione locale del dispositivo, ma viene anche rimandato al nodo, firmato con una chiave del telefono (da arruolare una volta sul nodo): un canale di sola scrittura, autenticato, su cui l'app deposita il verdetto attraverso lo stesso eepsite. Un blocco segnato come falso positivo il nodo smette di pubblicarlo, così l'app non ripropone ciò che hai già giudicato innocuo (è l'anello di retroazione che molti EDR/XDR usano per imparare dai triage). Il lato nodo affianca inoltre ai rilevamenti singoli una correlazione comportamentale: più eventi che da soli sono rumore, se compaiono in sequenza entro una finestra di tempo, diventano un unico avviso "comportamento sospetto". Dove ha senso le catene sono legate per soggetto (stesso utente o stesso indirizzo), così da distinguere, per esempio, un brute force seguito da un accesso riuscito dalla stessa origine (un break-in) dal rumore di tentativi e accessi scollegati; il punteggio è dinamico (parte dalla gravità della catena e sale con il legame di soggetto, il numero di segnali corroboranti e il coinvolgimento di un'utenza di root).

La prima versione era Android nativa (in android/); la riscrittura in Flutter (Android, Linux e web) è a sorgente aperto con licenza AGPL-3.0 nel repository dedicato tutanum-avvisi-app.

Codice, segreti e licenza

Tutto il codice è su GitLab: gitlab.com/Rekcah/tutanum → servizi/ (i link qui sopra puntano ai singoli file nel repository).

I segreti (chiavi di firma, token, passphrase) non stanno nel repository: gli script li leggono da file esterni, creati al momento della messa in opera. I contenuti dei siti web e delle applicazioni servite dal nodo non fanno parte di questi strumenti.

Il codice è distribuito con licenza AGPL-3.0: chi lo modifica e lo offre, anche come servizio di rete, deve renderne disponibile il sorgente. La documentazione del progetto resta CC BY-NC-SA 4.0. Per la messa in opera vedi le guide Classico e Lieve.