De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
In dit document worden de stappen beschreven die nodig zijn voor de integratie, verificatie en probleemoplossing van Cisco XDR met Secure Firewall.
Er zijn twee methoden om Secure Firewall en XDR te integreren, en elke integratie biedt verschillende resultaten.
De eerste methode beschrijft hoe Secure Firewall, Security Services Exchange (SSX), Security Cloud Control, XDR-Analytics en XDR kunnen worden geïntegreerd om onderzoeken te verrijken.
De tweede methode beschrijft hoe Secure Firewall, SSX, Security Cloud Control, XDR-A, SAL Cloud en XDR kunnen worden geïntegreerd om incidenten te verrijken.
Cisco raadt kennis van de volgende onderwerpen aan:
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Rollen virtuele account:
Alleen de virtuele accountbeheerder of de slimme accountbeheerder heeft het voorrecht om de slimme account te koppelen aan de SSX-account.
Stap 1. Om de rol van de slimme account te valideren, navigeert u naar software.cisco.com en selecteert u onder het menu Beheer de optie Smart account beheren.
Stap 2. Om de gebruikersrol te valideren, navigeert u naar Gebruikers en valideert u dat onder Rollen de accounts zijn ingesteld op Virtual Account Administrator, zoals wordt weergegeven in de afbeelding.
Stap 3. Zorg ervoor dat de virtuele account die is geselecteerd om te koppelen op SSX de licentie voor de beveiligingsapparaten bevat als een account dat geen beveiligingslicentie bevat, is gekoppeld op SSX, de beveiligingsapparaten en de gebeurtenis niet op het SSX-portaal wordt weergegeven.
Stap 4. Navigeer naar Systeem > Licenties > Slimme licentie om te bevestigen dat de FMC is geregistreerd in het juiste virtuele account:
Stap 1. Wanneer u zich aanmeldt bij uw SSX-account, moet u uw slimme account koppelen aan uw SSX-account, daarvoor moet u op het pictogram Tools klikken en Smart/Virtual Accounts koppelen selecteren.
Zodra het account is gekoppeld, ziet u het slimme account met alle virtuele accounts erop.
Stap 1. Zorg ervoor dat deze URL's zijn toegestaan in uw omgeving:
Amerikaanse regio
api-sse.cisco.com
MX*.sse.itd.cisco.com
dex.sse.itd.cisco.com
eventing-ingest.sse.itd.cisco.com
registration.us.sse.itd.cisco.com
defenseorchestrator.com
edge.us.cdo.cisco.com
EU-regio
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
defenseorchestrator.eu
edge.eu.cdo.cisco.com
APJC-regio
Regio Australië:
api.aus.sse.itd.cisco.com
MX*.aus.sse.itd.cisco.com
dex.au.sse.itd.cisco.com
eventing-ingest.aus.sse.itd.cisco.com
registration.au.sse.itd.cisco.com
aus.cdo.cisco.com
Regio India:
api.in.sse.itd.cisco.com
MX*.in.sse.itd.cisco.com
dex.in.sse.itd.cisco.com
eventing-ingest.in.sse.itd.cisco.com
registration.in.sse.itd.cisco.com
in.cdo.cisco.com
Stap 2. Meld u aan bij het SSX-portaal met deze URL https://admin.sse.itd.cisco.com, navigeer naar Cloud Services en schakel beide opties Cisco XDR en Eventing in, zoals weergegeven in de afbeelding.
Stap 3. U kunt nu valideren dat u de apparaten kunt zien die zijn ingeschreven op SSX:
De Gebeurtenissen worden verzonden door de Secure Firewall-apparaten, navigeer naar de Gebeurtenissen op de SSX-portal om de gebeurtenissen te verifiëren die door de apparaten naar SSX zijn verzonden, zoals weergegeven in de afbeelding.
Stap 1. Zorg ervoor dat deze URL's zijn toegestaan in uw omgeving
Amerikaanse regio:
defenseorchestrator.com
EU-regio
defenseorchestrator.eu
APJC-regio
apjc.cdo.cisco.com
Regio Australië:
aus.cdo.cisco.com
Regio India:
in.cdo.cisco.com
Stap 2. Navigeer naar Security Cloud Control (link kan variëren afhankelijk van uw regio), dit leidt u naar uw Security Cloud Control-organisatie te selecteren.
Stap 3. Zodra u de juiste organisatie hebt geselecteerd, navigeert u naar Producten > Firewall, controleert u of uw apparaat er al is, zo niet, dan kunt u het aan boord nemen van Security Cloud Control (Cisco Defense Orchestrator), hiervoor klikt u onder Algemene inventaris op Alle apparaten bekijken.
Stap 4. Navigeer naar Beheer > Firewall Management Center, een lijst met uw in SCC geïntegreerde FMC's wordt weergegeven. Als u het Firewall Management Center niet ziet, klikt u op het pluspictogram.
Stap 4.1. Normaal gesproken worden beveiligde firewalls automatisch aan boord geplaatst, zo niet, selecteer dan het apparaat dat u aan boord wilt hebben (FTD) en de gewenste onboarding-methode.
Stap 4.2. Klik in het gedeelte Beveiligingsapparaten op het pluspictogram en selecteer Onboard Secure Firewall Device en uw voorkeur
Stap 5. Zodra u uw apparaten in Security Cloud Control aan boord hebt, kunt u deze in de inventaris visualiseren.
Stap 6. Zorg ervoor dat uw CDO-organisatie is gekoppeld aan uw SSX-organisatie, blader hiervoor naar Security Services Exchange, klik op het pictogram Tools Menu en klik op CDO-account koppelen.
Stap 1. Navigeer in het Secure Firewall Management Center naar Integratie > SecureX
Stap 2. Kies het juiste gebied en klik op SecureX inschakelen.
Stap 3. Nadat u op SecureX inschakelen hebt geklikt, wordt u doorverwezen naar de verificatiepagina van Cisco Defense Orchestrator (die gebruikmaakt van de aanmeldingsprocedure voor de beveiligingscloud) en klikt u op Doorgaan naar Cisco SSO.
Opmerking:
Vanaf 7.6.x en hoger met Cisco XDR.
Stap 1. Navigeer in uw Secure Firewall Management Center naar Integratie > Cisco Security Cloud
Stap 2. Kies de juiste regio en klik op Cisco Security Cloud inschakelen.
Stap 3. Nadat u op Cisco Security Cloud inschakelen hebt geklikt, wordt u doorverwezen naar de verificatiepagina van Cisco Defense Orchestrator (die gebruikmaakt van de aanmeldingsprocedure voor de beveiligingscloud) en klikt u op Doorgaan naar Cisco SSO.
Stap 4. U kunt een reeds bestaande Security Cloud Control Tenant selecteren of een nieuwe maken.
Stap 5. Selecteer de juiste huurder en zorg ervoor dat de code die u op deze pagina ontvangt overeenkomt met de code die u in FMC ontvangt. Klik op FMC autoriseren als deze overeenkomt.
Stap 6. Voer uw aanmeldingsreferenties voor Security Cloud in en autoriseer de integratie, zodra deze is voltooid, en bevestig dat FMC toestemming heeft gekregen om zich te registreren bij Cisco Security Cloud.
Stap 7. Nadat de autorisatie is voltooid, kunt u teruggaan naar uw FMC en selecteren welke gebeurtenissen u naar de cloud wilt verzenden en zodra u dit hebt voltooid, klikt u op Opslaan.
Stap 8. U kunt ervoor kiezen om SecureX Orchestration (XDR Automate) in te schakelen
Stap 9. Navigeer naar XDR > Beheer > Op locatie en zoek naar uw apparaten, ze moeten automatisch worden geregistreerd.
Stap 10. Navigeer naar XDR > Beheer > Integraties en schakel de Secure Firewall Integration in.
Stap 10.1. Wijs een naam toe aan uw integratie en klik op +Toevoegen.
Met deze integratie kunt u Investigations verrijken binnen XDR.
Opmerking: voor een naadloze integratie tussen Secure Firewall, XDR, Cisco Defense Orchestrator (CDO), Security Services Exchange (SSX) en Security Analytics and Logging (SAL) is handmatige toewijzing vereist. Dit proces omvat het contact opnemen met Cisco TAC om de nodige configuraties en toewijzingen uit te voeren.
Stap 1. Uw CDO-account moet een Security Analytics- en Logging-licentie hebben om gebeurtenissen door te sturen naar Cisco XDR.
Stap 2. Gebruik de eerder beschreven stappen om uw apparaten te registreren in SSX en Security Cloud Control.
Stap 3. Als u klaar bent, neem dan contact op met TAC met deze gegevens en verzoek om Security Cloud Control / SAL te koppelen aan XDR Analytics.
Stap 4. Zorg ervoor dat uw CDO-account is gekoppeld aan XDR Analytics Portal.
Voordat u uw CDO-portal koppelt aan XDR Analytics, ziet het er als volgt uit:
Nadat de koppeling is voltooid, ziet u de optie om naar uw XDR Analytics-portal te navigeren.
Stap 5. Zodra uw XDR Analytics-account is gekoppeld aan uw Security Cloud Control Portal (CDO), moet u ervoor zorgen dat uw XDR Analytics is geïntegreerd met XDR, hiervoor moet u in XDR Analytics navigeren naar Instellingen > Integraties > XDR, zoeken naar XDR-integratie en ervoor zorgen dat er een groene controle is en dat de Integratiemodule naar uw juiste XDR Org wijst.
Valideren dat de beveiligde firewalls gebeurtenissen genereren (malware of indringing), zodat indringingsgebeurtenissen kunnen navigeren naar Analyse >Bestanden >Malware-gebeurtenissen, voor indringingsgebeurtenissen, navigeert u naar Analyse > Indringing > Gebeurtenissen.
De gebeurtenissen valideren die zijn geregistreerd op het SSX-portaal zoals vermeld in de sectie Apparaten registreren bij SSX stap 4.
Controleer of de informatie wordt weergegeven op het Cisco XDR-dashboard of controleer de API-logs zodat u de reden voor een mogelijke API-fout kunt zien.
Bevestig dat alle huurders correct aan elkaar zijn gekoppeld, open een TAC-zaak als u problemen hebt en geef deze details op:
U kunt algemene verbindingsproblemen detecteren in het bestand action_queue.log. In geval van een storing kunt u dergelijke logs in het bestand zien:
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.
In dit geval betekent afsluitcode 28 een time-out voor de werking en moeten we de connectiviteit met internet controleren. U moet ook afsluitcode 6 zien, wat betekent dat er problemen zijn met de DNS-resolutie
Stap 1. Controleer of de connectiviteit goed werkt.
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'
Deze uitvoer laat zien dat het apparaat de URL https://api-sse.cisco.com niet kan oplossen, in dit geval moeten we valideren dat de juiste DNS-server is geconfigureerd, deze kan worden gevalideerd met een nslookup van de deskundige CLI:
root@ftd01:~# nslookup api-sse.cisco.com
;; connection timed out; no servers could be reached
Deze uitvoer laat zien dat de geconfigureerde DNS niet wordt bereikt. Gebruik de opdracht Netwerk weergeven om de DNS-instellingen te bevestigen:
> 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
In dit voorbeeld is de verkeerde DNS-server gebruikt, u kunt de DNS-instellingen wijzigen met deze opdracht:
> configure network dns x.x.x.11
Nadat deze connectiviteit opnieuw kan worden getest en deze keer is de verbinding succesvol.
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;
Zowel FMC als Secure Firewall hebben een verbinding met de SSX-URL's op hun beheerinterface nodig om de verbinding te testen. Voer deze opdrachten in op de Firepower CLI met hoofdtoegang:
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
De certificaatcontrole kan worden omzeild met deze opdracht:
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;
Opmerking: u krijgt het 403 Verboden bericht omdat de parameters die vanuit de test worden verzonden niet zijn wat SSX verwacht, maar dit blijkt voldoende om de connectiviteit te valideren.
U kunt de eigenschappen van de connector controleren, zoals wordt weergegeven.
# more /ngfw/etc/sf/connector.properties
registration_interval=180
connector_port=8989
connector_fqdn=api-sse.cisco.com
Om de connectiviteit tussen de SSConnector en de EventHandler te controleren kunt u deze opdracht gebruiken, dit is een voorbeeld van een slechte verbinding:
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
In het voorbeeld van een gevestigde verbinding kunt u zien dat de stream-status is verbonden:
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
Om gebeurtenissen van het Secure Firewall-apparaat naar SSX te verzenden, moet een TCP-verbinding tot stand worden gebracht met https://eventing-ingest.sse.itd.cisco.com. Dit is een voorbeeld van een verbinding die niet tot stand is gebracht tussen het SSX-portaal en de 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)
In de 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"
Opmerking: Merkte op dat de IP-adressen weergegeven x.x.x.246 en 1x.x.x.246 behoren tot https://eventing-ingest.sse.itd.cisco.com moet veranderen, dit is waarom de aanbeveling is om het verkeer naar SSX Portal op basis van URL in plaats van IP-adressen.
Als deze verbinding niet tot stand is gebracht, worden de gebeurtenissen niet naar het SSX-portaal verzonden. Dit is een voorbeeld van een vaste verbinding tussen de beveiligde firewall en het SSX-portaal:
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)
Als uw apparaat niet kan worden ingeschreven in Security Cloud Control, moet u ervoor zorgen dat het verbinding heeft met de juiste CDO-tenant.
Om de juiste URL te verifiëren, navigeert u naar Beheer > Firewall Management Center, selecteert u Cloud Delivered FMC, rechtsboven in het scherm ziet u de hostnaam.
admin@MexAmpFTD:~$ nc -vz xxxxxxxx.app.us.cdo.cisco.com 443
Connection to xxxxxxxx.app.us.cdo.cisco.com 443 port [tcp/https] succeeded!
Als u nog steeds problemen ondervindt om verbinding te maken met CDO, moet u ervoor zorgen dat poort 8305 is geopend. Dit is een voorbeeld van een verbindingsprobleem.
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)
U kunt controleren bij welke SSX-tenant uw FMC is ingeschreven.
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:~$
Als de SSX-tenant onjuist is, moet u de stappen opnieuw uitvoeren om uw apparaten in SSX in te schrijven
Als de SSX-huurder correct is, maar de CDO-huurder niet is gekoppeld aan de juiste SSX-organisatie, neem dan contact op met TAC met deze gegevens:
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
2.0 |
06-May-2025
|
Bijwerken met beide methoden beschikbaar voor de XDR - Secure Firewall-integratie. |
1.0 |
30-Jul-2023
|
Eerste vrijgave |