أستكشاف أخطاء إستنزاف تنبيهات الصحة المتكررة التي لم تتم معالجتها ل FMC وإصلاحها
المحتويات
المقدمة
يوضح هذا المستند كيفية أستكشاف أخطاء الأحداث التي لم تتم معالجتها وإصلاحها والاستنزاف المتكرر لتنبيهات حماية الحدث في مركز إدارة FirePOWER.
نظرة عامة على المشكلة
يقوم مركز إدارة Firepower (FMC) بإنشاء أحد التنبيهات الصحية التالية:
- الإستنزاف المتكرر للأحداث الموحدة ذات الأولوية المنخفضة
- إستبعاد الأحداث غير المعالجة من الأحداث الموحدة ذات الأولوية المنخفضة
على الرغم من إنشاء هذه الأحداث وإظهارها على وحدة التحكم في إدارة اللوحة الأساسية (FMC)، إلا أنها ترتبط بجهاز محسس مدار سواء كان جهاز دفاع ضد تهديد الطاقة النارية (FTD) أو جهاز من الجيل التالي لنظام منع التسلل (NGIPS). بالنسبة لبقية هذا المستند، يشير مصطلح مستشعر إلى كل من أجهزة FTD و NGIPS ما لم يتم تحديد خلاف ذلك.
هذا هو هيكل التنبيه الصحي:
- إستنزاف متكرر ل <SILO Name>
- إستنزاف الأحداث التي لم تتم معالجتها من <اسم المخزن المؤقت>
في هذا المثال، يكون اسم المجال (SILO) هو أحداث موحدة منخفضة الأولوية. هذا أحد خيارات إدارة الأقراص (راجع قسم "معلومات الخلفية" للحصول على شرح أكثر شمولا).
بالإضافة إلى ذلك:
- على الرغم من أن أي مخزن يمكنه من الناحية التقنية توليد إستنزاف متكرر للتنبيه الصحي ل <SILO Name>، إلا أن أكثر الأحداث التي يتم رؤيتها شيوعا هي تلك المتعلقة بالأحداث، ومن بينها، الأحداث ذات الأولوية المنخفضة ببساطة لأن هذه هي نوع الأحداث التي يتم إنشاؤها بشكل أكبر من قبل أجهزة الاستشعار.
- عبارة عن عملية إستنزاف متكررة لحدث <SILO Name>، لها خطورة تحذير في حالة ما إذا كان لها صوامع مرتبطة بالحدث. إذا تمت معالجة ذلك (يتم بعد ذلك تقديم شرح حول ما يشكل حدثا لم تتم معالجته)، فإنه يتم في قاعدة بيانات FMC.
- بالنسبة لأي مخزن غير متعلق بالحدث، مثل مخزن النسخ الاحتياطي، يكون التنبيه حيويا عند فقد هذه المعلومات.
- تقوم صوامع نوع الحدث فقط بإنشاء إستنزاف للأحداث التي لم تتم معالجتها من تنبيه صحة <SILO NAME>. يكون لهذا التنبيه دائما خطورة حرجة.
الأعراض الإضافية يمكن أن تشمل:
- الخسائر في الأحداث
- بطء واجهة مستخدم FMC
سيناريوهات أستكشاف الأخطاء وإصلاحها الشائعة
ينتج إستنزاف متكرر لحدث <SILO NAME> عن إدخال كمية كبيرة جدا من المخزن لحجمه. في هذه الحالة، تقوم إدارة الأقراص بتصفية (عمليات إزالة) الملف مرتين على الأقل في آخر 5 دقائق من الفاصل الزمني. في مخازن نوع الحدث، يحدث ذلك عادة بسبب التسجيل المفرط لنوع الحدث هذا. إذا كان هناك أحداث لم تتم معالجتها في 'تصفية' الخاصة بالتنبيه الصحي ل <SILO Name>، فقد يحدث ذلك أيضا بسبب حدوث إزدحام في مسار معالجة الحدث.
في الرسم التخطيطي، هناك ثلاثة إختناقات محتملة:
- تم زيادة الاشتراك في عملية EventHandler على FTD (يتم قراءتها بشكل أبطأ من ما يكتبه Snort).
- تم زيادة الاشتراك في واجهة Eventing.
- تم زيادة الاشتراك في عملية SFDataCorrelator على FMC.
لفهم بنية معالجة الحدث، ارجع إلى قسم العمق.
القضية 1 - التسجيل المفرط
وكما ذكر في القسم السابق، فإن أحد الأسباب الأكثر شيوعا للتنبيهات الصحية من هذا النوع هو الإدخال المفرط.
الفرق بين علامة الماء المنخفضة (LWM) وعلامة الماء المرتفع (HWM) (المجموعة من أمر CLISH show لإدارة الأقراص) يوضح مقدار المساحة المطلوبة لأخذ هذا المخزن. للانتقال من LWM (مصفح حديثا) إلى قيمة HWM، إذا كان هناك استبدالات متكررة للأحداث (مع أو بدون أحداث غير معالجة)، يجب مراجعة تكوين التسجيل أولا.
للحصول على شرح متعمق لعملية إدارة الأقراص، ارجع إلى قسم العمق.
سواء كان التسجيل المضاعف أو مجرد معدل مرتفع للأحداث على النظام البيئي الشامل للمدير - المستشعرات، يجب إجراء مراجعة لإعدادات التسجيل.
الإجراءات الموصى بها
الخطوة 1. التحقق من التسجيل المزدوج
يمكن تحديد سيناريوهات التسجيل المزدوج إذا قمت بمراجعة أدائها على وحدة التحكم في إدارة اللوحة الأساسية (FMC) كما هو موضح في هذا الإخراج:
admin@FMC:~$ sudo perfstats -Cq < /var/sf/rna/correlator-stats/now
129 statistics lines read
host limit: 50000 0 50000
pcnt host limit in use: 0.01 0.01 0.01
rna events/second: 0.00 0.00 0.06
user cpu time: 0.48 0.21 10.09
system cpu time: 0.47 0.00 8.83
memory usage: 2547304 0 2547304
resident memory usage: 28201 0 49736
rna flows/second: 126.41 0.00 3844.16
rna dup flows/second: 69.71 0.00 2181.81
ids alerts/second: 0.00 0.00 0.00
ids packets/second: 0.00 0.00 0.00
ids comm records/second: 0.02 0.01 0.03
ids extras/second: 0.00 0.00 0.00
fw_stats/second: 0.00 0.00 0.03
user logins/second: 0.00 0.00 0.00
file events/second: 0.00 0.00 0.00
malware events/second: 0.00 0.00 0.00
fireamp events/second: 0.00 0.00 0.00
في هذا المثال، يمكن رؤية معدل مرتفع للتدفقات المكررة في المخرجات.
الخطوة 2. مراجعة إعدادات تسجيل قائمة التحكم في الوصول (ACP)
يجب أن تبدأ بمراجعة إعدادات التسجيل لنهج التحكم في الوصول (ACP). تأكد من إستخدام أفضل الممارسات الموضحة في أفضل الممارسات لتسجيل الاتصال.
من المستحسن مراجعة إعدادات التسجيل في جميع الحالات لأن التوصيات المدرجة لا تغطي سيناريوهات التسجيل المزدوج فقط.
للتحقق من معدل الأحداث التي تم إنشاؤها على FTD، تحقق من هذا الملف وركز على عمودي TotalEvents و PerSec:
admin@firepower:/ngfw/var/log$ sudo more EventHandlerStats.2023-08-13 | grep Total | more
{"Time": "2023-08-13T00:03:37Z", "TotalEvents": 298, "PerSec": 0, "UserCPUSec": 0.995, "SysCPUSec": 4.598, "%CPU": 1.9, "MemoryKB": 33676}
{"Time": "2023-08-13T00:08:37Z", "TotalEvents": 298, "PerSec": 0, "UserCPUSec": 1.156, "SysCPUSec": 4.280, "%CPU": 1.8, "MemoryKB": 33676}
{"Time": "2023-08-13T00:13:37Z", "TotalEvents": 320, "PerSec": 1, "UserCPUSec": 1.238, "SysCPUSec": 4.221, "%CPU": 1.8, "MemoryKB": 33676}
{"Time": "2023-08-13T00:18:37Z", "TotalEvents": 312, "PerSec": 1, "UserCPUSec": 1.008, "SysCPUSec": 4.427, "%CPU": 1.8, "MemoryKB": 33676}
{"Time": "2023-08-13T00:23:37Z", "TotalEvents": 320, "PerSec": 1, "UserCPUSec": 0.977, "SysCPUSec": 4.465, "%CPU": 1.8, "MemoryKB": 33676}
{"Time": "2023-08-13T00:28:37Z", "TotalEvents": 299, "PerSec": 0, "UserCPUSec": 1.066, "SysCPUSec": 4.361, "%CPU": 1.8, "MemoryKB": 33676}
الخطوة 3. تحقق ما إذا كان التسجيل المفرط متوقعا
يجب مراجعة ما إذا كان التسجيل المفرط له سبب متوقع أم لا. إذا كان التسجيل المفرط سببه هجمات رفض الخدمة (DoS)/رفض الخدمة (DdOS)، أو حلقة التوجيه، أو تطبيق/مضيف معين يحتوي على عدد كبير من الاتصالات؛ يجب عليك التحقق من الاتصالات من مصادر الاتصال غير المتوقعة/الزائدة وتخفيفها/إيقافها.
الخطوة 4. تحقق من ملف diskmanager.log تالف
عادة، يمكن أن يحتوي الإدخال على 12 قيمة مفصولة بفاصلة. للتحقق من السطور التالفة التي تحتوي على عدد مختلف من الحقول:
admin@firepower:/ngfw/var/log$ sudo cat diskmanager.log | awk -F',' 'NF != 12 {print}'
admin@firepower:/ngfw/var/log$
إذا كان هناك سطر تالف به أكثر من 12 حقل يتم عرضه.
الخطوة 5. نموذج الترقية
ترقية جهاز FTD إلى نموذج أداء أعلى (على سبيل المثال، FPR2100— FPR4100)، وبالتالي سيزيد مخزن المصدر.
الخطوة 6. ضع في الاعتبار ما إذا كان يمكنك تعطيل تسجيل الدخول إلى Ramdisk
في حالة وجود مخزن Unified Low Priority Events، يمكنك تعطيل Log to Ramdisk لزيادة حجم الصوامع. يمكنك مراجعة العيوب في قسم الغوص العميق.
الحالة 2 - إختناق في قناة الاتصال بين المستشعر و FMC
سبب آخر مشترك لهذا النوع من التنبيه هو مشاكل الاتصال و/أو عدم الاستقرار في قناة الاتصال (sftunnel) بين المستشعر و FMC. يمكن أن تكون مشكلة الاتصال بسبب:
- تم تجاوز الاشتراك في SFtunnel.
- SFtunnel معطل أو غير مستقر (FLAPS).
بالنسبة لمشكلة اتصال SFTUNNEL، تأكد من توفر إمكانية الوصول إلى FMC والمستشعر بين واجهات الإدارة الخاصة بهما على منفذ TCP 8305.
في FTD، أنت يستطيع بحثت ال sftunneld خيط في ال [/ngfw]/var/log/رسالة مبرد. تتسبب مشاكل الاتصال في إنشاء رسائل مثل هذه:
Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_ch_util [INFO] Delay for heartbeat reply on channel from 10.62.148.75 for 609 seconds. dropChannel... Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_connections [INFO] Ping Event Channel for 10.62.148.75 failed Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_channel [INFO] >> ChannelState dropChannel peer 10.62.148.75 / channelB / EVENT [ msgSock2 & ssl_context2 ] << Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_channel [INFO] >> ChannelState freeChannel peer 10.62.148.75 / channelB / DROPPED [ msgSock2 & ssl_context2 ] << Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_connections [INFO] Need to send SW version and Published Services to 10.62.148.75 Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_peers [INFO] Confirm RPC service in CONTROL channel Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_channel [INFO] >> ChannelState do_dataio_for_heartbeat peer 10.62.148.75 / channelA / CONTROL [ msgSock & ssl_context ] << Sep 9 15:41:48 firepower SF-IMS[5458]: [5464] sftunneld:tunnsockets [INFO] Started listening on port 8305 IPv4(10.62.148.180) management0 Sep 9 15:41:51 firepower SF-IMS[5458]: [27602] sftunneld:control_services [INFO] Successfully Send Interfaces info to peer 10.62.148.75 over managemen Sep 9 15:41:53 firepower SF-IMS[5458]: [5465] sftunneld:sf_connections [INFO] Start connection to : 10.62.148.75 (wait 10 seconds is up) Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_peers [INFO] Peer 10.62.148.75 needs the second connection Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Interface management0 is configured for events on this Device Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Connect to 10.62.148.75 on port 8305 - management0 Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Initiate IPv4 connection to 10.62.148.75 (via management0) Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Initiating IPv4 connection to 10.62.148.75:8305/tcp Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Wait to connect to 8305 (IPv6): 10.62.148.75
يمكن أن يكون الاشتراك الزائد لواجهة إدارة FMCs طفرة في حركة مرور الإدارة أو اشتراكا زائدا دائما. وتشكل البيانات التاريخية المستمدة من تقرير هيث مونيتور مؤشرا جيدا لهذا.
وأول ما يمكن ملاحظته في معظم الحالات هو أنه يتم نشر وحدة التحكم في إدارة الإطارات (FMC) باستخدام بطاقة واجهة شبكة (NIC) واحدة للإدارة. يتم إستخدام هذه الواجهة ل:
- إدارة FMC
- إدارة مستشعر FMC
- مجموعة أحداث FMC من أجهزة الاستشعار
- تحديث موجز ويب للمعلومات الإستخباراتية
- تنزيل تحديثات SRU و Software و VDB و GeoDB من موقع تنزيل البرامج
- الاستعلام عن سمعات URL وفئاته (إن أمكن)
- الاستعلام الخاص بعمليات توزيع الملفات (إذا كان ذلك ممكنا)
الإجراءات الموصى بها
يمكنك نشر بطاقة واجهة شبكة (NIC) ثانية على وحدة التحكم في إدارة اللوحة الأساسية (FMC) من أجل واجهة مخصصة للحدث. تعتمد عمليات التنفيذ على حالة الاستخدام. يمكن العثور على إرشادات عامة في دليل أجهزة FMC - النشر على شبكة الإدارة.
القضية 3 - إختناق في عملية SFDataCorrelator
السيناريو الأخير الذي تمت تغطيته هو عند حدوث إزدحام على جانب SFDataCorrelator (FMC).
الخطوة الأولى هي النظر في ملف diskmanager.log حيث أن هناك معلومات مهمة لتجميع مثل:
- تردد عملية إستنزاف المياه.
- عدد الملفات ذات الأحداث التي لم تتم معالجتها التي تم تسريبها.
-
حدوث عملية إستنزاف مع أحداث لم تتم معالجتها.
أحلت لمعلومة حول ال diskmanager.log مبرد وكيف أن يفسر هو، القرص مدير قسم. يمكن إستخدام المعلومات الواردة من diskmanager.log للمساعدة في تضييق الخطوات التالية.
وبالإضافة إلى ذلك، يجب عليك مراجعة إحصائيات أداء المشرف:
admin@FMC:~$ sudo perfstats -Cq < /var/sf/rna/correlator-stats/now
129 statistics lines read
host limit: 50000 0 50000 pcnt host limit in use: 100.01 100.00 100.55 rna events/second: 1.78 0.00 48.65 user cpu time: 2.14 0.11 58.20 system cpu time: 1.74 0.00 41.13 memory usage: 5010148 0 5138904 resident memory usage: 757165 0 900792 rna flows/second: 101.90 0.00 3388.23 rna dup flows/second: 0.00 0.00 0.00 ids alerts/second: 0.00 0.00 0.00 ids packets/second: 0.00 0.00 0.00 ids comm records/second: 0.02 0.01 0.03 ids extras/second: 0.00 0.00 0.00 fw_stats/second: 0.01 0.00 0.08 user logins/second: 0.00 0.00 0.00 file events/second: 0.00 0.00 0.00 malware events/second: 0.00 0.00 0.00 fireamp events/second: 0.00 0.00 0.01
تتصل هذه الإحصائيات بوحدة إدارة الاتصالات الفيدرالية (FMC) وهي تتوافق مع تجميع كافة أجهزة الاستشعار التي تديرها. في حالة الأحداث الموحدة ذات الأولوية المنخفضة، تبحث بشكل رئيسي عن:
- إجمالي التدفقات في الثانية من أي نوع حدث لتقييم الاشتراك الزائد المحتمل لعملية SFDataCorrelator.
- الصفان المبرزان في المخرج السابق:
- تدفقات rna/الثانية - تشير إلى معدل الأحداث ذات الأولوية المنخفضة التي تمت معالجتها بواسطة SFDataCorrelator.
- تدفقات RNA dup/الثانية - يشير إلى معدل الأحداث المكررة ذات الأولوية المنخفضة التي تمت معالجتها بواسطة SFDataCorrelator. يتم إنشاء ذلك عن طريق التسجيل المزدوج كما هو موضح في السيناريو السابق.
استنادا إلى الناتج، يمكن الاستنتاج بما يلي:
- لا يوجد تسجيل متكرر كما هو موضح بواسطة تدفقات RNA الإضافية/الصف الثاني.
- في تدفقات الرنا/الصف الثاني، تكون القيمة القصوى أعلى بكثير من القيمة المتوسطة، حيث حدث إرتفاع حاد في معدل الأحداث التي تمت معالجتها بواسطة عملية SFDataCorrelator. يمكن توقع هذا إذا قمت بالمراجعة مبكرا في الصباح عندما يكون يوم عمل المستخدمين قد بدأ للتو؛ بشكل عام، هذا علم أحمر ويتطلب المزيد من التحقيق.
يمكن العثور على مزيد من المعلومات حول عملية SFDataCorrelator ضمن قسم معالجة الأحداث.
الإجراءات الموصى بها
اولا، يجب ان تحددوا متى حدث المسمار. للقيام بذلك، يجب مراجعة إحصائيات جهة الاتصال لكل فاصل زمني عينة مدته 5 دقائق. يمكن أن تساعدك المعلومات التي تم تجميعها من diskmanager.log على مراجعة الإطارات الزمنية الحرجة.
admin@FMC:~$ sudo perfstats -C < /var/sf/rna/correlator-stats/now
<OUTPUT OMITTED FOR READABILITY>
Wed Sep 9 16:01:35 2020 host limit: 50000 pcnt host limit in use: 100.14 rna events/second: 24.33 user cpu time: 7.34 system cpu time: 5.66 memory usage: 5007832 resident memory usage: 797168 rna flows/second: 638.55 rna dup flows/second: 0.00 ids alerts/second: 0.00 ids pkts/second: 0.00 ids comm records/second: 0.02 ids extras/second: 0.00 fw stats/second: 0.00 user logins/second: 0.00 file events/second: 0.00 malware events/second: 0.00 fireAMP events/second: 0.00 Wed Sep 9 16:06:39 2020 host limit: 50000 pcnt host limit in use: 100.03 rna events/second: 28.69 user cpu time: 16.04 system cpu time: 11.52 memory usage: 5007832 resident memory usage: 801476 rna flows/second: 685.65 rna dup flows/second: 0.00 ids alerts/second: 0.00 ids pkts/second: 0.00 ids comm records/second: 0.01 ids extras/second: 0.00 fw stats/second: 0.00 user logins/second: 0.00 file events/second: 0.00 malware events/second: 0.00 fireAMP events/second: 0.00 Wed Sep 9 16:11:42 2020 host limit: 50000 pcnt host limit in use: 100.01 rna events/second: 47.51 user cpu time: 16.33 system cpu time: 12.64 memory usage: 5007832 resident memory usage: 809528 rna flows/second: 1488.17 rna dup flows/second: 0.00 ids alerts/second: 0.00 ids pkts/second: 0.00 ids comm records/second: 0.02 ids extras/second: 0.00 fw stats/second: 0.01 user logins/second: 0.00 file events/second: 0.00 malware events/second: 0.00 fireAMP events/second: 0.00 Wed Sep 9 16:16:42 2020 host limit: 50000 pcnt host limit in use: 100.00 rna events/second: 8.57 user cpu time: 58.20 system cpu time: 41.13 memory usage: 5007832 resident memory usage: 837732 rna flows/second: 3388.23 rna dup flows/second: 0.00 ids alerts/second: 0.00 ids pkts/second: 0.00 ids comm records/second: 0.01 ids extras/second: 0.00 fw stats/second: 0.03 user logins/second: 0.00 file events/second: 0.00 malware events/second: 0.00 fireAMP events/second: 0.00 197 statistics lines read host limit: 50000 0 50000 pcnt host limit in use: 100.01 100.00 100.55 rna events/second: 1.78 0.00 48.65 user cpu time: 2.14 0.11 58.20 system cpu time: 1.74 0.00 41.13 memory usage: 5010148 0 5138904 resident memory usage: 757165 0 900792 rna flows/second: 101.90 0.00 3388.23 rna dup flows/second: 0.00 0.00 0.00 ids alerts/second: 0.00 0.00 0.00 ids packets/second: 0.00 0.00 0.00 ids comm records/second: 0.02 0.01 0.03 ids extras/second: 0.00 0.00 0.00 fw_stats/second: 0.01 0.00 0.08 user logins/second: 0.00 0.00 0.00 file events/second: 0.00 0.00 0.00 malware events/second: 0.00 0.00 0.00 fireamp events/second: 0.00 0.00 0.01
أستخدم المعلومات الموجودة في الإخراج إلى:
- تحديد المعدل العادي/الأساسي للأحداث.
- حدد فترة الخمس دقائق التي حدث فيها الارتفاع.
في المثال السابق، هناك إرتفاع واضح في معدل الأحداث التي تم تلقيها في الساعة 16:06:39 وما بعدها. هذه خمسة دقائق متوسطات، لذلك الزيادة يمكن أن تكون أكثر مفاجئة مما هو موضح (انفجار)، على أي حال، أقل في هذه الفترة الزمنية التي تبلغ 5 دقائق إذا بدأت باتجاه نهايتها.
ويؤدي ذلك إلى الاستنتاج بأن هذا الارتفاع الحاد في الأحداث قد أدى إلى إستنزاف الأحداث غير المعالجة. يمكنك مشاهدة اتصال الأحداث من واجهة المستخدم الرسومية (GUI) الخاصة ب FMC باستخدام الإطار الزمني المناسب لفهم نوع الاتصالات التي تجتاز مربع FTD في هذا الارتفاع الحاد:
تطبيق هذا الإطار الزمني لعرض أحداث الاتصال التي تمت تصفيتها (لا تنس حساب المنطقة الزمنية.) في هذا المثال، يستخدم المستشعر UTC و FMC UTC+1. أستخدم طريقة عرض الجدول لعرض الأحداث التي أدت إلى الحمل الزائد للأحداث واتخاذ إجراء وفقا لذلك:
استنادا إلى الطوابع الزمنية (وقت الحزمة الأولى والأخيرة)، يمكن ملاحظة هذه هي الاتصالات القصيرة العمر. تظهر أعمدة حزمة البادئ والمستجيب أنه لم يتم تبادل سوى حزمة واحدة في كل إتجاه. وهذا يؤكد أن الاتصالات كانت قصيرة الأجل، وأنها لم تتبادل سوى بيانات قليلة جدا.
أنت يستطيع رأيت all the flow target ال نفسه مستجيب IPs ومنفذ. كما يتم الإبلاغ عنها جميعا بواسطة نفس المستشعر (الذي يمكن أن تتحدث معلومات واجهة الدخول والخروج إلى مكان واتجاه التدفقات). إجراءات إضافية:
- تحقق من Syslogs على نقطة نهاية الوجهة.
- تنفيذ الحماية ضد رفض الخدمة (DoS)/رفض الخدمة (DoS)، أو إتخاذ تدابير وقائية أخرى.
ملاحظة: الغرض من هذه المقالة هو توفير إرشادات لاستكشاف أخطاء تنبيهات الأحداث غير المعالجة وإصلاحها. أستخدم هذا المثال hping3 لإنشاء تدفق TCP SYN إلى الخادم الوجهة. للحصول على إرشادات لتعزيز جهاز FTD الخاص بك، ارجع إلى دليل تقوية الدفاع ضد تهديد FirePOWER من Cisco.
العناصر المطلوب تجميعها قبل الاتصال بمركز المساعدة التقنية (TAC) من Cisco
ينصح بشدة بجمع هذه العناصر قبل الاتصال ب Cisco TAC:
- لقطة شاشة (لقطات) للتنبيهات الصحية التي تم رؤيتها.
- أستكشاف أخطاء الملف الذي تم إنشاؤه من وحدة التحكم في إدارة اللوحة الأساسية (FMC) وإصلاحها.
- أستكشاف أخطاء الملف الذي تم إنشاؤه من أداة الاستشعار المتأثرة وإصلاحها.
- تاريخ ووقت بدء المشكلة لأول مرة.
- معلومات حول أي تغييرات تم إجراؤها مؤخرا على السياسات (إن أمكن).
- مخرجات الأمر stats_unified.pl كما هو موضح في قسم معالجة الأحداث (مع ذكر أجهزة الاستشعار المتأثرة).
التعمُّق
يغطي هذا القسم شرحا متعمقا لمختلف المكونات التي يمكن أن تشارك في أنواع التنبيهات الصحية. ويشمل ذلك ما يلي:
- معالجة الحدث: يغطي أحداث المسار التي تأخذ على كل من أجهزة الاستشعار و FMC. ويكون هذا مفيدا بشكل رئيسي عندما يشير تنبيه الصحة إلى مخزن نوع الحدث.
- إدارة الأقراص: يغطي عملية إدارة الأقراص والصوامع وكيفية تصفيتها.
- مراقبة الصحة: يغطي كيفية إستخدام وحدات Health Monitor لإنشاء تنبيهات الحماية.
- تسجيل الدخول إلى Ramdisk: يغطي ميزة التسجيل إلى ramDisk وتأثيرها المحتمل على تنبيهات الحماية.
لفهم تنبيهات حماية "إستنزاف الأحداث" وتحديد نقاط الأعطال المحتملة، يجب عليك النظر في كيفية عمل هذه المكونات والتفاعل فيما بينها.
معالجة الحدث
بينما يمكن تشغيل نوع التنبيهات الصحية "التنزيل المتكرر" بواسطة صوامع غير مرتبطة بالأحداث، فإن الغالبية العظمى من الحالات التي تم رؤيتها من قبل Cisco TAC مرتبطة بالمعلومات المتعلقة بحدث التنزيل. بالإضافة إلى ذلك، لفهم ما يشكل استنزافا للأحداث غير المعالجة، يتعين عليك النظر إلى بنية معالجة الحدث ومكوناتها.
عندما يستقبل مستشعر FirePOWER حزمة من اتصال جديد، تولد عملية النخر حدثا بتنسيق Unified2 والذي هو تنسيق ثنائي يسمح بالقراءة/الكتابة بشكل أسرع، بالإضافة إلى الأحداث الأخف.
يعرض الإخراج تتبع دعم نظام أمر FTD، حيث يمكنك رؤية إنشاء اتصال جديد. وتسلط الأضواء على الأجزاء الهامة وتشرح:
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 Packet: TCP, SYN, seq 3310981951
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 Session: new snort session
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 AppID: service unknown (0), application unknown (0)
192.168.0.2-42310 > 192.168.1.10-80 6 AS 1-1 I 0 new firewall session
192.168.0.2-42310 > 192.168.1.10-80 6 AS 1-1 I 0 using HW or preset rule order 4, 'Default Inspection', action Allow and prefilter rule 0
192.168.0.2-42310 > 192.168.1.10-80 6 AS 1-1 I 0 HitCount data sent for rule id: 268437505,
192.168.0.2-42310 > 192.168.1.10-80 6 AS 1-1 I 0 allow action
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 Firewall: allow rule, 'Default Inspection', allow
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 Snort id 0, NAP id 1, IPS id 0, Verdict PASS
يتم إنشاء ملفات snort unified_events لكل مثيل ضمن المسار [/ngfw]var/sf/detection_engine/*/instance-N/، حيث:
- * هو Snort uid. هذا فريد لكل جهاز.
- N هو معرف مثيل Snort الذي يمكن حسابه على أنه معرف المثيل من الإخراج السابق (الذي تم تمييزه بمقدار 0 في المثال) + 1
يمكن أن يكون هناك نوعان من ملفات unified_events في أي مجلد مثيل Snort محدد:
- unified_events-1 (الذي يحتوي على أحداث ذات أولوية عالية.)
- unified_events-2 (الذي يحتوي على أحداث ذات أولوية منخفضة.)
الحدث ذو الأولوية العالية، هو حدث يتوافق مع اتصال ضار محتمل.
أنواع الأحداث وأولويتها:
| أولوية عالية (1) |
أولوية منخفضة (2) |
| إقتحام |
الاتصال |
| برمجيات خبيثة |
إكتشاف |
| الإستخبارات الأمنية |
ملف |
| أحداث الاتصال المقترنة |
الإحصائيات |
يعرض الإخراج التالي حدثا ينتمي إلى الاتصال الجديد الذي تم تتبعه في المثال السابق. التنسيق موحد 2 ويأخذ من مخرجات كل سجل حدث موحد يقع ضمن [/ngfw]/var/sf/detection_engine/*/instance-1/ حيث 1 هو معرف مثيل snort بالخط الأسود في الإخراج السابق +1. يستخدم اسم تنسيق سجل الأحداث الموحد بناء جملة unified_events-2.log.1599654750 حيث يمثل إثنان أولوية الأحداث كما هو موضح في الجدول والجزء الأخير بالخط الأسود (1599654750) هو الطابع الزمني (Unix) عند إنشاء الملف.
تلميح: يمكنك إستخدام أمر تاريخ Linux لتحويل وقت Unix إلى تاريخ يمكن قراءته:
admin@FP1120-2:~$ sudo date -d@1599654750
سبتمبر المتزوج 9:32:30 ص 2020
Unified2 Record at offset 2190389
Type: 210(0x000000d2)
Timestamp: 0
Length: 765 bytes
Forward to DC: Yes
FlowStats:
Sensor ID: 0
Service: 676
NetBIOS Domain: <none>
Client App: 909, Version: 1.20.3 (linux-gnu)
Protocol: TCP
Initiator Port: 42310
Responder Port: 80
First Packet: (1599662092) Tue Sep 9 14:34:52 2020
Last Packet: (1599662092) Tue Sep 9 14:34:52 2020
<OUTPUT OMITTED FOR READABILITY>
Initiator: 192.168.0.2
Responder: 192.168.1.10
Original Client: ::
Policy Revision: 00000000-0000-0000-0000-00005f502a92
Rule ID: 268437505
Tunnel Rule ID: 0
Monitor Rule ID: <none>
Rule Action: 2
بجانب كل ملف Unified_events، هناك ملف إشارة مرجعية يحتوي على قيمتين مهمتين:
- مراسل الطابع الزمني لملف unified_events الحالي لذلك المثيل والأولوية.
- الموضع بالبايت لحدث القراءة الأخير في ملف unified_event.
يتم فصل القيم بفاصلة بالترتيب، كما هو موضح في هذا المثال:
root@FTD:/home/admin# cat /var/sf/detection_engines/d5a4d5d0-6ddf-11ea-b364-2ac815c16717/instance-1/unified_events-2.log.bookmark.1a3d52e6-3e09-11ea-838f-68e7af919059
1599862498, 18754115
وهذا يسمح لعملية إدارة الأقراص بمعرفة الأحداث التي تمت معالجتها بالفعل (والتي تم إرسالها إلى FMC) والأحداث التي لم تتم معالجتها.
ملاحظة: عندما تقوم إدارة الأقراص بمسح مخزن أحداث، فإنها تزيل ملفات حدث موحدة.
للحصول على مزيد من المعلومات حول عملية تصفية وحدات التخزين (SILOS)، ارجع إلى قسم إدارة الأقراص.
يعد الملف الموحد الذي تم إستنزافه يحتوي على أحداث لم تتم معالجتها عندما يكون أحد هذه الأحداث صحيحا:
- الطابع الزمني للإشارة المرجعية أقل من وقت إنشاء الملف.
- يكون الطابع الزمني للإشارة المرجعية هو نفس وقت إنشاء الملف والموضع بالبايت في الملف أقل من حجمه.
تقرأ عملية EventHandler الأحداث من الملفات الموحدة وتدفقها إلى FMC (على هيئة بيانات أولية) عبر SFTUNNEL، وهي العملية المسؤولة عن الاتصال المشفر بين المستشعر و FMC. هذا اتصال يستند إلى TCP، لذلك يتم التعرف على دفق الحدث بواسطة FMC
أنت يستطيع رأيت هذا رسالة في ال [/ngfw]/var/log/رسالة مبرد:
sfpreproc:OutputFile [INFO] *** Opening /ngfw/var/sf/detection_engines/77d31ce2-c2fc-11ea-b470-d428d53ed3ae/instance-1/unified_events-2.log.1597810478 for output" in /var/log/messages
EventHandler:SpoolIterator [INFO] Opened unified event file /var/sf/detection_engines/77d31ce2-c2fc-11ea-b470-d428d53ed3ae/instance-1/unified_events-2.log.1597810478
sftunneld:FileUtils [INFO] Processed 10334 events from log file var/sf/detection_engines/77d31ce2-c2fc-11ea-b470-d428d53ed3ae/instance-1/unified_events-2.log.1597810478
يوفر هذا الإخراج:
- فتح snort ملف unified_events للمخرجات (للكتابة فيه).
- قام "معالج الأحداث" بفتح الملف unified_events نفسه (للقراءة منه).
- قام sftunnel بالإعلام عن عدد الأحداث التي تمت معالجتها من ملف unified_events هذا.
يتم بعد ذلك تحديث ملف الإشارة المرجعية وفقا لذلك. يستخدم SFtunnel قناتين مختلفتين تدعيان قناة الأحداث الموحدة (UE) 0 و 1 للأحداث ذات الأولوية العالية والمنخفضة على التوالي.
باستخدام أمر واجهة سطر الأوامر (CLI) sfunnel_status على FTD، يمكنك عرض عدد الأحداث التي تم تدفقها.
Priority UE Channel 1 service
TOTAL TRANSMITTED MESSAGES <530541> for UE Channel service
RECEIVED MESSAGES <424712> for UE Channel service
SEND MESSAGES <105829> for UE Channel service
FAILED MESSAGES <0> for UE Channel service
HALT REQUEST SEND COUNTER <17332> for UE Channel service
STORED MESSAGES for UE Channel service (service 0/peer 0)
STATE <Process messages> for UE Channel service
REQUESTED FOR REMOTE <Process messages> for UE Channel service
REQUESTED FROM REMOTE <Process messages> for UE Channel service
في FMC، يتم إستلام الأحداث بواسطة عملية SFDataCorrelator. يمكن ملاحظة حالة الأحداث التي تمت معالجتها من كل مستشعر من خلال تشغيل الأمر stats_unified.pl:
admin@FMC:~$ sudo stats_unified.pl
Current Time - Fri Sep 9 23:00:47 UTC 2020
**********************************************************************************
* FTD - 60a0526e-6ddf-11ea-99fa-89a415c16717, version 6.6.0.1
**********************************************************************************
Channel Backlog Statistics (unified_event_backlog)
Chan Last Time Bookmark Time Bytes Behind
0 2020-09-09 23:00:30 2020-09-07 10:41:50 0
1 2020-09-09 23:00:30 2020-09-09 22:14:58 6960
يبدي هذا أمر الحالة من التراكم حدث لجهاز معين لكل قناة ومعرف القناة يستعمل ال نفسه بما أن ال sftunnel. يمكن حساب قيمة وحدات البايت الخلف كفرق بين الموضع الظاهر في ملف الإشارة المرجعية للحدث الموحد وحجم ملف الحدث الموحد (بالإضافة إلى أي ملف لاحق له طابع زمني أعلى من الملف الموجود في ملف الإشارة المرجعية).
تقوم عملية SFDataCorrelator أيضا بتخزين إحصائيات الأداء، والتي يتم حفظها في /var/sf/rna/correlator-stats/. يتم إنشاء ملف واحد في اليوم لتخزين إحصائيات الأداء لذلك اليوم بتنسيق CSV. يستخدم اسم الملف التنسيق YYYYY-MM-DD ويتم إستدعاء مراسل الملف إلى اليوم الآن.
وتجمع الإحصاءات كل 5 دقائق (هناك خط واحد لكل فترة خمس دقائق).
يمكن قراءة مخرجات هذا الملف بتشغيل الأمر perfstats.
ملاحظة: كما يتم إستخدام هذا الأمر لقراءة ملفات إحصائيات أداء الشوربة، لذا يجب إستخدام العلامات المناسبة.
-ج: يرشد العدالات إن الإدخال هو ملف Correlator-stats (بدون هذه العلامة، يفترض العدلاء أن الإدخال هو ملف إحصائيات أداء snort).
-س: يقوم الوضع "هادئ" بطباعة الملخص فقط للملف.
admin@FMC:~$ sudo perfstats -Cq < /var/sf/rna/correlator-stats/now
287 statistics lines read
host limit: 50000 0 50000
pcnt host limit in use: 100.01 100.00 100.55
rna events/second: 1.22 0.00 48.65
user cpu time: 1.56 0.11 58.20
system cpu time: 1.31 0.00 41.13
memory usage: 5050384 0 5138904
resident memory usage: 801920 0 901424
rna flows/second: 64.06 0.00 348.15
rna dup flows/second: 0.00 0.00 37.05
ids alerts/second: 1.49 0.00 4.63
ids packets/second: 1.71 0.00 10.10
ids comm records/second: 3.24 0.00 12.63
ids extras/second: 0.01 0.00 0.07
fw_stats/second: 1.78 0.00 5.72
user logins/second: 0.00 0.00 0.00
file events/second: 0.00 0.00 3.25
malware events/second: 0.00 0.00 0.06
fireamp events/second: 0.00 0.00 0.00
يحتوي كل صف في الملخص على ثلاث قيم بهذا الترتيب: المتوسط، الحد الأدنى، الحد الأقصى.
إذا قمت بالطباعة بدون علامة -q، فسترى أيضا قيم الفاصل الزمني لمدة 5 دقائق (سيتم عرض الملخص في النهاية).
ملاحظة: تحتوي كل وحدة من وحدات التحكم في إدارة الهيكل (FMC) على الحد الأقصى لمعدل التدفق الموضح في ورقة البيانات الخاصة بها. يحتوي الجدول التالي على القيم لكل وحدة نمطية مأخوذة من ورقة البيانات ذات الصلة.
| الطراز |
FMC 750 |
FMC 1000 |
FMC 1600 |
FMC 2000 |
FMC 2500 |
FMC 2600 |
FMC 4000 |
FMC 4500 |
FMC 4600 |
FMCv |
FMCv300 |
| الحد الأقصى لمعدل التدفق (FPS) |
2000 |
5000 |
5000 |
12000 |
12000 |
12000 |
20000 |
20000 |
20000 |
متغير |
12000 |
ملاحظة: تكون هذه القيم خاصة بتجميع جميع أنواع الأحداث الموضحة بالأسود في إخراج إحصائيات SFDataCorrelator.
إذا نظرت إلى المخرجات وقمت بحساب حجم FMC الذي أنت مستعد لسيناريو أسوأ الحالات (عندما تحدث كل القيم القصوى في نفس الوقت)، فإن معدل الأحداث الذي تراه FMC هو 48.65 + 348.15 + 4.63 + 3.25 + 0.06 = 404.74 إطار بالثانية.
يمكن مقارنة القيمة الإجمالية بالقيمة من ورقة البيانات الخاصة بالنموذج ذي الصلة.
كما يمكن أن يقوم SFDataCorrelator بعمل إضافي على رأس الأحداث المستلمة (مثل قواعد الارتباط)، ثم يقوم بتخزينها في قاعدة البيانات، والتي يتم الاستعلام عنها لنشر معلومات مختلفة في واجهة المستخدم الرسومية (GUI) ل FMC، مثل لوحات المعلومات وعروض الأحداث.
إدارة الأقراص
يوضح الرسم التخطيطي التالي المكونات المنطقية لكل من عمليتي Health Monitor و Disk Manager عند تداخلها لإنشاء تنبيهات الحماية المتعلقة بالقرص.
باختصار، تقوم عملية إدارة الأقراص بإدارة إستخدام القرص الخاص بالمربع، كما أنها تحتوي على ملفات التكوين الخاصة به في المجلد [/ngfw]/etc/sf/. هناك ملفات تكوين متعددة لعملية إدارة الأقراص يتم إستخدامها في ظروف معينة:
- diskmanager.conf: ملف التكوين القياسي.
- diskmanager_2hd.conf: يتم إستخدامه عندما يحتوي المربع على محركي أقراص ثابتة مثبتين. ومحرك الأقراص الصلبة الثاني هو ذلك المرتبط بتوسعة البرامج الضارة الذي يتم إستخدامه لتخزين الملفات كما هو محدد في نهج الملف.
- ramdisk-diskmanager.conf: يستخدم عند تمكين السجل إلى Ramdisk. راجع قسم السجل إلى Ramdisk.
يتم مراقبة كل نوع من الملفات بواسطة إدارة الأقراص التي تم تعيين مخزن لها. بناء على مساحة القرص المتوفرة على النظام، يقوم مدير الأقراص بحساب علامة ماء عالية (HWM) وعلامة ماء منخفضة (LWM) لكل مخزن. عندما تقوم عملية "إدارة الأقراص" بتصفية مخزن، فإنها تقوم بذلك حتى يتم الوصول إلى وحدة LWM. ونظرا لأنه يتم تصفية الأحداث لكل ملف، يمكن تجاوز هذا الحد.
للتحقق من حالة صوامع التخزين على جهاز إستشعار، يمكنك تشغيل هذا الأمر:
> show disk-manager Silo Used Minimum Maximum misc_fdm_logs 0 KB 65.208 MB 130.417 MB Temporary Files 0 KB 108.681 MB 434.726 MB Action Queue Results 0 KB 108.681 MB 434.726 MB User Identity Events 0 KB 108.681 MB 434.726 MB UI Caches 4 KB 326.044 MB 652.089 MB Backups 0 KB 869.452 MB 2.123 GB Updates 304.367 MB 1.274 GB 3.184 GB Other Detection Engine 0 KB 652.089 MB 1.274 GB Performance Statistics 45.985 MB 217.362 MB 2.547 GB Other Events 0 KB 434.726 MB 869.452 MB IP Reputation & URL Filtering 0 KB 543.407 MB 1.061 GB arch_debug_file 0 KB 2.123 GB 12.736 GB Archives & Cores & File Logs 0 KB 869.452 MB 4.245 GB Unified Low Priority Events 974.109 MB 1.061 GB 5.307 GB RNA Events 879 KB 869.452 MB 3.396 GB File Capture 0 KB 2.123 GB 4.245 GB Unified High Priority Events 252 KB 3.184 GB 7.429 GB IPS Events 3.023 MB 2.547 GB 6.368 GB
يتم تشغيل عملية "إدارة الأقراص" عند استيفاء أحد هذه الشروط:
في كل مرة يتم فيها تشغيل عملية "إدارة الأقراص"، فإنها تقوم بإنشاء إدخال لكل وحدة تخزين مختلفة في ملف السجل الخاص بها الذي يقع ضمن [/ngfw]/var/log/diskmanager.log ويحتوي على بيانات بتنسيق CSV.
بعد ذلك، يتم عرض نموذج للسطر من ملف diskmanager.log. تم اقتباسه من جهاز إستشعار تسبب في إستنزاف الأحداث غير المعالجة من "التنبيه الصحي للأحداث الموحدة ذات الأولوية المنخفضة"، بالإضافة إلى تصنيف الأعمدة ذات الصلة:
priority_2_events,1599668981,221,4587929508,1132501868,20972020,4596,1586044534,5710966962,1142193392,110,0
| عمود | القيمة |
| تسمية المخزن |
priority_2_events |
| زمن التصريف (الزمن الافتراضي) |
1599668981 |
| عدد الملفات التي تم تصفيتها | 221 |
| وحدات البايت التي تم تصفيتها | 4587929508 |
| الحجم الحالي للبيانات بعد عملية السحب (بالبايت) | 1132501868 |
| أكبر ملف تم تجفيره (بالبايت) | 20972020 |
| أصغر ملف تم تجفيره (بالبايت) | 4596 |
| أقدم ملف تم تجفيره (الوقت المستغرق في epoch) | 1586044534 |
| علامة مائية عالية (بايت) | 5710966962 |
| علامة مائية منخفضة (بايت) | 1142193392 |
| عدد الملفات ذات الأحداث التي لم تتم معالجتها التي تم تصفيتها | 110 |
| علم حالة Diskmanager | 0 |
ثم تقرأ هذه المعلومات بواسطة وحدة مراقبة الصحة المعنية لتشغيل التنبيه الصحي ذي الصلة.
املأ صوامع المياه يدويا
في سيناريوهات معينة، يمكنك إستنزاف سايلو يدويا. على سبيل المثال، لمسح مساحة القرص باستخدام ميزة "التخلص اليدوي من المخزن المؤقت"، تستفيد عمليات إزالة الملفات اليدوية من السماح لمدير القرص بتحديد الملفات التي يجب الاحتفاظ بها والملفات التي يجب حذفها. تقوم إدارة الأقراص بحفظ أحدث الملفات لهذا المخزن.
يمكن إستنزاف أي مخزن وهذا يعمل كما هو موضح (تقوم إدارة الأقراص بتصفية البيانات حتى يتم تدفق كمية البيانات أسفل حد LWM). يتوفر الأمر system support silo-drain في وضع CLISH ل FTD ويوفر قائمة بالوحدات المتاحة (الاسم + المعرف الرقمي).
هذا مثال على عملية إستنزاف يدوية لمكدس أحداث Unified Low Priority Events:
> show disk-manager Silo Used Minimum Maximum misc_fdm_logs 0 KB 65.213 MB 130.426 MB Temporary Files 0 KB 108.688 MB 434.753 MB Action Queue Results 0 KB 108.688 MB 434.753 MB User Identity Events 0 KB 108.688 MB 434.753 MB UI Caches 4 KB 326.064 MB 652.130 MB Backups 0 KB 869.507 MB 2.123 GB Updates 304.367 MB 1.274 GB 3.184 GB Other Detection Engine 0 KB 652.130 MB 1.274 GB Performance Statistics 1.002 MB 217.376 MB 2.547 GB Other Events 0 KB 434.753 MB 869.507 MB IP Reputation & URL Filtering 0 KB 543.441 MB 1.061 GB arch_debug_file 0 KB 2.123 GB 12.737 GB Archives & Cores & File Logs 0 KB 869.507 MB 4.246 GB Unified Low Priority Events 2.397 GB 1.061 GB 5.307 GB RNA Events 8 KB 869.507 MB 3.397 GB File Capture 0 KB 2.123 GB 4.246 GB Unified High Priority Events 0 KB 3.184 GB 7.430 GB IPS Events 0 KB 2.547 GB 6.368 GB > system support silo-drain Available Silos 1 - misc_fdm_logs 2 - Temporary Files 3 - Action Queue Results 4 - User Identity Events 5 - UI Caches 6 - Backups 7 - Updates 8 - Other Detection Engine 9 - Performance Statistics 10 - Other Events 11 - IP Reputation & URL Filtering 12 - arch_debug_file 13 - Archives & Cores & File Logs 14 - Unified Low Priority Events 15 - RNA Events 16 - File Capture 17 - Unified High Priority Events 18 - IPS Events 0 - Cancel and return Select a Silo to drain: 14 Silo Unified Low Priority Events being drained. > show disk-manager Silo Used Minimum Maximum misc_fdm_logs 0 KB 65.213 MB 130.426 MB Temporary Files 0 KB 108.688 MB 434.753 MB Action Queue Results 0 KB 108.688 MB 434.753 MB User Identity Events 0 KB 108.688 MB 434.753 MB UI Caches 4 KB 326.064 MB 652.130 MB Backups 0 KB 869.507 MB 2.123 GB Updates 304.367 MB 1.274 GB 3.184 GB Other Detection Engine 0 KB 652.130 MB 1.274 GB Performance Statistics 1.002 MB 217.376 MB 2.547 GB Other Events 0 KB 434.753 MB 869.507 MB IP Reputation & URL Filtering 0 KB 543.441 MB 1.061 GB arch_debug_file 0 KB 2.123 GB 12.737 GB Archives & Cores & File Logs 0 KB 869.507 MB 4.246 GB Unified Low Priority Events 1.046 GB 1.061 GB 5.307 GB RNA Events 8 KB 869.507 MB 3.397 GB File Capture 0 KB 2.123 GB 4.246 GB Unified High Priority Events 0 KB 3.184 GB 7.430 GB IPS Events 0 KB 2.547 GB 6.368 GB
مرقاب صحي
هذه هي النقاط الرئيسية:
- يتم إنشاء أي تنبيه صحي يظهر على FMC في قائمة Health Monitor أو تحت علامة التبويب Health في مركز الرسائل بواسطة عملية Health Monitor.
- تراقب هذه العملية سلامة النظام، بالنسبة لكل من وحدة إدارة اللوحة الأساسية (FMC) وأجهزة الاستشعار المدارة وتتألف من عدد من الوحدات المختلفة.
- يتم تحديد وحدات التنبيه الصحي في نهج الصحة، والتي يمكن إرفاقها لكل جهاز.
- يتم إنشاء تنبيهات الحماية بواسطة وحدة "إستخدام القرص" التي يمكن تشغيلها على كل جهاز من أجهزة الاستشعار المدارة بواسطة FMC.
- عند تشغيل عملية Health Monitor على FMC (مرة كل 5 دقائق أو عند تشغيل تشغيل يدوي)، تقوم الوحدة النمطية لاستخدام القرص بفحص ملف diskmanager.log، وإذا تم استيفاء الشروط الصحيحة، يتم تشغيل تنبيه الصحة الخاص.
لتنبيه صحة الأحداث غير المعالجة ليتم تشغيله، يجب أن تكون جميع هذه الشروط صحيحة:
- حقل وحدات البايت التي تم تسريبها أكبر من 0 (هذا يشير إلى أن البيانات من هذا المخزن تم تسريبه).
- عدد الملفات ذات الأحداث التي لم تتم معالجتها التي تم استنفادها أكبر من 0 (وهذا يشير إلى وجود أحداث لم تتم معالجتها داخل البيانات التي تم استنفادها).
- وقت النزيف في غضون الساعة الواحدة الأخيرة.
لتنبيه صحة الأحداث بشكل متكرر، يجب أن تكون هذه الشروط صحيحة:
- يجب أن يكون آخر إدخالين على ملف diskmanager.log صحيحا:
- حقل وحدات البايت التي تم تسريبها أكبر من 0 (هذا يشير إلى أن البيانات من هذا المخزن تم تسريبه).
- كن أقل من 5 دقائق متباعدا.
- وقت التصريف في الإدخال الأخير لهذا المخزن خلال الساعة الواحدة الأخيرة.
يتم إرسال النتائج التي تم تجميعها من وحدة إستخدام القرص (والنتائج التي تم تجميعها بواسطة وحدات أخرى) إلى FMC عبر SFTUNNEL. يمكنك رؤية عدادات أحداث الصحة المتبادلة عبر sftunnel عن طريق تشغيل الأمر sftunnel_status:
TOTAL TRANSMITTED MESSAGES <3544> for Health Events service
RECEIVED MESSAGES <1772> for Health Events service
SEND MESSAGES <1772> for Health Events service
FAILED MESSAGES <0> for Health Events service
HALT REQUEST SEND COUNTER <0> for Health Events service
STORED MESSAGES for Health service (service 0/peer 0)
STATE <Process messages> for Health Events service
REQUESTED FOR REMOTE <Process messages> for Health Events service
REQUESTED FROM REMOTE <Process messages> for Health Events service
تسجيل الدخول إلى Ramdisk
في حين يتم تخزين معظم الأحداث في القرص، يتم تكوين الجهاز بشكل افتراضي لتسجيل الدخول إلى القرص الثابت لمنع التلف التدريجي لمحركات الأقراص الصلبة (SSD) الذي يمكن أن يحدث بسبب عمليات الكتابة والحذف المستمرة للأحداث إلى القرص.
في هذا السيناريو، لا يتم تخزين الأحداث تحت [/ngfw]/var/sf/detection_engine/*/instance-N/، ومع ذلك، فإنها تقع في [/ngfw]/var/sf/detection_engines/*/instance-N/connection/، والتي تعد إرتباطا رمزيا ب /dev/shm/instance-N/connection. في هذه الحالة، تكمن الأحداث في الذاكرة الافتراضية بدلا من المادية.
admin@FTD4140:~$ ls -la /ngfw/var/sf/detection_engines/b0c4a5a4-de25-11ea-8ec3-4df4ea7207e3/instance-1/connection
lrwxrwxrwx 1 sfsnort sfsnort 30 Sep 9 19:03 /ngfw/var/sf/detection_engines/b0c4a5a4-de25-11ea-8ec3-4df4ea7207e3/instance-1/connection -> /dev/shm/instance-1/connection
للتحقق من الجهاز الذي تم تكوينه حاليا لتشغيل الأمر show log-events-to-ramdisk من واجهة سطر أوامر FTD. يمكنك أيضا تغيير هذا إذا قمت بتشغيل الأمر configure log-events-to-ramdisk <enable/disable>:
> show log-events-to-ramdisk
Logging connection events to RAM Disk.
> configure log-events-to-ramdisk
Enable or Disable enable or disable (enable/disable)
تحذير: عند تنفيذ الأمر configure log-events-to-ramdisk disable، هناك حاجة لإتمام عمليتي نشر على FTD لكي لا يعلق الشخر في حالة D (سكون غير متقطع)، مما قد يتسبب في انقطاع حركة المرور.
يتم توثيق هذا السلوك باستخدام معرف تصحيح الأخطاء من Cisco CSCvz53372. مع النشر الأول، يتم تخطي إعادة تقييم مرحلة ذاكرة snort، مما يؤدي إلى ظهور snort في حالة D. الحل البديل هو إنشاء عملية نشر أخرى مع أية تغييرات وهمية.
عندما تقوم بتسجيل الدخول إلى ذاكرة التخزين المؤقت، يكون العائق الرئيسي هو تخصيص مساحة أصغر للهواء الخاص بك ويتم إستيعابها أكثر في ظل نفس الظروف. الإخراج التالي هو "إدارة الأقراص" من FPR 4140 مع تمكين أحداث السجل أو بدونها على Ramdisk للمقارنة.
تم تمكين التسجيل إلى Ramdisk:
> show disk-manager
Silo Used Minimum Maximum
Temporary Files 0 KB 903.803 MB 3.530 GB
Action Queue Results 0 KB 903.803 MB 3.530 GB
User Identity Events 0 KB 903.803 MB 3.530 GB
UI Caches 4 KB 2.648 GB 5.296 GB
Backups 0 KB 7.061 GB 17.652 GB
Updates 305.723 MB 10.591 GB 26.479 GB
Other Detection Engine 0 KB 5.296 GB 10.591 GB
Performance Statistics 19.616 MB 1.765 GB 21.183 GB
Other Events 0 KB 3.530 GB 7.061 GB
IP Reputation & URL Filtering 0 KB 4.413 GB 8.826 GB
arch_debug_file 0 KB 17.652 GB 105.914 GB
Archives & Cores & File Logs 0 KB 7.061 GB 35.305 GB
RNA Events 0 KB 7.061 GB 28.244 GB
File Capture 0 KB 17.652 GB 35.305 GB
Unified High Priority Events 0 KB 17.652 GB 30.892 GB
Connection Events 0 KB 451.698 MB 903.396 MB
IPS Events 0 KB 12.357 GB 26.479 GB
تم تعطيل التسجيل إلى Ramdisk:
> show disk-manager
Silo Used Minimum Maximum
Temporary Files 0 KB 976.564 MB 3.815 GB
Action Queue Results 0 KB 976.564 MB 3.815 GB
User Identity Events 0 KB 976.564 MB 3.815 GB
UI Caches 4 KB 2.861 GB 5.722 GB
Backups 0 KB 7.629 GB 19.074 GB
Updates 305.723 MB 11.444 GB 28.610 GB
Other Detection Engine 0 KB 5.722 GB 11.444 GB
Performance Statistics 19.616 MB 1.907 GB 22.888 GB
Other Events 0 KB 3.815 GB 7.629 GB
IP Reputation & URL Filtering 0 KB 4.768 GB 9.537 GB
arch_debug_file 0 KB 19.074 GB 114.441 GB
Archives & Cores & File Logs 0 KB 7.629 GB 38.147 GB
Unified Low Priority Events 0 KB 9.537 GB 47.684 GB
RNA Events 0 KB 7.629 GB 30.518 GB
File Capture 0 KB 19.074 GB 38.147 GB
Unified High Priority Events 0 KB 19.074 GB 33.379 GB
IPS Events 0 KB 13.351 GB 28.610 GB
أما الحجم الأصغر للهواتف فيتم تعويضه بسرعة أعلى للوصول إلى الأحداث وتدفقها إلى وحدة التحكم في إدارة الاتصالات الفيدرالية (FMC). وهو خيار أفضل في ظل ظروف لائقة، في حين يتعين علينا أن ننظر في إحتمالات العودة.
الأسئلة المتداولة (FAQ)
س: هل تنبيهات صحة "إستنزاف الأحداث" تم إنشاؤها فقط بواسطة "أحداث الاتصال"؟
أ: لا.
- يمكن إنشاء تنبيهات "التخلص المتكرر" بواسطة أي مخزن لإدارة الأقراص.
- يمكن إنشاء التنبيهات الخاصة باستنزاف الأحداث التي لم تتم معالجتها بواسطة أي مخزن خاص بالأحداث. تعد "أحداث الاتصال" السبب الأكثر شيوعا.
س: هل من المستحسن دائما تعطيل سجل إلى Ramdisk عند ظهور تنبيه صحة "إستنزاف متكرر"؟
أ: لا. فقط في سيناريوهات التسجيل الزائدة، باستثناء DoS/DDo عندما يكون المخزن المؤقت المتأثر هو مخزن أحداث الاتصال، وفقط في الحالات التي لا يمكن فيها ضبط إعدادات التسجيل بشكل إضافي. إذا كانت رفض الخدمة (DoS)/رفض الخدمة (DoS) يؤدي إلى تسجيل مفرط، فإن الحل يكمن في تنفيذ حماية رفض الخدمة (DoS) أو القضاء على مصدر (مصادر) هجمات رفض الخدمة (DoS)/رفض الخدمة (DoS).
يقلل سجل الميزات الافتراضي إلى Ramdisk من إستهلاك محركات الأقراص المزودة بذاكرة مصنوعة من مكونات صلبة، لذلك يوصى بشدة باستخدامه.
س: ما الذي يشكل حدثا لم تتم معالجته بعد؟
أ: لا يتم تمييز الأحداث بشكل فردي كغير معالج. يحتوي الملف على أحداث غير معالجة عندما:
- الطابع الزمني للإنشاء أعلى من حقل الطابع الزمني في ملف الإشارة المرجعية الخاص.
أو
- طابع وقت الإنشاء يساوي حقل الطابع الزمني في ملف الإشارة المرجعية الخاص وحجمه أعلى من الموضع في حقل وحدات البايت في ملف الإشارة المرجعية الخاص.
س: كيف تعرف FMC عدد وحدات البايت المتخلفة عن جهاز إستشعار معين؟
أ: يرسل المستشعر بيانات أولية عن اسم ملف Unified_events وحجمه وكذلك المعلومات الموجودة على ملفات الإشارة المرجعية، والتي توفر معلومات FMC كافية لحساب وحدات البايت خلفها ك:
حجم ملف unified_events الحالي - موضع في حقل Bytes من ملف الإشارة المرجعية + حجم كل ملفات unified_events ذات ختم وقت أعلى من الطابع الزمني في ملف الإشارة المرجعية الخاص بها.
المشكلات الشائعة
1. افتح أداة البحث عن الأخطاء واستخدم هذا الاستعلام:
محفوظات المراجعة
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
4.0 |
10-Jul-2026
|
العنوان المحدث (طويل جدا)، التدقيق الإملائي، النحوي، الأسطر المدرجة إلى المقاطع المنفصلة من أجل إمكانية القراءة، النص البديل المحدث، وتنبيهات CCW. |
3.0 |
03-May-2024
|
مقدمة محدثة، PII، نص بديل، ترجمة آلية، أهداف إرتباط، وتنسيق. |
1.0 |
25-Sep-2020
|
الإصدار الأولي |
التعليقات