¿Por qué el inicio de sesión raíz a través de SSH es tan malo que todos recomiendan desactivarlo?

83

Todos en Internet aconsejan deshabilitar el inicio de sesión raíz a través de SSH, ya que es una mala práctica y un agujero de seguridad en el sistema, pero nadie explica por qué es así.

¿Qué es tan peligroso al habilitar el inicio de sesión raíz (especialmente con el inicio de sesión de contraseña deshabilitado)?

¿Y cuál es la diferencia entre el nombre de usuario del símbolo X y la contraseña del símbolo Y o el nombre de usuario raíz y la contraseña del símbolo X + Y desde el punto de vista de la seguridad en caso de que se permita la autenticación de contraseña?

ssh security root

— prisa
fuente

2

Tener un usuario root en la mayoría de los sistemas es malo en sí mismo, ¡deja solo habilitar un inicio de sesión SSH para dicho usuario!

— Suman

1

El inicio de sesión raíz a través de ssh es necesario para ehealth-aussie.blogspot.com/2012/01/… . Todo es un compromiso.

— emory

2

Umm ... ¿deberíamos trasladar esta pregunta a seguridad? Dado que el tema se inclina más hacia la seguridad que los sistemas * nix.

— Braiam

1

Hay una razón administrativa para deshabilitar root. En los servidores comerciales, siempre desea controlar el acceso por persona. La raíz nunca es una persona. Incluso si permite que algunos usuarios tengan acceso a la raíz, debe obligarlos a iniciar sesión a través de su propio usuario y luego su -o sudo -ipara que se pueda registrar su inicio de sesión real. Esto hace que revocar todo el acceso a un individuo sea mucho más simple, de modo que incluso si tienen la contraseña de root no pueden hacer nada con ella.

— Philip Couling

62

Por qué rootear sobre SSH es malo

Hay muchos bots que intentan iniciar sesión en su computadora a través de SSH. Estos bots funcionan de la siguiente manera.

Ejecutan algo como ssh root@$IPy luego prueban contraseñas estándar como "root" o "password123". Lo hacen todo el tiempo que pueden, hasta que encuentran la contraseña correcta. En un servidor accesible en todo el mundo, puede ver muchas entradas de registro en sus archivos de registro. Puedo subir hasta 20 por minuto o más.

Cuando los atacantes tienen suerte (o tiempo suficiente) y encuentran una contraseña, tendrían acceso de root y eso significaría que está en problemas.

Pero cuando no permite que root inicie sesión a través de SSH, el bot primero debe adivinar un nombre de usuario y luego la contraseña correspondiente. Entonces, digamos que la lista de contraseñas plausibles tiene Nentradas y la lista de usuarios plausibles es Mentradas grandes. El bot tiene un conjunto de N*Mentradas para probar, por lo que esto lo hace un poco más difícil para el bot en comparación con el caso raíz donde solo es un conjunto de tamaño N.

Algunas personas dirán que este adicional Mno es una ganancia real en seguridad y estoy de acuerdo en que es solo una pequeña mejora de seguridad. Pero pienso en esto más como estos pequeños candados que en sí mismos no son seguros, pero que impiden el acceso fácil a muchas personas. Por supuesto, esto solo es válido si su máquina no tiene otros nombres de usuario estándar, como tor o apache.

La mejor razón para no permitir root es que root puede causar mucho más daño en la máquina que un usuario estándar. Entonces, si por suerte encuentran su contraseña, todo el sistema se pierde, mientras que con una cuenta de usuario estándar solo puede manipular los archivos de ese usuario (que todavía es muy malo).

En los comentarios se mencionó que un usuario normal podría tener el derecho de usar sudoy si se adivina la contraseña de este usuario, el sistema también se pierde por completo.

En resumen, diría que no importa qué contraseña de usuario obtenga un atacante. Cuando adivinan una contraseña, ya no puede confiar en el sistema. Un atacante podría usar los derechos de ese usuario para ejecutar comandos sudo, también podría explotar una debilidad en su sistema y obtener privilegios de root. Si un atacante tenía acceso a su sistema, ya no puede confiar en él.

