какие уязвимости характерны для протокола ftp

Уязвимости сетевых протоколов

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

Через интернет сейчас делается все: от общения до интернет-банкинга и заключения сделок на миллионы долларов. Поэтому согласитесь, что от того, насколько безопасным будет канал, зависит многое. Давайте попробуем понять, как вообще работает эта самая сеть. Сеть, естественно, является некоторым количеством компьютеров, которые соединены между собой. Используется она для передачи данных. Вот возникает встречный вопрос: а как эти данные передаются? Ответ: посредством проколов. А что же такое протокол? Протоколом является набор правил, по которым и осуществляется этот самый обмен информацией. Мы рассмотрим несколько протоколов, изучим их слабые места и уязвимости, чтобы потом надежно защититься. Итак, приступим.

Для того, чтобы попасть в сеть и просматривать там страницы, пользователь обычно пользуется браузером. Сейчас их великое множество, и пользователям есть из чего выбирать. Это и стандартный Internet Explorer, и Opera, и Avant, и FireFox. Какой же протокол используют эти браузеры? А используют они протокол http. Он в основном применяется для работы с документами формата html (HyperTexet Markup Language) — это язык разметки, который определяет структуру документа. Но кроме этого протокол может работать со следующими элементами:

. текст;
. графика;
. звук;
. анимация;
. видео.

Кроме того, уже довольно продолжительное время язык html практически не используется. На его место пришли php и perl. Именно для передачи этого и был разработан протокол передачи гипертекстовых данных (HyperText Transfer Protocol, HTTP). Этот протокол работает в сеансовом режиме. Это означает, что связь разрывается сразу же после получения необходимой информации. Действует это следующим образом: вы вводите адрес необходимой страницы в адресной строке браузера, дальше ваш компьютер устанавливает соединение с сервером, на котором располагается эта страница. Браузер посредством протокола загружает html-код и отображает его на мониторе с учетом всей информации. Если вдруг в коде имеются сноски на другое содержимое (графика, звук), то браузер опять устанавливает соединение с сервером, на котором лежат данные объекты, и загружает их на компьютер, после чего соединение разрывается, и на монитор все выводится непосредственно с компьютера пользователя (рис.1). При этом каждый из документов отображается независимо от другого. Именно поэтому в браузерах имеется возможность отключения изображений и т.д. При включении этой функции браузер просто не догружает дополнительные объекты (изображения).

Активными элементами являются программы небольшого размера, использующие http-протокол и работающие автоматически. Среди таковых можно выделить Java-апплеты, управляющие элементы ActiveX и команды javascript. Именно эти элементы и являются наиболее уязвимыми местами в протоколе, так как наличие того или иного элемента на загружаемой странице сразу же вызывает его запуск, и, если у вас не стоит антивирус с возможностью постоянного сканирования сетевых протоколов, этот активный элемент может загрузить на ваш компьютер вредоносное ПО, при этом не подав никаких признаков. Если же компьютер оснащен необходимыми средствами безопасности, то он сразу де среагирует на попытку загрузки вируса.

Менее опасными являются файлы cookies, которые загружаются сервером на компьютер пользователи и хранятся на нем некоторое время для последующего использования. Механизм использования этих файлов был разработан корпорацией Netscape Corporation, так как протокол http не оставляет никаких меток, и каждое последующее обращение к одному и тому же серверу расценивается как новое действие. Файлы cookies могут быть использованы только для хранения информации, но и это несет в себе определенный риск. Они хранят такую информацию о пользователе, как Иям компьютера, IP-адрес и т.д. Эта информация может быть использована злоумышленником для проникновения на компьютер пользователя. Естественно, при разработке структуры и параметров работы файлов компанией Netscape были допущены и ошибки. Дело в том, что файлы cookies обычно отсылаются не только на сервер, с которого поступили, но и на другие компьютеры, принадлежащие этому домену. Например, сервер dxm.domen.by принадлежит к тому же домену, что и сервер rey.domen.by, т.к. имена после первой точки у них одинаковы.

