O unix_chkpw é executado antes do access.conf via pam - risco de segurança


0

Eu tenho sistemas RHEL 6.3 que têm o access.conf do PAM configurado e funcionando corretamente. No entanto, parece um estado abaixo do ideal, após a análise de uma tentativa de root-hack, e estou me perguntando se há algo que possa ser feito sobre isso.

Eu usei o authconfig para adicionar o access.conf e depois adicionei minhas regras. No entanto, parece que o PAM executa uma verificação de senha ANTES de executar as regras do access.conf. Eu quero reverter isso, e nem mesmo permitir que alguém verifique a senha, a menos que passe nas regras do access.conf PRIMEIRO.

O comportamento atual representa um risco à segurança, porque, embora o access.conf possa posteriormente negar uma suposição de senha bem-sucedida, há características que informarão ao hacker que elas acertaram. Isso é:

Tentativas malsucedidas de senha:

[ivo@pioneer:~]$ ssh root@mysecuresystem
root@mysecuresystem's password:
Permission denied, please try again.
root@mysecuresystem's password:
Permission denied, please try again.
root@mysecuresystem's password:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

Tentativas bem-sucedidas de senha:

[ivo@pioneer:~]$ ssh root@mysecuresystem
root@mysecuresystem's password:
Connection closed by 10.10.10.65

O comportamento não diz conclusivamente que eles receberam a senha, mas é diferente de um palpite com falha e, portanto, é notável. (Além disso, os logs ainda mostram unix_chkpw, o que resulta em um falso positivo no IDS / analisador de log da Security).

Embora a alteração desse comportamento resulte em alterações na origem do PAM e, portanto, seja complicada, pode ser fácil alterar a ordem das verificações no PAM?

Então, como faço para o PAM usar o access.conf ANTES de uma verificação de senha?

(Nota: precisamos usar o access.conf porque precisamos parar apenas o root da maioria das máquinas, mas permitir usuários de qualquer lugar. Portanto, a configuração do sshd não é uma solução, nem são wrappers para o que precisamos realizar)

Obrigado!

Respostas:


1

Esta não é uma solução, mas parece ser uma solução razoável. Modifique /etc/pam.d/sshd movendo a linha "pam_access.so" para que fique na seção "auth", por exemplo:

autenticação necessária pam_access.so

Ao invés de

conta necessária pam_access.so

Isso faz com que o logon tente produzir a mensagem "Acesso negado", mesmo quando uma senha válida for usada, evitando informar o hacker de uma suposição correta.


Obrigado Bill - Eu acho que essa é uma resposta parcial e, se depois de mais alguns dias, ninguém mais a marcar como tal. Isso resolve a parte em que o cracker receberá o mesmo aviso, se eles acertarem ou não. Eu adoraria ver os logs ainda não exibidos unix_chkpw, para que nosso grupo de segurança parasse de descer para "garantir que este seja um falso positivo ..." Mas isso resolve uma grande parte!
Zenfridge 18/03
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.