Sophos Firewall: hårdvara, virtuell eller moln?

Sophos Firewall kan köras som XGS Appliance, virtuell appliance, Software Appliance eller Cloud Deployment. Alla varianter kör Sophos Firewall OS, men driftsmodellen är inte densamma. Beslutet påverkar prestanda, support, nätverksportarnas utformning, HA, återställning, licensiering, övervakning och vem som ansvarar för respektive plattform vid en driftstörning.

För nya projekt bör man inte bara fråga vilken variant som är billigast. Det viktiga är vilken variant som passar den fysiska platsen, virtualiseringsplattformen, molnarkitekturen och driftteamet. Dimensioneringsguiden för Sophos Firewall är också viktig för prestandadimensioneringen.

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 fysisk plats behöver en dedikerad brandvägg med fysiska nätverksportar och tydligt supportansvar.
• Virtual Appliance: Passar oftast om en stabil virtualiseringsplattform finns och nätverkszonerna kan hållas tydligt åtskilda virtuellt.
• Software Appliance: Passar vanligtvis om man medvetet vill använda egen hårdvara som brandväggsplattform och ansvara för dess drift och support.
• Cloud Deployment: Passar oftast för att skydda arbetsbelastningar i AWS eller Azure eller ansluta dem till lokala nätverk.

Den viktigaste regeln: En virtuell brandvägg eller molnbrandvägg innebär inte att mindre planering behövs. CPU, RAM, lagring, virtuella switchar, routing, HA, säkerhetskopiering och övervakning måste planeras lika noggrant som för 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.

• Hypervisorn är redan hårt belastad: IPS, TLS Inspection, VPN och loggning behöver förutsägbara CPU- och I/O-reserver.
• WAN, LAN, DMZ och administration går genom samma fysiska flaskhals: En tydlig logisk separation hjälper föga om den faktiska datavägen är överbelastad eller felaktigt segmenterad.
• Inget team tar ett gemensamt ansvar för hypervisorn och brandväggen: Incidenter hamnar mellan plattforms-, nätverks- och brandväggsteamen.
• HA har bara planerats som en punkt att bocka av: Utan tester av värdar, lagring, nätverk och återställning är hög tillgänglighet inte verifierad.
• Molnrouting är inte helt dokumenterad: Brandväggen skyddar bara trafik som faktiskt dirigeras genom den.
• Återställning har aldrig övats: En säkerhetskopia är bara tillförlitlig om återställningen har testats realistiskt eller åtminstone planerats ordentligt.

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 det mest förutsägbara alternativet för traditionella verksamhetsställen. Hårdvara, nätverksportar, support, RMA, livscykel och brandväggsoperativsystem ingår i ett samordnat system.

Sophos utbud av fysisk hårdvara täcker olika behov, från hemanvändare och småföretag till stora företag. Vilken XGS Appliance som passar beror på trafik, skyddsfunktioner, portar och HA-krav. Låt vid behov Sophos säljteam eller en partner granska valet utifrån dessa krav. Att hårdvaran passar ett hemnätverk betyder inte automatiskt att den kostnadsfria Home-licensen får användas på den valda hårdvaran.

Fördelar:

• dedikerad hårdvara för brandväggen,
• fast konfiguration av nätverksportar och expansionsmöjligheter,
• tydlig tilldelning av WAN, LAN, DMZ, HA-länk och administration,
• enkel hårdvarusupport och process för utbyte,
• inget beroende av hypervisorresurser,
• väl lämpad för filialer, huvudkontor och brandväggar vid nätverkets gräns.

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 appliance

En virtuell Sophos Firewall är ett lämpligt alternativ om en väl utformad virtualiseringsplattform redan finns och brandväggen ska integreras i ett datacenter, en miljö med flera klientorganisationer eller en lösning för intern segmentering.

Den tillhandahåller SFOS-säkerhetsfunktioner från hårdvaruappliances i virtualiserad form, inklusive identitetsbaserad säkerhet. Säkerhetsbeslut tar därmed hänsyn till användarens identitet, inte bara nätverksadressen. Organisationer och leverantörer av hanterade säkerhetstjänster (MSSP) kan samla nätverksskyddet för virtuella datacenter eller kontor i en virtuell brandvägg. Tillgängliga funktioner beror på licenserna och den plattform som stöds; detta innebär varken identisk hårdvaruacceleration eller samma genomströmning som en XGS Appliance.

Virtuella driftsättningar och molndriftsättningar med SFOS kan via Sophos Endpoint Security Heartbeat även ta hänsyn till hälsostatusen för hanterade endpoints vid åtkomstbeslut. Detta kräver rätt licensrättigheter för endpoints och brandväggar, registrering i samma korrekta organisation och en uttryckligen konfigurerad reaktion. Identitetsbaserad säkerhet är inte en likvärdig mekanism för endpoint-hälsostatus; enbart registrering visar varken att isolering sker eller att alla trafikvägar blockeras. Förutsättningar, reaktionsvägar och kontroller av effekten förklaras i guiden till Security Heartbeat och Synchronized Security.

Sophos erbjuder även central administration av Sophos Firewall-enheter. Plattformöversikten för SFOS 22 använder namnet Sophos Fusion (previously Sophos Central), medan översikten för SFOS 23 använder Sophos Central. Dessa olika namn visar inte att central administration infördes med SFOS 23. Kontrollera vid planeringen vilken tjänst administrationsportalen använder och vilka krav som gäller för att ansluta brandväggen; central logganalys är inte i sig central enhetsadministration.

Relevanta virtuella plattformar omfattar VMware, Microsoft Hyper-V, KVM, Nutanix Prism och Citrix Hypervisor. Före driftsättning ska den specifika 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 minimikrav för installation, inte en dimensioneringsrekommendation för säkerhetsinspektion av produktionstrafik.

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-resurserna garanterade eller kraftigt överallokerade?
• Ä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-trunkning eller SR-IOV?
• Finns det en tydlig plan för säkerhetskopiering och återställning?
• Är det tydligt vilka som gemensamt felsöker hypervisorn, lagringen och brandväggen?

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 säkerhetskopior från virtualiseringsleverantören är inte en ersättning som stöds för Sophos integrerade säkerhetskopiering. För en återställning som stöds ska konfigurationen sparas under Backup & Firmware > Backup & Restore. Säkerhetskopior av plattformen kan användas som komplement, men får inte vara den enda återställningsvägen.

Software Appliance

En Software Appliance installeras på dedikerad x86-64-hårdvara. Detta kan vara användbart för labb, specialmiljöer eller lösningar med mycket specifika krav. I normal kunddrift bör modellen väljas medvetet eftersom val av hårdvara, drivrutiner, reservdelar, övervakning och support till stor del är driftorganisationens ansvar.

SFOS på lämplig fysisk hårdvara tillhandahåller brandväggsregler och policyer, hotrespons samt statisk routing, SD-WAN och dynamisk routing, beroende på relevanta licenser och plattformens dimensionering. Tillverkarnamn som Dell eller HP är exempel, inte en verifierad kompatibilitetslista för enskilda modeller.

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.

Motstridiga lagringsuppgifter: Plattformöversikterna för SFOS 22 och 23 anger minst 10 GB för egen hårdvara. De specifika installationskraven för Software Appliance med SFOS 22 anger däremot minst 32 GB och rekommenderar 64 GB. Denna guide följer medvetet det mer specifika och försiktiga installationskravet: minst 32 GB, med 64 GB rekommenderat. Planera inte en installation med 10 GB och kontrollera även kraven för den valda SFOS-versionen före installation. Dokumentationskonflikten redovisas därmed, utan att guiden påstår att den har lösts genom ett enhetstest.

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 ansluts till lokala verksamhetsställen. I molnet behöver andra frågor beaktas än på ett traditionellt verksamhetsställe.

Planera:

• VPC/VNet-design,
• routingtabeller,
• tillgänglighetszoner,
• Elastic IPs eller Public IPs,
• Site-to-Site VPN eller SD-WAN,
• loggning och central analys,
• molnkostnader för instanser, lagring, trafik och HA-design,
• driftansvar mellan molnteamet och brandväggsteamet.

En molnbrandvägg ersätter inte en väl utformad molnnätverksdesign. Endast trafik som faktiskt dirigeras genom brandväggen skyddas. Besluten om driftsättning 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 avbildningen 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 hämtades utan 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 utlöser fail-safe mode. Kontrollera den inköpta licensens rättigheter för CPU och resurser innan du ändrar tilldelningen; dessa minimikrav är inte en dimensionering för produktion. Öka rapportdiskens kapacitet när ytterligare CPU/RAM möjliggör större loggvolymer. Hypervisorsnapshots och leverantörens säkerhetskopieringsverktyg är inte brandväggssäkerhetskopior som stöds; använd SFOS säkerhetskopieringsfunktion.

Följande installationsförfaranden måste kontrolleras för den aktuella kombinationen av plattform och SFOS; en lyckad installation bekräftar ännu inte en fungerande produktions- eller återställningsväg. Kontrollera först aktuellt stöd för plattform, operativsystem, administrationsverktyg och avbildning. Validera installationen på en ny, isolerad VM innan du dirigerar produktionstrafik genom den. Låt den befintliga brandväggen och produktionsrutterna vara oförändrade tills installationen har godkänts.

Plattformsöversikterna för SFOS 22 och 23 anger dessutom XCP-ng-Center som ett alternativ till XenCenter för administration inom Citrix-familjen, och för VMware även VMware Workstation som ett alternativ till det ESXi/vSphere-förfarande som beskrivs här. Dessa alternativ i översikterna är inte en bekräftelse på aktuellt stöd och innebär inte ett generellt godkännande av alla XCP-ng-versioner. Innan något av alternativen väljs måste stöd för de exakta versionerna av värd, plattform och administrationsverktyg vara bekräftat. Om stödet fortfarande är oklart ska driftsättningen avbrytas och ett alternativ med dokumenterat stöd användas. De följande stegen för XenCenter och ESXi/vSphere är inte installationsanvisningar för dessa alternativ; i synnerhet får ESXi-förfarandet inte användas som ett installationsrecept för Workstation.

Citrix Hypervisor och XenCenter

Förutsättningar: Citrix Hypervisor är redan installerat på en nåbar värd och XenCenter är installerat på administrationsenheten. Kontrollera vilka versioner av värdplattform, operativsystem och verktyg som stöds och spara det uppackade Citrix OVF-paketet där XenCenter kan läsa alla dess filer.

1. Högerklicka på den avsedda resursen i XenCenter och välj Import > Browse. Välj OVF-filen, klicka på Open och sedan Next.
2. Under Import VM(s) to väljer du destination eller anger en Home Server och klickar sedan på Next. Välj lagringsarkiv för båda diskarna.
3. Koppla nätverksgränssnitten medvetet: PortA till det isolerade administrations-/LAN-nätet och adaptern mot WAN till det separata, avsedda WAN-/testnätet. Exponera inte WebAdmin med fabriksinställningar mot internet.
4. Verify manifest content är valfritt i importguiden; behåll manifestet och utred eventuella avvikelser i stället för att kringgå dem. Fortsätt med Next. Under OS Fixup Settings låter du Don’t use Operating System Fixup vara valt.
5. Granska sammanfattningen och klicka på Finish. Bekräfta att importen lyckades, att båda diskarna finns och att båda nätverkskorten har avsedda kopplingar innan du högerklickar på den nya VM:n och väljer Start. Öppna konsolen och följ sedan det gemensamma förfarandet för första åtkomst nedan.

VMware ESXi och vSphere Client

Förutsättningar: Servern kör redan en ESXi-version som för närvarande stöds och administratören har en fungerande vSphere Client-session med nätverksåtkomst till servern. Packa upp VMware-paketet på administrationsenheten. Äldre beteckningar för virtuell hårdvaruversion visar inte att ESXi 4 eller 5 stöds i dag.

Välj OVF-mall medvetet:

• sf_virtual och sf_virtual_vm7: äldre hårdvaruversion 7, PCNet32 (Vlance), virtuell länkbeskrivning 10 Mbps, halv duplex, fast inställning.
• sf_virtual_vm8: hårdvaruversion 8, E1000E, 1000 Mbps, full duplex, automatisk förhandling On.
• sf_virtual_vm8_paravirtual: hårdvaruversion 8, VMXNET 3, 10000 Mbps, full duplex, automatisk förhandling Off. Använd E1000E som dokumenterat reservalternativ om VMXNET 3-drivrutinen inte fungerar i din installation.
• sf_virtual_virtualbox är inte en VMware-mall. Länkbeskrivningarna ovan är egenskaper hos virtuella adaptrar, inte garantier för brandväggens genomströmning.

1. Högerklicka på driftsättningsplatsen i vSphere Client och välj Deploy OVF Template > Local file > Choose files. Välj den avsedda OVF-filen tillsammans med sf_virtual-disk1.vmdk, sf_virtual-disk2.vmdk och sf_virtual.mf; klicka på Open > Next.
2. Ange namn och plats, välj beräkningsresurs och granska uppgifterna. Gå vidare med Next.
3. Välj datastore och format för de virtuella diskarna. Thick Provision Lazy Zeroed tilldelar utrymme när disken skapas och nollställer block vid första skrivningen. Thick Provision Eager Zeroed tilldelar och nollställer utrymmet när disken skapas, vilket kan ta längre tid. Thin Provision tilldelar utrymme efter behov för att spara plats; övervaka faktisk kapacitet i datastore. Varken beskrivningen av diskformaten eller detta förfarande fastställer stöd från Sophos för Fault Tolerance eller en generell begränsning för diskkonvertering.
4. Koppla båda källnäten medvetet, med PortA på det isolerade administrationsnätet. Granska hela konfigurationen och klicka på Finish. Vänta tills driftsättningen har slutförts utan fel; kontrollera båda diskarnas storlek och de anslutna nätverkskortens kopplingar.
5. Välj Actions > Power > Power on, öppna konsolen och följ det gemensamma förfarandet för första åtkomst.

Hyper-V Manager

Förutsättningar: En Hyper-V-värd som stöds och Hyper-V Manager på en administrationsenhet med nätverksåtkomst till värden. Packa upp Hyper-V-paketet och placera båda VHD-filerna på lagring som värden kan nå; en sökväg som bara är synlig på administratörens dator räcker inte för en fjärrvärd.

1. Öppna Action > Connect to Server och sedan Action > New > Virtual Machine. Välj namn och plats, Generation 1 och Startup memory på minst 4096 MB i guiden.
2. Välj den isolerade virtuella administrationsswitchen för den första adaptern. Välj Use an existing virtual hard disk > Browse > PRIMARY-DISK.vhd > Open. Granska och välj Finish; starta inte VM:n ännu.
3. Högerklicka på den nya VM:n, öppna Settings och välj Network Adapter > Add under Hardware. Koppla den andra adaptern till det separata planerade nätet och klicka på Apply.
4. Välj SCSI Controller > Hard Drive > Add > Virtual hard disk > Browse, välj AUXILIARY-DISK.vhd och sedan Open > OK. Kontrollera den primära startdisken, den sekundära SCSI-disken, båda switchkopplingarna och diskstorlekarna.
5. Högerklicka på VM:n och välj Connect; starta den från konsolen. Följ det gemensamma förfarandet för första åtkomst.

KVM och Virtual Machine Manager

Förutsättningar: En x86 Linux-värd med en aktuell kärna och aktiverat Intel VT eller AMD-V samt installerad och tillgänglig Virtual Machine Manager eller lämpliga KVM-administrationsverktyg som stöds. Kör dessa skrivskyddade kontroller på Linux-värden, inte i SFOS-konsolen:

grep --color vmx /proc/cpuinfo
grep --color svm /proc/cpuinfo

Förvänta dig matchande vmx-flaggor för Intel eller svm för AMD, inte nödvändigtvis båda. Om den relevanta kontrollen inte ger några träffar ska du avbryta och kontrollera CPU-stöd, virtualiseringsinställningar i firmware och, för en nästlad värd, att funktionerna exponeras. Synliga flaggor bevisar inte i sig att funktionen är aktiverad i firmware eller att KVM-installationen fungerar. #!sh i äldre instruktioner är en formateringsmarkör, inte ett kommandoprefix.

1. Packa upp KVM-arkivet. Öppna File > New Virtual Machine > Import existing disk image > Browse, välj PRIMARY-DISK.qcow2 med Choose volume och sedan Forward.
2. Ställ in Memory (RAM) på minst 4096 MB och CPU på minst 1, inom licensrättigheterna och enligt dimensioneringen. Välj Customize configuration before install > Finish. Ange ett namn och välj Apply.
3. Välj det isolerade administrationsnätet som Network source för det första nätverkskortet. Det behållna exemplet använder Device model > Hypervisor default; kontrollera att den resulterande adaptern stöds och välj sedan Apply. Välj inte en gemensam WAN/LAN-brygga utan segmentering.
4. Välj den primära disken, som inledningsvis visas som IDE Disk 1, och sedan Advanced options > Disk bus > VirtIO > Apply.
5. Välj Add Hardware > Network, välj det separata planerade nätet och sedan Device model > virtio > Finish.
6. Välj Add Hardware > Storage > Select or create custom storage > Manage. Välj AUXILIARY-DISK.qcow2 med Choose volume, ställ in Disk bus > VirtIO och välj sedan Finish.
7. Kontrollera båda diskarna, deras bussar och storlekar samt nätverkskortens kopplingar innan du väljer Begin Installation. Välj brandväggen och öppna dess konsol med Open; följ det gemensamma förfarandet för första åtkomst.

Proxmox VE: arbetsflöde för katalogbaserad lagring

Detta sökvägsbaserade förfarande gäller lämplig katalogbaserad lagring, inte godtyckliga LVM-, ZFS- eller Ceph-backender. Granska först /etc/pve/storage.cfg för att identifiera faktiskt lagrings-ID, backend och sökväg. Om din backend inte kan använda dessa QCOW2-filsökvägar ska du avbryta och ta fram ett lämpligt importförfarande som stöds; klistra inte in katalogexemplen i den miljön.

1. Välj servern och Create VM. Ange Name, välj Do not use any media, välj miljöanpassade inställningar för System, Hard Disk och CPU och ställ in Memory (MB) på minst 4096. Standardvärden för Machine, SCSI Controller och Cache är specifika för exemplet, inte generella krav.
2. Välj den isolerade Bridge som används för administration. Låt Start after created vara avmarkerat, granska och välj Finish. Anteckna VMID och bekräfta att detta är den nya, oanvända test-VM:n.
3. Öppna värdens >_ Shell med lämpliga behörigheter. Håll endast denna nya VM avstängd, spara en kopia av /etc/pve/qemu-server/<vmid>.conf och dokumentera dess befintliga diskkoppling. Radera eller ersätt aldrig en produktionsdisk. /var/lib/vz/images/108/ är bara en exempelkatalog för VMID 108; använd sökvägen som hör till din bekräftade lagring och ditt VMID.
4. Överför det KVM-arkiv som faktiskt laddats ned till den katalogen och packa upp det, exempelvis med unzip ACTUAL_DOWNLOADED_ARCHIVE.zip efter att du ersatt platshållaren med det verkliga filnamnet. Förvänta dig PRIMARY-DISK.qcow2 och AUXILIARY-DISK.qcow2; ett historiskt byggversionsfilnamn är inte en instruktion för en aktuell nedladdning.
5. Öppna /etc/pve/qemu-server/<vmid>.conf i en textredigerare. Endast på denna avstängda test-VM, som kan kasseras, ersätter du den ursprungliga scsi0-kopplingen och lägger till den sekundära diskkopplingen. Den behållna exempelsyntaxen är:

