Nell'autunno del 2019 Check Point ha cessato il supporto per le versioni R77.XX, ed è stato necessario un aggiornamento. Si è già parlato molto delle differenze tra le versioni, dei pro e dei contro del passaggio a R80. Parliamo meglio di come, in realtà, aggiornare gli appliance virtuali Check Point (CloudGuard per VMware ESXi, Hyper-V, KVM Gateway NGTP) e di cosa potrebbe andare storto.
Quindi, avevamo 2 ingegneri CCSE, più di una dozzina di cluster virtuali Check Point R77.30, diversi cloud, un paio di hotfix e un mare di bug, glitch e tutto ciò, di tutti i colori e forme, e anche scadenze molto ravvicinate. Iniziamo!
Contenuto:
Questa è un'infrastruttura cloud tipica di un cliente con Check Point virtuale
Preparazione
Per prima cosa è necessario verificare se ci sono sufficienti risorse per l'aggiornamento. I requisiti minimi consigliati per R80.20 sono attualmente i seguenti:
Device
CPU
RAM
HDD
Security Gateway
2 core
4 Gb
Da 15 GB
SMS
2 core
6 Gb
—
Le raccomandazioni sono descritte nel documento .
Ma dobbiamo essere realisti. Se nella configurazione minima ciò è sufficiente, come dimostra la pratica, normalmente abbiamo attivata l'ispezione https, SmartEvent in esecuzione su SMS, ecc., il che richiede ovviamente capacità completamente diverse. Ma in generale, non molto diverse da quelle per R77.30.
Ma ci sono delle particolarità. E riguardano, prima di tutto, le dimensioni della memoria fisica. Molte operazioni durante il processo di aggiornamento richiederanno spazio su disco rigido.
Per il server di gestione la dimensione dello spazio libero su disco dipenderà fortemente dal volume dei log attuali (se desideriamo conservarli) e dal numero di revisioni della database salvate, anche se queste ultime non ci serviranno molto in gran numero. Naturalmente, per i nodi del cluster (a meno che non si conservino i log anche localmente) non ha importanza. Ecco come è possibile verificare la presenza dello spazio necessario:
- Ci connettiamo al Smart Management Server tramite ssh, entriamo in modalità esperto ed immettiamo il comando:
[Expert@cp-sms:0]# df -h
- In uscita vedremo 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 - Attualmente ci interessa la partizione /var/log
Si prega di tenere presente che, a seconda della politica di archiviazione e cancellazione dei vecchi log, così come delle dimensioni 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 archiviazione dei log, il sistema inizierà a cancellare i log vecchi e NON li includerà nell'archivio.
Inoltre, per il processo di aggiornamento, il sistema avrà bisogno di un minimo di 13 GB di spazio non allocato sul disco rigido. È possibile verificarne la disponibilità con il comando:
[Expert@cp-sms:0]# pvs
Vedremo un output approssimativamente di questo tipo:
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:
- Installiamo il pacchetto Migration Tools sul server di gestione. Per fare ciò, è necessario scaricare l'immagine dal portale..
- Carichiamo l'archivio sul server di gestione tramite WinSCP nella cartella /var/log/UpgradeR77.30_R80.20 (se necessario, creare prima la cartella).
- Ci connettiamo al server di gestione tramite SSH e navighiamo nella cartella dell'archivio:cd /var/log/UpgradeR77.30_R80.20/
- Decomprimiamo il file:tar -zxvf ./.tgz
- Avviamo l'utilità pre_upgrade_verifier con il comando: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
- Dopo l'esecuzione 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 scaricarlo tramite SCP e visualizzarlo tramite browser.
Per risolvere tutte le impostazioni incompatibili, utilizzare. - Dopo averlo eseguito nuovamente l'utilità pre_upgrade_verifier per assicurarci che tutte le cause di incompatibilità siano state risolte.
- Successivamente, raccogliamo informazioni sulle interfacce di rete, sulla tabella di routing e scarichiamo 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 - Scarichiamo il file ottenuto tramite SCP.
- Facciamo uno snapshot a livello di virtualizzazione.
- Aumentiamo il timeout della sessione SSH a 8 ore. Qui dipende dalla situazione: a seconda delle dimensioni del database esportato, può durare da pochi minuti a diverse ore. Per fare questo:
[Expert@HostName]# clish -c "show inactivity-timeout" Controlliamo il timeout attuale di clish,[Expert@HostName]# clish -c "set inactivity-timeout 720" Indichiamo il nuovo timeout di clish (in minuti),
[Expert@HostName]# echo $TMOUT Controlliamo il timeout attuale della modalità esperto,
[Expert@HostName]# export TMOUT=3600 Indichiamo il nuovo timeout della modalità esperto (in secondi); se si imposta il valore a 0, il timeout sarà disattivato.
- Carichiamo e montiamo l'immagine di installazione SMS.iso sulla macchina virtuale.
Prima di procedere al passo successivo, è OBBLIGATORIO controllare nuovamente che ci sia spazio non allocato sufficiente sul disco rigido (ricordo che 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'utilità migrate_export per esportare la configurazione. Per fare ciò, entriamo nella cartella creata in precedenza: cd /var/log/UpgradeR77.30_R80.20/ e usiamo il comando: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
oppure
entriamo 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 - Rimuoviamo il checksum dall'archivio: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Salviamo il valore ottenuto in un blocco note.
- Ci connettiamo a SMS tramite SCP ed esportiamo l'archivio con la configurazione sulla workstation. Assicurati di usare il trasferimento file in formato Binary.
Esportazione del database SmartEvent
Qui avremo bisogno di un SMS installato in precedenza, versione R80. Qualsiasi versione di test va bene.
- Dal SMS abbiamo bisogno dello script posizionato qui:$RTDIR/bin/eva_db_backup.csh
- Carichiamo lo script eva_db_backup.csh nella cartella: /var/log/UpgradeR77.30_R80.20/
- Ci connettiamo per 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 - Cambiamo 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
- Avviamo l'esportazione del database SmartEvent: $RTDIR/bin/eva_db_backup.csh
- Esportiamo i file ricevuti tramite SCP: $RTDIR/bin/-db-backup.backup e $RTDIR/bin/eventiaUpgrade.tar sulla workstation.
Aggiornamento
- Passiamo a WebUI GAIA SMS → CPUSE → Mostra tutti i pacchetti.
- Nel caso in cui CPUSE mostri un errore di connessione al cloud di Check Point, controlliamo DGW, DNS e impostazioni Proxy.
- Se tutto è corretto, ma l'errore persiste, sarà necessario aggiornare CPUSE manualmente, seguendo.
- Scarichiamo l'immagine e procediamo Verifier. Se necessario, risolviamo le discrepanze.
Dobbiamo vedere il seguente messaggio:
- Selezioniamo R80.20 Fresh Install and Upgrade for Security Management.
- Durante l'installazione dell'aggiornamento, selezioniamo Clean Install. Dopo l'installazione, il sistema si riavvierà.
- Procediamo con il First Time Wizard.
- Dopo aver ottenuto accesso, controlliamo gli account.
- Ci connettiamo a SMS tramite SSH e cambiamo la shell del nostro utente in /bin/bash:
set user shell /bin/bash
save config (se vogliamo mantenere bin/bash come shell predefinita anche dopo il riavvio).
- Successivamente, ci connettiamo a SMS tramite SCP e in modalità Binary trasferiamo l'archivio con la configurazione SMS_w_logs_export_r77_r80.tgz nella cartella /var/log/UpgradeR77.30_R80.20/
- Rimuoviamo 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 questo:
[Expert@HostName]# clish -c "show inactivity-timeout" Controlliamo il timeout attuale di clish,
[Expert@HostName]# clish -c "set inactivity-timeout 720" Indichiamo 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ò, andiamo 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 DISCONNETTETE LA SESSIONE SSH durante la procedura. Alla fine, il processo migrate visualizzerà un messaggio di successo o un errore.
Checklist di controllo dopo l'aggiornamento
- Disponibilità delle risorse.
- SIC con GW.
- Licenze. Se le licenze non vengono visualizzate correttamente o non vengono visualizzate su SMS, eseguiamo il comando vsec_central_licence per la distribuzione delle licenze.
- Impostazione della politica.
Importazione del database SmartEvent
- Attivate il blade SmartEvent.
- Ci connettiamo tramite WinSCP a SMS e in modalità binaria trasferiamo i file esportati in precedenza -db-backup.backup e eventiaUpgrade.tar nella cartella /var/log/UpgradeR77.30_R80.20/
- Avviamo 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. SONNO!
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, utilizzando il comando: clish -c "show configuration" > ./.txt
- Esportiamo i file utilizzando WinSCP.
- Ci connettiamo a WebUI di entrambi i nodi e andiamo alla scheda CPUSE → Mostra tutti i pacchetti.
- Troviamo il pacchetto di aggiornamento per la versione R80.20 Fresh Install, facciamo clic su Download.
- Controlliamo che il protocollo CCP funzioni in modalità Vroadcast, per fare ciò inseriamo il comando: cphaprob -a if
Se è selezionata la modalità Multicast, cambiatela con il comando: cphaconf set_ccp broadcast (il comando viene eseguito su ogni nodo). - Impostiamo il Downtime per i nodi coinvolti nel vostro sistema di monitoraggio.
- Controlliamo che a livello di virtualizzazione siano attivate le impostazioni Cambio dell'indirizzo MAC e Trasmissioni contraffatte per la rete di sincronizzazione.
Aggiornamento
- Ci connettiamo via ssh al nodo Attivo e avviamo il comando per monitorare lo stato del cluster: watch -n 2 cphaprob stat
- Torniamo a WebUI del nodo Standby 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. Durante il riavvio monitoriamo lo stato del cluster. Dopo il caricamento, lo stato del nodo aggiornato dovrebbe cambiare in READY. In alcuni casi, ci siamo trovati di fronte a una situazione in cui un nodo non aggiornato passava allo stato di Active Attention e smetteva di mostrare lo stato del nodo aggiornato. Non preoccupatevi: questa possibilità è accettabile.
- 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 dalla voce Per i cluster di gateway, se l'installazione su un membro del cluster fallisce, non installare su quel cluster.
- Installiamo la politica. Il sistema genererà un errore per il nodo attivo, che non è ancora stato aggiornato.
- Colleghiamoci al nodo aggiornato tramite ssh e avviamo il comando per monitorare lo stato del cluster: watch -n 2 cphaprob stat
- Colleghiamoci al WebUI del nodo attivo e andiamo alla scheda CPUSE → Mostra tutti i pacchetti.Troviamo il pacchetto di aggiornamento 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 attivo nella 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. Durante il riavvio monitoriamo lo stato del cluster sul nodo già aggiornato. Dopo il riavvio, lo stato del cluster sul nodo aggiornato cambierà da READY a ACTIVE.
- Quando il processo di upgrade sarà completato, avviamo SmartDashboard e impostiamo la politica.
Checklist di controllo dopo l'aggiornamento
- I registri degli eventi in SmartLog, lo stato dei tunnel VPN.
- Le impostazioni di GAIA.
- Ripristino del cluster dopo un failover di test.
- Licenze e contratti. Nel caso in cui le licenze vengano visualizzate in modo errato o non vengano visualizzate su SMS, avviamo il comando. vsec_central_licence per la distribuzione delle licenze.
- CoreXL.
- SecureXL.
- Hotfix e CPinfo su due nodi.
Conclusione
In generale, a questo punto è tutto: siete aggiornati.
Il nostro intero processo ha impiegato mediamente da 6 a 12 ore, a seconda delle dimensioni delle basi esportate. I lavori sono stati eseguiti in due notti: una per aggiornare SMS, l'altra per il cluster.
Non ci sono stati tempi di inattività del traffico, anche se tutti gli errori sopra menzionati li abbiamo verificati personalmente.
Certo, a volte possono sorgere anche nuove difficoltà durante l'aggiornamento, ma è Check Point, e come sappiamo, c'è sempre un hotfix!
Vi auguriamo notti e aggiornamenti neri-rosa di successo!
Fonte: habr.com
