We updaten Check Point van R77.30 naar 80.20.

In het najaar van 2019 stopte Check Point met de ondersteuning van versies R77.XX, en het was tijd om te upgraden. Er is al veel gezegd over de verschillen tussen versies, de voor- en nadelen van de overstap naar R80. Laten we het beter hebben over hoe we de virtuele appliance van Check Point (CloudGuard voor VMware ESXi, Hyper-V, KVM Gateway NGTP) daadwerkelijk kunnen upgraden en wat er mis kan gaan.

Dus, we hadden 2 CCSE-ingenieurs, meer dan een dozijn virtuele clusters van Check Point R77.30, enkele clouds, een paar hotfixes en een zee van allerlei bugs, glitches en ander gedoe, in alle kleuren en maten, en bovendien zeer strakke deadlines. Laten we beginnen!

Inhoud:

Voorbereiding
De managementserver upgraden
Cluster upgraden

Zo ziet de typische cloudinfrastructuur van een klant eruit met een virtuele Check Point

Voorbereiding

Allereerst moeten we controleren of er voldoende bronnen zijn voor de upgrade. De aanbevolen minimale vereisten voor R80.20 zijn momenteel als volgt:

Device

CPU

RAM

HDD

Security Gateway

2 core

4 Gb

Minimaal 15 GB

SMS

2 core

6 Gb

—

De aanbevelingen zijn beschreven in het document CP_R80.20_GA_Release_Notes.

Maar laten we realistisch zijn. Als dat in de aller-minimale configuratie voldoende is, dan is het, blijkt uit de praktijk, meestal zo dat we HTTPS-inspectie ingeschakeld hebben, dat SmartEvent op de SMS draait, enzovoorts, wat uiteraard andere capaciteiten vereist. Maar over het algemeen zijn die niet groter dan voor R77.30.

Maar er zijn nuances. Deze hebben vooral te maken met de grootte van het fysieke geheugen. Veel operaties tijdens het upgradeproces vereisen ruimte op de harde schijf.

Voor de managementserver zal de hoeveelheid vrije schijfruimte sterk afhangen van de hoeveelheid huidige logs (als we die willen behouden) en het aantal opgeslagen Database Revisions, ook al hebben we die in grote aantallen eigenlijk niet meer nodig. Uiteraard is dit allemaal niet van belang voor de knooppunten van het cluster (tenzij je de logs ook lokaal opslaat). Zo kun je controleren of er voldoende ruimte is:

1. We verbinden ons met de Smart Management Server via ssh, gaan naar expert modus en voeren de volgende opdracht in:

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

2. Bij de uitvoer zullen we ongeveer deze configuratie zien:

   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
   Momenteel zijn we geïnteresseerd in de partitie
   /dev/mapper/vg_splat-lv_log           243G  177G 53G  78% /var/log

3. Op dit moment zijn we geïnteresseerd in de sectie /var/log

Houd er rekening mee dat afhankelijk van het opslag- en verwijderingsbeleid van oude logbestanden en de grootte van de geëxporteerde database, meer ruimte nodig kan zijn. Als er bij het aanmaken van het archief minder vrije ruimte beschikbaar is dan volgens het beleid voor logbestanden is toegestaan, zal het systeem oude logs beginnen te wissen en deze NIET in het archief opnemen.

Voor het bijwerkingsproces heeft de systeem minimaal 13 GB onbenutte schijfruimte nodig. Deze kan gecontroleerd worden met het volgende commando:

[Expert@cp-sms:0]# pvs

We zien ongeveer deze uitvoer:

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

In dit geval hebben we 43 GB. De middelen zijn voldoende. We kunnen beginnen met de update.

Update de Check Point SMS beheerder

Voorafgaand aan de werkzaamheden moeten we het volgende doen:

1. Installeer het Migration Tools pakket op de beheerder. Hiervoor moet het beeld van de portal worden gedownload Check Point.
2. Upload het archief naar de beheerder via WinSCP in de map /var/log/UpgradeR77.30_R80.20 (indien nodig, maak dan eerst de map aan).
3. Verbind met de beheerder via SSH en ga naar de map met het archief:cd /var/log/UpgradeR77.30_R80.20/
4. Pak het bestand uit:tar -zxvf ./.tgz
5. Start de pre_upgrade_verifier tool met het commando: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
6. Na het uitvoeren van het commando zal er een rapport worden gegenereerd over incompatibele instellingen. Dit is beschikbaar op het adres: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Het is handiger om het via SCP te downloaden en het via de browser te bekijken.
   Om alle incompatibele instellingen te verhelpen, gebruik SK117237.
7. Start nu de pre_upgrade_verifier tool opnieuw om te bevestigen dat alle incompatibiliteitsredenen zijn opgelost.
8. Vervolgens verzamelen we informatie over netwerkintevallen, de routeringstabel en exporteren we de GAIA-configuratie:
   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. Exporteer het verkregen bestand via SCP.
10. Maak een snapshot op het virtualisatieniveau.
11. Verhoog de SSH sessietimeout naar 8 uur. Dit kan variëren: afhankelijk van de grootte van de geëxporteerde database kan het van enkele minuten tot enkele uren duren. Voer hiervoor het volgende uit: 
    [Expert@HostName]# clish -c "show inactivity-timeout" Bekijk de huidige clish timeout,

    [Expert@HostName]# clish -c "set inactivity-timeout 720" Geef de nieuwe clish timeout op (in minuten),

    [Expert@HostName]# echo $TMOUT Bekijk de huidige expert mode timeout,

    [Expert@HostName]# export TMOUT=3600 Geef de nieuwe expert mode timeout op (in seconden), als je een waarde van 0 opgeeft, zal de timeout worden uitgeschakeld.

12. We load and mount the installation image SMS.iso to the virtual machine.

    Before the next step, make sure to check once more that you have enough unallocated space on the hard drive (remember, you need 13 GB). 

13. Before starting the configuration export, we change the log file with the command: fw logswitch

Export configuration and logs

1. We launch the migrate_export utility to export the configuration. For this, we navigate to the previously created folder: cd /var/log/UpgradeR77.30_R80.20/ and use the command: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

   of

   we navigate to the folder: cd $FWDIR/bin/upgrade_tools/ en
   we run the command from there: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

2. We take the checksum from the archive: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
3. We save the obtained value in a notepad.
4. We connect to SMS via SCP and export the archive with the configuration to the workstation. Be sure to use binary file transfer mode.

Export SmartEvent database

Here we will need a pre-installed SMS version R80. Any test version will do. 

1. We need the script from SMS located here:$RTDIR/bin/eva_db_backup.csh
2. We upload the script through SCP eva_db_backup.csh to the folder: /var/log/UpgradeR77.30_R80.20/
3. We connect via SSH to SMS. Copy the file to the folder: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
   $RTDIR/bin/eva_db_backup.csh
4. We change the encoding: dos2unix $RTDIR/bin/eva_db_backup.csh
5. We add the owner: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
6. We add permissions: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
7. We start exporting the SmartEvent database: $RTDIR/bin/eva_db_backup.csh
8. We unload the obtained files via SCP: $RTDIR/bin/-db-backup.backup en $RTDIR/bin/eventiaUpgrade.tar to the workstation.

Bijwerken

1. We gaan naar WebUI GAIA SMS → CPUSE → Show all packages.
2. In case CPUSE returns a connection error to the Check Point cloud, we check DGW, DNS, and Proxy settings.
3. If everything is correct but the error persists, we need to manually update CPUSE according to sk92449.
4. We download the image and proceed with Verifier. If necessary, we eliminate discrepancies.

   As a result, we should see a message like this:

   

5. We kiezen R80.20 Fresh Install and Upgrade for Security Management.
6. When installing the update, we select Clean Install. After installation, the system will reboot.
7. We go through the First Time Wizard.
8. After gaining access, we check the accounts.
9. We connect to SMS via SSH and change our user's shell to /bin/bash:

   set user shell /bin/bash

   save config (in case we want to keep bin/bash as the default shell after reboot).

10. Next, we connect to SMS via SCP and transfer the archive with the configuration in Binary mode SMS_w_logs_export_r77_r80.tgz kopiëren naar de map /var/log/UpgradeR77.30_R80.20/
    
11. We take the checksum from the archive: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz en vergelijken met de vorige waarde. De checksum moet overeenkomen.
12. We verhogen de timeout van de SSH-sessie tot 8 uur. Hiervoor:

    [Expert@HostName]# clish -c "show inactivity-timeout" Bekijk de huidige clish timeout,

    [Expert@HostName]# clish -c "set inactivity-timeout 720" Geef de nieuwe clish timeout op (in minuten),

    [Expert@HostName]# echo $TMOUT Bekijk de huidige expert mode timeout,

    [Expert@HostName]# export TMOUT=3600 geven we de nieuwe timeout op in de expertmodus (in seconden). Als je de waarde 0 instelt, wordt de timeout uitgeschakeld.

13. Voor het importeren van instellingen starten we het hulpprogramma migrate import. Hiervoor gaan we naar de map: cd $FWDIR/bin/upgrade_tools/en starten we de import: ./migrate imp
    ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

Geniet de komende paar uur van het leven. SCHAKEL DE SSH- sessie NIET UIT tijdens de procedure. Aan het einde zal het migratieproces een bericht geven over een succesvolle uitvoering of een fout. 

Checklist van controles na de update

1. Beschikbaarheid van middelen.
2. SIC met GW.
3. Licenties. Als de licenties niet correct worden weergegeven of niet op de SMS verschijnen, voeren we de opdracht uit vsec_central_licence voor het toewijzen van licenties.
4. Instelling van het beleid. 

Importeren van de SmartEvent database

1. Activeer de SmartEvent blade.
2. We verbinden via WinSCP met de SMS en verzenden in binaire modus de eerder geëxporteerde bestanden -db-backup.backup en eventiaUpgrade.tar kopiëren naar de map /var/log/UpgradeR77.30_R80.20/
3. We starten het script met de opdracht: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
4. We controleren de status: watch -n 10 eventiaUpgrade.sh
5. Controleer de logs in SmartEvent. Slaap!

