> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # Wazuh أم Security Onion؟ أيهما تبدأ به - URL: https://arabroot.io/articles/wazuh-ام-security-onion-ايهما-تبدا-به/ - Published: 2026-10-26T07:15:15.000Z - Updated: 2026-10-26T08:14:44.000Z - Description: مقارنة بالأرقام بين منصة ترى داخل الجهاز وأخرى ترى الشبكة، ومتى تكفيك واحدة ومتى تحتاج الاثنتين معاً. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الأمن السيبراني, الاستضافة الذاتية, Wazuh, Security Onion بعد ثلاثة مقالات في هذه السلسلة جلس مدير شركة التوزيع الصغيرة في الدمام مع فريق تقنية المعلومات، وهو شخصان، وطرح سؤالاً واحداً: لدينا الآن Wazuh على كل السيرفرات، ومستشعر يشغل Suricata وZeek، وقرأنا عن Security Onion، فهل نحتاجها كلها؟ وإذا كان علينا أن نختار واحدة فأيها؟ وكم ستكلفنا كل واحدة من العتاد ومن وقتكما؟ وهو سؤال منطقي من مدير ينظر إلى الميزانية، ولكنه يخلط بين شيئين مختلفين، لأن Wazuh وSecurity Onion لم يصمما للإجابة عن السؤال نفسه، فالأول يسأل كل جهاز عما حدث داخله، والثاني يسأل الشبكة عما مر فيها، والمقارنة بينهما تشبه المقارنة بين كاميرات المراقبة داخل المكاتب والكاميرا على باب المبنى: كل منهما يرى ما لا تراه الأخرى، والسؤال الحقيقي ليس أيهما أفضل وإنما ما الذي تحتاج أن تراه أولاً. وفي هذا المقال سوف نجيب عن سؤال المدير بالأرقام التي جمعناها في السلسلة: ما قسناه بأنفسنا لـ Wazuh في [مختبر Wazuh](https://arabroot.io/articles/%D9%85%D8%B1%D8%A7%D9%82%D8%A8%D8%A9-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D9%85%D8%B9-wazuh-%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D8%AC%D9%84-%D8%A7%D9%84%D9%89-%D8%AD%D8%B8%D8%B1-%D8%A7%D9%84%D9%85%D9%87%D8%A7%D8%AC%D9%85/)، وما قسناه لـ Suricata وZeek في [مختبر مراقبة الشبكة](https://arabroot.io/articles/%D8%A7%D9%83%D8%AA%D8%B4%D8%A7%D9%81-%D8%A7%D9%84%D8%AA%D8%B3%D9%84%D9%84-%D9%81%D9%8A-%D8%A7%D9%84%D8%B4%D8%A8%D9%83%D8%A9-ids-%D9%85%D8%B9-suricata-%D9%88-zeek/)، وما تقوله الوثائق الرسمية عن Security Onion كما عرضناه في [مقال Security Onion](https://arabroot.io/articles/security-onion-%D9%85%D9%86%D8%B5%D8%A9-%D9%85%D8%AA%D9%83%D8%A7%D9%85%D9%84%D8%A9-%D9%84%D9%85%D8%B1%D8%A7%D9%82%D8%A8%D8%A9-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B4%D8%A8%D9%83%D8%A9/). 📚 المواضيع في السلسلة: (1) كيف يعمل محرك كشف SIEM من الداخل؟ (2) حلول الأمن التجارية وبدائلها مفتوحة المصدر. (3) مراقبة السيرفرات مع Wazuh. (4) مراقبة الشبكة واكتشاف التسلل مع Suricata وZeek. (5) Security Onion. (6) Wazuh أم Security Onion؟ (الموضوع الحالي) [![](https://arabroot.io/content/images/2026/10/wazuh-lab-cover-cover.webp)دليلمراقبة السيرفرات مع Wazuh: من السجل Log إلى حظر المهاجمشغلنا Wazuh مع وكيل على سيرفر تجريبي، فكشف تخمين كلمات مرور SSH وحظر المهاجم تلقائياً، ونبه على ملف PHP دخيل خلال ثانية.](https://arabroot.io/articles/%D9%85%D8%B1%D8%A7%D9%82%D8%A8%D8%A9-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D9%85%D8%B9-wazuh-%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D8%AC%D9%84-%D8%A7%D9%84%D9%89-%D8%AD%D8%B8%D8%B1-%D8%A7%D9%84%D9%85%D9%87%D8%A7%D8%AC%D9%85/)[![](https://arabroot.io/content/images/2026/10/suricata-zeek-cover-cover.webp)دليلمراقبة الشبكة واكتشاف التسلل IDS مع Suricata وZeekمختبر حقيقي يقرأ الحركة نفسها بأداتين، فيكشف Suricata الهجمات المعروفة ويكتب Zeek سجلاً لكل اتصال، مع الضبط وفقد الحزم.](https://arabroot.io/articles/%D8%A7%D9%83%D8%AA%D8%B4%D8%A7%D9%81-%D8%A7%D9%84%D8%AA%D8%B3%D9%84%D9%84-%D9%81%D9%8A-%D8%A7%D9%84%D8%B4%D8%A8%D9%83%D8%A9-ids-%D9%85%D8%B9-suricata-%D9%88-zeek/)[![](https://arabroot.io/content/images/2026/10/security-onion-cover-cover.webp)دليلSecurity Onion: منصة متكاملة لمراقبة أمن الشبكةما الذي تجمعه Security Onion فوق Suricata وZeek، وكم تحتاج من العتاد، وكيف تجربها بأمان قبل أن تقرر نقل مراقبتك إليها.](https://arabroot.io/articles/security-onion-%D9%85%D9%86%D8%B5%D8%A9-%D9%85%D8%AA%D9%83%D8%A7%D9%85%D9%84%D8%A9-%D9%84%D9%85%D8%B1%D8%A7%D9%82%D8%A8%D8%A9-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B4%D8%A8%D9%83%D8%A9/) وسوف نناقش في هذا المقال ما يلي: - السؤال الذي صممت كل منصة للإجابة عنه، وما يراه كل منهما وما لا يراه. - البنية جنباً إلى جنب، ولماذا تتشابه الطبقات ويختلف مصدر البيانات. - الذاكرة والقرص لكل منصة، بالأرقام التي قسناها وبالحد الأدنى في الوثائق. - ستة أحداث من السلسلة، ومن يرى كل حدث منها، ثم الاستجابة: من يمنع ومن يكتفي بالتنبيه. - الرخصة والتكلفة والتشغيل اليومي ومهارات الفريق. - ضوابط الهيئة الوطنية للأمن السيبراني: أي ضابط تغطيه كل منصة. - تشغيل الاثنين معاً، ومسار قرار من ثلاثة أسئلة، والأخطاء الشائعة. ## سؤالان مختلفان: الجهاز أم الشبكة؟ تصف [صفحة مكونات Wazuh](https://documentation.wazuh.com/current/getting-started/components/index.html?ref=arabroot.io) المنصة بأنها تقدم ميزات XDR وSIEM لحماية السيرفرات والسحابة والـ Containers، وتعدد ما تفعله: تحليل السجلات، وكشف الاختراق والبرمجيات الخبيثة، ومراقبة سلامة الملفات، وتقييم الإعدادات، وكشف الثغرات، ودعم الامتثال، وكل ذلك يبدأ من وكيل Agent يعمل على الجهاز نفسه، على Linux وWindows وmacOS وأنظمة أخرى. أما [صفحة مقدمة Security Onion](https://docs.securityonion.net/en/3/main/introduction/?ref=arabroot.io) فتبدأ من الشبكة: كشف التسلل بـ Suricata، وسجلات البروتوكولات بـ Zeek، والتقاط الحزم الكامل، وتحليل الملفات، ثم تضيف رؤية الأجهزة عبر Elastic Agent لتسد الفجوة التي يتركها التشفير. والشكل التالي يضع الاثنين جنباً إلى جنب: ![ثلاثة أعمدة: Wazuh يرى من داخل الجهاز سجلات النظام والتطبيقات عبر الوكيل ومراقبة سلامة الملفات وتقييم الإعدادات مقابل CIS وكشف الثغرات من قائمة الحزم والاستجابة التلقائية ومراقبة السحابة والـ Containers، ويحتاج وكيلاً على كل جهاز. وSecurity Onion يرى من الشبكة تنبيهات NIDS وسجلاً لكل اتصال والتقاط الحزم الكامل وتحليل الملفات والمصائد وإدارة الحالات، ويرى الأجهزة التي لا يثبت عليها شيء ولا يرى محتوى الحركة المشفرة. وفي الوسط ما يشتركان فيه: استقبال Syslog ومحرك بحث ولوحات وتنبيهات ووكيل على الأجهزة وقواعد كشف قابلة للكتابة](https://arabroot.io/content/images/2026/10/wazuh-vs-security-onion-01-coverage.webp) المنطقة المشتركة حقيقية، ولكن قوة كل منصة في الجهة التي صممت من أجلها والمنطقة المشتركة في الوسط تسبب أغلب الخلط، فكلاهما يستقبل Syslog من الجدران النارية والراوترات، وكلاهما فيه محرك بحث ولوحات وتنبيهات، وكلاهما له وكيل على الأجهزة، فـ Security Onion يستخدم Elastic Agent مع Osquery، وWazuh يستطيع أن يقرأ `eve.json` من Suricata كما فعلنا في المقال الرابع. لذلك يستطيع كل منهما نظرياً أن يقوم بجزء من عمل الآخر، والسؤال العملي هو: ما الذي يقدمه كل منهما جاهزاً ومختبراً دون أن تبنيه بنفسك؟ والإجابة في كل قسم من هذا المقال تعود إلى الشكل أعلاه: Wazuh قوي داخل الجهاز، وSecurity Onion قوي على الشبكة. ## البنية جنباً إلى جنب إذا نظرت إلى المنصتين من بعيد فستجد أربع طبقات متشابهة، والشكل التالي يبين ذلك: ![عمودان بأربع طبقات: Wazuh من الوكيل على كل جهاز إلى الخادم أو المدير الذي يفك السجلات بالـ Decoders ويطبق القواعد إلى الفهرس المبني على OpenSearch إلى لوحة التحكم، وSecurity Onion من المستشعر على منفذ SPAN أو TAP مع Suricata وZeek والـ PCAP وElastic Agent إلى المدير مع Logstash وRedis وSOC وKibana وElastAlert إلى عقد البحث بـ Elasticsearch إلى واجهة SOC](https://arabroot.io/content/images/2026/10/wazuh-vs-security-onion-02-architecture.webp) الطبقات متشابهة، والفرق الجوهري في الطبقة الأولى: وكيل داخل الجهاز أم مستشعر على الشبكة وفي الشكل أعلاه لاحظ التالي: - **الطبقة الأولى هي الفرق الحقيقي:** في Wazuh وكيل صغير على كل جهاز، استهلك في مختبرنا مع السيرفر والخدمات 65 MiB فقط، وفي Security Onion مستشعر واحد يرى نسخة من الحركة، فالأول يكلف قليلاً لكل جهاز ويحتاج أن تثبته وتحدثه على كل جهاز، والثاني يكلف كثيراً في نقطة واحدة ولا يحتاج شيئاً على الأجهزة. - **التحليل في مكانين مختلفين:** في Wazuh يحلل الخادم السجلات بالـ Decoders والقواعد قبل أن تصل إلى الفهرس، فما يصل إلى الفهرس هو التنبيهات والأحداث المحللة، كما شرحنا في [محرك كشف SIEM من الداخل](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D9%8A%D8%B9%D9%85%D9%84-%D9%85%D8%AD%D8%B1%D9%83-%D9%83%D8%B4%D9%81-siem-%D9%85%D9%86-%D8%A7%D9%84%D8%AF%D8%A7%D8%AE%D9%84/). وفي Security Onion يحدث أغلب الكشف على المستشعر نفسه، أي Suricata وZeek، ثم تأتي قواعد Sigma في ElastAlert على السجلات بعد الفهرسة. - **محرك البحث من العائلة نفسها:** فهرس Wazuh مبني على OpenSearch، وSecurity Onion يستخدم Elasticsearch، وكلاهما من الأصل نفسه قبل أن يفترقا، وقد شرحنا قصة الافتراق في [OpenSearch البديل المفتوح لـ Elasticsearch](https://arabroot.io/articles/opensearch-%D8%A7%D9%84%D8%A8%D8%AF%D9%8A%D9%84-%D8%A7%D9%84%D9%85%D9%81%D8%AA%D9%88%D8%AD-%D9%84-elasticsearch/). وهذا يعني أن مهارات الفهرسة ومدة الاحتفاظ واللقطات Snapshots التي يتعلمها الفريق في إحداهما تنتقل إلى الأخرى. - **التوسع:** Wazuh يتوسع بعنقود من الخوادم Server Cluster وعنقود من الفهارس، وتقول صفحة المكونات إن الخادم الواحد يحلل بيانات مئات أو آلاف الوكلاء. وSecurity Onion يتوسع بإضافة مستشعرات لكل نقطة مراقبة وعقد بحث للتخزين، وعقد استقبال لتحمل توقف المدير. ## كيف يكشف كل منهما؟ القواعد من الداخل قبل الأرقام نحتاج أن نفهم كيف يقرر كل منهما أن شيئاً ما يستحق التنبيه، لأن طريقة الكشف هي التي تحدد نوع العمل الذي سوف يقوم به فريقك كل يوم. في Wazuh يمر كل سطر سجل بمرحلتين. الأولى هي فك السجل Decoding، حيث يحول الـ Decoder سطراً نصياً مثل رسالة sshd إلى حقول منظمة: العنوان المصدر واسم المستخدم ونتيجة المحاولة. والثانية هي القواعد Rules المكتوبة بـ XML، وكل قاعدة لها رقم ومستوى من 0 إلى 15، وتستطيع أن تبني قاعدة على قاعدة أخرى، أو أن تشترط تكرار الحدث عدداً من المرات من نفس المصدر خلال مدة، وهكذا تحولت ثماني محاولات فاشلة في مختبرنا إلى القاعدة 5763 بالمستوى 10\. وفوق السجلات توجد وحدات Modules تعمل على الجهاز نفسه، مثل مراقبة سلامة الملفات التي تحسب بصمة كل ملف في المجلدات المراقبة وتنبه عند تغيرها، وتقييم الإعدادات SCA الذي يفحص إعداد النظام مقابل سياسات مثل CIS ويعطي درجة، وقد أعطى السيرفر التجريبي في المختبر 43 من 100 دون أن نطلب ذلك. والنتيجة أن العمل اليومي مع Wazuh يشبه عمل مدير الأنظمة: تقرأ سجلات تطبيقاتك، وتكتب لها Decoders وقواعد، وتختبرها في `wazuh-logtest` قبل أن تنشرها. أما في Security Onion فالكشف موزع على ثلاثة محركات، وكلها تدار من صفحة Detections. الأول Suricata الذي يطابق كل اتصال مع عشرات الآلاف من التوقيعات، وتنبيهاته محددة جداً بنمط في مكان معين من البروتوكول، كما رأينا في تشريح القاعدة 1000002\. والثاني قواعد Sigma التي يشغلها ElastAlert على السجلات بعد فهرستها، وهي صيغة مستقلة عن المنتج تصف نمطاً في السجلات، فتنطبق على سجلات Zeek وسجلات الأجهزة التي يجمعها Elastic Agent. والثالث قواعد YARA التي يطبقها Strelka على الملفات المستخرجة من الحركة. وفوق هذه المحركات يبقى Zeek نفسه بلغة سكربتاته، فتستطيع أن تكتب منطقاً كاملاً مثل السكربت الذي رفع إشعاراً عند ظهور أدوات الفحص. والعمل اليومي هنا يشبه عمل محلل الشبكات: تقرأ البروتوكولات والحزم، وتكتب توقيعات وسكربتات، وتقيس الإنذارات الكاذبة على حركة حقيقية. وقد يتساءل البعض: أي الطريقتين أدق؟ والإجابة أن الدقة تأتي من القرب من الحدث وليس من المنصة، فالوكيل الذي يقرأ سجل sshd يعرف بيقين أن الدخول فشل، والمستشعر الذي يرى اتصالات SSH مشفرة يخمن ذلك من عددها، وفي المقابل المستشعر الذي يرى طلب HTTP كاملاً يعرف بيقين ما أرسله المهاجم، والوكيل يعرف فقط ما قرر التطبيق أن يكتبه في سجله. لذلك ضع كل قاعدة في المكان الأقرب للدليل الذي تبحث عنه. ## كم تحتاج كل منصة من العتاد؟ هنا يظهر الفرق الذي يهم المدير مباشرة، والشكل التالي يجمع الأرقام التي قسناها في السلسلة مع الحد الأدنى في الوثائق الرسمية: ![أعمدة أفقية للذاكرة: Suricata وZeek في مختبرنا 0.55 GiB، وWazuh عقدة واحدة في مختبرنا 2.5 GiB، وSecurity Onion Import بحد أدنى 4 GB، وWazuh حتى 100 وكيل 8 GiB في الوثائق، وSecurity Onion Evaluation بحد أدنى 8 GB، وStandalone بحد أدنى 24 GB، وStandalone مع حركة حقيقية 32 GB أو أكثر، وتحتها أن Wazuh يطلب 50 إلى 200 GB لتسعين يوماً بينما قد يحتاج Security Onion مع PCAP مئات الجيجابايتات يومياً](https://arabroot.io/content/images/2026/10/wazuh-vs-security-onion-03-resources.webp) Security Onion أثقل بكثير لأنه يحمل الالتقاط والتحليل والفهرسة معاً على الجهاز نفسه والتفصيل كما يلي: | القياس | Wazuh | Security Onion | | ---------------------- | ------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------- | | الحد الأدنى في الوثائق | 4 vCPU و8 GiB و50 GB لتسعين يوماً حتى 25 وكيلاً، و8 vCPU و8 GiB و200 GB حتى 100 وكيل | Import بمعالجين و4 GB و100 GB، وStandalone بأربع أنوية و24 GB و200 GB وكرتي شبكة | | ما قسناه في السلسلة | نحو 2.5 GiB للعقدة الواحدة مع وكيل واحد، منها 1.63 GiB للفهرس | لم نشغلها، وأقرب قياس هو مكونات الشبكة وحدها: 465 MiB لـ Suricata و97 MiB لـ Zeek | | ما يحدد القرص | عدد الوكلاء وكمية السجلات ومدة الاحتفاظ | متوسط الحركة ومدة حفظ الحزم، فـ 50 Mbps تعني نحو 540 GB يومياً من PCAP | | ما يحدد المعالج | عدد الأحداث في الثانية | سرعة الخط، بنحو 200 Mbps لكل Worker من Suricata أو Zeek | | الـ Docker Images | نحو 7.4 GB في مختبرنا | 30 GB بحسب الوثائق، ومثلها للتحديث | والأرقام مصادرها [صفحة البداية السريعة لـ Wazuh](https://documentation.wazuh.com/current/quickstart.html?ref=arabroot.io) و[صفحة عتاد Security Onion](https://docs.securityonion.net/en/3/main/hardware/?ref=arabroot.io) ومقالا المختبر. وفي الجدول أعلاه لاحظ أن المقارنة ليست عادلة تماماً، فـ Wazuh في المختبر كان بدون كشف الثغرات، وهو وحده احتاج 2.7 GiB وقرصاً بحجم 11 GB في [مختبر الثغرات](https://arabroot.io/articles/%D9%85%D8%AE%D8%AA%D8%A8%D8%B1-%D8%A7%D9%83%D8%AA%D8%B4%D8%A7%D9%81-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%AA%D8%A7%D8%AB%D8%B1%D8%A9-%D8%A8%D8%AB%D8%BA%D8%B1%D8%A9-cve-%D9%88%D8%A7%D8%B5%D9%84%D8%A7%D8%AD%D9%87%D8%A7/)، وSecurity Onion يحمل في الحد الأدنى نفسه الالتقاط الكامل والتحليل والفهرسة والواجهة. ولكن الرسالة للمدير واضحة: Wazuh يعمل على سيرفر افتراضي متوسط، وSecurity Onion للإنتاج يحتاج جهازاً قوياً مخصصاً بذاكرة 32 GB أو أكثر وأقراص سريعة، وتنصح وثائقه بعتاد مادي للحركة الكبيرة. ## الهجوم نفسه بعينين: من يرى ماذا؟ أفضل طريقة لفهم الفرق أن نأخذ أحداثاً حقيقية من السلسلة ونسأل عن كل حدث: من يراه؟ والشكل التالي يجمع ستة أحداث: ![جدول من ستة أحداث: تخمين كلمات مرور SSH يراه Wazuh في auth.log ويحظر، ويراه Security Onion جزئياً كاتصالات SSH كثيرة ومحتواها مشفر. ورفع Web Shell يراه Wazuh عبر FIM خلال ثانية، ويراه Security Onion جزئياً إذا لم يكن الطلب مشفراً. وحقن SQL على HTTP يراه Wazuh جزئياً إذا سجله التطبيق، ويراه Security Onion بتنبيه Suricata وhttp.log وPCAP. والحقن نفسه على HTTPS يراه الاثنان جزئياً. وطابعة تتصل بعنوان خارجي لا يراها Wazuh لعدم وجود وكيل، ويراها Security Onion في conn.log. وحزمة قديمة فيها ثغرة يراها Wazuh بكشف الثغرات، ويراها Security Onion جزئياً إذا أعلن البرنامج إصداره](https://arabroot.io/content/images/2026/10/wazuh-vs-security-onion-04-same-attacks.webp) لا توجد منصة واحدة ترى كل شيء ولنفصل كل حدث بما رأيناه فعلاً في السلسلة: - **تخمين كلمات مرور SSH:** في مختبر Wazuh أطلقت ثماني محاولات فاشلة خلال 28 ثانية القاعدة 5763، وحظر الحظر التلقائي عنوان المهاجم في الثانية نفسها. أما المستشعر على الشبكة فيرى اتصالات SSH متكررة من عنوان واحد، ويستطيع Zeek أن يرى عددها ومدتها، ولكن محتواها مشفر، فلا يعرف هل كانت كلمة المرور خاطئة أم صحيحة، وهذا الفرق حاسم: Wazuh يعرف أن الدخول فشل ثماني مرات، والمستشعر يخمن ذلك من شكل الاتصالات. - **رفع Web Shell إلى مجلد الموقع:** نبهت مراقبة سلامة الملفات في Wazuh على ملف PHP الجديد خلال ثانية، وبعد أن رفعنا مستوى القاعدة صار التنبيه بالمستوى 12\. والمستشعر يرى طلب الرفع نفسه إذا كان على HTTP، أو ينبه عليه بقاعدة مكتوبة له، ولكنه لا يرى الملف على القرص، ولا يعرف أنه كتب في مجلد الموقع. - **حقن SQL على HTTP:** في مختبر الشبكة أطلقت قاعدتنا المحلية 1000001 تنبيهاً بالأولوية 1، وسجل Zeek الطلب كاملاً ووسمه `HTTP::URI_SQLI`، ومع الالتقاط الكامل في Security Onion سوف تجد الحزم كذلك. أما Wazuh فيرى الطلب فقط إذا سجله الـ Web Server أو التطبيق، وبالشكل الذي سجلاه به. - **الحقن نفسه على HTTPS:** هنا تتراجع الشبكة، فالمستشعر يرى الاسم في SNI والوقت والحجم فقط، كما رأينا في `ssl.log`، ويبقى الأمل في سجلات التطبيق عبر Wazuh، أو في وضع المستشعر خلف الـ Reverse Proxy الذي يفك التشفير. - **طابعة تتصل بعنوان خارجي:** لا يوجد وكيل على الطابعة، فلا يراها Wazuh إلا إذا وصلت سجلات الجدار الناري إليه عبر Syslog. والمستشعر يكتب الاتصال في `conn.log` مهما كان، وينبه إذا كان العنوان في قواعد البنية التحتية الضارة المعروفة. - **حزمة قديمة فيها ثغرة:** كشف الثغرات في Wazuh يقارن قائمة الحزم المثبتة على كل جهاز بقاعدة الثغرات، كما في [توثيق كشف الثغرات](https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/index.html?ref=arabroot.io). والمستشعر يرى الإصدار فقط إذا أعلنه البرنامج في الحركة، كما رأينا في `software.log` مع `nginx/1.22.1`، وهذا لا يغطي المكتبات داخل التطبيقات ولا الحزم التي لا تتكلم على الشبكة. والنتيجة أن كل منصة ترى ثلاثة أحداث بوضوح وتخمن الباقي، والأحداث التي تراها كل منهما بوضوح هي التي لا تراها الأخرى، وهذا ما يجعل الفرق الكبيرة تجمع بينهما، ويجعل الفريق الصغير يبدأ بالمنصة التي تغطي أخطر ما في بيئته. ## الاستجابة: من يمنع ومن يكتفي بالتنبيه؟ الفرق التالي يظهر بعد التنبيه. ففي Wazuh الاستجابة التلقائية Active Response جزء أساسي من المنصة، وقد رأينا في المختبر السكربت `firewall-drop` يضيف قاعدة iptables على السيرفر نفسه ويحظر المهاجم، ثم يرفع الحظر بعد 180 ثانية، وتستطيع أن تكتب استجابات أخرى مثل تعطيل حساب أو عزل جهاز، كما في [توثيق الاستجابة التلقائية](https://documentation.wazuh.com/current/user-manual/capabilities/active-response/index.html?ref=arabroot.io). ولأن الوكيل داخل الجهاز، فالاستجابة تحدث هناك، قرب المشكلة. أما Security Onion فمنصة مراقبة وتحقيق، فالمستشعر يرى نسخة من الحركة ولا يقف في طريقها، وSuricata فيه يعمل بوضع الكشف، ولا تذكر الوثائق آلية حظر تلقائي تنفذها المنصة على الأجهزة أو الجدار الناري. والاستجابة فيها هي سير عمل المحلل: التنبيه، ثم التحقق في السجلات والحزم، ثم الحالة Case، ثم القرار الذي ينفذه شخص على الجدار الناري أو الجهاز. وهذا ليس نقصاً في التصميم، وإنما اختيار يتفق مع ما قلناه في مقال Suricata وZeek: المنع التلقائي من الشبكة يحتاج ثقة كبيرة في القواعد، لأن القاعدة الخاطئة تقطع خدمة حقيقية. وفي شركة الدمام يعني هذا أن الحظر التلقائي لمن يخمن كلمات المرور يبقى في Wazuh، والتحقيق في حادثة مثل تلك الليلة التي بدأنا بها مقال Security Onion يبقى في Security Onion إذا اختاروه، وكلاهما يحتاج قراراً بشرياً لكل ما هو أكبر من حظر مؤقت. ## الرخصة والتكلفة الفرق في الرخصة مهم أكثر مما يبدو. فـ Wazuh مفتوح المصدر برخصة GPL-2.0 كما في [ملف الرخصة](https://github.com/wazuh/wazuh/blob/main/LICENSE?ref=arabroot.io)، ولا توجد نسخة مدفوعة بميزات مقفلة، وتبيع الشركة الدعم والخدمة السحابية. أما Security Onion فمكوناته ومكونات Elastic فيه برخصة Elastic License 2.0 كما في [صفحة الرخصة](https://docs.securityonion.net/en/3/main/license/?ref=arabroot.io)، وهي رخصة متاحة المصدر Source Available، وأهم قيودها كما في [نصها الكامل](https://www.elastic.co/licensing/elastic-license?ref=arabroot.io) أنك لا تستطيع تقديم البرنامج لطرف ثالث كخدمة مستضافة أو مدارة تعطيه مجموعة جوهرية من ميزاته. وللاستخدام الداخلي في جهتك لا يفرق هذا شيئاً، ولكن إذا كنت مزود خدمات أمنية Managed Security Service Provider يبني خدمة مراقبة للعملاء، فـ Wazuh بالرخصة GPL أوضح طريقاً، وSecurity Onion يحتاج مراجعة قانونية قبل البدء. وفي التكلفة المباشرة: | البند | Wazuh | Security Onion | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | البرنامج | مجاني بكل ميزاته | النسخة المجتمعية مجانية، والنسخة Pro تضيف OIDC والإشعارات وKafka والمساعد والدعم | | النسخة المدارة أو المدفوعة | [Wazuh Cloud](https://wazuh.com/cloud/?ref=arabroot.io) من 571 دولاراً شهرياً لخطة حتى 100 وكيل، و923 لخطة حتى 250، و1467 لخطة حتى 500، عند مراجعتها في أكتوبر 2026 | سعر [Pro](https://securityonion.com/pro?ref=arabroot.io) غير منشور، والرخصة القياسية حتى عشر عقد | | العتاد | سيرفر افتراضي متوسط يكفي البداية | جهاز مخصص بذاكرة 32 GB أو أكثر وأقراص سريعة، وكرت التقاط، ومنفذ SPAN أو TAP | | الوقت | تثبيت الوكلاء وتحديثهم، وكتابة القواعد المحلية | إدارة نظام كامل، وضبط القواعد، وتخطيط القرص | وتذكر أن الخدمة السحابية لـ Wazuh تعني أن سجلات أجهزتك تخرج إلى مزود خارجي، وأن المساعد السحابي في Security Onion Pro يعني أن تنبيهاتك تمر بنموذج خارجي، فإذا كانت جهتك ملزمة بشروط على موقع البيانات فراجع ذلك قبل السعر، كما شرحنا في [حماية البيانات الشخصية PDPL للخدمات المستضافة](https://arabroot.io/articles/%D8%AD%D9%85%D8%A7%D9%8A%D8%A9-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D8%A7%D9%84%D8%B4%D8%AE%D8%B5%D9%8A%D8%A9-pdpl-%D9%84%D9%84%D8%AE%D8%AF%D9%85%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B3%D8%AA%D8%B6%D8%A7%D9%81%D8%A9/). والمقارنة مع منتجات SIEM التجارية التي تسعر بحجم البيانات شرحناها في [حلول الأمن التجارية وبدائلها](https://arabroot.io/articles/%D8%AD%D9%84%D9%88%D9%84-%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%AC%D8%A7%D8%B1%D9%8A%D8%A9-%D9%88%D8%A8%D8%AF%D8%A7%D8%A6%D9%84%D9%87%D8%A7-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1/). ## التشغيل اليومي ومهارات الفريق الفريق في شركة الدمام شخصان، وهذا الرقم يحسم أموراً كثيرة، فكل منصة تضيف عملاً يومياً، وهذا ما يضيفه كل منهما: - **التحديث:** في Wazuh تحدث الخادم والفهرس ولوحة التحكم، ثم الوكلاء على كل جهاز، ويمكن تحديث الوكلاء عن بعد من المدير، وآخر إصدار مستقر هو [4.14.9](https://github.com/wazuh/wazuh/releases/tag/v4.14.9?ref=arabroot.io) بتاريخ 15 أكتوبر 2026، والسلسلة 5.0 في مرحلة الإصدارات التجريبية، فلا ينصح بها للإنتاج بعد. وفي Security Onion أمر واحد هو `soup` يحدث كل شيء، ولكنه تحديث لنظام كامل يحتاج متابعة، والإصدار 2.4 انتهى دعمه في 1 أكتوبر 2026. - **النسخ الاحتياطي:** في Wazuh تحفظ إعداد المدير وقواعدك المحلية ومفاتيح الوكلاء، كما فعلنا في المختبر بنسخة حجمها 290 KB لمجلد الإعداد. وفي Security Onion تحفظ المنصة الإعداد يومياً، ولكن بيانات Elasticsearch ومنها الحالات لا تنسخ وحدها. - **المهارات:** Wazuh يحتاج من يفهم سجلات الأنظمة ويكتب قواعد XML وDecoders، وهي مهارات مدير الأنظمة نفسه. وSecurity Onion يحتاج من يفهم الشبكات والبروتوكولات وقواعد Suricata، ويقرأ الحزم، ويدير Elasticsearch، وهي مهارات محلل SOC. - **الضجيج:** كلاهما يحتاج ضبطاً في الأسابيع الأولى، ولكن ضجيج الشبكة أكبر عادة، لأن الإنترنت مليء بأدوات الفحص الآلي، كما رأينا مع تنبيهات Shellshock وأدوات الفحص، وضجيج الوكلاء يأتي من التطبيقات المزعجة في سجلاتها. - **التعايش:** [صفحة أفضل الممارسات](https://docs.securityonion.net/en/3/main/best-practices/?ref=arabroot.io) في Security Onion تطلب ألا تثبت عليه وكلاء أمن من طرف ثالث، فلا تضع وكيل Wazuh على جهاز Security Onion نفسه، وراقبه من داخله. ## ماذا تغطي كل منصة من ضوابط الهيئة الوطنية؟ إذا كانت جهتك ملزمة [بالضوابط الأساسية للأمن السيبراني ECC 2:2024](https://nca.gov.sa/en/regulatory-documents/controls-list/ecc/?ref=arabroot.io)، فهذه الضوابط التي تمس المنصتين، وقد راجعنا أرقامها ونصوصها في وثيقة الضوابط الرسمية: | الضابط | المطلوب باختصار | Wazuh | Security Onion | | ------------------ | -------------------------------------------------------------------------- | --------------------------------------------------- | ------------------------------------------------- | | 2-3-3-1 | الحماية من الفيروسات والبرامج والأنشطة المشبوهة على الأجهزة والسيرفرات | كشف البرمجيات الخبيثة والملفات الدخيلة على الجهاز | تحليل الملفات المارة في الشبكة بـ Strelka وYARA | | 2-5-3-6 | أنظمة الحماية من الاختراقات IPS | لا يغطيه وحده، ويستقبل تنبيهات Suricata إذا أرسلتها | Suricata بقواعد مدارة، بوضع الكشف | | 2-5-3-7 | أمن خدمة أسماء النطاقات DNS | سجلات خادم DNS إذا كان عليه وكيل | سجل كل استعلام DNS على الشبكة | | 2-10-3-1 | التقييم الدوري لاكتشاف الثغرات | كشف الثغرات من قائمة الحزم على كل جهاز | لا يغطيه، فهو يرى الإصدارات المعلنة في الحركة فقط | | 2-12-3-1 و2-12-3-2 | تفعيل السجلات للأصول الحساسة وللحسابات ذات الصلاحيات الهامة والدخول عن بعد | جوهر عمله: سجلات الأجهزة وSSH وsudo | عبر Elastic Agent إذا ثبته، وSyslog | | 2-12-3-5 | الاحتفاظ بالسجلات 12 شهراً على الأقل | يحتاج سياسة فهرس وقرصاً | الافتراضي 90 يوماً، ويحتاج رفعاً وقرصاً | | 2-13-3-1 و2-13-3-2 | خطط الاستجابة والتصعيد وتصنيف الحوادث | التنبيهات بمستويات، وإدارة الحالات بأداة أخرى | صفحة الحالات Cases مدمجة | والدرس من هذا الجدول أن أي منصة وحدها تترك ضوابط مهمة دون تغطية، فـ Wazuh يغطي السجلات والثغرات وحماية الأجهزة، وSecurity Onion يغطي الشبكة وDNS والتحقيق، وتوثيق Wazuh نفسه في [صفحة الامتثال](https://documentation.wazuh.com/current/compliance/index.html?ref=arabroot.io) ينبه إلى أن ربط القواعد بالضوابط إرشادي، وأن تشغيل الأداة لا يعني الامتثال وحده، لأن الامتثال يعتمد على السياسات والإجراءات والأدلة. وشرحنا الضوابط نفسها في [الضوابط الأساسية بلغة بسيطة](https://arabroot.io/articles/%D8%A7%D9%84%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%84%D8%A7%D8%B3%D8%A7%D8%B3%D9%8A%D8%A9-%D9%84%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-nca-ecc-%D8%A8%D9%84%D8%BA%D8%A9-%D8%A8%D8%B3%D9%8A%D8%B7%D8%A9/). ## يوم الحادثة: كيف يبدو التحقيق في كل منصة؟ الأرقام والجداول مفيدة، ولكن الفرق الحقيقي يظهر في يوم سيئ. لنفرض أن مهاجماً وجد ثغرة رفع ملفات في نموذج قديم على متجر شركة الدمام، فرفع ملف PHP صغيراً إلى مجلد الموقع، ثم استخدمه ليرسل أوامر إلى السيرفر. ولنمش مع الفريق في الحالتين، مرة ولديه Wazuh وحده، ومرة ولديه Security Onion أيضاً. مع Wazuh وحده تبدأ القصة بتنبيه مراقبة سلامة الملفات: ملف جديد في مجلد الموقع، بالمستوى 12 بفضل القاعدة المحلية التي كتبناها في المختبر، وفي التنبيه اسم الملف ووقت إنشائه وبصمته. فيذهب الفريق إلى سجلات الـ Web Server في Wazuh، ويبحث عن الطلب الذي سبق إنشاء الملف بثوان، فيجد طلب POST إلى صفحة النموذج من عنوان معين، ثم طلبات GET متتالية إلى الملف الجديد من العنوان نفسه. وحتى هنا القصة واضحة، ولكن السؤال التالي هو الصعب: ماذا كانت الأوامر؟ وماذا رد السيرفر؟ وسجل الـ Web Server في إعداده الافتراضي يكتب الرابط ورمز الرد والحجم، ولا يكتب محتوى الطلب ولا الرد. فيعرف الفريق أن الملف استخدم، ولا يعرف بالضبط فيم، ويضطر أن يفترض الأسوأ: أن كل ما يصل إليه حساب الـ Web Server قد قرئ. ومع Security Onion أيضاً تبدأ القصة بالتنبيه نفسه من Wazuh، لأن المستشعر لا يرى الملف على القرص، ولكن الفريق يأخذ العنوان ووقت الطلب إلى صفحة Hunt، فيجد كل اتصالات هذا العنوان بالمتجر في ذلك اليوم، ويجد أيضاً أنه سأل قبلها بساعة عن صفحات لا وجود لها، وهي علامة فحص آلي. ثم يفتح الحزم الكاملة لطلبات GET إلى الملف، فإذا كانت على HTTP يرى الأوامر نفسها والردود: قائمة ملفات الإعداد، ثم محتوى ملف فيه كلمة مرور قاعدة البيانات. والآن يعرف الفريق ما الذي يجب أن يغيره فوراً، ولا يفترض الأسوأ بل يعرفه، ثم يبحث في `conn.log` هل اتصل السيرفر بعدها بقاعدة البيانات من مكان غير معتاد، أو بعنوان خارجي، وكل خطوة تحفظ في الحالة Case مع الأدلة. ولاحظ ثلاث نقاط في هذه المقارنة. الأولى أن التنبيه الذي بدأ القصة جاء من Wazuh في الحالتين، فالوكيل على السيرفر هو الذي رأى الملف، وهذا يؤكد أن Security Onion لا يغني عن الوكيل. والثانية أن قيمة الحزم كلها مشروطة بأن تكون الحركة غير مشفرة عند المستشعر، فإذا كان المتجر على HTTPS والمستشعر أمام الـ Reverse Proxy فلن يرى الفريق الأوامر، وإنما الأحجام والأوقات فقط، وهنا يأتي قرار مكان المستشعر الذي ناقشناه في مقال Suricata وZeek. والثالثة أن الفرق بين الحالتين ليس في كشف الهجوم وإنما في عمق التحقيق بعده، وهذا بالضبط ما يجب أن يسأل عنه المدير: هل نحتاج أن نعرف ما حدث بالضبط، أم يكفينا أن نعرف أنه حدث ونتصرف على أسوأ احتمال؟ والإجابة تعتمد على ما في السيرفرات، فمتجر يحفظ بيانات بطاقات أو بيانات شخصية لعملاء يحتاج أن يعرف بالضبط، لأن الإبلاغ والتعامل مع العملاء يعتمدان على ذلك. وفي هذا السيناريو يظهر أيضاً ثمن التأخير، فالحزم تحفظ أياماً محدودة بحسب القرص، فإذا اكتشف الفريق الملف بعد أسبوعين فقد تكون الحزم حذفت، وتبقى سجلات Zeek المختصرة لمدة أطول. لذلك اجعل مدة حفظ الحزم أطول من الوقت الذي تتوقع أن يمر بين الحادثة واكتشافها، وهو رقم لا تعرفه إلا من تجربتك، فابدأ بأسبوعين وراجعه بعد كل حادثة. ## تشغيل الاثنين معاً إذا كانت الإجابة أن الشركة تحتاج الجهتين، فهذا تصميم يجمعهما دون أن يتعارضا: ![السيرفرات وأجهزة الموظفين عليها وكيل Wazuh يرسل إلى Wazuh Manager الذي يقدم سجلات الأجهزة وFIM والثغرات والحظر التلقائي ولا يثبت وكيله على Security Onion، والسويتش يرسل نسخة من الحركة عبر منفذ SPAN إلى Security Onion Standalone الذي يقدم Suricata وZeek والـ PCAP والحالات، والطابعات والكاميرات بلا وكيل، والفريق يتابع اللوحتين، مع ملاحظة أن لوحتين عبء على فريق صغير](https://arabroot.io/content/images/2026/10/wazuh-vs-security-onion-05-together.webp) لكل منصة دورها، والقرار الصعب كم لوحة يستطيع فريقك أن يراقب وفي التصميم أعلاه لاحظ التالي: - الوكلاء على السيرفرات وأجهزة الموظفين يذهبون إلى Wazuh، وهو الذي ينفذ الحظر التلقائي على الأجهزة. - منفذ SPAN على السويتش الرئيسي يذهب إلى Security Onion، وهو الذي يرى الطابعات والكاميرات وسيرفر المورد، ويحفظ الحزم والحالات. - لا يوجد وكيل Wazuh على جهاز Security Onion، كما تطلب أفضل ممارساته. - والمشكلة الحقيقية في هذا التصميم ليست تقنية، وإنما أن الفريق الصغير أمام لوحتين، فإذا لم يتفق على من يراجع ماذا ومتى، فسوف تتراكم التنبيهات في إحداهما دون أن يراها أحد. والحل البسيط أن يبدأ اليوم من مكان واحد ثابت، وأن تكون الحالات كلها في Security Onion حتى لو بدأ التنبيه من Wazuh. وإذا كانت الشركة لا تحتاج الالتقاط الكامل وإدارة الحالات الآن، فالتصميم الأبسط هو ما بنيناه في المقالين السابقين: Wazuh على الأجهزة، ومستشعر صغير بـ Suricata وZeek، وتنبيهات Suricata تصل إلى Wazuh عبر `eve.json` كما في [دليل ربط Suricata بـ Wazuh](https://documentation.wazuh.com/current/proof-of-concept-guide/integrate-network-ids-suricata.html?ref=arabroot.io)، فتبقى لوحة واحدة، والعتاد أقل من جيجابايت للمستشعر. ## من أين تبدأ؟ مسار قرار الآن نعود إلى سؤال المدير، والشكل التالي يحوله إلى ثلاثة أسئلة: ![مسار قرار: هل لديك شبكة مكتب أو مركز بيانات تملكه؟ لا يعني Wazuh وحده لسيرفرات في السحابة. نعم ينقلك إلى: هل تحتاج PCAP وإدارة حالات وتدقيق؟ لا يعني Wazuh مع مستشعر صغير بـ Suricata وZeek. نعم ينقلك إلى: هل لديك 32 GB وقرص ووقت لنظام آخر؟ نعم يعني Wazuh للأجهزة وSecurity Onion للشبكة، ولا يعني ابدأ بـ Import للتعلم وخطط للعتاد، وفي الأسفل: إذا كنت ستبيع المراقبة كخدمة فراجع رخصة ELv2](https://arabroot.io/content/images/2026/10/wazuh-vs-security-onion-06-decision.webp) القرار يتغير مع نمو الشبكة والفريق، فراجعه كل سنة والسؤال الأول هو الأهم، وكثير من الفرق تتجاوزه: إذا كانت كل سيرفراتك عند مزود سحابي ولا توجد شبكة مكتب تملكها، فلا يوجد منفذ SPAN تضع عليه Security Onion أصلاً، وأغلب ما تحتاجه هو Wazuh على كل سيرفر، مع سجلات المزود السحابي. وإذا كانت لديك شبكة، فالسؤال الثاني يفصل بين حاجتين: أن ترى ما يحدث على الشبكة، وهذا يكفيه مستشعر صغير، وأن تحقق فيه وتحفظ التحقيق، وهذا ما يقدمه Security Onion. والسؤال الثالث صادق مع الميزانية: المنصة التي لا تملك عتادها ولا وقت إدارتها ستتحول إلى جهاز يعمل ولا ينظر إليه أحد، وهذا أسوأ من عدم وجودها، لأنه يعطيك شعوراً زائفاً بالأمان. وفي شركة الدمام، بفريق من شخصين ومتجر وسيرفرات في غرفة صغيرة وشبكة مكتب فيها أجهزة بلا وكلاء، كانت الإجابة: إبقاء Wazuh على كل الأجهزة، والمستشعر الصغير كما هو، وتجربة Security Onion بعقدة Import على ملفات PCAP من الشبكة لشهر، ووضع جهاز Standalone في ميزانية العام القادم إذا أثبتت التجربة أن الالتقاط الكامل والحالات يستحقان الثمن. ## ثلاث جهات أخرى، ثلاثة قرارات مختلفة شركة الدمام ليست الحالة الوحيدة، والمسار نفسه يعطي إجابات مختلفة لجهات مختلفة، ولنفرض ثلاث جهات بأوصاف للتوضيح فقط: - **شركة ناشئة في الرياض تقدم تطبيقاً على 12 سيرفراً في السحابة:** لا توجد شبكة مكتب تملكها، والموظفون يعملون من حواسيبهم عبر الإنترنت، فلا يوجد مكان لمنفذ SPAN. والقرار هنا Wazuh على كل سيرفر وكل حاسوب للموظفين، مع سجلات مزود السحابة، وكشف الثغرات مفعل لأن التطبيق يعتمد على حزم كثيرة تتحدث باستمرار. وإذا احتاجت رؤية للشبكة فهي في سجلات تدفق الشبكة التي يقدمها المزود، وليست في مستشعر. - **مستشفى بفرعين وألفي جهاز وفريق مراقبة من خمسة أشخاص:** في الشبكة أجهزة طبية لا يمكن أن يثبت عليها شيء، وكاميرات، وأنظمة تحكم بالمبنى، وأي اتصال غريب منها قد يعني حادثة خطيرة، وهناك متطلبات تحقيق وتوثيق لكل حادثة. والقرار هنا الاثنان معاً: Wazuh على السيرفرات وأجهزة الموظفين، وSecurity Onion موزع بمستشعر في كل فرع، وعقد بحث في مركز البيانات، وعقدة استقبال، لأن خمسة أشخاص يستطيعون مراقبة لوحتين بجدول مناوبة واضح، والحزم والحالات تستحق العتاد. - **مزود خدمات أمنية يريد أن يقدم المراقبة لعشرين عميلاً:** السؤال الأول هنا قانوني قبل أن يكون تقنياً، فرخصة ELv2 تقيد تقديم Security Onion كخدمة مدارة، لذلك يبني على Wazuh برخصته GPL، ويضيف مستشعرات Suricata وZeek عند العملاء الذين يحتاجون رؤية الشبكة، ويرسل تنبيهاتها إلى Wazuh، أو يتفاوض على ترخيص مناسب إذا أراد Security Onion تحديداً. ولاحظ أن عدد الأجهزة وحده لا يحدد القرار، وإنما ثلاثة أشياء: هل تملك الشبكة، وكم جهازاً فيها لا يقبل وكيلاً، وكم شخصاً يستطيع أن يراقب ويحقق. ### مسار النمو: لا تبن كل شيء من اليوم الأول القرار ليس ثابتاً، والطريق الطبيعي لأغلب الجهات الصغيرة والمتوسطة يمر بثلاث مراحل، كل مرحلة تبدأ عندما تظهر حاجة حقيقية وليس قبلها. في المرحلة الأولى Wazuh على كل ما يقبل وكيلاً، لأنه أرخص ما يغطي أكبر قدر من الخطر، فهو يكشف التخمين والملفات الدخيلة والثغرات ويحظر تلقائياً. وفي المرحلة الثانية، عندما يسأل أحد عن الأجهزة بلا وكلاء أو يطلب المدقق نظام كشف تسلل، يضاف مستشعر صغير بـ Suricata وZeek على منفذ SPAN، وترسل تنبيهاته إلى Wazuh، فتبقى لوحة واحدة، وتتعلم خلال أشهر كيف تضبط قواعد الشبكة وما حجم الحركة الحقيقي. وفي المرحلة الثالثة، عندما تحتاج الحزم والحالات، أو يصبح ربط الأدوات يدوياً أكثر كلفة من منصة متكاملة، ينتقل المستشعر إلى Security Onion، وقد صار الفريق يعرف متوسط الحركة لحساب القرص، ويعرف القواعد التي ضبطها لنقلها إلى صفحة Detections. وفائدة هذا المسار أن كل مرحلة تنتج المعرفة التي تحتاجها المرحلة التالية، فلا تشتري جهازاً بذاكرة 64 GB قبل أن تعرف هل تحتاج 32، ولا تنتقل إلى منصة كاملة قبل أن يعتاد الفريق على قراءة تنبيهات الشبكة. وفي كل مرحلة احتفظ بملف PCAP لحركة معروفة كما فعلنا في مقال Suricata وZeek، فهو الاختبار الذي يخبرك بعد كل تغيير أن المراقبة ما زالت ترى ما كانت تراه. ## أخطاء شائعة Common Mistakes - **المقارنة كأنهما منتجان متنافسان:** أحدهما للجهاز والآخر للشبكة، والسؤال الصحيح: ما الذي لا أراه اليوم؟ - **تثبيت Security Onion لسيرفرات سحابية:** بلا منفذ SPAN لا يرى المستشعر شيئاً، وWazuh هو الأنسب هنا. - **الاعتماد على الشبكة وحدها والحركة كلها مشفرة:** المستشعر يرى الأسماء والأحجام فقط، فتحتاج سجلات الأجهزة والتطبيقات. - **الاعتماد على الوكلاء وحدهم وفي الشبكة أجهزة بلا وكلاء:** الطابعات والكاميرات وسيرفرات الموردين تبقى خارج النظر. - **تقدير العتاد من الحد الأدنى:** 24 GB لـ Security Onion هو الحد الأدنى المطلق، والوثائق نفسها تنصح بـ 32 GB أو أكثر. - **بناء خدمة مدارة على Security Onion دون قراءة الرخصة:** ELv2 تقيد ذلك صراحة. - **لوحتان بلا مالك:** إذا شغلت المنصتين فحدد من يراجع كل لوحة ومتى، وأين تحفظ الحالات. ## الخلاصة وصلنا لنهاية الموضوع ونهاية هذه السلسلة، وأهم ما فيها: - Wazuh يسأل الجهاز عما حدث داخله، وSecurity Onion يسأل الشبكة عما مر فيها، والمقارنة الصحيحة هي ما الذي لا تراه اليوم. - Wazuh يرى السجلات وسلامة الملفات والثغرات ويحظر تلقائياً، ويحتاج وكيلاً على كل جهاز وسيرفراً متوسطاً، وقسناه بنحو 2.5 GiB لعقدة واحدة. - Security Onion يرى الأجهزة بلا وكلاء ويحفظ الحزم والحالات، ويحتاج جهازاً مخصصاً بذاكرة 32 GB أو أكثر وقرصاً يحدده متوسط الحركة. - من ستة أحداث في السلسلة رأت كل منصة ثلاثة بوضوح، وكانت الثلاثة التي تراها إحداهما هي التي تخمنها الأخرى. - Wazuh برخصة GPL-2.0 بلا ميزات مقفلة، وSecurity Onion برخصة ELv2 التي تقيد الخدمة المدارة، وسعر Pro غير منشور. - الضوابط تحتاج الجهتين: الثغرات والسجلات من Wazuh، وIPS وDNS والحالات من Security Onion، والاحتفاظ 12 شهراً عليك في الحالتين. - ابدأ بما تملك: سيرفرات سحابية تعني Wazuh، وشبكة مكتب تعني Wazuh ومستشعراً صغيراً، والحالات والحزم تعني Security Onion عندما تملك عتاده ووقته. وفي المقالات القادمة في مسار الأمن السيبراني بإذن الله ننتقل من المراقبة إلى أدوات تكملها: مصائد المهاجمين مع T-Pot، ومعلومات التهديدات مع MISP وOpenCTI. وأقرب المقالات إلى هذا الموضوع على الموقع: [![](https://arabroot.io/content/images/2026/10/wazuh-lab-cover-cover.webp)دليلمراقبة السيرفرات مع Wazuh: من السجل Log إلى حظر المهاجمشغلنا Wazuh مع وكيل على سيرفر تجريبي، فكشف تخمين كلمات مرور SSH وحظر المهاجم تلقائياً، ونبه على ملف PHP دخيل خلال ثانية.](https://arabroot.io/articles/%D9%85%D8%B1%D8%A7%D9%82%D8%A8%D8%A9-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D9%85%D8%B9-wazuh-%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D8%AC%D9%84-%D8%A7%D9%84%D9%89-%D8%AD%D8%B8%D8%B1-%D8%A7%D9%84%D9%85%D9%87%D8%A7%D8%AC%D9%85/)[![](https://arabroot.io/content/images/2026/10/suricata-zeek-cover-cover.webp)دليلمراقبة الشبكة واكتشاف التسلل IDS مع Suricata وZeekمختبر حقيقي يقرأ الحركة نفسها بأداتين، فيكشف Suricata الهجمات المعروفة ويكتب Zeek سجلاً لكل اتصال، مع الضبط وفقد الحزم.](https://arabroot.io/articles/%D8%A7%D9%83%D8%AA%D8%B4%D8%A7%D9%81-%D8%A7%D9%84%D8%AA%D8%B3%D9%84%D9%84-%D9%81%D9%8A-%D8%A7%D9%84%D8%B4%D8%A8%D9%83%D8%A9-ids-%D9%85%D8%B9-suricata-%D9%88-zeek/)[![](https://arabroot.io/content/images/2026/10/security-onion-cover-cover.webp)دليلSecurity Onion: منصة متكاملة لمراقبة أمن الشبكةما الذي تجمعه Security Onion فوق Suricata وZeek، وكم تحتاج من العتاد، وكيف تجربها بأمان قبل أن تقرر نقل مراقبتك إليها.](https://arabroot.io/articles/security-onion-%D9%85%D9%86%D8%B5%D8%A9-%D9%85%D8%AA%D9%83%D8%A7%D9%85%D9%84%D8%A9-%D9%84%D9%85%D8%B1%D8%A7%D9%82%D8%A8%D8%A9-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B4%D8%A8%D9%83%D8%A9/)[![](https://arabroot.io/content/images/2026/10/build-siem-cover-cover.webp)دليلكيف يعمل محرك كشف SIEM من الداخل؟كيف يجمع SIEM ملايين السجلات ويوحدها ويطبق قواعد الكشف، مع خط أنابيب Vector وLoki وقاعدة Sigma تطلق فعلاً.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D9%8A%D8%B9%D9%85%D9%84-%D9%85%D8%AD%D8%B1%D9%83-%D9%83%D8%B4%D9%81-siem-%D9%85%D9%86-%D8%A7%D9%84%D8%AF%D8%A7%D8%AE%D9%84/)[![](https://arabroot.io/content/images/2026/10/nca-ecc-cover-cover.webp)دليلالضوابط الأساسية للأمن السيبراني NCA ECC بلغة بسيطةكيف تقرأ الضوابط الأساسية ECC دون أن تضيع في أرقامها، وعلى من تنطبق، وما المطلوب من جهتك فعلاً في كل مكون.](https://arabroot.io/articles/%D8%A7%D9%84%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%84%D8%A7%D8%B3%D8%A7%D8%B3%D9%8A%D8%A9-%D9%84%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-nca-ecc-%D8%A8%D9%84%D8%BA%D8%A9-%D8%A8%D8%B3%D9%8A%D8%B7%D8%A9/)[![](https://arabroot.io/content/images/2026/10/security-oss-alternatives-cover-cover.webp)دليلحلول الأمن التجارية وبدائلها مفتوحة المصدر: متى توفر فعلاً؟لكل فئة من حلول الأمن التجارية الشائعة في السعودية بديل مفتوح المصدر، وهنا تعرف متى يوفر عليك فعلاً ومتى يكون التجاري أفضل.](https://arabroot.io/articles/%D8%AD%D9%84%D9%88%D9%84-%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%AC%D8%A7%D8%B1%D9%8A%D8%A9-%D9%88%D8%A8%D8%AF%D8%A7%D8%A6%D9%84%D9%87%D8%A7-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1/) ## تدريب عملي Practice - ارسم شبكتك على ورقة، وضع علامة على كل جهاز يمكن تثبيت وكيل عليه وكل جهاز لا يمكن، ثم احسب النسبة، فهي تخبرك أي المنصتين تغطي أكثر في بيئتك. - خذ جدول الأحداث الستة في هذا المقال، وأضف إليه ثلاثة أحداث تخشاها في جهتك، ثم املأ عمودي Wazuh وSecurity Onion لكل حدث، وقرر بناءً على الجدول من أين تبدأ. ## سجل التحديثات - أكتوبر 2026: كتابة المقال من قياسات مختبري Wazuh 4.14.9 وSuricata 8.0.7 وZeek 9.0.0 في هذه السلسلة، والوثائق الرسمية لـ Security Onion 3.3.0.