linux - picard - ¿Cómo se manejan las contraseñas de raíz de los servidores?

musicbrainz picard español (10)

En nuestro equipo de administración, todos tienen contraseñas root para todos los servidores del cliente. Pero, ¿qué deberíamos hacer si uno de los miembros del equipo ya no trabaja con nosotros? Todavía tiene nuestras contraseñas y tenemos que cambiarlas todas, cada vez que alguien nos deja.

Ahora estamos usando claves ssh en lugar de contraseñas, pero esto no es útil si tenemos que usar algo que no sea ssh.

Acabamos de hacer que sea realmente fácil cambiar las contraseñas de raíz en cada máquina que administramos, así que cuando la gente se fue solo ejecutamos el script. No sé muy bien pero funcionó. Antes de mi tiempo, todos en la compañía tenían acceso a la raíz en todos los servidores. afortunadamente nos alejamos de eso.

Aparte de la política de sudo, que probablemente sea mejor, no hay ninguna razón por la cual cada administrador no podría tener su propia cuenta con UID 0, pero con un nombre diferente, con una contraseña diferente e incluso con un directorio personal diferente. Solo elimine su cuenta cuando se hayan ido.

Contraseña de root razonablemente fuerte. Diferente en cada caja. No hay inicios de sesión raíz remotos ni contraseñas para inicios de sesión, solo claves.

En términos generales, si alguien se va de nuestro equipo, no nos molestamos en cambiar las contraseñas de root. O abandonaron la empresa (y ya no tienen forma de acceder a las máquinas ya que su VPN ha sido revocada, al igual que su acceso de placa al edificio, y su acceso inalámbrico a la red), o están en otro departamento dentro de la compañía y tener la profesionalidad para no atornillar con nuestro entorno.

¿Es un agujero de seguridad? Tal vez. Pero, realmente, si quisieran atormentarse con nuestro entorno, lo habrían hecho antes de seguir adelante.

Hasta ahora, cualquier persona que abandone el equipo que quiera tener acceso a nuestras máquinas nuevamente siempre ha pedido permiso, aunque podrían seguir adelante sin el permiso. No veo ninguna razón para impedir nuestra capacidad de hacer el trabajo, es decir, no hay razón para creer que cualquier otra persona que se mueva hacia adelante y hacia arriba lo haga de manera diferente.

Normalmente sugeriría lo siguiente:

Use una contraseña de root en blanco .
Deshabilitar telnet
Establezca ssh para no-root-login (o inicio de sesión raíz solo mediante clave pública)
Deshabilite su para rootear agregando esto a la parte superior de / etc / suauth: ''root: ALL: DENY''
Habilite la autenticación segura para el inicio de sesión raíz solo en la consola (tty1-tty8)
Use sudo para acceder a la raíz normal

Ahora bien, con esta configuración, todos los usuarios deben usar sudo para el administrador remoto, pero cuando el sistema está seriamente dañado, no hay búsqueda de la contraseña de root para desbloquear la consola.

EDITAR: otras herramientas de administración del sistema que proporcionan sus propios inicios de sesión también necesitarán ajustes.

Si bien es una buena idea utilizar una política de solo sudo como Chris sugirió dependiendo del tamaño de su sistema, un enfoque de ldap también puede ser útil. Complementamos eso con un archivo que contiene todas las contraseñas de raíz, pero las contraseñas de raíz son realmente largas y no memorables. Si bien eso puede considerarse un defecto de seguridad, nos permite iniciar sesión aún si el servidor ldap no funciona.

Si tiene acceso ssh a través de sus certificados, ¿no puede iniciar sesión a través de ssh y cambiar la contraseña de root través de passwd o sudo passwd cuando necesita hacer algo más que requiera la contraseña?

Usamos la política sudo only donde trabajo, pero aún se conservan las contraseñas raíz. Las contraseñas raíz solo están disponibles para unos pocos empleados seleccionados. Tenemos un programa llamado Password Manager Pro que almacena todas nuestras contraseñas y también puede proporcionar auditorías de contraseñas. Esto nos permite retroceder y ver a qué contraseñas han accedido los usuarios. Por lo tanto, solo podemos cambiar las contraseñas que realmente necesitan cambiarse.

Las claves SSH no tienen una alternativa real.

Para la administración de muchos archivos authorized_keys en muchos servidores, debe implementar su propia solución, si no desea el mismo archivo en cada servidor. Ya sea a través de una herramienta propia, o con alguna solución de administración de configuración como títere, ansible o algo así.

De lo contrario, bastará un bucle en bash o alguna acción de clush .

Cualquier cosa además de los inicios de sesión de SSH:
Para los servicios que ejecuta que están basados en el inicio de sesión, utilice algún tipo de autenticación con un backend central. Tenga en cuenta que nadie hará ningún trabajo si este backend no está disponible.

Ejecute el servicio en clúster. No hagas hacks con una cuenta de puerta trasera súper-duper-service, para tener siempre acceso en caso de que algo se rompa (como el acceso de administrador se rompe debido a una configuración incorrecta). No importa cuánto controle los cambios de acceso o configuración que afecten a esta cuenta, esto es ''simplemente malo'' (TM).

En lugar de tener esta puerta trasera correcta, también podría agrupar la aplicación, o al menos tener un sistema de repuesto que refleje periódicamente la configuración actual si la caja principal muere, que luego se puede activar fácilmente a través de cambios de enrutamiento en la red. Si esto parece demasiado complicado, su negocio es demasiado pequeño y puede vivir con medio día o dos días de inactividad. O realmente odias los clusters debido a la falta de conocimiento y solo guardas las cosas equivocadas.

En general : si utiliza software inutilizable con algún tipo de integración de Active Directory o LDAP, debe saltar al tiburón y cambiar las contraseñas manualmente.

También es muy agradable una base de datos de gestión de contraseñas dedicada a la que solo unos pocos puedan acceder de forma directa y que sea de solo lectura para todos los demás. No se moleste con los archivos de Excel, estos carecen de una gestión de derechos adecuada. Trabajar con control de versiones en archivos .csv tampoco lo corta después de un cierto umbral.

Los sistemas que ejecuto tienen una política de sudo- only. es decir, la contraseña de root es * (deshabilitada), y las personas tienen que usar sudo para obtener acceso a la raíz. Luego puede editar su archivo sudoers para otorgar / revocar el acceso de las personas. Es muy granular y tiene mucha capacidad de configuración, pero tiene valores predeterminados razonables, por lo que no le tomará mucho tiempo configurarlo.