CageFS por sitio: nueva arquitectura de seguridad para el alojamiento compartido

CageFS por sitio Separa estrictamente los distintos sitios web dentro de una cuenta de alojamiento compartido, lo que limita el riesgo de propagación lateral tras un ataque. Te explicaré la nueva arquitectura de seguridad, te mostraré ejemplos prácticos de uso y te explicaré cómo puedes gestionar de forma segura varios proyectos en una misma cuenta.

Puntos centrales

• Aislamiento de sitios web: Una separación adicional dentro de una misma cuenta reduce los riesgos colaterales.
• CloudLinux: Ampliación del concepto CageFS a nivel de dominio.
• WordPress: Ejecutar varias instancias de forma segura en paralelo.
• Recursos: Los límites de CPU, RAM y E/S complementan la separación de vistas de archivos.
• Práctica: Activación por dominio y una estrategia clara de derechos y rutas.

Qué ofrece concretamente „Per-Site CageFS“

La extensión aísla cada uno de los Dominios dentro de un CageFS de usuario ya existente, para que cada sitio web solo vea sus propios archivos y procesos. De este modo, evito que un proyecto comprometido pueda acceder a los archivos de configuración, las subidas o las claves de otros sitios que se encuentren en la misma cuenta. Según CloudLinux El blog (anuncio de la versión beta) explica que CageFS por sitio amplía el aislamiento entre sitios web dentro de una misma cuenta de usuario, reduciendo así el riesgo de movimientos laterales. Para mí, la ventaja es evidente: puedo segmentar claramente las cuentas de la agencia, las configuraciones multisitio y los entornos de prueba sin alterar la estructura de alojamiento. Esta explicación ofrece una visión general rápida del principio de CageFS: Sistema de archivos CageFS, sobre el que se basa el aislamiento por sitio.

Por qué el aislamiento de cuentas por sí solo no es suficiente

Una cuenta suele agrupar varias Proyectos – unas dos tiendas, tres blogs y un entorno de pruebas. Si un exploit ataca un plugin vulnerable, un atacante puede, sin necesidad de segmentación adicional, acceder a los directorios adyacentes y colocar allí más cargas maliciosas. Es precisamente aquí donde Per-Site CageFS aísla el sistema de archivos y los procesos de tal manera que cada sitio web funciona como si estuviera en su propio Cárcel funciona. Especialmente en el caso de instancias independientes de WordPress que comparten un mismo usuario de PHP, de lo contrario se crea una ventana de riesgo de escalada que yo cierro mediante el aislamiento de dominios. Esto reduce los daños derivados, simplifica el análisis forense y permite planificar las recuperaciones con mayor rapidez.

Así funciona técnicamente el aislamiento de sitios web

CloudLinux crea, mediante CageFS, un entorno virtual por usuario sistema de archivos; la capa «Per-Site» amplía esto a los límites del dominio. Cada dominio activado dispone de un espacio de trabajo independiente dentro del CageFS del usuario, que incluye rutas restringidas, directorios temporales propios y ejecución de scripts aislada. De este modo, los archivos wp-config.php, las carpetas de subida o los archivos de claves ajenos desaparecen del ámbito de visión del sitio web atacado. Las tareas cron, PHP y, en su caso, los comandos SSH acceden a las mismas bibliotecas del sistema, pero solo ven los recursos asignados Subconjuntos del sistema de archivos. Según la documentación, la separación se puede activar por dominio, lo que me permite un control muy preciso para las instancias en producción, de prueba y de desarrollo.

Comparación: aislamiento de cuentas, CageFS por sitio y contenedores

Para tomar la decisión de forma estructurada, comparo tres opciones habituales Modelos en función del nivel de aislamiento, el esfuerzo que requiere y la compatibilidad. El aislamiento por cuenta resuelve la separación entre clientes, pero deja abiertas las fronteras internas entre sitios. CageFS por sitio cierra esta brecha desde el punto de vista del sistema de archivos y de los procesos. Los contenedores crean límites estrictos, pero a menudo requieren más mantenimiento y ajustes. Esta guía ofrece una clasificación detallada del aislamiento de procesos: Comparación entre chroot, CageFS y jails.

Acérquese a	Separación entre cuentas	Separación entre sitios web dentro de la cuenta	Compatibilidad (PHP/CGI/SSH/Cron)	Gastos de explotación
Aislamiento de cuentas (clásico)	Alta	Bajo	Muy buena	Bajo
CageFS por sitio	Alta	Media a alta	Muy buena	Bajo a medio
Contenedores por emplazamiento	Muy alta	Muy alta	De bueno a muy bueno	Media a alta

En entornos de alojamiento compartido, CageFS por sitio ofrece una potente combinación de control preciso Separación y requiere pocos cambios, ya que los scripts suelen funcionar sin modificaciones. De este modo, protejo el punto débil más habitual: varios sitios web independientes bajo una única cuenta de usuario.

Práctica: cómo gestionar de forma segura varias instancias de WordPress

Separo cada instancia de WordPress en la que esté activada la Aislamiento de dominios y configuro grupos de PHP-FPM específicos para cada sitio web, de modo que los registros, el opcache y los límites se puedan asignar correctamente. Además, defino SALTs/KEYS específicos para cada sitio web en el archivo wp-config.php y evito cualquier acceso cruzado mediante los permisos de los archivos y los equivalentes de open_basedir. Almaceno las subidas estrictamente dentro de la raíz de documentos correspondiente y prohíbo los directorios globales compartidos para subidas. Durante las implementaciones, mantengo las rutas temporales dentro de cada sitio y elimino inmediatamente los artefactos de compilación, para que no queden puntos vulnerables innecesarios. Para las cachés de Composer o NPM utilizo directorios locales del sitio Directorios, para evitar que se produzcan efectos cruzados.

El rendimiento y la gestión de recursos en sinergia

CageFS por sitio se ocupa de la vista de archivos; la Actuación Me aseguro de establecer límites para la CPU, la RAM, las E/S y los procesos a nivel de cuenta o de grupo. De este modo, evito que un sitio genere una carga excesiva debido a plugins defectuosos y ralentice toda la cuenta. En muchas configuraciones, esto se incluye en cuotas de LVE o similares, que ajusto con precisión por grupo o por cuenta. Lo combino con la limitación de solicitudes en el servidor web o el WAF, para que los picos de tráfico se gestionen de forma ordenada. Esta combinación de aislamiento y cuotas aumenta la seguridad del servicio y la previsibilidad Distribución de la carga.

Cadena de protección: lo que no sustituye a CageFS por sitio

El aislamiento impide las vistas transversales, pero considero que las actualizaciones, Endurecimiento Se sigue aplicando de forma rigurosa el uso de PHP y contraseñas seguras. La autenticación multifactorial (MFA) para los inicios de sesión de administrador, los permisos mínimos de los archivos y los filtros de subida de archivos siguen siendo obligatorios. Un WAF, los límites de frecuencia y el registro continuo cubren vías adicionales que la mera separación de acceso a los archivos no controla. Además, compruebo periódicamente las tareas programadas (cronjobs) y los tokens de integración, que los atacantes suelen pasar por alto. Para obtener más información sobre la interacción entre la segregación de clientes y el endurecimiento de la seguridad, consulta esta guía sobre Seguridad del alojamiento compartido, que pone de relieve esa corriente de pensamiento.

Configuración y dificultades habituales

Activo el aislamiento de dominios de forma específica para cada sitio web y, a continuación, compruebo el acceso a SSH, Cron y PHP en condiciones reales. Las rutas absolutas en los scripts de implementación o en los plugins pueden causar problemas, por lo que prefiero utilizar rutas relativas o variables. Evito los enlaces simbólicos entre proyectos, ya que debilitan el principio de segregación; prefiero añadir las bibliotecas necesarias al repositorio de cada sitio web. Para las copias de seguridad, defino archivos separados y guardo los registros de cada dominio, para que la recuperación y el análisis forense se realicen de forma clara. En cuanto a los permisos, se ha demostrado que 640 para los archivos y 750 para las carpetas funcionan bien, además de Propietario adecuado para el pool de PHP correspondiente.

Análisis de la relación coste-beneficio para agencias y autónomos

Calculo la mejora en materia de seguridad frente al tiempo de gestión y los posibles costes por interrupción que generaría un incidente transversal, en Euro-Base. A menudo, unas pocas horas de respuesta ante incidentes cuestan mucho más que un pequeño recargo mensual por un mejor aislamiento. En el caso de las cuentas de agencias con varios proyectos de clientes, la segmentación reduce notablemente el riesgo de responsabilidad civil y de reputación. Además, los procesos de copia de seguridad y restauración se desarrollan de forma más ordenada, ya que puedo restaurar sitios concretos con precisión. En general, CageFS «por sitio» ofrece una mayor fiabilidad Gestión operativa con procesos previsibles.

Lista de verificación: Cuándo es obligatorio el CageFS por sitio

Activaré el aislamiento de dominios en cuanto haya varios Instalaciones que se ejecutan en una misma cuenta y tienen ciclos de actualización diferentes. Otro aspecto importante: los equipos de proyecto independientes o los accesos de administrador externos, que aumentan el riesgo de intervenciones involuntarias. Los elevados volúmenes de carga, los convertidores de archivos o el procesamiento de imágenes justifican aún más la separación, ya que a menudo se convierten en puntos de vulnerabilidad. Los distintos requisitos de cumplimiento normativo (por ejemplo, clientes, mercados, protección de datos) también abogan por una segmentación más detallada. Quien gestione en paralelo los entornos de preparación, pruebas y producción se beneficia de dominios de error claramente separados y de una clara Forense.

Requisitos y compatibilidad en la práctica

Antes de poner en producción Per-Site CageFS, compruebo el entorno de ejecución: el gestor de PHP utilizado (por ejemplo, PHP-FPM, lsapi), el servidor web activo, la integración disponible con el panel de control y la forma en que se gestionan las tareas programadas y las sesiones SSH. En entornos compartidos típicos, las aplicaciones siguen funcionando sin necesidad de modificar el código. Me aseguro de que exista una raíz de documentos propia para cada dominio, de que las rutas sean únicas (p. ej., /home/user/sites/proyecto-a/public) y de que se utilice un grupo dedicado de PHP-FPM para cada sitio web. Para las tareas cron, utilizo crontabs independientes para cada dominio o —cuando el panel las agrupa— prefijos y rutas de registro claros, para que las tareas se mantengan dentro de su Cárceles trabajo.

Separar claramente las bases de datos, las cachés y las sesiones

La vista de archivos es solo una parte. Llevo la separación hasta la base de datos y las cachés. Para cada sitio web, creo una base de datos propia y un usuario de base de datos propio con derechos mínimos. Para las cachés de objetos o de páginas (por ejemplo, Redis, Memcached), utilizo instancias separadas para cada sitio web o, como mínimo, prefijos de clave y bases de datos o espacios de nombres dedicados. Las sesiones de PHP se almacenan en rutas propias de cada sitio web; configuré el parámetro `session.save_path` por separado para cada grupo de FPM. Si utilizo una cola central o un backend de búsqueda, separo los índices y los temas por sitio. Este principio de „separación hasta el último tramo“ evita que los incidentes se propaguen a través de sistemas secundarios.

CI/CD y despliegues en aislamiento

En los procesos de compilación, aplico el aislamiento de forma predeterminada: cada sitio tiene su propia tarea de implementación, que solo accede al directorio del sitio. Descomprimo los artefactos dentro de la raíz del dominio, a continuación aplico las correcciones de propietario y grupo, y invalido únicamente las cachés afectadas. Los comandos de WP-CLI se ejecutan en el contexto correspondiente de CageFS, de modo que no afectan a proyectos ajenos. Mantengo las variables de entorno separadas para cada sitio web, y los secretos permanecen en los archivos de configuración propios del sitio o en el almacén de secretos del panel. Para garantizar un tiempo de inactividad cero, utilizo cambios atómicos de enlaces simbólicos dentro de los límites del dominio (p. ej., current/releases), pero me aseguro de que los enlaces simbólicos no apunten a proyectos vecinos. Las comprobaciones posteriores a la implementación (estado del sistema, análisis de errores 404/500, comprobación de permisos) son imprescindibles para cada sitio web.

Supervisión, registro y análisis forense

Separo los registros de forma sistemática: registros de acceso y de errores por dominio, registros propios de PHP y Cron, incluyendo rotaciones y retención. De este modo, en caso de incidente, puedo reconstruir la cronología de un sitio concreto sin tener que revisar toda la cuenta. Además, apuesto por comprobaciones de integridad de archivos (sumas de comprobación de los directorios principales), registros de auditoría distribuidos para las acciones de administración y sencillos archivos «canary» que detectan las manipulaciones de forma temprana. Para las alertas, a menudo bastan unos valores umbral: aumentos repentinos de los códigos de error 500, tamaños de subida inusuales, un crecimiento pronunciado del uso de inodos o un número excesivo de arranques de trabajadores PHP. Asocio estas señales a procedimientos de intervención claros: bloquear el sitio, comprobar las copias de seguridad, proteger los artefactos y reiniciar en un ámbito aislado.

Casos especiales de WordPress: Multisite, plugins MU y flujos de subida de archivos

En el caso de WordPress Multisite, sopeso las opciones: una instalación Multisite se beneficia menos de CageFS por sitio, ya que varios sitios comparten deliberadamente una base de código y una estructura. Si necesito límites más estrictos (equipos independientes, cachés separadas, análisis forense claro), prefiero configurar instancias individuales y aislarlas. Los plugins de MU, los «drop-ins» o las bibliotecas globales «must-use» solo los distribuyo dentro de cada sitio y evito las carpetas compartidas. Los flujos de trabajo de medios (CDN, optimización de imágenes, convertidores) se ejecutan dentro de la «jaula» del dominio; excluyo las subidas desde un sitio a los directorios de otro. Si un equipo desea compartir flujos de trabajo de activos, los replico por sitio o los encapsulo en un paquete que se integra en el repositorio correspondiente.

Ruta de migración: del sistema monolítico a la cuenta segmentada

Muchas cuentas empiezan con un directorio «public_html» muy grande y van creciendo con el tiempo. Yo sigo estos cinco pasos: 1) Hacer un inventario: ¿qué sitios web, dominios, tareas cron, bases de datos y claves de acceso hay? 2) Definir la estructura de rutas: para cada sitio web, su propia raíz, directorio temporal, registros y copias de seguridad. 3) Definir los grupos de PHP-FPM por dominio y establecer límites. 4) Mover archivos, ajustar permisos y limpiar rutas absolutas e inclusiones. 5) Activar CageFS por sitio, realizar pruebas bajo carga y poner en marcha la monitorización. Mientras tanto, tengo preparada una estrategia de reversión (instantáneas, copias de seguridad independientes). Tras la migración, compruebo si herramientas como WP-CLI, Composer, los procesos de imágenes y las tareas cron se ejecutan en el ámbito correcto y, si es necesario, ajusto las variables de ruta.

Imágenes de errores y resolución de problemas

• Errores 403/404 tras la activación: en la mayoría de los casos, las reglas de reescritura o las inclusiones remiten a rutas fuera de la raíz del dominio. Corrijo las rutas a variantes relativas o utilizo variables.
• Composer/NPM falla: las cachés globales no son visibles. Configuro directorios de caché locales para cada sitio y ajusto las variables HOME y TMP en la implementación.
• WP-CLI no encuentra el archivo wp-config.php: la ejecución no se realiza en la raíz del dominio. Configuro correctamente el directorio de trabajo o indico la ruta de forma explícita.
• Cronjobs desactivados: los usuarios de Cron o las rutas no están configurados por dominio. Compruebo las variables de entorno, las rutas de los binarios y los destinos de los registros dentro del entorno aislado del sitio.
• Las subidas fallan: session.save_path o tmp_dir apuntan a un directorio incorrecto. Asigno rutas temporales locales para cada grupo de FPM.
• Falta una biblioteca compartida: el enlace simbólico al proyecto adyacente está bloqueado. Replico la biblioteca en cada sitio o la incluyo como paquete en la implementación.

Gobernanza y modelo de acceso

Aunque técnicamente todo esté separado, sigue existiendo la cuestión de los accesos. Asigno accesos SSH/SFTP específicos para cada sitio web o limito el acceso al panel al dominio correspondiente. Los equipos de desarrolladores y agencias solo reciben las claves y los permisos que realmente necesitan. Para casos de emergencia, dispongo de un proceso de «break-glass» (derechos ampliados temporalmente, registro completo de actividades y revocación posterior). En las auditorías, documento por cada sitio web: rutas, grupos, límites, responsables, asignaciones RBAC y copias de seguridad. De este modo, la segmentación no solo es sólida desde el punto de vista técnico, sino también organizativo.

Brevemente resumido

CageFS por sitio complementa la separación de usuarios existente con una sitio web-nivel, lo que reduce de forma efectiva el riesgo de movimientos laterales. Considero que se trata de una medida muy práctica, ya que muchas cuentas agrupan varios proyectos independientes. La combinación de la separación de vistas de archivos y los límites de recursos aporta orden en cuanto a rendimiento, seguridad y funcionamiento. Quien aloje varias instancias de WordPress o tiendas online ganará tiempo en la resolución de errores, las copias de seguridad y la recuperación tras incidentes. Con derechos claros, actualizaciones, autenticación multifactorial (MFA) y registro de actividades, se crea una solución sólida Cadena de seguridad, lo que hace que el alojamiento compartido sea mucho más resistente.