☰

¿Por qué sería una mala idea tener un usuario sin contraseña (en este escenario)?

tag-icon • tag-icon security users password non-root-user privileges
¿Por qué sería una mala idea tener un usuario sin contraseña (en este escenario)?

Pensé en publicar esto aquí o en seguridad SE... pero decidí optar por Unix SE, ya que en realidad no se trata de cuestiones de criptografía, sino más bien de usuarios/privilegios de Linux. Tal vez mi google-fu esté débil hoy, pero las únicas cosas que he encontrado hasta ahora tampoco

  1. tener respuestas muy generales sobre que es una "mala práctica" o "mal vista" sin ningún ejemplo concreto, o
  2. tienen respuestas que asumen que el usuario sin contraseña tiene acceso root o está desechando todas las protecciones posibles.

Para ser claro: no estoy defendiendo esto y en realidad busco razones válidas.nohacer esto, pero me gustaría encontrar razones concretas de por qué en lugar de simplemente "es malo". :-)

Dejando eso de lado, permítanme establecer el ejemplo que realmente me hizo pensar en esto en primer lugar:

Digamos que estoy considerando configurar un sistema doméstico donde tengo una contraseña segura en la rootcuenta. Además tendré uncuenta no root llamada fredeso esNOen el grupo de administración wheel(o sudoersen Debian/Ubuntu). En este sistema, también tendré /homeuna partición separada cifrada con LUKS que se desbloquea durante el proceso de arranque. En otras palabras, una contraseñahacetodavía se ingresa entre GRUB y el administrador de inicio de sesión, pero el administrador de inicio de sesión está configurado para iniciar sesión automáticamente. Más allá de esto, digamos que también configuro (desde la raíz): password -f -u fredparaforzar desbloqueola contraseña para fred(efectivamente hacer fredque tenga una contraseña vacía).

¿Qué tipo de problemas de seguridad podría encontrarme en esta situación? Parece que debería haber alguna buena razón por la que no quieras hacer esto.Pero elsoloLo que me viene a la mente hasta ahora es:

  • Las particiones LUKS no se cierran cuando se activa el bloqueo del protector de pantalla (al menos, no en Cinnamon y asumiendo unaesconfigurado para disparar). Entonces, si alguien irrumpió en mi casa y fredya había iniciado sesión, podría simplemente sentarse y encender el monitor y luego proceder a revisar cualquier cosa freda la que tenga acceso, siempre y cuando no haya desconectado/reiniciado/apagado la PC primero ( y así volver a bloquear LUKS). Y sospecho que si me esforzara lo suficiente, tal vez podría encontrar una manera de llamar a un script cuando se activa el protector de pantalla y luego bloquear LUKS de dicho script, cerrando así este agujero (o tal vez kde/xfce/gnome/etc ya tenga alguna manera). encargarse de esto?).

Incluso si fredtuviera una contraseña segura y agradable, no podría instalar software ni alterar la configuración del sistema sin ser administrador. Y no lo sé con certeza, pero creo que el acceso del navegador/Wine a los archivos no se cambiaría de ninguna manera. ¿Hay algo más en riesgo aquí que sifred hizotienes una contraseña?

Editar: No creo que importe, pero la distribución es Fedora (con SELinux activado), pero si te sientes más cómodo respondiendo con respecto a otra distribución (o sin SELinux), está bien.

Edición #2: Respecto a ssh/ samba. Generalmente configuro algo así como una /media/sdb1/sharedcarpeta en lugar de usar $HOMErecursos compartidos de samba o como se llamen. Encuentro que esto es bastante fácil de configurar en un entorno de usuario pequeño como en casa (obviamente no haría esto en un entorno de trabajo o en un entorno donde no todos los usuarios confían entre sí). Pero siempre uso cuentas de usuario de samba separadas y protegidas con contraseña (no los mismos usuarios con los que inician sesión) y sigo varias guías para reforzar mi smb.confconfiguración. Si ve fallas en esta configuración, las consideraré válidas para atacar el escenario/configuración hipotético con una contraseña en blanco en la cuenta de inicio de sesión fred(recuerde que la contraseña de la cuenta samba esnoaunque en blanco).

