Pertanyaan Apakah itu normal untuk mendapatkan ratusan upaya break-in per hari?


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


196
2018-03-08 11:26




Sampai kami mengunci semua port eksternal yang tidak perlu, saya ingat tidak hanya kami mendapatkan banyak upaya hack, tetapi suatu hari itu sangat buruk sehingga kami diretas dari dua negara yang berbeda - pada saat yang sama! Jadi ya, 100 upaya break-in adalah hal yang normal. - Django Reinhardt
Kami memiliki server yang mengalami serangan "urutan" baru setiap 16 detik. Urutan tunggal biasanya batch sekitar 100 upaya di berbagai port. Hanya untuk iseng satu hari saya menyalakan server yang tidak di-patch di luar firewall kami; butuh waktu kurang dari 10 menit dari waktu itu diaktifkan untuk mendapatkan pwnd. Intinya adalah internet benar-benar adalah hutan; cobalah untuk tidak dimakan. - NotMe
Saya dapat melihat saya memposting pertanyaan saya ke situs yang salah: superuser.com/questions/200896/… - Justin C
sementara saya setuju dengan yang lain hal ini normal pada port umum yang diperlukan (80, 443) Saya secara praktis mengeliminasi upaya-upaya ini terhadap port SSH saya hanya dengan mengubah port default dari 22 menjadi sesuatu yang tidak jelas seperti 6022 misalnya. Hanya melakukan itu, sendirian, hampir menghilangkan 99% dari jenis serangan itu. - Kilo
Jika Anda akan mengubah port SSH Anda, ada alasan keamanan untuk menyimpannya di bawah port 1024 (hanya root yang dapat membuka port <1024, sehingga melindungi Anda dari pengguna lain yang membajak SSH). - Brendan Long


Jawaban:


Dalam internet saat ini, ini cukup normal. Ada banyak 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 akun aplikasi tertentu).

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

Itulah mengapa sangat penting untuk:

  • Larang login root di SSH (bagaimana caranya)
  • gunakan kata sandi yang kuat di mana saja (juga di aplikasi web Anda)
  • untuk SSH, gunakan autentikasi kunci publik jika memungkinkan dan nonaktifkan autentikasi kata sandi sepenuhnya (bagaimana caranya)

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

Selain serangan SSH, juga menjadi hal umum untuk memindai server web Anda untuk aplikasi web yang rentan (beberapa aplikasi blogging, CMS, phpmyadmin, dll.). Jadi pastikan untuk tetap up-to-date dan aman dikonfigurasi juga!


207
2018-03-08 11:35



Aplikasi seperti fail2ban dapat membantu banyak untuk 'sementara' menghentikan bot tersebut dari memukul server Anda pada saat-saat konyol di pagi hari :-) Saya telah mengatur saya untuk melarang 3 upaya yang salah selama 24 jam. - emtunc
Dan pindahkan port ssh dari 22 ke 222. Itu berfungsi dengan baik. - Tom O'Connor
+1, hanya autentikasi kunci publik :) - 0xC0000022L
@STATUS_ACCESS_DENIED: tindakan fail2ban yang dibutuhkan hanyalah daftar perintah shell untuk dijalankan. Jadi benar-benar fleksibel dan mudah dibuat bekerja dengan baik dengan konfigurasi khusus apa pun. Referensi terbaik adalah mengunduh dan melihat action.d/iptables.conf. - mattdm
Memblokir penyerang seperti ini adalah buang-buang waktu. Jika Anda menonaktifkan login root, ada kemungkinan bahwa tidak seorang pun akan 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 layak, mereka tidak akan pernah menebaknya. - Brendan Long


Beberapa 100 baik-baik saja ... Bulan lalu saya menemukan salah satu server saya memiliki 40k upaya gagal. Saya pergi melalui kesulitan merencanakan mereka: Peta

Setelah saya mengubah port ssh dan menerapkan Port Knocking, angka tersebut jatuh ke 0 :-)


58
2018-03-08 11:36



Peta bagus. Saya ingin tahu cara melakukan ini! - jftuga
@ 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 dalam CSV dan mengunggahnya ke zeemaps.com. Saya telah melihat peta yang lebih baik dari peta saya, di mana mereka akan menggunakan hitungan untuk mewarnai peta (hijau ke merah untuk jumlah upaya per county), tetapi saya belum mendapatkan jet yang keluar - Bart De Vos
Apa yang Anda maksud dengan 'menerapkan Port Knocking'? Apakah ada aplikasi yang dapat saya instal melalui apt-get untuk melakukan ini? Jumlah yang jatuh ke 0 terdengar bagus
Keamanan melalui ketidakjelasan mendapat bungkus yang buruk. Ini baik-baik saja selama itu bagian dari keseluruhan strategi daripada seluruh strategi. Lagi pula, apa lagi kata sandi selain string yang tidak jelas? - Joel Coel
@ Joel Coel, itu a rahasia string, yang bertentangan dengan sebagian besar keamanan melalui masalah ketidakjelasan - yang tidak jelas, tetapi tidak harus proses rahasia. - tobyodavies


Saya untuk satu menggunakan "tarpit" di samping hanya mengizinkan otentikasi kunci publik dan tidak mengizinkan login root.

Di netfilter ada sebuah recent modul, yang dapat Anda gunakan dengan (INPUT rantai):

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 recent modul dengan IP dan beberapa barang lainnya dengan nama "tarpit" (jika Anda ingin tahu, lihatlah /proc/net/xt_recent/tarpit). Tentunya Anda bisa menggunakan nama lain.

