Skip to content

Մեթոդաբանություն · Անվտանգության սարքեր

RFC 9411. firewall-ի թեստ՝ բոլոր գործառույթները միացրած

RFC 9411-ը 2023-ին փոխարինեց RFC 3511-ին։ Այն firewall-ը չափում է այնպես, ինչպես դուք այն շահագործում եք՝ inline ռեժիմում, միացված TLS inspection-ով և IPS-ով, իրական HTTP և HTTPS տրաֆիկով, 100 000 գործարքից 1 սխալի բյուջեով։ Այս էջում՝ ինչպես ենք մենք անցկացնում թեստը CloudLAB-ում և ինչ եք ստանում հաշվետվությունում։

  • 9 բենչմարք թեստ՝ 5-ը HTTP-ով, 4-ը HTTPS-ով՝ խորհուրդ տրվող cipher suite-երով
  • Sustain փուլ՝ 300 վ յուրաքանչյուր գործարկման համար, KPI-ները գրանցվում են առնվազն 2 վ-ը մեկ
  • Արդյունքը հաշվվում է միայն, եթե ձախողված գործարքները և անսպասելի RST-ները 0,001 %-ից քիչ են
Ստանալ NGFW թեստ-պլան Դեպի 9 թեստերը
OFFERED LOAD TRAFFIC LOAD PROFILE · RFC 9411 §4.3.4 TARGET OBJECTIVE 10% · QUALIFICATION KPIs MEASURED HERE SAMPLE INTERVAL UNDER 2 s INIT ≥ 5 s RAMP UP SUSTAIN ≥ 300 s RAMP DOWN COLLECT Հաշվետվության մեջ մտնում է միայն sustain փուլը

RFC 9411-ի յուրաքանչյուր գործարկում անցնում է այս պրոֆիլով։ Չափումները միայն sustain փուլում են՝ առնվազն 300 վ, բոլոր KPI-ները գրանցվում են այնտեղ և ոչ մի այլ տեղ։

Ո՞ր RFC-ն

Մեթոդը մեկն է՝ RFC 9411։ RFC 3511-ը մնացել է պատմության մեջ։

RFC 3511-ը 2003 թվականից է և firewall-ը չափում էր որպես փաթեթային ֆիլտր՝ IP throughput, կապերի արագություն, կանոնների հավաքածու։ 2023-ին RFC 9411-ը այն հնացած դարձրեց։ Այս էջում ամեն ինչ RFC 9411-ի մասին է. 3511-ը հիշատակվում է միայն, երբ տենդերը դեռ մեջբերում է այն։

Inspected throughput

KPI-ն հաշվում է այն բիթերը, որոնք ստուգվել, թույլատրվել և հասցվել են, մինչ DUT-ը ստուգում է տրաֆիկը։ Լռելյայն L2 մակարդակում. եթե չափում եք L3-ում, հաշվետվությունը պարտավոր է դա նշել, քանի որ թվերը համեմատելի չեն։

Մեկ կոնֆիգուրացիա բոլոր 9 թեստերի համար

DUT-ի կոնֆիգուրացիան ամրագրվում է առաջին թեստից առաջ և չի փոխվում մինչև վերջինը։ Յուրաքանչյուր անջատված խորհուրդ տրվող գործառույթ մտնում է հաշվետվություն՝ պատճառի և արտադրողականության վրա ազդեցության հետ միասին։

Վատագույն դեպքը՝ միտումնավոր

Ամբողջական TLS handshake յուրաքանչյուր կապի վրա, session resumption-ն անջատված, PSH՝ ամբողջ տրաֆիկի վրա։ Մեթոդը փնտրում է սարքի ստորին սահմանը՝ այն թիվը, որը ձեր օգտատերերը կստանան վատ օրը։

Անվճար ներբեռնում

RFC 9411 թեստային պլանի ձևանմուշ

Պլանը, որը լրացնում ենք միջցանցային էկրանի և NGFW-ի յուրաքանչյուր թեստից առաջ, PDF ձևաչափով՝ սարքի դասը և կանոնների ցուցակը, միացվող պաշտպանական գործառույթները, 9 թեստերը օբյեկտների չափերով և գաղտնագրման հավաքածուներով, վավերացման չափանիշները և արդյունքների թերթ

  • Պատրաստ է կցելու մրցույթի կամ առաջարկի հարցման
  • Նույն պարամետրերն ու չափանիշները բոլոր վենդորների և լաբորատորիաների համար
  • Վերջում թվարկված են արդյունքը փոխող սխալները

