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

Brandväggar har länge varit platsen där man avvärjer attacker. Idag är de själva ett av de mest attraktiva målen. Det är logiskt: En brandvägg sitter på en privilegierad position mellan internet, lokala nätverk, molntjänster, VPN-åtkomster 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.

Just därför räcker det inte längre att betrakta en brandvägg endast som en policy-motor för tillåt- och neka-regler. Modern nätverkssäkerhet behöver tre pelare: Härdning, Skydd samt Upptäckt och respons. Man måste minska attackytan före en attack, blockera rent under en attack och sedan snabbt upptäcka vad som har hänt.

Jag har under många år hanterat Sophos Firewall-miljöer i mycket olika storlekar och branscher. De följande rekommendationerna är därför inte tänkta som en teoretisk funktionslista, utan som det som har visat sig fungera i verkliga kundmiljöer, migrationer, revisioner och supportfall.

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

En brandvägg är ett lönsamt mål för angripare eftersom den är exponerad, privilegierad och ofta affärskritisk. Dessutom: Många miljöer driver brandväggar, VPN-portaler eller fjärrhanteringsåtkomster under många år. Inte alla miljöer är ordentligt patchade, inte alla hanteringsytor är verkligen avskärmade och inte alla inloggningar är säkrade med multifaktorautentisering.

I praktiken visar sig framför allt tre återkommande orsaker till framgångsrika attacker:

• Sårbarheter i brandväggar och edge-system, särskilt när patchar försenas eller inte alls appliceras.
• Komprometterade inloggningsuppgifter och identitetsattacker, ofta utan MFA eller med svag MFA-konfiguration. Sophos Active Adversary Report 2026 nämner identitetsrelaterade orsaker som grundorsak i 67,32 % av de undersökta fallen.
• Exponerade system, såsom RDP, VPN-portaler, användarportaler eller admin-gränssnitt som är direkt tillgängliga från internet.

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

De tre pelarna i modern nätverkssäkerhet

Modern nätverkssäkerhet kan förstås som ett spektrum från proaktivt till reaktivt:

1. Härdning: Minska attackytan, ta bort föråldrade system, använd säkra produkter, kontrollera konfigurationer, begränsa åtkomst.
2. Skydd: Blockera attacker, kontrollera krypterad trafik, använd webb-, IPS-, zero-day- och applikationskontrollfunktioner på ett meningsfullt sätt.
3. Upptäckt och respons: Upptäck avvikelser, isolera komprometterade enheter, korrelera hotdata och reagera automatiserat.

Många brandväggar är traditionellt starka i den andra pelaren. Dessa system blockerar trafik, inspekterar paket, känner igen kända mönster och genomdriver policies. Det är viktigt, men inte längre tillräckligt. Om brandväggen själv är felkonfigurerad, om fjärråtkomst körs utan MFA eller om ett opatchat system fortsätter att vara produktivt, har man ett strukturellt problem som ingen enskild IPS-regel kan lösa rent.

Min erfarenhet visar: De bästa resultaten uppnås inte genom en enda magisk funktion, utan genom ren grundkonfiguration, regelbundna granskningar och en brandvägg som är integrerad i den övriga säkerhetsprocessen.

Pelare 1: Härdning före attacken

Härdning är den del av säkerhetsarbetet som sällan får applåder, men som gör skillnad i allvarliga fall. Det handlar om mindre attackyta, färre gamla laster, färre öppna hanteringsvägar och mindre beroende av manuella reaktioner.

Minska infrastruktur och ta bort gamla system

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

För Sophos Firewall-administratörer betyder det konkret:

• Regelbundet kontrollera vilka brandväggar, REDs, VPN-gateways, WLAN-kontroller, omvända proxyer och fjärråtkomstkomponenter som fortfarande är produktiva.
• Ta bort End-of-Life- eller End-of-Support-system från privilegierade positioner.
• Konsolidera funktioner om det minskar komplexiteten: Brandvägg, SD-WAN, DNS Protection, ZTNA, Threat Feeds, rapportering och central hantering bör vara så välkoordinerade som möjligt.
• Dokumentera vilka tjänster som verkligen måste vara tillgängliga från internet.

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

