Sophos Firewall em modo Failsafe: verificar a causa

Quando uma Sophos Firewall inicia em modo Failsafe, o SFOS detetou um erro crítico e não iniciou o funcionamento normal. O processamento de pacotes, as interfaces e o acesso de gestão podem falhar total ou parcialmente, dependendo da causa. Por isso, uma porta de gestão ainda acessível não permite concluir que a firewall continua a oferecer proteção fiável.

O primeiro passo mais importante não é um Factory Reset ou reimage, mas guardar a causa detetada pelo SFOS:

1. Ligar através da consola local, série ou do hypervisor.
2. Abrir Device Console no menu Failsafe.
3. Executar o seguinte comando apenas de leitura:

show failure-reason

Em seguida, a consola pode apresentar, por exemplo:

failsafe> show failure-reason
Unable to apply Firewall Framework

failsafe> é apenas o prompt e não deve ser introduzido. A mensagem exata pode ser diferente. O importante é fotografar ou copiar a saída inalterada e as primeiras linhas visíveis da consola. Se o SSH ainda funcionar no estado de erro, a Device Console também está acessível por essa via; em caso de falha, a consola local, série ou do hypervisor continua a ser o caminho mais robusto.

⚠️ Guardar antes de reiniciar: Um Reboot pode alterar a situação de erro visível ou eliminá-la temporariamente. Documentar primeiro, no mínimo, a mensagem de erro, a versão SFOS com Build, a função da appliance e a hora. Reset to Factory Defaults, Remove Firewall Rules e intervenções manuais na base de dados ou no sistema de ficheiros não são diagnóstico e podem destruir configurações ou provas importantes.

O que significa o modo Failsafe

Failsafe é um estado de proteção e recovery. O SFOS inicia-o quando um componente necessário ao funcionamento seguro da firewall não arranca corretamente. As mensagens conhecidas e os casos de erro reais incluem, por exemplo, a base de dados de configuração, o firewall framework, o conjunto de regras, o serviço de logging ou rede, a base de dados de assinaturas ou, num modelo XGS devidamente equipado, a Network Processing Unit (NPU). Esta não é uma matriz de reparação completa; a saída concreta da consola continua a ser determinante.

Um WebAdmin inacessível, por si só, ainda não comprova um estado Failsafe. Se o tráfego continuar a passar e apenas a interface estiver bloqueada, deve começar-se pela verificação específica ou pelo reinício da GUI do WebAdmin. O Failsafe real é identificado na consola. A disponibilidade de acesso de gestão ou de algumas interfaces depende da causa e não comprova que o sistema esteja saudável.

Esta distinção é importante: se apenas um serviço falhou, pode fazer sentido reiniciá-lo de forma direcionada. No modo Failsafe, pelo contrário, falta um requisito crítico de arranque. Reiniciar vários serviços por tentativa tende a ocultar a causa em vez de a corrigir.

Verificar a causa do Failsafe com show failure-reason

O comando show failure-reason pertence à Device Console, não à Advanced Shell. Não altera a configuração. Mostra a classe de erro detetada pelo SFOS durante o arranque.

A saída é um ponto de partida e não uma instrução de reparação completa. Os seguintes grupos de mensagens ajudam na classificação:

• Configuration database: A firewall não conseguiu iniciar corretamente a base de dados de configuração. Antes de reparações manuais, guardar a mensagem de erro, o Build, a última alteração e o backup disponível. Não eliminar nem alterar ficheiros da base de dados.
• Firewall framework ou firewall rules: O SFOS não conseguiu aplicar a base do processamento de pacotes ou o conjunto de regras. São relevantes as últimas alterações a regras, objetos, restore ou firmware. Remover todas as regras de firewall de forma geral seria uma perda de dados, não um primeiro diagnóstico correto.
• Logging daemon: Um serviço crítico de logging não iniciou. Além da mensagem de erro, verificar o estado do storage, o Build e os logs. Não limpar Reports ou logs sem guardar primeiro os dados necessários.
• Network daemon: Os componentes de rede não conseguiram iniciar corretamente. Nas appliances virtuais, devem verificar-se os vNICs existentes, a ordem dos adaptadores e as alterações no hypervisor.
• Signature database: Não foi possível carregar uma base de dados de assinaturas necessária. O estado dos Patterns, o storage e a relação temporal com atualizações são relevantes; não eliminar ficheiros de assinaturas manualmente.
• NPU: Num modelo XGS com NPU, a primeira linha da consola já pode apresentar Network processing unit error. Mesmo que show failure-reason não produza depois uma saída útil, guardar toda a consola e preparar um caso de suporte ou hardware.

A grafia de uma mensagem específica pode variar consoante a versão SFOS. Para o suporte, a saída inalterada é, por isso, mais valiosa do que um resumo próprio como Firewall não inicia.

Verificar a plataforma e a última alteração

O passo seguinte depende de o problema afetar hardware, uma appliance virtual ou software, ou um cluster HA. A mesma mensagem de erro não deve conduzir automaticamente à mesma ação.

Firewall virtual e software appliance

Uma firewall virtual pode entrar em Failsafe devido a recursos inadequados. Para appliances SFOS 22 executadas localmente em VMware, Hyper-V, KVM e Citrix, a Sophos indica atualmente, no mínimo:

• 1 vCPU
• 4 GB vRAM
• 2 vNICs
• 32 GB Primary Disk
• 80 GB Report Disk

Além disso, os vCPU e vRAM configurados não podem exceder a licença adquirida. Os valores mínimos são apenas limites técnicos de arranque e não representam sizing produtivo para IPS, TLS Inspection ou throughput elevado.

O Auxiliary Disk das imagens VM é esta Report Disk separada. Não é opcional e não substitui a Primary Disk. Para AWS e Azure aplicam-se, em alternativa, os tipos de instância cloud suportados e os tamanhos específicos da plataforma.

No hypervisor, verificar se ambos os discos e todos os vNICs previstos continuam presentes, ligados e atribuídos pela ordem esperada. Uma alteração posterior a CPU, RAM, controlador de disco ou rede virtual também pertence à cronologia do incidente. As diferenças entre plataformas e os requisitos de recursos são explicados em mais detalhe num artigo próprio.

Para uma software appliance SFOS 22, são consensuais x86-64, Legacy BIOS, pelo menos 4 GB de RAM e duas placas de rede. Contudo, duas páginas atuais da Sophos contradizem-se quanto ao disco: a visão geral das plataformas indica um mínimo de 10 GB, enquanto a página específica e mais recente da software appliance indica um mínimo de 32 GB e recomenda 64 GB. Não existe, portanto, um limite Sophos publicado de forma uniforme. Para novas instalações, a Avanet recomenda, de forma conservadora, pelo menos 32 GB e, sempre que possível, 64 GB; assim segue-se a página de produto mais específica e evita-se um sistema já limitado durante o arranque.

Não alterar recursos arbitrariamente várias vezes durante uma tentativa de recovery pouco clara. Primeiro, documentar o estado atual; depois, efetuar uma correção planeada com um teste de arranque definido.

Hardware appliance e NPU

Num XGS físico, também se consideram eventos de energia, temperatura, ventoinhas, erros de SSD ou I/O e as primeiras mensagens de arranque. Um erro de NPU num modelo XGS devidamente equipado não é motivo para experimentar comandos de reset ou service não documentados. Se a mensagem voltar a aparecer ou se o próprio diagnóstico falhar, o passo seguinte correto é um caso de suporte com possível preparação de RMA.

Um único reinício bem-sucedido ainda não prova que um problema de hardware foi resolvido. Em falhas repetidas, também ajudam as verificações existentes de temperatura e ventoinhas e do estado do SSD.

Failsafe num cluster HA

Em HA, identifica-se primeiro qual Node é afetado e se o peer processa o tráfego produtivo de forma estável. Documentam-se Primary ou Auxiliary, estado do cluster, última mudança de função e o mesmo momento em ambas as appliances.

Não reiniciar os dois Nodes em simultâneo nem desativar HA por tentativa. Uma alteração não coordenada pode colocar em risco o caminho ainda funcional, alterar a distribuição de funções ou obrigar a uma reconstrução. O artigo Configurar High Availability na Sophos Firewall explica funções, sincronização e logs específicos do Node; a causa concreta do Failsafe continua, no entanto, a ser guardada no Node afetado.

Após uma atualização de firmware ou restore

Se o Failsafe ocorrer imediatamente após um upgrade, rollback ou restore, são importantes a versão de origem, a versão de destino e o número de Build completo. No SFOS 22, a Sophos corrigiu com o MR2 Build 546 várias causas específicas de Failsafe, incluindo erros após o upgrade para GA, um Logging Daemon que não iniciava, uma partição de configuração cheia e determinados objetos de serviço com erro. A visão geral do SFOS 22 MR2 indica os Issue IDs corrigidos.

Isto não significa que todos os eventos de Failsafe sejam resolvidos com uma atualização. Primeiro, verificar se a mensagem de erro e o Build utilizado correspondem a uma correção conhecida. Uma mudança de firmware continua a exigir backup, janela de manutenção, plano HA e caminho de retorno. Para isso, utilizar a preparação de uma atualização de firmware e a verificação de upgrade para SFOS 22.

Failed to start Red server service