Lo que hay que recordar aquí es que cada usuario en su sistema que puede iniciar sesión a través de SSH es una debilidad adicional. Al deshabilitar la raíz, eliminas una debilidad obvia.

¿Por qué las contraseñas sobre SSH son malas?

La razón para deshabilitar las contraseñas es realmente simple.

¡Los usuarios eligen contraseñas malas!

La idea de probar las contraseñas solo funciona cuando las contraseñas son adivinables. Entonces, cuando un usuario tiene la contraseña "pw123", su sistema se vuelve inseguro. Otro problema con las contraseñas elegidas por las personas es que sus contraseñas nunca son realmente aleatorias porque eso sería difícil de recordar.

También es el caso de que los usuarios tienden a reutilizar sus contraseñas, usándolas para iniciar sesión en Facebook o sus cuentas de Gmail y para su servidor. Entonces, cuando un hacker obtiene la contraseña de la cuenta de Facebook de este usuario, puede ingresar a su servidor. El usuario podría perderlo fácilmente mediante phishing o el servidor de Facebook podría ser pirateado.

Pero cuando usa un certificado para iniciar sesión, el usuario no elige su contraseña. El certificado se basa en una cadena aleatoria que es muy larga desde 1024 Bits hasta 4096 Bits (~ 128 - 512 caracteres de contraseña). Además, este certificado solo está allí para iniciar sesión en su servidor y no se utiliza con ningún servicio externo.

Enlaces

http://bsdly.blogspot.de/2013/10/the-hail-mary-cloud-and-lessons-learned.html

Este artículo proviene de los comentarios y quería darle una posición un poco más prominente, ya que profundiza un poco más en el tema de las botnets que intentan iniciar sesión a través de SSH, cómo lo hacen, cómo se ven los archivos de registro y qué se puede hacer para detenerlos. Ha sido escrito por Peter Hansteen.

— Raphael Ahrens
fuente

10

Buen resumen Pero las claves privadas ssh también pueden ser robadas.

— Faheem Mitha

16

@Faheem Mitha Sí, pero robado es diferente de adivinado, lo que hacen los bots. Además, su clave privada solo está en sus manos (o disco duro) y no en manos de terceros como Stack Exchange o Google.

— Raphael Ahrens

2

+1. Esta respuesta en realidad podría reducirse a simplemente N*M > N. Dado que la mayoría de los hosts * nix tienen un rootusuario, si permite que root inicie sesión directamente desde un host remoto, el tamaño de la matriz de prueba es la cantidad de contraseñas que debe probar; Al no permitir inicios de sesión de raíz directos, la cantidad de combinaciones posibles se multiplica por la cantidad de nombres de usuario que desea probar (¡y todavía no hay garantía de que probará nombres de usuario válidos!).

— un CVn

3

@ MichaelKjörling Agregaría que no es difícil obtener el nombre de usuario, ya que normalmente el nombre de usuario no es secreto y probablemente podría pedirle a cualquiera que lo obtenga. Pero ayuda contra Bots y el simple intento.

— Raphael Ahrens

2

@ Todos, si el nombre de usuario tiene símbolos X y la contraseña Y, hay # of X length words* # of Y length wordscombinaciones posibles para probar. Cuando el nombre de usuario es fijo (por ejemplo, root) pero la contraseña tiene una longitud de símbolos X + Y, existen # of X+Y length wordsposibles contraseñas. Y # of X+Y length words=# of X length words * # of Y length words

— skarap

10

Estas podrían ser algunas de las razones por las que no se debe permitir el inicio de sesión raíz directo.

Intentos de fuerza bruta. El inicio de sesión de root directo podría provocar más daños en un ataque de fuerza bruta exitoso.
La configuración incorrecta en las claves SSH "sin contraseña" (se produce un error humano) podría exponer su máquina a Internet

Pero esto es solo el CONSEJO del iceberg. Necesita configurar otras restricciones y configuraciones como:

Cambiar el puerto predeterminado (22)
Contraseñas seguras y frase de contraseña
Deshabilitar autenticación basada en host
Crear una lista de usuarios permitidos
Configurar tiempo de espera inactivo
Forzar el protocolo SSHv2
Deshabilitar contraseñas vacías
Utilice fail2ban como medida contra la fuerza bruta
Registrar todo
Configure las claves SSH y confíe solo en las claves públicas en .ssh / Authorizedkeke

55

"El inicio de sesión de root directo podría provocar más daños en un ataque de fuerza bruta exitoso". En realidad no, si se compara con una sudoconfiguración predeterminada . El verdadero asesino es el efecto multiplicador cuando no tienes ningún nombre de usuario con el que puedas contar para que sea válido en cualquier host.

— un CVn

@ MichaelKjörling - Sí, seguro que el sudo desordenado podría ser tan dañino como PermitRoot;)

Ver unix.stackexchange.com/a/2944/9454

— Restablecer Monica - M. Schröder

1

Cambiar el puerto es realmente perjudicial en muchos escenarios en sí mismo. Y tampoco es más que seguridad por oscuridad.

— 0xC0000022L

+1 por mencionar fail2ban, ya que los ataques de fuerza bruta no son solo una preocupación para SSH, sino para cualquier otra cosa en la máquina. No necesita obtener permisos de root o del sistema para "hacerse cargo" de una máquina con fines prácticos (acceder a datos privados, usar como volcado de archivos, usar para phishing, etc.).

— Eric Grange

8

Tiene razón en que el nombre de usuario raíz y la contraseña del símbolo X + Y es criptográficamente al menos tan seguro como un nombre de usuario del símbolo X + contraseña del símbolo Y. De hecho, es aún más seguro, porque los nombres de las personas son fáciles de adivinar (los bots pueden simplemente intentar con john, mike, bill, etc ... y por cierto: eso es lo que hacen muchos de ellos en lugar de probar root). Y no tienes suerte si se trata de un ataque dirigido, porque si alguien quiere romper el servidor de una empresa, no sería un problema averiguar el nombre (nick) del administrador del sistema.

Y tan pronto como el atacante tenga acceso a la cuenta que usa el administrador del sistema para los inicios de sesión de ssh (y luego usa suo sudopara realizar sus tareas), puede infectar la sesión de ese usuario con un programa que enviará la contraseña de root del atacante cuando el administrador del sistema escriba el siguiente hora.

Es cualquier tipo de inicio de sesión raíz que se considera (o debería considerarse) una mala práctica desde el punto de vista de la seguridad. El inicio de sesión de usuario "normal" -> su / sudo chain agrega una pista de auditoría. En inglés simple: permite descubrir quién hizo qué.

Un caso especial puede ser aquel en el que solo una persona tiene acceso de root. En ese caso, usar el usuario "normal" adicional no agregará mucho valor (al menos nunca pude ver ese valor). Pero de todos modos, se supone que debe tener un usuario simple en el sistema de todos modos (para tareas no administrativas, ejecutar wget, etc.).

— skarap
fuente

4

¿Qué es tan peligroso al habilitar el inicio de sesión raíz (especialmente con el inicio de sesión de contraseña deshabilitado)?

El atacante (bot / botnet / hacker) solo necesita adivinar la contraseña y tiene control completo sobre su sistema, si está abierto a Internet. Además, ninguna de las cuentas del sistema (www-data, proxy, etc.) debería poder iniciar sesión a través de SSH, por las mismas razones.

Si desactivó el inicio de sesión con contraseña (usando la clave pública, por ejemplo), tenga en cuenta que quien tenga acceso a la clave privada tiene el control total sobre su sistema. Vea por qué es mejor usar la clave pública con un usuario a continuación.

¿Y cuál es la diferencia entre el nombre de usuario del símbolo X y la contraseña del símbolo Y o el nombre de usuario raíz y la contraseña del símbolo X + Y desde el punto de vista de la seguridad en caso de que se permita la autenticación de contraseña?

