Pregunta ¿Debemos deshabilitar el usuario root?


¿Deberíamos eliminar la contraseña de root, deshabilitar el inicio de sesión remoto y básicamente requerir que los administradores usen sudo para realizar acciones administrativas?

alt text


20
2018-05-02 01:31


origen




Respuestas:


Todos mis servidores tienen la cuenta de root deshabilitada (sp_pwdp ajustado a *). Esto es para requerir sudo para todos los accesos de root. [1] El propósito de esto es tener todas las actividades de superusuario auditadas, para que las personas puedan ver lo que se ha hecho en el sistema.

Para una opción más hardcore, puedes hacer sudo escribir en un archivo de registro (a diferencia de syslog), y hacer que el archivo se agregue solo (usando chattr en Linux, o chflags en BSD). De esta manera, nadie puede editar la auditoría después.

[1] También tengo la política de no ejecutar un shell de root o hacer escapes de shell de un proceso de root. (Está bien usar sudo sh -c '...' para hacer tuberías o redirecciones, sin embargo.)


15
2018-05-02 01:57



"¡No hay que correr conchas, tampoco!" Uhm, ¿sabes cuántos programas tienen un comando "soltar en shell" en ellos? Incluso antes de empiezas a mirar el control de trabajo de shell ... - womble♦
Estoy hablando de "no shell" como una política, no como una opción sudo. (sudo tiene una opción noexec, pero obviamente eso no es hermético a menos que restrinjas los programas específicos que un usuario puede ejecutar). - Chris Jester-Young
¿Es posible configurar sudo para que no se pueda utilizar "sudo -s"? Solo he usado sudoers para configurar comandos individuales.
@Graham: Tú puedes. Sin embargo, como puede ver en los comentarios anteriores, eso no detiene nada, si los usuarios pueden ejecutar algo. La única solución hermética es un enfoque de lista blanca, donde se enumeran los programas específicos que los usuarios pueden ejecutar, y todos deben estar vinculados dinámicamente (para que la opción "noexec" pueda hacer su trabajo). - Chris Jester-Young
Como una política en la que confías en los administradores, esto es bueno. Puede ver qué comandos ejecutan las personas, lo que puede ser realmente útil al tratar de averiguar qué ha cambiado. - Hamish Downer


yo enfáticamente Recomienda no deshabilitar el usuario root. Deshabilite o restrinja los inicios de sesión de raíz (a través de securetty y a través de sshd_config y a través de PAM y a través de lo que usted tiene) Si su sistema lo permite, limite los privilegios de la raíz o divida la función raíz (similar a cómo RSBAC lo hace.) Pero por favor, Por favor, no deshabilite la cuenta raíz eliminando la contraseña, de lo contrario será imposible iniciar sesión en el sistema a través de sulogin. sulogin es usado por todos los initscripts que conozco en caso de errores graves reportados por fsck, y eso significa que se bloqueará la sesión del sistema si el sistema de archivos raíz se corrompe.

Para aclarar: al "desactivar la cuenta raíz eliminando la contraseña" me refiero a los diversos mecanismos que terminan con un! o un * en el campo de contraseña de / etc / shadow, o similar. No me refiero a "cambiar el mecanismo de inicio de sesión de raíz para que no se le solicite una contraseña".


14
2018-05-02 21:32



