O blog da AWS

As três mais importantes regras baseada em taxa no AWS WAF

Por Artem Lova, Arquiteto de Soluções Sênior na AWS
e Jesse Lepich, Arquiteto Sênior de Soluções de Segurança na AWS 

 

Neste post, explicamos quais são as três mais importantes regras baseada em taxa no AWS WAF para proteger proativamente suas aplicações web contra eventos comuns de flood HTTP e como implementar essas regras. Compartilhamos o que a equipe de resposta do Shield (SRT) aprendeu ao ajudar os clientes a responder a floods HTTP e mostramos como todos os clientes do AWS WAF podem se beneficiar desses aprendizados.

Quando você tem aplicações críticas para os negócios que estão publicadas na internet, você precisa protegê-las contra riscos como ataques distribuídos de negação de serviço (DDoS). O AWS Shield Advanced é um serviço gerenciado de proteção contra DDoS que protege aplicações que estão rodando atrás dos recursos disponíveis na internet da Amazon Web Services (AWS). O backend de sua aplicação pode estar em qualquer lugar, incluindo no on-premises, e o Shield Advanced pode protegê-lo. O Shield Advanced oferece proteção DDoS para as camadas 3-7. Ele também inclui acesso 24 horas por dia, 7 dias por semana à Equipe de resposta do Shield (SRT) para ajudá-lo a responder rapidamente a cenários sofisticados de atividade não autorizada que podem ser exclusivos de sua aplicação. Para saber mais sobre quais tipos de recursos são suportados para associar o AWS WAF, consulte o AWS WAF.

Cada vez mais, a equipe do SRT tem ajudado os clientes a se proteger contra ocorrências de flood HTTP na camada 7 que afetam negativamente a disponibilidade ou o desempenho das aplicações, sobrecarregando estas com um número excepcionalmente alto de requisições HTTP. Em muitos casos, esses eventos maliciosos podem ser mitigados automaticamente usando o AWS WAF. Além disso, o AWS WAF tem uma funcionalidade de regra baseada em taxa nativa e fácil de configurar, que detecta endereços IP de origem que fazem grandes quantidades de requisições HTTP em um intervalo de tempo de 5 minutos e bloqueia automaticamente as requisições do endereço IP ofensor até que a taxa de requisições caia abaixo de um limite definido. Neste post, mostramos como você pode extrair informações dos logs do AWS WAF para determinar qual deve ser o limite da sua regra baseada em taxa.

As três mais importantes regras baseada em taxa no AWS WAF são:

  • Uma regra baseada em taxa geral para proteger sua aplicação de grandes floods HTTP.
  • Uma regra baseada em taxa na URI para proteger URIs específicos em taxas mais restritivas do que a regra de taxa geral.
  • Uma regra baseada em taxa para proteger sua aplicação contra IPs de origem maliciosos conhecidos.

Visão geral da solução

O AWS WAF é um firewall de aplicações web que ajuda a proteger suas aplicações web contra explorações web comuns que podem afetar a disponibilidade, comprometer a segurança ou consumir recursos excessivos. O AWS WAF dá a você controle sobre qual tráfego web chega às suas aplicações. Se você já sabe as taxas de requisições para sua aplicação, tem todas as informações necessárias para começar a criar suas regras baseadas em taxas do AWS WAF. Para saber mais sobre como criar regras, consulte Criar uma regra e adicionar condições. No entanto, se você não tiver esses dados e quiser aprender como começar, esta solução ajuda você a determinar as taxas apropriadas para suas aplicações e como criar regras baseadas em taxas no AWS WAF.

A Figura 1 mostra como as informações de requisições recebidas são capturadas para que a equipe de operações possa usá-las para determinar as regras baseadas em taxas.

Figure 1: The workflow to collect and query logs and apply rate-based rulesFigura 1: Fluxo de trabalho para coletar e consultar logs e aplicar regras baseadas em taxa.

