مشاركة عبر

استكشاف الأخطاء وإصلاحها المتعلقة بموصل بيانات CEF أو Syslog

  • مقالة

تنبيه

تشير هذه المقالة إلى CentOS، وهو توزيع Linux يقترب من حالة نهاية العمر الافتراضي (EOL). يرجى مراعاة استخدامك والتخطيط وفقا لذلك. لمزيد من المعلومات، راجع إرشادات نهاية العمر الافتراضي CentOS.

توضح هذه المقالة الطرق الشائعة للتحقق من موصل بيانات CEF أو Syslog لـ Microsoft Sentinel واستكشاف الأخطاء وإصلاحها.

على سبيل المثال، إذا لم تظهر سجلاتك في Microsoft Sentinel، إما في Syslog أو جداول سجل الأمان المشترك، فقد يفشل مصدر البيانات في الاتصال أو قد يكون هناك سبب آخر لعدم استيعاب بياناتك.

تشمل الأعراض الأخرى لفشل توزيع الموصل، عندما يكون الملف security_events.conf أو security-omsagent.config.conf مفقودًا، أو عندما لا يستجيب خادم rsyslog إلى المنفذ 514.

لمزيد من المعلومات، راجع توصيل الحل الخارجي باستخدام تنسيق الأحداث الشائعة وجمع البيانات من المصادر المعتمدة على Linux باستخدام Syslog.

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

توضح لك هذه المقالة كيفية استكشاف أخطاء موصلات CEF أو Syslog وإصلاحها باستخدام عامل Log Analytics. لاستكشاف المعلومات المتعلقة باستيعاب سجلات CEF وإصلاحها عبر عامل Azure Monitor (AMA)، راجع تنسيق الحدث المشترك (CEF) عبر إرشادات موصل AMA .

هام

في 28 فبراير 2023، قدمنا تغييرات على مخطط جدول CommonSecurityLog. بعد هذا التغيير، قد تحتاج إلى مراجعة الاستعلامات المخصصة وتحديثها. لمزيد من التفاصيل، راجع قسم الإجراءات الموصى بها في منشور المدونة هذا. تم تحديث المحتوى الجاهز (الاكتشافات واستعلامات التتبع والمصنفات والموزعات وما إلى ذلك) بواسطة Microsoft Sentinel.

كيف يمكن استخدام هذه المقالة

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

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

قم بالتحقق من صحة اتصال CEF

بعد أن تقوم بـ توزيع جهاز إعادة توجيه السجل، وتكوين حل الأمان لإرسال رسائل CEF إليه، قم بالخطوات الواردة في هذا القسم للتحقق من الاتصال بين حل الأمان و Microsoft Sentinel.

هذا الإجراء ذو صلة فقط باتصالات CEF، وهو لا يتعلق باتصالات Syslog.

  1. التأكد من أن لديك المتطلبات الأساسية التالية:

    • يجب أن يكون لديك أذونات عالية المستوى (sudo) على جهاز إعادة توجيه السجل الخاص بك.

    • يجب أن يكون لديك إصدار python 2.7 أو 3 مثبتاً على جهاز إعادة توجيه السجل. قم باستخدام الأمر python --version للتحقق.

    • تحتاج إلى مُعرف مساحة العمل والمفتاح الأساسي لمساحة العمل في مرحلة ما من هذه العملية. يمكنك العثور عليها في مورد مساحة العمل، ضمن إدارة الوكلاء.

  2. من قائمة التنقل Microsoft Sentinel، قم بتحديد Logs. قم بتشغيل استعلام عن طريق استخدام مخطط CommonSecurityLog لمعرفة ما إذا كنت تتلقى سجلات من حل الأمان الخاص بك.

    قد يستغرق الأمر حوالي 20 دقيقة حتى تبدأ السجلات الخاصة بك في الظهور في Log Analytics.

  3. إذا لم تشاهد أي نتائج من الاستعلام، فتحقق من إنشاء الأحداث من حل الأمان الخاص بك، أو حاول إنشاء بعضها، وقم بالتحقق من إعادة توجيهها إلى جهاز إعادة توجيه Syslog الذي قمت بتعيينه.

  4. قم بتشغيل البرنامج النصي التالي على جهاز إعادة توجيه السجل (تطبيق مُعرف مساحة العمل بدلا من العنصر النائب) للتحقق من الاتصال بين حل الأمان وجهاز إعادة توجيه السجل و Microsoft Sentinel. يتحقق هذا البرنامج النصي من أن البرنامج الخفي يستجيب إلى المنافذ الصحيحة، وأن إعادة التوجيه تم تكوينها بشكل صحيح، وأنه لا يوجد شيء يمنع الاتصال بين البرنامج الخفي ووكيل Log Analytics. كما يرسل رسائل وهمية "TestCommonEventFormat" من أجل التحقق من الاتصال من طرف إلى طرف. 

    sudo wget -O cef_troubleshoot.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/CEF/cef_troubleshoot.py&&sudo python cef_troubleshoot.py [WorkspaceID]

