أستكشاف أخطاء عمليات نشر سياسة الدفاع عن تهديد FirePOWER وإصلاحها

المقدمة

يصف هذا المستند نظرة عامة عالية المستوى على عملية نشر السياسة في FTD بالإضافة إلى تقنيات أستكشاف الأخطاء وإصلاحها الأساسية. 

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• Firewall Management Center (FMC)
• Firepower Threat Defense (FTD)

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

معلومات أساسية

باستخدام Cisco Firepower Threat Defense (FTD)، يتم الآن دمج ميزات جدار الحماية التقليدية المعبرة عن الحالة التي توفرها Adaptive Security Appliances (ASA) وميزات جدار Next-Gen الحماية (التي يتم تشغيلها بواسطة Snort ) في منتج واحد.

بسبب هذا التغيير، Policy Deployment Infrastructure يعالج FTD الآن تغييرات التكوين لكل من رمز ASA (المشار إليه أيضا باسم LINA)، Snort وفي حزمة واحدة. 

نظرة عامة على نشر النهج

يستخدم برنامج FTD Policy Deployments من Cisco لإدارة التكوينات وإخراجها للأجهزة التي تم تسجيلها في Firewall Management Center (FMC) نفسها.

وداخل عملية النشر، توجد سلسلة من الخطوات التي يتم تقسيمها إلى "مراحل".

يمكن تلخيص مراحل FMC في هذه القائمة.

المرحلة 0	تهيئة النشر
المرحلة الأولى	مجموعة كائنات قاعدة البيانات
المرحلة الثانية	السياسة ومجموعة الكائنات
المرحلة الثالثة	إنشاء تكوين سطر الأوامر NGFW
المرحلة 4	إنشاء حزمة نشر الأجهزة
المرحلة 5	إرسال حزمة النشر واستقبالها
المرحلة 6	النشر وإجراءات النشر ورسائل نجاح النشر المعلقة

يمكن أن تساعد معرفة المراحل وموقع حالات الفشل في العملية في أستكشاف أخطاء الفشل التي يواجهها Firepower النظام وإصلاحها.

في بعض الحالات، قد يكون متعارضا بسبب التكوينات السابقة أو ناتجا عن Advanced Flex Configuration افتقار الكلمة الأساسية إلى كلمة أساسية والتي قد تتسبب في حدوث حالات فشل لا يتناولها تقرير الجهاز.

مثال نظرة عامة

الخطوة 1. انقر Deployment، والذي يحدد الجهاز الذي سيتم تحديده.

الخطوة 2. عند الالتزام بعملية النشر للجهاز، تبدأ FMC في تجميع جميع التكوينات المتعلقة بالجهاز. 

الخطوة 3. عندما يتم تجميع التكوينات، تقوم وحدة التحكم في إدارة الهيكل (FMC) بإنشاء الحزمة وإرسالها إلى المستشعر عبر آلية الاتصال الخاصة به والتي يطلق عليها SFTunnel.

الخطوة 4. تقوم وحدة التحكم في إدارة اللوحة الأساسية (FMC) بإعلام المستشعر ببدء عملية النشر باستخدام السياسة المتوفرة أثناء استماعه للاستجابات الفردية.

الخطوة 5. يفك الجهاز المدار الأرشفة ويبدأ في تطبيق التكوينات والحزم الفردية.

ألف - النصف الأول من النشر هو Snort التكوين الذي يتم فيه إختبار Snort التكوين محليا لضمان صلاحيته.

عندما يثبت أنه صحيح، يتم نقل التكوين الجديد إلى دليل الإنتاج ل Snort. في حالة فشل التحقق من الصحة، يفشل نشر النهج في هذه الخطوة.

باء - النصف الثاني من حمل حزمة النشر يتعلق بتكوين نظام LINA حيث يتم تطبيقه مباشرة على عملية LINA بواسطة عملية NGFWmanager.

في حالة حدوث فشل، يتم التراجع عن التغييرات ويحدث فشل في نشر النهج.

الخطوة 6. إذا Snort نجحت كل من وحزم LINA، يشير الجهاز المدار Snort إلى إعادة التشغيل أو إعادة التحميل in order to تحميل التكوين الجديد وحفظ جميع التكوينات الحالية.

الخطوة 7. في حالة نجاح كافة الرسائل، يرسل المستشعر رسالة نجاح وينتظر حتى يتم الاعتراف بها من قبل مركز الإدارة.

الخطوة 8. وبمجرد تلقيها، تحدد FMC المهمة على أنها ناجحة وتسمح لمجموعة السياسات بالإنهاء.

استكشاف الأخطاء وإصلاحها

المشاكل التي تتم مواجهتها خلال Policy Deployment يمكن أن ترجع إلى، ولكن لا تقتصر على، ما يلي:

1. تكوين خاطئ
2. الاتصال بين FMC و FTD
3. سلامة النظام وقواعد البيانات
4. عيوب البرامج والتحذيرات
5. حالات فريدة أخرى

يمكن إصلاح بعض هذه المشاكل بسهولة، في حين يمكن أن تتطلب أخرى مساعدة من Cisco Technical Assistance Center (TAC).

الهدف من هذا قسم أن يزود تقنية أن يعزل الإصدار أو يعين الجذر سبب. 

واجهة المستخدم الرسومية (GUI) لوحدة التحكم FMC 

توصي Cisco ببدء تشغيل كل جلسة أستكشاف أخطاء النشر وإصلاحها على جهاز FMC.

في إطار "إعلام الفشل"، في جميع الإصدارات بعد 6.2.3، هناك أدوات إضافية يمكن أن تساعد في حالات الفشل الأخرى المحتملة. 

إستخدام محاضر التوزيع

الخطوة 1. اسحب Deployments القائمة على واجهة مستخدم ويب FMC.

الخطوة 2. بينما تكون Deployments علامة التبويب محددة، انقر Show History.




الخطوة 3. داخل Deployment History المربع، يمكنك مشاهدة جميع عمليات النشر السابقة من وحدة التحكم في إدارة اللوحة الأساسية (FMC). حدد النشر الذي ترغب في رؤية مزيد من البيانات فيه.


الخطوة 4. بمجرد تحديد عنصر نشر، يعرض Deployment Details التحديد قائمة بجميع الأجهزة الموجودة داخل Transaction. يتم تقسيم هذه المدخلات إلى هذه الأعمدة: Device Number, Device Name, Status,و Transcript.








الخطوة 5. حدد الجهاز المعني وانقر فوق خيار النسخ للاطلاع على نسخة النشر الفردية التي يمكن أن تطلعك على حالات الفشل بالإضافة إلى عمليات التهيئة التي يتم وضعها على الأجهزة التي تتم إدارتها.





الخطوة 6. يمكن أن يحدد هذا النص حالات فشل معينة وكذلك يشير إلى رقم مهم جدا للخطوة التالية: Transaction ID.







الخطوة 7. وبشكل Firepower Deploymentعام، Transaction ID فإن هذا هو ما يمكن إستخدامه لتعقب كل قسم على حدة من نشر السياسات. مع هذا، على سطر الأوامر الخاص بالجهاز، يمكنك الحصول على إصدار أكثر تعمقا من هذه البيانات للإصلاح والتحليل.



تلميح: في حالة عدم قدرتك على تحديد موقع معرف الحركة أو إذا كنت تستخدم إصدارا قبل طباعة هذا الملف، يظل هذا السجل مستخدما لتحديد موقع رسائل الفشل الفردية.

أستكشاف الأخطاء وإصلاحها باستخدام سجلات FMC

على الرغم من أنه من المناسب إشراك Cisco TAC لتحليل السجلات، فإن البحث عبر السجلات يمكن أن يساعد في عزل المشكلة الأولية وتسريع الحل. هناك العديد من ملفات السجل على FMC التي تكشف تفاصيل حول عملية نشر النهج.

اللوحان المشار إليهما بشكل شائع هما policy_deployment.log و usmsharedsvcs.log.

يمكن عرض جميع الملفات المذكورة في هذا المستند باستخدام أوامر Linux المتعددة مثل more، less و vi. بيد أنه من المهم جدا ضمان عدم القيام إلا read بالإجراءات اللازمة لذلك. تتطلب كافة الملفات الوصول الجذر لتتمكن من عرضها.

/var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log

يحدد هذا السجل بوضوح بداية مهمة نشر السياسة على FMC وإكمال كل مرحلة، مما يساعد على تحديد المرحلة التي تعرض فيها النشر للفشل، بالإضافة إلى رمز الفشل.

يمكن إستخدام transactionID القيمة المضمنة في جزء JSON من السجل للعثور على إدخالات السجل المتعلقة بإحدى محاولات النشر المحددة.

10-May-2024 18:05:31.249,[INFO],(JsonRESTServerResource.java:111)
com.cisco.nm.vms.api.rest.DeploymentServerResource, ajp-nio-127.0.0.1-9009-exec-3
** REST Request [ DC ]
** ID : e45c6abd-0fff-4341-bdad-ddd5fee10034
** URL: POST https://localhost6/csm/api/deploy/GetTranscript
{
"data": {},
"deviceUUID": "49243dac-0ba7-11ef-af54-a592d78081a7",
"jobID": 34359753974,
"offset": {
"size": 20,
"start": 0
},
"requestID": "e3be908a0ef711ef9d519da21f9032fa",
"version": "7.2.5"
} 

