Sophos Linux Sensor: samla supportdata säkert

Vid problem med Sophos Linux Sensor (SLS) samlar man in ett supportarkiv och relevanta sensorloggar, helst medan felet pågår eller omedelbart efteråt. Insamlingen tar ungefär 30 sekunder. Fastställ först driftsättet: med Helm samlas data in per berörd nod, med Docker på Docker-värden och vid en direkt installation på Linux-värden. Efter felsökningssignalen måste nedladdningen ske omedelbart; det tillfälliga felsökningsfönstret är 60 sekunder.

Den här anvisningen gäller endast Sophos Linux Sensor. SLS är varken Sophos Protection for Linux (SPL), dess XDR Sensor eller dess Linux Runtime Detection-policy. Placeringen i serveröversikten är till för navigering och gör inte produkterna likvärdiga. För SPL gäller den separata installations- och driftanvisningen; följande SLS-kommandon får inte användas där.

Kontrollera målsystem och godkännande före insamlingen

Innan en signal skickas eller en omstart görs bekräftar man utifrån driftsättningsinventeringen och den körande instansen att det faktiskt är SLS som berörs. Värd eller kluster, namnrymd, podd, nod eller container, installerad sensorversion och tidpunkt för felet med tidszon dokumenteras i supportärendet. Versionsinformationen i det senare arkivet kompletterar denna koppling. Den här anvisningen följer supportflödet som uppdaterades den 5 oktober 2026; detta innebär inte någon minimiversion eller något godkännande för alla äldre sensor-, Helm-, Kubernetes- eller Docker-versioner. Vid avvikande namn, portar eller en saknad övervakningsändpunkt ska den faktiska driftsättningen först klarläggas med supporten.

Man behöver en åtkomstskyddad arbetskatalog med tillräckligt mycket ledigt utrymme. Filnamnen som visas nedan är relativa till denna katalog; spara befintliga paket separat innan insamlingen upprepas så att de inte skrivs över. Begränsa åtkomsten till arkiv, loggar och profiler till ansvariga personer och fastställ en lagringstid. Övervakningsadresserna ska förbli lokala för nedladdningar. Skapa ingen offentlig Service, Ingress eller allmänt åtkomlig felsökningsport.

Verktygen måste redan vara godkända och tillgängliga. Om curl saknas på en Linux-värd med direkt installation dokumenterar arbetsflödet följande installationskommandon:

# Red Hat-baserade system
sudo yum install curl

# Ubuntu
sudo apt-get install curl

Använd endast det kommando som passar distributionen inom den godkända pakethanteringsprocessen. En paketinstallation ändrar värden; den ingår inte i en ren granskning av artikeln. För Helm och Docker behövs även tar och gzip. Avbryt före aktivering av felsökning om nödvändiga verktyg eller behörigheter saknas.

Helm: ett paket per berörd nod

På administrationsdatorn måste kubectl vara konfigurerat för rätt kluster. Behörigheten måste tillåta att poddar listas, poddloggar läses, poddportar vidarebefordras och en efemär felsökningscontainer läggs till. Dessutom måste containrarnas körmiljö stödja att en annan containers processnamnrymd anges som mål. curl, tar och gzip behövs på denna dator.

Klustret måste kunna hämta busybox:latest. Om detta register inte är godkänt ska avbildningen först speglas till ett godkänt, åtkomligt register, och endast värdet för --image ersättas med denna kontrollerade avbildningsreferens. Lätta inte på registrets säkerhetsregler för att tvinga fram insamlingen. Den efemära containern innebär en ändring av podden; den kräver ett lämpligt driftgodkännande.

Välj podd och håll portvidarebefordran öppen

SLS-Helm-chartet tillhandahåller en sensorpodd per övervakad Linux-nod. Ersätt <namespace> med namnrymden för SLS-releasen:

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

Utdata måste koppla sensorpodden till den berörda noden. <sensor-pod> är just denna podd och <node-name> är dess nodnamn. Använd inte en godtycklig fungerande podd från samma release.