PDF անգլերենով։ Պետք է միայն էլ․ փոստը։

Թեստային ստենդ

Տրաֆիկի գեներատորի երկու կեսը և մեկ արկղ նրանց միջև

RFC-ի տարբերակ 1՝ էմուլացված կլիենտները մի կողմում, էմուլացված սերվերները մյուսում, DUT-ը inline։ Ոչ մի արտաքին սվիչ կամ երթուղիչ, եթե պորտերի քանակը դա չի պարտադրում. դրանք ավելացնում են սեփական ուշացումը և փոքրացնում ARP աղյուսակը, որի հետ DUT-ը պետք է գլուխ հանի։

TEST EQUIPMENT · CLIENTS EMULATED ROUTER (OPTIONAL) EMULATED BROWSERS HTTP/1.1 · HTTP/2 · HTTP/3 over QUIC TLS 1.2 / 1.3, full handshake, no resumption MSS 1460 · window 65535 · cwnd ≤ 10 MSS Source ports 1024–65535, PSH on 1,400–1,700 CLIENT IPs PER 10 Gbit/s GET · TLS DUT / SUT INLINE · FAIL-OPEN OFF · FLOW LOGGING ON One configuration for all 9 tests ACL set sized by class XS / S / M / L NGFW · NGIPS · PHYSICAL OR VNF TLS INSPECTION IDS/IPS ANTI-VIRUS ANTI-SPYWARE GEO ANTI-BOTNET ANTI-EVASION APP-ID LOGGING 200 OK TEST EQUIPMENT · SERVERS EMULATED ROUTER (OPTIONAL) EMULATED SERVER POOL HTTP on :80, HTTPS on :443, HTTP/3 on UDP TLS 1.2 or newer, 16 KB records No session tickets, no session cache One IP per FQDN per test port IPv4 / IPv6 SPLIT MIRRORS THE CLIENTS REFERENCE PRE-TEST FIRST նույն ստենդը, DUT-ի փոխարեն patch cord կամ fast-forward ռեժիմ · կորուստները, ուշացումը և գեներատորի պաշարը գրանցվում են մինչև DUT-ի միացումը

Էմուլացված կլիենտներ

MSS 1460 (IPv4) և 1440 (IPv6), 65 535 բայթ պատուհան, սկզբնական congestion window՝ մինչև 10 MSS, 3 կրկնություն, աղբյուրի պորտեր՝ 1024–65535։ Կլիենտների թիվը որոշվում է նպատակով՝ մոտ 1 400–1 700 IP 10 Gbit/s-ի համար ձեռնարկության պերիմետրում, 50 000–100 000՝ բաժանորդային պրոֆիլի համար։

DUT / SUT

Inline, fail-open-ն անջատված, խորհուրդ տրվող գործառույթները միացված, հոսքերի լոգավորումը միացված, գեոֆիլտրում՝ որտեղ սարքն այն աջակցում է։ ACL հավաքածուն որոշվում է դասով՝ 5 կանոն հավելվածներով և 50 արգելափակում IP-ով ու պորտերով XS-ի համար մինչև 50 և 500՝ L-ի համար։ Սկզբում արգելող կանոնները, թույլատրողները՝ վերջում, և դրանցից ոչ մեկը չի առնչվում թեստային տրաֆիկին։

Էմուլացված սերվերներ

HTTP/1.1 և HTTP/2՝ 80 և 443 պորտերում, HTTP/3՝ UDP-ով։ TLS 1.2 կամ ավելի նոր, 16 KB record սահման, առանց session ticket-ների և session cache-ի, մեկ IP սերվերի FQDN-ի համար յուրաքանչյուր թեստային պորտում։ IPv4-ի և IPv6-ի հարաբերակցությունը կրկնում է կլիենտների կողմը։

Մինչև DUT-ի միացումը՝ reference pre-test

