Architettura di Nmap e Fondamenti della Scansione

Meccaniche TCP/IP alla Base della Scoperta Host e della Scansione Porte

L'efficacia di Nmap si basa sulla manipolazione precisa dei comportamenti di protocollo definiti in RFC 793 (TCP), RFC 792 (ICMP) e RFC 768 (UDP). La scoperta host e la scansione porte sfruttano il fatto che uno stack TCP/IP deve rispondere a determinati stimoli: anche un rifiuto di comunicare costituisce informazione.

Three-Way Handshake TCP e Implicazioni per la Scansione

Client                          Server
  |                               |
  |  -------- SYN -------->       |  [Sonda di scansione: porta aperta?]
  |                               |
  |  <---- SYN/ACK --------       |  [Porta aperta: disponibile a stabilire]
  |                               |
  |  -------- ACK -------->       |  [Scansione full connect si completa qui]
  |                               |
  |  <---- RST (o dati) ----      |  [Nmap può inviare RST per evitare half-open]
  |                               |
  |  -------- SYN -------->       |
  |  <---- RST/ACK --------       |  [Porta chiusa: rifiuto attivo]
  |                               |
  |  -------- SYN -------->       |
  |  (timeout / ICMP unreach)     |  [Porta filtrata: nessuna risposta o bloccata]

L'handshake rivela tre stati critici da una singola sonda: open (SYN-ACK ricevuto), closed (RST-ACK ricevuto) e filtered (nessuna risposta, o ICMP admin prohibited). La SYN scan di Nmap (-sS) invia SYN e interrompe prima dell'ACK finale: questa tecnica "half-open" evita la registrazione in alcuni daemon applicativi e richiede privilegi di raw socket.

Per UDP, l'assenza di stato di connessione significa che una porta aperta tipicamente non restituisce risposta, mentre una porta chiusa restituisce ICMP Port Unreachable. La scansione UDP è intrinsecamente più lenta e meno affidabile; molti amministratori assumono erroneamente che l'esposizione UDP sia benigna.

⚠️ Solo uso autorizzato e difensivo. Le idle/zombie scan e alcune tecniche di frammentazione descritte di seguito sono utilizzate principalmente per testare le capacità di rilevamento della propria infrastruttura di monitoraggio. Distribuirle solo in ambienti di laboratorio o esercitazioni autorizzate di validazione del rilevamento.

Architettura Core di Nmap

Nmap opera come motore di pacchetti con quattro sottosistemi integrati:

Sottosistema	Funzione	Caratteristica Chiave
Motore di Sonda	Costruisce pacchetti IP raw con specifici flag TCP/UDP/ICMP, opzioni e payload	Bypassa lo stack di rete del SO; controllo completo dei campi header
Analizzatore di Risposte	Analizza i pacchetti restituiti confrontandoli con i comportamenti attesi conformi agli RFC	Distingue lo stato per timing, flag, dimensione finestra e sequenze IP ID
Sistema di Timing	Manipola il rate di sonda, la parallelizzazione e i calcoli di timeout	Si adatta alle condizioni di rete; critico per l'evasione e l'accuratezza
Motore di Fingerprinting	Confronta le risposte alle sonde con un database di firme note di OS/servizi	Le sonde attive rivelano particolarità di implementazione invisibili all'osservazione passiva

Il sistema di timing merita particolare attenzione. I preset -T0 fino a -T5 di Nmap regolano il ritardo inter-pacchetto, le soglie di timeout e il conteggio delle sonde parallele. -T4 (aggressive) assume condizioni LAN affidabili; -T2 (polite) riduce l'impatto collaterale su reti fragili. La regolazione manuale tramite --min-rate, --max-retries e --host-timeout permette un controllo preciso che i preset non possono eguagliare.

Tassonomia dei Tipi di Scansione

Nmap implementa tecniche di scansione distinte variando la composizione dei flag TCP della sonda:

Tecnica	Flag Impostati	Interpretazione della Risposta	Caso d'Uso Tipico
TCP Connect (-sT)	Full three-way handshake	Risultato standard di connect(); non servono raw socket	Quando la SYN scan non è disponibile (non privilegiato) o attraversamento proxy
SYN (-sS)	Solo SYN	Half-open; SYN-ACK = open, RST = closed, silenzio = filtered	Default, più veloce, scansione privilegiata più stealth
UDP (-sU)	Payload UDP alla porta	ICMP unreachable = closed; timeout = open o filtered	Scoperta servizi su infrastruttura DNS, SNMP, VoIP
ACK (-sA)	Solo ACK	RST = unfiltered (firewall stateful assente); timeout = filtered	Mappatura regole firewall, non stato porta
Window (-sW)	Solo ACK (come -sA)	Il campo Window nell'RST differenzia open/closed su determinati sistemi	Raro; utile contro specifici stack legacy
Maimon (-sM)	FIN/ACK	Le porte aperte ignorano per RFC 793; le chiuse restituiscono RST	Oscuro; bypassa alcuni filtri di pacchetti stateless
Idle/Zombie (-sI)	Spoofato da host zombie	L'analisi della sequenza IP ID sullo zombie rivela i risultati della scansione	Scansione anonimizzata; richiede host con IP ID prevedibile

