Назад | Перейти на главную страницу

nmap - получить подробный вывод для запросов?

Обновление 2: pf уже по умолчанию отбрасывается. Что заставляет Nmap замечать сервер? Что означает «полученный сброс»?

Обновление 1: Возможно, я неверно истолковал свои выводы. При запуске с -v2 nmap сообщает мне, что «Хост работает, получил сброс ttl 52». Означает ли это, что даже если ICMP заблокирован, Nmap может заметить, что сервер работает? Это связано с различиями в BLOCK / DROP? Сервер, который я исследую, запускает OpenBSD с pf. pf установлен на «блокировать все», за которым следуют очень конкретные исключения. IMHO по умолчанию это BLOCK, а не DROP в pf.

Когда я бегу

nmap -sn

чтобы зондировать конкретный хост, nmap возвращает "Host is up", хотя ICMP полностью заблокирован для исследуемого мной сервера, за исключением времени. Я предполагаю, что сообщение "Host is up" основано на ответе ICMP (поскольку это единственный "открытый" канал, о котором я знаю), на основе документации nmap:

Обнаружение хоста по умолчанию, выполняемое с помощью -sn, по умолчанию состоит из эхо-запроса ICMP, TCP SYN для порта 443, TCP ACK для порта 80 и запроса отметки времени ICMP по умолчанию.

Теперь мне интересно, можно ли каким-то образом заставить Nmap сообщать мне, ПОЧЕМУ хост работает, например получение подробного вывода для отдельных шагов, участвующих в зондировании. Я пробовал запустить его с -v, но это дает только версию и общую болтовню. ´

Я знаю, что могу сам выполнять отдельные запросы (например: hping3), но меня особенно интересует, возможно ли это с помощью nmap, поскольку я привязан к машине Windows здесь (и WSL по-прежнему не поддерживает сырые сокеты, необходимые для этот).

Спасибо.

Все дело в вариантах. Вот сайт который имеет рабочий веб-сервер на портах 80 и 443, но не отвечает на эхо-запросы.

C:\Users\doug>ping www.rlmueller.net

Pinging www.rlmueller.net [65.254.227.240] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Давайте попробуем nmap только с -sn вариант:

nmap -sn www.rlmueller.net

Результат:

…
Host is up (0.031s latency).
…

Итак, сервер работает, но мы не знаем, почему Nmap так думает. Но мы знаем, что это не так, потому что сервер отвечает на эхо-запросы.

Давайте использовать --reason вариант следующий:

nmap -sn --reason www.rlmueller.net

Результаты следующие:

...
Host is up, received syn-ack ttl 53 (0.031s latency).
…

Ага! Итак, Nmap решает, что сервер включен, потому что он ответил на SYN (отправленный на порт 443, согласно документации Nmap к -sn вариант) с помощью SYN-ACK.

Как насчет переключателей детализации?

nmap -sn -v1 www.rlmueller.net

Нет. Он дает больше информации, но результат все равно:

Host is up (0.031s latency).

nmap -sn -v2 www.rlmueller.net

Ага. Подобно использованию опции --reason, мы получаем:

Host is up, received syn-ack ttl 52 (0.032s latency).

Используя debug варианты, мы можем получить более подробную информацию.

nmap -sn -d1 www.rlmueller.net

...
We got a TCP ping packet back from 65.254.227.240 port 443
…
Host is up, received syn-ack ttl 52 (0.031s latency).
…

Ницца! Это согласуется с документацией, в которой упоминается пакет SYN для порта 443.

Более высокие уровни отладки, такие как -d2 или -d3 дать еще более подробную информацию. Вы можете пройти весь путь до -d6 если хочешь.