Sophos Firewall v23: översikt och nya funktioner

Sophos Firewall v23 tar itu med flera uppgifter som tar tid i det dagliga brandväggsarbetet: att söka bland regler, identifiera användare korrekt, planera uppdateringar och ta reda på varför ett kluster har växlat över. Den nya huvudversionen innehåller därför ett REST API, en AI-assistent samt förbättringar av WAF, DNS och DHCP.

Om versionsläget: Precis som tidigare år inleds nästa huvudversion med en Early Access-fas för Sophos Firewall v23 kring oktober, i år redan den 28 september 2026. Artikeln bygger på EAP1. Enskilda funktioner och detaljer kan fortfarande ändras innan den slutliga versionen kommer.

En del nyheter finns direkt på brandväggen; andra funktioner kräver Sophos Fusion eller ytterligare programvara. Särskilt viktigt i planeringen är att den nya användaridentifieringen via Synchronized Security kräver Sophos Endpoint på berörda enheter och en lämplig Endpoint-licens. Den som hittills bara använder Microsoft Defender eller ett annat endpointskydd får alltså inte funktionen enbart genom att uppdatera brandväggen, utan måste även införa och licensiera Sophos Endpoint. Om Sophos-licenser redan finns beror den extra insatsen på det befintliga avtalet. Förutsättningarna för de övriga funktionerna beskrivs i respektive avsnitt.

AI och automatisering

REST API: automatisera brandväggens konfiguration

Med det nya REST API:et kan skript och administrationsverktyg läsa och ändra konfigurationen direkt på brandväggen. Inloggningen sker med API-nycklar. En beskrivning i OpenAPI 3.0-format dokumenterar tillgängliga anrop och datafält, så att gränssnittet lättare kan integreras i befintliga verktyg. Åtkomsten går direkt till brandväggen och är oberoende av Sophos Central API för export och import av konfigurationer.

Att distribuera gemensamma inställningar till flera brandväggar var redan en grundidé i Sophos Central Firewall Management. Brandväggsgrupper och överordnade policyer ska göra det möjligt att hantera sådana ändringar centralt. I vår erfarenhet fungerar det dock bara delvis så tillförlitligt som vi behöver för driften. Vid återkommande ändringar litar vi därför hellre på egna skript och processer där vi själva kan kontrollera förlopp och resultat. Just där är det nya REST API:et ett värdefullt komplement.

Ett exempel är nätverksobjekt för en ny server som behövs på brandväggarna på flera platser. Ett skript kan först kontrollera om objektet redan finns, göra endast den nödvändiga ändringen och sedan läsa tillbaka det sparade värdet. Loggen visar vilken brandvägg som har uppdaterats och var ytterligare arbete krävs. Det är särskilt användbart om en plats inte är nåbar under ändringen och kan uppdateras senare.

API-nycklar hanteras under Administration > API access. De ärver behörigheterna från den tillhörande administratören. För automatisering bör man därför använda ett separat konto med en lämplig behörighetsprofil. Även tillåtna källadresser och administrationsåtkomst måste vara rätt inställda. Åtkomsten bör begränsas till de system som faktiskt behöver den för sina administrationsuppgifter.

Allowed IP hosts: även i v23 går det bara att tillåta IP-adresser eller nätverk här. Ett FQDN, alltså ett fullständigt DNS-namn, kan fortfarande inte anges. För en automationsserver med en fast utgående IP-adress är det inget problem. Körs skriptet däremot bakom en anslutning vars publika IP-adress ändras kan DNS-namnet inte enkelt läggas till som tillåten källa. Då behövs exempelvis en fast utgångspunkt eller kontrollerad VPN-åtkomst. För ett gränssnitt som ska underlätta automatisering hade vi önskat större flexibilitet.

REST API guide öppnas i WebAdmin under Administration > API access. Länken finns till höger ovanför listan med API-nycklar, direkt bredvid OpenAPI.yaml. Den publika Sophos Firewall API Reference beskriver slutpunkter, datafält och grunderna för autentisering. För den konkreta implementationen är OpenAPI-filen från den installerade brandväggsversionen avgörande. Innan befintlig XML-automatisering ersätts bör man kontrollera om alla funktioner som behövs täcks. Felhantering, loggning och en testad återställningsväg behövs även med ett modernt API.

AI-assistent för brandväggsregler

Den nya assistenten i Sophos Fusion svarar på frågor om brandväggsregler. Den skapar inaktiverade regelutkast längst ned i tabellen; administratören måste fortfarande godkänna dem.

Det är ett rimligt sätt att samarbeta med AI. En begäran som ”Skapa ett utkast för HTTPS-åtkomst från medarbetarnätet till den interna webbservern” kan förbereda arbetet. Innan regeln aktiveras måste det ändå vara tydligt exakt vilka objekt som avses, om användarna ska begränsas och vilka säkerhetskontroller som behövs.