Säkra hanteringsåtkomst konsekvent

En av de viktigaste bästa praxis är enkel: Web Admin Console och User Portal bör inte vara onödigt tillgängliga från WAN. Om fjärradministration är nödvändig bör den ske via Sophos Central, ett dedikerat hanteringsnät, ZTNA eller någon annan kontrollerad väg.

Jag ser i kundmiljöer gång på gång att det inte är den mest komplicerade attacktekniken som är problemet, utan en gammal admin-åtkomst, en historiskt växt portal eller ett “tillfälligt” undantag som aldrig togs bort. Just sådana punkter hör hemma i en regelbunden brandväggsgranskning.

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

• Aktivera MFA för administratörer, särskilt för standardadministratören 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 starkt till dedikerade källnät.
• Konfigurera starka lösenordsregler för användare och administratörer.
• Säkra SSH, helst med public key-autentisering och utan bred WAN-tillgänglighet.
• Aktivera centrala säkerhetskopior och skydda åtkomst till säkerhetskopior, eftersom konfigurationssäkerhetskopior kan innehålla känslig information.
• Aktivera aviseringar och loggning, så att säkerhetsrelevanta händelser inte går obemärkt förbi i driften.

Punkten med säkerhetskopior underskattas ofta. En brandväggssäkerhetskopia innehåller inte bara harmlösa inställningar, utan information om nätverk, regler, certifikat, VPN:er och interna strukturer. Därför måste säkerhetskopior krypteras, lagras kontrollerat och testas regelbundet.

Sätt medvetet Device Access och Local Service ACL

När man talar om WAN-åtkomst måste man på Sophos Firewall specifikt tala om Device Access och Local Service ACL. I Device Access-matrisen fastställs zonvis vilka lokala brandväggstjänster som är tillgängliga: HTTPS-admin, User Portal, SSH, Ping, DNS, Captive Portal, VPN-portaler och andra tjänster.

Bästa praxis är här mycket enkel men effektiv: Från WAN-zonen bör endast det som verkligen behövs vara tillgängligt. Admin-åtkomst, SSH och User Portal hör inte hemma brett på internet. Om undantag är nödvändiga bör de begränsas till specifika käll-IP-adresser eller hanteringsnät via Local Service ACL Exception Rules.

Länderregler som minimiskydd

Om fasta käll-IP-adresser inte är realistiska rekommenderar jag att åtminstone arbeta med länderregler. Åtkomst endast från några få relevanta länder är fortfarande betydligt bättre än global tillgänglighet. Alternativt kan man blockera länder som företaget inte har någon relation till och där inga medarbetare eller administratörer vanligtvis befinner sig. Det är ingen ersättning för MFA, starka roller och rena ACL:er, men det minskar onödigt brus och många automatiserade åtkomstförsök.

Enligt min mening är detta en av de första punkterna i varje brandväggsgranskning. Många riskabla konfigurationer uppstår inte av ond avsikt, utan för att en tjänst öppnades kort för en migration, ett supportfall eller ett test och senare aldrig stängdes igen. Just sådana detaljer skiljer en brandvägg som bara fungerar från en brandvägg som verkligen drivs rent.

Kontrollera inloggningssäkerhet och admin-roller

MFA är viktigt, men inloggningslagret består av mer än en andra faktor. Administratörer bör använda egna, spårbara konton och inte permanent arbeta med en gemensam fulladmin. Rollbaserade rättigheter hjälper till att skilja support-, rapporterings- eller helpdesk-åtkomst från den faktiska brandväggsadministratören.

Dessutom bör misslyckade inloggningsförsök begränsas, sessioner avslutas rent och admin-åtkomst begränsas till definierade nätverk. En inloggningsdisclaimer kan i vissa miljöer vara juridiskt meningsfull, men är ingen ersättning för verkliga tekniska kontroller. Viktigare är starka lösenordspolicyer, korta inaktiva sessioner, brute-force-skydd och minst privilegium.

Undvik patch-trötthet: Hotfixar måste verka snabbt

