الموقع قابل للوصول عبر عنوان IP عند عدم اتباع دليل التثبيت

[markersocial]

لأغراض الأمان، أعتقد أنه سيكون من الأفضل إذا لم تكن منتديات Discourse مرئية افتراضيًا عند التنقل مباشرة إلى عنوان IP في المتصفح.

بعض الأسباب:

• يسمح باستخدام الموقع بدون HTTPS، للمستخدمين وكذلك للإعداد الأولي من قبل المسؤول.
• يكشف عنوان الخادم الأصلي، وهو أمر سيء إذا كنت تستخدم Cloudflare أو ما شابه لحماية عنوان IP الأصلي من هجمات DDoS أو محاولات اختراق الخادم، خاصة إذا اعتبر المخترقون الخادم ذا قيمة عالية. هناك أشخاص يديرون برامج روبوتات تفحص جميع نطاقات عناوين IP المملوكة لموفري خدمات الاستضافة.

أيضًا، يقوم الآن مثبت Discourse بتأكيد أن النطاق أو النطاق الفرعي مُهيأ بشكل صحيح، وإلا فلن يستمر في التثبيت.

كل ما يحتاج إلى إضافته في أسفل ملف /etc/nginx/conf.d/discourse.conf (داخل حاوية Docker) هو:

server {
    listen 80;
    server_name 1.1.1.1;
    server_tokens off;
    return 404;
}

حيث أن 1.1.1.1 هو عنوان IP العام الخاص بخادمك. ربما توجد طريقة أكثر أناقة لتضمين عنوان IP بدلاً من كتابته بشكل ثابت. جربت عدة طرق لكن لم أستطع جعلها تعمل.

يعمل هذا بشكل جيد بالنسبة لي (بما في ذلك عند استخدام وسيط Cloudflare)، ولا أستطيع التفكير في حالات كثيرة حيث يكون السماح بالوصول المباشر عبر IP مفيدًا أو ضروريًا. يبدو أن منع هذا الأمر ممارسة شائعة إلى حد ما. يسعدني سماع أي أسباب لعدم القيام بذلك!

[Falco]

@markersocial

يسمح باستخدام الموقع بدون HTTPS، للمستخدمين وكذلك للإعداد الأولي من قبل المسؤول.

لماذا نجري أي تغيير عندما يتركك دليلنا الافتراضي بموقع يعمل حصريًا عبر HTTPS؟

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

[neounix (Dark Matter)]

@فالكو، مشاركة: 2، موضوع: 156214

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

شكرًا جزيلاً!

[markersocial]

@Falco

لماذا إجراء أي تغيير عندما يتركك دليلنا الافتراضي بموقع يعمل حصريًا عبر HTTPS؟

من الناحية الموضوعية، هذا غير دقيق. الموقع ليس حصريًا عبر HTTPS، حيث يمكنك الوصول إليه مباشرةً عبر عنوان IP الذي لا يستخدم HTTPS.

الفرق يكمن في منع الاتصال غير الآمن دون استخدام HTTPS وتجنب كشف عنوان IP الأصلي للخادم. ولا أدرك أي فوائد لذلك.

إذا قمت بإجراء بحث DNS لأهم 50 موقعًا في العالم، سيبدو وكأنه لا يمكن الوصول إلى أي منها بشكل غير آمن مباشرةً عبر عنوان IP. ولا أعتقد أنه من غير المعقول افتراض أن أهم 50 موقعًا في العالم يتبعون أفضل الممارسات.

إليك قائمة دقيقة جدًا لأهم المواقع:

Top Websites Ranking - Most Visited Websites In The World | Similarweb

إليك أداة بحث DNS:

Network Tools: DNS,IP,Email

[Falco]

@markersocial

بشكل موضوعي، هذا غير دقيق. الأمر ليس حصريًا على HTTPS، إذ يمكنك الوصول إلى الموقع مباشرة عبر عنوان IP الذي لا يستخدم HTTPS.

بشكل افتراضي، سيؤدي محاولة الوصول عبر عنوان IP إلى إرجاع إعادة توجيه 301 إلى النطاق الصحيح:

$ curl 159.203.68.6 -I
HTTP/1.1 301 Moved Permanently
Server: nginx/1.16.1
Date: Mon, 29 Jun 2020 20:24:41 GMT
Content-Type: text/html
Content-Length: 169
Connection: keep-alive
Location: https://falcoland.falco.dev/

@markersocial

كل ما يحتاج إلى إضافته في أسفل ملف /etc/nginx/conf.d/discourse.conf (داخل حاوية docker) هو:

server {
    listen 80;
    server_name 1.1.1.1;
    server_tokens off;
    return 404;
}

هل مقترحك هو التغيير من 301 إلى 404؟

[markersocial]

من أصل 8 تثبيتات، تم تثبيت جميعها باستخدام صورة Digital Ocean، حيث تم تثبيت Communiteq (المعروفة سابقًا باسم DiscourseHosting) ثم نقلها، وكذلك تم التثبيت يدويًا باستخدام هذا الدليل discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub. جميعها قابلة للوصول بشكل غير آمن عبر عنوان IP افتراضيًا. تم تثبيت اثنتين منها خلال الأسبوع الماضي (باستخدام دليل GitHub المذكور أعلاه).

هل هناك خطوة إضافية ربما أغفلتها؟ أعتقد أن رسالة خطأ 404 أفضل من إعادة التوجيه 301، خاصةً أن معظم الأشخاص الذين يتصفحون عناوين IP على الأرجح لا ينوون شيئًا جيدًا. لكن إعادة التوجيه 301 أفضل من الوصول غير الآمن.

[codinghorror (Jeff Atwood)]

لا يوجد تكرار…

http://38.242.24.122 يعيد توجيهي بشكل صحيح إلى https://discourse.codinghorror.com/

[markersocial]

هه، ربما يكون قالب كلاودفلير. هذا على الأرجح هو الاختلاف الوحيد المتسق مع التثبيت العادي تمامًا بين جميعها.

[Stephen]

إذا اتخذت خطوات غير مدرجة في تثبيت السحابة، فإنه ليس بحكم التعريف “تثبيتًا خامًا”.

قالب Cloudflare لا يقوم بأي شيء واضح يتعارض مع إعادة التوجيه:

run:
  - file:
      path: /tmp/add-cloudflare-ips
      chmod: +x
      contents: |
        #!/bin/bash -e
        # Download list of CloudFlare ips
        wget https://www.cloudflare.com/ips-v4/ -O - > /tmp/cloudflare-ips
        wget https://www.cloudflare.com/ips-v6/ -O - >> /tmp/cloudflare-ips
        # Make into nginx commands and escape for inclusion into sed append command
        CONTENTS=$(</tmp/cloudflare-ips sed 's/^/set_real_ip_from /' | sed 's/$/;/' | tr '\n' '\\' | sed 's/\\/\\n/g')
        
        echo CloudFlare IPs:
        echo $(echo | sed "/^/a $CONTENTS")
        # Insert into discourse.conf
        sed -i "/sendfile on;/a $CONTENTS\nreal_ip_header CF-Connecting-IP;" /etc/nginx/conf.d/discourse.conf
        # Clean up
        rm /tmp/cloudflare-ips

  - exec: "/tmp/add-cloudflare-ips"
  - exec: "rm /tmp/add-cloudflare-ips"

فهو يجلب نطاقات عناوين IP، ويخزنها مؤقتًا باسم cloudflare-ips، ويضيف دعمًا لـ CF-Connecting-IP

[markersocial]

صحيح. لم ادّعِ أنها “تثبيتات قياسية”.

لذلك جربت حذف قالب Cloudflare الرسمي على أحد هذه التثبيتات ثم إعادة بنائه، لكن للأسف لم يحدث أي فرق. لا يزال يمكن الوصول إليه بشكل غير آمن عبر عنوان IP.

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

[neounix (Dark Matter)]

ليس الأمر خاصًا بأي إعداد معين أو بـ Cloudflare، بل هو مجرد نقطة بيانات ورؤية أخرى:

يمكننا إعداد وكيل (proxy) لإعادة توجيه “عنوان IP عاري على المنفذ 80” (كمثال) إلى أي اسم نطاق كامل (FQDN) آخر بعدة طرق باستخدام كل من Apache2 وNginx.

