Sophos Firewall ATP: configurare X-Ops Threat Feeds

La precedente Advanced Threat Protection (ATP) si chiama Sophos X-Ops Threat Feeds in SFOS 22. Il firewall confronta il traffico in uscita con un database gestito da Sophos che contiene indirizzi IP, domini e URL dannosi noti. Può così impedire, ad esempio, che un client infetto contatti un server Command and Control conosciuto.

Un Threat Feed è un elenco costantemente aggiornato di questi indicatori, abbreviati in IoCs (Indicators of Compromise). X-Ops riceve automaticamente il database globale di SophosLabs; non si inserisce un URL di feed proprio. In Active Threat Response è possibile configurare uno o più moduli: MDR Threat Feeds fornisce le segnalazioni degli analisti MDR sulle minacce attive nella propria rete; NDR Essentials analizza il traffico del firewall con il machine learning, valuta gli IoC rilevati e li registra nei log. In Third-Party Threat Feeds, invece, si inseriscono i propri URL di feed. Un modulo X-Ops attivo non attiva automaticamente gli altri moduli.

In produzione l’obiettivo è Log and drop. La funzione è disattivata per impostazione predefinita e, dopo l’attivazione, blocca solo se si seleziona questa azione.

Configurare X-Ops Threat Feeds

Il modulo X-Ops richiede Network Protection. Per implementare il controllo dei threat feed serve inoltre Web Protection. Entrambe le licenze sono incluse nei bundle Standard e Xstream Protection oppure possono essere acquistate separatamente; X-Ops non richiede una licenza Sophos Fusion (in precedenza Sophos Central) aggiuntiva.

Prima di apportare modifiche, si documentano la build del firmware, le licenze, l’Action attuale, l’ambito di ispezione, le destinazioni dei log e le eccezioni. Per Synchronized Security è inoltre necessaria una licenza Intercept X in Sophos Fusion oppure Sophos Central; la sola licenza X-Ops non fornisce l’integrazione con gli endpoint. Si verifica anche se le regole del firewall reagiscono a un Security Heartbeat rosso: in tal caso, il cambiamento di stato documentato in SFOS 23 può influire sull’accesso dell’endpoint, oltre al blocco della singola connessione.

Aprire System services > Log settings.
Nella riga Active threat response, attivare almeno Local reporting. In base al modello operativo, selezionare anche la destinazione Syslog desiderata e Central reporting. Salvare con Apply le destinazioni dei log supportate dal modello nella pagina Log settings. Ricaricare la pagina e confermare che le destinazioni selezionate siano ancora impostate prima di passare alla configurazione di X-Ops. I log degli eventi locali non equivalgono alla reportistica locale; le alternative per i modelli senza reportistica locale sono indicate di seguito.
Aprire Protect > Active threat response > Sophos X-Ops threat feeds.
Attivare Sophos X-Ops threat feeds.
In Action, scegliere Log only per un pilot breve e controllato oppure Log and drop per la protezione in produzione.
SFOS 23: Log only registra l’evento senza modificare lo stato di Security Heartbeat dell’endpoint. Log and drop registra l’evento, blocca la minaccia e imposta su rosso lo stato di Security Heartbeat dell’endpoint.
In Advanced security settings, scegliere tra Inspect untrusted content e Inspect all content.
Salvare con Apply.
Controllare quindi impostazione, destinazioni dei log ed eccezioni esistenti.

XGS 87/87w e 88/88w non supportano il reporting locale. Su questi modelli si utilizza Central Reporting oppure un server Syslog. La colonna Central reporting compare soltanto dopo aver attivato Send reports and logs to Sophos Central in Sophos Fusion (in precedenza Sophos Central).

Sophos consiglia di bloccare gli IoC noti anziché limitarsi a registrarli. In un ambiente nuovo o finora non monitorato, Log only può comunque essere utile per una breve fase di osservazione con una scadenza precisa. Questa fase deve avere un responsabile e una data di passaggio; in caso contrario la funzione rischia di rimanere attiva senza effetto di blocco.