Vamos percorrer o fluxo para entender melhor o que acontece em cada etapa:

  1. Um usuário da aplicação faz requisições aa aplicação.
  2. O AWS WAF captura informações sobre as requisições recebidas e envia para o Amazon Kinesis Data Firehose.
  3. O Kinesis Data Firehose entrega os logs para um bucket do Amazon Simple Storage Service (Amazon S3), onde serão armazenados.
  4. A equipe de operações usa o Amazon Athena para analisar os logs com consultas SQL.
  5. O Athena faz consultas aos logs no bucket do S3 e mostra os resultados da consulta.
  6. A equipe de operações usa os resultados da consulta para determinar a regra baseadas em taxa apropriada no AWS WAF.

As três regras baseadas em taxa em detalhes

Cada uma das regras ajuda a proteger aplicações web contra atividades não autorizadas. Cada uma das regras se concentra em um aspecto específico de proteção. As regras se complementam e, quando combinadas, podem oferecer uma maior ajuda na proteção de sua aplicação web. Vamos analisar cada uma das regras para entender o que elas fazem.

Regra baseada em taxa geral

Uma regra baseada em taxa geral é projetada para evitar que qualquer endereço IP de origem único tenha um impacto negativo na disponibilidade de um site. Por exemplo, se o limite para a regra baseada em taxa for definido como 2.000, a regra bloqueará todos os IPs que estiverem fazendo mais de 2.000 requisições em um período de 5 minutos. Esta é a regra baseada em taxa mais básica e uma das mais valiosas para os clientes do AWS WAF implementarem. O SRT frequentemente ajuda os clientes que estão ativamente sob um ataque DDoS a implementar rapidamente esta regra. Em experiências passadas com casos de floods HTTP, se esta regra estivesse em vigor proativamente, o cliente teria sido protegido e não teria precisado entrar em contato com o SRT para obter ajuda. A regra baseada em taxa geral teria bloqueado automaticamente a tentativa sem intervenção humana.

Regra baseada em taxa específica de URI

Alguns endpoints URI da aplicação normalmente recebem um grande volume de requisições, mas para outros seria incomum e suspeito ver uma quantidade alta de requisições. Por exemplo, várias requisições em um período de 5 minutos para a página de login de um aplicativo são suspeitas e indicam um possível ataque de força bruta ou de preenchimento de credenciais contra a aplicação. Uma regra específica na URI pode impedir que um único endereço IP de origem se conecte à página de login com menos de 100 requisições por um período de 5 minutos, permitindo um volume de requisições muito maior para o restante da aplicação. Algumas aplicações naturalmente têm URIs computacionalmente caras que, quando chamadas, exigem consideravelmente mais recursos para processar a solicitação. Um exemplo disso pode ser uma consulta de banco de dados ou uma função de pesquisa. Se um ator mal-intencionado direcionar requisições para essas URIs computacionalmente caras, isso pode levar rapidamente a problemas de desempenho ou disponibilidade. Se você atribuir uma regra baseada em taxa em URIs específicas para estas partes do seu site, você pode configurar um limite muito menor do que a regra baseada em taxa geral. Isso está além do escopo deste blog post, mas alguns clientes utilizam os logs de acesso do Application Load Balancer e a informação target_processing_time para determinar precisamente quais partes do site estão mais lentas para responder e podem representar uma chamada computacionalmente cara. Estes clientes, então, colocam proteções adicionais de regra baseada em taxa em requisições que são feitas para essas URIs.

Regra baseada em taxa de reputação de IP

Muitos dos eventos DDoS em que o SRT ajuda os clientes incluem floods HTTP que têm origem em IPs maliciosos conhecidos. A solução Security Automations for AWS WAF fornece aos clientes AWS WAF uma assinatura de quatro listas de inteligência de ameaças de código aberto. Regras baseadas em taxa com baixos limites podem ser aplicadas a requisições provenientes dessas fontes suspeitas. Alguns clientes se sentem confortáveis bloqueando completamente requisições web desses IPs, mas, no mínimo, requisições desses IPs devem ser limitadas por taxa para proteger a aplicação dessas fontes maliciosas bem conhecidas.

Também é comum ver floods HTTP originários de endereços IP em certos países. Você pode usar as regras de correspondência geográfica do AWS WAF para atribuir limites de regra baseada em taxa mais baixos a requisições que tenham origem em determinados países ou países que não contenham a base de usuários principal da sua aplicação web. Por exemplo, suponha que sua aplicação atenda principalmente usuários nos Estados Unidos. Nesse caso, pode ser benéfico criar uma regra baseada em taxa com um limite baixo para requisições que venham de qualquer país que não seja os Estados Unidos. Floods HTTP também são comumente vistos originando-se de endereços IP classificados como IPs de provedores de hospedagem em nuvem. Você pode usar a Regra Gerenciada “HostingProviderIPList” do AWS WAF para rotular essas requisições e, em seguida, atribuir um limite de regra baseada em taxa mais baixo a elas também.

Pré-requisitos

Antes de implementar a solução, verifique se:

  • AWS WAF está implantado em sua conta AWS e está associado a uma distribuição do Amazon CloudFront ou a um Application Load Balancer.
  • Sua ação padrão do AWS WAF está definida para Bloquear. Ao criar e configurar uma web ACL, você define a ação padrão do da web ACL, que determina como o AWS WAF lida com requisições web que não correspondem a nenhuma regra na web ACL. Para saber mais sobre a ação padrão para uma web ACL, consulte Decidindo sobre a ação padrão para uma ACL da web.
  • O Log do AWS WAF está configurado e os logs estão sendo armazenados em um bucket do S3.Observação: Você pode seguir estas instruções para configurar a entrega dos logs do AWS WAF para o seu bucket do S3, e também pode usar o AWS Firewall Manager para configurar de forma centralizada o Log do AWS WAF em um ambiente de múltiplas contas.

Configurando Athena para analisar logs do AWSWAF

O Amazon Athena é um serviço de consulta interativa que você pode usar para analisar dados no Amazon S3 usando SQL padrão. Para esta solução, você usará o Athena para se conectar ao bucket S3 onde os logs do AWS WAF são armazenados e consultar os logs do AWS WAF. O primeiro passo é abrir o console do Athena e criar um banco de dados.

Observação: A criação de um banco de dados e tabela do Athena é um processo de configuração único. Você pode voltar posteriormente e executar as consultas e ver os resultados com base nos seus dados de log mais recentes do AWS WAF.

Para criar um banco de dados no Athena, você usará uma declaração de data definition language (DDL). Cole a seguinte consulta no editor de consulta do Athena, substituindo os valores conforme descrito aqui:

  • Substitua <nome-do-seu-bucket> pelo nome do bucket S3 que contém seus logs do AWS WAF.
  • Para <prefixo-do-bucket-se-existir>, se os logs do AWS WAF estiverem armazenados em um prefixo do bucket S3, substitua pelo nome do seu prefixo. Caso contrário, remova esta parte da consulta, incluindo a barra diagonal “/”  no final <bucket-prefix-if-exist>, if AWS WAF logs are stored in an S3 bucket prefix, replace with your prefix name. Otherwise, remove this part from the query, including the slash “/” at the end.
CREATE DATABASE IF NOT EXISTS wafrulesdb
  COMMENT 'AWS WAF logs'
  LOCATION 's3://<your-bucket-name>/<bucket-prefix-if-exist>/';

Escolha Run query para executar a consulta e criar o banco de dados. A conclusão bem-sucedida será indicada pelo resultado da consulta, como mostrado abaixo.

Results
Query successful. 

Em seguida, você criará uma tabela dentro do banco de dados. Cole a seguinte consulta no editor de consultas do Athena, substituindo os valores conforme descrito aqui:

  • Substitua <nome-do-seu-bucket> pelo nome do bucket S3 que contém os logs do AWS WAF.
  • Para <prefixo-do-bucket-se-existir>, se os logs do AWS WAF estiverem armazenados em um prefixo de bucket S3, substitua pelo nome do seu prefixo. Caso contrário, você pode remover esta parte da consulta, incluindo a barra “/” no final.
  • Para has_encrypted_data, se seus dados de log do AWS WAF estiverem criptografados em repouso, altere o valor para true, caso contrário, false é o valor correto.
CREATE EXTERNAL TABLE IF NOT EXISTS wafrulesdb.waftable (
  `terminatingRuleId` string,
  `httpSourceName` string,
  `action` string,
  `httpSourceId` string,
  `terminatingRuleType` string,
  `webaclId` string,
  `timestamp` float,
  `formatVersion` int,
  `ruleGroupList` array<string>,
  `httpRequest` struct<`headers`:array<struct<name:string,value:string>>,clientIp:string,args:string,requestId:string,httpVersion:string,httpMethod:string,country:string,uri:string>,
  `rateBasedRuleList` string,
  `nonTerminatingMatchingRules` string,
  `terminatingRuleMatchDetails` string 
)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
  'serialization.format' = '1'
) LOCATION 's3://<your-bucket-name>/<bucket-prefix-if-exist>/'
TBLPROPERTIES ('has_encrypted_data'='false');

Execute a consulta no console do Athena. Depois que a consulta for concluída, o Athena registrará a tabela “waftable”, o que tornará os dados nela disponíveis para consultas.

Execute consultas SQL para identificar os limites das regras baseadas em taxa

Agora que você tem uma tabela no Athena, sabe onde os dados estão localizados e tem o esquema correto, pode executar consultas SQL para cada uma das regras baseadas em taxa e ver os resultados da consulta.

Regra baseada em taxa geral para todos os endpoints de aplicativos

Você começará com uma consulta SQL que identifica a regra geral. O fator crítico para determinar a regra geral é executar a consulta contra dados de logs do AWS WAF que representam um volume alto e saudável de requisições. A seguinte consulta define uma janela de tempo de 6 horas à noite, expressa como 2020-12-01 16:00:00 e 2020-12-01 22:00:00. As janelas de tempo podem abranger algumas horas ou vários dias; no entanto, esta janela de tempo deve ser uma boa representação do volume de tráfego, que você usará como base para identificar o limite. Por exemplo, se a sua aplicação é mais utilizada durante determinados períodos, você deve avaliar os dados de log para esse período. No exemplo mostrado aqui, limitamos os resultados da consulta aos 100 principais IPs em nossas consultas SQL. Você pode ajustar o limite de acordo com suas necessidades, atualizando o valor LIMIT.

SELECT
  httprequest.clientip,
  COUNT(*) AS "count"
FROM wafrulesdb.waftable
WHERE from_unixtime(timestamp/1000) BETWEEN TIMESTAMP '2020-12-01 16:00:00' AND TIMESTAMP '2020-12-01 22:00:00'
GROUP BY httprequest.clientip, FLOOR("timestamp"/(1000*60*5))
ORDER BY count DESC
LIMIT 100; 

Atualize a janela de tempo de acordo com suas necessidades e execute a consulta no console do Athena. Os resultados mostrarão os principais IPs solicitantes em qualquer período de 5 minutos entre duas datas, conforme ilustrado na Figura 2.

Figure 2: The top requesting IP in any 5-minute period between datesFigura 2: Os IP que mais fizeram requisições em qualquer período de 5 minutos entre as datas.

Você pode visualizar os dados de resultados para ver uma visão completa da contagem de requisições por IP. O gráfico na Figura 3 ilustra os resultados da consulta SQL.

Figure 3: Chart: Top requesting IP in any 5-minute period between datesFigura 3: Gráfico: Principais IPs requisitantes em qualquer período de 5 minutos entre as datas.

Os resultados são ordenados mostrando os IPs com o maior volume de requisições para cada período de 5 minutos. Isso significa que o mesmo IP pode aparecer várias vezes, se a maioria das requisições foi feita dentro desse intervalo de 5 minutos. No nosso exemplo, olhando para o resultado, uma excelente primeira regra geral seria limitar o volume de requisições a cerca de 7.000 requisições dentro de um período de 5 minutos. Você pode criar a regra AWS WAF usando o seguinte JSON e o editor de regras JSON, ou usando o editor visual de regras do AWS WAF seguindo estas instruções. Se você estiver usando o JSON a seguir, certifique-se de substituir o valor do limite pelo valor que você identificou ao executar a consulta SQL anteriormente.

{
  "Name": "BlanketRule",
  "Priority": 2,
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "BlanketRule"
  },
  "Statement": {
    "RateBasedStatement": {
      "Limit": 7000,
      "AggregateKeyType": "IP"
    }
  }
}

Às vezes, um cliente se conecta a um aplicativo por meio de um proxy HTTP ou uma rede de entrega de conteúdo (CDN), o que obscurece o endereço IP de origem do cliente. É importante identificar o IP do cliente em vez do IP do proxy ou CDN, porque bloquear IPs de origem pode causar um impacto indesejado mais amplo. Você pode usar várias ferramentas para ajudá-lo a identificar se o IP de origem pode ser de uma CDN. Nesse caso, você precisaria consultar e filtrar os cabeçalhos X-Forwarded-For, True-Client-IP ou outros personalizados. Os provedores de CDN geralmente publicam quais cabeçalhos eles adicionam às requisições, mas X-Forwarded-For e True-Client-IP são comuns. A consulta a seguir mostra como você pode fazer referência a esses cabeçalhos, ilustrando com o cabeçalho X-Forwarded-For, para escrever regras baseadas em taxa. Você pode substituir X-Forwarded-For pelo cabeçalho que espera conter o IP do cliente.

SELECT
  header.value,
  COUNT(*) AS "count"
FROM wafrulesdb.waftable, UNNEST(httprequest.headers) as t(header)
WHERE
    from_unixtime(timestamp/1000) BETWEEN TIMESTAMP '2020-12-01 16:00:00' AND TIMESTAMP '2020-12-01 22:00:00'
  AND
    header.name = 'X-Forwarded-For'
GROUP BY header.value, FLOOR("timestamp"/(1000*60*5))
ORDER BY count DESC
LIMIT 100;

Regra baseada em URI para endpoints de aplicações específicos

Suponha que você queira limitar ainda mais as requisições para a página de login em seu site. Para fazer isso, você pode adicionar a seguinte condição de correspondência de string a uma regra baseada em taxa:

  • A parte request to filter on é a URI
  • O Match Type é Starts with
  • Um Value to match é /login (isso precisa ser o que identifica a página de login na URI da requisição web)

A seguir, você deve identificar qual é o volume típico de requisições para a URI /login na aplicação. A seguinte consulta SQL faz exatamente isso.

SELECT
  httprequest.clientip,
  httprequest.uri,
  COUNT(*) AS "count"
FROM wafrulesdb.waftable
WHERE 
  from_unixtime(timestamp/1000) BETWEEN TIMESTAMP '2020-12-01 16:00:00' AND TIMESTAMP '2020-12-01 22:00:00'
AND
  httprequest.uri = '/login'
GROUP BY httprequest.clientip, httprequest.uri, FLOOR("timestamp"/(1000*60*5))
ORDER BY count DESC
LIMIT 100;

Substitua o intervalo de tempo 2020-12-01 16:00:00 e 2020-12-01 22:00:00, e o valor httprequest.uri, se aplicável, e execute a consulta no console do Athena. Os resultados mostram o endereço IP e a URI /login com maior número de requisições em cada período de 5 minutos entre as datas, conforme ilustrado na Figura 4.

Figure 4: The highest requesting IP and /login URI for every 5-minute period between datesFigura 4: O endereço IP e a URI /login com maior número de requisições em cada período de 5 minutos entre as datas.

A Figura 5 ilustra um gráfico baseado nos resultados da consulta para o endereço IP e a URI /login com maior número de requisições em cada período de 5 minutos entre as datas.

Figure 5: Chart: The highest requesting IP and /login URI for every 5-minute period between datesFigura 5: Gráfico: O endereço IP e a URI /login com maior número de requisições em cada período de 5 minutos entre as datas.

Com base nos resultados da consulta SQL, você especificaria um limite de taxa de 150 requisições a cada 5 minutos. Adicionando esta regra baseada em taxa a uma web ACL, você limitará as requisições à sua página de login por endereço IP sem afetar o restante do seu site. Mais uma vez, você pode criar a regra do AWS WAF usando o seguinte JSON e o editor de regras JSON, ou usando o editor visual de regras do AWS WAF e seguindo estas instruções. Se você estiver usando o seguinte JSON, verifique se substituiu o valor Limite pelo valor que você identificou ao executar a consulta SQL anteriormente.