Regelns position är särskilt viktig. Ett sakligt korrekt tillstånd kan bli verkningslöst om en annan regel redan matchar trafiken. Omvänt kan en regel som placeras för högt tillåta mer trafik än tänkt. Assistenten tar därför inte säkerhetsbeslutet åt administratören. Värdet ligger i att förbereda arbetet med regelverket och göra samband lättare att hitta.

Tillåt eller blockera AI-tjänster på ett målinriktat sätt

Webbkategorin Generative AI och applikationsfilter inom Sophos AI Defense tillkommer för kontroll av AI-användning.

Under Diagnostics > URL category lookup kan man slå upp hur en domän klassificeras. För openai.com visar brandväggen kategorin Generative AI. Det hjälper vid felsökning: om en AI-tjänst oväntat blockeras kan man först kontrollera dess kategori och sedan den webbpolicy som tillämpas.

För företag börjar en genomtänkt konfiguration med ett enkelt beslut: vilka AI-tjänster är tillåtna för vilket arbete? En utvecklingsavdelning kan behöva andra verktyg än ekonomiavdelningen. Först därefter går det att utforma en användbar nätverkspolicy.

En tillåten domän säger dock inget om vilken information som får matas in där. Åtkomstkontroll och dataskydd är två olika uppgifter. Även för en godkänd tjänst behövs regler för kunduppgifter, källkod och konfidentiella dokument. Nätverksfilter kan stödja dessa organisatoriska regler, men ersätter inte en innehållslig granskning av varje prompt.

Regelhantering och användargränssnitt

Ny tabell för brandväggsregler

Vyn under Rules and policies > Firewall rules har gjorts om i grunden. I stället för mappar som fälls ut visas reglerna nu i en sammanhängande tabell. Grupperingen finns kvar men visas i kolumnen Group. Dessutom finns fritextsökning, filter och ett anpassningsbart urval av kolumner.

Det löser ett irritationsmoment i det tidigare gränssnittet: när en brandväggsregel hade redigerats och sparats fälldes gruppen ihop igen. Den som direkt ville redigera nästa regel i samma grupp fick öppna mappen på nytt. Vid flera ändringar i följd var det onödigt omständligt. När grupptillhörigheten visas i en kolumn slipper man fälla ut den om och om igen.

Välj och ordna kolumner

Via kugghjulet uppe till höger om tabellen väljer man vilka kolumner som ska visas. Uppgifter som inte behövs kan döljas, ytterligare detaljer kan visas och kolumnernas ordning kan ändras. Det går också att fästa kolumner. Då kan exempelvis regelnamnet vara synligt när man rör sig genom en bred tabell.

Särskilt glädjande är att den valda vyn i vårt test sparades även efter utloggning och ny inloggning. Den behöver alltså inte ställas in på nytt vid varje inloggning.

För en snabb överblick räcker ofta namn, grupp, åtgärd, status och trafik. Vid felsökning är däremot käll- och målnät, tjänster och loggning intressanta. Om åtkomsten till en gammal applikationsserver exempelvis ska tas bort vill man se målen i de berörda reglerna sida vid sida. Att slippa öppna varje regel separat sparar tid och gör jämförelsen enklare.

Följande kolumner kan väljas. Namnen motsvarar det engelska gränssnittet; för överskådlighetens skull grupperas de här efter ämne:

• Regel och översikt: Name, Type, Group, ID, Features, Traffic (In/Out), Status, Action, Schedule, Description.
• Nätverk och tjänster: Src networks, Src zones, Dst zones, Dst networks, Services.
• Användare och loggning: Users, Exclude users from accounting, Web authentication for unknown users, Log.
• Skyddsfunktioner och policyer: Email, Web policy, IPS policy, Application policy.
• Bandbredd och prioritering: Traffic shaping policy, Traffic shaping (applications), Traffic shaping (web category), DSCP marking.
• Security Heartbeat: Source HB, Block client with no source HB, Destination HB, Block client with no destination HB.
• Undantag: Excluded source address, Excluded destination address, Excluded source zone, Excluded destination zone, Excluded service.

Den gamla vyn finns kvar tills vidare

Med reglaget New design kan man fortfarande återgå till den tidigare vyn. Den som inte kommer överens med den nya tabellen har därmed ett alternativ tills vidare. Hur länge Sophos kommer att erbjuda båda vyerna parallellt är oklart.

NAT-regler: fortfarande ingen gruppering eller kloning

Tyvärr har Sophos inte överfört den nya vyn till NAT-reglerna. De hanteras annorlunda även i v23: NAT-regler går varken att gruppera eller klona. Brandväggsregler kan klonas, men för NAT-regler saknas funktionen fortfarande.

Just när flera liknande tjänster ska publiceras vore detta användbart. Om en annan webbserver behöver nästan samma vidarebefordran vill man kopiera en befintlig NAT-regel och sedan ändra mål och tjänst. I stället måste regeln skapas på nytt. Det tar tid och ökar risken att någon av de andra inställningarna avviker.

Vi tog redan upp dessa önskemål i artikeln om Sophos Firewall v22. Den nya vyn för brandväggsregler är ett välkommet framsteg. Därför är det desto mer beklagligt att NAT-hanteringen fortfarande saknar sådana grundläggande funktioner.

WebAdmin, serienummer och klusterstatus

WebAdmin-gränssnittet använder HTTP/2 för att påskynda överföringen av sidelement. Serienumret och HA-klustrets status förblir också synliga när man växlar mellan inställningssidorna.

HTTP/2 kan hjälpa när många sidelement ska laddas, särskilt över anslutningar med högre latens. Om en viss vy upplevs som snabbare beror dock också på bearbetningen i brandväggen. En långsam databasfråga eller lagring av en komplex konfiguration blir inte snabb enbart genom ett annat transportprotokoll. I mitt första test var hastighetsvinsten liten: det tog fortfarande flera sekunder att spara en brandväggsregel.

En synlig enhetsidentitet har en omedelbar fördel: med flera öppna brandväggssessioner blir det lättare att kontrollera vilket system man arbetar på. Innan man ändrar ett HA-kluster är det också klokt att se vilken roll och status de berörda enheterna har.

Den som arbetar med support för flera nästan identiska kundmiljöer känner igen tvekan precis innan en ändring sparas. Ett serienummer som alltid syns gör det enklare att jämföra med ärendet utan att lämna den aktuella inställningssidan. Det är en liten ändring med mycket konkret nytta.

Hög tillgänglighet: upptäck snabbare, växla över mer träffsäkert

Hårdvarustatus som utlösare

HA-klustret övervakar nu inte bara anslutningar och tjänster utan även status för vissa hårdvarukomponenter, bland annat SSD:n. Om dess status försämras kan klustret växla över till den andra brandväggen.

Ett HA-kluster kan bara reagera på ett fel om det också upptäcker det. En enhet kan fortfarande nås via sina nätverksgränssnitt trots att den redan har interna problem. Därför är det utökade hårdvaruperspektivet relevant för driften.

En felaktig SSD kan exempelvis påverka skrivningar medan HA-länken fortfarande fungerar. Ren anslutningsövervakning skulle inte upptäcka diskens tillstånd. Den utökade hårdvaruövervakningen kan ingripa innan den skadade noden slutar fungera helt.

Efter en sådan överväxling måste orsaken ändå utredas. Den andra noden upprätthåller tjänsten men reparerar inte en trasig SSD. Driftsrutinen bör därför omfatta kontroll av den berörda enheten, bedömning av den återstående redundansen och vid behov byte av hårdvara.

Kortare detektionstid

Med den snabbare övervakningen upptäcker HA-klustret att den andra brandväggen faller bort inom 300 ms i stället för tidigare fyra sekunder.

De 300 ms avser tiden tills brandväggen upptäcker att den andra enheten i klustret har fallit bort. Innan en applikation fungerar normalt igen kan fler steg behövas: den kvarvarande brandväggen måste ta över driften, angränsande nätverksutrustning måste styra trafiken rätt och befintliga anslutningar måste fortsätta eller etableras på nytt.

För ett meningsfullt test bör man därför följa mer än bara en ping. Ett pågående telefonsamtal, en filöverföring och VPN-åtkomst kan påverkas på olika sätt. Först sådana mätningar visar om överväxlingen är tillräckligt snabb för de egna verksamhetsprocesserna.

Färre felaktiga överväxlingar vid hög belastning

De två brandväggarna utbyter regelbundet korta statusmeddelanden, så kallade HA-Heartbeats. Dessa meddelanden behandlas nu med förtur och separat från den vanliga datatrafiken.

Det adresserar ett problem vid hög belastning: när ett system arbetar hårt kan ett sent svar se ut som ett avbrott. En överväxling som då utlöses skapar ytterligare störningar i en redan pressad miljö.

Vid acceptanstestning är därför två situationer intressanta: upptäcker klustret ett verkligt avbrott, och förblir det stabilt vid hög belastning utan ett faktiskt enhetsfel? Ett rent funktionstest i vila besvarar bara den första delen av frågan.

DNS-säkerhet, hotfixes och firmware

DNS over HTTPS och DNSSEC

