Sophos Firewall reinicia inesperadamente: verificar a causa

Quando uma Sophos Firewall reinicia sem uma intervenção planeada, não se deve fazer imediatamente outro reboot nem reiniciar serviços por precaução. Primeiro é necessário perceber se toda a appliance reiniciou realmente ou se apenas o WebAdmin, um serviço individual ou a função HA ativa deixou de estar disponível. Um reinício bem-sucedido pode repor o funcionamento, mas ainda não explica a causa.

⚠️ Guardar provas antes de outras intervenções: Não eliminar logs, não provocar outro reboot, não alterar o estado de auto-reboot-on-hang nem iniciar Debug, ações sobre serviços, fsck, Factory Reset ou Reimage por tentativa. Estas intervenções podem alterar indícios, causar novas interrupções ou ocultar o erro real.

O percurso rápido e seguro é:

Registar a hora com o fuso horário, a duração da falha e a última observação conhecida em funcionamento.
Registar se tráfego, WebAdmin, SSH e a consola local foram afetados ao mesmo tempo.
No Control Center, guardar uptime, services, interfaces, VPNs e, em HA, o estado do cluster.
Em Log viewer > System, exportar os eventos adequados e, em Diagnostics > System graphs, guardar a evolução.
Em Diagnostics > Tools, descarregar um CTR, sysinit.log, syslog.log e, em HA, os logs locais dos nodes.
Na Device Console, ler uptime, build e o estado de Auto-Reboot:

system diagnostics show uptime
system diagnostics show version-info
system auto-reboot-on-hang show

Em HA, comparar funções, estado, Last status change e uptime dos dois nodes.
Só depois verificar o ramo de causas adequado e testar completamente o ambiente de produção.

system auto-reboot-on-hang show não altera nada. O SFOS ativa esta função por predefinição e pode reiniciar automaticamente a firewall quando o kernel deixa de responder. No entanto, um enable apresentado apenas comprova a Recovery Policy configurada, não que um Kernel-Hang tenha causado este reinício concreto.

Ajustar a recovery policy apenas como alteração separada

Fora de uma análise ativa de incidente, a recovery policy pode ser explicitamente ativada ou desativada na Device Console:

system auto-reboot-on-hang enable
system auto-reboot-on-hang disable

enable é o valor predefinido. disable não impede um kernel hang, apenas remove este caminho de recovery automática se o kernel deixar de responder. Da mesma forma, enable não provoca um reinício imediato nem prova a causa de um hang anterior.

Uma divergência do valor predefinido deve ser tratada como uma alteração documentada ou um caso Sophos Support. Primeiro registam-se o estado inicial, o motivo, a janela de manutenção e o caminho de rollback. Depois, system auto-reboot-on-hang show confirma o estado pretendido. Durante o diagnóstico de um reinício não planeado, o estado encontrado permanece inalterado para não misturar as provas com a recovery policy.

Verificar o que falhou realmente

A interrupção observada, por si só, ainda não comprova um reboot completo. Estes quatro casos exigem passos seguintes diferentes:

Reboot completo da appliance: O uptime começa de novo, vários serviços e ligações foram interrompidos ao mesmo tempo e o SFOS voltou a executar o arranque do sistema. Neste caso aplica-se o triage de reboot deste artigo.
Apenas o WebAdmin ou um serviço foi afetado: O uptime continua a contar e o tráfego de produção pode continuar parcialmente inalterado. Nesse caso, um reinício direcionado do WebAdmin GUI ou a verificação de um serviço individual é mais adequado do que um reboot da appliance.
Failover HA: Os utilizadores podem observar uma breve interrupção, embora apenas as funções tenham mudado. Uptime, função e logs de cada node mostram se um equipamento reiniciou realmente. A verificação HA é apresentada mais abaixo.
Modo Failsafe: A firewall não arranca normalmente e apresenta um estado Recovery na consola. Nesse caso, siga o runbook sobre o modo Failsafe da Sophos Firewall antes de considerar um reinício, reset ou reimage. Não se pressupõe aqui um comando de diagnóstico geral.

