Creare e testare firme IPS personalizzate su Sophos Firewall

Una firma IPS personalizzata è utile quando Sophos non fornisce una firma adatta a un comportamento di rete o applicativo chiaramente definito. Può, ad esempio, riconoscere una stringa nota in chiaro, una caratteristica insolita di un protocollo o una combinazione precisa di porta, direzione e payload.

La firma da sola non protegge nulla. Deve essere utilizzata in una policy IPS, questa policy deve essere associata alla regola firewall che intercetta effettivamente il traffico e il flusso di dati deve essere visibile a IPS. Un pattern troppo ampio può bloccare traffico legittimo; uno troppo restrittivo non produce corrispondenze.

Testare prima una nuova firma in una regola IPS pilota con Action: Allow packet. Anche se Recommended action è già impostata su Allow packet, è l’azione della regola della policy IPS a determinare il comportamento. Drop packet, Drop session, Reset o Bypass session modificano il traffico di produzione e vanno introdotte in esercizio solo dopo un test positivo e uno negativo riproducibili.

Sei passaggi per un progetto pilota controllato

1. Descrivere il caso da rilevare indicando protocollo, direzione, porta e un pattern univoco.
2. In Intrusion prevention > Custom IPS signatures, creare una firma con una regola circoscritta e Recommended action: Allow packet.
3. Aggiungere la firma a una regola dedicata in una policy IPS eliminabile e selezionare Action: Allow packet.
4. Assegnare questa policy IPS solo alla regola firewall prevista per il progetto pilota e attivare Log firewall traffic in tale regola.
5. Generare un test corrispondente e uno volutamente non corrispondente, quindi confrontare Log Viewer, ips.log e la corrispondenza con la regola.
6. Modificare l’azione della regola della policy IPS solo dopo una validazione stabile; in caso di corrispondenze inattese, ripristinare l’assegnazione della policy precedente.

Una voce salvata o un controllo sintattico superato non dimostrano ancora il funzionamento. Il successo significa che il test positivo corrisponde esattamente alla firma personalizzata e alla regola firewall previste, il test negativo non produce corrispondenze e l’applicazione di produzione continua a comportarsi come prima.

Quando è adatta una firma personalizzata

Le firme personalizzate sono adatte a caratteristiche stabili e visibili a livello di pacchetto o di flusso. Può trattarsi di un valore di protocollo proprietario, di un indicatore chiaro di exploit o di una protezione temporanea per una vulnerabilità nota internamente. Il percorso dei dati previsto e la reazione desiderata devono essere definiti prima di scrivere la firma.

Per indirizzi IP o domini variabili, in genere sono più adatti host, servizi e gruppi, Threat Feed o regole firewall circoscritte. Una firma personalizzata, inoltre, non sostituisce né la gestione delle patch né una regola del produttore ben definita. Per una singola corrispondenza nel log, mantenere una soluzione sviluppata internamente è raramente proporzionato.

I dati cifrati costituiscono un limite importante. IPS può riconoscere un pattern content nel payload HTTPS solo se il contenuto viene effettivamente decifrato nel percorso di elaborazione scelto ed è visibile al motore. Senza una TLS Inspection adeguata, normalmente restano disponibili solo le caratteristiche non cifrate o altrimenti visibili.

Verificare prima licenza e ciclo di vita

Per attivare IPS occorrono una sottoscrizione Network Protection attiva o una licenza di prova valida, oltre all’accesso amministrativo per firma, policy e regola firewall. Prima del progetto pilota, si documentano l’assegnazione della policy esistente, l’ID della regola e un backup per il ripristino. I 30 giorni citati di seguito decorrono dalla scadenza della licenza o dalla disattivazione manuale di IPS, non dal successivo tentativo di configurazione.

Non è possibile configurare firme personalizzate quando la prova di IPS è scaduta o IPS Protection è disattivata in Intrusion prevention > IPS policies. Sophos consiglia di riattivare IPS entro 30 giorni se si desidera conservare le firme personalizzate esistenti. Un backup o un’esportazione deve quindi far parte del piano di ripristino prima di modifiche alla licenza, a IPS o di modifiche rilevanti alle policy.

IPS deve quindi essere attivo globalmente e la regola firewall che elabora il traffico deve avere una policy IPS. La configurazione di base completa è descritta in Configurare Sophos Firewall IPS e testarlo in sicurezza. Una firma personalizzata integra questo percorso dei dati, non costituisce un meccanismo di protezione parallelo.

