Variti botlara və DDoS hücumlarına qarşı müdafiəni inkişaf etdirir, həmçinin stress və yük testləri aparır. HighLoad++ 2018 konfransında biz resursları müxtəlif növ hücumlardan necə qorumaq barədə danışdıq. Qısacası: sistemin hissələrini təcrid edin, bulud xidmətlərindən və CDN-lərdən istifadə edin və müntəzəm olaraq yeniləyin. Ancaq mühafizəsi olan ixtisaslaşmış şirkətlər olmadan hələ də öhdəsindən gələ bilməzsiniz 🙂
Mətni oxumazdan əvvəl qısa tezisləri oxuya bilərsiniz .
Əgər oxumağı sevmirsinizsə və ya sadəcə videoya baxmaq istəyirsinizsə, reportajımızın qeydi aşağıda spoylerin altındadır.
Hesabatın video çəkilişi
Bir çox şirkət artıq yük testini necə edəcəyini bilir, lakin hər kəs stress testi etmir. Bəzi müştərilərimiz hesab edir ki, onların saytı toxunulmazdır, çünki onlar yüksək yükləmə sisteminə malikdirlər və o, hücumlardan yaxşı qoruyur. Bunun tamamilə doğru olmadığını göstəririk.
Təbii ki, testlər keçirməzdən əvvəl müştəridən imza və möhürlə icazə alırıq və bizim köməyimizlə heç kimə DDoS hücumu etmək mümkün deyil. Sınaq müştərinin seçdiyi vaxtda, onun resursunun iştirakının minimal olduğu və girişlə bağlı problemlər müştərilərə təsir etməyəcəyi zaman aparılır. Bundan əlavə, sınaq zamanı hər zaman bir şey səhv ola biləcəyi üçün müştəri ilə daimi əlaqə saxlayırıq. Bu, nəinki əldə edilmiş nəticələr barədə hesabat verməyə, həm də sınaq zamanı nəyisə dəyişdirməyə imkan verir. Testin sonunda biz həmişə bir hesabat tərtib edirik, orada aşkar edilmiş çatışmazlıqları qeyd edirik və saytın zəif tərəflərini necə aradan qaldırmaq barədə tövsiyələr veririk.
Necə işləyirik
Test edərkən biz botneti təqlid edirik. Şəbəkələrimizdə yerləşməyən müştərilərlə işlədiyimiz üçün limitlərin və ya qorunmanın aktivləşdirilməsi səbəbindən testin ilk dəqiqədə bitməməsi üçün bir IP-dən deyil, öz alt şəbəkəmizdən yükləyirik. Üstəlik, əhəmiyyətli bir yük yaratmaq üçün öz kifayət qədər güclü test serverimiz var.
Postulatlar
Çox şey yaxşı demək deyil
Mənbəni uğursuzluğa nə qədər az yükləsək, bir o qədər yaxşıdır. Əgər siz saniyədə bir sorğu və ya hətta dəqiqədə bir sorğu ilə saytın fəaliyyətini dayandıra bilsəniz, bu, əladır. Çünki alçaqlıq qanununa görə, istifadəçilər və ya təcavüzkarlar təsadüfən bu xüsusi zəifliyə düşəcəklər.
Qismən uğursuzluq tamamlamaqdan yaxşıdır
Biz həmişə sistemləri heterojen etməyi məsləhət görürük. Üstəlik, onları yalnız konteynerləşdirmə ilə deyil, fiziki səviyyədə ayırmağa dəyər. Fiziki ayrılma halında, saytda bir şey uğursuz olsa belə, çox güman ki, o, fəaliyyətini tamamilə dayandırmayacaq və istifadəçilər hələ də funksionallığın ən azı bir hissəsinə çıxış əldə edəcəklər.
Düzgün memarlıq davamlılığın təməlidir
Resursun nasazlıqlara qarşı dözümlülüyü və hücumlara və yüklərə tab gətirmək qabiliyyəti dizayn mərhələsində, əslində, bir notebookda ilk blok diaqramların çəkilməsi mərhələsində qoyulmalıdır. Çünki ölümcül səhvlər sürünürsə, gələcəkdə onları düzəltmək mümkündür, lakin bu, çox çətindir.
Yalnız kod deyil, həm də konfiqurasiya yaxşı olmalıdır
Bir çox insanlar yaxşı inkişaf komandasının xidmət xətalarına dözümlülüyün zəmanəti olduğunu düşünür. Yaxşı inkişaf komandası həqiqətən lazımdır, lakin yaxşı əməliyyatlar, yaxşı DevOps da olmalıdır. Yəni bizə Linux və şəbəkəni düzgün konfiqurasiya edəcək, nginx-də konfiqurasiyaları düzgün yazacaq, limitlər təyin edəcək və s. mütəxəssislər lazımdır. Əks təqdirdə, resurs yalnız testdə yaxşı işləyəcək və istehsalda bir anda hər şey pozulacaq.
Yük və stress testi arasındakı fərqlər
Yük sınağı sistemin işləmə hədlərini müəyyən etməyə imkan verir. Stress testi sistemdəki zəif cəhətləri tapmağa yönəlib və bu sistemi sındırmaq və müəyyən hissələrin sıradan çıxması prosesində özünü necə aparacağını görmək üçün istifadə olunur. Eyni zamanda, yükün xarakteri, adətən, stress testinin başlanmasına qədər müştəri üçün naməlum olaraq qalır.
L7 hücumlarının fərqli xüsusiyyətləri
Biz adətən yük növlərini L7 və L3&4 yüklərə bölürük. L7 tətbiq səviyyəsində yükdür, əksər hallarda yalnız HTTP kimi başa düşülür, lakin biz TCP protokolu səviyyəsində istənilən yükü nəzərdə tuturuq.
L7 hücumları müəyyən fərqləndirici xüsusiyyətlərə malikdir. Birincisi, onlar birbaşa tətbiqə gəlirlər, yəni şəbəkə vasitələri ilə əks olunma ehtimalı azdır. Bu cür hücumlar məntiqdən istifadə edir və buna görə də CPU, yaddaş, disk, verilənlər bazası və digər resursları çox səmərəli və az trafiklə istehlak edirlər.
HTTP Flood
Hər hansı bir hücum halında, yükü yaratmaq emaldan daha asandır və L7 vəziyyətində bu da doğrudur. Hücum trafikini qanuni trafikdən ayırmaq həmişə asan deyil və çox vaxt bunu tezliyə görə etmək olar, lakin hər şey düzgün planlaşdırılıbsa, o zaman qeydlərdən hücumun harada olduğunu və qanuni istəklərin harada olduğunu başa düşmək mümkün deyil.
İlk misal olaraq HTTP Flood hücumunu nəzərdən keçirək. Qrafik göstərir ki, bu cür hücumlar adətən çox güclü olur, aşağıdakı nümunədə sorğuların pik sayı dəqiqədə 600 mini keçib.
HTTP Flood yük yaratmağın ən asan yoludur. O, adətən ApacheBench kimi bir növ yük testi vasitəsini götürür və sorğu və hədəf təyin edir. Belə sadə bir yanaşma ilə serverin önbelleğe alınması ehtimalı yüksəkdir, lakin onu əldə etmək asandır. Məsələn, sorğuya təsadüfi sətirlər əlavə etməklə, serveri daim təzə səhifəni qaytarmağa məcbur edəcək.
Həmçinin, bir yük yaratma prosesində istifadəçi-agent haqqında unutmayın. Populyar test alətlərinin bir çox istifadəçi agentləri sistem administratorları tərəfindən süzülür, bu halda yük sadəcə arxa hissəyə çatmaya bilər. Sorğuya brauzerdən az və ya çox etibarlı başlıq daxil etməklə nəticəni əhəmiyyətli dərəcədə yaxşılaşdıra bilərsiniz.
HTTP Flood hücumları sadə olsa da, onların çatışmazlıqları da var. Birincisi, bir yük yaratmaq üçün çox güc tələb olunur. İkincisi, bu cür hücumları aşkar etmək çox asandır, xüsusən də eyni ünvandan gəlirsə. Nəticədə sorğular ya sistem administratorları, ya da hətta provayder səviyyəsində dərhal süzülməyə başlayır.
Nə axtarmaq lazımdır
Saniyədə sorğuların sayını azaltmaq və eyni zamanda səmərəliliyini itirməmək üçün bir az təsəvvür göstərmək və saytı araşdırmaq lazımdır. Beləliklə, siz yalnız kanalı və ya serveri deyil, həm də proqramın ayrı-ayrı hissələrini, məsələn, verilənlər bazası və ya fayl sistemlərini yükləyə bilərsiniz. Siz həmçinin saytda böyük hesablamalar aparan yerləri axtara bilərsiniz: kalkulyatorlar, məhsul seçim səhifələri və s. Nəhayət, tez-tez olur ki, saytda bir neçə yüz min sətirdən ibarət səhifə yaradan bir növ php skripti var. Belə bir skript həm də serveri çox yükləyir və hücum hədəfinə çevrilə bilər.
Hara baxmaq
Sınaqdan əvvəl resursu skan edərkən, ilk növbədə, əlbəttə ki, saytın özünə baxırıq. Biz hər cür giriş sahələrini, ağır faylları - ümumiyyətlə, resurs üçün problem yarada bilən və onu ləngidə bilən hər şeyi axtarırıq. Google Chrome və Firefox-da adi inkişaf alətləri səhifənin cavab müddətini göstərən burada kömək edir.
Biz həmçinin subdomenləri skan edirik. Məsələn, müəyyən bir onlayn mağaza var, abc.com və onun admin.abc.com alt domeni var. Çox güman ki, bu, avtorizasiyası olan bir idarəetmə panelidir, ancaq ona bir yük qoysanız, əsas resurs üçün problemlər yarada bilər.
Saytın api.abc.com alt domeni ola bilər. Çox güman ki, bu, mobil proqramlar üçün resursdur. Tətbiqi App Store və ya Google Play-də tapmaq, xüsusi giriş nöqtəsi qurmaq, API-ni parçalamaq və test hesablarını qeydiyyatdan keçirmək olar. Problem ondadır ki, insanlar tez-tez avtorizasiya ilə qorunan hər şeyin xidmətdən imtina hücumlarına qarşı həssas olmadığını düşünürlər. İddiaya görə, avtorizasiya ən yaxşı CAPTCHA-dır, lakin belə deyil. 10-20 test hesabı yaratmaq asandır və onları yaratmaqla biz mürəkkəb və açıq funksionallıq əldə edirik.
Təbii ki, biz resursun köhnə versiyalarını axtararaq robots.txt və WebArchive, ViewDNS-də tarixə baxırıq. Bəzən elə olur ki, tərtibatçılar, məsələn, mail2.yandex.net-i buraxdılar, lakin köhnə versiya, mail.yandex.net qaldı. Bu mail.yandex.net artıq dəstəklənmir, inkişaf resursları ona ayrılmır, lakin verilənlər bazasını istehlak etməyə davam edir. Müvafiq olaraq, köhnə versiyanın köməyi ilə arxa planın resurslarından və layoutun arxasında olan hər şeydən səmərəli istifadə edə bilərsiniz. Əlbəttə ki, bu, həmişə baş vermir, lakin biz yenə də bununla tez-tez qarşılaşırıq.
Təbii ki, biz bütün sorğu parametrlərini, kuki strukturunu hazırlayırıq. Siz, deyək ki, kuki daxilində JSON massivinə müəyyən dəyər ata, böyük bir yuva yarada və resursun əsassız olaraq uzun müddət işləməsini təmin edə bilərsiniz.
Axtarış yükü
Saytı araşdırarkən ağla gələn ilk şey verilənlər bazasını yükləməkdir, çünki demək olar ki, hər kəs axtarış aparır və təəssüf ki, demək olar ki, hər kəs onu zəif qoruyur. Nədənsə tərtibatçılar axtarışa kifayət qədər diqqət yetirmirlər. Ancaq burada bir tövsiyə var - eyni tipli sorğular etməməlisiniz, çünki HTTP daşqında olduğu kimi keşləmə ilə qarşılaşa bilərsiniz.
Verilənlər bazasına təsadüfi sorğular etmək də həmişə səmərəli olmur. Axtarışa uyğun açar sözlər siyahısını yaratmaq daha yaxşıdır. Bir onlayn mağazanın nümunəsinə qayıdaqsa: deyək ki, sayt avtomobil şinləri satır və təkər radiusunu, avtomobilin növünü və digər parametrləri təyin etməyə imkan verir. Buna uyğun olaraq, müvafiq sözlərin birləşmələri verilənlər bazasını daha mürəkkəb şəraitdə işlədəcək.
Bundan əlavə, səhifələşdirmədən istifadə etməyə dəyər: axtarış üçün axtarış nəticələrinin sondan əvvəlki səhifəsini vermək birincidən daha çətindir. Yəni səhifələşdirmənin köməyi ilə yükü bir az şaxələndirə bilərsiniz.
Aşağıdakı nümunə axtarışda yükü göstərir. Görünür ki, testin ilk saniyəsindən saniyədə on sorğu sürəti ilə sayt uzandı və cavab vermədi.
Axtarış yoxdursa?
Axtarış yoxdursa, bu o demək deyil ki, saytda digər həssas giriş sahələri yoxdur. Avtorizasiya belə bir sahə ola bilər. İndi tərtibatçılar giriş verilənlər bazasını göy qurşağı cədvəli hücumundan qorumaq üçün mürəkkəb heşlər yaratmağı sevirlər. Bu yaxşıdır, lakin belə hashlər çoxlu CPU resursunu istehlak edir. Saxta icazələrin böyük axını prosessorun nasazlığına gətirib çıxarır və nəticədə sayt çıxışda fəaliyyətini dayandırır.
Saytda şərhlər və rəylər üçün hər cür formaların olması oraya çox böyük mətnlər göndərmək və ya sadəcə kütləvi daşqın yaratmaq üçün bir səbəbdir. Bəzən saytlar gzip formatında olanlar da daxil olmaqla qoşmaları qəbul edir. Bu halda biz 1TB faylı götürürük, gzipdən istifadə edərək onu bir neçə bayta və ya kilobayta sıxıb sayta göndəririk. Sonra zibil açılır və çox maraqlı effekt əldə edilir.
İstirahət API
Bu gün Rest API kimi məşhur xidmətlərə bir az diqqət yetirmək istərdim. Rest API-nin təhlükəsizliyini təmin etmək adi veb saytdan daha çətindir. Rest API üçün hətta parol kobud gücdən və digər qeyri-qanuni fəaliyyətdən qorunmanın banal üsulları işləmir.
Rest API-ni sındırmaq çox asandır, çünki o, birbaşa verilənlər bazası ilə danışır. Eyni zamanda, belə bir xidmətin geri çəkilməsi biznes üçün kifayət qədər ciddi nəticələrə səbəb olur. Fakt budur ki, Rest API adətən yalnız əsas saytla deyil, həm də mobil proqramla, bəzi daxili biznes resursları ilə əlaqələndirilir. Və hamısı aşağı düşərsə, təsir sadə bir saytın uğursuzluğundan daha güclüdür.
Ağır məzmun yükü
Əgər bizə hansısa adi tək səhifəlik tətbiqi, açılış səhifəsini, mürəkkəb funksionallığı olmayan vizit kartı saytını sınaqdan keçirmək təklif edilərsə, biz ağır məzmun axtarırıq. Məsələn, serverin verdiyi böyük şəkillər, ikili fayllar, pdf sənədləri - bütün bunları yükləməyə çalışırıq. Bu cür testlər fayl sistemini yaxşı yükləyir və kanalları bağlayır və buna görə də təsirli olur. Yəni, serveri yerə qoymasanız belə, böyük bir faylı aşağı sürətlə endirsəniz, sadəcə olaraq hədəf serverin kanalını bağlayacaqsınız və sonra xidmətdən imtina baş verəcəkdir.
Belə bir testin nümunəsində, 30 RPS sürətində saytın cavab verməyi dayandırdığını və ya 500 server səhvi verdiyini görmək olar.
Serverləri qurmağı unutmayın. Tez-tez bir insanın virtual maşın aldığını, orada Apache quraşdırdığını, hər şeyi standart olaraq konfiqurasiya etdiyini, php tətbiqi yerləşdirdiyini və aşağıda nəticəni görə bilərsiniz.
Burada yük kökə getdi və yalnız 10 RPS idi. 5 dəqiqə gözlədik və server çökdü. Sona qədər onun niyə yıxıldığı məlum deyil, lakin onun sadəcə çox yaddaş yediyi və buna görə də cavab verməyi dayandırdığı ehtimalı var.
dalğa əsaslıdır
Son bir və ya iki ildə dalğa hücumları kifayət qədər populyarlaşdı. Bu, bir çox təşkilatın DDoS-dan qorunmaq üçün müəyyən aparat hissələrinin alınması ilə əlaqədardır ki, bu da hücumu süzgəcdən keçirməyə başlamaq üçün statistik məlumatları toplamaq üçün müəyyən vaxt tələb edir. Yəni ilk 30-40 saniyədə hücumu süzgəcdən keçirmirlər, çünki məlumat toplayır və öyrənirlər. Müvafiq olaraq, bu 30-40 saniyə ərzində saytda o qədər çox şey işə salına bilər ki, resurs bütün istəklər nəzərə alınana qədər uzun müddət yatacaq.
Aşağıdakı hücum vəziyyətində, 10 dəqiqəlik bir fasilə var idi, bundan sonra hücumun yeni, dəyişdirilmiş hissəsi gəldi.
Yəni müdafiə öyrəndi, süzgəci işə saldı, lakin hücumun yeni, tamamilə fərqli bir hissəsi gəldi və müdafiə yenidən məşqə başladı. Əslində, filtrləmə işləməyi dayandırır, qorunma təsirsiz olur və sayt əlçatan deyil.
Dalğa hücumları zirvədə çox yüksək dəyərlərlə xarakterizə olunur, L7 vəziyyətində saniyədə yüz min və ya bir milyon sorğuya çata bilər. L3 və 4 haqqında danışırıqsa, onda yüzlərlə gigabit trafik ola bilər və ya paketlərdə hesablasanız, yüzlərlə mpps ola bilər.
Bu cür hücumlarla bağlı problem sinxronizasiyadır. Hücumlar botnetdən gəlir və çox böyük birdəfəlik sünbül yaratmaq üçün yüksək dərəcədə sinxronizasiya tələb olunur. Və bu koordinasiya həmişə işləmir: bəzən çıxış bir növ parabolik zirvədir, bu olduqca acınacaqlı görünür.
HTTP Single deyil
L7 səviyyəsində HTTP ilə yanaşı, biz digər protokollardan istifadə etməyi xoşlayırıq. Bir qayda olaraq, adi veb-saytda, xüsusən də adi hostinqdə poçt protokolları və MySQL-dən kənarda qalır. Poçt protokolları verilənlər bazası ilə müqayisədə daha az vurğulanır, lakin onlar da kifayət qədər səmərəli şəkildə yüklənə bilər və serverdə həddindən artıq yüklənmiş CPU ilə nəticələnə bilər.
2016-cı il SSH zəifliyi ilə real uğur qazandıq. İndi bu zəiflik demək olar ki, hamı üçün düzəldilib, lakin bu o demək deyil ki, siz SSH-ə yük göndərə bilməyəcəksiniz. Bacarmaq. Sadəcə olaraq, böyük bir icazə yükü verilir, SSH serverdəki demək olar ki, bütün CPU-nu yeyir və sonra veb sayt saniyədə bir və ya iki sorğudan inkişaf edir. Müvafiq olaraq, loglardan bu bir və ya iki sorğu qanuni yükdən fərqlənə bilməz.
Müvafiq və serverlərdə açdığımız bir çox əlaqəni qoruyun. Əvvəllər Apache bununla günah edirdi, indi nginx əslində bununla günah edir, çünki tez-tez standart olaraq konfiqurasiya edilir. Nginx-in açıq saxlaya biləcəyi bağlantıların sayı məhduddur, ona görə də bu sayda əlaqəni açırıq, nginx artıq yeni bağlantı qəbul etmir və sayt çıxışda işləmir.
Test klasterimizdə SSL əl sıxmasına hücum etmək üçün kifayət qədər CPU var. Prinsipcə, təcrübədən göründüyü kimi, botnetlər də bəzən bunu etməyi xoşlayırlar. Bir tərəfdən, SSL-nin əvəzolunmaz olduğu aydındır, çünki Google buraxılışı, sıralaması, təhlükəsizliyi. Digər tərəfdən, SSL-də təəssüf ki, CPU problemi var.
L3 və 4
L3 və 4 səviyyələrində bir hücum haqqında danışarkən, adətən kanal səviyyəsində bir hücumdan danışırıq. Belə bir yük, SYN-daşqın hücumu olmadığı təqdirdə, demək olar ki, həmişə qanuni olandan fərqlənir. Müdafiə üçün SYN daşqın hücumları ilə bağlı problem şəffaf həcmdir. L3&4-ün maksimum dəyəri 1,5-2 Tbps idi. Bu cür trafiki hətta Oracle və Google da daxil olmaqla böyük şirkətlər üçün emal etmək çox çətindir.
SYN və SYN-ACK əlaqə qurarkən istifadə olunan paketlərdir. Buna görə də, SYN-daşqını qanuni yükdən ayırmaq çətindir: bunun əlaqə yaratmaq üçün gələn SYN və ya daşqının bir hissəsi olduğu aydın deyil.
UDP seli
Adətən hücumçuların bizdə olan gücləri yoxdur, ona görə də hücumları təşkil etmək üçün gücləndirmə istifadə edilə bilər. Yəni, təcavüzkar İnterneti skan edir və ya həssas və ya səhv konfiqurasiya edilmiş serverləri tapır, məsələn, bir SYN paketinə cavab olaraq üç SYN-ACK ilə cavab verir. Hədəf serverin ünvanından mənbə ünvanını saxtalaşdırmaqla, bir paket gücü, məsələn, üç dəfə artıra və trafiki qurbana yönləndirə bilər.
Gücləndiricilərlə bağlı problem onların aşkarlanmasının çətin olmasıdır. Ən son nümunələrdən həssas memcached ilə sensasiyalı hadisəyə istinad etmək olar. Üstəlik, indi çoxlu IoT cihazları, IP kameralar var ki, onlar da əsasən defolt olaraq konfiqurasiya edilir və standart olaraq səhv konfiqurasiya edilir, buna görə də təcavüzkarlar hücum etmək üçün bu cür cihazlardan ən çox istifadə edirlər.
Çətin SYN-daşqın
SYN-flood, yəqin ki, bir tərtibatçının nöqteyi-nəzərindən ən maraqlı hücum növüdür. Problem ondadır ki, sistem administratorları çox vaxt qorunmaq üçün IP blokundan istifadə edirlər. Üstəlik, IP tərəfindən bloklanma təkcə skriptlərə uyğun hərəkət edən sistem administratorlarına deyil, təəssüf ki, çox pula satın alınan bəzi qorunma sistemlərinə də təsir göstərir.
Bu üsul fəlakətə çevrilə bilər, çünki təcavüzkarlar IP ünvanlarını dəyişdirsələr, o zaman şirkət öz alt şəbəkəsini bloklayacaq. Firewall öz klasterini bloklayanda, nəticədə xarici qarşılıqlı əlaqələr dağılacaq və resurs pozulacaq.
Üstəlik, öz şəbəkənizi bloklamaq asandır. Müştərinin ofisində WI-Fi şəbəkəsi varsa və ya resursların performansı müxtəlif monitorlar vasitəsilə ölçülürsə, o zaman biz bu monitorinq sisteminin və ya ofis Wi-Fi müştərisinin İP ünvanını götürüb mənbə kimi istifadə edirik. Çıxışda resurs əlçatan görünür, lakin hədəf IP ünvanları bloklanır. Beləliklə, şirkətin yeni məhsulunun təqdim olunduğu HighLoad konfransının Wi-Fi şəbəkəsi bloklana bilər - və bu, müəyyən biznes və iqtisadi xərclərə səbəb olur.
Sınaq zamanı biz bəzi xarici resurslar tərəfindən yaddaşda saxlanılan gücləndirmədən istifadə edə bilmirik, çünki trafiki yalnız icazə verilən IP ünvanlarına çatdırmaq üçün razılaşmalar var. Müvafiq olaraq, sistem iki və ya üç SYN-ACK ilə bir SYN göndərilməsinə cavab verdikdə və çıxışda hücum iki-üç dəfə çoxaldıqda, SYN və SYN-ACK vasitəsilə gücləndirmədən istifadə edirik.
Tools
L7 səviyyəsində yükləmək üçün istifadə etdiyimiz əsas vasitələrdən biri Yandex-tankdır. Xüsusilə, bir fantom silah kimi istifadə olunur, üstəlik patron yaratmaq və nəticələri təhlil etmək üçün bir neçə skript var.
Tcpdump şəbəkə trafikini təhlil etmək üçün, Nmap isə serveri təhlil etmək üçün istifadə olunur. L3 və 4 səviyyəsində bir yük yaratmaq üçün OpenSSL istifadə olunur və DPDK kitabxanası ilə bir az öz sehrimizdən istifadə olunur. DPDK, Linux yığınından yan keçərək şəbəkə interfeysi ilə işləməyə və bununla da səmərəliliyi artırmağa imkan verən Intel kitabxanasıdır. Təbii ki, biz DPDK-dan təkcə L3 və 4 səviyyəsində deyil, həm də L7 səviyyəsində istifadə edirik, çünki o, bir maşından saniyədə bir neçə milyon sorğu daxilində çox yüksək yük axını yaratmağa imkan verir.
Biz həmçinin xüsusi sınaqlar üçün yazdığımız müəyyən trafik generatorlarından və xüsusi vasitələrdən istifadə edirik. SSH altındakı zəifliyi xatırlasaq, yuxarıdakı dəstlə ondan istifadə edilə bilməz. Əgər poçt protokoluna hücum etsək, onda biz poçt yardım proqramlarını alırıq və ya sadəcə onlara skriptlər yazırıq.
Tapıntılar
Yekun olaraq demək istərdim:
- Klassik yük testi ilə yanaşı, stress testi də aparmaq lazımdır. Bizdə partnyorun subpodratçısının yalnız yük testi apardığı real həyat nümunəsi var. Resursun standart yükə tab gətirə biləcəyini göstərdi. Ancaq sonra anormal bir yük meydana çıxdı, sayt ziyarətçiləri resursdan bir az fərqli istifadə etməyə başladılar və sonda subpodratçı yerə uzandı. Beləliklə, DDoS hücumlarından artıq qorunmuş olsanız belə, zəiflikləri axtarmağa dəyər.
- Sistemin bəzi hissələrini digərlərindən təcrid etmək lazımdır. Əgər axtarışınız varsa, onu ayrı-ayrı maşınlara, yəni dockerə belə daşımamalısınız. Çünki axtarış və ya avtorizasiya uğursuz olarsa, o zaman heç olmasa bir şey işləməyə davam edəcək. Onlayn mağaza vəziyyətində, istifadəçilər kataloqda məhsulları tapmağa, aqreqatordan getməyə, artıq icazəsi varsa satın almağa və ya OAuth2 vasitəsilə daxil olmağa davam edəcəklər.
- Bütün növ bulud xidmətlərini laqeyd yanaşmayın.
- CDN-dən təkcə şəbəkə gecikməsini optimallaşdırmaq üçün deyil, həm də kanalın tükənməsi hücumlarından və sadəcə statik vəziyyətə düşməkdən qorunmaq vasitəsi kimi istifadə edin.
- Xüsusi mühafizə xidmətlərindən istifadə etmək lazımdır. Kanal səviyyəsində özünüzü L3 və 4 hücumlarından qoruya bilməzsiniz, çünki çox güman ki, kifayət qədər kanalınız yoxdur. L7 hücumları ilə də mübarizə apara bilməyəcəksiniz, çünki onlar çox böyük ola bilər. Üstəlik, kiçik hücumların axtarışı hələ də xüsusi xidmətlərin, xüsusi alqoritmlərin səlahiyyətindədir.
- Müntəzəm olaraq yeniləyin. Bu, təkcə kernelə deyil, həm də SSH demonuna aiddir, xüsusən də onları xaricə açdığınız halda. Prinsipcə, hər şey yenilənməlidir, çünki müəyyən zəiflikləri təkbaşına izləyə bilməyəcəksiniz.
Mənbə: www.habr.com