Sophos Linux Sensor: recolher dados de suporte em segurança

Em caso de problema com Sophos Linux Sensor (SLS), recolhe-se um arquivo de suporte e os registos correspondentes do sensor, de preferência durante a ocorrência do erro ou imediatamente a seguir. A recolha demora aproximadamente 30 segundos. Primeiro, identificar o tipo de implementação: com Helm, a recolha é feita por cada nó afetado; com Docker, no host Docker; e, numa instalação direta, no host Linux. Após o sinal de depuração, a transferência tem de ser efetuada imediatamente; a janela temporária de depuração é de 60 segundos.

Este guia aplica-se exclusivamente a Sophos Linux Sensor. SLS não é Sophos Protection for Linux (SPL), nem o respetivo XDR Sensor ou a respetiva política Linux Runtime Detection. A inclusão na visão geral de servidores destina-se à navegação e não torna os produtos equivalentes. Para SPL, aplica-se o guia de instalação e operação separado; os comandos SLS seguintes não podem ser utilizados nesse contexto.

Verificar o sistema de destino e a autorização antes da recolha

Antes de enviar um sinal ou reiniciar, confirmar, com base no inventário da implementação e na instância em execução, que é efetivamente SLS que está afetado. Registar no caso de suporte o host ou cluster, namespace, pod, nó ou contentor, a versão instalada do sensor e a hora do erro com o fuso horário. As informações de versão no arquivo recolhido posteriormente complementam esta identificação. Este guia segue o procedimento de suporte atualizado em 5 de outubro de 2026; daí não resulta uma versão mínima nem uma autorização para todas as versões anteriores do sensor, Helm, Kubernetes ou Docker. Se os nomes ou as portas forem diferentes, ou se faltar um endpoint de monitorização, esclarecer primeiro a implementação real com o suporte.

É necessário um diretório de trabalho com acesso protegido e espaço livre suficiente. Os nomes de ficheiro apresentados abaixo são relativos a esse diretório; antes de repetir a recolha, guardar separadamente os pacotes existentes para evitar que sejam substituídos. Limitar o acesso ao arquivo, aos registos e aos perfis às pessoas responsáveis e definir um prazo de conservação. Para as transferências, os endereços de monitorização permanecem locais. Não configurar um serviço público, um Ingress ou uma porta de depuração acessível de forma geral.

As ferramentas têm de estar previamente autorizadas e disponíveis. Se faltar curl num host Linux com instalação direta, o procedimento documenta estes comandos de instalação:

# Sistemas baseados em Red Hat
sudo yum install curl

# Ubuntu
sudo apt-get install curl

Utilizar apenas o comando adequado à distribuição, no âmbito do processo aprovado de gestão de pacotes. A instalação de um pacote altera o host; não faz parte da mera revisão do artigo. Para Helm e Docker, são também necessários tar e gzip. Sem as ferramentas ou permissões necessárias, parar antes de ativar a depuração.

Helm: um pacote por cada nó afetado

No computador de administração, kubectl tem de estar configurado para o cluster correto. As permissões têm de permitir listar pods, ler registos de pods, reencaminhar portas de pods e adicionar um contentor de depuração efémero. Além disso, o runtime de contentores tem de suportar o direcionamento para o namespace de processos de outro contentor. São necessários curl, tar e gzip neste computador.

O cluster tem de conseguir obter busybox:latest. Se este registo não estiver aprovado, a imagem deve ser previamente replicada para um registo aprovado e acessível, substituindo-se apenas o valor de --image por essa referência de imagem verificada. Não flexibilizar as regras de segurança do registo para forçar a recolha. O contentor efémero constitui uma alteração ao pod; requer a autorização operacional adequada.

Selecionar o pod e manter o reencaminhamento de portas aberto

O chart Helm de SLS disponibiliza um pod de sensor por cada nó Linux monitorizado. Substituir <namespace> pelo namespace da release SLS:

kubectl --namespace <namespace> \
get pods \
--selector app=sophos-linux-sensor \
--output wide

O resultado tem de associar o pod do sensor ao nó afetado. <sensor-pod> é precisamente esse pod e <node-name> é o nome do respetivo nó. Não utilizar um pod saudável qualquer da mesma release.

No primeiro terminal, reencaminhar a porta de monitorização:

kubectl --namespace <namespace> \
port-forward pod/<sensor-pod> 9010:9010

Este terminal permanece aberto até a transferência estar concluída. Se a porta local já estiver ocupada, parar o procedimento e esclarecer o conflito, em vez de terminar um processo alheio. Não adicionar uma associação a endereços acessíveis publicamente. Se o reencaminhamento for interrompido, tem de voltar a estar em execução antes de repetir a transferência.

Enviar o sinal, transferir imediatamente e acrescentar os registos

No segundo terminal, o contentor de depuração é direcionado para o contentor SLS. O comando envia SIGUSR2 ao processo do sensor; não é uma instrução para terminar o sensor:

kubectl --namespace <namespace> \
debug pod/<sensor-pod> \
--image=busybox:latest \
--target=sophos-linux-sensor \
--attach=false -- \
pkill -USR2 -f '[s]ophoslinuxsensor'

O padrão de pesquisa [s]ophoslinuxsensor impede que pkill corresponda à sua própria linha de comando. Se a obtenção da imagem, as permissões ou o direcionamento para o processo falharem, a recolha não foi ativada de forma fiável. Não adicionar mais contentores de depuração às cegas; esclarecer primeiro a mensagem de erro.

Imediatamente a seguir, efetuar a transferência no segundo terminal:

curl --fail --silent --show-error \
--max-time 120 \
http://127.0.0.1:9010/support.tar \
--output sophos-linux-sensor-support-<node-name>.tar

--max-time 120 limita a chamada HTTP, mas não prolonga a janela de depuração. Depois, guardar os registos atuais do mesmo contentor e nó:

kubectl --namespace <namespace> \
logs pod/<sensor-pod> \
--container sophos-linux-sensor \
--timestamps \
> sophos-linux-sensor-<node-name>.log

Listar o conteúdo sem o extrair:

tar -tf sophos-linux-sensor-support-<node-name>.tar

Após a verificação de que o pacote está completo, descrita abaixo, terminar o reencaminhamento de portas no primeiro terminal com Ctrl+C. Para cada nó afetado adicional, utilizar um pod próprio e um nome de ficheiro único.

Docker: verificar o contentor em execução e a porta publicada

Todos os comandos seguintes são executados no host Docker com as permissões Docker aí aprovadas. O contentor SLS tem de estar em execução; a sua porta de monitorização já tem de estar publicada no host. A porta predefinida no contentor é 9010. curl, tar e gzip têm de estar disponíveis. Não se prescreve aqui a publicação posterior de uma porta nem o reinício do contentor como medida de reparação.

docker ps
docker port <sensor-container> 9010/tcp

<sensor-container> é o nome ou ID do contentor SLS confirmado. O segundo resultado indica o endereço e a porta do host. <host-port> é substituído por essa porta, não automaticamente por 9010. A transferência seguinte pressupõe que o endereço publicado é acessível através de 127.0.0.1 neste host Docker. Se existir apenas uma associação a outro endereço ou se não houver resultado, verificar primeiro a implementação; não adicionar uma porta acessível publicamente.

O comando seguinte altera o estado de depuração durante 60 segundos. Neste contexto, docker kill não pode ser executado sem --signal=SIGUSR2:

docker kill --signal=SIGUSR2 <sensor-container>

Imediatamente a seguir, aceder ao endpoint local publicado:

curl --fail --silent --show-error \
http://127.0.0.1:<host-port>/support.tar \
--output sophos-linux-sensor-support.tar

Os registos e a verificação do arquivo fazem parte do mesmo pacote:

docker logs <sensor-container> \
> sophos-linux-sensor.log 2>&1

tar -tf sophos-linux-sensor-support.tar

O modo de depuração temporário termina automaticamente. Uma nova consulta com docker ps tem de continuar a mostrar o contentor previsto em execução; contudo, só isso não comprova que a deteção esteja a funcionar.

Host Linux com instalação direta: utilizar o modo de depuração temporário

Este ramo aplica-se a SLS em execução diretamente no host, não a um contentor nem a /opt/sophos-spl. São necessários privilégios de root e acesso à porta de monitorização local. Numa instalação systemd, verificar previamente com journalctl -u sophoslinuxsensor se o journal corresponde ao serviço e ao host esperados. Se o serviço não existir ou houver várias instâncias do sensor, esclarecer primeiro a sua correspondência.

