Mengapa menjalankan nama (bind) di chroot sangat penting untuk keamanan? Atau mungkin bukan?


12

Saya bermain dengan bind dan mulai bertanya-tanya mengapa perangkat lunak ini, misalnya, dalam CentOS berjalan dalam chroot. Jangan salah paham, saya tahu untuk apa ikatan itu dan untuk apa chroot (penjara). Tapi pertanyaan utama saya adalah apakah mengikat berjalan tanpa chroot sangat tidak aman?

Apakah benar-benar berbahaya untuk mengaturnya tanpa penjara (lebih dari layanan atau perangkat lunak lain). Dalam sistem ada banyak proses berjalan tanpa chroot dan saya pikir kompromi dari mereka sangat berbahaya tetapi apa yang membuat nama lebih berbahaya daripada perangkat lunak lain berjalan tanpa chroot?


1
Untuk menambah pertanyaan: Bagaimana ini dipengaruhi oleh penggunaan mesin virtual modern? Untuk penyebaran berukuran sedang, semakin cenderung untuk mendedikasikan VM untuk setiap tugas, sehingga tidak ada data / aplikasi lain di dalamnya. Apakah masih ada manfaat nyata dalam chroot?
gregmac

3
Chroot bukan penjara. Penjara adalah sesuatu yang spesifik pada BSD. Jika Anda menginginkan yang setara, Anda harus melihat LXC
Zoredache

Jawaban:


14

Seperti @Some Guy sebutkan Anda harus memikirkan hal ini dalam perspektif sejarah.

Perspektif historis adalah bahwa satu perangkat keras adalah selusin atau lebih layanan yang berbeda di bawah sistem operasi tunggal. Jika satu layanan dikompromikan maka segala sesuatu pada perangkat keras itu dikompromikan.

Dengan virtualisasi ini jauh dari masalah. Meskipun bukan tidak mungkin untuk melarikan diri dari VM itu jauh dari sepele. Tentunya lebih sulit untuk keluar dari VM daripada proses yang berjalan dengan hak root untuk keluar dari chroot. Jadi server bind saya berjalan di VM mereka sendiri. Sebenarnya tidak ada banyak gunanya chroot dalam kasus itu karena kerusakan sudah dibatasi hanya oleh fakta bahwa itu adalah VM.

Chroot adalah upaya yang sangat lemah untuk menciptakan sesuatu seperti VM. Chroots dapat diloloskan dari proses apapun 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. Tetapi hari-hari ini dengan begitu mudah untuk memutar VM baru dari seluruh mesin itu mungkin tidak sepadan dengan usaha untuk setup, atau belajar bagaimana menggunakan alat virtualisasi tingkat OS untuk tujuan ini.

Versi bind sebelumnya tidak memberikan 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 kehilangan hak istimewa, kompromi apa pun akan berarti seluruh sistem dapat dikompromikan. Hampir semua perangkat lunak akhir-akhir ini akan mulai membuka soketnya dan melakukan hal-hal lain yang memerlukan hak akses root, kemudian mereka akan mengubah pengguna yang mereka jalankan sebagai akun yang tidak memiliki hak istimewa. Setelah privilege dihapus, dampak dikompromikan jauh lebih rendah dari sistem host.


10

Jawaban lain cukup bagus tetapi gagal menyebutkan konsep keamanan berlapis-lapis. 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 sebelum melakukan hal lain dalam sistem. Seperti yang disebutkan, hak root diperlukan untuk penghancuran chroot. BIND tidak berjalan sebagai root, dan seharusnya ada alat minimal yang tersedia di chroot, lebih lanjut membatasi opsi dan pada dasarnya hanya menyisakan panggilan sistem. Jika tidak ada panggilan sistem untuk meningkatkan hak istimewa maka musuh macet melihat catatan DNS Anda.

Situasi yang disebutkan di atas agak tidak mungkin karena SomeGuy menyebutkan, BIND memiliki sedikit kerentanan saat ini dan mereka sebagian besar terbatas pada skenario tipe DoS daripada eksekusi jarak jauh. Yang mengatakan, menjalankan chroot adalah konfigurasi default pada beberapa OS, jadi tidak mungkin mengambil upaya Anda untuk menjaga keamanan yang terus meningkat.