¿Es este un problema en sistemas como Ubuntu que nunca establecen una contraseña de root? Parece que soy capaz de ejecutar "sudo sulogin", pero tal vez no comprenda un aspecto crítico. - jldugger
Desafortunadamente, no estoy familiarizado con la forma en que Ubuntu maneja la raíz. Pero si puede hacer "sudo sulogin" y obtener un shell de root sin que se le solicite una contraseña de root, entonces no, no es un problema, ya que posiblemente el mismo mecanismo se aplicará en el arranque. Puede intentar buscar grepping en busca de sulogin a través de los initscripts para verificar cuándo y cómo se invoca. - Mihai Limbăşan
Ubuntu no usa sulogin. Si entras en modo de usuario único, obtienes un shell de root de inmediato. Sin embargo, lea mi comentario (en mi publicación) para ver por qué esto no es un problema, en la mayoría de los casos. - Chris Jester-Young
@Chris: Gracias, respondió allí. - Mihai Limbăşan
Además, hay afirmaciones de que tener su o sudo en su sistema disponible para los usuarios significa más riesgos de seguridad que puede evitar si solo tiene usuarios root dedicados. Esa es una posición defendida por los autores de la distribución segura de Owl (y el diseñador Solar entre ellos) - unix.stackexchange.com/questions/8581/… Intenta presentar su posición con referencias. - imz -- Ivan Zakharyaschev


Tengo la cuenta de root habilitada en todos mis servidores. Todos los administradores tienen su propio usuario y tienen que iniciar sesión a través de eso. Desde allí se cambian a raíz. (la raíz ssh está deshabilitada)

Mantenga la cuenta del administrador bajo. Solo las personas que realmente necesitan acceso de root en ese servidor tienen la contraseña.

No soy fan de sudo. Es demasiado fácil simplemente hacer 'sudo bash' para un shell de root. Soy consciente de que esto puede ser desactivado, pero ¿para qué molestarse? Simplemente limite los usuarios que pueden realizar tareas de administrador y hable con los demás. Tenemos una política para no permitir que los terminales raíz se abran sin supervisión. Así que es iniciar sesión, su, hacer el trabajo, cerrar sesión.

Nota: trabajo en una empresa bastante pequeña (50 empleados) y solo tenemos 2 administradores a tiempo parcial (1 Windows / 1 Linux). Esta forma de hacer las cosas podría no ser la mejor cuando tiene órdenes de magnitud más usuarios. Yo personalmente todavía no usaría sudo. Hay otras formas de registrar la actividad de la raíz.


2
2018-05-02 05:55



Si quieres root shell desde una consola, puedes hacer 'sudo -i' en lugar de abrirlo desde sudo bash. Personalmente, realmente no me gusta la idea de iniciar sesión como usuario root directamente, ya que es demasiado arriesgado para las maniobras malintencionadas (es decir, que accidentalmente deja la computadora desbloqueada con el shell de root abierto). - Spoike
Sin embargo, pierdes el registro / auditoría con eso. Haga que todos utilicen sudo y prohíban a las personas hacer sudo bash, o sudo -i, o sudo -s con la política corporativa. Eso le proporciona una pista de auditoría, y si está enviando todos sus registros a un servidor central de registro, es fácil verificar que las personas siguen las políticas. - Christopher Cashell
Ese es el enfoque adoptado y defendido por los autores de la distribución segura de Owl (y entre ellos el diseñador solar): unix.stackexchange.com/questions/8581/… Intenta presentar su posición con referencias. - imz -- Ivan Zakharyaschev


La desactivación de la contraseña de root es, de hecho, una falsa "buena idea". El día que lo necesites, lo harás. De Verdad necesito. (De acuerdo con su configuración, puede necesitarlo para iniciar sesión en modo de usuario único por ejemplo)

La desactivación del inicio de sesión remoto de la raíz puede ser relevante, pero solo si puede iniciar sesión localmente.

Y sí, sudo debería instalarse en cada uno de sus servidores. Es útil y fácil de configurar. ¿Por qué te gustaría no usarlo?


1
2018-05-29 17:34



¿Qué pasa si el arranque en modo de usuario único es una opción de grub? - jldugger
¿Cuál es el objetivo de deshabilitar la cuenta de root? ¿Qué harás si frenas tu sudo binario o la configuración (o cualquier herramienta que uses)? - Benoit
Disabling root remote login might be relevant but only if you are able to log on locally. Esto es simplemente descaradamente falso. Puede iniciar sesión de forma remota con alguna cuenta; deshabilitar el inicio de sesión remoto no lo limita al acceso local. - Dan


