Nmap ma schopnost sucasne scanovat porty alebo verzie viacerych hostitelskych stanic a to takym, sposobom, ze sa cielovy rozsah IP adries rozdeli do skupin a potom sa scanuje jedna skupina sucasne. Vo vseobecnosti su efektivnejsie vacsie skupiny, no nevyhodou je, ze vysledky nemozu byt poskytnute, kym nie je ukoncene cela skupina. cize ak Nmap zacne so skupinou velkosti 50, pouzivatel nedostane ziadnu spravu (okrem updatov v mode verbose) az kym nie je ukoncenych vsetkych 50 hostitelskych stanic.

V predvolenom nastaveni riesi Nmap tento konflikt kompromisom. Zacne skupinou o pocte 5, takze prve vysledky sa dostavia rychlo a potom sa velkost skupiny zvysi na 1024. Presne predvolene cisla zavisia od zadanych parametroch. Z dovodov efektivity pouziva Nmap rozsiahle skupiny pre UDP scany alebo malo portove TCP scany.

Po zadani maximalnej velkosti skupiny pomocou parametra --max_hostgroup Nmap nikdy neprokroci tuto hodnotu. Po zadani minimalnej velkosti skupiny parametrom --min_hostgroup nebude Nmap pouzivat mensie skupiny ako bolo zadane. Ak vsak nie je dostatok hostitelskych stanic, Nmap moze pracovat s mensimi skupinami ako specifikovane parametrom. Aj ked je to zriedkavo vyuzivane, oba parametre mozu byt pouzite sucasne na specifikovanie rozsahu skupiny.

Hlavne pouzitie tychto parametrov je specifikacia vacsieho minima velkosti skupiny, takze plny scan pobezi rychlejsie. Vseobecna volba velkosti minima na scan porcii siete triedy C je cislo 256. Nie je obvykle prilis uzitocne zvysovat toto cislo, ak sa jedna o scan s mnohymi portmi. Pri scanoch s par cislami portov je velkost skupiny hostitelskych pocitacov rovna 2048 alebo viac prospesna.

Tieto parametre ovladaju absolutny pocet testov, co moze byt nedokoncene pre skupinu hostitelskych pocitacov. Pouzivaju sa pri scanovani portov a zistovenie hostitelskych pocitacov. V povodnom nastaveni pocita vzdy sa meniaci idealny stav paralelizmu v zavislosti na vykone siete. Ak su pakety zahadzovane, Nmap spomali a povoli menej neukoncenych scanov. Idealny pocet testov pri dobrych podmienkach v sieti pomaly stupa. Tieto parametre urcuju na tuto premennu minimalnu a maximalnu hranicu. V predvolenom nastaveni sa idealny paralelizmus moze znizit az na 1, ak sa sietove testy javia ako nespolahlive a na druhej strane idealizmus stupa pri vybornych podmienkach.

Najcastejsim pouzitim je nastavenie parametra --min_parallelism na vyssiu hodnotu ako je 1 kvoli urychleniu scanovania pomalych hostitelskych stanic alebo sieti. Je to riskantny parameter na zabavu, pretoze prilis vysoka hodnota moze ovplyvnit presnost a takisto schopnost Nmapu ovladat paralelizmus dynamicky podla sietovych podmienok. Hodnota desat moze byt rozumna, hoci tuto hodnotu nastavujem len ako poslednu moznost.

Parameter --max_parallelism je niekedy nastaveny na 1, aby sa predislo odosielaniu viac ako jedneho testu sucasne. Moze sa to hodit v kombinacii s parametrom --scan_delay (rozoberanom nizsie), hoci tento druhy parameter je dostatocne silny, aby sam sluzil svojmu ucelu.

Nmap si uchovava hodnotu casoveho intervalu kvoli urceniu, ako dlho bude cakat na odpoved testu predtym ako to vzda alebo vykona retransmisiu testu. Pocita sa to na zaklade casov odpovedi predchadzajucich testov. Ak je latencia siete vyznamnym faktorom a meni sa, tento casovy interval narastie na niekolko sekund. Takisto zacina na opatrnej(vysokej) urovni a ak Nmap scanuje neodpovedajuce hostitelske stanice, moze to na nej aj chvilu ostat.

Tieto parametre maju hodnotu v milisekundach alebo je mozne pridat argument jednotky s, maleboh to a takto sa cas specifuje v sekundach, minutach alebo hodinach. Specifikovanie nizsich hodnot parametrov--max_rtt_timeout a --initial_rtt_timeout ako predvolene hodnoty moze vyznamne skratit casy scanov, co plati hlavne pre scany bez pingu (-P0) a dalej pre velmi filtrovane siete, nie je vsak dobre zadavat prilis kratke hodnoty, pretoze potom moze scan pozadovat viac casu ako je specifikovane a pre vela testov vyprsi casovy interval, zatial co odpoved je stale na ceste.

