Configurare e testare l’IPS di Sophos Firewall

L’Intrusion Prevention System (IPS) analizza il traffico alla ricerca di schemi di attacco noti, exploit e caratteristiche sospette dei protocolli. Affinché l’IPS protegga realmente il traffico, deve essere attivo a livello globale e alla regola firewall che elabora il traffico deve essere assegnata un’IPS Policy adeguata.

Non si dovrebbe applicare indiscriminatamente la policy più severa a tutte le regole. Una policy adatta al percorso dei dati, una fase pilota e log chiari evitano interruzioni inutili senza ridurre con leggerezza l’efficacia della protezione.

Attivare l’IPS e assegnarlo a una regola firewall

Prerequisiti

Prima della configurazione devono essere soddisfatti i seguenti requisiti:

• subscription Network Protection attiva o licenza trial
• firme IPS disponibili e pattern update funzionanti
• regola firewall nota che elabora effettivamente il traffico da analizzare
• logging della regola attivo e processo definito per i falsi positivi

IPS Protection è disattivato per impostazione predefinita. Su un firewall online, le firme IPS vengono aggiornate solo con una licenza valida e con l’IPS attivo. I firewall Air Gap con licenza costituiscono l’eccezione documentata: possono ricevere le firme IPS tramite il processo di aggiornamento previsto anche quando l’IPS è disattivato. I dettagli sono descritti in Licenze Air Gap e pattern updates.

Quando Network Protection scade, l’interruttore IPS può continuare a sembrare attivo anche se il firewall non applica più la protezione IPS. Se l’IPS viene disattivato manualmente, le firme online non vengono più aggiornate e non è più possibile configurare policies o firme personalizzate. Dopo 30 giorni, il firewall elimina le firme e le regole IPS.

Alla scadenza di una licenza trial, l’IPS si disattiva automaticamente. Nei 30 giorni successivi non applica alcuna protezione, non scarica firme e non permette di configurare policies; in seguito, firme e regole vengono eliminate. Per conservare la configurazione occorre prima esportarla o creare un backup.

Attivare l’IPS a livello globale

1. Aprire Protect > Intrusion prevention > IPS policies. In alcune viste il percorso abbreviato è Intrusion prevention > IPS policies.
2. Attivare IPS Protection.
3. Controllare lo stato della licenza e i pattern updates.
4. Attendere che le firme siano disponibili.
5. Verificare le policies standard esistenti.
6. Se serve una policy personalizzata, utilizzare Add per clonare una policy standard adatta.

Dopo l’attivazione non bisogna controllare soltanto l’interruttore. Pattern aggiornati e un primo evento nel log indicano molto meglio se l’intera catena di protezione sta funzionando.

L’attivazione o la disattivazione di Firewall Acceleration o PKI Acceleration riavvia l’IPS o la DPI Engine. Modifiche di questo tipo devono essere eseguite in una finestra di manutenzione e non durante un’analisi degli errori.

Attivare l’IPS nella regola firewall

1. Aprire Rules and policies > Firewall rules.
2. Modificare la regola che elabora effettivamente il traffico.
3. In Other security features, attivare Detect and prevent exploits (IPS).
4. Selezionare un’IPS Policy adatta al traffico.
5. Attivare il logging della regola, salvare e testare con traffico reale.

L’attivazione globale da sola non basta. Se il traffico corrisponde prima a un’altra regola senza IPS Policy, una regola successiva non lo protegge. In questo caso è utile La regola Sophos Firewall non viene applicata: verificare le cause.

Per i server pubblicati, DNAT, regola firewall ben delimitata, IPS Policy, logging e patch management devono essere coordinati. Anche per i segmenti interni occorre verificare che il traffico attraversi realmente il firewall e la regola prevista.

Scegliere l’IPS Policy adatta

La policy dipende da origine, destinazione e applicazione:

• Client verso Internet: utilizzare una policy client o LAN-to-WAN e coordinarla con Web Protection, Application Control ed eventualmente TLS Inspection. Browser, servizi di aggiornamento e applicazioni aziendali devono rientrare nella fase pilota; per i download sospetti, Zero-Day Protection completa l’analisi basata sulle firme.
• Internet verso un server tramite DNAT: configurare una policy server o webserver strettamente in base al sistema di destinazione e alle porte pubblicate. La protezione deve riguardare i servizi realmente esposti, non indiscriminatamente ogni tecnologia server. Pubblicare un server tramite DNAT spiega il contesto NAT e le regole; indirizzi IP, domini o URL noti come malevoli possono inoltre essere bloccati con i Threat Feeds.
• VPN Site-to-Site o Remote Access: scegliere la policy in base ai sistemi di origine e destinazione. Applicazioni produttive, MTU/MSS, latenza e throughput devono essere testati sulla connessione VPN reale.
• VoIP: testare SIP/RTP con una policy specifica e un piano di rollback. Una policy client o server aggressiva può compromettere la segnalazione o il flusso multimediale.
• Reti di management, backup e infrastruttura: proteggerle in modo restrittivo senza interrompere le connessioni necessarie per amministrazione, monitoraggio o backup. In questo caso regole strette sono generalmente più utili di una selezione particolarmente ampia di firme.

