16 giorni, 4.805 cicli di analisi, un evento CRITICAL che non era quello che sembrava. Questo è il resoconto onesto di AIWALL — aiwall homelab ids aggiornamento — da quando l'ho messo in produzione il 25 marzo fino a oggi.
Nel post originale su AIWALL avevo descritto l'architettura: un IDS su LXC Proxmox con Suricata per l'ispezione del traffico, Blocky per il DNS blocking, e un LLM locale che si attiva solo quando lo scoring supera una soglia precisa. L'idea era costruire qualcosa di leggero e osservare cosa succedeva in una rete reale. Bene — ecco cosa è successo.
I numeri reali di 16 giorni in produzione
Dal 25 marzo al 10 aprile 2026, AIWALL ha completato 4.805 cicli di analisi — uno ogni cinque minuti, senza interruzioni. Il load average sul LXC Proxmox si è assestato su circa 1.4. La RAM totale del sistema: circa 103 MB.
Per contestualizzare: Security Onion, la distribuzione standard per chi vuole Suricata in produzione con Zeek e log aggregation, richiede minimo 8 GB di RAM per una valutazione rapida in VM (modalità Eval) — 24 GB per un deployment standalone completo. Su hardware entry-level homelab, quel requisito è già un problema. AIWALL con 103 MB è un ordine di grandezza diverso, e il motivo è strutturale: il LLM rimane dormiente il 99% del tempo e si attiva solo per le escalation.
Sul fronte DNS: 1.460 query bloccate in 509 batch, circa 90 al giorno. Meno di quanto mi aspettassi. Il range tipico in homelab con pochi dispositivi è tra il 20% e il 50% delle query totali — un utente su HackerNews ha riportato 17.000 blocchi su 43.000 query (39%) con una rete normale. Il mio 90/giorno è nella fascia bassa, probabilmente perché ho pochi dispositivi attivi e Blocky usa blocklist conservative. Blocky pesa circa 10-20 MB a riposo, contro i 60-100 MB di Pi-hole — e non porta con sé lighttpd, PHP-FPM o SQLite.
Il 30 marzo alle 21:08: score 100/100 per quasi un'ora
L'evento più significativo dei sedici giorni. Alle 21:08 del 30 marzo lo scoring di AIWALL è andato a 100/100 e ci è rimasto per quasi cinquanta minuti. Il sistema ha escalato dalla modalità deterministica a LLM-full e ha inviato circa dieci alert su Telegram in automatico. Alle 22:13 il traffico si è normalizzato spontaneamente. Nessuna azione da parte mia.
Causa: oltre 300 alert Suricata con firma "ET INFO Session Traversal Utilities for NAT", tutti generati da un singolo dispositivo interno in un lasso di tempo ristretto. Classe STUN — il protocollo usato da VoIP e WebRTC per attraversare i NAT domestici.
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
Self-Hosting
Authentik SSO homelab: un login per 14 container, zero password dimenticate
Authentik Enterprise come identity provider self-hosted: SSO OAuth2/OIDC configurato su Grafana e Forgejo nel nostro homelab Proxmox con 14 container.
Ho verificato. Le regole Suricata SID 2016149 e 2016150 sono informational, non malicious. Non segnalano un attacco — segnalano la presenza di traffico STUN in rete. Bill Meeks su Netgate Forum è diretto: "There is nothing inherently malicious about this alert. In fact, it is an informational alert." La classificazione "Attempted User Privilege Gain" che Suricata assegna a questi SID è, in reti domestiche, quasi sempre un falso positivo.
La raccomandazione standard della community Suricata per reti domestiche: disabilitare esplicitamente SID 2016149 e 2016150. L'ho fatto. Il sistema ha smesso di escalare su traffico STUN.
In concreto, AIWALL homelab IDS ha funzionato: AIWALL ha funzionato correttamente. Ha visto 300+ alert in 50 minuti, ha escalato, ha notificato. Il problema non era nel sistema — era nella configurazione delle regole Suricata, che per una rete domestica devono essere calibrate diversamente rispetto a un ambiente enterprise. Questo è il tuning che ogni installazione IDS richiede, e che nessuno fa nei primi giorni.
Il falso positivo DGA e CloudFront
Il secondo episodio riguarda il rilevamento DGA — Domain Generation Algorithm, la tecnica usata dai malware per generare domini di command-and-control difficili da bloccare a priori.
AIWALL ha flaggato come sospetto un dominio con pattern di caratteri pseudocasuale. Era un endpoint di CloudFront — la CDN di Amazon.
CloudFront, come Akamai e Fastly, usa subdomain generati algoritmicamente per il bilanciamento del carico. Dal punto di vista di un rilevatore DGA, questi nomi sono indistinguibili da quelli generati da un malware: entropia alta, nessuna parola riconoscibile, pattern casuale. Elastic Security lo documenta esplicitamente nelle proprie linee guida: "Exceptions can be added to the rules in order to ignore false positives such as content delivery network (CDN) domains that may use pseudorandom domain names."
I paper di ricerca sul rilevamento DGA con LLM riportano un tasso di falso positivo del 4% con Llama3 8B fine-tuned su 68 famiglie malware (94% accuracy complessiva). I sistemi senza fine-tuning specifico — come quello in AIWALL, costruito da zero — hanno tassi significativamente più alti. Splunk riporta 1.03% per il proprio modello proprietario con anni di training su dataset specifici. Un sistema homebrew senza dataset dedicato si aspetta tassi nell'ordine del 5-10%.
CloudFront è ora in whitelist. CDN come Akamai e Fastly anche. Non è una soluzione elegante — ma è quella corretta. Qualsiasi sistema DGA, commerciale o homebrew, richiede un elenco di eccezioni mantenuto.
Il bug sul parser timestamp nginx: aperto
C'è un terzo problema, ancora aperto.
I log di nginx usano il formato europeo per i timestamp: dd/Mon/YYYY:HH:MM:SS. Il parser di AIWALL non gestisce correttamente questo formato e genera WARNING ricorrenti. Non è bloccante — il sistema continua a funzionare, gli altri moduli operano normalmente — ma è rumore nel log operativo.
Lo scrivo qui perché questo tipo di bug — piccolo, non critico — tende a restare aperto a lungo. Documentarlo pubblicamente è un modo per non dimenticarlo.
Gli aggiornamenti del 7-8 aprile al codice
Nella finestra 7-8 aprile ho aggiornato internal_monitor, blocky_reader e dns_reader. I dettagli di implementazione non li espongo qui — ma il senso degli aggiornamenti era ridurre il rumore su eventi che il sistema classificava come anomalie senza che lo fossero davvero.
Il pattern è quello classico di qualsiasi IDS in fase di rodaggio: si parte con regole conservative, si osservano i falsi positivi, si affina. Non è un difetto del sistema — è come funziona il tuning in produzione reale. Chiunque abbia mai configurato Suricata da zero sa che i primi giorni sono pieni di alert che non significano nulla.
Il 99% del tempo: score 0, LLM dormiente
Tolto l'evento del 30 marzo e i falsi positivi in fase di calibrazione, la situazione normale di AIWALL è questa: score 0/100, LLM inattivo, sistema in ascolto passivo.
4.805 cicli completati. Il modello LLM è stato interpellato in una frazione minima di questi. Questo è il design — il layer deterministico gestisce la quasi totalità degli eventi. Il LLM si attiva solo quando lo scoring supera la soglia di escalation, e la maggior parte delle reti domestiche non raggiunge quella soglia quasi mai.
È anche il motivo per cui il footprint rimane contenuto. Un sistema che interpella il LLM su ogni evento è inutilizzabile su hardware homelab standard. L'architettura a tier — deterministic → LLM-partial → LLM-full — esiste precisamente per questo, e i sedici giorni di dati lo confermano.
Suricata homelab monitoring: dove siamo rispetto all'open source
Ho cercato se esistono progetti equivalenti — IDS homelab con LLM dormiente e scoring real-time. Non ne ho trovati. I progetti GitHub sotto il topic llm-security si concentrano su red-teaming, vulnerability detection, analisi post-hoc. Il pattern di dormienza adattiva con escalation tier non ha, al momento, equivalenti open source documentati.
Non lo scrivo per vantarmi. Lo scrivo perché se stai cercando qualcosa di simile da installare senza costruirtelo da zero, al momento non esiste. CrowdSec homelab ha un approccio comunitario interessante per il dns blocking homelab e la threat intelligence distribuita, ma il suo meccanismo di scoring è diverso e non include un LLM locale.
Vale anche la pena tenere a mente la distinzione tra visibilità e sicurezza. Come avevamo analizzato guardando gli errori degli Uffizi, avere un sistema che monitora il traffico interno è diverso dall'avere sicurezza effettiva. AIWALL dà visibilità. Il resto richiede altro — e un IDS che monitora solo il traffico interno non vede nulla di ciò che arriva dall'esterno su una porta aperta.
Cosa ho imparato, in concreto
Sedici giorni di produzione reale insegnano cose che nessun test sintetico mostra.
Le regole ET INFO di Suricata vanno valutate una per una in contesto domestico — molte segnalano protocolli normali, non attacchi. Il tuning iniziale è obbligatorio, non opzionale.
Qualsiasi rilevatore DGA senza fine-tuning su CDN produrrà falsi positivi su CloudFront, Akamai, Fastly. La whitelist non è una scorciatoia — è parte del design.
Un bug sul parser timestamp rimane aperto perché non blocca nulla. Questo è il tipo di debito tecnico che si accumula silenziosamente.
103 MB di RAM per un IDS su LXC è sostenibile su quasi qualsiasi hardware homelab. Il vincolo non è la memoria — è il tempo di configurazione e tuning iniziale.
90 blocchi DNS al giorno su una rete con pochi dispositivi è nella norma bassa. Se il numero fosse dieci volte più alto, mi preoccuperei.
C'è anche un dato che non mi aspettavo: la quantità di informazioni che si ottiene semplicemente osservando il traffico interno per due settimane. Non l'analisi LLM — quella è rimasta quasi sempre dormiente. La visibilità base di Suricata più Blocky, con uno scoring che aggrega i segnali, mostra pattern che altrimenti resterebbero invisibili. Un dispositivo che genera centinaia di query STUN alle 21:08 è qualcosa che non sapevo ci fosse sulla mia rete.
ids homelab open source: prossimi passi
Il passo successivo è la risoluzione del bug timestamp nginx e una revisione sistematica delle regole Suricata attive — tenere quelle utili, disabilitare le ET INFO/POLICY che in rete domestica generano solo rumore.
Vorrei raccogliere dati su un periodo più lungo prima di trarre conclusioni sui pattern DNS. Sedici giorni sono un campione iniziale — abbastanza per trovare i falsi positivi più evidenti, non abbastanza per distinguere anomalie reali dal rumore di fondo.
Se invece gestisci anche un'installazione web pubblica, vale la pena leggere il post sulle vulnerabilità plugin WordPress 2026: la superficie d'attacco sulla rete interna e quella esposta verso l'esterno richiedono strategie diverse, e un IDS che monitora solo il traffico interno non vede nulla di ciò che arriva dall'esterno su una porta aperta.
Un sistema in rodaggio, non un sistema finito
Sedici giorni fa non sapevo che avrei trovato un dispositivo che genera centinaia di alert STUN alle nove di sera. Non sapevo che CloudFront avrebbe triggerato la DGA detection. Non sapevo che il parser timestamp nginx avrebbe prodotto WARNING silenziosi che si accumulano nei log.
Lo so adesso. E il sistema è migliore per questo.
Questo è il ciclo reale di un IDS in homelab: installi, osservi, scopri che metà degli alert che sembrano critici non lo sono, aggiusti, torni ad osservare. Non è sexy come un dashboard con numeri rossi e alert drammatici. È più simile a tenere un diario — impari qualcosa solo se sei disposto a guardare quello che ha scritto ieri.
Nel frattempo, AIWALL gira. Ogni cinque minuti. Anche stanotte.
