Hardening básico no Apache: headers de segurança e exposição mínima

O que é hardening no Apache (na prática)

Hardening é o conjunto de ajustes que reduz a superfície de ataque do servidor web. No Apache, isso normalmente significa: (1) expor menos informações sobre o software/versão, (2) enviar headers de segurança para orientar o navegador a se comportar de forma mais segura, (3) permitir apenas o necessário (métodos HTTP, listagem de diretórios, links simbólicos), e (4) validar o resultado observando as respostas HTTP.

O objetivo aqui é aplicar um “pacote inicial” de endurecimento que seja simples, reversível e fácil de verificar com curl.

Pré-checagens rápidas (antes de mudar)

• Tenha clareza de onde aplicar: global (servidor inteiro) ou por site (VirtualHost). Para headers de segurança, geralmente faz sentido aplicar por site, pois políticas como CSP variam por aplicação.
• Após mudanças, valide sintaxe e recarregue o Apache: apachectl -t e depois systemctl reload apache2 (Debian/Ubuntu) ou systemctl reload httpd (RHEL/CentOS/Fedora).

1) Headers de segurança com mod_headers

1.1 Habilitar o módulo (se necessário)

Em distribuições Debian/Ubuntu, o módulo costuma ser habilitado com:

sudo a2enmod headers

Em seguida, recarregue o serviço. Em outras distribuições, o módulo pode já estar compilado/carregado; verifique se existe uma linha como LoadModule headers_module nos arquivos de módulos.

1.2 Onde colocar as diretivas de header

Você pode aplicar no contexto do site (recomendado) dentro do bloco do VirtualHost, por exemplo:

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

<VirtualHost *:80> ... </VirtualHost>

ou no VirtualHost de HTTPS. Se o site roda em HTTPS, prefira configurar no VirtualHost 443 para garantir que o comportamento final seja o do tráfego real.

1.3 Conjunto inicial de headers (base)

Exemplo de configuração inicial (ajuste dentro do seu VirtualHost):

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"

  # CSP inicial (conservadora, mas pode quebrar apps que usam scripts inline/CDNs)
  Header always set Content-Security-Policy "default-src 'self'; base-uri 'self'; frame-ancestors 'self'; object-src 'none'"
</IfModule>

O que cada header faz (sem mistério)

• X-Content-Type-Options: nosniff: impede que o navegador “adivinhe” tipos de arquivo (mitiga alguns vetores de XSS e execução indevida de conteúdo).
• X-Frame-Options: SAMEORIGIN: reduz risco de clickjacking, impedindo que seu site seja embutido em iframe de outro domínio (permite apenas do mesmo domínio).
• Referrer-Policy: strict-origin-when-cross-origin: limita o quanto de URL é vazado no header Referer ao navegar para outros sites.
• Content-Security-Policy (CSP): define de onde a página pode carregar recursos (scripts, imagens, frames etc.). É um dos controles mais fortes contra XSS, mas exige ajuste fino por aplicação.

1.4 CSP em nível inicial: como começar sem travar o site

A CSP é poderosa, mas pode quebrar páginas que dependem de: scripts inline, estilos inline, eval, ou recursos de CDNs. Uma abordagem prática é começar com uma política mínima e evoluir.

Opção A (mais restritiva, melhor segurança, maior chance de ajustes):

Header always set Content-Security-Policy "default-src 'self'; base-uri 'self'; frame-ancestors 'self'; object-src 'none'"

Opção B (mais compatível para início, ainda útil):

Header always set Content-Security-Policy "default-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self'; base-uri 'self'; frame-ancestors 'self'; object-src 'none'"

Use a Opção B apenas se você realmente precisar de 'unsafe-inline' para estilos. Evite adicionar 'unsafe-inline' em script-src se puder, pois reduz bastante a proteção contra XSS.

1.5 Dica: aplicar headers também em respostas de erro

O uso de Header always set garante que os headers sejam enviados mesmo em respostas 4xx/5xx (quando aplicável), o que é desejável para consistência.

2) Exposição mínima: ServerTokens e ServerSignature

Por padrão, o Apache pode revelar detalhes no header Server e em páginas de erro geradas automaticamente. Reduzir isso dificulta fingerprinting (identificação de versão/stack) e automatizações de ataque baseadas em versão.

