Questo post vi aiuterà a scrivere regole di Snort efficaci per migliorare materialmente il vostro livello di sicurezza. Inizieremo con una suddivisione di come viene costruita una regola e poi esploreremo le migliori pratiche con esempi per catturare il maggior numero possibile di attività dannose utilizzando il minor numero possibile di regole.
Snort è un sistema di rilevamento delle intrusioni di rete (NIDS) open-source che fornisce analisi dei pacchetti in tempo reale e fa parte della soluzione Coralogix STA. Se sei un cliente Coralogix STA, assicurati di controllare anche il mio post precedente su come modificare le regole di Snort in STA.
Anatomia delle regole di Snort
Prima di immergerci nelle diverse strategie per scrivere le migliori regole di Snort, iniziamo a sezionare una regola di Snort di esempio:
alert: dice a Snort di segnalare questo comportamento come un alert (è obbligatorio nelle regole create per STA).
tcp: significa che questa regola si applicherà solo al traffico in TCP.
any: in questo contesto, significa “da qualsiasi porta sorgente”, poi c’è una freccia ‘->’ che significa “una connessione a” (non c’è un operatore ‘<-‘, ma si possono semplicemente invertire gli argomenti attorno all’operatore. Puoi usare l’operatore ‘<>’ per indicare che la direzione della connessione è irrilevante per questa regola), poi un intervallo IP che indica l’indirizzo IP di destinazione e poi la porta. Puoi indicare un intervallo di porte usando i due punti come 0:1024 che significa 0-1024. Nella parentesi tonda, ci sono alcune direttive per impostare il messaggio di avviso, i metadati sulla regola, così come i controlli aggiuntivi.
msg: è una direttiva che imposta semplicemente il messaggio che verrà inviato (a Coralogix nel caso STA) nel caso in cui venga rilevato un traffico corrispondente.
flow: è una direttiva che indica se il contenuto che stiamo per definire come nostra firma deve apparire nella comunicazione al server (“to_server”) o al client (“to_client”). Questo può essere molto utile se, ad esempio, vogliamo rilevare la risposta del server che indica che è stato violato.
established: è una direttiva che farà sì che Snort limiti la ricerca di pacchetti che corrispondono a questa firma solo ai pacchetti che fanno parte di connessioni stabilite. Questo è utile per minimizzare il carico su Snort.
uricontent: è una direttiva che indica a Snort di cercare un certo testo nel contenuto dell’URI HTTP normalizzato. In questo esempio, stiamo cercando un url che sia esattamente il testo “/root.exe”.
nocase: è una direttiva che indica che vorremmo che Snort conducesse una ricerca case insensitive.
classtype: è una direttiva che è un attributo di metadati che indica quale tipo di attività questa regola rileva.
reference: è una direttiva che è un attributo di metadati che collega a un altro sistema per ulteriori informazioni. Nel nostro esempio, il valore url,<https://….> si collega a un URL su Internet.
sid: è una direttiva che è un attributo di metadati che indica l’ID della firma. Se stai creando la tua firma (anche se stai solo sostituendo una regola integrata), usa un valore superiore a 9.000.000 per evitare una collisione con un’altra regola preesistente.
rev: è una direttiva che indica la versione della regola.
C’è molto altro da imparare sulle regole di Snort che supporta il parsing RegEx, il parsing specifico del protocollo (proprio come uricontent per HTTP), la ricerca di dati binari (non testuali) utilizzando valori esadecimali di byte e molto altro. Se volete saperne di più potete iniziare qui.
Best Practices to Writing Effective Snort Rules
- Mirate alla vulnerabilità, non all’exploit – Evitate di scrivere regole per rilevare uno specifico exploit kit perché ci sono innumerevoli exploit per la stessa vulnerabilità e possiamo essere sicuri che ne vengono scritti di nuovi mentre state leggendo questo. Per esempio, molte delle prime firme per rilevare gli attacchi di buffer overrun assomigliano a questa:
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (content:"AAAAAAAAAAAAAA", msg:"Buffer overrun detected.")
La ragione di ciò è naturalmente che per lanciare un attacco di buffer overrun di successo, l’attaccante ha bisogno di riempire il buffer di una certa variabile e aggiungere il suo payload dannoso alla fine in modo che diventi eseguibile. I caratteri che sceglie di utilizzare per riempire il buffer sono completamente insignificanti e infatti, dopo la comparsa di tali firme, molti toolkit di attacco hanno semplicemente utilizzato una o più lettere diverse per riempire il buffer, eludendo completamente il rilevamento di questo tipo di firma. Un modo molto migliore sarebbe quello di tentare di rilevare questo tipo di attacchi rilevando l’input errato nei campi in base al loro tipo e lunghezza.
- La vostra peculiarità è la vostra migliore risorsa, quindi usatela – Ogni organizzazione ha cose che la rendono unica. Molte di queste possono essere molto utili quando si cerca di catturare attività dannose nella vostra organizzazione – sia esterne che interne. Utilizzando questa profonda conoscenza interna a vostro vantaggio, convertirete essenzialmente il problema da tecnologico a un puro problema di intelligence vecchio stile, costringendo gli aggressori ad avere una comprensione molto più intima della vostra organizzazione per essere in grado di nascondere efficacemente le loro tracce. Queste cose possono essere di natura tecnologica o basate sulle particolari abitudini di lavoro e linee guida interne della vostra organizzazione. Ecco alcuni esempi:
- Orari di lavoro tipici: Alcune organizzazioni in cui ho lavorato non permettevano ai dipendenti di lavorare da casa e la maggior parte dei dipendenti avrebbe già lasciato l’ufficio alle 19:00. Per organizzazioni simili, avrebbe senso impostare un avviso per notificare le connessioni dall’ufficio dopo una certa ora. Un aggressore che volesse installare un software maligno nella vostra organizzazione dovrebbe conoscere questo comportamento e sintonizzare il suo malware per comunicare con i suoi server di Comando & Controllo proprio nello stesso momento in cui tali comunicazioni passerebbero inosservate.
- Browser tipico: Supponiamo che la vostra organizzazione abbia deciso di utilizzare il browser Brave come browser principale e che venga installato automaticamente su ogni nuovo portatile aziendale e che abbiate rimosso i collegamenti sul desktop al browser IE/Edge da tutti i vostri portatili aziendali. Se questo è il caso, una connessione dall’organizzazione, sia ad un indirizzo interno che esterno che usa un browser diverso come IE/Edge dovrebbe essere configurato per sollevare un allarme.
- Intervalli IP basati sui Ruoli: Se è possibile assegnare diversi intervalli IP per diversi server in base al loro ruolo, per esempio, avere tutti i server DB su 192.168.0.0/24, i server web su 192.168.1.0/24, ecc allora sarebbe possibile e anche facile impostare regole intelligenti in base al comportamento atteso dei vostri server in base al loro ruolo. Per esempio, i server di database di solito non si connettono ad altri server da soli, le stampanti non cercano di connettersi ai vostri controller di dominio, ecc.
- Tentativi di connessione insoliti: Molte organizzazioni usano una condivisione pubblica su un file server per aiutare i loro utenti a condividere i file tra loro e usano stampanti abilitate alla rete per permettere ai loro utenti di stampare direttamente dai loro computer. Ciò significa che i computer client non dovrebbero connettersi l’un l’altro, anche se avete (saggiamente) scelto di bloccare tale accesso in un firewall o allo switch, il solo tentativo di connettersi da un client a un altro computer client dovrebbe sollevare un allarme ed essere indagato a fondo.
- Porte non comuni: Alcune organizzazioni utilizzano una libreria speciale per l’ottimizzazione della comunicazione tra i servizi in modo che tutte le comunicazioni HTTP tra i server utilizzino una porta diversa da quelle comuni (come 80, 443, 8080, ecc.). In questo caso, è una buona idea creare una regola che verrebbe attivata da qualsiasi comunicazione su queste porte normalmente comuni.
- Honeytokens – In un campo di battaglia come Internet dove tutti possono essere praticamente chiunque, l’inganno, funziona bene per i difensori così come per gli attaccanti, se non meglio. Trucchi come rinominare l’account di amministratore incorporato con un nome diverso e meno attraente e creare un nuovo account chiamato Amministratore che non userai mai e creare una regola di Snort per rilevare se questo nome utente, email o password sono mai usati in rete. Sarebbe quasi impossibile per gli aggressori notare che Snort ha rilevato i loro tentativi di utilizzare il falso utente amministratore. Un altro esempio è quello di creare falsi prodotti, clienti, utenti e record di carte di credito nel database e poi far corrispondere le regole di Snort per rilevarli nel traffico di rete.
Speriamo che queste informazioni siano state utili. Per ulteriori informazioni su Coralogix STA, date un’occhiata alle ultime caratteristiche che abbiamo rilasciato di recente.
Per ulteriori informazioni su Coralogix STA, date un’occhiata alle ultime caratteristiche che abbiamo rilasciato di recente.