شرح البرنامج النصي الخاص بالتحقق من صحة CEF

يصف القسم التالي البرنامج النصي الخاص بالتحقق من صحة CEF، لبرنامج rsyslog الخفي وبرنامج syslog-ng الخفي.

برنامج rsyslog الخفي

بالنسبة إلى برنامج rsyslog الخفي، يقوم البرنامج النصي للتحقق من صحة CEF بتشغيل الفحوصات التالية:

  1. يتحقق من أن الملف
    /etc/opt/microsoft/omsagent/[WorkspaceID]/conf/omsagent.d/security_events.conf
    متوفر وصالح.

  2. يتحقق من أن الملف يتضمن النص التالي:

    <source>
    type syslog
    port 25226
    bind 127.0.0.1
    protocol_type tcp
    tag oms.security
    format /(?<time>(?:\w+ +){2,3}(?:\d+:){2}\d+|\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.[\w\-\:\+]{3,12}):?\s*(?:(?<host>[^: ]+) ?:?)?\s*(?<ident>.*CEF.+?(?=0\|)|%ASA[0-9\-]{8,10})\s*:?(?<message>0\|.*|.*)/
    <parse>
        message_format auto
    </parse>
</source>

<filter oms.security.**>
    type filter_syslog_security
</filter>

  3. يتحقق من أن تحليل أحداث Cisco ASA Firewall كما هو متوقع، باستخدام الأمر التالي:

    grep -i "return ident if ident.include?('%ASA')" /opt/microsoft/omsagent/plugin/security_lib.rb

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

      # Cisco ASA parsing fix
sed -i "s|return '%ASA' if ident.include?('%ASA')|return ident if ident.include?('%ASA')|g" /opt/microsoft/omsagent/plugin/security_lib.rb && sudo /opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  4. يقوم بالتحقق من تعيين حقل الكمبيوتر في مصدر syslog بشكل صحيح في وكيل Log Analytics، باستخدام الأمر التالي:

    grep -i "'Host' => record\['host'\]"  /opt/microsoft/omsagent/plugin/filter_syslog_security.rb

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

      # Computer field mapping fix
sed -i -e "/'Severity' => tags\[tags.size - 1\]/ a \ \t 'Host' => record['host']" -e "s/'Severity' => tags\[tags.size - 1\]/&,/" /opt/microsoft/omsagent/plugin/filter_syslog_security.rb && sudo /opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  5. يتحقق مما إذا كان هناك أي تحسينات أمنية على الجهاز تمنع نسبة استخدام الشبكة (مثل جدار حماية المضيف).

  6. يقوم بالتحقق من تكوين البرنامج الخفي syslog (rsyslog) بشكل صحيح لإرسال الرسائل (التي يعرفها على أنها CEF) إلى وكيل Log Analytics على منفذ TCP 25226:

    ملف التكوين:/etc/rsyslog.d/security-config-omsagent.conf

    if $rawmsg contains "CEF:" or $rawmsg contains "ASA-" then @@127.0.0.1:25226

  7. يقوم بإعادة تشغيل برنامج syslog الخفي ووكيل Log Analytics:

    service rsyslog restart

/opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  8. يتحقق من إنشاء الاتصالات الضرورية: tcp 514 لاستلام البيانات، tcp 25226 للاتصال الداخلي بين البرنامج الخفي لسجل النظام ووكيل Log Analytics:

    netstat -an | grep 514

