Check Point. CPU-ի և RAM-ի օպտիմիզացում

Բարև գործընկերներ: Այսօր ես կցանկանայի շատ կարևոր թեմա քննարկել Check Point-ի շատ ադմինիստրատորների համար՝ «CPU-ի և RAM-ի օպտիմիզացում»: Հաճախ լինում են դեպքեր, երբ gateway-ը և/կամ կառավարման սերվերը անսպասելիորեն սպառում են այդ ռեսուրսներից շատերը, և ես կցանկանայի հասկանալ, թե որտեղ են դրանք «հոսում» և, հնարավորության դեպքում, օգտագործել դրանք ավելի խելացի։

1. Վերլուծություն

Պրոցեսորի ծանրաբեռնվածությունը վերլուծելու համար օգտակար է օգտագործել հետևյալ հրամանները, որոնք մուտքագրվում են փորձագիտական ​​ռեժիմում.

վերեւ ցույց է տալիս բոլոր գործընթացները, սպառված պրոցեսորի և օպերատիվ հիշողության ռեսուրսների քանակը՝ որպես տոկոս, գործարկման ժամանակը, գործընթացի առաջնահերթությունը և այլ իրական ժամանակումи

cpwd_admin ցուցակ Ստուգեք Point WatchDog Daemon-ը, որը ցույց է տալիս հավելվածի բոլոր մոդուլները, դրանց PID-ը, կարգավիճակը և մեկնարկների քանակը

cpstat -f cpu os CPU-ի օգտագործումը, դրանց քանակը և պրոցեսորի ժամանակի բաշխումը տոկոսով

cpstat -f հիշողություն OS վիրտուալ RAM-ի օգտագործում, որքան ակտիվ, անվճար RAM և այլն

Ճիշտ դիտողությունն այն է, որ բոլոր cpstat հրամանները կարելի է դիտել կոմունալ ծրագրի միջոցով cpview. Դա անելու համար պարզապես անհրաժեշտ է մուտքագրել cpview հրամանը SSH նիստի ցանկացած ռեժիմից:

ps auxf բոլոր գործընթացների երկար ցուցակը, դրանց ID-ն, օկուպացված վիրտուալ հիշողությունը և հիշողությունը RAM-ում, CPU-ում

Հրամանների այլ տատանումներ.

ps-aF ցույց կտա ամենաթանկ գործընթացը

fw ctl մերձավորություն -l -a միջուկների բաշխում տարբեր firewall օրինակների համար, այսինքն՝ CoreXL տեխնոլոգիա

fw ctl pstat RAM-ի վերլուծություն և ընդհանուր կապի ցուցիչներ, թխուկներ, NAT

ազատ -մ RAM բուֆեր

Թիմն արժանի է հատուկ ուշադրության netsat և դրա տատանումները: Օրինակ, նեթստատ -ի կարող է օգնել լուծել սեղմատախտակների մոնիտորինգի խնդիրը: Այս հրամանի ելքում RX-ի բաց թողնված փաթեթներ (RX-DRP) պարամետրը, որպես կանոն, ինքնուրույն աճում է անօրինական արձանագրությունների կաթիլների պատճառով (IPv6, Bad / Unintended VLAN պիտակներ և այլն): Այնուամենայնիվ, եթե կաթիլները տեղի են ունենում այլ պատճառով, ապա դուք պետք է օգտագործեք սա հոդվածներսկսել ուսումնասիրել և հասկանալ, թե ինչու է տվյալ ցանցային ինտերֆեյսը թողնում փաթեթները: Պատճառը պարզելուց հետո հավելվածի աշխատանքը կարող է նաև օպտիմիզացվել։

Եթե ​​մոնիտորինգի սայրը միացված է, դուք կարող եք գրաֆիկորեն դիտել այս չափումները SmartConsole-ում՝ սեղմելով օբյեկտի վրա և ընտրելով «Սարքի և լիցենզիայի մասին տեղեկություններ»:

Խորհուրդ չի տրվում մշտական ​​հիմունքներով միացնել Մոնիտորինգի սայրը, բայց թեստավորման համար մեկ օրվա ընթացքում դա միանգամայն հնարավոր է:

Ավելին, դուք կարող եք ավելացնել ավելի շատ պարամետրեր մոնիտորինգի համար, որոնցից մեկը շատ օգտակար է` Bytes Throughput (կիրառման թողունակություն):

Եթե ​​կա մոնիտորինգի այլ համակարգ, օրինակ՝ անվճար Zabbix- ը, հիմնվելով SNMP-ի վրա, այն նաև հարմար է այս խնդիրները բացահայտելու համար:

2. RAM-ը ժամանակի ընթացքում արտահոսում է

Հաճախ հարց է առաջանում, որ ժամանակի ընթացքում դարպասը կամ կառավարման սերվերը սկսում են ավելի ու ավելի շատ RAM սպառել: Ես ուզում եմ ձեզ հանգստացնել. սա սովորական պատմություն է Linux-ի նման համակարգերի համար:

Նայելով հրամանների ելքին ազատ -մ и cpstat -f հիշողություն OS հավելվածում փորձագիտական ​​ռեժիմից կարող եք հաշվարկել և դիտել RAM-ի հետ կապված բոլոր պարամետրերը:

Այս պահին դարպասի վրա առկա հիշողության հիման վրա Ազատ հիշողություն + Բուֆերային հիշողություն + Քեշավորված հիշողություն = +-1.5 ԳԲ, սովորաբար.

Ինչպես ասում է CP-ն, ժամանակի ընթացքում gateway/management սերվերը օպտիմիզացնում և օգտագործում է ավելի ու ավելի շատ հիշողություն՝ հասնելով մոտ 80% օգտագործման և կանգ է առնում։ Դուք կարող եք վերագործարկել սարքը, այնուհետև ցուցիչը կզրոյացվի: 1.5 ԳԲ ազատ օպերատիվ հիշողությունը բավական է, որպեսզի դարպասը կատարի բոլոր առաջադրանքները, և կառավարումը հազվադեպ է հասնում նման սահմանային արժեքների:

Նաև նշված հրամանների ելքերը ցույց կտան, թե որքան ունեք Ցածր հիշողություն (RAM-ը օգտագործողի տարածքում) և Բարձր հիշողություն (RAM միջուկի տարածքում) օգտագործվում է:

Միջուկային գործընթացները (ներառյալ ակտիվ մոդուլները, ինչպիսիք են Check Point միջուկի մոդուլները) օգտագործում են միայն ցածր հիշողություն: Այնուամենայնիվ, օգտագործողի գործընթացները կարող են օգտագործել ինչպես ցածր, այնպես էլ բարձր հիշողություն: Ավելին, ցածր հիշողությունը մոտավորապես հավասար է Ընդհանուր հիշողություն.

Դուք պետք է անհանգստանաք միայն այն դեպքում, եթե գրանցամատյաններում սխալներ կան «Մոդուլները վերագործարկվում են կամ գործընթացները սպանվում են OOM-ի պատճառով հիշողությունը վերականգնելու համար (հիշողությունից դուրս)». Այնուհետև դուք պետք է վերաբեռնեք դարպասը և կապվեք աջակցության հետ, եթե վերաբեռնումը չի օգնում:

Ամբողջական նկարագրությունը կարելի է գտնել sk99547 и sk99593.

3. Օպտիմալացում

Ստորև ներկայացված են CPU-ի և RAM-ի օպտիմալացման վերաբերյալ հարցեր և պատասխաններ: Դուք պետք է անկեղծորեն պատասխանեք դրանց ինքներդ ձեզ և լսեք առաջարկությունները:

3.1. Հավելվածը ճի՞շտ է ընտրվել։ Կա՞ պիլոտային նախագիծ:

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

3.2. HTTPS ստուգումը միացվա՞ծ է: Եթե ​​այո, արդյո՞ք տեխնոլոգիան կազմաձևված է լավագույն փորձի համաձայն:

Վերաբերել հոդված, եթե դուք մեր հաճախորդն եք, կամ sk108202.

HTTPS-ի ստուգման քաղաքականության կանոնների կարգը մեծ դեր է խաղում HTTPS կայքերի բացման օպտիմալացման գործում:

Կանոնների առաջարկվող հերթականությունը.

1. Շրջանցեք կանոնները կատեգորիաներով/URL-ներով
2. Ստուգեք կանոնները կատեգորիաներով/URL-ներով
3. Ստուգեք բոլոր մյուս կատեգորիաների կանոնները

Համեմատելով firewall քաղաքականության հետ՝ Check Point-ը որոնում է փաթեթների համընկնում վերևից ներքև, ուստի ավելի լավ է վերևում տեղադրել շրջանցման կանոնները, քանի որ դարպասը չի վատնի ռեսուրսները բոլոր կանոններով անցնելու համար, եթե այս փաթեթը կարիք ունենա: անցնելու.

3.3 Արդյո՞ք օգտագործվում են հասցեների միջակայքի օբյեկտներ:

Հասցեների տիրույթ ունեցող օբյեկտները, օրինակ՝ 192.168.0.0-192.168.5.0 ցանցը, զգալիորեն ավելի շատ օպերատիվ հիշողություն են զբաղեցնում, քան ցանցի 5 օբյեկտները: Ընդհանուր առմամբ, SmartConsole-ում չօգտագործված օբյեկտները հեռացնելը համարվում է լավ պրակտիկա, քանի որ ամեն անգամ, երբ քաղաքականությունը տեղադրվում է, gateway-ը և կառավարման սերվերը ծախսում են ռեսուրսներ և, ամենակարևորը, ժամանակ՝ ստուգելով և կիրառելով քաղաքականությունը:

3.4. Ինչպե՞ս է կազմաձևվում սպառնալիքների կանխարգելման քաղաքականությունը:

Առաջին հերթին Check Point-ը խորհուրդ է տալիս տեղադրել IPS-ը առանձին պրոֆիլում և ստեղծել առանձին կանոններ այս սայրի համար։

Օրինակ, ադմինիստրատորը կարծում է, որ DMZ հատվածը պետք է պաշտպանված լինի միայն IPS-ի միջոցով: Հետևաբար, կանխելու համար, որ դարպասը ռեսուրսներ վատնի այլ շեղբերով փաթեթների մշակման վրա, անհրաժեշտ է ստեղծել կանոն հատուկ այս հատվածի համար՝ պրոֆիլով, որում միացված է միայն IPS-ը:

Ինչ վերաբերում է պրոֆիլների տեղադրմանը, ապա խորհուրդ է տրվում այն ​​կարգավորել լավագույն փորձի համաձայն փաստաթուղթը(էջ 17-20):

3.5. IPS կարգավորումներում քանի՞ ստորագրություն կա Detect ռեժիմում:

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

3.6. Ի՞նչ ֆայլեր են մշակվում Threat Emulation, Threat Extraction, Anti-Virus blades-ի միջոցով:

Անիմաստ է ընդօրինակել և վերլուծել ընդարձակման ֆայլերը, որոնք ձեր օգտատերերը չեն ներբեռնում, կամ դուք համարում եք ձեր ցանցում ավելորդ (օրինակ, bat, exe ֆայլերը կարող են հեշտությամբ արգելափակվել՝ օգտագործելով Content Awareness blade-ը firewall-ի մակարդակում, ուստի ավելի քիչ դարպաս: միջոցները կծախսվեն): Ավելին, Threat Emulation կարգավորումներում կարող եք ընտրել Environment (օպերացիոն համակարգ)՝ ավազարկղում սպառնալիքները նմանակելու համար, իսկ Environment Windows 7-ի տեղադրումը, երբ բոլոր օգտվողներն աշխատում են 10 տարբերակով, նույնպես իմաստ չունի:

3.7. Արդյո՞ք firewall-ի և հավելվածի մակարդակի կանոնները դասավորված են լավագույն փորձին համապատասխան:

Եթե ​​կանոնն ունի շատ հարվածներ (համընկնումներ), ապա խորհուրդ է տրվում դրանք դնել ամենավերևում, իսկ փոքր թվով հիթերի կանոնները՝ ամենաներքևում: Հիմնական բանը ապահովելն է, որ դրանք միմյանց չհատվեն կամ չհամընկնեն: Առաջարկվող firewall քաղաքականության ճարտարապետություն.

Բացատրություններ.

Առաջին կանոններ - այստեղ տեղադրված են ամենաշատ համընկնումներ ունեցող կանոնները
Աղմուկի կանոն - NetBIOS-ի նման կեղծ թրաֆիկը հեռացնելու կանոն
Գաղտնիության կանոն - արգելում է բոլորի կողմից դեպի դարպասներ և կառավարում զանգեր կատարել, բացառությամբ այն աղբյուրների, որոնք նշված են եղել Gateway-ի վավերացման կանոններում:
Մաքրման, վերջին և թողարկման կանոնները սովորաբար միավորվում են մեկ կանոնում՝ արգելելու այն ամենը, ինչ նախկինում թույլատրված չէր:

Լավագույն պրակտիկայի տվյալները նկարագրված են sk106597.

3.8. Ի՞նչ կարգավորումներ ունեն ադմինիստրատորների կողմից ստեղծված ծառայությունները:

Օրինակ, որոշ TCP ծառայություն ստեղծվում է որոշակի նավահանգստի վրա, և իմաստ ունի ծառայության Ընդլայնված կարգավորումներում հեռացնել «Համապատասխանություն ցանկացածի համար» նշումը: Այս դեպքում այս ծառայությունը կհայտնվի հատուկ կանոնների ներքո, որոնցում այն ​​հայտնվում է, և չի մասնակցի այն կանոններին, որտեղ Any-ը նշված է Ծառայություններ սյունակում:

Խոսելով ծառայությունների մասին՝ հարկ է նշել, որ երբեմն անհրաժեշտ է լինում կարգավորել թայմաութները։ Այս պարամետրը թույլ կտա ձեզ խելամտորեն օգտագործել gateway-ի ռեսուրսները, որպեսզի լրացուցիչ ժամանակ չպահեք արձանագրությունների TCP/UDP նիստերի համար, որոնք մեծ ժամանակի դադար չեն պահանջում: Օրինակ, ստորև ներկայացված սքրինշոթում ես փոխել եմ տիրույթի-udp ծառայության ժամկետը 40 վայրկյանից մինչև 30 վայրկյան:

3.9. Օգտագործվա՞ծ է SecureXL-ը և որքա՞ն է արագացման տոկոսը:

Դուք կարող եք ստուգել SecureXL-ի որակը՝ օգտագործելով հիմնական հրամանները փորձագիտական ​​ռեժիմում դարպասի վրա fwaccel վիճակագրություն и fw accel stats -s. Հաջորդը, դուք պետք է պարզեք, թե ինչպիսի տրաֆիկ է արագացվում, և ինչ այլ ձևանմուշներ կարելի է ստեղծել:

Drop Templates-ը լռելյայն միացված չէ, դրանց ակտիվացումը կշահի SecureXL-ին: Դա անելու համար անցեք դարպասի կարգավորումներ և «Օպտիմիզացումներ» ներդիր.

Նաև պրոցեսորի օպտիմալացման համար կլաստերի հետ աշխատելիս կարող եք անջատել ոչ կարևոր ծառայությունների համաժամացումը, ինչպիսիք են UDP DNS, ICMP և այլն: Դա անելու համար անցեք ծառայության կարգավորումներ → Ընդլայնված → Համաժամեցեք կապերը, կլաստերի վրա միացված է վիճակի համաժամացումը:

Բոլոր լավագույն փորձերը նկարագրված են sk98348.

3.10. Ինչպե՞ս է օգտագործվում CoreXl-ը:

CoreXL տեխնոլոգիան, որը թույլ է տալիս օգտագործել բազմաթիվ պրոցեսորներ firewall-ի օրինակների համար (firewall մոդուլներ), միանշանակ օգնում է օպտիմիզացնել սարքի աշխատանքը: Առաջին թիմը fw ctl մերձավորություն -l -a ցույց կտա օգտագործված firewall-ի օրինակները և SND-ին հատկացված պրոցեսորները (մոդուլ, որը բաշխում է տրաֆիկը firewall-ի սուբյեկտներին): Եթե ​​ոչ բոլոր պրոցեսորներն են օգտագործվում, ապա դրանք կարող են ավելացվել հրամանով cpconfig դարպասի մոտ.
Նաև լավ պատմություն է դնելու թեժ ուղղում Multi-Queue-ը միացնելու համար: Multi-Queue-ն լուծում է խնդիրը, երբ SND-ով պրոցեսորն օգտագործվում է շատ տոկոսով, իսկ այլ պրոցեսորների վրա firewall-ի օրինակները անգործուն են: Այնուհետև SND-ը հնարավորություն կունենա ստեղծել բազմաթիվ հերթեր մեկ NIC-ի համար և սահմանել տարբեր առաջնահերթություններ միջուկի մակարդակում տարբեր տրաֆիկի համար: Հետևաբար, պրոցեսորի միջուկները կօգտագործվեն ավելի խելացի։ Մեթոդները նույնպես նկարագրված են sk98348.

Եզրափակելով, ես կցանկանայի ասել, որ սրանք բոլորը չեն Check Point-ի օպտիմալացման լավագույն փորձը, բայց դրանք ամենատարածվածն են: Եթե ​​ցանկանում եք պատվիրել ձեր անվտանգության քաղաքականության աուդիտ կամ լուծել Check Point-ի հետ կապված խնդիրը, դիմեք [էլեկտրոնային փոստով պաշտպանված].

Շնորհակալություն ձեր ուշադրության համար:

Source: www.habr.com