Wazuh FIM وفحص ثغرات CVE: درس عملي 2026

📍 المقالة الرئيسية للمجموعة: Wazuh 2026: الدليل الكامل.

Wazuh مثبت، agents منشورة. الخطوة التالية: تفعيل FIM (File Integrity Monitoring) وفحص ثغرات CVE لتحويل المراقبة السلبية إلى كشف نشط. هذا الدرس يفصل التكوينات المُختبَرة في الإنتاج. بدون FIM وفحص CVE، Wazuh يبقى مجرد جامع سجلات بسيط — مع هذه الميزات يصبح SIEM حقيقي.

المتطلبات

Wazuh Manager + agents في الإنتاج. المستوى المتوقع: متوسط/متقدم. الوقت المقدر: ساعة. خبرة سابقة في إدارة Linux مفيدة لفهم الملفات الحرجة لكل خدمة.

FIM: مراقبة الملفات الحرجة

الخطوة 1 — فهم الاستراتيجية

FIM يراقب التعديلات (create، modify، delete) على الملفات/المجلدات المحددة. تنبيه في الوقت الفعلي أو يومي. حاسم لـ:

• ملفات النظام: /etc/passwd، /etc/shadow، /etc/sudoers. أي تعديل غير مصرح يشير إلى محاولة لإنشاء backdoor.
• التكوينات: /etc/ssh/sshd_config، /etc/nginx/، /etc/caddy/. تعديل غير متوقع قد يكون محاولة لتغيير سياسة الأمان.
• كود التطبيقات: /var/www/، /srv/apps/. وجود ملف PHP جديد قد يكون webshell زرعه مهاجم.
• السجلات الحساسة: /var/log/auth.log. حذفها قد يشير إلى محاولة محو الأدلة.

الخطوة 2 — تكوين FIM في ossec.conf

على كل agent (أو عبر تكوين مركزي Manager). الـ realtime="yes" يستخدم inotify على Linux للكشف الفوري دون استهلاك CPU. الـ whodata يدمج auditd لمعرفة من قام بالتعديل.

nano /var/ossec/etc/ossec.conf

<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency>  <!-- 12h فحص كامل -->
  
  <!-- Real-time monitoring -->
  <directories realtime="yes" check_all="yes" report_changes="yes">/etc</directories>
  <directories realtime="yes" check_all="yes" report_changes="yes">/var/www</directories>
  <directories realtime="yes" check_all="yes">/srv/apps</directories>
  
  <!-- فحص منتظم -->
  <directories check_all="yes">/usr/bin</directories>
  <directories check_all="yes">/usr/sbin</directories>
  
  <!-- استثناءات -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/hosts.deny</ignore>
  <ignore type="sregex">.log$|.swp$|.tmp$</ignore>
  
  <!-- Audit Linux: من قام بالتعديل -->
  <whodata>yes</whodata>
</syscheck>

systemctl restart wazuh-agent

الخطوة 3 — اختبار FIM

اختبار بسيط للتحقق من أن FIM يعمل: إنشاء ملف في /etc ومعرفة ما إذا كان Wazuh يكشفه. هذا الاختبار يجب أن يولد تنبيهاً في غضون ثوانٍ بفضل الـ realtime monitoring.

echo "test" >> /etc/test-fim.txt
# انتظر 30 ثانية

Dashboard → Modules → Integrity Monitoring → شاهد التنبيه.

الخطوة 4 — تنبيه حرج على الملفات الحساسة

قاعدة مخصصة للتنبيه بمستوى 12 على /etc/sudoers. هذا الملف يتحكم في امتيازات sudo — أي تعديل فيه قد يكون محاولة تصعيد امتيازات.

# /var/ossec/etc/rules/local_rules.xml
<group name="syscheck,">
  <rule id="100100" level="12">
    <if_sid>550,553,554</if_sid>
    <match>/etc/sudoers</match>
    <description>Critical: sudoers file modified</description>
    <mitre>
      <id>T1548.003</id>
    </mitre>
  </rule>
</group>

Vulnerability scanning

الخطوة 5 — تفعيل Vulnerability Detector

