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.

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

Depois do teste, desativar o modo de emergência e verificar novamente o estado:

system appliance_access disable
system appliance_access show

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

O SFOS 22 ativa o modo debug na Device Console, não no WebAdmin. Para um teste controlado com o exemplo Pktcapd documentado pela Sophos, registar primeiro o espaço livre e a hora do teste e executar:

system diagnostics subsystems Pktcapd debug on

Reproduzir o problema uma vez e depois descarregar o ficheiro de log ou um Consolidated Troubleshooting Report (CTR) em Diagnostics > Tools > Troubleshooting logs. O debug aumenta os ficheiros de log e permanece ativo até ser desativado. Por isso, executar o rollback documentado imediatamente após o download:

system diagnostics subsystems Pktcapd debug off

Registar ambos os comandos e o respetivo resultado da CLI. Se um comando for rejeitado, não improvisar outro comando de subsistema ou serviço: verificar a sintaxe com ? e contactar o Sophos Support. O debug na Advanced Shell é omitido intencionalmente, porque a sintaxe genérica dos serviços não fornece um comando universal de desativação para todos os modos.

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 shell, descarregam-se logs individuais ou um CTR em Diagnostics > Tools > Troubleshooting logs e fornecem-se através do portal de suporte acordado. Seguir Como recolher 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 o debug ativo após a análise: Os logs crescem desnecessariamente e podem consumir espaço de armazenamento. Desativar o debug imediatamente após o teste.
• 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 limpar depois do teste: O debug, os ficheiros temporários ou os acessos abrangentes permanecem ativos. Desativar o debug, verificar os ficheiros e remover as autorizações SSH temporárias.

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.
• O debug foi ativado apenas brevemente em Diagnostics > Tools > Troubleshooting logs, depois desativado e o estado normal foi verificado.
• 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