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. Local reporting memorizza localmente i log degli eventi per il Log Viewer; questi log non sono report generati sul dispositivo. In alternativa, utilizzare Sophos Fusion (in precedenza Sophos Central) o un server syslog come destinazione di log.
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 secondo le indicazioni del provider. Con API key, inserire separatamente il nome dell’header o del parametro indicato dal provider e il valore segreto; selezionare quindi Header o Query parameters come posizione di invio. Se un provider richiede, ad esempio, l’header X-API-Key, questo è il nome e non la chiave segreta. Con Basic authentication, inserire nome utente e password. Il valore della API key e la password 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 una connessione o una richiesta HTTP GET riuscita, ma non l’elaborazione completa dell’elenco né che il traffico previsto venga effettivamente rilevato o bloccato. Il contenuto e l’effetto devono essere validati separatamente.

Scegliere correttamente feed e azione

Indicatori supportati

Ogni configurazione di feed elabora esattamente uno dei seguenti tipi di indicatori:

• 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. Se il file del provider contiene più tipi, SFOS considera solo l’Indicator type selezionato. Per ogni tipo desiderato è quindi necessaria una configurazione separata; un file misto non deve essere suddiviso solo perché contiene tipi diversi. 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 esempio di formato contenente solo IPv4 è il seguente:

192.0.2.10
198.51.100.20

Questi indirizzi di documentazione mostrano soltanto il formato, non minacce reali o destinazioni di test raggiungibili. Per il test controllato descritto più avanti si utilizza invece il singolo indirizzo IPv4 della propria destinazione di test, non la relativa rete con suffisso CIDR. Con Cybora si utilizzano direttamente i file dei feed forniti.

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. L’integrazione non è limitata a un elenco fisso di provider selezionabili: è possibile integrare qualsiasi Third-Party Feed che soddisfi i requisiti descritti per i file. Sophos cita, ad esempio, GreyNoise Intelligence, CrowdSec e Q-Feeds come provider; questa menzione non sostituisce né la verifica dell’endpoint specifico né il proprio progetto pilota in modalità Monitor.

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. La panoramica delle licenze dei moduli indica lo Xstream Appliance Bundle, mentre la guida di configurazione indica lo Xstream Protection Bundle. Prima dell’acquisto o del rollout, consultare il confronto specifico di licenze e fonti per NDR Essentials e ottenere una conferma vincolante dell’entitlement del proprio firewall.
• 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 e URL 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.

Il percorso di ispezione competente è il modulo Web per il Web Proxy oppure IPS per il motore DPI con le regole di ispezione SSL/TLS. Questo vale sia per HTTPS cifrato sia per HTTPS decrittato; gli IoC rilevabili continuano a dipendere dalla visibilità del solo dominio o anche del percorso URL.

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

Sync status: Success conferma una connessione o una richiesta HTTP GET riuscita verso l’External URL, non la completezza o l’elaborazione riuscita di tutti gli indicatori previsti. Anche Test connection è soltanto una verifica della connessione. 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 come numero di feed attivi e di feed complessivamente configurati, Total threat indicators come numero di indicatori IPv4, di dominio e URL e Storage quota come spazio occupato nella quota dipendente dal modello. Le appliance più grandi dispongono di più spazio rispetto ai modelli desktop. Refresh aggiorna solo questi contatori visualizzati. Synchronize now, in Manage, recupera invece immediatamente il feed selezionato. I singoli IoC possono essere aperti e cercati tramite Threat indicators o attraverso il numero in Total indicators del feed interessato. Fetching indica che il download è in corso; Disabled indica che il feed è disattivato.

In caso di Authentication error, verificare prima il nome della API key, il valore segreto, la posizione di invio oppure nome utente e password. Se questi dati sono corretti, verificare anche un eventuale handshake TLS non riuscito: controllare il certificato e la catena di fiducia del server del feed e, se necessario, chiarire il problema con il provider. Non tutti gli errori di autenticazione sono errori TLS. Validate server certificate deve rimanere attivato; la mancanza di una CA attendibile si risolve con il certificato CA corretto, non disattivando la verifica.

