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

Почему 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 хотя не показывает, что такие службы прослушивают эти порты. Так что мне не хватает?

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

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

UDP: открыто | с фильтрацией закрыто TCP: открыто закрыто с фильтром

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

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

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

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

Nmap

# 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 на том же сервере (игорь) я получал такие же результаты, как и вы. Но я вернулся, чтобы попробовать еще раз, и теперь он не возвращает никаких результатов (нет успешного сообщения), а wirehark показывает, что «Назначение недоступно» отправляется обратно по ICMP. Я ничего из этого не понимаю. Но я бы переключился на другой метод проверки статуса порта UDP.