Критическая уязвимость CVE-2019-12815 в ProFTPd

Они ни когда не закончатся, просто клиентам будет все меньше и меньше отдавать. В pure-ftpd даже есть такой параметр не отдавать кому либо если нагрузка сервака больше такой то величины.

Чувак, у сервера может тупо не хватить fd для новых соединений.

Это какой же фтпд не может отдавать с конкретного байта ?

Ты ведь знаешь, что у RETR только один аргумент — имя файла? REST появился уже тогда, когда FTP начали зарывать.

Ну ВЫ бы еще назвали что электричество выключили, какие то детские отмазки, причем упорное умалчивание по фхп

Бгг. Ты к хайлоаду близко не подходил, да?

Ещё раз - при простом копировании проблем нет. При синхронизации диффа - проблемы.

Дано изначально:
Количество файлов - 27,163,816
Место на диске - 7,191,221,652,116

Дифф:
файлы - 757,751
объём - 376,615,015,033

Вот оно такое не умеет. И даже при меньших цифрах.

А диски какие? И да, дифы или сравнение mtime?

Вы о том что изменённых файлов 757,751 на 376 гигов ? Возможно, сам такое не гонял, хотя не понятно на чем ему виснуть. Ну и как вопрос як запускаем?
Второй вопрос, а есть что-то альтернативное и такое же простое?

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

Вот именно так и есть - почти лям файлов за пару дней и почти 400 гигов. Для таких целей есть взрослые решения типа bacula/bareos и всё такое. Они копирует диф за пару часов, rsync такое может неделями синкать, зависнув по пути. Но точно не за пару часов.

Прекрасно. Начали с ftp закончили бакулой. Конечно это очень удобный комфортный инструмент для копирования файлов.

Недоумение вызвало высказывание «Умеет сказать is uptodate при повторе копирования?». При больших объёмах - толку от этого ноль. Вот и весь посыл.

Для таких целей есть взрослые решения типа bacula/bareos и всё такое.

типа оно там не rsync использует, да?

https://docs.bareos.org/IntroductionAndTutorial/WhatIsBareos.html#bareos-comp...

https://docs.bareos.org/DeveloperGuide.html

https://docs.bareos.org/DeveloperGuide/daemonprotocol.html#the-save-protocol-...

Сам посмотри, что ты как маленький.

Сам посмотри, что ты как маленький.

беглый просмотр ничего не показал, процитируешь нужный участок?

Старый не значит плохой.

Если его не развивают, то значит.

процитируешь нужный участок?

Ctrl + F -> rsync же!

Ну и в копилку https://rsync.samba.org/how-rsync-works.html

Значит он само совершенство! Куда уж лучше)

Ну вон так вон. Только вот ты болтать горазд, а сделать не сможешь. Есть 1) Голый Linux 2) Nginx - заливай 15000 файлов.

Никак.

Если его не развивают, то значит.

Я тут по сравнивал его rfc и smtp в обои последний раз вливали в 2007-2008 году ... может я где то и ошибся так что этот показатель так себе.

Взять тех же скульпторов Микиланжело, или музыкальную классику ... и сравнить с современным :( так что старый и без развития это не так уж и плохо.

Не ну я понимаю развитие ЖС и писать приложения на ноде это же ОЧЕНЬ круто :)

Взять тех же скульпторов Микиланжело, или музыкальную классику ... и сравнить с современным

Причём тут музыка и скульптура? Протокол не произведение искусств.
Протокол - техническое средство. И оно должно удовлетворять текущим нуждам.

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

прикольно у ВАС тут :) предыдущий оратор упорно молчал про фхп, а ВЫ тоже из кучи текста выделили самое важное но про смтп как бы не заметили.

mandala, ну что там, закапыватели ftp уже предложили альтернативу или всё как обычно?

Если апач взлетит, то да.

А ты в сообщении на которое отвечаешь где про фтп увидел?

в целом как обычно, что еще ожидать.

Зачем апач? Есть легковесные веб-серверы.

Ну есть в lighthttpd какая-то кастрированная версия webdav.

sftp/clouds, если надо с правами и пр.

Лох, все Ъ пользуются gopher.

Почитал дискуссию, попробовал fizezill'ой законнектиться через sftp, все отлично. Посносил всех ftp'шных демонов.

Это называется «балансировка нагрузки». И это одна из причин, почему FTP выкинули. Потому что FTP не скалируется :)

Во-первых, FTP скалируется ничем не хуже HTTP. В чём разница-то?

Во-вторых, знаешь, почему его обычно не «скалируют»? Потому что нафиг не надо.

В HTTP масштабируют нагрузку на CPU/память. А FTP чудесен тем, что нагрузка на CPU равна примерно нулю, и ограничивают его только скорость сети или диска.

Во-первых, FTP скалируется ничем не хуже HTTP. В чём разница-то?

В том, что FTP не умеет хидеров, например. Поэтому хитрое кеширование контента в нем не очень возможно.

В HTTP масштабируют нагрузку на CPU/память. А FTP чудесен тем, что нагрузка на CPU равна примерно нулю, и ограничивают его только скорость сети или диска.

Какая малость-то. Нагрузка на диск и сеть. Лол.

Во-первых, паталогические проблемы с non-ascii, наследие telnet.

Какое наследие? Можно назвать хоть один более-менее популярный сервер не умеющий UTF8? Этому стандарту уже лет 20.

А теперь расскажите-ка про не ASCII-имена файлов в HTTP...

Во-вторых, ублюдский протокол с отдельным соединением на каждый трансфер, даже на list.

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

Причём про активное можно сразу забыть потому что оно не долетит к клиентам за NAT, а для пассивного вызывает боль настройка фаирвола или проброса портов, потому что ему нужен сразу диапазон.

Не любите диапазоны? Тогда conntrack_ftp — всё сделано давно и без боли.

Эта раздельность, кстати, незаменима при защите от DoS-ов, ведь можно выставить разные лимиты на управляющее соединение и на передачу данных. Всякие HTTP тут в полном пролёте.

Полное отсутствие SSL на практике, из-за чего принципиально нельзя надёжно передать файл

Что-то не вижу связи между SSL (который на практике есть), и надёжностью передачи. Переданность файла определяется по количеству переданных байт, не?

(хорошо видно по рассыпающимся кадрам в фильмах и по целой эпохе имён файлов с CRC в названии)

Вообще-то эта эпоха имён передавалась по IRC, и ни к FTP, ни к надёжности никакого отношения не имеет.

В том, что FTP не умеет хидеров, например. Поэтому хитрое кеширование контента в нем не очень возможно.

Хитрое кеширование чего? Файлов? Так с этим fscache ядра итак справится лучше всех. А что ещё в FTP кешировать-то?

Какая малость-то. Нагрузка на диск и сеть. Лол.

Не малость, но балансировать их обычно и не надо. А если это и делать — делается это так же как и для всех, ftp тут ничем не хуже.

Хитрое кеширование чего? Файлов? Так с этим fscache ядра итак справится лучше всех. А что ещё в FTP кешировать-то?

Ох лол.

Не малость, но балансировать их обычно и не надо. А если это и делать — делается это так же как и для всех, ftp тут ничем не хуже.

Ок, я понял, ты совсем не в теме.

Ок, я понял, ты совсем не в теме.

Не исключено. Так объясни же! Я не против узнать что-то новое.

rsync over ssh

rsync годится только для синхронизации, когда фактически передать надо совсем немного, или для медленного часто обрывающегося канала, чтобы заскриптовать и пойти спать. Для больших объёмов — он жуткий тормоз.

Если несколько небольших файлов по-быстрому, то лучше уж python -m SimpleHTTPServer 8080. Но для каталога или на аплоад это не сработает.

Вообще, мы это недавно уже обсуждали: у ftp нет особых альтернатив по производительности и простоте поддержки.

Расшарить диск с роутера в локалку можно только по ftp. Альтернативы: NFS, который хрен заведёшь под винду, и Samba, которая жрёт больше чем FTP и на порядок сложнее в настройке и поддержке. Всё остальное намного медленнее FTP. А FTP работает на скорости диска/сети, и доступен с любой ОС.

PS: заходя в эту тему, ожидаешь увидеть комменты «proftpd решето, все на pure-ftpd», или «pure-ftpd гавно и хрен настроишь, все на vsftpd»... А тут прямо рассадник закопателей...

Какое наследие? Можно назвать хоть один более-менее популярный сервер не умеющий UTF8? Этому стандарту уже лет 20.

А откуда вы взяли UTF8? FTP никак не регламентирует кодировку. Виндовые клиенты вполне себе считают что там CP1251. Поэтому FTP и известен «проблемами с я».

Что позволяет не подвешивать управляющее соединение пока идёт передача.

Это позволяет дополнительно управляющее соединение, которое все и делают, несмотря на такую полезную возможность FTP.

Или разделять передающий и управляющий хосты.

Да, но кто это когда-нибудь использовал на практике?

И файл может передаваться средствами ядра с нулевой нагрузкой на цпу. Что в этом плохого?

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

Не любите диапазоны? Тогда conntack_ftp — всё сделано давно и без боли.

Вы уж не думаете ли что пакеты исключительно линуксами роутятся? Алсо, что вы там собрались трекать если уж заикнулись про наличие SSL?

Эта раздельность, кстати, незаменима при защите от DoS-ов, ведь можно выставить разные лимиты на управляющее соединение и на передачу данных. Всякие HTTP тут в полном пролёте.

Потрудитесь объяснить чем вам для защиты от DoS помогут раздельные соединения.

Переданность файла определяется по количеству переданных байт, не?

Нет, переданность файла определяется по совпадению размера и содержания переданного и принятого.

Вообще-то эта эпоха имён передавалась по IRC, и ни к FTP, ни к надёжности никакого отношения не имеет.

Нудаконечно, контрольные суммы не имеют никакого отношения к надёжности.

Поискать в сети слово «CDN» ты сможешь сам.

Поискать в сети слово «CDN» ты сможешь сам.

А поточнее? Что там должно противоречить моей фразе:

FTP скалируется ничем не хуже HTTP. В чём разница-то?

Разве ftp://mirror.yandex.ru/ плохо скалируется? Да и чем, в принципе, кеширующий http-proxy отличается от кеширующего ftp-proxy?

А откуда вы взяли UTF8?

RFC-2640

Виндовые клиенты вполне себе считают что там CP1251. Поэтому FTP и известен «проблемами с я».

Считали, во времена win98. С тех пор прошло немного времени...

И, вроде, «проблемами с я» известен как раз сервер proftpd, на других серверах этих проблем не было же?

Да, но кто это когда-нибудь использовал на практике?

Вон, выше по теме, mx__ старательно на что-то намекает...

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

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

Вы уж не думаете ли что пакеты исключительно линуксами роутятся?

Ни в коем случае. А что, ваш файрвол НАСТОЛЬКО стар, что не умеет ftp?

Потрудитесь объяснить чем вам для защиты от DoS помогут раздельные соединения.

Очевидно, можно навесить ограничения на управляющее соединение, не ограничивая соединения данных легитимных юзеров.

И протокол FTP, и сам факт этой раздельности делает DoS-атаку на FTP сложной, а его защиту простой.

Нудаконечно, контрольные суммы не имеют никакого отношения к надёжности.

Нет, не имеют. К целостности имеют, но не к надёжности.

Напоминаю, в тех эпохах в имена файлов добавляли CRC32. Вы серьёзно считаете её «надёжной» контрольной суммой? Надёжной с какой точки зрения?

Считали, во времена win98. С тех пор прошло немного времени…

Только ничего не изменилось, кроме того что FTP стали ещё меньше использовать. А так-то и в этом году видел жалобы на проблемы с «я». Это значит и CP1251 никуда не делся, и правильно 0xff не научились обрабатывать.

И, вроде, «проблемами с я» известен как раз сервер proftpd, на других серверах этих проблем не было же?

