ما الذي تنصح به لإعداد خادم مشترك باستخدام PHP [مغلق]

Question

ما الذي تنصح به لإعداد خادم مشترك باستخدام PHP من وجهة نظر الأمان/الأداء؟

• Apache mod_php (كيف يمكنك تأمين ذلك؟بخلاف الوضع الآمن لأنه لن يكون موجودًا في PHP6)
• أباتشي CGI + suexec
• Lighttpd وينتج FastCGI لكل مستخدم

جنيه:لست مهتمًا باستخدام لوحة تحكم تم إنشاؤها بالفعل لأنني أحاول أن أكتب لوحتي الخاصة، لذا أريد أن أعرف ما هي أفضل طريقة لإعداد ذلك بنفسي.كنت أفكر في استخدام Lighttpd وإنشاء fastcgi لكل مستخدم مستضاف يجعل عملية fcgi تعمل بموجب بيانات اعتماده (يوجد برنامج تعليمي لهذا على lighttpd wiki).قد يكون هذا آمنًا إلى حد ما ولكن هل سيؤثر ذلك على الأداء (الكثير من المستخدمين/الذاكرة اللازمة لكل fcgi) لدرجة أنه ليس حلاً قابلاً للتطبيق؟

Answer 1

شخصيًا، على الرغم من أن Lighttpd لا بأس به، إلا أنني سأختار Nginx + FastCGI إذا انتهى بك الأمر باستخدام خادم ويب خفيف الوزن + حل FastCGI.لقد قمت بتشغيل المعايير وقرأت كل التعليمات البرمجية، وكان Nginx أسرع/أكثر استقرارًا تحت التحميل - إنه جيد جدًا.

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

CGI + suexec: يعد هذا هو الأكثر أمانًا والأكثر كفاءة/قابلية للتوسع بالنسبة لك من حيث عدد المستخدمين/المواقع في بيئة الاستضافة المشتركة.يتم إنشاء العمليات واستخدام الذاكرة فقط عند ورود الطلبات.بالطبع، يجعل نشر CGI هذا هو الأبطأ من حيث وقت تنفيذ البرامج النصية الفردية.كم أبطأ؟حسنًا، سيتعين عليك قياس الأداء، ولكن بشكل عام إذا كان الأشخاص يشغلون تطبيقات طويلة الأمد (على سبيل المثال،شيء مثل WordPress والذي يستغرق من 0.25 إلى 0.5 ثانية فقط لتحميل libs الخاص به والتهيئة عند كل طلب)، ثم تبدأ عقوبة نشر CGI في الظهور بمظهر ضئيل جدًا في السياق.

فاست سي جي آي: تكمن المشكلة هنا (ولا يهم إذا كان خادم الويب الخاص بك هو Apache أو Lighttpd أو Nginx) في معرفة عدد عمليات FCGI الفرعية التي تسمح لكل مستخدم بتركها قيد التشغيل، لأن كل عملية تستهلك ذاكرة تساوي حجم مترجم PHP (في نظام التشغيل Linux ليس كله سلكيًا بالطبع، لكنني أستطرد).وعلى عكس mod_php، لا تتم مشاركة هذه العمليات بين المستخدمين لذا يتعين عليك تحديد عدد لكل مستخدم.على سبيل المثال، يضع Dreamhost حدًا أقصى لذلك عند 3 لعملائه - الآن، بالنسبة للعميل الذي يدير موقع ويب يحصل على دفعات من أكثر من 2-5 مشاهدات للصفحة في الثانية، يعد هذا في الواقع أمرًا سيئًا للغاية لأن هذه الطلبات تتراكم ويتوقف الموقع.الآن، أحب FastCGI مع خادم ويب خفيف الوزن عندما أقوم بتشغيل التطبيقات على جهاز مخلص الخادم/المجموعة، عندما يمكنني منح التطبيق مئات من أطفال FCGI (جميعهم مزودون بخادم الويب الخاص بالطبع، على غرار Apache/prefork + mod_php).لكنني لا أعتقد أنه من المنطقي الاستضافة المشتركة حيث يتعين عليك تخصيص/تحديد عدد أطفال FCGI لكل مستخدم.

