Come vedere le porte in ascolto con Netstat

Quando devi capire quali porte sono in ascolto su Linux, netstat è ancora uno strumento pratico: non ti dice solo quali socket sono aperti, ma spesso ti aiuta anche a collegare una porta a un processo, a un protocollo e a uno stato preciso della connessione. In troubleshooting è utile perché riduce il problema a una domanda semplice: chi sta ascoltando, su quale porta, e su quale interfaccia?

Il punto da tenere a mente è che netstat fa parte del pacchetto net-tools, ormai considerato legacy in molte distribuzioni. Non è un difetto: significa solo che, per ambienti moderni, conviene sapere anche usare ss. Però netstat resta molto diffuso, soprattutto su server vecchi, sistemi minimali, documentazione storica e script operativi che girano ancora senza problemi.

Il comando base per vedere le porte in ascolto

La forma più usata è questa:

netstat -tuln

Le opzioni fanno la differenza:

• -t mostra le connessioni TCP.
• -u mostra le connessioni UDP.
• -l limita l’output ai socket in ascolto.
• -n evita la risoluzione DNS e mostra indirizzi e porte in formato numerico.

Se vuoi una vista rapida delle porte aperte, questa è la combinazione giusta. Senza -n, netstat può provare a risolvere nomi host e servizi, rallentando l’output e introducendo ambiguità. In diagnostica conviene quasi sempre mantenere il formato numerico.

Un esempio tipico di output può essere questo:

Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN
tcp6       0      0 :::80                   :::*                    LISTEN

Qui hai già tre informazioni operative: SSH in ascolto su tutte le interfacce IPv4, MySQL limitato al loopback, e HTTP esposto anche in IPv6. È il tipo di dettaglio che ti evita errori banali, come credere che un servizio sia esposto all’esterno quando in realtà parla solo in locale.

Interpretare correttamente indirizzi e stati

La colonna Local Address è quella da leggere con più attenzione. Se vedi 0.0.0.0:porta, il servizio ascolta su tutte le interfacce IPv4. Se vedi :::porta, il servizio è in ascolto su tutte le interfacce IPv6. Se invece compare un indirizzo specifico, il demone è vincolato a quell’IP.

Questo dettaglio cambia molto in ambienti con più NIC, IP virtuali, container o binding selettivi. Un servizio che ascolta su 127.0.0.1 è raggiungibile solo localmente; uno su 192.0.2.10 risponde solo su quell’indirizzo; uno su 0.0.0.0 può essere esposto molto più di quanto il team si aspetti. In audit di base, il primo controllo è proprio questo.

La colonna State ti interessa soprattutto per TCP. In ascolto vedrai quasi sempre LISTEN. Per UDP, netstat può mostrare socket aperti anche senza uno stato equivalente, perché il modello di trasporto è diverso. Se ti aspetti una porta aperta ma non la vedi, non fermarti al solo TCP: molti servizi usano UDP, ad esempio DNS, NTP o alcune componenti VoIP.

Vedere anche il processo che usa la porta

Per collegare una porta a un processo, aggiungi -p:

sudo netstat -tulnp

Con -p netstat tenta di mostrare il nome del processo e il PID. Su Linux questo richiede spesso privilegi elevati, quindi eseguirlo con sudo è la scelta normale. Senza root, molte distribuzioni nascondono l’informazione del processo per motivi di permessi.

Un output realistico può essere questo:

tcp        0      0 0.0.0.0:443            0.0.0.0:*               LISTEN      1245/nginx: master 
tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN      2381/postgres

Questo è il passaggio che ti permette di distinguere tra una porta aperta per scelta e una porta aperta per errore. Se trovi un servizio inatteso, la domanda successiva non è “come lo chiudo subito?”, ma “è un binding voluto, un processo residuo, o un servizio dimenticato?”. Prima osserva, poi intervieni.

Filtrare per protocollo, porta o indirizzo

Netstat non è il più elegante per filtrare, ma funziona bene in molte verifiche rapide. Un caso comune è cercare una porta specifica:

sudo netstat -tulnp | grep ':80 '

Oppure puoi cercare il servizio in base al nome del processo:

sudo netstat -tulnp | grep nginx

Se vuoi vedere solo TCP o solo UDP, separa le viste. Per esempio, un server DNS può apparire “vuoto” se guardi solo TCP, ma essere perfettamente operativo su UDP 53. In diagnostica, l’errore più comune è filtrare troppo presto e concludere che un servizio non sia in ascolto.

Per una ricerca più robusta, specialmente su sistemi con molte porte, conviene combinare netstat con altri strumenti. Ad esempio, lsof -i è spesso più chiaro quando devi mappare socket e processi, mentre ss -lntup è più veloce e moderno. Netstat però resta comodo per chi ha già in testa il suo formato classico.

Capire se il servizio è esposto davvero

Vedere una porta in ascolto non significa automaticamente che sia raggiungibile dall’esterno. Ci sono almeno quattro livelli da controllare: binding del processo, firewall locale, firewall di rete, e eventuale NAT o security group. In pratica, netstat ti dice che il servizio è pronto a ricevere, non che il traffico può arrivare fino a lui.

