Mengapa login root melalui SSH begitu buruk sehingga semua orang menyarankan untuk menonaktifkannya?

83

Semua orang di Internet menyarankan untuk menonaktifkan login root melalui SSH karena itu adalah praktik yang buruk dan lubang keamanan dalam sistem, tetapi tidak ada yang menjelaskan mengapa begitu.

Apa yang sangat berbahaya dalam mengaktifkan login root (terutama dengan login password yang dinonaktifkan)?

Dan apa perbedaan antara nama pengguna simbol X dan kata sandi simbol Y atau nama pengguna root dan kata sandi simbol X + Y dari sudut pandang keamanan jika otentikasi kata sandi dibolehkan?

ssh security root

— buru-buru
sumber

2

Memiliki pengguna root di sebagian besar sistem itu buruk, biarkan saja mengaktifkan SSH login untuk kata pengguna!

— Suman

1

Root login melalui ssh diperlukan untuk ehealth-aussie.blogspot.com/2012/01/… . Semuanya kompromi.

— emory

2

Umm ... haruskah kita memindahkan pertanyaan ini ke keamanan? Karena topik lebih condong ke keamanan maka sistem * nix.

— Braiam

1

Ada alasan administratif untuk menonaktifkan root. Pada server komersial Anda selalu ingin mengontrol akses oleh orang. root tidak pernah menjadi orang. Bahkan jika Anda mengizinkan beberapa pengguna untuk memiliki akses root, Anda harus memaksa mereka untuk login melalui pengguna mereka sendiri dan kemudian su -atau sudo -iagar login mereka yang sebenarnya dapat direkam. Ini membuat pencabutan semua akses ke seseorang menjadi lebih mudah sehingga bahkan jika mereka memiliki kata sandi root, mereka tidak dapat melakukan apa-apa dengannya.

— Philip Couling

62

Mengapa membasmi SSH itu buruk

Ada banyak bot di luar sana yang mencoba masuk ke komputer Anda melalui SSH. Bot ini bekerja dengan cara berikut.

Mereka mengeksekusi sesuatu seperti ssh root@$IPdan kemudian mereka mencoba kata sandi standar seperti "root" atau "password123". Mereka melakukan ini selama mungkin, sampai mereka menemukan kata sandi yang tepat. Pada server yang dapat diakses di seluruh dunia Anda dapat melihat banyak entri log dalam file log Anda. Saya bisa mencapai 20 per menit atau lebih.

Ketika penyerang memiliki keberuntungan (atau cukup waktu), dan menemukan kata sandi, mereka akan memiliki akses root dan itu berarti Anda dalam masalah.

Tetapi ketika Anda melarang root untuk login lebih dari SSH, bot pertama-tama perlu menebak nama pengguna dan kemudian kata sandi yang cocok. Jadi katakanlah daftar kata sandi yang masuk akal memiliki Nentri dan daftar pengguna yang masuk akal adalah Mentri yang besar. Bot memiliki serangkaian N*Mentri untuk diuji, jadi ini membuatnya sedikit lebih sulit untuk bot dibandingkan dengan kasus root di mana ia hanya seperangkat ukuran N.

Beberapa orang akan mengatakan bahwa tambahan Mini bukan keuntungan nyata dalam keamanan dan saya setuju bahwa ini hanya peningkatan keamanan kecil. Tetapi saya menganggap ini lebih sebagai gembok kecil ini yang dengan sendirinya tidak aman, tetapi mereka menghalangi banyak orang dari akses yang mudah. Ini tentu saja hanya valid jika mesin Anda tidak memiliki nama pengguna standar lainnya, seperti tor atau apache.

Alasan yang lebih baik untuk tidak mengizinkan root adalah root dapat melakukan lebih banyak kerusakan pada mesin daripada yang dapat dilakukan pengguna standar. Jadi, jika dengan keberuntungan mereka menemukan kata sandi Anda, seluruh sistem hilang sementara dengan akun pengguna standar Anda hanya dapat memanipulasi file-file dari pengguna tersebut (yang masih sangat buruk).

Dalam komentar disebutkan bahwa pengguna normal dapat memiliki hak untuk menggunakan sudodan jika kata sandi pengguna ini akan ditebak sistemnya juga hilang sama sekali.

Singkatnya saya akan mengatakan bahwa tidak masalah kata sandi pengguna mana yang didapat penyerang. Ketika mereka menebak satu kata sandi, Anda tidak dapat lagi mempercayai sistem. Seorang penyerang dapat menggunakan hak-hak pengguna itu untuk menjalankan perintah sudo, penyerang juga dapat mengeksploitasi kelemahan dalam sistem Anda dan mendapatkan hak akses root. Jika penyerang memiliki akses ke sistem Anda, Anda tidak bisa mempercayainya lagi.

