# Verificar as ligações de saída de um servidor

> Verificar as ligações de saída de um servidor: associar processos com ss e lsof, avaliar destinos desconhecidos e limitar a fuga de dados com um filtro de saída.

Fonte: https://phpsos.de/pt/blog/ausgehende-verbindungen-pruefen/  
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:** As ligações de saída de um servidor verifica-as com `ss -tunap` ou `lsof -i`, que associam cada ligação a um processo. São normais ligações à base de dados, ao servidor de correio, a servidores de atualização e a interfaces conhecidas. Ligações de processos PHP ou do servidor web a destinos desconhecidos, portas invulgares e ligações permanentes sem motivo são sinais de alerta de controlo remoto ou fuga de dados. A longo prazo ajuda uma filtragem de saída que só permita os destinos necessários.

## Porque é que olhar para fora revela tanto

Na procura de uma intrusão, a maioria olha para ficheiros. Mas um atacante quer fazer algo com o seu acesso: carregar ferramentas, receber comandos, levar dados ou usar o servidor para spam ou ataques a terceiros. Tudo isso precisa de ligações para fora.

Um servidor web só estabelece por si poucas ligações, e a maioria é previsível: consulta a base de dados, entrega correio, chama interfaces de pagamento ou de expedição e obtém atualizações. Por isso, ligações estranhas aqui dão particularmente nas vistas. Segundo os relatos de que dispomos, as ligações de saída estão entre os sinais de alerta gerais após uma intrusão; não existem Indicators of Compromise confirmados especificamente para o PHP2Shell. Outros indícios resume-os [Já fui comprometido?](https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/).

## Listar as ligações de saída e associá-las a processos

Os comandos seguintes só leem. Execute-os como root, caso contrário faltam as indicações de processo.

```bash
# Todas as ligações TCP estabelecidas com processo
ss -tnp state established

# TCP e UDP incluindo serviços à escuta
ss -tunap

# Ligações por programa e utilizador, sem resolução de nomes
lsof -i -n -P | grep -v LISTEN

# Apenas ligações de processos dos utilizadores do servidor web
lsof -i -n -P -u www-data 2>/dev/null
```

No resultado, atenção a três colunas: o processo, o endereço de destino com porta e o utilizador. Uma ligação do `php-fpm` à base de dados na porta 3306 é normal. Uma ligação de um programa de nome desconhecido em `/tmp` a um endereço estranho numa porta invulgar não é. Sob que utilizador o PHP corre depende da distribuição e do painel.

## Normal ou suspeito? Um enquadramento

| Observação | Mais provavelmente normal | Mais provavelmente suspeito |
|---|---|---|
| Destino | base de dados própria, servidor de correio, APIs conhecidas, servidores de atualização | endereços desconhecidos sem relação com a aplicação |
| Processo | php-fpm, servidor web, serviços de correio e de atualização | programas desconhecidos, processos de `/tmp` ou `/dev/shm` |
| Porta | 443, 3306, 5432, 587 | portas altas invulgares, portas típicas de IRC |
| Duração | curta, coerente com pedidos | permanentemente aberta, também de noite sem visitantes |
| Volume | baixo e regular | picos súbitos no volume de dados de saída |
| Tráfego de correio | envio através do servidor de correio previsto | muitas ligações diretas na porta 25 |

