Security Onion: منصة متكاملة لمراقبة أمن الشبكة

في مقال Suricata وZeek وضع فريق تقنية المعلومات في شركة التوزيع الصغيرة في الدمام مستشعراً على الشبكة، وكتب قواعده المحلية، وأرسل التنبيهات إلى Wazuh، ومرت ثلاثة أشهر والأمور تعمل. ثم جاءت ليلة وصل فيها تنبيه من القاعدة التي تراقب ردود السيرفر، يقول إن سيرفراً داخلياً أرسل نصاً يشبه مخرج الأمر id لحساب root، وفي الصباح جلس الشخصان أمام التنبيه وطرحا الأسئلة الطبيعية: ماذا أرسل السيرفر بالضبط في هذا الاتصال؟ هل كان رداً على طلب من الإنترنت أم من جهاز داخلي؟ ماذا حدث قبله وبعده؟ فوجدا الإجابة موزعة على أربع أدوات: التنبيه في Wazuh، والاتصال في conn.log على المستشعر، والطلب في http.log، أما الحزم نفسها فلم تكن موجودة في أي مكان، لأن أحداً لم يفكر في تسجيلها. وفي نهاية اليوم كتبا ما وجداه في ملف نصي، لأنه لا يوجد مكان آخر يحفظ فيه التحقيق، وعندما سأل المدقق بعد شهرين عن هذه الحادثة لم يجد أحد الملف.

وهذه المشكلة بالضبط هي التي بني من أجلها Security Onion: منصة واحدة تجمع Suricata وZeek والتقاط الحزم الكامل وتحليل الملفات وسجلات الأجهزة، وتحفظ كل ذلك في Elasticsearch، وتعطي المحلل واجهة واحدة فيها التنبيهات والبحث والحزم وإدارة الحالات. وفي هذا المقال سوف نتعرف عليها كما يتعرف عليها فريق صغير يفكر في الانتقال إليها: ما الذي فيها، وكيف تعمل من الداخل، وكم تحتاج من العتاد، وكيف تجربها دون أن تلمس شبكة الإنتاج، وما الذي تغيره الرخصة، وما الذي تطلبه منها ضوابط الهيئة الوطنية للأمن السيبراني.

دليلمراقبة الشبكة واكتشاف التسلل IDS مع Suricata وZeekمختبر حقيقي يقرأ الحركة نفسها بأداتين، فيكشف Suricata الهجمات المعروفة ويكتب Zeek سجلاً لكل اتصال، مع الضبط وفقد الحزم.دليلمراقبة السيرفرات مع Wazuh: من السجل Log إلى حظر المهاجمشغلنا Wazuh مع وكيل على سيرفر تجريبي، فكشف تخمين كلمات مرور SSH وحظر المهاجم تلقائياً، ونبه على ملف PHP دخيل خلال ثانية.دليلحلول الأمن التجارية وبدائلها مفتوحة المصدر: متى توفر فعلاً؟لكل فئة من حلول الأمن التجارية الشائعة في السعودية بديل مفتوح المصدر، وهنا تعرف متى يوفر عليك فعلاً ومتى يكون التجاري أفضل.

وسوف نناقش في هذا المقال ما يلي:

• ما هو Security Onion، ولماذا هو توزيعة كاملة وليس أداة تثبتها على سيرفر موجود، ومن أين جاء.
• مكوناته كما في الوثائق الرسمية للإصدار 3، ودور كل مكون، والتقاط الحزم الكامل Full Packet Capture الذي لم يكن في مختبرنا السابق.
• أشكال التثبيت الأربعة، وأنواع العقد Nodes، وطريق السجل من المستشعر إلى البحث، وماذا يحدث إذا توقف المدير.
• تقدير العتاد: المعالج والذاكرة والقرص، وحساب حجم الـ PCAP بالأرقام.
• سير عمل المحلل من التنبيه إلى الحالة Case، وصفحة Detections لضبط القواعد.
• كيف تجربه بأمان على ملفات من شبكتك، ثم الرخصة Elastic License 2.0 والنسخة Pro، وما يرسله المنتج خارج شبكتك.
• التحديث والنسخ الاحتياطي ونهاية الدعم، وضوابط الهيئة الوطنية، والأخطاء الشائعة، وجدول قرار: متى يناسبك ومتى لا يناسبك.

ولأن Security Onion توزيعة تثبت من ملف ISO بحجم 14 GB على جهاز مخصص، وأقل شكل لها يطلب قرصاً بحجم 100 GB، فهذا المقال مكتوب من الوثائق الرسمية للإصدار 3 وملاحظات الإصدار وصفحات المشروع، ولم نشغله في مختبر هذا المقال، فلن تجد فيه مخرجات من تشغيل، وإنما الأرقام والأوامر كما وردت في التوثيق، مع مقارنتها بما قسناه بأنفسنا لـ Suricata وZeek في المقال السابق.

ما هو Security Onion؟ توزيعة وليست أداة

أول ما يجب أن تعرفه عن Security Onion أنه ليس برنامجاً تثبته على سيرفر Linux لديك، وإنما نظام كامل تثبته على جهاز فارغ، والسبب أنه يجمع أكثر من عشرين مكوناً يجب أن تعمل معاً بإصدارات متوافقة وإعداد متناسق، فالفريق الذي يطوره يتحكم في كل شيء من نظام التشغيل إلى آخر سطر في الإعداد. وفي الإصدار 3 يأتي النظام على Oracle Linux 9، وكل المكونات تعمل في Containers، وصفحة Docker تقول إن الـ Docker Images موقعة بمفاتيح GPG ويتحقق منها أمر التحديث قبل استخدامها، والإعداد كله تديره أداة Salt. وتقول صفحة التثبيت عبر الشبكة إن الـ ISO والصور السحابية الرسمية هي طريقة التثبيت الوحيدة المدعومة، وإن التثبيت فوق Oracle Linux موجود ولكنه حل أخير لا يدعمه المشروع.