Когда я лет 10 назад настраивал одному знакомому ftp, проблемы были везде. И на proftpd, и на vsftp, кажется ещё на pure и ещё каком-то. И был патч для proftpd, и он чинил для одних клиентов, но ломал для других.

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

Я же написал: в неизменном виде, вы читали на что отвечаете? Если бы FTP после STOR/RETR писал/ожидал данные в том же соединении, sendfile замечательно бы работал. Это к тому что ваш аргумент что отдельное соединение нужно для sendfile - чушь собачья. А так-то весь веб давно живёт на мультиплексируемых соединениях и изменении посылаемых данных (сиречь https и gzip налету, который включают первым делом), и насчёт того что всё это не очень работает с sendfile никто не переживает от слова совсем.

Ни в коем случае. А что, ваш файрвол НАСТОЛЬКО стар, что не умеет ftp?

Мой - понятия не имею, я этот говённый протокол пропускать никуда не собираюсь. А вот вы, если заикнулись про «без боли», должны сейчас доказать что это поддерживается во всех софтовых и железных фаирволах, домашних роутерах и всем таком прочем. Сразу скажу, мой tplink не умеет, так что аргумент тоже чушь собачья. Ну и про старость мимо - новый фаирвол скорее костылей под FTP иметь не будет, потому что оный нормальным людям не нужен. Ну и опять же, если вы ранее заикались про SSL, потрудитесь объясниться как оно будет работать.

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

Это всё понятно. Уточню - объяснить значит подробно описать сценарий атаки и как от него помогут раздельные соединения.

И протокол FTP, и сам факт этой раздельности делает DoS-атаку на FTP сложной, а его защиту простой.

Нет, не делает. Вы наверное думаете что DoS будет если по управляющему соединению послать терабайт, и других DoS не бывает. Но нет, ни в этом случает DoS не будет (только если специально не написать криво сервер), ни от других сценариев ограничение на control connection не спасёт. Так что опять мимо.

Нет, не имеют. К целостности имеют, но не к надёжности.

Целостность - часть надёжности.

Вы серьёзно считаете её «надёжной» контрольной суммой? Надёжной с какой точки зрения?

Это вопрос не ко мне. Я просто намекаю что её использовали потому что битые файлы полученные по тупым протоколам типа FTP были нормой. Сейчас с увеличением объёмов стало только хуже.

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

Мне даже интересно, от кого в этом году были жалобы? Удастся найти репорт? А то, насколько я помню, сейчас даже виндовый проводник умеет FTP по UTF-8.

Когда я лет 10 назад настраивал одному знакомому ftp, проблемы были везде. И на proftpd, и на vsftp, кажется ещё на pure [...] И был патч для proftpd, и он чинил для одних клиентов, но ломал для других.

Это было не 10 лет назад, чуть раньше: http://www.opennet.ru/base/patch/ftp_charset_recode.txt.html И, конечно, _такой_ патч ломал utf8-клиентов. Но через несколько месяцев это было исправлено — UTF-клиенты получали свой UTF.

И, да, там тоже пишут, что «проблема буквы я» была только в proftpd.

Это к тому что ваш аргумент что отдельное соединение нужно для sendfile - чушь собачья.

Не нужно (где у меня написано, что нужно?), но очень удобно.

А так-то весь веб давно живёт на мультиплексируемых соединениях и изменении посылаемых данных (сиречь https и gzip налету, который включают первым делом), и насчёт того что всё это не очень работает с sendfile никто не переживает от слова совсем.

Э, что? Ещё как переживают! Для статики sendfile — одна из главных фич.

должны сейчас доказать что это поддерживается во всех софтовых и железных фаирволах, домашних роутерах и всем таком прочем. Сразу скажу, мой tplink не умеет

А мой дешёвый домашний tplink умеет. Но это не важно, ведь эта функция нужна только на файрволе сервера, а вы же не защищаете свой сервер этим tplink-ом?

Ну и опять же, если вы ранее заикались про SSL, потрудитесь объясниться как оно будет работать.

