Variti боттордон жана DDoS чабуулдарынан коргоону иштеп чыгат, ошондой эле стрессти жана жүктөмдү текшерүүнү жүргүзөт. HighLoad++ 2018 конференциясында биз ар кандай чабуулдардан ресурстарды кантип коргоо керектиги жөнүндө сүйлөштүк. Кыскача айтканда: системанын бөлүктөрүн изоляциялап, булут кызматтарын жана CDNди колдонуп, үзгүлтүксүз жаңыртып туруңуз. Бирок сиз дагы эле атайын компанияларсыз коргоону көтөрө албайсыз :)
Текстти окуудан мурун сиз кыскача тезистерди окуй аласыз .
Ал эми окууну жактырбасаңыз же жөн гана видеону көргүңүз келсе, биздин репортаждын жазуусу төмөндө спойлердин астында.
Отчеттун видео жазуусу
Көптөгөн компаниялар жүк тестин кантип жасоону билишет, бирок баары эле стресс-тестирлөө жасай бербейт. Кээ бир кардарларыбыз алардын сайтын кол тийбес деп ойлошот, анткени аларда жогорку жүктөө системасы бар жана ал чабуулдардан жакшы коргойт. Бул толугу менен туура эмес экенин көрсөтүп турат.
Албетте, тестирлөөдөн мурун, биз кардардын уруксатын алып, кол коюп, мөөр басабыз жана биздин жардамыбыз менен DDoS чабуулун эч кимге жасоого болбойт. Сыноо кардар тандаган убакта, анын ресурсуна трафик минималдуу болгон учурда жүргүзүлөт жана кирүү көйгөйлөрү кардарларга таасирин тийгизбейт. Мындан тышкары, тестирлөө учурунда бир нерсе туура эмес болуп кетиши мүмкүн болгондуктан, биз кардар менен дайыма байланыштабыз. Бул жетишилген натыйжалар жөнүндө гана эмес, тестирлөө учурунда бир нерсени өзгөртүүгө мүмкүндүк берет. Тестирлөө аяктагандан кийин биз ар дайым отчет түзөбүз, анда биз табылган кемчиликтерди көрсөтүп, сайттын алсыз жактарын жоюу боюнча сунуштарды беребиз.
Биз кандай иштейбиз
Сыноодо биз ботнетти туурайбыз. Тармактарыбызда жайгашпаган кардарлар менен иштешкендиктен, чектөөлөр же коргоо иштетилгендиктен тест биринчи мүнөттө бүтпөөсү үчүн, жүктү бир IPден эмес, өзүбүздүн ички тармактан беребиз. Мындан тышкары, олуттуу жүктү түзүү үчүн, бизде өзүбүздүн күчтүү тест серверибиз бар.
Постулаттар
Өтө көп жакшы дегенди билдирбейт
Канчалык аз жүк болсо, биз ресурсту ийгиликсиздикке жеткире алсак, ошончолук жакшы. Эгер сиз сайтты секундасына бир суроо, ал тургай мүнөтүнө бир суроо боюнча ишин токтото алсаңыз, бул эң сонун. Анткени адепсиздик мыйзамына ылайык, колдонуучулар же чабуулчулар кокусунан ушул өзгөчө аялуу жерине түшүп калышат.
Жарым-жартылай ишке ашпай калгандан жакшыраак
Биз ар дайым системаларды гетерогендик кылууну сунуштайбыз. Мындан тышкары, аларды контейнерлештирүү менен эмес, физикалык деңгээлде бөлүү керек. Физикалык бөлүнүү учурунда, сайтта бир нерсе иштебей калса да, ал толугу менен иштебей калбашы ыктымал жана колдонуучулар функциянын жок дегенде бир бөлүгүнө кирүү мүмкүнчүлүгүнө ээ болушат.
Жакшы архитектура туруктуулуктун негизи болуп саналат
Ресурстун катачылыкка чыдамкайлыгы жана анын чабуулдарга жана жүктөргө туруштук берүү жөндөмдүүлүгү долбоорлоо стадиясында, чындыгында блокнотко биринчи блок-схемаларды түзүү баскычында белгилениши керек. Анткени өлүмгө алып келе турган каталар кирип кетсе, келечекте аларды оңдоого болот, бирок бул абдан кыйын.
Код гана эмес, конфигурация да жакшы болушу керек
Көптөгөн адамдар жакшы өнүктүрүү командасы катага чыдамдуу кызматтын кепилдиги деп ойлошот. Жакшы иштеп чыгуу командасы чындап керек, бирок жакшы операциялар, жакшы DevOps да болушу керек. Башкача айтканда, бизге Linux жана тармакты туура конфигурациялай турган, nginxте конфигурацияларды туура жаза турган, чектөөлөрдү кое турган адистер керек. Болбосо, ресурс тестирлөөдө гана жакшы иштейт, ал эми кайсы бир учурда өндүрүштө баары бузулат.
Жүктөө жана стресс тестирлөөнүн ортосундагы айырмачылыктар
Жүктөлгөн тестирлөө системанын иштешинин чектерин аныктоого мүмкүндүк берет. Стресс тестирлөө системанын алсыз жактарын табууга багытталган жана бул системаны бузуу жана анын айрым бөлүктөрүнүн иштен чыгуу процессинде өзүн кандай алып жүрөрүн көрүү үчүн колдонулат. Бул учурда, стресс-тестирлөө башталганга чейин жүктүн мүнөзү, адатта, кардар үчүн белгисиз бойдон калууда.
L7 чабуулдарынын айырмалоочу өзгөчөлүктөрү
Биз көбүнчө жүктүн түрлөрүн L7 жана L3&4 деңгээлдериндеги жүктөргө бөлөбүз. L7 - бул колдонмо деңгээлиндеги жүк, көбүнчө HTTP гана билдирет, бирок биз TCP протоколунун деңгээлинде кандайдыр бир жүктү билдирет.
L7 чабуулдары белгилүү бир өзгөчөлүктөргө ээ. Биринчиден, алар түздөн-түз тиркемеге келишет, башкача айтканда, алар тармактык каражаттар аркылуу чагылдырылышы күмөн. Мындай чабуулдар логиканы колдонушат жана ушундан улам алар CPU, эстутум, диск, маалымат базасы жана башка ресурстарды абдан эффективдүү жана аз трафик менен керектейт.
HTTP Flood
Кандайдыр бир чабуул болгон учурда, жүктү башкарууга караганда түзүү оңой, ал эми 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 мындан ары колдоого алынбайт, өнүктүрүү ресурстары ага бөлүнбөйт, бирок ал маалымат базасын колдонууну улантууда. Демек, эски версияны колдонуу менен, сиз бэкендинин ресурстарын жана макеттин артында турган нерселердин бардыгын натыйжалуу колдоно аласыз. Албетте, бул дайыма эле боло бербейт, бирок биз дагы эле көп кездешет.
Албетте, биз бардык суроо-талап параметрлерин жана куки структурасын талдайбыз. Сиз, айталы, куки ичиндеги JSON массивине кандайдыр бир маанини түшүрүп, көп уяларды түзүп, ресурсту негизсиз узак убакытка иштете аласыз.
Издөө жүктөө
Сайтты изилдеп жатканда акылга келген биринчи нерсе - бул маалымат базасын жүктөө, анткени дээрлик бардыгында издөө бар жана дээрлик бардыгы үчүн, тилекке каршы, ал начар корголгон. Эмнегедир иштеп чыгуучулар издөөгө жетиштүү көңүл бурушпайт. Бирок бул жерде бир сунуш бар - сиз бир түрдөгү суроо-талаптарды жасабашыңыз керек, анткени HTTP селдегидей кэшке туш болушуңуз мүмкүн.
Маалыматтар базасына туш келди суроо берүү дайыма эле натыйжалуу боло бербейт. Издөөгө ылайыктуу ачкыч сөздөрдүн тизмесин түзүү алда канча жакшы. Эгерде биз интернет-дүкөндүн мисалына кайрылсак: бул сайт унаа дөңгөлөктөрүн сатат жана дөңгөлөктөрдүн радиусун, машинанын түрүн жана башка параметрлерди коюуга мүмкүндүк берет дейли. Демек, тиешелүү сөздөрдүн айкалышы маалымат базасын бир топ татаал шарттарда иштөөгө мажбурлайт.
Мындан тышкары, пагинацияны колдонуу керек: издөө үчүн издөө натыйжаларынын акыркы барагын кайтаруу биринчисине караганда алда канча кыйыныраак. Башкача айтканда, пагинациянын жардамы менен жүктү бир аз диверсификациялай аласыз.
Төмөндөгү мисал издөө жүгүн көрсөтөт. Сыноонун биринчи секундунан тартып секундасына он суроо ылдамдыкта сайт түшүп, жооп бербей калганын көрүүгө болот.
Издөө жок болсо?
Эгерде издөө жок болсо, бул сайтта башка аялуу киргизүү талаалары жок дегенди билдирбейт. Бул талаа уруксат болушу мүмкүн. Бүгүнкү күндө иштеп чыгуучулар кирүү маалыматтар базасын асан-үсөн үстөл чабуулунан коргоо үчүн татаал хэштерди жасаганды жакшы көрүшөт. Бул жакшы, бирок мындай хэштер CPU ресурстарын көп керектейт. Жалган авторизациялардын чоң агымы процессордун иштебей калышына алып келет, натыйжада сайт иштебей калат.
Комментарийлердин жана пикирлердин ар кандай формаларынын сайтында болушу ал жерге өтө чоң тексттерди жөнөтүүгө же жөн эле чоң селди жаратууга негиз болуп саналат. Кээде сайттар тиркелген файлдарды, анын ичинде gzip форматында кабыл алышат. Бул учурда, биз 1TB файлды алып, аны gzip аркылуу бир нече байт же килобайтка кысып, сайтка жөнөтөбүз. Андан кийин ал ачылып, абдан кызыктуу эффект алынат.
Эс алуу 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 жабышып турат. Почта протоколдору маалымат базаларына караганда азыраак жүктөмгө дуушар болушат, бирок алар дагы эффективдүү жүктөлүшү мүмкүн жана серверде ашыкча жүктөлгөн CPU менен аяктайт.
Биз 2016-жылдагы SSH аялуулугун колдонууда ийгиликтүү болдук. Эми бул аялуу дээрлик бардыгы үчүн оңдолду, бирок бул жүктү SSHга тапшырууга болбойт дегенди билдирбейт. мүмкүн. Жөн эле чоң жүктөө бар, SSH сервердеги дээрлик бардык процессорду жейт, андан кийин веб-сайт секундасына бир же эки суроо-талаптан кулап калат. Демек, журналдарга негизделген бул бир же эки суроону мыйзамдуу жүктөн айырмалоо мүмкүн эмес.
Серверлерде ачкан көптөгөн байланыштар да актуалдуу бойдон калууда. Буга чейин Apache күнөөлүү болсо, азыр nginx буга күнөөлүү, анткени ал көбүнчө демейки боюнча конфигурацияланат. Nginx ачык кармай турган байланыштардын саны чектелүү, ошондуктан биз бул сандагы байланыштарды ачабыз, nginx мындан ары жаңы туташууну кабыл албайт жана натыйжада сайт иштебейт.
Сыноочу кластерибизде SSL кол алышуусуна кол салуу үчүн жетиштүү CPU бар. Негизи, практика көрсөткөндөй, ботнеттер кээде муну да жасаганды жакшы көрүшөт. Бир жагынан алганда, Google натыйжалары, рейтинги, коопсуздук, анткени, SSL жок кыла албай турганы түшүнүктүү. Экинчи жагынан, SSL, тилекке каршы, CPU маселеси бар.
L3&4
L3 & 4 деңгээлиндеги чабуул жөнүндө сөз кылганда, биз көбүнчө шилтеме деңгээлиндеги чабуул жөнүндө сөз кылабыз. Мындай жүк дээрлик ар дайым мыйзамдуу айырмаланып турат, эгерде ал SYN-топон суу чабуулу болбосо. Коопсуздук куралдары үчүн SYN-топон суу чабуулдары менен көйгөй алардын чоң көлөмү. Максималдуу L3&4 мааниси 1,5-2 Тбит/сек болгон. Мындай трафикти Oracle жана Google сыяктуу ири компаниялар үчүн да иштетүү өтө кыйын.
SYN жана SYN-ACK - бул байланышты орнотууда колдонулган пакеттер. Ошондуктан, SYN-топон мыйзамдуу жүк айырмалоо кыйын: бул байланыш түзүү үчүн келген SYN, же селдин бир бөлүгү болуп саналат, белгисиз.
UDP - сел
Адатта, чабуулчулардын бизде болгон мүмкүнчүлүктөрү жок, андыктан чабуулдарды уюштуруу үчүн күчөтүү колдонулушу мүмкүн. Башкача айтканда, чабуулчу Интернетти сканерлейт жана, мисалы, бир SYN пакетине жооп катары үч SYN-ACK менен жооп берген аялуу же туура эмес конфигурацияланган серверлерди табат. Булак дарегин максаттуу сервердин дарегинен бурмалоо менен, бир пакет менен кубаттуулукту үч эсеге көбөйтүүгө жана трафикти жабырлануучуга багыттоого болот.
Күчөтүүдөгү көйгөй аларды аныктоо кыйын. Акыркы мисалдар аялуу memcached сенсациялуу окуяны камтыйт. Мындан тышкары, азыр көптөгөн IoT түзмөктөрү, IP камералары бар, алар көбүнчө демейки боюнча конфигурацияланган жана демейки боюнча алар туура эмес конфигурацияланган, ошондуктан чабуулчулар көбүнчө ушундай түзүлүштөр аркылуу чабуул жасашат.
Татаал SYN-топон суу
SYN-топон, балким, иштеп чыгуучунун көз карашы боюнча чабуулдун эң кызыктуу түрү. Маселе, системалык администраторлор коргоо үчүн IP бөгөттөөсүн көп колдонушат. Мындан тышкары, IP бөгөттөө скрипттерди колдонуу менен иш алып барган системалык администраторлорго гана эмес, тилекке каршы, көп акчага сатылып алынган кээ бир коопсуздук системаларына да таасирин тийгизет.
Бул ыкма кырсыкка айланып кетиши мүмкүн, анткени чабуулчулар IP даректерин алмаштырса, компания өзүнүн ички тармагын бөгөттөп салат. Firewall өзүнүн кластерин бөгөттөп койгондо, чыгаруу тышкы өз ара аракеттенишүүдө жана ресурс иштебей калат.
Анын үстүнө, өз тармагын бөгөт коюу кыйын эмес. Эгерде кардардын кеңсесинде Wi-Fi тармагы болсо, же ресурстардын иштеши ар кандай мониторинг тутумдары менен өлчөнө турган болсо, анда биз бул мониторинг системасынын же кардардын кеңсесинин Wi-Fi IP дарегин алып, аны булак катары колдонобуз. Акыр-аягы, ресурс жеткиликтүү окшойт, бирок максаттуу IP даректери бөгөттөлгөн. Ошентип, компаниянын жаңы продуктусу көрсөтүлүп жаткан HighLoad конференциясынын Wi-Fi тармагы жабылышы мүмкүн жана бул белгилүү бир бизнес жана экономикалык чыгымдарды талап кылат.
Сыноо учурунда биз эч кандай тышкы ресурстар менен мемкач аркылуу күчөтүүнү колдоно албайбыз, анткени трафикти уруксат берилген IP даректерге гана жөнөтүү боюнча келишимдер бар. Демек, система эки же үч SYN-ACK менен бир SYN жөнөтүүгө жооп бергенде, SYN жана SYN-ACK аркылуу күчөтүүнү колдонобуз жана чыгууда чабуул эки же үч эсеге көбөйөт.
аспаптар
L7 жүктөө үчүн биз колдонгон негизги куралдардын бири Яндекс-танк болуп саналат. Атап айтканда, фантом мылтык катары колдонулат, ошондой эле картридждерди түзүү жана натыйжаларды талдоо үчүн бир нече сценарийлер бар.
Tcpdump тармак трафигин талдоо үчүн, ал эми Nmap серверди талдоо үчүн колдонулат. L3&4 деңгээлинде жүктү түзүү үчүн OpenSSL жана DPDK китепканасы менен өзүбүздүн сыйкырыбыз колдонулат. DPDK - бул Intel китепканасы, ал Linux стекинен өтүп, тармак интерфейси менен иштөөгө мүмкүндүк берет, ошону менен натыйжалуулукту жогорулатат. Албетте, биз DPDKди L3&4 деңгээлинде гана эмес, L7 деңгээлинде да колдонобуз, анткени ал бизге бир машинадан секундасына бир нече миллион сурамдардын чегинде өтө жогорку жүк агымын түзүүгө мүмкүндүк берет.
Биз ошондой эле белгилүү бир тесттер үчүн жазган трафик генераторлорун жана атайын куралдарды колдонобуз. Эгерде биз SSH алкагындагы аялуулукту эстесек, анда жогорудагы топтомду колдонууга болбойт. Эгерде биз почта протоколуна кол салсак, почтанын утилиталарын алабыз же аларга жөн гана скрипт жазабыз.
табылгалары
Жыйынтык катары мен айткым келет:
- Классикалык жүк тестирлөөдөн тышкары, стресс-тестирлөө жүргүзүү зарыл. Бизде өнөктөштүн субподрядчысы жүктөм сыноону гана жүргүзгөн реалдуу мисал бар. Бул ресурс кадимки жүктү көтөрө аларын көрсөттү. Бирок андан кийин анормалдуу жүк пайда болуп, сайтка келгендер ресурсту бир аз башкача колдоно башташты, натыйжада субподрядчы жатып калды. Ошентип, сиз DDoS чабуулдарынан корголгон болсоңуз да, алсыздыктарды издөө керек.
- Системанын айрым бөлүктөрүн башкалардан бөлүп алуу зарыл. Эгер сизде издөө болсо, аны өзүнчө машиналарга, башкача айтканда, Dockerге да эмес, жылдыруу керек. Анткени издөө же авторизация ишке ашпай калса, жок дегенде бир нерсе иштей берет. Интернет-дүкөндө колдонуучулар каталогдон өнүмдөрдү таба беришет, агрегатордон өтүшөт, эгер алар мурунтан эле уруксаты бар болсо сатып алышат же OAuth2 аркылуу уруксат беришет.
- Булут кызматтарынын бардык түрлөрүнө көңүл бурбаңыз.
- CDNди тармактын кечигүүлөрүн оптималдаштыруу үчүн гана эмес, каналдын түгөнүп калышына жана жөн эле статикалык трафикке агып кетүүсүнө каршы коргонуу каражаты катары колдонуңуз.
- Атайын коргоо кызматтарын колдонуу зарыл. Канал деңгээлинде өзүңүздү L3&4 чабуулдарынан коргой албайсыз, анткени сизде жетиштүү канал жок. Сиз L7 чабуулдарына каршы күрөшө албайсыз, анткени алар абдан чоң болушу мүмкүн. Мындан тышкары, кичинекей чабуулдарды издөө дагы эле атайын кызматтардын, атайын алгоритмдердин укугу.
- үзгүлтүксүз жаңыртуу. Бул өзөккө гана эмес, SSH демонуна да тиешелүү, өзгөчө, эгер сизде алар сыртка ачык болсо. Негизи, бардыгын жаңыртуу керек, анткени сиз өз алдынча айрым кемчиликтерди байкай албайсыз.
Source: www.habr.com