Atualização de firmware do Sophos Firewall: preparação e boas práticas

Uma atualização de firmware do Sophos Firewall só deve ser aprovada quando o caminho de upgrade, o backup, o acesso, o estado do sistema, o HA e o plano de recovery estiverem esclarecidos. Executar uma atualização de firmware do Sophos Firewall descreve a instalação no WebAdmin ou através do Sophos Fusion (anteriormente Sophos Central).

⚠️ Antes de cada atualização: Devem estar disponíveis um backup recente, o Secure Storage Master Key associado e um plano de rollback concreto. Para o SFOS 22 ou posterior, deve-se também executar a verificação de upgrade do SFOS 22.

Aprovação em dez pontos

Uma alteração de firmware está pronta quando se pode responder sim aos dez pontos:

1. A versão atual, a versão de destino e o caminho de upgrade suportado estão documentados.
2. As release notes e os known issues foram verificados para a plataforma e configuração utilizadas.
3. A licença e o direito a suporte permitem a instalação.
4. Estão disponíveis um backup recente, a palavra-passe do backup e o Secure Storage Master Key correspondente.
5. O espaço livre, o estado do sistema e, nos modelos XGS Appliance afetados, o firmware do SSD cumprem os requisitos.
6. O estado, as funções e a sincronização HA estão corretos; ambos os nodes cumprem os requisitos.
7. A janela de manutenção, os responsáveis, o prazo para abortar e os critérios de rollback estão definidos.
8. Foi preparado um acesso de gestão local ou alternativo.
9. Foram definidos testes para WAN, VPN, DNS, NAT, WAF, autenticação e aplicações centrais.
10. A monitorização, a comunicação e os registos da alteração estão preparados.

Se faltar um destes pontos, a atualização não deve ser iniciada sob pressão de tempo. Adiar uma janela de manutenção é mais barato do que um reimage ou uma intervenção no local não planeados.

Verificar versão, plataforma e autorização

Um processo operacional definido verifica pelo menos uma vez por mês no Sophos Fusion ou em Backup & Firmware > Firmware se existe uma atualização disponível. As novas release notes e as maintenance releases anunciadas também são acompanhadas ativamente. Cada MR deve entrar no planeamento, porque mesmo uma versão apenas de manutenção pode incluir correções de segurança importantes. A instalação, os testes e o rollback continuam a ser executados de forma controlada durante uma janela de manutenção.

Release notes e caminho de upgrade

Antes da alteração, deve-se comparar nas release notes a versão SFOS atual, a versão de destino e o caminho suportado. Também se devem verificar os problemas conhecidos relativos à plataforma, HA, VPN, routing, autenticação e às funções efetivamente utilizadas.

O Sophos Firewall pode apresentar um aviso para um caminho de migração não suportado. Se a alteração for confirmada mesmo assim, a firewall pode iniciar com Factory Configuration e perder a configuração existente. O rollback automático não protege contra um caminho de upgrade não suportado. Deve ser utilizado apenas um caminho aprovado; para uma mudança de versão incompatível, o método correto é um reimage seguido de restore.

⚠️ Limite da plataforma: O SFOS 21.0 GA e versões posteriores não suportam appliances de hardware XG e SG. Para estes equipamentos, deve ser planeada uma migração para XGS Appliance antes do upgrade.

A verificação de upgrade do SFOS 22 documenta as versões de origem suportadas para um upgrade direto e a interpretação dos blockers do SFOS 22.0 MR2 Build 546. Esta matriz é específica desse build e não constitui um caminho universal para o SFOS 22; para qualquer outro build de destino, devem ser verificadas imediatamente antes da alteração as versões de origem suportadas e os blockers aplicáveis nas release notes atuais.

Devem ser excluídos explicitamente dois blockers do SFOS 22:

• SFOS 22.0 MR1 e posterior: A configuração legacy de Remote Access IPsec ainda existente bloqueia o upgrade. Deve ser resolvida segundo as instruções de migração atuais da Sophos; desativá-la não é suficiente.
• SFOS 22.0 MR2 e posterior: O VLAN tagging legacy configurado através da CLI em interfaces bridge bloqueia o upgrade. Devem ser identificadas as bridges afetadas e essa configuração resolvida primeiro segundo as release notes.

A verificação separada abrange os restantes temas do SFOS 22, incluindo espaço, nomes de interfaces, STAS, firmware SSD e plataforma. Para outras versões de destino, aplicam-se as respetivas release notes atuais.