In caso di Connection error, controllare DNS, accesso a Internet, server del feed e stato HTTP; anche 404, 500 e 302 sono possibili cause. SSL/TLS error è uno stato distinto per i problemi di certificato. In caso di Failed, verificare che il file effettivamente restituito sia in testo semplice, contenga un indicatore per riga e utilizzi tipi supportati appropriati; sono possibili anche altri errori. Dopo la correzione, eseguire nuovamente Test connection e Synchronize now, controllare il timestamp e l’IoC previsto e solo in seguito ripetere il test controllato del traffico. Se l’errore persiste, registrare stato, data e ora e dati del feed depurati da informazioni segrete da fornire al provider o al supporto.

Storage full indica che non c’è spazio sufficiente per l’elenco completo. 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 e gli URL, 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à. Confermare prima il corretto funzionamento del download e del percorso di ispezione e verificare se MDR, NDR o X-Ops rilevano già gli stessi IoC. Un test breve senza rilevamenti non è un motivo per eliminare il feed. Se, dopo queste verifiche, il feed risulta effettivamente ridondante, prima di eliminarlo documentare nome, URL, tipo di indicatore, azione, posizione, intervallo di polling e luogo di conservazione sicura delle credenziali. In Protect > Active threat response > Third-party threat feeds, eliminare il feed verificato per liberare spazio. Controllare quindi Refresh, Storage quota e Active feeds e recuperare nuovamente con Synchronize now un feed che in precedenza non era stato scaricato a causa di Storage full. Per ripristinare il feed eliminato, ricrearlo con i valori documentati, inizialmente su Monitor. La disattivazione temporanea per un rollback rimane una procedura distinta e non viene considerata una prova che sia stato liberato spazio.

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’eccezione controllata si crea in Protect > Active threat response > Add threat exclusions. In Host and network exclusions > Add new item, selezionare 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 nel 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.

Automatizzare ThirdPartyFeed tramite XML

Per automatizzare la stessa configurazione del feed, l’interfaccia XML utilizza l’oggetto ThirdPartyFeed. Questo configura il recupero e l’azione, non i singoli IoC scaricati. L’accesso, l’operazione di scrittura esplicita, la struttura della richiesta dipendente dalla versione e l’interpretazione sicura della risposta sono spiegati in Proteggere l’accesso all’API XML. I nomi dei campi e i limiti seguenti riguardano SFOS 22 e 23; completare la richiesta per l’operazione e la build previste. Prima dell’uso, confermare l’operazione Add/Edit specifica e il relativo payload in API help della build installata. In caso di sintassi non chiarita o di conflitto tra le fonti, non eseguire la scrittura, ma chiarire la questione con il supporto.

Prima di una modifica, identificare il feed esistente tramite il suo Name in WebAdmin e salvare nome, tipo di indicatore, URL, azione, attivazione, posizione e intervallo di polling. Il nome identifica la configurazione del feed, non il fornitore o un singolo IoC. Lo stesso fornitore può avere più configurazioni con nomi distinti per IPv4, domini e URL. Non dedurre dal nome dell’oggetto una semantica di ridenominazione, upsert o sovrascrittura non verificata.

