تقرأ الأداتان السجلات وتحظران العناوين، وللوهلة الأولى يبدو CrowdSec كأنه Fail2ban بشيفرة أحدث. لكن الفرق بينهما أعمق من ذلك، وهو لا يكمن في عمر الشيفرة بل في مصدر قرار الحجب.
كيف بُنيت كل منهما
Fail2ban عملية واحدة تقرأ السجلات وتحصي مطابقات التعابير النمطية وتستدعي أمرًا لجدار الحماية. وكل قرار يُتخذ على آلتك من عدّاداتك أنت. ولا يُرسل شيء إلى أي مكان، ولا توجد اعتماديات، والإعداد ملفات نصية.
أما CrowdSec فمقسوم إلى جزأين، وهذا هو الأهم لفهمه قبل التثبيت. فالوكيل نفسه يكشف فقط: يحلّل السجلات، ويطبّق السيناريوهات، ويكتب القرارات في قاعدته الخاصة. أما تنفيذ القرارات فيتولاه برنامج منفصل هو الـ bouncer. وبدون bouncer مثبَّت يعمل CrowdSec، ويعرض التنبيهات، ويحتفظ بقائمة قرارات — ولا يحجب شيئًا.
وهذه أشيع خيبة أمل عند التعارف الأول: الأداة مثبتة، والهجمات ظاهرة، والحركة تسير تمامًا كما كانت.
sudo apt install crowdsec
sudo apt install crowdsec-firewall-bouncer-iptables
sudo cscli bouncers listويجب أن يُظهر هذا الأمر الأخير مُدخلًا مسجّلًا واحدًا على الأقل. والقائمة الفارغة تعني أنه لا يوجد حجب.
الفرق الثاني: السمعة المشتركة
لا يعرف Fail2ban سوى ما جرى عندك. فعنوان قضى الأمس يقتحم مئة خادم آخر يبقى نظيفًا بالنسبة له حتى يطرق بابك — ومحاولاته الخمس الأولى مجانية.
أما CrowdSec فيرسل إشارات عمّا انطلق إلى شبكة مشتركة ويتلقى في المقابل قائمة بعناوين رُصدت عند خوادم آخرين. والأثر العملي: يُقطع جزء ملحوظ من التخمين قبل المحاولة الأولى. وهذا مهم خصوصًا في مواجهة الهجمات الموزّعة — آلاف العناوين بمحاولة واحدة لكل منها، حيث تكون العدّادات المحلية عاجزة بحكم التعريف.
وإليك ما ينبغي معرفته مسبقًا: التبادل يجري في الاتجاهين. فالذي يخرج من خادمك هو عناوين المخالفين وأنواع السيناريوهات التي انطلقت. والعمل المحلي بالكامل ممكن — دون تسجيل في وحدة التحكم السحابية — لكن القائمة المشتركة تصبح عندئذ غير متاحة لك أنت أيضًا، فتزول الميزة الرئيسية. وهذا اختيار واعٍ لا تفصيل إعداد.
أوامر يومية
sudo cscli metrics
sudo cscli alerts list
sudo cscli decisions list
sudo cscli decisions delete --ip 203.0.113.25ويجيب metrics عن سؤال هل تُقرأ السجلات أصلًا: فإن كان عدد الأسطر المحلَّلة صفرًا، فإما أن مجموعة خادم الويب لديك غير مثبتة أو أن مسار السجل خاطئ. وهذه ثاني أشيع حالة من حالات «مثبَّت ولا يعمل».
sudo cscli collections list
sudo cscli collections install crowdsecurity/nginxالموارد
كُتب CrowdSec بلغة Go ويحتفظ بحالته في قاعدة بيانات. واستهلاك الذاكرة في حدود مئة ميغابايت، إضافة إلى الـ bouncer. وعلى خادم بغيغابايت واحد يكون ذلك ملحوظًا؛ ومن اثنين فصاعدًا لا يكون. أما Fail2ban فأخف، ويفعل أقل.
هل يستحق تشغيلهما معًا
لا يتعارضان: فأحدهما يكتب قواعده في جدار الحماية والآخر يكتب قواعده، وحظر العنوان نفسه مرتين لا يضر بشيء. والتقسيم المعقول يبدو هكذا.
يتولى CrowdSec الحركة الجماعية: تخمين SSH، ومسح خادم الويب، والعناوين السيئة المعروفة من القائمة المشتركة. ويبقى Fail2ban حيث يكون لديك سجل خاص بصيغتك الخاصة، تكون كتابة تعبير نمطي له أسهل من كتابة سيناريو — تطبيق من صنعك، أو خدمة نادرة، أو نموذج دخول بعينه.
وإن توجّب اختيار واحد، فالمعيار هذا: على خادم عليه موقع يُجَسّ باستمرار، يعطي CrowdSec أكثر بفضل القائمة المشتركة. أما على خادم لا يصل إليه سوى أنت عبر SSH بالمفاتيح، فالفرق بينهما ضئيل — إذ أُنجز معظم العمل هناك بتعطيل كلمات المرور.
قيد مشترك
لا يحمي أي منهما من ثغرة في تطبيق. فكلاهما يعمل بتواتر الطلبات وسمعة العناوين، وطلب يستغل من المحاولة الأولى ثغرة في إضافة، وقادم من عنوان نظيف، سيمرّ من جانبهما معًا. تلك مهمة أدوات أخرى — جدار حماية تطبيقات على مستوى الطلب، وتحديثات في وقتها. فحجب العناوين يزيل الخلفية لا السبب.
والقيمة العملية لكليهما تتوقف على أن ينظر أحد إلى النتيجة. فارتفاع عدد القرارات، وسيناريو ينطلق للمرة الأولى، وتغيّر البلدان التي تأتي منها المحاولات — تلك هي المعلومات التي ثُبّتت الأداة من أجلها. وشكل ذلك على صفحة واحدة يعرضه العرض التوضيحي أدناه.