5

pembukaan

saya terus mendengar orang mengulangi kesalahpahaman dari seluruh internet .. dengan demikian, saya akan mencoba memberikan beberapa klarifikasi

pertama; berapa banyak kecelakaan penemuan telah ada sudah, yang hanya .. karena sebab dan akibat , akhirnya digunakan untuk sesuatu yang lain dari tujuan yang telah ditetapkan?

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 tempat tidur uji cepat, termasuk pembersihan yang mudah. tahun telah berlalu sejak itu, dan konsepnya serta penggunaan yang tersirat tentu saja telah berubah, juga.

chroot telah digunakan secara efektif , dan secara langsung di basis kode untuk beberapa program dan pustaka (yaitu openSSHd, apache2 + mod_security2 / mod_chroot, dovecot, sendmail, openVPN, pam_chroot, dan banyak lagi ). dengan asumsi bahwa semua aplikasi utama ini telah menerapkan solusi keamanan yang salah sama sekali tidak benar

chroot adalah solusi untuk virtualisasi sistem file: tidak kurang, tidak lebih. asumsi bahwa Anda dapat dengan mudah keluar dari chroot juga tidak benar ... selama Anda mematuhi pedoman proses yang berjalan di dalam chroot jail.

beberapa langkah untuk mengamankan chroot jail Anda

yaitu JANGAN menjalankan proses sebagai ROOT. ini bisa membuka vektor eskalasi root (yang juga benar 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 Chrootnya sendiri untuk membatasi permukaan serangan, dan memberikan privasi. hanya me-mount file, perpustakaan, dan perangkat yang diperlukan. terakhir, chroot BUKAN pengganti untuk keamanan sistem dasar. mengamankan sistem secara keseluruhan.

catatan penting lainnya: banyak orang berpikir bahwa OpenVZ adalah Rusak, atau itu tidak setara dengan virtualisasi sistem penuh. mereka membuat asumsi ini karena pada dasarnya Chroot, dengan tabel proses yang telah disterilkan. dengan langkah-langkah keamanan di perangkat dan perangkat keras. sebagian besar yang dapat Anda terapkan dalam chroot.

tidak setiap admin memiliki tingkat pengetahuan yang diperlukan untuk mengamankan semua parameter kernel yang diperlukan pada server khusus atau di bawah virtualisasi sistem penuh. ini berarti menggunakan OpenVZ berarti bahwa pelanggan Anda akan memiliki permukaan serangan yang jauh lebih sedikit untuk mencoba dan melindungi dan mengamankan sebelum menggunakan aplikasi mereka. tuan rumah yang baik akan melakukan pekerjaan dengan baik mengamankan parameter ini, dan pada gilirannya, ini lebih baik untuk tidak hanya semua orang di Node, atau di pusat data, tetapi untuk internet secara keseluruhan ...

sebagaimana dinyatakan, chroot menyediakan virtualisasi sistem file. Anda harus memastikan bahwa tidak ada executable setuid ', aplikasi tidak aman, perpustakaan, menggantung symlink tanpa pemilik, dll. jika penyerang dapat berkompromi mengikat, mereka akan perlu menjelajahi sistem file virtual untuk sesuatu yang 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 dalam sistem pangkalan.

jika ini terjadi, itu biasanya hasil dari pembaruan yang buruk, eksploitasi nol hari, atau kesalahan manusia idiomatik .

mengapa chroot masih digunakan, sebagai lawan dari virtualisasi sistem penuh

pertimbangkan skenario ini: Anda menjalankan Virtual Private Server, dengan node host menjalankan OpenVZ. Anda tidak bisa menjalankan apa pun yang berfungsi pada level kernel. ini juga berarti Anda tidak dapat menggunakan virtualisasi sistem operasi untuk memisahkan proses, dan memberikan keamanan tambahan. dengan demikian, Anda HARUS menggunakan chroot untuk tujuan ini.

Selain itu, chroot berkelanjutan pada sistem apa pun, terlepas dari sumber daya yang tersedia. sederhananya, itu memiliki overhead paling sedikit dari jenis virtualisasi. ini berarti masih penting pada banyak kotak kelas bawah.

pertimbangkan skenario lain: Anda memiliki apache berjalan di dalam lingkungan yang tervirtualisasi. 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 berlapis-lapis . Chroot berpotensi menjadi salah satunya. tidak semua orang dan setiap sistem memiliki kemewahan memiliki akses ke Kernel, oleh karena itu, chroot MASIH melayani tujuan. ada berbagai aplikasi di mana virtuaisation sistem penuh pada dasarnya berlebihan.

Menanggapi pertanyaan Anda

saya tidak terlalu menggunakan CentOS, tetapi saya tahu bahwa Bind sekarang menjatuhkan haknya sebelum operasi. saya akan berasumsi, bahwa ikatan diikat karena sejarah vektor serangan dan kerentanan potensial.

juga ... lebih masuk akal untuk secara otomatis chroot aplikasi ini, daripada tidak, karena tidak semua orang memiliki akses ke sistem penuh / virtualisasi tingkat sistem operasi. ini pada gilirannya, dan secara teori, membantu memberikan keamanan kepada basis pengguna CentOS:

Penyedia sistem operasi hanya tidak berkeliling dengan asumsi setiap orang menjalankan sistem yang sama. dengan cara ini, mereka dapat membantu memberikan lapisan keamanan tambahan pada ...

ada alasan mengapa begitu banyak aplikasi menggunakan ini , dan mengapa jelas OS Anda tidak secara default: karena ini digunakan sebagai fitur keamanan, dan itu TIDAK berfungsi. dengan persiapan yang hati-hati, seperti yang dinyatakan sebelumnya, itu adalah rintangan lain yang harus diatasi oleh penyerang potensial - sebagian besar waktu, membatasi kerusakan hanya pada penjara chroot.


Pengembang asli chroot point blank mengatakan dia tidak pernah bermaksud chroot untuk penggunaan keamanan. Adapun pengembang aplikasi utama menerapkan keamanan yang salah ... ARM, Intel, dan AMD semua baru-baru ini menemukan cacat keamanan pada perangkat keras mereka kembali ke era Pentium. SSLv2, SSLv3, TLSv1, dan TLS1.1 semuanya memiliki kelemahan keamanan kritis meskipun TLSv1.1 masih menjadi standar industri untuk OpenSSHd, Apache, Dovecot, OpenVPN ... hampir semua orang yang Anda sebutkan. Dan semuanya masih standar untuk menggunakan Kompresi SSL yang bahkan meruntuhkan standar TLSv1.2 dan TLSv1.3 terbaru.
Cliff Armstrong

Pengembang (yang paling sukses, setidaknya) pada akhirnya menyeimbangkan antara kenyamanan dan keamanan ... dan mereka sering lebih menyukai kenyamanan daripada keamanan. Aplikasi ini mendukung chroot untuk "keamanan" karena penggunanya menuntutnya. Pengguna mereka menuntutnya karena kesalahpahaman umum bahwa itu memberikan keamanan yang berarti. Tetapi, meskipun Anda tertarik dengan argumen massa / otoritas, ini terbukti tidak benar.
Cliff Armstrong

3

Ini sebagian karena alasan historis, ketika Bind versi lama memiliki kerentanan keamanan yang parah dan sering. Saya belum benar-benar mengikuti perkembangan tentang masalah ini, tetapi saya berani bertaruh bahwa ini jauh lebih baik sejak masa buruk.

Alasan lainnya, yang lebih praktis, hanya karena biasanya digunakan dalam peran yang dihadapi Internet, dan karenanya, terbuka untuk lebih banyak serangan, penyelidikan, dan kerusakan umum.

Oleh karena itu, seperti yang sering menjadi aturan praktis dalam masalah keamanan: lebih baik aman daripada menyesal, terutama karena upaya chroot itu relatif sedikit.


Anda benar, ini jauh lebih baik. Pada dasarnya, bind8 adalah mimpi buruk; bind9 bukan. Misalnya, jika Anda mencari NVD, saya tidak melihat bug eksekusi kode jarak jauh terdaftar, setidaknya sejak 2010 (sejauh pencarian berjalan): web.nvd.nist.gov/view/vuln/… ... banyak bug DoS, dan juga beberapa bug pengungkapan informasi (misalnya, pengungkapan zona internal).
derobert
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.