Creare e testare firme IPS personalizzate su Sophos Firewall

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

La firma da sola non protegge nulla. Deve essere utilizzata in una IPS policy, tale policy deve essere assegnata alla regola firewall che viene effettivamente applicata e il flusso deve essere visibile a IPS. Un pattern troppo ampio può bloccare traffico legittimo; uno troppo ristretto non genera corrispondenze.

Testare prima ogni nuova firma in una regola IPS pilota con Action: Allow packet. Anche se Recommended action è già Allow packet, prevale l’azione della regola dell’IPS policy. Drop packet, Drop session, Reset e Bypass session modificano il traffico di produzione e devono essere usati solo dopo un test positivo e uno negativo riproducibili.

Un pilot controllato in sei passaggi

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

Una voce salvata o un controllo sintattico riuscito non costituiscono ancora una prova di funzionamento. Il risultato è valido quando il test positivo attiva esattamente la Custom Signature e la regola firewall previste, il test negativo non genera alcuna corrispondenza e l’applicazione di produzione continua a funzionare come prima.

Quando è adatta una firma personalizzata

Le Custom Signatures sono adatte a una caratteristica stabile e visibile a livello di pacchetto o stream. Può trattarsi di un valore di protocollo proprietario, di un chiaro indicatore di exploit o di una protezione temporanea per una vulnerabilità interna nota. Il percorso dei dati previsto e la reazione desiderata devono essere definiti prima di scrivere la firma.

Per indirizzi IP o domini variabili, gli host, servizi e gruppi, i threat feed o regole firewall mirate sono generalmente più adatti. Una firma personalizzata non sostituisce inoltre il patch management o una regola del produttore ben mantenuta. Lo sviluppo di una firma permanente per un singolo evento di log è raramente proporzionato.

Il payload cifrato rappresenta un limite importante. IPS può rilevare un pattern content nel payload HTTPS solo se il contenuto viene effettivamente decifrato ed è visibile al motore nel percorso di elaborazione scelto. Senza una TLS Inspection adatta, normalmente rimangono disponibili solo caratteristiche non cifrate o comunque visibili.

Controllare prima licenza e ciclo di vita

Le firme personalizzate non possono essere configurate se la trial IPS è scaduta o se IPS Protection è disattivato in Intrusion prevention > IPS policies. Sophos consiglia di riattivare IPS entro 30 giorni se si vogliono conservare le Custom Signatures esistenti. Un backup o un’esportazione deve quindi far parte del piano di rollback prima di modifiche alla licenza, a IPS o a policy importanti.

IPS deve poi essere attivo globalmente e la regola firewall che elabora il traffico deve avere una IPS policy. La configurazione di base completa è descritta in Configurare e testare IPS in modo sicuro. Una firma personalizzata estende questo percorso dei dati; non è un meccanismo di protezione parallelo.

Limitare consapevolmente la sintassi della regola

La maschera separa Protocol e Custom rule. La regola combina singole parole chiave, i relativi valori e punti e virgola. Richiedere la corrispondenza di più caratteristiche indipendenti riduce generalmente i risultati casuali. Al tempo stesso, la firma non deve diventare così specifica da risultare inefficace dopo una modifica innocua del protocollo.

Per un test in chiaro esclusivamente controllato, selezionare TCP come protocollo e utilizzare, ad esempio, un pattern di payload mirato:

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

AVANET-IPS-PILOT è un valore di documentazione volutamente evidente. La regola firewall pilota corrispondente viene inoltre limitata al servizio di test, ad esempio alla porta TCP 8080. Token, direzione e porta vanno sostituiti con valori presenti nel flusso reale visibile a IPS. Questo esempio non è una firma d’attacco universale e non deve essere applicato invariato a regole di produzione ampie.

Payload e finestra di ricerca

content cerca una sequenza di caratteri o byte; i valori binari sono racchiusi tra barre verticali. nocase ignora maiuscole e minuscole per una corrispondenza content, mentre rawbytes lavora sui dati grezzi. depth e offset limitano la ricerca in modo assoluto nel payload; distance e within operano relativamente alla corrispondenza precedente. uricontent, isdataat e pcre coprono casi più specifici di URI, posizione ed espressioni regolari.

Una finestra di ricerca ristretta riduce i risultati casuali e il carico di elaborazione. In particolare, pcre, finestre ampie o più pattern content generici devono essere introdotti solo con pacchetti realistici e sotto carico monitorato. Se depth è più corto del pattern content cercato, la firma non potrà mai corrispondere.

Header, stream e valori strutturati

Origine, destinazione e porta possono essere limitate con srcaddr, dstaddr, srcport e dstport. Per l’header IP sono disponibili, tra gli altri, ttl, tos, id, ipopts, fragoffset, fragbits, dsize, ip_proto e samip. Le caratteristiche TCP vengono 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 destinati a protocolli strutturati o binari.

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

Creare la firma e assegnarla a una policy

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

