Причины упрёков в адрес FTP

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

Уже реально пофиг.

Ведь (1) протокол FTP имел те же достоинства и недостатки и 15-20 лет назад.

Какие достоинства? Только инерция.

SFTP затрудняет организацию публичного доступа.

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

У фтп было два преимущества:

1) не надо тратить процессорное время на шифрование

2) им можно качать файлы с сервера на другой сервер напрямую, команды обоим серверам при этом отдавая напрямую с клиента

оба они неизбежно связаны с рисками безопасности и таким образом давно не преимущества. Других объективных преимуществ у фтп нет, ни одного.

рисками безопасности

Да, именно в этом и состоит львиная доля упрёков. Это можно прочитать везде, но ведь мы же на ЛОРе. Был бы очень благодарен, если бы мне кто-то объяснил, в чём именно состоят риски безопасности конкретно той конфигурации, которая описана выше.

В том что протокол полностью открыт для прослушки, подмены данных и кражи паролей кем угодно посередине.

клиент скачивает бинарные файлы большого размера (>100Gb)

Если плевать что клиент скачает в результате(а FTP уязвим для MitM в силу своей открытости), то в общем-то проблем в вышеописанной схеме нет.

И да, если пожертвовать развесистой совместимостью клиентов, то можно завести FTPS, нивелируя тем самым проблему MitM.

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

Но вообще да, накладные расходы HTTP давным давно уже никого не волнуют с современными каналами связи, так что в твоей задаче(где даже авторизации по сути нет) вариант чистого HTTP/HTTPS имеет право на жизнь

разрешен анонимный доступ.
модель использования - клиент скачивает бинарные файлы большого размера (>100Gb). Клиент не может ничего загружать на сервер, у него нет прав на запись.

Здесь FTP решительно не нужен. А если взять HTTP, то клиентам не придется даже вылезать из любимого браузера.

значимая альтернатива не предложена: протокол HTTPS изначально создавался не для этих целей

Протокол HTTP и HTTPS позволяет загрузку произвольных данных. Просто FTP стал излишним и не нужным.

sctp не умеет

Протокол HTTP и HTTPS позволяет загрузку произвольных данных

Я понимаю что ты имел ввиду не это, но как раз «произвольные данные» http хоть и может отдавать но на практике это обычно включено/работает далеко не всегда/везде и часто только для конкретных маймов (например (f)mp4 на это надеется обычно)

Реализация http сервера не обязана поддерживать chunked, реализация ftp - вроде как обязана (по крайней мере я не видел не умеющих, правда эту фичу почему то часто отключали).
Т.е. если у тебя при скачке файла на 100гб коннект пошёл по елде на 99ом гигабайте, то с фтп ты просто запрашиваешь файл с N байта а с http … можешь попробовать но не факт что получится.

Если ЦА сервера пользователи качающие по 100 гб, то включить поддержку chunked проще, чем поднять ещё один сервер, но уже другого протокола.

А отвечая на вопрос темы - всем стало лень поддерживать ftp именно для твоего сценария раздачи файлов без авторизации - http с листингом директорий делает все тоже самое (ну кроме нюансов с докачкой, но большинство современных это все умеет) но при этом позволяет ещё и html раздавать - поддерживать отдельное приложение, торчащее голой попой в интернет ради дублирования фичи «скачать файл но через фтп» смысла ноль, а уж разворачивать на новом сервере - точно лень

Если ЦА сервера пользователи качающие по 100 гб, то включить поддержку chunked проще, чем поднять ещё один сервер, но уже другого протокола.

Йеп, я тоже самое потом дописал :-)
Нюанс правда остаётся в самописанных/библиотечных серверах - я недавно вкрячивал chunked в openjdk’шный и знатно отгрёбал несколько раз на ровном месте.
А фтп в 90ых/нулевых чуть не каждый школьник с нуля писал на информатике :-)

Знаете такой прикол про солонку в студенческой столовой (ведь туда могут подсыпать яд!)? Вот Интернет превратили в такую столовку. Всем плевать, никто не будет разбираться, почему открытый трафик через какого-то провайдера пускать небезопасно и вам там могут навалить не только спама, а натуральный яд в сырцы и бинари. 50 лет назад о таком и подумать не могли и тот же http натурально не понимал ни смещения в файлах для докачки (впрочем, да какие файлы, http вообще не для этого делался) ни нормально машинно читаемых датах (до сих пор кстати). А теперь как результат вам втюхивают шифрацию всего от страничек до видео под предлогом «безопасности», вместо того, чтобы натурально заботиться о безопасности. Кто против — пусть вначале озаботиться токсикологической домашней лабораторией, ведь вам могут и по всему пути продукта от производителя до прилавка или разностчика подсыпать яд вам прямо в колбасу.

Может ты еще и сторонник самописного шифрования? Чтобы уж точно никто не расшифровал!

Вот как раз в тему ‘голой попой в интернет’. Для http полно средств защиты сервера от атак. А как с этим у ftp?

Просто FTP стал излишним и не нужным.