Ak su vsetky hostitelske stanice v lokalnej sieti, rozumna hodnota intervalu je 100 milisekund --max_rtt_timeout. Ak je zahrnute routovanie, je potrebne najprv vykonat ping hosta bud pomocnym programom ICMP ping alebo prisposobenym programom pre tvorenie paketov ako napr. hping2, ktory sa pravdepodobnejsie dostane cez firewall. Vsimnite si maximalny cas hodnoty RTT (Maximum Round Trip) asi 10 paketov. Tuto hodnotu mozete zdvojnasobit pre --initial_rtt_timeout a stroj- alebo stvornasobit pre parameter--max_rtt_timeout. Vseobecne nenastavujem tento parameter maximum rtt pod 100ms, bez ohladu na hodnoty pingov, a ani ich nezvysujem nad 1000ms.

Parameter --min_rtt_timeout je malokedy pouzivany. Moze sa zist, ked je siet taka nespolahliva, ze aj predvolena hodnota Nmapu je prilis agresivna. Kedze vsak Nmap pri spolahlivej sieti znizuje casovy interval na minimum, tento parameter nie je potrebny a jeho pouzitie by sa malo nahlasit ako bug do mailingu listu nmap-dev.

Ak Nmap nedostane odpoved na test scanu portov, moze to znamenat , ze port je filtrovany alebo ze bol test alebo odpoved jednoducho stratena po sieti. Je mozne tiez, ze cielova stanica obmedzenie poctu odpovedi a to docasne zablokovalo odpoved, takze sa Nmap opatovna pokusi poslat pociatocny test. Ak Nmap detekuje slabu sietovu spolahlivost, moze sa pokusit o retransmissiu viackrat pred ukoncenim snahy. Na jednej strane to zvysuje presnost, no takisto aj cas scanov. Ak je kriticky vykon, scany mozu byt urychlenie limitovanim povoleneho poctu retransmisii. Retransmisiam sa zabrani parametrom --max_retries 0, no zriedkakedy sa to odporuca.

Predvolena hodnota (bez parametru-T) je 10 ten retransmisii. Ak sa siet zda byt spolahliva a cielove stanice neobmedzuju pocet odpovedi, Nmap obycajne vykona len jednu retransmisiu, takze vacsina scanov ani nie je ovplyvnena, ak sa parameter --max_retries znizi na 3. Tieto hodnoty dokazy podstatne zrychlit scany pomalych (s obmedzenim poctu odpovedi) hostitelskych stanic. Ak Nmap prilis skoro zanechava testy portov, obycajne sa stracaju nejake informacie, hoci moze to stale moze byt uprednostnovane pred situaciou, kde uplynie interval parametru --host_timeout a stratia sa vsetky informacie o cielovej stanici.

Niektore hostitelske stanice jednoducho potrebuju dlhy cas na to, aby boli prescanovane, co moze byt dosledkom zleho vykonu alebo nespolahliveho sietoveho hardwaru/softwaru, obmedzeniu poctu paketov alebo obmedzujuceho firewallu. Najpomalsich malo percent scanovanych hostitelskych stanic moze zabrat podstatu casu scanu. Niekedy je lepsie orezat tieto straty casu a preskocit taketo stanice uz na zaciatku. Da sa to dosiahnut zadanim parametra --host_timeout s pozadovanym poctom milisekund cakania. Alternativne je mozne pripojit argument jednotky s, m aleboh to , cim sa casovy interval specifikuje v sekundach, minutach alebo hodinach. Ja casto specifikujem hodnotu 30m, aby Nmap neplytval viac ako polhodinou na 1 stanicu. Vsimnite si, ze Nmap moze sucasne scanovat dalsie hostitelske stanice, takze to nie je uplna strata casu. Hostitelska stanica, ktorej casovy interval vyprsi sa vynecha a nezobrazi sa pre nu tabulka portov, detekcia OS, ani detekcia verzie.

Tento parameter sposobi, ze Nmap bude cakat aspon zadany hodnotu v milisekundach medzi odoslanim dalsieho testu hostitelskej stanice. Tak ako aj pri inych parametroch casu, aj tu je mozne pripojit s, maleboh ako argument na specifikovanie oneskorenia v sekundach, minutach alebo hodinach namiesto ms. Hodi sa to hlavne v pripade obmedzenia poctu odpovedi. Pocitace so systemom Solaris ako aj niektore ine obycajne na test UDP scanu odpovedia jednou ICMP spravou za sekundu. Vsetko co sa odosle Nmapom navyse, bude stratene. Parameter --scan_delay nastaveny na 1s udrzi Nmap na takejto pomalej rychlosti. Nmap sa pokusi detekovat obmedzenie a priposobit oneskorenie scanu podla toho, ale nie je na skodu specifikovat to explicitne, ak uz viete, aka rychlost je najvhodnejsia.

