DDoS հարձակում RDP ծառայությունների վրա. ճանաչել և պայքարել: Հաջողակ փորձ Tucha-ից

Եկեք պատմենք ձեզ մի թույն պատմություն այն մասին, թե ինչպես են «երրորդ կողմերը» փորձել խանգարել մեր հաճախորդների աշխատանքին, և ինչպես լուծվեց այս խնդիրը:

Ինչպես ամեն ինչ սկսվեց

Ամեն ինչ սկսվեց հոկտեմբերի 31-ի առավոտյան՝ ամսվա վերջին օրը, երբ շատերին խիստ անհրաժեշտ է ժամանակ ունենալ հրատապ ու կարևոր հարցերը լուծելու համար։

Գործընկերներից մեկը, ով մեր ամպում պահում է հաճախորդների մի քանի վիրտուալ մեքենաներ, որոնց նա սպասարկում է, հաղորդում է, որ 9:10-ից 9:20-ը մեր ուկրաինական կայքում աշխատող Windows-ի մի քանի սերվերներ չեն ընդունում կապեր հեռահար մուտքի ծառայության հետ, օգտատերերը չեն կարողացել: մուտք գործելու համար իրենց աշխատասեղան, բայց մի քանի րոպե անց խնդիրն ինքն իրեն լուծվեց:

Մենք բարձրացրել ենք կապի ուղիների շահագործման վիճակագրությունը, սակայն երթևեկության աճեր կամ խափանումներ չենք հայտնաբերել: Մենք նայեցինք հաշվողական ռեսուրսների ծանրաբեռնվածության վիճակագրությունը՝ ոչ մի անոմալիա: Իսկ դա ի՞նչ էր։

Այնուհետև մեկ այլ գործընկեր, ով մեր ամպում հյուրընկալում է ևս հարյուր սերվեր, զեկուցեց նույն խնդիրների մասին, որոնք նշել էին իրենց որոշ հաճախորդներ, և պարզվեց, որ ընդհանուր առմամբ սերվերները հասանելի են (պատշաճ կերպով արձագանքում են ping թեստին և այլ հարցումներին), բայց ծառայության հեռահար մուտքն այս սերվերների վրա կա՛մ ընդունում է նոր կապեր, կա՛մ մերժում դրանք, և մենք խոսում էինք տարբեր կայքերի սերվերների մասին, որոնց տրաֆիկը գալիս է տվյալների փոխանցման տարբեր ալիքներից:

Եկեք նայենք այս տրաֆիկին: Միացման հարցումով փաթեթը հասնում է սերվեր.

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


Սերվերը ստանում է այս փաթեթը, բայց մերժում է կապը.

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


Սա նշանակում է, որ խնդիրն ակնհայտորեն պայմանավորված է ոչ թե ենթակառուցվածքի շահագործման հետ կապված խնդիրներով, այլ այլ բանով։ Միգուցե բոլոր օգտվողները խնդիրներ ունեն հեռահար աշխատասեղանի լիցենզավորման հետ: Միգուցե ինչ-որ չարամիտ ծրագիր է հաջողվել ներթափանցել նրանց համակարգեր, և այսօր այն ակտիվացել է, ինչպես մի քանի տարի առաջ էր: XData и Պետյա?

Մինչ մենք դասավորում էինք այն, մենք նմանատիպ հարցումներ ստացանք ևս մի քանի հաճախորդների և գործընկերներից:
Ի՞նչ է իրականում տեղի ունենում այս մեքենաներում:

Իրադարձությունների մատյանները լի են գաղտնաբառի գուշակման փորձերի մասին հաղորդագրություններով.

DDoS հարձակում RDP ծառայությունների վրա. ճանաչել և պայքարել: Հաջողակ փորձ Tucha-ից

Սովորաբար, նման փորձերը գրանցվում են բոլոր սերվերների վրա, որտեղ ստանդարտ պորտը (3389) օգտագործվում է հեռավոր մուտքի ծառայության համար, և մուտքը թույլատրվում է ամենուր: Համացանցը լի է բոտերով, որոնք անընդհատ սկանավորում են բոլոր հասանելի կապի կետերը և փորձում են գուշակել գաղտնաբառը (այդ իսկ պատճառով մենք խստորեն խորհուրդ ենք տալիս օգտագործել բարդ գաղտնաբառեր «123»-ի փոխարեն): Սակայն այդ փորձերի ինտենսիվությունն այդ օրը չափազանց բարձր էր։

Ինչ անել:

Առաջարկու՞մ եք, որ հաճախորդները շատ ժամանակ ծախսեն՝ փոխելով պարամետրերը հսկայական թվով վերջնական օգտագործողների համար՝ այլ նավահանգիստ անցնելու համար: Լավ գաղափար չէ, հաճախորդները գոհ չեն լինի: Առաջարկո՞ւմ եք թույլատրել մուտքը միայն VPN-ի միջոցով: Շտապում և խուճապի մեջ բարձրացնելով IPSec կապերը նրանց համար, ովքեր չունեն դրանք բարձրացված, միգուցե նման երջանկությունը նույնպես չի ժպտում հաճախորդներին: Չնայած, պետք է ասեմ, որ սա ամեն դեպքում աստվածահաճո բան է, մենք միշտ խորհուրդ ենք տալիս սերվերը թաքցնել մասնավոր ցանցում և պատրաստ ենք օգնել կարգավորումներում, իսկ նրանց համար, ովքեր սիրում են դա ինքնուրույն պարզել, կիսվում ենք հրահանգներով: IPSec/L2TP մեր ամպում կայք-կայք կամ ճանապարհային ռեժիմում տեղադրելու համար՝ Warrior, և եթե որևէ մեկը ցանկանում է տեղադրել VPN ծառայություն իր Windows սերվերի վրա, նրանք միշտ պատրաստ են կիսվել խորհուրդներով, թե ինչպես ստեղծել ստանդարտ RAS կամ OpenVPN: Բայց, անկախ նրանից, թե որքան լավ էինք մենք, սա լավագույն ժամանակը չէր հաճախորդների շրջանում կրթական աշխատանք իրականացնելու համար, քանի որ մենք պետք է հնարավորինս արագ շտկենք խնդիրը օգտատերերի համար նվազագույն սթրեսով:

Մեր իրականացրած լուծումը հետեւյալն էր. Մենք ստեղծել ենք անցնող տրաֆիկի վերլուծություն այնպես, որ վերահսկենք 3389 պորտին TCP կապ հաստատելու բոլոր փորձերը և ընտրենք հասցեներից, որոնք 150 վայրկյանի ընթացքում կփորձեն կապեր հաստատել մեր ցանցի ավելի քան 16 տարբեր սերվերների հետ։ - սրանք են հարձակման աղբյուրները ( Իհարկե, եթե հաճախորդներից կամ գործընկերներից մեկն իրական կարիք ունի նույն աղբյուրից այդքան շատ սերվերների հետ կապեր հաստատելու, դուք միշտ կարող եք նման աղբյուրներ ավելացնել «սպիտակ ցուցակում»: Ավելին, եթե մեկ C դասի ցանցում այս 150 վայրկյանի ընթացքում հայտնաբերվում են 32-ից ավելի հասցեներ, իմաստ ունի արգելափակել ամբողջ ցանցը: Արգելափակումը սահմանված է 3 օրով, և եթե այս ընթացքում որևէ հարձակում չի իրականացվել տվյալ աղբյուրից, այս աղբյուրը ավտոմատ կերպով հեռացվում է «սև ցուցակից»: Արգելափակված աղբյուրների ցանկը թարմացվում է 300 վայրկյանը մեկ:

DDoS հարձակում RDP ծառայությունների վրա. ճանաչել և պայքարել: Հաջողակ փորձ Tucha-ից

Այս ցանկը հասանելի է այս հասցեով. https://secure.tucha.ua/global-filter/banned/rdp_ddos, դրա հիման վրա կարող եք կառուցել ձեր ACL-ները:

Մենք պատրաստ ենք կիսվել նման համակարգի սկզբնաղբյուրով, դրանում չափազանց բարդ բան չկա (սրանք մի քանի պարզ սցենարներ են, որոնք կազմվել են բառացիորեն մի քանի ժամվա ընթացքում ծնկի վրա), և միևնույն ժամանակ այն կարելի է հարմարեցնել և օգտագործել ոչ միայն նման հարձակումից պաշտպանվելու, այլ նաև ցանցի սկանավորման ցանկացած փորձ հայտնաբերելու և արգելափակելու համար. հետևեք այս հղմանը.

Բացի այդ, մենք որոշ փոփոխություններ ենք կատարել մոնիտորինգի համակարգի կարգավորումներում, որն այժմ ավելի ուշադիր հետևում է մեր ամպի վիրտուալ սերվերների կառավարման խմբի արձագանքին RDP կապ հաստատելու փորձին. եթե արձագանքը չի հետևում մի երկրորդ՝ սա ուշադրություն դարձնելու առիթ է։

Լուծումը բավականին արդյունավետ է ստացվել. այլևս դժգոհություններ չկան թե՛ հաճախորդների, թե՛ գործընկերների կողմից, թե՛ մոնիտորինգի համակարգից։ Նոր հասցեներ և ամբողջ ցանցեր պարբերաբար ավելացվում են սև ցուցակում, ինչը ցույց է տալիս, որ հարձակումը շարունակվում է, բայց այլևս չի ազդում մեր հաճախորդների աշխատանքի վրա:

Թվերի մեջ կա անվտանգություն

Այսօր տեղեկացանք, որ նմանատիպ խնդրի են բախվել նաև այլ օպերատորներ։ Ինչ-որ մեկը դեռ հավատում է, որ Microsoft-ը որոշ փոփոխություններ է կատարել հեռահար մուտքի ծառայության կոդում (եթե հիշում եք, մենք նույն բանը կասկածում էինք առաջին օրը, բայց շատ արագ մերժեցինք այս տարբերակը) և խոստանում է անել հնարավոր ամեն ինչ արագ լուծում գտնելու համար։ . Որոշ մարդիկ պարզապես անտեսում են խնդիրը և հաճախորդներին խորհուրդ են տալիս ինքնուրույն պաշտպանվել (փոխել կապի պորտը, թաքցնել սերվերը մասնավոր ցանցում և այլն): Եվ հենց առաջին օրը մենք ոչ միայն լուծեցինք այս խնդիրը, այլև որոշ հիմքեր ստեղծեցինք ավելի գլոբալ սպառնալիքների հայտնաբերման համակարգի համար, որը մենք նախատեսում ենք զարգացնել:

DDoS հարձակում RDP ծառայությունների վրա. ճանաչել և պայքարել: Հաջողակ փորձ Tucha-ից

Հատուկ շնորհակալություն հաճախորդներին և գործընկերներին, ովքեր չլռեցին և չնստեցին գետի ափին, սպասելով, որ մի օր թշնամու դիակը լողանա դրա երկայնքով, բայց անմիջապես մեր ուշադրությունը հրավիրեցին խնդրի վրա, որը մեզ հնարավորություն տվեց վերացնելու. այն նույն օրը։

Source: www.habr.com

Добавить комментарий