أباتشي + mod_php: الأقل أمانًا نظرًا لأن كل شيء يعمل مع خصوصيات خادم الويب، ولكن تتم مشاركة مجموعة عمليات PHP المباشرة الخاصة بك، لذا فهي الأفضل من حيث الأداء.من وجهة نظر المطورين، لا يمكنني تحمل وضع php_safe، ومن وجهة نظر مسؤول النظام، فهو في الواقع مجرد وهم للأمان (إنه يخفف من المستخدمين الأغبياء ولكنه لا يحمي من هجوم فعلي) لذا أفضل استخدام CGI إذا كان لدي يجب أن يتضمن الخيار الآخر الوضع الآمن.

يقوم Dreamhost بنوع من الهجين، فهم يقومون بـ Apache CGI + suexec افتراضيًا، لكنهم يسمحون للنسبة المئوية (الصغيرة) من المستخدمين الأكثر تطورًا باختيار تنفيذ FCGI إذا أرادوا ذلك، مع مراعاة الحد الأقصى ومراقبة استخدام الذاكرة الخاصة بهم .وهذا يوفر الكثير من موارد الذاكرة مقابل تمكين FCGI للجميع بشكل افتراضي.

هناك مشكلة أخرى إذا كنت تتحدث عن الاستضافة المشتركة التجارية القياسية، وهي أن Apache كامل الميزات، ويحتوي على وحدات لأي شيء تقريبًا (بما في ذلك أشياء مثل mod_security التي قد ترغب فيها)، وسيحبها المستخدمون لأن جميع تكوينات .htaccess الخاصة بهم ستعمل إلخ.- سوف تواجه مشاكل في الدعم مع أي شيء آخر عندما يذهبون لتثبيت Drupal أو WordPress أو أي شيء آخر (أقل مشكلة بكثير إذا كنا نتحدث عن المستخدمين الداخليين).

أنا شخصياً أوصي بإبقاء الأمر بسيطًا للبدء باستخدام CGI + suexec للحصول على أفضل أمان وقابلية للتوسع.إذا كان المستخدمون لديك يريدون FCGI أو mod_php ولديك قناة جيدة مفتوحة للاقتراحات/التواصل معهم، فسوف يطلبون ذلك، ولكن أيًا منهما يمثل صداعًا أكبر بكثير بالنسبة لك مع تحسينات هامشية فقط في الأداء لهم، لذا اقتراحي سيكون عدم القيام بأي منهما في البداية ولكن الاستجابة إذا طالبوا بذلك.

أنا أتعاطف مع الرغبة في القيام بشيء "مثير للاهتمام" مثل Lighttpd + FCGI بدلاً من Apache + CGI + suexec القياسي، لكنني في أعماقي لا أستطيع أن أوصي به حقًا.

إذا كنت تقوم بتشغيل عدة خوادم، فقد ينتهي بك الأمر إلى وضع CGI على بعضها وشيء آخر للمستخدمين المتميزين على الآخرين.وتأكد من حصولك على cron grep لجميع مواقع www الخاصة بأشياء مثل الإصدارات القديمة من phpBB!

Answer 2

أوصي سوهوسين

Answer 3

فيما يتعلق بـ PHP + FastCGI والأمن، تحقق هذا بلوق وظيفة.

The challenge with securing a shared hosting server is how to secure the website from attack both from the outside and from the inside. PHP has built-in features to help, but ultimately it’s the wrong place to address the problem.

I’ve already written about a number of solutions that work, but one option I’ve been asked time and time again to look at is using PHP + FastCGI. The belief is that using FastCGI will overcome the performance issues of Apache’s suexec or mod_suphp, because FastCGI processes persist between page views.

But before we can look at performance, the first question is: how exactly do we get PHP and FastCGI running as different users on the one web server in the first place?

Answer 4

لقد كنت استخدم InterWorx لمدة عام تقريبًا وقد أعجبت كثيرًا.إنه يحتفظ بخادم LAMP الذي يقوم بتجذير البرامج النصية الخاصة بك من أجل الأمان.

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