Pregunta:
Me gustaría tener la cuenta de root en un lugar seguro incluso si mi usuario sin privilegios está comprometido.
En Ubuntu, solo puede usar sudo por "razones de seguridad" de forma predeterminada. Sin embargo, no estoy seguro de que sea más seguro que simplemente usar el inicio de sesión en una consola en modo texto. Hay demasiadas cosas que pueden salir mal si un atacante puede ejecutar código como mi usuario normal. Por ejemplo, agregando alias, agregando cosas a mi PATH, configurando los keyloggers LD_PRELOAD y X11, solo por mencionar algunos. La única ventaja que puedo ver es el tiempo de espera, así que nunca me olvido de cerrar la sesión.
Tengo las mismas dudas sobre su pero ni siquiera tiene límite de tiempo. Algunas operaciones (especialmente la redirección de IO) son más convenientes con su, pero en términos de seguridad, esto parece ser peor.
El inicio de sesión en una consola en modo texto parece ser el más seguro. Dado que se inicia con init, si un atacante puede controlar PATH o LD_PRELOAD, ya es root. Los eventos de pulsación de tecla no pueden ser interceptados por programas que se ejecutan en X. No sé si los programas que se ejecutan en X pueden interceptar [ctrl] + [alt] + [f1] (y abrir una ventana de pantalla completa que parece una consola) o es seguro como [ctrl] + [alt] + [del] en Windows. Además de eso, el único problema que veo es la falta de tiempo de espera.
Entonces, ¿me estoy perdiendo algo? ¿Por qué los chicos de Ubuntu decidieron permitir solo sudo? ¿Qué puedo hacer para mejorar la seguridad de cualquiera de los métodos?
¿Y SSH? Tradicionalmente, el root no puede iniciar sesión a través de SSH. Pero usando la lógica anterior, ¿no sería esto lo más seguro?
- permitir root a través de SSH
- cambiar al modo de texto
- iniciar sesión como root
- ssh a la otra máquina
- iniciar sesión como root?
Respuesta:
La seguridad siempre se trata de hacer concesiones. Al igual que el proverbial servidor que se encuentra en un lugar seguro, desconectado, en el fondo del océano, la root sería más segura si no hubiera forma de acceder a él.
Los ataques LD_PRELOAD y PATH como los que describe asumen que ya hay un atacante con acceso a su cuenta, o al menos a sus dotfiles. Sudo no protege muy bien contra eso, después de todo, si tienen tu contraseña, no es necesario que intentes engañarte para más tarde … pueden usar sudo ahora .
Es importante tener en cuenta para qué se diseñó Sudo originalmente: delegación de comandos específicos (como aquellos para administrar impresoras) a "subadministradores" (tal vez estudiantes de posgrado en un laboratorio) sin revelar la raíz por completo. Usar sudo para hacer todo es el uso más común que veo ahora, pero no es necesariamente el problema que el programa estaba destinado a resolver (de ahí la sintaxis del archivo de configuración ridículamente complicada).
Pero, sudo-por-sin restricciones de la raíz hace dirección de otro problema de seguridad: gestión de las contraseñas de root. En muchas organizaciones, estos tienden a pasarse como si fueran caramelos, escribirse en pizarrones y dejarlos iguales para siempre. Eso deja una gran vulnerabilidad, ya que revocar o cambiar el acceso se convierte en un gran número de producción. Incluso realizar un seguimiento de qué máquina tiene qué contraseña es un desafío, y mucho menos rastrear quién sabe cuál.
Recuerde que la mayoría de los "delitos cibernéticos" provienen de adentro. Con la situación de la contraseña de root descrita, es difícil rastrear quién hizo qué; algo que sudo con el registro remoto maneja bastante bien.
En su sistema doméstico, creo que es más una cuestión de la conveniencia de no tener que recordar dos contraseñas. Es probable que muchas personas simplemente los hayan configurado para que sean iguales, o peor aún, configurándolos para que sean iguales inicialmente y luego dejándolos desincronizados, dejando que la contraseña de root se pudra.
El uso de contraseñas en absoluto para SSH es peligroso, ya que los demonios ssh troyanizado contraseña detectores se ponen en marcha en algo así como el 90% del sistema del mundo real compromisos que he visto. Es mucho mejor usar claves SSH, y este también puede ser un sistema viable para el acceso remoto a la raíz.
Pero el problema es que ahora ha pasado de la administración de contraseñas a la administración de claves, y las claves ssh no son realmente muy manejables. No hay forma de restringir las copias, y si alguien hace una copia, tiene todos los intentos que quiera para forzar la frase de contraseña. Puede establecer una política que diga que las claves deben almacenarse en dispositivos extraíbles y montarse solo cuando sea necesario, pero no hay forma de hacer cumplir eso, y ahora ha introducido la posibilidad de que un dispositivo extraíble se pierda o sea robado.
La seguridad más alta vendrá a través de claves únicas o tokens criptográficos basados en tiempo / contador. Esto se puede hacer en software, pero el hardware a prueba de manipulaciones es aún mejor. En el mundo del código abierto, está WiKiD , YubiKey o LinOTP y, por supuesto, también está el RSA SecurID patentado de peso pesado. Si está en una organización mediana a grande, o incluso en una pequeña consciente de la seguridad, le recomiendo que busque uno de estos enfoques para el acceso administrativo.
Sin embargo, probablemente sea excesivo para el hogar, donde realmente no tiene las molestias de administración, siempre y cuando siga prácticas de seguridad sensatas.