Cosa protegge X-Ops e cosa non protegge

X-Ops verifica destinazioni dannose note nel traffico inoltrato in uscita. Un evento tipico si verifica quando un client o un server tenta di raggiungere un IP, un dominio o un URL noto per malware, phishing o C2. In base all’azione selezionata, il tentativo viene soltanto registrato oppure scartato immediatamente.

La panoramica e la descrizione di X-Ops presentano delle contraddizioni: La matrice del traffico nella panoramica di SFOS 22/23 indica che X-Ops non supporta il Destination Match, mentre supporta il Source Match locale. La sezione sulla configurazione di X-Ops descrive invece il confronto con indirizzi IP, domini e URL dannosi, su cui si basa il controllo delle destinazioni in questo articolo. Da questa matrice contraddittoria non si può ricavare né una garanzia per tutte le destinazioni del traffico inoltrato né una copertura affidabile del Source Match locale. Per definire questo ambito occorre una conferma per la build in uso prima di sostituire le regole di protezione esistenti. La matrice indica invece in modo coerente che X-Ops non protegge dalle sorgenti remote nel caso di DNAT/WAF, né dalle sorgenti del traffico destinato al sistema, diretto a WebAdmin, al portale VPN o alla VPN. Per questi servizi restano necessarie regole restrittive per firewall, WAF e Device Access; i feed alternativi sono trattati nell’articolo su Third-Party Threat Feeds.

Anche IPS, Malware Scanning e Zero-Day Protection svolgono compiti diversi. X-Ops lavora in base agli indicatori: una destinazione deve essere già nota come IoC dannoso. IPS rileva invece pattern di attacco conosciuti nel traffico. Le due funzioni si completano, ma non si sostituiscono.

Active Threat Response controlla i moduli in questo ordine: MDR, NDR Essentials, Sophos X-Ops e infine Third-Party Threat Feeds. Se un modulo precedente blocca lo stesso IoC, il firewall interrompe i controlli. L’assenza di un log X-Ops non significa quindi automaticamente che non sia intervenuta alcuna protezione. La guida sui Third-Party Threat Feeds descrive più nel dettaglio l’ordine e gli indicatori sovrapposti.

Quali condizioni sono necessarie per rilevare gli eventi

La sola attivazione non garantisce che il firewall possa vedere ogni indicatore IP, dominio o URL. È decisivo quale informazione risulta visibile nel rispettivo percorso di rete.

Indirizzi IP

Per un match sull’IP di destinazione, il traffico in uscita deve attraversare una regola firewall appropriata. Il firewall può confrontare direttamente l’indirizzo di destinazione con il feed X-Ops; per questo non serve la decifratura TLS.

Domini

Per il rilevamento dei domini devono essere operative le impostazioni necessarie relative all’IPS: Application Classification deve essere attiva oppure deve essere selezionata una policy IPS nella regola del firewall interessata. Secondo la documentazione, Application Classification è attiva per impostazione predefinita; si verifica comunque lo stato effettivo. In questo contesto non va intesa come un’opzione aggiuntiva da attivare in ogni regola del firewall. Il requisito riguarda in particolare HTTPS e le richieste DNS a resolver esterni tramite HTTP oppure HTTPS. Se manca la classificazione richiesta, il confronto dei domini potrebbe non avvenire nel percorso di traffico interessato.

Se il firewall risponde direttamente alle richieste DNS dei client, il confronto del dominio viene eseguito dal modulo DNS. Se i client usano un resolver esterno, anche quel percorso DNS deve attraversare il firewall ed essere visibile con le impostazioni IPS richieste. Se non compare un evento di dominio, verificare il percorso del resolver effettivamente utilizzato e non soltanto la regola dal client alla destinazione Web.

URL completi tramite HTTPS

Oltre al dominio, un URL contiene un percorso, ad esempio https://example.invalid/download/payload.exe. Con traffico HTTPS cifrato, senza decifratura il firewall normalmente vede tramite SNI soltanto il dominio, ma non il percorso /download/payload.exe.

