Risoluzione dei problemi di svuotamento degli avvisi frequenti relativi alla salute non elaborati di FMC
Sommario
Introduzione
In questo documento viene descritto come risolvere i problemi relativi allo svuotamento degli eventi non elaborati e al frequente svuotamento degli avvisi di integrità degli eventi in Firepower Management Center.
Panoramica del problema
Firepower Management Center (FMC) genera uno dei seguenti avvisi di stato:
- Eventi unificati a bassa priorità eliminati di frequente
- Svuotamento di eventi non elaborati da eventi unificati a bassa priorità
Sebbene questi eventi vengano generati e visualizzati sul FMC, sono correlati a un sensore di dispositivo gestito, sia che si tratti di un dispositivo Firepower Threat Defense (FTD) o di un dispositivo Next-Generation Intrusion Prevention System (NGIPS). Nel prosieguo di questo documento, il termine sensore si riferisce sia ai dispositivi FTD che NGIPS, a meno che non sia specificato diversamente.
Questa è la struttura degli avvisi sull'integrità:
- Scarico frequente di <NOME SILO>
- Svuotamento degli eventi non elaborati da <NOME SILO>
Nell'esempio, il nome del SILO è Unified Low Priority Events. Questo è uno degli archivi di Gestione dischi (per una spiegazione più dettagliata, vedere la sezione Informazioni di base).
Inoltre:
- Sebbene ogni silo possa generare tecnicamente un Frequent drain of <SILO NAME> health alert, i più comunemente visti sono quelli relativi agli eventi e, tra questi, gli eventi a bassa priorità semplicemente perché sono il tipo di eventi più spesso generati dai sensori.
- Evento Frequent drain of <SILO NAME>. Gravità di avviso nel caso si tratti di un silo correlato a un evento. Se tali dati sono stati elaborati (dopo viene fornita una spiegazione su cosa costituisce un evento non elaborato), si trovano nel database FMC.
- Per un silo non correlato a eventi, ad esempio un silo di backup, l'avviso è critico in quanto tali informazioni vengono perse.
- Solo i silos dei tipi di eventi generano uno svuotamento degli eventi non elaborati dall'avviso di integrità <SILO NAME>. Questo avviso ha sempre un livello di gravità critico.
Altri sintomi possono includere:
- Perdita di eventi
- Lentezza nell'interfaccia utente del CCP
Scenari comuni di risoluzione dei problemi
Un evento Frequent drain of <SILO NAME> è causato da un input eccessivo nel silo per le sue dimensioni. In questo caso, il gestore del disco scarica (elimina) il file almeno due volte nell'ultimo intervallo di 5 minuti. In un silo di tipi di eventi, questo problema è in genere causato da un numero eccessivo di registrazioni di quel tipo di eventi. Se in uno svuotamento sono presenti eventi non elaborati di avviso di integrità <SILO NAME>, è possibile che si sia verificato un collo di bottiglia nel percorso di elaborazione degli eventi.
Nel diagramma sono illustrati tre potenziali colli di bottiglia:
- Il processo EventHandler su FTD è sovrascritto (legge più lentamente di quanto scrive Snort).
- Sottoscrizione eccessiva dell'interfaccia di gestione eventi.
- Il processo SFDataCorrelator su FMC è sovrascritto.
Per informazioni sull'architettura di elaborazione degli eventi, vedere la sezione Deep Dive.
Caso 1. Registrazione eccessiva
Come accennato nella sezione precedente, una delle cause più comuni per questo tipo di avvisi è l'input eccessivo.
La differenza tra Low Water Mark (LWM) e High Water Mark (HWM) (ricavata dal comando show disk-manager CLISH) indica lo spazio necessario per il silo. Per passare dal valore LWM (appena svuotato) al valore HWM, se si verificano frequenti svuotamenti di eventi (con o senza eventi non elaborati), è necessario prima esaminare la configurazione di registrazione.
Per una spiegazione dettagliata del processo di Disk Manager, vedere la sezione Deep Dive (Unità profonda).
Che si tratti di una doppia registrazione o di un'alta percentuale di eventi nell'ecosistema generale dei manager-sensori, è necessario rivedere le impostazioni di registrazione.
Azioni consigliate
Passaggio 1. Verificare la presenza di una doppia registrazione
È possibile identificare scenari di doppia registrazione se si esaminano le prestazioni dei correlatori nel FMC, come mostrato in questo output:
admin@FMC:~$ sudo perfstats -Cq < /var/sf/rna/correlator-stats/now
129 statistics lines read
host limit: 50000 0 50000
pcnt host limit in use: 0.01 0.01 0.01
rna events/second: 0.00 0.00 0.06
user cpu time: 0.48 0.21 10.09
system cpu time: 0.47 0.00 8.83
memory usage: 2547304 0 2547304
resident memory usage: 28201 0 49736
rna flows/second: 126.41 0.00 3844.16
rna dup flows/second: 69.71 0.00 2181.81
ids alerts/second: 0.00 0.00 0.00
ids packets/second: 0.00 0.00 0.00
ids comm records/second: 0.02 0.01 0.03
ids extras/second: 0.00 0.00 0.00
fw_stats/second: 0.00 0.00 0.03
user logins/second: 0.00 0.00 0.00
file events/second: 0.00 0.00 0.00
malware events/second: 0.00 0.00 0.00
fireamp events/second: 0.00 0.00 0.00
In questo esempio, è possibile vedere un'alta percentuale di flussi duplicati nell'output.
Passaggio 2. Verificare le impostazioni di registrazione del provider di servizi di audioconferenza
È necessario iniziare con una revisione delle impostazioni di registrazione dei criteri di controllo di accesso. Assicurarsi di utilizzare le procedure ottimali descritte in Procedure ottimali per la registrazione delle connessioni.
Si consiglia di rivedere le impostazioni di registrazione in tutte le situazioni, in quanto i consigli elencati non riguardano solo gli scenari di doppia registrazione.
Per verificare la frequenza degli eventi generati su FTD, controllare questo file e concentrarsi sulle colonne TotalEvents e PerSec:
admin@firepower:/ngfw/var/log$ sudo more EventHandlerStats.2023-08-13 | grep Total | more
{"Time": "2023-08-13T00:03:37Z", "TotalEvents": 298, "PerSec": 0, "UserCPUSec": 0.995, "SysCPUSec": 4.598, "%CPU": 1.9, "MemoryKB": 33676}
{"Time": "2023-08-13T00:08:37Z", "TotalEvents": 298, "PerSec": 0, "UserCPUSec": 1.156, "SysCPUSec": 4.280, "%CPU": 1.8, "MemoryKB": 33676}
{"Time": "2023-08-13T00:13:37Z", "TotalEvents": 320, "PerSec": 1, "UserCPUSec": 1.238, "SysCPUSec": 4.221, "%CPU": 1.8, "MemoryKB": 33676}
{"Time": "2023-08-13T00:18:37Z", "TotalEvents": 312, "PerSec": 1, "UserCPUSec": 1.008, "SysCPUSec": 4.427, "%CPU": 1.8, "MemoryKB": 33676}
{"Time": "2023-08-13T00:23:37Z", "TotalEvents": 320, "PerSec": 1, "UserCPUSec": 0.977, "SysCPUSec": 4.465, "%CPU": 1.8, "MemoryKB": 33676}
{"Time": "2023-08-13T00:28:37Z", "TotalEvents": 299, "PerSec": 0, "UserCPUSec": 1.066, "SysCPUSec": 4.361, "%CPU": 1.8, "MemoryKB": 33676}
Passaggio 3. Verificare se è prevista una registrazione eccessiva
È necessario verificare se la causa della registrazione eccessiva è prevista. Se un numero eccessivo di registrazioni è causato da attacchi DOS/DDoS, loop di routing o un'applicazione/host specifico che ha un elevato numero di connessioni; è necessario controllare e mitigare/interrompere le connessioni dalle origini di connessione impreviste/eccessive.
Passaggio 4. Verificare se il file diskmanager.log è danneggiato
In genere, una voce può avere 12 valori separati da virgole. Per verificare la presenza di righe danneggiate con un numero diverso di campi:
admin@firepower:/ngfw/var/log$ sudo cat diskmanager.log | awk -F',' 'NF != 12 {print}'
admin@firepower:/ngfw/var/log$
Se è presente una linea danneggiata con diversi da 12 campi, vengono visualizzati.
Passaggio 5. Aggiornamento del modello
Aggiornare il dispositivo hardware FTD a un modello con prestazioni più elevate (ad esempio, FPR2100 —> FPR4100), il silo di origine aumenterebbe.
Passaggio 6. Valutare se è possibile disabilitare Log to Ramdisk
Nel caso di un silo Unified Low Priority Events, è possibile disabilitare Log to Ramdisk per aumentare le dimensioni del silo. È possibile esaminare gli svantaggi nella sezione Immersione profonda.
Caso 2. Un collo di bottiglia nel canale di comunicazione tra il sensore e il CCP
Un'altra causa comune di questo tipo di allarme è costituita da problemi di connettività e/o instabilità nel canale di comunicazione (sftunnel) tra il sensore e la console centrale di gestione. Il problema di comunicazione può essere dovuto a:
- sottoscrizione eccessiva di sftunnel.
- sftunnel è inattivo o instabile (flap).
Per il problema di connettività del tunnel sicuro, verificare che FMC e il sensore abbiano raggiungibilità tra le loro interfacce di gestione sulla porta TCP 8305.
Con FTD è possibile cercare la stringa sftunneld nel file [/ngfw]/var/log/messages. I problemi di connettività provocano la generazione di messaggi di questo tipo:
Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_ch_util [INFO] Delay for heartbeat reply on channel from 10.62.148.75 for 609 seconds. dropChannel... Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_connections [INFO] Ping Event Channel for 10.62.148.75 failed Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_channel [INFO] >> ChannelState dropChannel peer 10.62.148.75 / channelB / EVENT [ msgSock2 & ssl_context2 ] << Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_channel [INFO] >> ChannelState freeChannel peer 10.62.148.75 / channelB / DROPPED [ msgSock2 & ssl_context2 ] << Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_connections [INFO] Need to send SW version and Published Services to 10.62.148.75 Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_peers [INFO] Confirm RPC service in CONTROL channel Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_channel [INFO] >> ChannelState do_dataio_for_heartbeat peer 10.62.148.75 / channelA / CONTROL [ msgSock & ssl_context ] << Sep 9 15:41:48 firepower SF-IMS[5458]: [5464] sftunneld:tunnsockets [INFO] Started listening on port 8305 IPv4(10.62.148.180) management0 Sep 9 15:41:51 firepower SF-IMS[5458]: [27602] sftunneld:control_services [INFO] Successfully Send Interfaces info to peer 10.62.148.75 over managemen Sep 9 15:41:53 firepower SF-IMS[5458]: [5465] sftunneld:sf_connections [INFO] Start connection to : 10.62.148.75 (wait 10 seconds is up) Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_peers [INFO] Peer 10.62.148.75 needs the second connection Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Interface management0 is configured for events on this Device Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Connect to 10.62.148.75 on port 8305 - management0 Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Initiate IPv4 connection to 10.62.148.75 (via management0) Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Initiating IPv4 connection to 10.62.148.75:8305/tcp Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Wait to connect to 8305 (IPv6): 10.62.148.75
La sottoscrizione in eccesso dell'interfaccia di gestione FMC può essere un picco nel traffico di gestione o una sovrassegnazione costante. I dati storici del Health Monitor ne sono un buon indicatore.
La prima cosa da notare è che nella maggior parte dei casi il FMC viene implementato con una singola scheda NIC per la gestione. Questa interfaccia viene utilizzata per:
- Gestione FMC
- Gestione dei sensori FMC
- Raccolta eventi FMC dai sensori
- Aggiornamento dei feed di intelligence
- Download di SRU, software, VDB e aggiornamenti GeoDB dal sito di download del software
- Query per reputazione e categorie URL (se applicabile)
- La query per le disposizioni file (se applicabile)
Azioni consigliate
È possibile distribuire una seconda scheda NIC nel FMC per un'interfaccia dedicata agli eventi. Le implementazioni dipendono dallo Use Case. Le linee guida generali sono disponibili nella Guida hardware di FMC - Distribuzione in una rete di gestione.
Caso 3. Una strozzatura nel processo di correlazione dei dati SFD
L'ultimo scenario trattato è quello in cui si verifica un collo di bottiglia sul lato SFDataCorrelator (FMC).
Il primo passaggio consiste nell'esaminare il file diskmanager.log in quanto vi sono informazioni importanti da raccogliere, quali:
- Frequenza dello scarico.
- Numero di file con eventi non elaborati eliminati.
-
Occorrenza dell'eliminazione con eventi non elaborati.
Per informazioni sul file diskmanager.log e su come interpretarlo, consultare la sezione Gestione dischi. Le informazioni contenute in diskmanager.log possono essere utilizzate per limitare i passaggi successivi.
Inoltre, è necessario esaminare le statistiche sulle prestazioni del correlatore:
admin@FMC:~$ sudo perfstats -Cq < /var/sf/rna/correlator-stats/now
129 statistics lines read
host limit: 50000 0 50000 pcnt host limit in use: 100.01 100.00 100.55 rna events/second: 1.78 0.00 48.65 user cpu time: 2.14 0.11 58.20 system cpu time: 1.74 0.00 41.13 memory usage: 5010148 0 5138904 resident memory usage: 757165 0 900792 rna flows/second: 101.90 0.00 3388.23 rna dup flows/second: 0.00 0.00 0.00 ids alerts/second: 0.00 0.00 0.00 ids packets/second: 0.00 0.00 0.00 ids comm records/second: 0.02 0.01 0.03 ids extras/second: 0.00 0.00 0.00 fw_stats/second: 0.01 0.00 0.08 user logins/second: 0.00 0.00 0.00 file events/second: 0.00 0.00 0.00 malware events/second: 0.00 0.00 0.00 fireamp events/second: 0.00 0.00 0.01
Queste statistiche si riferiscono al CCP e corrispondono all'aggregato di tutti i sensori da esso gestiti. Nel caso di eventi unificati a bassa priorità, vengono ricercati principalmente:
- Flussi totali al secondo di qualsiasi tipo di evento per valutare eventuali sottoscrizioni in eccesso del processo SFDataCorrelator.
- Le due righe evidenziate nell'output precedente:
- flussi rna/secondo: indica la frequenza di eventi a bassa priorità elaborati da SFDataCorrelator.
- flussi dup rna/secondo: indica la frequenza di eventi di bassa priorità duplicati elaborati da SFDataCorrelator. Questo viene generato dalla registrazione doppia come descritto nello scenario precedente.
Sulla base dei risultati ottenuti si può concludere che:
- Non sono presenti registrazioni duplicate come indicato dai flussi di dup RNA al secondo.
- Nella riga Flussi rna/secondo, il valore Massimo è molto più alto del valore medio, in quanto si è verificato un picco nella frequenza degli eventi elaborati dal processo SFDataCorrelator. Questo può essere previsto se si esamina la mattina presto quando il giorno lavorativo degli utenti ha appena iniziato; in generale, questo è un segnale d'allarme e richiede ulteriori indagini.
Ulteriori informazioni sul processo SFDataCorrelator sono disponibili nella sezione Elaborazione eventi.
Azioni consigliate
Innanzitutto, è necessario determinare quando si è verificato il picco. A tale scopo, è necessario esaminare le statistiche del correlatore per ogni intervallo di esempio di 5 minuti. Le informazioni raccolte da diskmanager.log possono essere utili per esaminare gli intervalli di tempo critici.
admin@FMC:~$ sudo perfstats -C < /var/sf/rna/correlator-stats/now
<OUTPUT OMITTED FOR READABILITY>
Wed Sep 9 16:01:35 2020 host limit: 50000 pcnt host limit in use: 100.14 rna events/second: 24.33 user cpu time: 7.34 system cpu time: 5.66 memory usage: 5007832 resident memory usage: 797168 rna flows/second: 638.55 rna dup flows/second: 0.00 ids alerts/second: 0.00 ids pkts/second: 0.00 ids comm records/second: 0.02 ids extras/second: 0.00 fw stats/second: 0.00 user logins/second: 0.00 file events/second: 0.00 malware events/second: 0.00 fireAMP events/second: 0.00 Wed Sep 9 16:06:39 2020 host limit: 50000 pcnt host limit in use: 100.03 rna events/second: 28.69 user cpu time: 16.04 system cpu time: 11.52 memory usage: 5007832 resident memory usage: 801476 rna flows/second: 685.65 rna dup flows/second: 0.00 ids alerts/second: 0.00 ids pkts/second: 0.00 ids comm records/second: 0.01 ids extras/second: 0.00 fw stats/second: 0.00 user logins/second: 0.00 file events/second: 0.00 malware events/second: 0.00 fireAMP events/second: 0.00 Wed Sep 9 16:11:42 2020 host limit: 50000 pcnt host limit in use: 100.01 rna events/second: 47.51 user cpu time: 16.33 system cpu time: 12.64 memory usage: 5007832 resident memory usage: 809528 rna flows/second: 1488.17 rna dup flows/second: 0.00 ids alerts/second: 0.00 ids pkts/second: 0.00 ids comm records/second: 0.02 ids extras/second: 0.00 fw stats/second: 0.01 user logins/second: 0.00 file events/second: 0.00 malware events/second: 0.00 fireAMP events/second: 0.00 Wed Sep 9 16:16:42 2020 host limit: 50000 pcnt host limit in use: 100.00 rna events/second: 8.57 user cpu time: 58.20 system cpu time: 41.13 memory usage: 5007832 resident memory usage: 837732 rna flows/second: 3388.23 rna dup flows/second: 0.00 ids alerts/second: 0.00 ids pkts/second: 0.00 ids comm records/second: 0.01 ids extras/second: 0.00 fw stats/second: 0.03 user logins/second: 0.00 file events/second: 0.00 malware events/second: 0.00 fireAMP events/second: 0.00 197 statistics lines read host limit: 50000 0 50000 pcnt host limit in use: 100.01 100.00 100.55 rna events/second: 1.78 0.00 48.65 user cpu time: 2.14 0.11 58.20 system cpu time: 1.74 0.00 41.13 memory usage: 5010148 0 5138904 resident memory usage: 757165 0 900792 rna flows/second: 101.90 0.00 3388.23 rna dup flows/second: 0.00 0.00 0.00 ids alerts/second: 0.00 0.00 0.00 ids packets/second: 0.00 0.00 0.00 ids comm records/second: 0.02 0.01 0.03 ids extras/second: 0.00 0.00 0.00 fw_stats/second: 0.01 0.00 0.08 user logins/second: 0.00 0.00 0.00 file events/second: 0.00 0.00 0.00 malware events/second: 0.00 0.00 0.00 fireamp events/second: 0.00 0.00 0.01
Utilizzate le informazioni nell'output per:
- Determinare la frequenza normale/di base degli eventi.
- Determinare l'intervallo di 5 minuti in cui si è verificato il picco.
Nell'esempio precedente, è presente un evidente picco nella frequenza degli eventi ricevuti alle 16:06:39 e oltre. Queste sono medie di 5 minuti, quindi l'aumento può essere più brusco di quanto mostrato (burst), tuttavia, diluito in questo intervallo di 5 minuti se ha iniziato verso la fine di esso.
Questo porta alla conclusione che questo picco di eventi ha causato lo svuotamento di eventi non elaborati. È possibile visualizzare la connessione degli eventi dall'interfaccia grafica dell'utente (GUI) di FMC con la finestra temporale appropriata per comprendere il tipo di connessioni che hanno attraversato la casella FTD in questo picco:
Applica questa finestra temporale per visualizzare gli eventi di connessione filtrati (non dimenticare di tenere conto del fuso orario). In questo esempio, il sensore utilizza UTC e FMC UTC+1. Utilizzare la Vista tabella per visualizzare gli eventi che hanno attivato il sovraccarico degli eventi e adottare le misure appropriate:
In base all'ora del primo e dell'ultimo pacchetto, si può notare che si tratta di connessioni di breve durata. Le colonne Pacchetto iniziatore e Pacchetto risponditore indicano che è stato scambiato un solo pacchetto in ciascuna direzione. Ciò conferma che le connessioni erano di breve durata e scambiavano pochissimi dati.
È possibile vedere tutti i flussi indirizzati agli stessi IP risponditore e alla stessa porta. Inoltre, sono tutti segnalati dallo stesso sensore (che insieme alle informazioni di interfaccia Ingress ed Egress può parlare al luogo e alla direzione dei flussi). Azioni aggiuntive:
- Controllare i syslog sull'endpoint di destinazione.
- Implementare la protezione DOS/DDOS o adottare altre misure preventive.
Nota: In questo articolo vengono fornite le linee guida per la risoluzione dei problemi relativi allo svuotamento degli avvisi degli eventi non elaborati. In questo esempio viene utilizzato hping3 per generare un flusso SYN TCP nel server di destinazione. Per le linee guida per fortificare il dispositivo FTD, consultare la Cisco Firepower Threat Defense Hardening Guide.
Elementi da raccogliere prima di contattare il Cisco Technical Assistance Center (TAC)
Si consiglia di raccogliere questi elementi prima di contattare Cisco TAC:
- Screenshot degli avvisi relativi allo stato di salute visualizzati.
- Risolvere i problemi relativi al file generato dal CCP.
- Risolvere i problemi relativi al file generato dal sensore interessato.
- Data e ora di inizio del problema.
- Informazioni su eventuali modifiche recenti apportate alle polizze (se del caso).
- L'output del comando stats_unified.pl come descritto nella sezione Elaborazione degli eventi (con una menzione dei sensori interessati).
Analisi approfondita
In questa sezione viene fornita una spiegazione dettagliata dei vari componenti che possono prendere parte ai tipi di avvisi sullo stato di salute. Ciò include:
- Elaborazione degli eventi: Copre gli eventi del percorso rilevati sia sui dispositivi sensore che sul FMC. Ciò è utile principalmente quando l'avviso di integrità fa riferimento a un silo di tipo evento.
- Gestione dischi: Illustra il processo di gestione dei dischi, gli archivi e il modo in cui vengono eliminati.
- Health Monitor: Illustra come i moduli di Health Monitor vengono utilizzati per generare avvisi di stato.
- Registra su Ramdisk: Descrive la funzionalità di registrazione su ramdisk e il suo impatto potenziale sugli avvisi relativi allo stato di salute.
Per comprendere gli avvisi di integrità relativi allo svuotamento degli eventi e identificare i potenziali punti di errore, è necessario esaminare il funzionamento e l'interazione tra questi componenti.
Elaborazione degli eventi
Mentre il tipo di avvisi sulla salute Frequent Drain può essere attivato da silos non correlati a eventi, la maggior parte dei casi rilevati da Cisco TAC è relativa a informazioni correlate a eventi di drenaggio. Inoltre, per comprendere che cosa costituisce un flusso di eventi non elaborati, è necessario esaminare l'architettura di elaborazione degli eventi e i relativi componenti.
Quando un sensore Firepower riceve un pacchetto da una nuova connessione, il processo di snort genera un evento nel formato unified2, ovvero un formato binario che consente di eseguire operazioni di lettura/scrittura più rapide, nonché eventi più leggeri.
L'output mostra la traccia di supporto del comando FTD, dove è possibile vedere che è stata creata una nuova connessione. Le parti importanti sono evidenziate e spiegate:
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 Packet: TCP, SYN, seq 3310981951
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 Session: new snort session
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 AppID: service unknown (0), application unknown (0)
192.168.0.2-42310 > 192.168.1.10-80 6 AS 1-1 I 0 new firewall session
192.168.0.2-42310 > 192.168.1.10-80 6 AS 1-1 I 0 using HW or preset rule order 4, 'Default Inspection', action Allow and prefilter rule 0
192.168.0.2-42310 > 192.168.1.10-80 6 AS 1-1 I 0 HitCount data sent for rule id: 268437505,
192.168.0.2-42310 > 192.168.1.10-80 6 AS 1-1 I 0 allow action
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 Firewall: allow rule, 'Default Inspection', allow
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 Snort id 0, NAP id 1, IPS id 0, Verdict PASS
I file Snort unified_events vengono generati per istanza nel percorso [/ngfw]var/sf/detection_engine/*/instance-N/, dove:
- * è l'UUID dell'ugello. Questa caratteristica è unica per ogni accessorio.
- N è l'ID istanza Snort che può essere calcolato come ID istanza dall'output precedente (lo 0 evidenziato nell'esempio) + 1
In una cartella di istanze Snort possono essere presenti due tipi di file unified_events:
- unified_events-1 (che contiene eventi ad alta priorità).
- unified_events-2 (che contiene eventi a bassa priorità).
Un evento con priorità alta è un evento che corrisponde a una connessione potenzialmente dannosa.
Tipi di eventi e relativa priorità:
| Priorità alta (1) |
Priorità bassa (2) |
| Intrusione |
Connessione |
| Malware |
Individuazione |
| Security Intelligence |
File |
| Eventi di connessione associati |
Statistiche |
Nell'output successivo viene mostrato un evento appartenente alla nuova connessione tracciata nell'esempio precedente. Il formato è unificato2 e viene ricavato dall'output del rispettivo registro eventi unificato situato in [/ngfw]/var/sf/detection_engine/*/instance-1/ dove 1 è l'ID istanza snort in grassetto nell'output precedente +1. Il nome formato del registro eventi unificato utilizza la sintassi unified_events-2.log.1599654750, dove 2 indica la priorità degli eventi come mostrato nella tabella e l'ultima parte in grassetto (1599654750) è il timestamp (Ora Unix) della data di creazione del file.
Suggerimento: È possibile utilizzare il comando Linux date per convertire l'ora Unix in una data leggibile:
admin@FP1120-2:~$ data sudo -d@1599654750
mer 9 set 14:32:30 CEST 2020
Unified2 Record at offset 2190389
Type: 210(0x000000d2)
Timestamp: 0
Length: 765 bytes
Forward to DC: Yes
FlowStats:
Sensor ID: 0
Service: 676
NetBIOS Domain: <none>
Client App: 909, Version: 1.20.3 (linux-gnu)
Protocol: TCP
Initiator Port: 42310
Responder Port: 80
First Packet: (1599662092) Tue Sep 9 14:34:52 2020
Last Packet: (1599662092) Tue Sep 9 14:34:52 2020
<OUTPUT OMITTED FOR READABILITY>
Initiator: 192.168.0.2
Responder: 192.168.1.10
Original Client: ::
Policy Revision: 00000000-0000-0000-0000-00005f502a92
Rule ID: 268437505
Tunnel Rule ID: 0
Monitor Rule ID: <none>
Rule Action: 2
Accanto a ogni file unified_events è disponibile un file segnalibro contenente due valori importanti:
- Timestamp corrispondente al file unified_events corrente per tale istanza e priorità.
- Posizione in byte per l'ultimo evento di lettura nel file unified_event.
I valori sono ordinati e separati da una virgola, come mostrato nell'esempio:
root@FTD:/home/admin# cat /var/sf/detection_engines/d5a4d5d0-6ddf-11ea-b364-2ac815c16717/instance-1/unified_events-2.log.bookmark.1a3d52e6-3e09-11ea-838f-68e7af919059
1599862498, 18754115
In questo modo il processo di gestione dei dischi può sapere quali eventi sono già stati elaborati (inviati a FMC) e quali no.
Nota: Quando Gestione dischi svuota un silo di eventi, rimuove i file di eventi unificati.
Per ulteriori informazioni sullo svuotamento dei silos, consultare la sezione Gestione dischi.
Un file unificato svuotato può avere eventi non elaborati quando si verifica una delle seguenti condizioni:
- Il timestamp del segnalibro è inferiore all'ora di creazione del file.
- Il timestamp del segnalibro corrisponde all'ora di creazione del file e la posizione in Byte nel file è inferiore alle dimensioni.
Il processo EventHandler legge gli eventi dai file unificati e li invia in streaming al FMC (come metadati) tramite sftunnel, che è il processo responsabile della comunicazione crittografata tra il sensore e il FMC. Si tratta di una connessione basata su TCP in modo che il flusso di eventi venga riconosciuto da FMC
È possibile visualizzare questi messaggi nel file [/ngfw]/var/log/messages:
sfpreproc:OutputFile [INFO] *** Opening /ngfw/var/sf/detection_engines/77d31ce2-c2fc-11ea-b470-d428d53ed3ae/instance-1/unified_events-2.log.1597810478 for output" in /var/log/messages
EventHandler:SpoolIterator [INFO] Opened unified event file /var/sf/detection_engines/77d31ce2-c2fc-11ea-b470-d428d53ed3ae/instance-1/unified_events-2.log.1597810478
sftunneld:FileUtils [INFO] Processed 10334 events from log file var/sf/detection_engines/77d31ce2-c2fc-11ea-b470-d428d53ed3ae/instance-1/unified_events-2.log.1597810478
Questo output fornisce:
- Snort ha aperto il file unified_events per l'output (per scrivervi).
- Il gestore eventi ha aperto lo stesso file unified_events (per leggerlo).
- sftunnel ha riportato il numero di eventi elaborati dal file unified_events.
Il file del segnalibro viene quindi aggiornato di conseguenza. Il sftunnel utilizza due diversi canali denominati Unified Events (UE) Channel 0 e 1 rispettivamente per gli eventi ad alta e bassa priorità.
Con il comando sfunnel_status CLI sull'FTD, è possibile visualizzare il numero di eventi trasmessi.
Priority UE Channel 1 service
TOTAL TRANSMITTED MESSAGES <530541> for UE Channel service
RECEIVED MESSAGES <424712> for UE Channel service
SEND MESSAGES <105829> for UE Channel service
FAILED MESSAGES <0> for UE Channel service
HALT REQUEST SEND COUNTER <17332> for UE Channel service
STORED MESSAGES for UE Channel service (service 0/peer 0)
STATE <Process messages> for UE Channel service
REQUESTED FOR REMOTE <Process messages> for UE Channel service
REQUESTED FROM REMOTE <Process messages> for UE Channel service
Nell'FMC, gli eventi sono ricevuti dal processo SFDataCorrelator. Lo stato degli eventi elaborati da ciascun sensore può essere visualizzato eseguendo il comando stats_unified.pl:
admin@FMC:~$ sudo stats_unified.pl
Current Time - Fri Sep 9 23:00:47 UTC 2020
**********************************************************************************
* FTD - 60a0526e-6ddf-11ea-99fa-89a415c16717, version 6.6.0.1
**********************************************************************************
Channel Backlog Statistics (unified_event_backlog)
Chan Last Time Bookmark Time Bytes Behind
0 2020-09-09 23:00:30 2020-09-07 10:41:50 0
1 2020-09-09 23:00:30 2020-09-09 22:14:58 6960
Questo comando mostra lo stato del backlog degli eventi per un determinato dispositivo per canale e l'ID canale utilizzato è lo stesso di sftunnel. Il valore Byte dietro può essere calcolato come la differenza tra la posizione mostrata nel file dei segnalibri degli eventi unificati e la dimensione del file degli eventi unificati (più qualsiasi file successivo con un timestamp superiore a quello del file dei segnalibri).
Il processo SFDataCorrelator memorizza anche le statistiche sulle prestazioni, salvate in /var/sf/rna/correlator-stats/. Viene creato un file al giorno per memorizzare le statistiche delle prestazioni per quel giorno in formato CSV. Il nome del file utilizza il formato AAAA-MM-GG e il file corrispondente al giorno corrente viene chiamato adesso.
Le statistiche vengono raccolte ogni 5 minuti (c'è una riga per ogni intervallo di 5 minuti).
L'output di questo file può essere letto eseguendo il comando perfstats.
Nota: Questo comando viene utilizzato anche per leggere i file delle statistiche sulle prestazioni degli snort, pertanto è necessario utilizzare i flag appropriati.
-C: Indica che l'input è un file correlator-stats. Senza questo flag, perfstats presuppone che l'input sia un file di statistiche delle prestazioni snort.
-q: In modalità non interattiva viene stampato solo il riepilogo del file.
admin@FMC:~$ sudo perfstats -Cq < /var/sf/rna/correlator-stats/now
287 statistics lines read
host limit: 50000 0 50000
pcnt host limit in use: 100.01 100.00 100.55
rna events/second: 1.22 0.00 48.65
user cpu time: 1.56 0.11 58.20
system cpu time: 1.31 0.00 41.13
memory usage: 5050384 0 5138904
resident memory usage: 801920 0 901424
rna flows/second: 64.06 0.00 348.15
rna dup flows/second: 0.00 0.00 37.05
ids alerts/second: 1.49 0.00 4.63
ids packets/second: 1.71 0.00 10.10
ids comm records/second: 3.24 0.00 12.63
ids extras/second: 0.01 0.00 0.07
fw_stats/second: 1.78 0.00 5.72
user logins/second: 0.00 0.00 0.00
file events/second: 0.00 0.00 3.25
malware events/second: 0.00 0.00 0.06
fireamp events/second: 0.00 0.00 0.00
Ogni riga del riepilogo ha tre valori nell'ordine seguente: Media, Minima, Massima.
Se si stampa senza il flag -q, verranno visualizzati anche i valori di intervallo di 5 minuti (il riepilogo è riportato alla fine).
Nota: Ogni CCP ha una portata massima descritta nella scheda tecnica. La tabella seguente contiene i valori per modulo ricavati dal rispettivo foglio dati.
| Modello |
FMC 750 |
FMC 1000 |
FMC 1600 |
CCP 2000 |
FMC 2500 |
FMC 2600 |
FMC 4000 |
FMC 4500 |
FMC 4600 |
FMCv |
FMCv300 |
| Massima portata (fps) |
2000 |
5000 |
5000 |
12000 |
12000 |
12000 |
20000 |
20000 |
20000 |
Variabile |
12000 |
Nota: Questi valori si riferiscono all'aggregazione di tutti i tipi di evento visualizzati in grassetto nell'output delle statistiche SFDataCorrelator.
Se si controlla l'output e si dimensiona il CCP predisposto per lo scenario peggiore (quando tutti i valori massimi si verificano contemporaneamente), il tasso di eventi rilevato da questo CCP è 48,65 + 348,15 + 4,63 + 3,25 + 0,06 = 404,74 fps.
Il valore totale può essere confrontato con il valore del foglio dati del rispettivo modello.
SFDataCorrelator consente inoltre di eseguire ulteriori operazioni sugli eventi ricevuti, ad esempio le regole di correlazione, e quindi di archiviarli nel database, che viene interrogato per popolare varie informazioni nell'interfaccia utente grafica di FMC, ad esempio dashboard e visualizzazioni eventi.
Gestione dischi
Nel diagramma successivo vengono illustrati i componenti logici per entrambi i processi Health Monitor e Gestione disco, interconnessi per la generazione di avvisi di integrità relativi al disco.
In breve, il processo di gestione dei dischi gestisce l'utilizzo del disco della scatola e ha i suoi file di configurazione nella cartella [/ngfw]/etc/sf/. Esistono più file di configurazione per il processo di gestione dischi che vengono utilizzati in determinate circostanze:
- diskmanager.conf: File di configurazione standard.
- diskmanager_2hd.conf: Utilizzato quando nella confezione sono installati due dischi rigidi. Il secondo disco rigido è quello correlato all'espansione malware utilizzato per archiviare i file come definito nel criterio file.
- ramdisk-diskmanager.conf: Utilizzato quando il log su Ramdisk è abilitato. Fare riferimento alla sezione Log to Ramdisk.
Ogni tipo di file monitorato dal gestore del disco a cui è assegnato un Silo. In base alla quantità di spazio su disco disponibile nel sistema, Gestione dischi calcola un High Water Mark (HWM) e un Low Water Mark (LWM) per ciascun silo. Quando il processo di gestione dei dischi scarica un silo, lo fa fino a raggiungere LWM. Poiché gli eventi vengono svuotati per file, questa soglia può essere superata.
Per controllare lo stato degli archivi su un dispositivo sensore, è possibile eseguire questo comando:
> show disk-manager Silo Used Minimum Maximum misc_fdm_logs 0 KB 65.208 MB 130.417 MB Temporary Files 0 KB 108.681 MB 434.726 MB Action Queue Results 0 KB 108.681 MB 434.726 MB User Identity Events 0 KB 108.681 MB 434.726 MB UI Caches 4 KB 326.044 MB 652.089 MB Backups 0 KB 869.452 MB 2.123 GB Updates 304.367 MB 1.274 GB 3.184 GB Other Detection Engine 0 KB 652.089 MB 1.274 GB Performance Statistics 45.985 MB 217.362 MB 2.547 GB Other Events 0 KB 434.726 MB 869.452 MB IP Reputation & URL Filtering 0 KB 543.407 MB 1.061 GB arch_debug_file 0 KB 2.123 GB 12.736 GB Archives & Cores & File Logs 0 KB 869.452 MB 4.245 GB Unified Low Priority Events 974.109 MB 1.061 GB 5.307 GB RNA Events 879 KB 869.452 MB 3.396 GB File Capture 0 KB 2.123 GB 4.245 GB Unified High Priority Events 252 KB 3.184 GB 7.429 GB IPS Events 3.023 MB 2.547 GB 6.368 GB
Il processo di Gestione dischi viene eseguito quando si verifica una delle seguenti condizioni:
- Il processo viene avviato o riavviato
- Un silo raggiunge l'HWM
- Un silo viene svuotato manualmente
- Una volta all'ora
Ogni volta che il processo di gestione dei dischi viene eseguito, viene generata una voce per ciascuno dei diversi archivi nel proprio file di log, che si trova in [/ngfw]/var/log/diskmanager.log e contiene dati in formato CSV.
Viene quindi visualizzata una riga di esempio del file diskmanager.log. È stato preso da un sensore che ha attivato lo svuotamento di eventi non elaborati dall'avviso di integrità degli eventi a bassa priorità unificati, nonché la suddivisione delle rispettive colonne:
priority_2_events,1599668981,221,4587929508,1132501868,20972020,4596,1586044534,5710966962,1142193392,110,0
| Colonna | Valore |
| Etichetta silo |
priority_2_events |
| Tempo di scarico (tempo di esposizione) |
1599668981 |
| Numero di file eliminati | 221 |
| Byte eliminati | 4587929508 |
| Dimensioni correnti dei dati dopo lo svuotamento (byte) | 1132501868 |
| File di dimensioni maggiori svuotato (byte) | 20972020 |
| File più piccolo svuotato (byte) | 4596 |
| Il file meno recente è stato prosciugato (tempo di attesa) | 1586044534 |
| Limite massimo (byte) | 5710966962 |
| Limite minimo (byte) | 1142193392 |
| Numero di file con eventi non elaborati eliminati | 110 |
| Flag di stato di Diskmanager | 0 |
Queste informazioni vengono quindi lette dal rispettivo modulo Health Monitor per attivare l'avviso di integrità correlato.
Svuotamento manuale di un silo
In alcuni casi, è possibile svuotare manualmente un silo. Ad esempio, per liberare spazio su disco con l'eliminazione manuale dei silo, la rimozione manuale dei file consente al gestore del disco di decidere quali file conservare e quali eliminare. In Gestione disco vengono salvati i file più recenti per il silo.
Qualsiasi silo può essere svuotato e funziona come descritto (il gestore di dischi svuota i dati fino a quando la quantità di dati non rientra nella soglia LWM). Il comando system support silo-drain è disponibile in modalità FTD CLISH e fornisce un elenco dei silos disponibili (nome + ID numerico).
Questo è un esempio di svuotamento manuale del silo Unified Low Priority Events:
> show disk-manager Silo Used Minimum Maximum misc_fdm_logs 0 KB 65.213 MB 130.426 MB Temporary Files 0 KB 108.688 MB 434.753 MB Action Queue Results 0 KB 108.688 MB 434.753 MB User Identity Events 0 KB 108.688 MB 434.753 MB UI Caches 4 KB 326.064 MB 652.130 MB Backups 0 KB 869.507 MB 2.123 GB Updates 304.367 MB 1.274 GB 3.184 GB Other Detection Engine 0 KB 652.130 MB 1.274 GB Performance Statistics 1.002 MB 217.376 MB 2.547 GB Other Events 0 KB 434.753 MB 869.507 MB IP Reputation & URL Filtering 0 KB 543.441 MB 1.061 GB arch_debug_file 0 KB 2.123 GB 12.737 GB Archives & Cores & File Logs 0 KB 869.507 MB 4.246 GB Unified Low Priority Events 2.397 GB 1.061 GB 5.307 GB RNA Events 8 KB 869.507 MB 3.397 GB File Capture 0 KB 2.123 GB 4.246 GB Unified High Priority Events 0 KB 3.184 GB 7.430 GB IPS Events 0 KB 2.547 GB 6.368 GB > system support silo-drain Available Silos 1 - misc_fdm_logs 2 - Temporary Files 3 - Action Queue Results 4 - User Identity Events 5 - UI Caches 6 - Backups 7 - Updates 8 - Other Detection Engine 9 - Performance Statistics 10 - Other Events 11 - IP Reputation & URL Filtering 12 - arch_debug_file 13 - Archives & Cores & File Logs 14 - Unified Low Priority Events 15 - RNA Events 16 - File Capture 17 - Unified High Priority Events 18 - IPS Events 0 - Cancel and return Select a Silo to drain: 14 Silo Unified Low Priority Events being drained. > show disk-manager Silo Used Minimum Maximum misc_fdm_logs 0 KB 65.213 MB 130.426 MB Temporary Files 0 KB 108.688 MB 434.753 MB Action Queue Results 0 KB 108.688 MB 434.753 MB User Identity Events 0 KB 108.688 MB 434.753 MB UI Caches 4 KB 326.064 MB 652.130 MB Backups 0 KB 869.507 MB 2.123 GB Updates 304.367 MB 1.274 GB 3.184 GB Other Detection Engine 0 KB 652.130 MB 1.274 GB Performance Statistics 1.002 MB 217.376 MB 2.547 GB Other Events 0 KB 434.753 MB 869.507 MB IP Reputation & URL Filtering 0 KB 543.441 MB 1.061 GB arch_debug_file 0 KB 2.123 GB 12.737 GB Archives & Cores & File Logs 0 KB 869.507 MB 4.246 GB Unified Low Priority Events 1.046 GB 1.061 GB 5.307 GB RNA Events 8 KB 869.507 MB 3.397 GB File Capture 0 KB 2.123 GB 4.246 GB Unified High Priority Events 0 KB 3.184 GB 7.430 GB IPS Events 0 KB 2.547 GB 6.368 GB
Health Monitor
Questi sono i punti principali:
- Qualsiasi avviso relativo allo stato di salute visualizzato sul CCP nel menu Health Monitor o nella scheda Stato del centro messaggi viene generato dal processo Health Monitor.
- Questo processo controlla lo stato del sistema, sia per il CCP che per i sensori gestiti ed è composto da una serie di moduli diversi.
- I moduli di avviso di integrità sono definiti nei criteri di integrità, che possono essere collegati per dispositivo.
- Gli avvisi sull'integrità vengono generati dal modulo Utilizzo disco che può essere eseguito su ogni sensore gestito dal FMC.
- Quando il processo Health Monitor sul FMC è in esecuzione (una volta ogni 5 minuti o quando viene attivata un'esecuzione manuale), il modulo Disk Usage controlla il file diskmanager.log e, se vengono soddisfatte le condizioni corrette, viene attivato il relativo avviso di stato.
Affinché venga attivato un avviso di stato di svuotamento degli eventi non elaborati, tutte le condizioni seguenti devono essere vere:
- Il campo Byte svuotati è maggiore di 0 (indica che i dati di questo silo sono stati svuotati).
- Il numero di file con eventi non elaborati eliminati è maggiore di 0 (ciò indica la presenza di eventi non elaborati all'interno dei dati eliminati).
- Il tempo di scarico è nell'ultima ora.
Affinché venga attivato un avviso di stato Frequent Drain of events, è necessario che si verifichino le seguenti condizioni:
- Le ultime due voci del file diskmanager.log devono essere vere:
- Il campo Byte svuotati è maggiore di 0 (indica che i dati di questo silo sono stati svuotati).
- Distanza inferiore a 5 minuti.
- Il tempo di drenaggio nell'ultima voce per questo silo è nell'ultima ora.
I risultati raccolti dal modulo di utilizzo del disco (e i risultati raccolti da altri moduli) vengono inviati al FMC tramite sftunnel. È possibile visualizzare i contatori degli eventi sanitari scambiati tramite sftunnel eseguendo il comando sftunnel_status:
TOTAL TRANSMITTED MESSAGES <3544> for Health Events service
RECEIVED MESSAGES <1772> for Health Events service
SEND MESSAGES <1772> for Health Events service
FAILED MESSAGES <0> for Health Events service
HALT REQUEST SEND COUNTER <0> for Health Events service
STORED MESSAGES for Health service (service 0/peer 0)
STATE <Process messages> for Health Events service
REQUESTED FOR REMOTE <Process messages> for Health Events service
REQUESTED FROM REMOTE <Process messages> for Health Events service
Registra su disco RAM
Sebbene la maggior parte degli eventi sia memorizzata su disco, per impostazione predefinita il dispositivo è configurato in modo da eseguire il log su ramdisk per impedire danni graduali all'unità SSD che possono essere causati da scritture e eliminazioni costanti di eventi su disco.
In questo scenario, gli eventi non vengono memorizzati in [/ngfw]/var/sf/detection_engine/*/instance-N/; tuttavia, si trovano in [/ngfw]/var/sf/detection_engine/*/instance-N/connection/, che è un collegamento simbolico a /dev/shm/instance-N/connection. In questo caso, gli eventi risiedono nella memoria virtuale anziché in quella fisica.
admin@FTD4140:~$ ls -la /ngfw/var/sf/detection_engines/b0c4a5a4-de25-11ea-8ec3-4df4ea7207e3/instance-1/connection
lrwxrwxrwx 1 sfsnort sfsnort 30 Sep 9 19:03 /ngfw/var/sf/detection_engines/b0c4a5a4-de25-11ea-8ec3-4df4ea7207e3/instance-1/connection -> /dev/shm/instance-1/connection
Per verificare quale dispositivo è attualmente configurato per l'esecuzione del comando show log-events-to-ramdisk dal CLISH FTD. È possibile modificare questa impostazione anche eseguendo il comando configure log-events-to-ramdisk <enable/disable>:
> show log-events-to-ramdisk
Logging connection events to RAM Disk.
> configure log-events-to-ramdisk
Enable or Disable enable or disable (enable/disable)
Avviso: Quando si esegue il comando configure log-events-to-ramdisk disable, è necessario che due distribuzioni vengano completate sull'FTD in modo che il router non rimanga bloccato in uno stato D (sospensione ininterrompibile), causando un'interruzione del traffico.
Questo comportamento è documentato con l'ID bug Cisco CSCvz53372. Con la prima implementazione, la nuova valutazione della memoria snort viene ignorata, determinando lo stato D dell'snort. La soluzione è creare un'altra distribuzione con eventuali modifiche fittizie.
Quando si accede a ramdisk, lo svantaggio principale è che il rispettivo silo ha uno spazio allocato più piccolo e li scarica più spesso nelle stesse circostanze. L'output successivo è lo strumento di gestione dei dischi di un FPR 4140 con e senza gli eventi di registro su ramdisk abilitato per il confronto.
Log su Ramdisk abilitato:
> show disk-manager
Silo Used Minimum Maximum
Temporary Files 0 KB 903.803 MB 3.530 GB
Action Queue Results 0 KB 903.803 MB 3.530 GB
User Identity Events 0 KB 903.803 MB 3.530 GB
UI Caches 4 KB 2.648 GB 5.296 GB
Backups 0 KB 7.061 GB 17.652 GB
Updates 305.723 MB 10.591 GB 26.479 GB
Other Detection Engine 0 KB 5.296 GB 10.591 GB
Performance Statistics 19.616 MB 1.765 GB 21.183 GB
Other Events 0 KB 3.530 GB 7.061 GB
IP Reputation & URL Filtering 0 KB 4.413 GB 8.826 GB
arch_debug_file 0 KB 17.652 GB 105.914 GB
Archives & Cores & File Logs 0 KB 7.061 GB 35.305 GB
RNA Events 0 KB 7.061 GB 28.244 GB
File Capture 0 KB 17.652 GB 35.305 GB
Unified High Priority Events 0 KB 17.652 GB 30.892 GB
Connection Events 0 KB 451.698 MB 903.396 MB
IPS Events 0 KB 12.357 GB 26.479 GB
Log su Ramdisk disabilitato:
> show disk-manager
Silo Used Minimum Maximum
Temporary Files 0 KB 976.564 MB 3.815 GB
Action Queue Results 0 KB 976.564 MB 3.815 GB
User Identity Events 0 KB 976.564 MB 3.815 GB
UI Caches 4 KB 2.861 GB 5.722 GB
Backups 0 KB 7.629 GB 19.074 GB
Updates 305.723 MB 11.444 GB 28.610 GB
Other Detection Engine 0 KB 5.722 GB 11.444 GB
Performance Statistics 19.616 MB 1.907 GB 22.888 GB
Other Events 0 KB 3.815 GB 7.629 GB
IP Reputation & URL Filtering 0 KB 4.768 GB 9.537 GB
arch_debug_file 0 KB 19.074 GB 114.441 GB
Archives & Cores & File Logs 0 KB 7.629 GB 38.147 GB
Unified Low Priority Events 0 KB 9.537 GB 47.684 GB
RNA Events 0 KB 7.629 GB 30.518 GB
File Capture 0 KB 19.074 GB 38.147 GB
Unified High Priority Events 0 KB 19.074 GB 33.379 GB
IPS Events 0 KB 13.351 GB 28.610 GB
Le dimensioni ridotte del silo sono compensate dalla velocità più elevata necessaria per accedere agli eventi e trasmetterli in streaming al FMC. Si tratta di un'opzione migliore in condizioni adeguate, mentre si deve prendere in considerazione la restituzione.
Domande frequenti (FAQ)
Q: Gli avvisi di integrità relativi allo svuotamento degli eventi vengono generati solo dagli eventi di connessione?
R: No.
- Gli allarmi relativi allo svuotamento frequente possono essere generati da qualsiasi silo di gestione dei dischi.
- Gli avvisi di svuotamento degli eventi non elaborati possono essere generati da qualsiasi silo correlato agli eventi. I motivi più comuni sono gli eventi di connessione.
Q: È sempre consigliabile disabilitare un log su Ramdisk quando viene visualizzato un avviso di stato di salute Frequent Drain (Drenaggio frequente)?
R: No. Solo in scenari di registrazione eccessivi, ad eccezione di DOS/DDOS quando il Silo interessato è il Silo degli eventi di connessione, e solo nei casi in cui non è possibile ottimizzare ulteriormente le impostazioni di registrazione. Se DOS/DDOS provoca una registrazione eccessiva, la soluzione è implementare la protezione DOS/DDOS o eliminare le origini degli attacchi DOS/DDOS.
La funzione predefinita Log to Ramdisk riduce l'usura dell'SSD, pertanto si consiglia vivamente di utilizzarla.
Q: Che cosa costituisce un evento non elaborato?
R: Gli eventi non vengono contrassegnati singolarmente come non elaborati. Un file presenta eventi non elaborati quando:
- Il timestamp di creazione è maggiore del campo timestamp nel file del segnalibro corrispondente.
o
- Il timestamp di creazione è uguale al campo timestamp nel file del segnalibro corrispondente e la sua dimensione è superiore alla posizione nel campo Byte del file del segnalibro corrispondente.
Q: Come fa il CCP a conoscere il numero di byte arretrati per un determinato sensore?
R: Il sensore invia i metadati sul nome e le dimensioni del file unified_events, nonché le informazioni sui file dei segnalibri, che forniscono a FMC informazioni sufficienti per calcolare i byte arretrati come:
Dimensione file unified_events corrente: posizione nel campo Byte dal file dei segnalibri + Dimensione di tutti i file unified_events con un timestamp superiore a quello nel file dei segnalibri corrispondente.
Problemi noti
1. Aprire Bug Search Tool e usare la seguente query:
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
4.0 |
10-Jul-2026
|
Titolo aggiornato (troppo lungo), ortografia, grammatica, righe inserite in sezioni separate per la leggibilità, testo alternativo aggiornato e avvisi CCW. |
3.0 |
03-May-2024
|
Introduzione aggiornata, PII, Alt Text, Traduzione automatica, Destinazioni link e Formattazione. |
1.0 |
25-Sep-2020
|
Versione iniziale |
Feedback