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.

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 para ficheiros, logs, processos e verificações de serviços. Os comandos típicos incluem cd /log, tail -f, grep, less, df -kh, service -S e conntrack.

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

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 ficheiros de log mais importantes encontram-se em /log. Para uma primeira orientação, muda-se para este diretório e listam-se os ficheiros.

cd /log
ls -lah

Comandos básicos úteis:

• Acompanhar um log em tempo real: tail -f /log/strongswan.log. Útil para erros de VPN que podem ser reproduzidos.
• Ler um ficheiro de log: less /log/ips.log. Dentro de less, pode pesquisar-se com /termo-de-pesquisa.
• Procurar erros: grep -i "error" /log/ips.log. A opção -i ignora maiúsculas e minúsculas.
• Mostrar correspondências com números de linha: grep -n "192.0.2.10" /log/firewall_rule.log. Útil para ficheiros extensos.
• Mostrar as últimas linhas: tail -n 100 /log/syslog.log. Proporciona uma visão geral rápida sem modo em tempo real.

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: 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 correspondentes ping6, dnslookup6 e traceroute6.

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.

Verificar ligações e fluxo de pacotes na Advanced Shell

Se o Log Viewer e a Device Console ainda não fornecerem uma resposta clara, alguns comandos da Advanced Shell ajudam a analisar o fluxo de pacotes.

Verificar ligações

Na Device Console, system diagnostics utilities connections é uma ferramenta de diagnóstico oficialmente documentada para ligações. As opções disponíveis e o resultado devem ser consultados previamente com ?.

O conntrack é uma ferramenta de apoio utilizada em contextos de suporte na Advanced Shell e mostra as ligações ativas conhecidas pelo percurso com monitorização de estado da firewall. A disponibilidade exata pode depender da versão do firmware.

conntrack -L | grep "192.0.2.10"

A ausência de uma correspondência é apenas um indício, porque o momento da captura, a direção do filtro ou o FastPath podem afetar a visibilidade. Por isso, o resultado deve ser comparado com o Log Viewer e o Packet Capture. Se existir uma entrada, mas a aplicação não funcionar, deve verificar-se adicionalmente se os pacotes de resposta regressam e se o NAT, a política ou a aplicação estão configurados corretamente.

tcpdump na Advanced Shell

Para verificações rápidas em tempo real, o tcpdump também pode ser utilizado na Advanced Shell.

tcpdump -i any -nn host 192.0.2.10

Em análises de produção, o filtro deve ser o mais restrito possível. Capturas abrangentes, como tcpdump -i any sem host, porta ou limite de pacotes, geram rapidamente um grande volume de resultados e são pouco práticas em firewalls com muita carga.

Um ponto de partida seguro é uma captura curta com host, porta e limite de pacotes:

tcpdump -i any -nn -c 50 host 192.0.2.10 and port 443

Se forem necessários mais dados, deve verificar-se previamente o espaço de armazenamento e escolher conscientemente o local para guardar o PCAP.

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

Para uma verificação complementar na Advanced Shell, estão disponíveis as ferramentas seguintes; a respetiva disponibilidade pode depender da versão do firmware:

df -kh
df -h /var

Outras verificações rápidas:

uptime
top
service -S
service -S | grep strongswan

O service -S mostra o estado de vários serviços. Os nomes dos serviços nem sempre são autoexplicativos. Por isso, deve comparar-se o serviço com o ficheiro de log adequado antes de realizar um reinício ou ativar o debug.

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.

Ativar especificamente um log de debug

Os logs de debug podem ajudar em problemas complexos, mas só devem ser ativados por pouco tempo e apenas para o serviço afetado. O debug gera muito mais dados de log e, se permanecer ativo durante demasiado tempo, pode consumir espaço de armazenamento.

Para um processo On/Off claramente controlado, utiliza-se um subsistema suportado na Device Console. Os nomes disponíveis devem ser consultados primeiro com system diagnostics subsystems ?. A Sophos documenta, por exemplo, o seguinte processo para Pktcapd:

system diagnostics subsystems Pktcapd debug on
system diagnostics subsystems Pktcapd debug off

Na Advanced Shell, a Sophos documenta adicionalmente o seguinte comando de debug do IPS:

service ips:debug -ds nosync

Para esta variante da Advanced Shell, não está documentado um comando separado com off acrescentado. Por isso, só deve ser utilizada quando o suporte da Sophos tiver confirmado o processo de reversão exato para o build instalado.

A imagem mostra, no SFOS 20.0.1, como o mesmo comando alterna o modo de debug do IPS e como service -S | grep ips confirma o estado antes e depois do teste. Nas versões atuais, não se deve pressupor este comportamento de alternância sem o verificar.

Para reiniciar serviços e compreender a função de cada serviço, deve consultar-se também Reiniciar serviços da Sophos Firewall. Em casos de suporte, deve documentar-se o período exato dos logs de debug.

Antes de reiniciar um serviço, deve verificar-se que função é afetada e se existe tráfego de produção a utilizá-la. O reinício de serviços de VPN, IPS, Web ou autenticação pode afetar sessões ativas ou inícios de sessão de utilizadores.

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 incluir credenciais de FTP em comandos, os logs devem ser transferidos através de um método seguro e rastreável, por exemplo, por scp para um servidor próprio ou através de um portal de suporte. O procedimento adequado encontra-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 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, ping, dnslookup, traceroute, drop-packet-capture ou tcpdump utilizados especificamente.
• Debug ativado apenas por pouco tempo e desativado com o comando off documentado para o subsistema selecionado.
• 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