Այս հոդվածը չորրորդն է «Ինչպես վերահսկել ձեր ցանցային ենթակառուցվածքը» շարքից: Շարքի բոլոր հոդվածների բովանդակությունը և հղումները կարելի է գտնել այստեղ.

В առաջին մասը Այս գլխում մենք դիտարկեցինք տվյալների կենտրոնի հատվածում ցանցային անվտանգության որոշ ասպեկտներ: Այս մասը նվիրված կլինի «Ինտերնետ հասանելիություն» հատվածին:

Մուտք ինտերնետ

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

Այս հատվածը ստուգելիս ուշադրություն դարձրեք հետևյալ ասպեկտներին.

• կառուցվածք
• BGP կարգավորումներ
• DOS/DDOS պաշտպանություն
• երթևեկության զտում firewall-ի վրա

Կառուցվածք

Որպես ձեռնարկությունների ցանցի համար այս հատվածի նախագծման օրինակ, ես խորհուրդ կտայի ղեկավարությունը Cisco-ից ներսում ԱՆՎՏԱՆԳ մոդելներ.

Իհարկե, գուցե այլ վաճառողների լուծումը ձեզ ավելի գրավիչ թվա (տես. Gartner Quadrant 2018 թ), բայց առանց խրախուսելու ձեզ մանրամասնորեն հետևել այս դիզայնին, ես դեռ օգտակար եմ համարում հասկանալ դրա հիմքում ընկած սկզբունքներն ու գաղափարները:

Նշում.

SAFE-ում «Remote Access» հատվածը «Internet Access» հատվածի մի մասն է: Բայց այս հոդվածաշարում մենք այն կքննարկենք առանձին:

Ձեռնարկությունների ցանցի համար այս հատվածի սարքավորումների ստանդարտ հավաքածուն է

• սահմանային երթուղիչներ
• firewalls

Դիտողություն 1

Այս հոդվածաշարում, երբ ես խոսում եմ firewalls-ի մասին, նկատի ունեմ NGFW.

Դիտողություն 2

Ես բաց եմ թողնում L2/L1-ի տարբեր տեսակների կամ L2-ի վրա L3-ի վրա վերադրվող լուծումների դիտարկումը, որոնք անհրաժեշտ են L1/L2 կապն ապահովելու համար և սահմանափակվում եմ միայն L3 մակարդակի և ավելի բարձր խնդիրներով: Մասամբ L1/L2 հարցերը քննարկվել են գլխում «Մաքրում և փաստաթղթավորում»:

Եթե ​​դուք չեք գտել firewall այս հատվածում, ապա չպետք է շտապեք եզրակացություններ անել:

Եկեք անենք նույնը, ինչ ներսում նախորդ մասըՍկսենք հարցից՝ ձեր դեպքում անհրաժեշտ է արդյոք այս հատվածում firewall օգտագործել:

Կարող եմ ասել, որ սա ամենաարդարացված վայրն է firewalls-ների օգտագործման և երթևեկության զտման բարդ ալգորիթմներ կիրառելու համար: IN մաս 1 Մենք նշեցինք 4 գործոն, որոնք կարող են խանգարել տվյալների կենտրոնի հատվածում firewalls-ի օգտագործմանը։ Բայց այստեղ դրանք այլեւս այնքան էլ նշանակալից չեն։

Օրինակ 1: Հետաձգումը

Ինչ վերաբերում է ինտերնետին, ապա նույնիսկ մոտ 1 միլիվայրկյան ուշացումների մասին խոսելն անիմաստ է։ Հետևաբար, այս հատվածում ուշացումը չի կարող լինել firewall-ի օգտագործումը սահմանափակող գործոն:

Օրինակ 2: Արտադրողականություն

Որոշ դեպքերում այս գործոնը դեռ կարող է նշանակալից լինել: Հետևաբար, դուք կարող եք թույլ տալ որոշ երթևեկություն (օրինակ՝ բեռների հավասարակշռող սարքերի երթևեկությունը) շրջանցելու firewall-ը:

