Solucionar problemas de drenagem de alertas de saúde frequentes não processados do FMC
Contents
Introdução
Este documento descreve como solucionar problemas de drenagem de eventos não processados e drenagem frequente de alertas de integridade de eventos no Firepower Management Center.
Visão geral do problema
O Firepower Management Center (FMC) gera um destes alertas de integridade:
- Esgotamento frequente de eventos de baixa prioridade unificados
- Drenagem de eventos não processados de eventos de baixa prioridade unificados
Embora esses eventos sejam gerados e mostrados no FMC, eles se relacionam a um sensor de dispositivo gerenciado, seja um dispositivo Firepower Threat Defense (FTD) ou um dispositivo NGIPS (Next-Generation Intrusion Prevention System). Para o restante deste documento, o termo sensor refere-se a dispositivos FTD e NGIPS, a menos que especificado de outra forma.
Esta é a estrutura de alerta de integridade:
- Esgotamento frequente de <NOME DO SILO>
- Esgotamento de eventos não processados de <NOME DO SILO>
Neste exemplo, o NOME DO SILO é Eventos de Baixa Prioridade Unificados. Este é um dos silos do gerenciador de disco (consulte a seção Informações de fundo para obter uma explicação mais abrangente).
Além disso:
- Embora qualquer silo possa gerar tecnicamente um dreno frequente de alerta de saúde do <SILO NAME>, os mais comumente vistos são os relacionados a eventos e, entre eles, os eventos de baixa prioridade simplesmente porque esses são os tipos de eventos mais frequentemente gerados pelos sensores.
- Um dreno frequente do evento <NOME DO SILO> tem uma severidade de aviso caso seja um silo relacionado a eventos. Se tiverem sido processados (é dada uma explicação sobre o que constitui um evento não processado em seguida), estão na base de dados do CVP.
- Para um silo não relacionado a eventos, como um silo de backup, o alerta é crítico à medida que essas informações são perdidas.
- Somente silos de tipo de evento geram um Esgotamento de eventos não processados do alerta de integridade de <SILO NAME>. Este alerta sempre tem severidade crítica.
Os sintomas adicionais podem incluir:
- Perda de eventos
- Lentidão na interface do usuário do FMC
Cenários comuns de solução de problemas
Um dreno frequente do evento <NOME DO SILO> é causado por muita entrada no silo para seu tamanho. Nesse caso, o gerenciador de disco drena (limpa) esse arquivo pelo menos duas vezes no último intervalo de 5 minutos. Em um silo de tipo de evento, isso é normalmente causado pelo registro excessivo desse tipo de evento. Se um DRENO tiver eventos não processados de alerta de integridade do <NOME DO SILO>, isso também poderá ser causado por um gargalo no caminho de processamento de eventos.
No diagrama, há três gargalos potenciais:
- O processo EventHandler no FTD está com excesso de assinaturas (a leitura é mais lenta do que o que o Snort escreve).
- A interface Eventing tem excesso de assinaturas.
- O processo SFDataCorrelator no FMC está com excesso de assinaturas.
Para entender a arquitetura do processamento de eventos, consulte a seção Mergulho profundo.
Caso 1. Registro Excessivo
Como mencionado na seção anterior, uma das causas mais comuns de alertas de integridade desse tipo é a entrada excessiva.
A diferença entre Low Water Mark (LWM) e High Water Mark (HWM) (obtida do comando show disk-manager CLISH) mostra quanto espaço é necessário para ocupar esse silo. Para ir do LWM (drenado recentemente) para o valor HWM, se houver drenagens frequentes de eventos (com ou sem eventos não processados), você deve primeiro revisar a configuração de registro.
Para obter uma explicação detalhada do processo do Gerenciador de Discos, consulte a seção Mergulho profundo.
Seja um registro duplo ou apenas uma alta taxa de eventos no ecossistema geral do gerenciador-sensores, uma revisão das configurações de registro deve ser feita.
Ações recomendadas
Etapa 1. Verificar se há registro duplo
Cenários de registro duplo podem ser identificados se você revisar o correlator perfstats no FMC como mostrado nesta saída:
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
Neste exemplo, uma alta taxa de fluxos duplicados pode ser vista na saída.
Etapa 2. Revisar as definições de log do ACP
Você deve começar com uma revisão das configurações de log da Política de Controle de Acesso (ACP). Certifique-se de usar as práticas recomendadas descritas em Best Practices for Connection Logging.
É aconselhável revisar as configurações de registro em todas as situações, já que as recomendações listadas não cobrem apenas cenários de registro duplo.
Para verificar a taxa de eventos gerados no FTD, verifique este arquivo e concentre-se nas colunas 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}
Etapa 3. Verificar se há expectativa de registro excessivo em log
Você deve verificar se o registro excessivo tem uma causa esperada. Se o registro excessivo for causado por ataques DOS/DDoS, loop de roteamento ou um aplicativo/host específico que tenha um grande número de conexões; você deve verificar e mitigar/interromper conexões das fontes de conexão inesperadas/excessivas.
Etapa 4. Verificar o arquivo diskmanager.log corrompido
Normalmente, uma entrada pode ter 12 valores separados por vírgula. Para verificar se há linhas corrompidas que tenham um número diferente de campos:
admin@firepower:/ngfw/var/log$ sudo cat diskmanager.log | awk -F',' 'NF != 12 {print}'
admin@firepower:/ngfw/var/log$
Se houver uma linha corrompida com diferentes de 12 campos são mostrados.
Etapa 5. Atualizar o modelo
Atualize o dispositivo de hardware FTD para um modelo de desempenho mais alto (por exemplo, FPR2100 —> FPR4100), o silo de origem aumentaria.
Etapa 6. Considere se você pode desativar o registro no Ramdisk
No caso de um silo de eventos de baixa prioridade unificados, você pode desabilitar Log to Ramdisk para aumentar o tamanho do silo. Você pode revisar as desvantagens na seção Mergulho profundo.
Caso 2. Gargalo no canal de comunicação entre o sensor e o CVP
Outra causa comum para esse tipo de alerta são problemas de conectividade e/ou instabilidade no canal de comunicação (sftunnel) entre o sensor e o FMC. O problema de comunicação pode ocorrer devido a:
- sftunnel está com excesso de assinaturas.
- o sftunnel está inoperante ou é instável (flaps).
Para o problema de conectividade sftunnel, certifique-se de que o FMC e o sensor tenham acessibilidade entre suas interfaces de gerenciamento na porta TCP 8305.
No FTD, você pode procurar a string sftunneld no arquivo [/ngfw]/var/log/messages. Problemas de conectividade fazem com que mensagens como estas sejam geradas:
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
O excesso de assinaturas da interface de gestão dos CVP pode ser um pico no tráfego de gestão ou um excesso constante de assinaturas. Os dados históricos do Monitor de integridade são um bom indicador disso.
A primeira coisa a observar é que, na maioria dos casos, o FMC é implantado com uma única placa de rede para gerenciamento. Essa interface é usada para:
- Gerenciamento de FMC
- Gerenciamento de sensor FMC
- Coleta de eventos do FMC dos sensores
- Atualização de Feeds de Inteligência
- O download de atualizações de SRU, Software, VDB e GeoDB a partir do site de download de software
- A consulta para Reputações e Categorias de URL (se aplicável)
- A consulta para Disposições do arquivo (se aplicável)
Ações recomendadas
Você pode implantar uma segunda placa de rede no FMC para uma interface dedicada a eventos. As implementações dependem do caso de uso. As diretrizes gerais podem ser encontradas no Guia de hardware do FMC - Implantação em uma rede de gerenciamento.
Caso 3. Um Gargalo no Processo SFDataCorrelator
O último cenário abordado é quando ocorre um gargalo no lado do SFDataCorrelator (FMC).
A primeira etapa é examinar o arquivo diskmanager.log, pois há informações importantes a serem coletadas, como:
- A frequência do dreno.
- O número de arquivos com eventos não processados drenados.
-
A ocorrência do esvaziamento com Eventos Não Processados.
Para obter informações sobre o arquivo diskmanager.log e como interpretá-lo, consulte a seção Gerenciador de Discos. As informações do diskmanager.log podem ser usadas para ajudar a restringir as etapas subsequentes.
Além disso, você deve revisar as estatísticas de desempenho do correlator:
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
Estas estatísticas dizem respeito ao CVP e correspondem ao conjunto de todos os sensores por ele geridos. No caso de eventos de baixa prioridade do Unified, você procura principalmente por:
- Total de fluxos por segundo de qualquer tipo de evento para avaliar uma possível sobreassinatura do processo SFDataCorrelator.
- As duas linhas destacadas na saída anterior:
- rna flows/second - Indica a taxa de eventos de baixa prioridade processados pelo SFDataCorrelator.
- rna dup flows/second - Indica a taxa de eventos de baixa prioridade duplicados processados pelo SFDataCorrelator. Isso é gerado pelo registro em log duplo, conforme discutido no cenário anterior.
Com base na produção, pode concluir-se que:
- Não há registro duplicado conforme indicado pela linha rna dup flows/second.
- Na linha fluxos de rna/segundo, o valor Máximo é muito maior que o valor médio, pois houve um pico na taxa de eventos processados pelo processo SFDataCorrelator. Isso pode ser esperado se você revisar de manhã cedo quando o dia de trabalho dos usuários tiver acabado de começar; em geral, essa é uma bandeira vermelha e requer mais investigação.
Mais informações sobre o processo SFDataCorrelator podem ser encontradas na seção Processamento de Eventos.
Ações recomendadas
Primeiro, você deve determinar quando o pico ocorreu. Para fazer isso, você deve rever as estatísticas do correlator para cada intervalo de amostra de 5 minutos. As informações coletadas do diskmanager.log podem ajudá-lo a revisar os períodos de tempo críticos.
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
Use as informações na saída para:
- Determine a taxa normal/linha de base dos eventos.
- Determine o intervalo de 5 minutos quando o pico ocorreu.
No exemplo anterior, há um pico óbvio na taxa de eventos recebidos às 16:06:39 e além. Essas são médias de 5 minutos, portanto, o aumento pode ser mais abrupto do que o mostrado (intermitência), no entanto, diluído nesse intervalo de 5 minutos, se tiver começado no final dele.
Isto leva à conclusão de que este pico de eventos causou a drenagem de eventos não processados. Você pode ver a conexão de eventos da interface gráfica do usuário (GUI) do FMC com a janela de tempo apropriada para entender o tipo de conexões que atravessaram a caixa do FTD neste pico:
Aplique esta janela de tempo para visualizar os eventos de conexão filtrados (não se esqueça de levar em conta o fuso horário). Neste exemplo, o sensor usa o UTC e o FMC UTC+1. Use a Exibição de Tabela para exibir os eventos que dispararam a sobrecarga de eventos e tomar as medidas necessárias:
Com base nos carimbos de data/hora (hora do primeiro e do último pacote), pode-se ver que essas são conexões de curta duração. As colunas de Iniciador e Pacote de Respondente mostram que houve apenas um pacote trocado em cada direção. Isso confirma que as conexões tiveram vida curta e trocaram muito poucos dados.
Você pode ver todos os fluxos direcionados aos mesmos IPs e porta do respondente. Além disso, todos são relatados pelo mesmo sensor (que, juntamente com as informações de interface de entrada e saída, pode falar com o local e a direção dos fluxos). Ações adicionais:
- Verifique os Syslogs no ponto final de destino.
- Implemente a proteção DOS/DDOS ou tome outras medidas preventivas.
Note: O objetivo deste artigo é fornecer diretrizes para solucionar problemas relacionados a alertas de Drenagem de Eventos Não Processados. Este exemplo usou o hping3 para gerar uma inundação TCP SYN para o servidor de destino. Para obter diretrizes para fortalecer o dispositivo FTD, consulte o Guia de Fortalecimento da Defesa contra Ameaças do Cisco Firepower.
Itens a serem coletados antes de entrar em contato com o Cisco Technical Assistance Center (TAC)
É altamente recomendável coletar esses itens antes de entrar em contato com o TAC da Cisco:
- Captura(s) de tela dos alertas de integridade vistos.
- Arquivo de solução de problemas gerado do FMC.
- Solução de problemas de arquivo gerado a partir do sensor afetado.
- Data e Hora em que o problema foi iniciado pela primeira vez.
- Informações sobre quaisquer alterações recentes às políticas (se aplicável).
- A saída do comando stats_unified.pl como descrito na seção Processamento de eventos (com uma menção dos sensores afetados).
Análise detalhada
Esta seção aborda uma explicação detalhada dos vários componentes que podem participar dos tipos de alertas de integridade. Isso inclui:
- Processamento de eventos: Abrange os eventos de caminho que ocorrem nos dispositivos do sensor e no FMC. Isso é útil principalmente quando o alerta de integridade refere-se a um Silo de tipo de evento.
- Gerenciador de discos: Aborda o processo do gerenciador de disco, os silos e como eles são drenados.
- Monitor de integridade: Aborda como os módulos do Monitor de integridade são usados para gerar alertas de integridade.
- Registrar no Ramdisk: Abrange o registro no recurso ramdisk e seu impacto potencial nos alertas de integridade.
Para entender os alertas de integridade de Drenagem de Eventos e identificar pontos de falha em potencial, você deve examinar como esses componentes funcionam e interagem entre si.
Processamento de eventos
Embora os alertas de integridade do tipo Drenagem Frequente possam ser acionados por silos não relacionados a eventos, a grande maioria dos casos vistos pelo TAC da Cisco está relacionada a informações relacionadas a eventos de drenagem. Além disso, para entender o que constitui um dreno de eventos não processados, você deve examinar a arquitetura de processamento de eventos e seus componentes.
Quando um sensor Firepower recebe um pacote de uma nova conexão, o processo de snort gera um evento no formato unified2, que é um formato binário que permite uma leitura/gravação mais rápida, bem como eventos mais leves.
A saída mostra o comando FTD system support trace, onde você pode ver que uma nova conexão foi criada. As partes importantes são destacadas e explicadas:
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
Os arquivos de eventos unificados do Snort são gerados por instância no caminho [/ngfw]var/sf/detection_engine/*/instance-N/, onde:
- * é o UUID do Snort. Isso é exclusivo por dispositivo.
- N é o ID da instância do Snort que pode ser calculado como o ID da instância da saída anterior (o 0 realçado no exemplo) + 1
Pode haver 2 tipos de arquivos unified_events em qualquer pasta de instância do Snort:
- unified_events-1 (Que contém eventos de alta prioridade.)
- unified_events-2 (Que contém eventos de baixa prioridade.)
Um evento de alta prioridade corresponde a uma conexão potencialmente mal-intencionada.
Tipos de eventos e suas prioridades:
| Alta prioridade (1) |
Baixa prioridade (2) |
| Intrusão |
Conexão |
| Malware |
Descoberta |
| Inteligência de segurança |
Arquivo |
| Eventos de Conexão Associados |
Estatísticas |
A próxima saída mostra um evento que pertence à nova conexão rastreada no exemplo anterior. O formato é unified2 e é tirado da saída do respectivo log de eventos unificado localizado em [/ngfw]/var/sf/detection_engine/*/instance-1/ onde 1 é o ID da instância do snort em negrito na saída anterior +1. O nome do formato do log de eventos unificado usa a sintaxe unified_events-2.log.1599654750 onde 2 representa a prioridade dos eventos como mostrado na tabela e a última parte em negrito (1599654750) é o carimbo de data/hora (hora Unix) de quando o arquivo foi criado.
Tip: Você pode usar o comando data do Linux para converter a hora do Unix em uma data legível:
admin@FP1120-2:~$ sudo date -d@1599654750
Qua Set 9 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
Ao lado de cada arquivo unified_events, há um arquivo de marcadores que contém dois valores importantes:
- Carimbo de data/hora correspondente ao arquivo unified_events atual para essa instância e prioridade.
- Posição em bytes para o último evento lido no arquivo unified_event.
Os valores estão em ordem, separados por vírgula, como mostrado neste exemplo:
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
Isso permite que o processo do gerenciador de disco saiba quais eventos já foram processados (enviados ao FMC) e quais não foram.
Note: Quando o gerenciador de disco drena um silo de eventos, ele remove arquivos de eventos unificados.
Para obter mais informações sobre a drenagem de silos, consulte a seção Gerenciador de Discos.
Um arquivo unificado drenado é considerado como tendo eventos não processados quando um destes é verdadeiro:
- O carimbo de data/hora do indicador é inferior à hora de criação do arquivo.
- O carimbo de data/hora do indicador é o mesmo da hora de criação do arquivo e a posição em Bytes no arquivo é menor do que seu tamanho.
O processo EventHandler lê os eventos dos arquivos unificados e transmite-os para o FMC (como metadados) através do sftunnel, que é o processo responsável pela comunicação criptografada entre o sensor e o FMC. Esta é uma conexão baseada em TCP, de modo que a transmissão do evento é confirmada pelo FMC
Você pode ver estas mensagens no arquivo [/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
Esta saída fornece:
- O Snort abriu o arquivo unified_events para saída (para gravar nele).
- O Manipulador de eventos abriu o mesmo arquivo unified_events (para ler dele).
- sftunnel relatou o número de eventos processados desse arquivo unified_events.
O arquivo de marcador é atualizado de acordo. O sftunnel usa dois canais diferentes chamados Unified Events (UE) Canal 0 e 1 para eventos de alta e baixa prioridade, respectivamente.
Com o comando CLI sfunnel_status no FTD, você pode visualizar o número de eventos que foram transmitidos.
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
No FMC, os eventos são recebidos pelo processo SFDataCorrelator. O status dos eventos que foram processados de cada sensor pode ser visto executando-se o 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
Esse comando mostra o status da lista de pendências de eventos para determinado dispositivo por canal e o ID do canal usado é o mesmo que o sftunnel. O valor de Bytes Atrás pode ser calculado como a diferença entre a posição mostrada no arquivo de marcador de evento unificado e o tamanho do arquivo de evento unificado (mais qualquer arquivo subsequente com um carimbo de data/hora maior do que aquele no arquivo de marcador).
O processo SFDataCorrelator também armazena estatísticas de desempenho, que são salvas em /var/sf/rna/correlator-stats/. Um arquivo é criado por dia para armazenar as estatísticas de desempenho desse dia no formato CSV. O nome do arquivo usa o formato AAAA-MM-DD e o arquivo correspondente ao dia atual é chamado agora.
As estatísticas são coletadas a cada 5 minutos (há uma linha para cada intervalo de 5 minutos).
A saída desse arquivo pode ser lida executando-se o comando perfstats.
Note: Esse comando também é usado para ler arquivos de estatísticas de desempenho do snort, portanto, os sinalizadores apropriados devem ser usados.
-c: Instrui perfstats a entrada é um arquivo correlator-stats (sem esta bandeira, perfstats assume que a entrada é um arquivo de estatísticas de desempenho de snort).
q: O modo silencioso imprime apenas o resumo do arquivo.
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
Cada linha no resumo tem três valores nesta ordem: Média, Mínimo, Máximo.
Se você imprimir sem o sinalizador -q, também verá os valores do intervalo de 5 minutos (o resumo é mostrado no final).
Note: Cada CVP tem um caudal máximo descrito na sua ficha técnica. A tabela a seguir contém os valores por módulo obtidos da respectiva folha de dados.
| Modelo |
FMC 750 |
CVP 1000 |
FMC 1600 |
CVP 2000 |
FMC 2500 |
FMC 2600 |
FMC 4000 |
FMC 4500 |
FMC 4600 |
FMCv |
FMCv300 |
| Caudal máximo (qps) |
2000 |
5000 |
5000 |
12000 |
12000 |
12000 |
20000 |
20000 |
20000 |
Variável |
12000 |
Note: Estes valores são para a agregação de todos os tipos de eventos mostrados em negrito na saída de estatísticas do SFDataCorrelator.
Se você observar a saída e dimensionar o FMC que está preparado para o pior cenário (quando todos os valores máximos ocorrerem ao mesmo tempo), a taxa de eventos observada por esse FMC será 48,65 + 348,15 + 4,63 + 3,25 + 0,06 = 404,74 fps.
O valor total pode ser comparado com o valor da folha de dados do respectivo modelo.
O SFDataCorrelator também pode fazer um trabalho adicional sobre os eventos recebidos (como as Regras de Correlação), depois os armazena no banco de dados, que é consultado para preencher várias informações na GUI do FMC, como Painéis e Visualizações de Eventos.
Gerenciador de disco
O diagrama a seguir mostra os componentes lógicos dos processos do Health Monitor e do Disk Manager à medida que eles são interligados para a geração de alertas de integridade relacionados ao disco.
Em poucas palavras, o processo gerenciador de disco gerencia o uso do disco da caixa e tem seus arquivos de configuração na pasta [/ngfw]/etc/sf/. Há vários arquivos de configuração para o processo do gerenciador de discos que são usados em determinadas circunstâncias:
- diskmanager.conf: Arquivo de configuração padrão.
- diskmanager_2hd.conf: Usado quando a caixa tem dois discos rígidos instalados. O segundo disco rígido é aquele relacionado à expansão de malware que é usado para armazenar arquivos conforme definido na política de arquivos.
- ramdisk-diskmanager.conf: Usado quando o registro no Ramdisk é habilitado. Consulte a seção Log to Ramdisk.
Cada tipo de arquivo monitorado pelo gerenciador de disco que é atribuído a um Silo. Com base na quantidade de espaço em disco disponível no sistema, o gerenciador de disco calcula uma Marca d'água superior (HWM) e uma Marca d'água inferior (LWM) para cada silo. Quando o processo do gerenciador de disco esgota um silo, ele o faz até que o LWM seja alcançado. Como os eventos são drenados por arquivo, esse limite pode ser ultrapassado.
Para verificar o status dos silos em um dispositivo sensor, você pode executar este 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
O processo do gerenciador de discos é executado quando uma destas condições é atendida:
- O processo é iniciado (ou reiniciado)
- Um silo alcança o HWM
- Um silo é drenado manualmente
- Uma vez a cada hora
Cada vez que o processo do gerenciador de disco é executado, ele gera uma entrada para cada um dos diferentes silos em seu próprio arquivo de log, localizado em [/ngfw]/var/log/diskmanager.log e que tem dados em formato CSV.
Em seguida, é exibida uma linha de exemplo do arquivo diskmanager.log. Ele foi tirado de um sensor que disparou o Esvaziamento de eventos não processados do alerta de integridade de Eventos de Baixa Prioridade Unificados, bem como a divisão das respectivas colunas:
priority_2_events,1599668981,221,4587929508,1132501868,20972020,4596,1586044534,5710966962,1142193392,110,0
| Coluna | Valor |
| Rótulo do Silo |
priority_2_events |
| Tempo de drenagem (Época) |
1599668981 |
| Número de arquivos drenados | 221 |
| Bytes drenados | 4587929508 |
| Tamanho atual dos dados após o esvaziamento (bytes) | 1132501868 |
| Maior arquivo esvaziado (Bytes) | 20972020 |
| Menor arquivo esvaziado (bytes) | 4596 |
| Arquivo mais antigo esvaziado (tempo Época) | 1586044534 |
| Marca d'água alta (bytes) | 5710966962 |
| Marca d'água baixa (bytes) | 1142193392 |
| Número de arquivos com eventos não processados drenados | 110 |
| Sinalizador de estado do Diskmanager | 0 |
Essas informações são lidas pelo respectivo módulo do Health Monitor para disparar o alerta de integridade relacionado.
Drenar um silo manualmente
Em determinados cenários, você pode drenar um silo manualmente. Por exemplo, para liberar espaço em disco com um esvaziamento manual do silo, as remoções manuais de arquivos têm o benefício de permitir que o gerenciador de disco decida quais arquivos manter e quais excluir. O gerenciador de discos salva os arquivos mais recentes desse silo.
Qualquer silo pode ser drenado e isso opera conforme descrito (o gerenciador de disco drena os dados até que a quantidade de dados vá abaixo do limite de LWM). O comando system support silo-drain está disponível no modo FTD CLISH e fornece uma lista de silos disponíveis (nome + id numérico).
Este é um exemplo de drenagem manual do silo de Eventos de Baixa Prioridade Unificados:
> 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
Monitor de integridade
Estes são os pontos principais:
- Qualquer alerta de integridade visto no FMC no menu Health Monitor ou na guia Health no Message Center é gerado pelo processo Health Monitor.
- Esse processo monitora a integridade do sistema, tanto para o FMC quanto para os sensores gerenciados, e é composto por vários módulos diferentes.
- Os módulos de alerta de integridade são definidos na Política de Integridade, que pode ser anexada por dispositivo.
- Os alertas de integridade são gerados pelo módulo de utilização de disco que pode ser executado em cada um dos sensores gerenciados pelo FMC.
- Quando o processo Health Monitor no FMC é executado (uma vez a cada 5 minutos ou quando uma execução manual é acionada), o módulo Disk Usage verifica o arquivo diskmanager.log e, se as condições corretas forem atendidas, o alerta de integridade respectivo é acionado.
Para que um alerta de integridade de Drenagem de eventos Não Processados seja disparado, todas estas condições devem ser verdadeiras:
- O campo Bytes drenados é maior que 0 (isso indica que os dados desse silo foram drenados).
- O número de arquivos com eventos não processados drenados maior que 0 (isso indica que havia eventos não processados nos dados drenados).
- O tempo de drenagem está dentro da última hora.
Para que um alerta de integridade de Drenagem Frequente de eventos seja disparado, estas condições devem ser verdadeiras:
- As duas últimas entradas no arquivo diskmanager.log devem ser verdadeiras:
- O campo Bytes drenados é maior que 0 (isso indica que os dados desse silo foram drenados).
- Esteja a menos de 5 minutos de distância.
- O tempo de drenagem na última entrada para este silo está dentro da última 1 hora.
Os resultados obtidos a partir do módulo de utilização do disco (e os resultados obtidos por outros módulos) são enviados ao FMC através do sftunnel. Você pode ver os contadores dos eventos de integridade trocados em sftunnel executando o 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
Registrar no Ramdisk
Embora a maioria dos eventos seja armazenada em disco, o dispositivo é configurado por padrão para registrar no ramdisk para evitar danos graduais ao SSD que podem ser causados por gravações e exclusões constantes de eventos no disco.
Neste cenário, os eventos não são armazenados em [/ngfw]/var/sf/detection_engine/*/instance-N/, no entanto, eles estão localizados em [/ngfw]/var/sf/detection_engines/*/instance-N/connection/, que é um link simbólico para /dev/shm/instance-N/connection. Nesse caso, os eventos residem na memória virtual em vez de na física.
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
Para verificar qual dispositivo está configurado atualmente para executar o comando show log-events-to-ramdisk a partir do CLISH FTD. Você também pode alterar isso se executar o 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)
aviso: Quando o comando configure log-events-to-ramdisk disable é executado, há um requisito para que duas implantações sejam concluídas no FTD para que o snort não fique preso em um estado D (Suspensão Ininterrupta), o que causaria uma interrupção de tráfego.
Esse comportamento é documentado com o bug da Cisco ID CSCvz53372. Com a primeira implantação, a reavaliação do estágio de memória snort é ignorada, o que faz com que o snort entre em um estado D. A solução é criar outra implantação com qualquer alteração fictícia.
Quando você faz login no ramdisk, a desvantagem principal é que o respectivo silo tem um espaço menor alocado e os drena com mais frequência sob as mesmas circunstâncias. A próxima saída é o gerenciador de disco de um FPR 4140 com e sem os eventos de registro para o ramdisk habilitado para comparação.
Log no Ramdisk habilitado:
> 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 no Ramdisk desabilitado:
> 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
O tamanho menor do silo é compensado pela velocidade mais alta para acessar os eventos e transmiti-los ao FMC. Trata-se de uma melhor opção em condições adequadas, devendo ser considerada a desvantagem.
Perguntas frequentes
P: Os alertas de integridade Drenagem de eventos são gerados apenas por Eventos do Connection?
R: Não.
- Alertas de Drenagem Frequente podem ser gerados por qualquer Silo do gerenciador de disco.
- Alertas de drenagem de eventos não processados podem ser gerados por qualquer silo relacionado a eventos. Os eventos de conexão são os culpados mais comuns.
P: É sempre aconselhável desativar um registro no Ramdisk quando um alerta de integridade de drenagem frequente é visto?
R: Não. Somente em cenários de log excessivo, exceto para DOS/DDOS quando o silo afetado é o silo de eventos de conexão, e somente nos casos em que não é possível ajustar ainda mais as configurações de log. Se o DOS/DDOS causar excesso de registro, a solução será implementar a proteção DOS/DDOS ou eliminar a(s) fonte(s) dos ataques DOS/DDOS.
O recurso padrão Log to Ramdisk reduz o desgaste do SSD, portanto, é altamente recomendável usá-lo.
P: O que constitui um evento não processado?
R: Os eventos não são marcados individualmente como não processados. Um arquivo tem eventos não processados quando:
- O carimbo de data/hora de criação é superior ao campo de carimbo de data/hora no respectivo arquivo de marcador.
or
- O carimbo de data/hora de criação é igual ao campo de carimbo de data/hora no respectivo arquivo de marcador e seu tamanho é maior que a posição no campo Bytes no respectivo arquivo de marcador.
P: Como o FMC sabe o número de bytes de atraso de um sensor específico?
R: O sensor envia metadados sobre o nome e o tamanho do arquivo unified_events, bem como as informações sobre os arquivos de marcadores, que fornecem ao FMC informações suficientes para calcular os bytes como:
Tamanho atual do arquivo unified_events - Posição no campo Bytes do arquivo de marcadores + Tamanho de todos os arquivos unified_events com carimbo de data/hora maior que o carimbo de data/hora no respectivo arquivo de marcadores.
Problemas conhecidos
1. Abra a Bug Search Tool e use esta consulta:
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
4.0 |
10-Jul-2026
|
Título atualizado (muito longo), ortografia, gramática, linhas inseridas em seções separadas para legibilidade, texto alternativo atualizado e alertas do CCW. |
3.0 |
03-May-2024
|
Introdução Atualizada, PII, Texto Alt, Tradução Automática, Alvos de Link e Formatação. |
1.0 |
25-Sep-2020
|
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)