DocumentaçãoAEMTutoriais do AEMTutorials da AEM Foundation

Usar o ModSecurity para proteger o seu site do AEM contra ataques de DoS

Last update: Wed Jun 04 2025 00:00:00 GMT+0000 (Coordinated Universal Time)
  • Aplica-se a:
  • Experience Manager 6.5
  • Experience Manager as a Cloud Service
  • Tópicos:

Criado para:

  • Experiente
  • Administrador
  • Desenvolvedor

Saiba como habilitar o ModSecurity para proteger o seu site contra ataques de negação de serviço (DoS), usando o Conjunto de Regras Principais (CRS) do OWASP ModSecurity no Dispatcher do Adobe Experience Manager (AEM) Publish.

https://video.tv.adobe.com/v/3452130?quality=12&learn=on&captions=por_br

Visão geral

A fundação Open Web Application Security Project® (OWASP) publica o OWASP Top 10, que descreve os 10 receios de segurança mais cruciais para aplicativos da web.

O ModSecurity é uma solução de código aberto para várias plataformas que oferece proteção contra uma variedade de ataques contra aplicativos da web. Ele também permite monitorar o tráfego HTTP, o registro em log e a análise em tempo real.

O OWSAP® também fornece o Conjunto de Regras Principais de Segurança (CRS) do OWASP® ModSecurity. O CRS é um conjunto de regras genéricas de detecção de ataques para uso com o ModSecurity. Assim, o CRS tem como objetivo proteger os aplicativos da web contra uma ampla variedade de ataques, incluindo os 10 principais do OWASP, com uma quantidade mínima de falsos alertas.

Este tutorial demonstra como habilitar e configurar a regra DOS-PROTECTION do CRS para proteger o seu site contra um possível ataque de DoS.

TIP
É importante observar que a CDN gerenciada do AEM as a Cloud Service satisfaz a maioria dos requisitos de desempenho e segurança do cliente. No entanto, o ModSecurity fornece uma camada extra de segurança e permite regras e configurações específicas do cliente.

Adicionar o CRS ao módulo de projeto do Dispatcher

  1. Baixe e extraia o Conjunto de Regras Principais do OWASP ModSecurity mais recente.

    code language-shell 
    # Replace the X.Y.Z with relevent version numbers.
$ wget https://github.com/coreruleset/coreruleset/archive/refs/tags/vX.Y.Z.tar.gz

# For version v3.3.5 when this tutorial is published
$ wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.5.tar.gz

# Extract the downloaded file
$ tar -xvzf coreruleset-3.3.5.tar.gz

  2. Crie as pastas modsec/crs em dispatcher/src/conf.d/ no código do seu projeto do AEM. Por exemplo, na cópia local do projeto de sites da WKND no AEM.

    Pasta do CRS no código do projeto do AEM: ModSecurity {width="200" modal="regular"}

  3. Copie a pasta coreruleset-X.Y.Z/rules do pacote de versão do CRS baixado para a pasta dispatcher/src/conf.d/modsec/crs.

  4. Copie o arquivo coreruleset-X.Y.Z/crs-setup.conf.example do pacote de versão do CRS baixado para a pasta dispatcher/src/conf.d/modsec/crs e renomeie-o como crs-setup.conf.

  5. Desabilite todas as regras do CRS copiadas de dispatcher/src/conf.d/modsec/crs/rules, renomeando-as como XXXX-XXX-XXX.conf.disabled. Você pode usar os comandos abaixo para renomear todos os arquivos de uma vez.

    code language-shell 
    # Go inside the newly created rules directory within the dispathcher module
$ cd dispatcher/src/conf.d/modsec/crs/rules

# Rename all '.conf' extension files to '.conf.disabled'
$ for i in *.conf; do mv -- "$i" "$i.disabled"; done

    Consulte as regras do CRS renomeadas e o arquivo de configuração no código do projeto da WKND.

    Regras do CRS desabilitadas no código do projeto do AEM: ModSecurity {width="200" modal="regular"}

Habilitar e configurar a regra de proteção contra ataques de negação de serviço (DoS)

