
Na podzim 2019 Check Point přestal podporovat verze R77.XX a bylo nutné provést aktualizaci. O rozdílech mezi verzemi, výhodách a nevýhodách přechodu na R80 už bylo řečeno hodně. Pojďme se raději zaměřit na to, jak vlastně aktualizovat virtuální appliance Check Point (CloudGuard pro VMware ESXi, Hyper-V, KVM Gateway NGTP) a co může jít špatně.
Takže jsme měli 2 inženýry CCSE, více než tucet virtuálních clusterů Check Point R77.30, několik cloudů, pár hotfixů a moře různých bugů, glitchů a všeho možného, ve všech barvách a velikostech, a k tomu velmi napjaté termíny. Jdeme na to!
Obsah:

Takto vypadá typická cloudová infrastruktura klienta s virtuálním Check Pointem
Příprava
Nejprve je třeba zkontrolovat dostatečnost zdrojů pro aktualizaci. Doporučené minimální požadavky pro R80.20 nyní vypadají takto:
Device
CPU
RAM
HDD
Security Gateway
2 jádra
4 GB
Od 15 GB
SMS
2 jádra
6 GB
—
Doporučení jsou popsána v dokumentu .
Ale buďme realisté. I když to stačí v minimální konfiguraci, jak ukazuje praxe, obvykle máme zapnutou https-inspekci, na SMS běží SmartEvent atd., což samozřejmě vyžaduje úplně jiné výkony. Ale celkově ne větší než pro R77.30.
Ale jsou tu nuanse. A týkají se především velikosti fyzické paměti. Mnoho operací přímo během aktualizace vyžaduje místo na pevném disku.
Pro server pro správu velikost volného místa na disku velmi závisí na objemu aktuálních logů (pokud je chceme zachovat) a na počtu uložených verzí databáze, i když ty už nám v hojném počtu nebudou potřebné. Samozřejmě, pro uzly clusteru (pokud logy neukládáte ještě lokálně) to vše není důležité. Zde je způsob, jak zkontrolovat dostupné místo:
- Připojte se k Smart Management Serveru pomocí ssh, přejděte do expert módu a zadejte příkaz:
[Expert@cp-sms:0]# df -h
- Na výstupu uvidíme přibližně takovou konfiguraci:
Souborový systém Velikost Použití Volno % Využito Připojeno na
/dev/mapper/vg_splat-lv_current 30G 7.4G 21G 27% /
/dev/sda1 289M 24M 251M 9% /boot
V tuto chvíli nás zajímá oddíl
/dev/mapper/vg_splat-lv_log 243G 177G 53G 78% /var/log - V současné době nás zajímá sekce /var/log
Mějte na paměti, že v závislosti na politice ukládání a odstraňování starých logů a také velikosti exportované databáze může být zapotřebí více místa. Pokud při vytváření archivu klesne volné místo pod úroveň uvedenou v politice ukládání logů, systém začne mazat staré logy a NEDÁ je do archivu.
Pro samotný proces aktualizace bude systému potřeba alespoň 13 GB nealokovaného místa na pevném disku. Jeho přítomnost můžete zkontrolovat příkazem:
[Expert@cp-sms:0]# pvs
Uvidíme přibližně takovýto výstup:
PV VG Fmt Attr PSize PFree
/dev/sda3 vg_splat lvm2 a- 141.69G 43.69G
V tomto případě máme k dispozici 43 GB. Zdroje stačí. Můžeme přistoupit k aktualizaci.
Aktualizujeme server pro správu Check Point SMS
Před zahájením prací je potřeba udělat následující:
- Nainstalujeme balíček Migration Tools na server pro správu. K tomu je potřeba stáhnout obraz z portálu..
- Nahrajeme archiv na server pro správu přes WinSCP do složky /var/log/UpgradeR77.30_R80.20 (pokud je to potřeba, předtím vytvořte složku).
- Připojíme se k serveru pro správu přes SSH a přejdeme do složky s archívem:cd /var/log/UpgradeR77.30_R80.20/
- Rozbalíme soubor:tar -zxvf ./.tgz
- Spustíme utilitu pre_upgrade_verifier příkazem: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
- Po vykonání příkazu bude vytvořena zpráva o nekompatibilních nastaveních. Je dostupná na adrese: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Je pohodlnější ji exportovat pomocí SCP a prohlédnout si ji v prohlížeči.
Pro odstranění všech nekompatibilních nastavení použijte. - Poté znovu spusťte utilitu pre_upgrade_verifier, abyste se ujistili, že byly všechny příčiny nekompatibility odstraněny.
- Dále shromáždíme informace o síťových rozhraních, směrovací tabulce a exportujeme konfiguraci 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 - Exportujeme získaný soubor přes SCP.
- Vytvoříme snapshot na úrovni virtualizace.
- Zvýšíme timeout SSH relace na 8 hodin. Zde to záleží: v závislosti na velikosti exportované databáze může trvat od několika minut do několika hodin. K tomu:
[Expert@HostName]# clish -c "show inactivity-timeout" zkontrolujeme aktuální timeout clish,[Expert@HostName]# clish -c "set inactivity-timeout 720" určíme nový timeout clish (v minutách),
[Expert@HostName]# echo $TMOUT zkontrolujeme aktuální timeout expert mode,
[Expert@HostName]# export TMOUT=3600 určíme nový timeout expert mode (ve sekundách), pokud nastavíme hodnotu 0, timeout bude vypnut.
- Načítáme a připojujeme instalační obraz SMS.iso k virtuálnímu stroji.
Před dalším krokem je POVINNÉ znovu zkontrolovat, že máte dostatečné nealokované místo na pevném disku (připomínám, že je potřeba 13 GB).
- Před začátkem exportu konfigurace změňte log soubor příkazem: fw logswitch
Export konfigurace a logů
- Spouštíme nástroj migrate_export pro export konfigurace. K tomu přejdeme do dříve vytvořené složky: cd /var/log/UpgradeR77.30_R80.20/ a použijeme příkaz: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
nebo
přejdeme do složky: cd $FWDIR/bin/upgrade_tools/ a
spouštíme odtud příkaz: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz - Získáváme checksum z archivu: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Uložíme získanou hodnotu do textového editoru.
- Připojíme se k SMS přes SCP a exportujeme archiv s konfigurací na pracovní stanici. Určitě používejte přenos souborů ve formátu Binary.
Export databáze SmartEvent
Budeme potřebovat předem nainstalovaný SMS verze R80. Jakákoliv testovací verze bude vyhovovat.
- Od SMS potřebujeme skript umístěný zde:$RTDIR/bin/eva_db_backup.csh
- Přes SCP načteme skript eva_db_backup.csh do složky: /var/log/UpgradeR77.30_R80.20/
- Připojíme se přes SSH k SMS. Zkopírujte soubor do složky: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$RTDIR/bin/eva_db_backup.csh - Změníme kódování: dos2unix $RTDIR/bin/eva_db_backup.csh
- Přidáváme vlastníka: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
- Přidáváme práva: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
- Spouštíme export databáze SmartEvent: $RTDIR/bin/eva_db_backup.csh
- Exportujeme získané soubory přes SCP: $RTDIR/bin/-db-backup.backup a $RTDIR/bin/eventiaUpgrade.tar na pracovní stanici.
Aktualizace
- Přejdeme do WebUI GAIA SMS → CPUSE → Zobrazit všechny balíčky.
- V případě, že CPUSE hlásí chybu připojení k cloudu Check Point, zkontrolujeme DGW, DNS a nastavení Proxy.
- Pokud je vše správně, ale chyba přetrvává, je nutné ručně aktualizovat CPUSE podle.
- Stáhneme obraz a projdeme Verifier. V případě potřeby odstraníme nesrovnalosti.
Výsledkem by mělo být následující zpráva:

- Vyberte R80.20 Fresh Install and Upgrade for Security Management.
- Při instalaci aktualizace vybíráme Clean Install. Po instalaci se systém restartuje.
- Projdeme First Time Wizard.
- Po získání přístupu zkontrolujeme účty.
- Připojíme se k SMS přes SSH a změníme shell našeho uživatele na /bin/bash/:
set user shell /bin/bash/
save config (v případě, že chceme ponechat bin/bash/ jako shell výchozí i po restartu).
- Dále se připojíme k SMS přes SCP a v režimu Binary přenášíme archiv s konfigurací SMS_w_logs_export_r77_r80.tgz do složky /var/log/UpgradeR77.30_R80.20/
- Získáváme checksum z archivu: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz a porovnáváme s předchozí hodnotou. Kontrolní součty by měly odpovídat.
- Zvyšujeme timeout SSH relace na 8 hodin. K tomu:
[Expert@HostName]# clish -c "show inactivity-timeout" zkontrolujeme aktuální timeout clish,
[Expert@HostName]# clish -c "set inactivity-timeout 720" určíme nový timeout clish (v minutách),
[Expert@HostName]# echo $TMOUT zkontrolujeme aktuální timeout expert mode,
[Expert@HostName]# export TMOUT=3600 uvádíme nový timeout v expert módu (v sekundách). Pokud nastavíte hodnotu 0, timeout bude vypnut.
- Pro import nastavení spouštíme utilitu migrate import. K tomu se přepneme do složky: cd $FWDIR/bin/upgrade_tools/a spustíme import: ./migrate imp
ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Užíváme si život v následujících několika hodinách. NEOZNAČUJTE SSH-RELACI během procedury. Na konci proces migrate zobrazí buď zprávu o úspěšném dokončení operace, nebo chybu.
Kontrolní seznam po aktualizaci
- Dostupnost zdrojů.
- SIC s GW.
- Licence. Pokud se licence zobrazují nesprávně nebo se nezobrazují na SMS, spouštíme příkaz vsec_central_licence pro rozdělení licencí.
- Nastavení politiky.
Import databáze SmartEvent
- Aktivujte blade SmartEvent.
- Připojujeme se přes WinSCP k SMS a v binárním režimu přenášíme dříve exportované soubory -db-backup.backup a eventiaUpgrade.tar do složky /var/log/UpgradeR77.30_R80.20/
- Spouštíme skript příkazem: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
- Zkontrolujte stav: watch -n 10 eventiaUpgrade.sh
- Kontrolujeme logy ve SmartEvent. SLEEP!
Aktualizujeme cluster Check Point GW (Aktivní/Záložní)
Před zahájením prací
- Ukládáme konfiguraci GAIA z každého uzlu clusteru do souboru, k tomu použijeme příkaz: clish -c "show configuration" > ./.txt
- Exportujeme soubory pomocí WinSCP.
- Připojujeme se k WebUI obou uzlů a přecházíme na záložku CPUSE → Zobrazit všechny balíčky.
- Najdeme aktualizační balíček pro verzi R80.20 Fresh Install, klikněte na Stáhnout.
- Kontrolujeme, že CCP protokol funguje v režimu Vroadcast, k tomu zadáme příkaz: cphaprob -a if
Pokud je vybrán režim Multicast, změňte jej příkazem: cphaconf set_ccp broadcast (příkaz se provádí na každém uzlu). - Nastavujeme Downtime pro zapojené uzly ve vaší monitorovací soustavě.
- Zkontrolujeme, že na úrovni virtualizace jsou povoleny parametry Změna MAC adresy a Falešné přenosy pro sync síť.
Aktualizace
- Připojujeme se přes ssh k aktivnímu uzlu a spouštíme příkaz pro monitorování stavu clusteru: watch -n 2 cphaprob stat
- Vracíme se do WebUI záložního uzlu na záložku CPUSE a pro vybraný balíček R80.20 Fresh Install spouštíme Verifier.
- Analyzujeme zprávu Verifier. Pokud je instalace povolena, pokračujeme dále.
- Vyberáme balíček R80.20 Fresh Install a spouštíme Upgrade. B průběhu upgrade bude systém restartován. Nastavení GAIA jsou zachována. V okamžiku restartu sledujeme stav klastru. Po načtení by se měl stav aktualizovaného uzlu změnit na READY. V některých případech nám vznikla situace, kdy ještě neaktualizovaný uzel přešel do stavu Active Attention a přestal zobrazovat stav aktualizovaného uzlu. Nebojte se – i tato varianta je přípustná.
- Po dokončení aktualizace otevřeme SmartDashboard.
- Otevřeme objekt clustru a změníme verzi clustru z R77.30 na R80.20. Klikneme na Ok. Pokud při ukládání změn dojde k chybě:
Došlo k interní chybě. (Kód: 0x8003001D, Nelze přistupovat k souboru pro zápis operace)
řídíme se. Poté uložíme změny a klikneme na Install Policy. - V nastavení odstraníme zaškrtnutí parametru For gateway clusters, if installation on a cluster member fails, do not install on that cluster.
- Nastavujeme politiku. Systém vyvolá chybu pro aktivní uzel, který ještě nebyl aktualizován.
- Připojujeme se k aktualizovanému uzlu přes ssh a spouštíme příkaz pro monitorování stavu clustru: watch -n 2 cphaprob stat
- Připojujeme se k WebUI aktivního uzlu a přecházíme na záložku CPUSE → Zobrazit všechny balíčky.Najdeme aktualizační balíček pro verzi R80.20 Fresh Install, klikneme na Stáhnout.
- Nastavujeme Downtime pro zapojené uzly ve vaší monitorovací soustavě.
- Vracíme se do WebUI aktivního uzlu na záložku CPUSE a pro vybraný balíček R80.20 Fresh Install spouštíme Verifier.
- Analyzujeme zprávu Verifier. Pokud je instalace povolena, pokračujeme dále.
- Vyberáme balíček R80.20 Fresh Install a spouštíme Upgrade. B průběhu upgrade bude systém restartován. Nastavení GAIA jsou zachována. V okamžiku restartu sledujeme stav clustru na již aktualizovaném uzlu. Po restartu se stav clustru na aktualizovaném uzlu změní z READY na ACTIVE.
- Když skončí proces upgradu, spustíme SmartDashboard a nastavíme politiku.
Kontrolní seznam po aktualizaci
- Protokoly událostí v SmartLog, stav VPN tunelů.
- Nastavení GAIA.
- Obnovení clustru po testovém failoveru.
- Licencí a smlouvy. V případě, že jsou licence zobrazeny nesprávně nebo se nezobrazují na SMS, spouštíme příkaz. vsec_central_licence pro distribuci licencí.
- CoreXL.
- SecureXL.
- Hotfix a CPinfo na dvou uzlech.
Závěr
Celkově tímto bodem vše končí – úspěšně jste se aktualizovali.
Celý proces nám průměrně trval od 6 do 12 hodin, v závislosti na velikosti exportovaných databází. Práce probíhaly dvě noci: jedna – pro aktualizaci SMS, druhá – pro klastr.
Nebyly žádné výpadky provozu, ačkoli všechny výše zmíněné chyby jsme si ověřovali sami.
Samozřejmě, někdy se mohou vyskytnout úplně nové potíže během aktualizace, ale to je Check Point, a jak všichni víme, vždy je tu hotfix!
Přejeme vám úspěšné černorůžové noci a aktualizace!
Zdroj: habr.com

