Sophos Firewall: bästa praxis för nätverkssäkerhet

Brandväggar var länge platsen där man stoppade attacker. I dag är de själva ett av de mest attraktiva målen. Det är logiskt: en brandvägg sitter i en privilegierad position mellan internet, platsnätverk, molntjänster, VPN-åtkomst och interna applikationer. Den som hittar en sårbarhet, ett svagt lösenord eller en felkonfiguration här står inte längre utanför dörren, utan ofta redan mitt i byggnaden.

Därför räcker det inte längre att se en brandvägg enbart som en policy-motor för Allow- och Deny-regler. Modern nätverkssäkerhet behöver tre pelare: hardening, protection samt detection and response. Attackytan måste minskas före en attack, attacker blockeras rent under attacken och därefter måste man snabbt kunna se vad som hänt.

Jag har i många år arbetat med Sophos Firewall-miljöer i mycket olika storlekar och branscher. Rekommendationerna nedan är därför inte en teoretisk funktionslista, utan sådant som gång på gång visat sig fungera i verkliga kundmiljöer, migreringar, audits och supportfall.

Varför brandväggar är så starkt i fokus

En brandvägg är ett attraktivt mål för angripare eftersom den är exponerad, privilegierad och ofta affärskritisk. Dessutom kör många miljöer brandväggar, VPN-portaler eller fjärradministration under många år. Alla miljöer är inte ordentligt patchade, alla managementytor är inte verkligen avskärmade och alla inloggningar skyddas inte med multi-factor authentication.

I praktiken syns framför allt tre återkommande orsaker bakom lyckade attacker:

• Sårbarheter i brandväggar och edge-system, särskilt när patchar installeras sent eller inte alls.
• Komprometterade inloggningsuppgifter och identitetsattacker, ofta utan MFA eller med svag MFA-konfiguration. Sophos Active Adversary Report 2026 anger identitetsrelaterade orsaker som root cause i 67.32 % av de analyserade fallen.
• Exponerade system, till exempel RDP, VPN-portaler, User Portals eller adminytor som är direkt nåbara från internet.

Den viktigaste tanken bakom detta: många attacker är inte längre spektakulära “inbrott”. Mycket ofta loggar angripare helt enkelt in. Om ett användarkonto, adminlösenord eller VPN-konto är komprometterat ser det första steget först ut som legitim användning för brandväggen.

De tre pelarna i modern nätverkssäkerhet

Sophos beskriver skyddet av moderna nätverk som ett spektrum från proaktivt till reaktivt:

1. Hardening: minska attackytan, ta bort föråldrade system, använda säkra produkter, kontrollera konfigurationer och begränsa åtkomst.
2. Protection: blockera attacker, kontrollera krypterad trafik och använda Web, IPS, Zero-Day och Application Control på ett meningsfullt sätt.
3. Detection and Response: upptäcka avvikelser, isolera komprometterade enheter, korrelera hotdata och reagera automatiserat.

Många brandväggar är traditionellt starka i den andra pelaren. De blockerar trafik, inspekterar paket, känner igen kända mönster och driver igenom policies. Det är viktigt, men inte längre tillräckligt. Om brandväggen själv är felkonfigurerad, om Remote Access körs utan MFA eller om ett opatchat system fortfarande är produktivt finns ett strukturellt problem som ingen enskild IPS-regel löser rent.

Min erfarenhet visar att de bästa resultaten inte skapas av en magisk funktion, utan av ren grundkonfiguration, regelbundna reviews och en brandvägg som är integrerad i den övriga säkerhetsprocessen.

Pelare 1: Hardening före attacken

Hardening är den del av säkerhetsarbetet som sällan får applåder, men som gör skillnad när det gäller. Det handlar om mindre attackyta, färre gamla system, färre öppna managementvägar och mindre beroende av manuella reaktioner.

Minska infrastrukturen och ta bort gamla system

Det enklaste sättet att minska en attackyta är ibland det mest obekväma: stänga av saker. Varje gammal appliance, glömd VPN-tjänst, managementportal och server som inte längre stöds är en extra angreppspunkt. Särskilt kritiska är system vid nätverkskanten eller system som indirekt möjliggör privilegierad åtkomst till interna nät.

