Gunicorn: القدرة على إخفاء سمة خادم رأس استجابة http

عادةً ما يتم نشر Gunicorn خلف خادم وكيل عكسي مثل nginx في بيئة الإنتاج ، وسوف ينتج nginx علامة Server .

الطابق العلوي زائد واحد

مع benoitc يمكننا اقتراح خيار في سطر الأوامر ، ما رأيك؟ خلاف ذلك ، سنغلق هذه التذكرة كما هو موضح من قبل

لا يمكن لأحد فقط تعديل البيئة في ربط post_request ؟

tilgovi الذي سيعمل على ما أعتقد ... لست متأكدًا مما إذا كنا بحاجة إلى إنشاء خيار آخر ...

لا يعمل. تم إرسال الطلب بالفعل في تلك المرحلة.

لن تعمل tilgovi الوسيطة أيضًا ، لأن Server موجود في الرؤوس الافتراضية.

ماذا لو أزلنا رأس الخادم تمامًا؟

+1

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

+1

لماذا تريد إزالة الرأس؟

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

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

أخذت حريتي في إنشاء علاقات عامة لهذه الميزة: # 1384. لقد كان على قائمة المطلوبين لبعض الوقت.

للإضافة إلى المناقشة: أود أن أزعم أنه بينما تقوم بعض خوادم الوكيل العكسي بتعديل رأس Server ، يضيف البعض رأس Via كما هو موضح في https://www.w3.org/Protocols/ rfc2616 / rfc2616-sec14.html # sec14.38

لسوء الحظ ، أغلق mathiasverhoeven علاقاته العامة لسبب ما ولم يكن لديه أي نشاط مؤخرًا.

هل سيكون من المستحيل أن يكون لديك خيار أكثر عمومية هنا ، كما هو الحال في --set-headers حيث يمكنك تحديد أي كمية من الرؤوس كأزواج مفتاح-قيمة؟ القيمة الفارغة ستهمل العنوان تمامًا.

في الوقت الحالي ، أود تعديل Server ، لكني أرغب أيضًا في إضافة رأس استجابة آخر ، على سبيل المثال X-Product: MyProduct .

يمكنني رمي شيء معًا بناءً على العلاقات العامة mathiasverhoeven . benoitc و tilgovi ما رأيك؟

فقط سأترك هذا هنا: https://www.fastly.com/blog/headers-we-dont-want. كما يمكنك أن تقرأ في المقالة ، فإن العنوان Server شائع جدًا وغير ضروري على الإطلاق.

أود أيضًا أن أتمكن من حذف رأس الخادم. أستخدم خادم ويب يركز على الأمان يسمى Hiawatha لعكس الخادم الوكيل ، مع عدم إضافة رأس خادم خاص به ، لذلك يقوم رأس خادم gunicorn حاليًا بجعله للعملاء.

فكرة tuukkamustonen تبدو جيدة بالنسبة لي. :)

تحرير: شاهدت للتو https://github.com/benoitc/gunicorn/pull/1617. server_tokens = true|false|string سيكون رائعًا.

أي شخص يشغل القارورة؟ https://stackoverflow.com/a/46858238/452210 يقترح التفاف وتجاوز process_response ، استبدال أو إزالة الرأس.

أود أيضًا أن أتمكن من حذف رأس الخادم. أستخدم خادم ويب يركز على الأمان يسمى Hiawatha لعكس الخادم الوكيل ، مع عدم إضافة رأس خادم خاص به ، لذلك يقوم رأس خادم gunicorn حاليًا بجعله للعملاء.

لقد لاحظت أنه حتى Cloudflare تعرض رأس خادم ، لذلك لست متأكدًا هذه الأيام من أن الأمر يتعلق بالأمان أكثر من الشهرة.

أعتقد أنه بدلاً من إضافة خيار آخر إلى سطر الأوامر أو التكوين ، سأقوم ببساطة بإزالة الإصدار من العنوان للبدء. ثم قم بإضافة ملف تكوين فقط الإعداد لإزالة server_token. ميزة ذلك هو أن الخادم الذي يقوم بالترقية بأمان إلى الإصدار الجديد سيكون قادرًا على إضافة هذا الإعداد دون إيقاف الخدمة. أفكار؟

لقد لاحظت أنه حتى Cloudflare تعرض رأس خادم ، لذلك لست متأكدًا هذه الأيام من أن الأمر يتعلق بالأمان أكثر من الشهرة.

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

أعتقد أنه بدلاً من إضافة خيار آخر إلى سطر الأوامر أو التكوين ، سأقوم ببساطة بإزالة الإصدار من العنوان للبدء. ثم قم بإضافة ملف تكوين فقط الإعداد لإزالة server_token. ميزة ذلك هو أن الخادم الذي يقوم بالترقية بأمان إلى الإصدار الجديد سيكون قادرًا على إضافة هذا الإعداد دون إيقاف الخدمة. أفكار؟

