FTP

FTP
Название	File Transfer Protocol
Уровень (по модели OSI)	Прикладной
Семейство	TCP/IP
Создан в	1971 год
Порт/ID	21/TCP для команд, 20/TCP для данных, 49152-65534/TCP динамически
Назначение протокола	Передача файлов
Спецификация	RFC 959
Основные реализации (клиенты)	Сравнение FTP-клиентов
Основные реализации (серверы)	Сравнение FTP-серверов
Расширяемость	Доп. команды
Медиафайлы на Викискладе

FTP (англ. File Transfer Protocol) — протокол передачи файлов по сети, появившийся в 1971 году задолго до HTTP и даже до TCP/IP, благодаря чему является одним из старейших прикладных протоколов. Изначально FTP работал поверх протокола NCP^[1], на сегодняшний день широко используется для распространения ПО и доступа к удалённым хостам. В отличие от TFTP, гарантирует передачу (либо выдачу ошибки) за счёт применения квитируемого протокола.

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

Первые клиентские FTP-приложения были интерактивными инструментами командной строки, реализующими стандартные команды и синтаксис. С тех пор были разработаны графические пользовательские интерфейсы для многих используемых по сей день операционных систем. Среди этих интерфейсов как компоненты программы общего веб-дизайна вроде Microsoft Expression Web, так и специализированные FTP-клиенты (например, FileZilla).

Достаточно яркая особенность протокола FTP в том, что он использует множественное (как минимум — двойное) подключение. При этом один канал является управляющим, через который поступают команды серверу и возвращаются его ответы (обычно через TCP-порт 21), а через остальные происходит собственно передача данных, по одному каналу на каждую передачу. Поэтому в рамках одной сессии по протоколу FTP можно передавать одновременно несколько файлов, причём в обоих направлениях. Для каждого канала данных открывается свой TCP порт, номер которого выбирается либо сервером, либо клиентом, в зависимости от режима передачи^[2].

Протокол FTP (как и HTTP) имеет двоичный режим передачи, что сокращает накладные расходы трафика и уменьшает время обмена данными при передаче больших файлов.

Начиная работу через протокол FTP, клиент входит в сессию, и все операции проводятся в рамках этой сессии (проще говоря, сервер помнит текущее состояние). Протокол HTTP ничего не «помнит» — его задача — отдать данные и забыть, поэтому запоминание состояния при использовании HTTP осуществляется внешними по отношению к протоколу методами^[2].

FTP работает на прикладном уровне модели OSI и используется для передачи файлов с помощью TCP/IP. Для этого должен быть запущен FTP-сервер, ожидающий входящих запросов. Компьютер-клиент может связаться с сервером по порту 21. Это соединение (поток управления) остаётся открытым на время сессии. Второе соединение (поток данных), может быть открыт как сервером из порта 20 к порту соответствующего клиента (активный режим), или же клиентом из любого порта к порту соответствующего сервера (пассивный режим), что необходимо для передачи файла данных. Поток управления используется для работы с сессией — например, обмен между клиентом и сервером командами и паролями с помощью telnet-подобного протокола. Например, «RETR имя файла» передаст указанный файл от сервера клиенту. Вследствие этой двухпортовой структуры FTP считается внешнеполосным протоколом, в отличие от внутриполосного HTTP.

Протокол определён в RFC 959. Сервер отвечает по потоку управления трёхзначными ASCII-кодами состояния с необязательным текстовым сообщением. Например, «200» (или «200 ОК») означает, что последняя команда была успешно выполнена. Цифры представляют код ответа, а текст — разъяснение или запрос. Текущая передача по потоку данных может быть прервана с помощью прерывающего сообщения, посылаемого по потоку управления.

FTP может работать в активном или пассивном режиме, от выбора которого зависит способ установки соединения. В активном режиме клиент создаёт управляющее TCP-соединение с сервером и отправляет серверу свой IP-адрес и произвольный номер клиентского порта, после чего ждёт, пока сервер запустит TCP-соединение с этим адресом и номером порта. В случае, если клиент находится за брандмауэром и не может принять входящее TCP-соединение, может быть использован пассивный режим. В этом режиме клиент использует поток управления, чтобы послать серверу команду PASV, и затем получает от сервера его IP-адрес и номер порта, которые затем используются клиентом для открытия потока данных с произвольного клиентского порта к полученному адресу и порту. Оба режима были обновлены в сентябре 1998 года для поддержки IPv6. В это время были проведены дальнейшие изменения пассивного режима, обновившие его до расширенного пассивного режима.

При передаче данных по сети могут быть использованы четыре представления данных:

• ASCII — используется для текста. Данные, если необходимо, до передачи конвертируются из символьного представления на хосте-отправителе в «восьмибитный ASCII», и (опять же, если необходимо) в символьное представление принимающего хоста. В частности, изменяются символы перевода строки (CR /chr(13)/, LF /chr(10)/ в Windows на LF /chr(10)/ в Unix/Linux. Как следствие, этот режим не подходит для файлов, содержащих не только обычный текст.
• Режим изображения (обычно именуемый бинарным) — устройство-отправитель посылает каждый файл байт за байтом, а получатель сохраняет поток байтов при получении. Поддержка данного режима была рекомендована для всех реализаций FTP.
• EBCDIC — используется для передачи обычного текста между хостами в кодировке EBCDIC. В остальном этот режим аналогичен ASCII-режиму.
• Локальный режим — позволяет двум компьютерам с идентичными установками посылать данные в собственном формате без конвертации в ASCII.

Для текстовых файлов предоставлены различные форматы управления и настройки структуры записи. Эти особенности были разработаны для работы с файлами, содержащими Telnet или ASA-форматирование.

Передача данных может осуществляться в любом из трёх режимов:

• Поточный режим — данные посылаются в виде непрерывного потока, освобождая FTP от выполнения какой бы то ни было обработки. Вместо этого вся обработка выполняется TCP. Индикатор конца файла не нужен, за исключением разделения данных на записи.
• Блочный режим — FTP разбивает данные на несколько блоков (блок заголовка, количество байт, поле данных) и затем передаёт их TCP.
• Режим сжатия — данные сжимаются единым алгоритмом (обычно кодированием длин серий).

FTP-аутентификация использует схему имя пользователя/пароль для предоставления доступа. Имя пользователя посылается серверу командой USER, а пароль — командой PASS. Если предоставленная клиентом информация принята сервером, то сервер отправит клиенту приглашение и начинается сессия. Пользователи могут, если сервер поддерживает эту особенность, войти в систему без предоставления учётных данных, но сервер может предоставить только ограниченный доступ для таких сессий.

Хост, обеспечивающий FTP-сервис, может предоставить анонимный доступ к FTP. Пользователи обычно входят в систему как «anonymous» (может быть регистрозависимым на некоторых FTP-серверах) в качестве имени пользователя. Хотя обычно пользователей просят прислать адрес их электронной почты вместо пароля, никакой проверки фактически не производится. Многие FTP-хосты, предоставляющие обновления программного обеспечения, поддерживают анонимный доступ.

Специально для работы FTP-протокола через межсетевые экраны было сделано расширение NAT, называемое FTP-ALG, позволяющее транслировать входящие соединения от сервера к клиенту через NAT. В процессе такого соединения FTP-ALG подменяет передаваемые данные от клиента, указывая серверу истинный адрес и порт, с которым сможет соединиться сервер, а потом транслирует соединение от сервера от этого адреса клиенту на его адрес. Несмотря на все меры и нововведения, принятые для поддержки FTP-протокола, на практике функция FTP-ALG обычно отключается во всех роутерах и маршрутизаторах с целью обеспечения дополнительной безопасности от вирусных угроз.

FTP обычно передаёт данные при наличии соединения сервера с клиентом, после того как клиент отправил команду PORT. Это создаёт проблему как для NAT, так и для брандмауэров, которые не разрешают соединения из интернета к внутренним хостам. Для NAT дополнительной проблемой является то, что представление IP-адресов и номера порта в команде PORT относится к IP-адресу и порту внутреннего хоста, вместо публичного IP-адреса и NAT-порта. Существует два подхода к этой проблеме. Первый заключается в том, что FTP-клиент и FTP-сервер используют команду PASV, которая вызывает соединение для передачи данных, установленное от клиента к серверу. Второй подход — изменение для NAT значений команды PORT с помощью шлюза на прикладном уровне.

Первая реализация протокола (1971 год) предусматривала обмен между клиентом и сервером сообщениями, состоящими из заголовка (72 бит) и данных переменной длины. Заголовок сообщения включал в себя запрос к FTP-серверу или ответ от него, тип и длину передаваемых данных. В качестве данных передавались параметры запроса (например, путь и имя файла), информация от сервера (например, список файлов в каталоге) и сами файлы. Таким образом, команды и данные передавались по одному и тому же каналу.

В 1972 году протокол был полностью изменён и принял вид, близкий к современному. Команды с параметрами от клиента и ответы сервера передаются по TELNET-соединению (канал управления), для передачи данных создаётся отдельное соединение (канал данных).

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

В 1980 году FTP-протокол стал использовать TCP. Последняя редакция протокола была выпущена в 1985 году.

В 1997 году появилось дополнение к протоколу, позволяющее шифровать и подписывать информацию в канале управления и канале данных. В 1999 году выпущено дополнение, посвящённое интернационализации протокола, которое рекомендует использовать кодировку UTF-8 для команд и ответов сервера и определяет новую команду LANG, устанавливающую язык ответов.

Большая часть обычных веб-браузеров может извлекать файлы, расположенные на FTP-серверах, хотя они могут не поддерживать расширения протоколов вроде FTPS. Когда указан FTP-адрес, а не HTTP-адрес, доступный контент на удалённом сервере представляется аналогично остальному веб-контенту. Полностью функциональный FTP-клиент может быть запущен в Firefox как расширение FireFTP.

С 2020 года браузер Chrome (как, возможно, и другие) будет полностью лишён поддержки протокола FTP.^[3]

Синтаксис

Синтаксис FTP URI описан в RFC1738, в форме: ftp://[<пользователь>[:<пароль>]@]<хост>[:<порт>]/<путь> (параметры в квадратных скобках необязательны). Например:

ftp://public.ftp-servers.example.com/mydirectory/myfile.txt (недоступная ссылка) (недоступная ссылка)

или:

ftp://user001:secretpassword@private.ftp-servers.example.com/mydirectory/myfile.txt (недоступная ссылка) (недоступная ссылка)

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

FTP не разрабатывался как защищённый (особенно по нынешним меркам) протокол и имеет многочисленные уязвимости в защите. В мае 1999 авторы RFC 2577 свели уязвимости в следующий список проблем:

• Скрытые атаки (bounce attacks)
• Спуф-атаки (spoof attacks)
• Атаки методом грубой силы (brute force attacks)
• Перехват пакетов, сниффинг (packet capture, sniffing)
• Защита имени пользователя
• Захват портов (port stealing)

FTP не может зашифровать свой трафик, все передачи — открытый текст, поэтому имена пользователей, пароли, команды и данные могут быть прочитаны кем угодно, способным перехватить пакет по сети. Эта проблема характерна для многих спецификаций Интернет-протокола (в их числе SMTP, Telnet, POP, IMAP), разработанных до создания таких механизмов шифрования, как TLS и SSL. Обычное решение этой проблемы — использовать «безопасные», TLS-защищённые версии уязвимых протоколов (FTPS для FTP, TelnetS для Telnet и т. д.) или же другой, более защищённый протокол, вроде SFTP/SCP, предоставляемого с большинством реализаций протокола Secure Shell.

Существует несколько методов безопасной передачи файлов, которые иногда называются «Безопасным FTP».

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

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

FTP через SSH (не SFTP) относится к практике туннелирования обычной FTP-сессии через SSH-соединение. Поскольку FTP использует несколько TCP-соединений, туннелирование через SSH особенно затруднительно. Когда много SSH-клиентов пытаются установить туннель для канала управления (изначальное «клиент-сервер» соединение по порту 21), защищён будет только этот канал; при передаче данных программное обеспечение FTP на любом конце установит новые TCP-соединения (каналы данных), которые обойдут SSH-соединение и, таким образом, лишатся целостной защиты.

Иначе, для клиентского программного обеспечения SSH необходимо иметь определённые знания о FTP для отслеживания и перезаписи сообщений потока управления FTP и автономного открытия новых перенаправлений для потока данных FTP.

Программные пакеты, поддерживающие этот режим:

• Tectia ConnectSecure (Win/Linux/Unix) из пакета SSH Communications Security
• Tectia Server for IBM z/OS из пакета SSH Communications Security
• FONC (под лицензией GPL)
• Co:Z FTPSSH Proxy

FTP через SSH иногда относят к безопасным FTP, но не стоит путать его с другими методами, такими как SSL/TLS (FTPS). Другие методы передачи файлов с помощью SSH и не связанные с FTP — SFTP и SCP. В каждом из них и учётные, и файловые данные всегда защищены протоколом SSH.

• ABOR — Прервать передачу файла.
• CDUP — Сменить каталог на вышестоящий.
• CWD — Сменить каталог.
• DELE — Удалить файл (DELE filename).
• EPSV — Войти в расширенный пассивный режим. Применяется вместо PASV.
• HELP — Выводит список команд, принимаемых сервером.
• LIST — Возвращает список файлов каталога. Список передаётся через соединение данных.
• MDTM — Возвращает время модификации файла.
• MKD — Создать каталог.
• NLST — Возвращает список файлов каталога в более кратком формате, чем LIST. Список передаётся через соединение данных.
• NOOP — Пустая операция.
• PASS — Пароль.
• PASV — Войти в пассивный режим. Сервер вернёт адрес и порт, к которому нужно подключиться, чтобы забрать данные. Передача начнётся при введении следующих команд: RETR, LIST и т. д.
• PORT — Войти в активный режим. Например PORT 12,34,45,56,78,89. В отличие от пассивного режима для передачи данных сервер сам подключается к клиенту.
• PWD — Возвращает текущий каталог.
• QUIT — Отключиться.
• REIN — Реинициализировать подключение.
• RETR — Скачать файл. Перед RETR должна быть команда PASV или PORT.
• RMD — Удалить каталог.
• RNFR и RNTO — Переименовать файл. RNFR — что переименовывать, RNTO — во что.
• SIZE — Возвращает размер файла.
• STOR — Закачать файл. Перед STOR должна быть команда PASV или PORT.
• SYST — Возвращает тип системы (UNIX, WIN, …).
• TYPE — Установить тип передачи файла (бинарный, текстовый).
• USER — Имя пользователя для входа на сервер.

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

• 2xx — Успешный ответ
• 4xx/5xx — Команда не может быть выполнена
• 1xx/3xx — Ошибка или неполный ответ

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

• x0z — Синтаксическая.
• x1z — Информация. Соответствует информационному сообщению.
• x2z — Соединения. Сообщение относится к управляющему соединению либо к соединению данных.
• x3z — Соответствует сообщениям об аутентификации пользователя и его правах.
• x4z — Не определено.
• x5z — Файловая система. Соответствует сообщению о состоянии файловой системы.

Третья цифра окончательно специфицирует ошибку.

В примере жирным шрифтом выделены команды, которые подаёт клиент; обычным шрифтом — сообщения сервера. Примечания отделены двумя слэшами:

220 FTP server ready. 

220 Hello World! USER anonymous 331 Anonymous login ok, send your complete email address as your password PASS ************ 230 Logged in anonymously. PASV 227 Entering Passive Mode (192,168,254,253,233,92) //Клиент должен открыть соединение на переданный IP LIST 150 Here comes the directory listing. // Сервер передаёт список файлов в каталог 226 Directory send OK. CWD incoming 250 Directory successfully changed. PASV 227 Entering Passive Mode (192,168,254,253,207,56) STOR example.avi 150 Ok to send data. // Клиент передаёт содержимое файла 226 File receive OK. QUIT 221 Goodbye. 

Аргумент 192,168,254,253,207,56 означает, что соединение к серверу ожидается на узле с IP-адресом 192.168.254.253 на порту 207 << 8 + 56 = 53048 (где << — операция побитового сдвига, 207 записывается в младший разряд, а потом сдвигается в старший, чтобы в младший записать {{{1}}}

На многих FTP-серверах существует каталог (под названием incoming, upload и т. п.), открытый на запись и предназначенный для закачки файлов на сервер. Это позволяет пользователям наполнять сервера свежими данными.

FXP (англ. File eXchange Protocol — протокол обмена файлами) — способ передачи файлов между двумя FTP-серверами напрямую, без закачки файлов на компьютер пользователя. При FXP-сессии клиент открывает два FTP-соединения к двум разным серверам, запрашивая файл на первом сервере, указывая в команде PORT IP-адрес второго сервера.

Несомненным преимуществом поддержки стандарта FXP является то, что на конечных пользователей, желающих скопировать файлы с одного FTP-сервера на другой, уже не действует ограничение пропускной способности их собственного интернет-соединения. Нет необходимости скачивать себе файл, чтобы потом загрузить его на другой FTP-сервер. Таким образом, время передачи файлов будет зависеть только от скорости соединения между двумя удаленными FTP-серверами, которая в большинстве случаев заведомо больше «пользовательской».

FXP стал использоваться злоумышленниками для атак на другие серверы: в команде PORT указывается IP-адрес и порт атакуемого сервиса на компьютере жертвы, и командами RETR/STOR производится обращение на этот порт от лица FTP-сервера, а не атакующей машины, что позволяло устраивать масштабные DDoS-атаки с использованием сразу многих FTP-серверов, либо обходить систему безопасности компьютера жертвы, если он полагается только на проверку IP клиента и используемый для атаки FTP-сервер находится в доверенной сети или на шлюзе. В результате сейчас практически все серверы проверяют соответствие IP-адреса, указанного в команде PORT, IP-адресу FTP-клиента и по умолчанию запрещают использование там IP-адресов третьих сторон. Таким образом, использование FXP невозможно при работе с публичными FTP-серверами.

• Первоначальная спецификация FTP RFC 959
• Расширения безопасности RFC 2228
• Интернационализация FTP RFC 2640
• Расширение NAT-PT для поддержки FTP RFC 2766
• Шифрование KEA и SKIPJACK RFC 2773
• Расширение команд FTP RFC 3659
• Реестр команд и расширений FTP RFC 5797 (есть перевод на русский)