En resumen: Quien quiere reforzar su servidor para PHP consigue que una sola vulnerabilidad no abra todo el servidor. Separamos los sitios web entre sí, configuramos PHP y el servidor web de forma segura, limitamos permisos y accesos y documentamos cada cambio. Así el daño es menor si, a pesar de todo, ocurre algo.
Por qué el refuerzo es más importante desde PHP2Shell
PHP2Shell ha mostrado con qué rapidez una vulnerabilidad en el propio PHP se convierte en un problema para todos los sitios web de un servidor. Con CVE-2026-109618 y CVE-2026-109619, los atacantes pueden ejecutar código sin autenticarse. El parche cierra esa puerta. El refuerzo responde a otra pregunta: ¿qué puede hacer alguien que consiga entrar de todos modos, por esta vulnerabilidad o por la siguiente?
En un servidor sin reforzar, todos los sitios web suelen ejecutarse con el mismo usuario, PHP puede ejecutar comandos del sistema y las credenciales están legibles para todos los procesos. Una intrusión en un sitio secundario pequeño llega entonces hasta la tienda online. Un buen refuerzo separa estas áreas. No es una acción puntual, sino un estado básico que debe mantenerse con cada sitio web nuevo y cada cambio de versión.
Reforzar un servidor para PHP: qué ajustamos en concreto
Aislamiento por sitio web
Cada sitio web recibe su propio usuario de sistema y su propio pool de PHP-FPM. Con open_basedir y los permisos de archivos adecuados, una aplicación solo ve su propio directorio. Más información en open_basedir y aislamiento por sitio web.
Configuración segura de PHP
Configuramos php.ini y el pool de modo que las aplicaciones no puedan sobrescribir por sí mismas los valores relevantes para la seguridad. Un extracto de cómo puede verse en un pool de FPM:
; Fijar los valores en el pool de FPM, sin posibilidad de cambio con ini_set()
php_admin_flag[expose_php] = off
php_admin_flag[display_errors] = off
php_admin_flag[log_errors] = on
php_admin_value[open_basedir] = /var/www/kunde1/:/tmp/
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[allow_url_include] = off
Qué funciones pueden bloquearse además depende de la aplicación. Encontrará indicaciones en Configurar php.ini de forma segura y Usar disable_functions correctamente.
Permisos de archivos y acceso de escritura
El servidor web solo puede escribir donde es necesario, por ejemplo en la carpeta de cargas. En los directorios de cargas se impide la ejecución de PHP. El código del programa pertenece a un usuario distinto de aquel con el que se ejecuta PHP. Los principios se explican en Permisos de archivos en el servidor web.
Accesos, servicios y registros
SSH solo con clave, interfaces de administración con autenticación en dos factores, servicios y puertos innecesarios cerrados. Los registros se conservan y se aseguran de modo que sigan existiendo después de un incidente. Comprobamos que las copias de seguridad puedan restaurarse.
Servidor web y cabeceras de seguridad
También el propio servidor web forma parte del refuerzo: ocultar las indicaciones de versión, desactivar los listados de directorios, bloquear el acceso a archivos de configuración, de copias de seguridad y de control de versiones, y proteger además las áreas de administración, por ejemplo con una autorización por IP. Las cabeceras de seguridad como Content-Security-Policy o HSTS protegen en el navegador a los visitantes de su sitio web.
Lo que encontramos con frecuencia en el inventario
Muchas debilidades se repiten de un servidor a otro. Son típicos varios sitios web bajo un usuario común, interfaces de base de datos accesibles públicamente, instalaciones de prueba antiguas en subcarpetas, versiones olvidadas de PHP junto a la actual y copias de seguridad que están en el directorio web y se pueden descargar. Con frecuencia falta además todo registro de inicios de sesión, o los registros se borran a los pocos días.
Ninguno de estos puntos es espectacular por sí solo. Pero, juntos, deciden si una intrusión queda limitada a un sitio web o afecta a todo el servidor.
¿Cómo ayuda PHP SOS en concreto?
- Inventario: registramos el sistema operativo, el servidor web, las versiones de PHP, los sitios web, los usuarios, los servicios abiertos y las copias de seguridad existentes.
- Plan de medidas: recibirá una lista priorizada con el esfuerzo y los posibles efectos de cada punto. Usted decide qué se aplica.
- Aplicación por pasos: modificamos las configuraciones de común acuerdo, probamos los sitios web después de cada paso y dejamos constancia de cómo puede revertirse cada cambio.
- Control: tras la aplicación comprobamos el efecto, por ejemplo si un sitio web ya no puede leer realmente directorios ajenos.
- Entrega: recibirá una documentación del nuevo estado que también podrán seguir su proveedor de hosting o su agencia.
Lo que recibe y lo que necesitamos
Recibirá un informe de refuerzo con la situación de partida, las medidas aplicadas, los puntos dejados abiertos a propósito con su justificación y una recomendación para el control periódico. Los cambios en los archivos de configuración quedan documentados de forma trazable.
De usted necesitamos:
- acceso root o de administrador al servidor y, si hay paneles, además el acceso al panel
- una lista de las aplicaciones y sus particularidades, por ejemplo cargas, interfaces, tareas cron
- una persona de contacto técnica que pueda confirmar las funciones tras los cambios
- ventanas de mantenimiento para los reinicios
- una copia de seguridad actual o el encargo de crear una antes
Lo que no prometemos
El refuerzo no hace que un servidor sea inatacable. Reduce la superficie de ataque y limita los daños, pero no sustituye ni a las actualizaciones ni a la vigilancia. Una versión de PHP sin parchear sigue siendo vulnerable, por muy bien que esté ajustado el resto. Por eso combinamos el refuerzo con el servicio de parcheo de PHP y recomendamos después un seguimiento continuo mediante un contrato de mantenimiento de seguridad.
En el hosting compartido muchas cosas no se pueden ajustar, porque el proveedor de hosting fija la configuración. En ese caso mostramos qué es posible dentro de su paquete y dónde sería razonable pasar a un servidor propio o gestionado.
Preguntas frecuentes
¿Qué significa reforzar un servidor?
Reforzar significa desactivar o limitar todo lo que no es necesario para el funcionamiento. Esto incluye servicios superfluos, permisos demasiado amplios, puertos abiertos y ajustes predeterminados inseguros. El objetivo es que un único fallo no abra de inmediato todo el servidor.
¿Habría evitado el refuerzo PHP2Shell?
No, frente a una vulnerabilidad en el propio PHP solo ayuda el parche. Pero el refuerzo limita lo que un atacante puede conseguir tras una intrusión exitosa, por ejemplo si puede acceder a otros sitios web o a credenciales.
¿Se estropeará mi sitio web con el refuerzo?
El riesgo existe si se cambian ajustes sin probarlos. Aplicamos los cambios por pasos, comprobamos las funciones después de cada uno y dejamos constancia de cómo puede revertirse cada cambio.
¿Con qué frecuencia debe revisarse el refuerzo?
Como muy tarde tras actualizaciones importantes, un cambio de versión de PHP o nuevas aplicaciones en el servidor. Conviene un control periódico dentro del mantenimiento continuo.