Apakah normal untuk mendapatkan ratusan upaya pembobolan per hari?

196

Saya baru saja memeriksa server saya /var/log/auth.logdan menemukan bahwa saya mendapatkan lebih dari 500 pemberitahuan upaya gagal kata sandi / pembobolan per hari! Situs saya kecil, dan URL-nya tidak jelas. Apakah ini normal? Haruskah saya mengambil tindakan apa pun?

— Kyle
sumber

2

Sampai kita mengunci semua port eksternal yang tidak perlu, saya ingat kita tidak hanya mendapatkan banyak upaya peretasan, tetapi suatu hari sangat buruk sehingga kita diretas dari dua negara yang berbeda - pada saat yang sama! Jadi ya, upaya pembobolan 100-an adalah normal.

— Django Reinhardt

91

Kami memiliki server yang mengalami "urutan" serangan baru setiap 16 detik sekali. Urutan tunggal biasanya merupakan kumpulan sekitar 100 upaya di berbagai port. Hanya untuk iseng suatu hari saya menyalakan server yang belum ditambal di luar firewall kami; hanya membutuhkan waktu kurang dari 10 menit sejak dinyalakan untuk mendapatkan pwnd. Intinya internet itu benar-benar hutan; cobalah untuk tidak dimakan.

— NotMe

2

Saya bisa melihat saya memposting pertanyaan saya ke situs yang salah: superuser.com/questions/200896/…

— Justin C

6

sementara saya setuju dengan orang lain ini normal pada port umum yang diperlukan (80, 443) Saya praktis menghilangkan upaya ini terhadap port SSH saya dengan hanya mengubah port default dari 22 ke sesuatu yang tidak jelas seperti 6022 misalnya. Hanya melakukan itu, sendirian, hampir menghilangkan 99% dari jenis serangan itu.

— Kilo

2

Jika Anda ingin mengubah port SSH Anda, ada alasan keamanan untuk menyimpannya di bawah port 1024 (hanya root yang bisa membuka port <1024, jadi itu melindungi Anda dari pengguna lain yang membajak SSH).

— Brendan Long

207

Di internet saat ini hal ini cukup normal. Ada gerombolan botnet yang mencoba masuk ke setiap server yang mereka temukan di seluruh jaringan IP. Biasanya, mereka menggunakan serangan kamus sederhana pada akun terkenal (seperti akun root atau aplikasi tertentu).

Target serangan tidak ditemukan melalui entri Google atau DNS, tetapi para penyerang hanya mencoba setiap alamat IP dalam subnet tertentu (misalnya perusahaan hosting server-root yang dikenal). Jadi tidak masalah bahwa URL Anda (karenanya entri DNS) agak tidak jelas.

Itulah mengapa sangat penting untuk:

larang login root di SSH ( howto )
gunakan kata sandi yang kuat di mana-mana (juga dalam aplikasi web Anda)
untuk SSH, gunakan otentikasi kunci publik jika mungkin dan nonaktifkan kata sandi auth sepenuhnya ( howto )

Selain itu, Anda dapat menginstal fail2ban yang akan memindai authlog dan jika ia menemukan sejumlah upaya login gagal dari IP, ia akan melanjutkan untuk menambahkan IP ke /etc/hosts.denyatau iptables / netfilter untuk mengunci penyerang selama beberapa menit.

Selain serangan SSH, juga umum untuk memindai server web Anda untuk aplikasi web yang rentan (beberapa aplikasi blogging, CMS, phpmyadmin, dll.). Jadi, pastikan untuk selalu memperbarui dan mengonfigurasi mereka dengan aman!

— Holger Just
sumber

21

Aplikasi seperti fail2ban dapat membantu banyak untuk 'sementara' menghentikan bot dari memukul server Anda pada waktu yang konyol di pagi hari :-) Saya telah mengatur saya untuk melarang 3 upaya yang salah selama 24 jam.

— emtunc

46

Dan pindahkan port ssh dari 22 ke 222. Itu bekerja dengan cukup baik.

— Tom O'Connor

40

+1, hanya otentikasi kunci publik :)

— 0xC0000022L

3

