Fase 2 da solução de problemas de caminho de dados do Firepower: Camada DAQ

Introduction

Este artigo faz parte de uma série de artigos que explicam como solucionar problemas sistematicamente no caminho de dados em sistemas Firepower para determinar se os componentes do Firepower podem estar afetando o tráfego. Consulte o artigo Visão geral para obter informações sobre a arquitetura das plataformas Firepower e links para outros artigos de solução de problemas de caminho de dados.

Neste artigo, examinaremos o segundo estágio da solução de problemas do caminho de dados do Firepower: a Camada DAQ (Aquisição de Dados).

Guia da plataforma

A tabela a seguir descreve as plataformas abrangidas por este artigo.

Nome do código da plataforma	Descrição	Aplicável Hardware Plataformas	Notas
SFR	Módulo ASA com Firepower Services (SFR) instalado.	ASA-5500-X Series	N/A
FTD (todos)	Aplica-se a todas as plataformas Firepower Threat Defense (FTD)	ASA-5500-X Series, plataformas NGFW virtuais, FPR-2100, FPR-9300, FPR-4100	N/A
FTD (não SSP e FPR-2100)	Imagem FTD instalada em um ASA ou uma plataforma virtual	ASA-5500-X Series, plataformas NGFW virtuais, FPR-2100	N/A
FTD (SSP)	FTD instalado como um dispositivo lógico em um chassi baseado no Firepower eXtensible Operative System (FXOS)	FPR-9300, FPR-4100	A série 2100 não usa o FXOS Chassis Manager

Troubleshooting da Fase DAQ do Firepower

A camada de DAQ (aquisição de dados) é um componente do Firepower que converte pacotes em uma forma que o snort pode entender. Ele inicialmente trata o pacote quando é enviado para snort. Portanto, se os pacotes estão entrando, mas não estão entrando no Firepower appliance ou se a solução de problemas de entrada de pacotes não produziu resultados úteis, a solução de problemas de DAQ pode ser útil.

Captura de tráfego na camada DAQ

Para obter um prompt para executar a captura, primeiro é necessário conectar-se usando SSH ao endereço IP do SFR ou FTD.

Note: Nos dispositivos FPR-9300 e 4100, insira connect ftd primeiro para terminar no segundo > prompt. Você também pode usar SSH no IP do FXOS Chassis Manager e, em seguida, inserir o console do módulo de conexão 1, seguido de conectar ftd.

Este artigo explica como coletar capturas de pacotes no nível de DAQ do Firepower.

Observe como a sintaxe não é a mesma do comando capture usado no ASA, assim como o lado LINA da plataforma FTD. Aqui está um exemplo de uma execução de captura de pacote DAQ de um dispositivo FTD:

Como visto na captura de tela acima, uma captura no formato PCAP chamada ct.pcap foi gravada no diretório /ngfw/var/common (/var/common na plataforma SFR). Esses arquivos de captura podem ser copiados do dispositivo Firepower do prompt > usando as instruções no artigo mencionado acima.

Como alternativa, no Firepower Management Center (FMC) no Firepower versão 6.2.0 e posterior, navegue para Dispositivos > Gerenciamento de dispositivos. Em seguida, clique no botão ao lado do dispositivo em questão, seguido por Advanced Troubleshooting > File Download.

Você pode inserir o nome do arquivo de captura e clicar em Download.

Como ignorar o Firepower

Se o Firepower estiver vendo o tráfego, mas foi determinado que os pacotes não estão egressando o dispositivo ou que há outro problema com o tráfego, a próxima etapa seria ignorar a fase de inspeção do Firepower para confirmar que um dos componentes do Firepower está descartando o tráfego. Veja a seguir uma análise da maneira mais rápida de fazer com que o tráfego ignore o Firepower em várias plataformas.

SFR - Coloque o módulo Firepower no modo somente de monitor

No ASA que hospeda o SFR, você pode colocar o módulo SFR no modo somente de monitor através da Interface de Linha de Comando (CLI - Command Line Interface) do ASA ou do Cisco Adaptive Security Device Manager (ASDM - Gerenciador de Dispositivos de Segurança Adaptiva). Isso faz com que apenas uma cópia dos pacotes ao vivo seja enviada ao módulo SFR. 

