Contents

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Configurar

Licenciamento

Vincule suas contas ao SSE e registre os dispositivos.

Método 1 (meia integração): Enriquecer as investigações

Registrar os dispositivos no SSE

Introdução

Este documento descreve as etapas necessárias para integrar, verificar e solucionar problemas do Cisco XDR com Secure Firewall.

Há dois métodos para integrar o Secure Firewall e o XDR, e cada integração fornece resultados diferentes.

O primeiro método descreve como integrar Secure Firewall, Security Services Exchange (SSX), Security Cloud Control, XDR-Analytics e XDR para enriquecer as investigações.

O segundo método descreve como integrar Secure Firewall, SSX, Security Cloud Control, XDR-A, SAL Cloud e XDR, para enriquecer incidentes.

Pré-requisitos

Requisitos

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

- Firepower Management Center (FMC)

- Firewall seguro

- Virtualização opcional de imagens

- Cisco Defense Orchestrator

- Security Services Exchange (Troca de serviços de segurança)

- Controle de nuvem de segurança

Componentes Utilizados

- Firewall seguro - 7.2

- Firepower Management Center (FMC) - 7.2

- Troca de serviços de segurança (SSX)

- Cisco XDR

- Portal Smart License

- Cisco Defense Orchestrator

- Controle de nuvem de segurança

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 o Administrador da Virtual Account, como mostrado na imagem.

Etapa 3. Verifique se a Virtual Account selecionada para ser vinculada 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, os dispositivos de segurança e o evento não forem exibidos no portal do SSE.

Etapa 4. Para validar 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.

Método 1 (meia integração): Enriquecer as investigações

Registrar os dispositivos no SSE

Etapa 1. Certifique-se de que estes URLs sejam permitidos em seu ambiente:

Região dos EUA

- api-sse.cisco.com

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

- mx*.sse.itd.cisco.com

- dex.sse.itd.cisco.com

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

- registration.us.sse.itd.cisco.com

Região da UE

- api.eu.sse.itd.cisco.com

- mx*.eu.sse.itd.cisco.com

- dex.eu.sse.itd.cisco.com

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

- registration.eu.sse.itd.cisco.com

Região da APJC

- api.apj.sse.itd.cisco.com

- mx*.apj.sse.itd.cisco.com

- dex.apj.sse.itd.cisco.com

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

- registration.apj.sse.itd.cisco.com

Etapa 2. Faça login no portal SSE com este URL https://admin.sse.itd.cisco.com, navegue para Serviços em nuvem e habilite as opções Eventual e resposta à ameaça do Cisco XDR, como mostrado na imagem a seguir:

Etapa 3. Você pode validar que agora pode ver os dispositivos inscritos no SSE:

Os eventos são enviados pelos dispositivos do Secure Firewall, navegue para os Eventos no portal SSX para verificar os eventos enviados pelos dispositivos para o SSX, como mostrado na imagem:

Registre os dispositivos no Security Cloud Control (SCC/CDO)

Etapa 1. Certifique-se de que esses URLS sejam permitidos em seu ambiente

Região dos EUA:

- defenseorchestrator.com

- edge.us.cdo.cisco.com

Região da UE

- defenseorchestrator.eu

- edge.eu.cdo.cisco.com

Região da APJC

- apjc.cdo.cisco.com

- edge.apjc.cdo.cisco.com

Etapa 2. Navegue até Security Cloud Control (o link pode variar dependendo da sua região). Isso o direciona para selecionar sua Security Cloud Control Organization.

Etapa 3. Depois de selecionar a organização apropriada, navegue até Products>Firewall, verifique se o dispositivo já está lá, caso contrário, você poderá Onboard it to Security Cloud Control (Cisco Defense Orchestrator); para isso, em Inventário geral, clique em Visualizar todos os dispositivos.

Etapa 4. Navegue até Administration>Firewall Management Center, uma lista de seus FMCs integrados no SCC é apresentada. Se você não vir seu Firewall Management Center, clique no ícone Plus.

Etapa 4.1. Normalmente, os firewalls seguros são integrados automaticamente. Caso contrário, selecione o dispositivo que deseja integrar (FTD) e o método de integração de sua preferência.