scsi0: vmdisk:<vmid>/PRIMARY-DISK.qcow2,size=32G
scsi1: vmdisk:<vmid>/AUXILIARY-DISK.qcow2,size=80G

Ersätt vmdisk med det bekräftade ID:t för kataloglagringen och <vmid> med faktiskt VMID; dessa är inte bokstavliga värden som fungerar direkt. Etiketterna size ändrar inte storleken på en för liten avbildning. Kontrollera att avbildningarnas faktiska storlekar uppfyller minimikraven och att ingen befintlig scsi1-koppling skrivs över.

6. Kontrollera båda diskplatserna, storlekarna och den primära startdisken under Hardware. Använd Add > Network device för att lägga till det andra nätverkskortet på den avsiktligt separata Bridge. Låt QEMU Guest Agent vara avstängt under Options. Kontrollera kopplingarna igen innan du väljer Start och öppnar konsolen.
7. Om ändringen är felaktig ska du hålla den nya VM:n avstängd och återställa dess sparade konfiguration efter att ha kontrollerat VMID och lagringens identitet på nytt. Ta inte bort den ursprungliga diskfilen som en del av återgången. Denna lokala återgång gäller före produktionssättning. Följ det gemensamma förfarandet för första åtkomst först när de korrigerade hårdvarukontrollerna har lyckats.

Nutanix Prism Central

Förutsättningar: AOS 6.5.x eller en senare LTS-version, dess medföljande AHV, en kompatibel Prism Central (PC) och ett AHV-kluster registrerat i PC. Plattformsvägledningen anger den senaste GA (LTS)-versionen av Partner VA: GA betyder General Availability och LTS betyder Long-Term Support. Kontrollera vilken kombination av partner-applianceversion och plattform som faktiskt stöds; en hjälpsida för SFOS 23 identifierar inte i sig den senaste GA-versionen. Bekräfta licensierade CPU-resurser, minst 4 GB RAM, två nätverkskort och diskar på 32 GB/80 GB.

1. Packa upp PRIMARY-DISK.qcow2 och AUXILIARY-DISK.qcow2 från Virtual Installers: Firewall OS for KVM på administrationsenheten.
2. Öppna Virtual Infrastructure > Images > Add Image > Add File i PC. Lägg till varje fil med Image Type > Disk. Klicka på Next, välj Placement Method och Select Clusters för målet och sedan Save. Uppdatera vyn efter uppladdningen och kontrollera att båda avbildningarna är tillgängliga.
3. Öppna Infrastructure > VMs > Create VM. Ange namn och tidszon under General Configuration; ange CPU-resurser enligt licensrättigheterna och tillräckligt RAM under Compute Details. Ta bort standardenheten för CD-ROM under Disks, endast på denna nya VM.
4. Välj Add New Disk > Operation > Clone from Image Service > Bus Type > SCSI > Image > PRIMARY-DISK.qcow2 > Add. Upprepa för AUXILIARY-DISK.qcow2 som loggdisk; det behållna exemplet för den sekundära disken använder också SCSI. Överför inte KVM-instruktionerna för VirtIO-buss hit.
5. Välj det isolerade administrations-VLAN:et under Network Adapters (NIC) > Add New NIC > VLAN Name och välj Add. Upprepa för det separata avsedda andra nätet. Källans alternativ för DHCP-anslutning är valfritt; planera stabil gränssnittsadressering därefter. Ett VLAN-val är inte i sig en IP-adress.
6. Välj en godkänd värd under VM Host Affinity > Set Affinity och välj Save. Spara sedan VM:n. Förvänta dig ett meddelande om att åtgärden lyckades; kontrollera båda diskarna, deras bussar och storlekar samt nätverkskortens kopplingar före start.
7. Starta den nya VM:n och välj Launch console. Följ det gemensamma förfarandet för första åtkomst.

Första åtkomst, validering och säker återgång

Kontrollera PortA och PortB mot administrations-, LAN- och WAN-näten före första starten. Omvända kopplingar kan exponera WebAdmin direkt mot internet. Endast i den isolerade startmiljön är det dokumenterade administratörskontot och fabrikslösenordet admin / admin; konsolen frågar efter administratörslösenordet admin. Öppna https://172.16.16.16:4444 från den isolerade administratörsklienten, exempelvis 172.16.16.2/24. Granska och acceptera Sophos End User Terms of Use och klicka på Start setup för registrering och grundkonfiguration. Byt fabriksinloggningsuppgifterna under konfigurationen innan någon exponering sker och följ sedan komma igång-guiden.

