Протокол передачи файлов

Протокол передачи файлов ( FTP ) — это стандартный протокол связи, используемый для передачи компьютерных файлов с сервера на клиент в компьютерной сети . FTP построен на архитектуре клиент-серверной модели с использованием отдельных соединений управления и данных между клиентом и сервером. ^[1] Пользователи FTP могут аутентифицировать себя с помощью протокола входа в систему с открытым текстом , обычно в виде имени пользователя и пароля, но могут подключаться анонимно, если сервер настроен так, чтобы это разрешать. Для безопасной передачи, которая защищает имя пользователя и пароль и шифрует содержимое, FTP часто защищается с помощью SSL/TLS ( FTPS ) или заменяется на SSH File Transfer Protocol ( SFTP ).

Первые клиентские приложения FTP были программами командной строки, разработанными до того, как операционные системы получили графический пользовательский интерфейс , и до сих пор поставляются с большинством операционных систем Windows , Unix и Linux . ^{[2] [3]} С тех пор было разработано множество специализированных клиентов FTP и утилит автоматизации для настольных компьютеров , серверов, мобильных устройств и оборудования, а FTP был включен в такие приложения для повышения производительности, как редакторы HTML и файловые менеджеры .

FTP-клиент обычно интегрировался в веб-браузеры , где файловые серверы просматривались с префиксом URIftp:// " ". В 2021 году поддержка FTP была прекращена Google Chrome и Firefox ^{[4] [5],} двумя основными поставщиками веб-браузеров, из-за того, что он был заменен более безопасными SFTP и FTPS; хотя ни один из них не реализовал новые протоколы. ^{[6] [7]}

Первоначальная спецификация для протокола передачи файлов была написана Абхаем Бхушаном и опубликована как RFC  114 16 апреля 1971 года. До 1980 года FTP работал на NCP , предшественнике TCP/IP . ^[2] Позднее протокол был заменен версией TCP/IP, RFC  765 (июнь 1980 года) и RFC  959 (октябрь 1985 года), текущей спецификацией. Несколько предложенных стандартов вносят поправки в RFC  959, например, RFC  1579 (февраль 1994 года) включает Firewall-Friendly FTP (пассивный режим), RFC  2228 (июнь 1997 года) предлагает расширения безопасности, RFC  2428 (сентябрь 1998 года) добавляет поддержку IPv6 и определяет новый тип пассивного режима. ^[8]

FTP может работать в активном или пассивном режиме, который определяет, как устанавливается соединение для передачи данных. ^[9] (Это значение «режима» отличается от значения команды MODE в протоколе FTP.)

• В активном режиме клиент начинает прослушивать входящие соединения данных от сервера на порту M. Он отправляет FTP-команду PORT ^[10] M, чтобы сообщить серверу, какой порт он прослушивает. Затем сервер инициирует канал данных для клиента со своего порта 20, порта данных FTP-сервера.
• В ситуациях, когда клиент находится за брандмауэром и не может принимать входящие TCP-соединения, может использоваться пассивный режим . В этом режиме клиент использует управляющее соединение для отправки команды PASV на сервер, а затем получает от сервера IP-адрес и номер порта сервера, ^[9] которые клиент затем использует для открытия соединения данных с произвольного порта клиента на полученные IP-адрес сервера и номер порта сервера. ^[11]

Оба режима были обновлены в сентябре 1998 года для поддержки IPv6 . В то же время были внесены дальнейшие изменения в пассивный режим, обновив его до расширенного пассивного режима . ^[12]

Сервер отвечает по управляющему соединению трехзначными кодами статуса в ASCII с необязательным текстовым сообщением. Например, «200» (или «200 OK») означает, что последняя команда была успешной. Цифры представляют собой код ответа, а необязательный текст представляет собой понятное человеку объяснение или запрос (например, <Нужна учетная запись для хранения файла>). ^[1] Текущая передача данных файла по управляющему соединению может быть прервана с помощью сообщения о прерывании, отправленного по управляющему соединению.

FTP требует два порта (один для отправки и один для получения), поскольку изначально он был разработан для работы поверх Network Control Protocol (NCP), который был симплексным протоколом , который использовал два адреса портов , устанавливая два соединения для двусторонней связи. Нечетный и четный порт были зарезервированы для каждого приложения или протокола прикладного уровня . Стандартизация TCP и UDP снизила необходимость использования двух симплексных портов для каждого приложения до одного дуплексного порта, ^{[13] : 15,} но протокол FTP никогда не менялся, чтобы использовать только один порт, и продолжал использовать два для обратной совместимости.

FTP обычно передает данные, заставляя сервер подключаться обратно к клиенту после отправки клиентом команды PORT. Это проблематично как для NAT , так и для брандмауэров, которые не разрешают соединения из Интернета к внутренним хостам. ^[14] Для NAT дополнительная сложность заключается в том, что представление IP-адресов и номера порта в команде PORT относится к IP-адресу и порту внутреннего хоста, а не к публичному IP-адресу и порту NAT.

Есть два подхода к решению этой проблемы. Один из них заключается в том, что FTP-клиент и FTP-сервер используют команду PASV, которая устанавливает соединение данных от FTP-клиента к серверу. ^[14] Это широко используется современными FTP-клиентами. Другой подход заключается в том, что NAT изменяет значения команды PORT, используя для этой цели шлюз прикладного уровня . ^[14]

При передаче данных по сети определены пять типов данных: ^{[2] [3] [8]}

• ASCII (ТИП A): Используется для текста. Данные преобразуются, если необходимо, из представления символов отправляющего хоста в "8-битный ASCII" перед передачей и (опять же, если необходимо) в представление символов принимающего хоста, включая символы новой строки . Как следствие, этот режим не подходит для файлов, содержащих данные, отличные от ASCII.
• Изображение (ТИП I, обычно называемый двоичным режимом): отправляющая машина отправляет каждый файл побайтно , а получатель сохраняет поток байтов по мере его получения. (Поддержка режима изображения рекомендована для всех реализаций FTP).
• EBCDIC (ТИП E): используется для передачи обычного текста между хостами с использованием набора символов EBCDIC.
• Локальный (TYPE L n ): Разработан для поддержки передачи файлов между машинами, которые не используют 8-битные байты, например, 36-битные системы, такие как DEC PDP-10s . Например, "TYPE L 9" будет использоваться для передачи данных в 9-битных байтах, или "TYPE L 36" для передачи 36-битных слов. Большинство современных клиентов/серверов FTP поддерживают только L 8, что эквивалентно I.
• Текстовые файлы Unicode с использованием UTF-8 (TYPE U): определены в устаревшем проекте Internet Draft ^[15] , который так и не стал RFC, хотя и был реализован несколькими FTP-клиентами/серверами.

Обратите внимание, что эти типы данных обычно называются «режимами», хотя это слово также неоднозначно используется для обозначения режима связи «активный-пассивный» (см. выше) и режимов, устанавливаемых командой MODE протокола FTP (см. ниже).

Для текстовых файлов (ТИП A и ТИП E) предусмотрены три различных параметра управления форматом, позволяющие контролировать, как будет напечатан файл:

• Непечатаемые (TYPE AN и TYPE EN) – файл не содержит никаких символов управления кареткой, предназначенных для принтера.
• Telnet (TYPE AT и TYPE ET) – файл содержит символы управления кареткой Telnet (или, другими словами, ASCII C0) (CR, LF и т. д.)
• ASA (ТИП AA и ТИП EA) – файл содержит символы управления кареткой ASA

Эти форматы в основном были актуальны для линейных принтеров ; большинство современных FTP-клиентов/серверов поддерживают только формат управления по умолчанию N.

Организация файла задается с помощью команды STRU. Следующие структуры файлов определены в разделе 3.1.1 RFC959:

• Структура F или FILE (ориентированная на поток). Файлы рассматриваются как произвольная последовательность байтов, символов или слов. Это обычная структура файла в системах Unix и других системах, таких как CP/M, MS-DOS и Microsoft Windows. (Раздел 3.1.1.1)
• Структура R или RECORD (ориентированная на запись). Файлы рассматриваются как разделенные на записи, которые могут быть фиксированной или переменной длины. Такая организация файлов распространена в мэйнфреймах и системах среднего уровня, таких как MVS, VM/CMS, OS/400 и VMS, которые поддерживают файловые системы, ориентированные на запись .
• Структура P или PAGE (ориентированная на страницы). Файлы делятся на страницы, которые могут содержать данные или метаданные; каждая страница может также иметь заголовок, дающий различные атрибуты. Эта структура файла была специально разработана для систем TENEX и, как правило, не поддерживается на других платформах. Раздел 4.1.2.3 RFC1123 рекомендует не реализовывать эту структуру.

Большинство современных FTP-клиентов и серверов поддерживают только STRU F. STRU R по-прежнему используется в приложениях для передачи файлов на мэйнфреймах и мини-компьютерах.

Передача данных может осуществляться в любом из трех режимов: ^{[1] [2]}

• Режим потока (MODE S): данные отправляются как непрерывный поток, освобождая FTP от выполнения какой-либо обработки. Вместо этого вся обработка остается за TCP . Индикатор конца файла не нужен, если только данные не разделены на записи .
• Блочный режим (MODE B): разработан в первую очередь для передачи файлов, ориентированных на записи (STRU R), хотя может также использоваться для передачи потоковых текстовых файлов (STRU F). FTP помещает каждую запись (или строку) данных в несколько блоков (заголовок блока, количество байтов и поле данных), а затем передает их в TCP. ^[8]
• Сжатый режим (MODE C): расширяет MODE B сжатием данных с использованием кодирования длин серий .

Большинство современных FTP-клиентов и серверов не реализуют MODE B или MODE C; исключение составляют FTP-клиенты и серверы для операционных систем мэйнфреймов и мини-компьютеров.

Некоторое программное обеспечение FTP также реализует режим сжатия на основе DEFLATE , иногда называемый «Mode Z» по команде, которая его включает. Этот режим был описан в Internet Draft , но не стандартизирован. ^[16]

GridFTP определяет дополнительные режимы, MODE E ^[17] и MODE X ^[18] , как расширения MODE B.

Более поздние реализации FTP поддерживают команду Modify Fact: Modification Time (MFMT), которая позволяет клиенту удаленно настраивать атрибут файла , что позволяет сохранять этот атрибут при загрузке файлов. ^{[19] [20]}

Для получения временной метки удаленного файла есть команда MDTM . Некоторые серверы (и клиенты) поддерживают нестандартный синтаксис команды MDTM с двумя аргументами, который работает так же, как MFMT ^[21]

Вход по FTP использует обычную схему имени пользователя и пароля для предоставления доступа. ^[2] Имя пользователя отправляется на сервер с помощью команды USER, а пароль отправляется с помощью команды PASS. ^[2] Эта последовательность не шифруется «на проводе», поэтому может быть уязвима для сетевой атаки сниффинга . ^[22] Если информация, предоставленная клиентом, принята сервером, сервер отправит приветствие клиенту, и сеанс начнется. ^[2] Если сервер поддерживает это, пользователи могут войти в систему без предоставления учетных данных для входа, но тот же сервер может разрешить только ограниченный доступ для таких сеансов. ^[2]

Хост, предоставляющий FTP-сервис, может предоставлять анонимный FTP-доступ. ^[2] Обычно пользователи входят в сервис с помощью «анонимной» (строчной и чувствительной к регистру учетной записи на некоторых FTP-серверах) учетной записи, когда им предлагается ввести имя пользователя. Хотя пользователей обычно просят отправить свой адрес электронной почты вместо пароля, ^[3] на самом деле никакая проверка предоставленных данных не выполняется. ^[23] Многие FTP-хосты, целью которых является предоставление обновлений программного обеспечения, разрешают анонимный вход. ^[3]

Многие файловые менеджеры, как правило, имеют реализованный FTP-доступ, например File Explorer (ранее Windows Explorer) в Microsoft Windows . Этот клиент рекомендуется только для небольших передач файлов с сервера из-за ограничений по сравнению со специализированным клиентским программным обеспечением. ^[24] Он не поддерживает SFTP . ^[25]

Оба собственных файловых менеджера для KDE на Linux ( Dolphin и Konqueror ) поддерживают как FTP, так и SFTP. ^{[26] [27]}

На Android файловый менеджер My Files на Samsung Galaxy имеет встроенный FTP и SFTP- клиент. ^[28]

В течение долгого времени большинство распространенных веб-браузеров могли извлекать файлы, размещенные на FTP-серверах, хотя не все из них поддерживали расширения протокола, такие как FTPS . ^{[3] [29]} Когда предоставляется FTP-адрес, а не HTTP- адрес , доступное содержимое на удаленном сервере представляется способом, аналогичным тому, который используется для другого веб-содержимого.

Google Chrome полностью удалил поддержку FTP в Chrome 88, что также повлияло на другие браузеры на базе Chromium , такие как Microsoft Edge . ^[30] Firefox 88 отключил поддержку FTP по умолчанию, а Firefox 90 полностью прекратил ее поддержку. ^{[31] [4]}

FireFTP — это устаревшее расширение браузера, которое было разработано как полнофункциональный FTP-клиент для работы в Firefox , но когда Firefox прекратил поддержку FTP, разработчик расширения рекомендовал использовать Waterfox . ^[32] Некоторые браузеры, такие как текстовый Lynx , по-прежнему поддерживают FTP. ^[33]

Синтаксис FTP URL описан в RFC  1738 и имеет следующий вид: (части в квадратных скобках необязательны).ftp://[user[:password]@]host[:port]/[url-path]

Например, URL ftp://public.ftp-servers.example.com/mydirectory/myfile.txt представляет файл myfile.txt из каталога mydirectory на сервере public.ftp-servers.example.com как FTP-ресурс. URL ftp://user001:secretpassword@private.ftp-servers.example.com/mydirectory/myfile.txt добавляет спецификацию имени пользователя и пароля, которые должны использоваться для доступа к этому ресурсу.

Более подробную информацию об указании имени пользователя и пароля можно найти в документации браузеров (например, Firefox ^[34] и Internet Explorer ^[35] ). По умолчанию большинство веб-браузеров используют пассивный режим (PASV), который легче обходит межсетевые экраны конечного пользователя.

Существуют некоторые различия в том, как различные браузеры обрабатывают разрешение пути в случаях, когда у пользователя есть некорневой домашний каталог. ^[36]

Большинство распространенных менеджеров закачек могут получать файлы, размещенные на FTP-серверах, а некоторые из них также предоставляют интерфейс для извлечения файлов, размещенных на FTP-серверах. DownloadStudio позволяет не только загружать файл с FTP-сервера, но и просматривать список файлов на FTP-сервере. ^[37]

LibreOffice объявил, что поддержка FTP устарела с версии 7.4, позднее она была удалена в версии 24.2. ^{[38] [39]}

FTP не был разработан как безопасный протокол и имеет много уязвимостей безопасности. ^[40] В мае 1999 года авторы RFC  2577 перечислили уязвимость, приводящую к следующим проблемам:

• Атака методом грубой силы
• FTP-атака с отказом
• Захват пакетов
• Кража порта (угадывание следующего открытого порта и захват законного соединения)
• Атака с использованием спуфинга
• Перечисление имени пользователя
• DoS или DDoS

FTP не шифрует свой трафик; все передачи осуществляются открытым текстом, а имена пользователей, пароли, команды и данные могут быть прочитаны любым человеком, способным выполнить захват пакетов ( сниффинг ) в сети. ^{[2] [40]} Эта проблема характерна для многих спецификаций интернет-протоколов (таких как SMTP , Telnet , POP и IMAP ), которые были разработаны до создания механизмов шифрования, таких как TLS или SSL. ^[8]

Распространенные решения этой проблемы включают в себя:

1. Использование безопасных версий небезопасных протоколов, например, FTPS вместо FTP и TelnetS вместо Telnet.
2. Использование другого, более безопасного протокола, который может справиться с этой задачей, например, протокола передачи файлов SSH или протокола защищенного копирования .
3. Использование защищенного туннеля, такого как Secure Shell (SSH) или виртуальной частной сети (VPN).

FTP через SSH — это практика туннелирования обычного сеанса FTP через соединение Secure Shell. ^[40] Поскольку FTP использует несколько TCP- соединений (что необычно для протокола TCP/IP, который все еще используется), туннелирование через SSH особенно затруднено. Для многих клиентов SSH попытка настроить туннель для канала управления (начальное соединение клиент-сервер на порту 21) защитит только этот канал; при передаче данных программное обеспечение FTP на обоих концах устанавливает новые TCP-соединения (каналы данных) и, таким образом, не обеспечивает конфиденциальности или защиты целостности .

В противном случае необходимо, чтобы программное обеспечение клиента SSH имело определенные знания о протоколе FTP, чтобы контролировать и перезаписывать сообщения канала управления FTP и автономно открывать новые пересылки пакетов для каналов данных FTP. Пакеты программного обеспечения, которые поддерживают этот режим, включают:

• Tectia ConnectSecure (Win/Linux/Unix) ^[41] из программного пакета SSH Communications Security

FTP через SSH не следует путать с протоколом передачи файлов SSH (SFTP).

Явный FTPS — это расширение стандарта FTP, которое позволяет клиентам запрашивать шифрование сеансов FTP. Это делается путем отправки команды «AUTH TLS». Сервер имеет возможность разрешать или запрещать соединения, не запрашивающие TLS. Это расширение протокола определено в RFC  4217. Неявный FTPS — это устаревший стандарт для FTP, который требовал использования соединения SSL или TLS. Было указано, что он использует порты, отличные от портов обычного FTP.

Протокол передачи файлов SSH (хронологически второй из двух протоколов, сокращенно SFTP) передает файлы и имеет аналогичный набор команд для пользователей, но использует протокол Secure Shell (SSH) для передачи файлов. В отличие от FTP, он шифрует как команды, так и данные, предотвращая открытую передачу паролей и конфиденциальной информации по сети. Он не может взаимодействовать с программным обеспечением FTP, хотя некоторое программное обеспечение FTP-клиента также поддерживает протокол передачи файлов SSH.

Trivial File Transfer Protocol (TFTP) — это простой FTP с фиксированным шагом, который позволяет клиенту получать файл с удаленного хоста или помещать его на него. Одно из его основных применений — ранние этапы загрузки из локальной сети , поскольку TFTP очень прост в реализации. TFTP не обеспечивает безопасности и не обладает большинством расширенных функций, предлагаемых более надежными протоколами передачи файлов, такими как File Transfer Protocol. TFTP был впервые стандартизирован в 1981 году, а текущую спецификацию протокола можно найти в RFC  1350.

Simple File Transfer Protocol (первый протокол, сокращенно SFTP), как определено RFC  913, был предложен как (незащищенный) протокол передачи файлов с уровнем сложности, промежуточным между TFTP и FTP. Он никогда не был широко принят в Интернете , и теперь IETF присвоил ему статус Historic . Он работает через порт 115 и часто получает инициализацию SFTP . Он имеет набор команд из 11 команд и поддерживает три типа передачи данных: ASCII , двоичный и непрерывный. Для систем с размером слова , кратным 8 битам, реализация двоичного и непрерывного одинакова. Протокол также поддерживает вход с идентификатором пользователя и паролем, иерархические папки и управление файлами (включая переименование , удаление , загрузку , загрузку , загрузку с перезаписью и загрузку с добавлением ).

Ниже приведена сводка кодов ответов FTP , которые может возвращать FTP- сервер . Эти коды были стандартизированы в RFC  959 IETF. Код ответа представляет собой трехзначное значение. Первая цифра используется для указания одного из трех возможных результатов — успеха, неудачи или для указания ошибки или неполного ответа:

• 2yz – Успешный ответ
• 4yz или 5yz – Неудачный ответ
• 1yz или 3yz – Ошибка или неполный ответ

Вторая цифра определяет вид ошибки:

• x0z – Синтаксис. Эти ответы относятся к синтаксическим ошибкам.
• x1z – Информация. Ответы на запросы информации.
• x2z – Подключения. Ответы, относящиеся к управляющим и информационным соединениям.
• x3z – Аутентификация и учет. Ответы на вопросы о процессе входа и процедурах учета.
• x4z – Не определено.
• x5z – Файловая система. Эти ответы передают коды состояния из файловой системы сервера.

Третья цифра кода ответа используется для предоставления дополнительных сведений по каждой из категорий, определенных второй цифрой.

• RFC  697 – CWD Command of FTP. Июль 1975 г.
• RFC  959 – (Стандарт) Протокол передачи файлов (FTP). Дж. Постел, Дж. Рейнольдс. Октябрь 1985 г.
• RFC  1579 – (Информационный) FTP, совместимый с брандмауэрами. Февраль 1994 г.
• RFC  1635 – (Информационный) Как использовать анонимный FTP. Май 1994 г.
• RFC  1639 – FTP-операции с большими адресными записями (FOOBAR). Июнь 1994 г.
• RFC  1738 – Унифицированные указатели ресурсов (URL). Декабрь 1994 г.
• RFC  2228 – (Предлагаемый стандарт) Расширения безопасности FTP. Октябрь 1997 г.
• RFC  2389 – (Предлагаемый стандарт) Механизм согласования функций для протокола передачи файлов. Август 1998 г.
• RFC  2428 – (Предлагаемый стандарт) Расширения для IPv6, NAT и расширенного пассивного режима. Сентябрь 1998 г.
• RFC  2577 – (Информационное) Вопросы безопасности FTP. Май 1999 г.
• RFC  2640 – (Предлагаемый стандарт) Интернационализация протокола передачи файлов. Июль 1999 г.
• RFC  3659 – (Предлагаемый стандарт) Расширения FTP. П. Хетмон. Март 2007 г.
• RFC  5797 – (Предлагаемый стандарт) Реестр команд и расширений FTP. Март 2010 г.
• RFC  7151 – (Предлагаемый стандарт) Команда HOST протокола передачи файлов для виртуальных хостов. Март 2014 г.
• Реестр команд и расширений FTP IANA – официальный реестр команд и расширений FTP

• Коммуникационные сети/Протокол передачи файлов на Wikibooks
• Онлайн-тестер FTP-сервера. Аутентификация, шифрование, режим и подключение.
• Анонимные FTP-серверы по коду страны TLD (2012): «Необычный Интернет — Публичный доступ — FTP». www.jumpjet.info . 2012. Архивировано из оригинала 28 марта 2023 г. Получено 16 января 2020 г.