Linee guida e Best Practice SIEM disaster recovery
Articoli tecnici ID:
KB90674
Ultima modifica: 04/10/2022
Ambiente
SIEM Enterprise Log Manager (ELM) 11.x
SIEM Enterprise Security Manager (ESM) 11.x
SIEM Event Receiver (Receiver) 11.x
Riepilogo
Quando il peggio accade, non è sempre noto quale sia il percorso giusto per il recupero. Questo documento copre gli errori più comuni, il modo migliore per ripristinare il servizio e la modalità di conservazione dei dati esistenti.
In comune disastri possono includere quanto segue:
- Perdita di ESM a causa di un errore hardware o file System.
- Perdita del Receiver a causa di un errore hardware o file System.
- Perdita di Olmo a causa di un errore hardware o file System.
- Altro danneggiamento del disco o del filesystem che non implica una sostituzione completa della casella.
Problema
La migliore prassi aziendale per disaster recovery è quella di eseguire backup regolari e mantenere una copia fuori sede ogni mese.
SIEM backup ed export Solutions:
- Backup del database ESM
- Backup del database ELM
- Esporta Policy Editor con regole personalizzate
- Esportazione allarme
- Esportazioni di rapporto e dashboard
- Esportazione elenco di controllo
- Esportazione origine dati del destinatario
Dispositivi senza backup. ESM mantiene la configurazione del dispositivo:
- Event Receiver (Receiver)
- Application Data Monitor (ADM)
- Database Event Monitor (DBM)
- Advanced Correlation Engine (ACE)
Soluzione
Ripristino di un ESM senza backup
ESM è uno dei dispositivi più critici di cui eseguire il backup. Tutte le informazioni sull'origine dati, dashboard e sui rapporti sono memorizzate in ESM. Se un ESM viene smarrito e non è disponibile un backup, è possibile che venga eseguito un recupero parziale dei dati utilizzando una sincronizzazione del Receiver.
- Quando l'ESM viene smarrito, immediatamente SSH direttamente a qualsiasi ricevitore collegato ad esso e al backup /etc/NitroGuard/thirdparty.conf .
Nota: Se i nomi delle origini dati del cliente in thirdparty.conf contengono un trattino (-) nel nome, sostituirlo con un altro carattere. In tal modo si evita un problema in cui i nomi delle origini dati vengono troncati dopo la sincronizzazione.
- Installare e rack il sostituto ESM. Assicurarsi che sia sulla stessa versione del dispositivo precedente.
- Impostare le chiavi SSH di tutti gli altri dispositivi Siem nuovamente su predefinito di fabbrica; ad esempio, il Receiver, ACE, ADM, DBM e ELM. Per istruzioni specifiche, attenersi alla procedura illustrata in KB74464-come reimpostare la chiave factory predefinita quando ssh non è autorizzato.
- Aggiungere i dispositivi a ESM utilizzando il relativo indirizzo IP esistente. Ad esempio, se l'indirizzo IP del destinatario prima del crash è 192.168.100.103 , aggiungerlo al nuovo ESM con lo stesso indirizzo IP. Non scrivere le impostazioni dell'origine dati. È importante che il Receiver mantenga la configurazione originale fino a quando non viene eseguita la sincronizzazione.
- Per ogni Receiver che è stato riaggiunto, accedere a Proprietà, configurazione del ricevitore, dispositivo di sincronizzazione. Se viene visualizzato un messaggio di errore relativo al destinatario che non dispone di origini dati, verificare che non siano state aggiunte manualmente le origini dati. Le origini dati includono tutti i dispositivi ePolicy Orchestrator (ePO) associati a un receiver. Ad esempio, il dispositivo di sincronizzazione non funziona se il Receiver non dispone di origini dati ma è presente un dispositivo ePO su ESM associato a tale ricevitore.
- Utilizzare il file Receiver thirdparty.conf per riportare la configurazione dell'origine dati a ESM e leggere automaticamente i dispositivi. L'utilizzo del file Receiver thirdparty.confconserva ipsids e identifica i dispositivi e consente di recuperare rapidamente la raccolta degli eventi consentendo l'accesso ai dati esistenti di Elm. Per sincronizzare la configurazione dal Receiver a ESM, sono necessari alcuni minuti.
- Al termine della sincronizzazione, modificare le origini dati del Receiver nella scheda origine dati . Scrivere le impostazioni dell'origine dati e policy roll.
L'ESM ora inizia a raccogliere gli eventi dal Receiver e l'elenco esistente di origini dati viene recuperato.
- Aprire qualsiasi origine dati sul Receiver e fare clic su registrazione nella visualizzazione modifica. Questa azione richiede all'utente di associare un Olmo al receiver. Rispondere Sì e consentire il completamento dell'azione.
- Ripetere il passaggio 8 per tutti i destinatari di ESM. Questo passaggio fa in modo che l'archivio ELM e la ricerca ELM avanzata funzionino in seguito.
Ripristino di un ricevitore dopo la sostituzione o l'arresto anomalo
La configurazione del Receiver viene memorizzata su ESM. Per sostituire un receiver, attenersi alla procedura riportata di seguito:
- Rack e installazione del Receiver sostitutivo o re-ISO del Receiver non riuscito se non è necessario un RMA.
- Eseguire il provisioning del nuovo Receiver con lo stesso indirizzo IP del vecchio Receiver e assicurarsi che sia sulla stessa versione del dispositivo precedente.
- Digitare il dispositivo dall'interfaccia utente grafica andando su proprietà del Receiver, gestione delle chiavi.
- In Proprietà ricevitore, scheda connessione , fare clic su stato. Passare al passaggio successivo quando lo stato viene tirato indietro e non genera un errore SSH.
- Nella scheda proprietà del Receiver, Data Source , modificare qualsiasi origine dati per attivare il pulsante di scrittura , quindi fare clic su Scrivi per scrivere le impostazioni dell'origine dati e Policy roll.
- La raccolta dei dati sul Receiver riprende dopo l'esecuzione della scrittura e del rotolamento.
Ripristino di un dispositivo Elm senza backup del database Elm
L'Olmo è uno dei dispositivi SIEM più critici per la conformità e i backup devono essere creati regolarmente. Se l'hardware ELM viene sostituito o richiede riimaging, potrebbe essere possibile recuperarlo. Il percorso del database e i registri ELM devono essere su un dispositivo CIFS, NFS, SAN o iSCSI affinché sia possibile eseguire il ripristino.
- Eseguire il rack e installare il nuovo Olmo utilizzando lo stesso indirizzo IP dell'unità precedente. Assicurarsi che l'Olmo si trovi sulla stessa versione di Siem dell'originale.
- Reinstallare i volumi SAN o iSCSI mancanti in Proprietà Elm, scheda archiviazione dati . Se si utilizza NFS o CIFS, ignorare questo passaggio.
- Rekey l'Olmo in Proprietà, gestione delle chiavi.
- Accedere a Proprietà Elm, pool di archiviazione.
- Nella finestra superiore, in dispositivi, aggiungere nuovamente il dispositivo NFS, CIFS, Sano iSCSI utilizzato in precedenza. Per i dispositivi NFS e CIFS, assicurarsi di utilizzare lo stesso nome e percorso di condivisione precedentemente utilizzati. Se il nome e il percorso della condivisione precedente non sono noti, utilizzare il percorso di rete in cui è archiviata la mgtdb Directory. L'idea è quella di creare un dispositivo di storage pool con accesso alla directory Olmi mgtdb sulla rete.
- SSH all'Olmo e confermare se la condivisione di df -h rete è accessibile eseguendo.
- Individuare la mgtdb directory nel percorso della condivisione di rete dalla riga di comando di Elm. Ad esempio, se la condivisione NFS è 10.10.10.10 e il punto di Mount è /elm_storage/nfs_1 , è possibile utilizzare cd /elm_storage/nfs_1 e ls -al per trovare una mgtdb Directory. Se tutto il resto non riesce, find / -name 'mgtdb' Mostra tutti i percorsi. Si sta tentando di trovare la posizione originale mgtdb sulla rete.
- Dopo aver trovato la posizione originale mgtdb , esaminare i collegamenti /usr/local/elm/mgtdb/elm_allocations/MGTDBxxx simbolici e assicurarsi che alla fine ritornino alla /elm_storage/xxx nfs condivisione. Ad esempio, se mgtdb è stato trovato in /elm_storage/nfs_1/mgtdb , è possibile creare un collegamento simbolico in /elm_allocations/xxx tale punto /elm_storage/nfs_1/mgtdb . È quindi possibile creare un collegamento simbolico in /usr/local/elm/mgtdb cui si fa riferimento al link simbolico in /elm_allocations/xx, cui viene quindi indicato il nfs supporto in /elm_storage/xxx . A titolo esemplificativo, /usr/local/elm/mgtdb si tratta di un collegamento simbolico che punta /elm_allocations/MGTDB_Alloc123/elm_allocations/MGTDB_Alloc123symlink a/elm_storage/nfs_1/mgtdb.
- /usr/local/elm/mgtdb punti di collegamento simbolici a /elm_allocations/MGTDB_xxx
- /elm_allocations/MGTDB_xxx punta a /elm_storage/name_of_NFS_mount/mgtdb
- /elm_storage/name_of_NFS_mount/mgtdb è il punto in cui la condivisione NFS è montata su SIEM e contiene una sottodirectory di mgtdb, cui contiene il database
- Eseguire il comando vi /etc/NitroGuard/mgtdbloc.conf e verificare che il percorso corrisponda al collegamento simbolico al passaggio 8, ad esempio /elm_storage/nfs_1/mgtdb .
- Per rendere effettive le modifiche, eseguire ELMStop e ELMStart .
- Dopo l'avvio del database ELM, l'Olmo comincia a funzionare, ma i storage.conf file e alloc.conf devono essere ricreati manualmente.
Connettersi al database ELM, query e individuare i nomi dei pool di archiviazione e della relativa posizione. Ad esempio, nquery -d rec -i --long --noblob apre il database. (Il database ELM viene ancora chiamato rec .) È quindi possibile ottenere i nomi dei dispositivi di storage utilizzando select * from rg . È anche possibile ottenere i nomi di ciascun shid nome e di assegnazione esaminando le tabelle come rg2sh o sh .
- SSH all'Olmo appena commissionato.
Dichiarazione di non responsabilità
Il contenuto di questo articolo è stato scritto in inglese. In caso di differenze tra il contenuto in inglese e la traduzione, fare sempre riferimento al contenuto in iglese. Parte del contenuto è stata tradotta con gli strumenti di traduzione automatica di Microsoft.
|