⚠️ Antes do primeiro upgrade para SFOS 21 ou posterior: Em Certificates > Certificate authorities, procurar os nomes de CA Let’s Encrypt reservados. Uma entrada existente com exatamente o mesmo nome pode interromper a migração devido a NC-146082. Não remover a CA sem verificação; primeiro proteger e verificar o backup, a chave privada, os certificados dependentes e os serviços.

Licença e suporte

A partir do SFOS 19.0 MR1, são permitidas três mudanças gratuitas para versões GA, MR ou EAP sem Enhanced Support ou Enhanced Plus Support. Depois disso, o firmware ainda pode ser descarregado, mas não instalado; Install fica desativado.

Pattern Updates, hotfixes, reimage, Mandatory Firmware Upgrades e Assistant Firmware Upgrades estão isentos desta regra de suporte. Antes da janela de manutenção, deve-se ainda verificar que:

• Administration > Licensing apresenta a licença e o direito a suporte esperados.
• O Sophos Fusion apresenta a firewall e o número de série corretos.
• A versão de destino e o download estão disponíveis.
• O acesso ao suporte, os contactos e o caminho de escalonamento são conhecidos.

Se for necessário acesso externo para a alteração, este deve ser testado previamente. Para a Avanet, consultar Configurar o acesso de suporte ao Sophos Firewall.

Verificar separadamente os hotfixes automáticos

Os hotfixes não são um slot de firmware nem um Pattern Update. O SFOS 22 verifica a existência de hotfixes disponíveis a cada 30 minutos e instala-os automaticamente por predefinição. A Sophos recomenda que esta definição não seja alterada. O estado é consultado na Device Console antes e depois de uma alteração de firmware:

system hotfix show

Para o SFOS 22, a Sophos indica que os hotfixes já instalados permanecem após um upgrade de firmware. Em contrapartida, a lista específica da versão no SFOS 23 é reavaliada após cada mudança de versão, como explicado na secção seguinte. Se a verificação mostrar que a instalação automática está desativada, deve primeiro determinar-se quem a desativou e porquê. Sem uma exceção documentada, deve ser reativada:

system hotfix enable

system hotfix disable apenas desativa a instalação automática e não é um passo geral de troubleshooting. Um estado ativo também não prova que um hotfix específico já tenha sido aplicado ou que o caminho de download funcione. Para um erro concreto, também se verificam a build, a hora, o acesso à Internet, os logs e a referência de erro da Sophos.

SFOS 23: comprovar os updates de segurança aplicados

No SFOS 23, Backup & firmware > Hotfix: Security updates mostra quais os updates de segurança por hotfix aplicados desde a mudança para a versão SFOS atualmente em execução. Os hotfixes corrigem o sistema em execução sem um upgrade de firmware e não devem ser confundidos com a lista de imagens de firmware disponíveis. A instalação automática de hotfixes tem de estar ativada; está ligada por predefinição. system hotfix show verifica esta definição, mas não comprova a aplicação de uma correção de segurança específica.

Para os registos da alteração antes e depois da mudança de firmware:

1. Documentar a versão SFOS ativa, incluindo o build e a hora da verificação, e abrir a página Hotfix: Security updates.
2. Ordenar as entradas pela data de aplicação e registar os updates relacionados com o problema investigado. Para vulnerabilidades descritas publicamente, a coluna Advisory remete para o aviso de segurança correspondente. As correções internas podem aparecer sem ID CVE e sem link para um aviso de segurança.
3. Em HA, incluir ambos os equipamentos na verificação posterior: o Primary atual recebe o hotfix, sincroniza com o Auxiliary e o hotfix também é aplicado nesse equipamento. Uma verificação bem-sucedida num equipamento não substitui a comprovação para o cluster.

Uma vulnerabilidade pode aparecer várias vezes, porque podem ser necessários vários hotfixes para a corrigir completamente. Por isso, uma única entrada correspondente não comprova, de forma geral, uma proteção completa. Para uma correção de segurança específica, devem comparar-se os requisitos do aviso de segurança correspondente com o build em execução e os updates efetivamente aplicados.

Notificações e logs: Em System services > Notification list, na área Firmware, ativar a opção Email em Security updates. Não estão disponíveis notificações SNMP para estes updates. Os updates de segurança por hotfix também aparecem no Log viewer; os respetivos Audit Logs são gerados e encaminhados para o Sophos Fusion para Central Firewall Reporting. Estas indicações sobre notificações e logs aplicam-se aos updates de segurança por hotfix, não de forma geral a todas as correções por hotfix. Por isso, a ausência de um email, por si só, não comprova nem o sucesso nem a falha.