För Sophos Firewall-admins betyder det konkret:

• Kontrollera regelbundet vilka brandväggar, REDs, VPN-gateways, WLAN-controllers, reverse proxies och Remote Access-komponenter som fortfarande är produktiva.
• Ta bort end-of-life- eller end-of-support-system från privilegierade positioner.
• Konsolidera funktioner när det minskar komplexiteten: firewall, SD-WAN, DNS Protection, ZTNA, Threat Feeds, reporting och central management bör samordnas så rent som möjligt.
• Dokumentera vilka tjänster som verkligen måste vara nåbara från internet.

Målet är inte att stoppa in så mycket som möjligt i en produkt. Målet är att undvika blind legacy. En liten, aktuell och välkontrollerad infrastruktur är nästan alltid säkrare än en stor, historiskt vuxen miljö med många “så har det alltid varit”-undantag.

Säkra managementåtkomst konsekvent

En av de viktigaste best practices är enkel: Web Admin Console och User Portal bör inte vara onödigt nåbara från WAN. Om fjärradministration krävs bör den ske via Sophos Central, ett dedikerat managementnät, ZTNA eller en annan kontrollerad väg.

I kundmiljöer ser jag om och om igen att problemet inte är den mest komplicerade attacktekniken, utan ett gammalt admin-konto, en historiskt vuxen portal eller ett “tillfälligt” undantag som aldrig togs bort. Just sådana punkter hör hemma i en regelbunden firewall review.

Följande punkter bör kontrolleras i varje Sophos Firewall-miljö:

• Aktivera MFA för administratörer, särskilt för standardadmin och alla konton med omfattande rättigheter.
• Tvinga MFA för VPN- och portalinloggningar om sådana åtkomster fortfarande används.
• Undvik WAN-åtkomst till Admin Console och User Portal eller begränsa den kraftigt till dedikerade källnät.
• Konfigurera starka lösenordsregler för användare och administratörer.
• Säkra SSH, helst med public-key-authentication och utan bred WAN-nåbarhet.
• Aktivera centrala backuper och skydda backupåtkomst, eftersom konfigurationsbackuper kan innehålla känslig information.
• Aktivera notifieringar och logging så att säkerhetsrelevanta händelser inte försvinner i driften.

Backuper underskattas ofta. En brandväggsbackup innehåller inte bara harmlösa inställningar, utan information om nät, regler, certifikat, VPNs och interna strukturer. Därför måste backuper krypteras, lagras kontrollerat och testas regelbundet.

Sätt Device Access och Local Service ACL medvetet

När man talar om WAN-åtkomst måste man i Sophos Firewall konkret tala om Device Access och Local Service ACL. I Device Access-matrisen anges zonvis vilka lokala brandväggstjänster som är nåbara: HTTPS admin, User Portal, SSH, ping, DNS, Captive Portal, VPN-portaler och andra tjänster.

Best practice är här mycket enkel men effektiv: från WAN-zonen bör bara det som verkligen behövs vara nåbart. Adminåtkomst, SSH och User Portal hör inte hemma brett på internet. Om undantag behövs bör de med Local Service ACL Exception Rules begränsas till konkreta käll-IP-adresser eller managementnät.

Landsregler som minimiskydd

Om fasta käll-IP-adresser inte är realistiska rekommenderar jag att åtminstone arbeta med landsregler. Åtkomst endast från några relevanta länder är fortfarande betydligt bättre än global nåbarhet. Alternativt kan man blockera länder som företaget inte har någon relation till och där medarbetare eller admins normalt inte befinner sig. Det ersätter inte MFA, starka roller och rena ACLs, men minskar onödigt brus och många automatiserade åtkomstförsök.

Ur mitt perspektiv är detta en av de första punkterna i varje firewall review. Många riskabla konfigurationer uppstår inte av illvilja, utan för att en tjänst öppnades kort för en migrering, ett supportfall eller ett test och sedan aldrig stängdes. Det är just sådana detaljer som skiljer en brandvägg som bara kör från en brandvägg som drivs rent.

Kontrollera Login Security och adminroller

MFA är viktigt, men loginlagret består av mer än en andra faktor. Administratörer bör använda egna, spårbara konton och inte permanent arbeta med ett delat full admin-konto. Rollbaserade rättigheter hjälper till att separera support-, reporting- eller helpdesk-åtkomst från den egentliga firewall-administrationen.

