Sizə "üçüncü tərəflərin" müştərilərimizin fəaliyyətinə necə mane olmağa çalışdığı və bu problemin necə həll olunduğu ilə bağlı maraqlı bir hekayə danışacağıq.
Hər şey necə başladı
Hər şey 31 oktyabr, ayın sonuncu günü başlayan səhərdən başladı, bir çoxları üçün təcili və vacib məsələləri həll etmək üçün vaxt yetişmişdi.
Bir tərəfdaş, bizim buludda müştərilərinə xidmət edən bir neçə virtual maşın saxlayan, 9:10-dan 9:20-ə qədər bir neçə Windows serverinin, bizim Ukrayna platformamızda, uzaq giriş xidmətinə qoşulmadığını bildirdi. İstifadəçilər iş masalarına daxil ola bilmədilər, lakin bir neçə dəqiqə sonra problem sanki öz-özünə aradan qaldı.
Biz əlaqə kanallarının statistikalarına baxdıq, lakin nə trafik artımı, nə də düşmələri aşkar edə bildik. Hesablamalı resursların yük statistikalarına baxdıq - heç bir anomaliya yox idi. Bəs bu nə idi?
Daha sonra bizim buludda yüzə yaxın server yerləşdirən başqa bir tərəfdaş da eyni problemlərdən bəhs etdi, müştərilərindən bəziləri bunu qeyd etdi, nəticədə bütün serverlərin əlçatan olduğu (ping testinə və digər sorğulara cavab verildiyi) aydın oldu, amma bu serverlərdə uzaq giriş xidməti bəzən yeni əlaqələri qəbul edir, bəzən isə onları rədd edirdi. Həmin serverlər fərqli platformalarda yerləşirdi və onlara müxtəlif məlumat ötürmə kanallarından trafik gəlirdi.
Gəlin bu trafikə baxaq. Bağlantı qurmaq üçün sorğu paketi 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 alır, lakin əlaqəni rədd edir:
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, problemin infrastrukturda baş verən nasazlıqlardan qaynaqlanmadığını, başqa bir səbəbi olduğunu göstərir. Bəlkə də, bütün istifadəçilərin uzaq iş masalarının lisensiyalaşdırılmasında problemləri yaranıb? Bəlkə də, onların sistemlərinə zərərli proqram daxil olub və bu gün aktivləşdi, iki il əvvəl baş verdiyi kimi XData və Petya?
Məsələni araşdırarkən, başqa bir neçə müştəridən və tərəfdaşdan da analoji müraciətlər aldıq.
Bu maşınlarda nə baş verir?
Hadisələrin qeyd jurnalında parolun tapılmasına cəhd edənlərin çox sayda mesajı var:
Adətən, belə cəhdlər, uzaq giriş xidməti üçün standart port (3389) istifadə edildikdə və hər yerə giriş icazəsi verildikdə bütün serverlərdə qeydə alınır. İnternetdə, bütün mövcud qoşulma nöqtələrini skan edən və parol tapmağa çalışan bir çox bot var (məhz buna görə biz sizə "123" yerinə mürəkkəb parollar istifadə etməyi tövsiyə edirik). Ancaq, həmin gün bu cəhdlərin intensivliyi çox yüksək idi.
Necə davranmalı?
Müştərilərə, çoxsaylı son istifadəçilərin parametrlərini dəyişdirmək üçün bir ton vaxt sərf etmələrini tövsiyə etmək, başqa bir porta keçmək üçün? Bu, çox yaxşı bir fikir deyil, müştərilər məmnun olmayacaq. Yalnız VPN vasitəsilə giriş verilməsini tövsiyə etmək? Təcili və panikada IPSec bağlantılarını qurmaq, kiminin olmadığına görə - müştərilər üçün belə bir bəxt də olmur. Yaxşı, qeyd edək ki, bu, hər halda xeyirxah bir işdir, biz həmişə serveri xüsusi bir şəbəkədə gizlətməyi tövsiyə edirik və parametrlərlə kömək etməyə hazırıq, özləri müstəqil işləmək istəyənlər üçün, site-to-site və ya road-warrior rejimində IPSec/L2TP-nin quraşdırılması üçün təlimatları paylaşırıq, birisi öz Windows serverində VPN xidməti quraşdırmaq istəyirsə, standart RAS və ya OpenVPN-in quraşdırılması ilə bağlı ipuclarını paylaşmağa həmişə hazırıq. Amma, nə qədər əla olsaq da, müştərilər arasında maarifləndirmə aparmaq üçün ən yaxşı vaxt deyildi, çünki problemi minimum narahatlıqla aradan qaldırmaq lazım idi.
İmplementasiya etdiyimiz həll aşağıdakı kimidir. Biz, keçən trafikin analizini elə nizamlamağı bacardıq ki, 3389 portuna TCP bağlantısı qurmağa cəhd edən bütün ünvanları izləsin və 150 saniyə ərzində şəbəkəmizdə 16 fərqli server ilə bağlantılar qurmağa cəhd edən ünvanları seçsin - bunlar hücum mənbələridir (müştərilərdən və ya tərəfdaşlardan kiminsə reallıqda bu qədər serverlə bir mənbədən bağlantı qurmağa ehtiyacı varsa, daim belə mənbələri
Bu siyahı aşağıdakı ünvanda mövcuddur: , onu əsasında öz ACL-inizi qura bilərsiniz.
Belə bir sistemin mənbə kodunu paylaşmağa hazırıq, burada heç bir mürəkkəb şey yoxdur (bir neçə sadə skript, bir neçə saat ərzində "dizayn edilmiş"), eyni zamanda bu, yalnız belə bir hücumdan qorumaq üçün deyil, həmçinin şəbəkənin taranması cəhdlərini aşkar etmək və bloklamaq üçün uyğunlaşdırıla bilər:
Bundan əlavə, sistem monitorinq parametrlərində bəzi dəyişikliklər etdik, beləliklə, buludumuzdakı virtual serverlərin nəzarət qrupu RDP bağlantısını qurmağa cəhdlərə reaksiya verərkən daha yaxından izlənilir: əgər bir saniyə ərzində reaksiya verilməsə, bu, diqqətin cəlb olunması üçün bir səbəbdir.
Həll olduqca effektiv oldu: müştəri və tərəfdaşlardan, eləcə də monitorinq sistemindən şikayət yoxdur. "Qara siyahı" davamlı olaraq yeni ünvanlar və tam şəbəkələri əlavə edir, bu da xəbərlərin hələ də davam etdiyini amma artıq müştərilərimizin işinə təsir etmədiyini göstərir.
Bir adam tək başına savaşçı deyil.
Bu gün oxşar problemlərlə üzləşən digər operatorların da olduğunu bildik. Bəziləri hələ də düşünür ki, bu, Microsoft-un uzaqdan giriş xidmətinin kodunu dəyişməsi ilə bağlıdır (xatırlayırsınızsa, ilk gün bunu təxmin etdik, amma bu fərziyyəni tez bir zamanda inkar etdik) və mümkün olan ən qısa zamanda bir həll tapmaq üçün əlindən gələni edəcəyini vəd edir. Bəziləri sadəcə problemi görməzdən gəlir və müştərilərə öz gücləri ilə müdafiə olunmağı tövsiyə edir (bağlantı portunu dəyişmək, serveri xüsusi şəbəkədə gizlətmək və sair). Biz isə ilk gündən yalnız bu problemi həll etmədi, həm də inkişaf etdirməyi planlaşdırdığımız daha geniş bir təhlükə aşkarlama sistemi üçün müəyyən bir təməl yaratdıq.
Susmayan və düşmən cəsədinin bir gün axınla keçəcəyini gözləməyən müştərilərimizə və tərəfdaşlarımıza ayrıca təşəkkür edirik, çünki ilk gündən problemə diqqətimizi yönəltdilər və bu da elə həmin gün onu aradan qaldırmağımıza imkan verdi.
Mənbə: habr.com
