LINUX.ORG.RU

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

 


1

5

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

  • ОС на сервере: Gentoo Linux (или FreeBSD);
  • сервер vsftpd или proftpd;
  • пассивный режим работы. Входящее соединение для команд FTP идёт на порт 21, а затем на порты из заранее заданного диапазона;
  • разрешен анонимный доступ. То есть используется команда ftp ftp.[domain].***, затем вводится имя anonymous, а пароль либо не запрашивается, либо запрашивается и остаётся пустым;
  • входящие соединения на порты FTP не фильтруются, доступ на порт 21 и на порты из диапазона для пассивного режима разрешен отовсюду из интернета;
  • используются популярные клиенты: ftp (linux, BSD), lftp, filezilla, winscp;
  • исходя из вышеуказанного, TLS не используется.
  • UPD: модель использования - клиент скачивает бинарные файлы большого размера (>100Gb). Клиент не может ничего загружать на сервер, у него нет прав на запись.

Вопросы:

1 - какие проблемы могут возникнуть с такой конфигурацией? Уточнение: проблемы именно для безопасности сервера.

2 - если проверить ftp популярных ресурсов из мира opensource, то видно, что многие из тех, что были доступны раньше, теперь недоступны. То есть даже нет A-записи в доменной зоне для ftp. Что же сподвигло их отказаться от ftp именно в последние несколько лет?

Ведь (1) протокол FTP имел те же достоинства и недостатки и 15-20 лет назад. Кто-то скажет, что в 71-м году были несколько иные требования. А в 2005-м году всё было хорошо? И это в тех обстоятельствах, когда (2) значимая альтернатива не предложена: протокол HTTPS изначально создавался не для этих целей, а SFTP затрудняет организацию публичного доступа.

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

4 - что, по вашему мнению, стоит за упрёками в адрес FTP? Почему значимость недостатков внезапно выросла в течение последних нескольких лет?



Последнее исправление: nasecom (всего исправлений: 8)

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

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

Usruser
()

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

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

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

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

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

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

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

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

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

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

nasecom
() автор топика
Последнее исправление: nasecom (всего исправлений: 1)
Ответ на: комментарий от nasecom

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

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

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

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

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

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 2)

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

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

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)

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

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

cvs-255 ★★★★★
()
Ответ на: комментарий от cvs-255

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

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

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

rukez ★★★★
()
Последнее исправление: rukez (всего исправлений: 1)
Ответ на: комментарий от rukez

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

rukez ★★★★
()
Ответ на: комментарий от KivApple

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

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

rukez ★★★★
()

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

vodz ★★★★★
()

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

tz4678_2
()
Ответ на: комментарий от cvs-255

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

cyzemogy
()
Ответ на: комментарий от tz4678_2

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

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

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

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

nasecom
() автор топика
Последнее исправление: nasecom (всего исправлений: 1)
Ответ на: комментарий от cvs-255

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

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

nasecom
() автор топика
Последнее исправление: nasecom (всего исправлений: 2)
Ответ на: комментарий от nasecom

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

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

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

tz4678_2
()
Ответ на: комментарий от cyzemogy

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

tz4678_2
()
Ответ на: комментарий от PolarFox

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

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

tz4678_2
()
Ответ на: комментарий от tz4678_2

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

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

nightmarez
()

Что же сподвигло их отказаться от 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.

EXL ★★★★★
()
Ответ на: комментарий от EXL

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

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

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

tz4678_2
()
Последнее исправление: tz4678_2 (всего исправлений: 1)
Ответ на: комментарий от PolarFox

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

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

nightmarez
()
Ответ на: комментарий от EXL

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

Слишком муторная настройка 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=[...]
pasv_enable=YES - настройка по умолчанию.

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

ascii_download_enable
ascii_upload_enable

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

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

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

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

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

nasecom
() автор топика
Последнее исправление: nasecom (всего исправлений: 9)
Ответ на: комментарий от nightmarez

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

PolarFox ★★★★★
()
Ответ на: комментарий от PolarFox

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

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

nightmarez
()
Ответ на: комментарий от nightmarez

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

pfg ★★★★★
()

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

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

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

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

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

Scondo
()
Ответ на: комментарий от Usruser

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

pfg ★★★★★
()