Да как настроят так и будет работать. А разве по скорости/нагрузке есть что-то лучше, чем FTP? Если да, то что? Если нет, то о чём мы спорим?

Вы наверное думаете что DoS будет если по управляющему соединению послать терабайт, и других DoS не бывает.

Нет, обычно наоборот. В принципе бывает DDoS, который полностью забивает канал провайдера, и тут ничего не сделать, но это редко и дорого.

Обычные DoS-ы достаточно примитивны — посылается заранее подготовленный пакет, в котором правится только заголовок. Простейший DoS против HTTP — это «GET /».

Можно выбрать другую страницу, которая подольше генерируется. Можно заранее добавить в заголовки no-cache, чтобы отключить кеширование, и этим ещё поднять нагрузку. И т.д.

Затем этот пакет посылается снова и снова, бесконечно, с множества соединений, пока сервер не ляжет, пытаясь для них всех эту страницу сгенерировать. Саму страницу можно даже не считывать, достаточно её запросить, чтобы создать нагрузку.

Для FTP это не работает. Во-первых, схема атаки усложняется — нужно два соединения и целая серия запросов-ответов. Во-вторых, досить нечего: по CPU не выйдет — FTP его почти не грузит, на управляющее соединение можно наложить жёсткие ограничения. А если атакующий и осилит выкачку файла по соединению данных, то любой ftp-сервер умеет ограничивать скорость и количество подключений, после чего разбушевавшийся юзер блочится, и на этом DoS заканчивается.

Целостность - часть надёжности.

Тогда я не знаю, что вы называете словом «надёжность». Поясните. Кстати, TCP — надёжный протокол? А HTTP?

Я просто намекаю что её использовали потому что битые файлы полученные по тупым протоколам типа FTP были нормой. Сейчас с увеличением объёмов стало только хуже.

То есть и сейчас тоже выкладывают контрольные суммы. Выходит, FTP ничем не хуже других «тупых протоколов», типа HTTPS. Ну ок.

Это было не 10 лет назад

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

Не нужно (где у меня написано, что нужно?), но очень удобно.

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

Э, что? Ещё как переживают! Для статики sendfile — одна из главных фич.

Статика кэшируется, на неё вообще насрать. Если вы про большие файлы, разница в нагрузке с nginx с/без sendfile на графиках не видна вообще.

А мой дешёвый домашний tplink умеет. Но это не важно, ведь эта функция нужна только на файрволе сервера, а вы же не защищаете свой сервер этим tplink-ом?

Вы запутались. Костыли под активный режим нужны на клиенте. Под пассивный никаких conntrack’ов не нужно, просто геморрой с диапазоном портов.

Да как настроят так и будет работать. А разве по скорости/нагрузке есть что-то лучше, чем FTP? Если да, то что? Если нет, то о чём мы спорим?

Конечно есть. Нет ничего ХУЖЕ чем FTP. Так-то файло давно раздаётся по HTTPS, даже все поддомены ftp.* давно отвечают по HTTP.

посылается заранее подготовленный пакет, в котором правится только заголовок

Вы должно быть не знаете как TCP работает. Из-за хендшейка там нельзя в «заранее подготовленный пакет». Это вы с UDP перепутали.

Простейший DoS против HTTP — это «GET /».

Бред конечно, но ход мысли понятен. Тогда против FTP то же самое - команд много. Разумеется, на клиенте никаких дополнительных соединений открывать не надо - PASV уже выжрет ресурсы на сокет на сервере, и никакой ratelimit на control connection вам не поможет.

любой ftp-сервер умеет ограничивать скорость и количество подключений,

Вот, наконец-то мысль начинает двигаться в правильном направлении. Так сервер любого протокола может, и никакие доаолнительные соединения для этого не нужны.

То есть и сейчас тоже выкладывают контрольные суммы. Выходит, FTP ничем не хуже других «тупых протоколов», типа HTTPS. Ну ок.

Выкладывают, потому что нет гарантии что файл не передадут по FTP, несмотря на то что изначальная раздача - торрентами, которые побиться не могут by design.