Ak Nmap prisposobuje oneskorenie scanu smerom nahor pri obmedzeni rychlosti odpovedi, scan sa dramaticky spomali. Parameter--max_scan_delay specifikuje najvacsie oneskorenie, ktore povoli Nmap. Nastavenie prilis nizkej hodnoty moze pri zavedenej obmedzenej rychlosti odpovedi viest k zbytocnym retransmisiam paketov a moznym vynechanym portom.

Dalsie pouzitie parametra --scan_delay je vyhnut sa systemom detekcie (IDS) a narusenia (IPS) zalozenych na prahovej hodnote.

Je sice pravda, ze vyssie rozoberane jemne casove ovladanie scanov je mocne a ucinne, no niektori ludia to povazuju za dezorientujuce. Niekedy dokonca moze volenie primeranych hodnot zabrat viac casu ako scan, ktory sa pokusat optimalizovat, a tak Nmap ponuka jednoduchsi pristup so siestimi sablonami. Je ich mozne specifikovat parametrom -T a ich cislami(0 - 5) ci menami. Nazvy sablon tu paranoid (0), sneaky (1), polite (2), normal (3), aggressive (4) a insane (5). Prve dve su urcene pre obidenie systemov IDS. Mod Polite sa spomali, ked scan pouziva mensiu sirky pasma a prostriedkov cieloveho pocitaca. Mod Normal je predvolenym a teda -T3 neurobi ziadnu zmenu. Mod Aggressive urychli scan predpokladom, ze ste na rozumne rychlej a spolahlivej sieti. Konecne mod Instane predpoklada, ze ste na vynimocne rychlej sieti alebo chcete obetovat presnost za rychlost.

Tieto sablony dovoluju pouzivatelovi specifikovat agresivitu, zatial co, Nmap sam vyberie presne hodnoty casovania. Sablony takisto vykonavaju male prisposobenia rychlosti, na ktore momentalne neexistuju jemne ovladacie parametre. Napriklad moznost -T4 zakazuje, aby dynamicke oneskorenie scanu prekrocilo 10ms pre TCP porty a-T5 ohranici tuto hodnotu 5 milisekundami. Pokial sa sablona specifikuje ako prva, moze byt pouzita v kombinacii s jemnym ovladanim, inak sa povodne hodnoty pre sablony prepisat vami specifikovanymi hodnotami. Odporucam pouzitie parametra -T4 ak sa scanuju moderne a spolahlive siete. Aj ked zadate dalsie jemne ovladanie kvoli dodatocnym malym povolenym optimalizaciam, zachovajte tento parameter (na zaciatok prikazoveho riadku).

Ak ste na poriadnej sieti s broadbandovym alebo ethernetovym pripojenim, vzdy by som odporucal pouzitie parametra-T4. Niektori ludia preferuju moznost -T5, hoci pre mna je prilis agresivna. Ini zasa niekedy zadaju -T2, pretoze si myslia, ze tymto je mensia pravdepodobnost sposobenia spadnutia pocitaca alebo pretoze sa sami vo vseobecnosti povazuju za zdvorilych. Casto si pritom neuvedomuju, za moznost -T Polite je skutocne velmi pomala. Takyto scan moze trvat desatkrat viac ako povodny scan. Spadnutia pocitacov a problemy so sirkou pasma su zriedkave pri pouziti predvoleneho parametra casovania (-T3) a tak ho normalne odporucam pre pozornych scannerov. Vynechanie detekcie verzie je vsak casovo ovela ucinnejsie ako hranie sa s hodnotami casovania.

Zatial co moznosti -T0a-T1 mozu byt uzitocne pre vyhnutie sa upozorneni systemov IDS, scanovanie tisicov portov pocitacov bude trvat vynimocne dlho. Pri takomto dlhom scane je mozno lepsie nastaveni presnych hodnot casovania namiesto spolahnutia sa na vopred pripravene moznosti-T0a-T1 .

Hlavnymi nasledkami pouzitia parametruT0 je serializacia scanovania portov, takze sa sucasne scanuje len jeden port, a pred vyslanim dalsieho testu sa caka 5 minut. Moznosti T1 a T2 su podobne, ale medzi jednotlivymi testami cakaju len 15 resp. 0.4 sekund. MoznostT3 je predvolenou pre Nmap a zahrna paralelizaciu. Moznost T4 je ekvivalentna zadaniu--max_rtt_timeout 1250 --initial_rtt_timeout 500 --max_retries 6 a nastavuje maximalne oneskorenie TCP scanu na 10 ms. MoznostT5 je ekvivalentna zadaniu --max_rtt_timeout 300 --min_rtt_timeout 50 --initial_rtt_timeout 250 --max_retries 2 --host_timeout 900000 a takisto nastavenia maximalneho oneskorenia TCP scanu na 5ms.