Renovação do certificado CA do FMC Sftunnel para conectividade do FTD

Introdução

Este documento descreve a renovação do certificado da CA (Certificate Authority, Autoridade de certificação) do túnel do Firepower Management Center (FMC) em relação à conectividade do Firepower Threat Defense (FTD).

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Firepower Threat Defense
• Firepower Management Center
• Public Key Infrastructure (PKI)

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

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.

Informações de Apoio

O FMC e o FTD comunicam-se entre si através do túnel sfl (túnel Sourcefire). Essa comunicação usa certificados para tornar a conversação segura em uma sessão TLS. Mais informações sobre o túnel sf e como ele é estabelecido podem ser encontradas neste link.

Na captura de pacotes, você pode ver que o FMC (10.48.79.232 neste exemplo) e o FTD (10.48.79.23) estão trocando certificados. Eles fazem isso para confirmar que conversam com o dispositivo correto e que não há interceptação nem ataque Man-In-The-Middle (MITM). A comunicação é criptografada usando esses certificados e somente a parte que tem a chave privada associada para esse certificado pode descriptografá-la novamente.

Certificate_exchange_server_cert

Certificate_exchange_client_cert

Você pode ver que os certificados são assinados pela mesma Autoridade de Certificação (CA) interna (emissor) que está configurada no sistema FMC. A configuração é definida no arquivo FMC em /etc/sf/sftunnel.conf que contém algo como:

proxyssl {
  proxy_cert   /etc/sf/keys/sftunnel-cert.pem;                ---> Certificate provided by FMC to FTD for the sftunnel communication (signed by InternalCA)
  proxy_key    /etc/sf/keys/sftunnel-key.pem;
  proxy_cacert /etc/sf/ca_root/cacert.pem;                    ---> CA certificate (InternalCA)
  proxy_crl    /etc/sf/ca_root/crl.pem;
  proxy_cipher 1;
  proxy_tls_version TLSv1.2;
}; 

Indica a autoridade de certificação que é utilizada para assinar todos os certificados de túnel duplo (tanto o FTD como o FMC) e o certificado utilizado pelo FMC para enviar a todos os FTD. Este certificado é assinado pela InternalCA.

Quando o FTD se registra no FMC, o FMC também cria um certificado para enviar para o dispositivo FTD que é usado para a comunicação posterior no túnel sf. Este certificado também é assinado pelo mesmo certificado CA interno. No FMC, você pode encontrar esse certificado (e a chave privada) em /var/sf/peers/<UUID-FTD-device> e possivelmente na pasta certs_push e é chamado sftunnel-cert.pem (sftunnel-key.pem para a chave privada). No FTD, você pode encontrá-los em /var/sf/peers/<UUID-FMC-device> com a mesma convenção de nomenclatura.

No entanto, cada certificado também tem um período de validade para fins de segurança. Ao inspecionar o certificado InternalCA, podemos ver também o período de validade, que é de 10 anos para o FMC InternalCA, conforme mostrado na captura de pacotes.

FMC-InternalCA_valid

Problema

O certificado InternalCA do FMC só é válido por dez anos. Após o prazo de validade, o sistema remoto deixa de confiar neste certificado (bem como nos certificados por ele assinados), o que dá origem a problemas de comunicação sftunnel entre o FTD e os dispositivos do FMC. Isso também significa que várias funcionalidades importantes, como eventos de conexão, pesquisas de malware, regras baseadas em identidade, implantações de políticas e muitas outras coisas não estão funcionando.

Os dispositivos aparecem como desativados na interface do usuário do FMC na guia Devices > Device Management quando o sftunnel não está conectado. O problema relacionado a essa expiração é rastreado na ID de bug da Cisco CSCwd08098. Observe que todos os sistemas são afetados, mesmo quando você executa uma versão fixa do defeito. Mais informações sobre essa correção podem ser encontradas na seção Solução.

Dispositivos desativados

O FMC não atualiza automaticamente a CA nem republica os certificados nos dispositivos de FTD. Além disso, não existe qualquer alerta sanitário do CVP que indique que o certificado expira. A ID de bug da Cisco CSCwd08448 é rastreada a este respeito para fornecer um alerta de integridade na interface do usuário do FMC no futuro.

O que acontece após a data de expiração?

