Utvärdera Sophos Endpoint-loggar och tjänster i Windows korrekt

En Sophos Endpoint i Windows består av flera skydds-, uppdaterings- och kommunikationskomponenter. En röd Health State betyder därför inte automatiskt att hela agenten har slutat fungera. För en tillförlitlig diagnos kopplas först symptomet till en komponent och därefter granskas endast dess logg under det relevanta tidsintervallet.

De flesta driftloggar finns under C:\ProgramData\Sophos. Installationsloggar finns däremot vanligen under C:\Windows\Temp, C:\Windows\SystemTemp eller i %TEMP% för kontot som startade installationsprogrammet. I nyare Core Agent-versioner finns vissa loggar för användargränssnittet under %LOCALAPPDATA%.

Snabb arbetsgång:

1. Notera incidenttid, tidszon och synligt symptom.
2. Kontrollera först Services och Components under Sophos Endpoint Agent > About > Open Endpoint Self Help Tool.
3. Notera plattform, Core Agent-version och installerade komponenter; licens och Agent Mode avgör förväntat tillstånd.
4. Välj relevant logg nedan och läs framåt från det första relevanta felet.
5. Uppdatera Self Help efter en korrigering och upprepa samma test. Spara även en SDU från samma tidsintervall vid eskalering.

Under Computer details > Status delar Central upp det övergripande tillståndet i Communication, Operations, Services, System, Threat och Update. Detaljerna Good, Warning, Bad och Info kan variera beroende på operativsystem och agentversion. Matcha därför alltid den berörda kategorin mot den exakta komponenten i Endpoint Self Help, i stället för att dra slutsatsen att en tjänst har slutat fungera enbart utifrån den övergripande färgen.

Från symptom till rätt logg

Filnamn och tjänstetilldelningar kan ändras med Core Agent-versionen. Jämför den installerade paketversionen med översikten över Sophos Endpoint-uppdateringar och komponentändringar innan du bedömer dem; basera själva diagnosen på komponenterna för den installerade versionen och de filer som faktiskt finns på den berörda enheten.

Uppdateringar och AutoUpdate

SophosUpdate.log är den viktigaste loggen för själva uppdateringsprocessen. På Windows-versioner som stöds visar sau-service.log när Central eller en ändrad uppdaterings- eller kommunikationspolicy utlöste en uppdatering. SophosLaunchUpdate.log registrerar när uppdateringsprocessen startas.

Bedöm inte ett uppdateringsfel enbart utifrån den sista Error-raden. Kontrollera först:

1. vilket uppdateringsmål som faktiskt användes,
2. om direktåtkomst, proxy eller Update Cache var involverad,
3. vilket HTTP- eller TLS-fel som inträffade först,
4. om samma tidpunkt syns i brandväggs- eller proxyloggen.

Felaktiga poster i Windows hosts-fil kan styra Sophos-mål till fel adress. Vid reproducerbara fel jämförs SophosUpdate.log, DNS, proxydata och en samtidig paketfångst.

Den klassiska Sophos AutoUpdate Service finns inte längre på moderna Windows. Om den saknas på en uttryckligen stödd Legacy-plattform repareras den cachade AutoUpdate-MSI:n med administratörsrättigheter och About > Update Now startas igen. Den gamla MSI-metoden används inte på Windows 10 x64, Windows Server 2016 eller senare.

Central-kommunikation och policyer

Sophos MCS Client upprätthåller anslutningen till Sophos Fusion (tidigare Sophos Central). McsClient.log visar om endpointen når Central. McsAgent.log visar därefter vilka policyer och kommandon som bearbetades. En aktuell Last Active-tid i Central är en användbar indikation på fungerande MCS, men den uppdateras högst ungefär en gång i timmen.

Vid kommunikationsfel kontrolleras brokeradress, DNS, routing, proxy och brandvägg. Efter en korrigering kan tjänsten Sophos MCS Client startas om och Endpoint Self Help uppdateras. Tamper Protection inaktiveras bara om det konkreta ingreppet kräver det.

Skydd, blockeringar och rensning

sed.log är den centrala driftloggen för Sophos Endpoint Defense. Den innehåller bland annat åtkomst till skyddade registernycklar, processer och filer samt blockerade åtgärder. seds.log hjälper till att avgöra om drivrutiner och tjänsten har lästs in.

För rensning är SophosCleanup.log och tillhörande Scan_*.log relevanta. De visar detekterat hot, utförd åtgärd, SafeStore-kontroll och varaktighet. Innan återställning från SafeStore görs ska det fastställas om filen är säker och varför den detekterades.

