Módulos de autenticación y su orden

Cada línea de una pila PAM tiene un tipo (auth, account, session…), una bandera de control y un módulo. La bandera decide qué pasa con el resultado del módulo. Con required, un fallo hace fallar toda la pila de ese tipo, pero se siguen evaluando las líneas de abajo. Con sufficient, un éxito (si ningún required anterior falló) da la pila por buena y las líneas siguientes no se leen.

Por eso sufficient es útil para ofrecer varias vías (cuenta local o del directorio), pero también es la bandera que más veces esconde un módulo importante que quedó debajo.

pam_permit es un módulo que siempre concede. Tiene usos legítimos, pero en una fase auth y con bandera sufficient puesto antes de los módulos que verifican la contraseña, convierte el servicio en uno que deja pasar a cualquiera: el primer módulo acierta siempre y el resto nunca se lee.

Abre los cuatro archivos de /pam y mira la primera línea de auth de cada uno; el nombre del servicio es el del archivo, sin la extensión.

La regla interna dice que toda pila de cara a personas lleva pam_access, que restringe quién puede entrar. En login.txt el módulo está, pero la fase account tiene una línea sufficient del directorio antes de él. Para una cuenta del directorio, esa línea acierta y la pila termina sin pasar por la lista de acceso.

Compara la fase account de login.txt con la de sshd.txt, donde el orden es otro.

pam_faillock cuenta los intentos fallidos y bloquea la cuenta temporalmente. En una pila va en tres lugares: con preauth antes de verificar la contraseña, con authfail después, y en la fase account. Sin él, un servicio acepta intentos indefinidos de adivinar una contraseña. Se mide cuántos de los servicios del servidor lo usan, no si lo usan bien: es el primer paso de la revisión.

Cuenta en los cuatro archivos de /pam cuántos contienen pam_faillock.