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 filtro de tráfego de limite de taxa regras e outras estratégias na CDN gerenciada pelo AEM as a Cloud Service (AEMCS). Esses ataques causam picos de tráfego no CDN e possivelmente no serviço de publicação do AEM (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 o limite de taxa regras de filtro de tráfego para mitigar esses ataques. O tutorial também descreve como configurar alertas para ser 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 que a degradação de desempenho antes do limite de taxa definido pelo Adobe é atendida, é recomendável estender as proteções padrão por meio do 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.

Adobe envia um pico de tráfego no alerta de origem como um Notificação da Central 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.

Configurar as ferramentas do painel usando uma das seguintes opções:

ELK - configurando ferramentas de painel de controle

A variável Elasticsearch, Logstash e Kibana (ELK) As ferramentas de painel fornecidas pelo Adobe podem ser usadas 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

Clientes que têm Encaminhamento do Log do Splunk habilitado O pode criar novos painéis para analisar os padrões de tráfego.

Para criar painéis no Splunk, siga Painéis do Splunk para a Análise de Log do AEM CS CDN etapas.

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 o filtro de tráfego de limite de taxa regras no do projeto AEM /config/cdn.yaml arquivo, 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 assim, você pode 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 tráfego de limite de taxa, é recomendável usar solicitar transformações para desfazer a definição de parâmetros de consulta não necessários para a aplicação minimizar as maneiras de ignorar o cache por meio de técnicas de eliminação de cache. Por exemplo, se você só quiser permitir 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 é recebido quando a regra é 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 Benchmark Apache, Apache JMeter, Vegeta, e outros podem ser usados.

Solicitações de borda

Usando o seguinte Vegeta comando, você pode fazer muitas solicitações ao 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 do CDN e fazer solicitações à origem (serviço de Publicação AEM), você pode adicionar um parâmetro de consulta exclusivo ao URL. Consulte a amostra de script Apache JMeter do Simular um ataque de DoS usando o script JMeter