Configurar o Apache para PHP com segurança

Em resumo: Para configurar o Apache para PHP com segurança, ligue o PHP através do PHP-FPM e do mod_proxy_fcgi, desative o .htaccess com AllowOverride None e defina ServerTokens Prod, ServerSignature Off, TraceEnable Off e Options -Indexes. Ajuste o LimitRequestBody aos limites do PHP e desative os módulos desnecessários. A configuração não substitui uma atualização do PHP, mas reduz claramente a superfície de ataque.

O Apache após o PHP2Shell: mais do que um reinício

Os operadores de Apache estiveram, em outubro de 2026, sob pressão especial. A equipa do PHP classifica o risco no mod_php como o mais elevado, porque foi demonstrado um exploit nesse modo antes de sequer ser executado código da aplicação. Os passos agudos, ou seja, aplicar o patch e reiniciar por completo, são descritos na página Por que o mod_php tem o risco mais elevado.

Depois do patch, fica a questão de quão boa é a própria configuração do Apache. Os servidores que foram crescendo trazem muitas vezes definições de muitos anos: listagens de diretórios, permissões abertas de .htaccess, módulos de que já ninguém precisa. Qualquer uma delas pode tornar um erro posterior maior do que teria de ser.

Este artigo descreve uma configuração de base enxuta e segura para o Apache 2.4 com PHP-FPM. Os exemplos usam caminhos Debian e Ubuntu; na família RHEL, os ficheiros estão em /etc/httpd/.

Ligar o PHP através do PHP-FPM em vez do mod_php

Com o PHP-FPM, o PHP corre em processos próprios, separado do servidor web. O Apache encaminha os pedidos através do mod_proxy_fcgi. Segundo a documentação do Apache, a ligação por SetHandler tem uma vantagem sobre o ProxyPassMatch: o Apache associa primeiro ele próprio o pedido a um ficheiro no sistema de ficheiros e só depois o passa ao PHP-FPM.

<FilesMatch "\.php$">
    SetHandler "proxy:unix:/run/php/seite1.sock|fcgi://localhost/"
</FilesMatch>

Ative os módulos no Debian e no Ubuntu com a2enmod proxy_fcgi. Quem muda do mod_php desativa o módulo PHP e passa depois do MPM Prefork para o MPM Event. O contexto do modo de operação antigo é explicado em mod_php explicado: PHP no processo do Apache.

Do lado do PHP-FPM, security.limit_extensions = .php pertence a cada pool. Segundo o manual do PHP, o FPM executa, caso contrário, também ficheiros .phar.

Configurar o Apache para PHP com segurança: as opções centrais

Algumas definições aplicam-se a todo o servidor e pertencem a um ficheiro de configuração próprio, por exemplo /etc/apache2/conf-available/haertung.conf, ativado com a2enconf haertung.

# Encurtar indicações de versão (só possível para todo o servidor)
ServerTokens Prod
ServerSignature Off

# Desativar o método TRACE
TraceEnable Off

# Por princípio, não libertar nada; os sites permitem de forma dirigida
<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>

O quadro seguinte enquadra as opções mais importantes. Os valores por defeito e o efeito provêm da documentação do Apache.

Importante no AllowOverride: muitas distribuições e guias de CMS definem AllowOverride All para a raiz web. Com isso, qualquer ficheiro .htaccess pode alterar regras de reescrita, handlers e, com o mod_php, até definições do PHP. Um atacante com direitos de escrita numa pasta de uploads pode aí criar um .htaccess próprio. Com AllowOverride None, este caminho fica fechado.

Um VirtualHost como modelo

O VirtualHost seguinte reúne os pontos para um único site. Adapte caminhos de certificados, socket e diretórios. O mod_ssl e o mod_headers têm de estar ativos.

