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 | HTTP |
---|---|---|
Встроена аутентификация пользователей | Да | Нет |
Изначально предусмотрен для передачи | Больших двоичных файлов | Небольших текстовых файлов |
Модель соединения | Двойное подключение | Одиночное подключение |
Поддерживает текстовый и двоичный режимы передачи | Да | Нет |
Поддерживает указание типов передаваемых данных (MIME заголовки) | Нет | Да |
Поддерживает операции над файловой системой (mkdir, rm, rename, и т. д.) | Да | Нет |
Достаточно яркая особенность протокола 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-ALG
Специально для работы FTP-протокола через межсетевые экраны было сделано расширение NAT, называемое FTP-ALG, позволяющее транслировать входящие соединения от сервера к клиенту через NAT. В процессе такого соединения FTP-ALG подменяет передаваемые данные от клиента, указывая серверу истинный адрес и порт, с которым сможет соединиться сервер, а потом транслирует соединение от сервера от этого адреса клиенту на его адрес. Несмотря на все меры и нововведения, принятые для поддержки FTP-протокола, на практике функция FTP-ALG обычно отключается во всех роутерах и маршрутизаторах с целью обеспечения дополнительной безопасности от вирусных угроз.
NAT и обход брандмауэров
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
Существует несколько методов безопасной передачи файлов, которые иногда называются «Безопасным FTP».
FTPS
Явный FTPS — расширение стандарта FTP, позволяющее клиентам требовать того, чтобы FTP-сессия была зашифрована. Это реализуется отправкой команды «AUTH TLS». Сервер обладает возможностью позволить или отклонить соединения, которые не запрашивают TLS. Это расширение протокола определено в спецификации RFC 4217. Неявный FTPS — устаревший стандарт для FTP, требующий использования SSL- или TLS-соединения. Этот стандарт должен был использовать отличные от обычного FTP порты.
SFTP
SFTP, или «SSH File Transfer Protocol», не связан с FTP, за исключением того, что он тоже передаёт файлы и имеет аналогичный набор команд для пользователей. SFTP, или безопасный FTP, — это программа, использующая SSH (Secure Shell) для передачи файлов. В отличие от стандартного FTP он шифрует и команды, и данные, предохраняя пароли и конфиденциальную информацию от открытой передачи через сеть. По функциональности SFTP похож на FTP, но так как он использует другой протокол, клиенты стандартного FTP не могут связаться с SFTP-сервером и наоборот.
FTP через SSH (не 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
Ниже представлено краткое описание кодов ответа, которые могут быть возвращены 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
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 (есть перевод на русский)
Примечания
- ↑ A Brief History of Mail Архивировано 27 марта 2008 года.
- ↑ 1 2 Chapter 27. Configuring an FTP Server . Дата обращения: 17 апреля 2017. Архивировано 3 июня 2017 года.
- ↑ Chrome 82 полностью лишится поддержки FTP Архивная копия от 16 августа 2019 на Wayback Machine // 3DNews, 16.08.2019