Sistemate le voci a 0 della home. Il collector fail2ban contava solo il jail sshd per SecureBox .51 (0 perche' SSH e' a sola chiave): ora somma TUTTI i jail locali, quindi i ban di apache-modsecurity contano. securebox-crowdsec-stats.sh riscritto: legge il DB SQLite di CrowdSec in sola lettura (0,12s contro i >2 min di cscli) e conta anche la blocklist community CAPI applicata dai bouncer LAN -> ~33.000 IP attivi, ~20.000 oggi. Il vecchio crowdsec_today era rotto (attivi_ora - attivi_a_mezzanotte, negativo perche' le decisioni scadono TTL~4h -> sempre 0). Card difese resa modello headline+scomposizione: "Attualmente bloccati" = unione fail2ban+UFW+CrowdSec, le card CrowdSec/UFW ne sono il dettaglio (non doppio conteggio). Kali .53 = 0 confermato corretto (pentest interna, nessun servizio pubblico). Audit finale: storico 20.253 = .51+.53+.125, incidenti total = aperti+risolti, frasi apprese = DB.
Le 9 eccezioni ModSecurity che spegnevano l'intero WAF per host (git, grafana, armandillo, ilgiornaledellapa, panel, helpdesk, serviziwebgratis) migrate a ctl:ruleEngine=DetectionOnly: ispezione e logging ripristinati ovunque (git passa da 0 a centinaia di voci audit, attacchi loggati come Warning senza bloccare), zero rischio di rottura, dati raccolti per passare poi a blocco pieno con esclusioni precise. agentiai.armandillo.it portato a protezione PIENA (falso positivo 951240 riproducibile): rimossa solo la famiglia 951, SQLi e traversal in ingresso ancora 403. Baseline HTTP di tutti i siti invariata.
Scoperto che ModSecurity blocca gia' (7.854 volte via 949110, HTTP 403 reali): il jail apache-modsecurity era pero' cieco perche' leggeva modsec_audit.log (formato seriale) invece di error.log dove i deny sono nel formato atteso -> 823 match, ora banna i recidivi. Aggiunto 93.56.205.72 (IP di casa) a ignoreip: in hairpin-NAT il traffico da casa appare come [client 93.56.205.72] e senza whitelist un test poteva autobannare l'IP di casa su tutti i jail. Risolti 2.780 errori "PCRE limits exceeded" sulla regola 951120 (backtracking su risposte grandi di agenda): eccezione chirurgica ctl:ruleRemoveById=951100-951300 solo per agenda, non ruleEngine=Off.
Apprendimento reso conforme alla regola scraping: da ThreadPoolExecutor (10 worker paralleli) a sequenziale con jitter 5-9s, minimo 45s per dominio, User-Agent identificativo con contatto, richieste condizionali ETag/Last-Modified, kill-switch su 403/429. VERA causa del tetto a ~1.000 frasi/giorno: mancava l'indice su learned_phrases.phrase (244k righe) -> ogni controllo duplicato era una scansione completa (429 ms). Con CREATE INDEX idx_lp_phrase la fase di elaborazione passa da 84 minuti a 155 secondi (~30x). Kill-switch reso per-dominio: un 403 da un sito (oracle, cert.be) esclude solo quel dominio e prosegue, invece di abortire l'intera passata. Rimossi oracle.com e cert.be da fonti.txt (403 anche all'UA onesto).
L'ingester Suricata promuoveva a incidente ogni firma, inclusa la reputazione IP (Dshield/CINS/Spamhaus) e le scansioni verso porte non in ascolto: 49 incidenti ogni 5 minuti, coda open a 4.180. Due regole di merito: le firme di sola reputazione e le sonde verso porte chiuse restano alert ma non aprono incidenti. La regola porte-chiuse e' dinamica (legge /proc/net, cache 5 min): se domani si espone un servizio nuovo torna a generare incidenti da sola. Nuovi incidenti da 49 a 0-3 ogni 5 min. Arretrato di 3.884 incidenti reputazionali chiuso come resolved con nota (elenco reversibile). Verificato che SQLi/scan su porte esposte restano incidenti.
Il vero colpevole della catena: services/alert_manager.py chiamava create_app() a OGNI save_alert() -> un FileHandler mai chiuso per alert, 1020 fd saturati su 1024, il DB non si apriva piu' e l'errore rientrava nel loop a ~400 righe/s nel journal (63 MB ogni 10 min, 5 file corrotti, 9 jail fail2ban con backend=systemd resi ciechi). Fix: app Flask in cache (fd 1020->8), LimitNOFILE 8192, log dell'ingester su file dedicato (journal da 2.400 a 1 riga/min), journal corrotti rimossi. Trovato anche un bug per cui ogni restart rimandava indietro l'offset (SIGTERM salvava una copia stantia) facendo rileggere 1,5 GB di eve.json, e aggiunta la detection del troncamento copytruncate al logrotate. busy_timeout 30s sul DB + commit per-incidente nell'AI resolver (teneva il lock esclusivo per 10+ minuti).
Home semplificata: rimosse le 5 card dei nodi Proxmox (fail2ban=0 perche' in LAN, protetti dal bouncer CrowdSec locale che ha ~31.622 IP, ma contarli sarebbe stato doppio conteggio della stessa community blocklist). Restano le 3 card originali: SecureBox .51, Kali .53, ARPAWEB Mail .125. Il collector continua a raccogliere gli 8 server nel JSON per riferimento futuro. Card "IP bloccati oggi" ora somma banned_today (fail2ban 3 server) + crowdsec_today (delta dal midnight snapshot). Cron /usr/local/bin/securebox-crowdsec-stats.sh (ogni 5 min) tiene traccia di midnight_date e midnight_count in /var/securebox/data/crowdsec_stats.json. AI Incident Resolver: BATCH_SIZE 10 -> 50 in /var/www/securebox/ai_incident_resolver.py. Con cron ogni 30 min = 100 risolti/h teorici contro ~60-80 nuovi/h creati da suricata_ingester. Deficit favorevole all'AI di 20-40/h, la coda open dovrebbe svuotarsi in 2-4 giorni.
Utente ha notato che l'aggregato mostrava solo secure-box + kali + arpaweb. Aggiunto: server3 (.81), pve10 (.90), pve-ai (.108), proxmox (.203), proxmox5 (.204). Distribuita chiave id_ed25519_collector root@.51 su tutti e 5 (authorized_keys). Nuova funzione parse_host_root() nel collector che chiama esplicitamente `fail2ban-client status sshd` via ssh -i. Se un nodo e' offline: status=unreachable, mantiene il cumulativo storico dal state file, la card mostra "irraggiungibile". Aggiunte 5 card colore arancio (#f59e0b) sotto Fail2Ban infrastruttura nella home + JS che le popola dal payload aggregate. Il collector gira via systemd timer ogni 15 min. Test /api/fail2ban/aggregate: 8 server ora restituiti.
Utente ha chiesto perche' i 3 server non bannavano oggi. Diagnosi: SecureBox .51 fail2ban sshd era cieco da quando ho fatto "journalctl --vacuum-time=1h" stamattina per pulire il journal saturato dallo spam Telegram. Il filter systemd si e' rotto (ERROR "Bad message") e ha lasciato il jail sshd senza monitoring: "No file is currently monitored" malgrado 439 failed password nel /var/log/auth.log di oggi. Fix in /etc/fail2ban/jail.local sezione [sshd]: aggiunto `backend = polling` per bypassare il journal e leggere direttamente il file. Restart, ora fail2ban rimonita auth.log e ban i nuovi attacchi (i vecchi >600s sono ignorati per findtime). Nota: Kali .53 e ARPAWEB .125 hanno 0 ban perche' sono VM interne senza esposizione esterna — normale, non un bug.
Backup 32 file .bak (528 MB inclusi securebox.db.pre-wal) spostati da /root+/var/securebox della VM 102 su TerraMASTER (.90:/RAIDZ-30Tb/bk-VM-Armandillo/securebox-history/config-backups/2026-07-22/) via scp con verifica SHA256, 0 fallimenti. Distribuita chiave id_ed25519_bak_to_tm da root@.51 a authorized_keys di root@.90. Fix crowdsec_active nell'endpoint aggregate: cscli decisions list sotto cap CPU 35% impiegava 30+s. Cron /usr/local/bin/securebox-crowdsec-stats.sh ogni 5 min aggiorna file JSON /var/securebox/data/crowdsec_stats.json; l'endpoint legge il file in millisecondi. Ora la card "Attualmente in jail" mostra il totale corretto (fail2ban + UFW + CrowdSec = 3775 vs 3732 prima). Fix Telegram invii: l'aver messo log.setLevel(WARNING) sul logger securebox.telegram silenziava anche gli INFO utili ("Telegram inviato"). Rimosso setLevel, cambiato SOLO il messaggio "disattivate" a livello DEBUG (silenzioso). Ora gli invii veri tornano visibili nei log. Test da diagnostica: send() torna True.
Dopo aver messo cap CPU/RAM ai daemon la VM era stabile ma i daemon consumavano ancora 20-40% CPU. Investigato con ps sort=cputime: rsyslogd 11.5%, journald 10.3%, tail -F /var/log/syslog dentro ids_engine. /var/log/syslog era 36 GB con rate 5 GB/h. Sample: migliaia di righe/s "INFO securebox.telegram: notifiche disattivate (token o chat_id mancanti)". Root cause: services/telegram_notifier.py logga a livello INFO ogni volta che init_config e' chiamato senza env var. suricata_ingester dentro securebox-suricata.service non aveva SECUREBOX_TG_TOKEN/CHAT nel drop-in (le aveva solo securebox.service). Ogni alert Suricata -> save_alert -> Telegram init -> log spam. Effetto cascata su rsyslogd + journald + ids_engine (tail). Fix (3 mosse): log.setLevel(WARNING) sul logger, drop-in telegram-env.conf con env var, truncate syslog + vacuum journald. Risultato: 5024 MB/h -> 27 MB/h (-99.5%). Disco 51% -> 38%.
Terzo freeze VM diagnosticato dall'RRD host: fra 15:35 e 16:04 la CPU totale era 78-85% costante. Il cron ai_incident_resolver dentro securebox-cron.slice (cap 100%) sommato ai daemon di difesa (crowdsec 82% + fail2ban 44% + suricata_ingester 39%) = 4 core saturi. Aggiunti drop-in limits.conf ai daemon di difesa: crowdsec 35% + 300M, fail2ban 30% + 400M, suricata 60% + 1.5G, ids_engine 25% + 300M. Totale difesa garantito = max 190% CPU su 4 core, restano 200% per Apache/gunicorn/cron/altro. Verificato: cap rispettati, webapp 60-80ms. Bonus stesso deploy: 3 API con moduli Python mancanti (/api/syslog/stats, /api/stix/bundle, /api/stix/download) ora restituiscono 501 "Feature non implementata" con messaggio chiaro invece di 500 generico. Guest agent qemu era gia' installato, attivato con systemctl enable --now.
Creato blueprints/_cache_helpers.py con decoratore @cache_seconds(ttl) in memoria per-worker. Applicato a /security (TTL 60s), /api/security_score (60s), /classifica_eventi (300s), /dati_grafico_fonti (300s): erano fra 10 e 23 secondi per query DB pesanti, dopo il primo giro su ciascuno dei 3 worker gunicorn rispondono in ~30ms. Fix pulito ssh_honeypot.py: logging.basicConfig incapsulato in def _setup_logging() e chiamato solo da `if __name__ == "__main__"`, cosi l'import Flask da www-data non tocca piu' il file di log. In precedenza il chmod 664 sul log bastava a farlo funzionare, ma il codice era sporco. Backup in /root/*.bak-*.
/root/move-baks-to-terramaster.sh (chmod 750 root): stasera, quando .90 riaccende, esegui `sudo /root/move-baks-to-terramaster.sh` e lui trova tutti i .bak di /root e /var/securebox (30 file, 528MB di cui il DB pre-wal 528M), verifica ping .90 e mount NFS, crea /RAIDZ-30Tb/bk-VM-Armandillo/securebox-history/config-backups/YYYY-MM-DD, scp con verifica SHA256 pre/post, elimina originali solo dopo conferma hash, alert Telegram al fine con conteggio spostati/falliti.
Test sistematico di tutte le route Flask: pubbliche, admin (302 a login), API con X-API-Key (401 senza chiave). Risultato 55/60 verdi. Trovato bug silenzioso su /api/ssh_honeypot/stats: il modulo ssh_honeypot faceva logging.basicConfig al top-level, quando l'API lo importava da gunicorn (www-data) andava in Permission denied sul log di root. Fix con chmod 664 immediato + fix pulito codice in successiva iterazione. Segnalati 4 endpoint lenti (fixati con cache) e 2 API con moduli Python mancanti (/api/syslog e /api/stix - feature incomplete non usate, non urgenti).
VM andata in freeze verso mezzogiorno (276% CPU, banner exchange SSH in timeout). Root cause: la unit systemd suricata-ingester.service creata stamattina era doppione di securebox-suricata.service che esisteva gia' (dimenticato di controllare) => due processi identici che leggevano lo stesso eve.json in parallelo, entrambi in loop di ingestion sul backlog. Rimossa la mia unit, sulla vera messo drop-in con MemoryMax=500M e CPUQuota=40%. Shutdown ACPI + start ha ripristinato in 45s. Contestualmente aggiunto nice -n 15 + ionice -c 3 ai 7 cron pesanti (apprendimento_auto_v2, batch_generate_embeddings, active_defense, ai_incident_resolver, proactive_hunter, fim_ransomware, fine_tuning_minilm) per evitare che le sovrapposizioni facciano stallare Apache/gunicorn. Configurato logrotate aggressivo: /var/securebox/log/securebox_app.log daily + maxsize 200M + rotate 3 + copytruncate (era arrivato a 3GB in 24h); altri 16 log SecureBox daily + maxsize 100M + rotate 7 + compress. Log dir passata da 4GB a 103MB. Disco / al 50% con 47GB liberi.
Dopo il cleanup di emergenza il disco / era comunque al 96%: qcow2 della VM espanso da 50 a 100 GB via `qm resize 102 scsi0 +50G` sul nodo proxmox5 (storage local, 307G liberi su 431G). Dentro la VM installato cloud-guest-utils, spostato il backup GPT header alla fine reale con sgdisk -e, growpart /dev/sda 2, resize2fs online. Nessun downtime, tutti i servizi critici sono restati attivi. Ora ci sono 49 GB liberi per respirare, ma la vera fix e' configurare logrotate piu' aggressivo su /var/securebox/log/securebox_app.log (che era 3 GB in 24h).
Mattinata di consolidamento SecureBox. VM 102 portata da 6 a 8 GB RAM (stop/start via API Proxmox, la VM e' su proxmox5 .204 dal 19-20/07, non piu' su pve-ai .108). Creata unit systemd suricata-ingester.service per il processo che ingeriva alert Suricata come orfano PPID=1 (ora Restart=on-failure, MemoryMax=500M). Rimosso cron root "30 4 1,15 * * /sbin/reboot" che riavviava la VM il 1 e 15 di ogni mese (origine dimenticata, nessuno la ricordava). Dopo il reboot il disco / e' schizzato al 100% (gunicorn non riusciva ad avviarsi per mancanza di tempfile): liberati ~2 GB eliminando syslog.1, log rotati modsec_audit, 2 backup DB vecchi (retroA 16/07 + snapshot 17/07) e troncando securebox_app.log da 3 GB alle ultime 5000 righe. Da valutare rotazione piu' aggressiva di /var/securebox/log e configurazione logrotate.
Le pagine /fail2ban e /dashboard/firewall mostravano "IP bannati totali = 0" dopo ogni restart di fail2ban perche' leggevano solo la tabella SQLite in-memory (svuotata quando i bantime scadono). Aggiunti in /api/fail2ban/ summary i campi cumulative_infrastructure (1.350.529 da collector persistente) e cumulative_secure_box. Aggiunto anche currently_banned_all che somma fail2ban + UFW deny (3.719) + CrowdSec decisions (57) = 3.774 IP bloccati adesso (era 0). Fix bug in dashboard_firewall.html che usava s.currently_banned_all invece di t.currently_banned_all (s=f.sshd, t=f.totals). Home: card "Attacchi bloccati oggi" rinominata "IP bloccati oggi" e ora somma banned_today + crowdsec_today, cosi include anche le decisioni CrowdSec del giorno.
Cleanup label frontend. Nella home la card fail2ban aggregato mostrava ARPAWEB Mail su .235 (VPS OVH dismesso il 17/07/2026); il collector JSON puntava gia' correttamente a .125 (VM 346, mail ecosistema attivo), solo l'HTML era rimasto indietro con l'IP del vecchio VPS. Contestualmente rinominata la voce "AI Ollama"/"Server Ollama" in "Server AI" per uniformare il branding (11 occorrenze in index.html + base.html + 7 template admin/dashboard/monitor/chat_tiny). Sostituzioni chirurgiche via sed, restart securebox.service. Verifica live: 0 "AI Ollama" residue, 0 ".235" residue nei template attivi.
Card degli incidenti in home vuote e badge "secure-box" rosso: due bug convergenti. (1) blueprints/api.py:216 controllava check_service_active("secure-box.service") ma quel unit e' inactive da tempo (rimasto disabilitato dopo la migrazione al nome senza trattino, securebox.service, che gira attivo da mesi) -> /api/health rispondeva sempre HTTP 503 status=degraded. (2) /var/securebox/securebox.db (528 MB) era in modalita' rollback journal, con 3+ writer concorrenti (gunicorn 3 worker + ids_engine + http_honeypot + suricata_ingester) i lock si accumulavano al punto che anche sqlite3 CLI con busy_timeout 10s falliva. /api/incidents/stats tornava HTTP 500 {"error":"database is locked"} in 5s. Fix: corretto nome servizio in api.py, DB portato a WAL mode con synchronous=NORMAL/busy_timeout=15000/wal_autocheckpoint=1000, backup DB pre-fix salvato. Ora /api/health torna healthy e /api/incidents/stats risponde in 78ms con 2844 incidenti. Scoperto anche che /usr/local/sbin/suricata_ingester.py gira senza unit systemd (PPID=1) — da integrare in un service dedicato.
Post analisi di tutti i 30 endpoint /api/*: 11 erano gia' protetti con @api_auth_required (session admin O header X-API-Key), 4 con @_admin_required puro, 15 pubblici — di cui 3 esponevano dati sensibili senza filtri. /api/vpn/stats e /api/vpn_status elencavano nomi e IP interni dei 10 peer WireGuard + stato online/offline (utile a correlare "chi e a casa"); il contatore /api/security_events aggregava eventi IDS accessibili senza auth. Aggiunto @api_auth_required a /api/vpn/stats e /api/vpn_status (blueprints/ api.py e network.py) e @_admin_required a /api/security_events (blueprints/ security_monitor.py). Ora rispondono 401/302 senza sessione. Le API della home (/api/sys, /api/ai/status, /api/fail2ban/aggregate, /api/incidents/stats, /ultimo_apprendimento) restano pubbliche per non rompere le card della landing e la /api/blocklist.txt continua a servire le 50 VM via X-API-Key.
Le 7 route della chat (/chat, /chat_tiny, /chat/send, /chat_tiny_send, /chat/stream, /chat/new_session, /chat/favorite) erano pubbliche: chiunque poteva usare l'endpoint verso Ollama .81 come chatbot gratuito e consumare token/CPU. Aggiunto @admin_required a tutte e 5 le funzioni in blueprints/ ai.py. Verificato: GET → 302 /admin/login, POST → 400 CSRF (bloccati perche' senza sessione non si ottiene il token dalla pagina).
Le route /vpn (GET+POST), /download_vpn/<user>, /download_vpn_qr/<user>, /fail2ban e /dashboard/firewall erano pubbliche senza @admin_required. La chain critica era: POST /vpn (username qualsiasi) generava una config WireGuard con genera_config_vpn.sh e /download_vpn/<user> permetteva di scaricarne .conf + chiavi + PSK — chiunque poteva creare un peer valido e entrare in LAN 192.168.1.0/24. Aggiunto @admin_required a tutte e 5 le route (blueprints/ network.py e blueprints/security.py). Verificato: 302 verso /admin/login per anonimi, API summary aggregate (/api/vpn/stats, /api/fail2ban/*) rimangono pubbliche per la home. Aggiunto anche link "Esci" (rosso) nel nav di base.html condizionale su session.admin_logged_in.
Suricata installata su .51 come Intrusion Detection System — ispezione del traffico che passa dal reverse proxy Apache verso i 190+ vhost dell'ecosistema. Signature-based detection, TLS fingerprinting, protocol anomalies. Complementare al WAF ModSecurity (che ispeziona il payload HTTP) e alle blocklist ipset (che filtrano a livello IP): Suricata vede il traffico network-wide con regole community + emerging threats.
Prima applicazione dell'alternativa morbida al piano-egress-firewall.md. Su .204 aggiunta regola OUTPUT `-m set --match-set securebox_blocklist dst -j LOG` (nessun DROP): traccia in kern.log ogni tentativo di connessione outbound verso i 3.749 IP maligni della blocklist condivisa. Kill switch pronto: /root/egress-blocklist-off.sh. Fase di osservazione prima del DROP.
Alert Telegram spurio inviato dal LAN Defender su Kali .53 (google.com risolveva IP diversi via 8.8.8.8 vs router — entrambi Google legittimi 1e100.net, ma un reverse-DNS timeout aveva marcato uno come cdn=False). Patch _is_known_cdn_ip: subnet whitelist statica (Google 142.250/251, 172.217/253, 216.58/239, 192.178/179; Cloudflare 104.16-21, 172.64-69) + retry reverse-DNS con 3 resolver.
Ripristinate le DUE istanze Ollama separate su .108 come da armandopassaro.it/admin/gpu_admin.php: :11434 CUDA=0 (qwen2.5:7b @ctx 32k + nomic-embed-text) e :11435 CUDA=1 (gpt-oss:20b per coder/agentiai). Preload script /usr/local/bin/ollama-preload.sh riscritto per caricare tutti e tre i modelli con keep_alive=-1. Aggiunta ollama-preload.service anche su .81 (non esisteva — modelli caricati solo su prima chiamata client).
200 alert Telegram "ARP SPOOFING? .204" ricevuti tra 20/07 sera e 21/07 mattina — proxmox5 ha due NIC (enp2s0 2.5GbE + enp3s0 100Mb hotplug), il cambio MAC del gateway di uscita era legittimo. Patch: baseline /home/armando/blueteam/data/arp_trusted.json aggiornata + .204 aggiunta ad ARP_EXCLUDE_IPS nel lan_defender.py con nota dual-NIC.
Script securebox-restore-drill.sh su .90 (VMID 999 isolato, storage nvme2). Cron primo sabato del mese 05:00 con rotazione VMID (SecureBox 2x/anno, altre 1x/anno). Restore + boot isolato (link_down su tutte le NIC) + verifica guest agent + destroy purge. Prima run manuale 2026-07-20: VMID 337 restorata e verificata in 162s.
4 job difensivi tornati alla baseline: apprendimento AI 3x -> 6x/g, AI Resolver 1x -> 2x/h, FIM+Ransomware 1x/2h -> 1x/h, Playbook 2x -> 3x/h. DNS blocklist con guardrail MIN_DOMAINS=5000, backup pre-swap e rollback automatico su unbound-checkconf fallito.
unbound su .51 come resolver locale, blocklist 20k domini (URLhaus, phishing.army, StevenBlack). Refresh quotidiano 04:00. Fallback DNS 192.168.1.254 nel resolv.conf.
10 raccolte di regole (9 open source webshell + 1 custom PHP heuristica). Cron notte 03:35, 13.322 file /var/www scansionati, dedup path+hash+regole. Su match: incidente critical + Telegram alert-critico.
Script /usr/local/bin/securebox-bak-to-tm.sh consolida i file .bak* di SecureBox in tarball settimanali (domenica 04:15) su TerraMASTER via .108, verifica hash SHA256, retention 12 archivi (~3 mesi). Notifica Telegram solo su errore.
File dinamico gestito dal playbook (aggiunge DENY di IP attaccanti ogni ora). Escluso dalla lista FIM per eliminare ~24 incidenti high/giorno di rumore.
Due piani formali (docs/piano-egress-firewall.md, docs/piano-restore-drill.md) per allowlist outbound sulle 50 VM protette e restore drill automatico mensile dei backup TerraMASTER.
Whitelist keyword sicurezza ampliata da ~80 a ~185 termini (vendor correnti, malware family, threat intel). Estrazione deterministica con dedup per-frase e campione 8000. Backfill storico applicato: 156 giorni (feb-lug 2026) ricalcolati.
Feed consolidato (fail2ban + UFW + CrowdSec) esposto via HTTPS. Ogni VM pulla 2x/giorno e applica DROP in INPUT e DOCKER-USER. Bouncer CrowdSec verso LAPI centrale (.51:8081) per propagazione <5 secondi.
Sostituisce vecchia logica time-based. Dossier fattuale + RAG su 229k+ frasi apprese + qwen2.5:7b con schema JSON forzato. Guardrail confidence: resolved >=0.75, false_positive >=0.85, auto-mitigazione ufw deny >=0.90.
291 file critici monitorati (hash SHA256). Ransomware scan: 30+ estensioni note, note di riscatto, mass mtime change (>100 file in <60s = cifratura).
SSH_BRUTEFORCE, HTTP_SCANNER, WAF_ATTACK_REPEATED, HONEYPOT_HIT, AI_RECOMMENDED_BLOCK. Whitelist LAN + VPN + IP casa. 3x/ora.
Estrae CVE-YYYY-NNNNN dalle frasi apprese ultime 24h, confronta con dpkg-query, apre incidenti per pacchetti installati vulnerabili. Deduplica seen_cves.
/admin/defense con 7 card (blocklist, CrowdSec, AI Resolver, Playbook, FIM+Ransomware, Incidenti, Apprendimento). Kill switch bottoni per ogni componente.
Root cause pve10 al 100%: journalctl vacuum 200M, truncate log da GB, /root/.cache rimosso. Nuovo local_db_snapshot.sh (SQLite consistent .backup() + tar config critici) come rete di sicurezza se TerraMASTER giù.
DNS-01 manuale via misterdomain.eu, cert valido fino al 04/09. Nuovo cert_expiry_alert.sh (cron 09:00): Telegram 14gg prima scadenza cert wildcard.
save_alert() falliva da active_defense cron ("Working outside application context"). Decorator _ensure_app_context aggiunto via patcher — crea app_context on-demand.
unscp/datipa/trasparenzaincomune fallivano challenge ACME (redirect /.well-known al backend). Aggiunto Alias /.well-known/acme-challenge → /var/www/html su :80 + RewriteCond di esclusione. 3 domini rinnovati a 89 giorni.
Falliva 7/8 notti (tar rc=1 su DB scritto live). Riscritto backup_sys.sh: snapshot SQLite consistent via .backup(), esclusione DB live dal tar, tolleranza tar rc=1. Archivio validato 3.6 GB.
73 pacchetti (18 security: bind9, exim4, gnutls, libssl3/openssl, openssh, kernel, modsecurity-crs). Boot-check 0 errori post-reboot.
nftables/UFW conflitto al boot corrompeva chain INPUT (10k+ pacchetti droppati, VM isolata). Fix: systemctl mask nftables, NAT WireGuard + FORWARD VPN in /etc/ufw/before.rules, boot health check auto-repair.
Metric impostato a 200 per evitare conflitto LAN/VPN quando in casa. In LAN traffico va via enp6s0, fuori casa via tunnel VPN.
/admin/mitre_attack, /admin/vuln_scanner (con POST scan + lock file PID), /admin/ids. IDS Engine come systemd service (6 monitor thread).
6 header applicati globalmente (X-Content-Type-Options, X-Frame-Options, HSTS, Referrer-Policy, Permissions-Policy, X-XSS-Protection) via conf-available/security-headers.conf. Copre tutti i 190+ vhost.
Redis 6379 solo LAN+VPN su .76 e .99. SMB disabilitato su .57. rpcbind (porta 111) chiusa su 5 VM (.51, .57, .86, .117, .112).
Ripristino da backup VM 200 del 30 marzo su .108, stessi IP e chiavi WireGuard. 10 script Python, 4 servizi, 4 blueprint, 9 template ri-deployati.
/etc/modules-load.d/ip6_tables.conf + load-ip6tables.service (Before=ufw.service) per risolvere crash UFW al boot su kernel 6.1.
Corretto da "30 5 * * *" (1x/giorno) a "*/30 * * * *" (48x/giorno). Combinato con 150 frasi/fonte → target 30k frasi/giorno.
Anomaly detection Isolation Forest, HTTP honeypot, threat hunting 6 query, audit log admin, alert persistenti DB, incident response workflow, API auth (10 endpoint), VPN analytics real-time.
ssh_honeypot.service (porta 2200, simula OpenSSH vulnerabile). http_honeypot.service (porta 8888, simula WP/phpMyAdmin/.env). Auto-ban dopo 5 tentativi/hit.
Completamento infrastrutturale su VM 201 (pve1-tools). Guacamole SSH: 29 → 56 connessioni. Kuma HTTP: 39 → 94 monitor.
Rimosso cron backup locale + directory (417 MB liberati). TerraMASTER settimanale domenica 3:00 diventa unico backup attivo.
Dimensionamento hardware per gestire 50 peer WireGuard concorrenti + traffico reverse proxy. Valutato Intel N100 come opzione low-power. Confermata scelta VM su Proxmox come architettura definitiva.
UFW, SSH no-root, fail2ban, sysctl. Verificato via boot check.
.108 da 218→96 vCPU, 172→89 GB RAM. .90 da 66→34 vCPU, 75→66 GB RAM. VM 200 (SecureBox): 6 vCPU, 6 GB RAM, swap 4 GB permanente.
Portata da 258 a 1009 URL verificate in /var/securebox/fonti.txt. CERT nazionali, vendor security blog, CVE feed, pentest blog, threat intel.
Cron ogni 2h. 4 funzioni: auto-blocco IOC da frasi contesto malevolo, correlazione log + threat intel, alert CVE critici Telegram, GeoIP auto-block.
Arricchisce risposte chat AI con contesto dalle frasi apprese (similarità coseno, threshold 0.35). MiniLM locale 384 dim.
Nuovo sistema apprendimento asincrono con log locali per debug. Modelli AI portati a qwen2.5:7b (generalista) e qwen2.5-coder:7b (coder).
SECRET_KEY resa permanente (era rigenerato ad ogni restart, invalidava sessioni). Watchdog riscritto: alert solo eventi critici (login SSH esterno, servizio down, file modificati, risorse >95%).
ModSecurity con Core Rule Set 4.x. MiniLM sentence-transformer locale (all-MiniLM-L6-v2, 384 dim). Fine-tuning settimanale su frasi apprese.
Redesign homepage con tema dark navy/gold. Frasi apprese, fonti attive, IP bloccati oggi, modelli AI aggiornati in tempo reale da API.
Pagine admin per creare peer WireGuard, generare QR code, gestire certificati Let's Encrypt (issue/renew/revoke).
Import iniziale del progetto 3.0-v2026-securebox in Gitea privato. Architettura Flask con Blueprint modulari, SQLite, AI remota Ollama, dark theme navy.
Congelamento della v1.x monolitica prima del refactor Blueprint. Primo record nel DB learned_phrases (12/02/2026 21:41). Cartella conservata come riferimento storico.
Ciclo di rinnovo Let's Encrypt su tutti i vhost del reverse proxy. Prima ricognizione dell'inventario cert dopo la crescita a 100+ domini. Occupazione disco 26G/98G.
Test completo pubblicazione SSH via reverse proxy e regole UFW. Base per la successiva formalizzazione della VPN client con metric 200 e route-splitting LAN/tunnel.
Prima integrazione con endpoint Ollama remoto (192.168.1.81:11434). Base per quello che diventerà l'ecosistema multi-modello (Ollama .81 + .108 con qwen2.5:7b).
Fine dell'esperimento parallelo Tailscale (config residue rimosse), WireGuard diventa unico stack VPN. 53 messaggi di troubleshooting configurazione peer.
Valutata migrazione dell'intera VM in un container Docker (~22 GB al tempo). Approccio poi accantonato: la complessità di stack systemd interni non giustificava il refactor.
Prima versione strutturata: unico app.py con tutti gli endpoint, integrazione moduli monitor/eventi_ai/minilm. Nessun blueprint ancora, secret_key hard-coded.
Nuovo logo con palette aggiornata per la fase produttiva del progetto. Precede il tema dark navy/gold che arriverà con la v2 nel marzo 2026.
Prima riga registrata in /var/log/securebox/pulizia_system.log ("INIZIO PULIZIA"). Da qui in poi log continui di attività della piattaforma v1.
Trasferimento da mini PC bare-metal a VM Proxmox per liberare l'hardware e per beneficiare di snapshot + backup vzdump. IP interno 192.168.1.51 mantenuto.
Evoluzione della home page — abbandono progressivo del tema verde monitor verso un layout più strutturato con card e sezioni.
Studio delle alternative firewall/VPN prima di consolidare lo stack. Confermata scelta WireGuard su Debian + UFW + fail2ban vs router dedicati.
Definita architettura AI multi-modello locale: MiniLM per embedding, GPT-2 per generazione, Phi-mini per chat. Reverse proxy e firewall auto-apprendente condividono la stessa fonte di apprendimento.
Formalizzazione del servizio come unit systemd (auto-start + restart on failure). Fine dei launch manuali via script shell — piattaforma sempre attiva.
Esplorazione container per portabilità e cleanup. Bloccato dalla necessità di privilegi netfilter/iptables/wg incompatibili con Docker rootless. Rinviato.
Prototipo di rewrite frontend con stack moderno JS. Abbandonato: over-engineering per un tool operativo — si mantiene Flask + Jinja per semplicità operativa.
Piano formale per migrare da bare-metal N2840 a VM Proxmox con backup vzdump settimanali. Base della migrazione che verrà eseguita il 1° novembre.
Test di riproducibilità dell'installazione su VM Debian 12 (proof-of-concept). Precede la migrazione definitiva di novembre 2025.
Primo tar.gz completo /etc + /var + /var/www/securebox archiviato su TrueNAS-2 (share bk-Secure-Box). 9.2 GB. Backup notturni 03:00 dal 28/07/2025 in poi.
Aggregatore di tutti i task periodici in un singolo runner. Prima versione di "Fail2AI" (fail2ban + AI): gestione IP sospetti con correlazione euristica tra log auth/UFW e frasi apprese. Base della difesa attiva 2026.
Prima versione della UI web con estetica retro-terminale (background #000, testo #0f0, monospace, bordi 2px verdi). File log_ai.html + index.old. La "versione originale stile monitor" da cui è nato tutto.
Stabilizzati: apri_ssh.sh, backup_securebox.sh, estrai_frasi_per_gpt2.sh, estrai_frasi_per_training.sh, rss_apprendimento.sh, telegram_notify.sh, solo_lan_ssh.sh, verifica_log_json.sh. Layout definitivo di controllo.
Documentazione strutturata di scopo, funzioni, componenti e workflow. Base della guida utente/admin generata poi nel 2026.
minilm_ai.py — primo motore di ricerca semantica basato su sentence-transformer locale (all-MiniLM-L6-v2, 384 dim). Base per il RAG che verrà nel 2026.
Guasto disco della prima installazione. Ripristino da tar di backup + installazione parallela completa su Debian 12 pulita (192.168.1.51/52). Evento che consolida la pratica di backup notturno tar.
Integrazione locale di piccoli LLM per chat (chat_tiny.py, chat_gpt2.py). Prima sperimentazione di AI conversazionale sul progetto.
Primi file operativi: monitor.py, eventi_ai.py, diagnostica_avanzata.sh, auto_restart_servizi.sh, check_servizi.sh, fail2ai_auto_ban.sh, rotazione_pdf.sh, forza_backup_manuale.sh. Origine del progetto — raccolta di script di monitoraggio e primo firewall auto-apprendente su hardware N2840.
Primo tentativo di installare Secure-Box in un container LXC su Proxmox per tenerlo staccato dal sistema principale. Debian 12 in LXC. Approccio poi accantonato in favore di installazione bare-metal sul mini PC dedicato.
Generata la prima immagine grafica ufficiale del progetto adottata come logo identificativo. Prima identità visiva coerente per la piattaforma.
Grosso ciclo di reinstallazione step-by-step su Intel Celeron N2840, 8 GB RAM, 500 GB SSD, zram 1,5 GB. Stack Debian 12 minimale + script custom. Prima versione realmente stabile per uso continuativo.
Idea iniziale — Intel i7 3770K, 16 GB RAM, 3x4TB HDD + NVMe 500 GB, scheda 2.5 Gb, 2x1 Gb, integrata. Obiettivo: firewall + VPN casalinga tra modem Fastweb e LAN, con variante Lite su N2840 come installazione low-power secondaria. Prima definizione delle funzioni base: protezione rete + accesso VPN da fuori.