DDoS փրկության համար. ինչպես ենք մենք իրականացնում սթրեսի և ծանրաբեռնվածության թեստեր

Variti-ն զարգացնում է պաշտպանություն բոտերից և DDoS հարձակումներից, ինչպես նաև իրականացնում է սթրեսի և ծանրաբեռնվածության թեստավորում: HighLoad++ 2018 կոնֆերանսում մենք խոսեցինք այն մասին, թե ինչպես պաշտպանել ռեսուրսները տարբեր տեսակի հարձակումներից: Մի խոսքով, մեկուսացրեք համակարգի մասերը, օգտագործեք ամպային ծառայություններ և CDN-ներ և պարբերաբար թարմացրեք: Բայց դուք դեռ չեք կարողանա պաշտպանել առանց մասնագիտացված ընկերությունների :)

Նախքան տեքստը կարդալը կարող եք կարդալ կարճ ակնարկները համաժողովի կայքում.
Իսկ եթե չեք սիրում կարդալ կամ պարզապես ցանկանում եք դիտել տեսանյութը, ապա մեր ռեպորտաժի ձայնագրությունը՝ ստորև՝ սփոյլերի տակ։

Հաշվետվության տեսագրություն

Շատ ընկերություններ արդեն գիտեն, թե ինչպես անել բեռնվածության թեստավորում, բայց ոչ բոլորն են սթրես-թեստավորում: Մեր հաճախորդներից ոմանք կարծում են, որ իրենց կայքը անխոցելի է, քանի որ նրանք ունեն բարձր բեռնման համակարգ, և այն լավ է պաշտպանում հարձակումներից։ Մենք ցույց ենք տալիս, որ դա ամբողջովին ճիշտ չէ:
Իհարկե, նախքան թեստեր անցկացնելը, մենք հաճախորդից թույլտվություն ենք ստանում՝ ստորագրված և կնիքով, և մեր օգնությամբ DDoS հարձակումը չի կարող իրականացվել որևէ մեկի վրա։ Թեստավորումն իրականացվում է հաճախորդի կողմից ընտրված ժամանակ, երբ նրա ռեսուրսի երթևեկությունը նվազագույն է, և մուտքի խնդիրները չեն ազդի հաճախորդների վրա: Բացի այդ, քանի որ թեստավորման ընթացքում ինչ-որ բան միշտ կարող է սխալ լինել, մենք մշտական ​​կապ ունենք հաճախորդի հետ: Սա թույլ է տալիս ոչ միայն զեկուցել ձեռք բերված արդյունքների մասին, այլև թեստավորման ընթացքում ինչ-որ բան փոխել: Թեստավորումն ավարտելուց հետո մենք միշտ կազմում ենք հաշվետվություն, որտեղ մատնանշում ենք հայտնաբերված թերությունները և առաջարկում ենք կայքի թույլ կողմերը վերացնելու վերաբերյալ:

Ինչպես ենք մենք աշխատում

Փորձարկելիս մենք ընդօրինակում ենք բոտնետը: Քանի որ մենք աշխատում ենք հաճախորդների հետ, որոնք տեղակայված չեն մեր ցանցերում, որպեսզի համոզվենք, որ թեստը չի ավարտվում առաջին րոպեին սահմանների կամ պաշտպանության գործարկման պատճառով, մենք բեռը մատակարարում ենք ոչ թե մեկ IP-ից, այլ մեր սեփական ենթացանցից: Բացի այդ, զգալի բեռ ստեղծելու համար մենք ունենք մեր բավականին հզոր թեստային սերվերը:

Պոստուլատներ

Չափից շատ չի նշանակում լավ
Որքան քիչ ծանրաբեռնվածություն կարողանանք ռեսուրս բերել ձախողման, այնքան լավ: Եթե ​​դուք կարող եք ստիպել, որ կայքը դադարեցնի գործել վայրկյանում մեկ խնդրանքով, կամ նույնիսկ մեկ խնդրանքով մեկ րոպեում, դա հիանալի է: Քանի որ ըստ ստորության օրենքի՝ օգտատերերը կամ հարձակվողները պատահաբար կհայտնվեն այս կոնկրետ խոցելիության մեջ:

Մասնակի ձախողումը ավելի լավ է, քան ամբողջական ձախողումը
Մենք միշտ խորհուրդ ենք տալիս համակարգերը դարձնել տարասեռ: Ընդ որում, արժե դրանք առանձնացնել ֆիզիկական մակարդակով, այլ ոչ միայն կոնտեյներացման միջոցով։ Ֆիզիկական տարանջատման դեպքում, նույնիսկ եթե կայքում ինչ-որ բան ձախողվի, մեծ է հավանականությունը, որ այն ամբողջությամբ չի դադարի աշխատել, և օգտատերերը կշարունակեն օգտվել ֆունկցիոնալության գոնե մի մասից:

Լավ ճարտարապետությունը կայունության հիմքն է
Ռեսուրսի սխալների հանդուրժողականությունը և հարձակումներին և բեռներին դիմակայելու կարողությունը պետք է սահմանվի նախագծման փուլում, ըստ էության, նոթատետրում առաջին սխեմաները գծելու փուլում: Որովհետև եթե ճակատագրական սխալները սողոսկեն, ապա հնարավոր է դրանք շտկել ապագայում, բայց դա շատ դժվար է։

Ոչ միայն կոդը պետք է լավ լինի, այլ նաև կոնֆիգուրացիա
Շատերը կարծում են, որ լավ զարգացման թիմը անսարքության հանդուրժող ծառայության երաշխիք է: Լավ մշակող թիմը իսկապես անհրաժեշտ է, բայց պետք է նաև լավ գործողություններ, լավ DevOps: Այսինքն՝ մեզ պետք են մասնագետներ, ովքեր ճիշտ կկարգավորեն Linux-ը և ցանցը, nginx-ում ճիշտ կգրեն կոնֆիգուրներ, սահմաններ կդնեն և այլն։ Հակառակ դեպքում ռեսուրսը լավ կաշխատի միայն թեստավորման ժամանակ, և ինչ-որ պահի ամեն ինչ կխախտվի արտադրության մեջ։

Տարբերությունները ծանրաբեռնվածության և սթրեսի փորձարկման միջև
Բեռնվածության փորձարկումը թույլ է տալիս բացահայտել համակարգի գործունեության սահմանները: Սթրես-թեստավորումն ուղղված է համակարգում թույլ կողմերը գտնելուն և օգտագործվում է այս համակարգը կոտրելու և տեսնելու համար, թե ինչպես է այն իրեն պահելու որոշ մասերի խափանման գործընթացում: Այս դեպքում բեռի բնույթը սովորաբար մնում է հաճախորդի համար անհայտ մինչև սթրես-թեստավորումը սկսելը:

L7 հարձակումների տարբերակիչ առանձնահատկությունները

Մենք սովորաբար բեռի տեսակները բաժանում ենք բեռների՝ L7 և L3&4 մակարդակներում: L7-ը բեռնվածություն է հավելվածի մակարդակում, ամենից հաճախ դա նշանակում է միայն HTTP, բայց մենք նկատի ունենք ցանկացած բեռ TCP արձանագրության մակարդակում:
L7 հարձակումները ունեն որոշակի տարբերակիչ հատկանիշներ: Նախ, դրանք գալիս են անմիջապես հավելվածին, այսինքն՝ դժվար թե դրանք արտացոլվեն ցանցային միջոցներով։ Նման հարձակումները օգտագործում են տրամաբանություն, և դրա շնորհիվ նրանք սպառում են CPU, հիշողություն, սկավառակ, տվյալների բազա և այլ ռեսուրսներ շատ արդյունավետ և քիչ տրաֆիկով:

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-ն այլևս չի աջակցվում, զարգացման ռեսուրսներ չեն հատկացվում դրան, բայց այն շարունակում է սպառել տվյալների բազան։ Համապատասխանաբար, օգտագործելով հին տարբերակը, դուք կարող եք արդյունավետորեն օգտագործել backend-ի ռեսուրսները և այն ամենը, ինչ գտնվում է դասավորության հետևում: Իհարկե, դա միշտ չէ, որ տեղի է ունենում, բայց մենք դեռ շատ հաճախ ենք հանդիպում դրան:
Բնականաբար, մենք վերլուծում ենք հարցման բոլոր պարամետրերը և թխուկների կառուցվածքը: Դուք կարող եք, ասենք, որոշակի արժեք լցնել JSON զանգվածի մեջ թխուկի ներսում, ստեղծել բազմաթիվ բույններ և ստիպել ռեսուրսը աշխատել անհիմն երկար ժամանակ:

Որոնման բեռնվածություն

Կայքը ուսումնասիրելիս առաջին բանը, որ գալիս է մտքին, տվյալների բազան բեռնելն է, քանի որ գրեթե բոլորն ունեն որոնում, և գրեթե բոլորի համար, ցավոք, այն վատ է պաշտպանված: Չգիտես ինչու, մշակողները բավարար ուշադրություն չեն դարձնում որոնմանը: Բայց այստեղ կա մեկ խորհուրդ՝ դուք չպետք է նույն տիպի հարցումներ կատարեք, քանի որ դուք կարող եք հանդիպել քեշավորման, ինչպես դա տեղի է ունենում HTTP flood-ի դեպքում:
Տվյալների բազայում պատահական հարցումներ կատարելը նույնպես միշտ չէ, որ արդյունավետ է: Շատ ավելի լավ է ստեղծել որոնման համար համապատասխան հիմնաբառերի ցանկ: Եթե ​​վերադառնանք առցանց խանութի օրինակին, ասենք, որ կայքը վաճառում է մեքենաների անվադողեր և թույլ է տալիս սահմանել անվադողերի շառավիղը, մեքենայի տեսակը և այլ պարամետրեր: Համապատասխանաբար, համապատասխան բառերի համակցությունները կստիպի տվյալների բազան աշխատել շատ ավելի բարդ պայմաններում:
Բացի այդ, արժե օգտագործել էջավորումը. որոնման արդյունքների նախավերջին էջը վերադարձնելը շատ ավելի դժվար է, քան առաջինը: Այսինքն, էջադրման օգնությամբ դուք կարող եք մի փոքր դիվերսիֆիկացնել բեռը:
Ստորև բերված օրինակը ցույց է տալիս որոնման բեռը: Երևում է, որ թեստի առաջին վայրկյանից վայրկյանում տասը հարցում արագությամբ կայքը իջել է և չի արձագանքել։

Եթե ​​որոնում չկա՞

Եթե ​​որոնում չկա, դա չի նշանակում, որ կայքը չի պարունակում այլ խոցելի մուտքային դաշտեր։ Այս դաշտը կարող է լինել թույլտվություն: Մեր օրերում մշակողները սիրում են բարդ հեշեր պատրաստել՝ մուտքի տվյալների բազան ծիածանի աղյուսակի հարձակումից պաշտպանելու համար: Սա լավ է, բայց նման հեշերը սպառում են 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

Բացի HTTP-ից L7-ում, մենք սիրում ենք շահագործել այլ արձանագրություններ: Որպես կանոն, սովորական կայքը, հատկապես սովորական հոսթինգը, ունի փոստի արձանագրություններ և MySQL-ն դուրս է մնում: Փոստի արձանագրությունները ենթակա են ավելի քիչ բեռնվածության, քան տվյալների շտեմարանները, բայց դրանք կարող են նաև բավականին արդյունավետ կերպով բեռնվել և ավարտվել սերվերի վրա գերբեռնված պրոցեսորով:
Մենք բավականին հաջողակ էինք՝ օգտագործելով 2016 թվականի SSH խոցելիությունը: Այժմ այս խոցելիությունը շտկվել է գրեթե բոլորի համար, բայց դա չի նշանակում, որ բեռը չի կարող ներկայացվել SSH-ին։ Կարող է. Ուղղակի թույլտվությունների հսկայական բեռ կա, SSH-ն ուտում է սերվերի գրեթե ամբողջ պրոցեսորը, այնուհետև վեբկայքը փլուզվում է վայրկյանում մեկ կամ երկու հարցումից: Համապատասխանաբար, տեղեկամատյանների վրա հիմնված այս մեկ կամ երկու հարցումները չեն կարող տարբերվել օրինական բեռից:
Շատ կապեր, որոնք մենք բացում ենք սերվերներում, նույնպես մնում են համապատասխան: Նախկինում Apache-ն մեղավոր էր դրա համար, այժմ nginx-ն իրականում մեղավոր է դրանում, քանի որ այն հաճախ կարգավորվում է լռելյայն: Կապերի քանակը, որոնք nginx-ը կարող է բաց պահել, սահմանափակ է, ուստի մենք բացում ենք այս թվով կապեր, nginx-ն այլևս չի ընդունում նոր կապ, և արդյունքում կայքը չի աշխատում։
Մեր փորձնական կլաստերն ունի բավականաչափ պրոցեսոր SSL ձեռքսեղմման վրա հարձակվելու համար: Սկզբունքորեն, ինչպես ցույց է տալիս պրակտիկան, բոտնետները երբեմն նույնպես սիրում են դա անել: Մի կողմից, պարզ է, որ դուք չեք կարող անել առանց SSL, քանի որ Google-ի արդյունքները, վարկանիշը, անվտանգությունը: Մյուս կողմից, SSL-ը, ցավոք, պրոցեսորի խնդիր ունի:

L3&4

Երբ մենք խոսում ենք L3&4 մակարդակներում հարձակման մասին, մենք սովորաբար խոսում ենք հարձակման մասին հղման մակարդակում: Նման բեռը գրեթե միշտ տարբերվում է օրինականից, եթե դա SYN-հեղեղի հարձակում չէ: Անվտանգության գործիքների համար SYN-flood հարձակումների խնդիրը դրանց մեծ ծավալն է: Առավելագույն L3&4 արժեքը եղել է 1,5-2 Թբիթ/վրկ: Նման թրաֆիկը շատ դժվար է մշակել նույնիսկ խոշոր ընկերությունների համար, ներառյալ Oracle-ը և Google-ը:
SYN-ը և SYN-ACK-ը փաթեթներ են, որոնք օգտագործվում են կապ հաստատելիս: Հետևաբար, SYN-flood-ը դժվար է տարբերակել օրինական բեռից. պարզ չէ՝ սա SYN է, որը եկել է կապ հաստատելու, թե ջրհեղեղի մաս:

UDP-ջրհեղեղ

Որպես կանոն, հարձակվողները չունեն այն հնարավորությունները, ինչ մենք ունենք, ուստի ուժեղացումը կարող է օգտագործվել հարձակումներ կազմակերպելու համար: Այսինքն՝ հարձակվողը սկանավորում է ինտերնետը և գտնում խոցելի կամ սխալ կազմաձևված սերվերներ, որոնք, օրինակ, ի պատասխան մեկ SYN փաթեթի, պատասխանում են երեք SYN-ACK-ներով։ Աղբյուրի հասցեն խաբելով թիրախային սերվերի հասցեից՝ հնարավոր է մեկ փաթեթով, ասենք, երեք անգամ մեծացնել հզորությունը և վերահղել տրաֆիկը դեպի տուժածը։

Ուժեղացման խնդիրն այն է, որ դրանք դժվար է հայտնաբերել: Վերջին օրինակները ներառում են խոցելի մեմքեշների սենսացիոն դեպքը: Բացի այդ, այժմ կան բազմաթիվ IoT սարքեր, IP տեսախցիկներ, որոնք նույնպես հիմնականում կարգավորվում են լռելյայն, իսկ լռելյայնորեն դրանք սխալ են կազմաձևված, ինչի պատճառով հարձակվողներն ամենից հաճախ հարձակումներ են կատարում նման սարքերի միջոցով:

Դժվար SYN-ջրհեղեղ

SYN-flood-ը, հավանաբար, ամենահետաքրքիր հարձակման տեսակն է մշակողի տեսանկյունից: Խնդիրն այն է, որ համակարգի ադմինիստրատորները հաճախ օգտագործում են IP արգելափակում պաշտպանության համար: Ավելին, IP-ի արգելափակումն ազդում է ոչ միայն համակարգի ադմինիստրատորների վրա, ովքեր գործում են սկրիպտների միջոցով, այլ նաև, ցավոք, անվտանգության որոշ համակարգերի վրա, որոնք ձեռք են բերվում մեծ գումարներով:
Այս մեթոդը կարող է վերածվել աղետի, քանի որ եթե հարձակվողները փոխարինեն IP հասցեները, ապա ընկերությունը կարգելափակի սեփական ենթացանցը։ Երբ Firewall-ը արգելափակում է իր սեփական կլաստերը, ելքը կխափանի արտաքին փոխազդեցությունները, իսկ ռեսուրսը կձախողվի:
Ավելին, դժվար չէ արգելափակել սեփական ցանցը։ Եթե ​​հաճախորդի գրասենյակն ունի Wi-Fi ցանց, կամ եթե ռեսուրսների արդյունավետությունը չափվում է մոնիտորինգի տարբեր համակարգերի միջոցով, ապա մենք վերցնում ենք այս մոնիտորինգի համակարգի կամ հաճախորդի գրասենյակի Wi-Fi-ի IP հասցեն և օգտագործում այն ​​որպես աղբյուր: Ի վերջո, ռեսուրսը կարծես հասանելի է, բայց թիրախային IP հասցեները արգելափակված են: Այսպիսով, HighLoad կոնֆերանսի Wi-Fi ցանցը, որտեղ ներկայացվում է ընկերության նոր արտադրանքը, կարող է արգելափակվել, ինչը ենթադրում է որոշակի բիզնես և տնտեսական ծախսեր։
Փորձարկման ընթացքում մենք չենք կարող օգտագործել ուժեղացում memcached-ի միջոցով որևէ արտաքին ռեսուրսների հետ, քանի որ պայմանավորվածություններ կան միայն թույլատրված IP հասցեներին տրաֆիկ ուղարկելու վերաբերյալ: Համապատասխանաբար, մենք օգտագործում ենք ուժեղացում SYN-ի և SYN-ACK-ի միջոցով, երբ համակարգը պատասխանում է մեկ SYN ուղարկելու երկու կամ երեք SYN-ACK-ներով, իսկ ելքում հարձակումը բազմապատկվում է երկու-երեք անգամ։

Գործիքներ

L7-ի ծանրաբեռնվածության համար օգտագործվող հիմնական գործիքներից մեկը Yandex-tank-ն է: Մասնավորապես, ֆանտոմն օգտագործվում է որպես ատրճանակ, գումարած, կան մի քանի սցենարներ փամփուշտներ ստեղծելու և արդյունքները վերլուծելու համար:
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