Configurare e testare in sicurezza IPS su Sophos Firewall

L’Intrusion Prevention System (IPS) esamina il traffico di rete alla ricerca di pattern di attacco noti, exploit e caratteristiche anomale dei protocolli. Affinché IPS offra una protezione effettiva, deve essere attivo a livello globale. Inoltre, la regola firewall che elabora il flusso di dati deve utilizzare una policy IPS appropriata.

La procedura breve e sicura consiste nel verificare licenza e pattern, attivare IPS, scegliere una policy in base al sistema da proteggere, assegnarla alla regola firewall corretta e collaudare il percorso dei dati con un piccolo gruppo pilota. Applicare la policy più restrittiva a ogni regola non garantisce automaticamente la protezione migliore. Una scelta inadeguata genera rilevamenti, carico o disservizi superflui e rende più difficile l’analisi dei risultati realmente importanti.

Verificare i prerequisiti e lo stato della licenza

Prima della configurazione sono necessari:

• una sottoscrizione Network Protection attiva o una licenza di prova;
• firme IPS disponibili e aggiornamenti dei pattern funzionanti;
• l’ID della regola firewall che elabora effettivamente il traffico previsto;
• il logging della regola per correlare sessione, regola firewall ed evento IPS;
• un responsabile, test definiti e una procedura di ripristino per i falsi positivi.

IPS Protection è disattivata per impostazione predefinita. Su un firewall online, le firme IPS vengono aggiornate solo se la licenza è valida e IPS è attivo. I firewall air gap dotati di licenza costituiscono l’eccezione documentata: possono ricevere le firme IPS mediante la procedura di aggiornamento prevista anche quando IPS è disattivato. Le differenze sono illustrate in Licenze air gap e aggiornamenti dei pattern.

Dopo la scadenza di una sottoscrizione Network Protection, l’interruttore IPS può continuare ad apparire attivo, benché il firewall non applichi più la protezione IPS. La licenza di prova si comporta diversamente: alla scadenza, IPS si disattiva automaticamente. Quando IPS è disattivato, non vengono più scaricate firme online e non è più possibile configurare policy o firme personalizzate. Dopo 30 giorni in questo stato, SFOS elimina le firme e le regole IPS. Se occorre conservare la configurazione, bisogna prima creare un’esportazione o un backup.

Anche quando IPS è disattivato, le policy IPS esistenti possono continuare a essere assegnate alle regole firewall. Questa assegnazione non dimostra che l’ispezione o la protezione siano attive. Se la sottoscrizione a pagamento è scaduta e IPS è disattivato, oppure se una licenza di prova scaduta ha disattivato automaticamente IPS, occorre prima attivare una sottoscrizione Network Protection per poter riattivare IPS. Dopo l’attivazione, verificare nuovamente l’interruttore IPS e le firme.

Anche una sottoscrizione valida non protegge indefinitamente in assenza di contatto con il sistema di licenze. In genere, i firewall online sincronizzano le licenze ogni 24 ore. Se la sincronizzazione non avviene per 90 giorni consecutivi, SFOS disattiva le Security Subscriptions; con una licenza air gap, il termine è di 180 giorni. Gli accessi e il traffico possono continuare a funzionare, ma senza la protezione delle sottoscrizioni disattivate. Lo stato della licenza deve quindi rientrare nell’analisi del problema quando IPS sembra configurato, ma non produce alcun effetto.

In Backup & firmware > Pattern updates, SFOS mostra, tra gli altri, gli stati Ready to install, Downloading, Success e Failed. Update pattern now avvia l’aggiornamento delle normali definizioni dei pattern. Una voce completata correttamente per Application Signatures non dimostra che siano state caricate anche le firme IPS: sui sistemi online, queste ultime richiedono comunque una licenza valida e IPS attivo.

Attivare IPS e definire il percorso dei dati

1. Aprire Intrusion prevention > IPS policies.
2. Attivare IPS Protection.
3. In Backup & firmware > Pattern updates, controllare data, ora e stato dei pattern IPS.
4. Documentare lo stato precedente di IPS Protection, l’ID della regola firewall del flusso pilota, la policy IPS precedente, Log firewall traffic e le eccezioni esistenti.

L’attivazione o la disattivazione di Firewall Acceleration o PKI Acceleration riavvia IPS o il motore DPI. Modifiche di questo tipo non fanno parte della procedura di attivazione. Se un problema riproducibile riguarda un’impostazione globale del motore, Verificare in sicurezza le impostazioni IPS globali descrive quali modifiche hanno effetto immediato, quali richiedono l’applicazione o il riavvio e come conservare il valore iniziale.

Il sistema da proteggere determina la policy

Target indica il lato sul quale si trova il software vulnerabile protetto da una firma. Non coincide semplicemente con la Source Zone o la Destination Zone. Per esempio, se un browser riceve una risposta appositamente predisposta, il Target può essere Client; per un server web pubblicato che riceve una richiesta dannosa, può essere Server.

La scelta si basa su tre domande:

1. Qual è il sistema da proteggere nel flusso in esame: il client o il server?
2. Quali piattaforme, protocolli e servizi sono effettivamente in esecuzione su quel sistema?
3. Una policy esistente copre questo ambito senza includere gruppi di firme non pertinenti?

Per il normale accesso a Internet di un client, il punto di partenza è una policy client o LAN-to-WAN appropriata. Nel caso di una pubblicazione DNAT, si sceglie una policy server o web server adeguata al sistema operativo e alle porte effettivamente pubblicate. Anche in un flusso VPN o di segmentazione, la scelta dipende dall’applicazione protetta, non soltanto dal nome della zona di origine. MTU, MSS, latenza e throughput devono essere verificati lungo il percorso VPN reale.

Il VoIP richiede un test funzionale specifico per la segnalazione SIP e i flussi multimediali RTP, oltre a una procedura già predisposta per tornare alla policy precedente. Per le reti di gestione, backup e infrastruttura, regole circoscritte sono in genere più utili di una selezione di firme particolarmente ampia. IPS può ostacolare gli attacchi laterali anche ai confini dei segmenti interni; le soglie contro spoofing e flooding restano tuttavia una funzione separata delle impostazioni anti-spoofing e DoS.

Una policy personalizzata è opportuna quando occorre delimitare meglio il percorso dei dati, quando un singolo SID richiede un’eccezione documentata o quando si intende impostare consapevolmente un’azione diversa da Recommended. A tale scopo, in Intrusion prevention > IPS policies > Add si assegna un nome univoco, come IPS-Pilot-LAN o IPS-DNAT-Webserver, e si clona come punto di partenza una policy esistente appropriata. Salvare prima la policy nuova o clonata con Save; questo non crea ancora una nuova regola della policy. Si modificano quindi le regole nella copia; le firme predefinite non sono modificabili.

Filtrare le firme e ordinare le regole della policy

Quando si aggiunge una regola, è possibile scegliere singole firme, firme personalizzate oppure Select all. Lo Smart Filter accetta termini di ricerca e criteri quali Category, Severity, Platform e Target; dopo l’immissione, il filtro viene applicato premendo Invio.

L’editor delle regole viene aperto separatamente dalla creazione della policy: in Intrusion prevention > IPS policies, selezionare Edit per la policy desiderata, già salvata, quindi Add e inserire un nome univoco per la regola. Selezionare poi le firme necessarie: Select individual signature per le singole firme oppure Custom signature per le firme personalizzate. Per una ricerca tramite Smart filter, selezionare prima Select all, inserire il termine di ricerca e applicarlo premendo Invio.

Le categorie aiutano a circoscrivere l’ambito tecnico. La tabella completa seguente spiega le etichette visibili in SFOS. Category è uno strumento di consultazione, non un giudizio sul rischio; insieme a Platform e Target, consente allo Smart Filter di selezionare solo le firme pertinenti.

Le categorie di indicatori molto ampie vanno inizialmente impiegate in un progetto pilota di osservazione. In particolare, indicator-compromise può generare falsi positivi; la categoria da sola non giustifica quindi un blocco o un’eccezione.

Dopo la selezione delle firme, impostare consapevolmente Action; le differenze sono spiegate nella sezione dedicata a Severity e azione. Salvare la regola con Save nell’editor delle regole. Questo passaggio è distinto dal salvataggio iniziale della policy. Nella procedura DDoS, salvare poi anche la policy che contiene la regola con Save.

Dopo il salvataggio, avviare una nuova sessione di test e verificare ips_policy_id o idp_policy_id e fw_rule_id; in caso di rilevamento, confrontare anche signature_id, classification e log_subtype con la regola e l’azione previste. L’assenza di rilevamenti non dimostra da sola che il filtro o la policy siano stati applicati.

Le regole di una policy vengono valutate dall’alto verso il basso. Una regola generale per tutte le firme server può quindi prevalere su una regola specifica per un singolo SID posizionata più in basso. Le eccezioni specifiche o le azioni diverse vanno collocate sopra la regola più generale. Un rilevamento successivo deve mostrare la policy, l’ID della regola e l’azione previsti.

Le firme IPS personalizzate servono per un caso di rilevamento chiaramente definito, non per compensare una selezione standard inadeguata. La procedura con sintassi, policy pilota circoscritta e test positivo e negativo è descritta in Creare e testare firme IPS personalizzate.

Valutare separatamente Severity e azione

Per log, ticket ed eccezioni sono importanti SID, Category, Severity, Platform, Target e Recommended action. Sophos assegna Critical ai valori CVSS da 9 a 10, Major da 7 a meno di 9, Moderate da 4 a meno di 7 e Minor da 1 a meno di 4 oppure alle firme principali. Warning identifica e segnala un determinato tipo di traffico. La sola Severity non determina il rischio: nella valutazione rientrano anche raggiungibilità, sistema di destinazione, livello delle patch e azione effettiva.

Questa corrispondenza con i valori CVSS ammette eccezioni: Sophos descrive casi in cui la classificazione della Severity non rientra nelle formule indicate. Da ciò non si può dedurre né l’esistenza di una funzione WebAdmin documentata per modificare la Severity né una procedura di riclassificazione; verificare la Severity effettivamente visualizzata per la firma.

Una regola della policy può sostituire l’azione consigliata:

• Recommended applica l’azione consigliata da Sophos per la firma specifica ed è il normale punto di partenza per le regole in produzione.
• Allow packet registra il rilevamento, ma consente il pacchetto. È una scelta adatta per un progetto pilota, ma non impedisce l’attacco rilevato.
• Drop packet scarta soltanto il pacchetto interessato. L’applicazione può continuare a funzionare oppure restituire un errore.
• Drop session termina l’intera sessione dopo un rilevamento.
• Reset termina attivamente una sessione TCP inviando un reset all’iniziatore.
• Disable disattiva esclusivamente questa firma, eliminando il relativo rilevamento.
• Bypass session interrompe l’ispezione per il resto della sessione. Il traffico può quindi passare a FastPath o all’offload ed essere escluso dai controlli in misura maggiore del previsto.

Le azioni sui pacchetti si applicano a ciascun pacchetto. Le azioni sulla sessione eseguono il controllo fino al primo rilevamento e agiscono poi sull’intera connessione. Ogni deviazione da Recommended deve pertanto essere motivata, indicando firma, policy, regola firewall, responsabile e data di revisione.

Selezionare la policy IPS nella regola firewall

1. Aprire Rules and policies > Firewall rules.
2. Modificare la regola il cui ID è stato verificato nel flusso pilota.
3. In Other security features, impostare la policy IPS scelta alla voce Detect and prevent exploits (IPS).
4. Attivare Log firewall traffic, salvare e creare una nuova sessione per il test.

