NGFW-ի թեստավորում. fast path, կեղծ AppMix և PCAP-replay-ի ծուղակներ
Alexander Zemskov
Սա վեցից երկրորդ մասն է այն մասին, թե ինչպես գնահատել ցանցային անվտանգության արտադրանքը։ Մաս 1-ը վերլուծեց datasheet-ների կառուցվածքային տարբերությունը, որն ընդհանուր է ողջ ոլորտի համար։
NGFW-ն կորպորատիվ անվտանգության ամենագնվող, ամենահաճախ թեստավորվող և ամենավատ գնահատվող կատեգորիան է։ Թեստավորման ծուղակներն այստեղ լավ հայտնի են ոլորտի ներսում և կայունորեն անհայտ նրանց, ովքեր որոշում են գնման մասին։
Fast path․ ֆունկցիա, որը թեստում դառնում է ծուղակ
Կորպորատիվ NGFW-ների մեծ մասն ունի սեփական ASIC-ներ կամ անվտանգության առանձնացված պրոցեսորներ։ Այս չիպերը տրաֆիկի մի մասը տանում են ապարատային fast path՝ ծրագրային ստեկը շրջանցելով։ Սա օրինական և օգտակար ճարտարապետական հատկություն է։ Ճիշտ պայմաններում այն տալիս է արտադրողականության իրական աճ՝ իսկական inspection-ով։
Ամբողջ բանը «ճիշտ պայմաններում» բառերի մեջ է։
Fast path-ն աշխատում է լավագույնս, երբ տրաֆիկը միատեսակ է, կանխատեսելի և պարզ՝ երկար սեսիաներ խոշոր payload-ով, նոր միացումների հավասար տեմպ, բաց կամ հեշտ դասակարգվող պրոտոկոլներ։ Այդ պայմաններում ASIC-ը վերցնում է հիմնական աշխատանքը, ծրագրային ստեկը գրեթե պարապ է, throughput-ը մոտենում է սարքի տեսական սահմանին։
Իրական կորպորատիվ տրաֆիկն այլ կերպ է կառուցված՝ կարճ սեսիաներ, շատ մանր օբյեկտներ, TLS 1.3 շիֆրված SNI-ով և ESNI-ով, ոչ ստանդարտ պորտեր, հավելվածների սեփական պրոտոկոլներ, նոր միացումների պոռթկումներ։ Այդ տրաֆիկի վրա fast path-ի ծածկույթը կտրուկ ընկնում է, և հիմնական ծանրաբեռնվածությունը կրում է ծրագրային ստեկը։
Վատ նախագծված թեստը՝ կամ հարմար արդյունքի տակ նախագծված թեստը՝ քշում է տրաֆիկն առաջին սցենարով։ Սարքը ցույց է տալիս գերազանց թվեր։ Պրոդում այդ թվերը չեն ապրում։
Վենդորական թեստային ռեժիմներ․ օպտիմիզացիա, որի մասին չեն հայտարարում
Fast path-ի ազնիվ պահվածքից բացի կա ավելի միտումնավոր օպտիմիզացիաների կատեգորիա։
Վենդորները գիտեն, թե ինչ գեներատորներով են սովորաբար թեստավորում անվտանգության արտադրանքը։ Գիտեն պրոֆիլները, փաթերները, գնահատումների տիպային PCAP ֆայլերը։ Որոշ պլատֆորմներ իրականացնում են օպտիմիզացիաներ, որոնք գործում են հենց այս հայտնի պրոֆիլների վրա՝ DPI-ի արդյունքի քեշավորում այն սեսիաների համար, որոնք բայթ առ բայթ համընկնում են արդեն տեսածի հետ; կրճատ վերլուծություն payload-ի ճշգրիտ փաթերների համար տարածված թեստային հավաքածուներից; fast path-ի կանոններ՝ կապված կոնկրետ գեներատորների առանձնահատկություններին։
Այս օպտիմիզացիաները տալիս են տպավորիչ թվեր բենչմարքի վրա։ Իրական բազմազան տրաֆիկի վրա դրանցից օգուտը քիչ է կամ չկա, իսկ երբեմն դրանք ավելացնում են պահվածքի տարբերություններ, որոնք դուրս են գալիս միայն իրատեսական ծանրաբեռնվածության տակ։
Եզրակացությունը պարզ է․ սարքը, որը լավ աշխատեց ծանոթ գործիքի վրա, կարող է նույն արդյունքը չտալ մեթոդիկայի վրա, որին այն չեն պատրաստել։ Սա տեսնելը հնարավոր է միայն անկախ թեստով, այն գործիքով, որը վենդորը չի կարող նախապես ուսումնասիրել։
AppMix-ի խնդիրը․ ձեր սահմանած բաշխումը այն չէ, ինչ անցել է սարքով
Սա NGFW-ի թեստավորման ամենանուրբ տեխնիկական խնդիրն է և ամենահաճախ բաց թողնվողը։
Դուք սահմանում եք թեստ հավելվածների նպատակային միքսով՝ ասենք 25% HTTPS, 20% HTTP, 15% DNS, 15% SMTP, 10% վիդեո, 10% ԲԴ, 5% custom՝ և սպասում եք, որ հենց այս բաշխումը կանցնի սարքով։ Այն չի անցնում։
Անվճար և open-source գեներատորները նոր սեսիաներ են պլանավորում ըստ սահմանված կշիռների։ Դրանք հաշվի չեն առնում, թե պրոտոկոլի ամեն տիպ որքան ժամանակ է մշակվում DUT-ի վրա։ Անվտանգության միջոցներով մշակումը պրոտոկոլների կտրվածքով անհավասար է։
Ծանր պրոտոկոլները՝ TLS փոխադարձ նույնականացմամբ, SMTP խոշոր կցորդներով, երկար DPI դասակարգմամբ պրոտոկոլներ՝ ծախսում են ավելի շատ ժամանակ մեկ սեսիայի վրա DUT-ի վրա։ Դրանք հերթ են կանգնում։ Դանդաղում են։ Գեներատորը դա չգիտի և շարունակում է նոր սեսիաներ գործարկել սահմանված հաճախականությամբ։ Թեթև պրոտոկոլները՝ սովորական HTTP, DNS հարցումներ, մանր UDP՝ մշակվում են արագ և անցնում սարքով լրիվ արագությամբ։
Արդյունքը․ թեստի ընթացքում իրական միքսը DUT-ի վրա շեղվում է դեպի ամենաթեթև, արագ պրոտոկոլները։ Սարքը կարծես պահում է 10 Gbps լրիվ inspection-ով։ Այն իսկապես պահում է 10 Gbps, բայց դրա 60%-ը սովորական HTTP և DNS է, որովհետև ձեր սահմանած SMTP և TLS սեսիաները կանգնած են հերթերում կամ դեն նետվում։
Throughput-ի թիվն իսկական է։ Տրաֆիկի պրոֆիլը, որի վրա այն չափվել է, այն չէ, ինչ դուք էիք ուզում։
Ինչու առանց AppMix-ի վերահսկման վենդորների համեմատությունն անիմաստ է։ A սարքը ծանր պրոտոկոլներն արդյունավետ է մշակում․ TLS-ը և բարդ DPI-ն գնում են չափավոր overhead-ով։ Ձեր թեստում A սարքի իրական AppMix-ը մոտ է սահմանվածին։ B սարքն ավելի արագ է դեն նետում ծանր սեսիաները․ overhead-ը չափազանց բարձր է, միացումներն ընկնում են ըստ timeout-ի։ B սարքի իրական AppMix-ը հիմնականում թեթև տրաֆիկ է։ B սարքը ցույց է տալիս ավելի բարձր throughput։
Դուք եզրակացնում եք, որ B սարքն ավելի արտադրողական է, քան A-ն։ Դուք դրանք չափում եք տարբեր քանոններով և չգիտեք դա։
PCAP-replay․ գործիք, որը վենդորին ասում է, թե ինչ է գալու
TRex-ը և Չինաստանից շատ թեստային գործիքներ օգտագործում են PCAP-replay ռեժիմ՝ վերարտադրում են նախապես գրանցված տրաֆիկը։ L7-ի ամեն սեսիա բայթ առ բայթ համընկնում է նույն տիպի ցանկացած այլ սեսիայի հետ։ Նույն վերնագրերը։ Նույն payload-ը։ Նույն հերթականության համարները, նույն SNI-ն, նույն URI փաթերները՝ կրկնվում են անվերջ։
Վենդորը, որ թեստավորում է ձեր արտադրանքը, գիտի, թե ինչ գործիքներով են աշխատում գնորդները։ Գիտի PCAP ֆայլերը։ Գիտի payload-ի փաթերները։ Դրանց տակ օպտիմիզացնելը ոչինչ չարժե։
Ինչ կոնկրետ է աշխատում դետերմինիստական PCAP-replay-ի դեմ․
- DPI-ի արդյունքի քեշավորում։ Եթե երկու TCP սեսիա ունեն նույն payload-ը, երկրորդը դասակարգվում է ակնթարթորեն քեշից՝ լրիվ DPI-ի փոխարեն։ Replay-ի վրա throughput-ը կտրուկ բարձր է, իրական բազմազան սեսիաների վրա շահույթը գրեթե զրո։
- Fast path-ի կանոններ հայտնի փաթերների տակ։ Թեստային PCAP-ից հայտնի ճշգրիտ փաթերի հետ համընկած սեսիան ուղարկվում է fast path՝ նվազագույն inspection-ից հետո։ Փոփոխվող payload-ով սեսիաներին սա կիրառելի չէ։
- Կրճատ վերլուծություն։ Որոշ DPI շարժիչներ օգտագործում են կրճատումներ payload-ի փաթերների համար, որոնք հաճախ են հանդիպում թեստային տրաֆիկում։ Հավելվածների նոր տվյալների վրա այս կրճատումները չեն աշխատում։
Անվճար գործիքների օգտին փաստարկը գինն է։ Ազնիվ հաշվարկը ներառում է․ ինժեներական ժամանակ ստենդի հավաքման վրա, ժամանակ մասշտաբավորման սահմանափակումների շրջանցման վրա, ժամանակ մեթոդիկայի նախագծման վրա՝ գումարած բազմամյա գնման որոշման արժեքը այն արդյունքներով, որոնց տակ վենդորը պատրաստվել է։ Սա էժան թեստ չէ։
Ինչ տեսք ունի NGFW-ի լավ թեստը
Լավ և վատ թեստի տարբերությունը հանգում է երեք կառավարելի փոփոխականի։
Տրաֆիկի դինամիկ գեներացիա։ Ամեն սեսիա գեներացվում է ընթացքում՝ եզակի վերնագրեր, token-ներ, payload L7-ի վրա։ Նույն տիպի երկու սեսիա չպետք է համընկնեն բայթ առ բայթ։ Սա անջատում է քեշի վրա օպտիմիզացիաները և ստիպում սարքին ամեն հոսք դասակարգել զրոյից, ինչպես կանի պրոդում։
AppMix-ի վերահսկում փակ ցիկլով։ Գեներատորը չափում է հավելվածների իրական միքսը DUT-ի վրա և վերադարձնում սեսիաների պլանավորման մեջ։ Եթե չափված միքսը հեռանում է նպատակայինից, կշիռները ճշգրտվում են ընթացքում։ Առանց դրա դուք հաշվետվում եք սահմանված միքսի մասին, ոչ թե չափվածի, և դրանք տարբեր թվեր են։
Պաշտպանության արդյունավետությունը ծանրաբեռնվածության տակ։ Հարձակումները մատուցվում են ֆոնային տրաֆիկի հոսքի ներսում, իրատեսական ծանրաբեռնվածության մակարդակով՝ ոչ առանձին, պարապ սարքի վրա։ Սարքը, որը 5% ծանրաբեռնվածության դեպքում արգելափակում է հարձակումների 99%-ը, իսկ 80%-ի դեպքում՝ 70%-ը, տալիս է բոլորովին այլ պաշտպանության մակարդակ, քան ասում է դետեկտի վերնագրային թիվը։
Սրանք էկզոտիկ պահանջներ չեն։ Սա ենթակառուցվածքի որակավորման ստանդարտ պրակտիկա է խոշոր օպերատորների և ֆինանսական կազմակերպությունների մոտ։ Այս ամենը հասանելի է ճիշտ գործիքների և մեթոդիկայի դեպքում։
Հաջորդը շարքում՝ Գրառում 3՝ WAF, IPS և DLP։ Ինչու է բովանդակության inspection-ի թեստավորումն ավելի դժվար, քան թվում է, և ինչպես է շրջանցման ծածկույթն առանձնացնում այն արտադրանքը, որը ձեզ պաշտպանում է, նրանից, որը պաշտպանում է ձեզ demo-ում։
TEST4NET LLC-ն ցանցերի և անվտանգության թեստավորման անկախ լաբորատորիա է՝ առանց կոմերցիոն կապերի անվտանգության վենդորների հետ։ Գրեք մեզ՝ ձեր NGFW-ի գնահատումը քննարկելու համար։
