본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.
Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.
이 문서에서는 Cisco XDR을 보안 방화벽과 통합, 확인 및 트러블슈팅하는 데 필요한 단계에 대해 설명합니다.
Secure Firewall과 XDR을 통합하는 방법은 두 가지가 있으며, 각 통합은 서로 다른 결과를 제공합니다.
첫 번째 방법은 Secure Firewall, SSX(Security Services Exchange), Security Cloud Control, XDR-Analytics 및 XDR을 통합하여 조사를 강화하는 방법을 설명합니다.
두 번째 방법은 Secure Firewall, SSX, Security Cloud Control, XDR-A, SAL Cloud 및 XDR을 통합하여 사고를 강화하는 방법을 설명합니다.
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
가상 어카운트 역할:
Virtual Account Admin 또는 Smart Account Admin에게만 Smart Account를 SSX 어카운트와 연결할 수 있는 권한이 있습니다.
1단계. Smart Account 역할을 검증하려면 software.cisco.com으로 이동하고 Administration(관리) 메뉴에서 Manage Smart Account(Smart Account 관리)를 선택합니다.
2단계. 사용자 역할을 검증하려면 Users(사용자)로 이동하여 이미지에 표시된 대로 Roles(역할)에서 계정이 Virtual Account Administrator(가상 어카운트 관리자)를 갖도록 설정되어 있는지 검증합니다.
3단계. 보안 라이센스가 포함되지 않은 계정이 SSX에 연결되어 있고 보안 디바이스 및 이벤트가 SSX 포털에 표시되지 않는 경우 SSX에서 연결하도록 선택한 가상 계정에 보안 디바이스에 대한 라이센스가 포함되어 있는지 확인합니다.
4단계. FMC가 올바른 Virtual Account에 등록되었는지 확인하려면 System > Licenses > Smart License로 이동합니다.
1단계. SSX 계정에 로그온할 때 Smart Account를 SSX 계정에 연결해야 합니다. 도구 아이콘을 클릭하고 Smart/Virtual Accounts 연결을 선택해야 합니다.
어카운트가 연결되면 Smart Account가 모든 Virtual Account와 함께 표시됩니다.
1단계. 사용자 환경에서 다음 URL이 허용되는지 확인합니다.
미국 지역
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 지역
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 지역
호주 지역:
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
인도 지역:
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
2단계. 이 URL https://admin.sse.itd.cisco.com을 사용하여 SSX 포털에 로그인하고 Cloud Services(클라우드 서비스)로 이동한 다음 이미지와 같이 Cisco XDR 및 Eventing 옵션을 모두 활성화합니다.
3단계. 이제 SSX에 등록된 디바이스를 확인할 수 있습니다.
이벤트는 Secure Firewall 디바이스에서 전송되며, SSX 포털의 Events로 이동하여 이미지에 표시된 대로 디바이스에서 SSX로 전송한 이벤트를 확인합니다.
1단계. 사용자 환경에서 이러한 URL이 허용되는지 확인합니다.
미국 지역:
defenseorchestrator.com
EU 지역
defenseorchestrator.eu
APJC 지역
apjc.cdo.cisco.com
호주 지역:
aus.cdo.cisco.com
인도 지역:
in.cdo.cisco.com
2단계. Security Cloud Control로 이동합니다(링크는 지역에 따라 다를 수 있음). 그러면 Security Cloud Control Organization을 선택할 수 있습니다.
3단계. 적절한 조직을 선택한 후 Products > Firewall(제품> 방화벽)로 이동하여, 디바이스가 이미 있는지 확인하고, 그렇지 않은 경우 Security Cloud Control(Cisco Defense Orchestrator)에 온보딩할 수 있습니다. 이를 위해 Overall Inventory(전체 인벤토리)에서 New all Devices(모든 디바이스 새로 만들기)를 클릭합니다.
4단계. Administration(관리) > Firewall Management Center(방화벽 관리 센터)로 이동하면 SCC에 통합된 FMC 목록이 표시됩니다. 방화벽 관리 센터가 표시되지 않으면 더하기 아이콘을 클릭합니다.
4.1단계. 일반적으로 Secure Firewalls는 자동으로 온보딩되며, 그렇지 않은 경우 온보딩할 디바이스(FTD)와 선호하는 온보딩 방법을 선택합니다.
4.2단계. Security Devices(보안 디바이스) 섹션에서 더하기 아이콘을 클릭하고 Onboard Secure Firewall Device(온보드 보안 방화벽 디바이스) 및 원하는 디바이스를 선택합니다
5단계. Security Cloud Control에서 디바이스를 온보딩한 후에는 인벤토리에서 이를 시각화할 수 있습니다.
6단계. CDO 조직이 SSX 조직에 연결되어 있는지 확인합니다. 이를 위해 Security Services Exchange로 이동하고, 도구 메뉴 아이콘을 클릭하고, CDO 계정 연결을 클릭합니다.
1단계. Secure Firewall Management Center에서 Integration > SecureX로 이동합니다.
2단계. 오른쪽 영역을 선택하고 Enable SecureX(SecureX 사용)를 클릭합니다.
3단계. Enable SecureX(SecureX 활성화)를 클릭하면 Cisco Defense Orchestrator Authentication Page(Security Cloud Sign On 활용)(Cisco Defense Orchestrator 인증 페이지)로 리디렉션되고 Continue to Cisco SSO(Cisco SSO로 계속)를 클릭합니다.
참고:
7.6.x 이상 버전부터 Cisco XDR 사용
1단계. Secure Firewall Management Center에서 Integration > Cisco Security Cloud로 이동합니다
2단계. 올바른 영역을 선택하고 Enable Cisco Security Cloud(Cisco 보안 클라우드 활성화)를 클릭합니다.
3단계. Enable Cisco Security Cloud(Cisco 보안 클라우드 활성화)를 클릭하면 Cisco Defense Orchestrator Authentication Page(보안 클라우드 사인온을 활용함)로 리디렉션되고 Continue to Cisco SSO(Cisco SSO로 계속)를 클릭합니다.
4단계. 기존 Security Cloud Control 테넌트를 선택하거나 새 테넌트를 생성할 수 있습니다.
5단계. 적절한 테넌트를 선택하고 이 페이지에서 수신하는 코드가 FMC에서 수신하는 코드와 일치하는지 확인합니다. 일치하는 경우 FMC 권한 부여를 클릭합니다.
6단계. Security Cloud Sign On 자격 증명을 입력하고 통합 권한을 부여합니다. 완료되면 FMC가 Cisco Security Cloud에 등록할 권한이 있다는 확인 메시지가 표시됩니다.
7단계. 권한 부여가 완료되면 FMC로 다시 이동하여 클라우드로 보낼 이벤트를 선택하고 이 작업을 마치면 Save(저장)를 클릭합니다.
8단계. SecureX 오케스트레이션(XDR 자동화)을 사용하도록 선택할 수 있습니다
9단계. XDR> Administration> On Premises Appliance로 이동하여 어플라이언스를 검색하면 자동으로 등록되어야 합니다.
10단계. XDR> Administration> Integrations로 이동하여 Secure Firewall Integration을 활성화합니다.
10.1단계. 통합에 이름을 지정하고 +추가를 누릅니다.
이러한 통합을 통해 XDR 내에서 조사를 강화할 수 있습니다.
참고: Secure Firewall, XDR, CDO(Cisco Defense Orchestrator), SSX(Security Services Exchange), SAL(Security Analytics and Logging) 간의 원활한 통합을 위해서는 수동 매핑이 필요합니다. 이 프로세스에는 필요한 컨피그레이션 및 매핑을 수행하기 위해 Cisco TAC에 문의하는 과정이 포함됩니다.
1단계. Cisco XDR에 이벤트를 전달하려면 CDO 계정에 Security Analytics and Logging 라이센스가 있어야 합니다.
2단계. 앞서 설명한 단계를 사용하여 어플라이언스를 SSX 및 Security Cloud Control에 등록하십시오.
3단계. 작업을 마치면 TAC에 연락하여 자세한 내용을 확인하고 보안 클라우드 제어/SAL을 XDR 분석에 연결하도록 요청하십시오.
4단계. CDO 계정이 XDR 분석 포털에 연결되어 있는지 확인합니다.
CDO 포털을 XDR 분석에 연결하기 전에 다음과 같이 하십시오.
링크가 완료되면 XDR 분석 포털로 이동하는 옵션이 표시됩니다.
5단계. XDR 분석 계정이 CDO(Security Cloud Control Portal)에 연결되면 XDR 분석이 XDR과 통합되었는지 확인해야 합니다. 이를 위해 XDR 분석에서 설정 > 통합> XDR로 이동하여 XDR 통합을 찾아 녹색 확인 표시가 있고 통합 모듈이 올바른 XDR 조직을 가리키는지 확인합니다.
보안 방화벽에서 이벤트(악성코드 또는 침입)를 생성하는지 확인합니다. 침입 이벤트의 경우 분석 >파일 >Malware Events(악성코드 이벤트)는 침입 이벤트의 경우 Analysis(분석) > Intrusion(침입) > Events(이벤트)로 이동합니다.
Register the devices to SSX(SSX에 디바이스 등록) 섹션 4에 설명된 대로 이벤트가 SSX 포털에 등록되었는지 확인합니다..
Cisco XDR 대시보드에 정보가 표시되는지 확인하거나 API 로그를 확인하여 API 실패의 원인을 확인할 수 있습니다.
모든 테넌트가 올바르게 연결되어 있는지 확인하고, 문제가 있는 경우 TAC 케이스를 열고 다음 세부 정보를 제공합니다.
action_queue.log 파일에서 일반 연결 문제를 탐지할 수 있습니다. 오류가 발생할 경우 파일에 해당 로그가 있는 것을 볼 수 있습니다.
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.
이 경우 종료 코드 28은 작업 시간이 초과되었음을 의미하며 인터넷 연결을 확인해야 합니다. DNS 확인 문제를 의미하는 종료 코드 6도 표시되어야 합니다
1단계. 연결이 제대로 작동하는지 확인합니다.
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'
이 출력은 디바이스가 URL https://api-sse.cisco.com을 확인할 수 없음을 보여줍니다. 이 경우 올바른 DNS 서버가 구성되어 있는지 검증해야 합니다. 전문 CLI의 nslookup으로 검증할 수 있습니다.
root@ftd01:~# nslookup api-sse.cisco.com
;; connection timed out; no servers could be reached
이 출력은 구성된 DNS에 도달하지 않았음을 보여줍니다. DNS 설정을 확인하려면 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
이 예에서는 잘못된 DNS 서버가 사용되었습니다. 다음 명령을 사용하여 DNS 설정을 변경할 수 있습니다.
> configure network dns x.x.x.11
이 연결을 다시 테스트할 수 있으며, 이 경우 연결에 성공합니다.
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;
FMC와 보안 방화벽 모두 관리 인터페이스의 SSX URL에 연결해야 합니다. 연결을 테스트하려면 루트 액세스로 Firepower CLI에서 다음 명령을 입력합니다.
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
인증서 검사는 다음 명령으로 우회할 수 있습니다.
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;
참고: 테스트에서 전송된 매개변수가 SSX의 예상과 다르지만 연결을 검증하기에 충분하므로 403 Forbidden 메시지가 표시됩니다.
표시된 대로 커넥터 속성을 확인할 수 있습니다.
# more /ngfw/etc/sf/connector.properties
registration_interval=180
connector_port=8989
connector_fqdn=api-sse.cisco.com
SSConnector와 EventHandler 간의 연결을 확인하기 위해 이 명령을 사용할 수 있습니다. 이 예는 잘못된 연결의 예입니다.
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
설정된 연결의 예에서는 스트림 상태가 connected임을 확인할 수 있습니다.
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
Secure Firewall 디바이스에서 SSX로 이벤트를 보내려면 https://eventing-ingest.sse.itd.cisco.com를 사용하여 TCP 연결을 설정해야 합니다. 이 예는 SSX 포털과 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)
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"
참고: 표시된 x.x.x.246 및 1x.x.x.246이 https://eventing-ingest.sse.itd.cisco.com에 속하는 IP 주소를 변경해야 합니다. 따라서 IP 주소 대신 URL을 기준으로 SSX 포털에 트래픽을 허용하는 것이 좋습니다.
이 연결이 설정되지 않으면 이벤트가 SSX 포털로 전송되지 않습니다. 다음은 보안 방화벽과 SSX 포털 간에 설정된 연결의 예입니다.
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)
디바이스가 Security Cloud Control에 등록할 수 없는 경우 해당 CDO 테넌트에 연결되어 있는지 확인합니다.
올바른 URL을 확인하려면 Administration(관리) > Firewall Management Center(방화벽 관리 센터)로 이동하여 Cloud Delivered FMC(클라우드 제공 FMC)를 선택합니다. 화면 오른쪽 상단에는 호스트 이름이 표시됩니다.
admin@MexAmpFTD:~$ nc -vz xxxxxxxx.app.us.cdo.cisco.com 443
Connection to xxxxxxxx.app.us.cdo.cisco.com 443 port [tcp/https] succeeded!
여전히 CDO에 연결하는 데 문제가 있는 경우 포트 8305가 열려 있는지 확인합니다. 이는 연결 문제의 예입니다.
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)
FMC가 등록된 SSX 테넌트를 확인할 수 있습니다.
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:~$
SSX 테넌트가 잘못된 경우 SSX에 어플라이언스를 등록하기 위한 단계를 다시 수행해야 합니다
SSX 테넌트가 올바르지만 CDO 테넌트가 적절한 SSX 조직에 연결되지 않은 경우 다음 세부 정보를 사용하여 TAC에 문의하십시오.
개정 | 게시 날짜 | 의견 |
---|---|---|
2.0 |
06-May-2025
|
XDR - 보안 방화벽 통합에 사용할 수 있는 두 가지 방법을 모두 사용하여 업데이트합니다. |
1.0 |
30-Jul-2023
|
최초 릴리스 |