Questa è la quarta parte della serie “Caccia con Splunk: Le basi”.
Utilizzo di metadati e tstat per stabilire rapidamente la consapevolezza della situazione
Quindi vuoi andare a caccia, eh??? Bene, mio giovane padwa, aspetta. Come un Jedi Splunk una volta mi ha detto, devi prima andare piano per andare veloce. Cosa intendo con questo? Beh, se ti precipiti nella caccia alle minacce e inizi a imbracciare la SPL indiscriminatamente, rischi di creare lacune nelle tue indagini. Quali lacune potrebbero essere? Come disse un uomo saggio, Conosci la tua rete. In realtà—in questo caso-conosci la tua rete e gli host. Per cacciare in modo efficace, capire i dati che hai e non hai per i tuoi host è la chiave. Senza questa conoscenza, si rischia di fare ipotesi che portano a decisioni sbagliate, mentre la caccia alle minacce.
Oggi, ho intenzione di condividere con voi la mia metodologia intorno raccolta di informazioni iniziali e come io uso i metadati e comandi tstats per capire i dati a mia disposizione quando inizio la caccia alle minacce.
Iniziamo guardando i metadati. Il comando metadati è un comando di generazione, il che significa che è il primo comando in una ricerca. Per coloro che non sono completamente aggiornati su Splunk, ci sono alcuni campi che vengono scritti al momento dell’indice. Questi campi sono _time, source (dove ha avuto origine l’evento; potrebbe essere un percorso di file o un valore di protocollo/porta), sourcetype (tipo di dati della macchina) e host (nome host o IP che ha generato un evento). Questi campi di metadati (vedi cosa ho fatto lì?) può essere cercato e restituito con valori che includono la prima volta, l’ultima volta e contano per un particolare valore.
Ecco un paio di esempi.
Il mio manager mi ha incaricato di iniziare la caccia sulla base di alcuni indicatori recentemente raccolti. Il mio primo pensiero è vedere che ho a disposizione set di dati che riguardano il tempo in cui sto cacciando. Questa è una ricerca rapida che potrei eseguire per enumerare sourcetypes in Splunk negli ultimi sette giorni.
Come puoi vedere, negli ultimi sette giorni ho 5.162 eventi FireEye. Facendo una piccola conversione di tempo epoch, determino che i dati hanno colpito per la prima volta il mio indicizzatore il 12 maggio 2017 alle 2:31:00 GMT e l’ultima volta che è stato visto sul mio indicizzatore è stato il 20 maggio 2017 22:01:12 GMT. Sulla base dell’intervallo di tempo della mia ricerca—è stato da maggio 13 22:00 GMT a maggio 20 22:38:15 GMT—Ho un alto livello di fiducia che i miei dati FireEye sono abbastanza attuali, ma se la mia indagine risale prima di maggio 12, non ho dati FireEye con cui lavorare, il che potrebbe influire sul modo in cui mi avvicino a questa attività o abbassare la mia fiducia nel determinare quando qualcosa è stato visto per la prima volta nella mia rete.
Ora che so quali tipi di dati ho in Splunk, vediamo quali host stanno inviando dati attraverso—ho dati correnti per tutti i miei host? Forse voglio isolare sugli host che stanno scrivendo su un indice specifico. In questo caso, voglio vedere tutti gli host che hanno dati nell’indice ‘os’ perché so che i dati in quell’indice saranno importanti per me nella mia caccia.
Il comando metadati non ha molte opzioni, ma è possibile restringere la ricerca a indici specifici, peer di ricerca o gruppi di server e persino sourcetypes (come ho fatto sopra). Una volta che hai un set di risultati, puoi flettere i muscoli SPL sui risultati per ottenere ulteriori informazioni. Forse vuoi migliorare la consapevolezza della situazione prima della caccia e verificare se ci sono host specifici che non hanno inviato dati a Splunk nelle ultime 24 ore.
In questa ricerca, ho usato il comando metadata per ottenere un elenco di host. Usando i comandi eval, search e fieldformat, sono stato in grado di filtrare gli host che non si erano registrati per più di 24 ore, modificare i valori temporali in qualcosa di più user friendly da visualizzare rispetto a quello che ho mostrato nel primo esempio, quindi ordinare e produrre in una vista tabella che può essere rapidamente consumata.
Un paio di considerazioni finali sui metadati. Richiede che la funzionalità get_metadata sia associata a un ruolo che l’utente ha prima che possa essere utilizzato. (Fatto divertente: lo sapevate che sotto il cofano, in realtà si esegue il comando metadati quando si fa clic sul pulsante Riepilogo dati nella home page di ricerca?)
E ora per qualcosa di completamente diverso… (No, non proprio).
Un altro comando potente, ma meno conosciuto in Splunk è tstats. Il comando tstats-oltre ad essere in grado di saltare edifici alti in un unico limite (ok, forse no)—può produrre risultati di ricerca a velocità accecante. Proprio come i metadati, tstats è un comando di generazione e funziona su campi indicizzati (host, source, sourcetype e _time) e modelli di dati. Amo i modelli di dati tanto quanto il prossimo ragazzo, ma non c’è abbastanza spazio per parlarne in questo post, quindi salviamoli per un’altra volta.
Nel frattempo, voglio migliorare la mia consapevolezza situazionale già consolidata e rispondere a una domanda fondamentale quando si inizia una caccia—a quali informazioni ho accesso e ho punti ciechi? Forse voglio ottenere rapidamente una vista nei miei eventi DNS.
Posso generare rapidamente un conteggio totale di eventi negli ultimi sette giorni in cui sourcetype è stream: dns e i dati risiedono nell’indice principale. In questa ricerca, i dati vengono suddivisi per _time e host in intervalli di 1 ora. Come i metadati-una volta eseguita la mia ricerca iniziale—posso usare SPL per formattare i dati come meglio ritengo, in questo caso usando il comando xyseries e quindi applicare un grafico ad area per generare un grafico di eventi provenienti dall’host in cui sto raccogliendo DNS. È importante notare che l’utilizzo di tstats in questo modo non è ottimale per più di una manciata di host. Se stai cercando un output tabulare e conteggi, non preoccuparti: questo può essere molto efficace. Cercando di grafico troppi host può ottenere molto occupato, rendendo difficile per un analista di consumare rapidamente.
Con questo gentile avvertimento, costruiamo una ricerca per identificare rapidamente gli host che registrano più o meno dati di quanto normalmente ci si possa aspettare. Posizionare i limiti sui dati, anche quando proviene da un gran numero di host, può essere fatto facilmente.
Per questa ricerca, sto guardando gli host che accedono all’indice ‘ os ‘ e voglio guardare indietro negli ultimi sette giorni nel ritagliare il tempo in intervalli di 3 ore per trovare il conteggio mediano degli eventi per host. La mediana è solo un’opzione statistica che posso usare; percentile e media sono disponibili anche in modo da utilizzare ciò che si sente è appropriato. Ho poi guardato indietro nel corso degli ultimi 3 ore per le stesse informazioni. Per determinare la differenza percentuale tra la mediana e il conteggio corrente, abbiamo diviso per ottenere un valore percentuale e filtrato per i risultati + / -5%. L’ordinamento e la ridenominazione dei campi rendono facile il consumo poiché ora ho i miei valori anomali, oltre a produrre un grafico che mostra la mediana e i volumi degli eventi correnti tracciati insieme alla differenza percentuale.