Akses root yang tidak dapat mengubah kata sandi root?


66

Kami mengalami sedikit masalah di server. Kami ingin beberapa pengguna dapat melakukan mis sudodan menjadi root, tetapi dengan batasan bahwa pengguna tidak dapat mengubah kata sandi root. Artinya, jaminan bahwa kami masih bisa masuk ke server itu dan menjadi root tidak peduli apa yang akan dilakukan pengguna lain.

Apakah itu mungkin?


32
Anda dapat menggunakan sudountuk memberikan izin hanya untuk aplikasi khusus root-privilege. Dengan cara itu, pengguna tidak akan diizinkan untuk mengubah kata sandi root
SHW

24
MENGAPA Anda butuhkan sudountuk para pengguna ini? Jika Anda tidak mempercayai mereka, jangan beri mereka sudoakses di tempat pertama. Juga catat bahwa idealnya, root seharusnya tidak memiliki kata sandi sama sekali , tetapi Anda harus menggunakan cara otentikasi lainnya. (Yang pengguna masih dapat "meretas", bahkan jika Anda mau protext /etc/passwd)
Anony-Mousse

3
Apa yang perlu dilakukan oleh para pengguna itu?
Olivier Dulac

4
Apa yang akan mereka lakukan dengan hak istimewa root mereka? Mungkin ada solusi yang lebih baik daripada apa yang Anda pikirkan.
sparticvs

23
Ini adalah salah satu dari mereka "Bisakah Tuhan membuat batu yang sangat besar sehingga dia sendiri tidak bisa mengangkatnya?" ketik pertanyaan. Jika Anda memiliki akses root, Anda dapat melakukan apa saja, itulah mengapa akses root paling baik diberikan secara bijaksana. sudodan setuiddapat memecahkan sebagian besar masalah.
bsd

Jawaban:


57

Kami ingin beberapa pengguna dapat melakukan mis sudodan menjadi root,

Nah, itulah masalahnya sudo dirancang untuk dipecahkan, sehingga bagian itu cukup mudah.

tetapi dengan batasan bahwa pengguna tidak dapat mengubah kata sandi root.

Anda dapat, seperti yang ditunjukkan SHW dalam komentar, mengonfigurasi sudo hanya mengizinkan tindakan tertentu untuk diambil sebagai root oleh pengguna tertentu. Artinya, Anda dapat mengizinkan user1 untuk melakukan sudo services apache2 restart, memungkinkan user2 untuk melakukan sudo reboottetapi tidak ada yang lain, sambil membiarkan administrator yang dipekerjakan sebagai sistem user3melakukan sudo -i. Ada howtos yang tersedia tentang cara mengatur sudo seperti itu, atau Anda dapat mencari (atau bertanya) di sini. Itu adalah masalah yang bisa dipecahkan.

Namun, pengguna yang telah diberikan kemampuan ke sudo -iatau sudoke dalam shell ( sudo bash, misalnya) dapat melakukan apa saja. Itu karena pada saat sudo meluncurkan shell, sudo sendiri sudah keluar dari gambar. Ini memberikan konteks keamanan pengguna yang berbeda (paling sering melakukan root), tetapi tidak memiliki suara dalam apa yang dilakukan aplikasi yang dieksekusi. Jika aplikasi itu pada gilirannya diluncurkan, passwd roottidak ada yang bisa dilakukan sudo. Perhatikan bahwa ini dapat dilakukan melalui aplikasi lain juga; sebagai contoh, banyak editor yang lebih maju menyediakan fasilitas untuk mengeksekusi perintah melalui shell, shell yang akan dieksekusi dengan uid efektif dari proses editor itu (yaitu, root).

Artinya, jaminan bahwa kami masih bisa masuk ke server itu dan menjadi root tidak peduli apa yang akan dilakukan pengguna lain.

Maaf; jika Anda benar-benar bermaksud "memastikan kami akan dapat masuk dan menggunakan sistem tidak peduli apa yang dilakukan seseorang dengan akses root", bahwa (untuk semua maksud dan tujuan) tidak dapat dilakukan. "Sudo rm / etc / passwd" atau "sudo chmod -x / bin / bash" yang cepat (atau apa pun yang menggunakan root shell) dan Anda cukup banyak disembunyikan. "Cukup banyak disembunyikan" yang berarti "Anda harus memulihkan dari cadangan dan berharap mereka tidak melakukan hal yang lebih buruk daripada selip jari". Anda dapat mengambil beberapa langkah untuk mengurangi risiko kecelakaan yang tidak disengaja yang mengarah ke sistem yang tidak dapat digunakan, tetapi Anda tidak dapat mencegah niat jahat dari menyebabkan masalah yang sangat serius hingga dan termasuk titik perlu membangun kembali sistem dari awal atau paling tidak dari yang diketahui. backup yang bagus.

Dengan memberikan akses root tanpa batas pada sistem ke pengguna, Anda percaya bahwa pengguna (termasuk perangkat lunak apa pun yang mereka pilih untuk mengeksekusi, bahkan sesuatu yang biasa-biasa saja seperti ls) untuk tidak memiliki niat jahat, dan untuk tidak mengacaukan secara tidak sengaja. Itulah sifat akses root.

Akses root terbatas melalui mis. Sudo sedikit lebih baik, tetapi Anda tetap harus berhati-hati untuk tidak membuka vektor serangan apa pun. Dan dengan akses root, ada banyak kemungkinan vektor serangan untuk serangan eskalasi hak istimewa.