Brandväggen kan nu skicka DNS-förfrågningar krypterat via HTTPS till en resolver och kontrollera DNS-svar med DNSSEC. Det har också blivit enklare att aktivera Sophos DNS Protection.

De båda DNS-teknikerna löser olika problem. DNS over HTTPS, DoH, krypterar överföringen till resolvern. DNSSEC används för att verifiera signerade DNS-data. En krypterad anslutning bekräftar inte i sig att ett DNS-svar är äkta, och en giltig signatur döljer inte förfrågan för dem som kan observera transportvägen.

Innan funktionerna införs bör man förstå den befintliga DNS-vägen. Frågar klienten brandväggen, en intern Windows-DNS-server eller en publik resolver direkt? Interna namnrymder måste fortfarande lösas upp på rätt plats. Till exempel förblir DNS Request Routes relevanta för detta.

Även webbläsare med egna DoH-inställningar behöver uppmärksamhet. Om en klient använder en annan resolver kan dess faktiska DNS-väg avvika från den centralt avsedda konfigurationen. Ett funktionstest bör därför omfatta interna namn, extern namnuppslagning och önskade filtreringsbeslut.

Synliga hotfixes och säkerhetsuppdateringar

När vi gick igenom gränssnittet lade vi märke till ytterligare en ändring: under Backup & firmware finns åter ett eget område för hotfixes. Fliken heter Hotfix: Security updates. Tidigare fanns hotfixinställningen under Firmware. Där kunde man med en kryssruta välja om viktiga hotfixes skulle installeras automatiskt. Efter att inställningen försvann från gränssnittet har hotfixes nu fått en synlig plats igen.

Den nya vyn visar status för säkerhetsuppdateringarna. Det tidigare reglaget för att slå på eller av funktionen syns inte på skärmbilden. Att inställningen under en tid saknades betyder inte heller att brandväggen slutade få hotfixes: automatisk installation finns fortfarande som funktion.

Vad hotfixes används till

Hotfixes är riktade rättningar av akuta problem, i synnerhet säkerhetsbrister. De kan distribueras utanför de vanliga firmwareutgåvorna. En viktig rättning behöver därmed inte vänta på nästa Maintenance Release och en fullständig firmwareuppdatering som måste planeras i organisationen.

Om en sårbarhet i en administrationstjänst blir känd kan en lämplig hotfix exempelvis rätta till den berörda komponenten. Automatisk installation förkortar tiden mellan att rättningen blir tillgänglig och att den tillämpas på brandväggen. Den är aktiverad som standard och bör förbli påslagen vid normal drift. Hotfixes ersätter dock inte vanliga firmwareuppdateringar: de senare innehåller även andra felrättningar, ändringar i komponenter och nya funktioner.

Kontrollera patchnivån direkt

Gränssnittet visar nu vilka säkerhetsbrister som har åtgärdats av installerade hotfixes. Varje post innehåller CVE-beteckning, allvarlighetsgrad, installationsdatum och en länk till tillhörande säkerhetsmeddelande. Uppgifterna finns också i rapporteringen.

Det hjälper till att besvara en vanlig driftfråga: är en specifik sårbarhet redan åtgärdad på just den här brandväggen? Ett firmwareversionsnummer ger inte alltid hela svaret när hotfixes distribueras separat.

Om en kund frågar om ett nytt säkerhetsmeddelande kan den lokala statusen då dokumenteras mer exakt. I stället för att utgå enbart från firmwareversionen kan man kontrollera den aktuella CVE:n och hotfixens installationsdatum och notera det i ärendet.

För dokumentationen bör den visade patchnivån bedömas tillsammans med det tillhörande säkerhetsmeddelandet. En installerad rättning besvarar frågan om just den åtgärden. Den bevisar varken att hela systemet är säkert konfigurerat eller att en tidigare attack kan uteslutas. Konfigurationskontroll, logganalys och vid behov en utredning behövs fortfarande.

Återkommande firmwareuppdateringar

I Sophos Fusion kan återkommande underhållsfönster anges då brandväggarna installerar nya firmwareversioner automatiskt. Alla enheter behöver inte uppdateras samtidigt. Man kan börja med utvalda brandväggar och låta de andra följa senare. Enskilda enheter kan ha avvikande inställningar, exempelvis om en plats behöver ett eget underhållsfönster.

Det är särskilt användbart för organisationer med flera kontor. Till exempel kan brandväggen på ett litet kontor få uppdateringen först. Därefter kontrolleras VPN-anslutningar, användarinloggningar och publicerade tjänster där. Först när dessa kontroller har lyckats uppdateras övriga platser. Då behöver inte varje installation startas separat, samtidigt som ordningen förblir under kontroll.

