Mengapa chroot_local_user dari vsftpd tidak aman?


20

Saya menyiapkan vsftpd pada VPS saya, dan saya tidak ingin pengguna diizinkan meninggalkan direktori home ftp mereka. Saya menggunakan ftp local_user, bukan anonim, jadi saya menambahkan:

chroot_local_user = YA

Saya sudah membaca di banyak posting forum, bahwa ini tidak aman.

  1. Mengapa ini tidak aman?
  2. Jika ini tidak aman karena menggunakan ssh untuk bergabung dengan VPS saya juga, maka saya bisa mengunci pengguna ini dari sshd, kan?
  3. Apakah ada opsi lain untuk mencapai perilaku vsftpd ini? (Saya tidak ingin menghapus izin baca di semua folder / file untuk "dunia" di sistem saya)

Jawaban:


20

Periksa di sini untuk FAQ VSFTPD untuk jawaban yang Anda cari. Di bawah ini adalah kutipan penting yang saya pikir akan menjawab pertanyaan Anda.

Q) Tolong! Apa implikasi keamanan yang disebutkan dalam opsi "chroot_local_user"?

A) Pertama-tama perhatikan bahwa daemon ftp lain memiliki implikasi yang sama. Ini adalah masalah umum. Masalahnya tidak terlalu parah, tetapi inilah: Beberapa orang memiliki akun pengguna FTP yang tidak dipercaya memiliki akses shell penuh. Jika akun ini juga dapat mengunggah file, ada risiko kecil. Seorang pengguna yang buruk sekarang memiliki kendali atas root filesystem, yang merupakan direktori home mereka. Daemon ftp dapat menyebabkan beberapa file config dibaca - misalnya / etc / some_file. Dengan chroot (), file ini sekarang berada di bawah kendali pengguna. vsftpd berhati-hati dalam bidang ini. Tapi, libc sistem mungkin ingin membuka file konfigurasi lokal atau pengaturan lainnya ...


Terima kasih untuk itu, saya sendiri tidak tahu semua itu. Belajar sesuatu! +1
Yanick Girouard

4
Sebenarnya saya datang ke sini setelah membaca FAQ karena saya tidak mengerti pernyataan yang mengkhawatirkan ini: "Daemon ftp dapat menyebabkan beberapa file konfigurasi untuk dibaca - misalnya / etc / some_file. Dengan chroot (), file ini sekarang berada di bawah kendali pengguna. " Agaknya ini hanya akan terjadi jika vsftpdmemiliki cacat keamanan (Ă  la buffer overflow) ??? Bagaimana menjalankan vsftpddengan pengguna chroot ke dir home mereka membuat skenario ini lebih mungkin? Tolong jelaskan ...
sxc731

4

Masalahnya adalah Anda tidak bisa menggunakan akun lokal dan juga menonaktifkan akun tersebut dari login shell. Jika Anda mengatur shell login mereka ke / bin / nologin, itu tidak akan membiarkan Anda masuk dengan vsftpd.

Daemon FTP yang lebih baik dan lebih aman adalah Pure-ftpd. Lihat itu, tersedia dari repositori EPEL, dan memungkinkan untuk membuat pengguna virtual. Server menggunakan pengguna / grup umum untuk mengatur semua izin untuk folder beranda pengguna dan "memetakan" pengguna virtual ke pengguna tersebut saat masuk untuk menangani izin. Itu lebih aman, dan Anda tidak harus berurusan dengan keamanan login openssh.

Pure-ftpd juga mendukung banyak fitur seperti kuota, rasio, dan semacamnya. Jauh lebih baik daripada vsftpd.

Berikut ini adalah tutorial sederhana tentang cara menginstalnya dan mengonfigurasi pengguna virtual dasar: http://blog.namran.net/2011/05/04/how-to-setup-virtual-ftp-server-using-pure-ftpd- dalam centos /

Jika Anda membaca dokumen lengkap (yang seharusnya) Anda akan tahu bahwa -d beralih saat membuat pengguna virtual adalah auto-chroot ke direktori itu untuk pengguna tersebut.


Saya menggunakan AllowUsers user1 user2arahan di sshd_config saya, di mana saya tidak mengizinkan ftp_user1 untuk login dengan ssh, masih pengguna ftp_user1 dapat login dengan ftp. Jadi ini berfungsi sebagai niat, tapi pertanyaan utama saya tetap terbuka, mengapa tidak aman?
p1100i

4
Ya, tentu saja! Anda hanya perlu menambahkan "non-shell" ke / etc / shells. Pada banyak sistem, / bin / false atau / bin / nologin ada di / etc / shells. Jika ada shell, vsftpd akan membiarkan Anda masuk, juga dengan chroot_local_user diaktifkan.
Frands Hansen

1
Saya berdiri dikoreksi kemudian. Terima kasih telah menunjukkannya!
Yanick Girouard
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.