Օրինակ 3: Հուսալիություն

Այս գործոնը դեռ պետք է հաշվի առնել, բայց այնուամենայնիվ, հաշվի առնելով բուն ինտերնետի անվստահելիությունը, դրա կարևորությունն այս հատվածի համար այնքան էլ նշանակալի չէ, որքան տվյալների կենտրոնի համար:

Այսպիսով, ենթադրենք, որ ձեր ծառայությունը ապրում է http/https-ի վերևում (կարճ նիստերով): Այս դեպքում կարող եք օգտագործել երկու անկախ տուփեր (առանց HA) և եթե դրանցից մեկի հետ երթուղային խնդիր կա, ամբողջ տրաֆիկը փոխանցեք երկրորդին։

Կամ դուք կարող եք օգտագործել firewall-ները թափանցիկ ռեժիմում և, եթե դրանք ձախողվեն, թույլ տվեք տրաֆիկին շրջանցել firewall-ը խնդիրը լուծելիս:

Հետևաբար, ամենայն հավանականությամբ պարզապես գին կարող է լինել այն գործոնը, որը կստիպի ձեզ հրաժարվել այս հատվածում firewalls-ից:

Կարեւոր!

Այս firewall-ը տվյալների կենտրոնի firewall-ի հետ համատեղելու գայթակղություն կա (այս հատվածների համար օգտագործեք մեկ firewall): Լուծումը, սկզբունքորեն, հնարավոր է, բայց դուք պետք է դա հասկանաք, քանի որ Ինտերնետ հասանելիության firewall-ը իրականում ձեր պաշտպանության առաջնագծում է և «վերցնում» է վնասակար տրաֆիկի առնվազն մի մասը, այնուհետև, իհարկե, դուք պետք է հաշվի առնեք այս firewall-ի անջատման մեծ ռիսկը: Այսինքն, օգտագործելով նույն սարքերը այս երկու հատվածներում, դուք զգալիորեն կնվազեցնեք ձեր տվյալների կենտրոնի սեգմենտի հասանելիությունը։

Ինչպես միշտ, դուք պետք է հասկանաք, որ կախված այն ծառայությունից, որը տրամադրում է ընկերությունը, այս հատվածի դիզայնը կարող է շատ տարբեր լինել: Ինչպես միշտ, դուք կարող եք ընտրել տարբեր մոտեցումներ՝ կախված ձեր պահանջներից:

Օրինակ

Եթե ​​դուք բովանդակության մատակարար եք, CDN ցանցով (տե՛ս, օրինակ. հոդվածների շարք), ապա միգուցե չցանկանաք ենթակառուցվածք ստեղծել տասնյակ կամ նույնիսկ հարյուրավոր ներկայության կետերում՝ օգտագործելով առանձին սարքեր՝ երթուղային և զտիչ երթևեկության համար: Դա թանկ կարժենա, և դա կարող է պարզապես ավելորդ լինել։

BGP-ի համար պարտադիր չէ, որ ունենաք հատուկ երթուղիչներ, կարող եք օգտագործել բաց կոդով գործիքներ, ինչպիսիք են. Քուագգա. Այսպիսով, երևի ձեզ անհրաժեշտ է միայն սերվեր կամ մի քանի սերվեր, անջատիչ և BGP:

Այս դեպքում ձեր սերվերը կամ մի քանի սերվերներ կարող են խաղալ ոչ միայն CDN սերվերի, այլ նաև երթուղիչի դեր։ Իհարկե, դեռ շատ մանրամասներ կան (օրինակ, թե ինչպես ապահովել հավասարակշռությունը), բայց դա հնարավոր է, և դա մոտեցում է, որը մենք հաջողությամբ կիրառել ենք մեր գործընկերներից մեկի համար:

Դուք կարող եք ունենալ մի քանի տվյալների կենտրոններ ամբողջական պաշտպանությամբ (հրդեհային պատեր, DDOS պաշտպանության ծառայություններ, որոնք տրամադրվում են ձեր ինտերնետ մատակարարների կողմից) և տասնյակ կամ հարյուրավոր «պարզեցված» ներկայության կետեր միայն L2 անջատիչներով և սերվերներով:

Իսկ ի՞նչ կասեք այս դեպքում պաշտպանության մասին։

Դիտարկենք, օրինակ, վերջերս հայտնի DNS ուժեղացում DDOS հարձակում. Դրա վտանգը կայանում է նրանում, որ ստեղծվում է մեծ քանակությամբ տրաֆիկ, որը պարզապես «խցանվում է» ձեր բոլոր վերահղումների 100%-ով:

Ի՞նչ ունենք մեր դիզայնի դեպքում։

• եթե դուք օգտագործում եք AnyCast, ապա երթևեկությունը բաշխվում է ձեր ներկայության կետերի միջև: Եթե ​​ձեր ընդհանուր թողունակությունը տերաբիթ է, ապա դա ինքնին իրականում (սակայն, վերջերս մի քանի հարձակումներ են եղել վնասակար թրաֆիկներով տերաբիթների կարգով) պաշտպանում է ձեզ «հորդառատ» վերին հղումներից:
• Եթե, այնուամենայնիվ, որոշ վերին հղումներ խցանվեն, ապա դուք պարզապես հեռացնում եք այս կայքը ծառայությունից (դադարեցնել գովազդել նախածանցը)
• Դուք կարող եք նաև մեծացնել ձեր «լիարժեք» (և, համապատասխանաբար, պաշտպանված) տվյալների կենտրոններից ուղարկվող տրաֆիկի բաժինը՝ այդպիսով հեռացնելով վնասակար տրաֆիկի զգալի մասը անպաշտպան ներկայության կետերից։

Եվ ևս մեկ փոքրիկ նշում այս օրինակին: Եթե ​​դուք բավականաչափ տրաֆիկ եք ուղարկում IX-ների միջոցով, ապա դա նաև նվազեցնում է ձեր խոցելիությունը նման հարձակումների նկատմամբ

BGP-ի կարգավորում

Այստեղ երկու թեմա կա.

• Միացում
• BGP-ի կարգավորում

Մենք արդեն մի փոքր խոսել ենք միացման մասին մաս 1. Խնդիրն այն է, որ ձեր հաճախորդների երթևեկությունը կատարվի օպտիմալ ճանապարհով: Թեև օպտիմալությունը միշտ չէ, որ վերաբերում է միայն ուշացմանը, ցածր հետաձգումը սովորաբար օպտիմալության հիմնական ցուցանիշն է: Որոշ ընկերությունների համար սա ավելի կարևոր է, մյուսների համար՝ ավելի քիչ։ Ամեն ինչ կախված է ձեր մատուցած ծառայությունից:

Օրինակ 1

Եթե ​​դուք փոխանակման եք, և ձեր հաճախորդների համար կարևոր են միլիվայրկյաններից պակաս ժամանակային միջակայքերը, ապա, իհարկե, որևէ տեսակի ինտերնետի մասին ընդհանրապես խոսք լինել չի կարող:

Օրինակ 2

Եթե ​​դուք խաղային ընկերություն եք, և տասնյակ միլիվայրկյանները ձեզ համար կարևոր են, ապա, իհարկե, կապը շատ կարևոր է ձեզ համար:

Օրինակ 3

Դուք նաև պետք է հասկանաք, որ TCP արձանագրության հատկությունների պատճառով տվյալների փոխանցման արագությունը մեկ TCP նիստի ընթացքում կախված է նաև RTT-ից (Round Trip Time): CDN ցանցերը նույնպես կառուցվում են այս խնդիրը լուծելու համար՝ բովանդակության բաշխման սերվերներն ավելի մոտեցնելով այս բովանդակության սպառողին:

Կապի ուսումնասիրությունն ինքնին հետաքրքիր թեմա է, որը արժանի է իր հոդվածին կամ հոդվածների շարքին և պահանջում է լավ հասկանալ, թե ինչպես է «աշխատում ինտերնետը»:

Օգտակար ռեսուրսներ.

ripe.net
bgp.he.net

Օրինակ

Ես միայն մեկ փոքրիկ օրինակ բերեմ.

Ենթադրենք, որ ձեր տվյալների կենտրոնը գտնվում է Մոսկվայում, և դուք ունեք մեկ վերելք՝ Ռոստելեկոմ (AS12389): Այս դեպքում (մեկ տուն) ձեզ BGP պետք չէ, և դուք, ամենայն հավանականությամբ, օգտագործում եք Ռոստելեկոմի հասցեների լողավազանը որպես հանրային հասցեներ:

Ենթադրենք, որ դուք որոշակի ծառայություն եք մատուցում, և բավականաչափ հաճախորդներ ունեք Ուկրաինայից, և նրանք բողոքում են երկար ուշացումներից։ Ձեր հետազոտության ընթացքում պարզել եք, որ դրանցից մի քանիսի IP հասցեները գտնվում են 37.52.0.0/21 ցանցում։

Գործարկելով traceroute-ը, դուք տեսաք, որ երթևեկությունը անցնում է AS1299 (Telia) միջով, իսկ ping-ը գործարկելով, ստացաք միջին RTT 70-80 միլիվայրկյան: Սա կարող եք տեսնել նաև այստեղ ապակի Ռոստելեկոմ.

Օգտագործելով whois utility-ը (ripe.net-ում կամ տեղական կոմունալ ծառայություններից), կարող եք հեշտությամբ որոշել, որ 37.52.0.0/21 բլոկը պատկանում է AS6849-ին (Ukrtelecom):

Հաջորդը, գնալով bgp.he.net դուք տեսնում եք, որ AS6849-ը որևէ կապ չունի AS12389-ի հետ (նրանք ոչ հաճախորդներ են, ոչ էլ միմյանց հետ կապողներ, ոչ էլ նրանք ունեն peering): Բայց եթե նայեք հասակակիցների ցուցակը AS6849-ի համար դուք կտեսնեք, օրինակ, AS29226 (Mastertel) և AS31133 (Megafon):

Այս մատակարարների ապակին գտնելուց հետո կարող եք համեմատել ուղին և RTT-ը: Օրինակ, Mastertel-ի համար RTT-ը կլինի մոտ 30 միլիվայրկյան:

Այսպիսով, եթե 80 և 30 միլիվայրկյանների միջև տարբերությունը նշանակալի է ձեր ծառայության համար, ապա գուցե դուք պետք է մտածեք կապի մասին, ստանաք ձեր AS համարը, ձեր հասցեների ֆոնդը RIPE-ից և միացնեք լրացուցիչ հղումներ և/կամ ստեղծեք ներկայության կետեր IX-ներում:

Երբ դուք օգտագործում եք BGP, դուք ոչ միայն հնարավորություն ունեք բարելավելու կապը, այլև ավելորդ կերպով պահպանում եք ձեր ինտերնետ կապը:

Այս փաստաթուղթը պարունակում է առաջարկություններ BGP-ի կազմաձևման համար: Չնայած այն հանգամանքին, որ այս առաջարկությունները մշակվել են մատակարարների «լավագույն պրակտիկայի» հիման վրա, այնուամենայնիվ (եթե ձեր BGP-ի կարգավորումները այնքան էլ հիմնական չեն) դրանք, անկասկած, օգտակար են և իրականում պետք է լինեն այն կարծրացման մի մասը, որը մենք քննարկել ենք: առաջին մասը.

DOS/DDOS պաշտպանություն

Այժմ DOS/DDOS հարձակումները շատ ընկերությունների համար դարձել են ամենօրյա իրականություն: Իրականում, այս կամ այն ​​ձևով բավականին հաճախ են հարձակվում ձեզ վրա: Այն փաստը, որ դուք դեռ չեք նկատել դա միայն նշանակում է, որ ձեր դեմ ուղղված հարձակումը դեռ չի կազմակերպվել, և որ պաշտպանական միջոցները, որոնք դուք օգտագործում եք, նույնիսկ գուցե առանց իմանալու (օպերացիոն համակարգերի տարբեր ներկառուցված պաշտպանություններ), բավարար են՝ համոզվեք, որ մատուցվող ծառայության վատթարացումը նվազագույնի հասցվի ձեր և ձեր հաճախորդների համար:

Կան ինտերնետային ռեսուրսներ, որոնք, հիմնվելով սարքավորումների տեղեկամատյանների վրա, իրական ժամանակում գծում են հարձակման գեղեցիկ քարտեզներ:

Այստեղ դուք կարող եք գտնել դրանց հղումները:

Իմ սիրածը քարտեզ CheckPoint-ից:

DDOS/DOS-ից պաշտպանությունը սովորաբար շերտավորված է: Հասկանալու համար, թե ինչու, դուք պետք է հասկանաք, թե ինչ տեսակի DOS/DDOS հարձակումներ կան (տե՛ս, օրինակ. այստեղ կամ այստեղ)

Այսինքն, մենք ունենք երեք տեսակի հարձակումներ.

• ծավալային հարձակումներ
• արձանագրային հարձակումներ
• հավելվածների հարձակումները

Եթե ​​դուք կարող եք պաշտպանվել ձեզ վերջին երկու տեսակի հարձակումներից՝ օգտագործելով, օրինակ, firewalls, ապա չեք կարող պաշտպանվել հարձակումներից, որոնք ուղղված են ձեր վերին հղումները «ճնշելու» (իհարկե, եթե ձեր ինտերնետ ալիքների ընդհանուր հզորությունը հաշվարկված չէ տերաբիթներով, կամ ավելի լավ, տասնյակ տերաբիտներով):

Հետևաբար, պաշտպանության առաջին գիծը պաշտպանությունն է «ծավալային» հարձակումներից, և ձեր մատակարարը կամ մատակարարները պետք է ապահովեն ձեզ այս պաշտպանությունը: Եթե ​​դուք դեռ չեք հասկացել դա, ուրեմն ձեր բախտը բերել է առայժմ:

Օրինակ

Ենթադրենք, դուք ունեք մի քանի վերին հղումներ, բայց մատակարարներից միայն մեկը կարող է ձեզ ապահովել այս պաշտպանությունը: Բայց եթե ամբողջ երթևեկությունը անցնում է մեկ մատակարարի միջոցով, ապա ինչ վերաբերում է միացմանը, որը մենք հակիրճ քննարկեցինք մի փոքր ավելի վաղ:

Այս դեպքում դուք ստիպված կլինեք մասամբ զոհաբերել կապը հարձակման ժամանակ: Բայց

• սա միայն հարձակման տևողության համար է: Հարձակման դեպքում դուք կարող եք ձեռքով կամ ավտոմատ կերպով վերակազմավորել BGP-ն այնպես, որ երթևեկությունը անցնի միայն այն մատակարարի միջոցով, որը ձեզ տրամադրում է «հովանոց»: Հարձակման ավարտից հետո դուք կարող եք վերադարձնել երթուղին իր նախկին վիճակին
• Անհրաժեշտ չէ փոխանցել ամբողջ տրաֆիկը: Եթե, օրինակ, տեսնում եք, որ հարձակումներ չկան որոշ վերին հղումների կամ հավասարեցումների միջոցով (կամ երթևեկությունը նշանակալի չէ), կարող եք շարունակել գովազդել այս BGP հարևանների նկատմամբ մրցակցային հատկանիշներով նախածանցներ:

Դուք կարող եք նաև «պրոտոկոլային հարձակումներից» և «կիրառական հարձակումներից» պաշտպանություն պատվիրակել ձեր գործընկերներին:
Այստեղ այստեղ դուք կարող եք կարդալ լավ ուսումնասիրություն (թարգմանություն) Ճիշտ է, հոդվածը երկու տարվա վաղեմություն ունի, բայց այն ձեզ պատկերացում կտա այն մոտեցումների մասին, թե ինչպես կարող եք պաշտպանվել DDOS հարձակումներից:

Սկզբունքորեն, դուք կարող եք սահմանափակվել դրանով, ամբողջովին աութսորսինգ անելով ձեր պաշտպանությունը: Այս որոշումը ունի առավելություններ, բայց կա նաև ակնհայտ թերություն. Փաստն այն է, որ մենք կարող ենք խոսել (կրկին, կախված նրանից, թե ինչ է անում ձեր ընկերությունը) բիզնեսի գոյատևման մասին: Եվ նման բաները վստահեք երրորդ անձանց...

Հետևաբար, եկեք տեսնենք, թե ինչպես կազմակերպել պաշտպանության երկրորդ և երրորդ գծերը (որպես մատակարարից պաշտպանվելու հավելում):

Այսպիսով, պաշտպանության երկրորդ գիծը զտիչն է և երթևեկության սահմանափակիչները (ոստիկանները) ձեր ցանցի մուտքի մոտ:

Օրինակ 1

Ենթադրենք, որ դուք ծածկվել եք DDOS-ի դեմ հովանոցով՝ պրովայդերներից մեկի օգնությամբ։ Ենթադրենք, որ այս մատակարարն օգտագործում է Arbor-ը՝ իր ցանցի եզրին տրաֆիկը և զտիչները զտելու համար:

The թողունակությունը, որը Arbor-ը կարող է «մշակել», սահմանափակ է, և մատակարարը, իհարկե, չի կարող անընդհատ փոխանցել իր բոլոր գործընկերների տրաֆիկը, ովքեր պատվիրում են այս ծառայությունը զտիչ սարքավորումների միջոցով: Հետեւաբար, նորմալ պայմաններում երթեւեկությունը զտված չէ։

Ենթադրենք, որ կա SYN ջրհեղեղի հարձակում: Նույնիսկ եթե դուք պատվիրել եք ծառայություն, որը հարձակման դեպքում ավտոմատ կերպով անցնում է երթևեկությունը զտման, դա անմիջապես տեղի չի ունենում: Մեկ րոպե կամ ավելի դուք մնում եք հարձակման տակ: Եվ դա կարող է հանգեցնել ձեր սարքավորումների ձախողման կամ ծառայության վատթարացման: Այս դեպքում, երթևեկության սահմանափակումը եզրային երթուղղման վրա, թեև դա կհանգեցնի նրան, որ այս ընթացքում որոշ TCP նիստեր չեն հաստատվի, ձեր ենթակառուցվածքը կփրկի ավելի լայնածավալ խնդիրներից:

Օրինակ 2

SYN փաթեթների աննորմալ մեծ քանակությունը կարող է լինել ոչ միայն SYN ջրհեղեղի հարձակման արդյունք: Ենթադրենք, որ դուք տրամադրում եք ծառայություն, որում կարող եք միաժամանակ ունենալ մոտ 100 հազար TCP կապ (մի տվյալների կենտրոնի):

Ենթադրենք, որ ձեր հիմնական պրովայդերներից մեկի հետ կարճաժամկետ խնդրի արդյունքում ձեր սեանսների կեսը հարվածում է: Եթե ​​ձեր հավելվածը նախագծված է այնպես, որ առանց երկու անգամ մտածելու այն անմիջապես (կամ որոշ ժամանակային ընդմիջումից հետո, որը նույնն է բոլոր նիստերի համար) փորձում է վերականգնել կապը, ապա դուք կստանաք մոտավորապես 50 հազար SYN փաթեթ։ միաժամանակ։

