Sophos Linux Sensor: supportgegevens veilig verzamelen

Bij een probleem met Sophos Linux Sensor (SLS) verzamelt u een supportarchief en de bijbehorende sensorlogs, bij voorkeur tijdens de fout of onmiddellijk daarna. Het verzamelen duurt ongeveer 30 seconden. Bepaal eerst de implementatie: bij Helm verzamelt u per getroffen node, bij Docker op de Docker-host en bij een directe installatie op de Linux-host. Na het debugsignaal moet de download onmiddellijk volgen; het tijdelijke debugvenster duurt 60 seconden.

Deze handleiding geldt uitsluitend voor Sophos Linux Sensor. SLS is noch Sophos Protection for Linux (SPL), noch de XDR Sensor of het Linux Runtime Detection-beleid daarvan. De indeling in het serveroverzicht dient voor navigatie en maakt de producten niet gelijkwaardig. Voor SPL geldt de afzonderlijke installatie- en beheerhandleiding; de volgende SLS-opdrachten mogen daar niet worden overgenomen.

Doelsysteem en toestemming vóór het verzamelen controleren

Controleer vóór een signaal of herstart aan de hand van de implementatie-inventaris en de actieve instantie of het daadwerkelijk om SLS gaat. Leg de host of het cluster, de namespace, pod, node of container, de geïnstalleerde sensorversie en het tijdstip van de fout met tijdzone vast in de supportcase. De versiegegevens in het latere archief vullen deze koppeling aan. Deze handleiding volgt de supportprocedure die op 5 oktober 2026 is bijgewerkt; daaruit volgt geen minimumversie of goedkeuring voor elke oudere sensor-, Helm-, Kubernetes- of Docker-versie. Stem bij afwijkende namen, poorten of een ontbrekend monitoringendpoint eerst de daadwerkelijke implementatie af met Support.

U hebt een werkmap nodig met toegangsbeveiliging en voldoende vrije opslagruimte. De hieronder getoonde bestandsnamen zijn relatief ten opzichte van deze map; stel bestaande pakketten vóór een herhaling afzonderlijk veilig, zodat ze niet worden overschreven. Beperk de toegang tot archief, logs en profielen tot de verantwoordelijke personen en stel een bewaartermijn vast. Voor downloads blijven de monitoringadressen lokaal. Richt geen openbare service, Ingress of algemeen bereikbare debugpoort in.

De hulpmiddelen moeten al zijn goedgekeurd en beschikbaar zijn. Als curl ontbreekt op een direct geïnstalleerde Linux-host, documenteert de procedure deze installatieopdrachten:

# Red-Hat-gebaseerde systemen
sudo yum install curl

# Ubuntu
sudo apt-get install curl

Gebruik alleen de opdracht die bij de distributie past, binnen het goedgekeurde pakketbeheerproces. Een pakketinstallatie wijzigt de host; deze hoort niet bij een loutere controle van het artikel. Voor Helm en Docker zijn daarnaast tar en gzip nodig. Stop vóór het activeren van debug als de vereiste hulpmiddelen of machtigingen ontbreken.

Helm: één pakket per getroffen node

Op de beheercomputer moet kubectl voor het juiste cluster zijn ingesteld. De machtiging moet het mogelijk maken pods op te sommen, podlogs te lezen, podpoorten door te sturen en een tijdelijke debugcontainer toe te voegen. Bovendien moet de containerruntime het mogelijk maken de procesnamespace van een andere container als doel te kiezen. curl, tar en gzip zijn op deze computer nodig.

Het cluster moet busybox:latest kunnen ophalen. Als deze registry niet is goedgekeurd, wordt de image vooraf gespiegeld naar een goedgekeurde, bereikbare registry en wordt alleen de waarde van --image vervangen door deze gecontroleerde imagereferentie. Versoepel de beveiligingsregels voor de registry niet om het verzamelen af te dwingen. De tijdelijke container is een wijziging aan de pod; daarvoor is de passende operationele toestemming nodig.

Pod kiezen en port-forward openhouden

De SLS-Helm-chart levert één sensorpod per bewaakte Linux-node. Vervang <namespace> door de namespace van de SLS-release:

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

