Low & Slow pode parecer um tópico ultrapassado, mas ainda é muito relevante e oportuno. 65% das organizações sofreram ataques Low & Slow em 2020, 30% deles mensalmente. Então, vamos dedicar a isso os cinco minutos que isso merece!
Quando um hacker quer derrubar uma aplicação, a forma mais fácil é lançar uma grande quantidade de tráfego para a aplicação e derrubar o servidor dela (Negação de serviço distribuído ou DDoS). Entretanto, hoje existem muitas tecnologias capazes de detectar e bloquear essas tentativas, seja por IP ou bloqueio baseado em assinatura, por gerenciamento de cotas ou soluções dedicadas de mitigação de DDoS.
No último mês, além de inundações, vimos o retorno de outro tipo de técnica antiga, mas ainda muito eficaz: o ataque Low & Slow. Até os últimos dias de fevereiro, a Radware já detectou um aumento de 20% em ataques Low & Slow contra nossos clientes em comparação ao quarto trimestre de 2020.
Uma atualização sobre o Low & Slow
Em vez de gerar uma explosão súbita de volume de tráfego, os ataques Low & Slow (também conhecidos como low-rate) passam desapercebidos (abaixo do radar). Eles têm o objetivo de abater um alvo silenciosamente deixando conexões abertas nele, criando um número relativamente baixo de conexões por um período de tempo e deixando essas sessões abertas pelo máximo de tempo possível.
Métodos comuns incluem enviar solicitações HTTP e pequenos pacotes de informação ou mensagens “keep alive” para impedir que a sessão fique inativa ou fora do ar. Esses vetores de ataque não só são difíceis de bloquear, mas também de detectar.
[Você também pode se interessar por: How to Keep APIs Secure in an Interconnected World] (Como proteger as APIs em um mundo interconectado)
Existem várias ferramentas conhecidas disponíveis para infratores lançarem esses ataques, incluindo o SlowLoris, SlowPost, SlowHTTPTest, Tor’sHammer, R.U.Dead.Yet e o LOIC.
Os ataques Low & Slow, que eram muito eficientes contra aplicações, estão tirando vantagem de APIs negligenciadas que não são tão vigiadas quanto as aplicações, abrindo assim caminho até o alvo. Devido ao baixo volume, e o que pode parecer uma tentativa legítima de se conectar ao aplicativo ou aos recursos do servidor, uma tecnologia de mitigação diferente é necessária. A fonte deve ser bloqueada em uma base comportamental e não de reputação.
Bloqueio por comportamento
A sincronização entre os componentes de detecção e mitigação é uma das razões pelas quais a Radware é reconhecida como líder do setor de proteção contra DDoS: Algoritmos de aprendizagem de comportamento monitoram e medem os tempos de resposta das conexões TCP, tanto do cliente quanto do servidor, assegurando que a fonte de fato está interagindo com o aplicativo, como esperado.
Esse método não envolve interação com a aplicação e não traz nenhum risco a ela, pois a mitigação é feita no nível da sessão. Posteriormente, usando um mecanismo único de sinalização e fluxos de trabalho automatizados, as próximas tentativas serão bloqueadas no perímetro da rede, impedindo qualquer impacto na aplicação.