Sophos Fusion: konfigurera och kontrollera Server Threat Protection på ett säkert sätt

När en serveragent har installerats är en synlig policy ännu inget bevis på att skyddet fungerar. Om installation och verifiering av agenten återstår: följ installation och verifiering av Windows Server för Windows Server, eller den separata installationsvägen för SPL för Linux-servrar. För en säker basnivå i Sophos Fusion (tidigare Sophos Central) kontrollerar du först vilken server och plattform det gäller, behåller sedan de rekommenderade inställningarna i en liten pilotgrupp och kontrollerar till sist under serverns flikar Policies, Status och Events vad som faktiskt har slagit igenom. Windows- och Linux-servrar delar policygränssnitt, men inte alla skyddsfunktioner.

Före ändringen: dokumentera plattform och omfattning

Anteckna tenant, servernamn, operativsystem, installerad agent, befintlig licens respektive tillgängliga funktioner, serverroll och aktuell policy. Jämför en Windows- och en Linux-pilotserver med samma produktionsprofil. Databasservrar, domänkontrollanter och Linux-värdar för containrar bör testas separat på grund av olika belastning och filåtkomst. Exemplen Pilot-Windows-App och Pilot-Linux-App är valfria namn på servergrupper, inte värden som Sophos föreskriver. Öppna fliken Server Groups under My Products > Server > Servers och välj Add Server Group. Skapa en grupp för vardera plattformen och tilldela enstaka servrar. En server kan bara tillhöra en grupp: om du flyttar den till en pilotgrupp tas den bort från sin tidigare grupp, vilket även kan förändra andra policyer som gäller för servern. Dokumentera därför i förväg varje servers tidigare grupp, tillämpade policyer samt deras ordning, tilldelningar och inställningar som underlag för återställning. Börja med bara några få representativa servrar, inte hela produktionen.

Base Policy skyddar servrar när ingen matchande policy med högre prioritet gäller. Ytterligare policyer lämpar sig för riktade avvikelser. Sophos Fusion tillämpar den första matchande aktiva policyn uppifrån för varje policytyp; inställningar från flera Threat Protection-policyer kombineras inte. Den gemensamma urvalsmodellen beskrivs i grunderna för policyer, men för denna pilot är det Server-policyer och servergrupper som gäller, inte grupper för endpoint-datorer. Placera den särskilda pilotpolicyn ovanför en allmän policy och behåll i övrigt den rekommenderade basnivån. Ändringar i en delad policy påverkar alla servrar som tilldelats den – kontrollera tilldelningen före Save.

Konfigurera Server Threat Protection i piloten

Öppna My Products > Server > Policies och välj Add Policy. Om du får välja typ, välj Threat Protection. För en befintlig policy öppnar du först policytypen och sedan namnet. Tilldela den nya policyn till den lilla pilotgruppen under Assigned to och kontrollera Excluded from om fältet visas. Ändra inte av misstag Base Policy för alla servrar.
Öppna Settings och låt policyn vara aktiverad. Välj först Windows under Show filters > Operating System, klicka på Apply, upprepa för Linux och klicka på Apply igen. Filtret visar vilka inställningar som finns för respektive plattform; det aktiverar ingen funktion i agenten. Recommended och Enabled/Disabled hjälper dig att se avvikelser.
Behåll om möjligt de rekommenderade inställningarna för Live Protection, Deep Learning och Real-time Scanning - Local Files and Network Shares. Under Real-time Scanning - Local Files and Network Shares styr Scan realtidsskanning av lokala filer och filer som nås via nätverket; Local begränsar skanningen till filer på själva enheten. Att byta till Local kräver ett motiverat användningsfall och test av de berörda nätverksresurserna.
On-access-skydd för Linux är avstängt som standard. För att en Linux-pilot ska få skydd vid filåtkomst måste SPL-produkten antivirus, det vill säga dess AV-plugin, vara installerad. I den gällande Server Threat Protection-policyn måste både Scan och Enable scan for Server Protection for Linux Agent vara aktiverade under Real-time Scanning - Local Files and Network Shares; det andra alternativet är avstängt från början. Kontrollera den installerade AV-komponenten på pilotservern enligt den länkade SPL-installationsartikeln. Utan komponenten eller om något av de två alternativen inte är aktiverat får piloten inte godkännas som on-access-skyddad. Dokumentera bristen och avbryt utökningen. En schemalagd skanning ersätter inte realtidsskanning: den kontrollerar vid bestämda tidpunkter, inte vid filåtkomst. Enable scheduled scan finns för båda plattformarna; välj vid behov en tid med låg belastning. Klockslaget följer enhetens lokala tid. På Linux använder den schemalagda skanningen Live Protection oberoende av motsvarande policyinställning.
Låt om möjligt Enable event journals vara aktiverat: utan dessa journaler saknas data för efterföljande utredningar under den tid funktionen är avstängd. Då fungerar inte heller Threat Graphs eller, om det används, Server File Integrity Monitoring. Konfigurera inga globala journalstorlekar här. Spara ändringen och kontrollera den gällande policyn på enheten innan du tilldelar fler servrar.

Blanda inte ihop funktionerna: realtidsskanning av internettrafik, HTTPS-dekryptering, CryptoGuard-/exploit-skydd, AMSI, Adaptive Attack Protection och Security Heartbeat är dokumenterade som Windows-funktioner i denna policy. Det innebär inte att de har motsvarande effekt på Linux. Linux runtime detections är en separat Linux-funktion som kräver rätt licens; att alternativet syns bevisar varken behörighet eller aktiv detektering under körning. Kontrollera den konkreta licensen och agentens och tenantens status innan du planerar att använda funktionen. Linux-alternativen för realtidsskanning och för att stoppa skadliga processer i samband med den är inte heller samma sak som Windows-modulerna för skydd under körning.

Gör undantag endast vid en belagd konflikt

Ett skanningsundantag minskar skyddet, även om andra kontroller fortfarande kan gälla för det undantagna objektet. Vid en falsk detektering letar du i fliken Events efter tidsstämpel, detektering och berörd sökväg. Stäm av detta mot programversion, leverantörens anvisningar och ett reproducerbart fel. En databasapplikation kan dock även utan detekteringshändelse drabbas av mätbar prestandaförlust vid skanning på grund av täta filåtkomster: jämför på ett reproducerbart sätt körningstid, belastning och berörda åtkomster före och efter ett tidsbegränsat test i pilotgruppen. Att en tjänst bara upplevs som långsam, utan spårbar koppling till skanning, motiverar inget undantag.

Under Settings > Exclusions > Add Exclusion väljer du Exclusion Type och anger bara det objekt som faktiskt berörs. För File or folder begränsar du Active for till Real-time Scanning eller Scheduled Scanning om inte båda bevisligen påverkas. Vid belagd databasbelastning i Windows undersöker du först Process (Windows) med programmets fullständiga sökväg enligt leverantörens anvisningar: endast filer som används av den processen undantas när processen kommer åt dem, i stället för att ett helt filträd undantas för andra processer. På Linux stöder File or folder (Linux) sökvägar till filer och mappar samt ? och *. En fullständigt angiven sökväg som /mnt/hgfs/excluded är ett syntaxexempel ur Sophos dokumentation, inte en generell rekommendation att undanta den mappen. Ersätt den endast med en verifierad sökväg på den berörda servern. Behandla inte Windows-undantag för processer eller exploits som motsvarigheter på Linux. Använd inte undantag för Detected Exploits eller hashning som generella genvägar runt skanning; kontakta först Sophos Support om ett hashbaserat undantag övervägs. Ett policyundantag gäller endast de servrar där policyn tillämpas, medan ett Global Exclusion omfattar hela tenanten. Skapa inte ett globalt detekteringsundantag via Don’t detect this again när du granskar en händelse. Den gemensamma vägledningen om undantag för endpoints och servrar förklarar typer, omfattning och återställning; här är valet fortfarande ett beslut för serverpolicyn. Dokumentera detekteringshändelsen eller reproducerbara prestandadata, leverantörens anvisningar, skäl, ansvarig, berörda servrar, test och planerat slutdatum. Kontrollera det berörda arbetsflödet efter att du sparat och ta bort undantaget igen när orsaken är åtgärdad och återställningen har verifierats.

Bekräfta effekten på den enskilda servern

Öppna My Products > Server > Servers, välj pilotservern och kontrollera:

Policies: Visas verkligen den avsedda policyn under Threat Protection? Om inte, kontrollera tilldelning, aktivering och ordning. Om du klickar på policyn öppnas dess inställningar; ändringar där påverkar även andra tilldelade servrar.
Status: På nyare Windows-servrar visar Health status och bedömningarna för Communication, Operations, Services, System, Threat och Update möjliga problem. På Linux och äldre Windows-servrar visar Security Health bland annat senaste kontakten med Sophos Fusion och aktiva Sophos-tjänster; det är inte samma detaljerade Windows-bedömning. En grön indikator ensam bevisar inte att angreppsskyddet har testats.
Events: Kontrollera meddelanden, lyckade uppdateringar och i förekommande fall en redan befintlig detektering via Details för den relevanta tidsperioden. Att ingen skadeprogramshändelse finns är inget funktionstest. Utlös inte avsiktligt skadeprograms- eller exploit-aktiviteter på en produktionsserver. Den visade tidpunkten Last active kan ligga före en händelse eftersom den uppdateras ungefär en gång i timmen.

På Linux kontrollerar du dessutom lokalt att produkten antivirus/AV-plugin är installerad och att policyn har tagits emot (kontrollvägar finns i SPL-installationsartikeln). Policies, Status, Events och en grön hälsostatus bevisar inte i sig att on-access-skanning är aktiv eller att den faktiskt detekterar. Endast på ett godkänt icke-produktionssystem kan ett kontrollerat funktionstest med den ofarliga EICAR-testfilen enligt Sophos anvisningar användas för att kontrollera reaktionen vid filåtkomst, posten i AV-loggen och larmet i Fusion. Ta bort testfilen och hantera testlarmet enligt lokala rutiner. Utan ett sådant test är detekteringsförmågan obekräftad; inga skadeprogramstester i produktion.

Dessutom visar Account Health Check när Server Threat Protection-policyer avviker från Sophos rekommendationer. Vid en varning öppnar du den angivna policyn, granskar rödmarkerade inställningar och korrigerar dem riktat. Fix automatically återställer alla alternativ i berörda policyer till rekommenderade inställningar och kan skriva över avsiktliga avvikelser i piloten; kontrollera berörda servrar och ändringens omfattning innan du bekräftar. Granska separat varningen för riskabla Policy exclusions: kontrollen fångar bara särskilt osäkra undantag, så grön status intygar inte att alla undantag är ofarliga. Gör inte heller där någon automatisk korrigering utan att granska hela den berörda policyomfattningen; den kan ta bort undantag från samtliga berörda policyer. Automatiska ändringar dokumenteras i granskningsloggen. Kontrollera efter varje korrigering återigen policy, status och händelser på pilotservern.

Om resultatet inte stämmer med konfigurationen

Fel policy eller ingen förväntad policy: Kontrollera tenant, servergrupp, aktiverad policy och prioritet i listan. Läs av rätt namn på serverns flik Policies; dra inte slutsatser om vad som gäller enbart från policylistan.
Oklart om realtidsskanning fungerar på Linux: Kontrollera Scan och Enable scan for Server Protection for Linux Agent under Real-time Scanning - Local Files and Network Shares i den gällande, Linux-filtrerade policyn samt SPL:s AV-plugin/produkten antivirus lokalt. Om något saknas eller effekten fortfarande är oklar, påstå inte att on-access-skydd finns, utöka inte piloten och lämna agent- och licensuppgifter samt diagnostik till Sophos Support.
Varning eller röd hälsobedömning: Öppna den konkreta bedömningen för Communication, Services eller Update i Windows; jämför senaste aktivitet i Fusion, aktiva tjänster och larm på Linux. Åtgärda först kommunikations- eller uppdateringsproblem och kontrollera sedan på nytt att policyn har tagits emot.
Programmet svarar långsamt eller en fil blockeras: Vid blockering kontrollerar du samtidig händelse och sökväg. Vid prestandaförlust utan händelse säkrar du reproducerbara jämförelser av belastning och åtkomst samt leverantörens anvisningar. Undanta inte på måfå en hel katalogstruktur eller hela tenanten. Ett snävt pilotundantag är försvarbart endast med belagd orsak och en väg tillbaka. Om avvikelsen kvarstår dokumenterar och eskalerar du resultatet, policyns tilldelning och agentstatus.

Stoppa och återställ piloten

Stoppa utökningen om Linux-on-access-skydd saknas, fel policy gäller, agenten har ihållande hälsoproblem, blockeringar är outredda eller en affärskritisk arbetsbelastning störs på ett mätbart sätt. Dokumentera berörda servrar och avvikelsen; samordna återställningen med ansvariga för arbetsbelastningen under ändringsfönstret. Flytta tillbaka varje omplacerad server till dess tidigare grupp, eller ta bort den från pilotgruppen om den tidigare inte tillhörde någon grupp. Om pilotändringarna har ändrat en befintlig policy, dess prioritet eller tilldelning, återställ dessutom den dokumenterade ordningen, tilldelningen och inställningarna; att enbart flytta tillbaka servern till den gamla gruppen reparerar inte en ändrad policy. Dra tillbaka pilotundantag på ett kontrollerat sätt efter granskning av berörd arbetsbelastning: säkerställ först att den tidigare blockeringen eller prestandaförlusten inte återkommer. Vid behov utreder du orsaken och dokumenterar tills vidare ett snävt avgränsat, tidsbegränsat kvarstående behov i stället för att ta bort undantaget okontrollerat. Kontrollera sedan på varje berörd server grupptillhörighet, gällande policyer, status/hälsa, händelser och det tidigare störda arbetsflödet. Utan lyckad verifiering förblir utrullningen stoppad och incidenten eskaleras.