Para habilitar e configurar a regra de proteção contra ataques de negação de serviço (DoS), siga as etapas abaixo:

  1. Habilite a regra de proteção contra DoS, renomeando REQUEST-912-DOS-PROTECTION.conf.disabled como REQUEST-912-DOS-PROTECTION.conf (ou remova .disabled da extensão do nome da regra) na pasta dispatcher/src/conf.d/modsec/crs/rules.

  2. Para configurar a regra, defina as variáveis DOS_COUNTER_THRESHOLD, DOS_BURST_TIME_SLICE, DOS_BLOCK_TIMEOUT.

    1. Crie um arquivo crs-setup.custom.conf dentro da pasta dispatcher/src/conf.d/modsec/crs.
    2. Adicione o trecho de regra abaixo ao arquivo recém-criado.
    code language-none 
    # The Denial of Service (DoS) protection against clients making requests too quickly.
# When a client is making more than 25 requests (excluding static files) within
# 60 seconds, this is considered a 'burst'. After two bursts, the client is
# blocked for 600 seconds.
SecAction \
    "id:900700,\
    phase:1,\
    nolog,\
    pass,\
    t:none,\
    setvar:'tx.dos_burst_time_slice=60',\
    setvar:'tx.dos_counter_threshold=25',\
    setvar:'tx.dos_block_timeout=600'"

Neste exemplo de configuração de regra, o DOS_COUNTER_THRESHOLD é 25, o DOS_BURST_TIME_SLICE é 60 segundos, e o DOS_BLOCK_TIMEOUT expira em 600 segundos. Esta configuração faz com que mais de duas ocorrências de 25 solicitações, excluindo arquivos estáticos, dentro de 60 segundos, seja qualificado como um ataque de DoS e o que resulta no bloqueio do cliente solicitante por 600 segundos (ou 10 minutos).

WARNING
Para definir os valores apropriados para as suas necessidades, colabore com a equipe de segurança da web.

Inicializar o CRS

Para inicializar o CRS, remova falsos positivos comuns e adicione exceções locais para o seu site, seguindo as etapas abaixo:

  1. Para inicializar o CRS, remova .disabled do arquivo REQUEST-901-INITIALIZATION. Em outras palavras, renomeie o arquivo REQUEST-901-INITIALIZATION.conf.disabled como REQUEST-901-INITIALIZATION.conf.

  2. Para remover os falsos positivos comuns, como o ping do IP local (127.0.0.1), remova .disabled do arquivo REQUEST-905-COMMON-EXCEPTIONS.

  3. Para adicionar exceções locais, como a plataforma do AEM ou caminhos específicos do site, renomeie o REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example como REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

    1. Adicione exceções de caminho específicas da plataforma do AEM ao arquivo recém-renomeado.
    code language-none 
    ########################################################
# AEM as a Cloud Service exclusions                    #
########################################################
# Ignoring AEM-CS Specific internal and reserved paths

SecRule REQUEST_URI "@beginsWith /systemready" \
    "id:1010,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleEngine=Off"

SecRule REQUEST_URI "@beginsWith /system/probes" \
    "id:1011,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleEngine=Off"

SecRule REQUEST_URI "@beginsWith /gitinit-status" \
    "id:1012,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleEngine=Off"

########################################################
# ADD YOUR SITE related exclusions                     #
########################################################
...

  4. Além disso, remova .disabled de REQUEST-910-IP-REPUTATION.conf.disabled para verificação de bloco de reputação de IP e REQUEST-949-BLOCKING-EVALUATION.conf.disabled para verificação da pontuação de anomalias.

TIP
Ao configurar o AEM 6.5, certifique-se de substituir os caminhos acima pelos respectivos caminhos do AMS ou no local que verificam a integridade do AEM (também conhecidos como caminhos de heartbeat).

Adicionar configuração do ModSecurity Apache

Para habilitar o ModSecurity (também conhecido como módulo mod_security Apache), siga as etapas abaixo:

  1. Crie modsecurity.conf em dispatcher/src/conf.d/modsec/modsecurity.conf com as configurações principais abaixo.

    code language-none 
    # Include the baseline crs setup
Include conf.d/modsec/crs/crs-setup.conf

# Include your customizations to crs setup if exist
IncludeOptional conf.d/modsec/crs/crs-setup.custom.conf

# Select all available CRS rules:
#Include conf.d/modsec/crs/rules/*.conf

# Or alternatively list only specific ones you want to enable e.g.
Include conf.d/modsec/crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
Include conf.d/modsec/crs/rules/REQUEST-901-INITIALIZATION.conf
Include conf.d/modsec/crs/rules/REQUEST-905-COMMON-EXCEPTIONS.conf
Include conf.d/modsec/crs/rules/REQUEST-910-IP-REPUTATION.conf
Include conf.d/modsec/crs/rules/REQUEST-912-DOS-PROTECTION.conf
Include conf.d/modsec/crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf

# Start initially with engine off, then switch to detection and observe, and when sure enable engine actions
#SecRuleEngine Off
#SecRuleEngine DetectionOnly
SecRuleEngine On

# Remember to use relative path for logs:
SecDebugLog logs/httpd_mod_security_debug.log

# Start with low debug level
SecDebugLogLevel 0
#SecDebugLogLevel 1

# Start without auditing
SecAuditEngine Off
#SecAuditEngine RelevantOnly
#SecAuditEngine On

# Tune audit accordingly:
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIJDEFHZ
SecAuditLogType Serial

# Remember to use relative path for logs:
SecAuditLog logs/httpd_mod_security_audit.log

# You might still use /tmp for temporary/work files:
SecTmpDir /tmp
SecDataDir /tmp

  2. Selecione o .vhost desejado no módulo dispatcher/src/conf.d/available_vhosts do Dispatcher do projeto do AEM, como, por exemplo, wknd.vhost, e adicione a entrada abaixo fora do bloco <VirtualHost>.

    code language-none 
    # Enable the ModSecurity and OWASP CRS
<IfModule mod_security2.c>
    Include conf.d/modsec/modsecurity.conf
</IfModule>

...

<VirtualHost *:80>
    ServerName    "publish"
    ...
</VirtualHost>

Todas as configurações do CRS do ModSecurity e DOS-PROTECTION acima estão disponíveis na ramificação tutorial/enable-modsecurity-crs-dos-protection do projeto de sites da WKND no AEM para revisão.

Validar configuração do Dispatcher

Ao trabalhar com o AEM as a Cloud Service, antes de implantar as suas alterações na configuração do Dispatcher, é recomendável validá-las localmente, usando-se o script validate das Ferramentas do Dispatcher do SDK do AEM.

# Go inside Dispatcher SDK 'bin' directory
$ cd <YOUR-AEM-SDK-DIR>/<DISPATCHER-SDK-DIR>/bin

# Validate the updated Dispatcher configurations
$ ./validate.sh <YOUR-AEM-PROJECT-CODE-DIR>/dispatcher/src

Implantar

Implante as configurações do Dispatcher validadas localmente, usando o pipeline Camada da web ou Pilha completa do Cloud Manager. Você também pode usar o Ambiente de desenvolvimento rápido para obter um tempo de resposta mais rápido.

Verificar

Para verificar a proteção contra DoS, neste exemplo, vamos enviar mais de 50 solicitações (25 limites de solicitação vezes duas ocorrências) em um intervalo de 60 segundos. No entanto, essas solicitações devem passar pela CDN integrada do AEM as a Cloud Service ou por qualquer outra CDN que esteja à frente do seu site.

Uma técnica para obter a passagem pela CDN é adicionar um parâmetro de consulta com um novo valor aleatório em cada solicitação de página do site.

Para acionar um número maior de solicitações (50 ou mais) em um curto período (como 60 segundos), o Apache JMeter ou a ferramenta de referência ou guia pode ser usada.

Simular um ataque de DoS com o script do JMeter