Jika Anda tidak dapat mempercayai mereka dengan tingkat akses yang disyaratkan oleh root, Anda akan memerlukan konfigurasi sudo yang sangat ketat, atau untuk tidak memberikan pengguna akses root yang dipertanyakan sama sekali melalui segala cara, sudo atau lainnya.


3
Maaf jawaban saya mendapatkan semua hype (saya tidak mengerti!). Jawaban Anda meningkatkan poin bagus dan saya harap itu diterima. +1 untuk Anda, tuan.
Joseph R.

@ JosephephR. terkadang jawaban singkat lebih disukai.
David Cowden

@ Davidvidow Ya, sepertinya ini yang terjadi di sini ...
Joseph R.

1
@ JosephephR. Tidak ada kekhawatiran bagi saya. Komunitas Stack Exchange tidak selalu dapat diprediksi, dan pertanyaan yang sudah memiliki banyak peningkatan cenderung menarik lebih banyak. Terima kasih atas upvotenya. :)
CVn

92

Ini praktis tidak mungkin. Pertama-tama, jika Anda memberi mereka kekuatan untuk menjadi root , maka tidak ada yang dapat Anda lakukan untuk mencegah mereka melakukan apa pun. Dalam kasus penggunaan Anda, sudoharus digunakan untuk memberi pengguna Anda beberapa kekuatan root sambil membatasi orang lain tanpa membiarkan mereka menjadi root .

Dalam skenario Anda, Anda perlu membatasi akses ke sudan passwdperintah dan membuka akses ke hampir semua yang lain. Masalahnya adalah, tidak ada yang dapat Anda lakukan untuk mencegah pengguna Anda mengedit /etc/shadow(atau /etc/sudoersdalam hal ini) secara langsung dan memasukkan kata sandi pengganti root untuk membajak root. Dan ini hanya skenario "serangan" yang paling mudah. Sudoers dengan kekuatan tidak terbatas kecuali untuk satu atau dua perintah dapat mengatasi pembatasan untuk membajak akses root penuh.

Satu-satunya solusi, seperti yang disarankan oleh SHW dalam komentar adalah menggunakan sudountuk memberikan pengguna Anda akses ke serangkaian perintah sebagai gantinya.


Memperbarui

Mungkin ada cara untuk mencapai ini jika Anda menggunakan tiket Kerberos untuk otentikasi. Baca dokumen ini menjelaskan penggunaan .k5loginfile.

Saya mengutip bagian yang relevan:

Misalkan pengguna alice memiliki file .k5login di direktori rumahnya yang berisi baris berikut:
bob@FOOBAR.ORG
Ini akan memungkinkan bob untuk menggunakan aplikasi jaringan Kerberos, seperti ssh (1), untuk mengakses akun alice, menggunakan tiket Kerberos bob.
...
Perhatikan bahwa karena bob mempertahankan tiket Kerberos untuk kepala sekolahnya sendiri bob@FOOBAR.ORG, ia tidak akan memiliki hak istimewa yang memerlukan tiket alice, seperti akses root ke host situs mana pun, atau kemampuan untuk mengubah kata sandi alice.

Tapi saya mungkin salah. Saya masih mengarungi dokumentasi dan belum mencoba Kerberos sendiri.


Bagaimana Anda melakukan itu referensi keren untuk komentar? Saya melihat sumber untuk jawaban Anda dan melihat () di sekitarnya. Topi rahasia keren!
Joe

@Joe Waktu komentar diposting sebenarnya adalah tautan ke komentar itu sendiri.
Joseph R.

@Joe Temukan id ( <tr id="thisistheid"...) ke komentar (mis. Di Chrome klik kanan dan Inspect element), lalu tambahkan ke tautan utas dengan pendahulunya #. Dalam kasus Anda (id = comment-162798) terlihat seperti ini: unix.stackexchange.com/questions/105346/…
polym

1
Terima kasih atas jawabannya, saya tidak tahu apakah saya harus menerima ini atau itu dari @Michael Kjörling, saya memilihnya karena itu memiliki lebih banyak deskripsi - diperlukan oleh noob seperti saya :) Namun, milik Anda juga membantu
244an

@ 244an Jangan khawatir. Saya sendiri akan merekomendasikan hal yang sama. :)
Joseph R.

17

Saya berasumsi Anda ingin memastikan Anda memiliki akses "admin darurat", bahkan jika administrator Anda yang sebenarnya kacau (tetapi selain itu, Anda sepenuhnya mempercayai administrator utama).

Pendekatan yang populer (meskipun sangat peretasan) adalah memiliki pengguna kedua denganuid=0 , umumnya dinamai toor(root backwards). Ini memiliki kata sandi yang berbeda, dan dapat berfungsi sebagai akses cadangan. Untuk menambahkan, Anda mungkin perlu mengedit /etc/passwddan /etc/shadow(menyalin rootgaris).

Semuanya aman-gagal, tetapi jika Anda hanya perlu melindungi terhadap "administrator utama" mengubah kata sandi tanpa pemberitahuan, maka itu akan berhasil. Mudah untuk menonaktifkan, dengan menghapus toorakun; jadi satu-satunya manfaat adalah memiliki kata sandi terpisah.

Atau, Anda mungkin ingin melihat mekanisme otentikasi alternatif, yaitu sshkunci libnss-extrausers,, LDAP dll.

Perhatikan bahwa admin masih bisa mengacaukannya. Misalnya dengan memblokir firewall.

Jika Anda ingin memiliki sistem yang sangat aman, pertimbangkan untuk menggunakan SELinux, di mana pengguna unix (mis. Root) juga datang dengan sebuah peran, yang bisa lebih berbutir halus. Anda mungkin ingin memberikan akses root admin Anda, tetapi hanya peran yang dibatasi (mis. Untuk hanya mengelola apache). Tetapi ini akan membutuhkan banyak upaya di pihak Anda untuk mengonfigurasi kebijakan dengan benar.


6
Ini sebenarnya tidak mencegah pengguna toormengubah kata sandi root; itu hanya menyediakan kata sandi kedua untuk menjadi root.
alexis

2
-1, lalu. Anda menyarankan kata sandi backdoor agar admin dapat memulihkan akses root setelah kehilangan itu ??? Itu hanya salah arah, dan selain itu pengguna sial dapat dengan mudah menonaktifkannya, seperti yang Anda katakan. Ada banyak cara yang lebih dapat diandalkan untuk mengatur backdoor.
alexis

2
@alexis Itulah yang diminta oleh IMHO penulis pertanyaan . Mengapa memberi -1 untuk ini? toorakun pemulihan telah menjadi praktik umum (meskipun disukai) di Unix selama beberapa dekade.
Anony-Mousse

9
Jika satu-satunya tujuan adalah mencegah perubahan kata sandi yang tidak disengaja , ini adalah jawaban yang bagus. Jika tujuannya adalah untuk mencegah sesuatu yang berbahaya, ini tidak banyak membantu. Karena OP tidak mengatakan apa tujuannya, kami tidak tahu.
Bobson

2
Itulah sebabnya saya menyatakan bahwa dalam kalimat pertama saya: "mengacaukan ... selain itu, Anda percaya ... sepenuhnya". Ini benar-benar hanya solusi "dukungan akses"; bukan fitur keamanan. Menggunakan kunci ssh root tambahan mencapai hal yang sama, tanpa menjadi peretasan.
Anony-Mousse

11

Inti dari root adalah memiliki perintah sistem yang tidak dibatasi. Anda bisa mengubahnya dengan SELinux (dulu ada situs demo di mana siapa pun bisa login sebagai root, tetapi kekuatannya lumpuh melalui sistem akses), tapi bukan itu intinya. Intinya adalah ini adalah solusi yang salah untuk masalah Anda.

Sekarang, Anda belum mengatakan apa masalah Anda, tetapi jika Anda tidak mempercayai pengguna ini untuk tidak menggunakan kata sandi root, mereka tidak memiliki bisnis untuk di-root. Jika mereka perlu mengelola server web, atau berbagai perangkat perangkat keras, atau drive warp atau apa pun, siapkan solusi untuk itu. Buat grup berdaya super, berikan semua akses yang dibutuhkan, dan tambahkan ke dalamnya. Jika mereka perlu melakukan panggilan sistem hanya root, tulis beberapa program setuid.

Tentu saja pengguna dengan akses semacam itu (dan sedikit pengetahuan) mungkin dapat dengan mudah meretas sistem, tetapi setidaknya Anda bekerja dengan model keamanan OS, bukan menentangnya.

PS. Ada banyak cara untuk mengatur akses root untuk diri sendiri tanpa kata sandi; untuk satu, jika Anda berada di /etc/sudoers(tanpa batasan) Anda hanya perlu kata sandi Anda sendiri untuk menjadi root, misalnya dengan sudo bash. Tetapi Anda tidak perlu pergi ke sana.


Tapi masalahnya adalah Anda tidak bisa menghentikan penyerang untuk mendapatkan root melalui exploit, SELinux memberikan pertahanan secara mendalam.
Timothy Leung

11

Mungkin dimungkinkan, setidaknya secara teori, untuk melakukan ini menggunakan SELinux . Ini memungkinkan Anda untuk mengatur aturan yang jauh lebih tepat tentang apa yang pengguna atau proses boleh atau tidak boleh dilakukan. Bahkan dengan SELinux, mungkin sulit untuk membuatnya mustahil bagi pengguna untuk mengubah kata sandi root, tetapi masih dapat melakukan apa pun yang perlu mereka lakukan.

Benar-benar itu tergantung pada apa yang harus dilakukan oleh pengguna yang tidak diizinkan untuk mengubah kata sandi root. Mungkin akan lebih mudah dan lebih aman untuk hanya mencari tahu apa itu, dan memberikan izin tersebut secara khusus menggunakan sudo.


8
Sementara melakukan ini dengan SELinux secara teori mungkin (dan saya tidak yakin), mengklaim bahwa itu tanpa menunjukkan aturan yang sebenarnya tidak akan membantu siapa pun.
Gilles 'SANGAT berhenti menjadi jahat'

@ Gilles sebenarnya , ini adalah tujuan SELinux dirancang. SELinux adalah lapisan izin yang diperlukan selain izin POSIX standar. Pada mesin SELinux yang dikonfigurasi dengan benar, akses root tidak berarti karena izin Anda yang sebenarnya ditentukan oleh konteks keamanan dan pelabelan objek.
tylerl


Secara teoritis, itu mungkin masih bisa dilakukan dengan SELinux; namun, pengaturan sesuatu seperti itu harus lebih kompleks, untuk memastikan pemisahan yang kuat untuk SEMUA file konfigurasi terkait SELinux dari sistem file "normal" (dimana rootpengguna memiliki akses penuh). Pada akhirnya, metode "termudah" untuk pemisahan seperti itu (dengan atau tanpa SELinux) adalah menggunakan sesuatu seperti Kerberos, seperti yang disebutkan oleh Joseph R.
ILMostro_7

7

Mungkin Anda harus mempertimbangkan untuk membiarkan pengguna memiliki akses root ke mesin virtual atau wadah LXC. Itu akan memungkinkan mereka untuk memiliki akses root penuh ke suatu sistem, tanpa membiarkan mereka mencegah Anda masuk ke host atau mengambil tindakan administratif.


Ini akan lebih aman daripada banyak opsi IMHO.
Penatua Geek

5

Saya tidak tahu ini akan layak secara praktis tetapi ini adalah satu hack kotor:

  1. tulis skrip / program pembungkus yang akan menyalin /etc/passwdfile ke lokasi lain, sebelum menelepon yang sebenarnyasudo
  2. Izinkan pengguna normal untuk menggunakan sudo
  3. Begitu dia menyelesaikan tugasnya, atau ketika dia keluar dari sudo, kembalikan /etc/passwdfile tersebut

Saya tahu, ada banyak hal plus-minus yang harus Anda pertimbangkan untuk mencapai ini. Bagaimanapun, ini adalah hack yang kotor


3
Selalu ada kemungkinan bahwa pengguna jahat akan membaca skrip ini dan menghapus salinan cadangan.
Joseph R.

Ini juga sudah cukup apa yang vipwdilakukan teman-teman.
CVn

Pertimbangkan programnya, dan hanya memiliki akses root
SHW

1
rootdapat mengedit "lokasi lain" setelah sudo.
Anony-Mousse

5
Mengapa Anda memberikan GRANT akses root ke pengguna yang berpotensi jahat ??? Sebagai root, itu sepele untuk memasang pintu belakang yang tidak tergantung pada melalui sudo dan / atau pembungkus ...
alexis

5

Pernyataan yang sudohanya untuk memberikan root dan tidak ada perlindungan setelah itu jelas-jelas salah.

Anda gunakan visudountuk memodifikasi file sudoers. Berikut ini contoh baris:

redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command
  • redsandroadalah nama pengguna yang kami beri izin. Letakkan a %di depan untuk membuatnya berlaku untuk grup.
  • ALLadalah nama untuk aturan ini. Sudoers dapat melakukan lebih dari sekedar memberikan izin global. Di situlah menjadi rumit sekalipun.
  • = tidak perlu penjelasan
  • ALL:ALLdibaca sebagai (who_to_run_it_as: what_group_to_run_it_as). Dengan cara ini Anda dapat mengizinkan menjalankan perintah, tetapi hanya dalam konteks pengguna atau grup tertentu.
  • NOPASSWD: mengatakannya untuk mematikan prompt kata sandi.
  • /path/to/command memungkinkan Anda menentukan perintah spesifik path_to_commmand, another_command

Yang perlu diingat adalah bahwa sementara sudosebagian besar digunakan oleh pengguna rumahan untuk meningkatkan hak akses root, itu bisa dan digunakan untuk mengontrol akses ke perintah tertentu dengan cara yang jauh lebih terperinci.

Referensi

  • dari jawaban saya yang lain di sini

Jawaban ini menjelaskan cara mengatur sudo untuk akses root terbatas, tetapi akan jauh lebih baik jika jawabannya berkata begitu dan ke mana harus pergi.
CVn

@ MichaelKjörling selesai
RobotHumans

3
"Pernyataan bahwa sudo hanya untuk memberikan root dan tidak ada perlindungan setelah itu benar-benar salah." Katakanlah saya memberikan sudo viakses kepada pengguna karena saya ingin mereka dapat mengedit file konfigurasi sistem. Pengguna itu kemudian melakukan :!/bin/bashdi dalam sudo visesi. Bagaimana kemampuan sudo untuk membatasi perintah apa yang dapat dijalankan pengguna melalui sudo membantu melindungi sistem saya dalam keadaan itu? (Tidak ada yang mengatakan sudo tidak dapat dikonfigurasikan dengan lebih ketat daripada pendekatan semua atau tidak sama sekali sudo -i.)
CVn

6
Memahami keterbatasan suatu pendekatan mudah sama pentingnya dengan mengetahui bagaimana melakukan suatu tugas.
CVn

1
@ MichaelKjörling, saya pikir ini hanya sebuah contoh. Tetapi untuk menjadi jelas, cara yang tepat untuk memungkinkan pengguna mengedit file konfigurasi sistem adalah membiarkannya berjalan sudoedit. Anda dapat secara spesifik mengidentifikasi file mana yang harus mereka dapat sudoedit. Hal ini man sudoers.
Matthew Flaschen

3

(Saya tidak tahu ubuntu, tetapi harus mirip dengan Fedora / Red-Hat)
Satu-satunya hal yang dapat saya bayangkan membatasi akses untuk mengubah kata sandi root adalah tidak memberikan akses root penuh, mungkin dengan sudo, atau menggunakan SElinux untuk membatasi akses ke file kata sandi ... tapi saya tidak akan mempercayai dengan banyak akses karena root pada umumnya memiliki akses tidak terbatas dan dapat memperbarui SElinux, atau mengubah nama file kata sandi, atau menjalankan beberapa program yang sudah disiapkan sebelumnya untuk mengubah kata sandi.

Jika Anda tidak cukup mempercayai mereka untuk tidak mengubah kata sandi, Anda mungkin seharusnya tidak memberi mereka akses root. Kalau tidak, saya kira Anda mencoba menghindari kecelakaan.

Jika Anda hanya mencoba melindungi akses Anda untuk melakukan root, aturlah sebuah program yang dapat mengembalikan kata sandi root, jadi meskipun itu diubah, program tersebut dapat dipulihkan dengan akses minimal. (Sudo melakukannya dengan baik pada miliknya sendiri)


3

Kebutuhan Anda adalah:

Kami mengalami sedikit masalah pada server [...] yaitu, jaminan bahwa kami masih dapat masuk ke server itu dan menjadi root tidak peduli apa yang akan dilakukan pengguna lain.

Dari pertanyaan Anda, seolah-olah Anda tidak menghadapi pengguna jahat acak yang bermaksud menghancurkan sistem Anda, tetapi sebaliknya memiliki pengguna semi tepercaya yang dapat menyebabkan kerusakan sekarang dan kemudian (siswa mungkin?). Saran saya mengatasi situasi itu, bukan serangan habis-habisan oleh pengguna jahat.

  1. Jalankan server di dalam lingkungan virtual. Anda dapat memasang sistem file server dan mengganti file yang diubah dengan versi yang dikenal baik. Bergantung pada kemungkinan kerusakan yang Anda antisipasi, Anda dapat mengambil snapshot dari semua direktori penting (/ bin, / sbin, / etc, / usr, / var, dll.) Dan memperluas snapshot untuk menimpa file yang rusak sambil meninggalkan sisa dari sistem utuh.

  2. Jalankan sistem hanya-baca, mis. Dari DVD-R. Jika Anda dapat hidup dengan sebagian besar sistem menjadi statis hingga reboot berikutnya, ini adalah opsi yang baik. Anda juga bisa menggunakan backing store read-only dengan lingkungan virtual atau memuat sistem basis melalui jaringan, membuat perubahan antar reboot jauh lebih mudah daripada menulis DVD-R baru.

  3. Modul kernel. Linux Security Modules (LSM) dari kernel menyediakan dasar untuk membuat modul yang aman. LSM digunakan oleh SELinux, tetapi juga digunakan oleh sejumlah sistem yang kurang dikenal dan lebih sederhana, seperti Smack, TOMOYO, dan AppArmor. Artikel ini memiliki ikhtisar opsi yang bagus. Peluangnya adalah salah satu yang dapat dikonfigurasikan out-of-the-box untuk mencegah akses tulis ke / etc / passwd, / etc / shadow, atau file lain yang Anda inginkan, bahkan oleh root.

  4. Ide yang sama dengan # 1, tetapi ketika server tidak berada dalam lingkungan virtual. Anda bisa memasukkan server-load ke dalam sistem read-only seperti live CD, yang secara otomatis akan me-mount sistem file server dan menimpa sistem basis pada setiap boot dengan salinan yang dikenal baik. OS read-only kemudian akan boot ke OS utama.

  5. Sekali lagi, dengan asumsi ini adalah pengguna semi tepercaya yang bertanggung jawab kepada atasan (guru / bos), jawaban terbaik mungkin adalah Audit Linux . Dengan cara ini Anda akan mengetahui setiap tindakan yang relevan dengan keamanan yang diambil dan siapa yang mengambilnya (Anda akan tahu siapa yang mengambilnya karena meskipun semua pengguna berbagi akun root, mereka akan sudo'ed dari akun pengguna mereka terlebih dahulu). Bahkan Anda mungkin dapat mengurai log audit secara realtime dan mengganti file yang rusak. / etc / shadow ditimpa? Tidak masalah, hanya meminta server pemantauan langsung menggantinya dengan versi yang dikenal baik.

Teknologi lain yang mungkin ingin Anda selidiki berdasarkan kebutuhan Anda:


2

Untuk melengkapi jawaban yang lain, saya akan berasumsi bahwa skenarionya adalah Anda merasa kehilangan kontrol root situasi yang langka, dan bahwa dalam kasus-kasus tersebut reboot server diperbolehkan. (Lagi pula, jika Anda yakin mesin itu telah dikompromikan, Anda tetap ingin membuatnya offline.)

Keuntungan besar dari ini adalah tidak ada yang perlu dikonfigurasi. Pertanyaan Anda menjadi: " Saya lupa kata sandi root, bagaimana saya kembali? " Dan jawabannya adalah me-reboot, dan memilih mode single-user ketika mesin muncul. Itu memberi Anda shell root tanpa perlu tahu kata sandi. Pada saat itu Anda dapat mengatur kata sandi baru. (Serta pergi dan memperbaiki kerusakan ...)


2
Tidak. Seperti yang dicatat oleh Michael dengan tepat , pengguna jahat dapat mencegah akses root tanpa harus membajak kata sandi hanya dengan mengacaukan binari. Bahkan init=...pendekatan tersebut dapat dicegah dengan menghapus izin eksekusi dari binari terkait. Saya pikir solusi yang lebih baik dalam hal ini, adalah me-mount sistem file root Anda melalui LiveCD dan (mencoba) memperbaiki kerusakan. Kemudian lagi, jika Anda yakin sistem telah dikompromikan, Anda lebih baik mengembalikan dari cadangan.
Joseph R.

@JosephR yang Disetujui; menemukan dan memperbaiki kerusakan itu rumit, dan saya baru saja menginstal ulang juga. Tapi saya kira kekhawatiran OP adalah tentang seseorang yang secara tidak sengaja mengunci mereka ... dengan sengaja meretas situasi kerja atau sekolah agak bunuh diri. ;-)
Darren Cook

1
Belum tentu. Seorang pengguna yang benar-benar jahat dikombinasikan dengan sysadmin ceroboh / tidak mengerti dapat meningkatkan hak istimewa tidak terdeteksi. Saya setuju bahwa maksud asli OP mungkin untuk menangkal kesalahan yang tidak bersalah daripada untuk menjaga terhadap niat jahat, tetapi pertanyaan itu ditandai "keamanan" dan kami hanya menjalankannya, saya kira :)
Joseph R.

2

Jika Anda mengkloning server Anda menjadi VM (seperti VirtualBox ), Anda dapat memberikan akses root tanpa batas kepada orang-orang dan masih menjamin bahwa Anda akan selalu memiliki akses langsung ke partisi sistem operasi tamu, dan oleh karena itu mempertahankan kontrol akhir atas /etc/passwddan sejenisnya, karena Anda akan memiliki root pada sistem host.

Tentu saja, memberikan akses root tanpa batas mungkin masih bukan solusi yang tepat: jika keamanan data merupakan masalah atau tanggung jawab Anda, Anda tidak dapat memberikan akses root.


2

Persyaratan ini tidak memungkinkan secara teknis. Seperti telah dikomentari dengan fasih, memberikan hak tanpa batas atau bahkan lebih terbatas sudokepada pengguna berarti Anda mempercayai pengguna itu. Seseorang yang memiliki niat jahat dan kemampuan teknis serta ketekunan yang cukup dapat melewati segala rintangan yang ada.

Namun, dengan asumsi Anda dapat memercayai pengguna Anda untuk tidak berkeinginan jahat, Anda dapat membuat pembatasan pada kata sandi mengubah masalah kebijakan . Anda dapat membuat pembungkus untuk passwdprogram yang akan mengingatkan mereka "tolong jangan ubah kata sandi root". Ini mengasumsikan sumber masalahnya adalah bahwa pengguna yang mengubah kata sandi root melakukannya karena kesalahpahaman (seperti mungkin berpikir mereka mengubah kata sandi mereka sendiri setelah selesai sudo bash).

Dalam keadaan khusus (jarang), jika lengkap kepercayaan tidak mungkin dan tidak mungkin untuk memecahkan sudoakses ke potongan cukup tapi cukup aman, Anda mungkin mempertimbangkan membangun sanksi organisasi terhadap perubahan password (atau bentuk tertentu lainnya dari sistem sabotase), mengatur pemantauan sumber daya kritis sehingga tidak mudah untuk tidak terdeteksi untuk menyiasati kebijakan yang ditetapkan - dan menjadi publik dan transparan tentang aturan penggunaan dan pemantauan.

Aspek pemantauan dan penemuan adalah masalah teknis yang sulit yang didapat dari pertanyaan lain jika Anda memilih untuk menempuh jalan itu. Sepertinya saya perlu melakukannya

  1. mendeteksi ketika pengguna mengubah identitas untuk melakukan root dan melacak setiap proses yang dibuat;
  2. log kreasi proses sejak saat itu untuk melihat siapa pengguna asli yang bertanggung jawab untuk setiap proses, dan menggunakan host jarak jauh di mana pengguna setengah tepercaya tidak memiliki akses untuk mengirim log;
  3. menggunakan semacam pelacakan sistem untuk mencatat apa yang terjadi dan kemudian dapat menemukan siapa yang berada di balik pelanggaran kebijakan.

Setidaknya kita perlu mencatat pembukaan file selain dari set file yang aman untuk menulis, membuat proses exec(), dan tentu saja setiap upaya untuk mengubah jaringan.

Implementasi dapat dilakukan dengan libc yang dimodifikasi atau penelusuran panggilan sistem (jauh lebih baik).

Tentu saja, tidak mungkin untuk membuat penelusuran dan penebangan seperti itu bekerja 100% dengan benar, tidak mudah untuk diimplementasikan, dan juga membutuhkan sumber daya tambahan untuk beroperasi. Ini tidak akan menghentikan perubahan kata sandi atau gangguan sistem yang tidak disukai lainnya, tetapi akan memungkinkan (lebih mungkin) untuk menemukan pengguna yang bersalah atau setidaknya menciptakan ilusi bahwa ada pemantauan dan membuatnya kurang mengundang bagi beberapa pengguna yang berpikiran jahat (tetapi beberapa peretas pencinta masalah yang melihat kesia-siaan mendasar dari langkah-langkah teknis yang diberlakukan mungkin merasa terdorong untuk menerima tantangan dan mencoba menghindari sistem hanya untuk bersenang-senang).


1

Pertanyaan yang dirumuskan semula tidak berguna. Sepertinya tujuan utama adalah "masih memiliki login" sehingga berbicara tentang beberapa masuk darurat yang tetap berfungsi bahkan dengan akses root yang diberikan kepada orang lain. Ceria untuk Anony-Mousse yang pertama kali mencatatnya secara eksplisit.

Masalahnya adalah: Jika pemilik memiliki akses fisik ke kotak, ia dapat dengan mudah memulihkan akses logis ke sistem (asalkan masih hidup :). Jika tidak - menjaga kata sandi root tidak akan menyelamatkan dari mis. Sshd down atau pengaturan jaringan yang buruk, maka sistem tetap tidak dapat diakses.

Topik tentang bagaimana mencegah sistem dari kerusakan oleh seseorang dengan hak administratif tampaknya terlalu luas untuk disesuaikan dengan format pertanyaan SE.

Berbicara tentang solusi masuk darurat jarak jauh, cara terbaik adalah IPMI (saya pikir) jika tersedia. Pemilik sistem dapat meng-atache virtual drive kapan saja, boot darinya dan diproses dengan pemulihan sistem.

Jika IPMI tidak tersedia, teknologi virtualisasi yang sesuai dapat digunakan, seperti yang telah diusulkan di atas.


0

Anda dapat membatasi akses ke sudo dalam /etc/sudoersfile Anda

Untuk sepenuhnya menjelaskan sintaks dari / etc / sudoers, kami akan menggunakan aturan sampel dan memecah setiap kolom:

jorge  ALL=(root) /usr/bin/find, /bin/rm

Kolom pertama menentukan pengguna atau grup yang menerapkan aturan sudo ini. Dalam hal ini, itu adalah jorge pengguna. Jika kata dalam kolom ini didahului dengan simbol%, kata ini menunjuk nilai ini sebagai grup alih-alih pengguna, karena sistem dapat memiliki pengguna dan grup dengan nama yang sama.

Nilai kedua (ALL) mendefinisikan host apa yang diterapkan aturan sudo ini. Kolom ini paling berguna ketika Anda menggunakan lingkungan sudo di beberapa sistem. Untuk sistem Ubuntu desktop, atau sistem di mana Anda tidak berencana untuk menyebarkan peran sudo ke beberapa sistem, Anda dapat merasa bebas untuk membiarkan nilai ini disetel ke ALL, yang merupakan wildcard yang cocok dengan semua host.

Nilai ketiga diatur dalam tanda kurung dan mendefinisikan apa pengguna atau pengguna pengguna di kolom pertama dapat mengeksekusi perintah sebagai. Nilai ini disetel ke root, yang berarti jorge akan diizinkan untuk mengeksekusi perintah yang ditentukan di kolom terakhir sebagai pengguna root. Nilai ini juga dapat diatur ke wildcard ALL, yang akan memungkinkan jorge untuk menjalankan perintah sebagai pengguna di sistem.

Nilai terakhir (/ usr / bin / find, / bin / rm) adalah daftar perintah yang dipisahkan koma, pengguna di kolom pertama dapat dijalankan sebagai pengguna di kolom ketiga. Dalam hal ini, kami mengizinkan jorge untuk menjalankan find dan rm sebagai root. Nilai ini juga dapat diatur ke wildcard ALL, yang akan memungkinkan jorge untuk menjalankan semua perintah pada sistem sebagai root.

Dengan mengingat hal ini, Anda dapat mengizinkan perintah X dengan cara yang dibatasi koma dan selama Anda tidak menambahkannya passwd, Anda harus baik-baik saja.


-1

Tidak ada 1/2 root :) Setelah Anda memberikan privilege root, mereka dapat melakukan apa pun yang mereka inginkan. Atau Anda dapat menggunakan sudo untuk menjalankan bash shell terbatas atau menjalankan rbash tanpa hak akses root.

Jika Anda ingin memiliki mekanisme yang gagal untuk login ke server sebagai root, Anda dapat membuat pengguna lain dengan uid=0atau membuat cron sederhana yang akan mengatur ulang kata sandi root secara berkala.


Sangat mudah untuk melarikan diri dari bash terbatas, lihat blog Sans
Franklin Piat

-1

Coba tambahkan grup roda daripada menggunakan sudo. sudo memungkinkan pengguna untuk mengeksekusi seolah-olah mereka root yang artinya tidak ada bedanya dengan menjalankan:

su -

menjadi root. Root uid = 0; roda uid = 10. Orang-orang menggunakan nama tetapi OS menggunakan uid. Perintah tertentu tidak dapat dijalankan oleh anggota grup wheel. (Jika Anda menggunakan roda jangan salah menambahkan root sebagai anggota grup roda). Lihatlah dokumentasi Red Hat jika Anda tidak tahu apa itu roda.

Pilihan lain adalah menggunakan kunci ssh daripada kata sandi. Dengan asumsi Anda dapat yakin orang-orang yang menggunakan sudo tidak menambahkan kunci publik mereka ke file ~ / .ssh / yang diotorisasi ini dapat mengatasi masalah perubahan kata sandi root karena kata sandi root secara efektif diabaikan.

Jika Anda lebih memilih untuk memperluas kepercayaan kepada pengguna ini (untuk tidak menambahkan kunci publik mereka sendiri) coba gunakan atribut file yang diperluas dan menggunakan bit Immutable. Setelah membuat file ~ / .ssh / yang diotorisasi, dan setelah mengkonfigurasi / etc / ssh / sshd_config dan / etc / ssh / ssh_config sesuka Anda, setel bit Immutable. Tentu, ada cara untuk mengacaukannya juga - tidak ada yang sempurna.

Dalam sistem apa pun, orang dalam adalah risiko tertinggi. Orang yang menjalankan pertunjukan berada di bagian atas tumpukan. Pikiran terkait berkaitan dengan kontrak. Pengacara akan memberi tahu Anda, "Jangan pernah berbisnis dengan seseorang yang Anda perlukan kontrak untuk berbisnis dengan". Akal sehat memberi tahu kita, "Jangan pernah melakukan bisnis tanpa kontrak". Ketika Anda menemukan seseorang yang cukup Anda percayai untuk berbisnis, tulis kontrak berdasarkan kebutuhan masing-masing.

Semua jawaban yang diajukan, termasuk jawaban saya, gagal mengatasi akses fisik. Siapa pun yang memilikinya, memiliki kendali. Jika bukan Anda maka kemungkinan ada cara bagi Anda untuk mendapatkan orang yang melakukannya untuk mengakses mesin secara fisik jika seseorang menemukan cara untuk mencegah Anda masuk, atau jika mereka menemukan cara untuk masuk bahkan setelah Anda Sudah berusaha untuk mencegah hal itu terjadi. Tentu saja, jika Anda memiliki akses fisik daripada mungkin tidak ada kebutuhan untuk hal-hal ini meskipun menerapkan pasangan harus tetap dipertimbangkan, jika Anda tertarik untuk TIDAK merasa tidak nyaman.

-John Crout


sudoadalah sangat berbeda dari su -. Ini telah ditunjukkan berulang kali, misalnya oleh SHW , Joseph R. , saya sendiri , hbdgaf dan sangat mungkin beberapa bidang komentar terlalu pendek untuk dimasukkan ...
CVn

Semua benar, tetapi tidak relevan. Anda sedang mendiskusikan cara alternatif untuk menjadi root, dan risiko pemberian akses root, tetapi tidak ada yang memiliki kaitan dengan "akses root yang tidak dapat mengubah kata sandi root".
Gilles 'SANGAT berhenti menjadi jahat'

Benar. Pertanyaannya adalah oxymoron logis; Itu tidak bisa ada kecuali instalasi rusak. Apa gunanya login / akun pengguna di mana pengguna itu tidak dapat mengubah kata sandi mereka, namun mereka memiliki akses root? Oleh karena itu saran yang ditawarkan berlaku untuk apa yang dimaksud si penanya; tidak dengan cara mereka menulis pertanyaan. Setiap metode kontrol akses memiliki risiko yang melekat.
John Crout

-3

Salah satu caranya adalah memastikan hal /etcitu tidak dapat ditulis. Oleh siapa pun, selama mungkin ada sudoersekitar.

Itu bisa dilakukan dengan memasangnya di jaringan dan memastikan di sisi lain bahwa perangkat tidak dapat ditulis.

Itu bisa dilakukan dengan menggunakan perangkat lokal yang mencegah akses tulis ke sana. (Cari write blockerperangkat keras)

Bagian yang penting adalah bahwa pembatasan harus diterapkan di luar konsep root dari mesin itu. Seorang peretas yang kreatif akan menemukan jalannya di sekitar semua hambatan yang Anda tempatkan di lingkungan yang bisa ia kendalikan. Jadi jika root dapat mengubah kata sandi, maka dapat juga a sudoer.

Untuk memastikan bahwa pengguna juga tidak dapat mengacaukan kemampuan login Anda, Anda harus sudah menginstal read-only /bindan /sbin.

Dan Anda harus memiliki skrip yang secara berkala mengembalikan koneksi jaringan.

(Sebagai sidenote: Jika Anda mengizinkan sudoer hanya seperangkat perintah yang sangat terbatas dan untuk masing-masingnya memastikan bahwa mereka tidak dapat keluar darinya / menggantinya, dll., Maka Anda dapat mencegahnya saat memiliki tulisan /etc..)


Mount / etc read-only, sementara mungkin dimungkinkan (Anda harus berhati-hati selama pivot-root dalam skrip boot initrd, misalnya), berisiko mengambil setup yang agak rapuh. Juga, ada banyak hal yang dapat dilakukan pengguna dengan akses root yang melumpuhkan kemampuan pengguna lain untuk mendapatkan hak akses root yang tidak melibatkan modifikasi di / etc.
CVn

@ MichaelKjörling Pengaturannya tidak rapuh, saya sering menggunakannya (hanya untuk mount lokal read-only).
Angelo Fuchs

@ MichaelKjörling Saya menambahkan beberapa elemen lain yang ingin Anda baca-saja jika Anda ingin memastikan Anda masih bisa masuk. Jadi, daftar tindakan yang harus dilakukan jika Anda menyusuri jalan itu tidak terlalu pendek, tetapi itulah satu-satunya cara "adalah, jaminan bahwa kami masih dapat masuk ke server itu dan menjadi root tidak peduli apa yang akan dilakukan pengguna lain."
Angelo Fuchs

Saya akui saya belum pernah melihat perlunya mencobanya, tetapi satu hal yang pasti bisa saya lihat yang akan berisiko adalah bagaimana init akan menangani /etc/inetab diganti di bawah kakinya. Atau apa yang akan dilakukan sistem jika inisial dan after-remounting / etc / fstab berbeda. Dan ada / etc / mtab. Pengguna lain mungkin ingin mengubah kata sandi mereka sendiri, yang melibatkan penulisan ke / etc / shadow dan mungkin / etc / passwd. Dan mount / etc read-only masih hanya solusi parsial. Saya tidak mengatakan itu tidak bisa menjadi bagian dari solusi, tapi itu jelas bukan langkah pertama yang saya ambil dalam situasi OP.
CVn

1
Iya. Melakukan ini berbahaya dan memiliki masalah parah jika dilakukan dengan salah. Sejauh yang saya bisa lihat, ini satu-satunya cara untuk menyelesaikan permintaan OP untuk pengguna yang seharusnya diizinkan untuk menjadi root.
Angelo Fuchs
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.