Pesquisando defeitos disposições da política em matéria de defesa da ameaça de FirePOWER

Introdução

Com defesa da ameaça de Cisco FirePOWER (FTD), as características tradicionais do firewall stateful oferecidas pelos recursos de firewall adaptáveis das ferramentas de segurança (ASA) e do Next Gen (postos pelo Snort) são combinadas agora em um produto. Devido a isto a mudança, infraestrutura da distribuição de política em FTD segura agora alterações de configuração para o código ASA (igualmente referido como LINA) e o Snort em um pacote. Este original fornece uma visão geral de alto nível do processo da distribuição de política em FTD e assim como em técnicas do Troubleshooting básico. 

Pré-requisitos

Cisco recomenda que você tem o conhecimento do seguinte Produtos:

• Centro de gerenciamento de FirePOWER (FMC)
• Defesa da ameaça de FirePOWER (FTD)

aviso: 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 sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Vista geral da distribuição de política

Cisco FTD utiliza distribuições de política para controlar e eliminar configurações para os dispositivos que são registrados ao centro de gerenciamento de FirePOWER (FMC) próprio. Dentro do desenvolvimento, há umas séries de etapas que se quebram em “fases”.

As fases FMC podem ser resumidas na seguinte lista.

Fase 0	Iniciação do desenvolvimento
Fase 1	Coleção do objeto de base de dados
Fase 2	Política e coleção do objeto
Fase 3	Geração do comando line configuration NGFW
Fase 4	Geração do pacote do desenvolvimento do dispositivo
Fase 5	Enviando e recebendo o pacote do desenvolvimento
Fase 6	Durante o desenvolvimento, as ações do desenvolvimento, e as mensagens de sucesso de distribuição

Compreender as fases, e saber onde a falha é ficada situada no processo, podem ajudar em pesquisar defeitos as falhas as caras de um esse sistema de FirePOWER. Em algumas situações, pode ser um conflito devido às configurações precedente ou causado por uma palavra-chave faltante da configuração avançada do cabo flexível que possa causar falhas que os relatórios do dispositivo não são explícitos aproximadamente.

Vista geral do exemplo

Etapa1. O usuário clica o botão do “desenvolvimento”, especificando que dispositivo o usuário gostaria de selecionar.

Etapa 2. O desenvolvimento para um dispositivo é comprometido uma vez, o FMC começa a recolher todas as configurações relevantes ao dispositivo. 

Etapa 3. Uma vez que as configurações são recolhidas, o FMC cria o pacote e envia-o sobre ao sensor sobre seu mecanismo de uma comunicação chamado SFTunnel.

Etapa 4. O FMC notifica então o sensor para começar o processo de desenvolvimento usando a política fornecida, ao escutar as respostas individuais.

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

A. A primeira metade do desenvolvimento é a configuração do Snort onde a configuração do Snort é testada localmente para assegurar sua validez. Provado uma vez ser válido a configuração nova é movido para o diretório da produção para o Snort. Se a validação falha, a distribuição de política falha nesta etapa.

B. A segunda metade da carga do pacote do desenvolvimento é para a configuração de LINA onde é aplicada diretamente ao processo de LINA pelo processo do ngfwManager. Se uma falha ocorre, as mudanças estão roladas para trás e uma falha da distribuição de política ocorre.

Etapa 6. Se o Snort e os pacotes de LINA são bem sucedidos, os sinais do dispositivo gerenciado roncam para reiniciar ou recarregar a fim carregar a configuração nova e salvar todas as configurações atual.

Passo 7. Se todas as mensagens são bem sucedidas, o sensor envia um mensagem de sucesso e uma espera para que esteja reconhecido pelo centro de gerenciamento.

Etapa 8. Uma vez que recebido, o FMC marca a tarefa como um sucesso e permite que o pacote da política termine.

Troubleshooting

Os problemas encontrados durante a distribuição de política podem ser devidos mas não limitados às seguintes razões:

1. Misconfiguration
2. Uma comunicação entre FMC e FTD
3. Base de dados e saúdes de sistema
4. Defeitos do software e advertências
5. Outras situações exclusivas

Algumas destas edições podem facilmente ser fixadas, quando outro puderem exigir o auxílio do centro de assistência técnica da Cisco (TAC).

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

Troubleshooting da interface gráfica de usuário (GUI) FMC

Cisco recomenda cada sessão de Troubleshooting para que as falhas do desenvolvimento comecem no dispositivo FMC.

No indicador da notificação de falha, em todas as versões além de 6.2.3, há as ferramentas do Troubleshooting adicional que podem ajudar com as falhas que você pode enfrentar. 

Utilizando os transcritos do desenvolvimento

Etapa 1. Levante as disposições alistam na Web UI FMC.

Etapa 2. Quando a aba das disposições for selecionada, selecione da “a opção da história mostra”.

Etapa 3. Dentro da caixa da história do desenvolvimento, você pode ver todas as disposições precedentes de seu FMC. Selecione o desenvolvimento em que você gostaria de ver mais dados.