@STATUS_ACCESS_DENIED: tindakan yang dilakukan fail2ban hanyalah daftar perintah shell untuk dijalankan. Jadi sangat fleksibel dan mudah untuk bekerja dengan benar dengan konfigurasi khusus. Referensi terbaik adalah untuk mengunduhnya dan melihatnya action.d/iptables.conf.

— mattdm

4

Memblokir penyerang seperti ini adalah buang-buang waktu. Jika Anda menonaktifkan login root, ada kemungkinan besar bahwa tidak seorang pun akan pernah menebak nama login Anda yang benar, apalagi kata sandi. SSH sendiri sudah membatasi permintaan kata sandi, jadi meskipun mereka tahu nama pengguna Anda (bot acak tidak akan), jika Anda memiliki kata sandi yang baik, mereka tidak akan pernah menebaknya.

— Brendan Long

58

Beberapa 100 baik-baik saja ... Bulan lalu saya menemukan salah satu server saya memiliki upaya gagal 40k. Saya mengalami kesulitan merencanakannya: Peta

Setelah saya mengubah port ssh dan mengimplementasikan Port Knocking, jumlahnya turun menjadi 0 :-)

— Bart De Vos
sumber

2

Peta yang bagus. Saya ingin tahu bagaimana melakukan ini!

— jftuga

9

@ jftuga saya mendapatkan semua IP dari log terlebih dahulu.

grep 'Failed password' /var/log/secure* | grep sshd | grep -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' | sort | uniq

(hapus | uniq di bagian akhir jika Anda ingin memperbolehkan duplikat). Anda kemudian dapat menempatkannya di CSV dan mengunggahnya ke zeemaps.com. Saya telah melihat peta yang lebih baik daripada milik saya, di mana mereka akan menggunakan hitungan untuk mewarnai peta (hijau menjadi merah untuk jumlah upaya per county) tapi saya belum menemukan satu pun

— Bart De Vos

3

Apa yang Anda maksud dengan 'mengimplementasikan Port Knocking'? Apakah ada aplikasi yang dapat saya instal melalui apt-get untuk melakukan ini? Angka yang turun menjadi 0 terdengar bagus

18

Keamanan melalui ketidakjelasan mendapat bungkus yang buruk. Tidak apa-apa asalkan itu bagian dari keseluruhan strategi daripada keseluruhan strategi. Lagi pula, apa lagi yang merupakan kata sandi selain string yang tidak jelas?

— Joel Coel

5

@ Joel Coel, ini adalah string rahasia , yang bertentangan dengan sebagian besar keamanan melalui masalah ketidakjelasan - suatu proses yang tidak jelas, tetapi belum tentu rahasia.

— tobyodavies

29

I untuk satu menggunakan "tarpit" selain hanya memungkinkan otentikasi kunci publik dan melarang login root.

Di netfiltersana ada recentmodul, yang dapat Anda gunakan dengan ( INPUTrantai):

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource
iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP
iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

Apa yang dilakukan adalah, bahwa setiap upaya untuk terhubung ke port 22 terdaftar oleh recentmodul dengan IP dan beberapa hal lain dengan nama "tarpit" (jika Anda penasaran, lihat /proc/net/xt_recent/tarpit). Jelas Anda bisa menggunakan nama lain.

Untuk membuat daftar atau menghapus daftar IP, gunakan:

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit
echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

Nilai ini membatasi upaya hingga 5 dalam 300 detik. Harap perhatikan bahwa pengguna dengan koneksi yang ada tidak terganggu oleh batas itu, karena mereka sudah memiliki koneksi yang sudah mapan dan diizinkan untuk membuat lebih banyak (bahkan di atas batas tarif).

Sesuaikan aturan sesuai keinginan Anda, tetapi pastikan bahwa aturan itu ditambahkan dalam urutan itu (yaitu saat menambahkan lalu menggunakannya dalam urutan ini, saat memasukkan lalu dalam urutan terbalik).

Ini sangat mengurangi kebisingan. Ini juga menyediakan keamanan aktual (melawan kekerasan) tidak seperti keamanan yang dirasakan untuk mengubah port. Namun, saya masih merekomendasikan untuk mengganti port jika memungkinkan di lingkungan Anda. Ini akan mengurangi tingkat kebisingan juga ...