Dessutom bör misslyckade inloggningsförsök begränsas, sessioner avslutas rent och adminåtkomst begränsas till definierade nät. En login disclaimer kan vara juridiskt meningsfull i vissa miljöer, men ersätter inte verkliga tekniska kontroller. Viktigare är starka lösenordspolicies, korta inaktiva sessioner, brute-force-skydd och least privilege.

Undvik patch fatigue: Hotfixes måste verka snabbt

Patching är ett av de ämnen där teori och praktik ligger långt från varandra. Självklart vet varje admin att firmware-uppdateringar är viktiga. I verkligheten betyder de underhållsfönster, riskbedömning, HA-planering, kommunikation med verksamheten och ibland downtime. Det leder till patch fatigue: uppdateringar skjuts upp eftersom de är krävande.

Just här blir tidsfaktorn farlig. Identitetsattacker är numera den dominerande root cause, men sårbarhetsexploatering är fortfarande en reell vektor, särskilt för edge-system som brandväggar, VPNs och andra internetnära tjänster. Sophos Active Adversary Report 2026 nämner som exempel CVE-2024-40766 i SonicOS, synlig i en stor del av de bekräftade exploitfallen i datasetet. Samtidigt låg mediantiden mellan vendor advisory eller patch och observerad exploatering på 322 dagar. Det är en tydlig signal: patch fatigue är inte ett abstrakt driftproblem, utan ett attackfönster.

Sophos Firewall tar här ett viktigt steg: Automated Hotfixes gör säkerhetsrelevanta live patches möjliga utan klassiskt underhållsfönster. För admins är det mycket värdefullt, eftersom den kritiska skyddseffekten inte behöver vänta till nästa lediga underhållsfönster.

Ändå ersätter Hotfixes inte en ren uppdateringsstrategi. De stänger den farliga luckan mellan upptäckt sårbarhet och reguljär firmware-upgrade. Best practice är därför:

• Låt Hotfixes vara aktiverade.
• Kontrollera firmwareversioner regelbundet och dokumentera förberedelsen av firmware update.
• Läs upgrade paths och kompatibilitet i förväg.
• Förbered backuper och rollback-plan.
• Planera HA-kluster och fjärrplatser separat.

Behandla inte VPN som bevis på tillit

Remote Access VPN var standard i många år. Problemet: klassisk VPN tänker ofta i nätverk, inte i applikationer. Den som ansluter framgångsrikt befinner sig ur många miljöers perspektiv redan i ett betrott område. Om endpointen är komprometterad eller inloggningsuppgifter stulits kan en angripare röra sig vidare därifrån.

Zero Trust Network Access (ZTNA) löser inte detta med magi, utan med en bättre princip: Trust nothing, verify everything. Åtkomst ges inte brett till ett nätverk, utan bedöms per användare, enhet, tillstånd och applikation. En enhet måste vara frisk och compliant, identiteten verifieras och policyn avgör granulärt vilken applikation som är nåbar.

ZTNA är inte automatiskt ett Sophos-beslut

Viktigt är detta: ZTNA är inte ett beslut som automatiskt måste innebära Sophos ZTNA. Beroende på miljön kan specialiserade ZTNA-, SSE- eller SASE-leverantörer vara längre fram funktionellt, erbjuda bättre integrationer eller passa organisationen bättre. Avgörande är inte leverantörsnamnet, utan om identitet, device posture, applikationsåtkomst, logging och drift samspelar rent.

Det är också min grundläggande hållning i Sophos-projekt: jag väljer inte automatiskt Sophos för varje tema. Om en tredjepartslösning för ZTNA, SSE, Threat Intelligence, SIEM eller NDR passar bättre tekniskt, då är det den bättre rekommendationen. En bra säkerhetsarkitektur uppstår inte genom maximal leverantörsbindning, utan genom rent integrerade komponenter med tydligt ansvar.

