# Sinal de alerta: o servidor web inicia uma shell

> O PHP-FPM ou o Apache inicia uma shell? Como ler a árvore de processos, separar casos inofensivos de vestígios de intrusão e vigiar o padrão de forma duradoura.

Fonte: https://phpsos.de/pt/blog/webserver-startet-shell/  
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:** Quando o PHP-FPM, o Apache ou outro processo do servidor web inicia uma shell como `sh` ou `bash`, é um dos sinais de alerta mais fortes de uma intrusão através do site. Verifique a árvore de processos, a linha de comandos e o diretório de trabalho da shell antes de terminar o que quer que seja. Algumas shells breves isoladas podem ser legítimas; shells de longa duração com ferramentas de rede quase nunca o são.

## Porque é que este padrão diz tanto

Um servidor web responde a pedidos. O PHP-FPM, o gestor de processos que executa scripts PHP para o servidor web, normalmente não inicia para isso outros programas. Uma shell sob o servidor web significa que o código PHP chamou deliberadamente um programa. Ou a aplicação o faz de propósito, ou alguém introduziu código.

Para o PHP2Shell não existem Indicators of Compromise publicados e confirmados, ou seja, nenhuma lista de características fixas de deteção. A deteção assenta no comportamento. Segundo os relatos de que dispomos, processos do servidor web ou do PHP-FPM que iniciam uma shell estão entre os sinais de alerta gerais mais fortes. Isto vale para qualquer vulnerabilidade através da qual atacantes executam código no servidor. Uma visão geral de outros indícios é dada por [Já fui comprometido?](https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/).

Porque é que a shell é tão importante para um atacante? Com uma vulnerabilidade, ele só consegue inicialmente emitir comandos isolados através do processo PHP. Uma shell transforma isso num posto de trabalho cómodo: pode explorar o sistema, carregar ferramentas, ler credenciais de ficheiros de configuração e instalar-se de forma duradoura. Quem reconhece a shell reconhece assim muitas vezes o atacante no momento em que passa do primeiro acesso ao verdadeiro objetivo.

## PHP-FPM inicia bash: ler a árvore de processos

Cada processo em Linux tem um processo pai. A questão é se uma shell corre como filha de um processo do servidor web. Os comandos seguintes só leem:

```bash
# Árvore de processos com utilizador, PID do pai e hora de arranque
ps -eo user,pid,ppid,lstart,cmd --forest | grep -B2 -A4 -E "[p]hp-fpm|[a]pache2|[h]ttpd|[l]sphp"

# Shells que correm sob utilizadores típicos do servidor web
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) " | grep -E "[ /](ba|da)?sh( |$)"

# Árvore a partir do processo PHP-FPM mais antigo
pstree -alp "$(pgrep -o php-fpm)"
```

Se encontrou uma shell suspeita, as entradas em `/proc` fornecem mais indicações, também apenas de leitura:

```bash
PID=12345   # PID da shell suspeita
tr '\0' ' ' < /proc/$PID/cmdline; echo        # linha de comandos completa
ls -l /proc/$PID/cwd /proc/$PID/exe            # diretório de trabalho e ficheiro do programa
ls -l /proc/$PID/fd 2>/dev/null | grep socket  # ligações de rede abertas
```

Os nomes dos processos no Debian e no Ubuntu são muitas vezes `php8.3-fpm` ou semelhantes; adapte os padrões de pesquisa. Diretórios de trabalho em `/tmp`, `/dev/shm` ou em pastas de upload são um sinal claro.

## Exceções legítimas e verdadeiros sinais de alerta

Algumas aplicações chamam programas através do PHP. Nisso pode surgir brevemente uma shell, por exemplo quando o PHP entrega correio através de `sendmail_path` ou uma aplicação processa imagens com uma ferramenta externa. Tais shells vivem apenas segundos e chamam sempre o mesmo programa. Documente uma vez, de forma limpa, estes casos esperados; assim, qualquer desvio salta logo à vista, em vez de se perder numa enxurrada de mensagens conhecidas.

| Observação | Mais provavelmente inofensivo se | Suspeito se |
|---|---|---|
| Shell breve sob o PHP-FPM | iniciar um programa conhecido da aplicação | o destino e a finalidade forem pouco claros |
| Shell de longa duração | nunca | correr durante minutos ou horas |
| Ferramentas de rede como processo filho | consulta conhecida de atualização ou API da aplicação | se seguirem downloads para diretórios temporários |
| Diretório de trabalho | pasta do projeto da aplicação | `/tmp`, `/dev/shm`, pasta de upload |
| Momento | coincide com uma ação conhecida, como o envio de correio | de noite, sem atividade de utilizadores, de forma repetida |

Se não souber se a sua aplicação chama programas, pergunte ao programador ou procure no código funções como `exec`, `shell_exec`, `system`, `passthru`, `proc_open` e `popen`. Resultados no código próprio são normais, resultados em ficheiros desconhecidos não.

## Vigiar de forma duradoura em vez de olhar uma vez

