Sophos Firewall: hårdvara, virtuell eller moln?

Sophos Firewall kan fungera som XGS Appliance, virtuell apparat, Software Appliance eller Cloud Deployment. Tekniskt sett körs Sophos Firewall OS överallt, men driftsmodellen är inte densamma. Beslutet påverkar prestanda, support, portdesign, HA, återhämtning, licensiering, övervakning och frågan om vem som ansvarar för vilken plattform vid avbrott.

För nya projekt ska man inte bara fråga vilken variant som är billigare. Det som spelar roll är vilken variant som passar platsen, virtualiseringsplattformen, molnarkitekturen och driftteamet. Sophos Firewall Storleksguide är också viktig för prestandastorlek.

Valet av plattform avgör också vilka efterlevnadsfunktioner som finns: FIPS 140-3-läget erbjuds på XGS Appliances, virtuella plattformar som stöds, AWS och Azure, men inte på Software Appliances eller XG- och SG-hårdvara.

Välj driftmodell

Snabbt beslut

• XGS Appliance: Passar oftast när en webbplats behöver en dedikerad brandvägg som tydligt stöds med fysiska portar.
• Virtual Appliance: Mest lämpligt om en stabil virtualiseringsplattform är tillgänglig och nätverkszoner kan separeras rent virtuellt.
• Software Appliance: Vanligtvis lämplig om din egen hårdvara avsiktligt ska drivas och stödjas som en brandväggsplattform.
• Cloud Deployment: Mest lämplig när du skyddar arbetsbelastningar i AWS eller Azure eller ansluter till lokala nätverk.

Den viktigaste regeln: En virtuell brandvägg eller molnbrandvägg är inte ett gratiskort för mindre planering. CPU, RAM, lagring, virtuella switchar, routing, HA, backup och övervakning måste planeras lika noggrant som med hårdvara.

När ska man vara försiktig

Beslutet ska inte bara baseras på vad som är tekniskt möjligt. Vissa miljöer ser flexibla ut på pappret, men skapar onödiga risker i driften.

• Hypervisor används redan hårt: IPS, TLS Inspection, VPN och loggning behöver förutsägbar CPU och I/O-reserv.
• WAN, LAN, DMZ och förvaltningen går igenom samma fysiska flaskhals: En logiskt ren separation är till liten hjälp om den verkliga datavägen är överbelastad eller felaktigt segmenterad.
• Inget team känner sig gemensamt ansvariga för hypervisor och brandvägg: Incidenter kvarstår mellan plattforms-, nätverks- och brandväggsteam.
• HA planerades endast som en kryssruta: Utan testning av värd, lagring, nätverk och återställning är hög tillgänglighet inte bevisad.
• Molnrouting är inte helt dokumenterad: Brandväggen skyddar bara trafik som faktiskt dirigeras genom den.
• Återställning praktiserades aldrig: En säkerhetskopia är bara tillförlitlig om en återställning har testats realistiskt eller åtminstone ordentligt planerad. I sådana fall är en XGS Appliance ofta inte mindre modern, utan helt enkelt det mer robusta driftbeslutet. Omvänt kan en virtuell brandvägg eller molnbrandvägg vara mycket användbar om plattformen, nätverksdesignen, övervakningen och ansvaret är tydligt klarlagda.

Jämför plattformarna

XGS Appliance

En XGS Appliance är vanligtvis den mest planerade varianten för klassiska platser. Hårdvara, portar, support, RMA, livscykel och brandväggsoperativsystem kommer som ett koordinerat system.

Fördelar:

• dedikerad hårdvara för brandväggen,
• fast hamnutrustning och expansionsmöjligheter,
• tydlig tilldelning av WAN, LAN, DMZ, HA länk och hantering,
• enkel hårdvarusupport och ersättningsprocess,
• inget beroende av hypervisorresurser,
• Väl lämpad för filialer, huvudkontor och kantbrandväggar. Den största fördelen ligger i driften: Om det finns ett problem behöver du inte först klargöra om hypervisor, vSwitch, lagring, molnrouting eller själva brandväggen är orsaken. För många små och medelstora företag är detta viktigare än maximal flexibilitet.

Virtuell apparat

En virtuell Sophos Firewall är vettig om det redan finns en ren virtualiseringsplattform och brandväggen ska integreras i ett datacenter, en miljö med flera hyresgäster eller en intern segmenteringsdesign.

Relevanta virtuella plattformar omfattar VMware, Microsoft Hyper-V, KVM, Nutanix Prism och Citrix Hypervisor. Före deployment ska den konkreta plattformsversionen kontrolleras mot aktuell kompatibilitetsinformation från Sophos. Sophos anger minst en vCPU, 4 GB RAM, två vNIC, en primär disk på 32 GB och en rapportdisk på 80 GB. Detta är installationsminimum, inte en sizingrekommendation för inspection-trafik i produktion.

Kontrollen får inte stanna vid produktfamiljen. För Nutanix kräver Sophos exempelvis AOS 6.5.x eller en senare LTS-version, den medföljande AHV-versionen, en kompatibel version av Prism Central och ett AHV-kluster som är registrerat i Prism Central. KVM kräver en x86-värd med en aktuell Linux-kärna och aktiverat stöd för Intel VT eller AMD-V. Om vCPU och RAM utökas för högre belastning bör även en större rapportdisk planeras för den ökade loggvolymen.

Viktiga operativa frågor:

• Är CPU-resurser garanterade eller kraftigt övertecknade?
• Är RAM och lagring tillräckligt dimensionerade?
• Är virtuella nätverkskort och portgrupper tydligt åtskilda?
• Finns det dedikerade nätverksvägar för WAN, LAN, DMZ, HA och hantering?
• Krävs promiskuöst läge, VLAN trunking eller SR-IOV?
• Finns det ett rent säkerhetskopierings- och återställningskoncept?
• Är det klart vem som felsöker hypervisor, lagring och brandvägg tillsammans?

En virtuell brandvägg kan fungera mycket bra. Saker och ting blir dock snabbt problematiska när den körs på en överbelastad värd eller när WAN, LAN och hanteringen bara ser logiskt rena ut, men fysiskt går igenom samma flaskhalsar.

⚠️ Hypervisorsnapshots eller backups från virtualiseringsleverantören är inte en supportad ersättning för Sophos integrerade backup. För en supportbar restore ska konfigurationen sparas under Backup & Firmware > Backup & Restore. Plattformens backups kan finnas som komplement, men får inte vara den enda recoveryvägen.

Software Appliance

En Software Appliance installeras på dedikerad x86-64-hårdvara. Detta kan vara användbart för laboratorier, specialmiljöer eller mycket riktade designer. I produktion måste modellen väljas medvetet eftersom hårdvara, drivrutiner, reservdelar, övervakning och support till stor del är operatörens ansvar.

Installationen formaterar och partitionerar om disken och raderar det befintliga operativsystemet samt alla filer. För en Software Appliance med SFOS 22 kräver Sophos Legacy BIOS, minst 4 GB RAM, två nätverksgränssnitt och minst 32 GB lagring; 64 GB rekommenderas. Om minimikraven inte uppfylls kan brandväggen gå in i fail-safe mode.

Om en appliance redan startar i Failsafe-läge ska orsaken som SFOS har identifierat sparas med runbooken Kontrollera Sophos Firewall i Failsafe-läge innan resurser ändras.

Kontrollera:

• Är hårdvaran lämplig för kontinuerlig drift?
• Är nätverkskort, lagring och BIOS/UEFI-konfiguration lämpliga?
• Finns det ersättningshårdvara?
• Är installations- och återställningsprocessen dokumenterad?
• Vem är ansvarig för hårdvarufel?

För standardplatser är en XGS Appliance ofta enklare. För speciella tekniska fall kan en Software Appliance ändå vara lämplig om driftteamet har god kontroll över plattformen.

Cloud Deployment

Molndistributioner är särskilt användbara när arbetsbelastningar i AWS eller Azure behöver skyddas eller när molnnätverk är anslutna till lokala platser. Olika frågor är viktiga i molnet än på den traditionella platsen.

Planera:

• VPC/VNet design,
• rutttabeller,
• Tillgänglighetszoner,
• Elastiska IP-adresser eller offentliga IP-adresser,
• Plats-till-plats VPN eller SD-WAN,
• Loggning och central utvärdering,
• Molnkostnader för till exempel lagring, trafik och HA design,
• Operativt ansvar mellan molnteam och brandväggsteam.

En molnbrandvägg är inte en ersättning för ren molnnätverksdesign. Endast de vägar som faktiskt dirigeras genom brandväggen är skyddade. Besluten om deployment och routing beskrivs i guiderna för Sophos Firewall på AWS och Sophos Firewall på Azure.

Installera en virtuell appliance eller Software Appliance

Ladda ned imagen direkt från Sophos-sidan Firewall Installers. Under Virtual Installers väljer du motsvarande OVF-paket för Citrix eller VMware, VHD-paketet för Hyper-V eller QCOW2-paketet för KVM, Proxmox eller Nutanix. För egen hårdvara använder du i stället ISO-filen under Software Installers.