Inicialmente, nada acontece e os canais de comunicação do sftunnel continuam a operar como antes. No entanto, quando a comunicação sftunnel entre os dispositivos FMC e FTD é interrompida e tenta restabelecer a conexão, ela falha e você pode observar linhas de registro no arquivo de registro de mensagens que apontam para a expiração do certificado.

Linhas de log do dispositivo FTD de /ngfw/var/log/messages:

Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [INFO] Initiating IPv4 connection to 10.10.200.31:8305/tcp
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [INFO] Wait to connect to 8305 (IPv4): 10.10.200.31
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [INFO] Connected to 10.10.200.31 from resolved_ip_list (port 8305) (IPv4)
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR] -Error with certificate at depth: 1
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR]   issuer   = /title=InternalCA/OU=Intrusion Management System/CN=06f5f3ca-c77b-11e2-81bf-884d9d11f3ef/O=Sourcefire, Inc.
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR]   subject  = /title=InternalCA/OU=Intrusion Management System/CN=06f5f3ca-c77b-11e2-81bf-884d9d11f3ef/O=Sourcefire, Inc.
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR]   err 10:certificate has expired
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR] SSL_renegotiate error: 1: error:00000001:lib(0):func(0):reason(1)
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR] Connect:SSL handshake failed
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [WARN] SSL Verification status: certificate has expired

Linhas de registro do dispositivo FMC de /var/log/messages:

Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [INFO] VERIFY ssl_verify_callback_initial ok=1!
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [ERROR] SSL_renegotiate error: 1: error:00000001:lib(0):func(0):reason(1)
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [WARN] establishConnectionUtil: SSL handshake failed
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [WARN] establishConnectionUtil: SSL Verification status: ok
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [WARN] establishConnectionUtil: SSL handshake failed: error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [INFO] establishConnectionUtil: Failed to connect using SSL to: '10.10.21.10'
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [ERROR] establishSSLConnection: Unable to connect with both threads:
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [ERROR] establishSSLConnection: ret_accept status : Too many levels of symbolic links
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [ERROR] establishSSLConnection: iret_connect status: Too many levels of symbolic links
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [ERROR] establishSSLConnection: Failed connecting with SSL to using to: '10.10.21.10' rval[40] *CA cert from FMC

A comunicação sftunnel pode ser interrompida por vários motivos:

• Perda de comunicação devido à perda de conectividade de rede (possivelmente apenas temporária)
• Reinicialização do FTD ou do FMC
  • Os esperados: reinicialização manual, atualizações, reinicialização manual do processo sftunnel no FMC ou FTD (por exemplo, por pmtool restartbyid sftunnel)
  • Inesperados: retornos de rastreamento, queda de energia

Como há tantas possibilidades que podem interromper a comunicação do túnel, é altamente aconselhável corrigir a situação o mais rápido possível, mesmo quando atualmente todos os dispositivos FTD estão conectados corretamente, apesar do certificado expirado.

Como verificar rapidamente se o certificado expirou ou quando ele expira?

A maneira mais fácil é executar esses comandos na sessão SSH do FMC:

expert
sudo su
cd /etc/sf/ca_root
openssl x509 -dates -noout -in cacert.pem

Mostra os elementos de Validade do certificado. A parte principal relevante aqui é o "notAfter" que mostra que o certificado aqui é válido até 5 de outubro de 2034.

NãoDepois

Se você preferir que um único comando seja executado que forneça imediatamente a quantidade de dias para os quais o certificado ainda é válido, você poderá usar:

CERT_PATH="/etc/sf/ca_root/cacert.pem"; EXPIRY_DATE=$(openssl x509 -enddate -noout -in "$CERT_PATH" | cut -d= -f2); EXPIRY_DATE_SECONDS=$(date -d "$EXPIRY_DATE" +%s); CURRENT_DATE_SECONDS=$(date +%s); THIRTY_DAYS_SECONDS=$((30*24*60*60)); EXPIRY_THRESHOLD=$((CURRENT_DATE_SECONDS + THIRTY_DAYS_SECONDS)); DAYS_LEFT=$(( (EXPIRY_DATE_SECONDS - CURRENT_DATE_SECONDS) / (24*60*60) )); if [ "$EXPIRY_DATE_SECONDS" -le "$CURRENT_DATE_SECONDS" ]; then DAYS_EXPIRED=$(( (CURRENT_DATE_SECONDS - EXPIRY_DATE_SECONDS) / (24*60*60) )); echo -e "\nThe certificate has expired $DAYS_EXPIRED days ago.\nIn case the sftunnel communication with the FTD is not yet lost, you need to take action immediately in renewing the certificate.\n"; elif [ "$EXPIRY_DATE_SECONDS" -le "$EXPIRY_THRESHOLD" ]; then echo -e "\nThe certificate will expire within the next 30 days!\nIt is ONLY valid for $DAYS_LEFT more days.\nIt is recommended to take action in renewing the certificate as quickly as possible.\n"; else echo -e "\nThe certificate is valid for more than 30 days.\nIt is valid for $DAYS_LEFT more days.\nThere is no immediate need to perform action but this depends on how far the expiry date is in the future.\n"; fi

