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.

PHP2Shell: verificare separatamente rilevamento e aggiornamenti

Per PHP2Shell (CVE-2026-109618 e CVE-2026-109619), l’advisory Sophos, versione 4 del 22 ottobre 2026, descrive firme IPS per Firewall ed Endpoint disponibili da tale data per il rilevamento dei tentativi di attacco. Questo non costituisce né una garanzia generale di blocco né una protezione WAF specifica. Gli ambienti di esecuzione PHP vulnerabili devono comunque essere aggiornati.

Sul firewall verificare che il download dei pattern IPS sia riuscito, quale regola venga effettivamente applicata al traffico interessato, la relativa policy IPS e l’azione effettiva della firma. Le sezioni diagnostiche riportate di seguito spiegano questi controlli. Correlare temporalmente i log del firewall e del server; l’assenza di allarmi non dimostra né l’applicazione di una patch né l’assenza di attacchi. Una richiesta di exploit reale non è un test adatto a un ambiente di produzione.

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 delimitare l’ambito tecnico; il riferimento delle categorie segue la procedura di configurazione.

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

SID è l’identificatore univoco di una firma IPS. Category descrive il gruppo funzionale, Severity la gravità della minaccia e Platform la piattaforma interessata, ad esempio Microsoft Windows. Target distingue le firme client e server; Recommended action indica l’azione prevista in caso di corrispondenza. I nomi e le descrizioni delle categorie riportate sotto non garantiscono un blocco: è determinante la regola della policy effettivamente applicata.

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:

Warning non dimostra un blocco: La guida alla Severity descrive Warning come un avviso in tutti i casi, mentre la guida generale alle regole descrive la sostituzione dell’azione consigliata. Non è quindi chiaramente documentata l’interazione tra queste indicazioni per una specifica firma Warning. Non dedurre un blocco dalla sola etichetta Severity o da un’azione Drop selezionata. Verificare l’azione effettiva in un progetto pilota controllato per questo impiego e chiarire eventuali comportamenti incerti con Sophos Support prima dell’uso in produzione.

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

Distinguere le firme DDoS dai limiti DoS locali

Le firme DDoS sono disponibili solo su XGS 5500 e firewall di capacità superiore. Su un modello supportato, creare una policy dedicata, ad esempio DDoS_Protection, in Intrusion prevention > IPS policies > Add e salvarla con Save. Aprire quindi Edit > Add, inserire un nome per la regola, scegliere Select all, digitare ddos in Smart filter e premere Enter. Impostare Action su Drop packet, salvare prima la regola e poi la policy con Save. In Rules and policies > Firewall rules, assegnare la policy alla regola che corrisponde effettivamente al traffico. Verificare licenza, interruttore IPS globale, firme disponibili e assegnazione come descritto sopra; il nome del modello non dimostra un’ispezione attiva.

I DoS settings locali in Intrusion prevention > DoS & spoof protection sono separati e supportano IPv4 e IPv6. Impostare le velocità di pacchetti e burst in base al traffico reale, selezionare il relativo Apply Flag e fare clic su Apply. Quando una sorgente supera il limite al minuto attivato per ICMP/ICMPv6, il firewall scarta i pacchetti eccedenti finché l’attacco continua. Il valore di esempio di 1200 pacchetti al minuto per sorgente non è un valore predefinito per la produzione. Protezione DoS e spoofing spiega misurazione, stato, eccezioni e rollback. Se la connessione Internet è già satura, occorre una protezione del provider o a monte; IPS non può recuperare quella larghezza di banda. Non generare un vero attacco flood per un test funzionale.

Riferimento delle categorie

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.

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

Inquadrare in sicurezza la configurazione IPS tramite XML API

Per configurazioni ripetibili, la XML API distingue due compiti: IPSFullSignaturePack controlla il download del pacchetto, mentre IPSPolicy descrive una policy con selezione delle firme e azioni. Nessuno di questi oggetti sostituisce la verifica della licenza, l’interruttore IPS globale, l’assegnazione alla regola firewall che corrisponde effettivamente al traffico o il collaudo con nuovo traffico. I prerequisiti e la procedura pilota descritti sopra valgono quindi anche per le modifiche automatizzate. L’accesso e l’analisi delle risposte sono illustrati in Utilizzare la XML API in sicurezza.

Pacchetto completo: Status non è un Get generale

La documentazione di riferimento delle API SFOS-22/23 descrive per IPSFullSignaturePack il campo scalare obbligatorio Status. I suoi valori sono esattamente, in minuscolo, enable, disable e show: i primi due attivano e disattivano rispettivamente il download del pacchetto completo, mentre il terzo serve a interrogare lo stato in questo oggetto. L’esempio mostra soltanto enable/disable; da questo non si può dedurre un’operazione Get generale. La tabella dei parametri API indica disable come valore predefinito, mentre la guida della Device Console riportata sopra non specifica alcun valore predefinito. Questo non sostituisce la lettura dello stato iniziale effettivo.

