Beberapa sysadmin Linux berfungsi sebagai root

Di tim kami, kami memiliki tiga sysadmin Linux berpengalaman yang harus mengelola beberapa lusin server Debian. Sebelumnya kita semua bekerja sebagai root menggunakan otentikasi kunci publik SSH. Tapi kami berdiskusi tentang apa praktik terbaik untuk skenario itu dan tidak bisa menyetujui apa pun.

Kunci publik SSH semua orang dimasukkan ke dalam ~ root / .ssh / authorized_keys2

• Keuntungan: mudah digunakan, penerusan agen SSH bekerja dengan mudah, sedikit overhead
• Kerugian: audit hilang (Anda tidak pernah tahu "root" mana yang membuat perubahan), kecelakaan lebih mungkin terjadi

Menggunakan akun dan sudo yang dipersonalisasi

Dengan begitu kita akan login dengan akun yang dipersonalisasi menggunakan kunci publik SSH dan menggunakan sudo untuk melakukan tugas tunggal dengan izin root . Selain itu, kami dapat memberi diri kami grup "adm" yang memungkinkan kami melihat file log.

• Keuntungan: audit yang baik, sudo mencegah kita melakukan hal-hal bodoh terlalu mudah
• Kerugian: istirahat penerusan agen SSH, itu merepotkan karena hampir tidak ada yang bisa dilakukan sebagai non-root

Menggunakan beberapa pengguna UID 0

Ini adalah proposal yang sangat unik dari salah satu sysadmin. Dia menyarankan untuk membuat tiga pengguna di / etc / passwd semuanya memiliki UID 0 tetapi nama login yang berbeda. Dia mengklaim bahwa ini sebenarnya tidak dilarang dan memungkinkan semua orang menjadi UID 0 tetapi masih dapat diaudit.

• Keuntungan: pekerjaan penerusan agen SSH, audit mungkin berhasil (tidak teruji), tidak ada kesulitan sudo
• Kerugian: terasa sangat kotor - tidak dapat menemukannya didokumentasikan di mana pun sebagai cara yang diizinkan

Apa yang kamu sarankan?

Pilihan kedua adalah yang terbaik IMHO. Akun pribadi, akses sudo. Nonaktifkan akses root melalui SSH sepenuhnya. Kami memiliki beberapa ratus server dan setengah lusin admin sistem, beginilah cara kami melakukannya.

Bagaimana tepatnya penerusan agen rusak?

Juga, jika repot menggunakan sudodi depan setiap tugas, Anda dapat memanggil sudo shell dengan sudo -satau beralih ke shell root dengansudo su -

Berkenaan dengan strategi yang disarankan ke-3, selain teliti useradd -o -u userXXXopsi seperti yang direkomendasikan oleh @jlliagre, saya tidak akrab dengan menjalankan beberapa pengguna sebagai uid yang sama. (karenanya jika Anda melanjutkannya, saya akan tertarik jika Anda dapat memperbarui pos dengan masalah apa pun (atau berhasil) yang muncul ...)

Saya kira pengamatan pertama saya mengenai opsi pertama "Kunci publik SSH Semua orang dimasukkan ke dalam ~ root / .ssh / official_keys2", adalah bahwa kecuali Anda benar-benar tidak akan pernah bekerja pada sistem lain;

1. lalu setidaknya beberapa waktu , Anda harus bekerja dengan akun pengguna dansudo

Pengamatan kedua adalah, bahwa jika Anda bekerja pada sistem yang bercita-cita untuk HIPAA, kepatuhan PCI-DSS, atau hal-hal seperti CAPP dan EAL, maka Anda harus mengatasi masalah sudo karena;

2. Ini merupakan standar industri untuk menyediakan akun pengguna individu non-root, yang dapat diaudit, dinonaktifkan, kedaluwarsa, dll, biasanya menggunakan beberapa basis data pengguna terpusat.

Begitu; Menggunakan akun dan sudo yang dipersonalisasi

