إعداد جدار حماية لـ Discourse

إذا كنت تستخدم تثبيت Discourse قياسيًا قائمًا على Docker، فإن قواعد جدار الحماية غير المعقد التالية ستحمي أي خدمات غير تابعة لـ Docker تعمل على الخادم الخاص بك:

ufw allow http
ufw allow https
ufw allow ssh
ufw enable

أي، السماح بـ HTTP (المنفذ 80) و HTTPS (المنفذ 443) و SSH (المنفذ 22)، ولا شيء آخر.

:warning: ملاحظة: يقوم Docker بالتلاعب بـ iptables مباشرة ويتجاوز قواعد ufw. هذا يعني أن ufw لا يمكنه حظر أو تقييد الوصول إلى المنافذ المكشوفة بواسطة حاويات Docker (المنافذ 80 و 443 في تثبيت Discourse قياسي). قواعد ufw المذكورة أعلاه ستحمي فقط الخدمات غير التابعة لـ Docker التي تعمل على المضيف الخاص بك.

تحقق من الحالة الحالية لجدار الحماية الخاص بك باستخدام

ufw status verbose

مثال للإخراج:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
80                         ALLOW IN    Anywhere
443                        ALLOW IN    Anywhere
22                         ALLOW IN    Anywhere
80 (v6)                    ALLOW IN    Anywhere (v6)
443 (v6)                   ALLOW IN    Anywhere (v6)
22 (v6)                    ALLOW IN    Anywhere (v6)

وإذا أردت إيقافه في أي وقت

ufw disable

تثبيت Docker الافتراضي لـ Discourse يعرض فقط المنفذين 80 و 443، لذا فإن جدار حماية المضيف ليس ضروريًا بشكل صارم. ولكن إذا كانت لديك خدمات أخرى قيد التشغيل على المضيف تستمع إلى منافذ إضافية، فإن إضافة جدار حماية يوفر طبقة إضافية من الأمان “للاحتياط” لتلك الخدمات.

33 إعجابًا

حسب فهمي، فإن حاوية Docker لديها عدد قليل جدًا من المنافذ المفتوحة للنظام المضيف، لذا فإن Discourse معزول بشكل فعال عن الخادم الذي يعمل عليه.

بالطبع، إذا كانت هناك أشياء أخرى تعمل على النظام المضيف، فإن الكابتن أوبفيس يقول إنك بحاجة إلى اتخاذ الاحتياطات اللازمة.

لقد واجهت خادمًا اعتقدنا أنه مؤمن بشكل جيد وتم اختراقه، ولم يكن الأمر لطيفًا.

إعجاب واحد (1)

الموضوع ليس دقيقًا تمامًا. إذا تم استخدام UFW خارج Docker، كما هو “طبيعي” على VPS، فإنه لا ينطبق بحد ذاته على Discourse. يمكنني تعطيل المنفذ 80 وسيظل مفتوحًا بالكامل لـ Discourse/docker.

بالتأكيد، إنه يحمي كل شيء آخر ولكن إذا لم تكن هناك خدمات أخرى تستمع، فهو غير ضروري.

لا أعرف كيف تعمل UFW أو iptables إذا تم استخدامها بعد enter app أو إذا كان يمكن لجدار الحماية العمل بهذه الطريقة على الإطلاق.

أنا أشير إلى هذا الموضوع:

3 إعجابات

أود بالتأكيد أن أسمع هذه القصة، ربما في موضوع منفصل :slight_smile:

على سبيل المثال، المناقشات حول العلاقة بين Docker و ufw / جدران الحماية قديمة قدم Docker نفسه، إليك مناقشة ذات أهمية كبيرة مع الكثير من الأفكار المثيرة للاهتمام

لقد تحسن Docker نفسه في السنوات الأخيرة فيما يتعلق بتوثيق التفاصيل ذات الصلة؛ Packet filtering and firewalls | Docker Docs

لا أريد إغراق الموضوع بالكثير من الروابط، ولكن إذا كنت مهتمًا بموضوع جدران الحماية، فتبدو هذه القطع مفيدة حقًا للمراجعة، جنبًا إلى جنب مع البحث العام على Google لمزيد من التفاصيل.

بناءً على بعض هذه المشاعر، وعلى الموضوع المفيد للغاية الذي رابطه @Jagster، يبدو أن التكوين الافتراضي لتثبيت Discourse الجاهز مع Docker كافٍ بحد ذاته؟ بعد كل شيء، يبدو جهازي هكذا؛

$ docker ps
CONTAINER ID   IMAGE                 COMMAND        CREATED      STATUS        PORTS                                                                      NAMES
5dd4a572cd8e   local_discourse/app   \"/sbin/boot\"   6 days ago   Up 16 hours   0.0.0.0:80-\u003e80/tcp, :::80-\u003e80/tcp, 0.0.0.0:443-\u003e443/tcp, :::443-\u003e443/tcp   app

لذلك، ما لم أكن مخطئًا، وما لم تكن هناك منافذ أخرى قيد الاستخدام بواسطة برامج أخرى على الخادم، أعتقد أن حركة المرور الوحيدة التي يجب أن تتصل بها من الداخل ستكون على هذه المنافذ المدرجة 80 و 443

إذا كنت ترغب في إجراء فحص للتحقق، أعتقد أنه يمكنك استخدام netstat للتحقق من المنافذ المستمعة على الخادم الخاص بك (How to Install netstat on Ubuntu ؛ https://linuxize.com/post/check-listening-ports-linux/)

netstat -tunlp

لإجراء فحص أقوى، قد تفكر في تشغيل خادم Linux صغير ثانٍ ومحاولة مسح منافذ خادم Discourse المفتوحة؛ How To Use Nmap to Scan for Open Ports | DigitalOcean

# مسح جميع المنافذ ؛ أدخل عنوان IP الخاص بك هنا
sudo nmap -n -PN -sT -sU -p- 1.2.3.4
  • تحقق من الرابط المضمن لوثائق DigitalOcean لمزيد من الأوامر للمسح، وما إلى ذلك.

أعتقد أنه إذا كان المرء قلقًا بشأن جدران الحماية للخادم الخاص بخادم Discourse الخاص به، فإن هذه الموارد والأفكار يجب أن تكون مفيدة للغاية :slight_smile:

3 إعجابات

شيء بسيط، لكن يبدو أن هذا الرابط لا يعمل.

إعجاب واحد (1)

أحدث إصدار LTS من Ubuntu ufw يعطي ALLOW وليس ALLOW IN

لقد كان هذا مزعجًا لمسؤول mail-reciever، حيث فشلت إعدادات واجهة برمجة التطبيقات (API) في ./launcher logs mail-receiver حتى مع فتح المنفذ 25 على ufw.

السماح لجميع الواردات والصادرات ثم رفض المنافذ المطلوبة كان حلاً.

لا أعرف ما يكفي عن iptables لضبطها بشكل أكبر بعد.