2.1 Ajustes recomendados

Em configuração global (geralmente no arquivo principal do Apache ou em um arquivo de hardening incluído), aplique:

ServerTokens Prod
ServerSignature Off

• ServerTokens Prod: reduz o header Server para algo mais genérico (sem versão e módulos).
• ServerSignature Off: remove assinatura do servidor em páginas de erro e listagens (quando existirem).

Observação importante: mesmo com isso, alguns ambientes/proxies podem adicionar ou alterar headers. Por isso a validação com curl -I é essencial.

3) Limitar métodos HTTP quando aplicável

Nem toda aplicação precisa aceitar todos os métodos. Reduzir métodos aceitos pode diminuir risco de abuso e simplificar a superfície exposta. O ideal é permitir apenas o que o site usa (comum: GET, POST, HEAD).

3.1 Restringindo métodos por diretório

Exemplo para permitir apenas GET, POST e HEAD no DocumentRoot:

<Directory "/var/www/seusite/public">
  <LimitExcept GET POST HEAD>
    Require all denied
  </LimitExcept>
</Directory>

Se sua aplicação usa PUT/DELETE (APIs REST), ajuste a lista. Evite bloquear OPTIONS sem testar: alguns clientes e CORS podem depender dele.

3.2 Validando métodos expostos

Para inspecionar o que o servidor anuncia, você pode checar a resposta de OPTIONS (nem sempre habilitado/útil, mas ajuda):

curl -i -X OPTIONS http://seu-dominio/

Procure pelo header Allow:. Se aparecerem métodos que você não usa (ex.: TRACE), revise a necessidade e as restrições.

4) Revisar diretivas que aumentam risco: Indexes e FollowSymLinks

Algumas opções de diretório podem expor conteúdo sem intenção ou facilitar caminhos inesperados.

4.1 Desabilitar listagem de diretórios (Indexes)

Se Indexes estiver habilitado e não houver arquivo de índice, o Apache pode listar arquivos do diretório. Em muitos cenários isso vaza informações (nomes de backups, arquivos temporários, versões).

Garanta que Indexes não esteja ativo onde não deve:

<Directory "/var/www/seusite/public">
  Options -Indexes
</Directory>

Se você precisar de listagem em um diretório específico (ex.: repositório público de arquivos), habilite apenas nele e com cuidado.

4.2 Cuidado com FollowSymLinks

FollowSymLinks permite seguir links simbólicos no filesystem. Isso pode ser útil, mas aumenta risco se houver symlinks apontando para locais indevidos (por erro de deploy, permissões erradas, ou manipulação em ambientes compartilhados).

Uma postura inicial mais conservadora é desabilitar e habilitar apenas quando necessário:

<Directory "/var/www/seusite/public">
  Options -FollowSymLinks
</Directory>

Se sua aplicação depende de symlinks (deploys com releases, assets compartilhados), você pode manter FollowSymLinks, mas combine com boas permissões e revisão de onde os links apontam.

Atividade prática: validar com curl -I e checklist de resposta

5.1 Comandos de validação

Valide primeiro em HTTP e depois em HTTPS (se aplicável). Exemplos:

# Somente headers (HEAD)
curl -I http://seu-dominio/

# Em HTTPS (se existir)
curl -I https://seu-dominio/

# Ver headers e status com mais detalhes
curl -s -D - -o /dev/null https://seu-dominio/

Se você configurou headers no VirtualHost 443, valide principalmente o HTTPS.

5.2 Checklist: o que deve aparecer

5.3 Checklist: o que evitar/exigir atenção

5.4 Exercício guiado (passo a passo)

• 1) Aplique ServerTokens Prod e ServerSignature Off em nível global e recarregue.
• 2) No VirtualHost principal do site, adicione os headers base com mod_headers e recarregue.
• 3) Rode curl -I e confirme o checklist “deve aparecer”.
• 4) Rode curl -i -X OPTIONS e avalie se há métodos sobrando; se sim, aplique <LimitExcept> e teste novamente.
• 5) Teste se há listagem de diretórios em algum caminho que não deveria; se houver, aplique Options -Indexes no escopo correto.
• 6) Se sua aplicação usa symlinks, valide comportamento antes de desabilitar FollowSymLinks; caso não use, desabilite e teste rotas e assets.