<VirtualHost *:443>
    ServerName www.example.de
    DocumentRoot /var/www/seite1/public

    SSLEngine on
    SSLCertificateFile    /etc/ssl/seite1/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/seite1/privkey.pem

    <Directory /var/www/seite1/public>
        Options -Indexes +SymLinksIfOwnerMatch
        AllowOverride None
        Require all granted
    </Directory>

    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/run/php/seite1.sock|fcgi://localhost/"
    </FilesMatch>

    # Bloquear controlo de versões e ficheiros de ambiente
    <DirectoryMatch "/\.(git|svn|hg)">
        Require all denied
    </DirectoryMatch>
    <FilesMatch "^\.env">
        Require all denied
    </FilesMatch>

    # 32 MiB, adequado a post_max_size = 32M
    LimitRequestBody 33554432

    Header unset X-Powered-By
    Header always unset X-Powered-By
</VirtualHost>

O Header unset duplicado não é descuido. Segundo a documentação do Apache, os cabeçalhos do mod_proxy_fcgi vão parar a uma tabela interna diferente da dos cabeçalhos do próprio servidor; com ambas as variantes, apanha os dois casos. Outros cabeçalhos que protegem ativamente os visitantes são descritos no guia Cabeçalhos de segurança para sites.

As pastas de uploads e de cache precisam, além disso, de um bloqueio de execução. Como encontrar e bloquear todas as pastas com permissão de escrita está em Proibir a execução de PHP em pastas de uploads.

Limpar módulos e verificar o resultado

Cada módulo carregado é código que reage a pedidos. Verifique que módulos estão ativos e desative o que não precisa. Candidatos típicos são autoindex, status sem restrição de acesso, cgi e userdir.

# Mostrar módulos ativos
apachectl -M | sort
# Exemplo Debian/Ubuntu: desativar o módulo de listagem de diretórios
sudo a2dismod autoindex
# Verificar a configuração e só depois recarregar
sudo apachectl configtest && sudo systemctl reload apache2
# Teste a partir de fora: TRACE deve devolver 405, .git 403
curl -s -o /dev/null -w "%{http_code}\n" -X TRACE https://www.example.de/
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/.git/HEAD

O mod_status merece atenção especial. A página de estado mostra pedidos em curso, com endereços e caminhos acedidos. Se for necessária, restrinja o acesso com Require ip às suas redes de administração. O mesmo vale para páginas de estado do PHP-FPM que tenham sido tornadas acessíveis através do Apache.

Como camada adicional antes da aplicação, pode fazer sentido uma Web Application Firewall própria; a introdução é descrita em Utilizar o ModSecurity e o OWASP Core Rule Set.

Conclusão: a ordem vence a medida isolada

Uma configuração segura do Apache para PHP consiste em poucos blocos bem compreendidos. O PHP corre através do PHP-FPM, separado do servidor web, o .htaccess não é avaliado, as indicações de versão e o TRACE estão desativados, os limites de tamanho são compatíveis com o PHP e as pastas com permissão de escrita não executam scripts. Nenhum destes pontos é, por si só, espetacular. Em conjunto, garantem que um erro num sítio não leva de imediato à tomada de controlo do servidor.

Para a gestão e os responsáveis de projeto, uma segunda característica é quase mais importante: uma configuração arrumada é rastreável. Se todas as regras estiverem no VirtualHost, em vez de dispersas por dezenas de ficheiros .htaccess, na próxima vulnerabilidade crítica verifica-se rapidamente que site está ligado de que forma. Numa situação como a de outubro de 2026, isso poupa precisamente o tempo que conta.

Ainda assim, planeie a migração com calma e com um ambiente de teste. Uma mudança precipitada do mod_php para o PHP-FPM pouco antes de um fim de semana cria mais problemas do que resolve.

Como ajuda concretamente a PHP SOS?

• Verificar o existente: lemos toda a configuração do Apache, todos os módulos ativos e todos os ficheiros .htaccess.
• Planear a migração: onde ainda corre o mod_php, preparamos a mudança para o PHP-FPM com pools próprios por site.
• Reforçar a configuração: definimos as opções centrais, passamos as regras do .htaccess para os VirtualHosts e bloqueamos as pastas com permissão de escrita.
• Testar e documentar: após cada alteração, verificamos os sites a partir de fora e registamos o estado no âmbito do reforço de segurança de servidores.

Perguntas frequentes

Fontes

• Apache: funcionalidades centrais (core)
• Apache: mod_proxy_fcgi
• Apache: mod_headers
• php.net: comunicados de segurança