Sophos Linux Sensor kiezen, installeren en controleren

Sophos Linux Sensor (SLS) verzamelt Linux-runtimegebeurtenissen en verwerkt deze met Detection Content tot alerts of ingestelde reacties. Integratie met bestaande logging- en alertinfrastructuur is mogelijk. SLS is een aparte sensor: het is niet Sophos Protection for Linux (SPL), de bijbehorende XDR Sensor of een SPL-runtime-detectiebeleid.

Controleer voor een eerste pilot platform en aanspraak, kies de installatiemethode en implementeer sensor én content. Volg daarna een testalert tot bij de daadwerkelijk bedoelde ontvanger. Alleen een actieve dienst is onvoldoende. Deze handleiding beschrijft rechtstreekse installatie op een systemd-host; containers en Kubernetes gebruiken een andere implementatiemethode.

Eerst licentie en beheermodel vaststellen

De op 27 oktober 2026 gecontroleerde Sophos-instructies noemen Sophos XDR Powered by Secureworks (Server), Sophos MDR (Server) of Sophos MDR Plus (Server) voor SLS-toegang. Evaluatielicenties geven geen recht op SLS. Een willekeurige endpointlicentie of alleen de aanwezigheid van een Linux-server is geen aanspraakbewijs.

SLS heeft licenties per apparaat. Volgens Sophos verschijnen de instanties echter niet in de Fusion-serverlijst, de Devices-weergave of de bijbehorende licentietelling. Houd daarom een eigen sensorinventaris bij. Fusion kan SLS-detectiedetails en alerts ontvangen, maar beheert de sensor niet. Een ontbrekende SLS-serververmelding is dus niet hetzelfde als mislukte SPL-registratie.

Gebruik voor een normale beheerde serveragent met de benodigde SPL-componenten Sophos Protection for Linux. Beoordeel SLS voor immutable images of bijzondere containerplatforms afzonderlijk; vermelding van een toepassing is geen vrijgave voor elke distributie-, kernel- en runtimecombinatie.

Platform en pilot voorbereiden

De actuele SLS-release notes vereisen op het controlemoment minstens 2 GB vrije schijfruimte, 2 GB vrij geheugen en x86_64 of ARM64. ARM64 vereist kernel 5.3 of nieuwer. Ook de concrete distributie, actuele minorversie en actieve kernel moeten bij de geteste platformlijst passen. De minimumkernel van een andere distributie is geen algemene vrijgave. Legacy-platforms hebben afzonderlijke supportvoorwaarden.

Leg vóór de pilot hostrol, distributie, architectuur, kernel, bestaande beveiligingssoftware, belastingsprofiel en alertontvanger vast. Rechtstreekse installatie vereist root-/pakketbeheerrechten, een geschikte systemd-omgeving en het vereiste Linux-debugsubsysteem, beschikbaar of goedgekeurd. Verzwak een gehard systeem niet preventief om een installatiescript te laten doorgaan.

Sophos biedt een eigen Helm-methode voor Kubernetes; ook Docker, CRI-O en containerd hebben specifieke instructies. Registrytoegang, zicht op de host, rechten, contentimage en runtime horen bij de controle. Neem een pakketcommando uit dit hostvoorbeeld niet ongewijzigd over in een sensorcontainer.

Registrytoken in de juiste tenant verkrijgen

SLS gebruikt een apart Package Registry API Token dat met SLS- begint. Het is niet het kortlevende OAuth-access token of het Client Secret van een API-identiteit.

De huidige SLS-procedure vereist een Super Admin in het Fusion Admin-dashboard van de klant, niet een Partner- of Enterprise-dashboard. Maak onder Global Settings > Administration > API Credentials Management > Add Credential de benodigde identiteit met Service Principal Super Admin. De verantwoordelijke eigenaar keurt deze ruime fabrikantvereiste vooraf goed; dit is niet de standaardrol voor willekeurige API-projecten. Bewaar Client ID en het slechts eenmaal getoonde Client Secret veilig.

Gebruik het proces voor API-credentials en OAuth voor het bearer token en bepaal via whoami/v1 de unieke klanttenant-ID. Voor deze route moet idType de klanttenant bevestigen. Een partner-ID is ongeschikt. Stuur vervolgens een POST naar /accounts/v1/access-tokens op de globale Sophos-API-host, met bearer-authenticatie, X-Tenant-ID en deze JSON:

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

label is een vrij gekozen beheernaam; type is de vaste API-waarde. Gebruik het antwoordveld token voor registrytoegang, niet de object-ID. Kies een optionele expiresAt volgens het toegangsplan; Sophos stelt dat een datum voorbij het einde van de serverlicentie daartoe wordt teruggebracht. Een verre voorbeelddatum bewijst geen permanente aanspraak.

Controleer HTTP-status en antwoordinhoud. Tokens en geheimen mogen niet in shellgeschiedenis, proxydiagnostiek, tickets of screenshots terechtkomen. Los fouten in tenant, aanspraak of token eerst op; wijzig niet op goed geluk tenantbreed beveiliging of rechten.

Rechtstreeks via pakketbeheer installeren

Richt eerst SLS-registrytoegang in via het goedgekeurde pakketbeheer. Sophos documenteert packages.sophos.com/sophos-linux-sensor/release/ en de sleutel sophos-linux-sensor-archive-keyring.gpg. Haal deze via de geauthenticeerde fabrikantmethode op en sla hem op als /etc/sophos-linux-sensor.gpg. Controleer vóór gebruik herkomst en actuele fingerprint via de goedgekeurde vertrouwensketen. gpg --list-packets toont alleen een leesbaar sleutelpakket; dat bewijst geen vertrouwde herkomst.

Ondersteunde Debian-hosts

Voeg de bron toe in een geschikt .list-bestand onder /etc/apt/sources.list.d/:

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

Sla het bijbehorende token op in een afgeschermd .conf-bestand onder /etc/apt/auth.conf.d/:

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

Vervang de tijdelijke aanduiding door het daadwerkelijk ontvangen token. Alleen de noodzakelijke bevoorrechte pakketbeheerprocessen mogen het bestand lezen; zet het token niet ook in de repository-URL. Voer na controle van ondertekening, bron en bestandsrechten tijdens het goedgekeurde wijzigingsvenster uit:

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

Ondersteunde RPM-hosts

De RPM-route gebruikt een apart .repo-bestand onder /etc/yum.repos.d/. Sectienaam en weergavenaam hieronder zijn vrij gekozen voorbeelden; URL, handtekeningcontrole en sleutelpad volgen de gedocumenteerde registrymethode:

[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

Vervang de tijdelijke aanduiding door het ontvangen token. Scherm het bestand met het token af. De URL mag niet zichtbaar worden in diagnoselogs, tickets of screenshots. Vervang bestaande distributierepositories niet en schakel handtekeningcontroles niet uit. De weergavenaam is geen vrijgave van een distributie of versie.

Na correcte bronconfiguratie noemt Sophos deze pakketten:

sudo yum install sophoslinuxsensor-systemd sophoslinuxcontent

Gebruik uitsluitend de pakketmethode voor de werkelijk ondersteunde distributie. Sensor en content zijn beide nodig. Zero policies configured betekent dat detectie niet is geaccepteerd, ook als het proces draait. Oude versienummers in fabrikantsvoorbeelden zijn geen actuele installatievoorschriften.

Tenant en alertuitvoer configureren

Stel customer_id in /etc/sophos/runtimedetections.yaml in op de gecontroleerde tenant-ID. Vul bestaande YAML-instellingen gericht aan, in plaats van het hele bestand met een voorbeeld te overschrijven. Controleer vóór de start doel en gegevenstoestemming voor telemetrieoverdracht en alertbestemmingen. Sophos beschrijft standaarduitvoer naar stdout; daarmee is niet iedere gewenste ontvanger automatisch verbonden.

Leg voor de eerste controle de concrete uitvoer vast: lokaal journal, bestaand logsysteem of expliciet ingestelde Sophos-ontvanger. Configureer credentials, bestemming en formaat voor die uitvoer. Een token registreren bewijst niet dat alerts worden doorgestuurd.

Start en controleer op de directe systemd-host vervolgens:

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

Controleer bij startfouten eerst platform, pakketten, effectieve YAML-configuratie en de rechten die het journal noemt. De fabrikant beschrijft de noodzakelijke Linux-capabilities; vervang die niet door onbeperkt bevoorrechte containers of een ongecontroleerde setcap op willekeurige bestanden.

Detectie tot bij de ontvanger valideren

Met geïnstalleerde Default Content en een actieve sensor kan op een goedgekeurde pilot het gedocumenteerde testalert worden opgewekt. Controleer eerst de syntaxis voor de geïnstalleerde versie: de installatiehandleiding toont eenmaal -test-alert, de aparte testhandleiding gebruikt --test-alert. Gebruik het volgende commando alleen als die versie deze schrijfwijze ondersteunt:

sophoslinuxsensor --test-alert

De test genereert bewust een gebeurtenis. Stem dit af met het ontvangende team; voer geen onaangekondigde productietest uit. Verwacht Alert Tester op de ingestelde uitvoer. Host, tijd en ontvanger moeten overeenkomen; een geslaagd commando of lokaal logbericht bewijst geen aflevering op afstand.

Is de syntaxis niet ondersteund of ontbreekt het alert, gebruik dan geen echte kwaadaardige code of ongecontroleerde aanval als vervanging.

Acceptatie legt minstens sensor-/contentversies, effectieve regels, foutloze start, testalert en daadwerkelijke ontvangst vast. Dit bevestigt die route, niet iedere detectie, belastingstoestand of aanspraak op MDR-onderzoek. Vergelijk aanvullende pilotbelasting en applicatiewerking met de uitgangssituatie.

Regels, updates en operationele problemen

Het standaardcontentpakket staat in /var/lib/sophos/content/runtimedetections-content.yaml en wordt bij updates overschreven. Wijzigingen horen in /etc/sophos/runtimedetections-rules.yaml, niet rechtstreeks in het fabrikantbestand. Volgens de detectiedocumentatie ondersteunt Sophos ongewijzigde standaardcontent; regel ondersteuning voor gewijzigde of eigen regels afzonderlijk.

Core- en Enhanced-detecties verschillen in diepgang en belasting. Meer content is zonder pilot niet automatisch beter voor iedere serverlast. Werk sensor en content bij via de passende pakket- of containeruitrol en valideer opnieuw; eenmalige installatiecontrole vervangt geen updatebeheer.

Onderzoek bij ontbrekende alerts content, geladen regels, gebeurtenis, uitvoer en doorsturen afzonderlijk. SLS-supportgegevens veilig verzamelen behandelt diepere logs en diagnosepakketten, inclusief aparte Helm-, Docker- en hostmethoden. Bereid geplande verwijdering voor met vastgelegde uitgangswaarden, resterende beveiligingsbehoefte en de passende fabrikantprocedure. Verwijder geen diensten of credentials van andere hosts.