Aula 29: ModSecurity — WAF open source para Apache e Nginx: bloqueio de ataques web
O ModSecurity é, sem exagero, uma das ferramentas mais importantes que um profissional de segurança Linux pode dominar. Trata-se de um Web Application Firewall (WAF) open source que opera como módulo do servidor web — Apache ou Nginx — e intercepta requisições HTTP antes que elas atinjam a aplicação. Quando falamos de aplicações web, a superfície de ataque é imensa: injeção SQL, cross-site scripting (XSS), inclusão de arquivos, command injection e uma lista crescente de ameaças exploradas diariamente. O ModSecurity atua justamente nessa camada, aplicando regras que identificam e bloqueiam padrões maliciosos, registram tentativas de ataque e podem até modificar o fluxo da requisição em tempo real.
Nesta aula avançada, você deixará de apenas entender o conceito de WAF e passará a implementar uma solução completa e funcional em servidores Linux. Vamos instalar e configurar o ModSecurity tanto no Apache quanto no Nginx, cobrindo os sistemas operacionais mais utilizados em produção: Ubuntu/Debian e CentOS/RHEL/Rocky Linux. O objetivo não é apenas fazer o módulo carregar, mas entregar um ambiente com regras de detecção reais, baseadas no OWASP Core Rule Set (CRS), e testar efetivamente o bloqueio de ataques com requisições maliciosas.
Ao longo desta aula, explicarei cada comando, cada diretiva de configuração e cada saída esperada. Você entenderá por que uma regra bloqueia, como ajustar falsos positivos e como criar suas próprias regras personalizadas para proteger aplicações específicas. Mais do que decorar comandos, você aprenderá a raciocinar sobre a política de segurança, o que é essencial para qualquer analista de infraestrutura, administrador de sistemas ou engenheiro DevSecOps. Em nossos projetos na JRT Technology Solutions, utilizamos diariamente esses procedimentos para proteger ambientes de missão crítica, e o conhecimento aqui compartilhado reflete exatamente o que aplicamos em campo.
Antes de iniciar, é importante destacar que esta é uma aula prática e densa. Siga os passos na ordem, execute os comandos em um ambiente controlado e observe cada saída. Ao final, você terá um WAF operacional, capaz de bloquear ataques reais, e estará preparado para evoluir essa implementação com regras customizadas e boas práticas de tuning. Prepare seu laboratório, acesse seu servidor e vamos começar.
O que você vai aprender nesta aula
Ao concluir esta aula, você terá plena capacidade de implementar, configurar e gerenciar o ModSecurity como um WAF completo em servidores Linux. Os objetivos de aprendizagem são os seguintes:
- Compreender o funcionamento do ModSecurity como Web Application Firewall e suas fases de processamento de requisições;
- Instalar e configurar o ModSecurity no Apache em Ubuntu/Debian e CentOS/RHEL/Rocky Linux;
- Instalar e configurar o ModSecurity no Nginx, compreendendo a arquitetura de módulo dinâmico;
- Ativar o OWASP Core Rule Set (CRS) e ajustar os parâmetros essenciais de detecção;
- Criar regras personalizadas para bloquear ameaças específicas da sua aplicação;
- Testar a configuração com requisições maliciosas e verificar os logs de auditoria;
- Diagnosticar e resolver os erros mais comuns na implementação do WAF;
- Aplicar boas práticas de tuning, atualização de regras e monitoramento contínuo.
Pré-requisitos e Ambiente
Para acompanhar esta aula, você precisará de um servidor Linux com acesso root ou um usuário com privilégios sudo. O ambiente deve ter acesso à internet para instalar pacotes e clonar repositórios. Recomendo utilizar uma máquina virtual ou um servidor de testes, pois vamos manipular regras de segurança e reiniciar serviços web. Os pré-requisitos específicos são:
- Um servidor com Ubuntu 22.04/24.04 LTS ou Debian 12, preferencialmente atualizado;
- Alternativamente, um servidor com CentOS Stream 9, Rocky Linux 9 ou AlmaLinux 9;
- Serviço Apache já instalado e funcionando (versão 2.4.x);
- Serviço Nginx já instalado e funcionando (versão 1.18 ou superior) para a parte dedicada a ele;
- Conhecimento básico de linha de comando, edição de arquivos e gerenciamento de serviços;
- Ferramenta curl instalada para testar requisições HTTP;
- Editor de texto nano ou vim instalado.
O leitor já passou pelas aulas anteriores do curso e, portanto, domina conceitos de hardening, firewalls e administração de serviços Linux. Nesta aula, elevamos o nível para a camada de aplicação, onde as ameaças são mais sofisticadas. O ModSecurity será o componente central, e vamos integrá-lo ao Apache e ao Nginx de forma consistente e reproduzível.
Recomendo fortemente que você execute os passos em um ambiente isolado antes de aplicar em produção. A ativação de regras agressivas sem tuning pode bloquear requisições legítimas de aplicações web. Em nossos projetos na JRT Technology Solutions, sempre realizamos uma fase de testes com tráfego real antes de habilitar o modo de bloqueio, e você verá como fazer isso de forma segura ao longo das seções seguintes.
O que é o ModSecurity e como um WAF open source funciona
O ModSecurity é um firewall de aplicação web criado originalmente por Ivan Ristić em 2002 e posteriormente adquirido pela Trustwave, que o manteve como projeto open source. Hoje, ele é mantido pela comunidade e pela equipe do OWASP, servindo como motor de detecção para o Core Rule Set. A principal função do ModSecurity é inspecionar todas as requisições e respostas HTTP, comparando cada parte — cabeçalhos, corpo, cookies, parâmetros de URL — contra regras que definem comportamentos anômalos ou maliciosos. Quando uma regra corresponde, o motor pode bloquear a requisição, redirecionar, registrar em log ou executar ações customizadas.
O funcionamento interno do ModSecurity é baseado em fases de processamento. A fase 1 analisa os cabeçalhos da requisição antes do corpo ser lido. A fase 2 inspeciona o corpo da requisição, onde normalmente estão os dados de formulários e parâmetros POST. As fases 3 e 4 tratam das respostas HTTP, permitindo detectar vazamento de informações ou modificar cabeçalhos de saída. A fase 5 é usada para ações de log e auditoria após a resposta ser enviada. Essa arquitetura de fases permite que as regras sejam aplicadas no momento exato em que os dados estão disponíveis, otimizando o processamento e evitando falsos positivos desnecessários.
Um dos conceitos mais importantes no ModSecurity é o modelo de detecção de anomalia versus bloqueio direto. No modo tradicional, cada regra pode especificar uma ação deny quando atinge seu critério. No modo de detecção de anomalia, as regras apenas incrementam uma pontuação de anomalia por transação, e uma regra geral decide com base no limiar atingido. O OWASP CRS utiliza esse segundo modelo, o que facilita o tuning e reduz falsos positivos em aplicações reais. Você precisa entender essa diferença para interpretar corretamente os logs e ajustar os parâmetros de pontuação.
O ModSecurity não é um antivírus nem substitui um firewall de rede tradicional. Ele atua especificamente na camada HTTP, compreendendo a semântica das aplicações web. Isso significa que ele pode detectar um ataque de SQL injection em um parâmetro de login, mesmo quando o firewall de rede não vê nada além de uma conexão TCP válida. Em nossos projetos na JRT Technology Solutions, combinamos o ModSecurity com iptables/nftables e soluções de monitoramento, formando uma defesa em profundidade que cobre desde a camada de rede até a lógica de negócio da aplicação.
A principal vantagem de utilizar o ModSecurity em relação a WAFs comerciais é a transparência e o controle total sobre as regras. Você pode auditar cada regra, entender exatamente o que está sendo bloqueado e adaptar o comportamento às necessidades da sua aplicação. Além disso, por ser um módulo que roda dentro do processo do servidor web, a latência adicionada é mínima quando comparada a proxies externos. Nesta aula, veremos como aproveitar esses benefícios na prática.
Instalação do ModSecurity no Apache em Ubuntu/Debian e CentOS/RHEL/Rocky
O primeiro passo é instalar o ModSecurity no Apache. O procedimento difere entre distribuições, mas a lógica é a mesma: instalar o pacote do módulo, habilitá-lo no servidor e reiniciar o serviço. Vamos começar pelo Ubuntu/Debian, onde o pacote libapache2-mod-security2 fornece o módulo dinâmico security2_module. Em seguida, cobrimos CentOS/RHEL/Rocky Linux, onde o pacote mod_security é disponibilizado pelo repositório EPEL.
No Ubuntu/Debian, execute os seguintes comandos em sequência. O primeiro atualiza o índice de pacotes. O segundo instala o módulo. O terceiro habilita o módulo no Apache. O quarto reinicia o serviço. Por fim, verificamos se o módulo está carregado corretamente:
# Atualiza a lista de pacotes disponíveis
sudo apt update
# Instala o módulo ModSecurity para Apache
sudo apt install libapache2-mod-security2 -y
# Habilita o módulo security2 no Apache
sudo a2enmod security2
# Reinicia o Apache para carregar o novo módulo
sudo systemctl restart apache2
# Verifica se o módulo ModSecurity está carregado
sudo apachectl -M | grep securityNo comando a2enmod security2, a ferramenta a2enmod cria os links simbólicos necessários em /etc/apache2/mods-enabled/ para que o Apache carregue o módulo. A opção -M do apachectl exibe a lista de módulos carregados, e o filtro grep security confirma que o módulo security2_module está ativo. A saída esperada deve ser semelhante a esta:
security2_module (shared)No CentOS/RHEL/Rocky Linux, o processo é igualmente simples. Primeiro, instale o repositório EPEL caso ainda não esteja disponível. Depois, instale o pacote mod_security. O Apache no CentOS carrega automaticamente os módulos instalados via pacote, mas é importante reiniciar o serviço para aplicar a mudança. Execute:
# Instala o repositório EPEL (se ainda não estiver instalado)
sudo dnf install epel-release -y
# Instala o módulo ModSecurity para Apache
sudo dnf install mod_security -y
# Reinicia o Apache para carregar o módulo
sudo systemctl restart httpd
# Verifica se o módulo ModSecurity está carregado
sudo httpd -M | grep securityNo CentOS, o serviço Apache é chamado de httpd, e o comando de verificação é httpd -M. A saída esperada é a mesma, confirmando que o módulo security2_module foi carregado com sucesso. Essa diferença de nomenclatura é comum entre distribuições e é importante internalizá-la para evitar confusões em ambientes mistos.
security2_module (shared)Após a instalação, o ModSecurity está ativo, mas ainda não possui regras de detecção carregadas. Na próxima seção, vamos configurar o arquivo principal de parâmetros e ativar o OWASP Core Rule Set, que é o conjunto de regras que realmente fornece a inteligência de detecção de ataques.
Configuração Detalhada do ModSecurity no Apache
A configuração do ModSecurity no Apache é feita por meio de arquivos de texto que contêm diretivas SecRuleEngine, SecRequestBodyAccess, SecAuditEngine e outras. O arquivo principal geralmente é /etc/modsecurity/modsecurity.conf no Ubuntu/Debian e /etc/httpd/modsecurity.d/modsecurity.conf no CentOS/RHEL. Nesta seção, vou apresentar o conteúdo completo de uma configuração de exemplo, adequada para um ambiente de produção com detecção ativa.
No Ubuntu, o arquivo /etc/modsecurity/modsecurity.conf pode não existir por padrão após a instalação, dependendo da versão. Vamos criá-lo com o conteúdo abaixo, que define os parâmetros globais do motor. No CentOS, o arquivo padrão já vem com a maioria dessas diretivas comentadas, mas vamos sobrescrevê-lo ou editá-lo para garantir consistência. Use o editor de sua preferência:
# /etc/modsecurity/modsecurity.conf
# Configuração global do ModSecurity
# Habilita o motor de regras (On = bloqueio; DetectionOnly = apenas detecta e loga)
SecRuleEngine On
# Habilita o acesso ao corpo da requisição (necessário para regras POST)
SecRequestBodyAccess On
# Limite máximo do corpo da requisição em bytes (128 MB)
SecRequestBodyLimit 134217728
# Limite para dados de formulário sem upload de arquivo
SecRequestBodyNoFilesLimit 131072
# Habilita o acesso ao corpo da resposta (para detecção de vazamento de dados)
SecResponseBodyAccess On
# Limite máximo do corpo da resposta em bytes
SecResponseBodyLimit 524288
# MIME types que serão inspecionados na resposta
SecResponseBodyMimeType text/plain text/html
# Limite de tentativas de match na engine PCRE
SecPcreMatchLimit 1500
SecPcreMatchLimitRecursion 1500
# Caminho do log de debug (apenas para troubleshooting; nível 0 desativa)
SecDebugLog /var/log/modsec_debug.log
SecDebugLogLevel 0
# Auditoria: registra apenas transações relevantes (bloqueios e erros 5xx/4xx)
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
# Partes do log de auditoria a serem gravadas
SecAuditLogParts ABIJDEFHZ
# Tipo de log de auditoria
SecAuditLogType Serial
# Caminho do log de auditoria do ModSecurity
SecAuditLog /var/log/modsec_audit.log
# Separador de argumentos (padrão e comercial)
SecArgumentSeparator &
# Formato de cookie (0 = padrão)
SecCookieFormat 0
# Engine de status (utilizado para monitoramento remoto; desativado por padrão)
SecStatusEngine Off
# Diretório temporário para uploads interceptados
SecUploadDir /tmp
# Mantém arquivos interceptados? Off = descarta após análise
SecUploadKeepFiles OffVamos analisar as diretivas mais críticas. SecRuleEngine On ativa o modo de bloqueio: quando uma regra determina ação de negação, a requisição é bloqueada com código 403 ou similar. Para ambientes de teste, você pode usar SecRuleEngine DetectionOnly, que registra os ataques sem bloqueá-los — essencial na fase inicial de tuning para evitar interrupções indevidas. SecRequestBodyAccess On permite que o motor leia e analise o corpo das requisições, o que é necessário para detectar SQL injection e XSS em formulários.
As diretivas de limite, como SecRequestBodyLimit e SecResponseBodyLimit, controlam o quanto o motor inspeciona. Valores muito altos podem causar alto consumo de memória; valores muito baixos podem deixar ataques passarem em requisições grandes. Os valores mostrados são seguros para a maioria das aplicações. SecAuditEngine RelevantOnly faz com que o log de auditoria registre apenas transações com status relevante (ataques e erros), evitando crescimento descontrolado do arquivo.
Depois de criar o arquivo, precisamos garantir que o Apache o inclua na configuração. No Ubuntu/Debian, o arquivo /etc/apache2/mods-enabled/security2.conf já vem com uma diretiva para incluir arquivos .conf do diretório /etc/modsecurity/. Se não existir, crie-o com o seguinte conteúdo:
# /etc/apache2/mods-enabled/security2.conf
<IfModule security2_module>
IncludeOptional /etc/modsecurity/*.conf
</IfModule>No CentOS/RHEL/Rocky, o pacote cria automaticamente o arquivo /etc/httpd/conf.d/mod_security.conf, que já contém os includes necessários. De qualquer forma, verifique se ele contém as linhas abaixo e, se não contiver, adicione-as:
# /etc/httpd/conf.d/mod_security.conf
LoadModule security2_module modules/mod_security2.so
<IfModule mod_security2.c>
IncludeOptional /etc/httpd/modsecurity.d/*.conf
IncludeOptional /etc/httpd/modsecurity.d/activated_rules/*.conf
</IfModule>No próximo passo, vamos clonar e ativar o OWASP Core Rule Set, que adicionará centenas de regras especializadas para detecção de ataques conhecidos. Essa etapa é indispensável para que o ModSecurity realmente proteja sua aplicação web.
Ativando o OWASP Core Rule Set (CRS) no ModSecurity
O OWASP Core Rule Set (CRS) é um conjunto abrangente de regras para o ModSecurity, mantido pela comunidade e amplamente adotado em produções de todos os tamanhos. Ele contém regras para SQL injection, XSS, inclusão de arquivos, execução remota de código, entre outras classes de ataques. Nesta seção, vamos instalar o CRS a partir do repositório oficial, configurar o arquivo crs-setup.conf e ativar as regras no Apache.
Primeiro, instale o git e clone o repositório do OWASP CRS em um diretório temporário. Depois, copie os arquivos necessários para o diretório de configuração do ModSecurity. Os passos abaixo são válidos tanto para Ubuntu quanto para CentOS, com pequenas adaptações de caminho:
# Instala o git (se ainda não estiver instalado)
sudo apt install git -y # Ubuntu/Debian
# ou
sudo dnf install git -y # CentOS/RHEL/Rocky
# Clona o repositório do OWASP CRS em /tmp
cd /tmp
git clone https://github.com/coreruleset/coreruleset.git
cd corereset
# Cria o diretório de regras no modsecurity
sudo mkdir -p /etc/modsecurity/crs
# Copia o arquivo de configuração do CRS
sudo cp crs-setup.conf.example /etc/modsecurity/crs/crs-setup.conf
# Copia todas as regras do CRS
sudo cp -r rules /etc/modsecurity/crs/Observe o comando cp -r rules /etc/modsecurity/crs/: a opção -r copia o diretório rules recursivamente para dentro de /etc/modsecurity/crs/, preservando todos os arquivos .conf de regras. O arquivo crs-setup.conf.example é um modelo que contém parâmetros de tuning globais, como o limiar de anomalia e a ativação de parâmetros de detecção. Ele precisa ser renomeado para crs-setup.conf para ser lido pelo motor. A opção -p no mkdir cria o diretório e todos os pais necessários.
Agora, precisamos incluir o CRS na configuração do Apache. No Ubuntu/Debian, edite o arquivo /etc/apache2/mods-enabled/security2.conf e adicione as linhas de include após a linha existente. O conteúdo final deve ficar assim:
# /etc/apache2/mods-enabled/security2.conf
<IfModule security2_module>
Include /etc/modsecurity/modsecurity.conf
Include /etc/modsecurity/crs/crs-setup.conf
IncludeOptional /etc/modsecurity/crs/rules/*.conf
IncludeOptional /etc/modsecurity/custom-rules.conf
</IfModule>No CentOS/RHEL/Rocky, crie o arquivo /etc/httpd/modsecurity.d/activated_rules/crs.conf com as mesmas linhas de include (ajustando o caminho se necessário). A princípio, o comando é:
# Cria o arquivo de include do CRS no CentOS/RHEL/Rocky
sudo bash -c 'cat > /etc/httpd/modsecurity.d/activated_rules/crs.conf << EOF
Include /etc/modsecurity/crs/crs-setup.conf
IncludeOptional /etc/modsecurity/crs/rules/*.conf
IncludeOptional /etc/modsecurity/custom-rules.conf
EOF'Antes de reiniciar, é altamente recomendável testar a sintaxe da configuração do Apache. O comando apachectl configtest ou httpd -t verifica se não há erros de sintaxe que impeçam o serviço de iniciar. Se não houver erros, reiniciamos o Apache:
# Testa a sintaxe da configuração do Apache
sudo apachectl configtest # Ubuntu/Debian
sudo httpd -t # CentOS/RHEL/Rocky
# Reinicia o serviço para aplicar as novas regras
sudo systemctl restart apache2 # Ubuntu/Debian
sudo systemctl restart httpd # CentOS/RHEL/RockyA saída esperada do teste de sintaxe deve ser Syntax OK. Se houver erros, o Apache não reiniciará, e você verá mensagens detalhadas no terminal ou nos logs. Após reiniciar com sucesso, o ModSecurity estará ativo com o OWASP CRS carregado. Agora, vamos criar regras personalizadas para demonstrar como estender a proteção para necessidades específicas da sua aplicação.
Criando Regras Personalizadas no ModSecurity
Embora o OWASP CRS cubra uma vasta gama de ataques genéricos, aplicações reais frequentemente possuem comportamentos específicos que exigem proteção adicional. Por exemplo, você pode querer bloquear o acesso a arquivos sensíveis como .env, restringir métodos HTTP incomuns ou proteger um endpoint administrativo contra força bruta. Nesta seção, você aprenderá a criar regras customizadas no ModSecurity, entendendo a sintaxe das diretivas SecRule e as fases de processamento.
As regras do ModSecurity seguem a sintaxe geral: SecRule VARIÁVEL OPERADOR AÇÕES. A variável indica o que será inspecionado (por exemplo, REQUEST_FILENAME para o caminho da URL). O operador define o critério de comparação (como @rx para expressões regulares ou @eq para igualdade). As ações determinam o que fazer quando a regra corresponde, como deny, log ou status:403. Cada regra deve ter um id único e, preferencialmente, uma msg descritiva para facilitar a análise de logs.
Vamos criar o arquivo /etc/modsecurity/custom-rules.conf com cinco regras práticas, abrangendo proteção de arquivos sensíveis, bloqueio de métodos perigosos, prevenção de SQL injection em parâmetro específico e limitação de tentativas de login. O conteúdo completo é o seguinte:
# /etc/modsecurity/custom-rules.conf
# Regras personalizadas do ModSecurity
# Bloqueia acesso a arquivos .env ou .git (protege segredos e repositório)
SecRule REQUEST_FILENAME "\.(env|git)" \
"id:100001,phase:2,deny,status:403,log,\
msg:'Acesso a arquivo sensível bloqueado'"
# Bloqueia métodos HTTP perigosos (TRACE, CONNECT, DEBUG)
SecRule REQUEST_METHOD "^(TRACE|CONNECT|DEBUG)$" \
"id:100002,phase:1,deny,status:403,log,\
msg:'Método HTTP não permitido bloqueado'"
# Bloqueia SQL injection no parâmetro 'query' (exemplo de proteção direcionada)
SecRule ARGS:query "@detectSQLi" \
"id:100003,phase:2,deny,status:403,log,\
msg:'Tentativa de SQL injection no parâmetro query'"
# Bloqueia acesso a qualquer URL que contenha /admin sem token válido (exemplo conceitual)
# Nota: substitua 'SECRET_TOKEN' pela implementação real da sua aplicação
SecRule REQUEST_URI "^/admin" \
"id:100004,phase:1,deny,status:403,log,\
chain"
SecRule &ARGS:token "@eq 0" "id:100005,deny,status:403,log,\
msg:'Acesso a /admin sem token de autorização'"
# Limita requisições repetidas ao endpoint /login (proteção básica contra força bruta)
SecAction "id:100006,phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},setvar:ip.login_count=+1,expirevar:ip.login_count=60"
SecRule REQUEST_URI "^/login" "id:100007,phase:1,chain,deny,status:403,log,\
msg:'Possível tentativa de força bruta'"
SecRule ip:login_count "@gt 10" "id:100008"A primeira regra usa a variável REQUEST_FILENAME e o operador de expressão regular implícito (quando não especificado, @rx é assumido) para detectar acesso a arquivos com extensão .env ou .git. Quando a condição é satisfeita, a ação deny bloqueia a requisição e retorna o status 403 Forbidden. A ação log garante que o evento seja registrado no log de auditoria. A diretiva msg fornece uma descrição legível que aparecerá nos logs.
A terceira regra demonstra o uso do operador especial @detectSQLi, que utiliza a biblioteca libinjection para detectar padrões de SQL injection de forma mais robusta que expressões regulares simples. Isso reduz falsos positivos e aumenta a precisão. A quarta e quinta regras mostram o encadeamento com chain, que exige que ambas as condições sejam verdadeiras para que a ação final seja executada — útil para lógicas condicionais complexas.
Após criar o arquivo, teste a sintaxe e reinicie o Apache novamente. O ModSecurity lerá automaticamente o arquivo custom-rules.conf se o include estiver configurado corretamente, como fizemos na seção anterior. Em ambientes de produção, recomendamos manter as regras customizadas em um arquivo separado para facilitar o gerenciamento e o versionamento das regras.
Instalação e Configuração do ModSecurity no Nginx
O Nginx não possui suporte nativo ao ModSecurity como o Apache, mas é possível integrá-lo por meio do módulo dinâmico libnginx-mod-security, que utiliza a biblioteca standalone libmodsecurity3. Essa arquitetura permite que o Nginx carregue o motor do ModSecurity durante a fase de processamento de requisições, com mínimo impacto em performance. Nesta seção, vamos configurar o ModSecurity no Ubuntu/Debian usando o pacote libnginx-mod-security, que já está disponível nos repositórios oficiais.
No Ubuntu, instale o pacote nginx (se ainda não estiver presente) e o módulo libnginx-mod-security. Em seguida, ative o carregamento do módulo no Nginx e configure as diretivas específicas. Execute os comandos:
# Instala o Nginx e o módulo ModSecurity
sudo apt update
sudo apt install nginx libnginx-mod-security -y
# Cria o arquivo de carregamento do módulo dinâmico
sudo bash -c 'echo "load_module modules/ngx_http_modsecurity_module.so;" > /etc/nginx/modules-enabled/mod-security.conf'
# Verifica se o módulo foi carregado corretamente
sudo nginx -T 2>&1 | grep modsecurityO comando nginx -T exibe a configuração completa efetiva, incluindo os módulos carregados. A opção 2>&1 redireciona a saída de erro para stdout, permitindo que o filtro grep capture mensagens relevantes. A saída esperada deve conter algo como load_module modules/ngx_http_modsecurity_module.so; ou indicar que o módulo foi carregado. Se você preferir, pode usar nginx -V para ver detalhes da compilação.
load_module modules/ngx_http_modsecurity_module.so;Em seguida, crie ou edite o arquivo de configuração principal do Nginx para incluir as diretivas do ModSecurity. No bloco server (ou location) onde deseja aplicar o WAF, adicione as diretivas modsecurity on; e modsecurity_rules_file /etc/modsecurity/modsecurity.conf;. O arquivo /etc/modsecurity/modsecurity.conf deve conter a mesma configuração global que usamos no Apache, ajustando apenas o caminho dos logs se necessário. Veja um exemplo de configuração de site:
# /etc/nginx/sites-available/default
server {
listen 80;
server_name example.com;
# Ativa o ModSecurity para este site
modsecurity on;
modsecurity_rules_file /etc/modsecurity/modsecurity.conf;
location / {
root /var/www/html;
index index.html index.htm;
}
error_page 403 /403.html;
}Após editar o arquivo, teste a configuração do Nginx com nginx -t e reinicie o serviço. O comando nginx -t verifica a sintaxe dos arquivos de configuração; se houver erros, o Nginx não reiniciará. A reinicialização é necessária para que as novas diretivas tenham efeito:
# Testa a configuração do Nginx
sudo nginx -t
# Reinicia o Nginx para aplicar as mudanças
sudo systemctl restart nginxNo CentOS/RHEL/Rocky Linux, o pacote libnginx-mod-security pode não estar disponível nos repositórios padrão. Nesses casos, é necessário compilar o ModSecurity standalone (libmodsecurity3) e o conector para Nginx a partir do código-fonte. Esse processo é mais avançado e foge do escopo desta aula, mas você encontrará a documentação oficial no repositório do projeto. Em nossos projetos na JRT Technology Solutions, utilizamos essa abordagem para ambientes CentOS quando não há pacote disponível, garantindo que todas as dependências sejam compiladas com as opções de segurança adequ
Quer aprender na prática com especialistas?
A JRT Technology Solutions oferece treinamentos e implementação de Segurança Linux para equipes corporativas.
