Sophos Firewall Hardening: best practices för säker konfiguration
Sophos Firewall hardening betyder att man medvetet minskar onödig attackyta kring själva brandväggen och de tjänster som publiceras genom den. Det är inte en enskild magisk inställning, utan en upprepbar driftprocess: begränsa administrationsåtkomst, kräva MFA, hålla firmware aktuell, granska regler, aktivera skyddsfunktioner och analysera loggar.
Den här artikeln är den centrala ingången. Den ersätter inte detaljguiderna, utan ordnar de viktigaste best practices och länkar till passande Avanet KB-artiklar.
Vad som bör kontrolleras först
Vid hardening spelar ordningen roll. En perfekt trimmad IPS-policy hjälper lite om WebAdmin är åtkomlig globalt från WAN eller en gammal VPN Portal står öppen utan MFA.
De viktigaste snabbkontrollerna:
- Är WebAdmin åtkomlig från WAN-zonen?
- Är SSH endast tillåtet från betrodda managementnät?
- Är MFA aktivt för administratörer, VPN Portal och Remote Access?
- Är firmware, hotfixes och pattern updates aktuella?
- Finns DNAT-, WAF- eller VPN-åtkomster som inte längre behövs?
- Har publicerade tjänster IPS, WAF, Threat Feeds, logging och tydlig ägare?
- Sparas säkerhetsrelevanta loggar centralt eller granskas de åtminstone regelbundet?
- Finns en aktuell och testad backup inklusive Secure Storage Master Key?
Säkra administrationsåtkomst
Det viktigaste hardening-området är åtkomst till själva brandväggen. WebAdmin, SSH, User Portal, VPN Portal, Captive Portal och lokala tjänster är inte vanliga firewallregler, utan lokala tjänster på brandväggen. De måste begränsas medvetet via Device Access och Local Service ACL.
Device Access och Local Service ACL
Under Administration > Device access definieras per zon vilka lokala tjänster som är åtkomliga. För WAN-zonen bör endast det som verkligen behövs vara aktivt. Adminåtkomst och SSH bör normalt inte exponeras brett mot internet.
Om fjärradministration behövs är dessa varianter renare:
- Hantering via Sophos Central.
- Åtkomst via ett dedikerat managementnät.
- Åtkomst via VPN eller ZTNA.
- Snäva Local Service ACL Exception Rules för fasta admin-käll-IP-adresser.
Den konkreta implementationen beskrivs i Säkra Sophos Firewall-åtkomst: konfigurera Device Access korrekt. Om SSH behövs hjälper även Anslut Sophos Firewall via SSH.
MFA, roller och login security
MFA bör vara obligatoriskt för administratörer och Remote Access-användare. Särskilt kritiska är lokala admin-konton, VPN Portal, User Portal och Remote Access VPN. MFA är dock bara en del av login-hardening. Namngivna adminkonton, tydliga roller, starka lösenordspolicies, begränsade loginförsök och korta session timeouts är lika viktiga.
Praktisk konfiguration finns i Aktivera MFA för Sophos Firewall WebAdmin, VPN Portal och Remote Access. För WAF-scenarier med användarinloggning passar Säkra Sophos Firewall WAF med MFA.
Firmware, hotfixes och recovery
En firewall är ett edge-system. Försenade uppdateringar är därför inte en liten detalj, utan ett verkligt attackfönster. Samtidigt får uppdateringar inte göras blint, eftersom fjärrplatser, HA-kluster, VPN och produktiva NAT-regler kan påverkas.
Göra uppdateringar planeringsbara
Firmwareuppdateringar bör förberedas med backup, underhållsfönster, release notes-granskning, HA-planering och rollbackkriterier. I aktuella SFOS 22-versioner visar WebAdmin-sidan Backup & Firmware > Firmware inte längre en separat Hotfix-sektion. Hotfix-funktionen finns fortfarande: Sophos installerar hotfixes automatiskt som standard och rekommenderar att inställningen inte ändras. Om status måste kontrolleras, använd system hotfix show i Device Console. Hotfixes ersätter inte en regelbunden updateprocess. Processen beskrivs i Sophos Firewall firmware update: förberedelse och best practices.
Vid större versionshopp bör även upgrade path, licens, plattform och kända begränsningar kontrolleras. Kontrollera Sophos Firewall före SFOS 22 upgrade passar här.
Kontrollera backup och restore
Hardening slutar inte med prevention. En härdad firewall måste också gå att återställa. Det kräver aktuell backup, backuplösenord, Secure Storage Master Key, dokumenterad åtkomstväg efter restore och ett acceptanstest.
Detaljerna finns i Skapa eller återställ Sophos Firewall backup. Ett komplett recoverypaket är obligatoriskt särskilt före firmware updates, migrationer, reimage och hårdvarubyte.
Minska attackytan i regelverket
Många risker kommer inte från exotiska attacker, utan från för breda regler, gamla undantag och publicerade tjänster som ingen längre verkligen äger.
NAT, WAF och publicerade tjänster
Varje tjänst som publiceras via DNAT eller WAF är en medvetet öppnad ingång. Det kan vara nödvändigt, men måste planeras snävt: source, destination, service, NAT-ordning, firewallregel, IPS/WAF-policy, logging, test och owner hör ihop.
För publicerade servrar hjälper Publicera server med DNAT på Sophos Firewall och Förstå NAT på Sophos Firewall. Om webbservrar publiceras är Sophos Firewall WAF: publicera webbservrar säkert bättre grund.
Firewallregler och segmentering
Regler med Any som source, destination eller service är inte automatiskt fel, men måste alltid kunna förklaras. För hardening är dessa frågor viktiga:
- Behövs regeln fortfarande?
- Är logging aktiv?
- Finns tydligare source eller destination?
- Är regeln korrekt placerad före bredare regler?
- Är admin-, server-, klient-, IoT-, gäst- och backupnät tydligt separerade?
Grunderna finns i Förstå och konfigurera Sophos Firewall-regler säkert. För att kontrollera en konkret regel passar Testa Sophos Firewall-regel rent.
Aktivera skyddsfunktioner medvetet
Skyddsfunktioner hjälper bara när de passar regeln, trafiken och driftprocessen. Blint aktiverade funktioner skapar false positives, prestandaproblem eller supportärenden. Avstängda funktioner lämnar däremot onödig attackyta öppen.
IPS, Spoof Protection och DoS
IPS bör användas på inkommande icke-betrodd trafik och på relevanta interna övergångar. Viktigt är passande IPS Policies, logging, false-positive-process och prestandablick. Implementeringen finns i Konfigurera och testa Sophos Firewall IPS säkert.
Spoof Protection och DoS Settings minskar osannolika källor och enkla floodingmönster. De måste testas försiktigt, särskilt med VoIP, VPN, hög paketlast eller speciella routingdesigner. Passande artikel är Kontrollera Sophos Firewall Spoof Protection och DoS Settings.
Threat Feeds för WAF och DNAT
Threat Feeds är ett mycket användbart tillägg när tjänster är åtkomliga via WAF, DNAT, VPN Portal eller andra offentliga åtkomstvägar. De kan blockera kända skadliga IPs, domäner eller URLer tidigare, innan de når den faktiska applikationen eller regeln.
De är särskilt värdefulla för:
- publika webbservrar bakom WAF eller DNAT,
- RDP-, SSH- eller adminåtkomst som ännu inte ersatts av ZTNA,
- VPN- och portalåtkomst med mycket internetbrus,
- miljöer där country blocking är för grovt,
- kunder som vill använda kuraterade tredjepartsfeeds utöver Sophos X-Ops.
Driften är avgörande: feedkvalitet, åtgärd Monitor eller Block, allowlist, false positives, logging och ansvar måste vara tydliga. Konfigurationen beskrivs i Konfigurera och drifta Sophos Firewall Threat Feeds säkert. För kuraterade feeds kan Cybora vara en användbar komponent, särskilt när publicerade tjänster konsekvent ska skyddas mot kända dåliga källor.
Web, DNS, TLS och Zero-Day Protection
Web Protection, DNS Protection, TLS Inspection och Zero-Day Protection ökar synlighet och blockeringsförmåga, men kräver ren planering. TLS Inspection bör inte starta som allt-eller-inget-projekt. DNS Protection måste passa de DNS-vägar som används. Zero-Day Protection hjälper bara när relevanta filtyper och policies är integrerade på ett vettigt sätt.
Passande detaljartiklar är Skapa Sophos Firewall Web Protection med Web Policies, Konfigurera Sophos DNS Protection med Sophos Firewall, Inför Sophos Firewall TLS Inspection korrekt och Förstå och drifta Sophos Firewall Zero-Day Protection.
Detektion, logging och review
Hardening är inte en engångsuppgift. Regler, användare, portaler, NAT-undantag och firmwareversioner ändras. Därför krävs regelbundna reviews och loggar som finns innan en incident inträffar.
Health Check som startpunkt
Sophos Firewall Health Check är en bra startpunkt eftersom den synliggör riskabla konfigurationer. Findings bör inte tillämpas blint, utan bedömas efter risk, driftpåverkan och lokal arkitektur.
Bra tillfällen för Health Check:
- efter initial setup,
- efter migrationer,
- före och efter firmware upgrades,
- efter större regeländringar,
- före audits,
- kvartalsvis i drift.
Logging, alerts och SIEM
Firewallregler utan logging är ofta värdelösa för troubleshooting och incident response. För längre retention räcker lokal Log Viewer oftast inte. Beroende på miljö är Sophos Central Reporting, Syslog, SIEM, MDR, XDR eller NDR användbara.
Teknisk Syslog-konfiguration beskrivs i Skicka Sophos Firewall Syslog säkert till SIEM. För centrala rapporter passar Aktivera och drifta Sophos Firewall Central Reporting. Om NDR och Active Threat Response är relevanta hjälper Drifta Sophos Firewall NDR och Active Threat Response.
Kompakt hardening-checklista
För en första review, använd denna ordning:
- Kontrollera WAN-åtkomst till WebAdmin, SSH, User Portal och VPN Portal.
- Aktivera MFA för admins och Remote Access.
- Rensa lokala adminkonton, roller och lösenordspolicies.
- Kontrollera firmware, hotfixes, pattern updates och supportstatus.
- Dokumentera backup, SSMK, restore-väg och recoverytest.
- Granska DNAT-, WAF- och VPN-publiceringar efter behov.
- Rensa regler med
Any, saknad logging eller oklar owner. - Aktivera IPS, Spoof Protection, DoS Settings och Threat Feeds målinriktat.
- Inför Web, DNS, TLS och Zero-Day Policies stegvis.
- Etablera Health Check, Syslog, alerts och regelbundna reviews som driftprocess.
Vanliga fel
WAN-åtkomst förblir öppen av bekvämlighet
WebAdmin- eller SSH-åtkomst öppnas för ett supportärende och glöms sedan bort. Just sådana tillfälliga undantag bör dokumenteras med slutdatum, owner och efterkontroll.
Threat Feeds aktiveras utan driftkoncept
Threat Feeds är starka, men inte underhållsfria. Utan monitoring, allowlist och false-positive-process kan en legitim partner, leverantör eller molntjänst blockeras. Testa därför först med Monitor eller begränsad scope och växla sedan rent till Block.
Logging saknas på kritiska regler
Om en publik DNAT-regel, WAF-regel eller VPN-regel inte loggar syns för lite vid incident. Minst säkerhetsrelevanta ingångar, adminåtkomst, deny-regler och kritiska segmentövergångar bör vara spårbara.
Health Check behandlas som engångsuppgift
En bra poäng efter setup är inget permanent tillstånd. Nya regler, nya VPN-användare, tillfälliga undantag och firmwareändringar kan ändra läget. Hardening behöver en review-rytm.