Vidarebefordra övervakningsporten i den första terminalen:

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

Denna terminal ska hållas öppen tills nedladdningen är slutförd. Om den lokala porten redan används ska du stoppa förloppet och reda ut konflikten i stället för att avsluta en annan process. Lägg inte till någon bindning till offentligt åtkomliga adresser. Om vidarebefordran avbryts måste den vara igång igen före en ny nedladdning.

Skicka signalen, ladda ned omedelbart och komplettera med loggar

I den andra terminalen riktas felsökningscontainern mot SLS-containern. Kommandot skickar SIGUSR2 till sensorprocessen; det är inte en instruktion att avsluta sensorn:

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

Sökmönstret [s]ophoslinuxsensor förhindrar att pkill träffar sin egen kommandorad. Om hämtningen av avbildningen misslyckas, behörighet saknas eller processen inte kan anges som mål har insamlingen inte aktiverats tillförlitligt. Lägg inte till fler felsökningscontainrar i blindo; klarlägg först felmeddelandet.

Ladda ned direkt därefter i den andra terminalen:

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 begränsar HTTP-anropet men förlänger inte felsökningsfönstret. Spara därefter de aktuella loggarna från samma container och nod:

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

Lista innehållet utan att packa upp:

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

Efter fullständighetskontrollen som beskrivs nedan avslutar du portvidarebefordran i den första terminalen med Ctrl+C. Använd en egen podd och unika filnamn för varje ytterligare berörd nod.

Docker: kontrollera körande container och publicerad port

Alla följande kommandon körs på Docker-värden med den Docker-behörighet som är godkänd där. SLS-containern måste vara igång; dess övervakningsport måste redan vara publicerad till värden. Standardporten i containern är 9010. curl, tar och gzip måste finnas. Här föreskrivs varken publicering av en port i efterhand eller omstart av en container som reparationsåtgärd.

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

<sensor-container> är namnet eller ID:t för den bekräftade SLS-containern. Det andra kommandots utdata anger värdadress och värdport. <host-port> ersätts med denna port, inte automatiskt med 9010. Följande nedladdning förutsätter att den publicerade adressen är åtkomlig via 127.0.0.1 på denna Docker-värd. Om bindningen enbart gäller en annan adress eller om utdata saknas ska driftsättningen kontrolleras först; lägg inte till någon offentligt åtkomlig port.

Följande kommando ändrar felsökningstillståndet i 60 sekunder. docker kill får då inte köras utan --signal=SIGUSR2:

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

Hämta från den publicerade lokala ändpunkten omedelbart därefter:

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

Loggar och arkivkontroll ingår i samma paket:

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

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

Det tillfälliga felsökningsläget avslutas automatiskt. En ny kontroll med docker ps måste fortfarande visa den avsedda körande containern; detta bevisar dock inte i sig att detekteringen fungerar.

Linux-värd med direkt installation: använd tillfälligt felsökningsläge

Denna gren gäller SLS som körs direkt på värden, inte en container och inte /opt/sophos-spl. Root-behörighet och åtkomst till den lokala övervakningsporten krävs. Vid en systemd-installation ska du i förväg använda journalctl -u sophoslinuxsensor för att kontrollera att journalen tillhör den förväntade tjänsten och värden. Om tjänsten saknas eller det finns flera sensorinstanser ska deras kopplingar först klarläggas.

Det dokumenterade värdkommandot träffar alla aktiva processer som matchar mönstret sophoslinuxsensor på värden. Det avgränsar inte till en enskild instans. Kör det inte utan godkännande för dessa instanser eller om processnamnen är oklara.

sudo pkill -SIGUSR2 -f sophoslinuxsensor

Sensorn tillhandahåller därefter support- och felsökningsinformation vid övervakningsändpunkten i 60 sekunder. Samla omedelbart in data i den förberedda arbetskatalogen:

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