La sola attivazione globale non è sufficiente. Se il traffico incontra prima un’altra regola senza policy IPS, una regola successiva non offre alcuna protezione. La regola Sophos Firewall non viene applicata: verificare le cause aiuta ad analizzare la corrispondenza delle regole.

Le regole firewall delimitano il traffico consentito. IPS rileva i pattern di attacco nel flusso di dati visibile. Web Protection gestisce contenuti e categorie web, Application Control classifica le applicazioni, TLS Inspection rende visibili, quando necessario, i contenuti cifrati e Zero-Day Protection analizza i file sospetti. I Threat Feeds, ad esempio i feed curati da Cybora, bloccano inoltre indirizzi IP, domini o URL dannosi già noti. Questi moduli si completano a vicenda; nessuno sostituisce regole firewall circoscritte, la gestione delle patch o la corretta scelta della policy.

Collaudare un progetto pilota controllato

Prima di iniziare si definiscono durata del test, responsabile, baseline di confronto e criteri di interruzione. La baseline comprende data e ora dei pattern, ID della regola firewall, policy IPS precedente e nuova, eccezioni note, CPU e memoria, nonché almeno una connessione di controllo invariata. Per VoIP, ERP, protocolli industriali, VPN e applicazioni meno recenti, il test richiede una finestra di manutenzione.

1. Verificare l’assegnazione della policy: creare una nuova sessione e controllare in Packet Capture o nel firewall log l’ID della regola firewall e l’ID della policy IPS previsti. Questo dimostra l’assegnazione, ma non ancora il rilevamento di una firma. La procedura condivisa per Log Viewer e Packet Capture può essere applicata direttamente alla connessione di prova.
2. Testare i flussi di lavoro reali: eseguire accessi, trasferimenti di file, aggiornamenti, chiamate API e sessioni di lunga durata. Un ping non è sufficiente.
3. Valutare gli eventi: in caso di rilevamento, acquisire ID e nome della firma, policy, regola firewall, origine, destinazione, porte e azione effettiva. Non si genera un attacco reale al solo scopo di verificare il funzionamento. Per ottenere un rilevamento innocuo e deterministico, si utilizza il progetto pilota con firma personalizzata.
4. Confrontare la connessione di controllo: una connessione consentita appartenente allo stesso ambito deve continuare a mostrare la regola e l’applicazione previste. Se alcuni pacchetti scompaiono, l’analisi separata dei pacchetti scartati aiuta a circoscrivere la causa.
5. Estendere solo in seguito: aggiungere altri host o regole esclusivamente quando non vi sono blocchi inspiegati e vengono rispettati i limiti di carico, latenza e funzionamento delle applicazioni stabiliti in precedenza.

Il successo non richiede necessariamente l’attivazione di una firma di attacco. Sono determinanti l’assegnazione comprovata della policy, il corretto funzionamento dei flussi di test e di controllo, l’assenza di blocchi inspiegati e valori delle risorse accettabili. Non appena un processo aziendale critico smette di funzionare, si verifica un blocco inspiegato o viene superata una soglia di prestazioni concordata, si ripristinano i valori iniziali documentati per l’assegnazione della policy e il logging della regola. Una policy pilota creata appositamente viene eliminata soltanto quando non è più assegnata ad alcuna regola e le relative eccezioni sono state documentate. Se prima del progetto pilota IPS era globalmente disattivato, questo stato iniziale viene ripristinato solo dopo aver verificato quali altre regole firewall perderebbero di conseguenza la protezione IPS.

Interpretare correttamente log, Packet Capture e report

Gli strumenti rispondono a domande differenti:

• Firewall log: ips_policy_id mostra quale policy era associata al flusso. È utile anche in assenza di rilevamenti di firme.
• Evento IPS: log_type=IDP, signature_id, signature_msg, idp_policy_id, fw_rule_id, classification e log_subtype correlano firma, policy, regola ed esito. Il valore detection_severity nel log non corrisponde necessariamente alla rappresentazione per categorie della Severity nella policy.
• Packet Capture: mostra, tra l’altro, l’ID della regola firewall, il NAT ID e l’ID della policy IPS nel flusso di pacchetti.
• ips.log: fornisce indicazioni più approfondite sulle decisioni di IPS, DPI, Application Control e Active Threat Response.
• sig_upgrade.log e sigmigration.log: mostrano rispettivamente l’aggiornamento e la migrazione delle firme.
• Reports > Network & threats > Intrusion attacks: è adatto all’analisi retrospettiva; Log Viewer rimane più indicato per singoli eventi recenti.