Delimitare chiaramente la sintassi delle regole

Limiti della documentazione per SFOS 22/23: La guida alla sintassi contiene esempi formattati in modo contraddittorio: distance: 4.within:4; non è un modello affidabile da copiare; per byte_jump, il testo esplicativo cita operandi di confronto che non compaiono nello schema sintattico. Anche le etichette dei bit TCP riservati sono poco chiare. Questi passaggi non vengono interpretati come funzionalità aggiuntive del motore. I frammenti illustrati di seguito restano esempi della documentazione, non regole testate su un firewall. Se una regola viene rifiutata o risulta poco chiara, conservare la build esatta, la regola e il messaggio di errore e chiedere chiarimenti al supporto Sophos; fino ad allora, non autorizzare alcuna azione di blocco in produzione.

La maschera di inserimento separa Protocol e Custom rule. Nella regola, le singole parole chiave vengono combinate con i rispettivi valori e un punto e virgola. Quanto maggiore è il numero di caratteristiche indipendenti che devono corrispondere contemporaneamente, tanto minore è normalmente il rischio di corrispondenze casuali. Allo stesso tempo, la firma non deve diventare così specifica da essere resa inefficace da una modifica innocua del protocollo.

Per un test esclusivamente controllato e in chiaro, si può usare TCP come protocollo e, ad esempio, il seguente pattern circoscritto per il payload:

content:"AVANET-IPS-PILOT"; nocase;

AVANET-IPS-PILOT è un valore di documentazione volutamente riconoscibile. La regola firewall pilota associata viene inoltre limitata al servizio di test, ad esempio alla porta TCP 8080. Token, direzione e porta vengono sostituiti con valori presenti nel flusso di dati reale visibile a IPS. Questo esempio non è una firma universale di attacco e non deve essere applicato senza modifiche a regole di produzione ad ampio raggio.

Payload e finestra di ricerca

content cerca una sequenza di caratteri o byte; i valori binari vengono indicati tra caratteri pipe. nocase ignora la distinzione tra maiuscole e minuscole nelle corrispondenze del contenuto, mentre rawbytes opera sui dati grezzi. depth e offset delimitano la ricerca in modo assoluto nel payload, mentre distance e within operano relativamente alla corrispondenza precedente. uricontent, isdataat e pcre coprono casi più specifici relativi a URI, posizioni ed espressioni regolari.

Un intervallo di ricerca circoscritto riduce le corrispondenze casuali e il carico di elaborazione. In particolare, pcre, finestre ampie o più pattern di contenuto estesi devono essere introdotti solo utilizzando pacchetti realistici e monitorando il carico. Se depth è inferiore alla lunghezza del pattern di contenuto cercato, la firma non può mai produrre una corrispondenza.

I modificatori nocase, rawbytes, depth, offset, distance e within si applicano a content; non sono regole di rilevamento indipendenti. Senza depth, la ricerca procede da offset fino alla fine del payload. Senza within, anche la ricerca di un secondo pattern di contenuto resta aperta da distance fino alla fine. Un punto iniziale da solo non basta quindi a mantenere circoscritta la finestra di ricerca. uricontent esamina l’URI normalizzato della richiesta, non dati arbitrari del payload. isdataat verifica la presenza di dati in una posizione specificata; con relative, questa posizione è riferita alla fine della corrispondenza di contenuto precedente.

Header, flussi e valori strutturati

Origine, destinazione e porta possono essere delimitate con srcaddr, dstaddr, srcport e dstport. Per gli header IP sono disponibili, tra gli altri, ttl, tos, id, ipopts, fragoffset, fragbits, dsize, ip_proto e samip. Le caratteristiche TCP sono descritte con flags, flow, seq, ack e window; itype, icode, icmp_id e icmp_seq si applicano a ICMP. rpc, byte_test e byte_jump sono pensati per protocolli strutturati o binari.

