Quantcast

Como instalar o Apache com ModSecurity no Ubuntu 22.04 LTS

ModSecurity, frequentemente referido como Modsec, é um firewall de aplicativo da web gratuito e de código aberto (WAF). O ModSecurity foi criado como um módulo para o servidor HTTP Apache. No entanto, desde seus primeiros dias, o WAF cresceu e agora cobre uma variedade de solicitações de protocolo de transferência de hipertexto e recursos de filtragem de resposta para várias plataformas, como Microsoft IIS, Nginx e Apache.

Como o WAF funciona, o mecanismo ModSecurity é implantado na frente do aplicativo da web, permitindo que o mecanismo varra as conexões HTTP de entrada e saída. ModSecurity é mais comumente usado em conjunto com o Conjunto de regras básicas OWASP (CRS), um conjunto de regras de código aberto escrito na linguagem SecRules do ModSecurity e é altamente considerado no setor de segurança.

O conjunto de regras OWASP com ModSecurity pode ajudar quase instantaneamente a proteger seu servidor contra:

  • Agentes de usuários ruins
  • DDOS
  • Cross site scripting
  • injeção SQL
  • Seqüestro de sessão
  • Outras Ameaças

Durante o tutorial, você pode notar que ele está instalando a versão 2, e isso ocorre porque, diferentemente do Nginx, a versão beta do Apache para o conector Apache/Modsecurity foi abandonada e não funcionará efetivamente, portanto, é recomendável permanecer no construção original. As atualizações ainda estão sendo realizadas, portanto, a compilação da versão dois não foi abandonada.

No tutorial a seguir, você aprenderá como instalar o ModSecurity 3 & OWASP Core Rule Set com Apache no Ubuntu 22.04 LTS Jammy Jellyfish com configurações de exemplo.

OWASP tem três versões para instalar; Testei o 3.3.2 e o 4.0.0 RC1, qual funcionou.

Atualize o Ubuntu

Primeiro, atualize seu sistema para garantir que todos os pacotes existentes estejam atualizados.

sudo apt update && sudo apt upgrade -y

Instale o Apache mais recente

Primeiro, é aconselhável remover todas as instalações existentes do Apache e instalar a versão mais recente, que usaremos o Ondrey Surfury PPA.

Remover a instalação existente do Apache

Pare o serviço atual se instalado com o comando a seguir.

sudo systemctl stop apache2

Agora remova a instalação existente do Apache da seguinte forma:

sudo apt-get purge apache2 -y && sudo apt autoremove apache2 -y

Adicionar Apache PPA mais recente

Agora que você removeu seu antigo serviço Apache, importe o PPA.

sudo add-apt-repository ppa:ondrej/apache2 -y

Após importar o repositório desejado, use o comando a seguir para atualizar sua lista de fontes do APT.

sudo apt update

Agora que você instalou o PPA e atualizou a lista de repositórios, instale o Apache com o seguinte comando.

sudo apt install apache2 -y

Instalar/habilitar o módulo ModSecurity Apache

O primeiro passo é instalar o módulo Apache incluído no repositório padrão do Ubuntu 22.04 com o seguinte comando.

sudo apt install libapache2-mod-security2

Uma vez instalado, habilite o módulo da seguinte forma.

sudo a2enmod security2

Certifique-se de reiniciar o serviço Apache2 para refletir o novo módulo e as alterações.

sudo systemctl restart apache2

Ativar módulo ModSecurity

As configurações do Apache ModSecurity podem ser encontradas em /etc/apache2/mods-enabled/security2.conf, que terá uma linha que contém o seguinte.

