Configurare e gestire in sicurezza Sophos Firewall Threat Feeds

I Sophos Firewall Threat Feeds importano automaticamente indirizzi IP, domini e URL dannosi noti come indicatori di compromissione (IoC). Per un rollout sicuro, occorre prima osservare il feed in modalità Monitor, verificare i rilevamenti e gli effetti collaterali e solo in seguito passare a Block.

Questo articolo tratta principalmente i Third-Party Threat Feeds, come i feed di Cybora. La funzione è stata introdotta con Sophos Firewall v21.

Configurare un Threat Feed

I Third-Party Threat Feeds richiedono lo Xstream Protection Bundle, ma non una licenza Sophos Central aggiuntiva. Il firewall deve poter raggiungere l’URL del feed tramite DNS e HTTPS.

1. Aprire System services > Log settings.
2. In Active threat response, attivare almeno una destinazione di log supportata. Per il Log Viewer locale si tratta di Local reporting. XGS 87/87w e 107/107w non supportano il reporting locale; su questi modelli utilizzare Sophos Central o un server syslog.
3. Per rendere visibili i rilevamenti sul traffico DNAT e WAF in entrata, attivare anche Remote source match (inbound traffic). Questa opzione è disattivata per impostazione predefinita.
4. Aprire Protect > Active threat response > Third-party threat feeds > Add.
5. Inserire un nome e una descrizione univoci, ad esempio:
   • Progetto pilota: Name cybora-premium-ipv4-monitor, Description Cybora Premium IPv4 - Pilot
   • Feed di produzione già verificato: Name cybora-premium-ipv4, Description Cybora Feed - Premium
6. Come Indicator type, selezionare IPv4 address, Domain o URL. Se una fonte fornisce più tipi, creare un feed separato per ciascun tipo.
7. Impostare Action su Monitor per la fase iniziale. Dopo un periodo di osservazione verificato, è possibile passare a Block.
8. In External URL, inserire l’indirizzo appropriato dall’elenco dei feed Avanet oppure quello fornito dal proprio provider. Il file deve contenere un indicatore per riga.
9. Se necessario, configurare una API key o Basic Authentication. Le credenziali non devono comparire in ticket o screenshot.
10. Attivare Validate server certificate. Per un certificato pubblico, la CA emittente deve essere presente in Certificates > Certificate authorities; per una CA privata, importarne prima il certificato.
11. Scegliere un Polling interval adeguato all’intervallo di aggiornamento del provider.
12. Eseguire Test connection e salvare con Save.

Controllare quindi Sync status, Last updated, il numero di Threat indicators e la Storage quota disponibile. Success conferma il download, ma non che il traffico previsto venga effettivamente rilevato o bloccato. Questo effetto deve essere verificato separatamente nel Log Viewer.

Scegliere correttamente feed e azione

Indicatori supportati

Un feed contiene esattamente uno dei seguenti tipi:

• IPv4 address: scanner, botnet, sistemi compromessi o server C2
• Domain: domini malware, di phishing o command-and-control
• URL: percorsi dannosi specifici o link di download

Il feed deve essere un file di testo semplice con un indicatore per riga. Intervalli IP, indirizzi IPv6, reti, domini wildcard ed espressioni regolari non possono essere utilizzati nei Third-Party Threat Feeds come sostituti dei singoli IoC supportati.

Un elenco esteso non è automaticamente valido. Origine, aggiornamento, intervallo di update, rischio di falsi positivi e rilevamenti nel proprio ambiente sono più importanti del semplice numero di voci. Un feed che non offre un vantaggio duraturo occupa soltanto spazio.

Monitor prima di Block

Monitor registra i rilevamenti ma consente il traffico. Mostra quindi quali fonti, destinazioni e servizi sarebbero interessati. Block registra e scarta il traffico corrispondente.

Per un nuovo feed è consigliabile questa procedura:

1. Posizionare il feed nella parte superiore dell’elenco Third-Party.
2. Iniziare con Monitor.
3. Verificare i rilevamenti e i possibili falsi positivi durante un periodo rappresentativo.
4. Documentare il responsabile e il processo di gestione delle eccezioni.
5. Solo a questo punto passare a Block.

Un feed IPv4 ben curato per servizi molto esposti può essere messo in produzione più rapidamente di un feed di domini o URL. Questi ultimi corrispondono più spesso a infrastrutture condivise, CDN o reindirizzamenti e richiedono quindi una verifica particolarmente accurata.

Ordine e nomi

Active Threat Response elabora i moduli in questo ordine: MDR, NDR Essentials, Sophos X-Ops e infine Third-Party Threat Feeds. Con Log and drop, una corrispondenza in un modulo precedente interrompe le verifiche successive. Con Log only o Monitor, invece, il firewall registra singoli eventi per MDR, X-Ops e Third-Party Threat Feeds.

All’interno dei Third-Party Threat Feeds, il firewall valuta separatamente gli elenchi Block e Monitor nell’ordine visualizzato. Registra la prima corrispondenza di ogni elenco e blocca in base alla prima corrispondenza nell’elenco Block. Feed di produzione, feed pilota ed elenchi temporanei per incidenti devono quindi essere denominati e ordinati in modo chiaro:

• cybora-premium-ipv4-block
• cybora-standard-domain-monitor
• incident-2026-06-c2-ipv4

Un buon nome indica il provider o lo scopo, il tipo di indicatore e l’azione. Questo fa risparmiare tempo durante l’analisi dei log e le revisioni.

Distinguere i moduli Threat Feed

In Active threat response sono presenti diverse funzioni con compiti e licenze differenti:

• Sophos X-Ops Threat Feeds: indicatori Sophos; richiedono Network Protection e, per l’applicazione, anche Web Protection. Entrambi sono inclusi nel bundle Standard o Xstream oppure possono essere acquistati separatamente.
• MDR Threat Feeds: IoC di Sophos MDR; richiedono lo Xstream Protection Bundle e MDR Essentials o MDR Complete in Sophos Central. La guida dedicata spiega integrazione Central, azione locale, Audit ID, Task Queue e verifica dell’incidente.
• Third-Party Threat Feeds: elenchi esterni di IPv4, domini o URL; richiedono lo Xstream Protection Bundle.
• NDR Essentials: analizza il traffico tramite machine learning e richiede lo Xstream Appliance Bundle.
• NDR Active Threat Intelligence: registra pattern NDR curati da Sophos, richiede lo Xstream Protection Bundle e deve essere attivato per ogni regola firewall mediante Scan with NDR Active threat intelligence. XGS 87/87w e 88/88w non sono supportati.

Per NDR è disponibile la guida separata Gestire Sophos Firewall NDR e Active Threat Response.

Comprendere l’effetto sul traffico

Traffico IPv4, di dominio e URL

Il traffico IPv4 inoltrato richiede una regola firewall che elabori il traffico interessato. Il traffico diretto al sistema per i servizi in Administration > Device access, come WebAdmin, VPN Portal e VPN, viene confrontato separatamente con gli indicatori IP di origine e non attraversa una regola firewall di transito.

Per il traffico inoltrato, i feed di domini richiedono inoltre Application Classification o una policy IPS nella regola firewall.

Per gli URL HTTPS completi, il firewall deve vedere anche il percorso. A tale scopo è necessario Web Proxy con decrittazione HTTPS oppure DPI con una regola di ispezione SSL/TLS adeguata. Senza decrittazione, tramite SNI il firewall vede soltanto il dominio, non il percorso URL completo.

DNAT e WAF da SFOS 22

A partire da SFOS 22, il firewall può confrontare l’IP di origine del traffico inoltrato in entrata per DNAT e WAF con i feed MDR, NDR e Third-Party Threat Feeds. In questo modo è possibile riconoscere scanner e botnet noti prima che raggiungano i servizi pubblicati.

