Kami akan memberi tahu Anda kisah keren tentang bagaimana "pihak ketiga" mencoba mengganggu pekerjaan pelanggan kami, dan bagaimana masalah ini diselesaikan.
Bagaimana semuanya dimulai
Semuanya dimulai pada pagi hari tanggal 31 Oktober, pada hari terakhir bulan itu, ketika banyak yang sangat membutuhkan untuk mengelola untuk menutup masalah yang mendesak dan penting.
Salah satu mitra yang menyimpan beberapa mesin virtual dari klien yang ia layani di cloud kami melaporkan bahwa dari jam 9:10 pagi hingga jam 9.20 pagi, beberapa server Windows yang berjalan di situs kami di Ukraina tidak menerima koneksi dengan layanan akses jarak jauh. , pengguna tidak dapat mengakses desktop mereka, tetapi setelah beberapa menit masalah tampaknya terselesaikan dengan sendirinya.
Kami meningkatkan statistik saluran komunikasi, tetapi tidak menemukan ledakan lalu lintas atau kegagalan. Melihat statistik beban pada sumber daya komputasi - tidak ada anomali. Dan apa itu?
Kemudian mitra lain yang menempatkan seratus server lain di cloud kami melaporkan masalah yang sama yang dicatat oleh beberapa klien mereka, dan ternyata secara umum server tersedia (mereka merespons dengan benar terhadap tes ping dan permintaan lainnya), tetapi layanan Akses jarak jauh di server-server ini menerima koneksi baru, kemudian menolaknya, sementara itu adalah masalah server di situs yang berbeda, lalu lintas yang berasal dari saluran transmisi data yang berbeda.
Dan mari kita lihat traffic ini. Paket dengan permintaan untuk membuat 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 koneksi menolak:
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
Ini berarti bahwa masalahnya jelas tidak disebabkan sama sekali oleh beberapa kerusakan dalam infrastruktur, tetapi oleh sesuatu yang lain. Mungkin semua pengguna memiliki masalah dengan lisensi Remote Desktops? Mungkin beberapa malware berhasil menyusup ke sistem mereka, tetapi hari ini telah diaktifkan, seperti halnya dengan
XData dan
Petya beberapa tahun yang lalu?
Sementara mereka memilahnya, mereka menerima permintaan serupa dari beberapa klien dan mitra.
Dan apa yang terjadi pada mesin ini?
Log peristiwa penuh dengan pesan tentang mencoba menemukan kata sandi:
Biasanya, upaya tersebut dicatat pada semua server di mana port standar (3389) digunakan 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 menemukan kata sandi (untuk alasan ini kami sangat menyarankan menggunakan kata sandi yang kompleks alih-alih “123”). Namun, intensitas upaya ini pada hari itu terlalu tinggi.
Apa yang harus dilakukan
Rekomendasikan klien untuk mencurahkan banyak waktu untuk mengubah pengaturan sejumlah besar pengguna akhir untuk beralih ke port lain? Bukan ide yang bagus, pelanggan tidak akan senang. Merekomendasikan untuk mengizinkan akses hanya melalui VPN? Dengan tergesa-gesa dan panik, untuk meningkatkan koneksi IPSec, dari siapa mereka tidak dibesarkan - mungkin, kebahagiaan seperti itu tidak tersenyum kepada klien juga. Meskipun, saya harus mengatakan, ini adalah masalah amal, kami selalu merekomendasikan menyembunyikan server di jaringan pribadi dan siap membantu dengan pengaturan, dan bagi mereka yang suka memilah, kami akan secara mandiri berbagi instruksi untuk mengatur IPSec / L2TP di cloud kami di situs-ke-situs atau mode jalan -warrior, dan jika ada yang ingin meningkatkan layanan VPN di server Windows mereka sendiri, mereka selalu siap untuk berbagi kiat tentang cara meningkatkan RAS atau OpenVPN standar. Tapi betapapun kerennya kami, ini bukan waktu terbaik untuk melakukan pekerjaan pendidikan di antara para pelanggan, karena itu perlu untuk menghilangkan masalah dengan ketegangan minimal bagi pengguna secepat mungkin.
Solusi yang kami terapkan adalah sebagai berikut. Kami telah menyiapkan analisis lalu lintas yang lewat sedemikian rupa untuk memantau semua upaya untuk membuat koneksi TCP ke port 3389 dan memilih alamat darinya yang dalam waktu 150 detik mencoba membangun koneksi dengan lebih dari 16 server berbeda di jaringan kami - ini adalah sumber serangan ( Tentu saja, jika salah satu klien atau mitra memiliki kebutuhan nyata untuk membangun koneksi dengan begitu banyak server dari sumber yang sama, Anda selalu dapat menambahkan sumber-sumber tersebut ke "daftar putih." Selain itu, jika dalam satu jaringan kelas C untuk 150 ini detik, lebih dari 32 alamat terdeteksi, masuk akal untuk memblokir seluruh jaringan. Pemblokiran diatur selama 3 hari, dan jika tidak ada serangan yang dilakukan dari sumber ini selama waktu ini, sumber ini secara otomatis dihapus dari daftar hitam. Daftar sumber yang diblokir diperbarui setiap 300 detik.
Daftar ini tersedia di sini di alamat ini:
https://secure.tucha.ua/global-filter/banned/rdp_ddos , Anda dapat membangun ACL Anda sendiri berdasarkan itu.
Kami siap untuk membagikan kode sumber dari sistem seperti itu, tidak ada yang super rumit (ini adalah beberapa skrip sederhana yang ditulis secara harfiah dalam beberapa jam "di lutut"), dan pada saat yang sama dapat diadaptasi dan digunakan tidak hanya untuk melindungi terhadap serangan seperti itu, tetapi juga untuk mengidentifikasi dan memblokir semua upaya pemindaian jaringan:
ikuti tautan ini.Selain itu, kami membuat beberapa perubahan pada pengaturan sistem pemantauan, yang sekarang memantau dengan cermat reaksi kelompok kontrol server virtual di cloud kami terhadap upaya untuk membangun koneksi RDP: jika reaksi tidak mengikuti selama sedetik, ini adalah kesempatan untuk memperhatikan.
Solusinya ternyata cukup efektif: tidak ada lagi keluhan dari klien dan mitra, serta dari sistem pemantauan. "Daftar hitam" secara teratur mencakup alamat baru dan seluruh jaringan, yang menunjukkan bahwa serangan itu terus berlanjut, tetapi tidak lagi memengaruhi pekerjaan pelanggan kami.
Sendiri di lapangan bukan seorang pejuang
Hari ini kami mengetahui bahwa operator lain menghadapi masalah yang sama. 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 menolak versi ini segera) dan berjanji untuk melakukan segala yang mungkin untuk segera temukan solusinya. Seseorang mengabaikan masalah dan menyarankan pelanggan untuk melindungi diri mereka sendiri (mengubah port koneksi, menyembunyikan server di jaringan pribadi, dan sebagainya). Dan pada hari pertama, kami tidak hanya menyelesaikan masalah ini, tetapi juga menciptakan beberapa landasan untuk sistem deteksi ancaman yang lebih global, yang kami rencanakan untuk dikembangkan.
Terima kasih khusus kepada pelanggan dan mitra yang tidak tinggal diam dan tidak duduk di tepi sungai untuk mengantisipasi bahwa suatu hari mayat musuh akan mengapung di atasnya, dan segera mengalihkan perhatian kami ke masalah, yang memberi kami kesempatan untuk menghilangkannya di hari yang sama.