Nell'autunno del 2019 Check Point ha smesso di supportare le versioni R77.XX ed è stato necessario aggiornarle. Si è già detto molto sulla differenza tra le versioni, sui pro e contro del passaggio alla R80. Parliamo meglio di come aggiornare effettivamente le apparecchiature virtuali Check Point (CloudGuard per VMware ESXi, Hyper-V, KVM Gateway NGTP) e cosa può andare storto.
Quindi, avevamo 2 ingegneri CCSE, più di una dozzina di cluster virtuali Check Point R77.30, diversi cloud, alcuni hotfix e un intero mare di vari bug, glitch e tutto il resto, di tutti i colori e dimensioni, e anche scadenze molto strette. Andiamo!
Contenuto:
Ecco come appare la tipica infrastruttura cloud di un cliente con Check Point virtuale
Formazione
Il primo passo è verificare se ci sono risorse sufficienti per l'aggiornamento. I requisiti minimi consigliati per R80.20 attualmente assomigliano a questi:
Dispositivo
CPU
RAM
HDD
Gateway di sicurezza
Nucleo 2
4 Gb
A partire da 15GB
sms
Nucleo 2
6 Gb
-
Le raccomandazioni sono descritte nel documento .
Ma saremo realistici. Se questo è sufficiente nella configurazione più minima, allora, come dimostra la pratica, di solito abbiamo l'ispezione https abilitata, SmartEvent in esecuzione su SMS, ecc., Che, ovviamente, richiede capacità completamente diverse. Ma in generale non più che per R77.30.
Ma ci sono delle sfumature. E riguardano, prima di tutto, la dimensione della memoria fisica. Molte operazioni effettuate direttamente durante il processo di aggiornamento richiederanno spazio sul disco rigido.
Per il server di gestione, la dimensione dello spazio libero su disco dipenderà molto dal volume dei log correnti (se vogliamo salvarli) e dal numero di revisioni del database salvate, anche se non ne avremo più bisogno in grandi quantità. Naturalmente, per i nodi del cluster (a meno che non si memorizzino anche i log localmente) tutto ciò non ha importanza. Ecco come verificare se hai lo spazio che ti serve:
- Ci colleghiamo a Smart Management Server tramite ssh, andiamo in modalità esperto e inseriamo il comando:
[Esperto@cp-sms:0]# df -h
- All'output vedremo qualcosa di simile a questa configurazione:
Dimensione file system utilizzata Avail Usa% Montato su
/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 - Al momento siamo interessati alla sezione / Var / log
Tieni presente che, a seconda della politica di archiviazione ed eliminazione dei vecchi file di registro, nonché della dimensione del database esportato, potrebbe essere necessario più spazio. Se, durante la creazione di un archivio, c'è meno spazio libero di quanto specificato nella politica di archiviazione dei file di registro, il sistema inizierà a cancellare i vecchi registri e NON li includerà nell'archivio.
Inoltre, per il processo di aggiornamento stesso, il sistema avrà bisogno di almeno 13 GB di spazio non allocato sul disco rigido. Puoi verificarne la presenza con il comando:
[Esperto@cp-sms:0]# pv
Vedremo qualcosa del genere:
PV VG Fmt Attr PSize PLibero
/dev/sda3 vg_splat lvm2 a- 141.69G 43.69G
In questo caso abbiamo 43 GB. Ci sono abbastanza risorse. Puoi iniziare ad aggiornare.
Aggiornamento del server di gestione SMS di Check Point
Prima di iniziare il lavoro è necessario effettuare le seguenti operazioni:
- Installare il pacchetto Strumenti di migrazione sul server di gestione. Per fare ciò, è necessario scaricare l'immagine dal portale.
- Caricare l'archivio sul server di gestione tramite WinSCP nella cartella /var/log/UpgradeR77.30_R80.20 (se necessario, creare prima una cartella).
- Connettiti al server di gestione tramite SSH e vai alla cartella con l'archivio:cd /var/log/UpgradeR77.30_R80.20/
- Decomprimere il file:tar -zxvf ./<nome file>.tgz
- Lanciamo l'utility pre_upgrade_verifier con il comando: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
- All'esecuzione del comando verrà generato un report sulle impostazioni incompatibili. È disponibile presso: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). È più comodo caricarlo tramite SCP e guardarlo tramite un browser.
Per risolvere eventuali impostazioni incompatibili, utilizzare. - Quindi eseguire nuovamente l'utilità pre_upgrade_verifier per assicurarsi che tutte le cause di incompatibilità siano state eliminate.
- Successivamente, raccogliamo informazioni sulle interfacce di rete, sulla tabella di routing e carichiamo 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 "mostra configurazione" > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt - Carica il file risultante tramite SCP.
- Facciamo uno snapshot a livello di virtualizzazione.
- Aumentiamo il timeout della sessione SSH a 8 ore. Dipende dalla fortuna: a seconda della dimensione del database esportato, può durare da alcuni minuti a diverse ore. Per questo:
[Esperto@NomeHost]# clish -c "mostra timeout di inattività" guarda l'attuale clic del timeout,[Esperto@NomeHost]# clish -c "imposta timeout di inattività 720" specificare il nuovo clic di timeout (in minuti),
[Esperto@NomeHost]# echo $TMOUT guarda la modalità esperto di timeout corrente,
[Esperto@NomeHost]# esporta TMOUT=3600 specificare la nuova modalità esperto di timeout (in secondi), se si imposta il valore su 0, il timeout verrà disabilitato.
- Scarichiamo e montiamo l'immagine di installazione SMS.iso sulla macchina virtuale.
Prima del passaggio successivo, ASSICURARSI di ricontrollare di avere abbastanza spazio non allocato sul disco rigido (ricorda, sono necessari 13 GB).
- Prima di iniziare ad esportare la configurazione modificare il file di log con il comando: fw logswitch
Esporta configurazione e registri
- Eseguire l'utilità migrate_export per scaricare la configurazione. Per fare ciò, vai alla cartella creata in precedenza: cd /var/log/UpgradeR77.30_R80.20/ e usa il comando: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
o
vai alla cartella: cd $FWDIR/bin/upgrade_tools/ и
esegui il comando da lì: ./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
- Salva il valore risultante nel blocco note.
- Ci colleghiamo agli SMS tramite SCP e carichiamo l'archivio con la configurazione sulla workstation. Assicurati di utilizzare il trasferimento file in formato binario.
Esporta il database SmartEvent
Qui abbiamo bisogno della versione SMS R80 preinstallata. Qualsiasi prova andrà bene.
- Dagli SMS abbiamo bisogno di uno script che si trova qui:$RTDIR/bin/eva_db_backup.csh
- Carica lo script tramite SCP eva_db_backup.csh nella cartella: /var/log/UpgradeR77.30_R80.20/
- Connettiti tramite SSH agli SMS. Copia il file nella cartella: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$RTDIR/bin/eva_db_backup.csh - Modifica della codifica: dos2unix $RTDIR/bin/eva_db_backup.csh
- Aggiunta del proprietario: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
- Aggiungi diritti: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
- Iniziamo ad esportare il database SmartEvent: $RTDIR/bin/eva_db_backup.csh
- Carica i file ricevuti tramite SCP: $RTDIR/bin/<data>-db-backup.backup и $RTDIR/bin/eventiaUpgrade.tar alla postazione di lavoro.
Aggiornare
- Passiamo a WebUI GAIA SMS → CPUSE → Mostra tutti i pacchetti.
- Se CPUSE restituisce un errore durante la connessione al cloud Check Point, controllare le impostazioni DGW, DNS e Proxy.
- Se tutto è corretto e l'errore non scompare, è necessario aggiornare manualmente CPUSE, guidato da.
- Scarica l'immagine e procedi Verificatore. Se necessario, eliminiamo le incoerenze.
Di conseguenza, dovresti vedere questo messaggio:
- selezionare R80.20 Nuova installazione e aggiornamento per la gestione della sicurezza.
- Durante l'installazione dell'aggiornamento, selezionare Installazione pulita. Dopo l'installazione, il sistema si riavvierà.
- Passiamo la Prima Volta Procedura guidata.
- Dopo aver ottenuto l'accesso, controlliamo i conti.
- Ci colleghiamo agli SMS tramite SSH e cambiamo la shell del nostro utente in /bin/bash/:
imposta l'utente <nome utente> shell /bin/bash/
salva configurazione (nel caso in cui vogliamo lasciare bin/bash/ come shell predefinita dopo il riavvio).
- Successivamente ci colleghiamo agli SMS tramite SCP e trasferiamo l'archivio con la configurazione in modalità binaria 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 confrontare con il valore precedente. Il checksum deve corrispondere.
- Aumentiamo il timeout della sessione SSH a 8 ore. Per questo:
[Esperto@NomeHost]# clish -c "mostra timeout di inattività" guarda l'attuale clic del timeout,
[Esperto@NomeHost]# clish -c "imposta timeout di inattività 720" specificare il nuovo clic di timeout (in minuti),
[Esperto@NomeHost]# echo $TMOUT guarda la modalità esperto di timeout corrente,
[Esperto@NomeHost]# esporta TMOUT=3600 specificare la nuova modalità esperto di timeout (in secondi). Se imposti il valore su 0, il timeout sarà disabilitato.
- Per importare le impostazioni, eseguire l'utilità di importazione della migrazione. Per fare ciò, vai alla cartella: cd $FWDIR/bin/upgrade_tools/ed esegui l'importazione: ./migra imp
ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Godiamoci la vita per le prossime due ore. NON DISCONNETTERE LA SESSIONE SSH durante la procedura. Alla fine, il processo di migrazione visualizzerà un messaggio di successo o un errore.
Lista di controllo dopo l'aggiornamento
- Disponibilità di risorse.
- SIC con GW.
- Licenze. Se le licenze vengono visualizzate in modo errato o non vengono visualizzate negli SMS, eseguire il comando vsec_central_licence per la distribuzione delle licenze.
- Definizione della politica.
Importazione del database SmartEvent
- Attivare il pannello SmartEvent.
- Ci colleghiamo tramite WinSCP agli SMS e trasferiamo i file precedentemente scaricati in modalità binaria <data>-db-backup.backup и 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
- Verifica dello stato: guarda -n 10 eventiaUpgrade.sh
- Controllo dei registri in SmartEvent. SOGNO!
Aggiornamento del cluster Check Point GW (attivo/backup)
Prima di iniziare il lavoro
- Salviamo la configurazione GAIA da ogni nodo del cluster in un file, per fare ciò utilizziamo il comando: clish -c "mostra configurazione" > ./<Nome file>.txt
- Caricamento di file utilizzando WinSCP.
- Connettiti alla WebUI di entrambi i nodi e vai alla scheda CPUSE → Mostra tutti i pacchetti.
- Trovare il pacchetto di aggiornamento per la versione R80.20 Nuova installazione, stampa Scarica.
- Controlliamo che il protocollo CCP funzioni nella modalità Trasmissione, per fare ciò, inserisci il comando: cphaprob -a se
Se la modalità è selezionata Multicast, sostituiscilo con il comando: trasmissione cphaconf set_ccp (il comando viene eseguito su ciascun nodo). - Installiamo Downtime per i nodi coinvolti nel tuo sistema di monitoraggio.
- Controlliamo che i parametri siano abilitati a livello di virtualizzazione Modifica indirizzo MAC и Trasmissioni forgiate per una rete di sincronizzazione.
Aggiornare
- Ci colleghiamo via ssh al nodo Active ed eseguiamo il comando per monitorare lo stato del cluster: guarda -n 2 cphaprob stat
- Torna alla scheda dei nodi Standby WebUI CPUSE e per il pacchetto selezionato R80.20 Nuova installazione lancio Verificatore.
- Analizziamo il report di Verifier. Se l'installazione è consentita, vai avanti.
- Seleziona un pacchetto R80.20 Nuova installazione e lanciare Upgrade. Durante il processo di aggiornamento, il sistema si riavvierà. Le impostazioni GAIA vengono salvate. Al momento del riavvio, monitoriamo lo stato del cluster. Dopo il caricamento, lo stato del nodo aggiornato dovrebbe cambiare in READY. In diversi casi, abbiamo riscontrato un momento in cui un nodo che non era stato ancora aggiornato passava allo stato di Attenzione attiva e smetteva di visualizzare lo stato del nodo aggiornato. Non allarmarti: anche questa opzione è accettabile.
- Una volta completato l'aggiornamento, apri SmartDashboard.
- Aprire l'oggetto cluster e modificare la versione del cluster da R77.30 a R80.20. Fare clic su OK. Se viene visualizzato un errore durante il salvataggio delle modifiche:
Si è verificato un errore interno. (Codice: 0x8003001D, Impossibile accedere al file per l'operazione di scrittura),
seguire. Successivamente, salva le modifiche e fai clic Installa politica. - Nelle impostazioni, deseleziona l'opzione Per i cluster gateway, se l'installazione su un membro del cluster non riesce, non eseguire l'installazione su quel cluster.
- Stabiliamo la politica. Il sistema genererà un errore per un nodo attivo che non è stato ancora aggiornato.
- Ci colleghiamo al nodo aggiornato tramite ssh ed eseguiamo il comando per monitorare lo stato del cluster: guarda -n 2 cphaprob stat
- Connettiti al nodo WebUI Active e vai alla scheda CPUSE → Mostra tutti i pacchetti.Trovare il pacchetto di aggiornamento per la versione R80.20 Nuova installazione, fare clic Scarica.
- Installiamo Downtime per i nodi coinvolti nel tuo sistema di monitoraggio.
- Torna alla scheda Nodi attivi WebUI CPUSE e per il pacchetto selezionato R80.20 Nuova installazione lancio Verificatore.
- Analizziamo il report di Verifier. Se l'installazione è consentita, vai avanti.
- Seleziona un pacchetto R80.20 Nuova installazione e lanciare Aggiornamento. Durante il processo di aggiornamento, il sistema si riavvierà. Le impostazioni GAIA vengono salvate. Al momento del riavvio monitoriamo lo stato del cluster sul nodo già aggiornato. Dopo il riavvio, lo stato del cluster sul nodo aggiornato cambierà da PRONTO ad ATTIVO.
- Una volta completato il processo di aggiornamento, avvia SmartDashboard e imposta la policy.
Lista di controllo dopo l'aggiornamento
- Registri eventi in SmartLog, stato dei tunnel VPN.
- Impostazioni GAIA.
- Ripristino di un cluster dopo un failover di prova.
- Licenze e contratti. Se le licenze vengono visualizzate in modo errato o non vengono visualizzate negli SMS, eseguire il comando. vsec_central_licence per la distribuzione delle licenze.
- CoreXL.
- SicuroXL.
- Hotfix e CPinfo su due nodi.
conclusione
In generale, a questo punto è tutto: sei stato aggiornato.
Per noi l’intero processo ha richiesto in media dalle 6 alle 12 ore, a seconda della dimensione dei database esportati. Il lavoro si è svolto in due notti: una per l'aggiornamento degli SMS, la seconda per il cluster.
Non si sono verificati tempi di inattività del traffico, nonostante abbiamo verificato personalmente tutti gli errori sopra menzionati.
Naturalmente, a volte possono sorgere difficoltà completamente nuove durante il processo di aggiornamento, ma questo è Check Point e, come tutti sappiamo, c'è sempre un hotfix!
Buone notti nere e rosa e aggiornamenti!
Fonte: habr.com