Untuk mencantumkan atau menghapus IP yang digunakan:

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

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

Sesuaikan aturan sesuai keinginan Anda tetapi pastikan bahwa aturan tersebut ditambahkan dalam urutan itu (yaitu ketika menambahkan lalu gunakan dalam urutan ini, saat memasukkannya dalam urutan terbalik).

Ini sangat mengurangi kebisingan. Ini juga memberikan keamanan yang sebenarnya (melawan kekerasan) tidak seperti keamanan yang dirasakan untuk mengganti port. Namun, saya tetap menyarankan untuk mengganti port jika itu layak di lingkungan Anda. Ini akan mengurangi tingkat kebisingan juga ...

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

EDIT:

Anda dapat mengunci diri untuk melakukan hal ini, sehingga Anda dapat menambahkan sesuatu seperti berikut yang memungkinkan Anda menghapus larangan dengan mengetuk port tertentu:

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

29
2018-03-08 14:24



Saya menggunakan ini dan berhasil memblokir diri saya sesekali, jadi suka memasang port lain sehingga Anda dapat "mengetuk" untuk menghapus larangan Anda. - benlumley
@benlumley: poin bagus. Port knocking dapat juga 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


Anda bisa menerapkan fail2ban, atau metode serupa seperti mengunci SSH ke IP Anda. Sayangnya bots mencoba untuk bruteforce akses sepanjang waktu sehingga cukup normal, Anda perlu memastikan bahwa Anda memiliki kata sandi yang baik.


15
2018-03-08 11:32



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


iya nih. Ini cukup normal saat ini.

Harap gunakan hanya autentikasi kunci publik untuk tujuan administratif jika memungkinkan. Hasilkan kunci pribadi di workstation Anda:

$ ssh-keygen -t dsa

Copypaste isi ~ / .ssh / id_dsa.pub kepada Anda server ~ / .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 untuk mereka.

Memeriksa Denyhosts dan fail2ban untuk memblokir upaya login SSH berulang dan lihat Mendengus jika Anda membutuhkan IDS / IPS penuh.


12
2018-03-09 23:32



Saya tidak akan merekomendasikan penggunaan autentikasi 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. Autentikasi kunci publik lebih untuk situasi di mana Anda memerlukan sesuatu seperti skrip atau program untuk dapat memiliki akses SSH ke sistem lain tanpa perlu kata sandi sehingga Anda tidak perlu menanamkan kata sandi plain-text di skrip / program Anda. - Registered User
@ Account Dihapus: Anda dapat mengatur frasa sandi untuk kunci pribadi SSH. - Phil Cohen
Komentar "Pengguna Terdaftar" salah arah. Hanya untuk memperjelas: Selalu atur kata sandi yang bagus pada kunci pribadi Anda, dan jangan simpan kunci pribadi di server apa pun. Simpan kunci pribadi di workstation Anda sendiri. Setelah Anda menambahkan kunci ke program ssh-agent, dan masukkan kata sandi Anda, Anda dapat masuk ke setiap sistem yang telah menginstal kunci publik, tanpa harus memasukkan kembali kata sandi Anda. Aktifkan agen-forwarding di klien ssh Anda sehingga Anda dapat masuk dari server ke server. Membuat kunci pribadi Anda dicuri adalah buruk, tetapi dengan kata sandi yang layak di atasnya, itu tidak seburuk kata sandi yang dicuri. - Martijn Heemels
Benar, jangan berpikir untuk menyimpan kunci privat admin yang tidak dienkripsi. - yarek


menggunakan http://denyhosts.sourceforge.net/

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


8
2018-03-09 09:37



Menonaktifkan autentikasi kata sandi tidak selalu merupakan solusi yang layak. - Publiccert


Upaya ini dimekanisasi, sehingga jumlahnya tampak oke (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.


6
2018-03-08 11:33





Saya akan mengatakan hanya mendapatkan hanya 500 agak rendah.

Pada perusahaan sebelumnya, salah satu peneliti keamanan komputer yang disebut aliran konstan dari upaya break-in "internet yang setara suara kosmik". Dia menggambarkannya sebagai aliran lalu lintas berbahaya yang normal dan terus menerus yang sedang mencari sistem di internet dan secara otomatis mengeksploitasi skrip untuk mencoba membajak sistem. Bot-jaring dan sistem jahat lainnya akan terus memindai dan memindai ulang internet untuk sistem rentan seperti SETI.


6
2018-03-08 17:06





Iya nih,

ini biasa, tetapi itu tidak berarti Anda tidak harus melawan pertarungan yang baik. Berikut ini beberapa langkah tentang bagaimana Anda dapat membuat server Anda lebih aman.

Hindari alamat IP terkait DNS

Anda dapat sangat mengurangi jumlah ini di lingkungan bersama atau colocation dengan menonaktifkan akses SSH pada alamat IP apa pun yang terkait dengan nama domain. Alamat IP non-domain yang tidak terdaftar akan menerima lebih sedikit jenis lalu lintas ini, jadi beli IP yang tidak terdaftar dan gunakan IP ini hanya 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 SSH Internet, pastikan Anda memiliki solusi lampu keluar terintegrasi. Siapkan VPN Anda, dan hanya izinkan akses SSH dari VPN Anda.

Terapkan aturan alamat IP untuk akses SSH

Jika VLAN bukan merupakan 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 tidur lebih mudah di malam hari mengetahui seseorang harus berkompromi jaringan perusahaan hosting Anda untuk mendapatkan akses ke server melalui SSH.


6
2018-03-08 21:56