Etapa 1: Verifique se as políticas corretas são distribuídas no Sensor e a integridade do Sensor é boa:

1. Clique no botão Policy e, em seguida, clique em Gerenciador de políticas.
2. Certifique-se de que tenha Política do IPS na frente da Nome do dispositivo pilha.

Etapa 2: Identifique um host por trás da interface do IPS que está tendo o problema. Execute uma geração de ataque de teste conforme documentado na seção "instalação dos sensores fisicamente" do guia de produto do NSP.

INDICADO McAfee documentação do produto Enterprise está disponível em: https://docs.mcafee.com.

• Se o ataque de teste for detectado, mas você perceber que menos ataques foram detectados nos registros de ataque:
  Um ataque de teste detectado confirma que o tráfego está fluindo pelas interfaces selecionadas e que Sensor detecção de assinatura está funcionando.
  
  1. Gere um relatório de próxima geração para os 10 principais ataques:
     1. Selecione o Analisa e, em seguida, clique em Relatório de eventos, Relatórios de próxima geração, Padrão, 10 principais ataques.
     2. Abrir o Política de IPS aplicada.
     3. Exiba a coluna de revisão ativa: clique no botão Policy e, em seguida, clique em Tipos de políticas, IPS, Revisão ativa.
     4. Compare e rastreie as alterações de revisão realizadas na política do IPS: revise os 10 principais relatórios de ataques gerados acima e verifique se algum dos 10 principais ataques está desativado na política do IPS.
     5. Revise a origem e o destino no relatório gerado anteriormente:
        1. Verifique se esses endereços IP principais que geram ataques são observados nos registros de ataque: clique no botão Analisa e, em seguida, selecione a guia Vulnerável acessar.
        2. Procure esses endereços IP na política firewall e verifique se algum dos endereços IP mais importantes que geram ataques foram bloqueados na política firewall: clique no botão Policy na Tipos de políticas, Políticas de Firewall.
        3. Verifique o relatório de História de quarentena padrão e descubra se qualquer um dos endereços IP que geram os principais ataques foram colocados em quarentena em um ponto no tempo: clique em Analisa, Relatório de eventos, Relatórios de próxima geração.
     6. Descubra se a gravidade de ataque de qualquer um dos 10 principais ataques foi modificada no atualmente instalado Sigset:
        1. Exibir a versão do Sigset instalada emitindo 'status' na CLI do Sensor.
        2. Abrir KB55446-atualizações de Network Security Signature Set e revisar o Sigset modificado no número de Sigset instalado versus os 10 principais ataques no relatório gerado acima.
        3. Analisá Ataques modificados em Ataques removidos nas notas de versão do Sigset instalado. Identificar se alguma das gravidades de assinatura da rede foi alterada. Ou, se alguma assinatura tiver sido removida do Sigset instalado. Essas alterações podem reduzir o número de alertas na rede.
           
        INDICADO Se qualquer gravidade de ataque for modificada de alto ou médio para informativo, esse ataque será automaticamente removido da política do IPS. Os alertas para este ataque não geraram a instalação do post Sigset.
        
        
• Se o ataque de teste não for detectado nos registros de ataque:
  1. Verifique se Sensor integridade é boa e o tráfego de teste está fluindo pelas interfaces do Sensor.
  2. Abra uma sessão de CLI do Sensor.
  3. Ferência Mostrar todos os EventLogs e pressione Enter.
  4. Procure eventos anormais, como Falha no processo Quanto Link para baixo.
  5. Execute o status na CLI do Sensor cinco vezes.
  6. Verifique se Alerta enviado em Registros enviados os contadores estão sendo incrementados. Se estiverem sendo incrementados, o Sensor estiver enviando alertas para o Gerenciador:
     
     [Manager comunicações]
     Confiança estabelecida: Sim (RSA 2048-bit com suporte a SHA2)
     Canal de alerta: para cima
     Canal de log: para cima
     Canal de autenticação: para cima
     Último erro: nenhum
     Alertas enviados: 360
     Registros enviados: 195
     
  7. Clique no botão Policy na Autoriza, Confirmação automática.
  8. Validar as configurações de reconhecimento automático; Eles devem ficar em branco.
  9. Efetue logon no banco de dados e valide se os registros estão sendo inseridos no banco de dados do NSM:
     1. Clique Começo, Executa, digite cmde, em seguida, pressione Enter.
     2. Altere o diretório para o diretório \bin:
     • Para NSM 9.1.7.75 e versões anteriores:
       Ferência cd <$install_directory>\McAfee\Network Security Manager\MySQL\bin\ e pressione Enter.
     • Para NSM 9.1.7.77 e versões posteriores, incluindo 10.x:
       Ferência cd <$install_directory>\McAfee\Network Security Manager\MariaDB\bin e pressione Enter.
       
  10. Digite o comando a seguir e pressione ENTER:
      
      mysql -u -p
      
      Por exemplo:
      mysql -uroot -proot123 lf
      
  11. Execute as consultas a seguir e exiba a saída:
      
      select min(creationTime), max(creationTime) from iv_alert;
      select min(creationTime), max(creationTime) from iv_packetlog;
      
  12. Se o máx. (CreationTime) a coluna reflete os dados e carimbos de data e hora mais recentes, mas você não vê nenhum alerta nos registros de ataque (Clique Guia análise, registro de ataques) Execute uma importação do Solr usando:
      KB86158-como importar dados do MySQL para o banco dados do Network Security Manager Solr.
  13. Se a saída do comando for nula e você não vir um carimbo de data/hora na saída do comando:
      1. Criar uma Solicitação de serviço e inclua este número de artigo no campo Descrição do problema.
      2. Colete os logs do coletor de informações e as saídas de comando acima.