Ir al contenido 
Seguridad del gestor de PHP determina hasta qué punto los sitios web están separados entre sí en entornos compartidos y qué superficies de ataque expone un servidor web; en una comparación directa de FPM frente a CGI, el aislamiento de procesos, los derechos de usuario y los límites duros son los factores más importantes. Demuestro por qué el FPM con pools dedicados reduce el riesgo, mientras que el CGI clásico proporciona un aislamiento estricto pero genera latencia y carga de CPU debido a los elevados gastos generales.
Puntos centrales
- Aislamiento determina la superficie de ataque y los riesgos entre cuentas.
- Piscinas FPM separar a los usuarios, establecer límites y proteger los recursos.
- CGI aísla fuertemente, pero cuesta CPU y tiempo por petición.
- OPcache necesita segmentos de almacenamiento separados para cada cuenta.
- alojamiento compartido se beneficia de instancias FPM dedicadas.
Cómo los gestores de PHP configuran la seguridad
Cada manejador conecta el servidor web y el intérprete PHP, pero el Ejecución mod_php carga PHP directamente en el proceso del servidor web; esto proporciona velocidad, pero comparte el mismo contexto de usuario y aumenta el riesgo de alojamiento. CGI inicia un nuevo proceso por petición bajo el usuario de destino, lo que mantiene los derechos limpiamente separados, pero con una sobrecarga notable. FastCGI mantiene los procesos vivos y reduce los costes de arranque, pero sólo FPM proporciona el control fino que exigen las modernas configuraciones multiusuario. Yo prefiero FPM porque permite pools separados, UIDs separados y límites estrictos por cuenta sin perder eficiencia.
FPM vs CGI: delimitación de la seguridad en la vida cotidiana
En una comparación directa, CGI separa estrictamente, pero FPM continúa la separación. permanente y mantiene baja la latencia. Los pools de FPM se ejecutan bajo el usuario de la cuenta correspondiente, aíslan las rutas y encapsulan los recursos; de este modo, un exploit en el sitio A impide el acceso al sitio B. También limito el efecto de los scripts defectuosos con memory_limit, max_execution_time y request_terminate_timeout. Aunque CGI termina cada proceso después de la petición, malgasta tiempo de CPU iniciando y cargando extensiones constantemente. En entornos compartidos, por tanto, predomina FPM, idealmente como pool dedicado por dominio o proyecto.
Aislamiento en alojamiento compartido: riesgos y soluciones
En los entornos compartidos, la mayor Riesgo de alojamiento, cuando las cuentas comparten recursos o derechos involuntariamente. Los atacantes se centran en permisos de archivos débiles, directorios temporales defectuosos o cachés no separadas. Con pools de FPM dedicados por cuenta, encapsulo procesos, rutas de archivos, registros y segmentos de OPcache. También separo las rutas de carga y evito los ataques de enlaces simbólicos con opciones de montaje restrictivas y modelos de propietario limpios. Varios niveles Aislamiento de procesos con chroot, CageFS o jails reduce significativamente el impacto de una intrusión porque el atacante no puede llegar al sistema anfitrión.
Gestión de recursos: pools, límites y tiempos de espera
FPM gana puntos porque puedo dirigir los recursos asignar y así frenar el mal uso. Utilizo pm.max_children para limitar los procesos PHP simultáneos, mientras que pm.max_requests reinicia los trabajadores de larga vida después de X peticiones para evitar fugas de memoria. request_terminate_timeout acaba con los cuelgues que de otro modo inmovilizarían la RAM y protege contra ataques de frenado. Para las subidas, establezco post_max_size y upload_max_filesize para que se ejecuten los flujos de trabajo normales, pero no se acepten archivos gigantescos. En combinación con cgroups para CPU y RAM en todo el sistema, el host sigue respondiendo incluso durante los picos de carga.
Rendimiento y seguridad en una comparación de cifras
Una comparación directa de los manipuladores revela las diferencias prácticas tangible. Utilizo el siguiente resumen para tomar decisiones y calibrar expectativas. Los valores describen tendencias típicas en configuraciones reales y muestran por qué FPM es la primera opción en escenarios de alojamiento compartido. CGI prioriza la dureza a través del reinicio, FPM equilibra el aislamiento y la velocidad, LSAPI brilla con las pilas LiteSpeed. Sigue siendo importante: El aislamiento sin límites es de poca ayuda, como lo son los límites sin aislamiento.
| manipulador | Actuación | Seguridad | Consumo de RAM | Aislamiento | Ideal para |
|---|---|---|---|---|---|
| mod_php | Alta | Bajo | Bajo | Bajo | Sitios pequeños y sencillos |
| CGI | Bajo | Alta | Alta | Alta | Pruebas, separación estricta |
| FastCGI | Medio | Medio | Medio | Medio | Fase de transición |
| PHP-FPM | Muy alta | Alta | Bajo | Alta | Alojamiento compartido, CMS |
| suPHP | Bajo | Muy alta | Alta | Muy alta | Máxima seguridad de los archivos |
| LSAPI | Muy alta | Medio | Muy bajo | Medio | Alto tráfico con LiteSpeed |
De esta yuxtaposición extraigo una clara ConsecuenciaPara un alojamiento multiusuario, FPM ofrece la mejor seguridad global por unidad de rendimiento. CGI sigue siendo una opción para casos especiales con máxima separación y pocas peticiones. Evito mod_php en entornos con varios clientes. LSAPI merece consideración cuando se usa LiteSpeed y la RAM es extremadamente escasa. En la mayoría de los escenarios, sin embargo, las ventajas de pools de FPM separados con límites claros superan las desventajas.
Trampas de configuración: valores predeterminados seguros para pilas FPM
Muchos robos se deben a Mala configuración, no mediante hazañas exóticas. Para mí hay dos interruptores obligatorios: pongo cgi.fix_pathinfo=0, para evitar los recorridos PATH_INFO, y limitar con seguridad.limitar_extensiones las terminaciones de los ejecutables (por ejemplo .php,.php8,.phtml). En las configuraciones de Nginx, compruebo que NOMBRE_DE_SCRIPT está configurado correctamente y no se cuelan peticiones a rutas arbitrarias. También desactivo funciones poco utilizadas como exec, shell_exec, proc_open y popen a través de desactivar_funciones. Esto no es una panacea, pero reduce significativamente el efecto de simples webshells. open_basedir Yo lo uso muy selectivamente: puede ayudar, pero fácilmente conduce a efectos secundarios con trabajos CLI, bibliotecas de manipulación de imágenes o Composer. Es mejor una separación consistente de rutas por cuenta y derechos de propietario limpios.
Aislar correctamente sesiones, cargas y directorios temporales
Común Trayectorias temporales son un clásico para la Escalada de Privilegios. Para cada pool de FPM defino session.save_path y upload_tmp_dir en un directorio específico de la cuenta por debajo del home, con derechos restrictivos y sticky bit sólo cuando sea necesario. noexec, nodev y nosuid en los montajes reducen la superficie de ataque de otros niveles. Para la GC de sesión establezco session.gc_probability/gc_divisor para que los archivos en de la cuenta se pueden envejecer y eliminar; rechazo los buckets de sesión globales entre usuarios. Cualquiera que utilice Redis para sesiones separa estrictamente los espacios de nombres y asigna credenciales y límites separados para cada cuenta. Esto evita que el código defectuoso afecte a las sesiones de otros proyectos.
Diseño de zócalos, autorizaciones y endurecimiento de systemd
Los pools de FPM se comunican a través de sockets. Prefiero Enchufes UNIX para la comunicación local y colocarlos en un directorio específico de la cuenta con 0660 y grupo adecuado. Global 0666-sockets son tabú. Alternativamente, yo sólo uso TCP con Bind en 127.0.0.1 o en una interfaz interna y cortafuegos. A nivel de servicio systemd de forma fiable: NoNewPrivileges=true, ProtectSystem=estricto, ProtegerInicio=true, PrivateTmp=true, CapacidadBoundingSet= (vacío), límites para MemoryMax, CPUQuota, TareasMax y LimitNOFILE. Esto elimina muchas vías de escalada, incluso si una vulnerabilidad de aplicación web es golpeada. También coloco los grupos en sus propios segmentos para silenciar a los vecinos ruidosos y hacer cumplir los presupuestos.
CLI, cron y queue worker: el mismo aislamiento que en la web
A menudo Blindspot: php-cli no se ejecuta a través de FPM. Por lo tanto, inicio cronjobs, indexadores y trabajadores de cola explícitamente como usuario de la cuenta asociada y utilizo un php.ini por proyecto (o php_value-overrides), los límites, extensiones y open_basedir-equivalentes. Los trabajadores de cola (por ejemplo, de CMS y frameworks comunes) reciben los mismos presupuestos de RAM/CPU que los procesos web, incluida una estrategia de reinicio en caso de fugas. Para trabajos recurrentes, establezco límites de backoff y tasa para que un importador de feeds defectuoso no bloquee el host. La paridad es importante: lo que está prohibido en el pool web no debería permitirse de repente en el CLI.
Registro, registros lentos y contrapresión
La visibilidad determina la rapidez con la que reconozco un ataque o una mala configuración. Para cada pool, escribo mi propio Registros de errores y activa request_slowlog_timeout terciopelo slowlog, para obtener las trazas de pila de los cuelgues. log_limit evita que las solicitudes individuales inunden los registros. Con pm.status_path y un punto final de ping, controlo los procesos, los tiempos de espera y la utilización. A nivel de servidor web, configuro Límites de tarifa, La base de reglas WAF también puede interceptar vectores de ataque triviales. Una base de reglas WAF también puede interceptar vectores de ataque triviales; sin embargo, sigue siendo crucial que FPM mantenga pequeña la superficie de ataque por cuenta y que los límites surtan efecto de forma fiable.
Separar limpiamente versiones y extensiones multi-PHP
Especialmente en el alojamiento compartido, varios Versiones PHP en paralelo. Mantengo mis propios binarios FPM, extensiones y configuraciones listas para cada versión y las enlazo por cuenta a. Los sockets terminan en directorios separados para que ninguna petición se dirija accidentalmente al pool equivocado. OPcache permanece separado para cada versión y cada cuenta; revalidar_frecuencia y validar_marcas_de_tiempo en función de la estrategia de lanzamiento. Tengo cuidado con el JIT: Rara vez acelera las cargas de trabajo típicas del CMS y aumenta la complejidad; desactivarlo suele ser la opción más segura y estable. Cargo mínimamente las extensiones; todo lo que no es absolutamente necesario (p. ej. pdo_mysql frente a los conductores no utilizados), se queda fuera.
Modelo de amenaza: vectores de ataque típicos e influencia del manipulador
En la práctica, siempre veo los mismos patrones: subidas de archivos con terminaciones ejecutables, deserialización insegura, suciedad, etc. PATH_INFO-forwarding, inclusión de archivos locales y trucos de symlink. FPM no resuelve esto automáticamente, pero limita el alcanceUn grupo comprometido sólo ve su propio espacio de nombres. Con seguridad.limitar_extensiones y una correcta configuración del servidor web, evito que las subidas de imágenes se interpreten como PHP. Las rutas temporales y de sesión separadas evitan las sesiones entre cuentas y las carreras de archivos temporales. Junto con permisos de archivo restrictivos, umask y noexec-la tasa de éxito de los exploits simples disminuye notablemente.
Conceptos de derechos de archivo, máscara de usuario y propiedad
Los sistemas de archivos siguen siendo Vulnerabilidad, si los permisos están configurados incorrectamente. Yo uso umask para regular los permisos por defecto para que las subidas no terminen siendo globalmente escribibles. suPHP o FPM con la asignación correcta de UID/GID aseguran que el propietario del script coincide con el propietario del archivo. Esto evita que un proceso de terceros modifique archivos o lea registros. También bloqueo las rutas sensibles, establezco noexec en los montajes /tmp y reduzco la superficie de ataque separando sistemáticamente las rutas de lectura y escritura.
Utilizar OPcache con seguridad
El almacenamiento en caché aporta velocidad, pero sin una separación limpia crea memoria compartida Efectos secundarios. Para los pools de FPM, mantengo OPcache separado para cada cuenta para que las claves y el código no se solapen. Activo validate_timestamps en modo desarrollo y sólo lo bajo en producción para despliegues estables para que los cambios de código surtan efecto correctamente. Además, sólo compruebo file_cache dentro del directorio home de la cuenta, no globalmente. Si usas memoria compartida, deberías usar la opción Riesgos de la memoria compartida y limitar estrictamente la visibilidad.
Combinaciones de servidores web: Apache, Nginx, LiteSpeed
La elección de la interfaz influye en la latencia, los apretones de manos TLS y la gestión de las solicitudes. notable. Apache con mpm_event armoniza bien con FPM si keep-alive y proxy buffer son correctos. Nginx antes de FPM convence con activos estáticos y puede desplazar la carga, mientras que PHP sólo recibe rutas dinámicas. LiteSpeed con LSAPI ofrece sobrecargas muy bajas, pero sigue ligado a un ecosistema diferente. Lo siguiente se aplica en cada pila: separar los pools de FPM limpiamente, definir límites, monitorizar los logs y configurar conscientemente las capas de caché.
Endurecimiento: chroot, CageFS y Jails
Además de los manejadores, el aislamiento del sistema operativo determina el Efecto de una intrusión. Con chroot, CageFS o Jails, bloqueo la cuenta en su propio universo de sistema de archivos. Esto significa que un atacante pierde el acceso a los binarios del host y a las rutas sensibles de los dispositivos. Combinado con FPM por cuenta, esto crea una defensa multicapa que también es efectiva contra las debilidades de los plugins en los sistemas CMS. Si desea comparar opciones, puede encontrar Comparación de gestores PHP valiosa orientación para clasificar las pilas.
Contenedores, SELinux/AppArmor y expectativas realistas
y marcos MAC como SELinux o AppArmor complementan eficazmente el FPM. La contenedorización ayuda a vincular las dependencias por proyecto y a limitar el acceso al sistema de archivos raíz. Mantengo las imágenes al mínimo, elimino las capacidades innecesarias y sólo monto los directorios que realmente se necesitan. Los perfiles SELinux/AppArmor restringen las llamadas al sistema y evitan que un proceso opere fuera de su contexto. Sigue siendo importante: Los contenedores no sustituyen al aislamiento FPM ni a los permisos de archivos limpios: forman una capa adicional que intercepta errores, no sustituye a la base.
Lista de control práctica para anfitriones y equipos
En los proyectos, empiezo con una idea clara SecuenciaPrimero separo las cuentas técnicamente, luego despliego pools de FPM por dominio. A continuación, establezco límites realistas, mido los picos de carga y ajusto pm.max_children y pm.max_requests. A continuación, compruebo los permisos de los archivos, aseguro los directorios de carga y elimino los permisos de escritura innecesarios. Configuro OPcache por pool para que el código, las sesiones y las cachés permanezcan aislados. Por último, pruebo la conmutación por error: simulo cuelgues, patrones de DoS y situaciones de falta de memoria hasta que los mecanismos de protección funcionan de forma fiable.
Brevemente resumido
Una cosa es cierta para mí: FPM ofrece la mejor Saldo de seguridad y rendimiento, especialmente al comparar fpm frente a cgi. CGI sigue siendo útil cuando se prioriza la separación absoluta sobre la velocidad, pero FPM alcanza objetivos de seguridad similares con una sobrecarga significativamente menor. Los pools dedicados, los límites estrictos y las cachés separadas reducen significativamente el riesgo de alojamiento en entornos compartidos. Complementado por el aislamiento de procesos, los permisos de archivos limpios y la utilización controlada de OPcache, un host establece los guardarraíles decisivos. La combinación coherente de estos componentes protege eficazmente los proyectos al tiempo que mantiene bajos los tiempos de respuesta.