Det måste vara bestämt i förväg vem som kontrollerar resultaten och stoppar följande uppdateringar vid problem. Automatisk installation ersätter varken säkerhetskopiering eller en förberedd återställningsväg. De nödvändiga stegen beskrivs i våra guider om firmwareuppdateringar och säkerhetskopiering och återställning.

Identitet och inloggning

Entra ID med Synchronized User ID

Via Synchronized Security kan brandväggen nu också identifiera användare som arbetar med Entra ID. Enheter anslutna till lokalt AD och enheter med molnidentitet kan därmed användas sida vid sida. Identifieringen kräver Sophos Endpoint på berörda enheter och en lämplig Endpoint-licens.

Den praktiska frågan är: hur vet brandväggen vilken användare som finns bakom en anslutning? Enbart en IP-adress räcker inte alltid för en meningsfull användarbaserad regel. Vid övergången från en lokal domän till en molnidentitet måste den kopplingen fortsätta fungera tillförlitligt.

Ett typiskt fall är ett företag som bara ansluter nya bärbara datorer till Entra ID medan äldre enheter fortfarande hör till den lokala AD-domänen. För ekonomiavdelningens webbpolicy bör denna tekniska övergång inte göra någon skillnad: det avgörande är användargruppen. Just denna kontinuitet är viktig vid en stegvis molnmigrering.

Vid planeringen måste funktionen skiljas från den redan kända Entra ID-inloggningen på Captive Portal. Här handlar det om samspelet med Sophos Endpoint. Att det finns en Entra ID-miljö innebär därför inte i sig att brandväggen kan identifiera användarna på rätt sätt. I ett pilottest bör man kontrollera vilken användare som faktiskt visas och vilken gruppregel som sedan tillämpas.

Google Workspace som Identity Provider

Användare kan logga in med sitt Google Workspace-konto på Captive Portal, VPN Portal, Sophos Connect och WebAdmin. Google Workspace fungerar då som Identity Provider och kan även kräva multifaktorautentisering vid inloggning.

För organisationer som använder Google som centralt användarkatalogsystem är det ett viktigt tillskott. Konton och inloggningsregler bör om möjligt hanteras på samma ställe som organisationens övriga åtkomster.

En skola med Google Workspace behöver exempelvis inte underhålla en separat lösenordsdatabas på brandväggen för lärarnas VPN-åtkomst. Det minskar dubbel administration och gör det lättare att skydda inloggningen via den centrala Identity Provider.

En lyckad inloggning är ändå bara en del av integrationen. Därefter måste rätt behörigheter tillämpas. En vanlig medarbetare får inte få administrationsåtkomst bara för att SSO-inloggningen fungerar. Därför hör användarattribut, grupptillhörighet, tillåtna tjänster och återkallande av åtkomsträttigheter ihop i testet.

MFA-registrering via e-post

För att konfigurera multifaktorautentisering kan brandväggen skicka den nödvändiga QR-koden via e-post. Om registreringen inte slutförs inom 24 timmar löper den oanvända koden ut. I befintliga installationer finns den tidigare registreringen via portalen kvar till att börja med.

Det ändrar registreringsprocessen för nya användare. Före utrullningen bör e-postadresser och leverans av e-post kontrolleras. Annars kan den första VPN-inloggningen bli ett supportärende trots att själva autentiseringen är korrekt konfigurerad.

En QR-kod för registrering innehåller säkerhetsrelevant information. Därför måste även den mottagande brevlådan vara skyddad. Supporten behöver dessutom en tydlig rutin för utgångna registreringar och felaktiga adresser. När ett nytt meddelande skickas får man inte hoppa över kontrollen av vem som begär det.

Chromebook-SSO

Ett nytt tillägg för Chromebooks kan överföra användarens inloggning till brandväggen utan att användaren behöver logga in på Captive Portal igen. Tillägget stöder alla SFOS-versioner som fortfarande stöds.

Särskilt i skolor är upprepade portalinloggningar störande. Avgörande är dock inte bara den första lyckade inloggningen, utan även när användare och enheter byts. Ett test med delade Chromebooks bör visa att en gammal användarkoppling inte ligger kvar efter ett användarbyte.

Eftersom tillägget är tänkt att fungera över flera versioner bör införandet planeras separat från uppgraderingen till v23. Om en ny klientkomponent och ny firmware för brandväggen rullas ut samtidigt blir det svårare att ringa in eventuella fel.

Terminalservrar: användarkoppling med XDR Sensor

För Sophos Authentication for Thin Client, SATC, kan en lättviktig XDR Sensor användas. Den hjälper brandväggen att koppla nätverkstrafik från en delad server till enskilda användare och kan användas parallellt med en befintlig endpointskyddslösning.

