Diagnosticar Sophos Endpoint com Self Help e SDU

Um problema Endpoint não se resolve com reinstalações aleatórias. Primeiro, delimita-se se são afetados componentes de proteção, comunicação Central, Update, Policy, sistema operativo ou rede. Endpoint Self Help fornece estados locais e primeiras causas. A Sophos Diagnostic Utility, SDU, recolhe depois os Logs técnicos.

O percurso de onboarding do Endpoint descreve toda a implementação, desde o planeamento até à passagem para as operações.

Fluxo rápido para um diagnóstico fiável

1. Registar sintoma, impacto, hora do erro com fuso horário e um teste reproduzível.
2. Abrir Endpoint Self Help e verificar a área afetada e o Network Test.
3. Ativar apenas o diagnóstico adicional relevante e reproduzir o problema no intervalo acordado.
4. Reverter ou parar Debug Logging e Packet Capture e recolher depois um SDU do mesmo intervalo.
5. Transferir o pacote em segurança e associá-lo ao caso com a análise própria e o nome de ficheiro SDU apresentado.

Assim, verificação de estado, reprodução e recolha de provas ficam alinhadas no tempo. Não iniciar reparações nem exclusões amplas antes de preservar a observação.

Antes da recolha de Logs

Antes de qualquer diagnóstico, documentam-se os sintomas visíveis:

• computador afetado, sistema operativo e hora,
• mensagem local ou Screenshot,
• Central Health, Last Active, Agent Mode e Policies efetivas,
• última instalação, atualização ou alteração de Policy,
• teste reproduzível e comportamento esperado.

Estas informações são frequentemente mais importantes do que um arquivo enorme sem referência temporal.

Abrir Endpoint Self Help

O ESH suporta Windows Endpoint e Windows Server geridos pelo Sophos Fusion (anteriormente Sophos Central). Na interface local, selecione About no canto inferior direito e depois Open Endpoint Self Help Tool, ou abra-o diretamente em C:\Program Files\Sophos\Endpoint Self Help. A ferramenta mostra o estado dos componentes, comunicação e serviços de proteção. As páginas visíveis dependem da licença, dos componentes instalados e da geração do agente e da plataforma; as versões antigas de Windows apresentam menos estados e funções.

Com o Core Agent 2026.3.0.2090, a interface Endpoint e o Self Help são reunidos num único componente Sophos Endpoint UI em Windows 10 64-bit e versões posteriores. As Release Notes indicam esta versão para outubro de 2026 e assinalam uma distribuição faseada. Antes de reparar componentes, verificar por isso as versões do agente e dos componentes efetivamente instaladas: a ausência de um pacote Self Help separado, por si só, não comprova uma falha de instalação a partir desta geração. Esta unificação não comprova uma alteração ao caminho de abertura descrito acima; verificar o ponto de entrada disponível no pacote instalado, em vez de presumir um novo percurso de menus. Verificado em 24 de outubro de 2026.

Nas plataformas modernas, desde o Core Agent 2024.2, o ESH fecha após duas horas sem interação e avisa cinco minutos antes. Desde a versão 2024.3, verifica automaticamente Known Issues ao iniciar. Os agentes atuais separam System, Services e Update; versões anteriores podem agrupar ou omitir vistas. Por isso, registe a versão do agente em cada screenshot.

Self Help responde a questões como:

• O componente esperado está em execução?
• Um serviço está parado ou com erro?
• O agente alcança o Central e a infraestrutura de Update?
• Existe um erro local conhecido de configuração ou permissões?

Um Check vermelho é documentado com nome, estado, detalhe e hora. Antes da reparação, verifica-se se uma Central Policy ou bloqueio de rede recriaria a causa.

Se SophosDiag.exe falhar logo ao abrir e o Windows Application Event Log identificar um user.config específico do utilizador danificado, elimina-se apenas o ficheiro indicado no erro dentro do perfil afetado. Não se automatiza a eliminação da pasta superior dependente da versão como caminho fixo. Depois volta-se a abrir Self Help. Se o erro persistir, recolhe-se um SDU ou repara-se o componente instalado.

Utilizar as páginas Self Help de forma específica

Cada página responde a perguntas diferentes. Não devem ser interpretadas como um indicador geral:

Um Policy Update pode demorar até cinco minutos. Se Override Sophos Central Policy for up to 4 hours estiver ativo localmente, as novas Central Policies ficam em Cache e só são aplicadas quando o Override termina. Uma hora antiga de Policy não comprova então um problema de comunicação.

