--min-hostgroup <numhosts>
;
--max-hostgroup <numhosts>
(Adjust
parallel scan group sizes)Nmap ha l'abilità di effettuare port scan o version
scan su più host in parallelo. Lo spazio degli indirizzi IP
di destinazione viene diviso in gruppi e viene scansionato un
gruppo per volta. In genere gruppi di dimensioni maggiori
portano ad una migliore efficienza. Il lato negativo di tutto
ciò è che i risultati non possono essere mostrati all'utente
fino a quando l'intero gruppo non è stato esplorato
completamente. Quindi, se si lancia Nmap impostando la
dimensione del gruppo a 50, l'utente non vedrà alcun risultato
fino a quando i primi 50 host non sono stati completati (a meno
che non si selezioni la modalità verbose).
Di default, Nmap usa un compromesso per ovviare a questa
difficoltà. Inizialmente utilizza una dimensione di cinque
host in modo da mostrare i primi risultati velocemente,
dopodiché incrementa la dimensione fino ad un massimo di
1024. Il numero esatto dipende dalle opzioni che vengono
passate. Per ragioni di efficienza Nmap usa gruppi di
dimensione maggiore per UDP o per scansioni di porte TCP di
piccole dimensioni.
Nel caso in cui una dimensione massima del gruppo sia
specificata con --max-hostgroup
, Nmap non
oltrepasserà mai questo limite. Specificando invece una
dimensione minima con --min-hostgroup
obbligherà Nmap a usare dimensioni almeno equivalenti. Nmap
potrebbe tuttavia dover usare gruppi più piccoli di quelli
indicati se non ci dovessero essere abbastanza host di
destinazione rimanenti per un'interfaccia per raggiungere la
minima quota specificata. Entrambe le opzioni possono essere
impostate per mantenere la dimensione del gruppo all'interno
di un certo limite, anche se questo succede raramente.
Queste opzioni durante la fase di host discovery di una
scansione non hanno effetto; ciò include anche il plain ping
scan (-sn
). L'host discovery lavora sempre su
grandi gruppi di host per aumentare la velocità e
l'accuratezza.
L'utilizzo principale di queste opzioni è quello di
specificare una dimensione minima maggiore rispetto al default
in modo da rendere più veloce la scansione globale. Una scelta
piuttosto comune è 256 per una scansione di una rete di classe
C. Per una scansione con molte porte, eccedere questo numero
è improbabile che aiuti molto. Per una scansione con poche
porte invece, una dimensione di 2048 o più può essere
d'aiuto.
--min-parallelism <numprobes>
;
--max-parallelism <numprobes>
(Adjust probe parallelization)Queste opzioni controllano il numero totale di probe che
possono uscire dalla macchina sorgente per un host group. Esse
sono usate per port scanning e host discovery. Di default,
Nmap calcola un parallelismo ideale in continuo cambiamento, a
seconda delle performance della rete. Se c'è un elevato
numero di pacchetti che viene scartato, Nmap rallenta e lavora
su un numero minore di probe in uscita. Il numero ideale di
probe in uscita incrementa poi gradualmente fino a quando la
rete lo permette. Questa opzione limiti minimi o massimi alla
variabile. Di default, il parallelismo può arrivare ad
un minimo di 1 se la rete si dimostra essere poco affidabile;
può invece aumentare a diverse centinaia per una rete in
condizioni ottimali.
L'uso più comune consiste nell'impostare
--min-parallelism
ad un valore maggiore di 1
per accelerare le scansioni di reti o host che rispondono in
maniera non adeguata. È abbastanza rischioso giocare con
quest'opzione, in quanto impostandola ad un valore troppo alto
può influire negativamente sull'accuratezza. Impostandola
manualmente inoltre riduce l'abilità di Nmap di controllare
dinamicamente il parallelismo basandosi sulle condizioni della
rete. Un valore di 10 è abbastanza ragionevole, anche se in
genere le modifiche a questo parametro vengono usate come
ultima risorsa.
L'opzione --max-parallelism
viene
impostata a volte sul valore 1 per impedire a Nmap di inviare
più di un probe alla volta verso un determinato host. L'opzione
--scan-delay
(discussa in seguito), è un altro
modo per ottenere questo risultato.
--min-rtt-timeout <time>
,
--max-rtt-timeout <time>
,
--initial-rtt-timeout <time>
(Adjust probe
timeouts)Nmap mantiene un valore di timeout aggiornato per
determinare quanto ci vorrà per un probe response prima di
ritrasmettere il probe. Questo viene calcolato basandosi sui
tempi di response degli ultimi probe inviati. La formula si
trova al link «Idle
Scan Implementation Algorithms». Se la latenza
della rete dovesse oscillare troppo questo timeout può
crescere fino ad un valore di diversi secondi. Inoltre esso è
impostato inizialmente ad un valore abbastanza alto e potrebbe
restare su quel valore per tutto il tempo in cui Nmap effettua
la scansione su host che non rispondono.
Specificando limiti di --max-rtt-timeout
e di --initial-rtt-timeout
inferiori ai
valori di default è possibile ridurre di molto i tempi di
scansione. Questo è vero in particolare per scansioni di tipo
"pingless" (opzione -Pn
) e nei confronti di
reti particolarmente protette. Tuttavia, è bene non esagerare;
infatti la scansione può addirittura richiedere più tempo del
previsto nel caso in cui si specifichi un valore talmente basso
da resettare il timeout dei probe (e forzarne un nuovo invio)
mentre la risposta sta ancora arrivando.
Se tutti gli host sono su una rete locale, 100
millisecondi (--max-rtt-timeout 100ms
)è un
valore ragionevolmente aggressivo. Se nella scansione è
coinvolto qualche routing, sarebbe meglio effettuare un ping
preliminare dell'host (con l'utility ICMP ping o con un
generatore di pacchetti come Nping che può penetrare un
firewall più facilmente), e osservare poi il valore massimo di
andata/ritorno ("round trip") per un numero di pacchetti non
inferiore a 10. È quindi consigliato raddoppiare questo valore
per l'opzione --initial-rtt-timeout
e
triplicarlo o quadruplicarlo per l'opzione
--max-rtt-timeout
. In genere si preferisce
non impostare il maximum RTT al di sotto di 100 millisecondi,
indipendentemente dai tempi di ping. E nemmeno al di sopra di
1000 millisecondi.
L'opzione --min-rtt-timeout
è usata
molto raramente; essa può essere utile nel caso in cui una
rete è talmente poco affidabile che anche il default di Nmap
risulta essere troppo aggressivo. Poiché Nmap riduce il timeout
fino al valore minimo quando la rete sembra affidabile, questa
esigenza di solito non è necessaria e dovrebbe essere
indicata come bug alla mailing list nmap-dev.
--max-retries <numtries>
(Specify
the maximum number of port scan probe retransmissions)Quando Nmap non riceve risposta ad un port scan probe,
potrebbe significare che la porte è filtrata. O forse che la
risposta o il probe stesso si sono persi nella rete. È anche
possibile che l'host obiettivo abbia attivato dei limiti sul
traffico che bloccano la risposta. In questi questi, Nmap prova
nuovamente a ritrasmettere il probe iniziale e, se ritiene che
la rete sia poco affidabile, prova molte volte prima di passare
alla porta successiva. Nonostante il vantaggio
dell'accuratezza, tutto ciò prolunga i tempi di scansione.
Quando le performance sono al primo posto, si può velocizzare
le scansioni limitando il numero di ritrasmissioni consentite.
Si può addirittura indicare --max-retries 0
per disabilitare ogni ritrasmissione, anche se è consigliato
solo in quelle situazioni in cui la non risposta di alcune
porte e alcuni host è accettabile (ad esempio sondaggi interni
o test).
Di default (senza nessun template, opzione
-T
) vengono effettuate dieci ritrasmissioni.
Se la rete risulta affidabile e gli host obiettivo non hanno
limitazioni, Nmap solitamente effettua una ritrasmissione.
Quindi la maggior parte degli obiettivi non viene coinvolta
abbassando --max-retries
ad un valore basso,
ad esempio tre. Alcuni valori possono velocizzare sensibilmente
le scansioni di host piuttosto lenti. Di solito vengono perse
alcune informazioni quando Nmap scansiona le porte velocemente,
però è sempre meglio che lasciar scadere
--host-timeout
e perdere tutte le informazioni
dell'obiettivo.
--host-timeout <time>
(Give up on
slow target hosts)Alcuni host a volte richiedono un tempo estremamente
lungo per portare a termine una
scansione. Questo può essere dovuto a hardware o software
poco performante o inaffidabile, a limiti di traffico impostati
o a firewall troppo restrittivi. La minoranza degli host
sottoposti a scansione può richiedere la maggior parte del
tempo di scansione. A volte è preferibile risparmiare sul tempo
ed evitare questi host fin dal principio. Questo comportamento
viene forzato dall'opzione --host-timeout
seguito dal tempo dopo il quale non si vuole più aspettare. Ad
esempio si specifica un valore di 30m per avere la garanzia che
Nmap non sprechi più di mezz'ora su di un singolo host. Si noti
che Nmap può nel frattempo effettuare la scansione su altri
host durante quella mezz'ora, per cui non si tratta di tempo
completamente sprecato. Un host che dovesse andare in timeout
viene semplicemente saltato. Non vengono mostrati l'elenco
delle porte, il detection del sistema operativo né risultati di
version detection per quell'host.
--scan-delay <time>
;
--max-scan-delay <time>
(Adjust delay
between probes)Quest'opzione obbliga Nmap ad aspettare almeno il tempo
indicato tra i probe inviati ad un determinato host. Questo
risulta particolarmente utile nel caso di limitazioni sulla
frequenza dell'invio ("rate limiting"). Tra gli altri, in
particolare le macchine Solaris in genere rispondono a
scansioni UDP con un solo messaggio ICMP al secondo. Qualsiasi
altro probe inviato da Nmap durante questo intervallo di tempo
sarebbe quindi sprecato. Un valore di
--scan-delay
di 1s manterrà Nmap al di sotto
di questa particolare frequenza di invio di probe. Nmap
comunque cercherà di capire eventuali limiti sulla frequenza e
modificherà i ritardi sui probe di conseguenza, tuttavia non è
cattiva abitudine specificarlo sulla linea di comando quando
dovesse essere noto a priori il valore ottimale.
Quando Nmap aumenta lo scan delay in base al rate
limiting, la scansione rallenta drammaticamente. L'opzione
--max-scan-delay
indica il valore massimo di
delay che Nmap può adottare. Un valore basso di quest'opzione
può velocizzare Nmap, ma ci sono dei rischi: settarlo troppo
basso può portare a ritrasmissioni inutili e una possibile
perdita di dati da porte che hanno rate limiting molto
ridotti.
Un altro uso dell'opzione--scan-delay
è quello in cui si desidera evitare sistemi anti-intrusione
(IDS/IPS, "intrusion-detection" e "intrusion-prevention
system"). Questa tecnica viene utilizzata nella sezione
«
A practical example: bypassing default Snort 2.2.0
rules» per vincere il port scanner detector di
default in Snort IDS. Molti altri IDS possono essere sconfitti
con questo sistema.
--min-rate <number>
;
--max-rate <number>
(Directly control the
scanning rate)Il timing dinamico di Nmap fa un buon lavoro trovando una
velocità adeguata a ciò che si sta scansionando. Alle volte,
però, può succedere di conoscere uno scanning rate appropriato
per quella determinata rete, oppure bisogna finire una
scansione in un tempo preciso. O forse si vuole impedire ad
Nmap di scansionare troppo velocemente. Le opzioni
--min-rate
e --max-rate
sono
state create proprio per queste situazioni.
Quando viene definita l'opzione
--min-rate
Nmap farà del suo meglio per
inviare i pacchetti non al di sotto del limite di frequenza
impostato. L'argomento è un numero reale positivo che
rappresenta la frequenza di invio dei pacchetti in
pacchetti/secondo. Per esempio, indicando
--min-rate 300
significa che Nmap proverà a
mantenere una frequenza di invio di almeno 300 pacchetti al
secondo. Quest'opzione non impedisce ad Nmap di aumentare la
frequenza se le condizioni lo permettono.
Viceversa, --max-rate
forza la
frequenza di invio dandogli un limite massimo. Utilizzare
--max-rate 100
, ad esempio, per limitare
l'invio a 100 pacchetti al secondo su una rete veloce. Usare
--max-rate 0.1
per una scansione lenta, un
pacchetto ogni dieci secondi. Entrambe le opzioni
--min-rate
e --max-rate
mantengono la frequenza all'interno del range
specificato.
Queste due opzioni sono globali, hanno effetto cioè
sull'intera scansione, non sugli host individuali. Vanno ad
agire sui port scan e gli host discovery. Altre feature, come
l'OS detection, hanno le loro opzioni di timing.
Ci sono due casi in cui la frequenza potrebbe
scendere sotto il minimo richiesto. Il primo è impostare la
frequenza minima più alta di quanto Nmap riesca ad inviare, il
che dipende dall'hardware in uso. In questo casto Nmap invierà
i pacchetti il più velocemente possibile, ma bisogna comunque
essere consapevoli che ciò potrebbe causare un calo
dell'affidabilità. Il secondo caso è quando Nmap non ha nulla
da inviare, ad esempio alla fine di uno scan quando gli ultimi
probe sono stati inviati ed Nmap sta aspettando una risposta
o che vadano in time out. È normale che lo scanning rate cali
alla fine di una scansione o tra hostgroups. La frequenza di
invio potrebbe inoltre superare temporaneamente il massimo
prefissato, per far fronte a delay improvvisi, ma nella media
rimarrà comunque entro i limiti.
Specificare un rate minimo, è una cosa da fare con
attenzione. Effettuare una scansione più velocemente di quanto
una rete possa supportare potrebbe portare a risultati
inaffidabili. In alcuni casi, una frequenza troppo alta può
portare ad un scansione più lenta rispetto
ad una scansione con un rate più basso. Questo perché
l'algoritmo adaptive
retransmission di Nmap potrebbe rilevare una
congestione della rete causata da un eccessivo scanning rate e
aumentare il numero di ritrasmissioni per mantenere una certa
affidabilità. Quindi anche se i pacchetti verranno inviati
velocemente, ne verranno comunque inviati di più. Limitare il
numero massimo ritrasmissioni con l'opzione
--max-retries
se si deve rispettare un tempo
massimo per la scansione totale.
--defeat-rst-ratelimit
Molti host usano da tempo delle funzionalità di "rate
limiting" (limitazioni alla frequenza) per ridurre il numero di
messaggi di errore ICMP che mandano (ad esempio gli errori
"port-unreachable"). Alcuni sistemi hanno iniziato ad applicare
le stesse tecniche all'invio di pacchetti RST (reset). Queste
tecniche possono rallentare di molto Nmap poiché esso
continuerà a calibrare la gestione dei timing per gestire
queste limitazioni di frequenza. Si può quindi indicare a Nmap
di ignorare questi rate limits (per i port scan come il SYN
scan, che non considerano le porte
silenziose come aperte
)
mediante l'opzione
--defeat-rst-ratelimit
.
L'utilizzo di quest'opzione può ridurre la precisione di
uno scan, poiché alcune porte potrebbero restituire uno stato
di non-risposta perché Nmap non è rimasto in attesa abbastanza
a lungo a causa di meccanismi di rate-limiting dei pacchetti
RST. Con una scansione di tipo SYN le porte "mute" (dalle quali
non si è ricevuto un RST) in questo caso vengono indicate con
filtered
piuttosto che
closed
. Quest'opzione è
utile solo quando si è interessati alle porte aperte, e la
distinzione tra porte closed
e filtered
non è di alcun
interesse rispetto al tempo che richiede.
--nsock-engine
epoll|kqueue|poll|select
Forza l'utilizzo di un determinato "nsock IO multiplexing
engine". Solo per il "select(2)
-based fallback
engine" viene garantita la compatibilità con il sistema in uso.
Gli engine vengono dichiarati dopo il nome del "IO management
facility" cui fanno riferimento. Gli engine attualmente
implementati sono epoll
,
kqueue
, poll
e select
, ma non saranno tutti presenti
su tutte le piattaforme. Utilizzare nmap -V per sapere quali engine sono
supportati.
-T
<paranoid|sneaky|polite|normal|aggressive|insane>
(Set a timing template)Mentre le opzioni mostrate nella precedente sezione sono
molto utili ed efficaci alcuni potrebbero trovarle troppo
complicate da usare. Inoltre, la scelta dei valori più
appropriati può a volte richiedere più tempo della scansione
stessa che si sta cercando di ottimizzare. Nmap offre quindi un
approccio più semplice mediante sei "timing templates", ovvero
opzioni pre-impostate per regolare l'aggressività della
scansione. Esse si specificano mediante l'opzione
-T
seguita dal numero del template
corrispondente o dal suo nome. Essi sono: paranoico (0),
furtivo (1), educato (2), normale (3), aggressivo (4) e
folle (5). I primi due vengono usati per evitare i sopracitati
sistemi anti-intrusione (IDS). La modalità "gentile" rallenta
la scansione in modo da usare meno banda e risorse sulla
macchina bersaglio. La modalità "normale" è di default
(e pertanto l'opzione -T3
non modifica nulla).
La modalità "aggressiva" incrementa la velocità assumendo che
si è su una rete veloce ed affidabile. Infine la modalità
"folle" dà per scontato che si è su una rete estremamente
veloce ed affidabile o che si vuole sacrificare l'accuratezza
in nome della velocità.
Questi template consentono all'utente di specificare
quanto aggressivi si desidera essere, lasciando al tempo stesso
a Nmap il compito di scegliere i valori più appropriati.
I template inoltre effettuano piccoli aggiustamenti sui timing
per i quali non esistono opzioni che ne consentono il
controllo. Ad esempio, l'opzione -T4
impedisce
al ritardo dinamico per una scansione di andare al di sotto
della soglia dei 10 millisecondi per le porte TCP, e l'opzione
-T5
limita questo valore a 5 millisecondi. I
template possono essere usati insieme a controlli più precisi
a patto che il template venga specificato per primo.
Altrimenti i valori impostati dal template potrebbero
sovrascrivere quelli specificati dall'utente. Si raccomanda di
usare l'opzione -T4
nel caso in cui si
desideri effettuare scansioni di reti abbastanza recenti e
affidabili; inoltre è consigliabile mantenere quell'opzione
(intesa come inserita all'inizio dei comandi) anche qualora si
dovessero aggiungere controlli più precisi in modo da
beneficiare da tutti i piccoli miglioramenti che dovessero
intervenire.
Se la propria connessione è a banda larga o di tipo
ethernet, si raccomanda di usare sempre l'opzione
-T4
. Alcuni prediligono anche l'opzione
-T5
, nonostante per i più sia troppo
aggressiva. Altri a volte usano l'opzione -T2
perché credono che sia meno propensa a mandare in crash un
host o perché si considerano persone educate. Spesso essi non
si rendono conto di quanto è lenta l'opzione -T
polite
; una scansione di questo tipo può impiegare
anche dieci volte il tempo richiesto per una scansione di
default. Crash di host e problemi di banda sono rari con le
opzioni di timing di default (opzione -T3
) e
pertanto è l'opzione consigliata a chi deve effettuare
scansioni senza dare troppo nell'occhio. Omettere una
scansione di tipo version detection è molto più efficiente
del giocare con i valori di timing per ridurre i problemi
sopracitati.
Mentre le opzioni -T0
e
-T1
potrebbero essere utili per evitare gli
allarmi di un IDS, esse richiederanno un tempo estremamente
lungo per portare a termine una scansione di migliaia di host o
di porte. In una situazione di questo tipo si suggerisce di
lavorare sui valori esatti di timing richiesti piuttosto che
avvalersi delle opzioni preimpostate nelle opzioni
-T0
e -T1
.
Gli effetti principali dell'opzione T0
sono quello di serializzare la scansione in modo da affrontare
una sola porta alla volta, e al tempo stesso quello di
attendere cinque minuti tra l'invio di un probe e il
successivo. Le opzioni T1
e
T2
sono simili ma attendono rispettivamente
15 secondi e 0.4 secondi tra un probe e l'altro. L'opzione
T3
è il comportamento di default di Nmap
(che include il parallelismo). L'opzione T4
ha lo stesso risultato dell'impostare
--max-rtt-timeout 1250ms --initial-rtt-timeout
500ms --max-retries 6
e di impostare il ritardo
massimo per una scansione TCP a 10 millisecondi. Infine
l'opzione T5
è equivalente a
--max-rtt-timeout 300ms --min-rtt-timeout 50ms
--initial-rtt-timeout 250ms --max-retries 2 --host-timeout
15m
e ad impostare il massimo ritardo TCP (maximum
delay) a 5 millisecondi.