После двух с половиной лет разработки увидел свет новый значительный выпуск ftp-сервера ProFTPD 1.3.5 (http://www.proftpd.org/), сильными сторонами которого являются расширяемость и функциональность, а слабыми - недостаточное внимание к качеству и безопасности кода. Одновременно доступен корректирующий выпуск ProFTPD 1.3.4e, который станет последним в серии ProFTPD 1.3.4.
Основные новшества (http://www.proftpd.org/docs/RELEASE_NOTES-1.3.5) ProFTPD 1.3.5:
- Новые модули:
- mod_dnsbl для ограничения доступа по черным спискам, опрашиваемым через DNS (DNSBL);
- mod_snmp для накопления различной статистики и предоставления доступа к ней через протокол SNMP (поддерживается SNMPv1 и SNMPv2);
- mod_log_forensic для сбора данных о действиях пользователя в рамках установленного сеанса, но сброса данной информации в лог только при выявлении необычной активности;
- mod_rlimit - в отдельный модуль вынесен код для задания лимитов через директивы RLimitCPU, RLimitMemory и RLimitOpenFiles;
- mod_geoip для получения информации о местоположении пользователя по его IP-адресу. На основе полученных данных могут быть созданы фильтры (например, можно запретить доступ из отдельных стран) или просто добавлена информация в лог.
- Новые директивы конфигурации
- LDAPLog для сохранения лога работы mod_ldap в отдельном файле;
- RLimitChroot для включения дополнительных ограничений на запись в директории /etc и /lib внутри chroot-окружения с целью защиты от атак (http://www.opennet.me/opennews/art.shtml?num=32450) по организации загрузки фиктивных библиотек.
- SQLUserPrimaryKey и SQLGroupPrimaryKey (mod_sql) для определения первичных ключей для хранимых в SQL таблиц с пользователями и группами;
- AllowChrootSymlinks для запрета следования символическим ссылкам при переходе в chroot;
- CapabilitiesRootRevoke для отмены полного сброса всех root-привилегий при использовании модуля mod_cap
- IfAuthenticated для задания набора директив, применяемых только к сеансам с аутентифицированным пользователем;
- FactsOptions для тонкой настройки MLSD/MLST-вывода модуля mod_facts;
- QuotaDefault для задания квоты по умолчанию, применяемой модулем mod_quotatab если квота для пользователя явно не определена;
- RewriteMaxReplace для ограничения максимального числа замен в mod_rewrite;
- TLSServerCipherPreference для расстановки приоритетов в выборе шифров при использовании mod_tls;- В директиве ExecOnEvent добавлена поддержка флага "~" при указании которого команда исполняется с правами вошедшего пользователя. ExecOnEvent также теперь допустимо использовать внутри блоков VirtualHost;
- В директиву SFTPOptions добавлена опция IgnoreSCPUploadTimes для запрета изменения времени модификации и создания файлов;
- В директиву SFTPOptions добавлена опция AllowInsecureLogin для принудительного включения поддержки небезопасных алгоритмов шифрования в mod_sftp, используемых в тестовых целях. Например, без использования "SFTPOptions AllowInsecureLogin" mod_sftp не работает при указании 'none' в SFTPCiphers и SFTPDigests;- Добавлена поддержка команды SSCN FTP для организации безопасной передачи данных между серверами (site-to-site, FXP);
- Обеспечена корректная работа конфигураций с TLS 1.1/1.2;
- Изменён формат вывода времени в логах, который теперь соответствует спецификации ISO-8601. Например, вместо "Jan 31 15:33:03" теперь указывается "2013-01-31 15:33:03,832";
- В утилиту ftpasswd добавлена поддержка хэшей SHA-256 и SHA-512, обеспечена возможность блокирования аккаунтов (--lock/--unlock);
- Изменён метод обработки команд PORT и EPRT, адреса в которых теперь проверяются на вхождение в список непубличых подсетей (10.x.x.x, 192.168.x.x и 172.16.x.x, определённый в RFC 1918 (http://tools.ietf.org/html/rfc1918). Запросы с такими адресами теперь игнорируются и вместо них используется IP с которого поступил запрос;
- В модуле mod_sql_passwd добавлена поддержка алгоритма хэширования PBKDF2 (http://ru.wikipedia.org/wiki/PBKDF2). Управление производится через директиву SQLPasswordPBKDF2;
- В модули mod_sftp и mod_tls добавлена поддержка методов шифрования по эллиптическим кривым (Elliptic Curve, ECDSA, ECDH). Обеспечена возможность аутентификации отдельных пользователей по цифровым сертификатам без пароля (директива TLSUserName).
- В mod_sftp добавлена поддержка SFTP-расширения "fsync@openssh" ( включается через SFTPExtensions fsync) для обработки клиентских запросов на принудительный сброс буферов.URL: http://www.proftpd.org/
Новость: http://www.opennet.me/opennews/art.shtml?num=39785
Интресно, где сейчас массово востребован FTP?На всякий случай - кроме shared hosting-ов с PHP.
Многие конторы используют FTP-серверы в качестве инструмента для обмена файлами с внешними контрагентами.
Бюстгальтерия, одножопа, медок, клиентбанки, клиентбутылки и т.п.
А расшифровать можно, что есть медок и клиентбутылки?
Видимо, клиент-банки с узким в^H горлышком.
> в качестве инструмента для обмена файлами с внешними контрагентами.А не проще HTTP? Он через любые фаеры пролазит, в отличие от.
Не поверишь, но много кто использует. Ибо проще всего объяснить планктону как что-то туда закачать/скачать оттуда. К тому же альтернативы не всегда хорошо работают. Я, например, файлы на php shared хостинг закачиваю обычно через ssh. Это заметно медленнее, чем по ftp. Но мне лень каждый месяц менять пароль, поэтому я просто использую ключ для ssh, который не нужно менять.
А почему ssh медленнее? Помню еще лет восемь назад экспериментировали в локалке на офисных машинах и оверхед от шифрования был в пределах погрешности.
> А почему ssh медленнее? Помню еще лет восемь назад экспериментировали в локалке
> на офисных машинах и оверхед от шифрования был в пределах погрешности.Потому, что трафик при передаче через ssh (scp, sftp) возрастает примерно в 3 раза... Ваш К.О.
Впрочем, в виндовой офисной локалке (т.е. у безруких одминов) сеть обычно настолько нетороплива, что не позволит этого увидеть. То есть лимитирует скорость приема/записи (виндового) сервера, а не скорость ssh/ftp.
У меня до 3 МБайт/с ssh и до 25-30 МБайт/с ftp по гигабитной локальной сетке.
Сморозил. ssh pipe 40-50 MB/s по гигабиту, с упором в cpu (blowfish).
Дай угадаю, "3 МБайт/с" - это винда + winscp?
> Дай угадаю, "3 МБайт/с" - это винда + winscp?Да знаешь, шифровать гигабит может поднапрячься и не только винда. Какой-нибудь ноут на атоме поднапряжется гигабит шифровать и так и сяк.
>Потому, что трафик при передаче через ssh (scp, sftp) возрастает примерно в 3 раза... Ваш К.О.Ты этим больше не ширяйся! Не менее ваш, Ваш К.О.
>Потому, что трафик при передаче через ssh (scp, sftp) возрастает примерно в 3 раза... Ваш К.О.Совсем не капитан, ты что, данные перед шифрованием в Base64 перегоняешь, а после шифрования поток ещё раз в Base64 ? :)
PS Лучшего объяснения не придумал, как траффик в 3 раза увеличить. :)
Ну разве я виноват, что у вас руки из задницы растут? Две линуксовые машины, 100mb сетка, scp:100% 93MB 10.3MB/s 00:09
real 0m8.604s
user 0m2.309s
sys 0m0.467sЧуть не забыл. Одной из машин уже семь лет, то есть даже древний атлончик не является проблемой. В качестве пробных данных было видео, то есть несжимаемый контент.
> 100% 93MB 10.3MB/s 00:09А теперь на гигабите, плиз :)
А у тебя есть гигабитные каналы хотябы до Германии?
для гигабитных каналов ssh патчат hpn патчами.
> для гигабитных каналов ssh патчат hpn патчами.Во, спасибо -- запамятовал уже имечко.
> А у тебя есть гигабитные каналы хотябы до Германии?У меня есть гигабитная локалка.
Человек сказал, что трафик возрастает втрое. А следующий человек это опроверг. Причём тут гигабит вообще?
> Причём тут гигабит вообще?При том что в гигабитной локалке шифрование очень все тормозит и сильно грузит машины.
>> Причём тут гигабит вообще?
> При том что в гигабитной локалке шифрование очень все тормозит и сильно
> грузит машины.И кто мешает отключить это шифрование?
Более того, то не ответ. Трафик втрое не возрастает. Иначе на 100мегабитах можно было бы пропихнуть лишь 33.
>> 100% 93MB 10.3MB/s 00:09
> А теперь на гигабите, плиз :)А что вы лыбитесь, думает что-то другое будет?
% time scp foo.MP4 xxx:/dev/null
foo.MP4 100% 957MB 50.4MB/s 00:19
scp foo.MP4 xxx:/dev/null 2.93s user 1.36s system 21% cpu 19.684 totalЭто древний core2duo, и канал, как вижно, забит чуть менее чем полностью.
В домашней локалке под i7 scp работает со скоростью канала и не создаёт нагрузки на CPU вообще.
>> А почему ssh медленнее? Помню еще лет восемь назад экспериментировали в локалке
>> на офисных машинах и оверхед от шифрования был в пределах погрешности.
> Потому, что трафик при передаче через ssh (scp, sftp) возрастает примерно в
> 3 раза... Ваш К.О.
> Впрочем, в виндовой офисной локалке (т.е. у безруких одминов) сеть обычно настолько
> нетороплива, что не позволит этого увидеть. То есть лимитирует скорость приема/записи
> (виндового) сервера, а не скорость ssh/ftp.
> У меня до 3 МБайт/с ssh и до 25-30 МБайт/с ftp по
> гигабитной локальной сетке.Обычно скачиваю сжатые файлы со скоростью 9-10 MB/s по uplink 100Mb/s используя scp, без тюнинга, железо правда минимум E3-1230:)
> трафик при передаче через ssh (scp, sftp) возрастает примерно в 3 раза... Ваш К.О.Даже если Compression yes или это был вообще rsync? Да и без них неочевидно, мягко говоря.
> У меня до 3 МБайт/с ssh и до 25-30 МБайт/с ftp по гигабитной локальной сетке.
Это процессоры/диски древние или локалка такая. На хорошем процессоре пятилетней давности 50+ MB/s по гигабиту мне ssh даёт без каких-либо ухищрений.
> Потому, что трафик при передаче через ssh (scp, sftp) возрастает примерно в 3 раза... Ваш К.О.Капитан олигофрен, вы ли это? Гнусная ложь, ничего там не возрастает. Только CPU time на шифрование, которое на компьютерах выпущенных в этом веке заметить очень сложно, особенно с учётом aesni и друзей.
http://www.psc.edu/index.php/hpn-ssh
http://daniel.haxx.se/blog/2010/12/08/making-sftp-transfers-.../
а почему вы не делаете это через git как все нормальные люди? :)
Наверное потому, что git это всего лишь одна из многих систем контроля версий, а не протокол передачи файлов по сети. При этом решения на базе git умеют взаимодействовать с различными протоколами передачи, например с ssh, что вводит недалеких людей в заблуждение и они искренне считают, что передают файлы на сервер при помощи git.
> Наверное потому, что git это всего лишь одна из многих систем контроля
> версий, а не протокол передачи файлов по сети.
$ grep ^git /etc/services
git 9418/tcp # git pack transfer service
git 9418/udp # git pack transfer service
Так и представляю: корпоративная сетка, офис предприятия, планктон и Git :))
> планктон и Git :))На гитхаб давно заглядывал? А то я видел как корпоративный манагер чертыхался, скрипел, но осваивал южеж git. Потому что партнеры выложили файло именно туда и иззъявили желание версионировать все через git. Бывает и вот так...
> Не поверишь, но много кто использует. Ибо проще всего объяснить планктону как
> что-то туда закачать/скачать оттуда. К тому же альтернативы не всегда хорошо
> работают. Я, например, файлы на php shared хостинг закачиваю обычно через
> ssh. Это заметно медленнее, чем по ftp. Но мне лень каждый
> месяц менять пароль, поэтому я просто использую ключ для ssh, который
> не нужно менять.scp, sftp ?
> scp, sftp ?УебДАВ?
>> scp, sftp ?
> УебДАВ?Очень на любителя.
> Не поверишь, но много кто использует. Ибо проще всего объяснить планктону как
> что-то туда закачать/скачать оттуда. К тому же альтернативы не всегда хорошо
> работают. Я, например, файлы на php shared хостинг закачиваю обычно через
> ssh. Это заметно медленнее, чем по ftp. Но мне лень каждый
> месяц менять пароль, поэтому я просто использую ключ для ssh, который
> не нужно менять.Попробуйте отключить шифрование контента при передаче по scp. Ваш КО.
При всей моей нелюбви к этому протоколу мне не приходит в голову замена в пределах его ниши. Другое дело, что он зачастую применяется там, где есть более удачные решения.
> Интресно, где сейчас массово востребован FTP?
> На всякий случай - кроме shared hosting-ов с PHP.сабж и sftp поддерживает, что очень удобно
Вы случаем не путаете sftp с ftps?
> Вы случаем не путаете sftp с ftps?Нет.
>> Вы случаем не путаете sftp с ftps?
> Нет.да.
> Вы случаем не путаете sftp с ftps?случаем не путаю
LoadModule mod_sftp.c
LoadModule mod_sftp_pam.cSFTPEngine on
SFTPLog /var/log/proftpd/sftp.log
TransferLog /var/log/proftpd/xferlog-sftp.logPort 2121
SFTPHostKey /etc/ssh/ssh_host_rsa_key
SFTPHostKey /etc/ssh/ssh_host_dsa_key
SFTPAuthorizedUserKeys file:~/.sftp/authorized_keys
SFTPCompression delayed
MaxLoginAttempts 3
> Вы случаем не путаете sftp с ftps?http://ru.wikipedia.org/wiki/SFTP - дополнение к SSH
http://ru.wikipedia.org/wiki/FTPS - дополнение к FTP
> Интресно, где сейчас массово востребован FTP?
> На всякий случай - кроме shared hosting-ов с PHP.в моем случае ftp - единственное что полностью утилизирует гигабитный канал. ни sftp, ни nfs, ни cifs даже половины скорости ftp не выдают.
в моем случае (внутри локалки) - основное достоинство, что поддерживается "искаропки" во всех используемых системах и не требует ничего ставить/настраивать. особенно актуально за пределами своего подразделения - уж "у себя"-то ЕСТЬ множество способов как обменяться файлами, в зависимости от назначения обмена, но для разового обмена временными и/или не очень служебными файлами используем тот же ftp. Да и через корпоративные политики и прибамбасы пролезает нормально.
> в моем случае (внутри локалки) - основное достоинство, что поддерживается "искаропки" во
> всех используемых системах и не требует ничего ставить/настраивать. особенно актуально
> за пределами своего подразделения - уж "у себя"-то ЕСТЬ множество способов
> как обменяться файлами, в зависимости от назначения обмена, но для разового
> обмена временными и/или не очень служебными файлами используем тот же ftp.
> Да и через корпоративные политики и прибамбасы пролезает нормально.прочитал. возрыдал. жуть какая. хорошо, что я так не живу.
> в моем случае (внутри локалки) - основное достоинство, что поддерживается "искаропки" во
> всех используемых системах и не требует ничего ставить/настраивать. особенно актуально
> за пределами своего подразделения - уж "у себя"-то ЕСТЬ множество способов
> как обменяться файлами, в зависимости от назначения обмена, но для разового
> обмена временными и/или не очень служебными файлами используем тот же ftp.
> Да и через корпоративные политики и прибамбасы пролезает нормально.Дропбоксы и прочие гугл-драйвы удобнее же.
> Дропбоксы и прочие гугл-драйвы удобнее же.Да, конечно, упал канал в интернет - работа энтерпрайза полностью встала. За такие советы вам яйца однажды оторвут. И боссы и сотрудники.
А у меня есть проблема: NFS больше 650MB/s (около 6Gb/s) не понимается....
>> Интресно, где сейчас массово востребован FTP?
>> На всякий случай - кроме shared hosting-ов с PHP.
> в моем случае ftp - единственное что полностью утилизирует гигабитный канал. ни
> sftp, ни nfs, ни cifs даже половины скорости ftp не выдают.Слишком толсто
> ни nfs, ни cifs даже половины скорости ftp не выдают.Опять же странно, хотя и мнение "нет ничего быстрей двух tar через rsh" помню...
для localhost'a весьма удобен pure-ftpd
мы макеты в типографию сливаем по фтп
PORT/EPRT
When handling PORT and EPRT FTP commands from clients, proftpd now
checks for RFC 1918 addresses in those commands; these are non-publicly
routable IP addresses, and should NOT be being sent by clients. When
proftpd detects these RFC1918 addresses being used for a WAN server
address, then proftpd will ignore the RFC1918 address, and instead
use the IP address of the connecting client. This change should help
interoperability of data transfers for some FTP clients.А разработчики ProFTPD не догадываются, что их сервер может использоваться в интранет сетях ? Администраторы внутренней сети РЖД от такого изменения будут счастливы ;-)
Администраторам региональной СПД Газпрома фиолетово. Они не используют этот комбайн.
А что будет не так? Сервер возьмёт тот адрес, с которого соединение вместо указанного в команде (если у сервера внешний IP), но эти два адреса должны бы совпадать.Хотя в совсем сложной ситуации всё сломается, она требует не только внутренних адресов, но и хитрого роутинга.
Никогда не мог понять, чем отличается сабж от, например, vsftpd?
Дырками?
В первую очередь дырявостью.
> В первую очередь дырявостью.за фичи приходится платить
Незнаю как сейчас, но раньше у ProFTPD можно было хитро настраивать права доступа. Я его использую.
> Никогда не мог понять, чем отличается сабж от, например, vsftpd?Вообще то всем отличается. Общего только протокол который они реализуют.
> Никогда не мог понять, чем отличается сабж от, например, vsftpd?Тем что умеет все, даже кофе в постель приносить. Правда, в комплекте с венерическими заболеваниями. Достаточно посмотреть на ченжлог, чтобы понять что это огромный энтерпрайзный мегамонстр. Чего для сетевого софта чревато кучами дыреней.
Мне больше нравится Pure-FTPd, только он давно уже не обновлялся, но проект хороший Pure-FTPd. Что же касается ProFTPD то он скоро будет напоминать новогоднюю елку, а за фичи платить безопасностью можно разве что в локальной сети, но не в Интрнете.
proftpd не елка, просто он модульный
Встроенный в дистр OpenBSD вполне подходит для рядовых задач. Без лишнего рукоблудия.
> Встроенный в дистр OpenBSD вполне подходит для рядовых задач. Без лишнего рукоблудия.Правда, сам openbsd хрен запустишь на новом оборудовании, а если запустишь - обнаружишь что он там работает галимо. Например, многопроцессорные машины оно нормально использовать не умеет, а однопроцессорных серверов нынче просто не бывает уже.
Где можно почитать как более правильно обновить proftpd 1.2 на новый 1.3.5?
Все это на CentOS 6.5.