No outono de 2019, a Check Point encerrou o suporte para as versões R77.XX, e era necessário atualizar. Já foi falado muito sobre a diferença entre as versões, os prós e contras da transição para o R80. Vamos falar melhor sobre como atualizar os appliances virtuais da Check Point (CloudGuard para VMware ESXi, Hyper-V, KVM Gateway NGTP) e o que pode dar errado.
Portanto, tínhamos 2 engenheiros CCSE, mais de uma dezena de clusters virtuais Check Point R77.30, algumas nuvens, alguns hotfixes e um mar de diversos bugs, falhas e tudo isso, de todas as cores e tamanhos, além de prazos muito apertados. Vamos lá!
Conteúdo:
Assim é como se parece a infraestrutura em nuvem típica de um cliente com o Check Point virtual
Preparação
Primeiro, precisamos verificar a adequação dos recursos para a atualização. As exigências mínimas recomendadas para o R80.20 são as seguintes:
Device
CPU
RAM
HDD
Security Gateway
2 core
4 Gb
A partir de 15 GB
SMS
2 core
6 Gb
—
As recomendações estão descritas no documento .
Mas vamos ser realistas. Se na configuração mínima isso é suficiente, a prática mostra que geralmente temos a inspeção https ativada, o SmartEvent funcionando no SMS, etc., o que, claro, exige recursos muito diferentes. Mas, de modo geral, não são muito maiores do que para o R77.30.
Mas há nuances. E elas dizem respeito, em primeiro lugar, ao tamanho da memória física. Muitas operações diretamente no processo de atualização exigirão espaço no disco rígido.
Para o servidor de gerenciamento, o tamanho do espaço livre no disco dependerá muito do volume dos logs atuais (se quisermos salvá-los) e da quantidade de Revisões do Banco de Dados salvas, embora precisemos delas em grande quantidade. Naturalmente, para os nós do cluster (a menos que você armazene logs localmente também), isso tudo não faz diferença. Veja como verificar a disponibilidade do espaço necessário:
- Conecte-se ao Smart Management Server via ssh, entre no modo expert e digite o comando:
[Expert@cp-sms:0]# df -h
- Na saída, veremos uma configuração mais ou menos assim:
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_splat-lv_current 30G 7.4G 21G 27% /
/dev/sda1 289M 24M 251M 9% /boot
Atualmente, estamos interessados na partição
/dev/mapper/vg_splat-lv_log 243G 177G 53G 78% /var/log - No momento, estamos interessados na seção /var/log
Considere que, dependendo da política de armazenamento e remoção de arquivos de log antigos, assim como do tamanho do banco de dados exportado, pode ser necessário mais espaço. Se ao criar o arquivo o espaço livre ficar abaixo do estipulado na política de armazenamento de logs, o sistema começará a apagar logs antigos e não os incluirá no arquivo.
Além disso, para o próprio processo de atualização, o sistema precisará de pelo menos 13 GB de espaço não alocado no disco rígido. Você pode verificar se há espaço disponível com o comando:
[Expert@cp-sms:0]# pvs
Veremos uma saída semelhante a esta:
PV VG Fmt Attr PSize PFree
/dev/sda3 vg_splat lvm2 a- 141.69G 43.69G
Neste caso, temos 43 GB. Os recursos são suficientes. Podemos iniciar a atualização.
Atualizando o servidor de gerenciamento Check Point SMS
Antes de iniciar o trabalho, é necessário fazer o seguinte:
- Instale o pacote Migration Tools no servidor de gerenciamento. Para isso, é necessário baixar a imagem do portal.
- Carregue o arquivo no servidor de gerenciamento através do WinSCP na pasta /var/log/UpgradeR77.30_R80.20 (se necessário, crie a pasta primeiro).
- Conecte-se ao servidor de gerenciamento via SSH e vá para a pasta com o arquivo:cd /var/log/UpgradeR77.30_R80.20/
- Descompacte o arquivo:tar -zxvf ./.tgz
- Execute a ferramenta pre_upgrade_verifier com o comando: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
- Após a execução do comando, será gerado um relatório sobre configurações incompatíveis. Ele está disponível no endereço: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). É mais conveniente transferi-lo via SCP e visualizar no navegador.
Para corrigir todas as configurações incompatíveis, use. - Depois, execute novamente a ferramenta pre_upgrade_verifier para garantir que todas as razões de incompatibilidade foram corrigidas.
- Em seguida, coletamos informações sobre as interfaces de rede, tabela de roteamento e exportamos a configuração 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 - Transfira o arquivo gerado via SCP.
- Faça um snapshot no nível de virtualização.
- Aumente o tempo limite da sessão SSH para 8 horas. Aqui depende: dependendo do tamanho do banco de dados exportado, pode levar desde vários minutos até várias horas. Para isso:
[Expert@HostName]# clish -c "show inactivity-timeout" verifique o tempo limite atual do clish,[Expert@HostName]# clish -c "set inactivity-timeout 720" defina o novo tempo limite do clish (em minutos),
[Expert@HostName]# echo $TMOUT verifique o tempo limite atual do modo expert,
[Expert@HostName]# export TMOUT=3600 defina o novo tempo limite do modo expert (em segundos), se definir o valor como 0, o tempo limite será desativado.
- Estamos carregando e montando a imagem de instalação SMS.iso na máquina virtual.
Antes do próximo passo, VERIFIQUE SE TEM espaço não alocado suficiente no disco rígido (lembro que são necessários 13 GB).
- Antes de iniciar a exportação da configuração, alteramos o arquivo de log com o comando: fw logswitch
Exportação da configuração e logs
- Iniciamos a utilidade migrate_export para exportar a configuração. Para isso, acesse a pasta criada anteriormente: cd /var/log/UpgradeR77.30_R80.20/ e usamos o comando: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
ou
acessamos a pasta: cd $FWDIR/bin/upgrade_tools/ e
executamos de lá o comando: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz - Calculamos o checksum do arquivo: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Salve o valor obtido em um bloco de notas.
- Conecte-se ao SMS via SCP e faça o download do arquivo de configuração para a estação de trabalho. Certifique-se de usar a transferência de arquivos no formato Binário.
Exportar a base SmartEvent
Aqui precisamos de um SMS pré-instalado na versão R80. Qualquer versão de teste funcionará.
- Precisamos do script do SMS, localizado aqui:$RTDIR/bin/eva_db_backup.csh
- Carregamos o script via SCP eva_db_backup.csh na pasta: /var/log/UpgradeR77.30_R80.20/
- Conecte-se ao SMS via SSH. Copie o arquivo para a pasta: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$RTDIR/bin/eva_db_backup.csh - Alteramos a codificação: dos2unix $RTDIR/bin/eva_db_backup.csh
- Adicionamos o proprietário: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
- Adicionamos permissões: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
- Iniciamos a exportação da base SmartEvent: $RTDIR/bin/eva_db_backup.csh
- Exportamos os arquivos obtidos via SCP: $RTDIR/bin/-db-backup.backup e $RTDIR/bin/eventiaUpgrade.tar para a estação de trabalho.
Atualizar
- Vamos para WebUI GAIA SMS → CPUSE → Mostrar todos os pacotes.
- No caso de o CPUSE apresentar um erro ao conectar ao cloud Check Point, verifique DGW, DNS e as configurações do Proxy.
- Se tudo estiver correto mas o erro persistir, será necessário atualizar o CPUSE manualmente, conforme.
- Baixe a imagem e prossiga Verificador. Em caso de necessidade, resolva as divergências.
Como resultado, devemos ver a seguinte mensagem:
- Escolhendo R80.20 Fresh Install and Upgrade for Security Management.
- Ao instalar a atualização, escolha Clean Install. Após a instalação, o sistema será reiniciado.
- Acesse o Primeiro Assistente.
- Após obter acesso, verifique as contas de usuário.
- Conecte-se ao SMS via SSH e altere o shell do nosso usuário para /bin/bash/:
set user shell /bin/bash/
save config (se quisermos manter o bin/bash/ como shell padrão após a reinicialização).
- Em seguida, conecte-se ao SMS via SCP e, no modo Binário, envie o arquivo de configuração SMS_w_logs_export_r77_r80.tgz para a pasta /var/log/UpgradeR77.30_R80.20/
- Calculamos o checksum do arquivo: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz e comparamos com o valor anterior. Os checksums devem coincidir.
- Aumentamos o timeout da sessão SSH para 8 horas. Para isso:
[Expert@HostName]# clish -c "show inactivity-timeout" verifique o tempo limite atual do clish,
[Expert@HostName]# clish -c "set inactivity-timeout 720" defina o novo tempo limite do clish (em minutos),
[Expert@HostName]# echo $TMOUT verifique o tempo limite atual do modo expert,
[Expert@HostName]# export TMOUT=3600 indicamos um novo timeout em modo expert (em segundos). Se o valor for 0, o timeout será desativado.
- Para importar as configurações, iniciamos a ferramenta migrate import. Para isso, navegamos até a pasta: cd $FWDIR/bin/upgrade_tools/e iniciamos a importação: ./migrate imp
ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Aproveite a vida pelas próximas horas. NÃO DESLIGUE A SESSÃO SSH durante o procedimento. No final, o processo migrate exibirá uma mensagem de sucesso ou um erro.
Lista de verificações após a atualização
- Disponibilidade de recursos.
- SIC com GW.
- Licenças. Se as licenças forem exibidas incorretamente ou não aparecerem no SMS, execute o comando vsec_central_licence para distribuir as licenças.
- Instalação da política.
Importar banco de dados do SmartEvent
- Ative a blade do SmartEvent.
- Conecte-se via WinSCP ao SMS e em modo binário transfira os arquivos exportados anteriormente -db-backup.backup e eventiaUpgrade.tar para a pasta /var/log/UpgradeR77.30_R80.20/
- Execute o script com o comando: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
- Verifique o status: watch -n 10 eventiaUpgrade.sh
- Verifique os logs no SmartEvent. SONE!
Atualizando o cluster Check Point GW (Ativo/Backup)
Antes de iniciar a operação
- Salve a configuração GAIA de cada nó do cluster em um arquivo, utilizando o comando: clish -c "show configuration" > ./.txt
- Exporte os arquivos usando WinSCP.
- Conecte-se ao WebUI de ambos os nós e navegue até a aba CPUSE → Mostrar todos os pacotes.
- Encontre o pacote de atualização para a versão R80.20 Fresh Install, clicamos em Baixar.
- Verifique se o protocolo CCP está funcionando em modo Broadcast, para isso, insira o comando: cphaprob -a if
Se o modo escolhido for Multicast, mude-o com o comando: cphaconf set_ccp broadcast (o comando deve ser executado em cada nó). - Defina o Downtime para os nós envolvidos no seu sistema de monitoramento.
- Verifique se os parâmetros estão ativados no nível de virtualização Mudança de Endereço MAC e Transmissões Forjadas para a rede de sync.
Atualizar
- Conecte-se via ssh ao nó ativo e execute o comando para monitorar o estado do cluster: watch -n 2 cphaprob stat
- Volte ao WebUI do nó de espera na aba CPUSE e para o pacote selecionado R80.20 Fresh Install inicie Verificador.
- Analise o relatório Verifier. Se a instalação for permitida, prossiga.
- Selecione o pacote R80.20 Fresh Install e inicie Atualizar. Durante o Upgrade, o sistema será reiniciado. As configurações do GAIA serão mantidas. No momento da reinicialização, monitoramos o estado do cluster. Após a inicialização, o status do nó atualizado deve mudar para READY. Em alguns casos, tivemos um momento em que um nó ainda não atualizado passava para o status de Atenção Ativa e deixava de exibir o status do nó atualizado. Não se preocupe, essa situação também é aceitável.
- Após a conclusão da atualização, abrimos SmartDashboard.
- Abrimos o objeto do cluster e mudamos a versão do cluster de R77.30 para R80.20. Clicamos em OK. Se ao salvar as alterações aparecer um erro:
Ocorreu um erro interno. (Código: 0x8003001D, Não foi possível acessar o arquivo para operação de gravação),
siga. Após isso, salvamos as alterações e clicamos em Instalar Política. - Nas configurações, desmarcamos a opção Para clusters de gateway, se a instalação em um membro do cluster falhar, não instale naquele cluster.
- Instalamos a política. O sistema gerará um erro para o nó ativo que ainda não foi atualizado.
- Conectamos ao nó atualizado via ssh e executamos o comando para monitorar o estado do cluster: watch -n 2 cphaprob stat
- Conectamos ao WebUI do nó Ativo e vamos para a aba CPUSE → Mostrar todos os pacotes.Encontre o pacote de atualização para a versão R80.20 Fresh Install, clicamos Baixar.
- Defina o Downtime para os nós envolvidos no seu sistema de monitoramento.
- Retornamos ao WebUI do nó Ativo na aba CPUSE e para o pacote selecionado R80.20 Fresh Install inicie Verificador.
- Analise o relatório Verifier. Se a instalação for permitida, prossiga.
- Selecione o pacote R80.20 Fresh Install e inicie Upgrade. Durante o Upgrade, o sistema será reiniciado. As configurações do GAIA permanecerão as mesmas. No momento da reinicialização, monitoramos o estado do cluster no nó já atualizado. Após a reinicialização, o estado do cluster no nó atualizado mudará de READY para ACTIVE.
- Quando o processo de Upgrade for concluído, iniciamos o SmartDashboard e definimos a política.
Lista de verificações após a atualização
- Registros de eventos no SmartLog, estado dos túneis VPN.
- Configurações do GAIA.
- Recuperação do cluster após uma falha de teste.
- Licenças e contratos. Caso as licenças sejam exibidas de forma incorreta ou não apareçam no SMS, executamos o comando vsec_central_licence para redistribuição das licenças.
- CoreXL.
- SecureXL.
- Hotfix e CPinfo em dois nós.
Conclusão
Basicamente, neste ponto, tudo está feito – você se atualizou.
Todo o processo levou em média de 6 a 12 horas, dependendo do tamanho das bases exportadas. Realizamos o trabalho em duas noites: uma para atualizar o SMS, e outra para o cluster.
Não houve interrupção no tráfego, apesar de que todos os erros mencionados foram verificados por nós.
Claro, às vezes podem surgir totalmente novas dificuldades durante o processo de atualização, mas isso é Check Point, e, como todos sabemos, sempre há um hotfix!
Desejamos boas noites e atualizações preto-rosa!
Fonte: habr.com
