Cosa fa#
Mappa la rete mandando pacchetti TCP/UDP/ICMP verso host e porte target e analizza le risposte. Da un singolo SYN capisce se una porta e' aperta (risposta SYN-ACK), chiusa (risposta RST) o filtrata (silenzio). Usato per asset discovery, port scanning e audit di sicurezza.
Sintassi#
nmap [opzioni] [target]
Target puo' essere: IP singolo, range (192.168.1.1-254), subnet (192.168.1.0/24), hostname.
Comandi essenziali#
| Comando | Flag | Significato flag | Cosa fa |
|---|---|---|---|
nmap 192.168.64.3 | — | — | Scan base — top 1000 porte TCP |
nmap -sS 192.168.64.3 | -sS | SYN scan | SYN scan silenzioso — non completa il handshake |
nmap -sV 192.168.64.3 | -sV | Version detection | Rileva versione del servizio in ascolto |
nmap -p 22 192.168.64.3 | -p | port | Scansiona solo la porta specificata |
nmap -p- 192.168.64.3 | -p- | all ports | Scansiona tutte le 65535 porte |
nmap -p 1-1000 192.168.64.3 | -p range | port range | Scansiona un range specifico |
nmap -T4 192.168.64.3 | -T4 | timing | Scansione piu' veloce (T0=lento, T5=aggressivo) |
nmap -O 192.168.64.3 | -O | OS detection | Tenta di rilevare il sistema operativo |
nmap -A 192.168.64.3 | -A | aggressive | OS + version + script + traceroute |
nmap -n 192.168.64.3 | -n | no DNS | Non risolve i nomi DNS — piu' veloce |
Stati delle porte#
nmap classifica ogni porta in uno di tre stati:
OPEN → ha risposto con SYN-ACK
un servizio e' in ascolto su quella porta
CLOSED → ha risposto con RST
la macchina e' raggiungibile ma nessun servizio ascolta
FILTERED → nessuna risposta (timeout)
un firewall blocca i pacchetti prima che arrivino
nmap non sa se la porta esisteDal punto di vista Blue Team:
Molte OPEN → superficie di attacco ampia
Molte CLOSED → server raggiungibile, servizi limitati
Molte FILTERED → c'e' un firewall — l'attaccante deve lavorare di piu'SYN scan — come funziona davvero#
-sS e' il default quando nmap gira con privilegi root. Non e' solo "difficile da loggare" — c'e' un motivo tecnico preciso:
Handshake completo (senza -sS):
Kali --[S]--> Ubuntu:22
Ubuntu --[S.]--> Kali
Kali --[.]--> Ubuntu ← terzo ACK completa la connessione
SSH vede la connessione
auth.log registra l'evento
SYN scan (-sS):
Kali --[S]--> Ubuntu:22
Ubuntu --[S.]--> Kali
Kali --[R]--> Ubuntu ← nmap manda RST invece di ACK
il handshake non si completa mai
SSH non viene mai coinvolto
auth.log non vede nullaIl SYN scan opera sotto il livello applicativo — tocca solo TCP, non arriva mai al servizio in ascolto.
tcpdump sul livello di rete: vede tutto ✓
auth.log, access.log: non vedono niente ✗Lezione difensiva: i log applicativi da soli non bastano per rilevare un port scan. Serve cattura a livello di rete.
Come appare in tcpdump e Wireshark#
Output tcpdump durante un nmap -sS:
# Porta aperta (22)
192.168.64.200 > 192.168.64.3.22: Flags [S] ← nmap manda SYN
192.168.64.3.22 > 192.168.64.200: Flags [S.] ← Ubuntu risponde: aperta
192.168.64.200 > 192.168.64.3.22: Flags [R] ← nmap taglia con RST
# Porta chiusa (993)
192.168.64.200 > 192.168.64.3.993: Flags [S] ← nmap manda SYN
192.168.64.3.993 > 192.168.64.200: Flags [R.] ← Ubuntu risponde: chiusaFiltro Wireshark per rilevare il scan:
tcp.flags.syn == 1 && tcp.flags.ack == 0 ← tutti i SYN di nmap
tcp.flags.syn == 1 && tcp.flags.ack == 1 ← solo porte aperte
ip.src == 192.168.64.3 && tcp.flags.reset == 1 ← RST da Ubuntu (porte chiuse)
ip.src == 192.168.64.200 && tcp.flags.reset == 1 ← RST da nmap (chiude handshake)Combinazioni utili#
# Scan veloce — top 100 porte
nmap -F 192.168.64.3
# Scan completo con versioni
nmap -sS -sV -p- 192.168.64.3
# Scan subnet intera — trova host vivi
nmap -sn 192.168.64.0/24
# Scan con output su file
nmap -sS -oN /tmp/scan.txt 192.168.64.3
# Scan con NSE script (SSL)
nmap -p 31000-32000 --script ssl-cert 127.0.0.1Sicurezza: cambiare la porta SSH non basta#
Un'idea comune e' spostare SSH dalla 22 a una porta alta per nasconderla.
# nmap trova SSH su qualsiasi porta in secondi
nmap -p 1-65535 192.168.64.3
# PORT STATE SERVICE
# 2222/tcp open sshSpostare la porta e' un ostacolo di pochi secondi, non una difesa. La difesa reale e':
PasswordAuthentication no ← elimina brute force
PubkeyAuthentication yes ← solo chiave privata
PermitRootLogin no ← root non accede direttamenteScenario Reale — Blue Team#
Un analista SOC trova in tcpdump 2000 SYN dallo stesso IP verso porte diverse in meno di un secondo. Lancia nmap dalla sua macchina per verificare cosa e' davvero aperto:
sudo nmap -sS -sV 192.168.10.45
# PORT STATE SERVICE VERSION
# 22/tcp open ssh OpenSSH 8.9
# 80/tcp open http nginx 1.18Confronta con l'inventario: la porta 80 non dovrebbe essere aperta su quella macchina. Possibile web shell installata dall'attaccante.
Dove l'ho usato#
- Bandit 16 — scansione porte 31000-32000 con
--script ssl-cert - Settimana 5 — SYN scan su Ubuntu, analisi flag in tcpdump
- Settimana 6 — SYN scan catturato in analizzato in Wireshark 1000 SYN → 999 porte chiuse (RST da Ubuntu), 1 aperta (porta 22)
Script SSL/TLS#
# Leggi il certificato di un host
nmap --script ssl-cert -p 443 github.com
# Elenca tutte le cipher suite supportate con valutazione
nmap --script ssl-enum-ciphers -p 443 github.comOutput di ssl-cert — campi chiave:
| Campo | Cosa indica |
|---|---|
commonName | dominio coperto dal certificato |
Subject Alternative Name | tutti i domini coperti esplicitamente |
Issuer | chi ha firmato il certificato |
Public Key type | algoritmo della chiave pubblica (ec, rsa) |
Not valid after | data di scadenza |
Output di ssl-enum-ciphers — cosa cercare: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 → ha ECDHE → PFS garantita TLS_RSA_WITH_AES_256_CBC_SHA → NO ECDHE → niente PFS
Le cipher suite senza ECDHE in TLS 1.2 sono un rischio: se la chiave privata del server viene rubata, tutto il traffico passato registrato da un attaccante diventa decifrabile. TLS 1.3 ha eliminato queste cipher suite — non sono più permesse.
Vedere cipher suite TLS_RSA_WITH_* senza ECDHE su un server interno è una finding da segnalare — considera di disabilitarle se non hai vincoli di compatibilità con client vecchi.
Note personali#
nmap -sn 192.168.64.0/24 e' il modo piu' veloce per scoprire quali host sono vivi sulla rete senza scansionare le porte. Utile come primo passo in un incident response per mappare la LAN.
Esegui nmap SOLO su reti e sistemi di cui hai autorizzazione. In un SOC, lo usi per verificare la tua infrastruttura — non come strumento offensivo su reti altrui.
tcpdump vede tutto il traffico generato da nmap. auth.log e i log applicativi non vedono nulla durante un SYN scan. Questo e' il motivo per cui il monitoraggio a livello di rete e' complementare e non sostituibile dai log applicativi.
Collegato a#
- network — categoria
- incidents — categoria
- tcp-handshake — i flag SYN, SYN-ACK, RST che nmap usa e genera
- tcpdump — cattura il traffico generato da nmap per analizzarlo
- wireshark — analizza il dfir del port scan con filtri sui flag
- netcat — alternativa leggera per test su singole porte
