¿Cuándo debo crear una nueva cuenta de usuario para ejecutar software en un servidor?

En general, ¿cuándo se debe crear una nueva cuenta de usuario para ejecutar un software de Internet en un servidor?

Por ejemplo, supongamos que estoy usando un servidor Debian compartido (por ejemplo, a través de Dreamhost) y quiero ejecutar algunos sitios web usando WordPress, algunos usando Redmine, algunos usando Ruby on Rails, tal vez algunos usando Django, y me gustaría servir Mercurial repositorios también.

En los servidores Dreamhost y muchos otros servidores configurados de manera similar, todo esto podría hacerse bajo una sola cuenta de usuario , pero puedo ver algunos inconvenientes de ese enfoque:

Un .bashrc más largo
Si esa cuenta se ve comprometida, también lo hacen todos los sitios que se ejecutan bajo ella.

Por otro lado, tener muchas cuentas de usuario podría ser un poco difícil de seguir, especialmente si algunas de ellas tienen requisitos idénticos en términos de software instalado. Por ejemplo, tener una cuenta para cada sitio web que ejecuta WordPress puede ser excesivo.

¿Cuál es la mejor práctica? ¿Es simplemente una cuestión de reducir el número de sitios alojados (o repositorios alojados, etc.) por cuenta de usuario proporcionalmente al nivel de paranoia?

Por favor publique sus opiniones sobre esto, exponiendo sus razones.

Además, si tiene alguna razón para pensar que el enfoque adoptado en un servidor privado o VPS debe diferir del enfoque adoptado en un servidor compartido, describa cuáles son y, nuevamente, sus razones.

— revs sampablokuper
fuente

Respuestas:

Generalmente soy fanático de "Un usuario para cualquier cosa que abra el socket de escucha en la red": uno para Apache, otro para correo, otro para DNS, etc.

Esta es (como la última vez que escuché) sigue siendo la mejor práctica actual, y la razón detrás de esto es una paranoia simple y simple: estos servicios están expuestos a Big Bad Internet, si alguien encuentra una vulnerabilidad y la explota antes de que tenga la oportunidad de reparar el software al menos los estoy confinando a una cuenta de usuario, con solo los privilegios necesarios para ejecutar el servicio único del que es responsable.
En general, considero que este nivel de aislamiento es suficiente para proteger el sistema, aunque cada aplicación es una isla de vulnerabilidad (por ejemplo, si alguien instala un plugin vulnerable de WordPress, todas las cosas a las que Apache tiene acceso (es decir, todos los sitios web) son efectivamente vulnerables en caso de compromiso.

Por lo tanto, se puede hacer una versión extendida de ese argumento para el sandboxing de los sitios web de los clientes de Hosting Compartido con su propia configuración y usuario de Apache (no necesariamente tiene que instalar una pila web completa para cada sitio, solo una configuración de Apache separada que especifica un usuario diferente ), la desventaja es que cada sitio ahora ejecuta un montón de procesos de Apache, por lo que su uso de RAM aumentó considerablemente, y las cosas que son legibles en todo el mundo siguen siendo vulnerables si alguna instancia / usuario de Apache se ve comprometida.

Ampliar aún más el argumento para poner cada Apache en un chroot (o cárcel si está en sistemas BSD) puede hacerse para una mayor seguridad, pero ahora está hablando de espacio en disco adicional ya que cada chroot / jail necesitará todo el software necesario para ejecute el sitio que contiene (y la necesidad de actualizar este software para cada sitio en lugar de solo una copia maestra en el servidor cuando salgan los parches), más el requisito de RAM al igual que cuando tenía usuarios separados / instancias de apache.
Esto mitiga todo, excepto un error del sistema operativo / kernel que permite a los usuarios salir del chroot (que se convierte en el argumento para ejecutar cada sitio en un servidor físico separado, que luego se convierte en el argumento para separar los sitios en diferentes vlans / subredes, etc.)

Como con todos los riesgos, no puede eliminarlo: solo puede mitigarlo a un nivel aceptable basado en el daño / costo potencial de un compromiso, la probabilidad de un compromiso y el costo de cada nivel de mitigación.
Para mi dinero, para un entorno de alojamiento compartido no crítico, no de comercio electrónico, el básico "Un usuario para Apache, uno para DNS, uno para correo, etc." la red de seguridad es suficiente. Si existe una necesidad de seguridad más allá de ese nivel, sus usuarios deberían considerar seriamente su propio hardware.

— voretaq7
fuente

También hay un módulo para Apache (¿creo que mod_su?) Que le permite a Apache cambiar dinámicamente al usuario en el que se ejecuta según la solicitud entrante; en un entorno de alojamiento compartido, lo configuraría para cambiar al usuario propietario del sitio al que se accede. Esto proporciona la compartimentación de los tipos más comunes de infracciones (inyección de código, etc.) para que solo un usuario que, por ejemplo, instaló el plugin de WordPress defectuoso, se vea afectado por él. También ofrece cierta protección contra una violación completa del proceso de Apache en sí, y contra ataques de escalada de privilegios, pero es cierto que ese no es su verdadero propósito.

— Kromey

@Kromey, no pude encontrar mucha información sobre mod_su. ¿Te refieres a mod_suexec ?

— sampablokuper

@sampablokuper Sí, ese sería el único, perdón por la desinformación.

— Kromey

@Kromey, el gran problema mod_suexeces que "las solicitudes no CGI siguen siendo procesos con el usuario especificado en la directiva de usuario", por lo que si PHP es un módulo, todavía se está ejecutando como el usuario "principal" de Apache. Sin embargo, es una gran solución si todo lo que está ejecutando es CGI.

— voretaq7

@voretaq Ah, no estaba al tanto de esa limitación. Aún así, podría ser útil en algunos entornos, pero eso lo hace menos aplicable de lo que pensaba.

— Kromey

En general, lo que hago es tener un usuario para los servicios externos que no pueden iniciar sesión ("nadie", por ejemplo) y una cuenta que puede iniciar sesión y su o sudo. Naturalmente, asegúrese de que sus nombres de usuario sean diferentes y no sean fáciles de adivinar.

No veo que sea necesario tener un usuario por servicio a menos que esté ejecutando un entorno de alojamiento compartido donde cada cliente tenga un inicio de sesión. Si realmente te ves como un objetivo muy atractivo para hackear, también puedes aislar tanto como sea posible. Sin embargo, a menos que esté haciendo algo muy controvertido o alojando datos financieros, en realidad no es tan atractivo como objetivo.

— Kyle
fuente

+1 el nivel de separación debe ser apropiado para la situación en cuestión, y típicamente una vez que llegue a "datos muy controvertidos" o "financieros", querrá mis propios niveles de separación de máquinas :-)

— voretaq7