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

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

Ինչպե՞ս ամենthing սկսվեց

Այն սկսվեց 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 և Petya?

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

Ծրագրերի հաշվարկման գրքերում լցված են հաղորդագրություններ՝ մուտքային գաղտնաբառի ստեղծման փորձերի մասին։

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

Ինչպե՞ս վարվենք։

Հաճախակի խորհուրդ տալ հաճախորդներին dedicating մեծ ժամանակ, որպեսզի փոխել կարգավորումները բազմաթիվ վերջնական օգտվողների համար, անցնելու այլ պորտի՞: Քանի որ դա շատ լավ գաղափար չէ, հաճախորդները չեն գոհ լինի։ Շնորհավորել թույլտվություն միայն VPN-ի միջոցով: Շտապ և անհանգիստ վերաբերմունքով բարձրացնել IPSec-կապեր, որտեղ նրանք չեն բարձրացել, կարող է լինել, որ հաճախորդներին այդպիսի երջանկություն նույնպես չի ծիծաղում: Շնորհիվ դրա, հարկ է ասել, դա, ի վերջո, Աստծո սխրանք է, մենք միշտ խորհուրդ ենք տալիս թաքցնել սերվերները մասնավոր ցանցում և պատրաստ ենք աջակցել կարգավորումներում, իսկ ինքնուրույն լուծումներ փնտրողներին տրամադրում ենք ուղեցույցներ IPSec/L2TP կարգավորումների համար մեր ամպում site-to-site կամ road-warrior ռեժիմում, իսկ եթե որեւէ մեկի ցանկություն է բարձրացնել VPN-ծառի իր սեփական Windows-սերվեր, միշտ պատրաստ ենք կիսվել պարզանման տեղեկություններով, թե ինչպես բարձրացնել ստանդարտ RAS կամ OpenVPN: Սակայն, որքան էլ մենք դուր հաջորդ լինենք, դա լավագույն ժամանակը չէր տեղեկացված աշխատել հաճախորդների շրջանում, քանի որ անհրաժեշտ էր հնարավորինս արագ լուծել խնդիրը նվազագույն հարմարավետությամբ օգտվողների համար։

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

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

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

علاوه بر این، ما تغییراتی در تنظیمات سیستم نظارت اعمال کردیم که اکنون به طور دقیق‌تری واکنش گروه کنترل سرورهای مجازی در فضای ابری ما را نسبت به تلاش برای برقراری اتصال RDP زیر نظر دارد: اگر واکنشی در مدت یک ثانیه صورت نگیرد، این یک زنگ هشدار است.

این راه‌حل به اندازه کافی مؤثر واقع شد: دیگر شکایت‌هایی از طرف مشتریان و شرکای ما و همچنین از سوی سیستم نظارت وجود ندارد. هر روز آدرس‌ها و شبکه‌های جدیدی به «لیست سیاه» اضافه می‌شوند، که نشان می‌دهد حمله ادامه دارد، اما دیگر روی کار ما تأثیری ندارد.

یک نفر در میدان جنگ نیست.

امروز متوجه شدیم که سایر اپراتورها نیز با مشکل مشابهی مواجه شده‌اند. برخی هنوز بر این باورند که این اصلاحات توسط مایکروسافت در کد سرویس دسترسی از راه دور انجام شده است (اگر به یاد داشته باشید، ما در همان روز اول مشکوک به این موضوع شدیم، اما خیلی زود این فرضیه را رد کردیم) و قول داده‌اند که تمام تلاش خود را به کار گیرند تا هرچه سریع‌تر راه حلی پیدا کنند. برخی دیگر به سادگی مشکل را نادیده می‌گیرند و به مشتریان توصیه می‌کنند که با تلاش‌های خود از خود محافظت کنند (تغییر پورت اتصال، پنهان کردن سرور در یک شبکه خصوصی و غیره). و ما در همان روز اول نه تنها این مشکل را حل کردیم، بلکه پایه‌ای برای یک سیستم جامع‌تر شناسایی تهدیدات ایجاد کردیم که قصد داریم آن را توسعه دهیم.

تشکر ویژه از مشتریان و شرکایی که سکوت نکردند و در کنار کنار رودخانه نشسته منتظر نماندند که یک روز جنازه دشمن از آن عبور کند و بلافاصله توجه ما را به مشکل جلب کردند، که به ما این امکان را داد تا همان روز آن را حل کنیم.

Ընտանիք: habr.com