☰

Dicas para lidar com uma taxa surpreendentemente alta de falhas de login sshd de "botnet"?

tag-icon • tag-icon linux ssh ddos
Dicas para lidar com uma taxa surpreendentemente alta de falhas de login sshd de "botnet"?

Acabei de configurar 2 novos Debian 12 VPS de uma só vez.

Um deles funcionou bem; o outro, parecia ter conectividade intermitente. Cheguei até a escrever metade de um tíquete de suporte, pensando que deveria ser um problema de conectividade em seu datacenter, mas depois fui mais fundo e descobri sobre o recurso "MaxStartups" do sshd: uma vez que há mais de um certo número de conexões que foram aberto, mas ainda não autenticado, o sshd começará a descartar intencionalmente outras conexões, o que é consistente com o que eu estava vendo.

No VPS que funciona bem, os logs mostram uma tentativa maliciosa aproximadamente uma vez a cada dois minutos, que é o que eu esperava. No problemático, parece estar em torno de umtodo segundoem média, com um LoginGraceTime padrão de 2 minutos, faz todo o sentido por que eu estava lutando para entrar. Já reduzi isso para 5 segundos, o que praticamente consegue manter o número de conexões abertas sob controle. (Ambos os VPS já estão configurados para aceitar apenas autenticação de chave pública, portanto, não há como uma tentativa maliciosa ter sucesso.)

Estou surpreso com a rapidez com que as tentativas estão chegando ao problemático. Eles parecem vir de todos os IPs de origem diferentes, então claramente uma botnet, e não algo que eu possa bloquear facilmente. fail2ban, por exemplo, não faria nada aqui, pois funciona totalmente no IP de origem.

Estou planejando colocar um servidor HTTP público neste VPS, então também estou preocupado que, se ele já for alvo de um ataque de botnet por SSH, meu servidor HTTP possa acabar caindo no esquecimento por DDOS antes mesmo de eu começar , e/ou atrair a atenção de alguém ou algo que procura vulnerabilidades para explorar. (O outro VPS, que está vendo apenas uma tentativa a cada dois minutos, estou planejando colocar um servidor de e-mail - não tenho certeza com qual protocolo devo me preocupar mais!)

  • Que taxa de tentativas maliciosas devoesperarser direcionado para um endereço IPv4 escolhido aleatoriamente?
  • Devo tomar alguma atitude em resposta a isso ou apenas aturar isso?
    • Pergunte ao meu provedor VPS se eles podem alterar o IP do servidor, já que talvez eu tenha tido azar e este tenha sido alvo de um DDOS contra alguma outra pessoa aleatória que desde então desalocou seu IP e acabou atribuído a mim?
    • Bloquear o SSH de qualquer lugar, exceto outro VPS meu pelo qual eu possa acessá-lo - apesar de estar executando um servidor HTTP público nele de qualquer maneira? (parece um pouco inútil desativar o SSH quando o HTTP precisa ser aberto - e seria um inconveniente moderado para mim fazer isso)
    • Apenas silenciar mensagens de log para tentativas malsucedidas? (assumindo que existem opções para fazer isso - ainda não verifiquei)
    • Existem pacotes de software de servidor SSH alternativos que posso usar e que são mais otimizados para lidar com uma alta taxa de tentativas maliciosas? Por exemplo, o sshd cria um novo processo para cada nova conexão antes da autenticação, o que parece ser uma sobrecarga desnecessária: idealmente, ele deveria consumir o mínimo de recursos possível até que a autenticação seja bem-sucedida.
    • ... alguma outra sugestão?

Responder1

Que taxa de tentativas maliciosas devo esperar que sejam direcionadas a um endereço IPv4 escolhido aleatoriamente?

