Hardening do Apache: O Guia para Amplificar sua Segurança (com tudo que pode dar errado se você não fizer) Cada configuração padrão do Apache que você ignora é uma porta entreaberta. Este guia mostra exatamente o que cada uma delas significa na prática — e como fechar, uma por uma.
Hardening do Apache: O Guia para Amplificar sua Segurança (com tudo que pode dar errado se você não fizer) Cada configuração padrão do Apache que você ignora é uma porta entreaberta. Este guia mostra exatamente o que cada uma delas significa na prática — e como fechar, uma por uma. Introdução O Apache HTTP Server é um dos servidores web mais usados do planeta há mais de 25 anos. E justamente por isso, é também um dos alvos mais estudados por atacantes. A configuração padrão dele é projetada para funcionar em qualquer lugar , não para ser segura em qualquer lugar . Essa diferença é o que separa um servidor saudável de um servidor que vira manchete. Neste guia, vamos passar por cada item de hardening explicando três coisas: O que a configuração padrão faz (ou deixa de fazer) O que um atacante consegue fazer com isso — com cenários reais Como corrigir , com configuração pronta pra copiar No final, você terá um Apache pronto pra produção e vai entender exatamente por que cada linha está ali. ServerTokens e ServerSignature: você está entregando um mapa do tesouro O que acontece por padrão Quando o Apache responde a qualquer requisição, ele inclui um header Server que, por padrão, contém algo assim: E em páginas de erro (404, 500, 403), ele adiciona um rodapé: Pode parecer inofensivo. Não é. O que isso causa na prática Imagine que você está rodando Apache 2.4.52 no Ubuntu. Um atacante varrendo a internet com Shodan, Censys ou um simples script Python descobre seu servidor. Em segundos, ele: Consulta o banco de CVEs filtrando por "Apache 2.4.52" — e encontra uma lista de vulnerabilidades conhecidas para essa versão exata. Sabe que é Ubuntu , então sabe quais pacotes estão instalados, qual é o caminho padrão dos arquivos (/var/www/html), onde ficam os logs, qual é o usuário que roda o serviço (www-data). Filtra exploits prontos no Exploit-DB ou Metasploit que casam com a sua versão. Se houver um exploit não corrigido, em poucos minutos ele já está testando. O custo de um atacante descobrir tudo isso saiu de "horas de reconhecimento" para "uma requisição HTTP". Você economizou o trabalho dele. Pior: scanners automatizados como o Mirai e seus derivados varrem a internet 24/7 procurando exatamente versões vulneráveis específicas. Não é pessoal — é industrial. A correção Em /etc/apache2/conf-enabled/security.conf (Debian/Ubuntu) ou /etc/httpd/conf/httpd.conf (RHEL/CentOS/Rocky): Depois disso, o header Server vira simplesmente Apache. O atacante ainda sabe que é Apache (não tem como esconder 100%), mas perdeu a versão e o sistema operacional. Já não consegue mais filtrar exploits específicos sem trabalho extra. Importante: isso é "segurança por obscuridade" e não substitui manter o servidor atualizado. Mas reduz drasticamente o número de ataques automatizados que conseguem te encontrar como alvo viável. expose php: o PHP gritando sua versão para o mundo O que acontece por padrão Toda resposta gerada por uma página PHP traz um header como: O que isso causa Mesmo problema do ServerTokens, com agravante: vulnerabilidades de PHP costumam ser muito mais críticas que vulnerabilidades do Apache, porque o PHP executa código. Algumas das CVEs mais conhecidas dos últimos anos (CVE-2019-11043 no PHP-FPM, por exemplo) permitiam execução remota de código com uma única requisição bem formada. Se o atacante sabe que você está rodando PHP 8.1.2, ele consulta as CVEs daquela versão exata e tenta. Se sua versão for vulnerável e ainda não tiver sido patchada, é game over. Existe outro efeito colateral menos óbvio: ferramentas de bug bounty e scanners agressivos priorizam alvos com versões antigas . Expor sua versão é como pendurar uma placa de "atire aqui primeiro". A correção No php.ini (use php --ini para descobrir o caminho exato): Reinicie o Apache (ou PHP-FPM, dependendo do seu setup). O header desaparece completamente. Atenção: se você usa PHP-FPM, há dois php.ini diferentes — um pro CLI e outro pro FPM. Ajuste o do FPM (/etc/php/8.x/fpm/php.ini). TraceEnable: o método HTTP que a gente esqueceu de matar O que acontece por padrão O método TRACE do HTTP foi criado nos anos 90 para fins de debug — quando você manda um TRACE, o servidor te responde com a requisição inteira que recebeu, intacta. Por padrão, o Apache vem com TraceEnable On. O que isso causa Existe um ataque conhecido chamado Cross-Site Tracing (XST) . A ideia: usando JavaScript em uma página comprometida, um atacante força o navegador da vítima a fazer um TRACE no servidor alvo. A resposta inclui todos os headers — inclusive cookies marcados como HttpOnly , que normalmente o JavaScript não consegue ler. Resultado: o atacante captura cookies de sessão que deveriam ser inacessíveis e sequestra a sessão da vítima. Funciona até hoje em servidores mal configurados. Além disso, scanners de vulnerabilidade automatizados marcam o TRACE habilitado como vulnerabilidade de severidade média, o que afeta scores de compliance (PCI-DSS, por exemplo, exige TRACE desabilitado). A correção…