Em resumo: um inventário de TI de servidores web é uma lista de todos os sites, portais, lojas e servidores com os dados de que se precisa de imediato perante um alerta de segurança: onde corre, com que versão e modo de operação do PHP, que aplicação, quem é o responsável e que dados seriam afetados. Sem esta lista, qualquer reação começa por procurar. Com ela, a comparação perante um alerta como o PHP2Shell demora minutos em vez de dias.
A primeira pergunta foi: onde é que, na nossa empresa, corre PHP?
Quando o projeto PHP publicou os patches a 21/10/2026 e o BSI (Gabinete Federal Alemão para a Segurança da Informação) recomendou agir de imediato, a instrução era clara: atualizar o PHP, reiniciar todos os processos. Para muitas empresas, o primeiro passo não foi, ainda assim, a atualização, mas um inventário. O site principal era conhecido. Mas o portal de revendedores? A página de carreiras num outro fornecedor? A página de destino de uma campanha de há três anos? A wiki interna?
A imprensa especializada e os serviços de medição tornaram visível a dimensão do problema. A Palo Alto Networks (Unit 42) contou mais de 22,6 milhões de instâncias expostas e potencialmente vulneráveis. Entre elas haverá muitos sistemas em que os próprios operadores simplesmente já não pensam.
O que deve constar de um inventário de TI de servidores web
Um inventário útil é uma tabela com uma linha por site ou aplicação. Estas colunas revelaram-se eficazes:
| Coluna | Exemplo | Para quê |
|---|---|---|
| Endereço | loja.exemplo.pt | atribuição inequívoca |
| Finalidade e importância | loja online, crítica para a faturação | priorização |
| Fornecedor de alojamento ou local | servidor gerido do fornecedor X | a quem se telefona |
| Servidor e sistema operativo | vServer, Debian | via de atualização, fontes de segurança |
| Servidor web e modo de operação do PHP | Nginx com PHP-FPM | risco, p. ex. mod_php |
| Versão do PHP e estado do pacote | 8.3, pacote com data | comparação com os alertas |
| Aplicação e versão | Shopware, plugins | alertas dos fabricantes |
| Responsável interno / externo | direção de TI / agência Y | quem age |
| Dados tratados | contas de clientes, encomendas | obrigações de notificação, urgência |
| Cópias de segurança | diárias, externas, testadas pela última vez em … | recuperação |
| Último comprovativo de patch | data e documento | prova perante terceiros |
O modo de operação merece atenção especial. No PHP2Shell, a equipa do PHP classificou o risco mais elevado no Apache com mod_php. Quem sabe que sistemas funcionam assim pode tratar deles primeiro. A coluna do estado do pacote é importante porque o número de versão apresentado, depois de backports, muitas vezes permanece igual; encontra indicações em Verificar corretamente a versão do PHP e o estado dos patches.
Encontrar sistemas esquecidos: como proceder
Os sistemas conhecidos são rapidamente registados. O verdadeiro trabalho são os desconhecidos. Estas fontes ajudam a descobri-los:
- Domínios e DNS: percorra todos os domínios da empresa e os seus subdomínios. Cada entrada que aponte para um servidor web é um candidato.
- Faturas: a contabilidade conhece cada fornecedor de alojamento, registador e fornecedor de nuvem que recebe dinheiro. Muitas vezes é a lista mais completa.
- Agências e departamentos: marketing, vendas e recursos humanos gostam de encomendar sites diretamente. Pergunte.
- Servidores conhecidos: em cada servidor, a configuração mostra que sites ele serve de facto.
- Dispositivos com interface web: NAS, routers e appliances trazem por vezes o seu próprio PHP, veja PHP em NAS, routers e appliances.
Para o passo 4, ajudam em servidores Linux alguns comandos só de leitura. Mostram os sites configurados, os serviços PHP e os pools FPM:
# Sites configurados (Apache ou Nginx)
apachectl -S 2>/dev/null
nginx -T 2>/dev/null | grep -E "^\s*server_name" | sort -u
# Serviços e processos PHP em execução
systemctl list-units --type=service | grep -iE "php|fpm|lsws|litespeed"
ps -eo user,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep | sort | uniq -c
# Pools FPM em Debian e Ubuntu
ls /etc/php/*/fpm/pool.d/ 2>/dev/null
Se num servidor correm várias versões do PHP em paralelo, cada uma tem de constar da lista. Cada uma tem de ser atualizada e reiniciada individualmente.
Registe também os sistemas que, na verdade, deviam ser desligados. São muitas vezes precisamente esses que continuam a funcionar, não são atualizados há anos e são esquecidos. Com uma entrada «desligar até …», a tarefa permanece visível.
Manter o inventário atualizado
Um inventário vale tanto quanto a sua última atualização. Três regras mantêm-no vivo. Primeira: uma pessoa é responsável e é informada de cada novo site, de cada mudança e de cada desativação, mesmo quando é uma agência a fazer o trabalho. Segunda: uma vez por trimestre, a lista é comparada com o DNS, as faturas e a configuração dos servidores. Terceira: o inventário faz parte do plano de emergência e existe também fora da própria TI, por exemplo em papel.
Para empresas com muitos sistemas distribuídos, como portais de revendedores, configuradores e acessos de fornecedores, Segurança de TI para PME e indústria descreve locais de descoberta típicos. Como integrar o inventário no plano de emergência, vê-se em Criar um plano de emergência de TI para servidores web.
Erros frequentes no inventário de servidores web
Muitos inventários existem, mas não ajudam numa emergência. As causas assemelham-se:
- Só servidores, sem sites: a lista indica máquinas, mas não que sites correm nelas nem quem responde por eles do ponto de vista funcional. Perante uma vulnerabilidade, ninguém sabe então que departamento é afetado.
- Versão em vez de estado do pacote: «PHP 8.3» diz pouco depois do PHP2Shell. Só o estado do pacote e a data mostram se a correção está incluída.
- Faltam sistemas externos: o que corre numa agência ou num serviço de plataforma é omitido, porque «aí não somos responsáveis». A responsabilidade pelos dados continua, ainda assim, dentro de casa.
- Sem interlocutores: uma entrada sem nome e número de telefone do responsável faz perder tempo numa emergência.
- Ação pontual: o inventário é criado numa semana de crise e nunca mais é aberto. Ao fim de um ano, boa parte já não está certa.
Quem evitar estes cinco pontos terá, no próximo alerta, uma lista com a qual se pode realmente trabalhar.
Como ajuda concretamente a PHP SOS?
- Registamos consigo todos os sites e servidores, incluindo os esquecidos, através do DNS, das faturas, dos prestadores de serviços e da configuração dos servidores.
- Apuramos, para cada sistema, o modo de operação, a versão do PHP e o estado efetivo do pacote.
- Priorizamos os sistemas segundo a acessibilidade, os dados e o modo de operação e indicamos onde é preciso agir primeiro.
- Onde o PHP2Shell ainda está em aberto, fechamos a vulnerabilidade através da ajuda imediata PHP2Shell e registamos o comprovativo no inventário.
Conclusão: um inventário é a medida de segurança mais discreta e, ao mesmo tempo, a mais eficaz. Quem sabe o que está a correr pode agir de imediato no próximo alerta, em vez de começar por procurar.
Perguntas frequentes
Que dados são o mínimo num inventário de servidores web?
Endereço do site, servidor ou fornecedor de alojamento, modo de operação do PHP, versão do PHP com o estado do pacote, aplicação com versão, pessoa responsável interna e externa, tipo de dados tratados e local das cópias de segurança. Com estes dados, cada novo alerta de segurança pode ser comparado rapidamente.
Como encontro sites de que ninguém já se lembra?
Por vários caminhos em simultâneo: gestão de domínios e zonas DNS, faturas de fornecedores de alojamento e de registadores, perguntas a agências e departamentos e a configuração dos servidores conhecidos. Páginas de campanhas antigas, sistemas de teste e subdomínios costumam assim aparecer.
Quem deve manter o inventário?
Uma pessoa designada, em regra na área de TI ou na direção de TI. É importante que qualquer alteração a sites e servidores seja ali comunicada, mesmo quando é um departamento ou uma agência a desencadeá-la.
Basta uma tabela ou é preciso software?
Para a maioria das PME, basta uma tabela bem mantida. Um software compensa quando muitos sistemas devem ser registados automaticamente. O que decide é a atualidade, não a ferramenta.