1 05/11/2026 9 min

Su Ubuntu 20.04 Nmap resta uno degli strumenti più pratici per capire che cosa espone davvero un host: porte aperte, servizi associati, versione del software e, quando serve, qualche indizio in più sul fingerprint del sistema. Il punto non è “lanciare una scansione” e basta, ma scegliere il tipo di verifica giusto, leggere l’output senza sovrainterpretarlo e usare il risultato per decidere il passo successivo: hardening, troubleshooting o validazione di un cambio.

Su una macchina Ubuntu 20.04 la procedura è semplice, ma va trattata con criterio. Una scansione fatta male può produrre falsi positivi, far scattare allarmi IDS/IPS, saturare temporaneamente un servizio fragile o, peggio, essere letta come attività ostile se eseguita fuori contesto. Per questo conviene partire da una distinzione netta: stai verificando la tua infrastruttura, un ambiente di laboratorio o un sistema di terzi per cui hai autorizzazione esplicita? Se la risposta non è chiara, fermati lì.

Installazione di Nmap su Ubuntu 20.04

Il pacchetto è nei repository standard. L’installazione non richiede repository esterni e, in generale, è la scelta corretta per un uso operativo normale. Dopo l’installazione conviene verificare la versione, perché l’output e alcune opzioni cambiano nel tempo.

sudo apt update
sudo apt install nmap
nmap --version

Il controllo atteso è vedere il binario disponibile e una versione coerente con i pacchetti di Ubuntu 20.04. Se il comando non viene trovato, il problema è quasi sempre banale: repository non aggiornati, installazione fallita o path alterato. In quel caso, prima di fare altro, verifica con dpkg -l | grep nmap e con which nmap.

Che cosa fa davvero una scansione porte

Nmap non “vede” direttamente i servizi: deduce lo stato delle porte attraverso il comportamento della rete e delle applicazioni. Il risultato finale dipende da firewall, filtri, rate limiting, NAT, CDN, regole ACL e dalla qualità della rete tra scanner e bersaglio. Per questo due scansioni sullo stesso host possono restituire esiti diversi se cambiano il percorso o la finestra temporale.

Nel caso più semplice, una porta può risultare open, closed oppure filtered. “Open” significa che qualcuno risponde su quella porta; “closed” che la porta non è in ascolto ma l’host è raggiungibile; “filtered” che un filtro impedisce a Nmap di capire con certezza se il servizio esiste o no. Questo dettaglio è importante: “filtered” non equivale a “sicuro”, significa solo che il test non ha avuto abbastanza visibilità.

Scansione base di un host singolo

La scansione TCP più semplice usa le porte comuni di default. È il punto di partenza per capire rapidamente se HTTP, SSH, SMTP, MySQL o altri servizi sono esposti.

nmap 192.0.2.10

Di default Nmap effettua una scansione delle porte più frequenti, non di tutte le 65535. Se vuoi un quadro più completo, passa a una scansione esplicita di tutte le porte TCP:

nmap -p- 192.0.2.10

Qui il compromesso è chiaro: più copertura, più tempo. Su host con firewall o dispositivi di protezione, una scansione completa può richiedere molto di più e generare più rumore nei log. Se l’obiettivo è un controllo operativo veloce, spesso basta una lista mirata di porte note:

nmap -p 22,80,443,25,110,143,3306,5432 192.0.2.10

Questo approccio è utile quando stai verificando un set di servizi attesi e vuoi confrontare l’osservato con il baseline. Se una porta critica non compare, la domanda corretta non è “Nmap sbaglia?”, ma “dove si interrompe il flusso: host, firewall, servizio o rete?”.

Riconoscere servizi e versioni

Per andare oltre il semplice stato della porta, Nmap può tentare il riconoscimento del servizio e della versione. È una funzione molto utile, ma va interpretata con prudenza: la versione rilevata è un’indicazione, non una prova assoluta.

nmap -sV 192.0.2.10