Um exemplo de uma configuração em que o certificado ainda é válido por vários anos é mostrado.

Certificate_expiry_validation_command

Como posso ser notificado futuramente sobre a expiração de um certificado?

Com atualizações recentes do VDB (399 ou superior), você é alertado automaticamente quando seu certificado expira em 90 dias. Portanto, você não precisa rastrear isso manualmente, pois é alertado quando está próximo do tempo de expiração. Em seguida, ele é exibido na página da Web do FMC em dois formulários. Ambas as formas se referem à página de notificação de campo.

O primeiro método é através da Guia Tarefa. Essa mensagem é fixa e está disponível para o usuário, a menos que seja explicitamente fechada. O pop-up de notificação também é exibido e fica disponível até que seja explicitamente fechado pelo usuário. Ele sempre aparece como um erro.

Notificação de vencimento na guia Tarefa

O segundo método é através do Health Alert. Isso aparece na guia Integridade, mas não é difícil e substitui ou remove quando o monitor de integridade é executado, o que por padrão é a cada 5 minutos. Ele também mostra um pop-up de notificação que precisa ser fechado explicitamente pelo usuário. Isso pode aparecer como erro (quando expirado) como um aviso (quando expirará).

Notificação de vencimento na guia Integridade

Notificação de aviso no Pop-up de Alerta de Integridade

Notificação de erro no pop-up de alerta de integridade

Solução 1 - O certificado ainda não expirou (cenário ideal)

Essa é a melhor situação, pois, dependendo da expiração do certificado, ainda temos tempo. Ou adotamos a abordagem totalmente automatizada (recomendada), que depende da versão do FMC, ou adotamos uma abordagem mais manual, que requer interação com o TAC.

Método recomendado

Esta é a situação em que não se espera nenhum tempo de inatividade e a menor quantidade de operações manuais em circunstâncias normais.

Antes de continuar, você deve instalar o hotfix para sua versão específica, conforme listado aqui. A vantagem aqui é que esses hotfixes não exigem uma reinicialização do FMC e, portanto, uma possível comunicação sftunnel interrompida quando o certificado já expirou. Os hotfixes disponíveis são:

• 7.0.0 - 7.0.6 : Hotfix FK - 7.0.6.99-9
• 7.1.x: nenhuma versão fixa como fim da manutenção de software
• 7.2.0 - 7.2.9 : Hotfix FZ - 7.2.9.99-4
• 7.3.x : Hotfix AE - 7.3.1.99-4
• 7.4.0 - 7.4.2 : Hotfix AO - 7.4.2.99-5
• 7.6.0 : Hotfix B - 7.6.0.99-5

Após a instalação do hotfix, o FMC agora contém o script generate_certs.pl que:

1. Regenera a CA interna
2. Recria os certificados sftunnel assinados por esta nova InternalCA
3. Envia por push os novos certificados sftunnel e as chaves privadas para os respectivos dispositivos FTD (quando o sftunnel estiver operacional)

Por conseguinte, recomenda-se (se possível):

1. Instalar o hotfix aplicável para o treinamento de versão
2. Fazer um backup no FMC
3. Valide todas as conexões sftunnel atuais usando o script sftunnel_status.pl no FMC (no modo expert)
4. Execute o script a partir do modo especialista usando generate_certs.pl
5. Inspecionar o resultado para validar se são necessárias quaisquer operações manuais (quando os dispositivos não estão ligados ao CVP) [explicado mais adiante]
6. Execute o sftunnel_status.pl do FMC para validar se todas as conexões do sftunnel estão funcionando corretamente

Script Generate_certs.pl

