Summary

  • FTP передавал команды через управляющее соединение, а файлы — по отдельному соединению данных.
  • RFC 1579 использовал уже существующую команду PASV, чтобы изменить инициатора второго соединения: фильтрам на стороне клиента было проще его пропустить, но серверу приходилось принимать входящие подключения к портам данных.

FTP мог сообщить «отправьте этот файл» по соединению, которое сам файл не переносило. Такое разделение входило в проект протокола. Из него следовало практическое ограничение: успешный вход и положительный ответ на RETR ещё не означали, что байты дойдут. FTP требовалось установить второе TCP-соединение в заданном направлении.

Опубликованная в 1985 году спецификация RFC 959 отделяла управляющий процесс для команд и ответов от процессов передачи данных. В обычной схеме клиент открывал управляющее соединение к серверу, как правило, на порту 21. Перед передачей он мог отправить PORT, сообщив серверу свой адрес и порт для прослушивания. Затем сервер сам открывал соединение данных обратно к клиенту. Поскольку сокет данных не совпадал с управляющим, межсетевой экран мог разрешить первое соединение и при этом блокировать второе.

В протоколе уже предусматривался и другой порядок. Команда PASV просила серверный процесс данных слушать на нестандартном порту. Сервер сообщал адрес и порт, после чего клиент подключался к ним сам. Данные по-прежнему шли через отдельное соединение; менялась только сторона, которая его начинала. Пассивный режим появился в протоколе задолго до рекомендации применять его для прохождения пакетных фильтров.

К 1994 году практика не всегда соответствовала исходному режиму по умолчанию. Steven Bellovin писал в RFC 1579, что распространённые клиенты открывали новое соединение данных для каждой передачи, выбирали новый порт, чтобы не ждать окончания TCP TIME-WAIT, и сообщали его серверу через PORT. Для фильтра пакетов это выглядело как входящий вызов на непредсказуемый порт. Межсетевые экраны часто пропускали избранные входящие службы, но отклоняли такие подключения, даже если пользователь уже прошёл аутентификацию в управляющем канале.

RFC 1579 рекомендовал поставщикам изменить FTP-клиенты, в том числе прокси-агенты Gopher, чтобы они использовали PASV вместо PORT. Тогда соединение данных инициировал клиент из своей сети. Пользовательскому межсетевому экрану было проще разрешить исходящее подключение, начатое самим клиентом, чем принимать незапрошенный входящий вызов на случайный порт. Записка не предлагала менять протокол передачи: команда уже существовала, и обе схемы требовали похожего обмена перед отправкой файла.

Это решение перемещало сложную границу, но не устраняло её. В пассивном режиме серверу требовалось принимать входящие соединения на портах, выбранных для передач. RFC 1579 признавал, что на стороне сервера это тоже создавало проблему с экраном. Аргумент был административным: серверов меньше, чем клиентов, поэтому оператор мог ограничить диапазон портов данных. Это предложение о месте управления доступом, а не доказательство внедрения у всех серверов и межсетевых экранов.

Стандарты позволяют отделить обязательную возможность от реально распространённого поведения. RFC 1123, опубликованный в 1989 году, требовал от FTP-серверов реализовать PASV и уточнял разбор ответа, хотя отмечал, что формат ответа стандартизован недостаточно. Позднее RFC 1579 сообщал о существовании как минимум двух независимо изменённых клиентов. Ни один документ не измеряет долю пользователей или площадок, сменивших режим. Запись 1994 года подтверждает рекомендацию и ограниченное число реализаций, но не всеобщий переход.

У FTP было две операционные поверхности. Управляющее соединение несло учётные данные, команды и ответы; соединение данных — список каталогов или файл. Ответ «открываем соединение данных» не являлся самим файлом, а успешная аутентификация не доказывала завершение передачи. Для диагностики требовалось проследить оба сокета и понять, какой узел должен был инициировать каждый из них.

Вывод RFC 1579 конкретнее, чем «межсетевые экраны сломали FTP». Протокол уже позволял выбирать направление соединения данных. Фильтрация превратила этот выбор в операционное решение. PASV позволял начинать соединение со стороны, которую межсетевой экран клиента с большей вероятностью пропускал, но требовал от оператора сервера управлять ограниченным диапазоном входящих портов. Протокол остался прежним, а место операционной нагрузки переместилось.

Sources