Em Components, comparam-se as versões de módulos instaladas, descarregadas e esperadas. Not installed, estados de download e instalação diferentes ou várias versões são primeiro verificados contra Update Status, Pending Restart e software de segurança concorrente. O Repository local não é eliminado por precaução. Em System, um Pending Restart persistente pode vir do Windows Update. Após alterações de hardware ou software de segurança, volta-se a detetar o estado do software pela Endpoint CLI antes de iniciar uma reparação.

Em condições normais, as ações do Central chegam em segundos ou minutos. Last Active, pelo contrário, só é atualizado, no máximo, aproximadamente uma vez por hora. Numa User Policy, a alteração pode demorar mais, porque Central User, conta com sessão local e Interactive Session reconhecida pelo MCS Client têm primeiro de coincidir.

Interpretar corretamente o Network Test

O Network Test verifica os canais Updating, Management Communication e Sophos Extensible List (SXL). Para cada destino, a ferramenta tenta primeiro HTTPS e, consoante o resultado, ICMP e DNS Resolution. Para o funcionamento é decisiva uma ligação HTTPS bem-sucedida. Um Ping ou nslookup isolado não prova, por isso, que a comunicação com o Central funcione.

É a primeira verificação quando o estado de Update ou Communication é negativo, o Live Discover/Response parece offline ou existem problemas com Real-Time Scanning, Web Control ou SXL. Identifica a etapa que falha, mas não determina por si só a causa na firewall, no proxy ou no DNS. Em Windows 7/8/8.1 e Server 2008 R2/2012, o teste HTTPS para sdds3.sophosupd.net pode falhar devido à ausência de Cipher Suites no sistema operativo.

Com um Update Cache ou Message Relay, Self Help verifica apenas a DNS Resolution do servidor atribuído. Um DNS Test verde não confirma Service Status, Port nem Forwarding. A função real de Cache ou Relay é verificada separadamente.

Dois limites são especialmente importantes:

• Após alterar uma atribuição de Cache ou Relay, Endpoint Self Help tem de ser fechado e aberto novamente; caso contrário, o Network Test pode continuar a utilizar o destino antigo.
• O Network Test não suporta Proxies autenticados e pode apresentar resultados enganadores.

Os SXL Tests requerem elevação administrativa por UAC. Se o dispositivo utilizar um Message Relay, Self Help não executa diretamente o SXL Test porque esse Traffic passa pelo Relay.

Se a comunicação continuar a falhar, comparam-se os Broker Addresses apresentados por Self Help com a configuração MCS local. Também se verificam Routing, Windows Hosts File, Proxy e Firewall Log. Após uma correção, pode reiniciar-se o Sophos MCS Client e atualizar Self Help. O acesso ao Central através de um Browser não substitui este teste.

Resolver Update Errors sem eliminar precipitadamente o Cache

Um Update falhado dentro do Sophos Grace Period pode ser temporário. Primeiro verificam-se Update Now, rede, Proxy, Update Source e hora do último Update bem-sucedido. Se estas verificações não indicarem a causa, guardam-se primeiro os seguintes elementos de diagnóstico para o Sophos Support.

Num erro reproduzível, correlaciona-se SophosUpdate.log com um Packet Capture simultâneo e os Firewall Logs ou Proxy Logs. São decisivos DNS Response, Update Server efetivamente contactado, percurso direto ou por Proxy e o primeiro erro HTTP ou TLS. Os principais Windows Log Paths encontram-se em Analisar Logs e serviços Sophos Endpoint no Windows.

O diagnóstico termina aqui; não altere as pastas de cache e repository com base em suspeitas. Um reset da cache requer instruções completas do Sophos Support adequadas à versão do agente e aos sintomas, com caminhos exatos, sequência e procedimento de recuperação.

Esta intervenção requer direitos de administrador e Tamper Protection temporariamente desativada; gera um Pending Restart Alert. Guarde ou renomeie as pastas afetadas de acordo com essas instruções, sem as eliminar sem verificação. Após a intervenção, uma atualização completa tem de terminar com êxito e Self Help deve voltar a apresentar um estado saudável após Refresh.

Por fim, reative Tamper Protection e verifique o estado de proteção ativo localmente e no Sophos Fusion. Enquanto faltar o procedimento ou a via de recuperação, limite-se aos resultados do diagnóstico.

Performance Analysis

