Mari beritahu anda kisah hebat tentang bagaimana "pihak ketiga" cuba mengganggu kerja pelanggan kami, dan cara masalah ini diselesaikan.
Bagaimana semuanya bermula
Semuanya bermula pada pagi 31 Oktober, hari terakhir bulan itu, apabila ramai yang sangat memerlukan masa untuk menyelesaikan isu penting dan mendesak.
Salah seorang rakan kongsi, yang menyimpan beberapa mesin maya pelanggan yang dia berkhidmat dalam awan kami, melaporkan bahawa dari 9:10 hingga 9:20 beberapa pelayan Windows yang berjalan di tapak Ukraine kami tidak menerima sambungan ke perkhidmatan akses jauh , pengguna tidak dapat untuk log masuk ke desktop mereka, tetapi selepas beberapa minit masalah itu nampaknya selesai dengan sendirinya.
Kami menaikkan statistik mengenai pengendalian saluran komunikasi, tetapi tidak menemui sebarang lonjakan trafik atau kegagalan. Kami melihat statistik mengenai beban sumber pengkomputeran - tiada anomali. Dan apakah itu?
Kemudian rakan kongsi lain, yang menjadi tuan rumah kira-kira seratus lagi pelayan di awan kami, melaporkan masalah yang sama seperti yang diperhatikan oleh beberapa pelanggan mereka, dan ternyata pada umumnya pelayan itu boleh diakses (bertindak balas dengan betul kepada ujian ping dan permintaan lain), tetapi akses jauh perkhidmatan pada pelayan ini sama ada menerima sambungan baharu atau menolaknya, dan kami bercakap tentang pelayan di tapak yang berbeza, lalu lintas yang datang dari saluran penghantaran data yang berbeza.
Mari kita lihat trafik ini. Satu paket dengan permintaan sambungan tiba di pelayan:
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
Pelayan menerima paket ini, tetapi menolak sambungan:
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 bermakna bahawa masalah itu jelas bukan disebabkan oleh sebarang masalah dalam operasi infrastruktur, tetapi oleh sesuatu yang lain. Mungkin semua pengguna menghadapi masalah dengan pelesenan desktop jauh? Mungkin beberapa jenis perisian hasad berjaya menembusi sistem mereka, dan hari ini ia telah diaktifkan, seperti yang berlaku beberapa tahun lalu XData ΠΈ petya?
Semasa kami menyelesaikannya, kami menerima permintaan serupa daripada beberapa lagi pelanggan dan rakan kongsi.
Apa sebenarnya yang berlaku pada mesin ini?
Log peristiwa penuh dengan mesej tentang percubaan meneka kata laluan:
Biasanya, percubaan sedemikian didaftarkan pada semua pelayan di mana port standard (3389) digunakan untuk perkhidmatan capaian jauh dan akses dibenarkan dari mana-mana sahaja. Internet penuh dengan bot yang sentiasa mengimbas semua titik sambungan yang tersedia dan cuba meneka kata laluan (inilah sebabnya kami amat mengesyorkan menggunakan kata laluan yang kompleks dan bukannya "123"). Walau bagaimanapun, keamatan percubaan ini pada hari itu terlalu tinggi.
Bagaimana untuk teruskan?
Syorkan bahawa pelanggan menghabiskan banyak masa menukar tetapan untuk sebilangan besar pengguna akhir bertukar ke port lain? Bukan idea yang baik, pelanggan tidak akan gembira. Syorkan membenarkan akses hanya melalui VPN? Dalam keadaan tergesa-gesa dan panik, meningkatkan sambungan IPSec bagi mereka yang tidak mempunyai mereka dibesarkan - mungkin kebahagiaan seperti itu tidak tersenyum kepada pelanggan sama ada. Walaupun, saya mesti katakan, ini adalah perkara yang baik dalam apa jua keadaan, kami sentiasa mengesyorkan menyembunyikan pelayan dalam rangkaian peribadi dan bersedia untuk membantu dengan tetapan, dan bagi mereka yang suka memikirkannya sendiri, kami berkongsi arahan untuk menyediakan IPSec/L2TP dalam awan kami dalam mod tapak ke tapak atau jalan raya -warrior, dan jika sesiapa ingin menyediakan perkhidmatan VPN pada pelayan Windows mereka sendiri, mereka sentiasa bersedia untuk berkongsi petua tentang cara menyediakan RAS standard atau OpenVPN. Tetapi, tidak kira betapa hebatnya kami, ini bukanlah masa terbaik untuk menjalankan kerja pendidikan dalam kalangan pelanggan, kerana kami perlu menyelesaikan masalah itu secepat mungkin dengan tekanan yang minimum untuk pengguna.
Penyelesaian yang kami laksanakan adalah seperti berikut. Kami telah menyediakan analisis trafik yang lalu dengan cara untuk memantau semua percubaan untuk mewujudkan sambungan TCP ke port 3389 dan memilih daripadanya alamat yang, dalam masa 150 saat, cuba mewujudkan sambungan dengan lebih daripada 16 pelayan berbeza pada rangkaian kami - ini adalah sumber serangan ( Sudah tentu, jika salah satu pelanggan atau rakan kongsi mempunyai keperluan sebenar untuk mewujudkan sambungan dengan begitu banyak pelayan dari sumber yang sama, anda sentiasa boleh menambah sumber tersebut ke "senarai putih." Selain itu, jika dalam satu rangkaian kelas C selama 150 saat ini, lebih daripada 32 alamat dikenal pasti, masuk akal untuk menyekat keseluruhan rangkaian. Penyekatan ditetapkan selama 3 hari, dan jika pada masa ini tiada serangan dilakukan daripada sumber tertentu, sumber ini dialih keluar secara automatik daripada "senarai hitam." Senarai sumber yang disekat dikemas kini setiap 300 saat.
Senarai ini boleh didapati di alamat ini: , anda boleh membina ACL anda berdasarkannya.
Kami bersedia untuk berkongsi kod sumber sistem sedemikian; tiada apa-apa yang terlalu rumit di dalamnya (ini adalah beberapa skrip mudah yang disusun secara literal dalam beberapa jam di atas lutut), dan pada masa yang sama ia boleh disesuaikan dan digunakan tidak hanya untuk melindungi daripada serangan sedemikian, tetapi juga untuk mengesan dan menyekat sebarang percubaan untuk mengimbas rangkaian:
Di samping itu, kami telah membuat beberapa perubahan pada tetapan sistem pemantauan, yang kini memantau dengan lebih teliti tindak balas kumpulan kawalan pelayan maya dalam awan kami terhadap percubaan untuk mewujudkan sambungan RDP: jika tindak balas tidak mengikuti dalam kedua, ini adalah sebab untuk memberi perhatian.
Penyelesaian itu ternyata agak berkesan: tiada lagi aduan daripada kedua-dua pelanggan dan rakan kongsi, dan daripada sistem pemantauan. Alamat baharu dan keseluruhan rangkaian kerap ditambahkan pada senarai hitam, yang menunjukkan bahawa serangan berterusan, tetapi tidak lagi menjejaskan kerja pelanggan kami.
Terdapat keselamatan dalam bilangan
Hari ini kami mengetahui bahawa pengendali lain telah menghadapi masalah yang sama. Seseorang masih percaya bahawa Microsoft membuat beberapa perubahan pada kod perkhidmatan akses jauh (jika anda masih ingat, kami mengesyaki perkara yang sama pada hari pertama, tetapi kami dengan cepat menolak versi ini) dan berjanji untuk melakukan segala yang mungkin untuk mencari penyelesaian dengan cepat . Sesetengah orang hanya mengabaikan masalah itu dan menasihati pelanggan untuk melindungi diri mereka sendiri (tukar port sambungan, sembunyikan pelayan dalam rangkaian peribadi, dan sebagainya). Dan pada hari pertama, kami bukan sahaja menyelesaikan masalah ini, tetapi juga mencipta beberapa asas untuk sistem pengesanan ancaman yang lebih global, yang kami merancang untuk membangunkan.
Terima kasih khas kepada pelanggan dan rakan kongsi yang tidak berdiam diri dan tidak duduk di tebing sungai menunggu mayat musuh terapung di sepanjangnya satu hari, tetapi segera menarik perhatian kami kepada masalah itu, yang memberi kami peluang untuk menghapuskan itu pada hari yang sama.
Sumber: www.habr.com