Ամենափոքր օբյեկտով HTTP պրոֆիլն անցկացնում ենք patch cord-ով (կամ DUT-ով fast-forward ռեժիմում), գրանցում ենք բուն ստենդի կորուստներն ու ուշացումը և համոզվում, որ գեներատորը պաշարով գերազանցում է DUT-ի հայտարարված արտադրողականությունը։ Եթե ստենդը չի գերազանցում datasheet-ը, DUT-ի արդյունքն իմաստ չունի։ Վիրտուալ ստենդներին լրացուցիչ հետևում ենք՝ աղմկոտ հարևաններ, VM-ների տեղափոխում և ջերմային throttling 300 վ-ի ընթացքում։

DUT/SUT կոնֆիգուրացիա

Ինչ պետք է միացված լինի առաջին փաթեթից առաջ

RFC-ի բաժին 4.2։ Ստորև ցանկը NGFW-ի համար է. NGIPS-ի համար այն ավելի կարճ է (առանց հակավիրուսի և ACL-ի), բայց DPI-ով և anti-malware-ով։ Մեքենայական ուսուցման և վարքային վերլուծության շարժիչներն անջատվում են՝ մեթոդը չի կարող դրանք վերարտադրել։

Խորհուրդ տրվող՝ միացված յուրաքանչյուր թեստում

  • TLS Inspection
  • IDS / IPS
  • Anti-Virus
  • Anti-Spyware
  • Anti-Botnet
  • Anti-Evasion
  • Application Identification

Դրանցից որևէ մեկն անջատել կարելի է, եթե ներդրմանը դա պետք չէ։ Այդ դեպքում հաշվետվությունը նշում է՝ որը, ինչու, և որ միացված գործառույթով արդյունքն ավելի ցածր կլիներ։ Application identification-ը պետք է կարգավորված լինի տրաֆիկի պրոֆիլի հավելվածները ճանաչելու համար։

Ընտրովի՝ ըստ ներդրման

  • Web Filtering
  • Data Loss Protection
  • DDoS Protection
  • Certificate Validation

Միացնում ենք, եթե ձեր քաղաքականությունը դրանք օգտագործում է արտադրության մեջ։ Սովորաբար թեստավորում ենք երկու ռեժիմով, երբ գործառույթներից մեկը ընտրության չափանիշ է, հատկապես DDoS-ից պաշտպանությունը։

Մուտքի ցանկ ըստ սարքի դասի (RFC-ի Table 4)

Դասը որոշվում է վաճառողի datasheet-ի throughput-ով։ Կանոնները գնում են այս հերթականությամբ՝ կոնկրետ արգելքները վերևում, և դրանցից ոչ մեկը չպետք է համընկնի թեստային տրաֆիկի հետ։

Կանոն XS
≤ 1 Gbit/s		 S
1–5 Gbit/s		 M
5–10 Gbit/s		 L
> 10 Gbit/s
Արգելափակում ըստ հավելվածի (տրաֆիկի պրոֆիլում բացակայող հավելվածներ)5102050
Արգելափակում ըստ աղբյուրի IP-ի և նպատակակետի պորտի (թեստում չօգտագործվող պորտեր)2550100250
Արգելափակում ըստ աղբյուրի և նպատակակետի ենթացանցի (թեստում չօգտագործվող ենթացանցեր)2550100250
Թույլտվություն ըստ հավելվածի (պրոֆիլի հավելվածների կեսը)10101010
Թույլտվություն ըստ կլիենտի ենթացանցի և պորտի, ապա ըստ կլիենտի ենթացանցիառնվազն 1 կանոն յուրաքանչյուր կլիենտային ենթացանցի համար, երկու տիպի կանոններում

Դասեր՝ XS մինչև 1 Gbit/s, S՝ 1-ից 5 Gbit/s, M՝ 5-ից 10 Gbit/s, L՝ 10 Gbit/s-ից բարձր (Appendix B)։ Ձեր կանոնների թիվը կարող է ավելի մեծ լինել. RFC-ն սահմանում է նվազագույնը։ Եթե սարքը կառուցված է առանց ACL-ի (NGIPS-ների մեծ մասը), թեստավորում ենք առանց դրանց և նշում ենք հաշվետվությունում։

RFC-ի բաժին 7

9 թեստ՝ յուրաքանչյուրն իր նպատակով և իր դարպասով

