Regole basate su firme con Snort e Suricata

Snort e Suricata sono i due principali motori IDS/IPS open source. Condividono un linguaggio delle regole in gran parte compatibile, quindi una regola scritta per l'uno viene generalmente eseguita anche dall'altro.

Suricata aggiunge il multi-threading, parser nativi dei protocolli, l'estrazione dei file e un logging dettagliato (EVE JSON); Snort 3 ha modernizzato in modo analogo il proprio motore. Imparare una volta la sintassi delle regole consente di lavorare efficacemente con entrambi.

Ogni regola è composta da due parti: un header e un corpo tra parentesi contenente le opzioni. L'header definisce l'azione, il protocollo e la direzione del traffico; il corpo specifica che cosa cercare e come segnalarlo.

L'intestazione si legge da sinistra a destra:

• azione — alert, drop, reject, pass
• protocollo — tcp, udp, icmp, ip (oppure i protocolli applicativi in Suricata: http, dns, tls)
• IP/porta di origine e IP/porta di destinazione
• direzione — -> unidirezionale oppure <> bidirezionale

Le variabili come $HOME_NET e $EXTERNAL_NET provengono dalla configurazione, così le regole restano portabili tra ambienti diversi.

L'azione determina il comportamento IDS o IPS della regola:

• alert — registra e notifica, senza interrompere il traffico (IDS)
• drop — scarta silenziosamente il pacchetto (IPS, solo in modalità inline)
• reject — scarta il pacchetto e invia un reset TCP oppure un messaggio ICMP di destinazione irraggiungibile
• pass — consente esplicitamente il traffico, ignorando le regole successive

Lo stesso motore può funzionare come IDS o IPS a seconda che sia distribuito in modalità inline e delle azioni utilizzate.

La parola chiave content cerca una sequenza di byte nel payload. Il testo è racchiuso tra virgolette; i dati binari sono racchiusi tra barre verticali e rappresentati in esadecimale.

Le parole chiave di ancoraggio rendono le corrispondenze più precise: offset, depth, distance e within limitano la posizione in cui può comparire il modello, migliorando sia l'accuratezza sia le prestazioni.

Le regole moderne cercano corrispondenze nei buffer consapevoli del protocollo anziché nel flusso grezzo. Dopo una parola chiave che seleziona un buffer, le successive corrispondenze content vengono applicate a quella parte del protocollo analizzato.

• http_uri — l'URI della richiesta
• http_header — le intestazioni della richiesta o della risposta
• http_user_agent — il valore User-Agent
• tls_sni / dns_query — il nome del server TLS / la query DNS

È molto più affidabile che cercare una sottostringa nell'intero pacchetto.

Quando le stringhe fisse non bastano, pcre introduce le espressioni regolari compatibili con Perl. Abbini un filtro preliminare content, poco costoso, a pcre, così l'espressione regolare viene eseguita solo sui pacchetti candidati, preservando le prestazioni.

Il modificatore nocase rende la corrispondenza del contenuto senza distinzione tra maiuscole e minuscole; è importante per le intestazioni e per i campi controllati dall'utente, che gli attaccanti possono variare.

L'opzione flow limita una regola allo stato e alla direzione della connessione, riducendo i falsi positivi e il costo di elaborazione.

• established — solo nelle sessioni TCP completate
• to_server / to_client — direzione della richiesta o della risposta

Cercare le risposte del server solo quando la connessione è stabilita e la direzione è to_client evita di attivare la regola per pacchetti isolati o contraffatti.

Le opzioni di gestione mantengono un ruleset facilmente manutenibile:

• sid — ID univoco della signature (usi 1000000+ per le regole locali)
• rev — numero di revisione, da incrementare a ogni modifica
• msg — il testo dell'avviso visualizzato dagli analisti
• classtype — categoria che determina la priorità
• reference — collegamento a un CVE o a un avviso di sicurezza

sid stabili e rev incrementali consentono di monitorare e aggiornare le regole senza compromettere dashboard e soppressioni.

Sebbene siano compatibili a livello di regole, i due motori offrono funzionalità diverse:

• Suricata è multithread, analizza nativamente i protocolli applicativi, estrae file, calcola JA3 e genera JSON EVE
• Snort 3 ha riscritto il proprio motore per migliorare le prestazioni e introdurre un sistema modulare di plugin

Alcune parole chiave sono specifiche del motore. Suricata aggiunge parole chiave del livello applicativo (tls.sni, dns.query, http.method) e funzionalità dataset/flowbits. Quando condivide le regole, punti al minimo comune denominatore oppure mantenga ruleset specifici per ciascun motore.

Per evitare che una regola inondi la console, applichi delle soglie. detection_filter si attiva solo dopo N eventi in una finestra temporale; threshold con limit limita il volume degli avvisi.

È essenziale per il rilevamento degli attacchi di forza bruta e delle scansioni, in cui un singolo evento non è significativo ma lo è una raffica di eventi.

Legga una regola e ne prevedա il comportamento.

Ora è in grado di leggere e scrivere le signature Snort/Suricata:

• Una regola = intestazione (azione, protocollo, origine/destinazione, direzione) + opzioni del corpo
• L'azione determina IDS o IPS: alert, drop, reject, pass
• content con offset/depth e corrispondenze esadecimali individua i byte del payload
• I buffer sticky (http.uri, tls.sni, dns.query) confrontano i campi del protocollo analizzato
• pcre e nocase gestiscono modelli variabili
• flow limita la corrispondenza allo stato e alla direzione
• sid/rev/msg/reference mantengono le regole facilmente manutenibili
• Le soglie riducono il rumore prodotto da attacchi di forza bruta e scansioni

Prossimo argomento: rilevare le minacce senza alcuna signature.