Etapa 4.2. Na seção Security Devices, clique no ícone Plus e selecione Onboard Secure Firewall Device e seu dispositivo

Etapa 5. Depois de integrar seus dispositivos no Security Cloud Control, você poderá visualizá-lo no inventário.

Etapa 6. Certifique-se de que sua organização CDO está vinculada à sua organização SSX, para isso, navegue para Security Services Exchange, clique no ícone do menu Ferramentas, clique em Vincular conta CDO.

Integre o Secure Firewall 7.2.x com o Cisco XDR

Etapa 1. No Secure Firewall Management Center, navegue até Integration>SecureX

Etapa 2. Escolha a região direita e clique em Enable SecureX.

Etapa 3.  Depois de clicar em Enable SecureX (Habilitar SecureX), você será redirecionado para a página de autenticação do Cisco Defense Orchestrator (que aproveita o Security Cloud Sign On), depois clique em Continue to Cisco SSO (Continuar para o Cisco SSO).

Etapa 4. Você pode selecionar um Locatário do Security Cloud Control preexistente ou criar um novo.

Etapa 5. Selecione o Locatário apropriado e verifique se o código que você está recebendo nesta página corresponde ao código que você está recebendo no FMC. Se eles corresponderem, clique em Autorizar FMC.

Etapa 6. Insira suas credenciais de Logon do Security Cloud e autorize a integração. Após a conclusão, uma confirmação de que o FMC foi autorizado a se registrar no Cisco Security Cloud é apresentada.

Etapa 7. Após a autorização ser concluída, você pode navegar de volta para o FMC e selecionar quais eventos deseja enviar para a nuvem. Depois de concluir essa etapa, clique em Salvar.

Etapa 8. Você pode optar por ativar a orquestração SecureX (XDR Automate)

Etapa 9. Navegue até XDR>Administration>On Premises Appliance e procure seus equipamentos, eles devem ser registrados automaticamente.

Etapa 10. Navegue até XDR>Administração>Integrações e habilite a Integração do Firewall Seguro.

Etapa 10.1. Atribua um nome à sua integração, clique em +Adicionar.

Essa integração permite enriquecer as Investigações no XDR.

Método 2 (Integração total): Enriquecer Incidentes no XDR

Etapa 1. Sua conta CDO deve ter uma licença Security Analytics and Logging para encaminhar eventos para o Cisco XDR.

Etapa 2. Use as etapas descritas anteriormente para registrar seus dispositivos no SSX e no Security Cloud Control.

Etapa 3. Quando terminar, entre em contato com o TAC e solicite o link Security Cloud Control/SAL (Controle de nuvem de segurança/SAL) para XDR Analytics.

- ID do locatário CDO

- Nome do CDO

- ID da Org XDR

- ID do Locatário SSE

- Nome SSE

- ID da Org. SCA

Etapa 4. Verifique se sua conta CDO está vinculada ao Portal de análise XDR.

Antes de vincular seu portal CDO ao XDR Analytics, ele se parece com o seguinte:

Depois que o link for concluído, você poderá ver a opção para navegar para o Portal de análise XDR.

Etapa 5. Depois que a conta do XDR Analytics estiver vinculada ao Security Cloud Control Portal (CDO), você precisará verificar se o XDR Analytics está integrado ao XDR. Para isso, no XDR Analytics, navegue até Settings>Integrations>XDR, procure XDR Integration e verifique se há uma verificação verde e se o módulo Integration aponta para a organização XDR correta.

Verificar

Valide se os Secure Firewalls geram eventos (malware ou invasão), para eventos de invasão, navegue até Análise>Arquivos>Eventos de malware, para eventos de intrusão, navegue para Análise>Invasão>Eventos.

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 do Cisco XDR ou verifique os logs de API para que você possa ver o motivo de uma possível falha de API.

Verifique se todos os locatários estão corretamente vinculados, se você tiver problemas, abra um caso TAC e forneça estes detalhes:

- ID do locatário CDO

- Nome do CDO

- ID da Org XDR

- ID do Locatário SSE

- Nome SSE

- ID da Org. SCA

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 precisamos verificar a conectividade com a Internet. Você também deve 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 está funcionando 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'

Esta saída mostra que o dispositivo não pode resolver o URL https://api-sse.cisco.com; neste 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

