DDoS uzbrukums RDP pakalpojumiem: atpazīt un cīnīties. Veiksmīga pieredze no Tucha

PastāstÄ«sim forÅ”u stāstu par to, kā "treŔās puses" mēģināja iejaukties mÅ«su klientu darbā un kā Ŕī problēma tika atrisināta.

Kā tas viss sākās

Viss sākās 31. oktobra rÄ«tā, mēneÅ”a pēdējā dienā, kad daudziem ļoti nepiecieÅ”ams laiks, lai atrisinātu steidzamus un svarÄ«gus jautājumus.

Viens no partneriem, kurÅ” mÅ«su mākonÄ« glabā vairākas viņa apkalpoto klientu virtuālās maŔīnas, ziņoja, ka no pulksten 9:10 lÄ«dz 9:20 vairāki Windows serveri, kas darbojas mÅ«su Ukrainas vietnē, nepieņēma savienojumus ar attālās piekļuves pakalpojumu, lietotāji nevarēja lai pieteiktos savos galddatoros, taču pēc dažām minÅ«tēm problēma, Ŕķiet, atrisinās pati no sevis.

Paaugstinājām statistiku par sakaru kanālu darbÄ«bu, taču nekonstatējām satiksmes pieaugumu vai kļūmes. ApskatÄ«jām statistiku par skaitļoÅ”anas resursu noslogojumu ā€“ nekādu anomāliju. Un kas tas bija?

Tad cits partneris, kurÅ” mÅ«su mākonÄ« mitina vēl aptuveni simts serveru, ziņoja par tām paŔām problēmām, ko atzÄ«mēja daži viņu klienti, un izrādÄ«jās, ka kopumā serveri bija pieejami (pareizi reaģējot uz ping testu un citiem pieprasÄ«jumiem), taču pakalpojumu attālinātā piekļuve Å”ajos serveros vai nu pieņem jaunus savienojumus, vai tos noraida, un mēs runājām par serveriem dažādās vietnēs, kuru trafika nāk no dažādiem datu pārraides kanāliem.

Paskatīsimies uz Ŕo satiksmi. Pakete ar savienojuma pieprasījumu nonāk 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


Serveris saņem Å”o paketi, bet noraida savienojumu:

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


Tas nozÄ«mē, ka problēmu nepārprotami rada nevis kādas problēmas infrastruktÅ«ras darbÄ«bā, bet gan kas cits. VarbÅ«t visiem lietotājiem ir problēmas ar attālās darbvirsmas licencÄ“Å”anu? VarbÅ«t kāda veida ļaunprogrammatÅ«ra spēja iekļūt viņu sistēmās, un Å”odien tā tika aktivizēta, tāpat kā pirms pāris gadiem XData Šø Petja?

Kamēr to kārtojām, saņēmām līdzīgus pieprasījumus no vēl vairākiem klientiem un partneriem.
Kas patiesībā notiek Ŕajās maŔīnās?

Notikumu žurnāli ir pilni ar ziņojumiem par mēģinājumiem uzminēt paroli:

DDoS uzbrukums RDP pakalpojumiem: atpazīt un cīnīties. Veiksmīga pieredze no Tucha

Parasti Ŕādi mēģinājumi tiek reÄ£istrēti visos serveros, kur attālās piekļuves pakalpojumam tiek izmantots standarta ports (3389) un piekļuve ir atļauta no jebkuras vietas. Internets ir pilns ar robotprogrammatÅ«ru, kas pastāvÄ«gi skenē visus pieejamos savienojuma punktus un mēģina uzminēt paroli (tāpēc mēs ļoti iesakām izmantot sarežģītas paroles, nevis ā€œ123ā€). Tomēr Å”o mēģinājumu intensitāte tajā dienā bija pārāk augsta.

Kā turpināt?

Vai ieteikt klientiem pavadÄ«t daudz laika, mainot iestatÄ«jumus, lai liels skaits galalietotāju pārslēgtos uz citu portu? Nav laba ideja, klienti nebÅ«s apmierināti. Vai ieteikt atļaut piekļuvi tikai caur VPN? Steigā un panikā audzinot IPSec savienojumus tiem, kam tie nav audzināti - iespējams, tāda laime nesmaida arÄ« klientiem. Lai gan, jāsaka, tas jebkurā gadÄ«jumā ir dievbijÄ«ga lieta, mēs vienmēr iesakām paslēpt serveri privātajā tÄ«klā un esam gatavi palÄ«dzēt ar iestatÄ«jumiem, un tiem, kam patÄ«k to izdomāt paÅ”iem, mēs dalāmies instrukcijās IPSec/L2TP iestatÄ«Å”anai mÅ«su mākonÄ« starp vietni vai ceļu režīmā -warrior, un, ja kāds vēlas iestatÄ«t VPN pakalpojumu savā Windows serverÄ«, viņŔ vienmēr ir gatavs dalÄ«ties ar padomiem, kā iestatÄ«t standarta RAS vai OpenVPN. Taču, lai arÄ« cik forÅ”i mēs bijām, Å”is nebija labākais laiks, lai veiktu izglÄ«tojoÅ”u darbu klientu vidÅ«, jo problēma bija jānovērÅ” pēc iespējas ātrāk ar minimālu stresu lietotājiem.

Risinājums, ko ieviesām, bija Ŕāds. Mēs esam izveidojuÅ”i caurlaidÄ«gās trafika analÄ«zi tā, lai pārraudzÄ«tu visus mēģinājumus izveidot TCP savienojumu ar portu 3389 un atlasÄ«tu no tā adreses, kas 150 sekunžu laikā mēģina izveidot savienojumus ar vairāk nekā 16 dažādiem serveriem mÅ«su tÄ«klā. - tie ir uzbrukuma avoti (Protams, ja kādam no klientiem vai partneriem ir reāla vajadzÄ«ba izveidot savienojumus ar tik daudziem serveriem no viena avota, jÅ«s vienmēr varat pievienot Ŕādus avotus ā€œbaltajam sarakstamā€. Turklāt, ja vienā C klases tÄ«klā Å”ajās 150 sekundēs tiek identificētas vairāk nekā 32 adreses, ir jēga bloķēt visu tÄ«klu. BloÄ·Ä“Å”ana tiek iestatÄ«ta uz 3 dienām, un, ja Å”ajā laikā netika veikts neviens uzbrukums no noteikta avota, Å”is avots tiek automātiski noņemts no ā€œmelnā sarakstaā€. Bloķēto avotu saraksts tiek atjaunināts ik pēc 300 sekundēm.

DDoS uzbrukums RDP pakalpojumiem: atpazīt un cīnīties. Veiksmīga pieredze no Tucha

Å is saraksts ir pieejams Å”ajā adresē: https://secure.tucha.ua/global-filter/banned/rdp_ddos, varat izveidot savus ACL, pamatojoties uz to.

Mēs esam gatavi dalÄ«ties ar Ŕādas sistēmas pirmkodu, tajā nav nekā pārāk sarežģīta (tie ir vairāki vienkārÅ”i skripti, kas apkopoti burtiski pāris stundu laikā), un tajā paŔā laikā to var pielāgot un izmantot ne. tikai, lai aizsargātu pret Ŕādu uzbrukumu, bet arÄ« atklātu un bloķētu visus mēģinājumus skenēt tÄ«klu: sekojiet Å”ai saitei.

Turklāt esam veikuÅ”i dažas izmaiņas uzraudzÄ«bas sistēmas iestatÄ«jumos, kas tagad stingrāk uzrauga mÅ«su mākonÄ« esoÅ”o virtuālo serveru kontroles grupas reakciju uz mēģinājumu izveidot LAP savienojumu: ja reakcija neseko otrkārt, tas ir iemesls pievērst uzmanÄ«bu.

Risinājums izrādījās diezgan efektīvs: vairs nav sūdzību ne no klientiem, ne partneriem, ne no uzraudzības sistēmas. Melnajam sarakstam regulāri tiek pievienotas jaunas adreses un veseli tīkli, kas norāda, ka uzbrukums turpinās, bet vairs neietekmē mūsu klientu darbu.

DroŔība ir skaitļos

Å odien uzzinājām, ka citi operatori ir saskāruÅ”ies ar lÄ«dzÄ«gu problēmu. Kāds joprojām uzskata, ka Microsoft veica dažas izmaiņas attālās piekļuves pakalpojuma kodā (ja atceraties, mums jau pirmajā dienā bija aizdomas par to paÅ”u, bet mēs ļoti ātri noraidÄ«jām Å”o versiju) un sola darÄ«t visu iespējamo, lai ātri atrastu risinājumu. . Daži cilvēki vienkārÅ”i ignorē problēmu un iesaka klientiem paÅ”iem sevi aizsargāt (mainÄ«t savienojuma portu, paslēpt serveri privātajā tÄ«klā utt.). Un jau pirmajā dienā mēs ne tikai atrisinājām Å”o problēmu, bet arÄ« izveidojām pamatu globālākai draudu noteikÅ”anas sistēmai, kuru plānojam izstrādāt.

DDoS uzbrukums RDP pakalpojumiem: atpazīt un cīnīties. Veiksmīga pieredze no Tucha

ÄŖpaÅ”s paldies klientiem un sadarbÄ«bas partneriem, kuri neklusēja un nesēdēja upes krastā, gaidot, kad kādu dienu pa to uzpeldēs ienaidnieka lÄ«Ä·is, bet gan uzreiz vērsa mÅ«su uzmanÄ«bu uz problēmu, kas deva iespēju novērst to tajā paŔā dienā.

Avots: www.habr.com

Pievieno komentāru