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 il 40% porte di posta. La finestra dettagliata comprendeva 27 destinazioni interne. I servizi sono dedotti dalle porte, non confermati dall’analisi del protocollo. Questa finestra mobile di 24 ore non coincide con le prime 24 ore dall’attivazione, quindi i totali non sono direttamente confrontabili.

I 232 eventi in uscita riguardavano dieci sistemi interni e 17 destinazioni elencate. Non provano un’infezione, ma richiedono verifica: possono dipendere da malware, contenuti di terzi, voci obsolete o servizi legittimi su IP riassegnati.

Dopo il cambiamento, la GUI del firewall era più reattiva e il cliente ha riferito caricamenti più veloci. Non sappiamo se il collo di bottiglia fosse il firewall, i server, le applicazioni o il collegamento. I log provano il filtraggio, non quantificano risorse risparmiate o una percentuale di miglioramento.

Prima, le richieste automatiche raggiungevano davvero i server web e applicativi, che dovevano rispondere anche a percorsi inesistenti. Il blocco anticipato ha evitato quel lavoro successivo. Consultare la lista ha comunque un costo; il beneficio sta nell’elaborazione evitata. L’ordine dipende dalla piattaforma e dalla configurazione. Il primo pacchetto raggiunge ancora la WAN: contro DDoS volumetrici serve protezione a monte.

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 a confronto

Vado subito al punto: molti colleghi e io usiamo un feed di Cybora. Lo utilizzo anche per i servizi pubblici sui miei cloud server. È una scelta maturata nel lavoro reale, non durante una dimostrazione.

Per dodici mesi abbiamo valutato più di 30 fonti commerciali e pubbliche su 15 firewall di clienti, spendendo diverse migliaia di dollari. Le offerte andavano dal gratuito a quasi 1.000 dollari mensili. Un prezzo alto non garantiva ampiezza: alcune liste costose erano molto più piccole.

Tutti i feed erano in Monitor sui 15 firewall: registravano i riscontri senza bloccare connessioni. Questo confronto è separato dal caso del data center in modalità blocco. Con i log del firewall e delle applicazioni abbiamo esaminato comportamenti malevoli, copertura aggiuntiva, attualità e possibili falsi positivi. Abbiamo raggruppato gli eventi ripetuti e considerato anche le connessioni legittime che sarebbero state bloccate.

È un resoconto operativo, non un benchmark riproducibile. Sovrapposizioni, ordine di valutazione e altri controlli influenzano i log Monitor; l’assenza di un evento non prova una lacuna. Non pubblico tutti gli snapshot delle liste, le impostazioni e i casi verificati.

Queste undici proposte non sono una classifica di popolarità. Cybora è al primo posto in base alla nostra esperienza.

Cybora

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 di Ultimate interessano soprattutto le infrastrutture grandi ed esposte.

Cybora è specializzata in feed per firewall. Secondo il fornitore, l’analisi combina i dati degli honeypot con segnali provenienti da firewall di produzione dei clienti che scelgono di fornire questi segnali. Questi apparati osservano attacchi contro servizi reali accessibili da Internet. Nel nostro confronto abbiamo trovato ripetutamente IP sospetti presenti, al momento della verifica, solo in Cybora. Per diversi IP associati a tentativi di forza bruta nei nostri log, Cybora li aveva già inseriti alcuni giorni prima degli altri feed che li hanno aggiunti in seguito. Questa copertura aggiuntiva e anticipata ha rappresentato per noi una differenza qualitativa concreta.

CrowdSec Blocklists

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

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

Q-Feeds dichiara di combinare oltre 2.500 fonti commerciali, aperte e governative in feed IP, domini e URL, con controlli di qualità. Nel nostro test in Monitor, già nella prima ora sono comparse diverse connessioni legittime che in modalità blocco sarebbero state impedite. Abbiamo verificato i log e segnalato questi possibili falsi positivi. Il supporto ha rimosso le voci segnalate abbastanza rapidamente, ma l’onere di indagine ci ha portato a smettere di riferire sistematicamente i casi successivi.

Il numero delle fonti non spiega da solo i riscontri. Senza origine e valutazione dei singoli IP non abbiamo potuto stabilirne la causa. Per bloccare su molti firewall dei clienti, il prevedibile lavoro di eccezioni e supporto era troppo alto per noi. Q-Feeds può comunque essere utile per monitoraggio o indagine.

Spamhaus DROP

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

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

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

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

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

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

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

Questo è il mio blog personale e non ricevo commissioni. Il mio datore di lavoro rivende però licenze Cybora con un margine: dichiaro quindi questo rapporto. La nostra scelta deriva dal confronto operativo descritto.

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.

Abbiamo trovato più volte IP presenti, al momento della verifica, soltanto in Cybora. I log disponibili mostravano sequenze anomale di richieste, percorsi URL e attività automatizzata su login o moduli. Un blocco IP anticipato non rivela da sé i percorsi HTTP: questa prova viene da periodi in Monitor o da altri log correlabili. Neppure molte richieste dimostrano da sole un attacco; contano comportamento e momento dell’inserimento.

Un caso ha mostrato il limite del blocco IP: un sito necessario a un cliente condivideva un indirizzo in lista con un’infrastruttura di hosting compromessa. La classificazione era giustificata, ma il sito legittimo risultava inaccessibile. Una regola IP non distingue siti sullo stesso indirizzo. Consideriamo quindi questi casi parte del lavoro sulle eccezioni: ove possibile, occorre limitare l’autorizzazione al servizio e agli utenti coinvolti e poi riesaminarla. Conta non solo la correttezza di una voce, ma la possibilità di applicare il feed in modo sicuro con un carico sostenibile.

Che cosa non può fare un threat feed

Le nostre misure riguardano IPv4. I servizi accessibili anche tramite IPv6 richiedono una protezione separata: una lista IPv4 non filtra quelle connessioni.

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