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 oberoende av brandväggen och övervakas de, med fastställd ägare och lagringstid?
• 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 Fusion (tidigare 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.

Undvik att låsa ute dig själv när du skapar ett WAN-undantag. Logga först in via en oberoende återställningsväg, till exempel konsolen, management-LAN, en admin-VPN eller Sophos Fusion, och testa den. Klicka därefter under Administration > Device access på Add under Local service ACL exception rule. Ett anpassningsbart exempel är WAN-Admin-203.0.113.10 med Rule position Top, IP version IPv4, Source zone WAN, administratörens fasta publika IP som Source network / host, brandväggens WAN-gränssnitt som Destination host, Services HTTPS och endast vid behov SSH, samt Action Accept. 203.0.113.10 är en dokumentationsadress och måste ersättas med den verkliga fasta admin-IP-adressen. Låt den befintliga sessionen vara öppen, testa åtkomst i en andra session från den källan och ta först därefter bort den bredare WAN-behörigheten för HTTPS eller SSH i Local service ACL. Om testet misslyckas är den tidigare åtkomsten oförändrad; korrigera undantaget innan zonbehörigheten ändras.

MFA, roller och login security

VPN Portal är inte bara till för nedladdningar: VPN-klienter och ändrade konfigurationer distribueras via VPN Portal. Även SSO kräver att nödvändig WAN-åtkomst behålls löpande: Microsoft Entra ID SSO i SFOS 22 och OpenID Connect SSO i SFOS 23. Stäng inte en SSO-väg som fortfarande behövs efter nedladdningarna. User Portal ska förbli avstängd på WAN; fjärråtkomst sker via VPN. Skydda VPN Portal med lämpliga, så snäva ACL:er som möjligt, ett giltigt certifikat och övervakning av brute-force-attacker. Kräv MFA i IdP vid OIDC, inte via ytterligare firewall-OTP. De lokala OTP-stegen nedan gäller traditionell autentisering, inte OIDC. Konfigurationen beskrivs i Entra VPN SSO och Google Workspace OIDC. Testa en ny inloggning och den faktiska VPN-tunneln från avsett externt nät efter ändringar av ACL eller autentisering; kontrollera vid fel ACL, certifikat och redirectmappning i stället för att öppna WAN brett.

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.

Behåll CAPTCHA aktiverat som standard, särskilt på inloggningssidor som kan nås från WAN eller icke-betrodda nät. Det ersätter varken MFA eller Block login; ett felaktigt CAPTCHA räknas inte som ett misslyckat inloggningsförsök för den blockeringen. Ändra och återställ CAPTCHA selektivt beskriver ett motiverat, godkänt VPN-undantag för WebAdmin eller User Portal. Dokumentera först omfattning, mål och startvärde, kontrollera åtkomst och MFA och verifiera sedan med show och en ny inloggning via avsedd VPN-väg. Återställningen återför exakt det dokumenterade värdet; en medveten återgång till aktiverad standard görs med enable. Global avstängning är varken hardening eller en lösning på den SFOS 22.0 GA-begränsning som beskrivs där. Undantagskommandona påverkar inte VPN Portal eller SPX Portal.

I SFOS 22 finns användarkonfigurationen under Authentication > Multi-factor authentication (MFA). Under One-time password (OTP) väljer du All users eller Specific users and groups, aktiverar Generate OTP token with next sign-in för appbaserade tokens och markerar varje tjänst som faktiskt används under Require MFA for. Det inbyggda kontot admin skyddas separat under Administration > Device access > MFA for default admin. Innan MFA krävs måste minst ett namngivet administratörskonto ha registrerat sin token; kontrollera utfärdandet under Issued tokens. Testa därefter en ny inloggning medan en befintlig adminsession hålls öppen som återställningsväg.

Praktisk konfiguration finns i Aktivera MFA för Sophos Firewall WebAdmin, VPN Portal och Remote Access. Hur personliga lokala konton, Device Access-profiler, inloggningskällor och offboarding samverkar beskrivs i Konfigurera administratörer och profiler säkert på Sophos Firewall. För WAF-scenarier med användarinloggning passar Säkra Sophos Firewall WAF med MFA.

Kontrollera behörigheter för Remote Access VPN

Ge VPN-åtkomst endast till användare och grupper som behöver den och endast till nödvändiga resurser. Välj inte standardgruppen för fallback, Open group, för detta. Användare utan matchande grupp kan hamna där, exempelvis vid AD-synkronisering. Granska medlemmar regelbundet och tilldela dem rätt grupper. Denna standardgrupp är varken en fallback-firewallregel eller den medvetet begränsade IdP-fallbackgruppen i den länkade SSO-guiden. Leverantörsspecifik mappning beskrivs fortsatt där. Testa vid acceptans en tillåten användare, en fallback/ej tilldelad användare och en nekad resurs: endast avsedd åtkomst får fungera. Korrigera gruppmappning och VPN/firewallbehörigheter vid oväntad åtkomst och upprepa testet.

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. Kontrollera tillgängliga maintenance releases regelbundet och installera dem skyndsamt efter godkännande. 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.

Sidan behåller högst två firmwareversioner. En rollback startar den föregående versionen med dess motsvarande tidigare konfiguration; ändringar som gjorts sedan versionsbytet går förlorade. Från SFOS 19.0 MR1 kräver firmwarebyten efter tre kostnadsfria uppgraderingar Enhanced Support eller Enhanced Plus; hotfixes kräver inte detta supportabonnemang. Kontrollera därför förväntad firmware, managementåtkomst, VPN och kritiska publiceringar innan fler konfigurationsändringar görs efter uppdateringen.

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.

En särskild efterlevnadsmigrering är FIPS 140-3-läget på Sophos Firewall: Aktiveringen utför en fabriksåterställning och kräver en fullständigt planerad återuppbyggnad med FIPS-kompatibla VPN- och certifikatinställningar.

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.

Publicera inte interna RDP-tjänster eller administrativ åtkomst direkt på internet. VPN eller ZTNA är den föredragna vägen för fjärråtkomst till interna system och fjärradministration. Threat Feeds motiverar inte publik exponering. IoT-enheter utan en molnproxyarkitektur som kräver direkt inkommande NAT-åtkomst behöver planerad isolering, ersättning eller avveckling, inte permanent WAN-exponering. Inte heller en molnproxy garanterar säkerhet i sig. Klargör beroenden, driftpåverkan och nödvändig tjänstekontinuitet med ägaren före en godkänd avstängning.

Inventera en befintlig RDP-publicering och en IoT-NAT-mappning som konkret granskning: destinationsvärd, tjänst, tillåtna källor, firewall/NAT Rule IDs, ägare och verkligt behov av fjärråtkomst. Planera migrering till VPN/ZTNA eller godkänd avveckling. En oundviklig befintlig publicering får endast kvarstå som ett uttryckligen dokumenterat, snävt avgränsat övergångsundantag med lämplig IPS-policy, aktuella patchar, loggning, ägare och slutdatum; det är inte likvärdigt med VPN/ZTNA. Testa nya tillåtna anslutningar och avsiktligt nekad extern åtkomst efter migreringen: den nödvändiga tjänsten ska fungera via avsedd väg och oönskad publik åtkomst ska vara borttagen. Kontrollera först regler, NAT, routing och ersättningsvägen vid fel i stället för att åter öppna WAN brett.

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.

DMZ i stället för huvud-LAN: Internetåtkomliga servrar hör hemma i ett separat segment och en DMZ-zon. Kontrollera den faktiska tilldelningen under Network > Zones och Network > Interfaces; ett VLAN- eller zonnamn ensamt framtvingar ingen isolering. Neka som standard DMZ-till-LAN i Rules and policies > Firewall rules, med endast uttryckligen nödvändiga, snävt avgränsade undantag. Ett anpassningsbart exempel tillåter WAN-till-DMZ-webbserver endast för HTTPS och managementnät-till-DMZ endast för godkänd admintjänst, men ingen allmän DMZ-åtkomst till klient-LAN. Ersätt värdar och tjänster med egna godkända objekt. Planera zoner och gränssnitt, avsnitt Fastställ åtkomstriktningar före reglerna, förklarar modellen. Testa tillåten applikationsåtkomst och nekade DMZ-till-LAN-anslutningar med nya flöden, förväntat Rule ID och vid behov Packet Capture. Kontrollera först ordning, zoner, objekt och bredare tillåtelser vid oväntad åtkomst. Beakta den olösta HTTP/HTTPS Drop-begränsningen under Action och loggning i regelartikeln före nya webblockeringsregler i produktion; ingen universell webbblockering utlovas här.

Internet endast för autentiserade LAN-användare: Aktivera Match known users i avsedd klientregel och välj behöriga användare/grupper efter att tillförlitlig användar-till-trafikmappning har konfigurerats. Avsnittet Match known users förklarar autentisering och förutsättningar. Servrar, IoT och annan trafik utan användarinloggning kräver separata, snäva regler; enbart IP-mappning är inte autentisering. Ingen bred fallbackregel får tillåta samma användartrafik utan identitetskontroll. Testa en tillåten användare och en okänd/obehörig användare och kontrollera att användare, grupp, Rule ID och faktisk åtkomst stämmer med avsett resultat. Kontrollera mappning, ordning och fallback vid avvikelser i stället för att ta bort användarmatchningen.

Konfigurera Security Heartbeat medvetet: Enbart managementregistrering isolerar inte komprometterade endpoints. Synchronized Security Heartbeat beskriver förutsättningarna: Network Protection, hanterad Sophos Endpoint med licens, samma molnhanteringskonto och aktiverad Heartbeat. Ange Minimum source HB permitted och vid behov för interna mål Minimum destination HB permitted i berörda regler; använd inte destination Heartbeat för WAN-mål. Green tillåter endast Green, Yellow tillåter Green eller Yellow och No restriction tillåter även Red och enheter utan Heartbeat. Kontrollera medvetet de separata alternativen Block clients with no heartbeat och Block request to destination with no heartbeat: enheter som aldrig har skickat Heartbeat blockeras endast när båda är aktiverade. Enheter utan Sophos Endpoint och Web Exceptions som hoppar över Policy checks förhindrar en generell isoleringsgaranti. Planera en godkänd pilot med definierade status/ingen-heartbeatfall, nya anslutningar och loggar; skapa ingen infektion i produktion som test. Om den förväntade begränsningen saknas, kontrollera regelmatchning, förutsättningar, status och undantag och återställ bara den senaste ändringen. Dessa kontroller är acceptanssteg för den egna miljön, inte appliance-tester som utförts här.

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 kompletterar skydd endast för en fastställd modul och trafikväg. Från SFOS 22 är matchning av käll-IPv4 för inkommande vidarebefordrad DNAT/WAF-trafik mot MDR, NDR och Third-Party Threat Feeds dokumenterad. För lokala tjänster som VPN Portal är det fastställda tilläggsskyddet käll-IPv4-matchning med stödda Third-Party Feeds; denna väg går inte genom en transit-firewallregel. Domän-/URL-indikatorer gäller i stället lämplig utgående destinationsmatchning, inte käll-IP för en inkommande inloggning. DNS/IPS/Application Classification- eller webb/TLS-inspektionsvägen måste vara lämplig; fullständiga HTTPS-URL-sökvägar kräver dekryptering. IPv6-källor omfattas inte av detta feedskydd.

Olöst X-Ops-gräns: ATR-texten och SVG-trafikmatrisen motsäger varandra om vissa X-Ops-matchriktningar, särskilt destinationsmatchning och lokal källmatchning för utgående trafik. Överför inte påståenden om MDR, NDR eller Third-Party Feeds till Sophos X-Ops, inte heller för DNAT/WAF eller lokala portaler. Förlita dig inte på omstridda feedeffekter före ett auktoritativt klargörande: restriktiva ACL:er, firewall/WAF-regler, patchning och MFA behövs oberoende av feeden. Verifiera modul, riktning, loggar och faktisk effekt endast genom godkända, kontrollerade tester. MDR Threat Feeds och NDR-guiden som länkas nedan ger mer sammanhang om gränsen.

Monitor upptäcker och loggar träffar men blockerar inte; Block måste konfigureras för den verifierade vägen. En träff bevisar varken blockering eller fullständig loggning. Kontrollera relevant ATR/firewall/WAF-logg tillsammans med den faktiska anslutningen; allowlist, hantering av false positives och ansvar behövs fortfarande. Exemplen nedan gäller endast inom dessa modul-/väggränser.

De är särskilt värdefulla för:

• publika webbservrar bakom WAF eller DNAT,
• uttryckligen godkända, tidsbegränsade RDP-, SSH- eller adminundantag under migrering till VPN/ZTNA; endast som tilläggsskydd inom fastställd modul/väg, inte som rekommendation för publik exponering,
• 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.

I SFOS 22 öppnar du widgeten Firewall health check i Control Center eller går till Monitor & analyze > Firewall health check. Data uppdateras när en övervakad konfiguration ändras. Viktigt: ett finding kan markeras manuellt som compliant utan att orsaken åtgärdas. Valideringen måste därför bekräfta att policykravet är uppfyllt, inte bara att visad status har ändrats.

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.

Bedöm telemetri och Sophos Assistant separat

Under Administration > Admin and user settings styr Sophos Adaptive Learning vilka användnings- och hotdata som firewallen skickar till Sophos. Det omfattar oklassificerade applikationer samt data om IPS-alerts, upptäckta virus, spam och fynd från Active Threat Response. Dessutom är den grundläggande rapporteringen av konfigurations- och användningsdata aktiverad som standard: enheten skickar regelbundet konfigurations-, funktions-, fel- och resursdata via HTTPS. Sophos uppger att ingen användarspecifik eller personaliserad information samlas in. Beslutet bör ändå dokumenteras med hänsyn till integritetskrav och driftmodell, i stället för att alternativet behandlas som en skyddsfunktion för lokal trafik.

Turn on Sophos Assistant påverkar däremot bara hjälptexter, smart tips och konfigurationsguider i WebAdmin. Efter en ändring måste man logga ut och in igen. Att stänga av assistenten minskar inte nätverkets attackyta och stoppar inte automatiskt telemetrin; inställningarna ska bedömas separat. Hur du använder assistenten, granskar källor och förstår gränserna för de guidade flödena förklaras i Använd Sophos Assistant säkert.

Logging, alerts och SIEM

Firewallregler utan logging är ofta värdelösa för troubleshooting och incident response. Den dokumenterade baslinjen är central rapportering i Sophos Fusion (tidigare Sophos Central) plus en vald SIEM-lösning. Fastställ händelseklasser, mottagare, ansvarig ägare, lagringstid och övervakning med åtgärdsväg. Dokumentera varje arkitekturundantag uttryckligen: det måste erbjuda en likvärdig väg som lagras oberoende av brandväggen och övervakas; inte varje arkitektur behöver dubbla destinationer. Regelbunden granskning enbart i lokal Log Viewer räcker inte. MDR, XDR och NDR är inte utbytbara loggarkiv. Kontrollera med en godkänd, ofarlig testhändelse leverans till varje avsedd destination, sökning i sparade loggar och övervaknings-/larmvägen. Korrigera händelseurval, anslutning och mottagare om leveransen misslyckas och testa igen. Kontrollera även lagringstid och behörigheter på destinationen.

Välj dessutom nödvändiga systemhändelser för e-post eller SNMP under System services > Notification list. Konfigurera först e-postmålet under Administration > Notification settings, eller SNMP-agenten och communityn eller användaren under Administration > SNMP. Efter Save ska en säker, kontrollerad händelse nå avsedd mottagare; om den inte gör det, kontrollera först e-post- eller SNMP-mål, åtkomlighet och vald händelseklass.

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.

Validera ändringar och återställ säkert

Genomför hardening i små, spårbara steg. Dokumentera aktuellt värde, owner och planerad återställningsväg före varje ändringsgrupp. Ändra sedan bara ett område, till exempel Device Access, en firewallregel eller åtgärden för ett Threat Feed. Testa både den förväntade tillåtna vägen och en avsiktligt nekad väg och kontrollera relevanta loggar. Fortsätt först därefter med nästa område.

Vid rollback återställs endast den senast ändrade inställningen till det dokumenterade startvärdet. Håll både den befintliga adminsessionen och en tidigare testad oberoende managementväg tillgängliga vid Device Access-ändringar. Ta inte bort den tidigare regeln innan den snävare ersättaren har validerats. Starta Threat Feeds med Monitor, granska träffar och möjliga false positives och byt först därefter till Block; om blockeringen orsakar problem, gå tillbaka till Monitor och lägg endast till verifierade undantag. En fullständig backuprestore är inte en bekväm Undo-knapp, utan recoveryvägen för större fel.

Kompakt hardening-checklista

För en första review, använd denna ordning:

1. Begränsa WAN-åtkomst till WebAdmin och SSH, håll User Portal avstängd och behåll och testa nödvändig VPN Portal-åtkomst för nedladdningar och SSO.
2. Aktivera MFA för admins och Remote Access.
3. Rensa lokala adminkonton, roller och lösenordspolicies.
4. Kontrollera firmware, hotfixes, pattern updates och supportstatus.
5. Dokumentera backup, SSMK, restore-väg och recoverytest.
6. Granska behovet av DNAT-, WAF- och VPN-publiceringar; begränsa VPN-grupper/resurser, ge inte Open group behörighet och testa tillåten och nekad åtkomst.
7. Rensa regler med Any, saknad logging eller oklar owner.
8. Aktivera IPS, Spoof Protection, DoS Settings och Threat Feeds målinriktat.
9. Inför Web, DNS, TLS och Zero-Day Policies stegvis.
10. Etablera Health Check, oberoende lagrade och övervakade loggar, leveranstester, alerts och regelbundna granskningar med ägare och lagringstid.

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.

FAQ