În toamna anului 2019, Check Point a încetat suportul pentru versiunile R77.XX, iar actualizarea a devenit necesară. S-a discutat deja destul despre diferențele dintre versiuni, despre avantajele și dezavantajele trecerii la R80. Mai bine să vorbim despre cum să actualizăm appliance-urile virtuale Check Point (CloudGuard pentru VMware ESXi, Hyper-V, KVM Gateway NGTP) și ce ar putea să meargă prost.
Deci, am avut 2 ingineri CCSE, peste zece clustere virtuale Check Point R77.30, câteva cloud-uri, câteva hotfix-uri și o mulțime de bug-uri, erori și tot felul de probleme, de toate culorile și dimensiunile, plus termene foarte strânse. Să începem!
Cuprins:
Așa arată infrastructura tipică a unui client cu Check Point virtual
Pregătire
În primul rând, trebuie să verificăm suficiența resurselor pentru actualizare. Cerințele minime recomandate pentru R80.20 arată acum în felul următor:
Dispozitiv
CPU
RAM
HDD
Security Gateway
2 nuclee
4 GB
De la 15 GB
SMS
2 nuclee
6 GB
—
Recomandările sunt descrise în documentul .
Dar să fim realiști. Dacă în configurația minimă acest lucru este suficient, în practică, de obicei avem activată inspecția https, SmartEvent funcționează pe SMS etc., ceea ce, desigur, necesită puteri complet diferite. Totuși, în general, nu mai mari decât pentru R77.30.
Dar există nuanțe. Și acestea se referă, în primul rând, la dimensiunile memoriei fizice. Multe operațiuni în procesul 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 păstrăm) și de numărul reviziunilor bazei de date salvate, chiar dacă acestea nu ne vor mai fi necesare în număr mare. Desigur, pentru nodurile clusterului (cu excepția cazului în care stocați jurnalele și local) asta nu are importanță. Iată cum putem verifica disponibilitatea spațiului necesar:
- Ne conectăm la Smart Management Server prin ssh, intrăm în modul expert și introducem comanda:
[Expert@cp-sms:0]# df -h
- La ieșire, vom vedea aproximativ această configurație:
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
Ne interesează în prezent această partiție
/dev/mapper/vg_splat-lv_log 243G 177G 53G 78% /var/log - În acest moment, ne interesează secțiunea /var/log
Atentie, in functie de politica de stocare si stergere a vechilor log-uri, precum si de dimensiunea bazei exportate, poate fi nevoie de mai mult spatiu. Daca, la crearea arhivei, spatiul liber scade sub cel specificat in politica de stocare a log-urilor, sistemul va incepe sa stearga vechile log-uri si NU le va include in arhiva.
De asemenea, pentru procesul de actualizare, sistemul va necesita un minim de 13 GB de spatiu nealocat pe discul dur. Verificarea acestuia se poate face cu comanda:
[Expert@cp-sms:0]# pvs
Vom vedea aproximativ următoarea ieșire:
PV VG Fmt Attr PSize PFree
/dev/sda3 vg_splat lvm2 a- 141.69G 43.69G
În acest caz, avem 43 GB. Resursele sunt suficiente. Putem începe actualizarea.
Actualizăm serverul de management Check Point SMS
Înainte de a începe lucrările, trebuie să facem următoarele:
- Instalăm pachetul Migration Tools pe serverul de management. Pentru aceasta, trebuie să descărcăm imaginea de pe portal.
- Încărcăm arhiva pe serverul de management prin WinSCP în folderul /var/log/UpgradeR77.30_R80.20 (dacă este necesar, creați mai întâi folderul).
- Ne conectăm la serverul de management prin SSH și intrăm în folderul cu arhiva:cd /var/log/UpgradeR77.30_R80.20/
- Dezarhivăm fișierul:tar -zxvf ./.tgz
- Executăm utilitarul pre_upgrade_verifier cu comanda: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
- După executarea comenzii, va fi generat un raport despre setările incompatibile. Acesta este disponibil la adresa: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Este mai convenabil să-l descărcați prin SCP și să-l vizualizați prin intermediul browserului.
Pentru a elimina toate setările incompatibile, utilizați. - După, rulați din nou utilitarul pre_upgrade_verifier pentru a vă asigura că toate motivele incompatibilității au fost eliminate.
- Apoi, colectăm informații despre interfețele de rețea, tabelul de rutare și exportă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 "show configuration" > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt - Exportăm fișierul obținut prin SCP.
- Facem un snapshot la nivel de virtualizare.
- Urmărim să creștem timeout-ul sesiunii SSH la 8 ore. Aici depinde de circumstanțe: în funcție de dimensiunile bazei exportate, acesta poate dura de la câteva minute la câteva ore. Pentru aceasta:
[Expert@HostName]# clish -c "show inactivity-timeout" verificăm timeout-ul curent clish,[Expert@HostName]# clish -c "set inactivity-timeout 720" setăm un nou timeout clish (în minute),
[Expert@HostName]# echo $TMOUT verificăm timeout-ul curent în modul expert,
[Expert@HostName]# export TMOUT=3600 setăm un nou timeout în modul expert (în secunde), dacă setăm valoarea 0, atunci timeout-ul va fi dezactivat.
- Încărcăm și montăm imaginea de instalare SMS.iso pe mașina virtuală.
Înainte de următorul pas, VERIFICĂ OBLIGATORIU din nou că ai suficient spațiu nealocat pe hard disk (amintesc, este nevoie de 13 GB).
- Înainte de a începe exportul configurației, schimbăm log-ul cu comanda: fw logswitch
Exportul configurației și al log-urilor
- Lansăm utilitarul migrate_export pentru a exporta configurația. Pentru aceasta, accesați folderul creat anterior: cd /var/log/UpgradeR77.30_R80.20/ și folosim comanda: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
sau
accesăm folderul: cd $FWDIR/bin/upgrade_tools/ și
lansăm comanda de acolo: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz - Calculăm checksum-ul arhivei: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Salvăm valoarea obținută într-un fișier text.
- Ne conectăm la SMS prin SCP și descărcăm arhiva cu configurația pe stația de lucru. Este esențial să folosim transferul de fișiere în format Binary.
Exportul bazei SmartEvent
Aici avem nevoie de SMS instalat anterior, versiunea R80. Orice test este acceptat.
- De la SMS avem nevoie de scriptul, situat aici:$RTDIR/bin/eva_db_backup.csh
- Prin SCP, încărcăm scriptul eva_db_backup.csh în folderul: /var/log/UpgradeR77.30_R80.20/
- Ne conectăm prin SSH la SMS. Copiem fișierul în folder: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$RTDIR/bin/eva_db_backup.csh - Schimbăm codificarea: dos2unix $RTDIR/bin/eva_db_backup.csh
- Adăugăm proprietar: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
- Adăugăm permisiuni: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
- Lansăm exportul bazei SmartEvent: $RTDIR/bin/eva_db_backup.csh
- Exportăm fișierele obținute prin SCP: $RTDIR/bin/-db-backup.backup și $RTDIR/bin/eventiaUpgrade.tar pe stația de lucru.
Actualizare
- Trecem la WebUI GAIA SMS → CPUSE → Afișați toate pachetele.
- În cazul în care CPUSE dă o eroare de conectare la cloud-ul Check Point, verificăm DGW, DNS și setările Proxy.
- Dacă totul este corect, dar eroarea persistă, trebuie să actualizăm CPUSE manual, conform.
- Descărcăm imaginea și continuăm Verifier. Dacă este necesar, remediem discrepanțele.
Ca rezultat, ar trebui să vedem următorul mesaj:
- Alegem R80.20 Instalare proaspătă și upgrade pentru gestionarea securității.
- La instalarea actualizării, alegem Instalare curată. După instalare, sistemul se va reporni.
- Trecem prin prima asistent.
- După obținerea accesului, verificăm conturile.
- Ne conectăm la SMS prin SSH și schimbăm shell-ul utilizatorului nostru la /bin/bash/:
set user shell /bin/bash/
save config (în cazul în care dorim să lăsăm bin/bash/ ca shell implicit și după repornire).
- Apoi, ne conectăm la SMS prin SCP și în modul Binary transmitem arhiva cu configurația SMS_w_logs_export_r77_r80.tgz în folderul /var/log/UpgradeR77.30_R80.20/
- Calculăm checksum-ul arhivei: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz și comparăm cu valoarea anterioară. Checksum-urile trebuie să fie identice.
- Creștem timeout-ul sesiunii SSH la 8 ore. Pentru asta:
[Expert@HostName]# clish -c "show inactivity-timeout" verificăm timeout-ul curent clish,
[Expert@HostName]# clish -c "set inactivity-timeout 720" setăm un nou timeout clish (în minute),
[Expert@HostName]# echo $TMOUT verificăm timeout-ul curent în modul expert,
[Expert@HostName]# export TMOUT=3600 specificăm noul timeout în modul expert (în secunde). Dacă setăm valoarea 0, timeout-ul va fi dezactivat.
- Pentru importarea setărilor, lansăm utilitarul migrate import. Pentru asta, mergem în folderul: cd $FWDIR/bin/upgrade_tools/și lansăm importul: .\/migrate imp
ort -l \/var\/log\/UpgradeR77.30_R80.20\/SMS_w_logs_export_r77_r80.tgz
Ne bucurăm de viață în următoarele câteva ore. NU DEZACTIVAȚI SESIUNEA SSH în timpul procedurii. La final, procesul migrate va oferi fie un mesaj de finalizare cu succes, fie o eroare.
Listă de verificare după actualizare
- Disponibilitatea resurselor.
- SIC cu GW.
- Licențele. Dacă licențele sunt afișate incorect sau nu sunt afișate pe SMS, lansăm comanda vsec_central_licence pentru distribuirea licențelor.
- Configurarea politicii.
Importul bazei SmartEvent
- Activăm blade-ul SmartEvent.
- Ne conectăm prin WinSCP la SMS și în modul binary transferăm fișierele exportate anterior -db-backup.backup și eventiaUpgrade.tar în folderul /var/log/UpgradeR77.30_R80.20/
- Lansăm scriptul cu comanda: $RTDIR\/bin\/eventiaUpgrade.sh -upgrade \/var\/log\/UpgradeR77.30_R80.20\/eventiaUpgrade.tar
- Verificăm statusul: watch -n 10 eventiaUpgrade.sh
- Verificăm log-urile în SmartEvent. SĂ NU DORMIM!
Actualizăm clusterul Check Point GW (Active\/Backup)
Înainte de a începe lucrările
- Salvăm configurația GAIA din fiecare nod al clusterului într-un fișier, pentru asta folosim comanda: clish -c "show configuration" > .\/\.txt
- Exportăm fișierele folosind WinSCP.
- Ne conectăm la WebUI ambele noduri și mergem pe tab-ul CPUSE → Afișare toate pachetele.
- Găsim pachetul de actualizare pentru versiunea R80.20 Fresh Install, dăm clic pe Descărcare.
- Verificăm dacă protocolul CCP funcționează în modul Broadacst, pentru asta introducem comanda: cphaprob -a if
Dacă este selectat modul Multicast, schimbați-l cu comanda: cphaconf set_ccp broadcast (comanda se execută pe fiecare nod). - Stabilim Downtime pentru nodurile implicate în sistemul dumneavoastră de monitorizare.
- Verificăm dacă la nivelul virtualizării sunt activate opțiunile MAC Address Change și Forged Transmits pentru rețeaua sync.
Actualizare
- Ne conectăm prin ssh la nodul Active și lansăm comanda pentru a monitoriza starea clusterului: watch -n 2 cphaprob stat
- Ne întoarcem în WebUI pe nodul Stanby pe tab-ul CPUSE și pentru pachetul selectat R80.20 Fresh Install pornim Verifier.
- Analizăm raportul Verifier. Dacă instalarea este permisă, continuăm.
- Selectăm pachetul R80.20 Fresh Install și lansăm Actualizare. În timpul Upgrade-ului, sistemul va fi repornit. Setările GAIA sunt salvate. În momentul repornirii, monitorizăm starea cluster-ului. După încărcare, statusul nodului actualizat ar trebui să se schimbe în READY. În unele cazuri, am întâmpinat o situație în care nodul care nu era încă actualizat trecea în statusul Active Attention și nu mai afișa statusul nodului actualizat. Nu vă panicați – această opțiune este, de asemenea, posibilă.
- După finalizarea actualizării, deschidem SmartDashboard.
- Deschidem obiectul cluster-ului și schimbăm versiunea cluster-ului de la R77.30 la R80.20. Apăsăm Ok. Dacă la salvarea modificărilor apare o eroare:
A apărut o eroare internă. (Cod: 0x8003001D, Nu s-a putut accesa fișierul pentru operațiunea de scriere),
urmează. După aceasta, salvăm modificările și apăsăm Instalare Politică. - În setări, debifăm opțiunea Pentru cluster-e gateway, dacă instalarea pe un membru al cluster-ului eșuează, nu instalați pe acel cluster.
- Instalăm politica. Sistemul va genera o eroare pentru nodul activ care nu a fost încă actualizat.
- Ne conectăm la nodul actualizat prin ssh și rulăm comanda pentru monitorizarea stării cluster-ului: watch -n 2 cphaprob stat
- Ne conectăm la WebUI nodului activ și mergem la tab-ul CPUSE → Afișare toate pachetele.Găsim pachetul de actualizare pentru versiunea R80.20 Fresh Install, apăsăm Descărcare.
- Stabilim Downtime pentru nodurile implicate în sistemul dumneavoastră de monitorizare.
- Ne întoarcem în WebUI nodului activ la tab-ul CPUSE și pentru pachetul selectat R80.20 Fresh Install pornim Verifier.
- Analizăm raportul Verifier. Dacă instalarea este permisă, continuăm.
- Selectăm pachetul R80.20 Fresh Install și lansăm Upgrade. În timpul Upgrade-ului, sistemul va fi repornit. Setările GAIA sunt salvate. În momentul repornirii, monitorizăm starea cluster-ului pe nodul deja actualizat. După repornire, starea cluster-ului pe nodul actualizat se va schimba de la READY la ACTIVE.
- Când procesul de Upgrade se va încheia, deschidem SmartDashboard și instalăm politica.
Listă de verificare după actualizare
- Jurnalele evenimentelor în SmartLog, starea tunelurilor VPN.
- Setările GAIA.
- Restaurarea cluster-ului după testul Failover.
- Licențe și contracte. În cazul în care licențele sunt afișate incorect sau nu sunt afișate pe SMS, rulăm comanda vsec_central_licence pentru distribuirea licențelor.
- CoreXL.
- SecureXL.
- Hotfix și CPinfo pe două noduri.
Concluzie
În esență, acesta este momentul – ați fost actualizați.
Întregul proces a durat în medie între 6 și 12 ore, în funcție de dimensiunile bazelor exportate. Am lucrat două nopți: una pentru actualizarea SMS-ului, a doua pentru cluster.
Nu au existat întreruperi ale traficului, în ciuda faptului că toate erorile menționate mai sus le-am verificat pe pielea noastră.
Desigur, uneori pot apărea și dificultăți complet noi în procesul de actualizare, dar aceasta este Check Point și, așa cum știm cu toții, există întotdeauna un hotfix!
Vă dorim nopți și actualizări plăcute în nuanțe de roz și negru!
Sursa: habr.com