Per il primo test, Recommended action rimane su Allow packet. Importante: l’azione della regola dell’IPS policy sostituisce questa raccomandazione; anche la regola pilota deve usare Allow packet. Le altre azioni hanno conseguenze molto più incisive:

• Drop packet elimina 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 analizza più il resto della sessione.

Per le azioni basate sulla sessione, SFOS esegue il controllo solo fino al primo pacchetto corrispondente. Prima di sostituire Allow packet con una di queste azioni, verificare che il primo match appartenga proprio alla sessione prevista.

Al salvataggio, SFOS riconfigura il motore IPS. L’operazione avviene senza interruzioni se è disponibile RAM libera sufficiente. In presenza di poca RAM libera, il motore può riavviarsi e causare una breve interruzione. Anche una modifica apparentemente piccola va quindi eseguita in una finestra monitorata. Dopo il salvataggio, controllare lo stato di IPS e ips.log per rilevare un riavvio o eventuali errori prima di proseguire il pilot.

Segue la seconda parte, spesso dimenticata: in Intrusion prevention > IPS policies, aprire una policy eliminabile destinata al pilot, aggiungere una regola, scegliere Custom signature, selezionare la firma e posizionare la regola specifica sopra quelle più ampie. SFOS valuta le regole dall’alto verso il basso. Assegnare poi la policy in Rules and policies > Firewall rules > [regola pilota] > Detect and prevent exploits (IPS).

Eseguire un test positivo e uno negativo

Il test positivo invia il pattern concordato sulla porta e nella direzione previste. In Log viewer, accessibile in alto a destra in WebAdmin, selezionare il modulo IPS e filtrare per ora del test, origine e destinazione. Firma o SID, azione e timestamp devono corrispondere al test. ips.log fornisce ulteriori dettagli. Packet Capture in Diagnostics > Packet capture mostra anche Firewall Rule ID e IPS Policy ID. Testare sistematicamente una regola firewall spiega il collegamento tra regola, cattura e modulo di sicurezza.

Dopo il pilot, l’effetto può essere esaminato anche in Reports > Network & threats > Intrusion attacks. Il report è utile per confrontare periodi, ma non sostituisce i test immediati in Log viewer.

Segue almeno un test negativo: lo stesso servizio senza token, un’altra porta o una direzione differente. La firma non deve corrispondere. Per un pattern content sono importanti anche le richieste normali dell’applicazione, perché stringhe brevi o generiche possono comparire in payload perfettamente legittimi.

Solo quando entrambi i test sono stabili si imposta l’azione di blocco prevista e si ripete la verifica. Una firma bloccante è collaudata solo se arresta esattamente il caso positivo, lascia proseguire quello negativo e nessun’altra regola firewall o IPS causa l’effetto.

Controllare il numero di firme

Il numero può essere verificato in WebAdmin senza usare la shell. In Intrusion prevention > IPS policies, aprire una policy eliminabile e aggiungere una nuova regola di policy. Con Select all, SFOS mostra il totale sopra Action. L’elenco è visibile solo durante l’aggiunta di una regola a una policy eliminabile; chiudere poi la finestra 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 predefinite, il secondo le Custom Signatures. Queste query del database non modificano i dati, ma devono comunque rientrare in una sessione di supporto o diagnosi documentata. Il numero non prova qualità o funzionamento e può cambiare con gli aggiornamenti dei pattern.

Se la firma non funziona come previsto

Non viene rilevata alcuna corrispondenza

Controllare prima che IPS sia attivo, che il traffico incontri la regola firewall prevista con la IPS policy corretta e che la Custom Signature sia effettivamente presente in una regola di policy valutata. Esaminare quindi protocollo, direzione, porta, cifratura e payload reale. Una stringa visualizzata in un browser non deve necessariamente comparire invariata nel pacchetto di rete.

Un Packet Capture con filtro ristretto aiuta a confermare contenuto visibile e direzione. Se il pattern non è già presente lì, modificare la regola IPS non può crearlo. Se i pacchetti sono visibili, controllare offset, depth, distance, within, stato dello stream e ordine delle regole della policy.

Corrispondono troppe connessioni

La firma rimane su Allow packet finché origine, destinazione, porta, direzione o finestra di ricerca non sono stati limitati meglio. Parole generiche, brevi sequenze binarie ed espressioni regolari senza limiti sono cause tipiche. Una regola firewall ampia rende l’effetto ancora più difficile da controllare.

Se dopo il salvataggio la firewall mostra un aumento delle risorse o un riavvio di IPS, conservare ora, modello, firmware, risorse libere e ips.log. Salvare ripetutamente varianti diverse non è più un test pulito; occorre prima chiarire la causa e una finestra di manutenzione.

Eseguire un rollback sicuro

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

Prima dell’eliminazione, documentare quale policy, regola firewall e applicazione la utilizzavano. I log, la versione di regola testata e il motivo del rollback fanno parte della documentazione del change. Disattivare IPS globalmente o rimuovere l’intera policy di produzione non è un rollback appropriato per una singola firma difettosa.

FAQ