¿Qué tan seguro está NOPASSWD en el modo de sudo sin contraseña?

NOPASSWD no tiene un impacto importante en la seguridad. Su efecto más obvio es proporcionar protección cuando el usuario deja desatendida su estación de trabajo: un atacante con acceso físico a su estación de trabajo puede extraer datos, realizar acciones y plantar malware con los permisos del usuario, pero no elevar su acceso a la raíz. Esta protección tiene un uso limitado porque el atacante puede plantar un programa de tipo keylogger que registra la contraseña del usuario la próxima vez que la ingrese en un aviso de sudo o en un protector de pantalla.

No obstante, requerir la contraseña eleva la barra del atacante. En muchos casos, la protección contra atacantes no sofisticados es útil, especialmente en escenarios de estaciones de trabajo desatendidas donde el ataque es a menudo una oportunidad y el atacante puede no saber cómo encontrar y configurar malware discreto a corto plazo. Además, es más difícil ocultar malware cuando no tiene permisos de root, no puede ocultarse de root si no tiene root.

Hay algunos escenarios realistas donde la falta de una contraseña protege incluso contra atacantes sofisticados. Por ejemplo, una computadora portátil robada: la computadora portátil del usuario es robada, completa con claves SSH privadas; o bien el ladrón logra adivinar la contraseña para el archivo de clave (tal vez por fuerza bruta), o obtiene acceso a ellos desde un volcado de memoria de un agente clave. Si se detecta el robo, esta es una señal para investigar la actividad reciente en la cuenta de ese usuario, y esto significa que se debe detectar un malware plantado. Si el atacante solo tenía acceso de nivel de usuario, cualquier cosa que hiciera dejaría rastros en los registros; si el atacante obtuvo la contraseña del usuario y ejecutó sudo, todos los registros están ahora comprometidos.

No sé si las desventajas de NOPASSWD equilibran las ventajas para su caso de uso. Necesita equilibrar eso con todos los otros factores de su situación. Por ejemplo, parece que usted permite pero no obliga a tener contraseñas diferentes. ¿Puede utilizar una base de datos de cuenta centralizada? ¿Cuánta contención necesitas entre tus sistemas? ¿Está considerando alternativas a Ansible que admitirían contraseñas de sudo diferentes? ¿Has considerado otros mecanismos de autenticación?

Hay dos casos específicos por los que no quieres un sudo sin contraseña:

1. Este es un mecanismo de defensa contra usuarios malintencionados que obtienen acceso a una cuenta administrativa. Esto puede ser a través de la explotación o debido a que un administrador deje su estación de trabajo sin supervisión sin bloquear su sesión.
2. Tener que volver a emitir la contraseña al usar sudo les da a los usuarios impulsivos el tiempo para pensar dos veces antes de realizar la acción.

Sobre la automatización:

Estoy de acuerdo en que puede hacer esto sin contraseña, pero al no requerir la contraseña sudo, en realidad le está dando TODO acceso a su herramienta de automatización. ¿Ahora piensa en lo que realmente se requiere que haga la herramienta? ¿Realmente necesita todos estos accesos? Probablemente no.

Sudo viene con una buena característica que te permite configurar comandos específicos con el indicador NOPASSWD dentro del archivo sudoers:

username myhost = (root) NOPASSWD: /sbin/shutdown
username myhost = (root) NOPASSWD: /sbin/reboot

  

Teniendo en cuenta los hechos, ssh se realiza mediante claves, las claves están protegidas con contraseña y todas las cuentas de usuario tienen contraseñas (por lo que su bob es imposible sin una contraseña)

Seamos claros aquí. Las contraseñas utilizadas para proteger las claves SSH y las contraseñas de las cuentas de usuario NO SON LAS MISMAS

NOPASSWD simplemente permite al usuario ejecutar comandos como otro usuario sin ingresar su contraseña. No afecta el hecho de que el usuario tiene que ingresar su contraseña cuando SSH ingresa al sistema.

Ansible puede usar varias cosas para la automatización: como sudo con una contraseña de sudo, o NOPASSWD. O use su, suexec, doas, o lo que sea.

Ahora bien, hablamos de:

become: yes
become_user:root
become_method: sudo

Solo tenga en cuenta que idealmente se debe utilizar ansible para la automatización (infra como código), no para uso interactivo. Los usuarios humanos todavía podrían usar contraseñas, por cierto podrían tropezar con las políticas de vencimiento.

Ansible Tower y AWX pueden almacenar todo tipo de credenciales cifradas y delegar su uso para trabajos específicos, sin perder las claves o contraseñas.

Una alternativa es usar claves ssh temporales (firmadas). Hashicorp Vault puede gestionarlos

Hay ventajas y desventajas para que el usuario ingrese una contraseña para acceder a sudo.

Pro: mejor protección si alguien obtiene acceso a una cuenta de administrador. por ejemplo, a través de un terminal desbloqueado, o algún tipo de explotación.

Con: el usuario ingresa una contraseña de texto sin formato que se cifra en tránsito, pero luego se descifra antes de que llegue al shell del usuario. Alguien podría, por ejemplo, manipular el script bashrc para ejecutar un registrador de claves. Dependiendo de su configuración y de los hábitos de los usuarios que puedan permitir el uso de la contraseña para iniciar sesión directamente en la cuenta de los usuarios en esta máquina, y quizás también en otras máquinas. La gente reutiliza las contraseñas con demasiada frecuencia.