كيف يمكن لـ Discourse تجاوز UFW؟ لقد قمت بتمكين المنفذ 22 فقط، لذا يجب أن تكون جميع المنافذ الأخرى مغلقة. لكن المنتدى عمل على أي حال. كيف هذا ممكن؟
قطرة DigitalOcean، ولكن هذا لا ينبغي أن يعني شيئًا. ولا يوجد تثبيت بنقرة واحدة، ولكن بالطريقة الرسمية.
هذا ليس سؤال دعم خالص، ولكن ليس لدينا هنا فئة تسمى أسئلة أساسية غبية من المبتدئين 
إذًا، إذا قمت بتشغيل ufw status verbose، فهل سترى فقط sshd؟
هذا صحيح. وتم تمكين UFW.
ماذا تم إدراجه كافتراضي عند تشغيل ufw status verbose؟
بالنسبة لما أعتقد أنك تريده، أتوقع أن أرى هذا:
الافتراضي: رفض (وارد)، سماح (صادر)، معطل (موجه)
مع السلوك الذي تصفه، أتوقع أن أرى هذا:
الافتراضي: سماح (وارد)، سماح (صادر)، معطل (موجه)
هل جربت فتح المنتدى في نافذة متصفح متخفي أو متصفح مختلف؟ من السهل أن تنخدع بالإصدار المخزن مؤقتًا الذي يظهر. لقد انخدعت بنفسي وجعلت مطورًا آخر يخبرني أن موقع المرحلة يبدو جيدًا بينما لم يكن يعمل على الإطلاق.
فقط 22/tcp (OpenSSH) ALLOW IN Anywhere كما ينبغي. هذان هما الشيئان اللذان أقوم بهما دائمًا: السماح بـ OpenSSH وتمكين UFW.
أفتح المنافذ فقط عند الحاجة، مثل عندما أقوم بتثبيت Nginx. ولكن نظرًا لأن VPS كان مخصصًا لـ Discourse فقط، لم أفعل أي شيء آخر - لقد نسيت UFW تمامًا.
لا يمكن أن يكون هذا هو الحال. كان هذا المنتدى نشطًا لأسابيع.
استيقظت على هذا الموقف عندما قمت بتوصيل Nginx/Varnish بهذا VPS واحتجت إلى فتح منفذ آخر - وأدركت أن المنفذ الوحيد المفتوح كان المنفذ 22.
تعديل:
كيف يمكنني إرسال رسائل البريد الإلكتروني؟ لم يكن المنفذ 587 مفتوحًا أيضًا 
هذا غريب حقًا.
لست متأكدًا مما إذا كنت تقول إن الإعداد الافتراضي هو الرفض أم لا. السبب الذي يجعلني أسأل عن سطر “Default” تحديدًا هو أنه من الممكن أن يكون لديك افتراضي للسماح وتعيين منفذ معين للسماح به، على الرغم من أن الأخير لا يغير شيئًا في هذا الترتيب.
إذا قام شخص آخر بإعداد Discourse، فهل من الممكن أن يكون هذا الشخص قد غير الإعداد الافتراضي إلى السماح بدلاً من السماح بمنافذ HTTP/HTTPS؟
أفترض أن هذا هو SMTP في مكان آخر، وخادم Discourse الخاص بك يتصل بخادم SMTP هذا باستخدام المنفذ 587. يتم السماح بالاتصالات الصادرة على جميع المنافذ افتراضيًا، لذلك لن يعيق UFW إرسال رسائل البريد الإلكتروني ما لم تغير سياسة الصادرة بشكل صريح.
عذري 
Default: deny (incoming), allow (outgoing), deny (routed)
لا. ولكن هل يسمح allow (outgoing) بأي شيء صادر؟ إذا كان الأمر كذلك، فإننا نعود إلى “ليس لدينا هنا فئة تسمى أسئلة أساسية غبية للمبتدئين” وقد تعلمت أشياء جديدة.
تعديل:
ما زلت ضائعًا - ولكن كيف هو deny (incoming)؟
لقد وجدت هذا:
الإجابة المختصرة هي أن Discourse لا يمكنه تجاوز قواعد جدار الحماية الخاص بك والمكان المناسب لطرح الأسئلة الغبية حول الأشياء المتعلقة بنظام التشغيل هو مكان مثل Stack Exchange. (من فضلك لا تعتقد أنني وقح. هناك تكمن تلك الإجابات. بعد تشغيل Linux منذ الإصدارات المبكرة جدًا، ما زلت أذهب إلى أماكن مثل هذه لجميع أسئلتي الغبية. ما زلت أمتلكها!)
أعرف المكان هناك نسبة إشارة إلى ضوضاء عالية جدًا. حسنًا، كانت تلك شخصية غير عادلة، لكنني كنت أعني أنه من الصعب جدًا العثور على أشياء ذات صلة من هناك. إنه ضخم جدًا.
هذا في الواقع سؤال جيد حقًا ولست متفاجئًا من أن لا أحد آخر قد طرحه بعد. الإجابة معقدة، ولكن حتى الآن كانت الردود على هذا الموضوع للأسف سلبية في نبرتها دون الإجابة على السؤال.
ليس الأمر أن Discourse يتجاوز ufw، بل إن docker يتجاوز ufw عن طريق إضافة قواعد تجعل أي منافذ مكشوفة لحاويات docker تعمل على الرغم من وجود ufw.
تصل الحزم الواردة الموجهة إلى حاوية إلى جدول FORWARD، وليس جدول INPUT كما قد يتوقع المرء.
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ufw-before-logging-forward all -- any any anywhere anywhere
0 0 ufw-before-forward all -- any any anywhere anywhere
0 0 ufw-after-forward all -- any any anywhere anywhere
0 0 ufw-after-logging-forward all -- any any anywhere anywhere
0 0 ufw-reject-forward all -- any any anywhere anywhere
0 0 ufw-track-forward all -- any any anywhere anywhere
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
8 416 DOCKER-USER all -- any any anywhere anywhere
8 416 DOCKER-ISOLATION-STAGE-1 all -- any any anywhere anywhere
0 0 ACCEPT all -- any docker0 anywhere anywhere ctstate RELATED,ESTABLISHED
4 256 DOCKER all -- any docker0 anywhere anywhere
4 160 ACCEPT all -- docker0 !docker0 anywhere anywhere
0 0 ACCEPT all -- docker0 docker0 anywhere anywhere
0 0 ufw-before-logging-forward all -- any any anywhere anywhere
0 0 ufw-before-forward all -- any any anywhere anywhere
0 0 ufw-after-forward all -- any any anywhere anywhere
0 0 ufw-after-logging-forward all -- any any anywhere anywhere
0 0 ufw-reject-forward all -- any any anywhere anywhere
0 0 ufw-track-forward all -- any any anywhere anywhere
السبب في وصول الحزم إلى جدول التوجيه هو بسبب القواعد التي يضيفها docker إلى جدول nat:
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
210 12734 DOCKER all -- any any anywhere anywhere ADDRTYPE match dst-type LOCAL
Chain DOCKER (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- docker0 any anywhere anywhere
0 0 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:https to:172.17.0.2:443
107 6848 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:http to:172.17.0.2:80
يتم معالجة nat/PREROUTING قبل اتخاذ القرار بشأن ما إذا كان سيتم إرسال الحزم عبر INPUT أو FORWARD.
في النهاية، تكمن المشكلة في وجود خدمتين على النظام تقوم بتعديل قواعد جدار الحماية. ufw لا يعرف شيئًا عن هذا، لذا يمكنه فقط الإبلاغ عما قام هو بتكوينه.
لحل هذه المشكلة، قم بإعادة تكوين جدار الحماية لتمرير حركة المرور الموجهة إلى docker عبر سلاسل ufw أيضًا:
أستخدم التعديل الطفيف التالي لعملهم، والذي يتم وضعه قبل تمكين ufw:
# مسروق من https://github.com/chaifeng/ufw-docker - يبدو منطقيًا
# إضافة التوجيه إلى ufw-user-input يسمح بالاتصالات
# بالمنافذ الموجهة التي فتحناها صراحةً
cat <<EOUFW >> /etc/ufw/after.rules
# BEGIN UFW AND DOCKER
*filter
:ufw-user-forward - [0:0]
:ufw-user-input - [0:0]
:DOCKER-USER - [0:0]
-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16
-A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN
-A DOCKER-USER -j ufw-user-forward
-A DOCKER-USER -j ufw-user-input
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j RETURN
COMMIT
# END UFW AND DOCKER
EOUFW
شكرا! لقد كان شرحًا كاملاً.
أهلاً بك، هذه هي طريقتي في فعل الأشياء 
تم حل هذا الموضوع، ولكنه كشف عن مشكلة صغيرة جدًا في إعداداتي. سأشرحها إذا بحث شخص ما عن شيء مشابه في المستقبل.
كان لدي خادم افتراضي خاص واحد حيث يتولى Nginx شهادة SSL وبعض الأشياء الأخرى لجميع مواقعي (الكثير من الأشياء، اللغة الإنجليزية لغة غريبة جدًا ). يرسل Nginx الطلبات إلى Varnish. إنه وكيل عكسي عديم الفائدة لـ Discourse، ولكنه يقوم ببعض التصفية. يرسل Varnish الطلبات إلى خادم افتراضي خاص آخر حيث يعيش Discourse باستخدام المنفذ 83. يستمع كلا الخادمين الافتراضيين الخاصين إلى نفس المنفذ ويُسمح به فقط لكلا عنواني IP. كنت سعيدًا تمامًا - حتى الآن.
حاولت معرفة ما يحدث عند استخدام المنفذ 443 curl -I https://forum.example.tld:443. لقد نجحت بشكل جيد، لأن لدي شهادة SSL صالحة لا تزال موجودة على جانب Discourse (لقد قمت بهذا التغيير قبل بضعة أسابيع).
إجابة @supermathie تشرح سبب حدوث ذلك وكيفية إصلاحه. بالتأكيد، لا توجد مشاكل أمنية بسبب ذلك على الإطلاق على حد علمي، ولكنه مزعج حقًا 
واو. هذا جنون! شكراً لك.
أعتقد أنه لا يتم طرحه كثيرًا لأنه ليس من الشائع أن يقوم شخص ما بتثبيت discourse ويريد منه ألا يعمل، لذلك عندما يجعل docker الأمر يعمل بينما قمت بتكوين جدار الحماية بحيث لا ينبغي له ذلك، فإن معظم الناس لا يشتكون.
إنها مشكلة مثيرة للاهتمام للغاية، ولكنها تبدو غريبة بعض الشيء، وليست مشكلة Discourse، بل هي نزوة من نزوات docker. السؤال يدور حول “كيف يمكنني تكوين جدار الحماية الخاص بي لمنع discourse من العمل؟” سأحاول تذكر تلك الأشياء الخاصة بالمسار المسبق.
لو كنت أعرف الإجابة لما كنت متعاليًا! شكرًا لإنقاذ الموقف في هذه المسألة!
لم أحاول بالتأكيد أن أكون مستخفًا، بل أن أستكشف المشكلة… ولكن من الواضح أنني كنت أتصرف من منطلق الجهل بما كان يفعله Docker. كل هذه معلومات مفيدة جدًا، شكرًا على الإجابة!
إذا كان بإمكان صاحب الموضوع أو شخص آخر تغييره، فقد يكون من المفيد تغيير الحل المحدد.
في حين أنها مشكلة تتعلق بـ Docker أكثر، يمكنني رؤية بعض الافتراضات لـ Discourse التي تنبع من هذا. على سبيل المثال، قد يكون لدي خادم مكتبي يمكن الوصول إليه من العالم الخارجي ولكنني أرغب في تكوين UFW لتقييد Discourse بحيث لا يمكن الوصول إليه إلا من داخل المكتب. ستمنع إضافات Docker هذا الإعداد.
على الرغم من أنني في هذا السيناريو المحدد سأقوم بإعداده على جدار حماية للأجهزة/المشرف الافتراضي بدلاً من UFW على المضيف على أي حال.
لقد جئت للتو إلى نفس مستودع git الذي وجدته، وأبحث في مشكلة ufw/docker، مما جعلني أفكر في هذا الموضوع.
ما الذي قمت بتغييره بالضبط (أعني، يمكنني رؤية الأسطر المضافة، ولكن ماذا يعني ذلك؟)، وهل هذه التغييرات خاصة بـ Discourse؟
لقد استخدمت الكود الافتراضي في المستودع وبدت مشكلة UFW الخاصة بي وكأنها تم إصلاحها بعد ذلك.
تحرير: عندما أستخدم الكود المعدل الخاص بك، في اللحظة الأولى التي أقوم فيها بتنفيذ ufw reload، أحصل على الخطأ التالي:
خطأ: تعذر تحميل قواعد التسجيل
في الواقع، لقد اكتشفت الأمر بعد فترة وكتبت هذا السكربت Bash للقيام بالمهمة لتثبيتات Discourse.
يقوم بإعادة تعيين جدار الحماية الخاص بك، وتثبيت ufw-docker-util (الذي يعدل after.rules)، ثم يضيف المنفذين 443 و 80 إلى قائمة السماح الخاصة بك. ها هو.
كما أنه يسمح بالمنفذ 22 من أي عنوان IP للتأكد من عدم قفل نفسك. بعد أن يعمل كل شيء، قم بتأمين المنفذ 22 مرة أخرى.
تعديل: يعمل السكربت ولكن إعادة بناء Discourse بعد استخدامه ستفشل:
fatal: unable to access 'https://github.com/discourse/discourse.git/': Could not resolve host: github.com- لذا لا تستخدم السكربت إلا إذا كنت تعرف كيفية حل هذه المشكلة.
تعديل 2: يعمل على Ubuntu، ولكنه لا يعمل على CentOS!
في المرة الأخيرة التي قمت فيها بكتابة نص باش، قمت بتغيير مالك جميع الدلائل إلى www-data:www-data - لذا بالنسبة لي، فإن جزءًا من العمل كهذا يجعل الحياة أسهل قليلاً
ولكن بشكل عام - أود أن أرى دوكر يتبع UFW/iptables بالكامل. فقط لأنني أستخدم حظر GeoIP عبر ipables (نعم، أعرف - UFW هو مجرد واجهة مستخدم بسيطة لـ iptables).
بالتأكيد، نحن لسنا في Discourse بعد الآن، ولكن هنا يمكننا أن نرى لماذا لا يستطيع المبرمجون والمستخدمون النهائيون فهم بعضهم البعض دائمًا بشكل جيد: يرى المبرمجون العالم ككتل منطقية وبناء جملة إذا/ثم/غير ذلك، بينما يراه المستخدمون النهائيون في سياق كامل. المعنى - لأنني أستخدم Discourse، حتى لو كان يعمل داخل دوكر، من وجهة نظري فإن Discourse هو الذي لا يتبع قواعدي 
يجب أن يذهب هذا إلى Praise ولكنني غيرت عنوان المنتدى قبل بضعة أسابيع. وحصلت على جميع أنواع المتسللين في العالم وروبوتات تحسين محركات البحث عديمة الفائدة لزيارته. حصلت على 3000 وكيل مستخدم مختلف في الساعة على خادم VPS بسعة 2 جيجابايت / 1 وحدة معالجة مركزية من DigitalOcean ولم يهتم Discourse بذلك. أي تثبيت ووردبريس سيكون بطيئًا / معطلاً بعد هذا النوع من الاندفاع المشابه لـ ddos.
لذلك، لا أحتاج حقًا إلى إجبار Discourse (حسنًا، دوكر) على اتباع الحظر بواسطة Fail2ban وقواعدي - ولكني أكره تلك الروبوتات بعمق.