Saltar para o conteudo
Avanet

Sophos Firewall Log Viewer não mostra novos logs

Sophos Firewall

Se o Log Viewer não mostrar novos eventos no SFOS 22, não se deve reiniciar um serviço com base apenas numa suspeita. 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. Em Diagnostics > Packet capture > Configure, definir um filtro BPF restrito, ativar a captura e verificar se o tráfego chega à firewall e qual Rule ID é processada.
  5. Desativar a captura após o teste. 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. No SFOS 22, não utilizar workarounds do Garner ou da base de dados provenientes de versões anteriores. Verificar a maintenance release atual e fornecer os dados de diagnóstico ao Sophos Support se todos os logs locais estiverem parados.
  7. O workaround do Garner mantido abaixo aplica-se exclusivamente ao SFOS 21.5.1 MR1 Build 261 e ao cenário exato documentado.

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.
  • A sessão termina sem um evento Destroy: se, por exemplo, a ligação à Internet falhar, a sessão pode ser encerrada sem qualquer entrada de log. Nesse caso, a entrada não está apenas atrasada: nunca é criada.
  • 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, abrir Diagnostics > Packet capture, clicar em Configure, introduzir o filtro restrito host 10.20.30.25 em Enter BPF string e guardar. Substituir o IP pelo endereço real do cliente de teste.
  5. Ativar Packet capture, repetir o teste uma vez e, em seguida, desativar a captura. Assim, a captura fica limitada ao cliente conhecido e a um período curto.

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. Se o buffer estiver cheio e Wrap capture buffer once full não estiver selecionado, o SFOS interrompe automaticamente a captura; Clear liberta o buffer para outro teste. A utilização e os valores de estado são explicados em Packet Capture no WebAdmin da Sophos Firewall.

Classificar a falha no SFOS 22

A Sophos Known Issues List limita NC-175936 ao SFOS 21.5.1 MR1 Build 261 e afirma explicitamente que o problema está resolvido na versão 22. Por isso, o reinício do Garner associado não é uma via de reparação para o SFOS 22.

As notas de versão do SFOS 22 indicam outras alterações no Logging Framework. O SFOS 22.0 GA Build 411 corrigiu NC-169237, em que a corrupção da base de dados fazia o Log Viewer perder eventos. O SFOS 22.0 MR1 Build 490 corrigiu NC-152553, uma falha no mecanismo de recuperação de active.db. A versão mais recente aí indicada, SFOS 22.0 MR2 Build 546, melhora o desempenho do Log Viewer com NC-181520.

Estas entradas confirmam erros corrigidos, mas não identificam a causa de uma falha atual. No SFOS 22, registar a versão e a build exatas, verificar um caminho de upgrade suportado para a maintenance release atual e não alterar ficheiros da base de dados nem reiniciar um serviço de logging a partir da shell se os eventos continuarem ausentes.

Verificar NC-175936 em SFOS 21.5.1 MR1 Build 261

A Sophos documenta o erro NC-175936 para SFOS 21.5.1 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 Sophos também afirma explicitamente que este problema está resolvido na versão 22. Por isso, o workaround histórico seguinte não deve ser utilizado no SFOS 22 nem noutra build 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.1 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. Um reinício de serviço não pode ser anulado; se o ficheiro continuar em falta ou os eventos não aparecerem, a intervenção termina aqui e o estado registado antes da alteração é entregue ao Sophos Support. 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.

Se o SFOS 22 continuar sem mostrar novos eventos

Se Packet Capture mostrar o fluxo de teste controlado no SFOS 22, Rule Logging e Local reporting estiverem corretos e continuarem a faltar novos eventos em todos os módulos, planeia-se primeiro um caminho suportado de atualização do firmware SFOS para a maintenance release atual. Se o problema persistir na build atual, não se intervém na base de dados nem 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;
  • para o cenário exato de 21.5.1 MR1, 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 pode distinguir entre erros de apresentação, base de dados, armazenamento, serviço e versão sem que tentativas de reparação repetidas ocultem a causa original.