Kontrollera före importen att nedladdningssidan som länkas ovan laddades via HTTPS, att paketet inte kom från en tredjepartsspegel och att arkivet packades upp fullständigt utan fel. För ett OVF-paket ska manifestet, OVF-filen och båda VMDK-filerna hållas tillsammans. Om importen rapporterar en avvikelse i manifest eller kontrollsumma ska du avbryta och ladda ned paketet igen direkt från Sophos. Vid en intern filöverföring kan du även registrera ett SHA-256-värde direkt efter nedladdningen och jämföra det på nytt på målsystemet. Detta upptäcker överföringsfel men ersätter inte en leverantörssignatur.

Före import gäller minimikraven 1 vCPU, 4 GB RAM, två vNIC, en primär disk på 32 GB och en rapportdisk på 80 GB. Otillräckliga resurser aktiverar fail-safe mode. Hypervisorsnapshots och leverantörens backupverktyg är inte stödda brandväggsbackuper; använd SFOS backupfunktion.

Kontrollera före första starten PortA och PortB mot management-, LAN- och WAN-nät. En omvänd koppling kan exponera WebAdmin direkt mot internet. Gör första åtkomsten från ett isolerat administratörsnät på https://172.16.16.16:4444, exempelvis med 172.16.16.2/24 på klienten. Ändra inte standardlösenordet i CLI före installationsguiden, eftersom den då inte startar. Efter wizard kontrolleras licens, båda diskarna, gränssnitt, rapportering, backup och ett negativt åtkomsttest från ett otillåtet nät.

Validera installationen och återgå säkert

Installera inte om direkt om https://172.16.16.16:4444 inte kan nås. Kontrollera först att administratörsklienten ligger direkt i PortA:s nät, att motsvarande vNIC är ansluten och att dess portgrupp eller bridge verkligen är kopplad till det isolerade administratörsnätet. Använd därefter VM-konsolen för att bekräfta att brandväggen har startat fullständigt och uteslut en adresskonflikt med 172.16.16.16. PortA får inte av misstag vara ansluten till det publika WAN-nätet under testet.

Om rapporter saknas efter konfigurationen eller om appliance startar i fail-safe mode jämförs auxiliary-/rapportdiskens tilldelning, buss och minsta storlek samt CPU, RAM och båda vNIC med Sophos plattformsspecifika krav. Dokumentera den identifierade orsaken med runbooken för fail-safe mode innan resurser ändras.

Så länge brandväggen inte dirigerar produktionstrafik är återgången enkel: stäng av VM:n, återställ testrutter eller tillfällig default gateway och fortsätt använda den befintliga brandväggen oförändrad. Efter produktionssättning måste recovery i stället bygga på en aktuell SFOS-backup och en dokumenterad återuppbyggnad av VM:n, inte på en hypervisorsnapshot.

Installera på egen maskinvara

Software Appliance ersätter det befintliga operativsystemet helt. Den kräver x86-64, Legacy BIOS, minst 4 GB RAM, två NIC och HDD eller SSD på 32 GB; 64 GB rekommenderas. USB-minnet behöver minst 1 GB. Windows eller macOS används bara för att skriva ISO-filen. Målservern startas sedan från USB och formateras och partitioneras om fullständigt efter bekräftelse. Säkra först data och kontrollera bootläge, NIC-identifiering och en oberoende återställningsväg.

Planera drift och återställning

Prestanda och storlek

När det kommer till hårdvara beror prestanda på vilken modell du väljer. För virtuella, mjukvaru- och molninstallationer är prestandan mer plattformsberoende.

Särskilt relevant:

• CPU prestanda och CPU reservation,
• RAM,
• lagringslatens,
• virtuella nätverkskort,
• hypervisor eller molnnätverksväg,
• antal sessioner,
• TLS Inspection,
• IPS,
• VPN genomströmning,
• Loggning och rapportering.

Databladsvärden ska därför alltid läsas i sitt sammanhang. Brandväggsgenomströmning utan säkerhetsinspektion är inte detsamma som Threat Protection, TLS Inspection eller IPsec VPN under verklig belastning. Skillnaderna förklaras Sophos Firewall Tolka prestandadata korrekt.

HA och återställning

Hög tillgänglighet skiljer sig markant beroende på plattform. När det kommer till hårdvara är HA vanligtvis lättare att förstå: två apparater, HA länk, definierade gränssnitt, tydlig ersättningsenhet. Ytterligare frågor uppstår för virtuella och molninstallationer:

• Körs HA-noder på olika värdar?
• Är lagring, nätverk och hypervisor verkligen överflödiga?
• Är virtuella MAC-adresser och vSwitch-regler kompatibla?
• Finns det några beroenden av molnrouting eller lastbalansering?
• Fungerar säkerhetskopieringar och återställningar på en ny instans?
• Har felet hos en värd eller en tillgänglighetszon testats?

Grunderna för HA-varianter finns i Ställa in Sophos Firewall High Availability (HA). För återställning krävs läsning av Sophos Firewall Skapa eller återställ säkerhetskopia.

Licensiering och support

Licenser ska kontrolleras tidigt eftersom hårdvaru-, virtuella och mjukvarubrandväggar hanteras olika. Sedan mars 2025 begränsas virtuella, mjukvaru- och cloud BYOL-licenser av CPU-kärnor; den tidigare RAM-gränsen gäller inte längre. Det betyder inte att obegränsat RAM kompenserar för dålig sizing av CPU, storage eller NIC. Serienummer, core-licens, support och subscription måste fortfarande passa instansen.

Sophos Firewall - Baslicens är lämplig för grundlicensen. Förändringen av virtuella licenser och mjukvarulicenser, där RAM inte längre är i fokus för licensgränsen, listas i blogginlägget Sophos Firewall VM & SW - Endast CPU räknas - Ingen mer RAM-gräns.

Vad är viktigt i drift:

• Dokumentlicens och supportstatus.
• Spela in serienummer och registreringsstatus.
• Kontrollera HA licensiering innan du bygger.
• Kontrollera firmware och stödberättigande före uppgraderingar.
• Känn till RMA eller återställningsprocessen för den valda plattformen. Före större uppgraderingar bör Kontrollera Sophos Firewall före SFOS 22 uppgradering också användas eftersom plattformsstöd, lagringsutrymme, backup, HA och gamla VPN-konfigurationer kan vara uppgraderingsrelevanta.

För active-passive HA på virtuella eller Software Appliances behöver endast Primary alla nödvändiga licenser, inklusive Base Firewall License. I active-active behöver varje node en egen Base Firewall License och samma ytterligare skyddslicenser; utgångsdatumen får skilja sig åt. Detta ska lösas innan klustret byggs, inte under analysen av första failover.

Beslutsmatris

• Klassisk plats med WAN, LAN och DMZ: Mestadels hårdvara. Endast virtuellt med en bra virtualiseringsstrategi.
• Datacenter med befintligt hypervisorteam: Hårdvara är möjlig, virtuellt är ofta vettigt.
• Molnbelastningar i AWS eller Azure: Mer virtuellt eller moln, inte klassisk hårdvara.
• Enkelt stöd och RMA viktigt: Mer hårdvara. Med virtuell eller moln beror mycket på plattformsteamet.
• Många fysiska portar krävs: Mer hårdvara. Endast virtuellt med ren NIC och vSwitch-design.
• Dynamisk skalning och Infrastructure as Code: Mer virtuellt eller moln.
• Små IT-team utan specialiserad hypervisorkunskap: Mestadels hårdvara; Planera virtuella brandväggar noggrant.
• Hyresgäst- eller segmenteringsdesign i datacentret: Hårdvara är möjlig, virtuellt är ofta vettigt.

Vanliga fel

• Kör virtuell brandvägg på överbokad värd.
• Separera inte WAN, LAN och hanteringen på hypervisorn.
• Välj bara hårdvara baserat på pris istället för storlek.
• Att implementera en molnbrandvägg, men inte helt tänka igenom routingtabeller.
• Planera HA men testa inte värd-, lagrings- eller molnfel.
• Skapa säkerhetskopia, men öva aldrig på återställning.
• Kontrollera endast licens- och supportstatus under uppgradering av firmware.
• Aktivera säkerhetsfunktioner som TLS Inspection eller IPS senare, utan prestandareserv.
• Samla endast plattformsteamet, nätverksteamet och brandväggshanterare vid störningar.

Checklista

• Plats tydligt definierad: plats, datacenter eller moln.
• Trafik, bandbredd och säkerhetsfunktioner registrerade för dimensionering.
• Hårdvara, virtuell, mjukvara eller molnvarianter avsiktligt valda.
• Ansvar för att brandvägg, hypervisor, moln och nätverk dokumenteras.
• HA och återställningsdesign kontrolleras.
• Säkerhetskopiera och återställa process testad eller planerad.
• Licens, support och registrering förtydligas.
• Övervakning för brandvägg och underliggande plattform tillgänglig.
• Uppgraderingsbarhet och plattformsstöd kontrolleras.
• Ansvarig för plattform, nätverk, brandvägg, backup och återställning namngiven.

Vanliga frågor