O comando de host documentado abrange todos os processos ativos no host que correspondam ao padrão sophoslinuxsensor. Não se restringe a uma única instância. Não o executar sem autorização para essas instâncias ou se os nomes dos processos não forem claros.

sudo pkill -SIGUSR2 -f sophoslinuxsensor

Depois disso, o sensor disponibiliza informações de suporte e depuração durante 60 segundos no endpoint de monitorização. Recolher imediatamente no diretório de trabalho preparado:

curl -O http://localhost:9010/support.tar && gzip support.tar

A recolha demora aproximadamente 30 segundos. Após a compressão bem-sucedida, fica disponível support.tar.gz. Esta chamada no host não inclui uma verificação de erros HTTP nem um tempo limite; por isso, a existência de um nome de ficheiro ou uma chamada gzip bem-sucedida não comprova que o arquivo esteja completo. Para a verificação local, sem extrair o pacote:

tar -tzf support.tar.gz

Os registos do host são lidos com:

journalctl -u sophoslinuxsensor

Para observação contínua, está também documentada esta chamada:

journalctl -efu sophoslinuxsensor

Terminar a observação com Ctrl+C e guardar as informações do journal necessárias para o período do erro através do método de exportação aprovado. Não tratar uma saída contínua sem limite como um pacote de suporte concluído.

Verificar o arquivo, isolar o erro e entregar em segurança

Um arquivo de depuração completo contém entradas como runtimedetections.yaml, environment.json, goroutine.out e profile.out, além de informações de métricas e versão. As entradas indicadas são exemplos, não uma garantia de conteúdos idênticos em todas as versões. tar tem de conseguir listar o arquivo sem erros. Uma página de erro HTML, um pacote vazio ou uma transferência interrompida não constituem um resultado utilizável.

Se o pacote contiver apenas metrics.txt e version.json, a recolha de depuração não estava ativa. Verificar a instância de destino, erros no envio do sinal e o intervalo de tempo. Depois, no ramo de implementação adequado, enviar novamente SIGUSR2 e voltar a transferir imediatamente. No ramo Helm, o reencaminhamento de portas tem de estar em execução durante toda a transferência. Encaminhar falhas repetidas para o suporte com a mensagem de erro exata, a versão do sensor e a hora do erro; não as contornar com um modo de depuração permanente ou uma porta de rede aberta.

Os arquivos, registos e perfis podem conter configuração confidencial, variáveis de ambiente e informações do host e do runtime. Mesmo que partes da configuração sejam automaticamente expurgadas, o pacote não fica automaticamente anonimizado para divulgação pública.

Antes do envio, verificar a lista de ficheiros e, quando necessário, os conteúdos num ambiente isolado, procurando credenciais, tokens, nomes de host internos e dados pessoais. Para expurgar dados, utilizar uma cópia separada e documentar as alterações; não alterar perfis binários de forma não controlada. Esclarecer com o suporte quais os conteúdos que são necessários sem alterações para o diagnóstico. Conservar o original apenas com acesso protegido e durante o prazo acordado.

Enviar o arquivo e os registos associados exclusivamente através do canal de suporte Sophos aprovado e confirmado no caso de suporte. Verificar o destinatário e o destino do carregamento com base no caso existente, não numa mensagem não solicitada. Não utilizar um ticket público, fórum, repositório Git ou área de armazenamento de ficheiros multimédia da KB. O pacote deve ser acompanhado pelo tipo de implementação, nós ou hosts afetados, versão do sensor, hora do erro com fuso horário, sintoma e passos de recolha já executados; não enviar credenciais no texto de acompanhamento.

Perfis de CPU e memória apenas quando especificamente necessários

Para um arquivo de suporte normal, basta o sinal temporário. Os perfis individuais seguintes constituem um método separado para problemas de CPU ou memória e utilizam o formato pprof da Google. Para a ativação de depuração configurada de forma permanente, é necessário saber previamente como o serviço SLS real é iniciado e como a sua configuração pode ser reposta.

Primeiro, guardar o conteúdo anterior de /etc/sophos/runtimedetections-rules.yaml, o valor anterior ou a ausência de debug e o ambiente de arranque efetivo. Em particular, determinar se RUNTIMEDETECTIONS_DEBUG já está definida. Uma cópia de segurança dessa configuração também é confidencial. Não a confundir com o ficheiro de nome semelhante runtimedetections.yaml no arquivo de suporte.

Escolher uma das ativações documentadas:

• Executar o sensor com RUNTIMEDETECTIONS_DEBUG=true no seu ambiente de arranque real. Um simples export numa shell de administração não altera o ambiente de um serviço já em execução.
• Definir debug: true em /etc/sophos/runtimedetections-rules.yaml, sem substituir as restantes regras nem criar uma segunda entrada contraditória.

Um reinício interrompe o serviço SLS. A autorização de manutenção, a interrupção tolerável da deteção e o acesso à configuração original têm de estar definidos previamente. Esta chamada systemd aplica-se à instalação direta no host; não é um procedimento de reinício para Helm ou Docker.

Com privilégios de root, executar o reinício documentado:

systemctl restart sophoslinuxsensor

Depois, verificar o estado do serviço e o journal. Só com o serviço em execução e uma configuração válida se devem recolher os perfis necessários no endpoint local:

curl -s http://localhost:9010/debug/pprof/heap > heap.out
curl -s 'http://localhost:9010/debug/pprof/profile?seconds=60' > profile.out

heap.out recolhe amostras da ocupação de memória dos objetos ativos no heap; profile.out recolhe a utilização de CPU durante 60 segundos. Estas chamadas não incluem uma verificação de erros HTTP: a criação de um ficheiro, por si só, não comprova que o perfil seja válido. Não interpretar ficheiros vazios ou uma resposta de erro como valores de medição; verificar o endpoint e a configuração de depuração efetiva e, se necessário, validar o formato com o suporte. Estes ficheiros também permanecem confidenciais.

As métricas, por outro lado, não requerem modo de depuração nem um reinício motivado pela depuração:

curl -s http://localhost:9010/metrics > metrics.out

Repor o estado de depuração e o estado operacional

Na recolha temporária, não enviar mais sinais após a janela de 60 segundos. Deixar o sensor em execução e verificar, com base nos seus registos ou na monitorização operacional existente, se continua a funcionar normalmente. Um processo em execução ou um endpoint de métricas acessível não constituem uma prova completa da deteção e da transmissão de dados. Se o comportamento divergir do esperado, trabalhar com o suporte.

Com a depuração configurada de forma permanente, não existe uma reposição automática após 60 segundos. Repor o valor de debug previamente guardado ou a sua ausência original no ficheiro YAML e repor no estado anterior, na configuração de arranque real, uma variável RUNTIMEDETECTIONS_DEBUG que tenha sido definida apenas para este diagnóstico. Não substituir indiscriminadamente outras definições nem toda a configuração entretanto alterada. A alteração exata do ambiente depende do mecanismo de arranque existente; sem um estado de referência conhecido, não existe um comando universal de reposição segura.

Para o serviço systemd instalado diretamente, após esta reposição, utilizar novamente o comando systemctl restart sophoslinuxsensor apresentado acima, na janela de manutenção aprovada. Verificar o serviço e o journal quanto a erros de arranque ou configuração, comparar a definição de depuração efetiva com o estado anterior e confirmar que não permanece qualquer acesso a perfis que tenha sido ativado apenas para o diagnóstico. Se a depuração já estava ativa anteriormente, a sua desativação é uma decisão operacional adicional e não uma reposição.

Terminar o reencaminhamento de portas Helm e confirmar que o respetivo processo de terminal terminou. O contentor de depuração efémero não pode ser removido do pod existente como um contentor normal; não eliminar um pod de sensor apenas para limpar os elementos deste diagnóstico. Se a política local do cluster exigir a renovação do pod, o operador responsável tem de a planear separadamente, tendo em conta a interrupção da deteção e o controlo do rollout.

Após a confirmação da receção pelo suporte e o fim do prazo de conservação definido, remover os ficheiros de arquivo, registo e perfil concretamente criados, bem como as cópias temporárias expurgadas, de acordo com a política local de eliminação. Não efetuar eliminações com caracteres universais nem eliminar regras do sensor, registos do produto ou outros casos de suporte. A eliminação de um ficheiro não garante a sobrescrita de cópias de segurança, snapshots ou blocos SSD; essa conservação é abrangida pela política de armazenamento e proteção de dados aplicável.