Para ssh, quiero confirmar que el valor predeterminado es que las contraseñas en blanco se rechacen entodocuentas (no sólo en root). Si no, consideraré válida la respuesta de FelixJN. De lo contrario, probablemente usaría, similar a samba, la misma configuración que hago normalmente, que es una versión reforzada de la configuración predeterminada. No recuerdo haber cambiado muchas configuraciones para esto, así que intentaré ver si puedo encontrar exactamente qué configuraciones suelo modificar e incluirlas aquí. Fuera de mi cabeza, sé que cambio el número de puerto y no es que esto importe mucho.

Al confirmar el sshrechazo, me sorprendió ver que en LM19 passwdno parece admitir el -findicador (forzar), por lo que, curiosamente, solo pude crear una contraseña en blanco para un usuario no root en fedora. Cuando intenté pasar sshde la caja LM19 a Fedora, fue rechazado:

    $ ssh -p 2468 fred@fedora-testbox
    fred@fedora-testbox's password: 
    Permission denied, please try again.
    fred@fedora-testbox's password: 
    Permission denied, please try again.

Aparte del puerto, parece que también aumenté los cifrados/MAC/Algoritmos Kex mínimos aceptables, reduje LoginGraceTime// MaxAuthTries, MaxSessionsconfiguré PermitRootLogin no// . Para :UsePAM yesChallengeResponseAuthentication noPermitEmptyPasswordsno parecía ser el valor predeterminadopero lo había hecho explícito.

Respuesta1

La razón práctica más importante que se me ocurre es que algún software de red puede permitir que alguien inicie sesión de forma remota en su máquina sin contraseña. El riesgo no es tanto el software que conoces, sino el software en el que no pensaste. Quizás el software que viene incluido con su distribución.

Con los usuarios sin contraseña, su trabajo es verificar todos los servicios conectados a la red en su máquina para ver si permitirán el inicio de sesión remoto sin contraseña.

Un principio de seguridad general es que desea que las cosas "fallen" bloqueando a todos en lugar de dejar entrar a cualquiera. Si tiene usuarios sin contraseña, los errores y los simples descuidos son más propensos a desbloquear alguna puerta trasera en alguna parte.

Un ejemplo de ello podrían ser los servidores de correo electrónico. Si tiene una máquina con una dirección IPv4 pública, entonces, garantizado, habrávoluntadHabrá intentos semanales o incluso diarios para iniciar sesión en SMTP. Los piratas informáticos simplemente recorren cada dirección IPv4 en busca de una máquina vulnerable (solo hay 4 mil millones de direcciones).

Asimismo SSH. OpenSSH está configurado para rechazar intentos de inicio de sesión sin contraseña (sin autenticación), por lo que lo más probable es que sea seguro. Pero todos los días veo algunos intentos de piratas informáticos que intentan encontrar un nombre de usuario con una contraseña en blanco. Simplemente revisan miles de nombres de usuario comunes con la esperanza de tener suerte.

Respuesta2

Generalmente consideraría estos aspectos:

  1. Acceso remoto:

Si tiene alguna opción de acceso remoto, como sshactiva, esta es una puerta abierta por razones obvias. En ese caso se aplican especialmente los puntos 2 y 3.

  1. Privacidad y seguridad de datos:

Su usuario expone información que tal vez no debería estar disponible para usuarios sin privilegios y, por supuesto, cualquiera podría eliminar su fecha. Algunas personas son simplemente destructivas.

  1. Sistema de seguridad:

Por supuesto, oficialmente el usuario no tiene derechos de administrador, pero ningún sistema es imposible de piratear. Una vez que alguien tiene acceso como usuario, nadie le impedirá cargar malware, explotar agujeros de seguridad, compilar programas localmente y luego violar el sistema...

Es una cuestión de cuántas piedras te gusta poner en el camino de alguien.

Entonces, la pregunta es ¿por qué tener un usuario sin contraseña, cuando también podría tener un inicio de sesión automático y evitar al menos algunos de estos riesgos, haciendo que la necesidad de acceso físico sea lo más alta posible?

información relacionada