Как вы файлы на сервер заливаете?

Из свежего: провайдер режет загрузку index.html

Т.е. я обновляю содержимое корневой директории сайта. Смотрю, а index.html не приехал. Повторяю – аналогично. Включаю впн – заработало!

Sshfs, scp, например

Неправильно вы это делаете. Правильно - git pull из оепозитория с кодом сайта

У меня к нему упреков нет. Я просто им не пользуюсь. Когда-то давно в винде удобно было в проводнике ftp ссылки открывать… Я им сто лет не пользовался. Может с 2014 где-то. Само по себе как-то. Ты сторонник гипертекстового фидонета?

После пулла нужно будет ещё делать что-то там билд, чтобы получить бандл. Тогда возникает вопрос, почему у меня человеческий ci/cd не настроен. И вот от простого паблишинга пришли к тому, что нужно нанимать девопса.

Ты сторонник гипертекстового фидонета?

Нет. Я сторонник всё же отвечать на поставленные вопросы 1-4.

Я просто им не пользуюсь.
Само по себе как-то.

Это не технический аргумент, а мы в техническом разделе.

А как с этим у ftp?

Да, так как же с этим у ftp? Многие говорят о недостатках, но хотелось бы детализировать с конкретными примерами: что именно может произойти с той конфигурацией, которая приведена в стартовом сообщении. Техническим языком. Это, кстати, и был вопрос №1.

ну ты все тпки в какой-то степени упорот. недостатки ftp:

• открытость: видит провайдер, видит фсб, трафик могут снимать представители недружественных стран…
• отсутствие сжатия. современные процессоры достаточно мощные. че их жалеть? а могли бы трафик экономить

разработка sftp была прекращена в угоду ssh. я пользовался ftp в конце нулевых… просто на шаред хостингах не было доступа по ссх, а фтп был, так же не было веб морд для файловых менеджеров. они только зарождались. посмотри интефейс сипанели. твой фтп просто не нужОн: там можно архив загрузить и автоматом распаковать

современные процессоры достаточно мощные. че их жалеть? а могли бы трафик экономить

Современные каналы достаточно широкие. Чё их жалеть?

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

Text mode/binary mode.

Active/passive mode.

Нет шифрования, пароль всем видно.

пароль всем видно

короче: одно недружественное государство снифает пакеты, ищут там те же пароли, а потом раз и гос услуги взломали… кто, как? - а потому что упоротые ретрограды сидят надрачивают на фтп

новость несложно нагуглить

снифает пакеты

Может проще поднять VPN, чем шифровать каждый вид траффика отдельно?

а твои сферические кОналы где-то в ваккууме существуют или все-таки сокеты - это абстракция над работой с оперативной памятью и несжатые данные оперативки больше жрут?

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

VPN — антипаттерн, протокол должен быть безопасный by design, а не рассчитан на то, что никто не врежется в ethernet-кабель.

ftp придуман и удобен не для браузеров.

Что же сподвигло их отказаться от ftp именно в последние несколько лет?

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

Что, по вашему мнению, стоит за упрёками в адрес FTP?

• Слишком муторная настройка FTP-серверов, да и зоопарк их всяких разных, которые постоянно дохнут или их выкидывают из репозиториев.

• Несовместимость старых FTP-серверов и новых FTP-клиентов или наоборот.

• Какие-то постоянные грабли с переключением Active и Passive режимов.

• Лет 15 назад натыкался на ситуацию, когда где-то там постоянно включался режим TEXT и бинарные файлы коверкало при отправке и загрузке, нужно было явно ставить BINARY.

• Какие-то убогие трюки с портами, которые иногда не нравятся Firewall’ам.

• Низкая безопасность как самого FTP, так и клиентов. Из какой-то там FileZilla и парочки других клиентов постоянно утекали пароли, и через этот FTP постоянно ломали PHP-макакам сайты на shared-хостингах, заливали им шеллы и пр.

• Чудовищный груз Legacy.

FTP напоминает X11, такая же гора и маленькая тележка проблем, которую проще решить выкидыванием и переходом на альтернативы, чем вставлением ещё одного костыля чтобы оно хоть как-то там работало.

Что, собственно все и делают. Тренд выкидывания FTP ты сам заметил. Никто не хочет настраивать все эти FTP-серверы и клиенты если на то нет рациональных причин.

Единственный плюс FTP был когда-то в том, что он был распространён по дефолту везде прямо из коробки. Из любого UNIX-like дистрибутива или даже любого Windows ты мог сразу подключиться к серверу и начать качать нужные файлы.

Я в начале нулевых обычно скачивал с FTP браузеры – Opera или Firefox.

а как же эта проблема с конвертацией ‘\r\n’ в ‘\n’?

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

я помню, кажись, c99.php (не он. в общем не помню чем) через фтп грузил, и он получал доступ за пределы разрешенного каталога

https://www.blackhat.com/presentations/bh-asia-02/bh-asia-02-beale-unix.pdf может тут что-нибудь есть