وهذا التصميم له نتيجة عملية تذكرها صفحة أفضل الممارسات صراحة: عامل Security Onion كجهاز Appliance، ولا تثبت عليه برامج من طرف ثالث، ولا أدوات أتمتة مثل Puppet وChef لأنها تتعارض مع Salt، ولا أدوات مراقبة مثل Zabbix، ولا وكلاء أمن الأجهزة من طرف ثالث. وهذه النقطة تهم شركة الدمام مباشرة، فقد اعتاد الفريق أن يثبت وكيل Wazuh على كل سيرفر، وهنا عليه أن يستثني جهاز Security Onion نفسه، وأن يراقبه من داخله بأدوات المنصة.

والقصة طويلة، فبحسب صفحة الشركة بدأ Doug Burks العمل على Security Onion سنة 2008 كتوزيعة Linux لكشف التسلل ومراقبة أمن الشبكة وإدارة السجلات، وصدر أول إصدار في 2009، ثم تأسست شركة Security Onion Solutions في 2014، وصدر Security Onion 2 في 2020، ثم النسخة التجارية Pro في 2024، ومساعد الذكاء الاصطناعي في 2025، ثم Security Onion 3 في 2026. وآخر إصدار عند كتابة المقال هو 3.3.0-20260911 بتاريخ 11 سبتمبر 2026، وهو إصدار تصحيحي سريع Hotfix بعد الإصدار 3.3.0 في 8 سبتمبر، وقبلهما 3.2.0 في يوليو و3.1.0 في مايو، فالمشروع يصدر نسخة رئيسية كل شهرين تقريباً.

ما الذي يجمعه في مكان واحد؟

تقسم صفحة المقدمة المنصة إلى رؤية الشبكة Network Visibility، ورؤية الأجهزة Host Visibility، وأدوات التحليل Analysis Tools، والشكل التالي يجمعها:

ولنمر على كل جزء ونربطه بما بنيناه في المقال السابق:

• كشف التسلل NIDS بـ Suricata: نفس المحرك الذي جربناه، بقواعد ET Open افتراضياً، مع إمكانية إضافة مصادر قواعد أخرى من الواجهة كما تشرح صفحة NIDS، التي تحيل إلى قائمة مصادر القواعد التي تصونها OISF. والفرق أن المزامنة اليومية للقواعد ونشرها على كل المستشعرات يحدث وحده، بدلاً من مهمة مجدولة لـ suricata-update على كل جهاز.
• سجلات البروتوكولات Network Metadata: بـ Zeek أو بـ Suricata نفسه، وأنت تختار. وهذا خيار مهم، فالتوثيق يقول إن Suricata يستطيع كتابة سجلات البروتوكولات أيضاً، كما رأينا في أحداث http وdns وflow داخل eve.json، وإن الاعتماد عليه وحده يوفر المعالج على الشبكات الكبيرة، والثمن أنك تخسر لغة سكربتات Zeek وسجلات مثل software.log.
• التقاط الحزم الكامل Full Packet Capture: يكتبه Suricata على القرص كملفات PCAP عادية، وهو الجزء الذي كان ينقص شركة الدمام في تلك الليلة، وسوف نفرد له قسماً.
• تحليل الملفات File Analysis: يستخرج Zeek وSuricata الملفات التي تمر في الحركة، ثم يحللها Strelka ويضيف إليها معلومات، ويطبق عليها قواعد YARA.
• رؤية الأجهزة: عبر Elastic Agent بإدارة مركزية من Elastic Fleet، ومعه Osquery للاستعلام الحي عن الأجهزة، كما في صفحة Elastic Agent، وللأجهزة التي لا تقبل وكيلاً مثل الجدران النارية والراوترات يستقبل Syslog.
• مصائد الكشف Intrusion Detection Honeypot: عقدة اختيارية تقلد خدمات مثل HTTP وFTP وSSH عبر OpenCanary، وأي اتصال بها يطلق تنبيهاً، والفكرة كما تشرحها صفحة IDH أن الجهاز الذي لا يستخدمه أحد لا يجب أن يتصل به أحد، فأي اتصال به علامة على شخص يستكشف الشبكة من الداخل، وتؤكد الصفحة أن هذه العقدة توضع داخل الشبكة ولا تكون مكشوفة على الإنترنت. وسوف نتعمق في المصائد في مقال T-Pot القادم في المسار.
• التخزين والبحث: Logstash وRedis للاستقبال والطابور، ثم Elasticsearch للفهرسة والتخزين، وElastAlert الذي يشغل قواعد Sigma على السجلات المفهرسة، وهي نفس فكرة قواعد Sigma التي شرحناها في محرك كشف SIEM من الداخل.
• واجهة المحلل Security Onion Console: واختصاراً SOC، وفيها صفحات التنبيهات واللوحات والبحث والحالات والحزم والقواعد وحالة العقد، ومعها CyberChef لفك الترميز وKibana للاستعلامات الحرة.

ولاحظ شيئاً صغيراً له دلالة كبيرة: ملاحظات الإصدار تقول إن 3.3.0 حدث Zeek إلى 8.0.10، وإن 3.2.0 حدث Suricata إلى 8.0.6، بينما جربنا في المقال السابق Zeek 9.0.0 وSuricata 8.0.7. أي أن المنصة تتأخر قليلاً عن أحدث إصدار من كل مكون، لأن الفريق يختبر المكونات معاً قبل أن ينشرها، وهذا هو الثمن الطبيعي لأي منصة متكاملة: تحصل على مكونات مختبرة معاً، وتتنازل عن أحدث ميزة في كل مكون حتى يصل دورها.

التقاط الحزم الكامل PCAP: الكاميرا التي لم تكن موجودة

تصف صفحة المقدمة التقاط الحزم الكامل بأنه مثل كاميرا فيديو للشبكة، بل أفضل، لأنه لا يقول فقط من دخل ومن خرج، وإنما إلى أين ذهب وماذا أخذ معه، وتقول إن الأدلة على الجهاز المخترق قد تحذف أو تعدل، أما الكاميرا فلا تكذب. ولنعد إلى ليلة شركة الدمام: التنبيه قال إن السيرفر أرسل نصاً يشبه مخرج id، وسجل Zeek قال إن الاتصال انتهى طبيعياً وكم بايت مر فيه، ولكن السؤال الحقيقي هو ما الذي أرسله السيرفر بعد ذلك النص، هل كان صفحة ثابتة كما في مختبرنا، أم مخرج أوامر نفذها مهاجم على السيرفر؟ وهذا سؤال لا يجيب عنه إلا محتوى الحزم نفسها.

