La scansione TCP Nmap riduce la percentuale di avanzamento

1

Sto eseguendo una scansione TCP su una rete e ho notato che nmap ha diminuito la percentuale di avanzamento.

Il comando è: nmap -A -sT 10.0.0.1-254 -oG scan.txt

Tra l'output che ho trovato:

Stats: 0:13:37 elapsed; 211 hosts completed (43 up), 43 undergoing Connect Scan
Connect Scan Timing: About 98.48% done; ETC: 04:04 (0:00:13 remaining)
Stats: 0:17:53 elapsed; 211 hosts completed (43 up), 43 undergoing Connect Scan
Connect Scan Timing: About 98.47% done; ETC: 04:09 (0:00:17 remaining)

Questo può essere ignorato come una fluttuazione, o c'è qualcos'altro sulla scansione in corso, non so?

    
posta SaAtomic 02.11.2016 - 09:15
fonte

3 risposte

3

Le statistiche di completamento percentuale di Nmap sono basate sul numero di cose completate diviso per il numero di cose tentate più il numero di cose da fare. Durante una scansione delle porte, le "cose" sono le sonde che vengono inviate. Se Nmap avesse completato 94 di 100 sonde, la percentuale sarebbe stata del 94%. Se poi invia una nuova sonda, la parte completata è ancora 94/100, ma la parte tentata è 0/1. La frazione totale sarebbe 94/101, o 93%.

Potrebbe sembrare un modo scarso di farlo, ma funziona piuttosto bene dato che Nmap invia molte sonde contemporaneamente e potrebbe cambiare il numero di sonde che intende provare in qualsiasi momento in base alla risposta del bersaglio.

    
risposta data 02.11.2016 - 15:05
fonte
2

Viene calcolata la frazione di completamento per host ( scan_engine.cc UltraScanInfo::getCompletionFraction() ) as :

 ports_finished * ( maxtries - 1 ) + probes_sent
 _______________________________________________
             maxtries * numprobes

La percentuale di completamento totale viene calcolata da questo attraverso tutti gli host. In una scansione TCP ( -sT ) il numero di sonde numprobes è fissato al numero di porte ( scan_engine.cc UltraScanInfo::numProbesPerHost() ) e non cambia mai dopo l'inizializzazione, quindi maxtries è il termine interessante del calcolo. ports_finished e probes_sent sono contatori incrementali, il precedente funziona a 1.0 quando ports_finished == probes_sent == numprobes . numprobes sarà 1000, il numero predefinito di sonde TCP nell'esempio che hai fornito.

Se maxtries aumenta (a causa del timeout e riprova) la quantità stimata di lavoro da fare aumenta, e quindi la frazione di lavoro completata diminuisce. ( --max-retries può controllare questo, anche se con -sT per la connessione TCP dallo stack IP OS connect() alcuni degli altri parametri timeout / retry che i supporti di nmap sono inefficaci).

Il conteggio di maxtries non è ingenuo, è il limite massimo di tentativi (+1) per una porta esplorata con successo nella scansione fino a quel momento. Se aggiungi -d (debug) vedrai il messaggio "Aumento di max_successful_tryno per 1.2.3.4 a 1 (caduta di pacchetti)". Questo non è lo stesso messaggio di "Aumento del ritardo di invio ...". Probabilmente vedrai entrambi i messaggi quando c'è una perdita di pacchetti durante una scansione.

Quello che hai visto allora è un probe TCP riuscito per un host, ma ha richiesto un nuovo tentativo, si è verificato tardi nella scansione ed è riuscito ad aumentare il limite superiore della stima del lavoro. Probabilmente ha corretto il completamento di oltre l'1% e la perdita di pacchetti probabilmente causa un aumento dei timeout, riducendo la velocità di scansione. Sono trascorsi circa 4 minuti tra le due linee di stato, quindi il calo nel completamento non era semplicemente dello 0,01%.

Il tempo di scansione del servizio è un calcolo separato.

    
risposta data 07.11.2016 - 19:32
fonte
0

Consiglierei di creare l'ultima versione di Nmap dal sorgente e testarla.

Se persiste ancora, segnala all'autore con l'intera riga di comando.

    
risposta data 02.11.2016 - 10:56
fonte

Leggi altre domande sui tag