• Identità e origine: Name è obbligatorio, consente al massimo 63 caratteri e solo lettere, numeri, trattini bassi e trattini. Description è facoltativo ed è limitato a 255 caratteri. ExternalURL è obbligatorio ed è limitato a 1024 caratteri; continuare a utilizzare un feed HTTPS in testo semplice direttamente raggiungibile, con un indicatore per riga.
• Azione e ordine: Action richiede esattamente block o monitor, corrispondenti rispettivamente a Block e Monitor nell’interfaccia utente. monitor registra le corrispondenze senza blocco da parte del feed; block registra e blocca. Le denominazioni Log only e Log and drop di altri moduli non sono valori sostitutivi per questo campo. Position consente top o bottom, corrispondenti a Top o Bottom. Questo seleziona la posizione all’interno dei Third-Party Feeds, non la loro precedenza rispetto a MDR, NDR Essentials o Sophos X-Ops. Le liste di blocco e di monitoraggio rimangono separate; fa fede la prima corrispondenza in ciascuna lista.
• Tipo di indicatore: IndicatorType richiede ip, domain o url, corrispondenti a IPv4 address, Domain o URL. In questo contesto, ip non è un tipo IPv6, di rete o di intervallo. Creare una configurazione separata per ogni tipo di indicatore desiderato.
• Autenticazione: Authorization richiede noAuthentication, basicAuthentication o apiKey. Solo per Basic Authentication sono previsti Username e Password, ciascuno con un massimo di 64 caratteri. Solo per l’autenticazione tramite chiave API sono previsti Key, Value e AddTo: il nome della chiave e il valore segreto sono separati e ciascuno è limitato a 64 caratteri; la posizione di trasmissione è esattamente header o queryParam, corrispondenti a Header o Query parameters. È il requisito del fornitore a determinare la scelta, non un valore predefinito presunto. Utilizzare solo i campi pertinenti al metodo; ottenere i segreti da un archivio protetto per i segreti e tenerli fuori da file XML nel repository, URL nei ticket, cronologia della shell, screenshot e log. Con i parametri di query, prestare particolare attenzione al mascheramento degli URL dei feed registrati nei log.
• Verifica del certificato: ValidateServerCertificate è obbligatorio; l’esempio dell’oggetto mostra true e false. Per un funzionamento sicuro, attivare esplicitamente la verifica e predisporre prima l’attendibilità della CA appropriata. Un errore TLS o di autenticazione non giustifica la disattivazione della verifica.
• Intervallo di recupero: PollingInterval è obbligatorio e consente esclusivamente 5m, 15m, 30m, 1h, 6h, 24h, 7d o 30d. Si tratta di token fissi, non di un numero di minuti liberamente selezionabile. Su XGS 87/87w, 88/88w e 107/107w, la selezione rimane limitata a 24h, 7d e 30d. Ad esempio, 1h è adatto a un aggiornamento orario del fornitore solo su un modello che supporta questo intervallo.
• Attivazione e valori predefiniti: Per Enabled, la tabella dei parametri indica 1 e 0, mentre l’esempio dell’oggetto indica true e false. Si tratta di una differenza di rappresentazione non risolta, non di una prova che le notazioni siano intercambiabili. Prima di tentare una scrittura, chiarire la forma valida nella build installata. La tabella indica inoltre monitor, top, ip e noAuthentication come valori predefiniti dei rispettivi campi; verificare lo stato effettivo dell’oggetto di destinazione. Impostare consapevolmente azione, posizione, tipo e autenticazione invece di fare affidamento su valori omessi.

Interpretare in sicurezza le risposte Add/Edit

Per Add Third-party threat feed e Edit Third-party threat feed sono documentate le seguenti associazioni. I valori Message.* sono simboli di messaggio non risolti, non testi di errore letterali né istruzioni operative sufficienti da sole:

In particolare, 409 / Message.CPResourceConflict appartengono ad Add e 404 / Message.CPRecordNotFound a Edit. Non equiparare queste associazioni specifiche dell’oggetto ai codici XML generali o a uno stato di trasporto HTTP; sono determinanti la risposta effettiva e Status Message Information nella build. Dopo ogni modifica, confrontare il feed salvato in WebAdmin con i valori previsti e controllare l’Audit Trail. In caso di errore, timeout o risposta poco chiara, controllare prima lo stato effettivamente salvato, prima di inviare nuovamente un Add o un Edit. Non dedurre da un simbolo alcuna ripetizione automatica, ridenominazione o presunta correzione dell’errore.

Una risposta di configurazione conforme non dimostra né il recupero del feed, né il contenuto degli IoC, né l’effetto sul traffico. Successivamente, continuare a verificare Test connection, Synchronize now, Last updated, Storage quota, un IoC atteso e un test controllato del traffico in modalità Monitor. Passare a Block solo dopo questa verifica; in caso di interruzioni impreviste, ripristinare l’azione salvata oppure disattivare il feed in modo controllato come descritto sopra, senza impostare una Threat Exclusion globale come sostituto.

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.