По умолчанию Nmap использует компромиссный подход к решению этой проблемы. Сначала производится сканирование небольших групп из 5-ти хостов, поэтому первые результаты приходят быстро, затем размер группы постепенно увеличивается до максимального - 1024. Точные значения по умолчанию зависят от заданных опций. Для большей эффективности Nmap использует группы больших размеров для UDP сканирования и для некоторых типов TCP сканирования портов.
Когда максимальный размер группы задан опцией --max-hostgroup, Nmap не будет его превышать. Минимальный размер группы задается опцией --min-hostgroup, и Nmap будет пытаться поддерживать размер групп больше этого уровня. Возможно Nmap придется использовать группы меньше заданных размеров, когда для выполнения условия минимальности будет не хватать целевых хостов. Эти опции могут быть использованы для удержания размера группы внутри некоторого диапазона, хотя это редко необходимо.
Эти опции не имеют эффекта на фазе обнаружения хостов. Там используются обычное ping сканирование (-sP). При сканировании с целью обнаружения хостов всегда используются большие группы для увеличения скорости и точности.
Основной целью использования этих опций является задание большого минимума размера группы, с тем чтобы сканирование проходило быстрее. При сканировании сети класса 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, чтобы предотвратить все повторные попытки, хотя это не рекомендуется.
Значением по умолчанию (без -T шаблона) является 10 ретрансляций. Если сеть кажется надежной, и целевые хосты не имеют ограничений на количество ответов, то Nmap обычно делают одну повторную попытку. Поэтому установка --max-retries в низкое значение (например, 3) никак не влечет на большинство типов сканирования. Такие значения могут значительно увеличить скорость сканирования медленных (с ограничениями на количество ответов) хостов. Обычно вы теряете некоторую информацию, когда Nmap рано прекращает сканировать порты, поэтому лучше дать истечь времени --host-timeout, и потерять всю информацию о цели.
--host-timeout <время> (Прекращает сканирование медленных целей)
Некоторые хосты просто требуют длительного времени сканирования. Это может быть в силу низкой производительности или ненадежности сетевого оборудования или программного обеспечения, ограничений на количество пакетов или ограничивающих брандмауэров. Несколько процентов наиболее медленных хостов могут занять большую часть времени сканирования. Иногда лучшим выходом является просто пропуск таких хостов. Передайте в качестве аргумента опции --host-timeout максимальное значение промежутка времени, в течении которого вы готовы ждать. Я часто задаю 30 мин, чтобы удостовериться в том, что Nmap не потратит более получаса на единичный хост. Имейте ввиду, что в течении этого получаса Nmap может сканировать другие хосты, так что это не просто потеря времени. Хост, чье время истекло, пропускается. Для этого хоста не выводится ни таблица портов, ни информации об ОС.
--scan-delay <время>; --max-scan-delay <время> (Регулирует задержку между запросами)
Эта опция вынуждает Nmap подождать по крайней мере заданное время между каждым запросом. Это особенно полезно в случае наличия ограничения на количество ответов у целевых хостов. Машины Solaris (как и многие другие) обычно отвечают на запросы при UDP сканировании только одним ICMP сообщением в секунду. Посылка большего количества запросов со стороны Nmap будет впустую. Установка значения опции --scan-delay в 1 сек будет поддерживать в Nmap такую медленную интенсивность. Nmap пытается определить ограничения на количество ответов у целевых хостов и подстроить задержку между запросами соответственно, но ничто не мешает указать вам это значение явно, если вы точно знаете, что так будет лучше.
Когда Nmap подстраивает задержку между запросами к обнаруженному ограничению, то скорость сканирования значительно уменьшается. Опция --max-scan-delay позволяет задать наибольшую возможную задержку. Установка здесь маленького значения может привести к бесполезной ретрансляции пакетов или возможному пропуску портов, если у цели есть строгий лимит на количество ответов.
Еще одним вариантом использования опции --scan-delay является обход пороговых систем обнаружения и предотвращения вторжений (IDS/IPS).
--min-rate <число> (Задает минимальную интенсивность сканирования)
Функции динамического управления различными опциями времени в Nmap хорошо справляются с задачей подборки подходящей скорости сканирования. Тем не менее, иногда вы можете заранее узнать подходящую интенсивность сканирования сети, или можете гарантировать, что сканирование закончится к определенному времени. Когда задается опция --min-rate, Nmap будет пытаться отсылать пакеты с той же или большей, чем задано, интенсивностью. Аргументом этой опции является положительное число, отражающее интенсивность сканирования в пакетах в секунду. Например, задание опции --min-rate 300 означает, что Nmap будет пытаться отсылать пакеты с интенсивностью 300 пакетов в секунду или больше. Задание низкого значения не отнимает у Nmap права работать с большей интенсивностью, если позволяют условия.
Существуют два варианта, при которых реальная интенсивность работы будет меньше заданного минимума. Первый, когда заданный минимум быстрее, чем наиболее быстрый возможный уровень работы Nmap, который зависит от аппаратного обеспечения. В этом случае Nmap будет посылать пакеты так быстро, как может; но будьте осторожны, т.к. при быстрой скорости возможны потери точности. Второй случай, когда у Nmap больше нечего отсылать, например, в конце сканирования, когда последние запросы уже посланы, и Nmap ожидает ответы на них. Это нормально, когда интенсивность падает в конце сканирования или при смене групп сканирования.