وفي Security Onion يكتب Suricata كل الحركة التي يراها إلى ملفات PCAP على المستشعر، كما في صفحة التقاط الحزم الكامل، وتصل إليها من أي تنبيه أو سجل بخيار PCAP في القائمة، فتفتح صفحة PCAP الاتصال كاملاً كقائمة حزم، وتستطيع أن تعرضه كنص متصل ASCII Transcript، أو ترسله إلى CyberChef، أو تنزل ملف PCAP لتفتحه في Wireshark. وتنصح الوثائق نفسها بألا تحلل ملفات PCAP المشبوهة على حاسوبك العادي، وإنما في بيئة منفصلة مثل Security Onion Desktop، لأن الملف قد يحتوي على برمجية خبيثة كاملة.

والثمن هو القرص، وسوف نحسبه بعد قليل، ولذلك توفر الإعدادات ثلاثة خيارات للالتقاط الشرطي Conditional PCAP: all لكل الحزم وهو الافتراضي، وalerts لحزم الاتصالات التي أطلقت تنبيهاً فقط، وtag للحزم التي تحددها قاعدة موسومة. ومعها maxsize وهو الحد الأقصى لحجم كل ملفات PCAP، وcompression لضغطها بـ lz4 مقابل استهلاك أكبر للمعالج. والقرار هنا ليس تقنياً فقط: الالتقاط الكامل يعطيك القدرة على التحقيق في هجوم لم تكتشفه أي قاعدة وقت حدوثه، والالتقاط الشرطي يوفر القرص ولكنه يعيدك إلى الاعتماد على القواعد، وهي بالضبط المشكلة التي رأيناها عندما فاتت قواعد ET Open أغلب طلبات مختبرنا.

أشكال التثبيت: من ملف على حاسوبك إلى شبكة عقد Grid

يسأل برنامج الإعداد Setup في أول تشغيل عن نوع التثبيت، والاختيار يحدد كل شيء بعده، والشكل التالي يلخص الأشكال الأربعة الأساسية والحد الأدنى لكل منها من صفحة العتاد:

وتفصيل كل شكل كما تشرحه صفحة البنية:

• Import: أبسط شكل، جهاز واحد يشغل أقل ما يكفي لاستيراد ملفات PCAP وملفات سجلات Windows EVTX وعرض نتائجها، ولا يلتقط حركة حية، ولا يقبل وكلاء ولا عقداً أخرى. وهو المكان الصحيح لتتعلم المنصة على حركة تعرفها.
• Evaluation: مثل Import ولكن بكرت شبكة مخصص للالتقاط من منفذ SPAN أو جهاز TAP، ولا يشغل Logstash ولا Redis لتوفير الذاكرة، فيرسل Elastic Agent السجلات مباشرة إلى Elasticsearch. والوثائق تقول بوضوح إنه للتجربة المؤقتة أو المختبر المنزلي، وليس للإنتاج.
• Standalone: كل المكونات في جهاز واحد، مع Logstash وRedis، وهو مناسب للتجارب ونماذج الإثبات POC والبيئات قليلة الحركة، والحد الأدنى 24 GB من الذاكرة مع احتمال الحاجة إلى Swap، والوثائق تنصح بـ 32 GB أو أكثر إذا كنت ستراقب أي حركة حقيقية.
• Distributed: مدير Manager، وعقدة بحث Search Node أو أكثر، ومستشعر Sensor أو أكثر، وهو الشكل الموصى به للإنتاج، لأنك تضيف عقداً كلما زادت الحركة أو السجلات.

وداخل الشكل الموزع توجد أنواع أخرى من العقد، ومنها عقدة المدير مع البحث Manager Search التي تجمع الدورين عندما لا تملك أجهزة كافية، وعقدة الاستقبال Receiver التي سوف نرى دورها في القسم التالي، وعقدة Fleet لإدارة أعداد كبيرة من الوكلاء، وعقدة IDH للمصائد، وعقدة سطح المكتب Desktop التي تعطي المحلل متصفحاً وأدوات مثل Wireshark وNetworkMiner في بيئة منفصلة. أما العقدة الثقيلة Heavy Node، أي مستشعر يحمل Elasticsearch الخاص به، فالوثائق تقول إنها غير موصى بها لأغلب المستخدمين بسبب الأداء، وإنها للتجربة أو البيئات قليلة الحركة فقط.

وبالنسبة لشركة الدمام، بخط إنترنت متوسط وفريق من شخصين وموقع واحد، فالخيار الواقعي هو Standalone على جهاز واحد قوي، أو Manager Search مع مستشعر منفصل إذا أرادوا أن يبقى المستشعر قرب السويتش والتخزين في غرفة السيرفرات. والشكل الموزع الكامل بمدير وعقد بحث منفصلة يصبح منطقياً عندما تكبر الحركة أو يتعدد المواقع.

طريق السجل من المستشعر إلى البحث

في الشكل الموزع لا يذهب السجل من المستشعر إلى Elasticsearch مباشرة، وإنما يمر بطابور Queue، والسبب أن الفهرسة عمل ثقيل قد يتأخر، والطابور يمتص الذروة فلا تضيع السجلات عندما تبطئ عقد البحث، وهذه نفس فكرة الطوابير التي شرحناها في تصميم الأنظمة. والشكل التالي يبين الطريق كما في صفحة البنية:

وفي الشكل أعلاه لاحظ التالي:

• ملفات PCAP لا تنتقل إلى المدير، وإنما تبقى على المستشعر، ويجلب المدير الجزء المطلوب منها عند الطلب فقط، والسبب حجمها، فلو نقلت كل الحزم إلى المدير لتضاعف حمل الشبكة. وهذا يعني أن قرص المستشعر هو الذي يحدد كم يوماً من الحزم تحتفظ به.
• عقد البحث هي التي تسحب من طابور Redis على المدير، ثم تحلل وتفهرس، والمدير عندما يسأله المحلل يوزع السؤال على عقد البحث ويجمع النتائج. والتوثيق ينبه إلى أن المدير المخصص يحتاج عقدة بحث واحدة على الأقل، وإلا تراكمت السجلات في الطابور دون مكان تذهب إليه.
• ماذا يحدث إذا توقف المدير؟ تقول صفحة البنية إنه بدون عقدة استقبال Receiver تتوقف عقد البحث عن الفهرسة لأنها لا تصل إلى Redis، ولا يستطيع الوكلاء الوصول إلى Logstash، فيتراكم الطابور على الوكلاء أنفسهم حتى يعود المدير. ومع عقدة Receiver فيها Logstash وRedis يتحول الوكلاء إليها، وتسحب عقد البحث منها، وتعمل عقد الاستقبال كلها في وقت واحد Active-Active.
• وتنبه الوثائق إلى أن عقدة الاستقبال يجب أن تكون قريبة من عقد البحث، فوضعها في موقع بعيد لا يوفر Bandwidth، لأن كل عقد البحث سوف تسحب من طابورها عبر الشبكة البعيدة.

كم يحتاج من العتاد؟

هذا السؤال هو الذي يحسم القرار في أغلب الجهات الصغيرة، والشكل التالي يجمع قواعد التقدير من صفحة العتاد مع مثال محسوب بالطريقة نفسها:

وتفصيل القواعد كما يلي:

• المعالج CPU: تعطي الوثائق تقديراً تقريبياً جداً، وهو نحو 200 ميجابت في الثانية لكل Worker من Suricata أو Zeek، فخط 1 Gbps ممتلئ يحتاج خمسة Workers لكل منهما، أي عشر أنوية على الأقل للأداتين فقط، فوقها أنوية لالتقاط الحزم والخدمات الأخرى. وإذا كانت الأنوية قليلة والحركة كبيرة تقترح الوثائق استخدام Suricata للتنبيهات والسجلات معاً والاستغناء عن Zeek.
• الذاكرة RAM: للمستشعر الذي يشغل Suricata مع الالتقاط الكامل وZeek، تقترح الوثائق 16 GB أو أكثر لشبكة إنتاج صغيرة حتى 100 Mbps، ومن 16 إلى 128 GB للشبكة المتوسطة حتى 1 Gbps، ومن 128 إلى 256 GB للكبيرة حتى 10 Gbps، وتنصح بزيادة الذاكرة حتى تستطيع إيقاف الـ Swap تماماً. وقارن هذا بما قسناه في المختبر، 465 MiB لـ Suricata و97 MiB لـ Zeek، فالفرق هو Elasticsearch وLogstash والواجهة والالتقاط الكامل، وكلها تعيش على نفس الجهاز في Standalone.
• القرص Disk: التخزين المحلي فقط، فالوثائق لا تدعم SAN أو NFS أو iSCSI، وتنصح بأقراص SSD أو أقراص سريعة بـ RAID 10 لبيانات Elasticsearch، وتقترح ألا تحتفظ بأكثر من 30 يوماً من الفهارس الساخنة Hot Indices. والـ Docker Images وحدها تأخذ 30 GB، وتنصح صفحة التثبيت عبر الشبكة بمساحة لنسخة ثانية منها من أجل التحديث.
• المعمارية: x86-64 فقط، ولا يدعم ARM. وتذكر ملاحظات الإصدار مشكلة معروفة حديثة: تغيير من Elastic يتطلب دعم المعالج لمستوى x86-64-v3، فإذا كنت تشغل المنصة في جهاز افتراضي على Proxmox فاضبط نوع المعالج على host، وإذا كانت معالجاتك قديمة لا تدعم هذا المستوى أصلاً فالتوصية أن تؤجل التحديث. وهذه نقطة يجب أن تتحقق منها قبل أن تشتري أو تعيد استخدام سيرفر قديم، وقد شرحنا أنواع المعالج في أول VM في Proxmox.
• كروت الشبكة: كرت للإدارة بعنوان ثابت، وكرت أو أكثر للالتقاط بلا عنوان IP، والإعداد يوقف تلقائياً تقنيات الـ Offloading مثل TSO وGSO وGRO على كروت الالتقاط حتى ترى الأداتان الحركة كما هي، وهذه بالضبط مشكلة الـ Checksum التي أخفت هجوم Shellshock في مختبرنا السابق، وهنا يحلها الإعداد بنفسه. وتنصح الوثائق بكروت جيدة، وتذكر أن أغلب المستخدمين يرون نتائج جيدة مع كروت Intel، وأن الكروت اللاسلكية غير مدعومة.

حساب القرص للـ PCAP بالأرقام

تعطي صفحة العتاد مثالاً كاملاً لخط متوسطه 50 ميجابت في الثانية: 50 Mb/s تساوي 6.25 MB/s، أي 375 MB في الدقيقة، و22,500 MB في الساعة، و540,000 MB في اليوم، أي نحو 540 GB من الحزم لكل يوم تحتفظ به. ولنطبق الطريقة نفسها على شركة الدمام بافتراض للتوضيح فقط، وهو أن متوسط الحركة على النقاط المراقبة 20 ميجابت في الثانية على مدار اليوم:

وفي الأرقام أعلاه لاحظ التالي:

• المتوسط هو المهم وليس سرعة الخط، فخط 1 Gbps متوسطه 20 ميجابت يحتاج قرصاً لـ 20 ميجابت، والوثائق تذكر ذلك صراحة عندما تقول إنك قد تراقب خط 1 Gbps لا يستخدم منه إلا 200 Mbps أغلب الوقت. لذلك قس المتوسط الحقيقي أسبوعاً من الـ Switch أو الـ Firewall قبل أن تحسب.
• الحزم لا تحفظ عادة مدة طويلة، فالهدف منها التحقيق في الأيام القريبة، أما الدليل طويل المدى فهو السجلات المختصرة، ولذلك يكفي أغلب الجهات الصغيرة أسبوع إلى أسبوعين من الحزم، ثم يحذف maxsize الأقدم.
• الحساب هنا للحزم فقط، وفوقه قرص Elasticsearch للسجلات والتنبيهات، وفوقه 30 GB للـ Docker Images ومثلها للتحديث.

