Threat feed per firewall: efficacia, limiti e fornitori a confronto

Internet è piena di sistemi che analizzano automaticamente gli indirizzi pubblici. Cercano porte aperte, pagine di accesso, portali VPN, applicazioni note e servizi vulnerabili. Fra questi ci sono ricercatori e motori di ricerca infrastrutturali, ma anche bot e aggressori.

Chi pubblica un servizio tramite WAF o DNAT, oppure espone posta elettronica o una pagina di login, prima o poi compare in queste scansioni. Un IP pubblico non equivale a una compromissione. Quando però un servizio risponde, questo rumore diventa lavoro reale per firewall, IPS, WAF, server, applicazioni e sistemi di logging.

Come security engineer conosco bene questa dinamica. Nel mio lavoro vedo regolarmente servizi pubblici impegnati a gestire scansioni, tentativi di accesso e verifiche automatiche di vulnerabilità. Di rado si tratta di un singolo attacco spettacolare: è soprattutto un flusso continuo.

Di recente ho partecipato all’analisi di un caso notevole anche per noi. Un firewall in un data center, con uplink da 10 Gbit/s e ampia capacità nominale, sembrava vicino al limite. L’utilizzo del collegamento era elevato, l’interfaccia di amministrazione lenta e i servizi esposti generavano eventi senza sosta.

Abbiamo esaminato direzione del traffico, destinazioni, porte, finestre temporali e indirizzi sorgente ricorrenti. Molte richieste automatizzate colpivano ripetutamente gli stessi servizi web, di posta e di login. Il loro costo non dipende soltanto dal volume: scartare un pacchetto, completare un handshake TLS e gestire una richiesta applicativa complessa richiedono risorse diverse.

Abbiamo spiegato al cliente i risultati: una parte rilevante del traffico era composta da bot e scansioni che colpivano continuamente i servizi pubblici. Gli abbiamo illustrato cosa avrebbe potuto fare un threat feed in quel punto del percorso, quali fossero i suoi limiti e che la licenza appropriata costava circa 350 dollari l’anno. Ottenuta l’approvazione, abbiamo installato la lista sul firewall in pochi clic e minuti.

Dopo l’attivazione, l’interfaccia di gestione del firewall è diventata sensibilmente più reattiva. Il cliente ha inoltre riferito che siti e applicazioni si caricavano molto più velocemente. È questo a rendere interessante il caso: non la novità dei feed, ma l’effetto operativo osservato e quanto facilmente se ne fraintendono funzionamento e limiti.

Il risultato in cifre

Le misure provengono da un firewall in produzione. Il feed IP è diventato efficace il 1° settembre 2026 alle 10:01:05; il primo evento è arrivato pochi secondi dopo. Alle 20:30 CEST del 2 settembre erano stati registrati 516.959 eventi di blocco.

Sull’intero intervallo la media è stata di 249,9 eventi al minuto, ossia 4,17 al secondo o uno ogni 0,24 secondi. Il minuto più intenso ne ha registrati 775. Il picco è stato di 107 eventi al secondo per due secondi consecutivi.

Parlo deliberatamente di eventi di blocco, corrispondenze o tentativi di connessione. Non sono necessariamente 516.959 attacchi distinti e diretti manualmente: uno scanner può riprovare più volte e un bot può contattare diverse porte in pochi istanti.

Chi bussava alla porta?

Nell’intero periodo di 34 ore e 29 minuti, 516.727 eventi erano in ingresso e soltanto 232 riguardavano connessioni in uscita impedite. Il 99,955% dell’attività del feed in questo ambiente proveniva quindi da sorgenti Internet.

Sono comparsi 10.518 IP differenti presenti in lista. Rispetto ai 220.000 indicatori IPv4 del feed all’epoca, circa il 4,8% della lista ha avuto rilevanza su questo singolo firewall in circa 34 ore. L’IP più attivo ha prodotto 4.141 eventi, i primi dieci circa 31.500 e 767 indirizzi sono comparsi una volta sola. Il 4,8% è un confronto dimensionale, non un tasso di rilevamento: la lista cambia e gli aggressori sconosciuti non figurano in questo contatore.

