# Verificare le connessioni in uscita di un server

> Connessioni in uscita di un server: associare i processi con ss e lsof, valutare le destinazioni sconosciute e limitare la fuga di dati con un filtro.

Fonte: https://phpsos.de/it/blog/ausgehende-verbindungen-pruefen/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**In breve:** le connessioni in uscita di un server si verificano con `ss -tunap` o `lsof -i`, che associano ogni connessione a un processo. Sono normali le connessioni a database, server di posta, server di aggiornamento e interfacce note. Connessioni di processi PHP o del server web verso destinazioni sconosciute, porte insolite e connessioni permanenti senza motivo sono segnali d'allarme di controllo remoto o fuga di dati. Nel tempo aiuta un filtro in uscita che consente solo le destinazioni necessarie.

## Perché guardare verso l'esterno rivela così tanto

Nella ricerca di un'intrusione i più guardano i file. Ma un aggressore vuole fare qualcosa con il proprio accesso: scaricare strumenti, ricevere comandi, far uscire dati o usare il server per spam o per attacchi ad altri. Tutto ciò richiede connessioni verso l'esterno.

Un server web stabilisce da sé poche connessioni, e la maggior parte è prevedibile: interroga il database, consegna e-mail, richiama interfacce di pagamento o spedizione e scarica aggiornamenti. Per questo le connessioni estranee qui spiccano in modo particolare. Secondo i rapporti di cui disponiamo, le connessioni in uscita rientrano tra i segnali d'allarme generali dopo un'intrusione; non esistono Indicators of Compromise confermati specifici per PHP2Shell. Altri segni li riassume [Sono già compromesso?](https://phpsos.de/it/php2shell/bin-ich-gehackt-anzeichen/).

## Elencare le connessioni in uscita e associarle ai processi

I comandi seguenti leggono soltanto. Li esegua come root, altrimenti mancano le indicazioni sui processi.

```bash
# Tutte le connessioni TCP stabilite con processo
ss -tnp state established

# TCP e UDP inclusi i servizi in ascolto
ss -tunap

# Connessioni per programma e utente, senza risoluzione dei nomi
lsof -i -n -P | grep -v LISTEN

# Solo connessioni dei processi degli utenti del server web
lsof -i -n -P -u www-data 2>/dev/null
```

Nell'output faccia attenzione a tre colonne: il processo, l'indirizzo di destinazione con la porta e l'utente. Una connessione di `php-fpm` al database sulla porta 3306 è normale. Una connessione di un programma con nome sconosciuto da `/tmp` a un indirizzo estraneo su una porta insolita non lo è. Sotto quale utente giri PHP dipende da distribuzione e pannello.

## Normale o sospetto? Un inquadramento

| Osservazione | Piuttosto normale | Piuttosto sospetto |
|---|---|---|
| Destinazione | database proprio, server di posta, API note, server di aggiornamento | indirizzi sconosciuti senza relazione con l'applicazione |
| Processo | php-fpm, server web, servizi di posta e aggiornamento | programmi sconosciuti, processi da `/tmp` o `/dev/shm` |
| Porta | 443, 3306, 5432, 587 | porte alte insolite, porte tipiche di IRC |
| Durata | breve, in linea con le richieste | permanentemente aperta, anche di notte senza visitatori |
| Quantità | ridotta e uniforme | picchi improvvisi nel volume di dati in uscita |
| Traffico e-mail | invio tramite il server di posta previsto | molte connessioni dirette sulla porta 25 |

Molte connessioni sulla porta 25 indicano invio di spam; c'è un articolo apposito, [Il server invia spam](https://phpsos.de/it/blog/server-verschickt-spam/).

## Valutare una destinazione sconosciuta

Un indirizzo estraneo nell'elenco non è ancora una prova. Prima di decidere, chiarisca dove porti la connessione e chi l'abbia stabilita. Anche questi passaggi non modificano nulla:

1. **Determinare il processo:** prendere il PID da `ss` e verificare con `ls -l /proc/PID/exe` e la riga di comando quale programma ci sia dietro.
2. **Cercare la destinazione:** con `dig -x <IP>` determinare il nome e con `whois <IP>` l'operatore di rete.
3. **Confrontare con l'applicazione:** chieda a sviluppatori o fornitori se la Sua applicazione usi questo servizio.
4. **Verificare lo storico:** i log del firewall e di rete mostrano da quando esiste la connessione e quanti dati sono passati.
5. **Conservare i risultati:** salvare gli output con l'ora prima di terminare o bloccare qualcosa.

Metta in conto risultati ambigui. Molti servizi legittimi girano presso grandi fornitori cloud e CDN, i cui indirizzi non permettono di risalire al cliente. Al contrario, anche gli aggressori usano server cloud in affitto. Un operatore di rete noto non è quindi né cessato allarme né prova; decisivo è se processo e scopo corrispondano alla Sua applicazione.

Un'istantanea con `ss` mostra solo ciò che è aperto in quel momento. Le connessioni brevi stabilite al minuto le vede solo nei log. Per questo i log del firewall o di flusso sono spesso più importanti dello sguardo al server stesso per la domanda su una fuga di dati.

> **Importante:**
> Se dei dati possono aver lasciato il Suo server e sono coinvolti dati personali, può sussistere un obbligo di notifica ai sensi del GDPR, di norma entro 72 ore. Lo chiarisca presto con il Suo responsabile della protezione dei dati; il contesto è in [Obbligo di notifica GDPR in 72 ore](https://phpsos.de/it/compliance/dsgvo-meldepflicht-72-stunden/). Questa non è consulenza legale.

## Non dimenticare DNS e container

Non ogni fuga di dati richiede una connessione visibile verso un indirizzo estraneo. Le risoluzioni di nomi via DNS vanno al resolver del Suo data center e nell'elenco di `ss` non spiccano quasi. Gli aggressori possono impacchettare dati in sottodomini lunghi dall'aspetto casuale e farli così uscire con richieste DNS. Indizi in tal senso li forniscono i log del resolver: un numero insolitamente alto di richieste allo stesso dominio estraneo, nomi molto lunghi o richieste in orari in cui nessuno usa il sito.

Se le Sue applicazioni girano in container, l'host vede spesso le connessioni dei container solo come traffico della rete dei container. Verifichi allora in ogni container singolarmente, se gli strumenti vi sono presenti, oppure valuti le connessioni a livello di host e firewall.

```bash
# Connessioni all'interno di un container (se ss è contenuto nell'immagine)
docker exec <container> ss -tnp 2>/dev/null

# Sull'host: connessioni tracciate dal kernel, se conntrack è installato
sudo conntrack -L 2>/dev/null | head -50
```

## Limitare il traffico in uscita nel tempo

La prevenzione più efficace è un filtro in uscita: il server può raggiungere solo le destinazioni di cui ha davvero bisogno, tutto il resto viene bloccato e registrato. Per gli aggressori diventa così nettamente più difficile scaricare strumenti o sottrarre dati, anche se possono eseguire codice.

La strada comincia con un elenco delle destinazioni necessarie, che ricava dalle connessioni raccolte sopra. Segue una fase in cui le connessioni bloccate vengono solo registrate, prima di attivare il blocco effettivo. Servizi di pagamento, server di aggiornamento e interfacce con indirizzi variabili richiedono in questo particolare cura. Come si costruisce nel complesso un firewall per server web lo descrive [Firewall per server web: aprire solo le porte necessarie](https://phpsos.de/it/blog/firewall-fuer-webserver/).

## Come aiuta concretamente PHP SOS?

- **Verificare le connessioni:** associamo tutte le connessioni attive a processi e scopi e valutiamo le destinazioni sconosciute.
- **Valutare la fuga di dati:** valutiamo i log del firewall e di rete e chiariamo se e quando siano stati trasmessi dati.
- **Limitare l'uscita:** elaboriamo con Lei un elenco di destinazioni consentite e configuriamo il filtro in uscita per gradi.
- **Monitorare nel tempo:** con il [monitoraggio della sicurezza](https://phpsos.de/it/leistungen/security-monitoring/) segnaliamo connessioni nuove o insolite.


## Domande frequenti

**Quali connessioni in uscita sono normali per un server web?**  
Tipiche sono connessioni al database, al server di posta, a servizi di pagamento e spedizione, a server di aggiornamento e a interfacce note dell'applicazione. Tutto ciò che non si può ricondurre a uno di questi scopi merita uno sguardo più attento.

**Come vedo quale processo ha stabilito una connessione?**  
Con ss -tunap o lsof -i -n -P come root. Entrambi mostrano per ogni connessione l'ID del processo e il nome del programma. Così riconosce se la connessione proviene da PHP, dal server web o da un programma estraneo.

**Una connessione sconosciuta significa che sono usciti dei dati?**  
Non necessariamente. È però un indizio che va chiarito. Se e quali dati siano stati trasmessi spesso si può stabilire solo con i log del firewall o di rete. Se sono coinvolti dati personali, possono sussistere obblighi di notifica.

**Un server web dovrebbe poter stabilire connessioni in uscita?**  
Solo verso le destinazioni di cui ha bisogno. Un filtro in uscita che blocca tutto il resto rende molto più difficile agli aggressori scaricare strumenti e far uscire dati. Va però testato con cura.

## Fonti

- [BSI: Ufficio federale tedesco per la sicurezza informatica](https://www.bsi.bund.de/)
- [GDPR art. 33: notifica all'autorità di controllo](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)