Patching är ett av de ämnen där teori och praktik skiljer sig mycket åt. Naturligtvis vet varje administratör att firmware-uppdateringar är viktiga. I verkligheten innebär de dock underhållsfönster, riskbedömning, HA-planering, kommunikation med fackavdelningar och ibland även driftstopp. Detta leder till patch-trötthet: Uppdateringar skjuts upp eftersom de är tidskrävande.

Just här är tidskomponenten farlig. Identitetsattacker är nu den dominerande grundorsaken, men sårbarhetsutnyttjande förblir en verklig vektor, särskilt för edge-system som brandväggar, VPN:er och andra internetnära tjänster. Sophos Active Adversary Report 2026 nämner som exempel CVE-2024-40766 i SonicOS, som var synlig i en stor del av de bekräftade exploit-fallen i datamängden. Samtidigt låg den mediana tiden mellan tillverkarens rådgivning respektive patch och observerad utnyttjande på 322 dagar. Det är en ganska tydlig signal: Patch-trötthet är inget abstrakt driftsproblem, utan ett angreppsfönster.

Sophos Firewall tar här ett viktigt steg: Automated Hotfixes möjliggör säkerhetsrelevanta live-patchar utan klassiskt underhållsfönster. För administratörer är detta enormt värdefullt eftersom den kritiska skyddseffekten inte inträffar först när nästa lediga underhållsfönster kommer.

Trots detta gäller: Hotfixar ersätter ingen ren uppdateringsstrategi. Hotfixar stänger den farliga luckan mellan upptäckt sårbarhet och regelbunden firmware-uppgradering. Bästa praxis är därför:

• Låt hotfixar vara aktiverade.
• Kontrollera firmwareversioner regelbundet och dokumentera förberedelser för firmware-uppdatering.
• Läs uppgraderingsvägar och kompatibilitet i förväg.
• Förbered säkerhetskopior och rollback-plan.
• Planera HA-kluster och fjärrplatser separat.

Behandla inte VPN som ett förtroendebevis

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

Zero Trust Network Access (ZTNA) löser detta problem inte genom magi, utan genom en bättre princip: Trust nothing, verify everything. Åtkomst beviljas inte generellt till ett nätverk, utan bedöms per användare, enhet, tillstånd och applikation. En enhet måste vara frisk och kompatibel, identiteten måste verifieras och policyn avgör granulerat vilken applikation som är tillgänglig.

ZTNA är inget automatiskt Sophos-beslut

Viktigt är: ZTNA är inget beslut som automatiskt måste tala för Sophos ZTNA. Beroende på miljö kan specialiserade ZTNA-, SSE- eller SASE-leverantörer vara funktionellt längre fram, erbjuda bättre integrationer eller passa organisatoriskt bättre. Avgörande är inte tillverkarens namn, utan om identitet, enhetstillstånd, applikationsåtkomst, loggning och drift spelar rent ihop.

Det är också min grundläggande inställning i Sophos-projekt: Jag satsar inte automatiskt på Sophos i varje ämne. Om en tredjepartslösning vid ZTNA, SSE, Threat Intelligence, SIEM eller NDR passar bättre är det just den bättre rekommendationen. En bra säkerhetsarkitektur uppstår inte genom maximal tillverkarbindning, 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-kompatibel enhet kan förlora åtkomst utan att en administratör först manuellt måste bygga om brandväggsregler. Det är också värt att titta på ZTNA Gateway på Sophos Firewall. I blandade eller större miljöer bör man dock medvetet jämföra och inte automatiskt sätta den befintliga brandväggstillverkaren som ZTNA-plattform.

Den som idag fortfarande starkt förlitar sig på SSL VPN eller IPsec Remote Access bör åtminstone kontrollera dessa punkter:

• Tvinga MFA för varje fjärråtkomst.
• Ta bort gamla eller oanvända VPN-användare.
• Kontrollera gruppimport från AD eller Entra ID, så att fjärråtkomst inte oavsiktligt aktiveras.
• Minska split-tunnel, tillåtna nätverk och behörigheter till ett minimum.
• Planera stegvis migration 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 rörelse

Om angripare kommer in med giltiga inloggningsuppgifter 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 en perimeter-gateway, utan bör rent separera interna zoner: Användare, servrar, hantering, IoT, gästnät, produktion, backup och särskilt kritiska system hör inte blint till samma förtroendemodell.

