Sophos Firewall em modo Failsafe: proceder em segurança

Quando uma Sophos Firewall apresenta failsafe, a situação deve ser tratada como um incidente de recovery. A documentação pública do SFOS 22 não descreve um comando de diagnóstico geral que identifique com fiabilidade a causa de todos os estados Failsafe. Por isso, este runbook não utiliza show failure-reason nem um substituto inventado.

Primeiro, guardar a mensagem apresentada sem alterações; depois, avaliar a plataforma, a função HA, o Build do firmware e a última alteração. Enquanto a causa não estiver comprovada, não modificar manualmente bases de dados, assinaturas, regras ou ficheiros de sistema.

⚠️ Documentar antes de reiniciar: Um reinício pode alterar o erro visível. Fotografar toda a consola, incluindo as primeiras mensagens de boot, e registar hora, modelo, número de série, versão SFOS completa com Build e, em HA, o Node afetado. Reset to Factory Defaults, Remove Firewall Rules e alterações manuais à base de dados ou ao sistema de ficheiros não são um diagnóstico inicial seguro.

Registar a mensagem Failsafe em segurança

1. Utilizar a consola direta disponível: local ou série em hardware, consola do hypervisor numa VM. Esta via mantém-se disponível quando o WebAdmin ou a rede não estão acessíveis.
2. Fotografar literalmente a mensagem com as linhas de boot imediatamente anteriores. Não substituir a mensagem real por um exemplo da Internet.
3. Registar plataforma e modelo, número de série, Build SFOS completo, hora da falha e última hora conhecida de funcionamento.
4. Registar alterações recentes, sobretudo upgrade do firmware, rollback, restore, regras ou objetos, recursos VM, discos virtuais, vNICs e eventos de storage.
5. Em HA, registar Node afetado, função, estado do peer e última mudança de função. Não reiniciar ambos os Nodes ao mesmo tempo nem desativar HA por suspeita.

Um WebAdmin inacessível, por si só, não comprova um estado Failsafe. Se a firewall iniciar normalmente e o tráfego continuar a passar, mas apenas a interface não responder, deve começar-se pela verificação específica ou pelo reinício da GUI do WebAdmin. Uma mensagem Failsafe explicitamente apresentada é, pelo contrário, tratada como problema de arranque ou recovery.

Delimitar causas documentadas

A Sophos documenta vários fatores específicos, mas não exaustivos, para o SFOS 22. As Release Notes do SFOS 22.0 MR2 Build 546 incluem Failsafe devido a uma partição de configuração cheia (NC-181331), um logging daemon que não iniciava no dispositivo HA Primary (NC-180110), Failsafe no dispositivo Primary inicial após upgrade para 22.0 GA (NC-177441) e Failed to start Red server service (NC-178906). Estas entradas comprovam falhas conhecidas e corrigidas, não uma matriz geral de reparação.

Se o estado observado, a plataforma ou a função HA e o histórico de versões corresponderem exatamente a uma entrada das Release Notes, incluir o Issue ID e o Build instalado no caso de suporte. Uma correspondência parcial não comprova a mesma causa nem que uma alteração de firmware não coordenada recupere a firewall. A Sophos só cita literalmente a mensagem apresentada para NC-178906. Se a firewall iniciar normalmente e apenas um túnel RED estiver offline, deve seguir-se a resolução de problemas de RED.

Software appliance

Para uma software appliance SFOS 22 instalada em hardware próprio, a Sophos define, entre outros, estes requisitos mínimos relevantes para o sistema em funcionamento e afirma expressamente que a firewall entra em modo fail-safe se não forem cumpridos:

• CPU x86-64 e Legacy BIOS
• pelo menos 4 GB de RAM
• HDD ou SSD com pelo menos 32 GB; recomendam-se 64 GB
• 2 placas de rede

Documentar o estado atual antes de qualquer alteração. Perante uma divergência confirmada, esclarecer com o Sophos Support se basta um ajuste de recursos suportado ou se é necessário um reimage controlado. Não improvisar alterações ao disco ou ao modo de arranque. Diferenças entre plataformas e requisitos de recursos explica em detalhe appliances de hardware, virtuais e software.

Appliance virtual e de hardware

Numa VM, registar vNICs e discos virtuais presentes e ligados, CPU, RAM, controlador de disco e alterações recentes no hypervisor. As plataformas cloud e hypervisor têm requisitos suportados próprios; não aplicar automaticamente os valores da software appliance a todas as implementações virtuais.

