Em resumo: quem quer fazer o hardening do seu servidor para PHP assegura que uma única vulnerabilidade não abre o servidor inteiro. Separamos os sites uns dos outros, configuramos o PHP e o servidor web de forma segura, restringimos direitos e acessos e documentamos cada alteração. Assim, o dano é menor se, apesar de tudo, algo acontecer.
Porque é que o hardening se tornou mais importante depois do PHP2Shell
O PHP2Shell mostrou a rapidez com que uma vulnerabilidade no próprio PHP se torna um problema para todos os sites de um servidor. Com a CVE-2026-109618 e a CVE-2026-109619, os atacantes podem executar código sem autenticação. O patch fecha essa porta. O hardening responde a outra pergunta: o que pode fazer quem, apesar disso, entrar, por esta ou pela próxima vulnerabilidade?
Num servidor sem hardening, correm muitas vezes todos os sites com o mesmo utilizador, o PHP pode executar comandos do sistema e as credenciais estão legíveis para todos os processos. Uma intrusão num pequeno site secundário chega então até à loja online. Um bom hardening separa estas áreas. Não é uma ação única, mas um estado de base que tem de ser mantido a cada novo site e a cada mudança de versão.
Hardening de servidor para PHP: o que ajustamos concretamente
Isolamento por site
Cada site recebe o seu próprio utilizador de sistema e o seu próprio pool PHP-FPM. Com open_basedir e permissões de ficheiros adequadas, uma aplicação vê apenas o seu próprio diretório. Mais informação em open_basedir e isolamento por site.
Configuração segura do PHP
Configuramos o php.ini e a configuração do pool de modo que as aplicações não possam sobrepor, por si próprias, valores relevantes para a segurança. Um excerto de como pode ser num pool FPM:
; fixar os valores no pool FPM, não alteráveis através de ini_set()
php_admin_flag[expose_php] = off
php_admin_flag[display_errors] = off
php_admin_flag[log_errors] = on
php_admin_value[open_basedir] = /var/www/kunde1/:/tmp/
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[allow_url_include] = off
As funções que se podem bloquear adicionalmente dependem da aplicação. Indicações a esse respeito constam de Configurar o php.ini de forma segura e Usar corretamente o disable_functions.
Permissões de ficheiros e acesso de escrita
O servidor web só pode escrever onde é necessário, por exemplo na pasta de uploads. Nos diretórios de uploads, a execução de PHP é impedida. O código do programa pertence a um utilizador diferente daquele com que o PHP corre. Os princípios são explicados em Permissões de ficheiros no servidor web.
Acessos, serviços e registos
SSH apenas com chave, interfaces de administração com autenticação de dois fatores, serviços e portas desnecessários fechados. Os registos são guardados e protegidos de modo a ainda existirem após um incidente. Verificamos se as cópias de segurança são recuperáveis.
Servidor web e cabeçalhos de segurança
Também o próprio servidor web faz parte do hardening: ocultar indicações de versão, desativar listagens de diretórios, bloquear o acesso a ficheiros de configuração, de cópias de segurança e de controlo de versões e proteger adicionalmente as áreas de administração, por exemplo com autorização por IP. Os cabeçalhos de segurança, como Content-Security-Policy ou HSTS, protegem no navegador os visitantes do seu site.
O que encontramos com frequência no levantamento
Muitas vulnerabilidades repetem-se de servidor para servidor. São típicos vários sites sob um utilizador comum, interfaces de base de dados acessíveis publicamente, instalações de teste antigas em subpastas, versões do PHP esquecidas ao lado da atual e cópias de segurança que estão no diretório web e podem ser descarregadas. Falta também com frequência qualquer registo de inícios de sessão, ou os registos são apagados ao fim de poucos dias.
Nenhum destes pontos é, por si só, espetacular. Em conjunto, decidem, porém, se uma intrusão fica limitada a um site ou atinge o servidor inteiro.
Como ajuda concretamente a PHP SOS?
- Levantamento: registamos o sistema operativo, o servidor web, as versões do PHP, os sites, os utilizadores, os serviços abertos e as cópias de segurança existentes.
- Plano de medidas: recebe uma lista priorizada, com esforço e possíveis efeitos por ponto. Decide o que é executado.
- Execução por etapas: alteramos as configurações após acordo, testamos os sites após cada passo e registamos como cada alteração pode ser revertida.
- Controlo: após a execução, verificamos o efeito, por exemplo se um site já não consegue realmente ler diretórios alheios.
- Entrega: recebe uma documentação do novo estado, que também o seu fornecedor de alojamento ou a sua agência conseguem compreender.
O que recebe e o que precisamos
Recebe um relatório de hardening com a situação de partida, as medidas executadas, os pontos deliberadamente deixados em aberto com fundamentação e uma recomendação para o controlo regular. As alterações aos ficheiros de configuração ficam documentadas de forma rastreável.
De si, precisamos de:
- acesso root ou de administrador ao servidor e, no caso de painéis, também o acesso ao painel
- uma lista das aplicações e das suas particularidades, por exemplo uploads, interfaces, cronjobs
- um interlocutor técnico que possa confirmar funções após alterações
- janelas de manutenção para reinícios
- uma cópia de segurança atual ou a incumbência de criar uma antes
O que não prometemos
O hardening não torna um servidor inatacável. Reduz a superfície de ataque e limita os danos, mas não substitui nem as atualizações nem a vigilância. Uma versão do PHP sem patch continua vulnerável, por muito bem que o resto esteja configurado. Por isso, combinamos o hardening com o serviço de patches PHP e recomendamos depois um acompanhamento contínuo através de um contrato de manutenção de segurança.
Em alojamento partilhado, muita coisa não é configurável, porque o fornecedor de alojamento define a configuração. Mostramos então o que é possível no âmbito do seu pacote e onde faria sentido mudar para um servidor próprio ou gerido.
Perguntas frequentes
O que significa fazer o hardening de um servidor?
Fazer o hardening significa desligar ou restringir tudo o que não é necessário para o funcionamento. Incluem-se serviços supérfluos, direitos demasiado amplos, portas abertas e predefinições inseguras. O objetivo é que um único erro não abra logo o servidor inteiro.
O hardening teria impedido o PHP2Shell?
Não; contra uma vulnerabilidade no próprio PHP só ajuda o patch. O hardening limita, porém, o que um atacante pode alcançar após uma intrusão bem-sucedida, por exemplo se consegue aceder a outros sites ou a credenciais.
O hardening pode estragar o meu site?
O risco existe se as definições forem alteradas sem teste. Aplicamos as alterações por etapas, verificamos as funções após cada passo e registamos como cada alteração pode ser revertida.
Com que frequência se deve rever o hardening?
O mais tardar após atualizações maiores, uma mudança de versão do PHP ou novas aplicações no servidor. Faz sentido um controlo regular no âmbito da manutenção contínua.