Bloqueio de ataques de DoS e DDoS usando regras de filtro de tráfego

Saiba como bloquear ataques de Negação de Serviço (DoS) e de Negação de Serviço Distribuída (DDoS) usando regras de filtro de limite de tráfego de taxa e outras estratégias na CDN gerenciada pelo AEM as a Cloud Service (AEMCS). Esses ataques causam picos de tráfego na CDN e possivelmente no serviço AEM Publish (também conhecido como origem) e podem afetar a capacidade de resposta e a disponibilidade do site.

Este tutorial serve como um guia sobre como analisar seus padrões de tráfego e configurar as regras de filtro de tráfego de limite de taxa para mitigar esses ataques. O tutorial também descreve como configurar alertas para que você seja notificado quando houver suspeita de ataque.

Noções básicas sobre proteção

Vamos entender as proteções de DDoS padrão para o seu site de AEM:

Essas proteções integradas devem ser consideradas uma linha de base para a capacidade de uma organização de minimizar o impacto no desempenho de um ataque de DDoS. Como cada site tem características de desempenho diferentes e pode observar essa degradação de desempenho antes que o limite de taxa definido pelo Adobe seja atingido, é recomendável estender as proteções padrão por meio da configuração do cliente.

Vamos analisar algumas medidas adicionais e recomendadas que os clientes podem tomar para proteger seus sites contra ataques de DDoS:

Variações das regras de tráfego de limite de taxa rate-limit-variations

Há duas variações de regras de tráfego de limite de taxa:

Jornada do cliente

As etapas abaixo refletem o processo provável pelo qual os clientes devem proteger seus sites.

O restante deste tutorial o orienta por esse processo.

Reconhecendo a necessidade de configurar regras recognize-the-need

Como mencionado anteriormente, o Adobe por padrão bloqueia o tráfego na CDN que excede uma determinada taxa. No entanto, alguns sites podem enfrentar desempenho degradado abaixo desse limite. Portanto, as regras de filtro de tráfego de limite de taxa devem ser configuradas.

Idealmente, você configuraria as regras antes de entrar em produção. Na prática, muitas organizações declaram regras reativamente apenas uma vez alertadas de um pico de tráfego, indicando um provável ataque.

O Adobe envia um alerta de pico de tráfego na origem como uma Notificação do Centro de Ações quando um limite padrão de tráfego de um único endereço IP é excedido, para um determinado PoP. Se você recebeu esse alerta, é recomendável configurar uma regra de filtro de tráfego de limite de taxa. Esse alerta padrão é diferente dos alertas que devem ser ativados explicitamente pelos clientes ao definir as regras de filtro de tráfego, sobre as quais você aprenderá em uma seção futura.

Análise de padrões de tráfego analyze-traffic

Se o site já estiver ativo, você poderá analisar os padrões de tráfego usando logs CDN e painéis fornecidos pelo Adobe.

Configure a ferramenta de painel usando uma das seguintes opções:

ELK - configurando ferramentas de painel de controle

A ferramenta de painel Elasticsearch, Logstash e Kibana (ELK) fornecida pelo Adobe pode ser usada para analisar os logs de CDN. Essa ferramenta inclui um painel que visualiza os padrões de tráfego, facilitando a determinação dos limites ideais para suas regras de filtro de tráfego de limite de taxa.

Splunk - configurando as ferramentas do painel

Os clientes que têm o encaminhamento do Log de Splunk habilitado podem criar novos painéis para analisar os padrões de tráfego.

Para criar painéis no Splunk, siga painéis do Splunk para as etapas de Análise de Log da CDN do AEMCS.

Examinando dados

As seguintes visualizações estão disponíveis nos painéis ELK e Splunk:

Escolha de valores de limite

Os valores-limite para as regras de filtro de tráfego limite de taxa devem se basear na análise acima e garantir que o tráfego legítimo não seja bloqueado. Consulte a tabela a seguir para obter orientação sobre como escolher os valores de limite:

O múltiplo a ser usado depende de suas expectativas de picos normais no tráfego devido ao tráfego orgânico, campanhas e outros eventos. Um múltiplo entre 5-10 pode ser razoável.

Se o site ainda não estiver ativo, não há dados para analisar e você deve fazer uma suposição detalhada sobre os valores apropriados a serem definidos para as regras de filtro de tráfego de limite de taxa. Por exemplo:

Configuração de regras configure-rules

Configure as regras de filtro de limite de taxa no arquivo /config/cdn.yaml do projeto AEM, com valores baseados na discussão acima. Se necessário, consulte sua equipe de Segurança da Web para verificar se os valores de limite de taxa são apropriados e não bloqueiam o tráfego legítimo.

Consulte Criar regras no projeto AEM para obter mais detalhes.

kind: CDN
version: '1'
metadata:
  envTypes:
    - dev
    - stage
    - prod
data:
  trafficFilters:
    rules:
    ...
    #  Prevent attack at edge by blocking client for 5 minutes if they make more than 500 requests per second on average
      - name: prevent-dos-attacks-edge
        when:
          reqProperty: tier
          in: ["author","publish"]
        rateLimit:
          limit: 500 # replace with the appropriate value
          window: 10 # compute the average over 10s
          penalty: 300 # block IP for 5 minutes
          count: all # count all requests
          groupBy:
            - reqProperty: clientIp
        action:
          type: log
          experimental_alert: true
    #  Prevent attack at origin by blocking client for 5 minutes if they make more than 100 requests per second on average
      - name: prevent-dos-attacks-origin
        when:
          reqProperty: tier
          in: ["author","publish"]
        rateLimit:
          limit: 100 # replace with the appropriate value
          window: 10 # compute the average over 10s
          penalty: 300 # block IP for 5 minutes
          count: fetches # count only fetches
          groupBy:
            - reqProperty: clientIp
        action:
          type: log
          experimental_alert: true

Observe que as regras de origem e de borda são declaradas e que a propriedade de alerta está definida como true para que você possa receber alertas sempre que o limite for atingido, provavelmente indicando um ataque.

Recomenda-se que o tipo de ação seja definido para registrar inicialmente, para que você possa monitorar o tráfego por algumas horas ou dias, garantindo que o tráfego legítimo não exceda essas taxas. Após alguns dias, altere para o modo de bloqueio.

Siga as etapas abaixo para implantar as alterações no ambiente do AEM CS:

Configurar regras de transformação de solicitação configure-request-transform-rules

Além das regras de filtro de limite de taxa de tráfego, é recomendável usar solicitar transformações para desdefinir parâmetros de consulta não necessários para o aplicativo, a fim de minimizar as formas de ignorar o cache por meio de técnicas de eliminação de cache. Por exemplo, se você quiser permitir apenas search e campaignId parâmetros de consulta, a seguinte regra pode ser declarada:

kind: "CDN"
version: "1"
metadata:
  envTypes:
    - dev
    - stage
    - prod
data:
  experimental_requestTransformations:
    rules:
      - name: unset-all-query-params-except-those-needed
        when:
          reqProperty: tier
          in: ["publish"]
        actions:
          - type: unset
            queryParamMatch: ^(?!search$|campaignId$).*$

Recebimento de alertas de regras de filtro de tráfego receiving-alerts

Como mencionado acima, se a regra de filtro de tráfego incluir experimental_alert: true, um alerta será recebido quando a regra for correspondida.

Atuação em alertas acting-on-alerts

Às vezes, o alerta é informativo, o que dá uma ideia da frequência dos ataques. Vale a pena analisar seus dados de CDN usando o painel descrito acima, para validar se o pico de tráfego se deve a um ataque e não apenas a um aumento no volume de tráfego legítimo. No último caso, considere aumentar o limite.

Simulação de ataque attack-simulation

Esta seção descreve métodos para simular um ataque de DoS, que podem ser usados para gerar dados para os painéis usados neste tutorial e para validar se as regras configuradas bloqueiam os ataques com êxito.

Para simular um ataque, ferramentas como o Apache Benchmark, o Apache JMeter, o Vegeta e outras podem ser usadas.

solicitações do Edge

Usando o seguinte comando Vegeta, você pode fazer muitas solicitações para o seu site:

$ echo "GET https://<YOUR-WEBSITE-DOMAIN>" | vegeta attack -rate=120 -duration=5s | vegeta report

O comando acima faz 120 solicitações por 5 segundos e gera um relatório. Supondo que o site não tenha taxa limitada, isso pode causar um pico no tráfego.

Solicitações de origem

Para ignorar o cache da CDN e fazer solicitações à origem (serviço AEM Publish), você pode adicionar um parâmetro de consulta exclusivo ao URL. Consulte o exemplo de script Apache JMeter do Simular ataque DoS usando o script JMeter