¿Qué recomienda para configurar un servidor compartido con php [cerrado]?

Question

¿Qué recomienda para configurar un servidor compartido con php desde un punto de vista de seguridad / rendimiento?

• Apache mod_php (¿cómo se asegura eso? aparte de safe_mode, ya que no estará en PHP6)
• Apache CGI + suexec
• Lighttpd y genera un FastCGI por usuario

LE: No estoy interesado en usar un panel de control ya creado, ya que estoy intentando escribir el mío, así que quiero saber cuál es la mejor manera de configurarlo yo mismo. Estaba pensando en usar Lighttpd y generar un fastcgi para cada usuario alojado que hace que el proceso fcgi se ejecute bajo sus credenciales (hay un tutorial para esto en lighttpd wiki). Esto sería algo seguro, pero ¿afectaría esto al rendimiento (muchos usuarios / memoria necesaria para cada fcgi) tanto que no sea una solución viable?

Answer 1

Personalmente, mientras que Lighttpd está bien, iría con Nginx + FastCGI si terminas con un servidor web ligero + solución FastCGI. He ejecutado puntos de referencia y he leído todo el código, y Nginx es un orden de magnitud más rápido / más estable bajo carga, es muy bueno.

Pero, eso no es lo que pediste. Básicamente, diría que hay un espectro de compensación / seguridad en comparación con la velocidad en las tres opciones que enumera, y solo tiene que decidir dónde quiere estar. Si usted es un proveedor de alojamiento compartido con usuarios que no son de confianza y que están instalando las aplicaciones de PHP, Dios sabe qué se inclinará más hacia la seguridad, si esto se comparte entre los usuarios más confiables, podría inclinarse hacia el rendimiento. Aquí están mis pensamientos:

CGI + suexec: Este es, con mucho, el más seguro y escalable en términos de número de usuarios / sitios en un entorno de alojamiento compartido. Los procesos se generan y la memoria se utiliza solo cuando llegan las solicitudes. Por supuesto, el desarrollo CGI hace que este sea el más lento para el tiempo de ejecución de los scripts individuales. ¿Cuánto más lento? Bueno, tendrías que hacer un punto de referencia, pero en general si la gente está ejecutando aplicaciones de larga duración (es decir, algo como WordPress, que tarda 0.25-0.5 segundos en cargar sus archivos e inicializarse en cada solicitud), la penalización de generación de CGI comienza a verse bastante bonita. insignificante en contexto.

FastCGI: El problema aquí (y no importa si su servidor web es Apache, Lighttpd o Nginx) es averiguar cuántos procesos secundarios de FCGI permite que cada usuario deje de funcionar, porque cada proceso come memoria igual al tamaño del intérprete de PHP (en Linux no todo está cableado, por supuesto, pero estoy divagando). Y, a diferencia de mod_php, estos procesos no se comparten entre los usuarios, por lo que tiene que limitarlos por usuario. Por ejemplo, Dreamhost limita esto a 3 para sus clientes; ahora, para un cliente que ejecuta un sitio web que recibe ráfagas de más de 2 a 5 páginas vistas por segundo, eso es bastante malo porque esas solicitudes solo se acumulan y el sitio se bloquea. Ahora, me gusta FastCGI con un servidor web liviano cuando ejecuto aplicaciones en un servidor / clúster dedicado , cuando puedo dar a la aplicación cientos de niños FCGI (todos con privilegios de servidor web, por supuesto, & # 224 ; la Apache / prefork + mod_php). Pero, no creo que tenga sentido para el alojamiento compartido, donde tiene que asignar / limitar los hijos FCGI por usuario.

Apache + mod_php: Menos seguro ya que todo funciona con servidores web, pero su conjunto de procesos PHP en vivo se comparte, por lo que es mejor para el rendimiento. Desde la perspectiva del desarrollador, no puedo tolerar el modo php_safe, y desde la perspectiva del administrador del sistema es solo una ilusión de seguridad (mitiga a los usuarios estúpidos pero no protege de un ataque real), así que en realidad preferiría tener CGI si mi otra opción tiene que incluir safe_mode.

Dreamhost hace una especie de híbrido, lo hace de Apache CGI + suexec de forma predeterminada, pero permite que el (pequeño) porcentaje de sus usuarios más sofisticados elija FCGI si lo desea, sujeto a un límite y su propio monitoreo. de uso de la memoria. Eso ahorra una tonelada de recursos de memoria en lugar de habilitar FCGI para todos de forma predeterminada.

Otro problema si está hablando de alojamiento compartido comercial estándar es, Apache tiene todas las funciones, tiene módulos para casi cualquier cosa (incluyendo cosas como mod_security que pueda desear), y a sus usuarios les gustará porque todos sus .htaccess las configuraciones funcionarán, etc. - tendrá problemas de soporte con cualquier otra cosa cuando instalen Drupal o WordPress o lo que sea (mucho menos de un problema si estamos hablando de usuarios internos).

Personalmente, recomendaría que sea sencillo comenzar y comenzar con CGI + suexec para la mejor seguridad y capacidad de ampliación. Si sus usuarios desean FCGI o mod_php y tiene un buen canal abierto para sugerencias / comunicación con ellos, lo solicitarán, pero cualquiera de estos son un dolor de cabeza mucho mayor con solo mejoras de rendimiento marginal para ellos, así que mi sugerencia sería no hacer ninguno de los dos inicialmente, pero responder si lo reclaman.

Simpatizo con el deseo de hacer algo " interesante " como Lighttpd + FCGI en lugar del Apache + CGI + suexec estándar, pero en el fondo no puedo recomendarlo.

Si está ejecutando varios servidores, podría terminar poniendo CGI en algunos y algo más para los usuarios avanzados en los demás. ¡Y asegúrese de tener cron grep en todos los directorios de www para cosas como las versiones antiguas de phpBB!

Answer 2

Recomiendo Suhosin

Answer 3

Con respecto a PHP + FastCGI y la seguridad, verifique esta publicación del blog .

  

El reto con asegurar un compartido.   servidor de alojamiento es cómo asegurar la   sitio web de ataque tanto desde el   Por fuera y por dentro. PHP tiene   características incorporadas para ayudar, pero   en última instancia, es el lugar equivocado para   abordar el problema.

     

Ya he escrito sobre una serie de   Soluciones que funcionan, pero una opción.   Me han preguntado una y otra vez para   mira está usando PHP + FastCGI. los   La creencia es que el uso de FastCGI hará   superar los problemas de rendimiento de   Suexec o mod_suphp de Apache, porque   Los procesos FastCGI persisten entre páginas.   vistas.

     

Pero antes de que podamos ver el rendimiento,   La primera pregunta es: ¿cómo hacer exactamente   tenemos PHP y FastCGI corriendo como   diferentes usuarios en un servidor web   en primer lugar?

Answer 4

He estado usando InterWorx desde hace aproximadamente un año y estoy muy impresionado. Mantiene un servidor LAMP con chroots para tus scripts para la seguridad.

También he usado Ensim , pero no lo he encontrado tan fácil, rápido y no lo he encontrado. Tiene tantas características. Además, cuesta mucho más.