GNU/Linux >> Belajar Linux >  >> Linux

Manakah Cara Teraman Untuk Mendapatkan Hak Istimewa Root:Sudo, Su Atau Login?

Saya ingin memiliki akun root dengan aman bahkan jika pengguna saya yang tidak memiliki hak disusupi.

Di Ubuntu Anda hanya dapat menggunakan sudo untuk "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 barang ke PATH saya, mengatur keyloggers LD_PRELOAD dan X11 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 segi keamanan ini tampaknya lebih buruk.

Masuk pada konsol mode teks tampaknya menjadi yang paling aman. Sejak dimulai oleh init jika penyerang dapat mengontrol PATH atau LD_PRELOAD dia sudah root. Peristiwa 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] di 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 dapat saya lakukan untuk meningkatkan keamanan metode apa pun?

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
  • masuk sebagai root
  • ssh ke mesin lain
  • masuk sebagai root?

Jawaban yang Diterima:

Keamanan selalu tentang membuat trade-off. Sama seperti server pepatah yang aman, dicabut, di dasar lautan, root akan menjadi paling aman jika tidak ada cara untuk mengaksesnya sama sekali.

Serangan LD_PRELOAD dan PATH seperti yang Anda gambarkan mengasumsikan bahwa ada penyerang yang sudah memiliki akses ke akun Anda, atau setidaknya ke dotfiles Anda. Sudo sama sekali tidak melindungi dari hal itu — jika mereka memiliki kata sandi Anda, bagaimanapun juga, tidak perlu mencoba menipu Anda untuk nanti… mereka cukup menggunakan sudo sekarang .

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

Tapi, sudo-for-unrestricted-root tidak mengatasi masalah keamanan lain:pengelolaan kata sandi root. Di banyak organisasi, ini cenderung dibagikan 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 yang memiliki sandi merupakan tantangan — apalagi melacak siapa yang tahu yang mana.

Terkait:Apa yang akan saya dapatkan ketika sudo program perusak kernel?

Ingatlah bahwa sebagian besar “kejahatan dunia maya” berasal dari dalam. Dengan situasi kata sandi root yang dijelaskan, sulit untuk melacak siapa yang melakukan apa — sesuatu yang sudo dengan logging jarak jauh menangani dengan cukup baik.

Di sistem rumah Anda, saya pikir ini lebih merupakan masalah kenyamanan karena tidak harus mengingat dua kata sandi. Kemungkinan banyak orang hanya menyetelnya agar sama — atau lebih buruk lagi, menyetelnya menjadi sama pada awalnya dan kemudian membiarkannya tidak sinkron, membiarkan sandi root membusuk.

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

Tetapi masalahnya sekarang Anda telah berpindah dari manajemen kata sandi ke manajemen kunci, dan kunci ssh tidak terlalu dapat dikelola. Tidak ada cara untuk membatasi salinan, dan jika seseorang membuat salinan, mereka memiliki semua upaya yang mereka inginkan untuk memaksa frasa sandi. Anda dapat membuat kebijakan yang mengatakan bahwa kunci harus disimpan di perangkat yang dapat dilepas dan hanya dipasang saat diperlukan, tetapi tidak ada cara untuk menerapkannya — 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 gangguan bahkan lebih baik. Di dunia open source, ada WiKiD, YubiKey, atau LinOTP, dan tentu saja ada juga RSA SecurID kelas berat berpemilik. Jika Anda berada di organisasi menengah hingga besar, atau bahkan organisasi kecil yang sadar akan keamanan, saya sangat menyarankan untuk melihat salah satu pendekatan ini untuk akses administratif.

Namun, ini mungkin berlebihan untuk rumah, di mana Anda tidak benar-benar memiliki kerepotan manajemen — selama Anda mengikuti praktik keamanan yang masuk akal.


Linux
  1. Cara Mengatur Hak Istimewa Sudo untuk Pengguna di Linux

  2. Linux:Bagaimana Mendapatkan Semua Log Masuk Dari Sistem?

  3. Linux – Cara Portabel Untuk Mendapatkan Alamat Sumber Rute Default?

  1. Bagaimana Cara Mendapatkan Tty Di Bash Yang Sedang Berjalan?

  2. Apa cara teraman untuk mengosongkan direktori di * nix?

  3. Ekstrak nomor seri Linux tanpa sudo

  1. Bagaimana cara membuat sudo meminta kata sandi root?

  2. Dapatkan ukuran total hard drive saya di Linux, menggunakan baris perintah, tanpa izin root?

  3. Cara mendapatkan nomor tampilan yang ditugaskan oleh X