Անցյալ հոդվածներում մենք մի փոքր ծանոթացանք elk հենքին և Logstash-ի կոնֆիգուրացիոն ֆայլի կարգավորմանը՝ լոգերի վերլուծության համար, այս հոդվածում անցե՜լ ենք մի առավել կարևոր քայլի, որը կապված է վերլուծության հետ, այն, ինչ ցանկանում եք տեսնել համակարգից, և ինչի համար դա ամեն ինչ ստեղծվել է՝ գրաֆիկներ և աղյուսակներ, որոնք միացված են դաշբորդներին։ Այսօր մենք ավելի մերձենում ենք տեսողական համակարգին Kibana։ կքննարկենք, թե ինչպես ստեղծել գրաֆիկներ, աղյուսակներ, և վերջում կառուցենք մի պարզ դաշбորդ Check Point-ի.Firewall-ին առնչվող լոգերի հիման վրա։
Kibana-ի հետ աշխատանքի առաջին քայլը՝ ստեղծել index pattern-֊ը։ որը տրամաբանական է, որ թվային դիտարկման բազան նախագծել է ընդհանուր հիմքի վրա։ Հասկանում եմ, որ դա բացառապես կարգավորում է, որպեսզի Kibana-ն ավելի հարմարավետ որոնի տեղեկատվությունը բոլոր ինդեքսներում միաժամանակ։ Սա սահմանվում է տողը համեմատելով, ասենք "checkpoint-*" և ինդեքսի անվան հետ։ Օրինակ ՝ «checkpoint-2019.12.05» համապատասխանում է ձևաչափին, իսկ պարզապես «checkpoint»-ը արդեն ոչ։ Իհարկե, պետք է նշել, որ տարբեր ինդեքսների ձևաչափերով տեղեկատվություն որոնել հնարավոր չէ, մի քիչ ուշ, հաջորդ հոդվածներում մենք կտեսնենք, որ API հարցումները իրականացվում են ինչպես ինդեքսի անվան հիման վրա, այնպես էլ հենց մեկ տողային ձևաչափով, նկարը կտտացման է ենթակա՝
Հետո մենք ստուգում ենք Discover մենյուում, որ բոլոր լոգերն ինդեքսավորվում են, և ճիշտ կարգավորիչ է։ Եթե հայտնվեն որևէ անհամապատասխանություններ, օրինակ, տվյալների տեսակն անցսել լոգից ամբողջ թվի, անհրաժեշտ կլինի խմբագրել Logstash-ի կոնֆիգուրացիոն ֆայլը, արդյունքում նոր լոգերը գրանցվելու են ճիշտ։ Այն բանի համար, որպեսզի հին լոգերը նախ փոփոխության ժամանակ ձեռք բերեն անհրաժեշտ ձևաչափ, օգնում է միայն վերին ինդեքսավորման գործընթացը, հաջորդ հոդվածներում այս գործողությունը ավելի մանրամասն կքննարկվի։ Վստահեցնենք, որ ամեն ինչ կարգին է, նկարը կտտացման է ենթակա՝
Լոգերը վայրում են, նշանակում է, որ կարելի է սկսել դաշբորդների կառուցումը։ Անվտանգության արտադրությունների դաշբորդների վերլուծության հիման վրա կարելի է հասկանալ կազմակերպության ԻԲ-ի վիճակը, տեսողական կերպով տեսնել ներկայիս քաղաքականության թույլ տեղերը և հետագայում մշակել դրանց վերացման միջոցներ։ Կառուցենք մի փոքր դաշբորդ, օգտագործելով մի քանի տեսողական միջոցներ։ Դաշբորդը կընդգրկի 5 բաղադրիչ.
- լոգերի ընդհանուր քանակի հաշվարկի աղյուսակ՝ բլեյդների համար
- կարգահարման աղյուսակ՝ կարևոր թվանշանների IPS-ով
- ուղեկցող աղյուսակ՝ Threat Prevention- ի դեպքերին
- գրաֆիկ՝ ամենատարածված այցելվող կայքերին
- գրաֆիկ՝ ամենավտանգավոր ծրագրերի օգտագործման մասին
Տեսողական ձևերի ստեղծման համար անհրաժեշտ է անցնել Visualize։ և ընտրեք այն ձևը, որը ցանկանում ենք կառուցել։ Գնանք հերթով։
Լոգերի ընդհանուր քանակի հաշվարկի աղյուսակ՝ բլեյդների համար
Նրա համար ընտրենք ձևը Data Table, մենք անցնում ենք գրաֆիկների ստեղծման գործիքակազմին, կողքին նշվում են ձևի կարգավորումները, աջում այն, թե ինչպես է այն տեսանելի ներկա կարգավորումներով: Նախ ցույց կտամ, թե պատրաստիկ աղյուսակը ինչպիսի տեսք ունի, և հետո անցնելու ենք կարգավորումներին, պատկերն է կտտոցով قابل انتخاب:
Ամենա մանրակրկիտ ձևի կարգավորումները, պատկերն է կտտոցով قابل انتخاب:
Գլուխ ենք առնում կարգավորումների:
Առաջին հերթին կարգավորում ենք մետրիկա, սա այն արժեքն է, որի շուրջ կհավաքվեն բոլոր դաշտերը: Մետրիկաներ հաշվարկվում են փաստաթղթերից տարբեր եղանակներով վերարտադրված արժեքների հիման վրա: Արժեքները սովորաբար վերարտադրվում են դաշտերից փաստաթղթի, բայց կարող են նաև ստեղծվել սցենարներով: Այս դեպքում դնում ենք Aggregation: Count (լոգերի ընդհանուր քանակը).
Հետագայում բաժանում ենք աղյուսակը հատվածներով (դաշտերով), որոնց վրա կկատարվի մետրիկայի հաշվարկը: Այս գործառույթը կատարում է Buckets կարգավորումը, որը իր հերթին բաղկացած է 2 տարբերակներից:
- split rows — սյուների ավելացում և հետագայում աղյուսակի բաժանում տողերի վրա
- split table — բաժանում մի քանի աղյուսակների ըստ որոշակի դաշտի արժեքների:
Մեույն buckets կարող են ավելացվել մի քանի բաժանումներ մի քանի սյուներ կամ աղյուսակներ ստեղծելու համար, այստեղ սահմանափակումները հիմնականում տրամաբանական են: Aggregation-ում կարող եք ընտրել, թե որ եղանակով կկատարվի բաժանումը հատվածներին: ipv4 range, date range, Terms և այլն: Ամենակողմնատու ընտրությունը հենց Terms և Significant Terms, բաժանումները կատարվում են հատուկ պարտքի հիմքով, տարբերությունը նրանց միջև է վերադարձվող արժեքների քանակը և դրանց ցուցադրումը: Քանի որ ցանկանում ենք բաժանել աղյուսակը բլեյդների ըստ անվան, ընտրում ենք դաշտը — product.keyword և սահմանում ենք չափը 25 վերադարձվող արժեքների մեջ:
Elasticsearch-ում տողերի փոխարեն օգտագործվում են 2 տիպի տվյալներ — text և keyword. Եթե ցանկանում եք կատարել ամբողջական տեքստի որոնում, պետք է օգտագործեք text տիպը, շատ հարմար բան է ձեր որոնման ծառայությունը մշակելու պահին, օրինակ, որոնում եք որևէ բառի բացատրություն որոշակի դաշտի (ոչթեքստին) մեջ: Եթե ցանկանում եք միայն ճշգրիտ համապատասխանություն, պետք է օգտագործեք keyword տիպը: Այդպես keyword տվյալների տիպը պետք է օգտագործել այն դաշտերի համար, որոնք պահանջում են դասակարգում կամ ագրեգացում, այսինքն, մեր դեպքում:
Արդյունքում Elasticsearch-ը հաշվում է լոգերի քանակը որոշակի ժամանակահատվածի համար՝ ագրեգացմամբ product դաշտի արժեքի շուրջ: Custom Label-ում սահմանում ենք տողակի անունը, որը կցուցադրվի աղյուսակում, սահմանում ենք ժամանակը, որի համար հավաքում ենք լոգերը, սկսում ենք ձևավորումն — Kibana-ն հարցում է ուղարկում elasticsearch-ին, սպասում պատասխանի և հետո տեսնում ստացված տվյալները: Աղյուսակը պատրաստ է!
Իրավիճքների Threat Prevention-ի շուրջ հյուսված շրջանակային գծապատկեր
Հետաքրքիր տեղեկատվություն է, իսկ որքանով է իրականում տոկոսային հարաբերակցության արձագանքները detect և prevent մասնավորապես և անվտանգության քաղաքականությունում: Այս դեպքում լավ է ձեռնարկել շրջանային գրաֆիկ: Ընտրեք Visualize — Շրջանային գրաֆիկ. Նախ, մետրիկայում սահմանում ենք ագրեգացումը լոգերի քանակով: buckets-ում դնում ենք Terms => action.
Գուցե ամեն ինչ ճիշտ է, բայց արդյունքում ցույց են տրվում արժեքներ բոլոր բլեյդների համար, անհրաժեշտ է ֆիլտրել միայն այն բլեյդներին, որոնք աշխատում են Threat Prevention ռազմավարության շրջանակներում: Այդ իսկ պատճառով unbedingt կարգավորում ենք ֆիլտր մենք պետք է որոնենք միայն այն բլեյդների համար, որոնք պատասխանատու են անվտանգության իրադարձությունների համար — product: («Anti-Bot» OR «New Anti-Virus» OR «DDoS Protector» OR «SmartDefense» OR «Threat Emulation»). Նկարը կտտամանալի է:
Եվ ավելի մանրամասն կարգավորումներ, նկարը կտտամանալի է:
IPS իրադարձությունների աղյուսակ
Այդուհետև անվտանգության պաշտպանության տեսանկյունից շատ կարևորն է բլեյդի իրադարձությունների դիտարկումն ու ստուգել IPS և Threat Emulation, որոնք չեն արգելափակվում 当前 շարունակվող քաղաքականությամբ, որպեսզի հետագայում կամ անցնեն ստորագրությունը կանխարգելման, կամ եթե երթևեկությունը վալիդ է — չստուգել ստորագրությունը: Նկարը ստեղծում ենք նույնպես ինչպես առաջին օրինակին, սակայն մի տարբերությամբ, որ ստեղծում ենք մի քանի սյուներ: protections.keyword, severity.keyword, product.keyword, originsicname.keyword: Անհրաժեշտ է կարգավորել ֆիլտր այն բլեյդների համար, որոնք պատասխանատու են անվտանգության իրադարձություններին — product: ( «SmartDefense» OR «Threat Emulation»). Նկարը կտտամանալի է:
Մանրամասների կարգավորումներ, նկարը կտտամանալի է:
Անվտանգության առավել հաճախ այցելվող կայքերի մասին գրաֆիկներ
Այս նպատակով մենք ստեղծում ենք ֆիգուր — Vertical Bar. Մետրիկան նույնպես օգտագործում ենք count (Y առանցք), իսկ X առանցքում որպես արժեքներ կօգտագործենք այցելված կայքերի անունները — “appi_name”. Այստեղ կա մի փոքր հնարք, եթե ներկայիս տարբերակում մեկնարկել настройки, ապա բոլոր կայքերը նշվելու են գրաֆիկում մեկ գույնով, որպեսզի դրանք բազմագույն դարձնել, օգտագործում ենք լրացուցիչ կարգավորում — “split series”, որը թույլ է տալիս բաժանել արդեն պատրաստ սյունը ևս մի քանի արժեքների, ըստ ընտրվող դաշտի, իհարկե! Այս բաժանման դեպքում կարող ենք օգտագործել որպես մեկ բազմագույն սյուն` stacked ռեժիմում, կամ normal ռեժիմում, որպեսզի ստեղծենք մի քանի սյուներ ըստ X առանցքի որոշակի արժեքի: Այս դեպքում այստեղ մենք օգտագործում ենք նույն արժեքը, ինչ X առանցքում, դա հնարավորություն է տալիս բոլոր սյուները բազմագույն դարձնել, վերևի աջ կողմում դրանք կնշվեն գույներով: Ֆիլտրում սահմանում ենք — product:«URL Filtering», որպեսզի տեսնենք միայն այցելված կայքերի մասին տեղեկատվությունը, նկարը կտտամանալի է:
Կարգավորումներ:
Անվտանգության առավել վտանգավոր ծրագրերի օգտագործման գրաֆիկ
Այս ընթացքում ստեղծում ենք Vertical Bar տեսակը։ Մենք также օգտագործում ենք count (Y 축), իսկ X 축ի համար որպես արժեքներ կիրառում ենք օգտագործվող ծրագրերի անունները՝ "appi_name"։ Այն ամենակարևորն է, որ սահմանում ենք ֆիլտրը՝ product: «Application Control» AND app_risk: (4 OR 5 OR 3) AND action:«accept»։ Ֆիլտրում ենք Application control բլեյդի տարեկաները, վերցնում ենք միայն այն կայքերը, որոնք դասավորված են որպես կայքեր, որոնք ունեն Critical, High, Medium ռիսկ և միայն այն դեպքում, եթե այդ կայքերին հասանելիություն է տրամադրված։ Պատկերն ակտիվ է:
Ն ustawки, ակտիվ է:
Դաշբորդ
Դաշբորդների դիտումը և ստեղծումը գոյություն ունի առանձին ընտրացանկում՝ Dashboard. Այստեղ ամեն ինչ պարզ է, ստեղծվում է նոր դաշբորդ, ավելացվում է визуализация, տեղադրվում է ըստ վայրերի և ողջորա!
Ստեղծենք դաշբորդ, որով կարող ենք հասկանալ կազմակերպության ԱՀ կանոնների հիմնական վիճակը, բնականաբար, միայն Check Point մակարդակում, պատկերն ակտիվ է:
Այս գրառումների հիման վրա կարող ենք հասկանալ, թե որոնք են քրիտիկական սիգնատուրաները, որոնք չեն արգելափակվում միջնախագծի էկրանին, որտեղ են հետևում օգտվողները, որոնք են ամենավտանգավոր ծրագրերը, որոնք նրանք օգտագործում են:
Ավարտ
Մենք դիտեցինք Kibana-ի հիմնական визуալիզացիաների ունակությունները և ստեղծեցինք դաշբորդ, բայց սա ընդամենը փոքր մասն է։ Դասընթացի մեջ մենք առանձնապես կքննարկենք քարտերի կարգավորումները, աշխատանքի հետ elasticsearch համակարգի հետ, ծանոթանանք API հարցումներին, ավտոմատացմանն ու շատ այլ բաներ!
Հետևեք թարմացումներին (, , , ), .
Ընտանիք: habr.com
