ProHoster > Blog > Administration > Opdaterer Check Point fra R77.30 til 80.20

Opdaterer Check Point fra R77.30 til 80.20

Opdaterer Check Point fra R77.30 til 80.20

I efteråret 2019 stoppede Check Point støtten til versioner R77.XX, og der var behov for opdatering. Der er allerede skrevet meget om forskellene mellem versionerne, fordele og ulemper ved overgangen til R80. Lad os i stedet tale om, hvordan man opdaterer Check Point virtuelle appliances (CloudGuard for VMware ESXi, Hyper-V, KVM Gateway NGTP) og hvad der kan gå galt.

Så vi havde 2 CCSE-ingeniører, mere end et dusin virtuelle klynger af Check Point R77.30, flere skyer, en smule hotfixes og et hav af forskellige fejl, problemer og alt sådan noget, i alle farver og størrelser, samt meget stramme tidsrammer. Lad os komme i gang!

Indhold:

Forberedelse
Opdaterer styringsserveren
Opdaterer klyngen

Opdaterer Check Point fra R77.30 til 80.20

Sådan ser en typisk kundes skyinfrastruktur ud med en virtuel Check Point

Forberedelse

Først skal ressourcernes tilstrækkelighed kontrolleres for opdateringen. De anbefalede minimumskrav til R80.20 ser nu sådan ud:

Device

CPU

RAM

HDD

Security Gateway

2 kerner

4 Gb

Fra 15 GB

SMS

2 kerner

6 Gb

—

Anbefalingerne er beskrevet i dokumentet CP_R80.20_GA_Release_Notes.

Men lad os være realistiske. Hvis dette er tilstrækkeligt i den minimale konfiguration, viser erfaringen, at HTTPS-inspektion normalt er aktiveret, SmartEvent kører på SMS osv., hvilket naturligvis kræver helt andre ressourcer. Men generelt set ikke meget mere end for R77.30.

Men der er nuancer. Og de vedrører før alt størrelsen på den fysiske hukommelse. Mange operationer under opdateringsprocessen vil kræve plads på harddisken.

For styringsserveren vil størrelsen på det frie plads på disken i høj grad afhænge af mængden af de nuværende logs (hvis vi ønsker at gemme dem) og antallet af gemte databaserevisioner, selvom vi ikke i større grad har brug for dem. Naturligvis er dette irrelevant for nodene i klyngen (medmindre du gemmer logs lokalt). Her er hvordan man kan kontrollere, om der er tilstrækkelig plads:

  1. Vi forbinder til Smart Management Server via SSH, går ind i eksperttilstand og indtaster kommandoen:

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

  2. Vi vil se en konfiguration som denne:

    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
    Vi er i øjeblikket interesseret i partitionen
    /dev/mapper/vg_splat-lv_log           243G  177G 53G  78% /var/log

  3. Vi er i øjeblikket interesseret i afsnittet /var/log

Husk, at afhængigt af politikken for opbevaring og sletning af gamle logfiler samt størrelsen af den eksporterede database, kan der være behov for mere plads. Hvis den ledige plads ved oprettelsen af arkivet bliver mindre end det angivne i logfilernes opbevaringspolitik, vil systemet begynde at slette gamle logs og INTE inkludere dem i arkivet.

Derudover har systemet brug for mindst 13 GB ikke-allokeret plads på harddisken til selve opdateringsprocessen. Du kan tjekke dette med kommandoen:

[Expert@cp-sms:0]# pvs

Vi vil se noget, der ligner dette output:

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

I dette tilfælde har vi 43 GB. Ressourcerne er tilstrækkelige. Vi kan begynde opdateringen.

Opdaterer Check Point SMS administrationsserver

Før du begynder, skal du gøre følgende:

  1. Installer Migration Tools-pakken på administrationsserveren. For dette skal du downloade billedet fra portalen. Check Point.
  2. Upload arkivet til administrationsserveren via WinSCP til mappen /var/log/UpgradeR77.30_R80.20 (hvis nødvendigt, opret mappen på forhånd).
  3. Opret forbindelse til administrationsserveren via SSH og gå ind i mappen med arkivet:cd /var/log/UpgradeR77.30_R80.20/
  4. Udpak filen:tar -zxvf ./.tgz
  5. Start pre_upgrade_verifier-værktøjet med kommandoen: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
  6. Når kommandoen er udført, vil der blive genereret en rapport om inkompatible indstillinger. Den er tilgængelig på adressen: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Det er nemmere at downloade den via SCP og se den i browseren.
    For at rette alle inkompatible indstillinger skal du bruge SK117237.
  7. Kør pre_upgrade_verifier-værktøjet igen for at sikre, at alle årsager til inkompatibilitet er løst.
  8. Dernæst samler vi oplysninger om netværksgrænseflader, routingtabel og eksporterer 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 "show configuration" > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
  9. Download den genererede fil via SCP.
  10. Tag et snapshot på virtualiseringsniveau.
  11. Øg timeout for SSH-sessionen til 8 timer. Dette afhænger af størrelsen på den eksporterede database, hvilket kan tage fra nogle minutter til flere timer. For dette: 
    [Expert@HostName]# clish -c "show inactivity-timeout" kontroller den nuværende clish timeout,

    [Expert@HostName]# clish -c "set inactivity-timeout 720" angiv den nye clish timeout (i minutter),

    [Expert@HostName]# echo $TMOUT kontroller den nuværende timeout for expert mode,

    [Expert@HostName]# export TMOUT=3600 angiv den nye timeout for expert mode (i sekunder); hvis du angiver værdien 0, vil timeout blive deaktiveret.

  12. Vi indlæser og monterer installationsbilledet SMS.iso til den virtuelle maskine.

    Før det næste trin, SKAL du igen sikre dig, at du har tilstrækkelig ikke-tilordnet plads på harddisken (jeg minder om, at du har brug for 13 GB). 

  13. Før vi starter eksporten af konfigurationen, ændrer vi logfilen med kommandoen: fw logswitch

Eksportér konfiguration og logfiler

  1. Vi starter værktøjet migrate_export for at eksportere konfigurationen. For at gøre dette går vi til den tidligere oprettede mappe: cd /var/log/UpgradeR77.30_R80.20/ og bruger kommandoen: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

    eller

    vi går ind i mappen: cd $FWDIR/bin/upgrade_tools/ og
    vi kører kommandoen derfra: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

  2. Vi tager checksum fra arkivet: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
  3. Vi gemmer den værdi, vi har fået, i en notesblok.
  4. Vi tilslutter os SMS via SCP og downloader arkivet med konfigurationen til arbejdsstationen. Sørg for at bruge filoverførsel i Binary format.

Eksport af SmartEvent databasen

Her har vi brug for en forudinstalleret SMS version R80. Enhver testversion vil være passende. 

  1. Fra SMS har vi brug for skripten, der ligger her:$RTDIR/bin/eva_db_backup.csh
  2. Via SCP uploader vi skripten eva_db_backup.csh til mappen: /var/log/UpgradeR77.30_R80.20/
  3. Vi tilslutter os SMS via SSH. Kopier filen til mappen: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
    $RTDIR/bin/eva_db_backup.csh
  4. Vi ændrer kodningen: dos2unix $RTDIR/bin/eva_db_backup.csh
  5. Vi tilføjer ejer: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
  6. Vi tilføjer rettigheder: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
  7. Vi starter eksporten af SmartEvent databasen: $RTDIR/bin/eva_db_backup.csh
  8. Vi downloader de modtagne filer via SCP: $RTDIR/bin/-db-backup.backup og $RTDIR/bin/eventiaUpgrade.tar til arbejdsstationen.

Opdatering

  1. Vi går til WebUI GAIA SMS → CPUSE → Vis alle pakker.
  2. I tilfælde af, at CPUSE giver en tilslutningsfejl til Check Point cloud, kontrollerer vi DGW, DNS og Proxy indstillinger.
  3. Hvis alt er korrekt, og fejlen ikke forsvinder, skal vi opdatere CPUSE manuelt ved at følge sk92449.
  4. Vi downloader billedet og går gennem Verifier. Hvis nødvendigt, retter vi uoverensstemmelser.

    Som resultat skal vi se denne meddelelse:

    Opdaterer Check Point fra R77.30 til 80.20

  5. Vi vælger R80.20 Fresh Install and Upgrade for Security Management.
  6. Ved installation af opdateringen vælger vi Clean Install. Systemet genstarter efter installationen.
  7. Vi gennemgår First Time Wizard.
  8. Efter at have fået adgang, kontrollerer vi brugerprofilerne.
  9. Vi tilslutter os SMS via SSH og skifter shell for vores bruger til /bin/bash:

    set user shell /bin/bash

    save config (i tilfælde af, at vi ønsker at efterlade bin/bash som standard shell selv efter genstart).

  10. Derefter tilslutter vi os SMS via SCP og overfører arkivet med konfigurationen i Binary tilstand SMS_w_logs_export_r77_r80.tgz til mappen /var/log/UpgradeR77.30_R80.20/
  11. Vi tager checksum fra arkivet: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz og sammenligner med den tidligere værdi. Checksum skal matche.
  12. Vi øger timeout for SSH-sessionen til 8 timer. For at gøre dette:

    [Expert@HostName]# clish -c "show inactivity-timeout" kontroller den nuværende clish timeout,

    [Expert@HostName]# clish -c "set inactivity-timeout 720" angiv den nye clish timeout (i minutter),

    [Expert@HostName]# echo $TMOUT kontroller den nuværende timeout for expert mode,

    [Expert@HostName]# export TMOUT=3600 angiver vi den nye timeout i eksperttilstand (i sekunder). Hvis værdien sættes til 0, vil timeout blive slået fra.

  13. For at importere indstillingerne skal vi køre migrationsværktøjet migrate import. For dette går vi ind i mappen: cd $FWDIR/bin/upgrade_tools/og starter importen: ./migrate imp
    ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

Nyd livet de næste par timer. MÅ IKKE SLUKKE SSH-SESSIONEN under proceduren. Til slut vil migrate proces give enten en besked om vellykket afslutning af operationen eller en fejl. 

Tjekliste til kontrol efter opdatering

  1. Tilgængelighed af ressourcer.
  2. SIC med GW.
  3. Licenser. Hvis licenserne vises forkert eller ikke vises på SMS, kører vi kommandoen vsec_central_licence for at distribuere licenserne.
  4. Installation af politik. 

Import af SmartEvent-database

  1. Aktivér SmartEvent-bladet.
  2. Vi forbinder via WinSCP til SMS og overfører de tidligere eksporterede filer i binært format -db-backup.backup og eventiaUpgrade.tar til mappen /var/log/UpgradeR77.30_R80.20/
  3. Vi starter scriptet med kommandoen: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
  4. Vi tjekker status: watch -n 10 eventiaUpgrade.sh
  5. Vi tjekker loggene i SmartEvent. SØVN!

Opdaterer Check Point GW-klyngen (Aktiv/Sikkerhedskopi)

Før arbejdet påbegyndes

  1. Gem GAIA-konfigurationen fra hver node i klyngen i en fil ved at bruge kommandoen: clish -c "show configuration" > ./.txt
  2. Vi overfører filer ved hjælp af WinSCP.
  3. Vi forbinder til WebUI på begge noder og går til fanen CPUSE → Vis alle pakker.
  4. Find opdateringspakken til versionen R80.20 Fresh Install, klik på Download.
  5. Vi tjekker, at CCP-protokollen fungerer i broadcast, for at gøre dette indtaster vi kommandoen: cphaprob -a if
    Hvis den valgte tilstand Multicast, ændr det med kommandoen: cphaconf set_ccp broadcast (kommandoen udføres på hver node).
  6. Vi sætter Downtime for de involverede noder i dit overvågningssystem.
  7. Vi tjekker, at de virtuelle parametre er aktiveret MAC Address Change og Forged Transmits for sync-netværket.

Opdatering

  1. Vi forbinder via ssh til den aktive node og kører kommandoen for at overvåge klyngets tilstand: watch -n 2 cphaprob stat
  2. Vi vender tilbage til WebUI Standby-noden på fanen CPUSE og for den valgte pakke R80.20 Fresh Install starter Verifier.
  3. Vi analyserer Verifier-rapporten. Hvis installationen er tilladt, går vi videre.
  4. Vi vælger pakken R80.20 Fresh Install og starter Upgrade. Under opgraderingen genstarter systemet. GAIA-indstillingerne gemmes. Under genstart overvåger vi tilstanden af klyngen. Efter genstart skal den opdaterede nodes status ændres til READY. I nogle tilfælde har vi oplevet, at den endnu ikke opdaterede node skiftede til status Active Attention og stoppede med at vise den opdaterede nodes status. Lad ikke dette bekymre dig - en sådan mulighed er også tilladt.
  5. Når opgraderingen er fuldført, åbner vi SmartDashboard.
  6. Vi åbner klyngeobjektet og ændrer klyngeversionen fra R77.30 til R80.20. Vi trykker Ok. Hvis der opstår en fejl under gemmingen af ændringer:
    En intern fejl er opstået. (Kode: 0x8003001D, Kunne ikke få adgang til filen til skriveoperation),
    følg SK119973. Efter dette gemmer vi ændringerne og trykker Install Policy.
  7. I indstillingerne fjerner vi fluebenet fra parameteren For gateway-klynger, hvis installationen på et klyngeelement fejler, må du ikke installere på den klynge.
  8. Vi installerer politikken. Systemet vil give en fejl for Active-noden, som endnu ikke er blevet opdateret.
  9. Vi opretter forbindelse til den opdaterede node via ssh og kører kommandoen for at overvåge tilstanden af klyngen: watch -n 2 cphaprob stat
  10. Vi opretter forbindelse til WebUI på Active-noden og går til fanen CPUSE → Vis alle pakker.Find opdateringspakken til versionen R80.20 Fresh Install, trykker vi på Download.
  11. Vi sætter Downtime for de involverede noder i dit overvågningssystem.
  12. Vi går tilbage til WebUI på Active-noden til fanen CPUSE og for den valgte pakke R80.20 Fresh Install starter Verifier.
  13. Vi analyserer Verifier-rapporten. Hvis installationen er tilladt, går vi videre.
  14. Vi vælger pakken R80.20 Fresh Install og starter Upgrade. Under opgraderingen genstarter systemet. GAIA-indstillingerne gemmes. Under genstart overvåger vi tilstanden af klyngen på den allerede opdaterede node. Efter genstart ændres tilstanden af klyngen på den opdaterede node fra READY til ACTIVE.
  15. Når opgraderingsprocessen er afsluttet, starter vi SmartDashboard og installerer politikken.

Tjekliste til kontrol efter opdatering

  • Hændelseslogfiler i SmartLog, tilstanden af VPN-tunneller.
  • GAIA-indstillinger.
  • Gendannelse af klyngen efter testet Failover.
  • Licenser og kontrakter. Hvis licenserne vises forkert eller ikke vises på SMS, kører vi kommandoen vsec_central_licence for distribution af licenser.
  • CoreXL.
  • SecureXL.
  • Hotfix og CPinfo på to noder.

Konklusion

Generelt set er det alt - du er blevet opgraderet.

Hele processen tog os gennemsnitligt mellem 6 og 12 timer, afhængigt af størrelsen på de eksporterede databaser. Arbejdet blev udført over to nætter: den ene for opgradering af SMS, den anden for klyngen.

Der var ingen trafiknedbrud, selvom vi har tjekket alle ovennævnte fejl på os selv.

Selvfølgelig kan der opstå helt nye vanskeligheder under opgraderingen, men det er Check Point, og som vi alle ved, findes der altid hotfix!

Ønsker dig held og lykke med de sort-rosa nætter og opgraderinger!

Kilde: habr.com

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster