În toamna lui 2019, Check Point a încetat să accepte versiunile R77.XX și a fost necesară actualizarea. S-au spus deja multe despre diferența dintre versiuni, avantajele și dezavantajele trecerii la R80. Să vorbim mai bine despre cum să actualizăm efectiv dispozitivele virtuale Check Point (CloudGuard pentru VMware ESXi, Hyper-V, KVM Gateway NGTP) și ce poate merge prost.
Deci, am avut 2 ingineri CCSE, mai mult de o duzină de clustere virtuale Check Point R77.30, mai multe nori, câteva remedieri rapide și o mare întreagă de diverse erori, erori și toate astea, de toate culorile și dimensiunile, și de asemenea, termene limită foarte strânse. Să mergem!
Cuprins:
Așa arată infrastructura cloud tipică a unui client cu Check Point virtual
Pregătire
Primul pas este să verificați dacă există suficiente resurse pentru actualizare. Cerințele minime recomandate pentru R80.20 arată în prezent astfel:
Dispozitiv
Procesor
RAM
HDD
Gateway de securitate
2 de bază
4 Gb
De la 15 GB
SMS-uri
2 de bază
6 Gb
-
Recomandările sunt descrise în document .
Dar vom fi realiști. Dacă acest lucru este suficient în cea mai minimă configurație, atunci, după cum arată practica, avem de obicei activată inspecția https, SmartEvent rulând pe SMS etc., care, desigur, necesită capacități complet diferite. Dar, în general, nu mai mult decât pentru R77.30.
Dar există nuanțe. Și se referă, în primul rând, la dimensiunea memoriei fizice. Multe operațiuni direct în timpul procesului de actualizare vor necesita spațiu pe hard disk.
Pentru serverul de management, dimensiunea spațiului liber pe disc va depinde foarte mult de volumul jurnalelor curente (dacă dorim să le salvăm) și de numărul de Revizii ale bazei de date salvate, deși nu vom mai avea nevoie de ele în cantități mari. Desigur, pentru nodurile de cluster (cu excepția cazului în care stocați și log-uri local), toate acestea nu contează. Iată cum puteți verifica dacă aveți spațiul de care aveți nevoie:
- Ne conectăm la Smart Management Server prin ssh, mergem în modul expert și introducem comanda:
[Expert@cp-sms:0]# df -h
- La ieșire vom vedea ceva de genul acestei configurații:
Filesystem Size Used Avail Use% Montat pe
/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 - Momentan suntem interesați de secțiune / var / log
Vă rugăm să rețineți că, în funcție de politica de stocare și ștergere a fișierelor jurnal vechi, precum și de dimensiunea bazei de date exportate, poate fi necesar mai mult spațiu. Dacă, la crearea unei arhive, există mai puțin spațiu liber decât este specificat în politica de stocare a fișierelor jurnal, sistemul va începe să ștergă jurnalele vechi și NU le va include în arhivă.
De asemenea, pentru procesul de actualizare în sine, sistemul va avea nevoie de cel puțin 13 GB de spațiu nealocat pe hard disk. Puteți verifica prezența acestuia cu comanda:
[Expert@cp-sms:0]# pvs
Vom vedea ceva de genul asta:
PV VG Fmt Attr PSize PFree
/dev/sda3 vg_splat lvm2 a- 141.69G 43.69G
În acest caz avem 43 GB. Sunt suficiente resurse. Puteți începe actualizarea.
Actualizarea serverului de gestionare SMS Check Point
Înainte de a începe lucrul, trebuie să faceți următoarele:
- Instalați pachetul Instrumente de migrare pe serverul de management. Pentru a face acest lucru, trebuie să descărcați imaginea de pe portal.
- Încărcați arhiva pe serverul de management prin WinSCP în folder /var/log/UpgradeR77.30_R80.20 (dacă este necesar, creați mai întâi un folder).
- Conectați-vă la serverul de management prin SSH și accesați folderul cu arhiva:cd /var/log/UpgradeR77.30_R80.20/
- Dezarhivați fișierul:tar -zxvf ./<nume fișier>.tgz
- Lansăm utilitarul pre_upgrade_verifier cu comanda: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
- La executarea comenzii, va fi generat un raport privind setările incompatibile. Este disponibil la: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Este mai convenabil să îl încărcați prin SCP și să îl urmăriți printr-un browser.
Pentru a rezolva orice setări incompatibile, utilizați. - Apoi rulați din nou utilitarul pre_upgrade_verifier pentru a vă asigura că toate cauzele de incompatibilitate au fost eliminate.
- Apoi, colectăm informații despre interfețele de rețea, tabelul de rutare și încărcăm configurația 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 „afișați configurația” > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt - Încărcați fișierul rezultat prin SCP.
- Facem un instantaneu la nivel de virtualizare.
- Creștem timpul de expirare a sesiunii SSH la 8 ore. Depinde de norocul tău: în funcție de dimensiunea bazei de date exportate, aceasta poate dura de la câteva minute la câteva ore. Pentru aceasta:
[Expert@HostName]# clish -c „afișează inactivitate-timeout” uitați-vă la conflictul de timeout actual,[Expert@HostName]# clish -c „set inactivity-timeout 720” specificați noul timeout clish (în minute),
[Expert@Nume gazdă]# echo $TMOUT uitați-vă la modul expert timeout actual,
[Expert@Nume gazdă]# export TMOUT=3600 specificați noul mod expert timeout (în secunde), dacă setați valoarea la 0, atunci timeout va fi dezactivat.
- Descărcăm și montăm imaginea de instalare SMS.iso pe mașina virtuală.
Înainte de pasul următor, ASIGURĂȚI-vă că aveți suficient spațiu nealocat pe hard disk (rețineți că aveți nevoie de 13 GB).
- Înainte de a începe exportul configurației, modificați fișierul jurnal cu comanda: fw comutator de busteni
Exportați configurația și jurnalele
- Rulați utilitarul migrate_export pentru a descărca configurația. Pentru a face acest lucru, mergeți la folderul creat anterior: cd /var/log/UpgradeR77.30_R80.20/ și folosiți comanda: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
sau
mergi la folderul: cd $FWDIR/bin/upgrade_tools/ и
rulați comanda de acolo: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz - Eliminam suma de control din arhiva: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Salvați valoarea rezultată în notepad.
- Ne conectăm la SMS prin SCP și încărcăm arhiva cu configurația pe stația de lucru. Asigurați-vă că utilizați transferul de fișiere în format binar.
Exportați baza de date SmartEvent
Aici avem nevoie de versiunea SMS R80 preinstalată. Orice test va merge.
- Din SMS avem nevoie de un script situat aici:$RTDIR/bin/eva_db_backup.csh
- Încărcați scriptul prin SCP eva_db_backup.csh la dosar: /var/log/UpgradeR77.30_R80.20/
- Conectați-vă prin SSH la SMS. Copiați fișierul în folder: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$RTDIR/bin/eva_db_backup.csh - Modificarea codificării: dos2unix $RTDIR/bin/eva_db_backup.csh
- Adăugarea proprietarului: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
- Adăugați drepturi: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
- Să începem să exportăm baza de date SmartEvent: $RTDIR/bin/eva_db_backup.csh
- Încărcați fișierele primite prin SCP: $RTDIR/bin/<date>-db-backup.backup и $RTDIR/bin/eventiaUpgrade.tar la postul de lucru.
actualizare
- Mergi la WebUI GAIA SMS → CPU → Afișează toate pachetele.
- Dacă CPUSE dă o eroare de conectare la cloud Check Point, verificați setările DGW, DNS și Proxy.
- Dacă totul este corect și eroarea nu dispare, atunci trebuie să actualizați manual CPUSE, ghidat de.
- Descărcați imaginea și treceți prin Verificator. Dacă este necesar, eliminăm inconsecvențele.
Ca urmare, ar trebui să vedeți acest mesaj:
- selecta R80.20 Instalare nouă și actualizare pentru managementul securității.
- Când instalați actualizarea, selectați Instalare curată. După instalare, sistemul se va reporni.
- Trecem Prima Oara Wizard.
- După ce obținem acces, verificăm conturile.
- Ne conectăm la SMS prin SSH și schimbăm shell-ul utilizatorului în /bin/bash/:
setați utilizatorul <nume utilizator> shell /bin/bash/
salva config (în cazul în care dorim să lăsăm bin/bash/ ca shell implicit după repornire).
- Apoi, ne conectăm la SMS prin SCP și transferăm arhiva cu configurația în modul Binary SMS_w_logs_export_r77_r80.tgz în dosar /var/log/UpgradeR77.30_R80.20/
- Eliminam suma de control din arhiva: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz și comparați cu valoarea anterioară. Suma de control trebuie să se potrivească.
- Creștem timpul de expirare a sesiunii SSH la 8 ore. Pentru aceasta:
[Expert@HostName]# clish -c „afișează inactivitate-timeout” uitați-vă la conflictul de timeout actual,
[Expert@HostName]# clish -c „set inactivity-timeout 720” specificați noul timeout clish (în minute),
[Expert@Nume gazdă]# echo $TMOUT uitați-vă la modul expert timeout actual,
[Expert@Nume gazdă]# export TMOUT=3600 specificați noul mod expert timeout (în secunde). Dacă setați valoarea la 0, atunci timeout va fi dezactivat.
- Pentru a importa setările, rulați utilitarul de import migrare. Pentru a face acest lucru, accesați folderul: cd $FWDIR/bin/upgrade_tools/și rulați importul: ./migrare imp
ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Să ne bucurăm de viață în următoarele două ore. NU DECONECTAȚI SESIUNEA SSH în timpul procedurii. La sfârșit, procesul de migrare va afișa fie un mesaj de succes, fie o eroare.
Lista de verificare după actualizare
- Disponibilitatea resurselor.
- SIC cu GW.
- Licențe. Dacă licențele sunt afișate incorect sau nu sunt afișate pe SMS, executați comanda vsec_central_licee pentru distribuirea licenței.
- Stabilirea politicii.
Importul bazei de date SmartEvent
- Activați lama SmartEvent.
- Ne conectăm prin WinSCP la SMS și transferăm fișierele descărcate anterior în modul binar <data>-db-backup.backup и eventiaUpgrade.tar în dosar /var/log/UpgradeR77.30_R80.20/
- Rulam scriptul cu comanda: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
- Verificarea starii: urmăriți -n 10 eventiaUpgrade.sh
- Verificarea jurnalelor în SmartEvent. VIS!
Actualizarea clusterului Check Point GW (Activ/Backup)
Înainte de a începe lucrul
- Salvăm configurația GAIA de la fiecare nod de cluster într-un fișier, pentru a face acest lucru folosiți comanda: clish -c "afișați configurația" > ./<Nume fișier>.txt
- Încărcarea fișierelor folosind WinSCP.
- Conectați-vă la WebUI a ambelor noduri și accesați fila CPUSE → Afișează toate pachetele.
- Găsirea pachetului de actualizare pentru versiune R80.20 Instalare proaspătă, presa Descărcați.
- Verificăm dacă protocolul CCP funcționează în modul Difuzare, pentru a face acest lucru, introduceți comanda: cphaprob -a if
Dacă este selectat modul multicast, înlocuiți-l cu comanda: cphaconf set_ccp broadcast (comanda se execută pe fiecare nod). - Instalăm Downtime pentru nodurile implicate în sistemul dumneavoastră de monitorizare.
- Verificăm dacă parametrii sunt activați la nivel de virtualizare Schimbarea adresei MAC и Transmite falsificate pentru o rețea de sincronizare.
actualizare
- Ne conectăm prin ssh la nodul Activ și rulăm comanda pentru a monitoriza starea cluster-ului: ceas -n 2 cphaprob stat
- Reveniți la fila WebUI Stanby noduri CPU și pentru pachetul selectat R80.20 Instalare proaspătă lansa Verificator.
- Să analizăm raportul Verifier. Dacă instalarea este permisă, treceți mai departe.
- Selectați un pachet R80.20 Instalare proaspătă și lansează Actualizare. În timpul procesului de actualizare, sistemul va reporni. Setările GAIA sunt salvate. În momentul repornirii, monitorizăm starea cluster-ului. După încărcare, starea nodului actualizat ar trebui să se schimbe în READY. Într-o serie de cazuri, am întâlnit un moment în care un nod care nu fusese încă actualizat a trecut la starea Atenție activă și a încetat să mai afișeze starea nodului actualizat. Nu vă alarmați - această opțiune este și ea acceptabilă.
- Odată ce actualizarea este completă, deschideți SmartDashboard.
- Deschideți obiectul cluster și modificați versiunea clusterului de la R77.30 la R80.20. Faceți clic pe OK. Dacă apare o eroare la salvarea modificărilor:
A apărut o eroare internă. (Cod: 0x8003001D, Nu s-a putut accesa fișierul pentru operația de scriere),
urma. După aceea, salvați modificările și faceți clic Politica de instalare. - În setări, debifați opțiunea Pentru clusterele gateway, dacă instalarea pe un membru de cluster eșuează, nu instalați pe acel cluster.
- Noi am stabilit politica. Sistemul va genera o eroare pentru un nod activ care nu a fost încă actualizat.
- Ne conectăm la nodul actualizat prin ssh și rulăm comanda pentru a monitoriza starea cluster-ului: ceas -n 2 cphaprob stat
- Conectați-vă la nodul WebUI Active și accesați fila CPUSE → Afișează toate pachetele.Găsirea pachetului de actualizare pentru versiune R80.20 Instalare proaspătă, faceți clic Descărcați.
- Instalăm Downtime pentru nodurile implicate în sistemul dumneavoastră de monitorizare.
- Reveniți la fila WebUI Active nodes CPU și pentru pachetul selectat R80.20 Instalare proaspătă lansa Verificator.
- Să analizăm raportul Verifier. Dacă instalarea este permisă, treceți mai departe.
- Selectați un pachet R80.20 Instalare proaspătă și lansează Modernizare. În timpul procesului de actualizare, sistemul va reporni. Setările GAIA sunt salvate. În momentul repornirii, monitorizăm starea cluster-ului pe nodul deja actualizat. După repornire, starea clusterului de pe nodul actualizat se va schimba de la READY la ACTIV.
- Când procesul de actualizare este finalizat, lansați SmartDashboard și instalați politica.
Lista de verificare după actualizare
- Jurnalele de evenimente în SmartLog, starea tunelurilor VPN.
- Setări GAIA.
- Restaurarea unui cluster după un test de failover.
- Licente si contracte. Dacă licențele sunt afișate incorect sau nu sunt afișate pe SMS, executați comanda. vsec_central_licence pentru distribuirea licenței.
- CoreXL.
- SecureXL.
- Remediere rapidă și CPinfo pe două noduri.
Concluzie
În general, asta este tot în acest moment - ați fost actualizat.
Pentru noi, întregul proces a durat în medie de la 6 la 12 ore, în funcție de dimensiunea bazelor de date exportate. Lucrarea s-a desfășurat pe parcursul a două nopți: una pentru actualizarea SMS-urilor, a doua pentru cluster.
Nu au existat timpi de oprire a traficului, în ciuda faptului că am verificat pe noi înșine toate erorile menționate mai sus.
Desigur, uneori pot apărea dificultăți complet noi în timpul procesului de actualizare, dar acesta este Check Point și, după cum știm cu toții, există întotdeauna o remediere rapidă!
Nopți negre și roz fericite și actualizări!
Sursa: www.habr.com
