O login em uma distribuição GNU / Linux está demorando muito

4

Então,

Quando eu tento fazer o login com meu nome de usuário e senha (em tty), e insiro uma senha errada, eu preciso esperar 5 segundos para o sistema dizer que a senha está errada.

Por que o processo de validação está demorando tanto?

Dito GNU / Linux: Archlinux.

    
por Marius Marusanici 07.04.2014 / 22:59

4 respostas

5

Adicionando um pouco de perspectiva histórica, a idéia de dormir após uma senha incorreta não é encontrada apenas em sistemas baseados em PAM. É muito antigo. Por exemplo, no 4.4BSD login fonte você encontrará este fragmento saboroso:

/* we allow 10 tries, but after 3 we start backing off */
if (++cnt > 3) {
        if (cnt >= 10) {
                badlogin(username);
                sleepexit(1);
        }
        sleep((u_int)((cnt - 3) * 5));
}

para que as 3 primeiras falhas sejam gratuitas, as 7 seguintes tenham atrasos crescentes (5 segundos, 10 segundos, 15 segundos ...) e depois de 10 ele faz um sleepexit(1) , que é um atraso de 5 segundos seguido por exit(1) .

Os sleeps são apenas um aborrecimento quando você está digitando uma senha no console, mas eles são importantes quando a entrada é proveniente de um usuário remoto que pode estar automatizando o processo.

O sleepexit após 10 falhas merece uma explicação especial. Depois que login sair, getty apenas imprime outro prompt de login e inicia o ciclo novamente. Então, por que dormir e sair em vez de apenas dormir? Porque quando esse recurso foi introduzido, o login por discagem era comum. (Nota para pessoas que nunca usaram um modem antes de 1995: eu disse login por discagem, não PPP ou outro protocolo baseado em pacotes por discagem. Você poderia discar um número em um emulador de terminal e obter um login prompt.)

No mundo da conexão discada, qualquer um poderia discar seu número e começar a emitir senhas nele, então o processo login foi encerrado após algumas senhas ruins, fazendo com que a conexão do modem fosse encerrada, forçando-as a rediscar antes de tentar mais senhas. O mesmo princípio se aplica a ssh today (opção de configuração MaxAuthTries ), mas foi mais eficaz nos velhos tempos, porque a discagem de um modem foi um pouco mais lenta do que um handshake TCP.

    
por 08.04.2014 / 01:39
2

Veja esta resposta no StackOverflow que cita o O Guia dos Escritores dos Módulos Linux-PAM :

As directed by this file, one of more of the modules may fail causing the pam_...() call to return an error. It is desirable for there to also be a pause before the application continues. The principal reason for such a delay is security: a delay acts to discourage brute force dictionary attacks primarily, but also helps hinder timed (covert channel) attacks.

The pam_fail_delay() function provides the mechanism by which an application or module can suggest a minimum delay (of micro_sec micro-seconds). Linux-PAM keeps a record of the longest time requested with this function. Should pam_authenticate() fail, the failing return to the application is delayed by an amount of time randomly distributed (by up to 25%) about this longest value.

Independent of success, the delay time is reset to its zero default value when Linux-PAM returns control to the application.
    
por 07.04.2014 / 23:30
2

Como outros já responderam, o PAM é provavelmente a causa disso. A verificação real da senha leva apenas um tempo muito curto, o resto é um atraso projetado para impedir ataques de força bruta. No Debian, eu tenho as seguintes linhas em /etc/pam.d/login :

# Enforce a minimal delay in case of failure (in microseconds).
# (Replaces the 'FAIL_DELAY' setting from login.defs)
# Note that other modules may require another minimal delay. (for example,
# to disable any delay, you should add the nodelay option to pam_unix)
auth       optional   pam_faildelay.so  delay=3000000

Se o atraso de 5 segundos for muito longo (certamente ter que esperar por esse tempo se você estiver com pressa pode sentir que é muito longo), você sempre pode encurtar o tempo procurando o arquivo equivalente no seu sistema. Se você não tiver o PAM, como o comentário no snippet acima diz, você pode procurar em /etc/login.defs para o valor FAIL_DELAY .

    
por 08.04.2014 / 00:43
0

Eu não uso o Archlinux por conta própria, então não sei exatamente, mas isso soa como um mecanismo contra a adivinhação de senha de força bruta.

    
por 07.04.2014 / 23:14