مرحباً، أحاول حظر شبكة فرعية /16 مسيئة مؤقتًا والتي تضرب منتدى Discourse بالطلبات. لقد جربت هذا…
…ولكنني ما زلت أرى عددًا كبيرًا من الطلبات الجديدة من نفس النطاق في /var/discourse/shared/standalone/log/var-log/nginx/access.log.
نظرًا لأن هذه تم تكوينها في Discourse، أنا متأكد من أن عناوين IP يتم حظرها بواسطة Discourse، وليس NGINX، لذلك ستظهر في سجلات NGINX. إنها Discourse التي تحظرها، وليس nginx. إذا كنت ترغب في حظرها حتى لا تظهر في سجلات NGINX، يمكنك حظرها باستخدام جدار الحماية الخاص بك.
إعجاب واحد (1)
شكرًا جاي، أنت على حق بشأن كيف سيظل يظهر في سجلات Nginx إذا تم حظره على مستوى التطبيق. ومع ذلك، فإن الحظر على مستوى التطبيق لا يفعل ما أتوقعه أيضًا. حاولت الاتصال عبر VPN ثم أضفت عنوان IP الخاص بي إلى قائمة “عناوين IP التي تم فحصها”، لكنه سمح لي بالتنقل في المنتدى. أعتقد أنه يجب تسميته “عناوين IP التي تم فحصها” وليس “عناوين IP المحظورة” لأنه ربما يمنع عناوين IP هذه فقط من تسجيل حساب؟
أحتاج إلى أن يقوم تطبيق Discourse برفض الوصول إلى الصفحات المطلوبة للطلبات الواردة من تلك العناوين، وخاصةً ألا يقوم بعرض تلك الصفحات، حيث أن كل هذه الطلبات تستهلك وحدة المعالجة المركزية.
هل ترى ديسكورس أنك قادم من أحد عناوين IP المحظورة إذا ذهبت للنظر في سجل المستخدم من /admin/users؟ (إذا كنت خلف وكيل مثل cloudflare، فقد ترى ديسكورس عنوان IP الخاص بالوكيل الخاص بك وليس عنوان IP الخاص بالمستخدم.)
نعم، عندما أتصل بشبكة الـ VPN ثم أنظر إلى آخر عنوان IP لحساب المستخدم الخاص بي في Discourse، يظهر عنوان IP الذي منحته لي شبكة الـ VPN. ومع ذلك، عندما أفتح نافذة متصفح متخفي وأحاول تسجيل حساب جديد، فإنها لا تسمح بذلك:
لا يُسمح بالتسجيلات الجديدة من عنوان IP الخاص بك.
لذلك، يبدو أن “عناوين IP التي تم فحصها” مخصصة للتسجيل فقط، وليس لمنع الوصول إلى موقع الويب تمامًا.
وليزيد الأمر تعقيدًا، فإن ufw على الخادم المضيف لا يمنع الأشياء كما هو متوقع داخل Docker على ما يبدو:
إعجاب واحد (1)
لست متأكدًا من أين نوثق هذا، ولكنه ظهر عدة مرات مؤخرًا.
“عناوين IP التي تم فحصها” تمنع التسجيل وتسجيل الدخول من عناوين IP المحظورة التي تتطابق، ولكن ليس الجلسات الحالية.
لست متأكدًا من أين (إن وجدت) نوثق هذا.
3 إعجابات
شكراً للتأكيد.
إذن، ما هي أسهل طريقة لرفض الطلبات من عنوان IP أو نطاق من عناوين IP؟ لقد وجدت هذا، ولكنه يبدو عكس ما أحتاجه. (قائمة بيضاء بدلاً من قائمة سوداء) والعبث بإعداد Nginx داخل الحاوية يبدو وكأنه حل غير احترافي تمامًا:
أعتقد أن القيام بذلك باستخدام UFW أو IPTABLES. هذا يزيل ويوقفها قبل أن يتدخل Discourse. أنا دائمًا ما أكون غامضًا وخائفًا من العبث بجدران الحماية خوفًا من أن أحبس نفسي، ولكن إذا استهدفت المنفذ 443 فقط فلن تكون في أي خطر.
لدى Digital Ocean بعض التلميحات: UFW Essentials: Common Firewall Rules and Commands for Linux Security | DigitalOcean. سأبحث فقط عن أمثلة.
هذا بالضبط ما أخشاه أيضًا. لكنني قمت بتمكينه على المضيف ومع ذلك فإنه لا يزال لا يحظر نطاق IP الإشكالي. يبدو أنه يحتاج إلى مجموعة معقدة من القواعد لجعله يطبق قواعد الرفض على حاويات Docker.
أوه. نعم. هذا صحيح تمامًا. انتهى بي الأمر بحظر الوصول من خوادم الويب المستندة إلى Docker الخاصة بي إلى قاعدة بيانات PostgreSQL المستندة إلى Docker (من المحتمل ألا تكون إحدى مشاكلك).
إليك فكرة أخرى: Geo Blocking plugin
شكرًا، كنت أبحث في هذا أيضًا، لكن يبدو أنه لا يسمح بحظر نطاقات IP الرقمية، بل البلدان بأكملها فقط؟
لم أقم بتثبيته مؤخرًا، ولكني متأكد من أنه يفعل ذلك
(تم إضافة التأكيد)
ولكن بعد ذلك وجدت هذا:
لذلك أعتقد أن هذا يعني أنه يمكنك وضع أي شبكة تريدها هناك.
إعجاب واحد (1)
/var/discourse/launcher enter app
apt install nano
nano /etc/nginx/conf.d/discourse.conf
وفي كتلة server { أضف:
## 2025-10-27
deny 12.34.0.0/16;
ثم احفظ ونفذ:
nginx -t
service nginx reload
لا أفهم تمامًا سبب استمرار رؤيتي لطلبات من 12.34.x.x في سجل access.log الخاص بـ Nginx، ولكنه يبدو أنه يعمل لأن استخدام وحدة المعالجة المركزية عاد إلى طبيعته. عملية معقدة بشكل لا يصدق في رأيي، ولكنها جيدة بما فيه الكفاية في الوقت الحالي لإعادة الموقع إلى العمل.
نعم، ولكن حاليًا سيقبل فقط أرقام AS وليس تدوين CIDR مثل 1.2.3.0/24.
إعجاب واحد (1)
هل نجح ذلك؟ أعتقد أنك بحاجة إلى القيام بذلك
sv restart nginx
ولكن إذا لم تحصل على خطأ، فأنا مخطئ.
هل ما زال Nginx يرى تلك الزيارات؟ هل يظهر أنه يخدمها؟ هل تراها في سجل الإنتاج الخاص بـ Rails (production.log)؟
آه. ربما كان يجب أن أنتبه أكثر إلى صفحة ويكيبيديا تلك حول أرقام AS.
أعتقد أن كلاهما اسم مستعار قديم تم ربطه الآن بأوامر systemd، لذا فإن systemctl restart nginx سيكون الأكثر ملاءمة.
تعديل: يبدو أن systemctl لا يعمل داخل Docker. إليك بعض الشروحات حول الاختلافات:
- https://serverfault.com/questions/867322/what-is-the-difference-between-service-and-systemctl
- https://askubuntu.com/questions/903354/difference-between-systemctl-and-service-commands/903405
نعم، في access.log لا تزال تظهر مثل:
[28/Oct/2025:00:29:27 +0000] "myforum.com" 12.34.56.78 "GET /permalink/12345 HTTP/1.1" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36" "-" 403 691 "-" - 0.000 "-" "-" "-" "-" "-" "-" "-" "
يبدو أنها تستهدف بشكل أساسي الروابط الدائمة الآن (تم ترحيلها من منصة منتديات قديمة). هل هناك نوع من الثغرة الأمنية مع الروابط الدائمة تسمح لها بتجاوز قاعدة deny؟ لم أتحقق من production.log بعد.
بشكل عام، أود أن أقول إن الافتقار إلى واجهة مستخدم رسومية لفحص سجلات الوصول وعدم وجود قائمة حظر IP على مستوى التطبيق هو قيد كبير جدًا لـ Discourse. إنه يحدث بشكل غير متكرر، ولكن عندما تتعرض لهجوم من هذه الروبوتات/المتسللين/الزواحف، فأنت تريد فقط تحديد المصدر على الفور وتخفيفه، دون العبث بمجموعة من ملفات التكوين والأوامر الغامضة، خاصة ليس على مستويات عميقة داخل حاوية Docker مع كل التجريد الغريب الذي يحدث هناك. المنصة القديمة للمنتديات التي قمت بالترحيل منها أظهرت قائمة بسيطة بالمستخدمين أو عناوين IP التي لديها أكبر عدد من الطلبات خلال نافذة زمنية قابلة للتعديل، وكان من الممكن حتى تصفيتها حسب المستخدمين و/أو عناوين IP التي شغلت أكبر قدر من وقت وحدة المعالجة المركزية. بهذه الطريقة، يمكنني تحديد العنوان أو النطاق المخالف بسرعة، ثم كانت هناك واجهة للنقر والإضافة لإضافته إلى قائمة الحظر، وكان سيتم إرجاع 404 للطلبات من عناوين IP هذه.
إذا كان لديك قاعدة deny، فسيتم تسجيل الأشياء في nginx. وهي تعمل بشكل صحيح، لأنه يوجد 403 هناك، مما يعني أنه تم منع العميل من الوصول.
لا يتم إعادة توجيه هذه الطلبات إلى Discourse. إذا كنت تريد معرفة ما إذا كان الحظر الخاص بك يعمل بشكل صحيح، فيجب عليك إما
- النظر في
production.logالخاص بـ Discourse بدلاً من ذلك - النظر في سجلات nginx ولكن تجاهل أي إدخال يحتوي على
403في حقل رمز استجابة HTTP.
3 إعجابات
هل تم حل هذا الموضوع الآن؟ هل هناك منشور واحد @rgj أو @pfaffman يمكنني اختياره كحل؟ يبدو أنكم تعاونتم في هذا الموضوع!
مرحباً، أود أن أقول إن هذه المشكلة ليست قابلة للحل في الوقت الحالي بالطرق “العادية”. الواجهة الإدارية لـ “عناوين IP المفحوصة” لا تفعل ما يتوقعه معظم المستخدمين، والطريقة التي تعمل بالفعل تتضمن العبث داخل حاوية Docker الخاصة بـ Discourse، لذا فهي أقرب إلى حل مؤقت قذر بدلاً من حل، على الأقل في رأيي. سيكون من الرائع لو حصل هذا على المزيد من الاهتمام: