Välja, installera och verifiera Sophos Linux Sensor

Sophos Linux Sensor (SLS) samlar in Linux-körningshändelser och behandlar dem med Detection Content till larm eller konfigurerade åtgärder. Det kan integreras med befintlig logg- och larminfrastruktur. SLS är en separat sensor: det är inte Sophos Protection for Linux (SPL), dess XDR Sensor eller en SPL-policy för runtime-detektering.

För en första pilot kontrolleras plattform och behörighet, installationsmetod väljs och både sensor och innehåll installeras. Därefter följs ett testlarm till den faktiska avsedda mottagaren. En aktiv tjänst räcker inte. Guiden beskriver direkt installation på en systemd-värd; containrar och Kubernetes använder en annan distributionsmetod.

Klargör licens och driftmodell först

Sophos-anvisningen som kontrollerades 27 oktober 2026 anger Sophos XDR Powered by Secureworks (Server), Sophos MDR (Server) eller Sophos MDR Plus (Server) som kvalificerande produkter för SLS. Utvärderingslicenser ger inte rätt till SLS. En godtycklig endpointlicens eller enbart en Linux-server är inget bevis på behörighet.

SLS licensieras per enhet. Enligt Sophos visas instanserna dock varken i Fusions serverlista, Devices-vy eller dess licensräkning. För därför ett separat inventarium över installerade sensorer. Fusion kan ta emot SLS-detekteringsdetaljer och larm men hanterar inte sensorn. En saknad SLS-post i serverlistan är därmed inte detsamma som misslyckad SPL-registrering.

För en vanlig hanterad serveragent med önskade SPL-komponenter används Sophos Protection for Linux. SLS bedöms separat för oföränderliga avbilder eller särskilda containerplattformar; att nämna ett användningsfall godkänner inte varje kombination av distribution, kärna och runtime.

Förbered plattform och pilot

Vid kontrolltillfället kräver aktuella SLS-release notes minst 2 GB ledigt diskutrymme, 2 GB ledigt minne och x86_64 eller ARM64. ARM64 kräver kärna 5.3 eller senare. Den konkreta distributionen, dess aktuella mindre version och körande kärna måste också motsvara listan över testade plattformar. En annan distributions minimikärna är inget generellt godkännande. Legacy-plattformar har separata supportvillkor.

Före piloten dokumenteras värdroll, distribution, arkitektur, kärna, befintligt skydd, belastningsprofil och larmmottagare. Direkt värdinstallation kräver root-/pakethanteringsrättigheter, en lämplig systemd-miljö och det Linux-debuggsubsystem som SLS behöver tillgängligt eller godkänt. Försvaga inte ett härdat system i förväg bara för att ett installationsskript ska fortsätta.

Sophos tillhandahåller en särskild Helm-metod för Kubernetes; Docker, CRI-O och containerd har också egna anvisningar. Registryåtkomst, värdsynlighet, rättigheter, innehållsavbild och runtime ska kontrolleras. Ett paketkommando från värdexemplet ska inte kopieras oförändrat in i en sensorcontainer.

Skapa registrytoken i rätt tenant

SLS använder en separat Package Registry API Token som börjar med SLS-. Den är inte samma sak som den kortlivade OAuth-access token eller en API-identitets Client Secret.

Den aktuella SLS-metoden kräver en Super Admin i kundens Fusion Admin-dashboard, inte en Partner- eller Enterprise-dashboard. Skapa den nödvändiga identiteten under Global Settings > Administration > API Credentials Management > Add Credential med Service Principal Super Admin. Ansvarig ska först godkänna detta omfattande tillverkarkrav; det ska inte bli standardroll för varje API-projekt. Förvara Client ID och det bara en gång visade Client Secret säkert.

Använd processen för API-uppgifter och OAuth för bearer token och identifiera kundens unika tenant-ID genom whoami/v1. Här måste idType bekräfta kundtenanten. Ett partner-ID är inte lämpligt. Skicka sedan en POST till /accounts/v1/access-tokens på Sophos globala API-värd, med bearer-autentisering, X-Tenant-ID och denna JSON:

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

label är ett valfritt administrativt namn medan type är det fasta API-värdet. Använd svarsfältet token för registryåtkomst, inte objektets ID. Välj ett eventuellt expiresAt enligt åtkomstplanen; Sophos anger att ett datum efter serverlicensens slut justeras till det slutdatumet. Ett avlägset exempeldatum bevisar ingen permanent rättighet.

Kontrollera HTTP-status och svarsinnehåll. Token och hemligheter får inte hamna i skalhistorik, proxydiagnostik, ärenden eller skärmbilder. Klargör först fel i tenant, behörighet eller token; ändra inte skydd eller rättigheter i hela tenanten på försök.

Installera direkt på värden med pakethantering

Förbered först SLS-registryåtkomst i godkänd pakethantering. Sophos dokumenterar packages.sophos.com/sophos-linux-sensor/release/ och nyckeln sophos-linux-sensor-archive-keyring.gpg. Hämta nyckeln via den autentiserade tillverkarvägen och spara den som /etc/sophos-linux-sensor.gpg. Verifiera ursprung och aktuellt fingeravtryck via godkänd förtroendekedja före användning. gpg --list-packets visar bara ett läsbart nyckelpaket; det bevisar inte betrott ursprung.

