DeafNews
// 4 CVE · 3 EXPLOIT · 1 ADVISORY NELLE ULTIME 24H→
Nmap

Mappatura della rete e audit di sicurezza con Nmap: una guida tecnica completa

L'infrastruttura di rete cambia costantemente, eppure le lacune di visibilità rimangono il più grande fattore abilitante delle intrusioni di successo. Che tu stia integrando un nuovo ambiente, validando una migrazione di firewall o cercando servizi non autorizzati, hai bisogno di uno scanner che si adatti al tuo intento senza nascondere la sua meccanica dietro astrazioni opache. Nmap offre esattamente questo: un motore open-source il cui controllo raw dei pacchetti, l'esteso layer di scripting e i formati di output trasparenti lo hanno reso il fondamento della ricognizione di rete per oltre venticinque anni. Questa guida è strutturata come un riferimento modulare che puoi leggere in sequenza o consultare per task specifici. Iniziamo con il modo in cui Nmap assembla i probe e interpreta le risposte, per poi passare rapidamente ai comandi che puoi eseguire nei prossimi cinque minuti. I modelli di permessi, le peculiarità di installazione e la sintassi dei target ricevono un trattamento dedicato perché una scansione tecnicamente corretta ma legalmente non autorizzata è un fallimento che può mettere fine alla carriera. Da lì si procede con scenari di discovery reali, sviluppo personalizzato di NSE, ottimizzazione delle prestazioni e delle tecniche di evasione, e infine l'impiantistica operativa—parsing, integrazione e monitoraggio continuo—che trasforma scansioni sporadiche in telemetria di sicurezza affidabile. Una checklist etica conclusiva e una sezione di risoluzione dei problemi completano il toolkit. Ogni pagina è autosufficiente; insieme costruiscono una pratica di audit di rete disciplinato e difendibile.

sezioni: 8 | aggiornata: 26 mag 2026

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

Guida rapida: Comandi Nmap essenziali

Comandi Essenziali di Nmap — Cheat Sheet

I seguenti dodici comandi coprono il 90% delle operazioni quotidiane con Nmap. Ogni voce elenca la sintassi esatta, lo scopo e una valutazione pratica su quando usarli o evitarli. I flag che richiedono privilegi root o generano rumore di rete significativo sono contrassegnati.

Simbolo Significato
🔒 Richiede privilegi root / elevati
🔊 Genera rumore significativo; probabile attivazione di allarmi IDS/IPS

Rilevamento Host e Mappatura Rete

nmap -sn 192.0.2.0/24

Cosa fa: Invia echo ICMP, TCP SYN sulla porta 443, TCP ACK sulla porta 80 e richieste di timestamp ICMP per identificare host attivi. Quando usarlo: Inventario iniziale della rete, scoperta asset o prima di una finestra di manutenzione per identificare sistemi che rispondono. Rischi: ICMP è spesso bloccato dai firewall perimetrali; perderai host che scartano il ping ma espongono servizi. Output atteso: Elenco di indirizzi IP con dati di latenza Host is up; nessun dato sulle porte.

Quando evitarlo Alternativa
Hai bisogno dei dati sullo stato delle porte per confermare l'esposizione del servizio Rimuovi -sn ed esegui direttamente -sS; accetta che scannerai alcuni IP inattivi

Scansione TCP Stealth con Rilevamento OS

sudo nmap -sS -O 198.51.100.42

🔒

Cosa fa: Invia pacchetti SYN senza completare il three-way handshake TCP (scansione half-open); sonda le peculiarità dello stack TCP/IP per l'impronta digitale del sistema operativo. Quando usarlo: Ricognizione in cui vuoi minimizzare le voci di log sul target; i dati OS aiutano a priorizzare i controlli di vulnerabilità. Rischi: -O richiede root e invia traffico di sonda aggiuntivo; l'accuratezza si degrada con firewall/NAT. Output atteso: Tabella delle porte più la riga Running: con ipotesi OS e percentuale di confidenza.

PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https
MAC Address: 00:50:56:C0:00:08 (VMware)
Device type: general purpose
Running: Linux 5.X
OS CPE: cpe:/o:linux:linux_kernel:5.15
OS details: Linux 5.15

Una porta marcata filtered non è un risultato pulito — è una domanda senza risposta. Significa che un firewall, un filtro host-based o un rate-limiting ha scartato la sonda senza RST. Registrale separatamente; spesso indicano confini di segmentazione degni di essere mappati.

Rilevamento Versione Servizio con Script Default

sudo nmap -sV -sC 198.51.100.42

🔒

Cosa fa: -sV sonda le porte aperte per determinare nomi servizio e banner di versione; -sC esegue il set di default di script NSE (categoria safe, non intrusiva). Quando usarlo: Documentazione di baseline, correlazione vulnerabilità o prima dei cicli di patch. Rischi: Il banner grabbing può far crashare servizi embedded fragili; gli script -sC sono "safe" ma non a rischio zero. Output atteso: Tabella porte migliorata con colonna VERSION e blocchi di output script.

Scansione Intera Gamma Porte

sudo nmap -p- 198.51.100.42

🔒

Cosa fa: Scansiona tutte le 65.535 porte TCP (-p- espande a 1-65535). Quando usarlo: Valutazione approfondita di compromissione, ambienti CTF o quando sospetti servizi non standard oltre la porta 1024. Rischi: La durata scala linearmente; un singolo host può richiedere 15-60+ minuti a seconda di latenza e limiti di rate. Output atteso: Inventario porte completo; la maggior parte mostrerà closed o filtered.

Lab: nmap -p- -T4 198.51.100.42 (più veloce, più rumoroso) Produzione: nmap -p- -T2 --max-retries 1 198.51.100.42 (più lento, più delicato su link WAN)

Scansione Aggressiva

sudo nmap -A 198.51.100.42

🔒 🔊

Cosa fa: Equivalente a -sV -sC -O --traceroute; abilita rilevamento versione, script default, fingerprinting OS e tracciamento percorso in una sola invocazione. Quando usarlo: Ispezione approfondita singolo host quando serve il massimo dei dati e il rumore è accettabile. Rischi: Molto verboso; le sonde traceroute possono trapelare informazioni sul percorso sorgente. Output atteso: Rapporto consolidato adatto per documentazione o allegato ticket.

Output in Tutti i Formati

nmap -oA scan_20250715_198.51.100.42 -sV 198.51.100.42

Cosa fa: Scrive simultaneamente .nmap (human-readable), .xml (parser-friendly) e .gnmap (grep-friendly). Quando usarlo: Qualsiasi flusso di lavoro scriptato o quando strumenti downstream consumano XML. Rischi: Nessuno operativo; assicurati che la directory di scrittura esista. Output atteso: Tre file con basename coerente.

Velocità Bilanciata per Porte Comuni

nmap -T4 --top-ports 1000 192.0.2.0/24

🔊

Cosa fa: Usa il template di timing 4 (aggressive) sulle 1.000 porte più frequentemente aperte secondo la ricerca di Fyodor. Quando usarlo: Controlli rapidi di integrità su reti interne con buona larghezza di banda e senza preoccupazioni IDS. Rischi: -T4 può sopraffare target lenti o link congestionati; perde pacchetti in condizioni di perdita. Output atteso: Risultati rapidi per host reattivi; falsi negativi su servizi non comuni.

Salta Rilevamento Host

nmap -Pn 198.51.100.42

Cosa fa: Tratta il target come online indipendentemente dalla risposta ping; procede direttamente alla scansione porte. Quando usarlo: I target bloccano ICMP, o stai scansionando attraverso proxy/forwarder dove le sonde di rilevamento host falliscono diversamente dalle sonde di porta. Rischi: Aspetterai cicli di timeout completi contro IP veramente morti. Output atteso: Risultati porte per host che altrimenti sarebbero saltati.

Scansione UDP Veloce

sudo nmap -sU -F 198.51.100.42

🔒

Cosa fa: -sU invia datagrammi UDP; -F limita alle top 100 porte invece delle 1.000 default. Quando usarlo: Controlli infrastruttura DNS, SNMP, NTP o VoIP dove sono previsti servizi UDP. Rischi: La scansione UDP è intrinsecamente lenta (nessun handshake per confermare lo stato); molte porte restituiscono open|filtered per silenzio. Output atteso: Risultati radi ma critici; pianifica runtime lunghi se espandi oltre -F.

Rilevamento Vulnerabilità con NSE

nmap --script vuln 198.51.100.42

🔊

Cosa fa: Esegue tutti gli script NSE nella categoria vuln (controlla CVE noti, misconfigurazioni, credenziali default). Quando usarlo: Valutazioni sicurezza programmate, validazione pre-patch o triage risposta agli incidenti. Rischi: Alcuni script sono intrusivi; i falsi positivi richiedono verifica manuale. Output atteso: Risultati vulnerabilità strutturati con riferimenti e punteggi CVSS dove disponibili.

Scansione Decoy

sudo nmap -D RND:10 198.51.100.42

🔒 🔊

Cosa fa: Genera 10 IP sorgente decoy casuali intercalati con sonde reali; i log del target mostrano origini miste. Quando usarlo: Solo uso autorizzato e difensivo. Usalo in ambienti lab o in esercizi di validazione rilevamento esplicitamente autorizzati per testare regole di correlazione SIEM e allarmi basati su sorgente.

Evasione per Frammentazione

sudo nmap -f --mtu 16 198.51.100.42

🔒 🔊

Cosa fa: -f divide la sonda in frammenti da 8 byte; --mtu 16 forza frammenti payload da 16 byte. Aggira filtri pacchetto semplici che non riassemblano i flussi. Quando usarlo: Solo uso autorizzato e difensivo. Testing IDS/IPS in ambienti controllati, o per validare che i propri dispositivi edge riassemblino correttamente prima della valutazione ACL.

Riferimento Rapido Categorie Flag

Categoria Flag Comuni Scopo
Tipo scansione -sS, -sT, -sU, -sV, -A, -sn TCP SYN, connect, UDP, versione, aggressive, ping sweep
Timing -T0 a -T5, --min-rate, --max-retries Compromesso velocità vs. stealth; -T0/T1 per evasione IDS, -T3 default, -T4/-T5 per reti interne
Output -oN, -oX, -oG, -oA Formati normal, XML, grepable, tutti
Evasione -f, --mtu, -D, --source-port, --data-length Frammentazione, decoy, origini spoofate, padding payload

Errori Comuni

Errore Perché ti penalizza
Eseguire -A di default su ogni target Raddoppia tempo e rumore della scansione; -sV da solo basta per la maggior parte degli inventari
Dimenticare -Pn contro host cloud AWS, GCP, Azure spesso bloccano ICMP; Nmap salta completamente l'host
Usare -T5 attraverso link WAN La perdita di pacchetti causa stati filtered o closed falsi; -T4 è di solito il limite massimo
Ignorare completamente UDP (-sU) SNMP, DNS, IPMI e vari protocolli IoT espongono superficie di attacco solo su UDP
Fidarsi ciecamente dei banner di versione I servizi possono essere honeypot, segnalati erroneamente o patchati con backport senza aggiornamento banner