Le scansioni ACK e Window illustrano un principio cruciale: non tutte le scansioni determinano se una porta accetta connessioni. Queste "scansioni firewall" mappano le regole di filtraggio. Una porta marcata unfiltered significa semplicemente che una sonda ha raggiunto l'host; non dice nulla sulla disponibilità del servizio. Confondere unfiltered con open è un errore analitico comune.

Macchina a Stati: Oltre Open e Closed

Nmap riporta sei stati di porta, e la loro semantica è importante per un'interpretazione accurata:

Stato	Definizione	Valore Diagnostico
open	Servizio che accetta connessioni	Obiettivo per rilevamento versione e correlazione vulnerabilità
closed	Nessun servizio in ascolto; RST ricevuto	Conferma host raggiungibile; firewall permette il traffico
filtered	Nessuna risposta; sonda scartata	Firewall o ACL in azione; richiede evasione o percorso alternativo
unfiltered	Solo risposta a scansione ACK; stato porta indeterminato	Firewall assente; procedere con SYN o Connect scan
open\|filtered	Ambiguità di scan UDP, IP proto, FIN/Null/Xmas	Non è stato possibile distinguere open da filtered; necessita sondaggi aggiuntivi
closed\|filtered	Ambiguità Maimon, ACK/Window su determinati sistemi	Raro; tipicamente richiede riscansione con tecnica diversa

Una porta marcata filtered non è un risultato pulito: è una domanda senza risposta. L'assenza di risposta può indicare una regola di drop, rate limiting o routing asimmetrico. Gli analisti di sicurezza devono correlare con i codici ICMP (tipo 3, codice 1 = host unreachable; codice 3 = port unreachable; codice 13 = admin prohibited) e considerare la varianza temporale attraverso multiple sonde.

Fingerprinting OS e Rilevamento Versione

Il rilevamento versione (-sV) opera inviando sonde specifiche per servizio e confrontando le risposte banner o le particolarità comportamentali con nmap-service-probes. Le sonde sono categorizzate per rarità; le sonde comuni vengono eseguite per prime, quelle esotiche solo con --version-all. Le versioni rilevate sono probabilistiche: i banner possono essere banalmente contraffatti, e le implementazioni possono emulare altri servizi.

Il fingerprinting OS (-O) costruisce una firma da:

Prevedibilità del TCP initial sequence number (ISN)
Algoritmo di generazione IP ID (incrementale, random, costante, derivato da timestamp)
Comportamento dell'opzione TCP timestamp
Dimensione finestra TCP e ordinamento opzioni
Risposte esplicite a pacchetti malformati di ICMP/TCP

La firma viene confrontata con nmap-os-db. I livelli di confidenza riflettono la prossimità statistica; una corrispondenza al 95% non è certezza. La virtualizzazione, la containerizzazione e lo spoofing deliberato dell'OS degradano l'accuratezza. L'infrastruttura cloud moderna spesso restituisce firme Linux generiche che offuscano il livello di patch del kernel sottostante.

Formati di Output e Granularità di Logging

Nmap fornisce multipli formati di output, ciascuno servente esigenze operative distinte:

# Laboratorio: Scansione SYN completa con tutti i formati di output per documentazione
nmap -sS -O -sV -p- -T4 \
  -oN scan-report-normal.txt \
  -oX scan-report.xml \
  -oG scan-report.gnmap \
  -oS scan-report-skiddie.txt \
  192.0.2.0/24

Cosa fa: Esegue scansione completa su tutte le 65535 porte, con rilevamento OS e versione, scrivendo quattro formati di output paralleli. Quando usarlo: Documentazione di baseline, importazione in strumenti SIEM/reporting (XML), automazione basata su grep (gnmap), o revisione umana (normal). Rischi: L'intero range porte (-p-) con rilevamento versione genera traffico significativo; invasivo in produzione. Output atteso: File multipli; XML adatto per confronto con ndiff e ingestione da parser.