På en terminalserver delar många sessioner samma server-IP. Ett IP-baserat tillstånd skiljer därför inte mellan en användare på ekonomiavdelningen och en extern medarbetare på samma värd. Användarbaserade webb- eller brandväggsregler kräver ytterligare en koppling.

Möjligheten att använda en sensor vid sidan av ett befintligt skyddsprogram är intressant för blandade miljöer. Det är dock ingen generell kompatibilitetsgaranti för varje kombination. Licens, operativsystem och stödd samverkan bör kontrolleras i förväg. Vid funktionstestet bör minst två samtidigt inloggade användare få olika regler. Påverkan på själva terminalservern måste bedömas separat från brandväggens beslut.

WAF: större kontroll över publicerade applikationer

Olika åtgärder per URL-sökväg

Web Application Firewall får åtgärder per sökväg: Protect, Block, Redirect och Passthrough. Den sistnämnda används för WebSockets utan WAF-inspektion.

Med Protect fortsätter sökvägen att inspekteras av WAF. Block avvisar åtkomsten med HTTP 403. Redirect skickar webbläsaren till en annan adress. Passthrough är därmed ett medvetet valt undantag för den aktuella WebSocket-trafiken, inte ett extra skyddssteg.

Det gör att behandlingen kan anpassas bättre till applikationens uppbyggnad. Efter ett byte av portal kan exempelvis /altes-portal omdirigeras till /kundenportal, medan ett avvecklat område under /legacy blockeras med HTTP 403. Själva applikationsdelen fortsätter att inspekteras av WAF. Att hantera sådana beslut direkt vid den framförliggande åtkomstpunkten kan minska behovet av ändringar i backend.

Vid omdirigering måste målet vara exakt rätt. En felaktig sökväg kan störa inloggningsflöden eller sparade länkar; en ogenomtänkt omdirigering kan skapa loopar. För ett undantag utan WAF-inspektion måste det också vara klart vilket skydd som finns kvar i applikationen. Att anslutningen fungerar är inget bevis för en likvärdig säkerhetskontroll.

Fler sökvägar och regler

Varje sökvägspost kan innehålla upp till 128 sökvägar. Gränsen för WAF-regler är 100 som standard och kan höjas till 200.

Vid planering bör gränsen för antal regler och prestandan bedömas separat. Fler konfigurerbara regler betyder inte automatiskt att en appliance kan hantera hur många aktiva applikationer som helst med samma svarstid. TLS-hantering, inspektion, filuppladdningar och backendservrarnas hastighet påverkar också resursbehovet.

Ett meningsfullt acceptanstest använder därför typiska förfrågningar från de faktiska applikationerna. En statisk testsida representerar exempelvis en portal med stora filuppladdningar dåligt.

Ny hantering med Apache Event MPM

WAF går över till Apache Event MPM för att bättre hantera samtidiga förfrågningar.

Förenklat handlar det om att använda arbetskapaciteten bättre medan vissa anslutningar väntar på vidare behandling. Vid många samtidiga åtkomster är fördelningen avgörande: varje öppen anslutning ska inte blockera resurser i onödan som behövs för andra förfrågningar. Backendens kapacitet är fortfarande en separat gräns.

Det avgörande driftmåttet är beteendet under belastning. En applikation kan vara tekniskt nåbar men ändå svara så långsamt att användarna avbryter sitt arbete. Vid belastningstester bör därför inte bara lyckade anslutningar utan också svarstider och felfrekvens utvärderas.

För en användbar jämförelse före och efter ändringen måste hårdvara, säkerhetsprofil, backend och testtrafik vara desamma. Först då går det att bedöma vad den nya hanteringen innebär i den egna miljön. Arkitekturbytet i sig ger inget allmänt genomströmningsvärde.

DHCP, routning och nätverkstjänster

DHCP på nya Control Plane

DHCP-tjänsten körs nu på nya Control Plane och kan hantera större adressintervall och fler reservationer. Dessutom granskas DHCP-trafiken av brandväggen innan den når tjänsten för att begränsa effekten av ett stort antal förfrågningar. Inställningar som tidigare krävde kommandoraden finns nu i gränssnittet.

Det berör ett grundläggande beroende i nätverket. Om klienterna inte får någon adress verkar många andra tjänster också vara störda. Vid en uppgradering bör DHCP-servern därför kontrolleras lika medvetet som VPN och internetåtkomst.

Skalningen kan exempelvis bli relevant i en skola när många enheter nästan samtidigt ansluter till trådlösa nätet på morgonen och begär en adress. För användarna ser en trög adressutdelning snabbt ut som ett wifi-problem. Snabb behandling av leases hjälper på ett ställe som lätt förbises vid felsökning.