O uptime é, portanto, uma prova sólida do período do reinício, mas não da causa. Uma breve falha de energia, um Kernel-Hang, um erro de firmware e um reinício planeado por um administrador também repõem o uptime.

Guardar provas após o reinício

Após um reboot não planeado, alguns dados voláteis podem já estar em falta. Ainda assim, deve guardar-se completamente o estado acessível antes de efetuar outras alterações.

O incidente deve incluir pelo menos:

modelo, número de série e plataforma: hardware, VM ou cloud
versão completa do SFOS com MR e build
hora exata, fuso horário, duração e frequência da falha
funções afetadas: tráfego, WebAdmin, SSH, consola, VPN e serviços publicados
última alteração de firmware, configuração, hypervisor, storage ou energia
uptime atual e estado de serviços, interfaces, VPN e HA
em HA: node afetado, funções antes e depois do evento e estado do Peer
eventos disponíveis de UPS, PDU, hypervisor, cloud, switch e monitorização no mesmo período

Em Diagnostics > System graphs, verificam-se CPU, Memory, Load e Disk em torno da hora suspeita. Uma anomalia pode delimitar a pesquisa. Um valor atual normal, por outro lado, não prova que a carga antes do reboot também era normal.

Em Log viewer > System, os eventos de Start, Restart, Shutdown e HA são delimitados ao mesmo período e exportados. O Log Viewer é uma fonte de tempo útil, mas não é uma prova completa de crash. Os eventos ainda não guardados podem estar em falta após um hang.

Ler o estado do sistema na Device Console

Além do uptime e da build, estes comandos só de leitura mostram o estado atual:

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk

Os valores devem ser incluídos na nota do incidente juntamente com a hora da consulta. Descrevem o estado após o reinício e não podem ser interpretados retroativamente como a causa.

Verificar logs de arranque e do sistema

Na Advanced Shell, é possível ler os ficheiros mais importantes na íntegra e sem os alterar:

cd /log
less sysinit.log
less syslog.log
less applog.log
less csc.log

Com q, termina-se o less. Dentro do ficheiro, /termo-de-pesquisa inicia uma pesquisa, por exemplo /error; n avança para a ocorrência seguinte.

sysinit.log documenta o arranque do sistema.
syslog.log contém eventos do kernel e do sistema.
applog.log e csc.log ajudam a enquadrar ações internas e alterações próximas no tempo.

Em Diagnostics > Tools > Troubleshooting logs, devem também descarregar-se os mesmos ficheiros para preservar os dados originais fora da appliance. A correspondência dos logs de serviços da Sophos Firewall explica qual o ficheiro de log adicional associado a cada serviço.

Adicionalmente, em Diagnostics > Tools > Consolidated troubleshooting report, cria-se um CTR com System snapshot e All log files. O CTR contém o estado atual do sistema e muitos logs num arquivo encriptado. Nos logs dos subsistemas de serviços estão incluídas, por predefinição, no máximo 10'000 linhas; para períodos mais longos, os logs individuais completos continuam a ser importantes. O procedimento completo encontra-se em Guardar logs da Sophos Firewall para suporte.

Uma secção de log vazia não exclui um crash nem uma falha de energia. As informações ainda não gravadas no disco podem perder-se durante um hang, e os logs locais podem ser sujeitos a rotação. Por isso, as fontes de tempo externas e uma cronologia precisa do incidente são tão importantes.

Distinguir failover HA de reboot do node

Em System services > High availability, registam-se Health, Mode, as funções, o estado, os números de série e Last status change. Depois, abre-se a Device Console de cada node e consulta-se separadamente o respetivo uptime com system diagnostics show uptime.

