oisf/suricataمحرك شبكة مفتوح المصدر لأنظمة IDS/IPS/NSM لفحص حركة المرور في الوقت الفعلي، واكتشاف ومنع التسلل، وتحليل البروتوكولات، ومطاردة التهديدات المبنية على القواعد.
Suricata هو محرك IDS وIPS وNSM للشبكات، طوّره OISF ومجتمع Suricata.
نرحّب باستلام التصحيحات والمساهمات الأخرى. يُرجى الاطلاع على عملية المساهمة لمعرفة كيفية البدء.
Suricata برنامج معقّد يتعامل مع مدخلات غير موثوقة في الغالب. وقد يؤدّي سوء التعامل مع هذه المدخلات إلى عواقب وخيمة:
بعبارة أخرى، نرى أن المخاطر كبيرة جدًا، خاصة أن مهاجمًا قد يتمكّن في كثير من الحالات الشائعة من الوصول المباشر إلى نظام IDS/IPS.
لهذا السبب، طوّرنا عملية ضمان جودة (QA) واسعة النطاق. ومن نتائج ذلك أن المساهمة في Suricata قد تكون عملية طويلة إلى حدٍ ما.
بشكل عام، الخطوات هي:
يمكن لأعضاء فريق OISF إرسال البنيات إلى بيئة ضمان الجودة الخاصة بنا. وستقوم بتشغيل سلسلة من اختبارات البناء ومجموعة اختبارات الانحدار (regression) للتأكد من عدم كسر أي ميزات قائمة.
تستغرق عمليات ضمان الجودة النهائية بضع ساعات كحد أدنى، وتُشغَّل عادةً أثناء الليل. وتشمل حاليًا:
إلى جانب هذه الاختبارات، وبناءً على نوع تغيير الكود، يمكن تشغيل اختبارات إضافية يدويًا:
من المهم أن تدرك أن جميع الاختبارات المذكورة أعلاه تقريبًا تُستخدم كاختبارات قبول. إذا فشل أي شيء، فالأمر يعود إليك لمعالجة ذلك في الكود الخاص بك.
تُنفَّذ حاليًا إحدى خطوات ضمان الجودة بعد الدمج. نرسل البنيات إلى برنامج Coverity Scan. ونظرًا لقيود هذه الخدمة (المجانية)، يمكننا الإرسال مرة واحدة يوميًا كحد أقصى. وبالطبع، يمكن أن يحدث أن يجد المجتمع مشكلات بعد الدمج. وفي كلتا الحالتين، نطلب منك المساعدة في معالجة المشكلات عند ظهورها.
س: هل ستقبل طلب السحب (PR) الخاص بي؟
ج: يعتمد ذلك على عدّة أمور، من بينها جودة الكود. بالنسبة للميزات الجديدة، يعتمد أيضًا على ما إذا كان الفريق و/أو المجتمع يرون أن الميزة مفيدة، ومدى تأثيرها على الكود والميزات الأخرى، وخطر تراجع الأداء، وما إلى ذلك.
س: متى سيتم دمج طلب السحب (PR) الخاص بي؟
ج: الأمر يعتمد على ذلك؛ إذا كانت الميزة رئيسية أو اعتُبر التغيير عالي الخطورة، فسيُدرج على الأرجح في الإصدار الرئيسي القادم.
س: لماذا تم إغلاق طلب السحب (PR) الخاص بي؟
ج: كما هو موثّق في سير عمل Suricata على GitHub، نتوقّع تقديم طلب سحب جديد لكل تغيير.
عادةً، يقدّم الفريق (أو المجتمع) ملاحظات على طلب السحب، وبعد ذلك يُتوقَّع استبداله بطلب سحب محسّن. لذا انظر إلى التعليقات. إذا كنت لا توافق على التعليقات، فلا يزال بإمكاننا مناقشتها في طلب السحب المغلق.
إذا أُغلق طلب السحب دون تعليقات، فمن المحتمل أن يكون السبب فشل ضمان الجودة. إذا فشلت فحوصات GitHub-CI، يجب إصلاح طلب السحب فورًا. لا حاجة للنقاش حول ذلك، إلا إذا كنت تعتقد أن فشل ضمان الجودة غير صحيح.
س: المترجم/محلّل الكود/الأداة مخطئ، ما العمل الآن؟
ج: للمساعدة في أتمتة ضمان الجودة، لا نقبل بقاء التحذيرات أو الأخطاء. في بعض الحالات، قد يعني ذلك إضافة كبت (suppression) إذا كانت الأداة تدعم ذلك (مثل valgrind وDrMemory). يمكن تعطيل بعض التحذيرات. في بعض الحالات الاستثنائية، يكون "الحل" الوحيد هو إعادة هيكلة الكود للالتفاف حول إيجابية خاطئة ناتجة عن قيود المدقّق الثابت. ورغم أن هذا محبط، فإننا نفضّله على ترك تحذيرات في المخرجات. فالتحذيرات تميل إلى أن تُتجاهل ثم تزيد من خطر إخفاء تحذيرات أخرى.
س: أعتقد أن اختبار ضمان الجودة لديكم خاطئ
ج: إذا كنت تعتقد ذلك فعلًا، يمكننا مناقشة كيفية تحسينه. لكن لا تتوصّل إلى هذا الاستنتاج بسرعة كبيرة؛ ففي أغلب الأحيان يتبيّن أن الكود هو الخطأ.
س: هل تطلبون التوقيع على اتفاقية ترخيص المساهم (CLA)؟
ج: نعم، نفعل ذلك لإبقاء ملكية Suricata في جهة واحدة: مؤسسة Open Information Security Foundation. انظر http://suricata.io/about/open-source/ وhttp://suricata.io/about/contribution-agreement/