Affinché questi rilevamenti compaiano nel log di Active Threat Response, è necessario attivare Remote source match (inbound traffic) in System services > Log settings > Active threat response. L’opzione è disattivata per impostazione predefinita. Senza questa impostazione, il blocco può funzionare mentre gli eventi DNAT o WAF attesi non compaiono nel Log Viewer.

Casi d’uso tipici

I Threat Feeds non aiutano soltanto con il traffico client in uscita. Soprattutto i servizi accessibili pubblicamente vengono spesso sottoposti a scansioni automatizzate in breve tempo.

• DNAT verso server interni: un feed IPv4 può bloccare le fonti note come dannose prima che raggiungano il server pubblicato.
• Pubblicazioni WAF: i dati di reputazione integrano le regole WAF contro traffico bot, scansioni CVE, sonde CMS e credential stuffing.
• VPN Portal, User Portal e WebAdmin: questi servizi vanno protetti innanzitutto con MFA, reti di origine e Device Access e Local Service ACL. I Threat Feeds riducono inoltre le fonti di attacco note.
• Traffico client in uscita: i feed di domini e URL possono bloccare destinazioni note di malware, phishing e C2.
• Indirizzi WAN sottoposti a scansioni intense: un buon feed IPv4 riduce il rumore automatizzato e alleggerisce il carico su firewall e log.

I Threat Feeds integrano l’hardening di base, ma non lo sostituiscono. I servizi pubblicati richiedono comunque regole DNAT o WAF restrittive, soltanto le porte necessarie, limitazioni adeguate per fonte o paese, IPS o WAF e logging attivo. Un feed non è un lasciapassare per regole Any estese. Il processo generale è descritto nel Sophos Firewall Hardening Hub.

Verificare sincronizzazione e operatività

Testare separatamente il download del feed e l’effetto sul traffico

Una connessione riuscita e Sync status: Success dimostrano soltanto che il firewall ha potuto scaricare e leggere l’elenco. Una verifica completa comprende tre livelli:

1. Download: Test connection, Sync status, Last updated e Storage quota sono plausibili.
2. Contenuto: in Threat indicators è presente un IoC previsto.
3. Effetto: il traffico di test controllato genera un rilevamento in Log viewer > Active threat response o nella destinazione Central o syslog configurata. A seconda della corrispondenza, sono tracciabili il nome del feed, Log/Drop, la direzione della corrispondenza, origine e destinazione o URL, protocollo e porte.

Per un test riproducibile si può utilizzare un breve feed pilota personalizzato su un server HTTPS controllato. Il feed contiene l’indirizzo IPv4 di una destinazione di test anch’essa controllata. Il feed rimane su Monitor, un client di laboratorio stabilisce una connessione con la destinazione di test e l’amministratore verifica la voce di log. Non accedere a destinazioni malware di produzione o a sistemi di terzi per eseguire i test.

Sincronizzazione e Storage Quota

Questi valori nella panoramica dei feed sono importanti per il funzionamento continuo:

• Success, Fetching o Disabled in Sync status
• il timestamp previsto in Last updated
• un numero plausibile di Threat indicators
• una Storage quota disponibile sufficiente
• un aggiornamento manuale riuscito tramite Synchronize now

In caso di Authentication error, verificare la API key o le credenziali; in caso di Connection error, controllare DNS, accesso a Internet, stato HTTP e server del feed. Un SSL/TLS error indica il certificato o la catena di certificati, mentre Failed è spesso dovuto al formato del feed o a indicatori non validi.

Se lo spazio è esaurito, è necessario rivedere dimensioni, qualità e priorità dei feed invece di aggiungere altri elenchi. Su XGS 87/87w, 88/88w e 107/107w sono disponibili solo gli intervalli di polling 24h, 7d e 30d per i Third-Party Threat Feeds. Un feed del provider aggiornato più frequentemente non annulla questo limite dell’appliance.

Se non compaiono rilevamenti