Acabo de deshabilitar el acceso SSH para root y requiero que los usuarios (a menudo solo son desarrolladores) utilicen las claves ssh. Simplemente hay demasiados ataques de diccionario y cambiar el puerto SSH no es una opción para nosotros.

De esa manera, no tiene que confiar en la capacidad de nadie para escribir una buena contraseña. Una vez dentro, solo los administradores tienen permisos para sudo.


1
2018-05-29 18:07



Cambiar el puerto SSH no tiene sentido de todos modos. Un simple portscan lo regala fácilmente. Cuando hago telnet al puerto 22 en mi máquina, obtengo SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2 - Matt Simmons
@MattSimmons Sí, pero la mayoría de los ataques de diccionario son automáticos y muy elementales. No se molestan en escanear puertos; intentan conectarse a direcciones IP aleatorias en el puerto 22 y, si se agotan, pasan a la siguiente IP en su lista. No es una medida de seguridad, solo ayuda a deshacerse de los ataques automatizados del puerto 22. Obviamente, un ataque dirigido es un juego de pelota completamente diferente. - Dan


Sé que este hilo es muy antiguo, pero hay algunas fallas importantes en la lógica de los artículos vinculados y me siento "rant'ie" - sudo permite tanto listas blancas como negras. No solo negro como especifican en el articulo enlazado. - Esto omite la idea de AAA (Autenticación, Autorización y Auditoría) - Su y sudo permiten tanto la autenticación graduada como la responsabilidad.

escenario 1 Un administrador introduce accidentalmente un código deshonesto en un sistema, ha iniciado sesión como raíz, el código tiene acceso completo y es posible que el administrador nunca sepa qué ha ocurrido. Al menos con los inicios de sesión calificados (por ejemplo, su / sudo), se solicitará al administrador que autentifique si el código deshonesto intenta usar derechos elevados ... Si no se eleva, entonces se limita a los derechos de los usuarios, lo que debería resultar en un daño mínimo.

Escenario 2 Un administrador deshonesto quiere obtener información / hacer un cambio. Se conectan a la consola (acceso a la consola física, HP iLo / similar o acceso a la consola vGuest), inician sesión como root y hacen lo que desean. A menos que se use una tarjeta de acceso / cuenta con nombre para obtener acceso a la consola, es probable que no haya mucho rastro de auditoría.

  1. Asegúrate de que realmente sean quienes dicen ser. El robo de identidad no es el problema, la verificación de identidad es.
  2. Verifique su autorización, solo déles lo que necesitan en ese momento. La autorización gradual les permite elevar cuando la necesitan.
  3. Audítelo todo, tenga un registro para que sepa quién, qué hizo, cuándo y dónde. Preferiblemente por qué también

1
2017-10-10 05:10





Debe exigir que todos usen sudo para cada comando de raíz como una política. Nunca hay una razón para ejecutar "sudo bash" o similar, es solo por conveniencia, debido a la ignorancia, o para cubrir las huellas de uno.

Si desactiva los inicios de sesión en la cuenta raíz directamente, paralizará su capacidad para arreglar el sistema cuando haya problemas graves.

Si no puede convencer a sus administradores para que inicien sesión como ellos mismos y ejecute sudo para cada comando que se ejecute como root, y para no romperlo en un shell, tiene serios problemas para los que no existe una solución técnica.


0
2018-05-23 23:53





Los autores de la distribución segura de Owl (y el diseñador Solar) tienen un punto de vista opuesto y cuidadosamente justificado; ver, por ejemplo, la respuesta https://unix.stackexchange.com/questions/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 Para una presentación de sus reclamaciones. El problema de auditar las acciones del superusuario (qué persona hizo qué) también se aborda en su punto de vista (básicamente, la solución es tener varios usuarios root con nombres diferentes).


0
2018-05-21 05:03