We updaten de Check Point GW-cluster (Actief/Back-up)

Voorafgaand aan de werkzaamheden

1. Sla de GAIA-configuratie van elke node van het cluster op in een bestand, gebruik hiervoor de opdracht: clish -c "show configuration" > ./.txt
2. Exporteer de bestanden met WinSCP.
3. We verbinden met de WebUI van beide nodes en gaan naar het tabblad CPUSE → Toon alle pakketten.
4. Zoek het updatepakket voor de versie R80.20 Fresh Install, we drukken op Download.
5. Controleer of het CCP-protocol werkt in de modus Broadcast, voer hiervoor de opdracht in: cphaprob -a if
   Als de modus is geselecteerd Multicast, verander deze met de opdracht: cphaconf set_ccp broadcast (de opdracht wordt op elke node uitgevoerd).
6. Stel Downtime in voor de betrokken nodes in uw monitoringsysteem.
7. Controleer of de parameters op virtualisatieniveau zijn ingeschakeld MAC Address Change en Forged Transmits voor het sync-netwerk.

Bijwerken

1. We verbinden via SSH met de actieve node en voeren de opdracht uit om de status van het cluster te monitoren: watch -n 2 cphaprob stat
2. We keren terug naar de WebUI van de Standby-node naar het tabblad CPUSE en voor het geselecteerde pakket R80.20 Fresh Install starten we Verifier.
3. We analyseren het Verifier-rapport. Als de installatie is toegestaan, gaan we verder.
4. We selecteren het pakket R80.20 Fresh Install en starten we Upgrade. Tijdens de Upgrade zal het systeem opnieuw worden opgestart. De GAIA-instellingen worden opgeslagen. Tijdens de herstart volgen we de status van het cluster. Na het opstarten moet de status van de bijgewerkte node veranderen naar READY. In sommige gevallen hebben we ervaren dat de nog niet bijgewerkte node overging naar de status Actieve Aandacht en de status van de bijgewerkte node niet meer toonde. Maak je geen zorgen – deze situatie is ook mogelijk.
5. Na de update openen we SmartDashboard.
6. We openen het clusterobject en wijzigen de cluster versie van R77.30 naar R80.20. We klikken op Ok. Als er een foutmelding verschijnt bij het opslaan van wijzigingen:
   Er is een interne fout opgetreden. (Code: 0x8003001D, Er kon geen toegang tot het bestand worden verkregen voor schrijfoperatie),
   volg SK119973. Daarna slaan we de wijzigingen op en klikken op Install Policy.
7. In de instellingen halen we het vinkje weg bij de parameter Voor gatewayclusters, als de installatie op een clusterlid faalt, installeer dan niet op dat cluster.
8. We installeren het beleid. Het systeem geeft een foutmelding voor de actieve node die nog niet is bijgewerkt.
9. We verbinden met de bijgewerkte node via ssh en voeren de opdracht uit voor het monitoren van de status van het cluster: watch -n 2 cphaprob stat
10. We verbinden met de WebUI van de actieve node en gaan naar het tabblad CPUSE → Toon alle pakketten.Zoek het updatepakket voor de versie R80.20 Fresh Install, we klikken op Download.
11. Stel Downtime in voor de betrokken nodes in uw monitoringsysteem.
12. We keren terug naar de WebUI van de actieve node naar het tabblad CPUSE en voor het geselecteerde pakket R80.20 Fresh Install starten we Verifier.
13. We analyseren het Verifier-rapport. Als de installatie is toegestaan, gaan we verder.
14. We selecteren het pakket R80.20 Fresh Install en starten we Upgrade. Tijdens de Upgrade zal het systeem opnieuw worden opgestart. De GAIA-instellingen worden opgeslagen. Tijdens de herstart volgen we de status van het cluster op de al bijgewerkte node. Na de herstart verandert de status van het cluster op de bijgewerkte node van READY naar ACTIVE.
15. Wanneer het Upgrade-proces is voltooid, starten we SmartDashboard en installeren we het beleid.

Checklist van controles na de update

• Gebeurtenislogs in SmartLog, status van VPN-tunnels.
• GAIA-instellingen.
• Herstel van het cluster na een test Failover.
• Licenties en contracten. Als de licenties onjuist worden weergegeven of niet worden weergegeven op SMS, voeren we de opdracht uit. vsec_central_licence voor de verdeling van licenties.
• CoreXL.
• SecureXL.
• Hotfix en CPinfo op twee nodes.

Conclusie

Over het algemeen is dit het moment – je hebt geüpgraded.

Ons proces duurde gemiddeld van 6 tot 12 uur, afhankelijk van de grootte van de geëxporteerde databases. We werkten twee nachten: één voor de SMS-update, de andere voor het cluster.

Er was geen verkeersonderbreking, ondanks dat we al deze eerder genoemde fouten zelf hebben getest.

Natuurlijk kunnen zich soms ook geheel nieuwe moeilijkheden voordoen tijdens de update, maar dat is Check Point, en zoals we allemaal weten, is er altijd een hotfix!

Ik wens je veel plezierige zwart-roze nachten en updates!

Bron: habr.com