Cómo proteger Apache y PHP en un servidor de producción

Apache y PHP pueden funcionar correctamente y, al mismo tiempo, estar mal aislados. En servidores con varias aplicaciones, el riesgo más frecuente no es un fallo sofisticado, sino que una web comprometida pueda leer configuraciones, sesiones o archivos de otra.

Separación por aplicación

La medida con mayor impacto es ejecutar cada sitio con un usuario propio y un pool PHP-FPM independiente. El DocumentRoot debe contener únicamente archivos públicos. Configuración, sesiones, copias, registros y secretos deberían quedar fuera de la carpeta servida por Apache.

Una estructura razonable es:

/var/www/cliente/public
/var/www/cliente/config
/var/www/cliente/storage
/var/www/cliente/logs

Apache apunta a public; PHP puede acceder a los directorios privados estrictamente necesarios.

Permisos y escritura

El código no debería ser escribible por el proceso web salvo durante despliegues controlados. Los directorios de subida sí necesitan escritura, pero deben impedir la ejecución de PHP y otros intérpretes. Comprueba propietarios, grupos y modos después de cada actualización.

Evita permisos 777. Si una aplicación solo funciona con permisos globales, el problema debe resolverse identificando el usuario real del proceso y concediendo únicamente el acceso necesario.

PHP-FPM y límites

Configura un pool por web con usuario, grupo, límites de procesos y registro propio. open_basedir puede reducir el alcance de accesos accidentales, aunque no debe considerarse una frontera de seguridad completa. También conviene limitar tamaño de subida, tiempo de ejecución y memoria según la función del sitio.

En producción, desactiva la presentación pública de errores:

display_errors = Off
log_errors = On

Los errores deben registrarse en un archivo no accesible desde la web. Mostrar rutas internas, consultas SQL o trazas facilita el reconocimiento de la aplicación.

Cabeceras de seguridad

Las cabeceras deben adaptarse al funcionamiento real. Algunas habituales son:

• X-Content-Type-Options: nosniff
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy para desactivar capacidades no utilizadas.
• Content-Security-Policy para limitar scripts, estilos, imágenes y conexiones.
• Strict-Transport-Security cuando todo el dominio funciona de forma estable por HTTPS.

Una CSP demasiado abierta apenas protege; una CSP demasiado restrictiva rompe funciones. Empieza en modo de informe, identifica dependencias y reduce orígenes gradualmente.

Directorios sensibles

Bloquea el acceso HTTP a archivos como .env, .git, copias, SQL, registros, configuraciones y archivos temporales. No confíes únicamente en nombres poco evidentes. Las copias deben estar fuera del árbol público.

Deshabilita el listado de directorios y revisa que Apache no entregue archivos con extensiones de respaldo.

TLS y redirecciones

Fuerza HTTPS de forma consistente, revisa que no existan recursos mixtos y automatiza la renovación de certificados. Después de cambiar dominios o certificados, comprueba tanto la conexión directa como las redirecciones.

Separación de bases de datos

Cada aplicación debería tener su propio usuario SQL con permisos limitados a su base. No utilices una cuenta administrativa desde el código web. La base de datos debe escuchar en una interfaz local o privada si no necesita acceso externo.

Registros y observabilidad

Separa los logs de acceso, errores y PHP-FPM por sitio. Añade identificadores de petición cuando sea posible. Esto permite saber qué aplicación originó un error y facilita detectar exploraciones, respuestas 500 o patrones anómalos.

Lista de comprobación

• DocumentRoot limitado a archivos públicos.
• Usuario Linux y pool PHP-FPM por aplicación.
• Código no escribible por el proceso web.
• Subidas sin ejecución de scripts.
• Errores ocultos al visitante y registrados internamente.
• Base de datos local y usuario con mínimo privilegio.
• HTTPS, cabeceras y CSP verificadas.
• Copias y archivos SQL fuera del árbol público.

Conclusión

La seguridad de Apache y PHP depende más del aislamiento y de los permisos que de una directiva aislada. Diseñar la estructura correctamente desde el principio evita que una vulnerabilidad en una web se convierta en un compromiso completo del servidor.

Este contenido es informativo y está orientado a administración defensiva, auditorías autorizadas y mejora de la seguridad. Adapta cualquier cambio a tu entorno y conserva una copia de seguridad antes de aplicarlo.