¿Cómo se cambia el nombre de root?

No es que sea una muy buena idea cambiarlo, sino por diversión. De acuerdo con este post, todavía hay algunos problemas incluso después de cambiar las entradas en /etc/passwd, /etc/shadow, y /etc/sudoers. ¿Alguna sugerencia?

Teóricamente, cambiarlo /etc/passwdy /etc/shadowsería todo lo que necesita para 'renombrar' la raíz. El problema se produce porque casi todas las piezas de software de Unix existentes suponen que el nombre de usuario 'root' existe y que es el superusuario: alias de correo, varios demonios, cron ...

Si realmente está empeñado en intentarlo, find /etc -type f -exec grep -l root {} +debería ser un buen comienzo para encontrar una lista de cada archivo de configuración que probablemente necesite cambiar, pero como ya dijo, esta es una muy mala idea en casi todas las situaciones imaginables.

EDITAR Otro pensamiento: si aún no lo ha hecho (que debería tener), asegúrese de que /etc/aliasescontenga una entrada rooty un nombre de usuario que exista o una dirección de correo electrónico que se evalúe correctamente. Muchas tareas automatizadas de todo el sistema ( cronpor ejemplo) envían su salida por correo electrónico a root, que tradicionalmente se alias al administrador del sistema responsable de las operaciones de ese sistema.

Todo este miedo traficante, diciendo "¡No lo hagas!" es ridículo. En un momento, sí, probablemente rompió muchos guiones mal escritos, pero sospecho que ya no son tan comunes; al menos no en las distribuciones estándar.

Nos han dicho que cambiemos el nombre de la cuenta raíz en un subconjunto de servidores Linux. Entonces, después de intentar investigar cómo hacerlo correctamente, encontré muchas publicaciones que decían "¡No lo hagas!" con muchas advertencias terribles de "cosas malas" que suceden si elige hacer esto. Pero, todavía tengo que encontrar alguno con ejemplos concretos de las "cosas malas" que podrían suceder.

Entonces, déjenme retroceder y explicar dónde estoy y cómo llegamos aquí. Estamos construyendo un entorno compatible con PCI, y una de las herramientas que nos ayuda a cumplir con esos "requisitos" es decirnos que necesitamos cambiar el nombre de las cuentas raíz y de administrador e invitado a otra cosa. Para aquellos sin educación sobre PCI, tienen la opción de seguir las pautas o documentar por qué no pueden o no seguir esa pauta, y qué estrategia de mitigación tienen para mantener seguros los sistemas. Entonces, me imagino que la mayoría de los lugares documentan por qué no van a cambiar el nombre de sus cuentas raíz, sin embargo, nuestro grupo ha decidido que, si podemos cambiar el nombre de las cuentas de administrador de Windows sin problemas, también cambiaríamos el nombre de las cuentas raíz de Linux.

Estoy bien versado en los argumentos de "seguridad a través de la oscuridad"; Sé que solo cambiar el nombre de la cuenta raíz en realidad no mejora mucho la seguridad, la raíz debe estar deshabilitada en SSH, etc. Lo sé, ese no es el punto, no estoy interesado en escuchar más. Tampoco me interesan más advertencias de "el cielo caerá". Estoy buscando declaraciones como esta: "> esto malo <sucederá con> este paquete estándar <(a menos que usted> haga esto <)".

Hasta ahora, tengo 3 sistemas CentOS (RHEL) que aparentemente no tienen problemas para cambiar el nombre de la cuenta raíz. Esto es lo que hice: cambié el nombre de la cuenta en / etc / passwd, / etc / shadow, / etc / group y / etc / gshadow. Luego seleccioné el nombre raíz en / etc / y modifiqué el archivo de alias postfix para que la raíz fuera un alias de nuestro nuevo nombre de cuenta, llámelo rojotoro. (Algo similar debe hacerse para otros sistemas de correo electrónico). También descubrí que necesitaba cambiar algunas configuraciones para logrotate al describir quién debería poseer los archivos que crearía automáticamente. Y eso ha sido todo lo que he cambiado hasta ahora.

He mirado muchos scripts init.d, pero no he cambiado nada, y todo parece comenzar bien en el arranque. Tengo que especificar la nueva cuenta cuando uso sudo: "sudo -u rojotoro vim / etc / passwd" como ejemplo, pero en realidad no necesitaba cambiar nada dentro del archivo sudoers. Esperaba quizás algunos problemas con selinux que tenemos y aplicamos, pero hasta ahora no he necesitado tocar ese sistema.

También puedo ver que los scripts mkdev o mkfs pueden necesitar ser ajustados, pero no planeo usarlos, así que no los he mirado con el escrutinio que merecen.

Si realmente es así de fácil de cambiar sin efectos nocivos en un sistema habilitado con Selinux, ¿por qué la continuación de todo el miedo?

sugerencia: no hagas eso.

Algunas herramientas intentan comunicarse con root a través de uid, allí no debería tener problemas. Algunas herramientas asumen que su cuenta raíz se llama raíz y se romperá. a menos que esté preparado para recompilar la mitad de su sistema "por diversión", simplemente no lo intente.

En mi opinión, lo más fácil es crear un nuevo usuario (alias), con UID 0 y /rootcomo inicio.

¿Por qué no cambias el shell predeterminado de tu raíz a ( /bin/falseo /sbin/nologinpara que nadie pueda iniciar sesión en él, pero el sistema todavía lo usa) e iniciar sesión en el nuevo alias creado?

razvan@naboo ~ $ head -2 /etc/passwd
root:x:0:0:root:/root:/bin/nologin
root2:x:0:0:root:/root:/bin/bash
razvan@naboo ~ $ su -
Password:
su: Authentication failure
razvan@naboo ~ $ su root2
Password:
naboo razvan # whoami
root

Si cambia el shell de root a nologin, el sudo, mail o ftw no se dañarán.

Linux no es Windows y la raíz no se puede renombrar fácilmente sin crear problemas futuros desconocidos.

¡Deshabilitar el inicio de sesión remoto e incluso local como root es un enfoque más seguro porque deshabilita activamente la raíz de la cuenta! UBUNTU esencialmente hace esto y fuerza sudo en lugar de acceso raíz.

¡Esencialmente nadie puede usar la cuenta raíz para atacar su sistema ya que ya no se puede usar para iniciar sesión en el sistema!

Sería bueno si se creara una forma estándar para modificar fácilmente tanto el nombre de la cuenta raíz como la generación aleatoria de su UID después de la instalación y, si es posible, en cada arranque en frío para evitar la orientación de UID, pero eso actualmente no existe.

Ajuste / etc / passwd Modificar raíz: x: 0: 0: raíz: / raíz: / bin / nologin

¡Cree una sola cuenta de administrador de reserva solo para USO DE EMERGENCIA! fallbackadmin: x: 0: 0: root: / root: / bin / bash

¡Implemente sudo para todos los administradores para que la auditoría de registro de cambios se pueda implementar para rastrear con precisión quién realiza los cambios para la responsabilidad!

Esto implementa los requisitos de PCI US Gov para deshabilitar las cuentas de administrador / invitado predeterminadas y crear una sola cuenta de administrador de uso de emergencia.

Una forma de archivar registros para auditoría es recopilar el historial del terminal de todos los usuarios con acceso a la cuenta de sudo si no se implementa AAA centralizado.

Una solución para implementar cuentas solo de administrador es crear una cuenta solo de usuario y una cuenta habilitada para sudo y luego obligar al usuario a acceder a su cuenta habilitada para acceso administrativo.

También podría implementar la autenticación con tarjeta inteligente si desea una mayor seguridad; existen soluciones disponibles para GNU / Linux que se comparan con las soluciones CAC de la tarjeta de acceso común de EE. UU. Para la autenticación de dos factores.