RDP xidmətlərinə DDoS hücumu: tanımaq və aradan qaldırmaq. Tuchadan uğurlu təcrübə

Gəlin sizə “üçüncü tərəflərin” müştərilərimizə necə müdaxilə etməyə çalışdığı və bu problemin necə həll edildiyi barədə gözəl bir hekayə danışaq.

Hər şey necə başladı

Hər şey oktyabrın 31-i səhər saatlarında, ayın son günü, çoxlarının təcili və vacib məsələləri bağlamağa vaxt tapmalı olduğu vaxt başladı.

Buludumuzda xidmət etdiyi müştərilərin bir neçə virtual maşınını saxlayan partnyorlardan biri bildirdi ki, saat 9:10-dan 9:20-dək Ukrayna saytımızda işləyən bir neçə Windows serveri bir anda uzaqdan giriş xidmətinə qoşulma qəbul etməyib. istifadəçilər öz masaüstü kompüterlərinə daxil ola bilmədilər, lakin bir neçə dəqiqədən sonra problem öz-özünə aradan qalxdı.

Rabitə kanallarının statistikasını qaldırdıq, lakin heç bir trafik partlayışı və ya nasazlıq aşkar etmədik. Biz hesablama resurslarına yüklənmənin statistikasına baxdıq - heç bir anomaliya yox idi. Və bu nə idi?

Sonra buludumuzda daha yüz serverə sahib olan başqa bir tərəfdaş, bəzi müştərilərinin qeyd etdiyi eyni problemləri bildirdi, halbuki, ümumiyyətlə serverlərin mövcud olduğu (ping-test və digər sorğulara düzgün cavab verir), lakin xidmət Bu serverlərə uzaqdan giriş ya yeni bağlantıları qəbul edir, ya da onları rədd edir, biz müxtəlif saytlardakı serverlərdən danışarkən, trafik müxtəlif məlumat ötürmə kanallarından gəlir.

Gəlin bu trafikə nəzər salaq. Bağlantı qurmaq tələbi olan paket serverə gəlir:

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 bu paketi qəbul edir, lakin əlaqə rədd edilir:

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


Bu o deməkdir ki, problem infrastrukturda hər hansı nasazlıqdan deyil, başqa bir şeydən qaynaqlanır. Bəlkə bütün istifadəçilərin uzaqdan iş masası lisenziyası ilə bağlı problemləri var? Ola bilsin ki, bir növ zərərli proqram onların sistemlərinə nüfuz etməyi bacarıb və bir neçə il əvvəl olduğu kimi bu gün də aktivləşib. XData и Petya?

Onu çeşidləyərkən daha bir neçə müştəri və tərəfdaşdan oxşar sorğular aldıq.
Bu maşınlarda əslində nə baş verir?

Hadisə qeydləri parolu təxmin etməyə cəhdlə bağlı mesajlarla doludur:

RDP xidmətlərinə DDoS hücumu: tanımaq və aradan qaldırmaq. Tuchadan uğurlu təcrübə

Tipik olaraq, bu cür cəhdlər standart portun (3389) uzaqdan giriş xidməti üçün istifadə edildiyi və istənilən yerdən girişə icazə verildiyi bütün serverlərdə qeyd olunur. İnternet bütün mövcud əlaqə nöqtələrini daim skan edən və parolu təxmin etməyə çalışan botlarla doludur (buna görə biz “123” əvəzinə mürəkkəb parollardan istifadə etməyi tövsiyə edirik). Lakin həmin gün bu cəhdlərin intensivliyi çox yüksək idi.

Nə etməliyəm?

Müştərilərin fərqli bir porta keçmək üçün çox sayda son istifadəçinin parametrlərini dəyişdirməyə çox vaxt sərf etmələrini tövsiyə edirsiniz? Yaxşı fikir deyil, müştərilər məmnun olmayacaq. Yalnız VPN vasitəsilə girişə icazə verməyi tövsiyə edirsiniz? Tələsik və çaxnaşma içində, onları böyütməyənlər üçün IPSec əlaqələrini artırmaq - bəlkə də belə xoşbəxtlik müştərilərə də gülümsəmir. Deməliyəm ki, bu, hər halda xeyriyyə işidir, biz həmişə serveri şəxsi şəbəkədə gizlətməyi tövsiyə edirik və parametrlərdə kömək etməyə hazırıq və bunu özbaşına başa düşməyi sevənlər üçün təlimatları paylaşırıq. saytdan sayta və ya yol rejimində buludumuzda IPSec / L2TP qurmaq üçün - döyüşçü və hər kəs öz Windows serverində VPN xidməti qurmaq istəsə, hər zaman IPSec / LXNUMXTP-ni necə qurmaq barədə məsləhətləri bölüşməyə hazırdır. standart RAS və ya OpenVPN. Ancaq nə qədər sərin olsaq da, müştərilərin maarifləndirilməsi üçün ən yaxşı vaxt deyildi, çünki istifadəçilərə mümkün qədər az müdaxilə etməklə problemi mümkün qədər tez həll etməli idik.