El nombre de usuario adicional puede agregar una capa de seguridad ya que: a) el atacante debe conocer tanto el par, el nombre de usuario y la contraseña; b) en caso de que el atacante viole su sistema, no tendría acceso inmediato a una cuenta privilegiada, lo que agregaría un poco de matiz al atacante.

En este caso, la clave pública también es una ventaja, ya que:

El atacante necesita tu clave pública
El atacante necesita la contraseña (o método de autenticación) para obtener privilegios elevados

— Braiam
fuente

1

Muy pocas de las contraseñas que uso tienen menos de 20 caracteres alfanuméricos aleatorios (conjunto [A-Za-z0-9] más algunos caracteres especiales). 20 de esos caracteres (de modo que la longitud 20 de un conjunto de caracteres de 40) le da el orden de 10 ^ 32 combinaciones. 128 bits de entropía son del orden de 10 ^ 38. No es una gran diferencia, considerando todo, y el servidor SSH es libre de implementar cualquier tipo de limitación de velocidad que le guste, por lo que no es como si estuviera haciendo un ataque de fuerza bruta fuera de línea en ese caso. No hay nada de malo en las contraseñas, si puedes vivir con ellas siendo tan difíciles de recordar como una clave de 128 bits.

— un CVn

@michael shh ... no le des rango, ahora los hackers saben que deberían usar tablas de arco iris del orden de 20 caracteres de longitud ...?

— Braiam

66

Las tablas de @Braiam Rainbow solo son útiles si el atacante tiene acceso a los hashes para realizar una búsqueda sin conexión. En el caso aquí, el atacante solo tiene que verificar la respuesta del servidor, lo que probablemente se limita a solo algunos intentos, y mucho más lento.

— Peter

@Peter ups, ensucié el diccionario y los hash, pero en cualquier caso el OP me preguntó por qué no debería usar contraseñas débiles o vacías, la bruja es ridícula, por lo tanto, llegué a situaciones ridículas por las que no debería. Lamento no haber sido interpretado de esa manera y fue tomado como FUD.

— Braiam

2

Si tiene ganas de probar algunas contraseñas 1.8 * 10 ^ 35 (y eso es solo para el rango de 18-22 caracteres aleatorios de un conjunto de 40, y no sabe qué caracteres están fuera del conjunto [A-Za-z0- 9] Yo uso), casi dije que se diviertan. Eso es aproximadamente 117.1 bits de entropía equivalente (2 ^ 117.1 ~ 1.78 * 10 ^ 35) y, como señaló @Peter, lo más probable es que necesite realizar un ataque en línea . El almacenamiento de todas esas contraseñas (sin recurrir a la compresión) parece necesitar aproximadamente 3.6 * 10 ^ 36 bytes o 3 * 10 ^ 24 TiB (y si esa cifra es incorrecta en algunos órdenes de magnitud, ¿a quién le importa? ). Palabra clave al azar .

— un CVn

1

No es exactamente malo siempre que tome precauciones de seguridad. Como ejemplo, podría instalar CSF (Configure Server Firewall) y establecer el número de intentos de falla permitidos, por lo que si alguien lo intentó, ¿digamos más de 5 intentos de falla ?, entonces se bloquean automáticamente. Entonces, la primera parte completa del mejor respondedor no será un problema en absoluto. Esto me sucedió muchas veces, y afortunadamente todos los presentadores fueron bloqueados permanentemente. Supongo que para un servidor no es un gran problema si usted es la única persona que administra el servidor, pero, por supuesto, si hay muchos administradores de sistemas o si está trabajando en una organización, obviamente no use raíz. También para una PC de escritorio, supongo que usar otra cuenta es mejor ya que existe un riesgo de seguridad ya que usa mucho software, pero en un servidor, no No elija software aleatorio en el que no confíe, asegúrese de mantenerlo lo más bajo posible. Entonces, la conclusión es que no, no es realmente dañino si sabes cómo administrar un servidor correctamente.

— Don Dilanga
fuente