Yang perlu diingat di sini adalah bahwa setiap pengguna di sistem Anda yang diizinkan masuk melalui SSH adalah kelemahan tambahan. Dengan menonaktifkan root, Anda menghapus satu kelemahan yang jelas.

Mengapa kata sandi lebih dari SSH buruk

Alasan untuk menonaktifkan kata sandi sangat sederhana.

Pengguna memilih kata sandi salah!

Seluruh gagasan mencoba kata sandi hanya berfungsi ketika kata sandi dapat ditebak. Jadi ketika pengguna memiliki kata sandi "pw123" sistem Anda menjadi tidak aman. Masalah lain dengan kata sandi yang dipilih oleh orang adalah bahwa kata sandi mereka tidak pernah benar-benar acak karena itu akan sulit untuk diingat.

Selain itu, pengguna cenderung menggunakan kembali kata sandi mereka, menggunakannya untuk masuk ke Facebook atau akun Gmail mereka dan ke server Anda. Jadi ketika seorang hacker mendapatkan kata sandi akun Facebook pengguna ini, ia bisa masuk ke server Anda. Pengguna dapat dengan mudah kehilangan itu melalui phishing atau server Facebook mungkin diretas.

Tetapi ketika Anda menggunakan sertifikat untuk masuk, pengguna tidak memilih kata sandinya. Sertifikat ini didasarkan pada string acak yang sangat panjang dari 1024 Bit hingga 4096 Bit (~ 128 - 512 karakter kata sandi). Selain itu, sertifikat ini hanya ada untuk masuk ke server Anda dan tidak digunakan dengan layanan luar.

Tautan

http://bsdly.blogspot.de/2013/10/the-hail-mary-cloud-and-lessons-learned.html

Artikel ini berasal dari komentar dan saya ingin memberikannya posisi yang sedikit lebih menonjol, karena masuk sedikit lebih dalam ke masalah botnet yang mencoba masuk melalui SSH, bagaimana mereka melakukannya, bagaimana file log terlihat seperti dan apa yang bisa dilakukan untuk menghentikan mereka. Ini ditulis oleh Peter Hansteen.

— Raphael Ahrens
sumber

10

Ringkasan yang bagus. Tapi kunci pribadi ssh juga bisa dicuri.

— Faheem Mitha

16

@ Faheem Mitha Ya tapi dicuri berbeda dari dugaan, yang dilakukan oleh bot. Juga kunci pribadi Anda hanya ada di tangan Anda (atau hard drive) dan tidak di tangan pihak ketiga seperti Stack Exchange atau Google.

— Raphael Ahrens

2

+1. Jawaban ini sebenarnya bisa dididihkan menjadi sederhana N*M > N. Karena sebagian besar * nix host memiliki rootpengguna, jika Anda mengizinkan root untuk login langsung dari host jarak jauh, ukuran matriks tes adalah jumlah kata sandi yang harus dicoba; tidak mengizinkan login root langsung, jumlah kombinasi yang mungkin dikalikan dengan jumlah nama pengguna yang ingin Anda uji (dan masih belum ada jaminan bahwa Anda akan menguji nama pengguna yang valid!).

— CVn

3

@ MichaelKjörling Saya akan menambahkan bahwa tidak sulit untuk mendapatkan nama pengguna, karena biasanya nama pengguna bukan rahasia dan saya mungkin bisa meminta siapa pun untuk mendapatkannya. Tapi itu membantu melawan Bot dan percobaan sederhana.

— Raphael Ahrens

2

@Setiap orang, jika nama pengguna memiliki simbol X dan kata sandi Y ada # of X length words* # of Y length wordskemungkinan kombinasi untuk dicoba. Ketika nama pengguna sudah diperbaiki (mis. Root) tetapi kata sandinya panjang X + Y, ada # of X+Y length wordskemungkinan kata sandi. Dan # of X+Y length words=# of X length words * # of Y length words

— skarap

10

Ini bisa menjadi beberapa alasan mengapa login root langsung tidak diizinkan.

Upaya bruteforce. Login root langsung dapat mengakibatkan lebih banyak kerusakan pada serangan bruteforce yang berhasil.
Konfigurasi yang salah pada kunci SSH "tanpa kata sandi" (kesalahan manusia terjadi) dapat mengekspos mesin Anda ke internet