Se apenas um node apresentar um uptime curto, isso é um indício de que esse equipamento reiniciou. Se os uptimes não tiverem mudado, mas as funções tiverem sido trocadas, deve investigar-se primeiro o desencadeador HA, por exemplo uma Monitored Port, a ausência de heartbeat ou um problema com o peer. Se estiver configurada a opção Preferred primary device, o failback automático também pode reiniciar o node que estava a funcionar sozinho quando a Primary inicial volta a ficar disponível. A cronologia deve, portanto, reunir a configuração HA, a sequência das funções e quaisquer intervenções do administrador.

Os logs HA ficam localmente no respetivo node e não são sincronizados. Por isso, são relevantes pelo menos estes ficheiros em ambas as appliances:

cd /log
less ha.log
less msync.log

ha.log mostra a criação e as alterações de estado, enquanto msync.log mostra a sincronização. Não provocar um reinício simultâneo dos dois nodes nem forçar outro failover para reprodução. O diagnóstico completo das funções e ligações encontra-se em Sophos Firewall High Availability.

Delimitar a causa pelo contexto

Reinício planeado pelo administrador ou pelo firmware

Primeiro, comparam-se o calendário de alterações, as janelas de manutenção, as ações dos administradores, as tarefas do Sophos Fusion (anteriormente Sophos Central) e as notificações com a hora do evento. As alterações de configuração anteriores podem ser enquadradas através dos logs do Audit Trail. A Sophos Firewall gera eventos do sistema para um Start e para Restart ou Shutdown através do WebAdmin. Se estiverem configuradas notificações por e-mail, a mensagem na caixa de correio pode confirmar adicionalmente a hora e a firewall emissora.

Se o reinício ocorreu durante um processo de firmware ou Hotfix, devem guardar-se a versão de origem, a versão de destino, a build, a hora da atualização e fwmgmt.log. Um reinício faz parte de uma troca normal de firmware; vários reboots não planeados ou uma build inesperada não. Para o enquadramento seguinte, consulte o procedimento Executar a atualização de firmware da Sophos Firewall.

Kernel-Hang ou erro de software

Com auto-reboot-on-hang ativo, o SFOS pode reiniciar-se quando o kernel deixa de responder. A função melhora a disponibilidade, mas nem sempre deixa uma prova local inequívoca da causa. O estado apresentado deve ser documentado e não alterado durante o triage. O caso é delimitado através da hora, logs, System graphs, CTR e build exata.

Na SFOS 22.0 MR2 Build 546, a Sophos corrigiu vários casos independentes de crash e restart, por exemplo:

NC-180974: Kernel-Crash em sdwan_profile com HA-Failover
NC-178354: Kernel-Crash ao fazer matching de regras SD-WAN
NC-178745: reinício automático de um equipamento HA devido a Out-of-Memory
NC-180433: crash repetido com tráfego Multicast através de um túnel VPN

Estas Issue-IDs mostram por que razão A firewall reiniciou ainda não é um diagnóstico. Só quando build, função, tráfego e hora do erro correspondem ao caso documentado se verifica o percurso de atualização suportado para MR2 Build 546 ou uma versão aprovada mais recente. Se o erro voltar a ocorrer nesta build ou numa mais recente, não se deve continuar a atribuí-lo automaticamente à mesma Issue-ID antiga. As restantes correções estão enquadradas na visão geral do SFOS 22.0 MR2.

Um Kernel-Crash não deve ser reproduzido deliberadamente com testes de carga, Multicast, alterações SD-WAN ou um failover forçado. A configuração e os padrões de tráfego devem ser documentados e depois analisados com o Sophos Support.

Carga, espaço em disco ou storage

O histórico de CPU, Memory, Load e Disk pode mostrar se já existia uma anomalia prolongada antes do reboot. Além disso, a Sophos indica /log/system-monitor/cpu_trigger.log para estados do sistema registados automaticamente com carga elevada de CPU. Na documentação do SFOS 22, existe também /log/system-monitor/memory_trigger.log para utilização elevada de memória; no SFOS 21.5, não se deve pressupor a existência deste ficheiro.