L’associazione degli altri file di log e servizi è illustrata in Servizi e log di Sophos Firewall. Se sono attivi più moduli di protezione, si confronta lo stesso istante nei log firewall, IPS, Web, Application Control e SSL/TLS Inspection. Una regola firewall può consentire traffico che viene poi bloccato da un modulo successivo.

Verificare le prestazioni con un carico comparabile

Le risorse richieste da IPS variano in base a modello, traffico, firme, TLS Inspection, Application Control, VPN e dimensione dei pacchetti. Prima e dopo l’attivazione, con un carico comparabile, si registrano CPU, memoria, throughput, latenza, ritrasmissioni delle applicazioni critiche, nonché il volume dei log IPS/DPI e Syslog.

Disattivare brevemente IPS non è sufficiente a dimostrare un nesso causale. Per confronti riproducibili occorrono metriche delle prestazioni del firewall correttamente contestualizzate e un test iPerf controllato.

Valutare i falsi positivi anziché limitarsi a consentirli

Un rilevamento IPS può essere un falso positivo, un’applicazione inattesa o un vero tentativo di exploit. Innanzitutto si acquisiscono ID e nome della firma, origine, destinazione, servizio, regola firewall, data e ora, frequenza, applicazione interessata e livello delle patch. Si procede quindi come segue:

1. Riprodurre il flusso legittimo e confermare che sia interessato proprio da questo SID.
2. Verificare il livello delle patch, le indicazioni del produttore e la raggiungibilità del sistema protetto.
3. Valutare il rischio qualora il rilevamento venga consentito. Un risultato dubbio o non riproducibile non giustifica un’eccezione permanente.
4. Scegliere la misura reversibile più circoscritta: preferibilmente installare le patch o restringere il percorso dei dati; in alternativa, impostare temporaneamente un singolo SID su Allow packet in una policy utilizzata soltanto in quel punto. Disable o Bypass session eliminano una porzione maggiore della protezione e richiedono una motivazione più solida.
5. Ripetere il test del flusso positivo legittimo e di un flusso negativo o di controllo.
6. Documentare eccezione, responsabile e data di revisione e rivalutare la decisione dopo ogni aggiornamento dell’applicazione, dei pattern, del firmware o del sistema.

Se molte firme interferiscono con la stessa applicazione, una policy personalizzata e circoscritta o una migliore segmentazione costituiscono una soluzione più pulita rispetto a una raccolta di eccezioni globali permanenti. Disattivare IPS a livello globale non è un rollback adeguato per un singolo SID.

Risoluzione dei problemi in base al sintomo

Nessun evento IPS visibile

Creare innanzitutto una nuova sessione e verificare l’ID della regola firewall e ips_policy_id nel firewall log o in Packet Capture. Se manca l’ID della policy, il flusso incontra un’altra regola oppure alla regola selezionata non è assegnata alcuna policy IPS. Se la policy è comprovata, ma non si rileva alcuna firma, il comportamento può essere corretto per traffico innocuo. Per una verifica riproducibile si utilizza una firma personalizzata circoscritta in un progetto pilota isolato, non un vero exploit.

Evento presente, ma il traffico non viene bloccato

Nell’evento IPS verificare signature_id, policy e log_subtype. Controllare quindi la prima regola corrispondente della policy e la relativa azione effettiva. Allow packet, Disable o Bypass session possono impedire il blocco previsto; una regola generale posizionata più in alto può prevalere su quella specifica. Dopo ogni modifica si testa una nuova sessione.