Se vuoi una lettura più dettagliata, puoi combinare la scansione delle porte con il rilevamento della versione:

nmap -p 22,80,443 -sV 192.0.2.10

Il valore operativo sta nel confronto con l’inventario: se il server dovrebbe esporre solo SSH e HTTPS ma compare anche un servizio su 3306 o 6379, hai già un indizio concreto di esposizione eccessiva. A quel punto il passo successivo non è “chiudere tutto” a caso, ma verificare da dove arriva l’apertura: ascolto locale, bind su 0.0.0.0, regole di firewall o forwarding non intenzionale.

Scansione UDP: utile ma da usare con criterio

La scansione UDP è molto meno immediata della TCP. Molti servizi UDP non rispondono in modo esplicito, quindi il risultato tende a essere più ambiguo e più lento da ottenere. Nmap può farlo, ma non va usato come se fosse identico alla scansione TCP.

sudo nmap -sU -p 53,67,68,123 192.0.2.10

Qui il prefisso sudo è spesso necessario perché alcune modalità di scansione e alcune ottimizzazioni richiedono privilegi elevati. Se il comando sembra “bloccato”, non significa per forza che la rete sia rotta: la scansione UDP è semplicemente più lenta e meno conclusiva. In ambienti sensibili conviene limitare le porte e definire un timeout ragionevole, invece di lanciare una scansione estesa senza controllo.

Scansione della rete o del range di host

Quando l’obiettivo è capire quali host sono vivi prima di verificare le porte, Nmap può fare discovery sul segmento. Questo è utile in un inventario interno, ma va usato con attenzione perché può produrre molto traffico e attirare l’attenzione dei sistemi di sicurezza perimetrali.

nmap -sn 192.0.2.0/24

Il risultato atteso è una lista di host raggiungibili, non l’elenco delle loro porte. Se invece ti serve una scansione completa di un sottorete, puoi combinarla con la verifica delle porte, ma a quel punto il carico operativo cresce rapidamente. In produzione è più sensato lavorare per gruppi, finestre orarie e scope ben definiti, soprattutto se ci sono apparati legacy o servizi molto sensibili ai burst di connessioni.

Lettura dell’output: cosa conta davvero

Il valore dell’output non sta solo nell’elenco delle porte aperte, ma nella coerenza complessiva tra stato, servizio e contesto. Se vedi 22/tcp open ssh, la domanda non è solo “c’è SSH?”, ma “è quello previsto, è esposto all’esterno, risponde con la versione attesa, e il firewall si comporta come dovrebbe?”.

Occhio anche ai casi in cui Nmap indica service unknown o una versione poco credibile. Può dipendere da banner offuscati, proxy, honeypot, servizi custom o semplicemente da un fingerprint incompleto. Non forzare conclusioni solo perché il nome non torna: incrocia sempre con il lato server, cioè con il processo in ascolto, i log applicativi e la configurazione del firewall.

Per una lettura più pulita, è utile salvare l’output in un file e rivederlo con calma:

nmap -sV -oN scansione.txt 192.0.2.10

Il file scansione.txt è comodo per archiviazione e confronto nel tempo. Se vuoi un formato più adatto a elaborazioni successive, puoi usare l’XML:

nmap -sV -oX scansione.xml 192.0.2.10

Permessi, privilegi e modalità di esecuzione

Molte opzioni di Nmap funzionano meglio con privilegi elevati, ma questo non significa che si debba lavorare sempre come root. La regola pratica è semplice: usa i privilegi minimi necessari per il tipo di scansione richiesto. Se stai facendo un controllo base su porte TCP, spesso non serve esagerare; se invece usi modalità che richiedono raw socket o scansioni più avanzate, i privilegi diventano necessari.

In ogni caso, la precauzione operativa è la stessa: esegui la scansione da una macchina affidabile, con un account tracciabile e in un contesto autorizzato. In ambienti aziendali conviene anche annotare data, host sorgente, target e obiettivo del test. Non è burocrazia: è il modo più rapido per distinguere un controllo legittimo da un evento sospetto nei log di sicurezza.