هناك طرق عديدة للقيام بذلك (إعادة كتابة وإعادة توجيه، استضافة افتراضية وإعادة توجيه، إلخ).

على سبيل المثال، يمكننا إنشاء استضافة افتراضية على وكيل عكسي يستمع إلى عنوان IP على المنفذ 80، وإعادة توجيه جميع تلك الطلبات إلى أي FQDN (أو عنوان IP) نختاره.

كما يمكننا القيام بذلك باستخدام وكيل عكسي مع mod_rewrite في Apache2 وقواعد إعادة الكتابة في Nginx.

في جميع إعدادات Discourse لدينا (في العمليات)، نستخدم وكيلًا عكسيًا أمام Discourse (بعضها Apache2 وبعضها Nginx)، ومن السهل التخفيف من هذه الأنواع من المشكلات (عند ظهورها) عن طريق تكوين الوكيل العكسي للتعامل مع هذه القضايا والحالات الخاصة.

ومع ذلك، لا أستخدم الحالة الخاصة لـ Cloudflare كوكيل، لكن يبدو أن أي وكيل يمكن تكوينه لإدارة هذه الأنواع من المشكلات، تمامًا كما يمكن تكوين أي وكيل عكسي لإعادة توجيه “تقريبًا أي شيء إلى أي شيء آخر”.

إذا انتقلنا خطوة إلى الأمام، فلو كنت مستخدمًا تجاريًا لخدمة وكيل (مثل Cloudflare) ولدي عنوان IP أو اسم نطاق محدد أرغب في إعادة توجيهه (أو حجب توجيهه)، فسأقوم بتكوين (أو طلب) من الوكيل (في هذه الحالة Cloudflare) لإعادة توجيه “عنوان IP العاري على المنفذ 80” إلى FQDN (أو أي مكان آخر) أختاره.

هذا النوع من الأمور صُممت الوكالات للتعامل معه (بشكل افتراضي)؛ وكما ذُكر، فإن هذا النوع من إعادة التوجيه سهل التنفيذ باستخدام Apache2 أو Nginx، لذا أفترض (ولست مستخدمًا لـ Cloudflare) أن خدمة تجارية مثل Cloudflare يمكنها إدارة هذا النوع من إعادة التوجيه التافهة بسهولة.

[elijah (Eli the Bearded)]

@markersocial

حيث أن 1.1.1.1 هو عنوان IP العام لخادمك. ربما توجد طريقة أكثر أناقة لتضمين عنوان IP بدلاً من كتابته بشكل ثابت. جربت عدة طرق لكن لم أتمكن من جعلها تعمل.

أنا أستخدم هذا لإرشاد البوتات التي تستهدف الموقع عبر عنوان IP الخام إلى صفحة خاصة:

server {
        listen 80;
        # listen [::]:80;

        server_name ~^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+;

        root /var/www/ip-address;
        default_type text/plain;
        index nothing.doing;
        location / {
                try_files $uri /nothing.doing;
        }
}

لكنني أتفق مع الآخرين في أنني لا أستطيع إعادة إنتاج الوصول عبر عنوان IP لم forum الخاص بي أيضًا. أحصل على إعادة التوجيه. وليس لدي أي إعدادات خاصة، ولا أستخدام لـ Cloudflare، وأنا أعمل فعليًا على خادم افتراضي مجاني تمامًا (بدون تكلفة شهرية) لا يقدم أي ميزات إضافية.

[michaeld (Michael - Communiteq)]

@markersocial

لا أعتقد أنه من غير المعقول افتراض أن أفضل 50 موقعًا في العالم يستخدمون أفضل الممارسات.

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

@markersocial

Communiteq (سابقًا DiscourseHosting) تم تثبيتها (ثم نقلها)

النقل لا ينسخ أي إعدادات لـ nginx، لذا فإن ذلك في الواقع هو مجرد تثبيت جديد.

[markersocial]

رائع، شكرًا لمشاركة هذا المقطع @elijah، نقدر ذلك! سأستبدل عنوان IP الثابت بـ regex الخاص بك، أو سأستخدم المقطع الكامل.

[markersocial]

@michaeld