5-ը գնում են բաց HTTP-ով, 4-ը կրկնում են սխեման HTTPS-ով՝ խորհուրդ տրվող cipher suite-երով։ Յուրաքանչյուր թեստ սկսվում է նպատակի 10 %-ից, ապա գնում է նպատակի վրա, ապա իտերացիաներով փնտրում է առավելագույն բեռնվածությունը, որը դեռ անցնում է վավերացման չափանիշները։

  1. 7.1Հավելվածների պրոֆիլ

    Throughput հավելվածային տրաֆիկի պրոֆիլով

    Inspected throughput և գործարքներ վայրկյանում իրատեսական պրոֆիլով՝ օրինակ NetSecOPEN enterprise perimeter կամ ձեր պերիմետրի ձայնագրություն։ Ամենամոտը աշխատանքային օրվան, ինչ կարելի է տեղավորել մեկ թվի մեջ։

    Նպատակ՝ DUT-ի պորտերի line rate կամ ձեր ներդրման թիվը · TTLB-ն զեկուցվում է պրոֆիլի օբյեկտների չափերով
  2. 7.2HTTP

    TCP կապեր վայրկյանում

    Մեկ GET յուրաքանչյուր կապի վրա, անմիջապես FIN։ Ցույց է տալիս, թե որքան արագ են սեսիաների աղյուսակը, քաղաքականության որոնումը և լոգավորման հոսքագիծն ընդունում նոր հոսքերը։ Փոքր օբյեկտները բեռնում են control path-ը, 64 KB-ի վրա պատկերի մեջ մտնում է throughput-ը։

    Օբյեկտներ՝ 1, 2, 4, 16 և 64 KB, մեկ չափ յուրաքանչյուր իտերացիայի համար · նպատակ՝ datasheet-ի CPS կամ ձերը
  3. 7.3HTTP

    HTTP throughput

    Կայուն inspected throughput օբյեկտի տարբեր չափերի դեպքում։ Փոքր օբյեկտները ցույց են տալիս ստուգման շարժիչների գինը մեկ հարցման համար. 256 KB-ը ցույց է տալիս, թե ինչ է քաշում data path-ը, երբ շարժիչները գրեթե անելիք չունեն։

    Օբյեկտներ՝ 1, 16, 64, 256 KB գումարած խառը հավաքածու 0,2 KB-ից · throughput և գործարքներ/վ յուրաքանչյուր չափի համար
  4. 7.4HTTP

    HTTP գործարքի ուշացում

    Time to first byte և time to last byte, մինչ սարքն աշխատում է 7.2 և 7.3 թեստերի գտածի կեսով։ Ուշացումը 50 % բեռնվածության դեպքում այն թիվն է, որը զգում են օգտատերերը. ուշացումը պարապ վիճակում՝ datasheet-ի թիվը։

    TTFB և TTLB min / avg / max · 1 և 10 գործարք յուրաքանչյուր կապի վրա · օբյեկտներ 1, 16 և 64 KB
  5. 7.5HTTP

    Միաժամանակյա TCP կապերի տարողունակություն

    Քանի սեսիա է DUT-ը միաժամանակ բաց պահում՝ ոչինչ չգցելով և չընդհատելով։ Ramp-up-ը գնում է 7.2-ի CPS տեմպով, որպեսզի սահմանին բախվի հենց սեսիաների քանակը։

    Ramp-up ժամանակ = նպատակային կապերի թիվ ÷ առավելագույն CPS · sustain-ը ստուգում է, որ թիվը մնա 10 %-ի սահմաններում
  6. 7.6HTTPS · TLS inspection-ով

    TCP կամ QUIC կապեր վայրկյանում, HTTPS

    7.2 թեստը՝ ամբողջական TLS handshake-ով յուրաքանչյուր կապի վրա և մեջտեղում վերծանող DUT-ով։ Անցկացվում է յուրաքանչյուր cipher suite-ի և բանալու երկարության համար. RSA 4096-ը P-384-ով ամենաշատն է հարվածում proxy ռեժիմի ստուգմանը։

    Օբյեկտներ՝ 1, 2, 4, 16 և 64 KB · TLS handshake-ի արագությունը չափվում է 1 KB օբյեկտի վրա
  7. 7.7HTTPS · TLS inspection-ով

    HTTPS throughput

    7.3 թեստը TLS-ի վրայով։ Հենց այս թիվն են դնում datasheet-ի կողքին՝ վերծանել, ստուգել, նորից գաղտնագրել 64 KB օբյեկտների վրա՝ միացված IPS-ով և application identification-ով։

    Իտերացիաները ծածկում են ECDHE-ն AES-128-GCM-ով և AES-256-GCM-ով, RSA 2048 և 4096, P-256 և P-384
  8. 7.8HTTPS · TLS inspection-ով

    HTTPS գործարքի ուշացում

    TTFB և TTLB, մինչ TLS proxy-ն անում է իր գործը 50 % բեռնվածության դեպքում։ Ամենաշատը կտեղաշարժվի TTFB-ն՝ handshake-ն այժմ տեղի է ունենում երկու անգամ՝ մինչև DUT-ը և դրանից հետո։

    Նույն սցենարները, ինչ 7.4-ում · min / avg / max յուրաքանչյուր օբյեկտի չափի և cipher suite-ի համար
  9. 7.9HTTPS · TLS inspection-ով

    Միաժամանակյա TCP կամ QUIC կապերի տարողունակություն, HTTPS

    Միաժամանակ պահվող բաց TLS սեսիաներ։ TLS 1.3-ի դեպքում DUT-ն աշխատում է որպես middlebox, որը պահում է վկայագրերն ու բանալիները, այնպես որ սահմանին են բախվում և՛ սեսիաների աղյուսակը, և՛ բանալիների նյութը։

    Ramp-up 7.6-ի HTTPS CPS տեմպով · շեղում 10 %-ից քիչ sustain-ի ընթացքում

