Escolher, instalar e verificar Sophos Linux Sensor

Sophos Linux Sensor (SLS) recolhe eventos de execução Linux e processa-os com Detection Content para gerar alertas ou respostas configuradas. Pode integrar-se com a infraestrutura existente de logs e alertas. SLS é um sensor separado: não é Sophos Protection for Linux (SPL), o respetivo XDR Sensor nem uma política SPL de deteção em execução.

Num primeiro piloto verificam-se plataforma e direito, escolhe-se o método e implementam-se sensor e conteúdo. Depois segue-se um alerta de teste até ao destinatário efetivamente previsto. Um serviço ativo não basta. Esta orientação descreve a instalação direta num host systemd; contentores e Kubernetes usam outro método de implementação.

Clarificar licença e modelo operacional

As instruções Sophos verificadas em 27 de outubro de 2026 indicam Sophos XDR Powered by Secureworks (Server), Sophos MDR (Server) ou Sophos MDR Plus (Server) para acesso a SLS. Licenças de avaliação não são elegíveis. Uma licença endpoint qualquer ou a simples existência de um servidor Linux não comprovam o direito.

SLS é licenciado por dispositivo. No entanto, segundo a Sophos, as instâncias não aparecem na lista de servidores Fusion, na vista Devices nem na sua contagem de licenças. Mantém-se, por isso, um inventário separado dos sensores. Fusion pode receber detalhes de deteção e alertas SLS, mas não gere o sensor. A ausência de uma entrada de servidor SLS não equivale a falha de registo SPL.

Para um agente de servidor gerido convencional com os componentes SPL necessários, usa-se Sophos Protection for Linux. SLS é avaliado separadamente para imagens imutáveis ou plataformas especiais de contentores; mencionar esse uso não aprova todas as combinações de distribuição, kernel e runtime.

Preparar plataforma e piloto

As notas SLS atuais exigem, à data de verificação, pelo menos 2 GB de espaço livre em disco, 2 GB de memória livre e x86_64 ou ARM64. ARM64 exige kernel 5.3 ou posterior. A distribuição concreta, versão menor atual e kernel em execução também devem corresponder à lista de plataformas testadas. O mínimo de outra distribuição não é uma aprovação universal. Plataformas legacy têm condições de suporte separadas.

Antes do piloto registam-se função do host, distribuição, arquitetura, kernel, proteção existente, perfil de carga e destinatário de alertas. A instalação direta exige permissões root/gestão de pacotes, um sistema systemd adequado e o subsistema de debug Linux necessário disponível ou autorizado. Não se enfraquece preventivamente um sistema reforçado só para avançar um script.

A Sophos disponibiliza um método Helm próprio para Kubernetes; Docker, CRI-O e containerd também têm instruções específicas. Verificam-se acesso ao registo, visibilidade do host, permissões, imagem de conteúdo e runtime. Uma ordem de pacotes deste exemplo não se transpõe sem alterações para um contentor do sensor.

Preparar o token de registo no tenant correto

SLS usa um Package Registry API Token separado que começa por SLS-. Não é o access token OAuth temporário nem o Client Secret de uma identidade API.

O procedimento SLS atual exige um Super Admin no dashboard Fusion Admin do cliente, não no de Partner ou Enterprise. Em Global Settings > Administration > API Credentials Management > Add Credential, cria-se a identidade necessária com Service Principal Super Admin. O responsável autoriza primeiro este requisito amplo do fabricante; não se torna a função padrão de qualquer projeto API. Client ID e Client Secret, visível apenas uma vez, são conservados em segurança.

O processo de credenciais API e OAuth permite obter o bearer token e determinar o ID único do tenant cliente através de whoami/v1. Neste percurso, idType deve confirmar o tenant cliente. Um identificador de parceiro não é adequado. Depois envia-se um POST para /accounts/v1/access-tokens no host API global Sophos, com autenticação Bearer, X-Tenant-ID e este JSON:

{
  "label": "SLS Pilot",
  "type": "sophosLinuxSensor"
}

label é um nome administrativo livre; type é o valor API fixo. Usa-se o campo token da resposta para o registo, não o ID do objeto. O expiresAt opcional é escolhido segundo o plano de acesso; a Sophos indica que uma data posterior à expiração da licença de servidor é reduzida a essa expiração. Uma data distante de exemplo não comprova um direito permanente.

Verificam-se estado e conteúdo da resposta HTTP. Tokens e segredos não devem surgir no histórico da shell, diagnósticos proxy, tickets ou capturas. Erros de tenant, direito ou token esclarecem-se primeiro; não se alteram à experiência proteções ou permissões de todo o tenant.

Instalar no host através de pacotes

Prepara-se primeiro o acesso ao registo SLS na gestão de pacotes aprovada. A Sophos documenta packages.sophos.com/sophos-linux-sensor/release/ e a chave sophos-linux-sensor-archive-keyring.gpg. Obtém-se a chave pelo percurso autenticado do fabricante e guarda-se em /etc/sophos-linux-sensor.gpg. Antes do uso verificam-se origem e fingerprint atual pela cadeia de confiança aprovada. gpg --list-packets mostra apenas um pacote de chave legível; não demonstra por si só uma origem fiável.

Hosts Debian suportados

Adiciona-se a fonte num ficheiro .list adequado em /etc/apt/sources.list.d/:

deb [signed-by=/etc/sophos-linux-sensor.gpg] https://packages.sophos.com/sophos-linux-sensor/release/ stable main

O token associado é guardado num ficheiro .conf com acesso restrito em /etc/apt/auth.conf.d/:

machine packages.sophos.com login <SLS-REGISTRY-TOKEN>

Substitui-se o marcador pelo token recebido. Só os processos privilegiados necessários à gestão de pacotes devem ler o ficheiro; não se coloca o token também no URL do repositório. Após verificar confiança da assinatura, fonte e permissões do ficheiro, executa-se na janela aprovada:

sudo apt-get update
sudo apt-get install sophoslinuxsensor-systemd sophoslinuxcontent

Hosts RPM suportados

O método RPM usa um ficheiro .repo separado em /etc/yum.repos.d/. Os nomes de secção e apresentação são exemplos livres; URL, verificação de assinatura e caminho da chave correspondem ao método documentado:

[sls]
name=Sophos Linux Sensor
baseurl=https://<SLS-REGISTRY-TOKEN>@packages.sophos.com/sophos-linux-sensor/release/
gpgcheck=1
enabled=1
gpgkey=file:///etc/sophos-linux-sensor.gpg

Substitui-se o marcador pelo token recebido. O acesso ao ficheiro que o contém é restrito. O URL não deve aparecer em logs de diagnóstico, tickets ou capturas. Não se substituem repositórios existentes nem se desligam verificações de assinatura. O nome apresentado não aprova uma distribuição ou versão concreta.

Com a fonte corretamente configurada, a Sophos indica estes pacotes:

sudo yum install sophoslinuxsensor-systemd sophoslinuxcontent

Usa-se apenas o método adequado à distribuição efetivamente suportada. Sensor e conteúdo são necessários. Zero policies configured significa que a aceitação da deteção falhou, mesmo que o processo esteja ativo. Versões antigas nas saídas de exemplo do fabricante não são requisitos atuais de instalação.

Configurar tenant e saída dos alertas

Em /etc/sophos/runtimedetections.yaml define-se customer_id com o tenant verificado. Complementam-se as definições YAML de forma seletiva, sem substituir todo o ficheiro por um exemplo. Antes do arranque verificam-se finalidade e autorização dos dados de telemetria e destinos de alerta. A Sophos descreve saída para stdout por predefinição; isso não liga automaticamente todos os destinatários pretendidos.

Na primeira verificação regista-se o destino real: journal local, sistema de logs existente ou destinatário Sophos configurado explicitamente. Credenciais, destino e formato são preparados para essa saída. Registar um token não prova o encaminhamento de alertas.

No host systemd direto inicia-se e verifica-se:

sudo systemctl start sophoslinuxsensor
sudo systemctl status sophoslinuxsensor
sudo journalctl -u sophoslinuxsensor

Em falhas de arranque verificam-se primeiro plataforma, pacotes, YAML efetivo e permissões indicadas no journal. A instalação do fabricante descreve as Linux Capabilities necessárias; não se substituem por contentores indiscriminadamente privilegiados ou setcap não verificado em ficheiros arbitrários.

Validar a deteção até ao destinatário

Com Default Content instalado e sensor ativo pode gerar-se o alerta documentado num piloto autorizado. Verifica-se primeiro a sintaxe da versão instalada: a instalação mostra num ponto -test-alert, enquanto a orientação específica de teste usa --test-alert. O comando seguinte só se usa se essa versão aceitar esta forma:

sophoslinuxsensor --test-alert

O teste gera deliberadamente um evento. É coordenado com a equipa destinatária, não executado às escondidas em produção. Espera-se Alert Tester na saída configurada. Host, hora e destinatário devem coincidir; executar o comando com sucesso ou ver um log local não confirma entrega remota.

Se a sintaxe não for suportada ou faltar o alerta, não se recorre a código malicioso real ou ataque descontrolado como substituição.

A aceitação documenta no mínimo versões sensor/conteúdo, regras efetivas, arranque sem erros, alerta de teste e receção real. Confirma esse percurso, não todas as deteções, situações de carga ou direito a investigação MDR. Comparam-se a carga adicional do piloto e o funcionamento das aplicações com o estado inicial.

Regras, atualizações e problemas operacionais

O conteúdo padrão reside em /var/lib/sophos/content/runtimedetections-content.yaml e é substituído nas atualizações. As alterações vão para /etc/sophos/runtimedetections-rules.yaml, não diretamente para o ficheiro do fabricante. Segundo a documentação de deteção, a Sophos suporta o conteúdo padrão inalterado; o apoio a regras modificadas ou próprias é esclarecido separadamente.

Core e Enhanced diferem em profundidade e impacto na carga. Mais conteúdo sem piloto não é automaticamente melhor para qualquer servidor. Sensor e conteúdo são atualizados pelo rollout adequado de pacotes ou contentores e novamente verificados; uma aceitação inicial não substitui a gestão das atualizações.

Se faltarem alertas, investigam-se separadamente conteúdo, regras carregadas, evento, saída e encaminhamento. Recolher dados de suporte SLS em segurança explica logs e diagnósticos, incluindo as vias distintas Helm, Docker e host. Uma remoção planeada usa valores iniciais documentados, proteção restante e procedimento de desinstalação pertinente. Não se apagam serviços ou credenciais de outros hosts.