Checklist Pre-Scansione

  • [ ] Confermare il campo di autorizzazione (range IP, porte, vincoli di timing)
  • [ ] Verificare che la versione di nmap corrisponda alle funzionalità attese (nmap --version)
  • [ ] Testare connettività: ping o nc su un target per confermare il percorso
  • [ ] Selezionare il formato output per il consumo downstream
  • [ ] Per produzione: iniziare con -T3 o -T2, escalation solo se le prestazioni lo consentono
  • [ ] Registrare i parametri di scansione per riproducibilità e correlazione incidenti

Ulteriori letture

Installazione, Modelli di Autorizzazione e Specifica del Target

Installazione della Piattaforma e Trappole Pratiche

Nmap funziona su tutte le piattaforme principali, ma i percorsi di installazione presentano frizioni significativamente diverse. Su Linux, preferire i pacchetti della distribuzione per la risoluzione delle dipendenze, anche se gli ambienti container e sandbox introducono fallimenti prevedibili.

Piattaforma Metodo tipico Trappola nota
Linux (Debian/Ubuntu) apt install nmap I pacchetti Snap limitano CAP_NET_RAW; usare .deb o compilare dai sorgenti
Linux (RHEL/Fedora) dnf install nmap I contesti SELinux possono bloccare le operazioni su socket raw; vedi sotto
macOS brew install nmap Il firewall PF di macOS può scartare silenziosamente pacchetti craftati; verificare con tcpdump
Windows Installer ufficiale Npcap vs. WinPcap: Npcap è mantenuto attivamente; WinPcap è deprecato e fallisce su Windows moderni
Container/sistemi minimi Compilazione dai sorgenti Richiesto il linking statico di libpcap; header mancanti nelle immagini -slim

Per la compilazione dai sorgenti, la Nmap Install Guide fornisce la procedura canonica. Verificare l'integrità utilizzando le firme distaccate GPG fornite—gli hash SHA-1 sono disponibili, anche se potreste preferire validare direttamente la firma GPG.

Lab: Compilare con libpcap condivisa (standard, funziona su Debian/Ubuntu complete):

./configure && make && sudo make install

Produzione (container): Link statico per evitare dipendenze runtime mancanti in immagini minimali:

./configure --with-libpcap=included && make && make install

Cosa fa: Incorpora libpcap per eliminare la risoluzione delle dipendenze esterne in ambienti ridotti all'osso. Quando usarlo: Alpine, debian:slim, o immagini di build personalizzate dove ldconfig non trova oggetti condivisi. Rischi: Binario più grande, aggiornamenti di sicurezza più lenti per i componenti libpcap. Output atteso: Singolo binario nmap portatile senza dipendenze ldd su libpcap.so esterna.

Privilegi, Capabilities e Modelli di Permesso

Il comportamento predefinito di Nmap dipende fortemente dal livello di privilegio. Molti tipi di scansione richiedono l'accesso a socket raw per creare pacchetti o leggere risposte raw.

Livello di privilegio Tipi di scansione disponibili Limitazione
root / sudo Tutti (SYN stealth, UDP, rilevamento OS, frammentazione) Accesso completo a socket raw
Utente non privilegiato TCP Connect scan (-sT), alcuni script NSE SYN stealth (-sS) non disponibile; il kernel gestisce il completo handshake TCP
Capability CAP_NET_RAW SYN stealth, operazioni su pacchetti raw Non richiede root completo; funziona con file capabilities o ambient capabilities nei container

Su Linux, concedere file capabilities per evitare l'esecuzione come root:

sudo setcap cap_net_raw,cap_net_admin=eip $(which nmap)

Cosa fa: Allega le Linux capabilities al binario Nmap, permettendo operazioni su socket raw senza setuid o sudo. Quando usarlo: Pipeline CI/CD, shell restrittive, o scansioni containerizzate dove le direttive USER impediscono l'esecuzione come root. Rischi: Qualsiasi utente con permesso di esecuzione sul binario ottiene accesso a socket raw; verificare con getcap. Output atteso: -sS ha successo senza sudo; verificare con nmap -sS -p 80 192.0.2.1.

I contesti SELinux su RHEL/CentOS/Fedora possono bloccare i socket raw anche con privilegi root. Controllare i messaggi avc: denied in audit.log e applicare un boolean mirato o un modulo policy personalizzato se le operazioni su pacchetti raw sono necessarie per flussi di lavoro di scansione autorizzati.

Sintassi di Specificazione dei Target

Nmap accetta target in più formati. Il parser è flessibile ma implacabile con la notazione ambigua.

# Singolo host
nmap 192.0.2.1

# Range CIDR
nmap 192.0.2.0/24

# Target discreti multipli
nmap 192.0.2.1 192.0.2.10 198.51.100.5

# Lista host da file
nmap -iL targets.txt

# Escludere host (critico per la conformità dello scope)
nmap 192.0.2.0/24 --exclude 192.0.2.1,192.0.2.2

# Escludere da file
nmap 192.0.2.0/24 --excludefile protected_hosts.txt

Cosa fa: -iL legge target delimitati da newline; --exclude e --excludefile impediscono la scansione di sistemi fuori scope o fragili. Quando usarlo: Definizione dello scope di penetration test, subnet di produzione con host sensibili noti (SCADA legacy, dispositivi medici), o ambienti segmentati con esclusioni change-control. Rischi: --exclude è solo lato client; un errore di battitura nella sintassi di esclusione scansiona proprio l'host che intendevate saltare. Output atteso: Nmap elenca i target esclusi all'avvio; verificare nelle prime righe di output.

IPv6 richiede abilitazione esplicita e sintassi adattata:

nmap -6 2001:db8::1
nmap -6 2001:db8::/64

Gli ambienti dual-stack richiedono attenzione: -6 forza solo IPv6; senza di esso, Nmap risolve i nomi host in IPv4 per impostazione predefinita. Per audit dual-stack, scansionare separatamente ciascun protocollo o utilizzare i controlli di risoluzione dei nomi. La notazione CIDR IPv6 funziona identicamente a IPv4, ma assicurarsi che la shell esci le parentesi quadre se si incorporano indirizzi letterali negli script.

Errori comuni:

Errore Perché fa male
nmap 192.0.2.1-100 Parsa come 192.0.2.1 fino a 192.0.2.100; se intendevate porte, usare -p 1-100
nmap 192.0.2.1/24 -p- senza --exclude Scansiona tutte le 65535 porte su ogni host, inclusa l'infrastruttura di rete di cui non siete proprietari
Dimenticare -6 su host solo-IPv6 Appare come "host down" quando il target semplicemente non ha record A
Spazi bianchi nei file -iL Spazi finali causano tentativi di risoluzione DNS su nomi non validi, con perdita di dati e rallentamento delle scansioni

File di Configurazione e Ottimizzazione Ambientale

Il file .nmaprc nella home directory applica impostazioni predefinite persistenti. È qui che si impone la disciplina di scansione: limiti di rate, liste di esclusione e comportamento preferito di risoluzione DNS.

# Esempio ~/.nmaprc
max-retries 2
max-rtt-timeout 500ms
max-scan-delay 20ms
dns-servers 192.0.2.53
exclude 127.0.0.1,10.0.0.0/8

Le variabili d'ambiente integrano questo: NMAP_PRIVILEGED=1 forza Nmap ad assumere di avere le capability per socket raw (utile quando il rilevamento delle capability fallisce nei container); NMAP_UNPRIVILEGED=1 fa l'opposto.

Cosa fa: .nmaprc elimina flag ripetitivi e previene la sovra-scansione accidentale codificando impostazioni conservative predefinite. Quando usarlo: Host jump multi-utente, workstation di contractor, o qualsiasi ambiente dove una semplice invocazione nmap dovrebbe defaultare a parametri sicuri. Rischi: Le impostazioni predefinite nascoste creano lacune di audit—documentare i contenuti di .nmaprc nella metodologia di scansione. Output atteso: nmap --help non rivela le impostazioni .nmaprc attive; usare --datadir o -v verbose per ispezionare le impostazioni applicate.

Quadri di Autorizzazione Legale

La scansione non autorizzata viola lo U.S. Computer Fraud and Abuse Act (CFAA), lo UK Computer Misuse Act, e legislazioni analoghe nella maggior parte delle giurisdizioni. Le policy di acceptable use degli ISP espongono inoltre alla terminazione del servizio. La documentazione ufficiale su legal issues di Nmap documenta casi risultanti in cause legali, licenziamento, espulsione e carcerazione.

L'autorizzazione scritta è non negoziabile. Una lettera di autorizzazione valida contiene:

Elemento Scopo
Parti nominate Chi è autorizzato a scansionare (individuo o organizzazione)
Range IP, nomi host o blocchi CIDR Scope tecnico esatto; l'ambiguità non giova a nessuno
Intervallo date e restrizioni orarie Previene difese "era un'autorizzazione vecchia"; rispetta le finestre di manutenzione
Tecniche consentite Port scanning, rilevamento versione, script NSE, o controlli vulnerabilità
Contatto emergenza Chi notificare in caso di comportamento inatteso o interruzione
Firmatario con autorità Capacità legale di concedere accesso alla rete target

Confini bug bounty: Gli scope delle piattaforme (HackerOne, Bugcrowd, ecc.) definiscono dinamicamente i target consentiti. Un wildcard *.example.com non autorizza scansioni di infrastruttura contro le reti corporate di example.com se non esplicitamente elencate. Verificare sempre la lista degli asset in-scope al momento della scansione; i programmi mutano.

⚠️ Solo uso autorizzato, difensivo. Le opzioni di rate-limiting e timing trattate più avanti in questa guida esistono per la validazione dei rilevamenti e il troubleshooting di rete, non per aggirare i confini di autorizzazione.

Una porta marcata filtered non è un risultato pulito—è una domanda senza risposta. Avete inviato una sonda, ricevuto nessuna risposta o un errore ICMP ambiguo, e ora detenete spazio negativo dove dovrebbe esserci uno stato. Quell'ambiguità è dove i rischi legali e tecnici si compongono: il probing aggressivo ripetuto contro porte filtered per forzare una risposta scala da ricognizione a potenziale denial-of-service, e la clausola di scope della vostra lettera di autorizzazione è ciò che separa il testing autorizzato dal manomissione criminale di rete.

Approfondimenti

Esempi pratici svolti: dalla scoperta della rete alla verifica delle vulnerabilità

Inventario Rete Enterprise: Ottimizzazione per la Scalabilità

