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.
(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.