L’analisi delle porte riguarda una finestra mobile di 24 ore con circa 369.000 eventi dettagliati:

Circa il 56% degli eventi interessava porte web e circa il 40% porte di posta, in linea con i servizi pubblicati. La finestra dettagliata includeva 27 sistemi di destinazione interni. I nomi dei servizi sono dedotti dalle porte, non provati da un’analisi del protocollo. Inoltre questa finestra mobile non coincide con le prime 24 ore dall’attivazione: i totali non sono direttamente confrontabili.

I 232 eventi in uscita erano pochi, ma meritavano attenzione: dieci sistemi interni avevano tentato connessioni verso 17 IP elencati. Non è una prova di infezione. Le spiegazioni possibili includono malware, contenuti di terzi, voci obsolete e servizi legittimi su IP riassegnati.

La maggiore reattività della GUI e i tempi di caricamento più brevi riferiti dal cliente sono osservazioni successive alla modifica. Non identificano il collo di bottiglia precedente, che poteva trovarsi nel firewall, nei server web, nelle applicazioni o nel collegamento. I log provano che il feed ha filtrato traffico, non quantificano il risparmio di risorse né una percentuale di miglioramento.

In questo caso le richieste automatiche raggiungevano effettivamente i server web e applicativi, che dovevano elaborarle e, per esempio, restituire errori per percorsi inesistenti. Il blocco anticipato degli IP ha eliminato quel lavoro a valle per le richieste interessate. Anche la consultazione della lista costa risorse; il vantaggio deriva dall’elaborazione successiva evitata. Ordine e punto di applicazione dipendono dalla piattaforma e dalla configurazione, specialmente con WAF e servizi ospitati sul firewall. Il primo pacchetto arriva comunque alla WAN: un blocco locale non sostituisce la mitigazione upstream di un DDoS volumetrico.

Che cosa fa davvero un threat feed

Un feed per firewall può essere semplicemente un file di testo scaricato via HTTPS. Molti fornitori offrono indicatori per domini e URL oltre agli IP. Nella maggior parte dei nostri casi usiamo soprattutto gli IP, perché sono le informazioni più utili per il blocco anticipato sul firewall. La lista viene aggiornata a intervalli definiti e il traffico corrispondente viene registrato o bloccato secondo la configurazione.

La qualità dipende dalle decisioni prese prima della pubblicazione:

• Il comportamento osservato era malevolo o soltanto insolito?
• Quanto è recente l’osservazione?
• Fonti indipendenti confermano il segnale?
• Quando va rimossa una voce non più attuale?

Una lista lunga non equivale a buona threat intelligence. Contano attualità, precisione e rimozione disciplinata. IP dinamici di cloud, hosting e ISP possono tornare a un uso legittimo; una lista troppo piccola, invece, può coprire troppo poco del rumore quotidiano.

Threat feed per firewall

Non voglio nascondere fino alla fine la nostra scelta: il provider utilizzato oggi da molti colleghi e da me è Cybora. Lo uso anche privatamente per proteggere servizi pubblici sui miei cloud server. La decisione nasce dal confronto in ambienti reali, non da una dimostrazione commerciale.

In dodici mesi il nostro team ha valutato oltre 30 provider e fonti pubbliche su 15 firewall di clienti, acquistando abbonamenti e spendendo diverse migliaia di dollari. I prodotti andavano dai feed gratuiti a pacchetti prossimi ai 1.000 dollari mensili; alcuni dei più costosi avevano liste molto più piccole e puntavano sulle proprie promesse di freschezza e precisione.

Abbiamo installato i feed in esame sui 15 firewall in modalità Monitor, cioè con registrazione delle corrispondenze senza blocco. Abbiamo confrontato le sorgenti segnalate e verificato richieste sospette e possibili falsi positivi nei log di firewall e applicazioni. Questo confronto prolungato è distinto dall’installazione bloccante nel data center. Abbiamo considerato attività malevola confermata, copertura aggiuntiva, attualità e lavoro richiesto dalle eccezioni; prezzo e dimensione della lista non bastano.

Gli eventi ricorrenti vanno raggruppati, altrimenti uno scanner molto attivo domina i risultati. Sono altrettanto importanti le connessioni legittime che un feed impedirebbe. Anche un IP classificato correttamente come problematico può produrre un falso positivo operativo.

Si è trattato di un confronto nell’uso quotidiano, non di un benchmark di laboratorio riproducibile. Ordine di valutazione, sovrapposizioni e altri controlli attivi possono influenzare i log in modalità Monitor; un evento assente non dimostra da solo una lacuna. Per un benchmark indipendente servirebbero snapshot delle liste con timestamp, configurazioni e casi positivi e negativi verificati. Non pubblico qui il dataset completo.

Queste undici offerte sono una selezione editoriale, non una classifica di popolarità. AbuseIPDB e IPsum sono inclusi sulla base della documentazione, senza attribuire loro risultati di test diretti. Cybora compare per primo per la nostra esperienza; il resto non è ordinato secondo un punteggio misurato. Le informazioni sugli altri prodotti sono state verificate l'8 settembre 2026, quelle su Q-Feeds il 28 settembre.

Cybora ci ha dato il miglior equilibrio fra copertura, attualità, corrispondenze utili, pochi falsi positivi da gestire, integrazione, supporto e prezzo. I piani d’ingresso sono accessibili; gli aggiornamenti ogni 15 minuti del piano Ultimate interessano in particolare le infrastrutture grandi ed esposte. L’intervallo di pubblicazione non dice però quanto tempo siano serviti prima per rilevare e valutare l’indicatore. Anche download e importazione sul firewall aggiungono ritardo. Nei dati del caso compaiono due risposte HTTP 429: la lista locale è rimasta attiva e il download seguente ha recuperato. Occorre quindi monitorare età della lista e aggiornamenti falliti.

CrowdSec Blocklists unisce un Security Engine open source, segnali comunitari e liste curate distribuibili a firewall e gateway. La telemetria di produzione e i feed specialistici sono punti forti; una lista per un CMS, un proxy o una CVE specifica non è automaticamente un feed generale perimetrale.

GreyNoise fornisce anche liste IP interrogabili per firewall. GNQL permette di selezionare sorgenti malevole recenti o attività legate a CVE. È una buona opzione per chi vuole definire i criteri, ma richiede progettazione delle query, accesso ai moduli dati e verifica dei risultati. Non è soltanto uno strumento per arricchire i log.

Q-Feeds dichiara di aggregare oltre 2.500 fonti commerciali, aperte e governative, con feed IP, domini e URL, controlli di qualità e filtri per falsi positivi. La nostra esperienza di blocco è stata meno positiva: già nella prima ora diverse connessioni legittime sono state impedite. Abbiamo verificato il traffico interessato e classificato come falsi positivi i casi analizzati. Il supporto ha rimosso abbastanza rapidamente le voci segnalate, ma l’onere di indagine e segnalazione era tale che in seguito abbiamo smesso di notificare sistematicamente gli altri casi. Il numero di fonti non spiega da solo la causa. Senza conoscere origine, motivazione e rivalutazione di ogni IP, non possiamo determinarla. Per una distribuzione bloccante su molti firewall di clienti il lavoro di eccezione osservato era troppo alto; Q-Feeds può comunque essere utile per monitoraggio e indagine.

Spamhaus DROP è una lista prudente di reti particolarmente pericolose per filtraggio perimetrale o decisioni di routing. La soglia alta la rende affidabile, ma non mira a comprendere ogni scanner effimero.

