proteção DDoS para um VPS: capacidade, regras de aplicação e recuperação

Um caminho de rede inundado, tabela de conexões esgotada e consulta de aplicação cara exigem controles diferentes. Colete contadores de rede, taxas de requisição e tempo de resposta. O primeiro sintoma é evidência a investigar, não prova de um único tipo de ataque.

Velocidade de porta do servidor, franquia de transferência por período e capacidade de mitigação são especificações diferentes. Os valores de mitigação do catálogo preparado variam de 10 a 400 Gbps por plano. Nenhum altera o tempo de CPU necessário para responder a uma solicitação custosa.

Umbra 1 lista uma porta de servidor de 1 Gbps, 1 TB de transferência mensal e uma especificação de mitigação de 10 Gbps. A primeira descreve a conexão, a segunda uma franquia por período e a terceira um envelope de filtragem proposto. Nenhuma significa que a aplicação consegue responder 10 Gbps de requisições úteis. O comportamento de filtragem e o tráfego permitido precisam de validação na rede de lançamento.

O design preparado detecta anomalias de tráfego, desvia ataques para filtragem e devolve o tráfego permitido. Sua meta de ativação pretendida é abaixo de 60 segundos, mas o roteamento ao vivo e os controles upstream precisam ser testados antes que isso se torne uma promessa. Pergunte o que acontece além do envelope incluído e como o tráfego legítimo é restaurado.

Faça cache de respostas adequadas, limite a taxa de caminhos caros e proteja o acesso administrativo. Um WAF ou proxy reverso deve ser configurado e mantido como uma camada separada. Restrinja o acesso web de origem a fontes de proxy confiáveis se isso fizer parte do design, sem fechar a rota de recuperação.

Defina quem pode alterar regras, quais evidências pertencem a um ticket e como os usuários aprendem o status. Teste a entrega de alertas e a rota de substituição. Um backup funcional e um registro de incidente sóbrio são úteis mesmo quando o evento acaba sendo uma falha de aplicação.

Incidentes L3/L4 podem envolver amplificação UDP por meio de DNS, NTP ou memcached, ou floods TCP SYN que pressionam o estado de conexão. Incidentes L7 visam o trabalho da aplicação, como buscas repetidas ou tentativas de login. Compare bits por segundo, pacotes por segundo e requisições por segundo separadamente. Um filtro de borda, um controle de conexão e uma regra de aplicação resolvem partes diferentes do problema.

• Feche ou restrinja serviços UDP públicos desnecessários e mantenha o acesso à origem deliberado.
• Um projeto anycast geograficamente distribuído precisa de retirada de rotas, tratamento de estado e testes de failover; ele não é estabelecido por um número de capacidade de mitigação.

Um desafio, CAPTCHA ou barreira de prova de trabalho pode adicionar atrito a solicitações suspeitas. Também pode afetar visitantes legítimos, clientes automatizados e acessibilidade, então aplique-o a endpoints adequados e meça o resultado. Uma resposta lenta ou tarpit também ocupa recursos; teste o custo antes de presumir que é mais barato do que rejeitar a solicitação.

• Mantenha uma rota acessível de recuperação ou suporte quando um desafio impedir a entrada.
• Limites de solicitação, cache e correções de aplicação continuam úteis mesmo quando um desafio está habilitado.