من التنبيه إلى الحالة Case: كيف يعمل المحلل؟

الآن نعود إلى التنبيه الذي أيقظ فريق الدمام، ونمر عليه بسير العمل الذي تقترحه صفحة المقدمة نفسها، والشكل التالي يبين الخطوات:

1. Alerts: تعرض صفحة التنبيهات التنبيهات مجمعة، ولكل تنبيه أيقونتان مهمتان: الجرس للتأكيد Acknowledge، أي أن المحلل رآه وقرر أنه لا يحتاج عملاً، وعلامة التعجب للتصعيد Escalate إلى حالة جديدة أو موجودة. وهذا الفرق الصغير يحل مشكلة كبيرة في فريق من شخصين: لا يعيد أحدهما فحص ما فحصه الآخر، وتعرف في أي لحظة ما الذي لم يره أحد بعد.
2. Detections: إذا كان التنبيه ضجيجاً، فبدلاً من ملفات threshold.config وdisable.conf على كل مستشعر، تدير صفحة Detections كل القواعد من مكان واحد: قواعد NIDS التي تحمل في Suricata، وقواعد Sigma التي تحمل في ElastAlert، وقواعد YARA التي تحمل في Strelka، مع حالة كل محرك ونتيجة آخر مزامنة، وخيار مزامنة جزئية سريعة أو كاملة.
3. Dashboards وHunt: ما كنا نفعله بـ grep وzeek-cut على ملفات متفرقة أصبح استعلاماً واحداً على كل السجلات: ماذا فعل هذا العنوان اليوم في DNS وHTTP وTLS، وبمن اتصل، ثم توسيع البحث في Hunt بالمؤشرات Observables مثل العنوان أو الهاش أو اسم النطاق.
4. PCAP: الحزم الكاملة للاتصال نفسه، وهنا يجد الفريق الجواب على سؤال تلك الليلة: ماذا أرسل السيرفر بعد النص المشبوه.
5. CyberChef: لفك ما يجده في الطلب أو الرد، مثل نص مرمز بـ Base64 أو رابط مرمز URL Encoding.
6. Cases: تشرح صفحة الحالات أنها تجمع التنبيهات والسجلات المصعدة، وتسمح بتعيين محلل، وإضافة تعليقات ومرفقات، وتتبع المؤشرات، وفي النسخة Pro يسجل المحلل أيضاً عدد الساعات التي قضاها في كل نشاط. وهذا هو الملف الذي لم يجده المدقق في قصتنا: مكان واحد فيه الحادثة كاملة، بتواريخها وأدلتها وقرارها.

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

كيف تجربه دون أن تلمس شبكة الإنتاج؟

الخطأ الشائع أن يبدأ الفريق بتثبيت Standalone على منفذ SPAN في الشبكة الحقيقية، ثم يقضي أسبوعاً في حل مشكلات الذاكرة والقرص قبل أن يرى أي قيمة. والطريقة التي يقترحها المشروع نفسه في دليل المستخدمين الجدد أبسط: ابدأ بـ Import على جهاز افتراضي بمعالجين و4 GB ذاكرة و100 GB قرص، واستورد ملفات PCAP، وتعلم الواجهة على حركة تعرفها. وهنا يأتي الملف الذي بنيناه في المقال السابق، فهو حركة نعرف كل طلب فيها، وما رأته Suricata وZeek فيها، فإذا استوردته في Security Onion ستعرف فوراً هل ترى ما تتوقعه.

والخطوات بالترتيب:

1. نزل الـ ISO من صفحة التنزيل والتحقق، وتحقق من توقيعه قبل الإقلاع منه، وهذه الأوامر كما وردت في الصفحة للإصدار الحالي:

wget https://raw.githubusercontent.com/Security-Onion-Solutions/securityonion/3/main/KEYS -O - | gpg --import -
wget https://github.com/Security-Onion-Solutions/securityonion/raw/3/main/sigs/securityonion-3.3.0-20260911.iso.sig
wget https://download.securityonion.net/file/securityonion/securityonion-3.3.0-20260911.iso
gpg --verify securityonion-3.3.0-20260911.iso.sig securityonion-3.3.0-20260911.iso

والتحقق ليس شكلياً هنا، فأنت تثبت نظاماً سوف يرى كل حركة شبكتك، ونسخة معدلة منه هي أخطر ما يمكن أن تضعه في الشبكة. وتنبه صفحة التنزيل أيضاً إلى أن برامج مكافحة الفيروسات قد تنبه على الـ ISO، والسبب في الغالب ملفات قواعد كشف داخله تحتوي على أنماط برمجيات خبيثة، وليست برمجيات خبيثة.

2. أقلع الجهاز الافتراضي من الـ ISO، وأنشئ المستخدم، ثم يبدأ Setup وحده بعد إعادة التشغيل، فاختر التثبيت القياسي، ثم IMPORT، ثم وافق على الرخصة، وحدد اسم الجهاز. وانتبه هنا لتحذير صفحة التثبيت: الإعداد ينشئ الشهادات من اسم الجهاز، ولا يدعم المشروع تغيير الاسم بعد الإعداد، فاختره صحيحاً من المرة الأولى.
3. بعد الإعداد افتح الواجهة، وتأكد من صفحة Grid أن كل الخدمات تعمل، ثم ارفع ملف PCAP من زر الرفع أسفل الصفحة نفسها، وسوف تظهر رسالة فيها رابط إلى Dashboards بكل التنبيهات والسجلات من الملف.

وإذا أردت الاستيراد من سطر الأوامر، فتشرح صفحة so-import-pcap الأمر الذي يشغل Suricata وZeek على الملف ويحفظ النتائج في Elasticsearch بأوقاتها الأصلية:

sudo so-import-pcap /full/path/to/import.pcap