Um instantâneo com `ps` só apanha shells que estão a correr nesse momento. Os processos de vida curta escapam. É mais fiável registar de forma duradoura os arranques de programas pelo utilizador do servidor web. Em Linux, isso é feito pelo serviço de auditoria auditd, com uma regra para arranques de programas do utilizador do servidor web. A avaliação faz-se em leitura:

```bash
# Mostrar arranques de programas registados sob uma chave de regra (chave como exemplo)
sudo ausearch -k web_exec --start today -i | grep -E "exe=|proctitle="
```

O aspeto da regra depende da distribuição e do ID de utilizador; teste-a primeiro, porque em servidores muito carregados surgem muitas entradas.

Dois complementos tornam a vigilância sólida. Primeiro, os registos devem seguir também para um sistema central, porque um atacante com direitos de root pode apagar registos locais. Segundo, é preciso um alarme: um arranque de programa do utilizador do servidor web que não conste de uma lista curta de programas esperados deve desencadear um aviso, não apenas uma entrada de registo. Quem já usa uma solução de deteção em terminais ou servidores pode reproduzir lá a mesma regra. Como prevenção, com `disable_functions` pode bloquear-se o que a aplicação não precisa. Isso não fecha nenhuma vulnerabilidade no interpretador, mas dificulta o passo seguinte de um atacante. Os pormenores estão em [Usar o disable_functions corretamente](https://phpsos.de/pt/ratgeber/disable-functions/).

## O que fazer se encontrar uma shell sob o servidor web

1. **Documentar:** guardar o resultado do `ps`, a linha de comandos, o diretório de trabalho e as ligações abertas num ficheiro fora do diretório web.
2. **Não limpar:** não apagar ficheiros nem terminar processos antes de os vestígios estarem guardados.
3. **Isolar:** retirar o servidor da rede ou restringir fortemente o acesso.
4. **Procurar a causa:** verificar registos, novos ficheiros e persistência como tarefas cron, ver [Encontrar processos suspeitos em servidores Linux](https://phpsos.de/pt/blog/verdaechtige-prozesse-linux/).
5. **Mudar os acessos:** todas as palavras-passe e chaves que estavam no servidor devem considerar-se conhecidas.

Se a aplicação corre em contentores, vale o mesmo princípio em ponto pequeno. Uma shell no contentor PHP é tão suspeita como num servidor clássico, e as imagens de contentor contêm-na muitas vezes apenas porque a imagem base a traz. Antes de reiniciar o contentor, guarde o seu estado, porque com o contentor desaparecem também os vestígios no sistema de ficheiros volátil.

Verifique também a vizinhança. Um atacante com uma shell num servidor web tenta muitas vezes, a partir daí, alcançar outros sistemas, como a base de dados, o armazenamento de cópias de segurança ou interfaces de administração internas. As credenciais em ficheiros de configuração da aplicação facilitam-lhe isso.

> **Agir de imediato:**
> Uma shell de longa duração sob o PHP-FPM num servidor com dados de clientes é um incidente de segurança. Trate-a como tal: guardar, isolar, tratar de forma estruturada, mandar verificar as obrigações de notificação.

## Como ajuda concretamente a PHP SOS?

- **Enquadrar o resultado:** verificamos a árvore de processos, as linhas de comandos e as ligações e separamos o comportamento da aplicação de vestígios de intrusão.
- **Preservar vestígios:** guardamos o estado do sistema de forma rastreável antes de alterar o que quer que seja.
- **Tratar o incidente:** com a [resposta a incidentes](https://phpsos.de/pt/leistungen/incident-response/), conduzimos da contenção até à conclusão documentada.
- **Proteger de forma duradoura:** configuramos o registo de arranques de programas e limitamos as funções PHP ao necessário. Como o PHP-FPM funciona internamente explica-o [PHP-FPM explicado](https://phpsos.de/pt/php/php-fpm-erklaert/).


## Perguntas frequentes

**Toda a shell sob o PHP-FPM é um ataque?**  
Nem toda. Algumas aplicações chamam deliberadamente programas através do PHP, por exemplo para tratamento de imagens ou envio de correio, e nisso pode surgir brevemente uma shell. Torna-se suspeito quando a shell corre durante mais tempo, inicia ferramentas de rede ou trabalha a partir de diretórios invulgares.

**Devo terminar logo o processo suspeito?**  
Primeiro documentar, depois agir. Registe os dados do processo, a linha de comandos, o diretório de trabalho e as ligações de rede. Depois isole o servidor. Terminá-lo precipitadamente destrói vestígios e não impede que o atacante volte.

**Existem indicadores de deteção confirmados para o PHP2Shell?**  
Não. Não há Indicators of Compromise publicados e confirmados. As shells sob o servidor web são um sinal de alerta geral de intrusões através de aplicações web, não específico do PHP2Shell.

**Como impeço que o PHP chegue a iniciar shells?**  
Através de disable_functions podem bloquear-se funções como exec, shell_exec, system e proc_open, se a aplicação não precisar delas. Isto não fecha nenhuma vulnerabilidade no interpretador PHP, mas dificulta a exploração.

## Fontes

- [BSI: Agência Federal Alemã para a Segurança da Informação](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: avisos de segurança](https://www.php.net/)