Anda masih dapat menggabungkan ini dengan fail2ban, meskipun saya sudah berjalan dengan baik tanpa itu dan hanya aturan di atas.

SUNTING:

Dimungkinkan untuk mengunci diri Anda keluar dari melakukan ini, sehingga Anda dapat menambahkan sesuatu seperti berikut ini yang memungkinkan Anda menghapus Anda melarang dengan mengetuk port tertentu:

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove

— 0xC0000022L
sumber

2

Saya menggunakan ini dan mengelola untuk memblokir diri saya sesekali, jadi ingin mengatur port lain sehingga Anda dapat "mengetuk" untuk menghapus larangan Anda.

— benlumley

@ Benlumley: poin bagus. Mengetuk port juga bisa berguna untuk mengubah port default - atau bahkan keduanya dalam kombinasi ...

— 0xC0000022L

@benlumley: lihat komentar Anda (sekarang dihapus oleh Sam). Saya benar-benar tidak keberatan jika jawabannya diedit / ditingkatkan;)

— 0xC0000022L

15

Anda bisa mengimplementasikan fail2ban , atau metode serupa seperti mengunci SSH ke IP Anda. Sayangnya bot mencoba untuk mengakses bruteforce sepanjang waktu sehingga itu cukup normal, Anda perlu memastikan Anda memiliki kata sandi yang baik.

— Yakub
sumber

3

Jika Anda menggunakan SSH, pertimbangkan otentikasi kunci publik. Ini sedikit lebih aman daripada otentikasi kata sandi.

— Piskvor

12

Ya . Ini cukup normal saat ini.

Harap gunakan hanya otentikasi kunci publik untuk keperluan administratif jika memungkinkan. Hasilkan kunci pribadi di komputer Anda:

$ ssh-keygen -t dsa

Copypaste konten ~ / .ssh / id_dsa.pub ke server Anda ~ / .ssh / Authorized_keys (dan /root/.ssh/authorized_keys, jika Anda memerlukan login root langsung).

Konfigurasikan server Anda / etc / ssh / sshd_config untuk hanya menerima otentikasi kunci publik:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

Jika Anda memiliki terlalu banyak server, Anda dapat menggunakan Wayang untuk menjalankan kunci publik dan konfigurasi padanya.

Lihatlah ke Denyhosts dan fail2ban untuk memblokir upaya login SSH berulang dan lihat Snort jika Anda memerlukan IDS / IPS lengkap.

— jkj
sumber

2

Saya tidak akan merekomendasikan menggunakan otentikasi kunci publik di SSH untuk akses shell ke server Anda. Jika workstation Anda dikompromikan atau, bahkan lebih buruk dicuri, maka seseorang sekarang memiliki akses terbuka ke server Anda tanpa perlu kata sandi. Otentikasi kunci publik lebih untuk situasi di mana Anda memerlukan sesuatu seperti skrip atau program untuk dapat memiliki akses SSH ke sistem lain tanpa memerlukan kata sandi sehingga Anda tidak harus memasukkan kata sandi teks biasa ke skrip / program Anda.

— Pengguna Terdaftar

5

@ Akun Dihapus: Anda dapat menetapkan frasa sandi untuk kunci pribadi SSH.

— Phil Cohen

2

Komentar "Pengguna Terdaftar" salah arah. Hanya untuk memperjelas: Selalu atur kata sandi yang baik pada kunci pribadi Anda, dan jangan menyimpan kunci pribadi di server mana pun. Simpan kunci pribadi di stasiun kerja Anda sendiri. Setelah Anda menambahkan kunci ke program ssh-agent, dan memasukkan kata sandi Anda, Anda dapat masuk ke setiap sistem yang memiliki kunci publik diinstal, tanpa harus memasukkan kembali kata sandi Anda. Aktifkan penerusan agen di klien ssh Anda sehingga Anda dapat masuk dari server ke server. Mencuri kunci pribadi Anda adalah hal yang buruk, tetapi dengan kata sandi yang layak, tidak seburuk kata kunci yang dicuri.

— Martijn Heemels

Benar, bahkan jangan berpikir untuk menyimpan kunci pribadi admin yang tidak dienkripsi.

— yrk

8

gunakan http://denyhosts.sourceforge.net/

