Seberapa berisiko memiliki server pribadi dengan ssh dibuka ke Internet?

25

Kelanjutan judul akan “sementara memiliki pengetahuan terbatas tentang keamanan internet”.

Saya baru-baru ini menyiapkan server kecil dengan komputer low end yang menjalankan debian dengan tujuan untuk menggunakannya sebagai repositori git pribadi. Saya telah mengaktifkan ssh dan cukup terkejut dengan ketepatan di mana ia menderita serangan brute force dan sejenisnya. Lalu saya membaca bahwa ini cukup umum dan belajar tentang langkah-langkah keamanan dasar untuk menangkal serangan ini (banyak pertanyaan dan duplikat pada serverfault yang berurusan dengannya, lihat misalnya ini atau ini ).

Tapi sekarang saya bertanya-tanya apakah semua ini sepadan dengan usaha. Saya memutuskan untuk membuat server sendiri sebagian besar untuk bersenang-senang: Saya hanya bisa mengandalkan solusi pihak ketiga seperti yang ditawarkan oleh gitbucket.org, bettercodes.org, dll. Sementara bagian yang menyenangkan adalah tentang belajar tentang keamanan Internet, saya belum cukup waktu untuk mendedikasikan untuk menjadi ahli dan hampir yakin bahwa saya mengambil langkah pencegahan yang benar.

Untuk memutuskan apakah saya akan terus bermain dengan proyek mainan ini, saya ingin tahu apa yang benar-benar saya risiko melakukannya. Misalnya, sejauh mana komputer lain yang terhubung ke jaringan saya juga mengancam? Beberapa dari komputer ini digunakan oleh orang-orang dengan pengetahuan yang bahkan lebih rendah daripada komputer saya yang menggunakan Windows.

Berapa probabilitas saya mendapat masalah nyata jika saya mengikuti pedoman dasar seperti kata sandi yang kuat, akses root yang dinonaktifkan untuk ssh, port non standar untuk ssh dan mungkin menonaktifkan login kata sandi dan menggunakan salah satu aturan fail2ban, denyhosts atau iptables?

Dengan kata lain, apakah ada beberapa serigala jahat besar yang harus saya takuti atau apakah sebagian besar tentang mengusir kiddies naskah?

security ssh debian

— Alfred M.
sumber

Saya pikir Anda memukul kepala ketika Anda menyebutkan bahwa Anda tidak punya waktu atau kecenderungan untuk menjadi ahli dalam keamanan $ TECHNOLOGY; ini adalah alasan utama untuk menggunakan solusi yang di-host. Satu-satunya argumen umum lainnya dalam mengevaluasi in-house vs hosting adalah biayanya. Karena github dan sejenisnya gratis, Anda pada dasarnya menyerahkan waktu pribadi Anda hanya untuk mendapatkan pengetahuan tentang cara menjalankan git repo. Kami tidak dapat memberi tahu Anda apa yang harus Anda lakukan dengan waktu pribadi Anda, tetapi dalam situasi profesional ini tidak masuk akal. (peringatan emptor: situasi rumit memiliki lebih banyak variabel).

— Chris S

1

Jika Anda memutuskan untuk menjalankan server Anda sendiri, tambahkan juga ke daftar tugas Anda secara teratur memeriksa pembaruan dan kerentanan keamanan untuk setiap layanan yang Anda jalankan. Pengaturannya saja tidak cukup.

— minggu

Dua kata: kunci publik, seperti yang dikatakan @Stephane. Nonaktifkan keyboard-interactiveotentikasi dan gunakan hanya pubkeyotentikasi.

— kostix

14

IMO SSH adalah salah satu hal paling aman untuk didengarkan di internet terbuka. Jika Anda benar-benar khawatir, dengarkan di port high-end non-standar. Saya masih memiliki firewall (level perangkat) antara kotak Anda dan Internet aktual dan hanya menggunakan port forwarding untuk SSH tapi itu tindakan pencegahan terhadap layanan lain. SSH sendiri sangat solid.

Saya memiliki orang-orang menekan server SSH rumah saya sesekali (terbuka untuk Time Warner Cable). Tidak pernah memiliki dampak aktual.

Beberapa hal tambahan yang dapat Anda lakukan untuk membuat SSH lebih aman adalah mencegah upaya berulang dari alamat IP yang sama untuk mesin rumahan seperti

MaxStartups 2:30:10

di / etc / ssh / sshd_config yang akan membatasi berapa banyak koneksi yang dapat dibuat dalam satu baris sebelum login dengan sukses.

— TheFiddlerWins
sumber

Penyedia layanan Internet saya menyediakan firewall yang parameternya saya lihat ketika membuka port untuk ssh. Apakah itu yang Anda rujuk?

— Alfred M.

2

Bisa jadi, beberapa ISP memberi Anda perangkat bodoh, beberapa router dengan firewall bawaan. Saya hanya mengatakan bahwa JANGAN PERNAH menempatkan OS tujuan umum langsung di Internet, apa pun tindakan pencegahan yang Anda lakukan. Anda ingin semacam perangkat perangkat keras (atau sesuatu seperti DD-WRT) antara Anda dan orang jahat.

