pam_tally2 incrememts antes da senha para tentativas de su

Question

Há um comportamento semelhante aqui , mas acredito que isso seja uma causa subjacente diferente, ou pelo menos requer uma solução diferente, já que essa falha não é causada por chaves SSH.

Nossa empresa está passando por uma auditoria do Linux e eu preciso ativar o bloqueio de conta do PAM para três tentativas incorretas de senha. Não tenho experiência anterior em PAM.

Se eu executar pam_tally2 -u testuser imediatamente depois de executar su testuser , mas antes de inserir a senha, o pam_tally para falhas já é 1, mesmo que eu ainda não tenha digitado uma senha.

Eu entendo que no caso que eu me vinculei acima, o incremento pré-senha é causado por uma troca de chave SSH com falha, mas depois de ler man su , não parece que uma troca de chave está envolvida. Então, minha pergunta é: "Por que é que pam_tally incrementa antes de digitar uma senha?"

Estou fazendo o meu melhor para garantir que o login tente / bloqueie toda a correspondência entre sshd_config, PAM, fail2ban e /etc/login.def, mas é complicado quando pam_tally conta eventos que não estou esperando!

OS é o servidor Ubuntu 14.04

Apenas as alterações de configuração do PAM feitas no servidor estão em /etc/pam.d/common-auth adicionando esta linha na parte superior:

auth    required pam_tally2.so deny=3 unlock_time=900

Obrigado!

    

Answer 1

Uma leitura cuidadosa do que pam_tally2 explicará completamente o comportamento que você está vendo. Você espera ver quantas tentativas com falha ocorreram no login; no entanto, a página man explica (ênfase minha):

This module maintains a count of attempted accesses

Então, está se comportando exatamente como pretendido. Quando você su user , independentemente de ter digitado ou não uma senha (correta ou incorreta), você terá imediatamente acesso . Quando você insere subsequentemente uma senha correta, a conta é redefinida para 0 . Você definiu o máximo de tentativas para 3 , então você recebe um erro assim que excede essa - é a quarta tentativa que gera o erro.

O comportamento está correto, e agora que entendemos o que o pam_tally2 realmente faz, é razoável.