¿Por qué la cuenta de administrador del sistema * nix (root) tiene una contraseña segura si se inhabilitan los inicios de sesión remotos?

Si sigue el principio de privilegios mínimos y seguridad en capas, debe asegurarse de que en cada nivel de un sistema implemente medidas de seguridad sólidas. En cada nivel significa que no hace ninguna suposición sobre qué tan fácil o difícil puede ser para un atacante llegar a ese nivel en primer lugar.

Cuando escribes

  

Como consecuencia de lo anterior, para obtener acceso a la raíz de forma remota, primero   necesidad de entrar en la cuenta de un usuario ordinario, entonces, además,   escalar a la raíz de acceso. En este caso, la contraseña en la raíz.   La cuenta solo protege contra un ataque de craqueo de contraseña en la raíz   cuenta, no ninguna de las otras múltiples formas posibles de   atacante para escalar privilegios.

tienes toda la razón, pero ¿por qué dices

  

solo protege contra un ataque de descifrado de contraseñas

? Una contraseña segura elimina este vector de ataque, incluso si quedan otros vectores de ataque para aumentar los privilegios. Por supuesto, los otros vectores de ataque también deben cuidarse.

La contraseña de root es la protección para evitar que los usuarios normales puedan iniciar comandos administrativos. El único caso en el que la contraseña de root podría ser débil es si cualquier usuario en el sistema (incluido daemon usuarios como www o postgresql) puede usar sudo para obtener acceso administrativo sin contraseña, o más precisamente tener un la contraseña de root es más o menos equivalente a la configuración weird

Porque incluso el sudo normal requiere que el usuario:

• tiene una contraseña normal (los usuarios del daemon generalmente tienen una contraseña rechazar todas )
• conoce su propia contraseña

Entonces, si un atacante infringe la seguridad de una aplicación y obtiene acceso a un usuario no root, aún tendrá que encontrar una contraseña para obtener acceso de root. Y si la contraseña de root es débil, será mucho más sencillo pasar esa segunda barrera.

En tu pregunta, solo has cubierto dos áreas: el aspecto físico y los ataques de un atacante normal . Si el atacante está más determinado o mejor financiado, es seguro asumir que tiene acceso a ataques más sofisticados, tal vez incluso entre días no revelados. Si su sistema está dañado, como dijo, todavía hay docenas de formas en que un atacante podría escalar sus privilegios, pero ¿por qué no probar algunas contraseñas fáciles para escalar privilegios? (Me encanta un MD5 que comienza con 5f4d.. :))

Además, muchos usuarios (incluso los administradores preocupados por la seguridad) tienden a reutilizar las contraseñas. Eso es un hecho bien conocido. Al solicitar que la cuenta raíz tenga una contraseña compleja, está reduciendo las posibilidades de que el administrador desee escribir esa cadena nuevamente en otras aplicaciones, lo que podría no almacenar las contraseñas de forma segura. Este tipo de reduce la posibilidad de reutilizar la contraseña.

Como alguien en las respuestas vinculadas ya mencionadas, simplemente puede atacar al usuario de diferentes maneras (dejar que descarguen un binario de puerta trasera, MITM su tráfico y luego intentar iniciar sesión en una cuenta alternativa creada por el mismo usuario, crear una aplicación maliciosa (sí, esto suena inverosímil, pero - hey.)

Pondré mi cabeza en el bloque de corte - En la mayoría de tus casos, no creo que realmente debas preocuparte por tu contraseña de root . Si tiene confianza en el resto de sus hábitos de seguridad, entonces nadie puede impedirle usar password123# (solo envíeme un enlace a su servidor: P)

Esto también tiene un aspecto legal. Si su servidor fue violado, y en la investigación posterior se encontró que su contraseña de root era débil, es posible que las sanciones impuestas se incrementen, debido a una falta de debida diligencia percibida, aunque, como se señaló anteriormente, el real El riesgo es mínimo. Es un razonamiento similar detrás de los problemas de seguridad, tanto en las computadoras como en otros: los riesgos de tener las contraseñas de los servidores escritas en una sala segura que tiene un acceso restringido totalmente forzado son mínimos, pero si los guarda en un escritorio allí, en lugar de en un caja bloqueada / cajón, es posible que las auditorías lo detecten.

Incluso si el riesgo legal no se aplicara, hay argumentos similares para los posibles aspectos de reputación. La mayoría de las personas que leen este sitio saben que los riesgos reales son mínimos, dadas las otras precauciones que se implementan correctamente, pero son una minoría. Tenga en cuenta que es bastante conocido que durante mucho tiempo los códigos de lanzamiento nuclear para los EE. UU. Fueron "00000000", pero obtener acceso a un sistema que le permitió ingresarlos no fue trivial. Los informes sobre este tema tienden a centrarse en "mirar". la contraseña realmente fácil de adivinar "en lugar de" si obtuvo el acceso adecuado, desde una red estrechamente controlada, y convenció al personal de servicio de que estaba autorizado y tenía las credenciales anteriores apropiadas, podría lanzar un misil presionando y sosteniendo 0 ".

Hay una alternativa donde no necesita esa contraseña segura: bloquear la cuenta de root.

En ese caso, podría salirse sin establecer una contraseña segura para esa cuenta. En realidad, probablemente haría ambas cosas, porque no requiere mucho esfuerzo.

Vea enlace para una discusión sobre esto.

En general, tiene más sentido ver qué puede hacer el sudo por ti, que proporcionarle la capacidad de su - root .

Un área clave donde esto es importante es la auditoría: con sudo (incluso si alguien ejecuta sudo -i o sudo su - root ), aún puede obtener información sobre el usuario real haciendo todo esto (registrado por auditd como el AUID).