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

المقدمة

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

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

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

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

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

توصي Cisco بمعرفة هذه المنتجات:

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

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

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

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

يستخدم برنامج FTD من Cisco Policy Deployments لإدارة عمليات التهيئة للأجهزة المسجلة في Firepower 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 لإعادة التشغيل أو إعادة التحميل لتحميل التكوين الجديد وحفظ جميع التكوينات الحالية.

الخطوة 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 من السجل للعثور على إدخالات السجل المتعلقة بإحدى محاولات النشر المحددة.

22-Nov-2019 01:28:52.844,[INFO],(DefenseCenterServiceImpl.java:1372)
com.cisco.nm.vms.api.dc.DefenseCenterServiceImpl, ajp-nio-127.0.0.1-9009-exec-4
** REST Request [ CSM ]
** ID : e1c84364-0966-42eb-9356-d2914be2b4a3
** URL: Broadcast message.send.deployment
{
  "body" : {
    "property" : "deployment:deployment_initiated_for_the_device",
    "argumentList" : [ {
      "key" : "PHASE",
      "value" : "Phase-0"
    } ]
  },
  "user" : "68d03c42-d9bd-11dc-89f2-b7961d42c462",
  "type" : "deployment",
  "status" : "running",
  "progress" : 5,
  "silent" : true,
  "restart" : true,
  "transactionId" : 12884916552,
  "devices" : [ "93a2089a-fa82-11e9-8219-e1abeec81dc9" ]
}

/var/log/sf/policy_deployment.log

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

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

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

Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO starting populateGlobalSnapshot - sqlite = /var/cisco/umpd/8589938337/DC_policy_deployment.db, transaction = 8589938337, time = 1563470402, running as (memory = 56.35 MB) (Framework 3950<196 <- CSMTasks 223<10 <- SF::ActionQueue 2457)
Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO deployment threading: disabled (Framework 198 <- CSMTasks 223<10 <- SF::ActionQueue 2457)
Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO -> calling SF::UMPD::Plugins::Correlation::Manager::getPluginDependencies (Plugin 298<90 <- Framework 3579<3566<216 <- CSMTasks 223)
...

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

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

إذا تم عزل مشكلة نشر إلى فشل على الجهاز المدار، يمكن تنفيذ المزيد من أستكشاف الأخطاء وإصلاحها على الجهاز باستخدام سجلين على الجهاز: 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 و Transaction ID.

الخطوة 3. بروتوكول SSH في Management Center واستخدم أداة لينوكس less لقراءة الملف كما هو موضح في FMC:

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

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

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

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

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

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

 يحدث i_failed_to_recovery_running_configuration أثناء حالات فشل الاتصال بين الجهازين. 

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

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

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

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

—

الاتصال ب TAC للمساعدة

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

https://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html