/var/log/sf/policy_deployment.log

وعلى الرغم من وجود ملف السجل هذا خلال إصدارات 6.x التي تبدأ من 6.4، فقد تم توسيع نطاق تغطيته.

وهو يصف الآن الخطوات التفصيلية التي اتخذت بشأن وحدة إدارة الاتصالات الفيدرالية (FMC) لإعداد حزم النشر، وبالتالي فهو يستخدم على أفضل وجه لتحليل حالات الفشل من المرحلة 1-4.

يتم تمييز بداية كل مرحلة بخط مع INFO start .

May 8 02:00:58 RTP-vFMC-Pod-09 ActionQueueScrape.pl[10413]: > SF::UMPD::CSMData::getPolicyRollbackInfo start (161.32M)
May 8 02:00:58 RTP-vFMC-Pod-09 ActionQueueScrape.pl[10413]: < SF::UMPD::CSMData::getPolicyRollbackInfo end (161.32M, 0.012(sec))
...

أستكشاف أخطاء الأجهزة المدارة وإصلاحها

هناك مراحل إضافية وأقسام تعتمد على حزمة الأجهزة والتكوين عالي التوافر ونتائج المراحل السابقة لكل جهاز تتم إدارته.

إذا تم عزل مشكلة نشر إلى فشل على الجهاز المدار، يمكن تنفيذ المزيد من أستكشاف الأخطاء وإصلاحها على الجهاز باستخدام سجلين على الجهاز: policy_deployment.log وngfwManager.log.

/ngfw/var/log/ngfwManager.log

يوفر ملف السجل هذا الخطوات التفصيلية التي تم إتخاذها Config Communication Manager للاتصال Config Dispatcher بوحدة التحكم في إدارة الهيكل (FMC)، والعمل مع حزمة النشر، وتنسيق عملية التحقق من تكوينات Snort و LINA وتطبيقها.

هذه أمثلة قليلة على ngfwManager.log التي تمثل بداية المراحل الرئيسية:

FTD receives FMC's request for running configuration: May 30 16:37:10 ccm[4293] Thread-10: INFO com.cisco.ccm.ConfigCommunicationManager- Passing CD-Message-Request to Config Dispatcher... May 30 16:37:10 ccm[4293] Thread-10: DEBUG com.cisco.ccm.ConfigCommunicationManager- <?xml version="1.0" encoding="UTF-8"?><cdMessagesList><timeStamp>1559234230012</timeStamp><cdMessage><name>LinaShowCommand</name><messageId>-753133537443151390</messageId><contentType>XML</contentType><msgContent><![CDATA[<?xml version="1.0" encoding="UTF-8"?><message><name>LinaShowCommand</name>... FTD receives FMC's request to download the deployment package: May 30 16:37:18 ccm[4293] Thread-9: INFO com.cisco.ccm.ConfigCommunicationManager- Downloading database (transaction 8589938211, version 1559234236) May 30 16:37:18 ccm[4293] Thread-9: DEBUG com.cisco.ccm.DownloadManager- handle record: 8589938211, status = PENDING May 30 16:37:18 ccm[4293] Thread-9: DEBUG com.cisco.ccm.DownloadManager- begin downloading database FTD begins the deployment of policy changes: May 30 16:37:21 ccm[4293] Thread-9: INFO com.cisco.ccm.ConfigCommunicationManager- Starting deployment May 30 16:37:21 ccm[4293] Thread-11: INFO com.cisco.ccm.ConfigCommunicationManager- Sending message: DEPLOYMENT_STATUS_CCM to Manager FTD begins LINA deployment: May 30 16:37:42 ccm[4293] Thread-19: DEBUG com.cisco.ngfw.configdispatcher.communicators.LinaCommunicatorImpl- Trying to send Start-Config-Sequencerequest to lina FTD begins finalizing the deployment: May 30 16:38:48 ccm[4293] Thread-19: DEBUG com.cisco.ngfw.configdispatcher.communicators.LinaCommunicatorImpl- Clustering Message sent out of ConfigDispatcher: Name:Cluster-App-Conf-Finalize-Request 

/ngfw/var/log/sf/policy_deployment.log

