Почему сканирование netcat на UDP-порты всегда проходит успешно?

Я пытаюсь проверить, что несколько наших серверов могут обмениваться данными через определенные порты, прежде чем переносить на них некоторые из наших сервисов, и что они не заблокированы списками управления доступом межсетевого экрана наших организаций.

Имеет смысл

[mrduki@mybox1~]$ nc -ul 40000
---
[mrduki@mybox2~]$ nc -zvuw2 mybox1.com 40000
Connection to mybox1.com 40000 port [udp/*] succeeded!

Не имеет смысла

[mrduki@mybox1~]$ nc -ul 40000
[mrduki@mybox1~]$ ^C
---
[mrduki@mybox2~]$ nc -zvuw2 mybox1.com 40000
Connection to mybox1.com 40000 port [udp/*] succeeded!

На самом деле, если я делаю сканирование портов из 40000-40100, каждый порт успешно.

Если я делаю те же тесты без -u (так что он тестирует TCP вместо UDP), я получаю 40000 (tcp) timed out: Operation now in progress ошибки, как я и ожидал (так как у меня нет такой службы TCP прослушивания 40000).

Делать sudo netstat -alnp | grep LISTEN на mybox1 хотя не показывает таких служб прослушивания на этих портах. Так чего мне не хватает?

Источник

3 ответа

Решение

nc возможно, не лучший инструмент для проверки состояния порта. Ты пытался nmap? Это на самом деле сканер портов. Я проверил файловый сервер в моей домашней сети и 127.0.0.1, оба сообщают, что UDP port 40000 закрыто.

птар

# nmap -sU -p 40000 igor

Starting Nmap 7.01 ( https://nmap.org ) at 2016-08-18 18:27 EDT
Nmap scan report for igor (192.168.1.125)
Host is up (0.00027s latency).
rDNS record for 192.168.1.125: igor.swass
PORT      STATE  SERVICE
40000/udp closed unknown
MAC Address: 68:05:CA:3A:BF:B7 (Intel Corporate)

Nmap done: 1 IP address (1 host up) scanned in 0.53 seconds

Ядро + /dev

Вы также можете использовать ядро, чтобы сделать это так. Но nmap наверное лучше.

# timeout 3 cat < /dev/udp/example.com/40000

Когда я пытался nc на том же сервере (игорь) я получал те же результаты, что и вы. Но я вернулся, чтобы повторить попытку, и теперь он не возвращает никаких выходных данных (сообщение об ошибке не было выполнено), и wireshark показывает, что "пункт назначения недоступен", отправляемый по протоколу ICMP. Я не понимаю ничего из этого. Но я бы переключился на другой метод проверки состояния порта UDP.

Источник

UDP - это протокол без установления соединения. Если вы отправляете пакет и не получаете отказа (через ICMP), он считается успешным. Это независимо от того, отвечает или нет что-либо. Я не смог принять сообщение на удаленном конце, что можно рассматривать как проблему с высоким уровнем связи, например, DNS, но это не сбой, если речь идет о UDP.

Сравните это с TCP, который с состоянием. Ошибка получения ответа (ACK) считается ошибкой в ​​TCP (обычно она отображается как "отфильтрованная"), так же как и отрицательные ответы (RST, которая будет отображаться как закрытая).

UDP: открыто | отфильтровано закрыто TCP: открыто закрыто отфильтровано

Источник

Ни один блок брандмауэра не остановит попытку соединения UDP, поскольку соединение с UDP не требует отправки чего-либо или прослушивания каких-либо ответов. Функционально операция UDP-соединения аналогична отправке до точки, где данные фактически отправляются, то есть:

  1. Гарантирует, что выбранный локальный порт может быть связан с, если он был выбран.
  2. Если локальный порт не был выбран, он выбирает один.
  3. Блокирует конечную точку, чтобы она по умолчанию связывалась с выбранным IP-адресом и портом и отбрасывала любые дейтаграммы, полученные с любого другого IP-адреса или порта.
  4. Система может изменить способ обработки некоторых типов ошибок.
  5. Вот и все.

Обратите внимание, что ничего из этого не делает ничего, что может помешать брандмауэр, и ничего не передается по проводам.

Источник
Другие вопросы по тегам