Testet bör omfatta nya leases, förnyelse av befintliga leases och reserverade adresser. Även överförda värden som gateway, DNS-servrar och individuella DHCP-alternativ måste stämma. Inställningar som sällan används märks ofta först när en särskild enhet startar om.

Även visningen av tilldelade adresser har omarbetats. DHCP-alternativ behandlas mer enhetligt enligt de bakomliggande standarderna. Därför bör befintliga specialkonfigurationer jämföras noggrant före och efter uppgraderingen.

Till inställningarna som har flyttats till gränssnittet hör negativa bekräftelser och en begränsning till en lease per klient. En negativ bekräftelse säger till klienten att den inte får använda en begärd adress och måste förhandla om sin adresskonfiguration. Sådana inställningar bör bedömas utifrån den egna nätverksdesignen, särskilt när flera DHCP-tjänster är inblandade.

mDNS-reflektor för Bonjour och enhetsidentifiering

Med mDNS-reflektorn kan enheter upptäcka tjänster även i andra utvalda nätverk. Det fungerar med både IPv4 och IPv6. För att sedan ansluta till den upptäckta enheten behövs fortfarande en lämplig brandväggsregel.

Det är exempelvis relevant när skrivare och medarbetare finns i olika VLAN. Skrivaren kan vara korrekt adresserad och i princip nåbar men ändå inte visas i den automatiska enhetssökningen. Upptäckt av en tjänst och den efterföljande dataanslutningen är två separata steg.

I konfigurationen bör bara de nätverkspar och tjänster som behövs tillåtas. Ett gästnät behöver inte kunna upptäcka alla enheter i den interna infrastrukturen. Efter konfigurationen bör man testa både önskat beteende och gränsen: den avsedda skrivaren hittas och kan användas, medan andra interna tjänster förblir otillgängliga.

Routingmotor och experimentellt BFD

Brandväggen använder en uppdaterad version av routingprogramvaran FRR. De olika routingprotokollen kan hanteras via en gemensam konsol. Experimentellt stöd för BFD tillkommer för BGP och statiska rutter på fristående brandväggar.

BFD står för Bidirectional Forwarding Detection och används för att snabbt upptäcka att en förbindelse mellan routinggrannar har fallit bort. Det är en annan uppgift än ett rollbyte i ett HA-kluster för brandväggar. Snabbare feldetektering kan hjälpa till att tidigare leda trafiken via en alternativ väg.

Mycket korta övervakningsintervall är dock inget självändamål. Om motparten eller transportvägen inte svarar tillförlitligt under belastning kan en aggressiv inställning orsaka onödiga statusändringar. Därför bör funktionens experimentella status tas på allvar och BFD först bedömas i en lämplig testmiljö.

Ett exempel är två routade platsförbindelser: det lokala gränssnittet kan vara aktivt trots att grannen inte längre kan nås via den föredragna vägen. Länkstatus räcker då inte för att upptäcka felet. En lämplig BFD-anslutning kan i en sådan arkitektur hjälpa till att konstatera bortfallet tidigare.

IPv6 IPoE och 4in6

Brandväggen stöder ytterligare anslutningsvarianter med IPv6 IPoE och 4in6-tunnlar. Dit hör även den japanska internettjänsten Xpass.

Med 4in6 transporteras IPv4-trafik genom en IPv6-anslutning. Sådana funktioner är framför allt relevanta när internetleverantören kräver just denna anslutningsmodell. För en vanlig anslutning är det i sig inget skäl att bygga om WAN-konfigurationen.

Utökningarna gäller också dynamiska adresser, tunneländpunkter och MTU/MSS. Samspelet är viktigt vid felsökning: att tunneln etableras betyder inte nödvändigtvis att stora paket eller alla applikationer fungerar korrekt. Leverantörsparametrar, namnuppslagning och paketstorlekar bör därför kontrolleras tillsammans.

Driftsättning i IONOS Cloud

Sophos Firewall kan nu också köras i IONOS Cloud med den officiella SFOS-avbildningen. Installationen görs manuellt med en egen avbildning och inte via en färdig post i Marketplace.

I arkitekturplaneringen behöver man därför klargöra hur publika och interna nät ansluts, hur administrationsåtkomst skyddas och vem som ansvarar för den virtuella maskinens livscykel. En installationsplats som stöds besvarar ännu inte frågorna om redundans, återställning och övervakning.

Den egna driftmodellen får i synnerhet inte tyst förutsätta funktioner som hör till en helt hanterad molntjänst. Även en virtuell brandvägg behöver planerat underhåll och säkerhetskopior som kan kontrolleras.

Hotmeddelanden och mindre ändringar

NDR-meddelanden utan automatisk isolering

