A Netflix acaba de publicar em seu blog estratégias para mitigar ataques DDoS em arquiteturas orientadas a microservices. O post inclui uma visão geral de como identificar as requisições que iniciam estes ataques, como testá-las com os frameworks open source Repulsive Grizzly e Cloudy Kraken, bem como as melhores práticas para proteção de um sistema.
O embaixador de segurança de aplicações da Netflix, Scott Behrens e o líder de segurança de produtos e aplicações, Bryan Payne, primeiramente esclarecem que arquiteturas orientadas a microservices estão mais propensas à ataques DDoS. Isto acontece porque chamadas de API que demandam alto uso de recursos computacionais podem produzir múltiplos saltos de rede entre serviços, fazendo com que o sistema cause um ataque a si mesmo e destaca o seguinte observação:
"Uma única requisição em uma arquitetura orientada a microservices pode gerar dezenas de milhares de outras chamadas de serviço complexas na camada intermediária e no backend."
O primeiro desafio ao enfrentar ataques DDoS é a identificação. Como o que parece ser uma chamada de API legítima feita por um usuário, pode ser detectada de início como algo que vai iniciar uma pesada utilização de recursos internamente?
Uma das primeiras estratégias elencadas é identificar quanto tempo uma chamada de API pode durar. Ao invés de olhar para a camada superior, o que pode nos dar falsos positivos, é mais vantajoso monitorar os tempos de requisição dos serviços no backend. Estas requisições podem passar por engenharia reversa para determinar que tipo de chamada de API iniciou-as originalmente.
Quando o desenvolvedor encontra estas chamadas, pode-se analisar a própria requisição e descobrir como ela pode ser alterada para ser mais custosa. O exemplo dado é um parâmetro que determina o limite do tamanho do resultado em uma requisição de consulta, que pode ser incrementado para produzir uma quantidade maior de valores retornados. Uma forma útil para ver se a requisição correta foi identificada é por meio de indicadores de erro, como por exemplo limitação de tamanho e exceções ou por aumento na latência.
Uma vez que estes tipos de requisição são identificados, é sugerido o uso do Repulsive Grizzly, um framework de teste de ataques DDoS para a camada de aplicação como uma forma de executá-las. Esse framework não é uma ferramenta de identificação, mas ele provê meios para organizar o processo de teste por meio da execução de requisições no sistema que está sendo avaliado.
Eles também apresentam o Cloudy Kraken, uma ferramenta de teste open source da AWS, que ajuda a orquestrar a execução de testes em escala global. Isto é feito por meio do gerenciamento de uma frota de instâncias AWS em múltiplas regiões de forma escalável, cada uma executando uma suíte de teste do Repulsive Grizzly. Também é disponibilizada a funcionalidade de sincronização, fazendo com que os testes sejam executados paralelamente.
Uma vez que as requisições sejam identificadas e validadas pelos testes, as seguintes estratégias de mitigação são sugeridas:
- Produzir uma arquitetura que minimize a dependência entre microservices. Se um serviço falha, ele deveria falhar isoladamente, sem quebrar os outros.
- Entender como os serviços utilizam uns aos outros e como os serviços são invocados. Por exemplo, limitar os tamanhos execução em lote ou de requisição de objetos.
- Fornecer um feedback dos serviços de backend para o firewall da aplicação. Isto repassa informações adicionais a respeito do uso de recursos das chamadas à API, o que não seria identificável na ponta.
- Monitorar a falta de objetos em cache ("cache misses"): um volume alto pode significar que o cache não está configurado adequadamente.
- Utilizar diversos padrões de resiliência no cliente, por exemplo, disjuntor (circuit breaker) e timeouts.
O post completo está disponível para leitura online, com um estudo de caso e análise mais aprofundada a respeito deste assunto.