Чому chroot_local_user vsftpd небезпечний?


20

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

chroot_local_user = ТАК

Я багато читав у форумі, що це незахищено.

  1. Чому це незахищено?
  2. Якщо це незахищено через використання ssh для приєднання до моєї VPS, то я можу просто заблокувати цих користувачів із sshd, правда?
  3. Чи є інший варіант для досягнення такої поведінки vsftpd? (Я не хочу видаляти дозволи на читання з усіх папок / файлів для "world" у моїй системі)

Відповіді:


20

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

Q) Допомога! Про які наслідки для безпеки йдеться у варіанті "chroot_local_user"?

А) По-перше, зауважте, що інші ftp-демон мають такі самі наслідки. Це загальна проблема. Проблема не надто гостра, але це так: Деякі люди мають облікові записи користувачів FTP, яким не довіряють повний доступ до оболонки. Якщо ці акаунти також можуть завантажувати файли, існує невеликий ризик. Зараз поганий користувач має контроль над коренем файлової системи, який є їх домашнім каталогом. Демон ftp може спричинити зчитування деякого конфігураційного файла - наприклад / etc / some_file. З chroot () цей файл зараз знаходиться під контролем користувача. vsftpd є обережним у цій галузі. Але, libc системи може захотіти відкрити локальні файли конфігурацій або інші налаштування ...


Дякую за це, я сам цього не знав. Навчився чогось! +1
Янік Жируар

4
Насправді я прийшов сюди, прочитавши FAQ, тому що я не розумію цього занепокоєного твердження: "Демон FTP може спричинити зчитування якогось конфігураційного файла - наприклад / etc / some_file. З chroot () цей файл зараз знаходиться під контролем користувач. ". Імовірно, це було б лише в тому випадку, якщо vsftpdб був недолік безпеки (переповнення буфера à la) ??? Як біг vsftpdз користувачами, що перебувають під керівництвом додому, робить цей сценарій більш імовірним? Будь ласка, поясніть ...
sxc731

4

Проблема полягає в тому, що ви не можете користуватися локальними обліковими записами, а також відключити ці облікові записи із входу в оболонку. Якщо ви встановите їх оболонку для входу в / bin / nologin, вона також не дозволить вам увійти через vsftpd.

Кращим і безпечнішим демоном FTP буде Pure-ftpd. Подивіться, він доступний у сховищі EPEL, і він дозволяє створювати віртуальних користувачів. Сервер використовує загальний користувач / групу для встановлення всіх дозволів для домашніх папок користувачів і "карта" віртуальних користувачів цьому користувачеві, коли він входить для роботи з дозволами. Це більш безпечно, і вам не доведеться мати справу з безпекою входу в систему opensh.

Pure-ftpd також підтримує цілий ряд функцій, таких як квоти, коефіцієнти тощо. Набагато краще, ніж vsftpd.

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

Якщо ви прочитаєте повний документ (який вам слід), ви знатимете, що перемикач -d при створенні віртуального користувача є автоматичним хротографією до цього каталогу для цього користувача.


Я використовую AllowUsers user1 user2директиву в моєму sshd_config, де я не дозволяю ftp_user1 входити в систему з ssh, все ж користувач ftp_user1 може входити через ftp. Отже, це працює як задумано, але все ж моє головне питання відкрите, чому це незахищено?
p1100i

4
Так це буде! Вам просто потрібно додати "не оболонку" до / etc / shell. У багатьох системах / bin / false або / bin / nologin існує в / etc / shell. Якщо оболонка є, vsftpd дійсно дозволить вам увійти, також із включеним chroot_local_user.
Frands Hansen

1
Я стою виправлений тоді. Дякуємо, що вказали на це!
Янік Жируар
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.