{
  "Name": "UriBasedRule",
  "Priority": 1,
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "UriBasedRule"
  },
  "Statement": {
    "RateBasedStatement": {
      "Limit": 150,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "FieldToMatch": {
            "UriPath": {}
          },
          "PositionalConstraint": "STARTS_WITH",
          "SearchString": "/login",
          "TextTransformations": [
            {
              "Type": "NONE",
              "Priority": 0
            }
          ]
        }
      }
    }
  }
}

As regras do AWS WAF com um valor mais baixo de Priority são avaliadas antes das regras com um valor mais alto. Para que as regras do AWS WAF funcionem conforme o esperado (avaliando primeiro a regra mais específica – a regra UriBasedRule – e somente depois a regra BlanketRule mais ampla), você deve definir a prioridade da regra do AWS WAF. Isso pode ser feito atualizando o JSON e definindo o valor de Priority como 1 para a regra BlanketRule e 0 para a regra UriBasedRule, ou usando o editor visual de regras do AWS WAF. A prioridade esperada da regra do AWS WAF deve ser conforme ilustrado na Figura 6.

Figure 6: AWS WAF rules with priority for UriBasedRuleFigura 6: Regras do AWS WAF com prioridade para UriBasedRule.

Se você deseja saber o volume de requisições em todas as URIs da aplicação, o seguinte SQL irá realizar isso.

SELECT
  httprequest.clientip,
  httprequest.uri,
  COUNT(*) AS "count"
FROM wafrulesdb.waftable
WHERE from_unixtime(timestamp/1000) BETWEEN TIMESTAMP '2020-12-01 16:00:00' AND TIMESTAMP '2020-12-01 22:00:00'
GROUP BY httprequest.clientip, httprequest.uri, FLOOR("timestamp"/(1000*60*5))
ORDER BY count DESC
LIMIT 100;

A Figura 7 mostra um gráfico de como os resultados da consulta SQL podem parecer.

Figure 7: The highest requesting IP and URI for every 5-minute period between datesFigura 7: O endereço IP e a URI com maior número de requisições em cada período de 5 minutos entre as datas.

Grupos de regras de reputação de IP para bloquear bots ou outras ameaças

Você pode usar regras de reputação de IP para bloquear requisições com base em sua origem. O AWS WAF oferece uma ampla opções de grupos de regras gerenciadas, e a lista de reputação de IP da Amazon é aquela que ajudará a reduzir sua exposição ao tráfego de bots ou tentativas de exploração.

Para adicionar a regra da lista de reputação de IP da Amazon à sua WEB ACL

  1. Abra o console do AWS WAF e navegue para a visualização de grupos de regras gerenciadas.

    Figure 8: The managed rule group view in AWS WAFFigura 8: A visualização do grupo de regras gerenciadas no AWS WAF.

  2. Selecione AWS managed rule groups e, para Amazon IP reputation list, escolha Add to web ACL.

    Figure 9: Add the Amazon IP reputation list to the web ACLFigura 9: Adicione a lista de reputação de IP da Amazon à web ACL.

  3. Role até o final da página e escolha Add rule.
  4. Neste ponto, você deverá ver a visualização Set rule priority. Mova a regra gerenciada da Amazon para cima para que ela tenha a prioridade mais alta. Se uma solicitação originar de um bot, você deseja negar a solicitação o mais cedo possível, e você alcança exatamente isso atribuindo a prioridade mais alta à regra da lista de reputação de IP da Amazon. A ordem final das regras do AWS WAF deve ser como mostrado na Figura 10.

    Figure 10: Final AWS WAF rules ordered by priorityFigura 10: Regras finais do AWS WAF ordenadas por prioridade.

Considerações para regras baseadas em taxa

