Me gustaría tener la cuenta raíz segura incluso si mi usuario no privilegiado 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 LD_PRELOAD y keyloggers X11 solo por mencionar algunos. La única ventaja que puedo ver es el tiempo de espera, por lo que nunca olvido cerrar 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 términos de seguridad, esto parece ser peor.
Iniciar sesión en una consola en modo texto parece ser el más seguro. Dado que se inicia por init si un atacante puede controlar PATH o LD_PRELOAD, él 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 se parece a 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é hay de SSH? Tradicionalmente, la raíz no puede iniciar sesión a través de SSH. Pero usar la lógica anterior no sería 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?
Respuestas:
La seguridad siempre se trata de hacer compensaciones. Al igual que el servidor proverbial que se encuentra en un lugar seguro, desconectado, en el fondo del océano,
root
sería más seguro si no hubiera forma de acceder a él.Los ataques LD_PRELOAD y PATH como los que usted describe asumen que ya hay un atacante con acceso a su cuenta, o al menos a sus archivos de puntos. Sudo no protege contra las que muy bien a todos - si tienen su contraseña, después de todo, no hay necesidad de tratar de engañar a usted para más adelante ... sólo se puede utilizar
sudo
ahora .Es importante tener en cuenta para qué se diseñó originalmente Sudo: delegación de comandos específicos (como aquellos para administrar impresoras) a "subadministradores" (tal vez estudiantes graduados en un laboratorio) sin entregar 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 ridículamente complicada del archivo de configuración).
Pero, sudo-para-sin restricciones de la raíz hace frente a otro problema de seguridad: gestión de las contraseñas de root. En muchas organizaciones, estos tienden a pasarse como dulces, se escriben en pizarras y se dejan 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.
Recuerde que la mayoría de los "delitos cibernéticos" provienen del interior. 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 trata bastante bien.
En su sistema doméstico, creo que es más una cuestión de conveniencia de no tener que recordar dos contraseñas. Es probable que muchas personas simplemente los configuraran para que fueran iguales, o peor, al principio para que fueran iguales y luego dejaran de sincronizarse, dejando que la contraseña de root se pudriera.
El uso de contraseñas en absoluto para SSH es peligroso, ya que la contraseña detectores de demonios ssh con troyanos se puso en marcha 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 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, tienen todos los intentos que desean para forzar la frase de contraseña. Puede hacer 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 una sola vez o tokens criptográficos basados en tiempo / contador. Esto se puede hacer en software, pero el hardware resistente a la manipulación es aún mejor. En el mundo de código abierto, está WiKiD , YubiKey o LinOTP , y por supuesto también está el SecurID RSA de peso pesado patentado . Si está en una organización de mediana a grande, o incluso en una pequeña que se preocupa por 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 los problemas de administración, siempre que siga prácticas de seguridad sensatas.
fuente
sudo
es muy similar al Control de cuentas de usuario en Windows Vista. Ambos en realidad están diseñados no para aumentar la seguridad, sino para facilitar la disminución de manera controlada. Pero debido a que hacen que sea más fácil elevar temporalmente sus privilegios de una manera de baja fricción, no necesita correr con privilegios elevados durante períodos prolongados de tiempo, lo que aumenta la seguridad. (Esto no era tan grande de un problema en Unix, pero en Windows Me acuerdo ejecutando como administrador durante varios días, sólo porque el cambio fue tan doloroso.)root
contraseñas de su empresa también se mencionan como el elemento final en el Informe de Operaciones , que vale la pena leer.Esta es una pregunta muy compleja. mattdm ya ha cubierto muchos puntos .
Entre su y sudo, cuando considera a un solo usuario, su es un poco más seguro porque un atacante que ha encontrado su contraseña no puede obtener privilegios de root de inmediato. Pero todo lo que se necesita es que el atacante encuentre un agujero raíz local (relativamente poco común) o instale un troyano y espere a que ejecute su.
Sudo tiene ventajas incluso sobre un inicio de sesión de consola cuando hay varios usuarios. Por ejemplo, si un sistema está configurado con registros remotos a prueba de manipulaciones, siempre puede averiguar quién ejecutó sudo por última vez (o cuya cuenta se vio comprometida), pero no sabe quién escribió la contraseña de root en la consola.
Sospecho que la decisión de Ubuntu fue en parte por la simplicidad (solo una contraseña para recordar) y en parte por la seguridad y la facilidad de distribución de credenciales en máquinas compartidas (empresa o familia).
Linux no tiene una clave de atención segura u otra interfaz de usuario segura para la autenticación. Hasta donde sé, incluso OpenBSD no tiene ninguno. Si está tan preocupado por el acceso a la raíz, puede deshabilitar el acceso a la raíz desde un sistema en ejecución por completo: si desea ser root, deberá escribir algo en el indicador del gestor de arranque. Obviamente, esto no es adecuado para todos los casos de uso. (* El nivel seguro de BSD funciona así: a un nivel alto seguro, hay cosas que no puede hacer sin reiniciar, como bajar el nivel seguro o acceder directamente a los dispositivos en bruto montados).
Restringir las formas en que uno puede convertirse en root no siempre es una ganancia para la seguridad. Recuerde al tercer miembro de la tríada de seguridad : confidencialidad , integridad , disponibilidad . Bloquearse fuera de su sistema puede evitar que responda a un incidente.
fuente
Los diseñadores de la distribución segura de OpenWall GNU / * / Linux también han expresado opiniones críticas sobre
su
(para convertirse en root) ysudo
. Quizás te interese leer este hilo:... desafortunadamente tanto su como sudo son sutil pero fundamentalmente defectuosos.
Además de discutir los defectos
su
y otras cosas, Solar Designer también apunta a una razón específica para usarsu
:En su distribución, se han "eliminado completamente de los programas raíz SUID en la instalación predeterminada" (es decir, incluida
su
; y no usan capacidades para esto):Por cierto, que eran para reemplazar
sulogin
conmsulogin
permitir que el programa de instalación con múltiples cuentas root:msulogin
permite escribir el nombre de usuario también al entrar en el modo de usuario único (y preservar la "rendición de cuentas") (esta información proviene de esta discusión en ruso ) .fuente
Parece suponer que el uso
sudo
siempre preserva las variables de entorno, pero este no es siempre el caso. Aquí hay un extracto de la página de manual de sudo:Entonces, si
env_reset
está habilitado (el valor predeterminado), un atacante no puede anular suPATH
u otras variables de entorno (a menos que las agregue específicamente a una lista blanca de variables que deben conservarse).fuente
Password:
no muestra nada cuando escribo, le envía lo que escribí, dice que la contraseña es incorrecta y luego ejecuta el sudo real.alias /usr/bin/sudo="echo pwned"
además de que hay un montón de programas involucrados (X, xterm, el shell), cualquiera de los cuales puede robar la contraseña. Es por eso que dije que hay demasiados problemas para cambiar de forma segura.bash: alias: `/usr/bin/sudo': invalid alias name
El enfoque más seguro es el inicio de sesión ssh utilizando (al menos) la clave larga 2048 (con el inicio de sesión con contraseña desactivado) utilizando un dispositivo físico para almacenar la clave.
fuente
Solo quiero agregar algo un poco fuera de tema. (para el tema uno marque '/ bin / su -' aquí después)
Creo que la "seguridad" anterior también debe estar vinculada a los datos reales que queremos proteger.
Lo hará y debería ser diferente si queremos asegurar: my_data, my_company_data, my_company_network.
Por lo general, si hablo de seguridad, también hablo de "seguridad de datos" y respaldo. También podemos agregar sistemas tolerantes a fallas y similares.
Dado esto, creo que la seguridad en su conjunto es un equilibrio entre la usabilidad, la "seguridad de los datos" y el esfuerzo requerido para implementar un sistema seguro.
El objetivo de Ubuntu era, y sigue siendo, el usuario final: Sudo es el valor predeterminado.
Fedora es la versión gratuita de RedHat que a su vez está más orientada a servidores: Sudo solía estar deshabilitado.
Para las otras distribuciones no tengo información directa.
Estoy usando en este momento, principalmente, fedora. Y como usuario de estilo antiguo, nunca escribí 'su'. Pero puedo escribir "/ bin / su -" en muy poco tiempo, incluso si no soy exactamente un mecanógrafo. La variable PATH ... no debería ser un problema (escribo la ruta). Además, el "-" (menos) en principio debería eliminar las variables de entorno de mi usuario y cargar solo las raíz. es decir, evitar algunos posibles problemas adicionales. Probablemente también el LS_PRELOAD.
Por lo demás, supongo que @mattdm fue bastante preciso.
Pero vamos a ponerlo en la casilla correcta. Suponga que un kit inteligente de secuencias de comandos obtiene acceso a mis datos. ¿Qué demonios crees que va a hacer con eso? - Publicar mis fotos? ¿mi? - ¿Tratando de averiguar el nombre de mi novia y decirle que visito sitios pornográficos?
En la imagen de un solo usuario, las dos peores situaciones son: - El niño borra todos mis datos: por diversión o por error - El niño usa mi máquina para crear un ataque adicional a otra entidad. O objetivos similares.
Para el primer caso, mencioné anteriormente, es mejor poner esfuerzos en una copia de seguridad que en la seguridad de la red. Sí, estás a salvo. Quiero decir que un bloqueo de hardware no es tan diferente.
El segundo caso es más sutil. Pero hay señales sobre estas actividades. En cualquier caso, puede hacer lo posible, ¡pero no configuraría la PC de mi hogar para que esté protegida contra ataques terroristas!
Me saltearé los otros escenarios.
aclamaciones F
fuente
Si la preocupación es que se puede usar una cuenta de usuario comprometida para rastrear la contraseña utilizada para
sudo
osu
, entonces use un código de acceso único parasudo
ysu
.Puede forzar el uso de claves para usuarios remotos, pero es posible que no se apruebe para fines de cumplimiento. Podría ser más efectivo configurar una caja de puerta de enlace SSH que requiera autenticación de dos factores, luego permitir el uso de la clave desde allí. Aquí hay un documento sobre dicha configuración: asegure su implementación SSH con la autenticación de dos factores WiKID .
fuente
También puede echar un vistazo a privacyIDEA , que no solo le brinda la posibilidad de usar OTP para iniciar sesión en la máquina (o para hacer su / sudo) sino que también puede hacer OTP sin conexión.
Además, es capaz de administrar sus claves SSH. Es decir, si tiene muchas máquinas y varios usuarios root, todas las claves SSH se almacenan centralmente. Por lo tanto, es fácil "revocar" / eliminar una clave SSH, si ya no se puede confiar en la clave.
Por supuesto, hay tareas organizativas y flujos de trabajo para asegurar el sistema.
fuente