Använd Sophos Firewall Health Check på rätt sätt
Sophos Firewall Health Check är en integrerad kontroll av brandväggskonfigurationen. Den visar i kontrollcentret om viktiga inställningar följer rekommenderade säkerhets- och bästa praxis-riktlinjer. För administratörer är detta särskilt användbart eftersom riskabla konfigurationer blir synliga innan de orsakar säkerhets- eller driftproblem.
Health Check introducerades med Sophos Firewall v22. Funktionen utvärderar konfigurationer mot bland annat bästa praxis och standarder som CIS-benchmarks. Med SFOS 22.0 MR1 uppdaterades även den underliggande CIS-konteksten.
Videoguide
Vilken säkerhetsartikel passar?
Health Check är en bra startpunkt, men inte varje fynd löses helt i Health Check-artikeln. För praktisk implementering hjälper dessa ingångar:
| Situation | Bättre ingång |
|---|---|
| Samla, prioritera och dokumentera fynd | Denna artikel |
| WebAdmin, SSH, User Portal, VPN Portal, DNS eller Ping är för brett tillgängliga | Säkra Sophos Firewall-åtkomst: Konfigurera Device Access korrekt |
| MFA för administratörer, VPN Portal eller fjärråtkomst saknas | Aktivera MFA för Sophos Firewall WebAdmin, VPN Portal och fjärråtkomst |
| XML API eller automationsåtkomst är för öppen | Säkra Sophos Firewall XML API-åtkomst |
| Brandväggsregler är för breda eller oklara | Förstå och konfigurera Sophos Firewall-regler korrekt |
| IPS ska aktiveras eller kontrolleras | Ställ in och testa Sophos Firewall IPS säkert |
| TLS Inspection ska införas | Inför Sophos Firewall TLS Inspection korrekt |
| Web Protection, kategorier eller omedelbara varningar är relevanta | Använd Sophos Firewall Web-kategorier och omedelbara varningar |
| DNS-skydd ska drivas via Sophos Central | Ställ in Sophos DNS Protection med Sophos Firewall |
| Threat Feeds, NDR eller Active Threat Response ska leverera fynd | Driv Sophos Firewall NDR och Active Threat Response |
| Konfigurationsändringar måste vara spårbara | Kontrollera Sophos Firewall Audit Trail Logs |
Denna uppdelning förhindrar två typiska misstag: Fynd betraktas antingen bara som en dashboard-meddelande utan att tekniskt åtgärdas, eller så aktiveras skyddsfunktioner generellt utan att klargöra loggning, undantag och ansvar.
Vad Health Check är avsedd för
Health Check är inte en klassisk systemstatus och ingen hårdvarusensor. Den kontrollerar inte om en strömförsörjning är defekt eller om en SSD snart kommer att fallera. För detta passar andra driftkontroller, till exempel Kontrollera SSD-hälsotillstånd eller HA- och hårdvaruövervakning.
Health Check svarar snarare på dessa frågor:
- Är administrativa åtkomster för brett öppna?
- Är MFA aktiverat för kritiska inloggningar?
- Är brandväggsregler för öppna?
- Är säkerhetskopior, hotfixar, loggning eller Central-funktioner ordentligt förberedda?
- Avviker konfigurationen från rekommenderade säkerhetsstandarder?
- Finns det fynd som bör klargöras före en revision eller Go-live?
Det är därmed ett bra verktyg för härdning, granskning och förändringskontroll. Det ersätter dock inte en ren arkitektur, ingen regelverksdokumentation och ingen manuell utvärdering.
⚠️ En grön Health Check betyder inte automatiskt att brandväggen är säkert planerad. Den visar om vissa kontrollerbara inställningar passar. Nätverksdesign, affärslogik, undantag, användargrupper och driftprocesser måste fortfarande utvärderas professionellt.
Missförstå inte poängen som ett mål
Health Check är hjälpsam, men poängen bör inte bli ett självändamål. Vissa punkter är klara säkerhetsgrunder, till exempel MFA, hotfixar, lösenordsregler, begränsad WebAdmin-åtkomst, säkerhetskopior eller IPS. Andra punkter är mer beroende av Sophos-ekosystemet, licensiering eller driftmodellen.
Därför bör man inte aktivera varje rekommendation bara för att få en grön visning. Ett exempel är Login disclaimer: I revisions- eller efterlevnadsmiljöer kan en inloggningsvarning krävas. I många normala driftmiljöer skapar den dock främst ett extra klick vid varje inloggning och ger praktiskt taget ingen teknisk säkerhetsfördel. Om det bara ökar Health Check-poängen är mervärdet begränsat.
Det är liknande med funktioner som DNS Protection, MDR threat feeds, NDR Essentials, Sophos X-Ops, Synchronized Application Control eller Sophos Central Reporting. Dessa funktioner kan vara meningsfulla om de är licensierade, förstådda, övervakade och verkligen används i drift. Man bör dock inte slå på dem blint bara för att Health Check rekommenderar dem. Det avgörande är alltid: Minskar åtgärden en verklig risk i denna miljö, och finns det en ansvarig för drift, undantag och falska positiva?
Som tumregel:
| Kategori | Bedömning |
|---|---|
| Internetexponerade hanteringsåtkomster, MFA, hotfixar, säkerhetskopior, lösenordsregler, IPS | Vanligtvis verkliga säkerhets- eller driftgrunder. Dessa punkter bör tas på stort allvar. |
| Loggning, rapportering, meddelanden, NTP | Viktigt för drift och spårbarhet. Den konkreta vägen beror dock på driftmodellen. |
| DNS Protection, NDR, MDR threat feeds, X-Ops, Synchronized Security | Meningsfullt om funktionen används, licensieras, övervakas och integreras i processer. Inte automatiskt bättre bara på grund av poäng. |
| Login disclaimer | Vanligtvis mer en efterlevnads-/informationsfunktion än en teknisk skyddsåtgärd. Aktivera bara om det verkligen krävs eller önskas. |
Öppna Health Check
Health Check-statusen visas i Control center. Detaljvyn finns också via huvudmenyn:
Firewall health check
Där ser du antalet kontrollerade konfigurationer, de överensstämmande punkterna och de icke-överensstämmande punkterna. Sophos visar icke-överensstämmande poster efter allvarlighetsgrad. Uppgifterna uppdateras när en övervakad konfiguration ändras. Därför är Health Check också lämplig för en direkt uppföljning efter ändringar.
För granskningen bör man inte bara notera den övergripande statusen. Viktigare är de konkreta fynden, riskkontexten och den planerade åtgärden. Ett enskilt kritiskt fynd om WAN-åtkomlighet för WebAdmin är i drift viktigare än flera låga fynd utan internetexponering.
Översikt över de 31 Health Check-kontrollerna
Följande lista är baserad på den engelska Health Check-vyn. Statusen är medvetet inte inkluderad eftersom den varierar mellan brandväggar. Viktigare är vilken kontroll som avses och hur man professionellt bedömer den.
| Nr. | Kontroll | Modul | Standard | Allvarlighetsgrad | Bedömning |
|---|---|---|---|---|---|
| 1 | Synchronized Application Control bör vara aktiverad. | Active threat response | Recommended | Medium | Meningsfull i Sophos Endpoint-miljöer. I blandade eller Microsoft Defender-miljöer bör man först kontrollera om funktionen faktiskt levererar data. |
| 2 | NDR Essentials bör vara aktiverad och övervaka minst ett gränssnitt. | Active threat response | Recommended | Medium | Endast värdefullt om de övervakade gränssnitten är meningsfullt valda och fynd senare utvärderas. |
| 3 | Sophos X-Ops bör vara aktiverad, åtgärd Log and drop. | Active threat response | CIS | High | Säkerhetsrelevant om Threat Feeds används aktivt. Falska positiva och loggning måste kontrolleras. |
| 4 | MDR threat feeds bör vara aktiverade, åtgärd Log and drop. | Active threat response | Recommended | High | Endast meningsfullt om MDR eller motsvarande Threat Feed-funktioner är licensierade och integrerade i drift. |
| 5 | En brandväggsregel bör använda Synchronized Security Heartbeat. | Active threat response and Advanced security | CIS | Medium | Stort mervärde med Sophos Endpoint. Utan Sophos Endpoint bör det inte bara betraktas som ett poängämne. |
| 6 | Security Heartbeat bör vara aktiverad. | Active threat response and Advanced security | CIS | High | Viktigt om Sophos Endpoint används. Annars bör Endpoint-designen först klargöras. |
| 7 | Login disclaimer bör vara aktiverad. | Admin settings | CIS | Medium | Efterlevnadstema. Tekniskt sett liten skyddseffekt, men skapar ett extra klick vid inloggning. |
| 8 | Hotfix setting bör vara aktiverad. | Admin settings | CIS | High | Mycket viktigt. Hotfixar bör vara aktiva i produktionsmiljöer om förändringsprocessen tillåter det. |
| 9 | Inaktiva sessioner bör avslutas och inloggningar blockeras efter misslyckade försök. | Admin settings | CIS | High | Klar inloggningshärdning. Särskilt viktigt vid exponerade portaler och adminåtkomster. |
| 10 | Lösenordskomplexitet bör konfigureras för användare. | Admin settings | CIS | High | Meningsfullt, särskilt för lokala användare och portaler. Vid extern IdP bör även dess lösenords- och MFA-policy kontrolleras. |
| 11 | Lösenordskomplexitet bör konfigureras för administratörer. | Admin settings | CIS | High | Grundläggande härdning. Ännu viktigare är individuella administratörer, MFA och begränsad åtkomst. |
| 12 | DNS Protection bör konfigureras och vara aktiv. | Advanced security | Recommended | Medium | Inte aktivera generellt. DNS Protection är meningsfullt om Central-DNS-policyer och rapportering verkligen används. |
| 13 | MFA bör vara aktiv för fjärråtkomst-VPN-inloggningar. | Authentication | CIS | High | Mycket viktigt för SSL VPN och IPsec fjärråtkomst. Planera rollout med fallback-admin och testanvändare. |
| 14 | MFA bör vara aktiv för WebAdmin Console och VPN Portal. | Authentication | CIS | High | Mycket viktigt, särskilt om portaler är tillgängliga från mindre kontrollerade nätverk. |
| 15 | Anslutningar till autentiseringsservrar bör vara krypterade. | Authentication servers | CIS | Medium | Viktigt vid AD/LDAP/RADIUS-anslutningar. Undvik okrypterad autentisering. |
| 16 | Säkerhetskopior bör planeras på brandväggen eller i Sophos Central. | Backup & restore | CIS | Low | Låg allvarlighetsgrad, men extremt viktigt i nödfall. Testa även återställningsprocessen. |
| 17 | Offentlig nyckelautentisering bör vara aktiverad för SSH. | Device access | Recommended | High | Mycket meningsfullt. Tillåt dessutom SSH endast från betrodda nätverk. |
| 18 | User Portal bör inte vara tillgänglig från WAN-zonen. | Device access | Recommended | High | Rätt i många miljöer. Om WAN-åtkomst behövs, begränsa starkt och använd MFA. |
| 19 | WebAdmin Console bör inte vara tillgänglig från WAN-zonen. | Device access | CIS | High | En av de viktigaste punkterna. Öppna aldrig WebAdmin brett mot internet. |
| 20 | MFA bör konfigureras för standardadministratören. | Device access | CIS | High | Viktigt, men bättre är dessutom en ren adminprocess med personliga adminkonton. |
| 21 | Notifikationsmail bör konfigureras för system- och säkerhetshändelser. | Notification settings | CIS | Low | Viktigt för drift. Alternativt eller dessutom integrera övervakning, Syslog, SIEM eller Central Alerts. |
| 22 | Automatiska mönsteruppdateringar bör vara aktiverade. | Pattern updates | CIS | High | Grundläggande drift. Utan aktuella mönster förlorar många skyddsfunktioner sitt värde. I Air-Gap-miljöer behövs istället en manuell mönster- och licensprocess. |
| 23 | En webbpolicy bör väljas i en brandväggsregel. | Rules and Policies | Recommended | Medium | Meningsfullt för användarwebbtrafik. Använd inte blint på server-till-server- eller specialtrafik. |
| 24 | Zero-day protection bör väljas i en brandväggsregel. | Rules and Policies | CIS | High | Meningsfullt för lämpliga webb- och nedladdningsvägar. Beakta licens, prestanda och falska positiva. |
| 25 | IPS bör vara aktiverat och en IPS-policy bör väljas i en brandväggsregel. | Rules and Policies | CIS | High | Mycket viktig skyddspunkt. IPS måste dock väljas och loggas lämpligt per trafikväg. |
| 26 | En Application-Control-Policy bör väljas i en brandväggsregel. | Rules and Policies | CIS | Medium | Meningsfullt för klient-internetregler. Testa först vid kritisk trafik. |
| 27 | En SSL/TLS Inspection Rule bör använda åtgärd Decrypt. | Rules and Policies | CIS | High | Aktivera inte blint. TLS Inspection kräver CA-distribution, undantag, pilotfas och felsökningsprocess. |
| 28 | En Allow-regel bör inte använda Any överallt i nätverks- och tjänstefält. | Rules and Policies | CIS | Medium | Mycket viktigt för regelhygien. Any kan medvetet behövas, men måste då motiveras och loggas. |
| 29 | Sophos Central Reporting bör vara aktiverat. | Sophos central | Recommended | Medium | Användbart för rapportering och längre utvärderingar. Inte nödvändigt om Syslog/SIEM drivs korrekt. |
| 30 | Brandväggen bör vara registrerad för Sophos Central Management och Central Management bör vara aktiverat. | Sophos central | Recommended | Medium | Praktiskt för central hantering, säkerhetskopior och rapportering. Inte alla miljöer vill eller behöver molnhantering. |
| 31 | En NTP-server bör konfigureras. | Time | CIS | Low | Grundläggande krav. Utan korrekt tid lider loggar, certifikat, autentisering och felsökning. |
Prioritera fynd korrekt
Inte varje fynd har samma betydelse i varje miljö. En bra granskning sorterar därför posterna inte bara efter teknisk allvarlighet, utan också efter exponering och driftrisk.
Denna ordning har visat sig vara effektiv:
- Internetexponerade hanterings- och portalåtkomster kontrolleras.
- MFA och inloggningssäkerhet för administratörer, VPN Portal, User Portal och fjärråtkomst kontrolleras.
- Brandväggsregler med för breda källor, mål eller tjänster rensas upp.
- Loggning, säkerhetskopior och hotfixar kontrolleras.
- Skyddsfunktioner per regel kontrolleras, till exempel IPS, webbpolicy, applikationskontroll, TLS Inspection eller Zero-Day Protection.
- Central, rapportering eller NDR-fynd utvärderas efter om funktionen verkligen används och drivs i miljön.
Ordningen är pragmatisk: Först de saker som är direkt synliga på internet eller ger åtkomst till brandväggen. Därefter regelhygien och skyddsfunktioner. Därefter drift- och ekosystemfrågor.
Typiska fynd och lämpliga åtgärder
WebAdmin, User Portal eller VPN Portal är för brett tillgängliga
Om administrativa eller användarnära portaler är tillgängliga från för många zoner ökar risken för skanningar, brute-force-försök och credential stuffing. Den viktigaste artikeln om detta är Säkra Sophos Firewall-åtkomst: Konfigurera Device Access korrekt.
För produktionsmiljöer bör man kontrollera:
- Är WebAdmin verkligen nödvändig från WAN-zonen?
- Finns det en Local Service ACL Exception Rule för hanterings-IP eller adminnät?
- Är SSH endast tillåtet från betrodda nätverk?
- Är User Portal och VPN Portal endast tillgängliga där de behövs?
MFA saknas eller är inte konsekvent aktiverad
MFA bör åtminstone finnas på administrativa åtkomster och fjärråtkomst. Om Health Check visar MFA-fynd bör man inte blint ändra för alla användare samtidigt. Bättre är en kontrollerad rollout med testanvändare, fallback-admin och en ren token-process.
Den praktiska guiden finns i Aktivera MFA för Sophos Firewall WebAdmin, VPN Portal och fjärråtkomst.
Brandväggsregler är för öppna
Mycket breda regler med Any vid källa, mål eller tjänst är ofta historiskt utvecklade. Inte varje bred regel är automatiskt fel, men varje bör motiveras.
För att rensa upp är dessa frågor hjälpsamma:
- Vilken zon får verkligen åtkomst till vilken zon?
- Är mål- eller tjänstenätverk begränsade?
- Är loggning aktiv så att träffar blir synliga?
- Finns det gamla testrutiner eller tillfälliga undantag?
- Kan regeln delas upp i flera mer begripliga regler?
Grunderna finns i Förstå och konfigurera Sophos Firewall-regler korrekt. Om det är oklart vilken regel som gäller, hjälper Testa brandväggsregler med Log Viewer, Policy Test och Packet Capture.
Säkerhetskopior, hotfixar och uppdateringsprocess saknas
En Health Check kan påpeka saknade säkerhetskopior eller uppdaterings-/hotfix-teman. Dessa punkter verkar mindre spektakulära än portalexponering, men är avgörande i nödfall.
Innan större ändringar bör man skapa en säkerhetskopia och veta hur en återställning fungerar. Förfarandet beskrivs i Skapa eller återställa Sophos Firewall-säkerhetskopior. För firmware-teman passar Sophos Firewall Firmware Update - Förberedelse och bästa praxis.
Loggning och rapportering är ofullständig
Om loggar saknas är driften blind. Health Check kan ge ledtrådar om loggnings- eller rapporteringsteman, men det egentliga beslutet beror på driftmodellen.
För lokal analys är Log Viewer, Service-logs och Packet Capture relevanta. För längre lagring behövs Central Firewall Reporting eller Syslog/SIEM. Om inte enskilda logghändelser, utan trafikflöden, bandbreddstoppar eller märkbara kommunikationsrelationer ska undersökas, passar dessutom sFlow Monitoring. De lokala grunderna finns i Sophos Firewall Troubleshooting: Services och Logs.
Skyddsfunktioner är inte aktiva i regler
En vanlig punkt är regler utan IPS, webbpolicy, applikationskontroll, TLS Inspection eller Zero-Day Protection. Här bör man inte aktivera allt generellt, utan förstå trafikvägen.
Exempel:
- Användarwebbtrafik behöver andra kontroller än server-till-server-trafik.
- TLS Inspection måste planeras införas eftersom den kan störa applikationer.
- IPS och applikationskontroll behöver loggning och en granskningsrutin.
- NDR- eller Threat Feed-funktioner hjälper bara om fynd senare också utvärderas.
För TLS Inspection passar Inför Sophos Firewall TLS Inspection korrekt. För Threat Feeds passar Sophos Firewall Threat Feeds.
Dokumentera överstyrningar medvetet
Sophos Firewall tillåter att manuellt överstyra statusen för enskilda kontroller. Detta kan vara meningsfullt om en rekommendation medvetet inte implementeras i den egna miljön.
Överstyrningar bör dock inte missförstås som en städfunktion. Om en punkt överstyras bör det dokumenteras:
- Varför är rekommendationen inte lämplig?
- Vem har godkänt beslutet?
- Gäller undantaget permanent eller bara tillfälligt?
- När kommer det att granskas igen?
- Finns det en kompensatorisk åtgärd?
⚠️ En överstyrning är ingen fix. Det är en medveten riskacceptans eller ett dokumenterat undantag. Utan motivering blir Health Check mindre värdefull.
Dokumentera resultatet ordentligt
En Health Check-granskning bör generera ett spårbart resultat. Annars ser man visserligen kort en dashboard, men vet senare inte längre vilket beslut som fattades och vilka punkter som fortfarande är öppna.
För små miljöer räcker ofta en enkel tabell:
| Fält | Syfte |
|---|---|
| Datum | När kontrollerades Health Check? |
| Firmware | På vilken SFOS-version utvärderades? |
| Fynd | Vilken icke-överensstämmande punkt rapporterades? |
| Risk | Varför är punkten relevant eller mindre relevant i denna miljö? |
| Åtgärd | Vad kommer att ändras, testas eller medvetet accepteras? |
| Ansvarig | Vem klargör punkten professionellt eller tekniskt? |
| Termin | När ska åtgärden vara klar eller omvärderas? |
| Bevis | Skärmdump, ärende, ändrings-ID eller audit-logg-hänvisning |
För produktiva brandväggar bör beviset inte bara bestå av en skärmdump. Om en konfiguration ändrades hör ändringsärende, audit trail, berörd brandväggsregel och resultatet av uppföljningen ihop. För ändringar av regler, gränssnitt, värdar och tjänster är Kontrollera Sophos Firewall Audit Trail Logs särskilt användbart.
Kontrollera igen efter ändringar
Efter en fix bör man öppna Health Check igen och kontrollera om fyndet verkligen har försvunnit. Dessutom behövs en teknisk funktionskontroll, eftersom en grön status ensam inte bevisar att den produktiva trafiken fortfarande fungerar korrekt.
Exempel:
- Efter en ändring av Device access kontrollera om adminåtkomst från det avsedda hanteringsnätet fortfarande fungerar och inte längre är tillgänglig från oönskade nätverk.
- Efter MFA-ändringar logga in med en testanvändare och kontrollera fallback-admin separat.
- Efter regelverksändringar testa Log Viewer, Policy Test och berörda applikationer.
- Efter loggnings- eller rapporteringsändringar kontrollera om nya händelser verkligen är synliga lokalt, i Sophos Central eller i Syslog.
- Efter en överstyrning sätta en påminnelse så att undantaget inte glöms bort permanent.
Om flera fynd bearbetas samtidigt bör man dela upp ändringarna i små block. Annars är det vid ett senare problem oklart om Device Access, MFA, brandväggsregler, TLS Inspection eller någon annan ändring var orsaken.
Använd Health Check som en driftprocess
Health Check är som starkast när den utförs regelbundet och efter viktiga ändringar.
Lämpliga tidpunkter:
- efter den första konfigurationen eller ett Go-live,
- före och efter större regelverksändringar,
- före firmware-uppgraderingar,
- efter återställning eller hårdvarubyte,
- efter migrationer eller större arkitekturändringar,
- före revisioner,
- kvartalsvis som en säkerhetsgranskning.
För ändringar själva bör dessutom audit trail användas. Artikeln Kontrollera Sophos Firewall Audit Trail Logs förklarar hur man utvärderar configuration-audit.log och spårar konfigurationsändringar.
Praktisk granskningsprocess
En pragmatisk Health Check-granskning går till så här:
- Öppna Health Check i kontrollcentret.
- Sortera icke-överensstämmande fynd efter allvarlighetsgrad.
- Kontrollera internetexponerade tjänster och adminåtkomster först.
- Bearbeta MFA-, lösenords- och sessionsteman.
- Identifiera breda brandväggsregler och validera med Log Viewer.
- Kontrollera säkerhetskopior, hotfixar, loggning och rapportering.
- Utvärdera skyddsfunktioner per regel.
- Dokumentera berättigade undantag istället för att överstyra utan kommentar.
- Kontrollera igen efter ändringar.
- Dokumentera resultatet med datum, bearbetare och öppna punkter.
För återkommande granskningar räcker ofta en enkel tabell med fynd, risk, åtgärd, ansvarig, status och påminnelse. Viktigt är att fynd inte bara ses, utan bearbetas eller medvetet accepteras.
Begränsningar
Health Check är hjälpsam, men har klara begränsningar.
- Den känner inte till hela affärslogiken i miljön.
- Den bedömer inte om en regel behövs professionellt.
- Den ersätter inte nätverkssegmentering och ingen zonmodell.
- Den upptäcker inte automatiskt varje riskabel specialfall.
- Den ersätter ingen extern revision och ingen manuell regelverksgranskning.
- Den säger inte om varningar senare också bearbetas.
Därför bör man se Health Check som en startpunkt. Den gör synliga avvikelser greppbara, men den egentliga säkerhetskvaliteten uppstår genom god arkitektur, rena processer och konsekvent underhåll.
Driftchecklista
- Utför Health Check efter Go-live och efter stora ändringar.
- Prioritera fynd efter allvarlighetsgrad och exponering.
- Kontrollera WAN-åtkomlighet för WebAdmin, SSH, User Portal och VPN Portal.
- Aktivera MFA för administratörer, portaler och fjärråtkomst.
- Rensa eller motivera breda brandväggsregler.
- Aktivera loggning i viktiga regler.
- Kontrollera säkerhetskopior och återställningsprocess.
- Dokumentera hotfix- och firmware-process.
- Sätt överstyrningar endast med motivering.
- Dokumentera Health Check-resultatet regelbundet.