En otoño de 2019, Check Point dejó de dar soporte a las versiones R77.XX, y era necesario actualizar. Ya se ha hablado mucho sobre las diferencias entre las versiones, las ventajas y desventajas de la transición a R80. Hablemos mejor de cómo actualizar, de hecho, los appliances virtuales de Check Point (CloudGuard para VMware ESXi, Hyper-V, KVM Gateway NGTP) y qué puede salir mal.
Así que teníamos 2 ingenieros CCSE, más de una docena de clústeres virtuales Check Point R77.30, varias nubes, algunos hotfixes y un mar de diversos bugs, glitches y todo eso, de todos los colores y tamaños, además de tiempos muy ajustados. ¡Vamos!
Contenido:
Así luce una infraestructura cloud típica del cliente con Check Point virtual
Preparación
Lo primero que hay que hacer es verificar la suficiencia de los recursos para la actualización. Los requisitos mínimos recomendados para R80.20 son los siguientes:
Dispositivo
CPU
RAM
HDD
Gateway de Seguridad
2 núcleos
4 Gb
Desde 15 GB
SMS
2 núcleos
6 Gb
—
Las recomendaciones están descritas en el documento .
Pero seamos realistas. Si en la configuración más mínima esto es suficiente, como muestra la práctica, normalmente tenemos habilitada la inspección https, SmartEvent funciona en SMS, etc., lo que, por supuesto, requiere capacidades completamente diferentes. Pero en general, no mucho más que para R77.30.
Pero hay matices. Y se refieren, sobre todo, a los tamaños de la memoria física. Muchas operaciones directamente durante el proceso de actualización requerirán espacio en el disco duro.
Para el servidor de gestión, el tamaño del espacio libre en el disco dependerá mucho del volumen de los registros actuales (si deseamos conservarlos) y de la cantidad de revisiones de base de datos guardadas, aunque estas ya no nos serán necesarias en gran cantidad. Por supuesto, para los nodos del clúster (a menos que almacenes los registros localmente) esto no tiene sentido. Así es como se puede comprobar el espacio necesario:
- Conectamos al Smart Management Server por ssh, entramos en modo experto e introducimos el comando:
[Expert@cp-sms:0]# df -h
- En la salida veremos una configuración similar a esta:
Sistema de archivos Tamaño Utilizado Disponible Uso% Montado en
/dev/mapper/vg_splat-lv_current 30G 7.4G 21G 27% /
/dev/sda1 289M 24M 251M 9% /boot
Lo que nos interesa en este momento es la partición
/dev/mapper/vg_splat-lv_log 243G 177G 53G 78% /var/log - Actualmente estamos interesados en la sección /var/log
Tenga en cuenta que, dependiendo de la política de almacenamiento y eliminación de registros antiguos, así como del tamaño de la base de datos exportada, puede ser necesario más espacio. Si al crear el archivo queda menos espacio libre del que se indica en la política de almacenamiento de registros, el sistema comenzará a eliminar registros antiguos y NO los incluirá en el archivo.
Además, para el propio proceso de actualización, el sistema necesitará un mínimo de 13 GB de espacio no asignado en el disco duro. Puede comprobar su disponibilidad con el siguiente comando:
[Expert@cp-sms:0]# pvs
Veremos aproximadamente la siguiente salida:
PV VG Fmt Attr PSize PFree
/dev/sda3 vg_splat lvm2 a- 141.69G 43.69G
En este caso, tenemos 43 GB. Hay suficientes recursos. Se puede proceder a la actualización.
Actualizando el servidor de gestión Check Point SMS
Antes de comenzar, es necesario hacer lo siguiente:
- Instalamos el paquete Migration Tools en el servidor de gestión. Para ello, es necesario descargar la imagen desde el portal.
- Subimos el archivo al servidor de gestión a través de WinSCP en la carpeta /var/log/UpgradeR77.30_R80.20 (si es necesario, crear la carpeta previamente).
- Nos conectamos al servidor de gestión a través de SSH y accedemos a la carpeta con el archivo:cd /var/log/UpgradeR77.30_R80.20/
- Descomprimimos el archivo:tar -zxvf ./.tgz
- Ejecutamos la utilidad pre_upgrade_verifier con el comando: . /pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
- Al ejecutar el comando, se generará un informe sobre configuraciones incompatibles. Está disponible en: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Es más conveniente exportarlo a través de SCP y revisarlo a través del navegador.
Para eliminar todas las configuraciones incompatibles, utilice. - Luego vuelva a ejecutar la utilidad pre_upgrade_verifier para asegurarse de que todas las razones de incompatibilidad se han eliminado.
- A continuación, recopilamos información sobre las interfaces de red, la tabla de enrutamiento y exportamos la configuración de 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 - Exportamos el archivo obtenido a través de SCP.
- Hacemos un snapshot a nivel de virtualización.
- Aumentamos el tiempo de espera de la sesión SSH a 8 horas. Aquí depende de la suerte: según el tamaño de la base de datos exportada, puede durar desde unos minutos hasta varias horas. Para ello:
[Expert@HostName]# clish -c "show inactivity-timeout" verificamos el tiempo de espera actual de clish,[Expert@HostName]# clish -c "set inactivity-timeout 720" estamos configurando el nuevo tiempo de espera de clish (en minutos),
[Expert@HostName]# echo $TMOUT verificamos el tiempo de espera actual del modo experto,
[Expert@HostName]# export TMOUT=3600 estamos configurando el nuevo tiempo de espera del modo experto (en segundos). Si se establece en 0, se deshabilitará el tiempo de espera.
- Cargamos y montamos la imagen de instalación SMS.iso en la máquina virtual.
Antes del siguiente paso, asegúrate OBLIGATORIAMENTE de que tienes suficiente espacio no asignado en el disco duro (recuerda, se necesitan 13 GB).
- Antes de comenzar la exportación de la configuración, cambiamos el archivo de registro con el siguiente comando: fw logswitch
Exportación de la configuración y los registros
- Iniciamos la herramienta migrate_export para exportar la configuración. Para ello, accedemos a la carpeta creada anteriormente: cd /var/log/UpgradeR77.30_R80.20/ y usamos el comando: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
o
accedemos a la carpeta: cd $FWDIR/bin/upgrade_tools/ y
ejecutamos el siguiente comando desde allí: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz - Obtenemos el checksum del archivo: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Guardamos el valor obtenido en un bloc de notas.
- Nos conectamos a SMS a través de SCP y descargamos el archivo de configuración en la estación de trabajo. Asegúrate de usar la transferencia de archivos en formato Binary.
Exportación de la base de datos SmartEvent
Aquí necesitaremos SMS instalado previamente en la versión R80. Cualquier versión de prueba servirá.
- De SMS necesitamos el script ubicado aquí:$RTDIR/bin/eva_db_backup.csh
- Subimos el script a través de SCP eva_db_backup.csh a la carpeta: /var/log/UpgradeR77.30_R80.20/
- Nos conectamos por SSH a SMS. Copiamos el archivo a la carpeta: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$RTDIR/bin/eva_db_backup.csh - Cambiamos la codificación: dos2unix $RTDIR/bin/eva_db_backup.csh
- Añadimos el propietario: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
- Añadimos permisos: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
- Iniciamos la exportación de la base de datos SmartEvent: $RTDIR/bin/eva_db_backup.csh
- Descargamos los archivos obtenidos a través de SCP: $RTDIR/bin/-db-backup.backup y $RTDIR/bin/eventiaUpgrade.tar en la estación de trabajo.
Actualización
- Vamos a WebUI GAIA SMS → CPUSE → Mostrar todos los paquetes.
- En caso de que CPUSE indique un error de conexión con la nube de Check Point, revisamos DGW, DNS y configuraciones de Proxy.
- Si todo está correcto, pero el error persiste, será necesario actualizar CPUSE manualmente, siguiendo.
- Descargamos la imagen y procedemos al Verificador. Si es necesario, resolvemos las discrepancias.
Como resultado, deberíamos ver el siguiente mensaje:
- Seleccionamos R80.20 Instalación limpia y actualización para Gestión de Seguridad.
- Al instalar la actualización, seleccionamos Instalación limpia. Después de la instalación, el sistema se reiniciará.
- Pasamos por el primer Asistente.
- Después de obtener acceso, verificamos las cuentas.
- Nos conectamos a SMS por SSH y cambiamos el shell de nuestro usuario a /bin/bash:
set user shell /bin/bash
save config (en caso de que queramos dejar bin/bash como shell por defecto después del reinicio).
- Luego nos conectamos a SMS a través de SCP y, en modo Binary, transferimos el archivo de configuración SMS_w_logs_export_r77_r80.tgz a la carpeta /var/log/UpgradeR77.30_R80.20/
- Obtenemos el checksum del archivo: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz y lo comparamos con el valor anterior. Los checksums deben coincidir.
- Aumentamos el timeout de la sesión SSH a 8 horas. Para ello:
[Expert@HostName]# clish -c "show inactivity-timeout" verificamos el tiempo de espera actual de clish,
[Expert@HostName]# clish -c "set inactivity-timeout 720" estamos configurando el nuevo tiempo de espera de clish (en minutos),
[Expert@HostName]# echo $TMOUT verificamos el tiempo de espera actual del modo experto,
[Expert@HostName]# export TMOUT=3600 indicamos un nuevo timeout en modo experto (en segundos). Si se establece el valor 0, el timeout se desactivará.
- Para importar la configuración, ejecutamos la utilidad migrate import. Para ello, vamos a la carpeta: cd $FWDIR/bin/upgrade_tools/y ejecutamos la importación: ./migrate imp
ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Disfrutemos de la vida durante un par de horas. NO DESCONECTE LA SESIÓN SSH durante el procedimiento. Al final, el proceso migrate mostrará un mensaje de finalización exitosa de la operación o un error.
Lista de verificación después de la actualización
- Disponibilidad de recursos.
- SIC con GW.
- Licencias. Si las licencias se muestran incorrectamente o no aparecen en SMS, ejecutamos el comando vsec_central_licence para distribuir las licencias.
- Instalación de políticas.
Importar base de datos SmartEvent
- Active el blade SmartEvent.
- Conectamos a SMS a través de WinSCP y en modo binario transferimos los archivos exportados anteriormente -db-backup.backup y eventiaUpgrade.tar a la carpeta /var/log/UpgradeR77.30_R80.20/
- Ejecutamos el script con el comando: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
- Verificamos el estado: watch -n 10 eventiaUpgrade.sh
- Revisamos los logs en SmartEvent. ¡Zzz!
Actualizamos el clúster Check Point GW (Activo/Backup)
Antes de comenzar el trabajo
- Guardamos la configuración de GAIA de cada nodo del clúster en un archivo, para ello utilizamos el comando: clish -c "show configuration" > ./.txt
- Exportamos archivos usando WinSCP.
- Conectamos a la WebUI de ambos nodos y vamos a la pestaña CPUSE → Mostrar todos los paquetes.
- Encontramos el paquete de actualización para la versión R80.20 Fresh Install, hacemos clic en Descargar.
- Verificamos que el protocolo CCP esté funcionando en modo Broadcast, para ello introducimos el comando: cphaprob -a if
Si se selecciona el modo Multicast, cámbialo con el comando: cphaconf set_ccp broadcast (el comando se ejecuta en cada nodo). - Establecemos el Downtime para los nodos involucrados en su sistema de monitoreo.
- Verificamos que en el nivel de virtualización estén habilitadas las opciones Cambio de dirección MAC y Transmisiones falseadas para la red de sincronización.
Actualización
- Conectamos por ssh al nodo Activo y ejecutamos el comando para monitorear el estado del clúster: watch -n 2 cphaprob stat
- Regresamos a la WebUI del nodo de espera en la pestaña CPUSE y para el paquete seleccionado R80.20 Fresh Install ejecutamos Verificador.
- Analizamos el informe del Verificador. Si la instalación está permitida, seguimos adelante.
- Seleccionamos el paquete R80.20 Fresh Install y ejecutamos ActualizaciónDurante el proceso de Upgrade, el sistema será reiniciado. Las configuraciones de GAIA se mantienen. Durante el reinicio, monitoreamos el estado del clúster. Después de iniciar, el estado del nodo actualizado debe cambiar a READY. En algunos casos, hemos tenido momentos en los que un nodo que aún no se había actualizado pasaba al estado de Atención Activa y dejaba de mostrar el estado del nodo actualizado. No se asusten, esta opción también es válida.
- Al finalizar la actualización, abrimos SmartDashboard.
- Abrimos el objeto del clúster y cambiamos la versión del clúster de R77.30 a R80.20. Hacemos clic en Aceptar. Si al guardar los cambios aparece un error:
Ha ocurrido un error interno. (Código: 0x8003001D, No se puede acceder al archivo para la operación de escritura),
sigan. Después de esto, guardamos los cambios y hacemos clic en Instalar Políticas. - En la configuración, desmarcamos la opción Para clústeres de gateways, si la instalación en un miembro del clúster falla, no instalar en ese clúster.
- Instalamos la política. El sistema mostrará un error para el nodo Activo que aún no está actualizado.
- Conectamos al nodo actualizado por ssh y ejecutamos el comando para monitorear el estado del clúster: watch -n 2 cphaprob stat
- Conectamos a la WebUI del nodo Activo y vamos a la pestaña CPUSE → Mostrar todos los paquetes.Encontramos el paquete de actualización para la versión R80.20 Fresh Install, hacemos clic en Descargar.
- Establecemos el Downtime para los nodos involucrados en su sistema de monitoreo.
- Volvemos a la WebUI del nodo Activo en la pestaña CPUSE y para el paquete seleccionado R80.20 Fresh Install ejecutamos Verificador.
- Analizamos el informe del Verificador. Si la instalación está permitida, seguimos adelante.
- Seleccionamos el paquete R80.20 Fresh Install y ejecutamos Upgrade. Durante el proceso de Upgrade, el sistema será reiniciado. Las configuraciones de GAIA se mantienen. Durante el reinicio, monitoreamos el estado del clúster en el nodo ya actualizado. Después del reinicio, el estado del clúster en el nodo actualizado cambiará de READY a ACTIVE.
- Cuando finalice el proceso de Upgrade, iniciamos SmartDashboard y establecemos la política.
Lista de verificación después de la actualización
- Registros de eventos en SmartLog, estado de los túneles VPN.
- Configuraciones de GAIA.
- Recuperación del clúster después de una prueba de Failover.
- Licencias y contratos. En caso de que las licencias se muestren incorrectamente o no se muestren en SMS, ejecutamos el comando vsec_central_licence para la distribución de licencias.
- CoreXL.
- SecureXL.
- Hotfix y CPinfo en dos nodos.
Conclusión
En general, en este punto, eso es todo: se han actualizado.
Nosotros tardamos entre 6 y 12 horas en promedio, dependiendo de los tamaños de las bases exportadas. Trabajamos durante dos noches: una para la actualización de SMS, la segunda para el clúster.
No hubo paradas de tráfico, a pesar de que verificamos todos los errores mencionados anteriormente.
Por supuesto, a veces pueden surgir dificultades totalmente nuevas durante el proceso de actualización, pero esto es Check Point, y como todos sabemos, siempre hay un hotfix.
¡Les deseamos noches y actualizaciones exitosas!
Fuente: habr.com