وفي هذا الأمر لاحظ نقطتين من التوثيق: أنه يحفظ النتائج بأوقات الحزم الأصلية وليس بوقت الاستيراد، لذلك إذا لم تر شيئاً في صفحة التنبيهات فغير الفترة الزمنية لتشمل تاريخ الملف، وأنه يحسب هاش MD5 للملف وينشئ له مجلداً في /nsm/import/، فإذا استوردت الملف نفسه مرة ثانية سيرفض، وعليك أن تحذف مجلده أولاً.

وماذا تقيس في هذه التجربة؟ خذ جدول الحركة من المقال السابق، وتأكد أن كل طلب ظهر كما توقعت، وأن تنبيهات ET Open الجاهزة هي نفسها، ثم أضف قواعدك المحلية الخمس من صفحة Detections وأعد الاستيراد، وتأكد من التنبيهات السبعة. وبعد أسبوع من التعلم على ملفات من شبكتك، تقرر الشكل الذي تحتاجه للإنتاج وعتاده، وأنت تعرف ما الذي تشتريه.

الرخصة Elastic License 2.0: ماذا تعني لك؟

تقول صفحة الرخصة إن أغلب البرامج داخل Security Onion برخص مفتوحة المصدر، ولكن مكونات Elastic ومكونات Security Onion نفسها برخصة Elastic License 2.0، واختصاراً ELv2، ويطلب الإعداد موافقتك عليها، وقد أعلن المشروع هذا التغيير في تدوينة أغسطس 2022. وELv2 ليست رخصة مفتوحة المصدر بالتعريف المعروف، وإنما رخصة متاحة المصدر Source Available، ونصها الكامل في صفحة Elastic، وأهم قيودها ثلاثة:

• لا يجوز أن تقدم البرنامج لطرف ثالث كخدمة مستضافة أو مدارة Managed Service تعطيه الوصول إلى مجموعة جوهرية من ميزاته.
• لا يجوز أن تنقل أو تعطل أو تتحايل على وظائف مفتاح الترخيص License Key.
• لا يجوز أن تزيل إشعارات الترخيص أو حقوق النشر.

وبالنسبة لشركة الدمام التي تستخدم المنصة لمراقبة شبكتها، فهذه القيود لا تمسها، فهي تستخدم البرنامج داخلياً. ولكن إذا كنت مزود خدمات أمنية Managed Security Service Provider تريد أن تبني خدمة مراقبة لعملائك فوق Security Onion، فاقرأ القيد الأول بعناية مع مستشارك القانوني قبل أن تبدأ، لأن الخدمة المدارة هي بالضبط ما يقيده. وهذا من أهم الفروق مع Wazuh برخصة GPL-2.0، وسوف نعود إليه في المقال القادم عند المقارنة.

النسخة المجتمعية Community والنسخة Pro

كل ما شرحناه حتى الآن في النسخة المجتمعية المجانية، بما فيه الالتقاط الكامل والحالات والقواعد والتوزيع على عقد متعددة والمصائد. أما النسخة Pro فتضيف ميزات تحتاجها المؤسسات المتوسطة والكبيرة والجهات الحكومية، ومنها بحسب صفحتها وصفحات التوثيق:

• الدخول الموحد عبر OpenID Connect، فيدخل المحللون بحسابات Active Directory أو مزود الهوية الذي تستخدمه، وقد شرحنا البروتوكول في مرحلة الهوية.
• الإشعارات الصادرة بالبريد وSlack وغيرها، وهي غير مفعلة في النسخة المجتمعية.
• الحماية المتوافقة مع STIG لمشكلات النظام من الفئة الأولى، وFIPS، وتشفير التخزين بـ LUKS.
• التوصيل المضمون للرسائل Guaranteed Message Delivery عبر Kafka، كما تذكر صفحة Kafka.
• المساعد Onion AI، وسوف نتكلم عنه في القسم التالي.
• دعم فني بمهلة استجابة يوم عمل، أو أربع ساعات عمل، وساعات خدمات مهنية، وفحصان صحيان سنوياً.

والرخصة القياسية تغطي حتى عشر عقد مع حزم إضافية للشراء، وهناك رخص للشبكات الأصغر مثل عقدة Standalone واحدة، وبعض أجهزة الشركة الكبيرة تأتي معها رخصة عقدة واحدة. ولم نجد سعر النسخة Pro منشوراً في صفحتها عند مراجعتها في أكتوبر 2026، فهو بالتواصل مع الشركة، وكذلك أسعار الأجهزة الجاهزة Appliances.

ماذا يخرج من شبكتك؟ القياس عن بعد Telemetry والذكاء الاصطناعي

منصة ترى كل حركة شبكتك يجب أن تعرف بالضبط ماذا ترسل هي إلى الخارج، وفي Security Onion نقطتان تستحقان الانتباه، وخاصة إذا كانت جهتك ملزمة ببقاء بياناتها داخل المملكة أو بنظام حماية البيانات الشخصية كما شرحنا في حماية البيانات الشخصية PDPL للخدمات المستضافة:

• القياس عن بعد من الواجهة: تقول صفحة Telemetry إن واجهة SOC تستطيع إرسال بيانات استخدام إلى Google Analytics لتساعد الفريق في معرفة الميزات المستخدمة، وإن الإعداد والتحديث اليدوي يطلبان منك أن تختار تفعيلها أو تعطيلها، وتستطيع تغييرها لاحقاً من الإعدادات. والقرار المحافظ في جهة حكومية أو مالية أن تعطلها.
• المساعد Onion AI: ميزة في Pro معطلة افتراضياً، وتشرح صفحتها أنها تتصل بنماذج لغة عبر محولات Adapters: الافتراضي SOAI يمر عبر بوابة الشركة المستضافة في السحابة باستهلاك أرصدة Credits من الرخصة، ومحول Gemini يستخدم سحابة Google بمفتاحك، ومحولان متوافقان مع OpenAI يسمحان بالاتصال بنموذج تستضيفه بنفسك، وتشرح صفحة الاستضافة المحلية مثالاً على جهاز بذاكرة 128 GB، وتقول بصراحة إن النموذج المحلي لن يصل إلى دقة النماذج التجارية. والسؤال الذي يجب أن تسأله قبل التفعيل: ما الذي سوف يرسل إلى النموذج؟ فالمساعد يعمل على تنبيهاتك وسجلاتك، وإذا كان النموذج في سحابة خارجية فهذه البيانات تخرج من شبكتك، وقد شرحنا تشغيل النماذج محلياً في مرحلة الذكاء الاصطناعي المحلي.

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

