تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يصف هذا المستند الخطوات المطلوبة لدمج Cisco XDR مع جدار الحماية الآمن والتحقق من صحته واستكشاف أخطائه وإصلاحها.
هناك طريقتان لدمج Secure Firewal و XDR، وكل دمج يوفر نتائج مختلفة.
تصف الطريقة الأولى كيفية دمج جدار الحماية الآمن، وتبادل خدمات الأمان (SSX)، والتحكم في سحابة الأمان، وتحليلات XDR و XDR لإثراء التحقيقات.
تصف الطريقة الثانية كيفية دمج جدار الحماية الآمن و SSX والتحكم في سحابة الأمان و XDR-A و SAL Cloud و XDR لإثراء الحوادث.
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
يتم وصف خطوات الترخيص هذه لإصدارات جدار الحماية الآمن 7.2.x وأسفل، إذا كان جدار الحماية الآمن الخاص بك موجودا على إصدار أكبر، يمكنك الانتقال إلى ربط حساباتك ب SSX وتسجيل قسم الأجهزة.
أدوار الحساب الظاهري:
يتمتع فقط مسؤول الحساب الظاهري أو مسؤول الحساب الذكي بامتياز ربط الحساب الذكي بحساب SSX.
الخطوة 1. للتحقق من صحة دور الحساب الذكي، انتقل إلى software.cisco.com وتحت قائمة الإدارة، حدد إدارة الحساب الذكي.
الخطوة 2. للتحقق من صحة دور المستخدم، انتقل إلى المستخدمين، وتحقق من تعيين الحسابات تحت الأدوار إلى مسؤول حساب ظاهري، كما هو موضح في الصورة.
الخطوة 3. تأكد من أن الحساب الظاهري المحدد للارتباط على SSX يحتوي على ترخيص لأجهزة الأمان في حالة إرتباط حساب لا يحتوي على ترخيص الأمان على SSX وأجهزة الأمان والحدث لا يظهر على مدخل SSX.
الخطوة 4. للتحقق من تسجيل FMC في الحساب الظاهري الصحيح، انتقل إلى نظام > تراخيص > ترخيص ذكي:
الخطوة 1. عند تسجيل الدخول إلى حساب SSX الخاص بك، يجب عليك ربط حسابك الذكي بحساب SSX الخاص بك، حتى تحتاج إلى النقر فوق رمز "أدوات" وتحديد ربط الحسابات الذكية/الظاهرية.
بمجرد ربط الحساب، سترى الحساب الذكي الذي يحتوي على كافة الحسابات الظاهرية الموجودة عليه.
الخطوة 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
منطقة الاتحاد الأوروبي
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
إقليم أبكان
منطقة اوستراليا:
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. سجل الدخول إلى بوابة SSX باستخدام عنوان URL هذا https://admin.sse.itd.cisco.com، انتقل إلى خدمات السحابة، وقم بتمكين كلا الخيارين Cisco XDR وEventing، كما هو موضح في الصورة.
الخطوة 3. يمكنك التحقق من أنه يمكنك الآن رؤية الأجهزة المسجلة في SSX:
يتم إرسال الأحداث بواسطة أجهزة جدار الحماية الآمنة، انتقل إلى الأحداث الموجودة على بوابة SSX للتحقق من الأحداث التي تم إرسالها بواسطة الأجهزة إلى SSX، كما هو موضح في الصورة.
الخطوة 1. تأكد من أن عناوين URL هذه مسموح بها على بيئتك
المنطقة الأمريكية:
defenseorchestrator.com
منطقة الاتحاد الأوروبي
defenseorchestrator.eu
إقليم أبكان
apjc.cdo.cisco.com
منطقة اوستراليا:
aus.cdo.cisco.com
منطقة الهند:
in.cdo.cisco.com
الخطوة 2. انتقل إلى التحكم في شبكة الأمان (يمكن أن يختلف الارتباط حسب منطقتك) وهذا يوجهك لتحديد مؤسسة التحكم في سحابة الأمان.
الخطوة 3. بمجرد تحديد المؤسسة المناسبة، انتقل إلى المنتجات>جدار الحماية، تحقق مما إذا كان الجهاز لديك موجودا بالفعل، إن لم يكن موجودا، فيمكنك تضمينه إلى التحكم في سحابة الأمان (Cisco Defense Orchestrator)، لهذا، ضمن قائمة الجرد العامة، انقر فوق تحديد جميع الأجهزة.
الخطوة 4. انتقل إلى الإدارة>مركز إدارة جدار الحماية، يتم تقديم قائمة بأنظمة FMC المدمجة في SCC، إذا لم ترى مركز إدارة جدار الحماية، انقر على أيقونة زائد.
الخطوة 4.1. عادة، يتم إدراج جدران الحماية الآمنة تلقائيا على اللوحة، إذا لم يكن الأمر كذلك، فحدد الجهاز الذي تريد إستخدامه على اللوحة (FTD) وأسلوب تسجيل الدخول المفضل لديك.
الخطوة 4.2. تحت قسم أجهزة الأمان انقر فوق رمز علامة الجمع، حدد جهاز جدار الحماية الآمن على اللوحة والكمبيوتر المفضل لديك
الخطوة 5. بمجرد تسجيل الوصول إلى أجهزتك في "التحكم في سحابة الأمان"، يمكنك تصورها في المخزون.
الخطوة 6. تأكد من أن مؤسسة CDO مرتبطة بمؤسسة SSX الخاصة بك، لهذا السبب، انتقل إلى "تبادل خدمات الأمان"، وانقر فوق رمز القائمة "أدوات"، وانقر فوق إرتباط حساب CDO.
الخطوة 1. في مركز إدارة جدار الحماية الآمن، انتقل إلى الدمج>SecureX
الخطوة 2. أختر المنطقة المناسبة، وانقر فوق تمكين SecureX.
الخطوة 3. بعد النقر فوق تمكين SecureX، فإنه يعيد توجيهك إلى صفحة مصادقة Cisco Defense Orchestrator (التي تستفيد من تسجيل دخول سحابة الأمان)، انقر فوق متابعة إلى Cisco SSO.
ملاحظة:
من 7.6.x والإصدارات الأحدث باستخدام ذاكرة XDR من Cisco
الخطوة 1. في مركز إدارة جدار الحماية الآمن لديك، انتقل إلى التكامل > سحابة أمان Cisco
الخطوة 2. أختر المنطقة المناسبة، وانقر فوق تمكين سحابة أمان Cisco.
الخطوة 3. بعد النقر فوق تمكين سحابة أمان Cisco، فإنها تعيد توجيهك إلى صفحة مصادقة Cisco Defense Orchestrator (التي تستفيد من تسجيل دخول سحابة الأمان)، انقر فوق متابعة إلى Cisco SSO.
الخطوة 4. يمكنك إما تحديد مستأجر عنصر تحكم في سحابة أمان موجود مسبقا أو إنشاء مستأجر جديد.
الخطوة 5. حدد المستأجر المناسب وتأكد من أن الرمز الذي تتلقاه في هذه الصفحة يطابق الرمز الذي تتلقاه في FMC، إذا كان مطابق، انقر فوق تخويل FMC.
الخطوة 6. أدخل بيانات اعتماد تسجيل الدخول إلى سحابة الأمان وتخويل الدمج، بمجرد اكتماله، يتم تقديم تأكيد على أن FMC قد تم تخويلها للتسجيل مع سحابة أمان Cisco.
الخطوة 7. بعد اكتمال التفويض، يمكنك إعادة الاتصال ب FMC، وتحديد الأحداث التي تريد إرسالها إلى مجموعة النظراء وبمجرد الانتهاء من ذلك، انقر فوق حفظ.
الخطوة 8. يمكنك تحديد تمكين تزامن SecureX (أتمتة XDR)
الخطوة 9. انتقل إلى XDR>إدارة>On Premises Appliance وابحث عن أجهزتك، يجب أن يتم تسجيلها تلقائيا.
الخطوة 10. انتقل إلى XDR>إدارة>عمليات التكامل وتمكين تكامل جدار الحماية الآمن.
الخطوة 10.1. قم بتعيين اسم للتكامل الخاص بك، انقر فوق +إضافة.
يتيح لك هذا الدمج إثراء التحقيقات داخل XDR.
ملاحظة: لضمان التكامل السلس بين جدار الحماية الآمن و XDR و Cisco Defense Orchestrator (CDO) و Security Services Exchange (SSX) وتحليلات الأمان والتسجيل (SAL)، يلزم التعيين اليدوي. تتضمن هذه العملية الاتصال ب Cisco TAC لتنفيذ التكوينات والتعيينات الضرورية.
الخطوة 1. يجب أن يحتوي حساب CDO لديك على ترخيص تحليلات الأمان والتسجيل لإعادة توجيه الأحداث إلى Cisco XDR.
الخطوة 2. يرجى إستخدام الخطوات الموضحة سابقا لتسجيل أجهزتك في SSX والتحكم في سحابة الأمان.
الخطوة 3. بمجرد الانتهاء، يرجى الوصول إلى TAC باستخدام هذه التفاصيل وطلب ربط التحكم في سحابة الأمان/SAL بتحليلات XDR.
الخطوة 4. تأكد من إرتباط حساب CDO الخاص بك ببوابة تحليلات XDR.
قبل ربط بوابة CDO بتحليلات XDR، يبدو كما يلي:
بعد اكتمال الارتباط، يمكنك رؤية الخيار للانتقال إلى مدخل تحليلات XDR.
الخطوة 5. بمجرد ربط حساب تحليلات XDR الخاص بك ببوابة التحكم في سحابة الأمان (CDO)، يجب التأكد من دمج تحليلات XDR مع XDR، لهذا، في تحليلات XDR، انتقل إلى الإعدادات>عمليات التكامل>XDR، ابحث عن تكامل XDR وتأكد من وجود تحقق أخضر ومن أن وحدة التكامل تشير إلى مؤسسة XDR الصحيحة.
تحقق من أن جدران الحماية الآمنة تقوم بإنشاء أحداث (برامج ضارة أو أختراق)، ولأحداث التسلل انتقل إلى تحليل >ملفات>أحداث البرامج الضارة، لأحداث التطفل، انتقل إلى التحليل>التطفل > أحداث.
التحقق من صحة الأحداث المسجلة على بوابة SSX كما هو مذكور في الخطوة 4 قسم تسجيل الأجهزة على SSX.
تحقق من صحة عرض هذه المعلومات على لوحة معلومات Cisco XDR أو تحقق من سجلات واجهة برمجة التطبيقات (API) حتى يمكنك الاطلاع على سبب فشل واجهة برمجة التطبيقات (API) المحتمل.
تحقق من أن جميع المستأجرين مرتبطون معا بشكل صحيح، إذا كانت لديك مشاكل، افتح حالة مركز المساعدة الفنية وقم بتوفير التفاصيل التالية:
يمكنك الكشف عن مشاكل الاتصال العامة من ملف 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 انتهاء مهلة العملية ويجب التحقق من الاتصال بالإنترنت. يجب أن ترى أيضا رمز الخروج 6 الذي يعني مشاكل في دقة DNS
الخطوة 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 المناسب، ويمكن التحقق من صحته باستخدام NSLOOKUP من واجهة سطر الأوامر (CLI) الخبير:
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;
ملاحظة: تحصل على الرسالة 403 المحظورة لأن المعلمات المرسلة من الاختبار ليست ما تتوقع SSX ولكن هذا يثبت بما فيه الكفاية للتحقق من الاتصال.
يمكنك التحقق من خصائص الموصل كما هو موضح.
# more /ngfw/etc/sf/connector.properties
registration_interval=180
connector_port=8989
connector_fqdn=api-sse.cisco.com
للتحقق من الاتصال بين SSContor و 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
في مثال على اتصال ثابت، يمكنك أن ترى أن حالة الدفق متصلة:
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
لإرسال الأحداث من جهاز جدار الحماية الآمن إلى SSX يلزم إنشاء اتصال TCP مع https://eventing-ingest.sse.itd.cisco.com هذا مثال على اتصال لم يتم إنشاؤه بين مدخل SSX وجدار الحماية الآمن:
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)
في الموصل.السجلات:
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"
ملاحظة: لاحظ أن عناوين IP المعروضة x.x.x.246 و 1x.x.246 تنتمي إلى https://eventing-ingest.sse.itd.cisco.com يجب أن تتغير، ولهذا السبب فإن التوصية هي السماح بحركة المرور إلى مدخل SSX استنادا إلى URL بدلا من عناوين IP.
في حالة عدم إنشاء هذا الاتصال، لا يتم إرسال الأحداث إلى مدخل 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)
إذا تعذر تسجيل جهازك في "التحكم في سحابة الأمان"، فتأكد من توفر اتصال به لمستأجر CDO المناسب.
للتحقق من عنوان URL الصحيح، انتقل إلى الإدارة >مركز إدارة جدار الحماية، حدد اسم المضيف (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)
يمكنك التحقق من أي مستأجر SSX مسجل في FMC الخاص بك.
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
|
الإصدار الأولي |