Uuendame Check Pointi R77.30-lt 80.20-le

Sügis 2019. aastal lõpetas Check Point R77.XX versioonide toetamise, seega oli aeg uuendada. Versioonide, ülemineku plusside ja miinuste kohta on juba palju räägitud. Räägime paremini sellest, kuidas uuendada Check Pointi virtuaalseid appliance'e (CloudGuard for VMware ESXi, Hyper-V, KVM Gateway NGTP) ja millised probleemid võivad ette tulla.

Nii, meil oli 2 CCSE inseneri, üle tosin virtuaalset Check Point R77.30 klastrit, mitu pilve, mõned hotfixid ja tohutu hulk erinevaid vigu, tõrkeid ja nii edasi, kõikvõimalikes variatsioonides, ning väga kitsad tähtajad. Alustame!

Sisu:

Ettevalmistus
Uuendame juhtimisseveri
Uuendame klastrit

Nii näeb välja tüüpiline kliendi pilveinfrastruktuur koos virtuaalse Check Pointiga

Ettevalmistus

Esiteks tuleb kontrollida, kas ressursid on uuendamiseks piisavad. R80.20 minimaalsete soovitatud nõuete järgi näevad need hetkel välja järgmiselt:

Seade

CPU

RAM

HDD

Security Gateway

2 core

4 Gb

Alates 15 GB

SMS

2 core

6 Gb

—

Soovitused on kirjas dokumendis CP_R80.20_GA_Release_Notes.

Ent olgem realistlikud. Isegi kui minimaalne konfiguratsioon on piisav, siis praktika näitab, et enamasti on meil sisse lülitatud HTTPS-i inspekteerimine, SmartEvent töötab SMS-is jne, mis muidugi nõuab täiesti erinevaid ressursse. Kuid kokkuvõttes mitte oluliselt suuri, kui R77.30 jaoks.

Kuid on nüansse. Need puudutavad peamiselt füüsilise mälu suurusi. Paljud uuendamise käigus vajalikud toimingud nõuavad kõvakettal ruumi.

Juhtimisseveri puhul sõltub vabade ketasruumide suurus väga palju praeguste logide mahust (kui soovime neid säilitada) ja salvestatud Database Revisions arvust, kuigi neid ei ole meil suurtes kogustes enam vaja. Loomulikult ei oma klastrinode puhul (kui te ei salvesta logisid ka lokaalselt) see kõik tähtsust. Nii saab kontrollida vajaliku ruumi olemasolu:

1. Ühendume Smart Management Serveriga kasutades ssh, siseneme ekspertrežiimi ja sisestame käsu:

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

2. Väljundina näeme umbes sellist konfiguratsiooni:

   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. Hetkel huvitab meid üldiselt partitsioon /var/log

Pange tähele, et sõltuvalt poliitikast, mis reguleerib vana logifailide säilitamist ja kustutamist, samuti eksporditava andmebaasi suurusest, võib ruumi vaja minna rohkem. Kui arhiivi loomisel jääb vaba ruumi vähemaks, kui on määratud logifailide säilitamise poliitikas, hakkab süsteem vanu logisid kustutama ja EI lisa neid arhiivi.

Samuti on uuendamisprotsessis süsteemil minimaalne vajadus 13 GB jaotamata ketasruumi. Selle olemasolu kontrollimiseks saab kasutada käsku:

[Expert@cp-sms:0]# pvs

Näeme umbes sellist väljundit:

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

Antud juhul on meil 43 GB. Ressursse on piisavalt. Saame alustada uuendamist.

Uuendame Check Pointi SMS-i juhtimisseverit

Enne tööde alustamist tuleb teha järgmised sammud:

1. Installime juhendite paketi juhtimissevrisse. Selleks tuleb pildifail üles laadida portaalist. Check Point.
2. Laadime arhiivi juhtimissevrisse läbi WinSCP kausta /var/log/UpgradeR77.30_R80.20 (kui vajalik, siis lugege eelnevalt kausta).
3. Ühendume juhtimissevriga SSH kaudu ja läheme arhiivi kaustasse:cd /var/log/UpgradeR77.30_R80.20/
4. Kaalume faili:tar -zxvf ./.tgz
5. Käivitame utiliidi pre_upgrade_verifier käsuga: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
6. Käskluse täitmisel luuakse aruanne ühilduvuse probleemidest. See on saadaval aadressil: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Mugavam on see eksportida SCP kaudu ja vaadata brauseris.
   Ühilduvuse probleemide kõrvaldamiseks kasutage SK117237.