Для осуществления работы с финансами, заключения договоров через web-интерфейс необходимо что-то надежнее, чем http. Именно для этой цели и используется разновидность протокола http — https. Это тот же http, но только данные перед отправкой пакуются в с шифрованием посредством протокола ssl (обычно). Это позволяет намного повысить безопасность и работать с важными документами, используя web-интерфейс. В отличие от стандартного http, для обмена информацией используется порт 443.

Это протокол, который позволяет обмениваться файлами в режиме менеджера файлов. Как он работает? Сначала клиент (пользовательский компьютер) с любого порта устанавливает соединение с портом 21 сервера. После сервер устанавливает канал обмена данными через порт 20. Именно это и является уязвимым местом этого протокола. Вместо сервера может выступить злоумышленник и отправить на компьютер жертвы вредоносное программное обеспечение, которое будет воспринято системой как файл, запрашиваемый пользователем. Одним из методов противостояния такого рода атакам является так называемый пассивный метод, когда компьютер пользователя сам дает команду на установку соединения (рис. 2). Пассивный FTP был добавлен к основному большей частью не из-за волнений о безопасности пользователей, а из-за того, что пользователи стали беспокоится о своей безопасности. Применение брандмауэр-систем привело к тому, что серверы не могли установить соединение с клиентом. Поэтому они перешли на пассивный режим, чтобы клиент сам мог инициировать подключение командой port.

Многие пользуются такими программами, как the Bat! или MS Outlook. Эти софтдевайсы для работы с сервером почты используют протокол SMTP (Simple Mail Transport Protocol). Он содержит в себе две составляющие:
. агент передачи сообщений (Message Transfer Agent — MTA);
. агент пользователя (Mail User Agent — UA).

MTA-агент устанавливается на стороне провайдера на сервере и хранит почту клиента до момента передачи. UA-агент — программный компонент, который как раз и выступает программой-почтовиком, поэтому у каждого пользователя он разный (рис. 3). С помощью протокола SMTP почта рассылается без какой-либо шифровки и не прикрепляется к конкретному адресу, что делает очень простым ее перехват, изменение и замену адреса/имени отправителя. Еще одним уязвимым местом этого протокола является утилита Sendmail, которая используется большинством почтовых сервисов. Ее недостаток заключен в сложности, что делает ее подверженной ошибкам/сбоям, а также очень непростой при настройке. В результате бреши в системе безопасности позволяют злоумышленникам делать с пользовательской информацией все что угодно вплоть до удаления.

Протокол, который используется для поиска почты на серверах и обмена с ними. По сути, он является почтовым протоколом, который работает совместно с SMTP. POP (Post Office Protocol) работает через TCP-порт 110. Главнейшим его недостатком является то, что он работает в текстовом формате, и логин/пароль передаются без шифровки.

Аналог протоколу POP, но превосходит его с точки зрения поддержки каталогов, которые находятся на сервере. После широкого внедрения его на серверах почтовых служб была обнаружена его слабая защищенность, в результате чего тысячи пользовательских компьютеров были под угрозой взлома. Практически все компании вернулись к использованию протокола POP, а IMAP (Internet Mail Access Protocol) был отвергнут. Сейчас им пользуются редкие сервисы. Для работы он использовал TCP-порт 143.

Протокол управления передачей является наиболее важным после IP-протокола. Для его функционирования необходимо соединение. Соединение работает в обе стороны. Данные передаются в виде пакетов фиксированной длины. Структуру заголовка TCP-пакета данных вы сможете увидеть на рис. 7. В заголовке пакета, кроме прочих данных, присутствуют два 16-битовых номера конечных портов, как отправителя, так и получателя. При установке соединения системы генерируют порядковые номера, которые при обмене подтверждаются. При каждой отсылке фрагмента пакета также генерируется порядковый номер. Это позволяет точно собирать фрагменты в пакет независимо от времени их получения.

Протокол передачи дейтаграмм пользователя (User Datagram Protocol) является протоколом транспортного уровня, не требующим соединения. Для передачи данных используется IP-протокол. Дополняя его, он позволяет различать службы на системе получателя. UDP-протокол дает очень маленькую нагрузку на систему, что делает его очень удобным и позволяет проще организовывать повторную передачу пакета в случае сбоя. Заголовок UDP-пакета показан на рис. 5. Он не предусматривает отсылку сообщения/уведомления о правильности доставки пакета, его точности и т.д. Это делает его не совсем безопасным, поскольку злоумышленник может без проблем перехватить данные и внести изменения или уничтожить.

IP
Протокол IP (Internet Protocol) не предусматривает соединение и относится к первому виду. Заголовок IP состоит из нескольких полей, каждое из которых несет отдельную информацию:
• Общая длина. Это информация о длине всего пакета в байтах.
• Время жизни (Time to live — TTL). Протокол не подразумевает обязательную активность компьютерной системы получателя. Если пакет был отправлен, а система, которой он предназначался, неактивна, то пакет будет циркулировать по сети, пока система не сможет его принять. Чтобы это не происходило (ведь возможен перехват важной информации), при формировании пакета задается такой параметр, как время жизни. При прохождении пакетом промежуточного пункта (маршрутизатора и т.п.) этот параметр уменьшается, при достижении значения, равного нулю, пакет уничтожается.
• Версия. Информация о номере версии протокола, который использовался при создании пакета.
• Длина заголовка. Тут указывается длина заголовка в 32-разрядных единицах.
• Тип службы. Этот параметр определяет важность пакета, а также тип пути, по которому пакет будет передаваться (защищенный маршрут и т.д.).
• Идентификатор. Во время передачи пакет может быть для удобства разбит на фрагменты. Именно с помощью идентификатора он собирается в единое целое на месте.
• Флаги. Под флаги отводится по одному биту. Первый флаг определяет возможность фрагментации. Второй участвует при сборке пакета на месте — он точным образом определяет, откуда был послан пакет.

• Смещение фрагмента. После разбиения пакета на части им присваиваются последовательные номера. Однако пакеты могут рассылаться разными путями через сеть, поэтому порядок их прихода нестабилен. Пакет может быть сформирован из фрагментов только при наличии всех фрагментов.
• Протокол. В этом параметре указывается описание стороннего протокола, который используется в IP-пакете.
• Контрольная сума заголовка. Этот параметр необходим для обеспечения целостности заголовка. При формировании пакета на системе-отправителе высчитывается значение и сохраняется в этом поле. После прихода система-получатель так же высчитывает значение и сравнивает с сохраненным, таким образом, делается вывод о целостности заголовка пакета.
• Адрес отправителя. Адрес системы отправителя.
• Адрес получателя. Адрес системы получателя. Тут, как и в адресе отправителя, указывается IP-адрес.
• Опции IP-протокола. В этом поле в основном хранится информация о сети прохождения, о маршрутизации и т.д.
Структура пакета IP-протокола показана на рис. 6.

Так как протокол IP не может устанавливать соединение, ему необходим тот инструмент, который будет делать это за него. Например, уведомить систему получателя, что время существования пакета истекло. Для выполнения этих задач в протокол IP был встроен ICMP (Internet Control Message Protocol) протокол. Наиболее уязвимым местом этого протокола является то, что злоумышленник, изменяя информацию ICMP-протокола, может заставить систему получателя реагировать таким образом, как ему будет удобно, для последующего получения контроля над ней. На рис. 4 показана структура заголовка ICMP-пакета данных. ICMP-пакет содержит информацию об ошибках, диагностическую и т.д. Инициируется она внутренним образом и обрабатывается на уровне IP-протокола. Различают несколько типов сообщения ICMP-протокола. Они характеризуются номером в заголовке и содержат разные данные.

• Echo Reply (0). Это сообщение рассылается при приеме сообщения Echo Request с другой компьютерной системы. В поле данных заносятся тестовые данные, данные о времени функционирования и т.п.
• Destination Unreachable (3). Это сообщение отсылается отправителю в том случае, когда отправленный им пакет данных не может быть доставлен системе-получателю вследствие ее недоступности. Сообщения такого типа могут быть использованы злоумышленником для разрыва соединения.
• Source Quench (4). Сообщение такого рода отправляется системе-отправителю, если маршрутизатор не может справиться с потоком данных. В таком случае отправитель должен снизить поток.
• Redirect (5). Сообщение такого рода отсылается отправителю пакета в том случае, если маршрутизатор заметит, что путь пакета неоптимален.
• Echo Request (8). Это сообщение отправляется для того, чтобы определить, достижим ли получатель.
• Time Excceded (11). Это сообщение отправитель получает в результате отвержения пакета системой-получателем из-за истечения времени жизни.
• Parameter Problem (12). Если же пакет отвергся из-за ошибок в заголовке и т.п., то отправитель получает сообщение этого типа.
Ярким примером сообщения ICMP-протокола является команда ping, использующаяся в большинстве систем для проверки их работоспособности.

Протоколы обмена мгновенными сообщениями

Под этот подзаголовок подходят все агенты обменов быстрыми сообщениями. Работают они как электронная почта, только нет архивов сообщений. А значит, получать информацию из этих сообщений можно так же, как и из почты — например, атакой «человек-посередине». Это делает сообщения небезопасными. Именно по этой причине и возможен брут номера icq с последующей его кражей. Разные клиенты используют разные порты. ICQ использует динамический TCP-порт и UDP-порт 4000; AOL Instant Messenger использует TCP-порт 5190; Yahoo Messenger — TCP-порт 5050; MSN Messenger пользуется TCP-портом 1863.

Сейчас трудно встретить игры, в которых нет поддержки сетевого режима. Это тоже уязвимое место. Если отправить на порт, используемый определенный игрой, специально сформированный пакет во время активности игры, то можно вызвать определенную реакцию системы — например, открытие стороннего порта.

На этом закончу. Теперь, думаю, у вас сложилось более точное представление о том, какую опасность представляет собой тот или иной протокол.

Евгений Кучук, q@sa-sec.org, SASecurity gr.

Компьютерная газета. Статья была опубликована в номере 19 за 2008 год в рубрике безопасность

Источник

Русские Блоги

Исследование уязвимостей протокола ftp в сочетании с snort (1)

cve-2004-1166

Описание уязвимости:
Уязвимость внедрения CRLF в Microsoft Internet Explorer 6.0.2800.1106 и более ранних версиях позволяет удаленным злоумышленникам выполнять произвольные команды FTP через ftp: // URL, который содержит кодировку URL перед командой ftp. Символ новой строки («% 0a»), который вызывает вставку команды в созданный сеанс FTP, как показано с помощью команды PORT.
Эта уязвимость вызвана неправильной обработкой управляющих символов ASCII. Злоумышленник может использовать эту уязвимость, побуждая пользователей щелкнуть тщательно созданный URL-адрес, содержащий управляющие символы ASCII. Злоумышленник, использующий уязвимость, должен знать местоположение и адрес FTP-сервера, а также действительную комбинацию имени пользователя и пароля, к которой может подключиться целевой пользователь. Злоумышленники могут использовать эту уязвимость только для запуска команд консоли FTP с разрешениями учетной записи, содержащейся во вредоносном URL.
Эта уязвимость существует из-за неправильной обработки управляющих символов ASCII в URL-адресах FTP. В Konqueror эти символы обрабатываются библиотеками kio_ftp и kioslave. Когда уязвимый обозреватель встречает управляющий символ ASCII (например, символ новой строки), приложение передает этот символ как символ новой строки. Таким образом, любые символы, следующие за управляющими символами ASCII, будут переданы FTP-серверу как консольная команда. Это может позволить злоумышленнику подавать произвольные команды удаленному FTP-серверу из уязвимой пользовательской системы. Злоумышленник должен знать действительные учетные данные для аутентификации, которые можно использовать во вредоносном URL-адресе для получения доступа к целевому FTP-серверу.

1）Ответ сервера клиенту
2）соответствие
1.ftp://
2. Символы, кроме «,», совпадают любое количество раз.
3.% 0a, без учета регистра
можно комбинировать для соответствия:ftp://lalala%0a

1）Ответ сервера клиенту
2）Установите курсор для обнаружения следующих буферов: http, smtp и т. Д.
3）
fast_only означает, что он используется только для быстрого сопоставления, а не для параметров правила.
^ \ s означает соответствие любому непустому символу
+? Это ленивое сопоставление, сопоставление слева направо, до совпадения с \ x25 (\ x25 на самом деле%), 0, a или b, без учета регистра
После комбинации он может соответствовать следующим образом:
ftp://abcdx%a

cve-2004-1376

cve-2004-1992

cve-2007-0217

Описание уязвимости:
Код FTP-клиента wininet.dll в Microsoft Internet Explorer 5.01 и 6 может позволить удаленному злоумышленнику выполнить произвольный код через ответ FTP-сервера определенной длины, что приведет к прекращению записи нулевого байта. За пределами буфера, что приводит к повреждению кучи.
The vulnerability is due to insufficient sanitization of FTP server responses

Комбинация может совпадать следующим образом:
123a (1019) smi

cve-2007-0247

Комбинация может соответствовать:
ftp://.a;type=D

cve-2008-2541

Описание уязвимости:
Множественные переполнения буфера на основе стека в службе шлюза HTTP (icihttp.exe) в CA eTrust Secure Content Manager 8.0 позволяют удаленным злоумышленникам выполнять произвольный код или вызывать отклонение с помощью длинных ответов FTP Сервис, который связан с (1) полем месяца файла в команде LIST; (2) командой PASV; (3) каталогами, файлами и ссылками в команде LIST.

Эта уязвимость существует в службе шлюза HTTP icihttp.exe из-за небезопасной обработки слишком долгого ответа FTP-сервера PASV. По умолчанию служба работает на TCP-порту 8080. Неаутентифицированный удаленный злоумышленник может воспользоваться этой уязвимостью, создав вредоносный FTP-сервер за пределами HTTP-шлюза. Затем изнутри HTTP-шлюза злоумышленник может войти на FTP-сервер и выдать команду PASV FTP. На этом этапе злонамеренный FTP-сервер может ответить на команду PASV очень длинным ответом. Когда icihttp.exe обрабатывает этот ответ, может произойти переполнение буфера, поскольку служба не выделяет достаточно места для обработки тщательно разработанного ответа с данными. Это переполнение может вызвать сбой службы или выполнение произвольного кода с привилегиями SYSTEM.

После совмещения его можно сопоставить следующим образом:
-R-r-r-r-r- a a a 4096

cve-2008-3734

Описание уязвимости:
Уязвимости форматной строки в Ipswitch WS_FTP Home 2007.0.0.2 и WS_FTP Professional 2007.1.0.0 позволяют удаленным FTP-серверам вызывать отказ в обслуживании (сбой приложения) или передавать приветствие подключения (ответ) Спецификаторы строки формата (спецификаторы строки формата) выполняют произвольный код.

1）Ответ от сервера к клиенту
2）соответствие%
3）
не соответствует трем последовательным числам + (пробел)
соответствует любому непустому символу любое количество раз
соответствует%
соответствует буквам, цифрам, знакам подчеркивания или китайским символам.
не чувствителен к регистру

Комбинация может соответствовать:
abcd%a

cve-2008-4321

Описание уязвимости:
FlashGet (ранее JetCar). Переполнение буфера в FTP 1.9 позволяет удаленному FTP-серверу выполнять произвольный код посредством длинного ответа на команду PWD.
При работе со слишком длинными откликами FTP PWD возникают лазейки из-за недостаточных ограничений границ. Злоумышленник может воспользоваться этой уязвимостью, убедив целевого пользователя подключиться к вредоносному FTP-серверу из веб-браузера, настроенного для загрузки файлов с FTP-сервера с помощью FlashGet. Уязвимость может вызвать переполнение буфера на основе стека в FlashGet, что может вызвать сбой браузера или позволить злоумышленнику выполнить произвольный код с разрешениями пользователя. Злоумышленник может запустить атаку, убедив пользователей перейти по ссылке для загрузки файлов с вредоносного FTP-сервера.

1）Ответ сервера клиенту
2）
соответствует 257, а начало 20 в шестнадцатеричном формате
соответствует непустым символам, которые больше или равны 257 раз.
соответствует шестнадцатеричному числу 20
соответствует mi

В совокупности они могут совпадать следующим образом:
257 / x20a (257a) / x20mi

Источник

Умрёт ли FTP? Расцвет и упадок протокола

Вот небольшое известие, которое вы могли пропустить, восстанавливая свою жизнь после начала кризиса COVID: из-за того, что вирус перемешал всем карты, Google пропустила выпуск Chrome версии 82. «Да кого это волнует?», — спросите вы. Ну, хотя бы пользователей FTP, или File Transfer Protocol. Во время пандемии Google отложила свои планы по убийству FTP, и теперь, когда буря немного успокоилась, Google недавно объявила о том, что возвращается к мысли об убийстве в Chrome версии 86, которая снова сократит поддержку протокола, и окончательно убьёт его в Chrome 88. (Mozilla объявила о похожих планах на Firefox, утверждая, что дело в безопасности и возрасте поддерживающего протокол кода.) Это один из старейших протоколов, который поддерживает мейнстримный Интернет (в следующем году ему исполнится 50 лет), но эти популярные приложения хотят оставить его в прошлом. Сегодня мы поговорим об истории FTP, сетевого протокола, который продержался дольше, чем почти все остальные.

Именно в этом году родившийся в Индии студент магистратуры MIT Абхай Бхушнан впервые разработал File Transfer Protocol. FTP, появившийся спустя два года после telnet, стал одним из первых примеров работающего пакета приложений для системы, которая в дальнейшем стала известна как ARPANET. Он обогнал электронную почту, Usenet и даже стек TCP/IP. Как и telnet, FTP по-прежнему используется, хоть и ограниченно. Однако в современном Интернете он потерял значимость, в основном из-за проблем с безопасностью, а его место занимают альтернативные протоколы с шифрованием — в случае FTP это SFTP, протокол передачи файлов, работающий поверх протокола Secure Shell (SSH), по большей мере заменившего telnet.

FTP настолько стар, что появился раньше электронной почты, а в начале он сам играл роль email-клиента. Наверно, неудивительно, что среди множества программ прикладного уровня, созданных для раннего ARPANET именно FTP выделился и проложил себе дорогу в мир современных технологий.

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

«Различия в характеристиках терминалов учитываются программами систем хостов в соответствии со стандартными протоколами», — пишет он, упоминая и telnet, и протокол удалённого ввода заданий той эпохи. «Однако чтобы использовать их, вам необходимо знать различные условности удалённых систем».

Телетайпный терминал эпохи ARPANET.

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

В своём RFC Бхушан пишет:

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

В интервью подкасту Mapping the Journey Бхушан сообщил, что приступил к разработке протокола из-за очевидной потребности в приложениях для зарождающейся системы ARPANET, в том числе из-за потребности в электронной почте и FTP. Эти первые приложения стали фундаментальными строительными блоками современного Интернета и за последующие десятилетия сильно усовершенствовались.

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

«Мы спросили: „Почему бы не добавить в FTP две команды под названием mail и mail file?“ Команда mail будет использоваться для обычных текстовых сообщений, а mail file для вложений писем, которые существуют и сегодня», — говорит он в интервью.

Разумеется, Бхушан был не единственным, кто принял участие в разработке этого фундаментального раннего протокола, ведь после выпуска из вуза он получил должность в Xerox. Созданный им протокол продолжил своё развитие без него, получив в 1970-х и 1980-х серию обновлений в виде RFC; в том числе примерно в 1980 году появилась его реализация, позволявшая обеспечивать поддержку спецификации TCP/IP.

Хотя со временем появлялись незначительные обновления, чтобы протокол успевал за временем и мог поддерживать новые технологии, версия, которую мы используем сегодня, была выпущена в 1985 году, когда Джон Постел и Джойс К. Рейнольдс разработали RFC 959 — обновление предыдущих протоколов, лежащих в основе современного ПО для работы с FTP. (Постел и Рейнольдс, среди прочего, примерно в то же время работали над системой доменных имён (DNS).) Хотя в документе эта версия описывается как «предназначенная для исправления незначительных ошибок документации, улучшения объяснения некоторых функций протокола и добавления новых вспомогательных команд», стандартной стала именно она.

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

Во многих смыслах, из-за столь раннего появления в истории Интернета FTP повлиял на структуру множества последующих протоколов. Можно сравнить его с чем-то, что часто менялось и совершенствовалось в течение нескольких десятков лет, допустим, с баскетбольными кроссовками. Да, Converse All-Stars — это хорошая обувь, и в нужных условиях с честью она послужит и сегодня, но с гораздо большей вероятностью успеха добьётся какая-нибудь модель от Nike, вероятно, под брендом Air Jordan.