Sangat disayangkan bahwa sebagai sysadmin, hampir semua yang perlu Anda lakukan pada mesin jarak jauh akan memerlukan beberapa izin tinggi, namun itu menjengkelkan bahwa sebagian besar alat dan utilitas berbasis SSH rusak saat Anda berada di sudo

Karenanya saya dapat menyampaikan beberapa trik yang saya gunakan untuk mengatasi gangguan sudoyang Anda sebutkan. Masalah pertama adalah bahwa jika login root diblokir menggunakan PermitRootLogin=noatau Anda tidak memiliki root menggunakan kunci ssh, maka itu membuat file SCP sesuatu dari PITA.

Masalah 1 : Anda ingin scp file dari sisi jarak jauh, tetapi mereka membutuhkan akses root, namun Anda tidak dapat masuk ke kotak jauh sebagai root secara langsung.

Solusi Membosankan : salin file ke direktori home, chown, dan scp down.

ssh userXXX@remotesystem, sudo su -dll, cp /etc/somefileske /home/userXXX/somefiles,, chown -R userXXX /home/userXXX/somefilesgunakan scp untuk mengambil file dari jarak jauh.

Memang sangat membosankan.

Solusi Kurang Membosankan : sftp mendukung -s sftp_serverflag, maka Anda dapat melakukan sesuatu seperti berikut (jika Anda telah mengkonfigurasi sudo tanpa kata sandi di /etc/sudoers);

sftp  -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \
userXXX@remotehost:/etc/resolv.conf 

(Anda juga dapat menggunakan hack-around ini dengan sshfs, tapi saya tidak yakin ini direkomendasikan ... ;-)

Jika Anda tidak memiliki hak sudo tanpa kata sandi, atau karena alasan terkonfigurasi bahwa metode di atas rusak, saya dapat menyarankan satu lagi metode transfer file yang lebih tidak membosankan, untuk mengakses file root jarak jauh.

Metode Ninja Penerusan Port :

Login ke host jarak jauh, tetapi tentukan bahwa port jarak jauh 3022 (dapat berupa apa saja gratis, dan tidak disediakan untuk admin, yaitu> 1024) harus diteruskan kembali ke port 22 di sisi lokal.

 [localuser@localmachine ~]$ ssh userXXX@remotehost -R 3022:localhost:22
Last login: Mon May 21 05:46:07 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------

Dapatkan root dengan cara normal ...

-bash-3.2$ sudo su -
[root@remotehost ~]# 

Sekarang Anda dapat scp file ke arah lain menghindari langkah membosankan membosankan membuat salinan menengah file;

[root@remotehost ~]#  scp -o NoHostAuthenticationForLocalhost=yes \
 -P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password: 
resolv.conf                                 100%  
[root@remotehost ~]#  

Masalah 2: Penerusan agen SSH : Jika Anda memuat profil root, misalnya dengan menentukan shell login, variabel lingkungan yang diperlukan untuk penerusan agen SSH seperti SSH_AUTH_SOCKdiatur ulang, maka penerusan agen SSH "rusak" di bawah sudo su -.

Setengah jawaban panggang :

Apa pun yang memuat shell root dengan benar, akan mengatur ulang lingkungan dengan benar, namun ada sedikit penyelesaian yang dapat Anda gunakan saat Anda membutuhkan KEDUA root root DAN kemampuan untuk menggunakan Agen SSH, PADA SAAT YANG SAMA

Ini mencapai semacam profil chimera, yang seharusnya benar-benar tidak digunakan, karena ini adalah peretasan yang tidak menyenangkan , tetapi berguna ketika Anda perlu meng-SCP file dari host remote sebagai root, ke host remote lain.

Bagaimanapun, Anda dapat mengaktifkan bahwa pengguna Anda dapat mempertahankan variabel ENV mereka, dengan mengatur yang berikut ini dalam sudoers;

 Defaults:userXXX    !env_reset

ini memungkinkan Anda untuk membuat lingkungan login hybrid yang buruk seperti itu;

login seperti biasa;

[localuser@localmachine ~]$ ssh userXXX@remotehost 
Last login: Mon May 21 12:33:12 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------
-bash-3.2$ env | grep SSH_AUTH
SSH_AUTH_SOCK=/tmp/ssh-qwO715/agent.1971