Per verificare l’indicatore URL completo serve il Web Proxy con decifratura HTTPS attiva oppure una regola SSL/TLS Inspection appropriata con Decrypt. TLS Inspection non dovrebbe essere attivata globalmente e senza controllo soltanto per X-Ops: distribuzione dei certificati, privacy, eccezioni, compatibilità delle applicazioni e performance richiedono un rollout dedicato.

Con il Web Proxy, nella regola del firewall pertinente, in Web filtering si selezionano le opzioni Use web proxy instead of DPI engine e Decrypt HTTPS during web proxy filtering. Nel percorso DPI, Use web proxy instead of DPI engine resta disattivata; la regola di decrittografia pertinente viene configurata in Rules and policies > SSL/TLS inspection rules con Action Decrypt. Entrambi i percorsi richiedono anche i prerequisiti di classificazione indicati sopra per un controllo completo degli URL HTTPS. Si modifica solo il percorso di traffico autorizzato e si verificano poi l’attendibilità dei certificati, il normale processo aziendale e la regola effettivamente applicata nel Log Viewer.

Scegliere consapevolmente l’ambito di ispezione

In Advanced security settings si stabilisce quanto ampiamente X-Ops deve esaminare il traffico:

Inspect untrusted content limita il controllo al traffico con origini o destinazioni non attendibili. Richiede meno risorse ed è un punto di partenza ragionevole quando carico ed effetti collaterali non sono ancora noti.
Inspect all content controlla traffico attendibile e non attendibile. Offre una copertura maggiore, ma può influire sulle performance, soprattutto negli ambienti con molto traffico.

Per reti client, server o di amministrazione particolarmente sensibili, Inspect all content può essere appropriato se l’appliance dispone di risorse sufficienti. La modifica dovrebbe avvenire in una finestra di manutenzione. In seguito si confrontano utilizzo CPU, latenza, throughput e segnalazioni all’helpdesk con la situazione precedente.

La documentazione descrive la differenza di prestazioni tra i due ambiti di ispezione come generalmente ridotta, ma potenzialmente significativa in presenza di traffico elevato. Prima della modifica si annota il valore attuale. Se il confronto mostra un peggioramento rilevante, in Advanced security settings si ripristina l’ambito di ispezione precedente, si salva con Apply e si verificano nuovamente il processo aziendale, il carico e la registrazione dei log. Non è necessario disattivare indiscriminatamente l’azione di blocco.

Durante l’introduzione è preferibile non modificare più volte e contemporaneamente azione e ambito di ispezione. Cambiando prima la visibilità e poi l’azione di blocco, in caso di problema è più semplice capire quale impostazione ne sia la causa.

Controllare effetto e logging

Dopo il salvataggio non basta verificare che l’interruttore sia attivo. Un controllo operativo affidabile comprende tre livelli:

Configurazione: X-Ops è attivo e sono stati salvati l’Action e l’ambito di ispezione desiderati.
Visibilità: regola firewall, Application Classification o IPS e, per gli URL HTTPS completi, la decifratura TLS corrispondono al tipo di indicatore.
Evidenza: gli eventi sono disponibili in Log viewer > Active threat response oppure nella destinazione Central o Syslog configurata.

Per un riepilogo locale, si apre Reports > Network & threats > Active threat response. Il widget omonimo nel Control Center mostra una panoramica degli host interessati e degli eventi di minaccia. MDR e X-Ops mostrano lo stato e le minacce bloccate, NDR Essentials lo stato e le minacce monitorate; Third-Party Threat Feeds mostra inoltre i feed configurati e il relativo stato di sincronizzazione. Configure apre la configurazione, Reports apre i report e More details espande la vista del widget. Sui dispositivi senza reportistica locale il pulsante Reports non è presente; su questi dispositivi si utilizzano le destinazioni Central o Syslog configurate. Un conteggio NDR delle minacce monitorate non dimostra che siano state bloccate. L’azione specifica e i dettagli della connessione si verificano nel report o nel Log Viewer. Per Third-Party Threat Feeds, il widget mostra anche il numero di minacce bloccate da questi feed.

Il tipo tecnico dei log Syslog continua a chiamarsi ATP, anche se l’interfaccia oggi usa X-Ops e Active Threat Response. In base al percorso di elaborazione, log_component può indicare Firewall, DNS, IPS o Web. Per un’analisi sono particolarmente utili timestamp, azione, Source, Destination, porte, dominio o URL, Threat Name, Feed Name ed Event ID.

Nell’Advanced Shell, ips.log è il log principale dell’engine per Active Threat Response. garner.log aiuta a esaminare l’elaborazione e l’inoltro degli eventi, in particolare quando Central Reporting sembra incompleto. La panoramica dei servizi e dei log di Sophos Firewall spiega questi file e l’accesso SSH sicuro.

Non esiste un indicatore di test X-Ops innocuo e documentato in modo generale. Non si dovrebbe quindi aprire intenzionalmente un vero dominio malware o un indirizzo IP dannoso noto. Se serve un test riproducibile, un Third-Party Pilot Feed proprio con una destinazione controllata è il metodo più sicuro. Per X-Ops si controllano configurazione e visibilità; il successivo evento reale analizzato con attenzione conferma l’effetto di blocco.

Se un IoC non viene bloccato o non compare un log X-Ops

Iniziare dal tipo specifico di indicatore e dal percorso effettivo del traffico. In questo modo si evitano eccezioni ampie o modifiche TLS globali basate su supposizioni:

In Protect > Active threat response > Sophos X-Ops threat feeds, verificare che X-Ops sia attivo e che Action sia realmente impostato su Log and drop. Log only crea soltanto una voce.
In Log viewer > Active threat response, verificare il modulo, l’azione effettiva e i dettagli della connessione per lo stesso IoC. Solo un’azione di blocco comprovata di un modulo precedente, ad esempio MDR con Log and drop, interrompe l’ulteriore controllo prima di X-Ops. NDR Essentials rileva e registra le minacce con Log threats, ma non le blocca. Un evento monitorato da NDR, da solo, non interrompe il controllo di X-Ops e non spiega l’assenza di una voce di log di X-Ops.
Per un indirizzo IP di destinazione, controllare la regola firewall LAN-to-WAN che viene effettivamente applicata. Per un dominio, controllare anche Application Classification, la policy IPS e il percorso del resolver.
Per un URL HTTPS completo, cercare il nome del server in Log viewer > SSL/TLS inspection. Se la SSL/TLS rule corrispondente mostra Don't decrypt, X-Ops non può vedere il percorso dell’URL. Pianificare una regola Decrypt il più possibile limitata solo dopo aver identificato la regola.
In Log viewer > Web filter, cercare il dominio o l’URL; controllare anche la colonna Category e la vista dei dettagli. Qui sono riportati l’ID della regola del firewall e la Web Policy selezionata. Se la Web policy responsabile mostra Allow, verificare l’ordine delle regole e delle policy. Per un dominio o un URL confermato come dannoso, è possibile utilizzare un gruppo di URL con un ambito strettamente limitato e un’azione della Web Policy Block in una regola LAN-to-WAN appropriata, posizionata sopra la regola che finora consentiva il traffico. Nel percorso Web Proxy, controllare anche Web > Exceptions: URL pattern matches, Web categories, Destination IP addresses e Source IP addresses possono includere l’indicatore o l’endpoint che effettua la richiesta. Nel percorso DPI, controllare le SSL/TLS Exclusion Lists. Non si rimuove un’eccezione indiscriminatamente; prima si chiariscono lo scopo, il processo aziendale interessato e l’autorizzazione.
In Protect > Active threat response > Add threat exclusions, cercare sia lo IoC sia l’host o la rete che effettua la richiesta. Queste eccezioni si applicano a tutti i moduli.

Dopo ogni correzione, ripetere lo stesso processo aziendale e controllare i log pertinenti. Se la causa rimane incerta, salvare timestamp, ID della regola firewall, ID della regola Web o SSL/TLS e vista dettagliata dell’evento Active Threat Response per il caso di supporto.

Analizzare un allarme X-Ops