Ordine di verifica consigliato:

1. Feed attivo, Sync status: Success e IoC previsto in Threat indicators
2. un rilevamento MDR, NDR o X-Ops con priorità superiore per lo stesso IoC
3. logging di Active Threat Response e, per DNAT/WAF, Remote source match
4. la regola firewall corrispondente e il relativo logging
5. per i domini, Application Classification o una policy IPS
6. per gli URL, Web Proxy o DPI e SSL/TLS Inspection
7. Threat Exclusions, Web Exclusions e SSL/TLS Exclusion Lists

Se un feed non genera rilevamenti rilevanti durante un periodo di osservazione rappresentativo, occorre rivalutarne l’utilità.

Gestire i falsi positivi

In caso di blocco errato, aprire prima la voce di log e documentare nome del feed, Log/Drop, direzione della corrispondenza, origine e destinazione o URL, protocollo e porte. Verificare quindi che il traffico sia legittimo, segnalare al provider del feed l’indicatore interessato e impostare soltanto un’eccezione il più possibile limitata, con motivo, responsabile e data di revisione.

Un’eccezione estesa a intere reti non è una soluzione corretta. In caso di corrispondenze di domini o URL possono essere coinvolti anche TLS Inspection, una Web Policy, DNS Protection o un’altra funzione di sicurezza.

Backup e restore

Un backup del firewall contiene la configurazione dei Third-Party Threat Feeds, ma non gli elenchi scaricati. Dopo un restore, il firewall scarica immediatamente di nuovo le fonti e applica l’azione configurata. DNS, accesso a Internet, convalida dei certificati e credenziali devono quindi funzionare subito dopo il ripristino.

Le configurazioni dei Threat Feed non possono essere importate o esportate separatamente; le Threat Exclusions, invece, sì. Dopo un restore è necessario controllare di nuovo il download del feed, il numero di IoC e l’effetto sul traffico.

Cybora Threat Feeds per Sophos Firewall

Cybora fornisce feed curati, evitando agli amministratori di dover raccogliere, normalizzare e verificare continuamente più elenchi OSINT. I dati provengono, tra l’altro, da fonti community e OSINT, Threat Intelligence commerciale, honeypot e log anonimizzati di attacchi e anomalie provenienti da ambienti Sophos Firewall gestiti.

Avanet ha testato diversi provider di Threat Feed in ambienti firewall reali. Per Sophos Firewall, riteniamo che Cybora offra attualmente il miglior rapporto qualità-prezzo. Sono stati valutati qualità dei feed, copertura, intervalli di aggiornamento e costi. Anche un feed di questo tipo va prima verificato in un proprio progetto pilota in modalità Monitor.

Confrontare i piani

Free (Basic) è adatto a home user, proof of concept e test di compatibilità. Standard aggiunge al feed IPv4 domini malware e phishing. Premium estende la copertura a domini e URL con aggiornamenti ogni ora. Ultimate, con aggiornamenti ogni 15 minuti, è rivolto a infrastrutture critiche e perimetri ad alto rischio.

Oltre alla quantità e al prezzo, contano aggiornamento, tipi di indicatori supportati, qualità delle fonti, intervallo di update, rischio di falsi positivi e tracciabilità nel Log Viewer. Il feed adatto è quello che genera rilevamenti rilevanti con effetti collaterali accettabili nel proprio ambiente.

Avanet Firewall Network

Una parte del feed Premium proviene da una rete distribuita di firewall. Questa prospettiva aiuta a identificare pattern di attacco che su un singolo firewall sono difficilmente visibili.

Negli attacchi brute force distribuiti, ogni bot effettua solo pochi tentativi di accesso non riusciti e spesso rimane al di sotto di una soglia locale. L’aggregazione dei segnali anonimizzati rende visibili gli indirizzi IP che attaccano in modo mirato l’infrastruttura su più sistemi. Ne deriva un Threat Intelligence Feed aggiornato continuamente per la difesa automatica.