¿Implicaciones de seguridad de tener archivos que son propiedad del usuario de apache?

Navega tus respuestas
14

Actualmente se está ejecutando una instancia de LAMP que los desarrolladores están usando para una variedad de aplicaciones web. Tengo el siguiente escenario:

  • Varios desarrolladores necesitan acceso para crear y modificar archivos en / var / www / html
  • Los desarrolladores deben poder acceder al código de cada uno en caso de que estén fuera de vacaciones, enfermos, etc.

Mis pensamientos fueron los siguientes:

  1. Para cada aplicación web (directorio) bajo / var / www / html, cambie recursivamente el propietario a 'apache' y el grupo a un grupo de 'desarrolladores'. Establezca los permisos en 570 .
  2. Para cada archivo en / var / www / html, cambie recursivamente el propietario a 'apache' y el grupo a un grupo de 'desarrolladores'. Establezca los permisos en 470 .

Mantener los archivos y directorios como solo de lectura para el usuario de Apache es una buena práctica de seguridad, pero ¿el hecho de que dichos archivos sean propiedad del usuario de Apache es malo? Mi preocupación era sobre lo que sucedería si Apache fuera golpeado por una vulnerabilidad de 0 días o algo por el estilo.

Si alguien tiene una forma más elegante de hacerlo, también me interesa escucharlo.

    
pregunta am4 14.12.2011 - 17:10
fuente

2 respuestas

10

Restringir el demonio con MAC

No importa cómo lo corte, envolver a Apache en una capa de control de acceso obligatorio como AppArmor o SELinux es un buen primer paso. Eso le permitirá restringir las operaciones permitidas del daemon incluso si de otro modo tiene permisos para hacerlo. Eso evitará que Apache modifique sus archivos.

Usa el control de versiones con checkouts automáticos

Si cada desarrollador tiene acceso a git y la rama de producción es revisada automáticamente por el servidor web cuando se actualiza, tendrá control e historial de todo lo que se carga, así como una verificación instantánea de que todo es lo que debería ser. .

Permisos

La desventaja de hacer que Apache sea el propietario de los archivos es que, en teoría, Apache podría modificar esos archivos. Por esa razón, hacer que el directorio y los archivos de datos que son propiedad de otro usuario tenga un beneficio a menos que espere que Apache altere el directorio. Si lo hace, intente separar los directorios para el contenido dinámico esperado y el contenido que Apache nunca debería actualizar.

    
respondido por el Jeff Ferland 14.12.2011 - 17:32
fuente
9

Tienes toda la razón, mantener al usuario ejecutando el proceso del servidor web, en tu caso apache aislado de escribir en webroot, es una buena idea. Es una de las guías básicas de endurecimiento por una razón. Si el usuario puede escribir en los archivos o directorios, facilita la modificación del sistema de archivos para un usuario malintencionado. Una cosa que no está teniendo en cuenta es cómo funciona la propiedad de los sistemas de archivos.

El usuario que posee un archivo siempre puede escribir en él. Esto parece contradictorio, pero está en su lugar para que el usuario pueda hacer cosas como sobrescribir o eliminar el archivo.

Si, para su proceso de negocio, los desarrolladores requieran acceso directo de escritura a los archivos web en vivo, modificaría sus recomendaciones a esto:

Mis pensamientos fueron los siguientes:

  1. Para cada aplicación web (directorio) bajo /var/www/html , cambie recursivamente el propietario a otra cuenta como nobody o root y el grupo a un grupo developers . Establezca los permisos en 575.
  2. Para cada archivo bajo /var/www/html , cambie recursivamente el propietario a otra cuenta como nobody o root y el grupo a un grupo developers . Establezca los permisos en 474.

Esto permitirá al usuario apache leer los archivos, permitiendo así que httpd sirva los archivos, mientras evita que los modifique.

    
respondido por el Scott Pack 14.12.2011 - 17:30
fuente

Lea otras preguntas en las etiquetas

¿Debo cambiar el número de teléfono y la dirección de correo electrónico después del fraude de PayPal? ¿Qué debo saber sobre SPDY antes de habilitarlo?