Ändra inte standardlösenordet i CLI före installationsguiden: guiden startar inte därefter. Om detta redan har gjorts ska grundkonfigurationen slutföras manuellt; återställ inte en konfigurerad brandvägg bara för att få tillbaka guiden. En fabriksåterställning raderar konfigurationen och är endast ett medvetet alternativ för en skyddad, ny test-VM som kan kasseras och inte har någon konfiguration att bevara.

Före övergången till produktion ska du kontrollera licens och serienummer, normal start i konsolen, båda diskarna och rapporteringen, gränssnitt och zoner, SFOS-säkerhetskopiering som stöds samt att WebAdmin-åtkomst nekas från ett obehörigt nät.

Installera inte om direkt om WebAdmin inte kan nås. Kontrollera att klienten ligger direkt i PortA:s nät, att vNIC är ansluten och att portgruppen eller bryggan faktiskt är kopplad till det isolerade administrationsnätet. Bekräfta fullständig start i konsolen och uteslut en adresskonflikt med 172.16.16.16. PortA får inte vara ansluten till det publika WAN-nätet. Om rapporter saknas eller fail-safe mode aktiveras ska du kontrollera rapportdiskens tilldelning, buss och storlek, CPU/RAM och båda vNIC. Dokumentera den identifierade orsaken med runbooken för fail-safe mode innan resurser ändras.

Om du beslutar att dra tillbaka den nya driftsättningen före produktionssättning och ingen produktionstrafik ännu dirigeras genom den nya VM:n ska du stänga av den, återställa testrutter och tillfälliga gateways och fortsätta använda den befintliga brandväggen oförändrad. Dessa steg gäller endast när driftsättningen dras tillbaka, inte vid en framgångsrikt validerad övergång till produktion. Efter produktionssättning kräver återställning en aktuell SFOS-säkerhetskopia och en dokumenterad återuppbyggnad, inte en hypervisorsnapshot; använd förfarandet för säkerhetskopiering och återställning.

Software Appliance på egen hårdvara

Målsystemet kräver x86-64, Legacy BIOS, minst 4 GB RAM, två nätverkskort och en HDD/SSD på 32 GB (64 GB rekommenderas). USB-minnet behöver minst 1 GB. Windows/macOS är operativsystemet på arbetsstationen som används för att skriva installationsmediet, inte ett operativsystem som behålls vid sidan av SFOS. Använd nedladdningen Software Installers: Firewall OS Software ISO for Intel Hardware, packa upp arkivet och kontrollera SW ISO-filen och överföringsintegriteten enligt ovan. Använd inte en HW/XGS-avbildning eller ett paket med virtuella diskar.

⚠️ När installationsmediet skrivs raderas hela den valda USB-enheten. Installationen formaterar och partitionerar sedan om målserverns disk och raderar dess tidigare operativsystem och alla data. Identifiera den exakta enheten utifrån kapacitet och enhetsidentitet före båda åtgärderna, spara data externt och verifiera en oberoende återställningsväg. Avbryt om det är oklart vilken enhet som är målet. Det finns ingen automatisk ångring efter installationen; återställning kräver separat sparade installationsmedier och data för det ursprungliga systemet, eller en kompatibel SFOS-säkerhetskopia med dess lösenord och tillhörande SSMK.

Windows: Win32 Disk Imager

1. Sätt i USB-minnet och identifiera dess enhetsbokstav, kapacitet och enhetsidentitet i Windows diskhantering; koppla om möjligt bort andra flyttbara enheter. Hämta och starta Win32 Disk Imager på arbetsstationen.
2. Filväljaren filtrerar normalt på IMG-filer. Ändra filtret till *.* och välj den uppackade Sophos SW-filen med ändelsen .ISO.
3. Välj den bekräftade USB-enheten som mål, inte en system- eller datadisk. Kontrollera den valda filen och enheten igen mot den identitet du dokumenterat, välj sedan Write och bekräfta raderingsvarningen. Vänta tills skrivningen har slutförts utan fel och mata ut enheten säkert. Att kopiera ISO-filen som en vanlig fil skapar inte ett startbart medium.

macOS: alternativ med inbyggda verktyg för att skriva installationsmediet

1. Använd Disk Utility för att identifiera den externa USB-enheten utifrån kapacitet och enhetsidentitet. Äldre instruktioner visar Partitions > Volume scheme: 1 partition > Format: Free Space > Apply; dessa kontroller är versionsspecifika och kanske inte finns i din macOS-version. Hitta inte på en motsvarighet och formatera inte en annan disk för att återskapa det gamla gränssnittet. Förfarandet för att skriva installationsmedier i ominstallationsguiden är ett alternativ, men använd SW ISO-filen här i stället för guidens hårdvaruavbildning.
2. Gå till ISO-filens katalog i Terminal. Ersätt SOPHOS_ISO med det faktiskt nedladdade filnamnet innan du kör:

