Solucionar problemas de implantações da política do Firepower Threat Defense

Introdução

Este documento descreve 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. 

Informações de Apoio

Com Cisco Firepower Threat Defense (FTD), recursos de firewall com informações de estado tradicionais oferecidos pela Adaptive Security Appliances (ASA) e Next-Gen recursos de firewall (com tecnologia Snort) são agora combinados em um único produto.

Devido a essa alteração, Policy Deployment Infrastructure 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. 

Pré-requisitos

A Cisco recomenda o conhecimento destes produtos:

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

Componentes Utilizados

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Visão geral da implantação da política

O Cisco FTD utiliza Policy Deployments para gerenciar e distribuir configurações para dispositivos registrados no Firepower Management Center (CVP).

Dentro da implantação, há uma série de etapas divididas em "Fases".

As fases do CVP podem ser resumidas na presente lista.

Fase 0	Inicialização da Implantação
Fase 1	Coleção de Objetos de Banco de Dados
Fase 2	Política e coleção de objetos
Fase 3	Geração de configuração de linha de comando do NGFW
Fase 4	Geração de Pacote de Implantação de Dispositivo
Fase 5	Enviar e Receber o Pacote de Implantação
Fase 6	Implantação pendente, ações de implantação e mensagens de êxito da implantação

O conhecimento das fases e do local das falhas no processo pode ajudar a solucionar as falhas que um Firepower faces de sistema.

Em algumas situações, pode ser um conflito devido a configurações anteriores ou causado por um Advanced Flex Configuration que não possui uma palavra-chave que possa causar falhas que o relatório do dispositivo não aborda.

Visão geral do exemplo

Etapa 1. Clique em Deployment, que especifica o dispositivo a ser selecionado.

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

Etapa 3. Quando as configurações são coletadas, o FMC cria o pacote e o envia ao sensor pelo seu mecanismo de comunicação chamado SFTunnel.

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

Etapa 5. O dispositivo gerenciado descompacta o arquivo e começa a aplicar as configurações e os pacotes individuais.

A. A primeira metade da implantação é a Snort configuração em que o Snort a configuração é testada localmente para garantir sua validade.

Quando comprovada como válida, a nova configuração é movida para o diretório de produção para Snort. Se a validação falhar, a implantação da política falhará nesta etapa.

B. A segunda metade da carga do pacote de implantação é para a configuração LINA, onde é aplicada diretamente ao processo LINA pelo processo ngfwManager.

Se ocorrer uma falha, as alterações serão revertidas e ocorrerá uma falha na implantação da política.

Etapa 6. Se ambos Snort e os pacotes LINA são bem-sucedidos, os sinais de dispositivos gerenciados Snort para reiniciar ou recarregar para 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 esperará que ela seja confirmada 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 Policy Deployment pode ser devido a, mas não limitado a:

1. Configuração incorreta
2. Comunicação entre o CVP e o DTF
3. Integridade do banco de dados e do sistema
4. Avisos e defeitos de software
5. Outras situações únicas

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

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

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 seja iniciada no dispositivo FMC.

Na janela de notificação de falha, em todas as versões além de 6.2.3, há ferramentas adicionais que podem ajudar com outras possíveis falhas. 

Utilizar As Transcrições De Implantação

Etapa 1. Puxe para cima o Deployments na interface do usuário da Web do FMC.

Etapa 2. Embora a Deployments estiver selecionada, clique em Show History.

Etapa 3. Dentro do Deployment History você pode ver todas as implantações anteriores do FMC. Selecione a implantação na qual você deseja ver mais dados.

Etapa 4. Depois que um elemento de implantação é selecionado, o Deployment Details exibe uma lista de todos os dispositivos dentro do Transaction. Estas entradas são divididas nestas colunas: Device Number, Device Name, Status,e Transcript.

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

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

Passo 7. Em um Firepower Deployment,o Transaction ID é 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 correção e análise.

Dica: Caso você não consiga localizar o ID da transação ou caso esteja em uma versão anterior à impressão, esse log ainda poderá ser útil para localizar mensagens de falha individuais.

Solucionar problemas com registros do FMC

Embora seja apropriado envolver o TAC da Cisco para analisar os logs, uma pesquisa nos logs 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 mais comumente consultados são policy_deployment.log e usmsharedsvcs.log.

Todos os arquivos mencionados neste documento podem ser visualizados com vários comandos Linux, como more, less e vi. No entanto, é muito importante garantir que apenas read são executadas. Todos os arquivos requerem acesso raiz para serem visualizados.

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

Esse registro marca claramente o início da tarefa de implantação da 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 transactionID o valor incluído na parte JSON do log pode ser usado para localizar entradas de log relacionadas a uma tentativa de disponibilizaçã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 em todas as versões 6.x, que começam na 6.4, sua cobertura foi expandida.

Agora, ele descreve as etapas detalhadas executadas no FMC para criar os pacotes de implantação, portanto, é mais adequado para o para analisar falhas das Fases 1 a 4.

O início de cada fase é marcado por uma linha com "INFO start.. ":

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 dispositivo gerenciado

Há fases e seções adicionais que dependem do pacote do dispositivo, 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, uma solução de problemas adicional poderá ser executada no dispositivo com dois logs no dispositivo: policy_deployment.log e ngfwManager.log.

/ngfw/var/log/ngfwManager.log

Esse arquivo de log fornece as etapas detalhadas executadas pelo Config Communication Manager e 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

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

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 o Deploy Transcript e Transaction ID.

Etapa 3. SSH em seu Management Center e utilizar o utilitário Linux less para ler o arquivo conforme mostrado no FMC:

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

Etapa 4. Quando você estiver em lessuse a barra e digite o ID da mensagem para procurar os logs relacionados ao deployment transactionID. 

Exemplo:"/60129547881" (Enquanto estiver em less, use n para navegar até o próximo resultado)

Exemplo de mensagem em execução:

Exemplo de mensagem de falha:

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

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

Mensagens de falha comuns

Essas são mensagens de falha comuns que podem ser vistas no front-end da Management Center Task assim 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 eles não sejam vistos ou não resolvam sua situação, entre em contato com o TAC para obter assistência. 

----------------------------------------------------------------------------------------

Entre em contato com o TAC para obter assistência

Caso as informações anteriores não permitam que uma implantação de política prossiga, ou caso o problema pareça não estar relacionado a um comportamento documentado preexistente, 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