Quando você cria uma API no API Gateway, ‌throttling é ativada por padrão nas configurações do stage:

Por padrão, todo método herda suas configurações de throttling do stage:

Ter o throttling integrado e ativado por padrão é ótimo. No entanto, os limites do método padrão - 10k req/s com uma explosão de 5000 solicitações simultâneas - correspondem aos limites da sua conta da AWS. Como resultado, TODAS as suas APIs em todas as regiões compartilham um limite de taxa que pode ser esgotado por um único método.

Isso também significa que, como um invasor, eu só preciso fazer um ataque DOS em um único endpoint público. Posso derrubar não apenas a API em questão, mas todas as suas APIs em toda sua região. Efetivamente tornando todo o seu sistema indisponível.

Dado que muitas organizações executam todo o ambiente de produção em uma única região e conta da AWS, esse é um risco que você não pode ignorar.

AWS WAF não é a resposta para o DOS?

Você pode configurar as regras WAF para o API Gateway e o CloudFront. Você pode fazer isso nas configurações de stage no API Gateway:

Com o AWS WAF, você pode criar regras baseadas em taxas que limitam os limites ao nível do IP:

Isso é suficiente para repelir ataques básicos de DOS, onde todas as solicitações se originam de um punhado de endereços IP. Mas está longe de ser um sistema infalível.

Para iniciantes, ele não o protegerá de ataques DDOS de até uma pequena rede de bots com milhares de hosts. A ascensão dos dispositivos IoT (e sua pouca segurança) também deu origem às botnets de IoT. Essas redes de bots podem incluir milhões de dispositivos comprometidos.

Essas regras WAF baseadas em taxas também não resolvem os ataques DOS baixos e lentos. Esses ataques geram um fluxo lento e constante de solicitações difíceis de diferenciar do tráfego normal.

Esse ingênuo limite de taxa ao nível do IP também pode bloquear o tráfego de instituições que compartilham o mesmo endereço IP para seus usuários. Isso pode incluir universidades e, em alguns casos, até cidades pequenas. No passado, também observei que muitos usuários da AOL compartilhariam o mesmo endereço IP.

Em suma, o WAF pode manter script kiddies fora, mas não é uma resposta suficiente para a ameaça de ataques DOS. O núcleo do problema aqui é que um método pode infligir danos máximos a toda a região. E é um problema que realmente precisa ser resolvido no nível da plataforma.

Então o que nós podemos fazer?

A solução é simples, mas o desafio está na governança.

"Tudo o que você precisa fazer" é aplicar um limite de taxa sensível para cada método individualmente. No entanto, isso exige disciplina do desenvolvedor, constantemente. E sabemos pela história que isso leva ao fracasso, já que os humanos são terríveis com coisas repetitivas.

No momento de escrita desse artigo, não há suporte interno pelo Serverless Framework para definir essas configurações de métodos. A melhor solução parece ser o plugin serverless-api-stage. Funciona, mas está inativo há mais de um ano. E o autor não respondeu a nenhuma das issues recentes ou *PR*s.

Você pode criar uma regra personalizada no AWS Config para verificar se todos os métodos do API Gateway são criados com uma taxa de limite diferente. Essa é uma boa maneira de capturar a não conformidade e aplicar melhores práticas na organização.

Você também pode implementar alguma correção automatizada. Por exemplo, você pode acionar uma função Lambda após cada criação do API Gateway com o CloudTrail e o CloudWatch Events / EventBridge. Se o autor da API deixou os limites de taxa padrão ativados, podemos substituí-lo por uma configuração de limite de taxa mais sensata. No entanto, este não seria minha primeira abordagem. Isso pode ser confuso para o autor da API, não entendendo por que a configuração da sua API foi alterada sem nenhuma ação da parte dele.

Outra estratégia seria reduzir a quantidade de tráfego que chega ao API Gateway, aproveitando o CloudFront como CDN. As regras WAF baseadas em taxa também podem ser aplicadas ao CloudFront, embora as mesmas limitações que discutimos anteriormente ainda se apliquem. O que significa que você pode encontrar custos adicionais do CloudFront durante um ataque DDOS.

Com o AWS Shield Advanced (USD $ 3000/mês mais várias outras taxas), você pode obter proteção de cobrança contra esse custo extra ocorrido durante um ataque. Talvez o mais importante seja que você também tenha acesso à equipe de resposta ao DDoS se já tiver um suporte comercial ou corporativo. Dado o custo envolvido, é provável que isso esteja fora do alcance de muitas startups.

Em suma, as ferramentas precisam melhorar para ajudar as pessoas a fazerem a coisa certa por padrão. Precisamos de um suporte melhor de ferramentas como Serverless Framework, para que possamos configurar esses limites de taxa facilmente. E espero que a AWS altere o comportamento padrão de limites de aplicações em toda a região e em todos os métodos. Ou, no mínimo, mostre mensagens de aviso no console de que suas configurações de limite de taxa estão expondo você a riscos sérios.

Créditos

• The API Gateway security flaw you need to pay attention to, escrito originalmente por Yan Cui