O ruído de fundo da Internet: verificações rotineiras e automatizadas de arrasto (em vez de direcionadas especificamente ao seu endereço IPv4) de grandes partes da Internet em busca de hosts e serviços expostos. Um fluxo contínuo de investigações, resultando facilmente em centenas de tentativas de login/abuso por dia apenas em um sshd exposto (embora os números possam variar de dezenas a (muitos) milhares, com determinados intervalos de endereços IP de provedores sendo mais visados ​​do que outros) com fontes variando de:

  • provedores diligentes (que podem estar executando scanners de vulnerabilidade porque desejam avisar/desconectar clientes quando operam sistemas inseguros/vulneráveis/comprometidos)
  • projetos de pesquisa (como por exemploshodan.ioe outros) e outras pessoas curiosas
  • atores maliciosos (que podem estar usando botnets para executar suas investigações)
  • etc etc.

Devo tomar alguma atitude em resposta a isso ou apenas aturar isso?

Em geral: quando você expõe um servidor e serviço à Internet, você deve esperar conexões e, o mais importante, abusos (tentativas) de toda a Internet.

Se um serviço não se destinar a ser um serviço públicoentãonão deve ser exposto a toda a Internet.
Quando você puder: a prática recomendada é aplicar controles de acesso. Isso pode assumir vários formatos, mas o comum é limitar o acesso a endereços IP conhecidos e/ou intervalos de endereços IP conhecidos. Ou, alternativamente, quando você não conhece exatamente bons intervalos de endereços IP, bloqueie intervalos que provavelmente nunca terão um requisito de acesso válido.
Embora a vinculação de endereços IP (intervalos) a localizações geográficas esteja longe de ser 100% confiável nem totalmente completa, as listas de acesso que usam dados Geo-IP podem ser muito úteis nesse sentido.

Os controles de acesso podem ser definidos fora do host, por exemplo, com grupos de segurança ou um dispositivo de firewall. Então o próprio servidor não precisa fornecer recursos para mantê-los.

Muitas vezes mais flexíveis, mas também exigindo recursos do próprio host, são os controles de acesso baseados em host, como um firewall baseado em host (no Linux netfilter/iptables/nftables) ou controles de acesso no próprio aplicativo. Muitas vezes, essa pode ser a única maneira de definir diferentes restrições de endereço IP para diferentes usuários.

Quando um serviço se destinapara um serviço público, como, por exemplo, um servidor web com seu site público,normalmente você não aplica controles de acesso, porque visitantes genuínos do site são bem-vindos de qualquer lugar.
Freqüentemente, esses serviços públicos adotam a abordagem: permitir o acesso de qualquer lugar, masdetectar comportamento malicioso e (temporariamente) bloquear o endereço IP usado pelo(s) malfeitor(es). Uma ferramenta comoFail2bané uma dessas abordagens,Sistemas IDS e IPSoutro.

Exemplo:Uma lista de controle de acesso na página de pedidos de take-away e sistemas de reservas on-line para um restaurante local, digamos, Amsterdã, minha cidade natal. Você não definiria isso para permitir acesso apenas a endereços IP de Amsterdã. Isso provavelmente seria excessivamente restritivo e, por exemplo, afastaria visitantes locais válidos que estivessem usando seus telefones celulares para acessar o site.
Mas, por outro lado, o bloqueio de intervalos de endereços IP conhecidos por estarem atribuídos e em utilização fora da Europa e utilizados, por exemplo, nas regiões de África, Ásia-Pacífico, América do Norte e do Sul, deverá reduzir significativamente o número de tentativas de abuso e é improvável impactar o número de reservas/encomendas de take-away.
Em contraste, a lista de controle de acesso para acesso SSH nesse mesmo servidor web pode ser facilmente limitada aos endereços IP estáticos dos administradores do site, ao gateway de seu escritório e/ou quando eles não possuem um endereço IP estático ou um Servidor VPN, para os intervalos utilizados pelos seus ISPs.

Existem pacotes de software de servidor SSH alternativos que posso usar e que são mais otimizados para lidar com uma alta taxa de tentativas maliciosas? Por exemplo, o sshd cria um novo processo para cada nova conexão antes do auth, o que parece ser uma sobrecarga desnecessária:

Acho e espero que você esteja superestimando os requisitos reais de recursos e o impacto dessas tentativas de login. No esquema geral, a carga que um nível "normal" de tentativas de abuso de ssh gera nos sistemas VPS expostos que vi é insignificante em comparação com cargas reais de aplicativos.

parece um pouco inútil desativar o SSH no firewall quando o HTTP precisa ser aberto

Uma abordagem geral à segurança é aPrincípio do menor privilégio; que nas regras de firewall se traduz em:

  • bloquear tudo por padrão
  • só permitir o acesso ao que é necessário para quem precisa

Portanto, não é inútil permitir o acesso ssh apenas a partir de alguns endereços IP e não do mundo inteiro e permitir o acesso mundial às portas 80 (para redirecionar diretamente para https) e 443, a porta https padrão.

Responder2

Eu nunca vi ataques do tipo slowloris no ssh. Olhando a documentação, MaxStartups não parece se importar se estes são do mesmo cliente (ou seja, você poderia estar facilitando o DOS usando isso). Minha primeira resposta (dependendo do padrão dos ataques) seria usar iptables connlimit (limitar conexões por IP do cliente).

Fail2ban é a solução óbvia para a maioria dos ataques ssh (também o usei para tráfego HTTP[S]), mas certifique-se de que esteja configurado para usar ipset.

É improvável que alterar o endereço IP ajude a longo prazo.

Bloquear SSH de qualquer lugar, exceto outro VPS meu pelo qual eu possa acessá-lo

Sim - usar uma caixa de salto é uma prática bastante comum. Novamente, isso é algo que você pode fazer sozinho. Basta definir uma regra de firewall padrão para a porta 22 e colocar seus jumpboxes na lista de permissões. O Ssh ainda possui funcionalidades integradas que tornam o uso transparente, por exemplo

ssh -J [email protected] [email protected]

ou você pode definir isso em seu ssh_config e apenas ssh targethost.example.com:

Host jumpbox.example.com
   User: jumpuser
   IdentityFile: ~/.ssh/jumpuser.id_rsa

Host targethost.example.com
   User: user
   ProxyCommand: ssh -q -W %h:%p [email protected]:22 
   IdentityFile: ~/.ssh/user.id_rsa

Apenas silenciar mensagens de log para tentativas malsucedidas?

Eu não defenderia isso. Sinta-se à vontade para ignorá-los se tiver tomado medidas razoáveis ​​para impedir o acesso não autorizado.

Como sugere pepoluan, você também pode usar uma porta não padrão e porta-knoocking (aliás, o último pode serimplementado puramente em iptablessem ter que usar knockd)

Responder3

Minhas sugestões:

  1. Mude a porta SSH de 22 para outra.
  2. Se os bots ainda conseguirem encontrar sua porta, instale knockde configure seu servidor para implementar a porta.

Responder4

Se você expor o SSH via IP público, ele será verificado mais cedo ou mais tarde, e os agentes da ameaça tentarão tentativas de autenticação, independentemente do provedor VPS ou da rede.

Eu fortaleceria sua configuração ssh usando um manual ansible como este: https://github.com/dev-sec/ansible-collection-hardening/tree/master/roles/ssh_hardening

Ou este manual, que fortalece todo o servidor: https://github.com/konstruktoid/ansible-role-hardening

E eu também recomendaria o fail2ban. Fail2Ban: bane hosts que causam vários erros de autenticação Fail2Ban verifica arquivos de log como /var/log/auth.log e proíbe endereços IP que conduzam muitas tentativas de login malsucedidas. Isso é feito atualizando as regras de firewall do sistema para rejeitar novas conexões desses endereços IP, por um período de tempo configurável.

Ou talvez você possa criar uma conexão VPN com a rede do seu VPS/criar um servidor VPN no seu VPS usando OpenVPN (por exemplo) e colocar SSH atrás da VPN, e não expô-lo à internet.

informação relacionada