Հոսքի արձանագրությունները որպես ներքին ցանցի անվտանգության մոնիտորինգի գործիք

Երբ խոսքը վերաբերում է ներքին կորպորատիվ կամ գերատեսչական ցանցի անվտանգության մոնիտորինգին, շատերը դա կապում են տեղեկատվության արտահոսքի վերահսկման և DLP լուծումների իրականացման հետ: Եվ եթե փորձեք պարզաբանել հարցը և հարցնել, թե ինչպես եք հայտնաբերում հարձակումները ներքին ցանցի վրա, ապա պատասխանը, որպես կանոն, կլինի ներխուժման հայտնաբերման համակարգերի (IDS) հիշատակում: Իսկ այն, ինչ 10-20 տարի առաջ միակ տարբերակն էր, այսօր դառնում է անախրոնիզմ։ Ներքին ցանցի մոնիտորինգի համար կա ավելի արդյունավետ և որոշ տեղերում միակ հնարավոր տարբերակը՝ հոսքային արձանագրությունների օգտագործումը, որոնք ի սկզբանե նախատեսված էին ցանցային խնդիրների որոնման համար (անսարքությունների վերացում), բայց ժամանակի ընթացքում վերածվեցին անվտանգության շատ հետաքրքիր գործիքի: Մենք կխոսենք այն մասին, թե ինչ հոսքային արձանագրություններ կան, և որոնք են ավելի լավ ցանցային հարձակումները հայտնաբերելու համար, որտեղ ավելի լավ է իրականացնել հոսքի մոնիտորինգ, ինչ փնտրել նման սխեման տեղադրելիս և նույնիսկ ինչպես այս ամենը «բարձրացնել» կենցաղային սարքավորումների վրա: սույն հոդվածի շրջանակներում:

«Ինչո՞ւ է անհրաժեշտ ներքին ենթակառուցվածքի անվտանգության մոնիտորինգը» հարցին չեմ անդրադառնա։ Պատասխանը կարծես թե պարզ է. Բայց եթե, այնուամենայնիվ, կցանկանայիք ևս մեկ անգամ համոզվել, որ այսօր չեք կարող ապրել առանց դրա, նայեք կարճ տեսանյութ այն մասին, թե ինչպես կարող եք 17 եղանակով ներթափանցել կորպորատիվ ցանց, որը պաշտպանված է firewall-ով: Հետևաբար, մենք կենթադրենք, որ հասկանում ենք, որ ներքին մոնիտորինգը անհրաժեշտ բան է, և մնում է հասկանալ, թե ինչպես կարելի է դա կազմակերպել։

Ցանցի մակարդակում ենթակառուցվածքի մոնիտորինգի համար ես կառանձնացնեի տվյալների երեք հիմնական աղբյուրներ.

• «հում» տրաֆիկ, որը մենք գրավում և վերլուծության ենք ներկայացնում որոշակի վերլուծության համակարգերի,
• իրադարձություններ ցանցային սարքերից, որոնցով անցնում է երթևեկությունը,
• երթևեկության մասին տեղեկատվությունը ստացված հոսքի արձանագրություններից մեկի միջոցով:

Չմշակված թրաֆիկի գրավումը անվտանգության մասնագետների շրջանում ամենատարածված տարբերակն է, քանի որ այն պատմականորեն հայտնվել է և առաջինն էր: Սովորական ցանցային ներխուժման հայտնաբերման համակարգերը (առաջին առևտրային ներխուժման հայտնաբերման համակարգը եղել է NetRanger-ը Wheel Group-ից, որը գնվել է 1998 թվականին Cisco-ի կողմից) ճշգրտորեն ներգրավված են եղել փաթեթների գրավման մեջ (և ավելի ուշ նիստերի), որոնցում որոշակի ստորագրություններ են որոնվել («վճռական կանոններ» FSTEC տերմինաբանություն), ազդանշանային հարձակումներ: Իհարկե, դուք կարող եք վերլուծել չմշակված երթևեկությունը ոչ միայն IDS-ի միջոցով, այլ նաև օգտագործելով այլ գործիքներ (օրինակ՝ Wireshark, tcpdum կամ NBAR2 ֆունկցիոնալությունը Cisco IOS-ում), բայց դրանք սովորաբար չունեն գիտելիքների բազա, որը տարբերում է տեղեկատվական անվտանգության գործիքը սովորականից: ՏՏ գործիք.

Այսպիսով, հարձակումների հայտնաբերման համակարգեր: Ցանցային հարձակումների հայտնաբերման ամենահին և ամենատարածված մեթոդը, որը լավ է աշխատում պարագծում (անկախ նրանից, թե ինչ է `կորպորատիվ, տվյալների կենտրոն, հատված և այլն), բայց ձախողվում է ժամանակակից փոխարկված և ծրագրային ապահովմամբ սահմանված ցանցերում: Սովորական անջատիչների հիման վրա կառուցված ցանցի դեպքում հարձակումների հայտնաբերման սենսորների ենթակառուցվածքը դառնում է չափազանց մեծ. դուք պետք է սենսոր տեղադրեք այն հանգույցի յուրաքանչյուր միացման վրա, որի վրա ցանկանում եք վերահսկել հարձակումները: Ցանկացած արտադրող, իհարկե, ուրախ կլինի ձեզ վաճառել հարյուրավոր և հազարավոր սենսորներ, բայց կարծում եմ, որ ձեր բյուջեն չի կարող ապահովել նման ծախսեր: Կարող եմ ասել, որ նույնիսկ Cisco-ում (իսկ մենք NGIPS-ի մշակողներն ենք) մենք դա չկարողացանք անել, չնայած թվում էր, թե գնի հարցը մեր առջև է։ Ես չպետք է կանգնեմ, դա մեր սեփական որոշումն է. Բացի այդ, հարց է առաջանում՝ ինչպե՞ս միացնել սենսորը այս տարբերակում։ Արդյո՞ք բացը: Ինչ անել, եթե սենսորն ինքնին ձախողվի: Պահանջե՞լ շրջանցող մոդուլ սենսորում: Օգտագործե՞լ բաժանարարներ (թակել): Այս ամենը թանկացնում է լուծումը և դարձնում այն ​​անհասանելի ցանկացած չափի ընկերության համար։

Դուք կարող եք փորձել «կախել» սենսորը SPAN/RSPAN/ERSPAN միացքի վրա և ուղղորդել երթևեկությունը անհրաժեշտ անջատիչ պորտերից դեպի այն: Այս տարբերակը մասամբ վերացնում է նախորդ պարբերությունում նկարագրված խնդիրը, բայց առաջ է բերում ևս մեկը. SPAN նավահանգիստը չի կարող ընդունել բացարձակապես ամբողջ տրաֆիկը, որը կուղարկվի իրեն, այն չի ունենա բավարար թողունակություն: Ստիպված կլինեք ինչ-որ բան զոհաբերել։ Կամ թողեք որոշ հանգույցներ առանց մոնիտորինգի (այնուհետև նախ պետք է դրանց առաջնահերթությունը տալ), կամ ուղարկեք ոչ ամբողջ տրաֆիկը հանգույցից, այլ միայն որոշակի տեսակ: Ամեն դեպքում, մենք կարող ենք բաց թողնել որոշ գրոհներ։ Բացի այդ, SPAN նավահանգիստը կարող է օգտագործվել այլ կարիքների համար: Արդյունքում, մենք ստիպված կլինենք վերանայել գոյություն ունեցող ցանցի տոպոլոգիան և, հնարավոր է, ճշգրտումներ անենք դրանում, որպեսզի ձեր ցանցը առավելագույնս ծածկենք ձեր ունեցած սենսորների քանակով (և դա համաձայնեցնենք ՏՏ-ի հետ):

Իսկ եթե ձեր ցանցն օգտագործում է ասիմետրիկ երթուղիներ: Ի՞նչ անել, եթե դուք իրականացրել եք կամ նախատեսում եք իրականացնել SDN: Ի՞նչ անել, եթե Ձեզ անհրաժեշտ է վերահսկել վիրտուալացված մեքենաները կամ բեռնարկղերը, որոնց երթևեկությունն ընդհանրապես չի հասնում ֆիզիկական անջատիչին: Սրանք հարցեր են, որոնք ավանդական IDS վաճառողներին դուր չեն գալիս, քանի որ չգիտեն, թե ինչպես պատասխանել դրանց: Միգուցե նրանք ձեզ համոզեն, որ այս բոլոր նորաձև տեխնոլոգիաները հիպ են, և դա ձեզ պետք չէ: Միգուցե նրանք կխոսեն փոքրից սկսելու անհրաժեշտության մասին։ Կամ միգուցե նրանք կասեն, որ դուք պետք է ցանցի կենտրոնում տեղադրեք հզոր սրիչ և ողջ երթևեկությունը դեպի այն ուղղեք հավասարակշռիչների միջոցով: Ինչ տարբերակ էլ որ առաջարկվի ձեզ, դուք պետք է հստակ հասկանաք, թե ինչպես է դա ձեզ հարմար։ Եվ միայն դրանից հետո որոշում կայացվի ցանցային ենթակառուցվածքի տեղեկատվական անվտանգության մոնիտորինգի մոտեցման ընտրության վերաբերյալ։ Վերադառնալով փաթեթների գրավմանը, ուզում եմ ասել, որ այս մեթոդը շարունակում է մնալ շատ տարածված և կարևոր, բայց դրա հիմնական նպատակը սահմանային հսկողությունն է. սահմաններ ձեր կազմակերպության և ինտերնետի միջև, սահմաններ տվյալների կենտրոնի և ցանցի մնացած մասերի միջև, սահմաններ գործընթացի կառավարման համակարգի և կորպորատիվ հատվածի միջև: Այս վայրերում դասական IDS/IPS-ները դեռ իրավունք ունեն գոյություն ունենալ և լավ հաղթահարել իրենց առաջադրանքները:

Անցնենք երկրորդ տարբերակին։ Ցանցային սարքերից եկող իրադարձությունների վերլուծությունը կարող է օգտագործվել նաև հարձակումների հայտնաբերման նպատակով, բայց ոչ որպես հիմնական մեխանիզմ, քանի որ այն թույլ է տալիս հայտնաբերել ներխուժումների միայն փոքր դասը: Բացի այդ, դա բնորոշ է որոշակի ռեակտիվությանը՝ նախ հարձակումը պետք է տեղի ունենա, այնուհետև այն պետք է գրանցվի ցանցային սարքի կողմից, որն այս կամ այն ​​կերպ ազդարարում է տեղեկատվական անվտանգության հետ կապված խնդիր: Նման մի քանի եղանակներ կան. Սա կարող է լինել syslog, RMON կամ SNMP: Տեղեկատվական անվտանգության համատեքստում ցանցի մոնիտորինգի վերջին երկու արձանագրությունները օգտագործվում են միայն այն դեպքում, եթե մենք պետք է հայտնաբերենք DoS հարձակում հենց ցանցային սարքավորումների վրա, քանի որ RMON-ի և SNMP-ի միջոցով հնարավոր է, օրինակ, վերահսկել սարքի կենտրոնական բեռը: պրոցեսորը կամ դրա միջերեսը: Սա «ամենաէժաններից» մեկն է (բոլորն ունեն syslog կամ SNMP), բայց նաև ամենաանարդյունավետը ներքին ենթակառուցվածքի տեղեկատվական անվտանգության մոնիտորինգի բոլոր մեթոդներից. շատ հարձակումներ պարզապես թաքնված են դրանից: Իհարկե, դրանք չպետք է անտեսվեն, և նույն syslog վերլուծությունը օգնում է ձեզ ժամանակին բացահայտել սարքի կազմաձևման փոփոխությունները, դրա փոխզիջումը, բայց դա այնքան էլ հարմար չէ ամբողջ ցանցի վրա հարձակումները հայտնաբերելու համար:

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

• Հոսքի առաջացում կամ արտահանում: Այս դերը սովորաբար վերագրվում է երթուղիչին, անջատիչին կամ ցանցային այլ սարքին, որն իր միջով ցանցային երթևեկությունն անցնելով թույլ է տալիս նրանից հանել հիմնական պարամետրերը, որոնք այնուհետև փոխանցվում են հավաքման մոդուլին: Օրինակ, Cisco-ն աջակցում է Netflow արձանագրությանը ոչ միայն երթուղիչների և անջատիչների, ներառյալ վիրտուալ և արդյունաբերական, այլ նաև անլար կարգավորիչների, firewalls-ի և նույնիսկ սերվերների վրա:
• Հավաքածուի հոսք. Հաշվի առնելով, որ ժամանակակից ցանցը սովորաբար ունի մեկից ավելի ցանցային սարքեր, առաջանում է հոսքերի հավաքագրման և համախմբման խնդիր, որը լուծվում է այսպես կոչված կոլեկտորների միջոցով, որոնք մշակում են ստացված հոսքերը և այնուհետև փոխանցում վերլուծության։
• Հոսքի վերլուծություն Անալիզատորն իր վրա է վերցնում հիմնական ինտելեկտուալ խնդիրը և, տարբեր ալգորիթմներ կիրառելով հոսքերի վրա, որոշակի հետևություններ է անում։ Օրինակ, որպես ՏՏ գործառույթի մաս, նման անալիզատորը կարող է բացահայտել ցանցի խցանումները կամ վերլուծել երթևեկության ծանրաբեռնվածության պրոֆիլը ցանցի հետագա օպտիմալացման համար: Իսկ տեղեկատվական անվտանգության համար նման անալիզատորը կարող է հայտնաբերել տվյալների արտահոսքը, վնասակար կոդի տարածումը կամ DoS հարձակումները։

Մի կարծեք, որ այս եռաստիճան ճարտարապետությունը չափազանց բարդ է. մյուս բոլոր տարբերակները (բացառությամբ, հավանաբար, SNMP-ի և RMON-ի հետ աշխատող ցանցի մոնիտորինգի համակարգերի) նույնպես աշխատում են ըստ դրա: Մենք ունենք տվյալների գեներատոր վերլուծության համար, որը կարող է լինել ցանցային սարք կամ առանձին սենսոր: Մենք ունենք ահազանգերի հավաքման համակարգ և կառավարման համակարգ ամբողջ մոնիտորինգի ենթակառուցվածքի համար։ Վերջին երկու բաղադրիչները կարող են համակցվել մեկ հանգույցի մեջ, սակայն քիչ թե շատ մեծ ցանցերում դրանք սովորաբար տարածվում են առնվազն երկու սարքերի վրա, որպեսզի ապահովեն մասշտաբայնություն և հուսալիություն:

Ի տարբերություն փաթեթների վերլուծության, որը հիմնված է յուրաքանչյուր փաթեթի վերնագրի և մարմնի տվյալների ուսումնասիրության վրա, և այն բաղկացած է նիստերից, հոսքի վերլուծությունը հիմնված է ցանցային տրաֆիկի վերաբերյալ մետատվյալների հավաքագրման վրա: Ե՞րբ, որքա՞ն, որտեղից և որտեղից, ինչպես... սրանք հարցերի պատասխաններ են տալիս ցանցային հեռաչափության վերլուծությունը՝ օգտագործելով հոսքային տարբեր արձանագրություններ։ Սկզբում դրանք օգտագործվում էին վիճակագրություն վերլուծելու և ցանցում ՏՏ խնդիրները գտնելու համար, բայց հետո, երբ վերլուծական մեխանիզմները զարգացան, հնարավոր դարձավ դրանք կիրառել նույն հեռաչափության վրա՝ անվտանգության նպատակներով։ Կրկին հարկ է նշել, որ հոսքի վերլուծությունը չի փոխարինում կամ փոխարինում փաթեթների հավաքագրմանը: Այս մեթոդներից յուրաքանչյուրն ունի իր կիրառման ոլորտը: Բայց այս հոդվածի համատեքստում հոսքի վերլուծությունն է, որը լավագույնս հարմար է ներքին ենթակառուցվածքի մոնիտորինգի համար: Դուք ունեք ցանցային սարքեր (անկախ նրանից՝ դրանք գործում են ծրագրային ապահովման կողմից սահմանված պարադիգմում, թե ստատիկ կանոնների համաձայն), որոնց հարձակումը չի կարող շրջանցել: Այն կարող է շրջանցել դասական IDS սենսորը, բայց ցանցային սարքը, որն աջակցում է հոսքի արձանագրությանը, չի կարող: Սա այս մեթոդի առավելությունն է:

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

Պատկերացնենք, որ ցանցը աշխատում է 250 Մբիթ/վրկ արագությամբ։ Եթե ​​ցանկանում եք պահպանել այս ամբողջ ծավալը, ապա ձեզ անհրաժեշտ կլինի 31 ՄԲ հիշողություն՝ երթևեկության մեկ վայրկյանի համար, 1,8 ԳԲ՝ մեկ րոպեի համար, 108 ԳԲ՝ մեկ ժամ, և 2,6 ՏԲ՝ մեկ օրվա համար։ 10 Գբիթ/վ թողունակություն ունեցող ցանցից ամենօրյա տվյալներ պահելու համար ձեզ անհրաժեշտ կլինի 108 ՏԲ պահեստ: Բայց որոշ կարգավորիչներ պահանջում են տարիներ շարունակ պահպանել անվտանգության տվյալները... Պահանջով գրանցումը, որն օգնում է ձեզ իրականացնել հոսքի վերլուծությունը, օգնում է նվազեցնել այս արժեքները մեծության պատվերներով: Ի դեպ, եթե խոսենք ցանցի ձայնագրված հեռաչափության տվյալների ծավալի և ամբողջական տվյալների հավաքագրման հարաբերակցության մասին, ապա այն մոտավորապես 1-ից 500 է: Վերևում տրված նույն արժեքների համար պահվում է ամբողջ ամենօրյա տրաֆիկի ամբողջական տառադարձությունը: կկազմի համապատասխանաբար 5 և 216 ԳԲ (կարող եք նույնիսկ այն ձայնագրել սովորական ֆլեշ կրիչով):

Եթե ​​ցանցի չմշակված տվյալների վերլուծության գործիքների դեպքում դրանք վաճառողից վաճառող հավաքելու եղանակը գրեթե նույնն է, ապա հոսքի վերլուծության դեպքում իրավիճակն այլ է։ Հոսքի արձանագրությունների մի քանի տարբերակներ կան, որոնց տարբերությունները պետք է իմանաք անվտանգության համատեքստում: Ամենատարածվածը Cisco-ի կողմից մշակված Netflow արձանագրությունն է: Այս արձանագրության մի քանի տարբերակներ կան, որոնք տարբերվում են իրենց հնարավորություններով և գրանցված երթևեկության տեղեկատվության քանակով: Ներկայիս տարբերակը իններորդն է (Netflow v9), որի հիման վրա մշակվել է արդյունաբերական ստանդարտ Netflow v10, որը հայտնի է նաև որպես IPFIX։ Այսօր ցանցային վաճառողներից շատերն իրենց սարքավորումներում աջակցում են Netflow-ին կամ IPFIX-ին: Բայց հոսքային արձանագրությունների համար կան տարբեր այլ տարբերակներ՝ sFlow, jFlow, cFlow, rFlow, NetStream և այլն, որոնցից sFlow-ն ամենահայտնին է: Հենց այս տեսակն է, որն առավել հաճախ աջակցվում է ցանցային սարքավորումների հայրենական արտադրողների կողմից՝ իր իրականացման հեշտության պատճառով: Որո՞նք են հիմնական տարբերությունները Netflow-ի, որը դարձել է դե ֆակտո ստանդարտ, և sFlow-ի միջև: Ես կառանձնացնեի մի քանի հիմնական: Նախ, Netflow-ն ունի օգտագործողի կողմից կարգավորվող դաշտեր՝ ի տարբերություն sFlow-ի ֆիքսված դաշտերի: Եվ երկրորդը, և սա ամենակարևորն է մեր դեպքում, sFlow-ը հավաքում է այսպես կոչված նմուշային հեռաչափություն; ի տարբերություն Netflow-ի և IPFIX-ի համար չընտրվածի: Ո՞րն է նրանց միջև տարբերությունը:

Պատկերացրեք, որ որոշել եք կարդալ գիրքը»Անվտանգության օպերացիոն կենտրոն. Ձեր SOC-ի կառուցում, շահագործում և պահպանումԻմ գործընկերների՝ Գարի Մակինթայրի, Ջոզեֆ Մունիցի և Նադեմ Ալֆարդանի (գրքի մի մասը կարող եք ներբեռնել հղումից): Դուք ունեք երեք տարբերակ՝ ձեր նպատակին հասնելու համար՝ կարդալ ամբողջ գիրքը, շրջանցել այն, կանգ առնել յուրաքանչյուր 10-րդ կամ 20-րդ էջում կամ փորձել գտնել հիմնական հասկացությունների վերապատմում բլոգում կամ ծառայությունում, ինչպիսին է SmartReading-ը: Այսպիսով, չընտրված հեռաչափությունը կարդում է ցանցային տրաֆիկի յուրաքանչյուր «էջը», այսինքն՝ վերլուծում է մետատվյալները յուրաքանչյուր փաթեթի համար: Ընտրանքային հեռաչափությունը երթևեկության ընտրովի ուսումնասիրություն է այն հույսով, որ ընտրված նմուշները կպարունակեն այն, ինչ ձեզ հարկավոր է: Կախված կապուղու արագությունից, նմուշառված հեռաչափությունը կուղարկվի վերլուծության յուրաքանչյուր 64-րդ, 200-րդ, 500-րդ, 1000-րդ, 2000-րդ կամ նույնիսկ 10000-րդ փաթեթը:

Տեղեկատվական անվտանգության մոնիտորինգի համատեքստում սա նշանակում է, որ ընտրված հեռաչափությունը լավ հարմար է DDoS հարձակումները հայտնաբերելու, սկանավորելու և վնասակար կոդի տարածման համար, սակայն կարող է բաց թողնել ատոմային կամ բազմափաթեթ հարձակումները, որոնք ներառված չեն վերլուծության ուղարկված նմուշում: Չնշված հեռաչափությունը նման թերություններ չունի: Դրանով հայտնաբերված հարձակումների շրջանակը շատ ավելի լայն է: Ահա իրադարձությունների կարճ ցանկը, որոնք կարելի է հայտնաբերել ցանցային հեռաչափության վերլուծության գործիքների միջոցով:

Իհարկե, որոշ բաց կոդով Netflow անալիզատոր ձեզ թույլ չի տա դա անել, քանի որ դրա հիմնական խնդիրն է հավաքել հեռաչափություն և դրա վրա հիմնական վերլուծություն կատարել ՏՏ տեսանկյունից: Հոսքի վրա հիմնված տեղեկատվական անվտանգության սպառնալիքները բացահայտելու համար անհրաժեշտ է անալիզատորը համալրել տարբեր շարժիչներով և ալգորիթմներով, որոնք կբացահայտեն կիբերանվտանգության խնդիրները՝ հիմնված ստանդարտ կամ սովորական Netflow դաշտերի վրա, կհարստացնեն ստանդարտ տվյալները արտաքին տվյալների հետ Threat Intelligence-ի տարբեր աղբյուրներից և այլն:

Հետևաբար, եթե ունեք ընտրություն, ապա ընտրեք Netflow կամ IPFIX: Բայց նույնիսկ եթե ձեր սարքավորումն աշխատում է միայն sFlow-ի հետ, ինչպես հայրենական արտադրողները, ապա նույնիսկ այս դեպքում դուք կարող եք դրանից օգտվել անվտանգության համատեքստում:

2019 թվականի ամռանը ես վերլուծեցի այն հնարավորությունները, որոնք ունեն ռուսական ցանցային սարքավորումներ արտադրողները, և բոլորը, բացառությամբ NSG-ի, Polygon-ի և Craftway-ի, հայտարարեցին sFlow-ին աջակցելու մասին (առնվազն Zelax, Natex, Eltex, QTech, Rusteleteh):

Հաջորդ հարցը, որին դուք կբախվեք, այն է, թե որտեղ պետք է իրականացնել հոսքի աջակցություն անվտանգության նպատակներով: Փաստորեն, հարցը լիովին ճիշտ չի դրված. Ժամանակակից սարքավորումները գրեթե միշտ աջակցում են հոսքի արձանագրություններին: Հետևաբար, ես այլ կերպ կձևակերպեի հարցը. որտեղ է ամենաարդյունավետը անվտանգության տեսանկյունից հեռաչափություն հավաքելը: Պատասխանը միանգամայն ակնհայտ կլինի՝ մուտքի մակարդակում, որտեղ դուք կտեսնեք ողջ տրաֆիկի 100%-ը, որտեղ դուք կունենաք մանրամասն տեղեկատվություն հոսթների մասին (MAC, VLAN, ինտերֆեյսի ID), որտեղ կարող եք նույնիսկ վերահսկել P2P տրաֆիկը հոսթերների միջև, ինչը: կարևոր է վնասակար կոդի հայտնաբերման և տարածման համար: Հիմնական մակարդակում դուք կարող եք պարզապես չտեսնել տրաֆիկի մի մասը, բայց պարագծի մակարդակում դուք կտեսնեք ձեր ամբողջ ցանցի տրաֆիկի մեկ քառորդը: Բայց եթե ինչ-ինչ պատճառներով ձեր ցանցում ունեք արտասահմանյան սարքեր, որոնք հարձակվողներին թույլ են տալիս «մուտք և դուրս գալ»՝ առանց պարագիծը շրջանցելու, ապա դրանից հեռաչափությունը վերլուծելը ձեզ ոչինչ չի տա: Հետևաբար, առավելագույն ծածկույթի համար խորհուրդ է տրվում միացնել հեռաչափության հավաքումը մուտքի մակարդակում: Միևնույն ժամանակ, հարկ է նշել, որ նույնիսկ եթե մենք խոսում ենք վիրտուալացման կամ բեռնարկղերի մասին, հոսքի աջակցությունը հաճախ հանդիպում է նաև ժամանակակից վիրտուալ անջատիչների մեջ, ինչը թույլ է տալիս վերահսկել նաև այնտեղ երթևեկությունը:

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

Մեկ այլ կետ, որը կարևոր է հիշել հոսքի վերլուծության գործիքների մասին խոսելիս: Եթե ​​անվտանգության իրադարձությունների առաջացման սովորական միջոցների հետ կապված մենք օգտագործում ենք EPS մետրիկ (իրադարձություն մեկ վայրկյանում), ապա այս ցուցանիշը կիրառելի չէ հեռաչափական վերլուծության համար. այն փոխարինվում է FPS-ով (հոսքը վայրկյանում): Ինչպես EPS-ի դեպքում, այն հնարավոր չէ նախօրոք հաշվարկել, բայց կարող եք գնահատել թելերի մոտավոր թիվը, որոնք ստեղծում է տվյալ սարքը՝ կախված իր առաջադրանքից: Ինտերնետում կարող եք գտնել մոտավոր արժեքներով աղյուսակներ տարբեր տեսակի ձեռնարկությունների սարքերի և պայմանների համար, որոնք թույլ կտան գնահատել, թե ինչ լիցենզիաներ են ձեզ անհրաժեշտ վերլուծության գործիքների համար և ինչպիսին կլինի դրանց ճարտարապետությունը: Փաստն այն է, որ IDS սենսորը սահմանափակված է որոշակի թողունակությամբ, որը կարող է «քաշել», իսկ հոսքի կոլեկտորն ունի իր սահմանափակումները, որոնք պետք է հասկանալ: Հետեւաբար, մեծ, աշխարհագրորեն բաշխված ցանցերում սովորաբար լինում են մի քանի կոլեկցիոներներ: Երբ նկարագրեցի ինչպես է ցանցը վերահսկվում Cisco-ի ներսում, ես արդեն տվել եմ մեր կոլեկցիոներների թիվը՝ դրանք 21-ն են, և սա հինգ մայրցամաքներում ցրված ցանցի համար է և հաշվում է մոտ կես միլիոն ակտիվ սարքեր):

Մենք օգտագործում ենք մեր սեփական լուծումը՝ որպես Netflow մոնիտորինգի համակարգ Cisco Stealthwatch, որը հատուկ ուղղված է անվտանգության խնդիրների լուծմանը։ Այն ունի բազմաթիվ ներկառուցված շարժիչներ՝ անոմալ, կասկածելի և ակնհայտորեն վնասակար գործունեությունը հայտնաբերելու համար, ինչը թույլ է տալիս հայտնաբերել տարբեր սպառնալիքների լայն շրջանակ՝ կրիպտոմայնացումից մինչև տեղեկատվության արտահոսք, վնասակար կոդի տարածումից մինչև խարդախություն: Հոսքի անալիզատորների մեծ մասի պես, Stealthwatch-ը կառուցված է եռաստիճան սխեմայի համաձայն (գեներատոր - կոլեկտոր - անալիզատոր), բայց այն համալրված է մի շարք հետաքրքիր առանձնահատկություններով, որոնք կարևոր են դիտարկվող նյութի համատեքստում: Նախ՝ այն ինտեգրվում է փաթեթների գրավման լուծումների հետ (օրինակ՝ Cisco Security Packet Analyzer), որը թույլ է տալիս ձայնագրել ընտրված ցանցային նիստերը՝ հետագայում խորը հետաքննության և վերլուծության համար: Երկրորդը, հատկապես անվտանգության խնդիրները ընդլայնելու համար, մենք մշակել ենք հատուկ nvzFlow արձանագրություն, որը թույլ է տալիս «հեռարձակել» հավելվածների գործունեությունը վերջնական հանգույցների վրա (սերվերներ, աշխատատեղեր և այլն) դեպի հեռաչափություն և փոխանցել այն կոլեկցիոներին հետագա վերլուծության համար: Եթե ​​իր սկզբնական տարբերակում Stealthwatch-ն աշխատում է ցանկացած հոսքի արձանագրության հետ (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) ցանցի մակարդակով, ապա nvzFlow-ի աջակցությունը թույլ է տալիս տվյալների հարաբերակցությունը նաև հանգույցի մակարդակում, այդպիսով: բարձրացնելով ամբողջ համակարգի արդյունավետությունը և տեսնել ավելի շատ հարձակումներ, քան սովորական ցանցային հոսքի անալիզատորները:

Հասկանալի է, որ երբ խոսում ենք Netflow վերլուծության համակարգերի մասին անվտանգության տեսանկյունից, շուկան չի սահմանափակվում Cisco-ի մեկ լուծումով։ Դուք կարող եք օգտագործել ինչպես կոմերցիոն, այնպես էլ անվճար կամ shareware լուծումներ: Բավական տարօրինակ է, եթե Cisco-ի բլոգում որպես օրինակ մեջբերեմ մրցակիցների լուծումները, ուստի մի քանի խոսք կասեմ այն ​​մասին, թե ինչպես կարելի է վերլուծել ցանցային հեռաչափությունը՝ օգտագործելով երկու հանրաճանաչ, անուններով նման, բայց դեռ տարբեր գործիքներ՝ SiLK և ELK:

SiLK-ը երթևեկության վերլուծության համար նախատեսված գործիքների մի շարք է (համակարգ ինտերնետի մակարդակի գիտելիքների համար), որը մշակվել է ամերիկյան CERT/CC-ի կողմից և որն այսօրվա հոդվածի համատեքստում աջակցում է Netflow-ին (5-րդ և 9-րդ, ամենահայտնի տարբերակները), IPFIX: և sFlow և օգտագործելով տարբեր կոմունալ ծառայություններ (rwfilter, rwcount, rwflowpack և այլն) ցանցային հեռաչափության վրա տարբեր գործողություններ իրականացնելու համար՝ դրանում չթույլատրված գործողությունների նշաններ հայտնաբերելու համար: Բայց պետք է նշել մի քանի կարևոր կետ. SiLK-ը հրամանի տողի գործիք է, որն իրականացնում է առցանց վերլուծություն՝ մուտքագրելով այսպիսի հրամաններ (200 բայթից ավելի ICMP փաթեթների հայտնաբերում).

rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15

ոչ շատ հարմարավետ: Դուք կարող եք օգտագործել iSiLK GUI-ն, բայց դա ձեր կյանքը շատ չի դյուրացնի, միայն կլուծի վիզուալիզացիայի գործառույթը և չփոխարինի վերլուծաբանին: Եվ սա երկրորդ կետն է. Ի տարբերություն առևտրային լուծումների, որոնք արդեն ունեն ամուր վերլուծական բազա, անոմալիաների հայտնաբերման ալգորիթմներ, համապատասխան աշխատանքային հոսք և այլն, SiLK-ի դեպքում դուք ստիպված կլինեք այս ամենը անել ինքներդ, ինչը ձեզանից մի փոքր այլ կոմպետենտներ կպահանջի, քան արդեն պատրաստի օգտագործումը: օգտագործելու գործիքներ. Սա ոչ լավ է, ոչ էլ վատ. սա գրեթե ցանկացած անվճար գործիքի առանձնահատկությունն է, որը ենթադրում է, որ դուք գիտեք, թե ինչ անել, և դա միայն կօգնի ձեզ դրանում (առևտրային գործիքներն ավելի քիչ կախված են իր օգտագործողների իրավասություններից, չնայած նրանք նաև ենթադրում են. որ վերլուծաբանները հասկանան ցանցի հետաքննության և մոնիտորինգի առնվազն հիմունքները): Բայց վերադառնանք SiLK-ին։ Վերլուծաբանի աշխատանքային ցիկլը դրա հետ ունի հետևյալ տեսքը.

• Վարկածի ձևակերպում. Մենք պետք է հասկանանք, թե ինչ ենք փնտրելու ցանցային հեռաչափության ներսում, իմանանք այն եզակի հատկանիշները, որոնց միջոցով մենք կբացահայտենք որոշակի անոմալիաներ կամ սպառնալիքներ:
• Մոդելի կառուցում. Ձևակերպելով հիպոթեզ՝ մենք այն ծրագրավորում ենք՝ օգտագործելով նույն Python-ը, shell-ը կամ SiLK-ում չներառված այլ գործիքներ:
• Փորձարկում. Այժմ հերթը հասնում է ստուգելու մեր վարկածի ճիշտությունը, որը հաստատվում կամ հերքվում է «rw», «set», «bag» տառերով սկսվող SiLK կոմունալ ծրագրերի միջոցով:
• Իրական տվյալների վերլուծություն. Արդյունաբերական շահագործման ժամանակ SiLK-ն օգնում է մեզ բացահայտել ինչ-որ բան, և վերլուծաբանը պետք է պատասխանի «Գտա՞նք այն, ինչ ակնկալում էինք», «Արդյո՞ք դա համապատասխանում է մեր վարկածին», «Ինչպե՞ս նվազեցնել կեղծ դրականների քանակը», «Ինչպե՞ս»: բարձրացնել ճանաչվածության մակարդակը» եւ այլն։
• Բարելավում. Վերջնական փուլում մենք բարելավում ենք այն, ինչ արվել է ավելի վաղ՝ ստեղծում ենք ձևանմուշներ, բարելավում և օպտիմալացնում ենք կոդը, վերակազմակերպում և պարզաբանում վարկածը և այլն։

Այս ցիկլը կիրառելի կլինի նաև Cisco Stealthwatch-ի համար, միայն վերջինն է առավելագույնս ավտոմատացնում այս հինգ քայլերը՝ նվազեցնելով վերլուծաբանների սխալների քանակը և բարձրացնելով միջադեպերի հայտնաբերման արդյունավետությունը: Օրինակ, SiLK-ում դուք կարող եք հարստացնել ցանցի վիճակագրությունը վնասակար IP-ների արտաքին տվյալներով՝ օգտագործելով ձեռքով գրված սկրիպտներ, իսկ Cisco Stealthwatch-ում դա ներկառուցված ֆունկցիա է, որն անմիջապես ցույց է տալիս ահազանգ, եթե ցանցային երթևեկությունը փոխազդեցություն է պարունակում սև ցուցակից IP հասցեների հետ:

Եթե ​​դուք գնում եք ավելի բարձր «վճարովի» բուրգի հոսքի վերլուծության ծրագրային ապահովման համար, ապա բացարձակապես անվճար SiLK-ից հետո կհայտնվի ELK-ը, որը բաղկացած է երեք հիմնական բաղադրիչներից՝ Elasticsearch (ինդեքսավորում, որոնում և տվյալների վերլուծություն), Logstash (տվյալների մուտքագրում/ելք): ) և Կիբանա (վիզուալիզացիա): Ի տարբերություն SiLK-ի, որտեղ դուք պետք է ամեն ինչ ինքներդ գրեք, ELK-ն արդեն ունի բազմաթիվ պատրաստի գրադարաններ/մոդուլներ (ոմանք վճարովի, ոմանք՝ ոչ), որոնք ավտոմատացնում են ցանցային հեռաչափության վերլուծությունը։ Օրինակ, GeoIP ֆիլտրը Logstash-ում թույլ է տալիս կապել վերահսկվող IP հասցեները նրանց աշխարհագրական դիրքի հետ (Stealthwatch-ն ունի այս ներկառուցված հատկությունը):

ELK-ն ունի նաև բավականին մեծ համայնք, որը լրացնում է մոնիտորինգի այս լուծման համար բացակայող բաղադրիչները: Օրինակ, Netflow-ի, IPFIX-ի և sFlow-ի հետ աշխատելու համար կարող եք օգտագործել մոդուլը elastiflow, եթե ձեզ չի բավարարում Logstash Netflow մոդուլը, որն աջակցում է միայն Netflow-ին։

Մինչդեռ ELK-ն ավելի մեծ արդյունավետություն է ապահովում հոսքի հավաքագրման և դրա մեջ որոնումների հարցում, ներկայումս չունի հարուստ ներկառուցված վերլուծություն՝ ցանցային հեռաչափության մեջ անոմալիաները և սպառնալիքները հայտնաբերելու համար: Այսինքն, հետևելով վերը նկարագրված կյանքի ցիկլին, դուք ստիպված կլինեք ինքնուրույն նկարագրել խախտումների մոդելները, այնուհետև օգտագործել այն մարտական ​​համակարգում (այնտեղ ներկառուցված մոդելներ չկան):

ELK-ի համար, իհարկե, կան ավելի բարդ ընդլայնումներ, որոնք արդեն պարունակում են ցանցային հեռաչափության անոմալիաների հայտնաբերման որոշ մոդելներ, բայց այդպիսի ընդլայնումները գումար են արժենում, և այստեղ հարցն այն է, թե արդյոք խաղը արժե՞ մոմը. ինքներդ գրեք նմանատիպ մոդել, գնեք այն: իրականացում ձեր մոնիտորինգի գործիքի համար, կամ գնել ցանցային տրաֆիկի վերլուծության դասի պատրաստ լուծում:

Ընդհանրապես, ես չեմ ուզում մտնել այն բանավեճի մեջ, որ ավելի լավ է գումար ծախսել և գնել պատրաստի լուծում ցանցային հեռաչափության անոմալիաների և սպառնալիքների մոնիտորինգի համար (օրինակ, Cisco Stealthwatch) կամ ինքներդ պարզել և հարմարեցնել նույնը: SiLK, ELK կամ nfdump կամ OSU Flow Tools յուրաքանչյուր նոր սպառնալիքի համար (ես խոսում եմ դրանցից վերջին երկուսի մասին ասաց Վերջին անգամ)? Ամեն մեկն ընտրում է իր համար, և յուրաքանչյուրն ունի իր շարժառիթներն ընտրելու երկու տարբերակներից որևէ մեկը: Պարզապես ուզում էի ցույց տալ, որ ցանցային հեռաչափությունը շատ կարևոր գործիք է ձեր ներքին ենթակառուցվածքի ցանցային անվտանգությունն ապահովելու համար, և դուք չպետք է անտեսեք այն, որպեսզի չմիանաք այն ընկերությունների ցանկին, որոնց անունը նշվում է լրատվամիջոցներում «էպիտետների հետ միասին»: կոտրված է», «չի համապատասխանում տեղեկատվական անվտանգության պահանջներին», «չմտածելով իրենց տվյալների և հաճախորդների տվյալների անվտանգության մասին»:

Ամփոփելու համար ես կցանկանայի թվարկել այն հիմնական խորհուրդները, որոնք դուք պետք է հետևեք ձեր ներքին ենթակառուցվածքի տեղեկատվական անվտանգության մոնիտորինգ կառուցելիս.

1. Մի սահմանափակեք ձեզ միայն պարագծով: Օգտագործեք (և ընտրեք) ցանցային ենթակառուցվածքը ոչ միայն երթևեկությունը A կետից B կետ տեղափոխելու, այլ նաև կիբերանվտանգության խնդիրները լուծելու համար:
2. Ուսումնասիրեք առկա տեղեկատվական անվտանգության մոնիտորինգի մեխանիզմները ձեր ցանցային սարքավորումներում և օգտագործեք դրանք:
3. Ներքին մոնիտորինգի համար նախապատվությունը տվեք հեռաչափական վերլուծությանը. այն թույլ է տալիս հայտնաբերել ցանցի տեղեկատվական անվտանգության բոլոր միջադեպերի մինչև 80-90%-ը՝ միաժամանակ անելով այն, ինչ անհնար է ցանցային փաթեթները գրավելիս և տարածք խնայելով տեղեկատվական անվտանգության բոլոր իրադարձությունները պահելու համար:
4. Հոսքերը վերահսկելու համար օգտագործեք Netflow v9 կամ IPFIX - դրանք ավելի շատ տեղեկատվություն են տրամադրում անվտանգության համատեքստում և թույլ են տալիս վերահսկել ոչ միայն IPv4, այլև IPv6, MPLS և այլն:
5. Օգտագործեք առանց նմուշի հոսքի արձանագրություն. այն ավելի շատ տեղեկատվություն է տրամադրում սպառնալիքների հայտնաբերման համար: Օրինակ, Netflow կամ IPFIX:
6. Ստուգեք ձեր ցանցային սարքավորումների ծանրաբեռնվածությունը. այն կարող է չկարողանալ կարգավորել նաև հոսքի արձանագրությունը: Այնուհետև մտածեք վիրտուալ սենսորների կամ Netflow Generation Appliance-ի օգտագործման մասին:
7. Կիրառեք հսկողություն առաջին հերթին մուտքի մակարդակում. սա ձեզ հնարավորություն կտա տեսնել ամբողջ տրաֆիկի 100%-ը:
8. Եթե ​​այլընտրանք չունեք և օգտագործում եք ռուսական ցանցային սարքավորումներ, ապա ընտրեք մեկը, որն աջակցում է հոսքի արձանագրություններին կամ ունի SPAN/RSPAN պորտեր:
9. Միավորել ներխուժման/հարձակման հայտնաբերման/կանխման համակարգերը ծայրերում և հոսքի վերլուծության համակարգերը ներքին ցանցում (ներառյալ ամպերում):

Վերջին հուշման վերաբերյալ ես կցանկանայի ներկայացնել մի օրինակ, որը ես արդեն տվել եմ նախկինում: Դուք տեսնում եք, որ եթե նախկինում Cisco տեղեկատվական անվտանգության ծառայությունը գրեթե ամբողջությամբ կառուցում էր իր տեղեկատվական անվտանգության մոնիտորինգի համակարգը ներխուժման հայտնաբերման համակարգերի և ստորագրության մեթոդների հիման վրա, ապա այժմ նրանց բաժին է ընկնում միջադեպերի միայն 20%-ը: Եվս 20% բաժին է ընկնում հոսքի վերլուծության համակարգերին, ինչը հուշում է, որ այդ լուծումները քմահաճույք չեն, այլ իրական գործիք ժամանակակից ձեռնարկության տեղեկատվական անվտանգության ծառայությունների գործունեության մեջ: Ավելին, դուք ունեք ամենակարևորը դրանց իրականացման համար՝ ցանցային ենթակառուցվածք, ներդրումներ, որոնցում կարելի է հետագայում պաշտպանել՝ ցանցին տեղեկատվական անվտանգության մոնիտորինգի գործառույթներ վերապահելով։

Ես կոնկրետ չեմ անդրադարձել ցանցային հոսքերում հայտնաբերված անոմալիաներին կամ սպառնալիքներին արձագանքելու թեմային, բայց կարծում եմ, որ արդեն պարզ է, որ մոնիտորինգը չպետք է ավարտվի միայն սպառնալիքի հայտնաբերմամբ։ Դրան պետք է հետևի պատասխան և գերադասելի է ավտոմատ կամ ավտոմատ ռեժիմով: Բայց սա առանձին հոդվածի թեմա է։

Լրացուցիչ տեղեկություններ:

• Cisco IOS Netflow-ի նկարագրությունը
• Netflow-ի աջակցության մատրիցա Cisco-ի տարբեր լուծումներում
• Cisco-ի տարբեր հարթակներում Netflow-ի կազմաձևման ուղեցույց
• sFlow համայնք
• Լաբորատորիա՝ օգտագործելով Stealtjwatch, SiLK և ELK՝ Netflow-ն անվտանգության տեսանկյունից վերլուծելու համար
• SiLK կայքը
• Երեք հարյուր էջանոց ուղեցույց SiLK-ի օգտագործման համար՝ տոննա օրինակներով
• Logstash Netflow մոդուլ
• Cisco-ի քայլ առ քայլ ուղեցույց ELK-ում ցանցային հոսքերի վերլուծության համար
• NetFlow v.9 Cisco ASA-ի վերլուծություն՝ օգտագործելով Logstash (ELK)
• Cisco Stealthwatch լուծում

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

Source: www.habr.com