Tapi ini hanya TIP gunung es. Anda perlu mengonfigurasi pembatasan dan konfigurasi lain seperti:

Ubah port default (22)
Kata sandi dan frasa sandi yang kuat
Nonaktifkan Otentikasi Berbasis Host
Buat Daftar pengguna yang diizinkan
Konfigurasikan Batas Waktu idle
Paksa protokol SSHv2
Nonaktifkan Kata Sandi Kosong
Gunakan fail2ban sebagai tindakan terhadap bruteforce
Catat semuanya
Konfigurasikan Kunci SSH, dan percaya hanya pada kunci publik di .ssh / authorized_keys

5

"Login root langsung dapat mengakibatkan lebih banyak kerusakan pada serangan bruteforce yang berhasil." Tidak juga, jika dibandingkan dengan sudopengaturan default . Pembunuh sebenarnya adalah efek multiplikasi ketika Anda tidak memiliki satu nama pengguna yang Anda anggap valid pada host mana pun.

— CVn

@ MichaelKjörling - Ya, pasti bahwa sudo yang berantakan bisa sama berbahayanya dengan PermitRoot;)

Lihat unix.stackexchange.com/a/2944/9454

— Monica - M. Schröder

1

Mengubah port sebenarnya merugikan banyak skenario itu sendiri. Dan itu tidak lebih dari keamanan dengan ketidakjelasan juga.

— 0xC0000022L

+1 untuk menyebutkan fail2ban, karena serangan brute force tidak hanya menjadi perhatian bagi SSH, tetapi untuk hal lain pada mesin. Anda tidak perlu mendapatkan izin root atau sistem untuk "mengambil alih" mesin untuk tujuan praktis (akses data pribadi, gunakan sebagai tempat pembuangan file, gunakan untuk phishing, dll.).

— Eric Grange

8

Anda benar bahwa nama pengguna root dan kata sandi simbol X + Y secara kriptografis setidaknya seaman kata sandi simbol nama pengguna + simbol Y. Bahkan itu bahkan lebih aman, karena nama orang mudah ditebak (bot mungkin hanya mencoba john, mike, tagihan, dll ... dan btw: itulah yang banyak dari mereka lakukan daripada mencoba root). Dan Anda terutama kurang beruntung jika itu serangan yang ditargetkan, karena jika seseorang ingin memecahkan server perusahaan itu tidak akan menjadi masalah untuk mengetahui nama (nick) dari sysadmin.

Dan segera setelah penyerang memiliki akses ke akun yang sysadmin gunakan untuk login ssh (dan kemudian menggunakan suatau sudountuk melakukan tugasnya) ia dapat menginfeksi sesi pengguna itu dengan sebuah program yang akan mengirimkan kata sandi root penyerang ketika sysadmin mengetik yang berikutnya waktu.

Ini salah jenis login root yang (atau harus) dianggap praktik buruk dari sudut pandang keamanan. Login pengguna "normal" -> su / sudo chain menambahkan jejak audit. Dalam bahasa Inggris yang sederhana: memungkinkan untuk mengetahui siapa yang melakukan apa.

Kasus khusus mungkin adalah kasusnya, di mana hanya satu orang yang memiliki akses root. Dalam hal menggunakan tambahan "normal" pengguna tidak akan menambah banyak nilai (setidaknya saya tidak pernah bisa melihat nilai itu). Tapi bagaimanapun - Anda seharusnya memiliki pengguna sederhana pada sistem (untuk tugas-tugas non-administratif, menjalankan wget, dll ;-)).

— skarap
sumber

4

Apa yang sangat berbahaya dalam mengaktifkan login root (terutama dengan login password yang dinonaktifkan)?

Penyerang (bot / botnet / hacker) hanya perlu menebak kata sandi dan memiliki kendali penuh atas sistem Anda, jika Anda terbuka untuk internet. Selain itu, tidak ada akun sistem (www-data, proksi, dll.) Yang dapat masuk melalui SSH, karena alasan yang sama.

Jika Anda menonaktifkan login kata sandi (menggunakan kunci publik, misalnya), pertimbangkan bahwa siapa pun yang memegang kunci privat mendapatkan kendali penuh atas sistem Anda. Lihat mengapa menggunakan kunci publik dengan pengguna lebih baik di bawah ini.

Dan apa perbedaan antara nama pengguna simbol X dan kata sandi simbol Y atau nama pengguna root dan kata sandi simbol X + Y dari sudut pandang keamanan jika otentikasi kata sandi dibolehkan?

