Кратко

  • FTP разделяет команды и файлы. Клиент начинает управляющее соединение, но в обычном активном режиме сервер открывал второе соединение к указанному клиентом порту данных.
  • Пакетный фильтр видел в таком обратном вызове новый вход на непредсказуемый порт. RFC 1579 рекомендовал PASV: сервер слушает, а клиент начинает и канал данных.
  • EPSV стал возвращать только порт и брать адрес из управляющего соединения, упрощая IPv6 и NAT. Направление не удостоверяло партнёра: bounce-атака и захват пассивного порта требовали самостоятельной защиты.

Одна сессия состояла из двух встреч

В RFC 959 команды и ответы идут по управляющему соединению, а каталоги и файлы — по отдельному соединению данных. Последнее может открываться и закрываться для каждой передачи, не завершая основную сессию.

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

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

На границе обратный вызов стал чужим

RFC 1579 в 1994 году описал клиентов, выбиравших новый порт для каждой передачи. Фильтр перед клиентом видел внешний сервер, начинающий TCP-соединение к постоянно меняющемуся высокому порту.

FTP знал, что это продолжение входа пользователя. Пакетный фильтр мог не знать. Разрешить все порты означало лишить границу смысла; научить её полностью разбирать FTP — перенести состояние приложения в посредника. Столкнулись две локальные политики: FTP допускал обратный вызов, а экран предпочитал новые соединения из защищённой зоны.

PASV менял только инициатора. Сервер открывал нестандартный слушающий порт и сообщал его, после чего клиент устанавливал соединение. Теперь и управление, и данные начинались изнутри. RFC 1579 рекомендовал клиентам пользоваться этим режимом даже без межсетевого экрана.

Каналы не сливались, формат файла не менялся. Поскольку клиент и так обычно посылал PORT, дополнительный обмен не был обязателен. Старый сервер мог отвергнуть PASV, а клиент — вернуться к активному режиму там, где сеть пропускала обратный вызов. Переход определяли реализации и параметры, а не одно объявление.

Обсуждавшаяся команда APSV для полностью пассивной сессии осталась без известной реализации. Документ мог предложить будущее, но не мог запустить его вместо участников.

EPSV перестал повторять адрес

Старые PORT и PASV встраивали IPv4-адрес и порт в управляющий текст. Формат не подходил IPv6. При NAT записанный внутри адрес мог отличаться от адреса реального пути, заставляя транслятор понимать и переписывать прикладные данные.

RFC 2428 ввёл EPRT и EPSV. EPRT передаёт семейство, сетевой адрес и порт для активного режима. Ответ EPSV содержит только TCP-порт; сетевой протокол и адрес берутся из управляющего соединения.

Если передача идёт между теми же машинами, действующее соединение уже установило партнёра. Повторный текстовый адрес создавал вторую, потенциально неверную версию факта. Расширение оставило только новую информацию — временный порт.

После принятия EPSV ALL сервер обязан отвергать EPRT, PORT, PASV и другие способы настройки данных в этой сессии. Для внезапно потребовавшейся трёхсторонней передачи открывается новая сессия. Решение строго, но его область ясна.

Направление не заменило личность

RFC 2577 описывает FTP bounce. Атакующий указывал в PORT чужую машину и сервис, а затем заставлял FTP-сервер отправлять туда подготовленные данные. Источником выглядел сервер, что затрудняло расследование и иногда обходило адресные ограничения.

Среди мер предлагались отказ от активных целей ниже TCP-порта 1024, отключение PORT без необходимости межсерверной передачи и проверка адресов партнёров обоих соединений, когда доступ зависит от сети.

Пассивный режим открывал временный порт уже на сервере. Если номера назначались предсказуемо, злоумышленник мог угадать следующий и подключиться первым: помешать клиенту, получить чужой файл или внедрить поддельные данные. RFC 2577 рекомендовал случайные локальные порты. Реализация также должна связывать партнёра по данным с контекстом управления.

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

Тонкий механизм оставил решения на местах

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

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

Источники и ограничения

RFC 959 задаёт соединения, PORT и PASV; RFC 1579 разбирает фильтры; RFC 2428 определяет расширения; RFC 2577 описывает bounce и захват порта.

Документы не измеряют современное распространение и не гарантируют поведение каждого клиента, сервера, прокси, NAT или экрана. Они не делают пассивный FTP безопасным транспортом. Они подтверждают более узкую историю: небольшая смена инициатора сохранила архитектуру перед новой границей, оставив доверие работающим системам.