hdiutil convert -format UDRW -o sf.img.dmg SOPHOS_ISO

3. Förvänta dig den konverterade filen sf.img.dmg. Kör diskutil list, identifiera hela den externa USB-disken igen och avmontera dess volymer före råskrivningen (Disk Utility Unmount, inte utmatning). Avbryt om du inte kan identifiera eller avmontera den avsedda enheten.
4. Följande är en mall, inte ett kommando som kan klistras in och köras direkt. Ersätt PATH_TO_USB med den bekräftade sökvägen till hela enheten, aldrig en partition eller ett antaget disknummer. Kommandot raderar hela den enheten:

dd if=./sf.img.dmg of=PATH_TO_USB bs=1m

Använd sudo endast om enhetsbehörigheterna kräver det, efter att du har kontrollerat målet på nytt. En råenhetssökväg lägger till r i det bekräftade enhetsnamnet (/dev/diskN blir /dev/rdiskN); N är en platshållare, inte ett disknummer att kopiera. Rååtkomst kan vara snabbare men gör inte åtgärden säkrare. Vänta tills kommandot har slutförts utan fel och kommandoprompten visas igen; skriv väntande data till disken med sync och mata ut USB-enheten säkert innan du tar bort den. Avbryt vid fel i stället för att installera från ett medium vars skrivning inte har verifierats.

Installera och kontrollera den fysiska servern

1. Planera driftstopp, bevara den befintliga trafikvägen genom brandväggen och externa säkerhetskopior och kontrollera Legacy BIOS/USB-start samt exakt vilken disk som ska användas för installationen. Koppla om möjligt bort andra datadiskar. Anslut lokal bildskärm och tangentbord samt en lämplig seriell konsol vid behov.
2. Starta från det förberedda USB-minnet. Innan du skriver y och trycker på Enter vid installationsprogrammets bekräftelse ska du kontrollera serverns och diskens identitet igen och bekräfta att allt tidigare operativsystem och alla data får raderas. Avbryt om installationsmålet är oklart. Följ anvisningarna tills installationen är klar, ta bort USB-minnet och starta om; första starten kan ta några minuter. Tillämpa inte XGS-instruktioner för lysdioder på denna generiska server.
3. Kontrollera de identifierade nätverkskorten och identifiera administrationsgränssnittet innan du ansluter den isolerade administratörsklienten med 172.16.16.2/24. Bekräfta normal start och använd https://172.16.16.16:4444, Terms of Use och Start setup enligt ovan. Säkra inloggningsuppgifterna, slutför registrering och licensiering och spara en extern SFOS-säkerhetskopia före övergången till produktion.
4. Om USB-minnet inte startar ska du kontrollera att avbildningen skrevs till det i stället för att kopieras som en fil, att rätt SW-avbildning användes och att Legacy BIOS/USB-start är valt. Vid saknade nätverkskort eller fail-safe mode ska du dokumentera orsaken i konsolen och kontrollera minimikrav och drivrutinskompatibilitet före ominstallation. Om WebAdmin inte kan nås ska du kontrollera administrationskortets identitet, länk, klientadress, fullständig start och adresskonflikter; anslut aldrig administration med fabriksinställningar till publikt WAN som en genväg. Använd den interna fail-safe-guiden, komma igång-guiden och guiden för säkerhetskopiering och återställning för nästa beslut.

Denna dokumentationsguide gör inte anspråk på att någon USB-skrivning, destruktiv installationsåtgärd, driftsättning på fysisk utrustning eller återställning har utförts.

Planera drift och återställning

Prestanda och dimensionering

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. Guiden till tolkning av prestandadata för Sophos Firewall förklarar dessa skillnader.

HA och återställning

Hög tillgänglighet skiljer sig markant beroende på plattform. För hårdvara är HA vanligtvis lättare att överblicka: två appliances, en HA-länk, definierade gränssnitt och en tydligt specificerad ersättningsenhet. För virtuella installationer och molninstallationer tillkommer fler frågor:

• Körs HA-noder på olika värdar?
• Är lagringen, nätverket och hypervisorn verkligen redundanta?
• Ä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 bortfall av en värd eller en tillgänglighetszon testats?

Grunderna för HA-varianterna beskrivs i guiden för att konfigurera hög tillgänglighet (HA) i Sophos Firewall. Inför återställning behöver du läsa guiden för att skapa eller återställa en säkerhetskopia i Sophos Firewall.

Licensiering och support

