Integración y resolución de problemas de SecureX con Firepower Threat Defense (FTD)

Introducción

Este documento describe los pasos necesarios para integrar, verificar y resolver problemas de SecureX con Firepower Firepower Firepower Threat Defense (FTD). 

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Firepower Management Center (FMC)
• Firepower Threat Defense (FTD)
• Virtualización opcional de imágenes 

Componentes Utilizados

• Firepower Threat Defense (FTD) - 6.5
• Firepower Management Center (FMC) - 6.5
• Intercambio de servicios de seguridad (SSE)
• SecureX
• Portal de licencias inteligentes

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. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Configurar

Licencias

Funciones de cuenta virtual: 

Sólo el administrador de cuenta virtual o el administrador de cuenta inteligente tienen el privilegio de vincular la cuenta inteligente con la cuenta SSE.

Paso 1. Para validar la función de cuenta inteligente, navegue a software.cisco.com y en el menú Administración, seleccione Administrar cuenta inteligente.

Paso 2. Para validar la función de usuario, navegue hasta Usuarios, y valide que en Funciones las cuentas estén configuradas para tener Administrador de cuenta virtual, como se muestra en la imagen.

Paso 3. Asegúrese de que la cuenta virtual seleccionada para vincular en SSE contenga la licencia para los dispositivos de seguridad si una cuenta que no contiene la licencia de seguridad está vinculada en SSE, los dispositivos de seguridad y el evento no aparecen en el portal SSE.

Paso 4. Para validar que el FMC se registró en la cuenta virtual correcta, navegue hasta Sistema>Licencias>Licencia inteligente:

Enlace sus cuentas a SSE y registre los dispositivos.

Paso 1. Cuando inicia sesión en su cuenta SSE, debe vincular su cuenta inteligente a su cuenta SSE, para lo cual debe hacer clic en el icono de herramientas y seleccionar Link Accounts.

Una vez que la cuenta está vinculada, verá la cuenta inteligente con todas las cuentas virtuales que contiene.

Registre los dispositivos en SSE

Paso 1. Asegúrese de que estas URL están permitidas en su entorno:

Región de EE. UU.

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

Región de la UE

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

Región APJ

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

Paso 2. Inicie sesión en el portal SSE con esta URL https://admin.sse.itd.cisco.com, acceda a Cloud Services y habilite ambas opciones Eventing y Cisco SecureX Threat Response, como se muestra en la siguiente imagen:

 Paso 3. Inicie sesión en Firepower Management Center y navegue hasta System>Integration>Cloud Services, habilite Cisco Cloud Event Configuration y seleccione los eventos que desea enviar a la nube:

Paso 4. Puede volver al portal SSE y validar que ahora puede ver los dispositivos inscritos en SSE:

Los eventos son enviados por los dispositivos FTD, naveguen hasta Eventos en el portal SSE para verificar los eventos enviados por los dispositivos a SSE, como se muestra en la imagen:

Configurar paneles personalizados en SecureX

Paso 1. Para crear el Panel, haga clic en el icono + Nuevo Panel, seleccione el nombre y la ficha que desea utilizar para el Panel, como se muestra en la imagen:

Paso 2. Después de esto puede ver la información del panel cumplimentada desde SSE, puede seleccionar cualquiera de las amenazas detectadas y el portal SSE se inicia con el filtro Tipo de evento en él:

Verificación

Validar que los FTD generan eventos (malware o intrusión), para los eventos de intrusión navegue hasta Análisis >Archivos>Eventos de malware, para eventos de intrusión navegue hasta Análisis>Intrusión>Eventos.

Validar los eventos se registran en el portal SSE como se menciona en la sección Registrar los dispositivos en SSE, paso 4.

Valide que la información se muestre en el panel SecureX o verifique los registros de API para que pueda ver el motivo de una posible falla de la API.

Troubleshoot

Detectar problemas de conectividad

Puede detectar problemas de conectividad genérica desde el archivo action_queue.log. En caso de error, puede ver dichos registros presentes en el archivo:

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.

En este caso, el código de salida 28 significa que el tiempo de espera de la operación ha expirado y debemos comprobar la conectividad a Internet. También puede ver el código de salida 6, lo que significa problemas con la resolución de DNS

Problemas de conectividad debido a la resolución de DNS

Paso 1. Compruebe que la conectividad funciona correctamente.

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'

El resultado anterior muestra que el dispositivo no puede resolver la URL https://api-sse.cisco.com, en este caso, necesitamos validar que el servidor DNS adecuado está configurado, se puede validar con una nslookup de la CLI experta:

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

El resultado anterior muestra que el DNS configurado no se alcanza, para confirmar la configuración DNS, utilice el 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

En este ejemplo se utilizó el servidor DNS incorrecto, puede cambiar la configuración DNS con este comando:

> configure network dns x.x.x.11

Después de que esta conectividad se pueda probar de nuevo y esta vez, la conexión se realiza correctamente.

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 en el portal SSE

Tanto FMC como FTD necesitan una conexión a las URL SSE en su interfaz de administración, para probar la conexión, ingrese estos comandos en la CLI de Firepower con acceso raíz:

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

La verificación del certificado se puede omitir con 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;

Nota: Recibe el mensaje 403 Forbidden, ya que los parámetros enviados desde la prueba no son lo que espera SSE, pero esto demuestra lo suficiente para validar la conectividad.

Verificación del estado SSEConnector

Puede verificar las propiedades del conector como se muestra.

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

Para verificar la conectividad entre el SSConnector y el EventHandler puede utilizar este comando, este es un ejemplo de una conexión incorrecta:

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

En el ejemplo de una conexión establecida, puede ver que el estado de la secuencia 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 los datos enviados al portal SSE y al CTR

Para enviar eventos desde el dispositivo FTD a SEE se necesita establecer una conexión TCP con https://eventing-ingest.sse.itd.cisco.com Este es un ejemplo de una conexión no establecida entre el portal SSE y el 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)

En los registros 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"

Nota: Al observar que las direcciones IP mostradas x.x.x.246 y 1x.x.x.246 pertenecen a https://eventing-ingest.sse.itd.cisco.com pueden cambiar, esta es la razón por la que la recomendación es permitir el tráfico al portal SSE basado en URL en lugar de direcciones IP.

Si no se establece esta conexión, los eventos no se envían al portal SSE. Este es un ejemplo de una conexión establecida entre el FTD y el 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)

Video