Desde o Core Agent 2024.3, o ESH pode carregar Scanner Summaries em Windows 10 x64 ou posterior e Windows Server 2016 ou posterior. Pode utilizar os resultados de um processo Product Analysis ou ficheiros gerados através de SFS > Scan Summaries em Product Logging; estes podem provir deste dispositivo ESH ou de outro. Os ficheiros CSV encontram-se normalmente em:

C:\ProgramData\Sophos\Sophos File Scanner\Logs\summary.<TIMESTAMP>.csv

Podem ser analisados noutro dispositivo com Endpoint Self Help. O ficheiro mostra que Processes e Paths geraram Scan Load durante o intervalo registado. Isto ainda não justifica uma Exception global. Primeiro verificam-se aplicação, Access Pattern e a exclusão tecnicamente mais restrita.

Na análise, comparam-se primeiro pastas com tempo de Scan acumulado elevado, depois Paths verificados com muita frequência e, por fim, grandes volumes de dados. Um Path frequente não tem de ser o que apresenta maior duração total. Se Self Help avisar que uma exclusão é demasiado ampla, usa-se apenas brevemente para confirmar a causa. Uma solução permanente é limitada à subpasta ou ao processo que realmente causa a carga.

Product Analysis vai mais longe e desativa e reativa funções de proteção de forma guiada para delimitar o componente envolvido. Requer direitos de administrador e, com Tamper Protection ativo, a respetiva Password. Executa-se apenas num dispositivo de teste controlado ou numa janela de manutenção. Primeiro documentam-se Protection Status e Update Status, guarda-se o resultado e depois restauram-se todas as funções e Updates. A ferramenta fornece uma hipótese, não uma autorização automática para uma exclusão.

File Info em vez de suposições

Em Tools > File Info, avalia-se localmente um ficheiro PE Windows. Self Help mostra SHA-256, tamanho, categoria Application Control, produto e Policy Decision. Local Reputation inclui dados Sophos e Allowed Applications ou Blocked Items do cliente, podendo diferir de Global Reputation e prevalecer na decisão local.

Deep Learning exige licença Intercept X adequada. Um resultado verde não prova que malware já detetado seja inofensivo; ficheiros Malware ou PUA detetados normalmente não podem ser arrastados para a página. Para classificação errada guardam-se Hash, Signature, Lookup Type local e global e decisão concreta, usando depois Sample Submission.

File Info fornece os dados mais completos para ficheiros Windows PE; para outros tipos de ficheiro, as informações são limitadas. Após Run as administrator, o Windows pode bloquear o arrastar e largar a partir de um processo com menos privilégios; nesse caso, utilize browse for a file. A reputação e o resultado da política não são uma garantia de integridade. Quando a confiança no ficheiro é decisiva, segue-se a análise de amostras aprovada.

Aprofundar o estado de Policy, Services e Operations

Se Policy mostrar timestamps antigos, distingue-se receção de processamento local. Verifica-se McsClient.log por Connection e Backoff e McsAgent.log por Policy, Namespace e Status Errors. Em MCS Cache, Active.policy e Latest.policy mostram se uma Policy chegou mas não ficou ativa. Services só são reiniciados depois de guardar a observação e a transição é confirmada no log.

Nem todo o símbolo azul ou vazio em Operations é erro. Distingue-se Data Lake desativado, dispositivo excluído ou limite diário atingido de uma Live Query Service avariada. Com Data Lake Status negativo, verificam-se primeiro SophosLiveQueryService.log, SophosOsquery.log e Service State.

Heartbeat mostra Readiness, Certificate State e ligação a Sophos Firewall. configured, no connection currently available não prova sozinho uma falha Endpoint e Heartbeat não entra no Device Health geral. Quando se espera ligação, correlacionam-se logs por hora e Device ID. Registry ou Certificate Repairs de Advanced Self Help exigem Backup, Tamper Protection desativado e rollback documentado.

Iniciar SDU pela interface

Em Endpoint Self Help, abra Launch SDU, aceite a EULA e selecione Start para recolher informações do sistema e Sophos Product Logs. Depois, View log mostra a recolha, Open folder abre a pasta com sdu.log e os arquivos e Submit permite o upload ou a entrega manual para o caso. Em Windows, sducli.exe sem opções de recolha guarda os dados em C:\WINDOWS\Temp\sdu-YYYYMMDD_xxxxxx_xxxxxx. Para Upload to Sophos, sdu-feedback.sophos.com tem de estar acessível através de TCP 443. O URL de upload, intencionalmente não navegável, é copiado para o caso e também pode ser encontrado no fim de sdu.log.

O arquivo pode conter Hostnames, utilizadores, caminhos, IPs, processos, configurações e Events. Não deve ser colocado em tickets públicos, File Shares desprotegidos ou chats.

Um dispositivo Windows, macOS ou Linux também pode ser diagnosticado a partir do Central: abrir My Environment > Computers & Servers, selecionar o dispositivo e depois Summary > More actions > Diagnose > Run. O campo SDU mostra Status, Last Run e File Name; o nome do ficheiro deve ser incluído no caso de suporte. O arquivo é enviado diretamente para a Sophos por HTTPS 443 através do percurso normal de domínios Sophos autorizados. A ação e o administrador que a iniciou aparecem em Reports > General Logs > Audit Logs.

Se o dispositivo estiver offline, o Central mantém a ordem por um máximo de 14 dias. Depois elimina-a e é necessário iniciá-la de novo. O comando começa na próxima Central Communication, por isso é preciso esclarecer antes o momento, a autorização relativa aos dados e a conectividade esperada.

Product Logging e Packet Capture

Product Logging aumenta o nível de logging dos componentes selecionados e requer elevação UAC. Ativa-se apenas para o componente suspeito e durante um período em que o problema possa ser reproduzido. Uma definição Parent aplica-se a todos os Children; um asterisco no Parent assinala valores diferentes definidos ao nível de Child. Save aplica os níveis pendentes e Revert… apenas descarta alterações antes de serem guardadas. Um nível já aplicado é reposto com Default no Parent/Child alterado, seguido de Save. Ao fechar, Revert to Default repõe as predefinições; Just Close mantém o debug ativo. Fechar o ESH, por si só, não termina esse logging. Guardam-se os logs com os horários e passos; o debug permanente pode gerar conteúdo sensível e um grande volume de dados.

Packet Capture utiliza Windows pktmon, requer elevação UAC e não está disponível antes de Windows 10 1809 nem em Windows Server 2016 ou anterior. O limite predefinido é 512 MB e pode ser ajustado entre 1 e 9999 MB; nos builds Windows 10 anteriores à versão 2004, mantém-se nos 512 MB. Um limite controlado evita encher o disco. Cada execução cria capture-<date><time>.etl e capture-<date><time>.pcapng em C:\ProgramData\Sophos\Endpoint Self Help\PacketCapture; ambos os ficheiros são entregues para análise. Fechar o ESH termina a captura. Os ficheiros não são limpos automaticamente e têm de ser eliminados manualmente após o prazo de conservação aprovado.

Se Self Help não conseguir elevar Logging, Packet Capture ou SDU, verifica-se primeiro UAC. UAC totalmente desativado ou prompts suprimidos podem bloquear. Restaurar valores Microsoft é melhor do que executar permanentemente com Administrator integrado.

SDU no Windows pela CLI

A versão Windows encontra-se normalmente em:

C:\Program Files\Sophos\Sophos Diagnostic Utility\sducli.exe

Uma sessão de PowerShell com direitos de administrador mostra a ajuda integrada:

& "C:\Program Files\Sophos\Sophos Diagnostic Utility\sducli.exe" -help

Parâmetros importantes:

A saída local de -help é determinante para a versão instalada. Recolhas automatizadas têm limite de armazenamento, destino seguro e prazo de eliminação.

SDU no macOS pela CLI

Num Mac, SDU é iniciado a partir do Application Bundle:

/Library/Sophos\ Anti-Virus/Tools/Sophos\ Diagnostic\ Utility.app/Contents/MacOS/Sophos\ Diagnostic\ Utility --help

--help mostra apenas os comandos disponíveis e não recolhe diagnósticos. O comando executável de recolha é:

/Library/Sophos\ Anti-Virus/Tools/Sophos\ Diagnostic\ Utility.app/Contents/MacOS/Sophos\ Diagnostic\ Utility --cli

--output_path="<path>" define o destino; caso contrário usa-se o diretório atual. Estas opções aplicam-se ao agente macOS 2026.1 e posterior. O processo necessita das permissões requeridas pelos dados. Full Disk Access ou System Extension em falta são verificados adicionalmente no diagnóstico de permissões macOS.

SDU no Linux pela CLI

Num dispositivo protegido pelo Sophos Protection for Linux, o utilitário instalado é executado assim:

/opt/sophos-spl/bin/sophos_diagnose

Cria um arquivo tar.gz no diretório de trabalho atual e recolhe os logs do agente SPL, de todos os plugins e o Audit Log. Para usar um destino controlado, crie um diretório privado e passe-o como primeiro argumento posicional:

mkdir -p "$HOME/sophos-sdu"
chmod 700 "$HOME/sophos-sdu"
/opt/sophos-spl/bin/sophos_diagnose "$HOME/sophos-sdu"

O último argumento é um diretório, não o nome do arquivo; o tar.gz resultante é criado dentro dele. Assim mantém-se a sintaxe do fabricante sem usar uma pasta temporária partilhada.

Avaliar corretamente o modo forense

SDU pode criar Forensic Logs especiais. Este modo destina-se ao Sophos Incident Response ou a uma investigação forense específica. Não substitui um processo forense empresarial completo e não deve permanecer ativo sem uma tarefa definida.

Perante possível comprometimento:

• não reiniciar nem limpar precipitadamente,
• documentar fonte de hora e fuso horário,
• guardar evidências apenas num destino controlado,
• registar Hash, transferência e acesso ao arquivo,
• envolver os responsáveis de Incident Response.

Mostrar configuração e Software Status pela CLI

A Endpoint CLI local pode mostrar estados de Policy e Software. Output configuration mostra as definições recebidas. Software Monitor fornece estados dos componentes e pode atualizá-los.

Estas saídas ajudam em três contradições típicas:

1. O Central mostra uma Policy atribuída, mas a definição falta localmente.
2. Agent Mode está correto, mas um componente não está instalado ou saudável.
3. Um Update foi anunciado, mas Software Monitor permanece em erro.

A ajuda local deve ser verificada, pois comandos e parâmetros podem depender da versão do agente.

Avaliar Logs de forma direcionada

Nem todos os Logs são lidos integralmente. Começa-se por uma janela temporal curta e procura-se o primeiro erro, não apenas erros subsequentes. São particularmente úteis:

• Installer e Update Logs em problemas de Rollout,
• MCS ou Management Communication quando falta contacto Central,
• Health e Component Logs em estado vermelho,
• Events Web, DLP, Application ou Peripheral em problemas de Policy,
• Operating System Event Logs em torno de serviços, drivers e certificados.

Um único error ainda não é a causa. Correlação temporal, componente e comportamento reproduzível decidem.

Preparar o pacote de suporte

Um bom pacote contém:

1. descrição curta e impacto,
2. hora exata com fuso horário,
3. dispositivos afetados e comparativos não afetados,
4. passos de reprodução,
5. Central Screenshots relevantes sem Secrets,
6. arquivo SDU e, se necessário, Installer Logs,
7. medidas já testadas e resultado.

Palavras-passe de Tamper Protection, API Secrets, palavras-passe Proxy e Installer Tokens nunca são anexados em texto simples.

Cumprir os Minimum Escalation Requirements

A Sophos dividiu os requisitos de escalada para Windows Endpoint por classe de erro. Um SDU sem análise própria não cumpre estes Minimum Escalation Requirements, ou MER.

Em cada caso registam-se primeiro plataforma e versão do produto, componente afetado, âmbito, frequência, reprodutibilidade, alterações anteriores ao problema e mensagens de erro exatas. Os Logs têm de estar completos, conter o momento do erro e, em problemas Client-Server, corresponder temporalmente.

Depois acrescentam-se dados específicos do cenário:

Num caso de Performance, distingue-se primeiro se a anomalia está em SophosFileScanner.exe, SEDService.exe, SSPService.exe, outro Sophos Process ou na carga geral do sistema. Uma proteção globalmente desativada não fornece uma causa fiável sem medição simultânea e associação exata ao componente.

Um pedido de suporte não inclui apenas os ficheiros recolhidos, mas também o resultado da análise própria: que Log mostra o primeiro erro relevante, a que hora e que hipótese foi confirmada ou rejeitada?

Verifica-se ainda em Account Preferences > Evaluation Modes se Aggressive threat detection está ativo. Esta opção de diagnóstico de Sophos Support e SophosLabs aumenta claramente a carga do sistema e não é uma baseline de segurança de produção. Se estiver ativa, documenta-se o objetivo e desativa-se depois da medição prevista. Se o problema persistir, continua-se como caso Performance separado com um novo intervalo.

Em casos de Exploit, Ransomware ou HitmanPro.Alert, verifica-se também se a Sophos disponibiliza uma Endpoint Maintenance Release com uma correção adequada. Cria-se o Crash Dump ou Memory Dump completo depois de reproduzir a falha e antes do SDU, para que os artefactos pertençam ao mesmo intervalo. Não se mudam nomes de DLLs ou Drivers de proteção sem um Runbook Sophos atual.

Perguntas frequentes