Sophos Firewall Log Viewer não mostra novos logs

Se o Log Viewer não mostrar novos eventos, não se deve reiniciar imediatamente um serviço. Primeiro é necessário determinar se falta apenas uma entrada esperada ou se a apresentação local dos logs parou por completo. Para a utilização normal, filtros e interpretação de campos, consultar primeiro Utilizar corretamente o Log Viewer da Sophos Firewall. O procedimento rápido e seguro para uma vista parada é:

1. No Log Viewer, verificar Pause, módulo, período e filtros aplicados e, em seguida, executar Reset e Refresh.
2. Na regra de firewall afetada, verificar Log firewall traffic e, em System services > Log settings, o tipo de log Firewall em Local reporting.
3. Gerar uma ligação curta a partir de um cliente de teste conhecido e anotar a hora.
4. Utilizar Packet capture para verificar se o tráfego chega à firewall e qual Rule ID é processada.
5. Apenas se também faltarem outros eventos esperados, registar a versão SFOS, a build completa e a hora do último log visível.
6. Utilizar o workaround do Garner apenas em SFOS 21.5 MR1 Build 261 e apenas para o cenário de erro descrito abaixo.

Desta forma, a resolução de problemas permanece rastreável: um filtro incorreto ou uma regra que não gera logs não é confundida com um erro da base de dados de logging.

Porque pode faltar uma única entrada de log

O Log Viewer é normalmente atualizado de forma automática. No entanto, apresenta apenas os eventos que o módulo selecionado guarda localmente e que não estão ocultos pela vista atual.

As causas mais comuns que não correspondem a uma falha técnica do Viewer são:

• Pause está ativo: os novos eventos só aparecem depois de retomar a vista ou efetuar uma atualização manual.
• O módulo, o período ou os filtros não correspondem: Reset remove todos os filtros; depois seleciona-se novamente o módulo adequado ao caso.
• Rule Logging está desativado: as sessões da firewall só aparecem quando Log firewall traffic está ativo na regra que corresponde efetivamente ao tráfego.
• Local reporting está desativado: em System services > Log settings, o tipo de log necessário deve estar selecionado na coluna Local reporting.
• A ligação continua aberta: normalmente, as sessões da firewall são registadas no evento Destroy, quando a ligação termina. Por isso, uma entrada pode aparecer depois do primeiro estabelecimento da ligação.
• O tráfego não chega à firewall: a ausência de uma entrada de log não prova que a firewall descartou o pacote. O cliente, um router anterior, o DNS ou outro caminho podem impedir a ligação antes disso.
• Firewall Log suppression agrega repetições: os eventos consecutivos da firewall que são suprimidos podem ser agregados em Log occurrence, em vez de aparecerem em muitas linhas individuais.

Se o Log Viewer continuar a mostrar novos eventos do sistema ou da firewall noutros testes, a apresentação está, em princípio, a funcionar. Nesse caso, é mais provável que a causa esteja em Rule Logging, na seleção do módulo, nos filtros, no fim da sessão ou no caminho real dos pacotes. Para esta delimitação, o procedimento Verificar uma regra de firewall com Log Viewer, Policy Tester e Packet Capture é mais adequado.

Gerar um fluxo de teste controlado

Um teste reproduzível é mais fiável do que esperar por tráfego aleatório dos utilizadores. No exemplo seguinte, o cliente de teste tem o endereço IP ajustável 10.20.30.25. No cliente – não na shell da firewall – estabelece-se uma ligação HTTPS curta:

curl -I https://example.com/

example.com é um domínio de exemplo reservado. Também pode ser utilizado um serviço HTTPS conhecido e permitido da própria organização. O importante é que o processo volte a terminar a ligação e que sejam conhecidos a hora, o IP do cliente e o destino.

Em seguida, verifica-se pela seguinte ordem:

1. Em Rules and policies > Firewall rules, confirmar se a regra esperada tem Log firewall traffic ativado.
2. No Log Viewer, executar Reset, selecionar o módulo Firewall e um período adequado e filtrar por 10.20.30.25.
3. Aguardar alguns segundos e atualizar manualmente uma vez, porque o evento da firewall pode aparecer apenas depois de a sessão terminar.
4. Se a entrada não aparecer, utilizar em Diagnostics > Packet capture um filtro restrito, como host 10.20.30.25, e repetir o mesmo teste.

A observação determina o passo seguinte:

• Packet Capture não mostra tráfego de teste: procurar a causa antes da firewall ou no cliente.
• Packet Capture mostra outra Rule ID: verificar a regra que corresponde efetivamente e o respetivo logging.
• Aparecem outros novos eventos no Log Viewer: o Viewer não parou por completo; continuar a verificar os filtros, o tipo de log e a regra específica.
• Packet Capture confirma o fluxo, Rule Logging e Local reporting estão corretos, mas continuam a faltar todos os novos eventos: verificar a build e o processamento local dos logs.

Packet Capture mostra o fluxo de pacotes, mas não repara a apresentação dos logs. A utilização e os valores de estado são explicados em Packet Capture no WebAdmin da Sophos Firewall.

Verificar NC-175936 em SFOS 21.5 MR1 Build 261

A Sophos documenta o erro NC-175936 para SFOS 21.5 MR1 Build 261: o ficheiro /tmp/eventlogs/active.db pode estar em falta, fazendo com que o Log Viewer deixe de mostrar novos dados. Segundo a Sophos, a firewall continua a processar o tráfego e as funções de segurança continuam ativas. Esta afirmação descreve o erro conhecido e não constitui uma confirmação geral do bom estado de uma firewall sem logs.

A atual Sophos Known Issues List não indica um campo inequívoco de versão corrigida para 21.5 MR2. Por isso, o workaround seguinte não deve ser utilizado noutras builds apenas devido a um sintoma semelhante.

Verificações só de leitura na Advanced Shell

Primeiro, registam-se a build completa, a hora, o último evento visível e, em HA, o nó afetado. Se o WebAdmin ainda funcionar, guardam-se garner.log e, se possível, um Consolidated Troubleshooting Report antes da alteração.

Em seguida, estabelece-se ligação através do acesso SSH documentado à Sophos Firewall e abre-se a Advanced Shell. Os comandos seguintes apenas leem o estado do armazenamento, o ficheiro e o log:

df -kh /tmp
ls -l /tmp/eventlogs/active.db
tail -n 200 /log/garner.log

df -kh /tmp mostra se ainda existe espaço livre no sistema de ficheiros. ls -l confirma se active.db existe; se estiver em falta, a shell pode, consoante a build, mostrar uma mensagem como No such file or directory. O garner.log é verificado quanto a erros na hora documentada do teste. Outros nomes de serviços e ficheiros de log são organizados em Atribuir corretamente os logs de serviços da Sophos Firewall.

Se /tmp estiver cheio, o ficheiro existir, a build for diferente ou o sintoma não for inequívoco, não se executa o reinício seguinte. Os ficheiros em /tmp/eventlogs não são eliminados, copiados nem criados manualmente.

Reiniciar o Garner uma única vez e de forma controlada

⚠️ Comando que altera o estado: este workaround aplica-se apenas ao cenário de erro comprovado em SFOS 21.5 MR1 Build 261. Guardar primeiro os logs e o estado do sistema. Num cluster HA, não executar o comando nos dois nós sem uma verificação prévia. Não reiniciar repetidamente o Garner e nunca reparar ou eliminar manualmente active.db.

Para NC-175936, a Sophos indica exatamente este comando na Advanced Shell:

service garner:restart -ds nosync

O comando foi transcrito para este artigo a partir da atual Sophos Known Issues List, mas não foi testado em laboratório numa appliance. Após o reinício único, o ficheiro e as últimas mensagens do Garner voltam a ser verificados apenas em modo de leitura:

ls -l /tmp/eventlogs/active.db
tail -n 50 /log/garner.log

Depois, executar Reset e Refresh no Log Viewer e repetir o mesmo fluxo de teste curto. A medida só é bem-sucedida quando aparece um novo evento com o carimbo de data/hora correspondente. A mera existência de active.db ainda não prova que todo o caminho de logging voltou a funcionar.

Outras builds e falhas recorrentes

A Sophos corrigiu outros erros relacionados com a base de dados do Log Viewer, mas não idênticos. SFOS 22.0 MR1 Build 490 inclui em NC-152553 uma correção para uma falha do mecanismo de recuperação de active.db; NC-169237, relativo à perda de eventos do Log Viewer devido a corrupção da base de dados, está listado para SFOS 21.5 MR2 Build 323 e SFOS 22.0 GA Build 411. Estes Issue IDs não comprovam uma correção para NC-175936 nem determinam automaticamente a causa de uma falha atual.

Numa build mais antiga, planeia-se primeiro um caminho suportado de atualização do firmware SFOS. Numa build atual ou após um reinício do Garner sem sucesso, não se tentam outras intervenções na base de dados ou nos serviços.

Para um caso de suporte, guardam-se pelo menos os seguintes dados:

• modelo da appliance, versão SFOS e build completa;
• em HA, o nó afetado e a respetiva função;
• último carimbo de data/hora visível no Log Viewer e hora do fluxo de teste;
• módulo, filtros, Rule ID, Source, Destination e Service do teste;
• estado de Log firewall traffic e Local reporting;
• resultado do Packet Capture;
• resultado de df -kh /tmp e ls -l /tmp/eventlogs/active.db;
• garner.log, se necessário fwlog.log e iview.log, e, se possível, um CTR antes de outras alterações;
• informação sobre se o reinício do Garner foi executado uma vez e o que mudou depois disso.

Assim, a Sophos consegue distinguir entre erros de apresentação, base de dados, armazenamento, serviço e específicos da versão, sem que tentativas repetidas de reparação ocultem a causa original.