Os ataques SSH drenam 4 GB em 10 horas. Possível?

Fui avisado de que meu servidor quebrou seu limite de transferência. Como o meu nó Tor se tornou popular, decidi desativá-lo este mês (não é a melhor opção para a comunidade, mas preciso ir para baixo). Então notei que o servidor transferiu cerca de 4 GB nesta noite. Verifiquei os logs do Apache com o Awstats, sem tráfego relevante (e não hospedo sites tão populares lá). Eu verifiquei os logs de correio, ninguém tentou enviar lixo. Eu verifiquei messageslogs e encontrei toneladas desses

Apr 29 10:17:53 marcus sshd[9281]: Did not receive identification string from 85.170.189.156
Apr 29 10:18:07 marcus sshd[9283]: Did not receive identification string from 86.208.123.132
Apr 29 10:18:24 marcus sshd[9298]: Did not receive identification string from 85.170.189.156
Apr 29 10:18:39 marcus sshd[9303]: Did not receive identification string from 86.208.123.132
Apr 29 10:18:56 marcus sshd[9306]: Did not receive identification string from 85.170.189.156
Apr 29 10:19:11 marcus sshd[9309]: Did not receive identification string from 86.208.123.132
Apr 29 10:19:18 marcus sshd[9312]: Did not receive identification string from 101.98.178.92
Apr 29 10:19:27 marcus sshd[9314]: Did not receive identification string from 85.170.189.156
Apr 29 10:19:41 marcus sshd[9317]: Did not receive identification string from 86.208.123.132
Apr 29 10:20:01 marcus sshd[9321]: Did not receive identification string from 85.170.189.156
Apr 29 10:20:13 marcus sshd[9324]: Did not receive identification string from 86.208.123.132
Apr 29 10:20:32 marcus sshd[9327]: Did not receive identification string from 85.170.189.156
Apr 29 10:20:48 marcus sshd[9331]: Did not receive identification string from 86.208.123.132
Apr 29 10:21:07 marcus sshd[9336]: Did not receive identification string from 85.170.189.156
Apr 29 10:21:20 marcus sshd[9338]: Did not receive identification string from 86.208.123.132
Apr 29 10:21:35 marcus sshd[9341]: Did not receive identification string from 85.170.189.156
Apr 29 10:21:51 marcus sshd[9344]: Did not receive identification string from 86.208.123.132
Apr 29 10:22:06 marcus sshd[9349]: Did not receive identification string from 85.170.189.156
Apr 29 10:22:23 marcus sshd[9353]: Did not receive identification string from 86.208.123.132
Apr 29 10:22:39 marcus sshd[9359]: Did not receive identification string from 85.170.189.156
Apr 29 10:22:54 marcus sshd[9361]: Did not receive identification string from 86.208.123.132
Apr 29 10:23:10 marcus sshd[9367]: Did not receive identification string from 85.170.189.156
Apr 29 10:23:29 marcus sshd[9369]: Did not receive identification string from 86.208.123.132
Apr 29 10:23:45 marcus sshd[9375]: Did not receive identification string from 85.170.189.156
Apr 29 10:24:10 marcus sshd[9387]: Did not receive identification string from 86.208.123.132
Apr 29 10:24:16 marcus sshd[9388]: Did not receive identification string from 85.170.189.156

A cada poucos segundos, um bot está tentando invadir meu SSH, o que é impossível porque eu preciso de autenticação pubkey. Minha pergunta é: esse tráfego, nessa frequência, pode consumir 4 GB (digamos 3,5) em 10 horas de ataque contínuo?

Alterei minha porta SSH e parei esses ataques, mas não tenho certeza sobre o consumo de rede. Não tenho serviços descontrolados em execução - meu firewall é meio restritivo - ou compartilho o servidor com alguém que esteja abusando de P2P ou o que for. Minha preocupação é ficar abaixo de 400 GB / mês.

Alguma dica?

linux bandwidth-control

— usr-local-ΕΨΗΕΛΩΝ
fonte

Respostas:

É possível 4 GB, mas muito improvável, considerando a taxa de ataque. Sugiro instalar o OSSEC, ele detecta interrupções nas tentativas e bloqueia o IP automaticamente por um certo tempo.

