Resolução de problemas na CLI da Sophos Firewall: comandos importantes

Na resolução de problemas da Sophos Firewall, o Log Viewer é frequentemente suficiente para uma primeira análise. Quando um serviço não inicia corretamente, as ligações VPN estão instáveis, alguns pacotes não chegam ao destino ou o suporte necessita de dados detalhados, a CLI torna-se importante.

Esta visão geral apresenta os comandos mais importantes para o dia a dia: onde são executados, o que mostram e quando é preferível consultar um artigo especializado. Para garantir um acesso seguro por SSH, deve começar-se por verificar como estabelecer ligação à Sophos Firewall por SSH. Uma chave pública, a verificação da chave do host e uma autorização de Device Access restrita são mais importantes do que conseguir iniciar sessão rapidamente a partir de qualquer origem.

⚠️ Importante: Os comandos da CLI e da Advanced Shell só devem ser executados a partir de redes de administração fidedignas e com um objetivo claro. Em especial, o debug, o tcpdump, as operações sobre ficheiros e os comandos de serviço podem afetar o espaço de armazenamento, o desempenho ou as ligações em curso.

Primeiro o WebAdmin, depois a CLI

A CLI nem sempre é o ponto de partida mais rápido. Para correspondência de regras, NAT ou ligações individuais, o Log Viewer, o Policy Test e o Packet Capture no WebAdmin permitem muitas vezes obter um diagnóstico claro mais depressa.

Bons pontos de partida:

• Que regra de firewall é aplicada? Utilizar primeiro o Log Viewer, o Policy Test e o Packet Capture. A CLI só é necessária quando o Log Viewer não apresenta detalhes suficientes ou são necessários logs em tempo real.
• Os pacotes chegam à firewall? Utilizar primeiro o Packet Capture no WebAdmin. A CLI é útil quando é necessária uma captura mais restrita ou um ficheiro PCAP para o suporte.
• Existe um problema com um serviço? Verificar primeiro o Dashboard, o Log Viewer e os logs do serviço. A CLI torna-se importante quando é necessário consultar diretamente o estado do serviço, o debug ou os ficheiros de log.
• Foi efetuada alguma alteração? Verificar primeiro os Audit Trail Logs. Depois, a CLI ajuda a comparar uma diferença de configuração com logs ou cópias de segurança.

O objetivo não é entrar na Advanced Shell o mais depressa possível. É preferível seguir um processo compreensível: verificar primeiro os eventos visíveis e, em seguida, abrir especificamente o ficheiro de log ou a captura adequada.

Documentar os resultados da CLI de forma útil

Os resultados da CLI só são úteis se mais tarde ainda for claro a que teste pertencem. Mensagens de erro isoladas, copiadas sem intervalo de tempo, endereços IP ou função afetada, originam frequentemente pedidos de esclarecimento e análises repetidas.

Normalmente, basta uma nota breve por teste:

• Intervalo de tempo: Início, fim e fuso horário do teste.
• Fluxo de teste: IP de origem, IP de destino ou FQDN, porta, utilizador ou peer VPN.
• Ferramenta: Device Console, Advanced Shell, Log Viewer ou Packet Capture.
• Comando ou filtro: Comando executado, termo de pesquisa utilizado no grep ou filtro da captura.
• Resultado: Correspondência, mensagem de erro, entrada de log em falta, pacote visível ou pacote não visível.
• Conclusão seguinte: Por exemplo, problema de regra, problema de DNS, caminho de retorno, erro de serviço ou caso de suporte.

Antes de partilhar os resultados com o suporte, a Avanet ou parceiros externos, deve verificar-se se contêm dados sensíveis: endereços IP públicos, nomes de host internos, nomes de utilizador, parâmetros VPN, números de série, tokens, endereços de e-mail ou designações de clientes. Uma análise técnica não exige que os dados sejam distribuídos de forma indiscriminada; o importante é fornecer o menor excerto que comprove o diagnóstico.

Antes do primeiro comando