Após uma mudança de versão: O SFOS instala primeiro o novo firmware e aplica depois os hotfixes disponíveis para essa versão. A lista de hotfixes anterior é removida e substituída pela lista da nova versão; não é um arquivo que abranja várias versões. A mesma correção pode voltar a aparecer porque foi aplicada de forma independente à nova versão. Se as correções anteriores já estiverem incluídas no novo firmware, podem não aparecer como entradas de hotfix separadas.

Uma lista vazia significa apenas que ainda não foram aplicados e apresentados updates de segurança por hotfix para a versão atual. Não comprova a falta de proteção, uma proteção completa ou o funcionamento da instalação automática. Em caso de dúvida, verificar em conjunto a versão ativa e o build, a definição na CLI, o aviso de segurança, as release notes e os logs; não desativar preventivamente a instalação automática nem concluir que é necessário um rollback com base numa página vazia.

Preparar backup, recovery e registos

Backup, SSMK e slots de firmware

Antes da atualização, deve ser descarregado um backup recente da configuração e verificado qual o Secure Storage Master Key associado. A palavra-passe do backup, o acesso de administrador, a versão de firmware ativa e a versão de destino também devem ser registados na alteração.

O Sophos Firewall mantém no máximo duas versões de firmware: uma ativa e uma inativa. Cada partição tem o seu próprio estado de configuração. Um rollback ativa, portanto, não apenas o firmware anterior, mas também a respetiva configuração. As alterações realizadas após o upgrade podem perder-se ao voltar atrás.

O rollback automático está disponível a partir do SFOS 20.0 para determinados erros de migração da configuração. É uma função de segurança, mas não substitui um backup nem a análise da causa e não está disponível para um caminho de upgrade não suportado.

O processo completo está descrito em Criar ou restaurar um backup do Sophos Firewall. Se não for possível uma mudança de versão normal, consultar Reinstalar o Sophos Firewall OS com uma unidade USB.

Definir antecipadamente os critérios de rollback

Antes de iniciar, deve-se definir durante quanto tempo um erro será analisado e quando começa a recovery. Um rollback é adequado se WAN, HA, VPN centrais ou publicações críticas para a produção não puderem ser estabilizadas dentro do prazo acordado. Para uma única regra, objeto ou serviço externo, o troubleshooting direcionado é muitas vezes melhor.

Para uma Maintenance Release normal, um backup, uma captura da página de firmware, a janela e o resultado dos testes são registos suficientes. Para alterações maiores, o Sophos Firewall Config Studio ajuda a comparar configurações e o Audit Trail regista as alterações durante a janela de manutenção.

Verificar o estado do sistema, o espaço e o HA

Espaço e SSD

Antes de um upgrade importante, deve-se verificar no WebAdmin que:

• Control center não apresenta avisos críticos por resolver.
• Backup & Firmware > Firmware apresenta os slots de firmware esperados.
• Diagnostics > Log viewer não contém erros recorrentes do sistema ou de migração.
• Os serviços relevantes estão estáveis.
• O Firewall Health Check não contém pontos abertos que afetem a alteração.

Após iniciar sessão por SSH, deve-se abrir Device Management > Advanced Shell e verificar o espaço livre:

df -kh

Se uma partição estiver quase cheia, não se devem eliminar indiscriminadamente ficheiros, logs ou reports na Advanced Shell. Primeiro deve ser identificada a causa e utilizado o método de limpeza documentado. Consultar Verificar o espaço do Sophos Firewall e gerir reports.

O SFOS 22 pode exigir espaço adicional. Em alguns modelos XGS Appliance, também é necessário atualizar primeiro o firmware do SSD; o WebAdmin apresenta uma mensagem quando isso é necessário. Num cluster HA, cada node é avaliado separadamente. Se uma appliance não cumprir os requisitos, pode bloquear todo o upgrade.

Em appliances mais antigos ou com problemas de I/O, base de dados ou reports, deve-se também verificar o estado do SSD com SMART. Sem uma conclusão concreta, alterações manuais a bases de dados ou sistemas de ficheiros não são uma preparação útil.

A Sophos refere um reinício antes do upgrade apenas como opção para limpar a cache de memória. Não é um requisito e causa uma interrupção adicional. Por isso, o reinício só deve ser feito na janela de manutenção, depois de guardar os logs relevantes e confirmar o caminho de recuperação do acesso de gestão. Se a firewall apresentar instabilidade sem explicação, o upgrade deve ser interrompido; um reinício não pode substituir a análise da causa nem fazer o sistema parecer saudável apenas temporariamente.

Cluster HA

O HA não precisa de ser desativado para uma atualização normal de firmware. Antes da aprovação, ambas as appliances devem, no entanto, estar ligadas, sincronizadas e claramente identificadas como Primary e Auxiliary. Uma atualização HA também requer uma janela de manutenção, porque o failover pode interromper brevemente sessões, túneis VPN ou pings individuais.

Antes de iniciar, deve-se documentar:

• Funções, estado HA e sincronização.
• Estado do link HA.
• Requisitos de firmware, espaço e SSD de ambos os nodes.
• Acesso de gestão alternativo.
• Failover esperado e possíveis interrupções breves.

A appliance Auxiliary não deve ser atualizada separadamente. O artigo de execução explica a sequência exata de atualização da Auxiliary, failover e atualização da anterior Primary. Outros cenários HA estão descritos em Cluster HA do Sophos Firewall: variantes e manutenção.

Os Pattern Updates são instalados na Primary e depois sincronizados com a Auxiliary. Os hotfixes e o respetivo estado devem ser considerados separadamente e verificados em ambos os equipamentos após a janela de manutenção.

Planear a janela de manutenção, Central e testes

Janela de manutenção e acesso

Uma janela de manutenção abrange mais do que o momento da instalação:

• Hora de início, prazo máximo e decisão de rollback.
• Responsáveis pela firewall, rede, servidores, aplicações e suporte.
• Contacto local, acesso out-of-band ou um segundo caminho de gestão.
• Canal de comunicação se WAN ou Remote Access falhar.
• Modo de manutenção para monitorização e alertas.
• Sequência de testes para os processos empresariais mais importantes.

Em locais remotos, não se deve depender apenas do Sophos Fusion ou da ligação VPN existente. Se esse caminho falhar durante a atualização, deve continuar disponível um acesso ou caminho de escalonamento definido.

Planear o firmware através do Sophos Fusion

As atualizações de firmware geridas pelo Central são preparadas e monitorizadas em My Products > Firewall Management > Firewalls. A Task Queue destina-se a políticas de grupo e tarefas de configuração MDR/API e não apresenta atualizações de firmware.

Através do Central só podem ser instaladas versões de destino que tenham atingido a fase Available to all do processo de lançamento. As atualizações planeadas começam de acordo com o fuso horário definido na firewall, e não com a hora do browser do administrador. Para locais internacionais, o fuso horário, a janela local e a versão de destino devem ser registados na alteração.

Durante o upgrade, um ícone de estado gira junto à firewall e desaparece quando termina. Depois, continua a ser obrigatório verificar localmente a versão de firmware ativa. Em caso de rollback automático, o Central apresenta uma mensagem correspondente junto à versão.

Testes funcionais reais

Um ping por si só não prova que a firewall funciona corretamente após a atualização. Devem ser definidos previamente testes concretos com source, destination e resultado esperado:

• Acesso à Internet e resolução DNS.
• DHCP, VLANs, uplinks WAN e rotas SD-WAN.
• Site-to-Site VPN, Remote Access VPN e RED.
• Regras de firewall, NAT e serviços publicados.
• WAF, Web Protection e TLS Inspection.
• LDAP, RADIUS, Microsoft Entra ID e outra autenticação central.
• Fluxo de email e aplicações críticas para o negócio.
• Syslog, SIEM e monitorização.

Validar após a atualização

Após o reinício, deve-se verificar primeiro a versão ativa e o slot inativo esperado em Backup & Firmware > Firmware. Depois:

• Verificar em Control center novos avisos ou um rollback automático.
• Verificar interfaces, WAN, SD-WAN, funções HA e sincronização.
• Validar VPN, RED, DNS, DHCP, regras, NAT, WAF e autenticação com os testes preparados.
• Verificar o estado de patterns e hotfixes.
• Verificar a sincronização do Sophos Fusion, bem como monitorização, syslog e SIEM.
• Registar na alteração o resultado, os horários, os desvios e eventuais trabalhos posteriores.

Se uma única função falhar, devem ser utilizados primeiro Log Viewer, Policy Test, Packet Capture e os service logs relevantes. Consultar Testar uma regra de firewall com Log Viewer, Policy Test e Packet Capture e Troubleshooting do Sophos Firewall: serviços e logs.

FAQ