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.

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:

Um fluxo de tráfego individual é afetado: filtrar em Log Viewer por Origem, Destino, Serviço e horário.
Log Viewer não mostra decisão: iniciar Packet Capture com filtro estreito.
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.
Um serviço específico parece instável: observar o ficheiro apropriado em /log com tail -f.
Um erro é esporádico ou requer suporte: preparar janela de tempo, filtro, ficheiro de logs e, se necessário, tcpdump.
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.

Inicie sessão na CLI, escolha 5 Device Management e depois 3 Advanced Shell.
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 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:

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

As associações principais seguem a documentação atual do SFOS 22.0. Em instalações mais antigas ou em ficheiros 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 já não os inclui na lista atual de logs do SFOS 22.0; por isso, não se deve pressupor que existam num build atual.

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

Arranque do sistema: sysinit.log; verificar primeiro em caso de problemas de arranque e Failsafe.
Mensagens do sistema: syslog.log; verificar também a hora, os reinícios e os eventos de interface.
Servidor web do WebAdmin: apache.log, apache_access.log; verificar também Device Access e Local Service ACL.
Aplicação WebAdmin: tomcat.log; verifique também erros de GUI, carga elevada e estado do serviço.
SSH: sshd.log; verificar também Device Access, a rede de origem e a autenticação por chave pública.
Erros de GUI/CLI: error_log.log; verificar também as alterações recentes e as ações efetuadas no navegador ou pelo 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 armazenamento, backup/restore e caso de suporte.
Canal de comunicação entre determinados componentes e os respetivos serviços: garner.log; para Central Management e reporting, verificar também as entradas dos plugins correspondentes.
API: apiparser.log; verificar também validation.log, a ACL da API, o token e a Central Task Queue.
Validação: validation.log, validationError.log; verificar também objetos ou importações com erros.
Licenciamento: licensing.log; verifique também o estado da licença, o Central Sync e o caso especial de Air-Gap.
Atualizações do Sistema: u2d.log; verifique 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.
Processamento geral de firewall: fwlog.log; utilizar também Packet Capture.
Regras NAT: nat_rule.log; verificar também o ID da regra NAT no Log Viewer.
DNAT com Link Load Balancing: verificar também dgd.log quando a seleção de gateway ou link está 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 a Traffic Shaping Policy.
Publicação de host virtual/servidor antigo: vhost.log; verificar também NAT e WAF.
Proteção de servidor web / WAF: reverseproxy.log; verificar também a regra WAF, Hosted address e a acessibilidade do backend.

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 outras, tabelas IP, tabela ARP, 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.

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

Proxy HTTPS: Serviço awarrenhttp, log awarrenhttp.log.
Acesso proxy HTTPS: Log de acesso awarrenhttp, log awarrenhttp_access.log. Em SFOS 22/23, os pedidos individuais do proxy web só aparecem aqui quando awarrenhttp está a funcionar com o debug ativado; seguir o procedimento de recolha abaixo.
Categorização/Reputação Web: Serviço nSXLd, log nSXLd.log.
Atualizações de categorias (SFOS 22/23): ficheiro catUpdateLog – respeitar as maiúsculas e minúsculas, sem o sufixo .log.
Proxy HTTP/FTP herdado: Serviço skein, log skein.log.
Proxy FTP: Serviço ftpproxy, log ftpproxy.log.
Firewall de aplicação Web: Proxy reverso, 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 sites na categoria highly objectionable criminal activity por predefinição e oculta o nome de domínio em registos e relatórios. 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.

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 do utilizador: Servidor de acesso / AAA, log access_server.log.
NTLM / NASM: Serviço nasm, registo nasm.log.
SSO do Chromebook: Back-end do SSO do Chromebook, registo chromebook-sso-backend.log.
SSO OAuth Captive Portal (SFOS 22): log oauth_sso_captive.log.
SSO OAuth WebAdmin (SFOS 22): log oauth_sso_webadmin.log.
SSO OAuth VPN (SFOS 22): log oauth_sso_vpn.log.
OAuth SSO (SFOS 23): oauth_sso_svc.log para os inícios de sessão SSO em WebAdmin, Captive Portal, VPN Portal, IPsec VPN e SSL VPN.
RADIUS SSO: Associação utilizador-IP por accounting em access_server.log. RADIUS SSO com accounting explica a configuração e validação.
STAS: STAS / Contexto Servidor de Acesso, conforme contexto de 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

DNS Serviço: Serviço dnsd, log dnsd.log.
DNS Grabber: Serviço dnsgrabber, log dnsgrabber.log.
DNS Entidade/outros componentes DNS: Serviços entity, eacd; registos entity.log, eacd.log.
DHCP IPv4: Serviço dhcpd, log dhcpd.log.
DHCP IPv6: log dhcpd6.log.
Serviço de rede: Serviço networkd, log networkd.log.
Hosts FQDN: Serviço fqdnd, log fqdnd.log.
Deteção de gateway inativo: Serviço dgd, log dgd.log.
DNS Dinâmico: Cliente DNS Dinâmico, log ddc.log.
Cliente NTP: log ntpclient.log.
Router Advertisement IPv6: Serviço radvd, 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: log staticd.log. A configuração e verificação são explicadas em Configurar uma rota estática na Sophos Firewall.
Instalação de rotas Unicast estáticas IPv4: Serviço zebra, log zebra.log.
Encaminhamento Baseado em Aplicação: Serviço appcached, log appcached.log.
Encaminhamento Multicast: log mrouting.log.
BGP: Serviço bgpd, log bgpd.log. Configurar BGP na Sophos Firewall explica a configuração e a validação; zebra.log ajuda adicionalmente a verificar se uma rota aprendida foi instalada no sistema.
OSPFv2 e OSPFv3: Serviços ospfd e ospf6d, logs ospfd.log e ospf6d.log. O ficheiro adicional zebra.log mostra se a rota dinâmica foi instalada no sistema. Configurar e validar OSPF na Sophos Firewall explica a configuração e a validação.
RIP: Serviço ripd, registo ripd.log. Configurar e validar RIPv2 na Sophos Firewall explica a configuração e a validação; zebra.log mostra também se uma rota aprendida foi instalada no stack de routing.
PIM-SM: Serviço pimd, registo pimd.log. A configuração e a validação são explicadas em Configurar PIM-SM na 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.

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: Gestão Central, registos centralmanagement.log, sophos-central.log.
CSC: Serviços csc, cschelper, csd; registos csc.log, cschelper.log, csd.log.
Security Heartbeat: Serviços heartbeatd, hbtrust; registos heartbeatd.log, hbtrust.log.
Synchronized Application Control: verifique os dados enviados para 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 dos dados enviados para a SophosLabs.
Heartbeat para Central: Serviços fwcm-eventd, fwcm-heartbeatd, fwcm-updaterd; verificar os respetivos logs de serviço.
Executor API Central: Serviço fwcm-api-executor, log fwcm-api-executor.log.
Active Threat Response: contexto ATR; verificar de acordo com 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.

Alta disponibilidade

Status e configuração HA: HA Log da Aplicação, log applog.log.
HA Serviço de Par: Serviço ha_pair, log ha_pair.log.
Túnel HA: Serviço ha_tunnel, log ha_tunnel.log.
Conntrack Sync: Serviço ctsyncd, log ctsyncd.log.
Msync: Serviço msync, log msync.log.
Estabelecimento de HA e alterações de estado: ha.log.
Sincronização de ficheiros de serviços selecionados com o dispositivo Auxiliary: 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, log avd.log.
Atualizações de antivírus: Up2Date AV, log up2date_av.log.
Anti-Spam: Serviço sasi, registo sasi.log.
Sandbox: Serviço sandboxd, log sandboxd.log.
SMTP MTA: Serviço smtpd, log smtpd_main.log.
Erros de SMTP: smtpd Erro/Pânico/Rejeição, registos smtpd_error.log, smtpd_panic.log, smtpd_reject.log.
Proxy SMTP/S legado: Serviços awarrensmtp, awarrenmta; logs awarrensmtp.log, awarrenmta.log. Mail Protection em Legacy mode explica a configuração e o teste end-to-end.
Proxy POP/IMAP: Serviço warren, log warren.log. Analisar POP3 e IMAP na Sophos Firewall explica a configuração e o teste end-to-end.

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: Serviço awed, log awed.log.
Clientes wireless: comunicação entre o cliente e o AP/APX em wc_remote.log.
Hotspot: Serviços hostapd, hotspotd; logs hostapd.log, hotspotd.log.
RED: RED Serviço, log red.log. Consoante o tipo e a instância RED, também podem aparecer red-<serial ID of RED>.log e red-<RED ID>.log.
SNMP: Serviço snmpd, registo snmpd.log.
Serviço Syslog: registo syslog.log.
Licenciamento: Serviço de Licenciamento, log licensing.log.
Atualizações do Sistema: Serviço u2d, log u2d.log.
VMware Tools: Serviço vmtool, 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, log postgres.log.
Postgres: Serviço postgres, log postgres.log.
Base de dados de assinaturas: Serviço sigdb, log sigdb.log.
Base de dados de relatórios: BD de relatórios, log reportdb.log.
Base de dados de migração: migração de relatórios, log reportmigration.log.
Migração da configuração (SFOS 22/23): ficheiro migration.log; não confundir com reportmigration.log, que corresponde à migração dos relatórios.
Garner: Serviço garner, registo garner.log.
iView: Serviço iview, registo 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 atuais do SFOS 22

Os ficheiros seguintes são necessários com menos frequência no troubleshooting diário do tráfego, mas pertencem ao mapeamento atual do SFOS 22. Estão agrupados por função para que não se deduza precipitadamente uma causa apenas pelo nome do ficheiro:

Auditoria, FIPS e acesso ao suporte: configuration-audit.log regista a alteração de configuração, o administrador e a hora; fips.log o arranque em modo FIPS; uma.log o Support Access.
Pipeline de logs e manutenção de dados locais: syslog-ng.log mostra a supressão de eventos consecutivos; reportdb_v9.log pertence à antiga base de dados de relatórios. dbcleanup.log, readobject.log, fstrim.log e logrotate.log abrangem a limpeza da base de dados, a leitura interna de objetos, o trimming do sistema de ficheiros e a rotação de logs.
ATR, NDR e FastPath: atr-service.log mostra o início e a paragem do serviço ATR. ndr.log e ndr_agent.log abrangem a licença NDR, a configuração, o arranque do agente e o processamento de metadados; vfpdf.log aplica-se a metadados NDR nos XGS 88/88w, 108/108w, 118/118w e 128/128w. setup_vf_dpdk.log regista a inicialização da memória FastPath e não se aplica precisamente a estas quatro gamas.
TLS e SSL VPN: httplogd.log mostra ligações HTTPS não desencriptadas no caminho DPI. peruser_cert_sslvpn.log regista certificados SSL VPN gerados por utilizador; openvpn-status0.log, openvpn-status1.log e outros ficheiros numerados mostram ligações SSL VPN ativas por processo.
Rede e HA: dhcprelay.log pertence ao DHCP Relay. ha.log mostra o sucesso ou erro ao estabelecer HA e as alterações de estado; filesync.log a sincronização de ficheiros de serviços selecionados para o dispositivo Auxiliary.
Central, implementação e ZTNA: fwcm-eventd.log, fwcm-heartbeatd.log, fwcm-updaterd.log e fwcm-frpcd.log abrangem informações de zonas e interfaces enviadas ao Central, a ligação, a configuração transmitida e o Fast Reverse Proxy. ssod.log contém informações de firmware e backups do Central, zt.log e zerotouch.log variantes de Zero Touch, ztna-connector.log o ZTNA Connector local.
Backup, firmware, Air Gap e certificados: interfacemapping.log regista o mapeamento 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 juntamente com applog.log a certificados Let’s Encrypt.
Hardware e estado do sistema: npu-startup.log, npu_syslog.log, xgs-healthmond.log, xgs-host.log, xgs-npu-fw.log, xgs-npu-serial.log e xgs-pport-wait.log abrangem arranque, comunicação, firmware, porta série, estado da NPU e criação de interfaces físicas. raid.log mostra o RAID por software, lcd.log o visor de hardware. system-monitor/cpu_trigger.log regista o estado do sistema sob elevada carga de CPU; system-monitor/memory_trigger.log aplica-se no SFOS 22 a elevada carga de memória.
Serviços cloud e de plataforma: iaasd.log regista o provisionamento e a verificação de licenças no Azure, waagent.log o agente Azure e o respetivo Health Monitoring; vmtool.log pertence ao 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

Anote o problema com precisão: hora com fuso horário, cliente, destino, porta, utilizador, ação.
Decida se é tráfego, estado do serviço, alteração de configuração ou sincronização com Central.
Filtrar o Log Viewer por IP de origem, IP de destino, módulo e hora.
Verificar a visibilidade do ID da regra de firewall, do ID da regra NAT, do utilizador, do gateway e dos IDs de política.
Utilizar Packet Capture se o fluxo de pacotes, o caminho de retorno ou a visualização NAT não forem claros.
Verificar o log adequado com tail -f, less ou grep.
Reproduza o problema e documente o momento exato do teste.
Se necessário, ative o Debug apenas para o serviço afetado e apenas brevemente.
Desative o Debug novamente e verifique o espaço de armazenamento.
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

Qual é o ficheiro de log mais importante em Sophos Firewall?

Depende do problema. Para regras de firewall, firewall_rule.log é importante, para NAT nat_rule.log, para IPsec strongswan.log, para SSL VPN sslvpn.log, para IPS e Application Control frequentemente ips.log. Contudo, o Log Viewer ainda é a melhor primeira entrada para ligações simples.

O que é CTR nos logs Sophos Firewall?

CTR em muitos contextos significa Consolidated Troubleshooting Report. Para administradores, o importante é que um CTR ou pacote de logs de resolução de problemas ajuda o suporte, mas não substitui uma descrição clara do erro com hora, IPs afetados, utilizador, nome do túnel, ID da regra e passos de reprodução.

Quando o Advanced Shell é necessário?

A Advanced Shell é útil quando é necessário verificar ficheiros de log locais com tail, grep ou less, monitorizar o estado de um serviço ou quando o Sophos Support precisa de dados de log detalhados. Para muitas verificações iniciais, Log Viewer, Policy Test e Packet Capture em WebAdmin são suficientes.

O log de depuração deve ser deixado ativado permanentemente?

Não. A depuração gera muitos dados e pode consumir espaço de armazenamento. A depuração deve ser usada apenas para o serviço afetado, para um teste curto e reproduzível e com posterior desativação.

Porque não aparecem os eventos de firewall esperados no Log Viewer?

Muitas vezes, Log firewall traffic não está ativo na regra afetada, foi escolhido o período ou filtro errado ou o tráfego não chega à firewall. Se o fluxo de pacotes não estiver claro, Log Viewer e Packet Capture devem ser usados em conjunto.

Os logs locais são melhores que Central Reporting ou Syslog?

São ferramentas diferentes. Os logs locais ajudam na análise detalhada diretamente na firewall. O Central Reporting é adequado para relatórios e históricos do Sophos Fusion. O Syslog é mais adequado para um SIEM ou SOC próprio, ou para armazenamento de longo prazo.