Licensvillkoren måste kontrolleras före driftsättning eller resursändringar. Äldre installationsanvisningar för plattformarna begränsar både vCPU och vRAM till den inköpta licensen. Artikeln som länkas nedan beskriver en ändring för kommersiella virtuella licenser, programvarulicenser och molnlicenser med BYOL, som gäller från den 1 mars 2025 och innebär licensiering efter CPU-kärnor utan den tidigare RAM-gränsen. Den beskrivningen bevisar inte att varje SKU, äldre licensrättighet eller Home-licens har samma villkor. Bekräfta inköpt SKU och rätt till CPU-kärnor, serienummer, prenumeration och support samt instansens faktiska licensstatus i licensportalen innan du tilldelar resurser. Om licensrättigheterna är oklara ska du avbryta och reda ut dem med licensleverantören. Tillämpa inte den kommersiella ändringen på Home-licenser och dra inte slutsatsen att resurserna är obegränsade utifrån denna artikel. Installationsminimum på 4 GB och dimensioneringen av RAM, lagring och nätverkskort för produktion är fortfarande tekniska krav, oavsett eventuell licensgräns.

Information om grundlicensen finns i Sophos Firewall – baslicens. Den beskrivna ändringen för virtuella licenser och programvarulicenser behandlas i Sophos Firewall VM & SW – endast CPU räknas, ingen tidigare RAM-gräns; även där måste villkoren för den inköpta licensen bekräftas.

Viktigt i driften:

• Dokumentera licens- och supportstatus.
• Dokumentera serienummer och registreringsstatus tydligt.
• Kontrollera HA-licensieringen innan klustret byggs.
• Kontrollera firmware och rätten till support före uppgraderingar.
• Känn till RMA- eller återställningsprocessen för den valda plattformen.

Före större uppgraderingar bör även kontrollguiden inför uppgradering av Sophos Firewall till SFOS 22 användas, eftersom plattformsstöd, lagringsutrymme, säkerhetskopiering, HA och äldre VPN-konfigurationer kan påverka uppgraderingen.

För active-passive HA på virtuella appliances eller Software Appliances behöver endast den primära noden alla nödvändiga licenser, inklusive Base Firewall-licensen. För active-active HA behöver varje nod en egen Base Firewall-licens och samma ytterligare skyddslicenser; utgångsdatumen får skilja sig åt. Red ut detta innan klustret byggs, inte under felsökningen av den första failover-händelsen.

Beslutsmatris

• Traditionellt verksamhetsställe med WAN, LAN och DMZ: Vanligtvis hårdvara. Virtuellt endast med en genomtänkt virtualiseringsstrategi.
• Datacenter med befintligt hypervisorteam: Hårdvara är ett alternativ, men virtuellt är ofta lämpligt.
• Arbetsbelastningar i AWS eller Azure: Främst virtuellt eller moln, inte traditionell hårdvara.
• Enkel support och RMA är viktigt: Främst hårdvara. För virtuella lösningar och molnlösningar beror mycket på plattformsteamet.
• Många fysiska nätverksportar krävs: Främst hårdvara. Virtuellt endast med en väl utformad NIC- och vSwitch-design.
• Dynamisk skalning och Infrastructure as Code: Främst virtuellt eller moln.
• Litet IT-team utan specialiserad hypervisorkunskap: Vanligtvis hårdvara; planera virtuella brandväggar noggrant.
• Design för flera klientorganisationer eller segmentering i datacentret: Hårdvara är ett alternativ, men virtuellt är ofta lämpligt.

Vanliga fel

• Att köra en virtuell brandvägg på en värd med överallokerade resurser.
• Att inte hålla WAN, LAN och administration tydligt åtskilda på hypervisorn.
• Att välja hårdvara efter pris i stället för kapacitetsdimensionering.
• Att driftsätta en molnbrandvägg utan att slutföra routingdesignen.
• Att planera HA utan att testa bortfall av värdar, lagring eller molnresurser.
• Att skapa säkerhetskopior utan att öva på återställning.
• Att kontrollera licens- och supportstatus först vid en uppgradering.
• Att lägga till TLS Inspection eller IPS utan prestandareserver.
• Att involvera de ansvariga för plattform, nätverk och brandvägg först efter en incident.

Checklista

• Driftsmiljön är tydligt definierad: fysiskt verksamhetsställe, datacenter eller moln.
• Trafik, bandbredd och säkerhetsfunktioner är dokumenterade för dimensioneringen.
• Valet av hårdvara, virtuell appliance, Software Appliance eller molnlösning är medvetet gjort.
• Ansvaret för brandvägg, hypervisor, moln och nätverk är dokumenterat.
• HA- och återställningsdesignen är kontrollerad.
• Processen för säkerhetskopiering och återställning är testad eller planerad.
• Licens, support och registrering är klarlagda.
• Övervakning finns för brandväggen och den underliggande plattformen.
• Uppgraderingsmöjligheter och plattformsstöd är kontrollerade.
• Ansvariga för plattform, nätverk, brandvägg, säkerhetskopiering och återställning är utsedda.

Vanliga frågor