Ընթացակարգ

Յուրաքանչյուր թեստ առաստաղ է փնտրում, և ամեն քայլին դարպաս է կանգնած

RFC-ն թույլ չի տալիս զեկուցել թիվ, որի ճանապարհին ինչ-որ բան կոտրվել է։ 4 քայլ, խստորեն այս հերթականությամբ, 9 թեստերից յուրաքանչյուրի և օբյեկտի յուրաքանչյուր չափի համար։

  1. 00

    Reference pre-test

    Ստենդն առանց DUT-ի։ Գրանցում ենք կորուստները, ուշացումը և գեներատորի պաշարը։ Կրկնում ենք, եթե նախագծի ընթացքում ստենդում ինչ-որ բան փոխվում է։

  2. 01

    Որակավորում 10 %-ի վրա

    Սկզբնական նպատակը՝ նպատակայինի 10 %-ը։ Բոլոր KPI-ները պետք է անցնեն չափանիշները այս թեթև բեռնվածության դեպքում, հակառակ դեպքում թեստն այստեղ կանգ է առնում, և մենք գնում ենք կոնֆիգուրացիան պարզելու։

  3. 02

    Գործարկում նպատակի վրա

    Բեռնվածության ամբողջական պրոֆիլը նպատակային արժեքի վրա՝ datasheet-ի թիվ, line rate կամ ձեր պահանջը։ Անցա՞ք չափանիշների սահմաններում։ Դա էլ արդյունքն է։

  4. 03

    Իտերացիա դեպի առավելագույն

    Չհասա՞ք նպատակին կամ խախտեցի՞ք չափանիշը։ Քայլ ներքև և կրկնություն, մինչև գտնվի առավելագույն բեռնվածությունը, որն անցնում է։ Վերջնական իտերացիան գնում է ամբողջ 300 վ sustain։

Վավերացման դարպասը՝ վերահսկվում է ամբողջ sustain փուլի ընթացքում

  • 0,001 %

    Ձախողված գործարքների առավելագույն բաժինը՝ ամեն ինչ, ինչ 200 OK չէ, բոլոր փորձերից։ 1-ը 100 000-ից։

  • 0,001 %

    DUT-ի անսպասելի RST-ով ընդհատված կապերի առավելագույն բաժինը։ Firewall-ը, որը բեռնվածության տակ սեսիաներ է գցում, գործարկումը չի անցնում։

  • 5 %

    Փոխանցման արագության առավելագույն շեղումը sustain-ի ընթացքում։ Տրաֆիկը պետք է գնա հավասար, առանց սղոցաձև թռիչքների։

  • 10 %

    Միաժամանակյա կապերի թվի առավելագույն շեղումը կայուն ռեժիմում։ Հաստատում է, որ DUT-ը սեսիաները բացում և փակում է նույն տեմպով։

