Integrar e solucionar problemas do SecureX com o Firepower Threat Defense (FTD)

Introdução

Este documento descreve as etapas necessárias para integrar, verificar e solucionar problemas do SecureX com o Firepower Threat Defense (FTD). 

Pré-requisitos

Requisitos

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

• Firepower Management Center (FMC)
• Firepower Threat Defense (FTD)
• Virtualização opcional de imagens 

Componentes Utilizados

• Firepower Threat Defense (FTD) - 6,5
• Firepower Management Center (FMC) - 6,5
• Troca de serviços de segurança (SSE)
• SecureX
• Portal Smart License

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.

Configurar

Licenciamento

Funções da Virtual Account: 

Somente o administrador da Virtual Account ou o administrador da Smart Account têm o privilégio de vincular a Smart Account à conta SSE.

Etapa 1. Para validar a função da Smart Account, navegue até software.cisco.com e, no menu Administração, selecione Gerenciar Smart Account.

Etapa 2. Para validar a função de usuário, navegue até Usuários e confirme se, em Funções, as contas estão definidas para ter um Administrador de conta virtual, como mostrado na imagem.

Etapa 3. Verifique se a Virtual Account selecionada para vincular no SSE contém a licença para os dispositivos de segurança se uma conta que não contém a licença de segurança estiver vinculada no SSE, se os dispositivos de segurança e o evento não aparecerem no portal do SSE.

Etapa 4. Para confirmar que o FMC foi registrado na Virtual Account correta, navegue até System>Licenses>Smart License:

Vincule suas contas ao SSE e registre os dispositivos.

Etapa 1. Ao fazer logon em sua conta SSE, você precisa vincular sua Smart Account à sua conta SSE, para isso, você precisa clicar no ícone de ferramentas e selecionar Vincular Contas.

Quando a conta estiver vinculada, você verá a Smart Account com todas as Virtual Accounts nela.

Registrar os dispositivos no SSE

Etapa 1. Verifique se estes URLs são permitidos em seu ambiente:

Região dos EUA

• api-sse.cisco.com
• eventing-ingest.sse.itd.cisco.com

Região da UE

• api.eu.sse.itd.cisco.com
• eventing-ingest.eu.sse.itd.cisco.com

Região APJ

• api.apj.sse.itd.cisco.com
• eventing-ingest.apj.sse.itd.cisco.com

Etapa 2. Faça login no portal SSE com este URL https://admin.sse.itd.cisco.com, Navegue até Cloud Services e habilite ambas as opções Eventing e Cisco SecureX threat response, como mostrado na imagem a seguir:

 Etapa 3. Faça login no Firepower Management Center e navegue até System>Integration>Cloud Services, habilite Cisco Cloud Event Configuration e selecione os eventos que deseja enviar para a nuvem:

Etapa 4. Você pode voltar ao portal SSE e confirmar que agora pode ver os dispositivos inscritos no SSE:

Os eventos são enviados pelos dispositivos de FTD, navegue até os Eventos no portal SSE para verificar os eventos enviados pelos dispositivos para o SSE, como mostrado na imagem:

Configurar painéis personalizados no SecureX

Etapa 1. Para criar seu Painel, clique no ícone + Novo Painel, Selecione um nome e um Bloco que deseja usar para o Painel, como mostrado na imagem:

Etapa 2. Depois disso, você poderá ver as informações do Painel preenchidas a partir do SSE. É possível selecionar qualquer uma das Ameaças detectadas e o portal do SSE é iniciado com o filtro Tipo de evento:

Verificar

Valide se os FTDs geram eventos (malware ou intrusão), para eventos de intrusão, navegue até Analysis>Files>Malware Events, para eventos de intrusão, navegue até Analysis>Intrusion>Events.

Valide se os eventos estão registrados no portal SSE conforme mencionado na seção Registrar os dispositivos no SSE etapa 4.

Verifique se as informações são exibidas no painel SecureX ou verifique os logs de API para que você possa ver o motivo de uma possível falha de API.

Troubleshooting

Detectar problemas de conectividade

Você pode detectar problemas de conectividade genéricos a partir do arquivo action_queue.log. Em caso de falha, você pode ver esses logs presentes no arquivo:

ActionQueueScrape.pl[19094]: [SF::SSE::Enrollment] canConnect: System (/usr/bin/curl -s --connect-timeout 10 -m 20 -L --max-redirs 5 --max-filesize 104857600 --capath /ngfw/etc/sf/keys/fireamp/thawte_roots -f https://api.eu.sse.itd.cisco.com/providers/sse/api/v1/regions) Failed, curl returned 28 at /ngfw/usr/local/sf/lib/perl/5.10.1/SF/System.pmline 10477.

Nesse caso, o código de saída 28 significa que a operação atingiu o tempo limite e devemos verificar a conectividade com a Internet. Você também pode ver o código de saída 6, que significa problemas com a resolução DNS

Problemas de conectividade devido à resolução DNS

Etapa 1. Verifique se a conectividade funciona corretamente.

root@ftd01:~# curl -v -k https://api-sse.cisco.com
* Rebuilt URL to: https://api-sse.cisco.com/
* getaddrinfo(3) failed for api-sse.cisco.com:443
* Couldn't resolve host 'api-sse.cisco.com'
* Closing connection 0
curl: (6) Couldn't resolve host 'api-sse.cisco.com'

A saída acima mostra que o dispositivo não pode resolver o URL https://api-sse.cisco.com; nesse caso, precisamos validar se o servidor DNS apropriado está configurado, ele pode ser validado com um nslookup da CLI do especialista:

root@ftd01:~# nslookup api-sse.cisco.com
;; connection timed out; no servers could be reached

A saída acima mostra que o DNS configurado não foi alcançado. Para confirmar as configurações DNS, use o comando show network:

> show network
===============[ System Information ]===============
Hostname                  : ftd01
DNS Servers               : x.x.x.10
Management port           : 8305
IPv4 Default route
Gateway                   : x.x.x.1

======================[ eth0 ]======================
State                     : Enabled
Link                      : Up
Channels                  : Management & Events
Mode                      : Non-Autonegotiation
MDI/MDIX                  : Auto/MDIX
MTU                       : 1500
MAC Address               : x:x:x:x:9D:A5
----------------------[ IPv4 ]----------------------
Configuration             : Manual
Address                   : x.x.x.27
Netmask                   : 255.255.255.0
Broadcast                 : x.x.x.255
----------------------[ IPv6 ]----------------------
Configuration             : Disabled

===============[ Proxy Information ]================
State                     : Disabled
Authentication            : Disabled

Neste exemplo, o servidor DNS errado foi usado. Você pode alterar as configurações DNS com este comando:

> configure network dns x.x.x.11

Depois que essa conectividade puder ser testada novamente e dessa vez, a conexão será bem-sucedida.

root@ftd01:~# curl -v -k https://api-sse.cisco.com
* Rebuilt URL to: https://api-sse.cisco.com/
* Trying x.x.x.66...
* Connected to api-sse.cisco.com (x.x.x.66) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=US; ST=California; L=San Jose; O=Cisco Systems, Inc.; CN=api -sse.cisco.com
* start date: 2019-12-03 20:57:56 GMT
* expire date: 2021-12-03 21:07:00 GMT
* issuer: C=US; O=HydrantID (Avalanche Cloud Corporation); CN=HydrantID S SL ICA G2
* SSL certificate verify result: self signed certificate in certificate c hain (19), continuing anyway.
> GET / HTTP/1.1
> Host: api-sse.cisco.com
> User-Agent: curl/7.44.0
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< Date: Wed, 08 Apr 2020 01:27:55 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 9
< Connection: keep-alive
< Keep-Alive: timeout=5
< ETag: "5e17b3f8-9"
< Cache-Control: no-store
< Pragma: no-cache
< Content-Security-Policy: default-src 'self'
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Strict-Transport-Security: max-age=31536000; includeSubdomains;

Problemas de registro no portal SSE

O FMC e o FTD precisam de uma conexão com os URLs SSE em sua interface de gerenciamento. Para testar a conexão, insira estes comandos na CLI do Firepower com acesso raiz:

curl -v https://api-sse.cisco.com/providers/sse/services/registration/api/v2/clients --cacert /ngfw/etc/ssl/connectorCA.pem
curl -v https://est.sco.cisco.com --cacert /ngfw/etc/ssl/connectorCA.pem

curl -v https://eventing-ingest.sse.itd.cisco.com --cacert /ngfw/etc/ssl/connectorCA.pem
curl -v https://mx01.sse.itd.cisco.com --cacert /ngfw/etc/ssl/connectorCA.pem

A verificação do certificado pode ser ignorada com este comando:

root@ftd01:~# curl -v -k https://api-sse.cisco.com
* Rebuilt URL to: https://api-sse.cisco.com/
* Trying x.x.x.66...
* Connected to api-sse.cisco.com (x.x.x.66) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=US; ST=California; L=San Jose; O=Cisco Systems, Inc.; CN=api -sse.cisco.com
* start date: 2019-12-03 20:57:56 GMT
* expire date: 2021-12-03 21:07:00 GMT
* issuer: C=US; O=HydrantID (Avalanche Cloud Corporation); CN=HydrantID S SL ICA G2
* SSL certificate verify result: self signed certificate in certificate c hain (19), continuing anyway.
> GET / HTTP/1.1
> Host: api-sse.cisco.com
> User-Agent: curl/7.44.0
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< Date: Wed, 08 Apr 2020 01:27:55 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 9
< Connection: keep-alive
< Keep-Alive: timeout=5
< ETag: "5e17b3f8-9"
< Cache-Control: no-store
< Pragma: no-cache
< Content-Security-Policy: default-src 'self'
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Strict-Transport-Security: max-age=31536000; includeSubdomains;

Observação: você recebe a mensagem 403 Forbidden, pois os parâmetros enviados do teste não são o que o SSE espera, mas isso prova o suficiente para validar a conectividade.

Verificar o estado do SSEConnector

Você pode verificar as propriedades do conector conforme mostrado.

# more /ngfw/etc/sf/connector.properties
registration_interval=180
connector_port=8989
connector_fqdn=api-sse.cisco.com

Para verificar a conectividade entre o SSConnector e o EventHandler, você pode usar esse comando, este é um exemplo de conexão inválida:

root@firepower:/etc/sf# netstat -anlp | grep EventHandler_SSEConnector.sock
unix 2 [ ACC ] STREAM LISTENING 3022791165 11204/EventHandler /ngfw/var/sf/run/EventHandler_SSEConnector.sock

No exemplo de uma conexão estabelecida, você pode ver que o status do fluxo está conectado:

root@firepower:/etc/sf# netstat -anlp | grep EventHandler_SSEConnector.sock
unix 2 [ ACC ] STREAM LISTENING 382276 7741/EventHandler /ngfw/var/sf/run/EventHandler_SSEConnector.sock
unix 3 [ ] STREAM CONNECTED 378537 7741/EventHandler /ngfw/var/sf/run/EventHandler_SSEConnector.soc

Verificar os dados enviados ao portal SSE e ao CTR

Para enviar eventos do dispositivo FTD para VER, uma conexão TCP precisa ser estabelecida com https://eventing-ingest.sse.itd.cisco.com Este é um exemplo de uma conexão não estabelecida entre o portal SSE e o FTD:

root@firepower:/ngfw/var/log/connector# lsof -i | grep conn
connector 60815 www 10u IPv4 3022789647 0t0 TCP localhost:8989 (LISTEN)
connector 60815 www 12u IPv4 110237499 0t0 TCP firepower.cisco.com:53426->ec2-100-25-93-234.compute-1.amazonaws.com:https (SYN_SENT)

Nos logs connector.log:

time="2020-04-13T14:34:02.88472046-05:00" level=error msg="[firepower.cisco.com][events.go:90 events:connectWebSocket] dial tcp x.x.x.246:443: getsockopt: connection timed out"
time="2020-04-13T14:38:18.244707779-05:00" level=error msg="[firepower.cisco.com][events.go:90 events:connectWebSocket] dial tcp x.x.x.234:443: getsockopt: connection timed out"
time="2020-04-13T14:42:42.564695622-05:00" level=error msg="[firepower.cisco.com][events.go:90 events:connectWebSocket] dial tcp x.x.x.246:443: getsockopt: connection timed out"
time="2020-04-13T14:47:48.484762429-05:00" level=error msg="[firepower.cisco.com][events.go:90 events:connectWebSocket] dial tcp x.x.x.234:443: getsockopt: connection timed out"
time="2020-04-13T14:52:38.404700083-05:00" level=error msg="[firepower.cisco.com][events.go:90 events:connectWebSocket] dial tcp x.x.x.234:443: getsockopt: connection timed out"

Observação: observe que os endereços IP exibidos x.x.x.246 e 1x.x.x.246 pertencem a https://eventing-ingest.sse.itd.cisco.com podem mudar, por isso a recomendação é permitir o tráfego para o Portal SSE com base na URL em vez de nos endereços IP.

Se essa conexão não for estabelecida, os eventos não serão enviados ao portal SSE. Este é um exemplo de uma conexão estabelecida entre o FTD e o portal SSE:

root@firepower:# lsof -i | grep conn
connector 13277   www   10u  IPv4 26077573      0t0  TCP localhost:8989 (LISTEN)
connector 13277   www   19u  IPv4 26077679      0t0  TCP x.x.x.200:56495->ec2-35-172-147-246.compute-1.amazonaws.com:https (ESTABLISHED)

Vídeo