25 marzo 2026 · 10 min lettura
Intelligenza Artificialeduck.ai promette chat AI senza tracciamento: nessun log, nessun IP, accordi con Anthropic e OpenAI. Ma DuckDuckGo ha già tradito questa fiducia una volta.
Self-HostingLa cloud sovranità europea è sovereignty washing: i datacenter sono in UE, le chiavi restano a Seattle. Gaia-X è fallito, NIS2 stringe. Il homelab risponde.
Self-HostingIscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
900k siti WordPress esposti a RCE critico, 500k a file read su wp-config.php. Se ospiti WordPress in homelab o su VPS, ecco cosa fare nei prossimi 30 minuti.
365.930 eventi di rete in 48 ore. Questo è il volume che attraversa il mio homelab ogni due giorni. Flussi TCP, handshake TLS, query DNS, tentativi SSH, scan WordPress. In mezzo a questo rumore, 571 alert reali e 4 tentativi di Remote Code Execution.
La maggior parte degli homelabber installa Suricata, guarda i log per una settimana, poi smette. Troppo rumore, troppi falsi positivi, nessun contesto. Ho deciso di risolvere il problema in modo diverso: ho costruito AIWALL, un sistema di difesa di rete che usa un LLM per analizzare gli alert, un Raspberry Pi 5 come gateway attivo e un correlatore multi-sorgente che incrocia Suricata, DNS e log dei reverse proxy. Tutto self-hosted, costo zero.
Funziona. Gira in produzione da settimane. Ecco come l'ho costruito e cosa ho imparato. Se hai seguito la saga delle vulnerabilità negli AI IDE o degli attacchi alla supply chain, capisci perché un IDS nel proprio homelab non è più un lusso.
AIWALL non è un singolo demone su un server. È un sistema distribuito su tre nodi, ciascuno con un ruolo preciso.
Internet
|
v
[ Cloudflare Tunnel ] --> [ Reverse Proxy ] --> Web app sulla LAN
|
v
+-----------------------------------------------------------+
| RPi 5 - GATEWAY |
| Suricata IPS (selective drop) + DNS sinkhole (Blocky) |
| API agent + nftables ban/rate-limit |
+-----------------------------------------------------------+
|
v
+-----------------------------------------------------------+
| Proxmox Host - SENSORE PASSIVO |
| Suricata IDS (2 interfacce) + CrowdSec |
+-----------------------------------------------------------+
|
v
+-----------------------------------------------------------+
| Container LXC - ORCHESTRATORE (il cervello) |
| Scoring engine + LLM (Groq) + Correlatore + Telegram bot |
| Alert store (SQLite) + Prometheus metrics + Dashboard |
+-----------------------------------------------------------+
|
v
[ Monitoring: Grafana + Loki + Prometheus ]Il Raspberry Pi 5 è il gateway fisico della rete. Tutto il traffico passa da lì. Suricata gira in modalità IPS, combinando analisi passiva e drop attivo dei pacchetti malevoli. Sulla stessa macchina gira Blocky, un DNS sinkhole che blocca 280.000 domini tra malware, phishing, tracking e advertising.
Il Proxmox host fa da sensore passivo. Suricata IDS monitora due interfacce di rete: una per il traffico LAN e una per la VPN overlay (Tailscale). CrowdSec analizza i log e mantiene una blocklist comunitaria di oltre 5.000 IP malevoli aggiornata in tempo reale.
Il container orchestratore è il cervello. Oltre 9.000 righe di Python che leggono gli eventi EVE di Suricata, li scorano con un engine deterministico, correlano alert da fonti diverse, invocano un LLM quando serve e mandano notifiche su Telegram con bottoni per bannare o ignorare. Tutto su un container LXC con 1 GB di RAM.
Questo è il principio architetturale più importante di AIWALL. Il risk score è deterministico. L'LLM è un consulente, non un decisore. Ho visto troppi progetti delegare la classificazione degli alert a un modello linguistico e finire con falsi positivi allucinati o, peggio, minacce reali declassate perché il modello non aveva contesto.
Lo scoring funziona così. Ogni alert Suricata ha una severity (1 = critica, 2 = media, 3 = bassa). Il peso base è: Sev1 = 25 punti, Sev2 = 10, Sev3 = 2. Poi si applicano moltiplicatori di contesto:
Il risultato è uno score da 0 a 100. L'LLM viene invocato solo quando il punteggio supera una soglia configurabile. Nelle ultime 48 ore, su 148 analisi completate, l'LLM è stato chiamato solo 18 volte. La maggior parte del traffico viene gestita dal solo scoring deterministico. Questo significa meno costi API, meno latenza, meno rumore.
Quando lo score supera zero, AIWALL invia il batch di alert a Groq con il modello llama-3.3-70b-versatile. Perché Groq e non OpenAI o Anthropic? Tre motivi: è gratis (free tier), è veloce (media 0.85 secondi per risposta nel mio sistema), e il modello 70B è abbastanza capace per analisi di sicurezza senza essere overkill.
L'LLM riceve tre livelli di contesto. Il batch corrente con gli alert filtrati. La storia degli ultimi 30 minuti per vedere pattern in evoluzione. E il tracker degli IP ricorrenti nelle ultime 6 ore per identificare attacchi multi-fase — lo stesso IP che prima scanna le porte SSH e poi prova un exploit HTTP.
La risposta è JSON strutturato. L'LLM restituisce: livello di rischio, summary in italiano, IP sospetti, pattern identificati e una raccomandazione operativa. Se il JSON non parsa, AIWALL degrada gracefully — logga l'errore e va avanti. Zero errori LLM in produzione finora.
Un alert Suricata isolato dice poco. Un alert Suricata + un blocco DNS malware dallo stesso IP entro 5 minuti dice molto. Questo è il lavoro del correlatore multi-sorgente.
AIWALL incrocia tre fonti: gli alert Suricata (signature-based), i blocchi DNS di Blocky (reputation-based) e i log del reverse proxy (pattern-based). Quando le fonti convergono, il correlatore genera alert compositi con priorità elevata.
Tre tipi di correlazione implementati:
In due giorni di produzione: 33 correlazioni DNS_SURICATA_WEAK e 6 correlazioni totali segnalate. La correlazione ha identificato pattern che nessuna singola fonte avrebbe catturato.
Ogni client TLS ha un'impronta digitale — il JA3 hash — calcolata dai parametri dell'handshake. Cobalt Strike, Metasploit, Sliver, Empire: ognuno ha un JA3 noto. AIWALL mantiene un database di 25 hash malevoli e li confronta in tempo reale con ogni handshake TLS catturato da Suricata.
Un match JA3 non è un falso positivo. Se il TLS handshake del tuo traffico ha la stessa impronta di Cobalt Strike, hai un problema serio.
La maggior parte degli IDS guarda solo il traffico esterno. Ma il lateral movement — un attaccante che si muove tra i nodi interni dopo aver compromesso un servizio — avviene tutto dentro la LAN. AIWALL ha un modulo dedicato.
L'internal monitor funziona in due fasi. Nella fase learn (7 giorni di default), osserva tutto il traffico LAN e costruisce una baseline: quali container parlano con quali, su quali porte, con quale frequenza. Oltre 120 flow nella baseline attuale, decine di migliaia di flow interni processati. Nella fase enforce, ogni connessione fuori baseline è un'anomalia — potenziale lateral movement.
Se un container che normalmente parla solo con il database inizia improvvisamente a connettersi ad altri servizi su porte non standard, AIWALL interviene. Il sistema può segnalare, limitare o bloccare il traffico anomalo in base alla configurazione.
Un IDS che manda solo notifiche è un IDS che ignori dopo tre giorni. AIWALL ha un bot Telegram completo con comandi, bottoni inline e un sistema di approvazione per le azioni di blocco.
Quando arriva un alert critico, il bot manda una notifica con tre bottoni: [Ban], [Rate-Limit] e [Ignora]. Premi Ban e l'IP viene bloccato sul gateway in tempo reale. Il sistema supporta sia la modalità con approvazione umana che quella completamente automatica, configurabile in base al livello di rischio.
Il bot supporta 15 comandi: dallo stato in tempo reale ai top 5 IP sospetti, dalla storia di un indirizzo ai conteggi giornalieri, fino al ban e unban manuali. Gestisco la sicurezza del mio homelab dal telefono mentre sono in fila al supermercato.
Il reader dei log del reverse proxy ha intercettato nelle ultime 48 ore: 36 tentativi di scan WordPress (path traversal verso wp-admin, wp-login, xmlrpc.php) e 4 tentativi di Remote Code Execution. Gli scanner automatici provano tutto, indipendentemente dallo stack reale del sito.
Sul fronte DNS, il sinkhole ha bloccato quasi 100 richieste distribuite tra telemetria, beacon, advertising e altro. Un potenziale tentativo di DNS tunneling rilevato. I numeri sembrano bassi? È perché funziona: 280.000 domini già bloccati a livello DNS significa che la maggior parte del traffico malevolo non raggiunge nemmeno Suricata.
AIWALL espone più di 50 metriche Prometheus. Risk score in tempo reale, latenza LLM, eventi per tipo, alert per severity, correlazioni, anomalie interne, stato del bot Telegram, attacchi web, blocchi DNS. Tutto finisce in Grafana.
I numeri che contano dopo 48 ore di produzione:
Niente. O quasi.
Un Darktrace per PMI parte da 50.000 dollari/anno. Un CrowdStrike Falcon Go da 60 dollari/dispositivo/anno. AIWALL non è al loro livello — non ha machine learning su petabyte di telemetria — ma per un homelab con una decina di container e diversi domini pubblici, fa il suo lavoro. E lo fa gratis.
AIWALL non è un prodotto. È un progetto che ho costruito per il mio homelab e che puoi adattare al tuo. Servono:
Se lo costruisci, mandami un messaggio — voglio sapere cosa rilevi nella tua rete.
Ho una decina di container, diversi domini pubblici e un Raspberry Pi da 130 euro che sorveglia tutto. In 48 ore ha processato 365.930 eventi, identificato 4 tentativi di RCE, correlato 33 pattern sospetti e non ha generato un singolo falso positivo critico. Il tuo homelab sa chi bussa alla porta?
Fonti e riferimenti: Suricata IDS/IPS, CrowdSec, Groq Cloud, Blocky DNS, AbuseIPDB. Dati di produzione dal sistema AIWALL dell'autore, marzo 2026.