Anche tramite API, l’opzione resta limitata alle appliance con almeno 32 GB di RAM e a una necessità comprovata. Non è né un interruttore di licenza né un’assegnazione di policy. Per l’operazione IPSFullSignaturePack, la documentazione di riferimento indica lo stato 200 con Operation Successful. e 500 con Operation Fail.. Una risposta di configurazione riuscita non dimostra ancora che il download dei pattern sia stato completato o che la protezione IPS sia efficace: dopo il successivo aggiornamento, eseguire i controlli su firme, risorse e traffico indicati sopra.

Policy: distinguere le regole ereditate dalla selezione personalizzata

Nell’esempio di configurazione, IPSPolicy racchiude i campi Name, Description, Template e RuleList. Il commento relativo a Template spiega che, se si sceglie una policy esistente come modello, tutte le sue regole vengono ereditate e vengono aggiunte le ulteriori regole specificate; senza un modello, la policy contiene soltanto le regole specificate. In presenza di un modello, un breve elenco di regole personalizzate non implica quindi automaticamente una policy circoscritta. Verificare l’elenco completo effettivamente salvato e il relativo ordine, affinché nessuna regola generale ereditata prevalga su un’eccezione SID prevista. L’esempio non garantisce come un aggiornamento successivo tratti le regole non incluse nella richiesta.

Ogni voce Rule in RuleList associa un RuleName, il RuleType, la selezione e una Action. RuleType distingue tra Default Signature e Custom Signature. Nella documentazione di riferimento, il campo di selezione si chiama letteralmente SignaturSelectionType, senza aggiungere a posteriori una lettera. Distingue tra All Application e Individual Application. A questo proposito, l’esempio mostra CategoryList con Category, SeverityList con Severity, PlatformList con Platform, TargetList con Target e SignatureList con Signature. I criteri di filtro circoscrivono l’ambito tecnico della selezione; le singole firme vengono indicate separatamente. Le descrizioni di Platform e Target parlano di elenchi basati su ID: non utilizzare le etichette visualizzate come ID API senza averle verificate.

Per Action, l’esempio mostra i valori testuali Allow Packet, Drop Packet, Disable, Drop Session, Reset, Bypass Session e Recommended. I loro effetti sono spiegati sopra. La tabella dei parametri riporta anche 7, ma non spiega alcuna corrispondenza con un’azione denominata. Non dedurre da questo numero un significato o un’impostazione da usare in produzione; se la selezione non è chiara, modificare la policy nel WebAdmin oppure chiarire la sintassi con Sophos Support.

La tabella dei parametri richiede un nome di policy scalare in UTF-8, senza virgole e con un massimo di 60 caratteri; Description è facoltativo. Per le regole indica nomi obbligatori con un massimo di 70 caratteri, oltre a Rule Type, modalità di selezione delle firme e azione come array con più valori. Secondo la tabella, i valori duplicati vengono ignorati soltanto per i nomi delle regole, non per gli altri array citati. Le singole firme e i quattro elenchi di filtri sono array bidimensionali di stringhe facoltativi. Queste indicazioni della tabella non garantiscono un’elaborazione atomica né che i campi di selezione omessi rimangano invariati durante un aggiornamento. Prima di una modifica, salvare la policy completa con le regole ereditate, le azioni, le eccezioni e le assegnazioni alle regole firewall; in seguito, rileggere la selezione e l’ordine salvati e collaudare il progetto pilota con nuove sessioni.

Risposte: verificare insieme l’operazione e lo stato salvato

Le corrispondenze seguenti sono riportate in entrambe le documentazioni di riferimento SFOS-22/23. Gli identificatori Message.* restano simboli di documentazione non risolti: non sono né messaggi garantiti in fase di esecuzione né una prova di una causa specifica. I valori sono stati della XML API, non automaticamente codici di stato HTTP.

In particolare, in caso di 505 dopo Add, non presumere che la policy sia rimasta invariata e non dedurre la necessità di un riavvio del motore dal solo simbolo. In caso di 502, confrontare il nome esistente e la policy desiderata anziché creare una seconda policy; in caso di 522, verificare le policy effettivamente presenti. In caso di 506, verificare la licenza e lo stato IPS globale senza attivare IPS come gestione automatica dell’errore. Questi controlli aiutano a circoscrivere lo stato, ma non sostituiscono l’analisi della risposta effettiva.

Secondo la documentazione di riferimento, Delete identifica la policy tramite il campo obbligatorio Name, con gli stessi limiti per il nome. La pagina Delete non contiene una struttura completa della richiesta; pertanto, non ricavarne qui una richiesta di eliminazione eseguibile. Prima di un’eliminazione pianificata, verificare assegnazioni e dipendenze e predisporre la procedura di ripristino necessaria. In caso di 503, controllare in particolare i riferimenti esistenti, senza dedurre dal simbolo un elenco completo delle relazioni che impediscono l’eliminazione. Dopo una risposta poco chiara o non riuscita, verificare innanzitutto nel WebAdmin se la policy esiste ancora e quali regole, azioni e assegnazioni sono effettivamente salvate. Solo dopo aver chiarito lo stato effettivo, decidere se effettuare un nuovo tentativo mirato o ripristinare i valori iniziali documentati; le tabelle delle risposte non garantiscono né la ripetibilità automatica né il rollback. Mantenere anche in questo caso la procedura centrale di sicurezza API.

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