flow si applica solo a TCP. to_server e from_client hanno lo stesso significato, così come to_client e from_server. bi_direction estende il rilevamento a entrambe le direzioni; se si impone un vincolo sulla porta, il test negativo deve quindi considerare anche il traffico di ritorno. La scelta tra no_stream e only_stream non va confusa con un controllo della dimensione dei pacchetti: dsize verifica la dimensione del payload di un pacchetto e non produce corrispondenze sui pacchetti riassemblati da un flusso. Una combinazione con only_stream è quindi inadatta. Se manca una corrispondenza, occorre prima decidere se cercare la caratteristica nel singolo pacchetto o nel flusso riassemblato, anziché modificare soltanto la dimensione o il pattern di contenuto.

Per le regole complesse vale la sintassi Custom IPS descritta sopra e supportata da SFOS 22. Le parole chiave Snort non documentate o le regole copiate da altri motori non devono essere adottate senza verifica.

Operandi: indirizzo, porta, URI e posizione dei dati

I seguenti frammenti vanno inseriti in Custom rule, non nella shell. Sono un riferimento per SFOS 22/23, non firme di attacco già testate. Si combinano solo le condizioni adatte al caso da rilevare; Protocol, policy pilota e Allow packet restano parte del test descritto sopra. Le parentesi quadre negli schemi sintattici indicano parti facoltative e non vanno inserite.

• srcaddr:192.0.2.10; dstaddr:198.51.100.20; confronta gli IP di origine e destinazione con singoli indirizzi. Gli indirizzi di documentazione vengono sostituiti con gli indirizzi osservati nei test; da questo esempio non si può dedurre il supporto per sottoreti o elenchi di indirizzi.

• srcport:40000; dstport:8080; confronta le porte di origine e destinazione con valori numerici. La porta di destinazione rappresenta qui il servizio di test. Una porta di origine del client variabile deve essere fissata solo se fa realmente parte del caso da rilevare; altrimenti le nuove connessioni non soddisfano questa condizione.

• uricontent:"/ips-pilot"; cerca il percorso sostituibile nell’URI normalizzato della richiesta. Sono possibili anche pattern misti di testo e dati binari. Il confronto deve corrispondere al valore normalizzato dell’URI, non soltanto alla forma visualizzata nella barra degli indirizzi del browser.

• content:"AVANET-IPS-PILOT"; isdataat:50,relative; richiede inoltre la presenza di dati alla posizione 50 rispetto alla fine di questa corrispondenza di contenuto. Senza relative, la posizione nel payload è assoluta. Il numero viene scelto in base alla struttura effettiva del protocollo; verifica la disponibilità dei dati, non il loro contenuto.

• content:"ABC"; content:"DEF"; distance:1; within:10; utilizza due pattern sostituibili con una finestra di ricerca relativa. distance definisce la distanza dalla fine della prima corrispondenza, mentre within limita la ricerca successiva. Per le finestre assolute, anche offset e depth ricevono valori numerici, ad esempio offset:4; depth:20; sul content corrispondente. Questi numeri vengono scelti in base alla posizione e alla lunghezza effettive del pattern; non sono valori predefiniti del protocollo.

Espressioni regolari con pcre

Le forme di base sono pcre:"/REGEX/"; e pcre:"m/REGEX/";. Un ! prima della virgoletta di apertura nega l’espressione, ad esempio pcre:!"/AVANET-IPS-PILOT/i";. Si tratta di una condizione di mancata corrispondenza e, senza ulteriori limitazioni, può avere un ambito molto ampio. REGEX o il token pilota vengono sostituiti con il pattern necessario. Le opzioni si trovano dopo il / di chiusura, ad esempio pcre:"/AVANET-IPS-PILOT/i";.

• i ignora la distinzione tra maiuscole e minuscole; s consente a . di riconoscere anche le interruzioni di riga.
• m consente a ^ e $ di corrispondere anche all’inizio e alla fine delle righe nel buffer. x ignora i caratteri di spaziatura non protetti nel pattern, tranne nelle classi di caratteri.
• A ancora la corrispondenza all’inizio del buffer. E vincola $ solo alla fine effettiva, non alla posizione prima di un’interruzione di riga finale.
• G inverte il comportamento greedy predefinito dei quantificatori; un ? successivo lo inverte nuovamente.
• R inizia relativamente alla fine dell’ultima corrispondenza di pattern. U utilizza buffer URI decodificati, mentre B non utilizza buffer decodificati.

Prima del progetto pilota si stabilisce quindi in quale buffer e da quale posizione deve applicarsi il pattern. Un’espressione regolare corretta sui dati grezzi non deve necessariamente produrre una corrispondenza su un URI decodificato.

Leggere campi binari: byte_test e byte_jump

byte_test legge un campo e ne verifica il valore numerico. Lo schema è byte_test:COUNT,[!]OPERATOR,VALUE,OFFSET[,relative][,big|little][,NUMBER_TYPE,string];. COUNT è il numero di byte letti, OFFSET è il punto iniziale nel payload; con relative, l’inizio è relativo all’ultima corrispondenza di pattern. VALUE è il valore di confronto. Sono documentati <, >, =, ! e &: minore, maggiore, uguale, diverso e AND bit a bit. Un ! prima di un operatore di confronto ne nega il risultato. big o little definisce l’ordine dei byte. Con string si leggono cifre testuali anziché un campo numerico binario; hex, dec e oct valgono solo per questa modalità testuale.

Esempio per un campo binario: byte_test:2,=,16,0,big; legge due byte dalla posizione 0 del payload in formato Big Endian e li confronta con 16. Numero di byte, posizione, ordine dei byte e valore di confronto devono derivare dal protocollo, non da questo esempio. Un valore numerico casuale non è una prova di attacco.

byte_jump, invece, legge una lunghezza e sposta la posizione per i controlli successivi. Lo schema è byte_jump:COUNT,OFFSET[,relative][,multiplier FACTOR][,big|little][,string][,hex|dec|oct][,align][,from_beginning];. I primi due operandi determinano la larghezza del campo e la posizione di lettura; relative riferisce l’offset all’ultima corrispondenza di pattern. multiplier moltiplica il valore letto per determinare l’ampiezza del salto. align la arrotonda per eccesso al successivo limite di 32 bit. Con from_beginning, l’ampiezza del salto viene applicata dall’inizio del payload anziché dalla posizione corrente. string e le basi numeriche hanno lo stesso scopo che in byte_test.

byte_jump:2,0,big; è quindi un frammento per un campo di lunghezza di due byte all’inizio del payload, con ordine dei byte scelto esplicitamente. Non è un confronto di dimensioni; l’operatore di confronto e il valore di confronto non sono operandi di byte_jump. Per entrambe le parole chiave relative ai byte, nei campi binari multibyte si sceglie esplicitamente big o little: non bisogna affidarsi a un ordine dei byte predefinito dedotto dalla documentazione. Verificare prima il campo e la destinazione del salto sul payload reale di test, quindi controllare un caso positivo e uno negativo per la condizione successiva. Una lunghezza errata può spostare la posizione di ricerca oltre il pattern desiderato.

Campi IP, opzioni e frammenti

• ttl:64;, ttl:>64; e ttl:<64; confrontano il Time to Live IP rispettivamente per uguaglianza, per valori superiori o per valori inferiori. tos:16; confronta il campo TOS, id:1234; il campo IP ID. Questi numeri di esempio non sono valori di rilevamento consigliati; vengono scelti in base alla caratteristica dell’header effettivamente cercata.
• ipopts:rr; verifica la presenza di un’opzione IP. I valori consentiti sono rr (Record Route), eol (End of List), nop (No Operation), ts (Timestamp), sec (Security), lsrr (Loose Source Routing), ssrr (Strict Source Routing), satid (Stream Identifier) e any (una qualsiasi opzione IP). any richiede quindi un’opzione, non semplicemente un qualsiasi pacchetto IP.
• fragoffset:0; confronta l’offset del frammento nell’header IP con un numero decimale. Questo campo non è l’offset di ricerca del contenuto nel payload.
• fragbits verifica M (More Fragments), D (Don’t Fragment) e R (Reserved). Un + iniziale consente altri bit oltre a quelli specificati, * richiede almeno uno dei bit specificati e ! richiede che i bit specificati non siano impostati. Pertanto, fragbits:+M; verifica che More Fragments sia impostato senza escludere altri bit.
• dsize:300;, dsize:>300;, dsize:<300; e dsize:300<>400; descrivono la dimensione esatta del payload, un confronto per valori superiori/inferiori o un intervallo. I numeri si riferiscono ai dati del payload del pacchetto, non all’intera connessione. Restano validi i limiti rispetto ai flussi ricostruiti spiegati sopra.
• ip_proto:6;, ip_proto:!6;, ip_proto:>6; e ip_proto:<6; confrontano l’identificatore numerico del protocollo nell’header IP, non la porta TCP/UDP. samip; non ha un valore e richiede che gli IP di origine e destinazione siano uguali.

Campi TCP e selezione dei flussi

flags verifica i flag TCP: S per SYN, A per ACK, F per FIN, R per RST, U per URG e P per PSH. Senza modificatore, ad esempio, flags:S; verifica la presenza del solo SYN. Un +, * o ! iniziale ha il significato spiegato sopra per fragbits. flags:+S; consente quindi flag aggiuntivi. La guida mostra un secondo gruppo di flag facoltativo dopo una virgola, ma non ne spiega la semantica di confronto. Non trattare quindi flags:S,A; come un’istruzione confermata per ignorare ACK; prima dell’uso, far chiarire questo comportamento per la build installata. I casi particolari relativi ai bit TCP riservati e a «nessun flag impostato» non vengono qui deliberatamente autorizzati come sintassi da copiare; richiedono una regola confermata per la specifica versione e non devono essere dedotti da un’etichetta poco chiara.

Per flow sono disponibili le direzioni già illustrate, oltre a established, no_stream e only_stream. flow:established; richiede una connessione TCP stabilita. flow:no_stream; esclude i pacchetti del flusso ricostruiti, mentre flow:only_stream; limita il rilevamento a questi ultimi. Questi frammenti illustrano le singole scelte e non invitano a usare insieme entrambe le opzioni di flusso. bi_direction resta l’estensione al traffico di andata e ritorno descritta sopra.

seq:1234;, ack:1234; e window:4096; confrontano rispettivamente numero di sequenza TCP, numero di riscontro e dimensione della finestra con un valore numerico. I valori esatti di sequenza o ACK cambiano tra le connessioni e hanno senso solo se proprio quel valore fa parte del caso da rilevare. La finestra TCP non è una finestra di ricerca nel payload.

ICMP e RPC

itype:8; e icode:0; confrontano tipo e codice ICMP. Entrambi supportano anche <, > e intervalli come itype:3<>5;; tipo e codice sono campi distinti. icmp_id:1234; e icmp_seq:1; confrontano per uguaglianza l’identificatore ICMP e il valore di sequenza. I valori vengono scelti in base al caso ICMP desiderato, senza equipararli ai numeri di sequenza TCP.

rpc:100000,2,*; verifica, nelle richieste SUNRPC CALL, il numero di applicazione 100000, la versione 2 e una procedura qualsiasi. Lo schema è rpc:APPLICATION,VERSION,PROCEDURE;; * è consentito per versione e procedura, non per il numero di applicazione. I numeri vengono sostituiti con l’applicazione, la versione e la procedura cercate. Un carattere jolly non evita l’analisi del protocollo: lascia intenzionalmente aperta la parte corrispondente e amplia quindi il rilevamento.

Creare la firma e assegnarla a una policy

In Intrusion prevention > Custom IPS signatures > Add si definiscono Name, Protocol, Custom rule, Severity e Recommended action. Un nome come PILOT-TCP-8080-AVANET-TOKEN rende visibili lo scopo e i limiti del test. Severity descrive la propria valutazione del rischio; non dimostra che il pattern sia malevolo.

Per la prima esecuzione, Recommended action resta impostata su Allow packet. Importante: l’azione della regola della policy IPS prevale su questa raccomandazione. Anche la regola pilota deve quindi utilizzare Allow packet. Le altre azioni hanno conseguenze nettamente più incisive:

• Drop packet scarta solo il pacchetto corrispondente.
• Drop session termina la sessione dopo la corrispondenza.
• Reset termina una sessione TCP e invia un reset all’origine.
• Bypass session consente il traffico e non controlla ulteriormente il resto della sessione.

Per le azioni basate sulla sessione, SFOS controlla solo fino al primo pacchetto corrispondente. Prima di passare da Allow packet a una di queste azioni, deve quindi essere confermato che proprio questa prima corrispondenza riguardi la sessione prevista.

Al salvataggio, SFOS riconfigura il motore IPS. Se la RAM libera è sufficiente, ciò avviene senza interruzioni. Se la RAM libera è scarsa, il motore può riavviarsi e causare una breve interruzione. Le modifiche devono quindi essere eseguite in una finestra temporale monitorata anche quando la firma sembra di piccola entità. Dopo il salvataggio, verificare lo stato di IPS e ips.log per individuare riavvii o errori prima di proseguire con il progetto pilota.