dan ya, Anda harus menggunakan otentikasi kunci publik dan menonaktifkan kata sandi auth.

— nomor 5
sumber

Menonaktifkan otentikasi kata sandi tidak selalu merupakan solusi yang layak.

— Publiccert

6

Upaya ini dilakukan secara mekanis, sehingga jumlahnya tampak OK (ya mereka tinggi dibandingkan dengan beberapa situs dan rendah dibandingkan dengan yang lain). Anda harus mengambil langkah-langkah yang biasanya Anda harus: Anda menganggap situs Anda sebagai target serangan setiap hari, bahkan ketika Anda tidak mendeteksi serangan; tidak mendeteksi serangan, tidak berarti itu tidak ada .

— adamo
sumber

6

Menurut saya hanya mendapat 500 saja agak rendah.

Di perusahaan sebelumnya, salah satu peneliti keamanan komputer menyebut aliran konstan upaya pembobolan "ekuivalen internet dari kebisingan kosmik ". Dia menggambarkannya sebagai arus normal, lalu lintas berbahaya yang mencari sistem di internet dan secara otomatis mengeksploitasi skrip untuk mencoba membajak sistem. Bot dan sistem jahat lainnya akan terus memindai dan memindai ulang internet untuk sistem yang rentan seperti SETI.

— James Schek
sumber

6

Iya,

ini biasa, tetapi itu tidak berarti Anda tidak boleh bertarung dengan pertarungan yang baik. Berikut adalah beberapa langkah tentang bagaimana Anda dapat membuat server Anda lebih aman.

Hindari alamat IP terkait DNS

Anda dapat sangat mengurangi nomor ini di lingkungan bersama atau colocation dengan menonaktifkan akses SSH pada alamat IP yang terkait dengan nama domain. Alamat IP non-domain yang tidak terdaftar akan menerima lebih sedikit dari jenis lalu lintas ini, jadi belilah IP yang tidak terdaftar dan hanya gunakan IP ini untuk akses SSH.

Gunakan VPN untuk semua akses SSH

Jika Anda berada di lingkungan di mana Anda dapat mengimplementasikan IPsec / VPN ke jaringan pribadi dalam lingkungan server Anda, ini sangat ideal. Nonaktifkan semua akses Internet SSH, pastikan Anda memiliki solusi lampu mati terintegrasi. Atur VPN Anda, dan hanya izinkan akses SSH dari VPN Anda.

Menerapkan aturan alamat IP untuk akses SSH

Jika VLAN bukan opsi konfigurasi router Anda, atau aturan firewall hanya mengizinkan koneksi SSH dari rentang alamat IP yang diketahui.

Jika Anda mengikuti langkah-langkah ini Anda akan lebih mudah tidur di malam hari mengetahui seseorang harus berkompromi dengan jaringan perusahaan hosting Anda untuk mendapatkan akses ke server melalui SSH.

— Ben DeMott
sumber

5

Cukup normal untuk melihat ratusan koneksi SSH yang gagal.

Jika Anda memiliki opsi, saya cukup mengubah port SSH saya ke sesuatu yang tidak standar. Itu tidak selalu membuat server Anda lebih aman, tetapi itu jelas membersihkan log (dan memungkinkan Anda melihat seseorang dengan sengaja mencoba masuk!)

— Adrian Macneil
sumber

5

Selain menggunakan mekanisme penguncian otomatis seperti fail2ban, Anda memiliki satu opsi lagi: benar-benar menghubungi ISP alamat penyerang penyerang. Ini mungkin tampak benar-benar sia-sia tetapi dalam kasus script-kiddie ISP mereka lebih dari bersedia untuk mengambil tindakan terhadap mereka.

Untuk menemukan alamat penyalahgunaan, mulailah dengan arin.net dan cari alamat IP menggunakan whois. Anda mungkin dialihkan ke registri regional lain tetapi pada akhirnya Anda dapat menemukan ISP yang bertanggung jawab untuk blok IP yang berisi alamat tersebut. Cari alamat @ penyalahgunaan atau kirimkan kontak teknis.

Kirimi mereka pesan sopan dengan entri file log yang relevan (pastikan untuk menghapus informasi pribadi apa pun) dan minta mereka untuk mengambil tindakan terhadap host yang melanggar.

— JRW
sumber

4

Kami biasa melakukan ini. Namun jumlah waktu yang dihabiskan versus manfaat yang diterima sangat kecil sehingga tidak masalah.

— NotMe

1

Varian dari taktik ini yang lebih efektif, tetapi jauh lebih berisiko, adalah melaporkan ISP ke simpul perantara. Tetapi Anda HARUS memiliki bukti laporan yang kuat. Saya mendapatkan seluruh ISP dalam kesulitan besar setelah melakukan ini, karena mereka mengabaikan laporan penyalahgunaan mereka.

— staticsan

1

Suatu kali saya melakukan ini, pesan penyalahgunaan mencapai peretas alih-alih seseorang yang bertanggung jawab atas server. Sejak itu, saya tidak repot lagi, terlalu banyak masalah.

— wump

Ini benar-benar tidak akan membantu dalam banyak kasus dan dapat memakan waktu

— RichVel

4

Saya akan merekomendasikan tidak menggunakan fail2ban tetapi menjalankan SSH (dan lainnya) pada port non-standar. Saya tidak percaya pada keamanan oleh ketidakjelasan tapi saya pikir ini adalah cara terbaik untuk mengurangi kebisingan di log Anda.

Login gagal pada port non-standar akan sedikit dan jauh antara dan juga dapat menunjukkan lebih banyak serangan yang ditargetkan.

Anda bahkan dapat melangkah lebih jauh menginstal honeypot SSH seperti Kippo untuk 'membiarkan' para bruteforcers dan melihat apa yang akan mereka lakukan jika diberi kesempatan.

— Andy Smith
sumber

Haha, Kippo terlihat sangat baik. Saya akan menginstalnya di server hanya untuk melihat apa yang mereka coba lakukan.

— wump

4

Ya itu normal. Apa yang saya katakan pada klien dalam situasi Anda dengan situs web kecil.

Selalu siap untuk diretas.

Memiliki salinan situs web Anda di server dev. Ini bisa menjadi desktop Windows Anda menggunakan XAMPP yang bisa Anda dapatkan secara gratis.

SELALU membuat perubahan ke server dev Anda lalu mengunggahnya ke situs web langsung Anda. Jika itu adalah CMS seperti Wordpress, buat posting Anda di server dev kemudian salin dan tempel ke server langsung.

JANGAN PERNAH mengunduh apa pun dari situs web langsung Anda ke server dev Anda.

Pantau halaman web Anda secara teratur untuk setiap perubahan yang tidak Anda lakukan. Secara khusus, tautan tersembunyi ke obat-obatan atau produk 'tambahan'. Anda dapat menemukan banyak browser dan program yang akan melakukan ini untuk Anda.

Jika Anda dikompromikan. Beri tahu host Anda, hapus semuanya, ubah semua kata sandi, dan unggah server dev bersih Anda ke server web yang sekarang kosong. Bekerja dengan host Anda untuk mencegah terulangnya.

Anda seharusnya tidak memerlukan tim keamanan untuk situs kecil. Itulah yang seharusnya disediakan oleh tuan rumah Anda. Jika tidak, dapatkan host lain yang jauh lebih mudah dilakukan ketika Anda memiliki server dev daripada mencoba memindahkan server langsung.

Semoga ini membantu.

— J Litten
sumber

2

+1 untuk "Selalu bersiap untuk diretas."

— user78940

3

Cara lain untuk menghentikannya (karena saya pribadi tidak suka memindahkan port SSH): putuskan apakah Anda dapat membuat daftar semua jaringan dari mana Anda ingin login, kemudian hanya mengizinkan ini untuk mengakses port SSH Anda.

Entri WHOIS dari ISP lokal membantu saya mengurangi serangan menjadi 1-2 upaya login sebulan (saat itu sekitar 1 k / hari). Saya mendeteksi mereka dengan masih menggunakan denyhosts .

— berat
sumber

3

Selain saran bagus lainnya yang telah Anda terima, saya juga ingin menggunakan arahan AllowUsers jika sesuai untuk server yang diberikan. Ini memungkinkan hanya pengguna tertentu untuk masuk melalui SSH yang sangat mengurangi kemungkinan mendapatkan akses melalui akun tamu / layanan / sistem yang tidak aman dikonfigurasi.

Contoh:

AllowUsers admin jsmith jdoe

Opsi AllowUsers menentukan dan mengontrol pengguna mana yang dapat mengakses layanan ssh. Beberapa pengguna dapat ditentukan, dipisahkan oleh spasi.

— Jay
sumber

3

Ya itu normal. Kamu bisa :

Kurangi peluang serangan dengan menggunakan fwknop

Fwknop adalah salah satu implementasi ketukan port yang lebih baik karena tidak spoofable dan benar-benar mengotentikasi sebagai lawan hanya mengotorisasi koneksi.

Anda dapat mengubah port yang digunakan openssh tetapi Anda tidak benar-benar meningkatkan keamanan.
Fortifikasi ssh otentikasi menggunakan Google-authenticator atau wikid

Ini akan melindungi serangan berbasis kata sandi dan kemungkinan penyerang / serangan bertarget yang membahayakan mesin admin Anda dan mencuri kombo ssh-key & password Anda.

Lihat saja comp pwn2own terbaru untuk melihat betapa mudahnya bagi penyerang yang terampil untuk berkompromi dengan kotak admin Anda yang telah ditambal sepenuhnya.

— Hilton D
sumber

1

Sayangnya ini cukup normal. Anda harus mempertimbangkan untuk menambahkan sesuatu seperti fail2ban ke sistem Anda untuk secara otomatis mendeteksi dan melarang penyerang. Jika Anda belum melakukannya, Anda juga harus mempertimbangkan hanya menggunakan ssh dengan kunci publik dan tidak mengizinkan login root melalui ssh. Jika menggunakan ftp untuk mentransfer file ke sistem, pertimbangkan untuk menggunakan scp / sftp sebagai gantinya.

— pengguna619714
sumber

1

Saya menerapkan port knocking, dan memiliki beberapa probe per hari. Mereka tidak mendapatkan koneksi, jadi mereka pergi. Saya mencatat dan melaporkan semua akses ke port yang terlibat.

Saya juga menjalankan fail2ban dengan Shorewall sebagai firewall untuk sementara daftar hitam penyerang gigih.

Jika Anda tidak memerlukan akses Internet untuk menonaktifkan SSH itu. Jika Anda memiliki beberapa alamat yang diketahui yang memerlukan akses jarak jauh, batasi akses ke alamat-alamat itu.

Membatasi akses ke kunci yang diizinkan juga dapat membantu.

— BillThor
sumber

0

Saya gunakan pam_abluntuk sementara mem-blacklist brute forcers, dan bekerja dengan baik. Saya pikir rasanya lebih baik untuk memiliki otorisasi di PAM menggunakan database sendiri daripada bergantung pada hosts.denyatau iptables.

Kelebihan lainnya adalah pam_abltidak tergantung pada pemindaian file log.

— Christoffer Hammarström
sumber

0

Ini sangat normal akhir-akhir ini.
Anda dapat mengatur batas "burst" pada firewall untuk koneksi baru yang masuk pada port SSH,
atau menginstal salah satu dari banyak parser log, kecuali fail2ban atau mengubah port SSH;).

Yang terakhir adalah yang termudah. Pada mesin berat yang dimuat, upaya break-in seperti itu dapat memberikan pengaruh sangat buruk bagi seluruh sistem.

-
Salam,
Robert

— Robert
sumber

0

Ya itu normal.

Saya baru saja mengubah port ssh dari standar 22. Server saya, aturan saya :) cukup sunting / etc / ssh / sshd_config, ubah port dan restart layanan. Satu-satunya kelemahan adalah Anda harus ingat untuk menambahkan port itu ke konfigurasi untuk setiap klien ssh yang Anda gunakan.

— John
sumber

0

Nonaktifkan login root (Di setiap pengguna sistem root linux ada sehingga bot dapat dengan mudah menebak nama pengguna). Setelah masuk sebagai pengguna normal Anda dapat beralih ke root baik dengan su atau sudo.
ubah port default dari 22
Izinkan akses ssh dari hanya ip yang dikenal
Gunakan kata sandi alfanumerik yang kuat untuk pengguna dengan akses ssh

— Kevin Parker
sumber