Mari ceritakan kisah keren tentang bagaimana "pihak ketiga" mencoba mengganggu pekerjaan klien kami, dan bagaimana masalah ini diselesaikan.
Bagaimana semuanya dimulai
Semuanya dimulai pada pagi hari tanggal 31 Oktober, hari terakhir bulan itu, ketika banyak orang sangat membutuhkan waktu untuk menyelesaikan masalah-masalah yang mendesak dan penting.
Salah satu mitra, yang menyimpan beberapa mesin virtual klien yang dia layani di cloud kami, melaporkan bahwa dari pukul 9:10 hingga 9:20 beberapa server Windows yang berjalan di situs Ukraina kami tidak menerima koneksi ke layanan akses jarak jauh, pengguna tidak dapat untuk masuk ke desktop mereka, namun setelah beberapa menit masalahnya sepertinya teratasi dengan sendirinya.
Kami meningkatkan statistik pengoperasian saluran komunikasi, tetapi tidak menemukan adanya lonjakan atau kegagalan lalu lintas. Kami melihat statistik beban sumber daya komputasi - tidak ada anomali. Dan apa itu tadi?
Kemudian mitra lain, yang menghosting sekitar seratus server lagi di cloud kami, melaporkan masalah yang sama yang dicatat oleh beberapa klien mereka, dan ternyata secara umum server tersebut dapat diakses (merespon dengan benar terhadap tes ping dan permintaan lainnya), tetapi layanan akses jarak jauh di server ini menerima koneksi baru atau menolaknya, dan kita berbicara tentang server di situs berbeda, lalu lintasnya berasal dari saluran transmisi data yang berbeda.
Mari kita lihat lalu lintas ini. Sebuah paket dengan permintaan koneksi tiba di server:
xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
Server menerima paket ini, tetapi menolak koneksi:
xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0
Artinya, permasalahan tersebut jelas bukan disebabkan oleh permasalahan operasional infrastruktur tersebut, melainkan oleh hal lain. Mungkin semua pengguna mengalami masalah dengan lisensi desktop jarak jauh? Mungkin beberapa jenis malware berhasil menembus sistem mereka, dan hari ini sudah diaktifkan, seperti yang terjadi beberapa tahun lalu Data X ΠΈ Petya?
Saat kami memilahnya, kami menerima permintaan serupa dari beberapa klien dan mitra lainnya.
Apa yang sebenarnya terjadi pada mesin ini?
Log peristiwa penuh dengan pesan tentang upaya menebak kata sandi:
Biasanya, upaya seperti itu didaftarkan di semua server yang menggunakan port standar (3389) untuk layanan akses jarak jauh dan akses diizinkan dari mana saja. Internet penuh dengan bot yang terus-menerus memindai semua titik koneksi yang tersedia dan mencoba menebak kata sandinya (inilah sebabnya kami sangat menyarankan penggunaan kata sandi yang rumit daripada β123β). Namun, intensitas upaya tersebut hari itu terlalu tinggi.
Apa yang harus saya lakukan?
Merekomendasikan agar pelanggan menghabiskan banyak waktu mengubah pengaturan untuk sejumlah besar pengguna akhir untuk beralih ke port lain? Bukan ide yang bagus, pelanggan tidak akan senang. Merekomendasikan mengizinkan akses hanya melalui VPN? Terburu-buru dan panik, meningkatkan koneksi IPSec bagi mereka yang belum meningkatkannya - mungkin kebahagiaan seperti itu juga tidak membuat klien tersenyum. Meskipun, harus saya katakan, ini adalah hal yang baik dalam hal apa pun, kami selalu menyarankan untuk menyembunyikan server di jaringan pribadi dan siap membantu dengan pengaturannya, dan bagi mereka yang suka mencari tahu sendiri, kami membagikan instruksi untuk mengatur IPSec/L2TP di cloud kami dalam mode situs-ke-situs atau jalan -warrior, dan jika ada yang ingin mengatur layanan VPN di server Windows mereka sendiri, mereka selalu siap untuk berbagi tips tentang cara mengatur a RAS standar atau OpenVPN. Namun, betapapun kerennya kami, ini bukanlah waktu terbaik untuk melakukan pekerjaan pendidikan di antara klien, karena kami perlu memperbaiki masalah secepat mungkin dengan tekanan minimal bagi pengguna.
Solusi yang kami terapkan adalah sebagai berikut. Kami telah menyiapkan analisis lalu lintas yang lewat sedemikian rupa untuk memantau semua upaya membuat koneksi TCP ke port 3389 dan memilih alamat yang, dalam 150 detik, mencoba membuat koneksi dengan lebih dari 16 server berbeda di jaringan kami - ini adalah sumber serangan ( Tentu saja, jika salah satu klien atau mitra benar-benar perlu menjalin koneksi dengan begitu banyak server dari sumber yang sama, Anda selalu dapat menambahkan sumber tersebut ke "daftar putih". Selain itu, jika lebih dari 150 alamat diidentifikasi dalam satu jaringan kelas C selama 32 detik ini, masuk akal untuk memblokir seluruh jaringan. Pemblokiran diatur selama 3 hari, dan jika selama ini tidak ada serangan yang dilakukan dari sumber tertentu, sumber ini secara otomatis dihapus dari βdaftar hitam.β Daftar sumber yang diblokir diperbarui setiap 300 detik.
Daftar ini tersedia di alamat ini: , Anda dapat membuat ACL berdasarkan itu.
Kami siap membagikan kode sumber sistem seperti itu; tidak ada yang terlalu rumit di dalamnya (ini adalah beberapa skrip sederhana yang dikompilasi hanya dalam beberapa jam), dan pada saat yang sama dapat diadaptasi dan digunakan tidak hanya untuk melindungi terhadap serangan semacam itu, tetapi juga untuk mendeteksi dan memblokir segala upaya untuk memindai jaringan:
Selain itu, kami telah membuat beberapa perubahan pada pengaturan sistem pemantauan, yang sekarang memantau dengan lebih cermat reaksi kelompok kontrol server virtual di cloud kami terhadap upaya membuat koneksi RDP: jika reaksi tidak mengikuti dalam a kedua, ini adalah alasan untuk memperhatikan.
Solusi tersebut ternyata cukup efektif: tidak ada lagi keluhan baik dari klien maupun mitra, dan dari sistem monitoring. Alamat baru dan seluruh jaringan secara teratur ditambahkan ke daftar hitam, yang menunjukkan bahwa serangan terus berlanjut, namun tidak lagi mempengaruhi pekerjaan klien kami.
Tidak ada prajurit di lapangan
Hari ini kami mengetahui bahwa operator lain mengalami masalah serupa. Seseorang masih percaya bahwa Microsoft membuat beberapa perubahan pada kode layanan akses jarak jauh (jika Anda ingat, kami mencurigai hal yang sama pada hari pertama, tetapi kami segera menolak versi ini) dan berjanji untuk melakukan segala kemungkinan untuk menemukan solusi dengan cepat . Beberapa orang mengabaikan masalah tersebut dan menyarankan klien untuk melindungi diri mereka sendiri (mengubah port koneksi, menyembunyikan server di jaringan pribadi, dan sebagainya). Dan pada hari pertama, kami tidak hanya memecahkan masalah ini, namun juga menciptakan beberapa landasan bagi sistem deteksi ancaman yang lebih global yang kami rencanakan untuk dikembangkan.
Terima kasih khusus kepada para klien dan partner yang tidak tinggal diam dan tidak duduk-duduk di tepian sungai menunggu jenazah musuh terapung di sepanjang sungai tersebut suatu saat, namun langsung mengalihkan perhatian kami pada permasalahan tersebut, yang memberikan kesempatan kepada kami untuk menghilangkannya. itu pada hari yang sama.
Sumber: www.habr.com