# Configurar o Apache para PHP com segurança

> Configurar o Apache para PHP com segurança: PHP-FPM via mod_proxy_fcgi, AllowOverride None, ServerTokens, TraceEnable e LimitRequestBody definidos e verificados.

Fonte: https://phpsos.de/pt/blog/apache-fuer-php-absichern/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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](https://phpsos.de/pt/php2shell/mod-php-risiko/).

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.

```apache
<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](https://phpsos.de/pt/php/mod-php-erklaert/).

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`.

```apache
# 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.

| Diretiva | Por defeito | Recomendação | Porquê |
|---|---|---|---|
| `ServerTokens` | `Full` | `Prod` | o cabeçalho `Server` indica apenas «Apache» |
| `ServerSignature` | `Off` | `Off` | nenhuma linha de versão sob as páginas de erro |
| `TraceEnable` | `on` | `Off` | o TRACE é rejeitado com 405 |
| `Options` | `FollowSymlinks` | `-Indexes`, ligações simbólicas só conforme o proprietário | nenhuma listagem de diretórios |
| `AllowOverride` | `None` | `None` | o `.htaccess` não é avaliado |
| `LimitRequestBody` | 1 GiB (desde 2.4.54) | adequado ao `post_max_size` | rejeitar cedo pedidos grandes |

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.

```apache
<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](https://phpsos.de/pt/ratgeber/sicherheits-header/).

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](https://phpsos.de/pt/blog/php-in-uploads-verbieten/).

## 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`.

```bash
# 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.

> **Importante:**
> Não altere o `AllowOverride` sem preparação. Passe primeiro as regras de todos os ficheiros `.htaccess` para o VirtualHost e teste o site numa cópia. Caso contrário, os redirecionamentos e os URLs amigáveis deixam de funcionar após o recarregamento.

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](https://phpsos.de/pt/blog/modsecurity-owasp-crs/).

## 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](https://phpsos.de/pt/leistungen/server-haertung/).


## Perguntas frequentes

**Devo continuar a usar o mod_php?**  
Para novas instalações, recomendamos o PHP-FPM através do mod_proxy_fcgi. A equipa do PHP classifica o risco do PHP2Shell como o mais elevado no mod_php. Com o PHP-FPM, o PHP corre separado do servidor web, com utilizadores próprios por site e limites próprios.

**Por que AllowOverride None, se o meu CMS precisa de .htaccess?**  
Qualquer pessoa com permissão de escrita na raiz web pode criar um .htaccess, incluindo código introduzido. Com AllowOverride None, o Apache não avalia esses ficheiros. As regras do seu CMS passam então, de uma só vez, para o VirtualHost. Dá algum trabalho, mas torna a configuração rastreável e mais rápida.

**Posso definir o ServerTokens de forma diferente para cada site?**  
Não. Segundo a documentação do Apache, o ServerTokens aplica-se a todo o servidor e não pode ser alterado por VirtualHost. Controla ao mesmo tempo a indicação de versão sob as páginas de erro que o ServerSignature apresenta.

**Qual é o valor por defeito do LimitRequestBody?**  
Desde o Apache 2.4.54, o valor por defeito é 1 GiB; na versão 2.4.53 e anteriores era ilimitado. Defina o valor de acordo com o post_max_size da sua configuração PHP, para que os pedidos demasiado grandes sejam rejeitados logo no servidor web.

## Fontes

- [Apache: funcionalidades centrais (core)](https://httpd.apache.org/docs/2.4/mod/core.html)
- [Apache: mod_proxy_fcgi](https://httpd.apache.org/docs/2.4/mod/mod_proxy_fcgi.html)
- [Apache: mod_headers](https://httpd.apache.org/docs/2.4/mod/mod_headers.html)
- [php.net: comunicados de segurança](https://www.php.net/)