Nell'autunno del 2019, Check Point ha interrotto il supporto per le versioni R77.XX, rendendo necessaria l'upgrade. Si è già parlato ampiamente delle differenze tra le versioni, dei pro e dei contro del passaggio a R80. Discutiamo piuttosto su come aggiornare effettivamente gli appliance virtuali Check Point (CloudGuard per VMware ESXi, Hyper-V, KVM Gateway NGTP) e cosa potrebbe andare storto.
Quindi, avevamo 2 ingegneri CCSE, oltre dieci cluster virtuali Check Point R77.30, diversi cloud, alcuni hotfix e un mare di bug e glitch di ogni genere e dimensione, oltre a tempi molto ristretti. Iniziamo!
Contenuto:
Questo è come appare una tipica infrastruttura cloud del cliente con Check Point virtuale
Preparazione
Per prima cosa, è necessario verificare la sufficienza delle risorse per l'aggiornamento. I requisiti minimi raccomandati per R80.20 sono attualmente i seguenti:
Dispositivo
CPU
RAM
HDD
Security Gateway
2 core
4 Gb
A partire da 15 GB
SMS
2 core
6 Gb
—
Le raccomandazioni sono descritte nel documento .
Ma siamo realistici. Se per la configurazione minimale questo è sufficiente, la pratica dimostra che di solito attiviamo l'ispezione https, SmartEvent funziona su SMS, e così via, il che richiede, naturalmente, potenze completamente diverse. Tuttavia, in generale, non molto maggiori rispetto a R77.30.
Ma ci sono delle sfumature. E riguardano principalmente le dimensioni della memoria fisica. Molte operazioni durante l'aggiornamento richiederanno spazio su disco.
Per il server di gestione, la dimensione dello spazio libero su disco dipenderà molto dal volume dei log attuali (se desideriamo conservarli) e dal numero di revisioni della Database salvate, anche se quest'ultime non ci saranno necessarie in gran numero. Ovviamente, per i nodi del cluster (a meno che non conserviate i log anche localmente) tutto questo non ha importanza. Ecco come possiamo verificare la disponibilità dello spazio necessario:
- Ci connettiamo al Smart Management Server via ssh, entriamo in modalità esperto e digitiamo il comando:
[Expert@cp-sms:0]# df -h
- L'output mostrerà una configurazione simile:
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 - In questo momento ci interessa la partizione /var/log
Si prega di tenere presente che a seconda della politica di conservazione e cancellazione dei registri, nonché della dimensione del database esportato, potrebbe essere necessario più spazio. Se durante la creazione dell'archivio lo spazio libero diventa inferiore a quanto indicato nella politica di conservazione dei registri, il sistema inizierà a cancellare i log più vecchi e NON li includerà nell'archivio.
Inoltre, per il processo di aggiornamento, il sistema avrà bisogno di almeno 13 GB di spazio non allocato su disco. Puoi verificarne la disponibilità con il comando:
[Expert@cp-sms:0]# pvs
Vedremo un output simile a questo:
PV VG Fmt Attr PSize PFree
/dev/sda3 vg_splat lvm2 a- 141.69G 43.69G
In questo caso abbiamo 43 GB. Le risorse sono sufficienti. Possiamo procedere con l'aggiornamento.
Aggiorniamo il server di gestione Check Point SMS
Prima di iniziare, è necessario fare quanto segue:
- Installa il pacchetto Migration Tools sul server di gestione. A tale scopo, è necessario scaricare l'immagine dal portale.
- Carica l'archivio sul server di gestione tramite WinSCP nella cartella /var/log/UpgradeR77.30_R80.20 (se necessario, crea prima la cartella).
- Collegati al server di gestione tramite SSH e accedi alla cartella con l'archivio:cd /var/log/UpgradeR77.30_R80.20/
- Decomprimere il file:tar -zxvf ./.tgz
- Avvia l'utilità pre_upgrade_verifier con il comando: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
- Al termine del comando verrà generato un report sulle impostazioni incompatibili. È disponibile all'indirizzo: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). È più comodo esportarlo tramite SCP e visualizzarlo tramite un browser.
Per risolvere tutte le impostazioni incompatibili, utilizza. - Dopo, riavvia l'utilità pre_upgrade_verifier per assicurarti che tutte le cause di incompatibilità siano state risolte.
- Successivamente raccogliamo informazioni sulle interfacce di rete, sulla tabella di routing e esportiamo la configurazione 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 - Esportiamo il file ottenuto tramite SCP.
- Facciamo uno snapshot a livello di virtualizzazione.
- Aumentiamo il timeout della sessione SSH a 8 ore. Qui dipende: a seconda delle dimensioni del database esportato, può durare da pochi minuti a diverse ore. Per fare ciò:
[Expert@HostName]# clish -c "show inactivity-timeout" controlliamo il timeout attuale di clish,[Expert@HostName]# clish -c "set inactivity-timeout 720" impostiamo il nuovo timeout di clish (in minuti),
[Expert@HostName]# echo $TMOUT controlliamo il timeout attuale della modalità esperto,
[Expert@HostName]# export TMOUT=3600 impostiamo il nuovo timeout della modalità esperto (in secondi); impostando il valore 0, il timeout verrà disattivato.
- Stiamo caricando e montando l'immagine di installazione SMS.iso sulla macchina virtuale.
Prima del passaggio successivo, controlla OBBLIGATORIAMENTE di avere abbastanza spazio non allocato sul disco rigido (ricordo, servono 13 GB).
- Prima di iniziare l'esportazione della configurazione, cambiamo il file di log con il comando: fw logswitch
Esportazione della configurazione e dei log
- Avviamo l'utility migrate_export per esportare la configurazione. Per fare ciò, andiamo nella cartella precedentemente creata: cd /var/log/UpgradeR77.30_R80.20/ e utilizziamo il comando: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
oppure
andiamo nella cartella: cd $FWDIR/bin/upgrade_tools/ e
eseguiamo da lì il comando: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz - Estraiamo il checksum dall'archivio: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Salviamo in un file di testo il valore ottenuto.
- Ci connettiamo a SMS tramite SCP e trasferiamo l'archivio con la configurazione sulla workstation. Utilizzare assolutamente la trasmissione dei file in formato Binary.
Esportazione del database SmartEvent
Qui avremo bisogno di SMS già installato in versione R80. Qualsiasi versione di test andrà bene.
- Dal SMS ci serve lo script, situato qui:$RTDIR/bin/eva_db_backup.csh
- Carichiamo lo script tramite SCP eva_db_backup.csh nella cartella: /var/log/UpgradeR77.30_R80.20/
- Ci connettiamo via SSH a SMS. Copiamo il file nella cartella: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$RTDIR/bin/eva_db_backup.csh - Modifichiamo la codifica: dos2unix $RTDIR/bin/eva_db_backup.csh
- Aggiungiamo il proprietario: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
- Aggiungiamo i permessi: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
- Iniziamo l'esportazione del database SmartEvent: $RTDIR/bin/eva_db_backup.csh
- Carichiamo i file ottenuti tramite SCP: $RTDIR/bin/-db-backup.backup e $RTDIR/bin/eventiaUpgrade.tar sul workstation.
Aggiornamento
- Andiamo su WebUI GAIA SMS → CPUSE → Mostra tutti i pacchetti.
- Se CPUSE restituisce un errore di connessione al cloud Check Point, verifichiamo DGW, DNS e impostazioni del proxy.
- Se tutto è corretto e l'errore persiste, sarà necessario aggiornare CPUSE manualmente, seguendo.
- Scarichiamo l'immagine e procediamo Verifier. Se necessario, risolviamo le discrepanze.
Dovremmo visualizzare il seguente messaggio:
- Selezioniamo R80.20 Installazione Fresca e Aggiornamento per la Gestione della Sicurezza.
- Durante l'installazione dell'aggiornamento, selezioniamo Installazione Pulita. Dopo l'installazione, il sistema si riavvierà.
- Procediamo con il Primo Wizard.
- Dopo aver ottenuto l'accesso, verifichiamo gli account.
- Ci connettiamo a SMS tramite SSH e cambiamo la shell del nostro utente in /bin/bash/:
set user shell /bin/bash/
salva configurazione (nel caso in cui vogliamo mantenere /bin/bash come shell predefinita anche dopo il riavvio).
- Successivamente, ci connettiamo a SMS tramite SCP e in modalità Binaria trasferiamo l'archivio con la configurazione SMS_w_logs_export_r77_r80.tgz nella cartella /var/log/UpgradeR77.30_R80.20/
- Estraiamo il checksum dall'archivio: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz e confrontiamo con il valore precedente. I checksum devono corrispondere.
- Aumentiamo il timeout della sessione SSH a 8 ore. Per fare ciò:
[Expert@HostName]# clish -c "show inactivity-timeout" controlliamo il timeout attuale di clish,
[Expert@HostName]# clish -c "set inactivity-timeout 720" impostiamo il nuovo timeout di clish (in minuti),
[Expert@HostName]# echo $TMOUT controlliamo il timeout attuale della modalità esperto,
[Expert@HostName]# export TMOUT=3600 indichiamo un nuovo timeout in modalità esperto (in secondi). Se impostiamo il valore a 0, il timeout sarà disattivato.
- Per importare le impostazioni, avviamo l'utilità migrate import. Per fare ciò, entriamo nella cartella: cd $FWDIR/bin/upgrade_tools/e avviamo l'importazione: ./migrate imp
ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Godiamoci la vita nelle prossime ore. NON DISCONNETTERE LA SESSIONE SSH durante la procedura. Alla fine, il processo migrate fornirà un messaggio di successo o un errore.
Checklist di verifica dopo l'aggiornamento
- Disponibilità delle risorse.
- SIC con GW.
- Licenze. Se le licenze vengono visualizzate in modo errato o non vengono visualizzate su SMS, eseguiamo il comando vsec_central_licence per la distribuzione delle licenze.
- Installazione della policy.
Importa il database SmartEvent
- Attiva il blade SmartEvent.
- Colleghiamoci tramite WinSCP a SMS e in modalità binary trasferiamo i file precedentemente esportati -db-backup.backup e eventiaUpgrade.tar nella cartella /var/log/UpgradeR77.30_R80.20/
- Eseguiamo lo script con il comando: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
- Controlliamo lo stato: watch -n 10 eventiaUpgrade.sh
- Controlliamo i log in SmartEvent. Pausa!
Aggiorniamo il cluster Check Point GW (Attivo/Backup)
Prima di iniziare i lavori
- Salviamo la configurazione GAIA da ogni nodo del cluster in un file, per fare ciò utilizziamo il comando: clish -c "show configuration" > ./.txt
- Esportiamo i file utilizzando WinSCP.
- Colleghiamoci al WebUI di entrambi i nodi e accediamo alla scheda CPUSE → Mostra tutti i pacchetti.
- Troviamo il pacchetto di aggiornamenti per la versione R80.20 Fresh Install, facciamo clic su Download.
- Verifichiamo che il protocollo CCP funzioni in modalità Broadcast, per fare ciò inseriamo il comando: cphaprob -a if
Se è selezionata la modalità Multicast, cambiarla con il comando: cphaconf set_ccp broadcast (il comando deve essere eseguito su ogni nodo). - Impostiamo il Downtime per i nodi coinvolti nel vostro sistema di monitoraggio.
- Verifichiamo che a livello di virtualizzazione siano attivate le opzioni Cambiamento dell'indirizzo MAC e Trasmissioni falsificate per la rete sync.
Aggiornamento
- Colleghiamoci via ssh al nodo Active e avviamo il comando per monitorare lo stato del cluster: watch -n 2 cphaprob stat
- Torniamo nel WebUI del nodo Stanby alla scheda CPUSE e per il pacchetto selezionato R80.20 Fresh Install avviamo Verifier.
- Analizziamo il rapporto Verifier. Se l'installazione è consentita, procediamo.
- Selezioniamo il pacchetto R80.20 Fresh Install e avviamo Aggiorna. Durante l'Upgrade, il sistema verrà riavviato. Le impostazioni di GAIA vengono salvate. Durante il riavvio, monitoriamo lo stato del cluster. Dopo il caricamento, lo stato del nodo aggiornato deve cambiare in READY. In alcuni casi, abbiamo avuto momenti in cui il nodo non aggiornato passava allo stato Active Attention e smetteva di visualizzare lo stato del nodo aggiornato. Non preoccupatevi, questa possibilità è accettabile anche.
- Al termine dell'aggiornamento, apriamo SmartDashboard.
- Apriamo l'oggetto del cluster e cambiamo la versione del cluster da R77.30 a R80.20. Facciamo clic su Ok. Se durante il salvataggio delle modifiche appare l'errore:
Si è verificato un errore interno. (Codice: 0x8003001D, Impossibile accedere al file per l'operazione di scrittura),
seguire. Dopo di che, salviamo le modifiche e facciamo clic su Install Policy. - Nelle impostazioni togliamo il segno di spunta dall'opzione Per i cluster gateway, se l'installazione su un membro del cluster fallisce, non installare su quel cluster.
- Installiamo la politica. Il sistema darà un errore per il nodo Active che non è ancora aggiornato.
- Ci connettiamo al nodo aggiornato tramite ssh e avviamo il comando per monitorare lo stato del cluster: watch -n 2 cphaprob stat
- Ci connettiamo al WebUI del nodo Active e andiamo alla scheda CPUSE → Mostra tutti i pacchetti.Troviamo il pacchetto di aggiornamenti per la versione R80.20 Fresh Install, facciamo clic su Download.
- Impostiamo il Downtime per i nodi coinvolti nel vostro sistema di monitoraggio.
- Torniamo al WebUI del nodo Active alla scheda CPUSE e per il pacchetto selezionato R80.20 Fresh Install avviamo Verifier.
- Analizziamo il rapporto Verifier. Se l'installazione è consentita, procediamo.
- Selezioniamo il pacchetto R80.20 Fresh Install e avviamo Upgrade. Durante l'upgrade, il sistema verrà riavviato. Le impostazioni di GAIA vengono salvate. Al momento del riavvio, monitoriamo lo stato del cluster sull' nodo già aggiornato. Dopo il riavvio, lo stato del cluster sul nodo aggiornato cambierà da READY a ACTIVE.
- Al termine del processo di upgrade, avviamo SmartDashboard e impostiamo la policy.
Checklist di verifica dopo l'aggiornamento
- I log degli eventi in SmartLog, lo stato dei tunnel VPN.
- Le impostazioni di GAIA.
- Ripristino del cluster dopo il failover di test.
- Licenze e contratti. Nel caso in cui le licenze vengano visualizzate in modo errato o non vengano visualizzate su SMS, eseguiamo il comando vsec_central_licence per la distribuzione delle licenze.
- CoreXL.
- SecureXL.
- Hotfix e CPinfo su due nodi.
Conclusione
A questo punto, è tutto – sei aggiornato.
Il nostro processo è durato in media dalle 6 alle 12 ore, a seconda delle dimensioni dei database esportati. Abbiamo lavorato per due notti: una per l'aggiornamento di SMS, l'altra per il cluster.
Non ci sono stati tempi morti nel traffico, nonostante tutte le problematiche sopra menzionate siano state verificate.
Certo, possono sorgere anche nuove difficoltà durante l'aggiornamento, ma questo è Check Point e, come tutti sappiamo, c'è sempre un hotfix!
Vi auguriamo notti e aggiornamenti neri-rosa di successo!
Fonte: habr.com
