Po azhurnojmë Check Point nga R77.30 në 80.20

Në vjeshtën e vitit 2019, Check Point ndërpreu mbështetjen për versionet R77.XX dhe u bë i domosdoshëm përditësimi. Për dallimet midis versioneve, si dhe për avantazhet dhe disavantazhet e kalimit në R80, është folur tashmë mjaft. Më mirë të shohim se si të përditësohen në praktikë appliance-et virtuale Check Point (CloudGuard for VMware ESXi, Hyper-V, KVM Gateway NGTP) dhe çfarë mund të shkojë keq.

Pra, kishim 2 inxhinierë CCSE, më shumë se një duzinë klasterësh virtualë Check Point R77.30, disa cloud, pak hotfix-e dhe një det të tërë bug-esh, glitch-esh e problemesh të ndryshme, në çdo formë e madhësi, plus afate shumë të ngushta. Le t'ia nisim!

Përmbajtja:

Përgatitja
Përditësojmë serverin e menaxhimit
Përditësojmë klasterin

Kështu duket një infrastrukturë tipike cloud e klientit me Check Point virtual

Përgatitja

Së pari, duhet të kontrolloni nëse burimet janë të mjaftueshme për përditësimin. Kërkesat minimale të rekomanduara për R80.20 aktualisht janë këto:

Pajisja

CPU

RAM

HDD

Security Gateway

2 bërthama

4 Gb

Nga 15 GB

SMS

2 bërthama

6 Gb

—

Rekomandimet përshkruhen në dokumentin CP_R80.20_GA_Release_Notes.

Por le të jemi realistë. Nëse për konfigurimin minimal kjo mjafton, praktika tregon se zakonisht kemi të aktivizuar inspektimin HTTPS, në SMS funksionon SmartEvent etj., gjë që natyrisht kërkon kapacitete krejt të tjera. Megjithatë, në përgjithësi jo më të mëdha se për R77.30.

Por ka disa nuanca. Dhe ato lidhen, para së gjithash, me madhësinë e memories fizike. Shumë operacione gjatë vetë procesit të përditësimit do të kërkojnë hapësirë në disk.

Për serverin e menaxhimit, sasia e hapësirës së lirë në disk do të varet shumë nga vëllimi i log-eve aktuale (nëse dëshirojmë t'i ruajmë) dhe nga numri i Database Revisions të ruajtura, megjithëse nuk do të na duhen më në sasi të mëdha. Natyrisht, për nyjet e klasterit (përveç rastit kur ruani log-et edhe lokalisht) kjo nuk ka rëndësi. Ja si mund të kontrolloni nëse ka hapësirën e nevojshme:

1. Lidhemi me Smart Management Server përmes SSH, hyjmë në expert mode dhe ekzekutojmë komandën:

   [Expert@cp-sms:0]# df -h

2. Në dalje do të shohim afërsisht një konfigurim të tillë:

   Filesystem Size Used Avail Use% Mounted on
   /dev/mapper/vg_splat-lv_current       30G  7.4G   21G 27% /
   /dev/sda1             289M 24M 251M 9% /boot
   tmpfs 2.0G 0 2.0G 0% /dev/shm
   /dev/mapper/vg_splat-lv_log           243G  177G 53G  78% /var/log

3. Për momentin, na intereson ndarja /var/log

Mbani parasysh se, në varësi të politikës së ruajtjes dhe fshirjes së skedarëve të vjetër të log-eve, si edhe madhësisë së bazës së të dhënave që eksportohet, mund të nevojitet më shumë hapësirë. Nëse gjatë krijimit të arkivit hapësira e lirë bie nën vlerën e përcaktuar në politikën e ruajtjes së skedarëve të log-eve, sistemi do të nisë të fshijë log-et e vjetra dhe NUK do t'i përfshijë ato në arkiv.

Gjithashtu, për vetë procesin e përditësimit sistemit do t'i duhen të paktën 13 GB hapësirë e pacaktuar në diskun e ngurtë. Prania e saj mund të kontrollohet me komandën:

[Expert@cp-sms:0]# pvs

Do të shohim afërsisht një dalje të tillë:

PV     VG   Fmt  Attr PSize   PFree
/dev/sda3  vg_splat lvm2 a-   141.69G 43.69G

Në këtë rast kemi 43 GB. Burimet janë të mjaftueshme. Mund të fillojmë përditësimin.

Përditësojmë serverin e menaxhimit Check Point SMS

Para fillimit të punës duhet të bëni sa vijon:

1. Instalojmë paketën Migration Tools në serverin e menaxhimit. Për këtë duhet të shkarkoni imazhin nga portali Check Point.
2. Ngarkojmë arkivin në serverin e menaxhimit përmes WinSCP në dosjen /var/log/UpgradeR77.30_R80.20 (nëse është e nevojshme, krijoni paraprakisht dosjen).
3. Lidhemi me serverin e menaxhimit përmes SSH dhe kalojmë në dosjen me arkivin:cd /var/log/UpgradeR77.30_R80.20/
4. Çarkivojmë skedarin:tar -zxvf ./.tgz
5. Nisim mjetin pre_upgrade_verifier me komandën: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
6. Pas ekzekutimit të komandës do të krijohet një raport mbi cilësimet e papajtueshme. Ai është i disponueshëm në adresën: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Është më e përshtatshme ta shkarkoni përmes SCP dhe ta shikoni në shfletues.
   Për të eliminuar të gjitha cilësimet e papajtueshme, përdorni SK117237.
7. Më pas ekzekutoni sërish mjetin pre_upgrade_verifier për t'u siguruar që të gjitha arsyet e papajtueshmërisë janë eliminuar.
8. Më tej mbledhim informacion për ndërfaqet e rrjetit, tabelën e rrugëzimit dhe eksportojmë konfigurimin GAIA:
   ip a > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
   ip r > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
   clish -c "show configuration" > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
9. Shkarkojmë skedarin e krijuar përmes SCP.
10. Krijojmë një snapshot në nivel virtualizimi.
11. Rrisim timeout-in e sesionit SSH në 8 orë. Kjo varet nga rrethanat: në varësi të madhësisë së bazës së të dhënave që eksportohet, procesi mund të zgjasë nga disa minuta deri në disa orë. Për këtë: 
    [Expert@HostName]# clish -c "show inactivity-timeout" shohim timeout-in aktual të clish,

    [Expert@HostName]# clish -c "set inactivity-timeout 720" caktojmë timeout-in e ri të clish (në minuta),

    [Expert@HostName]# echo $TMOUT shohim timeout-in aktual të expert mode,

    [Expert@HostName]# export TMOUT=3600 caktojmë timeout-in e ri të expert mode (në sekonda); nëse vendosni vlerën 0, timeout-i do të çaktivizohet.

12. Ngarkojmë dhe montojmë imazhin e instalimit SMS.iso në makinën virtuale.

    Përpara hapit të radhës, SIGUROHUNI patjetër edhe një herë që keni mjaftueshëm hapësirë të pacaktuar në diskun e ngurtë (kujtoj se duhen 13 GB). 

13. Para se të filloni eksportin e konfigurimit, ndryshoni skedarin e log-ut me komandën: fw logswitch

Eksporti i konfigurimit dhe i log-eve

1. Nisim mjetin migrate_export për të eksportuar konfigurimin. Për këtë, kalojmë në dosjen e krijuar më parë: cd /var/log/UpgradeR77.30_R80.20/ dhe përdorim komandën: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

   ose

   kalojmë në dosjen: cd $FWDIR/bin/upgrade_tools/ dhe
   nisim prej andej komandën: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

2. Llogarisim checksum-in e arkivit: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
3. Ruajeni vlerën e marrë në bllok shënimesh.
4. Lidhemi me SMS përmes SCP dhe shkarkojmë arkivin me konfigurimin në stacionin e punës. Sigurohuni të përdorni transferimin e skedarëve në formatin Binary.

Eksporti i bazës së të dhënave SmartEvent

Këtu do të na duhet një SMS me versionin R80 i instaluar paraprakisht. Mjafton edhe një mjedis testues. 

1. Nga SMS na duhet skripti që ndodhet këtu:$RTDIR/bin/eva_db_backup.csh
2. Ngarkojmë skriptin përmes SCP eva_db_backup.csh në dosjen: /var/log/UpgradeR77.30_R80.20/
3. Lidhemi me SMS përmes SSH. Kopjoni skedarin në dosjen: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
   $RTDIR/bin/eva_db_backup.csh
4. Ndryshojmë kodimin: dos2unix $RTDIR/bin/eva_db_backup.csh
5. Vendosim pronarin: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
6. Vendosim të drejtat e aksesit: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
7. Nisim eksportin e bazës së të dhënave SmartEvent: $RTDIR/bin/eva_db_backup.csh
8. Shkarkojmë skedarët e përftuar përmes SCP: $RTDIR/bin/-db-backup.backup dhe $RTDIR/bin/eventiaUpgrade.tar në stacionin e punës.

Përditësim

1. Kalojmë te WebUI GAIA SMS → CPUSE → Show all packages.
2. Nëse CPUSE shfaq një gabim lidhjeje me cloud-in e Check Point, kontrolloni DGW, DNS dhe cilësimet e Proxy.
3. Nëse gjithçka është në rregull, por gabimi vazhdon, atëherë duhet të përditësoni CPUSE manualisht, duke ndjekur sk92449.
4. Shkarkojmë imazhin dhe kalojmë më tej Verifier. Nëse është e nevojshme, korrigjojmë mospërputhjet.

   Si rezultat, duhet të shihni këtë mesazh:

   

5. Zgjidhni R80.20 Fresh Install and Upgrade for Security Management.
6. Gjatë instalimit të përditësimit, zgjidhni Clean Install. Pas instalimit, sistemi do të rindizet.
7. Kalojmë te First Time Wizard.
8. Pas marrjes së aksesit, kontrollojmë llogaritë e përdoruesve.
9. Lidhemi me SMS përmes SSH dhe ndryshojmë shell-in e përdoruesit tonë në /bin/bash/:

   set user shell /bin/bash/

   save config (nëse duam ta lëmë bin/bash/ si shell të parazgjedhur edhe pas rindizjes).

10. Më pas lidhemi me SMS përmes SCP dhe në modalitetin Binary transferojmë arkivin me konfigurimin SMS_w_logs_export_r77_r80.tgz në folderin /var/log/UpgradeR77.30_R80.20/
    
11. Llogarisim checksum-in e arkivit: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz dhe e krahasojmë me vlerën e mëparshme. Checksum duhet të përputhen.
12. Rrisim timeout-in e sesionit SSH deri në 8 orë. Për këtë:

    [Expert@HostName]# clish -c "show inactivity-timeout" shohim timeout-in aktual të clish,

    [Expert@HostName]# clish -c "set inactivity-timeout 720" caktojmë timeout-in e ri të clish (në minuta),

    [Expert@HostName]# echo $TMOUT shohim timeout-in aktual të expert mode,

    [Expert@HostName]# export TMOUT=3600 specifikojmë timeout-in e ri në expert mode (në sekonda). Nëse vendosni vlerën 0, timeout-i do të çaktivizohet.

13. Për të importuar konfigurimet, ekzekutojmë utilitën migrate import. Për këtë kalojmë në dosjen: cd $FWDIR/bin/upgrade_tools/dhe nisim importin: ./migrate imp
    ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

Shijoni jetën për dy orët e ardhshme. MOS E SHKËPUTNI SESIONIN SSH gjatë procedurës. Në fund, procesi migrate do të shfaqë ose një mesazh për përfundimin me sukses të operacionit, ose një gabim. 

Checklist i kontrolleve pas përditësimit

1. Disponueshmëria e burimeve.
2. SIC me GW.
3. Licencat. Nëse licencat shfaqen gabim ose nuk shfaqen në SMS, ekzekutoni komandën vsec_central_licence për shpërndarjen e licencave.
4. Instalimi i politikës. 

Importi i bazës SmartEvent

1. Aktivizoni blade-in SmartEvent.
2. Lidhemi përmes WinSCP me SMS dhe në modalitetin binary transferojmë skedarët e eksportuar më parë -db-backup.backup dhe eventiaUpgrade.tar në folderin /var/log/UpgradeR77.30_R80.20/
3. E ekzekutojmë skriptin me komandën: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
4. Kontrollojmë statusin: watch -n 10 eventiaUpgrade.sh
5. Kontrollojmë log-et në SmartEvent. GJUMË!

Përditësojmë klasterin Check Point GW (Active/Backup)

Para fillimit të punimeve

1. Ruajmë konfigurimin GAIA nga secila nyje e klasterit në një skedar, për këtë përdorni komandën: clish -c "show configuration" > ./.txt
2. Shkarkojmë skedarët me ndihmën e WinSCP.
3. Lidhemi me WebUI të të dy nyjeve dhe kalojmë te skeda CPUSE → Show all packages.
4. Gjejmë paketën e përditësimit për versionin R80.20 Fresh Install, klikojmë Download.
5. Kontrollojmë që protokolli CCP të funksionojë në modalitetin Broadcast, për këtë fusim komandën: cphaprob -a if
   Nëse është zgjedhur modaliteti Multicast, ndryshojeni me komandën: cphaconf set_ccp broadcast (komanda ekzekutohet në secilën nyje).
6. Vendosim Downtime për nyjet e përfshira në sistemin tuaj të monitorimit.
7. Kontrollojmë që në nivelin e virtualizimit të jenë të aktivizuara parametrat MAC Address Change dhe Forged Transmits për rrjetin sync.

Përditësim

1. Lidhemi përmes ssh me nyjen Active dhe ekzekutojmë komandën për monitorimin e gjendjes së klasterit: watch -n 2 cphaprob stat
2. Kthehemi në WebUI të nyjes Standby te skeda CPUSE dhe për paketën e zgjedhur R80.20 Fresh Install në funksion Verifier.
3. Analizojmë raportin Verifier. Nëse instalimi lejohet, vazhdojmë më tej.
4. Zgjedhim paketën R80.20 Fresh Install dhe nisim Upgrade. Gjatë procesit të Upgrade, sistemi do të rindizet. Cilësimet e GAIA ruhen. Gjatë rindizjes monitorojmë gjendjen e klasterit. Pas ngarkimit, statusi i nodës së përditësuar duhet të kalojë në READY. Në disa raste na ka ndodhur që noda ende e papërditësuar të kalonte në statusin Active Attention dhe të mos shfaqej më statusi i nodës së përditësuar. Mos u shqetësoni – edhe kjo situatë është e pranueshme.
5. Pas përfundimit të përditësimit, hapim SmartDashboard.
6. Hapim objektin e klasterit dhe ndryshojmë versionin e klasterit nga R77.30 në R80.20. Shtypim Ok. Nëse gjatë ruajtjes së ndryshimeve shfaqet gabimi:
   An internal error has occurred. (Code: 0x8003001D, Could not access file for write operation),
   ndiqni SK119973. Pas kësaj, ruajmë ndryshimet dhe shtypim Install Policy.
7. Te cilësimet, hiqni shenjën nga parametri For gateway clusters, if installation on a cluster member fails, do not install on that cluster.
8. Instalojmë politikën. Sistemi do të japë një gabim për nodën Active, e cila ende nuk është përditësuar.
9. Lidhemi me nodën e përditësuar përmes ssh dhe ekzekutojmë komandën për monitorimin e gjendjes së klasterit: watch -n 2 cphaprob stat
10. Lidhemi me WebUI të nodës Active dhe kalojmë te skeda CPUSE → Show all packages.Gjejmë paketën e përditësimit për versionin R80.20 Fresh Install, shtypim Download.
11. Vendosim Downtime për nyjet e përfshira në sistemin tuaj të monitorimit.
12. Kthehemi te WebUI i nodës Active në skedën CPUSE dhe për paketën e zgjedhur R80.20 Fresh Install në funksion Verifier.
13. Analizojmë raportin Verifier. Nëse instalimi lejohet, vazhdojmë më tej.
14. Zgjedhim paketën R80.20 Fresh Install dhe nisim Upgrade. Gjatë procesit të Upgrade, sistemi do të rindizet. Cilësimet e GAIA ruhen. Gjatë rindizjes monitorojmë gjendjen e klasterit në nodën tashmë të përditësuar. Pas rindizjes, gjendja e klasterit në nodën e përditësuar do të ndryshojë nga READY në ACTIVE.
15. Kur të përfundojë procesi i Upgrade, nisim SmartDashboard dhe instalojmë politikën.

Checklist i kontrolleve pas përditësimit

• Regjistrat e ngjarjeve në SmartLog, gjendja e tuneleve VPN.
• Cilësimet e GAIA.
• Rikthimi i klasterit pas Failover testues.
• Licencat dhe kontratat. Nëse licencat shfaqen gabim ose nuk shfaqen në SMS, ekzekutoni komandën vsec_central_licence për shpërndarjen e licencave.
• CoreXL.
• SecureXL.
• Hotfix dhe CPinfo në të dy nodat.

Përfundim

Në përgjithësi, në këtë pikë gjithçka përfundon – përditësimi u krye.

I gjithë procesi tek ne zgjaste mesatarisht nga 6 deri në 12 orë, në varësi të madhësisë së bazave që eksportoheshin. Punimet i kryem gjatë dy netëve: njëra për përditësimin e SMS, tjetra për klasterin.

Nuk pati ndërprerje të trafikut, megjithëse të gjitha gabimet e përmendura më sipër i verifikuam vetë në praktikë.

Sigurisht, ndonjëherë gjatë procesit të përditësimit mund të dalin edhe vështirësi krejtësisht të reja, por ky është Check Point dhe, siç e dimë të gjithë, gjithmonë ka një hotfix!

Ju urojmë net të suksesshme bardhezi-rozë dhe përditësime të mbara!

Burimi: habr.com