Եթե, օրինակ, դուք պետք է գործարկեք ssl/tls ձեռքսեղմում այս նիստերի վերևում, որը ներառում է վկայագրերի փոխանակում, ապա ձեր բեռի հավասարակշռողի համար ռեսուրսները սպառելու տեսանկյունից սա շատ ավելի ուժեղ «DDOS» կլինի, քան պարզ: SYN ջրհեղեղ. Թվում է, թե հավասարակշռողները պետք է զբաղվեն նման իրադարձություններով, բայց... ցավոք, մենք նման խնդրի առաջ ենք կանգնած։

Եվ, իհարկե, եզրային երթուղիչի ոստիկանը այս դեպքում նույնպես կփրկի ձեր սարքավորումը:

DDOS/DOS-ից պաշտպանության երրորդ մակարդակը ձեր firewall-ի կարգավորումներն են:

Այստեղ դուք կարող եք դադարեցնել երկրորդ և երրորդ տիպի հարձակումները: Ընդհանուր առմամբ, այն ամենը, ինչ հասնում է firewall-ին, կարող է զտվել այստեղ:

Խորհուրդ

Փորձեք հնարավորինս քիչ աշխատանք տալ firewall-ին՝ հնարավորինս զտելով պաշտպանության առաջին երկու գծերի վրա: Եվ ահա թե ինչու։

Ձեզ հետ պատահե՞լ է, որ պատահաբար, երբ թրաֆիկ եք ստեղծում՝ ստուգելու համար, օրինակ, թե որքանով է ձեր սերվերների օպերացիոն համակարգը դիմադրում DDOS գրոհներին, «սպանեք» ձեր firewall-ը՝ բեռնելով այն 100 տոկոսով, նորմալ ինտենսիվությամբ տրաֆիկով։ ? Եթե ​​ոչ, միգուցե դա պարզապես այն պատճառով է, որ չե՞ք փորձել:

Ընդհանրապես, firewall-ը, ինչպես ասացի, բարդ բան է, և այն լավ է աշխատում հայտնի խոցելիության և փորձարկված լուծումների հետ, բայց եթե դուք ինչ-որ անսովոր բան եք ուղարկում, պարզապես մի քանի աղբ կամ փաթեթներ սխալ վերնագրերով, ապա դուք որոշների հետ եք, ոչ թե With: այդքան փոքր հավանականությունը (հիմնված իմ փորձի վրա), դուք կարող եք ապշեցնել նույնիսկ բարձրակարգ սարքավորումները: Հետևաբար, 2-րդ փուլում, օգտագործելով սովորական ACL-ներ (L3/L4 մակարդակում), թույլատրեք միայն երթևեկությունը դեպի ձեր ցանց, որը պետք է մտնի այնտեղ:

Հրդեհային պատի վրա տրաֆիկի զտում

Շարունակենք զրույցը firewall-ի մասին։ Դուք պետք է հասկանաք, որ DOS/DDOS հարձակումները կիբերհարձակման ընդամենը մեկ տեսակ են:

Բացի DOS/DDOS պաշտպանությունից, մենք կարող ենք նաև ունենալ հետևյալ հատկանիշների ցանկի նման մի բան.

• հավելվածի firewalling
• սպառնալիքների կանխարգելում (հակավիրուսներ, հակալրտեսող ծրագրեր և խոցելիություն)
• URL զտիչ
• տվյալների զտում (բովանդակության զտում)
• ֆայլերի արգելափակում (ֆայլերի տեսակների արգելափակում)

Դուք պետք է որոշեք, թե ինչ է ձեզ անհրաժեշտ այս ցանկից:

Շարունակելի

Source: www.habr.com