Documentazione su regole Snort e allerta tuning, in particolare per i nuovi utenti

5

Ho appena iniziato a usare Snort. C'è molto da fare. Sto solo cercando una documentazione migliore di ciò che alcune delle regole Snort in realtà significano - cioè, come dovrei reagire a loro quando ho un avviso per una determinata regola pop-up. Sembra che i documenti, gli esempi e i forum Snort presuppongano un sacco di conoscenze di base sull'amministratore della sicurezza di rete esoterica che non sembra avere (ancora).

Ad esempio, ho trovato questo:

link

Tuttavia quella sezione del sito web Snort è tristemente obsoleta e la parte di ricerca non funziona, e il 404 compare quando inserisco manualmente molti degli id delle regole a cui sono interessato.

Esempio, per il preprocessore stream5:

Il secondo, "129: 12", ha una descrizione testuale di "Segmenti TCP consecutivi di piccole dimensioni che superano la soglia". Che cosa vuol dire, anche? In che modo è indicativo di un problema? Ho esaminato la nostra rete e c'è solo attività di rete accettabile (che potrei dire). Durante un evento in cui Snort era molto prolisso su questo particolare problema (nell'ordine di 100 messaggi al minuto), il problema è stato ricondotto al traffico autorizzato che passa attraverso il nostro proxy Squid.

Quindi, dovrei semplicemente sopprimere tutti questi messaggi? È un modo normale per sintonizzare Snort? Basta sopprimere il rumore? Questo mi sembra pazzesco ... Se cancello tutti questi messaggi, cosa succede se ci sono messaggi di questa classe che effettivamente indicano un problema?

Spero che ti venga l'idea.

Attualmente sto usando pullpork per assemblare i set di regole e sopprimere le regole rumorose tramite le direttive di soppressione in threshold.conf.

Infine, dovrei menzionare che sto eseguendo Snort in un modo abbastanza non convenzionale, come soluzione alternativa per soddisfare i requisiti IDS per PCI, durante l'esecuzione nel cloud AWS. Per farla breve, abbiamo Snort in esecuzione su tutte le caselle che classifichiamo come caselle "edge" e stiamo sniffando il traffico su quelle. Fornirò maggiori dettagli se richiesto, ma ciò non cambia l'essenza di base di questa domanda.

    
posta JDS 17.02.2016 - 17:26
fonte

1 risposta

3

Stai riscontrando uno dei problemi più basilari con praticamente TUTTO il sistema di monitoraggio: come gestire correttamente i dati generati e separare il segnale dal rumore.

Sfortunatamente per te, non c'è una risposta facile perché tutto dipende da cosa sono le tue risorse e il valore di ciò che stai proteggendo.

Vorrei essere più specifico: se stai lavorando con una piccola rete di alto valore e hai un sacco di persone (competenti) per gestire l'attività, puoi lasciare tutti gli avvisi e indagare su tutti loro completamente. Ovviamente è molto costoso e hai bisogno di persone altamente qualificate (e probabilmente di un software molto intelligente) per essere in grado di gestirle correttamente.

D'altro canto, se disponi di una rete di grandi dimensioni e di basso valore con poche persone disponibili per la gestione degli incidenti, puoi decidere semplicemente di registrare tutto e analizzare solo i problemi che sono esplicitamente contrassegnati come incidenti attraverso un altro canale ("Chi ha cambiato la password dell'email del CEO?"). Il tuo IDS ti sarà comunque utile perché puoi utilizzare i log per alcune analisi post mortem di un incidente ma non ti consentirà di reagire in modo proattivo.

La maggior parte delle reti si trova tra questi due estremi, quindi devi creare avvisi che corrispondano il più fedelmente possibile al tuo reale livello di minaccia e alle capacità di risposta. Ci vuole tempo ed è un processo che dovrebbe essere continuo: dovrai adeguare le tue regole per reagire alle nuove minacce, ai cambiamenti di utilizzo o di capacità in ogni momento.

    
risposta data 17.02.2016 - 17:47
fonte

Leggi altre domande sui tag