En enskild loggpost är inte skäl att godkänna ett undantag. Skapa ett undantag först efter att fil, utgivare, hash, rykte och verksamhetsbehov har kontrollerats.

Med Splashtop Streamer 3.5.6.0 kan många snabbt roterande och namnändrade loggar fylla Sophos skanningskö och höja CPU och RAM. Uppdatera helst till 3.5.8.0 eller senare och starta om. Endast om det är omöjligt bedöms den faktiska loggsökvägen som ett snävt undantag för gruppen; att undanta hela Splashtop är för brett.

En annan orsak till hög CPU för SEDService.exe är en Sysmon File Delete-regel som arkiverar .bin-filer under C:\ProgramData\Sophos. sed.log hänvisar då upprepade gånger till Sysmon-arkivet. Undanta strukturen från Sysmons FileDelete-arkivering, inte från Sophos-skanning. Efter omladdning av Sysmon bör SEDService.exe bearbeta öppna journaler och belastningen sjunka.

Windows Security Audit Logging: volym och återställning

Enable additional audit policy logging är aktiverat som standard med Sophos Endpoint Core Agent 2026.1 och Sophos Server Core Agent 2026.1. Listan över ytterligare Windows-granskningshändelser, som inte kan konfigureras individuellt, förbättrar dataunderlaget för detektering och Threat Hunting. Dessa händelser finns i Windows Security Event Log, inte i en Sophos-textlogg under C:\ProgramData\Sophos. Kopplingen och återställningen som beskrivs här gäller Windows-endpoints och Windows Server; de beskriver ingen Linux-funktion.

Den policy som faktiskt tillämpas hanteras för endpoints i Threat Protection och för servrar i Server Threat Protection. En högre händelsevolym är inte i sig ett skyddsfel. Kontrollera logglagring och SIEM-bearbetning innan funktionen stängs av, eftersom färre granskningsdata begränsar möjligheterna att utreda senare angrepp.

Koppla händelser till granskningsunderkategorier

Tabellen anger de engelska Windows-underkategorierna. På en lokaliserad Windows-installation kan namnen vara annorlunda; för lokala kommandon används den GUID som tas fram nedan. ID:na visar kopplingen, inte en testplan: alla serverroller eller aktiviteter genererar inte alla händelser. Använd befintlig, auktoriserad driftaktivitet för kontrollen; gör inga konto-, aktivitets- eller tjänsteändringar enbart för ett test.

Tidigare tillstånd, lagring och bevissäkring

Dokumentera före en planerad ändring policynamn och tilldelning, Core Agent-version, serverroll, ändringstid med tidszon och ansvariga för varje enhet. Dokumentera granskning av lyckade och misslyckade försök separat för varje berörd underkategori och klargör om GPO:er, en säkerhetsbaslinje eller en annan produkt kräver den. Om funktionen redan är aktiv dokumenterar en ny säkerhetskopia bara det aktuella tillståndet, inte automatiskt tillståndet före Sophos ändring. Inaktivera ingen underkategori på måfå utan en äldre, tillförlitlig konfiguration och godkännande från den ansvariga ägaren.

Följande kommandon är avsedda för en Windows-kommandotolk som öppnats som administratör. De läser konfigurationer eller skriver en säkerhetskopieringsfil; de ändrar inga granskningsinställningar. C:\Audit-Sicherung är ett exempel på en åtkomstskyddad katalog som ska skapas i förväg och ha tillräckligt med ledigt utrymme. Använd ett nytt filnamn vid varje insamling så att det tidigare tillståndet bevaras.

auditpol /get /category:* /r
auditpol /list /subcategory:* /v
auditpol /backup /file:"C:\Audit-Sicherung\audit-vorher.csv"
wevtutil gl Security
wevtutil gli Security

CSV-säkerhetskopian omfattar system- och användarspecifika granskningsinställningar samt granskningsalternativ; den ersätter inte en GPO-säkerhetskopia. Spara frågeresultaten tillsammans med ändringsdokumentationen. Dokumentera GUID för den aktuella underkategorin från listan tillsammans med dess lokalt visade namn för senare jämförelse.

wevtutil gl Security visar bland annat maximal storlek, loggsökväg och lagringsläge; wevtutil gli Security visar loggens tillstånd. Kontrollera Security-loggen i Windows Loggboken: dokumentera den äldsta kvarvarande tidsstämpeln, händelserna i det fastställda jämförelseintervallet och dominerande ID:n. Jämför före och efter ändringen under jämförbar belastning antalet händelser per tidsintervall, tillgänglig lokal historik, ledigt utrymme samt SIEM:s inkommande händelsefrekvens, fördröjning och kasserade händelser. Enbart filstorleken visar inte hur mycket historik som finns kvar i en cirkulär logg.