VPN — антипаттерн, протокол должен быть безопасный by design, а не рассчитан на то, что никто не врежется в ethernet-кабель.

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

Я всё же вернусь к конфигурации в стартовом сообщении, чтобы было что обсуждать:

Слишком муторная настройка FTP-серверов, да и зоопарк их всяких разных

vsftpd вполне актуален (как и proftpd). Минимальная настройка для вышеуказанной конфигурации. Большинство значений в конфиге не указываются вовсе, так как удовлетворяют.

Несовместимость старых FTP-серверов и новых FTP-клиентов или наоборот.

Не смог найти ftp-клиент, несовместимый с данной конфигурацией. Ах да, я не смог осилить консольный клиент ftp в оффтопике 7, поскольку (как я прочитал в интернете) он не поддерживает пассивный режим. Но если ввести в проводнике, то всё открывается. Но в случае с Implicit TLS работали lftp, filezilla, winscp. Проверял и в других (Far Manager, Total Commander), но уже не помню результатов.

Какие-то постоянные грабли с переключением Active и Passive режимов.

Нужно выставить диапазон портов для пассивного режима:

pasv_max_port=[...]
pasv_min_port=[...]

постоянно включался режим TEXT и бинарные файлы коверкало при отправке и загрузке, нужно было явно ставить BINARY

ascii_download_enable
ascii_upload_enable

NO по умолчанию.

Какие-то убогие трюки с портами, которые иногда не нравятся Firewall’ам

На сервере одна строка, разрешающая входящие соединения на порт 21 и на диапазон портов. Исходящие соединения дополнительно разрешать не потребовалось для пассивного режима.

Низкая безопасность как самого FTP, так и клиентов.

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

Исторически сложилось, что шифрованного канала по-умолчанию нигде нет. А когда пытаешься организовывать через vpn-ы, то очень легко промахнуться и пустить данные по нешифрованному каналу. Сколько даркнет-бизнесменов полегло из-за криво настроенного killswitch.

Исторически сложилось, что шифрованного канала по-умолчанию нигде нет

Наоборот же, исторически сложилось, что размазывать ответственность за приватность принято по всем приложениям, мол, разбирайтесь сами, как хотите. Вместо того, чтобы поднять шифрованый канал и забыть о проблеме.

исторически надо было впихнуть в протокол STARTTLS модификацию и всё было бы карошо.
но всем было влом, и исторически не сложилось

этожъ самый TRUEunixway - каждое приложение должно делать одно и точка.
а труюникс-пользователь должон собирать из отдельных приложений необходимый ему конгломерат умности.

Как раз труъ-юникс вей – это когда ftp передаёт файлы, а шифрованием не заморачивается.

Unixway вообще к пользвоателю не имеет никакого отношения. Это для программистов, которые из отлаженных библиотек\программ собирают уже что-то юзабельное.

Unix way — это когда пользователь и программист примерно одно и то же.

Ты сейчас говоришь про юниксвей образца 70х. С тех пор утекло много памяти…

1)Для безопасности сервера и именно в такой конфигурации - никаких особенно. Только для безопасности данных или при других конфигурациях (дыра в которую сам когда-то по нубовости вляпался: использование пользователя вместо субдомена и забыл отключить шелл)

2)Скорее всего отказ от поддержки ftp в браузерах. Ну и да, отдельная зона для ftp совершенно необязательна так-то…

3)Да хоть http. Не говоря о всяких там торрентах. В целом конкретно для описываемой задачи http и ftp примерно равнозначны. Но при этом http шире поддерживается и имеет простой очевидный шифрованный вариант https для защиты от подмены и/или прослушивания данных. Вопрос «изначально создавался» кажется мне некорректным: ftp тоже не под чисто анонимную скачку создавался. Но в сценарии не описаны задачи, которые решает ftp, a http нет (листинг директорий, закачка на сервер и др.)

4)Именно описанный сценарий при наличии http для данных целей. При этом http развивается (QUIC, TLS) а ftp - нет. Поэтому тянуть поддержку ftp чисто для данного сценария в браузерах достало. А для других сценариев есть специализированные клиенты.

Да, если нужен листинг и скачка не браузером и подмена не парит или проверяется сторонним каналом и прослушка не парит - вполне валидный сценарий. Просто из браузерных сценариев ftp начал отмирать, вот и всё…

Защита от ддос, балансировка траффика - это самый минимум. Что с готовыми инструментами для этого у ftp?

дык вот и вешай поверх ftp vpn или иной вариант шифроканала. фтп должон только файлами рулить.

ой вей сударь, как много вам еще предстоит узнать на своей ж…
труюниксвей он аккурат и про пользователя : это вот когда на tar натягиваешь gzip, шифруешь все gpg и закрашиваешь поверх par2 и еще вагон инструментов, с не всегда совпадающим интерфейсом управления, держишь в голове т.д.
а самое веселое начинается через полгода, когда пытаешься вспомнить что этот хитроумный комбайн делает то конкретно со всей тучей своих параметров и как ее изменить что бы получить чтуь другое.