أتمنى لو كان Discourse يسجل محاولات تسجيل الدخول غير الصالحة في ملف، حتى لو كان ذلك يتطلب إعدادًا خاصًا. عندها سأستطيع إنشاء فلتر وسجن مخصص لـ Discourse.
أستخدم خادم fail2ban مركزيًا. طريقة عمله هي أن جميع الحاويات وصور Docker والماكينات الافتراضية (VMs) الخاصة بي تحتوي على إجراء حظر مخصص:
في fail2ban، تحدد الإجراء المطلوب تنفيذه في السجن، مثل: action = iptables-allports
ثم كل ما عليك فعله هو تعديل ذلك الإجراء: sudo nano /etc/fail2ban/action.d/iptables-allports.conf
بهذا الإعداد، ستقوم الحاوية/صورة Docker/الماكينة الافتراضية بحظر المهاجم محليًا عبر fail2ban، لكنها ستنقل هذه المعلومات أيضًا إلى خادم fail2ban المركزي. يمكن للخادم المركزي أيضًا تجميع جميع عناوين IP المجمعة وجعلها متاحة كقائمة حظر نصية، مثل: https://fail2ban.YourDomain.com/banned.txt
ثم يمكنك جعل جدار الحماية pfsense الخاص بك يشترك في قائمة الحظر هذه، ويمكنك حتى مشاركة القائمة مع موجهات pfsense أخرى. بهذه الطريقة، إذا حاولوا اختراق أحد التطبيقات، سيتم حظرهم من جميع التطبيقات. لقد نجح هذا الحل معي لسنوات.
وكل ما أحتاجه لتطبيق هذا على Discourse هو أن يسجل Discourse مدخلاً في ملف السجل عند حدوث محاولة تسجيل دخول غير صالحة
سجلات NGINX
قد تحتوي سجلات NGINX أحيانًا على بعض النصائح الإضافية، وتوجد في:
cd /var/discourse
./launcher enter app
cd /var/log/nginx
ستجد هناك ملفات access.log و error.log بالإضافة إلى مجموعة من الملفات المضغوطة المُدارة. عند تشغيل أمر less access.log.2.gz سيتم فك ضغط وعرض ملف السجل تلقائيًا.
كما أن هذا الدليل متاح على المضيف في المسار /var/discourse/shared/standalone/log/var-log/nginx.
للأسف، لا يسجل ملفا error.log و access.log الخاصين بـ nginx أي محاولات دخول غير صالحة.
أهلاً @Falco شكراً على الرد. لقد تفقدت السجلات على الفور الآن، ومحاولة كلمة مرور صحيحة ومحاولة كلمة مرور غير صحيحة تبدوان متشابهتين بالنسبة لي (استجابة 200):
(لقد قمت بتنقية عنوان IP والنطاق، والباقي لم يمسه أحد)
رائع، شكراً على الرد! حالما أحصل على القليل من وقت الفراغ سأحاول إنشاء إضافة لتوليد هذه المعلومات! (كل ما أحتاجه هو تسجيل عنوان IP في ملف عندما يحاول شخص ما تسجيل الدخول بكلمة مرور غير صحيحة، على سبيل المثال: محاولة تسجيل دخول غير صالحة من IP 10.111.222.33)
أنا أكتب عن أدوار مسؤول الويب العصامي والمستخدم النهائي البحت، ولكن…
تسجيل الدخول غير صالح هو الخطأ 200 بحكم تعريفه. بالتأكيد، يمكن وينبغي أن يكون خطأ داخليًا للتطبيق، وفي مرحلة ما يولد شيئًا آخر، مثل الخطأ 403 بالإضافة إلى شيء آخر مثل إرسال رابط استرداد، ولكن لا ينبغي أو لا يمكن أن يحدث ذلك على الفور.
Fail2ban أداة لطيفة ولكنها مبالغ فيها حقًا. دعنا ننسى docker، لأنه يجعل كل شيء أصعب، ولكن مجرد حقيقة أنه يمكنه تجاوز iptables الخاص بـ VPS هو أمر ضبابي حقًا بالنسبة لي. لكن الروبوتات تميل إلى تغيير عنوان IP بعد كل محاولة ثالثة وهذا يجعل Fail2ban عديم الفائدة تمامًا ضد هجوم القوة الغاشمة عبر تسجيل الدخول.
المتسللون المبتدئون قصة أخرى، بالطبع. ينسخون ويلصقون كل ما يجدونه، ويقومون بتدويرها ولا يلعبون بعناوين IP. عندها يمكن لـ Fail2ban إيقافهم، حتى لو كانوا نادرًا ما يفعلون أي ضرر، ولكنهم يزيدون الحمل. المشكلة الحقيقية هي كمية المتسللين المبتدئين عندما يكون هناك تدفق فوري.
ولكن طالما أن VPS يمكنه التعامل مع مثل هذا الموقف، فهذا لا يهم. الآن هو عام 2023 ومعظم هؤلاء الأوغاد يطرقون الثغرات القديمة لـ wordpress على موقع discourse
ولكن يجب أن يكون لدينا بعض المنطق لإيقاف تسجيلات الدخول المستمرة، بغض النظر عما إذا كان هذا ليس تهديدًا يوميًا، على ما أعتقد.