Apakah boleh mengatur sudo tanpa kata sandi di server cloud?

Saya suka gagasan mengakses server melalui kunci, sehingga saya tidak perlu mengetikkan kata sandi setiap kali sshmasuk ke dalam kotak, saya bahkan mengunci rootkata sandi pengguna (bukan ) ( passwd -l username) sehingga tidak mungkin untuk masuk tanpa kunci.

Tetapi semua ini rusak jika saya diminta untuk memasukkan kata sandi untuk sudoperintah. Jadi saya tergoda untuk mengatur kata sandisudo untuk membuat hal-hal sejalan dengan login tanpa kata sandi.

Namun, saya tetap punya firasat bahwa itu mungkin menjadi bumerang bagi saya dengan cara yang tidak terduga, sepertinya tidak aman. Apakah ada peringatan dengan pengaturan seperti itu? Apakah Anda merekomendasikan / tidak merekomendasikan melakukan ini untuk akun pengguna di server?

Klarifikasi

1. Saya berbicara tentang sudopenggunaan sesi pengguna interaktif di sini, bukan untuk skrip layanan atau administrasi
2. Saya berbicara tentang menggunakan server cloud (jadi saya tidak punya akses fisik lokal ke mesin dan hanya bisa masuk dari jarak jauh)
3. Saya tahu bahwa sudoada batas waktu di mana saya tidak perlu memasukkan kembali kata sandi saya. Tetapi konser saya bukan tentang membuang waktu ekstra untuk mengetikkan kata sandi secara fisik. Ide saya adalah untuk tidak harus berurusan dengan kata sandi sama sekali, karena saya berasumsi bahwa:
   • Jika saya harus menghafalnya sama sekali, sangat mungkin terlalu pendek untuk aman atau digunakan kembali
   • Jika saya membuat kata sandi yang panjang dan unik untuk akun jarak jauh saya, saya harus menyimpannya di suatu tempat (program pengelola kata sandi lokal atau layanan cloud) dan mengambilnya setiap kali saya ingin menggunakannya sudo. Saya berharap bisa menghindarinya.

Jadi dengan pertanyaan ini saya ingin lebih memahami risiko, peringatan dan pengorbanan dari satu konfigurasi yang mungkin atas yang lain.

Tindak lanjut 1

Semua jawaban mengatakan bahwa tanpa kata sandi sudotidak aman karena memungkinkan peningkatan hak "mudah" jika akun pengguna pribadi saya dikompromikan. Aku mengerti itu. Tetapi di sisi lain, jika saya menggunakan kata sandi, kami menanggung semua risiko klasik dengan kata sandi (string terlalu pendek atau umum, diulang di berbagai layanan, dll.). Tapi saya kira jika saya menonaktifkan otentikasi kata sandi /etc/ssh/sshd_configsehingga Anda masih harus memiliki kunci untuk masuk, saya dapat menggunakan kata sandi yang lebih sederhana hanya untuk sudoyang lebih mudah untuk mengetik? Apakah itu strategi yang valid?

Tindak lanjut 2

Jika saya juga memiliki kunci untuk masuk sebagai rootmelalui ssh, jika seseorang mendapatkan akses ke komputer saya dan mencuri kunci saya (mereka masih dilindungi oleh kata sandi keyring OS!), Mereka mungkin juga mendapatkan akses langsung ke rootakun , melewati sudojalan. Apa yang seharusnya menjadi kebijakan untuk mengakses rootakun itu?

Saya suka gagasan mengakses server melalui kunci, sehingga saya tidak perlu mengetikkan kata sandi setiap kali saya ssh ke dalam kotak, saya bahkan mengunci kata sandi pengguna saya (bukan root) (passwd -l nama pengguna) sehingga tidak mungkin untuk masuk tanpa kunci ... Apakah Anda merekomendasikan / tidak merekomendasikan melakukan ini untuk akun pengguna di server?

Anda akan menonaktifkan login berbasis kata sandi dengan cara yang salah. Alih-alih mengunci akun pengguna, atur PasswordAuthentication nodi akun Anda /etc/ssh/sshd_config.

