Porte aperte su Linux: ss, netstat, lsof e nmap

Controllare le porte aperte con ss, lo standard moderno

Ogni porta aperta su un sistema Linux esiste perché un processo ha chiesto al kernel di mettersi in ascolto su di essa. Lo strumento che oggi mostra questi socket è ss (socket statistics), parte della suite iproute2 installata in ogni distribuzione moderna. Un solo comando copre la maggior parte delle situazioni:

sudo ss -tulpn

Ogni flag svolge un compito preciso:

• -t: include i socket TCP
• -u: include i socket UDP
• -l: mostra solo i socket in ascolto (rimuovilo per vedere anche le connessioni stabilite)
• -p: mostra il processo proprietario di ogni socket; è per questo che serve sudo, perché senza vedi solo i tuoi processi
• -n: output numerico, che stampa :22 invece di :ssh ed evita le risoluzioni DNS inverse, il che rende anche il comando più rapido

Una tipica riga di output ha questo aspetto:

Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      128          0.0.0.0:22         0.0.0.0:*    users:(("sshd",pid=712,fd=3))

La colonna Local Address è quella che conta per la sicurezza. 0.0.0.0:22 significa che il socket accetta connessioni su ogni interfaccia IPv4, [::]:22 è l'equivalente IPv6 e 127.0.0.1:5432 significa che il servizio risponde solo su loopback e non è raggiungibile dalla rete.

Alcune varianti da tenere a memoria:

ss -tlnp                      # TCP listeners only
ss -ulnp                      # UDP listeners only
sudo ss -tlnp 'sport = :22'   # who is listening on port 22
ss -tn state established      # active TCP connections right now

netstat funziona ancora, ma è legacy

Milioni di tutorial continuano a indicare netstat -tulpn, e i flag corrispondono uno a uno al comando ss visto sopra, quindi la memoria muscolare si trasferisce in entrambe le direzioni. La differenza è sotto il cofano: netstat appartiene al pacchetto net-tools in modalità di sola manutenzione e legge i file di /proc, mentre ss interroga il kernel direttamente via netlink, ed è notevolmente più veloce su macchine che gestiscono migliaia di socket.

La maggior parte delle distribuzioni attuali non include più net-tools per impostazione predefinita. Se ti serve comunque:

sudo netstat -tulpn

# if the command is missing:
sudo apt install net-tools    # Debian / Ubuntu
sudo dnf install net-tools    # RHEL / Fedora

Non c'è motivo di installarlo su un server nuovo. Considera netstat un ripiego di compatibilità per i sistemi più vecchi che erediti e usa ss in tutti gli altri casi.

lsof: le porte viste dalla prospettiva dei processi

Su Linux tutto è un file, compresi i socket di rete, quindi lsof (list open files) funziona anche come ispettore di porte. Dà il meglio quando ragioni già in termini di processi anziché di porte:

sudo lsof -i -P -n                  # every process with a network socket
sudo lsof -iTCP -sTCP:LISTEN -P -n  # TCP listeners only
sudo lsof -i :443                   # everything touching port 443

-P e -n disabilitano la risoluzione dei nomi di porta e degli hostname, la stessa idea del -n in ss -tulpn. La terza forma è quella di uso quotidiano: la punti su una porta e ottieni nome del comando, PID, utente e descrittore di file in un'unica tabella leggibile. A differenza di ss, lsof elenca anche le connessioni stabilite di ogni processo accanto ai suoi listener, il che aiuta quando vuoi sapere chi sta parlando con un servizio in questo momento, non solo che il servizio esiste.

nmap: in ascolto non significa raggiungibile

Tutto quanto visto finora risponde a una domanda: cosa è in ascolto su questa macchina. Per la sicurezza conta di più un'altra domanda: cosa è effettivamente raggiungibile dall'esterno. I due elenchi coincidono raramente, perché firewall locali, filtraggio a livello di provider e bind solo su loopback creano scarti fra loro. È anche il motivo per cui scansionare se stessi da se stessi dimostra poco: nmap localhost passa dall'interfaccia di loopback, ignora completamente le regole del firewall esterno e riporta allegramente servizi che nessun attaccante potrebbe mai raggiungere.

