¿ProxyPass es más seguro que alojar directamente el sitio PHP?

Dependería de su modelo de amenaza, "¿seguro contra qué "?

La mayoría de las vulnerabilidades de las aplicaciones (lado PHP) no están relacionadas con el servidor web o la arquitectura; serán causadas por solicitudes HTTP normales y legales que son ilegales o no planificadas en la capa de aplicación de PHP. P.ej. el clásico

GET /...login.php?user=' OR 1=1;&pass=

En contra de este amplio espectro de posibles ataques, hay poco que el módulo Apache o NginX pueden hacer por usted, y no hay ninguna razón real para elegir el uno sobre el otro.

Luego existe la posibilidad de atacar directamente a el servidor HTTP . No es muy probable (aunque puede suceder) que una solicitud falsificada contra la que Apache es vulnerable pueda pasar a través de NginX sin sufrir daños, y mucho menos que se vuelva a formatear como letalidad para Apache por parte de NginX. Entonces podemos asumir razonablemente que en la estructura de NginX fastcgi, NginX es el único punto vulnerable a tales ataques.

Entonces, creo que NginX debería proporcionar una capa adicional de seguridad, si se ejecuta en una máquina propia , con monitoreo adecuado y privilegios reducidos (de los cuales NginX necesitaría mucho menos que PHP) .

Luego, atacar el sistema provocaría que NginX se subvirtiera y se bloqueara (o se traicionara a la supervisión), y se detuviera el ataque; o dejar la casilla NginX comprometida y abierta al atacante.

En este último caso, no es peor que con PHP directamente expuesto, en lo que respecta a su aplicación; en ambos casos no hay nada entre usted y una caja controlada por un atacante (solo que ahora está operando desde una caja desconocida, y hay un poco de consuelo allí).

En lo que respecta al resto del mundo, ahora las cosas son posibles (y usted podría ser responsable de ellas) que no existían antes: por ejemplo, el propósito del atacante podría no ser comprometer su aplicación en absoluto. pero solo para obtener un punto de apoyo en la máquina NginX para operar como la pata de un zombi o gato contra otra parte. En este escenario, realmente ha aumentado su superficie de ataque: un atacante en busca de NginX vulnerables no habría tenido ninguna razón para atacar una instalación de PHP.

Si NginX se ejecuta en la misma máquina que la aplicación PHP, el riesgo general aumenta. En otra máquina, diría que el riesgo ... cambia , tanto en tipo como en nivel.

Si se protege adecuadamente, puede disminuir; y puede obtener algunos beneficios de poder hacer malabares con diferentes opciones de configuración rápida o diferentes máquinas para distribuir la carga con facilidad. Si no también supervisa y mantiene el cuadro de NginX, es decir, si no aumenta la superficie y el costo de mantenimiento, el riesgo puede aumentar nuevamente.

Entonces, a lo que se reduce todo esto, no se trata tanto de NginX en comparación con el módulo de Apache, sino de qué implementación (y mantenimiento) NginX versus qué implementación (y mantenimiento) de Apache ) .

Todos los demás son iguales (es decir, el mismo nivel de costo y esfuerzo, solo con Apache o compartido entre PHP y NginX), prefiero que las cosas sean sencillas y mi ataque sea pequeño, y ir con el módulo de apache. Si piensa que podría beneficiarse del equilibrio de carga en el futuro y está dispuesto a asumir los costos adicionales, NginX sería una opción adecuada ahora.

nginx es joven y hasta ahora ha tenido un horrible historial de seguridad . Es más probable que nginx sufra otra vulnerabilidad crítica más que un HTTPD más experimentado como Apache o incluso IIS (¡jadeo!).