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 Fusion 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 Fusion (in precedenza 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 Position, selezionare Top per un feed pilota, in modo che la sua corrispondenza non venga nascosta da un altro feed di terze parti. Bottom è adatto a un feed di priorità inferiore le cui sovrapposizioni sono già note.
9. In External URL, inserire l’indirizzo appropriato dall’elenco dei feed Avanet oppure quello fornito dal proprio provider. L’URL deve restituire direttamente il file di testo semplice. Se l’endpoint risponde invece, ad esempio, con HTTP 302, SFOS lo classifica come Connection error. Il file contiene un indicatore per riga.
10. In Authorization, selezionare No authentication, API key o Basic authentication. Una API key può essere inviata nel Header o nei Query parameters; il relativo valore e la password di Basic Authentication supportano ciascuno un massimo di 64 caratteri. Le credenziali non devono comparire in ticket o screenshot.
11. 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.
12. Scegliere un Polling interval adeguato all’intervallo di aggiornamento del provider.
13. 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.

SFOS non impone un numero fisso di IoC per ogni Third-Party Feed. Le dimensioni effettivamente utilizzabili sono limitate dalla Storage quota dipendente dal modello. Dopo l’importazione, controllare insieme quota libera, numero di Threat indicators e download riuscito.

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.

Prima di passare a Block, registrare nome del feed, numero di IoC, posizione e rilevamenti osservati fino a quel momento. Se la modifica causa interruzioni impreviste, riportare immediatamente Action dello stesso feed su Monitor e ripetere il test del traffico interessato. Un feed difettoso o non controllabile può essere disattivato temporaneamente. Una Threat Exclusion globale non è un rollback equivalente, perché incide anche su MDR, NDR e Sophos X-Ops.

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 Fusion. La guida dedicata spiega integrazione con Sophos Fusion, 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 Synchronized Security e il contesto aggiuntivo dell’endpoint nei log di Active Threat Response è inoltre necessaria una licenza Intercept X in Sophos Fusion. Questa licenza non è un requisito del Threat Feed stesso, ma dell’arricchimento dell’evento con informazioni su host, utente e processo.

Synchronized Security è opzionale per il confronto con i Threat Feed. Se un Sophos Endpoint gestito invia un Security Heartbeat rosso dopo aver contattato un server dannoso, una regola Heartbeat configurata correttamente può bloccarne il traffico; Lateral Movement Protection può inoltre isolare l’endpoint compromesso dalla rete interna. Questa reazione dell’endpoint integra il feed e i relativi log, ma non sostituisce né la configurazione del feed né la regola firewall.

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.

Le richieste DNS a cui il firewall risponde direttamente come server DNS vengono confrontate con gli IoC di dominio dal modulo DNS. Se i client utilizzano un altro server DNS, IPS deve vedere il traffico DNS. Un feed di domini da solo non dimostra quindi che il percorso effettivo del resolver venga ispezionato.

Per il traffico inoltrato, i feed di domini richiedono inoltre Application Classification o una policy IPS nella regola firewall. Application Classification è attiva per impostazione predefinita, ma deve comunque essere verificata nel percorso della regola interessata.

Per gli URL HTTPS completi, il firewall deve vedere anche il percorso. Nel percorso Web Proxy si selezionano Use web proxy instead of DPI engine e Decrypt HTTPS during web proxy filtering in Web filtering nella regola firewall. Nel percorso DPI si disattiva Use web proxy instead of DPI engine e si aggiunge una regola di ispezione SSL/TLS adeguata con Action: Decrypt. 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 Sophos Fusion 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

Il Summary mostra Active feeds, Total threat indicators e Storage quota. Refresh aggiorna solo questi contatori visualizzati. Synchronize now, invece, recupera immediatamente il feed selezionato. I singoli IoC possono essere aperti e cercati tramite Threat indicators o attraverso il numero di indicatori del feed interessato.

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, il firewall continua a recuperare il feed secondo l’intervallo di polling configurato, ma aggiorna l’elenco IoC memorizzato solo quando torna disponibile spazio. È quindi 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

Per risalire da un IoC di dominio o URL consentito alla regola responsabile, aprire Log viewer > Web filter, cercare l’IoC in Category o direttamente il dominio e aprire la vista dettagliata. Qui sono riportati la Firewall Rule ID e la Web policy selezionata nella regola. Se l’azione della policy corrispondente è Allow, controllare l’ordine delle regole e della policy. Un blocco intenzionale utilizza un URL Group limitato in una Web Policy di blocco assegnata a una regola LAN-to-WAN con priorità superiore. Ripetere quindi lo stesso test del traffico.

Per il percorso DPI, aprire anche Log viewer > SSL/TLS inspection, cercare l’URL in Server name e controllare Action e SSL/TLS rule. Un IoC URL richiede Decrypt. Se la corrispondenza indica Don't decrypt, la Rule ID identifica l’eccezione o la regola che evita la decrittografia. Aggiungere un URL Group limitato a una regola Decrypt con priorità superiore solo dopo questa attribuzione. Distribuire TLS Inspection gradualmente descrive il metodo controllato.

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.

Un’esclusione controllata si crea in Protect > Active threat response > Add threat exclusions. Host and network exclusions utilizza oggetti host o rete esistenti. In Threat exclusions, inserire un singolo indirizzo IP, dominio o URL; ogni voce può contenere al massimo 128 caratteri. Dopo Add e Apply, ripetere lo stesso test del traffico e verificare in Log Viewer che non compaia più soltanto il rilevamento previsto.

⚠️ Una Threat Exclusion si applica a tutti i moduli Active Threat Response, non solo al feed che ha causato il falso positivo. Prima di selezionare Apply, valutare l’effetto su MDR, NDR, Sophos X-Ops e Third-Party Threat Feeds. Documentare voce, motivo, responsabile e data di revisione, quindi rimuovere l’esclusione quando non è più necessaria.

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 distribuisce i feed IPv4, domini e URL come file di testo HTTPS con un indicatore per riga. La descrizione pubblica del prodotto indica che combina fonti OSINT e community, Threat Intelligence commerciale, honeypot, sensori e segnali provenienti dai firewall. Il formato è quindi direttamente compatibile con l’interfaccia di terze parti di SFOS, ma un progetto pilota in modalità Monitor deve comunque confermarne il valore nella propria rete.

Cybora è qui un esempio concreto di provider. A qualsiasi altro provider si applicano gli stessi criteri tecnici: tipi di indicatori adeguati, file scaricabile direttamente, dati aggiornati, falsi positivi accettabili, rilevamenti tracciabili e un processo accessibile per le correzioni.

Confrontare i piani

Free (Basic) contiene solo indicatori IPv4 ed è aggiornato ogni 24 ore, perciò consente di validare la distribuzione e la compatibilità SFOS prima dell’acquisto. Standard fornisce IPv4 e un insieme più limitato di domini ogni sei ore. Premium fornisce IPv4, domini e URL ogni ora, mentre Ultimate offre gli stessi tipi di indicatori ogni 15 minuti. Su XGS 87/87w, 88/88w e 107/107w, tuttavia, l’intervallo SFOS minimo selezionabile rimane 24h, indipendentemente dal piano del provider.

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.