Un esempio concreto: se un demone ascolta su 0.0.0.0:8080 ma firewalld o iptables bloccano la porta, dall’esterno vedrai timeout o rifiuti, mentre in locale la porta risulterà aperta. Per questo conviene sempre affiancare la lettura di netstat a una prova attiva, ad esempio con curl o nc.

curl -I http://127.0.0.1:8080
nc -vz 127.0.0.1 8080

Se il test locale funziona ma il servizio non è raggiungibile da remoto, il problema non è quasi mai nel socket in ascolto. A quel punto il controllo si sposta su firewall, routing, proxy inverso, load balancer o policy di sicurezza del cloud.

Netstat e systemd: controlli utili quando il servizio non compare

Se ti aspetti una porta in ascolto ma netstat non mostra nulla, il passo successivo non è cambiare configurazione alla cieca. Prima verifica lo stato del servizio gestito da systemd:

systemctl status nginx
systemctl status php-fpm
systemctl status mariadb

Se il servizio è fermo, in errore o in crash loop, netstat non potrà mostrarti alcuna porta. Guarda anche i log recenti:

journalctl -u nginx -n 50 --no-pager
journalctl -u php-fpm -n 50 --no-pager

Questa sequenza è utile perché evita una falsa attribuzione: non sempre “porta chiusa” significa “firewall”. Più spesso significa che il processo non è partito, ha fallito il bind, o è stato limitato da una configurazione errata.

Problemi tipici che netstat aiuta a smascherare

Il primo caso classico è il binding sull’IP sbagliato. Un servizio configurato per ascoltare solo su 127.0.0.1 sembra attivo, ma dall’esterno non risponde. Netstat lo mette subito in evidenza.

Il secondo caso è la porta occupata. Se un demone non parte perché un altro processo usa già la stessa porta, netstat con -p può aiutarti a identificare il conflitto. Questo succede spesso con web server, proxy, agent di monitoraggio e stack containerizzati che si sovrappongono.

Il terzo caso è la confusione tra IPv4 e IPv6. Può capitare di vedere una porta su tcp6 e credere che sia esposta solo in IPv6, quando in realtà il comportamento dipende anche dalle impostazioni del kernel e del daemon. In ambienti dual stack, conviene sempre testare entrambi i percorsi.

Un quarto caso frequente è il servizio che ascolta ma non serve traffico. Netstat ti conferma il listen socket, ma non la salute applicativa. Per esempio un database può essere in ascolto sulla porta 3306 ma rifiutare login, oppure un web server può accettare connessioni e restituire errori 502 perché il backend PHP è morto. Qui netstat è il punto di partenza, non il verdetto finale.

Quando netstat non c’è: installazione e alternative

Su molte distribuzioni moderne netstat non è installato di default. Se il comando manca, la causa è quasi sempre il pacchetto net-tools non presente nel sistema. Su Debian/Ubuntu lo installi così:

sudo apt update
sudo apt install net-tools

Su RHEL, CentOS Stream, AlmaLinux o Rocky Linux il nome del pacchetto è in genere lo stesso, ma il gestore cambia:

sudo dnf install net-tools

Se vuoi una soluzione più attuale, usa ss:

ss -tulnp

In pratica, ss è la scelta migliore per velocità e manutenzione del sistema, ma netstat resta utile quando lavori su host datati, in ambienti con documentazione preesistente o quando devi seguire una procedura già scritta con quel comando. Sapere entrambi ti evita di bloccarti per un dettaglio di tooling.

Uso operativo: checklist rapida

Se devi verificare le porte in ascolto in modo ordinato, questa sequenza funziona bene:

1. Controlla le porte aperte con sudo netstat -tulnp.
2. Individua indirizzo, porta e processo associato.
3. Verifica se il bind è su 0.0.0.0, ::, loopback o IP specifico.
4. Confronta il risultato con systemctl status e con i log del servizio.
5. Prova una connessione locale con curl, nc o telnet a seconda del protocollo.
6. Se la porta è corretta ma il servizio non è raggiungibile da fuori, controlla firewall, security group, proxy e NAT.

Questa sequenza evita il classico salto logico dal sintomo alla causa sbagliata. In particolare, non confondere la presenza di un listen socket con la disponibilità del servizio per gli utenti finali.

Un esempio pratico su un server LAMP

Su un server LAMP puoi incontrare una situazione come questa: Apache ascolta su 80 e 443, MySQL su 3306 solo in locale, e PHP-FPM non espone porte TCP perché lavora via socket Unix. Netstat aiuta a vedere subito la parte rete, ma non tutto lo stack applicativo è visibile allo stesso modo.

sudo netstat -tulnp | egrep '(:80|:443|:3306) '

Se il sito restituisce una pagina bianca, netstat può dirti che Apache è vivo e che MySQL ascolta, ma non ti dirà se PHP sta fallendo a livello di runtime o se un modulo è andato in errore. In quel caso la lettura delle porte è solo il primo filtro: poi devi passare ai log di Apache, PHP-FPM e database.

Il valore di netstat, quindi, non è “mostrare le porte” in astratto. È darti una fotografia rapida del piano di ascolto del sistema, abbastanza precisa da separare un problema di esposizione da un problema di servizio. In troubleshooting serio, questo ti fa risparmiare tempo e riduce le modifiche fatte alla cieca.