Solução de problemas de implantações de políticas de defesa contra ameaças do Firepower

Introduction

Com o Cisco Firepower Threat Defense (FTD), os recursos de firewall stateful tradicionais oferecidos pelos dispositivos de segurança adaptáveis (ASA) e recursos de firewall de próxima geração (acionados pelo Snort) agora são combinados em um único produto. Devido a essa alteração, a Infraestrutura de implantação de política no FTD agora lida com alterações de configuração para o código ASA (também conhecido como LINA) e Snort em um pacote. Este documento fornece uma visão geral de alto nível do processo de implantação de política no FTD e também técnicas básicas de solução de problemas. 

Prerequisites

A Cisco recomenda que você tenha conhecimento dos seguintes produtos:

• Firepower Management Center (FMC)
• Firepower Threat Defense (FTD)

aviso: The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Visão geral da implantação de políticas

O Cisco FTD utiliza as implantações de política para gerenciar e distribuir configurações para dispositivos registrados no próprio Firepower Management Center (FMC). Dentro da implantação, há uma série de etapas que são divididas em "fases".

As fases do CVP podem ser resumidas na lista seguinte.

Fase 0	Inicialização da implantação
Fase 1	Coleta de Objetos de Banco de Dados
Fase 2	Coleta de política e objeto
Fase 3	Geração de configuração de linha de comando NGFW
Fase 4	Geração de pacote de implantação de dispositivo
Fase 5	Envio e recebimento do pacote de implantação
Fase 6	Implantação pendente, ações de implantação e mensagens de êxito de implantação

Compreender as fases e saber onde a falha está localizada no processo podem ajudar na solução de problemas enfrentados por um sistema Firepower. Em algumas situações, pode ser um conflito devido a configurações anteriores ou causado pela falta de uma palavra-chave Advanced Flex Configuration que pode causar falhas sobre as quais o relatório do dispositivo não é explícito.

Exemplo de visão geral

Etapa 1. O usuário clica no botão "Implantação", especificando qual dispositivo o usuário gostaria de selecionar.

Etapa 2. Depois que a implantação de um dispositivo é confirmada, o FMC começa a coletar todas as configurações relevantes para o dispositivo. 

Etapa 3. Depois que as configurações são coletadas, o FMC cria o pacote e o envia para o sensor através de seu mecanismo de comunicação chamado SFTunnel.

Etapa 4. Em seguida, o FMC notifica o sensor para iniciar o processo de implantação usando a política fornecida, enquanto ouve as respostas individuais.

Etapa 5. O dispositivo gerenciado descompacta o arquivo e inicia a aplicação de configurações e pacotes individuais.

A. A primeira metade da implantação é a configuração do Snort, onde a configuração do Snort é testada localmente para garantir sua validade. Depois de comprovada a validade, a nova configuração é movida para o diretório de produção do Snort. Se a validação falhar, a implantação da política falhará nesta etapa.

B. A segunda metade do carregamento do pacote de implantação é para a configuração do LINA, na qual ele é aplicado diretamente ao processo LINA pelo processo ngfwManager. Se ocorrer uma falha, as alterações serão revertidas e uma falha na implantação da política ocorrerá.

Etapa 6. Se os pacotes Snort e LINA tiverem êxito, o dispositivo gerenciado sinalizará Snort para reiniciar ou recarregar a fim de carregar a nova configuração e salvar todas as configurações atuais.

Passo 7. Se todas as mensagens forem bem-sucedidas, o sensor enviará uma mensagem de êxito e aguardará que ela seja reconhecida pelo Management Center.

Etapa 8. Uma vez recebido, o FMC marca a tarefa como um sucesso e permite que o pacote de políticas seja concluído.

Troubleshooting

Problemas encontrados durante a implantação de política podem ser devidos, mas não limitados aos seguintes motivos:

1. Configuração incorreta
2. Comunicação entre o CVP e o DTF
3. Integridade do banco de dados e do sistema
4. Defeitos de software e avisos
5. Outras situações exclusivas

Alguns desses problemas podem ser facilmente corrigidos, enquanto outros podem exigir assistência do Cisco Technical Assistance Center (TAC).

O objetivo desta seção é fornecer ferramentas e técnicas de solução de problemas para isolar o problema ou determinar a causa raiz. 

Solução de problemas da interface gráfica do usuário (GUI) do FMC

A Cisco recomenda que cada sessão de solução de problemas para falhas de implantação comece no dispositivo FMC.

Na janela de notificação de falha, em todas as versões além da 6.2.3, há ferramentas adicionais de solução de problemas que podem ajudar com as falhas que você pode enfrentar. 

Utilizando As Transcrições De Implantação

Etapa 1. Puxe a lista Implantações na interface da Web do FMC.

Etapa 2. Enquanto a guia Implantações estiver selecionada, selecione a opção "Mostrar histórico".

Etapa 3. Na caixa Histórico de implantação, você pode ver todas as implantações anteriores do seu FMC. Selecione a implantação na qual deseja ver mais dados.

Etapa 4. Quando um elemento de implantação é selecionado, você é levado à seleção Detalhes da implantação, que mostra uma lista de todos os dispositivos dentro da transação. Essas entradas são divididas nas seguintes colunas: Número do dispositivo, Nome do dispositivo, Status e Transcrição.

Etapa 5. Você pode selecionar o dispositivo em questão e clicar na opção de transcrição para ver a transcrição de implantação individual que pode informá-lo de falhas, bem como das configurações que são colocadas nos dispositivos gerenciados.

Etapa 6. Essa transcrição pode designar certas condições de falha, bem como indicar um número muito importante para a próxima etapa: ID de transação.

Passo 7. Em uma implantação do Firepower, a ID da transação é o que pode ser usado para rastrear cada seção individual de uma implantação de política. Com isso, na linha de comando do dispositivo, você pode obter uma versão mais detalhada desses dados para solução de problemas e análise.

Tip: Caso você não consiga localizar a ID da transação ou se estiver em uma versão antes da impressão, o registro acima ainda poderá ser usado para localizar mensagens de falha individuais.

Solução de problemas usando registros FMC

Embora seja apropriado envolver o TAC da Cisco para analisar os registros, a análise dos registros pode ajudar no isolamento inicial do problema e acelerar a resolução. Há vários arquivos de log no FMC que revelam os detalhes sobre o processo de implantação da política. Os dois registros referenciados com mais frequência são policy_Deployment.log e usmsharedsvcs.log.

Todos os arquivos mencionados neste documento podem ser visualizados com vários comandos Linux como mais, menos e vi. No entanto, é muito importante garantir que somente as ações lidas sejam executadas nela. Todos os arquivos exigem acesso raiz para poder exibi-los.

/var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log

Esse registro marca claramente o início da tarefa de implantação de política no FMC e a conclusão de cada fase, o que ajuda a determinar a fase em que a implantação ocorreu uma falha, juntamente com o código de falha. O valor "TransactionID" incluído na parte JSON do registro pode ser usado para localizar entradas de log relacionadas a uma tentativa de implantação específica.

22-Nov-2019 01:28:52.844,[INFO],(DefenseCenterServiceImpl.java:1372)
com.cisco.nm.vms.api.dc.DefenseCenterServiceImpl, ajp-nio-127.0.0.1-9009-exec-4
** REST Request [ CSM ]
** ID : e1c84364-0966-42eb-9356-d2914be2b4a3
** URL: Broadcast message.send.deployment
{
  "body" : {
    "property" : "deployment:deployment_initiated_for_the_device",
    "argumentList" : [ {
      "key" : "PHASE",
      "value" : "Phase-0"
    } ]
  },
  "user" : "68d03c42-d9bd-11dc-89f2-b7961d42c462",
  "type" : "deployment",
  "status" : "running",
  "progress" : 5,
  "silent" : true,
  "restart" : true,
  "transactionId" : 12884916552,
  "devices" : [ "93a2089a-fa82-11e9-8219-e1abeec81dc9" ]
}

/var/log/sf/policy_deployment.log

Embora esse arquivo de log tenha existido durante as versões 6.x, a partir da versão 6.4, sua cobertura foi expandida. Agora, ele descreve as etapas detalhadas tomadas no FMC para criar os pacotes de implantação, portanto, é melhor usado para analisar falhas das fases 1 a 4. O início de cada fase é marcado por uma linha com "INFO Iniciando XYZ":

Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO starting populateGlobalSnapshot - sqlite = /var/cisco/umpd/8589938337/DC_policy_deployment.db, transaction = 8589938337, time = 1563470402, running as (memory = 56.35 MB) (Framework 3950<196 <- CSMTasks 223<10 <- SF::ActionQueue 2457)
Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO deployment threading: disabled (Framework 198 <- CSMTasks 223<10 <- SF::ActionQueue 2457)
Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO -> calling SF::UMPD::Plugins::Correlation::Manager::getPluginDependencies (Plugin 298<90 <- Framework 3579<3566<216 <- CSMTasks 223)
...

Solução de problemas de dispositivos gerenciados

Há fases e seções adicionais, dependendo do pacote de dispositivos, da configuração de alta disponibilidade e do resultado das fases anteriores para cada dispositivo gerenciado. Se um problema de implantação for isolado a uma falha no dispositivo gerenciado, a solução de problemas adicional pode ser executada no dispositivo usando dois registros no dispositivo: policy_Deployment.log e ngfwManager.log.

/ngfw/var/log/ngfwManager.log

Este arquivo de log fornece as etapas detalhadas do Config Communication Manager e do Config Dispatcher para se comunicar com o FMC, trabalhar com o pacote de implantação e orquestrar a validação e a aplicação das configurações Snort e LINA. Estes são alguns exemplos de ngfwManager.log que representam o início das fases principais:

FTD receives FMC's request for running configuration:

May 30 16:37:10 ccm[4293] Thread-10: INFO  com.cisco.ccm.ConfigCommunicationManager- Passing CD-Message-Request to Config Dispatcher...
May 30 16:37:10 ccm[4293] Thread-10: DEBUG com.cisco.ccm.ConfigCommunicationManager- <?xml version="1.0" encoding="UTF-8"?><cdMessagesList><timeStamp>1559234230012</timeStamp><cdMessage><name>LinaShowCommand</name><messageId>-753133537443151390</messageId><contentType>XML</contentType><msgContent><![CDATA[<?xml version="1.0" encoding="UTF-8"?><message><name>LinaShowCommand</name>...



FTD receives FMC's request to download the deployment package:

May 30 16:37:18 ccm[4293] Thread-9: INFO  com.cisco.ccm.ConfigCommunicationManager- Downloading database (transaction 8589938211, version 1559234236)
May 30 16:37:18 ccm[4293] Thread-9: DEBUG com.cisco.ccm.DownloadManager- handle record: 8589938211, status = PENDING
May 30 16:37:18 ccm[4293] Thread-9: DEBUG com.cisco.ccm.DownloadManager- begin downloading database



FTD begins the deployment of policy changes:

May 30 16:37:21 ccm[4293] Thread-9: INFO  com.cisco.ccm.ConfigCommunicationManager- Starting deployment
May 30 16:37:21 ccm[4293] Thread-11: INFO  com.cisco.ccm.ConfigCommunicationManager- Sending message: DEPLOYMENT_STATUS_CCM to Manager



FTD begins LINA deployment:

May 30 16:37:42 ccm[4293] Thread-19: DEBUG com.cisco.ngfw.configdispatcher.communicators.LinaCommunicatorImpl- Trying to send Start-Config-Sequencerequest to lina



FTD begins finalizing the deployment:

May 30 16:38:48 ccm[4293] Thread-19: DEBUG com.cisco.ngfw.configdispatcher.communicators.LinaCommunicatorImpl- Clustering Message sent out of ConfigDispatcher:
Name:Cluster-App-Conf-Finalize-Request

/ngfw/var/log/sf/policy_deployment.log

Este log contém os detalhes da política aplicada ao Snort. Embora o conteúdo do log seja mais avançado e exija análise pelo TAC, ainda é possível rastrear o processo usando algumas entradas principais:

Config Dispatcher begins extracting the packaged policies for validation:

Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO  -> calling SF::UMPD::Plugins::NGFWPolicy::Device::exportDeviceSnapshotToSandbox  (Plugin 230 <- Framework 611 <- Transaction 1085)
Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO  found NGFWPolicy =>   (NGFWPolicy::Util 32 <- NGFWPolicy::Device 43 <- Plugin 235)
...
Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO export FTD platform settings... (PlatformSettings::FTD::Device 29 <- Plugin 235<339 <- PlatformSettings::Device 13)



Config validation begins:

Jul 18 17:21:37 firepower policy_apply.pl[25122]: INFO  starting validateExportedFiles - sqlite = /var/cisco/deploy/sandbox/policy_deployment.db, sandbox = /var/cisco/deploy/sandbox/exported-files (memory = 229.99 MB)  (Framework 3950<687 <- Transaction 1101 <- main 194)



Validation has completed successfully:

Jul 18 17:21:49 firepower policy_apply.pl[25122]: INFO validateExportedFiles - sqlite = /var/cisco/deploy/sandbox/policy_deployment.db, sandbox = /var/cisco/deploy/sandbox/exported-files took 12 (memory = 238.50 MB, change = 8.51 MB) (Framework 3976<724 <- Transaction 1101 <- main 194) 



Config Dispatcher begins moving the validated configuration to the Snort directories in production:

Jul 18 17:21:54 firepower policy_apply.pl[26571]: INFO  -> calling SF::UMPD::Plugins::NGFWPolicy::Device::publishExportedFiles  (Plugin 230 <- Framework 822 <- Transaction 1662)



Snort processes will reload to apply the new configurations:

Jul 18 17:22:02 firepower policy_apply.pl[26571]: INFO  Reconfiguring DE a3bcd340-992f-11e9-a1f1-ac829f31a4f9...  (Snort::SnortNotifications 292<154 <- Snort::Device 343 <- Plugin 235)
Jul 18 17:22:02 firepower policy_apply.pl[26571]: INFO  sending SnortReload to a3bcd340-992f-11e9-a1f1-ac829f31a4f9  (Snort::SnortNotifications 298<154 <- Snort::Device 343 <- Plugin 235)



Snort reload has completed successfully:

Jul 18 17:22:14 firepower policy_apply.pl[26571]: INFO notifyProcesses - sandbox = /var/cisco/deploy/sandbox/exported-files took 16 (memory = 169.52 MB, change = 16.95 MB) (Framework 3976<964 <- Transaction 1680 <- main 200)



After LINA config apply finishes, Snort deployment is finalized:

Jul 18 17:23:32 firepower policy_apply.pl[26913]: INFO  starting finalizeDeviceDeployment - sandbox = /var/cisco/deploy/sandbox (memory = 101.14 MB)  (Framework 3950<980 <- Transaction 1740 <- main 206)

Exemplo

Etapa 1. Uma implantação falha

Etapa 2. Obtenha a ID da transação e da transcrição da implantação.

Etapa 3. Faça SSH no seu Centro de Gerenciamento e utilize o utilitário Linux menos para ler o arquivo da seguinte forma no seu FMC:

Exemplo:"sudo less /var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log" (A senha sudo é a senha do usuário para ssh)

Etapa 4. Quando estiver em menos, use a barra e insira a ID da mensagem para pesquisar os logs relacionados à ID da transação de implantação. 

Exemplo:"/60129547881" {Em menos, use n para navegar para o próximo resultado}

Exemplo de mensagem de execução:

Exemplo de mensagem de falha:

5) Compare a falha correta com a tabela anexada de Mensagens de falha comuns.

 Ou seja, failed_to_retrieve_running_configuration ocorre durante falhas de comunicação entre os dois dispositivos. 

Mensagens de falha comuns

Abaixo estão as mensagens de falha comuns que podem ser vistas no front-end da tarefa do Management Center, bem como o código de erro que pode ser visto no back-end. Essas mensagens podem ser analisadas e comparadas com as razões comuns para possíveis resoluções.

Caso isso não seja observado, ou não resolva sua situação que está ocorrendo, entre em contato com o TAC para obter assistência. 

Entre em contato com o TAC para obter assistência

Caso as informações acima não permitam que uma implantação de política continue ou se o problema parecer não estar relacionado a um comportamento pré-existente documentado, use as etapas fornecidas no próximo link para gerar um arquivo de solução de problemas e entre em contato com o TAC para análise e criação de bugs.

https://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html