Բեռնվածության պրոֆիլը յուրաքանչյուր գործարկման հետևում

  • Init, 5 վ-իցARP/ND և MAC ուսուցում։ Կլիենտները լռում են, սերվերները պատրաստ են։ Առանց չափումների։
  • Ramp up0-ից մինչև նպատակային արժեք, բավական դանդաղ, որպեսզի գեներատորը չգերազանցի DUT-ի սեփական CPS և throughput սահմանները։ Առանց չափումների։
  • Sustain, 300 վ-իցՀաստատուն բեռնվածություն, հաստատուն կլիենտների թիվ։ Միակ փուլը, որը չափվում է՝ բոլոր KPI-ները գրվում են անընդհատ, նմուշառման միջակայքը 2 վ-ից քիչ։
  • Ramp down և collectionՏրաֆիկը հետ՝ 0-ի, ապա գեներատորը հաշվիչներն ու վիճակագրությունը հավաքում է հաշվետվության տվյալների մեջ։ Առանց չափումների։

Արդյունք

Ինչ է դրվում ձեր սեղանին

RFC-ի բաժին 6-ը նկարագրում է հաշվետվությունը։ Մերը հետևում է դրան և ավելացնում հումքը, որպեսզի աուդիտորը, վաճառողի ինժեները կամ ձեր թիմը վերստուգեն յուրաքանչյուր թիվ՝ առանց մեզ զանգելու։

Բենչմարքներ յուրաքանչյուր թեստի համար

  • Inspected throughput Gbit/s-ով 2 նիշով, փակագծերում kbit/s
  • TCP կամ QUIC կապեր վայրկյանում՝ օբյեկտի յուրաքանչյուր չափի համար
  • Հավելվածային գործարքներ վայրկյանում (միայն 200 OK)
  • TLS handshake-ի արագություն ըստ cipher suite-երի և բանալու երկարության
  • Պահվող միաժամանակյա TCP կամ QUIC կապեր
  • TTFB և TTLB՝ նվազագույն, միջին, առավելագույն, օբյեկտի յուրաքանչյուր չափի համար

Համատեքստ, որը թվերը դարձնում է համեմատելի

  • DUT-ի արտադրող, մոդել, firmware, պորտերի արագություններ. VNF-ի համար՝ միջուկներ, RAM, DPDK կամ SR-IOV, pinning, NUMA, հիպերվիզոր
  • Յուրաքանչյուր միացված գործառույթ և պատճառը՝ յուրաքանչյուր անջատված խորհուրդ տրվողի համար
  • Գեներատորի մոդել, ծրագրային ապահովման տարբերակ, TCP և TLS պարամետրեր, cipher suite-եր
  • Տրաֆիկի պրոֆիլ, IPv4-ի և IPv6-ի հարաբերակցություն, կլիենտների և սերվերների հասցեների միջակայքեր, թվարկման մեթոդ
  • Reference pre-test-ի արդյունքներ՝ բուն ստենդի կորուստներն ու ուշացումը
  • Յուրաքանչյուր գործարկման ժամանակն ու ամսաթիվը՝ ըստ փուլերի
RFC 9411 · TEST REPORT SUSTAIN 300 s · IPv4 100% 7.1Throughput, app mix 7.2TCP CPS, 1 KB object 7.4TTLB, 64 KB object 7.6HTTPS CPS, ECDHE-RSA 2048 7.7HTTPS throughput, 64 KB 7.9HTTPS concurrent capacity 6.20 Gbit/s 48,000 /s 41 ms avg 9,800 /s 5.40 Gbit/s 1.8 M transactions 5,900 /s · TTLB with mix object sizes failed 0.0003% · RST 0.0001% · rate dev 1.2% TTFB 9 / 12 / 31 ms · 10 transactions per connection TLS handshakes 9,800 /s · full handshake, no resumption AES-128-GCM · P-256 · inspection on RST 0.004% at 2.0 M: criterion b failed, 1.8 M reported ATTACHED DUT CONFIG EXPORT FEATURES + REASONS PRE-TEST RESULTS RAW COUNTERS · PCAP Արժեքները պատկերային են։ Ձեր հաշվետվությունում ձեր թվերն են՝ օբյեկտի յուրաքանչյուր չափի և cipher suite-ի համար։

Մեզանից՝ RFC-ից բացի

  • Հում հաշվիչներ և pcap յուրաքանչյուր իտերացիայից, որպեսզի թվերը հնարավոր լինի նորից ստանալ
  • DUT-ի կոնֆիգուրացիայի արտահանում այն տեսքով, ինչպես թեստավորվել է, ACL հավաքածուի հետ
  • 1 էջանոց առաջարկություն՝ որ սարքը, որ բեռնվածության վրա, ինչը միացրած

