ما يشتركان فيه — ولماذا يكون الخلط مشروعاً
يستهدف كلٌّ من Fail2ban وCrowdSec الفئة ذاتها من التهديدات: الهجمات الآلية بالقوة الغاشمة ومسح المنافذ. يقرأ كلاهما سجلات الخدمة، ويرصد أنماط الفشل المتكررة (محاولات SSH، وأخطاء HTTP 401/403، ومسح Nginx) ويُطلق استجابة شبكية — الحظر عبر iptables أو nftables أو ufw.
كلاهما مفتوح المصدر، ومجاني التثبيت، ومتاح على Ubuntu 24.04 وDebian 12 من المستودعات الرسمية، وقادر على حماية SSH في أقل من عشر دقائق من التهيئة.
هذا التداخل بالضبط هو ما يُولِّد الخلط: المطور الذي يقرأ الوثيقتين بالتوازي يرى أولاً ما يجمعهما، لا ما يفرق بينهما.
Fail2ban مقابل CrowdSec في لمحة
مرّر الجدول أفقيًا
| المعيار | Fail2ban | CrowdSec |
|---|---|---|
| البنية | خدمة وحيدة، محلية بالكامل | Agent + bouncer + LAPI (واجهة API محلية) |
| الكشف | أنماط regex على السجلات | تحليل سلوكي + سيناريوهات |
| قائمة الحجب المجتمعية | لا | نعم (15,000 عنوان IP خبيث في الطبقة المجانية) |
| بصمة الذاكرة | خفيفة (< 50 ميغابايت في الاستخدام الاعتيادي) | خفيفة إلى معتدلة (< 100 ميغابايت دون AppSec/WAF) |
| التبعيات الشبكية | لا شيء | وصول HTTPS إلى واجهة API المركزية لـCrowdSec |
| تعدد الخوادم | غير مدعوم أصلاً | نعم (LAPI مركزي مشترك) |
| جدار حماية تطبيقي مدمج | لا | نعم (مكوّن AppSec منذ الإصدار v1.6) |
| الإعداد | Jails + مرشحات (regex) | سيناريوهات YAML + bouncers |
| أحدث إصدار مستقر | انظر ملاحظات الإصدار | voir notes de version |
| الأنسب لـ | VPS بموارد محدودة، خدمة SSH واحدة، عزل شبكي | بنية متعددة الخدمات والعقد، حركة مرور ويب |
متى يكون Fail2ban الخيار الأنسب
يتألق Fail2ban في السياقات التي تكون فيها البساطة قيداً حقيقياً لا اختصاراً.
خادم افتراضي بموارد محدودة. Fail2ban خدمة Python دون أي تبعية شبكية خارجية. على خادم بـ512 ميغابايت أو 1 غيغابايت من الذاكرة وخدمة مكشوفة واحدة (SSH)، يؤدي دوره دون تعقيد إضافي — لا واجهة API محلية للصيانة، ولا حاجة للسماح بحركة HTTPS الصادرة في جدار الحماية، ولا عملية ثانية للإشراف عليها.
محيط محلي صارم. إذا كانت سياسة أمانك تمنع خروج أي بيانات قياس أداء أو مزامنة من الخادم، فـFail2ban هو الأداة المناسبة. يتصل CrowdSec، حتى دون محرك AppSec، بالواجهة API المركزية لاستقبال قائمة الحجب المجتمعية والإبلاغ عن عناوين IP المكتشفة محلياً.
بيئة بلا Docker. يُثبَّت Fail2ban كحزمة واحدة، ويُهيَّأ عبر ملفات INI، ويُعاد تشغيله بـsystemctl. لا يفرض أي تبعية على Docker أو بيئة تشغيل الحاويات — مما يهم على خادم مخصص لمكدس PHP أو Python دون containerisation.
خدمة واحدة للحماية. إذا كان SSH هو نقطة الدخول الوحيدة للمراقبة وكان مُهيَّأً بشكل صحيح (منفذ غير قياسي، مصادقة بالمفتاح)، يغطي Fail2ban هذه الحاجة تحديداً دون مبالغة في المواصفات.
Fail2ban برنامج ناضج يحظى بصيانة نشطة وهو متوافق مع Python 3.x.
متى يضيف CrowdSec قيمة واضحة
يبرر CrowdSec تعقيده الإضافي في السياقات التي يصل فيها Fail2ban إلى حدوده الطبيعية.
سطح هجوم متعدد الخدمات. حالما يكشف خادمك الافتراضي Nginx وتطبيقاً للويب وواجهة API عامة أو خدمة ملفات إلى جانب SSH، يدير CrowdSec الجميع عبر سيناريوهات متخصصة لكل خدمة، بينما يتطلب Fail2ban jail منفصلة لكل بروتوكول.
البُعد التعاوني. تجمع قائمة الحجب المجتمعية لـCrowdSec إشارات من أكثر من 70,000 وكيل نشط في أكثر من 190 دولة. يستفيد كل وكيل من الحظر الوقائي لعناوين IP المُعرَّفة كعدوانية من قِبَل الأعضاء الآخرين في الشبكة — نحو 15,000 عنوان IP في الطبقة المجانية.
بنية تحتية متعددة العقد. إذا كنت تُدير عدة خوادم افتراضية (تجريبي، إنتاجي، نسخ احتياطية)، يتيح CrowdSec مركزة قرارات الحظر على LAPI مشترك. تُحجب الإشارة المكتشفة على العقدة التجريبية تلقائياً على عقدة الإنتاج.
الحاجة إلى جدار حماية تطبيقي. منذ الإصدار v1.6، يتضمن CrowdSec مكوّن AppSec يتيح له العمل كجدار حماية تطبيقي أمام Nginx أو OpenResty: فحص طلبات HTTP، وكشف حقن SQL واجتياز المجلدات، وتكامل أصلي دون reverse proxy إضافي.
يمكن للأداتين التعايش معاً
السؤال ليس دائماً بين خيارين فقط. نمط شائع: يحمي Fail2ban SSH محلياً (خفة، بلا تبعية شبكية) بينما يحمي CrowdSec، عبر bouncer الخاص بـNginx، حركة مرور HTTP/HTTPS التطبيقية. يعتمد الاثنان على iptables أو nftables دون تعارض، طالما تستهدف قواعدهما منافذ مختلفة. هذا ليس الإعداد الموصى به لخادم بموارد محدودة، لكنه متسق على خادم افتراضي مخصص لتطبيق ويب مكشوف.
إجراء الترحيل: الانتقال من Fail2ban إلى CrowdSec
إذا كان لديك Fail2ban في الإنتاج وتريد الترحيل، إليك التسلسل الذي يتبعه لتجنب أي ثغرة في الحماية.
قبل البدء: أدرج jails النشطة (fail2ban-client status) وسجِّل العتبات المُهيَّأة (maxretry، bantime، findtime) — ستكون مرجعاً للتحقق من أن CrowdSec يعمل قبل إزالة Fail2ban.
للحصول على دليل تثبيت CrowdSec الكامل (agent، bouncer جدار الحماية، Console)، راجع مقال تأمين خادمك الافتراضي باستخدام CrowdSec.
التحقق من التعايش المؤقت: يمكن لـCrowdSec وFail2ban العمل بالتوازي أثناء التحقق من الإعداد الجديد. تحقق من أنهما لا يكتبان معاً في سلسلة iptables ذاتها (قد يسبب تكرار القواعد). يُظهر iptables -L -n | grep f2b قواعد Fail2ban النشطة؛ بينما يُظهر iptables -L -n | grep crowdsec قواعد bouncer CrowdSec.
التبديل: بمجرد التحقق من صحة سيناريوهات CrowdSec وتلقي قائمة الحجب المجتمعية، أوقف Fail2ban: systemctl stop fail2ban && systemctl disable fail2ban. القواعد المضافة يدوياً إلى iptables تبقى بعد إيقاف الخدمة — امسحها بـfail2ban-client unban --all قبل الإيقاف، أو أفرِغ سلسلة f2b بـiptables -F f2b-sshd.
الاختبار النهائي: من جهاز اختبار، أنشئ خمس محاولات تسجيل دخول SSH ببيانات خاطئة وتحقق من حظر عنوان IP في cscli decisions list.
ملخص شجرة القرار
- خادم افتراضي بموارد محدودة (≤ 1 غيغابايت RAM)، خدمة SSH واحدة → Fail2ban: خفيف، بلا تبعية شبكية، يُهيَّأ في 10 دقائق.
- سياسة عزل شبكي صارمة (لا حركة صادرة لـAPIs خارجية) → Fail2ban: يتطلب CrowdSec وصول HTTPS إلى الواجهة API المركزية.
- خادم افتراضي بلا Docker أو بيئة تشغيل حاويات، مكدس PHP/Python كلاسيكي → Fail2ban: يُثبَّت كحزمة واحدة، بلا تبعيات إضافية.
- متعدد الخدمات (SSH + Nginx + تطبيق ويب) على خادم افتراضي جيد التجهيز → CrowdSec: سيناريوهات لكل خدمة، قائمة حجب مجتمعية، bouncer HTTP.
- بنية متعددة العقد (تجريبي + إنتاجي + نسخ) → CrowdSec: LAPI مركزي، قرارات حظر متزامنة بين الخوادم.
- الحاجة إلى جدار حماية تطبيقي دون reverse proxy إضافي → CrowdSec: مكوّن AppSec أصلي متاح منذ الإصدار v1.6.
- التعايش: Fail2ban لـSSH وCrowdSec bouncer لـNginx → خيار صالح على خادم افتراضي مخصص لتطبيق ويب مكشوف.
UFW والأداتان
يعتمد كلٌّ من Fail2ban وCrowdSec على طبقات شبكة النواة Linux (iptables، nftables، أو عبر UFW). إعداد UFW مسبقاً — برفض كل حركة المرور الواردة باستثناء المنافذ الضرورية — ممارسة جيدة مستقلة عن اختيار أداة الكشف. يتناول مقال تهيئة جدار الحماية UFW على خادمك الافتراضي إعداد هذه الطبقة الأساسية.
ما لا تغطيه هذه المقارنة
تتناول هذه المقارنة الاختيار، لا التثبيت. أدلة التثبيت الكاملة منفصلة:
- لـCrowdSec (agent، bouncer، Console): تأمين خادمك الافتراضي باستخدام CrowdSec
- لـFail2ban (jails لـSSH وNginx، عتبات، اختبارات): Fail2ban Enhanced على خادم VPS: حجب الهجمات المتكررة
لا تغطي هذه المقارنة أيضاً الحلول المدفوعة أو الهجينة (Imunify360، ConfigServer Security & Firewall) ولا جدران حماية الويب السحابية (Cloudflare، AWS WAF). للحصول على نهج شامل لتصليب Linux، يضع مقال التصليب الأولي لخادم Linux الأسس التي تُثبَّت عليها هاتان الأداتان.