No exemplo aqui, você vê que ele cria um arquivo de log em /var/log/sf/sfca_generation.log, indica para usar sftunnel_status.pl, indica o tempo de expiração em InternalCA e indica para quaisquer falhas nele. Aqui, por exemplo, ele falhou ao enviar os certificados para o dispositivo BSNS-1120-1 e EMEA-FPR3110-08, o que é esperado porque o sftunnel estava inoperante para esses dispositivos.

Para corrigir o sftunnel das conexões com falha, execute as próximas etapas:

1. Na CLI do FMC, abra o arquivo FAILED_PUSH usando cat /var/tmp/certs/1728303362/FAILED_PUSH (o valor do número representa o tempo UNIX, portanto, verifique a saída do comando anterior em seu sistema) que tem o próximo formato: FTD_UUID FTD_NAME FTD_IP SOURCE_PATH_ON_FMC DESTINATION_PATH_ON_FTD
   
   FAILED_PUSH
   
   
2. Transferir esses novos certificados (cacert.pem / sftunnel-key.pem / sftunnel-cert.pem) do FMC para os dispositivos do FTD
   ===Aproximação automática===
   
   A instalação do hotfix também fornece os scripts copy_sftunnel_certs.py e copy_sftunnel_certs_jumpserver.py que automatizam a transferência dos vários certificados para sistemas para os quais o sftunnel não estava ativo enquanto os certificados eram regenerados. Isso também pode ser usado para sistemas que tiveram uma conexão sftunnel interrompida porque o certificado já expirou.
   
   Você pode usar o script copy_sftunnel_certs.py quando o próprio FMC tiver acesso SSH aos vários sistemas FTD. Se não for o caso, você pode fazer o download do script (/usr/local/sf/bin/copy_sftunnel_certs_jumpserver.py) do FMC para um servidor de salto que tenha acesso SSH aos dispositivos FMC e FTD e executar o script Python a partir daí. Se isso também não for possível, sugira executar a abordagem manual mostrada a seguir. Os próximos exemplos mostram o script copy_sftunnel_certs.py sendo usado, mas as etapas são as mesmas para o script copy_sftunnel_certs_jumpserver.py .
   
   A. Crie um arquivo CSV no FMC (ou servidor de salto) que contenha as informações do dispositivo (nome_do_dispositivo, endereço IP, nome_do_usuário admin, senha_admin) que são usadas para fazer a conexão SSH.
   
   Ao executar isso a partir de um servidor remoto, como um servidor de salto para o FMC primário, certifique-se de adicionar os detalhes do FMC primário como a primeira entrada seguida por todos os FTD gerenciados e FMC secundário. Ao executar isso a partir de um servidor remoto, como um servidor de salto para o FMC secundário, certifique-se de adicionar os detalhes do FMC secundário como a primeira entrada seguida por todos os FTD gerenciados.
   
   i. Crie um arquivo usando vi devices.csv.vi devices.csv
   
   ii) Isso abre o arquivo vazio (não mostrado) e você preenche os detalhes como mostrado depois de usar i letra no teclado para entrar no modo INTERATIVO (visto na parte inferior da tela).
   exemplo de devices.csv
   
   iii) Quando terminar, feche e salve o arquivo usando ESC seguido por :wq e, em seguida, Enter.
   Salve o device.csv
   
   B. Execute o script (a partir da raiz usando sudo) com copy_sftunnel_certs.py devices.csv e ele mostrará o resultado. Aqui, ele mostra que o certificado para FTDv foi enviado corretamente e que para BSNS-1120-1 ele não pôde fazer a conexão SSH com o dispositivo.
   
   copy_sftunnel_certs.py dispositivos.csv
   
   ===Aproximação manual===
   
   
   1. Imprima (cat) a saída de cada um dos arquivos para cada FTD afetado (cacert.pem / sftunnel-key.pem (não mostrado completamente para fins de segurança) / sftunnel-cert.pem) na CLI do FMC copiando o local do arquivo da saída anterior (arquivo FAILED_PUSH).
      
      cacert.pem
      sftunnel-key.pem
      sftunnel-cert.pem
   2. Abra o FTD CLI de cada FTD respectivo no modo especialista com privilégios de raiz através do sudo su e renove os certificados com o próximo procedimento.
      1. Navegue até o local visto no realce azul claro da saída FAILED_PUSH (cd /var/sf/peers/cdb123c8-4347-11ef-aca1-f3aa241412a1 aqui por exemplo, mas isso é diferente para cada FTD).
      2. Fazer backups dos arquivos existentes.
         

         cp cacert.pem cacert.pem.backup
         cp sftunnel-cert.pem sftunnel-cert.pem.backup
         cp sftunnel-key.pem sftunnel-key.pem.backup​

         
         Fazer backups dos certificados atuais
      3. Esvazie os arquivos para que possamos gravar novo conteúdo neles.
         

         > cacert.pem
         > sftunnel-cert.pem
         > sftunnel-key.pem​

         
         Conteúdo vazio de arquivos de certificado existentes
      4. Escreva o novo conteúdo (da saída FMC) em cada um dos arquivos individualmente usando vi cacert.pem / vi sftunnel-cert.pem / vi sftunnel-key.pem (comando separado por arquivo - capturas de tela mostram isso apenas para cacert.pem, mas precisam ser repetidas para sftunnel-cert.pem e sftunnel-key.pem).vi cacert.pem
         1. Pressione i para entrar no modo interativo (depois que o comando vi for inserido e um arquivo vazio for exibido).
         2. Copie e cole o conteúdo inteiro (incluindo -----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----) no arquivo.
            Copiar conteúdo no vi (modo INSERT)
         3. Feche e grave no arquivo com ESC seguido por :wq e insira.
            ESC seguido por :wq para gravar no arquivo
      5. Valide se as permissões corretas (chmod 644) e os proprietários (chown root:root) estão definidos para cada um dos arquivos usando ls -hal. Isso é definido corretamente na verdade quando atualizamos o arquivo existente.
         Todos os arquivos de certificado atualizados com permissões e proprietários de direitos
         
         
   3. Reinicie o sftunnel em cada FTD respectivo onde o sftunnel não estava operacional para que as alterações no certificado entrem em vigor com o comando pmtool restartbyid sftunnel
      
      pmtool restartbyid sftunnel
      
      
