Me gustaría tener la cuenta raíz segura 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, agregar alias, agregar cosas a mi RUTA, configurar registradores de teclas LD_PRELOAD y X11 solo por mencionar algunos. La única ventaja que puedo ver es el tiempo de espera, por lo 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 E/S) son más convenientes con su, pero en cuanto a la seguridad, esto parece ser peor.
Iniciar sesión en una consola en modo texto parece ser lo más seguro. Como lo inicia init, si un atacante puede controlar PATH o LD_PRELOAD, ya es root. Los eventos de pulsación de teclas 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?
¿Qué pasa con SSH? Tradicionalmente, la raíz no puede iniciar sesión a través de SSH. Pero usar la lógica anterior, ¿no sería esto lo más seguro?
- permitir la raíz 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 aceptada:
La seguridad siempre consiste en hacer concesiones. Al igual que el servidor proverbial que está en un lugar seguro, desenchufado, en el fondo del océano, root sería la mayoría seguro si no hubiera forma de acceder a él en absoluto.
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 archivos de puntos. Sudo no protege muy bien contra eso. Si tienen tu contraseña, después de todo, no es necesario que intenten engañarte para más tarde... simplemente pueden usar sudo. ahora .
Es importante tener en cuenta para qué se diseñó originalmente Sudo:delegación de específicos comandos (como los de administrar impresoras) a "subadministradores" (quizás estudiantes graduados en un laboratorio) sin revelar la raíz por completo. Usando sudo para hacer todo es el uso más común que veo ahora, pero no es necesariamente el problema que el programa debía resolver (de ahí la sintaxis del archivo de configuración ridículamente complicada).
Pero, sudo-for-unrestricted-root sí abordar otro problema de seguridad:la capacidad de administración de las contraseñas de root. En muchas organizaciones, estos tienden a distribuirse como dulces, se escriben en pizarras y se dejan igual 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 hacer un seguimiento de qué máquina tiene qué contraseña es un desafío, y mucho menos rastrear quién sabe cuál.
Relacionado:¿Qué obtendría cuando sudo un programa destructivo del kernel?Recuerde que la mayoría de los "delitos cibernéticos" provienen de adentro. Con la situación de la contraseña raíz descrita, es difícil rastrear quién hizo qué; algo que sudo con el registro remoto funciona bastante bien.
En su sistema doméstico, creo que en realidad se trata más de la conveniencia de no tener que recordar dos contraseñas. Es probable que muchas personas simplemente los configuraran para que fueran iguales, o peor aún, los configuraron para que fueran iguales inicialmente y luego dejaron que se desincronizaran, dejando que la contraseña de root se pudriera.
Usar contraseñas en absoluto para SSH es peligroso, ya que los demonios ssh troyanos rastreadores de contraseñas se colocan en algo así como el 90% de los compromisos del sistema del mundo real que he visto. Es mucho mejor usar claves SSH, y este también puede ser un sistema viable para el acceso raíz remoto.
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 crear una política que diga que las claves deben almacenarse en dispositivos extraíbles y solo montarse 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 mayor seguridad vendrá a través de claves de un solo uso o fichas criptográficas basadas en tiempo/contador. Esto se puede hacer en el software, pero el hardware a prueba de manipulaciones es aún mejor. En el mundo del código abierto, están WiKiD, YubiKey o LinOTP y, por supuesto, también está el RSA SecurID patentado de peso pesado. Si se encuentra en una organización mediana o grande, o incluso en una pequeña preocupada por la seguridad, le recomiendo buscar uno de estos enfoques para el acceso administrativo.
Sin embargo, probablemente sea excesivo para el hogar, donde realmente no tiene los problemas de administración, siempre que siga prácticas de seguridad sensatas.