Para colocar o módulo SFR no modo somente de monitoramento através da CLI do ASA, o mapa de classe e o mapa de política usados para redirecionamento do SFR devem primeiro ser determinados executando o comando show service-policy sfr. 

# show service-policy sfr

Global policy:
  Service-policy: global_policy
    Class-map: sfr
      SFR: card status Up, mode fail-open
        packet input 10000, packet output 9900, drop 100, reset-drop 0

A saída mostra que o mapa de política global_policy está aplicando a ação fail-open do sfr no mapa de classe "sfr".

Note: "fail-close" é também um modo no qual o SFR pode ser executado, mas não é tão usado, pois bloqueia todo o tráfego se o módulo SFR estiver inativo ou sem resposta.

Para colocar o módulo SFR no modo somente de monitor, você pode emitir estes comandos para negar a configuração atual do SFR e inserir a configuração somente de monitor:

# configure terminal
(config)# policy-map global_policy
(config-pmap)# class sfr
(config-pmap-c)# no sfr fail-open
(config-pmap-c)# sfr fail-open monitor-only

INFO: The monitor-only mode prevents SFR from denying or altering traffic.

(config-pmap-c)# write memory
Building configuration...

Depois que o módulo tiver sido colocado no modo somente monitor, ele poderá ser verificado na saída show service-policy sfr.

# sh service-policy sfr

Global policy:
  Service-policy: global_policy
    Class-map: sfr
      SFR: card status Up, mode fail-open monitor-only
        packet input 0, packet output 100, drop 0, reset-drop 0

Note: Para colocar o módulo SFR de volta no modo inline, emita o comando no sfr fail-open monitor-only no prompt (config-pmap-c)# mostrado acima, seguido pelo sfr {fail-open comando | fail-close} originalmente presente.

Como alternativa, você pode colocar o módulo somente no monitor via ASDM navegando para Configuração > Firewall > Regras de Política de Serviço. Em seguida, clique na regra em questão. Em seguida, acesse a página Ações da regra e clique na guia Inspeção do FirePOWER ASA. Assim que estiver lá, o monitor apenas poderá ser selecionado.

Se o problema de tráfego continuar mesmo depois que o módulo SFR tiver sido confirmado para estar no modo somente monitor, o módulo Firepower não está causando o problema. O Packet Tracer pode então ser executado para diagnosticar mais os problemas no nível do ASA.

Se o problema não continuar, a próxima etapa seria solucionar os problemas dos componentes do software Firepower.

FTD (todos) - Coloque Conjuntos em linha no modo TAP

Se o tráfego estiver passando por pares de interface configurados em conjuntos em linha, o conjunto em linha poderá ser colocado no modo TAP. Isso faz com que o Firepower não tome uma ação no pacote ao vivo. Ele não se aplica ao modo de roteador ou transparente sem conjuntos de linha, pois o dispositivo deve modificar os pacotes antes de enviá-los para o próximo salto e não pode ser colocado em um modo de desvio sem descartar o tráfego. Para o modo roteado e transparente sem conjuntos inline, continue com a etapa packet tracer.

Para configurar o modo TAP na Interface de Usuário (UI) da FMC, navegue até Dispositivos > Gerenciamento de Dispositivos e edite o dispositivo em questão. Na guia Inline Sets, marque a opção para TAP Mode.

Se o modo TAP resolver o problema, a próxima etapa seria solucionar os componentes do software Firepower.

Se o modo TAP não resolver o problema, o problema estará fora do software Firepower. O Packet Tracer pode ser usado para diagnosticar o problema.

Usando o Packet Tracer para Solucionar Problemas de Tráfego Simulado

O Packet Tracer é um utilitário que pode ajudar a identificar a localização de um descarte de pacote. É um simulador, portanto, executa um rastreamento de um pacote artificial.

SFR - Execute o Packet Tracer na CLI do ASA

Aqui está um exemplo de como executar o packet-tracer no ASA CLI para tráfego SSH. Para obter informações mais detalhadas sobre a sintaxe do comando packet tracer, consulte esta seção no guia de referência de comando da série ASA.

No exemplo acima, vemos o módulo ASA e o módulo SFR permitindo os pacotes, bem como informações úteis sobre como o ASA lidaria com o fluxo do pacote.

