[Comm] Question on FTP

Fr. Br. George =?iso-8859-1?q?george_=CE=C1_altlinux=2Eru?=
Вт Сен 12 17:49:02 MSD 2006


On Tue, Sep 12, 2006 at 11:50:22AM +0400, Headlong John wrote:
> Ну то есть вы хотите сказать, что об FTP теперь можно вообще забыть и всегда использовать только SMB? Вы хотите сказать, что все владельцы FTP-сайтов и веб-хостингов в интернете не очень хорошо разбираются в средствах доступа к файлам по сети?
Да. Вы хотите об этом поговорить?

> Если бы мне нравился SMB или я хотел его использовать, я бы поставил MS Windows, а не открытую ОС.
Не говорите глупостей. SMB придумали не в MS, этот протокол не является
их собственностью, и если где-то существует реализация _стандарта_ (то
есть открытой спецификации) на SMB, то уж никак не в Weendooze. Просто
если обсуждать сетевые файловые системы (а говоря о правах доступа к
файлам, мы говорим о файловых системах) и делать выбор между NFS и SMB в
_гетерогенных_ сетях, NFS резко проигрывает бедностью реализаций на
не-POSIX системах. И остаётся SMB.

> > И если вас будут удовлетворять гуляющие по вашей сети в открытом
> > виде ftp-пароли.
> 
> Для решения этой проблемы есть SSL, если безопасность критична.
FTP-соединение, в силу специфики протокола, нельзя организовать
поверх SSL. Требуется модифицировать протокол, что, конечно,
поддерживается далеко не всеми. Обычно используется TLS, это проще. Есть
несколько клиентов под linux, поддерживающих FTP/TLS. Наверное, есть они
и для windows, сам не видел ничего, кроме lftp/CYGWIN или wget/CYGWIN (если
пересобрать их с OpenSSL). Тут встаёт большая проблема принудительного
внедрения и обязательной перенасстройки именно этого ПО на клиентских
машинах. Потому что без внедрения и настройки у вас будет сразу две
радости: и пароли будут утекать, и пользователи не смогут зайти по FTP
:)).

> А насколько "защищен" SMB?
SMB вообще не гоняет по сети пароли, только невосстановимые хеши,
которые при желании можно защитить SSL, хотя, кажется, незачем.
Правда, он хранит эти пароли в расшифровываемом виде на сервере. Так что
вопрос в том, насколько "защищён" сам сервер. Про NFS молчу: там
IP-based авторизация.

> Спасибо, эта часть проблемы уже решена, я писал об этом. Я использую /etc/fstab для монтирования, никаких самоделок.
Самоделки понадобятся для модифицирования fstab при множественном
добавлении пользоватлей и включения их в разнообразные группы..

> Теперь такой вопрос - как в /etc/vsftpd.conf указать, куда chroot'ить
> пользователей? Поскольку мне надо контролировать доступ к файлам на
> уровне пользователей, то от виртуальных пользователей vsftpd я
> отказался, буду использовать реальных. Но вот загвоздка: chroot'ятся
> они в свои домашние каталоги, а мне надо, чтобы при доступе через ftp
> они все chroot'ились в один и тот же каталог /home/ftpsite, который
> будет набит точками монтирования нужных мне для ftp-доступа фрагментов
> файловой системы. При этом надо, чтобы при обычном входе в систему
> (через ssh, например), пользователь попадал в свой обычный домашний
> каталог.
Отменить chroot по пользователям вообще, а chroot-ить сам демон?

> И еще - в чем скрытый смысл опции passwd_chroot_enable? Ведь при включенной chroot_local_user пользователи и так chroot'ятся в свои домашние каталоги, прописанные в /etc/passwd... Или я чего-то недопонял?
Темна вода в облацех. Проще всего попробовать и посмотреть, что
получится. Из невнятного текста man у меня создалось впечатление, что
chroot_local_user -- это как раз то, что вам нужно. Гм. С добавлением
Warning: This option has security implications, especially if the users
have upload permission, or shell access. Only enable if you know what
you are doing.

-- 
			Георгий Курячий (aka Fr. Br. George)
			Руководитель образовательных проектов ALT Linux
			mailto : george at altlinux_ru



Подробная информация о списке рассылки community