Anche ai confini tra segmenti, per esempio da client a server o da VPN a server, l’IPS ostacola i movimenti laterali dopo una compromissione. Tuttavia, integra soltanto regole firewall ben configurate. Le impostazioni separate per Spoof Protection e DoS gestiscono i semplici schemi di spoofing e flooding.

Creare una policy personalizzata da un modello

Con Add è possibile clonare una policy standard e poi adattarla in modo mirato. Questo approccio è più comprensibile di una raccolta libera di firme e mantiene una protezione di base sensata. Il nome dovrebbe indicare scopo e percorso dei dati, per esempio IPS-Pilot-LAN o IPS-DNAT-Webserver.

Le regole della policy vengono elaborate dall’alto verso il basso. Una regola ampia per tutte le firme server può quindi nascondere una regola speciale sottostante per un singolo SID. Le modifiche specifiche devono precedere le regole più generali; un evento corrispondente nel log deve poi confermare che viene applicata l’azione prevista.

Filtrare e valutare le firme

Le firme possono essere filtrate in base a Category, Severity, Platform e Target. È anche possibile creare firme IPS personalizzate, ma solo per un caso di rilevamento descritto con precisione e con una successiva revisione. Le seguenti informazioni sono essenziali per log, ticket ed eccezioni:

• SID: ID univoco della firma
• Category: area tecnica, per esempio DNS, browser o malware
• Severity: livello di gravità
• Platform: piattaforma interessata, per esempio Windows o Linux
• Target: firma client o server
• Recommended action: azione consigliata da Sophos

Sophos associa Critical a 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 o alle firme parent. Warning segnala come allarme un traffico sospetto. La Severity da sola non determina però la valutazione: una firma Major su un server esposto va considerata diversamente da un evento Warning in una rete di test. Sistema di destinazione, raggiungibilità, stato delle patch e azione effettiva devono sempre rientrare nella valutazione.

Comprendere le azioni IPS

Una regola della policy può sovrascrivere l’azione consigliata da Sophos:

• Recommended: punto di partenza adatto per le regole di produzione; viene applicata la raccomandazione Sophos specifica per la firma
• Allow packet: registra l’evento ma consente il pacchetto; adatto a una fase pilota, ma non impedisce l’attacco rilevato
• Drop packet: elimina soltanto il pacchetto interessato; l’applicazione può continuare a funzionare o generare errori
• Drop session: termina l’intera sessione dopo un evento; intervento più incisivo in presenza di un rischio di attacco confermato
• Reset: reimposta attivamente la sessione TCP; l’utente o l’applicazione subisce un’interruzione netta
• Disable: disattiva la firma; viene meno la protezione per quello specifico rilevamento
• Bypass session: non analizza più il resto della sessione; il traffico può passare in FastPath o Offload e quindi sottrarsi all’ispezione in misura maggiore del previsto

Le azioni sui pacchetti si applicano a ogni singolo pacchetto. Le azioni sulle sessioni analizzano fino al primo evento e poi agiscono sull’intera connessione. Qualsiasi deviazione da Recommended richiede quindi una nota con firma, policy, regola firewall, motivo, owner e data di review.

Pattern PQC da SFOS 22.0 MR2

SFOS 22.0 MR2 rileva negoziazioni ML-KEM pure e ibride, tra cui ML-KEM-512, -768, -1024 e X25519 con ML-KEM-768. I nuovi pattern PQC sono impostati per default su Disabled, perché PQC non è automaticamente sospetto. Per analizzarli, è preferibile testare prima una policy pilota personalizzata con Allow packet e logging, e passare a Drop session o Reset solo dopo la valutazione. I dettagli sono descritti in Sophos Firewall v22 MR2: controllo PQC.

Eseguire rollout e test controllati

1. Scegliere una regola pilota: iniziare con una rete client di test nota o una singola regola DNAT. Il traffico previsto e la persona responsabile devono essere chiari prima del test.
2. Testare applicazioni reali: verificare login, trasferimenti di file, aggiornamenti, API e sessioni di lunga durata. Un breve ping non dimostra che l’applicazione rimanga stabile con l’IPS.
3. Valutare gli eventi: nel Log viewer controllare origine, destinazione, servizio, regola firewall, firma, SID, Severity, azione e orario. Gli strumenti seguenti forniscono il contesto tecnico.
4. Estendere gradualmente: aggiungere altre regole soltanto dopo test stabili. VoIP, ERP, protocolli industriali, VPN e applicazioni legacy richiedono una finestra di test e un piano di rollback.

Per l’analisi sono utili Servizi e log, l’uso congiunto di Log Viewer e Packet Capture e l’analisi dei pacchetti scartati.