Etapa 4. Uma vez que um elemento do desenvolvimento é selecionado, você está tomado à seleção dos detalhes do desenvolvimento que mostra uma lista de todos os dispositivos dentro da transação. Estas entradas são divididas nas seguintes colunas: Número do dispositivo, nome de dispositivo, estado, e transcrito.

Etapa 5. Você pode selecionar o dispositivo na pergunta e clicar sobre a opção do transcrito para ver o transcrito individual do desenvolvimento que pode o informar das falhas assim como das configurações que são colocadas nos dispositivos gerenciado.

Etapa 6. Este transcrito pode designar determinadas condições de falha assim como indicar um número muito importante para a próxima etapa: ID de transação.

Passo 7. Em um desenvolvimento de FirePOWER, o ID de transação é o que pode ser usado para seguir cada seção individual de uma distribuição de política. Com isto, nos dados da linha de comando do dispositivo, você pode obter uma versão mais detalhada destes dados para a pesquisa de defeitos e a análise.

Dica: Caso você for incapaz de encontrar o ID de transação ou se você está em uma versão antes que este estiver imprimido, o log acima pode ainda ser do uso para encontrar mensagens de falha individuais.

Pesquisa de defeitos usando logs FMC

Embora é apropriado contratar o tac Cisco analisar os logs, olhar através dos logs pode ajudar com isolamento de problema inicial e expedir a definição. Há uns arquivos de registro múltiplos em FMC que revelam os detalhes sobre o processo da distribuição de política. Os dois logs o mais geralmente providos são policy_deployment.log e usmsharedsvcs.log.

Todos os arquivos mencionados neste original podem ser vistos com os comandos linux múltiplos tais como mais, menos e vi. Contudo, é muito importante assegurar-se de que somente as ações lidas lhe estejam executadas. Todos os arquivos exigem o acesso raiz poder os ver.

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

Este log marca claramente o começo da tarefa da distribuição de política em FMC e a conclusão de cada fase, que ajuda a determinar a fase aonde o desenvolvimento foi executado em uma falha, junto com o código de falha. O valor do “transactionID” incluído na parcela JSON do log pode ser usado para encontrar entradas de registro relativas a uma tentativa particular do desenvolvimento.

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

Quando este arquivo de registro existir durante todo as liberações 6.x, partindo de 6.4, sua cobertura esteve expandida. Descreve agora as etapas detalhadas tomadas em FMC para construir os pacotes do desenvolvimento, consequentemente é usada melhor analisando falhas da fase 1 - 4. O começo de cada fase é marcado por uma linha com a “INFORMAÇÃO que começa o 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)
...

Pesquisa de defeitos do dispositivo gerenciado

Há umas fases e umas seções adicionais segundo o pacote do dispositivo, a Alta disponibilidade da configuração, e o resultado de fases prévias para cada dispositivo gerenciado. Se um problema de desenvolvimento é isolado a uma falha no dispositivo gerenciado, um Troubleshooting mais adicional pode ser executado no dispositivo que usa dois entra o dispositivo: policy_deployment.log e ngfwManager.log.

/ngfw/var/log/ngfwManager.log

Este arquivo de registro fornece as etapas detalhadas tomadas pelo gerente de uma comunicação da configuração e pelo expedidor da configuração para comunicar-se com o FMC, trabalho o pacote do desenvolvimento, e orquestra a validação e o aplicativo do Snort e das configurações de LINA. Estes são alguns exemplos de ngfwManager.log que representam o começo de 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 para roncar. O índice do log na maior parte é avançado embora e exige a análise pelo TAC, ele é ainda possível para seguir o processo usando algumas entradas chaves:

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

Etapa1. Um desenvolvimento falha

Etapa 2. Obtenha o transcrito e o ID de transação da distribuição.

Etapa 3. O SSH em seu centro de gerenciamento e utiliza a utilidade de Linux menos para ler o arquivo como segue em seu FMC:

Exemplo: “sudo menos /var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log” (a senha do sudo é sua senha de usuários para o ssh)

Etapa 4. Uma vez que você é dentro menos, use a barra e entre-a no ID de mensagem para procurar pelos logs relativos ao transactionID do desenvolvimento. 

Exemplo: "/60129547881" {quando dentro menos, uso n navegar ao resultado seguinte}

Exemplo de executar a mensagem:

Exemplo do mensagem de falha:

5) Compare a falha apropriada à tabela anexada de mensagens da falha comum.

 Isto é o failed_to_retrieve_running_configuration ocorre durante falhas de comunicação entre os dois dispositivos. 

Mensagens da falha comum

Falham abaixo as mensagens da falha comum que podem ser consideradas na parte frontal da tarefa do centro de gerenciamento assim como do código de erro que podem ser considerados na parte posterior. Estas mensagens podem ser analisadas e comparado com os motivos comuns para resoluções possíveis.

Caso estes não forem vistos, nem não resolverem sua situação que está ocorrendo, contacte por favor o TAC para o auxílio. 

Contacte o TAC para o auxílio

Caso a informação acima não permitir uma distribuição de política continuar, ou se a edição parece não ser relacionada a um comportamento documentado PRE-existente, use por favor as etapas fornecidas na relação seguinte para gerar um arquivo da pesquisa de defeitos e para alcançá-lo para fora ao TAC para a criação da análise e do erro.

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