För rena Sophos-miljöer kan integrationen ändå vara intressant, eftersom ZTNA, Endpoint, Firewall och Sophos Central kan användas tillsammans. En komprometterad eller icke-compliant enhet kan förlora åtkomst utan att en admin först manuellt bygger om firewall-regler. Det är också värt att titta på ZTNA Gateway på Sophos Firewall. I blandade eller större miljöer bör man dock jämföra medvetet och inte automatiskt välja den befintliga firewall-leverantören som ZTNA-plattform.

Den som fortfarande är starkt beroende av SSL VPN eller IPsec Remote Access bör åtminstone kontrollera dessa punkter:

• Tvinga MFA för varje Remote Access-åtkomst.
• Ta bort gamla eller oanvända VPN-användare.
• Kontrollera gruppimport från AD eller Entra ID så att Remote Access inte aktiveras oavsiktligt.
• Minska Split-Tunnel, tillåtna nät och rättigheter till minimum.
• Planera stegvis migrering till en lämplig ZTNA-, SSE- eller SASE-lösning, särskilt för interna webbappar, RDP, SSH, administrationsportaler och affärsapplikationer.

Segmentering mot Lateral Movement

När angripare kommer in med giltiga credentials eller via en exponerad tjänst avgör den interna segmenteringen hur långt de kan röra sig. En brandvägg bör därför inte bara vara perimeter-gateway, utan separera interna zoner rent: användare, servrar, management, IoT, gästnät, produktion, backup och särskilt kritiska system hör inte blint hemma i samma tillitsmodell.

Praktiskt betyder det att VLAN och zoner inte bara byggs för ordningens skull, utan skyddas med verkliga firewall-regler. Mellan användar- och servernät bör endast nödvändiga applikationer tillåtas. Managementåtkomst hör hemma i dedikerade adminnät. IoT- och skrivarnät bör inte kunna prata fritt med servrar. Backuper och domain controllers förtjänar särskilt restriktiva regler och bra logging.

Här sluts cirkeln till påståendet “angripare loggar in”. Om ett komprometterat konto visserligen har åtkomst till en applikation, men inte till hela nätet, blir en incident inte automatiskt en fullständig kompromettering.

I nya projekt planerar jag därför segmentering så tidigt som möjligt. I efterhand är det fortfarande möjligt, men betydligt jobbigare eftersom applikationer, undantag och historiska beroenden först måste redas ut.

Gör felkonfigurationer synliga

En brandvägg kan vara tekniskt mycket kraftfull och ändå bli farlig genom fel konfiguration. För breda regler, “Any”-objekt, svag autentisering, saknade IPS-policies, avstängda pattern updates eller öppna portaler är typiska exempel. Det svåra är att sådana risker i växande miljöer inte alltid syns direkt.

Sophos Firewall Health Check adresserar just detta problem. Den kontrollerar dussintals inställningar mot best practices och benchmarks och visar i Control Center var konfigurationer är riskabla eller avviker från rekommenderade standarder. Resultaten prioriteras efter risk, leder direkt till berörda inställningar och kan beroende på situation åtgärdas eller medvetet överskridas.

Health Check är särskilt användbar för återkommande driftsprocesser:

• efter en ny firewall-rollout,
• efter större regeländringar,
• före och efter firmware-upgrades,
• före audits,
• efter migreringar från gammal hårdvara,
• som regelbunden kvartalscheck.

Viktigt är också: en Health Check tar inte bort behovet av adminernas omdöme. Alla rekommendationer passar inte alla miljöer. Vissa punkter har compliance- eller driftskäl, andra är tydliga säkerhetsluckor. Avgörande är att avvikelser bedöms medvetet och inte får växa obemärkt.

Ur mitt perspektiv är Health Check framför allt stark som löpande driftsverktyg. Den är inte bara något för första go-live, utan en bra startpunkt för kvartalsreviews, audit-förberedelse och rensning av gamla regelverk.

Secure by Design: härda själva brandväggen

Ur mitt perspektiv behövs inte bara säkerhetsprodukter, utan säkra säkerhetsprodukter. Det är en viktig skillnad. En brandvägg får inte bara blockera attacker mot andra system, utan måste själv vara härdad mot attacker.

För Sophos Firewall ingår flera nivåer:

• Härdad kernel och moderniserad arkitektur: den nyare Xstream-arkitekturen bygger mer på isolation, modularisering, containerisering och privilege separation. Därmed minskas vissa sårbarhetsklasser och effekter begränsas genom bättre isolation. Mitigations mot side-channel- och CPU-sårbarheter tillkommer. Det gör plattformen robustare, men inte immun mot sårbarheter.
• Automated Hotfixes: säkerhetskorrigeringar kan distribueras mycket snabbt och utan klassiskt underhållsfönster.
• Remote Integrity Monitoring: den integrerade Sophos XDR Linux Sensor kan övervaka systemintegritet i realtid, till exempel obehöriga konfigurationsändringar, Rule Exports, misstänkt programkörning eller File Tampering. Detta är värdefullt bara om funktionen är aktiverad, licensierad, ansluten och övervakad i drift.
• Säker Central-hantering: administration kan ske via Sophos Central utan att managementportar exponeras brett mot internet.
• Health Check: riskabla konfigurationer blir direkt synliga.
• Krypterade backuper: konfigurationsdata överförs och lagras skyddat.

Dessutom satsar Sophos på proaktiv övervakning av den installerade firewall-basen. Telemetri från brandväggar kan hjälpa att tidigare upptäcka tecken på attacker eller manipulation. När ett mönster blir synligt kan Sophos stödja kunder eller partners riktat och rulla ut Hotfixes snabbt och brett.

Dessa punkter är i vardagen mindre spektakulära än en ny firewall-regel eller en blockerad attack i loggen. På lång sikt är de ändå avgörande. En härdad produkt minskar sannolikheten att brandväggen själv blir ingångspunkt. Men den ersätter inte en ren patchprocess, monitoring eller regelbunden konfigurationsreview.

Vad man bör förvänta sig av en firewall-tillverkare

Secure by Design är inte bara en produktegenskap, utan också en leverantörsfråga. Kunder bör kunna förvänta sig att tillverkare hanterar sårbarheter transparent, kommunicerar lifecycle-information tydligt, rullar ut säkerhetsfixar snabbt och bygger produkter så att felkonfigurationer och komprometterade komponenter blir synliga så tidigt som möjligt.

Ansvaret är delat. Tillverkare måste leverera säkra produkter och reagera transparent. Kunder måste installera uppdateringar, ersätta EOL-system, använda MFA och kontrollera driften regelbundet. Båda delarna hör ihop.

Pelare 2: Protection under attacken

Hardening är basen. Därefter måste brandväggen fortsätta göra det den används för: kontrollera trafik och blockera attacker. För Sophos Firewall omfattar det bland annat IPS, Web Protection, Application Control, Zero-Day Protection, TLS Inspection, DNS Protection och Threat Intelligence Feeds.

Sophos använder starkt Xstream-arkitekturen för detta. Betrodd trafik kan processas effektivare, beräkningsintensiva uppgifter som crypto-operationer går via optimerade vägar, och mer prestandareserv blir kvar för trafik med högre risk, till exempel Deep Packet Inspection, TLS Inspection och Zero-Day Protection.

TLS Inspection är ett bra exempel på balansen mellan säkerhet och drift. Utan dekryptering förblir en stor del av modern trafik osynlig. Med dåligt planerade TLS-regler skapas däremot supportfall, certifikatproblem eller prestandaflaskhalsar. Best practice är därför inte “dekryptera allt blint”, utan att klassificera rent:

• kritiska användargrupper och servrar först,
• undanta banking, health, privacy och kända problematiska kategorier rent,
• testa blockerings- och varningssidor,
• dokumentera certifikatdistribution,
• utvärdera loggar aktivt.

Min rekommendation är att inte starta TLS Inspection som ett allt-eller-inget-projekt. Bättre är en ren rollout med tydliga användargrupper, undantag, testfönster och loggutvärdering. Då ökar synligheten utan att helpdesk blir överkörd dag ett.

Threat Feeds hör också till detta skyddsområde. Sådana feeds hjälper till att blockera kända skadliga IPs, domäner eller URLs direkt vid nätverkskanten. I nyare Sophos Firewall-versioner är de betydligt starkare integrerade i Active Threat Response och skyddsmekanismer.

Threat Feeds blir särskilt intressanta när man inte bara använder generiska listor, utan kurerade tredjepartsfeeds med aktuell kontext. Ett exempel är Cybora.io, där skadliga IPs och domäner från olika källor och firewall-telemetri sammanförs till användbara feeds. Hur sådana feeds kan användas på brandväggar har jag beskrivit mer utförligt i artikeln Threat Intelligence Feeds för brandväggen.

Även här gäller: Threat Feeds måste testas och observeras. För aggressiva feeds, saknade allowlist-processer eller oklara ansvar kan blockera legitim trafik och skapa mer skada än nytta i drift. Bra feeds ersätter inte en regelreview, utan är en extra byggsten med egen tuning.

De klassiska SFOS-härdningarna bör inte heller glömmas: Spoof Protection, lämpliga DoS-inställningar och Geo-IP-Blocking kan minska enkla, högljudda eller uppenbart oönskade åtkomster. Det ersätter inte en ren policy, men tar bort onödigt brus från brandväggen och blockerar attackvägar som i många miljöer saknar legitimt syfte.

Här rekommenderar jag ett pragmatiskt tillvägagångssätt: kontrollera först de stora riskerna rent, skärp sedan skyddsfunktionerna stegvis och bevisa med loggar vad som verkligen fungerar. En överlastad policy som ingen längre förstår är ingen långsiktig säkerhetsvinst.

Pelare 3: Detection and Response efter första signalen

Den mest intressanta delen av modern nätverkssäkerhet är responsen. En brandvägg bör inte arbeta isolerat, utan använda signaler från Endpoint, Server, NDR, MDR, XDR och Threat Intelligence. Sophos kan spela ut ekosystemfördelar här, men bara om integrationerna verkligen passar miljön.

Ekosystem hjälper bara när de passar

Synchronized Security och Security Heartbeat är bra idéer: brandväggen kan ta hänsyn till endpoint-status och begränsa eller blockera kommunikation för komprometterade enheter. I verkligheten använder dock allt fler företag Microsoft Defender eller andra endpoint-lösningar. Då fungerar denna del av Sophos-ekosystemet bara begränsat eller inte alls. Därför bör man inte automatiskt ta allt från samma leverantör bara för att det erbjuds som ett integrerat ekosystem.

Min rekommendation är tydlig: avgörande är vad som passar företaget och kan implementeras rent. Om Microsoft Defender, en annan EDR, en tredjeparts-NDR eller ett externt SIEM är den bättre basen, bör brandväggen integreras rent i den arkitekturen. Viktigare än cross-selling är att loggar hamnar på rätt plats, larm förstås och någon regelbundet kontrollerar vad systemen rapporterar. Utan logganalys, tuning och incidentprocess hjälper även den bästa integrationen lite.

Med Active Threat Response kan upptäckta hot automatiskt översättas till nätverksbeslut. Och med NDR Essentials får brandväggen ytterligare insyn i misstänkt nätverkstrafik, även där ingen klassisk endpoint-agent är installerad.

Automatisering behöver runbooks

Automatisering behöver ramar. Det måste vara tydligt vilka signaler som får blockera automatiskt, vem som häver en isolering, hur false positives hanteras och hur sådana processer testas. Utan runbooks, ansvar och regelbundna övningar vet ingen i en incident om en blockering var avsedd, korrekt eller för aggressiv.

Vad händer i en incident? En komprometterad enhet kan isoleras, C2-kommunikation avbrytas, exfiltration blockeras och en MDR- eller XDR-analytiker kan trigga Active Threat Response utan att först manuellt bygga en regel i brandväggen. Det är särskilt värdefullt när en attack upptäcks utanför normal arbetstid.

För admins är en sak särskilt viktig: reaktionen måste vara tillräckligt snabb. Om en MDR- eller XDR-analytiker först måste ringa, skriva ett ticket och en lokal admin sedan fredag kväll manuellt måste bygga en regel, är responstiden för lång. Automatiserad respons betyder inte att människor ersätts. Det betyder att den första inneslutningen sker direkt och att teamet därefter kan undersöka rent.

Särskilt i mindre IT-team är denna automatisering värdefull. Inte alla företag har en firewall-specialist tillgänglig dygnet runt. När Endpoint, Firewall, NDR, MDR och SIEM samverkar meningsfullt över leverantörsgränser vinner man tid, och tid är ofta den viktigaste faktorn vid aktiva attacker.