A resolução de problemas através da CLI é muito mais fiável quando o contexto está definido antes do primeiro comando. Caso contrário, surgem rapidamente excertos de log sem referência temporal, capturas demasiado abrangentes ou logs de debug que mais tarde já não podem ser associados claramente ao teste.

Antes de realizar testes na CLI em produção, deve registar-se:

• Hora do problema: Permite pesquisar os logs especificamente no intervalo do teste.
• IP de origem, IP de destino e porta: O grep, o tcpdump e o Packet Capture mantêm-se restritos e legíveis.
• Utilizador ou peer afetado: A autenticação, a VPN e o User Matching podem ser associados mais facilmente.
• Módulo esperado: Procura-se primeiro no ficheiro de log adequado, em vez de pesquisar todos os logs.
• Ação planeada: O debug, a verificação de um serviço ou uma captura não ficam ativos inadvertidamente.
• Reversão ou critério de interrupção: O teste é terminado em caso de carga, armazenamento cheio ou efeitos secundários.
• Cópia de segurança atual em trabalhos que envolvam alterações: Os reinícios de serviços ou as alterações de configuração podem ser protegidos de forma adequada.

O primeiro passo deve ser, sempre que possível, apenas de leitura: verificar o Log Viewer, consultar o ficheiro de log adequado, ler service -S ou iniciar uma captura restrita. Os reinícios, o modo de debug e as capturas abrangentes só devem ser realizados posteriormente, numa janela de teste planeada.

Em clusters HA, também deve estar claro qual é o equipamento que se encontra ativo. Os logs, o debug e as capturas devem ser verificados no nó por onde passa efetivamente o tráfego em causa.

Executar um reinício completo apenas como ação planeada

Um reinício completo não é um comando de diagnóstico. Primeiro, preservam-se os logs relevantes, a hora do sistema, o uptime, as funções HA e o estado atual da falha. Se apenas o WebAdmin ou um único serviço estiver afetado, verifica-se se basta um reinício direcionado do WebAdmin ou um reinício do serviço.

O SFOS 22 documenta a seguinte sintaxe na Device Console:

system restart [all]

Os parênteses retos não fazem parte do comando, mas indicam o argumento opcional all. Primeiro, verifica-se a forma disponibilizada pelo build instalado com system restart ?. O comando reinicia a firewall e interrompe sessões, túneis VPN e o acesso de gestão. Não existe rollback na CLI após a execução, pelo que a janela de manutenção, o acesso à consola e um caminho de retorno à gestão testado devem estar preparados antes da confirmação.

Segundo a Sophos, system restart provoca um failover num cluster HA. Isto não garante ligações sem interrupções. O peer, a sincronização, as funções e a ligação HA devem estar estáveis primeiro. Após o reinício, verificam-se ambos os nós, as funções, a sincronização, o uptime, WAN, routing, DNS, VPN, serviços publicados e um fluxo real de aplicação. Um arranque bem-sucedido não prova que a causa original foi resolvida.

Encerrar apenas com um caminho de arranque preparado

Para um encerramento controlado, utiliza-se exatamente este comando na Device Console:

system shutdown

A Sophos não documenta opções para este comando. Por isso, não se acrescenta all, um nome de nó ou um suposto modificador HA à sintaxe. Antes da confirmação, preservam-se os logs e a configuração, informam-se as equipas dependentes e define-se como a appliance será novamente ligada através de acesso físico, gestão remota ou plataforma de virtualização. A página shutdown não garante qualquer comportamento HA; assim, um nó do cluster só é encerrado segundo o procedimento de manutenção HA previsto e o peer é depois verificado explicitamente.

Device Console ou Advanced Shell?

A Sophos Firewall tem duas áreas de consola distintas. Muitos erros ocorrem porque um comando é introduzido na área errada.

As áreas têm funções diferentes:

• Device Console: CLI da Sophos para comandos de rede, sistema e diagnóstico. Os comandos típicos incluem ping, dnslookup, traceroute, tcpdump, drop-packet-capture e show.
• Advanced Shell: shell semelhante a Linux com acesso completo aos componentes do sistema. Este artigo limita-a aos comandos de diagnóstico documentados pela Sophos: cd /log, tail, grep, less e service -S.

