Sophos Firewall ATP: configurare X-Ops Threat Feeds

La precedente Advanced Threat Protection (ATP) si chiama Sophos X-Ops Threat Feeds nelle versioni SFOS attuali. 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.

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

Prima dell’attivazione devono essere presenti le licenze Network Protection e Web Protection. Entrambe sono incluse nei bundle Standard e Xstream Protection; X-Ops non richiede una licenza Sophos Central aggiuntiva.

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.
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.
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 107/107w 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 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.

X-Ops non supporta invece Source Match locali o remoti. Non blocca quindi automaticamente gli indirizzi IP di attaccanti noti che accedono come origine a una pubblicazione DNAT o WAF, al WebAdmin o a un VPN Portal. Per questi casi sono più adatti MDR, NDR o i Third-Party Threat Feeds, insieme a regole restrittive di firewall, WAF e Device Access.

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.

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 rilevare i domini, nella regola firewall interessata deve essere attiva Application Classification oppure deve essere selezionata una IPS Policy. Se mancano entrambe, nel relativo percorso del traffico potrebbe non avvenire la classificazione necessaria.

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.

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.

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 stato e numero delle minacce bloccate; l’azione concreta e i dettagli della connessione si verificano nel report o nel Log Viewer.

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.

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 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. 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.

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.