Login Root Jarak Jauh

8

Saya tahu salah satu hal pertama yang Anda lakukan untuk mengamankan server adalah tidak mengizinkan login root jarak jauh.

Kata sandi sangat lemah; apa yang orang pikirkan hanya mengizinkan login root melalui kunci ssh atau metode tanpa kata sandi lainnya.

Metode mana yang terbaik? Apakah lebih baik tidak mengambil risiko? Apakah ssh-ing dengan akun sekunder dan menggunakan su -benar - benar menambah keamanan?

Bagaimana orang-orang di serverfault.com mengakses root di server jauh?

— Kousha
sumber

9

Sebagian besar ada sedikit yang diperoleh dengan benar-benar menonaktifkan login root jarak jauh. Ini sedikit membantu menegakkan kebijakan yang admin login melalui akun mereka sendiri dan suuntuk me-root seperlunya (atau sudomungkin digunakan dengan sudosh... tergantung pada kebijakan Anda).

Membuat kata sandi root yang sangat panjang dan rumit (efektif selama Anda masih belum menggunakan hashing garam DES + 12-bit kuno untuk kata sandi Anda) sama efektifnya untuk menegakkan kebijakan semacam itu.

Satu situs yang saya kenal memiliki sistem di mana kata sandi unik dihasilkan secara acak untuk setiap host, disimpan dalam database, dan didorong ke sistem. Admin diminta untuk menggunakan sshakun normal mereka, dan sudountuk sebagian besar operasi. Namun, kata sandi root dapat diakses oleh mereka melalui layanan web internal berbasis SSL (yang selanjutnya memerlukan token RSA SecurID dan PIN mereka). Mengambil kata sandi root berarti memasukkan justifikasi (biasanya tautan ke nomor tiket Remedy (TM)) dan mengakses tempat yang diaudit secara berkala. Salah satu dari beberapa alasan yang dapat diterima untuk menggunakan kata sandi root secara langsung adalah dalam kasus-kasus di mana sistem dihentikan fsckselama proses boot ... dansuloginmembutuhkan kata sandi root nyata untuk menjalankan proses pemeriksaan dan perbaikan sistem file secara manual. (Ada beberapa diskusi tentang metode alternatif untuk ini --- yang relatif mudah untuk Linux, tetapi menjadi jauh lebih sulit ketika Anda mencoba untuk memperpanjang prosedur Anda untuk menjelaskan banyak warisan HP-UX, AIX dan sistem SunOS dan Solaris lama yang masih dalam produksi di lingkungan itu).

Ada kasus sudut di mana kata sandi root diperlukan --- atau setidaknya merupakan alternatif terbaik yang tersedia. Menjaga ketersediaannya sementara membuatnya cukup kuat terhadap berbagai ancaman yang dapat Anda antisipasi pada umumnya adalah strategi terbaik Anda.

Situs lain yang saya tahu memiliki pendekatan yang agak elegan untuk manajemen akun terdesentralisasi. Mereka memiliki paket pengguna * dan sudo * * (pikirkan RPM) yang diinstal ke dalam sistem menggunakan prosedur manajemen paket normal dan infrastruktur otomatisasi. Dalam kasus mereka, paket sudo- * memiliki ketergantungan pada paket pengguna- * yang sesuai. Ini bagus karena memungkinkan Anda untuk memiliki kelompok mesin dengan akun yang dilokalkan (semua akun adalah admin, pengembang, staf pendukung atau akun "tanpa kepala") dan menghilangkan ketergantungan pada LDAP / NIS atau layanan identitas dan otentikasi jaringan lainnya. (Ini mengurangi kopling antar sistem membuatnya secara signifikan lebih kuat).

Satu hal yang saya sukai dari pendekatan itu adalah memberikan fleksibilitas. Siapa pun yang memiliki sudoakses dapat mengeluarkan perintah untuk menambahkan pengguna normal atau sudoakun pengguna lain . Jadi, jika saya mengerjakan tiket, siapa saja yang sudah memiliki akses ke sistem dapat dengan mudah memberi saya akses. Tidak ada penundaan sementara tiket untuk menambahkan saya ke beberapa daftar kontrol akses di beberapa pusat data menggiling melalui beberapa proses persetujuan terpusat dan akhirnya menyebarkan perubahan kembali ke sistem yang bersangkutan. Siapa pun yang berwenang sudodi sistem dapat memberi saya akses dan kemudian menghapus saya. (Ya jika saya jahat dan mereka mempermainkan sayasudoSaya dapat mengubah hal-hal jahat untuk mempertahankan akses ... pada kenyataannya ada beberapa hal yang dapat saya lakukan seperti pengguna biasa untuk mempertahankan akses melewati penghapusan tersebut. Namun, itu bukan ancaman yang mereka khawatirkan. Akses saya masih terbatas pada jumlah sistem yang relatif lebih kecil secara keseluruhan; jadi dampak dari akun yang disusupi masih lebih terbatas daripada kebanyakan skema serupa yang pernah saya lihat.

— Jim Dennis
sumber

2

Jika Anda menonaktifkan akses root jarak jauh, Anda mencegah penyerang jarak jauh langsung mendapatkan root - mereka harus membobol akun lain, mendapatkan akses ke mesin, dan kemudian mencoba dan mendapatkan akses ke root. Ini langkah ekstra.

Root umumnya dinonaktifkan untuk akses jarak jauh. SU bekerja dengan baik. Jika sesuatu benar-benar rusak selalu ada akses langsung ke kotak untuk memperbaikinya.

Jika Anda ingin menjadi lebih ketat - cukup nonaktifkan sepenuhnya root, untuk itulah sudo ada. Sekali lagi, dengan pendekatan itu Anda masih bisa mendapatkan akses root dengan beralih ke mode pengguna tunggal - ala Ubuntu. Meskipun, saya percaya mereka menggunakan init yang ditambal untuk itu, sesuai dokumen mereka.

Selain itu Anda dapat mengatur idle untuk memulai pengguna idle jika terminal mereka dibiarkan terbuka, dan PC juga terbuka. Anda dapat memaksa semua pengguna untuk menggunakan kunci, tetapi manajemen kunci bisa sulit.

Sebuah host logging pass-through tunggal sebagai sistem tipe breakglass juga memaksa lapisan perlindungan tambahan dan jejak audit.

— Alex
sumber

2

Saya sarankan Anda mengatur sistem untuk memungkinkan akses root SAJA di konsol.

Kalau tidak, menggunakan sudo dengan opsi kata sandi, memungkinkan pengguna terpilih mengakses perintah priv'd. BTW, sadari bahwa sudo dapat dirancang untuk membatasi akun pengguna untuk perintah tertentu jika Anda mau. Sudo, meninggalkan "tanda" di log sistem yang digunakan. sudo lebih baik daripada su karena kata sandi root tidak diungkapkan. Dengan demikian Anda dapat mengubah kata sandi root dan pengguna yang menggunakan sudo tidak akan lebih bijaksana.

Penggunaan sudo yang diizinkan untuk masuk ke perintah priv'd harus disertai dengan perubahan kata sandi periodik paksa dengan frekuensi tergantung pada lingkungan.

— mdpc
sumber

1

Saya merasa masalah dengan sudo adalah ia menggunakan kata sandi normal pengguna. Karena itu, jika akun dikompromikan, maka akses root hanya berjarak 'sudo -s'. Menggunakan 'su' membutuhkan penyerang mematahkan dua kata sandi.

— Kousha

Juga, saya akan memerlukan semacam akses root jarak jauh karena ini adalah server yang dihosting, dan saya tidak memiliki akses ke konsol fisik.

— Kousha

Jika saya ingat, Anda dapat mengonfigurasi sudo untuk menggunakan kata sandi akun lain selain akun pengguna.

— mdpc

1

jangan pernah izinkan root

mengatur sistem untuk memungkinkan akses melalui kunci hanya tanpa kata sandi

lalu atur sudo untuk pengguna yang diizinkan melakukan perubahan melalui akun root

— drfrog
sumber

Sementara saya setuju untuk sebagian besar situasi, ada saat-saat tertentu saya merasa baik-baik saja dalam mengizinkan akses root jarak jauh (terutama menggunakan kunci)

— Matt Simmons

saya lebih suka mengambil waktu ekstra untuk sudo untuk melakukan sesuatu daripada memiliki akses root ke mesin, bahkan wa kunci dari hanya sekilas pada setiap server auth log yang biasanya melihat login root yang digunakan untuk mencoba mendapatkan akses ke kotak , sekitar 90% dari semua upaya login! jika Anda memiliki info tentang sebuah kotak, Anda tidak ingin sembarang orang mendapatkan akses ke bentuknya yang buruk untuk membiarkan sebuah kotak terbuka untuk di-root

— drfrog

Di desktop, ya. Tetapi pada server yang dikelola oleh satu pengguna, penggunaan sudo sedikit seperti bermain "kata simon". IMO hanya jika Anda memiliki beberapa admin dan Anda ingin / perlu tindakan mereka dicatat, maka penggunaan pengguna sudo adalah sah. Bahkan kemudian, saya tidak yakin bahwa menonaktifkan root diperlukan (walaupun membatasi login root jarak jauh hanya untuk kunci adalah bijaksana).

— Jeremy Davis