Cómo evitar que los usuarios extiendan su ventana de inicio de sesión válido


14

He estado trabajando en algunos procedimientos de refuerzo de seguridad para un cuadro de RedHat, y quería saber si sería posible evitar que un usuario cambie su contraseña, una vez que haya caducado.

Para uno de nuestros clientes, el requisito es que solo deben tener acceso al servidor a través de cuentas temporales, lo que significa que una vez que se crean las credenciales de usuario, la contraseña debe caducar en 4 horas, y una vez que la contraseña caduca, solo la raíz debe poder cambiarla. .

Para el primer requisito (las contraseñas expiran después de 4 horas), supongo que podría lograrse configurando passwordMaxAge = 144000 . Pero todavía no pude encontrar una manera de evitar que los usuarios cambien las contraseñas caducadas, sin desactivar la caducidad de la contraseña.

¿Alguien puede ayudar?


44
¿Está bien si el usuario mantiene abiertas las sesiones de inicio de sesión más allá de la ventana de 4 horas? Vencer la contraseña del usuario no los eliminará si ya están conectados. Podría mantener abierta una sesión SSH durante semanas.
Wyzard

En lugar de confiar en at / cronjobs y modificar los binarios del sistema, es posible que pueda escribir un módulo de pam simple, o tal vez haya uno (o puede bifurcar pam_time para incluir más opciones)
PlasmaHH

Respuestas:


21

En general, la caducidad de la contraseña se utiliza para obligar a los usuarios a cambiar sus contraseñas. Lo que parece que quieres hacer es bloquear la cuenta, lo que impide todo el inicio de sesión.

Lo que sugeriría que haga en su lugar es que, cuando cree la cuenta, también configure un trabajo que bloqueará la cuenta después de cuatro horas.

Por ejemplo:

useradd temp8143
echo chage -E 0 temp8143 | at now + 4 hours

( chage -Eespera que las fechas de vencimiento se den en días, por lo que trabajamos alrededor de esto con un trabajo).


3
Esa es una buena solución. +1 de mi parte
Jenny D

2
Ah, explosión - me gusta esta idea , así ; también +1. Incluso podría hacer un atted userdel, que tendría la ventaja de ordenar todas estas cuentas temporales para que no se queden para siempre.
MadHatter

2
Creo que esto es mejor que mi sugerencia, en realidad.
Jenny D

Creo passwd -l temp813que logrará lo mismo que chage -E 0 temp8143.
Nate Eldredge

55
@NateEldredge No exactamente. passwd -lno evitará los inicios de sesión de clave ssh o los inicios de sesión de huellas digitales, por ejemplo, mientras que lo chage -E 0hará.
Michael Hampton

24

Si elimina el bit setuid del comando passwd, solo root podrá usarlo. Esto también impedirá que los usuarios cambien la contraseña antes de que caduque, lo que de otro modo podría ser una forma de que los usuarios extiendan la cuenta por otras cuatro horas.

[jenny@finch ~] sudo chmod -s /usr/bin/passwd
[jenny@finch ~]$ passwd
Changing password for user jenny.
Changing password for jenny.
(current) UNIX password: 
New password: 
Retype new password: 
passwd: Authentication token manipulation error

Root todavía puede cambiar cualquier contraseña:

[jenny@finch ~]$ sudo passwd jenny
Changing password for user jenny.
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.

55
Elegante y muy UNIX. +1 de mi parte @borntohula, no olvides aceptar esta respuesta haciendo clic en el esquema "marca" si estás contento con ella.
MadHatter

66
Esto casi funciona. El problema con esto es que su eliminación del bit setuid se deshará si passwdalguna vez el sistema lo actualiza.
Michael Hampton

3
@MichaelHampton Verdadero. Arreglando eso es para lo que es, por ejemplo, una marioneta Además, ¿no todos revisan sus sistemas en busca de nuevos bits setuid / setgid después de cada actualización?
Jenny D

1
@JennyD: probablemente deberían verificar el cambio de bits setuid / setgid, pero muy pocos lo hacen alguna vez
warren

2
@warren: puede haber un leve rastro de sarcasmo en esa oración. Un rastro muy pequeño. Minúscula.
Jenny D
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.