— TheFiddlerWins

1

Siapkan otentikasi kunci publik seperti disebutkan dalam jawaban lain, dan MATIKAN ChallengeResponseAuthentication dan PasswordAuthentication di / etc / ssh / sshd_config.

— Randy Orrison

Saya tahu ini adalah pertanyaan bodoh tetapi apakah saya harus membeli domain untuk mengakses server saya (melalui ssh atau browser) dari internet?

— TheRookierLearner

@TheRookierLearner - tidak, Anda dapat menggunakan alamat IP yang disediakan ISP Anda. Namun, tergantung pada konfigurasi jaringan rumah Anda, dapat dibagikan melalui semua perangkat Anda dengan sesuatu yang disebut PNAT (kebanyakan orang menyebutnya NAT). Jika Anda seperti kebanyakan orang, Anda perlu mengetahui IP "NATed" dari perangkat tertentu yang ingin Anda akses dari internet (hanya ifconfig / ipconfig pada sistem, itu akan menjadi 10.xxx, 172.16. alamat xx atau 192.168.xx lihat RFC 1918 untuk lebih dari yang Anda pedulikan tentang angka-angka ini) dan kemudian beri tahu router Anda untuk "port forward" atau "DMZ" port 22.

— TheFiddlerWins

10

Menyiapkan sistem otentikasi kunci publik dengan SSH benar - benar sepele dan membutuhkan waktu sekitar 5 menit untuk pengaturan .

Jika Anda memaksa semua koneksi SSH untuk menggunakannya, maka itu akan membuat sistem Anda cukup tangguh seperti yang Anda harapkan tanpa menginvestasikan BANYAK ke dalam infrastruktur keamanan. Terus terang, ini sangat sederhana dan efektif (selama Anda tidak memiliki 200 akun - maka itu menjadi berantakan) sehingga tidak menggunakannya harus menjadi pelanggaran publik.

— Stephane
sumber

3

Untuk memaksa koneksi SSH menggunakan otentikasi kunci publik setelah Anda mengaturnya, pastikan Anda MENGHIDUPKAN ChallengeResponseAuthentication dan PasswordAuthentication di / etc / ssh / sshd_config. Saya lupa ini sekali, saya sangat menyesal (hanya sekali, dan tidak pernah lagi).

— Randy Orrison

8

Saya juga menjalankan server git pribadi yang terbuka untuk dunia pada SSH, dan saya juga memiliki masalah brute-force yang sama seperti Anda, sehingga saya dapat bersimpati dengan situasi Anda.

TheFiddlerWins telah membahas implikasi keamanan utama dengan membuka SSH pada IP yang dapat diakses publik, tetapi alat IMO terbaik dalam menanggapi upaya brute-force adalah Fail2Ban - perangkat lunak yang memantau file log otentikasi Anda, mendeteksi upaya intrusi, dan menambahkan aturan firewall ke iptablesfirewall lokal mesin . Anda dapat mengonfigurasikan berapa banyak upaya sebelum larangan dan juga panjang larangan (standar saya adalah 10 hari).

— Craig Watson
sumber

Seperti komentar saya pada posting sebelumnya, itulah yang digunakan NAS saya di rumah, dan setelah beberapa bulan, jumlah upaya telah menurun secara signifikan.

— mveroone

2

Cara lain untuk menangani ini adalah dengan mengatur VPN. Daripada menghubungkan langsung ke port SSH di server rumah Anda, Anda terhubung ke VPN terlebih dahulu, kemudian jalankan semua lalu lintas Anda melalui koneksi terenkripsi dan aman.

Cara ideal untuk menangani ini adalah dengan firewall yang menggabungkan VPN Endpoint, tetapi Anda juga dapat mengatur komputer Windows untuk bertindak sebagai server VPN.

Ini sebuah contoh:

http://www.howtogeek.com/135996/

Sekarang perlu diingat bahwa konfigurasi keamanan yang tepat akan melibatkan komputer publik (atau semi-publik) yang terisolasi dari jaringan internal Anda. Server web, atau komputer mana pun yang menghosting layanan yang tersedia untuk umum, harus berada di luar jaringan aman rumah atau kantor Anda. Anda akan menggunakan 2 router untuk membuat zona aman, atau DMZ, antara Anda dan Internet.

Dengan cara ini, jika server Anda diretas, itu tidak dapat digunakan sebagai vektor untuk menyerang komputer Anda yang lain.

Jadi setup akan terlihat seperti ini:

Konfigurasi DMZ

— TomXP411
sumber

Maaf tentang gambar kecil ... Saya tidak tahu cara mengedit posting saya.

— TomXP411

2

Jawabannya sangat bagus, saya hanya akan merekomendasikan dua hal:

Pertimbangkan akses hanya oleh sistem otentikasi kunci
Gunakan Denyhosts : Ini akan mencekal host yang mencoba mengakses server Anda dengan auth yang tidak valid

— Carlos C Soto
sumber