À l'automne 2019, Check Point a cessé de supporter les versions R77.XX, et il était temps de mettre à jour. On a déjà beaucoup parlé des différences entre les versions, des avantages et des inconvénients de la transition vers R80. Parlons plutôt de la manière de mettre à jour les appliances virtuelles Check Point (CloudGuard pour VMware ESXi, Hyper-V, KVM Gateway NGTP) et des problèmes qui peuvent survenir.
Donc, nous avions 2 ingénieurs CCSE, plus d'une dizaine de clusters virtuels Check Point R77.30, plusieurs clouds, quelques correctifs et toute une mer de bogues, de dysfonctionnements et autres, de toutes tailles et de toutes couleurs, et des délais très serrés. C'est parti !
Contenu :
Voici à quoi ressemble une infrastructure cloud typique d'un client avec un Check Point virtuel
Préparation
Tout d'abord, il faut vérifier la suffisance des ressources pour la mise à jour. Les exigences minimales recommandées pour R80.20 sont actuellement les suivantes :
Appareil
CPU
RAM
HDD
Passerelle de sécurité
2 cœurs
4 Go
À partir de 15 Go
SMS
2 cœurs
6 Go
—
Les recommandations sont décrites dans le document .
Mais soyons réalistes. Si, dans la configuration minimale, c’est suffisant, comme le montre la pratique, nous avons généralement l'inspection https activée, SmartEvent fonctionne sur SMS, etc., ce qui nécessite évidemment des ressources complètement différentes. Mais en général, pas beaucoup plus que pour R77.30.
Mais il y a des nuances. Et elles concernent principalement la taille de la mémoire physique. De nombreuses opérations durant le processus de mise à jour nécessiteront de l'espace sur le disque dur.
Pour le serveur de gestion, la taille de l'espace libre sur le disque dépendra fortement du volume des journaux actuels (si nous souhaitons les conserver) et du nombre de révisions de base de données enregistrées, bien qu'elles ne soient plus nécessaires en grande quantité. Évidemment, pour les nœuds du cluster (sauf si vous stockez également les journaux localement), cela n’a pas d'importance. Voici comment vérifier la disponibilité de l'espace requis :
- Connectez-vous au Smart Management Server par ssh, entrez en mode expert et tapez la commande :
[Expert@cp-sms:0]# df -h
- En sortie, nous verrons une configuration approximative :
Système de fichiers Taille Utilisé Disponible Utilisé% Monté sur
/dev/mapper/vg_splat-lv_current 30G 7.4G 21G 27% /
/dev/sda1 289M 24M 251M 9% /boot
Le partitionnement qui nous intéresse actuellement
/dev/mapper/vg_splat-lv_log 243G 177G 53G 78% /var/log - est la section /var/log
Prenez en compte qu'en fonction de la politique de conservation et de suppression des anciens fichiers journaux, ainsi que de la taille de la base de données exportée, il peut être nécessaire de disposer de plus d'espace. Si, lors de la création de l'archive, l'espace libre devient inférieur à celui stipulé dans la politique de conservation des journaux, le système commencera à supprimer les anciens journaux et NE les inclura PAS dans l'archive.
De plus, pour le processus de mise à jour, le système aura besoin d'au moins 13 Go d'espace non alloué sur le disque dur. Vous pouvez vérifier sa disponibilité avec la commande :
[Expert@cp-sms:0]# pvs
Nous obtiendrons environ ce genre de sortie :
PV VG Fmt Attr PSize PFree
/dev/sda3 vg_splat lvm2 a- 141.69G 43.69G
Dans ce cas, nous avons 43 Go. Les ressources sont suffisantes. Nous pouvons commencer la mise à jour.
Mise à jour du serveur de gestion Check Point SMS
Avant de commencer les travaux, il faut faire ce qui suit :
- Installez le paquet Migration Tools sur le serveur de gestion. Pour cela, il est nécessaire de télécharger l'image depuis le portail..
- Téléchargez l'archive sur le serveur de gestion via WinSCP dans le dossier. /var/log/UpgradeR77.30_R80.20 (si nécessaire, créez d'abord le dossier).
- Connectez-vous au serveur de gestion via SSH et accédez au dossier contenant l'archive :cd /var/log/UpgradeR77.30_R80.20/
- Décompressez le fichier :tar -zxvf ./.tgz
- Lancez l'utilitaire pre_upgrade_verifier avec la commande : ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
- Après l'exécution de la commande, un rapport sur les paramètres incompatibles sera généré. Il est accessible à l'adresse : /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Il est plus pratique de l'exporter via SCP et de le visualiser dans un navigateur.
Pour corriger tous les paramètres incompatibles, utilisez. - Ensuite, relancez l'utilitaire pre_upgrade_verifier pour vous assurer que toutes les causes d'incompatibilité ont été corrigées.
- Ensuite, collectez des informations sur les interfaces réseaux, la table de routage et exportez la configuration 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 - Exportez le fichier obtenu via SCP.
- Faites un snapshot au niveau de la virtualisation.
- Augmentez le timeout de session SSH à 8 heures. Ça dépend des circonstances : selon la taille de la base de données exportée, cela peut prendre de quelques minutes à plusieurs heures. Pour cela :
[Expert@HostName]# clish -c "show inactivity-timeout" vérifiez le timeout actuel de clish,[Expert@HostName]# clish -c "set inactivity-timeout 720" indiquez le nouveau timeout de clish (en minutes),
[Expert@HostName]# echo $TMOUT vérifiez le timeout actuel du mode expert,
[Expert@HostName]# export TMOUT=3600 indiquez le nouveau timeout du mode expert (en secondes), si vous définissez la valeur à 0, le timeout sera désactivé.
- Nous chargeons et montons l'image d'installation SMS.iso sur la machine virtuelle.
Avant de passer à l'étape suivante, VÉRIFIEZ ENCORE UNE FOIS que vous disposez de suffisamment d'espace non alloué sur le disque dur (rappelez-vous qu'il faut 13 Go).
- Avant de commencer l'exportation de la configuration, changez le fichier log avec la commande : fw logswitch
Exportation de la configuration et des logs
- Nous lançons l'utilitaire migrate_export pour exporter la configuration. Pour cela, accédez au dossier précédemment créé : cd /var/log/UpgradeR77.30_R80.20/ et utilisez la commande : ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
ou
accédez au dossier : cd $FWDIR/bin/upgrade_tools/ et
lancez la commande depuis là : ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz - Récupérez le checksum de l'archive : md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Notez la valeur obtenue.
- Connectez-vous à SMS via SCP et exportez l'archive de configuration vers votre station de travail. Assurez-vous d'utiliser le transfert de fichiers au format binaire.
Exportation de la base SmartEvent
Ici, nous aurons besoin d'un SMS déjà installé en version R80. N'importe quelle version de test conviendra.
- Nous avons besoin du script de SMS, situé ici :$RTDIR/bin/eva_db_backup.csh
- Téléchargez le script via SCP eva_db_backup.csh dans le dossier : /var/log/UpgradeR77.30_R80.20/
- Connectez-vous à SMS par SSH. Copiez le fichier dans le dossier : cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$RTDIR/bin/eva_db_backup.csh - Changez l'encodage : dos2unix $RTDIR/bin/eva_db_backup.csh
- Ajoutez le propriétaire : chown -v admin:root $RTDIR/bin/eva_db_backup.csh
- Ajoutez les autorisations : chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
- Lancez l'exportation de la base SmartEvent : $RTDIR/bin/eva_db_backup.csh
- Exportez les fichiers obtenus via SCP : $RTDIR/bin/-db-backup.backup et $RTDIR/bin/eventiaUpgrade.tar vers votre station de travail.
Mise à jour
- Passons à WebUI GAIA SMS → CPUSE → Afficher tous les packages.
- Si CPUSE renvoie une erreur de connexion au cloud Check Point, vérifiez les paramètres de DGW, DNS et proxy.
- Si tout est correct mais que l'erreur persiste, mettez à jour CPUSE manuellement, en vous référant à.
- Téléchargez l'image et passez par Verifier. En cas de besoin, corrigez les incohérences.
Vous devriez obtenir le message suivant :
- Sélectionnez R80.20 Fresh Install and Upgrade for Security Management.
- Lors de l'installation de la mise à jour, choisissez Clean Install. Après l'installation, le système redémarrera.
- Passez par le First Time Wizard.
- Après avoir obtenu l'accès, vérifiez les comptes.
- Connectez-vous à SMS par SSH et changez le shell de notre utilisateur en /bin/bash :
set user shell /bin/bash
save config (si nous voulons garder bin/bash comme shell par défaut même après le redémarrage).
- Ensuite, connectez-vous à SMS via SCP et transférez l'archive de configuration en mode binaire SMS_w_logs_export_r77_r80.tgz dans le dossier /var/log/UpgradeR77.30_R80.20/
- Récupérez le checksum de l'archive : md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz et comparons avec la valeur précédente. Les checksums doivent correspondre.
- Augmentons le timeout des sessions SSH à 8 heures. Pour cela :
[Expert@HostName]# clish -c "show inactivity-timeout" vérifiez le timeout actuel de clish,
[Expert@HostName]# clish -c "set inactivity-timeout 720" indiquez le nouveau timeout de clish (en minutes),
[Expert@HostName]# echo $TMOUT vérifiez le timeout actuel du mode expert,
[Expert@HostName]# export TMOUT=3600 nous indiquons un nouveau timeout en mode expert (en secondes). Si la valeur 0 est définie, le timeout sera désactivé.
- Pour importer les paramètres, lançons l'utilitaire migrate import. Pour cela, accédons au dossier : cd $FWDIR/bin/upgrade_tools/et lançons l'import : ./migrate imp
ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Profitez de la vie pendant quelques heures. NE DÉCONNECTEZ PAS LA SESSION SSH pendant la procédure. À la fin, le processus migrate indiquera soit un message de réussite, soit une erreur.
Liste de vérification après la mise à jour
- Disponibilité des ressources.
- SIC avec le GW.
- Licences. Si les licences s'affichent incorrectement ou ne s'affichent pas sur le SMS, lançons la commande vsec_central_licence pour répartir les licences.
- Installation de la politique.
Import de la base SmartEvent
- Activez le blade SmartEvent.
- Connectez-vous via WinSCP au SMS et en mode binaire, transférez les fichiers exportés précédemment -db-backup.backup et eventiaUpgrade.tar dans le dossier /var/log/UpgradeR77.30_R80.20/
- Lançons le script avec la commande : $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
- Vérifions le statut : watch -n 10 eventiaUpgrade.sh
- Vérifiez les logs dans SmartEvent. SOMMEIL !
Mise à jour du cluster Check Point GW (Actif/Sauvegarde)
Avant de commencer les travaux
- Sauvegardez la configuration GAIA de chaque nœud du cluster dans un fichier, pour cela, utilisez la commande : clish -c "show configuration" > ./.txt
- Exportez les fichiers à l'aide de WinSCP.
- Connectez-vous à l'interface Web des deux nœuds et allez à l'onglet CPUSE → Afficher tous les packages.
- Trouvez le package de mise à jour pour la version R80.20 Fresh Install, cliquez sur Télécharger.
- Vérifiez que le protocole CCP fonctionne en mode Broadcast, pour cela, saisissez la commande : cphaprob -a if
Si le mode est sélectionné Multicast, changez-le avec la commande : cphaconf set_ccp broadcast (la commande est exécutée sur chaque nœud). - Fixez le Downtime pour les nœuds impliqués dans votre système de surveillance.
- Vérifiez que les paramètres au niveau de la virtualisation sont activés Changement d'adresse MAC et Transmissions forgées pour le réseau de synchronisation.
Mise à jour
- Connectez-vous par ssh au nœud actif et exécutez la commande pour surveiller l'état du cluster : watch -n 2 cphaprob stat
- Revenez dans l'interface Web du nœud Standby à l'onglet CPUSE et pour le package sélectionné R80.20 Fresh Install lancez Verifier.
- Analysez le rapport Verifier. Si l'installation est autorisée, passez à l'étape suivante.
- Sélectionnez le package R80.20 Fresh Install et lancez Mise à jourAu cours de la mise à niveau, le système va redémarrer. Les paramètres GAIA sont conservés. Pendant le redémarrage, nous surveillons l'état du cluster. Après le démarrage, le statut du nœud mis à jour doit changer en READY. Dans certains cas, nous avons rencontré un moment où le nœud qui n'était pas encore mis à jour passait au statut Active Attention et cessait d'afficher le statut du nœud mis à jour. Ne vous inquiétez pas – cette situation est également acceptable.
- Une fois la mise à jour terminée, ouvrons SmartDashboard.
- Nous ouvrons l'objet de cluster et changeons la version du cluster de R77.30 à R80.20. Nous cliquons sur Ok. Si une erreur apparaît lors de la sauvegarde des modifications :
An internal error has occurred. (Code: 0x8003001D, Could not access file for write operation),
suivez. Après cela, nous sauvegardons les modifications et cliquons sur Install Policy. - Dans les paramètres, nous décochons l'option For gateway clusters, if installation on a cluster member fails, do not install on that cluster.
- Nous installons la politique. Le système générera une erreur pour le nœud actif qui n'est pas encore mis à jour.
- Nous nous connectons au nœud mis à jour par ssh et exécutons la commande pour surveiller l'état du cluster : watch -n 2 cphaprob stat
- Nous nous connectons à l'interface Web du nœud actif et allons à l'onglet CPUSE → Afficher tous les packages.Trouvez le package de mise à jour pour la version R80.20 Fresh Install, cliquons sur Télécharger.
- Fixez le Downtime pour les nœuds impliqués dans votre système de surveillance.
- Nous revenons à l'interface Web du nœud actif à l'onglet CPUSE et pour le package sélectionné R80.20 Fresh Install lancez Verifier.
- Analysez le rapport Verifier. Si l'installation est autorisée, passez à l'étape suivante.
- Sélectionnez le package R80.20 Fresh Install et lancez Upgrade. Au cours de la mise à niveau, le système va redémarrer. Les paramètres GAIA sont conservés. Pendant le redémarrage, nous surveillons l'état du cluster sur le nœud déjà mis à jour. Après le redémarrage, l'état du cluster sur le nœud mis à jour changera de READY à ACTIVE.
- Lorsque le processus de mise à niveau sera terminé, nous lançons SmartDashboard et installons la politique.
Liste de vérification après la mise à jour
- Les journaux d'événements dans SmartLog, l'état des tunnels VPN.
- Les paramètres GAIA.
- Récupération du cluster après un test de failover.
- Licences et contrats. Si les licences s'affichent incorrectement ou ne s'affichent pas sur SMS, nous exécutons la commande vsec_central_licence pour la répartition des licences.
- CoreXL.
- SecureXL.
- Hotfix et CPinfo sur les deux nœuds.
Conclusion
En gros, à ce stade, tout est fait – vous avez mis à jour.
Nous avons passé en moyenne de 6 à 12 heures sur tout le processus, selon la taille des bases exportées. Le travail s'est effectué sur deux nuits : une pour mettre à jour SMS, l'autre pour le cluster.
Il n'y a pas eu d'interruption du trafic, même si toutes les erreurs mentionnées ci-dessus, nous les avons vérifiées par nous-mêmes.
Bien sûr, de nouvelles difficultés peuvent également survenir pendant le processus de mise à jour, mais c'est Check Point, et comme nous le savons tous, il y a toujours un hotfix !
Nous vous souhaitons de belles nuits et mises à jour colorées !
Source : habr.com