— Lucas Kauffman
fonte

Eu já tenho o fail2ban, ele bloqueou com êxito os logins incorretos, mas parece ignorar essas mensagens. Talvez eu melhore.

— usar o seguinte comando

Aceitaram. O Fail2ban precisava de algum ajuste para aceitar essas mensagens de log como tentativas de invasão. +1 para @lain também porque não consigo aceitar 2 respostas

— usr-local-ΕΨΗΕΛΩΝ

@ djechelon: Informe-nos se isso resolver o problema. De alguma forma, duvido que seja assim que os pacotes forem descartados após a chegada ao seu sistema.

— usar o seguinte comando

@A maioria dos atacantes desiste quando é derrubada.

— 27612 Lucas Kauffman

@LucasKaufman: 4Gb / 10Hrs é ~ 120Kb / seg. Não vejo muita produtividade de tentativas falhas e o snippet acima mostra uma taxa de ataque muito menor (26 em ~ 7 minutos).

— usar o seguinte comando

Se essa é a causa do uso da largura de banda, a largura de banda já é consumida no momento em que você lida com eles no sistema. Você pode usar uma ferramenta como o iptraf para fornecer uma explicação do que está acontecendo em cada interface / porta e, em seguida, tomar as medidas apropriadas com base em fatos.

— user9517
fonte

Obviamente, posso colocar meus esforços em impedir o consumo futuro de largura de banda, a partir do próximo mês

— usr-local-ΕΨΗΕΛΩΝ

E ... resposta muito útil, mas o iptraf não funciona com o OpenVZ (referência webhostingtalk.com/showthread.php?t=924814 ) e eu não mencionei isso :)

— usr-local-ΕΨΗΕΛΩΝ

A idéia básica permanece a mesma. Encontre algo que lhe diga onde está o uso e depois resolva o problema. Qualquer outra coisa é adivinhação.

— user9517

Não, essas tentativas de conexão uma vez por segundo não somam 4 GB em dez horas. Você acha que pode baixar um arquivo de 4 GB em 10 horas recebendo um pacote minúsculo uma vez por segundo? Há 3600 segundos em uma hora; portanto, se você obtiver um kilobyte por segundo por dez horas, isso será 36000 Kb ou 36 megabytes.

Sua largura de banda é medida de acordo com o que desce do cano do seu provedor para o seu roteador externo, não o que chega ao seu servidor. Você deve observar a porcaria que não está atingindo seu servidor, que a maioria dos equipamentos externos está rejeitando.

Quanto ao que chega ao seu servidor, você não pode confiar nos logs do aplicativo. Até os pacotes que são descartados silenciosamente pelo firewall local são de largura de banda. As estatísticas da interface (mostradas por ifconfig) informam bytes Tx / Rx.

— Kaz
fonte

Não tenho certeza. Do meu ponto de vista, as mensagens de log mostram que os clientes abriram um soquete na porta 22, mas foram rejeitados porque "o que eles transmitiram" não foi reconhecido como um handshake SSH adequado. Eu não queria escutar a porta 22 para ver a carga útil real que os scanners enviaram, mas em teoria eles poderiam enviar toneladas de lixo até o SSH cair. A questão é: quando o openSSH descarta um handshake inválido? Em segundo lugar, eu passei uma noite com Tor deficientes e tráfego ainda aumentou (Apache não mostram o tráfego significativo), quando reconfigurado tráfego fail2ban quase parou

— usr-local-ΕΨΗΕΛΩΝ

Deixe-me reformular um pouco, só por precaução. Se eu quisesse drenar 4 GB de largura de banda de um servidor, poderia criar uma botnet que abra conexões HTTP e envie cargas POST ilimitadas para cada solicitação. Os logs mostrarão que as solicitações com falha ocorrem com taxas baixas, mas cada uma é extremamente pesada. Mas isso começa a perder o sentido. Eu estou familiarizado com as verificações SSH ("falha na autenticação para raiz, administrador ...") porque o objetivo delas é assumir o controle do nó. Por que um invasor se importaria de drenar a largura de banda via SSH? Não faz sentido. A menos que alguém odeia nós Tor ...

— ΕΨΗΕΛΩΝ usr-local-