Я сейчас спросил знакомого виндузятника что там с кириллицей на ftp, он сказал что как были проблемы так и есть. Его слово против анонимуса с лора.

А у меня тут рядом win7 ходит на ftp проводником, и показывает в нём хоть букву «я», хоть китайские иероглифы.

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

Чушь собачья? А попробуйте описать протокол, когда sendfile делается в том же соединении. Хоть на пальцах. Как прервать передачу? Как узнать, что передача прервалась, и дальше идут команды, а не данные файла?

Статика кэшируется, на неё вообще насрать.

Угу, кешируется ядром. А какой самый быстрый способ отдать его из кеша ядра в сокет?

Вы запутались. Костыли под активный режим нужны на клиенте.

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

Под пассивный никаких conntrack’ов не нужно, просто геморрой с диапазоном портов.

Можно и так, ок.

Конечно есть. Нет ничего ХУЖЕ чем FTP. Так-то файло давно раздаётся по HTTPS, даже все поддомены ftp.* давно отвечают по HTTP.

Ну да, для чтения сайтов HTTPS хорош. Я и не предлагаю переводить на FTP все сайты. FTP вне конкуренции только для передачи файлов. Как по https скачать каталог? А как залить каталог по https? А по ftp — это Ctrl+C/Ctrl+V в проводнике.

Поэтому, как ни крути, а ничего лучше FTP нету. Или предлагайте ещё варианты. 🙂

посылается заранее подготовленный пакет, в котором правится только заголовок

Вы должно быть не знаете как TCP работает. Из-за хендшейка там нельзя в «заранее подготовленный пакет».

Кстати, можно. Надо только исправить ACK и контрольную сумму.

Тогда против FTP то же самое - команд много. Разумеется, на клиенте никаких дополнительных соединений открывать не надо - PASV уже выжрет ресурсы на сокет на сервере,

Не выжрет. PASV можно сделать только после авторизации юзера, а у юзера есть лимиты на число и скорость соединений данных. Эти лимиты не дадут юзеру выжрать ресурсы или забить канал через соединение данных.

и никакой ratelimit на control connection вам не поможет.

А он не даст забить канал через управляющее соединение.

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

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

[контрольные суммы] выкладывают, потому что нет гарантии что файл не передадут по FTP, несмотря на то что изначальная раздача - торрентами, которые побиться не могут by design.

Вообще-то их выкладывают рядом с http/https-ссылками... Казалось бы, причём тут ftp ...

А у меня тут рядом win7 ходит на ftp проводником, и показывает в нём хоть букву «я», хоть китайские иероглифы.

Рад за тебя. Но ты не все, да и враль.

Угу, кешируется ядром. А какой самый быстрый способ отдать его из кеша ядра в сокет?

Нет, кэшируется не ядром, кэшируется клиентами. Чего FTP не умеет вовсе.

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

Что не нужно, чтобы файлы передавались? Конечно не нужно. Зато обязательно нужно знать тонкости протокола чтобы выбрать правильный режим и настроить под него фаирвол.

А по ftp — это Ctrl+C/Ctrl+V в проводнике.

У меня Ctrl+C/Ctrl+V это scp и https. При этом не нужно настраивать фаирволы и гадать не побилось ли оно при передаче или не было ли перехвачено. А так конечно понятно - аргументов за протокол не осталось, пошёл проводник.

Не выжрет. PASV можно сделать только после авторизации юзера, а у юзера есть лимиты на число и скорость соединений данных. Эти лимиты не дадут юзеру выжрать ресурсы или забить канал через соединение данных.

Это возможно в любом протоколе.

А он не даст забить канал через управляющее соединение

Это возможно в любом протоколе.

Рад за тебя. Но ты не все, да и враль.

А у тебя (или у твоего друга) win7 работает иначе? Может, вы просто забыли обновить тот FTP-сервер 10-летней давности? 😉

Нет, кэшируется не ядром, кэшируется клиентами. Чего FTP не умеет вовсе.

