Я иногда использую nmap для проверки своих хостов. Например: nmap -sS -p- example.com
Но эта команда никогда не завершается.
Поэтому я делю сканирование на небольшие части: nmap -sS -p 0-999 example.com(12 секунд до конца)
и затем nmap -sS -p 1000-1999 example.com(14 секунд до конца) и т. д. Это утомительно.
Если использовать более широкие детали: nmap -sS -p 0-3999 example.com
на завершение уйдет более 3 минут.
И с nmap -sS -p 0-7999 example.comним не покончено через 30 минут.
Итак:
1000 портов -> 12 секунд
4000 портов -> 3 минуты
9000 портов -> 30 минут
В чем проблема?
Как найти открытые TCP-порты для одного хоста с помощью nmap?
решение1
Nmap делает все возможное, чтобы найти скорость, с которой он может точно определить состояние (открыт, закрыт или отфильтрован) для каждого порта. Система синхронизации сложна, и у нее есть некоторые наихудшие сценарии, которые могут привести к очень медленному сканированию. Один из таких случаев — когда цель ограничивает скорость сброса TCP-подключения (RST), которые являются ответами, которые Nmap получает при закрытии порта. Большинство портов в системе обычно закрыты, и для экономии ресурсов или, возможно, для того, чтобы заблокировать попытки сканирования, ОС цели может выбрать отправку RST только один раз в секунду.
Когда Nmap обнаруживает ограничение скорости RST, он должен замедлить свои зонды, чтобы соответствовать этой скорости, в противном случае закрытый порт может быть помечен как «отфильтрованный», поскольку не было получено ответа, что соответствует брандмауэру, сбрасывающему трафик на этот порт. Это замедление происходит постепенно, поэтому первые несколько портов не так сильно затронуты, как последующие. Кроме того, это влияет только на закрытые порты, поэтому часто используемые порты между 1 и 1000 с меньшей вероятностью будут способствовать замедлению.
Есть обходной путь для этой проблемы, но он приводит к потере точности. Если вам не важно знать разницу между фильтрованными и закрытыми портами, вы можете использовать опцию, --defeat-rst-ratelimitчтобы не позволять ограниченным по скорости RST влиять на синхронизацию Nmap. Nmap продолжит отправлять с подходящей для сети скоростью, обнаруживая потерянные пакеты и замедляясь при необходимости, но при этом будет совершенно счастлив, помечая закрытые порты как фильтрованные. Набор открытых портов должен быть точно таким же, а это все, что нужно большинству людей. Фактически, вы даже можете добавить , --openчтобы вообще не выводить информацию о закрытых и фильтрованных портах.
решение2
Вы можете добавить -T5опцию для увеличения скорости сканирования. СогласноВремя и производительность nmapрекомендуется использовать -T4опцию:
Я бы рекомендовал всегда использовать -T4. Некоторые люди любят -T5, хотя он слишком агрессивен на мой вкус. Люди иногда указывают -T2, потому что считают, что он менее вероятно приведет к сбою хостов или потому что они считают себя вежливыми в целом. Они часто не осознают, насколько медленным на самом деле является -T polite. Их сканирование может занять в десять раз больше времени, чем сканирование по умолчанию. Сбои в работе машины и проблемы с пропускной способностью редки при использовании параметров синхронизации по умолчанию (-T3), поэтому я обычно рекомендую это для осторожных сканеров. Пропуск определения версии гораздо эффективнее, чем игра со значениями синхронизации для уменьшения этих проблем.
решение3
Попробуйте запустить nmap с -v(verbose), чтобы выяснить причину замедления.
Запуск nmap -sS -Pn -v -p 1-9999 myserver.comна одном из моих серверов выдает следующее где-то после 3000 портов:
Increasing send delay for (ip address) from 0 to 5 due to max_successful_tryno increase to 4
Increasing send delay for (ip address) from 5 to 10 due to 17 out of 55 dropped probes since last increase.
[...]
Increasing send delay for (ip address) from 160 to 320 due to 11 out of 31 dropped probes since last increase.
SYN Stealth Scan Timing: About 17.08% done; ETC: 13:17 (0:02:30 remaining)
Похоже, эти сообщения не появляются у меня ниже порта 1024.