Insamlingen tar ungefär 30 sekunder. Efter lyckad komprimering finns support.tar.gz. Detta värdanrop innehåller varken kontroll av HTTP-fel eller timeout; ett befintligt filnamn eller ett lyckat gzip-anrop är därför inget bevis för ett fullständigt arkiv. För lokal kontroll utan att packa upp paketet:

tar -tzf support.tar.gz

Värdloggarna läser man med:

journalctl -u sophoslinuxsensor

För löpande observation finns dessutom detta dokumenterade anrop:

journalctl -efu sophoslinuxsensor

Avsluta observationen med Ctrl+C och spara den journalinformation som behövs för felperioden via den godkända exportvägen. Behandla inte obegränsad löpande utdata som ett färdigt supportpaket.

Kontrollera arkivet, avgränsa felet och överlämna säkert

Ett fullständigt felsökningsarkiv innehåller poster som runtimedetections.yaml, environment.json, goroutine.out och profile.out, samt mätvärdes- och versionsinformation. De nämnda posterna är exempel, inte ett löfte om identiskt innehåll i varje version. tar måste kunna lista arkivet utan fel. En HTML-felsida, ett tomt paket eller en avbruten nedladdning är inte ett användbart resultat.

Om paketet endast innehåller metrics.txt och version.json var felsökningsinsamlingen inte aktiv. Kontrollera målinstans, signalfel och tidsintervallet. Skicka sedan SIGUSR2 igen i rätt driftsättningsgren och ladda omedelbart ned på nytt. I Helm-grenen måste portvidarebefordran vara igång under hela nedladdningen. Eskalera upprepade misslyckanden till supporten med exakt felmeddelande, sensorversion och tidpunkt för felet; kringgå dem inte genom permanent felsökningsläge eller en öppen nätverksport.

Arkiv, loggar och profiler kan innehålla konfidentiell konfiguration, miljövariabler samt värd- och körningsinformation. Även om delar av konfigurationen maskeras automatiskt är paketet inte automatiskt anonymiserat för offentlig delning.

Före överföringen ska fillistan och, i den mån det behövs, innehållet granskas i en isolerad miljö med avseende på inloggningsuppgifter, token, interna värdnamn och personuppgifter. Använd en separat kopia för maskering och dokumentera ändringarna; ändra inte binära profiler okontrollerat. Klarlägg med supporten vilket innehåll som behövs oförändrat för diagnosen. Förvara originalet åtkomstskyddat och behåll det endast under den överenskomna tiden.

Överför arkivet och tillhörande loggar endast via den godkända Sophos-supportkanal som bekräftats i supportärendet. Verifiera mottagaren och uppladdningsmålet utifrån det befintliga ärendet, inte utifrån ett oombett meddelande. Använd inte ett offentligt ärende, forum, Git-arkiv eller en medielagringsplats för kunskapsbasen. Till paketet hör driftsättningstyp, berörda noder eller värdar, sensorversion, tidpunkt för felet med tidszon, symtom och redan utförda insamlingssteg; skicka inga inloggningsuppgifter som följtext.

CPU- och minnesprofiler endast vid specifikt behov

För ett normalt supportarkiv räcker den tillfälliga signalen. Följande enskilda profiler är en separat metod för CPU- eller minnesproblem och använder Googles pprof-format. Innan felsökning aktiveras permanent via konfigurationen måste det vara klarlagt hur den faktiska SLS-tjänsten startas och hur dess konfiguration kan återställas.

Spara först det befintliga innehållet i /etc/sophos/runtimedetections-rules.yaml, det befintliga värdet för debug eller uppgiften att det saknas, samt den gällande startmiljön. Fastställ särskilt om RUNTIMEDETECTIONS_DEBUG redan är satt. En säkerhetskopia av denna konfiguration är också konfidentiell. Förväxla den inte med filen med det liknande namnet runtimedetections.yaml i supportarkivet.

Välj en av de dokumenterade aktiveringsmetoderna:

Kör sensorn med RUNTIMEDETECTIONS_DEBUG=true i dess faktiska startmiljö. Enbart ett export i ett administrationsskal ändrar inte miljön för en tjänst som redan körs.
Sätt debug: true i /etc/sophos/runtimedetections-rules.yaml utan att ersätta övriga regler eller skapa en andra, motstridig post.

En omstart avbryter SLS-tjänsten. Godkännande för underhåll, en tolererbar lucka i detekteringen och åtkomst till den ursprungliga konfigurationen måste vara fastställda i förväg. Detta systemd-anrop gäller den direkta värdinstallationen; det är inte en anvisning för omstart av Helm eller Docker.

Utför den dokumenterade omstarten med root-behörighet:

systemctl restart sophoslinuxsensor

Kontrollera därefter tjänstens status och journalen. Samla de profiler som behövs vid den lokala ändpunkten först när tjänsten körs och konfigurationen är giltig:

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

heap.out samlar stickprov av minnesanvändningen för levande heap-objekt; profile.out samlar CPU-användning under 60 sekunder. Dessa anrop innehåller ingen kontroll av HTTP-fel: en skapad fil i sig bevisar inte att profilen är giltig. Tolka inte tomma filer eller ett felsvar som mätvärden; kontrollera ändpunkten och den gällande felsökningskonfigurationen och validera vid behov formatet med supporten. Även dessa filer förblir konfidentiella.

Mätvärden kräver däremot varken felsökningsläge eller en omstart på grund av felsökning:

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

Återställ felsökningstillstånd och driftstillstånd

Vid tillfällig insamling ska inga ytterligare signaler skickas efter 60-sekundersfönstret. Låt sensorn fortsätta köra och kontrollera via dess loggar eller den befintliga driftövervakningen om den fortfarande fungerar normalt. En körande process eller en åtkomlig mätvärdesändpunkt är inte ett fullständigt bevis för detektering och dataöverföring. Samarbeta med supporten vid avvikande beteende.

Vid permanent konfigurerad felsökning sker ingen automatisk återställning efter 60 sekunder. Återställ det tidigare sparade debug-värdet eller dess ursprungliga frånvaro i YAML-filen och återställ en RUNTIMEDETECTIONS_DEBUG-variabel som satts för denna diagnos till dess tidigare tillstånd i den faktiska startkonfigurationen. Skriv inte generellt över andra inställningar eller hela konfigurationen om den har ändrats under tiden. Den exakta miljöändringen beror på den befintliga startmekanismen; utan ett känt utgångsläge finns inget universellt säkert återställningskommando.

För den direkt installerade systemd-tjänsten ska det ovan visade systemctl restart sophoslinuxsensor användas igen efter denna återställning, inom det godkända underhållsfönstret. Kontrollera tjänsten och journalen med avseende på start- eller konfigurationsfel, jämför den gällande felsökningsinställningen med det tidigare tillståndet och kontrollera att ingen profilåtkomst som aktiverats särskilt för diagnosen finns kvar. Om felsökning redan var aktiv tidigare är avaktivering ett ytterligare driftbeslut och inte en återställning.

Avsluta Helm-portvidarebefordran och bekräfta att dess terminalprocess har avslutats. Den efemära felsökningscontainern kan inte tas bort från den befintliga podden som en vanlig container; radera ingen sensorpodd enbart för att städa upp efter denna diagnos. Om den lokala klusterpolicyn kräver att podden återskapas måste ansvarig driftoperatör planera detta separat med hänsyn till luckan i detekteringen och kontroll av utrullningen.

Efter att supporten har bekräftat mottagandet och den fastställda lagringstiden har löpt ut ska de specifikt skapade arkiv-, logg- och profilfilerna samt tillfälliga maskerade kopior tas bort enligt den lokala raderingspolicyn. Utför ingen radering med jokertecken och radera inte sensorregler, produktloggar eller andra supportärenden. Att radera en fil garanterar inte att säkerhetskopior, ögonblicksbilder eller SSD-block skrivs över; denna lagring omfattas av den tillämpliga lagrings- och dataskyddspolicyn.