Solusi 1:
Seperti yang disebutkan oleh @Some Guy, Anda harus memikirkan hal ini dalam perspektif sejarah.
Perspektif historisnya adalah bahwa satu perangkat keras adalah selusin layanan yang berbeda di bawah satu sistem operasi. Jika satu layanan disusupi, maka semua yang ada di perangkat keras itu disusupi.
Dengan virtualisasi, ini jauh dari masalah. Meskipun bukan tidak mungkin untuk keluar dari VM, ini jauh dari sepele. Tentu saja lebih sulit untuk keluar dari VM daripada proses yang berjalan dengan hak akses root untuk keluar dari chroot. Jadi server bind saya berjalan di VM mereka sendiri. Sebenarnya tidak ada gunanya chroot dalam kasus itu karena kerusakan sudah dibatasi hanya oleh fakta bahwa itu adalah VM.
Chroot adalah upaya yang sangat lemah untuk membuat sesuatu seperti VM. Chroot dapat diloloskan dari proses apa pun dengan hak akses root. Chroot tidak dimaksudkan dan tidak berfungsi sebagai mekanisme keamanan. Chroot dengan jail BSD, atau LXC memberi Anda virtualisasi level OS dan menyediakan fitur keamanan. Namun saat ini, dengan begitu mudahnya menjalankan VM baru dari seluruh mesin, mungkin tidak ada gunanya menyiapkannya, atau mempelajari cara menggunakan alat virtualisasi level OS untuk tujuan ini.
Versi sebelumnya dari bind tidak menghilangkan hak istimewa. Di Unix, hanya akun root yang dapat membuka port di bawah 1024, dan Bind seperti yang kita semua tahu perlu mendengarkan di udp/53, dan tcp/53. Karena Bind dimulai sebagai root, dan tidak menghilangkan hak istimewa, kompromi apa pun berarti seluruh sistem dapat dikompromikan. Hampir semua perangkat lunak hari ini akan mulai membuka soketnya dan melakukan hal lain yang memerlukan hak istimewa root, lalu mereka akan mengubah pengguna yang mereka jalankan menjadi akun yang tidak memiliki hak istimewa. Setelah hak istimewa dicabut, dampak disusupi jauh lebih rendah ke sistem host.
Solusi 2:
Jawaban lainnya cukup bagus tetapi gagal menyebutkan konsep keamanan berlapis. Setiap lapisan keamanan yang Anda tambahkan ke sistem Anda adalah lapisan lain yang harus diatasi oleh musuh. Menempatkan BIND di chroot menambah satu kendala lagi.
Katakanlah ada kerentanan yang dapat dieksploitasi di BIND dan seseorang dapat mengeksekusi kode arbitrer. Jika mereka berada di chroot, mereka harus keluar dari itu sebelum masuk ke hal lain di sistem. Seperti yang disebutkan, hak akses root diperlukan untuk pemecahan chroot. BIND tidak berjalan sebagai root, dan seharusnya ada alat minimal yang tersedia di chroot, opsi pembatasan lebih lanjut dan pada dasarnya hanya menyisakan panggilan sistem. Jika tidak ada panggilan sistem untuk meningkatkan hak istimewa maka musuh terjebak melihat catatan DNS Anda.
Situasi yang disebutkan di atas agak tidak mungkin seperti yang disebutkan SomeGuy, BIND memiliki sedikit kerentanan akhir-akhir ini dan sebagian besar terbatas pada skenario jenis DoS daripada eksekusi jarak jauh. Yang mengatakan, berjalan di chroot adalah konfigurasi default pada beberapa OS, jadi tidak mungkin Anda melakukan upaya apa pun untuk menjaga keamanan yang sedikit meningkat.
Solusi 3:
pembukaan
saya terus mendengar orang mengulangi kesalahpahaman dari seluruh internet.. jadi, saya akan mencoba memberikan beberapa klarifikasi
pertama; berapa banyak penemuan yang tidak disengaja, yang hanya .. karena sebab dan akibat , akhirnya digunakan untuk sesuatu lainnya dari tujuan yang dimaksudkan?
apa itu, dan apa itu, penjara Chroot
Chroot awalnya dirancang untuk mengubah direktori root untuk proses atau pengguna (bagus untuk mengkompilasi perangkat lunak dari sumber yang tidak dikenal). ini memberikan keamanan ke sistem dasar, serta alat uji cepat, termasuk pembersihan yang mudah. bertahun-tahun telah berlalu sejak itu, dan konsep serta penggunaan tersiratnya juga telah berubah.
chroot telah digunakan secara efektif , dan langsung di basis kode untuk beberapa program dan pustaka (yaitu openSSHd, apache2 + mod_security2/mod_chroot, dovecot, sendmail, openVPN, pam_chroot, dan masih banyak lagi ). berasumsi bahwa semua aplikasi utama ini telah mengimplementasikan solusi keamanan yang salah adalah tidak benar
chroot adalah solusi untuk virtualisasi sistem file:tidak kurang, tidak lebih. anggapan bahwa Anda dapat dengan mudah keluar dari chroot juga tidak benar... selama Anda mematuhi panduan menjalankan proses di dalam chroot jail.
beberapa langkah untuk mengamankan chroot jail Anda
yaitu melakukan TIDAK menjalankan proses sebagai ROOT. ini bisa membuka vektor eskalasi root (yang juga berlaku di dalam atau di luar chroot). jangan menjalankan proses di dalam chroot, menggunakan pengguna yang sama dengan proses lain di luar chroot. pisahkan setiap proses dan pengguna ke dalam Chroot-nya sendiri untuk membatasi permukaan serangan, dan memberikan privasi. hanya pasang file, perpustakaan, dan perangkat yang diperlukan. terakhir, chroot BUKAN pengganti keamanan sistem dasar. mengamankan sistem secara keseluruhan.
catatan penting lainnya: banyak orang berpikir bahwa OpenVZ Rusak, atau tidak sama dibandingkan dengan virtualisasi sistem penuh. mereka membuat asumsi ini karena pada dasarnya ini adalah Chroot, dengan tabel proses yang telah disterilkan. dengan langkah-langkah keamanan yang diterapkan pada perangkat keras dan perangkat. paling yang dapat Anda terapkan di chroot.
tidak setiap admin memiliki tingkat pengetahuan yang diperlukan untuk mengamankan semua parameter kernel yang diperlukan di server khusus atau di bawah virtualisasi sistem penuh. ini berarti bahwa menerapkan OpenVZ berarti bahwa pelanggan Anda akan memiliki permukaan serangan yang jauh lebih sedikit untuk dicoba dan dilindungi serta diamankan sebelum menerapkan aplikasi mereka. tuan rumah yang baik akan melakukan pekerjaan yang baik mengamankan parameter ini, dan pada gilirannya, ini lebih baik tidak hanya untuk semua orang di Node, atau di pusat data, tetapi untuk internet secara keseluruhan...
seperti yang dinyatakan, chroot menyediakan virtualisasi sistem file. Anda harus memastikan bahwa tidak ada setuid executable, aplikasi tidak aman, perpustakaan, symlink tanpa pemilik yang menggantung, dll. jika penyerang BISA mengkompromikan ikatan, mereka perlu menjelajahi sistem file virtual untuk mencari buffer overrun, bermain dengan deskriptor file, atau dengan cara lain mengkompromikan sesuatu yang berada di dalam chroot- melarikan diri dari penjara biasanya melalui eskalasi hak istimewa atau menyuntikkan muatannya ke sistem dasar.
jika ini terjadi, biasanya akibat dari pembaruan yang buruk, eksploitasi nol hari, atau kesalahan manusia idiomatis .
mengapa chroot masih digunakan, bukan virtualisasi sistem penuh
pertimbangkan skenario ini:Anda menjalankan Virtual Private Server, dengan node host menjalankan OpenVZ. Anda hanya tidak bisa jalankan apa pun yang berfungsi pada level kernel. ini juga berarti Anda tidak dapat menggunakan virtualisasi sistem operasi untuk memisahkan proses, dan memberikan keamanan tambahan. jadi, Anda HARUS gunakan chroot untuk tujuan ini.
apalagi, chroot berkelanjutan pada sistem apa pun, terlepas dari sumber daya yang tersedia. sederhananya, ia memiliki overhead paling sedikit dari semua jenis virtualisasi. ini berarti masih penting pada banyak kotak kelas bawah.
pertimbangkan skenario lain:Anda menjalankan apache di dalam lingkungan virtual. Anda ingin memisahkan setiap pengguna. menyediakan sistem file tervirtualisasi melalui chroot add on ke apache (mod_chroot, mod_security, dll) akan menjadi pilihan terbaik untuk memastikan privasi maksimal antara pengguna akhir. ini juga membantu mencegah pengumpulan intel, dan menawarkan lapisan keamanan lainnya.
sederhananya, penting untuk menerapkan keamanan di lapisan . Chroot berpotensi menjadi salah satunya. tidak semua orang dan setiap sistem memiliki kemewahan untuk memiliki akses ke Kernel, oleh karena itu, chroot STILL melayani suatu tujuan. ada berbagai aplikasi di mana virtuaisasi sistem penuh pada dasarnya berlebihan.
Menanggapi pertanyaan Anda
saya tidak terlalu menggunakan CentOS, tetapi saya tahu bahwa Bind sekarang melepaskan hak istimewanya sebelum operasi. saya akan berasumsi, bagaimanapun, bahwa bind di-chroot karena riwayat vektor serangan dan potensi kerentanannya.
juga... lebih masuk akal untuk melakukan chroot secara otomatis pada aplikasi ini, daripada tidak, karena tidak SEMUA ORANG memiliki akses ke virtualisasi tingkat sistem/sistem operasi secara penuh. ini pada gilirannya, dan secara teori, membantu menyediakan keamanan bagi basis pengguna CentOS:
penyedia sistem operasi tidak asal-asalan dengan asumsi setiap orang menjalankan sistem yang sama. dengan cara ini, mereka dapat membantu memberikan lapisan keamanan tambahan secara luas...
ada alasan mengapa begitu banyak aplikasi yang menggunakan ini , dan mengapa jelas OS Anda melakukannya secara default:karena IS digunakan sebagai fitur keamanan, dan TIDAK berfungsi. dengan persiapan yang cermat, seperti yang dinyatakan sebelumnya, ini adalah rintangan lain yang harus diatasi oleh penyerang potensial- sebagian besar waktu, membatasi kerusakan yang dilakukan hanya pada chroot jail.
Solusi 4:
Ini sebagian karena alasan historis, ketika versi Bind yang lebih lama memiliki kerentanan keamanan yang parah dan sering terjadi. Saya belum benar-benar mengikuti perkembangan terbaru tentang masalah ini, tetapi saya berani bertaruh bahwa ini jauh lebih baik sejak masa lalu yang buruk.
Alasan lainnya, yang lebih praktis, hanya karena biasanya digunakan dalam peran yang menghadap ke Internet, dan karena itu, terbuka untuk lebih banyak serangan, penyelidikan, dan kerusakan umum.
Oleh karena itu, seperti aturan umum dalam masalah keamanan:lebih baik aman daripada menyesal, terutama karena upaya chroot relatif kecil.