Обновление 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
если хочешь.