Depois de iniciar sessão por SSH, a firewall apresenta primeiro o menu da consola. Para a Device Console, seleciona-se normalmente 4. Device Console. Para a Advanced Shell, utiliza-se 5. Device Management > 3. Advanced Shell.

A Device Console reúne em advanced-firewall os parâmetros globais de inspeção de pacotes, TCP, UDP, acesso WAN e caminhos especiais. Os seus efeitos e um procedimento de alteração seguro são explicados em Verificar Advanced Firewall Settings em segurança.

O teste DNS mostra bem por que razão o ambiente da consola é importante. Na Device Console, o comando oficialmente documentado é:

dnslookup host example.com

example.com é um valor de documentação seguro; num teste real, deve ser substituído pelo FQDN afetado. A resposta confirma apenas a resolução do ponto de vista da firewall. Para uma falha no cliente, devem também verificar-se o servidor DNS, a resposta e o caminho de rede desse cliente.

A ajuda oficial da CLI da Sophos suporta Tab e ? para verificar a sintaxe. Isto é útil na Device Console, porque os comandos não têm todos a mesma estrutura.

Na Device Console, em especial, não se deve executar um comando incompleto ou baseado numa suposição. A Sophos alerta que um comando incompleto pode bloquear o access_server. Por isso, deve começar-se por consultar a sintaxe com Tab ou ? e só depois executar conscientemente o comando completo.

As alterações de configuração efetuadas diretamente na Advanced Shell não são persistentes nem são incluídas nas cópias de segurança. Por esse motivo, neste artigo a Advanced Shell é utilizada apenas para comandos de diagnóstico.

Antes do acesso de emergência: Obter aprovação explícita para o objetivo, a pessoa responsável, a appliance afetada e uma janela de emergência curta com hora de fim e critério de interrupção; prever a interrupção do encaminhamento para a Internet. Abrir efetivamente primeiro um caminho de recuperação independente e verificar o acesso de administração, por exemplo através de uma consola local, da consola da plataforma de virtualização ou de gestão fora de banda. Este acesso não pode depender do caminho de rede avariado nem do modo de emergência e deve continuar disponível para desativar o modo. Não ativar sem aprovação ou sem um caminho de recuperação independente funcional; acordar primeiro a recuperação com a pessoa responsável ou o Sophos Support.

Um comando especial para situações de emergência é system appliance_access enable. Este comando substitui a configuração de Device Access e permite o acesso a todos os serviços locais da firewall, incluindo serviços legacy como Telnet. Importante: enquanto este modo estiver ativo, a firewall deixa de encaminhar tráfego de saída para a Internet. Não se trata de um passo normal de resolução de problemas, mas apenas de uma medida de emergência de curta duração. Antes de o ativar, verificar o estado:

O default documentado é Disable. Com enable, todas as portas aceitam ligações de entrada e a restrição normal de alcance do Device Access é temporariamente removida. A autenticação de cada serviço continua a ser um controlo separado, mas não torna esta exposição ampla inofensiva.

system appliance_access show

Assim que o acesso completo de administração previsto estiver restabelecido, desativar imediatamente o modo de emergência em 4. Device Console e verificar novamente o estado; não esperar pela conclusão de outros diagnósticos. Desativá-lo também através do caminho de recuperação independente preparado se o procedimento for interrompido ou se for atingida a hora de fim aprovada:

system appliance_access disable
system appliance_access show

Depois, show deve confirmar Disable. Testar também um novo início de sessão no WebAdmin ou por SSH a partir da rede de administração prevista, sob as regras normais de Device Access, e confirmar que os acessos anteriormente bloqueados continuam bloqueados. A partir de um cliente afetado atrás da firewall, testar uma ligação real de saída para a Internet, por exemplo um pedido HTTPS para um destino aprovado, e verificar uma resposta bem-sucedida; um ping a partir da firewall ou apenas show não comprovam que o encaminhamento foi restabelecido. Se as verificações falharem ou o estado não for claro, não encerrar o caso como resolvido: manter aberto o caminho de recuperação independente, guardar a resposta da CLI e os resultados do teste e coordenar com a pessoa responsável ou o Sophos Support, em vez de reativar o acesso de emergência abrangente como solução permanente.