La scansione di una /16 (65.536 indirizzi) senza bloccare segmenti di rete o il proprio host richiede un'ottimizzazione deliberata delle prestazioni. I template di timing predefiniti sono troppo conservativi per questa scala e troppo aggressivi per collegamenti WAN congestionati.

sudo nmap -sn -PE -PP -PM -n --min-parallelism 512 --max-rtt-timeout 300ms --initial-rtt-timeout 150ms --max-retries 2 --max-scan-delay 10ms -oA corp-discovery 192.0.2.0/16

Cosa fa: Scoperta host (-sn, nessuna scansione porte) con probe ICMP echo (-PE), timestamp (-PP) e richiesta netmask (-PM); disabilita la risoluzione DNS (-n) per eliminare i colli di bottiglia del resolver. Quando usarlo: Scansioni baseline di inventario, riconciliazione CMDB o validazione dello scope pre-patching. Rischi: I filtri ICMP eliminano silenziosamente i probe; il parallelismo sopra 1.024 può sopraffare i socket locali sull'host di scansione. Output atteso: Lista ricercabile di host attivi con metriche di latenza.

Variante lab (aggressiva): --min-rate 10000 per saturare uno switch lab locale e testare il proprio monitoraggio. Variante produzione (conservativa): Aggiungere --scan-delay 5ms e limitare a --max-rate 500 per evitare di attivare soglie IDS basate sulla frequenza.

Una scansione /16 tipicamente rivela l'8-15% di host attivi in allocazioni enterprise sparse. Una porta marcata filtered non è un risultato pulito — è una domanda senza risposta. Distinguere sempre tra filtered (probe inviato, nessuna risposta) e admin-prohibited (ricevuto ICMP type 3, code 13), che conferma una regola firewall che ti blocca esplicitamente.

Valutazione Server Web: Proxy, WAF e Inganno dei Servizi

I servizi web si espongono raramente direttamente. Rilevare gli intermediari impedisce di effettuare fingerprinting sul bersaglio sbagliato e di attaccare erroneamente un nodo edge CDN.

sudo nmap -sS -sV -p80,443,8080,8443 --script=http-title,http-server-header,http-waf-detect,http-security-headers -d --reason 198.51.100.25

Estratto di output sanificato:

PORT     STATE SERVICE  VERSION
80/tcp   open  http     nginx 1.24.0 (reverse proxy)
| http-server-header: cloudflare
|_http-title: 301 Moved Permanently
443/tcp  open  ssl/http nginx 1.24.0
| http-waf-detect: IDS/WAF detected: Cloudflare
| ssl-cert: Subject: commonName=origin.internal.example
|_Not valid before: 2024-01-15T00:00:00
8080/tcp open  http     Apache Tomcat/Coyote JSP engine 1.1
|_http-title: Apache Tomcat/9.0.82

Interpretazione: La porta 80 termina su Cloudflare (WAF confermato). Il ssl-cert sulla 443 espone il nome interno del server origin (origin.internal.example) — una configurazione errata comune quando i certificati vengono copiati dall'origin all'edge senza pulizia dei SAN. La porta 8080 espone direttamente un'interfaccia di gestione, bypassando completamente il WAF.

Servizio Scoperto Configurazione Errata Comune Comando di Verifica
Front-end Cloudflare Il certificato origin espone nomi interni openssl s_client -connect 198.51.100.25:443
Reverse proxy nginx Divulgazione versione nell'header Server: --script http-server-header
Gestione Tomcat /manager/html accessibile senza restrizione IP --script http-auth,http-brute (solo autorizzato)
Apache con mod_proxy Errata configurazione trust X-Forwarded-For Test manuale injection header

Guida alla remediation: Limitare la gestione Tomcat a loopback e richiedere mTLS; rimuovere i banner versione tramite server_tokens off; in nginx; distribuire certificati pubblici separati senza SAN interni.

Audit Esposizione Database: Porte Predefinite e Affidabilità dei Banner

Le porte predefinite non sono garanzie, ma sono forti priori per configurazioni errate. Verificare con rilevamento servizio, mai assumere.

sudo nmap -sS -sV -sC -p3306,5432,27017,6379,1433,1521 --version-intensity 7 192.168.50.0/24

Cosa fa: Scansione SYN con rilevamento versione (-sV) e script NSE predefiniti (-sC) contro porte database comuni; intensità 7 bilancia velocità e profondità probe. Quando usarlo: Validazione segmentazione, revisione sicurezza migrazione cloud o valutazione esposizione post-incidente. Rischi: I probe MongoDB e Redis possono attivare fallimenti di autenticazione che bloccano account se fail2ban o simili è attivo; i probe versione MySQL possono essere loggati come tentativi di connessione. Output atteso: Nomi servizio, versioni e configurazioni rilevate dagli script.

Avvertenza critica: Le versioni rilevate e i banner non sono affidabili al 100%. Gli honeypot imitano deliberatamente servizi vulnerabili; alcuni container riportano la versione del kernel host piuttosto che il proprio livello di patch. Correlare sempre con inventario patch autenticato quando disponibile.

Fingerprinting Dispositivi IoT e Embedded

I dispositivi embedded spesso eseguono servizi non convenzionali o implementazioni di protocolli antichi che le scansioni standard non rilevano.

sudo nmap -sV --version-all -p- --script=banner -T4 --max-retries 1 --host-timeout 15m 10.0.3.0/24

Flag chiave spiegati: -p- = tutte le 65.535 porte; --version-all = invia ogni probe nel database Nmap (lento ma approfondito); --max-retries 1 = accetta più falsi negativi per velocità su reti IoT inaffidabili.

Estratto di output sanificato:

PORT      STATE SERVICE VERSION
23/tcp    open  telnet  BusyBox telnetd (D-Link router)
| banner: \xFF\xFD\x03\xFF\xFB\x01\xFF\xFD\x1F\xFF\xFB\x01\r\nD-Link DSL-2740B
80/tcp    open  http    micro_httpd
| http-title: Router Login - DSL-2740B
|_http-server-header: micro_httpd
1900/tcp  open  upnp    Portable SDK for UPnP devices 1.6.6
| upnp-info:
|   Server: LINUX/2.4 UPnP/1.0 BRCM400/1.0
|   Location: http://10.0.3.15:49152/gatedesc.xml
|_  Last boot: 2023-08-14
2323/tcp  open  telnet  Boa embedded web server config console

Interpretazione: Telnet sulla 23 e una console di gestione telnet alternativa sulla 2323 — entrambe non crittografate. Il servizio UPnP (1900/tcp) espone XML di descrizione dispositivo che spesso contiene versioni firmware ed endpoint servizio. Last boot agosto 2023 senza patch successive suggerisce trascuratezza cronica.

Analisi Configurazione SSL/TLS con NSE

I siti corporate interni non possono raggiungere tool esterni come Qualys SSL Test. ssl-enum-ciphers di Nmap fornisce valutazione equivalente per scope di audit interno.

nmap --script ssl-cert,ssl-enum-ciphers,ssl-heartbleed -p443 198.51.100.100

Output sanificato con annotazione forza cipher:

PORT    STATE SERVICE
443/tcp open  https
| ssl-cert: Subject: commonName=legacy-app.internal
| Issuer: commonName=Corporate-ICA-2019
| Public Key type: rsa
| Public Key bits: 2048
| Not valid before: 2023-06-01T00:00:00
| Not valid after:  2025-06-01T23:59:59
|_ssl-date: TLS randomness does not represent time
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048)   - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048)      - C
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048)      - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048)        - C
|     compressors:
|       NULL
|   TLSv1.1:
|     ciphers:
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048)         - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048)        - C
|   TLSv1.0:
|     ciphers:
|       TLS_RSA_WITH_RC4_128_SHA (rsa 1024)             - F
|     least strength: F
|_  Grade: F (due to TLSv1.0 with RC4 and 1024-bit RSA)
Voto Significato Trigger Tipici
A Forward secrecy forte, cipher AEAD, nessuna debolezza nota ECDHE + AES-GCM, TLS 1.2+
B Problemi minori (no FS per alcuni client, SHA-1 nella catena) Scambio chiave RSA statico, hash catena vecchio
C Algoritmi deboli o obsoleti permessi Modalità CBC senza EtM, 3DES, RSA statico
D Debolezze significative Crittografia export-grade, firme MD5
F Vulnerabilità critica o effettivamente rotto RC4, SSLv2/v3, RSA 512/1024-bit, nessuna crittografia

Cosa fa: Enumera tutti i ciphersuite per versione protocollo, valuta ciascuno e riporta il collegamento più debole. Quando usarlo: Baseline pre-migrazione, analisi gap compliance o validazione restrizioni cipher-suite distribuite via GPO/registry. Rischi: La metodologia di valutazione pesa lo scambio chiave e la forza del cipher stream; l'integrità messaggio (algoritmo MAC) non è considerata — un voto "C" con SHA-1 HMAC è ancora permesso senza downgrade. Output atteso: Liste cipher per versione con voti lettera e riepilogo aggregato least strength.

Interpretazione del campione: Il voto F è determinato interamente dal TLS 1.0 che supporta RC4 con RSA 1024-bit — banalmente violabile con risorse modeste. Tuttavia il TLS 1.2 offre cipher di voto A, il che significa che la remediation è solo configurazione (disabilitare TLS 1.0/1.1 e cipher deboli), non sostituzione certificato.

Conferma Remediation Vulnerabilità: Flusso di Lavoro Prima/Dopo

Il diffing dell'output di scansione è essenziale quando le finestre di change-control sono ristrette e le decisioni di rollback devono basarsi su evidenze.

# Baseline (pre-remediation)
nmap --script ssl-enum-ciphers -p443 -oX baseline-198.51.100.100.xml 198.51.100.100

# Post-remediation
nmap --script ssl-enum-ciphers -p443 -oX postfix-198.51.100.100.xml 198.51.100.100

# Diff strutturato
ndiff baseline-198.51.100.100.xml postfix-198.51.100.100.xml > ssl-cipher-diff.txt

Estratto di diff sanificato:

-  TLSv1.0:
-    ciphers:
-      TLS_RSA_WITH_RC4_128_SHA (rsa 1024) - F
-  least strength: F
-  Grade: F
+  TLSv1.2:
+    ciphers:
+      TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
+  least strength: A
+  Grade: A

Nota automazione: Integrare i codici di uscita di ndiff nei gate CI/CD — uscita non-zero su qualsiasi degrado dalla baseline. Per deployment rolling, baseline rispetto al target di produzione, non all'immagine golden; il configuration drift in produzione invalida spesso le assunzioni testate in lab.

Rate-Limiting ed Evasione IDS: Incontri Reali

Durante la scansione /16 sopra, diversi comportamenti hanno indicato contromisure difensive:

Sintomo Causa Probabile Diagnostica Risposta
Tutte le porte filtered dopo risultati iniziali open Regola firewall rate-limiting nping --tcp -p80 --rate 100 vs --rate 1000 Ridurre --max-rate a 200, estendere --scan-delay
Ritardi consistenti di 10 secondi su risposte SYN IPS shunning o tarpit tcptraceroute per identificare l'hop dove appare il ritardo Passare a -sS -T1 con decoy: -D RND:10,ME
ICMP admin-prohibited solo sulla porta 80 Negazione ACL esplicita, non drop generico Confrontare con comportamento porta nota aperta Documentare come controllo confermato, non fallimento scansione
SYN-ACK seguito da RST prima del completo handshake Proxy SYN o TCP intercept tcpdump mostra nessun payload dal target Ridurre complessità probe; intensità versione a 2

⚠️ Solo uso autorizzato e difensivo. Le scansioni con decoy (-D) e la frammentazione (-f) sono descritte qui per esercizi di validazione IDS e taratura dei propri threshold di rilevamento. Usare solo in ambienti lab o esercizi di validazione rilevamento esplicitamente autorizzati dove si possiede o si ha permesso scritto di testare tutta l'infrastruttura coinvolta.

Errori Comuni nelle Scansioni di Produzione

Errore Perché ti danneggia
Eseguire -A (aggressive) su scope /8 Il rilevamento OS e il traceroute moltiplicano il conteggio probe 10×; le scansioni falliscono per esaurimento memoria o ban di rete
Omettere -n su range grandi I timeout del resolver DNS bloccano l'intera scansione; i record PTR rivelano l'intento di ricognizione agli amministratori DNS
Fidarsi di Service Info: OS: Linux da -sV Nmap indovina l'OS dai banner servizio; le app containerizzate riportano il kernel host, non il loro runtime
Eseguire script NSE brute-force senza --script-args defaults Le liste username predefinite (es. oracle-brute) bloccano account dopo 3 tentativi; rivedere sempre gli argomenti brute.*
Ignorare filtered come "probabilmente niente" Le porte filtered spesso indicano i segmenti più sensibili — gli asset che vale la pena nascondere

Motore di Scripting Nmap: Automazione Personalizzata e Sviluppo NSE

Architettura ed Execution Model di NSE

Il Nmap Scripting Engine (NSE) incorpora un runtime Lua 5.3 che esegue script in parallelo con il motore di pacchetto nativo di Nmap. Non è un'aggiunta successiva applicata allo scanner: gli script vengono eseguiti durante la fase di scansione stessa, non in un passaggio di post-elaborazione. Il motore si lega a Nsock per I/O di rete asincrono, permettendo a centinaia di script di eseguire simultaneamente senza bloccare il thread principale della scansione.

Gli script rientrano in categorie (vuln, exploit, auth, brute, discovery, safe, intrusive, malware, version, default) e si attivano tramite quattro tipi di regola:

Tipo di regola Quando si attiva Utilizzo tipico
prerule Prima del discovery dell'host Configurazione a livello di script, lettura di file
hostrule Dopo il discovery dell'host, per ogni target attivo Controlli a livello di host (es. analisi traceroute)
portrule Dopo la scansione delle porte, corrispondenza con porte/servizi specifici Enumerazione dei servizi, controlli di vulnerabilità
postrule Dopo il completamento di tutte le scansioni Report aggregati, correlazione cross-host

Le regole restituiscono booleani Lua; il motore di Nmap decide se mettere in coda la funzione action dello script. Una portrule che corrisponde a shortport.http si attiverà contro qualsiasi porta identificata come HTTP da Nmap—sia la 80, la 8080, o una porta non standard con un banner riconoscibile.

Libreria di Script Built-in e Selezione

NSE include centinaia di script. Considera il set predefinito (-sC, equivalente a --script=default) come una linea di base sicura; esegue solo script nelle categorie default, safe, o version che si completano rapidamente e comportano un rischio minimo di crash.

Pattern di esecuzione selettiva:

# Script predefiniti sicuri contro un singolo host
nmap -sC 192.0.2.10

# Categoria specifica — controlli vuln contro un web server
nmap --script vuln -p 80,443 198.51.100.5

# Categorie multiple, separate da virgola
nmap --script "discovery,auth" 192.168.50.0/24

# Escludi script distruttivi anche con globbing
nmap --script "not intrusive" 10.0.3.0/24

Cosa fa: --script vuln carica tutti gli script nella categoria vuln, verificando CVE noti, debolezze di configurazione e divulgazioni di informazioni. Quando usarlo: Durante le fasi autorizzate di valutazione delle vulnerabilità dopo il discovery iniziale degli host. Rischi: Alcuni script vuln sono intrusive—possono attivare allarmi IDS o, in casi rari, causare crash di servizi fragili. Output atteso: Risultati strutturati di vulnerabilità con riferimenti CVE e indicatori di gravità.

Distinzione Lab vs. Produzione:

Ambiente Approccio Motivazione
Lab nmap --script "vuln,exploit" --script-args=unsafe=1 Copertura completa, accettare crash in reti isolate
Produzione nmap --script "safe,vuln" --max-parallelism 10 --max-retries 2 Escludere exploit, limitare il parallelismo, ridurre tempeste di retry

La categoria exploit merita particolare cautela. Questi script tentano attivamente l'esecuzione di codice o il bypass dell'autenticazione. Sono preziosi per validare lo stato delle patch in un lab, ma un'esecuzione exploit in produzione contro un server shadow IT mancato è un report di incidente in attesa di accadere.

Argomenti degli Script e Interazione Dinamica

Gli script espongono parametri configurabili tramite --script-args e --script-args-file. Questo trasforma gli script statici in strumenti flessibili.

# Passa un User-Agent personalizzato a http-title
nmap --script http-title --script-args http.useragent='Mozilla/5.0 (Windows NT 10.0; Win64; x64)' -p 80,443 192.0.2.15

# Argomenti multipli, delimitati da punto e virgola
nmap --script ssh-brute --script-args "userdb=./users.txt,passdb=./passwords.txt,ssh-brute.timeout=8s" -p 22 198.51.100.20

# Argomenti da file per ripetibilità
nmap --script smb-enum-shares --script-args-file ./smb-args.txt 10.0.4.50

Cosa fa: http.useragent sovrascrive la stringa User-Agent predefinita di NSE, riducendo il rilevamento basato su firme e corrispondendo alle aspettative di logging del target. Quando usarlo: Quando si testano regole WAF, si riproduce un ambiente client specifico, o si evitano stringhe "Nmap Scripting Engine" nei log. Rischi: Gli User-Agent personalizzati sono banali da impostare; non costituiscono un'evasione significativa contro un monitoraggio maturo. Output atteso: Estrazione http-title identica, ma i log del server riflettono la stringa fornita.

Scopri gli argomenti disponibili per qualsiasi script:

nmap --script-help http-title
nmap --script-help ssh-brute

L'output di --script-help elenca argomenti obbligatori vs. opzionali, valori predefiniti e appartenenza alle categorie. Leggilo prima di eseguire script non familiari—gli script brute in particolare possono bloccare account se non si impostano ritardi adeguati.

Scrivere Script NSE Personalizzati

Gli script personalizzati colmano il divario dove nessuno script esistente corrisponde al tuo protocollo, alla tua logica di rilevamento o al tuo formato di report. Lo script minimamente funzionante richiede quattro campi: description, categories, rule, e action.

Esempio minimale completo — uno script hostrule che verifica se il record PTR di un target risolve a un pattern sospetto:

description = [[
Checks if a reverse-DNS PTR record contains indicators of
dynamic/residential IP space, useful for flagging VPN exit nodes
or residential proxies during incident response.
]]

categories = {"discovery", "safe"}
author = "Analyst Name"
license = "Same as Nmap"

-- Pull in the NSE DNS library
local dns = require "dns"
local stdnse = require "stdnse"

-- Hostrule: run once per host after host discovery
hostrule = function(host)
  -- Only run if we have an IP; IPv6 PTR logic differs
  return host.ip ~= nil
end

-- Main action
action = function(host)
  local status, name = dns.query(host.ip, {dtype="PTR"})
  if not status then
    return "No PTR record found"
  end

  local suspicious = {
    "dhcp", "dynamic", "pool", "res", "ppp", "dsl", "cable"
  }

  local lower_name = string.lower(name)
  for _, pattern in ipairs(suspicious) do
    if string.find(lower_name, pattern, 1, true) then
      return string.format("SUSPICIOUS PTR: %s (matched '%s')", name, pattern)
    end
  end

  return string.format("PTR: %s", name)
end

Salva come ptr-suspicious.nse nella directory degli script di Nmap (<nmapdatadir>/scripts/ su Linux, o usa --datadir per puntare altrove). Esegui con:

nmap --script ptr-suspicious 192.0.2.100

Cosa fa: La hostrule si attiva dopo il discovery dell'host; action esegue una lookup DNS inverso e pattern-matching contro parole chiave note di IP dinamici. Quando usarlo: Durante il threat-hunting per segnalare proxy residenziali o fonti di scansione erratamente attribuite. Rischi: I record PTR sono controllabili dall'attaccante; non considerare mai un risultato "pulito" come prova di infrastruttura legittima. Output atteso: Una stringa di pattern corrispondente, un record PTR semplice, o "No PTR record found."

Librerie NSE chiave per lo sviluppo:

Libreria Scopo Funzione di esempio
nmap API core: info host/port, creazione socket nmap.new_socket()
stdnse Utility: formattazione, debug, timing stdnse.debug(1, "message")
shortport Predicati comuni per portrule shortport.http
table Helper per manipolazione tabelle table.contains(t, val)
string Pattern matching, parsing string.match(response, "Server: (.+)\r\n")
nsock I/O asincrono (tramite metodi socket di nmap) socket:connect(host, port)

Gli script vengono eseguiti in un ambiente Lua sandboxato. Non è possibile importare librerie C arbitrarie o eseguire comandi shell direttamente—questo è voluto. Per logica complessa che richiede dati esterni, usa stdnse.get_script_args() per leggere percorsi di file passati tramite --script-args, poi analizza quei file in puro Lua.

Debug degli Script e Profiling delle Prestazioni

Gli script NSE falliscono silenziosamente per impostazione predefinita—un timeout, una porta chiusa, o una mancata corrispondenza di protocollo non producono output. Forza la visibilità:

# Livello di debug 2: flusso di esecuzione dello script
nmap --script http-title -d2 --script-trace 192.0.2.10

# Traccia completa a livello di pacchetto dell'attività di rete dello script
nmap --script http-title -d3 --packet-trace 192.0.2.10

