Risoluzione dei problemi, insidie e verifica dei risultati

L'Anatomia dei Falsi Negativi

L'assenza di prove di Nmap non è mai prova di assenza. I falsi negativi più insidiosi derivano da patologie dei pacchetti che si mascherano da quiete di rete.

Pacchetti filtrati versus pacchetti scartati creano firme diagnostiche divergenti. Una porta filtrata elicita un ICMP admin-prohibited o TCP RST da un firewall, che Nmap interpreta correttamente. Un pacchetto scartato, tuttavia, svanisce silenziosamente—indistinguibile da una porta aperta senza listener, o da un firewall configurato per DROP senza risposta. Quando si vede open|filtered, Nmap confessa la sua incertezza: la porta non ha risposto entro la finestra di timeout del probe, ma non è stata ricevuta alcuna拒绝. Questa ambiguità domina la scansione UDP (-sU) per progettazione, poiché UDP manca di semantica di acknowledgment. Un servizio UDP effettivamente aperto potrebbe semplicemente non rispondere al payload del tuo probe, mentre una porta UDP filtrata lo assorbe identicamente. L'unica disambiguazione è la specificità del payload: se il probe DNS predefinito di Nmap (porta 53) non riceve risposta, provare nmap -sU -p 53 --script dns-recursion <target> con una query valida, o iniettare manualmente con echo -n -e '\x00\x00\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\x03www\x06google\x03com\x00\x00\x01\x00\x01' | nc -u <target> 53.

Rate limiting aggrava il problema. Host target, IDS intermedi, o persino il proprio ISP possono limitare le risposte ICMP o i tassi di SYN-ACK. Il timing dinamico di Nmap (-T4, -T5) assume che la scansione aggressiva si adatti al percorso; non è così. Quando Nmap riporta 0/1000 porte aperte su un host noto come attivo, ispezionare l'output di nmap --packet-trace per ritrasmissioni che superano --max-retries. L'escalation dei conteggi di retry con valori statici di --max-rtt-timeout suggerisce congestione del percorso, non inattività dell'host.

Le risposte TCP window=0 costituiscono una trappola sottile. Alcuni servizi—particolarmente sistemi embedded e kernel hardened—acknowledgano il SYN con SYN-ACK, win=0, poi non completano mai il handshake. Nmap tipicamente segna queste come open, tuttavia il servizio può essere intenzionalmente non responsivo o privo di risorse. La porta è tecnicamente aperta a livello di macchina a stati TCP, ma funzionalmente inutile. Verificare incrociatamente con nc -vz <target> <port> osservando se il trasferimento dati ha successo, o catturare l'handshake completo con il filtro tcpdump discussi di seguito.

Pattern di Falsi Positivi: Quando l'Infrastruttura Mente

Le architetture di rete moderne ingannano attivamente gli scanner di porte. Load balancer con SYN proxying o configurazioni DSR (Direct Server Return) possono acknowledgano i SYN per pool backend che sono down, presentando porte open a nessun servizio disponibile. L'indizio: risultati consistentemente open con drop immediati della connessione durante la negoziazione applicativa, o valori TTL selvaggiamente variabili nei pacchetti restituiti (nmap --reason --packet-trace espone questo).

Proxy trasparenti e nodi edge CDN intercettano e rispondono ai probe prima di raggiungere l'origine. Un risultato dello script http-proxy con mismatch di banner—Apache presentato dove ci si aspetta Nginx, o stringhe di versione impossibili—merita sospetto. Gli honeypot amplificano questo: Kippo, Cowrie, e piattaforme di deception commerciali emulano banner di servizio con indizi caratteristici (versioni SSH eccessivamente verbose, shell root immediate, o violazioni di protocollo). Quando gli script ssh-hostkey restituiscono chiavi con lunghezze di bit sospettosamente basse o duplicate attraverso subnet non correlate, ci si trova probabilmente di fronte a strumentazione, non infrastruttura.

La Diagnostica 'Tutte le Porte Filtrate'

Un risultato apparentemente semplice—1000 porte filtered—richiede un'interrogazione strutturata:

| Scenario | Sintomi | Verifica | |----------|----------|--------------| | Target down/nessuna route | Fallimenti ARP, ICMP unreachable dal gateway | ping, traceroute verso host adiacenti, nmap -sn host discovery | | Blocco stateful firewall | ICMP admin-prohibited consistente, timing uniforme | Variare source port (-g), frammentare (-f), o protocollo (-sO) | | Misconfigurazione dello scanner | Risultati autoconsistenti ma assurdi (es., localhost filtered) | nmap 127.0.0.1, verificare selezione interfaccia (-e) |

Il fallimento del VPN MSS clamping merita enfasi. La scansione attraverso tunnel senza consapevolezza del Path MTU genera pacchetti frammentati o sovradimensionati che i middlebox scartano. Se all filtered appare esclusivamente attraverso interfacce VPN, testare con nmap -sS --mtu 1400 o forzare il clamping all'interfaccia del tunnel. La scansione IPv6 fallisce analogamente: la selezione degli indirizzi link-local (fe80::/10) richiede il binding esplicito dell'interfaccia (nmap -e eth0 fe80::1%eth0), e molti script di Nmap defaultano a comportamento IPv4-only senza -6. L'errore Failed to resolve given IPv6 hostname indica spesso flag -6 mancante o percorsi IPv6 irraggiungibili, non assenza del target.

Troubleshooting delle Prestazioni: Isolamento dei Colli di Bottiglia

Le esplosioni di durata della scansione tracciano tipicamente a tre domini. La risoluzione DNS si blocca quando Nmap risolve inversamente ogni IP scoperto (-n disabilita questo; -R lo forza). Per range grandi, nmap -n è obbligatorio, con massdns esterno per gestire le operazioni di naming se richiesto.

I fallimenti di calcolo RTT emergono in percorsi satellitari, cellulari o congestionati. La stima RTT iniziale di Nmap (undocumented, tipicamente ~100ms a -T3) può sottostimare la latenza effettiva, innescando ritrasmissioni premature che aggravano la congestione. La calibrazione esplicita con nmap --initial-rtt-timeout 2s --max-rtt-timeout 5s per percorsi ad alta latenza previene questa spirale.

I colli di bottiglia nell'esecuzione degli script appaiono con --script vuln o http-enum contro liste grandi di host. Il motore esegue serialmente per host; la parallelizzazione richiede nmap --script-timeout 10m o il disaccoppiamento a nmap per discovery e script nse via nmap --script <script> --script-args=newtargets in passaggi secondari.

Metodologie di Verifica: Nmap come Ipotesi

Trattare ogni risultato Nmap come una claim falsificabile. La toolchain di verifica:

La scansione incrociata con netcat valida lo stato TCP indipendentemente:

# Nmap dichiara porta 443/tcp open; verificare con negoziazione manuale
nc -vz -w 5 <target> 443          # Timeout di connessione o successo?
echo "QUIT" | nc -q 1 <target> 443  # Validazione risposta di protocollo

La conferma tramite cattura pacchetti tcpdump fornisce verità di fondo per l'interpretazione di Nmap. Sintassi del filtro di cattura ottimizzata per verifica dello scanner:

# Cattura tutti i probe TCP e le risposte per il target 192.0.2.10
sudo tcpdump -ni eth0 -w nmap_verify.pcap \
  'host 192.0.2.10 and (tcp[13] & 2 != 0 or tcp[13] & 16 != 0 or icmp[icmptype] == icmp-unreach)'

# Analisi: il SYN ha ricevuto SYN-ACK, RST, o silenzio?
tcpdump -r nmap_verify.pcap -nn -tttt -v 'tcp port 443'

Questo cattura i flag SYN (tcp[13] & 2), SYN-ACK/RST (tcp[13] & 16 per ACK—raffinare con ulteriore bitmasking), e ICMP unreachables. Confrontare con il log di Nmap --packet-trace riga per riga.

La correlazione con strumenti secondari rompe il bias specifico dello strumento. masscan con il suo stack TCP separato può raggiungere porte che Nmap manca a causa di logiche di ritrasmissione differenti; zgrab2 o openssl s_client validano handshake TLS che gli script ssl-cert interpretano erroneamente. Per UDP, unicornscan con payload custom (-mU -r 3000) può elicitare risposte che i probe predefiniti di Nmap mancano.

Quando Nmap è Fondamentalmente a Scala Sbagliata

Le assunzioni architetturali di Nmap—affidabilità, completezza, scriptabilità—diventano passività a scala. Masscan sacrifica l'accuratezza per la velocità, trasmettendo senza attendere risposte, rendendolo adatto per censimento internet-wide (stimato 45 minuti per /0 a 100kpps). Zmap ottimizza ulteriormente per casi d'uso di ricerca, raggiungendo prestazioni line-rate con tracciamento minimo dello stato. Nessuno dei due sostituisce il service detection di Nmap; lo complementano come fasi di discovery.

Scanner di protocollo specializzati—ike-scan per ISAKMP, onesixtyone per brute-forcing di community SNMP, rdp-sec-check per negoziazione di sicurezza RDP—superano gli script NSE in profondità per la ricognizione single-protocol. Il rigore professionale è sapere quando la generalità di Nmap introduce tassi di errore inaccettabili, e selezionare lo strumento preciso per la misurazione richiesta.

Ogni riga di output esige questa domanda: quale osservazione contraddirebbe questa conclusione, e l'ho cercata?