Esegui la scansione da un'altra macchina, puntando all'IP pubblico del server:

nmap 203.0.113.10                            # top 1000 TCP ports
nmap -p- 203.0.113.10                        # all 65535 TCP ports
sudo nmap -sU --top-ports 100 203.0.113.10   # common UDP ports (slow)

nmap riporta tre stati da capire bene: open significa che un servizio ha risposto, closed significa che il pacchetto è arrivato ma nulla è in ascolto, e filtered significa che il pacchetto è stato scartato in silenzio, quasi sempre da un firewall. Una porta che ss mostra come LISTEN ma che un nmap remoto riporta come filtered è esattamente l'aspetto di un firewall che funziona. Una regola vale senza eccezioni: scansiona solo host che ti appartengono o per cui hai un'autorizzazione esplicita.

Trovare esattamente quale processo occupa una porta

Supponiamo che qualcosa occupi la porta 8080 e la tua applicazione non riesca a fare il bind. Tre strade portano al PID:

sudo ss -tlnp 'sport = :8080'
sudo lsof -i :8080
sudo fuser -v 8080/tcp

fuser è il più compatto: stampa il PID, e -v aggiunge utente e nome del comando. Può anche terminare direttamente il colpevole con fuser -k 8080/tcp, ma questo invia un segnale senza alcuna pulizia a livello di servizio, quindi trattalo come ultima risorsa. Una volta ottenuto un PID, ps -fp PID mostra la riga di comando completa e systemctl status PID ti dice quale unit systemd lo ha avviato.

Quando non hai alcuno strumento a disposizione (per esempio in un'immagine container ridotta all'osso), la tabella del kernel è sempre lì: cat /proc/net/tcp. Le porte appaiono in esadecimale (0016 è 22) e lo stato 0A significa LISTEN. Questa tabella grezza è proprio il dato che gli altri strumenti analizzano e formattano per te.

Tutto ciò che apre un socket compare in questi elenchi nello stesso modo, sia che si tratti di un database o di uno stack proxy: un inbound V2Ray, per esempio, è solo un altro listener sulla porta che hai configurato, come spiegato nella nostra guida al protocollo V2Ray.

Chiudere una porta aperta: kill o firewall

Una porta è aperta perché un processo è in ascolto, il che ti dà due leve distinte: rimuovere il listener oppure bloccare la raggiungibilità. Non sono interscambiabili e, su qualsiasi cosa importante, di solito conviene usarle entrambe.

La soluzione pulita è fermare e disabilitare il servizio proprietario del socket. Uccidere il PID sembra più rapido ma raramente regge: systemd riavvia automaticamente i servizi supervisionati e la porta è di nuovo lì prima che tu rieseguia ss. Riserva kill ai processi che hai avviato a mano. Per vedere cosa è in esecuzione e spegnere ciò che non ti serve, la nostra guida su come elencare i servizi con systemctl copre l'intero flusso di lavoro.

sudo systemctl stop cups
sudo systemctl disable cups

Il firewall gestisce la seconda leva. Su Ubuntu, autorizza SSH prima di abilitare ufw, altrimenti ti chiudi fuori dalla macchina:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Sui sistemi della famiglia RHEL, la zona predefinita di firewalld scarta già il traffico non sollecitato; rimuovi ciò che avevi aperto in precedenza con firewall-cmd --permanent --remove-port=8080/tcp seguito da firewall-cmd --reload. Una cosa che non è una soluzione: spostare un servizio su una porta non standard. Ti nasconde dalle scansioni più pigre e riduce il rumore nei log, ma nmap -p- trova la nuova porta in pochi minuti. L'oscurità non è sicurezza: chiudi la porta o mettila dietro il firewall.

Un audit delle porte in cinque minuti per un server nuovo

Al primo accesso su una macchina appena fornita, esegui l'inventario con sudo ss -tulpn. Un'installazione minimale pulita dovrebbe mostrare molto poco: sshd sulla 22 e, sulle distribuzioni che usano systemd-resolved, uno stub DNS su 127.0.0.53:53. Tutto il resto merita una spiegazione. Poi segui questa checklist:

1. Identifica ogni listener per nome del processo e PID; disabilita ogni servizio che non hai richiesto.
2. Metti in discussione ogni bind su 0.0.0.0 o [::]: database e pannelli di amministrazione vanno su 127.0.0.1, a meno che debbano davvero servire la rete.
3. Riconosci a vista le porte comuni: 22 SSH, 80/443 web, 3306 MySQL, 5432 PostgreSQL, 6379 Redis. La porta 3389 è il desktop remoto: su Linux significa che xrdp è in esecuzione, e l'esposizione e l'hardening di quella porta sono l'argomento della nostra guida alla porta RDP 3389.
4. Scansiona l'IP pubblico dalla tua macchina con nmap -p- e confronta il risultato con l'elenco di ss: ogni differenza è un firewall che fa il suo lavoro o un bind su loopback.
5. Concludi con un firewall in default-deny che consente solo le porte che hai scelto consapevolmente di esporre.

Ecco l'intera cassetta degli attrezzi, una riga per strumento:

I comandi diventano riflessi solo su una macchina dove hai root davvero e dove niente di importante può rompersi. Un VPS Linux di rdp.monster ti dà esattamente questa sandbox: accesso amministrativo completo, CPU e RAM dedicate, banda illimitata (fair-use), nessun KYC, e il server è online circa 10 secondi dopo la conferma del pagamento, abbastanza in fretta per lanciare il tuo primo ss -tulpn prima che il caffè si raffreddi.

Domande frequenti

Serve root per controllare le porte aperte su Linux?

No per elencare le porte, sì per vedere quale processo le occupa.

Qualsiasi utente può eseguire ss -tuln o leggere /proc/net/tcp, quindi l'elenco delle porte in ascolto non è mai nascosto. Il limite sta nel flag -p: senza root, ss, lsof e fuser mostrano solo i processi del tuo utente e gli altri socket appaiono con la colonna del processo vuota. Con nmap, la scansione SYN predefinita (-sS) richiede root; l'alternativa non privilegiata è la connect scan (-sT), che funziona bene ma è un po' più rumorosa.

Come verifico se una porta specifica è aperta su un server remoto?

Usa netcat: nc -zv host porta dà una risposta immediata.

nc -zv example.com 443 tenta una connessione TCP e riporta successo o fallimento senza inviare dati. Se netcat non è presente, può farlo anche Bash da solo: timeout 3 bash -c '</dev/tcp/example.com/443' && echo open. Entrambi provano soltanto che qualcosa ha accettato la connessione: non dicono nulla su quale servizio abbia risposto né sul suo stato di salute. Per UDP non esiste un test rapido affidabile, perché una porta silenziosa può essere aperta o filtrata; usa nmap -sU in quel caso.

Perché ss mostra una porta in ascolto ma non riesco a connettermi dall'esterno?

Il socket è associato al loopback oppure un firewall scarta il traffico.

Controlla prima la colonna Local Address: 127.0.0.1:PORT o [::1]:PORT significa che il servizio accetta solo connessioni locali, scelta deliberata e comune per i database. Se è associato a 0.0.0.0, i pacchetti vengono filtrati da qualche parte sul percorso: un firewall locale come ufw, firewalld o nftables puro, oppure il filtraggio di bordo del tuo provider. Una scansione nmap esterna che riporta la porta come filtered conferma un firewall; closed significa che il traffico arriva ma nulla è in ascolto su quell'interfaccia.

Quali porte dovrebbero essere aperte su un server Linux nuovo?

Una: SSH. Tutto il resto, su un'installazione pulita, merita una spiegazione.

Un'installazione minimale di Debian, Ubuntu o Rocky dovrebbe esporre alla rete solo sshd sulla porta 22. Un resolver DNS stub su 127.0.0.53:53 (systemd-resolved) è normale e non raggiungibile dall'esterno. Le immagini cloud a volte aggiungono un agent o un demone di monitoraggio: identifica ogni listener con ss -tulpn e disabilita tutto ciò che non hai richiesto. Ogni servizio che installi in seguito dovrebbe restare su loopback per impostazione predefinita, a meno che debba davvero servire la rete, con il firewall che consente solo ciò che è pubblico.