Praktisk checklista för Sophos Firewall-admins

Den som vill härda sin Sophos Firewall i dag kan börja med denna lista:

Kontrollera direkt

• Är Hotfixes aktiverade?
• Är MFA aktivt för administratörer?
• Är Web Admin Console och User Portal nåbara från WAN?
• Är SSL VPN eller IPsec Remote Access skyddade med MFA?
• Finns det oanvända lokala admin-konton?
• Är backuper planerade, krypterade och testade?
• Är Device Access och Local Service ACL reducerade till minimum?
• Är WAN-nåbara tjänster minst begränsade till relevanta länder eller kända källnät?
• Är pattern updates och firmwareversioner aktuella?

Inom de närmaste veckorna

• Kör Health Check och prioritera findings.
• Kontrollera gamla firewall-regler med “Any” som källa, destination eller service.
• Kontrollera adminroller, Login Security, session timeouts och brute-force-skydd.
• Inventera exponerade tjänster som RDP, SSH, webbservrar, portaler och NAT-regler.
• Kontrollera interna zoner och VLAN-regler mot lateral movement.
• Jämför ZTNA-, SSE- eller SASE-alternativ för typiska Remote Access-applikationer.
• Kontrollera Threat Feeds och DNS Protection.
• Aktivera Spoof Protection, DoS-skydd och Geo-IP-Blocking efter risk.
• Testa TLS Inspection strukturerat och rulla ut stegvis.

Planera strategiskt

• Ersätt end-of-life-system.
• Samordna firewall-, VPN-, DNS-, SD-WAN- och ZTNA/SSE-drift på ett meningsfullt sätt.
• Standardisera central management, reporting och alerting, till exempel via Sophos Central, SIEM eller befintliga säkerhetsplattformar.
• Definiera Syslog/SIEM-export och log retention för forensiska analyser.
• Integrera MDR/XDR/NDR-signaler i incidentprocessen.
• Inför återkommande firewall hardening-reviews.

Slutsats

Network Security Best Practices är inget engångsprojekt, utan en driftsmodell. Just eftersom brandväggar vid nätverkskanten är så privilegierade måste de regelbundet härdas, patchas, granskas och integreras i detection.

Min rekommendation efter många år med Sophos Firewall är därför tydlig: en modern brandvägg måste vara mer än en skyddsprodukt. Avgörande är säker design, synliga felkonfigurationer, snabba säkerhetskorrigeringar och en respons som i en incident samverkar med Endpoint, NDR, XDR och MDR.

Eller praktiskt sagt: om en brandvägg är så gammal att den hör hemma mer på museum än i ett rack, är den inte bara en driftsrisk. Den är en attackyta. Och just den attackytan håller jag så liten som möjligt.

Support från Avanet

Om stöd behövs för hardening av en Sophos Firewall kan Avanet hjälpa till. Som långvarig Sophos-specialist stödjer jag IT-team med firewall audits, Health Check-reviews, rensning av regelverk, Remote Access- och ZTNA/SSE-planering, uppdateringsstrategier och utbildningar.

En extern blick på managementåtkomst, VPN-konfiguration, gamla regler, WAN-exponerade tjänster och update-status lönar sig ofta. Många risker uppstår inte genom en enskild felaktig inställning, utan genom historiskt vuxna undantag som ingen längre ifrågasätter i vardagen.

Vid intresse räcker ett kort meddelande via kontaktformuläret. Därefter kan man gemensamt klargöra om en kompakt firewall review, en audit eller en utbildning är mest meningsfull för den aktuella miljön.

FAQ

Vidare länkar

• Avanet Blog: Sophos Firewall v22: översikt och alla nya funktioner
• Avanet Blog: Threat Intelligence Feeds för brandväggen
• Avanet Blog: Sophos ZTNA Gateway på Sophos Firewall
• Avanet Blog: Sophos NDR - eliminera blinda fläckar i nätverket
• Avanet KB: Sophos Firewall Firmware Update - förberedelse och best practices

Källor

• Sophos: Firewall: Network Security Best Practices
• Sophos Docs: Hardening your Sophos Firewall
• Sophos X-Ops: Nowhere, man: The 2026 Active Adversary Report