Praktiskt betyder det: Bygg VLAN och zoner inte bara av ordningskärlek, utan säkra dem med verkliga brandväggsregler. Mellan användar- och servernät bör endast de nödvändiga applikationerna tillåtas. Hanteringsåtkomst hör hemma i dedikerade admin-nät. IoT- och skrivarnät bör inte fritt kunna kommunicera med servrar. Backuper och domänkontrollanter förtjänar särskilt restriktiva regler och bra loggning.

Just här sluts cirkeln till uttalandet “Angripare loggar in”. Om ett komprometterat konto visserligen får åtkomst till en applikation, men inte till hela nätverket, blir en incident inte automatiskt en fullständig kompromettering.

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

Gör felkonfigurationer synliga

En brandvägg kan tekniskt sett vara mycket kraftfull och ändå bli farlig genom felaktig konfiguration. För breda regler, “Any”-objekt, svag autentisering, saknade IPS-policies, inaktiverade mönsteruppdateringar eller öppna portaler är typiska exempel. Det svåra med detta: I växande miljöer ser man inte alltid sådana risker omedelbart.

Sophos Firewall Health Check adresserar just detta problem. Den kontrollerar dussintals inställningar mot bästa praxis och benchmarks och visar i kontrollcentret var konfigurationer är riskabla eller avviker från rekommenderade standarder. Resultaten prioriteras efter risk, leder med ett klick till de berörda inställningarna och kan beroende på situation åtgärdas eller medvetet åsidosättas.

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

• efter en ny brandväggsutrullning,
• efter större regeländringar,
• före och efter firmware-uppgraderingar,
• före revisioner,
• efter migrationer från gammal hårdvara,
• som regelbunden kvartalskontroll.

Viktigt är dock också: En Health Check tar inte bort tänkandet från administratörer. Inte varje rekommendation passar varje miljö. Vissa punkter har compliance- eller driftsorsaker, andra är klara säkerhetsluckor. Avgörande är att medvetet bedöma avvikelser och inte låta dem växa obemärkt.

Enligt min mening är Health Check framför allt stark som ett löpande driftsverktyg. Det är inte bara något för den första go-live, utan en bra startpunkt för kvartalsgranskningar, revisionsförberedelser och rensning av gamla regelverk.

Secure by Design: Härda brandväggen själv

Enligt min mening 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 på andra system, utan måste själv vara härdad mot attacker.

På Sophos Firewall ingår flera nivåer:

• Härdad kärna och moderniserad arkitektur: Den nyare Xstream-arkitekturen satsar mer på isolering, modularisering, containerisering och privilegieseparation. Därigenom reduceras vissa sårbarhetsklasser och effekter begränsas genom bättre isolering. Dessutom finns mitigeringar mot sidokanals- och CPU-sårbarheter. 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-sensorn kan övervaka systemintegritet i realtid, till exempel otillåtna konfigurationsändringar, regelutdrag, misstänkt programkörning eller filmanipulering. Detta är dock endast värdefullt om funktionen är aktiverad, licensierad, ansluten och övervakad i drift.
• Säker central hantering: Administration kan ske via Sophos Central utan att hanteringsportar öppnas brett mot internet.
• Health Check: Riskabla konfigurationer blir direkt synliga.
• Krypterade säkerhetskopior: Konfigurationsdata överförs och lagras skyddat.

Dessutom satsar Sophos på proaktiv övervakning av den installerade brandväggsbasen. Telemetri från brandväggar kan hjälpa till att upptäcka tecken på attacker eller manipulationer tidigare. Om ett mönster blir synligt kan Sophos stödja kunder eller partners riktat och snabbt rulla ut hotfixar brett.

Dessa punkter är i vardagen mindre spektakulära än en ny brandväggsregel eller en blockerad attack i loggen. På lång sikt är de dock avgörande. En härdad produkt minskar sannolikheten för att brandväggen själv blir en inträdespunkt. Det ersätter dock ingen ren patch-process, ingen övervakning och ingen regelbunden konfigurationskontroll.

Vad man bör tänka på hos brandväggstillverkaren