3. Valide se todos os FTDs estão conectados corretamente agora usando a saída sftunnel_status.pl

Solução 2 - O certificado já expirou

Nesta situação, temos dois cenários diferentes. Ou todas as conexões sftunnel ainda estão operacionais ou não estão mais (ou parciais).

FTDs ainda conectados por meio de sftunnel

Podemos aplicar o mesmo procedimento indicado na seção Certificado ainda não expirou (cenário ideal) - Abordagem recomendada.

No entanto, NÃO atualize nem reinicialize o FMC (ou qualquer FTD) nesta situação, pois ele desconecta todas as conexões sftunnel e precisamos executar manualmente todas as atualizações de certificado em cada FTD. A única exceção a esta, são as versões de Hotfix listadas, pois não exigem uma reinicialização do FMC.

Os túneis permanecem conectados e os certificados são substituídos em cada um dos FTD. Caso alguns certificados falhem ao serem preenchidos, ele o avisa com os que falharam e você precisa fazer a abordagem manual conforme indicado anteriormente na seção anterior.

Os FTDs não estão mais conectados por meio do sftunnel

Método recomendado

Podemos aplicar o mesmo procedimento indicado na seção Certificado ainda não expirou (cenário ideal) - Abordagem recomendada. Neste cenário, o novo certificado será gerado no FMC, mas não poderá ser copiado para os dispositivos, pois o túnel já está inoperante. Esse processo pode ser automatizado com os scripts copy_sftunnel_certs.py / copy_sftunnel_certs_jumpserver.py

Se todos os dispositivos do FTD estiverem desconectados do FMC, podemos atualizá-lo nessa situação, pois isso não afeta as conexões de sftunnel. Se ainda houver alguns dispositivos conectados por meio do sftunnel, lembre-se de que a atualização do FMC fecha todas as conexões do sftunnel e elas não são ativadas novamente devido ao certificado expirado. O benefício da atualização aqui seria que ela fornece uma boa orientação sobre os arquivos de certificado que precisam ser transferidos para cada um dos FTDs.

Abordagem manual

Nessa situação, você pode executar o script generate_certs.pl no FMC que gera os novos certificados, mas ainda é necessário enviá-los para cada um dos dispositivos do FTD manualmente. Dependendo da quantidade de dispositivos, isso pode ser feito ou pode ser uma tarefa entediante. No entanto, ao usar os scripts copy_sftunnel_certs.py / copy_sftunnel_certs_jumpserver.py, isso é altamente automatizado.