Esta saída 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 Secure Firewall 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;

Note: 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 ser 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 Secure Firewall para SEE, 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 Secure Firewall:

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"

Note: Observado que os endereços IP exibidos x.x.x.246 e 1x.x.x.246 pertencem a https://eventing-ingest.sse.itd.cisco.com devem ser alterados, é por isso que 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 Secure Firewall 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)

O dispositivo (FTD) não pode ser inscrito no Security Cloud Control

Se seu dispositivo não puder ser inscrito no Security Cloud Control, verifique se ele tem conectividade com o locatário de CDO apropriado.

Para verificar o URL correto, navegue para Administração>Centro de gerenciamento de firewall, selecione FMC fornecido pela nuvem. No lado superior direito da tela, você pode ver o nome do host.

admin@MexAmpFTD:~$ nc -vz xxxxxxxx.app.us.cdo.cisco.com 443

Connection to xxxxxxxx.app.us.cdo.cisco.com 443 port [tcp/https] succeeded!

Se você ainda estiver enfrentando problemas para se conectar ao CDO, verifique se a porta 8305 está aberta, este é um exemplo de um problema de conexão.

admin@AMP-DMZ-FPR:~$ sudo tail /ngfw/var/log/messages

Jan 25 18:48:56 AMP-DMZ-FPR SF-IMS[20448]: [1465] sftunneld:sf_peers [INFO] Peer xxxxxxxx.app.us.cdo.cisco.com needs a single connection

Jan 25 18:48:56 AMP-DMZ-FPR SF-IMS[20448]: [1465] sftunneld:sf_ssl [INFO] Connect to xxxxxxxx.app.us.cdo.cisco.com on port 8305 - management0

Jan 25 18:48:56 AMP-DMZ-FPR SF-IMS[20448]: [1465] sftunneld:sf_ssl [INFO] Initiate connection using resolved_ip_list having [2] entries on list [1] (via management0)

Jan 25 18:48:56 AMP-DMZ-FPR SF-IMS[20448]: [1465] sftunneld:sf_ssl [INFO] Initiate IPv6 type connection

Jan 25 18:48:56 AMP-DMZ-FPR SF-IMS[20448]: [1465] sftunneld:sf_ssl [INFO] Initiate IPv4 type connection

Jan 25 18:48:56 AMP-DMZ-FPR SF-IMS[20448]: [1465] sftunneld:sf_ssl [INFO] Initiate IPv4 connection from resolved_ip_list to x.x.x.51 (via management0)

Jan 25 18:48:56 AMP-DMZ-FPR SF-IMS[20448]: [1465] sftunneld:sf_ssl [INFO] Initiating IPv4 connection to x.x.x.51:8305/tcp

Jan 25 18:48:56 AMP-DMZ-FPR SF-IMS[20448]: [1465] sftunneld:sf_ssl [INFO] Wait to connect to 8305 (IPv4): x.x.x.51

Jan 25 18:48:56 AMP-DMZ-FPR SF-IMS[20448]: [1465] sftunneld:sf_ssl [INFO] Connect to x.x.x.51 failed on port 8305 socket 8 (Connection refused)

Dispositivo inscrito no locatário SSX incorreto

Você pode verificar em qual locatário SSX seu FMC está inscrito.

admin@fmc01:~$ curl localhost:8989/v1/contexts/default/tenant

{"registeredTenantInfo":{"companyId":"689xxxxx-eaxx-5bxx-b1xx-a7662axxxxx","companyName":"XDR BETA - TAC Org","id":"7487917c-2ead-471b-b521-caxxxxxxxxxa","spId":"SXSO"},"tenantInfo":[{"companyId":"689xxxxx-eaxx-5bxx-b1xx-a7662axxxxx","companyName":"XDR BETA - TAC Org","id":"7487917c-2ead-471b-b521-caxxxxxxxxxa","spId":"SXSO"}]}admin@fmc01:~$

Se o locatário do SSX estiver incorreto, você precisará refazer as etapas para inscrever seus dispositivos no SSX

Se o locatário do SSX estiver correto, mas o locatário do CDO não estiver vinculado à organização do SSX apropriada, entre em contato com o TAC com estes detalhes:

- ID do locatário SSX

- ID do locatário CDO