De uitvoer moet de sensorpod aan de getroffen node koppelen. <sensor-pod> is precies deze pod, <node-name> is de nodenaam daarvan. Gebruik niet zomaar een gezonde pod van dezelfde release.

Stuur in de eerste terminal de monitoringpoort door:

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

Deze terminal blijft open totdat de download is voltooid. Als de lokale poort al bezet is, stopt u de procedure en lost u het conflict op in plaats van een ander proces te beëindigen. Voeg geen binding aan openbaar bereikbare adressen toe. Als het doorsturen wordt onderbroken, moet dit vóór de volgende download weer actief zijn.

Signaal verzenden, onmiddellijk downloaden en logs toevoegen

In de tweede terminal wordt de debugcontainer op de SLS-container gericht. De opdracht verzendt SIGUSR2 naar het sensorproces; dit is geen instructie om de sensor te beëindigen:

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

Het zoekpatroon [s]ophoslinuxsensor voorkomt dat pkill zijn eigen opdrachtregel treft. Als het ophalen van de image, de machtiging of het richten op het proces mislukt, is het verzamelen niet betrouwbaar geactiveerd. Voeg niet blindelings meer debugcontainers toe; onderzoek eerst de foutmelding.

Download direct daarna in de tweede 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 begrenst de HTTP-aanroep, maar verlengt het debugvenster niet. Stel daarna de actuele logs van dezelfde container en node veilig:

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

Geef de inhoud weer zonder uit te pakken:

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

Beëindig na de hieronder beschreven volledigheidscontrole de port-forward in de eerste terminal met Ctrl+C. Gebruik voor elke volgende getroffen node een eigen pod en unieke bestandsnaam.

Docker: actieve container en gepubliceerde poort controleren

Alle volgende opdrachten worden uitgevoerd op de Docker-host met de daar goedgekeurde Docker-machtiging. De SLS-container moet actief zijn; de monitoringpoort moet al naar de host zijn gepubliceerd. De standaardpoort in de container is 9010. curl, tar en gzip moeten aanwezig zijn. Het achteraf publiceren van een poort of het herstarten van een container wordt hier niet als herstelmaatregel voorgeschreven.

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

<sensor-container> is de naam of ID van de bevestigde SLS-container. De tweede uitvoer vermeldt het hostadres en de hostpoort. <host-port> wordt vervangen door deze poort, niet automatisch door 9010. De volgende download veronderstelt dat het gepubliceerde adres via 127.0.0.1 op deze Docker-host bereikbaar is. Controleer bij uitsluitend een andere binding of ontbrekende uitvoer eerst de implementatie; voeg geen openbaar bereikbare poort toe.

De volgende opdracht wijzigt de debugstatus gedurende 60 seconden. docker kill mag daarbij niet zonder --signal=SIGUSR2 worden uitgevoerd:

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

Haal onmiddellijk daarna het gepubliceerde lokale endpoint op:

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

Logs en archiefcontrole horen bij hetzelfde pakket:

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

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

De tijdelijke debugmodus eindigt automatisch. Een nieuwe controle met docker ps moet nog steeds de bedoelde actieve container tonen; dit alleen bewijst echter nog niet dat de detectie werkt.

Direct geïnstalleerde Linux-host: tijdelijke debugmodus gebruiken

Deze tak geldt voor SLS dat direct op de host draait, niet voor een container en niet voor /opt/sophos-spl. Rootrechten en toegang tot de lokale monitoringpoort zijn vereist. Controleer bij een systemd-installatie vooraf met journalctl -u sophoslinuxsensor of het journal bij de verwachte dienst en host hoort. Als de dienst ontbreekt of er meerdere sensorinstanties zijn, moet eerst hun koppeling worden opgehelderd.

De gedocumenteerde hostopdracht treft alle actieve processen met het patroon sophoslinuxsensor op de host. Deze beperkt zich niet tot één instantie. Voer de opdracht niet uit zonder toestemming voor deze instanties of bij onduidelijke procesnamen.

sudo pkill -SIGUSR2 -f sophoslinuxsensor

De sensor biedt daarna gedurende 60 seconden support- en debuginformatie aan op het monitoringendpoint. Verzamel onmiddellijk in de voorbereide werkmap:

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

