As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Ataques na camada de aplicação
Um invasor pode atacar o próprio aplicativo usando um ataque de camada 7 ou camada de aplicativo. Nesses ataques, semelhantes aos ataques à infraestrutura de SYN inundação, o atacante tenta sobrecarregar funções específicas de um aplicativo para tornar o aplicativo indisponível ou não responder aos usuários legítimos. Às vezes, isso pode ser obtido com volumes de solicitações muito baixos que geram apenas um pequeno volume de tráfego de rede. Isso pode dificultar a detecção e mitigação do ataque. Exemplos de ataques à camada de aplicação incluem HTTP inundações, ataques de destruição de cache e - inundações. WordPress XML RPC
-
Em um ataque de HTTP inundação, um invasor envia HTTP solicitações que parecem ser de um usuário válido do aplicativo web. Algumas HTTP inundações têm como alvo um recurso específico, enquanto HTTP inundações mais complexas tentam emular a interação humana com o aplicativo. Isso pode aumentar a dificuldade de usar técnicas comuns de mitigação, como a limitação da taxa de solicitações.
-
Os ataques de bloqueio de cache são um tipo de HTTP inundação que usa variações na sequência de caracteres de consulta para contornar o cache da rede de entrega de conteúdo (). CDN Em vez de serem capazes de retornar resultados em cache, eles CDN devem entrar em contato com o servidor de origem para cada solicitação de página, e essas buscas de origem causam pressão adicional no servidor web do aplicativo.
-
Com um WordPress XMLataque de RPC inundação, também conhecido como inundação de WordPress pingback, um atacante tem como alvo um site hospedado no software de gerenciamento de conteúdo. WordPress O atacante usa indevidamente a RPC API função XML-
para gerar uma enxurrada de solicitações. HTTP O recurso de pingback permite que um site hospedado no WordPress (Site A) notifique um WordPress site diferente (Site B) por meio de um link que o Site A criou para o Site B. O Site B então tenta acessar o Site A para verificar a existência do link. Em uma inundação de pingback, o atacante usa indevidamente esse recurso para fazer com que o Site B ataque o Site A. Esse tipo de ataque tem uma assinatura clara: " WordPress:
" normalmente está presente no User-Agent do cabeçalho da solicitação. HTTP
Há outras formas de tráfego malicioso que podem afetar a disponibilidade de um aplicativo. Os bots Scraper automatizam as tentativas de acessar um aplicativo da web para roubar conteúdo ou registrar informações da concorrência, como preços. Ataques de força bruta e preenchimento de credenciais são esforços programados para obter acesso não autorizado a áreas seguras de um aplicativo. Esses não são estritamente DDoS ataques, mas sua natureza automatizada pode ser semelhante a um DDoS ataque e pode ser mitigada com a implementação de algumas das mesmas melhores práticas abordadas neste paper.
Os ataques na camada de aplicativos também podem ter como alvo os serviços do Sistema de Nomes de Domínio (DNS). O mais comum desses ataques é uma inundação de DNS consultas, na qual um invasor usa muitas DNS consultas bem formadas para esgotar os recursos de um servidor. DNS Esses ataques também podem incluir um componente de bloqueio de cache em que o atacante randomiza a string do subdomínio para ignorar o cache local de qualquer resolvedor. DNS Como resultado, o resolvedor não pode tirar proveito das consultas de domínio em cache e, em vez disso, deve entrar em contato repetidamente com o DNS servidor autorizado, o que amplifica o ataque.
Se um aplicativo da web for entregue pelo Transport Layer Security (TLS), um invasor também poderá optar por atacar o TLS processo de negociação. TLSé computacionalmente caro, então um invasor, ao gerar carga de trabalho extra no servidor para processar dados ilegíveis (ou ininteligíveis (texto cifrado)) como um aperto de mão legítimo, pode reduzir a disponibilidade do servidor. Em uma variação desse ataque, um atacante conclui o TLS aperto de mão, mas renegocia perpetuamente o método de criptografia. Como alternativa, um invasor pode tentar esgotar os recursos do servidor abrindo e fechando várias TLS sessões.