Guardar logs do Sophos Firewall para suporte e análise

Em caso de falhas, problemas de VPN ou eventos de firewall não claros, capturas de tela individuais da interface web muitas vezes não são suficientes. Para uma análise fundamentada, um caso de suporte precisa de marcações de tempo rastreáveis, arquivos de log apropriados e, às vezes, uma captura de pacotes adicional.

O procedimento oficial de transferência e diagnóstico aplica-se ao SFOS 22 e SFOS 23. Os arquivos manuais complementares continuam a ser um método de análise separado, não uma exportação padrão confirmada para ambas as versões. Descreve o caminho oficial por Diagnostics > Tools e distingue-o do método complementar para logs brutos pela Advanced Shell. Para o Sophos Support, o Consolidated Troubleshooting Report (CTR) costuma ser o melhor ponto de partida, pois reúne logs e um snapshot do sistema num arquivo encriptado. Um arquivo /log criado manualmente continua útil quando são necessários logs brutos completos, dados IPsec adicionais ou uma análise interna. No entanto, não é um CTR encriptado nem a exportação padrão documentada pela Sophos.

O procedimento não substitui a primeira delimitação no Log Viewer. Se ainda não estiver claro qual módulo está afetado, a visão geral Solução de problemas do Sophos Firewall: Serviços e Logs pode ajudar inicialmente.

Delimitar primeiro o caso de suporte

Um arquivo grande não é automaticamente um bom pacote de suporte. Primeiro é preciso estabelecer qual teste falhou, quando foi executado e qual componente está provavelmente envolvido.

Analisar primeiro ou já recolher os dados?

Dependendo do tipo de erro, uma abordagem diferente pode ser mais rápida:

• Qual regra, regra NAT ou rota atinge uma tentativa de conexão específica?: Testar regra de firewall com Log Viewer, Policy Test e Packet Capture.
• Qual arquivo de log local pertence a VPN, Web, IPS, GUI ou serviços do sistema?: Solução de problemas do Sophos Firewall: Serviços e Logs.
• O problema é conhecido e os dados precisam ser entregues: seguir este artigo para criar um CTR, logs direcionados ou um arquivo de logs brutos.

Para relatórios históricos ou eventos recorrentes, usar Central Firewall Reporting. A retenção e correlação a longo prazo exigem Syslog ou SIEM. Um arquivo de suporte pontual não substitui nenhum dos dois.

Escolher o pacote de dados conforme o problema

Nem todo problema precisa imediatamente de um arquivo de logs completo. Quanto mais claro o erro for delimitado, menores e mais úteis serão os dados.

• Regra de firewall ou regra NAT é aplicada inesperadamente: Hora, IP de origem, IP de destino, ID da regra, ID NAT, exportação do Log Viewer e, se necessário, Packet Capture.
• Serviço não inicia ou WebAdmin mostra erro: Consolidated Troubleshooting Report, serviço afetado, hora e último passo de configuração.
• Túnel IPsec não é estabelecido ou cai: Arquivo de logs normal, dados de diagnóstico IPsec, IP do peer, redes locais e remotas, momento da tentativa de conexão.
• Tráfego não chega ao destino: Log Viewer, Packet Capture ou, para análises mais longas, tcpdump-PCAP.
• Problema após alteração de configuração: Audit Trail, momento aproximado da alteração, administrador envolvido, objetos afetados e CTR, se necessário.

Para muitos tickets, a combinação de momento do problema, breve descrição do erro, arquivo de logs e uma evidência adicional direcionada é melhor do que um pacote de dados muito amplo sem contexto. Se um ticket oficial da Sophos for criado, também é adequado Abrir um ticket de suporte da Sophos: Preparação e Portal.

Pré-requisitos

Para este guia, você precisará de:

• Acesso administrativo ao Sophos Firewall
• Acesso a Diagnostics > Tools no WebAdmin
• Para arquivos de logs brutos, acesso adicional à Advanced Shell
• Um servidor de destino, portal de suporte ou outro meio seguro de transferir os arquivos
• Espaço de armazenamento suficiente no firewall para os arquivos temporários

Os comandos são executados diretamente no firewall. Portanto, deve-se trabalhar com cuidado e não excluir arquivos, a menos que esteja claro para que são usados.