buat bash shell, yang berjalan /root/.profiledan /root/.bashrc. tapi mempertahankanSSH_AUTH_SOCK

-bash-3.2$ sudo -E bash -l

Jadi shell ini memiliki izin root, dan root $PATH(tetapi direktori home borked ...)

bash-3.2# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:system_r:unconfined_t
bash-3.2# echo $PATH
/usr/kerberos/sbin:/usr/local/sbin:/usr/sbin:/sbin:/home/xtrabm/xtrabackup-manager:/usr/kerberos/bin:/opt/admin/bin:/usr/local/bin:/bin:/usr/bin:/opt/mx/bin

Tetapi Anda dapat menggunakan doa itu untuk melakukan hal-hal yang memerlukan root sudo jarak jauh, tetapi juga akses agen SSH seperti itu;

bash-3.2# scp /root/.ssh/authorized_keys ssh-agent-user@some-other-remote-host:~
/root/.ssh/authorized_keys              100%  126     0.1KB/s   00:00    
bash-3.2# 

Opsi ke-3 terlihat ideal - tetapi apakah Anda benar-benar mencobanya untuk melihat apa yang terjadi? Meskipun Anda mungkin melihat nama pengguna tambahan dalam langkah otentikasi, setiap pencarian sebaliknya akan mengembalikan nilai yang sama.

Mengizinkan akses ssh root langsung adalah ide yang buruk, bahkan jika mesin Anda tidak terhubung ke internet / gunakan kata sandi yang kuat.

Biasanya saya menggunakan 'su' daripada sudo untuk akses root.

Saya menggunakan (1), tetapi saya mengetik

rm -rf / tmp *

pada suatu hari yang bernasib buruk. Saya bisa melihat cukup buruk jika Anda memiliki lebih dari beberapa admin.

(2) Mungkin lebih direkayasa - dan Anda dapat menjadi root penuh melalui sudo su -. Kecelakaan masih mungkin terjadi.

(3) Saya tidak akan menyentuh dengan tongkang. Saya menggunakannya di Suns, untuk memiliki akun root non-barebone-sh (jika saya ingat dengan benar) tetapi tidak pernah kuat - ditambah saya ragu itu akan sangat diaudit.

Jawaban pasti 2.

1. Berarti Anda mengizinkan akses SSH sebagai root. Jika mesin ini dalam cara apa pun menghadapi publik, ini hanya ide yang mengerikan; kembali ketika saya menjalankan SSH pada port 22, VPS saya mendapat beberapa upaya setiap jam untuk mengotentikasi sebagai root. Saya memiliki IDS dasar yang diatur untuk mencatat dan melarang IP yang membuat beberapa upaya gagal, tetapi mereka terus berdatangan. Untungnya, saya telah menonaktifkan akses SSH sebagai pengguna root segera setelah saya memiliki akun saya sendiri dan sudo dikonfigurasi. Selain itu, Anda hampir tidak memiliki jejak audit untuk melakukan ini.

2. Menyediakan akses root saat dan ketika dibutuhkan. Ya, Anda nyaris tidak memiliki hak istimewa sebagai pengguna standar, tetapi ini persis seperti yang Anda inginkan; jika akun dikompromikan, Anda ingin itu dibatasi dalam kemampuannya. Anda ingin setiap pengguna super membutuhkan entri ulang kata sandi. Selain itu, akses sudo dapat dikontrol melalui grup pengguna, dan terbatas pada perintah tertentu jika Anda suka, memberi Anda lebih banyak kontrol atas siapa yang memiliki akses ke apa. Selain itu, perintah dijalankan karena sudo dapat dicatat, sehingga memberikan jejak audit yang jauh lebih baik jika ada kesalahan. Oh, dan jangan hanya menjalankan "sudo su -" begitu Anda masuk. Itu praktik yang sangat buruk.

