Variti боттардан және DDoS шабуылдарынан қорғауды дамытады, сонымен қатар стресс пен жүктеме тестін жүргізеді. HighLoad++ 2018 конференциясында біз әртүрлі шабуыл түрлерінен ресурстарды қалай қорғауға болатынын айттық. Қысқасы: жүйенің бөліктерін оқшаулаңыз, бұлттық қызметтерді және CDN желілерін пайдаланыңыз және үнемі жаңартып отырыңыз. Бірақ сіз әлі де мамандандырылған компанияларсыз қорғаныспен айналыса алмайсыз :)
Мәтінді оқымас бұрын қысқаша рефераттарды оқуға болады .
Ал егер сіз оқығыңыз келмесе немесе жай ғана бейнені көргіңіз келсе, біздің репортаждың жазбасы төменде спойлердің астында.
Есептің бейнежазбасы
Көптеген компаниялар жүкті тестілеуді қалай жасау керектігін біледі, бірақ бәрі де стресс-тестілеуді жасамайды. Біздің кейбір тұтынушыларымыз олардың сайтын зиянсыз деп санайды, өйткені оларда жоғары жүктеме жүйесі бар және ол шабуылдардан жақсы қорғайды. Біз мұның мүлдем дұрыс емес екенін көрсетеміз.
Әрине, сынақтарды өткізбес бұрын біз тұтынушыдан рұқсат аламыз, қол қойып, мөр басамыз және біздің көмегімізбен DDoS шабуылын ешкімге жасай алмаймыз. Тестілеу тұтынушы таңдаған уақытта, оның ресурсына трафик аз болған кезде жүргізіледі және қол жеткізу мәселелері клиенттерге әсер етпейді. Сонымен қатар, тестілеу барысында бірдеңе дұрыс болмауы мүмкін болғандықтан, біз тұтынушымен үнемі байланыстамыз. Бұл қол жеткізілген нәтижелер туралы хабарлауға ғана емес, тестілеу кезінде бір нәрсені өзгертуге мүмкіндік береді. Тестілеу аяқталғаннан кейін біз әрқашан есеп жасаймыз, онда анықталған кемшіліктерді көрсетіп, сайттың әлсіз жақтарын жою бойынша ұсыныстар береміз.
Біз қалай жұмыс жасаймыз
Тестілеу кезінде біз ботнетке эмуляция жасаймыз. Біз желілерде орналаспаған клиенттермен жұмыс істейтіндіктен, шектеулер немесе қорғаныс іске қосылуына байланысты сынақ бірінші минутта аяқталмауы үшін біз жүктемені бір IP-ден емес, өз ішкі желіден жеткіземіз. Сонымен қатар, айтарлықтай жүктемені жасау үшін бізде өте қуатты сынақ сервері бар.
Постулаттар
Тым көп жақсы дегенді білдірмейді
Неғұрлым аз жүктеме ресурсты сәтсіздікке әкелетін болса, соғұрлым жақсы. Егер сіз сайтты секундына бір сұрау, тіпті минутына бір сұрау бойынша жұмысын тоқтата алсаңыз, бұл тамаша. Өйткені ақымақтық заңына сәйкес пайдаланушылар немесе шабуылдаушылар кездейсоқ осы осалдыққа түседі.
Толық сәтсіздікке қарағанда жартылай сәтсіздік жақсы
Біз әрқашан жүйелерді гетерогенді етуге кеңес береміз. Сонымен қатар, оларды контейнерлеу арқылы емес, физикалық деңгейде бөлу керек. Физикалық бөліну жағдайында, сайтта бірдеңе сәтсіз болса да, оның жұмысын толығымен тоқтатпау ықтималдығы жоғары және пайдаланушылар функционалдылықтың кем дегенде бір бөлігіне қол жеткізуді жалғастырады.
Жақсы сәулет - тұрақтылықтың негізі
Ресурстың ақауларға төзімділігі және оның шабуылдар мен жүктемелерге төтеп беру қабілеті жобалау кезеңінде, шын мәнінде блокноттағы алғашқы блок-схемаларды салу кезеңінде көрсетілуі керек. Өйткені, егер өлімге әкелетін қателер болса, болашақта оларды түзетуге болады, бірақ бұл өте қиын.
Тек код емес, конфигурация да жақсы болуы керек
Көптеген адамдар жақсы әзірлеу тобы ақауларға төзімді қызметтің кепілі деп ойлайды. Жақсы әзірлеу тобы шынымен қажет, бірақ жақсы операциялар, жақсы DevOps болуы керек. Яғни, бізге Linux және желіні дұрыс конфигурациялайтын, nginx-те конфигурацияларды дұрыс жазатын, шектеулер қоятын және т.б. мамандар қажет. Әйтпесе, ресурс тек тестілеуде жақсы жұмыс істейді және бір сәтте бәрі өндірісте бұзылады.
Жүктеме мен стресс-тестілеу арасындағы айырмашылықтар
Жүктеме сынағы жүйенің жұмыс істеу шегін анықтауға мүмкіндік береді. Стресс-тестілеу жүйенің әлсіз жақтарын табуға бағытталған және бұл жүйені бұзу және белгілі бір бөліктердің істен шығуы процесінде оның қалай әрекет ететінін көру үшін қолданылады. Бұл жағдайда жүктеменің сипаты әдетте стресс-тестілеу басталғанға дейін тұтынушыға белгісіз болып қалады.
L7 шабуылдарының ерекше белгілері
Біз әдетте жүк түрлерін L7 және L3&4 деңгейлеріндегі жүктемелерге бөлеміз. L7 қолданба деңгейіндегі жүктеме, көбінесе ол тек HTTP дегенді білдіреді, бірақ біз TCP протокол деңгейіндегі кез келген жүктемені айтамыз.
L7 шабуылдарының белгілі бір ерекше белгілері бар. Біріншіден, олар тікелей қолданбаға келеді, яғни олардың желілік құралдар арқылы көрінуі екіталай. Мұндай шабуылдар логиканы пайдаланады және осыған байланысты олар процессорды, жадты, дискіні, дерекқорды және басқа ресурстарды өте тиімді және аз трафикпен пайдаланады.
HTTP тасқыны
Кез келген шабуыл жағдайында жүктемені өңдеуден гөрі жасау оңайырақ, ал L7 жағдайында бұл да дұрыс. Шабуыл трафигін заңды трафиктен ажырату әрқашан оңай емес, және көбінесе мұны жиілік бойынша жасауға болады, бірақ бәрі дұрыс жоспарланған болса, журналдардан шабуылдың қай жерде және заңды сұраулардың қайда екенін түсіну мүмкін емес.
Бірінші мысал ретінде HTTP Flood шабуылын қарастырыңыз. График мұндай шабуылдардың әдетте өте күшті екенін көрсетеді, төмендегі мысалда сұраулардың ең жоғары саны минутына 600 мыңнан асты.
HTTP Flood - жүктемені жасаудың ең оңай жолы. Әдетте, ол ApacheBench сияқты жүктемені тексеру құралының қандай да бір түрін алады және сұрау мен мақсатты орнатады. Осындай қарапайым тәсілмен серверді кэштеуде іске қосылу ықтималдығы жоғары, бірақ оны айналып өту оңай. Мысалы, серверді үнемі жаңа бетке қызмет көрсетуге мәжбүр ететін сұрауға кездейсоқ жолдарды қосу.
Сондай-ақ, жүктемені жасау процесінде пайдаланушы-агент туралы ұмытпаңыз. Танымал тестілеу құралдарының көптеген пайдаланушы-агенттерін жүйелік әкімшілер сүзеді және бұл жағдайда жүктеме серверге жетпеуі мүмкін. Сұрау ішіне шолғыштан азды-көпті жарамды тақырыпты енгізу арқылы нәтижені айтарлықтай жақсартуға болады.
HTTP Flood шабуылдары қаншалықты қарапайым болса да, олардың кемшіліктері де бар. Біріншіден, жүктемені жасау үшін үлкен қуат қажет. Екіншіден, мұндай шабуылдарды анықтау өте оңай, әсіресе олар бір мекенжайдан келсе. Нәтижесінде сұраулар дереу жүйелік әкімшілермен немесе тіпті провайдер деңгейінде сүзіле бастайды.
Нені іздеу керек
Тиімділігін жоғалтпай секундына сұраулар санын азайту үшін сізге аздап қиял көрсетіп, сайтты зерттеу керек. Осылайша, сіз арнаны немесе серверді ғана емес, сонымен қатар қолданбаның жеке бөліктерін, мысалы, дерекқорларды немесе файлдық жүйелерді жүктей аласыз. Сондай-ақ сайттан үлкен есептеулер жасайтын орындарды іздеуге болады: калькуляторлар, өнімді таңдау беттері және т.б. Ақырында, сайтта бірнеше жүз мың жолдан тұратын бетті жасайтын PHP сценарийінің қандай да бір түрі бар екендігі жиі кездеседі. Мұндай сценарий серверді де айтарлықтай жүктейді және шабуылдың нысанасына айналуы мүмкін.
Қайда қарау керек
Тестілеуден бұрын ресурсты сканерлеген кезде, біз, әрине, сайттың өзіне қараймыз. Біз енгізу өрістерінің барлық түрлерін, ауыр файлдарды - жалпы алғанда, ресурс үшін проблемалар тудыруы және оның жұмысын баяулатуы мүмкін барлық нәрселерді іздейміз. Бұл жерде Google Chrome және Firefox жүйелеріндегі банальды әзірлеу құралдары көмектеседі, бет жауап беру уақытын көрсетеді.
Біз сондай-ақ қосалқы домендерді сканерлейміз. Мысалы, белгілі бір интернет-дүкен бар, abc.com және оның admin.abc.com ішкі домені бар. Сірә, бұл авторизациясы бар әкімші панелі, бірақ егер сіз оған жүк салсаңыз, ол негізгі ресурс үшін проблемалар тудыруы мүмкін.
Сайтта api.abc.com қосалқы домені болуы мүмкін. Сірә, бұл мобильді қосымшаларға арналған ресурс. Қолданбаны App Store немесе Google Play дүкенінен табуға, арнайы кіру нүктесін орнатуға, API интерфейсін бөлуге және сынақ тіркелгілерін тіркеуге болады. Мәселе мынада, адамдар көбінесе авторизация арқылы қорғалған кез келген нәрсе қызмет көрсету шабуылдарынан бас тартуға қарсы иммунитет деп ойлайды. Авторизация ең жақсы CAPTCHA болып табылады, бірақ олай емес. 10-20 сынақ тіркелгісін жасау оңай, бірақ оларды жасау арқылы біз күрделі және жасырын функционалдылыққа қол жеткіземіз.
Әрине, біз robots.txt және WebArchive, ViewDNS сайттарында тарихқа қараймыз және ресурстың ескі нұсқаларын іздейміз. Кейде әзірлеушілер, айталық, mail2.yandex.net шығарды, бірақ ескі нұсқасы, mail.yandex.net қалады. Бұл mail.yandex.net сайтына енді қолдау көрсетілмейді, әзірлеу ресурстары оған бөлінбейді, бірақ ол дерекқорды пайдалануды жалғастыруда. Тиісінше, ескі нұсқаны пайдалана отырып, сіз сервердің ресурстарын және орналасудың артындағы барлық нәрсені тиімді пайдалана аласыз. Әрине, бұл әрдайым бола бермейді, бірақ біз әлі де жиі кездеседі.
Әрине, біз барлық сұрау параметрлері мен cookie құрылымын талдаймыз. Сіз, айталық, cookie ішіндегі JSON массивіне кейбір мәндерді тастай аласыз, көп ұяшықтар жасай аласыз және ресурсты негізсіз ұзақ уақыт жұмыс істей аласыз.
Іздеу жүктемесі
Сайтты зерттеген кезде бірінші ойға келетін нәрсе - дерекқорды жүктеу, өйткені барлығында дерлік іздеу бар, және, өкінішке орай, ол нашар қорғалған. Кейбір себептермен әзірлеушілер іздеуге жеткілікті көңіл бөлмейді. Бірақ мұнда бір ұсыныс бар - сіз бір түрдегі сұрауларды жасамауыңыз керек, өйткені HTTP тасқыны сияқты кэштеумен кездесуіңіз мүмкін.
Дерекқорға кездейсоқ сұраулар жасау әрқашан тиімді бола бермейді. Іздеуге қатысты кілт сөздердің тізімін жасау әлдеқайда жақсы. Егер біз интернет-дүкеннің мысалына оралсақ: бұл сайт автомобиль шиналарын сатады және шиналардың радиусын, көлік түрін және басқа параметрлерді орнатуға мүмкіндік береді делік. Тиісінше, сәйкес сөздердің тіркесімі дерекқорды әлдеқайда күрделі жағдайларда жұмыс істеуге мәжбүр етеді.
Сонымен қатар, беттеуді қолданған жөн: іздеу үшін біріншіге қарағанда іздеу нәтижелерінің соңғыдан кейінгі бетін қайтару әлдеқайда қиын. Яғни, беттеу көмегімен жүктемені аздап әртараптандыруға болады.
Төмендегі мысал іздеу жүктемесін көрсетеді. Сынақтың алғашқы секундынан-ақ секундына он сұраныс жылдамдығымен сайттың жұмысы тоқтап, жауап бермегенін байқауға болады.
Іздеу болмаса?
Егер іздеу болмаса, бұл сайтта басқа осал енгізу өрістері жоқ дегенді білдірмейді. Бұл өріс авторизация болуы мүмкін. Қазіргі уақытта әзірлеушілер кіру дерекқорын кемпірқосақ кестесінің шабуылынан қорғау үшін күрделі хэштерді жасауды ұнатады. Бұл жақсы, бірақ мұндай хэштер процессордың көп ресурстарын тұтынады. Жалған рұқсаттардың үлкен ағыны процессордың істен шығуына әкеледі және нәтижесінде сайт жұмысын тоқтатады.
Сайтта пікірлер мен кері байланысқа арналған барлық формалардың болуы өте үлкен мәтіндерді жіберуге немесе жай ғана жаппай тасқынды жасауға себеп болып табылады. Кейде сайттар тіркелген файлдарды, соның ішінде gzip пішімінде қабылдайды. Бұл жағдайда біз 1 ТБ файлды алып, оны gzip көмегімен бірнеше байт немесе килобайтқа қысып, сайтқа жібереміз. Содан кейін ол ашылады және өте қызықты әсер алынады.
Rest API
Мен Rest API сияқты танымал қызметтерге аздап назар аударғым келеді. Rest API қауіпсіздігін қамтамасыз ету қарапайым веб-сайтқа қарағанда әлдеқайда қиын. Тіпті парольді дөрекі күштен және басқа да заңсыз әрекеттерден қорғаудың тривиальды әдістері Rest API үшін жұмыс істемейді.
Rest API интерфейсін бұзу өте оңай, себебі ол дерекқорға тікелей қатынасады. Сонымен қатар, мұндай қызметтің сәтсіздігі бизнес үшін айтарлықтай ауыр зардаптарға әкеледі. Өйткені, Rest API әдетте негізгі веб-сайт үшін ғана емес, сонымен қатар мобильді қосымша және кейбір ішкі бизнес ресурстары үшін де қолданылады. Ал егер мұның бәрі түсіп кетсе, оның әсері қарапайым веб-сайттың істен шығуына қарағанда әлдеқайда күшті болады.
Ауыр мазмұн жүктелуде
Бізге күрделі функционалдығы жоқ қарапайым бір беттік қолданбаны, бастапқы бетті немесе визит картасы веб-сайтын сынау ұсынылса, біз ауыр мазмұнды іздейміз. Мысалы, сервер жіберетін үлкен кескіндер, екілік файлдар, pdf құжаттамасы - біз мұның бәрін жүктеп алуға тырысамыз. Мұндай сынақтар файлдық жүйені жақсы жүктейді және арналарды бітеп тастайды, сондықтан тиімді. Яғни, серверді төмен түсірмесеңіз де, үлкен файлды төмен жылдамдықпен жүктеп алсаңыз, сіз мақсатты сервердің арнасын жай ғана бітеп қоясыз, содан кейін қызмет көрсетуден бас тарту орын алады.
Мұндай сынақтың мысалы 30 RPS жылдамдығында сайт жауап беруді тоқтатқанын немесе 500-ші сервер қателерін шығарғанын көрсетеді.
Серверлерді орнату туралы ұмытпаңыз. Адамның виртуалды машина сатып алғанын, сол жерде Apache орнатқанын, әдепкі бойынша барлығын конфигурациялағанын, PHP қолданбасын орнатқанын және төменде нәтижені көре аласыз.
Мұнда жүктеме тамырға түсіп, тек 10 RPS құрады. Біз 5 минут күттік және сервер істен шықты. Оның не себепті құлағаны толық белгісіз екені рас, бірақ оның жады тым көп болғандықтан, жауап беруді тоқтатқан деген болжам бар.
Толқынға негізделген
Соңғы бір-екі жылда толқынды шабуылдар өте танымал болды. Бұл көптеген ұйымдардың шабуылды сүзуді бастау үшін статистиканы жинақтау үшін белгілі бір уақытты қажет ететін DDoS қорғанысы үшін белгілі бір аппараттық құралдарды сатып алуына байланысты. Яғни, олар алғашқы 30-40 секундта шабуылды сүзбейді, өйткені олар деректерді жинақтайды және үйренеді. Тиісінше, осы 30-40 секундта сіз сайтта көп нәрсені іске қоса аласыз, ресурс барлық сұраулар жойылмайынша ұзақ уақыт бойы қалады.
Төмендегі шабуыл жағдайында 10 минуттық аралық болды, содан кейін шабуылдың жаңа, өзгертілген бөлігі келді.
Яғни, қорғаныс үйренді, сүзуге кірісті, бірақ шабуылдың жаңа, мүлдем басқа бөлігі келді және қорғаныс қайтадан үйрене бастады. Шын мәнінде, сүзу жұмысын тоқтатады, қорғау тиімсіз болады және сайт қолжетімсіз болады.
Толқындық шабуылдар шыңында өте жоғары мәндермен сипатталады, ол L7 жағдайында секундына жүз мың немесе миллион сұранысқа жетуі мүмкін. Егер L3&4 туралы айтатын болсақ, онда жүздеген гигабит трафик болуы мүмкін немесе, егер сіз пакеттерде есептесеңіз, сәйкесінше жүздеген mpps болуы мүмкін.
Мұндай шабуылдардың мәселесі синхрондау болып табылады. Шабуылдар ботнеттен келеді және өте үлкен бір реттік өсуді жасау үшін жоғары деңгейде синхрондау қажет. Және бұл үйлестіру әрқашан нәтиже бермейді: кейде нәтиже өте аянышты болып көрінетін қандай да бір параболалық шың болып табылады.
Жалғыз HTTP емес
L7 HTTP протоколынан басқа, біз басқа протоколдарды пайдаланғанды ұнатамыз. Әдетте, кәдімгі веб-сайтта, әсіресе тұрақты хостингте пошта хаттамалары және MySQL-тің икемділігі бар. Пошта хаттамалары дерекқорларға қарағанда азырақ жүктеледі, бірақ олар сонымен бірге өте тиімді жүктелуі мүмкін және серверде шамадан тыс жүктелген процессормен аяқталады.
2016 жылғы SSH осалдығын пайдаланып, біз өте сәтті болдық. Енді бұл осалдық барлығына дерлік түзетілді, бірақ бұл SSH-ге жүктемені жіберу мүмкін емес дегенді білдірмейді. мүмкін. Авторизациялардың үлкен жүктемесі бар, SSH сервердегі процессордың барлығын дерлік жейді, содан кейін веб-сайт секундына бір немесе екі сұраудан құлап қалады. Сәйкесінше, журналдарға негізделген осы бір немесе екі сұрауды заңды жүктемеден ажырату мүмкін емес.
Біз серверлерде ашатын көптеген қосылымдар да өзекті болып қала береді. Бұған дейін Apache кінәлі болса, енді nginx бұл аурудан зардап шегеді, өйткені ол жиі әдепкі бойынша конфигурацияланады. Nginx ашық ұстай алатын қосылымдар саны шектеулі, сондықтан біз қосылымдардың осы санын ашамыз, nginx енді жаңа қосылымды қабылдамайды, нәтижесінде сайт жұмыс істемейді.
Біздің сынақ кластерімізде SSL қол алысуға шабуыл жасау үшін жеткілікті CPU бар. Негізінде, тәжірибе көрсеткендей, ботнеттер кейде мұны да ұнатады. Бір жағынан, сіз SSLсіз жасай алмайтыныңыз анық, өйткені Google нәтижелері, рейтингі, қауіпсіздік. Екінші жағынан, SSL-де, өкінішке орай, процессор мәселесі бар.
L3&4
L3 және 4 деңгейлеріндегі шабуыл туралы айтатын болсақ, біз әдетте сілтеме деңгейіндегі шабуыл туралы айтамыз. Мұндай жүктеме әрқашан дерлік заңдыдан ерекшеленеді, егер ол SYN-тасқын шабуылы болмаса. Қауіпсіздік құралдарына арналған SYN-flood шабуылдарының проблемасы олардың үлкен көлемі болып табылады. Максималды L3&4 мәні 1,5-2 Тбит/с болды. Трафиктің мұндай түрін өңдеу тіпті ірі компаниялар үшін, соның ішінде Oracle және Google үшін өте қиын.
SYN және SYN-ACK қосылымды орнату кезінде қолданылатын пакеттер. Сондықтан SYN-тасқынды заңды жүктемеден айыру қиын: бұл байланыс орнатуға келген SYN ме, әлде су тасқынының бөлігі ме, белгісіз.
UDP-тасқын
Әдетте, шабуылдаушылар біздегі мүмкіндіктерге ие емес, сондықтан шабуылдарды ұйымдастыру үшін күшейтуді пайдалануға болады. Яғни, шабуылдаушы Интернетті сканерлейді және, мысалы, бір SYN пакетіне жауап ретінде үш SYN-ACK жауап беретін осал немесе қате конфигурацияланған серверлерді табады. Мақсатты сервер мекенжайынан бастапқы мекенжайды бұрмалау арқылы қуатты бір пакетпен үш есе арттыруға және трафикті құрбанға қайта бағыттауға болады.
Күшейтуге қатысты мәселе оларды анықтау қиын. Соңғы мысалдарға осал мемкэштің сенсациялық оқиғасы жатады. Сонымен қатар, қазір көптеген IoT құрылғылары, IP камералары бар, олар да негізінен әдепкі бойынша конфигурацияланады және әдепкі бойынша олар қате конфигурацияланады, сондықтан шабуылдаушылар көбінесе осындай құрылғылар арқылы шабуыл жасайды.
Күрделі SYN тасқыны
SYN-flood - әзірлеуші көзқарасы бойынша шабуылдың ең қызықты түрі. Мәселе мынада, жүйе әкімшілері қорғау үшін жиі IP блоктауын пайдаланады. Сонымен қатар, IP блоктау тек сценарийлерді пайдаланып әрекет ететін жүйелік әкімшілерге ғана емес, сонымен қатар, өкінішке орай, көп ақшаға сатып алынатын кейбір қауіпсіздік жүйелеріне де әсер етеді.
Бұл әдіс апатқа айналуы мүмкін, өйткені шабуылдаушылар IP мекенжайларын ауыстырса, компания өзінің ішкі желісін блоктайды. Брандмауэр өз кластерін блоктаған кезде, шығыс сыртқы өзара әрекеттесу сәтсіз болады және ресурс сәтсіз болады.
Оның үстіне өз желіңізді блоктау қиын емес. Егер клиент кеңсесінде Wi-Fi желісі болса немесе ресурстардың өнімділігі әртүрлі бақылау жүйелері арқылы өлшенсе, біз осы бақылау жүйесінің немесе клиент кеңсесінің Wi-Fi IP мекенжайын алып, оны көз ретінде пайдаланамыз. Соңында ресурс қолжетімді болып көрінеді, бірақ мақсатты IP мекенжайлары бұғатталған. Осылайша, компанияның жаңа өнімі ұсынылып жатқан HighLoad конференциясының Wi-Fi желісі бұғатталуы мүмкін және бұл белгілі бір іскерлік және экономикалық шығындарды талап етеді.
Тестілеу кезінде біз кез келген сыртқы ресурстармен memcached арқылы күшейтуді пайдалана алмаймыз, өйткені трафикті тек рұқсат етілген IP мекенжайларына жіберу туралы келісімдер бар. Тиісінше, жүйе екі немесе үш SYN-ACK арқылы бір SYN жіберуге жауап бергенде және шығыс кезінде шабуыл екі немесе үш есеге көбейтілген кезде SYN және SYN-ACK арқылы күшейтуді қолданамыз.
Құралдар
L7 жүктемесі үшін біз қолданатын негізгі құралдардың бірі - Яндекс-танк. Атап айтқанда, фантом мылтық ретінде пайдаланылады, сонымен қатар картридждерді жасау және нәтижелерді талдау үшін бірнеше сценарийлер бар.
Tcpdump желілік трафикті талдау үшін, ал Nmap серверді талдау үшін пайдаланылады. L3&4 деңгейінде жүктемені жасау үшін OpenSSL және DPDK кітапханасы бар өз сиқырымыз пайдаланылады. DPDK - бұл Linux стекін айналып өтіп, желілік интерфейспен жұмыс істеуге мүмкіндік беретін Intel кітапханасы, осылайша тиімділікті арттырады. Әрине, біз DPDK-ны тек L3&4 деңгейінде ғана емес, сонымен қатар L7 деңгейінде де қолданамыз, өйткені ол бір машинадан секундына бірнеше миллион сұраулар ауқымында өте жоғары жүктеме ағынын жасауға мүмкіндік береді.
Біз сондай-ақ белгілі бір трафик генераторларын және арнайы сынақтар үшін жазатын арнайы құралдарды пайдаланамыз. Егер SSH бойынша осалдықты еске түсірсек, жоғарыда аталған жиынды пайдалану мүмкін емес. Егер біз пошта протоколына шабуыл жасасақ, біз пошта утилиталарын аламыз немесе оларға жай ғана сценарий жазамыз.
қорытындылар
Қорытынды ретінде мен айтқым келеді:
- Классикалық жүктемелік тестілеуден басқа, стресс-тестілеуді жүргізу қажет. Бізде серіктестің қосалқы мердігері тек жүктеме сынағы жүргізген нақты мысал бар. Бұл ресурстың қалыпты жүктемеге төтеп бере алатынын көрсетті. Бірақ содан кейін қалыпты емес жүктеме пайда болды, сайтқа келушілер ресурсты сәл басқаша пайдалана бастады, нәтижесінде қосалқы мердігер жатып қалды. Осылайша, сіз DDoS шабуылдарынан қорғалған болсаңыз да, осалдықтарды іздеген жөн.
- Жүйенің кейбір бөліктерін басқалардан оқшаулау қажет. Егер сізде іздеу болса, оны бөлек машиналарға жылжыту керек, яғни тіпті Docker-ке емес. Өйткені іздеу немесе авторизация сәтсіз аяқталса, кем дегенде бір нәрсе жұмысын жалғастырады. Интернет-дүкен жағдайында пайдаланушылар каталогтан өнімдерді табуды, агрегатордан өтуді, рұқсаты бар болса сатып алуды немесе OAuth2 арқылы авторизациялауды жалғастырады.
- Бұлттық қызметтердің барлық түрлерін назардан тыс қалдырмаңыз.
- CDN желісін кідірістерді оңтайландыру үшін ғана емес, сонымен қатар арнаның таусылуына шабуылдардан және жай статикалық трафикке түсуден қорғау құралы ретінде пайдаланыңыз.
- Арнайы қорғау қызметтерін пайдалану қажет. Арна деңгейінде өзіңізді L3&4 шабуылдарынан қорғай алмайсыз, себебі сізде жеткілікті арна жоқ. Сондай-ақ L7 шабуылдарымен күресу екіталай, өйткені олар өте үлкен болуы мүмкін. Сонымен қатар, шағын шабуылдарды іздеу әлі де арнайы қызметтердің, арнайы алгоритмдердің құқығы болып табылады.
- Тұрақты түрде жаңартыңыз. Бұл ядроға ғана емес, сонымен қатар SSH демонына да қатысты, әсіресе олар сыртқа ашық болса. Негізінде, барлығын жаңарту қажет, өйткені сіз белгілі бір осалдықтарды өз бетіңізше бақылай алмайсыз.
Ақпарат көзі: www.habr.com