Dalam salah satu artikel saya berbicara tentang bagaimana skrip anak-anak mengganggu kehidupan klien kami. Pada artikel ini, saya ingin berbicara tentang solusi: bagaimana kami akan mencoba menghadapinya.
Sejauh ini, tanpa kode sumber lengkap, mereka akan ada di artikel berikutnya. Sementara itu, lebih tepatnya, tentang strategi dan taktik pertahanan.
"Solusi" standar
Kirim keluhan
Pendekatan yang sangat umum. Jika gangguan ke IS Anda terdeteksi, masukkan penyerang ke firewall (atau tidak) dan kirim keluhan otomatis melalui surat, yang ditemukan di whois.
Kami menerima keluhan tentang klien kami dari sistem deteksi intrusi berbagai bank, kantor, situs web. Bahkan, tampaknya, organisasi besar hanya meluncurkan fail2ban dan hanya itu.
Itu semua akan bekerja setiap saat, bagaimana jika penyerang tidak dilarang? Ya, dan memberikan kesempatan untuk mengetuk pintu Anda salah, bagaimana jika seseorang menyetel kata sandi level solarwinds123 dan diretas pada percobaan pertama?
Paksa pengguna untuk melakukan hal yang benar.
Anda dapat membuat layanan Anda sendiri, hampir seperti malware, seperti yang dilakukan GoDaddy, menambahkan pengguna lain di bawah login nydys dan lupa menonaktifkan administrator cloud-init, seperti yang dilakukan GoDaddy, instal 8 sertifikat tambahan ke dalam sistem, seperti yang dilakukan GoDaddy.
Anda juga dapat memblokir AD dan "port tidak aman" lainnya, seperti yang dilakukan beberapa hosting lain, dan itu saja.
Anda dapat menjalankan crawler Anda dan memindai jaring Anda sendiri. Pindai porta, temukan layanan yang rentan, atau bahkan coba masuk ke klien Anda sendiri dengan kata sandi yang paling sering diretas.
Ini akan sangat membantu dalam sesuatu, tetapi apa dan bagaimana harus diatur pada server pengguna harus diputuskan oleh pengguna. Selain itu, jika Anda melakukan semua ini, seperti yang mereka katakan, dalam skala, maka kita akan menemukan kecakapan teknis pengguna dan kesalahpahaman, "Nah, apa yang telah saya lakukan ?!" dan "Saya bukan programmer!", tetapi semua orang harus aman.
Tangani keamanan
Semua yang diatas sangat keren dan bisa bermanfaat. Tetapi pengguna perlu dilindungi. Terutama para pemula. Server virtual sering digunakan sebagai bidang untuk eksperimen, platform untuk membiasakan diri dengan sistem server, dan terkadang pengguna salah paham.
Kami berbicara dengan pemilik mesin yang disusupi, meminta mereka untuk dengan jujur mengatakan kata sandi apa yang telah disetel dan, sayangnya, login dan kata sandi pengujian: tingkat pengujian atau 111: 111, ini masih merupakan praktik umum.
Pengguna Linux semakin parah, mereka tidak bersedia untuk dihubungi seperti pengguna Windows, meskipun dilihat dari jumlah keluhan tentang server Linux, mereka lebih sering diretas atau digunakan oleh penjahat dunia maya.
Jelas bahwa tidak semua orang kehilangan kebijakan mereka dan menyetel sandi tingkat "12345678" di root, tetapi ini terjadi secara teratur, jadi Anda harus mencoba.
Arsitektur
Sederhana seperti tidur. Ini gambarnya:
- Server perangkap mengumpulkan statistik selama 1 jam dan mengirimkan data yang dikumpulkan ke database.
- Server juri mengumpulkan data dari database dan membuat keputusan tentang larangan. Larangan juga dicatat untuk riwayat medis setiap alamat IP tertentu.
- Server BGP mengurai daftar terlarang yang dihasilkan dan mengirimkan daftar ini sebagai umpan BGP lebih jauh ke router.
Dari hook server, data dikirim dalam format yang sama dengan “Get-Bruteforce” yang sama yang kami tawarkan sebelumnya, yaitu:
- Upaya peretasan
- Login digunakan
- alamat IP
- Catatan PTR
Bagaimana keputusan dipertimbangkan
Kami berbicara tentang solusi yang berpotensi memerangi, oleh karena itu, tidak mungkin untuk melarang semua orang secara berturut-turut. Penting untuk memperkenalkan kriteria yang terpisah dan dapat dipahami sehingga jelas bagaimana, apa dan mengapa.
Saat ini, 6 faktor diperhitungkan:
- Berapa kali penyerang mencoba menerobos masuk
- Berapa banyak umpan berbeda yang dia pukul
- Apakah alamat IP statis
- Apakah alamat IP milik hosting atau penyedia rumah
- Apakah penyerang menggunakan login "buruk"
- Apa kata orang baik lainnya
Ekspresi Kuantitatif
Semuanya jelas di sini. Semakin intens pencarian dan semakin luas areanya, dan semakin besar kamus, semakin tinggi ancaman yang ditimbulkan oleh penyerang. Tidak ada gunanya memperluas item ini.
PTR dan segala sesuatu yang berhubungan dengannya
Ketika kami menerbitkan analisis brute force awal, terlihat bahwa catatan PTR menunjukkan banyak hal.
Jumlah perusahaan hosting China yang menyerang server kami sangat banyak, tetapi ini tidak terkecuali, pelanggan Azure dan AWS juga sangat senang terlibat dan tidak mengambil tempat terakhir.
Jumlah serangan terbesar berasal dari alamat IP statis penyedia hosting, jadi jika server merupakan ancaman keamanan terbesar, mengapa melarang pengguna biasa?
Login buruk
Ada beberapa. Misalnya, dari "k8h3d" yang mudah dicari di Google adalah kandidat pertama untuk larangan. Ini adalah login dari worm penambang kripto yang sangat bodoh yang meninggalkan pintu belakang di RDP dengan nama pengguna ini. Hal yang sama berlaku untuk login yang diketik dalam bahasa Hindi, China, dan tata letak lain yang tidak biasa untuk klien kami.
Bisa dibayangkan situasi dimana seseorang melakukan kesalahan dalam satu digit alamat IP, tidak memasukkan dan mulai memilah-milah semua password yang ada dalam hidupnya. Tetapi sulit untuk membayangkan mengharapkan dari klien kami bahwa dia akan mulai mengetik sesuatu selain Administrator standar. Kami menyediakan OS hanya dengan login bahasa Inggris, oleh karena itu, melarang tata letak keyboard mungkin adalah yang paling efektif dan aman.
Orang baik lainnya
Spamhaus sebagai contoh orang baik, terima kasih kepada mereka atas daftar blokir terbuka. Katakanlah seorang penyerang hanya memukul satu honeypot, tetapi alamatnya sudah lama di SBL, lalu mengapa menarik?
Ini sama dengan daftar fail2ban terbuka, pendapat orang baik lainnya memungkinkan Anda membuat keputusan dengan lebih percaya diri.
Menguji
Seperti dalam pengobatan. Studi acak, double-blind. Server yang dipantau (kecuali untuk jebakan) dibagi menjadi dua kelompok.
- Kelompok kontrol
- Para pasien
Untuk dua minggu pertama, kami menerapkan aturan pemfilteran hanya untuk pasien. Grup kontrol menerima semua lalu lintas tanpa penyaringan. Setelah itu, tepat setengah dari server dari kedua grup akan ditukar.
Grup kontrol tambahan akan ditempatkan di DC lain untuk memperhitungkan "kemusiman" dan mengecualikan pengaruh faktor lain, misalnya, penutupan pengontrol, dll.
Dengan demikian, akan mungkin untuk paling andal menetapkan seberapa efektif honeypotting sebagai metode untuk melindungi apa pun selain honeypot itu sendiri.
Apa berikutnya?
Setelah mengumpulkan data primer, pengujian pertempuran jarak dekat akan dilakukan hanya pada beberapa pusat data, dan jika ini secara signifikan mengurangi jumlah serangan, kami akan menerbitkan:
- Buka lembar pemblokiran dengan komentar yang diperluas dalam format txt, xml dan json
- Script untuk RouterOS dan daun pemblokiran terpisah untuk RouterOS
- Buka umpan untuk router BGP.
- Kode sumber.
Nah, jika tidak ada lebih sedikit serangan atau lebih banyak masalah, maka kami hanya akan menerbitkan kode sumber dan laporan mengapa itu terbakar.
Saya berharap topik ini menarik bagi Anda karena menunggu pemikiran Anda tentang sistem yang diusulkan, pemikiran apa pun akan berguna.