FTD (todos) - Execute o packet tracer na CLI do FTD

Em todas as plataformas FTD, o comando packet tracer pode ser executado a partir da CLI do FTD. 

Neste exemplo, o packet tracer mostra o motivo da queda. Nesse caso, é a lista negra de IP dentro do recurso Security Intelligence no Firepower que bloqueia o pacote. A próxima etapa seria solucionar os problemas do componente de software Firepower individual que está causando a queda.

Usando Captura com Rastreamento para Solucionar Problemas de Tráfego ao Vivo

O tráfego ao vivo também pode ser rastreado através do recurso de captura com rastreamento, que está disponível em todas as plataformas via CLI. Abaixo está um exemplo de execução de uma captura com rastreamento em relação ao tráfego SSH.

Neste exemplo, o quarto pacote na captura foi rastreado, pois esse é o primeiro pacote com dados de aplicativo definidos. Como mostrado, o pacote acaba sendo whitelistelado pelo snort, o que significa que nenhuma inspeção de snort adicional é necessária para o fluxo, e é permitida em geral.

Para obter mais informações sobre a captura com sintaxe de rastreamento, consulte esta seção no Guia de referência de comando da série ASA.

FTD (todos) - Execução da captura com rastreamento na GUI do FMC

Nas plataformas FTD, a captura com rastreamento pode ser executada na IU do FMC. Para acessar o utilitário, navegue até Dispositivos > Gerenciamento de dispositivos.

Em seguida, clique no botão ao lado do dispositivo em questão, seguido por Advanced Troubleshooting > Capture w/Trace.

Abaixo está um exemplo de como executar uma captura com rastreamento via GUI.

Se a captura com rastreamento mostrar a causa da queda do pacote, a próxima etapa seria solucionar os problemas dos componentes individuais do software.

Se ele não mostrar claramente a causa do problema, a próxima etapa será o caminho rápido do tráfego.

Criação de uma regra de caminho rápido de pré-filtro no FTD

Em todas as plataformas FTD, há uma política de pré-filtro, que pode ser usada para desviar o tráfego da inspeção do Firepower (snort). 

No FMC, isso é encontrado em Políticas > Controle de acesso > Prefiltro. Não é possível editar a política de pré-filtro predefinida, pelo que será necessário criar uma política personalizada.

Depois, a política de pré-filtro recém-criada precisa ser associada à política de controle de acesso. Isso é configurado na guia Avançado da Política de controle de acesso na seção Configurações de política de pré-filtro.

Abaixo está um exemplo de como criar uma regra de Fastpath em uma política de pré-filtro e verificar a contagem de ocorrências.

Clique aqui para obter mais detalhes sobre a operação e a configuração das Políticas de pré-filtro.

Se a adição de uma política de pré-filtro resolver o problema de tráfego, a regra pode ser mantida no lugar, se desejado. No entanto, não é efetuada qualquer nova inspeção a esse fluxo. A solução de problemas adicional do software Firepower precisará ser executada.

Se a adição da política de pré-filtro não resolver o problema, o pacote com etapa de rastreamento pode ser executado novamente para rastrear o novo caminho do pacote.

Dados a fornecer ao TAC

Dados	Instruções
Saídas de comando	Consulte este artigo para obter instruções
Capturas de pacotes	Para ASA/LINA: https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/118097-configure-asa-00.html Para Firepower: http://www.cisco.com/c/en/us/support/docs/security/sourcefire-firepower-8000-series-appliances/117778-technote-sourcefire-00.html
Saída 'show tech' do ASA	Faça login no ASA CLI e salve a sessão do terminal em um log. Digite o comando show teche forneça o arquivo de saída da sessão de terminal ao TAC. Esse arquivo pode ser salvo em disco ou em um sistema de armazenamento externo com esse comando. show tech | redirecionar disco0:/show_tech.log
Solucionar problemas do dispositivo Firepower que inspeciona o tráfego	http://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html

Próxima etapa

Se for determinado que um componente de software Firepower é a causa do problema, a próxima etapa seria excluir sistematicamente cada componente, começando pela inteligência de segurança.

Clique aqui para continuar com o próximo guia.