يحتوي هذا السجل على تفاصيل النهج المطبق عليه Snort. على الرغم من أن محتوى السجل متقدم في معظمه ويتطلب تحليلا بواسطة TAC، إلا أنه لا يزال من الممكن تتبع العملية بعدد قليل من الإدخالات الأساسية:

Config Dispatcher begins extracting the packaged policies for validation: Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO -> calling SF::UMPD::Plugins::NGFWPolicy::Device::exportDeviceSnapshotToSandbox (Plugin 230 <- Framework 611 <- Transaction 1085) Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO found NGFWPolicy => (NGFWPolicy::Util 32 <- NGFWPolicy::Device 43 <- Plugin 235) ... Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO export FTD platform settings... (PlatformSettings::FTD::Device 29 <- Plugin 235<339 <- PlatformSettings::Device 13) Config validation begins: Jul 18 17:21:37 firepower policy_apply.pl[25122]: INFO starting validateExportedFiles - sqlite = /var/cisco/deploy/sandbox/policy_deployment.db, sandbox = /var/cisco/deploy/sandbox/exported-files (memory = 229.99 MB) (Framework 3950<687 <- Transaction 1101 <- main 194) Validation has completed successfully: Jul 18 17:21:49 firepower policy_apply.pl[25122]: INFO validateExportedFiles - sqlite = /var/cisco/deploy/sandbox/policy_deployment.db, sandbox = /var/cisco/deploy/sandbox/exported-files took 12 (memory = 238.50 MB, change = 8.51 MB) (Framework 3976<724 <- Transaction 1101 <- main 194) Config Dispatcher begins moving the validated configuration to the Snort directories in production: Jul 18 17:21:54 firepower policy_apply.pl[26571]: INFO -> calling SF::UMPD::Plugins::NGFWPolicy::Device::publishExportedFiles (Plugin 230 <- Framework 822 <- Transaction 1662) Snort processes will reload to apply the new configurations: Jul 18 17:22:02 firepower policy_apply.pl[26571]: INFO Reconfiguring DE a3bcd340-992f-11e9-a1f1-ac829f31a4f9... (Snort::SnortNotifications 292<154 <- Snort::Device 343 <- Plugin 235) Jul 18 17:22:02 firepower policy_apply.pl[26571]: INFO sending SnortReload to a3bcd340-992f-11e9-a1f1-ac829f31a4f9 (Snort::SnortNotifications 298<154 <- Snort::Device 343 <- Plugin 235) Snort reload has completed successfully: Jul 18 17:22:14 firepower policy_apply.pl[26571]: INFO notifyProcesses - sandbox = /var/cisco/deploy/sandbox/exported-files took 16 (memory = 169.52 MB, change = 16.95 MB) (Framework 3976<964 <- Transaction 1680 <- main 200) After LINA config apply finishes, Snort deployment is finalized: Jul 18 17:23:32 firepower policy_apply.pl[26913]: INFO starting finalizeDeviceDeployment - sandbox = /var/cisco/deploy/sandbox (memory = 101.14 MB) (Framework 3950<980 <- Transaction 1740 <- main 206)

مثال

الخطوة 1. فشل النشر

الخطوة 2. احصل على علامة Deploy Transcript AND Transaction ID.

الخطوة 3. أدخل SSH Management Center في وحدة التحكم FMC الخاصة بك واستخدم أداة Linux المساعدة less لقراءة الملف كما هو موضح على وحدة التحكم في إدارة الملفات (FMC) لديك:

مثال: أقل من /var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log (كلمة مرور sudo هي كلمة مرور المستخدم ل SSH.)

الخطوة 4. عند دخولك، lessأستخدم شرطة مائلة للأمام وأدخل معرف الرسالة للبحث عن السجلات المرتبطة بمعرف حركة النشر. 

مثال: /60129547881 (أثناءless الدخول، أستخدم n للتنقل إلى النتيجة التالية).

مثال على تشغيل الرسالة

مثال على رسالة الفشل

5) قارن الفشل الصحيح بالجدول المرفق لرسائل الأعطال الشائعة.

 وهذا يعني حدوث failed_to_recovery_running_configuration أثناء حالات فشل الاتصال بين الجهازين. 

رسائل الفشل الشائعة

هذه هي رسائل الفشل الشائعة التي يمكن رؤيتها على الطرف الأمامي من رمز الخطأ Management Center Task وكذلك التي يمكن رؤيتها في الطرف الخلفي.

ويمكن تحليل هذه الرسائل ومقارنتها بالأسباب المشتركة لاتخاذ قرارات محتملة.

في حال عدم رؤية هذه الأمور، أو عدم حلها، يرجى الاتصال ب TAC للحصول على المساعدة. 

—

معلومات ذات صلة