Med retention:false skriver nya händelser över de äldsta när den maximala storleken har nåtts. Med retention:true utan automatisk säkerhetskopiering kasseras då nya händelser. autoBackup:true kräver retention:true; arkiv kräver fortfarande lagringsutrymme och kontrollerad lagring. Minska därför inte loggstorleken generellt och förväxla inte ”skriv inte över” med obegränsad lagring. Samordna ändringar av maximal storlek, lagringsläge eller arkivering med de Windows-/SIEM-ansvariga och dokumentera alla tre ursprungsvärden i förväg. Återställ vid återgång exakt dessa värden via den styrande lokala konfigurationen eller GPO-konfigurationen och kontrollera med wevtutil gl Security. Händelser som redan skrivits över eller kasserats återkommer inte genom detta.

Exportera relevanta händelser före ett ingrepp; töm inte Security-loggen. Använd även här ett nytt filnamn och ett skyddat mål med tillräckligt med utrymme:

wevtutil epl Security "C:\Audit-Sicherung\Security-vorher.evtx"

Öppna den exporterade filen i Loggboken och kontrollera det tidsintervall som behövs. Granskningsdata kan innehålla användar-, konto- och aktivitetsinformation; begränsa åtkomst, överföring och lagring därefter.

Selektiv återställning efter att policyn stängts av

Stäng först av Enable additional audit policy logging i den Endpoint eller Server Threat Protection-policy som faktiskt tillämpas, spara och kontrollera att enheten har tagit emot policyn. Redan aktiverade Windows-granskningsinställningar finns kvar och måste vid behov återställas manuellt. Ta inte bort hela granskningspolicyn: det skulle även påverka inställningar som behövs oberoende av Sophos. Återställ inte heller en hel CSV-säkerhetskopia blint, eftersom legitima ändringar kan ha gjorts sedan den skapades.

Återställ de bevisligen berörda underkategorierna individuellt till deras belagda tidigare värden endast efter godkännande från de Windows-/säkerhetsansvariga. Följande exempel ändrar inställningar och gäller endast om granskning av lyckade försök tidigare var aktiv och granskning av misslyckade försök var inaktiv. Ersätt <GUID> helt med den framtagna underkategorins GUID inklusive {...}; platshållaren kan inte köras. Läs av inställningarna lokalt igen innan de ändras:

auditpol /get /subcategory:"<GUID>"
auditpol /set /subcategory:"<GUID>" /success:enable /failure:disable
auditpol /get /subcategory:"<GUID>"

För andra belagda tidigare tillstånd väljer du de två värdena oberoende av varandra: enable bibehåller eller aktiverar respektive gren, medan disable inaktiverar den. Endast om båda grenarna tidigare var avstängda och inget annat gällande krav behöver dem ska båda inaktiveras för just denna underkategori. En underkategori kan styra fler händelser än de ID:n som anges här; ändringen är inget filter för enskilda Event IDs.

Jämför avsedda och faktiska värden efter varje ändring, läs av dem igen efter den ordinarie GPO-/produktuppdateringen och kontrollera det händelseflöde som behövs samt logg-/SIEM-volymen. Om inställningarna aktiveras igen utreder du först den styrande GPO:n eller den andra säkerhetsprodukten – försök inte motverka dem upprepade gånger lokalt. Om tidigare tillstånd, ansvar eller mottagandet av Sophos-policyn fortfarande är oklart, stoppa återställningen och eskalera resultaten för policy, agent, granskning och volym. Om den ytterligare synligheten ska återställas aktiverar du Sophos-alternativet igen och kontrollerar granskningstillstånd och händelseflöde efter att policyn har tagits emot; en datalucka som uppstått under tiden fylls inte igen genom detta.

Bedöm tjänster korrekt

Self Help skiljer mellan Windows SCM Services och Sophos SCM Services. Endast den första gruppen är registrerad i Windows Service Control Manager och synlig i services.msc. Sophos SCM Services körs som processer men visas inte där. På moderna plattformar flyttades Sophos Live Query, Sophos Health Service och Sophos System Protection Service till den andra gruppen från Core Agent 2025.2. En saknad post i services.msc bevisar därför inte ensam ett installationsfel.

Sophos beskriver denna konsolidering i 2025.2.1 som en prestandaoptimering. Diagnostiken måste ändå följa den installerade Core Agent-versionen och motsvarande Self Help-artikel: den aktuella Services-artikeln är uttryckligen märkt för Core Agent 2026.1, och andra paket kan kräva en annan arbetsgång. Kontrollera först status i Self Help, som även anger om tjänsten hanteras via Windows SCM eller Sophos SCM. Reparationsprocedurerna kräver administratörsrättigheter och inaktiverat Tamper Protection; kör dem inte enbart för att en gammal tjänstelista avviker.

I Core Agent 2025.x kan detta sällsynta fall uppstå efter en misslyckad Windows 11 feature update från 23H2 till 24H2 eller 25H2 med rollback. Om återgången sammanfaller exakt med en DecisionCache-uppdatering kan versionerna i registret och filsystemet skilja sig åt. Endpoint blir röd, System Protection startar inte och C:\ProgramData\Sophos\Endpoint Defense\Logs\SSP.log rapporterar en saknad regelversion.

Vänta inte upp till 96 timmar utan System Protection. Tilldela tillfälligt en Update Management Policy med ett FTS- eller LTS-paket som stöds. Ta bort enheten från reparationspolicyn först när Health State är grön, komponenten körs och SSP-loggen är aktuell. Manuell registerkorrigering kräver Tamper Protection Override, backup och exakt matchande regelkatalog.

Den officiella listan över komponenter och tjänster innehåller bland annat följande kopplingar. Tabellen är ett diagnostikhjälpmedel, inte en fullständig lista över förväntat tillstånd på varje enhet:

Vilka komponenter som ska finnas beror på plattform, Agent Mode och licens. En XDR Sensor installerar till exempel telemetrikomponenter men inget fullständigt Sophos-skydd mot skadlig kod. Fastställ först det förväntade tillståndet i Central och jämför därefter med tjänster och processer.

Nätverks- och webbskydd

SophosNetFilter.log innehåller webbplatsanslutningar och åtgärder från Web Control samt internetkontroll i realtid. SophosIPS.log visar konfiguration och detekteringsinnehåll för nätverkshotsskydd. SntpService.log innehåller bland annat information om isolering och andra nätverksfunktioner.

För en blockerad webbplats jämförs tidpunkt, URL, process och effektiv policy. Loggen ensam visar inte alltid om Endpoint Web Control, DNS Protection eller en uppströms brandvägg blockerade först. Kontrollera dessa kontrollpunkter separat.

Användargränssnitt och Self Help

I aktuella Core Agent-versioner finns SophosUI.Net.log och SophosUITray.log under:

%LOCALAPPDATA%\Sophos\Sophos UI\Logs

De registrerar åtgärder i det lokala gränssnittet respektive vid aktivitetsfältets ikon. Från Core Agent 2026.1 kan Self Help-loggar även lagras per användare under %LOCALAPPDATA%\Sophos\Endpoint Self Help\Logs. Beroende på komponenten är den datoromfattande katalogen under C:\ProgramData\Sophos\Endpoint Self Help\Logs fortfarande relevant.

Utvärdera en logg korrekt

Definiera ett snävt felintervall inklusive tidszon innan loggen öppnas. Läs därefter framåt från det första relevanta felet. Senare följdfel som service unavailable, timeout eller component unhealthy är ofta bara konsekvenser.

En tillförlitlig anteckning innehåller:

• synligt symptom och ett reproducerbart test,
• loggnamn, tidsstämpel och första relevanta meddelande,
• berörd Endpoint-, proxy-, cache- eller relayväg,
• jämförelse med en fungerande enhet,
• testad ändring och dess mätbara resultat.

Öka inte loggnivåerna permanent i förebyggande syfte. Detaljerad MCS-loggning kan innehålla känsliga kommunikationsdata och använda extra lagring. Aktivera den endast för ett definierat tidsintervall enligt aktuella Sophos-anvisningar och återställ den därefter.

Sophos Support kan begära en diagnostic message trail för MCS. På Windows 10 x64 eller Server 2016 och senare är den aktiv som standard sedan Core Agent 2023.2; XML-stegen för att aktivera och sedan inaktivera den gäller endast Legacy-plattformar. Trailfiler kan innehålla policy- och kommunikationsdata och ska överföras skyddat tillsammans med SDU:n. Inaktivera en Legacy-insamling efteråt, eftersom den annars kan fylla disken.

Spara loggar för Support

Enskilda loggar hjälper vid lokal avgränsning. För en eskalering skapas dessutom en SDU-samling från samma felperiod. Paketet kan innehålla värdnamn, användare, sökvägar, IP-adresser och konfigurationsdata och ska överföras skyddat.

Den fullständiga samlingen förklaras i Diagnostisera Sophos Endpoint med Self Help och SDU. Installationsfel behandlas separat i Felsök Sophos Endpoint-installation i Windows systematiskt.

Vanliga frågor