Im Herbst 2019 hat Check Point die Unterstützung für die Versionen R77.XX eingestellt, sodass ein Upgrade erforderlich wurde. Über die Unterschiede zwischen den Versionen, die Vor- und Nachteile des Wechsels auf R80 wurde bereits viel gesagt. Lassen Sie uns besser darüber sprechen, wie man die virtuellen Appliances von Check Point (CloudGuard für VMware ESXi, Hyper-V, KVM Gateway NGTP) aktualisiert und was schiefgehen könnte.
Also, wir hatten 2 CCSE-Ingenieure, mehr als ein Dutzend virtuelle Cluster von Check Point R77.30, mehrere Clouds, ein paar Hotfixes und eine ganze Menge an verschiedenen Bugs, Glitches und so weiter, in allen Formen und Farben, und zudem sehr enge Fristen. Lassen Sie uns anfangen!
Inhalt:
So sieht die typische Cloud-Infrastruktur eines Kunden mit virtuellem Check Point aus
Vorbereitung
Zuerst müssen wir die Ressourcenverfügbarkeit für das Upgrade überprüfen. Die empfohlenen Mindestanforderungen für R80.20 sehen derzeit folgendermaßen aus:
Gerät
CPU
RAM
HDD
Security Gateway
2 Kerne
4 Gb
Ab 15 GB
SMS
2 Kerne
6 Gb
—
Die Empfehlungen sind im Dokument .
Aber wir wollen realistisch sein. Wenn das in der minimalen Konfiguration ausreicht, zeigt die Praxis, dass bei uns normalerweise die HTTPS-Inspektion aktiviert ist, SmartEvent auf dem SMS läuft, usw. was natürlich ganz andere Ressourcen erfordert. Aber insgesamt nicht viel mehr als für R77.30.
Aber es gibt Nuancen. Und die betreffen in erster Linie die Größe des physischen Speichers. Viele Vorgänge während des Update-Prozesses benötigen Platz auf der Festplatte.
Für den Management-Server wird die Größe des freien Speicherplatzes auf der Festplatte stark von der Menge an aktuellen Protokollen abhängen (wenn wir diese speichern möchten) und von der Anzahl der gespeicherten Datenbankrevisionen, obwohl wir diese in großer Zahl nicht mehr benötigen. Natürlich spielt das für die Knoten des Clusters (es sei denn, Sie speichern die Protokolle auch lokal) keine Rolle. So können Sie den erforderlichen Speicherplatz überprüfen:
- Wir verbinden uns per SSH mit dem Smart Management Server, gehen in den Expert-Modus und geben den Befehl ein:
[Expert@cp-sms:0]# df -h
- Im Ergebnis sehen wir etwa eine solche Konfiguration:
Dateisystem Größe Benutzt Verfügbar Verw. % Eingehängt 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 - Derzeit interessiert uns die Partition /var/log
Bitte beachten Sie, dass je nach Aufbewahrungs- und Löschrichtlinien für alte 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 den Aufbewahrungsrichtlinien für Log-Dateien angegebenen Wert fällt, beginnt das System mit dem Löschen alter Logs und schließt diese NICHT in das Archiv ein.
Für den Aktualisierungsprozess benötigt das System außerdem mindestens 13 GB unzugeordneten Speicherplatz auf der Festplatte. Um dies zu überprüfen, können Sie den Befehl verwenden:
[Expert@cp-sms:0]# pvs
Wir werden ungefähr 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 sind genügend Ressourcen vorhanden. Wir können mit dem Upgrade beginnen.
Wir aktualisieren den Check Point SMS Management Server
Vor Beginn der Arbeiten müssen folgende Schritte unternommen werden:
- Installieren Sie das Migration Tools-Paket auf dem Management-Server. Dazu muss das Image vom Portal heruntergeladen werden:.
- Laden Sie das Archiv über WinSCP in den Ordner auf dem Management-Server hoch: /var/log/UpgradeR77.30_R80.20 (falls erforderlich, zuerst den Ordner erstellen).
- Verbinden Sie sich über SSH mit dem Management-Server und navigieren Sie in den 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. Er ist unter folgender Adresse verfügbar: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Am einfachsten ist es, ihn über SCP herunterzuladen und im Browser anzusehen.
Um alle inkompatiblen Einstellungen zu beheben, verwenden Sie. - Starten Sie das Tool pre_upgrade_verifier erneut, um sicherzustellen, dass alle Ursachen für die Inkompatibilität behoben wurden.
- Sammlung von Informationen zu Netzwerkschnittstellen, Routing-Tabelle und Konfiguration von GAIA exportieren:
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 - Exportieren Sie die erhaltene Datei über SCP.
- Erstellen Sie ein Snapshot auf der Virtualisierungsebene.
- Erhöhen Sie das Timeout der SSH-Sitzung auf 8 Stunden. Das hängt vom Glück ab: je nach Größe der exportierten Datenbank kann es von mehreren Minuten bis zu mehreren Stunden dauern. Dazu:
[Expert@HostName]# clish -c "show inactivity-timeout" Prüfen Sie das aktuelle Timeout des clish.[Expert@HostName]# clish -c "set inactivity-timeout 720" Geben Sie das neue Timeout für clish (in Minuten) an.
[Expert@HostName]# echo $TMOUT Prüfen Sie das aktuelle Timeout im Expert-Modus.
[Expert@HostName]# export TMOUT=3600 Geben Sie das neue Timeout für den Expert-Modus (in Sekunden) an; wenn der Wert 0 ist, wird der Timeout deaktiviert.
- Laden und mounten Sie das Installations-Image SMS.iso an die virtuelle Maschine.
Überprüfen Sie unbedingt vor dem nächsten Schritt noch einmal, dass genügend nicht zugewiesener Speicherplatz auf der Festplatte verfügbar ist (ich erinnere daran, dass Sie 13 GB benötigen).
- Ändern Sie vor dem Export der Konfiguration die Protokolldatei mit dem Befehl: fw logswitch
Export der Konfiguration und Protokolle
- Starten Sie das Dienstprogramm migrate_export, um die Konfiguration zu exportieren. Navigieren 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
wechseln Sie in den Ordner: cd $FWDIR/bin/upgrade_tools/ und
führen Sie von dort den Befehl aus: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz - Überprüfen Sie die Prüfziffer des Archivs: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Speichern Sie den erhaltenen Wert in einem Textdokument.
- Verbinden Sie sich über SCP mit dem SMS und laden Sie das Archiv mit der Konfiguration auf die Arbeitsstation herunter. Verwenden Sie unbedingt die Datenübertragung im Binary-Format.
Export der SmartEvent-Datenbank
Wir benötigen eine zuvor installierte SMS-Version R80. Jeder Test 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/
- Verbinden Sie sich über SSH mit dem SMS. 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
- Fügen Sie den Besitzer hinzu: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
- Fügen Sie die Berechtigungen hinzu: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
- Starten Sie den Export der SmartEvent-Datenbank: $RTDIR/bin/eva_db_backup.csh
- Laden Sie die erhaltenen Dateien über SCP hoch: $RTDIR/bin/-db-backup.backup und $RTDIR/bin/eventiaUpgrade.tar auf die Arbeitsstation.
Aktualisierung
- Gehen Sie zu WebUI GAIA SMS → CPUSE → Alle Pakete anzeigen.
- Falls CPUSE einen Verbindungsfehler zum Check Point-Cloud ausgibt, überprüfen Sie DGW, DNS und Proxy-Einstellungen.
- Wenn alles korrekt ist und der Fehler nicht verschwindet, müssen Sie CPUSE manuell aktualisieren, gemäß.
- Laden Sie das Image herunter und fahren Sie fort mit Verifier. Beheben Sie ggf. Unstimmigkeiten.
Sie sollten dann diese Nachricht sehen:
- Wählen Sie R80.20 Fresh Install and Upgrade for Security Management.
- Wählen Sie beim Installieren des Updates die Option Clean Install. Nach der Installation wird das System neu gestartet.
- Durchlaufen Sie den ersten Assistent.
- Überprüfen Sie nach dem Zugriff die Konten.
- Verbinden Sie sich über SSH mit dem 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 einem Neustart beibehalten möchten).
- Verbinden Sie sich als nächstes über SCP mit dem SMS und übertragen Sie das Archiv mit der Konfiguration im Binary-Modus SMS_w_logs_export_r77_r80.tgz in den Ordner /var/log/UpgradeR77.30_R80.20/
- Überprüfen Sie die Prüfziffer des Archivs: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz und vergleichen wir mit dem vorherigen Wert. Die Checksumme muss übereinstimmen.
- Wir erhöhen den Timeout der SSH-Sitzung auf 8 Stunden. Dafür:
[Expert@HostName]# clish -c "show inactivity-timeout" Prüfen Sie das aktuelle Timeout des clish.
[Expert@HostName]# clish -c "set inactivity-timeout 720" Geben Sie das neue Timeout für clish (in Minuten) an.
[Expert@HostName]# echo $TMOUT Prüfen Sie das aktuelle Timeout im Expert-Modus.
[Expert@HostName]# export TMOUT=3600 geben wir den neuen Timeout im Expertenmodus (in Sekunden) an. Wenn der Wert 0 gesetzt wird, ist der Timeout deaktiviert.
- Für den Import der Einstellungen starten wir das Tool migrate import. Dazu wechseln wir in den Ordner: 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 VERFAHRENS NICHT AUS. Am Ende wird der Migrationsprozess entweder eine Erfolgsmeldung oder eine Fehlermeldung ausgeben.
Checkliste nach dem Update
- Verfügbarkeit der Ressourcen.
- SIC mit GW.
- Lizenzen. Wenn die Lizenzen nicht korrekt angezeigt werden oder auf der SMS nicht angezeigt werden, führen wir den Befehl aus vsec_central_licence zur Verteilung der Lizenzen.
- Festlegung der Richtlinie.
Import der SmartEvent-Datenbank
- Aktivieren Sie das SmartEvent-Blade.
- Verbinden Sie sich über WinSCP mit der SMS und übertragen Sie die zuvor exportierten Dateien im Binärmodus -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!
Aktualisierung des Check Point GW Clusters (Active\/Backup)
Vor Arbeitsbeginn
- Sichern Sie die GAIA-Konfiguration von jeder Knoten im Cluster in eine Datei, verwenden Sie dafür den Befehl: clish -c "show configuration" > .\/\.txt
- Exportieren Sie die Dateien mit WinSCP.
- Verbinden Sie sich mit der WebUI beider Knoten und wechseln Sie zur Registerkarte CPUSE → Alle Pakete anzeigen.
- Suchen Sie das Update-Paket für die Version R80.20 Neuinstallation, klicken Sie auf Herunterladen.
- Überprüfen Sie, ob das CCP-Protokoll im Modus Broadcast, funktioniert, dazu geben wir den Befehl ein: cphaprob -a if
Wenn der Modus Multicast, ausgewählt ist, ändern Sie ihn mit dem Befehl: cphaconf set_ccp broadcast (der Befehl wird auf jedem Knoten ausgeführt). - Stellen Sie die Downtime für die betroffenen Knoten in Ihrem Überwachungssystem ein.
- Überprüfen Sie, ob auf der Virtualisierungsebene die Parameter MAC Address Change und Forged Transmits für das Sync-Netzwerk aktiviert sind.
Aktualisierung
- Verbinden Sie sich per SSH mit dem aktiven Knoten und führen Sie den Befehl zur Überwachung des Clusterstatus aus: watch -n 2 cphaprob stat
- Kehren Sie zur WebUI des Standby-Knotens zurück und wechseln Sie zur Registerkarte CPUSE und starten Sie für das ausgewählte Paket R80.20 Neuinstallation die Verifier.
- Analysieren Sie den Verifier-Bericht. Wenn die Installation erlaubt ist, fahren Sie fort.
- Wählen Sie das Paket R80.20 Neuinstallation und starten Sie die Aktualisierung. Während des Upgrades wird das System neu gestartet. Die GAIA-Einstellungen werden gespeichert. Zum Zeitpunkt des Neustarts überwachen wir den Zustand des Clusters. Nach dem Booten sollte der Status des aktualisierten Knotens auf READY umschalten. In einigen Fällen hatten wir den Moment, als der noch nicht aktualisierte Knoten in den Status Active Attention wechselte und aufhörte, den Status des aktualisierten Knotens anzuzeigen. Keine Panik – das ist auch eine zulässige Variante.
- 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:
Ein interner Fehler ist aufgetreten. (Code: 0x8003001D, Konnte nicht auf die Datei für Schreibvorgänge zugreifen),
folgen 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, wenn die Installation auf einem Cluster-Mitglied fehlschlägt, nicht auf diesem Cluster installieren.
- Wir installieren die Richtlinie. Das System gibt einen Fehler für den aktiven Knoten aus, der noch nicht aktualisiert wurde.
- Wir verbinden uns per ssh mit dem aktualisierten Knoten und führen den Befehl zur Überwachung des Cluster-Zustands aus: watch -n 2 cphaprob stat
- Wir verbinden uns mit der WebUI des aktiven Knotens und gehen zum Tab CPUSE → Alle Pakete anzeigen.Suchen Sie das Update-Paket für die Version R80.20 Neuinstallation, klicken wir auf Herunterladen.
- Stellen Sie die Downtime für die betroffenen Knoten in Ihrem Überwachungssystem ein.
- Wir kehren zur WebUI des aktiven Knotens zum Tab CPUSE und starten Sie für das ausgewählte Paket R80.20 Neuinstallation die Verifier.
- Analysieren Sie den Verifier-Bericht. Wenn die Installation erlaubt ist, fahren Sie fort.
- Wählen Sie das Paket R80.20 Neuinstallation und starten Sie die Upgrade. Während des Upgrades wird das System neu gestartet. Die GAIA-Einstellungen werden gespeichert. Zum Zeitpunkt des Neustarts überwachen wir den Zustand des Clusters am bereits aktualisierten Knoten. Nach dem Neustart ändert sich der Zustand des Clusters am aktualisierten Knoten von READY auf ACTIVE.
- Wenn der Upgrade-Prozess abgeschlossen ist, starten wir SmartDashboard und installieren die Richtlinie.
Checkliste nach dem Update
- Ereignisprotokolle in SmartLog, Zustand der VPN-Tunnel.
- GAIA-Einstellungen.
- Wiederherstellung des Clusters nach einem Test-Failover.
- Lizenzen und Verträge. Falls die Lizenzen falsch angezeigt werden oder auf SMS nicht angezeigt werden, führen wir den Befehl aus. vsec_central_licence zur Verteilung der Lizenzen.
- CoreXL.
- SecureXL.
- Hotfix und CPinfo auf zwei Knoten.
Fazit
Im Grunde sind wir an diesem Punkt fertig – Sie haben das Upgrade abgeschlossen.
Der gesamte Prozess dauerte bei uns im Durchschnitt zwischen 6 und 12 Stunden, je nach Größe der exportierten Datenbanken. Wir arbeiteten zwei Nächte: eine für das Upgrade von SMS, die andere für das Cluster.
Es gab keine Verkehrsunterbrechungen, obwohl wir alle genannten Fehler an uns selbst getestet haben.
Natürlich können während des Upgrades auch völlig neue Schwierigkeiten auftreten, aber das ist Check Point, und wie wir alle wissen, gibt es immer einen Hotfix!
Ich wünsche Ihnen erfolgreiche Schwarz-Rosa Nächte und Upgrades!
Quelle: habr.com
