Como instalar o ModSecurity 2 com Apache no Debian 12 ou 11

O ModSecurity 2 é um firewall de aplicativo web (WAF) essencial para proteger servidores HTTP Apache, oferecendo monitoramento em tempo real e filtragem baseada em regras. Instalado em um servidor Linux Debian 12 ou 11, o ModSecurity ajuda a evitar injeções de SQL, cross-site scripting (XSS) e outros ataques. O Digitalwave ModSecurity Repository simplifica a instalação, garantindo que você esteja usando a versão estável mais recente.

Para aumentar a segurança, o OWASP Core Rule Set (CRS) fornece regras pré-configuradas visando vulnerabilidades comuns. Configurá-lo permite que os administradores fortaleçam as defesas com configuração manual mínima. Este guia mostrará como instalar o ModSecurity 2 no Debian usando o repositório Digitalwave e configurar o OWASP CRS para proteção ideal.

Atualizar pacotes do sistema Debian para instalação do ModSecurity 2

Nosso primeiro passo é garantir que nosso sistema Debian esteja atualizado. Fazer isso mantém todos os pacotes existentes atualizados, garante desempenho ideal e minimiza riscos de segurança. Faça isso executando o seguinte comando:

sudo apt update && sudo apt upgrade

Após atualizar seu sistema, verifique se o Apache está instalado. Se não, use o seguinte comando para instalá-lo:

sudo apt install apache2

Importar ModSecurity Módulo PPA

Configurando o repositório necessário

A próxima tarefa em nossa lista é instalar o ModSecurity Apache Module. A versão disponível nos repositórios padrão do Debian pode não ser a mais recente, e usá-la pode levar a erros imediatos. Em vez disso, importaremos um repositório de terceiros para instalar o mais recente ModSecurity Module para Apache. Este repositório de terceiros, mantido pela Digitalwave, é conhecido por seus binários estáveis.

Comece instalando um conjunto de pacotes necessários:

sudo apt install apt-transport-https lsb-release ca-certificates curl -y

Em seguida, procedemos à importação do repositório PPA do módulo ModSecurity 2 Chave GPG:

curl -fsSL https://modsecurity.digitalwave.hu/archive.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/digitalwave-modsecurity.gpg > /dev/null

Após adquirir a chave GPG, adicione o repositório ao seu sistema:

echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list
echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc)-backports main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list

Priorizando o novo repositório PPA do módulo Apache

Com o repositório instalado, agora é necessário ajustar a política APT para priorizar este repositório para pacotes específicos relacionados ao ModSecurity. O comando a seguir realiza isso:

cat << EOF | sudo tee -a /etc/apt/preferences.d/99modsecurity
Package: *nginx*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libapache2-mod-security2*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *modsecurity-crs*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libmodsecurity*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
EOF

Em seguida, execute uma atualização do APT para refletir a fonte recém-importada:

sudo apt update

Além disso, para confirmar as preferências, você pode confirmar esta alteração de política com o seguinte:

sudo apt-cache policy libapache2-mod-security2 modsecurity-crs libmodsecurity3

Instalar o módulo ModSecurity 2

Agora que o repositório está pronto, prossiga com a instalação do módulo libapache2-mod-security2:

sudo apt install libapache2-mod-security2

Após a instalação, o módulo deve ser habilitado. Use o comando a seguir para fazer isso:

sudo a2enmod security2

Reiniciando o serviço Apache

Por fim, reiniciamos o serviço Apache para garantir que todas as alterações tenham efeito e que o módulo ModSecurity recém-adicionado esteja corretamente integrado:

sudo nano /etc/apache2/mods-enabled/security2.conf

Habilitar o módulo ModSecurity 2 no Apache HTTP

Acessando o arquivo de configuração do ModSecurity

O arquivo de configuração para Apache ModSecurity pode ser encontrado em /etc/apache2/mods-enabled/security2.conf. Acesse esse arquivo usando o editor de texto nano (ou seu editor de texto preferido) com o seguinte comando:

sudo nano /etc/apache2/mods-enabled/security2.conf

Procure a linha que diz:

IncludeOptional /etc/modsecurity/*.conf

Certifique-se de que esta linha não esteja comentada, pois ela inclui outros arquivos de configuração necessários do diretório /etc/modsecurity. Ela deve estar descomentada por padrão.

Modificando a configuração do ModSecurity 2

Precisamos renomear o arquivo de configuração modsecurity.conf-recommended para modsecurity.conf para torná-lo ativo. Isso pode ser feito com o seguinte comando:

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Agora, vamos abrir este arquivo de configuração recém-nomeado:

sudo nano /etc/modsecurity/modsecurity.conf

O mecanismo de regras do ModSecurity é definido como DetectionOnly por padrão neste arquivo. Isso significa que ele identificará e registrará comportamento potencialmente malicioso sem bloqueá-lo. Para alterar isso e habilitar os recursos de bloqueio do ModSecurity, localize a linha SecRuleEngine (em torno da linha 7) e substitua DetectionOnly por On.

De:

SecRuleEngine DetectionOnly

Para:

SecRuleEngine On

Ajustando as configurações de log para Apache

Mais abaixo no arquivo de configuração, você encontrará a linha SecAuditLogParts (por volta da linha 224). A configuração padrão para essa linha não está muito correta; ela precisa ser ajustada para registrar todas as informações de transação com precisão.

Mudar:

SecAuditLogParts ABDEFHIJZ

Para:

SecAuditLogParts ABCEFHJKZ

Com essas modificações em vigor, salve suas alterações e saia do editor.

Reiniciando o Apache para aplicar as alterações

Nossa etapa final neste processo é reiniciar o serviço Apache para que nossas alterações na configuração do ModSecurity entrem em vigor. Isso é feito usando o seguinte comando:

sudo systemctl restart apache2

Instalar o conjunto de regras principais do OWASP para ModSecurity2

O ModSecurity sozinho não protege seu servidor web. Ele requer um conjunto de regras para identificar ameaças potenciais e bloquear atividades maliciosas. O OWASP (Open Web Application Security Project) Core Rule Set (CRS) é um conjunto de regras altamente considerado usado por vários servidores web e Web Application Firewalls (WAFs). A implantação deste conjunto de regras fornece ao seu servidor proteção robusta contra uma série de ameaças emergentes na internet.

Antes de prosseguir, é essencial verificar se você tem a versão mais recente do OWASP CRS visitando o Página de tags de lançamento do OWASP. Esta etapa garante que você baixe e instale as medidas de segurança mais atualizadas para seu servidor.

Criando o diretório pai para OWASP CRS

Primeiro, vamos criar o diretório pai principal para o OWASP usando o comando mkdir:

sudo mkdir /etc/apache2/modsec/

Baixe o arquivo OWASP CRS no Debian

Em seguida, usaremos o comando wget para buscar o arquivo OWASP CRS 3.3.4, que é a versão estável no momento da escrita. Lembre-se de que você deve verificar a versão usando o link mencionado anteriormente.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.4.zip

A compilação noturna pode oferecer medidas de segurança mais atualizadas, mas pode causar problemas devido ao seu status de desenvolvimento. Para novos usuários, é aconselhável usar a versão estável para evitar possíveis complicações.

Observação: você deve verificar constantemente se há atualizações; as regras estáveis ​​não mudam semanalmente, mas a cada trimestre ou a menos que uma atualização urgente seja necessária.

Extraindo o arquivo

Com o arquivo baixado, podemos extraí-lo para o diretório que criamos anteriormente:

sudo tar xvf v3.3.4.tar.gz -C /etc/apache2/modsec

Lembre-se de alterar os comandos com base na versão do OWASP CRS que você baixou.

Configurando o conjunto de regras

O OWASP CRS tem um arquivo de configuração de exemplo que você deve renomear, mantendo o original como backup. Você pode fazer isso usando o comando 'cp':

sudo cp /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf.example /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf

Observação: lembre-se de substituir /coreruleset-3.3.4/ pela versão exata do OWASP CRS que você escolheu.

Habilitando as regras

Para ativar as regras, abra o arquivo /etc/apache2/mods-enabled/security2.conf:

sudo apt install unzip -y

Em seguida, insira as duas linhas seguintes:

Include /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf
Include /etc/apache2/modsec/coreruleset-3.3.4/rules/*.conf

Observação: novamente, certifique-se de substituir /coreruleset-3.3.4/ pela versão exata do OWASP CRS que você selecionou, pois o coreruleset que você baixará provavelmente será mais recente que o exemplo do guia.

Além disso, comente ou remova a seguinte linha:

IncludeOptional /usr/share/modsecurity-crs/*.load

Uma vez feito isso, salve e saia do arquivo:

Reiniciando o Apache para aplicar as alterações

O último passo é reiniciar o serviço Apache para garantir que as alterações entrem em vigor:

sudo systemctl restart apache2

Introdução ao conjunto de regras principais do OWASP e ao ModSecurity 2

O OWASP Core Rule Set (CRS) é uma ferramenta abrangente com inúmeras opções personalizáveis. Sua configuração padrão fornece melhorias de segurança imediatas para a maioria dos servidores sem impactar visitantes genuínos ou bots de Search Engine Optimization (SEO). Discutiremos alguns aspectos significativos do CRS nesta seção, mas explorar os arquivos de configuração para uma compreensão completa de todas as opções disponíveis é sempre benéfico.

Ajustando a configuração do CRS

Começamos abrindo o arquivo crs-setup.conf, onde a maioria das configurações do CRS podem ser alteradas:

sudo nano /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf

Compreendendo o sistema de pontuação CRS

O ModSecurity opera em dois modos distintos:

• Modo de Pontuação de Anomalias: Recomendado para a maioria dos usuários, este modo atribui uma 'pontuação de anomalias' cada vez que uma regra corresponde. Após processar as regras de entrada e saída, a pontuação de anomalias é verificada e uma ação disruptiva é acionada, se necessário. Esta ação geralmente assume a forma de um erro 403. Este modo fornece informações de log precisas e oferece maior flexibilidade na configuração de políticas de bloqueio.
• Modo Autocontido: Neste modo, uma ação é aplicada instantaneamente sempre que uma regra é correspondida. Embora possa reduzir o uso de recursos, ele oferece menos flexibilidade e produz logs de auditoria menos informativos. O processo de correspondência de regras para quando a primeira regra é atendida e a ação especificada é executada.

Compreendendo os níveis de paranoia

O OWASP CRS define quatro níveis de paranoia:

• Nível de paranoia 1: o nível padrão é adequado para a maioria dos usuários.
• Paranoia Nível 2: Para usuários avançados.
• Paranoia Nível 3: Para usuários experientes.
• Paranoia Nível 4: Aconselhável somente em circunstâncias extraordinárias.

Níveis mais altos de paranoia permitem regras adicionais, aumentam a segurança e aumentam a probabilidade de bloquear tráfego legítimo devido a falsos positivos. Escolher um nível de paranoia que se alinhe com sua expertise e necessidades de segurança é essencial.

Testando OWASP CRS em seu servidor

Para garantir que o OWASP CRS esteja operando corretamente em seu servidor, use seu navegador de internet para acessar a seguinte URL. Lembre-se de substituir “seudominio.com” pelo seu domínio real:

https://www.yourdomain.com/index.html?exec=/bin/bash

Se você receber um erro 403 Forbidden, o OWASP CRS funcionará conforme o esperado. Se não, pode haver um passo em falso no processo de configuração que requer sua atenção; o problema mais comum pode ser esquecer de alterar DetectionOnly para On ou algo semelhante.

Abordar falsos positivos e regras de exclusão personalizadas

Gerenciar falsos positivos com o ModSecurity e o OWASP Core Rule Set (CRS) pode ser uma tarefa contínua. No entanto, a defesa robusta que esses sistemas oferecem contra uma ampla gama de ameaças torna esse esforço essencial. Para minimizar falsos positivos inicialmente, é aconselhável definir um nível baixo de paranoia.

Ao executar o conjunto de regras em um nível de paranoia mais baixo por várias semanas ou até meses, você pode reduzir a probabilidade de um número esmagador de falsos positivos. Essa abordagem dá a você tempo para se familiarizar com os alertas e as respostas apropriadas antes de aumentar gradualmente o nível de paranoia para uma segurança mais rigorosa.

Gerenciando falsos positivos em aplicativos conhecidos no Debian com OWASP, ModSecurity 2

O ModSecurity inclui a capacidade de colocar na lista de permissões certas ações que podem disparar falsos positivos involuntariamente. Por exemplo:

#SecAction \
# "id:900130,\
#  phase:1,\
#  nolog,\
#  pass,\
#  t:none,\
#  setvar:tx.crs_exclusions_cpanel=1,\
#  setvar:tx.crs_exclusions_dokuwiki=1,\
#  setvar:tx.crs_exclusions_drupal=1,\
#  setvar:tx.crs_exclusions_nextcloud=1,\
#  setvar:tx.crs_exclusions_phpbb=1,\
#  setvar:tx.crs_exclusions_phpmyadmin=1,\
#  setvar:tx.crs_exclusions_wordpress=1,\
#  setvar:tx.crs_exclusions_xenforo=1"

Para ativar a lista de permissões para aplicativos como WordPress, phpBB e phpMyAdmin, descomente as respectivas linhas e mantenha o valor (1). Para evitar a lista de permissões de serviços que não estão em uso, ajuste o valor para (0).

A configuração atualizada poderia ter a seguinte aparência:

SecAction \
 "id:900130,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_exclusions_phpbb=1,\
  setvar:tx.crs_exclusions_phpmyadmin=1,\
  setvar:tx.crs_exclusions_wordpress=1"

Neste caso, opções estranhas foram removidas, deixando a sintaxe correta para as configurações necessárias.

Criando exclusões de regras antes da implementação do CRS

Para criar exclusões personalizadas, comece renomeando o arquivo “REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf” usando o seguinte comando:

sudo cp /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Lembre-se de que cada regra de exclusão deve ter um 'idnumber' exclusivo para evitar erros durante os testes do serviço Apache2.

Por exemplo, alguns “REQUEST_URIs” podem causar falsos positivos. O exemplo a seguir ilustra dois desses casos envolvendo o beacon do Google PageSpeed ​​e o plugin WPMU DEV para WordPress:

SecRule REQUEST_URI "@beginsWith /wp-load.php?wpmudev" "id:1544,phase:1,log,allow,ctl:ruleEngine=off"

SecRule REQUEST_URI "@beginsWith /ngx_pagespeed_beacon" "id:1554,phase:1,log,allow,ctl:ruleEngine=off"

Essas regras permitem automaticamente qualquer URL que comece com o caminho especificado.

Você também pode colocar endereços IP específicos na lista de permissões:

SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"

SecRule REMOTE_ADDR "@ipMatch 127.0.0.1/8, 195.151.0.0/24, 196.159.11.13" "phase:1,id:1313413,allow,ctl:ruleEngine=off"

Na primeira regra, um único endereço IP é incluído na lista de permissões, enquanto a segunda regra usa a diretiva '@ipMatch' para correspondência de sub-rede mais ampla. Para bloquear uma sub-rede ou endereço IP, basta substituir 'allow' por 'deny'. Essa flexibilidade permite que você crie listas negras e brancas detalhadas, que podem ser integradas ao Fail2Ban para uma estratégia de segurança aprimorada.

Desabilitando regras específicas no Debian com OWASP, ModSecurity 2

Em vez de colocar um caminho inteiro na lista de permissões, outra abordagem é desabilitar regras específicas que causam falsos positivos persistentes. Embora esse método exija mais testes, ele oferece benefícios de longo prazo.

Por exemplo, se as regras 941000 e 942999 na área “/admin/” acionarem falsos positivos para sua equipe, você pode localizar a ID da regra em seus logs do ModSecurity e desabilitar apenas essas IDs específicas usando o comando “RemoveByID”:

SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"

Monitoramento de Logs e Identificação de Padrões

O monitoramento contínuo de logs é essencial ao lidar com falsos positivos com Apache, ModSecurity e OWASP. Ele ajuda a identificar padrões que disparam falsos positivos, permitindo que você crie regras personalizadas para lidar com eles.

Por exemplo, se regras específicas causam consistentemente falsos positivos, você pode criar uma regra de exclusão para lidar com essas instâncias específicas. Essa abordagem personalizada garante um gerenciamento mais eficaz de falsos positivos.

Ao revisar regularmente seus logs e ajustar suas regras, você pode manter um ambiente mais seguro e eficiente para seus aplicativos.

Rotação de Log para ModSecurity 2

Devido à natureza dinâmica das transações da web, os logs do ModSecurity podem crescer rapidamente, tornando crucial o gerenciamento efetivo de logs. A rotação de logs é uma ferramenta útil para gerenciar esses logs, embora não seja configurada por padrão no ModSecurity. Esta seção o guiará pela configuração da rotação de logs especificamente para o ModSecurity.

Criando um arquivo de rotação do ModSecurity

Primeiro, você precisa criar um arquivo dedicado para a rotação de log do ModSecurity. Para fazer isso, use o seguinte comando para criar e abrir um novo arquivo chamado modsec:

sudo nano /etc/logrotate.d/modsec

Configurando o arquivo de rotação

No arquivo de configuração ModSecurity (modsec) recém-criado, adicione o seguinte:

/var/log/modsec_audit.log
{
        rotate 31
        daily
        missingok
        compress
        delaycompress
        notifempty
}

Esta configuração retém logs por 31 dias, mas você pode modificar o número para atender às suas necessidades. Por exemplo, alterá-lo para 'rotate 7' manterá uma semana de logs.

A diretiva 'daily' garante que os logs sejam rotacionados todos os dias, enquanto 'compress' economiza espaço compactando logs antigos. A opção 'delaycompress' atrasa a compactação até o segundo ciclo de rotação, e 'missingok' previne erros se o arquivo de log estiver ausente. Além disso, 'notifempty' garante que arquivos de log vazios não sejam rotacionados.

Dica: A rotação diária de logs é aconselhável para evitar lidar com arquivos de log muito grandes, o que pode tornar a análise mais demorada.

Conclusão

Agora você instalou o ModSecurity 2 no seu servidor Debian 12 ou 11 usando o repositório Digitalwave e configurou o OWASP Core Rule Set. Com essas ferramentas em vigor, seu servidor está equipado para bloquear muitas ameaças comuns de aplicativos da web.

Lembre-se de atualizar regularmente o CRS e monitorar quaisquer falsos positivos ou vulnerabilidades perdidas. Testes e ajustes consistentes são essenciais para manter uma configuração de segurança robusta.