Hösten 2019 slutade Check Point att stödja versionerna R77.XX och det var nödvändigt att uppdatera. Mycket har redan sagts om skillnaden mellan versionerna, för- och nackdelarna med att byta till R80. Låt oss prata om hur man faktiskt uppdaterar Check Point virtuella apparater (CloudGuard för VMware ESXi, Hyper-V, KVM Gateway NGTP) och vad som kan gå fel.
Så vi hade 2 CCSE-ingenjörer, mer än ett dussin Check Point R77.30 virtuella kluster, flera moln, några snabbkorrigeringar och ett helt hav av olika buggar, fel och allt det där, i alla färger och storlekar, och också mycket snäva deadlines. Nu går vi!
Innehåll:
Så här ser en typisk klients molninfrastruktur med virtuell Check Point ut
Utbildning
Det första steget är att kontrollera om det finns tillräckligt med resurser för uppdateringen. De rekommenderade minimikraven för R80.20 ser för närvarande ut så här:
Anordning
CPU
RAM
HDD
Säkerhetsgateway
2 kärna
4 Gb
Från 15 GB
SMS
2 kärna
6 Gb
-
Rekommendationer beskrivs i dokumentet .
Men vi kommer att vara realistiska. Om detta räcker i den mest minimala konfigurationen, så har vi, som praxis visar, vanligtvis https-inspektion aktiverad, SmartEvent körs på SMS, etc., vilket naturligtvis kräver helt andra kapaciteter. Men i allmänhet inte mer än för R77.30.
Men det finns nyanser. Och de relaterar först och främst till storleken på fysiskt minne. Många operationer direkt under uppdateringsprocessen kräver hårddiskutrymme.
För hanteringsservern kommer storleken på ledigt diskutrymme mycket att bero på volymen av aktuella loggar (om vi vill spara dem) och på antalet sparade databasrevisioner, även om vi inte längre kommer att behöva dem i stora mängder. Naturligtvis spelar allt detta ingen roll för klusternoder (såvida du inte också lagrar loggar lokalt). Så här kontrollerar du om du har det utrymme du behöver:
- Vi ansluter till Smart Management Server via ssh, går till expertläge och anger kommandot:
[Expert@cp-sms:0]# df -h
- Vid utgången kommer vi att se något i stil med denna konfiguration:
Filsystem Storlek använd Tillgänglig användning% monterad på
/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 - Vi är just nu intresserade av avsnittet / Var / log
Observera att beroende på policyn för att lagra och ta bort gamla loggfiler, samt storleken på den exporterade databasen, kan mer utrymme behövas. Om, när du skapar ett arkiv, det finns mindre ledigt utrymme än vad som anges i loggfillagringspolicyn, kommer systemet att börja radera gamla loggar och kommer INTE att inkludera dem i arkivet.
Dessutom kommer systemet att behöva minst 13 GB oallokerat hårddiskutrymme för själva uppdateringsprocessen. Du kan kontrollera dess närvaro med kommandot:
[Expert@cp-sms:0]# pvs
Vi kommer att se något sånt här:
PV VG Fmt Attr PSize PFree
/dev/sda3 vg_splat lvm2 a- 141.69G 43.69G
I det här fallet har vi 43 GB. Det finns tillräckligt med resurser. Du kan börja uppdatera.
Uppdaterar Check Point SMS-hanteringsserver
Innan du börjar arbeta måste du göra följande:
- Installera Migration Tools-paketet på hanteringsservern. För att göra detta måste du ladda ner bilden från portalen.
- Ladda upp arkivet till hanteringsservern via WinSCP till mappen /var/log/UpgradeR77.30_R80.20 (om nödvändigt, skapa en mapp först).
- Anslut till hanteringsservern via SSH och gå till mappen med arkivet:cd /var/log/UpgradeR77.30_R80.20/
- Packa upp filen:tar -zxvf ./<filnamn>.tgz
- Vi startar pre_upgrade_verifier-verktyget med kommandot: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
- Vid körning av kommandot kommer en rapport om inkompatibla inställningar att genereras. Den finns på: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Det är bekvämare att ladda upp det via SCP och titta på det via en webbläsare.
För att lösa eventuella inkompatibla inställningar, använd. - Kör sedan om verktyget pre_upgrade_verifier för att se till att alla orsaker till inkompatibilitet elimineras.
- Därefter samlar vi in information om nätverksgränssnitt, routingtabellen och laddar upp GAIA-konfigurationen:
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 "visa konfiguration" > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt - Ladda upp den resulterande filen via SCP.
- Vi tar en ögonblicksbild på virtualiseringsnivå.
- Vi ökar timeouten för SSH-sessionen till 8 timmar. Det beror på din tur: beroende på storleken på den exporterade databasen kan den pågå från flera minuter till flera timmar. För detta:
[Expert@HostName]# clish -c "visa timeout för inaktivitet" titta på den aktuella timeout-clishen,[Expert@HostName]# clish -c "set inactivity-timeout 720" ange den nya timeout clish (i minuter),
[Expert@HostName]# eko $TMOUT titta på det aktuella expertläget för timeout,
[Expert@HostName]# export TMOUT=3600 ange det nya expertläget för timeout (i sekunder), om du ställer in värdet till 0, kommer timeout att inaktiveras.
- Vi laddar ner och monterar SMS.iso installationsbilden till den virtuella maskinen.
Innan nästa steg, SE till att dubbelkolla att du har tillräckligt med oallokerat utrymme på din hårddisk (kom ihåg att du behöver 13 GB).
- Innan du börjar exportera konfigurationen, ändra loggfilen med kommandot: fw loggbrytare
Exportera konfiguration och loggar
- Kör verktyget migrate_export för att ladda ner konfigurationen. För att göra detta, gå till den tidigare skapade mappen: cd /var/log/UpgradeR77.30_R80.20/ och använd kommandot: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
eller
gå till mappen: cd $FWDIR/bin/upgrade_tools/ и
kör kommandot därifrån: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz - Vi tar bort checksumma från arkivet: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Spara det resulterande värdet i anteckningsblocket.
- Vi ansluter till SMS via SCP och laddar upp arkivet med konfigurationen till arbetsstationen. Se till att använda filöverföring i binärt format.
Exportera SmartEvent-databas
Här behöver vi den förinstallerade SMS-versionen R80. Alla test duger.
- Från SMS behöver vi ett skript som finns här:$RTDIR/bin/eva_db_backup.csh
- Ladda skriptet via SCP eva_db_backup.csh till mapp: /var/log/UpgradeR77.30_R80.20/
- Anslut via SSH till SMS. Kopiera fil till mapp: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$RTDIR/bin/eva_db_backup.csh - Ändra kodningen: dos2unix $RTDIR/bin/eva_db_backup.csh
- Lägga till ägaren: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
- Lägg till rättigheter: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
- Låt oss börja exportera SmartEvent-databasen: $RTDIR/bin/eva_db_backup.csh
- Ladda upp de mottagna filerna via SCP: $RTDIR/bin/<datum>-db-backup.backup и $RTDIR/bin/eventiaUpgrade.tar till arbetsstationen.
Uppdatera
- Gå till WebUI GAIA SMS → CPUSE → Visa alla paket.
- Om CPUSE ger ett fel vid anslutning till Check Point-molnet, kontrollera DGW, DNS och proxyinställningar.
- Om allt är korrekt och felet inte försvinner, måste du uppdatera CPUSE manuellt, guidad av.
- Ladda ner bilden och gå igenom Bekräftare. Vid behov eliminerar vi inkonsekvenser.
Som ett resultat bör du se detta meddelande:
- Välj R80.20 Nyinstallation och uppgradering för säkerhetshantering.
- När du installerar uppdateringen väljer du Ren installation. Efter installationen kommer systemet att starta om.
- Vi passerar First Time Trollkarl.
- Efter att ha fått tillgång kontrollerar vi kontona.
- Vi ansluter till SMS via SSH och ändrar vår användares skal till /bin/bash/:
ställ in användar <användarnamn> skal /bin/bash/
spara konfiguration (om vi vill lämna bin/bash/ som standardskal efter omstart).
- Därefter ansluter vi till SMS via SCP och överför arkivet med konfigurationen i binärt läge SMS_w_logs_export_r77_r80.tgz till en mapp /var/log/UpgradeR77.30_R80.20/
- Vi tar bort checksumma från arkivet: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz och jämför med föregående värde. Kontrollsumman måste matcha.
- Vi ökar timeouten för SSH-sessionen till 8 timmar. För detta:
[Expert@HostName]# clish -c "visa timeout för inaktivitet" titta på den aktuella timeout-clishen,
[Expert@HostName]# clish -c "set inactivity-timeout 720" ange den nya timeout clish (i minuter),
[Expert@HostName]# eko $TMOUT titta på det aktuella expertläget för timeout,
[Expert@HostName]# export TMOUT=3600 ange det nya expertläget för timeout (i sekunder). Om du ställer in värdet till 0, kommer timeout att inaktiveras.
- För att importera inställningar, kör verktyget migrera import. För att göra detta, gå till mappen: cd $FWDIR/bin/upgrade_tools/och kör importen: ./migrera imp
ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Låt oss njuta av livet de kommande timmarna. KOPPLA INTE ifrån din SSH-SESSION under proceduren. I slutet kommer migreringsprocessen antingen att visa ett framgångsrikt meddelande eller ett fel.
Checklista efter uppdatering
- Tillgänglighet av resurser.
- SIC med GW.
- Licenser. Om licenser visas felaktigt eller inte visas på SMS, kör kommandot vsec_central_licence för licensdistribution.
- Fastställer policyn.
Importerar SmartEvent-databas
- Aktivera SmartEvent-bladet.
- Vi ansluter via WinSCP till SMS och överför tidigare nedladdade filer i binärt läge <datum>-db-backup.backup и eventiaUpgrade.tar till en mapp /var/log/UpgradeR77.30_R80.20/
- Vi kör skriptet med kommandot: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
- Kontrollera status: titta -n 10 eventiaUpgrade.sh
- Kontrollerar loggarna i SmartEvent. DRÖM!
Uppdatering av Check Point GW-klustret (aktiv/backup)
Innan du börjar arbeta
- Vi sparar GAIA-konfigurationen från varje klusternod till en fil, för att göra detta använder vi kommandot: clish -c "visa konfiguration" > ./<Filnamn>.txt
- Ladda upp filer med WinSCP.
- Anslut till webbgränssnittet för båda noderna och gå till fliken CPUSE → Visa alla paket.
- Hitta uppdateringspaketet för versionen R80.20 Nyinstallerad, Tryck Hämta.
- Vi kontrollerar att CCP-protokollet fungerar i läget Utsända, för att göra detta, skriv in kommandot: cphaprob -a if
Om läget är valt multicast, ersätt det med kommandot: cphaconf set_ccp sändning (kommandot exekveras på varje nod). - Vi installerar Downtime för de inblandade noderna i ditt övervakningssystem.
- Vi kontrollerar att parametrarna är aktiverade på virtualiseringsnivå Ändra MAC-adress и Smidda sändningar för ett synknätverk.
Uppdatera
- Vi ansluter via ssh till den aktiva noden och kör kommandot för att övervaka klustrets status: titta -n 2 cphaprob stat
- Återgå till fliken WebUI Stanby noder CPUSE och för det valda paketet R80.20 Nyinstallerad lansera Bekräftare.
- Låt oss analysera Verifier-rapporten. Om installationen är tillåten, gå vidare.
- Välj ett paket R80.20 Nyinstallerad och lansera Uppgradera. Under uppgraderingsprocessen kommer systemet att starta om. GAIA-inställningarna sparas. Vid tidpunkten för omstart övervakar vi klustrets tillstånd. Efter laddning bör statusen för den uppdaterade noden ändras till READY. I ett antal fall stötte vi på ett ögonblick då en nod som ännu inte hade uppdaterats bytte till statusen Active Attention och slutade visa statusen för den uppdaterade noden. Var inte orolig - det här alternativet är också acceptabelt.
- Öppna när uppdateringen är klar Smart Dashboard.
- Öppna klusterobjektet och ändra klusterversionen från R77.30 till R80.20. Klicka på OK. Om ett fel visas när ändringarna sparas:
Ett internt fel har uppstått. (Kod: 0x8003001D, kunde inte komma åt filen för skrivoperation),
Följ. Efter det, spara ändringarna och klicka Installationspolicy. - Avmarkera alternativet i inställningarna För gateway-kluster, om installationen på en klustermedlem misslyckas, installera inte på det klustret.
- Vi sätter policyn. Systemet kommer att generera ett fel för en aktiv nod som ännu inte har uppdaterats.
- Vi ansluter till den uppdaterade noden via ssh och kör kommandot för att övervaka klustrets tillstånd: titta -n 2 cphaprob stat
- Anslut till WebUI Active-noden och gå till fliken CPUSE → Visa alla paket.Hitta uppdateringspaketet för versionen R80.20 Nyinstallerad, Tryck Hämta.
- Vi installerar Downtime för de inblandade noderna i ditt övervakningssystem.
- Återgå till fliken WebUI Active nodes CPUSE och för det valda paketet R80.20 Nyinstallerad lansera Bekräftare.
- Låt oss analysera Verifier-rapporten. Om installationen är tillåten, gå vidare.
- Välj ett paket R80.20 Nyinstallerad och lansera Uppgradera. Under uppgraderingsprocessen kommer systemet att starta om. GAIA-inställningarna sparas. Vid tidpunkten för omstart övervakar vi klustrets tillstånd på den redan uppdaterade noden. Efter omstarten kommer klustertillståndet på den uppdaterade noden att ändras från READY till ACTIVE.
- När uppgraderingsprocessen är klar, starta SmartDashboard och installera policyn.
Checklista efter uppdatering
- Händelseloggar i SmartLog, status för VPN-tunnlar.
- GAIA-inställningar.
- Återställer ett kluster efter ett testfailover.
- Licenser och kontrakt. Om licenser visas felaktigt eller inte visas på SMS, kör kommandot. vsec_central_licence för licensdistribution.
- CoreXL.
- SecureXL.
- Snabbkorrigering och CPinfo på två noder.
Slutsats
I allmänhet är det allt vid det här laget - du har blivit uppdaterad.
För oss tog hela processen i genomsnitt från 6 till 12 timmar, beroende på storleken på de exporterade databaserna. Arbetet genomfördes under två nätter: en för uppdatering av SMS, den andra för klustret.
Det blev ingen trafikstopp, trots att vi kontrollerat alla ovan nämnda fel på oss själva.
Självklart kan det ibland uppstå helt nya svårigheter under uppdateringsprocessen, men det här är Check Point, och som vi alla vet finns det alltid en snabbfix!
Glada svarta och rosa nätter och uppdateringar!
Källa: will.com