Պրակտիկայից

40 Gbit/s datasheet-ում։ Ո՞ր մեթոդով է դա ստացվել։

NGFW-ների մեծ մասի վերնագրային թիվը վերցվում է RFC 3511-ի ոգով գործարկումից՝ մեծ IP փաթեթներ, մի բուռ սեսիա, ստուգումն անջատված։ Անցկացրեք նույն սարքը RFC 9411-ով՝ միացված TLS inspection-ով, IPS-ով և application identification-ով, 64 KB HTTPS օբյեկտներով և ամբողջական handshake-ով յուրաքանչյուր կապի վրա, և inspected throughput-ը կհայտնվի 6 Gbit/s-ի վրա։ Սարքը մի քանոնով չափեց 40, մյուսով՝ 6։

Գնեք 40-ի հաշվով, և պերիմետրը կլինի անհրաժեշտից 6–7 անգամ փոքր։ Մենք տեսել ենք, թե ինչ է լինում հետո՝ առաջին վթարը, և ինժեները լուռ անջատում է ստուգումը, որ այն անցնի։ Պատվերը ստորագրված է, պաշտպանությունը կիսով չափ անհետացել է, և դա ոչ մի տեղ գրված չէ։

Չափեք այն քանոնով, որով ապրելու եք

SAME BOX · TWO RULERS RFC 3511 · IP THROUGHPUT 1518-byte packets, a handful of sessions, inspection off 40 Gbit/s RFC 9411 · INSPECTED THROUGHPUT HTTPS 64 KB, full handshake, TLS inspection + IPS + App-ID on 6 Gbit/s SIZING GAP 6.7× Գնել եք 40-ի հաշվով, աշխատում եք 6-ով. պերիմետրը փոքր է դեռ առաջին օգտատիրոջից առաջ։

Ինչպես ենք մենք դա անում

RFC 9411 որպես ծառայություն՝ CloudLAB-ում կամ ձեզ մոտ

Դուք բերում եք DUT-ը կամ շորթ-լիստը. մենք բերում ենք գեներատորը, մեթոդը և հաշվետվությունը։ Ծավալը համաձայնեցնում ենք առաջին փաթեթից առաջ՝ 9 թեստերից որոնք, օբյեկտների որ չափերը, սարքի որ դասը, IPv4-ի և IPv6-ի հարաբերակցությունը, ձեր տրաֆիկի պրոֆիլը կամ NetSecOPEN-ինը։

Load & Performance Testing

9 բենչմարք ձեր ստենդին համապատասխան կոմերցիոն գեներատորի վրա՝ 1G-ից մինչև 100G։ Հայաստանում միացված ֆիզիկական սարք կամ ձեր վիրտուալ NGFW-ն մեր հոսթերի վրա, հաշվիչները՝ իրական ժամանակում բրաուզերում։

Հայցել թեստ-պլան

Security & Resilience Testing

Appendix A-ն բաժին 7-ից առաջ՝ 500 և ավելի CVE CVSS 7-ից 10, բաց տեսքով և TLS-ի ներսում, evasion տեխնիկաներով, աշխատանքային բեռնվածության ֆոնին։ Ինչ է արգելափակվել, ինչ է անցել և ինչ է DUT-ն ինքը զեկուցել այդ մասին։

Քննարկել CVE հավաքածուն

Test Plan & Methodology Design

Փորձարկումների ծրագիր և մեթոդիկա, որը կստորագրեն տենդերը, աուդիտորը կամ վաճառողը՝ սարքի դաս, ACL հավաքածու, տրաֆիկի պրոֆիլ, cipher suite-եր, անցման չափանիշներ, հաշվետվության ձևաչափ։ Օգտակար է, երբ վաճառողն առաջարկում է թեստն անցկացնել իր սարքավորումով, իսկ դուք ուզում եք նրան սահմանների մեջ պահել։

Պատվիրել թեստ-պլան

Hosted DUT Testing & Remote Lab Access

Ուղարկեք սարքը կամ բեռնեք VM-ը, դիտեք գործարկումը բրաուզերից, թեստային հավաքածուները պահեք ձեզ մոտ։ Կամ ամրագրեք CloudLAB-ի ժամանակ արդեն կարգավորված RFC 9411 մեթոդով. գործարկումը վարում են մեր ինժեներները, ձեր թիմը դիտում է և սահմանում պայմանները։

Մուտք CloudLAB
  • Անկախություն՝ մենք վաճառում ենք թեստը, վաճառողը՝ սարքը
  • Մեկ մեթոդ և մեկ ստենդ շորթ-լիստի յուրաքանչյուր թեկնածուի համար
  • Հում արդյունքները և թեստային հավաքածուները մնում են ձեզ մոտ

Թեմայի շուրջ

ՀՏՀ

Հարցեր, որոնք տալիս են առաջին գործարկումից առաջ

Տենդերում դեռ գրված է RFC 3511։ Կարո՞ղ եք թեստավորել դրանով։

Այո։ RFC 3511-ը հնացած է, բայց տենդերային փաստաթուղթը տենդերային փաստաթուղթ է։ Անցկացնում ենք 3511 հավաքածուն թղթերի համար և 9411 հավաքածուն որոշման համար, իսկ հաշվետվությունը բացատրում է, թե ինչու են թվերը տարբերվում։

Մեր NGFW-ն վիրտուալ է։ Մեթոդը փոխվու՞մ է։

Թեստերը նույնն են. հաշվետվությունն ավելի երկար է։ Հոսթի CPU-ն և RAM-ը, ամրացված միջուկները, NUMA հանգույցը, DPDK-ն կամ SR-IOV-ը, հիպերվիզորի տարբերակը՝ այս ամենը մտնում է հաշվետվություն, քանի որ vNGFW-ի արդյունքն առանց դրանց հնարավոր չէ վերարտադրել։ Sustain-ի ընթացքում հոսթը նույնպես հսկողության տակ է՝ աղմկոտ հարևաններ։

Պարտադի՞ր է միացնել TLS inspection-ը

RFC-ն այն խորհուրդ է տալիս և թույլ է տալիս բացառություններ։ Եթե ձեր արտադրության մեջ այն անջատված է, թեստավորում ենք առանց դրա, նշում ենք հաշվետվությունում և ավելացնում գործարկում միացվածով, որպեսզի տեսնեք հետագայում այն միացնելու գինը։

Իսկ եթե գեներատորը DUT-ից դանդա՞ղ է

Այդ դեպքում թեստ չկա։ Reference pre-test-ը հենց դրա համար է՝ ստենդը պարտավոր է գերազանցել DUT-ի հայտարարված արտադրողականությունը մինչև դրա միացումը։ Մենք ընտրում ենք գեներատորը և պորտերի քանակն այդ նշաձողի համար, իսկ pre-test-ի արդյունքը մտնում է հաշվետվություն։

Կարո՞ղ ենք բերել մեր տրաֆիկի պրոֆիլը

Այո, և մենք դա նախընտրում ենք։ Ձեր պերիմետրից մեկ օրվա flow տվյալներն ավելի լավ են, քան ցանկացած տիպային պրոֆիլ։ Դրանք վերածում ենք պրոֆիլի՝ հավելվածների նույն բաժիններով և օբյեկտների չափերով, և 7.1 թեստը գնում է դրա վրա՝ ստանդարտի կողքին։

Test. Compare. Decide.

Ուղարկեք մոդելը կամ շորթ-լիստը և այն դասը, որի համար հաշվում եք չափսը։ Ի պատասխան կստանաք RFC 9411 թեստ-պլան՝ թեստեր, օբյեկտների չափեր, cipher suite-եր, լաբորատոր օրեր և գին։ Հետո սարքը գնում է ստենդ, իսկ datasheet-ը՝ սեղանի դարակ։

Հայցել թեստ-պլան Մուտք CloudLAB

Ուղարկեք ցուցակը

Մեթոդը ձեր ձեռքին է։ Մնում է ստանալ թվերը։

Նշեք մոդելները և ձեզ համար կարևոր ցուցանիշները։ Ինժեները կպատասխանի մեկ աշխատանքային օրվա ընթացքում թեստային պլանի նախագծով և գնահատականով։

Հարմար է զրուցե՞լ Գրել ինժեներին WhatsApp-ով

Ուղարկվածն օգտագործում ենք միայն ձեզ պատասխանելու համար։ Տե՛ս գաղտնիության քաղաքականությունը։