SSH, atau Secure SHell, menggantikan Telnet di suatu tempat di tahun 1990-an sebagai protokol akses jarak jauh pilihan, dan untuk alasan yang baik. SSH memungkinkan administrator—atau pengguna—untuk mengakses shell jarak jauh melalui terowongan yang aman, dengan menghubungkan klien SSH mereka ke server SSH. SSH juga dapat menangani transfer file, yang seharusnya menggantikan FTP, meskipun ada sejumlah situasi yang mengejutkan yang masih mengandalkan FTP teks lama yang jelas.
Mengapa? Ugh.
Untuk alasan di atas, sistem Linux modern dikelola melalui SSH. Sebagian besar sysadmin berpengalaman menyukai akses langsung dan kekuatan yang mereka dapatkan dari menghubungkan secara aman ke shell sistem mereka dengan relatif mudah. Pada artikel ini, saya akan berbicara secara khusus tentang daemon server OpenSSH, sshd . Kami akan membahas beberapa masalah keamanan yang mungkin Anda alami, dan cara mengurangi—atau langsung menyelesaikannya—.
Mengapa kita membutuhkan SSH
Seperti yang saya sebutkan, SSH adalah alat yang ampuh. Melalui sesi SSH, Anda dapat menghubungkan terminal virtual langsung ke sistem target Anda. Di tangan yang salah, kemampuan ini bisa menjadi masalah, jadi mengapa kita membiarkan kekuatan seperti itu dapat diakses? Nah, kekuatan SSH melibatkan keseimbangan yang rumit. Dalam beberapa menit, administrator dapat membuka sesi aman ke server mereka untuk menanggapi insiden. Kesederhanaan itu elegan.
SSH juga merupakan inti dari alat otomatisasi seperti Ansible. Ansible dapat menerapkan perubahan ke sistem melalui SSH tanpa memerlukan agen. Semua perubahan dilakukan, sebagai gantinya, menggunakan SSH dan Python.
SSH juga dapat digunakan, seperti yang saya sebutkan, untuk transfer file yang aman. Misalnya, rsync terowongan melalui SSH untuk sinkronisasi data yang aman. SSH juga dapat digunakan untuk melakukan tunnel melalui satu sistem ke sistem lain, yang sangat bagus untuk pemecahan masalah, tetapi juga bagus untuk penyerang.
Jika paragraf sebelumnya tidak meyakinkan Anda, saya akan mengatakan ini lagi:SSH adalah alat yang ampuh, dan seperti alat yang kuat lainnya, itu dapat disalahgunakan. Jika penyerang bisa mendapatkan shell aman ke dalam sistem Anda, permainan berakhir. Dan penyerang mengetahui hal ini, jadi mereka terus-menerus mencari sistem dengan SSH yang terbuka untuk dunia agar mereka dapat menyerang.
Kunci SSH
Serangan tunggal yang paling umum terhadap SSH adalah brute force. Pada sistem saya, saya pribadi tidak pernah berhasil melakukan serangan brute force terhadap SSH. Namun, sebelum saya mulai mengikuti aturan penguncian sederhana, saya dapat memberi tahu Anda bahwa mereka pasti mencobanya.
Pencarian cepat di Shodan—mesin pencari yang menargetkan perangkat yang terhubung ke Internet—menunjukkan 20.984.090 sistem dengan SSH terbuka untuk dunia. Apakah mereka perlu diatur dengan cara ini? Saya hampir dapat menjamin Anda bahwa setiap sistem tersebut menerima beberapa serangan brute force SSH per detik. Saat saya menulis artikel ini, saya memulai sebuah droplet di Digital Ocean, membiarkan SSH terbuka untuk dunia, dan membuntuti /var/log/secure . Dalam waktu sekitar 20 menit, saya melihat probe SSH pertama. Dalam satu jam, banjir serangan brute force dimulai.
Jun 23 01:35:33 centos-s-1vcpu-1gb-sgp1-01 sshd[10926]: Did not
receive identification string from 81.22.45.137 port 61000
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]: Invalid
user fake from 104.248.132.25 port 36050
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]:
input_userauth_request: invalid user fake [preauth]
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]: Received
disconnect from 104.248.132.25 port 36050:11: Bye Bye [preauth]
Singkatnya, kata sandi yang buruk pada sshd default instalasi bisa menjadi semua yang berdiri di antara orang-orang jahat dan sistem Anda. Meskipun konfigurasi default untuk OpenSSH cukup aman, konfigurasi tersebut dapat dikeraskan. Beruntung bagi Anda, saya punya saran.
Batasi akses ke port 22
Mulailah dengan memeriksa untuk melihat apakah port SSH default (port 22) terbuka untuk dunia. Anda dapat melakukannya dengan menjalankan Nmap, yang akan menyelidiki jaringan Anda sesuai dengan spesifikasi Anda:
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-22 20:56 EDT
Nmap scan report for 167.71.200.117
Host is up (0.26s latency).
Not shown: 995 closed ports
PORT STATE SERVICE
22/tcp open ssh Mempersempit siapa yang dapat mengakses port 22 adalah hal paling dasar yang dapat Anda lakukan untuk mengamankan sistem Anda. Saya menyadari bahwa taktik ini mungkin tidak berhasil untuk setiap skenario. Mungkin Anda menjalankan sistem penggunaan publik, atau mungkin CIO sering bepergian dan mungkin mengakses sistem dari banyak tempat berbeda (kita akan membicarakan VPN sebentar lagi). Maksud saya adalah Anda mungkin memiliki alasan yang sah bahwa SSH benar-benar perlu dibuka untuk masyarakat umum. Pikirkan sangat sulit untuk menghindari konfigurasi itu. Saya sudah melakukannya, tetapi kebanyakan karena kemalasan. Biasanya ada cara yang lebih baik.
Jika Anda menggunakan penyedia cloud, konfigurasikan grup keamanan untuk hanya menerima lalu lintas SSH dari jaringan tempat Anda bekerja. Tugas ini seharusnya sederhana jika Anda mengakses penyedia ini dari lingkungan perusahaan. Anda mungkin memiliki rentang alamat IP sendiri, yang berarti Anda dapat memasukkannya ke daftar putih dan memblokir yang lainnya. Namun, jika Anda mengakses penyedia cloud dari rumah, Anda mungkin harus melakukan beberapa trik untuk memasukkan blok IP yang dialokasikan secara dinamis ke daftar putih ISP Anda. Menggunakan grup keamanan akan memungkinkan Anda mengubah rentang alamat IP melalui portal layanan mandiri penyedia cloud jika diperlukan.
Jika Anda menghosting sistem yang tidak berada di belakang firewall, gunakan firewall berbasis host untuk memblokir port 22 dari mana saja kecuali rentang alamat IP Anda, menggunakan metode yang sama yang baru saja saya jelaskan. Masalahnya, tentu saja, jika Anda terkunci karena alamat IP Anda berubah, Anda akan kesulitan melakukan perubahan yang diperlukan.
Dan jangan lupa bahwa ada manfaat untuk lingkungan perusahaan. Jika server Anda berada di jaringan perusahaan, ada kemungkinan besar ada firewall jaringan yang dapat Anda gunakan untuk mengunci akses SSH, jadi gunakan fakta itu untuk keuntungan Anda. Pertahanan secara mendalam, semuanya!
Memerlukan VPN untuk akses jarak jauh
Oke, jadi mari kita bicara tentang CIO bepergian yang benar-benar membutuhkan akses ke ssh dari kamar hotel. Solusinya tampak jelas bagi kita yang telah berada di sekitar blok, tetapi jika Anda mempertimbangkan untuk membuka akses SSH ke seluruh dunia, mungkin Anda perlu mendengar ini:VPN, atau Virtual Private Network, memungkinkan Anda membangun terowongan terenkripsi dari titik akhir—seperti laptop CIO Anda di hotel di Maui—kembali ke jaringan perusahaan Anda di Seattle. Koneksi ini dilindungi dengan caranya sendiri, dan dienkripsi.
Namun, lusinan server Anda yang tidak dapat diakses oleh dunia dapat diakses melalui satu titik ini. Ya, praktik ini mengalihkan target serangan ke VPN, tetapi itu berarti ada satu rintangan lagi yang harus dilalui oleh penjahat.
Tolak akses root
Sekarang kita beralih ke sshd yang sebenarnya konfigurasi. Daemon OpenSSH memiliki opsi yang disebut PermitRootLogin . Secara default, opsi ini disetel ke Yes , karena ketika Anda menginstal beberapa sistem, hanya root yang ada pada awalnya. Ketika situasi ini terjadi, Anda memerlukan akun root untuk mengakses sistem dan melakukan konfigurasi awal.
Saya sarankan menambahkan pengguna selama proses instalasi, atau sebagai bagian dari gambar emas Anda, dan mematikan login root sejak awal. Tidak ada alasan untuk masuk sebagai root, dan tentu saja tidak ada alasan untuk masuk sebagai root melalui SSH. Jadi, ubah baris konfigurasi menjadi:
PermitRootLogin no Terapkan otentikasi berbasis kunci
Awalnya, saya menggunakan otentikasi berbasis kunci sebagai kemudahan. Saya membuat kunci pribadi, menambahkan kunci publik ke authorized_keys saya file di server yang saya kelola, dan kemudian dapat terhubung dengan aman ke sistem saya tanpa kata sandi. Melakukan hal ini menghemat waktu, dan memungkinkan otomatisasi. MENANG! Baru kemudian saya menemukan bahwa otentikasi berbasis kunci SSH dapat dimanfaatkan untuk menghilangkan upaya paksa kata sandi.
Untuk membuat kunci, jalankan ssh-keygen pada kotak Mac atau Linux. Mungkin Anda orang Windows dapat melakukan ini secara asli sekarang, tetapi pada mesin Windows, saya selalu menggunakan PuTTYGen (dan kemudian menggunakan kunci dengan klien Putty). Anda akan dimintai jenis kunci, dan panjangnya. Saya telah membuat kunci RSA 4096 bit akhir-akhir ini. Semakin banyak bit, semakin sulit kuncinya untuk dipecahkan. Jadi mengapa tidak?
[gangrif@meliodas ~]$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/gangrif/.ssh/id_rsa): ./test-key
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ./test-key.
Your public key has been saved in ./test-key.pub.
The key fingerprint is:
SHA256:xfHOf4t3V3CCkJ+3FbEnQusAjBwOjBXfOa9WdGXBMqc [email protected]
The key's randomart image is:
+---[RSA 4096]----+
| ++o.+. ....+o.|
| . .+o..+o+o+o..|
| o + =o=B..o|
| = *E.+.+|
| S o +. * |
| o .. .|
| o . o|
| . .o+|
| ...o|
+----[SHA256]-----+
Apa yang Anda dapatkan adalah file baru bernama test-key (dalam hal ini), dan test-key.pub . Kunci di test-key adalah kunci pribadi saya, dan test-key.pub berisi kunci publik. Lindungi kunci pribadi dengan hidup Anda. Anda dapat membiarkan kunci publik tergeletak di mana pun Anda mau, karena tidak ada gunanya tanpa kunci pribadi.
[gangrif@meliodas ~]$ cat test-key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDAQxmjoHO6i4Kkq8vp49KtqAsMcw+ptgvd+PGjxVYkDPGdzRZpJhq0c3BDstFs86ENlojs61zZaP3MihLR0BlDdIyM3jh9TmVvmOPiylhu4X9QliAca/ODxyVp76OpTKm+QcgBi/7i/JNiJdEgcSy8izB0Oil7LZjIhS6wCs3mQFVbkPXPfe1lmHQIcuMDOKO0RuyecY/lrKodcr/YbEE4GsM/P11QdDPZ78lq83G3H5vqLqMrxVKkLw7Z4//+PZPFFxi/N1EBwBp/uPEo4MfD1IwSmnKromRlkYTdOYlbiCNosdvEobtMARySdqjv7RDn0Iwb3JxioUW6jQdAXfl8d01LvX/0Yb1tq5hF44ahwvI6TyoB4z3DRs+3cFiMPWQR7LK8/qQOvHk5I2NMBAV9KuSN2ML0d7xeB8tglw38PYjhZsXl/t2rAWT4n8PU0o6+Hrrli+WEfvk8QWpLesmBBmzG0sLjH0mXBU/xN4UBLLJNlrsUQ/TzEsdknntMhh7leOzechlU3PiTNuUitweT9NqLJwCP+CHbeSJn2M5qzb090CPnCGpnr2GOfm2dL+RfHQi2R1Cf04nBDq3WuhAPJY5SoEw2llfSgA2GlOdhcY9N9Bl9rLUBPgQ6ttBd7qZJ6E3BkiPlHnU+kSSpYr8Gkw1oDGbtd2UUjExZqvz4rQ== [email protected]
Pada mesin yang ingin Anda sambungkan tanpa menggunakan kata sandi, salin kunci publik ke .ssh/authorized_keys (atau minta pengguna melakukannya, tergantung situasinya). Sekarang, saya katakan tanpa kata sandi, tetapi Anda masih perlu membuka kunci pribadi dengan kata sandi yang Anda tetapkan selama pembuatan. Anda telah menetapkan kata sandi, bukan?
Anda juga dapat menyalin kunci ini dari jarak jauh ke server menggunakan ssh-copy-id .
Nonaktifkan otentikasi berbasis kata sandi
Ingat ketika saya mengatakan bahwa otentikasi berbasis kunci membuka kemungkinan mengunci upaya brute force SSH sepenuhnya? Nah begini caranya. Dengan kunci pribadi dan publik Anda di tempat, SSH tidak meminta kata sandi lagi, bukan? Jadi mengapa membiarkan jalan itu terbuka sebagai vektor serangan?
Di setiap server Linux yang saya jalankan, saya menambahkan kunci publik saya sebagai bagian dari instalasi dasar kami, dan saya mematikan otentikasi kata sandi SSH bahkan sebelum sistem mencapai jaringan. Ini adalah pengaturan tepat di sshd file konfigurasi . Sekali lagi, pengaturan default memungkinkan otentikasi kata sandi, karena fitur itu harus berfungsi untuk konfigurasi. Namun, setelah Anda memiliki kunci, matikan.
PasswordAuthentication no Selamat, Anda sekarang kebal terhadap serangan brute force password.
Jail pengguna SSH, dengan chroot
chroot —biasanya diucapkan “chi-root”, atau “ch-root”—perintah adalah alat yang rapi. Ini memungkinkan Anda mengubah direktori root yang dilihat oleh suatu proses dan anak-anaknya, oleh karena itu namanya. Ini bagus untuk memecahkan masalah sistem tempat Anda dapat mengakses disk, tetapi tidak bisa boot. Anda cukup memasang disk dan chroot ke /mnt/whatever.
Ini juga merupakan alat keamanan yang rapi untuk sesuatu seperti server shell. Anda dapat melakukan chroot pengguna saat login, sehingga mereka benar-benar tidak dapat melihat sistem file lainnya. Saya tidak sering melakukan ini, tetapi ini adalah penjara yang sangat layak bagi pengguna. Saya menemukan apa yang tampak sebagai tulisan yang layak di sini.
Rotasi
Layak untuk mempertimbangkan kata sandi dan rotasi kunci ssh. Saya akan mencoba menguraikan yang baik dan yang buruk di sini.
Kebijakan Sandi dan Rotasi
Saya akan menggabungkan kebijakan kata sandi dengan rotasi kata sandi karena mereka terkait. Kebijakan kata sandi yang menerapkan kerumitan adalah cara yang bagus untuk membuat pengguna Anda memilih kata sandi yang "kuat". Namun, ini memiliki beberapa peringatan, terutama jika digabungkan dengan kedaluwarsa kata sandi yang berubah-ubah (yaitu waktunya). Saya dapat menulis seluruh artikel tentang perasaan saya tentang kebijakan dan rotasi kata sandi, tetapi saya akan mencoba membuatnya singkat di sini.
Tahun lalu, NIST melakukan sesuatu tentang pedoman kata sandi mereka, mengubah beberapa saran mereka yang telah tertanam di sebagian besar pikiran kita untuk sebagian besar karier kita. Komunitas Infosec (yang saya coba-coba) telah menyarankan selama bertahun-tahun, kata sandi acak 8 karakter, atau panjang minimum 8 karakter dengan aturan kompleksitas yang ketat, berbuat lebih banyak untuk membahayakan kebersihan kata sandi daripada membantunya. Gabungkan aturan kerumitan yang ketat dengan kebijakan rotasi kata sandi 3-6 bulan, dan Anda membuat pengguna Anda frustrasi. Frustrasi itu mengarah pada penggunaan kembali kata sandi dan kebiasaan buruk lainnya. Jadi pikirkan baik-baik apakah Anda ingin memaksakan ini pada pengguna Anda. Rekomendasi baru cenderung kedaluwarsa hanya ketika pelanggaran atau kompromi dicurigai, dan kebijakan yang mengarahkan pengguna Anda ke frasa sandi yang kuat daripada sandi. “Ini adalah p@ssw0rd 2019 saya.” jauh lebih sulit ditebak, dan dipecahkan, daripada "W1nt3r2019". Omong-omong, yang merupakan tujuan umum untuk pembuat kata sandi, dan tim merah. Namun perlu diingat, jika Anda meminta admin cerdas untuk merotasi kata sandi mereka, Anda mungkin tidak mengalami masalah ini (karena mereka mengerti MENGAPA mereka melakukannya, dan betapa pentingnya itu). Namun bagi pengguna Anda pada umumnya, kedaluwarsa yang sewenang-wenang dan "kata sandi" yang rumit sudah menjadi sesuatu dari masa lalu.
Rotasi Kunci Pribadi SSH
Seperti pengidentifikasi apa pun yang dapat dibuat, sebaiknya pertimbangkan untuk merotasi kunci pribadi Anda secara berkala. Kunci pribadi Anda tidak semudah untuk dicuri atau ditebak seperti kata sandi, tetapi ada kemungkinan bahwa seseorang mengambil kunci Anda tanpa sepengetahuan Anda. Ini masuk ke wilayah "seberapa paranoid Anda ingin menjadi". Mengubah kata sandi pada kunci pribadi Anda tidak cukup baik. Kata sandi itu membuka kunci itu, jika saya menggesek kunci Anda hari ini, dan Anda mengubah kata sandi Anda besok, salin jika kunci Anda yang saya miliki masih memiliki kata sandi lama Anda. Jika Anda akan melakukan ini dengan benar, Anda perlu membuat kunci yang sama sekali baru. Sekarang adalah waktu yang tepat untuk membuat panjang kunci lebih panjang jika standar telah naik sejak Anda terakhir kali membuat kunci. Mungkin Anda membuat kunci baru setiap kali majikan Anda mengeluarkan laptop baru untuk Anda, mungkin Anda melakukannya setahun sekali pada hari jadi kerja Anda. Saya belum menemukan solusi yang akan mengelola ini untuk Anda.
Ingatlah, bahwa membuat kunci baru berarti semua kunci publik yang Anda miliki di dunia sekarang tidak valid. Atau setidaknya mereka tidak valid dengan kunci baru Anda. Anda mungkin perlu menggunakan kunci lama Anda, untuk menempatkan kunci publik baru Anda.
MFA
Otentikasi multi faktor menjadi norma. Beberapa orang telah mencoba mengklaim bahwa kunci SSH adalah bentuk MFA, mereka sebenarnya tidak. Terutama jika Anda telah menonaktifkan otentikasi kata sandi. Namun Anda dapat mengintegrasikan mfa seperti TOTP, atau YubiKey ke dalam konfigurasi PAM sistem Anda. Solusi autentikasi pusat seperti FreeIPA membuatnya mudah.
Kesimpulan
Jadi begitulah, saya harap Anda mengambil informasi ini dan menerapkannya ke sistem Anda untuk meningkatkan keamanan Anda. Jangan menjadi salah satu dari 21 juta sistem dengan SSH yang terbuka untuk dunia. Tidak ada alasan untuk itu.
Terima kasih telah membaca!
Artikel ini awalnya diterbitkan di Undrground.org. Diterbitkan ulang dengan izin.