Modalità più utili in pratica

Nel lavoro quotidiano, poche opzioni coprono gran parte dei casi reali. La scansione di default, il rilevamento della versione e la scansione completa delle porte sono i tre strumenti da tenere davvero a portata. Il resto serve quando hai un obiettivo preciso: tempi, fingerprinting più spinto, controllo UDP o test su range di host.

  • Controllo rapido: nmap 192.0.2.10 per un primo quadro.
  • Verifica completa: nmap -p- 192.0.2.10 per non lasciare fuori porte non standard.
  • Inventario servizi: nmap -sV 192.0.2.10 per associare porte e versioni.
  • Discovery host: nmap -sn 192.0.2.0/24 per capire chi risponde.
  • UDP mirato: sudo nmap -sU -p 53,123 192.0.2.10 per servizi specifici.

La scelta corretta dipende dall’obiettivo, non dall’abitudine. Se ti interessa la sicurezza, la scansione “più aggressiva” non è automaticamente la migliore: spesso è solo quella che produce più rumore e meno segnali utili.

Interpretare i falsi positivi e i falsi negativi

Un falso positivo tipico è vedere un servizio che in realtà non è quello atteso, magari per via di un proxy, di un banner generico o di un fingerprint incompleto. Un falso negativo, invece, capita quando un firewall filtra in modo selettivo, quando la rete introduce perdita o quando il servizio risponde solo a determinate condizioni. In entrambi i casi, la contromisura è la stessa: non fermarti al singolo output.

Il confronto più utile è tra tre livelli: ciò che Nmap dice, ciò che il sistema ascolta davvero sul server e ciò che il firewall permette in ingresso. Se questi tre livelli non coincidono, hai già un problema di configurazione o di visibilità. La scansione, in questo senso, è uno strumento di verifica incrociata, non un oracolo.

Uso sicuro in ambienti di produzione

In produzione conviene partire sempre dal presupposto che il target sia sensibile. Anche una scansione lecita può generare alert o piccoli disservizi su apparati fragili. Per questo è buona pratica limitare lo scope, definire finestre di esecuzione, evitare scansioni massive senza necessità e condividere l’attività con chi gestisce sicurezza e operations.

Se stai verificando la superficie esposta di un server Ubuntu 20.04, il flusso più robusto è semplice: prima osservi, poi confronti, infine correggi. Se una porta inattesa risulta aperta, il passo successivo è capire se il problema sta nell’applicazione, nel servizio di sistema, nel firewall locale o in un’esposizione a monte. La scansione ti dice dove guardare; il resto lo fai con log, configurazioni e test mirati.

Un esempio operativo completo

Supponiamo di dover controllare un server web che dovrebbe esporre solo SSH e HTTPS. La sequenza sensata è questa: prima una scansione breve, poi una verifica completa delle porte TCP, quindi il rilevamento dei servizi sulle porte trovate. Se compare una porta inattesa, ad esempio 8080 o 3306, si passa a controllare il processo in ascolto e le regole di rete.

nmap 192.0.2.10
nmap -p- 192.0.2.10
nmap -sV -p 22,443,8080,3306 192.0.2.10

Il risultato utile non è solo “cosa è aperto”, ma la discrepanza tra ciò che dovrebbe esserlo e ciò che lo è davvero. È lì che Nmap diventa uno strumento di sicurezza concreto, non un semplice scanner di porte.

Se vuoi rendere il controllo ripetibile, conserva sempre il contesto: IP o nome host, data, opzioni usate, motivo della scansione e risultato finale. In questo modo puoi confrontare esecuzioni diverse e capire se un cambiamento di superficie esposta dipende da un deploy, da un firewall o da una modifica di rete. È il modo migliore per trasformare una scansione in un dato operativo, non in uno screenshot isolato.