Si algún usuario no puede acceder a algún comando sudo
3 veces, esto se debe informar al usuario raíz en logs de acceso \ errores.
¿Puede la raíz ver estos intentos (como las contraseñas probadas) en el texto de los registros?
Si algún usuario no puede acceder a algún comando sudo
3 veces, esto se debe informar al usuario raíz en logs de acceso \ errores.
¿Puede la raíz ver estos intentos (como las contraseñas probadas) en el texto de los registros?
Respuestas:
Los intentos de inicio de sesión exitosos y sin éxito se registran
/var/log/auth.log
Ejemplo de un intento exitoso:
Oct 23 21:24:01 schijfwereld sudo: rinzwind : TTY=pts/0 ; PWD=/home/rinzwind ; USER=root ; COMMAND=/bin/bash
Oct 23 21:24:01 schijfwereld sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Y sin éxito:
Oct 23 21:25:33 schijfwereld sudo: pam_unix(sudo:auth): authentication failure; logname= uid=1000 euid=0 tty=/dev/pts/1 ruser=rinzwind rhost= user=rinzwind
Oct 23 21:26:02 schijfwereld sudo: rinzwind : 3 incorrect password attempts ; TTY=pts/1 ; PWD=/home/rinzwind ; USER=root ; COMMAND=/bin/bash
Registra el intento fallido y también registra el total de 3 contraseñas mal escritas.
Las contraseñas para sudo
intentos nunca se muestran o almacenan.
La práctica habitual es no registrar las contraseñas utilizadas en los intentos de inicio de sesión, incluso si la contraseña en cuestión no es válida. Esto se debe simplemente a que la contraseña podría ser válida para otro usuario en el mismo sistema (por ejemplo, el usuario escribió mal su nombre de usuario , no la contraseña), o podría ser una alternancia trivial de la contraseña real (el usuario perdió una letra más o menos).
Cualquiera de esos casos dejaría una contraseña de texto sin formato en el sistema, vulnerable a alguna filtración de información. (La contraseña también podría ser una contraseña válida para otro sistema que no sea el que se ingresó, pero eso es realmente un problema mayor para "ellos", no para "nosotros").
Algo relacionado con esto son los casos en los que un usuario escribe su contraseña en lugar de su nombre de usuario (por ejemplo, generalmente usan un sistema que ingresa el nombre de usuario automáticamente, pero ahora no lo hizo, pero aún así escribió la contraseña como primera cosa). En ese caso, tendría una contraseña de texto sin formato en los registros. Esto no es óptimo, pero es útil ver los nombres de usuario para los intentos de inicio de sesión fallidos habituales, y no existe una solución simple para almacenarlos, pero no las contraseñas ingresadas como nombres de usuario.
Dicho esto, tampoco hay nada que impida que el administrador del sistema haga que el sistema registre las contraseñas. Probablemente se pueda agregar el registro agregando una llamada syslog()
y volviendo a compilar el módulo PAM. (PAM es lo que sudo
usa Ubuntu , pero, por supuesto, lo mismo se aplica para las aplicaciones web y todo lo demás también).
Entonces, no, generalmente un administrador no puede ver las contraseñas ingresadas en el sistema, pero si ingresa su contraseña en un sistema en el que no confía, debería, estrictamente hablando, considerarla perdida y cambiarla.
En términos más generales, muy pocos programas en Unix registran contraseñas reales en syslog o en otro lugar: casi nunca hay una buena razón para hacerlo, y hay buenas razones para no hacerlo.
Debido a la forma en que se codifican las contraseñas, el sistema no puede distinguir entre una contraseña incorrecta y un error tipográfico: si su contraseña era% $ zDF + 02G y escribió% $ ZDF + 02G, le fallará tanto como sea posible. lo haría si escribiera 'rubberbabybuggybumpers', pero el registro de la contraseña fallida le daría información valiosa a un tercero malintencionado que lea el registro.
El caso que he encontrado en un programa hizo tener la capacidad de registrar las contraseñas (y un caso de uso donde eso sería una idea buena) se encuentra en servidores RADIUS, donde se puede en un interruptor de pellizco en más-información-que- probablemente quiso el modo de depuración y luego agregue explícitamente el indicador que significa 'sí, incluidas las contraseñas' porque tiene un cliente que no se conecta y necesita descartar absolutamente todas las causas posibles ...