Dengan set itu, otentikasi kata sandi dinonaktifkan untuk ssh, tetapi Anda masih dapat menggunakan kata sandi untuk sudo.

Satu- satunya waktu saya merekomendasikan pengaturan NOPASSWDdalam sudo adalah untuk akun layanan, di mana proses harus dapat menjalankan perintah melalui sudo secara terprogram. Dalam keadaan itu, pastikan bahwa Anda secara eksplisit memasukkan daftar putih hanya perintah khusus yang perlu dijalankan akun. Untuk akun interaktif, Anda harus selalu membiarkan kata sandi diaktifkan.

Tanggapan untuk pertanyaan tindak lanjut Anda:

Tapi saya kira jika saya menonaktifkan otentikasi kata sandi di / etc / ssh / sshd_config sehingga Anda masih harus memiliki kunci untuk masuk, saya dapat menggunakan kata sandi yang lebih sederhana hanya untuk sudo yang lebih mudah untuk mengetik? Apakah itu strategi yang valid?

Ya itu benar. Saya masih merekomendasikan penggunaan kata sandi akun lokal yang relatif kuat, tetapi tidak terlalu kuat. ~ 8 karakter, dihasilkan secara acak sudah cukup.

Jika saya juga memiliki kunci untuk login sebagai root melalui ssh, jika seseorang mendapatkan akses ke komputer saya dan mencuri kunci saya (mereka masih dilindungi oleh kata sandi keyring OS!), Mereka mungkin juga mendapatkan akses langsung ke akun root, melewati jalur sudo.

Akses root melalui ssh harus dinonaktifkan. Titik. Ditetapkan PermitRootLogin nodalam sshd_config.

Apa yang seharusnya menjadi kebijakan untuk mengakses akun root?

Anda harus selalu memiliki cara untuk mendapatkan akses out-of-band ke konsol server Anda. Beberapa vendor VPS memang menyediakan ini, seperti halnya vendor perangkat keras khusus. Jika penyedia Anda tidak memberikan akses konsol nyata (misalnya, EC2 misalnya), Anda biasanya masih dapat memulihkan akses menggunakan proses seperti apa yang saya uraikan dalam jawaban ini .

Saya biasanya membatasi penggunaan NOPASSWORDuntuk perintah yang dijalankan oleh proses otomatis. Lebih disukai memiliki akun layanan untuk perintah-perintah ini, dan membatasi penggunaan sudo untuk perintah yang diperlukan.

Mengizinkan NOPASSWORDperintah umum, memungkinkan siapa saja yang mendapatkan akses ke userid Anda untuk menjalankan perintah apa pun. Ini bisa terjadi akibat kompromi kredensial Anda, tetapi bisa sesederhana seseorang yang duduk di meja Anda ketika Anda menjauh sebentar.

Saya merasa saya tidak harus sering memasukkan kata sandi. Setelah Anda memasukkan kata sandi, Anda dapat menjalankan beberapa perintah jika Anda tidak menunggu terlalu lama di antara mereka. Batas waktu dapat dikonfigurasi.

Saya hanya akan menggunakan ini dalam dua keadaan:

• Ketika itu mutlak diperlukan untuk skrip otomatis yang berjalan sebagai pengguna tertentu
• Untuk tugas admin tertentu (hanya baca tugas admin, bukan tugas yang mengambil tindakan untuk mengubah sistem) dan kemudian hanya untuk pengguna tertentu saja

Secara default sebagian besar sudokonfigurasi tidak akan meminta Anda lagi untuk sementara waktu di sesi yang sama (jika Anda membuka shell baru yang tidak memiliki efek apa pun). Anda dapat mengontrol perilaku ini sampai batas tertentu dengan timestamp_timeoutpengaturan.

Tanpa kata sandi sudotidak hampir sama berbahaya dengan sshkunci tanpa frasa sandi , karena penyerang jarak jauh memerlukan kredensial Anda untuk masuk, tetapi jika mereka masuk dengan cara entah bagaimana membahayakan kunci pribadi Anda (atau jika mereka secara fisik lokal bagi Anda dan Anda membiarkan diri Anda masuk dan membuka kunci saat jauh dari mesin) maka permintaan kata sandi adalah pertahanan ekstra yang berharga di antara mereka dan akses istimewa.

Mengenai tindak lanjut 2:

Jika saya juga punya kunci untuk login sebagai root via ssh

Ini sebaiknya dihindari juga, untuk alasan yang persis Anda jelaskan. Jika koneksi jarak jauh harus memiliki akses istimewa, login melalui akun layanan dan berikan kontrol yang cukup untuk melakukan tugasnya melalui sudo. Ini lebih sulit untuk dikonfigurasikan tentu saja sehingga banyak yang tidak repot (yang menguntungkan Anda jika Anda melakukannya, karena ada banyak buah gantung yang lebih rendah daripada penyerang yang menghabiskan waktu di sana!), Jadi itu tergantung pada kompromi lama antara keamanan dan kenyamanan (tip pro: pilih keamanan!).

Anda dapat memiliki yang terbaik dari kedua dunia: Otentikasi SSH untuk masuk dan untuk sudo. Jika Anda mengintegrasikan modul pam_ssh_agent_auth Anda dapat menggunakan kunci SSH untuk mengotentikasi tanpa memberikan kata sandi saat Anda sudo.

Saya telah menggunakan ini dalam produksi selama lebih dari lima tahun.

Untuk mengkonfigurasinya, instal modul PAM, lalu tambahkan baris ke /etc/pam.d/sudoatau setara dengan sistem Anda:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys

Jika Anda melakukan ini, pastikan untuk melindungi kunci Anda di komputer Anda dengan frasa sandi. Dengan begitu, seseorang harus membobol komputer Anda dan mencuri kunci untuk masuk. Mereka bisa melakukannya dengan menariknya dari memori saat mereka tidak terkunci jika mereka memiliki akses ke akun Anda, dengan memecahkan kata sandi Anda, atau mencuri kata sandi Anda melalui seorang keylogger atau selancar bahu saat Anda mengetiknya (lihat di belakang Anda!).

Anda dapat menggunakan kunci SSH yang sama seperti yang Anda lakukan untuk login, atau Anda bisa mengatur kunci terpisah yang hanya Anda tambahkan ke agen Anda ketika Anda sudo. Jadi, jika Anda ingin ekstra hati-hati, Anda bisa memelihara file Author_keys terpisah yang memiliki kunci SSH terpisah yang hanya Anda tambahkan ke agen Anda ketika Anda perlu sudo:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo

Karena Anda bertanya, inilah saran umum saya tentang cara mengatasi sudomasalah ini.

Sudo tidak dirancang untuk memberikan lebih banyak keamanan (meskipun dalam beberapa hal bisa) ... tetapi lebih memberikan jejak audit yang baik tentang siapa yang melakukan apa pada sistem Anda dengan hak istimewa apa.

Pengaturan yang tepat, Sudo tidak akan menggunakan ALL=(ALL) ALLpengaturan, melainkan sesuatu yang lebih terbatas pada apa pun yang secara spesifik dibutuhkan oleh pengguna. Misalnya, jika Anda memerlukan pengguna untuk dapat masuk dan memulai kembali layanan yang macet, mereka mungkin tidak memerlukan kemampuan untuk menginstal perangkat lunak baru atau mematikan server Anda, mengubah aturan firewall, dll.

Terkadang orang menggunakan sudo untuk menaikkan diri mereka ke akun root, yaitu. sudo su -. Setelah mereka melakukan itu, Anda berhenti melihat siapa yang melakukan apa dari akun root (root dapat login ke beberapa kali secara bersamaan). Jadi kadang-kadang orang ingin menonaktifkan sudo su -perintah juga. Tetapi, untuk alasan praktis, jika Anda benar-benar membutuhkan akun istimewa yang sepenuhnya root untuk administrasi, setidaknya memiliki seseorang mengeluarkan sudo su -perintah akan mencatat siapa yang ditinggikan untuk root dan kapan.

Bagaimana saya mengamankan kotak saya:

Ubah port SSH ke sesuatu selain yang default. Ini untuk menghindari bot bodoh yang mencari nomor port lalu menumbuknya sampai mereka masuk (atau tidak).

Larang login Root melalui SSH menggunakan AllowRootLogin nopengaturan di sshd_config Anda. Ini mencegah seseorang dari kekerasan memaksa masuk ke akun root Anda. Ini umumnya merupakan praktik yang baik untuk tidak pernah mengizinkan seseorang untuk langsung masuk ke akun root / administrator untuk alasan audit dan juga keamanan. Jika Anda mengizinkan login root secara langsung, Anda tidak tahu siapa yang login, dari siapa mereka mendapatkan kata sandi, dll. Tetapi, jika seseorang login ke akun Jimmy, kemudian meningkatkan izin mereka untuk melakukan root, Anda memiliki ide yang lebih baik dari mana memulai. pencarian audit (dan siapa akun yang akan direset).

Hanya izinkan pengguna ke SSH yang membutuhkannya Gunakan AllowUserspengaturan dan kejelasan menentukan akun mana yang membutuhkan akses SSH. Ini akan, secara default, memblokir semua akun lain dari SSH.

Sunting Sudoers via visudo dan hanya izinkan perintah yang dibutuhkan pengguna. Ada banyak panduan mendalam tentang cara melakukan ini, jadi saya tidak akan menjelaskan di sini. Inilah pemula: http://ubuntuforums.org/showthread.php?t=1132821

Inti dari ini adalah untuk mencegah akun yang disusupi membahayakan mesin Anda. yaitu. jika akun Sally dibobol, dan Sally hanya dapat menggunakan sudo untuk memulai kembali server web, baik penyerang mungkin bersenang-senang memulai kembali server web Anda dalam satu lingkaran, tetapi setidaknya mereka tidak bisa rm -rf /your/webserver/directoryatau membuka semua port firewall Anda, dll.

Siapkan aturan firewall yang baik yang hanya memungkinkan port yang diperlukan untuk komputer Anda untuk beroperasi. Secara umum Anda ingin meninggalkan semuanya dan hanya mengizinkan apa yang Anda butuhkan secara eksplisit. Ada banyak iptables yang layak dan firewall lainnya mulai online, inilah yang saya gunakan (ini adalah starter dasar):

# Generated by iptables-save v1.4.7 on Mon Mar  3 17:55:02 2014
*filter
:INPUT DROP [4528:192078]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [39845:27914520]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4254 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Mar  3 17:55:02 2014

Juga kata sandi yang kuat adalah kuncinya.Bahkan jika Anda menggunakan kunci SSH untuk akses jarak jauh Anda, Anda tetap harus meminta kata sandi untuk penggunaan Sudo. Ini adalah kasus di mana sudo dapat memberikan keamanan lebih. Jika seseorang mencuri kunci ssh Anda, mereka masih akan dicegah melakukan sesuatu yang signifikan pada kotak Anda jika mereka masih harus memaksa paksa kata sandi akun Anda untuk menggunakan sudo. Kata sandi tidak boleh berupa kata, melainkan Frasa Lulus. Pikirkan sebuah kalimat, dan gunakan itu. Ini biasanya memberi Anda lebih dari 8 karakter, memberikan banyak entropi, tetapi juga lebih mudah diingat daripada kata sandi acak. Tentu saja, praktik kata sandi yang baik mengatakan untuk menggunakan kata sandi acak yang dihasilkan mesin untuk mengelabui alat cracking seperti John the Ripper, yang akan merobek sebagian besar frasa sandi dan kata sandi. Tidak, mengubah E dengan 3 tidak berhasil, John mendapatkan permutasi juga.

Dalam beberapa kasus, ini perlu dilakukan. misalnya beberapa hypervisor API perlu login tanpa kata sandi dan tanpa kata sandi sudo. Tetapi Anda masih bisa membatasi itu tanpa melanggar.

Untuk apa yang ingin Anda capai. Menurut saya, biasakan mengetikkan kata sandi. Keamanan lebih nyaman daripada kenyamanan di sini. Selain itu, jika Anda benar-benar membutuhkan akses root, Anda dapat menggunakan sudodan itu akan men-cache kredensial untuk sementara waktu sehingga jika Anda menjalankan beberapa perintah sudo berturut-turut, itu hanya akan meminta kata sandi pertama kali. Jadi itu bukan ketidaknyamanan besar seperti yang Anda duga.

Juga jika Anda mengetikkan banyak perintah khusus root dan tidak ingin menempatkan sudo di depannya sepanjang waktu Anda bisa suatau sudo -suntuk mendapatkan shell root. Anda akan memasukkan kata sandi Anda sekali dan hanya itu saja.

Saya pernah digigit sudo tanpa kata sandi. Itu adalah skrip shell, beberapa penginstal yang memanggil sudo atas nama saya sebagai lawan, Anda tahu, hanya memerlukan sudo atau kesalahan.

Pencitraan dengan mengetikkan 'make' dan skrip yang melakukan bagian 'sudo make install' untuk Anda, tanpa mengatur atau menampilkan path dasar, dan skrip tersebut menjadi braindead di tempat pertama sehingga Anda tidak yakin mereka tahu tentang / usr / local dan Anda mulai memeriksa / usr untuk modifikasi ...

Saya bersumpah untuk tidak menggunakan NOPASSWD lagi dan juga mengubah pengaturan batas waktu ke 0.

Meskipun tidak secara ketat menjawab pertanyaan Anda, opsi lain mungkin mengatur lebih lama timestamp_timeoutsehingga Anda tidak perlu mengetik kata sandi terlalu sering. Ini akan mencegah sembarang orang mendapatkan hak istimewa admin, tetapi mengurangi gangguan Anda.

Dari halaman manual sudoers :

timestamp_timeout

Jumlah menit yang dapat dilewati sebelum sudo akan meminta passwd lagi. Batas waktu dapat mencakup komponen fraksional jika granularitas menit tidak cukup, misalnya 2,5. Standarnya adalah 5. Tetapkan ini ke 0 untuk selalu meminta kata sandi. Jika disetel ke nilai kurang dari 0, stempel waktu pengguna tidak akan pernah kedaluwarsa. Ini dapat digunakan untuk memungkinkan pengguna membuat atau menghapus prangko waktu mereka masing-masing melalui "sudo -v" dan "sudo -k".

Posting blog ini menunjukkan beberapa contoh penggunaan visudountuk mengatur batas waktu dalam hitungan menit, seperti:

Defaults timestamp_timeout=60

Mungkin ini adalah jalan tengah yang menyenangkan antara keamanan dan kemudahan penggunaan?

Jawaban lain di sini luar biasa, dan menyentuh sebagian besar poin penting. Satu hal yang belum saya lihat sebutkan adalah kenyataan bahwa segala jenis otentikasi yang Anda lakukan ketika masuk sendiri dapat ditangkap oleh penyerang jarak jauh yang telah membuat pijakan di akun Anda. Mereka dapat memodifikasi file login shell Anda atau PATH untuk menginstal keylogger sehingga semua yang Anda ketik, termasuk kata sandi sudo Anda, dikirimkan kepada mereka. Mereka dapat menambahkan biner sudo yang diretas ke PATH Anda untuk mengumpulkan kata sandi Anda. Mereka dapat membajak koneksi ssh agent kembali ke mesin penghubung Anda untuk mengalahkan pam_ssh_agent_auth dan menjadi root sendiri begitu Anda terhubung. Jadi dalam hal keamanan absolut, saya tidak melihat perbedaan antara menggunakan kata sandi untuk sudo dan tidak. Itu, tentu saja, membuatnya menjadi serangan yang lebih rumit,

Singkatnya, saya percaya satu-satunya cara untuk benar-benar mencegah akun pengguna yang dikompromikan menjadi root jika Anda memiliki akses sudo adalah menghapus akses sudo dari diri Anda sendiri, atau tidak pernah menggunakannya. Jika Anda tidak setuju, beri tahu saya, karena saya ingin salah!