إذا كانت سجلات Windows وLinux والجدار الناري والخدمات السحابية موزعة بين عدة شاشات، فلن تكمن المشكلة في نقص البيانات، بل في صعوبة ربطها وتحويلها إلى تنبيه يمكن لفريق تقنية المعلومات التعامل معه. هنا يأتي دور Wazuh بوصفه منصة أمنية مفتوحة المصدر تجمع إمكانات إدارة معلومات وأحداث الأمن (SIEM) مع وظائف الاكتشاف والاستجابة الموسعة (XDR).
لكن تثبيت Wazuh لا يصنع مركز عمليات أمنية تلقائياً، ولا يحول كل Log إلى معلومة مفيدة. نجاحه يعتمد على اختيار مصادر البيانات الصحيحة، وضبط القواعد، وتحديد مسؤول عن مراجعة التنبيهات، وبناء إجراء واضح للاستجابة. يشرح هذا الدليل ما هو Wazuh، وكيف تعمل مكوناته، ومتى يناسب الشركات، وكيف تنفذ تجربة أولية قابلة للقياس قبل اعتماده في الإنتاج.
Wazuh منصة مجانية ومفتوحة المصدر لمراقبة الأمن، تجمع سجلات الأجهزة والخوادم ومصادر الشبكة والسحابة، ثم تحللها وتفهرسها وتعرض التنبيهات في لوحة مركزية. تستطيع استخدامها لمراقبة سلامة الملفات، واكتشاف البرمجيات المعرضة لثغرات معروفة، وتقييم الإعدادات الأمنية، وربط التنبيهات بإطار MITRE ATT&CK، وتنفيذ استجابات آلية مضبوطة. وهي لا تستبدل Antivirus أو Firewall أو Backup أو إدارة التحديثات، بل تربط أدلتها وتمنح فريق IT رؤية أمنية مركزية.
حتى 24 أغسطس 2026، الإصدار المستقر الأحدث هو Wazuh 4.14.7. لأن أوامر التثبيت ومتطلبات التوافق تتغير، راجع دائماً ملاحظات الإصدارات الرسمية وQuickstart قبل تنفيذ أي تغيير في بيئة إنتاجية.
ما هو Wazuh وما المشكلة التي يحلها؟
Wazuh هو منصة أمن سيبراني مجانية ومفتوحة المصدر، منشورة بترخيص GPLv2 وفق المستودع الرسمي، ومصممة لجمع بيانات الأمن من النقاط النهائية (Endpoints) والخوادم وأجهزة الشبكة والخدمات السحابية، ثم تحليلها والبحث فيها وإظهار التنبيهات من مكان مركزي. النسخة ذاتية الاستضافة لا تفرض رسوم ترخيص للبرنامج، لكن هذا لا يعني أن تشغيلها بلا تكلفة؛ فأنت تحتاج إلى موارد حوسبة وتخزين، ونسخ احتياطي، وتحديثات، ووقت هندسي لإدارة القواعد والتنبيهات.
وظيفة SIEM الأساسية هي تجميع Telemetry والسجلات من مصادر متعددة، وتحليلها وربط الأحداث لتسهيل البحث والتحقيق والامتثال. أما XDR فيركز على توسيع الاكتشاف والاستجابة عبر أكثر من طبقة، مثل أجهزة المستخدمين والخوادم والسحابة. يقدم Wazuh وظائف من المجالين: فهو يجمع السجلات ويفهرسها، ويشغل قواعد اكتشاف، ويراقب الملفات والإعدادات، ويمكنه تشغيل إجراءات استجابة آلية.
من المهم ألا نتعامل مع مصطلح XDR كضمان بأن Wazuh يساوي كل منتج EDR تجاري من حيث عمق Telemetry أو عزل الجهاز أو التحقيق الجنائي. المقارنة الصحيحة تكون حسب السيناريو ومصادر البيانات وقدرة فريقك على الضبط والتشغيل، لا حسب الاسم التسويقي فقط.
- عندما تريد رؤية محاولات الدخول الفاشلة، وتغييرات الحسابات والصلاحيات، وأحداث الخدمات من شاشة واحدة.
- عندما تحتاج إلى مراقبة تغيّر ملفات أو إعدادات حساسة على Windows وLinux.
- عندما تريد معرفة البرامج المثبتة وربط إصداراتها بثغرات CVE معروفة.
- عندما تجمع Syslog من Firewall وSwitch وRouter وأجهزة لا يمكن تثبيت Agent عليها.
- عندما تحتاج إلى تقارير تساعد في PCI DSS أو GDPR أو HIPAA أو NIST 800-53، مع إدراك أن الأداة تساعد في إثبات الضوابط ولا تمنح الامتثال تلقائياً.
- عندما تريد بناء قدرة مراقبة أمنية داخلية بميزانية ترخيص محدودة، ولديك وقت وخبرة لتشغيلها.
كيف يعمل Wazuh؟ شرح المعمارية والمكونات
تتكون معمارية Wazuh الحالية من وكيل متعدد الأنظمة وأربعة أدوار عملية: جمع البيانات على الجهاز، تحليلها، تخزينها وفهرستها، ثم عرضها والبحث فيها. توضح وثائق معمارية Wazuh الرسمية أن المكونات المركزية هي Wazuh Server وWazuh Indexer وWazuh Dashboard، بينما يعمل Wazuh Agent على الأجهزة المراد مراقبتها.
| المكوّن | وظيفته | الملاحظة التشغيلية |
|---|---|---|
| Wazuh Agent | يجمع السجلات وInventory وحالة الملفات والإعدادات من Endpoint ويرسلها إلى الخادم. | يجب توزيعه بمجموعات وسياسات مختلفة حسب نوع الجهاز، لا بإعداد واحد لكل البيئة. |
| Wazuh Server | يستقبل الأحداث، ويفك ترميزها، ويطبق قواعد التحليل، ويولد التنبيهات، ويدير Agents. | هو قلب منطق الاكتشاف؛ راقب الأداء والطوابير وحالة الاتصالات باستمرار. |
| Wazuh Indexer | يفهرس التنبيهات والبيانات ويتيح البحث والتحليل شبه الفوري. | التخزين ومدة الاحتفاظ ومعدل الأحداث عوامل حاسمة في الحجم والأداء. |
| Wazuh Dashboard | يوفر واجهة البحث واللوحات وإدارة Agents ومراجعة التنبيهات والتقارير. | لا تعرّضه مباشرة للإنترنت؛ استخدم وصولاً إدارياً مقيداً وTLS وRBAC. |
- يقرأ Agent حدثاً من Windows Event Log أو ملف سجل في Linux، أو يجمع Inventory، أو يكتشف تغييراً ضمن مسار مراقب.
- يرسل Agent البيانات إلى Wazuh Server عبر قناة مشفرة ومصادق عليها.
- يفك الخادم بنية الحدث باستخدام Decoders، ثم يقارنه بقواعد Ruleset أو قواعد محلية مخصصة.
- عند تحقق شروط القاعدة، ينشئ الخادم Alert يحتوي السياق ودرجة الخطورة والحقول المرتبطة.
- تُنقل البيانات إلى Indexer للفهرسة، ثم يستخدم Dashboard هذه الفهارس للبحث والعرض والتحقيق.
لا تتطلب جميع المصادر Agent. يمكن لأجهزة Firewall وSwitch وRouter وAccess Point إرسال Syslog، كما يدعم Wazuh أساليب مراقبة Agentless لبعض الأنظمة. ويمكن ربطه أيضاً بخدمات مثل AWS وMicrosoft Azure وGoogle Cloud وMicrosoft 365 وGitHub وفق التكامل المتاح لكل مصدر.
| المنفذ | البروتوكول | الاستخدام | التوصية |
|---|---|---|---|
| 1514 | TCP افتراضياً | اتصال Agents وإرسال الأحداث. | اسمح به من شبكات الأجهزة المراقبة إلى Wazuh Server فقط. |
| 1515 | TCP | تسجيل أو Enrollment الوكلاء. | قيده قدر الإمكان، واستخدم آلية تسجيل موثوقة. |
| 443 | TCP | واجهة Wazuh Dashboard. | اجعل الوصول عبر Management VLAN أو VPN وعناوين إدارية موثوقة. |
| 55000 | TCP | Wazuh Server API. | لا تنشره على الإنترنت، واسمح به للمكونات وأدوات الإدارة المطلوبة فقط. |
| 9200 | TCP | واجهة Wazuh Indexer API. | أبقِه داخل شبكة المكونات المركزية ولا تفتحه للمستخدمين. |
| 514 | UDP افتراضياً أو TCP اختيارياً | استقبال Syslog، وهو معطل افتراضياً في Wazuh. | فعّله فقط عند الحاجة، ويفضل بروتوكولاً موثوقاً أو قناة محمية عندما يدعم المصدر ذلك. |
ماذا يستطيع Wazuh مراقبته واكتشافه؟
قيمة Wazuh لا تأتي من لوحة Dashboard وحدها، بل من نوع Telemetry الذي تجمعه ومن القواعد التي تحول هذه البيانات إلى أدلة قابلة للتحقيق. أهم القدرات العملية هي الآتية:
يجمع Wazuh أحداث أنظمة التشغيل والتطبيقات وأجهزة الشبكة والسحابة، ثم يطبق Decoders وRules لاستخراج حقول مفهومة واكتشاف أنماط مثل تكرار فشل تسجيل الدخول، أو تشغيل خدمة غير معتادة، أو تغيير حساب ذي صلاحية. ويمكن ربط بعض التنبيهات بتكتيكات وتقنيات MITRE ATT&CK، ما يساعد المحلل على فهم سلوك المهاجم بدلاً من الاكتفاء برقم Alert. لفهم هذه الطبقة بصورة أعمق، راجع شرح MITRE ATT&CK Framework العملي.
تراقب File Integrity Monitoring إنشاء الملفات المحددة وتعديلها وحذفها، وتقارن Checksum وخصائص أخرى بالحالة السابقة. هذه القدرة مفيدة لمراقبة ملفات إعداد التطبيقات، ومجلدات Web Server، وملفات النظام الحساسة، وبعض مفاتيح Windows Registry. لكنها تحتاج Scope دقيقاً؛ مراقبة مجلدات كثيرة سريعة التغير بلا حاجة قد تنتج ضوضاء واستهلاكاً كبيرين.
يجمع Syscollector معلومات نظام التشغيل والبرامج والحزم المثبتة، ثم يربطها Wazuh Server بمعلومات الثغرات في Wazuh CTI لاكتشاف تطابقات CVE. هذه آلية Software Inventory Correlation وليست فحص اختراق شبكي أو فحص Web Application. لذلك تفيد في تحديد البرامج المعرضة للخطر ومتابعة المعالجة، لكنها لا تلغي الحاجة إلى Vulnerability Scanner متخصص عندما تحتاج إلى اكتشاف الخدمات المكشوفة أو الاختبارات النشطة أو فحص التطبيقات.
تفحص Security Configuration Assessment إعدادات Endpoint باستخدام Policy Files واختبارات محددة، وتعرض النتائج Passed وFailed وNot Applicable. تتوفر سياسات مبنية على CIS Benchmarks لعدد من أنظمة Windows وLinux، ويمكن إنشاء سياسات مخصصة. استخدم النتيجة كقائمة Remediation مدروسة، ولا تطبق كل توصية آلياً قبل اختبار أثرها على التطبيقات والخدمات.
يمكن تشغيل Script أو إجراء عند تحقق Rule ID أو مستوى أو مجموعة قواعد محددة، مثل حظر عنوان مصدر مؤقتاً أو تعطيل حساب في سيناريو مضبوط. هذه ميزة قوية، لكنها أيضاً أكثر جزء قد يسبب انقطاعاً إذا كانت القاعدة كثيرة False Positives أو كان الإجراء يعمل على نطاق واسع.
لا تفعّل Active Response على كل Agents أو على قواعد عامة منذ اليوم الأول. ابدأ بالتنبيه فقط، اجمع Baseline، اختبر القاعدة على مجموعة Pilot، أضف Allowlist دقيقة، وحدد Timeout وRollback ومالكاً للإجراء. تنبيه خاطئ يمكن مراجعته، أما حظر Domain Controller أو حساب خدمة بالخطأ فقد يتحول إلى Incident حقيقي.
هل Wazuh بديل للـ Antivirus أو EDR أو أدوات المراقبة؟
الإجابة المختصرة هي لا. Wazuh يغطي مساحة واسعة، لكنه يعمل أفضل كطبقة رؤية وتحليل واستجابة ضمن منظومة أمنية، وليس كبديل لكل أداة. يوضح الجدول حدود كل فئة:
| الأداة أو الفئة | الغرض الأساسي | ما الذي تتميز به؟ | علاقتها بـ Wazuh |
|---|---|---|---|
| Wazuh | رؤية أمنية مركزية، تحليل Logs، مراقبة Endpoint، اكتشاف واستجابة. | مفتوح المصدر، متعدد المصادر، قواعد قابلة للتخصيص، FIM وSCA وVulnerability Detection. | المنصة المركزية التي تربط الأدلة والتنبيهات. |
| Antivirus أو NGAV | منع واكتشاف البرمجيات الخبيثة على الجهاز. | محركات فحص وسلوك وحجر ملفات وتكامل عميق مع Endpoint. | تكاملي؛ يمكن جمع أحداث Microsoft Defender أو حلول أخرى داخل Wazuh. |
| EDR | Telemetry تفصيلية على Endpoint والتحقيق والاحتواء. | Process Tree، سلوك العمليات، بحث وتحقيق واستجابة بحسب المنتج. | قد تتقاطع الوظائف، لكن العمق والاستجابة يختلفان؛ قيّم حالة الاستخدام عملياً. |
| Syslog أو Log Server | استقبال السجلات والاحتفاظ بها. | تجميع مركزي بسيط وقدرة أرشفة. | Wazuh يضيف التحليل والقواعد والسياق والتنبيهات فوق جمع Logs. |
| Vulnerability Scanner | اكتشاف الثغرات عبر فحوص نشطة أو مصادق عليها. | فحص خدمات الشبكة والإعدادات والتطبيقات حسب الأداة. | يكمل آلية Wazuh المعتمدة أساساً على Inventory وربط الحزم بـ CVE. |
| NMS مثل PRTG أو Zabbix | مراقبة التوافر والأداء والسعة. | CPU وRAM وLatency وInterfaces وService Health. | تكاملي؛ NMS يجيب «هل الخدمة تعمل؟»، وWazuh يركز على «هل يوجد سلوك أمني مريب؟». |
إذا كان هدفك فقط معرفة أن السيرفر متوقف أو القرص ممتلئ، ابدأ بأداة Monitoring. إذا كان هدفك جمع الأدلة الأمنية وربط تسجيل الدخول وتغييرات الملفات والثغرات والتنبيهات عبر عدة مصادر، فهنا تظهر قيمة Wazuh. وفي معظم الشركات ستحتاج إلى الأداتين معاً.
كيف تصمم وتنشر Wazuh في شركة؟
ابدأ من حجم البيانات والمخاطر، لا من عدد الأجهزة وحده. جهاز Firewall يرسل كمية أحداث مختلفة تماماً عن Laptop عادي، ومراقبة FIM في مجلد تطبيق سريع التغير قد تولد أحداثاً أكثر من عشرات الأجهزة. لذلك أدخل في التصميم معدل الأحداث، ومدة الاحتفاظ، وعدد الفهارس والنسخ، وأنواع Logs، ومتطلبات High Availability ووقت البحث المقبول.
| النموذج | متى يناسب؟ | المخاطرة أو القيد |
|---|---|---|
| All-in-one | مختبر، Proof of Concept، أو بيئة صغيرة محدودة البيانات. | المكونات تتنافس على الموارد، والخادم يصبح نقطة فشل واحدة. |
| Distributed Single-node | بيئة متوسطة تحتاج فصل Server وIndexer وDashboard وتحسين الأداء. | الفصل لا يحقق High Availability وحده؛ كل دور قد يبقى نقطة فشل. |
| Multi-node Cluster | بيئة كبيرة، معدل أحداث مرتفع، أو متطلبات استمرارية وتوسع. | تعقيد أعلى في الشهادات والتوازن والمراقبة والنسخ الاحتياطي والترقيات. |
بحسب Quickstart الرسمي الحالي، يكفي نشر All-in-one عادةً لمراقبة حتى 100 Endpoint مع نحو 90 يوماً من التنبيهات القابلة للبحث، ويقترح الدليل 4 vCPU و8 GiB RAM و50 GB لعدد 1 إلى 25 Agent، ثم 8 vCPU و8 GiB RAM مع 100 GB لعدد 25 إلى 50، و200 GB لعدد 50 إلى 100. تعامل مع هذه الأرقام كبداية مختبرية، لا كـ Sizing نهائي؛ فالحجم الفعلي يتأثر بمعدل الأحداث وسياسة الاحتفاظ ونوع البيانات.
- حدد هدفاً واضحاً: اكتشاف محاولات الدخول، مراقبة Domain Controller، استقبال Firewall Syslog، أو متابعة الثغرات. لا تبدأ بكل شيء دفعة واحدة.
- اختر Pilot ممثلاً: عدة أجهزة Windows، وخادم Linux إن وجد، وخادم تطبيق، ومصدر Syslog واحد. افصلها ضمن Agent Groups حسب الدور.
- أنشئ خادم الإدارة: استخدم Linux مدعوماً، وManagement VLAN، وDNS وNTP صحيحين، وشهادة TLS موثوقة أو خطة لاستبدال الشهادة الافتراضية.
- اجمع أقل Telemetry مفيد: Windows Security وSystem والأحداث الإدارية المهمة، وسجلات المصادقة وsudo في Linux، وسجلات Firewall المطلوبة فقط.
- راقب Baseline: امنح البيئة عدة أيام لفهم النشاط الطبيعي، ثم عالج القواعد المزعجة من خلال Scope وشروط دقيقة بدلاً من تعطيلها بصورة عامة.
- اختبر سيناريوهات شرعية: فشل تسجيل دخول داخل المختبر، تغيير ملف تجريبي مراقب، توقف Agent، أو اكتشاف برنامج يحتاج تحديثاً.
- حدد Workflow: من يراجع Alert؟ ما الأولوية؟ متى يُفتح Ticket؟ متى يُصعّد إلى Incident؟ وما الدليل المطلوب للإغلاق؟
- وسع على دفعات: بعد إثبات القيمة والأداء، أضف بقية الخوادم والأجهزة ومصادر Cloud على حلقات نشر يمكن الرجوع عنها.
الأمر التالي مرتبط بسلسلة Wazuh 4.14 الحالية، ويثبت المكونات المركزية All-in-one على خادم Linux. استخدمه على VM نظيفة ومخصصة للمختبر، واقرأ صفحة Quickstart الرسمية للتأكد من الإصدار والأنظمة المدعومة قبل التنفيذ. لا تشغله على خادم إنتاج يستضيف خدمات أخرى.
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash ./wazuh-install.sh -aبعد انتهاء المثبت، احفظ بيانات الدخول في Password Vault، ثم تحقق من الخدمات المركزية:
sudo systemctl status wazuh-manager wazuh-indexer wazuh-dashboard filebeat --no-pagerوللتحقق من Agent على Windows استخدم PowerShell بصلاحية إدارية:
Get-Service wazuhsvc| الاختبار | النتيجة المتوقعة | الدليل الذي تحفظه |
|---|---|---|
| إيقاف Agent مؤقتاً على جهاز Pilot ثم تشغيله. | ظهور تغير الحالة وعودة الاتصال دون Agent مكرر. | Agent ID، الوقت، وسجل الاتصال. |
| تنفيذ محاولات دخول فاشلة يدوية على حساب اختبار. | Alert يوضح الجهاز والحساب والوقت ومصدر الحدث. | Rule ID وEvent ID والحقول المهمة. |
| تعديل ملف غير حساس داخل مجلد FIM تجريبي. | تنبيه إنشاء أو تعديل أو حذف مطابق للعملية. | المسار وChecksum وهوية المستخدم إن كانت Who-data مفعلة. |
| إرسال حدث من Firewall إلى Syslog. | وصول الحدث وقابلية البحث في الحقول المطلوبة. | عنوان الجهاز وTimestamp وDecoder أو Rule المستخدم. |
| مراجعة جهاز يحوي تحديثاً أمنياً مفقوداً معروفاً. | ظهور CVE المتوافق مع Inventory، ثم تغير حالته بعد المعالجة. | الحزمة والإصدار وCVE ووقت إعادة الجرد. |
تشغيل Wazuh يومياً وتقليل ضوضاء التنبيهات
المشكلة الأكثر شيوعاً ليست فشل التثبيت، بل نجاحه في إنتاج آلاف التنبيهات التي لا يملك أحد وقتاً لمراجعتها. الحل هو تشغيل المنصة كخدمة لها Owners وPriorities وRunbooks، وليس كلوحة تُفتح عند وقوع مشكلة فقط.
- تأكيد الحدث: هل Alert حقيقي، وهل Timestamp واسم الجهاز والمستخدم والمصدر صحيحة؟
- تحديد النطاق: هل حدث على جهاز واحد أم عدة أجهزة؟ وهل الحساب أو IP ظهر في أحداث أخرى؟
- جمع السياق: راجع الأحداث السابقة واللاحقة، وAsset Criticality، والتغييرات المصرح بها، وحالة Endpoint.
- اتخاذ الإجراء الأقل خطراً: احتواء جهاز أو حساب بعد التأكد، بدلاً من تشغيل استجابة واسعة غير قابلة للتحكم.
- التحقق: تأكد أن النشاط توقف وأن الخدمة الطبيعية ما زالت تعمل.
- التوثيق والتحسين: سجل الأدلة والقرار، وعدل Rule أو Runbook إذا ظهر نقص أو False Positive.
| التكرار | المهام | مؤشر النجاح |
|---|---|---|
| يومي | مراجعة التنبيهات العالية، Agents المنقطعة، فشل Ingestion، ومحاولات الدخول غير المعتادة. | لا توجد Alerts حرجة بلا Owner أو قرار موثق. |
| أسبوعي | مراجعة القواعد كثيرة الضوضاء، الثغرات الجديدة، حالة التخزين، ونسبة الأجهزة المتصلة. | انخفاض False Positives مع بقاء تغطية حالات الاستخدام المهمة. |
| شهري | اختبار Detection واحد، مراجعة RBAC والحسابات، فحص الشهادات والنسخ الاحتياطي، ومراجعة سعة Indexer. | اختبار موثق وRestore أو Validation قابل للإثبات. |
| قبل الترقية | قراءة Release Notes، نسخ الإعدادات والقواعد والشهادات، اختبار Upgrade وRollback، وتأكيد توافق المكونات. | كل المكونات المركزية على Patch Level متطابق، والخادم ليس أقدم من Agents. |
- ضع Wazuh داخل شبكة إدارة منفصلة، ولا تكشف Dashboard أو API أو Indexer مباشرة للإنترنت.
- استخدم RBAC وحسابات فردية وSSO أو MFA عندما يتاح ضمن تصميم الهوية، ولا تشارك حساب admin.
- قسم Agents إلى مجموعات مثل Domain Controllers وServers وWorkstations وLinux وDMZ، وطبّق سياسة مناسبة لكل مجموعة.
- اكتب القواعد المخصصة في المسارات المخصصة بدلاً من تعديل القواعد الافتراضية، حتى لا تفقد التعديلات عند الترقية.
- خطط لسياسة Retention وIndex Lifecycle قبل امتلاء القرص، وحدد ما الذي يجب أن يبقى قابلاً للبحث وما الذي يمكن أرشفته.
- احتفظ بنسخة آمنة من الإعدادات والقواعد والشهادات، وخطط لنسخ Indexer بالطريقة المدعومة، ثم اختبر الاستعادة.
- لا ترقِّ المكونات عشوائياً؛ وفق وثائق Wazuh يجب أن تحمل المكونات المركزية الإصدار نفسه بما فيه Patch Level، وأن يكون Wazuh Manager مساوياً لـ Agents أو أحدث منها.
- اربط التنبيهات المهمة بـ Ticket أو Incident Record حتى يصبح لها Owner ووقت استجابة وقرار إغلاق.
في بيئات Windows، تبدأ جودة الكشف من جودة Auditing وWindows Event Logs وGroup Policy. إذا كانت سجلات Domain Controllers ناقصة أو الوقت غير متزامن أو الأجهزة لا تطبق السياسات، فلن يستطيع SIEM تعويض البيانات غير الموجودة. يمكن الرجوع إلى دليل Active Directory وWindows Server لفهم طبقة الهوية والسجلات التي يعتمد عليها جزء كبير من المراقبة.
الأسئلة الشائعة عن Wazuh
هل Wazuh مجاني بالكامل؟
البرنامج ذاتي الاستضافة مجاني ومفتوح المصدر بترخيص GPLv2. لكن الشركة تتحمل تكلفة الخوادم والتخزين والنسخ الاحتياطي والإدارة والتحديث والوقت اللازم لمراجعة التنبيهات. توجد أيضاً خدمات Cloud ودعم احترافي اختيارية مدفوعة.
هل يستبدل Wazuh برنامج Antivirus أو Microsoft Defender؟
لا. يستطيع Wazuh جمع أحداث Defender وتحليلها وربطها بأحداث أخرى، ويقدم وظائف اكتشاف إضافية، لكنه لا يلغي الحاجة إلى طبقة Endpoint Protection متخصصة ومحدثة.
هل يمكن تثبيت مكونات Wazuh المركزية على Windows Server؟
وفق الوثائق الحالية، تتطلب المكونات المركزية معالجاً 64-bit ونظام Linux مدعوماً. يمكن تثبيت Wazuh Agent على Windows لمراقبته وإرسال بياناته إلى الخادم المركزي.
هل يناسب Wazuh الشركات الصغيرة؟
نعم، خصوصاً عندما تبدأ الشركة بحالات استخدام محددة مثل مراقبة Domain Controller والخوادم وFirewall. نشر All-in-one مناسب للمختبرات والبيئات الصغيرة، لكن يجب ألا يُعتمد في خدمة حرجة من دون دراسة نقطة الفشل والسعة والنسخ الاحتياطي.
هل يحتاج كل جهاز إلى Wazuh Agent؟
الأجهزة التي تريد منها Telemetry عميقة مثل FIM وInventory وSCA تحتاج عادةً إلى Agent. أما أجهزة الشبكة وبعض الأنظمة فقد ترسل Syslog أو تستخدم Agentless Monitoring، لكن مستوى الرؤية يختلف بحسب المصدر والتكامل.
هل يمكن تشغيل Wazuh من دون اتصال مباشر بالإنترنت؟
يمكن تصميم بيئة مقيدة أو Offline، وتدعم وثائق Wazuh مستودعاً محلياً لمحتوى Vulnerability Detection. لكن تثبيت الحزم والتحديثات وThreat Intelligence يحتاج خطة نقل وتحديث موثقة، ولا ينبغي ترك المنصة القديمة بلا دورة Patch.
هل أحتاج إلى فريق SOC على مدار الساعة؟
ليس شرطاً لبدء الاستخدام، لكن يجب وجود شخص أو فريق يملك التنبيهات ويعرف متى يراجعها وكيف يصعّدها. البيئة عالية المخاطر أو الخدمة المستمرة تحتاج زمناً أقصر للمراقبة والاستجابة من شركة صغيرة منخفضة الحساسية.
الخاتمة: هل Wazuh مناسب لشركتك؟
Wazuh خيار قوي عندما تحتاج إلى منصة مفتوحة المصدر تجمع مراقبة Endpoint وتحليل Logs وFIM وتقييم الإعدادات واكتشاف الثغرات المعروفة ضمن رؤية مركزية. ميزته الحقيقية ليست أنه «مجاني»، بل أنه مرن وقابل للتخصيص ويستطيع ربط بيانات كانت موزعة بين Windows وLinux وFirewall والسحابة.
في المقابل، لا تبدأ بنشر شامل ولا تقيس النجاح بعدد Alerts. ابدأ بحالة استخدام واحدة مؤلمة، وانشر Pilot صغيراً، واختبر وصول الدليل من المصدر إلى Dashboard، واضبط القواعد، وعيّن Owner لكل تنبيه مهم. إذا أثبتت التجربة أن الفريق يكتشف المشكلة أسرع ويتخذ قراراً أوضح، عندها يصبح التوسع قراراً هندسياً مبرراً.
الخطوة العملية التالية هي إنشاء قائمة من عشرة أصول حرجة وثلاثة سيناريوهات تريد اكتشافها، ثم بناء Pilot مع معايير نجاح وRollback ومدة احتفاظ واضحة. بهذه الطريقة يصبح Wazuh جزءاً من عملية أمنية قابلة للإدارة، لا مجرد أداة أخرى تعمل في الخلفية.