Formato	Estensione	Scopo	Compromesso
Normal (-oN)	`.txt`	Leggibile umano con metadati di runtime	Non analizzabile automaticamente; verbose
XML (-oX)	`.xml`	Dati strutturati; importazione in strumenti, database, trasformate XSLT	Verbose; richiede parser; più completo
Grepable (-oG)	`.gnmap`	Un host per riga; friendly per `awk`/`grep`/script shell	Perde dettagli output script; struttura flat
Script Kiddie (-oS)	`.txt`	Trasformazione in leetspeak	Inutile eccetto per presentazione ironica

Il formato grepable persiste nonostante la superiorità dell'XML perché l'integrazione pipeline rimane più veloce del parsing DOM per estrazione ad hoc:

# Estrae host con qualsiasi porta web aperta dall'output grepable
awk '/Host: / && /80\/open|443\/open|8080\/open/' scan-report.gnmap

Cosa fa: Filtra l'output grepable per host con porte HTTP/HTTPS o porte web alternate aperte. Quando usarlo: Triage rapido senza strumenti XML. Rischi: Il formato grepable omette l'output degli script NSE e i dettagli del fingerprinting OS. Output atteso: Righe corrispondenti al pattern, ciascuna contenente stato completo host e elenco porte.

Variante produzione (minore intensità, formato output singolo per monitoraggio):

# Produzione: Verifica uptime servizio con rate limiting
nmap -sS -p 22,80,443,3389 --min-rate 50 --max-retries 2 \
  -oG - 198.51.100.0/26 | tee daily-uptime.gnmap

Cosa fa: Controllo porte limitato a 50 pacchetti/secondo massimo, con tolleranza retry ridotta, streaming output grepable. Quando usarlo: Monitoraggio routine servizi senza impattare la produzione. Rischi: Anche scansioni contenute possono attivare IDS; coordinarsi con i team di monitoraggio. Output atteso: Riga singola per host; adatto per cron-driven diff rispetto alle esecuzioni precedenti.

Confronto Ricognizione Attiva vs Passiva

Dimensione	Attiva (Nmap)	Passiva
Generazione pacchetti	Sonde inviate al target	Nessuna interazione diretta; osserva traffico esistente
Rilevabilità	Registrata da firewall, IDS, OS host	Invisibile al target
Completezza	Enumera tutti gli host/porte responsivi	Limitata agli endpoint comunicanti
Accuratezza	Determinazione precisa dello stato; bassi falsi negativi	Dipendente dal volume di traffico; perde host silenziosi
Velocità	Controllata dall'operatore; può essere rapida	Limitata dai pattern di traffico naturali
Posizione legale/contrattuale	Richiede autorizzazione esplicita	Ambigua; monitorare solo reti proprie

Nmap è fondamentalmente attiva. Ogni sonda è un evento rilevabile. Gli operatori difensivi dovrebbero riconoscere che gli avversari usano tecniche identiche; la firma di Nmap è ben catalogata nelle regole Snort/Suricata. Il valore della scansione attiva nella pratica difensiva risiede nella validazione della baseline: confermare che la realtà osservata della rete corrisponda al suo stato documentato, e che la propria infrastruttura di rilevamento registri l'attività che dovrebbe.

Errori Comuni

Errore	Perché ti danneggia
Scansionare senza scoperta host (default `-Pn`)	Spreca ore sondando route blackhole o sottoreti dismesse; verificare sempre prima che i target siano vivi
Trattare `filtered` come `closed`	Perde servizi esposti dietro ispezione stateful; le porte filtrate possono essere accessibili da punti di osservazione alternativi
Eseguire `-A` (aggressive: OS + versione + traceroute + script) su tutto	Costo temporale proibitivo su reti grandi; le sonde di versione possono crashare servizi embedded fragili
Ignorare `--max-retries` e `--host-timeout`	Scansioni in sospeso su singoli host non responsivi ritardano l'intero job; i timeout prevengono il fallimento a cascata
Affidarsi ciecamente ai banner di versione	Honeypot e framework di inganno servono banner contraffatti; validare attraverso test comportamentali

Checklist: Preparazione Pre-Scansione

[ ] Verificare il campo di autorizzazione: range IP, limiti porte, vincoli di timing
[ ] Notificare i team operativi se scansione in produzione; confermare eccezioni di monitoraggio
[ ] Selezionare la tecnica di scansione corrispondente al livello di privilegio e alla postura firewall
[ ] Scegliere il/i formato/i di output in base ai requisiti di elaborazione a valle
[ ] Impostare il template di timing o limiti di rate manuali appropriati alla resilienza del target
[ ] Documentare la topologia attesa per l'analisi delle deviazioni post-scansione