Cosa fa: -d2 abilita l'output di debug a livello di script; --script-trace stampa ogni lettura/scrittura Nsock. Quando usarlo: Quando uno script non restituisce nulla e si sospetta un edge case di protocollo. Rischi: Le tracce di pacchetto sono voluminose; reindirizza su file. Output atteso: Stack trace Lua, transizioni di stato del socket, e coppie raw di richiesta/risposta HTTP.

Per il profiling sistematico, usa --script-timeout e --host-timeout per impedire che script bloccati rallentino intere fasi di scansione. La funzione stdnse.debug() accetta livelli 1-9; usa il livello 1 per diagnostica in produzione e il livello 3+ solo durante lo sviluppo attivo.

Mantenere Repository di Script Privati

Le organizzazioni con logica di rilevamento personalizzata o firme sensibili non dovrebbero affidarsi alla directory globale degli script di Nmap. Stabilisci una struttura di repository privata:

/opt/nse-private/
├── scripts/          # file *.nse
├── lib/              # Librerie Lua private
├── data/             # File di fingerprint, wordlist
└── update.sh         # Deployment version-controlled

Invoca con datadir esplicito:

nmap --datadir /opt/nse-private --script my-custom-script 192.0.2.0/24

O crea symlink di singoli script nella directory di sistema ed esegui --script-updatedb per ricostruire il database degli script. Il file script.db nel datadir è una tabella Lua che Nmap analizza all'avvio; corruzioni qui causano criptici errori "Script not found".

Meccanismi di aggiornamento: il comando built-in nmap --script-update-db reindicizza solo i file locali. Per una vera consegna di aggiornamenti, versiona il tuo repository e fai deploy tramite configuration management (Ansible, Puppet, ecc.). Non tentare di sovrapporre script privati sulla directory upstream di Nmap—gli aggiornamenti dei pacchetti upstream entreranno in conflitto e sovrascriveranno.

NSE vs. Strumenti Esterni: Quando Restare, Quando Uscire

NSE eccelle nell'integrazione stretta con i risultati della scansione: consapevolezza dello stato delle porte, dati del rilevamento versione, e timing delle hostrule sono gratuiti. Vacilla quando hai bisogno di sessioni persistenti, macchine a stati di protocollo complesse, o post-elaborazione pesante.

Scenario NSE appropriato? Alternativa migliore
Acquisizione header HTTP durante la scansione host Sì —
Crawl completo di web application e test di form No Burp Suite, OWASP ZAP
Fingerprinting chiavi SSH Sì —
Brute-force con logica personalizzata di retry/backoff Marginale Hydra, Medusa
Exploit con consegna payload multi-stadio No Metasploit framework
Controllo vulnerabilità con 100+ varianti di richiesta No Scanner standalone (OpenVAS, Nessus)

I moduli Metasploit e gli script NSE si sovrappongono concettualmente ma divergono architetturalmente. NSE viene eseguito stateless per host/porta con secondi di tempo di esecuzione; Metasploit mantiene sessioni, effettua pivoting ed esegue Ruby arbitrario. Uno script come msrpc-enum elencherà interfacce; un modulo Metasploit si legherà a una ed estrarrà hash SAM. Usa NSE per la vastità della ricognizione, Metasploit per la profondità mirata.

Sicurezza degli Script e Denial of Service

La categorizzazione safe vs. intrusive è un segnale, non una garanzia. Gli script safe non causano crash di servizi nei test di Nmap, ma il tuo antico HMI ICS che parla un sottoinsieme HTTP rotto non era in quella matrice di test. Gli script intrusive possono inviare payload che esauriscono tabelle di connessione, riempiono log su disco, o attivano regole fail2ban.

Errori comuni:

Errore Perché ti colpisce
Eseguire script brute senza --script-args brute.delay Blocco account, allarmi SIEM, telefonate arrabbiate
Usare la categoria exploit in produzione senza scoping Crash effettivi di servizi su sistemi non patchati
Globbing --script "*" su grandi reti Esaurimento risorse da centinaia di script × migliaia di host
Ignorare http.max-cache-size e limiti simili Bloated di memoria, OOM kills su nodi di scansione a bassa risorsa
Assumere che safe significhi "impatto di rete zero" Qualsiasi sonda aumenta il carico; l'effetto cumulativo conta a scala

⚠️ Solo uso autorizzato e difensivo. Gli script exploit e intrusive sono progettati per validazione in lab e valutazioni di hardening autorizzate. Non indirizzarli mai a sistemi senza autorizzazione esplicita, documentata, che copra sia lo scope tecnico che l'impatto aziendale di una potenziale interruzione di servizio.

Prima del deployment in produzione, replicare le versioni dei servizi del target in un lab ed eseguire lo script previsto con -d3 --packet-trace. Osservare limiti di rateo di connessione, risposte di protocollo non standard, e crescita di memoria. Uno script che si completa in 0.3 secondi contro nginx può bloccarsi indefinitamente contro un server web embedded personalizzato che non chiude mai il socket.

Ottimizzazione delle prestazioni, tecniche di evasione e contro-rilevamento

Template di Timing e Controllo Granulare

I template -T di Nmap bilanciano velocità, stealth e carico di rete. L'intervallo utile va da -T0 (paranoico, un pacchetto ogni cinque minuti) a -T5 (folle, throughput massimo con potenziale perdita di accuratezza). Per la maggior parte delle valutazioni autorizzate, -T3 (normale) è il default, -T4 è lo standard aggressivo dei laboratori, e -T5 rischia report duplicati da probe persi.

I template configurano una matrice di timer interni. Quando serve un controllo chirurgico, sovrascrivili individualmente:

nmap -sS -p- --min-parallelism 50 --max-retries 2 --host-timeout 10m 192.0.2.0/24

Cosa fa: Esegue SYN-scan su tutte le 65.535 porte TCP con almeno 50 probe in volo, abbandonando un host dopo 2 tentativi o 10 minuti. Quando usarlo: Scansione di una rete lab stabile dove serve certezza di completamento contro host con firewall che scartano silenziosamente i pacchetti. Rischi: Il parallelismo elevato può sopraffare le tabelle di stato su equipaggiamenti di fascia bassa o attivare il rate-limiting. Output atteso: Tabella porte Nmap standard con stati open, closed, filtered o unfiltered per host; gli host che raggiungono --host-timeout vengono riportati come SKIPPED.

Template Comportamento Caso d'uso tipico
-T0 / -T1 Seriale, 5 min / 15 sec tra i probe Evasione IDS, target estremamente sensibili
-T2 Cortese, 0.4 sec tra i probe Carico leggero su infrastruttura condivisa
-T3 Timing dinamico default Scansione generica
-T4 Aggressivo, 10 ms tra i gruppi, parallelismo variabile Ambienti lab, valutazioni con time-box
-T5 Folle, assunzioni timeout a 5 ms Solo segmenti gigabit locali; aspettarsi falsi negativi

Un errore comune: assumere che -T5 trovi di più. Spesso trova meno, perché gli stimatori di timing di Nmap assumono condizioni di rete che percorsi congestionati o filtrati violano. Una porta marcata filtered a -T5 può rivelarsi open a -T3 con --max-retries 3.

Variante lab (velocità massima):

nmap -sS -T4 -p- --min-rate 1000 --max-rtt-timeout 500ms 10.0.0.0/24

Variante produzione (vincolata):

nmap -sS -T2 -p 22,80,443,8080-8090 --max-rate 100 --max-retries 3 10.0.0.0/24

Frammentazione, Manipolazione MTU e Scansione con Decoy

Nmap supporta la frammentazione IP con -f (frammenti da 8 byte dopo il primo) e --mtu per dimensioni personalizzate. L'obiettivo è suddividere le informazioni di header tra i frammenti, forzando il riassemblaggio prima dell'ispezione. Questo prende di mira sensori IDS/IPS più datati o mal configurati che mancano di motori di riassemblaggio completi.

nmap -sS -f --send-eth -p 22,80,443 192.0.2.100

Cosa fa: Frammenta i probe SYN in payload da 8 byte, bypassando alcuni pattern matcher semplici; --send-eth forza l'Ethernet grezzo per garantire che Nmap controlli la frammentazione anziché lo stack IP del SO. Quando usarlo: Validare se un sensor edge del target riassembla prima di allertare. Rischi: I sensori moderni riassemblano i frammenti; spesso fallisce contro Suricata con reassemble_fragments: yes o dispositivi Palo Alto. Output atteso: Stati delle porte identici alla scansione non frammentata se avviene il riassemblaggio; le discrepanze rivelano lacune nei sensori.

La scansione con decoy (-D) offusca la vera sorgente intrecciando probe spoofati da host falsi o reali:

nmap -sS -D 198.51.100.1,ME,198.51.100.2 -p 80,443 192.0.2.100

Cosa fa: Invia scansioni da tre sorgenti apparenti; ME posiziona il tuo IP reale tra i decoy. Il target logga tutti e tre; solo la vera sorgente riceve le risposte. Quando usarlo: Testare se gli analisti dei log correlano gli alert o semplicemente contano le sorgenti. Rischi: I decoy spoofati verso host live generano backscatter e tempeste RST; usare IP di terze parti reali ma non autorizzati è abusivo. Output atteso: La tua console mostra le risposte; i log del target mostrano sorgenti multiple.

⚠️ Solo uso autorizzato e difensivo. Usa queste tecniche solo in ambienti lab o in esercizi di validazione della detection esplicitamente autorizzati.

Errore Perché ti punisce
-f senza --send-eth o --send-ip Lo stack del SO spesso riassembla prima della trasmissione, annullando la frammentazione
Decoy che sono host live e responsivi Le loro risposte RST ai SYN non sollecitati creano rumore che aiuta gli analisti a isolare il vero scanner
Valori --mtu non multipli di 8 Nmap rifiuta o frammenta male; verifica con nmap --mtu 16 vs. nmap --mtu 17

Spoofing Porta Sorgente, Spoofing MAC e Proxy Chains

Alcune regole firewall si fidano del traffico da porte sorgente specifiche (DNS legacy: 53, dati FTP: 20). Il --source-port di Nmap sfrutta questo:

nmap -sS --source-port 53 -p 22,80 192.0.2.100

Cosa fa: Genera probe SYN da UDP/53, potenzialmente corrispondendo a regole firewall any port 53. Quando usarlo: Audit di set di regole che confondono numero di porta con fiducia nel servizio. Rischi: Il traffico di ritorno sulla porta 53 può entrare in conflitto con processi DNS locali o non raggiungere il socket senza manipolazione SO_REUSEADDR. Output atteso: Porte open che risultano filtered senza lo spoof; conferma logica di regola debole.

Lo spoofing dell'indirizzo MAC (--spoof-mac) opera solo su segmenti Ethernet locali e richiede root:

nmap -sS --spoof-mac 00:11:22:33:44:55 -e eth0 192.0.2.100

L'integrazione con proxy chains instrada Nmap attraverso proxy SOCKS4/5 o HTTP, aggiungendo latenza ma offuscando l'origine. Configura /etc/proxychains.conf, poi:

proxychains nmap -sT -Pn -n --max-retries 1 198.51.100.0/24

Cosa fa: Forza scansioni TCP connect (-sT) attraverso la proxy chain; -Pn salta il host discovery (l'ICMP non attraversa); -n disabilita il DNS. Quando usarlo: Test da prospettiva esterna attraverso un pivot o servizio di scansione commerciale. Rischi: proxychains wrappa i socket via LD_PRELOAD, che le scansioni grezze di Nmap bypassano—solo -sT funziona in modo affidabile. Output atteso: Completamento più lento con latenza del proxy iniettata; semantica degli stati identica.

Meccanica della Scansione Idle/Zombie

La scansione idle (-sI) è la tecnica di Nmap più anonima per quanto riguarda la sorgente. Sfrutta sequenze IPID prevedibili su un host "zombie" per inferire gli stati delle porte senza inviare pacchetti dal tuo IP al target.

Meccanismo: (1) Interroga l'IPID dello zombie; (2) Forgia SYN verso il target con l'indirizzo sorgente dello zombie; (3) Il target risponde SYN/ACK allo zombie (aumentando il suo IPID di 1 se la porta è aperta) o RST allo zombie (IPID invariato se chiusa, o nessuna risposta se filtrata); (4) Re-interroga l'IPID dello zombie. Un delta di 2 significa porta aperta; delta di 1 significa chiusa o filtrata.

Trovare zombie adatti richiede host con allocazione IPID incrementale e traffico basso:

nmap -sI 192.0.2.50:80 -p 22,80,443 198.51.100.25

Cosa fa: Usa 192.0.2.50 come zombie, con la porta 80 come porta di probe dello zombie (deve essere aperta per il campionamento IPID). Quando usarlo: Requisiti estremi di anonimato in esercizi red-team autorizzati. Rischi: Zombie con IPID randomizzato o zero (Linux moderno, Windows post-Vista) rendono inutilizzabile la tecnica; zombie ad alto traffico producono delta ambigui. Output atteso: Stati delle porte inferiti tramite cambiamenti IPID; nessun pacchetto dal tuo IP al target eccetto i probe iniziali allo zombie.

Test di idoneità dello zombie:

nmap -sS -O -v --script ipidseq 192.0.2.50

Lab (scoperta aggressiva zombie):

nmap -n -Pn -sS -p 80 --script ipidseq --script-args probeport=80 192.0.2.0/24 | grep -i "incremental"

Produzione (singolo zombie verificato, velocità ridotta):

nmap -sI 192.0.2.50 -p 22,80,443 -T2 --max-retries 2 198.51.100.25

Adattamento al Logging di IDS/IPS e Firewall

L'evasione è una corsa agli armamenti, non una soluzione. I sensori moderni rilevano le scansioni per volume, pattern o anomalia comportamentale—non solo per contenuto dei pacchetti. Un testing autorizzato efficace imita pattern di traffico legittimo piuttosto che inseguire l'invisibilità perfetta.

Strategie di evitamento della firma:

Tecnica Limitazione Contromisura di detection
Throttling dei pacchetti (-T0, --max-rate) Completa lentamente; gli attaccanti pazienti vincono comunque Correlazione time-windowed tra i probe
Mismatch di protocollo (-sN, -sF, -sX) Le scansioni Null/Fin/Xmas falliscono contro filtri stateful e vengono loggate come anomalie comunque Tracciare combinazioni rare di flag
Ordine target randomizzato (--randomize-hosts) Rompe i log sequenziali ma non i modelli comportamentali Analisi di cluster per timing e distribuzione dei probe
Decoy (-D) Sorgenti multiple aumentano il carico di lavoro degli analisti Analisi TTL, correlazione TCP timestamp, matching entropia payload

La verità onesta: un difensore determinato e dotato di risorse con full packet capture vince contro un singolo scanner. L'evasione compra tempo contro analisti pigri o sensori sottodimensionati. Pianifica per la detection e tieni pronta la documentazione di autorizzazione.

Prospettiva Difensiva: Riconoscere Nmap nei Log

Il valore blue-team deriva dalla comprensione delle impronte degli scanner. La scansione SYN default di Nmap esibisce pattern prevedibili che tcpdump rivela:

sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0' -c 20

Campione di output realistico:

14:32:10.123456 IP 203.0.113.50.54321 > 192.0.2.100.80: Flags [S], seq 1234567890, win 1024, length 0
14:32:10.123512 IP 203.0.113.50.54322 > 192.0.2.100.443: Flags [S], seq 1234567900, win 1024, length 0
14:32:10.123578 IP 203.0.113.50.54323 > 192.0.2.100.22: Flags [S], seq 1234567910, win 1024, length 0

Elementi riconoscibili: le porte sorgente incrementano sequenzialmente (54321, 54322, 54323), la dimensione della finestra TCP è fissa a 1024 (default Nmap per alcuni tipi di probe), i numeri di sequenza iniziale avanzano in modo prevedibile, e i probe arrivano in stretti cluster temporali.

Regola Suricata/Snort per rilevamento SYN stealth:

alert tcp any any -> any any (
    msg:"NMAP TCP SYN Stealth Scan";
    flags:S;
    ack:0;
    threshold:type both, track by_src, count 20, seconds 60;
    reference:url,https://nmap.org/book/synscan.html;
    classtype:attempted-recon;
    sid:1000001;
    rev:1;
)

Questo scatta su 20 pacchetti SYN-senza-ACK da una singola sorgente in 60 secondi. Regola count e seconds sulla tua baseline—le applicazioni legittime possono attivare soglie aggressive.

Per il rilevamento di scansioni zombie, monitora anomalie IPID: un singolo host che mostra incrementi IPID esattamente di 2 con connessioni esterne intrecciate suggerisce probing con sorgente forgiata. Logga le sequenze IPID dove fattibile.

Divulgazione Responsabile: Notificare o Trattenere?

La scoperta di lacune evasione-capaci nell'infrastruttura difensiva crea una scelta scomoda. Lo standard professionale: notificare il proprietario dell'infrastruttura prima di dimostrare l'impatto, a meno che tu non sia il proprietario o detenga autorizzazione esplicita a validare senza pre-briefing. Trattenere tecniche da un report per "rimanere utili per il prossimo impegno" è una mossa limitante per la carriera che erode la fiducia. Documenta cosa hai trovato, come l'hai trovato, e cosa un avversario meno vincolato potrebbe ottenere. Il valore di un red team si misura per ciò che migliora nelle difese, non per i trucchi che rimangono segreti.

Flussi di lavoro per l'analisi dell'output, l'integrazione e il monitoraggio continuo

Analisi Programmatica dell'Output XML di Nmap

L'output XML di Nmap (-oX) è l'unico formato sufficientemente strutturato per un'automazione affidabile. Lo schema è semplice: un elemento radice nmaprun contenente nodi host, ciascuno con figli address, hostnames, ports e os. Per Python, hai due percorsi pratici: la libreria python-nmap per l'orchestrazione diretta delle scansioni con accesso agli oggetti, oppure libnmap (che include parser, report e backend MongoDB/Elastic) per il post-processing di file esistenti. Quando devi solo analizzare—specialmente in un worker CI che non ha eseguito la scansione—evita il wrapper e usa la libreria standard.

Ecco un parser rodato in produzione che estrae le porte nuovamente aperte effettuando il diff rispetto a una baseline di scansione precedente:

#!/usr/bin/env python3
"""Extract new open ports from Nmap XML compared to a baseline."""
import xml.etree.ElementTree as ET
from pathlib import Path
from datetime import datetime
import sys

def parse_ports(xml_path):
    """Return dict: {(ip, port, proto): service_banner}."""
    ports = {}
    tree = ET.parse(xml_path)
    for host in tree.findall('host'):
        status = host.find('status')
        if status is None or status.get('state') != 'up':
            continue
        ip = host.find('address').get('addr')
        ports_elem = host.find('ports')
        if ports_elem is None:
            continue
        for port in ports_elem.findall('port'):
            if port.find('state').get('state') != 'open':
                continue
            portid = port.get('portid')
            proto = port.get('protocol')
            service = port.find('service')
            banner = ''
            if service is not None:
                banner = service.get('name', '')
                if service.get('product'):
                    banner += f" {service.get('product')}"
                if service.get('version'):
                    banner += f" {service.get('version')}"
            ports[(ip, portid, proto)] = banner.strip()
    return ports

def diff_scans(baseline_path, current_path):
    baseline = parse_ports(baseline_path)
    current = parse_ports(current_path)
    new = {k: v for k, v in current.items() if k not in baseline}
    closed = {k: v for k, v in baseline.items() if k not in current}
    return new, closed

if __name__ == '__main__':
    new, closed = diff_scans(sys.argv[1], sys.argv[2])
    print(f";; Delta report generated {datetime.utcnow().isoformat()}Z")
    for (ip, port, proto), banner in sorted(new):
        print(f"[NEW] {ip}:{port}/{proto} {banner}")
    for (ip, port, proto), banner in sorted(closed):
        print(f"[CLOSED] {ip}:{port}/{proto} {banner}")

Cosa fa: Confronta due file XML di Nmap, riportando le porte apparse o scomparse. Quando usarlo: Job cron notturni, gate CI, o triage incident-response quando servono delta actionable automaticamente. Rischi: XML senza --service-version produce banner vuoti; abbinalo sempre a -sV per diff significativi. Output atteso: Righe prefissate con [NEW] o [CLOSED] con IP, porta, protocollo e fingerprint del servizio.

La libreria python-nmap incapsula il binario ed espone i risultati come dizionari; libnmap offre oggetti di reporting più sofisticati e serializzazione integrata. Entrambe si basano sullo stesso XML sottostante. Per Go o Rust, genera struct dallo schema con xsdgen o serde—la community ha pubblicato diverse implementazioni corrette.

Scansione Differenziale con Ndiff

Per confronti ad-hoc senza scrivere codice, Nmap include ndiff, un diff semantico che comprende la logica di scansione invece di effettuare un semplice diff testuale. Ignora il rumore di timestamp e runtime, concentrandosi sui cambiamenti di stato degli host, delle porte e del SO.

# Lab: Confronto settimanale del segmento lab interno
ndiff /scans/baseline-192.0.2.0-24.xml /scans/weekly-192.0.2.0-24.xml

# Produzione: Scansione a intensità ridotta, stesso flusso di diff
nmap -sS -p- --max-rate 100 --max-retries 2 -oX /scans/prod-weekly.xml 192.0.2.0/24
ndiff /scans/baseline-prod.xml /scans/prod-weekly.xml

Cosa fa: Confronta due file XML di Nmap e restituisce solo i cambiamenti significativi in formato human-readable. Quando usarlo: Revisioni operative settimanali, validazione del change-control, o dopo finestre di manutenzione per rilevare esposizioni non intenzionali. Rischi: ndiff non allerta su host mancanti che non hanno risposto; gli host down spariscono silenziosamente da entrambi i report. Output atteso: Righe prefissate con + e - che mostrano servizi acquisiti o persi; = per elementi invariati.

Output realistico di ndiff:

- Nmap 7.94 scan initiated Mon Jan 15 06:00:00 2024 as: nmap -sS -sV -p- -oX baseline.xml 192.0.2.0/24
+ Nmap 7.94 scan initiated Mon Jan 22 06:00:00 2024 as: nmap -sS -sV -p- -oX weekly.xml 192.0.2.0/24

  192.0.2.10:
+   8080/tcp open  http    Apache Tomcat 9.0.82
-   3306/tcp open  mysql   MySQL 8.0.34

  192.0.2.55:
+   Host is up.
+   22/tcp open  ssh     OpenSSH 9.3p1

La riga + 8080/tcp è il tuo segnale: o è avvenuto un deployment senza ticket di change, o è in esecuzione un servizio non autorizzato. La riga - 3306/tcp è altrettanto importante—la scomparsa di un servizio può indicare una risposta a un compromesso (attaccante che copre le tracce) o una misconfigurazione che ha rotto una dipendenza.

L'archiviazione delle scansioni in PostgreSQL abilita l'analisi longitudinale: "Mostrami tutti gli host dove la porta 3389/RDP è apparsa negli ultimi 90 giorni" o "Conta le istanze SMB esposte per subnet nel tempo." Schema minimale:

CREATE TABLE scans (
    scan_id SERIAL PRIMARY KEY,
    started_at TIMESTAMPTZ NOT NULL,
    target_cidr CIDR,
    nmap_version TEXT,
    xml_checksum BYTEA UNIQUE
);

CREATE TABLE hosts (
    host_id BIGSERIAL PRIMARY KEY,
    scan_id INT REFERENCES scans(scan_id),
    ip INET NOT NULL,
    mac TEXT,
    hostname TEXT,
    os_guess TEXT,
    state TEXT CHECK (state IN ('up', 'down', 'unknown'))
);

CREATE TABLE ports (
    port_id BIGSERIAL PRIMARY KEY,
    host_id BIGINT REFERENCES hosts(host_id),
    port INT,
    protocol TEXT,
    state TEXT,
    service_name TEXT,
    product TEXT,
    version TEXT,
    extrainfo TEXT
);

CREATE INDEX ON ports(port, protocol, state) WHERE state = 'open';
CREATE INDEX ON hosts(ip, scan_id);

Importa tramite COPY da un CSV prodotto dal tuo parser Python, o usa l'estensione xml2 di PostgreSQL per lo shredding diretto dell'XML. Partiziona scans per started_at mensilmente; gli archivi di scansione crescono rapidamente.

Architettura di Scansione Continua

┌─────────────┐     ┌─────────────┐     ┌─────────────────┐
│  Scheduler  │────▶│  Scan Jobs  │────▶│  Nmap Workers   │
│  (cron/     │     │  (temporal/  │     │  (dedicated     │
│   Airflow)  │     │   ephemeral) │     │   network seg)  │
└─────────────┘     └─────────────┘     └─────────────────┘
                                               │
                                               ▼
                                        ┌─────────────┐
                                        │  XML Output │
                                        │  (S3/nfs)   │
                                        └─────────────┘
                                               │
                    ┌──────────────────────────┼──────────────────────────┐
                    ▼                          ▼                          ▼
              ┌─────────┐              ┌─────────────┐              ┌─────────────┐
              │ Parser  │              │   Ndiff     │              │  Zenmap/    │
              │ (Python)│              │   Engine    │              │  Faraday    │
              └────┬────┘              └──────┬──────┘              └─────────────┘
                   │                          │
                   ▼                          ▼
              ┌─────────┐              ┌─────────────┐
              │PostgreSQL│             │  Alerting   │
              │(trends)  │             │  (PagerDuty │
              └─────────┘              │  /Slack/API) │
                                       └─────────────┘

Decisioni operative chiave in questa pipeline:

Decisione Implicazione pratica
Frequenza di scansione dal CI Scansioni baseline ad ogni deployment; sweep completi settimanali. Troppo frequenti e si desensibilizzano i responder; troppo radi e si accumula drift.
Segmentazione dei worker Esegui Nmap da una NIC/VLAN dedicata con regole firewall esplicite. Un worker compromesso è una miniera d'oro per un attaccante.
Ritenzione XML L'XML raw è 10-50× le righe compresse del DB. Mantieni 90 giorni hot, archivio glacier per il periodo di compliance.
Deduplicazione per checksum XML identici (nessun cambiamento di rete) saltano il parsing; risparmia I/O, rivela infrastruttura stagnante.

Integrazione con Pipeline CI/CD

Incorpora la scansione baseline nelle pipeline di deployment per intercettare il drift dell'infrastructure-as-code prima che raggiunga la produzione. Esempio GitLab CI:

network-baseline:
  image: nmap:latest  # pin digest, not tag
  variables:
    TARGET: "198.51.100.0/24"
    RATE: "500"  # Production: reduce to 100 or less
  script:
    - nmap -sS -sV -p- --max-rate $RATE -oX scan-$(date +%s).xml $TARGET
    - python3 /scripts/parse_and_alert.py scan-*.xml --baseline /baselines/prod.xml
  artifacts:
    paths: ["scan-*.xml"]
    expire_in: 30 days
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"

Cosa fa: La pipeline schedulata esegue Nmap, analizza i risultati, e fallisce se appaiono nuove porte rispetto alla baseline. Quando usarlo: Ad ogni deployment su infrastruttura network-adjacent, o notturnamente per ambienti statici. Rischi: Fallimenti della pipeline da jitter di rete causano alert fatigue; implementa retry con backoff e alerting basato su soglia (es. 3 delta consecutivi). Output atteso: Log del job CI con le nuove porte analizzate, o pass verde se la baseline corrisponde.

Il parser dovrebbe emettere exit code 2 su drift, exit code 0 su match, e exit code 1 su fallimento della scansione—convenzioni standard Nagios che la maggior parte dei sistemi CI e degli hook di monitoring comprendono nativamente.

Visualizzazione e Integrazione con Strumenti di Terze Parti

La vista topologica di Zenmap è adeguata per la comprensione di singole reti ma non scala oltre poche centinaia di host. Per dashboard operative, esporta verso:

Strumento Ruolo Percorso di integrazione
Faraday Workspace collaborativo per pentest Upload XML via API; correlazione con finding di exploit
Dradis Generazione report Importa XML come evidenza; template per executive summary
Grafana Dashboard time-series Backend PostgreSQL con query di esposizione porte
nmap-vulners Contesto vulnerabilità --script nmap-vulners arricchisce i dati porta con riferimenti CVE al momento della scansione 
# Lab: Arricchisci la scansione con lo script vulners per contesto di triage immediato
nmap -sV --script nmap-vulners -p 22,80,443 -oX vuln-enriched.xml 192.0.2.0/24

Cosa fa: Interroga l'API Vulners per CVE associati alle versioni di servizio rilevate. Quando usarlo: Prioritizzazione di servizi esposti; mai come unica valutazione di vulnerabilità. Rischi: Il rilevamento versione è probabilistico; falsi positivi su patch backportate comuni in Linux enterprise. Output atteso: Lista CVE appesa all'output script di ciascuna porta nell'XML.

RustScan come Livello di Accelerazione

Per il discovery iniziale su grandi patrimoni, la velocità ispirata a masscan di RustScan con fallback a Nmap migliora il throughput della pipeline. Non è un sostituto—il rilevamento servizi e gli script richiedono Nmap propriamente detto—ma collassa la fase di discovery da ore a minuti.

# Lab: RustScan per discovery porte, Nmap per ispezione approfondita
rustscan -a 192.0.2.0/24 --range 1-65535 --scan-order random \
  -- -sV -sC -oX deep.xml

Il -- passa gli argomenti rimanenti a Nmap. In produzione richiede rate limiting: i default di RustScan sono aggressivi e sovraccaricheranno firewall stateful o triggereranno soglie IDS.

Ritenzione Dati per Archivi Sensibili di Topologia

Gli archivi di scansione contengono una mappa di rete completa—indirizzamento IP, host attivi, versioni servizi, guess SO. Trattali come confidenziali al livello di sensibilità della tua documentazione di rete, non semplicemente come dati di log.

Elementi pratici di policy:

  • Ritenzione: 90 giorni online in PostgreSQL, 1-3 anni XML compresso in object storage, poi distruzione crittografica. Il legal hold sospende la cancellazione.
  • Accesso: Solo service account per il parser; l'accesso umano richiede break-glass con riferimento ticket loggato.
  • Crittografia: XML a riposo (AES-256-GCM via S3 o crittografia filesystem); TLS 1.3 per il trasporto parser-to-database.
  • Geografia: Archivia nella stessa giurisdizione della rete; il trasferimento transfrontaliero di mappe infrastrutturali può violare la data residency o attivare review di export control.

Intuizione conquistata sul campo: Una porta marcata filtered non è un risultato pulito—è una domanda senza risposta. Molti operatori archiviano solo le porte open e perdono il segnale rilevante per la sicurezza dei cambiamenti nelle regole firewall. Archivia gli stati filtered e closed; il delta da filtered a open senza ticket di change è spesso il tuo primo indicatore di intrusione.

Errori comuni, risoluzione diagnostica dei problemi e checklist etica

Quando i Risultati Mentono: Falsi Positivi, Falsi Negativi e Interferenze dei Middlebox

Una porta marcata filtered non è un risultato pulito — è una domanda senza risposta. La trappola più pericolosa nello scanning di rete è assumere che il silenzio equivalga all'assenza, o che una porta aperta sia effettivamente raggiungibile end-to-end.

Cause alla base dei risultati ingannevoli:

Sintomo Probabile Colpevole Priorità Diagnostica
Tutte le porte open su IP esterno Proxy trasparente o dispositivo di intercettazione TCP Verificare con probe a livello applicativo
Host appare down ma i servizi rispondono Firewall stateful che scarta i probe, ICMP bloccato Usare -Pn con ping specifico per l'applicazione
Fingerprint OS incoerente Pool bilanciato, NAT hairpinning, o host virtualizzato Multiple passate di scansione da diversi punti di vista
Commutazione intermittente filtered/open Rate limiting o regola firewall dinamica Ridurre --max-rate, osservare i pattern temporali
closed inaspettato su servizio noto TCP wrappers, hosts.allow/deny, o IPS shun Controllare --reason e risposta a livello di pacchetto

I firewall e i middlebox iniettano risposte sintetiche. Un SYN TCP alla porta 80 che restituisce SYN-ACK potrebbe raggiungere un server web, o potrebbe raggiungere un proxy trasparente che tenterà a sua volta la connessione verso upstream. Lo stato filtered — nessuna risposta, o ICMP admin-prohibited — indica che esiste un dispositivo di controllo, ma non se un servizio si nasconde dietro di esso.

Flag Diagnostici: Leggere la Mente di Nmap

Quando i risultati contraddicono le aspettative, scalare attraverso la verbosità diagnostica prima di ipotizzare.

# Livello 1: Perché Nmap ha concluso ciò che ha concluso?
nmap --reason -p 443 192.0.2.10

# Livello 2: Visibilità a livello di pacchetto (alto volume di output)
sudo nmap --packet-trace -p 443 192.0.2.10

# Livello 3: Version scan con piena disclosure dei probe
sudo nmap -sV --version-trace -p 443 192.0.2.10

# Livello 4: Traccia di esecuzione degli script NSE
sudo nmap --script "http-title" --script-trace -p 80 192.0.2.10

Cosa fa: --reason espone l'evidenza esatta per ogni stato di porta: syn-ack, syn-ack ttl 58, no-response, reset, admin-prohibited. Quando usarlo: Triage di prima linea per qualsiasi risultato inaspettato. Rischi: Trascurabili; non aggiunge pacchetti. Output atteso: Riga singola per host/porta con razionale esplicito.

Interpretazione dell'output di --packet-trace:

SENT (0.0423s) TCP 198.51.100.5:42311 > 192.0.2.10:443 S ttl=53 id=49217 iplen=44 seq=298743210 win=1024
RCVD (0.0891s) TCP 192.0.2.10:443 > 198.51.100.5:42311 SA ttl=122 id=0 iplen=44 seq=384721098 win=64240
Campo Interpretazione
SA (SYN-ACK) vs RA (RST-ACK) Servizio genuino vs rifiuto attivo
ttl=122 Tipico host Windows; Linux solitamente 64, Cisco IOS 255. TTL incoerente con l'OS atteso suggerisce middlebox o risposta contraffatta.
id=0 Alcuni load balancer azzerano l'IP ID; artefatto utile per il fingerprinting
Delta temporale 0.0468s Confrontare con la baseline; picchi di latenza improvvisi indicano rate limiting o accodamento

Un valore ttl che salta tra le esecuzioni di scansione — 122, poi 58, poi 241 — è una prova schiacciante di load balancing o infrastruttura anycast. Non fidarsi del rilevamento OS da scansione singola in questi ambienti.

Variante di produzione per reti con vincoli:

# Lab: Traccia pacchetti completa
sudo nmap --packet-trace -T4 -p- 192.0.2.0/24

# Produzione: Limitata, mirata, con reason-only come prima passata
nmap --reason --max-rate 50 -p 22,443,8080 --max-retries 2 192.0.2.0/24

Cosa fa: La variante di produzione limita a 50 pacchetti/secondo, restringe i retry, e riduce lo scope delle porte. Quando usarla: Scansione attraverso collegamenti WAN, durante l'orario lavorativo, o vicino a segmenti fragili IoT/SCADA. Rischi: Più lenta ma previene l'esaurimento delle tabelle di stato sui firewall intermedi. Output atteso: Stessi dati di stato, larghezza di banda e carico sui dispositivi ridotti.

Impatto sull'Infrastruttura: Lo Scanning come Vettore di Denial-of-Service

Nmap può rompere cose che non ti appartengono. I seguenti sono modalità di guasto documentate e riproducibili:

Tempeste di broadcast da probe mal diretti: Domini broadcast di Livello 2 con VLAN scarsamente segmentate possono amplificare il traffico ARP. Una scansione /16 contro una topologia di rete flat genera ARP per ogni target; su reti con switch datati, questo riempie le tabelle CAM e triggera l'unknown unicast flooding.

Esaurimento della tabella di stato: I firewall stateful tracciano lo stato della connessione per ogni flusso. Una SYN scan a -T4 o -T5 contro un firewall con hardware modesto può esaurire la sua tabella di sessione, causando il drop o il mancato stabilimento di connessioni legittime. Questo non è teorico — è una causa frequente di incidenti del tipo "il firewall si è bloccato durante la scansione".

Saturazione della larghezza di banda: Le scansioni di frammentazione (-f) moltiplicano il conteggio dei pacchetti; il rilevamento versione (-sV) e gli script NSE aggiungono payload a livello applicativo. Un nmap -sV -sC -p- contro un /24 remoto su un collegamento MPLS da 10 Mbps lo saturerà per ore.

Incidente reale — scanning non autorizzato che causa outage di produzione:

Nel 2019, un analista junior di sicurezza presso un'azienda manifatturiera europea ha eseguito nmap -p- -sS -T5 contro un intervallo IP ritenuto essere un nuovo segmento server. L'intervallo includeva controller embedded sulla rete di tecnologia operazionale (OT), separata dall'IT solo da un firewall con una regola di permesso mal configurata. La velocità di scansione ha sopraffatto gli stack TCP dei controller; tre programmable logic controllers (PLC) sono entrati in modalità fault, arrestando una linea di produzione per 6,5 ore. L'analista aveva l'approvazione verbale di un IT manager ma nessuna approvazione dell'ingegneria OT, nessuna coordinazione della finestra temporale, e nessun contatto di emergenza. Post-incidente: l'analista è stato licenziato, l'azienda ha affrontato obblighi di notifica normativa, e la regola firewall è risultata esistere da 18 mesi a causa di una dismissione incompleta.

La lezione non è "Nmap è pericoloso" — è che la verifica dello scope e il controllo della velocità sono prerequisiti operazionali, non formalità burocratiche.

Albero Decisionale: Risultati di Scansione Inaspettati

Inizio: Risultato contraddice l'aspettativa (es., porta aperta che dovrebbe essere chiusa)
    │
    ▼
┌─────────────────────────┐
│ Riesegui con --reason   │
│ Stesso risultato?       │
└─────────────────────────┘
    │ No ──► Probabilmente transitorio; annota il timing e prosegui
    ▼ Sì
┌─────────────────────────┐
│ Controlla --packet-trace│
│ TTL/ID coerenti con il  │
│ target atteso?          │
└─────────────────────────┘
    │ No ──► Interferenza middlebox/proxy/NAT; escala a test stratificati
    ▼ Sì
┌─────────────────────────┐
│ Lo stato è coerente     │
│ tra multiple esecuzioni │
│ da diverse fonti?       │
└─────────────────────────┘
    │ No ──► Filtraggio dinamico o load balancing; documenta la varianza
    ▼ Sì
┌─────────────────────────┐
│ Verifica con strumento  │
│ indipendente (nc, curl, │
│ openssl s_client)       │
└─────────────────────────┘
    │ Mismatch ──► La firma del probe Nmap ha triggerato risposta diversa;
    │              possibile manipolazione IPS/IDS; ispeziona dispositivi inline
    ▼ Match
┌─────────────────────────┐
│ Risultato validato:     │
│ Aggiorna l'inventario e │
│ valuta l'esposizione    │
└─────────────────────────┘

Prevenzione dello Scope Creep e Procedure di Emergenza

Il confine tra "solo un'altra subnet" e un rapporto di incidente è più sottile di quanto la maggior parte immagini. Implementa controlli meccanici, non forza di volontà.

Arresti forzati — non negoziabili:

Trigger Azione Immediata
Scoperta di etichetta produzione critica (SCADA, MEDICAL, FIN-PROD) Arresta scansione; verifica che l'autorizzazione copra esplicitamente questo segmento
Scansione causa latenza osservabile nelle risposte del target Riduci --max-rate del 50%; se persiste, interrompi e rischedula
Contatto da network operations o SOC Pausa tutte le scansioni attive; conferma ricezione entro 15 minuti
Superamento della finestra temporale concordata Termina; non "finire questo host"

Comando di arresto di emergenza: Tieni pronta una shell con pkill -9 nmap, o pre-posiziona uno script che uccida i processi di scansione e registri il timestamp di terminazione. Non affidarti a Ctrl-C attraverso sessioni SSH con lag.

⚠️ Solo uso autorizzato e difensivo. Le tecniche di evasione (-f, --scanflags, -D, -S, --proxies) sono documentate per la validazione del rilevamento e il testing dell'architettura difensiva. Usare solo in ambienti lab o esercizi esplicitamente autorizzati con approvazione scritta che specifichi tecnica, target e durata.

Obblighi Pre-Engagement e Post-Scan

Template di checklist scaricabile (copia e adatta):

Fase Voce Responsabile Data/Iniziale
Pre-scan Autorizzazione scritta con intervalli IP, porte e tecniche permesse
Confini dello scope confermati: elenco di inclusione esplicito, non "tranne produzione"
Contatti di emergenza: escalation tecnica e liaison legal/compliance
Finestra temporale: inizio, arresto forzato, fuso orario, periodi di blackout
Team di rete notificato; NOC/SOC informato degli IP sorgente della scansione
Limiti di velocità concordati e configurati nel comando di scansione
Durante la scansione Monitoraggio in tempo reale della reattività del target
Ritenzione dei log: log locali della scansione, packet capture se usati flag diagnostici
Post-scan Gestione dei dati: crittografia a riposo, controlli di accesso, periodo di ritenzione
Conferma distruzione: log eliminati secondo policy di ritenzione, certificati o artefatti eliminati in modo sicuro
Divulgazione responsabile: risultati riportati al proprietario dell'asset prima della pubblicazione esterna; standard 90 giorni a meno che la criticità richieda urgenza
Consegna del rapporto: risultati tecnici, rating del rischio, indicazioni di remediation, nessun dato raw nelle email

Meccanismi di divulgazione responsabile: Un risultato senza un percorso di remediation è una passività, non un risultato. Consegna i rapporti cifrati (PGP o canale approvato dall'organizzazione), con severità calibrata sull'effettiva exploitabilità, non sul massimo teorico CVSS. Include passaggi di riproduzione sufficienti per la verifica ma non per la weaponization. Conferma ricezione. Se il proprietario dell'asset non risponde, consulta il consulente legale prima di qualsiasi divulgazione più ampia — l'approccio "pubblica e fatti maledire" distrugge la fiducia e può esporti a responsabilità.

Conferma distruzione dei dati: I log di Nmap contengono topologia del target, dati banner, e potenzialmente credenziali o identificatori di sessione catturati nell'output NSE. Uno shred -uz o la distruzione del volume cifrato sono insufficienti senza documentazione del processo. Mantieni un log di distruzione con hash crittografico dei dati pre-distruzione se il team di incident response o legale della tua organizzazione richiede evidenza della gestione.

La checklist non è teatro di compliance — è la differenza tra un engagement professionale e un evento limitante per la carriera.

Letture consigliate