Sophos Server Protection: godkänn Windows- och Linux-plattformar på säkra grunder

Kort beslutsregel: Ta bara med en server i nästa installations- eller uppdateringsomgång om dess specifika operativsystem och agent omfattas av Sophos aktuella stöd, de funktioner som behövs finns tillgängliga i den egna tenanten och en representativ pilotserver fungerar utan problem. En rad i äldre versionsinformation visar bara att det en gång fanns komponenter för en plattform – inte att operativsystemet stöds utan begränsningar i dag. Saknas tillförlitligt underlag får servern stå utanför omgången tills plattformsfrågan har klarats ut med Sophos Support.

Den här guiden hjälper dig att fatta ett godkännandebeslut före en nyinstallation, ett byte av operativsystem eller en agentuppdatering. Själva stegen för Windows Server och Sophos Protection for Linux (SPL) finns i respektive installationsguide.

Kontrollera versionsläge och supportläge var för sig

Vid kontrollen den 24 september 2026 anger Sophos versionsinformation 2026.2.2.1 (september 2026) som senaste version av Windows Server Core Agent, med separata komponentavsnitt för Windows Server 2016 och senare samt för äldre legacy-plattformar. Aktuell versionsinformation för Windows Server Core Agent är vägledande för versions- och komponentändringar. Där påpekas också att det kan ta flera veckor efter publiceringen innan programvaran har distribuerats. Ett historiskt eller aktuellt komponentavsnitt är inte ett godkännande av en viss Windows-utgåva eller ett visst bygge.

Enligt Sophos systemkrav för Windows Server (KBA-000003024, daterade 7 maj 2026) är Windows Server 2016, 2019, 2022 och 2025 servergenerationer med fullständigt stöd. Windows Server 2008 R2 samt 2012 och 2012 R2 är legacy-plattformar och kräver en Extended Support-licens; enskilda funktioner kan saknas eller inte stödjas respektive uppdateras där. Sensor Mode stöds inte på legacy-plattformar. Den daterade översikten innebär inte ett generellt godkännande av varje utgåva, arkitektur eller buildvariant. Inventera därför exakt utgåva, fullständigt OS-bygge, arkitektur, agentversion, avsett skyddsläge och faktisk Extended Support-rätt för legacy-värdar före omgången. Kontrollera den konkreta kombinationen mot Sophos aktuella systemkrav för Windows Server, uppgifter om Windows-varianter som stöds och utfasningskalendern. Om Sophos supportsida inte går att läsa eller inte ger ett entydigt besked ska godkännandet skjutas upp och Sophos Support kontaktas. Att en agent startar eller nämns i versionsinformationen bevisar inte i sig någon rätt till support.

Kontrollera resurser utifrån licens och läge: Per 7 maj 2026 kräver Sophos Endpoint – Server minst 8 GB ledigt diskutrymme, 8 GB RAM och 2 kärnor. För Sophos EDR, XDR och MDR – Server krävs minst 10 GB ledigt diskutrymme, 8 GB RAM och 2 kärnor; rekommendationen är 10 GB ledigt diskutrymme, 16 GB RAM och 4 kärnor. Kraven gäller både Full Protection och Sensor Mode – resurstabellen upphäver inte förbudet mot Sensor Mode på legacy-plattformar. Sophos rekommenderar starkt SSD som startenhet. Värdena är allmänna riktvärden, ingen garanti för tillräcklig prestanda vid varje serverbelastning: CPU-, RAM- och diskbelastning kan tillfälligt öka, särskilt vid upptäckt och rensning av skadlig kod. Kontrollera marginalerna och beteendet i den egna piloten.

För Linux anger versionsinformationen för SPL 2026.3 (september 2026) som senaste version vid samma kontrolltillfälle. Även här kan distributionen till den egna tenanten ske först efter att versionsinformationen har publicerats. Under System requirements anges för närvarande minst 2,5 GB ledigt diskutrymme, 2 GB ledigt RAM-minne, x86_64 eller ARM64, ett körande systemd, Bash och glibc version 2.17 eller senare; för ARM64 krävs glibc version 2.18 eller senare och kärna version 5.3 eller senare. Värdena är ett daterat kontrollunderlag, inte ett permanent godkännande av alla Linux-distributioner eller kärnor.

Sophos anvisningar om SPL-distributioner och kärnor hänvisar till System requirements > Supported platforms i versionsinformationen för den aktuella plattformslistan; de utgör inte en andra, oberoende godkännandematris. Distribution, major- och minorversion, arkitektur, körande kärna och leverantörens support måste stämma överens. Den testade listan omfattar vid det angivna kontrolltillfället bland annat RHEL 8–10, Debian 11–13 och Ubuntu 22.04/24.04 LTS samt 26.04; därutöver finns en separat angiven legacy-lista, som inte innebär ett automatiskt godkännande. Sophos testar de senaste aktiva minorversionerna respektive servicepaketen; för x86_64 kan distributionsspecifika minimiversioner för kärnan gälla. Kärna 5.3 innebär därför inte ett generellt godkännande för x86_64. Även en kärna över minimigränsen kan vara problematisk: i den aktuella versionsinformationen nämns ett känt ftrace-fel för 5.10.133 till 5.10.142 som kan få kärnan att hänga sig. Godkänn inte den kombinationen enbart för att installationen verkar lyckas; kontrollera först kärnan och Sophos anvisningar.

Hantera undantag före piloten: Om Linux-avbilden är immutable ska SPL inte godkännas här – enligt Sophos är SPL inte avsett för immutable-distributioner, och för sådana plattformar hänvisar de till den separata produkten Sophos Linux Sensor (SLS). SLS är inte SPL:s XDR Sensor; den här guiden beskriver ingen SLS-installation. Downstream-distributioner som inte finns i listan, egna eller minimala kärnor och härdade system blir inte heller automatiskt testade plattformar: Sophos beskriver för dem en prövning efter bästa rimliga förmåga och kan kräva att problemet återskapas på en plattform som stöds eller att systemet uppgraderas.

För en befintlig legacy-Linux-värd ska du dessutom kontrollera den faktiska rätten till Extended Support, det installerade programvarupaketet och det paket som tilldelats via Update Management. Den 24 september 2026 anger Sophos det LTS-paket som stöds, 2026.1.0.35, för legacy-versioner och rekommenderar att det tilldelas via Update Management. Vid problem med ett nyare paket kan en återgång till det paket som stöds behövas för felsökningen. Kontrollera aktuella Sophos-anvisningar och att det specifika paketet finns tillgängligt innan något ändras: rubriken SPL 2026.3 är inte ett automatiskt uppdateringsmål för en legacy-värd, och 2026.1.0.35 är varken ett permanent löfte eller en generell nedgraderingsanvisning.

Dokumentera beslutet för en konkret omgång

Ett kort kontrollprotokoll förhindrar att en fungerande installation misstas för bevis på support. Dokumentera följande för varje serverfamilj – till exempel Windows-applikationsservrar och Linux-databasservrar var för sig:

Nuläge och målläge: serverroll, OS-utgåva respektive distribution och minorversion, fullständigt bygge respektive uname -r, arkitektur, installerad agent inklusive komponenter och avsedd målversion. För Windows: kontrollera licenstyp (Endpoint – Server eller EDR/XDR/MDR – Server), Full Protection eller Sensor Mode, ledigt diskutrymme, RAM, kärnor och startenhet. För Linux: kontrollera också avbildstyp (immutable eller ändringsbar), ledigt RAM-minne och utrymme på den faktiska installationsvolymen, körande systemd, Bash och glibc. För legacy-Linux ska installerat och tilldelat programvarupaket dokumenteras var för sig.
Underlag: notera datum och version för Windows-systemkraven och Windows- eller SPL-versionsinformationen, aktuella OS- och kärnkrav, livscykel/Extended Support inklusive den faktiska rätten för legacy-värdar samt den licens och de tenantfunktioner som krävs. För Windows utan entydigt underlag för utgåva, build, arkitektur och skyddsläge: skriv uttryckligen öppet i stället för ”kompatibel”. Att versionsinformationen nämner en ny funktion – till exempel Linux som Update Cache eller Message Relay från SPL 2026.3 – bevisar varken att funktionen faktiskt finns tillgänglig i tenanten eller att dess separata förutsättningar är uppfyllda.
Beslut: ”godkänd för pilot”, ”uppdatera OS/kärna först” eller ”stoppa och kontakta support”. Ange granskare, ändringsfönster, pilotservrar och stoppkriterier. Det första alternativet kräver positivt underlag för plattformen; ett otestat downstream-bygge är inte likvärdigt med en testad kombination. Immutable Linux ska stå utanför SPL-omgången. Fortsätt med legacy-Linux endast när rätten till support är klarlagd, rätt paket har tilldelats och aktuellt supportunderlag finns.

Kör följande läsande kommandon på Linux-pilotservern så nära ändringsfönstret som möjligt och spara utdata i protokollet:

cat /etc/os-release
uname -r; uname -m
free -m
df -h -- /opt
ps -p 1 -o comm=; test -d /run/systemd/system && printf 'systemd läuft\n'
command -v bash; getconf GNU_LIBC_VERSION

Jämför kolumnen available (inte total) från free -m med kravet på 2 GB ledigt minne. df -h -- /opt är bara relevant för en standardinstallation om /opt ligger på den faktiska målvolymen. Vid en separat montering eller användning av --install-dir ska du i stället kontrollera en redan befintlig sökväg på den faktiska installationsvolymen med df -h -- <Pfad> och påvisa 2,5 GB ledigt utrymme. Om volymen ännu inte går att identifiera ska resurserna inte godkännas. ps och katalogen /run/systemd/system kontrollerar vilket init-system som körs; Bash måste kunna hittas och den angivna glibc-versionen måste passa arkitekturen. Kontrollera dessutom om avbilden är immutable utifrån avbilds-/OS-typen i driftsättningsinventariet; enbart os-release bevisar inte att värden är ändringsbar. För Windows sparar du fullständiga OS- och agentuppgifter från det hanterade inventariet och systemegenskaperna samt resursvärdena för avsedd licens och avsett skyddsläge. Upprepa kontrollen när OS, kärna, agent, licens eller Sophos krav ändras – lita inte enbart på datumet för den här artikeln.

Pilot, hälsostatus och nästa omgång

Välj först en representativ server för varje relevant plattformskombination: samma OS-minorversion, arkitektur och kärna, liknande nätverks-/proxyväg samt jämförbar serverroll och belastning. Kontrollera säkerhetskopiering och återställningsväg före piloten, säkerställ konsolåtkomst eller åtkomst utanför ordinarie nätverk och avsätt ett underhållsfönster som även rymmer en eventuell omstart. En databas med särskilda I/O-toppar behöver ett lämpligt belastningstest; att bara starta en tom test-VM räcker inte.

Efter installation eller uppdatering kontrollerar du i My Products > Server > Servers i rätt tenant att pilotservern visas en gång, kommunicerar som den ska, har förväntade skyddskomponenter och avsedd servergrupp samt inte visar något bestående hälsolarm. Jämför installerade komponenter och versioner på enheten och i Fusion; kontrollera den gällande serverpolicyn på värden, inte bara grupptilldelningen. På Linux kontrollerar du dessutom sudo systemctl status sophos-spl. Endast om antiviruspluginet är installerat läser du vid standardsökvägen sudo cat /opt/sophos-spl/plugins/av/VERSION.ini (anpassa sökvägen om --install-dir har ändrats) och jämför dess version med Server Protection-komponenten, inte SPL-baskomponenten, i Central. På en ren SPL-XDR Sensor utan AV-plugin kontrollerar du i stället de komponenter som faktiskt är installerade och deras version och hälsostatus i Central; att AV-filen saknas är då inget fel. Att tjänsten fungerar bekräftar inte i sig att skyddet mot skadlig kod är aktuellt eller att en policy tillämpas. Genomför ett planerat och säkert test av on-access-detektering enligt Linux-installationsguiden endast om AV-skyddet är installerat och du har kontrollerat att både Real-time scanning - Local files and network shares och Enable scan for Server Protection for Linux Agent är aktiverade i den gällande Server Threat Protection Policy. En ren XDR Sensor är inte en lämplig kandidat för detta test.

Jämför därefter affärsapplikationen, omstartsbeteendet, nätverksanslutningarna och den normala belastningen med läget före ändringen. Kontrollera först i tenanten om en ny agentfunktion faktiskt erbjuds pilotservern. Nästa begränsade omgång får börja först när plattformsunderlag, agent- och policyläge, hälsostatus och applikationstest samtliga är godkända. Versionsinformation kan publiceras före distributionen; om den version som faktiskt erbjuds avviker är det skäl att kontrollera saken, inte att tvinga fram en nedladdning.

Förbered stopp och återställning

Före ändringen dokumenterar du fungerande OS-/kärn- och agentversion, för legacy-Linux även installerat och tilldelat programvarupaket, säkerhetskopia, underhållsfönster, skyddsläge och ansvarig person. Det är inte säkert att du kan återgå till en äldre agent bara för att versionen nämns i historisk versionsinformation. Vid återställning av OS eller kärna måste startbarhet, datakonsistens och stöd för målversionen kontrolleras var för sig. Även om Sophos i supportärenden för legacy-Linux kan kräva återgång till det paket som stöds, är Sophos programvarupaket och uppdateringspolicyer ingen generell nedgraderingsknapp. Stäm av en återställningsväg för den specifika värden med Sophos i förväg.

Om registreringen uteblir, hälsostatusen förblir dålig, skyddet får fel omfattning, oväntade omstarter inträffar eller en serverapplikation störs: stoppa distributionen och automatiska omförsök omedelbart, avgränsa berörda värdar och starta ingen ny omgång. Kontrollera först tenant, anslutning, gällande policy, erbjuden agentversion och OS-/kärnavvikelser mot protokollet. Begränsa en policykorrigering till pilotservern och godkänn den på nytt efteråt; inaktivera inte skyddet för hela tenanten. Om en återgång behövs använder du den i förväg fastställda och testade systemåterställningsvägen samt Sophos supportförfarande för den aktuella agentversionen. Ta inte bort komponenter eller drivrutiner på chans. Om plattformsfrågan eller en återställningsväg som stöds fortfarande är oklar, spara loggar och plattformsdata och kontakta Sophos Support. Fram till dess förblir utrullningen stoppad.