Se um comando não for reconhecido, deve verificar-se primeiro a área da consola. É mais provável estar na área errada do que existir um problema com o próprio comando.

Verificar logs na Advanced Shell

Os principais ficheiros de log encontram-se em /log. A Sophos documenta primeiro a mudança para este diretório na Advanced Shell:

cd /log

Comandos básicos úteis:

• Seguir um log em direto: tail -f ips.log. Manter o resultado contínuo aberto apenas durante a janela de teste registada.
• Ler um ficheiro de log: less ips.log. As linhas são apresentadas por secções.
• Pesquisar um termo: grep error ips.log. Adaptar o termo e o ficheiro ao problema.

A correspondência entre cada ficheiro de log e o respetivo módulo está resumida em Resolução de problemas da Sophos Firewall: serviços e logs.

Ao consultar logs em tempo real, o período de teste deve ser curto e a hora deve ser registada. Isto é particularmente importante quando mais tarde é necessário enviar um arquivo de logs ao suporte da Sophos ou à Avanet.

Device Console para verificações rápidas da rede

A Device Console é adequada para testes rápidos a partir da perspetiva da firewall. Permite verificar se o DNS, o encaminhamento ou a conectividade funcionam de forma geral.

Verificações rápidas:

• Verificar a conectividade com um host: ping 192.0.2.10 count 4 verifica a conectividade ICMP.
• Verificar o DNS na Device Console: dnslookup host example.com verifica a resolução de nomes a partir da perspetiva da firewall.
• Verificar a rota: traceroute 192.0.2.10 mostra o caminho até ao destino.
• Consultar o estado das interfaces: show interfaces mostra informações sobre as interfaces.
• Iniciar uma captura de pacotes descartados: drop-packet-capture 'host 192.0.2.10' mostra pacotes descartados por regras de firewall.
• Iniciar uma captura de pacotes: tcpdump 'host 192.0.2.10 and port 443' verifica se os pacotes são visíveis na firewall.

Para IPv6, estão disponíveis os comandos equivalentes ping6, dnslookup6 e traceroute6.

tcpdump e drop-packet-capture continuam a ser executados até serem parados com Ctrl+C. Definir primeiro o filtro e a janela de teste, observar o resultado e parar a captura imediatamente depois. Estes comandos não alteram a configuração, mas a carga depende do volume de tráfego, da abrangência do filtro e do tempo de execução.

O drop-packet-capture é particularmente útil quando não é claro se a firewall está a descartar pacotes ativamente. No entanto, não substitui uma análise da aplicação. Se um servidor responder, mas a aplicação continuar sem funcionar, é também necessário verificar o Log Viewer, o NAT, o Packet Capture ou os logs da aplicação.

Para capturas mais longas e ficheiros PCAP, é preferível consultar o artigo específico Sophos Firewall: recolher logs com TCPDump para análise. Também deve ser planeado o tamanho máximo do ficheiro, o local onde será guardado e a forma segura de o transferir.

Verificações de rede no WebAdmin sem CLI

Em Diagnostics > Tools, é possível responder às mesmas questões básicas sem acesso à consola. O Ping permite selecionar IPv4 ou IPv6, a interface de saída e o tamanho do pacote. A Sophos utiliza 32 bytes por predefinição e permite valores entre 1 e 65 507 bytes. Um ping bem-sucedido confirma a conectividade ICMP a partir da interface selecionada da firewall, mas não o funcionamento de um serviço de aplicação.

Para o Ping em SFOS 22 e SFOS 23, IP address or hostname pode conter um endereço IPv4, um endereço IPv6 ou um FQDN. IP family define a família de endereços, Interface a interface de saída e Size o tamanho do pacote. No caso de um FQDN, é também necessária a resolução de nomes; para isolar um problema de DNS, comparar o mesmo teste utilizando também o endereço IP esperado.

O resultado do Ping mostra se chegam respostas, quantos pacotes foram enviados e recebidos, a perda de pacotes e o tempo de ida e volta (RTT). O RTT é o tempo da troca de pedido e resposta, não o tempo de trânsito num único sentido. Se não chegar nenhuma resposta, é apresentada uma perda de pacotes de 100 por cento. Isto, por si só, não prova que o host esteja desligado: verificar o endereço de destino, a interface selecionada, o routing e se o ICMP é permitido e, se necessário, utilizar um Packet Capture restrito. Mesmo um teste bem-sucedido deve corresponder ao fluxo real da aplicação.

O Traceroute também aceita IPv4, IPv6 ou um FQDN e uma interface de saída escolhida conscientemente. A ausência de resposta de hops individuais não prova uma interrupção se hops posteriores ou o destino responderem. Para analisar um caminho, consideram-se em conjunto a conectividade do destino, o último hop que responde e o fluxo de pacotes medido em paralelo.

No WebAdmin, em Diagnostics > Tools > Traceroute, definir o destino em IP address or hostname, a família de endereços em IP version e a interface de saída em Interface; iniciar a consulta com Traceroute. Para SFOS 22 e SFOS 23, a Sophos descreve o resultado como apresentando os routers percorridos, o número máximo de hops e o tempo total de retorno do pacote em milissegundos. O número máximo de hops limita a pesquisa do caminho; não comprova que o destino tenha sido alcançado. Os valores de tempo descrevem as respostas de diagnóstico e não comprovam o débito da aplicação. Em 4. Device Console, traceroute6 2001:db8::10 complementa o exemplo IPv4 acima; substituir o endereço de documentação pelo endereço IPv6 de destino real.

As designações Name lookup e Lookup using all configured servers utilizadas abaixo aplicam-se ao SFOS 22. As designações alteradas no SFOS 23, DNS lookup e All configured servers, bem como as opções adicionais de servidor e os respetivos pré-requisitos, são explicadas em Comparar resolvers individuais em Diagnostics.

Name lookup consulta um servidor DNS selecionado. Lookup using all configured servers permite comparar todos os servidores DNS configurados na firewall e os respetivos tempos de resposta. Um único resultado rápido ainda não justifica alterar a prioridade DNS; o conteúdo da resposta, a fiabilidade e o caminho do cliente afetado também devem estar corretos.

Route lookup mostra por que interface a firewall encaminharia um destino IPv4 ou IPv6. Não demonstra a regra de firewall, NAT, a decisão SD-WAN nem um caminho de retorno funcional. A validação prossegue, por isso, com uma ligação real, Connection List ou Packet Capture.

Verificar ligações sem alterar o respetivo estado

Filtrar as ligações IPv4 e IPv6 atuais em Current activities > Live connections e Diagnostics > Connection list. A Connection list mostra, entre outros dados, interfaces de entrada e saída, origem e destino, Rule ID, NAT ID, endereços traduzidos, estado e contadores Rx/Tx. É um ponto de partida melhor do que uma ferramenta Advanced Shell não documentada.

Na Device Console, também está documentado este utilitário de ligações:

system diagnostics utilities connections

Antes da execução, verificar os argumentos disponíveis com system diagnostics utilities connections ?. Como a Connection list é um instantâneo, reproduzir o fluxo de teste enquanto se atualiza a vista. Se a ligação continuar ausente, executar um Packet Capture restrito; se aparecer, prosseguir com Rule ID, NAT ID, interfaces, tradução e contadores de resposta.

Verificar o espaço de armazenamento e o estado do sistema

Antes de ativar logs de debug, gerar grandes arquivos de logs ou realizar capturas prolongadas, deve verificar-se o espaço de armazenamento livre.

A Device Console disponibiliza verificações de sistema apenas de leitura e oficialmente documentadas:

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk
system diagnostics show uptime
system diagnostics show version-info

system diagnostics show version-info também apresenta o número de série e o Device ID. Estes identificadores devem ser ocultados antes de partilhar resultados ou capturas.

Outros alvos apenas de leitura são interrupts, syslog, sysmsg, subsystem-info e ctr-log-lines. Respondem a perguntas diferentes e não devem ser tratados como valores de estado equivalentes:

system diagnostics show interrupts
system diagnostics show syslog
system diagnostics show sysmsg
system diagnostics show subsystem-info
system diagnostics show ctr-log-lines

Nas XGS Appliances, está também disponível system diagnostics selftest para testes básicos da placa de rede. O comando não se aplica a outras plataformas e não substitui um teste de cabo, uma medição de débito ou uma captura de pacotes. Como a Sophos não indica na página do comando o impacto no tráfego de produção, o teste só é executado de forma planeada ou por indicação do suporte e é comparado com o estado do link, os contadores da interface e o tráfego real.

Em system diagnostics utilities, o SFOS agrupa outras ferramentas para ARP, largura de banda, ligações, DNS, captura de pacotes descartados, configuração de rede, ping, processos, rotas e traceroute, incluindo variantes IPv6 quando disponibilizadas pela Sophos. A sintaxe exata é verificada na compilação instalada através da conclusão com Tab. Algumas ferramentas apenas leem o estado, enquanto outras geram tráfego de teste ou iniciam uma saída contínua.

Para uma verificação adicional apenas de leitura, a Sophos documenta na Advanced Shell:

service -S
service -S | grep ips

A primeira variante mostra vários estados de serviços; a segunda usa o exemplo de IPS documentado pela Sophos. A ausência de resultados não é motivo para reiniciar: primeiro devem comparar-se o nome do serviço e o ficheiro de log com a lista atual da Sophos.

Se o espaço de armazenamento já for reduzido, não se deve iniciar o debug nem uma captura prolongada. Deve começar-se por determinar quais os logs ou relatórios que podem ser guardados e eliminados em segurança.

Recolher logs de debug apenas com um caminho de retorno confirmado

Para SFOS 22 e SFOS 23, a ativação e a desativação do debug do subsistema de serviço aqui apresentado estão documentadas na Device Console, não no WebAdmin. Pktcapd é o exemplo documentado, não um comando genérico para todos os serviços. Registar previamente o build instalado e o nó HA afetado, o espaço livre, a hora do teste e o procedimento adequado para desativar o debug; verificar a sintaxe e o subsistema disponível com ? ou Tab. O debug aumenta o tamanho dos ficheiros de log e permanece ativo até ser desativado. Ativá-lo apenas durante uma janela de análise curta e acordada:

Antes de debug on: Determinar e documentar o estado de depuração existente para este subsistema específico neste nó HA específico, através de um método apenas de leitura suportado pela compilação instalada ou com o Sophos Support. Esclarecer também quem é responsável por um diagnóstico existente e se está em curso uma recolha. system diagnostics show subsystem-info é apenas uma verificação complementar do sistema; a sintaxe documentada não garante um campo uniforme de estado de depuração nem uma comprovação fiável de que a depuração está desativada.

Parar se a depuração estiver ativa ou se o estado inicial ou a responsabilidade não forem claros: Não executar este procedimento de ativação/desativação e, em particular, não utilizar preventivamente debug off para estabelecer um estado inicial. Primeiro, acordar com o responsável pelo diagnóstico ou com o Sophos Support o objetivo, a responsabilidade e o procedimento de desativação; prosseguir apenas com um estado inicial inativo explicitamente aprovado e confirmado. Uma janela de teste acordada, por si só, não autoriza a terminar outra recolha de diagnóstico em curso. Só então ativar de novo a depuração para este procedimento e registar a própria responsabilidade pela ativação e desativação:

system diagnostics subsystems Pktcapd debug on

Reproduzir o erro uma vez. Os logs individuais são selecionados em Diagnostics > Tools > Troubleshooting logs e descarregados como arquivo comprimido através de Download. Para um Consolidated troubleshooting report (CTR), selecionar, em alternativa, as opções necessárias System snapshot e All log files em Diagnostics > Tools > Consolidated troubleshooting report, indicar o motivo, selecionar Generate e depois Download. O CTR é descarregado encriptado; System snapshot não requer o modo de debug. Para alguns logs do CTR, a definição na CLI limita o número de linhas de log incluídas, pelo que um CTR não contém necessariamente todo o histórico de logs.

Imediatamente após a transferência, desativar o modo de depuração em 4. Device Console exclusivamente para os subsistemas de serviço cuja depuração tenha sido ativada de novo por este procedimento a partir do estado inicial inativo confirmado e continue sob a sua responsabilidade. Deixar inalterado o estado de outros diagnósticos em curso. Para o exemplo assim ativado, o procedimento de desativação é exatamente:

system diagnostics subsystems Pktcapd debug off

Em caso de interrupção da reprodução, falha na transferência, carga elevada ou pouco espaço de armazenamento, terminar o teste e desativar exclusivamente a depuração que tenha sido ativada de novo por este procedimento a partir do estado inicial inativo confirmado e continue sob a sua própria responsabilidade, em vez de esperar por uma exportação bem-sucedida. Não terminar recolhas de diagnóstico em curso da responsabilidade de terceiros; se a responsabilidade não for clara, coordenar com o responsável pelo diagnóstico ou com o Sophos Support, sem desativar por mera suposição. Uma sessão SSH terminada ou uma transferência de registos não substitui o próprio comando de desativação. Os registos e relatórios não são sincronizados entre nós HA; efetuar a recolha e a limpeza no nó em que este procedimento tenha ativado de novo a depuração.

Documentar os comandos de ativação e desativação, a hora, o nó e a resposta completa da CLI. Após o comando de desativação, verificar se a CLI confirma a desativação ou apresenta um erro; como verificação complementar, comparar o resultado da verificação de sistema apenas de leitura system diagnostics show subsystem-info com o estado registado antes do teste. A sintaxe documentada não garante um campo uniforme de estado do debug em todos os builds. Se não houver uma confirmação inequívoca, não dar o debug como desativado; esclarecer o resultado com o Sophos Support. Se o comando for rejeitado, verificar a sintaxe com ? e não prosseguir com comandos de subsistema, reinício ou serviço baseados em suposições. Em particular, a sintaxe dos subsistemas de serviço não deve ser aplicada a CSC, cujo comando de debug está documentado de forma diferente. O debug na Advanced Shell é deliberadamente omitido aqui, porque a sintaxe genérica dos serviços não disponibiliza um comando uniforme de desativação para todos os modos de debug.

Para reinícios de serviços e os respetivos efeitos, consultar Como reiniciar serviços da Sophos Firewall. Reiniciar serviços VPN, IPS, web ou de autenticação pode interromper sessões ou inícios de sessão ativos.

Disponibilizar logs em segurança

Em casos complexos, alguns excertos de log não são normalmente suficientes. Para o suporte da Sophos, a Avanet ou uma análise externa, um arquivo de logs completo é geralmente mais útil.

Em vez de introduzir credenciais em comandos da shell, recolher os ficheiros no WebAdmin: selecionar Diagnostics > Tools > Troubleshooting logs para ficheiros de log individuais e escolher Download. Para um CTR, utilizar Diagnostics > Tools > Consolidated troubleshooting report, selecionar as opções necessárias System snapshot e All log files e indicar um motivo; em seguida, escolher Generate e Download. Antes de partilhar os dados, verificar se o arquivo ou o relatório encriptado foi efetivamente descarregado e disponibilizá-lo apenas através do portal de suporte acordado. Uma exportação falhada não é motivo para deixar ativa a depuração que tenha sido ativada de novo por este procedimento a partir de um estado inicial inativo confirmado e continue sob a sua própria responsabilidade; isso não pode levar a terminar outra recolha de diagnóstico em curso. As instruções adequadas encontram-se em Guardar logs da Sophos Firewall para suporte e análise.

Os ficheiros de log podem conter informações sensíveis: endereços IP internos e públicos, nomes de host, nomes de utilizador, parâmetros VPN e mensagens de erro. Antes da partilha, deve estar claro quem recebe os dados e durante quanto tempo serão conservados.

Erros frequentes na resolução de problemas pela CLI

• Comando na área de consola errada: A Device Console e a Advanced Shell utilizam sintaxes diferentes. Verificar primeiro a área.
• Deixar a própria depuração ativa após a análise: Os registos crescem desnecessariamente e podem consumir espaço de armazenamento. Desativar de imediato apenas a depuração que tenha sido ativada de novo por este procedimento a partir de um estado inicial inativo confirmado e continue sob a sua própria responsabilidade; não terminar recolhas de diagnóstico da responsabilidade de terceiros.
• Executar um tcpdump abrangente sem filtro: Gera muitos resultados, carga elevada e dados difíceis de analisar. Restringir por host, porta, interface ou número de pacotes.
• Incluir credenciais de FTP no histórico da shell: As credenciais podem ficar registadas em logs, capturas de ecrã ou no histórico. Utilizar uma transferência segura e credenciais temporárias.
• Verificar apenas um ficheiro de log: Muitos problemas envolvem vários módulos. Combinar o Log Viewer, os logs de serviço adequados e o Packet Capture.
• Não documentar a hora: O suporte terá de pesquisar intervalos de log desnecessariamente extensos. Registar a hora, a ação de teste e os endereços IP envolvidos.
• Não efetuar a limpeza após o teste: A depuração, os ficheiros temporários ou os acessos alargados permanecem ativos. Desativar apenas a depuração que tenha sido ativada de novo por este procedimento a partir de um estado inicial inativo confirmado e continue sob a sua própria responsabilidade, verificar os ficheiros e remover as autorizações temporárias de acesso SSH; não terminar recolhas de diagnóstico da responsabilidade de terceiros.

Lista de verificação

• Acesso SSH permitido apenas a partir de redes de administração fidedignas.
• Impressão digital SSH e acesso admin verificados antes da análise.
• Área de consola correta selecionada: Device Console ou Advanced Shell.
• Hora do problema, IP de origem, IP de destino, porta e utilizador documentados.
• Resultado da CLI documentado com intervalo de tempo, comando, filtro e resultado.
• Comandos apenas de leitura utilizados antes de iniciar o debug, reiniciar serviços ou realizar capturas prolongadas.
• Log Viewer verificado primeiro.
• Ficheiro de log adequado identificado em /log.
• tail, grep ou less utilizados com um termo de pesquisa restrito.
• Para problemas de rede, dnslookup, ping, traceroute, drop-packet-capture ou tcpdump foram usados de forma direcionada na Device Console.
• Antes da depuração do subsistema de serviço em SFOS 22/23, esclarecidos o estado existente e o responsável pelo diagnóstico para o subsistema e o nó HA exatos, e confirmado e documentado um estado inicial inativo explicitamente aprovado; em caso de estado ativo ou pouco claro, não executado o procedimento de ativação/desativação, mas coordenado com o responsável ou com o suporte. Ativada de novo por um breve período em 4. Device Console apenas a partir deste estado inicial; no exemplo, com system diagnostics subsystems Pktcapd debug on e, depois, com system diagnostics subsystems Pktcapd debug off, desativada exclusivamente a depuração que tenha sido ativada de novo por este procedimento e continue sob a sua própria responsabilidade. Deixadas inalteradas as recolhas de diagnóstico da responsabilidade de terceiros. Verificadas a resposta à desativação e as informações complementares sobre o estado do sistema; esclarecido com o suporte qualquer estado pouco claro, sem o assinalar como desativado.
• Espaço de armazenamento verificado antes do debug ou de um PCAP.
• Arquivo de logs transferido em segurança e ficheiros temporários removidos.
• Exceções temporárias de Device Access ou SSH removidas após o caso de suporte.

FAQ