Im Herbst 2019 stellte Check Point die Unterstützung für die Versionen R77.XX ein, und es war Zeit für ein Update. Es gibt bereits viele Informationen über die Unterschiede zwischen den Versionen sowie die Vor- und Nachteile des Wechsels zu R80. Lassen Sie uns stattdessen darüber sprechen, wie man die virtuellen Appliance von Check Point (CloudGuard für VMware ESXi, Hyper-V, KVM Gateway NGTP) tatsächlich aktualisiert und was dabei schiefgehen kann.
Also, wir hatten 2 CCSE-Ingenieure, mehr als ein Dutzend virtueller Cluster von Check Point R77.30, mehrere Clouds, ein paar Hotfixes und ein Meer von verschiedenen Bugs, Glitches und all diesem Kram in allen Formen und Farben sowie sehr enge Zeitrahmen. Legen wir los!
Inhalt:
So sieht die typische Cloud-Infrastruktur eines Kunden mit virtualisiertem Check Point aus
Vorbereitung
Zuerst müssen wir die Ressourcen für das Update überprüfen. Die empfohlenen Mindestanforderungen für R80.20 sehen jetzt wie folgt aus:
Gerät
CPU
RAM
HDD
Sicherheitsgateway
2 Kerne
4 GB
Ab 15 GB
SMS
2 Kerne
6 GB
—
Die Empfehlungen sind im Dokument beschrieben .
Seien wir jedoch realistisch. Auch wenn die minimalste Konfiguration ausreicht, zeigt die Praxis, dass in der Regel HTTPS-Inspektion aktiviert ist, SmartEvent über SMS funktioniert usw., was selbstverständlich ganz andere Kapazitäten erfordert. Insgesamt sind diese jedoch nicht größer als für R77.30.
Es gibt jedoch Nuancen. Diese betreffen in erster Linie die Größe des physischen Speichers. Viele Vorgänge im Aktualisierungsprozess benötigen Platz auf der Festplatte.
Für den Management-Server hängt die Größe des freien Speicherplatzes auf der Festplatte stark vom Volumen der aktuellen Logs ab (falls wir diese aufbewahren möchten) und von der Anzahl der gespeicherten Datenbankrevisionen, obwohl wir diese in der Regel nicht in großen Mengen benötigen. Für die Cluster-Knoten spielt das, sofern Sie die Logs nicht lokal speichern, keine Rolle. So können Sie überprüfen, ob der benötigte Speicherplatz vorhanden ist:
- Wir verbinden uns per SSH mit dem Smart Management Server, gehen in den Expertenmodus und geben den Befehl ein:
[Expert@cp-sms:0]# df -h
- Die Ausgabe wird ungefähr folgendes Format haben:
Dateisystem Größe Benutzt Verfügbar Nutzung% Eingehängt in
/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 interessiert uns der Abschnitt /var/log
Bitte beachten Sie, dass je nach Richtlinien zur Speicherung und Löschung von alten Log-Dateien sowie der Größe der exportierten Datenbank möglicherweise mehr Speicherplatz erforderlich ist. Wenn beim Erstellen des Archivs der verfügbare Speicherplatz unter den in der Richtlinie für die Speicherung von Log-Dateien angegebenen Wert fällt, beginnt das System, alte Logs zu löschen und wird diese NICHT in das Archiv aufnehmen.
Für den Aktualisierungsprozess benötigt das System außerdem mindestens 13 GB nicht zugewiesenen Speicherplatz auf der Festplatte. Sie können dessen Verfügbarkeit mit dem Befehl überprüfen:
[Expert@cp-sms:0]# pvs
Wir werden ungefähr die folgende Ausgabe sehen:
PV VG Fmt Attr PSize PFree
/dev/sda3 vg_splat lvm2 a- 141.69G 43.69G
In diesem Fall haben wir 43 GB. Es stehen genügend Ressourcen zur Verfügung. Wir können mit dem Update beginnen.
Wir aktualisieren den Verwaltungserver Check Point SMS
Vor Beginn der Arbeiten müssen Sie Folgendes tun:
- Installieren Sie das Migration Tools-Paket auf dem Verwaltungsserver. Dazu müssen Sie das Abbild vom Portal herunterladen..
- Laden Sie das Archiv über WinSCP in den Ordner auf dem Verwaltungsserver hoch. /var/log/UpgradeR77.30_R80.20 (Falls erforderlich, erstellen Sie vorher einen Ordner).
- Verbinden Sie sich über SSH mit dem Verwaltungsserver und navigieren Sie zu dem Ordner mit dem Archiv:cd /var/log/UpgradeR77.30_R80.20/
- Entpacken Sie die Datei:tar -zxvf ./.tgz
- Starten Sie das Tool pre_upgrade_verifier mit dem Befehl: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
- Nach Ausführung des Befehls wird ein Bericht über inkompatible Einstellungen erstellt. Dieser ist verfügbar unter: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Es ist praktischer, ihn über SCP herunterzuladen und im Browser anzusehen.
Zur Behebung aller inkompatiblen Einstellungen verwenden Sie. - Führen Sie die Utility pre_upgrade_verifier erneut aus, um sicherzustellen, dass alle Kompatibilitätsprobleme behoben sind.
- Als nächstes sammeln wir Informationen über die Netzwerk-Schnittstellen, die Routing-Tabelle und exportieren die GAIA-Konfiguration:
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 - Laden Sie die erhaltene Datei über SCP herunter.
- Erstellen Sie einen Snapshot auf der Virtualisierungsebene.
- Erhöhen Sie den Timeout für die SSH-Sitzung auf 8 Stunden. Dies kann variieren: je nach Größe der exportierten Datenbank kann dies von einigen Minuten bis zu mehreren Stunden dauern. Dafür:
[Expert@HostName]# clish -c "show inactivity-timeout" wir prüfen den aktuellen Timeout in clish,[Expert@HostName]# clish -c "set inactivity-timeout 720" wir setzen den neuen Timeout für clish (in Minuten),
[Expert@HostName]# echo $TMOUT wir prüfen den aktuellen Timeout im Expertenmodus,
[Expert@HostName]# export TMOUT=3600 wir setzen den neuen Timeout im Expertenmodus (in Sekunden). Wenn Sie den Wert 0 einstellen, wird der Timeout deaktiviert.
- Wir laden das Installationsimage SMS.iso in die virtuelle Maschine ein und montieren es.
Vor dem nächsten Schritt überprüfen Sie unbedingt erneut, ob genügend unbenutzter Speicherplatz auf der Festplatte vorhanden ist (denken Sie daran, es werden 13 GB benötigt).
- Bevor wir mit dem Export der Konfiguration beginnen, ändern wir die Protokolldatei mit dem Befehl: fw logswitch
Export der Konfiguration und Logs
- Wir starten das Tool migrate_export, um die Konfiguration zu exportieren. Dazu navigieren wir in den zuvor erstellten Ordner: cd /var/log/UpgradeR77.30_R80.20/ und verwenden den Befehl: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
oder
wir wechseln in den Ordner: cd $FWDIR/bin/upgrade_tools/ und
und führen von dort den Befehl aus: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz - Wir erstellen die Prüfziffer für das Archiv: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Notieren Sie sich den erhaltenen Wert.
- Verbinden Sie sich über SCP mit dem SMS und laden Sie das Archiv mit der Konfiguration auf die Workstation herunter. Achten Sie darauf, den Dateiübertragungsmodus Binary zu verwenden.
Export der SmartEvent-Datenbank
Hierfür benötigen wir einen zuvor installierten SMS der Version R80. Jede Testversion ist geeignet.
- Von SMS benötigen wir das Skript, das sich hier befindet:$RTDIR/bin/eva_db_backup.csh
- Laden Sie das Skript über SCP hoch eva_db_backup.csh in den Ordner: /var/log/UpgradeR77.30_R80.20/
- Stellen Sie eine SSH-Verbindung zum SMS her. Kopieren Sie die Datei in den Ordner: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$RTDIR/bin/eva_db_backup.csh - Ändern Sie die Kodierung: dos2unix $RTDIR/bin/eva_db_backup.csh
- Eigentümer hinzufügen: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
- Berechtigungen hinzufügen: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
- Starten Sie den Export der SmartEvent-Datenbank: $RTDIR/bin/eva_db_backup.csh
- Übertragen Sie die erhaltenen Dateien über SCP: $RTDIR/bin/-db-backup.backup und $RTDIR/bin/eventiaUpgrade.tar auf die Arbeitsstation.
Aktualisierung
- Gehen wir zu WebUI GAIA SMS → CPUSE → Alle Pakete anzeigen.
- Wenn CPUSE einen Verbindungsfehler mit der Check Point Cloud ausgibt, überprüfen Sie DGW, DNS und die Proxy-Einstellungen.
- Wenn alles korrekt ist und der Fehler weiterhin besteht, muss CPUSE manuell aktualisiert werden, gemäß.
- Laden Sie das Abbild herunter und fahren Sie fort. Verifier. Beseitigen Sie gegebenenfalls Diskrepanzen.
Am Ende sollten wir folgende Nachricht sehen:
- Wählen Sie R80.20 Neuinstallation und Upgrade für Security Management.
- Wählen Sie bei der Installation des Updates 'Clean Install'. Nach der Installation wird das System neu gestartet.
- Durchlaufen Sie den Ersteinrichtungs- Assistenten.
- Nach dem Zugriff überprüfen Sie die Konten.
- Verbinden Sie sich per SSH mit der SMS und ändern Sie die Shell unseres Benutzers auf /bin/bash:
set user shell /bin/bash
save config (falls wir /bin/bash als Standard-Shell auch nach dem Neustart beibehalten möchten).
- Verbinden Sie sich dann über SCP mit der SMS und übertragen Sie im Binärmodus das Archiv mit der Konfiguration SMS_w_logs_export_r77_r80.tgz in den Ordner /var/log/UpgradeR77.30_R80.20/
- Wir erstellen die Prüfziffer für das Archiv: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz und vergleichen sie mit dem vorherigen Wert. Die Checksummen müssen übereinstimmen.
- Wir erhöhen den Timeout der SSH-Sitzung auf 8 Stunden. Dazu:
[Expert@HostName]# clish -c "show inactivity-timeout" wir prüfen den aktuellen Timeout in clish,
[Expert@HostName]# clish -c "set inactivity-timeout 720" wir setzen den neuen Timeout für clish (in Minuten),
[Expert@HostName]# echo $TMOUT wir prüfen den aktuellen Timeout im Expertenmodus,
[Expert@HostName]# export TMOUT=3600 geben wir den neuen Timeout im Expertenmodus (in Sekunden) an. Wenn Sie den Wert 0 setzen, wird der Timeout deaktiviert.
- Um die Einstellungen zu importieren, starten wir das Dienstprogramm migrate import. Dazu wechseln wir in das Verzeichnis: cd $FWDIR/bin/upgrade_tools/und starten den Import: ./migrate imp
ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Genießen Sie das Leben in den nächsten paar Stunden. SCHALTEN SIE DIE SSH-SITZUNG während des Vorgangs NICHT AUS. Am Ende gibt der Migrationsprozess entweder eine Meldung über einen erfolgreichen Abschluss der Operation oder einen Fehler aus.
Checkliste der Überprüfungen nach dem Update
- Verfügbarkeit der Ressourcen.
- SIC mit GW.
- Lizenzen. Wenn Lizenzen falsch angezeigt werden oder nicht im SMS angezeigt werden, führen wir den Befehl aus vsec_central_licence zur Verteilung der Lizenzen.
- Richtlinieninstallation.
Import der SmartEvent-Datenbank.
- Aktivieren Sie das SmartEvent-Blade.
- Verbinden Sie sich über WinSCP mit dem SMS und übertragen Sie die zuvor exportierten Dateien im binären Modus -db-backup.backup und eventiaUpgrade.tar in den Ordner /var/log/UpgradeR77.30_R80.20/
- Starten Sie das Skript mit dem Befehl: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
- Überprüfen Sie den Status: watch -n 10 eventiaUpgrade.sh
- Überprüfen Sie die Protokolle in SmartEvent. SCHLAFEN!
Aktualisieren Sie das Check Point GW-Kluster (Active/Backup)
Vor Beginn der Arbeiten
- Wir speichern die GAIA-Konfiguration von jedem Knoten des Clusters in eine Datei. Dafür verwenden Sie den Befehl: clish -c "show configuration" > ./.txt
- Wir übertragen die Dateien mit WinSCP.
- Wir verbinden uns mit der WebUI beider Knoten und gehen zum Tab CPUSE → Alle Pakete anzeigen.
- Wir suchen das Update-Paket für die Version R80.20 Frische Installation, drücken Sie Herunterladen.
- Wir überprüfen, ob das CCP-Protokoll im Modus Broadcastfunktioniert. Dazu geben wir den Befehl ein: cphaprob -a if
Wenn der Modus Multicastausgewählt ist, ändern Sie ihn mit folgendem Befehl: cphaconf set_ccp broadcast (Der Befehl wird auf jedem Knoten ausgeführt). - Wir setzen die Downtime für die betroffenen Knoten in Ihrem Überwachungssystem.
- Wir überprüfen, ob die Parameter auf der Virtualisierungsebene aktiviert sind: Änderung der MAC-Adresse und Gefälschte Übertragungen für das Sync-Netzwerk.
Aktualisierung
- Wir verbinden uns per SSH mit dem aktiven Knoten und starten den Befehl zur Überwachung des Clusterstatus: watch -n 2 cphaprob stat
- Wir kehren zur WebUI des Standby-Knotens zurück und gehen zum Tab CPUSE und für das ausgewählte Paket R80.20 Frische Installation starten wir Verifier.
- Wir analysieren den Verifier-Bericht. Wenn die Installation erlaubt ist, fahren wir fort.
- Wir wählen das Paket R80.20 Frische Installation und starten es. Upgrade. Während des Upgrades wird das System neu gestartet. Die GAIA-Einstellungen bleiben erhalten. Während des Neustarts beobachten wir den Zustand des Clusters. Nach dem Booten sollte der Status des aktualisierten Knotens auf READY wechseln. In einigen Fällen kam es vor, dass der noch nicht aktualisierte Knoten in den Status Active Attention wechselte und der Status des aktualisierten Knotens nicht mehr angezeigt wurde. Keine Sorge – diese Möglichkeit ist ebenfalls zulässig.
- Nach Abschluss des Updates öffnen wir SmartDashboard.
- Wir öffnen das Clusterobjekt und ändern die Cluster-Version von R77.30 auf R80.20. Wir klicken auf OK. Wenn beim Speichern der Änderungen ein Fehler auftritt:
Es ist ein interner Fehler aufgetreten. (Code: 0x8003001D, Datei konnte nicht für Schreiboperationen zugegriffen werden),
befolgen Sie. Danach speichern wir die Änderungen und klicken auf Install Policy. - In den Einstellungen entfernen wir das Häkchen bei der Option Für Gateway-Cluster, falls die Installation auf einem Clustermitglied fehlschlägt, nicht auf diesem Cluster installieren.
- Wir installieren die Richtlinie. Das System wird einen Fehler für den Active-Knoten ausgeben, der noch nicht aktualisiert wurde.
- Wir verbinden uns per SSH mit dem aktualisierten Knoten und führen den Befehl zur Überwachung des Clusterzustands aus: watch -n 2 cphaprob stat
- Wir verbinden uns mit der WebUI des Active-Knotens und wechseln zum Tab CPUSE → Alle Pakete anzeigen.Wir suchen das Update-Paket für die Version R80.20 Frische Installation, klicken wir auf Herunterladen.
- Wir setzen die Downtime für die betroffenen Knoten in Ihrem Überwachungssystem.
- Wir kehren zur WebUI des Active-Knotens zurück und gehen zum Tab CPUSE und für das ausgewählte Paket R80.20 Frische Installation starten wir Verifier.
- Wir analysieren den Verifier-Bericht. Wenn die Installation erlaubt ist, fahren wir fort.
- Wir wählen das Paket R80.20 Frische Installation und starten es. Upgrade. Während des Upgrades wird das System neu gestartet. Die GAIA-Einstellungen werden beibehalten. Während des Neustarts überwachen wir den Status des Clusters auf dem bereits aktualisierten Knoten. Nach dem Neustart ändert sich der Status des Clusters auf dem aktualisierten Knoten von READY auf ACTIVE.
- Sobald der Upgrade-Prozess abgeschlossen ist, starten wir das SmartDashboard und legen die Richtlinie fest.
Checkliste der Überprüfungen nach dem Update
- Ereignisprotokolle in SmartLog, Status der VPN-Tunnel.
- GAIA-Einstellungen.
- Wiederherstellung des Clusters nach einem Test-Failover.
- Lizenzen und Verträge. Falls Lizenzen falsch oder gar nicht auf dem SMS angezeigt werden, führen wir den Befehl vsec_central_licence zur Verteilung der Lizenzen aus.
- CoreXL.
- SecureXL.
- Hotfix und CPinfo auf zwei Knoten.
Fazit
Im Grunde genommen war das alles – Sie haben aktualisiert.
Der gesamte Prozess hat im Durchschnitt zwischen 6 und 12 Stunden gedauert, abhängig von den Größen der exportierten Datenbanken. Die Arbeiten wurden über zwei Nächte durchgeführt: eine für das Update des SMS, die andere für den Cluster.
Es gab keine Unterbrechungen des Datenverkehrs, obwohl wir all die oben genannten Fehler selbst überprüft haben.
Natürlich können während des Updates auch völlig neue Probleme auftreten, aber das ist Check Point, und wie wir alle wissen, gibt es immer einen Hotfix!
Viel Erfolg bei Ihren schwarz-rosa Nächten und Updates!
Quelle: habr.com