Debian-baserade värdar som stöds

Lägg till källan i en lämplig .list-fil under /etc/apt/sources.list.d/:

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

Spara tillhörande token i en åtkomstskyddad .conf-fil under /etc/apt/auth.conf.d/:

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

Ersätt platshållaren med den token som faktiskt erhållits. Endast nödvändiga privilegierade pakethanteringsprocesser ska kunna läsa filen; lägg inte dessutom token i repository-URL:en. Kör följande i godkänt ändringsfönster efter kontroll av signaturförtroende, källa och filrättigheter:

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

RPM-baserade värdar som stöds

RPM-metoden använder en separat .repo-fil under /etc/yum.repos.d/. Sektions- och visningsnamnet nedan är valfria exempel; URL, signaturkontroll och nyckelsökväg följer den dokumenterade metoden:

[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

Ersätt platshållaren med mottagen token. Begränsa åtkomsten till filen som innehåller den. URL:en får inte exponeras i diagnostikloggar, ärenden eller skärmbilder. Ersätt inte befintliga distributionsrepositorier och stäng inte av signaturkontroll. Visningsnamnet godkänner inte en viss distribution eller version.

Med källan korrekt konfigurerad anger Sophos dessa paket:

sudo yum install sophoslinuxsensor-systemd sophoslinuxcontent

Använd bara paketmetoden för den faktiskt stödda distributionen. Både sensor och innehåll behövs. Zero policies configured betyder att detekteringsacceptansen inte är godkänd även om processen körs. Gamla versionsnummer i tillverkarens exempelutdata är inga aktuella installationskrav.

Konfigurera tenant och larmutgång

Sätt customer_id i /etc/sophos/runtimedetections.yaml till det verifierade tenant-ID:t. Komplettera befintliga YAML-inställningar selektivt i stället för att skriva över hela filen med ett exempel. Kontrollera syfte och datagodkännande för telemetriöverföring och larmdestinationer före start. Sophos beskriver utmatning till stdout som standard; det ansluter inte automatiskt varje önskad mottagare.

För den första kontrollen dokumenteras den konkreta utgången: lokal journal, befintligt loggsystem eller uttryckligen konfigurerad Sophos-mottagare. Ställ in uppgifter, destination och format för denna utgång. En registrerad token bevisar inte fungerande larmvidarebefordran.

Starta och kontrollera sedan på den direkta systemd-värden:

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

Vid startfel kontrolleras först plattform, paket, faktisk YAML-konfiguration och de rättigheter som journalen anger. Tillverkarens installationsguide beskriver nödvändiga Linux-capabilities; ersätt dem inte med generellt privilegierade containrar eller en okontrollerad setcap på valfria filer.

Verifiera detektering hela vägen till mottagaren

Med Default Content installerat och sensorn aktiv kan det dokumenterade testlarmet genereras på en godkänd pilot. Kontrollera först syntaxen för installerad version: installationsguiden visar på ett ställe -test-alert, medan den särskilda testguiden använder --test-alert. Använd bara följande kommando om versionen stöder skrivsättet:

sophoslinuxsensor --test-alert

Testet skapar avsiktligt en händelse. Samordna det med mottagarteamet i stället för att köra ett oanmält produktionstest. Alert Tester ska nå den konfigurerade utgången. Värd, tid och mottagare måste stämma; ett lyckat kommando eller en lokal loggrad bekräftar inte fjärrleverans.

Om syntaxen inte stöds eller det väntade larmet uteblir används inte verklig skadlig kod eller en okontrollerad attack som ersättning.

Acceptansen dokumenterar minst sensor-/innehållsversioner, faktiska regler, felfri start, testlarm och verklig mottagning. Testet bekräftar den vägen, inte varje detektering, belastningssituation eller rätt till MDR-utredning. Jämför ytterligare pilotbelastning och applikationsdrift med utgångsläget.

Regler, uppdateringar och driftproblem

Standardinnehållet finns i /var/lib/sophos/content/runtimedetections-content.yaml och skrivs över vid uppdatering. Anpassningar hör hemma i /etc/sophos/runtimedetections-rules.yaml, inte direkt i tillverkarfilen. Enligt detekteringshjälpen stöder Sophos oförändrat standardinnehåll; stöd för ändrade eller egna regler behöver klargöras separat.

Core- och Enhanced-detekteringar skiljer sig i djup och belastningspåverkan. Mer innehåll är inte automatiskt bättre för varje serverlast utan pilot. Uppdatera sensor och innehåll via rätt paket- eller containerutrullning och kontrollera sedan igen; en enda installationskontroll ersätter inte uppdateringsdrift.

Vid saknade larm undersöks innehåll, inlästa regler, händelse, utgång och vidarebefordran separat. Samla in SLS-supportdata säkert beskriver djupare loggar och diagnostikpaket samt skilda metoder för Helm, Docker och värdar. Förbered ett planerat avvecklande med dokumenterade utgångsvärden, kvarstående skyddsbehov och rätt avinstallationsmetod från tillverkaren. Radera inte andra värdars tjänster eller uppgifter.