التشغيل اليومي: التحديث والنسخ الاحتياطي

المنصة المتكاملة تريحك من ربط الأدوات، ولكنها تضيف نظاماً كاملاً يجب أن تديره، وهذه أهم نقاط التشغيل من التوثيق.

التحديث Upgrade بالأمر soup

التحديث في Security Onion أمر واحد، واسمه soup اختصاراً لـ Security Onion UPdater:

sudo soup

ويحدث نفسه أولاً ثم يطلب تشغيله مرة ثانية، ثم يبحث عن إصدار جديد أو إصلاح سريع Hotfix أو تحديثات لنظام التشغيل. والإصدار الجديد يحدث كود Salt وكل الـ Docker Images، ويحتفظ بالنسخ السابقة من الـ Images حتى التحديث التالي. وفي الصفحة ثلاثة تحذيرات عملية:

• إذا شغلت soup عبر SSH وانقطعت الجلسة توقف التحديث في منتصفه، لذلك شغله داخل tmux أو screen، ولا تتركه دون متابعة من حاسوب قد ينام.
• جرب التحديث على نشر تجريبي قبل الإنتاج إذا استطعت، وهنا تفيدك عقدة Import التي جربت عليها.
• بعد التحديث أو إعادة التشغيل قد تحتاج الخدمات دقائق لتظهر سليمة في صفحة Grid، وإذا لم تظهر خلال 15 دقيقة تقترح الصفحة الأمر sudo so-checkin.

وتذكر الصفحة أن حذف الـ Images القديمة فوراً ممكن بأمر docker system prune -a، وتصفه بأنه خيار عنيف يجب الحذر معه، فلا تشغله قبل أن تتأكد أن التحديث نجح وأن كل شيء يعمل.

النسخ الاحتياطي Backup: ما الذي لا يحفظ وحده؟

تقول صفحة النسخ الاحتياطي إن المنصة تأخذ يومياً نسخة من ملفات الإعداد الحرجة في ملف tar داخل /nsm/backup/ على المدير، وفيها الشهادات و/etc/salt/ والتعديلات التي أجريتها من صفحة الإعدادات، وتنصح بنسخ هذا المجلد إلى خارج المدير. وقاعدة PostgreSQL تنسخ يومياً أيضاً. ولكن الجملة الأهم في الصفحة هي أن بيانات Elasticsearch لا تنسخ تلقائياً، وهذا يشمل تخصيصات Kibana وبيانات الحالات Cases في الفهارس so-case وso-casehistory. أي أن ملف التحقيق الذي كان ينقص شركة الدمام، إذا لم تأخذ له نسخة احتياطية، يمكن أن يضيع مع قرص واحد. والحل الذي تقترحه الصفحة هو النسخ المكررة Replicas إذا كان لديك أكثر من عقدة بحث، مع أنها تضاعف القرص، أو اللقطات Snapshots المدمجة في Elasticsearch بعد ضبط path.repo، وقد شرحنا فكرة اللقطات والاستعادة في محركات البحث في OpenSearch البديل المفتوح لـ Elasticsearch.

مدة الاحتفاظ Retention

تشرح صفحة Elasticsearch أن الإصدار 3.2.0 أضاف إدارة دورة حياة تيارات البيانات Data Stream Lifecycle Management، وأن التثبيتات الجديدة تستخدمها افتراضياً بمدة احتفاظ 90 يوماً، بينما تبقى التثبيتات القديمة على Index Lifecycle Management، التي تسمح بنقل البيانات بين طبقات تخزين ساخنة ودافئة وباردة. وهذا الرقم 90 يوماً هو الذي يجب أن تضعه بجانب متطلبات جهتك في القسم التالي.

ماذا تكسب مقارنة بالمختبر اليدوي، وماذا تدفع؟

قبل أن نصل إلى الضوابط، نضع ما بنيناه بأيدينا في المقال السابق بجانب ما يقابله في المنصة، لأن هذا هو القرار الذي يواجهه أي فريق صغير:

ونقاط القوة ونقاط الضعف كما نراها بعد هذه المقارنة:

• نقاط القوة: كل أدوات مراقبة الشبكة مختبرة معاً ومحدثة بأمر واحد، والتقاط كامل للحزم مع واجهة، وإدارة حالات تحفظ التحقيق، وإعداد يتجنب أخطاء مثل الـ Offloading وحده، وواجهة واحدة للتنبيهات والسجلات والحزم، ونسخة مجتمعية مجانية لا تخفي الميزات الأساسية، ومشروع نشط بإصدارات كل شهرين.
• نقاط الضعف: عتاد أكبر بكثير، فالحد الأدنى للإنتاج على جهاز واحد 24 GB والنصيحة 32 GB أو أكثر، ونظام كامل يجب أن تعامله كجهاز مستقل فلا تضع عليه أدواتك المعتادة، ورخصة ELv2 تقيد تقديمه كخدمة مدارة، وتأخر قليل عن أحدث إصدارات المكونات، وبيانات الحالات لا تنسخ وحدها، ومنحنى تعلم لواجهة جديدة وElasticsearch.

ماذا تطلب ضوابط الهيئة الوطنية للأمن السيبراني؟

إذا كانت جهتك ملزمة بالضوابط الأساسية للأمن السيبراني ECC 2:2024، فهذه الضوابط التي تمسها المنصة، وقد راجعنا أرقامها ونصوصها في وثيقة الضوابط الرسمية، وشرحنا الضوابط نفسها في الضوابط الأساسية بلغة بسيطة:

والنقطة التي تستحق التكرار هي سطر الاحتفاظ، فالمدقق سوف يسأل عن 12 شهراً، والإعداد الافتراضي 90 يوماً، ولو رفعت المدة دون أن تحسب القرص فسوف يمتلئ قرص Elasticsearch في منتصف السنة ويتوقف عن قبول السجلات، وهذا أسوأ من مدة احتفاظ أقصر.

أخطاء شائعة Common Mistakes