Se o acesso ao Shell ainda não estiver configurado, o guia Conectar ao Sophos Firewall via SSH explica como estabelecer uma conexão SSH com o firewall.

⚠️ Arquivos de logs e arquivos PCAP podem conter informações sensíveis. Esses arquivos devem ser mantidos no firewall apenas por um curto período, transferidos com segurança e removidos após a entrega bem-sucedida.

Recolher logs

Dependendo do caso de suporte, pode bastar um download direcionado no WebAdmin, um CTR ou um arquivo de logs bruto a partir da Advanced Shell. O processo deve começar pelo menor conjunto de dados que ainda explique o erro de forma limpa.

A retenção local dos logs é limitada pelo espaço atribuído a cada subsistema e pelo modelo do firewall. Quando um ficheiro de log atinge o limite de tamanho, é comprimido com gzip; quando o subsistema atinge o limite de armazenamento, as rotações .gz mais antigas são eliminadas primeiro. Se o firewall deixar de responder, também podem perder-se os dados de log que ainda estão na RAM e não foram escritos no sistema de ficheiros. Por isso, os logs relevantes devem ser guardados o mais rapidamente possível: uma exportação contém apenas os dados ainda disponíveis e não recupera entradas perdidas.

Os logs de diagnóstico são guardados na partição /var e lidos através de /log. Os componentes críticos recebem mais espaço; são conservadas duas ou mais rotações comprimidas, consoante o subsistema. Após a rotação, a firewall continua a escrever com o nome original. Numa XGS Appliance, o histórico disponível depende, por isso, também do modelo e do serviço, não de um período de retenção uniforme.

Caminho padrão: criar CTR no WebAdmin

Para muitos casos de suporte, deve-se criar primeiro o Consolidated Troubleshooting Report. O CTR contém um snapshot do sistema e ficheiros de log num arquivo encriptado. O Sophos Support consegue avaliar este arquivo diretamente no caso de suporte.

Como criar o CTR:

1. Reproduzir o erro, se possível, e anotar a hora exata.
2. Abrir Diagnostics > Tools no WebAdmin.
3. Em Consolidated troubleshooting report, selecionar as opções necessárias.
4. Para um caso de suporte amplo, ativar System snapshot e All log files.
5. Inserir um motivo curto, por exemplo número do ticket, sintoma e janela temporal.
6. Selecionar Generate.
7. Após a criação, selecionar Download.
8. Disponibilizar o ficheiro pelo portal de suporte, pelo upload seguro acordado ou pelo caminho interno de análise.

System snapshot não requer modo debug e regista o estado atual do sistema, incluindo processos ativos e utilização de recursos. O nome documentado é CTR_<APPKEY>_<MM_DD_YY>_<HH_MM_SS>: APPKEY é o número de série da firewall; os restantes campos indicam a data de criação em mês/dia/ano e a hora em hora/minuto/segundo. O próprio nome do ficheiro é, portanto, confidencial. Isto é prático quando várias firewalls ou várias tentativas acabam no mesmo ticket.

O limite de linhas afeta apenas os Service subsystem logs; os Default subsystem logs são incluídos na íntegra, desde que os dados ainda estejam disponíveis. Não verificar um CTR encriptado com o comando tar -tzf apresentado mais adiante: confirmar a conclusão da transferência, um tamanho plausível, o equipamento e a hora do teste, e anexar o ficheiro de forma segura ao caso de suporte. Se a geração ou a transferência falhar, documentar o erro e guardar primeiro os logs individuais afetados, em vez de eliminar logs.

⚠️ O CTR não é um dump completo de dados brutos. Os logs dos subsistemas de serviço contêm no máximo 10.000 linhas por predefinição; este limite aplica-se apenas ao CTR. Para obter logs mais antigos ou completos, descarregar individualmente os Troubleshooting Logs afetados ou guardar os ficheiros pela Advanced Shell.

Verificar o limite de linhas do CTR na Device Console

O limite de linhas dos logs de subsistemas de serviço no CTR pode ser consultado e definido independentemente dos logs brutos. No menu principal da CLI, abrir 4. Device Console. O SFOS 22 e o SFOS 23 permitem entre 250 e 10000 linhas e utilizam 10000 por predefinição:

system diagnostics show ctr-log-lines
system diagnostics ctr-log-lines 5000

Normalmente não é necessário alterar o valor predefinido. 5000 apenas demonstra a sintaxe para um CTR deliberadamente menor: o intervalo é fixo, mas o valor depende do caso de suporte. Antes da alteração, registar o valor atual com show; depois de gerar o CTR, restaurá-lo com o mesmo comando de definição. A alteração afeta apenas futuros ficheiros CTR, não os logs brutos completos, e não recupera dados já eliminados ou substituídos.

Descarregar Troubleshooting Logs individuais

Se o módulo afetado já for conhecido, uma exportação direcionada de logs costuma ser melhor do que um conjunto de dados muito amplo.

1. Abrir Diagnostics > Tools.
2. Em Troubleshooting logs, selecionar os ficheiros de log relevantes.
3. Selecionar Download.
4. Encaminhar o ficheiro comprimido gerado juntamente com hora do erro, caso de teste e firewall afetada.

Este caminho é adequado quando, por exemplo, só é necessário strongswan.log, charon.log, sslvpn.log, reverseproxy.log, applog.log ou outro serviço claramente afetado. Ao contrário do CTR, estes downloads individuais não estão sujeitos ao limite de linhas. A correspondência entre ficheiros e módulos está em Sophos Firewall Troubleshooting: Serviços e Logs.

Abrir o Advanced Shell

Faça login no Sophos Firewall e abra o Advanced Shell:

1. No menu principal da CLI, selecionar 5. Device Management.
2. Em seguida, abrir 3. Advanced Shell.
3. Confirme o acesso, caso o firewall exiba uma consulta adicional.

Após o login, você estará no Shell do firewall. A partir daí, os arquivos de log podem ser arquivados.

Guardar um pequeno excerto de log em tempo real

Na Advanced Shell, acompanhar novas entradas durante um teste delimitado:

cd /log
tail -f /log/charon.log

charon.log é um exemplo concreto para IPsec; para outros problemas, escolher o ficheiro existente adequado na visão geral dos logs de serviços. Anotar início, fim e fuso horário do teste, reproduzir o problema e copiar a saída para um ficheiro de texto protegido no computador de administração. Ctrl+C termina a visualização, não o serviço da firewall. tail -f mostra as últimas linhas existentes e as novas entradas, não uma exportação completa. Se faltarem entradas, verificar primeiro nó, nome do ficheiro, hora e serviço; se necessário, transferir o ficheiro individual completo. Carregar o excerto e o contexto no caso de suporte.

Recolher logs específicos antes de arquivar

Se um problema for reproduzível, ele deve ser desencadeado novamente, se possível, imediatamente antes de arquivar os logs. Isso garante que as entradas relevantes estejam o mais atualizadas possível nos arquivos de log.

Para problemas mais complexos, os logs normais às vezes não são suficientes. Nesse caso, pode ser útil ativar um log de debug para o serviço afetado antes de arquivar. O debug deve ficar ativo apenas de forma direcionada e por pouco tempo e deve ser desativado após a recolha, pois os ficheiros podem crescer rapidamente. A secção Ativar log de debug direcionado explica o procedimento.

Qual arquivo de log pertence a qual módulo do firewall está resumido em Solução de problemas do Sophos Firewall: Serviços e Logs. Esta visão geral é útil se você quiser verificar especificamente se para um problema são mais relevantes os logs de VPN, IPS, Web, Mail, GUI ou do sistema.

Se não for um problema de serviço, mas o fluxo de pacotes em si não estiver claro, um arquivo de logs sozinho muitas vezes não é suficiente. Para testes curtos, Packet Capture no WebAdmin é adequado. Para arquivos PCAP, capturas mais longas ou análises de suporte, tcpdump no Sophos Firewall é a ferramenta apropriada.

Recolher debug com um retorno controlado

O debug está desativado por predefinição. Antes de o alterar, confirmar na mesma com administradores e suporte se já existe uma recolha em curso; documentar nó, espaço livre e uma janela de teste curta. Trabalhar com um único subsistema suportado de cada vez. Os dados de debug estão disponíveis através de transferências individuais, CTR e CLI. Para o exemplo de serviço documentado, executar em 4. Device Console:

Para os outros serviços suportados, a sintaxe é system diagnostics subsystems <subsystem> debug on e system diagnostics subsystems <subsystem> debug off. Substituir <subsystem> por um nome CLI confirmado no build concreto, não por um nome de ficheiro de log. Se já estiver em curso uma recolha debug para outro caso de suporte, não alterar o estado sem acordo.

system diagnostics subsystems Pktcapd debug on

Executar apenas o teste previsto, transferir o log ou o CTR concluído e desativar o debug na mesma Device Console:

system diagnostics subsystems Pktcapd debug off

Registar as saídas de ativação e desativação e os horários; realizar um pequeno teste de controlo para confirmar que não surgem novas entradas de debug e que o crescimento dos logs e o consumo de espaço voltam ao normal. Se o comando for rejeitado, não adivinhar nomes: verificar a sintaxe do build e contactar o suporte. Desativar não elimina os ficheiros recolhidos.

Para o controlador do sistema, o guia de logs indica o mesmo comando, system diagnostics subsystems CSC debug, para ativar e desativar, sem on nem off. Não usar este comutador como consulta de estado nem executá-lo duas vezes sem confirmar o estado. Se o estado inicial ou o retorno não forem claros, não alterar o debug CSC; seguir o procedimento CSC controlado com o suporte. Os nomes de ficheiros de log não são nomes de subsistemas CLI.

A visão geral de diagnóstico do SFOS 22/23 enumera os seguintes Default logs para debug; este grupo também está isento do limite de linhas do CTR:

syslog.log, postgres.log, reportdb.log, applog.log, access_server.log, awarrenhttp.log, awed.log, charon.log, csc.log, garner.log, heartbeatd.log, ips.log, iview.log, msync.log, nSXLd.log, networkd.log, red.log, reverseproxy.log, smtpd_main.log, sslvpn.log, tomcat.log, u2d.log, up2date_av.log, npu-startup.log.prev, npu_syslog.log, syslog-ng.log, xgs-healthmond.log, xgs-host.log, xgs-npu-fw.log, xgs-pport-wait.log.

Os Service logs enumerados são:

awarrenhttp_access.log, httplogd.log, bwm.log, awarrensmtp.log, pktcapd.log, warren.log.

A lista descreve ficheiros suportados para debug, não todos os logs nem a sua presença garantida em todas as plataformas. Verificar os ficheiros NPU e XGS no contexto da XGS Appliance específica. Manter maiúsculas e minúsculas: pktcapd.log não é o parâmetro de comando Pktcapd.

Guardar as provas antes de limpar os logs

Uma limpeza com purge não é necessária para criar um CTR ou transferir ficheiros individuais. O guia de diagnóstico apresenta a limpeza de um subsistema antes de reproduzir o problema apenas como opcional. Primeiro esclarecer as provas, as necessidades de suporte e os requisitos de retenção, e guardar os ficheiros necessários fora da firewall. Ao contrário da remoção posterior dos próprios arquivos, uma purge elimina o histórico de diagnóstico; não existe retorno possível.

Os comandos globais da Device Console são system diagnostics purge-old-logs para todos os logs .gz comprimidos e system diagnostics purge-all-logs para todo o conteúdo dos logs. Segundo a ajuda CLI, uma limpeza completa deixa ficheiros vazios. As ações globais também afetam outros subsistemas e casos de suporte em curso.

Conflito de sintaxe para um subsistema individual: A ajuda de administração SFOS 22/23 indica system diagnostics <subsystem> purge-log e system diagnostics <subsystem> purge-old-log; a ajuda CLI documenta, em contrapartida, system diagnostics subsystems <subsystem> purge-log e system diagnostics subsystems <subsystem> purge-old-log. Antes de uma limpeza autorizada em 4. Device Console, verificar a sintaxe completa e os nomes através da ajuda CLI ou do preenchimento com Tab, e esclarecer o conflito com o suporte. Não experimentar ambas as variantes.

Parar se a sintaxe, a origem dos ficheiros ou uma recolha em curso não forem claras, e usar o procedimento de análise de espaço e limpeza controlada. Após uma ação acordada, verificar espaço livre, novas entradas normais e estado dos serviços; menos espaço ocupado não prova que a causa esteja resolvida. Não eliminar manualmente logs do sistema com rm ou caracteres universais.

Guardar logs brutos pela Advanced Shell

Se o CTR não for suficiente ou forem necessários todos os logs brutos disponíveis nesse momento para análise interna, é possível arquivar manualmente o diretório /log. Este método pela shell não substitui o CTR oficial nem o download individual em Troubleshooting logs. Antes de arquivar, verificar se há espaço livre suficiente em /var:

Antes de usar este método complementar pela shell, verificar os diretórios existentes e o espaço livre. Se /log for uma ligação simbólica, o comando tar abaixo pode arquivar apenas a ligação em vez dos logs: não prosseguir com um arquivo aparentemente concluído; usar a transferência individual oficial ou acordar o método com o suporte. Um diretório que continua a receber escritas também não é uma cópia de segurança consistente. Resolver primeiro caminhos em falta, erros de leitura ou problemas de espaço; não eliminar logs do sistema para libertar espaço.

ls -ld /log
df -h /var

Em seguida, crie um arquivo compactado com os arquivos do diretório /log:

tar -cvzf /var/Sophos-Firewall-Logs.tar.gz -C / log

O comando cria o arquivo:

/var/Sophos-Firewall-Logs.tar.gz

Os componentes principais do comando:

• tar cria um arquivo.
• -c cria um novo arquivo.
• -v exibe os arquivos processados.
• -z compacta o arquivo com gzip.
• -f especifica o nome do arquivo.
• -C / muda para o diretório raiz para o processo de arquivamento.
• log é o diretório com os arquivos de log do Sophos Firewall.

A vantagem de -C / é que o comando funciona independentemente do diretório de trabalho atual. Um cd / anterior não é necessário. Se o arquivo já existir, ele será sobrescrito pelo comando.

Dependendo do tamanho e da carga do firewall, o processo de arquivamento pode demorar algum tempo. A saída de tar mostra, durante o processo, quais arquivos estão sendo escritos no arquivo.

Em seguida, pode-se verificar o tamanho do arquivo:

ls -lh /var/Sophos-Firewall-Logs.tar.gz

Além disso, deve-se verificar rapidamente se o arquivo é legível e realmente contém o diretório de logs:

tar -tzf /var/Sophos-Firewall-Logs.tar.gz

A saída deve mostrar caminhos sob log/. Se o comando relatar um erro ou o arquivo for incomumente pequeno, ele não deve ser transmitido. Primeiro, verifique o espaço livre, permissões de escrita e a execução anterior do tar.

Copiar arquivo de logs para um servidor Linux

Se um servidor Linux for acessível via SSH, o arquivo pode ser transferido com scp.

Exemplo:

scp /var/Sophos-Firewall-Logs.tar.gz root@192.0.2.10:/root/

Aí, o endereço IP, o usuário e o caminho de destino devem ser ajustados ao seu ambiente.

Após a transferência, o arquivo estará no servidor de destino em:

/root/Sophos-Firewall-Logs.tar.gz

A partir daí, ele pode ser transmitido internamente ou disponibilizado para o suporte da Sophos ou Avanet.

Guardar dados de diagnóstico IPsec separadamente

Nos problemas de VPN ou IPsec, também podem ser úteis os dados de ligação de /tmp/ipsec/connections/. Os guias SFOS 22/23 analisados não descrevem este método manual como exportação padrão. Usá-lo apenas para análise interna ou a pedido expresso do suporte e confirmar primeiro que o diretório existe.

Para isso, crie um arquivo separado:

ls -ld /tmp/ipsec/connections
tar -cvzf /var/Sophos-Firewall-IPsec-Connections.tar.gz -C /tmp/ipsec connections

Aqui também, o arquivo gerado pode ser verificado rapidamente:

ls -lh /var/Sophos-Firewall-IPsec-Connections.tar.gz

Este arquivo também pode ser copiado para um servidor de destino via scp:

scp /var/Sophos-Firewall-IPsec-Connections.tar.gz root@192.0.2.10:/root/

Especialmente em caso de erros IPsec, é aconselhável fornecer este arquivo junto com os logs normais do firewall, para que o status do túnel, informações de conexão e entradas de log possam ser avaliados em conjunto.

O que um arquivo de suporte não substitui

Um CTR e um arquivo /log são instantâneos do firewall local. Ajudam em erros de serviço e do sistema, mas não fornecem automaticamente um histórico de longo prazo nem provam que um pacote específico atravessou o firewall. Para histórico e pesquisa, usar Central Firewall Reporting ou Syslog e SIEM. As alterações de configuração podem ser rastreadas de forma mais direta nos Audit Trail Logs.

Tratar capturas de pacotes separadamente

Arquivos de logs e capturas de pacotes são evidências diferentes. O arquivo de logs mostra mensagens de serviço, erros, estados de VPN e eventos do sistema. Um Packet Capture ou tcpdump mostra, por outro lado, se os pacotes realmente chegam, são encaminhados ou se as respostas estão faltando.

Para casos de suporte, não se deve enviar capturas de pacotes sem filtro. É melhor:

1. Anotar o caso de teste com IP de origem, IP de destino, porta, protocolo e hora.
2. Primeiro verificar o Log Viewer e o WebAdmin Packet Capture, se isso for suficiente.
3. Somente se necessário, criar uma captura tcpdump restrita como PCAP.
4. Transferir o arquivo PCAP com segurança.
5. Remover o arquivo PCAP do firewall após a transferência bem-sucedida.

O arquivo PCAP não pertence ao arquivo /log, mas é criado e transferido separadamente. Isso mantém claro qual arquivo contém logs de serviço e qual arquivo contém pacotes de rede.

Segurança e privacidade

Arquivos de log podem conter informações sensíveis, como:

• Endereços IP públicos e internos
• Nomes de usuário
• Nomes de host
• Informações de VPN
• Mensagens de erro com detalhes técnicos
• Indicações de estruturas de rede internas

Arquivos de logs devem, portanto, ser transmitidos apenas por canais seguros e disponibilizados apenas para pessoas ou organizações envolvidas na análise. Se os logs forem enviados a um parceiro externo, deve-se primeiro verificar internamente se a transmissão está de acordo com as políticas de privacidade e segurança da própria organização.

Em clusters HA, os logs e relatórios não são sincronizados automaticamente entre as appliances Primary e Auxiliary. Cada appliance contém os logs e relatórios do tráfego que processa. Em problemas de HA ou períodos que incluam um failover, registar de que nó veio o arquivo e se também são necessários logs do segundo nó.

Remover arquivos temporários

Depois da transferência, verificar o arquivo no sistema de destino e removê-lo do firewall para libertar o espaço temporário. Os comandos seguintes removem apenas os nomes fixos criados neste guia:

rm /var/Sophos-Firewall-Logs.tar.gz

Se também foi criado um arquivo IPsec separado, ele também deve ser removido:

rm /var/Sophos-Firewall-IPsec-Connections.tar.gz

Antes de excluir, deve-se verificar se os arquivos chegaram com sucesso ao sistema de destino.

Lista de verificação para casos de suporte

• Problema brevemente descrito: O que não funciona, desde quando, com que frequência?
• Hora exata com fuso horário anotada.
• IP de origem, IP de destino, usuário, serviço ou nome do túnel afetado anotado.
• Módulo relevante verificado no Log Viewer.
• Se necessário: Debug ativado apenas brevemente e desativado novamente.
• CTR criado em Diagnostics > Tools quando o Sophos Support ou um snapshot do sistema é necessário.
• Se necessário, Troubleshooting Logs individuais ou um arquivo completo de /log criado.
• Para problemas IPsec, dados de diagnóstico IPsec também guardados.
• Para problemas de fluxo de pacotes, Packet Capture ou tcpdump criado separadamente.
• Verificados os logs reais com tar -tzf apenas nos arquivos gzip manuais; no CTR encriptado, confirmados transferência, equipamento e hora.
• Em HA, verificado de que nó vieram os logs.
• Arquivo e PCAP transmitidos apenas por canais seguros.
• Arquivos temporários no firewall removidos após a transferência bem-sucedida.

FAQ