Dopo questa verifica preliminare, salvare la firma con Save e riaprire la relativa voce: Protocol, Custom rule, Severity e Recommended action devono corrispondere ai valori pianificati. Lasciare invariati Firewall Acceleration e PKI Acceleration durante il progetto pilota; ogni attivazione o disattivazione riavvia IPS e altera il confronto. Controllo delle zone, Trusted MAC, coppie IP-MAC ed eccezioni DoS sono meccanismi separati, descritti in Protezione DoS e anti-spoofing, non proprietà di una firma personalizzata.

Segue poi la seconda parte, spesso trascurata: in Intrusion prevention > IPS policies, aprire una policy eliminabile destinata al progetto pilota, aggiungere una regola, scegliere Custom signature, selezionare la firma e posizionare la regola specifica sopra quelle più generiche. SFOS valuta le regole della policy IPS dall’alto verso il basso. Salvare la regola della policy con Save, quindi salvare anche la policy IPS che la contiene con Save. Riaprire la policy e verificare la selezione della firma e l’azione salvate. Successivamente, questa policy viene associata alla regola pilota che intercetta effettivamente il traffico in Rules and policies > Firewall rules > [regola pilota] > Detect and prevent exploits (IPS); salvare anche la regola firewall e verificarla con una nuova sessione.

Gestire lo stesso oggetto firma tramite XML API

Chi automatizza il progetto pilota lavora con l’oggetto XML IPSCustomSignature, non con una regola della policy IPS. Il riferimento SFOS 22/23 denomina le operazioni Add Custom Signature, Update custom signature e Delete Custom Signature. Accesso, operazione di scrittura esplicita, backup, valutazione della risposta e arresto in caso di payload non chiarito sono spiegati centralmente in Usare XML API in sicurezza. Prima della scrittura, la definizione dell’oggetto e l’operazione devono essere confermate in API help della build installata; qui non viene fornita alcuna ulteriore richiesta di scrittura eseguibile.

Nell’esempio dell’oggetto, Name, Protocol, CustomRule, Severity e RecommendedAction si trovano all’interno di IPSCustomSignature. Name identifica la firma, non la policy o la regola firewall. La tabella dei parametri richiede una stringa scalare di massimo 15 caratteri; anche Delete richiede questo nome esatto. Per l’automazione tramite API, scegliere quindi un nome breve e univoco come IPS-PILOT-8080. Il nome di esempio WebAdmin più lungo riportato sopra non è un modello da copiare per l’API. Prima di Update o Delete, leggere l’identità effettivamente salvata e tutti gli utilizzi nelle policy, anziché dedurre l’oggetto di destinazione da una SID o da una voce con nome simile.

La tabella indica tutti e cinque i dati come obbligatori e scalari per Add/Update. Protocol consente TCP, UDP, ICMP o ALL; Severity consente Critical, Major, Moderate, Minor o Warning. CustomRule contiene la definizione della firma sotto forma di stringa. L’etichetta della tabella Custom Rule, con uno spazio, non è la forma XML CustomRule. L’ulteriore indicazione di separare le lettere con un punto non spiega né una conversione generale delle regole né l’escaping XML. Non modificare quindi meccanicamente con punti la sintassi descritta sopra, ma verificare il contenuto della regola e la corretta codifica XML per la build. L’esempio del produttore utilizza solo SignatureDefinition come segnaposto; da questo non deriva una firma pronta all’uso o che rilevi in modo comprovato traffico malevolo.

Non confondere raccomandazione e azione: L’esempio XML usa RecommendedAction, mentre la tabella dei parametri chiama lo stesso ambito Action. Come valori testuali elenca Allow Packet, Drop Packet, Drop Session, Reset e Bypass Session, oltre a 3. Questo non costituisce una conferma che sia consentito sostituire RecommendedAction con un tag XML Action. Per 3 non viene spiegato alcun significato né alcuna associazione a un’azione testuale; non indovinare questo valore e non usarlo come abbreviazione per una determinata azione. Rileggere la raccomandazione effettivamente salvata e continuare a verificare separatamente l’azione della regola della policy IPS. Un oggetto creato tramite API non sostituisce né l’assegnazione della policy né i test positivo e negativo.

Confrontare le risposte API con l’operazione e lo stato salvato

Le righe seguenti sono documentate nei riferimenti degli oggetti SFOS 22/23. I nomi Message.* restano simboli di documentazione non risolti: non sono né messaggi di runtime garantiti, né testi di errore tradotti, né cause definitivamente confermate. Anche i numeri sono codici di stato XML, non codici di stato HTTP. Conservare insieme operazione, codice e risposta effettiva; non sostituire le righe specifiche dell’oggetto con un’interpretazione generale dei codici tratta dall’articolo centrale sull’API.

Per Add Custom Signature, il riferimento indica:

• 200 — Message.CustomSigAddSuccess
• 500 — Message.CustomSigAddFailed
• 502 — Message.CustomSigRecordExists
• 504 — Message.CustomSigInvalidSignatureRule
• 505 — Message.IPSpolicyEngineRestartFail
• 506 — Message.CustomSignatureIpsOff

Per Update custom signature, indica:

• 200 — Message.CustomSigUpdateSuccess
• 500 — Message.CustomSigUpdateFailed
• 502 — Message.CustomSigRecordExists
• 504 — Message.CustomSigCustomSignatureCheck1
• 505 — Message.IPSpolicyEngineRestartFail
• 506 — Message.CustomSignatureIpsOff

Proprio 504 distingue Add e Update attraverso il simbolo; Message.CustomSigCustomSignatureCheck1 non viene reinterpretato come un presunto messaggio inequivocabile di errore sintattico. Prima di ripetere Add/Update, riaprire la voce in WebAdmin o verificarla con una query di lettura confermata per la build: Name, Protocol, Custom rule, Severity e Recommended action corrispondono allo stato desiderato? Con 502, confrontare l’identità esistente e quella desiderata, senza sovrascrivere automaticamente né creare una voce con un secondo nome. Con 504, confrontare inoltre la regola esatta con la documentazione della build. Con 505, verificare insieme stato salvato, stato di IPS e ips.log; dal simbolo non derivano né un rollback sicuro né l’autorizzazione a riavviare il motore. Con 506, controllare lo stato di IPS e della licenza facendo riferimento alla sezione sul ciclo di vita, senza però attivare o disattivare IPS sulla base di un sospetto. Anche dopo 200, restano da verificare i valori salvati, il collegamento alla policy e il percorso dei dati; 500 non dimostra che non sia avvenuta alcuna modifica parziale.

Per Delete Custom Signature sono documentate queste righe specifiche:

• 200 — Message.CustomSigDeleteSuccess
• 500 — Message.CustomSigDeleteFailed
• 503 — Message.CustomSignatureInUse
• 506 — Message.CustomSignatureIpsOff

Autorizzare Delete solo dopo il rollback descritto sotto e una verifica completa degli utilizzi. Con 503, esaminare i riferimenti delle policy all’oggetto effettivo, senza eliminare indiscriminatamente una policy di produzione. Con 506, chiarire lo stato di IPS e della licenza, anziché disattivare globalmente IPS per tentare un’eliminazione. Dopo la risposta, verificare l’assenza del nome esatto e lo stato previsto delle policy dipendenti; con 500 o una risposta poco chiara, non ripetere l’eliminazione alla cieca. Se stato salvato, risposta o competenza restano poco chiari, interrompere l’automazione e chiarire con il supporto Sophos la risposta depurata dai dati sensibili, la versione della regola, la build e i log. Qui non si afferma che alcun comportamento di runtime sia stato testato su un firewall.

Eseguire test positivo e negativo

Il test positivo invia il pattern concordato sulla porta prevista e nella direzione attesa. Nel Log Viewer, in alto a destra in WebAdmin, selezionare il modulo IPS e filtrare per orario del test, Source e Destination. Firma o SID, azione e orario devono corrispondere al test. ips.log fornisce dettagli aggiuntivi sul motore. Packet Capture in Diagnostics > Packet capture mostra inoltre Firewall Rule ID e IPS Policy ID. Il collegamento tra regola, Packet Capture e modulo di sicurezza è spiegato in Testare sistematicamente una regola firewall.

Dopo la fase pilota, è inoltre possibile valutare l’effetto in Reports > Network & threats > Intrusion attacks. Il report è utile per confrontare periodi diversi, ma non sostituisce il test positivo e negativo eseguito tempestivamente nel Log Viewer. XGS 87/87w e XGS 88/88w non supportano i report locali sul dispositivo; su questi modelli, eseguire le verifiche immediate descritte nel Log Viewer.