netstat -an | grep 25226

  9. يقوم بالتحقق من أن برنامج syslog الخفي يتلقى بيانات على المنفذ 514، وأن الوكيل يتلقى البيانات على المنفذ 25226:

    sudo tcpdump -A -ni any port 514 -vv

sudo tcpdump -A -ni any port 25226 -vv

  10. يقوم بإرسال بيانات MOCK إلى المنفذ 514 على المضيف المحلي. يجب أن تكون هذه البيانات قابلة للملاحظة في مساحة عمل Microsoft Sentinel عن طريق تشغيل الاستعلام التالي:

    CommonSecurityLog
| where DeviceProduct == "MOCK"

برنامج syslog-ng الخفي

بالنسبة إلى البرنامج rsyslog-ng الخفي، يعمل البرنامج النصي على التحقق من صحة CEF بتشغيل الفحوصات التالية:

  1. يتحقق من أن الملف
    /etc/opt/microsoft/omsagent/[WorkspaceID]/conf/omsagent.d/security_events.conf
    متوفر وصالح.

  2. يتحقق من أن الملف يتضمن النص التالي:

    <source>
    type syslog
    port 25226
    bind 127.0.0.1
    protocol_type tcp
    tag oms.security
    format /(?<time>(?:\w+ +){2,3}(?:\d+:){2}\d+|\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.[\w\-\:\+]{3,12}):?\s*(?:(?<host>[^: ]+) ?:?)?\s*(?<ident>.*CEF.+?(?=0\|)|%ASA[0-9\-]{8,10})\s*:?(?<message>0\|.*|.*)/
    <parse>
        message_format auto
    </parse>
</source>

<filter oms.security.**>
    type filter_syslog_security
</filter>

  3. يتحقق من أن تحليل أحداث Cisco ASA Firewall كما هو متوقع، باستخدام الأمر التالي:

    grep -i "return ident if ident.include?('%ASA')" /opt/microsoft/omsagent/plugin/security_lib.rb

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

      # Cisco ASA parsing fix
sed -i "s|return '%ASA' if ident.include?('%ASA')|return ident if ident.include?('%ASA')|g" /opt/microsoft/omsagent/plugin/security_lib.rb && sudo /opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  4. يقوم بالتحقق من تعيين حقل الكمبيوتر في مصدر syslog بشكل صحيح في وكيل Log Analytics، باستخدام الأمر التالي:

    grep -i "'Host' => record\['host'\]"  /opt/microsoft/omsagent/plugin/filter_syslog_security.rb

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

      # Computer field mapping fix
sed -i -e "/'Severity' => tags\[tags.size - 1\]/ a \ \t 'Host' => record['host']" -e "s/'Severity' => tags\[tags.size - 1\]/&,/" /opt/microsoft/omsagent/plugin/filter_syslog_security.rb && sudo /opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  5. يتحقق مما إذا كان هناك أي تحسينات أمنية على الجهاز تمنع نسبة استخدام الشبكة (مثل جدار حماية المضيف).

  6. يقوم بالتحقق من تكوين البرنامج الخفي syslog (syslog-ng) بشكل صحيح لإرسال الرسائل التي يعرفها على أنها CEF (باستخدام regex) إلى وكيل Log Analytics على منفذ TCP 25226:

    • ملف التكوين:/etc/syslog-ng/conf.d/security-config-omsagent.conf

      filter f_oms_filter {match(\"CEF\|ASA\" ) ;};destination oms_destination {tcp(\"127.0.0.1\" port(25226));};
log {source(s_src);filter(f_oms_filter);destination(oms_destination);};

  7. يقوم بإعادة تشغيل برنامج syslog الخفي ووكيل Log Analytics:

    service syslog-ng restart

/opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  8. يتحقق من إنشاء الاتصالات الضرورية: tcp 514 لاستلام البيانات، tcp 25226 للاتصال الداخلي بين البرنامج الخفي لسجل النظام ووكيل Log Analytics:

    netstat -an | grep 514

netstat -an | grep 25226

  9. يقوم بالتحقق من أن برنامج syslog الخفي يتلقى بيانات على المنفذ 514، وأن الوكيل يتلقى البيانات على المنفذ 25226:

    sudo tcpdump -A -ni any port 514 -vv

sudo tcpdump -A -ni any port 25226 -vv

  10. يقوم بإرسال بيانات MOCK إلى المنفذ 514 على المضيف المحلي. يجب أن تكون هذه البيانات قابلة للملاحظة في مساحة عمل Microsoft Sentinel عن طريق تشغيل الاستعلام التالي:

    CommonSecurityLog
| where DeviceProduct == "MOCK"

قم بالتحقق من المتطلبات الأساسية لموصل البيانات

قم باستخدام الأقسام التالية للتحقق من متطلبات موصل بيانات CEF أو Syslog.

Azure Virtual Machine كـ مجمع CEF

إذا كنت تستخدم جهاز Azure الظاهري كمجمع CEF، قم بالتحقق مما يلي:

  • قبل توزيع البرنامج النصي Python لموصل بيانات تنسيق الحدث المشترك، قم بالتأكد من أن الجهاز الظاهري غير متصل بالفعل بمساحة عمل Log Analytics موجودة. يُصبح بإمكانك العثور على هذه المعلومات في قائمة الجهاز الظاهري لمساحة عمل Log Analytics، حيث يتم إدراج الجهاز الظاهري المتصل بمساحة عمل Syslog على أنه متصل.

  • قم بالتأكد من اتصال Microsoft Sentinel بمساحة عمل Log Analytics الصحيحة، مع تثبيت حل SecurityInsights.

    لمزيد من المعلومات، راجع الخطوة 1: توزيع جهاز إعادة توجيه السجل.

  • قم بالتأكد من تغيير حجم جهازك بشكل صحيح مع الحد الأدنى من المتطلبات الأساسية المطلوبة على الأقل. لمزيد من المعلومات، قم بمراجعة المتطلبات الأساسية لـ CEF.

جهاز محلي أو جهاز ظاهري غير Azure

إذا كنت تستخدم جهازا محليا أو جهازا ظاهريا غير Azure لموصل البيانات، قم بالتأكد من تشغيل البرنامج النصي للتثبيت على تثبيت جديد لنظام تشغيل Linux مدعوم:

تلميح

يُصبح بإمكانك أيضا العثور على هذا البرنامج النصي من صفحة موصل بيانات تنسيق ملف شائع في Microsoft Sentinel.

sudo wget -O cef_installer.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/CEF/cef_installer.py&&sudo python cef_installer.py <WorkspaceId> <Primary Key>

قم بتمكين أداة CEF الخاصة بك وتسجيل مجموعة الخطورة

يقوم خادم Syslog، إما rsyslog أو syslog-ng، بإعادة توجيه أي بيانات محددة في ملف التكوين ذي الصلة، والذي يتم ملؤه تلقائياً عن طريق الإعدادات المحددة في مساحة عمل Log Analytics.

قم بالتأكد من إضافة تفاصيل حول المرافق ومستويات سجل الخطورة التي تريد استيعابها في Microsoft Azure Sentinel. من الممكن أن تستغرق عملية التكوين حوالي 20 دقيقة.

للحصول على مزيدٍ من المعلومات، راجع شرح البرنامج النصي للتوزيع.

على سبيل المثال، فميا يتعلق بخادم rsyslog، قم بتشغيل الأمر التالي لعرض الإعدادات الحالية لإعادة توجيه Syslog، ومراجعة أي تغييرات على ملف التكوين:

cat /etc/rsyslog.d/security-config-omsagent.conf

في هذه الحالة، بالنسبة لـ rsyslog، يتعين عرض الإخراج المشابه لما يلي:

if $rawmsg contains "CEF:" or $rawmsg contains "ASA-" then @@127.0.0.1:25226

استكشاف المشكلات الخاصة بنظام التشغيل وإصلاحها

يصف هذا القسم كيفية استكشاف المشكلات الناجمة من تكوين نظام التشغيل وإصلاحها.

لاستكشاف مشكلات نظام التشغيل وإصلاحها:

  1. إذا لم تكن قد فعلت ذلك بعد، فتأكد من أنك تعمل باستخدام نظام تشغيل مدعوم وإصدار Python. لمزيد من المعلومات، قم بمراجعة المتطلبات الأساسية لـ CEF.

  2. إذا كان الجهاز الظاهري الخاص بك في Azure، قم بالتحقق من أن مجموعة أمان الشبكة (NSG) تسمح باتصال TCP/UDP الوارد من عميل السجل (المرسل) على المنفذ 514.

  3. قم بالتحقق من وصول الحزم إلى مجمع Syslog. لالتقاط حزم syslog التي تصل إلى مجمع Syslog، يجب بتشغيل:

    tcpdump -Ani any port 514 and host <ip_address_of_sender> -vv

  4. قم بأحد الإجراءات التالية:

    • إذا لم تشاهد أي حزم تصل، قم بالتأكد من أذونات مجموعة أمان NSG ومسار التوجيه إلى مجمع Syslog.

    • إذا لاحظت وصول الحزم تصل، قم بالتأكد من عدم رفضها.

    إذا لاحظت الحزم المرفوضة، قم بالتأكد من أن جداول IP لا تحظر الاتصالات.

    للتأكد من عدم رفض الحزم، يجب تشغيل:

    watch -n 2 -d iptables -nvL

  5. قم بالتحقق مما إذا كان خادم CEF يعالج السجلات. تشغيل:

    tail -f /var/log/messages or tail -f /var/log/syslog

    تُعرض أي سجلات CEF تتم معالجتها في نص عادي.

  6. قم بالتأكد من أن خادم rsyslog يستجيب إلى منفذ TCP/UDP 514. تشغيل:

    netstat -anp | grep syslog

    إذا كان لديك أي سجلات CEF أو ASA يتم إرسالها إلى مجمع Syslog الخاص بك، يجب أن تشاهد اتصالا حاليًا على منفذTCP 25226.

    على سبيل المثال:

    0 127.0.0.1:36120 127.0.0.1:25226 ESTABLISHED 1055/rsyslogd

    إذا تم حظر الاتصال، يُصبح لديك اتصال SELinux محظور بوكيل OMS، أو عملية جدار حماية محظورة. قم باستخدام الإرشادات ذات الصلة أدناه لتحديد المشكلة.

قم بحظر SELinux الاتصال بوكيل OMS

يصف هذا الإجراء كيف يمكن تأكيد ما إذا كان SELinux حالياً في حالة permissive، أو يحظر الاتصال بوكيل OMS. يكون هذا الإجراء مناسبًا عندما يكون نظام التشغيل الخاص بك هو توزيع من RedHat أو CentOS، ولكل من موصلات بيانات CEF و Syslog.

إشعار

يتضمن الدعم الخاص بـ Microsoft Sentinel لـ CEF و Syslog فقط تصلب FIPS. أساليب تقوية أخرى، مثل SELinux أو CIS غير مدعومة حاليا.

  1. تشغيل:

    sestatus

    تُعرض الحالة كأحد ما يلي:

    • disabled. هذا التكوين مدعوم لاتصالك ب Microsoft Sentinel.
    • permissive. هذا التكوين مدعوم لاتصالك ب Microsoft Sentinel.
    • enforced. هذا التكوين غير معتمد، ويتعين إما تعطيل الحالة أو تعيينها إلى permissive.

  2. إذا تم تعيين الحالة حاليا إلى enforced، فقم بإيقاف تشغيلها مؤقتا لتأكيد ما إذا كان هذا هو المانع. تشغيل:

    setenforce 0

    إشعار

    تقوم هذه الخطوة بإيقاف تشغيل SELinux فقط حتى يتم إعادة تشغيل الخادم. تعديل تكوين SELinux لإبقاءه متوقفاً عن التشغيل.

  3. للتحقق مما إذا كان التغيير ناجحاً، يجب بتشغيل:

    getenforce

    يتعين إرجاع الحالة permissive.

هام

يتم فقدان تحديث الإعداد هذا بمجرد إعادة تمهيد النظام. لتحديث هذا الإعداد بشكل دائم إلى permissive، يجب تعديل ملف /etc/selinux/config، وتغيير القيمة SELINUX إلى SELINUX=permissive.

لمزيد من المعلومات، قم بمراجعة وثائق RedHat.

النهج الخاص بجدار الحماية المحظور

يصف هذا الإجراء كيف يمكن التحقق مما إذا كان نهج جدار الحماية يمنع الاتصال من برنامج Rsyslog الخفي إلى وكيل OMS، وكيفية تعطيله حسب الحاجة. هذا الإجراء مناسب لكل من موصلات البيانات الخاصة بـ CEF و Syslog.

  1. قم بتشغيل الأمر التالي للتحقق مما إذا كانت هناك أي أسباب رفض في جداول IP، مما يشير إلى نسبة استخدام الشبكة التي يتم إسقاطها بواسطة نهج جدار الحماية:

    watch -n 2 -d iptables -nvL

  2. للحفاظ على تمكين نهج جدار الحماية، يجب إنشاء قاعدة نهج للسماح بالاتصالات. قم بإضافة القواعد حسب الحاجة للسماح بمنافذ TCP/UDP 25226 و25224 من خلال جدار الحماية النشط.

    على سبيل المثال:

    Every 2.0s: iptables -nvL                      rsyslog: Wed Jul  7 15:56:13 2021

Chain INPUT (policy ACCEPT 6185K packets, 2466M bytes)
 pkts bytes target     prot opt in     out     source               destination


Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination


Chain OUTPUT (policy ACCEPT 6792K packets, 6348M bytes)
 pkts bytes target     prot opt in     out     source               destination

  3. لإنشاء قاعدة للسماح بمنافذ TCP/UDP 25226 و25224 من خلال جدار الحماية النشط.

    1. لتثبيت محرر نهج جدار الحماية، يجب تشغيل:

      yum install policycoreutils-python

    2. قم بإضافة قواعد جدار الحماية إلى نهج جدار الحماية. على سبيل المثال:

      sudo firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 25226  -j ACCEPT
sudo firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p udp --dport 25224  -j ACCEPT
sudo firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 25224  -j ACCEPT

    3. قم بالتحقق من إضافة الاستثناء. تشغيل:

      sudo firewall-cmd --direct --get-rules ipv4 filter INPUT

    4. قم بإعادة تحميل جدار الحماية. تشغيل:

      sudo firewall-cmd --reload

إشعار

لتعطيل جدار الحماية، يجب تشغيل: sudo systemctl disable firewalld

إذا لم تحل الخطوات الموضحة سابقا في هذه المقالة مشكلتك، فقد تواجه مشكلة في الاتصال بين وكيل OMS ومساحة عمل Microsoft Sentinel.

في مثل هذه الحالات، قم بالاستمرار في استكشاف الأخطاء وإصلاحها عن طريق التحقق مما يلي:

  • تأكد من أنه يمكنك رؤية الحزم التي تصل إلى منفذ TCP/UDP 514 على مجمع Syslog

  • قم بالتأكد من أنه يمكنك رؤية السجلات التي تتم كتابتها إلى ملف السجل المحلي، إما /var/log/messages أو /var/log/syslog

  • قم بالتأكد من أنه يمكنك رؤية حزم البيانات المتدفقة على المنفذ 25226

  • قم بالتأكد من أن جهازك الظاهري لديه اتصال صادر بالمنفذ 443 عبر TCP، أو يمكنه الاتصال بنقاط نهاية Log Analytics

  • قم بالتأكد من أن لديك حق الوصول إلى عناوين URL المطلوبة من مجمع CEF الخاص بك من خلال نهج جدار الحماية الخاص بك. لمزيد من المعلومات، راجع متطلبات جدار حماية وكيل Log Analytics.

يجب تشغيل الأمر التالي لتحديد ما إذا كان الوكيل يتواصل بنجاح مع Azure، أو إذا تم حظر وكيل OMS من الاتصال بمساحة عمل Log Analytics.

Heartbeat
 | where Computer contains "<computername>"
 | sort by TimeGenerated desc

يتم إرجاع الإدخال الخاص بالسجل إذا كان الوكيل يتصل بنجاح. وإلا، يُحظر وكيل OMS.

الخطوات التالية

إذا لم تساعد خطوات استكشاف الأخطاء وإصلاحها في هذه المقالة في المشكلة، فافتح تذكرة دعم أو استخدم موارد مجتمع Microsoft Sentinel. لمزيد من المعلومات، راجع موارد مفيدة للعمل مع Microsoft Sentinel.

راجع المقالات التالية للتعرُّف على المزيد حول Microsoft Azure Sentinel: