Atribuir logs de serviço de Sophos Firewall

No Sophos Firewall existem três níveis importantes para resolução de problemas: logs de eventos em Log Viewer, ferramentas de diagnóstico em WebAdmin e ficheiros de serviço ou log na firewall. O Log Viewer é ideal para dúvidas rápidas como “a ligação foi permitida ou bloqueada?” Os ficheiros em /log são mais importantes quando um serviço não inicia, um túnel VPN está instável, os filtros da web agem inesperadamente ou o suporte precisa de dados detalhados.

Este artigo classifica os serviços e ficheiros de log mais importantes de acordo com problemas típicos de administração. Também é útil quando o nome de um serviço técnico aparece no painel de controlo, na Advanced Shell ou num caso de suporte e não fica imediatamente claro qual função da firewall está por trás dele. Nomes como zebra, warren, awed, garner ou strongswan não são autoexplicativos no dia a dia.

Seleção de ferramentas e pré-requisitos

Antes de procurar nos ficheiros de log, deve estar claro qual ferramenta fornece a resposta mais rapidamente. Muitos casos já podem ser delimitados com Log Viewer ou Packet Capture. A shell só se torna realmente útil quando é necessário verificar o próprio serviço ou quando o suporte precisa de dados de log detalhados.

Qual ferramenta de resolução de problemas é apropriada?

Nem todos os problemas de firewall começam com uma shell. Muitas vezes, outra ferramenta é mais rápida no início:

• Ligação permitida ou bloqueada? Testar regra de firewall com Log Viewer, Teste de política e Packet Capture.
• Todo o Log Viewer deixou de mostrar novos eventos? Verificar filtros, logging e o workaround do Garner específico da build.
• Toda a firewall reiniciou inesperadamente? Primeiro, classificar o reinício como reboot da appliance, failover HA ou falha de serviço e depois guardar sysinit.log, syslog.log e CTR.
• Os pacotes chegam, mas não está claro se são encaminhados? Utilizar o Packet Capture da Sophos Firewall no WebAdmin.
• A captura deve decorrer durante mais tempo, ser guardada como PCAP ou analisada no Wireshark? Sophos Firewall tcpdump: capturar pacotes por CLI.
• Suspeita-se que uma alteração de configuração seja a causa? Verificar os logs do Audit Trail da Sophos Firewall.
• Uma alteração do Sophos Fusion (anteriormente Sophos Central) está bloqueada? Verificar a fila de tarefas da firewall no Sophos Fusion.
• São necessários relatórios ou histórico no Sophos Fusion? Ativar e operar Sophos Firewall Central Reporting.
• Os logs devem ser enviados a longo prazo para SIEM, SOC ou servidor de log? Enviar Syslog de Sophos Firewall para SIEM.
• O foco são fluxos de tráfego, picos de largura de banda ou padrões de comunicação? Configurar monitorização sFlow em Sophos Firewall.
• Um serviço não funciona ou o suporte precisa de logs? Este artigo.
• Guardar logs locais para Sophos Support ou Avanet? Guardar logs da Sophos Firewall para suporte e análise.
• Preparar um caso de suporte? Abrir um ticket de suporte Sophos: Preparação e portal.

A ordem é importante. O Log Viewer geralmente mostra mais rapidamente qual regra ou módulo tomou a decisão. Packet Capture demonstra o fluxo de pacotes em WebAdmin. tcpdump é útil quando é necessária uma captura mais longa, um ficheiro PCAP ou um filtro CLI muito preciso. Os logs de serviço e depuração ajudam quando um serviço específico é o problema ou quando é necessário recolher dados para o Sophos Support.

Para questões exclusivamente relacionadas com a acessibilidade, Diagnostics > Tools, com Ping, Traceroute e consultas de DNS e rotas, complementa a pesquisa nos logs. Ping verifica a acessibilidade, Traceroute o caminho e uma consulta verifica a resolução de nomes ou a rota. Os comandos básicos de diagnóstico ajudam a escolher a ferramenta; um teste bem-sucedido a partir da firewall não substitui um teste a partir do cliente afetado.

Entrada rápida por sintoma

Se não estiver claro qual log é relevante, será útil começar com o sintoma em vez do nome do serviço.

• Uma única ligação não funciona: primeiro, verificar o Log Viewer com origem, destino, serviço e hora. Em seguida, utilizar Packet Capture, firewall_rule.log e nat_rule.log.
• O túnel VPN está inativo ou instável: verifique o estado da VPN, o IP do peer, a hora e o Log Viewer. Em seguida, verifique strongswan.log, charon.log, sslvpn.log e os dados de diagnóstico IPsec.
• WebAdmin, User Portal ou SSH não são acessíveis: verificar Device Access, Local Service ACL e a zona afetada. Em seguida, utilizar apache.log, tomcat.log, sshd.log e Packet Capture na porta de destino.
• O filtro web, TLS Inspection ou IPS bloqueiam inesperadamente: verificar o módulo no Log Viewer e o ID da política. Em seguida, comparar ips.log, awarrenhttp.log e Packet Capture.
• Uma tarefa do Sophos Fusion está bloqueada: comparar a Central Task Queue com o estado local. Em seguida, verificar centralmanagement.log, sophos-central.log e fwcm-api-executor.log.
• HA comporta-se de forma diferente consoante o nó: identificar o nó ativo, o nó auxiliar e o caminho de tráfego afetado. Em seguida, iniciar sessão diretamente no nó afetado e verificar os logs de HA.
• Os relatórios locais estão em falta ou o armazenamento está cheio: verificar as definições dos relatórios, o espaço disponível e Central Reporting. Em seguida, utilizar reportdb.log, garner.log e a análise de armazenamento.

Esta abordagem evita uma armadilha comum: pesquisar um log de serviço quando primeiro é necessário confirmar a correspondência de regras, Device Access, NAT ou o encaminhamento.

Log Viewer ou ficheiro de log?

O Log Viewer abre na consola WebAdmin no canto superior direito. É atualizado automaticamente, pode ser filtrado por módulo, hora, valores de campo e texto livre, além de poder exportar registos como CSV.

Para proteger nomes de utilizador e endereços IP, MAC e de e-mail na vista diária dos logs, pode utilizar-se Data Anonymization para logs e relatórios locais. O efeito no Log viewer não prova automaticamente que os ficheiros em /log, CTR, Remote Syslog ou Central anonimizam as mesmas identidades; cada caminho de saída é verificado separadamente.

Os logs de resolução de problemas encontram-se no diretório /log. O caminho oficialmente documentado passa pela CLI: iniciar sessão, escolher 5 Device Management e depois 3 Advanced Shell. SSH costuma ser mais confortável para sessões longas com tail, grep ou less. A preparação segura está descrita em Conectar Sophos Firewall por SSH.

Antes de longas sessões na shell, deve ficar claro a partir de que rede de gestão é estabelecida a ligação, se a impressão digital SSH foi verificada e se a Advanced Shell é realmente necessária. Para muitas verificações iniciais, Log Viewer ou Packet Capture em WebAdmin são suficientes.

Como regra geral, esta é a sequência:

1. Um fluxo de tráfego individual é afetado: filtrar em Log Viewer por Origem, Destino, Serviço e horário.
2. Log Viewer não mostra decisão: iniciar Packet Capture com filtro estreito.
3. Packet Capture mostra Incoming, mas não uma decisão clara: verifique ID de regra, ID NAT, ID de firewall 0, caminho de retorno e log apropriado.
4. Um serviço específico parece instável: observar o ficheiro apropriado em /log com tail -f.
5. Um erro é esporádico ou requer suporte: preparar janela de tempo, filtro, ficheiro de logs e, se necessário, tcpdump.
6. Logs normais não são suficientes: ative o Debug apenas para o serviço afetado e por um curto período de tempo.

Isto mantém a análise suficientemente limitada. Primeiro recolhe-se a evidência visível, depois passa-se para o fluxo de pacotes e só então para os registos de serviço ou de depuração. Assim reduz-se o risco de ativar demasiado cedo registos de depuração abrangentes ou de avaliar um ficheiro de log incorreto.

Ler ficheiros de log em Advanced Shell

Antes de examinar /log, o caso de teste deve ser documentado com a maior precisão possível: hora local, IP de origem afetado, IP de destino, porta, utilizador, módulo e comportamento esperado. Estes dados fazem a diferença entre uma análise de log útil e uma longa pesquisa em entradas antigas.

1. Inicie sessão na CLI, escolha 5 Device Management e depois 3 Advanced Shell.
2. Mude para o diretório de log.

cd /log

Comandos úteis:

tail -f firewall_rule.log
tail -f nat_rule.log
grep -i error ips.log
less strongswan.log
service -S | grep ips

Os comandos mais importantes do Advanced Shell:

• Ler ao vivo: tail -f /log/<logfilename>.log, por exemplo tail -f /log/ips.log.
• Ler um ficheiro estático: less /log/<logfilename>.log, por exemplo less /log/ips.log.
• Procurar um termo: grep <keyword> /log/<logfilename>.log, por exemplo grep error /log/ips.log.
• Ler o estado de um serviço: utilizar service -S ou limitar a um nome, por exemplo service -S | grep ips. Esta verificação não altera o serviço.

Para um filtro restrito em tempo real, pode acrescentar a data ou o endereço do cliente:

tail -f /log/ips.log | grep 2026-10-10
tail -f /log/ips.log | grep 192.0.2.10
less /log/ips.log | grep error

A data e 192.0.2.10 são valores de exemplo: substitua-os pela data visível no log ou pelo IP do cliente afetado. tail -f mostra apenas as últimas linhas existentes e as novas entradas, não automaticamente todo o histórico do dia. Para entradas já guardadas, utilize, por exemplo, grep 2026-10-10 /log/ips.log. Se o filtro não apresentar resultados, verifique primeiro o formato da hora, o fuso horário, o IP e o ficheiro de log antes de presumir que não há logging. Em less /log/ips.log, Shift+G avança para o fim do ficheiro, Enter avança uma linha e q termina a visualização; Ctrl+C termina uma captura em curso com tail -f. A pipeline com less fornece uma saída de texto filtrada, não uma vista interativa de less. Estes comandos leem logs, mas não alteram regras nem o estado de Debug.

Para suporte ou análise adicional, não se devem copiar apenas linhas de registo individuais. É melhor ter um intervalo de tempo claro, o teste reproduzido, capturas de ecrã relevantes de Log Viewer ou Packet Capture e, se necessário, um ficheiro de logs completo. Os logs locais são sujeitos a rotação; por isso, os dados importantes devem ser guardados enquanto o evento ainda estiver no período abrangido. O procedimento está descrito em Guardar logs da Sophos Firewall para análise externa.

Descarregar logs de resolução de problemas no WebAdmin

Nem toda a recolha tem de ser montada manualmente em Advanced Shell. O WebAdmin reúne os ficheiros em Diagnostics > Tools.

Na prática existem dois caminhos:

• Ficheiros de log individuais: abrir Diagnostics > Tools > Troubleshooting logs, selecionar os ficheiros de log afetados e descarregá-los como ficheiro comprimido.
• Consolidated Troubleshooting Report (CTR): usar Diagnostics > Tools > Consolidated troubleshooting report quando o suporte precisa de todos os logs, estado do sistema, processos e dados de recursos num único pacote.

Isto é conveniente quando basta um pacote de logs bem delimitado. O CTR é mais adequado quando o Sophos Support precisa de um instantâneo abrangente do sistema. Deve indicar-se um motivo claro, como o número do ticket, a janela temporal ou o sintoma. O relatório é descarregado cifrado; o nome também contém o número de série da firewall e, por isso, não deve constar de anexos públicos.

Por predefinição, um CTR contém 10 000 linhas por service subsystem log. Na Device Console, o valor só pode ser definido entre 250 e 10 000, pelo que apenas pode ser reduzido em relação à predefinição. Os default subsystem logs incluem todas as linhas. Este limite aplica-se apenas ao CTR; os ficheiros individuais completos continuam disponíveis em Troubleshooting logs ou Advanced Shell.

Importante: um pacote de log transferido não substitui dados de contexto. O suporte ainda precisa de horário com fuso horário, IPs afetados, utilizador, nome do túnel, ID da regra, ID NAT e uma breve descrição do que exatamente foi reproduzido.

Em clusters HA é preciso ter também em atenção: logs e relatórios não são simplesmente sincronizados entre Primary e Auxiliary. Cada nó contém os logs do tráfego e dos serviços que ele próprio processou. Em erros específicos de um nó, deve ser verificado o nó afetado.

Compreender a rotação de logs e os dados voláteis

Os Troubleshooting Logs são primeiro criados na memória e depois copiados pela firewall para o sistema de ficheiros. Se a firewall deixar de responder, podem perder-se entradas que ainda não tenham sido copiadas. Um reinício inesperado ou bloqueio não é, por isso, motivo para adiar a preservação de provas; primeiro são guardados os CTR, logs e dados temporais disponíveis.

Cada subsistema tem limites próprios de tamanho e armazenamento, conforme a criticidade e o modelo do appliance. Quando o ficheiro ativo atinge o limite, o SFOS comprime-o como .gz e continua a escrever com o nome original. Se as rotações também atingirem o limite do subsistema, o ficheiro comprimido mais antigo é eliminado primeiro. Por isso, o número de rotações e a profundidade do histórico não são iguais para todos os serviços.

Os ficheiros de log e as rotações .gz não devem ser renomeados nem eliminados manualmente. Para análise de espaço, exportação e comandos de purge documentados, deve seguir-se o procedimento Gerir de forma controlada o armazenamento e os relatórios.

Advanced Shell ou Device Console?

No Sophos Firewall existem duas áreas de consola diferentes que são frequentemente confundidas:

• Device Console: CLI da Sophos para comandos de firewall específicos, por exemplo, prioridade de encaminhamento, rotas IPsec ou opções do sistema.
• Advanced Shell: shell semelhante a Linux para o sistema de ficheiros, logs e comandos só de leitura como tail, grep, less e service -S.

Nem todos os comandos funcionam em ambas as áreas. /log, tail -f, grep e service -S pertencem a Advanced Shell. Os comandos documentados system diagnostics ... para limites CTR, limpeza de logs e debug de subsistemas pertencem a Device Console.

Esta distinção é importante porque muitos erros surgem simplesmente por um comando correto ser introduzido no local errado.

O registo deve estar ativo

Nem todas as informações esperadas aparecem automaticamente.

• Nas regras de firewall, Log firewall traffic deve estar ativo.
• Nas regras de inspeção SSL/TLS, o registo em log deve estar ativado.
• System services > Log settings deve definir quais tipos de registos serão enviados localmente, para Sophos Fusion ou para Syslog.

Para armazenamento de longo prazo, um servidor Syslog ou Sophos Central Firewall Reporting é útil. Como ligar servidores de registo externos ou um SIEM está descrito em Enviar Syslog de Sophos Firewall para SIEM. Para o Sophos Fusion, Ativar Central Firewall Reporting é o procedimento apropriado.

Ativar a depuração apenas de forma direcionada

O log de depuração gera muito mais dados, ocupa armazenamento e pode registar conteúdo confidencial. Por isso, não é um primeiro passo sensato. Primeiro definem-se o log normal, a janela temporal e o teste reproduzível; o debug só é utilizado para o subsistema afetado e pelo tempo estritamente necessário.

A Sophos documenta dois métodos diferentes. A forma de Advanced Shell service <service>:debug -ds nosync alterna o estado e não aceita um argumento separado on ou off. Para um subsistema de serviço suportado, devem preferir-se os comandos explícitos de Device Console documentados pela Sophos: system diagnostics subsystems <subsystem> debug on, reproduzir o problema e recolher os dados, e depois executar system diagnostics subsystems <subsystem> debug off. Para o debug de Packet Capture, por exemplo, o nome do subsistema é Pktcapd. O debug está desativado por predefinição, mas antes de o alterar deve confirmar-se que nenhum outro administrador ou o Sophos Support já está a recolher dados. Registar a alteração e confirmar no fim que o debug está desativado.

Tratar o debug do controlador do sistema CSC como uma alternância separada

O SFOS 22 documenta um comando separado de Device Console para o controlador do sistema (CSC):

system diagnostics subsystems CSC debug

Ao contrário da sintaxe do subsistema de serviço acima, este comando não tem um argumento on ou off: cada execução alterna o debug de CSC. Deve ser usado como alteração controlada e não como consulta de estado:

1. Verificação prévia: Confirmar com os outros administradores e o Sophos Support que o debug de CSC não está já ativo nem faz parte de uma recolha em curso. Registar a firewall ou o nó HA, hora, motivo e janela de recolha prevista. Conservar uma cópia de referência do log CSC relevante antes da alteração. Não executar a alternância apenas para descobrir o seu estado.
2. Ativar e reproduzir: Em Device Console, executar o comando exatamente uma vez. Reproduzir apenas o problema delimitado e registar a hora do teste com fuso horário.
3. Preservar provas: Antes do rollback, descarregar o log de troubleshooting individual relevante ou gerar o CTR e descarregar o ficheiro CTR concluído. Restringir o acesso ao CTR encriptado e a qualquer arquivo de logs porque podem conter dados confidenciais; não eliminar nem substituir as provas necessárias para o caso.
4. Desativar / rollback: Voltar a Device Console e executar exatamente uma vez o mesmo comando. Esta segunda execução planeada volta a desativar o debug de CSC.
5. Verificar: Fazer um teste controlado curto e confirmar nas novas linhas do log CSC que a saída de nível debug terminou e o crescimento do log voltou ao ritmo normal. Registar a hora e o resultado do rollback. Se o estado inicial ou a verificação posterior forem ambíguos, não repetir a alternância; parar e coordenar o estado com o Sophos Support.

⚠️ Debug de WAF e reverseproxy.log: A Sophos corrigiu no SFOS 22.0 MR2 Build 546 o erro NC-177457, no qual uma palavra-passe ficava visível em reverseproxy.log quando o debug de WAF estava ativo. A Sophos não indica o início do intervalo de versões afetadas nem o tipo de palavra-passe. Por isso, logs de debug de WAF, ficheiros de resolução de problemas e ficheiros CTR já criados em builds mais antigos ou desconhecidos devem ser tratados como potencialmente contendo credenciais.

Se for encontrada uma credencial em texto simples: limitar o acesso, documentar o incidente e substituir a credencial afetada. Não eliminar os logs indiscriminadamente antes de esclarecer os requisitos de suporte, análise forense e retenção.

O tópico de registo de depuração e os comandos básicos de CLI são descritos com mais detalhes no artigo Sophos Firewall CLI Resolução de problemas: comandos importantes. Para reiniciar serviços individuais, Reiniciar serviços Sophos Firewall com segurança também é útil.

Erros típicos na busca de registos

Muitas análises de logs demoram não por falta de dados, mas porque se começa demasiado cedo pela ferramenta errada.

• Ativar o Debug diretamente: primeiro verificar o Log Viewer, o log adequado e um teste reproduzível.
• Procurar apenas mensagens de erro: delimitar também origem, destino, utilizador, ID da regra, ID da regra NAT e hora.
• Ignorar Packet Capture: se não estiver claro se os pacotes chegam ou são encaminhados, utilizar Packet Capture numa fase inicial.
• Interpretar Central Reporting como depuração em tempo real: utilizar Central Reporting para histórico e relatórios e os logs locais para análise detalhada.
• Guardar os logs de suporte apenas dias depois: guarde os logs, a hora e os passos de reprodução enquanto o evento ainda pode ser rastreado.
• Deixar o Debug ativo após o teste: desativar novamente o Debug e verificar o espaço de armazenamento.

Um bom caso de resolução de problemas inclui sempre três elementos: um teste rigoroso, a fonte de registo adequada e uma hora documentada. Sem esta base, é possível ver muitas linhas de log, mas não necessariamente a causa.

Ficheiros de log por área funcional

As listas seguintes servem de referência. É melhor selecionar primeiro a área funcional afetada e depois verificar o registo apropriado com uma janela de tempo estreita.

Os mapeamentos principais têm em conta SFOS 22.0 e 23.0; os ficheiros de OAuth SSO diferem entre estas versões, conforme indicado abaixo. Em instalações mais antigas ou em arquivos de suporte antigos também podem aparecer os nomes anteriormente utilizados app-feedback.log, sig_update.log, sessiontbl.log, webproxy.log, fqdndebug.log, ipsec_Test_Connect.log, redis, hotspot.log, awarrenmta_debug.log, smbnetfs.log, snireport.log, confdbstatus.log e crreportdb.log. A Sophos não os inclui nas listas de logs de SFOS 22/23 consideradas aqui; por isso, não se deve pressupor que existem numa build atual.

Os logs gerais do sistema e da configuração são verificados juntamente com os do módulo em questão. Um ficheiro pode servir várias funções: o que importa é o seu significado no problema concreto, não apenas o nome do serviço.

Sistema, gestão e serviços básicos

• Arranque do sistema: sysinit.log; verificar primeiro em caso de problemas de arranque ou de modo Failsafe.
• Mensagens do sistema ao nível do kernel: syslog.log; verificar também a hora, o reboot e os eventos das interfaces. Comparar também os eventos do sistema e os desencadeados por administradores no Log Viewer.
• Servidor web Apache para WebAdmin e User Portal: apache.log, apache_access.log e error_log.log; verificar também Device Access e Local Service ACL.
• Aplicação WebAdmin e User Portal: servidor de aplicações web Jetty, ficheiro de log tomcat.log; verificar também erros da GUI, carga elevada e estado do serviço. O nome do ficheiro não é o nome do servidor de aplicações web atual.
• SSH: sshd.log; verificar também Device Access, rede de origem e início de sessão com chave pública.
• Erros da GUI/CLI: error_log.log; verificar também a alteração recente, o browser e a ação do administrador.
• Alterações de configuração: applog.log, csc.log; verificar também Audit Trail e Config Studio.
• Base de dados de configuração: postgres.log; verificar também o espaço de armazenamento, backup/restauro e o caso de suporte.
• Canal de comunicação entre determinados componentes e os seus serviços: garner.log; para Central Management e Reporting, verificar também as entradas dos respetivos plugins.
• API: apiparser.log; verificar também validation.log, ACL da API, token e Central Task Queue.
• Validação: validation.log, validationError.log; verificar também objetos ou importações com erros.
• Licenciamento: licensing.log; verificar também o estado da licença, Central Sync e o caso especial de Air Gap.
• Atualizações do sistema: u2d.log; verificar também o estado dos padrões, DNS/HTTPS e espaço de armazenamento.

Em problemas de gestão, não se deve verificar apenas o log do WebAdmin. Muitas vezes, Device Access, uma Local Service ACL Exception Rule ou uma rede de origem incorreta determinam se WebAdmin, SSH, User Portal, VPN Portal, DNS ou SNMP são acessíveis. Para esta parte, Proteger o acesso à Sophos Firewall: configurar corretamente Device Access é o melhor ponto de entrada.

Firewall, NAT e Packet Capture

• Correspondência de regras de firewall: firewall_rule.log; verificar também o módulo Firewall no Log Viewer.
• Logs de firewall relativos a ligações: fwlog.log; a sua geração depende do logging da regra de firewall e de Log settings. Utilizar também Packet Capture.
• Regras NAT: nat_rule.log; verificar também NAT Rule ID no Log Viewer.
• DNAT com Link Load Balancing: verificar também dgd.log quando a seleção de gateway ou ligação estiver envolvida.
• Packet Capture no WebAdmin: pktcapd.log; verificar também Diagnostics > Packet capture.
• Gestão de largura de banda / QoS: bwm.log; verificar também Traffic Shaping Policy.
• Virtual Host / publicação de servidores antiga: vhost.log; verificar também NAT e WAF.
• Proteção de servidores web / WAF: reverseproxy.log; alguns detalhes da configuração WAF também constam de firewall_rule.log. Verificar a regra WAF, Hosted address e a acessibilidade do backend.

NAT não se resume a nat_rule.log: a definição NAT de uma ligação IPsec Site-to-Site é verificada em charon.log, e um comando NAT executado através da CLI em applog.log. Assim, é possível distinguir uma configuração de túnel de uma regra NAT normal.

Para problemas de DNAT, verificar sempre a regra de firewall e a regra NAT em conjunto. O NAT apenas traduz endereços; não permite o tráfego. Mais informações: Compreender o NAT na Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Sophos Firewall utiliza, entre outros, IP tables, ARP table, IPset e conntrack para ligações de firewall. Para QoS ou gestão de largura de banda, o IMQ é usado. Estas informações são úteis ao visualizar mensagens de log ou saídas de suporte com termos técnicos do caminho de rede do Linux.

IPS, Application Control e TLS Inspection

• Prevenção contra Invasões: Serviço ips, log ips.log.
• Application Control: Serviço ips / Filtro de Aplicação, log ips.log.
• DPI e TLS Inspection: Mecanismo DPI, log ips.log.
• Antivírus no caminho da rede: Serviço avd, log avd.log.
• Zero-Day Protection / Sandbox: Serviço Sandbox, log sandboxd.log.
• Active Threat Response / X-Ops Threat Feeds: ATR no caminho da rede; primeiro Log Viewer, conforme módulo também ips.log.
• MDR Threat Feeds: estado do feed ATR/MDR, log atr.log; o guia operacional correlaciona Audit ID, Task Queue e prova de tráfego local.
• Atualizações de assinatura: Atualizador de assinatura, log sig_upgrade.log.
• Migração de assinatura: Migração de assinatura, log sigmigration.log.

appcached.log também contém a cache temporária de aplicações categorizadas antes de serem guardadas na base de dados; a sua utilização para Application Based Routing é indicada mais abaixo. Para feeds de ameaças MDR e de terceiros, atr.log mostra o estado da licença e da configuração; por si só, não comprova uma decisão sobre o tráfego. Para IoCs de endereços IP, verifica-se também firewall_rule.log. Para IoCs de domínios ou URLs, os logs de firewall, DNS, inspeção SSL/TLS e proxy web devem ser analisados em conjunto: firewall_rule.log, dnsd.log, ips.log, httplogd.log e, consoante o percurso de processamento, awarrenhttp.log. Os módulos envolvidos implementam Active Threat Response de acordo com o tipo de IoC.

Muitas funções de proteção modernas só conseguem analisar detalhes suficientes quando o tráfego HTTPS é desencriptado. Se a TLS Inspection não for aplicada, o filtro web, o Application Control, o IPS e a análise de malware fornecem resultados menos informativos, consoante o tráfego.

Se não estiver claro se o IPS está ativo, qual política é aplicada ou por que uma assinatura está bloqueada, consulte primeiro Configurar e testar com segurança o IPS Sophos Firewall. ips.log, Log Viewer e Packet Capture podem então ser correlacionados de forma mais direcionada.

Se o problema estiver relacionado com o reconhecimento de aplicações, a filtragem de aplicações ou bloqueios inesperados do Application Control, começar por Configurar e testar o Application Control da Sophos Firewall.

Para a Zero-Day Protection, também é importante verificar se Web Protection, TLS Inspection, tipo e tamanho do ficheiro, política e ação são compatíveis. O artigo operacional adequado é Compreender e operar a Zero-Day Protection da Sophos Firewall. Para Threat Feeds, consultar Configurar e operar os Threat Feeds da Sophos Firewall em segurança. Mais informações sobre TLS Inspection: Implementar a inspeção TLS na Sophos Firewall passo a passo.

Web, Proxy, WAF e filtro web

• HTTP e HTTPS através do proxy web: serviço awarrenhttp, ficheiro de log awarrenhttp.log.
• Acesso ao proxy HTTPS: log de acesso de awarrenhttp, ficheiro de log awarrenhttp_access.log. Em SFOS 22/23, os pedidos individuais ao proxy web só aparecem aqui quando awarrenhttp está a funcionar com Debug ativado; seguir o procedimento de recolha abaixo.
• Categorização / reputação web: serviço nSXLd, ficheiro de log nSXLd.log.
• Atualizações de categorias (SFOS 22/23): ficheiro de log catUpdateLog — respeitar as maiúsculas e minúsculas, sem a extensão .log.
• FTP através do proxy HTTP: serviço skein, ficheiro de log skein.log.
• Proxy FTP: serviço ftpproxy, ficheiro de log ftpproxy.log.
• Web Application Firewall: proxy inverso, ficheiro de log reverseproxy.log.

Para esta recolha do log de acesso, identificar primeiro o nó de firewall/HA afetado, o caso de teste, a hora e uma janela curta de recolha, verificar o espaço em disco e confirmar com os outros administradores ou o suporte que o debug está desativado. Não utilizar o comando de alternância para consultar o estado. Depois, executar service awarrenhttp:debug -ds nosync exatamente uma vez em Advanced Shell, reproduzir o problema delimitado e guardar awarrenhttp_access.log de forma protegida. Em seguida, executar o mesmo comando exatamente uma vez para voltar a desativar o debug. Com um teste breve e controlado, verificar que não surgem novas entradas de debug e que o log normal volta a crescer ao ritmo habitual; documentar o rollback e a verificação do espaço em disco. Se o estado inicial ou a verificação final não forem claros, não continuar a alternar e esclarecer a situação com o suporte. Este método aplica-se aqui a awarrenhttp em SFOS 22/23, não de forma geral a todos os serviços ou versões.

Perante um possível loop de proxy, block_proxy_loop juntamente com debug awarrenhttp ativado brevemente pode produzir Duplicate Via header values, proxy loop. Verificar em segurança as definições HTTP Proxy explica o requisito, o efeito global e o rollback seguro. O debug só fica ativo durante o teste reproduzível.

Se o tráfego web parecer bloqueado em Log Viewer, a causa pode estar em vários módulos: política web, inspeção SSL/TLS, controlo de aplicação, IPS ou WAF. Portanto, selecione sempre o módulo específico no Log Viewer e verifique também o ficheiro de registo apropriado.

A Sophos bloqueia sempre os sites da categoria highly objectionable criminal activity e oculta o nome do domínio nos logs e relatórios. Esta não é uma ação predefinida que se possa escolher livremente. Por isso, se uma entrada nesta área parecer deliberadamente anonimizada, isso pode ser intencional.

Para categorias da web, grupos de URL, políticas da web e alertas instantâneos, consulte Usar categorias da web e alertas instantâneos em Sophos Firewall.

VPN

• IPsec de SFOS v17+: Serviços strongswan, charon; registos strongswan.log, charon.log.
• Específico da ligação IPsec: uma ligação IPsec específica, log /log/ipsec_conn/ipsec_<connectionname>.log.
• IPsec versões anteriores: Serviço IPsec, log ipsec.log.
• Monitorização IPsec: Monitor IPsec, log ipsec_monitor.log.
• XFRM / VPN baseado em rota: Serviço xfrmi, log xfrmi.log.
• SSL VPN: SSL VPN / OpenVPN, registo sslvpn.log.
• Estado da SSL VPN: estado do OpenVPN, log openvpn-status*.log.
• VPN Portal: registo vpnportal.log.
• L2TP: Serviço l2tpd, registo l2tpd.log. L2TP Remote Access na Sophos Firewall explica a configuração e o diagnóstico.
• PPTP: PPTP VPN, registo pptpvpn.log.
• Certificados VPN: Serviços de certificados VPN, log vpncertificate.log.
• Clientless SSL VPN: Acesso sem cliente, log clientless_access.log.

Sophos Firewall usa strongSwan para IPsec VPN e OpenVPN para SSL VPN. Nas questões IPsec, tempo, IP de peer, proposta, sub-redes locais/remotas, NAT-T, encaminhamento e regras de firewall são cruciais.

Estas implementações aplicam-se tanto a Site-to-Site como a Remote Access. /log/ipsec_conn/ipsec_<connectionname>.log contém, em particular, as ações do WebAdmin específicas da ligação para ativar, desativar e ligar o túnel; <connectionname> é substituído pelo nome real da ligação. Para autenticação de utilizadores VPN, verificar também access_server.log e, em caso de problemas do portal, vpnportal.log. Em caso de problemas com o cliente Sophos Connect, o relatório de suporte técnico do cliente também deve ser incluído na recolha de evidências: os logs da firewall, por si só, não mostram todo o estado do cliente. O procedimento de resolução de problemas de IPsec ajuda a analisar em conjunto os resultados do cliente e da firewall.

Para problemas de IPsec, o artigo Resolução de problemas de IPsec em Sophos Firewall é o melhor guia passo a passo. Se for VPN baseado em rotas e rotas manuais IPsec, ajuda Criar rota IPsec em Sophos Firewall.

Autenticação, User Portal e SSO

• Autenticação, autorização e accounting de utilizadores: Access Server / AAA, ficheiro de log access_server.log.
• NTLM / NASM: serviço nasm, ficheiro de log nasm.log.
• Chromebook SSO: backend de Chromebook SSO, ficheiro de log chromebook-sso-backend.log.
• Fluxo de Chromebook SSO: csd.log; distinguir do log do backend.
• OAuth SSO Captive Portal (SFOS 22): ficheiro de log oauth_sso_captive.log.
• OAuth SSO WebAdmin (SFOS 22): ficheiro de log oauth_sso_webadmin.log.
• OAuth SSO VPN (SFOS 22): ficheiro de log oauth_sso_vpn.log.
• OAuth SSO (SFOS 23): oauth_sso_svc.log para inícios de sessão SSO em WebAdmin, Captive Portal, VPN Portal, IPsec VPN e SSL VPN.
• RADIUS SSO: associação entre utilizador e IP através de accounting em access_server.log. A configuração e a validação são explicadas em RADIUS SSO com accounting.
• STAS: contexto de STAS / Access Server, consoante o contexto do serviço e access_server.log.

Nas regras baseadas em utilizadores, verificar sempre primeiro se o utilizador é conhecido. Se Match known users estiver ativo e a autenticação não funcionar, a regra não corresponde. Para logins clássicos no browser, Configurar e testar o Sophos Firewall Captive Portal combina Device Access, a regra de utilizador, Live users, Log Viewer e access_server.log num processo de verificação completo.

Se ainda não for claro se falha a seleção do serviço, a identidade, a Main Group, a quota ou apenas o percurso posterior do tráfego, Resolver sistematicamente erros de autenticação na Sophos Firewall reúne estas camadas num único processo de diagnóstico.

Se o Captive Portal for utilizado com o SSO do Microsoft Entra ID, Configurar o SSO do Microsoft Entra ID para o Captive Portal da Sophos Firewall ajuda a verificar oauth_sso_captive.log (SFOS 22; em SFOS 23: oauth_sso_svc.log), Device Access, grupos e a correspondência das regras seguintes.

DNS, DHCP e rede

• Serviço DNS: serviço dnsd, ficheiro de log dnsd.log.
• Serviço de FQDN com wildcard / DNS Grabber: serviço dnsgrabber, ficheiro de log dnsgrabber.log.
• DNS Entity / outros componentes DNS: serviços entity, eacd; ficheiros de log entity.log, eacd.log.
• DHCP IPv4: serviço dhcpd, ficheiro de log dhcpd.log.
• DHCP IPv6: ficheiro de log dhcpd6.log.
• Interfaces físicas e virtuais: serviço networkd, ficheiro de log networkd.log.
• Hosts FQDN: serviço fqdnd, ficheiro de log fqdnd.log.
• Dead Gateway Detection e gestão de WAN/gateways: serviço dgd, ficheiro de log dgd.log; verificar também failover de ligações, failover de VPN e DNAT.
• DNS dinâmico: cliente de DNS dinâmico, ficheiro de log ddc.log.
• Cliente NTP: ficheiro de log ntpclient.log.
• Router Advertisement IPv6: serviço radvd, ficheiro de log radvd.log.

Os problemas de DNS e DHCP geralmente parecem problemas de firewall. Portanto, o endereço IP, gateway, servidor DNS e se os clientes devem utilizar a firewall como servidor DNS ou DHCP devem ser verificados primeiro.

Se os domínios internos não forem resolvidos corretamente, Definir DNS Request Routes para Sophos Firewall é geralmente relevante. Para opções especiais de DHCP, existe um artigo próprio Definir opções de DHCP em Sophos Firewall.

WAN celular

• Modem WWAN/USB: verifique a ligação e remoção de dispositivos USB em modemd.log.
• Configuração de rede do modem: verificar as interfaces relacionadas com o modem e a configuração IP em networkd.log.
• USB, modem e PPP: verificar as mensagens de Syslog sobre USB, modem e Point-to-Point Protocol em syslog.log.

Em problemas de Cellular WAN, também se deve verificar se o modem é reconhecido, se o PIN/SIM/APN estão corretos e se a firewall cria um gateway adequado.

Encaminhamento

• Rotas unicast estáticas: ficheiro de log staticd.log. A configuração e a verificação são explicadas em Configurar uma rota estática no Sophos Firewall.
• Instalação de rotas unicast IPv4 estáticas: serviço zebra, ficheiro de log zebra.log.
• Encaminhamento baseado em aplicações: serviço appcached, ficheiro de log appcached.log.
• Encaminhamento multicast: ficheiro de log mrouting.log.
• BGP e BGP-IPv6: serviço bgpd, ficheiro de log bgpd.log. A configuração e a validação são explicadas em Configurar BGP no Sophos Firewall; zebra.log também ajuda a verificar se uma rota dinâmica IPv4 ou IPv6 aprendida foi instalada no kernel.
• OSPFv2 e OSPFv3: serviços ospfd e ospf6d, ficheiros de log ospfd.log e ospf6d.log. zebra.log também mostra se a rota dinâmica foi incorporada no sistema. A configuração e a validação são explicadas em Configurar OSPF no Sophos Firewall.
• RIP: serviço ripd, ficheiro de log ripd.log. A configuração e a validação são explicadas em Configurar RIPv2 no Sophos Firewall; zebra.log também mostra se uma rota aprendida foi instalada na pilha de encaminhamento.
• PIM-SM: serviço pimd, ficheiro de log pimd.log. A configuração e a validação são explicadas em Configurar PIM-SM no Sophos Firewall.

Em questões de encaminhamento, verificar também Routing > SD-WAN routes, os gateways e o Packet Capture. O Policy tester não substitui um teste de encaminhamento real.

Para rotas estáticas e dinâmicas, csc.log fornece também informações de opcode e indicações de reinícios de serviços. No contexto de HA, acrescentam-se ha.log, msync.log e applog.log. Para rotas SD-WAN, além de appcached.log, verificam-se também applog.log, csc.log e dgd.log; se IPsec estiver envolvido, incluem-se os logs de IPsec.

Mais informações: Definir prioridade de encaminhamento para Sophos Firewall.

GUI, CLI e acesso ao sistema

Para WebAdmin, SSH, API e serviços de gestão local, a lista básica encontra-se acima em Sistema, gestão e serviços básicos. Se WebAdmin ou SSH não estiverem acessíveis, não se devem verificar apenas apache.log, tomcat.log ou sshd.log. O acesso local é controlado por Administration > Device access e pela Local Service ACL.

Maiores informações: Estabelecer ligação SSH com Sophos Firewall.

Sophos Fusion, Heartbeat e Gestão Central

• Sophos Central Management: Central Management, ficheiros de log centralmanagement.log, sophos-central.log.
• CSC e serviços auxiliares: serviços csc, cschelper, csd; ficheiros de log csc.log, cschelper.log, csd.log. cschelper.log diz respeito a e-mails gerados pelo sistema e a ferramentas de autenticação; csd.log, ao fluxo de Chromebook SSO.
• Security Heartbeat e Synchronized Security: heartbeatd.log contém o estado dos endpoints e informações sobre aplicações enviados à firewall; hbtrust.log, a comunicação com Central. Os serviços chamam-se heartbeatd e hbtrust; verificar também csc.log e applog.log.
• Synchronized Application Control: verificar os dados enviados a SophosLabs em sac-feedback.log.
• Otimização da base de dados SAC (SFOS 22/23): sac-vacuum.log regista a otimização semanal da base de dados de Synchronized Application Control; sac-feedback.log continua a ser o log separado para os dados enviados a SophosLabs.
• Eventos de Central, ligação e transferência de configuração: fwcm-eventd.log mostra as informações de zonas/interfaces enviadas para objetos dinâmicos; fwcm-heartbeatd.log, a ligação; e fwcm-updaterd.log, a configuração transferida. Os serviços chamam-se fwcm-eventd, fwcm-heartbeatd e fwcm-updaterd; nem todos os três são serviços Heartbeat.
• Central API Executor: serviço fwcm-api-executor, ficheiro de log fwcm-api-executor.log.
• Active Threat Response: contexto de ATR; verificar consoante a versão e o módulo.

Em questões relacionadas com o Sophos Fusion, verificar primeiro se a firewall está registada, se os serviços da Central estão ativos e se as ligações DNS/HTTPS de saída estão a funcionar. Se uma alteração efetuada no Sophos Fusion não chegar localmente, comparar a fila de tarefas da firewall no Sophos Fusion com os logs locais. Um estado verde no Sophos Fusion não prova, por si só, que uma política específica tenha sido processada localmente.

Para registo e tokens de acesso, é relevante sophos-central.log; para gestão e reporting ativados, centralmanagement.log. O registo e a anulação do registo são também comparados com applog.log, e as atualizações de firmware com csc.log. hbtrust.log mostra a comunicação; em garner.log, as entradas do plugin SCM pertencem a Central Management e as entradas do plugin CR a Central Reporting. fwcm-api-executor.log também contém análises MDR transferidas para a firewall. A documentação de SFOS 22 considerada designa a plataforma como Sophos Fusion (anteriormente Sophos Central), enquanto a documentação de SFOS 23 a designa como Sophos Central; os nomes existentes de serviços e ficheiros permanecem inalterados.

Alta disponibilidade

• Estado e configuração de HA: log da aplicação HA, ficheiro de log applog.log.
• Deteção do peer HA em QuickHA: serviço ha_pair, ficheiro de log ha_pair.log.
• Túnel SSH entre dispositivos HA através da ligação dedicada: serviço ha_tunnel, ficheiro de log ha_tunnel.log.
• Sincronização de Conntrack: serviço ctsyncd, ficheiro de log ctsyncd.log.
• Msync: serviço msync, ficheiro de log msync.log.
• Estabelecimento de HA e alterações de estado: ha.log.
• Sincronização de ficheiros de serviços selecionados para o dispositivo auxiliar: filesync.log.

Os logs e relatórios HA não são sincronizados entre os dispositivos. Cada nó guarda apenas dados do tráfego que processou. Por isso, Log Viewer e Diagnostics > Tools > Troubleshooting logs devem ser verificados em cada dispositivo afetado. Para obter os troubleshooting logs do dispositivo Auxiliary, é necessário iniciar sessão diretamente na respetiva CLI pelo endereço IP ou FQDN da interface de administração. O Sophos Central Firewall Reporting pode combinar relatórios dos dois dispositivos, mas não substitui ficheiros de troubleshooting locais de cada nó.

Correio e anti-spam

• Antivírus: serviço AV, ficheiro de log avd.log.
• Atualizações de antivírus: Up2Date AV, ficheiro de log up2date_av.log.
• Antispam: serviço sasi, ficheiro de log sasi.log.
• Sandbox: serviço sandboxd, ficheiro de log sandboxd.log.
• SMTP MTA: serviço smtpd, ficheiro de log smtpd_main.log.
• Erros SMTP no modo MTA: smtpd_error.log para erros de análise de e-mail, smtpd_panic.log para erros internos e smtpd_reject.log para e-mails rejeitados; o serviço é smtpd.
• Proxy SMTP/S no modo Legacy: serviços awarrensmtp, awarrenmta; ficheiros de log awarrensmtp.log, awarrenmta.log. A configuração e o teste de ponta a ponta são explicados em Mail Protection no modo Legacy.
• Proxy POP/IMAP: serviço warren, ficheiro de log warren.log. A configuração e o teste de ponta a ponta são explicados em Analisar POP3 e IMAP no Sophos Firewall.

Em problemas de correio, verificar sempre se o modo MTA, a regra de firewall, o DNS, os certificados e as restrições do fornecedor são compatíveis entre si. O procedimento para o fluxo de mensagens, spool, quarentena e retransmissão é descrito em Configurar a proteção de correio no modo MTA na Sophos Firewall.

Sophos Firewall usa Avira e Sophos Antivirus. O serviço anti-spam só é iniciado se houver uma política de spam de entrada ou saída. Esta dependência é importante se sasi.log permanecer vazio ou o serviço anti-spam não estiver em execução.

Wireless, RED, Hotspot e outros serviços

• Controlador wireless e comunicação de AP/APX com a firewall: serviço awed, ficheiro de log awed.log.
• Clientes wireless: comunicação entre o cliente e o AP/APX em wc_remote.log.
• SSID de LocalWifi: serviço hostapd, ficheiro de log hostapd.log; não confundir com eventos de hotspot.
• Eventos de hotspot: serviço hotspotd, ficheiro de log hotspotd.log.
• RED: red.log regista todos os dispositivos RED configurados, incluindo Site-to-Site RED e SD-RED. red-<serial ID of RED>.log pertence ao respetivo dispositivo SD-RED, e red-<RED ID>.log à respetiva configuração de Site-to-Site RED. A RED ID encontra-se em Network > Interfaces, abrindo o Site-to-Site RED em questão. Os marcadores de posição são substituídos pelo número de série real ou pela RED ID real, respetivamente.
• SNMP: serviço snmpd, ficheiro de log snmpd.log.
• Serviço Syslog: ficheiro de log syslog.log.
• Licenciamento: serviço de licenciamento, ficheiro de log licensing.log.
• Atualizações do sistema: serviço u2d, ficheiro de log u2d.log.
• VMware Tools: serviço vmtool, ficheiro de log vmtool.log.

Em questões de licenciamento, Air-Gap ou padrões, licensing.log e u2d.log são os primeiros pontos de referência técnica. Para o procedimento operacional com ficheiro de licença, janela de 180 dias e atualizações manuais de padrões, consulte Operar o licenciamento Air-Gap e as atualizações de padrões na Sophos Firewall.

Base de dados e relatórios

• Base de dados de configuração: Config DB, ficheiro de log postgres.log.
• Postgres: serviço postgres, ficheiro de log postgres.log.
• Base de dados de assinaturas: serviço sigdb, ficheiro de log sigdb.log.
• Base de dados de relatórios: nova base de dados de relatórios a partir de SFOS 21.0, ficheiro de log reportdb.log.
• Base de dados de migração: migração de relatórios, ficheiro de log reportmigration.log.
• Migração de configuração (SFOS 22/23): ficheiro de log migration.log; não confundir com reportmigration.log, destinado à migração de relatórios.
• Garner: serviço garner, ficheiro de log garner.log.
• Visualização de logs no WebAdmin: serviço iview, ficheiro de log iview.log.

Se os relatórios estiverem em falta ou lentos, ou se existirem problemas de espaço de armazenamento, os logs dos relatórios e da base de dados são relevantes. Além disso, verificar se os relatórios são armazenados localmente ou enviados para o Sophos Fusion.

Outros ficheiros de log para SFOS 22/23

Os ficheiros seguintes são necessários com menor frequência na resolução diária de problemas de tráfego, mas fazem parte do mapeamento de SFOS 22/23. Estão agrupados por função para evitar que se deduza precipitadamente uma causa a partir de um nome de ficheiro:

• Auditoria, FIPS e acesso de suporte: configuration-audit.log regista a alteração de configuração, o administrador e o momento; fips.log, o arranque em modo FIPS; e uma.log, o Support Access.
• Pipeline de logs e manutenção de dados locais: syslog-ng.log mostra a supressão de entradas consecutivas do mesmo evento; reportdb_v9.log pertence à antiga base de dados de relatórios. dbcleanup.log diz respeito à limpeza da base de dados no reinício da firewall; readobject.log, à leitura interna de objetos; fstrim.log, ao trimming do sistema de ficheiros; e logrotate.log, à rotação para ficheiros .gz.
• ATR, NDR Essentials e FastPath: atr-service.log mostra o início e o fim do serviço ATR. ndr.log abrange a licença NDR, a configuração e o arranque do agente; ndr_agent.log, o arranque do serviço e o processamento de metadados. vfpdf.log mostra os metadados enviados de FastPath para NDR Essentials exclusivamente nos modelos XGS 88/88w, 108/108w, 118/118w e 128/128w. setup_vf_dpdk.log regista a inicialização da memória de FastPath e não se aplica precisamente a estas quatro séries de modelos.
• TLS e SSL VPN: httplogd.log mostra ligações HTTPS não desencriptadas no percurso DPI. peruser_cert_sslvpn.log regista certificados SSL VPN gerados especificamente para cada utilizador; openvpn-status0.log, openvpn-status1.log e outros ficheiros numerados mostram as ligações SSL VPN ativas por processo.
• Rede e HA: dhcprelay.log pertence ao DHCP Relay. ha.log mostra o sucesso ou a falha no estabelecimento de HA, bem como as alterações de estado; filesync.log, a sincronização de ficheiros de serviços selecionados para o dispositivo auxiliar.
• Central, implementação e ZTNA: fwcm-eventd.log, fwcm-heartbeatd.log e fwcm-updaterd.log abrangem informações de zonas/interfaces, ligação e transferência de configuração. fwcm-frpcd.log diz respeito ao Fast Reverse Proxy ao abrir várias firewalls em simultâneo em Central. ssod.log contém informações de atualização de firmware enviadas a Central e backups da firewall criados nessa plataforma. Para True/Controlled Zero Touch, verificar zt.log e fwcm-heartbeatd.log; para Zero Touch através de USB, zerotouch.log, não fwcm-heartbeatd.log. ztna-connector.log contém IDs da conta do cliente e do conector, estado do conector, túneis ZTNA, aplicações acedidas e atualizações de configuração.
• Backup, firmware, Air Gap e certificados: interfacemapping.log regista a associação de interfaces durante o restauro; legacyconversion.log, backups sem Secure Storage Master Key; e fwmgmt.log, a instalação e gestão de firmware. u2d_airgap.log aplica-se a atualizações Air Gap; cps_messages.log, a erros de hotfix; e letsencrypt.log, em conjunto com applog.log, a certificados Let’s Encrypt.
• API, restauro e gestão de certificados: apiparser.log diz respeito à tradução da API entre JSON e XML; validation.log e validationError.log, à validação da API. Para backup/restauro, verificar também applog.log e postgres.log. vpncertificate.log abrange não apenas certificados VPN, mas também CAs, CSRs e CRLs.
• Hardware e estado do sistema: npu-startup.log mostra o arranque da NPU; npu_syslog.log, os syslogs da NPU; e xgs-host.log, os drivers do host durante o arranque. xgs-npu-fw.log diz respeito à verificação de compatibilidade, atualização e recuperação da NPU; xgs-npu-serial.log, à porta série da NPU; e xgs-pport-wait.log, à criação de interfaces físicas durante o arranque. xgs-healthmond.log abrange a utilização da CPU, a temperatura, a velocidade das ventoinhas e a porta de gestão da NPU. raid.log mostra o RAID por software e lcd.log, o visor do hardware. Em firewalls de hardware, virtuais, de cloud e de software, system-monitor/cpu_trigger.log e system-monitor/memory_trigger.log registam o estado do sistema em caso de carga elevada de CPU ou memória, respetivamente; ambos estão listados para SFOS 22/23.
• Syslogs de FastPath: npu_syslog.log diz respeito a FastPath baseado em NPU e não se aplica aos modelos XGS 88/88w, 108/108w, 118/118w e 128/128w. syslog.log mostra a comunicação do host com FastPath baseado em NPU, bem como Virtual FastPath. Em VMware, além do log de VMware Tools vmtool.log, verificar também syslog.log.
• Serviços de cloud e de plataforma: iaasd.log regista o aprovisionamento da configuração e a verificação de licenças em Azure; waagent.log, o aprovisionamento ao nível do sistema operativo e a monitorização de estado pelo agente de aprovisionamento Azure; vmtool.log pertence a VMware Tools.

A presença de um ficheiro não prova um erro nesse módulo. Primeiro correlacionam-se a hora do evento, o nó afetado, a plataforma, o estado do serviço e um sintoma reproduzível; só depois se pesquisa com um filtro restrito no ficheiro adequado.

Fluxo de análise

1. Anote o problema com precisão: hora com fuso horário, cliente, destino, porta, utilizador, ação.
2. Decida se é tráfego, estado do serviço, alteração de configuração ou sincronização com Central.
3. Filtrar o Log Viewer por IP de origem, IP de destino, módulo e hora.
4. Verificar a visibilidade do ID da regra de firewall, do ID da regra NAT, do utilizador, do gateway e dos IDs de política.
5. Utilizar Packet Capture se o fluxo de pacotes, o caminho de retorno ou a visualização NAT não forem claros.
6. Verificar o log adequado com tail -f, less ou grep.
7. Reproduza o problema e documente o momento exato do teste.
8. Se necessário, ative o Debug apenas para o serviço afetado e apenas brevemente.
9. Desative o Debug novamente e verifique o espaço de armazenamento.
10. Guardar os logs enquanto a reprodução do erro ainda for recente.

Para casos de suporte, todas as mensagens de erro, etapas de reprodução e etapas de resolução de problemas já realizadas também devem ser documentadas. Essas informações aceleram significativamente os casos de suporte. O procedimento adequado está descrito em Abrir um ticket de suporte Sophos: preparação e portal.

Perguntas frequentes