Em hardware, incluir no caso de suporte falhas de boot recorrentes, eventos de energia, indícios de I/O ou SSD, temperatura e ventoinhas. Um reinício bem-sucedido não exclui um defeito. Ajudam as verificações de temperatura e ventoinhas, estado do SSD e preparação de RMA.

Guardar logs e backup

Se a Advanced Shell ainda estiver acessível, sysinit.log, syslog.log e, perante indicação de base de dados, postgres.log são logs oficiais de troubleshooting relevantes. Para a mensagem RED documentada, incluir também red.log. Este runbook não fornece deliberadamente comandos shell para copiar, eliminar ou reparar: a via de acesso e as ferramentas disponíveis podem variar num estado de recovery.

Quando o WebAdmin voltar a estar disponível, gerar um arquivo Troubleshooting ou CTR. O procedimento encontra-se em Guardar logs da Sophos Firewall para suporte. Logs e arquivos podem conter dados confidenciais de rede, utilizadores e configuração e só devem ser transmitidos de forma protegida a destinatários autorizados.

Antes de restore ou reimage, devem estar disponíveis um backup adequado, a palavra-passe e o Secure Storage Master Key associado. Backup e restore da Sophos Firewall explica estas dependências.

Utilizar fsck-on-nextboot apenas com Sophos Support

system fsck-on-nextboot não é uma verificação geral de estado. A Sophos avisa que só deve ser utilizado por recomendação do Sophos Support. Destina-se a erros de mount de /sig, /conf ou /var; se o hardware ou SSD não estiver saudável, a verificação pode danificar o sistema de ficheiros.

A sintaxe documentada da Device Console é:

system fsck-on-nextboot [on | off | show]

on força a verificação de todas as partições no reinício seguinte, off cancela-a antes desse reinício e show apresenta a configuração atual; a predefinição é off. O SFOS pode agendar a verificação automaticamente em Failsafe se a base de dados de configuração, relatórios ou assinaturas não iniciar, se não for possível aplicar uma migração ou se o deployment mode não for encontrado.

Não reiniciar apenas porque aparece on. Incluir primeiro no mesmo plano de manutenção a recomendação do suporte, acesso estável à consola, alimentação, backup, possíveis erros I/O e, em HA, o estado do peer. A Sophos não indica duração fixa nem garantia de sucesso.

Escolher um caminho de recovery seguro

• Requisito de software claramente abaixo do mínimo: Guardar o estado atual e executar numa janela de manutenção o ajuste ou reimage confirmado pelo Sophos Support. Observar o arranque seguinte na consola.
• Mensagem corresponde a um problema conhecido das Release Notes: Guardar Build completo e Issue ID. Pedir ao Sophos Support que confirme o caminho de recovery, upgrade ou rollback para esse estado.
• Incidente HA: Proteger o peer ainda operacional. Sem reinícios simultâneos ou mudanças não planeadas de função ou cluster. Consultar High Availability na Sophos Firewall.
• Erro de storage, base de dados, regras, NPU, I/O ou desconhecido: Não remover ficheiros ou configuração por suspeita. Escalar ao Sophos Support com consola, logs e cronologia.
• Reimage: Utilizar apenas se o Sophos Support ou um plano de recovery documentado o justificar e estiverem disponíveis todos os requisitos de restore. Consultar Reinstalar o Sophos Firewall OS.

Depois de qualquer ação, não verificar apenas o WebAdmin e o login. Confirmar arranque normal da consola, estado HA, interfaces, routing e ligações necessárias de Internet e VPN. Se a mensagem voltar, adicionar hora e saída inalterada em vez de improvisar novas alterações.

Escalar ao Sophos Support

Escalar um incidente Failsafe assim que a causa não possa ser limitada a uma divergência de recursos documentada e corrigível em segurança. O caso no Sophos Support deve incluir, no mínimo:

• fotografia ou cópia de todas as mensagens Failsafe e de boot
• modelo, número de série, plataforma e Build SFOS completo
• hora da falha, última hora de funcionamento e cronologia de alterações
• em HA: Node, função, estado do peer e última mudança de função
• logs relevantes ou CTR e indícios de storage, I/O, NPU ou energia
• backup disponível e estado da palavra-passe e SSMK, sem revelar segredos no texto do ticket
• reinícios ou alterações já realizados e respetivo resultado

Se o WebAdmin estiver disponível e a Sophos pedir acesso remoto, pode ativar-se temporariamente Support access em Diagnostics > Support access. Partilhar o Access ID gerado apenas pelo canal de suporte acordado; o acesso pode ser desativado a qualquer momento.