Tətbiq etdiyimiz həll aşağıdakı kimi idi. Biz ötürmə trafikinin təhlilini elə qurmuşuq ki, 3389 nömrəli porta TCP bağlantısı qurmaq üçün bütün cəhdləri izləyək və ondan 150 saniyə ərzində şəbəkəmizdəki 16-dan çox müxtəlif serverlə əlaqə yaratmağa çalışan ünvanları seçək - bunlar hücum mənbələri (əlbəttə, əgər müştərilərdən və ya partnyorlardan birinin eyni mənbədən bu qədər serverlə əlaqə yaratmağa real ehtiyacı varsa, siz həmişə belə mənbələri “ağ siyahıya” əlavə edə bilərsiniz. Üstəlik, bir sinifdə olarsa. Bu 150 saniyə ərzində C şəbəkəsi, 32-dən çox ünvan müəyyən edilib, bütün şəbəkəni bloklamaq mənasızdır.Bloklama 3 gün müddətinə təyin edilir və bu müddət ərzində bu mənbədən heç bir hücum edilməyibsə, bu mənbədən silinir. avtomatik olaraq "qara siyahı" bloklanmış mənbələrin siyahısı hər 300 saniyədən bir yenilənir.

RDP xidmətlərinə DDoS hücumu: tanımaq və aradan qaldırmaq. Tuchadan uğurlu təcrübə

Bu siyahı burada mövcuddur: https://secure.tucha.ua/global-filter/banned/rdp_ddos, siz onun əsasında ACL-lərinizi yarada bilərsiniz.

Biz belə bir sistemin mənbə kodunu paylaşmağa hazırıq, orada çox mürəkkəb bir şey yoxdur (bunlar bir neçə saat ərzində "diz üstə" tərtib edilmiş bir neçə sadə skriptdir) və eyni zamanda uyğunlaşdırıla bilər. və yalnız belə bir hücumdan qorunmaq üçün deyil, həm də şəbəkəni skan etmək cəhdlərini aşkar etmək və bloklamaq üçün istifadə olunur: bu linki izləyin.

Bundan əlavə, biz indi buludumuzdakı virtual serverlərin nəzarət qrupunun RDP bağlantısı qurmaq cəhdinə reaksiyasını daha yaxından izləyən monitorinq sisteminin parametrlərində bəzi dəyişikliklər etdik: reaksiya bir saniyə ərzində baş verməsə , bu diqqət yetirmək üçün bir səbəbdir.

Həll olduqca təsirli oldu: həm müştərilərdən, həm tərəfdaşlardan, həm də monitorinq sistemindən artıq şikayətlər yoxdur. Yeni ünvanlar və bütün şəbəkələr mütəmadi olaraq qara siyahıya düşür, bu da hücumun davam etdiyini, lakin artıq müştərilərimizin işinə təsir etmədiyini göstərir.

Rəqəmlərdə təhlükəsizlik var

Bu gün digər operatorların da oxşar problemlə üzləşdiyini öyrəndik. Kimsə hələ də Microsoft-un uzaqdan giriş xidmətinin kodunda bəzi dəyişikliklər etdiyinə inanır (xatırlayırsınızsa, biz ilk gündə eyni şeydən şübhələnirdik, lakin bu versiyanı çox tezliklə rədd etdik) və daha çox həll tapmaq üçün mümkün olan hər şeyi edəcəyini vəd edir. . Kimsə sadəcə problemə məhəl qoymur və müştərilərə özlərini müdafiə etməyi məsləhət görür (bağlantı portunu dəyişdirin, serveri şəxsi şəbəkədə gizlədin və s.). Və elə ilk gündə biz nəinki bu problemi həll etdik, həm də inkişaf etdirməyi planlaşdırdığımız daha qlobal təhlükənin aşkarlanması sistemi üçün bəzi əsaslar yaratdıq.

RDP xidmətlərinə DDoS hücumu: tanımaq və aradan qaldırmaq. Tuchadan uğurlu təcrübə

Səssiz qalmayan, çayın sahilində oturub düşmən meyitinin bir gün çayın kənarında üzməsini gözləyən, lakin dərhal diqqətimizi problemə cəlb edən müştərilərə və partnyorlara xüsusi təşəkkürlər. eyni gündə onu aradan qaldırın.

Mənbə: www.habr.com

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