• البدء بالإنتاج مباشرة: ابدأ بـ Import على ملفات PCAP تعرفها، ثم Standalone أو موزع، فهذا يوفر عليك أسبوعاً من حل المشكلات دون أن تعرف ما المتوقع.
• اسم الجهاز وعنوانه: الإعداد ينشئ الشهادات من اسم الجهاز، والمشروع لا يدعم تغيير الاسم أو العنوان بعد الإعداد، فاختر الاسم بحروف صغيرة والعنوان الثابت قبل أن تبدأ.
• معالج لا يدعم x86-64-v3 أو جهاز افتراضي بنوع معالج عام: تحقق قبل التحديث، وفي Proxmox اجعل نوع المعالج host.
• التخزين الشبكي: NFS أو iSCSI غير مدعومة، والقرص المحلي السريع هو المطلوب.
• تثبيت أدواتك المعتادة على المنصة: وكيل أمن آخر أو أداة مراقبة أو أتمتة قد تتعارض مع المكونات، فراقب المنصة من داخلها.
• Heavy Node لأنه يبدو أبسط: الوثائق لا توصي به لأغلب المستخدمين، واستخدم Manager Search إذا كانت أجهزتك قليلة.
• نسيان نسخ الحالات: بيانات Cases في Elasticsearch ولا تنسخ وحدها، فاضبط اللقطات Snapshots.
• البقاء على 2.4: انتهى دعمه في 1 أكتوبر 2026.
• تفعيل ميزات ترسل بيانات إلى الخارج دون قرار: القياس عن بعد والمساعد السحابي يحتاجان موافقة من يملك قرار البيانات في جهتك.

جدول قرار: هل يناسبك Security Onion؟

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• Security Onion توزيعة كاملة على Oracle Linux 9 تثبت من ISO بحجم 14 GB، وليست أداة تضيفها إلى سيرفر موجود، فعاملها كجهاز مستقل.
• تجمع Suricata وZeek والتقاط الحزم الكامل وStrelka وElastic Agent والمصائد مع Elasticsearch وواجهة واحدة فيها التنبيهات والبحث والحزم والحالات والقواعد.
• الالتقاط الكامل هو أهم ما ينقص المختبر اليدوي، وثمنه القرص: 50 ميجابت في الثانية تعني نحو 540 GB يومياً، فاحسب المتوسط الحقيقي ومدة الحزم قبل الشراء.
• أشكال التثبيت من Import بـ 4 GB إلى Standalone بـ 24 GB على الأقل إلى الشبكة الموزعة، والبداية الصحيحة Import على ملفات تعرفها.
• في الشكل الموزع تبقى الحزم على المستشعر، ويمر السجل عبر طابور Redis إلى عقد البحث، وعقدة Receiver تبقي الطريق مفتوحاً إذا توقف المدير.
• الرخصة ELv2 لا تقيد استخدامك الداخلي، ولكنها تقيد تقديم المنصة كخدمة مدارة، والنسخة Pro تضيف OIDC والإشعارات وKafka والمساعد والدعم، وسعرها غير منشور.
• بيانات الحالات لا تنسخ وحدها، والاحتفاظ الافتراضي 90 يوماً بينما يطلب الضابط 2-12-3-5 اثني عشر شهراً، والإصدار 2.4 انتهى دعمه.

وفي المقال القادم بإذن الله نضع Wazuh وSecurity Onion جنباً إلى جنب، ونجيب عن السؤال الذي يسأله كل فريق صغير بعد هذه السلسلة: أيهما أبدأ به، ومتى أحتاج الاثنين معاً؟ وأقرب المقالات إلى هذا الموضوع على الموقع:

دليلمراقبة الشبكة واكتشاف التسلل IDS مع Suricata وZeekمختبر حقيقي يقرأ الحركة نفسها بأداتين، فيكشف Suricata الهجمات المعروفة ويكتب Zeek سجلاً لكل اتصال، مع الضبط وفقد الحزم.دليلمراقبة السيرفرات مع Wazuh: من السجل Log إلى حظر المهاجمشغلنا Wazuh مع وكيل على سيرفر تجريبي، فكشف تخمين كلمات مرور SSH وحظر المهاجم تلقائياً، ونبه على ملف PHP دخيل خلال ثانية.دليلكيف يعمل محرك كشف SIEM من الداخل؟كيف يجمع SIEM ملايين السجلات ويوحدها ويطبق قواعد الكشف، مع خط أنابيب Vector وLoki وقاعدة Sigma تطلق فعلاً.دليلالضوابط الأساسية للأمن السيبراني NCA ECC بلغة بسيطةكيف تقرأ الضوابط الأساسية ECC دون أن تضيع في أرقامها، وعلى من تنطبق، وما المطلوب من جهتك فعلاً في كل مكون.دليلالتحقيق الرقمي DFIR للمبتدئين: احفظ الأدلة قبل أن تنظف السيرفرماذا تفعل عندما تشك أن سيرفرك مخترق، ولماذا تمسح إعادة التشغيل والتنظيف الأدلة التي تحتاجها لتعرف ما حدث.دليلOpenSearch: البديل المفتوح لـ Elasticsearch وقصة الترخيصلماذا ولد OpenSearch من Elasticsearch، وكيف تشغله على سيرفرك بصلاحيات دقيقة وتنبيهات حقيقية على سجلاتك.

تدريب عملي Practice

• احسب بنفس طريقة القسم السابق حجم الحزم اليومي لشبكتك: خذ متوسط الحركة الحقيقي لأسبوع من الـ Firewall، ثم احسب القرص لأسبوع ولأسبوعين، وقارنه بالأقراص المتاحة لديك.
• جهز ملف PCAP فيه حركة تعرفها من بيئة تجريبية، واكتب قبل استيراده قائمة بما تتوقع أن تراه من تنبيهات وسجلات، ثم استورده في عقدة Import وقارن، فهذا هو الاختبار الذي سوف تعيده بعد كل تحديث.

سجل التحديثات

• أكتوبر 2026: كتابة المقال من الوثائق الرسمية لـ Security Onion 3 وملاحظات الإصدار 3.3.0-20260911.