IncludeOptional /etc/modsecurity/*.conf

Exemplo:

Como instalar o Apache com ModSecurity no Ubuntu 22.04 LTS

O Apache carregará todos os * .conf arquivos do /etc/modsecurity/ diretório, mas você precisará renomear o recomendado pelo modsecurity.conf arquivo de configuração primeiro.

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

Em seguida, usando seu editor de texto favorito no Ubuntu, abra o modsecurity.conf arquivo da seguinte forma.

sudo nano /etc/modsecurity/modsecurity.conf

Por padrão, a configuração do ModSecurity tem o mecanismo de regras especificado como (Detecção somente), que em outras palavras, executa o ModSecurity e detecta todos os comportamentos maliciosos, mas não bloqueia ou proíbe ações e registra todas as transações HTTP que sinaliza. Isso só deve ser usado se você tiver muitos falsos positivos ou tiver aumentado as configurações de nível de segurança para um nível extremo e testando para ver se ocorrem falsos positivos.

No arquivo de configuração, altere esse comportamento para (em), encontrado na linha 7.

SecRuleEngine DetectionOnly

Altere a linha para habilitar o ModSecurity:

SecRuleEngine On

Exemplo:

Como instalar o Apache com ModSecurity no Ubuntu 22.04 LTS

Agora, você precisa localizar o seguinte SecAuditLogParts, que está localizado na linha 224.

# Log everything we know about a transaction.
SecAuditLogParts ABDEFHIJZ

Isso não está correto e precisa ser alterado. Modifique a linha para o seguinte:

SecAuditLogParts ABCEFHJKZ

Agora salve o arquivo usando (CTRL + O), então saia (CTRL + X).

Reinicie seu serviço Apache usando o comando systemctl para ativar as alterações.

sudo systemctl restart apache2

Instale o conjunto de regras básicas OWASP para ModSecurity

ModSecurity por si só não protege seu servidor web, e você precisa ter regras. Uma das regras mais famosas, respeitadas e conhecidas é o conjunto de regras OWASP CRS. As regras são as mais utilizadas entre os servidores web e outros WAFs, e a maioria dos outros sistemas similares baseiam a maioria de suas regras neste CRS. A instalação desse conjunto de regras fornecerá automaticamente uma ótima fonte de proteção contra a maioria das ameaças emergentes na Internet, detectando agentes mal-intencionados e bloqueando-os.

Verifique o Página de tag de lançamento do OWASP para ver quais são as últimas, pois o exemplo abaixo pode ter mudado no futuro.

Primeiro, crie o diretório que será o pai principal do OWASP.

sudo mkdir /etc/apache2/modsec/

Com o comando wget, baixar o Arquivo OWASP CRS 3.3.2, que a partir desta data é o mais recente estável, mas lembre-se de que há quatro dias, a versão de pré-lançamento caiu, então meu conselho é verificar o link algumas linhas acima para ver como são os lançamentos para o conjunto de regras principal.

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

Para aqueles que querem viver no limite, você pode baixar a compilação noturna. Use o nightly apenas se estiver preparado para continuar recompilando e verificando o CoreRuleSet Github com frequência para atualizações e tenha mais confiança em descobrir problemas. Tecnicamente, o noturno pode ser mais seguro, mas potencialmente pode criar problemas.

Para usuários iniciantes, use a versão estável e não use a versão abaixo.

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

No momento da criação do tutorial, o pré-lançamento v4.0.0-RC1 também está disponível, conforme mencionado anteriormente.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v4.0.0-rc1.zip

Instale o Descompacte o pacote se você não tiver isso instalado em seu servidor.

sudo apt install unzip -y

Agora descompacte o arquivo.

sudo unzip v3.3.2.zip -d /etc/apache2/modsec

Lembre-se, se você baixou a v4.0 ou a nightly, altere os comandos para refletir isso.

OWASP CRS vem com um arquivo de configuração de amostra que você precisa renomear. É melhor usar o comando CP e manter um backup para o futuro caso seja necessário reiniciar novamente.

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

Lembre-se de que o comando acima é apenas um exemplo, certifique-se de alterar /coreruleset-3.3.2/ com a versão exata do OWASP que você decidir.

Para habilitar as regras, abra o /etc/etc/apache2/mods-enabled/security2.conf do seguinte modo.

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

Uma vez dentro do arquivo novamente, adicione as seguintes duas linhas adicionais:

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

Lembre-se de que o comando acima é apenas um exemplo, certifique-se de alterar /coreruleset-3.3.2/ com a versão exata do OWASP que você decidir.

Além disso, apague a linha a seguir ou remova-a.

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

Exemplo:

Como instalar o Apache com ModSecurity no Ubuntu 22.04 LTS

Salve o arquivo (CTRL + O) e sair (CTRL + T).

Reinicie seu serviço Apache para ativar as alterações da seguinte maneira:

sudo systemctl restart apache2

Usando e entendendo o conjunto de regras principais do OWASP

OWASP CRS tem muitas opções, as configurações padrão, no entanto, fora da caixa, protegerão a maioria dos servidores imediatamente sem prejudicar seus visitantes reais e bons bots de SEO. Abaixo, algumas áreas serão abordadas para ajudar a explicar. A leitura adicional seria melhor para investigar todas as opções nos próprios arquivos de configuração, já que eles têm muitos dados de texto para explicar o que são.

Abra o seu CRS-setup.conf arquivo.

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

Observe que esta é a configuração da versão dev com itens adicionais em comparação com a versão 3.3.

A partir daqui, você pode modificar a maioria das configurações do OWASP CRS.

Pontuação OWASP CRS

Para dividir, o ModSecurity tem dois modos:

Modo de pontuação de anomalias

# -- [[ Anomaly Scoring Mode (default) ]] --
# In CRS3, anomaly mode is the default and recommended mode, since it gives the
# most accurate log information and offers the most flexibility in setting your
# blocking policies. It is also called "collaborative detection mode".
# In this mode, each matching rule increases an 'anomaly score'.
# At the conclusion of the inbound rules, and again at the conclusion of the
# outbound rules, the anomaly score is checked, and the blocking evaluation
# rules apply a disruptive action, by default returning an error 403.

Modo autossuficiente

# -- [[ Self-Contained Mode ]] --
# In this mode, rules apply an action instantly. This was the CRS2 default.
# It can lower resource usage, at the cost of less flexibility in blocking policy
# and less informative audit logs (only the first detected threat is logged).
# Rules inherit the disruptive action that you specify (i.e. deny, drop, etc).
# The first rule that matches will execute this action. In most cases this will
# cause evaluation to stop after the first rule has matched, similar to how many
# IDSs function.

A Pontuação de Anomalias é geralmente, para a maioria dos usuários, o melhor modo a ser usado.

Existem quatro níveis de paranóia:

  • Paranóia Nível 1 - Nível padrão e recomendado para a maioria dos usuários.
  • Paranóia Nível 2 - Somente usuários avançados.
  • Paranóia Nível 3 - Apenas usuários experientes.
  • Paranóia Nível 4 - Nem um pouco recomendado, exceto em circunstâncias excepcionais.
# -- [[ Paranoia Level Initialization ]] ---------------------------------------
#
# The Paranoia Level (PL) setting allows you to choose the desired level
# of rule checks that will add to your anomaly scores.
#
# With each paranoia level increase, the CRS enables additional rules
# giving you a higher level of security. However, higher paranoia levels
# also increase the possibility of blocking some legitimate traffic due to
# false alarms (also named false positives or FPs). If you use higher
# paranoia levels, it is likely that you will need to add some exclusion
# rules for certain requests and applications receiving complex input.
#
# - A paranoia level of 1 is default. In this level, most core rules
#   are enabled. PL1 is advised for beginners, installations
#   covering many different sites and applications, and for setups
#   with standard security requirements.
#   At PL1 you should face FPs rarely. If you encounter FPs, please
#   open an issue on the CRS GitHub site and don't forget to attach your
#   complete Audit Log record for the request with the issue.
# - Paranoia level 2 includes many extra rules, for instance enabling
#   many regexp-based SQL and XSS injection protections, and adding
#   extra keywords checked for code injections. PL2 is advised
#   for moderate to experienced users desiring more complete coverage
#   and for installations with elevated security requirements.
#   PL2 comes with some FPs which you need to handle.
# - Paranoia level 3 enables more rules and keyword lists, and tweaks
#   limits on special characters used. PL3 is aimed at users experienced
#   at the handling of FPs and at installations with a high security
#   requirement.
# - Paranoia level 4 further restricts special characters.
#   The highest level is advised for experienced users protecting
#   installations with very high security requirements. Running PL4 will
#   likely produce a very high number of FPs which have to be
#   treated before the site can go productive.
#
# All rules will log their PL to the audit log;
# example: [tag "paranoia-level/2"]. This allows you to deduct from the
# audit log how the WAF behavior is affected by paranoia level.
#
# It is important to also look into the variable
# tx.enforce_bodyproc_urlencoded (Enforce Body Processor URLENCODED)
# defined below. Enabling it closes a possible bypass of CRS.

Teste OWASP CRS em seu servidor

Para testar se OWASP CRS está funcionando em seu servidor, abra seu navegador de Internet e use o seguinte:

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

Você deve receber um Erro proibido 403. Se não, então uma etapa foi perdida.

Exemplo:

Como instalar o Apache com ModSecurity no Ubuntu 22.04 LTS

O problema mais comum está faltando para mudar Detecção somente para On, conforme abordado anteriormente no tutorial.

Lidando com Falsos Positivos e Exclusão de Regras Customizadas

Uma das tarefas muitas vezes intermináveis ​​é lidar com falsos positivos, ModSecurity e OWASP CRS fazem um ótimo trabalho juntos, mas custa seu tempo, mas, dada a proteção que você obtém, vale a pena. Para começar, nunca colocar o nível de paranóia no alto é a regra de ouro.

Uma boa regra prática é executar o conjunto de regras por algumas semanas a meses sem quase nenhum falso positivo, então aumentar, por exemplo, o nível de paranóia 1 para o nível de paranóia 2, para que você não seja inundado com uma tonelada simultaneamente.

Excluindo aplicativos conhecidos de falsos positivos

O Modsecurity, por padrão, pode colocar na lista de permissões ações do dia a dia que levam a falsos positivos como abaixo:

#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 habilitar, por exemplo, WordPress, phpBB e phpMyAdmin como você usa todos os três, descomente as linhas e deixar o (1) número intacto, altere os outros serviços que você não usa, por exemplo, Xenforo para (0) porque você não deseja colocar essas regras na lista de permissões.

Exemplo abaixo:

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

Você também pode modificar a sintaxe, o que seria mais limpo. Por exemplo:

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"

Como você pode ver, removidas são as opções não necessárias e adicionadas (“) no final do WordPress para sintaxe correta.

Excluindo regras antes do CRS

Para lidar com exclusões personalizadas, em primeiro lugar, você precisa alterar o nome do REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf arquivo com o comando cp como se segue:

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

Um ponto a ser lembrado ao criar regras de exclusão, cada uma deve ter id: e ser único, ou então quando você testar seu serviço Apache2, você receberá um erro.

Exemplo “Id: 1544, phase: 1, log, allow, ctl: ruleEngine = off”, a id 1544 não pode ser usada para uma segunda regra.

Por exemplo, alguns REQUEST_URI's irão gerar falsos positivos. O exemplo abaixo é dois com beacon de velocidade de página do Google e plug-in WMUDEV 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"

Como você pode ver, qualquer URL que comece com o caminho será permitido automaticamente.

Outra opção é colocar endereços IP na lista de permissões; algumas maneiras de fazer isso:

SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"
## or ###
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"

A @ipMatch pode ser usado mais extensivamente para sub-redes. Se você quiser negar uma alteração de sub-rede ou endereço IP, permita negar. Com um pouco de conhecimento, você também pode criar listas negras e brancas e configurá-las com fail2ban. As possibilidades muitas vezes podem ser infinitas.

Um último exemplo é desabilitar apenas as regras que acionam falsos positivos, não a lista de permissões de todo o caminho, como você viu no primeiro exemplo REQUEST_URI. No entanto, isso leva mais tempo e testes.

Por exemplo, se você deseja remover regras 941000 e 942999 a partir de sua / admin / área, pois continua acionando banimentos e bloqueios falsos para sua equipe, encontre em seu arquivo de logs de modsecurity o ID da regra e, em seguida, desative apenas esse ID com RemoveByID conforme o exemplo abaixo:

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

Exemplos podem ser encontrados no ModSecurity GIT página wiki.

Conjunto de regras WPRS do WordPress para ModSecurity

Outra opção para WordPress usuários é instalar e executar junto com seu conjunto de regras OWASP CRS, um projeto bem conhecido chamado conjunto de regras WPRS. Como isso é opcional e não é para todos, o tutorial não o abordará nesta seção.

No entanto, se você quiser instalar isso para proteção extra se usar o WordPress em seu servidor, visite nosso tutorial em Instalação do conjunto de regras ModSecurity (WPRS) do WordPress.

Crie o arquivo ModSecurity LogRotate.

Os logs do ModSecurity podem crescer demais, então você precisa configurar a rotação de logs, pois isso não é feito para você.

Primeiro, crie e abra seu arquivo de rotação do ModSecurity modsec.

sudo nano /etc/logrotate.d/modsec

Adicione o seguinte código:

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

Isso manterá os logs por 31 dias. Se você preferir ter menos, altere 31 para 7 dias, o equivalente a uma semana de registros. Você deve rodar diariamente para ModSecurity. Se você precisar revisar os arquivos de log, ter um arquivo semanal será um desastre para filtrar, dado o tamanho dele.

Comentários e Conclusão

No geral, a implantação do ModSecurity em seu servidor fornecerá proteção instantânea. No entanto, paciência, tempo e dedicação ao aprendizado serão um ótimo recurso. A última coisa que você quer é bloquear bots de SEO ou, mais importante, usuários reais que podem ser clientes em potencial.



Siga LinuxCapable.com!

Gosta de receber atualizações automáticas? Siga-nos em uma de nossas redes sociais!