Mana cara teraman untuk mendapatkan hak akses root: sudo, su atau login?

Saya ingin memiliki akun root dalam keamanan bahkan jika pengguna saya yang tidak berkompromi terganggu.

Di Ubuntu Anda hanya dapat menggunakan sudo karena "alasan keamanan" secara default. Namun saya tidak yakin itu lebih aman daripada hanya menggunakan login pada konsol mode teks. Ada terlalu banyak hal yang bisa salah jika penyerang dapat menjalankan kode sebagai pengguna normal saya. Misalnya menambahkan alias, menambahkan hal-hal ke PATH saya, mengatur LD_PRELOAD dan X11 keyloggers hanya untuk menyebutkan beberapa. Satu-satunya keuntungan yang bisa saya lihat adalah batas waktu jadi saya tidak pernah lupa untuk logout.

Saya memiliki keraguan yang sama tentang su tetapi bahkan tidak memiliki batas waktu. Beberapa operasi (terutama pengalihan IO) lebih nyaman dengan su tetapi dari sisi keamanan sepertinya ini lebih buruk.

Masuk pada konsol mode teks tampaknya paling aman. Karena ini dimulai oleh init jika penyerang dapat mengontrol PATH atau LD_PRELOAD, ia sudah di-root. Acara penekanan tombol tidak dapat dicegat oleh program yang berjalan di X. Saya tidak tahu apakah program yang berjalan di X dapat mencegat [ctrl] + [alt] + [f1] (dan membuka jendela layar penuh yang terlihat seperti konsol) atau aman seperti [ctrl] + [alt] + [del] pada Windows. Selain itu satu-satunya masalah yang saya lihat adalah kurangnya waktu tunggu.

Jadi, apakah saya melewatkan sesuatu? Mengapa orang-orang Ubuntu memutuskan untuk hanya mengizinkan sudo? Apa yang bisa saya lakukan untuk meningkatkan keamanan dari salah satu metode?

Bagaimana dengan SSH? Secara tradisional root tidak dapat masuk melalui SSH. Tetapi menggunakan logika di atas bukankah ini hal yang paling aman untuk dilakukan:

• izinkan root melalui SSH
• beralih ke mode teks
• login sebagai root
• ssh ke mesin lain
• login sebagai root?

Keamanan selalu tentang pengorbanan. Sama seperti server pepatah yang di yang aman, unplugged, di bagian bawah laut, rootakan paling aman jika tidak ada cara untuk mengaksesnya sama sekali.

Serangan LD_PRELOAD dan PATH seperti yang Anda jelaskan berasumsi bahwa sudah ada penyerang dengan akses ke akun Anda, atau setidaknya ke dotfiles Anda. Sudo sama sekali tidak melindungi terhadap hal itu dengan baik - jika mereka memiliki kata sandi Anda, tidak perlu mencoba menipu Anda untuk nanti ... mereka hanya dapat menggunakan sudo sekarang .

Penting untuk mempertimbangkan apa yang awalnya dirancang untuk Sudo: pendelegasian perintah khusus (seperti yang mengelola printer) ke "sub-administrator" (mungkin mahasiswa pascasarjana di lab) tanpa memberikan root sepenuhnya. Menggunakan sudo untuk melakukan semuanya adalah penggunaan yang paling umum yang saya lihat sekarang, tetapi itu belum tentu masalah yang ingin diselesaikan oleh program (karenanya sintaksis file konfigurasi ridiculously rumit).

Tapi, sudo-for-unrestricted-root memang mengatasi masalah keamanan lain: pengelolaan kata sandi root. Di banyak organisasi, ini cenderung diedarkan seperti permen, ditulis di papan tulis, dan dibiarkan sama selamanya. Itu meninggalkan kerentanan besar, karena mencabut atau mengubah akses menjadi jumlah produksi yang besar. Bahkan melacak mesin apa saja yang memiliki kata sandi merupakan tantangan - apalagi melacak siapa yang tahu .

Ingatlah bahwa sebagian besar "kejahatan dunia maya" berasal dari dalam. Dengan situasi password root yang dijelaskan, sulit untuk melacak siapa yang melakukan apa - sesuatu yang sudo dengan penawaran logging jarak jauh dengan cukup baik.

Pada sistem rumah Anda, saya pikir ini lebih merupakan masalah kenyamanan karena tidak harus mengingat dua kata sandi. Mungkin banyak orang hanya mengaturnya agar sama - atau lebih buruk, mengaturnya agar sama pada awalnya dan kemudian membiarkan mereka keluar dari sinkronisasi, membiarkan kata sandi root membusuk.

Menggunakan kata sandi sama sekali untuk SSH berbahaya, karena daemon trojaned ssh sniffing ssh ditempatkan pada sesuatu seperti 90% dari kompromi sistem dunia nyata yang pernah saya lihat. Jauh lebih baik menggunakan kunci SSH, dan ini bisa menjadi sistem yang bisa diterapkan untuk akses root jarak jauh juga.

Tapi masalahnya sekarang Anda sudah beralih dari manajemen kata sandi ke manajemen kunci, dan kunci ssh tidak terlalu mudah dikelola. Tidak ada cara untuk membatasi salinan, dan jika seseorang membuat salinan, mereka memiliki semua upaya yang mereka inginkan untuk secara paksa memaksa frasa sandi. Anda dapat membuat kebijakan dengan mengatakan bahwa kunci harus disimpan pada perangkat yang dapat dilepas dan hanya dipasang jika diperlukan, tetapi tidak ada cara untuk menegakkannya - dan sekarang Anda telah memperkenalkan kemungkinan perangkat yang dapat dilepas hilang atau dicuri.

Keamanan tertinggi akan datang melalui kunci satu kali atau token kriptografi berbasis waktu / counter. Ini dapat dilakukan dalam perangkat lunak, tetapi perangkat keras yang tahan terhadap kerusakan bahkan lebih baik. Di dunia open source, ada WiKiD , YubiKey , atau LinOTP , dan tentu saja ada juga RSA SecurID kelas berat . Jika Anda berada di organisasi menengah ke besar, atau bahkan organisasi kecil yang sadar akan keamanan, saya sangat merekomendasikan untuk melihat ke salah satu pendekatan ini untuk akses administratif.

Ini mungkin terlalu berat untuk rumah, di mana Anda tidak benar-benar memiliki kerepotan manajemen - selama Anda mengikuti praktik keamanan yang masuk akal.

Ini adalah pertanyaan yang sangat kompleks. mattdm telah membahas banyak hal .

Antara su dan sudo, ketika Anda mempertimbangkan satu pengguna, su sedikit lebih aman karena penyerang yang menemukan kata sandi Anda tidak dapat langsung mendapatkan hak akses root. Tetapi yang diperlukan hanyalah penyerang menemukan lubang root lokal (relatif tidak umum) atau menginstal trojan dan menunggu Anda menjalankan su.

Sudo memiliki kelebihan bahkan dibandingkan login konsol ketika ada banyak pengguna. Misalnya, jika suatu sistem dikonfigurasikan dengan log anti-perusakan jarak jauh, Anda selalu dapat mengetahui siapa yang terakhir menjalankan sudo (atau yang akunnya disusupi), tetapi Anda tidak tahu siapa yang mengetik kata sandi root pada konsol.

Saya menduga keputusan Ubuntu sebagian untuk kepentingan kesederhanaan (hanya satu kata sandi untuk diingat) dan sebagian untuk kepentingan keamanan dan kemudahan distribusi kredensial pada mesin bersama (bisnis atau keluarga).

Linux tidak memiliki kunci perhatian aman atau antarmuka pengguna aman lainnya untuk otentikasi. Sejauh yang saya tahu bahkan OpenBSD tidak memilikinya. Jika Anda khawatir tentang akses root, Anda bisa menonaktifkan akses root dari sistem yang sedang berjalan: jika Anda ingin menjadi root, Anda perlu mengetikkan sesuatu di prompt bootloader. Ini jelas tidak cocok untuk semua kasus penggunaan. (* Securelevel BSD bekerja seperti ini: pada securelevel tinggi, ada hal-hal yang tidak dapat Anda lakukan tanpa me-reboot, seperti menurunkan securelevel atau mengakses perangkat mentah yang terpasang secara langsung.)

Membatasi cara seseorang menjadi root tidak selalu merupakan keuntungan untuk keamanan. Ingatlah anggota ketiga dari triad keamanan : kerahasiaan , integritas , ketersediaan . Mengunci diri Anda dari sistem dapat mencegah Anda merespons insiden.

Para perancang distro OpenWall GNU / * / Linux yang diamankan juga telah menyatakan pendapat kritis tentang su(untuk menjadi root) dan sudo. Anda mungkin tertarik membaca utas ini:

... sayangnya baik su dan sudo secara halus tetapi pada dasarnya cacat.

Selain membahas kekurangan sudan hal-hal lain, Desainer Surya juga menargetkan satu alasan khusus untuk digunakan su:

Ya, dulu kebijaksanaan sysadmin umum untuk "su root" daripada login sebagai root. Beberapa orang yang, ketika ditanya, benar-benar dapat memberikan alasan yang valid untuk preferensi ini akan merujuk pada akuntabilitas yang lebih baik yang dicapai dengan pendekatan ini. Ya, ini benar-benar alasan yang bagus untuk pendekatan ini. Tapi itu juga satu-satunya. ...(Baca lebih lajut)

Di distro mereka, mereka telah "sepenuhnya menyingkirkan program root SUID di instalasi default" (yaitu, termasuk su; dan mereka tidak menggunakan kemampuan untuk ini):

Untuk server, saya pikir orang perlu mempertimbangkan kembali dan, dalam banyak kasus, melarang permintaan su dan sudo oleh pengguna. Tidak ada keamanan tambahan dari "login sebagai non-root, lalu su atau sudo untuk me-root" sysadmin "wisdom", dibandingkan dengan masuk sebagai non-root dan sebagai root secara langsung (dua sesi terpisah). Sebaliknya, pendekatan yang terakhir adalah satu-satunya yang benar, dari sudut pandang keamanan:

http://www.openwall.com/lists/owl-users/2004/10/20/6

(Untuk akuntabilitas beberapa sysadmin, sistem perlu mendukung memiliki beberapa akun root-privilege, seperti yang dilakukan Owl.)

(Untuk desktop dengan X, ini menjadi lebih sulit.)

Anda juga benar-benar harus berurusan dengan ...

BTW, mereka harus mengganti sulogindengan msuloginuntuk memungkinkan pengaturan dengan beberapa akun root: msuloginmemungkinkan seseorang untuk mengetikkan nama pengguna juga ketika masuk ke mode pengguna tunggal (dan mempertahankan "akuntabilitas") (info ini berasal dari diskusi ini dalam bahasa Rusia ) .

Anda tampaknya berasumsi bahwa menggunakan sudoselalu menjaga variabel lingkungan, tetapi ini tidak selalu terjadi. Berikut ini kutipan dari sudo manpage:

Ada dua cara berbeda untuk menangani variabel lingkungan. Secara default, opsi sudoers env_reset diaktifkan. Ini menyebabkan perintah dijalankan dengan lingkungan minimal yang berisi TERM, PATH, HOME, SHELL, LOGNAME, USER dan USERNAME sebagai tambahan terhadap variabel dari proses pemanggilan yang diizinkan oleh opsi sudo env_check dan env_keep. Ada secara efektif daftar putih untuk variabel lingkungan.

Namun, jika opsi env_reset dinonaktifkan di sudoers, variabel apa pun yang tidak secara eksplisit ditolak oleh opsi env_check dan env_delete diwarisi dari proses pemanggilan. Dalam hal ini, env_check dan env_delete berperilaku seperti daftar hitam. Karena tidak mungkin memasukkan semua variabel lingkungan yang berpotensi berbahaya ke daftar hitam, dianjurkan untuk menggunakan perilaku env_reset default.

Dalam semua kasus, variabel lingkungan dengan nilai yang dimulai dengan () dihapus karena mereka dapat diartikan sebagai fungsi bash. Daftar variabel lingkungan yang dibolehkan atau ditolak oleh sudo terkandung dalam output sudo -V saat dijalankan sebagai root.

Jadi jika env_resetdiaktifkan (default), seorang penyerang tidak dapat mengesampingkan PATHvariabel lingkungan Anda atau lainnya (kecuali Anda secara khusus menambahkannya ke daftar putih variabel yang harus dipertahankan).

Pendekatan paling aman adalah ssh login menggunakan (setidaknya) kunci panjang 2048 (dengan login password dinonaktifkan) menggunakan perangkat fisik untuk menyimpan kunci.

Saya hanya ingin menambahkan sesuatu yang sedikit keluar dari topik. (untuk topik, periksa '/ bin / su -' di sini setelah)

Saya pikir "keamanan" di atas juga harus dikaitkan dengan data aktual yang ingin kita amankan.

Akan dan harus berbeda jika kita ingin mengamankan: my_data, my_company_data, my_company_network.

Biasanya, jika saya berbicara tentang keamanan saya juga berbicara tentang "keamanan data" dan cadangan. Kami juga dapat menambahkan sistem toleran kesalahan dan sejenisnya.

Mengingat ini, saya pikir keamanan secara keseluruhan adalah keseimbangan antara kegunaan, "keamanan data" dan upaya yang diperlukan untuk menerapkan sistem yang aman.

Target Ubuntu adalah, dan sebagian besar masih, pengguna akhir: Sudo adalah default.

Fedora adalah versi gratis RedHat yang pada gilirannya lebih berorientasi pada server: Sudo dulu dinonaktifkan.

Untuk distribusi lain saya tidak punya informasi langsung.

Saya menggunakan sekarang, sebagian besar, fedora. Dan sebagai pengguna gaya lama saya tidak pernah mengetik 'su'. Tapi saya bisa mengetik "/ bin / su -" dalam waktu yang sangat singkat bahkan jika saya bukan pengetik. Variabel PATH .. seharusnya tidak menjadi masalah (saya ketik path). Juga "-" (minus) pada prinsipnya harus menghapus variabel lingkungan pengguna saya dan hanya memuat yang root. yaitu menghindari beberapa masalah tambahan yang mungkin terjadi. Mungkin juga LS_PRELOAD.

Selebihnya saya rasa @mattdm cukup tepat.

Tapi mari kita taruh di kotak yang benar. Asumsikan bahwa kit cerdas skrip mendapatkan akses ke data saya. Menurutmu apa yang akan dia lakukan dengan itu? - Publikasikan gambar saya? saya? - Mencoba mencari tahu nama pacar saya dan mengatakan kepadanya bahwa saya mengunjungi situs porno?

Dalam gambar pengguna tunggal dua situasi terburuk adalah: - Anak itu menghapus semua data saya: untuk bersenang-senang atau tidak sengaja - Anak itu menggunakan mesin saya untuk membuat serangan lebih lanjut ke beberapa entitas lain. Atau target serupa.

Untuk kasus pertama, saya sebutkan di atas, lebih baik melakukan upaya cadangan daripada keamanan jaringan. Yap, kamu selamat. Maksudku, kerusakan perangkat keras tidak jauh berbeda.

Kasus kedua lebih halus. Namun ada sinyal tentang kegiatan ini. Bagaimanapun, Anda dapat melakukan yang mungkin, tetapi saya tidak akan mengkonfigurasi PC rumah saya untuk dilindungi dari serangan teroris!

Saya akan melewatkan skenario lainnya.

tepuk tangan F

Jika masalahnya adalah bahwa akun pengguna yang dikompromikan dapat digunakan untuk mengendus kata sandi yang digunakan untuk sudoatau su, maka gunakan kode sandi satu kali untuk sudodan su.

Anda dapat memaksa penggunaan tombol untuk pengguna jarak jauh, tetapi itu mungkin tidak berlaku untuk tujuan kepatuhan. Mungkin lebih efektif untuk menyiapkan kotak gateway SSH yang memerlukan auth dua faktor, kemudian mengizinkan penggunaan kunci dari sana. Berikut ini dok pada pengaturan seperti itu: Amankan penyebaran SSH Anda dengan otentikasi dua faktor WiKID .

Anda juga dapat melihat privacyIDEA , yang tidak hanya memberi Anda kemungkinan untuk menggunakan OTP untuk login ke mesin (atau untuk melakukan su / sudo) tetapi juga dapat melakukan OTP offline.

Selain itu ia mampu mengelola kunci SSH Anda. Yaitu jika Anda memiliki banyak mesin dan beberapa pengguna root, semua kunci SSH disimpan secara terpusat. Dengan demikian mudah untuk "mencabut" / menghapus kunci SSH, jika kunci tersebut tidak dapat dipercaya lagi.

Tentu saja ada tugas dan alur kerja organisasi, untuk mengamankan sistem.