Variti botlardan va DDoS hujumlaridan himoyani ishlab chiqadi, shuningdek, stress va yuk testlarini o'tkazadi. HighLoad++ 2018 konferensiyasida biz resurslarni har xil turdagi hujumlardan qanday himoya qilish haqida gaplashdik. Muxtasar qilib aytganda: tizim qismlarini ajratib oling, bulutli xizmatlar va CDN-lardan foydalaning va muntazam ravishda yangilang. Ammo siz hali ham ixtisoslashgan kompaniyalarsiz himoya bilan shug'ullana olmaysiz :)
Matnni o'qishdan oldin siz qisqacha tezislarni o'qishingiz mumkin .
Va agar siz o'qishni yoqtirmasangiz yoki shunchaki videoni ko'rishni istasangiz, bizning hisobotimiz yozuvi quyida spoyler ostida.
Hisobotni videoga olish
Ko'pgina kompaniyalar allaqachon yuk testini qanday qilishni bilishadi, lekin hamma ham stress testini o'tkazmaydi. Ba'zi mijozlarimiz o'zlarining saytlarini daxlsiz deb hisoblashadi, chunki ular yuqori yuklash tizimiga ega va u hujumlardan yaxshi himoya qiladi. Bu mutlaqo to'g'ri emasligini ko'rsatamiz.
Albatta, testlarni o'tkazishdan oldin biz mijozdan ruxsat olamiz, imzo va muhr qo'yamiz va bizning yordamimiz bilan hech kimga DDoS hujumini amalga oshirib bo'lmaydi. Sinov mijoz tanlagan vaqtda, uning resursiga trafik minimal bo'lgan va kirish muammolari mijozlarga ta'sir qilmaydigan vaqtda amalga oshiriladi. Bundan tashqari, sinov jarayonida har doim biror narsa noto'g'ri ketishi mumkinligi sababli, biz mijoz bilan doimiy aloqadamiz. Bu nafaqat erishilgan natijalar haqida xabar berish, balki sinov paytida biror narsani o'zgartirish imkonini beradi. Sinov tugagandan so'ng, biz har doim hisobot tuzamiz, unda aniqlangan kamchiliklarni ko'rsatamiz va saytning zaif tomonlarini bartaraf etish bo'yicha tavsiyalar beramiz.
Biz qanday ishlaymiz
Sinov paytida biz botnetga taqlid qilamiz. Biz tarmoqlarimizda bo'lmagan mijozlar bilan ishlayotganimiz sababli, cheklovlar yoki himoya ishga tushirilganligi sababli sinov birinchi daqiqada tugamasligini ta'minlash uchun biz yukni bitta IPdan emas, balki o'z ichki tarmoqimizdan ta'minlaymiz. Bundan tashqari, sezilarli yuk yaratish uchun bizda o'zimizning juda kuchli test serverimiz bor.
Postulatlar
Ko'p narsa yaxshi degani emas
Resursni muvaffaqiyatsizlikka qanchalik kam yuklasak, shuncha yaxshi bo'ladi. Agar siz sekundiga bitta so'rov yoki hatto bir daqiqada bitta so'rov bo'yicha sayt faoliyatini to'xtata olsangiz, bu juda yaxshi. Chunki shafqatsizlik qonuniga ko'ra, foydalanuvchilar yoki tajovuzkorlar tasodifan ushbu zaiflikka tushib qolishadi.
Qisman muvaffaqiyatsizlik to'liq muvaffaqiyatsizlikdan yaxshiroqdir
Biz har doim tizimlarni heterojen qilishni maslahat beramiz. Bundan tashqari, ularni konteynerlash orqali emas, balki jismoniy darajada ajratishga arziydi. Jismoniy ajralish holatida, saytda biror narsa muvaffaqiyatsizlikka uchragan taqdirda ham, u to'liq ishlashni to'xtatmaslik ehtimoli yuqori va foydalanuvchilar hech bo'lmaganda funksionallikning bir qismiga kirishda davom etadilar.
Yaxshi arxitektura barqarorlik uchun asosdir
Resursning nosozliklarga chidamliligi va uning hujumlar va yuklarga bardosh berish qobiliyati dizayn bosqichida, aslida daftarda birinchi oqim sxemalarini chizish bosqichida belgilanishi kerak. Chunki agar halokatli xatolar yuzaga kelsa, kelajakda ularni tuzatish mumkin, ammo bu juda qiyin.
Faqat kod emas, balki konfiguratsiya ham yaxshi bo'lishi kerak
Ko'pchilik, yaxshi rivojlanish jamoasi xatoga chidamli xizmatning kafolati deb o'ylaydi. Yaxshi ishlab chiqish guruhi haqiqatan ham zarur, lekin yaxshi operatsiyalar, yaxshi DevOps ham bo'lishi kerak. Ya'ni, bizga Linux va tarmoqni to'g'ri sozlaydigan, nginx-da konfiguratsiyalarni to'g'ri yozadigan, chegaralarni o'rnatadigan va hokazo mutaxassislar kerak. Aks holda, resurs faqat sinovda yaxshi ishlaydi va bir nuqtada ishlab chiqarishda hamma narsa buziladi.
Yuk va stress testlari o'rtasidagi farqlar
Yuk testi tizimning ishlash chegaralarini aniqlash imkonini beradi. Stress testi tizimdagi zaif tomonlarni topishga qaratilgan bo'lib, ushbu tizimni buzish va uning muayyan qismlarning ishdan chiqishi jarayonida o'zini qanday tutishini ko'rish uchun ishlatiladi. Bunday holda, yukning tabiati odatda stress testi boshlanishidan oldin mijozga noma'lum bo'lib qoladi.
L7 hujumlarining o'ziga xos xususiyatlari
Biz odatda yuk turlarini L7 va L3 va 4 darajalarida yuklarga ajratamiz. L7 - bu dastur darajasidagi yuk, ko'pincha bu faqat HTTP degan ma'noni anglatadi, lekin biz TCP protokoli darajasidagi har qanday yukni nazarda tutamiz.
L7 hujumlari ma'lum o'ziga xos xususiyatlarga ega. Birinchidan, ular to'g'ridan-to'g'ri dasturga keladi, ya'ni ular tarmoq vositalari orqali aks etishi dargumon. Bunday hujumlar mantiqdan foydalanadi va shu sababli ular CPU, xotira, disk, ma'lumotlar bazasi va boshqa resurslarni juda samarali va kam trafik bilan iste'mol qiladilar.
HTTP toshqin
Har qanday hujum holatida yukni yaratishdan ko'ra uni yaratish osonroq va L7 holatida bu ham to'g'ri. Hujum trafigini qonuniy trafikdan ajratish har doim ham oson emas va ko'pincha buni chastota bo'yicha amalga oshirish mumkin, lekin agar hamma narsa to'g'ri rejalashtirilgan bo'lsa, jurnallardan hujum qaerda va qonuniy so'rovlar qaerda ekanligini tushunish mumkin emas.
Birinchi misol sifatida, HTTP Flood hujumini ko'rib chiqing. Grafik shuni ko'rsatadiki, bunday hujumlar odatda juda kuchli; quyidagi misolda so'rovlarning eng yuqori soni daqiqada 600 mingdan oshdi.
HTTP Flood - yuk yaratishning eng oson usuli. Odatda, u ApacheBench kabi yukni tekshirish vositasini oladi va so'rov va maqsadni belgilaydi. Bunday oddiy yondashuv bilan server keshiga kirish ehtimoli yuqori, ammo uni chetlab o'tish oson. Masalan, so'rovga tasodifiy satrlarni qo'shish, bu serverni doimiy ravishda yangi sahifaga xizmat ko'rsatishga majbur qiladi.
Bundan tashqari, yuk yaratish jarayonida foydalanuvchi-agent haqida unutmang. Mashhur test vositalarining ko'plab foydalanuvchi-agentlari tizim ma'murlari tomonidan filtrlanadi va bu holda yuk oddiygina orqa qismga etib bormasligi mumkin. Brauzerdan so'rovga ko'proq yoki kamroq joriy sarlavha qo'shish orqali natijani sezilarli darajada yaxshilashingiz mumkin.
HTTP Flood hujumlari qanchalik sodda bo'lsa, ularning kamchiliklari ham bor. Birinchidan, yukni yaratish uchun katta miqdorda quvvat talab qilinadi. Ikkinchidan, bunday hujumlarni aniqlash juda oson, ayniqsa ular bitta manzildan kelgan bo'lsa. Natijada, so'rovlar darhol tizim ma'murlari yoki hatto provayder darajasida filtrlashni boshlaydi.
Nima qilish kerak
Samaradorlikni yo'qotmasdan soniyada so'rovlar sonini kamaytirish uchun siz ozgina tasavvurni ko'rsatishingiz va saytni o'rganishingiz kerak. Shunday qilib, siz nafaqat kanal yoki serverni, balki dasturning alohida qismlarini, masalan, ma'lumotlar bazalari yoki fayl tizimlarini ham yuklashingiz mumkin. Bundan tashqari, saytdagi katta hisob-kitoblarni amalga oshiradigan joylarni qidirishingiz mumkin: kalkulyatorlar, mahsulotni tanlash sahifalari va boshqalar. Nihoyat, ko'pincha sayt bir necha yuz ming qatorli sahifani yaratadigan PHP skriptiga ega bo'ladi. Bunday skript ham serverni sezilarli darajada yuklaydi va hujum nishoniga aylanishi mumkin.
Qaerga qarash kerak
Sinovdan oldin resursni skanerlaganimizda, avvalo, albatta, saytning o'ziga qaraymiz. Biz har qanday kirish maydonlarini, og'ir fayllarni - umuman olganda, resurs uchun muammolarni keltirib chiqaradigan va uning ishlashini sekinlashtiradigan barcha narsalarni qidiramiz. Bu yerda Google Chrome va Firefox-dagi banal ishlab chiqish vositalari yordam beradi, ular sahifaning javob vaqtini ko'rsatadi.
Shuningdek, biz subdomenlarni skanerlaymiz. Misol uchun, ma'lum bir onlayn-do'kon bor, abc.com va unda admin.abc.com subdomeni mavjud. Ehtimol, bu avtorizatsiyaga ega boshqaruv paneli, ammo agar siz unga yuk qo'ysangiz, u asosiy manba uchun muammolarni keltirib chiqarishi mumkin.
Saytda api.abc.com subdomeni bo'lishi mumkin. Ehtimol, bu mobil ilovalar uchun resurs. Ilovani App Store yoki Google Play-da topish, maxsus kirish nuqtasini o'rnatish, API-ni ajratish va sinov hisoblarini ro'yxatdan o'tkazish mumkin. Muammo shundaki, odamlar ko'pincha avtorizatsiya bilan himoyalangan har qanday narsa xizmat hujumlarini rad etishdan himoyalangan deb o'ylashadi. Taxminlarga ko'ra, avtorizatsiya eng yaxshi CAPTCHA, lekin unday emas. 10-20 ta test hisobini yaratish oson, ammo ularni yaratish orqali biz murakkab va yashirin funksiyalarga kirish imkoniyatiga ega bo'lamiz.
Tabiiyki, biz tarixga qaraymiz, robots.txt va WebArchive, ViewDNS va resursning eski versiyalarini qidiramiz. Ba'zan shunday bo'ladiki, ishlab chiquvchilar, masalan, mail2.yandex.net ni chiqardilar, ammo eski versiya, mail.yandex.net qoladi. Ushbu mail.yandex.net endi qo'llab-quvvatlanmaydi, rivojlanish resurslari unga ajratilmaydi, lekin u ma'lumotlar bazasini iste'mol qilishda davom etmoqda. Shunga ko'ra, eski versiyadan foydalanib, siz backend resurslaridan va tartibning orqasida turgan barcha narsalardan samarali foydalanishingiz mumkin. Albatta, bu har doim ham sodir bo'lmaydi, lekin biz hali ham tez-tez duch kelamiz.
Tabiiyki, biz barcha so'rov parametrlari va cookie tuzilishini tahlil qilamiz. Aytaylik, kuki ichidagi JSON massiviga ba'zi qiymatlarni tushirishingiz, ko'p joylashtirishlarni yaratishingiz va resursni asossiz uzoq vaqt ishlashiga imkon berishingiz mumkin.
Qidiruv yuki
Saytni tadqiq qilishda aqlga keladigan birinchi narsa ma'lumotlar bazasini yuklashdir, chunki deyarli hamma qidiruvga ega va deyarli hamma uchun, afsuski, u yomon himoyalangan. Ba'zi sabablarga ko'ra, ishlab chiquvchilar qidiruvga etarlicha e'tibor bermaydilar. Ammo bu erda bitta tavsiya bor - siz bir xil turdagi so'rovlarni qilmasligingiz kerak, chunki siz HTTP toshqinida bo'lgani kabi keshlash bilan duch kelishingiz mumkin.
Ma'lumotlar bazasiga tasodifiy so'rovlar qilish ham har doim ham samarali emas. Qidiruvga mos keladigan kalit so'zlar ro'yxatini tuzish yaxshiroqdir. Agar onlayn-do'kon misoliga qaytadigan bo'lsak: aytaylik, sayt avtomobil shinalarini sotadi va shinalar radiusini, avtomobil turini va boshqa parametrlarni belgilash imkonini beradi. Shunga ko'ra, tegishli so'zlarning kombinatsiyasi ma'lumotlar bazasini ancha murakkab sharoitlarda ishlashga majbur qiladi.
Bundan tashqari, sahifalashdan foydalanishga arziydi: qidiruv uchun qidiruv natijalarining oxirgi sahifasini qaytarish birinchisiga qaraganda ancha qiyin. Ya'ni, sahifalash yordamida siz yukni biroz diversifikatsiya qilishingiz mumkin.
Quyidagi misol qidiruv yukini ko'rsatadi. Ko'rinib turibdiki, testning birinchi soniyasidan sekundiga o'n so'rov tezligida sayt ishlamay qolgan va javob bermagan.
Agar qidiruv bo'lmasa?
Agar qidiruv bo'lmasa, bu sayt boshqa zaif kirish maydonlarini o'z ichiga olmaydi degani emas. Bu maydon avtorizatsiya bo'lishi mumkin. Hozirgi vaqtda ishlab chiquvchilar login ma'lumotlar bazasini kamalak jadvali hujumidan himoya qilish uchun murakkab xeshlarni yaratishni yaxshi ko'radilar. Bu yaxshi, lekin bunday xeshlar juda ko'p CPU resurslarini iste'mol qiladi. Noto'g'ri avtorizatsiyalarning katta oqimi protsessorning ishlamay qolishiga olib keladi va natijada sayt ishlashni to'xtatadi.
Saytda sharhlar va fikr-mulohazalar uchun barcha turdagi shakllarning mavjudligi u erga juda katta matnlarni yuborish yoki shunchaki katta toshqinni yaratish uchun sababdir. Ba'zan saytlar biriktirilgan fayllarni, shu jumladan gzip formatida ham qabul qiladi. Bunday holda, biz 1TB faylni olamiz, uni gzip yordamida bir necha bayt yoki kilobaytga siqib, saytga yuboramiz. Keyin u ochiladi va juda qiziqarli effekt olinadi.
Rest API
Men Rest API kabi mashhur xizmatlarga bir oz e'tibor qaratmoqchiman. Rest API xavfsizligini ta'minlash oddiy veb-saytga qaraganda ancha qiyin. Parolni qo'pol kuchdan va boshqa noqonuniy harakatlardan himoya qilishning ahamiyatsiz usullari ham Rest API uchun ishlamaydi.
Rest API-ni buzish juda oson, chunki u to'g'ridan-to'g'ri ma'lumotlar bazasiga kiradi. Shu bilan birga, bunday xizmatning muvaffaqiyatsizligi biznes uchun juda jiddiy oqibatlarga olib keladi. Gap shundaki, Rest API odatda nafaqat asosiy veb-sayt uchun, balki mobil ilova va ba'zi ichki biznes resurslari uchun ham qo'llaniladi. Va agar bularning barchasi tushib qolsa, bu ta'sir oddiy veb-sayt ishlamay qolganidan ko'ra kuchliroq bo'ladi.
Og'ir kontent yuklanmoqda
Agar bizga murakkab funksiyalarga ega boʻlmagan oddiy bir sahifali ilova, ochilish sahifasi yoki tashrif qogʻozi veb-saytini sinab koʻrish taklif qilinsa, biz ogʻir kontentni qidiramiz. Masalan, server yuboradigan katta rasmlar, ikkilik fayllar, pdf hujjatlari - bularning barchasini yuklab olishga harakat qilamiz. Bunday testlar fayl tizimini yaxshi yuklaydi va kanallarni yopishadi va shuning uchun samarali bo'ladi. Ya'ni, agar siz serverni qo'ymasangiz ham, past tezlikda katta faylni yuklab olsangiz, siz shunchaki maqsadli serverning kanalini yopib qo'yasiz va keyin xizmat ko'rsatishni rad etish sodir bo'ladi.
Bunday testning misoli shuni ko'rsatadiki, 30 RPS tezligida sayt javob berishni to'xtatdi yoki 500-server xatosini keltirib chiqardi.
Serverlarni sozlash haqida unutmang. Siz tez-tez odam virtual mashina sotib olganini, u erda Apache-ni o'rnatganini, sukut bo'yicha hamma narsani sozlaganini, PHP dasturini o'rnatganini va quyida natijani ko'rishingiz mumkin.
Bu erda yuk ildizga o'tdi va atigi 10 RPSni tashkil etdi. Biz 5 daqiqa kutdik va server ishdan chiqdi. To'g'ri, uning nima uchun yiqilganligi to'liq noma'lum, ammo u shunchaki xotirasi juda ko'p bo'lgan va shuning uchun javob berishni to'xtatgan degan taxmin bor.
To'lqinga asoslangan
So'nggi bir yoki ikki yil ichida to'lqinli hujumlar juda mashhur bo'ldi. Buning sababi shundaki, ko'plab tashkilotlar DDoS himoyasi uchun ma'lum apparat qismlarini sotib oladi, bu esa hujumni filtrlashni boshlash uchun statistik ma'lumotlarni to'plash uchun ma'lum vaqtni talab qiladi. Ya'ni, ular birinchi 30-40 soniyada hujumni filtrlamaydilar, chunki ular ma'lumotlarni to'playdi va o'rganadi. Shunga ko'ra, ushbu 30-40 soniya ichida siz saytda shunchalik ko'p narsalarni ishga tushirishingiz mumkinki, barcha so'rovlar tozalanmaguncha resurs uzoq vaqt yotadi.
Quyidagi hujum holatida 10 daqiqalik oraliq bor edi, shundan so'ng hujumning yangi, o'zgartirilgan qismi keldi.
Ya'ni, himoya o'rgandi, filtrlashni boshladi, lekin hujumning yangi, butunlay boshqa qismi keldi va himoya yana o'rganishni boshladi. Aslida, filtrlash ishlashni to'xtatadi, himoya samarasiz bo'ladi va sayt mavjud emas.
To'lqinli hujumlar cho'qqisida juda yuqori qiymatlar bilan tavsiflanadi, L7 holatida u soniyada yuz ming yoki million so'rovga yetishi mumkin. Agar biz L3 va 4 haqida gapiradigan bo'lsak, agar siz paketlarda hisoblasangiz, u holda yuzlab gigabit trafik yoki shunga mos ravishda yuzlab mpps bo'lishi mumkin.
Bunday hujumlar bilan bog'liq muammo sinxronizatsiyadir. Hujumlar botnetdan keladi va juda katta bir martalik spike yaratish uchun yuqori darajadagi sinxronizatsiyani talab qiladi. Va bu muvofiqlashtirish har doim ham ishlamaydi: ba'zida chiqish juda achinarli ko'rinadigan parabolik cho'qqiga aylanadi.
Faqat HTTP emas
L7 da HTTP-dan tashqari, biz boshqa protokollardan foydalanishni yaxshi ko'ramiz. Qoidaga ko'ra, oddiy veb-sayt, ayniqsa oddiy xosting, pochta protokollari va MySQL-ga ega. Pochta protokollari ma'lumotlar bazalariga qaraganda kamroq yuklanadi, lekin ular ham juda samarali yuklanishi mumkin va serverda ortiqcha yuklangan CPU bilan yakunlanadi.
Biz 2016 yilgi SSH zaifligidan juda muvaffaqiyatli foydalandik. Endi bu zaiflik deyarli hamma uchun tuzatildi, ammo bu yukni SSHga yuborish mumkin emas degani emas. mumkin. Shunchaki katta miqdordagi avtorizatsiyalar mavjud, SSH serverdagi deyarli butun protsessorni iste'mol qiladi va keyin veb-sayt soniyasiga bir yoki ikkita so'rovdan yiqilib tushadi. Shunga ko'ra, jurnallarga asoslangan bu bir yoki ikkita so'rovni qonuniy yukdan ajratib bo'lmaydi.
Biz serverlarda ochadigan ko'plab ulanishlar ham dolzarb bo'lib qolmoqda. Ilgari, Apache buning uchun aybdor edi, endi nginx aslida bundan aziyat chekmoqda, chunki u ko'pincha sukut bo'yicha sozlangan. Nginx ochiq tuta oladigan ulanishlar soni cheklangan, shuning uchun biz bu sonli ulanishlarni ochamiz, nginx endi yangi ulanishni qabul qilmaydi va natijada sayt ishlamaydi.
Sinov klasterimiz SSL qo‘l siqishiga hujum qilish uchun yetarli protsessorga ega. Aslida, amaliyot shuni ko'rsatadiki, botnetlar ba'zan buni qilishni yaxshi ko'radilar. Bir tomondan, siz SSLsiz qilolmaysiz, chunki Google natijalari, reyting, xavfsizlik. Boshqa tomondan, SSL, afsuski, CPU muammosiga ega.
L3 va 4
L3 va 4 darajalarida hujum haqida gapirganda, biz odatda havola darajasidagi hujum haqida gapiramiz. Bunday yuk deyarli har doim qonuniy bo'lganidan ajralib turadi, agar u SYN-toshqin hujumi bo'lmasa. Xavfsizlik vositalari uchun SYN-to'fon hujumlari bilan bog'liq muammo ularning katta hajmidir. Maksimal L3&4 qiymati 1,5-2 Tbit/s edi. Bunday trafikni hatto yirik kompaniyalar, jumladan Oracle va Google uchun ham qayta ishlash juda qiyin.
SYN va SYN-ACK - bu ulanishni o'rnatishda ishlatiladigan paketlar. Shu sababli, SYN-to'fonni qonuniy yukdan ajratish qiyin: bu aloqa o'rnatish uchun kelgan SYNmi yoki toshqinning bir qismimi, aniq emas.
UDP - toshqin
Odatda, tajovuzkorlar bizda mavjud bo'lgan imkoniyatlarga ega emas, shuning uchun hujumlarni tashkil qilish uchun kuchaytirishdan foydalanish mumkin. Ya'ni, tajovuzkor Internetni skanerlaydi va zaif yoki noto'g'ri tuzilgan serverlarni topadi, masalan, bitta SYN paketiga javoban uchta SYN-ACK bilan javob beradi. Maqsadli server manzilidan manba manzilini aldash orqali, masalan, bitta paket bilan quvvatni uch barobar oshirish va trafikni jabrlanuvchiga yo'naltirish mumkin.
Kuchaytirish bilan bog'liq muammo shundaki, ularni aniqlash qiyin. So'nggi misollarga zaif memcachedning shov-shuvli ishi kiradi. Bundan tashqari, hozirda juda ko'p IoT qurilmalari, IP kameralar mavjud, ular ham asosan sukut bo'yicha sozlangan va sukut bo'yicha ular noto'g'ri sozlangan, shuning uchun tajovuzkorlar ko'pincha bunday qurilmalar orqali hujum qilishadi.
Qiyin SYN-toshqin
SYN-flood, ehtimol, ishlab chiquvchi nuqtai nazaridan hujumning eng qiziqarli turi. Muammo shundaki, tizim ma'murlari ko'pincha himoya qilish uchun IP blokirovkasidan foydalanadilar. Bundan tashqari, IP blokirovkasi nafaqat skriptlardan foydalangan holda ishlaydigan tizim ma'murlariga, balki, afsuski, ko'p pul evaziga sotib olingan ba'zi xavfsizlik tizimlariga ham ta'sir qiladi.
Ushbu usul falokatga aylanishi mumkin, chunki agar tajovuzkorlar IP manzillarini almashtirsa, kompaniya o'zining pastki tarmog'ini bloklaydi. Xavfsizlik devori o'z klasterini bloklaganda, chiqish tashqi o'zaro ta'sirlarda muvaffaqiyatsizlikka uchraydi va resurs muvaffaqiyatsiz bo'ladi.
Bundan tashqari, o'z tarmog'ingizni blokirovka qilish qiyin emas. Agar mijozning ofisida Wi-Fi tarmog'i mavjud bo'lsa yoki resurslarning ishlashi turli monitoring tizimlari yordamida o'lchanadigan bo'lsa, biz ushbu monitoring tizimining IP-manzilini yoki mijoz ofisining Wi-Fi manzilini olamiz va undan manba sifatida foydalanamiz. Oxir-oqibat, resurs mavjud bo'lib tuyuladi, ammo maqsadli IP-manzillar bloklanadi. Shunday qilib, kompaniyaning yangi mahsuloti taqdim etilayotgan HighLoad konferentsiyasining Wi-Fi tarmog'i bloklanishi mumkin va bu ma'lum biznes va iqtisodiy xarajatlarni talab qiladi.
Sinov paytida biz har qanday tashqi manbalar bilan memcached orqali kuchaytirishdan foydalana olmaymiz, chunki trafikni faqat ruxsat etilgan IP manzillarga jo'natish bo'yicha kelishuvlar mavjud. Shunga ko'ra, biz SYN va SYN-ACK orqali kuchaytirishdan foydalanamiz, tizim ikkita yoki uchta SYN-ACK bilan bitta SYN yuborishga javob berganda va chiqishda hujum ikki yoki uch marta ko'paytiriladi.
asboblar
L7 ish yuki uchun biz foydalanadigan asosiy vositalardan biri Yandex-tank. Xususan, fantom qurol sifatida ishlatiladi, shuningdek, patronlarni yaratish va natijalarni tahlil qilish uchun bir nechta skriptlar mavjud.
Tcpdump tarmoq trafigini tahlil qilish uchun, Nmap esa serverni tahlil qilish uchun ishlatiladi. L3 va 4 darajasida yuk yaratish uchun OpenSSL va DPDK kutubxonasi bilan o'z sehrimizdan foydalaniladi. DPDK - bu Intel kutubxonasi bo'lib, u Linux stekini chetlab o'tib, tarmoq interfeysi bilan ishlashga imkon beradi va shu bilan samaradorlikni oshiradi. Tabiiyki, biz DPDK dan nafaqat L3&4, balki L7 darajasida ham foydalanamiz, chunki u bir mashinadan soniyasiga bir necha million so‘rovlar oralig‘ida juda yuqori yuk oqimini yaratishga imkon beradi.
Biz, shuningdek, muayyan sinovlar uchun yozadigan ma'lum trafik generatorlari va maxsus vositalardan foydalanamiz. Agar biz SSH ostidagi zaiflikni eslasak, yuqoridagi to'plamdan foydalanib bo'lmaydi. Agar biz pochta protokoliga hujum qilsak, biz pochta yordam dasturlarini olamiz yoki ularga oddiygina skriptlarni yozamiz.
topilmalar
Xulosa sifatida aytmoqchiman:
- Klassik yuk testidan tashqari, stress testini o'tkazish kerak. Bizda sherikning subpudratchisi faqat yuk sinovini o'tkazgan haqiqiy misolimiz bor. Bu resurs normal yukga bardosh bera olishini ko'rsatdi. Ammo keyin g'ayritabiiy yuk paydo bo'ldi, saytga tashrif buyuruvchilar resursdan biroz boshqacha foydalanishni boshladilar va natijada subpudratchi yotdi. Shunday qilib, siz allaqachon DDoS hujumlaridan himoyalangan bo'lsangiz ham, zaifliklarni izlashga arziydi.
- Tizimning ba'zi qismlarini boshqalardan ajratish kerak. Agar sizda qidiruv bo'lsa, uni alohida mashinalarga ko'chirishingiz kerak, ya'ni hatto Docker-ga ham emas. Chunki qidiruv yoki avtorizatsiya muvaffaqiyatsiz tugasa, hech bo'lmaganda biror narsa ishlashda davom etadi. Onlayn do'kon bo'lsa, foydalanuvchilar katalogdagi mahsulotlarni topishda davom etadilar, agregatordan o'tadilar, agar ular allaqachon avtorizatsiya qilingan bo'lsa sotib oladilar yoki OAuth2 orqali avtorizatsiya qilishadi.
- Barcha turdagi bulut xizmatlarini e'tiborsiz qoldirmang.
- CDN-dan nafaqat tarmoq kechikishlarini optimallashtirish uchun, balki kanalning tugashi va shunchaki statik trafikga to'lib ketishiga qarshi hujumlardan himoya vositasi sifatida foydalaning.
- Maxsus himoya xizmatlaridan foydalanish kerak. Siz o'zingizni kanal darajasida L3 va 4 hujumlaridan himoya qila olmaysiz, chunki sizda yetarlicha kanal yo'q. Siz L7 hujumlariga qarshi tura olmaysiz, chunki ular juda katta bo'lishi mumkin. Bundan tashqari, kichik hujumlarni qidirish hali ham maxsus xizmatlarning, maxsus algoritmlarning vakolati hisoblanadi.
- Muntazam ravishda yangilang. Bu nafaqat yadroga, balki SSH demoniga ham taalluqlidir, ayniqsa siz ularni tashqi tomondan ochiq qilsangiz. Aslida, hamma narsani yangilash kerak, chunki siz o'zingiz ba'zi zaifliklarni kuzata olmaysiz.
Manba: www.habr.com