Gli strumenti rispondono a domande diverse:

• ips.log: informazioni più approfondite sulle decisioni IPS, DPI e Application Control
• Packet Capture: flusso di pacchetti, direzione, Firewall Rule ID, NAT ID e IPS Policy ID
• Test della regola: quale regola firewall elabora effettivamente il traffico
• Syslog o Central Reporting: conservazione più lunga e correlazione

Quando sono attivi più moduli di protezione, occorre confrontare gli orari nei log di firewall, IPS, Web, Application Control e SSL/TLS Inspection. Una regola firewall può consentire un traffico che viene successivamente bloccato da un modulo a valle.

Confrontare le prestazioni

L’IPS utilizza una quantità di risorse diversa in base a modello, traffico, firme, TLS Inspection, Application Control, VPN e dimensione dei pacchetti. Prima e dopo l’attivazione bisogna pertanto rilevare sotto un carico comparabile:

• carico di CPU e memoria
• throughput sulle interfacce interessate
• latenza e retransmit delle applicazioni critiche
• volume IPS/DPI e Syslog
• segnalazioni di utenti e applicazioni

Disattivare brevemente l’IPS non dimostra ancora la causa. Per confronti riproducibili occorrono dati prestazionali del firewall correttamente interpretati e un test iPerf controllato.

Gestire falsi positivi ed eccezioni

Se viene bloccato traffico legittimo, non bisogna disattivare immediatamente l’IPS a livello globale. Un evento può essere un falso positivo, un’applicazione inattesa o un reale tentativo di exploit. Per prima cosa raccogliere:

• ID e nome della firma
• origine, destinazione, servizio e regola firewall interessata
• orario, frequenza e applicazione interessata
• stato delle patch del sistema di destinazione
• estratto di log o Packet Capture rilevante

Domande concrete aiutano l’analisi: l’errore si verifica soltanto con un host o una porta? È riproducibile? Scompare dopo una patch? Lo stesso SID riguarda ripetutamente la stessa destinazione? Solo questi elementi giustificano una modifica alla policy.

La modifica va quindi limitata il più possibile:

• adattare una singola firma anziché un’intera categoria
• utilizzare un’IPS Policy personalizzata soltanto nella regola firewall interessata
• controllare l’ordine delle regole della policy
• restringere ulteriormente origine, destinazione e servizio nella regola firewall
• documentare motivo, owner e data di review
• verificare dopo la modifica che sia interessato soltanto il traffico previsto

Un’eccezione temporanea è generalmente preferibile a una disattivazione permanente. Deve essere rivalutata dopo un aggiornamento dell’applicazione, del firmware o del sistema. Se molte firme interferiscono con la stessa applicazione, una policy dedicata o una migliore segmentazione è più pulita di una grande eccezione globale.

Troubleshooting e gestione operativa

L’IPS non ha effetto

Controllare in questo ordine:

1. Network Protection o la licenza trial sono validi?
2. IPS Protection è attivo a livello globale?
3. I pattern IPS sono aggiornati? Nel cluster HA vengono aggiornati sul Primary e sincronizzati automaticamente con l’Auxiliary.
4. Il traffico corrisponde alla regola firewall prevista, con IPS Policy e logging?
5. Una regola ampia della policy nasconde una regola specifica?
6. La policy contiene azioni non giustificate come Allow packet, Disable o Bypass session?
7. La policy è adatta al traffico client, server, VPN o VoIP?
8. È stato verificato con traffico reale che Log Viewer e ips.log mostrino eventi corrispondenti?

Le eccezioni senza owner o data di review sono considerate aperte e devono essere incluse nel successivo controllo operativo.

Il servizio IPS è nello stato DEAD

Con SFOS 22.0 GA e versioni successive, in rari casi possono mancare i dati di configurazione necessari per Web Policy. Il servizio Web Policy non si avvia, l’IPS non riesce a inizializzare la propria policy e rimane nello stato DEAD; falliscono anche i pattern updates. In un cluster HA, ogni nodo può essere interessato in modo indipendente.

Nella CLI, 5 Device Management > 3 Advanced Shell conduce alla shell necessaria. Qui, il seguente comando read-only mostra tutte le righe dei servizi il cui nome contiene ips:

service -S | grep -i ips

È rilevante soltanto la riga in cui il primo nome del servizio è esattamente ips; ipsec-monitor non è il servizio corretto. In un cluster HA, ogni nodo interessato deve essere controllato separatamente.

Se il servizio è nello stato DEAD, occorre acquisire versione SFOS, orario, nodo, output di stato completo, ips.log e sig_upgrade.log, quindi contattare Sophos Support citando NC-181971. Il comando da solo non dimostra la presenza di questo problema. Sophos continua a non pubblicare una versione corretta e fornisce il workaround soltanto tramite Support. Ripetuti tentativi di riavvio o comandi di riparazione non documentati non costituiscono una soluzione corretta.

FAQ