هذا سيكون رائع. : +1:: ابتسامة طفيفة:

نعم يرجى إزالة الإصدار على الأقل. لا يضيف الإصدار أي شيء إلى الشهرة ويوفر الكثير من الوقت للمهاجمين.

أنا أفكر في إزالة الإصدار فقط. tilgovi أي أفكار حول ذلك؟

جيد بالنسبة لي!

أي تقدم في هذا؟ هذا يبدو وكأنه فوز سريع للأمن.

سيكون هذا جزءًا من 20.1 القادمة

أنا أفكر في إزالة الإصدار فقط.

هل لا يزال إعداد ملف التكوين فقط لإزالة رأس الخادم بالكامل مخططًا؟

DavidOliver لماذا السؤال؟

benoitc يمكن تفسير تعليقك الذي نقلته على أنه يعني أنه "فقط" / فقط رقم الإصدار الذي ستتم إزالته ، بينما في وقت سابق في المحادثة ، كان الإعداد لإزالة رأس الخادم تمامًا (وهو ما أود القيام به) قيد النظر.

شكرا.

إذا كان بإمكاننا إزالة رأس الخادم تمامًا ، فيجب علينا القيام بذلك.

ما زلت مقتنعًا بأن إزالته لها علاقة بـ
الأمان. لم يكن مشكلة في السنوات العشر الماضية. الأمن بواسطة
الغموض لا يساعد أيضًا ، أفضل معرفة أن لدينا مشكلة و
اصلحه. يمكن أن تساعد معرفة الخادم أيضًا في العمليات

أنا أميل إلى إزالة الإصدار في الوقت الحالي لأن هذا الإصدار يعطي
الكثير من المعلومات حول كيفية صيانة الخادم. يجب أن نفعل ذلك من أجل
كل فرع حافظنا عليه.

أفكار؟

بينوا

في الأحد 29 ديسمبر 2019 الساعة 04:23 ، كتب Randall Leeds [email protected] :

إذا كان بإمكاننا إزالة رأس الخادم تمامًا ، فيجب علينا القيام بذلك.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/benoitc/gunicorn/issues/825؟email_source=notifications&email_token=AAADRIQBGN2KQRKOKLAYK43Q3AJ2PA5CNFSM4ASCOWF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAADRISEUFGD43CKXLV3EZTQ3AJ2PANCNFSM4ASCOWFQ
.

>

مرسلة من هاتفي المحمول

مرحبا،

أنا أستخدم gunicorn لخدمة الاستجابات عبر اتصال حيث البيانات
باهظ الثمن ، أي شيء يمكنني إزالته هو أي شيء لست مضطرًا لدفعه.

رأس الخادم صغير ، لكن الأشياء الصغيرة تضيف أحيانًا
تعني الأشياء الصغيرة أنه يمكنك وضع كل شيء في حزمة أقل من واحد:
يبلغ رأس الخادم بالإصدار 24 بايت ، أي حوالي 1.7٪ من الحمولة
مع MSS من 1460 ورؤوس TLS. حتى بدون الحزمة الإضافية ،
من المرجح أن تحتاج الحزمة الأكبر إلى الاستياء تمامًا
عندما يكون الاتصال سيئًا (مثل شبكة خلوية في مكان بعيد).

على اتصال HTTPS جديد ، المصافحة والشهادة
الصرف جعل معظم الحمولة ويمكن أن تكون الأشياء الصغيرة
تجاهله. بالنسبة للطلبات الصغيرة المتكررة ، استخدم حفظ ، فائض عن الحاجة
تصبح الرؤوس جزءًا أكبر بكثير من الطلب / الاستجابة.

قد يكون هذا مهمًا أيضًا للأشخاص الذين يهتمون أكثر بالعميل
الأداء (الكمون أكثر من الإنتاجية) من التكلفة.

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

يقتصر هذا التعليق في الغالب على إضافة مرجع / مواصفات / معلومات RFC ذات صلة ، و (نأمل) في الغالب تفسير / تعليق غير معروف.

بروتوكول نقل النص التشعبي RFC7231 (HTTP / 1.1): الدلالات والمحتوى https://tools.ietf.org/html/rfc7231#section -7.4.2

... قد يقوم الخادم الأصلي بإنشاء حقل خادم في استجاباته.

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

https://tools.ietf.org/html/rfc7231#section -9.6

