¿Por qué su para rootear en lugar de iniciar sesión como root?

33

He escuchado a menudo que es mejor su rootear en lugar de iniciar sesión directamente como usuario root (y, por supuesto, la gente también dice que es aún mejor usar sudo). Nunca he entendido realmente por qué uno es mejor que el otro, ¿perspicacia?

— thepocketwade
fuente

2

¿Está pensando en inicios de sesión ssh o también inicios de sesión desde la máquina física?

— Telémaco

43

La inferencia es solo suo sudocuando sea necesario.

La mayoría de las tareas cotidianas no requieren un shell raíz. Por lo tanto, es una buena práctica usar un shell sin privilegios como comportamiento predeterminado y luego elevarse a la raíz cuando necesite realizar tareas especiales.

Al hacerlo, está reduciendo el alcance de errores peligrosos (secuencias de comandos incorrectas, comodines extraviados, etc.) y vulnerabilidades de cualquier aplicación que utilice. Especialmente aquellos que se conectan a Internet - vea el viejo adagio "No IRC como root" .

sudo a menudo se recomienda porque le permite obtener un grano fino y auditar el uso de tales privilegios.

Al observar estas prácticas, también está en condiciones de deshabilitar los inicios de sesión raíz remotos. Esto aumenta la barra de entrada para cualquier posible atacante, ya que tendrían que comprometer una cuenta de usuario normal que fuera miembro del grupo "rueda" e idealmente solo autorizada por las claves públicas SSH, luego la cuenta raíz misma.

— Dan Carley
fuente

1

¿Podría comprender por qué el inicio de sesión raíz remoto es una "vulnerabilidad razonablemente grande"?

— thepocketwade el

55

Debido a que todo el mundo conoce el nombre de usuario ('root'), es solo una cuestión de averiguar la contraseña. Y pueden hacerlo por la fuerza bruta y hacerse cargo de su computadora.

— Shalom Craimer

2

Otra ventaja de sudo: registro de comandos ejecutados.

— Manuel Faux el

Eso es auditoría;)

— Dan Carley

1

Si bien sudoes superior, sutambién le permite usar el -mindicador para mantener las variables de entorno iguales mientras se encuentra en un terminal raíz. Nada me impulsa más loco a rootear suun poco, solo para hacer algo con ~el nombre del directorio y que no funcione.

— tj111

27

Debe deshabilitar el acceso a la raíz desde el control remoto para que un atacante no pueda comprometer la raíz sin primero comprometer a un usuario y luego escalar a la raíz. Solo habilitamos el acceso de root en la consola.

Además, crea responsabilidad. :)

— egorgry
fuente

+1 corto y al grano

— lexu

15

La razón principal es crear una pista de auditoría. Si necesita iniciar sesión en un sistema como usuario normal y luego su, es posible rastrear quién es responsable de las acciones dadas.

— Tim
fuente

Después de que alguien ha ejecutado su - root, ¿cómo determina qué comandos ejecuta? ¿Está registrado en alguna parte?

— Dobes Vandermeer

10

sudo también registra automáticamente cada comando en syslog y puede definir los comandos que cada usuario puede usar.

— Jure1873
fuente

3

En cuanto al registro: este es el caso de cada comando precedido por 'sudo', pero en el caso de que sudo se use para elevar a un shell raíz, los comandos solo se registran en las áreas tradicionales (específicamente el historial del shell).

— Zenham

2

De hecho, sudo vim foo.txtluego caer a un shell desde vim le dará un shell raíz sin el registro de sudo regular.

— Ophidian

O simplemente sudo -ipara obtener una sesión interactiva ...

— Kamil Kisiel

No entiendo el problema con sudo vim foo.txt. Corrí eso, luego salí de VIM y todavía era yo mismo, ¿hay algo que me falta?

— thepocketwade el

puede "engañar" a sudo para que le dé un shell escribiendo sudo su - o sudo vim y luego ir a un nuevo subshell. Pero si usa sudo porque quiere tener todo registrado en syslog (centralizado) y sabe que también se puede usar para obtener otra subshell, entonces no veo nada de malo en eso, es solo una bonificación siempre que No dependo solo de eso.