Firme IPS mancanti o aggiornamento dei pattern non riuscito

Verificare insieme lo stato della licenza, l’interruttore IPS globale e Backup & firmware > Pattern updates. Lo stato Failed o un aggiornamento recente delle Application Signatures non dimostrano che l’aggiornamento IPS sia riuscito. sig_upgrade.log mostra il percorso di aggiornamento; in caso di problemi di licenza, licensing.log fornisce ulteriore contesto. In un cluster HA, il nodo Primary aggiorna i pattern IPS e li sincronizza automaticamente con il nodo Auxiliary.

Il servizio IPS è nello stato DEAD

In System services > Services, verificare e documentare lo stato del servizio IPS. Se Sophos Support richiede anche l’output della shell per uno specifico nodo, 5 Device Management > 3 Advanced Shell consente di eseguire questo controllo in sola lettura:

service -S | grep -i ips

Fa fede la riga in cui il primo nome di servizio è esattamente ips; ipsec-monitor non è quello interessato. Questo comando di Advanced Shell non fa parte della procedura pubblicata per il problema noto e va usato soltanto per una diagnostica concordata con il supporto. In un cluster HA, lo stato richiesto deve essere acquisito separatamente su ciascun nodo interessato.

A partire da SFOS 22.0 GA, in rari casi possono mancare dati di configurazione necessari per le web policy. Il servizio Web Policy non si avvia, IPS non riesce a inizializzare la propria policy e rimane nello stato DEAD; anche gli aggiornamenti dei pattern non riescono. In un cluster HA, ciascun nodo può essere interessato in modo indipendente.

Acquisire versione SFOS, data e ora, nodo, stato del servizio, ips.log e sig_upgrade.log, quindi contattare Sophos Support indicando NC-181971. Il solo stato non dimostra questa causa. Nell’elenco attuale dei problemi noti Sophos non indica ancora una versione corretta e fornisce la soluzione alternativa tramite il supporto. Riavvii ripetuti o comandi di riparazione non documentati non costituiscono una procedura diagnostica adeguata.

Pacchetto completo di firme solo per casi particolari comprovati

Durante un aggiornamento dei pattern, SFOS può scaricare il pacchetto completo delle firme IPS anziché un pacchetto parziale. Questa opzione è disponibile soltanto per appliance con almeno 32 GB di RAM e, secondo Sophos, può influire sulle prestazioni. Non attiva IPS e non assegna una policy ad alcuna regola firewall.

Un motivo valido è una specifica firma, indicata espressamente da Sophos Support, che non è inclusa nel pacchetto parziale. L’opzione non va attivata in via preventiva soltanto perché un maggior numero di firme può sembrare preferibile. Per prima cosa, leggere lo stato corrente nella Device Console:

system ips full-signature-pack show

La guida della Device Console non specifica un valore predefinito. Dopo aver confermato il requisito di RAM e la necessità concreta, è possibile attivare il download completo:

system ips full-signature-pack enable

Dopo il successivo aggiornamento dei pattern, controllare data e ora dei pattern, sig_upgrade.log, firma prevista, stato IPS, CPU, RAM e traffico interessato. Se il vantaggio atteso non si concretizza o il funzionamento peggiora, ripristinare lo stato letto in precedenza. Se prima del test era disable, il comando di ripristino è:

system ips full-signature-pack disable

Rilevamento PQC a partire da SFOS 22.0 MR2

SFOS 22.0 MR2 è in grado di rilevare e controllare meccanismi di scambio di chiavi post-quantum puri e ibridi basati su ML-KEM. I nuovi pattern IPS sono disattivati per impostazione predefinita, perché PQC non è automaticamente sospetto. Per analizzare queste connessioni, occorre utilizzare inizialmente una policy pilota personalizzata con Allow packet e logging. Solo un caso d’uso definito, accompagnato da test positivi e di controllo stabili, giustifica Drop session o Reset. Per ulteriori informazioni, consultare Sophos Firewall v22 MR2: controllo PQC.

FAQ