3. Ide sysadmin Anda buruk. Dan dia seharusnya merasa tidak enak. Tidak, * mesin nix mungkin tidak akan menghentikan Anda dari melakukan ini, tetapi kedua sistem file Anda, dan hampir setiap aplikasi di luar sana mengharapkan setiap pengguna memiliki UID yang unik. Jika Anda mulai menuruni jalan ini, saya dapat menjamin bahwa Anda akan mengalami masalah. Mungkin tidak segera, tetapi pada akhirnya. Misalnya, meskipun menampilkan nama yang ramah, file dan direktori menggunakan nomor UID untuk menunjuk pemiliknya; jika Anda menjalankan program yang memiliki masalah dengan duplikat UID di telepon, Anda tidak bisa hanya mengubah UID di file passwd Anda nanti tanpa harus melakukan pembersihan sistem file manual yang serius.

sudoadalah jalan ke depan. Ini dapat menyebabkan kerumitan tambahan dengan menjalankan perintah sebagai root, tetapi memberikan Anda dengan kotak yang lebih aman, baik dalam hal akses dan audit.

Pilihan 2, tetapi gunakan grup untuk memberi setiap pengguna kontrol sebanyak mungkin tanpa perlu menggunakan sudo. sudo di depan setiap perintah kehilangan separuh manfaatnya karena Anda selalu berada di zona bahaya. Jika Anda membuat direktori yang relevan dapat ditulis oleh sysadmin tanpa sudo Anda mengembalikan sudo ke pengecualian yang membuat semua orang merasa lebih aman.

Di masa lalu, sudo tidak ada. Akibatnya, memiliki beberapa pengguna UID 0 adalah satu-satunya alternatif yang tersedia. Tapi itu masih tidak begitu baik, terutama dengan pencatatan berdasarkan UID untuk mendapatkan nama pengguna.

Saat ini, sudo adalah satu-satunya solusi yang tepat. Lupakan yang lainnya.

Ini didokumentasikan diizinkan oleh fakta. BSD unices telah memiliki akun toor mereka untuk waktu yang lama, dan pengguna bashroot cenderung menerima praktik pada sistem di mana csh adalah standar (malpraktik yang diterima;)

Mungkin saya aneh, tetapi metode (3) adalah yang pertama muncul di pikiran saya juga. Pro: Anda akan memiliki setiap nama pengguna di log dan akan tahu siapa yang melakukan apa sebagai root. Cons: mereka masing-masing menjadi root sepanjang waktu, sehingga kesalahan bisa menjadi bencana besar.

Saya ingin mempertanyakan mengapa Anda membutuhkan semua admin untuk memiliki akses root. Semua 3 metode yang Anda usulkan memiliki satu kelemahan yang berbeda: begitu seorang admin menjalankan satu sudo bash -latau lebih sudo su -, Anda kehilangan kemampuan untuk melacak siapa yang melakukan apa dan setelah itu, kesalahan bisa menjadi bencana besar. Selain itu, dalam kasus kemungkinan perilaku yang salah, ini bahkan mungkin jauh lebih buruk.

Alih-alih, Anda mungkin ingin mempertimbangkan cara lain:

• Buat pengguna admin Anda sebagai pengguna biasa
• Putuskan siapa yang perlu melakukan pekerjaan apa (manajemen apache / manajemen postfix dll)
• Tambahkan pengguna ke grup terkait (seperti tambahkan "martin" ke "postfix" dan "mail", "amavis" jika Anda menggunakannya, dll.)
• Perbaiki izin (chmod -R g + w postfix: postfix / etc / postfix)
• hanya berikan kekuatan sudo relatif: (visudo -> biarkan martin menggunakan /etc/init.d/postfix, / usr / bin / postsuper dll.)

Dengan cara ini, martin dapat menangani postfix dengan aman, dan jika terjadi kesalahan atau kelakuan buruk, Anda hanya akan kehilangan sistem postfix Anda, bukan seluruh server.

Logika yang sama dapat diterapkan ke subsistem lain, seperti apache, mysql, dll.

Tentu saja, ini murni teoretis pada titik ini, dan mungkin sulit diatur. Memang terlihat seperti cara yang lebih baik untuk pergi. Setidaknya bagi saya. Jika ada yang mencoba ini, tolong beri tahu saya bagaimana hasilnya.