File Transfer Protocol — это Converse All-Star Интернета. Он передавал файлы ещё до того, как это стало круто, и по-прежнему сохраняет часть своей притягательности.

«Никто не зарабатывал на Интернете. Скорее наоборот, на него тратили кучу денег. Мы смело сражались в этой битве и знали, что у него был потенциал. Но если кто-то скажет вам, что он знал, что будет дальше, то это ложь. Ведь я видел всё сам своими глазами».

Так Алан Эмтедж, создатель Archie, считающегося первым поисковым движком Интернета, рассказывал Internet Hall of Fame почему его изобретение, позволявшее пользователям искать на анонимных FTP-серверах файлы, не сделало его богатым. Если вкратце, то Интернет тогда был некоммерческим, а аспирант и работник техподдержки монреальского Университета Макгилла Эмтедж без разрешения использовал сеть вуза для работы Archie. «Но именно так и лучше всего было поступить. Как гласит старая пословица, лучше просить прощения, чем разрешения». (Как и Бхушан, Эмтедж был иммигрантом, он родился и вырос на Барбадосе и приехал в Канаду, став студентом благодаря своим достижениям.)

Скриншот WS_FTP — FTP-клиента для Windows, который был довольно популярен в 90-х.

Почему FTP может быть последней связью с нашим прошлым, до сих пор используемым онлайн

Как я писал несколько лет назад, если взять старую книгу об Интернете и попытаться пройти по старым ссылкам, то вероятность добраться до указанного в них ПО выше всего, если оно хранится на большом корпоративном FTP-сайте, потому что такие сайты обычно закрывают не очень часто.

Крупные технологические компании наподобие Hewlett-Packard, Mozilla, Intel и Logitech десятками лет использовали эти сайты для распространения среди конечных пользователей документации и драйверов. И по большей части эти сайты по-прежнему находятся онлайн, храня контент, который находился там долгие годы.

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

Пример того, как выглядит FTP в современном веб-браузере (ftp.logitech.com).

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

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

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

В том интервью Скотт заметил, что долгая жизнь таких FTP-сайтов на самом деле больше исключение, чем правило.

«Невероятно странно, что FTP-сайты накопили инерцию, позволившую им продолжать работать в течение 15-20 лет», — сказал он.

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

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

— Цитата из статьи 1997 года в Network World; в ней говорится, что FTP, несмотря на свою неуклюжесть, по-прежнему остаётся хорошим вариантом для надомных работников и корпоративных пользователей Интернета. Хотя автор статьи был заинтересованным лицом (Роджер Грин являлся президентом компании Ipswitch, крупного изготовителя программ для FTP), его аргументы, тем не менее, соответствовали духу эпохи. Протокол был отличным способом передачи больших файлов через сети и сохранения их на сервере. Проблема в том, что FTP, несмотря на своё постепенное совершенствование, будет вытеснен гораздо более изощрёнными альтернативами, как протоколами (BitTorrent, SFTP, rsync, git, даже современными вариантами HTTP), так и облачными системами наподобие Dropbox или Amazon Web Services.

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

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

Panic’s Transmit — современный пример FTP-клиента. Множество современных клиентов поддерживает широкий набор протоколов, а не только старый добрый FTP.

Позже я выпустился и FTP-сервер отключился навсегда; к тому же всё равно возникли более эффективные варианты его замены, например, BitTorrent, и более законные, типа Spotify и Tidal.

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

Даже если популярные браузеры в ближайшие месяцы избавятся от поддержки FTP, это не значит, что у нас совершенно исчезнут другие способы работы с этим протоколом. Специализированное ПО, разумеется, по-прежнему будет существовать. Но, что более важно, для замены устаревшего протокола FTP есть веские причины.

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

Самые распространённые способы его использования, например, для организации публично доступных анонимных FTP-серверов, по сути, потеряли свою популярность. А в своей основной нише он в конечном итоге был заменён более защищёнными и современными версиями, например SFTP.

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

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

На правах рекламы

VDS с посуточной оплатой для любых целей — это про наши эпичные серверы. Максимальная конфигурация — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe.

Источник