Guia de proteção e segurança do servidor Web Apache

Um guia prático para proteger e fortalecer o Apache HTTP Server.

O Servidor Web é uma parte crucial dos aplicativos baseados na Web. O Apache Web Server é frequentemente colocado na borda da rede, tornando-se um dos serviços mais vulneráveis ​​a ataques.

A configuração padrão fornece muitas informações confidenciais que podem ajudar o hacker a se preparar para um ataque aos aplicativos. A maioria dos ataques a aplicativos da Web são por meio de ataques XSS, Info Leakage, Gerenciamento de Sessão e SQL Injection, devido a códigos de programação fracos e falha na higienização da infraestrutura de aplicativos da Web.

Uma pesquisa interessante da Positive Technologies revela que 52% dos aplicativos verificados apresentavam altas vulnerabilidades.

Neste artigo, falarei sobre algumas das melhores práticas para proteger o servidor Apache HTTP na plataforma Linux.

A seguir são testados na versão Apache 2.4.x.

• Isso pressupõe que você instalou o Apache na plataforma UNIX. Caso contrário, você pode acessar o guia de instalação.
• Chamarei o diretório de instalação do Apache /opt/apache como $Web_Server ao longo deste guia.
• É aconselhável fazer um backup do arquivo de configuração existente antes de qualquer modificação.

Público

Isso é projetado para Administrador de Middleware, Suporte a Aplicativos, Analista de Sistemas ou qualquer pessoa que trabalhe ou esteja ansiosa para aprender as diretrizes de Proteção e Segurança.

Conhecimento razoável do comando Apache Web Server e UNIX é obrigatório.

Notas

Você precisa de alguma ferramenta para examinar os cabeçalhos HTTP para algumas verificações de implementação. Existem duas maneiras de fazer isso.

1. Use as ferramentas de desenvolvedor incorporadas ao navegador para inspecionar os cabeçalhos HTTP. Normalmente, está na guia Rede
2. Use a ferramenta de verificação de cabeçalho de resposta HTTP online

Remover banner de versão do servidor

Eu diria que esta é uma das primeiras coisas a considerar, pois você não quer expor qual versão do servidor web está usando. Expor a versão significa que você está ajudando o hacker a acelerar o processo de reconhecimento.

A configuração padrão irá expor a versão do Apache e o tipo de sistema operacional, conforme mostrado abaixo.

• Vá para a pasta $Web_Server/conf
• Modifique o httpd.conf usando o editor vi
• Adicione a seguinte diretiva e salve o httpd.conf

 ServerTokens Prod ServerSignature Off

• Reinicie o apache

ServerSignature removerá as informações de versão da página gerada pelo Apache.

ServerTokens mudará Header para produção apenas, ou seja, Apache

Como você pode ver abaixo, as informações da versão e do sistema operacional desapareceram.

Desativar listagem de navegadores de diretório

Desative a listagem de diretórios em um navegador, para que o visitante não veja todos os arquivos e pastas que você tem na raiz ou subdiretório.

Vamos testar como fica nas configurações padrão.

• Vá para o diretório $Web_Server/htdocs
• Crie uma pasta e alguns arquivos dentro dela

 # mkdir test # touch hi # touch hello

Agora, vamos tentar acessar o Apache por http://localhost/test

Como você pode ver, ele revela todos os arquivos/pastas que você possui e tenho certeza de que você não deseja expor isso.

• Vá para o diretório $Web_Server/conf
• Abra o httpd.conf usando o vi
• Procure o diretório e altere a diretiva Options para None ou –Indexes

 <Directory /opt/apache/htdocs> Options -Indexes </Directory>

(ou)

 <Directory /opt/apache/htdocs> Options None </Directory>

• Reinicie o Apache

Observação : se você tiver várias diretivas de diretório em seu ambiente, considere fazer o mesmo para todas.

Agora, vamos tentar acessar o Apache por http://localhost/test

Como você pode ver, ele exibe um erro proibido em vez de mostrar a listagem de pastas de teste.

Etag

Ele permite que invasores remotos obtenham informações confidenciais, como número de inode, limite MIME de várias partes e processo filho por meio do cabeçalho Etag.

Para evitar essa vulnerabilidade, vamos implementá-la conforme abaixo. Isso é necessário para corrigir a conformidade com PCI.

• Vá para o diretório $Web_Server/conf
• Adicione a seguinte diretiva e salve o httpd.conf

 FileETag None

• Reinicie o apache

Execute o Apache de uma conta sem privilégios

Uma instalação padrão é executada como ninguém ou daemon. Usar um usuário não privilegiado separado para o Apache é bom.

A ideia aqui é proteger outros serviços em execução no caso de qualquer falha de segurança.

• Crie um usuário e grupo chamado apache

 # groupadd apache # useradd –G apache apache

• Altere a propriedade do diretório de instalação do apache para um usuário sem privilégios recém-criado

 # chown –R apache:apache /opt/apache

• Vá para $Web_Server/conf
• Modifique o httpd.conf usando o vi
• Pesquise por User & Group Directive e altere como apache de conta não privilegiada

 User apache Group apache

• Salve o httpd.conf
• Reinicie o Apache

grep para executar o processo http e garantir que ele esteja sendo executado com o usuário apache

 # ps –ef |grep http

Você deve ver que um processo está sendo executado com root. Isso porque o Apache está escutando na porta 80 e precisa ser iniciado com root.

Proteger permissão de diretório binário e de configuração

Por padrão, a permissão para binário e configuração é 755, o que significa que qualquer usuário em um servidor pode visualizar a configuração. Você pode impedir que outro usuário entre na pasta conf e bin.

• Vá para o diretório $ Web_Server
• Alterar a permissão da pasta bin e conf

 # chmod –R 750 bin conf

Proteção de configurações do sistema

Em uma instalação padrão, os usuários podem substituir a configuração do apache usando .htaccess. Se você quiser impedir que os usuários alterem as configurações do servidor apache, adicione AllowOverride a None , conforme mostrado abaixo.

Isso deve ser feito no nível da raiz.

• Vá para o diretório $Web_Server/conf
• Abra o httpd.conf usando o vi
• Pesquise o diretório em um nível raiz

 <Directory /> Options -Indexes AllowOverride None </Directory>

• Salve o httpd.conf
• Reinicie o Apache

Métodos de solicitação HTTP

O protocolo HTTP 1.1 suporta muitos métodos de solicitação que podem não ser necessários e alguns deles apresentam risco potencial.

Normalmente, você pode precisar dos métodos de solicitação GET, HEAD, POST em um aplicativo da Web, que pode ser configurado na respectiva diretiva de diretório.

A configuração padrão suporta o método OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT no protocolo HTTP 1.1.

• Vá para o diretório $Web_Server/conf
• Abra o httpd.conf usando o vi
• Pesquise por Diretório e adicione o seguinte

 <LimitExcept GET POST HEAD> deny from all </LimitExcept>

• Reinicie o Apache

Desativar solicitação HTTP de rastreamento

Por padrão, o método Trace está habilitado no servidor web Apache.

Ativar isso pode permitir o ataque Cross Site Tracing e potencialmente dar uma opção a um hacker para roubar informações de cookies. Vamos ver como fica na configuração padrão.

• Faça um IP de servidor web telnet com porta de escuta
• Faça uma solicitação TRACE conforme mostrado abaixo

 #telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. TRACE / HTTP/1.1 Host: test HTTP/1.1 200 OK Date: Sat, 31 Aug 2013 02:13:24 GMT Server: Apache Transfer-Encoding: chunked Content-Type: message/http 20 TRACE / HTTP/1.1 Host: test 0 Connection closed by foreign host. #

Como você pode ver na solicitação TRACE acima, ele respondeu minha consulta. Vamos desativá-lo e testá-lo.

• Vá para o diretório $Web_Server/conf
• Adicione a seguinte diretiva e salve o httpd.conf

 TraceEnable off

• Reinicie o apache

Faça um IP de servidor web telnet com porta de escuta e faça uma solicitação TRACE conforme mostrado abaixo

 #telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. TRACE / HTTP/1.1 Host: test HTTP/1.1 405 Method Not Allowed Date: Sat, 31 Aug 2013 02:18:27 GMT Server: Apache Allow:Content-Length: 223Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>405 Method Not Allowed</title> </head><body> <h1>Method Not Allowed</h1> <p>The requested method TRACE is not allowed for the URL /.</p> </body></html> Connection closed by foreign host. #

Como você pode ver na solicitação TRACE acima, ela bloqueou minha solicitação com o método HTTP 405 não permitido.

Agora, este servidor web não permite a solicitação TRACE e ajuda a bloquear o ataque Cross Site Tracing.

Definir cookie com HttpOnly e sinalizador seguro

Você pode mitigar a maioria dos ataques comuns de Cross Site Scripting usando HttpOnly e o sinalizador Secure em um cookie. Sem ter HttpOnly e Secure, é possível roubar ou manipular a sessão e os cookies da aplicação web, e isso é perigoso.

• Certifique-se de que mod_headers.so esteja ativado em seu httpd.conf
• Vá para o diretório $Web_Server/conf
• Adicione a seguinte diretiva e salve o httpd.conf

 Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

• Reinicie o apache

Ataque de clickjacking

Clickjacking é uma vulnerabilidade de aplicativo da web bem conhecida.

• Certifique-se de que mod_headers.so esteja ativado em seu httpd.conf
• Vá para o diretório $Web_Server/conf
• Adicione a seguinte diretiva e salve o httpd.conf

 Header always append X-Frame-Options SAMEORIGIN

• Reinicie o apache

X-Frame-Options também suporta mais duas opções que expliquei aqui.

Inclusão do lado do servidor

Server Side Include (SSI) tem o risco de aumentar a carga no servidor. Se você compartilhou o ambiente e os aplicativos da Web de tráfego intenso, considere desabilitar o SSI adicionando a diretiva Include in Options.

O ataque SSI permite a exploração de uma aplicação web injetando scripts em páginas HTML ou executando códigos remotamente.

• Vá para o diretório $Web_Server/conf
• Abra o httpd.conf usando o vi
• Procure o diretório e adicione a diretiva Include in Options

 <Directory /opt/apache/htdocs> Options –Indexes -Includes Order allow,denyAllow from all </Directory>

• Reinicie o Apache

Observação: se você tiver várias diretivas de diretório em seu ambiente, considere fazer o mesmo para todas.

Proteção X-XSS

A proteção Cross Site Scripting (XSS) pode ser ignorada em muitos navegadores. Você pode aplicar essa proteção a um aplicativo da Web se ele tiver sido desabilitado pelo usuário. Isso é usado pela maioria das empresas gigantes da web como Facebook, Twitter, Google, etc.

• Vá para o diretório $Web_Server/conf
• Abra httpd.conf usando vi e adicione a seguinte diretiva de cabeçalho

 Header set X-XSS-Protection "1; mode=block"

• Reinicie o Apache

Como você pode ver, XSS-Protection é injetado no cabeçalho de resposta.

Desativar protocolo HTTP 1.0

Quando falamos de segurança, devemos proteger o máximo que pudermos. Então, por que usamos a versão HTTP mais antiga do protocolo, vamos desativá-los também?

O HTTP 1.0 tem uma fraqueza de segurança relacionada ao seqüestro de sessão. Podemos desabilitar isso usando o módulo mod_rewrite.

• Certifique-se de carregar o módulo mod_rewrite no arquivo httpd.conf
• Habilite a diretiva RewriteEngine como segue e adicione a condição Rewrite para permitir apenas HTTP 1.1

 RewriteEngine On RewriteCond %{THE_REQUEST} !HTTP/1.1$ RewriteRule .* - [F]

Configuração do valor de tempo limite

Por padrão, o valor de tempo limite do Apache é de 300 segundos, o que pode ser vítima de ataque Slow Loris e DoS. Para atenuar isso, você pode diminuir o valor do tempo limite para talvez 60 segundos.

• Vá para o diretório $Web_Server/conf
• Abra o httpd.conf usando o vi
• Adicione o seguinte em httpd.conf

 Timeout 60

SSL

Ter SSL é uma camada adicional de segurança que você está adicionando ao aplicativo Web. No entanto, a configuração padrão de SSL leva a certas vulnerabilidades e você deve considerar ajustar essas configurações.

Chave SSL

A violação da chave SSL é difícil, mas não impossível. É apenas uma questão de poder computacional e tempo.

Como você deve saber, usando um PC da era de 2009 quebrando por cerca de 73 dias, você pode fazer engenharia reversa de uma chave de 512 bits.

Portanto, quanto maior o comprimento da chave, mais complicado se torna quebrar a chave SSL. A maioria das empresas gigantes da Web usam chave de 2048 bits, como abaixo, então por que não nós?

• Outlook.com
• Microsoft.com
• Live.com
• Skype.com
• Apple.com
• Yahoo.com
• Bing.com
• Hotmail.com
• Twitter.com

Você pode usar o OpenSSL para gerar CSR com 2048 bits conforme abaixo.

 openssl req -out geekflare.csr -newkey rsa:2048 -nodes -keyout geekflare.key

Ele gerará um CSR que você precisará enviar a uma autoridade de certificação para assiná-lo. Depois de receber o arquivo de certificado assinado, você pode adicioná-los no arquivo httpd-ssl.conf

 SSLCertificateFile #Certificate signed by authority SSLCertificateChainFile #Certificate signer given by authority SSLCertificateKeyFile #Key file which you generated above

• Reinicie o servidor web Apache e tente acessar a URL com https

Cifra SSL

SSL Cipher é um algoritmo de criptografia, que é usado como chave entre dois computadores na Internet. A criptografia de dados é o processo de conversão de texto simples em códigos criptografados secretos.

É baseado na configuração do SSL Cipher do seu servidor web que a criptografia de dados ocorrerá. Portanto, é importante configurar o SSL Cipher, que é mais forte e não vulnerável.

• Vá para a pasta $Web_Server/conf/extra
• Modifique a diretiva SSLCipherSuite em httpd-ssl.conf conforme abaixo para aceitar apenas algoritmos de criptografia mais altos

 SSLCipherSuite HIGH:!MEDIUM:!aNULL:!MD5:!RC4

• Salve o arquivo de configuração e reinicie o servidor apache

Observação: se você tiver muitas cifras fracas em seu relatório de auditoria SSL, poderá rejeitá-las rapidamente adicionando ! no inicio.

Desabilitar SSL v2 e v3

SSL v2 e v3 tem muitas falhas de segurança, e se você estiver trabalhando para teste de penetração ou conformidade com PCI, espera-se que você feche a descoberta de segurança para desabilitar o SSL v2/v3.

Qualquer comunicação SSL v2/v3 pode ser vulnerável a um ataque Man-in-The-Middle que pode permitir adulteração ou divulgação de dados.

Vamos implementar o servidor web apache para aceitar apenas o TLS mais recente e rejeitar a solicitação de conexão SSL v2/v3.

• Vá para a pasta $Web_Server/conf/extra
• Modifique a diretiva SSLProtocol em httpd-ssl.conf conforme abaixo para aceitar apenas TLS 1.2+

 SSLProtocol –ALL +TLSv1.2

Depois de concluir a configuração do SSL, é uma boa ideia testar seu aplicativo da Web com a ferramenta de certificado SSL/TLS online para encontrar qualquer erro de configuração.

Segurança do Mod

Mod Security é um firewall de aplicativo da Web de código aberto, que você pode usar com o Apache.

Ele vem como um módulo que você precisa compilar e instalar. Se você não puder comprar um firewall comercial para aplicativos da Web, essa seria uma excelente opção.

Para fornecer proteção genérica a aplicativos da Web, as Regras Principais usam as seguintes técnicas:

• Proteção HTTP – detectando violações do protocolo HTTP e uma política de uso definida localmente
• Pesquisas de lista negra em tempo real - utiliza reputação de IP de terceiros
• Detecção de malware baseada na Web – identifica conteúdo malicioso da Web verificando a API de navegação segura do Google.
• Proteções de negação de serviço HTTP – defesa contra inundação de HTTP e ataques HTTP DoS lentos.
• Proteção comum contra ataques da Web – detectando ataques comuns à segurança de aplicativos da Web
• Detecção de automação – Detectando bots, rastreadores, scanners e outra atividade de superfície maliciosa
• Integração com AV Scanning for File Uploads – identifica arquivos maliciosos carregados por meio do aplicativo da web.
• Rastreamento de dados confidenciais – Rastreia o uso do cartão de crédito e bloqueia vazamentos.
• Proteção de Trojan – Detectando acesso a cavalos de Tróia.
• Identificação de Defeitos do Aplicativo – alertas sobre configurações incorretas do aplicativo.
• Detecção e Ocultação de Erros – Disfarça as mensagens de erro enviadas pelo servidor.

Download e instalação

Os pré-requisitos a seguir devem ser instalados no servidor onde você deseja usar o Mod Security com Apache. Se algum deles não existir, a compilação do Mod Security falhará. Você pode usar o yum install no Linux ou Centos para instalar esses pacotes.

• apache 2.x ou superior
• pacote libpcre
• pacote libxml2
• pacote liblua
• pacote libcurl
• pacote libapr e libapr-util
• módulo mod_unique_id empacotado com servidor web Apache

Agora, vamos baixar a versão estável mais recente do Mod Security 2.7.5 aqui

• Transfira o arquivo baixado para /opt/apache
• Extraia modsecurity-apache_2.7.5.tar.gz

 # gunzip –c modsecurity-apache_2.7.5.tar.gz | tar xvf –

• Vá para a pasta extraída modsecurity-apache_2.7.5

 # cd modsecurity-apache_2.7.5

• Execute o script de configuração incluindo o caminho apxs para o Apache existente

 # ./configure –with-apxs=/opt/apache/bin/apxs

• Compile e instale com o script make

 # make # make install

• Depois que a instalação estiver concluída, você verá mod_security2.so na pasta de módulos em /opt/apache

Agora que isso conclui, você instalou o módulo Mod Security no servidor web Apache existente.

Configuração

Para usar o recurso de segurança Mod com o Apache, temos que carregar o módulo de segurança mod em httpd.conf. O módulo mod_unique_id é pré-requisito para Mod Security.

Este módulo fornece uma variável de ambiente com um identificador único para cada solicitação, que é rastreada e utilizada pelo Mod Security.

• Adicione seguindo uma linha para carregar o módulo para Mod Security em httpd.conf e salve o arquivo de configuração

 LoadModule unique_id_module modules/mod_unique_id.so LoadModule security2_module modules/mod_security2.so

• Reinicie o servidor web apache

Mod Security já está instalado!

A próxima coisa que você precisa fazer é instalar a regra principal do Mod Security para aproveitar ao máximo seu recurso.

A última regra básica pode ser baixada seguindo um link, que é gratuito. https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master

• Copie o zip da regra principal baixada para a pasta /opt/apache/conf
• Descompacte o arquivo de regra principal
• Você pode querer renomear a pasta para algo curto e fácil de lembrar. Neste exemplo, vou renomear para crs.
• Vá para a pasta crs e renomeie modsecurity_crs10_setup.conf.example para modsecurity_crs10_setup.conf

Agora, vamos habilitar essas regras para que funcionem com o servidor web Apache.

• Adicione o seguinte em httpd.conf

 <IfModule security2_module> Include conf/crs/modsecurity_crs_10_setup.confInclude conf/crs/base_rules/*.conf </IfModule>

Na configuração acima, estamos carregando o arquivo de configuração principal do Mod Security modsecurity_crs_10_setup.conf e as regras básicas base_rules/*.conf fornecidas pelo Mod Security Core Rules para proteger aplicativos da web.

• Reinicie o servidor web apache

Você configurou com sucesso o Mod Security com o Apache!

Bem feito. Agora, o servidor da Web Apache é protegido pelo firewall de aplicativo da Web Mod Security.

Começando

Vamos começar com algumas das configurações críticas do Mod Security para fortalecer e proteger aplicativos da web.

Nesta seção, faremos todas as modificações de configuração em /opt/apache/conf/crs/modsecurity_crs_10_setup.conf.

Referiremos /opt/apache/conf/crs/modsecurity_crs_10_setup.conf como setup.conf nesta seção para fins de exemplo.

É importante entender quais são as regras do OWASP são fornecidas gratuitamente. Existem dois tipos de regras fornecidas pelo OWASP.

Regras básicas – essas regras são fortemente testadas e, provavelmente, a taxa de falsos alarmes é menor.

Regras experimentais – essas regras são para fins experimentais e você pode ter um alarme falso alto. É importante configurar, testar e implementar no UAT antes de usá-los em um ambiente de produção.

Regras opcionais – essas regras opcionais podem não ser adequadas para todo o ambiente. Com base em sua exigência, você pode usá-los.

Se você estiver procurando por proteção CSRF, rastreamento de usuários, seqüestro de sessão, etc., considere usar regras opcionais. Temos as regras básicas, opcionais e experimentais após extrair o arquivo zip crs baixado da página de download do OWASP.

Este arquivo de configuração de regras está disponível nas pastas crs/base_rules, crs/optional_rules e crs/experimental_rules. Vamos nos familiarizar com algumas das regras básicas.

• modsecurity_crs_20_protocol_violations.conf: Esta regra protege contra vulnerabilidades de protocolo como divisão de resposta, contrabando de solicitações, usando protocolo não permitido (HTTP 1.0).
• modsecurity_crs_21_protocol_anomalies.conf: Isso é para proteger de uma solicitação, que está faltando com Host, Accept, User-Agent no cabeçalho.
• modsecurity_crs_23_request_limits.conf: Esta regra tem a dependência do aplicativo específico, como tamanho da solicitação, tamanho do upload, comprimento de um parâmetro, etc.
• modsecurity_crs_30_http_policy.conf:Isso é para configurar e proteger métodos permitidos ou não permitidos como CONNECT, TRACE, PUT, DELETE, etc.
• modsecurity_crs_35_bad_robots.conf: Detectar robôs maliciosos
• modsecurity_crs_40_generic_attacks.conf:Isso é para proteger contra injeção de comandos do SO, inclusão de arquivos remotos, etc.
• modsecurity_crs_41_sql_injection_attacks.conf:Esta regra para proteger SQL e solicitação de injeção de SQL cega.
• modsecurity_crs_41_xss_attacks.conf:Proteção contra solicitação de script entre sites.
• modsecurity_crs_42_tight_security.conf: Detecção e proteção de passagem de diretório.
• modsecurity_crs_45_trojans.conf:Esta regra para detectar saída de gerenciamento de arquivo genérico, upload de página de backdoor HTTP, assinatura conhecida.
• modsecurity_crs_47_common_exceptions.conf: Isso é usado como um mecanismo de exceção para remover falsos positivos comuns que podem ser encontrados como conexão fictícia interna do Apache, pinger SSL, etc.

Exploração madeireira

O log é uma das primeiras coisas a configurar para que você possa criar logs para o que o Mod Security está fazendo. Existem dois tipos de registro disponíveis; Registro de depuração e auditoria.

Log de depuração: é para duplicar as mensagens de erro, aviso e aviso do Apache do log de erros.

Log de auditoria: serve para gravar os logs de transação marcados pela regra Mod Security O Mod Security oferece a flexibilidade de configurar o log de auditoria, depuração ou ambos.

Por padrão, a configuração gravará os dois logs. No entanto, você pode alterar com base em sua necessidade. O log é controlado na diretiva SecDefaultAction . Vejamos a configuração de log padrão em setup.conf

 SecDefaultAction “phase:1,deny,log”

Para registrar Debug, log de auditoria – use “log” Para registrar apenas log de auditoria – use “nolog,auditlog” Para registrar apenas log de depuração – use “log,noauditlog” Você pode especificar o local do Log de Auditoria a ser armazenado que é controlado por SecAuditLog diretiva.

Vamos escrever o log de auditoria em /opt/apache/logs/modsec_audit.log adicionando como mostrado abaixo.

• Adicione a diretiva SecAuditLog no setup.conf e reinicie o Apache Web Server

 SecAuditLog /opt/apache/logs/modsec_audit.log

• Após a reinicialização, você deverá ver o modsec_audit.log sendo gerado

Ativar mecanismo de regras

Por padrão, a regra do mecanismo está desativada, o que significa que, se você não ativar o mecanismo de regras, não está utilizando todas as vantagens do Mod Security.

A habilitação ou desabilitação do Rule Engine é controlada pela diretiva SecRuleEngine .

• Adicione a diretiva SecRuleEngine no setup.conf e reinicie o Apache Web Server

 SecRuleEngine On

Existem três valores para SecRuleEngine:

• Ativado – para habilitar o mecanismo de regras
• Desligado – para desabilitar o mecanismo de regras
• DetectionOnly – habilita o mecanismo de regras, mas nunca executa ações como bloquear, negar, descartar, permitir, proxy ou redirecionar

Quando o Rule Engine estiver ativado, o Mod Security estará pronto para proteger com alguns dos tipos de ataque comuns.

Proteção de tipo de ataque comum

Agora o servidor web está pronto para proteger com tipos de ataques comuns como XSS, SQL Injection, Protocol Violation, etc., pois instalamos o Core Rule e ativamos o Rule Engine. Vamos testar alguns deles.

Ataque XSS

• Abra o Firefox e acesse seu aplicativo e coloque a tag <script> no final ou URL
• Monitore o modsec_audit.log na pasta apache/logs

Você notará que o Mod Security bloqueia a solicitação, pois contém a tag <script>, que é a raiz do ataque XSS.

Ataque de travessia de diretório: - Os ataques de travessia de diretório podem criar muitos danos, aproveitando essas vulnerabilidades e acessando arquivos relacionados ao sistema. Ex – /etc/passwd, .htaccess, etc.

• Abra o Firefox e acesse seu aplicativo com passagem de diretório
• Monitore o modsec_audit.log na pasta apache/logs

 http://localhost/?../.../boot

• Você notará que o Mod Security bloqueia a solicitação, pois contém a travessia de diretório.

Alterar banner do servidor

Anteriormente neste guia, você aprendeu como remover o Apache e o tipo de SO, ajuda de versão da diretiva ServerTokens.

Vamos um passo à frente, que tal manter o nome do servidor como quiser? É possível com a diretiva SecServerSignature no Mod Security. Você vê que é interessante.

Nota: para usar o Mod Security para manipular o Banner do Servidor a partir de um cabeçalho, você deve definir ServerTokesn como Full no httpd.conf do servidor web Apache.

• Adicione a diretiva SecServerSignature com o nome do servidor desejado em setup.conf e reinicie o Apache Web Server

 SecServerSignature YourServerName

Ex:

 [/opt/apache/conf/crs] #grep SecServer modsecurity_crs_10_setup.conf SecServerSignature geekflare.com [/opt/apache/conf/crs] #

Configuração geral

Vamos verificar algumas das configurações gerais como prática recomendada.

Configurar Ouvir

Quando você tem várias interfaces e IPs em um único servidor, é recomendável ter a diretiva Listen configurada com IP absoluto e número de porta.

Quando você deixa a configuração do apache para Ouvir todos os IPs com algum número de porta, isso pode criar o problema de encaminhar a solicitação HTTP para algum outro servidor web. Isso é bastante comum no ambiente compartilhado.

• Configure a diretiva Listen em httpd.conf com IP absoluto e porta como um exemplo mostrado abaixo

 Listen 10.10.10.1:80

Log de acesso

É essencial configurar o log de acesso corretamente em seu servidor web. Alguns dos parâmetros importantes a serem capturados no log seriam o tempo necessário para atender a solicitação, SESSION ID.

Por padrão, o Apache não está configurado para capturar esses dados. Você tem que configurá-los manualmente da seguinte forma.

• Para capturar o tempo gasto para atender a solicitação e o SESSION ID em um log de acesso
• Adicione %T & %sessionID em httpd.conf sob a diretiva LogFormat

 LogFormat "%h %l %u %t "%{sessionID}C" "%r" %>s %b %T" common

Você pode consultar http://httpd.apache.org/docs/2.2/mod/mod_log_config.html para obter uma lista completa de parâmetros suportados na diretiva LogFormat no Apache Web Server.

Desabilitar Carregando módulos indesejados

Se você compilou e instalou com todos os módulos, há grandes chances de ter muitos módulos carregados no Apache, o que pode não ser necessário.

A melhor prática é configurar o Apache com os módulos necessários em seus aplicativos da web. Os módulos a seguir têm questões de segurança e você pode estar interessado em desabilitar o httpd.conf do Apache Web Server.

WebDAV (Web-based Distributed Authoring and Versioning) Este módulo permite que clientes remotos manipulem arquivos no servidor e estejam sujeitos a vários ataques de negação de serviço. Para desabilitar o comentário seguinte em httpd.conf

 #LoadModule dav_module modules/mod_dav.so #LoadModule dav_fs_module modules/mod_dav_fs.so #Include conf/extra/httpd-dav.conf

Módulo Info O módulo mod_info pode vazar informações confidenciais usando .htaccess assim que este módulo for carregado. Para desabilitar o comentário seguinte em httpd.conf

 #LoadModule info_module modules/mod_info.so

Referência: Isso não seria possível sem a orientação do seguinte link:

• http://httpd.apache.org/docs/2.4/
• http://www.modsecurity.org/documentation/
• https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

Então, essas foram algumas das melhores práticas que você pode usar para proteger seu servidor web Apache.

Verifique este link se você deseja implementar a página de erro personalizada no Apache.

Se você é novo no Apache HTTP, recomendo fazer o curso de administração do Apache HTTP.