7. Pärast seda käivitage utiliit pre_upgrade_verifier uuesti, et veenduda, et kõik ühilduvuse probleemid on lahendatud.
8. Seejärel kogume teavet võrguliideste, marsruuditud tabeli ja GAIA konfiguratsiooni eksportimiseks:
   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. Eksportige saadud fail SCP kaudu.
10. Tehke virtualiseerimise tasemel snapshot.
11. Suurendame SSH seansi ooteaega 8 tunnini. Siin sõltub see õnnest: sõltuvalt eksporditava andmebaasi suurusest võib see kesta ühest minutist mitme tunnini. Selleks: 
    [Expert@HostName]# clish -c "show inactivity-timeout" kontrollime praegust clishi ooteaega,

    [Expert@HostName]# clish -c "set inactivity-timeout 720" seadke uus clishi ooteaeg (minutites),

    [Expert@HostName]# echo $TMOUT kontrollime praegust ekspertrežiimi ooteaega,

    [Expert@HostName]# export TMOUT=3600 seadke uus ekspertrežiimi ooteaeg (sekundites), kui panna väärtuseks 0, siis ooteaeg lülitatakse välja.

12. Laadige installatsioonipilt SMS.iso virtuaalmasinale.

    Enne järgmise sammu JÄRJEKINDLAT kontrollige, et teil oleks piisavalt jaotamata ketasruumi (meeldetuletuseks, on vajalik 13 GB). 

13. Enne konfiguratsiooni eksportimise alustamist muudame logifaili käsuga: fw logswitch

Konfiguratsiooni ja logide eksport

1. Käivitame utiliidi migrate_export konfiguratsiooni väljatõmbamiseks. Selleks liigume varasema loomise kausta: cd /var/log/UpgradeR77.30_R80.20/ ja kasutame käsku: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

   või

   liigume kausta: cd $FWDIR/bin/upgrade_tools/ ja
   käivitame sealt käsu: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

2. Saame arhiivist checksum'i: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
3. Salvestame saadud väärtuse tekstiredaktorisse.
4. Ühendame SMS-iga läbi SCP ja laadime konfiguratsiooni arhiivi tööjaama. Kasutage kindlasti failide ülekannet binaarses formaadis.

SmartEvent andmebaasi eksport

Siin on meil vaja eelnevalt installitud SMS-i versioonis R80. Sobib iga testversioon. 

1. SMS-ilt vajame skripti, mis asub siin:$RTDIR/bin/eva_db_backup.csh
2. Laadime skripti eva_db_backup.csh kausta: /var/log/UpgradeR77.30_R80.20/
3. Ühendame SMS-iga SSH kaudu. Kopeerime faili kausta: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
   $RTDIR/bin/eva_db_backup.csh
4. Muudame kodeeringut: dos2unix $RTDIR/bin/eva_db_backup.csh
5. Lisame omandi: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
6. Lisame õigused: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
7. Käivitame SmartEvent andmebaasi eksportimise: $RTDIR/bin/eva_db_backup.csh
8. Laadime saadud failid läbi SCP: $RTDIR/bin/-db-backup.backup ja $RTDIR/bin/eventiaUpgrade.tar tööjaama.

Uuendamine

1. Liigume WebUI GAIA SMS → CPUSE → Näita kõiki pakette.
2. Kui CPUSE annab Check Pointi pilvega ühenduse viga, kontrollime DGW, DNS ja proxy seadeid.
3. Kui kõik on õige, kuid viga ei kao, tuleb CPUSE käsitsi uuendada, järgides sk92449.
4. Laadime pildi alla ja liigume edasi Verifier. Vajadusel lahendame ebakõlad.

   Võime nähtud sõnumit näha:

   

5. Valime R80.20 Fresh Install ja Upgrade Security Management'i jaoks.
6. Uuenduse installimisel valime Clean Install. Pärast installimist taaskäivitub süsteem.
7. Läbime First Time Wizard.
8. Pärast ligipääsu saamist kontrollime kontoandeid.
9. Ühendame SMS-iga SSH kaudu ja muudame meie kasutaja shell'i /bin/bash/:

   set user shell /bin/bash/

   salvesta seaded (kui soovime jätta bin/bash/ vaikimisi shell'iks ka pärast taaskäivitamist).

10. Seejärel ühendame SMS-iga SCP kaudu ja binaarses formaadis edastame konfiguratsiooni arhiivi SMS_w_logs_export_r77_r80.tgz kausta /var/log/UpgradeR77.30_R80.20/
    
11. Saame arhiivist checksum'i: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz ja võrdleme eelneva väärtusega. Checksum'id peaksid kattuma.
12. Kasutame SSH seansi timeout'i 8 tundi. Selleks:

    [Expert@HostName]# clish -c "show inactivity-timeout" kontrollime praegust clishi ooteaega,

    [Expert@HostName]# clish -c "set inactivity-timeout 720" seadke uus clishi ooteaeg (minutites),

    [Expert@HostName]# echo $TMOUT kontrollime praegust ekspertrežiimi ooteaega,

    [Expert@HostName]# export TMOUT=3600 määrame uue timeout'i spetsiaalrežiimis (sekundites). Kui määrata väärtus 0, siis timeout lülitub välja.

13. Seadete importimiseks käivitame utiliidi migrate import. Selleks liigume kausta: cd $FWDIR/bin/upgrade_tools/ja käivitame impordi: ./migrate import -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
    Naudime elu järgmised paar tundi. ÄRGE KATKESTAGE SSH-SESSIONI protseduuri ajal. Lõpus annab migrate protsess kas eduka lõpuleviimise sõnumi või veateate.

Kontrollide kontrollnimekiri pärast uuendamist 

Ressursside kättesaadavus.

1. SIC GW-ga.
2. Litsentsid. Kui litsentsid on vale kuvatav või ei kuvatud SMS-is, käivitame käsu
3. vsec_central_licence litsentside jaotamiseks. Poliitika seadistamine.
4. SmartEvent andmebaasi import 

Aktiveeri SmartEvent blade.

1. Ühendame WinSCP abil SMS-iga ja binaarses formaadis edastame varem eksportitud failid
2. -db-backup.backup eventiaUpgrade.tar ja Käivitame skripti käsuga: kausta /var/log/UpgradeR77.30_R80.20/
3. $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar Kontrollime staatust:
4. watch -n 10 eventiaUpgrade.sh Kontrollime logisid SmartEvent'is.
5. SON! Uuendame Check Point GW klastrit (Active/Backup)

Enne tööde alustamist

Salvestame GAIA konfiguratsiooni iga klastrite sõlme faili, kasutades käsku:

1. clish -c "show configuration" > ./.txt Laadime failid välja WinSCP abil.
2. Ühendame kahe sõlme WebUI ja liigume vahekaardile
3. CPUSE → Näita kõiki pakette. Leiame uuenduste paketi versioonile
4. R80.20 Fresh Install Laadi alla., klikkige Kontrollime, et CCP-protokoll töötab režiimis
5. Broadcast , selleks sisestame käsu:cphaprob -a if Kui režiim on valitud,
   vahetame selle käsuga: Multicastcphaconf set_ccp broadcast (käsk täidetakse igas sõlmes). Seadistame Downtime seotud sõlmede jaoks teie jälgimissüsteemis.
6. Kontrollime, et virtualiseerimise tasemel oleksid lubatud seaded
7. MAC Address Change Forged Transmits ja sync-võrgus. Ühendame Active-sõlmega ssh kaudu ja käivitame käsu klasteri oleku jälgimiseks:

Uuendamine

1. watch -n 2 cphaprob stat Naaseme WebUI Stanby sõlmele ja valime vahekaardi
2. CPUSE ja valitud paketi Analüüsime Verifieri aruannet. Kui installimine on lubatud, liigume edasi. Laadi alla. käivitame Verifier.
3. ja käivitame
4. . Uuendamise protsessis süsteem taaskäivitatakse. GAIA seaded salvestatakse. Taaskäivitamise ajal jälgime klastriseisundit. Pärast laadimist peab uuendatud sõlme staatus muutuma READY-ks. Mõningatel juhtudel on meil tekkinud olukord, kus veel uuendamata sõlm läks Active Attention staatusesse ja lõpetas uuendatud sõlme staatuse kuvamise. Ära muretse – selline variant on samuti lubatud. Laadi alla. Pärast uuendamise lõpetamist avame UuendaSmartDashboard.
5. Avame klastrielemendi ja muudame klastriversiooni R77.30-lt R80.20-le. Vajutame Ok. Kui muudatuste salvestamisel ilmneb viga: SmartDashboard.
6. Avame klusteriobjekt ja muudame klustversiooni R77.30-lt R80.20-le. Vajutame Ok. Kui muudatuste salvestamisel ilmneb viga:
   Sisekõrge viga on toimunud. (Kood: 0x8003001D, Faili kirjutamiseks juurdepääsu ei saanud)
   järgige SK119973. Pärast seda salvestame muudatused ja vajutame Installige poliitika.
7. Seadetes eemaldame märgi parameetrilt Kliendigruppide puhul, kui installimine klastriliikmele ebaõnnestub, siis ärge installige sellele klastrile.
8. Seame poliitika. Süsteem annab Active-node'i jaoks vea, mis ei ole veel uuendatud.
9. Ühendame uuendatud node'iga ssh kaudu ja käivitame käsu klastriseisundi jälgimiseks: Naaseme WebUI Stanby sõlmele ja valime vahekaardi
10. Ühendame WebUI Active-node'iga ja liigume vahelehele Leiame uuenduste paketi versioonileR80.20 Fresh Install Laadi alla., vajutame Kontrollime, et CCP-protokoll töötab režiimis
11. Kontrollime, et virtualiseerimise tasemel oleksid lubatud seaded
12. Tagasi WebUI Active-node'i vahelehele ja valitud paketi Analüüsime Verifieri aruannet. Kui installimine on lubatud, liigume edasi. Laadi alla. käivitame Verifier.
13. ja käivitame
14. . Uuendamise protsessis süsteem taaskäivitatakse. GAIA seaded salvestatakse. Taaskäivitamise ajal jälgime klastriseisundit. Pärast laadimist peab uuendatud sõlme staatus muutuma READY-ks. Mõningatel juhtudel on meil tekkinud olukord, kus veel uuendamata sõlm läks Active Attention staatusesse ja lõpetas uuendatud sõlme staatuse kuvamise. Ära muretse – selline variant on samuti lubatud. Laadi alla. Pärast uuendamise lõpetamist avame Uuendamine. Uuendamise käigus süsteem taaskäivitub. GAIA seadistused salvestatakse. Taaskäivitamise hetkel jälgime klastriseisundit juba uuendatud node'is. Pärast taaskäivitamist muutub klastriseisund uuendatud node'is READY'st ACTIVE'ks.
15. Kui Uuendamine on lõppenud, käivitame SmartDashboardi ja seadistame poliitika.

Ressursside kättesaadavus.

• Sündmuste logid SmartLogis, VPN-tunnelite seisund.
• GAIA seadistused.
• Klastre taastamine pärast katset Failover.
• Litsentsid ja lepingud. Kui litsentsid kuvatakse vale või ei kuvatata SMS-is, käivitame käsu vsec_central_licence litsentside jaotamiseks.
• CoreXL.
• SecureXL.
• Hotfix ja CPinfo kahel node'il.

Kokkuvõte

Üldiselt on see hetk kõik – olete uuendatud.

Kogu protsess kestis meil keskmiselt 6–12 tundi, sõltuvalt eksporditud andmebaaside suurusest. Töö toimus kahe öö jooksul: üks – SMS-i uuendamiseks, teine – klastriks.

Liiklus seiskumist ei olnud, hoolimata kõigist eelnevalt mainitud vigadest, mida me ise kontrollisime.

Loomulikult võivad uuendamise käigus tekkida täiesti uued raskused, kuid see on Check Point ja nagu me kõik teame, on alati hotfix!

Soovin teile musta-roosaid öid ja uuendusi!

Allikas: habr.com