Se a firewall apresentar exatamente esta mensagem no modo Failsafe, o erro corresponde a NC-178906. A Sophos corrigiu este erro de Failsafe com o SFOS 22.0 MR2 Build 546. Num Build anterior, depois de guardar as provas, verifica-se um caminho controlado de recovery e upgrade para o Build 546 ou posterior. Se a mensagem ocorrer no Build 546 ou posterior, o Issue ID por si só não comprova a causa; nesse caso, abre-se um Support Case com os logs guardados.

Antes de um reinício ou de uma mudança de firmware, guardam-se o Build completo, a hora, o Node HA afetado e sysinit.log, red.log e syslog.log no momento do erro. Não se eliminam por suspeita interfaces RED, RED Firmware Pattern ou a configuração RED, nem se reinicia repetidamente o serviço RED. Se a firewall iniciar normalmente e apenas um túnel RED permanecer offline, deve utilizar-se a resolução de problemas de RED.

Guardar provas antes do recovery ou reinício

Para uma análise sólida, recolher, sempre que possível, antes da primeira ação que altere o estado:

• saída completa de show failure-reason e primeiras linhas de arranque visíveis
• modelo, número de série e plataforma hardware, virtual ou software
• versão SFOS exata, incluindo MR e Build
• hora da falha e última hora conhecida de funcionamento
• últimas alterações a firmware, restore, regras, objetos, interfaces, recursos VM ou storage
• em HA: Node afetado, função, estado do peer e hora do último failover
• backup atual disponível e respetivo Secure Storage Master Key
• em VMs: vCPU, vRAM, vNICs, Primary Disk, Report Disk e limite da licença
• sintomas recorrentes, como Reboots e erros de I/O, NPU, temperatura ou storage

Se a Advanced Shell ainda estiver acessível, também podem ser guardados excertos de log adequados. Estes exemplos leem apenas as últimas 200 linhas e não alteram o sistema:

tail -n 200 /log/sysinit.log
tail -n 200 /log/syslog.log
tail -n 200 /log/postgres.log

O sysinit.log é o log central do arranque do sistema, o syslog.log contém eventos do kernel e do sistema e o postgres.log ajuda na base de dados de configuração. Dependendo de show failure-reason, o mesmo comando tail apenas de leitura é aplicado ao log de detalhe adequado, por exemplo:

tail -n 200 /log/networkd.log
tail -n 200 /log/sigdb.log
tail -n 200 /log/npu-startup.log

O networkd.log pertence às interfaces físicas e virtuais, o sigdb.log à base de dados de assinaturas e o npu-startup.log apenas aos modelos de hardware com NPU. Nem todos os ficheiros existem em todas as plataformas. A correspondência adicional encontra-se em Serviços e ficheiros de log da Sophos Firewall. Os excertos de log podem conter dados confidenciais e devem ser transferidos de forma protegida.

Quando o WebAdmin voltar a estar acessível, também se deve guardar um arquivo CTR ou Troubleshooting. O procedimento encontra-se em Guardar logs da Sophos Firewall para suporte.

Escolher o próximo passo seguro

Depois de guardar as provas, é possível decidir o caminho de recovery com maior precisão:

1. Desvio claro de recursos numa VM ou software appliance: Documentar o estado atual, verificar os limites da licença e os valores mínimos atuais, desligar a VM de forma controlada, corrigir exatamente o desvio confirmado e observar o próximo arranque.
2. Indicação de storage ou logging: Verificar a partição e o tipo de dados afetado apenas em modo de leitura. Não eliminar ficheiros com rm. O guia Verificar storage e Reports em segurança mostra os métodos de diagnóstico e limpeza previstos.
3. Erro imediatamente após uma alteração de firmware: Comparar o Build com problemas conhecidos e só depois decidir de forma controlada entre o Maintenance Release atual, rollback ou suporte.
4. Indicação de NPU, I/O ou hardware recorrente: Preparar um caso de suporte e, se necessário, um RMA. Um Reboot temporariamente bem-sucedido não exclui um defeito.
5. Erro de base de dados, framework, regras ou arranque desconhecido: Guardar a saída e os logs e abrir um caso no Sophos Support com o cenário de erro completo. Não remover manualmente ficheiros da base de dados, conjuntos de regras ou assinaturas.
6. Reimage como recovery: Utilizar apenas quando os danos no sistema operativo, o suporte ou o plano de recovery documentado justificarem este caminho. Antes disso, devem estar disponíveis backup, palavra-passe e SSMK. O procedimento completo encontra-se em Reinstalar o Sophos Firewall OS.

Depois de cada ação, não verificar apenas o WebAdmin. São decisivos o arranque normal da consola, o estado correto de HA, o estado das interfaces e do routing, as ligações de Internet e VPN, e a repetição da mesma mensagem de erro. Se a causa continuar pouco clara ou reaparecer, não deve ser ocultada por outras alterações espontâneas.