Como posso impedir que os robôs do SSH tentem o SSH como root?

1

Eu tenho a solução atual, fail2ban, e proíbo o SSH como root nas configurações do sshd. Não é tão eficaz quanto eu preciso em certas situações. Mais particularmente em servidores de gateway, que têm memória e espaço em disco limitados (porque supostamente são leves)

Desativar o login como root nas configurações do sshd, ainda permite que os bots se conectem, especifiquem o login como root e tentem 3 ou mais vezes. O Fail2ban bloqueia seus IPs após 5 falhas.

No entanto, o volume incessante de bots deixa 8 threads sshd na memória a qualquer momento, 3GB auth.log de falhas (30% do meu espaço em disco), enormes sobrecargas de memória para o fail2ban filtrar e processar todos eles e diminuir a velocidade resposta quando tentamos fazer o login, porque há 50.000 blocos de ip cada conexão deve ser filtrada primeiro, e 20-48MB de memória usada para loggin e segurança estão em troca por causa das demandas do sistema para lidar com o volume de pedidos.

A solução preferível é: "Quando uma conexão SSH tenta efetuar login e usuário = root", então "sshd disconnect". Qualquer tentativa de especificar a raiz do usuário resulta na eliminação da conexão.

Isso reduziria o processamento desnecessário para filtrar todos os ataques de força bruta. Eu não posso usar o acesso somente de chaves porque faz com que o login ignore a autenticação de fator 2 requerida.

    
por ppostma1 08.05.2017 / 19:23

2 respostas

1

Pessoalmente, eu prefiro mudar a porta de escuta ssh, isso pode evitar esse problema. E é muito fácil de fazer.

    
por iTzWam 10.05.2017 / 18:00
0

Acontece que o fail2ban pode ser modificado para incluir isso como um evento indesejado. Altere / adicione um arquivo de configuração ssh no filter.d para incluir um filtro para acesso como root: link

Em seguida, falhar ao banir responderá mais rapidamente a esses logins, mas não tão rápido quanto soltá-los no local (o que aconteceria exigiria a alteração do código e a recompilação do sshd)

Reduzir o tempo de espera para algumas horas evita uma lista enorme de ips bloqueados que o firewall teria que classificar, reduzindo a sobrecarga e o tempo de conexão. A senha com falha e o tempo de espera de login-como-raiz podem ser configurados separadamente. Dessa forma, se um usuário tiver o CAPS ativado, seu tempo é de apenas alguns minutos, mas os bots de força bruta serão bloqueados por duas horas. (notei que o bantime padrão é de 10 minutos, e a maioria dos bots simplesmente espera 10:01 minutos e retoma suas tentativas)

A redução dos níveis de log reduz todos os arquivos de log e sua sobrecarga de memória. Reduzir o tempo de espera do fail2ban reduz a quantidade de arquivos de log que o fail2ban mantém na memória!

Ter as configurações corretas é importante, porque todos os três desses sistemas criam um triângulo amoroso de uso de memória! Não bloquear os bots em breve, resulta em enormes arquivos de log, o que significa mais uso de memória pelo rsyslog. O Fail2ban mantém esses logs na memória para varrer ( # of attacks/second * by findtime ). E o backup de threads sshd de todas as tentativas simultâneas que os bots podem fazer. Mantenha o bantime muito curto e os bots voltarão criando mais encadeamentos sshd. Tem bantime definido muito longo e o firewall tem que percorrer uma longa lista de permissões armazenadas na memória.

bantime: 5-10 minutes for bad passwords
bantime: 2-6 hours for attempts as root (not days, certainly not 99999999)
log-files: Warn (not info!)
findtime: 5-15 minutes on SSH (log memory usage reduced by quick bans)
maxretry: 2-3
Also config the max attempts permitted in sshd to be 2 because it will dump them to the watched log file much faster

A próxima mudança nos ataques de força bruta (e é por isso que foi mais difícil para nós) é executá-los simultaneamente. Se você for bloqueá-los depois de algumas tentativas, inicie 20x ssh e tente 20 forças brutas de uma só vez! Todas as configurações acima só são efetivas contra um único ataque ip de conexão única. Eles são menos eficazes se várias conexões ssh forem executadas ao mesmo tempo.

Isso pode ser bloqueado no firewall impedindo mais de N conexões de um determinado IP de uma vez:

    
por ppostma1 10.05.2017 / 17:55