Het verzamelen duurt ongeveer 30 seconden. Na geslaagde compressie is support.tar.gz beschikbaar. Deze hostaanroep bevat noch een HTTP-foutcontrole, noch een time-out; een aanwezige bestandsnaam of geslaagde gzip-aanroep bewijst daarom niet dat het archief volledig is. Voor de lokale controle, zonder het pakket uit te pakken:

tar -tzf support.tar.gz

Lees de hostlogs met:

journalctl -u sophoslinuxsensor

Voor doorlopende observatie is daarnaast deze aanroep gedocumenteerd:

journalctl -efu sophoslinuxsensor

Beëindig de observatie met Ctrl+C en stel de benodigde journalgegevens voor de foutperiode veilig via de goedgekeurde exportroute. Behandel onbeperkt doorlopende uitvoer niet als een afgerond supportpakket.

Archief controleren, fout afbakenen en veilig overdragen

Een volledig debugarchief bevat items zoals runtimedetections.yaml, environment.json, goroutine.out en profile.out, naast metriek- en versiegegevens. De genoemde items zijn voorbeelden, geen garantie op identieke inhoud voor elke versie. tar moet het archief zonder fouten kunnen weergeven. Een HTML-foutpagina, een leeg pakket of een afgebroken download is geen bruikbaar resultaat.

Als het pakket alleen metrics.txt en version.json bevat, was het verzamelen van debuggegevens niet actief. Controleer de doelinstantie, signaalfouten en het tijdsinterval. Verzend daarna in de passende implementatietak opnieuw SIGUSR2 en download onmiddellijk opnieuw. Bij de Helm-tak moet de port-forward gedurende de volledige download actief zijn. Escaleer herhaalde mislukkingen met de exacte foutmelding, sensorversie en het tijdstip van de fout naar Support; omzeil deze niet met permanente debugmodus of een open netwerkpoort.

Archieven, logs en profielen kunnen vertrouwelijke configuratie, omgevingsvariabelen, host- en runtimegegevens bevatten. Ook als delen van de configuratie automatisch onleesbaar worden gemaakt, is het pakket niet automatisch geanonimiseerd voor openbare verspreiding.

Controleer vóór overdracht de bestandslijst en, waar nodig, de inhoud in een afgeschermde omgeving op toegangsgegevens, tokens, interne hostnamen en persoonsgegevens. Gebruik voor het onleesbaar maken van vertrouwelijke gegevens een afzonderlijke kopie en documenteer wijzigingen; wijzig binaire profielen niet ongecontroleerd. Stem met Support af welke inhoud voor de diagnose ongewijzigd nodig is. Bewaar het origineel alleen met toegangsbeveiliging en volgens de afgesproken bewaartermijn.

Verstuur het archief en de bijbehorende logs uitsluitend via het goedgekeurde Sophos-supportkanaal dat in de supportcase is bevestigd. Verifieer de ontvanger en uploadbestemming aan de hand van de bestaande case, niet aan de hand van een ongevraagd bericht. Gebruik geen openbaar ticket, forum, Git-repository of KB-mediaopslag. Bij het pakket horen het implementatietype, de getroffen nodes of hosts, de sensorversie, het tijdstip van de fout met tijdzone, het symptoom en de al uitgevoerde verzamelstappen; stuur geen toegangsgegevens mee als begeleidende tekst.

CPU- en geheugenprofielen alleen bij gerichte behoefte

Voor een normaal supportarchief volstaat het tijdelijke signaal. De volgende afzonderlijke profielen vormen een aparte route voor CPU- of geheugenproblemen en gebruiken het pprof-formaat van Google. Voor het permanent geconfigureerd activeren van debug moet vooraf vaststaan hoe de daadwerkelijke SLS-dienst wordt gestart en hoe de configuratie kan worden teruggezet.

Stel eerst de bestaande inhoud van /etc/sophos/runtimedetections-rules.yaml, de bestaande waarde of het ontbreken van debug en de effectieve startomgeving veilig. Stel met name vast of RUNTIMEDETECTIONS_DEBUG al is ingesteld. Een back-up van dezelfde configuratie is eveneens vertrouwelijk. Verwar deze niet met het vergelijkbaar genaamde bestand runtimedetections.yaml in het supportarchief.

Kies een van de gedocumenteerde activeringen:

Voer de sensor uit met RUNTIMEDETECTIONS_DEBUG=true in de daadwerkelijke startomgeving. Alleen een export in een beheershell wijzigt de omgeving van een al actieve dienst niet.
Stel debug: true in /etc/sophos/runtimedetections-rules.yaml in, zonder de overige regels te vervangen of een tegenstrijdige tweede vermelding aan te maken.

Een herstart onderbreekt de SLS-dienst. Toestemming voor onderhoud, een aanvaardbare detectieonderbreking en toegang tot de oorspronkelijke configuratie moeten vooraf vaststaan. Deze systemd-aanroep geldt voor de directe hostinstallatie; dit is geen herstartprocedure voor Helm of Docker.

Voer met rootrechten de gedocumenteerde herstart uit:

systemctl restart sophoslinuxsensor

Controleer daarna de dienststatus en het journal. Verzamel de benodigde profielen pas bij een actieve dienst en geldige configuratie via het lokale endpoint:

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

heap.out legt steekproeven van het geheugengebruik van levende heapobjecten vast; profile.out legt CPU-gebruik gedurende 60 seconden vast. Deze aanroepen bevatten geen HTTP-foutcontrole: een aangemaakt bestand alleen bewijst niet dat het profiel geldig is. Interpreteer lege bestanden of een foutantwoord niet als meetwaarde; controleer het endpoint en de effectieve debugconfiguratie en valideer het formaat zo nodig met Support. Ook deze bestanden blijven vertrouwelijk.

Metrieken vereisen daarentegen geen debugmodus en geen herstart vanwege debug:

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

Debugstatus en operationele status herstellen

Verzend bij tijdelijke verzameling na het venster van 60 seconden geen verdere signalen. Laat de sensor actief en controleer aan de hand van de logs of de bestaande operationele monitoring of deze normaal blijft werken. Een actief proces of bereikbaar metriekendpoint is geen volledig bewijs voor detectie en gegevensoverdracht. Werk bij afwijkend gedrag samen met Support.

Bij permanent geconfigureerde debug is er na 60 seconden geen automatisch herstel. Herstel de eerder veiliggestelde debug-waarde of het oorspronkelijke ontbreken daarvan in het YAML-bestand en zet een voor deze diagnose nieuw ingestelde RUNTIMEDETECTIONS_DEBUG-variabele in de daadwerkelijke startconfiguratie terug naar de vorige toestand. Overschrijf niet zonder onderscheid andere instellingen of de volledige configuratie die inmiddels is gewijzigd. De exacte omgevingswijziging hangt af van het bestaande startmechanisme; zonder bekende uitgangssituatie is er geen universele veilige resetopdracht.

Gebruik voor de direct geïnstalleerde systemd-dienst na dit herstel opnieuw de hierboven getoonde systemctl restart sophoslinuxsensor binnen het goedgekeurde onderhoudsvenster. Controleer de dienst en het journal op start- of configuratiefouten, vergelijk de effectieve debuginstelling met de vorige toestand en controleer dat er geen voor de diagnose nieuw geactiveerde profieltoegang overblijft. Als debug daarvoor al actief was, is het uitschakelen ervan een aanvullende operationele beslissing en geen herstel.

Beëindig de Helm-port-forward en bevestig dat het terminalproces ervan is beëindigd. De tijdelijke debugcontainer kan niet als een normale container uit de bestaande pod worden verwijderd; verwijder geen sensorpod alleen om deze diagnose op te ruimen. Als het lokale clusterbeleid vernieuwing van een pod vereist, moet de verantwoordelijke beheerder dit afzonderlijk plannen, met aandacht voor de detectieonderbreking en controle van de uitrol.

Verwijder na bevestigde ontvangst door Support en het verstrijken van de vastgestelde bewaartermijn de specifiek aangemaakte archief-, log- en profielbestanden en tijdelijke kopieën met afgeschermde gegevens volgens het lokale verwijderbeleid. Voer geen verwijdering met wildcards uit en verwijder geen sensorregels, productlogs of andere supportcases. Bestandsverwijdering garandeert niet dat back-ups, snapshots of SSD-blokken worden overschreven; die bewaring valt onder het toepasselijke opslag- en gegevensbeschermingsbeleid.