Um disco cheio, uma carga de I/O elevada e uma falha de SSD são problemas diferentes. Por isso, não se eliminam reports nem logs por tentativa. Para a verificação só de leitura e a limpeza prevista, consulte Verificar o espaço da Sophos Firewall e gerir reports; o estado de hardware do disco é explicado em Verificar a integridade do SSD da Sophos Firewall através de SMART.

Energia, temperatura ou hardware

Numa XGS Appliance física, verificam-se a alimentação, as fontes de alimentação, UPS/PDU, temperatura do rack, fluxo de ar, ventoinhas, LEDs, SSD e a consola local. A ausência de um registo de Shutdown normal pode ser compatível com um evento abrupto de energia, mas não o comprova. A cronologia conjunta da firewall, UPS/PDU, monitorização e ambiente é determinante.

Uma temperatura atual após o reboot também é apenas um valor momentâneo. A verificação da temperatura, ventoinhas e xgs-healthmond.log explica o ramo térmico de causas. Erros recorrentes de boot, I/O, fonte de alimentação, NPU ou ventoinha devem ser incluídos, juntamente com os dados guardados, na preparação de um caso de hardware e RMA.

Firewall virtual ou Cloud Appliance

Numa VM, verificam-se adicionalmente eventos do hypervisor, reinícios do host, latência do datastore, tarefas de snapshot ou backup, vCPU, RAM, disks e vNICs no mesmo momento. Em AWS ou Azure, os eventos da plataforma, o estado da instância e as manutenções planeadas fazem parte da cronologia do incidente.

Um evento do host ou da plataforma pode reiniciar a VM sem que o próprio SFOS tenha causado o problema. Inversamente, um hypervisor sem anomalias não prova que o sistema convidado estava isento de erros. Por isso, as duas cronologias são avaliadas em conjunto. As diferenças atuais entre plataformas e recursos são explicadas em Sophos Firewall como hardware, VM ou Cloud Appliance.

Verificar o funcionamento após o reinício

Uma página de login acessível ainda não constitui um teste de aceitação completo. Após guardar as provas, devem verificar-se, conforme o ambiente:

Control Center sem novos avisos de services, interfaces, VPN ou performance; verificar adicionalmente System graphs e Notifications quanto a anomalias de Memory e Disk
WAN, routing, DNS e acesso à internet pelo percurso esperado
ligações importantes de Site-to-Site VPN e Remote-Access VPN
publicações centrais DNAT, WAF ou de servidores
DHCP, RED e Wireless, se a firewall disponibilizar estes serviços
em HA: Health, funções, sincronização e uptime dos dois nodes
novos erros de sistema, kernel ou hardware desde o arranque

Os fluxos de negócio reais mais importantes devem ser testados deliberadamente e documentados com a hora. Um uptime estável mostra apenas que não ocorreu outro reboot. A causa original só é considerada esclarecida quando a cronologia, os logs e as observações da plataforma oferecem uma explicação sólida.

Preparar o caso de suporte e a deteção futura

Um ticket do Sophos Support é apropriado se o reboot continuar sem explicação, voltar a ocorrer, tiver causado uma falha de HA ou de uma localização, ou houver indícios relativos ao kernel, memória, storage, NPU ou hardware. O caso deve incluir a hora do incidente com fuso horário, plataforma, build completa, uptime, funções afetadas, últimas alterações, funções HA, CTR, logs relevantes completos e a cronologia externa de energia ou do hypervisor.

Para o incidente seguinte, uma monitorização preparada melhora as provas disponíveis:

Entregar notificações por e-mail para System started, Restart/Shutdown e alterações de estado HA.
Enviar eventos de sistema e HA para Syslog ou SIEM, para que a cronologia seja preservada fora da firewall.
Monitorizar uptime e estado de hardware através de SNMP Monitoring.
Operar alarmes de UPS/PDU, hypervisor e cloud com o mesmo servidor de tempo e uma identificação clara da localização.

Assim, no evento seguinte, é possível decidir mais rapidamente se a falha foi causada pelo próprio SFOS, por um node individual, pela plataforma ou pelo ambiente de energia e hardware.