— Jure1873

9

Otra buena razón: cuando se eleva a la raíz a través de sudo, un usuario se autentica con sus propias credenciales, lo que significa que no necesariamente se les debe dar la contraseña de root, lo que facilita el bloqueo cuando alguien abandona su organización.

— Zenham
fuente

4

Si desea crear una pista de auditoría y no quiere ser víctima de los problemas "sudo su -" o "sudo vim foo.txt" mencionados aquí, puede usar "sudosh". Distribuya el acceso raíz a través de sudo, pero cree el único comando permitido para ejecutar "sudosh".

sudosh es un shell de registro, y puede reproducir toda la sesión de terminal en una fecha posterior, mostrando exactamente lo que el usuario vio en su terminal.

— mibus
fuente

Eso supone, por supuesto, que sudosh está disponible en el sistema. Acabo de marcar y no lo tengo en ninguno de mis cuadros de Linux.

— John Gardeniers

También puede usar el nuevo ksh93 con el registro de seguimiento de auditoría habilitado. Consulte este artículo en IBM developerWorks: ibm.com/developerworks/aix/library/au-korn93/…

— Mei

Bastante fácil de omitir simplemente ejecutando un script de shell (que luego borra). Cree el script con un nombre inocuo como usuario no auditado (o escríbalo desde su estación de trabajo), luego sudo y ejecútelo. Incluso podría ocultarlo nombrándolo 'ls' o somesuch y ponerlo en $ PATH (alterando $ PATH si es necesario), y hacer que haga su trabajo sucio mientras invoca / bin / ls para que se vea normal. Límpielo después. El registro de auditoría no sabrá que / home / anthony / bin solía contener un 'ls'.

— derobert

Sí, no es perfecto. sabemos esto, pero es un sitio mucho mejor que el simple "sudo su -" en mi humilde opinión. Y sí, no está instalado por defecto en ningún lugar AFAIK. Sin embargo, se ejecuta en Solaris y Linux con bastante facilidad.

— mibus

1

Debe practicar la seguridad en profundidad.

No permita el acceso raíz remoto (o al menos el acceso raíz a través de contraseñas). (si permite el acceso de root a través de claves, controle cuidadosamente esas claves o, mejor aún, use algo como kerberos que permita la revocación centralizada de claves).

Deshabilitaría su y usaría sudo. De esa manera, los usuarios usan claves (preferiblemente encriptadas) para acceder al sistema y luego usan su contraseña solo para escalar privilegios. Puede restringir los programas a los que las personas acceden con sudo, pero principalmente solo restringe el acceso a quién conoce la contraseña de root.

En un mundo ideal, debería poder publicar sus contraseñas raíz en Internet y no importaría, incluso si le dio acceso a las personas a su máquina (pero no las colocó en el archivo / etc / sudoers). Por supuesto, no debe publicar la contraseña de root, pero la idea es proteger sus sistemas con capas concéntricas de protección.

— Chris
fuente

0

La idea es deshabilitar el inicio de sesión raíz y, por lo tanto, no tener una cuenta de administrador predeterminada. De esa forma, un atacante debe adivinar tanto el nombre de usuario como la contraseña (y no solo la contraseña).

— Johan
fuente

0

Si usa root de forma regular, entonces sus permisos pueden ser incorrectos o puede que tenga que otorgar derechos de sudo o un nuevo grupo de derechos para r / w / x los archivos o directorios.

Los buenos esquemas de permisos son algo que incluso los usuarios de Linux desde hace mucho tiempo se equivocan, o no se dan cuenta del alcance que tienen.

¡Ni siquiera me hagas empezar con lo que hizo Ubuntu!

— Aiden Bell
fuente

-2

Le impide ejecutar rm -r -f / Acabo de ejecutar eso hace 2 días (como usuario sin privilegios, quería ejecutar rm -r -f *)

— artilugio
fuente

La respuesta aceptada ya tenía toda la información.

— Theuni