Un IoC bloccato è un segnale importante, ma non rappresenta ancora un’analisi completa dell’incidente. L’indirizzo di destinazione potrebbe essere stato contattato da malware, da un link di phishing, da un’estensione del browser compromessa o da un servizio legittimo classificato erroneamente.

Un procedimento utile è il seguente:

Salvare timestamp, firewall o nodo HA, azione e dettagli completi del log.
Registrare Source IP, Destination IP, dominio o URL, porte, protocollo, Threat Name e Feed Name.
Correlare i log firewall, DNS, IPS e Web dello stesso intervallo.
Identificare il client interno tramite DHCP Lease, associazione utente o dati dell’endpoint.
Cercare sul sistema interessato il relativo processo, la cronologia del browser, il download e altri eventi di sicurezza.
In caso di compromissione confermata, isolare il sistema e trattarlo secondo il runbook interno di Incident Response.
Solo dopo l’analisi decidere se servono pulizia, un blocco aggiuntivo o un’eccezione strettamente limitata.

Con Synchronized Security, sugli endpoint Windows supportati possono comparire anche utente del processo, Endpoint ID e percorso di esecuzione. Su macOS questi dettagli del processo non sono disponibili; la Source IP rimane quindi particolarmente importante per l’associazione.

Falso allarme HA noto `NC-170292`

Su un sistema HA con SFOS 21.5.1 MR1 Build 261, NC-170292 può generare in Sophos Fusion (in precedenza Sophos Central) un falso allarme Advanced threat detected con Raw Logs. Contemporaneamente può arrivare un’e-mail del firewall senza dettagli utili.

Questa limitazione non vale in generale per altri build o per firewall standalone. L’allarme viene quindi prima salvato e analizzato come descritto sopra. Se il sistema corrisponde esattamente al build interessato e mancano dati affidabili sull’evento, Sophos indica il riavvio del servizio Garner come workaround temporaneo. Poiché la Known Issues List non specifica un comando CLI concreto per questo errore, il riavvio dovrebbe essere eseguito solo secondo una procedura di supporto o manutenzione approvata. Se gli allarmi ricompaiono, stato HA, firmware build, timestamp e garner.log devono essere allegati al caso Sophos Support.

Aggiungere eccezioni solo dopo un’analisi confermata

In Protect > Active threat response > Add threat exclusions è possibile aggiungere Host and network exclusions e Threat exclusions per indirizzi IP, domini o URL. Una voce in Threat exclusions può contenere al massimo 128 caratteri. Un’eccezione di questo tipo non vale soltanto per X-Ops, ma per tutti i moduli Active Threat Response. Una soluzione rapida può quindi indebolire allo stesso tempo la protezione di MDR, NDR o Third-Party Threat Feeds.

Quando viene confermato un falso positivo, si dovrebbe escludere solo l’indicatore minimo necessario. L’eccezione deve avere motivo, ticket, responsabile e data di revisione. Escludere preventivamente intere reti client o ampi gruppi di domini elimina l’allarme visibile, ma anche gran parte della protezione.

Per un’eccezione autorizzata, si apre Protect > Active threat response > Add threat exclusions e si utilizza una delle seguenti alternative in base al tipo di eccezione:

Host o reti: In Host and network exclusions, fare clic su Add new item e selezionare solo gli oggetti host o rete autorizzati.
Indicatore di minaccia: In alternativa, in Threat exclusions, inserire l’indirizzo IP, il dominio o l’URL autorizzato e aggiungerlo all’elenco con Add. Rispettare il limite di 128 caratteri per voce.

Salvare quindi con Apply. Riaprire la pagina e verificare che siano state salvate solo le voci previste. Il solo clic su Add new item o Add non sostituisce questo passaggio finale di salvataggio.

Dopo la modifica si verifica nuovamente lo stesso processo aziendale e si controlla in Log Viewer che scompaia soltanto l’evento previsto. Gli altri eventi X-Ops devono continuare a essere registrati o bloccati.

