Im Herbst 2019 stellte Check Point die Unterstützung der Versionen R77.XX ein und es war ein Update erforderlich. Über den Unterschied zwischen den Versionen, die Vor- und Nachteile eines Umstiegs auf den R80 wurde bereits viel gesagt. Lassen Sie uns darüber sprechen, wie Sie die virtuellen Check Point-Appliances (CloudGuard für VMware ESXi, Hyper-V, KVM Gateway NGTP) tatsächlich aktualisieren und was schief gehen kann.
Wir hatten also zwei CCSE-Ingenieure, mehr als ein Dutzend virtuelle Check Point R2-Cluster, mehrere Clouds, ein paar Hotfixes und ein ganzes Meer verschiedener Bugs, Glitches und all das, in allen Farben und Größen, und auch sehr enge Fristen. Lass uns gehen!
Inhalt:
So sieht die Cloud-Infrastruktur eines typischen Kunden mit virtuellem Check Point aus
Training
Im ersten Schritt wird geprüft, ob genügend Ressourcen für das Update vorhanden sind. Die empfohlenen Mindestanforderungen für R80.20 sehen derzeit wie folgt aus:
Gerät
CPU
RAM
HDD
Sicherheits-Gateway
2 Kern
4 Gb
Ab 15 GB
SMS
2 Kern
6 Gb
-
Empfehlungen sind im Dokument beschrieben .
Aber wir werden realistisch bleiben. Wenn dies in der minimalsten Konfiguration ausreicht, dann haben wir, wie die Praxis zeigt, normalerweise die https-Inspektion aktiviert, SmartEvent läuft auf SMS usw., was natürlich ganz andere Kapazitäten erfordert. Aber im Allgemeinen nicht mehr als für R77.30.
Aber es gibt Nuancen. Und sie beziehen sich vor allem auf die Größe des physischen Gedächtnisses. Viele Vorgänge direkt während des Update-Vorgangs erfordern Festplattenspeicher.
Für den Verwaltungsserver hängt die Größe des freien Speicherplatzes stark von der Menge der aktuellen Protokolle (sofern wir diese speichern möchten) und von der Anzahl der gespeicherten Datenbankrevisionen ab, obwohl wir diese nicht mehr in großen Mengen benötigen. Für Cluster-Knoten spielt dies natürlich keine Rolle (es sei denn, Sie speichern auch Protokolle lokal). So prüfen Sie, ob Sie über den benötigten Platz verfügen:
- 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
- Bei der Ausgabe sehen wir etwa diese Konfiguration:
Verwendete Dateisystemgröße, verfügbare Nutzung %. Eingebunden auf
/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 - Wir sind derzeit an der Rubrik interessiert / var / log
Bitte beachten Sie, dass je nach Richtlinie zum Speichern und Löschen alter Protokolldateien sowie der Größe der exportierten Datenbank möglicherweise mehr Speicherplatz benötigt wird. Wenn beim Erstellen eines Archivs weniger freier Speicherplatz vorhanden ist, als in der Protokolldatei-Speicherrichtlinie angegeben ist, beginnt das System, alte Protokolle zu löschen und sie NICHT in das Archiv aufzunehmen.
Außerdem benötigt das System für den Update-Vorgang mindestens 13 GB nicht zugewiesenen Festplattenspeicher. Sie können das Vorhandensein mit dem folgenden Befehl überprüfen:
[Expert@cp-sms:0]# pvs
Wir werden so etwas 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 sind genügend Ressourcen vorhanden. Sie können mit der Aktualisierung beginnen.
Aktualisierung des Check Point SMS-Verwaltungsservers
Bevor Sie mit der Arbeit beginnen, müssen Sie Folgendes tun:
- Installieren Sie das Migration Tools-Paket auf dem Verwaltungsserver. Dazu müssen Sie das Bild vom Portal herunterladen.
- Laden Sie das Archiv über WinSCP in den Ordner auf den Managementserver hoch /var/log/UpgradeR77.30_R80.20 (Erstellen Sie ggf. zunächst einen Ordner.)
- Stellen Sie über SSH eine Verbindung zum Verwaltungsserver her und wechseln Sie in den Ordner mit dem Archiv:cd /var/log/UpgradeR77.30_R80.20/
- Entpacken Sie die Datei:tar -zxvf ./<Dateiname>.tgz
- Wir starten das Dienstprogramm pre_upgrade_verifier mit dem Befehl: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
- Bei Ausführung des Befehls wird ein Bericht über inkompatible Einstellungen erstellt. Es ist erhältlich unter: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Es ist bequemer, es über SCP hochzuladen und über einen Browser anzusehen.
Um inkompatible Einstellungen zu beheben, verwenden Sie. - Führen Sie dann das Dienstprogramm pre_upgrade_verifier erneut aus, um sicherzustellen, dass alle Ursachen der Inkompatibilität beseitigt wurden.
- Als nächstes sammeln wir Informationen über Netzwerkschnittstellen, die Routing-Tabelle und laden die GAIA-Konfiguration hoch:
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 "Konfiguration anzeigen" > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt - Laden Sie die resultierende Datei über SCP hoch.
- Wir machen einen Snapshot auf der Virtualisierungsebene.
- Wir erhöhen das Timeout der SSH-Sitzung auf 8 Stunden. Es hängt von Ihrem Glück ab: Je nach Größe der exportierten Datenbank kann der Vorgang mehrere Minuten bis mehrere Stunden dauern. Dafür:
[Expert@HostName]# clish -c "show inactivity-timeout" Schauen Sie sich den aktuellen Timeout-Clish an.[Expert@HostName]# clish -c "set inactivity-timeout 720" Geben Sie den neuen Timeout-Clish (in Minuten) an.
[Expert@HostName]# echo $TMOUT Schauen Sie sich den aktuellen Timeout-Expertenmodus an.
[Expert@HostName]# export TMOUT=3600 Geben Sie den neuen Timeout-Expertenmodus (in Sekunden) an. Wenn Sie den Wert auf 0 setzen, wird Timeout deaktiviert.
- Wir laden das SMS.iso-Installationsimage herunter und mounten es auf der virtuellen Maschine.
Stellen Sie vor dem nächsten Schritt UNBEDINGT sicher, dass Sie über genügend nicht zugewiesenen Speicherplatz auf Ihrer Festplatte verfügen (denken Sie daran, dass Sie 13 GB benötigen).
- Bevor Sie mit dem Exportieren der Konfiguration beginnen, ändern Sie die Protokolldatei mit dem folgenden Befehl: fw logswitch
Konfiguration und Protokolle exportieren
- Führen Sie das Dienstprogramm migrate_export aus, um die Konfiguration herunterzuladen. Gehen Sie dazu in den zuvor erstellten Ordner: cd /var/log/UpgradeR77.30_R80.20/ und verwenden Sie den Befehl: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
oder
Gehe in den Ordner: cd $FWDIR/bin/upgrade_tools/ и
Führen Sie den Befehl von dort aus: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz - Wir entfernen die Prüfsumme aus dem Archiv: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Speichern Sie den resultierenden Wert im Notizblock.
- Wir verbinden uns über SCP mit SMS und laden das Archiv mit der Konfiguration auf den Arbeitsplatz hoch. Stellen Sie sicher, dass Sie die Dateiübertragung im Binärformat verwenden.
Exportieren Sie die SmartEvent-Datenbank
Hier benötigen wir die vorinstallierte SMS-Version R80. Jeder Test reicht aus.
- Von SMS benötigen wir ein Skript, das sich hier befindet:$RTDIR/bin/eva_db_backup.csh
- Laden Sie das Skript über SCP eva_db_backup.csh zum Ordner: /var/log/UpgradeR77.30_R80.20/
- Verbinden Sie sich über SSH mit SMS. Datei in Ordner kopieren: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$RTDIR/bin/eva_db_backup.csh - Codierung ändern: dos2unix $RTDIR/bin/eva_db_backup.csh
- Eigentümer hinzufügen: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
- Rechte hinzufügen: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
- Wir beginnen mit dem Export der SmartEvent-Datenbank: $RTDIR/bin/eva_db_backup.csh
- Laden Sie die empfangenen Dateien über SCP hoch: $RTDIR/bin/<Datum>-db-backup.backup и $RTDIR/bin/eventiaUpgrade.tar zum Arbeitsplatz.
Aktualisieren
- Wir gehen zu WebUI GAIA SMS → CPUSE → Alle Pakete anzeigen.
- Wenn CPUSE beim Herstellen der Verbindung zur Check Point-Cloud einen Fehler ausgibt, überprüfen Sie die DGW-, DNS- und Proxy-Einstellungen.
- Wenn alles korrekt ist und der Fehler nicht verschwindet, müssen Sie CPUSE manuell unter Anleitung aktualisieren.
- Laden Sie das Bild herunter und gehen Sie durch Prüfer. Bei Bedarf beseitigen wir Unstimmigkeiten.
Als Ergebnis sollte diese Meldung angezeigt werden:
- wählen R80.20 Neuinstallation und Upgrade für das Sicherheitsmanagement.
- Wählen Sie bei der Installation des Updates „Clean Install“ aus. Nach der Installation wird das System neu gestartet.
- Wir kommen zum ersten Mal vorbei Magier.
- Nach Erhalt des Zugangs prüfen wir die Konten.
- Wir verbinden uns über SSH mit SMS und ändern die Shell unseres Benutzers in /bin/bash/:
Setze Benutzer <Benutzername> Shell /bin/bash/
Konfig speichern (für den Fall, dass wir bin/bash/ nach dem Neustart als Standard-Shell belassen möchten).
- Als nächstes verbinden wir uns über SCP mit SMS und übertragen das Archiv mit der Konfiguration im Binärmodus SMS_w_logs_export_r77_r80.tgz zum Ordner /var/log/UpgradeR77.30_R80.20/
- Wir entfernen die Prüfsumme aus dem Archiv: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz und mit dem vorherigen Wert vergleichen. Prüfsumme muss übereinstimmen.
- Wir erhöhen das Timeout der SSH-Sitzung auf 8 Stunden. Dafür:
[Expert@HostName]# clish -c "show inactivity-timeout" Schauen Sie sich den aktuellen Timeout-Clish an.
[Expert@HostName]# clish -c "set inactivity-timeout 720" Geben Sie den neuen Timeout-Clish (in Minuten) an.
[Expert@HostName]# echo $TMOUT Schauen Sie sich den aktuellen Timeout-Expertenmodus an.
[Expert@HostName]# export TMOUT=3600 Geben Sie den neuen Timeout-Expertenmodus (in Sekunden) an. Wenn Sie den Wert auf 0 setzen, wird die Zeitüberschreitung deaktiviert.
- Um Einstellungen zu importieren, führen Sie das Dienstprogramm „Migrate Import“ aus. Gehen Sie dazu in den Ordner: cd $FWDIR/bin/upgrade_tools/und führen Sie den Import aus: ./migrate imp
ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Lasst uns die nächsten paar Stunden das Leben genießen. TRENNEN SIE IHRE SSH-SITZUNG während des Vorgangs NICHT. Am Ende des Migrationsprozesses wird entweder eine Erfolgsmeldung oder ein Fehler angezeigt.
Checkliste nach dem Update
- Verfügbarkeit von Ressourcen.
- SIC mit GW.
- Lizenzen. Wenn Lizenzen falsch oder nicht in der SMS angezeigt werden, führen Sie den Befehl aus vsec_central_licence für die Lizenzverteilung.
- Festlegen der Richtlinie.
SmartEvent-Datenbank importieren
- Aktivieren Sie das SmartEvent-Blatt.
- Wir verbinden uns über WinSCP mit SMS und übertragen zuvor heruntergeladene Dateien im Binärmodus <Datum>-db-backup.backup и eventiaUpgrade.tar zum Ordner /var/log/UpgradeR77.30_R80.20/
- Wir führen das Skript mit dem Befehl aus: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
- Status prüfen: watch -n 10 eventiaUpgrade.sh
- Überprüfung der Protokolle in SmartEvent. TRAUM!
Aktualisieren des Check Point GW-Clusters (Aktiv/Backup)
Vor Arbeitsbeginn
- Wir speichern die GAIA-Konfiguration von jedem Clusterknoten in einer Datei. Verwenden Sie dazu den Befehl: clish -c "Konfiguration anzeigen" > ./<Dateiname>.txt
- Hochladen von Dateien mit WinSCP.
- Stellen Sie eine Verbindung zur WebUI beider Knoten her und gehen Sie zur Registerkarte CPUSE → Alle Pakete anzeigen.
- Suchen des Update-Pakets für die Version R80.20 Neuinstallation, Drücken Sie Herunterladen.
- Wir überprüfen, ob das CCP-Protokoll im Modus funktioniert ÜbertragenGeben Sie dazu den Befehl ein: cphaprob -a if
Wenn der Modus ausgewählt ist Multicast, ersetzen Sie es durch den Befehl: cphaconf set_ccp Broadcast (Der Befehl wird auf jedem Knoten ausgeführt). - Wir installieren Downtime für die beteiligten Knoten in Ihrem Überwachungssystem.
- Wir prüfen, ob die Parameter auf der Virtualisierungsebene aktiviert sind Änderung der MAC-Adresse и Gefälschte Übertragungen für ein Synchronisierungsnetzwerk.
Aktualisieren
- Wir verbinden uns per SSH mit dem aktiven Knoten und führen den Befehl aus, um den Status des Clusters zu überwachen: watch -n 2 cphaprob stat
- Kehren Sie zur Registerkarte „WebUI Stanby-Knoten“ zurück CPUSE und für das ausgewählte Paket R80.20 Neuinstallation Start Prüfer.
- Lassen Sie uns den Verifier-Bericht analysieren. Wenn die Installation zulässig ist, fahren Sie fort.
- Wählen Sie ein Paket aus R80.20 Neuinstallation und Renn Upgrade. Während des Upgrade-Vorgangs wird das System neu gestartet. GAIA-Einstellungen werden gespeichert. Zum Zeitpunkt des Neustarts überwachen wir den Status des Clusters. Nach dem Laden sollte sich der Status des aktualisierten Knotens in READY ändern. In einigen Fällen kam es zu einem Moment, in dem ein noch nicht aktualisierter Knoten in den Status „Aktive Aufmerksamkeit“ wechselte und den Status des aktualisierten Knotens nicht mehr anzeigte. Seien Sie nicht beunruhigt – diese Option ist auch akzeptabel.
- Sobald das Update abgeschlossen ist, öffnen Sie es SmartDashboard.
- Öffnen Sie das Clusterobjekt und ändern Sie die Clusterversion von R77.30 auf R80.20. OK klicken. Wenn beim Speichern von Änderungen ein Fehler auftritt:
Ein interner Fehler ist aufgetreten. (Code: 0x8003001D, Auf die Datei konnte für den Schreibvorgang nicht zugegriffen werden),
folgen. Speichern Sie anschließend die Änderungen und klicken Sie auf Richtlinie installieren. - Deaktivieren Sie in den Einstellungen die Option Wenn bei Gateway-Clustern die Installation auf einem Cluster-Mitglied fehlschlägt, installieren Sie nicht auf diesem Cluster.
- Wir legen die Richtlinien fest. Das System generiert einen Fehler für einen aktiven Knoten, der noch nicht aktualisiert wurde.
- Wir stellen über ssh eine Verbindung zum aktualisierten Knoten her und führen den Befehl aus, um den Status des Clusters zu überwachen: watch -n 2 cphaprob stat
- Stellen Sie eine Verbindung zum WebUI Active-Knoten her und wechseln Sie zur Registerkarte CPUSE → Alle Pakete anzeigen.Suchen des Update-Pakets für die Version R80.20 Neuinstallation, klicken Herunterladen.
- Wir installieren Downtime für die beteiligten Knoten in Ihrem Überwachungssystem.
- Kehren Sie zur Registerkarte „Aktive Knoten“ der WebUI zurück CPUSE und für das ausgewählte Paket R80.20 Neuinstallation Start Prüfer.
- Lassen Sie uns den Verifier-Bericht analysieren. Wenn die Installation zulässig ist, fahren Sie fort.
- Wählen Sie ein Paket aus R80.20 Neuinstallation und Renn Aktualisierung. Während des Upgrade-Vorgangs wird das System neu gestartet. GAIA-Einstellungen werden gespeichert. Zum Zeitpunkt des Neustarts überwachen wir den Status des Clusters auf dem bereits aktualisierten Knoten. Nach dem Neustart ändert sich der Clusterstatus auf dem aktualisierten Knoten von BEREIT zu AKTIV.
- Wenn der Upgrade-Vorgang abgeschlossen ist, starten Sie SmartDashboard und legen Sie die Richtlinie fest.
Checkliste nach dem Update
- Ereignisprotokolle in SmartLog, Status von VPN-Tunneln.
- GAIA-Einstellungen.
- Wiederherstellen eines Clusters nach einem Test-Failover.
- Lizenzen und Verträge. Wenn Lizenzen falsch oder nicht in der SMS angezeigt werden, führen Sie den Befehl aus. vsec_central_licence für die Lizenzverteilung.
- CoreXL.
- SecureXL.
- Hotfix und CPinfo auf zwei Knoten.
Abschluss
Im Allgemeinen ist das an dieser Stelle alles – Sie wurden auf dem Laufenden gehalten.
Bei uns dauerte der gesamte Vorgang je nach Größe der exportierten Datenbanken durchschnittlich 6 bis 12 Stunden. Die Arbeiten wurden über zwei Nächte hinweg durchgeführt: eine für die Aktualisierung von SMS, die zweite für den Cluster.
Es kam zu keinen Verkehrsausfällen, obwohl wir alle oben genannten Fehler selbst überprüft haben.
Natürlich kann es während des Update-Vorgangs manchmal zu ganz neuen Schwierigkeiten kommen, aber das ist Check Point, und wie wir alle wissen, gibt es immer einen Hotfix!
Frohe schwarze und rosa Nächte und Updates!
Source: habr.com