Analisi approfondita del rilevamento del servizio e della versione

La Meccanica della Costruzione e Corrispondenza delle Probe

Il rilevamento delle versioni in Nmap opera attraverso un sofisticato sistema di corrispondenza probe-prototipo definito nel file nmap-service-probes. Comprendere la struttura di questo file rivela come Nmap identifichi effettivamente i servizi, piuttosto che trattarlo semplicemente come una scatola nera.

Ogni voce di probe segue una sintassi precisa. La direttiva Probe si avvia con un protocollo (TCP o UDP), un nome univoco e la stringa letterale da inviare:

Probe TCP GetRequest q|GET / HTTP/1.0\r\n\r\n|

Il delimitatore q| utilizza | come carattere di racchiusione; qualsiasi carattere può svolgere questa funzione. Nmap supporta sequenze di escape incluse \r, \n, \t, e rappresentazioni ottali/esadecimali (\x0D, \0D). Questo è importante perché le probe spesso richiedono sequenze di byte esatte per ottenere risposte identificabili da servizi selettivi.

Le direttive Match formano il nucleo analitico. Ogni match contiene un nome di servizio, un'espressione regolare, un'estrazione opzionale della versione e un punteggio di confidenza:

match http m|^HTTP/1\.[01] \d\d\d.*?\r\nServer: Apache/([\w._-]+)|s p/Apache/ v/$1/

Il pattern m|...| utilizza | come suo delimitatore. Il flag finale s abilita . a corrispondere con i newline—critico per banner multi-riga. Le catture tra parentesi alimentano le variabili di estrazione della versione: $1 attraverso $9 popolano i campi v/ (versione), i/ (info), h/ (hostname), o/ (sistema operativo), d/ (tipo di dispositivo), e cpe:/.

Le Softmatch (softmatch) differiscono in modo cruciale: identificano una famiglia di servizi senza estrarre dettagli della versione, permettendo a Nmap di saltare le probe incompatibili e procedere verso quelle più specifiche. Questa classificazione gerarchica—softmatch generico seguito da hard match preciso—riduce il traffico delle probe mantenendo l'accuratezza.

Il file nmap-service-probes organizza le probe per raretà. Le probe comuni (raretà 1-4) vengono eseguite durante scansioni normali -sV; le probe di rarità superiore si attivano solo con l'elevazione --version-intensity o quando le probe di rarità inferiore non producono corrispondenze.

Rilevamento del Wrapper SSL/TLS e Probing dei Servizi Cifrati

I servizi moderni nascondono sempre più spesso dietro la cifratura TLS, il che storicamente costringeva gli analisti a concatenare strumenti esterni (openssl s_client, ncat --ssl) prima del rilevamento della versione. La negoziazione SSL integrata di Nmap elimina questa frizione attraverso il rilevamento trasparente del wrapper.

Quando Nmap si connette a un servizio, analizza la risposta iniziale per indicatori di handshake TLS—specificamente il byte del tipo di contenuto 0x16 (handshake) e i byte di versione (0x0301 per TLS 1.0, 0x0303 per TLS 1.2, ecc.) nel record layer. Rilevando questo pattern, Nmap avvia un handshake TLS completo utilizzando la sua integrazione OpenSSL embedded, quindi instrada le probe successive attraverso il canale cifrato.

Questo permette il probing diretto di HTTPS, SMTPS, IMAPS, POP3S e XMPPS senza intervento manuale:

nmap -sV --version-intensity 7 -p 443,465,993,995 target.example.com

La sequenza delle probe si adatta automaticamente: Nmap invia prima una probe generica, rileva il wrapping TLS, completa l'handshake con la negoziazione appropriata della suite di cifratura (degradando solo quando necessario per compatibilità), quindi ritrasmette le probe del livello applicazione attraverso il tunnel cifrato. L'estrazione della versione procede normalmente, con le corrispondenze regex applicate alle risposte decifrate.

Per i servizi su porte non standard con TLS, la softmatch del servizio ssl attiva il tunneling delle probe indipendentemente dal numero di porta. Un server web sulla porta 8443 riceve trattamento identico a uno sulla 443, a condizione che l'handshake TLS abbia successo. Nmap gestisce anche gli upgrade STARTTLS per protocolli come SMTP, FTP e XMPP attraverso probe dedicate che emettono comandi STARTTLS prima di avviare il TLS.

In modo critico, il parsing del certificato avviene indipendentemente: anche quando il probing del livello applicazione fallisce, Nmap estrae i nomi del soggetto, i periodi di validità e le informazioni dell'emittente dall'handshake TLS stesso, contribuendo all'identificazione del servizio.

RPC Grinding e Strategia di Probing Sequenziale

I servizi SunRPC (ONC RPC) presentano sfide uniche perché tipicamente si registrano con rpcbind (portmapper) piuttosto che esporre direttamente le informazioni di versione. La tecnica di RPC grinding di Nmap affronta questo problema attraverso l'enumerazione sistematica dei numeri di programma.

La sequenza di probe standard per i servizi RPC sospetti:

Invio delle probe: Invio di una chiamata di procedura NULL alla porta target con numeri di programma variabili
Analisi della risposta: Interpretazione di PROG_UNAVAIL (programma non disponibile) versus PROC_UNAVAIL (programma noto, procedura non disponibile) versus risposta NULL di successo
Enumerazione delle versioni: Identificato un numero di programma valido, probing degli intervalli di versione per determinare le versioni di protocollo supportate

Nmap mantiene un database di numeri di programma RPC noti (file rpc-names), ma il grinding può scoprire servizi RPC non registrati o personalizzati attraverso enumerazione brute-force. L'impostazione --version-intensity controlla direttamente la completezza del grinding—intensità più elevate espandono lo spazio di ricerca dei numeri di programma e le probe degli intervalli di versione.

La strategia sequenziale si rivela necessaria perché i servizi RPC mancano dell'identificazione basata su banner comune ad altri protocolli. Una corrispondenza sulla porta 2049 richiede di confermare se serve programmi nfs, mountd, nlockmgr, o status, ciascuno con numeri di programma distinti. Il file delle probe di Nmap contiene probe RPC specializzate con classificazioni di rarità rpc che si attivano solo durante questa fase di grinding.

Livelli di Intensità di Scansione: Lo Spettro Tempo/Accuratezza

Il parametro --version-intensity (0-9) controlla uno spazio di compromesso multi-dimensionale:

| Intensità | Comportamento | Impatto Tipico sulla Durata | |-----------|---------------|-----------------------------| | 0 (-sV --version-intensity 0) | Solo softmatch; nessuna estrazione della versione | Minimo; ~1-2 probe per porta | | 1-2 | Probe più comuni; copre ~60% dei servizi | 2-4 probe per porta | | 3-5 (default con -sV) | Probe di rarità standard (≤5) | 5-15 probe per porta | | 6-7 | Set di probe espanso; RPC grinding abilitato | 15-40 probe per porta | | 8-9 (--version-all) | Tutte le probe indipendentemente dalla rarità; RPC grinding esaustivo | 50+ probe per porta; significativo aumento del tempo |

La selezione dell'intensità richiede giudizio contestuale. Una scansione perimetrale di migliaia di host giustifica intensità 3-5; una valutazione mirata di un server database critico giustifica intensità 8-9. I flag --version-light (intensità 2) e --version-all (intensità 9) forniscono scorciatoie convenienti.

I timeout delle probe compongono questo calcolo. Nmap applica --version-intensity sia alla selezione delle probe che alla pazienza del timeout—intensità più elevate attendono più a lungo per servizi lenti. Regola --version-timeout indipendentemente quando hai bisogno di ampiezza delle probe senza attese prolungate.

Parsing Applicativo, Estrazione della Versione e Punteggio di Confidenza

L'output di Nmap riflette una confidenza sfumata piuttosto che una certezza binaria. Il sistema di punteggio di confidenza opera a livelli multipli:

La confidenza di corrispondenza deriva dalla specificità della regex. Un pattern che corrisponde esattamente a Apache/2.4.41 ottiene punteggio più alto di uno che corrisponde semplicemente a Apache. Le catture tra parentesi con classi di caratteri rigide ([\w._-]+) elevano la confidenza rispetto ai pattern permissivi (.*).

L'assegnazione CPE (Common Platform Enumeration) aggiunge validazione: l'estrazione CPE di successo (cpe:/a:apache:http_server:2.4.41) conferma la parsabilità della versione contro database noti. CPE mancante suggerisce stringhe di versione non standard o build personalizzate.

Interpretazione critica dell'output:

PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)

La parentesi (Ubuntu) deriva dalla cattura i/ (info), non v/ (versione). La linea http-server-header prefissata da pipe mostra l'header grezzo per verifica manuale. Le discrepanze tra il campo VERSION e l'output dello script meritano investigazione—Nmap potrebbe aver affinato la sua corrispondenza dopo il rilevamento iniziale.

Quando la confidenza scende al di sotto della soglia, Nmap aggiunge ? al nome del servizio o emette service unrecognized despite returning data. Questo si verifica con banner modificati, build patchate o fork proprietari che alterano le stringhe di identificazione senza cambiare il comportamento del protocollo.

Limitazioni e Verifica Critica

L'inganno deliberato pervade l'infrastruttura moderna. I servizi che riportano versioni errate—comune in ambienti attenti alla sicurezza—sconfiggono il pattern matching senza analisi comportamentale a livello di protocollo. Un server Apache patchato che restituisce nginx/1.18.0 nel suo header Server verrà identificato erroneamente a meno che le probe aggiuntive di Nmap (analisi ETag, ordinamento degli header, ispezione delle pagine di errore) non rivelino discrepanze comportamentali.

I backend bilanciati del carico creano apparente incoerenza di versione: scansioni sequenziali colpiscono server diversi con versioni software divergenti. Gli script http-methods o ssl-cert a volte espongono la diversità dei backend attraverso differenze nella catena di certificati o variazioni nei metodi consentiti.

La randomizzazione delle impronte honeypot sfrutta attivamente il database di Nmap. Strumenti come honeyd e piattaforme di inganno commerciali ciclicano tra banner di servizio, colpendo occasionalmente stringhe di versione reali ma mancando delle corrispondenti implementazioni di protocollo. La verifica comportamentale—esercitando effettivamente le funzionalità di protocollo implicate dalla versione—li espone: un OpenSSH 8.2 dichiarato che accetta negoziazioni KEX algorithm non valide si rivela da sé.

Tecniche di verifica manuale quando la confidenza è sospetta:

# Acquisizione diretta del banner con timeout esplicito
nc -w 3 target 22 | head -5

# Test comportamentale specifico del protocollo
ssh -v -o BatchMode=yes -o ConnectTimeout=3 target 2>&1 | grep "Remote protocol"

# Esame del certificato TLS indipendentemente dal rilevamento della versione
openssl s_client -connect target:443 -servername target </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A2 "Subject Alternative Name"

Incrocia l'output di Nmap con feed CPE e database di vulnerabilità. Un servizio identificato con 90% di confidenza come vsftpd 3.0.3 richiede correlazione CVE; la stessa identificazione al 50% di confidenza con anomalie comportamentali suggerisce di scansionare l'hash di rilascio effettivo del vendor per confermare la provenienza della build.