Muitas ligações na porta 25 indicam envio de spam; sobre isso há um artigo próprio, [O servidor envia spam](https://phpsos.de/pt/blog/server-verschickt-spam/).

## Avaliar um destino desconhecido

Um endereço estranho na lista ainda não é prova. Antes de decidir, esclareça para onde leva a ligação e quem a estabeleceu. Também estes passos não alteram nada:

1. **Determinar o processo:** tirar o PID do `ss` e verificar com `ls -l /proc/PID/exe` e a linha de comandos que programa está por trás.
2. **Consultar o destino:** com `dig -x <IP>` obter o nome e com `whois <IP>` o operador de rede.
3. **Comparar com a aplicação:** perguntar a programadores ou prestadores se a sua aplicação usa este serviço.
4. **Verificar o histórico:** os registos da firewall e da rede mostram desde quando a ligação existe e quantos dados fluíram.
5. **Guardar os resultados:** guardar os resultados com hora antes de terminar ou bloquear algo.

Conte com resultados ambíguos. Muitos serviços legítimos correm em grandes fornecedores de cloud e CDN, cujos endereços não permitem concluir quem é o cliente. Inversamente, também os atacantes usam servidores cloud alugados. Um operador de rede conhecido não é por isso nem um alívio nem uma prova; o decisivo é se o processo e a finalidade se adequam à sua aplicação.

Um instantâneo com `ss` mostra apenas o que está aberto neste momento. Ligações breves, estabelecidas ao ritmo de minutos, só as vê em registos. Por isso, os registos da firewall ou de fluxos são muitas vezes mais importantes para a questão de uma fuga de dados do que olhar para o próprio servidor.

> **Importante:**
> Se os dados podem ter saído do seu servidor e estiverem em causa dados pessoais, pode existir uma obrigação de notificação nos termos do RGPD, em regra no prazo de 72 horas. Esclareça-o cedo com o seu encarregado da proteção de dados; antecedentes em [Obrigação de notificação do RGPD em 72 horas](https://phpsos.de/pt/compliance/dsgvo-meldepflicht-72-stunden/). Isto não constitui aconselhamento jurídico.

## Não esquecer o DNS e os contentores

Nem toda a fuga de dados precisa de uma ligação visível a um endereço estranho. As resoluções de nomes por DNS vão para o resolvedor do seu centro de dados e quase não dão nas vistas na lista do `ss`. Os atacantes podem embalar dados em subdomínios longos e de aparência aleatória e assim levá-los através de pedidos DNS. Indícios disso fornecem-nos os registos do resolvedor: um número invulgarmente elevado de pedidos ao mesmo domínio estranho, nomes muito longos ou pedidos em horas em que ninguém usa o site.

Se as suas aplicações correm em contentores, o anfitrião vê muitas vezes as ligações dos contentores apenas como tráfego da rede de contentores. Verifique então em cada contentor individualmente, na medida em que as ferramentas lá existam, ou avalie as ligações ao nível do anfitrião e da firewall.

```bash
# Ligações dentro de um contentor (se o ss estiver incluído na imagem)
docker exec <container> ss -tnp 2>/dev/null

# No anfitrião: ligações seguidas pelo kernel, se o conntrack estiver instalado
sudo conntrack -L 2>/dev/null | head -50
```

## Limitar o tráfego de saída de forma duradoura

A prevenção mais eficaz é uma filtragem de saída: o servidor só pode alcançar os destinos de que realmente precisa, tudo o resto é bloqueado e registado. Para os atacantes, torna-se assim claramente mais difícil carregar ferramentas ou extrair dados, mesmo que consigam executar código.

O caminho até lá começa com uma lista dos destinos necessários, que deriva das ligações recolhidas acima. Segue-se uma fase em que as ligações bloqueadas são apenas registadas, antes de o bloqueio ser ativado. Serviços de pagamento, servidores de atualização e interfaces com endereços variáveis exigem aqui especial cuidado. Como se constrói no seu conjunto uma firewall para servidores web descreve-o [Firewall para servidores web: abrir apenas as portas necessárias](https://phpsos.de/pt/blog/firewall-fuer-webserver/).

## Como ajuda concretamente a PHP SOS?

- **Verificar ligações:** associamos todas as ligações ativas a processos e finalidades e avaliamos destinos desconhecidos.
- **Avaliar a fuga de dados:** analisamos registos da firewall e da rede e esclarecemos se e quando foram transmitidos dados.
- **Limitar a saída:** elaboramos consigo uma lista de destinos permitidos e configuramos a filtragem de saída por etapas.
- **Vigiar de forma duradoura:** com a [monitorização de segurança](https://phpsos.de/pt/leistungen/security-monitoring/), assinalamos ligações novas ou invulgares.


## Perguntas frequentes

**Que ligações de saída são normais num servidor web?**  
São típicas ligações à base de dados, ao servidor de correio, a serviços de pagamento e de expedição, a servidores de atualização e a interfaces conhecidas da aplicação. Tudo o que não se consiga associar a nenhuma destas finalidades merece uma análise mais atenta.

**Como vejo que processo estabeleceu uma ligação?**  
Com ss -tunap ou lsof -i -n -P como root. Ambos mostram, para cada ligação, o ID do processo e o nome do programa. Assim reconhece se a ligação provém do PHP, do servidor web ou de um programa estranho.

**Uma ligação desconhecida significa que houve fuga de dados?**  
Não necessariamente. Mas é um indício que tem de ser esclarecido. Se e que dados foram transmitidos só muitas vezes se responde com registos da firewall ou da rede. Se estiverem em causa dados pessoais, podem existir obrigações de notificação.

**Deve um servidor web poder, de todo, estabelecer ligações de saída?**  
Apenas para os destinos de que precisa. Uma filtragem de saída que bloqueie tudo o resto dificulta consideravelmente aos atacantes carregar ferramentas e exfiltrar dados. Tem, porém, de ser testada com cuidado.

## Fontes

- [BSI: Agência Federal Alemã para a Segurança da Informação](https://www.bsi.bund.de/)
- [RGPD Art. 33: notificação à autoridade de controlo](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)