Secure by Design är inte bara en produktegenskap, utan också en tillverkarfråga. Kunder bör förvänta sig av tillverkare att de hanterar sårbarheter transparent, kommunicerar livscykelinformation tydligt, snabbt rullar ut säkerhetsfixar och bygger sina produkter så att felkonfigurationer och komprometterade komponenter upptäcks så tidigt som möjligt.

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

Pelare 2: Skydd under attacken

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

Sophos satsar starkt på Xstream-arkitekturen för detta. Betrodd trafik kan bearbetas mer effektivt, beräkningsintensiva uppgifter som kryptografiska operationer körs över optimerade vägar, och för trafik med högre risk finns mer prestandareserv för djup paketinspektion, TLS-inspektion och zero-day-skydd.

Just TLS-inspektion ä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 skapar man dock supportfall, certifikatproblem eller prestandaflaskhalsar. Bästa praxis är därför inte “dekryptera allt blint”, utan klassificera rent:

• kritiska användargrupper och servrar först,
• bank, hälsa, integritet och kända problematiska kategorier undantas rent,
• testa block- och varningssidor,
• dokumentera certifikatdistribution,
• utvärdera loggar aktivt.

Min rekommendation är att inte starta TLS-inspektion som ett allt-eller-inget-projekt. Bättre är en ren utrullning med klara användargrupper, undantag, testfönster och loggutvärdering. Så ökar synligheten utan att helpdesken överbelastas första dagen.

Även Threat Feeds hör hemma i detta skyddsområde. Sådana feeds hjälper till att blockera kända skadliga IP:er, domäner eller URL:er direkt vid nätverksgränsen. I nyare Sophos Firewall-versioner är de betydligt starkare integrerade i Active Threat Response och skyddsmekanismer.

Särskilt intressanta blir Threat Feeds när inte bara generiska listor används, utan kuraterade tredjepartsfeeds med aktuell kontext. Ett exempel på detta är Cybora.io, där skadliga IP:er och domäner från olika källor och brandväggstelemetri 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 övervakas. För aggressiva feeds, saknade tillåtlistprocesser eller oklara ansvarsområden kan blockera legitim trafik och orsaka mer skada än nytta i driften. Bra feeds är ingen ersättning för en regelgranskning, utan en ytterligare byggsten med egen tuning.

Dessutom bör man inte glömma de klassiska SFOS-härdningarna: Spoof Protection och lämpliga DoS-inställningar samt Geo-IP-blockering kan minska enkla, högljudda eller uppenbart oönskade åtkomster. Det ersätter ingen ren policy, men det tar bort onödigt brus från brandväggen och blockerar angreppsvägar som i många miljöer inte har något legitimt syfte.

Jag rekommenderar här att gå pragmatiskt tillväga: först kontrollera de stora riskerna rent, sedan skärpa skyddsfunktionerna stegvis och med loggar bevisa vad som verkligen fungerar. En överbelastad policy som ingen längre förstår är på lång sikt ingen säkerhetsvinst.

Pelare 3: Upptäckt och respons efter första signalen

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

Ekosystem hjälper bara om de passar

Synchronized Security och Security Heartbeat är bra idéer: Brandväggen kan ta hänsyn till tillståndet hos endpoints och begränsa eller blockera kommunikation vid 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 endast begränsat eller inte alls. Just därför bör man inte automatiskt ta allt från samma tillverkare bara för att det erbjuds som ett integrerat ekosystem.

Min rekommendation är hä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 denna arkitektur. Viktigare än korsförsäljning är att loggar landar på rätt ställe, larm förstås och någon regelbundet kontrollerar vad systemen rapporterar. Utan logganalys, tuning och incident-process hjälper inte ens den bästa integrationen mycket.

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 dock riktlinjer. Det bör vara klart vilka signaler som får blockera automatiskt, vem som häver en isolering, hur falska positiva hanteras och hur sådana processer testas. Utan runbooks, ansvarsområden och regelbundna övningar vet annars ingen i allvarliga fall om en blockering var avsiktlig, korrekt eller för aggressiv.