É importante observar que as regras do AWS WAF mais específicas devem ter uma prioridade mais alta, porque você deseja que essas regras limitem o volume de requisições primeiro. Em nosso exemplo, a estratégia das regras é baseada primeiro em uma URI específica e depois em uma regra geral que limita as requisições em toda a aplicação.

As regras baseadas em taxa que discutimos aqui fornecem uma base sólida para ajudá-lo a proteger suas aplicações voltadas para a internet contra floods comuns de requisições HTTP. No entanto, a solução neste blog post não deve ser vista como uma configuração única, mas sim como uma atividade iterativa.

Você deve determinar um intervalo de tempo saudável para executar consultas do Amazon Athena para identificar uma nova regra baseada em taxa que esteja alinhada com o crescimento da aplicação e o aumento do volume de requisições. Revisar as regras baseadas em taxa em uma base iterativa e incorporá-las aos seus processos existentes, como o ciclo de vida do desenvolvimento de software, é uma ótima maneira de agendar o processo de revisão. Cada regra do AWS WAF pode publicar métricas do Amazon CloudWatch, que podem ser usadas para acionar alertas antes que os limites sejam ultrapassados. Você pode usar alertas para criar tickets para equipes de operações com base em limites que você definiu. Isso alerta suas equipes de operações para revisar a situação e ver se é um ataque DDoS sendo frustrado versus tráfego legítimo sendo descartado.

Depois de definir a quantidade de requisições, adicione uma folga para permitir o crescimento. As regras baseadas em taxa devem ter uma folga razoável para levar em conta o crescimento futuro próximo da aplicação. Por exemplo, quando um resultado de consulta do Athena mostra um volume de requisições de 500 requisições, uma regra baseada em taxa com um limite de 1.000 requisições dá uma folga de mais 500 requisições para levar em conta o crescimento da aplicação.

Resumo

Neste post, apresentamos as três regras baseadas em taxa mais importantes do AWS WAF para proteger suas aplicações web de eventos comuns de flood HTTP. Também abordamos como implementar essas regras baseadas em taxa e determinamos um limite de requisições apropriado para sua aplicação usando logs do AWS WAF e consultas do Amazon Athena.

Para saber mais sobre as melhores práticas que ajudam você a proteger seus sites e aplicações web contra vários vetores de ataque usando o AWS WAF, consulte nosso whitepaper, Diretrizes para Implementar o AWS WAF.

Você pode aprender mais sobre o AWS WAF em outros posts do blog de segurança relacionados ao AWS WAF.

 

Este artigo foi traduzido do Blog da AWS em Inglês.


Artem Lovan é um Arquiteto de Soluções Sênior baseado em Nova York. Ele ajuda os clientes a projetar e otimizar aplicações na AWS. Ele tem experiência em diversos níveis de TI, incluindo infraestrutura, redes, segurança, DevOps e desenvolvimento de software.

 

 

 

 

Jesse Lepich é um Arquiteto Sênior de Soluções de Segurança na AWS com sede em Lake St. Louis, Missouri. Seu foco é ajudar os clientes a implementar serviços de segurança nativos da AWS. Fora da segurança na nuvem, seus interesses incluem relaxar com a família, esqui aquático descalço, snowboard/esqui na neve, surf, navegação/velejar e escalada em montanha.

 

 

 

 

Revisores

Paulo Cesar é um Technical Account Manager na AWS e reside em São Paulo, Brasil. Seu foco é ajudar clientes de diversos setores a aumentarem seus níveis de maturidade de segurança em cloud, apoiando-os também em diversos temas como otimização de custos e performance. Possui experiência em segurança ofensiva e defensiva, atua com tecnologia há mais de 23 anos.

 

 

 

 

Ricardo Makino atualmente é arquiteto de soluções na AWS apoiando os clientes de governo em sua jornada para a nuvem, possui mais de 20 anos de experiência em TI onde já passou pelos setores de governo, educação e pesquisa atuando como administrador de redes e sistemas, analista de segurança da informação, pesquisador de segurança da informação e especialista em nuvem, e esteve envolvido em diversos projetos de tecnologias de orquestração de infraestrutura e plataforma, otimização de aplicações, migrações, segurança de redes e aplicações e outros.