Para simular um ataque de DoS com o JMeter, siga as etapas abaixo:

  1. Baixe o Apache JMeter e instale-o localmente

  2. Execute-o localmente, usando o script jmeter do diretório <JMETER-INSTALL-DIR>/bin.

  3. Abra o script do JMX WKND-DoS-Attack-Simulation-Test de amostra no JMeter, usando o menu de ferramentas Abrir.

    Abra amostra do script de teste do JMX contra ataques de DoS à WKND: ModSecurity

  4. Atualize o valor do campo Nome ou IP do servidor na Página inicial e na Página de aventura do sampler de solicitação HTTP correspondente ao URL do ambiente de teste do AEM. Revise outros detalhes da amostra de script do JMeter.

    JMetere de solicitação HTTP do nome do servidor do AEM: ModSecurity

  5. Para executar o script, pressione o botão Iniciar no menu de ferramentas. O script envia 50 solicitações HTTP (5 usuários e 10 contagens de loop) à Página inicial e à Página de aventura do site da WKND. Portanto, um total de 100 solicitações para arquivos não estáticos qualifica o ataque de DoS pela configuração personalizada da regra DOS-PROTECTION do CRS.

    Executar script do JMeter: ModSecurity

  6. O ouvinte do JMeter Exibir resultados na tabela mostra o status de resposta Falha para a solicitação número ~ 53 e posterior.

    Falha da resposta na exibição de resultados na tabela do JMeter: ModSecurity

  7. O Código de resposta HTTP 503 é retornado para as solicitações com falha. Você pode exibir os detalhes, usando o ouvinte do JMeter Exibir árvore de resultados.

    JMeter da resposta 503: ModSecurity

Revisar logs

A configuração do agente de log do ModSecurity registra os detalhes do incidente de ataque de DoS. Para visualizar os detalhes, siga as etapas abaixo:

  1. Baixe e abra o arquivo de log httpderror do Dispatcher do Publish.

  2. Pesquise a palavra burst no arquivo de log para ver as linhas de erro

    code language-none 
    Tue Aug 15 15:19:40.229262 2023 [security2:error] [pid 308:tid 140200050567992] [cm-p46652-e1167810-aem-publish-85df5d9954-bzvbs] [client 192.150.10.209] ModSecurity: Warning. Operator GE matched 2 at IP:dos_burst_counter. [file "/etc/httpd/conf.d/modsec/crs/rules/REQUEST-912-DOS-PROTECTION.conf"] [line "265"] [id "912170"] [msg "Potential Denial of Service (DoS) Attack from 192.150.10.209 - # of Request Bursts: 2"] [ver "OWASP_CRS/3.3.5"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "paranoia-level/1"] [tag "attack-dos"] [tag "OWASP_CRS"] [tag "capec/1000/210/227/469"] [hostname "publish-p46652-e1167810.adobeaemcloud.com"] [uri "/content/wknd/us/en/adventures.html"] [unique_id "ZNuXi9ft_9sa85dovgTN5gAAANI"]

...

Tue Aug 15 15:19:40.515237 2023 [security2:error] [pid 309:tid 140200051428152] [cm-p46652-e1167810-aem-publish-85df5d9954-bzvbs] [client 192.150.10.209] ModSecurity: Access denied with connection close (phase 1). Operator EQ matched 0 at IP. [file "/etc/httpd/conf.d/modsec/crs/rules/REQUEST-912-DOS-PROTECTION.conf"] [line "120"] [id "912120"] [msg "Denial of Service (DoS) attack identified from 192.150.10.209 (1 hits since last alert)"] [ver "OWASP_CRS/3.3.5"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "paranoia-level/1"] [tag "attack-dos"] [tag "OWASP_CRS"] [tag "capec/1000/210/227/469"] [hostname "publish-p46652-e1167810.adobeaemcloud.com"] [uri "/us/en.html"] [unique_id "ZNuXjAN7ZtmIYHGpDEkmmwAAAQw"]

  3. Revise os detalhes, como endereço IP do cliente, ação, mensagem de erro e detalhes da solicitação.

Impacto do ModSecurity no desempenho

Habilitar o ModSecurity e as regras associadas tem algumas implicações em relação ao desempenho, portanto, lembre-se de quais regras são necessárias, redundantes e ignoradas. Firme parcerias com os seus especialistas em segurança da web para habilitar e personalizar as regras do CRS.

Regras adicionais

Este tutorial só habilita e personaliza a regra DOS-PROTECTION do CRS para fins de demonstração. É recomendável firmar parcerias com especialistas em segurança da web para entender, revisar e configurar as regras apropriadas.

recommendation-more-help
c92bdb17-1e49-4e76-bcdd-89e4f85f45e6