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.

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, show failure-reason do runbook sobre o modo Failsafe da Sophos Firewall é o primeiro comando adequado.

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, guardam-se Health, Mode, funções, estado, números de série e Last status change. Na Device Console, o seguinte comando também mostra detalhes:

system ha show details

De seguida, verifica-se o uptime nos dois nodes. Se apenas um node tiver um uptime curto, isso indica um reinício desse equipamento. Se os uptimes não tiverem mudado, mas as funções tiverem sido trocadas, deve investigar-se primeiro o desencadeador HA, como uma Monitored Port ou um problema com o Peer. Uma troca manual da função ativa também pode reiniciar a anterior Primary; por isso, uma possível intervenção do administrador deve fazer parte da cronologia.

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 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 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.