Vulnerability Detector يقارن قائمة packages المثبَّتة مع قواعد بيانات CVE المعروفة (NVD، Canonical، Debian، RedHat). كل ساعة، يُحدِّث feeds ويعيد فحص endpoints. هذا يكتشف الثغرات الأمنية فور إعلانها.

nano /var/ossec/etc/ossec.conf

<vulnerability-detector>
  <enabled>yes</enabled>
  <interval>5m</interval>
  <run_on_start>yes</run_on_start>
  
  <provider name="canonical">
    <enabled>yes</enabled>
    <os>jammy</os>
    <os>noble</os>
    <update_interval>1h</update_interval>
  </provider>
  
  <provider name="debian">
    <enabled>yes</enabled>
    <os>bookworm</os>
  </provider>
  
  <provider name="redhat">
    <enabled>yes</enabled>
  </provider>
  
  <provider name="nvd">
    <enabled>yes</enabled>
    <update_from_year>2018</update_from_year>
  </provider>
</vulnerability-detector>

systemctl restart wazuh-manager

الخطوة 6 — أول فحص

انتظر 30-60 دقيقة لتحميل feeds من NVD + Canonical + Debian. هذا التحميل الأولي ثقيل (1-2 جيجابايت)، لكنه يحدث مرة واحدة فقط. التحديثات اللاحقة differential وأخف بكثير.

Dashboard → Modules → Vulnerabilities → شاهد جميع CVE المُكتشَفة لكل endpoint. الواجهة تعرض شدة كل CVE (Critical/High/Medium/Low)، نسخة المتأثرة، نسخة المُصحَّحة. هذه المعلومات تساعد فريق الأمان على تحديد الأولويات.

الخطوة 7 — تصفية حسب الشدة

Dashboard يقدم فلاتر: Critical، High، Medium، Low. للشركة الصغيرة، فضل Critical و High مع نقاط CVSS > 7. هذا التركيز يتجنب الإغراق بآلاف CVE Low ويسمح للفريق الصغير بمعالجة أهم المخاطر.

الخطوة 8 — العمل على CVE المكتشفة

لكل CVE Critical:

1. اقرأ التقرير: package المتأثر، النسخة الحالية، النسخة المُصحَّحة.
2. تحقق من توفر patch: apt list --upgradable.
3. خطط للتصحيح في نافذة الصيانة.
4. طبِّق وتحقق من الفحص الجديد.

الأخطاء الشائعة

التكيف مع السياق المغاربي وغرب إفريقيا

ثلاث توضيحات. إدارة التصحيح. للشركة الإفريقية الصغيرة دون فريق مخصص، برنامج patch tuesday + تنبيه Wazuh = workflow بسيط. هذا الإيقاع الأسبوعي يتجنب التأخير الكارثي ويبقى قابلاً للإدارة لفريق صغير. الامتثال ARTCI. تقرير CVE شهري + إجراءات patch موثقة = دليل اجتهاد للتدقيق. ARTCI الإيفواري تطلب عموماً دليلاً على إدارة الثغرات السنوية. مراقبة الكود المخصص. FIM على /srv/apps يكشف إذا حقن المهاجم webshell بعد اختراق. هذا الكشف الدقيق يقصر فترة الاختراق من أشهر إلى ساعات.

دروس الإخوة في المجموعة

• نشر Wazuh
• الامتثال PCI DSS

الأسئلة المتكررة

تكلفة RAM Differential FIM؟ 50-100 ميغابايت لكل 100,000 ملف مُراقب.

تردد فحص الثغرات؟ كل 5 دقائق interval. لكن CVE جديد = إعادة فحص endpoint.

قائمة بيضاء CVE إيجابي خاطئ؟ نعم عبر قاعدة مخصصة level 0 على CVE ID.

NIST CVSS v4؟ Wazuh 4.10+ يدعم CVSS v3.1، v4 في beta.

Active Directory FIM Windows؟ نعم، مراقبة registry + ملفات GPO.

للاستزادة

• 🔝 العودة للمرجع: الدليل الكامل Wazuh 2026
• وثائق FIM: documentation.wazuh.com/fim