Jawaban:
Ini tidak berguna seperti yang diklaim beberapa orang, tetapi setidaknya akan mengurangi dampak pada file log Anda karena banyak upaya login brute force hanya menggunakan port default daripada memindai untuk melihat apakah SSH mendengarkan di tempat lain. Beberapa serangan akan memindai SSH di tempat lain, jadi itu bukan peluru perak.
Jika server Anda akan menjadi semacam host bersama, alih-alih hanya melayani kebutuhan proyek Anda, menggunakan port non-standar bisa menyusahkan karena Anda harus menjelaskannya kepada pengguna Anda berulang-ulang dan berakhir ketika mereka lupa dan program klien mereka gagal terhubung ke port 22!
Masalah lain yang mungkin terjadi dengan SSH pada port non-standar adalah jika Anda menjumpai klien dengan set filter keluar terbatas, yang tidak dapat terhubung ke port khusus Anda karena filter mereka hanya memungkinkan, misalnya, port 22, 53, 80 dan 443 menjadi tujuan untuk koneksi keluar baru. Ini tidak biasa, tetapi tentu saja tidak pernah terdengar. Pada masalah yang sama, beberapa ISP mungkin melihat lalu lintas terenkripsi pada port selain yang biasanya diharapkan (port 443 atau HTTPS, 22 untuk SSH, dan sebagainya) sebagai upaya untuk menyembunyikan koneksi P2P dan throttle (atau blokir) koneksi dengan cara yang tidak nyaman.
Saya pribadi menjaga SSH pada port standar untuk kenyamanan. Selama tindakan pencegahan biasa dilakukan (kata sandi / kunci kebijakan yang kuat, membatasi login root, ...) itu tidak perlu menjadi masalah dan masalah pertumbuhan file log ketika Anda terkena serangan brute force dapat dikurangi dengan menggunakan alat seperti sebagai fial2ban untuk sementara memblokir host yang memberikan terlalu banyak set kredensial autentikasi dalam ruang waktu tertentu.
Apapun port yang Anda pilih, jika Anda pindah dari 22, pastikan itu di bawah 1024. Di bawah sebagian besar pengaturan Unix-a-like di konfigurasi default mereka, hanya root (atau pengguna dalam grup root) yang dapat mendengarkan pada port di bawah 1024, tetapi setiap pengguna dapat mendengarkan pada port yang lebih tinggi. Menjalankan SSH pada port yang lebih tinggi meningkatkan kemungkinan pengguna jahat (atau diretas) yang mengelola crash daemon SSH Anda dan menggantinya dengan proxy mereka sendiri.
Ini adalah bentuk keamanan yang sederhana (namun sangat efektif) melalui ketidakjelasan .
Jika server SSH Anda tidak ada di port 22, kemungkinan besar itu akan ditemukan oleh mereka yang memindai seluruh internet mencari kata sandi yang lemah pada akun default. Jika Anda memindai seluruh jaringan, Anda tidak dapat memeriksa semua port 64k yang mungkin untuk menemukan server SSH.
Namun, jika seseorang secara aktif menargetkan Anda secara spesifik, itu tidak memberikan manfaat, karena nmappemindaian satu kali saja akan mengungkapkan port tempat ia sebenarnya berjalan.
Untuk benar-benar menghindari serangan bruteforce, selalu penting untuk mengikuti beberapa langkah:
Ya itu berguna karena hanya membantu menghindari semua serangan brute force dan membantu menjaga log tetap bersih :)
Adapun nomor port yang terserah Anda, saya telah melihat perusahaan menggunakan 1291 cukup sering. Saya menggunakan sesuatu yang lebih tinggi meskipun hanya untuk membantu menghindari beberapa skrip.
Tidak mengizinkan login ssh root dan mengubah nomor port dan mungkin sesuatu seperti fail2ban dan Anda harus menjadi emas. tambahkan iptables untuk ukuran yang baik dan terus perbarui informasi Anda dan Anda tidak akan memiliki masalah apa pun.
Menggunakan port ssh yang tidak standar akan membutuhkan lebih banyak penjelasan dan dokumentasi, dan menjawab email "Saya tidak bisa masuk".
Saya menganggap manfaat menjalankan sshd berikut pada port non-standar lebih penting daripada masalah yang diciptakannya:
Selain itu, jika Anda ingin benar-benar jahat, Anda selalu dapat menjalankan sshd palsu (dengan DenyUsers * ) pada port standar 22, sementara sshd reguler Anda berjalan pada port 54321. Ini akan memastikan Anda bahwa semua bot dan penyusup-wannabes akan selamanya cobalah masuk ke layanan yang menolak semua login, karena tidak seorang pun akan berpikir untuk mencoba menemukan layanan sshd Anda yang sebenarnya .
2 sen saya.
Melakukan ini untuk alasan "keamanan" apa pun adalah palsu. Ini adalah contoh terbaik keamanan oleh ketidakjelasan yang bukan keamanan.
Jika Anda ingin membuat log Anda sedikit lebih ringan dan bersih, maka ya ini berguna karena Anda tidak akan mendapatkan sebanyak mungkin upaya bruteforce port knocking / script-kiddy.
Karena ada banyak orang jahat di luar sana yang memindai semua IP server untuk port terbuka dalam upaya untuk mengeksploitasi. Saya pernah mengalami serangan palu pada port SSH saya sepanjang hari sampai saya memindahkannya ke port lain dan pada IP yang tidak terhubung ke situs web saya lagi.
Ini berguna karena skrip-bot yang mencoba serangan tebak-tebakan pada umumnya berfokus pada Port 22, jadi mengubah port biasanya membuangnya. Anda harus menyeimbangkan nilai memitigasi risiko itu dengan rasa sakit saat mengonfigurasi ssh klien untuk terhubung ke port non-standar (tidak terlalu besar jika Anda tidak memiliki banyak pengguna yang terhubung, diakui).
Sebagai alternatif, Anda dapat mengurangi risiko brute-force dengan mematikan otentikasi kata sandi dan memerlukan otentikasi kunci-RSA sebagai gantinya.
Saya biasanya tidak mengubah port pada SSHD, jadi saya tidak dapat menyarankan nomor lain, tetapi periksa daftar port yang biasa digunakan untuk menemukan nomor lain (yaitu yang tidak digunakan oleh hal lain, dan dengan demikian mungkin dipindai) .
Saya selalu mengubah SSHd saya untuk menggunakan port 2222, semua orang yang perlu masuk ke server saya tahu ini dan itu bukan rahasia. Sama sekali tidak ada keuntungan keamanan dengan melakukan ini (kecuali jika calon peretas adalah orang tolol).
Satu-satunya manfaat yang saya dapatkan dari ini adalah bahwa auth log tidak memiliki sejuta upaya login gagal untuk 'root', 'alice', 'bob', 'sally', 'admin', dll.
Keamanan melalui ketidakjelasan telah terbukti tidak berguna, biasanya saya mengkonfigurasi akses ssh dengan port standar untuk semua alasan yang disebutkan di atas (masalah klien dalam konfigurasi ulang, firewall dan masalah proxy, dll).
Selain itu saya selalu menonaktifkan login root dan otentikasi kata sandi dan sebagai langkah terakhir saya menggunakan fail2ban untuk menyingkirkan pesan-pesan yang mengganggu di syslog. Di Debian / Ubuntu itu sesederhana mengetik aptitude install fail2ban. Konfigurasi default berfungsi dengan baik, tetapi saya biasanya menyetel beberapa parameter agar lebih membatasi memiliki waktu larangan yang lebih lama (setidaknya satu hari) dan hanya 2 upaya otentikasi yang gagal sebagai pemicu untuk larangan tersebut.
Saya akan mengatakan bahwa hal yang paling Anda lindungi saat mengubah port SSH adalah pemindaian otomatis yang akan mencoba dan mendapatkan akses menggunakan nama pengguna / kata sandi standar, jika kebijakan kata sandi Anda ketat, Anda tidak perlu khawatir tentang mereka.
Jika Anda menonaktifkan login kata sandi ke server Anda (yang sangat disarankan), maka mengubah port SSH sama sekali tidak berguna. Dengan menonaktifkan kata sandi login (dan memerlukan otentikasi berbasis kunci), Anda menghapus kemungkinan upaya kata sandi brute-force, sehingga Anda tidak mendapatkan apa-apa dengan mencari-cari nomor port.
Jika Anda terus mengizinkan otentikasi basis kata sandi, maka Anda membiarkan diri Anda terbuka terhadap kemungkinan upaya brute force yang berhasil atau - lebih umum, dalam pengalaman saya - kata sandi Anda dikompromikan karena Anda mengetiknya saat menggunakan sistem yang berjalan seorang keylogger.
man ssh-keygenbanyak info.
Bukan jawaban tetapi terlalu lama untuk komentar, jadi saya akan membuat CW ini.
Saya sudah memikirkan hal ini sebentar dan sampai pada kesimpulan bahwa ada banyak kebenaran dalam apa yang dikatakan Juliano dalam komentar atas jawaban Alnitak. Namun demikian, saya menemukan bahwa dengan menjalankan SSH pada port 22 hanya membuatnya terlalu mudah untuk meluncurkan serangan apa pun terhadapnya.
Untuk mengatasi masalah ini, saya menjalankan server SSH internal saya pada port 22 dan menggunakan firewall untuk mem-forward port tinggi ke 22 pada mesin target. Ini memberikan keamanan melalui ketidakjelasan sambil mempertahankan keamanan port rendah, seperti yang ditunjukkan Juliano.
Keamanan melalui ketidakjelasan bukanlah prinsip yang biasanya saya langgani dan sering ditunjukkan bahwa pemindaian port sederhana akan mengungkapkan port target, membuat ketidakjelasan itu tidak berharga. Untuk mengatasi masalah itu firewall saya (Smoothwall Express), baik di kantor maupun di rumah, gunakan skrip bernama Guardian Active Response, yang dipicu oleh peringatan Snort. Dari pengamatan saya dapat memberitahu Anda bahwa ketika Anda menekan lebih dari 3 port berbeda dari sumber yang sama paket Anda dijatuhkan sampai waktu reset yang telah ditetapkan. Ini membuatnya agak sulit dan sangat memakan waktu untuk menjalankan pemindaian port, membuat ketidakjelasan itu benar-benar berharga. Kenyataannya ini menyebabkan saya sering keluar dari jaringan sehingga saya menetapkan pengecualian untuk alamat IP sumber saya (rumah atau kantor).
Masalah yang Anda miliki adalah bahwa firewall diatur untuk hanya mengizinkan IP tertentu untuk terhubung, dan bos sudah bosan membuka IP tertentu ketika dia keluar dan sekitar. Jika Anda mengunci IP tertentu di firewall, itu bisa menyebalkan.
Dua hal yang saya pikirkan di sini. Mengubah port melindungi terhadap serangan otomatis. Itu tentang hal itu, tetapi itu adalah bagian besar dari lalu lintas serangan rata-rata di luar sana ... jaringan pemindaian skrip otomatis. Jika Anda mengubah port default, serangan-serangan itu akan langsung gagal. Jadi masuk akal dalam hal itu. Tapi itu tidak melakukan apa-apa terhadap serangan terarah, karena penyerang hanya dapat memindai dari Nessus atau NMAP untuk menentukan port apa yang Anda gunakan jika Anda memiliki teman kecil khusus yang cukup membenci Anda.
Kedua, jika Anda menggunakan server mirip UNIX, Anda dapat menginstal utilitas seperti Denyhosts untuk menghentikan serangan. Jika Anda menginstal denyhosts, ia memantau upaya login yang salah dan setelah (apa pun yang Anda tentukan jumlahnya) upaya gagal itu akan mencekal IP untuk periode waktu yang Anda tentukan. Denyhosts juga dapat berbicara dengan host penolakanhost lain dan meneruskan daftar larangan, jadi jika seorang penyerang terkunci dari sistem Linux Fred di Montana, sistem Anda juga akan mendapatkan IP tersebut untuk dicekal. Sangat berguna selama pengguna Anda mengingat kata sandi mereka.
Itu semua tergantung pada skenario penggunaan Anda. Berapa banyak program yang Anda miliki yang merupakan "rasa sakit" untuk mengubah port koneksi untuk SSH / SCP (dan jika mereka tidak mengizinkannya atau membuatnya sakit, Anda benar-benar perlu mempertimbangkan untuk mengganti vendor, secara pribadi). Jika itu hanya potensi ketakutan, saya akan mengatakan itu bukan masalah. Dan ini bos Anda, meminta sesuatu yang tidak sepenuhnya aneh karena banyak sysadmin yang membalik port SSH (dengan beberapa kritik dari orang-orang yang membenci apa pun yang berbau keamanan bahkan samar-samar melalui ketidakjelasan ... tapi itu benar-benar mengurangi kebisingan latar belakang kasar dari pemindaian otomatis.)
Rebus - mengubah port memblokir skrip otomatis dan sebagian besar lalu lintas buruk. Tidak akan menghentikan penyerang yang diarahkan. Pertimbangkan juga menginstal utilitas pelarangan otomatis. Keamanan berlapis-lapis tidak melukai Anda jika dilakukan dengan benar dan mengubah port membantu lebih daripada yang menyakitkan di sebagian besar situasi.
Saya telah menjalankan SSH pada port> 1024 selama lebih dari 5 tahun sekarang. Sejak itu, saya tidak melihat adanya upaya portscan di file log saya (kecuali dari diri saya sendiri). Ada server saya yang saya admin yang dijalankan menggunakan port> 1024.
Banyak server SSH yang berjalan pada port> 1024, memiliki situs web sendiri yang cukup populer.
Jika server SSH berjalan di perusahaan saya sendiri, mungkin saya sudah memposting alamat IP dari server itu di sini sehingga kalian dapat mencoba untuk meretas ke server. Sayangnya server SSH bukan milik saya. ;-)
Tetapi ada hal-hal lain yang harus Anda siapkan untuk membuatnya aman. SSH> 1024 saja tidak akan cukup. Nomor port tidak boleh di / etc / services, harus menggunakan port forwarding (mis. Port 1124-> 22), akses langsung ke Root harus dinonaktifkan dan hal lainnya.
Jadi, jika Anda ingin berdebat, lebih baik jalankan SSH pada port> 1024 selama beberapa tahun.
p / s: 1124 bukan port SSH saya no. Ha ha.
Memindahkan SSH dengan baik ke port lain memang masuk akal, ini membantu dengan keamanan tetapi tidak terlalu besar. Tentu saja untuk melakukannya Anda harus memiliki kontrol atas firewall Anda, tetapi itu bukan masalah bagi Anda. Apa yang saya pikir mengurungkan manfaat memindahkan pelabuhan adalah pembukaan rentang yang dapat diterima - sebenarnya saya akan mengatakan bahwa itu lebih dari membatalkan manfaat dan mengekspos Anda lebih jauh dari Anda hari ini. Saya yakin Anda dapat meyakinkannya untuk memindahkan port DAN mengurangi secara signifikan rentang masuk dengan menyusun daftar kemungkinan titik masuk bukannya hanya membuka semuanya.
Mengubah port ssh Anda adalah latihan sia-sia yang hanya memberi Anda keamanan terbatas. Lebih baik Anda menonaktifkan otentikasi kata sandi, yang menghilangkan risiko upaya kata sandi kasar, dan hanya mengandalkan autentikasi berbasis kunci ssh. Jika lingkungan Anda memerlukan otentikasi kata sandi, adopsi beberapa mekanisme dua faktor, seperti SecurID atau Wikid.
Kedua hal ini memberi Anda peningkatan nyata dalam keamanan, sedangkan mengubah ssh port hanya memberi Anda ilusi keamanan.
Ini adalah POV praktis: Saya mengoperasikan server ssh pribadi yang terlihat secara publik selama lebih dari empat tahun dengan port SSH yang berubah dan saya tidak pernah mencoba memindai kata sandi. Demi QA ini, saya baru saja mengaktifkan kembali 22 pada salah satu dari mereka selama satu hari. Akibatnya saya dipindai sekitar setiap 10 menit dengan frekuensi percobaan kata sandi sekitar 5 per detik. Selain itu "scan kiddies" juga mencari server dengan kerentanan OpenSSH tertentu.
Yang pasti ini adalah keamanan oleh ketidakjelasan yang tidak membantu jika Anda punya musuh.
Ini bekerja dengan baik, terlepas dari rengekan kerumunan "keamanan melalui ketidakjelasan".
Kelinci konyol, SEMUA keamanan adalah keamanan melalui ketidakjelasan. Hanya karena Anda percaya bahwa protokol kripto Z yang tidak jelas [memerlukan kombinasi sampel DNA, kunci bersama dan tidak mungkin untuk benar-benar mengetikkan kata sandi manusia] sebenarnya aman tidak membuatnya begitu. Yang benar adalah, setiap dan semua ukuran keamanan bergantung pada probabilitas dan asumsi oleh pengguna. Sayang sekali bagi Anda jika saya tahu bagaimana mengeksploitasi asumsi itu, tetapi itu dia.
Bagaimanapun,
Kami telah melakukan ini selama bertahun-tahun, bersama dengan a) membatasi tingkat upaya koneksi (namun, saya tidak tahu bagaimana kami mengaturnya, sesuatu dalam konfigurasi ssh), dan b) skrip untuk melarang host yang menjalankan serangan kamus dengan lebih dari X tebakan salah dalam Y menit. Kami melarang host membuat koneksi untuk jangka waktu tertentu, dan itu membuatnya lebih mudah untuk beradaptasi dengan topologi jaringan yang berubah.
Jika kata sandi Anda cukup kompleks, dan mereka hanya dapat melakukan 3 upaya dalam 15 menit, tidak ada yang perlu ditakuti. Tidaklah sulit untuk mengawasi serangan yang terdistribusi, baik - kita biasanya mengumpulkan dengan subnet dan ip untuk mengesampingkan hal semacam itu.
Akhirnya, yang Anda butuhkan hanyalah beberapa metode tupai rahasia untuk memungkinkan koneksi ke port Anda dengan memodifikasi aturan f / w. Itu bisa apa saja ... smtp, web, magic dns query. Hal-hal seperti SecurID atau Wikid hanya memberikan lebih banyak info kepada pihak ketiga. Dan jangan mulai saya menggunakan sertifikat aman melalui pihak ketiga.