BT

A sua opinião é importante! Por favor preencha a pesquisa do InfoQ!

Netflix: proteção contra ataques DDoS em arquiteturas orientadas a microservices

| por Andrew Morgan Seguir 0 Seguidores , traduzido por Delfino Filho Seguir 0 Seguidores em 09 ago 2017. Tempo estimado de leitura: 3 minutos |

Para melhorar a experiência das pessoas que acessam o InfoQ Brasil, nós criamos uma série de funcionalidades que te permitem ficar pode dentro das últimas tendências e das novidades de seu interesse, sem que você seja incomodado por coisas irrelevantes. Receba e-mails periódicos e notificações sobre seus tópicos favoritos!

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.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT