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 con Allow packet e logging su un piccolo percorso pilota. 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 Allow packet.
3. Aggiungere la firma a una regola dedicata in una IPS policy eliminabile.
4. Assegnare questa IPS policy solo alla regola firewall pilota prevista e attivare il logging.
5. Generare un test corrispondente e uno deliberatamente non corrispondente, quindi confrontare Log Viewer, ips.log e la regola applicata.
6. Impostare l’azione prevista solo dopo un collaudo stabile; rimuovere l’assegnazione della policy o la firma 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.

La referenza completa della sintassi IPS personalizzata di SFOS 22 rimane vincolante per le regole complesse. 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 si impostano 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. 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.

Al salvataggio, SFOS riconfigura il motore IPS. Secondo Sophos, 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.

Segue la seconda parte, spesso dimenticata: in Intrusion prevention > IPS policies, aprire una policy eliminabile destinata al pilot, aggiungere una regola, selezionare la Custom Signature e posizionare la regola specifica sopra quelle più ampie. Assegnare poi questa policy, in Rules and policies > Firewall rules, alla regola pilota effettivamente applicata.

Eseguire un test positivo e uno negativo

Il test positivo invia il pattern concordato sulla porta e nella direzione previste. Contemporaneamente si registrano in Log Viewer Firewall Rule ID, IPS policy, nome della firma, origine, destinazione, azione e ora. ips.log fornisce ulteriori dettagli del motore; Testare sistematicamente una regola firewall spiega il collegamento tra regola, Packet Capture e modulo di sicurezza.

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