ThreatFox di abuse.ch e Spamhaus raccoglie indicatori associati a malware, inclusa l’infrastruttura di comando e controllo. È prezioso per rilevamento e threat hunting, ma più circoscritto di un feed generale contro scanner e brute force.

URLhaus di abuse.ch distribuisce URL che veicolano malware. È indicato per filtri DNS, proxy, secure web gateway e analisi, meno per il solo blocco IP perimetrale. L’API richiede un Auth-Key e l’accesso comunitario non significa uso commerciale gratuito illimitato: vanno rispettate le condizioni di fair use.

DShield pubblica una lista di blocco compatta ricavata da log firewall inviati alla piattaforma. Può integrare altri feed. Gli altri dataset servono soprattutto a ricerca e contesto e non vanno importati indiscriminatamente come blocchi.

FireHOL IP Lists aggrega molte liste pubbliche e permette di confrontarne dimensione, aggiornamenti, età e sovrapposizioni. L’aggregatore eredita però i difetti delle fonti; voci ripubblicate ripetutamente possono durare troppo.

AbuseIPDB offre reputazione basata su segnalazioni e blacklist in testo semplice con soglie di confidenza configurabili. Un punteggio alto non prova che ogni connessione attuale sia malevola. Contano età delle segnalazioni, IP condivisi e limiti di richieste del piano.

IPsum aggrega quotidianamente oltre 30 liste pubbliche e offre soglie basate sul numero di liste concordi. È trasparente, ma tre liste possono riutilizzare la stessa osservazione e non rappresentare tre conferme indipendenti. L’aggiornamento giornaliero limita la reattività; non è una fonte autonoma di telemetria.

Gratuito non significa scadente e commerciale non significa automaticamente migliore. Molti feed pubblici eccellono nel loro ambito; per una protezione perimetrale generale li consideriamo soprattutto componenti specialistici, non un sostituto completo di un feed curato continuamente.

Perché Cybora è arrivato primo nel nostro confronto

Per trasparenza: questo è il mio blog personale e non ricevo commissioni personali. Il mio datore di lavoro è però rivenditore Cybora e acquista licenze scontate da rivendere con margine. È un rapporto commerciale rilevante per valutare la raccomandazione. La scelta è nata dall’esperienza descritta, non dalle condizioni di rivendita.

Nel caso del data center il feed era di Cybora. Abbiamo iniziato con Premium a 349 dollari l’anno, con aggiornamenti orari. Secondo la descrizione pubblica del prodotto, Cybora combina OSINT, fonti commerciali, honeypot, sensori e telemetria reale dei firewall. Gli indicatori vengono valutati per recenza, confidenza e concordanza, deduplicati, confrontati con regole di inclusione ed esclusione e pubblicati come lista HTTPS. Al momento del test Premium offriva 220.000 IPv4, 45.000 domini e 25.000 URL. Sul firewall misurato gli IPv4 erano impostati su Block, i domini inizialmente su Monitor.

Dopo una settimana il cliente è passato a Ultimate: all’epoca oltre 300.000 IPv4 e più di 100.000 domini e URL ciascuno, con aggiornamenti ogni 15 minuti. Il cliente ha riferito un ulteriore miglioramento, ma la finestra di misura qui analizzata si chiude prima del cambio e non può dimostrare il guadagno aggiuntivo. In questo caso il piano superiore costava molto meno di un firewall più grande e della relativa licenza. Non è comunque la scelta automatica per una piccola sede: contano esposizione, servizi e profilo dei riscontri.

Le reti in produzione integrano gli honeypot con servizi e profili di traffico differenti. Non garantiscono da sole superiorità: anche altri provider le usano. Nei nostri controlli abbiamo trovato ripetutamente IP presenti allora soltanto nelle liste Cybora, associati nei log disponibili a sequenze insolite, percorsi URL e tentativi automatizzati su login o moduli. Un blocco IP anticipato non rivela da sé un percorso HTTP: questa evidenza proviene da periodi in Monitor o log correlabili. Neppure una frequenza elevata dimostra da sola un attacco.

