Integration und Fehlerbehebung bei Cisco XDR mit Secure Firewall
Inhalt
Einleitung
In diesem Dokument werden die erforderlichen Schritte zur Integration, Überprüfung und Fehlerbehebung von Cisco XDR mit Secure Firewall beschrieben.
Es gibt zwei Methoden zur Integration von Secure Firewall und XDR, und jede Integration führt zu unterschiedlichen Ergebnissen.
Die erste Methode beschreibt die Integration von Secure Firewall, Security Services Exchange (SSX), Security Cloud Control, XDR-Analytics und XDR zur Bereicherung von Untersuchungen.
Die zweite Methode beschreibt die Integration von Secure Firewall, SSX, Security Cloud Control, XDR-A, SAL Cloud und XDR zur Optimierung von Vorfällen.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
- Cisco Firewall Management Center (FMC)
- Cisco Secure Firewall - Schutz vor Bedrohungen
- Optionale Bildvirtualisierung
- Cisco Defense Orchestrator
- Austausch von Security Services
- Cloud-Sicherheitskontrolle
Verwendete Komponenten
- Sichere Firewall - 7.2
- FirePOWER Management Center (FMC) - 7.2
- Security Services Exchange (SSX)
- Cisco XDR
- Smart License-Portal
- Cisco Defense Orchestrator
- Cloud-Sicherheitskontrolle
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Konfigurieren
Lizenzierung
Virtuelle Kontorollen:
Nur der Virtual Account-Administrator oder der Smart Account-Administrator verfügt über die Berechtigung, das Smart Account mit dem SSX-Konto zu verknüpfen.
Schritt 1: Um die Smart Account-Rolle zu validieren, navigieren Sie zu software.cisco.com, und wählen Sie im Administrationsmenü die Option Smart Account verwalten aus.
Schritt 2: Um die Benutzerrolle zu validieren, navigieren Sie zu Benutzer, und überprüfen Sie, ob die Konten unter Rollen als Virtual Account Administrator eingerichtet sind, wie im Bild gezeigt.
Schritt 3: Stellen Sie sicher, dass das virtuelle Konto, das auf SSX verknüpft werden soll, die Lizenz für die Sicherheitsgeräte enthält, wenn ein Konto, das die Sicherheitslizenz nicht enthält, auf SSX, den Sicherheitsgeräten und dem Ereignis verknüpft ist, das nicht im SSX-Portal angezeigt wird.
Schritt 4: Um zu überprüfen, ob das FMC für das richtige Virtual Account registriert wurde, navigieren Sie zu System > Licenses > Smart License:
Verknüpfen Sie Ihre Konten mit SSX, und registrieren Sie die Geräte.
Schritt 1. Wenn Sie sich bei Ihrem SSX-Konto anmelden, müssen Sie Ihr Smart Account mit Ihrem SSX-Konto verknüpfen. Dazu müssen Sie auf das Symbol Tools klicken und Smart/Virtual Accounts verknüpfen auswählen.
Sobald das Konto verknüpft ist, wird das Smart Account mit allen virtuellen Konten angezeigt.
Methode 1 (Halbintegration): Untersuchungen anreichern
Registrieren der Geräte für SSX
Schritt 1: Stellen Sie sicher, dass die folgenden URLs in Ihrer Umgebung zulässig sind:
Region USA
-
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-Region
-
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
Region 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
- apj.cdo.cisco.com
- edge.apj.cdo.cisco.com
Region Australien:
-
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
Region Indien:
-
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
Schritt 2: Melden Sie sich mit folgender URL beim SSX-Portal an: https://admin.sse.itd.cisco.com, navigieren Sie zu Cloud Services, und aktivieren Sie die beiden Optionen Cisco Cisco XDR und Eventing, wie im Bild gezeigt.
Schritt 3. Sie können überprüfen, dass Sie nun die Geräte sehen können, die auf SSX registriert sind:
Die Ereignisse werden von den Secure Firewall-Geräten gesendet. Navigieren Sie zu den Ereignissen im SSX-Portal, um die Ereignisse zu überprüfen, die von den Geräten an SSX gesendet wurden, wie im Bild gezeigt.
Registrieren der Geräte bei Security Cloud Control (SCC/CDO)
Schritt 1: Stellen Sie sicher, dass diese URLs in Ihrer Umgebung zulässig sind.
Region USA:
-
defenseorchestrator.com
- edge.us.cdo.cisco.com
EU-Region
-
defenseorchestrator.eu
- edge.eu.cdo.cisco.com
Region APJC
-
apjc.cdo.cisco.com
- edge.apjc.cdo.cisco.com
Region Australien:
-
aus.cdo.cisco.com
Region Indien:
-
in.cdo.cisco.com
Schritt 2: Navigieren Sie zu Security Cloud Control (der Link kann je nach Region variieren), und wählen Sie Ihre Security Cloud Control Organization aus.
Schritt 3: Nachdem Sie die entsprechende Organisation ausgewählt haben, navigieren Sie zu Produkte > Firewall, überprüfen Sie, ob Ihr Gerät bereits vorhanden ist, wenn nicht, können Sie es in Security Cloud Control (Cisco Defense Orchestrator) einbinden, für diese, unter Gesamtbestand, klicken Sie auf Alle Geräte anzeigen.
Schritt 4. Navigieren Sie zu Administration > Firewall Management Center. Eine Liste Ihrer in SCC integrierten FMCs wird angezeigt. Wenn Ihr Firewall Management Center nicht angezeigt wird, klicken Sie auf das Pluszeichen.
Schritt 4.1: Normalerweise werden sichere Firewalls automatisch integriert. Wenn dies nicht der Fall ist, wählen Sie das zu integrierende Gerät (FTD) und Ihre bevorzugte Methode für die Integration aus.
Schritt 4.2. Klicken Sie im Abschnitt "Sicherheitsgeräte" auf das Pluszeichen, und wählen Sie Onboard Secure Firewall Device und Ihre bevorzugte
Schritt 5: Sobald Sie Ihre Geräte in Security Cloud Control integriert haben, können Sie sie im Inventar visualisieren.
Schritt 6: Vergewissern Sie sich, dass Ihre CDO-Organisation mit Ihrer SSX-Organisation verknüpft ist. Navigieren Sie dazu zu Security Services Exchange, klicken Sie auf das Symbol "Tools Menu" (Menü), und klicken Sie auf Link CDO Account (CDO-Konto verknüpfen).
Integration einer sicheren Firewall
7.2.x bis 7.4.x mit Cisco XDR
Schritt 1: Navigieren Sie in Ihrem Secure Firewall Management Center zu Integration > SecureX
Schritt 2: Wählen Sie den richtigen Bereich aus, und klicken Sie auf SecureX aktivieren.
Schritt 3: Wenn Sie auf "SecureX aktivieren" klicken, werden Sie zur Cisco Defense Orchestrator-Authentifizierungsseite weitergeleitet (die die Anmeldung bei der Security Cloud nutzt). Klicken Sie auf "Weiter zu Cisco SSO".
Schritt 4: Sie können entweder einen bereits vorhandenen Security Cloud Control-Tenant auswählen oder einen neuen erstellen.
Schritt 5: Wählen Sie den entsprechenden Tenant aus, und stellen Sie sicher, dass der Code, den Sie auf dieser Seite erhalten, mit dem Code übereinstimmt, den Sie in FMC empfangen. Wenn dieser übereinstimmt, klicken Sie auf FMC autorisieren.
Schritt 6: Geben Sie Ihre Anmeldeinformationen für die Security Cloud ein, und autorisieren Sie die Integration. Nach Abschluss des Vorgangs wird eine Bestätigung angezeigt, dass FMC zur Registrierung bei Cisco Security Cloud berechtigt war.
Schritt 7: Nachdem die Autorisierung abgeschlossen ist, können Sie zu Ihrem FMC zurückkehren und auswählen, welche Ereignisse Sie an die Cloud senden möchten. Klicken Sie anschließend auf Speichern.
Schritt 8. Sie können wählen, um SecureX Orchestration (XDR Automate) zu aktivieren
Schritt 9. Navigieren Sie zu XDR > Administration > On Premises Appliance und suchen Sie nach Ihren Appliances, sie müssen automatisch registriert werden.
Schritt 10: Navigieren Sie zu XDR > Administration > Integrations und aktivieren Sie die sichere Firewall-Integration.
Schritt 10.1. Weisen Sie der Integration einen Namen zu, und klicken Sie auf +Hinzufügen.
Diese Integration ermöglicht es Ihnen, Untersuchungen innerhalb von XDR zu bereichern.
Methode 2 (vollständige Integration): Anreichern Incidentes in XDR
Schritt 1: Ihr CDO-Konto muss über eine Security Analytics- und Protokollierungslizenz verfügen, um Ereignisse an Cisco XDR weiterzuleiten.
Schritt 2: Verwenden Sie die zuvor beschriebenen Schritte, um Ihre Appliances in SSX und Security Cloud Control zu registrieren.
Schritt 3: Wenden Sie sich nach Abschluss an das TAC mit diesen Informationen, und fordern Sie an, Security Cloud Control/SAL mit XDR Analytics zu verknüpfen.
- CDO-Tenant-ID
- CDO-Name
- XDR-Org.-ID
- SSX-Tenant-ID
- SSX-Name
- SCA-Org.-ID
Schritt 4: Stellen Sie sicher, dass Ihr CDO-Konto mit dem XDR Analytics Portal verknüpft ist.
Bevor Sie Ihr CDO-Portal mit XDR Analytics verknüpfen, sieht es folgendermaßen aus:
Nachdem der Link fertig gestellt ist, können Sie die Option sehen, zu Ihrem XDR Analytics Portal zu navigieren.
Schritt 5: Sobald Ihr XDR Analytics-Konto mit Ihrem Security Cloud Control Portal (CDO) verknüpft ist, müssen Sie sicherstellen, dass Ihre XDR-Analytik in XDR integriert ist. Navigieren Sie dazu in XDR Analytics zu Einstellungen > Integrationen > XDR, suchen Sie nach XDR-Integration und vergewissern Sie sich, dass es einen grünen Häkchen gibt und dass das Integrationsmodul auf Ihre XDR-Org.
Überprüfung
Überprüfen Sie, ob die sicheren Firewalls Ereignisse (Malware oder unbefugte Zugriffe) generieren, und navigieren Sie zu
Validieren Sie, dass die Ereignisse im SSX-Portal registriert werden, wie im Abschnitt Registrieren der Geräte bei SSX im Schritt 4 erwähnt..
Überprüfen Sie, ob die Informationen im Cisco XDR-Dashboard angezeigt werden, oder überprüfen Sie die API-Protokolle, um den Grund für einen möglichen API-Fehler zu ermitteln.
Überprüfen Sie, ob alle Tenants korrekt miteinander verknüpft sind. Wenn Probleme auftreten, öffnen Sie ein TAC-Ticket, und machen Sie die folgenden Angaben:
- CDO-Tenant-ID
- CDO-Name
- XDR-Org.-ID
- SSX-Tenant-ID
- SSX-Name
- SCA-Org.-ID
Fehlerbehebung
Erkennen von Verbindungsproblemen
Sie können generische Verbindungsprobleme aus der Datei action_queue.log erkennen. Bei einem Fehler werden die Protokolle in der Datei angezeigt:
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 diesem Fall bedeutet Exitcode 28, dass der Vorgang abgelaufen ist, und wir müssen die Verbindung zum Internet überprüfen. Sie müssen auch Code 6 zum Beenden sehen, was bedeutet, dass Probleme mit der DNS-Auflösung auftreten.
Verbindungsprobleme aufgrund von DNS-Auflösung
Schritt 1: Stellen Sie sicher, dass die Verbindung ordnungsgemäß funktioniert.
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'
Diese Ausgabe zeigt, dass das Gerät nicht in der Lage ist, die URL https://api-sse.cisco.com aufzulösen. In diesem Fall müssen wir überprüfen, ob der richtige DNS-Server konfiguriert ist. Er kann mit einem nslookup aus der CLI des Experten validiert werden:
root@ftd01:~# nslookup api-sse.cisco.com
;; connection timed out; no servers could be reached
Diese Ausgabe zeigt an, dass der konfigurierte DNS nicht erreicht wurde. Verwenden Sie zum Bestätigen der DNS-Einstellungen den Befehl show network (Netzwerk anzeigen):
> 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 diesem Beispiel wurde der falsche DNS-Server verwendet. Sie können die DNS-Einstellungen mit dem folgenden Befehl ändern:
> configure network dns x.x.x.11
Nachdem diese Verbindung erneut getestet werden kann, ist die Verbindung dieses Mal erfolgreich.
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;
Registrierungsprobleme beim SSX-Portal
Sowohl FMC als auch Secure Firewall benötigen eine Verbindung zu den SSX-URLs auf ihrer Verwaltungsschnittstelle. Um die Verbindung zu testen, geben Sie die folgenden Befehle in die Firepower-CLI mit Root-Zugriff ein:
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
Die Zertifikatsüberprüfung kann mit dem folgenden Befehl umgangen werden:
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;
Überprüfen des SSEConnector-Status
Sie können die Verbindungseigenschaften wie abgebildet überprüfen.
# more /ngfw/etc/sf/connector.properties
registration_interval=180
connector_port=8989
connector_fqdn=api-sse.cisco.com
Um die Verbindung zwischen SSConnector und EventHandler zu überprüfen, können Sie diesen Befehl verwenden. Dies ist ein Beispiel für eine fehlerhafte Verbindung:
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
Im Beispiel einer bestehenden Verbindung sehen Sie, dass der Stream-Status verbunden ist:
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
Überprüfen der an das SSX-Portal und den CTR gesendeten Daten
Um Ereignisse vom Secure Firewall-Gerät an SSX zu senden, muss eine TCP-Verbindung mit https://eventing-ingest.sse.itd.cisco.com hergestellt werden. Dies ist ein Beispiel für eine Verbindung, die nicht zwischen dem SSX-Portal und der sicheren Firewall hergestellt wurde:
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 connector.log logs:
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"
Wenn diese Verbindung nicht hergestellt wird, werden die Ereignisse nicht an das SSX-Portal gesendet. Dies ist ein Beispiel für eine hergestellte Verbindung zwischen der sicheren Firewall und dem SSX-Portal:
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)
Gerät (FTD) kann nicht für Security Cloud Control registriert werden
Wenn Ihr Gerät nicht bei Security Cloud Control registriert werden kann, stellen Sie sicher, dass es über eine Verbindung mit dem entsprechenden CDO-Tenant verfügt.
Um die korrekte URL zu überprüfen, navigieren Sie zu Administration > Firewall Management Center, wählen Sie Cloud Delivered FMC aus, und oben rechts auf Ihrem Bildschirm sehen Sie den Hostnamen.
admin@MexAmpFTD:~$ nc -vz xxxxxxxx.app.us.cdo.cisco.com 443
Connection to xxxxxxxx.app.us.cdo.cisco.com 443 port [tcp/https] succeeded!
Wenn bei der Verbindung mit CDO immer noch Probleme auftreten, stellen Sie sicher, dass Port 8305 geöffnet ist. Dies ist ein Beispiel für ein Verbindungsproblem.
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)
Gerät bei falschem SSX-Tenant angemeldet
Sie können überprüfen, bei welchem SSX-Tenant Ihr FMC registriert ist.
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:~$
Wenn der SSX-Tenant falsch ist, müssen Sie die Schritte zum Registrieren Ihrer Appliances in SSX wiederholen.
Wenn der SSX-Tenant korrekt ist, der CDO-Tenant jedoch nicht mit der entsprechenden SSX-Organisation verknüpft ist, wenden Sie sich mit folgenden Informationen an das TAC:
- SSX-Tenant-ID
- CDO-Tenant-ID
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
2.0 |
06-May-2025
|
Update mit beiden Methoden für die XDR - Secure Firewall-Integration. |
1.0 |
30-Jul-2023
|
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)