Detektioner från NDR Essentials och NDR Active Threat Intelligence kan utlösa ett meddelande utan att den berörda enheten automatiskt isoleras från nätverket.

Det skiljer tydligare mellan upptäckt och åtgärd. Det kan underlätta när nya detektionskällor införs: man utvärderar först kvaliteten på meddelandena och bestämmer sedan vilka händelser som ska leda till blockering. Skillnaderna mellan metoderna förklaras i vår artikel om NDR Active Threat Intelligence.

Ett meddelande är dock bara användbart om det hanteras. Ansvar, svarstid och eskaleringsväg måste vara fastställda. Dessutom bör man separat kontrollera vilka blockeringsåtgärder som fortfarande är konfigurerade i Active Threat Response. En ändring av larmbeteendet innebär inte att alla skyddsåtgärder har stängts av.

Innehållslistor för e-post och webbkategorier

Ytterligare ändringar gäller ID-baserade referenser för innehållslistor i e-post och versionshantering av webbkategorier.

För innehållslistorna i e-post, Content Control Lists, skiljs referensen från det synliga namnet. Namnet hjälper människor att orientera sig, medan ett stabilt ID ger en entydig koppling. Versionshanteringen av webbkategorier gäller däremot samordningen av de kategoridefinitioner som används med Sophos i bakgrunden.

Dessa punkter är mindre synliga än ett nytt gränssnitt, men hör hemma i en fullständig översikt över versionen. Vid konfigurationsändringar och återställningar är det viktigt att en policy fortfarande använder det avsedda objektet. För webbfilter bör dessutom kända tillåtna och blockerade testsidor fortfarande ge förväntat resultat efter en uppgradering.

eDirectory stöds inte längre

Sophos Firewall v23 stöder inte längre den inbyggda servertypen eDirectory. En befintlig eDirectory-koppling förhindrar därför uppgraderingen. Alternativen är Entra ID SSO, Active Directory, RADIUS eller en LDAP-koppling till den befintliga eDirectory-servern.

Det är viktigt att skilja mellan inloggning och automatisk användaridentifiering: LDAP kan autentisera användare mot den befintliga katalogen men ersätter inte den inbyggda eDirectory-SSO-funktionen. Den gamla eDirectory-kopplingen tas inte heller med när en säkerhetskopia återställs eller en konfiguration importeras.

Övergången och följderna för användare, grupper och tjänster beskrivs i vår guide Sophos Firewall: migrera eDirectory före SFOS 23.

Slutsats

REST API:et är enligt mig en av de mest meningsfulla nyheterna i Sophos Firewall v23. Det förenklar återkommande ändringar och ger en bra grund för att analysera konfigurationer med egna verktyg. API:er är också användbara vid AI-baserad analys: regler och objekt kan läsas ut strukturerat, jämföras och granskas för avvikelser. Vilka ändringar som sedan ska göras måste fortfarande en administratör avgöra. Men redan insamling och förberedelse av information kan spara mycket manuellt arbete.

Jag gillar också den nya översikten över brandväggsregler. Grupptillhörigheten i en kolumn, de fritt valbara detaljerna och att vyn sparas permanent gör arbetet smidigare. Synd att denna förbättring inte också har nått NAT-reglerna. Just där saknas fortfarande gruppering och kloning, trots att båda funktionerna vore värdefulla när större konfigurationer byggs upp och underhålls.

Jag hade dessutom gärna sett fler funktioner från Sophos Firewall Config Studio direkt i brandväggen: jämförelse av flera konfigurationstillstånd, sammanslagning av konfigurationsmallar och rapporter som för brandväggs-, NAT- och TLS-regler även visar värdena för refererade objekt. Sådana verktyg hjälper till att förstå och förbereda ändringar. I den här formen är de fortfarande förbehållna det separata Config Studio.

När det gäller hastigheten såg jag däremot ingen större förbättring i mitt första test. Det tar fortfarande flera sekunder att spara en brandväggsregel. Vid en enstaka ändring spelar det liten roll. Men när ett regelverk städas upp och många regler bearbetas efter varandra blir väntetiderna sammantaget långa och avbryter ständigt arbetsflödet. Förbättringarna av gränssnittet är välkomna. För den dagliga driften önskar jag framför allt att vanliga uppgifter går snabbare att utföra och att brandväggs- och NAT-regler kan hanteras mer enhetligt.

FAQ

Källor

• Sophos Firewall v23: versionsmeddelande, meddelande från den 28 september 2026.
• Sophos Firewall OS v23: Key New Features, teknisk funktionsguide, daterad den 28 september 2026.
• Sophos Firewall v23: återkoppling och erfarenheter, löpande synpunkter från communityn.