Nama pengguna tambahan dapat menambahkan lapisan keamanan karena: a) penyerang harus mengetahui pasangan, nama pengguna dan kata sandi; b) dalam hal penyerang melanggar sistem Anda, itu tidak akan memiliki akses langsung ke akun istimewa menambahkan sedikit nuansa bagi penyerang.

Dalam hal ini kunci publik juga merupakan nilai tambah, karena:

Penyerang membutuhkan kunci publik Anda
Penyerang membutuhkan kata sandi (atau metode otentikasi) untuk mendapatkan hak istimewa yang lebih tinggi

— Braiam
sumber

1

Sangat sedikit kata sandi yang saya gunakan kurang dari sekitar 20 karakter alfanumerik acak (set [A-Za-z0-9] ditambah beberapa karakter khusus). 20 karakter tersebut (jadi panjang 20 dari 40 karakter) memberi Anda urutan 10 ^ 32 kombinasi. 128 bit entropi ada di urutan 10 ^ 38. Bukan perbedaan besar, semua hal dipertimbangkan, dan server SSH bebas untuk menerapkan segala jenis pembatasan yang disukai sehingga tidak seperti Anda melakukan serangan brute force offline dalam kasus itu. Tidak ada yang salah dengan kata sandi, jika Anda dapat hidup dengan kata sandi yang sulit untuk diingat sebagai kunci 128-bit.

— CVn

@michael shh ... tidak memberikan jangkauan, sekarang peretas tahu bahwa mereka harus menggunakan tabel pelangi dengan urutan 20 karakter panjang ...?

— Braiam

6

@Braiam Rainbow tables hanya berguna jika penyerang memiliki akses ke hash untuk melakukan pencarian offline. Dalam kasus di sini, penyerang hanya memiliki respons server untuk memverifikasi, yang kemungkinan hanya terbatas pada begitu banyak upaya - dan jauh lebih lambat.

— Peter

@Peter up, saya mengacaukan kamus dan hash, tetapi bagaimanapun OP bertanya mengapa dia tidak boleh menggunakan kata sandi yang lemah atau kosong, penyihir itu konyol, karena itu saya datang dengan situasi konyol mengapa dia tidak boleh. Maaf saya tidak ditafsirkan seperti itu dan dianggap FUD.

— Braiam

2

Jika Anda merasa ingin mencoba beberapa kata sandi 1,8 * 10 ^ 35 (dan itu hanya untuk rentang 18-22 karakter acak dari 40, dan Anda tidak tahu karakter mana di luar rangkaian [A-Za-z0- 9] Saya menggunakan), saya hampir mengatakan bersenang-senang. Itu tentang 117.1 bit setara entropi (2 ^ 117.1 ~ 1.78 * 10 ^ 35) dan seperti yang ditunjukkan @Peter, Anda kemungkinan besar perlu melakukan serangan online . Menyimpan semua kata sandi tersebut (tanpa menggunakan kompresi) muncul sebagai membutuhkan sekitar 3,6 * 10 ^ 36 byte atau 3 * 10 ^ 24 TiB (dan jika angka itu salah oleh beberapa perintah besar, siapa yang peduli? ). Kata kunci acak .

— CVn

1

Ini tidak terlalu buruk selama Anda mengambil tindakan pencegahan keamanan. Sebagai contoh, Anda dapat menginstal CSF (Configure Server Firewall) dan mengaturnya jumlah upaya kegagalan yang diizinkan, jadi jika seseorang mencoba, katakanlah lebih dari 5 upaya kegagalan ?, maka mereka secara otomatis diblokir. Jadi seluruh bagian pertama dari penjawab terbaik tidak akan menjadi masalah sama sekali. Ini terjadi pada saya berkali-kali, dan untungnya semua pengantar diblokir secara permanen. Saya kira untuk server itu bukan masalah besar jika Anda adalah satu-satunya orang yang mengelola server, tetapi tentu saja jika ada banyak admin sistem, atau jika Anda bekerja di suatu organisasi, maka jelas tidak menggunakan akar. Juga untuk PC desktop, saya kira menggunakan akun lain lebih baik karena ada risiko keamanan karena Anda menggunakan banyak perangkat lunak, tetapi di server, Anda tidak Untuk menggunakan perangkat lunak acak yang tidak Anda percayai, pastikan Anda menyimpannya serendah mungkin. Jadi kesimpulannya adalah, Tidak, itu tidak benar-benar berbahaya jika Anda tahu cara mengelola server dengan benar.

— Don Dilanga
sumber