Segue poi almeno un test negativo: lo stesso servizio senza token, una porta diversa o una direzione differente. La firma non deve produrre corrispondenze. Per un pattern di contenuto sono importanti anche le normali richieste dell’applicazione, perché stringhe brevi o generiche possono comparire in payload del tutto legittimi.

Solo quando entrambi i test sono stabili si imposta l’azione di blocco pianificata e si ripete la verifica. Una firma bloccante si considera validata solo se viene arrestato esattamente il caso positivo, il caso negativo continua a funzionare e nessun’altra regola firewall o IPS causa l’effetto.

Verificare il numero di firme

Il numero può essere determinato in WebAdmin senza usare la shell. In Intrusion prevention > IPS policies, aprire una policy eliminabile e creare una nuova regola della policy. Con Select all, SFOS mostra il totale sopra Action. L’elenco è visibile solo quando si aggiunge una regola a una policy eliminabile; la finestra di dialogo può poi essere chiusa senza salvare.

Sophos documenta inoltre due query di sola lettura in 5. Device management > 3. Advanced shell:

psql -U nobody -d signature -p 5434 -c "select count (*) from tblidprules;"
psql -U nobody -d corporate -c "select count (*) from tblidpcustomsignature;"

Il primo comando conta le firme standard, il secondo quelle personalizzate. Queste query al database non modificano nulla, ma devono rientrare in una sessione di supporto o diagnostica documentata. Il numero non dimostra la qualità o il funzionamento e può cambiare con gli aggiornamenti dei pattern.

Per ogni query è prevista una singola riga di risultato sotto count, seguita da (1 row). I valori di esempio Sophos 28623 e 1 provengono da un esempio SFOS 19.0.1 e non sono valori attesi per SFOS 22/23. In caso di errori di database, connessione o autorizzazione, non modificare tabelle o servizi: utilizzare la verifica in WebAdmin e conservare l’output esatto e la build per il supporto.

Se la firma non funziona come previsto

Nessuna corrispondenza

Verificare innanzitutto che IPS sia attivo, che il traffico venga intercettato dalla regola firewall prevista con la policy IPS corretta e che la firma personalizzata sia effettivamente presente in una regola della policy valutata. Controllare poi protocollo, direzione, porta, cifratura e payload reale. Una stringa visualizzata nel browser non deve necessariamente comparire invariata nel pacchetto di rete.

È utile un Packet Capture con filtri circoscritti che mostri direzione, porta e contenuto visibile nel punto di cattura. L’assenza di un pattern in chiaro in una cattura cifrata, tuttavia, non dimostra che esso sia assente dal buffer IPS decifrato. Verificare quindi insieme punto di cattura, decifratura e ricostruzione del flusso. Per un test controllato in chiaro, il pattern effettivamente trasmesso deve essere verificabile; successivamente si controllano offset, depth, distance, within, stato del flusso e ordine delle regole della policy.

Troppe connessioni producono corrispondenze

La firma resta su Allow packet finché Source, Destination, porta, direzione o finestra di ricerca non sono stati circoscritti ulteriormente. Parole generiche, brevi sequenze binarie ed espressioni regolari non limitate sono cause tipiche. Una regola firewall ad ampio raggio rende inoltre l’effetto difficile da controllare.

Se dopo il salvataggio il firewall mostra un aumento dell’utilizzo delle risorse o un riavvio di IPS, conservare orario, modello, firmware, risorse libere e ips.log. Salvare ripetutamente varianti diverse non costituisce in questo caso un test rigoroso; occorre prima chiarire la causa e definire una finestra di manutenzione.

Eseguire il rollback in sicurezza

In caso di corrispondenze inattese, rimuovere prima la regola personalizzata dalla policy pilota o ripristinare la precedente policy IPS sulla regola firewall. Verificare poi nuove sessioni con test positivo e negativo. Eliminare la firma personalizzata solo quando non esistono altri utilizzi.

Prima dell’eliminazione, occorre documentare quali policy, regola firewall e applicazione abbiano utilizzato la firma. Log, versione della regola testata e motivo del rollback devono far parte della documentazione della modifica. Disattivare globalmente IPS o rimuovere l’intera policy di produzione non è un rollback adeguato per una singola firma difettosa.

FAQ