تكوين جدار حماية لـ Discourse

It’s unclear if Linux distributions really “need” a firewall – but we have found that the following Uncomplicated Firewall rules work fine with a standard Docker based Discourse install:

ufw allow http
ufw allow https
ufw allow ssh
ufw enable

That is, allow HTTP (port 80), HTTPS (port 443), and SSH (port 22), and nothing else.

Check the current status of your firewall with

ufw status verbose

Sample output:

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)

And if you ever want to turn it off

ufw disable

A firewall should not matter if you are using a default Docker install of Discourse, for the same reason almost no Linux distribution ships with a firewall enabled by default.

But if you have somehow installed extra services that talk to the outside world, adding a firewall gives you “belt and suspenders” security, if that is of interest to you.

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 لضبطها بشكل أكبر بعد.