Mengamankan server SSH terhadap bruteforcing


14

Saya punya sedikit server SVN, dell optiplex lama menjalankan debian. Saya tidak memiliki permintaan tinggi pada server saya, karena itu hanya server SVN kecil ... tetapi ingin itu aman.

Saya baru saja memperbarui server saya ke optiplex yang lebih baru dan lebih baik, dan mulai mencari sedikit ke server lama. Saya menurunkannya setelah mengalami masalah. Ketika saya memeriksa log, penuh dengan upaya paksa dan entah bagaimana seseorang telah berhasil memasuki mesin saya. Orang ini menciptakan beberapa volume tambahan yang disebut "knarkgosse" dengan dua dir "root" dan "swap1" atau sesuatu. Tidak benar-benar tahu mengapa dan apa yang mereka lakukan, tetapi tentu saja ingin mencegah hal ini terjadi lagi. Saya menemukan ini agak aneh karena saya mengganti kata sandi saya beberapa bulan atau lebih, dan kata sandi selalu acak huruf dan angka disatukan ... tidak mudah untuk memaksa.

Saya tahu saya bisa mencegah root masuk, dan menggunakan sudoers ... dan mengubah port SSH, tapi apa lagi yang bisa saya lakukan?

Jadi saya punya beberapa pertanyaan:

  1. Bagaimana saya bisa mencegah masuk selama 5 menit setelah X mencoba jumlah yang salah. Atau mencoba lambat setelah setiap percobaan salah?

  2. Apakah ada semacam daftar hitam pusat dimana server dapat terhubung? Daftar hitam yang melacak alamat IP yang "tidak aman" dan tidak boleh diberikan akses?

  3. Apa lagi yang bisa saya lakukan untuk menerapkan keamanan ke server saya?

Seperti yang saya katakan sebelumnya, saya menjalankan Debian 5 dengan Apache (masalah pengguna www-data?), Svn, mysql, php, phpmyadmin, hudson. Itu adalah pada jaringan rumah dengan port forwarding pada 80, 443, 8080, 8180, 23 dan 22.


Jawaban:


17

Fail2ban dan Port Knocking harus memenuhi sebagian besar kebutuhan Anda.

Mengubah port SSH Anda dan hanya mengizinkan otentikasi berbasis Kunci juga disarankan.

Dapat dikatakan bahwa Anda mungkin mencapai titik pengembalian yang semakin berkurang dengan menambahkan langkah-langkah keamanan tambahan, tetapi sekali lagi, terserah Anda untuk memutuskan kapan Anda "cukup aman".

Sebaiknya batalkan login root.


2
Saya menggunakan denyhosts, tapi itu hampir sama dengan fail2ban afaik.
pfyon

Fail2Ban terdengar familier ... Saya akan memeriksanya.
Paul Peelen

1
+1 Fail2Ban, 5 upaya gagal = 5 blok IP menit. Kecuali Anda memiliki kata sandi yang sangat mudah, kata sandi tidak akan pernah kasar pada 1 kata sandi per menit.
Chris S

@ Chris S Ya, itu salah satu favorit saya. Script Kiddies biasanya tidak tahu bagaimana menghadapi timeout ...
gWaldo

1
@ gWaldo, bias konfirmasi sangat membantu dalam menulis ulang hal-hal yang Anda baca untuk mengatakan apa yang Anda anggap benar.
Chris S

7

Tidak ada pengganti untuk kata sandi aman DAN otentikasi kunci. Yang sedang berkata, Fail2Ban adalah alat yang hebat untuk melarang IP pengguna yang mencoba untuk mengotentikasi terlalu banyak. Ini juga tersedia sebagai paket pre-built untuk sebagian besar distro. Berhati-hatilah, Anda dapat secara tidak sengaja mendapatkan diri Anda diblokir, jadi pastikan Anda juga memiliki IP pemulihan yang terdaftar putih atau akses konsol yang mudah ...

Fail2Ban memiliki beberapa contoh bagus tentang cara mengonfigurasi semua yang Anda tanyakan ... namun tidak, memiliki gudang universal untuk alamat yang buruk. Saya tidak berpikir ada repositori di mana pun karena kemudahan mendapatkan IP lain (dhcp renew / bot-net attack / etc ...). Saya juga akan menonaktifkan login melalui ssh menggunakan nama pengguna tipe 'administrator' yang umum (root / admin / administrator / sysop / dll.) Karena ini adalah yang paling sering digedor.


Jawaban yang bagus Saya sangat setuju dengan Anda teks tebal ... karena itu surat tersebut digabungkan dengan kata sandi angka. Otentikasi kunci agak terlalu banyak untuk server ini ... tetapi ide yang bagus. Saya sekarang telah menginstal Fail2ban, sepertinya saya tidak perlu mengkonfigurasi ulang dan karena server svn kecil ini ada di rumah, saya memiliki akses yang mudah (mengingat di belakang ada walk-in closet = S) Thnx atas saranmu!
Paul Peelen

1
Spamhaus menerbitkan daftar jaringan spammer yang dikenal. Itu tidak mencakup botnet, itu hanya diketahui pengirim spam "profesional": spamhaus.org/drop
Chris S


4

Ada sejumlah saran bagus yang ditawarkan di sini. Saya dengan hormat menyarankan bahwa tiga hal harus membuat ini relatif aman:

  1. Jalankan sshd pada port tinggi acak. Bot biasanya hanya mengejar port 22 dan variasi pada port 22 seperti 2222.
  2. Nonaktifkan otentikasi berbasis kata sandi di sshd config:

UsePAM no

  1. Hanya autentikasi dengan situs ini melalui pasangan kunci SSH yang dibagikan sebelumnya. Man on ssh-keygen untuk memulai dengan otentikasi berbasis PKI.

Semoga ini membantu.


2
Untuk solusi stres yang sangat rendah, saya pasti menjalankan ssh pada port yang tidak standar. Dari apa yang saya lihat, ini akan menghentikan upaya koneksi brute force ke server ssh Anda dengan urutan besarnya. Selama periode seminggu, salah satu server saya (menjalankan ssh pada port standar) mendapat 134 upaya koneksi yang tidak valid. Periode waktu yang sama, sebuah instance virtual pada server yang sama (menjalankan ssh pada port yang tidak standar) memiliki 0.
DF

1

Saya selalu menjadi penggemar berat CSF / LFD yang dapat memblokir alamat IP orang yang mencoba bruteforce, portscan, dan beberapa opsi lainnya. Ini pada dasarnya perl-wrapper besar untuk tabel IP, tetapi file konfigurasi tidak sulit dibaca dan dokumentasinya tidak buruk.


Apakah Anda tahu jika ada cara agar seseorang dapat diperingatkan (mis. Melalui email) setiap kali port-scan dilakukan di server?
Paul Peelen

1

Anda juga bisa melihat ke sshguard. Saya belum menggunakannya tetapi saya sudah mendengar hal-hal baik.

Sumber:
http://isc.sans.edu/diary.html?storyid=9370

http://www.sshguard.net/

http://www.sshguard.net/docs/faqs/

"Sshguard memonitor server dari aktivitas logging mereka. Ketika log menyampaikan bahwa seseorang melakukan hal yang buruk, sshguard bereaksi dengan memblokirnya sebentar. Sshguard memiliki kepribadian yang sensitif: ketika seorang anak nakal nakal bersikeras mengganggu tuan rumah Anda, ia bereaksi lebih kencang dan kencang. "


Ini kedengarannya rapi ... Saya akan memeriksanya. thnx
Paul Peelen

1

Saya memiliki server SSH yang terhubung ke internet pada port default dan tidak pernah mengalami masalah ..

  • tcp_wrappers (mis. hosts.allow hosts.deny) untuk SSH .. Saya tidak berpikir ada SSH di luar sana yang tidak memiliki dukungan yang terkompilasi di dalamnya
  • iptables ini dalam hubungannya dengan tcp_wrappers menghilangkan sekitar 99% dari pemindaian port acak / upaya bruteforce .. satu-satunya masalah adalah Anda perlu tahu dari mana Anda akan menghubungkan dari untuk memungkinkan rentang IP / IP ... Saya hanya melakukan mencari penyedia populer di sekitar area saya untuk melihat rentang IP mereka dan mengizinkannya .. sebagian besar pemindaian tampaknya berasal dari negeri yang jauh :)
  • PermitRootLogin tanpa kata sandi (mis. Hanya pasangan kunci RSA / DSA yang dienkripsi dengan frasa sandi) berfungsi luar biasa untuk tugas otomatis .. ketika saya login untuk berinteraksi, saya jelas menggunakan akun saya (biasa) yang dikonfigurasikan dengan akses sudo
  • sudoers
  • pembaruan konstan .. Saya sering memperbarui kotak ini dengan semua pembaruan keamanan / kritis
  • perubahan kata sandi / frasa sandi
  • jalankan chkrootkit setiap sekarang dan lagi untuk melihat apakah saya punya masalah .. (ada beberapa di luar sana yang melakukan fungsi ini)

semoga membantu!


1

Ada cara yang lebih baik untuk melakukan ini, menggunakan fail2ban berarti Anda harus menambahkan aplikasi, dan itu beroperasi pada lapisan aplikasi.

Jika Anda menggunakan iptables, ini lebih efisien karena beroperasi di lapisan jaringan dan Anda tidak perlu menginstal aplikasi tambahan.

Gunakan modul terbaru iptables http://www.snowman.net/projects/ipt_recent/

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP
iptables -A SSHSCAN -j ACCEPT

0

Opsi (untuk digunakan selain langkah-langkah keamanan lainnya) adalah sshd mendengarkan pada port selain 22. Saya belum mencobanya sendiri, tetapi telah mendengar hal itu mengurangi jumlah serangan brute force murni oleh bot.

Saya harus menekankan bahwa ini bukan keamanan nyata, hanya mengurangi jumlah serangan brute force otomatis. Terlalu banyak pekerjaan untuk memeriksa setiap port kurasa.


Saya melakukan itu juga, swiched ke port 23. Terutama karena saya punya server lain di port 22 (yang sekarang saya turun).
Paul Peelen

2
23 adalah port khusus untuk telnetsaat ini. Seringkali merupakan ide yang lebih baik untuk menggunakan port yang tidak dicadangkan, seperti> 60k. iana.org/assignments/port-numbers memberi Anda daftar nomor port yang dipesan.
ℝaphink

Terima kasih atas tipnya. Saya tidak menggunakan prinsip pada mesin ini (belum) tetapi akan mengubah port. Saya memiliki kisaran port antara 52000 - 59000 yang saya gunakan di server profesional saya, berpikir untuk menggunakan yang sama untuk yang satu ini.
Paul Peelen

1
@ Paul: I don't use te[l]net on this machine- tetap seperti itu. Meskipun Anda menginginkan klien telnet untuk berbagai alasan, tidak ada alasan untuk menjalankan server telnet ketika Anda memiliki ssh. Kata sandi plaintext di atas kawat itu buruk .
mlp

0

Sesuatu yang tidak disebutkan di sini dan seharusnya membatasi akses melalui firewall. Ini tidak sesuai dengan setiap situasi, tetapi jika Anda terhubung ke host dari lokasi yang konsisten dengan IP statis, Anda bisa memblokir SSH sepenuhnya kecuali untuk IP itu. Ini akan memastikan bahwa penyusup tidak bisa masuk. Seperti yang saya sebutkan sebelumnya, ini tidak selalu sesuai dengan setiap situasi, terutama jika IP Anda dinamis dan sering berubah.


Secara umum saya setuju dengan solusi Anda. Saya percaya ini adalah standar di perusahaan tempat saya bekerja ... tapi saya tidak berpikir ini sesuatu untuk saya. Masalahnya adalah bahwa saya terutama menggunakan macbook pro saya baik dari rumah (jaringan lokal), dari kantor (IP statis) atau saat bepergian (menggunakan modem 3G / iPhone). Untuk yang terakhir masalah jika saya tidak memiliki VPN yang terlalu banyak saya kira. Terima kasih atas jawaban Anda.
Paul Peelen

0

DenyHosts, http://denyhosts.sourceforge.net/ , adalah proyek bagus yang saya miliki. Jika Anda menetapkan denyhosts untuk menyinkronkannya, itu akan mengunduh IP baru untuk ditambahkan ke daftar larangan yang harus memaksa sistem lain menggunakan denyhosts. Itu juga kedaluwarsa IP yang belum mencoba brute force untuk sementara waktu.

Menggunakan otentikasi kunci publik dan menonaktifkan pembuatan kata sandi mungkin adalah hal terbaik yang bisa Anda lakukan. Mengalahkan serangan brute force.


0

Apa yang efektif bagi saya:

  1. Seperti yang orang lain katakan, tidak ada login root, PasswordAuthentication diatur ke no (hanya login dengan kunci) di sshd_config

  2. Hanya satu atau dua pengguna yang diizinkan masuk melalui ssh dan mereka punya nama yang tidak jelas yang tidak ada dalam daftar nama pengguna alat kasar yang umum (yaitu, bukan "admin" atau "apache" atau "web" atau " johnny ")

  3. Aturan firewall terbatas (pada dasarnya, semuanya diblokir kecuali port layanan saya dan ssh). Saya bahkan membatasi ping, untuk menangkal pindaian yang lebih kasar (banyak yang mengecewakan pasangan saya).

  4. Di host web saya, saya membatasi akses ke beberapa alamat IP tertentu - tetapi ini sepertinya bukan pilihan bagi Anda. Tentu saja tidak dapat melakukannya sendiri di semua host kami. Anda mungkin juga ingin melihat "port-knocking."

  5. Dan favorit saya: Modul respon aktif OSSEC untuk memblokir sejumlah kondisi brute force dan peringatan tentang kesalahan lain juga. Ia mendeteksi x login yang tidak valid dalam jumlah waktu y, dan kemudian memblokir (melalui perintah firewall-drop iptables) untuk periode waktu tertentu. Saya memblokir sekitar 12 jam sekarang untuk bersenang-senang. :)

Satu hal yang saya lakukan di sini untuk memastikan saya tidak memblokir terlalu banyak hal yang salah, adalah bahwa di /etc/ossec.conf, saya mengatur respons aktif ke level tinggi (yang tidak ada dalam konfigurasi default) dan kemudian buka sshd_rules.xml dan atur aturan yang ingin saya blokir ke level itu dan ubah ambang batas untuk blok vs. lansiran seperlunya.

Jika Anda menjalankan Apache, Anda juga dapat memblokir hal-hal yang melanggar aturan apache. Saya tidak memblokir ini hanya karena masalah NAT, saya ingin berpikir tentang memblokir seluruh universitas atau sesuatu. :) Selain itu, Anda dapat menulis aturan khusus untuk memblokir kondisi tertentu dalam file log, yang dapat sangat membantu.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.