Почему chroot_local_user из vsftpd небезопасен?


20

Я настраиваю на своем VPS vsftpd, и я не хочу, чтобы пользователи могли оставлять свои домашние каталоги ftp. Я использую ftp local_user, а не анонимный, поэтому я добавил:

chroot_local_user = ДА

Я прочитал во многих сообщениях на форуме, что это небезопасно.

  1. Почему это небезопасно?
  2. Если это небезопасно из-за использования ssh для подключения к моему VPS, то я могу просто заблокировать этих пользователей из sshd, верно?
  3. Есть ли другой вариант для достижения такого поведения vsftpd? (Я не хочу удалять разрешения на чтение для всех папок / файлов для "world" в моей системе)

Ответы:


20

Здесь вы найдете ответы на часто задаваемые вопросы VSFTPD . Ниже приведен важный отрывок, который, я думаю, ответит на ваш вопрос.

Q) Помогите! Каковы последствия для безопасности, указанные в опции «chroot_local_user»?

A) Во-первых, обратите внимание, что другие демоны ftp имеют те же последствия. Это общая проблема. Проблема не слишком серьезна, но она такова: у некоторых людей есть учетные записи пользователей FTP, которым не доверяют полный доступ к оболочке. Если эти учетные записи также могут загружать файлы, существует небольшой риск. Плохой пользователь теперь имеет контроль над корнем файловой системы, который является их домашним каталогом. Демон ftp может привести к чтению файла конфигурации, например, / etc / some_file. С помощью chroot () этот файл теперь находится под контролем пользователя. vsftpd осторожен в этой области. Но системный libc может захотеть открыть файлы конфигурации локали или другие настройки ...


Спасибо за это, я сам все это не знал. Узнал что-то! +1
Яник Жируард

4
На самом деле я пришел сюда после прочтения FAQ, потому что я не понимаю этого тревожного утверждения: «Демон ftp может привести к чтению какого-либо файла конфигурации - например, / etc / some_file. С помощью chroot () этот файл теперь находится под контролем Пользователь.". Предположительно, это было бы только в том случае, если vsftpdбы был брешь в безопасности (а именно переполнение буфера) ??? Как запуск vsftpdс пользователями, привязанными к их домашнему каталогу, делает этот сценарий более вероятным? Пожалуйста, объясните ...
sxc731

4

Проблема в том, что вы не можете использовать как локальные учетные записи, так и отключить эти учетные записи от входа в оболочку. Если вы установите их оболочку входа в систему / bin / nologin, она также не позволит вам войти через vsftpd.

Лучшим и более безопасным FTP-демоном был бы Pure-ftpd. Посмотрите, он доступен в репозитории EPEL и позволяет создавать виртуальных пользователей. Сервер использует общего пользователя / группу для установки всех разрешений для домашних папок пользователей и «сопоставляет» виртуальных пользователей с этим пользователем при входе в систему для обработки разрешений. Это более безопасно, и вам не нужно иметь дело с безопасностью входа в систему openssh.

Pure-ftpd также поддерживает множество функций, таких как квоты, отношения и тому подобное. Гораздо лучше, чем vsftpd.

Вот простое руководство по установке и настройке обычного виртуального пользователя: http://blog.namran.net/2011/05/04/how-to-setup-virtual-ftp-server-using-pure-ftpd- в-CentOS /

Если вы прочтете полный документ (что вам следует), вы будете знать, что ключ -d при создании виртуального пользователя является авто-chroot в этот каталог для этого пользователя.


Я использую AllowUsers user1 user2директиву в моем sshd_config, где я не позволяю ftp_user1 войти в систему с помощью ssh, тем не менее, пользователь ftp_user1 может войти с помощью ftp. Так что это работает как задумано, но мой главный вопрос остается открытым, почему это небезопасно?
p1100i

4
Да, это будет! Вам просто нужно добавить «non-shell» в / etc / shells. Во многих системах / bin / false или / bin / nologin существует в / etc / shells. Если оболочка есть, vsftpd действительно позволит вам войти, также с включенным chroot_local_user.
Frands Hansen

1
Я стою исправлено тогда. Спасибо за указание на это!
Яник Жируард
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.