9.6 الإفصاح عن معلومات المنتج
غالبًا ما تكشف حقول رأس وكيل المستخدم (القسم 5.5.3) وعبر (القسم 5.7.1 من [RFC7230]) والخادم (القسم 7.4.2) معلومات حول أنظمة برامج المرسل المعني. من الناحية النظرية ، يمكن أن يسهل ذلك على المهاجم استغلال الثغرات الأمنية المعروفة ؛ في الممارسة العملية ، يميل المهاجمون إلى تجربة جميع الثغرات المحتملة بغض النظر عن إصدارات البرامج الظاهرة المستخدمة. يجب أن تتخذ الوكلاء الذين يعملون كبوابة عبر جدار حماية شبكة احتياطات خاصة فيما يتعلق بنقل معلومات الرأس التي قد تحدد المضيفين خلف جدار الحماية. يسمح حقل رأس Via للوسطاء باستبدال أسماء الأجهزة الحساسة بأسماء مستعارة.

من (موقوف) RFC2616:

15.1.2 نقل المعلومات الحساسة
مثل أي بروتوكول عام لنقل البيانات ، لا يمكن لـ HTTP تنظيم محتوى البيانات التي يتم نقلها ، ولا توجد أي طريقة مسبقة لتحديد حساسية أي جزء معين من المعلومات في سياق أي طلب معين. لذلك ، يجب أن توفر التطبيقات أكبر قدر ممكن من التحكم في هذه المعلومات لموفر تلك المعلومات. تستحق أربعة حقول رأس جديرة بالذكر في هذا السياق: الخادم ، وعبر ، والمراجع ، ومن.
قد يؤدي الكشف عن إصدار البرنامج المحدد للخادم إلى السماح لجهاز الخادم بأن يصبح أكثر عرضة للهجمات ضد البرامج المعروفة باحتوائها على ثغرات أمنية. يجب على المنفذين أن يجعلوا حقل رأس الخادم خيارًا قابلاً للتكوين.

PEP3333 Python Web Server Gateway Interface v1.0.1 https://www.python.org/dev/peps/pep-3333/#the -start-response-callable

بشكل عام ، يكون الخادم أو البوابة مسؤولاً عن ضمان إرسال الرؤوس الصحيحة إلى العميل: إذا أغفل التطبيق رأسًا مطلوبًا بواسطة HTTP (أو المواصفات الأخرى ذات الصلة السارية) ، فيجب على الخادم أو البوابة إضافته. على سبيل المثال ، تاريخ HTTP: and Server: عادةً ما يتم توفير الرؤوس بواسطة الخادم أو البوابة.

• يعتبر عنوان استجابة الخادم اختياريًا وفقًا لـ HTTP 1.1
• يتعرف RFC على أن حقول الخادم شديدة التفصيل يمكن أن تسهل فحص المواقع بحثًا عن الخوادم المعرضة للخطر. من الواضح أن هذا يعد شرطًا أصعب بخطوة واحدة ، والغموض ، ومقدار التفاصيل أكثر من اللازم هو ظرفية.
• تم إيقاف HTTP 1.1 RFC2616 أكثر جرأة في قيمة إخفاء رأس الخادم.
• يبدو أن PEP3333 يتجاوز قليلاً عند ذكر رأس الخادم في سياق الرؤوس المطلوبة أو العادية.

الكثير من الآراء حول هذا ، كما هو الحال في Apache HTTPD ServerTokens : https://httpd.apache.org/docs/2.4/mod/core.html#servertokens

لا يوصى بتعيين ServerTokens على أقل من الحد الأدنى لأنه يزيد من صعوبة تصحيح مشكلات التشغيل البيني. لاحظ أيضًا أن تعطيل Server: header لا يفعل شيئًا على الإطلاق لجعل الخادم أكثر أمانًا. إن فكرة "الأمن من خلال الغموض" خرافة وتؤدي إلى شعور زائف بالأمان.

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

أشخاص مثل @ kmichel-sereema ، الذين يرغبون في تحسين حجم كل عملية نقل ، أعتقد أن هذا ليس المكان المناسب لإجراء مثل هذا التحسين الجزئي. إذا كانت رؤوس HTTP كبيرة جدًا ، فإن HTTP 1.x ليس البروتوكول المثالي للاستخدام ، ولا أعتقد أنه يجب علينا إضافة تكوين إضافي للسماح بتغيير رأس الخادم أو تعطيله.

يبدو اقتراح tilgovi بمثابة حل وسط جيد بالنسبة لي.

في العديد من البيئات قد يكون هذا موضع نقاش. توصي مستندات نشر برنامج Gunicorn بوجود خادم وكيل مثل nginx أمام برنامج Gunicorn. يقوم nginx تلقائيًا بإزالة

باتباع اقتراحي وتعليقاتي من tilgovi & jamadden أقوم بإغلاق هذا الإصدار لصالح # 2233. شكرا لكم جميعا على الكود والتعليقات!