Это непростой вопрос.
TL; DR:
1) Клиент устанавливает соединение TCP с брандмауэром на (закрытом / недоступном) порту 21, даже если брандмауэр не отвечает на SYN-пакет клиента.
2) Клиент отправляет 1 пакет SYN (без повторной передачи), межсетевой экран видит 3 пакета SYN от клиента.
3) То же самое происходит с сервером Linux на другом континенте с правилом блокировки в цепочке PREROUTING.
Недавно мы заметили, что наш пограничный корпоративный межсетевой экран (топ-3 в рейтинге Gartner) показывает порт 21 как открытый порт на своем порту WAN.
Несмотря на то, что сам брандмауэр не использует этот порт ни для одной из своих служб, и нет политики / NAT / LB, перенаправляющей его на другой хост / сервер, он по-прежнему отображается как открытый в выводе NMAP или telnet / NC.
Явное отрицание этого в интерфейсе брандмауэра и с помощью политик безопасности не имело значения. Мой поиск по документам этого продавца не дал никаких результатов.
В то время, чтобы убедиться, что брандмауэр отвечает на порт 21, я запустил tcpdump в своей системе и инструмент «потока пакетов» этого брандмауэра, чтобы увидеть, что происходит, и вот, я вижу, что мое соединение с портом 21 течет. в брандмауэр, проверка того, что пакеты от клиента достигают самого брандмауэра.
Как ни странно, мой клиент отправляет 1 пакет SYN и межсетевой экран получает 3 пакета SYN, не отвечает моему клиенту (нет отправленных SYN / ACK) и все же как-то соединение успешно.
Дело только в том, что рукопожатие TCP проходит успешно на стороне клиента и если вы нажмете Enter в своем клиентском терминале, ваше соединение немедленно закрывается.
Поскольку эти брандмауэры основаны на UNIX, из любопытства я решил попробовать и посмотреть, смогу ли я воспроизвести это поведение на VPS (работает Ubuntu Server 19) У меня на другом континенте.
Используя IPTABLES, я создал политику DROP в ПЕРЕДАЧА цепочка для блокировки трафика, предназначенного для порта 21. Я повторил свой тест, и результат был точно таким же! Клиент отправляет 1 пакет SYN, сервер Ubuntu видит 3 пакета SYN, не отвечает ACK, и все же каким-то образом соединение устанавливается для клиента! Иглы говорят, что при нажатии Enter на клиентском терминале соединение сразу закрывается. Точно такое же поведение на брандмауэре.
Ниже приведены тесты, которые я провел, и они идентичны как на сервере, так и на брандмауэре:
Клиентские телнета к серверу через порт 21:
Client~# telnet Server-IP 21
Trying Server-IP...
Connected to Server-IP.
Escape character is '^]'.
Connection closed by foreign host.
TCPDUMP запускается на клиенте при запуске telnet:
Client~# tcpdump -ni any port 21
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
19:24:05.456477 IP Client-priv-IP.36284 > Server-IP.21: Flags [S], seq 3093982956, win 64240, options [mss 1460,sackOK,TS val 3370721563 ecr 0,nop,wscale 7], length 0
19:24:05.557556 IP Server-IP.21 > Client-priv-IP.36284: Flags [S.], seq 3130560876, ack 3093982957, win 4080, options [mss 1360,sackOK,TS val 1773913297 ecr 3370721563], length 0
19:24:05.557679 IP Client-priv-IP.36284 > Server-IP.21: Flags [.], ack 1, win 64240, options [nop,nop,TS val 3370721664 ecr 1773913297], length 0
19:24:17.740636 IP Server-IP.21 > Client-priv-IP.36284: Flags [R.], seq 1, ack 1, win 0, length 0
TCPDUMP запускается на сервере при запуске telnet:
Server~# tcpdump -ni any -Q in port 21
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
19:25:05.001238 IP Client-pub-IP.36288 > Server-IP.21: Flags [S], seq 2605288404, win 4080, options [mss 1360,sackOK,TS val 1773972678 ecr 0], length 0
19:25:08.000566 IP Client-pub-IP.36288 > Server-IP.21: Flags [S], seq 2605288404, win 4080, options [mss 1360,sackOK,TS val 1773975678 ecr 0], length 0
19:25:10.999775 IP Client-pub-IP.36288 > Server-IP.21: Flags [S], seq 2605288404, win 4080, options [mss 1360,sackOK,TS val 1773978678 ecr 0], length 0
19:25:16.999702 IP Client-pub-IP.36288 > Server-IP.21: Flags [R.], seq 2605288405, ack 0, win 0, length 0
IPTABLES отбрасывает 3 пакета SYN:
Server~# iptables -t raw -L -n -v
Chain PREROUTING (policy ACCEPT 36M packets, 26G bytes)
pkts bytes target prot opt in out source destination
3 2468 DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
Мы протестировали это на разных ПК и у разных интернет-провайдеров, чтобы исключить странные проблемы с клиентом или интернет-соединением.
В целях сохранения секретности я не смог сообщить IP-адреса и имя производителя.
Кто-нибудь может объяснить такое поведение? Самым загадочным является тот факт, что клиент отправляет 1 SYN, а сервер / брандмауэр получает 3.
заранее спасибо
Благодаря Тилману Шмидту я смог найти и найти RFC 3234, на самом деле это промежуточный ящик, действующий с FTP-трафиком.
В выводе TCPDUMP вы можете видеть, что такие факторы, как значение MSS и некоторые параметры TCP, такие как SACK, различаются от клиента к серверу, что указывает на наличие промежуточного ящика.
Средний ящик имеет тенденцию манипулировать:
Я подозреваю (оптимистично), что эти промежуточные блоки действуют таким образом, потому что такие протоколы, как FTP, работают в двух разных каналах TCP. Такое поведение при проксировании моего FTP-соединения должно учитывать и не нарушать канал данных, передаваемый от сервера к клиенту.
Это не ожидаемое поведение? «Если первоначальное установление связи TCP не удается из-за отбрасывания пакетов, вы увидите, что пакет TCP SYN повторно передается только 3 раза». Я не знаю, является ли Microsoft авторитетом в этом вопросе, но я обнаружил следующее: документы Microsoft
Порт 21 - это хорошо известный порт для FTP, который не совсем подходит для NAT. Ваш отредактированный tcpdump от клиента говорит «Client-priv-IP», тогда как тот, что с сервера, говорит «Client-pub-IP», поэтому я полагаю, что клиент находится за маршрутизатором NAT. Готов поспорить, что маршрутизатор перехватывает FTP, чтобы заставить его работать через NAT, самостоятельно завершая трехстороннее рукопожатие и параллельно делая три попытки доступа к целевому серверу. Когда целевой сервер не отвечает, он прерывает соединение с клиентом при следующей возможности.