لكن إذا فكرت في الأمر، قد تدرك أن جميعها تمتلك إعدادات موازنة الحمل على بنية تحتية تكلف (عشرات) الملايين من الدولارات. لذا فهي ليست ممثلة أيضًا.

نعم، هذا يشير إلى أن هذه المواقع على الأرجح غير قابلة للاستخدام عبر الويب بأي عنوان IP مباشر. على أي حال، لا يبدو أن أحدًا يدعم السماح بالوصول غير الآمن عبر عنوان IP مباشر على الويب.

@michaeld

الهجرة لا تنسخ أي إعدادات nginx، لذا فإن ذلك في الواقع هو تثبيت جديد.

نعم، أنت محق.

[markersocial]

لقد اختبرت للتو تشغيل نسختين من Discourse على Digital Ocean باستخدام تطبيق سوقهم الخاص لإطلاقها بسرعة.

أردت اختبار ذلك مع إعداد مخصص شبه معدوم، فقط بتعديل smtp و dev email و discourse_hostname بتفاصيل وهمية (للسماح بإعادة البناء).

توقفت أداة التثبيت بسبب أن النطاق/النطاق الفرعي الوهمي الذي قمت بإعداده لم يجتز خطوة التحقق من النطاق (وتوصي بتعديل ملف app.yml يدوياً ثم إعادة البناء).

بعد تعديل ملف app.yml وإعادة البناء (smtp و dev email و discourse_hostname فقط)، أصبح الموقع متاحاً بشكل غير آمن على عنوان IP دون أي تدخل من Cloudflare. ولم يعاد توجيهه إلى discourse_hostname المحدد.

معظم عمليات التثبيت الخاصة بي لم تستخدم تطبيق سوق Digital Ocean للإعداد، بل تم إجراؤها يدوياً باستخدام دليل تثبيت Docker القياسي.

لاحظ أن توقف أداة التثبيت بسبب عدم القدرة على التحقق من النطاق حدث أيضاً في عمليتي تثبيت حديثتين استخدمتا Cloudflare، ربما بسبب التوجيه الوسيط. أما باقي عمليات التثبيت فقد تمت قبل إضافة خطوة التحقق من النطاق في أداة التثبيت.

تعديل: لاحظ أن عمليتي تثبيت من أصل 8 عمليات تثبيت لـ Discourse فقط واجهتا أي مشكلة في التحقق من النطاق أثناء التثبيت الأولي (دون احتساب نسختي الاختبار المذكورتين أعلاه). تقترح سكريبت إعداد Discourse على المستخدم تعديل ملف app.yml يدوياً وإعادة البناء عند حدوث خطأ في التحقق من النطاق. لا مشكلة إذا لم يكن هذا مفيداً، فهذا لم يكن حلاً لي.

تعديل: بشكل عام نستخدم SSL المرن من Cloudflare، وليس letsencrypt (الذي سيكون أفضل). شكراً @neounix.

[neounix (Dark Matter)]

للعلم @markersocial

جميع تثبيتات Discourse لدينا تعيد توجيه http://the.ip.add.res إلى https://FQDN المُعرَّف عبر تفعيل LETSENCRYPT في ملف حاوية Discourse .yml.

لكي تعمل كل هذه الأمور بشكل صحيح ولتعمل شهادات LETSENCRYPT، تحتاج إلى تكوين SSL كامل وصحيح (عادةً باستخدام LETSENCRYPT)، كما تعلم بالتأكيد بالفعل.

فقط تذكير… آمل أن يكون هذا مفيدًا.

[Falco]

@markersocial

يتوقف المثبت بسبب النطاق/النطاق الفرعي غير الصحيح الذي قمت بإعداده، حيث لا يمر بخطوة التحقق من النطاق (ويوصي بتعديل ملف app.yml يدويًا ثم إعادة البناء).

Vanilla يتطلب نطاقًا صالحًا ويستخدم سكريبت إعداد Discourse.

إذا لم تفعل أيًا من ذلك، فلا يُتوقع أن تكون النتيجة مختلفة.

هذا الموضوع لا يحتوي على معلومات قابلة للتنفيذ، ولا يمكننا إعادة إنتاج المشكلة إذا تم اتباع التعليمات.