Ну, чтобы клиент его закешировал, сервер всё равно должен его сначала отдать. Да и ftp тут, в общем-то, не причём. Это мы обсуждали раздачу статики с помощью sendfile всякими nginx-ами...

Что не нужно, чтобы файлы передавались?

Да, «активное» соединение не является необходимым для того, чтобы файлы передавались.

Зато обязательно нужно знать тонкости протокола чтобы выбрать правильный режим и настроить под него фаирвол.

Знать нужно только админу сервера. Если он не по туториалу делает.

А клиенту ничего знать не надо. Также как не надо знать, чем отличаются HTTP/1.0 от /1.1 и /2.0, или что такое HTTP Pipelining. Хотя в браузере эти настройки есть.

У меня Ctrl+C/Ctrl+V это scp и https.

Э... А как раздать каталог по https, так чтобы юзер его себе скопировал по Ctrl+C/Ctrl+V? Да, блин, как вообще раздать каталог по https? Не файл, а каталог?

Кстати, а как раздать каталог по scp? Не всю файловую систему, а отдельный каталог?

А так конечно понятно - аргументов за протокол не осталось, пошёл проводник.

Так это ж и есть один из аргументов. Ещё раз, вкратце, FTP рулит потому что он:
⚫ один из самых быстрых (минимальная нагрузка на сервер);
⚫ работает для файлов и каталогов;
⚫ работает на даунлоад и аплоад;
⚫ прост в настройке, обслуживании и защите;
⚫ прост в использовании, работает под любой ОС, обычно из коробки, без внешнего софта (например, в проводнике в винде).

Это возможно в любом протоколе.

Конкретно это возможно только в протоколе, где можно выставить разные лимиты для данных авторизованных юзеров, и для управляющих соединений. Я такой протокол знаю только один — FTP.

Например, не более 5кБ/с и не более 12 подключений в минуту с одного IP на управляющее соединение, и пусть DoSит...

один из самых быстрых (минимальная нагрузка на сервер)

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

Насчёт нагрузки - я уже говорил: померяйте, потом приходите.

работает для файлов и каталогов работает на даунлоад и аплоад

Это не уникальные свойства FTP.

прост в настройке, обслуживании и защите

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

прост в использовании, работает под любой ОС, обычно из коробки, без внешнего софта (например, в проводнике в винде)

Это не уникальные свойства FTP.

Конкретно это возможно только в протоколе, где можно выставить разные лимиты для данных авторизованных юзеров, и для управляющих соединений. Я такой протокол знаю только один — FTP.

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

А можно как-то оценить, давно ли существует эта уязвимость?

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

Медленных по сравнению с чем? Для авторизации по HTTP диалог может и подлиннее быть...

Насчёт нагрузки - я уже говорил: померяйте, потом приходите.

Меряли когда-то... При раздаче каталога с роутера в локалку на чтение-запись быстрее FTP была только NFS. Но завести NFS под виндой не получилось.

Правда HTTP мы не меряли: по HTTP сложно раздать каталог на чтение-запись.

Это не уникальные свойства FTP.

По отдельности — не уникальные. Но вместе они и делают FTP лучшим выбором.

Ну или предложите альтернативу же!

Я с удовольствием использую что-то лучшее, но что? HTTP плох для каталогов, особенно на аплоад, SCP медленный. Да и как в SCP каталог расшарить, а не всю файловую систему? Какие ещё варианты?

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

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

Соответственно DoSер может свободно флудить запросами, создавая нагрузку и забивая канал. И сервер не сможет его ограничить, пока эти запросы не выполнит. А когда выполнит, и поймёт, что юзера надо ограничить, то уже будет не важно — запрос уже выполнен, нагрузка уже состоялась, DoS достиг цели.

Поэтому управляющее соединение нужно ограничить ДЛЯ ВСЕХ, и для авторизованных и для анонимусов. На FTP это можно сделать. На HTTP нельзя, ведь там нет отдельного управляющего соединения.

PS: кстати, сервер в принципе не способен ограничить подключение к сокету в зависимости от IP ­— у него просто нет для этого средств. Это может только файрвол.