Основной целью использования этих опций является задание большого минимума размера группы, с тем чтобы сканирование проходило быстрее. При сканировании сети класса C обычным выбором является 256. При сканировании большого количества портов, превышение этого числа вряд ли поможет. При сканировании лишь нескольких портов, наилучшим размером группы будет 2048 или больше.
--min-parallelism <количество_запросов>; --max-parallelism <количество_запросов> (Регулирует распараллеливание запросов)
Эти опции регулируют общее количество запросов для группы хостов. Опции используются при сканировании портов и при обнаружении хостов. По умолчанию Nmap высчитывает степень параллельности основываясь на производительности сети. Если пакеты отбрасываются, то Nmap использует меньшее количество запросов. Количество запросов медленно увеличивается по мере того, как сеть продолжает нормально работать. Эти опции устанавливают минимальную и максимальную границы для этой переменной. По умолчанию параллелизм устанавливается в 1, если сеть работает плохо, и может достигать нескольких сотен при идеальных условиях.
Наиболее частым вариантом применения является установка опции --min-parallelism в значение большее единицы, чтобы увеличить скорость сканирования плохо работающих хостов и сетей. Это очень рискованная опция, т.к. установка большого значения может повлиять на правильность результатов сканирования. Установка этого значения также сокращает возможности Nmap по динамическому контролю параллелизма в зависимости от условий в сети. Значение равное 10-ти является приемлимым, хотя я прибегаю к этой опции в последнюю очередь.
Опция --max-parallelism иногда устанавливается для предотвращения отправки хостам более одного запроса за раз. Это может быть полезно в комбинации с опцией --scan-delay (описывается далее), хотя она и сама справляется со своими обязанностями.
--min-rtt-timeout <время>, --max-rtt-timeout <время>, --initial-rtt-timeout <время> (Регулирует время ожидания ответа на запрос)
В Nmap есть значение промежутка времени, в течении которого будет ожидаться ответ на запрос, перед тем как прекратить попытки или совершить еще одну. Этот промежуток вычисляется на основе времени, в течении которого были получены ответы на предыдущие запросы. Если в сети есть значительная и непостоянная задержка, то этот промежуток может возрасти до нескольких секунда. Он также устанавливается на безопасном (высоком) уровне и может таким и оставаться некоторое время, если Nmap производит сканирование не отвечающих на запросы хостов .
Задание значений --max-rtt-timeout и --initial-rtt-timeout ниже значений по умолчанию может существенно сократить время сканирования. Это особенно заметно при различных вариантах сканирования с заданной опцией -PN, а также при сканировании сильно фильтруемых сетей. Однако не торопитесь делать этого сразу. Сканирование займет много времени, если вы укажете такое низкое значение, при котором у большинства запросов закончиться время ожидания ответа, и они будут ретранслированы, в то время как ответы на них будут в пути.
Если хосты находятся в локальной сети, то 100 миллисекунда будет приемлимым значением опции --max-rtt-timeout. Если при этом производится отслеживание маршрута, то для начала пропингуйте хост в сети с помощью утилиты ICMP ping или hping2, у которой больше шансов обойти брандмауэр. Выясните среднее максимальное значение для, примерно, 10-ти пакетов. Удвойте это значение для передачи опции --initial-rtt-timeout и умножьте на три или четыре для опции --max-rtt-timeout. Обычно я не устанавливаю maximum RTT ниже 100 мс, не зависимо от результатов пингования. А также не превышаю 1000 мс.
Опция --min-rtt-timeout редко используется; она может быть полезна, в случае если сеть настолько ненадежна, что даже значения Nmap по умолчанию слишком агрессивны. Так как Nmap просто сокращает время ожидания до минимума, в случае если сеть кажется надежной, то нужды в этой опции нет, о ней дожно быть сообщено как о баге на nmap-dev рассылку.
--max-retries <количество_попыток> (Задает максимальное количество повторных передач запроса)
Когда Nmap не получает ответа на запрос сканирования порта, это может означать, что порт фильтруется. А возможно, запрос или ответ просто затерялись в сети. Также возможно, что у цели есть ограничение на количество ответов, что стало причиной временной блокировки запроса. В этом случае Nmap повторную передачу исходного запроса. Если для Nmap сеть кажется ненадежной, то она может совершить очень много попыток, перед тем как бросить это дело. Хотя это и придает достоверность результатам сканирования, это в то же время увеличивает время сканирования. Когда производительность критична, время сканирования может быть сокращено путем введения ограничения на максимальное количество повторных передач запроса. Вы даже можете задать --max-retries 0, чтобы предотвратить все повторные попытки, хотя это не рекомендуется.