Un caso di supporto ha mostrato il limite del blocco IP: una pagina necessaria a un cliente era su un IP di hosting condiviso inserito in lista. L’indagine ha confermato la compromissione dell’infrastruttura. La classificazione era comprensibile, ma la pagina legittima risultava bloccata: un falso positivo operativo. Una regola IP non distingue i siti sullo stesso indirizzo. L’eccezione, se possibile, va limitata al servizio e agli utenti coinvolti e rivalutata. Consentire tutto l’IP riaprirebbe anche gli altri contenuti. Un singolo contatto con il supporto non prova tempi di risposta generali.

Alla fine il risultato tecnico è semplice: un indirizzo HTTPS e una lista importabile in minuti sulle piattaforme supportate. Applicarla responsabilmente richiede però una verifica sul proprio traffico.

STIX e TAXII non sono una blocklist

STIX (Structured Threat Information Expression) è un modello dati strutturato. Può rappresentare IP, malware, campagne, attori, tecniche, osservazioni, periodi, livelli di confidenza e relazioni: descrive perché un indicatore conta e in quale contesto è stato visto.

TAXII (Trusted Automated Exchange of Intelligence Information) è il protocollo per scambiare quei dati via HTTPS. In breve, STIX descrive il contenuto e TAXII il trasporto o l’API.

Il contesto è prezioso per piattaforme di intelligence, SIEM e SOC. Per il controllo veloce degli IP, il firewall usa spesso soltanto un insieme di indirizzi derivato da tali dati: scarica gli indicatori periodicamente e consulta l’insieme locale, senza reinterpretare STIX/TAXII per ogni pacchetto. Una lista TXT è meno ricca, ma adatta all’applicazione perimetrale.

Che cosa non può fare un threat feed

I dati e la copertura IP di questo caso riguardano IPv4. Non dimostrano nulla sulla protezione IPv6; chi espone servizi anche via IPv6 deve verificarla separatamente.

Un feed blocca indicatori noti. Non identifica automaticamente un aggressore nuovo con IP pulito, attività malevole su servizi cloud legittimi, attacchi dietro una CDN o vulnerabilità nella propria applicazione. IP e domini cambiano, i sistemi compromessi vengono ripuliti o riassegnati.

Non sostituisce quindi patch, MFA, IPS, WAF, EDR, policy corrette e log utili. È un livello decisionale anticipato che può assorbire rumore noto su DNAT, WAF, VPN e posta. Avvierei sempre un nuovo feed in modalità di osservazione, predisponendo eccezioni, verificando limiti di capacità e aggiornamento del firewall e definendo la gestione dei falsi positivi.

La mia conclusione

Questi numeri non provano che una licenza sostituisca magicamente un uplink da 10 Gbit/s o un firewall più grande. Mostrano che su questo singolo firewall oltre mezzo milione di eventi noti e indesiderati sono stati fermati presto in poco più di 34 ore.

Per il cliente contava il risultato quotidiano: amministrazione più fluida e siti e applicazioni percepiti come molto più rapidi. È un dato operativo utile, anche se non conosciamo il collo di bottiglia originario. I log documentano l’azione regolare del feed, non una misura diretta della prestazione.

Nel nostro confronto di dodici mesi Cybora è stato il feed generalista più adatto a questo scenario. CrowdSec, GreyNoise, Spamhaus, abuse.ch e altre fonti restano validi, spesso migliori nel proprio ambito. La domanda utile non è «Chi ha la lista più lunga?», ma «Quali dati sono attuali, precisi e sicuri da applicare ai miei servizi esposti?».

Alla prossima,
Joe

FAQ