Per tornare allo stato precedente, si annulla solo l’ultima modifica effettuata: l’ambito dell’ispezione viene impostato sul valore precedente documentato e salvato con Apply; una regola o un’eccezione Web/SSL/TLS appena creata viene annullata in modo mirato, senza modificare le regole esistenti o altre eccezioni. Successivamente vengono ricontrollati il processo aziendale, la regola che trova effettivamente corrispondenza e i log. Se un’eccezione viene annullata, la corrispondenza interessata può essere nuovamente bloccata. Se un disservizio rende temporaneamente necessario Log only, il blocco da parte di X-Ops viene sospeso per quel periodo; vengono definiti i responsabili e l’orario di fine, e Log and drop viene ripristinato una volta chiarita la causa. Un modulo disattivato non rappresenta un ritorno equivalente allo stato precedente, poiché viene meno anche l’ispezione che esegue. Un test controllato con un feed pilota dedicato configurato in Third-Party Threat Feeds convalida solo il percorso del traffico di quel feed, non la distribuzione del database X-Ops né la ricerca di corrispondenze nel database.

XML API: gestire separatamente attivazione, azione ed eccezioni

Chi automatizza X-Ops deve distinguere tre impostazioni indipendenti nell’oggetto XML documentato ATP. La documentazione di riferimento dell’API SFOS-22/23 descrive:

ATP/ThreatProtectionStatus: interruttore scalare del modulo con Enable o Disable. Attiva o disattiva X-Ops; non rappresenta né l’azione da eseguire in caso di corrispondenza né una singola eccezione.
ATP/Policy: azione scalare da eseguire in caso di corrispondenza. La tabella dei parametri indica Log Only e Log and Drop, riporta Log Only come valore predefinito e contrassegna il campo come obbligatorio quando X-Ops è attivo. Si tratta di un’indicazione della tabella API, non di una prova dello stato salvato sul proprio firewall.
ATP/InspectContent: ambito di ispezione scalare con all o untrusted. Un ambito di ispezione diverso non equivale a Disable né a una modifica dell’azione da eseguire in caso di corrispondenza.
ATP/HostException/Host: elenco di stringhe per gli host o le reti di origine da escludere. L’esempio riporta HostName; per una voce è necessario il riferimento all’oggetto autorizzato della propria configurazione.
ATP/ThreatException/Threat: elenco separato di stringhe per gli indicatori di destinazione da escludere. La tabella API indica indirizzi IP di destinazione e domini. La possibilità di inserire URL nell’interfaccia, descritta sopra, non dimostra di per sé quale sia la sintassi del payload XML per gli URL.

I due elenchi di eccezioni sono quindi annidati sotto elementi padre diversi e possono contenere più voci. Non sono interruttori di disattivazione globale. La tabella API ne indica l’effetto su X-Ops, MDR e Third-Party Threat Feeds; restano pertanto importanti l’avvertenza più ampia sull’effetto trasversale ai moduli e le regole di autorizzazione nella sezione dedicata alle eccezioni.

Chiarire il conflitto relativo alla Policy prima di una richiesta di scrittura: L’esempio XML usa per Policy il testo alert/drop, mentre la tabella dei parametri indica Log Only e Log and Drop. Queste forme non vengono convertite automaticamente l’una nell’altra; nemmeno la grafia delle etichette dell’interfaccia dimostra che un valore sia valido per l’API. Prima dell’automazione, si confermano il valore specifico e la struttura della richiesta consultando la guida API della build installata oppure Sophos Support. Fino ad allora, l’esempio non è una richiesta pronta da copiare e dal funzionamento verificato.

La configurazione sicura della XML API viene trattata separatamente. Prima di una modifica autorizzata, si salvano lo stato del modulo, l’azione, l’ambito di ispezione ed entrambi gli elenchi di eccezioni. Successivamente si legge nuovamente lo stato effettivamente salvato oppure si apre la pagina di configurazione e si confrontano singolarmente questi cinque ambiti. In caso di errore, prima di riprovare si verifica lo stato salvato; un’eccezione o un ambito di ispezione diverso non devono trasformarsi involontariamente in una disattivazione globale.