Vad händer i allvarliga fall? En komprometterad enhet kan isoleras, C2-kommunikation avbryts, exfiltration kan blockeras och en MDR- eller XDR-analytiker kan utlösa en Active Threat Response utan att först manuellt bygga en regel i brandväggen. Detta är särskilt värdefullt när en attack upptäcks utanför normala driftstider.

För administratörer är det framför allt en sak som är viktig: Reaktionen måste vara tillräckligt snabb. Om en MDR- eller XDR-analytiker först måste ringa, skriva ett ärende och en lokal administratör sedan manuellt måste bygga en regel på fredagskvällen är reaktionstiden för lång. Automatiserad reaktion betyder inte att människor ersätts. Det betyder att den första inneslutningen sker omedelbart och att teamet sedan kan undersöka rent.

Särskilt i mindre IT-team är denna automatisering värdefull. Inte varje företag har en brandväggsspecialist tillgänglig dygnet runt. Om Endpoint, Firewall, NDR, MDR och SIEM spelar rent ihop över tillverkare vinner man tid, och tid är ofta den viktigaste faktorn vid aktiva attacker.

Praktisk checklista för Sophos Firewall-administratörer

Den som vill stärka sin Sophos Firewall idag kan börja med denna lista:

Kontrollera omedelbart

• Är hotfixar aktiverade?
• Är MFA för administratörer aktiv?
• Är Web Admin Console och User Portal tillgängliga från WAN?
• Är SSL VPN eller IPsec Remote Access skyddade med MFA?
• Finns det fortfarande oanvända lokala admin-konton?
• Är säkerhetskopior planerade, krypterade och testade?
• Är Device Access och Local Service ACL reducerade till ett minimum?
• Är WAN-tillgängliga tjänster åtminstone begränsade till relevanta länder eller kända källnät?
• Är mönsteruppdateringar och firmwareversioner aktuella?

Inom de närmaste veckorna

• Utför Health Check och prioritera fynd.
• Kontrollera gamla brandväggsregler med “Any” vid källa, mål eller tjänst.
• Kontrollera admin-roller, inloggningssäkerhet, 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 rörelse.
• Jämför ZTNA-, SSE- eller SASE-alternativ för typiska fjärråtkomstapplikationer.
• Kontrollera Threat Feeds och DNS Protection.
• Aktivera Spoof Protection, DoS-skydd och Geo-IP-blockering efter risk.
• Testa TLS-inspektion strukturerat och rulla ut stegvis.

Strategiskt planera

• Ersätt End-of-Life-system.
• Samordna drift av brandvägg, VPN, DNS, SD-WAN och ZTNA/SSE på ett meningsfullt sätt.
• Standardisera central hantering, rapportering och larm, till exempel via Sophos Central, SIEM eller befintliga säkerhetsplattformar.
• Definiera Syslog-/SIEM-export och loggretention för forensiska utvärderingar.
• Integrera MDR/XDR/NDR-signaler i incident-processen.
• Inför återkommande brandväggshärdningsgranskningar.

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, kontrolleras och integreras i upptäckten.

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

Eller rent praktiskt sagt: Om en brandvägg är så gammal att den snarare hör hemma på ett museum än i ett rack, är det inte bara en driftsrisk. Det är en angreppsyta. Och just denna angreppsyta håller jag så liten som möjligt.

Stöd från Avanet

Om stöd behövs vid härdning av en Sophos Firewall kan man gärna kontakta Avanet. Jag stödjer som långvarig Sophos-specialist vid brandväggsrevisioner, Health Check-granskningar, regelverksrensning, fjärråtkomst och ZTNA/SSE-planering, uppdateringsstrategier och utbildningar för IT-team.

Särskilt en extern blick på hanteringsåtkomster, VPN-konfiguration, gamla regler, WAN-exponerade tjänster och uppdateringsstatus lönar sig ofta. Många risker uppstår inte genom en enskild felaktig inställning, utan genom växande undantag som ingen längre ifrågasätter i vardagen.

Vid intresse räcker det med ett kort meddelande via kontaktformuläret. Därefter kan man tillsammans klargöra om en kompakt brandväggsgranskning, en revision eller en utbildning för den aktuella miljön är mest meningsfull.

FAQ

Vidare läsning

• 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 bästa praxis

Källor

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